Information Technology Reference
In-Depth Information
instantiation is limited to the initialization phase while destruction of objects
is not used at all. This fits well into the current practice in embedded systems
design, where a constant, limited and predictable memory footprint is wanted.
This also avoids some of the semantic variation points on deletion/creation in
context of composition and aggregation relations between classes.
Classes, member-fields and method definitions map easily to the respective
counterparts in the OOAS as described in the previous section. Mapping of in-
heritance is also straight forward, provided the subclass is a valid superposition-
refinement of the superclass. Behavioral aspects are mainly expressed with state
machines in the selected UML subset; while there is a similarity between state
machine transitions and guarded actions, some of the features of UML state
machines need some more thought on how to implement them in OOAS.
4.2 Events
Transitions in UML state machines are triggered by events. There are four trig-
ger types:
signal triggers, call triggers, change triggers
and
time triggers
.All
events concerning an object are stored in the object's event pool until they are
consumed, e.g., by transitions. Although we assume that there is always only one
external input event at a time, multiple objects might be interested in an event,
e.g., a signal reception event, and processing the event might produce further
events before the initial events are consumed in the other objects. Hence the
need to implement an event-management logic.
Most models are developed with an assumption of in order processing of
events, therefore we decided to use event queues, implemented as lists in OOAS.
The event distribution logic of the respective event type adds the event at the
end of the list. State machine transitions consume events from the front of
the list. Providing real pool behavior with OOAS can be easily done by non-
deterministically choosing the event to process next, at the cost of increased
non-determinism.
A transition path (one direct transition between states or a series of transitions
connected by choice pseudo-states) is implemented as a named action of the
following form:
1
transition OpenAndLocked to ClosedAndLocked =
requires
( state = OpenAndLocked)
and
2
(events
<>
[nil])
and
3
(
hd
events) [0] = received AlarmSystem Close) :
4
state := ClosedAndLocked
5
end
;
6
7
/
.. other transitions ..
/
8
dequeue =
9
requires
events
<>
[nil] :
10
events :=
tl
self .events
11
end
The
requires
expression (guard) of the transition tests if the object is in the
source state, and whether the first event in the event queue is one of the trigger
events of the transition. In case the transition has a guard, it is also checked.
All actions modeling transitions are combined by non-deterministic choice as
follows.
