CORRECTNESS

Algorithm 5.21Weaving conflict handling

1: procedureWEAVECONFLICTHANDLING(Aspect)

2: r←container(Aspect)

3: insertTransition(Aspect,Err(r),∗,GT(Aspect) =err,skip) 4: end procedure

istrue, then this variable is returned; otherwise, i.e. if at least two different resump- tion variables on the highest priority level aretrue, thenerris returned, indicating the state machine to enter an exception state or to handle the exception.

GT(Aspect) =                              ⊥, if¬∃s∈S r∈region(Aspect)gtVars(r)·[gt(s)] g, ifgt(g), g∈S r∈region(Aspect)gtVars(r), and∀s∈S r∈region(Aspect)gtVars(r) ·[(s6=g∧pr(s)≥pr(g)) =⇒ ¬gt(s)] err, if∃g1, g2∈S_r∈region(Aspect)gtVars(r)

·[g1 6=g2∧pr(g1) =pr(g2)∧gt(g1)∧gt(g2)∧ ∀s∈S

r∈region(Aspect)gtVars(r) ·[pr(s)>pr(g) =⇒ ¬gt(s)]]

5.7. Correctness

Our weaving algorithms implement the informal semantics given in Sect.4.3

correctly, we show this in the following theorem:

THEOREM5.9 (Correctness of the weaving algorithms). Given a state machine

SM and a setAof aspects. Let the result of weaving the aspects contained inA

toSMbeSMA. IfSMandSMAare in the same constellation, that is, if the active

state configuration and the environment (the valuation of the variables) are the same in bothSMandSMA, then in the next execution step ofSMsome aspecta∈

Ais activated iff. in the next execution step ofSMAsome aspect state containing a region implementingais activated.

PROOF. We first prove that when an aspect a is activated by SM, then, in

SMA, an aspect state containing a region implementingais also activated. Ifais

awhilstaspect, its activation is the result ofSMbeing in a certain constellation

(active state configuration and variable valuations) and handling a certain event. According to Algorithm 5.18, there is a transitiont0 inSMAthat should be fired

in the same constellation upon the same event. Since t0 leads to an aspect state containing (among others) an instance ofa, this instance is activated in the next step. If ais a transition aspect, then the activation of acan be only caused by a change of the constellation ofSMas a consequence of the firing of some transition

t ∈ T(SM). Let t’s corresponding transition inSMA betA. SinceSMandSMA

have the same constellation,tAis now fired inSMA. According to Algorithm5.19,

tAleads to an aspect state Aspect, containing an instance of every aspect (in par-

ticular, a) that is applicable to t. Due to the same environment ofSM andSMA, the precondition ofais also satisfied inSMA. Therefore, the instance ofainSMA

On the other hand, suppose an instance R of some aspect a is activated in

SMA. This means thata’s precondition is satisfied and that there is a transition

tA leading to some aspect state Aspectcontaining R is fired. Due to the same

environment ofSMandSMA, the precondition is also satisfied inSM. Moreover, if ais a_whilstaspect,trigger(pointcut(a))is the current event; ifais a transition

aspect, tA’s corresponding transition, t, should be fired inSM. In both cases, it

holds thatais activated.

5.8. Implementation

Modeling with HILA and weaving of aspects were implemented prototypically in the tool Hugo/HILA, an extension of the UML translator and model checker Hugo/RT [45]. Aspects are given in an extension of the UTEformat2and woven according to the algorithms described above. The weaving result is then output in

UTEagain.

5.8.1. Hugo/RT. Hugo is a translator and model checker for UML 1.x [56] state machines. It closes the gap between the state machine model, enhanced by the temporal language specification of the properties to verify, and the model checkers SPIN [36] andUppaal[49]. Currently, Hugo/RT supports only UML 1.x.

Model. The input model, consisting of UML state machines, is specified in the ArgoUML3_format

.zargo, the MagicDraw4_{, or Hugo/RT’s (proprietary) textual for-}

matUTE. The state machines are then translated to kripke structures [13] that are accepted by the aforementioned model checkers. Simply spoken, Hugo/RT breaks down the hierarchical structure of UML state machines, calculates the (compound) transitions to fire, and updates the variables according the the UML Specifica- tion [56]. The translation details are beyond the scope of the thesis, the interested reader is referred to [44].

Specification. For the specification of system properties, both linear tempo- ral logic (LTL) and computation tree logic (CTL) [48] can be used. Note that in Hugo/RT the operators G(always), F(eventually) andU(until) are defined on UML states instead of states of the transition system. Hugo/RT translates property specifications containing these operators transparently from the view of the user into temporal logic formulae w.r.t. the underlying kripke structure.

Moreover, Hugo/RT also supports the OCL statement inState, returning if a given state is active. This statement can currently only be used in a temporal logical specification, but not in the state machine. We therefore still need the preprocessing step “inserting trace variables” (Sect.5.3.5) to make the states “know” which other states are also active.

Note, however, that Hugo/RT does not support the deferment of completion events. In Hugo/HILA we use “defer *” to defer completion events.

5.8.2. Weaving. We extended Hugo/RT by the functionality of reading HILA aspects and weaving them to a base machine. In fact, we extended theUTEformat and its Hugo/RT parser to cover aspect definitions as well. Our extension also

2_{http://www.pst.ifi.lmu.de/projekte/hugo/#UTE}

3_{http://www.argouml.org} 4_{http://www.magicdraw.com/}