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.
5.5. GeneratingStateMachines 89<br />
theorythatrefert<strong>of</strong>ormalparameters<strong>of</strong>theoperationsinvolved,asthis<br />
wouldrequireinterpretation<strong>of</strong>theseconditions. Ifnecessary,suchconstraintscanbeaddeddirectlytotheMessagesthatspecifyanactualparameterinthesequencediagrams.TheactiveClasscontainsanAttributeforeachstatevariable.Thesubset<strong>of</strong>statevariablesusedforintroducinghierarchyisencodedbysetting<br />
thevisibility<strong>of</strong>allstatevariablesincludedinthesubsettopublic<strong>and</strong>the<br />
otherstoprivate.Finally,theorder<strong>of</strong>thestatevariableAttributesonthe<br />
Classrepresentstheprioritisation<strong>of</strong>statevariables(thetoponehaving<br />
thehighestpriority). Thispriorityindicatestheorderinwhichthestate<br />
variablesareusedtopartitiontheset<strong>of</strong>statesbyassigningthesestatesto<br />
CompositeStatesaccordingtothevalueassignedtothestatevariable.<br />
5.5.2 <strong>Model</strong>Transformations<br />
Ourtransformationsgenerateastatemachineforthecomponentthatis<br />
representedbytheactiveClassinthesourcemodel. Ascenariospecifiesoneparticularpaththroughthestatemachineforthatcomponent,on<br />
whichitproceedstothenextstateuponeachcommunication.Wereferto<br />
thestatemachinethatonlydescribesthatpathasa‘flat’statemachine.<br />
WetailoredtheapproachinWhittle<strong>and</strong>Schumann[2000](seeSection5.3)toaccountforthetype<strong>of</strong>inputintheOcécase,forourmodeldrivenstrategy,<strong>and</strong>forourgoal:<br />
consistencychecking. Forthisreason<br />
weintroducefewerabstractions,makingdetecting<strong>and</strong>resolvinginconsistenciesmoreconvenient.<br />
Ourmappingconsists<strong>of</strong>fourseparatesteps:1)<br />
applythedomaintheory,2)generateflatstatemachines,3)mergeflatstate<br />
machines,<strong>and</strong>4)introducehierarchyintothemergedstatemachine.<br />
WeformalisedourmappingfromscenariostostatemachinesasfourATL<br />
modeltransformationsthatcorrespondtothefoursteps<strong>of</strong>ourmapping.<br />
Everyconsecutivetransformationusesthetargetmodel<strong>of</strong>theprevious<br />
transformationasitssourcemodel.<br />
Together,thesetransformationsarespecifiedinlessthan700lines<strong>of</strong><br />
ATLcode. BeforethesetransformationscanbeappliedtotheOcécase,a<br />
normalisationstepisrequired,whichisdiscussedinSection5.6.1.<br />
ApplyDomainTheory Thisstepisspecifictoourapproach. UnlikeWhittle<br />
<strong>and</strong>Schumann[2000], butinaccordancewith UML, wedistinguishbetweenpre-<strong>and</strong>postconditionsontheOperations<strong>of</strong>aClass<strong>and</strong>thoseon<br />
theCallActionsassociatedwithMessagesinasequencediagram.Thishas<br />
twoadvantages. First,itallowsforsimplepre-<strong>and</strong>postconditionstobe<br />
specifiedonlyonce(i.e.,onaClass’Operations).Second,itcircumventsthe
Change language