Model-Driven Evolution of Software Architectures - Software and ...
Model-Driven Evolution of Software Architectures - Software and ...
Model-Driven Evolution of Software Architectures - Software and ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
5.4. <strong>Model</strong>-<strong>Driven</strong>ConsistencyChecking 87<br />
someinvariants(overstatevariables)hold. Themetamodeldefinesthe<br />
followingtypes<strong>of</strong> States.A CompositeStatecontains(owns)anumber<strong>of</strong>substates(subvertex).A<br />
SimpleStateisaStatewithoutanysub-states.<br />
Nexttostatenodesthatdescribeadistinctsituation,themetamodel<br />
also<strong>of</strong>fersatype<strong>of</strong> StateVertextomodelstransientnodes: Pseudostate.Only<br />
one Pseudostatetype(PseudostateKind)isrelevantforthestatemodelsinthis<br />
chapter:theinitial Pseudostate.Aninitial Pseudostateisthedefaultnode<strong>of</strong><br />
a CompositeState. Ithasonlyone outgoing Transitionleadingtothedefault<br />
State<strong>of</strong>aCompositeState.<br />
Nodesinastatemachineareconnectedby Transitionsthatmodelthe<br />
transitionfromone State(source)toanother(target).A Transitionisfiredby<br />
a CallEvent(trigger). The effect<strong>of</strong>aTransitionspecifiesan CallActiontobeexecuteduponitsfiring.<br />
Finally,aStateMachineisdefinedinthe context<strong>of</strong>a<br />
Class<strong>and</strong>consists<strong>of</strong>aset<strong>of</strong> Transitions<strong>and</strong>one top StatethatisaComposite-<br />
State(intheUMLspecificationthisisspecifiedasanOCLwell-formedness<br />
rule,whichwedonotshow).<br />
5.4.3 ConsistencyCheckingApproach<br />
Assaid,theset<strong>of</strong>scenariosisnotexpectedtobecompleteorprecise.For<br />
instance,whencomparingtheset<strong>of</strong>scenarios<strong>and</strong>thestatemachinescreatedbythedevelopersitisunclearwhetherascenariospecifiesuniversal<br />
orexistentialbehaviour[Damm<strong>and</strong>Harel,2001]. However,ifweareto<br />
generateastatemachineforaset<strong>of</strong>scenarioswehavetotakeaposition<br />
withrespecttothemeaning<strong>of</strong>thosescenarios.Thegeneration<strong>of</strong>scenarios<br />
isbasedontheapproachbyWhittle<strong>and</strong>Schumann[2000]. Tothisend,<br />
weinterpretOcé’sscenariosinprincipleasuniversal: ifthestartcondition<strong>of</strong>ascenarioissatisfiedthesystembehavesexactlyasspecifiedby<br />
thatscenario. Weconsiderthestartcondition<strong>of</strong>ascenariotobethefirst<br />
conditionspecifiedasdecoration<strong>and</strong>occurrence<strong>of</strong>thefirstmessage. As<br />
such,thescenarioinFigure5.7(a)onpage96specifiesexactlywhathappenswhen<br />
ESM receivesthemessage m_SetUnit(st<strong>and</strong>by)whileitisinstate<br />
running. However,whenduringexecution<strong>of</strong>ascenariothestartcondition<br />
<strong>of</strong>anotherscenarioissatisfied,executioncontinuesaccordingtothatscenario.<br />
Forinstance,inthecase<strong>of</strong>Figure5.7(a)onpage96,while ESM is<br />
stopping,executioncouldcontinueaccordingtothescenariothatperforms<br />
therequest<strong>of</strong>ESMgoingbacktorunningwhileitwasstopping.<br />
Inourapproachweusemodeltransformationsforthegeneration<strong>of</strong>a<br />
statemachinefromaset<strong>of</strong>scenarios. Thespecification<strong>of</strong>thosetransformationsisdiscussedinSection5.5.<br />
Toincludeallrequiredinformation,<br />
thesourcemodelhastocomplytoaset<strong>of</strong>modellingconventions. When<br />
consideringanarbitraryindustrialcase(e.g.,Océ’sreferencearchitecture),<br />
themodelsusedtypicallydonotcomplytothoseconventions. Therefore,
Change language