09.08.2013 Views

Architecture Modeling - SPES 2020

Architecture Modeling - SPES 2020

Architecture Modeling - SPES 2020

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!