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.
7.9. Evaluation 163<br />
morecomplicated.Ontheotherh<strong>and</strong>,thenormalisationsteprequiresless<br />
effortinthatcase.<br />
Inourcase,thetargetmetamodelspecifiesthedomain-specificpart<strong>of</strong><br />
aproduct-line.Webelievethatmodeltransformationsareparticularlyapplicableasamigrationapproachfortherecurringmigration<strong>of</strong>individual<br />
product-linemembers. Ingeneral,amodel-basedmigrationapproachis<br />
beneficialinsituationswhereanumber<strong>of</strong>similarartefactsneedtobemigrated.<br />
Suchasettingprovidessufficientreturnoninvestmentforthe<br />
definition<strong>of</strong>metamodels,normalisationrules,<strong>and</strong>transformationrules.<br />
Morespecifically,whenconsideringthepreviouslymentionedtrade-<strong>of</strong>f,<br />
alargernumber<strong>of</strong>artefactsthatneedtobemigratedjustifiesahigher<br />
investmentinthedefinition<strong>of</strong>transformationrules,allowingforalessinvolvednormalisationstep.<br />
Asanotherexample<strong>of</strong>thistrade-<strong>of</strong>f,consider<br />
ourassumption<strong>of</strong>propernesting. Itimpliesthatalternativebranchesin<br />
astatemachinearejoinedtwoatatime<strong>and</strong>inreverseorder. Onecould<br />
relaxthisassumption(constraint)<strong>and</strong>implementamoreintricatetransformationruletoh<strong>and</strong>lethisrelaxation.<br />
Extensibility Currently,ourtransformationrulesdonoth<strong>and</strong>lesynchronisationacrossdifferentrequests.Thiscouldprovetobealimitationforthe<br />
largescaleapplication<strong>of</strong>ourtransformationrules.Tothisend,wewould<br />
haveto(atleast)extendourpr<strong>of</strong>iletoincludeaspecialtype<strong>of</strong>Eventto<br />
denoteexternaleventsforsuchinter-requestdependencies.<br />
Theoverallextensibility<strong>of</strong>ourmigrationapproachisdemonstratedby<br />
usingsourcemodelswithtwodistinctoriginsforourexperiments. Inthe<br />
case<strong>of</strong>theunloadwaferrequestweusedtheavailablearchitecturedocumentation<strong>of</strong>theinvolvedSMCcomponent.ThisdocumentationcontainedUMLstatechartdiagramsforthecomponent’srequests,includingourexamplerequest.However,fortheSMCcomponentthatperformstheprocesswaferrequest,documentationwasnotavailable.Wehadtoreconstructthesource<br />
modelfromthesourcecode.Forthiswetookadvantage<strong>of</strong>thefactthatthis<br />
componentwasbasedonaproprietarylibraryforFSMs.Usingthislibrary,<br />
thecomponentimplementedthreeconcurrentstatemachinesthatcovered<br />
thebehaviour<strong>of</strong>allrequests<strong>and</strong>combinationshere<strong>of</strong>.Figure7.12onthe<br />
nextpagedepictsone<strong>of</strong>thecomponent’sthreestatemachines.<br />
Thisparticularstatemachineillustratesthetypicalresult<strong>of</strong>anevolvings<strong>of</strong>twarearchitecture:twolegacystate-basedcomponentswereaugmentedwithanewsupervisor.Thissupervisorwasobtainedbytakingtheproduct<strong>of</strong>thetwolegacystate-machines<strong>and</strong>addingtwochoicepseudostates(i.e.,<br />
s1<strong>and</strong> s11)toallowfordifferentactivationpaths,basedon<br />
legacyrequestcombinations.