Architecture Modeling - SPES 2020

Architecture Modeling
When specifying requirements there is no strict typing like int or real but there are categories
that specify what is described by the different attributes. To not complicate the language too
much and to be also expressive enough, the set of supported attributes has been carefully chosen:
• Events represent activities in the system. An event can be for example a signal, a user
input by pressing a button, or the availability of a computational result. Events occur at
specific points in time and have no duration.
• Conditions are logical and/or arithmetical expressions over variables and the status of
events. Conditions can be used in two different ways. Firstly, they can be used as pseudo
events to trigger an action if the condition becomes true. And secondly, they may represent
the system state that has to hold for a specified time.
• Intervals describe a continuous fragment of time whose boundaries are either (relative)
time measures, or events. Intervals can be open “]x,y[“ or closed “[x,y]” or a combination.
• Components refer to entities that are able to handle events or condition variables.
RSL supports various combinations of elements. It allows for example filtering of events by
intervals or conditions. That is, whenever a pattern expects an event, one may also use “event
during interval”, or “event under (condition)”. Thus, one can e.g. specify
whenever request during [activate,deactivate] occurs response occurs during [l,u]
meaning that a response is constrained only if the request happened after an activate and before
some deactivate event. Filtering of events can be applied recursively. So activate could again
be filtered by some interval or condition.
The interested reader is referred to Section 6.1 for a detailed description of the RSL.
While specification languages such as RSL help the engineer to formalize requirements, there
are other pitfalls when specifying contracts. Two key properties of contracts, essential to maintain
sanity of the design-flow shall be discussed here, namely receptiveness and consistency.
Receptiveness Since the interface of a component distinguishes input ports and output ports,
there is a clear separation between those ports the component controls and those that are controlled
by the components environment. Receptiveness denotes the fact that also the responsibilities
of both assumption and guarantee of a contract are properly distinguished. More formally,
a contract is receptive only if the assumption does not restrict possible behavior of the output of
a component, and if the guarantee does not restrict the input ports.
To give an example, we assume a component with inport i and outport o. A guarantee stating
that, whenever the component sends an event to o, the environment responds by another event
send to i within, say 5 ms, violates the receptiveness property. It violates receptiveness because
it is not the duty of a components guarantee to require the environment to react in a certain
amount of time. For the same reason, an assumption stating that the component produces an
output event each 10 ms violates receptiveness. On the other hand, an assumption for such a
component, stating that whenever the component sends an event to o, the environment responds
by another event send to i within 5 ms, perfectly maintains receptiveness. A receptive contract
is denoted directed.
49/ 156