Model-Driven Evolution of Software Architectures - Software and ...

5.6. ApplicationtoOcé 95
rule TopCompositeState {
from cs_in:UML!CompositeState
using {
sm:UML!StateMachine=thisModule.allStateMachines->select(sm|sm.top
=cs_in);
}
to cs_out:UML!CompositeState (
name collect(cs|thisModule.CompositeState(sm,cs))))
}
rule CompositeState (sm:UML!StateMachine, cset:Set(UML!Constraint))
{
to cs:UML!CompositeState(
subvertex union(sm.
compositeStateConstraintSeqsAt(cset)->collect(cs|thisModule.
CompositeState(sm,cs))))
do{cs;}
}
Listing 5.4:Addinghierarchytostatemachine
tobeintheindicatedstate.Hence,weattachacorrespondingprecondition
tothemessage. Figure5.7onthenextpageshowsanexample. Finally,
weadda(public)attribute, state,totheclasscorrespondingtothe ESM
component.
5.6.2 Results
AfragmentoftheresultofapplicationofthetransformationstepstoOcé’s
ESMcomponent,isdepictedinFigure5.8onpage97. Thedashedline
indicatesthepaththroughthestatemachinethatistraversedwhenESM
isrequestedtogotostandbywhileitisrunning.Thispathcorrespondsto
thescenariodepictedinFigure5.7onthenextpage.
Wecomparedthisderivedstatemachinewiththeimplementationstate
machine,fromwhichOcégeneratescode. Therearemanyinconsistencieswithrespecttolow-levelstatesandtransitions.Intheimplementationstatemachinelow-levelstatesarenotonlydecomposedfurther,the
sequenceofstatesandtransitionsisalsodifferentinmanycases. This
isnotsurprisingconsideringthefactthatthesequencediagramsofthe
sourcemodelfromwhichwederivedastatemachine,constitutethefirst
behaviouralmodelthatiscreatedforthe ESMcomponent,while,inthe
implementationstatemachine,low-leveltransitionsandstatesoftencorrespondtoasinglemethodcallinthegeneratedcode.
Ifwerestrictthe