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.
6.5. Mappings<strong>and</strong><strong>Model</strong>Transformations 115<br />
thecorrespondingobject-orientedsourcecode). TherelationbetweenC&C<br />
views<strong>and</strong>theimplementationcanbemorecomplicated;theseviewsare<br />
anabstraction<strong>of</strong>thesystemsstructureatruntime<strong>and</strong>not<strong>of</strong>theimplementationitself(cf.<br />
therelationbetweencollaboratingobjectsina<br />
UMLcollaborationdiagram<strong>and</strong>thesourcecodethatcausedtheseobjects<br />
tobeinstantiated). Thismakesreconstruction<strong>of</strong>thoseviewsagreater<br />
challenge.<br />
ModuleViews Forthepopulation<strong>of</strong>aMADLmodelwehavetoidentifymodules<strong>and</strong>usesrelations.<br />
Typically,implementation-levelmodularisationconstructsdonotmatch<br />
one-to-onewiththearchitecture-levelmodules. Developerstypicallyhave<br />
reasonst<strong>of</strong>urtherrefinetheprovideddecomposition<strong>of</strong>thedevelopment<br />
viewsduringimplementation.Inourapproachweassumethatthedecompositionisrecorded,forinstance,throughannotations.Asimple,yetsufficient,methodistoaddcommentstotheimplementationwith<br />
@module(...)clauses.TheseclausesassociateaJavaclass(or<br />
otherimplementationunit)withamodule<strong>of</strong>thearchitecturalusesview.<br />
Alternatively,packagescanbeusedtorepresentmodulesinanimplementation.Inthiscase,however,wealreadyusedpackagestorepresentarchitecturallayering.<br />
Nexttomodules,ausesviewdefinesusesrelations[Clementsetal.,<br />
2002a]. Thenotion<strong>of</strong>usehasconflictinginterpretations[Stevens,2001].<br />
Inordertodeterminetheexistenceorpossiblyinexistence<strong>of</strong>aparticular<br />
usesrelation,westartwiththedefinitiongivenbyClementsetal.[2002a]:<br />
“UnitAissaidtouseunitBifA’scorrectnessdependsonacorrectimplementation<strong>of</strong>Bbeingpresent.”<br />
Asourapproachcannotguaranteethata<br />
moduleiscorrectlyimplemented,wetakeapragmaticpositionbymapping<br />
thearchitecturalusesrelationtoacheckabletuple:alinkplusanaction<br />
thateffectuatesthelink.Thelinkisareferencefromaclassthatbelongs<br />
tothe‘using’moduletotheclassthatbelongstothe‘used’module.Theactioncanbeanythingfromafunctioncalltoanattributeaccess.Infact,our<br />
interpretationcapturescalls<strong>and</strong>shares-data-withdependencyrelations,<br />
whicharedifferentspecialisations<strong>of</strong>thedepends-onrelation.<br />
WeusetheliftingoperationdescribedbyFahmy<strong>and</strong>Holt[2000b]to<br />
transformlinks,actions,<strong>and</strong> @moduleannotationstocreateusesrelations<br />
inatargetmodel.<br />
Firstwerecoverclasses<strong>and</strong>theirdependenciesfromtheJavaMLrepresentation<strong>of</strong>theAST.UsingsimpleATLexpressionsweselecttheXMLElementsthatrepresentaclass<strong>and</strong>foreachcreateaClassintheMADLtarget<br />
model. Toinstantiatecorresponding calls<strong>and</strong> fieldAccessdependenciesin<br />
thetargetmodel,weselectalltheirchildElementsrepresentingmethod
Change language