Model-Driven Evolution of Software Architectures - Software and ...
Model-Driven Evolution of Software Architectures - Software and ...
Model-Driven Evolution of Software Architectures - Software and ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
94 Chapter5. <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
IntroducingHierarchy AssuggestedbyWhittle<strong>and</strong>Schumann[2000],weuse<br />
anorderedsubset<strong>of</strong>theset<strong>of</strong>statevariablestoaddhierarchybymeans<br />
<strong>of</strong>CompositeStates.Thesestatevariablesdefineahierarchy<strong>of</strong>Composite-<br />
States.Forinstance,thestatevariablewiththehighestpriorityresultsin<br />
CompositeStatesinthetoplevelCompositeState:oneforeachvalue<strong>of</strong>that<br />
statevariable’sdomain(providedthatitoccursinone<strong>of</strong>thesimplestates’<br />
stateinvariants). Foreach<strong>of</strong>theresultingCompositeStates,thesecondhighestprioritystatevariable,inturn,resultsinCompositeStatesforeach<br />
value<strong>of</strong>thatstatevariable’sdomainthatoccursincombinationwiththe<br />
correspondingvalue<strong>of</strong>thehigher-prioritystatevariable.<br />
Theproblem<strong>of</strong>specifyingthismappingwithATListhatthereisnot<br />
alwaysamatchingsourcemodelelementtocreateaCompositeStatefor.<br />
Therefore,weuseanATLcalledrule(CompositeState). Acalledruleisan<br />
imperativerulethatisnotmatchedbyasourcemodelelement. Instead,<br />
itisexplicitlycalled<strong>and</strong>canhaveparameters.The CompositeStatecalled<br />
ruleinListing5.4 createsaCompositeStateforagivenset<strong>of</strong>Constraints<br />
(cset). TheseConstraints(i.e.,stateinvariants)aredeterminedbythe<br />
compositeStateConstraintSetsAthelperthattakesaset<strong>of</strong>Constraintsthat<br />
representsthecurrentCompositeState<strong>and</strong>determinesthesets<strong>of</strong>ConstraintsthatcorrespondtotheCompositeStatesatthatlevel.Foreach<strong>of</strong><br />
thosesetsaCompositeStateiscreated.Thiscalledruleisusedtoinitialise<br />
the subvertexfeatureintherulethatmatchesthetopCompositeState<strong>of</strong><br />
themergedStateMachine,aswellas(recursively)inthe CompositeState<br />
ruleitself. Thedoclauseinthe CompositeStaterulereturnsthecreated<br />
CompositeState.<br />
5.6 ApplicationtoOcé<br />
Inthissectionwefirstexplainwhatadditionalworkhastobedonetoapply<br />
ourapproachtotheOcécase. Subsequentlywegiveanoverview<strong>of</strong>the<br />
resultsobtainedbyapplication<strong>of</strong>ourapproach.<br />
5.6.1 Source<strong>Model</strong>Normalisation<br />
Inthecase<strong>of</strong>Océ,neitheradomaintheory,noraset<strong>of</strong>statevariables<br />
wereavailable. Toovercomethis,wenormaliseOcé’ssequencediagrams.<br />
Inparticular,weinterpretthedecorationsonobjectlifelinesaspre-<strong>and</strong><br />
postconditionsonasinglestatevariable<strong>of</strong>asuitableenumerationtype:<br />
state. Themessageprecedingastatedecorationapparentlyresultedin<br />
thecomponentmovingtotheindicatedstate.Hence,we(manually)attach<br />
acorrespondingpostconditiontothemessage(e.g., esm.state=starting).A<br />
messagesucceedingastatedecorationapparentlyrequiresthecomponent