Architecture Modeling - SPES 2020
Architecture Modeling - SPES 2020
Architecture Modeling - SPES 2020
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
6.1.1.1.1<br />
Attribuute<br />
Definit tion and SSemantics<br />
There are<br />
three kinds<br />
of attribu utes that aree<br />
used in th he functional<br />
patterns: EEvents,<br />
Inter rvals and<br />
Conditions.<br />
In most ccases<br />
these attributes arre<br />
intuitive to o use and no o special knoowledge<br />
is necessary n<br />
to speciffy<br />
requiremeents.<br />
This se ection defines<br />
the exact syntax and semantic of basic and advanced a<br />
features of the attribuutes<br />
and its possible p connversions<br />
and d combinatio ons.<br />
6.1.1.1.1.1<br />
Evennts<br />
Events aare<br />
signals thhat<br />
occur at a defined pooint<br />
in time. Examples ar re messagess<br />
that get se ent over a<br />
bus systtem,<br />
sporadic<br />
signals fr rom sensorss<br />
or even us ser interactio on like presssing<br />
a butto on. While<br />
specifyinng<br />
events thhe<br />
names ca an be choseen<br />
by the re equirements engineer, bbut<br />
have to be used<br />
consistently,<br />
i.e. samme<br />
events ha ave to have the same id dentifiers. If there<br />
exists aan<br />
architectu ure these<br />
names hhave<br />
to be mapped<br />
to the e correspondding<br />
parts in the t design model m in laterr<br />
design stag ges.<br />
Specifyy<br />
locationn<br />
of event occurrencce<br />
It is posssible<br />
to specify<br />
for each event e the loccation<br />
where it occurred.<br />
A compoonent<br />
can reefer<br />
to system m componennts<br />
like “Brak ke Actuator” or “Engine CController”<br />
bu ut also to<br />
non systtem<br />
artefactss<br />
like “Driver r” or “Passennger”.<br />
It is hig ghly recomm mended to usse<br />
the same identifier<br />
for samee<br />
componentts.<br />
In later ddesign<br />
steps the compon nent identifierrs<br />
can be ma apped to the actual archiitecture<br />
of the<br />
system<br />
to start aanalysis<br />
taskks.<br />
Even the consistent uuse<br />
of identif fiers can be one o of the poossible<br />
analy yses, it is<br />
not part of the speciffication<br />
langu uage to guaraantee<br />
consis stency, but allow<br />
the checcking<br />
of it.<br />
The termm<br />
“Componeent”<br />
can be fu urther refinedd:<br />
and<br />
The requesst<br />
event star rts the patterrn<br />
and requires<br />
a respon nse in the defined<br />
time frame. Is<br />
there no request<br />
event there is no specification n for the occurrences<br />
of tthe<br />
response<br />
events.<br />
There mighht<br />
be such an n event or noot.<br />
But of courrse<br />
there might<br />
be otheer<br />
patterns th hat restrict the t occurrennces<br />
of the response<br />
event.<br />
Event on<br />
whenever GearUp on ShifttPaddleCon<br />
ntroller<br />
occurs duuring<br />
[0ms s,100ms].<br />
Event on<br />
Event on<br />
Component t<br />
user User r<br />
system Sy ystem<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Component<br />
Useer<br />
System S<br />
occurs oopen<br />
on<br />
clutch<br />
It is posssible<br />
to use component and user or system. The e later ones can be usedd<br />
to explicitly y mention<br />
user inteeraction<br />
or syystem<br />
behav vior.<br />
111/ 156