Information Technology Reference
In-Depth Information
the core statechart treats the 'closeDoor' event exactly and transfers to the
'DoorClosing' state.
[3] If the core statechart is in the 'DoorOpening' state and no any event is intro-
duced, and if the time aspect statechart is in the state 'Normal' satisfying
' t>Max_Time '. Then the time aspect statechart transfers to the 'TimeOut' state,
the core statechart transfers to the 'DoorClosing' state.
[4] If the core statechart is in the 'ReadyMove' state and a 'down(up)' event is in-
troduced, and if the time aspect statechart is in the state 'InitState' satisfying
't>=Min_Time&&t<=Max_Time'. Then the time aspect statechart transfers to
the 'Normal' state, the core statechart treats the 'down(up)' event exactly and
transfers to the 'Elevator Starting
Down(Elevator Starting Up)' state.
The time aspect and core statecharts will only make the transitions based on the decla-
rations defined above. So it makes sure that the system will implement strictly relying
on the timing constraints and guarantee the real time feature. Weaving the time aspect
of the elevator system is shown in Fig. 7. We take a step forward from the work de-
scribed in [35] by extending the reinterpretation function so that an aspect can be
woven into other aspects or core classes. In the example above, weaving can be speci-
fied using a reference to the core 'statechart' object and a reference to the aspect
'statechart' object:
AspectID= core.crosscutBy(TimeAspect);
This specifies how an aspect is woven into other aspects or core classes. Every
weaving of aspect has unique AspectID. When aspects are weaving, methods will be
called to map events in the core and aspect statecharts. The declarations will hold
which events need to be reinterpreted. These details will be filled in while a specific
aspect is woven. The declarations above are equivalent to the expressions as follows:
[1]. reinterpretEvent(ore,”ElevatorStopping”,”openDoor”,”InitState”,”start/t>=OPEN_
MIN_TIME&&t<=OPEN_MAX_TIME”,AspectID,Statechart.PREHANDLE)
[2]. reinterpretEvent(ore,”DoorOpening”,”button”,”InitState”,”start/t>=STAY_OPE
N_MIN_TIME”,AspectID,Statechart.PREHANDLE)
[3]. reinterpretEvent(ore,”DoorOpening”,” ”,”Normal”,”start/t>STAY_OPEN_NOR
MAL_TIME”,AspectID,Statechart.PREHANDLE)
[4]. reinterpretEvent(ore,”ReadyMove”,”down(up)”,”InitState”,”start/t>=CLOSE_M
IN_TIME&&t<= CLOSE_MAX_TIME”,AspectID,Statechart.PREHANDLE).
This is done without either statechart explicitly knowing about the other. The aspect
statechart can be used in any situation. Since there is no restriction on which state-
chart may crosscut a core statechart or it may crosscut another aspect statechart. In
order to designate the real-time features explicitly, we can add the timing constraints
in formal expressions like RTL to the weaving statechart as it is shown in Fig.7. The
code generation will be our future work and is not discussed here.
The above three case studies have shown that aspect-oriented specification can
simplify system specification. With reference to software systems concerns can be
viewed as distinct system aspects or features. Concern-based decomposition has be-
come central to software development due to the benefits that such an approach can
potentially provide. A number of benefits result from maintaining a separation of
Search WWH ::




Custom Search