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.1. Introduction 79<br />
atethecomponent.Finally,ontheright-h<strong>and</strong>side<strong>of</strong>the‘V’,thedifferent<br />
componentsareintegratedintoacompleteproduct.<br />
Suchas<strong>of</strong>twaredevelopmentprocess,wherestate-basedcomponentdesignisbasedonthespecification<strong>of</strong>aset<strong>of</strong>usecases,isadvocatedbymanycomponent-based,object-oriented,<strong>and</strong>real-times<strong>of</strong>twaredevelopmentmethods[D’Souza<strong>and</strong>Wills,1998;Kruchten,1998;Jacobsonetal.,<br />
1999;Selicetal.,1994].Assuch,manys<strong>of</strong>twaredevelopmentorganisations<br />
deploysimilardevelopmentprocesses.<br />
Ass<strong>of</strong>twareevolvesitis<strong>of</strong>tenthecasethatchangesaremadeto‘downstream’s<strong>of</strong>twaredevelopmentartefacts(suchasdesigns)withoutpropagatingthechangestothecorresponding‘upstream’s<strong>of</strong>twaredevelopment<br />
artefacts(suchasrequirements).Thiscanbetheresult<strong>of</strong>changerequests,<br />
butalso<strong>of</strong>designflawsthatareonlydiscoveredonamoredetailedlevel.<br />
Otherinconsistenciesaresimplyintroducedbymisinterpretations<strong>of</strong>‘upstream’developmentartefacts.<br />
Inthischapterwefocusoninconsistenciesbetweeninteraction-based<br />
behaviouralmodels<strong>and</strong>state-basedbehaviouralmodels. Inconsistencies<br />
betweenthesemodelscanbeparticularlyimportantbecausetheydecomposebehaviouralongdifferentdimensions.<br />
Interaction-basedmodelsare<br />
decomposedaccordingtothedifferentusecases,thatis,theyarerequirements-driven.<br />
State-basedmodels, ontheotherh<strong>and</strong>, aredecomposed<br />
accordingtothedifferentcomponentsthatwereidentifiedduringarchitecturedesign,thatis,theyarearchitecture-driven.Thismakesithardto<br />
discoverinconsistencies[Amyot<strong>and</strong>Eberlein,2003;Bontempsetal.,2005].<br />
Furthermore,whendifferentdevelopmentgroupsareresponsibleforthe<br />
development<strong>of</strong>thedifferentarchitecturalcomponents,<strong>and</strong>thesegroups<br />
individuallyresolveinconsistenciesindifferentways,thismayobviously<br />
leadtoproblemsduringintegration<strong>and</strong>maintenance.<br />
Inindustrialpracticebehaviouralmodelsare<strong>of</strong>tenspecifiedusingthe<br />
Unified<strong>Model</strong>ingLanguage 1 (UML). Moreover,toolsareavailablethat,<br />
basedon UML,arecapable<strong>of</strong>generatingsourcecodefromsuchmodels.<br />
Consideringsuchamodel-basedinfrastructure,webelieveitmakessense<br />
toviewconsistencychecking<strong>of</strong>behaviouralspecificationsasamodeltransformationproblem.Inthischapterweinvestigatewhattheadvantages<strong>and</strong>disadvantagesare<strong>of</strong>usingmodeltransformationtechnologytodiscoverinconsistenciesbetweeninteraction-based<strong>and</strong>state-basedbehaviouralmodels.Furthermore,weaimtominimisetheimpact<strong>of</strong>ourapproachonexistingdevelopmentprocesses,forinstance,interms<strong>of</strong>thelanguages<strong>and</strong><br />
toolsused.<br />
InSection5.2weintroducetheindustrialcasethatmotivatedthischapter:<br />
anembeddeds<strong>of</strong>twarecontrolcomponentdevelopedbyOcé,alarge<br />
1 http://www.uml.org(June2007)