Architecture Modeling - SPES 2020

can be uused
to generate
the arch hitecture. Whhen
specifyin ng requireme ents there is nno
strict typin ng like int
or real but
there are categories th hat specify wwhat
is described
by the different d attribbutes.
To not ccomplicate
thhe
language e too much and to be also a expressive
enough the set of supported s
attributess
has to be ccarefully
chosen:
Event
Events repreesent
the act tivity in the syystem.
An ev vent can be for f example a received signal,
a
uuser
input byy
a pressed button, b a commputational
result r or the change of a value. Event ts occur
aat
one point of time and have h no duraation
in time. .
CCondition
A condition is
a logic and d/or arithmetiic
expression n based on variables v andd
the status of
eevents.
Condditions
can be b used in twwo
different ways w in patter rns. On the oone
hand the ey can be
uused
as pseudo
events to t trigger an action if the condition becomes
true. On the other
hand
tthe
conditionn
can be the system statee
that has to hold for a sp pecified time.
The values s the
ccondition
is bbased
on ma ay change wiith
time only.
IInterval
Intervals desscribe
a cont tinuous fragmment
of time which can ha ave relative aand
quantita ative time
mmeasures
ass
delimiters or o events. Inttervals
can be b open “]x,y[“
or closed “ “[x,y]” or a
ccombination
of them.
JJitter
JJitter
of an eevent
is the variation
in thhe
point of tim me of occurre ence in a reaal
time contex xt. In this
ddocument
jittter
is conside ered as alwaays
positive, i.e. the even nt is delayed. .
CComponentt
CComponentss
refer to entities
that aree
able to hand dle events or r condition vaariables.
Typ pically
tthese
compoonents
refer to t an actual architecture, , but in early design stagees,
where the
system
hhas
not beenn
designed completely c thhere
are also “possible” component
naames
allowe ed. These
iidentifiers
caan
either be used u to geneerate
the mis ssing architec cture or be mmapped
to the
design
iin
later development
stag ges.
6.1.1 PPattern
sppecification
In this ssection
the different pat tterns get described
in more detail.
The patterns
are liste ed in the
previoussly
mentioned
categories s. Some of tthe
patterns can be use ed to expresss
requireme ents from
more thaan
one cateegory.
Althou ugh there arre
only listed d in the mos st used cateegory,
other applying
categoriees
are menttioned
in the e descriptionn.
For each pattern the syntax and a descriptio on of the
semanticcs
are providded.
In secti ion 6.1.2 wee
give an exe emplary view w on the formmal
semantics
of the
observerr
of a patternn
that is used d to verify thee
correct beh havior of a co omponent aggainst
a requirement.
6.1.1.1
Functionnal
Pattern n:
Architecture Modeling
The funcctional
patterns
describe e relationshipps
between events, cond dition and suubjects.
For example
events ccan
depend on other ev vents or connditions
have e to hold af fter an evennt
has occurred.
This
pattern ccan
be usedd
to express the functional
behavior of a system.
Since all paatterns
have e optional
interval aattributes,
thhese
patterns s can also bbe
used to ex xpress simple
timing connstraints.
On n the one
hand theese
constrains
may refer
to events and conditio ons, on the other o hand tthese
constrains
may
refer to rreal
time.
Functionnal
pattern coonsist
of a tr rigger and ann
action. If the
trigger oc ccurs, the paattern
“starts”
and the
action haas
to occur tooo.
110/ 156