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.7. Discussion 99<br />
rivedpre-<strong>and</strong>postconditionsfromdecorationsinthesequencediagrams.<br />
Ingeneral,pre-<strong>and</strong>postconditionsarenotalwaysobviousfromdesigndocumentation.<br />
Insuchsituationsthesemighthavetobederivedindirectly<br />
fromdocumentationorreverseengineeredfromsourcecode.<br />
Theintroduction<strong>of</strong>pre-<strong>and</strong>postconditionseffectivelyisanormalisationtotheUMLst<strong>and</strong>ardusedbyOcé<strong>and</strong>ourtools(version1.4[OMG,<br />
2007a]).ForthecurrentUML(version2.1.1)thisisnotnecessary,assuch<br />
lifeline decorations became part <strong>of</strong> the specification (the corresponding<br />
metamodel element is called StateInvariant [OMG, 2007b, page 500]).<br />
Tosupportthis,onlyminormodificationstoourATLtransformationsare<br />
required.<br />
Scalability<strong>of</strong>theapproach Ourapproachconstitutesafirststeptowardsfully<br />
automatedconsistencychecking.<br />
IntheOcécasestudy,thesourcemodelforthetransformationstep<strong>of</strong><br />
ourapproachincludes10sequencediagramsthatcontain62messages.The<br />
resultingintegrated,hierarchicalstatemachine,<strong>of</strong>whichafragmentwas<br />
depictedinFigure5.8onpage97,contains23transitionsbetween14compositestatescontainingintotal47simplestates.<br />
Ourapproachisafirststept<strong>of</strong>ullyautomatedconsistencychecking<br />
<strong>of</strong>behaviouralspecifications. Fornow,werelyonmanualinspection<strong>of</strong><br />
theresultingstatemachineforactualevaluation<strong>of</strong>theconsistency. As<br />
such,thescalabilityiscurrentlynotlimitedbythetransformationsteps(in<br />
theOcécasetheyeachtakelessthan10seconds),butbythecomparison<br />
step. Forcaseswerethenumber<strong>of</strong>statesislimited<strong>and</strong>developershave<br />
knowledgeonthesystem,thisisafeasibleapproach.ForESM,whichisa<br />
medium-sizedcomponent(approximately10KLOC),thisturnedoutnotto<br />
beaproblem.<br />
Fullyautomaticconsistencycheckingcouldbedonebyrelyingonnaming.Anexample<strong>of</strong>suchanapproachisdiscussedbyVanDijketal.[2005].<br />
ItcheckstheconsistencybetweentheunderlyingXMIrepresentations<strong>of</strong><br />
UMLmodels.However,inthiscase,thenames<strong>of</strong>messagesinthescenarios<br />
didnotpreciselycorrespondtothenames<strong>of</strong>transitioneffects<strong>and</strong>events<br />
intheimplementationstatemachine.Althoughtheyareeasilymatchedby<br />
ahuman,thishampersfullautomation.<br />
Theuse<strong>of</strong>graphmatchingtechniquesisanotherpossibility<strong>of</strong>checkingtheconsistency<strong>of</strong>twostatemachines.Alsousingsuchtechniquesthe<br />
problem<strong>of</strong>matchingnode<strong>and</strong>edgelabelsremains.<br />
Als<strong>of</strong>orautomaticapproaches,however,thegeneration<strong>of</strong>astatemachinefromaset<strong>of</strong>scenarios,asdiscussedinthischapter,islikelytobea<br />
firststep.
Change language