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.
<strong>Model</strong>-<strong>Driven</strong><strong>Evolution</strong><br />
<strong>of</strong>S<strong>of</strong>tware<strong>Architectures</strong>
<strong>Model</strong>-<strong>Driven</strong><strong>Evolution</strong><strong>of</strong>S<strong>of</strong>tware<strong>Architectures</strong><br />
Proefschrift<br />
terverkrijgingv<strong>and</strong>egraadv<strong>and</strong>octor<br />
a<strong>and</strong>eTechnischeUniversiteitDelft,<br />
opgezagv<strong>and</strong>eRectorMagnificuspr<strong>of</strong>.dr.ir.J.T.Fokkema,<br />
voorzittervanhetCollegevoorPromoties,<br />
inhetopenbaarteverdedigenopdinsdag27november2007om12:30uur<br />
door<br />
BastiaanStephanGRAAF<br />
informaticaingenieur<br />
geborenteDenHaag
Ditproefschriftisgoedgekeurddoordepromotor:<br />
Pr<strong>of</strong>.dr.A.vanDeursen<br />
Samenstellingpromotiecommissie:<br />
RectorMagnificus,voorzitter<br />
Pr<strong>of</strong>.dr.A.vanDeursen,TechnischeUniversiteitDelft,promotor<br />
Pr<strong>of</strong>.dr.ir.H.J.Sips,TechnischeUniversiteitDelft<br />
Pr<strong>of</strong>.dr.ir.A.Verbraeck,TechnischeUniversiteitDelft<br />
Pr<strong>of</strong>.dr.M.G.J.v<strong>and</strong>enBr<strong>and</strong>,TechnischeUniversiteitEindhoven<br />
Pr<strong>of</strong>.Dr.rer.nat.R.Koschke,UniversitätBremen<br />
Dr.L.Somers,OcéenTechnischeUniversiteitEindhoven<br />
Theworkinthisthesishasbeencarriedoutundertheauspices<strong>of</strong>theresearchschoolIPA(InstituteforProgrammingresearch<strong>and</strong>Algorithmics).<br />
Theresearchdescribedinthisthesiswasmadepossiblethroughsuppport<br />
<strong>of</strong>SenterNovem(Mooseproject)<strong>and</strong>NWO(Reconstructorproject).<br />
IPADissertationSeries2007-16<br />
Copyright c○2007byBasGraaf<br />
Aboutthecover:Thecovershowsafragment<strong>of</strong>JohannesVermeer:<br />
‘ViewonDelft’,Mauritshuis,TheHague(ca.1661-1664.Oiloncanvas)<br />
<strong>and</strong>apicturetakenfromthesameviewpointbyRenév<strong>and</strong>erKrogtin<br />
May2006.<br />
PrintedbyUniversalPress,Veenendaal<br />
ISBN:978-90-9022390-2
Preface<br />
Atlast!TimehascometowritetheprefacetomyPhD-thesis.Duringthe<br />
almostfive<strong>and</strong>ahalfyearsittookmetoarriveatthispoint,Istartedto<br />
comparetheprocess<strong>of</strong>doingaPhDwiththerunningexercisesIdoinbetweentw<strong>of</strong>ootballseasons.Ialwaysstartveryenthusiastic<strong>and</strong>motivated;<br />
halfwayIdoubtthatIwillevermakeit<strong>and</strong>almostregrettohavestarted;<br />
neartheendItryhardtoputinallremainingenergytomakeittothe<br />
finish;<strong>and</strong>afterwardsIfeelgood,happy,<strong>and</strong>proudaboutwhatI’vedone.<br />
LikeIfeelnow.OnebigdifferenceisthatduringmyPhD-careerIencounteredmanypeoplethathelpedmeorthatmadethewholeexercisemore<br />
pleasant.Thosepeopledeservetobeacknowledged.Well,hereitgoes.<br />
Ifcrossingthefinishlinehastobeattributedtooneperson,thanthat<br />
personhasgottobeArievanDeursen.Arie,Iamverygratefultoyoufor<br />
‘adopting’measaPhD-student.Formethebestremedytoovercomeseeminglydeadendsinmyresearchorwhenwritingarticleswasaconversation<br />
withyou.Youhavebeenatrulyinspiringteacher!Forthis<strong>and</strong>manyother<br />
reasonsitwasapleasuretoworkwithyou.<br />
IwanttothankHansToetenel<strong>and</strong>JanDietzfortalkingmeintothis<br />
excerciseinthefirstplace.IamalsogratefulforHans’supervisionduring<br />
thefirstphase<strong>of</strong>myworkasaPhD-student.<br />
Ofcoursesomebodyhastoreadtheresult<strong>of</strong>allthatwork.Forthis,my<br />
gratitudegoestothemembers<strong>of</strong>theexaminationcommittee: Pr<strong>of</strong>. H.J.<br />
Sips,Pr<strong>of</strong>.A.Verbraeck,Pr<strong>of</strong>.M.G.J.v<strong>and</strong>enBr<strong>and</strong>,Pr<strong>of</strong>.R.Koscke,<strong>and</strong><br />
Dr.L.Somers.<br />
I’vehadtheopportunitytoworkinseveralresearchprojects: Moose,<br />
Merlin,Ideals<strong>and</strong>Reconstructor. DuringalltheseprojectsIworkedtogetherwithinteresting<strong>and</strong>inspiringpeople.Thankyouallforthat!More<br />
inparticular,IwanttothankRinivanSolingenforallkinds<strong>of</strong>general<br />
adviceonhowtosucceedasaPhD-student.AlsoIwanttospeciallythank<br />
SvenWeberasaco-author<strong>of</strong>one<strong>of</strong>thepublicationsonwhichthisthesisis<br />
based.<br />
v
vi Preface<br />
Furthermore,Iwanttomentionall(former)colleagues<strong>of</strong>thes<strong>of</strong>tware<br />
engineeringdepartmentforallthenicelunches,drinks,<strong>and</strong>diners. In<br />
particularIamgratefultoHylkevanDijk<strong>and</strong>MarcoLormans.Hylkeasa<br />
co-author<strong>of</strong>twoarticlesonwhichthisthesisisbased,<strong>and</strong>foraskingthose<br />
nastyquestionsallthetime.WithMarcoIworkedtogetheralreadysince<br />
thebeginning<strong>of</strong>ourmaster-thesisprojectsevenyearsago,allthattime<br />
asroommates.Mostworkingtripshavebeenquitememorablebecause<strong>of</strong><br />
him.Thanks!<br />
Finally,IwanttothankDaanforbeingpatientenoughtocopewithme<br />
beingalmostfinishedforasuchalongtime<strong>and</strong>,puttingonholdallother<br />
plans;forbeingimpatientenoughtoapplytherightamount<strong>of</strong>pressure;<br />
<strong>and</strong>forbeingmygirl-friendalltheway.<br />
BasGraaf<br />
Delft,August2007
Contents<br />
Preface v<br />
List<strong>of</strong>Figures x<br />
Abbreviations xiii<br />
1 Introduction 1<br />
1.1 ProblemDescription:<strong>Evolution</strong><strong>of</strong>S<strong>of</strong>tware<strong>Architectures</strong> . 4<br />
1.2 Objectives . ............................ 7<br />
1.2.1 IntegrationinPractice . ................. 7<br />
1.2.2 ProductLines . ...................... 7<br />
1.2.3 <strong>Model</strong>-<strong>Driven</strong>Engineering. ............... 8<br />
1.3 Approach .............................. 9<br />
1.4 Overview .............................. 10<br />
1.5 Origin<strong>of</strong>Chapters ........................ 13<br />
2 Background 17<br />
2.1 S<strong>of</strong>tware<strong>Evolution</strong> ........................ 17<br />
2.2 Architecture-<strong>Driven</strong>S<strong>of</strong>twareDevelopment.......... 20<br />
2.2.1 S<strong>of</strong>twareArchitecture . ................. 20<br />
2.2.2 S<strong>of</strong>twareArchitectureUsage .............. 22<br />
2.2.3 S<strong>of</strong>twareArchitectureDesign .............. 23<br />
2.2.4 S<strong>of</strong>twareArchitectureDescription . .......... 24<br />
2.2.5 S<strong>of</strong>twareArchitectureEvaluation . .......... 25<br />
2.2.6 S<strong>of</strong>twareProductLines. ................. 26<br />
2.3 <strong>Model</strong>-<strong>Driven</strong>Engineering.................... 27<br />
2.3.1 <strong>Model</strong>ling.......................... 28<br />
2.3.2 Metamodelling. ...................... 29<br />
2.3.3 <strong>Model</strong>Transformations. ................. 32<br />
2.3.4 MDE<strong>and</strong>OtherTechnologicalSpaces.......... 37<br />
vii
viii Contents<br />
2.4 <strong>Model</strong>-<strong>Driven</strong><strong>Evolution</strong><strong>of</strong>S<strong>of</strong>tware<strong>Architectures</strong> . ..... 38<br />
3 Embedded-S<strong>of</strong>twareEngineering:TheState<strong>of</strong>thePractice 41<br />
3.1 Introduction ............................ 41<br />
3.2 Methods<strong>and</strong>Scope ........................ 42<br />
3.3 Embedded-S<strong>of</strong>twareDevelopmentContext .......... 45<br />
3.4 RequirementsEngineeringResults............... 47<br />
3.4.1 RequirementsSpecification ............... 48<br />
3.4.2 RequirementsManagement ............... 49<br />
3.5 S<strong>of</strong>twareArchitectureResults. ................. 50<br />
3.5.1 S<strong>of</strong>twareArchitectureDesign .............. 50<br />
3.5.2 S<strong>of</strong>twareArchitectureDescription . .......... 51<br />
3.5.3 S<strong>of</strong>twareArchitectureEvaluation . .......... 52<br />
3.5.4 Reuse ............................ 53<br />
3.6 Discussion . ............................ 54<br />
3.7 Outlook ............................... 55<br />
4 EvaluatinganEmbeddedS<strong>of</strong>twareReferenceArchitecture<br />
–IndustrialExperienceReport– 57<br />
4.1 Introduction ............................ 57<br />
4.2 Overview<strong>of</strong>theReferenceArchitecture ............ 59<br />
4.2.1 BusinessDrivers ..................... 59<br />
4.2.2 ReferenceArchitecture . ................. 60<br />
4.2.3 Structure.......................... 61<br />
4.2.4 Usage............................ 61<br />
4.3 EvaluationApproach . ...................... 63<br />
4.3.1 Selection<strong>of</strong>EvaluationMethod . ............ 63<br />
4.3.2 TailoringSAAM. ...................... 65<br />
4.4 ConductingtheEvaluation. ................... 67<br />
4.4.1 Preparation ........................ 67<br />
4.4.2 Scenarios.......................... 67<br />
4.4.3 Execution.......................... 68<br />
4.4.4 OverallEvaluation . ................... 70<br />
4.5 Discussion . ............................ 71<br />
4.5.1 ReferenceArchitecture . ................. 71<br />
4.5.2 DistributedSAAM ..................... 73<br />
4.6 RelatedWork............................ 75<br />
4.7 Conclusion . ............................ 76<br />
5 <strong>Model</strong>-<strong>Driven</strong>ConsistencyChecking<strong>of</strong>Behavioural<br />
Specifications 77<br />
5.1 Introduction ............................ 77<br />
5.2 RunningExample . ........................ 80
Contents ix<br />
5.3 RelatedWork............................ 82<br />
5.4 <strong>Model</strong>-<strong>Driven</strong>ConsistencyChecking .............. 83<br />
5.4.1 EnablingTechnologies . ................. 83<br />
5.4.2 Behavioural<strong>Model</strong>ling . ................. 85<br />
5.4.3 ConsistencyCheckingApproach ............ 87<br />
5.5 GeneratingStateMachines ................... 88<br />
5.5.1 InstantiatingaSource<strong>Model</strong> .............. 88<br />
5.5.2 <strong>Model</strong>Transformations. ................. 89<br />
5.6 ApplicationtoOcé. ........................ 94<br />
5.6.1 Source<strong>Model</strong>Normalisation............... 94<br />
5.6.2 Results . .......................... 95<br />
5.7 Discussion . ............................ 98<br />
5.8 Conclusions ............................ 101<br />
6 <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<strong>of</strong>Structural<br />
Specifications 103<br />
6.1 Introduction ............................ 103<br />
6.2 RunningExample . ........................ 105<br />
6.3 Approach .............................. 108<br />
6.3.1 ConformanceCheckingSystem . ............ 108<br />
6.3.2 <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking . ........ 109<br />
6.4 Viewpoints<strong>and</strong>Metamodels................... 110<br />
6.4.1 Component-<strong>and</strong>-ConnectorViews............ 111<br />
6.4.2 ModuleViews . ...................... 112<br />
6.5 Mappings<strong>and</strong><strong>Model</strong>Transformations . ............ 114<br />
6.5.1 <strong>Model</strong>Population ..................... 114<br />
6.5.2 <strong>Model</strong>Comparison . ................... 118<br />
6.5.3 <strong>Model</strong>Presentation . ................... 121<br />
6.6 Discussion . ............................ 121<br />
6.6.1 <strong>Model</strong>ware . ........................ 121<br />
6.6.2 ImprovingtheApproach ................. 123<br />
6.7 Relatedwork............................ 125<br />
6.8 Conclusions ............................ 126<br />
7 <strong>Model</strong>-drivenMigration<strong>of</strong>SupervisoryMachineControl<br />
<strong>Architectures</strong> 129<br />
7.1 Introduction ............................ 129<br />
7.2 RelatedWork............................ 132<br />
7.3 MigrationContext. ........................ 133<br />
7.3.1 SupervisoryMachineControl .............. 133<br />
7.3.2 RunningExample:AWaferScanner .......... 134<br />
7.3.3 ConcernsforSupervisoryMachineControlSystems . 135<br />
7.4 <strong>Model</strong>-<strong>Driven</strong>Migration ..................... 136
x Contents<br />
7.5 SourceMetamodel. ........................ 138<br />
7.6 NormalisationRules . ...................... 143<br />
7.7 TargetMetamodel. ........................ 147<br />
7.8 Transformation .......................... 151<br />
7.8.1 TheAtlasTransformationLanguage.......... 152<br />
7.8.2 BasicTarget<strong>Model</strong>Elements .............. 153<br />
7.8.3 Concern-BasedTransformationRules . ........ 156<br />
7.8.4 TransformationResults ................. 159<br />
7.9 Evaluation . ............................ 161<br />
7.10Conclusions<strong>and</strong>FutureWork . ................. 165<br />
8 Visualisation<strong>of</strong>Domain-Specific<strong>Model</strong>lingLanguages<br />
UsingUML 167<br />
8.1 Introduction ............................ 167<br />
8.2 Background ............................ 169<br />
8.2.1 S<strong>of</strong>twareArchitecture . ................. 169<br />
8.2.2 EnablingMDETechnologies ............... 171<br />
8.3 <strong>Model</strong>-<strong>Driven</strong>ArchitecturalViews ............... 172<br />
8.3.1 MDAVFramework . ................... 172<br />
8.3.2 MDAVProcess. ...................... 173<br />
8.4 UsingMDAVtoGenerateViews................. 174<br />
8.4.1 Module-UsesView . ................... 174<br />
8.4.2 Component-<strong>and</strong>-ConnectorView ............ 177<br />
8.5 IndustrialApplication ...................... 181<br />
8.6 Discussion . ............................ 185<br />
8.7 RelatedWork............................ 186<br />
8.8 ConcludingRemarks . ...................... 187<br />
9 Conclusion 189<br />
9.1 Contributions . .......................... 190<br />
9.2 IntegrationinPractice(RQ1) . ................. 190<br />
9.3 S<strong>of</strong>twareProductLines(RQ2).................. 193<br />
9.4 <strong>Model</strong>-<strong>Driven</strong>Engineering(RQ3) . ............... 194<br />
9.5 Supportfor<strong>Evolution</strong><strong>of</strong>S<strong>of</strong>tware<strong>Architectures</strong>(RQ0) ... 199<br />
9.6 FutureWork<strong>and</strong>Recommendations .............. 201<br />
References 205<br />
Summary 221<br />
Samenvatting 225<br />
CurriculumVitae 229
List <strong>of</strong> Figures<br />
1.1 ASMLwaferscanner . ...................... 2<br />
1.2 S<strong>of</strong>twareevolutiontasks ..................... 5<br />
1.3 Océcopier . ............................ 12<br />
2.1 Complexityvs.sizeforsubsequentrevisions<strong>of</strong>copiers<strong>of</strong>tware 18<br />
2.2 Fundamentalrelationsbetweensystem, model, <strong>and</strong>metamodel<br />
. ............................... 28<br />
2.3 LayeredMDEmodellingstack . ................. 30<br />
2.4 Metamodel<strong>and</strong>conformingmodel ............... 31<br />
2.5 ConformstorelationinMDE ................... 31<br />
2.6 <strong>Model</strong>transformationmegamodel. ............... 33<br />
2.7 Ametamodelforsimpleclassmodels.............. 34<br />
2.8 Three-dimensionalevolutionframework............ 38<br />
3.1 The decomposition <strong>of</strong> the embedded-systems-development<br />
process ............................... 46<br />
3.2 Embedded-systems-developmentstakeholders<strong>and</strong>otherfactors<br />
................................. 47<br />
4.1 Mainflowsinacopier. ...................... 59<br />
4.2 Thereferencearchitecture<strong>and</strong>derivedprojects. ....... 62<br />
4.3 SAAMsteps . ............................ 64<br />
4.4 SAAMresults ............................ 69<br />
5.1 Typicaldevelopmentprocess................... 78<br />
5.2 Architectureforcopierengines ................. 81<br />
5.3 Constraints. ............................ 85<br />
5.4 Collaborations(simplified) . ................... 86<br />
5.5 Statemachines .......................... 86<br />
5.6 Flatstatemachine ........................ 92<br />
xi
xii List<strong>of</strong>Figures<br />
5.7 Examplescenario: requestacopierenginetogotost<strong>and</strong>by<br />
whileitisrunning. ........................ 96<br />
5.8 Mergedstatemodel<strong>of</strong>ESM(fragment) . ............ 97<br />
6.1 Aligningarchitecture<strong>and</strong>implementation. .......... 104<br />
6.2 Digitalmusicboxreadersystem . ............... 106<br />
6.3 Architecturalviews ........................ 107<br />
6.4 ConceptualConformanceCheckingSystem .......... 109<br />
6.5 Genericmetamodelelement ................... 111<br />
6.6 Metamodels ............................ 113<br />
6.7 ReconstructedMADLmodels................... 117<br />
6.8 ReconstructedCPADLmodels . ................. 119<br />
6.9 MergedMADLconformancemodel. ............... 119<br />
6.10MergedCPADLconformancemodel ............... 120<br />
7.1 Machinecontrolcontext ..................... 133<br />
7.2 Simplifiedlayout<strong>of</strong>awaferscanner .............. 134<br />
7.3 Generictwo-phasedmigrationapproach............ 137<br />
7.4 Sourcemetamodel. ........................ 139<br />
7.5 Processwaferrequest. ...................... 141<br />
7.6 Unloadwaferrequest....................... 142<br />
7.7 Normalisedprocesswaferrequest. ............... 148<br />
7.8 Normalisedunloadwaferrequest................ 149<br />
7.9 Moduleviewfortheproduct-lineSMCarchitecture ..... 150<br />
7.10Targetmetamodel......................... 151<br />
7.11Resultsforunloadwaferrequest . ............... 160<br />
7.12One<strong>of</strong>threeconcurrentstatemodels(madeanonymous) . . 164<br />
8.1 MDAVframework . ........................ 172<br />
8.2 C&Cmodel<strong>of</strong>CaPiTaLiZe(ACME). ............... 174<br />
8.3 MADL . ............................... 175<br />
8.4 CCADL. ............................... 178<br />
8.5 XMLmetamodel .......................... 180<br />
8.6 Task-resourcemetamodel,model,<strong>and</strong>UMLrepresentation . 184<br />
9.1 Megamodelformodel-drivenevolution<strong>of</strong>s<strong>of</strong>twarearchitectures.................................<br />
195
Abbreviations<br />
ADL architecturedescriptionlanguage<br />
ALMA architecture-levelmodifiabilityanalysis[Bengtssonetal.,2004]<br />
API applicationprogramminginterface<br />
AST abstractsyntaxtree<br />
ATAM ArchitectureTrade<strong>of</strong>fAnalysisMethod[Clementsetal.,2002b]<br />
ATL AtlasTransformationLanguage[Jouault<strong>and</strong>Kurtev,2005]<br />
COTS commercial<strong>of</strong>f-the-shelf<br />
CMM CapabilityMaturity<strong>Model</strong>[Humphrey,1989]<br />
DSAAM DistributedSAAM<br />
DSL domain-specificlanguage<br />
DSML domain-specificmodellinglanguage<br />
DTD DocumentTypeDefinition<br />
EBNF ExtendedBackus-Naurform<br />
EMF Eclipse<strong>Model</strong>ingFramework 1<br />
FSM finitestatemachine<br />
GMF GraphicalEditingFramework 2<br />
GPL general-purposelanguage<br />
ITEA InformationTechnologyforEuropeanAdvancement 3<br />
1 http://www.eclipse.org/emf(June2007)<br />
2 http://www.eclipse.org/gmf(June2007)<br />
3 http://www.itea-<strong>of</strong>fice.org(June2007)<br />
xiii
xiv ABBREVIATIONS<br />
MDA <strong>Model</strong><strong>Driven</strong>Architecture 1<br />
MDE model-drivenengineering<br />
MDR MetadataRepository 2<br />
MOF MetaObjectFacility 3<br />
MOOSE S<strong>of</strong>twareEngineeringMethOdOlogieSforEmbeddedSystems 4<br />
OCL ObjectConstraintLanguage 5<br />
OMG ObjectManagementGroup 6<br />
QVT Query/View/Transformation[OMG,2005]<br />
SAAM S<strong>of</strong>twareArchitectureAnalysisMethod[Kazmanetal.,1996]<br />
SEI S<strong>of</strong>twareEngineeringInstitute 7<br />
SMC supervisorymachinecontrol<br />
SPICE S<strong>of</strong>twareProcessImprovement<strong>and</strong>CapabilitydEtermination[Emametal.,1997]<br />
SVG ScalableVectorGraphics 8<br />
UML Unified<strong>Model</strong>ingLanguage 9<br />
XMI XMLMetadataInterchange 10<br />
XML ExtensibleMarkupLanguage 11<br />
XSLT ExtensibleStylesheetLanguageTransformations 12<br />
1http://www.omg.org/mda(June2007) 2http://mdr.netbeans.org(June2007) 3http://www.omg.org/m<strong>of</strong>(June2007) 4http://www.mooseproject.org(June2007) 5http://www.omg.org/technology/documents/modeling_spec_catalog.htm#OCL(June2007) 6http://www.omg.org(June2007) 7http://www.sei.cmu.edu(June2007) 8http://www.w3.org/Graphics/SVG(June2007) 9http://www.uml.org(June2007) 10http://www.omg.org/mda/specs.htm#XMI(June2007) 11http://www.w3.org/XML(June2007) 12http://www.w3.org/TR/xslt(June2007)
Chapter1<br />
Introduction 1<br />
Mosts<strong>of</strong>twarethatisreallyusedisexposedtomanyforcesthatrequire<br />
ittochange,suchaschanginguserrequirementsorachangingoperating<br />
environment. Asaresults<strong>of</strong>twarechangescontinuously. Thisprocessis<br />
calleds<strong>of</strong>twareevolution[Lehman<strong>and</strong>Belady,1985].<br />
When changes are required to a s<strong>of</strong>tware system, the question is<br />
whethertheycanbeimplementedwithintheboundssetbythecurrent<br />
architectureorrequirearedesign<strong>of</strong>thearchitecture.<br />
Theformercausestypes<strong>of</strong>s<strong>of</strong>twareevolutionreferredtoasarchitecturaldrift<strong>and</strong>erosion[Perry<strong>and</strong>Wolf,1992].<br />
Architecturaldriftoccurs<br />
whenthecurrentarchitectureisnotwell-understoodbythedevelopersinvolvedinmakingthesesmall-scalechanges.Asaresulttheirchangesarebasedonas<strong>of</strong>twarearchitecturethatisdifferentfromtheintendedarchitecture.<br />
Architecturalerosioniscausedbyviolations<strong>of</strong>thearchitecture.<br />
Bothhaveanegativeeffectonthemaintainability<strong>of</strong>s<strong>of</strong>tware.<br />
Eventuallyarchitecturaldrift<strong>and</strong>erosionmakearedesign<strong>of</strong>thearchitectureunavoidable.Inthisthesisweconsiderthistype<strong>of</strong>s<strong>of</strong>twareevolution,thatis,onthelevel<strong>of</strong>architecture.Althoughwediscusstheconcepts<strong>of</strong>s<strong>of</strong>twarearchitectureextensivelyinChapter2,fornowitsufficestodescribearchitectureasthehigh-levelorglobaldesign<strong>of</strong>as<strong>of</strong>twaresystem.Toillustratetheneedfor<strong>and</strong>implications<strong>of</strong>architecturalchanges,considerthefollowingsituationatASML,acompanythatdevelopsmanufacturingmachinesforthesemiconductorindustry.<br />
Anewarchitecturefor<br />
thecontrols<strong>of</strong>tware<strong>of</strong>one<strong>of</strong>ASML’sproducts,aso-calledwaferscanner<br />
(seeFigure1.1onthefollowingpage),isinvestigated[V<strong>and</strong>enNieuwelaar<br />
etal.,2003].Thisarchitectureisbasedongenericreusables<strong>of</strong>twarecomponents<strong>and</strong>enablesthe(automatic)generation<strong>of</strong>application-specificparts<br />
1 Thischapterisbasedon:Graaf,Bas. <strong>Model</strong>-drivenevolution<strong>of</strong>s<strong>of</strong>twarearchitectures.<br />
InProceedings<strong>of</strong>the11 th EuropeanConferenceonS<strong>of</strong>twareMaintenance<strong>and</strong>Reengineering(CSMR2007),pages357–360.IEEEComputerSociety,2007<br />
1
2 Chapter1. Introduction<br />
Figure 1.1:ASMLwaferscanner<br />
<strong>of</strong>controlcomponentsfromadeclarativespecification.Asaresult,therequiredeffortfordevelopment<strong>and</strong>maintenance<strong>of</strong>thecontrols<strong>of</strong>twarecan<br />
bereduced.<br />
Aproblemthatremainsisthemigration<strong>of</strong>existingcontrolcomponents<br />
tothisnewarchitecture. Apossibleapproachistostart-over<strong>and</strong>develop<br />
thesecomponentsfromscratchaccordingtothenewarchitecture. Inthis<br />
casethismeansthatforeachcontrolcomponentanewspecificationhas<br />
tobecreated. Unfortunately,theknowledgeincorporatedinthecode<strong>and</strong><br />
designs<strong>of</strong>alreadyexistingcontrolcomponentswillbelargelylostthisway.<br />
Consideringthefactthatthecurrentbehaviour<strong>of</strong>thesecomponentsdoes<br />
notneedtobechanged, thisconstitutesawaste<strong>of</strong>knowledge<strong>and</strong>resources,<strong>and</strong>anunnecessaryrisk.Analternativesolutionistoderivethespecifications<strong>of</strong>thesecomponentsforthenewarchitecturefromtheirexistingspecifications.<br />
Thescenariosketchedabove,whichisfullyexploredinChapter7,is<br />
aboutachangingorevolvings<strong>of</strong>twarearchitecture<strong>and</strong>illustratessome<br />
<strong>of</strong>theissuesweaddressinthisthesis. Manycompaniesareconfronted<br />
withsimilarscenarios.Anexampleinacompletelydifferentdomainisthe<br />
problem<strong>of</strong>makingexistinginformationsystemsaccessibleviatheWorld<br />
WideWeb.Thistypicallyalsorequiresarchitecturalchanges.Manyother<br />
scenarioscanbementionedthatinvolvearchitecturalchangesforreasons<br />
thatincludemaintainability<strong>and</strong>functionality.<br />
However, while<strong>of</strong>tenrequired, architecturalchangestypicallycome<br />
withasignificantrisk<strong>and</strong>areexpensivetoperform. Moreover,whenthe<br />
objective<strong>of</strong>suchchangesismaintainabilityimprovement,asinthescenarioabove,theirbenefitsareonlyexperiencedlateron.Thismakessuch
changesproblematic.Therefore,ourgoalistosupportevolution<strong>of</strong>s<strong>of</strong>tware<br />
architecturessuchthatrisk<strong>and</strong>costsarereduced.<br />
Consideringthedescribedscenario,nexttothequestion<strong>of</strong>howtomigrateexistingcomponents,otherquestionsarise,suchashowtoevaluatethatsuchchangesarenecessary,<strong>and</strong>,whethertheycanbeperformed<br />
(semi-)automatically.<br />
Anotherrelevantaspect<strong>of</strong>thisscenarioisthatitdealswithas<strong>of</strong>tware<br />
architecturebasedonaplatform(i.e.,thegenericreusablecomponents),<br />
whichappliestoawholeseries<strong>of</strong>systems(i.e.,thedifferentcontrolsystemsinawaferscanner).Sucharchitecturesarereferredtoasproductlinearchitectures[Clements<strong>and</strong>Northrop,2002].Torealiseeconomies<strong>of</strong><br />
scale,atrendinindustryistointegratethedevelopment<strong>of</strong>awholeset<strong>of</strong><br />
similarproductsinasingle(s<strong>of</strong>tware)productline.Thedevelopment<strong>of</strong>a<br />
s<strong>of</strong>twareproductlineisbasedonaproduct-linearchitecturethatdefines<br />
thecommonality<strong>and</strong>variabilitybetweentheproduct-linemembers(i.e.,<br />
individualproducts<strong>of</strong>theproductline). Inthecontext<strong>of</strong>s<strong>of</strong>twarearchitectureevolution,product-linearchitecturesareacomplicatingfactor<strong>and</strong>,<br />
aswewillexplaininthisthesis,requirespecialattention.<br />
Anothercomplicatingfactortoachieveourgoal<strong>of</strong>supportings<strong>of</strong>tware<br />
architectureevolutionistheintegration<strong>of</strong>evolutionsupportinindustrial<br />
practice.Industryisreluctanttoadoptnews<strong>of</strong>twareengineeringtechnologies.<br />
Animportantreasonforthisisthatittendstohavearisk-avoiding<br />
attitude.Thisproblemisalsoaddressedinthisthesis.<br />
Wewillsearchthesolutioninthearea<strong>of</strong>model-drivenengineering.We<br />
adoptthevision<strong>of</strong>model-drivenengineering(MDE)forthepurpose<strong>of</strong>supportings<strong>of</strong>twareevolution.MDEisthetermforanewgeneration<strong>of</strong>s<strong>of</strong>twaredevelopmentapproachesinwhichmodelsplayadominantrole<strong>and</strong>in<br />
which(part<strong>of</strong>)thedevelopmentstepsareperformedby(automatic)model<br />
transformations[Bézivin,2005].Intheseapproachess<strong>of</strong>twaremodelsare<br />
graduallytransformedintosourcecode,whichtypicallyexecutesontop<strong>of</strong><br />
as<strong>of</strong>twareplatform.<br />
MDEapproachesareenabledbytheavailability<strong>of</strong>st<strong>and</strong>ards,suchas<br />
formodelling<strong>and</strong>transformations. Theyhavebeendevelopedtohidethe<br />
behavioural<strong>and</strong>structuralcomplexity<strong>of</strong>theplatformsunderlyings<strong>of</strong>tware<br />
productlines[Schmidt,2006].Thiscorrespondstotheenvisionedsituation<br />
inthescenariowedescribedabove.Theconcept<strong>of</strong>MDEisfurtherdiscussed<br />
inChapter2.<br />
Ourapproachistoinvestigatetowhatextents<strong>of</strong>twarearchitecturecan<br />
bemadeexplicitasmodels, <strong>and</strong>whethertheexistingknowledge, st<strong>and</strong>ards,<strong>and</strong>toolsinthearea<strong>of</strong>MDEcanbeusedforthepurpose<strong>of</strong>s<strong>of</strong>tware<br />
architectureevolution. Thus,instead<strong>of</strong>applyingmodeltransformations<br />
forthedevelopment<strong>of</strong>s<strong>of</strong>twarebythegeneration<strong>of</strong>sourcecodefrommore<br />
abstracts<strong>of</strong>twaremodels,weapplymodeltransformationstosupportthe<br />
3
4 Chapter1. Introduction<br />
evolution<strong>of</strong>s<strong>of</strong>tware. Thisinvolvesdifferenttypes<strong>of</strong>s<strong>of</strong>twareengineeringtasks,suchasevaluation<strong>and</strong>migration.Weinvestigatetheextentto<br />
whichsuchtaskscanbeperformedbytheuse<strong>of</strong>modeltransformations.<br />
Additionally,wefocusonreal-lifesituationssuchasthemigration<strong>of</strong>controlcomponentsatASML.Intheremainder<strong>of</strong>thisintroductionwedescribetheproblem<strong>and</strong>formulatetheresearchquestionsthisthesisaddresses.Subsequently,weexplaintheapproachwefollowedtoanswerthesequestions<strong>and</strong>thescope<strong>of</strong><br />
ourwork.Weconcludewithanoutline<strong>of</strong>thisthesis<strong>and</strong>anoverview<strong>of</strong>its<br />
contributions.<br />
1.1 ProblemDescription: <strong>Evolution</strong><strong>of</strong>S<strong>of</strong>tware<strong>Architectures</strong><br />
Inthisthesis,wefocusontheevolution<strong>of</strong>s<strong>of</strong>twareplatforms<strong>and</strong>thesystemstheysupport.Moreparticularly,weaddresstheproblem<strong>of</strong>theirevolutiononthearchitecturallevel.<br />
Perry<strong>and</strong>Wolf[1992]describearchitectureasthe‘load-bearingwalls’<br />
<strong>of</strong>as<strong>of</strong>twaresystem.Assuch,as<strong>of</strong>twarearchitectureallowssomechanges<br />
<strong>and</strong>precludesothers,thatis,itallowssomedegree<strong>of</strong>evolution.Changes<br />
thatitallowsdonotrequireamigration<strong>of</strong>thearchitecture.Changes,however,thatarenotsupportedbythecurrentarchitecturewillrequiresuch<br />
amigration. Assuch,anarchitecturedetermineswhichtype<strong>of</strong>evolution<br />
ischeap(i.e.,thetypethatinvolveschangesthatdonotrequirechangesto<br />
thearchitecture)<strong>and</strong>whichtypeisexpensive(i.e.,thetypethatinvolves<br />
changesthatdorequirechangestothearchitecture).Infact,areasonfor<br />
migratingtoadifferents<strong>of</strong>twarearchitectureistochangethis,thatis,<br />
makingadifferenttype<strong>of</strong>changescheap. Asanexample,intheASML<br />
scenariosketchedaboveone<strong>of</strong>thegoalswasindeedtoreducetheeffort<br />
requiredtochangethesequence<strong>of</strong>themanufacturingactivitiesawafer<br />
scannerperformsforthemanufacturing<strong>of</strong>microchips.<br />
Whenconsiderings<strong>of</strong>twareevolutionfromanarchitecturalperspective,<br />
itneedstobedeterminedifanarchitecturerequireschanges,<strong>and</strong>subsequentlyhowtoperformthosechanges.Theformerrequiresanarchitecture<br />
evaluation. Thelatterrequiresanapproachtomigrateas<strong>of</strong>twarearchitecture,<strong>and</strong>thecorresponding‘downstream’developmentartefacts.Inthecase<strong>of</strong>acomplexarchitecture,oraproductline,whereanarchitectureaffectsmultiplesystems,itpays<strong>of</strong>ftodothisautomatically.<br />
Todoso,an<br />
architecturecanbeconsideredasamodelthatcanbemanipulated. The<br />
technologytomakethishappenis<strong>of</strong>feredbyMDE. In-linewithMDE,we<br />
aimatthedevelopment<strong>of</strong>automatedtechniques,wherepossible.
1.1. ProblemDescription 5<br />
Evaluation<br />
Conformance Checking<br />
Documentation Migration<br />
Figure 1.2:S<strong>of</strong>twareevolutiontasks<br />
Aswewillseefromthisthesis,theautomaticmanipulation<strong>of</strong>(architectural)modelsishamperedbyindustry’sresistancetoadoption<strong>of</strong>state-<strong>of</strong>the-arts<strong>of</strong>twareengineeringtechnologies.Animportantreasonforthisisthatsuchtechnologies<strong>of</strong>tenhavealargeimpactoncurrentways<strong>of</strong>working,resultinginunacceptablerisks(seealsoChapter3).Thismeansthat,inthecontext<strong>of</strong>s<strong>of</strong>twareevolution,wehavetotakeintoaccount,forinstance,theinformaluse<strong>of</strong>modellinglanguagesinindustry[Langeetal.,<br />
2006].Thismakesautomationparticularlydifficult.Ingeneral,theimpact<br />
<strong>of</strong>solutions(technologiesorprocesses)tocurrentways<strong>of</strong>workingshould<br />
beminimised.<br />
Toclarifythescope<strong>of</strong>ourworkwedistinguishfourtypes<strong>of</strong>activities<br />
relatedtoevolution<strong>of</strong>s<strong>of</strong>tware. Werefertotheseactivitiesass<strong>of</strong>tware<br />
evolutiontasks. ThetasksweconsideraredepictedinFigure1.2inan<br />
evolutionarys<strong>of</strong>twarelife-cycle<strong>and</strong>areexplainedbelow.<br />
Evaluation Inourworkthemainobjective<strong>of</strong>architectureevaluationisto<br />
determinewhetherornotproposedchangestoas<strong>of</strong>twaresystemrequire<br />
changestothecurrentarchitecture.Weconsiderarchitectureevaluationas<br />
thestartingpoint<strong>of</strong>as<strong>of</strong>twarearchitectureevolutioncycle. Aparticular<br />
challengeistheassessment<strong>of</strong>whetheraproduct-linearchitecturerequires<br />
changesintheface<strong>of</strong>anticipatedchangestotheproduct-linemembers.Dobrica<strong>and</strong>Niemelä[2002]giveanoverview<strong>of</strong>proposedarchitectureevaluationapproaches.However,none<strong>of</strong>thoseisexplicitlyaimedats<strong>of</strong>tware<br />
productlines.<br />
ConformanceChecking In the case that an evaluation indicates that architectural<br />
changes are required, it is necessary to determine to what<br />
extent‘downstream’developmentartefactsconformtothe(product-line)<br />
architecture. The question is whether development artefacts that are<br />
constrainedbythedecisionsmadeduringthearchitectingphasedonot<br />
violatethesedecisions. Inprinciple,alldesignartefactareconstrained<br />
bythearchitecture,suchasdetaileddesigns,implementations<strong>and</strong>even<br />
product-linemembers.<br />
Krikhaar[1999]<strong>and</strong>Mens[2000]compareanumber<strong>of</strong>approachesto<br />
checkarchitectureconformance.However,conformancebetweenmodelsat
6 Chapter1. Introduction<br />
differentabstractionlevelsisnotaddressed. Moreover,mostapproaches<br />
dictatetheintroduction<strong>of</strong>specificmodellinglanguages,requiringachange<br />
tocurrentways<strong>of</strong>working.<br />
Migration Aset<strong>of</strong>consistentdevelopmentartefactsasdeterminedbythe<br />
conformancecheckingtask,reducestherisk<strong>of</strong>anactualmigration<strong>of</strong>the<br />
architecture<strong>and</strong>dependentdevelopmentartefacts. Themigrationtoa<br />
newproduct-linearchitecture<strong>and</strong>associateds<strong>of</strong>twareplatformthatbettersupportsforeseenrequirements,requiresthemigration<strong>of</strong>allproducts<br />
supportedbythelegacyplatform. Thereisnopreviousworkthatconsiderss<strong>of</strong>tware(architecture)migrationasamodeltransformationproblem.<br />
Severalotherworkdoesaddressthetransformation<strong>of</strong>s<strong>of</strong>twaresystems.<br />
However, they consider single-product architectures [Bosch <strong>and</strong> Molin,<br />
1999], simple graphs [Fahmy <strong>and</strong> Holt, 2000b], or the level <strong>of</strong> source<br />
code[Terekhov<strong>and</strong>Verhoef,2000]. Thelanguagemigrationprocessused<br />
byTerekhov<strong>and</strong>Verhoef[2000]isparticularlyinteresting.Itseparatesa<br />
migrationinthreephasesthatincluderestructuring<strong>of</strong>sourceprograms<br />
toenablethe(automatic)transformationphase. Althoughitwasusedfor<br />
sourcecodemigration,suchapreparatorystepisalsorequiredforthemigrationonthearchitecturalleveltotakeintoaccountindustrialmodelling<br />
conventions.<br />
Documentation Afteramigration<strong>of</strong>the(product-line)architecture<strong>and</strong>the<br />
product-line membersit supports, documentationneeds tobeupdated.<br />
Itisgenerallyacceptedthatthedocumentation<strong>of</strong>s<strong>of</strong>twarearchitectures<br />
consists<strong>of</strong>multipleviews[Kruchten,1995;H<strong>of</strong>meisteretal.,2005]. OftentheUnified<strong>Model</strong>ingLanguage<br />
1 (UML)isusedintheseviews. On<br />
theotherh<strong>and</strong>,specialisedarchitecturedescriptionlanguages(ADLs)(see<br />
Medvidovic<strong>and</strong>Taylor[1997]foranoverview)<strong>and</strong>MDEsupportthecreation<strong>of</strong>modelstoautomateseverals<strong>of</strong>twareengineeringtasks,suchas<br />
codegeneration. However,noapproachaddressestheproblem<strong>of</strong>keeping<br />
documentation<strong>and</strong>modelsconsistent. Withtheupcoming<strong>of</strong> MDEapproachesthisbecomesahighlyrelevantproblem.<br />
Inthisthesis,weaimatincreasingourunderst<strong>and</strong>ing<strong>of</strong>each<strong>of</strong>these<br />
fours<strong>of</strong>twareevolutiontasksaswellas<strong>of</strong>feringsupportforthem.<br />
1 http://www.uml.org(June2007)
1.2. Objectives 7<br />
1.2 Objectives<br />
Intheprevioussectionweexplainedthatchangestos<strong>of</strong>twarearchitectures<br />
canberequiredtoimproveorrestorethemaintainability<strong>of</strong>s<strong>of</strong>twaresystems.However,suchevolutioninvolveshighrisks<strong>and</strong>costs.<br />
Assuch,ourmainresearchquestionis:<br />
RQ0Howcantheevolution<strong>of</strong>s<strong>of</strong>twarearchitecturesbesupported?<br />
Wewillinvestigatethisquestioninterms<strong>of</strong>thes<strong>of</strong>twareevolution<br />
tasksweidentified:evaluation,conformancechecking,migration,<strong>and</strong>documentation.WhenconsideringtheproblemdescriptioninSection1.1,RQ0<br />
raisesanumber<strong>of</strong>subquestionsthatweintroducebelow.<br />
1.2.1 IntegrationinPractice<br />
Aswewillseeinthisthesis,integration<strong>of</strong>news<strong>of</strong>twareengineeringtechnologiesinindustrialpracticeisdifficult.<br />
Thisisduetotherisk-avoiding<br />
attitude<strong>of</strong>industrialcompaniestowardssuchinnovation,resultingina<br />
preference<strong>of</strong>proventechnologies.<br />
However,alsoacademia’sattitudetowardspracticalindustrialproblems<br />
hampersapplication<strong>of</strong>researchresultsinpractice. Theseproblemsare<br />
<strong>of</strong>tenconsiderednottobeinterestingfromanacademicpoint<strong>of</strong>vieworare<br />
difficulttoinvestigatebecausesuchinvestigationsareverycostly<strong>and</strong>time<br />
consuming.Finally,industryisnotalwayswillingtocooperate.Theresult<br />
isthat<strong>of</strong>tens<strong>of</strong>twareengineeringtechnologiesdevelopedbyacademiaare<br />
not(fully)appliedinindustrialpractice.Anexampleistheinformaluse<strong>of</strong><br />
modellinginpractice.<br />
Thisleadstoourfirstsubquestion:<br />
RQ1Howtointegratethesupportfors<strong>of</strong>twareevolutiontasksinpractice,<br />
consideringtheinformaluse<strong>of</strong>modellinglanguages<strong>and</strong>preference<br />
forproventechnologiesinindustry?<br />
1.2.2 ProductLines<br />
Manycompaniesextendedthescope<strong>of</strong>theirs<strong>of</strong>twarearchitecturesfrom<br />
singlesystemstomultiplesystemstoincreasereuse<strong>and</strong>reducerequired<br />
development<strong>and</strong>maintenanceeffort 1 .<br />
Forours<strong>of</strong>twareevolutiontaskstheuse<strong>of</strong>productlineprinciplesis<br />
relevant. Onereasonis,forinstance,thatproductlinearchitecturesare<br />
1 Forexamples,visittheProductLineHall<strong>of</strong>Fame:http://www.sei.cmu.edu/productlines/<br />
plp_h<strong>of</strong>.html(June2007)
8 Chapter1. Introduction<br />
definedonahigherlevel<strong>of</strong>abstractionthansingle-productarchitectures.<br />
Furthermore,thenumber<strong>of</strong>stakeholdersforaproductlinealsoishigher.<br />
Thiscomplicates,forinstance,evaluations.<br />
Thisleadstooursecondsubquestion:<br />
RQ2Whatistheimpact<strong>of</strong>theuse<strong>of</strong>s<strong>of</strong>twareproductlines<strong>and</strong>platforms<br />
onthesupportfors<strong>of</strong>twareevolutiontasks?<br />
1.2.3 <strong>Model</strong>-<strong>Driven</strong>Engineering<br />
S<strong>of</strong>twarearchitectureevolutioniscostly<strong>and</strong>risky. Therefore,wewillinvestigatetheuse<strong>of</strong>MDEtechnologyforthisproblem.Automationisone<strong>of</strong><br />
thekeycharacteristics<strong>of</strong>MDE.Whenappliedtothearchitectureevolution<br />
thismayyieldcheaper<strong>and</strong>morereliableresults.<br />
Ouruse<strong>of</strong>MDEisalsomotivatedbyRQ1<strong>and</strong>RQ2. Thedevelopment<br />
<strong>of</strong> MDEtechnologieshasbeendrivenbyindustry. Thiscanbeseen,for<br />
instance,fromthewide-spreaduse<strong>of</strong>UMLfors<strong>of</strong>twaredesign. Assuch,<br />
supportfors<strong>of</strong>twareevolutiontasksbasedonsimilartechnologymightby<br />
itselfalreadyimproveintegration<strong>of</strong>suchsupportinindustrialenvironments.<br />
Finally,astronglinkexistsbetweenMDE<strong>and</strong>s<strong>of</strong>twareproductlines.<br />
WithMDEthegeneratedcodetypicallyexecutesontop<strong>of</strong>as<strong>of</strong>twareplatform.Atthesametimes<strong>of</strong>twareplatformsarethefoundationforeventhe<br />
mostbasicproductlines[Bosch,2002]. Assuch,MDEapproachescanbe<br />
usedfortheautomaticderivation<strong>of</strong>product-linemembers[Deelstraetal.,<br />
2003].<br />
Forindustrialapplicability,onespecifictype<strong>of</strong>MDEisparticularrelevant.<br />
WefocusonMDEtechnologiesbasedonaset<strong>of</strong>st<strong>and</strong>ardsdefined<br />
bytheObjectManagementGroup 1 (OMG)underthename<strong>Model</strong><strong>Driven</strong><br />
Architecture 2 (MDA). ThereasonforthisisthatUMLisanessentialpart<br />
<strong>of</strong>theMDAframework;<strong>and</strong>UMListhe(defacto)st<strong>and</strong>ardformodelling<br />
s<strong>of</strong>tware[Kobryn,1999]thatismostwidelyappliedinindustry. Webelievethatthepracticalrelevance<strong>of</strong>ourworkisincreasedbyrestricting<br />
ourselvestothisframework(seealsoRQ1).<br />
<strong>Model</strong>-drivensupportatthearchitecturallevelforours<strong>of</strong>twareevolutiontasksallowsfor(partial)automation,resultinginimprovedreliability,efficiency(<strong>of</strong>thedevelopmentprocess),<strong>and</strong>quality(<strong>of</strong>developeds<strong>of</strong>tware)[Atkinson<strong>and</strong>Küne,2003;Selic,2003].<br />
Thisleadstoourthird<strong>and</strong>finalsubquestion:<br />
RQ3Towhatextentcanthesupportfors<strong>of</strong>twareevolutiontasksbeautomatedbytheuse<strong>of</strong>model-drivenengineering?<br />
1 http://www.omg.org(June2007)<br />
2 http://www.omg.org/mda(June2007)
1.3. Approach 9<br />
1.3 Approach<br />
Ass<strong>of</strong>twareengineeringisanappliedscience,ourviewons<strong>of</strong>twareengineeringresearchisthatresultscanonlybeprovenusefulbyvalidationin<br />
industrialpractice. Furthermore,thistype<strong>of</strong>researchisaimedatsolvingrealproblems.<br />
Suchproblemsaremainlyfoundinindustry(atleast<br />
problemsinthedomain<strong>of</strong>s<strong>of</strong>twareengineering).<br />
Therefore,weintendourresearchtobeindustry-driven;weadoptthe<br />
‘industry-as-laboratory’approachproposedbyPotts[1993]. Inthisapproachtheproblemsstudiedareidentifiedbycloseinvolvementinindustrialprojects<strong>and</strong>resultsareappliedtopracticalproblems;thereisanemphasisonrealcasestudies.<br />
Weaccomplishtheinteractionswithindustryonwhichthisapproachis<br />
basedinthreeways:asurvey,industrialcasestudies,<strong>and</strong>closecollaborationwiths<strong>of</strong>twarepractitionersinindustry.<br />
Wefirstperformasurveyamongmorethan35s<strong>of</strong>twarepractitionersat<br />
eightcompaniestogetanoverview<strong>of</strong>s<strong>of</strong>twareengineeringpractices<strong>and</strong><br />
specificproblemsinthe(embedded)s<strong>of</strong>twareindustry(seeChapter3).The<br />
observationsmadeinthatsurveyincludetheupcominguse<strong>of</strong>product-line<br />
approaches,theinformaluse<strong>of</strong>modellinglanguages,<strong>and</strong>theimportance<br />
<strong>of</strong>theevolutionaryaspect<strong>of</strong>s<strong>of</strong>tware. Thissurveypartiallydetermined<br />
theproblemsweaddressintheresearchdescribedbythisthesis.<br />
Theexploratorycharacter<strong>of</strong>ourresearch,thetype<strong>of</strong>researchquestions<br />
wewanttoinvestigate(‘how’questions),<strong>and</strong>thelowlevel<strong>of</strong>controlwe<br />
haveoverthe(industrial)environmentinwhichs<strong>of</strong>twareevolutiontakes<br />
place,makethatcasestudiesareasuitableresearchapproach[Yin,2003].<br />
Furthermore,theuse<strong>of</strong>industrialcasestudiesreducestherisk<strong>of</strong>scalabilityproblems<strong>of</strong>theresultsKitchenhametal.[1995].Therefore,weuse<br />
casestudiestoinvestigatetheapplicability<strong>of</strong>model-drivenapproachesto<br />
thefours<strong>of</strong>twareevolutiontaskswedefined.<br />
Foreachtaskweproposeaseparatesolution,whichweevaluateina<br />
(industrial)casestudy. Assuch,weperformedseparatecasestudiesfor<br />
each<strong>of</strong>theevolutiontasks:evaluation,conformancechecking,migration,<br />
<strong>and</strong>documentation. Thecasestudiesweconductedaremainlyrelatedto<br />
twoindustrialsystems: copiersdevelopedbyOcé<strong>and</strong>waferscannersdevelopedbyASML.Assuch,byourcasestudies,wefocusontheembedded<br />
s<strong>of</strong>twaredomain.TheconclusioninChapter9alsoreflectsonthequestion<br />
<strong>of</strong>whetherthisisrelevantfromtheperspective<strong>of</strong>ourresearchquestions.<br />
Giventheexploratorycharacter<strong>of</strong>ourresearch,wedonotdefineaset<br />
<strong>of</strong>researchpropositionstoinvestigate.Instead,wedirectourresearchby<br />
thesubquestionsoutlinedinSection1.2. AsdiscussedbyYin[2003]we<br />
usethisdirectiontoguideouranalysis<strong>of</strong>thecasestudiesweperform.We<br />
qualitativelyevaluatethesolutionsweproposebycarefullyobserving<strong>and</strong>
10 Chapter1. Introduction<br />
analysingtheirapplicationineachcasestudy.<br />
Forthecasestudyinwhichweevaluatedourapproachforthemigration<br />
task,wewereabletocompareourfindingswithrespecttoamigration<br />
<strong>of</strong>thesamesystemconductedmanually.Theconformancecheckingtasks<br />
wereonlyexecutedusingourtechniques. Therefore,theirevaluationis<br />
basedonthetype<strong>and</strong>number<strong>of</strong>inconsistenciesfound.Fortheevaluation<br />
<strong>and</strong>documentationtasks,weevaluateoursolutionswithrespecttothe<br />
application<strong>of</strong>similarapproachesinothercases.<br />
Consideringourresearchquestions,wespecificallyfocusedtheevaluationontheextenttowhichthes<strong>of</strong>twareevolutiontaskscanbeautomated,<br />
theimpact<strong>of</strong>s<strong>of</strong>twareproductlines,<strong>and</strong>possibilitiesforreusing(proven)<br />
s<strong>of</strong>twaretechnologies<strong>and</strong>reducingorganisationalimpact.<br />
1.4 Overview<br />
Thisthesisaddressestheproblem<strong>of</strong>managingevolutionforcomplexs<strong>of</strong>twareintensivesystems.Westudiedthisproblem<strong>and</strong>itssolutionsinterms<br />
<strong>of</strong>s<strong>of</strong>twarearchitecture<strong>and</strong>MDE.Theremainder<strong>of</strong>thisthesisisorganised<br />
asfollows.<br />
SettingtheScene InChapter2weintroducesome<strong>of</strong>theconceptsthatwere<br />
touchedupononlybrieflyinthisintroductionmorethoroughly.Inparticularwediscusss<strong>of</strong>twarearchitecture<strong>and</strong>MDE.Chapter3reportsonthesurveyweconductedamongseveralcompaniesdevelopingembeddeds<strong>of</strong>tware.<br />
Thesurveyresultedinanumber<strong>of</strong><br />
importantobservationsforthisthesis:<br />
•Industryrarelydevelopsproductsfromscratch.Thisobservationconfirmstheimportance<strong>of</strong>theevolution<strong>and</strong>maintenanceaspects<strong>of</strong>s<strong>of</strong>twaredevelopment.<br />
•Increasingly,product-line<strong>and</strong>MDEapproachesareappliedforthedevelopment<strong>of</strong>embeddeds<strong>of</strong>tware.<br />
•Currents<strong>of</strong>twareengineeringtechnologiesaredifficulttoapplyin<br />
practiceduetoseveralreasons. Oneconsequenceisthatsuchtechnologiesareappliedinapragmaticway,forinstance,modellinglanguages<strong>and</strong>toolsare<strong>of</strong>tenonlyusedtodrawdiagramsforthepurpose<strong>of</strong>documentationratherthanforthepurpose<strong>of</strong>,forinstance,<br />
automaticanalysesorcodegeneration.
1.4. Overview 11<br />
Thefirsttwoobservationscallforanapproachthatenablestheintroduction<strong>of</strong>productlinesina“bottom-up”manner,meaningthatproductlinescomeintoexistencebasedonexistingproducts<strong>and</strong>aredevelopedin<br />
anevolutionary,ratherthanrevolutionary(ortop-down),way.<br />
Thethirdobservationaddstheconstraintthatsuchanapproachtakes<br />
intoaccountsome<strong>of</strong>thepracticalissuesthatarearealityfors<strong>of</strong>twaredevelopmentorganisations,suchastheinformaluse<strong>of</strong>modellinglanguages,<br />
thelimitedamount<strong>of</strong>timefordoinganalysis,<strong>and</strong>theriskinvolvedin<br />
changingexistingways<strong>of</strong>working.<br />
TheEvaluationTask InChapter4wedefineascenario-basedapproachbased<br />
ontheS<strong>of</strong>twareArchitectureAnalysisMethod(SAAM)[Kazmanetal.,1996]<br />
forassessingthequality<strong>of</strong>anemergingproduct-linearchitectureforthe<br />
embeddeds<strong>of</strong>twareforcopiersdevelopedbyOcé(Figure1.3onthefollowingpage).Thisarchitectureemergedinabottom-upmannerfromanumber<strong>of</strong>existingproducts.Atsomepointquestionswereraisedwithrespect<br />
tothesuitability<strong>of</strong>theproduct-linetoincorporatemoreexisting<strong>and</strong>future<br />
productsasproduct-linemembers.Thereforeanassessmentwasinitiated<br />
thathadtotakeintoaccounttheemergentcharacter<strong>and</strong>corresponding<br />
low-visibility<strong>of</strong>theproduct-lineintheorganisation. Thelatterresulted<br />
inalowcommitment<strong>of</strong>severalstakeholderstosuchanassessment. The<br />
resultsshowthatatwo-phasedscenariodevelopmentstep,inwhichpart<br />
<strong>of</strong>thescenariosarecollectedseparatelyfromthejointevaluationsession,<br />
resultsinamoreefficientapproachthatstillyieldsacceptableassessment<br />
results. Additionally,thischapteridentifiestheproblem<strong>of</strong>conformance<br />
<strong>of</strong>thearchitecture<strong>of</strong>product-linememberstoaproduct-linearchitecture.<br />
Suchconformanceisdesirablebeforeupdatingaproduct-linearchitecture<br />
ormigratinganexistingproducttoincorporateitintheproduct-line.<br />
TheConformanceCheckingTask Twochaptersdealspecificallywithconformancechecking.<br />
InChapter5wediscusshowtousemodeltransformationstocombine<br />
scenariosintostate-basedbehaviouralmodels. Comparedtotheprevious<br />
casestudy,thescenariosareexpressedinmoredetailusingUMLsequence<br />
diagrams.Weappliedthetransformationstoaset<strong>of</strong>scenariosforacomponentdefinedbytheproduct-linearchitecturefortheembeddedcopier<br />
s<strong>of</strong>tware<strong>of</strong>Océ. Thisresultsinastatetransitionmodel. Toassessthe<br />
extenttowhichthescenariosareconsistentwithastatetransitionmodel<br />
thatisusedtogeneratethesourcecodeforthatcomponent,we(manually)investigatethedifferencesbetweenthetwostatemodels.Assuch,we<br />
identifiedanumber<strong>of</strong>inconsistencies.
12 Chapter1. Introduction<br />
Figure 1.3:Océcopier<br />
A model-driven approach for automatically determining the conformance<strong>of</strong>s<strong>of</strong>twareartefactsisproposedinChapter6.Aview-basedprocess<br />
for conformancecheckingis described thatdoes not interfere with the<br />
currentway<strong>of</strong>working<strong>of</strong>theinvolveddomains(e.g.,requirements,architecture,orimplementation)byintroducingtheconcept<strong>of</strong>aconformance<br />
viewpoint(i.e.,atype<strong>of</strong>view). Inthecase<strong>of</strong>architectureconformance<br />
suchaviewpoint,specifiedasametamodel,definescheckableaspects<strong>of</strong><br />
thearchitecture<strong>and</strong>implementation,assuchbridgingthesemanticgap<br />
betweenthetwodomains. Weillustratehowmodeltransformationscan<br />
be used to automatically discover inconsistencies between architecture<br />
specifications<strong>and</strong>implementation.<br />
TheMigrationTask Onceaproduct-linearchitecturehasbeenassessed<strong>and</strong><br />
theconformance<strong>of</strong>product-instanceswithrespecttotheproduct-linehas<br />
beenconfirmed,existingproductsneedtobemigratedtothenewproductlineapproach.Thisrequiresthatinstancespecificinformationisextracted<br />
<strong>and</strong>transformedintoaviewassociatedwithaviewpointthatwasdefined<br />
todescribeproductinstances. InChapter7wedescribeagenericviewbasedprocessformigratingthelegacydesignsdiscussedatthestart<strong>of</strong>this<br />
chapterintoviewsthatexactlydescribeaproductinstanceinterms<strong>of</strong>a<br />
newproduct-linearchitecture. Forthemigration<strong>of</strong>controlarchitectures<br />
basedonfinitestatemachineswedefineanumber<strong>of</strong>transformationrules<br />
thatresultinaspecification<strong>of</strong>suchanarchitectureinterms<strong>of</strong>aproductlinearchitecturebasedontask-resourcesystems.Theserulesareamenable<br />
foranMDA-type<strong>of</strong>approachthatispartiallyautomated.
1.5. Origin<strong>of</strong>Chapters 13<br />
Table 1.1:Coverage<strong>of</strong>researchquestionsinchapters<br />
Question<br />
RQ1<br />
RQ2<br />
RQ3<br />
Chapter<br />
3<br />
√<br />
4<br />
√<br />
√<br />
5<br />
√<br />
√<br />
6<br />
√<br />
√<br />
7<br />
√<br />
√<br />
√<br />
8<br />
√<br />
√<br />
TheDocumentationTask Todecreasetheeffortrequiredforfutureevolution<br />
<strong>of</strong>s<strong>of</strong>twareproducts,up-to-datedocumentationisanimportantasset[Forward<strong>and</strong>Lethbridge,2001].InChapter8wediscusstherelationbetween<br />
thearchitecturalmodelsusedforconformancechecking<strong>and</strong>migration,for<br />
instance,<strong>and</strong>architecturalviewsfordocumentation.Wepresentaframeworkinwhichtheinvolvedconceptsarerelatedtoeachother<strong>and</strong>show<br />
howsuchaframeworkcanbesupportedbyMDEtechnologies.<br />
TheResearchQuestions Finally,toconclude,Chapter9presentsanoverview<br />
<strong>of</strong> our contributions <strong>and</strong> revisits the research questions raised in Section1.2.Table1.1illustrateshowthesequestionsarecoveredbythecore<br />
chapters<strong>of</strong>thisthesis. Allchapterstakeintoaccountthepracticalapplicability<strong>of</strong>theproposedsolutions,forinstancebytheuse<strong>of</strong>twoindustrial<br />
casestudies. Developmentusingproduct-lineprinciplesplaysanimportantroleinChapters4<strong>and</strong>7.<br />
Automationusing MDEisthedominant<br />
concerninthefinalfourcorechapters.Inallthesecasestheexperiments<br />
are conducted using the Atlas Transformation Language [Jouault <strong>and</strong><br />
Kurtev,2005](ATL).<br />
1.5 Origin<strong>of</strong>Chapters<br />
ExceptforChapter2,thechaptersinthisthesisappearedbeforeasrefereedpublicationsininternationaljournals,<strong>and</strong>proceedings<strong>of</strong>conferences<br />
<strong>and</strong>workshops.Apartfromtheintroduction(substantiallyextended)<strong>and</strong><br />
Chapter6(majorrevision)onlyminorchangeswereappliedbeforeinclusioninthisthesis.Theorigin<strong>of</strong>thisthesis’schaptersisasfollows:<br />
Chapter1Graaf,Bas.<strong>Model</strong>-drivenevolution<strong>of</strong>s<strong>of</strong>twarearchitectures.In<br />
Proceedings<strong>of</strong>the11 th EuropeanConferenceonS<strong>of</strong>twareMaintenance<strong>and</strong>Reengineering(CSMR2007),pages357–360.IEEE<br />
ComputerSociety,2007
14 Chapter1. Introduction<br />
Chapter3Graaf,Bas,MarcoLormans,<strong>and</strong>HansToetenel.Embeddeds<strong>of</strong>twareengineering:Thestate<strong>of</strong>thepractice.<br />
IEEES<strong>of</strong>tware,<br />
20(6):pages61–69,2003;<strong>and</strong><br />
Graaf,Bas,MarcoLormans,<strong>and</strong>HansToetenel.S<strong>of</strong>twaretechnologiesforembeddedsystems:Anindustryinventory.InProceedings<strong>of</strong>the4<br />
th InternationalConferenceonProductFocused<br />
S<strong>of</strong>twareProcessImprovement(PROFES2002),volume2559<strong>of</strong><br />
LectureNotesinComputerScience,pages453–465.Springer-<br />
Verlag,2002<br />
Chapter4Graaf,Bas,HylkevanDijk,<strong>and</strong>ArievanDeursen.Evaluating<br />
anembeddeds<strong>of</strong>twarereferencearchitecture–industrialexperiencereport.InProceedings<strong>of</strong>the9<br />
th EuropeanConferenceon<br />
S<strong>of</strong>twareMaintenance<strong>and</strong>Reengineering(CSMR2005),pages<br />
354–363.IEEEComputerSociety,2005<br />
Chapter5VanDijk,HylkeW.,BasGraaf,<strong>and</strong>RobBoerman. Onthesystematicconformancecheck<strong>of</strong>s<strong>of</strong>twareartefacts.InProceedings<br />
<strong>of</strong>the2 nd EuropeanWorkshoponS<strong>of</strong>twareArchitecture(EWSA<br />
2005),volume3047<strong>of</strong>LectureNotesonComputerScience,pages<br />
203–221.Springer-Verlag,2005<br />
Chapter6Graaf,Bas<strong>and</strong>ArievanDeursen. <strong>Model</strong>-drivenconsistency<br />
checking<strong>of</strong>behaviouralspecifications.InProceedings<strong>of</strong>the4 th<br />
InternationalWorkshopon<strong>Model</strong>-basedMethodologiesforPervasive<strong>and</strong>EmbeddedS<strong>of</strong>tware(MOMPES2007),pages115–<br />
126.IEEEComputerSociety,2007a<br />
Chapter7Graaf,Bas,SvenWeber,<strong>and</strong>ArievanDeursen. <strong>Model</strong>-driven<br />
migration<strong>of</strong>supervisorymachinecontrolarchitectures.Journal<br />
<strong>of</strong>Systems<strong>and</strong>S<strong>of</strong>tware,2007. Doi:10.1016/j.jss.2007.06.007;<br />
<strong>and</strong><br />
Graaf,Bas,SvenWeber,<strong>and</strong>ArievanDeursen. Migratingsupervisorycontrolarchitecturesusingmodeltransformations.InProceedings<strong>of</strong>the10thEuropeanConferenceonS<strong>of</strong>twareMaintenance<strong>and</strong>Reengineering(CSMR2006),pages151–160.IEEE<br />
ComputerSociety,2006<br />
Chapter8Graaf,Bas<strong>and</strong>ArievanDeursen. Visualisation<strong>of</strong>domainspecificmodellinglanguagesusingUML.<br />
InProceedings<strong>of</strong>the<br />
14 th AnnualIEEEInternationalConference<strong>and</strong>Workshopon<br />
theEngineering<strong>of</strong>ComputerBasedSystems(ECBS2007),pages<br />
586–595.IEEEComputerSociety,2007c
1.5. Origin<strong>of</strong>Chapters 15<br />
Furthermore,ourresearchhasresultedinthefollowingpublications<br />
thatarenotdirectlyincludedinthisthesis:<br />
•Graaf,Bas<strong>and</strong>ArievanDeursen. UsingMDEforgenericcomparison<strong>of</strong>views.<br />
InProceedings<strong>of</strong>the4 th InternationalWorkshopon<br />
<strong>Model</strong>Design,Verification<strong>and</strong>Validation(MoDeVVa2007),pages57–<br />
66.INRIA,2007b<br />
•Spanjers,Hans,MaartenterHuurne,DanBendas,BasGraaf,Marco<br />
Lormans,<strong>and</strong>RinivanSolingen. Toolsupportfordistributeds<strong>of</strong>twareengineering.<br />
InProceedings<strong>of</strong>the1 st InternationalConference<br />
onGlobalS<strong>of</strong>twareEngineering(ICGSE2006),pages187–198.IEEE<br />
ComputerSociety,2006<br />
•Doyle,Duncan,HansGeers,BasGraaf,<strong>and</strong>ArievanDeursen. Migrating<br />
a domain-specific modeling language to MDA technology.<br />
In Proceedings <strong>of</strong> the 3 rd International Workshop on Metamodels,<br />
Schemas,Grammars,<strong>and</strong>OntologiesforReverseEngineering(ateM<br />
2006),number1/2006inMainzerInformatik-Berichte,pages47–54.<br />
JohannesGutenberg-UniversitätMainz,2006<br />
•Cornelissen,Bas,BasGraaf,<strong>and</strong>LeonMoonen.Identification<strong>of</strong>variationpointsusingdynamicanalysis.<br />
InProceedings<strong>of</strong>the1 st InternationalWorkshoponReengineeringtowardsProductLines(R2PL<br />
2005),pages9–13.2005
Chapter2<br />
Background<br />
Inthischapterweelaborateonsome<strong>of</strong>theconceptsbrieflyintroducedin<br />
Chapter1. Inparticular,wediscusss<strong>of</strong>twareevolution,s<strong>of</strong>twarearchitecture,<strong>and</strong>model-drivenengineeringinthelight<strong>of</strong>theresearchquestions<br />
weposedpreviously.<br />
2.1 S<strong>of</strong>tware<strong>Evolution</strong><br />
Engineeringdisciplinesaretypicallybasedonuniversal,scientificlaws<strong>and</strong><br />
principles.Alsointhediscipline<strong>of</strong>s<strong>of</strong>twareengineeringanumber<strong>of</strong>such<br />
lawshavebeendiscovered.Endres<strong>and</strong>Rombach[2003]giveanoverview.A<br />
few<strong>of</strong>themostwidelyacknowledgedlawsweredefinedbyLehman[1978]<br />
<strong>and</strong>areconcernedwiththechange<strong>of</strong>s<strong>of</strong>twaresystemsovertime:s<strong>of</strong>tware<br />
evolution.Theyarebasedonempiricalobservations.Thefirsttwo<strong>of</strong>these,<br />
so-called,laws<strong>of</strong>s<strong>of</strong>twareevolutiondynamicsarestatedinTable2.1on<br />
thefollowingpage.<br />
ThegraphinFigure2.1onthenextpageillustratesbothlawsbyplottingameasureforsizeagainstameasureforcomplexity<strong>of</strong>embedded<br />
copiers<strong>of</strong>twaredevelopedbyOcé. Itshowsatrend<strong>of</strong>increasingsize<strong>and</strong><br />
complexityforthesubsequent(i.e.,intime)revisions<strong>of</strong>thes<strong>of</strong>tware.<br />
S<strong>of</strong>twareevolvesbecause<strong>of</strong>variousreasons.Thes<strong>of</strong>twaresystems(programs)referredtointhes<strong>of</strong>twareevolutionlawsare,forinstance,affected<br />
bychangesintherealityreflectedintheirspecification[Lehman,1980].<br />
Suchchangesarecausedbychangesinstakeholderobjectivesortothe<br />
environment. Anexample<strong>of</strong>theformerareadditionalormodifiedstakeholderrequirements.<br />
Anexample<strong>of</strong>thelatter,inthecase<strong>of</strong>embedded<br />
systems,arechangestohardware. Asaresponseas<strong>of</strong>twaresystemrequiresadaptivemaintenance.Obviously,theusefulness<strong>of</strong>as<strong>of</strong>twaresystemdecreasesifsuchmaintenancetasksarenotperformed.<br />
Othertypes<br />
17
18 Chapter2. Background<br />
Table 2.1:FirsttwoLaws<strong>of</strong>S<strong>of</strong>tware<strong>Evolution</strong>[Lehman,1978]<br />
I Law<strong>of</strong>ContinuingChange<br />
A large program that is used undergoes continuing change or becomes<br />
progressively less useful. The change process continues until it is<br />
judged more cost-effective to replace the system with a recreated version.<br />
II Law<strong>of</strong>IncreasingComplexity<br />
As a large program is continuously changed, its complexity, which reflects<br />
deteriorating structure, increases unless work is done to maintain<br />
or reduce it.<br />
Figure 2.1:Complexityvs.sizeforsubsequentrevisions<strong>of</strong>copiers<strong>of</strong>tware[Sonnenberg,2005]
2.1. S<strong>of</strong>tware<strong>Evolution</strong> 19<br />
<strong>of</strong>maintenancetasksarecorrective(removal<strong>of</strong>bugs)orperfective(optimisingperformanceormaintainability)[Swanson,1976;IEEE-1219,1998]<br />
<strong>and</strong>alsocauses<strong>of</strong>twaretoevolve. Thefirstlawstatesthatsuchchanges<br />
continueuntilitbecomesmorecost-effectivetoreplaceasystem.However,<br />
development<strong>of</strong>replacementsystemstypicallywillnotstartfromscratch,<br />
<strong>and</strong>significantparts<strong>of</strong>thealreadyexistings<strong>of</strong>twarewillbereused. As<br />
such,thes<strong>of</strong>twarecontinuestoevolve.<br />
Implicitly,thefirstlawisbasedontheassumptionthatchangebecomes<br />
moreexpensiveoverthelifetime<strong>of</strong>as<strong>of</strong>twaresystembystatingthatat<br />
somepointreplacementbecomesmorecost-effectivethanmakingchanges.<br />
Thisismadeexplicitinthesecondlaw.Itdescribestheunfortunateconsequence<strong>of</strong>continualchange:s<strong>of</strong>twaresystemsbecomeprogressivelymore<br />
complexovertime.Inthislaw,complexitydoesnotrefertocomputational<br />
complexity,buttotheeffortrequiredtounderst<strong>and</strong>theinnerworkings<strong>of</strong><br />
as<strong>of</strong>twaresystem.Foralargepartthiseffortdependsonthestructure<strong>of</strong><br />
thes<strong>of</strong>tware[Lehman,1978],thatis,itscomponents<strong>and</strong>theirrelations.<br />
Aschangerequiresunderst<strong>and</strong>ing,aconsequence<strong>of</strong>increasedcomplexity<br />
isthatitmakesas<strong>of</strong>twaresystemmoredifficulttochange.<br />
Therearevariousexplanations<strong>of</strong>thislaw<strong>of</strong>increasingcomplexity.Although,intheory,itmightbepossibletomakechangestos<strong>of</strong>twaresystemswithoutdeterioratingitsstructure,practiceisdifferent.Inindustrials<strong>of</strong>twareprojects,theusers<strong>and</strong>customers<strong>of</strong>as<strong>of</strong>twaresystemaremainlyconcernedwithitsoperation(e.g.,performance,functionality),<strong>and</strong>notwithitsstructure.Thismakesitdifficultforthedevelopmentorganisationtojustifylongerlead-time<strong>of</strong>changerequestsbecause<strong>of</strong>structuralpreservation<strong>and</strong>recovery.Moreover,theeffects<strong>of</strong>sucheffortsarenotmeasurableimmediatelyafterchangesaremade,butareonlylong-term;theydecrease<br />
theeffortrequiredforsubsequentchanges[Lehman,1978]. Eventually,<br />
asthisprocess<strong>of</strong>increasingcomplexitycontinues,itbecomesinfeasible<br />
tomakeevensmallchangestothes<strong>of</strong>tware. Then,asystemneedstobe<br />
replaced.<br />
VanDeursen[2005]proposedtwopossiblestrategiestodealwiththese<br />
laws: 1)postponethemomentatwhichasystemneedstobereplaced<br />
asmuchaspossiblebyapplyingtechniquestomanageitsever-increasing<br />
complexity;<strong>and</strong>2)applytechniquestorestoretheoriginalstructureorimposeanewstructureonthes<strong>of</strong>twaresystem.<br />
ConsideringtheresearchquestionsposedinChapter1,weinvestigate<br />
inthisthesishow<strong>and</strong>bytheuse<strong>of</strong>whichtechnologiesthesetwostrategies<br />
canbesupported. Tothisendweconsiderhowspecifications<strong>of</strong>s<strong>of</strong>tware<br />
structurecanbeevaluated<strong>and</strong>manipulated.Furthermore,totakeintoaccountthecomplexity<strong>of</strong>s<strong>of</strong>twaresystemsweinvestigatetowhatextentthis<br />
canbeautomated.Asanexample,techniquestodeterminetheconsistency<br />
<strong>of</strong>differentdevelopmentartefacts,discussedinChapters5<strong>and</strong>6,helpto
20 Chapter2. Background<br />
managecomplexity;techniquestoautomatethemigration<strong>of</strong>as<strong>of</strong>tware<br />
architecture,discussedinChapter7,helptoimposeanewstructure.<br />
Wealreadystatedthatas<strong>of</strong>twaresystem’scomplexityisstronglyrelatedtoitsstructure(seeLehman’ssecondlaw,Table2.1onpage18).The<br />
subfield<strong>of</strong>s<strong>of</strong>twareengineeringthatstudiess<strong>of</strong>twarestructureiscalled<br />
s<strong>of</strong>twarearchitecture. Theideabehinds<strong>of</strong>twarearchitectureisthatcomplexitycanbemanagedbyapplyingseparation<strong>of</strong>concerns<strong>and</strong>abstraction.<br />
ThisisdiscussedinSection2.2.<br />
Anotherwaytomanagecomplexityistheuse<strong>of</strong>automation. <strong>Model</strong>drivenengineering(MDE)isanapproachtos<strong>of</strong>twaredevelopmentbasedonautomation(<strong>and</strong>abstraction).WithMDEapplicationsaregeneratedautomaticallybymeans<strong>of</strong>modeltransformationsthattransformabstracts<strong>of</strong>twaremodelsintosourcecode.MDEisdiscussedinSection2.3.InthisthesisweemployMDEtechniquestosupporttheevolution<strong>of</strong>s<strong>of</strong>twarearchitectures.WeconcludethischapterinSection2.4byexplaining<br />
thatduetoaconceptualoverlapMDEtechniquesareparticularlysuitedfor<br />
thispurpose.<br />
2.2 Architecture-<strong>Driven</strong>S<strong>of</strong>twareDevelopment<br />
2.2.1 S<strong>of</strong>twareArchitecture<br />
Thedevelopment<strong>of</strong>as<strong>of</strong>twaresysteminvolvesalargenumber<strong>of</strong>designdecisionsthateventuallyleadtoanexecutablespecification<strong>of</strong>itsbehaviour,<br />
typicallyintheform<strong>of</strong>sourcecode. Foralongtime,ithasbeenrealised<br />
(e.g.,byDijkstra[1968],Parnas[1972]<strong>and</strong>Brooks,Jr[1975])that,nextto<br />
behaviour,itpays<strong>of</strong>ftobealsoconcernedwithas<strong>of</strong>twaresystem’sstructure<strong>and</strong>organisationforreasons<strong>of</strong>dependability,underst<strong>and</strong>ability,<strong>and</strong><br />
maintainability. Therefore,forlargesystems,thesedesigndecisionsnot<br />
onlyconsiderthebehaviour,butalsothestructures<strong>of</strong>thes<strong>of</strong>twaresystem.<br />
Thekeyprinciplesonwhichthedesign<strong>of</strong>s<strong>of</strong>twarearchitecturesisbased<br />
areseparation<strong>of</strong>concerns[Dijkstra,1974]<strong>and</strong>abstraction.<br />
Because<strong>of</strong>thecomplexity<strong>of</strong>s<strong>of</strong>twaresystems,multiplelevels<strong>of</strong>abstractionarenecessarytoensuredesignsremaincomprehensible.<br />
This<br />
givesrisetoseveraltypes<strong>of</strong>design. Usually,atleasttwolevels<strong>of</strong>designaredistinguished.<br />
Detaileddesigninvolvesthedecisionsrelatedto,<br />
forinstance,datastructures<strong>and</strong>algorithms.Atahigherlevel<strong>of</strong>abstraction,designiscalleds<strong>of</strong>twarearchitecturedesign[Garlan<strong>and</strong>Shaw,1993],<br />
whichisone<strong>of</strong>thekeytopics<strong>of</strong>thisthesis.<br />
Itisdifficulttocapturethenotion<strong>of</strong>s<strong>of</strong>twarearchitectureinasingle<br />
definition. Asanexample,theS<strong>of</strong>twareEngineeringInstitute[2006]collectedmanydefinitions.Perry<strong>and</strong>Wolf[1992]provideamodel<strong>of</strong>s<strong>of</strong>tware
2.2. Architecture-<strong>Driven</strong>S<strong>of</strong>twareDevelopment 21<br />
architectureconsisting<strong>of</strong>elements,form,<strong>and</strong>rationale. Themodeldistinguishesbetweenthreetypes<strong>of</strong>(design)elements:processing,data,<strong>and</strong><br />
connectingelements.Formincludestherelationshipsamongtheelements<br />
<strong>of</strong>anarchitecture.Rationaleprovidesthemotivationforthedecisionsthat<br />
yieldaparticularset<strong>of</strong>elements<strong>and</strong>form.Thethreeaspects<strong>of</strong>thismodel<br />
fors<strong>of</strong>twarearchitecturecanbefoundinvariousdefinitionsfors<strong>of</strong>tware<br />
architectureusedbylaterresearch(<strong>and</strong>practice).<br />
Garlan<strong>and</strong>Shaw[1993]enumerateaset<strong>of</strong>issuess<strong>of</strong>twarearchitecturesareconcernedwiththatincludesgrossorganisation,globalcontrolstructure,communicationprotocols,<strong>and</strong>assignment<strong>of</strong>functionalitytodesignelements.<br />
Amorerecentdefinition<strong>of</strong>s<strong>of</strong>twarearchitecturecanbefoundinIEEE-<br />
1471[2000]:<br />
Thefundamentalorganisation<strong>of</strong>asystemembodiedinitscomponents,<br />
theirrelationshipstoeachother,<strong>and</strong>totheenvironment,<strong>and</strong>theprinciples<br />
guidingitsdesign<strong>and</strong>evolution.<br />
Thisdefinitionnotonlyincludescomponents(elements)<strong>and</strong>theirrelations,butalsoprinciples,referringto,forinstance,theuse<strong>of</strong>aparticular<br />
architecturalstyle(seeSection2.2.3)ortheuse<strong>of</strong>particularconventions<br />
duringdesign<strong>and</strong>maintenance<strong>of</strong>as<strong>of</strong>twaresystem.<br />
AnalternativedefinitionthatisfrequentlyusedisgivenbyBassetal.<br />
[2003]:<br />
Thes<strong>of</strong>twarearchitecture<strong>of</strong>aprogramorcomputingsystemisthestructureorstructures<strong>of</strong>thesystem,whichcomprises<strong>of</strong>twareelements,theexternallyvisibleproperties<strong>of</strong>thoseelements,<strong>and</strong>therelationshipsamong<br />
them.<br />
This definition acknowledges the now common underst<strong>and</strong>ing that<br />
thereisnosuchthingasthestructure<strong>of</strong>as<strong>of</strong>twaresystem<strong>and</strong>thatdifferenttypes<strong>of</strong>structurescanbeusedtodescribethearchitecture<strong>of</strong>asingle<br />
system.<br />
Kruchten[1998]statesthats<strong>of</strong>twarearchitectureencompassesaset<strong>of</strong><br />
significantdecisionsregardingsystemorganisation,selection<strong>of</strong>elements,<br />
theircomposition,<strong>and</strong>selection<strong>of</strong>anarchitecturalstyletoguidethesedecisions.Inthisdefinition,architectureisthusconsideredasaset<strong>of</strong>decisions,aperspectivefurtherexploredbyJansen[2005].<br />
Insummary,s<strong>of</strong>twarearchitecturecanbeunderstoodinatleasttwo<br />
differentways:1)asaset<strong>of</strong>(architectural)designdecisions,or2)asthe<br />
structurethatistheresult<strong>of</strong>thosedecisions. Inthisthesisweoptfor<br />
thelatter,sinceweonlyconsiders<strong>of</strong>twarestructuresasprescribedbyan<br />
architecturespecificationorasimplementedinsourcecode.<br />
Unfortunately,throughtheuse<strong>of</strong>adjectiveslike“significant”,“fundamental”,“gross”,<strong>and</strong>“global”thedefinitionscitedabovedonotcompletely<br />
clarifywhichparts<strong>of</strong>adesignarearchitectural<strong>and</strong>whichpartsarenot.
22 Chapter2. Background<br />
Moreover,ifas<strong>of</strong>twarearchitectureisaset<strong>of</strong>architecturaldesigndecisions,howdowedeterminewhetheradesigndecisionisarchitectural?<br />
Edenetal.[2006]clarifythisbyprovidingacriterionthatcanbeapplied<br />
todesignstatements.Themathematicallydefinedlocalitycriterionstates<br />
thatadesignstatementislocalifthesystemtowhichitappliescannotbe<br />
madetoviolateitbymereexpansion.<strong>Architectures</strong>tatementsaredefined<br />
tobelongtotheclass<strong>of</strong>non-localstatements.Forinstance,thelayeredarchitecturalstyle<strong>of</strong>as<strong>of</strong>twaresystemcanbeviolatedbysimplyexp<strong>and</strong>ingone<strong>of</strong>thelayerswithacomponentthatinteractswithcomponentsinnonadjacentlayers.<br />
Hence,decisionsregardingstylearearchitectural. Conversely,adesignpatterncannotbeviolatedbyonlyexp<strong>and</strong>ingasystem.<br />
Thus,decisionsregardingdesignpatternsarenotarchitectural.<br />
Despitetheprecisedefinitiondiscussedabove,architectureisarelative<br />
conceptbecause<strong>of</strong>themultiplelevels<strong>of</strong>abstractionatwhichs<strong>of</strong>twaredesigncanbeconsidered.Whatisarchitecturaldependson,amongstothers,<br />
thelevel<strong>of</strong>abstractionthatisconsidered[Monroeetal.,1997;Clements<br />
etal.,2002a]:whatisconsidereddetaileddesignfromamoreabstractlevel<br />
canbeconsideredarchitecturalfromalessabstractlevel.<br />
Fromourcollaborationswithindustryitbecameclearthatinpractice,<br />
architectureis‘defined’differently. There,differentsets<strong>of</strong>decisionsare<br />
consideredtobearchitectural,forinstance,theearliest(intime)decisions,<br />
thedecisionsthataremostdifficult(expensive)tochangelateron,orsimplythedecisionstakenbythes<strong>of</strong>twarearchitect.<br />
Althoughthesesets<br />
mightbeslightlydifferent,inthisthesiswewillassumetheycoincide,takingthepoint<strong>of</strong>view(asstatedabove)thatanarchitectureistheresult<strong>of</strong><br />
suchdecisions.<br />
2.2.2 S<strong>of</strong>twareArchitectureUsage<br />
So,whyisitimportanttoconsiders<strong>of</strong>twarearchitectureasaseparatetype<br />
<strong>of</strong>design?Bassetal.[2003]mentionafewreasons.First,itallowstoset<br />
aparttheglobaldesigndecisions,thatis,thosethataffectmultiplecomponents,<strong>and</strong>henceneedtobecommunicatedtoallinvolveddeveloperstoensuretheconceptualintegrity[Brooks,Jr,1975]<strong>of</strong>thesystemunderdevelopment.<br />
Second,asdesigndecisionsaffects<strong>of</strong>twarequalityattributes,as<strong>of</strong>tware<br />
architectureallowsforearlyqualityassessment<strong>of</strong>(tobedeveloped)s<strong>of</strong>twaresystems.Infact,thes<strong>of</strong>twarearchitectureisthefirstdesignartefact<br />
createdinas<strong>of</strong>twareprojectthatallowsforsuchassessments.<br />
Finally,s<strong>of</strong>twarearchitecturesenablethereuse<strong>of</strong>s<strong>of</strong>twaresolutions.<br />
Bydocumentingas<strong>of</strong>twarearchitecturethedesigndecisionsitcaptures<br />
canbetransferredtoothersystems,forinstance,whensimilarqualityattributerequirementsneedtobefulfilled.
2.2. Architecture-<strong>Driven</strong>S<strong>of</strong>twareDevelopment 23<br />
Thesemotivationsforconsiderings<strong>of</strong>twarearchitecturedesignasaseparatephaseinthes<strong>of</strong>twaredevelopmentprocess,alsoillustratestheimportance<strong>of</strong>s<strong>of</strong>twareevolutiononthearchitecturallevel.Ifs<strong>of</strong>twareiscontinuouslyevolvedonlowerabstractionlevels,phenomenasuchasarchitecture<br />
drift<strong>and</strong>erosion[Perry<strong>and</strong>Wolf,1992](seealsoChapter1),decreasethe<br />
possibility<strong>of</strong>usingthes<strong>of</strong>twarearchitectureinthewaysdescribed.Atthat<br />
point,restoration<strong>of</strong>theintendedarchitectureormigrationtoanewarchitecture,again,bringsthebenefits<strong>of</strong>conceptualintegrity,earlyassessment<br />
<strong>of</strong>designdecisions,<strong>and</strong>reuse.<br />
Withrespecttotheprecedingdiscussionons<strong>of</strong>twarearchitecturethis<br />
thesispositionss<strong>of</strong>twarearchitectureinterms<strong>of</strong>structure<strong>and</strong>architecturalelements.Moreover,consideringtheimportance<strong>of</strong>s<strong>of</strong>twarestructurefors<strong>of</strong>twareevolution(seeSection2.1),weinvestigatehowtouse<strong>and</strong>manipulates<strong>of</strong>twarearchitecturesforthes<strong>of</strong>twareevolutiontasksweidentifiedinSection1.1.<br />
2.2.3 S<strong>of</strong>twareArchitectureDesign<br />
Thegoal<strong>of</strong>s<strong>of</strong>twarearchitecturedesignistodefinetheconstraintsforsubsequentdesign<strong>and</strong>implementationactivitiesthatresultinthedevelopment<strong>of</strong>asystemthatfulfilsitsfunctional<strong>and</strong>otherqualitygoals.Assuch,<br />
as<strong>of</strong>twarearchitectureisbothpermissive<strong>and</strong>restrictivewithrespectto<br />
thedecisionstakeninsubsequentactivities[Perry<strong>and</strong>Wolf,1992].<br />
Basedonexistingdesign<strong>and</strong>evaluationmethods,Kazmanetal.[2006]<br />
formulatethreeprinciplesthatareusefultounderst<strong>and</strong>howarchitectural<br />
constraintsaredefined: 1)anarchitectureshouldbedefinedinterms<strong>of</strong><br />
elementsthatarecoarseenoughforhumanintellectualcontrol<strong>and</strong>specificenoughformeaningfulreasoning,2)businessgoalsdeterminequality<br />
attributerequirements,<strong>and</strong>3)qualityattributerequirementsguidethe<br />
design<strong>and</strong>analysis<strong>of</strong>s<strong>of</strong>twarearchitectures.<br />
Similartootherengineeringdisciplines,theactualdesign<strong>of</strong>s<strong>of</strong>tware<br />
largelyremainsacreativeactivity. Consequently,thesuccess<strong>of</strong>s<strong>of</strong>tware<br />
projectsforalargepartdependsontheexperience<strong>and</strong>skills<strong>of</strong>thes<strong>of</strong>tware<br />
architects. Althoughs<strong>of</strong>twarearchitectureevaluationmethodscanhelp<br />
architectstoassessthequality<strong>of</strong>feredbythearchitecturetheydefined,<br />
suchmethodscanonlybeappliedafterithasbeendesigned.Weintroduce<br />
thesemethodsinSection2.2.5.<br />
Toalsoprovideguidanceduringthedesignprocessitself,theanalysis<br />
<strong>and</strong>codification<strong>of</strong>experiencesbycategorisingproblemtypes<strong>and</strong>recording<br />
<strong>and</strong>generalisingsuccessful(byexperience)solutions,is<strong>of</strong>greatimportance<br />
fors<strong>of</strong>twarearchitecturepractice.S<strong>of</strong>twarearchitecturalstyles,sometimes<br />
alsoreferredtoasarchitecturalpatterns,aresuchcodifications.
24 Chapter2. Background<br />
Anarchitecturalstyleisaset<strong>of</strong>constraintsthatisimposedonthearchitecture<strong>of</strong>systemsthatarebasedonthatstyle.<br />
Assuch,anarchitectural<br />
styledefinesaset<strong>of</strong>architectures. Theconstraintsdefinedbyastylenot<br />
onlylimitthetype<strong>of</strong>architecturalelements<strong>and</strong>theirpossibleconnections,<br />
butalsodictatehowtheirsemanticsshouldbeinterpreted[Abowdetal.,<br />
1993].Shaw<strong>and</strong>Garlan[1996]<strong>and</strong>Buschmannetal.[1996],amongstothers,providecollections<strong>of</strong>sucharchitecturalstyles.Thedefinition<strong>of</strong>architecturalstylesprovidesasharedvocabularyfors<strong>of</strong>twarearchitects.Furthermore,itencouragesresearcherstostudytheproperties<strong>of</strong>particular<br />
stylesinterms<strong>of</strong>qualityattributes.Thisgiveswaytoarchitecturedesign<br />
(<strong>and</strong>evaluation)approachesthatarebasedontheselection<strong>of</strong>appropriatestylesforthedesiredqualityattributes<strong>of</strong>asystem,suchasdescribed<br />
byKleinetal.[1999]<strong>and</strong>byBosch[2000].<br />
Eachstyleoptimisesadistinctset<strong>of</strong>qualityattributes.Inpracticethis<br />
impliestheapplication<strong>of</strong>multiplearchitecturalstylesforthedevelopment<br />
<strong>of</strong>asingles<strong>of</strong>twaresystem. Asaresult,multiplerepresentations<strong>of</strong>such<br />
anarchitectureareconceivable;eachclarifyingaspecificstyle.<br />
2.2.4 S<strong>of</strong>twareArchitectureDescription<br />
Toeffectivelyuse(e.g.,forevaluationormaintenance)thedecisionsthat<br />
compriseas<strong>of</strong>twarearchitectureinnon-trivialprojects,itisrequiredthat<br />
thesedecisionsaredocumentedinausefulway.Forthedescription<strong>of</strong>s<strong>of</strong>twarearchitectureswedistinguishbetweenapproachesbasedon:1)architecturedescriptionlanguages(ADLs)(seeMedvidovic<strong>and</strong>Taylor[1997]for<br />
anoverview),<strong>and</strong>2)views[IEEE-1471,2000].<br />
Alargenumber<strong>of</strong>ADLshavebeendeveloped(mainlybytheresearch<br />
community).Typically,suchADLs<strong>of</strong>feraformalsyntax<strong>and</strong>semanticsfor<br />
thedescription<strong>of</strong>s<strong>of</strong>twarearchitecturesinterms<strong>of</strong>runtimecomponents<br />
(computationalelements)<strong>and</strong>connectors(abstractionsforcomponentinteraction)[Medvidovic<strong>and</strong>Taylor,1997].<br />
Assuch,theyallowtocreate<br />
precisedescriptions<strong>of</strong>oneaspect<strong>of</strong>as<strong>of</strong>twaresystem(i.e.,itsruntime<br />
structure<strong>and</strong>behaviour). Because<strong>of</strong>theformality<strong>of</strong>suchdescriptions,<br />
theycanbeusedtoautomateseverals<strong>of</strong>twareengineeringtasks,suchas<br />
codegeneration<strong>and</strong>verification.<br />
The‘viewsapproach’ontheotherh<strong>and</strong>allowsformorebroaddescriptions<strong>of</strong>s<strong>of</strong>twarearchitecture.Asdiscussedbefore,designcanbeconsideredondifferentlevels<strong>of</strong>abstraction.However,wecanalsoconsiderdesignwithdifferenttypes<strong>of</strong>abstractions.Assuch,aparticularviewmight<br />
onlyconsiderruntime,whichistypicallythecasewithADLs,oronlydesign<br />
timeaspects<strong>of</strong>as<strong>of</strong>twaresystem. Thetypes<strong>of</strong>abstractionactuallyused<br />
canvary<strong>and</strong>aredeterminedbywhatisimportantforaparticulars<strong>of</strong>tware<br />
project.
2.2. Architecture-<strong>Driven</strong>S<strong>of</strong>twareDevelopment 25<br />
Viewsarebasedontheideathatas<strong>of</strong>twarearchitectureistoocomplex<br />
tobedescribedinasinglestroke,orbyonetype<strong>of</strong>abstraction(thatiswhy<br />
wetalkedaboutstructures(plural)before).Multipleviewsarerequiredto<br />
completelydescribe<strong>and</strong>documentas<strong>of</strong>twarearchitecture. Each<strong>of</strong>those<br />
viewsaddressesaspecificset<strong>of</strong>concerns[IEEE-1471,2000]. Theguidelinesforcreatingviewsaredefinedinso-calledviewpoints,oneforevery<br />
type<strong>of</strong>view.Severalsets<strong>of</strong>thoseviewpointshavebeendefined[Kruchten,<br />
1995;H<strong>of</strong>meisteretal.,1999;Clementsetal.,2002a].<br />
Comparedtothe‘ADLapproach’this‘viewsapproach’ismoreadoptedby<br />
industry[Kruchtenetal.,2006],whereaviewtypicallyisadocumentthat<br />
consists<strong>of</strong>somemodelsordiagrams<strong>and</strong>explainingtext,<strong>and</strong>islessformal<br />
thanADL-typedescriptions<strong>of</strong>s<strong>of</strong>twarearchitecture.Whencomparingthe<br />
twoapproaches,itcanbeconcludedthattheADL-approachasinvestigated<br />
bytheresearchcommunityfocusesonin-depthdescription<strong>of</strong>s<strong>of</strong>twarearchitectures,whiletheviews-approachasusedbyindustryfocusesonbroad<br />
description<strong>of</strong>s<strong>of</strong>twarearchitectures[Medvidovicetal.,2002].<br />
Finally,wespecificallymentiontheUnified<strong>Model</strong>ingLanguage 1 (UML).<br />
Although UMLwasoriginallyintendedasalanguageforobject-oriented<br />
modelling<strong>of</strong>systems,ithasbeenusedforarchitecturedevelopmentaswell<br />
(see,forinstance,Chapter3<strong>and</strong>Langeetal.[2006]).Tosomeextentitcan<br />
beusedasanADL[Medvidovicetal.,2002]. Furthermore,UMLdiagrams<br />
are<strong>of</strong>tenusedinarchitectureviews.<br />
Inthisthesis,wemanipulatedifferenttypes<strong>of</strong>architecturalviewsto<br />
supports<strong>of</strong>twareevolution.Insomecases,wealsopartlydemonstratethe<br />
definition<strong>of</strong>newADLs.Asanexample,inChapter5wetransformonetype<br />
<strong>of</strong>viewintoanothertochecktheconsistency<strong>of</strong>behaviouralspecifications<br />
<strong>of</strong>s<strong>of</strong>twareembeddedinthecopiersdevelopedbyOcé.<br />
2.2.5 S<strong>of</strong>twareArchitectureEvaluation<br />
Animportantreasonforexplicitlyconsiderings<strong>of</strong>twarearchitectureasa<br />
separatetype<strong>of</strong>designactivityordocument,isthatitconstitutesthefirst<br />
opportunityfortheprediction<strong>of</strong>properties<strong>of</strong>thesystemunderdevelopment.Wedistinguishbetweentwotypes<strong>of</strong>propertiesorqualities<strong>of</strong>asystem:operationalproperties<strong>and</strong>development(i.e.,non-operational)properties[Bosch,2000].<br />
Thefirsttypeincludesthosepropertiesthatcanbe<br />
measuredbyobservingthesysteminoperation,suchasfunctionality,performance,reliability.Non-operationalproperties,ordevelopmentpropertiesinvolvethedevelopment<strong>of</strong>thesystem,suchas,maintainability,modifiability,portability,developmentcost<strong>and</strong>effort.<br />
1 http://www.uml.org(June2007)
26 Chapter2. Background<br />
Fortheprediction<strong>of</strong>thesepropertiesdifferenttypes<strong>of</strong>approacheshave<br />
beendeveloped[Bosch,2000]. Approachesbasedonmathematicalmodels,suchasrate-monotonicanalysis[Liu<strong>and</strong>Layl<strong>and</strong>,1973]<strong>and</strong>model<br />
checking[Clarke,Jr.etal.,1999],arebestusedforanalysis<strong>of</strong>operational<br />
properties<strong>of</strong>thesystem. ADLsarealsobasedonsuchmodels. Onthe<br />
otherh<strong>and</strong>,scenario-basedapproachessuchas,theS<strong>of</strong>twareArchitecture<br />
AnalysisMethod(SAAM)[Kazmanetal.,1996],theArchitectureTrade<strong>of</strong>f<br />
AnalysisMethod[Clementsetal.,2002b](ATAM),<strong>and</strong>architecture-level<br />
modifiabilityanalysis[Bengtssonetal.,2004](ALMA)(seealsoDobrica<br />
<strong>and</strong>Niemelä[2002]foranoverview<strong>of</strong>scenario-baseds<strong>of</strong>twarearchitecture<br />
analysismethods),arebettersuitedfortheanalysis<strong>of</strong>developmentproperties.Theseapproachesusescenariostomakequalityattributerequirementsconcreteafterwhichthearchitectureisevaluatedforitssupport<br />
fortheidentifiedscenarios.Suchapproachescanbeused,forinstance,to<br />
assessthemaintainability<strong>of</strong>as<strong>of</strong>twaresystem.<br />
InChapter4<strong>of</strong>thisthesiswewillexperimentwithsuchanapproachfor<br />
thescenario-basedevaluation<strong>of</strong>themaintainability<strong>of</strong>s<strong>of</strong>twareembedded<br />
inthecopiersdevelopedbyOcé.<br />
2.2.6 S<strong>of</strong>twareProductLines<br />
One<strong>of</strong>themostimportantpromises<strong>of</strong>theuse<strong>of</strong>architecturalprinciples<br />
forthedevelopment<strong>of</strong>s<strong>of</strong>twaresystemsisthepotentialincrease<strong>of</strong>reuse.<br />
Thisnotonlyincludesreuse<strong>of</strong>designdecisionsbycapturingbestpractices<br />
inarchitecturalstyles,butalso<strong>of</strong>architecturalbuildingblocksbyexplicitly<br />
definingwhatsuchcomponentshaveto<strong>of</strong>fer<strong>and</strong>whattheyrelyon(i.e.,<br />
theirexternalvisibleproperties).<br />
Thelatteruse,however,turnedouttobeproblematicinpracticebecausesomedegree<strong>of</strong>variationistypicallyrequired[Garlanetal.,1995].<br />
Toalsoaccountforvariation<strong>and</strong>notonlyforcommonalities,sets<strong>of</strong>similar<br />
s<strong>of</strong>twareproductscanbeviewedass<strong>of</strong>twareproductfamiliesorproduct<br />
lines.<br />
Aproductlineencompassesawholerange<strong>of</strong>productsthathavemuchin<br />
common.Bydevelopingsuchproductsasas<strong>of</strong>twareproductline[Clements<br />
<strong>and</strong>Northrop,2002]theircommonalities<strong>and</strong>variabilitiesaremadeexplicitinaproduct-linearchitecture.Thedevelopment<strong>of</strong>individualproductsisreducedtobindingthevariationpointsdefinedintheproduct-line<br />
architecturetospecificinstances,thatis,ifallvariabilityismadeexplicit<br />
intheproduct-linearchitecture.<br />
As<strong>of</strong>twareproductlineinvolvesthedevelopment<strong>of</strong>product-lineassets,<br />
suchasaproduct-linearchitecture,reusablecomponents,<strong>and</strong>product-line<br />
members. Theassetsthatapplytotheproductlineasawholearedevelopedinaprocessreferredtoasdomainengineering.Product-linemembers
2.3. <strong>Model</strong>-<strong>Driven</strong>Engineering 27<br />
aredevelopedinaprocesscalledapplicationengineering.<br />
Aproductlinecanbeorderedalongamaturityscalebyconsideringits<br />
(domain)scope,theextentthatcommonalities<strong>and</strong>variabilityaremade<br />
explicit,<strong>and</strong>bindingtime<strong>of</strong>itsvariationpoints[Bosch,2002].Afirststep<br />
onthisscaleisthedefinition<strong>of</strong>allcommonalities<strong>and</strong>theirimplementation<br />
asa(domain-specific)s<strong>of</strong>twareplatform. Product-linemembersarethen<br />
builtontop<strong>of</strong>thatplatform.<br />
Boththesystemsthatarethesubject<strong>of</strong>ourindustrialcasestudies(the<br />
ASMLwaferscanners<strong>and</strong>Océcopiers)aredevelopedusingproduct-line<br />
principles.<br />
2.3 <strong>Model</strong>-<strong>Driven</strong>Engineering<br />
Tohidethestructural<strong>and</strong>behaviouralcomplexity<strong>of</strong>s<strong>of</strong>twareplatforms,<br />
approachestos<strong>of</strong>twaredevelopmenthavebeenintroducedthatarereferred<br />
toasmodel-drivenengineering(MDE)[Schmidt,2006]. WithMDEmodels<br />
arecentralinstead<strong>of</strong>code. Theideaistodevelops<strong>of</strong>twarebytransformingabstractmodelsintomoreconcretemodels<strong>and</strong>eventuallyintocode<br />
thattypicallyrunsontop<strong>of</strong>as<strong>of</strong>twareplatform. Suchtransformations<br />
arereferredtoasmodeltransformations. Becausethesetransformations<br />
areautomated,weareparticularlyinterestedinMDEtechnologiesforthe<br />
support<strong>of</strong>thes<strong>of</strong>twareevolutiontaskswedefined.Furthermore,bothMDE<br />
<strong>and</strong>s<strong>of</strong>twarearchitecturesarebasedonabstractions.<br />
Some<strong>of</strong>thebasicideasbehindMDE,thatis,development<strong>of</strong>s<strong>of</strong>tware<br />
byaseries<strong>of</strong>modeltransformations<strong>and</strong>separation<strong>of</strong>functionalspecificationsfromthetechnicaldetails<strong>of</strong>aspecificplatform,areverysimilartothat<strong>of</strong>stepwiserefinementproposedbyWirth[1971].ManytopicsrelatedtoMDEhavebeenextensivelystudiedbytheresearchcommunity:<br />
s<strong>of</strong>twarereuse[Krueger,1992],generativeprogramming[Horowitz<br />
etal.,1985;Cleavel<strong>and</strong>,1988;Czarnecki<strong>and</strong>Eisenecker,2000],transformationalprogramming[Partsch<strong>and</strong>Steinbrüggen,1983],domain-specificlanguages[VanDeursenetal.,2000;Merniketal.,2005],<strong>and</strong>environments<strong>and</strong>approachesfordevelopment<strong>of</strong>suchlanguages[Klint,1993;Van<br />
Deursenetal.,1996].<br />
Foralargepartthedevelopment<strong>of</strong>currentMDEapproaches,however,<br />
hasbeendrivenbyindustry.Severalimplementations<strong>of</strong>theMDEconcept<br />
areinusetoday.Oftenthesearebasedonproprietaryinfrastructurethat<br />
includesdomain-specific(modelling)languages, applicationframeworks,<br />
codegenerators,<strong>and</strong>modelrepositories(see,e.g.,Doyleetal.[2006]).<br />
Additionally, a set <strong>of</strong> industry st<strong>and</strong>ards for MDE has been defined
28 Chapter2. Background<br />
Metamodel<br />
<strong>Model</strong><br />
System<br />
conforms to<br />
represented by<br />
Figure 2.2:Fundamentalrelationsbetweensystem,model,<strong>and</strong>metamodel[Bézivin,2005]<br />
bytheObjectManagementGroup 1 (OMG)underthename<strong>Model</strong><strong>Driven</strong><br />
Architecture 2 (MDA)<strong>and</strong>numeroustoolsnowsupportpart<strong>of</strong>thesest<strong>and</strong>ards.<br />
Other,non-MDAtoolsareavailablethatalsosupport MDE,such<br />
as Micros<strong>of</strong>t’s Domain-Specific Language Tools based on the approach<br />
byGreenfieldetal.[2004]. Itistheavailability<strong>of</strong>thesest<strong>and</strong>ards,supportingtools,<br />
<strong>and</strong>reusables<strong>of</strong>twareplatformsthatmakesthatcurrent<br />
MDEapproachesgeneratemuchmoreindustrialmomentumthanearlier,<br />
relatedefforts[Schmidt,2006].<br />
Onlyrecently,theresearchcommunityhasstartedinvestigatingthe<br />
fundamentalprinciplesbehindMDE[Bézivinetal.,2007].Thefoundations<br />
for MDEareabstraction(modelling)<strong>and</strong>automation(modeltransformations)[Sendall,2003;Schmidt,2006].<br />
<strong>Model</strong>ling<strong>and</strong>thedefinition<strong>of</strong>the<br />
requiredmodellinglanguagesusing,so-called,metamodelsarebasedon<br />
theconcepts<strong>and</strong>relationsdepictedinFigure2.2. Theyarefundamental<br />
forMDE<strong>and</strong>arethereforeintroducedbrieflyinthefollowingsections.<br />
2.3.1 <strong>Model</strong>ling<br />
Seidewitz[2003]definesamodelasaset<strong>of</strong>statementsaboutasystemunderstudy.Othershaveproposedsimilardefinitionsthataddthatamodel<br />
hasaspecificpurpose[Bézivin<strong>and</strong>Gerbé,2001;OMG,2007a]. Amodel<br />
canbeusedeitherdescriptivelytodetermineproperties<strong>of</strong>asystem,or<br />
prescriptivelyasaspecification<strong>of</strong>asystemtobebuilt[Seidewitz,2003].<br />
Therelationbetweenamodel<strong>and</strong>thesystemunderstudyisreferredtoas<br />
represented by<strong>and</strong>wasdepictedinFigure2.2.<br />
ForMDEapproachestobebeneficialtheinvolvedmodelsshouldbeeasiertocreate<strong>and</strong>underst<strong>and</strong>thanthesystemstheyrepresent,<strong>and</strong>atthe<br />
1 http://www.omg.org(June2007)<br />
2 http://www.omg.org/mda(June2007)
2.3. <strong>Model</strong>-<strong>Driven</strong>Engineering 29<br />
sametimepowerfulenoughto,forexample,generatesourcecode<strong>and</strong>performassessments[Bézivin,2005].Thisrequiresthatmodelsleaveoutdetailsthatareirrelevantfortheirpurpose.Thissimplification(orabstraction)istheessence<strong>of</strong>modelling[Bézivin<strong>and</strong>Gerbé,2001].<br />
Strictlyspeaking,sourcecodeisalsoamodel[Mens<strong>and</strong>VanGorp,2006]<br />
that,withMDE,isthetarget<strong>of</strong>amodeltransformation.Inpractice,however,code<strong>and</strong>modelsare<strong>of</strong>tenconsideredtobedifferenttypes<strong>of</strong>artefacts.<br />
Typically,ins<strong>of</strong>twareengineeringpractice<strong>and</strong>inparticularinthecontext<br />
<strong>of</strong>MDEsomethingisconsideredtobeamodelifithasagraphicalrepresentationinstead<strong>of</strong>onlyatextualoneasinthecaseforsourcecode[Mellor<br />
etal.,2003;Bézivin,2006].<br />
Kleppeetal.[2003]addanotherelementtothedefinition<strong>of</strong>amodelby<br />
statingthatamodeliswritteninawell-definedlanguage. Thus,forthe<br />
creation<strong>of</strong>modelsmodellinglanguagesarerequired. Basicallytwotypes<br />
<strong>of</strong>suchlanguagesexist: general-purposelanguages(GPLs)<strong>and</strong>domainspecificlanguages(DSLs).<br />
UMLisanexample<strong>of</strong>alanguageintheMDA<br />
framework<strong>of</strong>theformertype.Itisappliedinmanydifferentdomains<strong>and</strong><br />
formanydifferentpurposes. Thelattertype<strong>of</strong>languagesis<strong>of</strong>tenspecificallydefined.<br />
Inthisthesisthes<strong>of</strong>twareevolutiontaskswedefinedareappliedto<br />
modelsasinthecontext<strong>of</strong>MDE. Tothisend,wenotonlyuseUML,but<br />
also(domain-specific)languageswedefinedourselvesusingtheMetaObject<br />
Facility 1 (MOF),themetamodellinglanguagedefinedbytheOMG.<br />
2.3.2 Metamodelling<br />
WithMDE,themodellinglanguagesusedtocreatemodelsaredefinedby<br />
metamodels. Ametamodelisagraphcomposed<strong>of</strong>concepts<strong>and</strong>theirrelationships.Fromausageperspectiveametamodeldetermineswhichaspects<strong>of</strong>asystemwillbemodelledinacorrespondingmodel[Bézivin,2006].<br />
Ametamodelisamodelitself,thatis,amodel<strong>of</strong>alanguage.Assuch,a<br />
metamodelis,inturn,createdusingamodellinglanguage.Themetamodel<br />
usedtodefinethismetamodellinglanguageisreferredtoasthemetametamodel.<br />
Thismetametamodelisdefinedreflectivelybyusingthelanguage<br />
itdefinesitself.Thisyieldsalayeredstructure(architecture)<strong>of</strong>modelsas<br />
depictedinFigure2.3onthenextpagethatistypicalforMDEapproaches.<br />
Itisbasedonthetw<strong>of</strong>undamentalrelations(represented by<strong>and</strong> conforms to)<br />
<strong>and</strong>concepts(system<strong>and</strong> model)<strong>of</strong>Figure2.2. ForstructuresasinFigure2.3onthenextpagethatmodelMDEconcepts,suchassystem,model,<br />
<strong>and</strong>metamodel,thetermmegamodelwasintroduced[Bézivinetal.,2005;<br />
Favre,2005b].<br />
1 http://www.omg.org/m<strong>of</strong>(June2007)
30 Chapter2. Background<br />
conforms to<br />
conforms to<br />
represented by<br />
Metametamodel<br />
Metamodel<br />
<strong>Model</strong><br />
System<br />
conforms to<br />
model world<br />
real world<br />
Figure 2.3:LayeredMDEmodellingstack<br />
Therelationbetweenamodelelement<strong>and</strong>acorrespondingmetamodel<br />
element(i.e.,onahighermodellevel)hastobedistinguishedfromthe<br />
instance-<strong>of</strong>relationthatexistsbetweenatype<strong>and</strong>aninstance<strong>of</strong>thattype<br />
withinthesamemodellinglevel.Inpracticetheseare<strong>of</strong>tenconfused.Asan<br />
example,considerFigure2.4. Themetamodelisasimplifiedfragment<strong>of</strong><br />
theUMLmetamodel.Itdefinesamodellinglanguagethatallowstocreate<br />
modelsconsisting<strong>of</strong>objects<strong>and</strong>classesthatcanberelatedtoeachotherby<br />
the instance-<strong>of</strong>relation.Thesemetamodelelementscanbeusedtocreatea<br />
model<strong>of</strong>someapplication,forinstance,todefineaClass Person<strong>and</strong>aninstance<strong>of</strong>that<br />
Class: Object joe.Boththerelationsbetween Class<strong>and</strong> Person<br />
<strong>and</strong> Person<strong>and</strong> joeare instance-<strong>of</strong>relations.However,theyare<strong>of</strong>adifferent<br />
nature. Therefore,Atkinson<strong>and</strong>Küne[2003]distinguishbetweenalinguistic(between<br />
Class<strong>and</strong> Person)<strong>and</strong>anontological(between Person<strong>and</strong><br />
joe)instance-<strong>of</strong>relation.Similarly,Bézivin<strong>and</strong>Gerbé[2001]usesadifferenttermforthelinguisticinstance-<strong>of</strong>relationbyreferringtoitasmeta.<br />
Notethatthe conforms torelationdepictedinFigure2.3effectivelysummarisesmetarelationsbetweenindividualmodel<strong>and</strong>metamodelelements:<br />
amodelconformstoametamodelif<strong>and</strong>onlyifallitsmodelelementshave<br />
ametarelationwithanelementdefinedinthatmetamodel[Bézivin,2006].<br />
Favre[2005a]usessettheorytoexplainthatthe conforms torelation<br />
betweenamodel<strong>and</strong>itsmetamodelisactuallyaderivedrelationasillustratedbyFigure2.5.<br />
Ifweconsideramodellinglanguageastheset<strong>of</strong><br />
modelsexpressedinthatlanguage,therelationbetweenamodel<strong>and</strong>the<br />
modellinglanguageisthe element <strong>of</strong>relationfromsettheory.Whenwealso<br />
considerthemodellinglanguageasthesystemunderstudy,themodelling<br />
languageis,inturn,relatedtothemetamodelbythe represented byrelation.
2.3. <strong>Model</strong>-<strong>Driven</strong>Engineering 31<br />
metamodel<br />
model<br />
Class<br />
instance−<strong>of</strong><br />
Object<br />
+ class<br />
instance−<strong>of</strong><br />
instance−<strong>of</strong><br />
Person joe : Person<br />
instance−<strong>of</strong><br />
Figure 2.4:Metamodel<strong>and</strong>conformingmodel<br />
element <strong>of</strong><br />
Language<br />
<strong>Model</strong><br />
represented by<br />
conforms to<br />
Metamodel<br />
Figure 2.5:ConformstorelationinMDE<br />
instance−<strong>of</strong>
32 Chapter2. Background<br />
In the case <strong>of</strong> MDA, MOF is the metametamodel. MOF defines the<br />
(meta)modelelementsnecessarytodefinemodellinglanguages,suchas,<br />
class,association,<strong>and</strong>constraint. Metamodellingissimilartodatamodelling<strong>and</strong>objectmodelling.<br />
Assuch, MOFmodelsaresimilartoentityrelationshipmodels[Chen,1976]<strong>and</strong>,inparticular,toUMLclassmodels.<br />
Similarlytogrammars, MOFisusedtodefinetheabstractsyntax<strong>of</strong><br />
modellinglanguages,thatis,thestructure<strong>of</strong>correspondingmodels. As<br />
anexample,theUMLmetamodelisnowalsodefinedusingMOF. Where,<br />
with(context-free)grammars,theabstractsyntaxdefinesaset<strong>of</strong>abstract<br />
syntaxtrees,aMOFmetamodeldefinesaset<strong>of</strong>abstractsyntaxgraphs.In<br />
contrastwithgrammars,MOFcannotbeusedtodefinetheconcretesyntax,<br />
thatis,thenotation,<strong>of</strong>amodellinglanguage. Inthecase<strong>of</strong>UML,forinstance,thenotationsusedinthedifferentdiagramsaredefinedseparately.<br />
InChapter8,weproposealight-weightsolutiontothisproblem.<br />
Severalimplementations<strong>of</strong> MOFexist. Theseallowthedefinition<strong>of</strong><br />
metamodels <strong>and</strong> the creation <strong>of</strong> conforming models in the Extensible<br />
MarkupLanguage 1 (XML)orasobjectsinmemory. Suchimplementationsareused,forinstance,forthedevelopment<strong>of</strong>modeltransformation<br />
tools. Asanexample,theEclipse<strong>Model</strong>ingFramework 2 (EMF)isapluginforEclipse<br />
3 thatisbasedonMOF. GivenametamodelEMFgenerates<br />
animplementation<strong>of</strong>thatmetamodel(inJava)thatcanbeextendedto<br />
developtoolsbasedonthatmetamodel,suchasamodeleditor.<br />
ForaparticularMDEapproachthemetamodellinglanguagecanbeused<br />
todefineawholeclass<strong>of</strong>modellinglanguages.Havingasinglemetamodellinglanguagealsoenablesthedevelopment<strong>of</strong>modeltransformationlanguages<strong>and</strong>supportingtools.<br />
Inseveral<strong>of</strong>thisthesis’chapterswecreatedmetamodels.InChapter6,<br />
forinstance,wedefinedasimplemodellinglanguagetorepresentmodularisationconstructs,suchasclass<strong>and</strong>module;inChapter7,wedefinedametamodelforthespecification<strong>of</strong>task-resourcemodelsforcontrolcomponentsinmanufacturingmachines.<br />
2.3.3 <strong>Model</strong>Transformations<br />
<strong>Model</strong>transformationsareessentialtoMDE[Gerberetal.,2002;Sendall,<br />
2003]. Atransformationdefinitiondescribesmappingsortransformation<br />
rulestotransformelements<strong>of</strong>asourcemodelintoelements<strong>of</strong>atarget<br />
model[Kleppeetal.,2003].Oftenmodeltransformationlanguagesuseex-<br />
1 http://www.w3.org/XML(June2007)<br />
2 http://www.eclipse.org/emf(June2007)<br />
3 Eclipseisawidely-used,freely-available,open-sourceintegrateddevelopmentenvironment,seehttp://www.eclipse.org(June2007)
2.3. <strong>Model</strong>-<strong>Driven</strong>Engineering 33<br />
conforms to<br />
conforms to<br />
Metamodel<br />
+ source<br />
<strong>Model</strong><br />
Metametamodel<br />
conforms to<br />
TransformationMetamodel<br />
+ source<br />
Transformation<strong>Model</strong><br />
Transformation<br />
conforms to<br />
Metamodel<br />
+ target<br />
represented by<br />
<strong>Model</strong><br />
Figure 2.6:<strong>Model</strong>transformationmegamodel<br />
conforms to<br />
conforms to<br />
+ target<br />
pressionsintheObjectConstraintLanguage 1 (OCL)toselecttheelements<br />
inthesourcemodeltotransform.OCLisadeclarativelanguage,originally<br />
developedtospecifyconstraintsoverUMLmodels.<br />
TheMDEpatternormegamodelformodeltransformationsisdepicted<br />
inFigure2.6[Bézivinetal.,2005]. WithMDEaTransformationbetweena<br />
source<strong>and</strong>target <strong>Model</strong>isdefinedbyatransformationlanguage. When<br />
thislanguageisdefinedbyaTransformation<strong>Model</strong>Metamodel,thetransformationdefinitionisinfactamodelitself.<br />
This Transformation<strong>Model</strong>specifies<br />
transformations<strong>of</strong>sourceintotargetmodelsinterms<strong>of</strong>the Metamodels<br />
they conform to. Incorrespondencewiththemetamodellingmegamodelin<br />
Figure2.3onpage30,allinvolvedmetamodels conform toasingle Metametamodel.<br />
Atransformationengine(automatically)transformssourcemodelsthat<br />
conformtothesourcemetamodelintotargetmodelsthatconformtothe<br />
targetmetamodelasdescribedinthetransformationdefinition. Assuch,<br />
transformationenginesrequireseveralinputs:sourcemodel,sourcemetamodel,targetmetamodel,<strong>and</strong>transformationdefinition.<br />
Many different types <strong>of</strong> model transformations <strong>and</strong> model transformationlanguagesareconceivable.<br />
Sendall[2003];Czarnecki<strong>and</strong>Helsen<br />
[2006];<strong>and</strong>Mens<strong>and</strong>VanGorp[2006]eachgiveanumber<strong>of</strong>properties<br />
<strong>of</strong>modeltransformationlanguages. Theseincludethetype<strong>and</strong>number<br />
<strong>of</strong>source<strong>and</strong>targetmodels,horizontalvs. verticaltransformations(with<br />
respecttoabstractionlevel),type<strong>of</strong>notation(e.g.,graphicalvs. textual),<br />
source-targetrelationship(newvs.in-place),<strong>and</strong>manymore.<br />
1 http://www.omg.org/technology/documents/modeling_spec_catalog.htm#OCL(June2007)
34 Chapter2. Background<br />
Class<strong>Model</strong> + classes<br />
1..*<br />
+ attributes * * + operations<br />
Attribute<br />
Operation<br />
−name :String<br />
−visibility :String<br />
Class<br />
−name :String<br />
−name :String<br />
Figure 2.7:Ametamodelforsimpleclassmodels<br />
ATL: amodeltransformationlanguage InthisthesiswemainlyusetheAtlasTransformationLanguage[Jouault<strong>and</strong>Kurtev,2005](ATL)tospecifymodeltransformations.Although,ATLisprimarilyadeclarativemodel<br />
transformationlanguage(basedonOCL),italsohasimperativefeatures.<br />
AnimportantreasonsforusingATLisitsimplementationinatoolkitthat<br />
includesaneditor,debugger<strong>and</strong>transformationenginethatisfreelyavailable.Furthermore,thistoolkitintegrateswithEMF<strong>and</strong>other(UML)tooling.Thisallowstheuse<strong>of</strong>UMLmodelsaswellasmodelsbasedoncustom<br />
(MOF-based)metamodels.Here,webrieflyintroduceATL 1 asanexample<strong>of</strong><br />
amodeltransformationlanguage.<br />
Asillustrativeexample,wediscussthetransformationinListing2.1<br />
thataddsgetters<strong>and</strong>setterstoasimpleclassmodel.Figure2.7depictsa<br />
metamodelforsimpleclassmodels. Itcontainsarootelement Class<strong>Model</strong><br />
thatownsanynumber<strong>of</strong> classes. Inturn,aClass,ownsanumber<strong>of</strong> attributes<strong>and</strong><br />
operations. Class, Attribute,<strong>and</strong> Operationallhaveanamefeature.<br />
Additionally,an Attributealsohasafeature visibility.<br />
<strong>Model</strong>transformationsarespecifiedinanATLModulethatiscomposed<br />
<strong>of</strong>aheader,transformationrules<strong>and</strong>so-calledhelpers. AsinListing2.1,<br />
theheaderspecifiesthenamesforthesourcemodels(IN),targetmodels<br />
(OUT),<strong>and</strong>metamodels(CLASSM)thatareusedinthedefinition<strong>of</strong>transformationrules<strong>and</strong>helpers.<br />
AdeclarativetransformationruleiscalledamatchedruleinATL. It<br />
specifiesasource<strong>and</strong>targetpattern,indicatedbythefrom<strong>and</strong>toblocks,<br />
respectively.Thesourcepatternspecifiesthetype<strong>of</strong>modelelementsthat<br />
arematchedbytherule.Optionally,thesourcepatternmayspecifyaguard<br />
intheform<strong>of</strong>aBooleanOCLexpressionthatfurtherconstraintstheset<br />
<strong>of</strong>elementsthatarematched. Forinstance,inthe PrivateAttributerule<br />
(lines31–40),thesourcepattern(a_in)specifiesthattherulematcheselements<strong>of</strong>type<br />
Attributeforwhichthe privatehelperevaluatestotrue.<br />
1 Please,consulttheATLUserManual[ATLASgroup]formoredetailedinformation
2.3. <strong>Model</strong>-<strong>Driven</strong>Engineering 35<br />
1module ADDGETSET;<br />
2create OUT : CLASSM from IN : CLASSM;<br />
3<br />
4helper context CLASSM!Attribute def: isPrivate: Boolean =<br />
5 self.visibility = ’private’;<br />
6<br />
7rule Class<strong>Model</strong> {<br />
8 from cm_in:CLASSM!Class<strong>Model</strong><br />
9 to<br />
10 cm_out:CLASSM!Class<strong>Model</strong> (is<br />
11 classes union(c_in.attributes->select(a|a.isPrivate)->collect(a|<br />
thisModule.resolveTemp(a,’set’)))<br />
23 )<br />
24}<br />
25rule Attribute {<br />
26 from a_in:CLASSM!Attribute (not a_in.private)<br />
27 to<br />
28 a_out:CLASSM!Attribute (<br />
29 name
36 Chapter2. Background<br />
Thetargetpattern<strong>of</strong>atransformationrulemayconsist<strong>of</strong>multipletargetpatternelements.Eachelementspecifiesthecreation<strong>of</strong>amodelelementinthetargetmodel.<br />
Atargetpatternelementspecifiesthetype<strong>of</strong><br />
thecreatedelement<strong>and</strong>aset<strong>of</strong>bindingsthatspecifieshowthefeatures<br />
<strong>of</strong>thecreatedmodelelementwillbeinitialised.The PrivateAttributerule<br />
createsthreeelementsinthetargetmodelbyitstargetpatternelements:<br />
anAttribute(a_out)<strong>and</strong>twoOperations(get<strong>and</strong>set).Theirbindingsrefer<br />
tothematchedsourcemodelelement(a_in)toinitialisethe namefeature<strong>of</strong><br />
thecreatedtargetmodelelements.<br />
WithATL,thesourcemodelisread-only<strong>and</strong>thetargetmodeliswriteonly.Toinitialisethefeatures<strong>of</strong>targetmodelelements,theATLtransformationengineappliesaspecificvalueresolutionalgorithm.Whenthetype<br />
<strong>of</strong>theexpression<strong>of</strong>abindingisaprimitivetype(e.g., c_in.nameinline18)<br />
orwhenitsvalueisanothertargetpatternelement<strong>of</strong>thesamerule,itis<br />
simplyassigned.Whenthevalueisa(set<strong>of</strong>)sourcemodelelement(s)itis<br />
firstresolvedintoatargetmodelelement(e.g., c_in.attributesinline19).<br />
Effectively,thetargetmodelelementcreatedbytherulethatmatchesthe<br />
sourcemodelelementspecifiedinthebinding’sexpressionisassigned.<br />
Inthecasethatthematchingrulespecifiesmultipletargetpatternelementsthedefault(i.e.,thefirst)targetpatternelementisused.Whenthis<br />
isnotdesirable,ATL<strong>of</strong>fersthe resolveTempoperationthatcanbeusedto<br />
resolvesourcemodelelementsusingnon-defaulttargetpatternelements.<br />
Tothisend,ittakesthesourcemodelelementtoberesolved<strong>and</strong>thename<br />
<strong>of</strong>thetargetpatternelementasparameters.<br />
Asanexample,weexplainhowtheoperationsfeature<strong>of</strong>atargetClass<br />
isinitialisedbythe Classruleinlines20–22. Usingst<strong>and</strong>ardOCLoperationstheexpression<strong>of</strong>thebindingsspecifiestheunion<strong>of</strong>theoperations<br />
alreadypresentinthematchingClass(c_in.operations)<strong>and</strong>thegetters<br />
<strong>and</strong>settersgeneratedforprivateAttributes. Wespecifythegettersby<br />
firstselectingfromallattributes<strong>of</strong>thematchingClass(c_in.attributes)<br />
thosethatareprivateusingone<strong>of</strong>OCL’siterators(->select(a|a.isPrivate<br />
)). Subsequently,fortheresultingAttributeswecollectthecreatedtargetelementsusingthe<br />
’get’targetpatternelement<strong>of</strong>thematchingrule<br />
(->collect(a|thisModule.resolveTemp(a,’get’).Wespecifythecreatedsetterssimilarly.Ahelpermaybedefinedinthecontext<strong>of</strong>somesourcemetamodelelement.Assuch,iteffectivelyaddsafeaturetosuchanelement.Forexample,the<br />
isPrivatehelper(lines4–5)isdefinedinthecontext<strong>of</strong>Attributes.<br />
ItevaluatestotrueforeveryAttributeforwhichitsvisibilityfeatureisset<br />
tothestring ’private’. Thishelperisanexample<strong>of</strong>aso-calledattribute<br />
helper. Suchhelpersdonottakeparameters<strong>and</strong>areevaluatedonlyonce<br />
foreverysourcemodelelement.Operationhelpers,ontheotherh<strong>and</strong>,may<br />
takeparameters<strong>and</strong>havetobeevaluateduponeachcall.Finally,byomit-
2.3. <strong>Model</strong>-<strong>Driven</strong>Engineering 37<br />
tingthecontextfromthedefinition<strong>of</strong>ahelperitisdefinedinthecontext<strong>of</strong><br />
thetransformationmoduleasawhole,whichisrepresentedbythebuilt-in<br />
thisModuleelement.<br />
Inadditiontothe(declarative)featuresexplainedabove,ATL<strong>of</strong>fersa<br />
number<strong>of</strong>additionalfeaturesthatweonlymentionbriefly. Nexttothe<br />
simpletargetpatternelementsinListing2.1thatgenerateasingletargetmodelelement,iterativetargetpatternelementsthatiterateoversome<br />
collectioncanbeusedtocreateawholeset<strong>of</strong>targetmodelelementsfora<br />
singlematchingsourcemodelelement.ATLalso<strong>of</strong>fersimperativefeatures<br />
thatmakeitpossibletoaddimperativeinstructionstomatchedrules.Finally,apartfrommatchedrules,itispossibletodefine(imperative)rulesthatarenotmatchedbysourcemodelelements,butthatarecalledexplicitly.Assuch,thesecalledrulesdonothaveasourcepattern.<br />
2.3.4 MDE<strong>and</strong>OtherTechnologicalSpaces<br />
Asdiscussedabove,abstraction<strong>and</strong>automationaremadepossibleinMDE<br />
bytheuse<strong>of</strong>metamodels. However,othersolutionsexistaswell. Asan<br />
example,modellinglanguagescanalsobedefinedusinggrammarsorXML<br />
schemas. ThelayeredstructuredepictedinFigure2.3onpage30canbe<br />
recognisedwhenusingthesealternativesaswell,forinstance,inthecase<br />
<strong>of</strong>grammars,EBNFisonthemetametamodellevel,grammarsareonthe<br />
metamodellevel,<strong>and</strong>programsonthemodellevel.<br />
Suchdifferenttypes<strong>of</strong>solutionseachcomewithawholecontext<strong>of</strong>concepts,abody<strong>of</strong>knowledge,requiredskills,<strong>and</strong>possibilities.Kurtevetal.<br />
[2002]coinedthetermtechnologicalspaceforsuchacontext.Assuch,the<br />
MDEspaceincludesmodels,metamodels,modeltransformations,modelling<br />
tools<strong>and</strong>transformationlanguages.Thisspaceisalsoreferredtoasmodelware.Similarly,thegrammarspace,orgrammarware[Klintetal.,2005],includesprograms,programminglanguages,grammars,parsers,<strong>and</strong>programtransformationsystems(e.g.,V<strong>and</strong>enBr<strong>and</strong>etal.[2001];Visser<br />
[2004]). Otherrecognisedtechnologicalspacesarebasedon XMLorontologies,forinstance.Specificoperationsonaparticulartype<strong>of</strong>modelsmightbemoreconvenientinonetechnologicalspacethanintheother.<br />
Forthisreasonit<br />
canbenecessarytocreateabridgebetweendifferenttechnologicalspaces.<br />
InChapter6,forinstance,weusedabridgebetweenthemodelware<strong>and</strong><br />
grammarwaretechnologicalspacetovisualiseMDAmodelsusingagraph<br />
visualisationtoolthathasagrammar-basedinputlanguage.<br />
AnotherbridgethatisveryimportanttoMDAisXMLMetadataInterchange<br />
1 (XMI). Thisbridgemakesitpossibletoserialisemodelsbasedon<br />
1 http://www.omg.org/mda/specs.htm#XMI(June2007)
38 Chapter2. Background<br />
abstraction type<br />
abstraction level<br />
evolution<br />
Figure 2.8:Three-dimensionalevolutionframework<br />
MOFmetamodelsas XMLdocuments. Assuch, XMIisusedtoexchange<br />
modelsbetweentools,forinstance,betweenmodelling<strong>and</strong>transformation<br />
tools.<br />
Inthisthesiswemainlyusetechnologiesrelatedto MDA, OMG’ssolution<br />
to MDE. It is a set <strong>of</strong> st<strong>and</strong>ards that includes capabilities for<br />
modelling(e.g., UML),metamodelling(MOF),<strong>and</strong>modeltransformations<br />
(Query/View/Transformation[OMG,2005](QVT)). Theadvantage<strong>of</strong>such<br />
st<strong>and</strong>ards is that they make it worthwhile for tool vendors to develop<br />
toolsthatsupportMDAtechnology[Boochetal.,2004],suchasArcStyler 1<br />
(InteractiveObjects)<strong>and</strong>Borl<strong>and</strong>Together 2 Onlywhensupportingtools<br />
areavailableaninitiativeastheMDAcanbecomeasuccessinpractice.<br />
ToolsthatsupportUMLmodellinghavebeenavailableforquitesometime,<br />
butnowalsotoolsbecomeavailablesupportingmetamodelling<strong>and</strong>model<br />
transformations 3 .<br />
2.4 <strong>Model</strong>-<strong>Driven</strong><strong>Evolution</strong><strong>of</strong>S<strong>of</strong>tware<strong>Architectures</strong><br />
Inthisthesisweinvestigatethemodel-drivenevolution<strong>of</strong>s<strong>of</strong>twarearchitectures.<br />
Weconcludethischapterbyexplaininginthissectionwhywe<br />
thinkthismakessense.<br />
Firstly,asexplainedinSection2.2.4,architecturesare<strong>of</strong>tendescribed<br />
usingmultipleviewseachaddressingaspecificset<strong>of</strong>concerns. Forarchitecturalviewsabstractionplaystworoles:thelevel<strong>of</strong>abstraction,<strong>and</strong><br />
thetype<strong>of</strong>abstraction,whichreferstothetype<strong>of</strong>theview(i.e.,theview-<br />
1 http://www.interactive-objects.com/products/arcstyler(September2007)<br />
2 http://www.borl<strong>and</strong>.com/us/products/together/(September2007)<br />
3 Seehttp://planetmde.org/tools(June2007)foranoverview<strong>of</strong>MDA<strong>and</strong>MDEtools.
2.4. <strong>Model</strong>-<strong>Driven</strong><strong>Evolution</strong><strong>of</strong>S<strong>of</strong>tware<strong>Architectures</strong> 39<br />
point[IEEE-1471,2000]). Suchaviewiscentredaroundamodel. Often<br />
thisisamodelinageneralsense,thatis,itisasimplifiedrepresentation<strong>of</strong>thesystemfromaspecificperspective.Inpracticesuchamodelcan<br />
beadrawingorsketchthatisnotbasedonadefinedmodellinglanguage.<br />
InthisthesisweattempttoconsiderthosemodelsinamorespecificMDE<br />
sense,thatis,modelsconformingtoametamodel. Usingthisperspective<br />
itbecomespossibletosupportours<strong>of</strong>twareevolutiontasksbymodeltransformations.<br />
Byconsiderings<strong>of</strong>twareevolutionasdrivenbyortheresult<strong>of</strong>model<br />
transformations,webasicallyaddadimensionalongwhichmodelscanbe<br />
transformedtothetwodimensionsidentifiedinSection2.2.4(type<strong>and</strong><br />
level<strong>of</strong>abstraction). Thisresultsinathree-dimensionalframeworkwith<br />
twoabstractionaxes(onefortype<strong>and</strong>oneforlevel<strong>of</strong>abstraction)<strong>and</strong>one<br />
evolutionaxis.<strong>Model</strong>saretransformedinadevelopment(abstractionlevel)<br />
directionaswellasinan(orthogonal)evolutiondirection. Athirdaxis<br />
indicatesthedifferenttypes<strong>of</strong>abstractions(views)used(seeFigure2.8).<br />
Secondly,theuse<strong>of</strong>product-lineprinciplescanbenefitespeciallyfrom<br />
MDEapproaches[Schmidt,2006]. S<strong>of</strong>twareproductlinesaretypically(at<br />
least)basedonaplatform[Bosch,2002],aset<strong>of</strong>s<strong>of</strong>twarecomponentscommontoallproduct-linemembers.<br />
MDEapproachesareparticularlysuited<br />
tobeappliedtogeneratecodeforsuchplatformsbyapplication<strong>of</strong>model<br />
transformations. Wealsoapplythesemodeltransformationstosupport<br />
ourevolutiontasksinthecase<strong>of</strong>anevolvingproductlinearchitecture,or<br />
platform.<br />
Forthesereasonsthisthesisexplorestheevolution(discussedinSection2.1)<strong>of</strong>s<strong>of</strong>twarearchitectures(Section2.2)usingmodel-driventechniques(Section2.3).
Chapter3<br />
Embedded-S<strong>of</strong>tware Engineering:<br />
The State <strong>of</strong> the Practice 1<br />
Theembedded-s<strong>of</strong>twaremarkethasgrownveryfastthelastdecade<strong>and</strong>will<br />
continuetodosointhecomingyears. Thespecificproperties<strong>of</strong>embedded<br />
s<strong>of</strong>tware,suchashardwaredependencies,makeitsdevelopmentdifferent<br />
fromnon-embeddeds<strong>of</strong>tware. Thereforeweexpectedveryspecifics<strong>of</strong>tware<br />
developmenttechnologiestobeusedinthisdomain.Theinventoryweconductedatseveralembedded-s<strong>of</strong>tware-developmentcompaniesinEuroperemarkablyshowsthatthisisnottrue.Howevertheinventoryresultsconcerningrequirementsengineering<strong>and</strong>architecturedesignatthesecompaniesdosuggestthatthereisaneedformorespecificallyaimeddevelopmenttechnologies.Thischapterpresentstheinventoryresults<strong>and</strong>identifiespossibilitiesforfutureresearchtocustomiseexisting<strong>and</strong>developnews<strong>of</strong>tware<br />
developmenttechnologiesfortheembedded-s<strong>of</strong>twaredomain.<br />
3.1 Introduction<br />
Manyproductstodaycontains<strong>of</strong>tware(e.g.,mobiletelephones,DVDplayers,cars,aeroplanes,<strong>and</strong>medicalsystems).<br />
Because<strong>of</strong>advancementsin<br />
information<strong>and</strong>communicationtechnology,inthefutureevenmoreproductswilllikelycontains<strong>of</strong>tware.Themarketforthese‘enhanced’productsisforecastedtogrowexponentiallyinthenext10years[PROGRESS,<br />
2002]. Moreover,theseembedded-systems’complexityisincreasing,<strong>and</strong><br />
theamount<strong>and</strong>variety<strong>of</strong>s<strong>of</strong>twareintheseproductsaregrowing. This<br />
createsabigchallengeforembedded-s<strong>of</strong>twaredevelopment. Intheyears<br />
1 Thischapterwaspublishedearlieras:Graaf,Bas,MarcoLormans,<strong>and</strong>HansToetenel.<br />
Embeddeds<strong>of</strong>twareengineering:Thestate<strong>of</strong>thepractice. IEEES<strong>of</strong>tware,20(6):pages<br />
61–69,2003<br />
41
42 Chapter3. State<strong>of</strong>thePractice<br />
tocome,thekeytosuccesswillbetheabilitytosuccessfullydevelophighqualityembeddedsystems<strong>and</strong>s<strong>of</strong>twareontime.Asthecomplexity,number,<strong>and</strong>diversity<strong>of</strong>applicationsincrease,more<strong>and</strong>morecompaniesare<br />
havingtroubleachievingsufficientproductquality<strong>and</strong>timelydelivery.To<br />
optimisethetimeliness,productivity,<strong>and</strong>quality<strong>of</strong>embedded-s<strong>of</strong>twaredevelopment,companiesmustapplys<strong>of</strong>twareengineeringtechnologiesthat<br />
areappropriateforspecificsituations.<br />
Unfortunately,themanyavailables<strong>of</strong>twaredevelopmenttechnologies<br />
don’ttakeintoaccountthespecificneeds<strong>of</strong>embedded-systemsdevelopment.<br />
This development is fundamentally different from that <strong>of</strong> nonembeddedsystems.Technologiesforthedevelopment<strong>of</strong>embeddedsystemsshouldaddressspecificconstraintssuchashardtimingconstraints,limitedmemory<strong>and</strong>poweruse,predefinedhardwareplatformtechnology,<strong>and</strong>hardwarecosts.Existingdevelopmenttechnologiesdon’taddresstheirspecificimpacton,ornecessarycustomisationfor,theembeddeddomain.Nor<br />
dothesetechnologiesgivedevelopersanyindication<strong>of</strong>howtoapplythem<br />
tospecificareasinthisdomain–forexample,automotivesystems,telecommunications,orconsumerelectronics.Consequently,tailoringatechnology<br />
foraspecificuseisdifficult.Furthermore,theembeddeddomainisdriven<br />
byreliabilityfactors,costfactors,<strong>and</strong>timetomarket. So,thisembedded<br />
domainneedsspecificallytargeteddevelopmenttechnologies.<br />
Inindustry,thegeneralfeelingisthatthecurrentpractice<strong>of</strong>embeddeds<strong>of</strong>twaredevelopmentisunsatisfactory.However,changestothedevelopmentprocessmustbegradual;adirectionmustbesupplied.<br />
Toachieve<br />
this,weneedmoreinsightintothecurrentlyavailable<strong>and</strong>currentlyused<br />
methods,tools,<strong>and</strong>techniquesinindustry.<br />
Togainsuchinsight,weperformedanindustrialinventoryaspart<strong>of</strong>the<br />
S<strong>of</strong>twareEngineeringMethOdOlogieSforEmbeddedSystems 1 (MOOSE)<br />
project. MOOSEispart<strong>of</strong>theInformationTechnologyforEuropeanAdvancement<br />
2 (ITEA)programme<strong>and</strong>isaimedatimprovings<strong>of</strong>twarequality<br />
<strong>and</strong>developmentproductivityforembeddedsystems.Notonlydidwegain<br />
anoverview<strong>of</strong>whichtechnologiestheMOOSEconsortium’sindustrialpartnersuse,wealsolearntwhytheyuseordon’tusecertaintechnologies.In<br />
addition,wegainedinsightintowhatcurrentlyunavailabletechnologies<br />
mightbehelpfulinthefuture.<br />
3.2 Methods<strong>and</strong>Scope<br />
Theinventoryinvolvedsevenindustrialcompanies<strong>and</strong>oneresearchinstituteinthreeEuropeancountries(seeTable3.1).Thesecompaniesbuilda<br />
1 http://www.mooseproject.org(June2007)<br />
2 http://www.itea-<strong>of</strong>fice.org(June2007)
3.2. Methods<strong>and</strong>Scope 43<br />
Table 3.1:Inventoriedcompanies<br />
Company Products<br />
TeamArteche (Spain) Measurement, control, <strong>and</strong> protection<br />
systems for electrical substations<br />
Nokia (Finl<strong>and</strong>) Mobile networks <strong>and</strong> mobile<br />
phones<br />
Solid (Finl<strong>and</strong>) Distributed-data-management solutions<br />
VTT Electronics (Finl<strong>and</strong>) Technology services for businesses<br />
Philips PDSL (Netherl<strong>and</strong>s) Consumer electronics<br />
ASML (Netherl<strong>and</strong>s) Lithography systems for the semiconductor<br />
industry<br />
Océ (Netherl<strong>and</strong>s) Document-processing systems<br />
LogicaCMG (Netherl<strong>and</strong>s) Global IT solutions <strong>and</strong> services<br />
variety<strong>of</strong>embedded-s<strong>of</strong>twareproducts,rangingfromconsumerelectronics<br />
tohighlyspecialisedindustrialmachines. Weperformed36one-hourinterviewswiths<strong>of</strong>twarepractitioners.Therespondentswereengineers,researchers,s<strong>of</strong>twareorsystemarchitects,<strong>and</strong>managers,withvaryingbackgrounds.<br />
Togetafairoverview<strong>of</strong>thecompaniesinvolved(most<strong>of</strong>which<br />
areverylarge),weinterviewedatleastthreerespondentsatthesmaller<br />
companies<strong>and</strong>fiveorsixatthelargercompanies.Theseinterviewswere<br />
conductedintheperiodApril–October2002.<br />
Webasedtheinterviewsonanoutlinespecifyingthediscussiontopics<br />
(seeTable3.2onthefollowingpage). Tobeascompleteaspossible,itis<br />
basedonareferenceprocessmodel. Becauses<strong>of</strong>twareprocessimprovementmethodshavesucha(ideal)processmodelastheircore,weused<br />
one<strong>of</strong>them. Wechosetheprocessmodel<strong>of</strong>theBOOTSTRAPmethod[Kuvajaetal.,1994]because<strong>of</strong>itsrelativeemphasisonengineeringprocesses<br />
comparedtootherprocessmodels[Wangetal.,1999],suchasthose<strong>of</strong>the<br />
CapabilityMaturity<strong>Model</strong>[Humphrey,1989](CMM)<strong>and</strong>S<strong>of</strong>twareProcess<br />
Improvement<strong>and</strong>CapabilitydEtermination[Emametal.,1997](SPICE).<br />
BOOTSTRAP’sotheradvantageforthisinventoryisthatthe BOOTSTRAP<br />
InstitutedevelopeditwiththeEuropeans<strong>of</strong>twareindustryinmind.<br />
Foreveryinterviewwecreatedareport;weconsolidatedthereports<br />
foracompanyintoonereport. Wethenanalysedthecompanyreports<br />
fortrends<strong>and</strong>commonpractices. Finally,wewroteacomprehensivereportthat,forconfidentialityreasons,isavailableonlytoMOOSEconsortium<br />
members.Thatreportformsthebasisforthisdiscussion.
44 Chapter3. State<strong>of</strong>thePractice<br />
Table 3.2:Asample<strong>of</strong>theinterviewoutline<br />
Here are some discussion topics <strong>and</strong> questions from the outline we used<br />
for the interviews.<br />
Technology<br />
What are the most important reasons for selecting development technologies?<br />
• Impact <strong>of</strong> introducing new technologies (cost, time, <strong>and</strong> so on).<br />
• Why not use modern/different technologies?<br />
S<strong>of</strong>tware life cycle<br />
S<strong>of</strong>twarerequirementsengineering<br />
How are the requirements being gathered?<br />
• What are the different activities?<br />
• What documents are produced?<br />
• What about tool support?<br />
How are the requirements being specified?<br />
• What specification language?<br />
• What about tool support? (Consider cost, complexity, automation, training,<br />
acceptance)<br />
• What notations/diagrams?<br />
• What documents are produced?<br />
• How are documents reviewed?<br />
• What are advantages/disadvantages <strong>of</strong> followed approaches?<br />
S<strong>of</strong>twarearchitecturedesign<br />
How is the architecture specified?<br />
• What architecture description language?<br />
• What about tool support? (Consider cost, complexity, automation, training,<br />
acceptance)<br />
• Are design patterns used?<br />
• What notations/diagrams?<br />
• What documents are produced?<br />
• How are documents reviewed?<br />
• What are advantages/disadvantages <strong>of</strong> followed approaches?
3.3. Embedded-S<strong>of</strong>twareDevelopmentContext 45<br />
3.3 Embedded-S<strong>of</strong>twareDevelopmentContext<br />
Whenconsideringtheembedded-s<strong>of</strong>tware-developmentprocess,youneed<br />
tounderst<strong>and</strong>thecontextinwhichitisapplied. Afterall,mostcompaniesthatdevelopembeddeds<strong>of</strong>twaredonotsellit.<br />
Althoughatthetime<br />
<strong>of</strong>writingthisisslowlychanginginsomeindustries(e.g.,consumerelectronics,seeVanGenuchten[2007],theyprimarilysellmobilephones,CD<br />
players,lithographysystems,<strong>and</strong>otherproducts. Thes<strong>of</strong>twareinthese<br />
productsconstitutesonlyone(important)part. Embedded-s<strong>of</strong>twareengineering<strong>and</strong>otherprocessessuchasmechanicalengineering<strong>and</strong>electrical<br />
engineeringareinfactsubprocesses<strong>of</strong>systemsengineering.Coordinating<br />
thesesubprocessestodevelopqualityproductsisone<strong>of</strong>embedded-system<br />
development’smostchallengingaspects.Theincreasingcomplexity<strong>of</strong>systemsmakesitimpossibletoconsiderthesedisciplinesinisolation.Forinstance,whenlookingatcommunicationbetweendifferentdevelopmentteams,wenoticedthatbesidesverticalcommunicationlinksalong<br />
thelines<strong>of</strong>thehierarchy<strong>of</strong>architectures,horizontalcommunicationlinks<br />
existed. Verticalcommunicationoccursbetweendeveloperswhoareresponsibleforsystems,subsystems,orcomponentsatdifferentabstraction<br />
levels(e.g.,asystemarchitectcommunicatingwithas<strong>of</strong>twarearchitect).<br />
Horizontalcommunicationoccursbetweendeveloperswhoareresponsible<br />
forthesethingsatthesameabstractionlevel(e.g.,aprogrammerresponsibleforcomponentAcommunicatingwithaprogrammerresponsiblefor<br />
componentB).<br />
Still,wefoundthatsystemsengineeringwasmostlyhardwaredriven<br />
–thatis,fromamechanicaloranelectronicviewpoint. Insomecompanies,s<strong>of</strong>twarearchitectsweren’teveninvolvedindesigndecisionsatthe<br />
systemlevel. Hardwaredevelopmentprimarilydominatedsystemdevelopmentbecause<strong>of</strong>longerleadtimes<strong>and</strong>logisticaldependenciesonexternalsuppliers.Consequently,s<strong>of</strong>twaredevelopmentstartedwhenhardware<br />
developmentwasalreadyatastagewherechangeswouldbeexpensive.<br />
Hardwarepropertiesthennarrowedthesolutionspacefors<strong>of</strong>twaredevelopment.Thisresultedinsituationswheres<strong>of</strong>twareinappropriatelyfulfilledtherole<strong>of</strong>integrator;thatis,problemsthatshouldhavebeensolved<br />
inthehardwaredomainweresolvedinthes<strong>of</strong>twaredomain. Embeddeds<strong>of</strong>twaredevelopersfeltthatthiswasbecomingaseriousproblem.<br />
So,<br />
inmanycompaniesthiswaschanging;s<strong>of</strong>twarearchitectswerebecoming<br />
moreinvolvedonthesystemlevel.<br />
Dependingontheproduct’scomplexity,projectsusedsystemrequirements<br />
to design a system architecture containing multidisciplinary or<br />
monodisciplinary subsystems. (A multidisciplinary subsystem will be<br />
implementedbydifferentdisciplines; adisciplinereferstos<strong>of</strong>tware, or<br />
mechanics,orelectronics,oroptics,<strong>and</strong>soon.Amonodisciplinarysubsys-
46 Chapter3. State<strong>of</strong>thePractice<br />
Figure 3.1:Thedecomposition<strong>of</strong>theembedded-systems-developmentprocess<br />
temwillbeimplementedbyonediscipline.) Next,theprojectsallocated<br />
systemrequirementstothearchitecture’sdifferentelements<strong>and</strong>refined<br />
therequirements. Thisprocessisrepeatedforeachsubsystem. Finally,<br />
theprojectsdecomposedthesubsystemsintomonodisciplinarycomponents<br />
thatanindividualdeveloperorsmallgroups<strong>of</strong>developerscoulddevelop.<br />
Thelevel<strong>of</strong>detailatwhichdecompositionresultedinmonodisciplinary<br />
subsystemsvaried. Insomecases,thefirstdesignordecompositionstep<br />
immediatelyresultedinmonodisciplinarysubsystems<strong>and</strong>thecorrespondingrequirements.<br />
Inothercases,subsystemsremainedmultidisciplinary<br />
forseveraldesignsteps.<br />
Thisgenericembedded-systems-developmentprocessresultedinatree<br />
<strong>of</strong>requirements<strong>and</strong>designdocuments(seeFigure3.1). Eachlevelrepresentedthesystemataspecificabstractionlevel.<br />
Themorecomplexthe<br />
system,themoreevidentthisconcept<strong>of</strong>abstractionlevelswasinthedevelopmentprocess<strong>and</strong>itsresultingartefacts(forexample,requirements<br />
documentation).
3.4. RequirementsEngineeringResults 47<br />
Figure 3.2:Embedded-systems-developmentstakeholders<strong>and</strong>otherfactors<br />
IntheprocessinFigure3.1,requirementsondifferentabstractionlevelsarerelatedtoeachotherbydesigndecisions,whichwererecordedin<br />
architecture<strong>and</strong>designdocumentation. Atthesystemlevel,thesedecisionsconcernedpartitioning<strong>of</strong>thefunctional<strong>and</strong>nonfunctionalrequirementsovers<strong>of</strong>tware<strong>and</strong>hardwarecomponents.Thecriteriausedforsuchconcurrentdesign(codesign)weremostlyimplicit<strong>and</strong>basedonsystemarchitects’experience.<br />
3.4 RequirementsEngineeringResults<br />
Typically, embedded-systems development involved many stakeholders.<br />
This was most apparent during requirements engineering. Figure 3.2<br />
depictsourview<strong>of</strong>themostcommonstakeholders<strong>and</strong>otherfactors.<br />
Inrequirementsengineering’sfirstphase,thecustomerdeterminesthe<br />
functional<strong>and</strong>nonfunctionalrequirements.Dependingontheproductdomain,thecustomernegotiatestherequirementsviathemarketing<strong>and</strong><br />
salesareaordirectlywiththedevelopers.<br />
Thefirstphase’soutputistheagreedrequirementsspecification,which<br />
isadescription<strong>of</strong>thesystemthatallstakeholderscanunderst<strong>and</strong>. This<br />
documentservesasacontractbetweenthestakeholders<strong>and</strong>developers.At<br />
thispoint,wenoticedacleardifferencebetweensmall<strong>and</strong>largeprojects.<br />
Insmallprojects,thestakeholderrequirementsalsoservedasdeveloper<br />
requirements.Inlargeprojects,stakeholderrequirementsweretranslated<br />
intotechnicallyorienteddeveloperrequirements.
48 Chapter3. State<strong>of</strong>thePractice<br />
Requirementsspecifywhatasystemdoes;adesigndescribeshowto<br />
realiseasystem. S<strong>of</strong>twareengineeringtextbooksstrictlyseparatetherequirements<strong>and</strong>thedesignphases<strong>of</strong>s<strong>of</strong>twaredevelopment;inpractice,this<br />
separationislessobvious.Infact,thesmallcompanies<strong>of</strong>tenputboththe<br />
requirements<strong>and</strong>designintothesystemspecification. Thesecompanies<br />
didnotexplicitlyderives<strong>of</strong>twarerequirementsfromthesystemrequirements.<br />
Thedevelopmentprocessesinthelargercompaniesdidresultin<br />
separaterequirements<strong>and</strong>designdocumentsondifferentabstractionlevels.<br />
However,inmanycases,thesecompaniesdirectlycopiedinformation<br />
fromadesigndocumentintoarequirementsdocumentforthenextabstractionlevelinstead<strong>of</strong>firstperformingadditionalrequirementsanalysis.<br />
Forinstance,as<strong>of</strong>twarearchitecturespecification(i.e.,adesigndocument)<br />
mightlistsomecharacteristics<strong>of</strong>thecomponentsthatcomprisethearchitecture.<br />
Onthenextabstractionlevelarequirementsdocumentconcerns<br />
onlyanindividualcomponent.Oftensimplythecharacteristicsmentioned<br />
inthearchitecturespecificationareusedastherequirements,instead<strong>of</strong><br />
elaboratingthoserequirements<strong>and</strong>addingmoredetailedrequirements.<br />
3.4.1 RequirementsSpecification<br />
Requirementswereusuallyspecifiedinnaturallanguage<strong>and</strong>processed<br />
withanordinarywordprocessor.Thecompaniesnormallyusedtemplates<br />
<strong>and</strong>guidelinestostructurethedocuments.Thetemplatesprescribedwhat<br />
aspectshadtobespecified. However,notallprojectsatacompanyused<br />
these templates, so requirements specifications from different projects<br />
sometimeslookedquitedifferent.<br />
Becauseembedded-s<strong>of</strong>tware’snonfunctionalpropertiesaretypicallyimportant,weexpectedthesetemplatestoreserveasectiononnonfunctional<br />
requirementsnextt<strong>of</strong>unctionalrequirements.Thiswasn’talwaysthecase.<br />
Forexample,therequirementsspecificationdidn’talwaysexplicitlytake<br />
intoaccountreal-timerequirements.Sometimesaprojectexpressedthem<br />
inaseparatesectionintherequirementsdocuments,but<strong>of</strong>tentheywere<br />
implicit.Requirementsspecification<strong>and</strong>designalsousuallydidn’texplicitlyaddressothertypicalembedded-s<strong>of</strong>twarerequirements,suchasthose<br />
forpowerconsumption<strong>and</strong>memoryuse.<br />
Projectsthatemployeddiagramstosupportrequirementsusedmostly<br />
free-form<strong>and</strong>box-linediagramsinastylethatresemblestheUnified<strong>Model</strong>ingLanguage<br />
1 (UML),data-flowdiagrams,orothernotations. Project<br />
membersprimarilyusedgeneral-purposedrawingtoolstodrawthediagrams.<br />
Because<strong>of</strong>thelack<strong>of</strong>propersyntax<strong>and</strong>semantics,otherproject<br />
members<strong>of</strong>tenmisinterpretedthediagrams. Thiswasespeciallytruefor<br />
1 http://www.uml.org(June2007)
3.4. RequirementsEngineeringResults 49<br />
projectmembersworkinginotherdisciplinesthatemployadifferenttype<br />
<strong>of</strong>notation.<br />
UMLwasnotcommonpracticeyet,butmostcompanieswereatleast<br />
consideringitspossibilitiesforapplicationinrequirementsengineering.<br />
Usecaseswerethemost-usedUMLconstructsinthisphase.Someprojects<br />
usedsequencediagramstorealiseusecases;othersappliedclassdiagrams<br />
fordomainmodelling. However,theinterpretation<strong>of</strong>UMLnotationswas<br />
notalwaysagreedonduringrequirementsengineering. Itwasn’talways<br />
clear,forinstance,whatobjects<strong>and</strong>messagesin UMLdiagramsdenote<br />
whenasequencediagramspecifiesausecaserealisation.<br />
Onthelowestlevels,projectscommonlyusedpre-<strong>and</strong>postconditionsto<br />
specifys<strong>of</strong>twarerequirements.Theyspecifiedinterfacesaspre-<strong>and</strong>postconditionsinnaturallanguage,C,orsomeinterfacedefinitionlanguage.<br />
Projectsrarelyusedformalspecifications.Onereasonwasthatformal<br />
specificationswereconsidereddifficulttouseincomplexindustrialenvironments<strong>and</strong>requirespecialisedskills.Whenprojectsdidusethem,communicationbetweenprojectmemberswasdifficultbecausemostmembers<br />
didnotcompletelyunderst<strong>and</strong>them. Thisproblemworsenedasprojects<br />
<strong>and</strong>customersneededtocommunicate. Inonecase,however,aproject<br />
whosehighestprioritywassafetyusedtheformalnotationZforspecification.<br />
3.4.2 RequirementsManagement<br />
WhenlookingatFigures3.1onpage46<strong>and</strong>3.2onpage47,youcanimagine<br />
thatit’shardtomanagethedifferentrequirementsfromallthesedifferent<br />
sourcesthroughoutdevelopment. Thisissuewasimportantespeciallyin<br />
largeprojects.<br />
Anothercomplicatingfactorwasthatmostprojectsdidn’tstartfrom<br />
scratch.Inmostcases,companiesbuiltanewprojectonpreviousprojects.<br />
So,thesenewprojectsreusedrequirementsspecifications(evenfordevelopinganewproductline).Consequently,keepingrequirementsdocuments<br />
consistentwasdifficult.Tokeepalldevelopmentproducts<strong>and</strong>documents<br />
consistent,theprojectshadtoanalysethenewfeatures’impactprecisely.<br />
However,theprojectsfrequentlydidn’texplicitlydocumentrelationsbetweenrequirements,soimpactanalysiswasquitedifficult.Thistraceabilityisanessentialaspect<strong>of</strong>requirementsmanagement.Tracingrequirementswasdifficultbecausetherelations(e.g.,betweenrequirements<strong>and</strong><br />
architecturalcomponents)weretoocomplextospecifymanually.<br />
Available requirements management tools didn’t seem to solve this<br />
problem, although tailored versions worked in some cases. A general<br />
shortcoming<strong>of</strong>thesetoolswasthattherelationsbetweentherequirementshadnomeaning.Inparticular,tooluserscouldspecifytherelations
50 Chapter3. State<strong>of</strong>thePractice<br />
butnottherationalebehindthelink.<br />
Whenprojectsdiddocumentrelationsbetweenrequirements,theyused<br />
separate spreadsheets. Some companies were using or experimenting<br />
withmoreadvancedrequirementsmanagementtoolssuchasRequisitePro<br />
(Rational), RTM(IntegratedChipware),<strong>and</strong>DOORS(Telelogic). Theseexperimentsweren’talwayssuccessful.<br />
Inonecase,thetool’susersdidn’t<br />
havetherightskills,<strong>and</strong>learningthemtooktoolong. Also,thetoolh<strong>and</strong>ledonlythemoretrivialrelationsbetweenrequirements,design,<strong>and</strong>test<br />
documents. So,developerscouldn’trelyonthetoolcompletely,whichis<br />
importantwhenusingatool.<br />
Requirementsmanagementalsoinvolvesreleasemanagement(managingfeaturesinreleases),changemanagement(backwardscompatibility),<br />
<strong>and</strong>configurationmanagement. Somerequirementsmanagementtools<br />
supportedtheseprocesses.However,becausemostcompaniesalreadyhad<br />
othertoolsforthisfunctionality,integrationwiththosetoolswouldhave<br />
beenpreferable.<br />
3.5 S<strong>of</strong>twareArchitectureResults<br />
Small projects didn’t always consider the explicit development, specification,<strong>and</strong>analysis<strong>of</strong>theproductarchitecturenecessary.<br />
Also,owing<br />
totime-to-marketpressure,thescheduleddeadlines<strong>of</strong>tenobstructedthe<br />
development<strong>of</strong>soundarchitectures.Architects<strong>of</strong>tensaidtheydidn’thave<br />
enoughtimetodothingsright.<br />
Thedistinctionbetweendetaileddesign<strong>and</strong>architectureseemedsomewhatarbitrary.Duringdevelopment,theprojectsinterpretedarchitecturesimplyashigh-leveldesign.Theydidn’tmakethedistinctionbetweenarchitectural<strong>and</strong>othertypes<strong>of</strong>designexplicit,as,forexample,Eden<strong>and</strong><br />
Kazman[2003]. There,thelocalitycriterionisintroducedtodistinguish<br />
architecturaldesignfromdetaileddesign. Adesignstatementissaidto<br />
belocalwhenitcan’tbeviolatedbymereexpansion. Theapplication<strong>of</strong><br />
adesignpatternisanexample<strong>of</strong>alocaldesignstatement. Architectural<br />
designisnotlocal. Forinstance,anarchitecturalstylecanbeviolatedby<br />
simpleexpansion.<br />
3.5.1 S<strong>of</strong>twareArchitectureDesign<br />
Designingaproduct’sorsubsystem’sarchitecturewasforemostacreative<br />
activitythatwasdifficulttodivideintosmall,easy-to-takesteps. Justas<br />
systemrequirementsformedthebasisforsystemarchitecturedecisions,<br />
systemarchitecturedecisionsconstrainedthes<strong>of</strong>twarearchitecture.
3.5. S<strong>of</strong>twareArchitectureResults 51<br />
Insomecases,adifferentorganisationalunithaddesignedthesystem<br />
architecture. So,thearchitecturewasmoreorlessfixed–forinstance,<br />
whenthehardwarearchitecturewasdesignedfirstorwasalreadyknown.<br />
Thisledtosuboptimal(s<strong>of</strong>tware)architectures.Becauses<strong>of</strong>twarewasconsideredmoreflexible<strong>and</strong>hasashorterleadtime,projectsuseditt<strong>of</strong>ix<br />
hardwarearchitectureflaws,aswementionedbefore.<br />
Thedesignprocessdidn’talwaysexplicitlytakeintoaccountperformance<br />
requirements. In most cases where performance was an issue,<br />
projectsjustdesignedthesystemtobeasfastaspossible. Theydidn’t<br />
establishhowfastuntilanimplementationwasavailable. Projectsthat<br />
tookperformancerequirementsintoaccountduringdesigndidsomostly<br />
through budgeting. For example, they frequently divided a high-level<br />
real-time constraint among several lower-level components. This division,however,<strong>of</strong>tenwasbasedonthedevelopers’experienceratherthan<br />
well-fundedcalculations. Projectsalsousedthistechniqueforothernonfunctionalrequirementssuchasforpower<strong>and</strong>memoryuse.<br />
Projectssometimesconsideredcommercial<strong>of</strong>f-the-shelf(COTS)componentsasblackboxesinadesign,specifyingonlytheexternalinterfaces.<br />
Thiswassimilartoanapproachthatincorporatedhardwaredriversinto<br />
anobject-oriented(OO)design. However,developers<strong>of</strong>hardwaredrivers<br />
typicallydon’tuse OOtechniques. Byconsideringthesedriversasblack<br />
boxes<strong>and</strong>lookingonlyattheirinterfaces,thedesignerscouldnevertheless<br />
includetheminan OOdesign. FortheCOTScomponents,theblackbox<br />
approachwasn’talwayssuccessful. Insomecases,theprojectsalsohad<br />
toconsiderthecomponents’bugs,sotheycouldn’ttreatthecomponentsas<br />
blackboxes.<br />
Thes<strong>of</strong>twarearchitecture<strong>of</strong>tenmirroredthehardwarearchitecture,<br />
whichmadetheimpact<strong>of</strong>changesinhardwareeasiertodetermine.Most<br />
casesinvolvingcomplexsystemsemployedalayeredarchitecturepattern.<br />
Theselayersmadeiteasiertodealwithembedded-systems’growingcomplexity.<br />
3.5.2 S<strong>of</strong>twareArchitectureDescription<br />
UMLwasthemostcommonlyusednotationforarchitecturalmodelling.On<br />
thehigherabstractionlevels,thespecificmeaning<strong>of</strong>UMLnotationsinthe<br />
architecturedocumentationshouldbecleartoallstakeholders,whichwas<br />
notalwaysthecase. Someprojectsdocumentedthisinareferencearchitectureorarchitecturemanual(wediscussthesedocumentsinmoredetail<br />
later).
52 Chapter3. State<strong>of</strong>thePractice<br />
IBM’sRationalRoseTechnicalDeveloper 1 (formerlyknownasRational<br />
RoseRealTime)letsdeveloperscreateexecutablemodels<strong>and</strong>completely<br />
generatesourcecode.Afewprojectstriedthisapproach.Oneprojectcompletelygeneratedreusableembedded-s<strong>of</strong>twarecomponentsfromRational<br />
RoseRealTimemodels. However,most<strong>of</strong>theseprojectsusedthesetools<br />
onlyexperimentally.<br />
ForcreatingUMLdiagrams,respondentsfrequentlymentionedonlytwo<br />
tools:Micros<strong>of</strong>tVisio<strong>and</strong>RationalRose. Projectsusedthesetoolsmostly<br />
fordrawingratherthanmodelling.Thismeans,forinstance,thatmodels<br />
weren’talwayssyntacticallycorrect<strong>and</strong>consistent.<br />
Otherwell-knownnotationsthatprojectsusedforarchitecturalmodellingweredata-flowdiagrams,entity-relationshipdiagrams,flowcharts,<strong>and</strong>Hatley-Pirbhaidiagrams[Hatley<strong>and</strong>Pirbhai,1987]fortherepresentation<strong>of</strong>controlflow<strong>and</strong>state-basedbehaviour.Projects<strong>of</strong>tenuseddiagramsbasedonthesenotationstoclarifytextualarchitecturaldescriptionsinarchitecturedocuments.Someprojectsusedmorefree-formboxlinedrawingstodocument<strong>and</strong>communicatedesigns<strong>and</strong>architectures.<br />
OneprojectusedtheKoalacomponentmodel[VanOmmeringetal.,<br />
2000]todescribethes<strong>of</strong>twarearchitecture. Comparedtobox-linedrawings,theKoalacomponentmodel’sgraphicalnotationhasamoredefined<br />
syntax.Koalaprovidesinterface<strong>and</strong>componentdefinitionlanguagesbased<br />
onCsyntax. AKoalaarchitecturediagramspecifiestheinterfacesthata<br />
componentprovides<strong>and</strong>requires.ThisprojectusedMicros<strong>of</strong>tVisiotodraw<br />
theKoaladiagrams.<br />
Projects<strong>of</strong>tenusedpseudocode<strong>and</strong>pre-<strong>and</strong>postconditionstospecify<br />
interfaces. Althoughthistechniqueismorestructuredthannaturallanguage,theresultingspecificationsweremostlyincomplete,withmanyimplicitassumptions.Thisnotonlysometimesledtomisunderst<strong>and</strong>ingsbut<br />
alsohamperedtheuse<strong>of</strong>othertechniquessuchasformalverification.<br />
Someprojectsreferredtoareferencearchitectureoranarchitecture<br />
usermanual. Thesedocumentsdefinedthespecificnotationsinarchitecturaldocuments<strong>and</strong>explainedwhicharchitecturalconceptstouse<strong>and</strong><br />
howtospecifythem.<br />
3.5.3 S<strong>of</strong>twareArchitectureEvaluation<br />
Mostprojectsdidnotexplicitlyaddressarchitectureverificationduringdesign;thosethatdidprimarilyusedqualitativetechniques.<br />
Fewprojects<br />
usedquantitativetechniquessuchasPetrinetsorratemonotonicschedulinganalysis[Liu<strong>and</strong>Layl<strong>and</strong>,1973].Onereasonisthatquantitativeanalysistoolsneeddetailedinformation.Inpractice,projects<strong>of</strong>tenusedan<br />
1 http://www-306.ibm.com/s<strong>of</strong>tware/awdtools/developer/technical(June2007)
3.5. S<strong>of</strong>twareArchitectureResults 53<br />
architectureonlyasavehicleforcommunicationamongstakeholders.<br />
The most commonly employed qualitative techniques were reviews,<br />
meetings, <strong>and</strong>checklists. Anotherqualitativetechniqueemployedwas<br />
scenario-based analysis. With this technique, a project can consider<br />
whethertheproposedarchitecturesupportsdifferentscenarios. Byusingdifferenttypes<strong>of</strong>scenarios(e.g.,usescenarios<strong>and</strong>changescenarios),<br />
aprojectnotonlycanvalidatethatthearchitecturesupportsacertain<br />
functionalitybutalsocanverifyqualitiessuchaschangeability.<br />
Therespondentstypicallyfeltthatformalverificationtechniqueswere<br />
inapplicableinanindustrialsetting.Theyconsideredthesetechniquesto<br />
beusefulonlyinlimitedapplicationareassuchascommunicationprotocols<br />
orparts<strong>of</strong>security-criticalsystems. ThefewprojectsthatusedRational<br />
RoseRealTimewereabletousesimulationtoverify<strong>and</strong>validatearchitectures.<br />
3.5.4 Reuse<br />
Reuseis<strong>of</strong>tenconsideredone<strong>of</strong>themostimportantadvantages<strong>of</strong>developmentusingarchitecturalprinciples.Bydefiningclean,clearinterfaces<strong>and</strong><br />
adoptingacomponent-baseddevelopmentstyle,projectsshouldbeableto<br />
assemblenewapplicationsfromreusablecomponents.<br />
Ingeneral,reusewasratheradhoc.Projectsreusedrequirements,designdocuments,<strong>and</strong>codefromearlier,similarprojectsbycopyingthem.<br />
Thiswasbecausemostproductswerebasedonpreviousproducts.<br />
Forhighlyspecialisedproducts,respondentsfeltthatusingconfigurable<br />
componentsfromacomponentrepositorywasimpossible. Anotherissue<br />
thatsometimespreventedreusewasthedifficulty<strong>of</strong>estimatingbotha<br />
reuseapproach’sbenefits<strong>and</strong>theefforttointroduceit.<br />
Insomecasesaprojectorcompanyexplicitlyorganisedreuse.OnecompanydidthisincombinationwiththeKoalacomponentmodel.Thecompanyappliedthismodeltogetherwithaproprietarymethodfordeveloping<br />
productfamilies.<br />
Somecompanieshadadoptedaproduct-lineapproachtocreateaproductlineorfamilyarchitecture.Whenadoptingthisapproach,thecompanies<strong>of</strong>tenhadtoextracttheproduct-linearchitecturefromexistingproduct<br />
architectures<strong>and</strong>implementations.Thisiscalledreversearchitecting.<br />
Inmostcases,hardwareplatformsservedasthebasisfordefiningproductlines,butsometimesmarketsegmentsdeterminedproductlines.When<br />
acompanytrulyfollowedaproduct-lineapproach,architecturedesigntook<br />
variabilityintoaccount.<br />
Onecompanyusedaproprietys<strong>of</strong>twaredevelopmentmethodthatenabledlarge-scale,multisite,<strong>and</strong>incrementals<strong>of</strong>twaredevelopment.<br />
This<br />
methoddefinedseparatelong-termarchitectureprojects<strong>and</strong>subsystem
54 Chapter3. State<strong>of</strong>thePractice<br />
projects. Thecompanyusedthesubsystemsinshort-termprojectstoinstantiateproducts.<br />
Anothercompanyhadaspecialprojectthatmadereusablecomponents<br />
foracertainsubsystem<strong>of</strong>theproductarchitecture. Thecompanyused<br />
RationalRoseRealTimetodevelopthesecomponentsasexecutablemodels.<br />
Somecompaniespractisedreusebydevelopinggeneralplatformsontop<br />
<strong>of</strong>whichtheydevelopeddifferentproducts.Thisstrategyiscloselyrelated<br />
toproductlines,whichare<strong>of</strong>tendefinedperplatform.<br />
3.6 Discussion<br />
Youmightwellask,arethesesurveyresultsrepresentative<strong>of</strong>thewhole<br />
embedded-s<strong>of</strong>twaredomain? Byinterviewingseveralrespondentswith<br />
differentrolesineachcompany,wetriedtogetarepresentativeunderst<strong>and</strong>ing<br />
<strong>of</strong> that company’s embedded-s<strong>of</strong>tware-development processes.<br />
Theamount<strong>of</strong>newinformationgatheredduringsuccessiveinterviewsdecreased.So,weconcludedwedidhavearepresentativeunderst<strong>and</strong>ingfor<br />
thatcompany.<br />
Withrespecttoembedded-s<strong>of</strong>twaredevelopmentingeneral,webelieve<br />
thatthelargenumber<strong>of</strong>respondents<strong>and</strong>thecompanies’diversity<strong>of</strong>size,<br />
products,<strong>and</strong>country<strong>of</strong>originmakethisinventory’sresultsrepresentative,forEuropeatleast.However,whetherwecanextendtheseresultsto<br />
otherareas(e.g.,theUnitedStates)isquestionable.<br />
Anotherpointfordiscussionisthatthemethods,tools,<strong>and</strong>techniques<br />
thecompaniesusedwererathergenerals<strong>of</strong>twareengineeringtechnologies.<br />
Weexpectedthatthecompanieswouldusemorespecialisedtoolsinthis<br />
domain. Memory,power,<strong>and</strong>real-timerequirementswerefarlessprominentdurings<strong>of</strong>twaredevelopmentthanweexpected.That’sbecausemost<br />
generals<strong>of</strong>twareengineeringtechnologiesdidn’thavespecialfeaturesfor<br />
dealingwiththeserequirements.Tailoringcanbeasolutiontothisproblem,butitinvolvesmucheffort,<strong>and</strong>theresultis<strong>of</strong>tentoospecifictoapplytootherprocesses.Makings<strong>of</strong>twaredevelopmenttechnologiesmoreflexiblecanhelpmaketailoringmoreattractive.So,flexibles<strong>of</strong>twaredevelopmenttechnologiesarenecessary.Here,withflexiblewemean,forinstance,requirementsmanagementtoolsthatallowtomodifythetypes<strong>and</strong>characteristics<strong>of</strong>themanagedrequirements,ormodeltransformationtoolsthatallowtotransformmodelsinarbitrarymodellinglanguages,instead<strong>of</strong>beingrestrictedtoUML.<br />
Wenoticedarelativelylargegapbetweentheinventory’sresults<strong>and</strong><br />
theavailables<strong>of</strong>twaredevelopmenttechnologies.Whyisn’tindustryusing<br />
many<strong>of</strong>thesetechnologies?Duringtheinterviews,respondentsmentioned<br />
severalreasons.Welookatthree<strong>of</strong>themhere.
3.7. Outlook 55<br />
Thefirstreasoniscompliancewithlegacy. Aswementionedbefore,<br />
mostprojectsdidn’tstartfromscratch. Developersalwayshavetodeal<br />
withthislegacy,whichmeansthatthetechnologyusedincurrentprojects<br />
shouldatleastbecompatiblewiththetechnologyusedinpreviousproducts.Also,companiescan<strong>of</strong>tenusepreviousproducts’componentsinnew<br />
productswithfewornoadaptations. Thiscontradictsthetop-downapproachinFigure3.1onpage46.<br />
Unlikewiththatapproach,components<br />
atadetailedlevelareavailablefromthestart,beforethenewproduct’s<br />
architectureisevendefined. Thiswouldsuggestabottom-upapproach.<br />
However,becausemostavailables<strong>of</strong>twaredevelopmentapproachesaretopdown,theydon’taddressthisissue.<br />
Anotherreasonismaturity.Mostdevelopmentmethodsaredefinedata<br />
conceptuallevel;howtodeploy<strong>and</strong>usethemisunclear.Whenmethodsare<br />
pastthisconceptualstage<strong>and</strong>evenhavetoolimplementations,thetools’<br />
maturitycanstillpreventindustryfromusingthem.Thiswasthecasefor<br />
somerequirementsmanagementtools. Somerespondentssaidthatthese<br />
toolsweren’tsuitedformanagingthecomplexdependenciesbetweenrequirements<strong>and</strong>otherdevelopmentartefacts,suchasdesign<strong>and</strong>testdocumentation.Also,integratingthesetoolswithexistingsolutionsforother<br />
problemssuchasconfigurationmanagement<strong>and</strong>changemanagementwas<br />
notstraightforward.<br />
Thethirdreasoniscomplexity. Complexdevelopmenttechnologiesrequirehighlyskilleds<strong>of</strong>twareengineerstoapplythem.Butthedevelopment<br />
processalsoinvolvesstakeholderswhoaren’ts<strong>of</strong>twarepractitioners. For<br />
instance,aswementionedbefore,projectteammembersmightusearchitecturespecificationstocommunicatewith(external)stakeholders.These<br />
stakeholders<strong>of</strong>tendonotunderst<strong>and</strong>complextechnologysuchasformal<br />
architecturedescriptionlanguages(ADLs). Still,formalspecificationsare<br />
sometimesnecessary–forexample,insafety-criticalsystems. Tomake<br />
suchhighlycomplextechnologiesmoreapplicableinindustry,thesetechnologiesshouldintegratewithmoreaccepted<strong>and</strong>easy-to-underst<strong>and</strong>technologies.Suchastrategywillhidecomplexity.<br />
3.7 Outlook<br />
Intheremainder<strong>of</strong>thisthesiswetakeintoaccounttheaforementioned<br />
reasonsforindustry’sreluctance<strong>of</strong>adoptingstate-<strong>of</strong>-the-arts<strong>of</strong>twaredevelopmenttechnologies.<br />
Thisimpliesthatwe,werepossible,makeuse<strong>of</strong><br />
existingst<strong>and</strong>ards<strong>and</strong>technologiesthatalreadyhavebeensuccessfully<br />
appliedinindustrialpractice.<br />
Moreover,wehaveseenthats<strong>of</strong>twaredevelopmentinpracticeseldom<br />
startsfromscratch.Assuch,technologiestosupports<strong>of</strong>twaremaintenance
56 Chapter3. State<strong>of</strong>thePractice<br />
deserveatleastasmuchattentionasthosethatsupports<strong>of</strong>twaredevelopment.Therefore,wefocusons<strong>of</strong>twareevolution<strong>and</strong>howrelateds<strong>of</strong>tware<br />
engineeringtaskscanbesupported. Tothisend,weuse<strong>and</strong>combineexistings<strong>of</strong>twareengineeringtechnologiesasmuchaspossible.<br />
Thetrendweobservedthats<strong>of</strong>twaredevelopmentismovingtowards<br />
largerscale<strong>and</strong>morestructuredreusebytheuse<strong>of</strong>s<strong>of</strong>twareproduct-line<br />
approachesisafinalimportantconsiderationintheremainder<strong>of</strong>thisthesis.
Chapter4<br />
Evaluating an Embedded S<strong>of</strong>tware<br />
Reference Architecture<br />
– Industrial Experience Report – 1<br />
Inthis chapter, we discussexperiencesgained duringevaluation <strong>of</strong> the<br />
maintainability<strong>of</strong>as<strong>of</strong>twarereferencearchitectureinuseatOcé,one<strong>of</strong>the<br />
world’sleadingcopiermanufacturers.Theevaluationisconductedusingan<br />
approachbasedontheS<strong>of</strong>twareArchitectureAnalysisMethod.Thechapter<br />
proposesavariant<strong>of</strong>thismethodthathelpstoreducetheorganisational<br />
impact<strong>of</strong>architectureevaluations. Second,weanalysetheimplications<br />
<strong>of</strong>evaluatingreferencearchitecturesasopposedtosingle-productarchitectures.<br />
Furthermore,weshareourexperience<strong>of</strong>conductingtheevaluation,<br />
drawlessonsforpractitioners,<strong>and</strong>proposenewresearchtopics.<br />
4.1 Introduction<br />
Inindustrynewproductsarerarelydevelopedfromscratch.Mostproducts<br />
arebasedonpreviousgenerations<strong>of</strong>similarproducts.Therefore,thecapability<strong>of</strong>reusinglargeparts<strong>of</strong>earlierdevelopmenteffortswhendevelopingnewproductscanincreasethedevelopmentefficiency<strong>of</strong>companiestremendously[Jacobsonetal.,1997].However,currentlymanycompanieshaveno<br />
structuredapproachforreuse,astheinventoryconductedamongseveral<br />
companiesdevelopingembeddeds<strong>of</strong>twareconfirmed(seeChapter3).<br />
1 Thischapterwaspublishedearlieras:Graaf,Bas,HylkevanDijk,<strong>and</strong>Arievan<br />
Deursen. Evaluatinganembeddeds<strong>of</strong>twarereferencearchitecture–industrialexperiencereport.<br />
InProceedings<strong>of</strong>the9 th EuropeanConferenceonS<strong>of</strong>twareMaintenance<br />
<strong>and</strong>Reengineering(CSMR2005),pages354–363.IEEEComputerSociety,2005<br />
57
58 Chapter4. Evaluation<br />
Onestrategytoarriveatstructuredreuse,istoadoptarchitecturalconcepts,includingproduct-lineapproaches,duringthes<strong>of</strong>twaredevelopment<br />
process.Architecture-baseddevelopmentincreasesdevelopmentefficiency<br />
<strong>and</strong>makess<strong>of</strong>twaresystemsmoreeasytomaintain<strong>and</strong>evolve.Itdoesso<br />
byincreasingtheconceptualintegrity[Brooks,Jr,1975]<strong>of</strong>s<strong>of</strong>twaresystems<strong>and</strong>byprovidingacommons<strong>of</strong>twareinfrastructurewhichmakesiteasiertounderst<strong>and</strong>systems<strong>and</strong>tointegratenewcomponents.Aproductlinearchitectureextendstheseideasbeyondsingle-productdevelopments<br />
toawholegeneration<strong>of</strong>products<strong>and</strong>thusenablesthereuse<strong>of</strong>components<br />
innewproduct-linemembers.<br />
AtOcé,one<strong>of</strong>theworld’sleadingcopiermanufacturers,everycouple<strong>of</strong><br />
yearsanewproductgenerationislaunched,comprisingafamily<strong>of</strong>similarproducts.Tomakedevelopment<strong>and</strong>maintenance<strong>of</strong>thesegenerationsmoreeffective<strong>and</strong>efficientOcédecidedtodefineareferencearchitectureforapart<strong>of</strong>theembeddeds<strong>of</strong>twareinitsproducts.Itestablishesa<br />
commons<strong>of</strong>twareinfrastructurefordifferentgenerations,thusfacilitating<br />
reuseacrossgenerationboundaries.<br />
Since this reference architecture will potentially impact all embeddeds<strong>of</strong>twaretobedevelopedatOcé,thearchitectureteamatOcédecided<br />
to conduct an evaluation <strong>of</strong> the quality <strong>of</strong> this reference architecture,usinganapproachbasedontheS<strong>of</strong>twareArchitectureAnalysis<br />
Method(SAAM)[Kazmanetal.,1996;Clementsetal.,2002b]whichwas<br />
developedattheS<strong>of</strong>twareEngineeringInstitute 1 (SEI).Inthischapterwe<br />
reportonthisevaluation.<br />
Thecontributions<strong>of</strong>thischapterarethreefold.First,weproposeavariant<strong>of</strong>SAAMthatreducestheorganisationalimpact<strong>of</strong>architectureevaluations.Second,weanalysetheimplications<strong>of</strong>evaluatingreferencearchitecturesasopposedtoproductarchitectures.Lastbutnotleast,weshareourexperiencewithconductinganevaluation<strong>of</strong>areal-lifereferencearchitecturethatisactuallyusedinindustry.Thelessonslearntareusefulfor<br />
practitioners,<strong>and</strong>leadtonewresearchquestionsrelatedtoarchitecture<br />
evaluation.<br />
InordertoprotectOcé’sinterests,wecannotdiscussOcé-sensitivedetails<strong>of</strong>thereferencearchitecture.Instead,wewilldiscussamodifiedversion.<br />
Webelievethatthearchitecturalissues<strong>and</strong>theevaluationmethod<br />
arenotmateriallyaffectedbythesechanges.<br />
Thischapterisorganisedasfollows. InSection4.2wesummarisethe<br />
content<strong>and</strong>context<strong>of</strong>theembeddeds<strong>of</strong>twarereferencearchitecturefor<br />
copierengines(hereafterreferredtoas‘thereferencearchitecture’). In<br />
Section4.3,wedescribewhyweselectedSAAMtoconducttheevaluation<br />
<strong>and</strong>whyOcé’ssituationrequiredsomemodificationstoit. InSection4.4<br />
1 http://www.sei.cmu.edu(June2007)
4.2. Overview<strong>of</strong>theReferenceArchitecture 59<br />
weexplainhowtheactualevaluationwascarriedout<strong>and</strong>howpractical<br />
problemsweresolved. Then,inSection4.5wereflectontheevaluation<br />
<strong>and</strong>identifyfuturework. Weconcludewithadiscussion<strong>of</strong>relatedwork<br />
<strong>and</strong>asummary<strong>of</strong>thechapter’scontributions.<br />
4.2 Overview<strong>of</strong>theReferenceArchitecture<br />
Thereferencearchitectureaddressestheengines<strong>of</strong>twareforOcédocument<br />
processingsystems(copiers).Acopierengineisthepart<strong>of</strong>thesystemthat<br />
h<strong>and</strong>leseitherthescanningortheprinting<strong>of</strong>documents.Figure4.1illustratestheworkings<strong>of</strong>acopier.<br />
Ascannerengineextractsanimagefrom<br />
theoriginalsheet,whereasaprinterenginereproducestheimagedataon<br />
blanksheets.Thereferencearchitecturedescribesanabstractenginethat<br />
canpotentiallybeusedforanyOcécopier.<br />
original<br />
sheets<br />
print data<br />
4.2.1 BusinessDrivers<br />
Controller<br />
image data & info<br />
Scanner Printer<br />
original<br />
sheets<br />
network<br />
blank<br />
sheets<br />
scanned data<br />
Figure 4.1:Mainflowsinacopier.<br />
printed<br />
sheets<br />
Océ’sreferencearchitectureservesseveralpurposes,<strong>of</strong>whichthemostimportantare:<br />
KnowledgebaseItprovidescommonterminologyfors<strong>of</strong>twarearchitects<br />
thatisapplicabletoseveralproducts. Thesharedterminologytogetherwiththeregularmeetingsdedicatedtodevelopment<strong>of</strong>thereferencearchitectureenablearchitectstoshareexperiencesmoreefficiently.
60 Chapter4. Evaluation<br />
StartingpointItsdocumentationcanbeusedbynewprojectsasastartingpointforOcé’siterativedevelopmentprocess.Thisgreatlyreducestheeffortrequiredfordesigninganenginearchitecturefora<br />
newproduct.<br />
ReuseItdescribesthegenericstructure<strong>and</strong>behaviour<strong>of</strong>theengines<strong>of</strong>twarecomponents.Thismakesintegratingexistings<strong>of</strong>twarecomponentsthatarecomplianttothereferencearchitectureeasier,<strong>and</strong>thus<br />
increasesthereusepotential<strong>of</strong>thosecomponents. Thisnotonlyincludesbinarycomponents,butalsodesigns,requirements<strong>and</strong>other<br />
s<strong>of</strong>twareartefacts.<br />
Infactthethreepointsaboveareallrelatedtoreuse(i.e.,<strong>of</strong>knowledge,documentation,<strong>and</strong>others<strong>of</strong>twareproducts).Therefore,thereferencearchitectureshouldmakeitpossibletoeventuallyspeedupthedevelopment<br />
(fastprototyping)<strong>and</strong>maintenance<strong>of</strong>productssignificantly.<br />
4.2.2 ReferenceArchitecture<br />
Thereferencearchitecturedefinesthefundamentalelements,relationsbetweentheseelements,<strong>and</strong>properties<strong>of</strong>other,product-specificelements<strong>of</strong><br />
Océ’scopierengines<strong>of</strong>tware.Itisusedtoderiveas<strong>of</strong>twarearchitecturefor<br />
enginesincorporatedinaspecificseries<strong>of</strong>Océprinters.Fromthiss<strong>of</strong>tware<br />
architecture,individualenginescanbeconfiguredtobeintegratedinOcé’s<br />
products.Inthiswaythereferencearchitecturedefinesafamily<strong>of</strong>copier<br />
engines.<br />
Deelstraetal.[2005]giveaclassification<strong>of</strong>productfamilieswithrespecttolevel<strong>of</strong>reuse.Weusethisclassification<strong>and</strong>theaccompanyingterminologytopositionthereferencearchitecture.<br />
Four(ordered)levelsare<br />
identified: 1)st<strong>and</strong>ardisedinfrastructure,2)platform,3)s<strong>of</strong>twareproductline,<strong>and</strong>4)configurableproductfamily.<br />
Theselevelsdenotetowhich<br />
extentthecommonalitiesbetweenrelatedproductsintheproductfamily<br />
areexploited.Océ’sreferencearchitecturecanbepositionedasaplatform,<br />
sinceitprovidesreusablecomponentsthataredevelopedbyaseparate<br />
reusegroup(seeSection4.2.4). Furthermore,itdefinesast<strong>and</strong>ardised<br />
infrastructurebyprescribinghowcomponentsshouldinteract<strong>and</strong>what<br />
functionalcomponentsshouldlooklike. Additionally,it<strong>of</strong>fersaplatform<br />
thatrealisescommonfunctionality,suchaserrorh<strong>and</strong>ling<strong>and</strong>scheduling.<br />
Asallbusinessdrivers<strong>of</strong>thereferencearchitecturearerelatedtoreuse,<br />
Océisparticularlyinterestedininvestigatingwhetheritispossible<strong>and</strong><br />
worthwhiletoraisethecurrentreuselevel<strong>of</strong>thereferencearchitectureto<br />
that<strong>of</strong>aproductline.However,inordertoqualifyasaproduct-linearchitecture,itmustdefinethefunctionalvariabilitybetweendifferentengines.
4.2. Overview<strong>of</strong>theReferenceArchitecture 61<br />
Table 4.1:Viewsusedininthereferencearchitecture’sdocumentation<br />
View<br />
Persp.<br />
Static Dynamic<br />
Conceptual System context, stake- Use cases, user visible<br />
holders, key require- states, configurations, variments,<br />
external interfacesants<br />
Logical System components Behaviour, component<br />
<strong>and</strong> dependencies, connection <strong>and</strong> discon-<br />
subsystem decomponection, startup, key algosition,<br />
persistent data,<br />
internal interfaces<br />
rithms.<br />
Physical Files, directories, code, Threads, tasks, schedul-<br />
build rules<br />
ing, interrupts.<br />
4.2.3 Structure<br />
Thereferencearchitectureisextensivelydocumentedusingtextillustrated<br />
withUnified<strong>Model</strong>ingLanguage 1 (UML)diagramsinmorethan500pages.<br />
ThedocumentationisstructuredaccordingtotheArchitectureMeta<strong>Model</strong><br />
(AMM)developedbyAtosOrigin[Dintheretal.,2001]. AMMbuildsupon<br />
theSiemensfour-viewsmodel[Sonietal.,1995]<strong>and</strong>Kruchten’s4+1View<br />
<strong>Model</strong>[Kruchten,1995].Itisorganisedaroundthreetypes<strong>of</strong>views:conceptual,logical,<strong>and</strong>physicalviews.<br />
Foreachtype<strong>of</strong>view,astatic<strong>and</strong>a<br />
dynamicperspectiveis<strong>of</strong>fered. Thisgivesrisetosixviews,asillustrated<br />
inTable4.1.<br />
Thedocumentationincludesoneoverviewdocument<strong>of</strong>approximately<br />
50pages,<strong>and</strong>adozendocumentsdescribingthearchitectureforspecific<br />
concerns,suchasstatuscontrol,s<strong>of</strong>twaredownloading,datapersistence,<br />
<strong>and</strong>diagnostics. Each<strong>of</strong>thesedocumentsisorganisedaccordingtoAMM.<br />
TheviewsareillustratedwithdiagramsexpressedinUML-RT,areal-time<br />
extension<strong>of</strong>UMLwidelyusedatOcé[Dohmen<strong>and</strong>Somers,2003].Inparticular,manyusecasesareelaboratedinsequencediagrams.<br />
4.2.4 Usage<br />
Currentlytheuse<strong>of</strong>thereferencearchitectureisvoluntary. However,architectswhowanttouseitfortheirprojectaresupposedt<strong>of</strong>irstparticipateinthededicatedmeetingsforsomemonthstogetthesameshared<br />
underst<strong>and</strong>ing<strong>of</strong>thereferencearchitectureastheotherparticipatingar-<br />
1 http://www.uml.org(June2007)
62 Chapter4. Evaluation<br />
p1 p2 p3 p4 Reference architecture evolution<br />
Product development Figure 4.2:Thereferencearchitecture<strong>and</strong>derivedprojects.<br />
chitects. Thisensuresthatthereferencearchitectureismorethanapile<br />
<strong>of</strong>documents. Thesemeetingsareveryimportantastheyprovideacommunicationplatformwhichisessentialformeetingtheinitialobjectives<br />
(Section4.2.1).<br />
Inagreementwiththeseobjectives,thereisalogicallinkbetweenthe<br />
referencearchitecturegroup<strong>and</strong>thegroupthatdevelopsreusables<strong>of</strong>tware<br />
componentsfortheengines<strong>of</strong>tware. Inthecurrentsituation, onlythe<br />
reusablecomponentsrefertothereferencearchitecture’sdocumentation,<br />
whichmeansthatthisdocumentationitselfdoesnotshowwhatcomponentscanbeusedtoimplementthedifferentelements<strong>of</strong>thearchitecture.<br />
Theactualusage<strong>of</strong>thereferencearchitectureleadstorefinements<strong>and</strong><br />
additions. Figure4.2depictsthisinterplaybetweenusage<strong>and</strong>evolution.<br />
Thehorizontallinerepresentstheevolution<strong>of</strong>thereferencearchitecture.<br />
Each pirepresentsaprojectinwhichanengineisdevelopedforaseries<strong>of</strong><br />
Océcopiers. Aprojectcan‘join’thereferencearchitectureforsometime,<br />
contributetoitsdevelopment,<strong>and</strong>benefitfrommodificationsmadetoit.<br />
Thisisindicatedbytheobliquelinesforprojects p1, p2,<strong>and</strong> p4. Aftera<br />
while,suchprojectsmaydecideto‘leave’thereferencearchitecture,<strong>and</strong><br />
continueontheirownusingafixedversion(thelinesbecomevertical).<br />
Otherprojects(p3)maydecidetouseafixedversionrightfromthestart,<br />
extractingjustwhateverisnecessaryfromthatversion<strong>of</strong>thereference<br />
architecture.<br />
Thereferencearchitecturecameintoexistencebasedonthedocumentation<strong>and</strong>experience<strong>of</strong>severalpreviousprojects.Infact,itwasdeveloped<br />
largelyinparallelwithonespecificproject. Assuchitcancurrentlybe<br />
understoodasthecommondenominator<strong>of</strong>severalproductspecificarchitectures.<br />
Assaidusingthereferencearchitectureisvoluntary<strong>and</strong>itisnotyet<br />
knowntoallpotentialstakeholders. Thereforewecansaythatitiscur-
4.3. EvaluationApproach 63<br />
rentlyinanemergingphase.Assuch,besidesconfirmationthatthereferencearchitectureissuitableforitsintendedpurpose,now<strong>and</strong>inthefuture,<br />
anotherresult<strong>of</strong>itsevaluationistheincreasedawareness<strong>of</strong>thepotential<br />
benefits<strong>of</strong>thereferencearchitecturewithotherdevelopmentteamswithin<br />
Océ.<br />
4.3 EvaluationApproach<br />
Theinitialquestionthattriggeredthisworkwas“Howgoodisthereferencearchitecture?”<br />
Additionallyanotherimportant<strong>and</strong>relatedquestion<br />
wasasked:“Doesthisreferencearchitecturehaveareasontoexist?”The<br />
developmentteammainlywantedtogetconfirmationthatthereference<br />
architectureisuseful<strong>and</strong>thatitis<strong>of</strong>goodquality.<br />
Wefirstdefinewhattheterms‘quality’<strong>and</strong>‘good’meaninthiscontext.<br />
As‘good’isalwaysrelativetoparticularrequirements,thefirststepisto<br />
determinetheserequirementsforthereferencearchitecture,whichwere<br />
unknownsincetheirdefinitionwasneglectedduringdevelopment.<br />
Asthereferencearchitectureisintendedtobeusedforseveralyears<br />
<strong>and</strong>productgenerations,itisessentialthatitsupportsfuturechangesto<br />
itsenvironment<strong>and</strong>newproductrequirements. Thisisthemaintype<strong>of</strong><br />
qualityunderconsiderationintheevaluation.Furthermore,inview<strong>of</strong>the<br />
factthattheobjectives<strong>of</strong>thisarchitectureaspresentedinSection4.2are<br />
centredaroundreuse,theimpactthatfuturechangeswillhaveonthereuse<br />
potentialit<strong>of</strong>fers,isessential. Intherest<strong>of</strong>thischapterwewillusethe<br />
termmaintainabilitytorefertothetype<strong>of</strong>qualityrequiredforareference<br />
architecturedescribedabove.<br />
Thus,thecentralquestionis: “Howwellisthereferencearchitecture<br />
preparedforthefuture?” Asthisfutureisnotalwaysknownatthetime<br />
<strong>of</strong>evaluation,theselectedmethodmustexplicitlyaddressspecification<strong>of</strong><br />
possibleextensions.<br />
4.3.1 Selection<strong>of</strong>EvaluationMethod<br />
A literature overview <strong>of</strong> architecture evaluation methods [Dobrica <strong>and</strong><br />
Niemelä, 2002] was used to select an appropriate approach to answer<br />
thecentralquestionabove. Besidesaddressingmaintainabilityaswedescribeditinthepreviousparagraphs,Océfurtherrequiredthemethod<br />
tobelightweight<strong>and</strong>well-documented. Themethodmusthavealoworganisationalimpactbecause,asthereferencearchitectureisstillinan<br />
emergingphase, itsevaluationmustnotaffectotherprocessesatOcé.<br />
Additionally,themethodmustbeexecutablewithoutadditionaltraining.<br />
Thisrequiresthataclearprocedurefordoinganevaluationbasedonthe
64 Chapter4. Evaluation<br />
Describe<br />
Develop<br />
Architecture Scenarios<br />
Classify / prioritise<br />
scenarios<br />
Individually evaluate<br />
indirect scenarios<br />
Assess scenario<br />
interaction<br />
Create overall<br />
evaluation<br />
Figure 4.3:SAAMsteps[Clementsetal.,2002b].<br />
selectedmethodisavailable. Theseconstraintsimplytheexclusion<strong>of</strong><br />
many<strong>of</strong>theinventoriedmethodsbecausetheseeitherfocusonadifferent<br />
qualityattributeorlacksufficientdetail,e.g. manymethodsaredefined<br />
<strong>and</strong>explainedinonlyonepublishedarticle.<br />
Thebest-suitedmethodsdescribedintheinventoryseemtobeSAAM<strong>and</strong><br />
itssuccessor,theArchitectureTrade<strong>of</strong>fAnalysisMethod[Clementsetal.,<br />
2002b](ATAM). Bothaddressmaintainability<strong>and</strong>areextensivelydocumented.<br />
AlthoughATAMislikelytoproducemoreobjective<strong>and</strong>accurate<br />
results,italsoseemsmoredifficulttoapplyforinexperiencedassessors.<br />
Theuse<strong>of</strong>attribute-basedarchitecturestyles<strong>and</strong>theirassociatedqualityattributecharacterisationsforanalysis<strong>of</strong>architecturaldecisionsisnot<br />
straightforward. Alsotheidentification<strong>of</strong>sensitivity<strong>and</strong>trade-<strong>of</strong>fpoints<br />
<strong>and</strong>thegeneration<strong>of</strong>autilitytreerequiresmoreeffort<strong>and</strong>experience.<br />
DuetoOcé’srequirementswithrespecttotheneedfortraining(noneed)<br />
<strong>and</strong>organisationalimpact(low)<strong>of</strong>themethod,SAAMwasselected.<br />
InaSAAMevaluation, scenariosaredevelopedtoassessas<strong>of</strong>tware<br />
architecture’ssupportformaintainability. Thescenariosareusedtoexpresstherequiredtype<strong>of</strong>maintainability<strong>and</strong>thusSAAMcanalsobeusedtoevaluatethetype<strong>of</strong>maintainabilitywedescribedpreviously.Thedevelopedscenariosrepresentpossiblefuturechangestothes<strong>of</strong>twaresystem.Animportantaspect<strong>of</strong>SAAMisthatitinvolvesallstakeholders<strong>of</strong>as<strong>of</strong>twarearchitectureinajointevaluationsession,whichresultsinabetter<br />
appreciation <strong>and</strong> a more widely shared underst<strong>and</strong>ing <strong>of</strong> the s<strong>of</strong>tware<br />
architecture.
4.3. EvaluationApproach 65<br />
Figure4.3 showsthedifferentphases<strong>of</strong>SAAM.ASAAMevaluationsessionstartswithscenariodevelopment<strong>and</strong>description<strong>of</strong>thearchitecture.Theseareiterativeactivities.Newscenarioscanmakeitnecessarytodescribethearchitecturefurther,sothatthearchitectscananalysethem,<br />
whiledescribingaspects<strong>of</strong>thearchitectureforcestothinkaboutpossible<br />
scenariosaddressingtheseaspects.<br />
Next,thescenariosareprioritised<strong>and</strong>classified.Scenariosthatcanbe<br />
realisedwithoutmakingchangestothecurrentarchitectureareclassified<br />
asdirect. Scenariosthatdorequirechangestothecurrentarchitecture<br />
areclassifiedasindirect.Theindirectscenariosareevaluatedfortheirimpact.Furthermore,thescenariointeractionisdetermined.<br />
Twoscenarios<br />
interactwhentheyrequirechangestothesamearchitecturalcomponent.<br />
Informationonscenariointeractionisindicative<strong>of</strong>thequality<strong>of</strong>thedecomposition.Finally,theclassification,prioritisation,analysis<strong>of</strong>theindividualscenarios,<strong>and</strong>thescenariointeractionareusedtocreateanoverallevaluation.ASAAMevaluationsessiontypicallytakestwodays<strong>and</strong>involvesanexternalevaluationteam<strong>of</strong>threet<strong>of</strong>ourpeople.Asessionalsoinvolvessystemarchitects<strong>and</strong>otherstakeholders.<br />
Thetype<strong>of</strong>stakeholdersinvolved<br />
isverydiverse:architects,developers,maintainers,integrators,managers,<br />
customers,endusers,<strong>and</strong>soon.<br />
4.3.2 TailoringSAAM<br />
SAAMhasbeenselectedastheevaluationmethod,yetithadtobetailored<br />
toOcé’ssituation.ThecurrentsituationatOcémakesitnecessarytomodifySAAMfortworeasons:1)theorganisationalimpact<strong>of</strong>SAAM<strong>and</strong>2)the<br />
level<strong>of</strong>abstraction<strong>of</strong>thereferencearchitecture.<br />
Inthesituation<strong>of</strong>Océtheimpact<strong>of</strong>gatheringallpotentialstakeholders<br />
(asindicatedinTable4.2onthenextpage),wasconsideredtoolarge.The<br />
mainreasonwasthatthestakeholders<strong>of</strong>as<strong>of</strong>twarearchitecturetypically<br />
includesome<strong>of</strong>theimportantmembers<strong>of</strong>anorganisationthatusually<br />
haveverybusyschedules.Forthereferencearchitecturethisisespecially<br />
trueasitisthedevelopmentgroup’sambitiontomakeitareferencearchitecturethatwillimpactdevelopment<strong>of</strong>many<strong>of</strong>Océ’scopiersforyears.<br />
Furthermore,thescope<strong>of</strong>areferencearchitectureislargerthanthat<strong>of</strong>a<br />
single-productarchitecture<strong>and</strong>therefore,nexttoagroup<strong>of</strong>directstakeholdersalargegroup<strong>of</strong>indirectstakeholders(asindicatedinTable4.2on<br />
thefollowingpage)exist,whichmakesthecompletegroup<strong>of</strong>peoplewith<br />
aninterestinareferencearchitecturemuchlarger.
66 Chapter4. Evaluation<br />
Theincreasednumber<strong>of</strong>stakeholdersmadeitimpossiblet<strong>of</strong>indadate<br />
thatsuitedallstakeholders<strong>and</strong>undesirabletotakeoneortw<strong>of</strong>ulldays<strong>of</strong><br />
eachstakeholders’time.<br />
Besidesthenumber<strong>of</strong>stakeholdersthefactthatwearestudyingareferencearchitecturealsohasanimpactontheevaluation.<br />
Itaffectsthe<br />
level<strong>of</strong>abstraction;areferencearchitectureismoreabstractthanasingleproductarchitecture.<br />
Thecharacteristics<strong>of</strong>thesituationasfoundatOcéthatwediscussed<br />
abovehaveseveralimplicationsfortheevaluation. Belowwewilldiscuss<br />
howtheseissuesleadtomodificationstothetypicalSAAMprocessasdescribedbyKazmanetal.[1996].<br />
Table 4.2:Referencearchitecturestakeholders.<br />
Stakeholder Interest<br />
Architects Reference architecture architects<br />
Users Product architects<br />
Management Sponsors <strong>and</strong> decision makers<br />
Potential users Product architects not using the reference architecture<br />
Reuse group Provider <strong>of</strong> compliant components<br />
Indirect Stakeholders <strong>of</strong> products based on the reference<br />
architecture<br />
Theproposedtailoredversionisadistributedimplementation<strong>of</strong>SAAM,<br />
calledDistributedSAAM(DSAAM),thatimplementsparts<strong>of</strong>theSAAMactivities<strong>of</strong>f-line,separatelyfromthejointsession.Forinstance,inpreparationtotheevaluationsession,stakeholdersareconsultedindividually.ThejointSAAMsessionitselfinvolvesonlyparticipantsfullyaware<strong>of</strong><strong>and</strong>wellinformedonthereferencearchitecture.Theadvantage<strong>of</strong>thisapproachisthattheorganisationalimpactismuchsmaller.Off-lineconsultation<strong>of</strong>individualstakeholderstakeslesstimethanajointSAAMsession.Additionallytheseconsultationscanbescheduledfittingthestakeholders’agenda’s.Ofcoursethisapproachincreasestheeffortrequiredbytheassessorsinvolvedinthesepreparations.However,becausewetriedtominimiseorganisationalimpact,weaimedatreducingtherequiredstakeholdereffort.<br />
Anadditionaladvantageisthatsmallergatheringspotentiallyinduce<br />
lessambiguity,leadingtoamoreefficientjointsession. ThereforetheactualDSAAMevaluationsessionlastshalfadayinstead<strong>of</strong>theusualtwo<br />
days.Thisfurtherdecreasestheorganisationalimpact<strong>of</strong>theevaluation.
4.4. ConductingtheEvaluation 67<br />
4.4 ConductingtheEvaluation<br />
Theevaluationconsisted<strong>of</strong>roughlythreephases. First,thejointDSAAM<br />
sessionhadtobeprepared.Second,theDSAAMevaluationsessionitselfwas<br />
executed. Andfinallyanoverallevaluation<strong>of</strong>thereferencearchitecture<br />
wascreated.Threearchitectsinvolvedinthedevelopment<strong>of</strong>thereference<br />
architecture<strong>and</strong>twoexternalobserversparticipatedinthejointsession.<br />
One<strong>of</strong>thearchitectsplayedtherole<strong>of</strong>evaluationleader<strong>and</strong>prepared,<br />
chaired,<strong>and</strong>evaluatedthejointsession<strong>of</strong>DSAAM. ForeachSAAMstepin<br />
Figure4.3onpage64,weexplainbelowhowitwasincludedinthedifferent<br />
phases<strong>of</strong>theDSAAMassessment.<br />
4.4.1 Preparation<br />
Inpreparationtotheexecution<strong>of</strong>thejointDSAAMsessiontheavailable<br />
documentation(onthereferencearchitecture<strong>and</strong>onSAAM)wasdistributed<br />
amongtheparticipants. Thereferencearchitecture’sdocumentationwas<br />
especiallyusefulfortheexternalobserversasitexplainsthearchitecture<br />
<strong>and</strong>theappliedarchitecturalmechanisms. ThedocumentsonSAAMwere<br />
onlyusedbytheevaluationleader.<br />
Thestep‘developscenarios’wascarriedoutintwostages. Duringthe<br />
preparationphase,theevaluationleaderconsultedstakeholders<strong>of</strong>f-line.<br />
Thisresultedinaninitialset<strong>of</strong>high-levelscenariosrepresentingpossible<br />
futuresfromastakeholder’sperspective.Theset<strong>of</strong>stakeholdersincluded<br />
thesponsor<strong>of</strong>thereferencearchitecture,members<strong>of</strong>thes<strong>of</strong>twarereuse<br />
group,<strong>and</strong>hardware<strong>and</strong>domainexperts. Unfortunately,themarketing<br />
<strong>and</strong>maintenancegroupswerenotconsulted,whichlimitedtheviewon<br />
theroadmapsforOcécopiermachines. Thescenarioswererelatedtoeitherexistingproductsorforeseenproducts.Whetherthereferencearchitecturewasbasedontheseproductsisirrelevant.<br />
Theevaluationleader<br />
thenaddedmoredetailtothesescenariosaccordingtoatemplateforscenariosbasedonBassetal.[2003].<br />
4.4.2 Scenarios<br />
Intotalsixteenscenariosweredeveloped<strong>of</strong>f-line.Themajority<strong>of</strong>thescenariosaimedatreducingmaterialcosts,forexamplebysharingresources,<br />
usinglow-powerdesigns,or<strong>of</strong>floadingorre-mappingfunctionality. One<br />
scenario,forinstance,aimedatmovingfunctionalityfromtheengines<strong>of</strong>twaretothemaincontroller,anothersubsystem<strong>of</strong>acopier.<br />
Asecondkind<strong>of</strong>scenarioswasdevelopedtoreducedevelopmentcosts.<br />
Forinstance,introduction<strong>of</strong>codegenerationforcontrollers<strong>of</strong>sensors<strong>and</strong><br />
actuatorsbasedonmathematicalmodels<strong>of</strong>thosehardwaredevices.These
68 Chapter4. Evaluation<br />
scenarioswereespeciallytargetedatinteractionswhichgobeyondthedomainlevel,suchascommunicationswiththemechatronics,testing,<strong>and</strong><br />
manufacturinggroups.<br />
Finally,aminorsource<strong>of</strong>scenariosinvolvedanupgrade<strong>of</strong>thefunctionality,suchascolour<strong>and</strong>wide-formatprinting.Anexamplescenariois<br />
depictedinTable4.3inaformatdescribedbyBassetal.[2003].<br />
Stimulus<br />
Table 4.3:Anexamplescenario.<br />
Reduce power consumption by turning <strong>of</strong>f<br />
parts <strong>of</strong> the copier machine during low-power<br />
mode<br />
Response Solve in engine specific projects<br />
Source Electronics department<br />
Environment Engine development time<br />
Stimulated arte- Reference architecture documentation<br />
fact<br />
Response measure<br />
4.4.3 Execution<br />
Reuse percentage remains on same level<br />
Inthejointsessioneacharchitectrepresentedaproductasauser<strong>of</strong>the<br />
referencearchitecture.Additionally,allarchitectsplayedtherole<strong>of</strong>assessor.Assome<strong>of</strong>theparticipantshadnoexperienceinSAAMevaluations<strong>and</strong><br />
toexplainthesteps<strong>of</strong>theDSAAMprocess,thesessionstartedwithabrief<br />
introduction<strong>of</strong>theprocess. Fortheprocessobserversalsotherole<strong>of</strong>the<br />
referencearchitectureintheorganisation<strong>of</strong>Océwasexplained.<br />
The step ‘describe the architecture’ was largely omitted during the<br />
DSAAM session, since the DSAAM session only involved people that are<br />
well-informed with respect to the reference architecture <strong>and</strong> extensive<br />
documentationwasalreadyavailable.<br />
Thesecondpart<strong>of</strong>thestep‘developscenarios’wasdoneduringthe<br />
DSAAMsession.Thisinvolvedonlyarchitects<strong>of</strong>productsonwhichthereferencearchitecturewasbased.<br />
Apparently,thescenarioscontributedby<br />
thestakeholdersconsultedpriortothejointsessionarerepresentativefor<br />
whatmaychangeinthefuture,assolicitingforextrascenariosgaveno<br />
results.Assuch,thescenariosgathered<strong>and</strong>elaboratedbytheevaluation<br />
leaderwereused.<br />
Scenarioswereclassified,prioritised,<strong>and</strong>evaluatedasinSAAM,that<br />
is,duringthesessionitself. Thescenarioswereclassified<strong>and</strong>evaluated<br />
onebyone,bypassingprioritisation(Figure4.3onpage64). Figure4.4
4.4. ConductingtheEvaluation 69<br />
givesanimpression<strong>of</strong>thefinalresult<strong>of</strong>theSAAMsession.Scenarioswere<br />
classifiedin directly<strong>and</strong> indirectlysupportedscenarios.<br />
Priority<br />
1<br />
2<br />
3<br />
Direct scenarios Indirect scenarios<br />
concrete floating<br />
low impact high impact<br />
scenario ID<br />
description<br />
characterisation<br />
scenario ID<br />
description<br />
characterisation<br />
scenario ID<br />
description<br />
scenario ID<br />
characterisation<br />
description<br />
characterisation<br />
scenario ID<br />
description<br />
scenario ID<br />
characterisation<br />
description<br />
characterisation<br />
scenario ID<br />
description<br />
scenario ID<br />
characterisation<br />
description<br />
scenario ID<br />
characterisation<br />
description<br />
characterisation<br />
scenario ID<br />
description<br />
characterisation<br />
Figure 4.4:SAAMresults<br />
scenario ID<br />
description<br />
characterisation<br />
scenario ID<br />
description<br />
characterisation<br />
Ingeneral,firsttheimpact<strong>of</strong>ascenarioonaspecificproductwasevaluated,<strong>and</strong>thenitsimpactonthereferencearchitecture.Classification<strong>and</strong>evaluationrequiredadifferentattitudebecausewewereevaluatingareferencearchitectureinstead<strong>of</strong>aproductarchitecture.Thedifficultyliedinthefactthatwhilescenariosareconcrete,representingfuturefunctionality,orthequality<strong>of</strong>actualproducts,thereferencearchitectureisabstract.<br />
Thequestion:“Whatistheimpactonthereferencearchitecture?”neededto<br />
beansweredconsistentlyforallscenarios.Thereforewedefinedtwotypes<br />
<strong>of</strong>directscenarios:<br />
1.Scenariosthataresupportedbythereferencearchitectureasis<strong>and</strong><br />
forwhichitprovides concreteguidelinesonhowtorealisethemin<br />
productinstantiations,<strong>and</strong><br />
2.Scenariosthatcanberealisedbysystemsbasedonthereference<br />
architecture,butforwhichitdoesnot(yet)providedetailedinformationonhowtorealizethem(floating).<br />
Theclass<strong>of</strong> floatingscenarioscallsforacookbookwithrecipesthatdescribesolutionsforvariationpointsinthereferencearchitecture.Cookbookrecipesdescribehowthereferencearchitecturecanbeusedtorealizeaspecific(floating)scenario.Forexample,itmightbenecessarytodescribewhat
70 Chapter4. Evaluation<br />
kind<strong>of</strong>componentsneedtobedefinedorhowsome<strong>of</strong>thealreadydefined<br />
componentsshouldcooperatetoimplementthedesiredbehaviour.Thisinformationcanbeincludedinthereferencearchitectureinaseparatedocumentwithoutaffectingtheexistingdocumentation.Byrealisingscenarios<br />
thiswaythescope<strong>of</strong>reuseisextended<strong>and</strong>thereferencearchitecture’s<br />
classificationmovesfromplatformtowardsproductline(seeSection4.2.2).<br />
Anexample<strong>of</strong>suchacookbookrecipewasthedescription<strong>of</strong>howtorealizesharing<strong>of</strong>hardwareresourceswithinanengine.Therecipeswerejust<br />
newreferencearchitecturedocuments. Infact,some<strong>of</strong>theexistingdocumentsalreadyweresuchrecipes,suchasthedocumentdescribinghow<br />
functioncomponentshouldlooklike, withoutactuallydefiningconcrete<br />
functioncomponents. Thesedocumentshadadifferentnaturethanthe<br />
otherdocumentsthatdescribespecificcomponents<strong>of</strong>thereferencearchitecture,likeascheduler.Figure4.4onthepreviouspageshowsthatmost<br />
<strong>of</strong>thescenariosfallinthiscategory<strong>of</strong>directscenarios.<br />
Theindirectscenarioswere,asusualinSAAM,partitionedintwosubsets:asubsetwith<br />
lowimpact<strong>and</strong>asubsetwith highimpact.Overallthis<br />
assessmentsessiondidnotdiscovermanydesignflaws. Thearchitects<br />
spentmost<strong>of</strong>theirtimeonthesinglehighimpact,highpriorityscenario<br />
(multiplesheetpaths).<br />
Theindirectscenariointeractionwasconsideredverybrieflyasonlya<br />
fewindirectscenarioswerediscovered.Itwasconcludedthatthosedidnot<br />
interact.<br />
4.4.4 OverallEvaluation<br />
Thisfinalstage<strong>of</strong>theassessmentinvolvedtheoverallevaluation,which<br />
resultedinaset<strong>of</strong>strong<strong>and</strong>weakpoints. Theset<strong>of</strong>strongpointsincludestheaforementioneduse<strong>of</strong>thereferencearchitecture<strong>and</strong>itsflexibility;most<strong>of</strong>theevaluatedscenariosaredirectlysupported.<br />
Theset<strong>of</strong>weakpointsincludesadesignflawthatpreventssupportfor<br />
multiplesheetpaths,whichisrequiredforduplexprinting,forinstance.<br />
Additionally, thereferencearchitectureseemedincompleteasitmissed<br />
severalcookbookrecipes. Forexample,recipesforsharinghardwareresources<strong>and</strong>reusingenginepartsamongstdifferentenginesinasingle<br />
copierarecurrentlynotincluded. Anotherweaknesswasthatvariation<br />
pointswerenotexplicitinthedocumentation. Relatedtothisissueisa<br />
missingstructurefordocumentinganinstantiation<strong>of</strong>thereferencearchitecture,anenginegeneration,withrespecttoitsdocumentation.Itwasnot<br />
clearhowconformanceto<strong>and</strong>deviationsfromthereferencearchitecture<br />
shouldbespecifiedbyprojectsthatdevelopsuchaninstantiation. Nevertheless,thisisimportantforthemaintainability<strong>of</strong>thereferencearchitecture<strong>and</strong>itsinstantiations.
4.5. Discussion 71<br />
4.5 Discussion<br />
Belowwebothdiscusstheimplications<strong>of</strong>evaluatingareferencearchitecture<strong>and</strong>usingadistributedSAAMapproach<strong>and</strong>weindicatewherethese<br />
leadtosuggestionsforfuturework<strong>and</strong>researchquestions.<br />
4.5.1 ReferenceArchitecture<br />
ReuseLevel InSection4.2.2wepositionedthereferencearchitectureasa<br />
platform.Furthermoreitsbusinessdriverswereallrelatedtoreuse(Section4.2.1).Thereforethepositioningraisedtwoquestions:isthepositioning<strong>of</strong>thereferencearchitecturecorrectforthecurrentsituation,<strong>and</strong>for<br />
thefuture?Ifcorrect,thecurrentreusepositioningasaplatformshouldbe<br />
supportedbylinksbetweenthedocumentation<strong>of</strong>thereferencearchitecture<br />
<strong>and</strong>thedocumentation<strong>of</strong>instantiatedproducts.Inview<strong>of</strong>thereusepositioning,weexpectaconsiderablereductionintheeffort<strong>of</strong>documentinga<br />
productinstantiationcomparedtoasingle-productarchitectureapproach.<br />
Aprerequisiteforthisconjectureisthattheremustbeasystematicway<br />
<strong>of</strong>documentingproductinstantiationswithrespecttothereferencearchitecture.<br />
Itisunclearwhethersuchasystematicdocumentationprocess<br />
exists.<br />
ResearchquestionCanwedefine<strong>and</strong>deployasystematicprocessfordocumentingproductarchitectureswithrespecttoareferencearchitecture?<br />
Inordert<strong>of</strong>indoutifproductinstancesaredocumentedwithrespect<br />
totheirreferencearchitectureinasystematicwayreusemetricsarerequired[Poulin,1997]todeterminehowmuch<strong>of</strong>thereferencearchitecturedocumentationisreusedintheproductinstancedocumentation.Asanexample<strong>of</strong>suchareusemetric,considertwoindicativefigures:therelative<br />
size<strong>and</strong>anormalisedcohesionfactor. Thesizefactorcalculatesthelines<br />
<strong>of</strong>documentation<strong>of</strong>aproductinstantiationrelativetothesize<strong>of</strong>thereferencearchitecture’sdocumentation.<br />
Thecohesionfactortakesthenumber<br />
<strong>of</strong>referencesfromthedocumentation<strong>of</strong>aconcreteproducttothereference<br />
architecture’sdocumentationthath<strong>and</strong>levariationpoints,normalisedwith<br />
thetotalnumber<strong>of</strong>referencesfromtheproductinstantiationdocumentationtothereferencearchitecture’sdocumentation.Alowrelativesize<strong>and</strong>highcohesionfactorindicateahighreusefactor<strong>and</strong>thusasystematicapproachforreusingthereferencearchitectureinproductinstantiations.<br />
FutureworkDefineametrictopositionareferencearchitecture<br />
withrespecttoscope<strong>of</strong>reuse.
72 Chapter4. Evaluation<br />
Withrespecttothefuturereusepositioning<strong>of</strong>thereferencearchitecture<br />
wewouldexpect,lookingatitsreuse-orientedbusinessdrivers,thatOcé<br />
aimstoincreaseitsreusescope.Thisobjectiveissupportedbytheidentification<strong>of</strong>variousdirectfloatingscenarios,whichwillbeimplementedbythe<br />
developmentteaminacookbook(Figure4.4onpage69).Thisimpliesthat<br />
Océindeedforeseesthatthereusepositioning<strong>of</strong>thereferencearchitecture<br />
israisedfromplatformtos<strong>of</strong>twareproductlineinthenearfuture.<br />
Updates Maintainabilitywasthecentralqualityaspectintheevaluation.<br />
Oneaspect<strong>of</strong>maintainabilityisthepossibilitytoupdatethereference<br />
architecturewithdevelopmentsthattakeplaceinaproductinstantiation:<br />
duringtheobliquelinesinFigure4.2onpage62.Inordertosuccessfully<br />
implementaproposedupdatetwoissuesneedtobeconsidered: conformance<strong>and</strong>permissiveness.Conformanceistheextenttowhichtheproductarchitecture<strong>and</strong>referencearchitecturematch.<br />
Onemustspecifytheupdateinagreementwith<br />
theexistingreferencearchitecture.Thisisnecessary,forexample,topreventspecification<strong>of</strong>updatestocomponentsthatdonotexistatallinthe<br />
referencearchitecture. Thearchitecture<strong>of</strong>aproductmayundergosmall<br />
changesduringitsdevelopment.Consequently,theremaybeadiscrepancy<br />
betweentheproductarchitecture<strong>and</strong>thereferencearchitecture.Thediscrepancymayobstructthetransfer<strong>of</strong>architecturalfragments,e.g.,acookbookrecipe,fromthereferencearchitecturetotheproductarchitecture.<br />
Butitmayalsoobstructtheupdate<strong>of</strong>thereferencearchitectureitself.<br />
Todetectthesearchitecturaldiscrepancies<strong>and</strong>suggestpossiblerepairs,<br />
onecouldchecktheconformancebyfirstusingreverseengineeringtechniquestoraisethelevel<strong>of</strong>abstraction<strong>of</strong>concreteproductarchitectures<br />
<strong>and</strong>thencomparetheresultwiththereferencearchitecture[VanDeursen<br />
etal.,2004].Chapters5<strong>and</strong>ch:ewsa2005investigatehowtoassessconformance<strong>of</strong>architecturespecificationsautomatically.<br />
FutureworkDevelopatechniquetomeasuretheconformance<br />
<strong>of</strong>aproductarchitecturewithrespecttothereferencearchitecture<br />
onwhichitisbasedinordertoassessthepossibilitytotransferfragmentsfromaproductarchitecturetothereferencearchitecture.<br />
Thebarefactthataproducthasanarchitecturethatconformswiththe<br />
referencearchitecturedoesnotensurebyitselfthataproposedupdatewill<br />
besuccessful. Thereferencearchitecturealsohastobepermissivewith<br />
respecttotheupdate. Thereferencearchitecturemustprovidetheflexibilitytoincorporatetheproposedupdate.<br />
Anupdatemightviolatesome<br />
<strong>of</strong>thedesigndecisionstakenearlier;whetherthisisthecaseisinpracticegenerallyhardtoassess.<br />
Onereasonforthisisthatdesigndecisions
4.5. Discussion 73<br />
arenotcompletelydocumented.Mosttimesonlythestructuraleffect<strong>of</strong>a<br />
designdecisionisdocumented. Documentingotheraspects<strong>of</strong>designdecisions,suchastheirrationale<strong>and</strong>effectwithrespectto(non)-functional<br />
requirementsis<strong>of</strong>tenneglected.<br />
ResearchquestionHowcanwedocumentdesigndecisionsexplicitly<strong>and</strong>howcanwethenusethemtoassessanarchitecture’s<br />
permissivenesswithrespecttoaproposedupdate?<br />
Use<strong>of</strong>Reference<strong>Architectures</strong> Besidesitstechnicaluseasastartingpointfor<br />
productspecifics<strong>of</strong>twarearchitectures,thereferencearchitectureserved<br />
accordingtoitsobjectivesasadiscussionplatformforthes<strong>of</strong>twarearchitects<strong>of</strong>differentproducts.Inthatsensethereferencearchitectureindeed<br />
isanefficientwaytoexchangeexperiencesamongproductteams.<br />
Anotheruse<strong>of</strong>thereferencearchitectureappearedduringdiscussions<br />
inthe DSAAMevaluation. Itactsasastableplatformfornegotiations<br />
amongstdifferentdomains: themechatronics,manufacturing,<strong>and</strong>s<strong>of</strong>twarereusegroupsatOcé.Byintroducingageneric<strong>and</strong>morestablearchitecturefortheengines<strong>of</strong>tware<strong>of</strong>Océcopiersthedevelopmentgrouptries<br />
topreventthats<strong>of</strong>twareisautomaticallyconsideredtobethemeansto<br />
solveproblemsduringengineintegration. Assuchdefininganembedded<br />
s<strong>of</strong>twarereferencearchitecturehelpscreatingabetterbalancebetweenthe<br />
differentdisciplinesinvolvedinenginedevelopment.Thisisatypicalproblemintheembeddeds<strong>of</strong>twaredomainaswasalsoobservedintheinventory<br />
describedinChapter3.<br />
Intheevaluationweconducted,theusage<strong>of</strong>thereferencearchitecture<br />
wasnotaddressedexplicitly. Consideringthespecificuse<strong>of</strong>referencearchitecturesdescribedabove,itseemsusefultodoso,especiallyinthecase<br />
<strong>of</strong>embeddedsystems.<br />
ResearchquestionHowcanweincludetheusage<strong>of</strong>areference<br />
architectureinanevaluation?<br />
4.5.2 DistributedSAAM<br />
Themainconcern<strong>of</strong>scenario-basedevaluationmethodsiswhetherthecoverage<strong>and</strong>scopeisbroadenoughtobeconclusiveaboutthefindings<strong>of</strong>the<br />
evaluation. SAAMovercomesthisbyorganisingageneraltwo-daygathering,whichismoderatedbyexperiencedassessors.InDSAAMwehadtotake<br />
alternativemeasures.<br />
Inview<strong>of</strong>thetwoquestionsabove,thenumber<strong>of</strong>directstakeholders<br />
<strong>of</strong>thereferencearchitectureislimited(seeTable4.2onpage66),although
74 Chapter4. Evaluation<br />
manyindirectstakeholderscanbeidentified. Thesetwogroups<strong>of</strong>stakeholdersseemtohavedifferentinterests.<br />
Raisingthescope<strong>of</strong>reuse<strong>of</strong>thereferencearchitecturedirectlyconcerns<br />
thearchitects<strong>of</strong>compatibleproductsasitsusers<strong>and</strong>architects.Itimplies<br />
thatthereferencearchitecturenotonlyshouldidentifyvariationpoints<br />
butalsoexplicitlygivealternatives. Thecookbook<strong>of</strong>theprevioussection<br />
providesthese.<br />
Scenariosthatdescribefuturedevelopment<strong>of</strong>existing<strong>and</strong>foreseen<br />
productsaretheconcern<strong>of</strong>thestakeholders<strong>of</strong>thoseproducts.Thedevelopment<strong>of</strong>thesescenariosistheresponsibility<strong>of</strong>thesestakeholders,which<br />
arenotnecessarilyalsodirectstakeholders<strong>of</strong>thereferencearchitecture.<br />
Ontheotherh<strong>and</strong>theresultingscenariosareinputtoDSAAMsession,thus<br />
indirectlytheyare.<br />
Onemeasurewetooktoincludeindirectstakeholdersintheevaluation<br />
wastosplittheprocess<strong>of</strong>developingtheset<strong>of</strong>scenariosintwostages:an<br />
<strong>of</strong>f-linestagewiththeindirectstakeholders,<strong>and</strong>aDSAAMstagewiththe<br />
directstakeholders. Thescenariosprovidedbytheindirectstakeholders<br />
wereproductspecific.Evaluatingtheimpactonthereferencearchitecture<br />
wasnottheirconcern,butthat<strong>of</strong>thedirectstakeholders. Furthermore<br />
thedirectstakeholdersaretheonlyonescapable<strong>of</strong>doingso. Therefore<br />
becauseonlytheindirectstakeholderswereexcludedfromthejointsession,<br />
thescope<strong>of</strong>theDSAAMsessionwasnotaffectedbythelack<strong>of</strong>stakeholder<br />
interactionduringevaluation.<br />
However,thisalsopreventedindirectstakeholderstointerfereorinteractduringscenarioprioritisation.DuringtheDSAAMsession,thearchitectsconcentratedonthemostlikelyscenarios,fromtheperspective<strong>of</strong>anarchitect.Althoughscenarioswereprioritisedwithrespecttotheirimpact,there<br />
wasnoclearrationaleforthisranking. HenceDSAAM’sscopewasstillat<br />
riskduetothepossibility<strong>of</strong>awrongscenarioprioritisation.<br />
InordertovalidateDSAAM’sscopewerecommendtoorganiseindirect<br />
stakeholder involvement after the joint session. During this feedback<br />
phasestakeholdersmightbeconsultedinsmallsessionsorindividualinterviews,inthesamewayaswedidinpreparationtothesession.<br />
This<br />
timetheindirectstakeholderscancommentonthescenariosprioritisation<strong>and</strong>verifywhethertheevaluationcoveredallrelevantaspects<strong>of</strong>the<br />
architecture. Thispreservesthesmallimpactontheorganisation<strong>of</strong>fered<br />
byDSAAM.Duringthefeedbackphase,indirectstakeholdersmayconclude<br />
thatsomelikelyscenarioshavenotbeenevaluatedthoroughlyenough.<br />
Thusthefeedbackphasemayyieldnewlydevelopedscenarios. Thisnew<br />
set<strong>of</strong>scenarioshastobeevaluatedinanewDSAAMsession.<br />
FutureworkExtendDSAAMwithan<strong>of</strong>f-linefeedbackphaseafterthejointsessionforindirectstakeholders.
4.6. RelatedWork 75<br />
Use<strong>of</strong>Documentation Duringtheassessmentweweresomewhatsurprised<br />
thattheactualdocumentation<strong>of</strong>thereferencearchitecturewasnotusedat<br />
allduringthesession.Thismeansthatthearchitectureassessedistheone<br />
thatisintheteammembers’heads,<strong>and</strong>notthedocumentedarchitecture.<br />
Thecorrespondingriskisthattheteammayhavedifferentarchitectures<br />
intheirminds,thatthedocumentedarchitectureisinadequate,<strong>and</strong>that<br />
architectsnotparticipatingmayhavedifferentperspectives.Thuswehave:<br />
ResearchquestionHowcanweinvolvethearchitectureasdocumentedexplicitlyintheassessmentprocess?<br />
Solutiondirectionswillrequireexplicit,analysablerepresentations<strong>of</strong><br />
boththearchitecture<strong>and</strong>thescenariosusedintheassessment.Aninterestingresearchtopiciswhetherinformationretrievaltechniquescanbe<br />
usedtoanalysetherelationshipbetweenthesetworepresentations.<br />
4.6 RelatedWork<br />
An overview <strong>of</strong> SAAM <strong>and</strong> ATAM, as well as references to many other<br />
methodsforevaluatings<strong>of</strong>twarearchitecturescanbefoundinthebook<br />
byClementsetal.[2002b].<br />
Gallagher[2000]discussestheapplication<strong>of</strong>ATAMtoareferencearchitecture.Unfortunately,hehardlydiscussesanyissuesspecifictotheevaluation<strong>of</strong>referencearchitectures(suchasthedifferentrole<strong>of</strong>scenarios).<br />
Thereferencearchitectureismoreorlessevaluatedasasingle-product<br />
s<strong>of</strong>twarearchitecturewithspecificbusinessdrivers.<br />
Sincetheboundarybetweenproductlinearchitectures<strong>and</strong>reference<br />
architecturesisnotalwaysdistinct(Section4.2),anotherarea<strong>of</strong>relevant<br />
relatedworkisthefield<strong>of</strong>productlineevaluation.Lutz<strong>and</strong>Gannod[2003]<br />
discussthearchitecturalanalysis<strong>of</strong>aproductlinearchitecture. Theauthorspresentathree-phasedapproachconsisting<strong>of</strong>architecturerecovery,<br />
scenario-basedassessment,<strong>and</strong>modelchecking<strong>of</strong>safety-criticalbehaviour.<br />
Hereas<strong>of</strong>twarearchitectureneededtoberecoveredfromanexistingproduct,whichisthenevaluatedinordertoseewhetherthistype<strong>of</strong>productis<br />
amenabletoaproduct-line-developmentapproach.<br />
Ofparticularinterestareevaluationmethodsfocusingonmaintainability.<br />
Thearchitecture-levelmodifiabilityanalysis[Bengtssonetal.,2004]<br />
(ALMA)methodintegratesanumber<strong>of</strong>differentscenario-basedapproaches<br />
forassessingarchitecturemaintainability.
76 Chapter4. Evaluation<br />
4.7 Conclusion<br />
Inthischapterwereportedtheevaluation<strong>of</strong>anembeddeds<strong>of</strong>twarereferencearchitectureusingatailoredSAAM-basedapproach.<br />
Theobjective<strong>of</strong><br />
theassessmentwastoassessthemaintainability<strong>of</strong>thearchitecture.Maintainabilityinvolvedtwoaspects,raisingthescope<strong>of</strong>reusefromaplatform<br />
toaproductline<strong>and</strong>facilitatinganticipatedextensions<strong>of</strong>derivedproducts<br />
<strong>and</strong>futureproducts.<br />
Theevaluation<strong>of</strong>thereferencearchitecturewasbasedonadistributed<br />
SAAM(DSAAM)method, involvingthreephases: apreparationphasein<br />
whichindirectstakeholdersareconsultedindividuallytocollectscenarios,ajointevaluationsessionwithonlyarchitects<strong>and</strong>observers,<strong>and</strong>an<br />
evaluationphase.<br />
Assessingareferencearchitectureisdifferentfromassessingaproduct<br />
architecture. InanordinarySAAMsession,evaluatedscenariosarecategorisedindirectly<strong>and</strong>indirectlysupportedscenarios.<br />
Wesubdividedthe<br />
set<strong>of</strong>directlysupportedscenariosintothosewithevidence<strong>of</strong>beingsupportedbythereferencearchitecture<strong>and</strong>thosewithoutevidence.Thelatter<br />
classtypicallyconsist<strong>of</strong>scenariosforwhichsolutionsareavailableinone<br />
<strong>of</strong>theproducts,butthesehavenotbeendocumentedyet. IntheDSAAM<br />
sessionwedefinedacookbooktocoverthesescenarios.<br />
Theexperienceprovidedvaluableinsightsforindustryaswellasfor<br />
academia. InretrospectwearguedthatDSAAMisasuitableapproachfor<br />
thegivensituation,assessingthemaintainability<strong>of</strong>amaturingreference<br />
architecture.Boththecoverage<strong>of</strong>DSAAM<strong>and</strong>thequality<strong>of</strong>itsconclusions<br />
aretenable.Notethatreference<strong>and</strong>product-linearchitecturesenableefficientreuse,akeybusinessdriverinmanyorganisations.Theconceptsonwhichthistype<strong>of</strong>architecturesarebasedarematuring.Thereforeitisexpectedthatmore<strong>and</strong>morecompanieswilladoptaproduct-lineapproach,<br />
possiblyinvolvingreferencearchitectures.<br />
Océgainedinsightinthepositioning<strong>and</strong>status<strong>of</strong>thereferencearchitectureintheirorganisation,itscurrentposition,<strong>and</strong>itsfutureposition.<br />
Océalsogainedconfidenceinitsmaintainability.<br />
Wegainedinsightintheprocess<strong>of</strong>assessingareferencearchitecture.<br />
Forinstance,scenariosaretypicallyevaluatedbasedonaproductinstance<br />
<strong>and</strong>theresultsareabstractedtothereferencearchitecture. Thisevokes<br />
allkinds<strong>of</strong>questionsrelatedtotopicssuchasconformancechecking<strong>and</strong><br />
documentingdesigndecisions,asdiscussedinSection4.5.
Chapter5<br />
<strong>Model</strong>-<strong>Driven</strong> Consistency Checking<br />
<strong>of</strong> Behavioural Specifications 1<br />
For the development <strong>of</strong> s<strong>of</strong>tware intensive systems different types <strong>of</strong> behaviouralspecificationsareused.<br />
Althoughsuchspecificationsshouldbe<br />
consistentwithrespecttoeachother,thisisnotalwaysthecaseinpractice.<br />
Maintainabilityproblemsaretheresult. Inthischapterwepropose<br />
atechniqueforassessingtheconsistencybetweentwotypesbehavioural<br />
specifications: scenarios<strong>and</strong>statemachines. Thetechniqueisbasedon<br />
thegeneration<strong>of</strong>statemachinesfromscenarios. Wespecifytherequired<br />
mappingusingmodeltransformations. Theuse<strong>of</strong>technologiesrelatedto<br />
the<strong>Model</strong><strong>Driven</strong>Architectureenableseasyintegrationwithwidelyadopted<br />
(UML)tools.Weappliedourtechniquetoassesstheconsistencybetweenthe<br />
behaviouralspecificationsfortheembeddeds<strong>of</strong>tware<strong>of</strong>copiersdeveloped<br />
byOcé. Finally,weevaluatetheapproach<strong>and</strong>discussitsgeneralisability<br />
<strong>and</strong>widerapplicability.<br />
5.1 Introduction<br />
Systemunderst<strong>and</strong>ingisaprerequisiteformodifyingas<strong>of</strong>twareintensive<br />
system[Lehman<strong>and</strong>Belady,1985].Assuchthe(typical)absence<strong>of</strong>up-todatedesigndocumentationhamperssuccessfuls<strong>of</strong>twaremaintenance<strong>and</strong><br />
evolution. Inthischapterweaddressthisproblemforthedocumentation<br />
<strong>of</strong>asystem’sbehaviour. Wefocusonensuringtheconsistencybetween<br />
twotypes<strong>of</strong>behaviouralspecifications:interaction-based<strong>and</strong>state-based<br />
1 Thischapterwaspublishedearlieras:Graaf,Bas<strong>and</strong>ArievanDeursen. <strong>Model</strong>-driven<br />
consistencychecking<strong>of</strong>behaviouralspecifications.InProceedings<strong>of</strong>the4 th International<br />
Workshopon<strong>Model</strong>-basedMethodologiesforPervasive<strong>and</strong>EmbeddedS<strong>of</strong>tware(MOM-<br />
PES2007),pages115–126.IEEEComputerSociety,2007a<br />
77
78 Chapter5. <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
Requirements<br />
Use cases<br />
Architecture<br />
Scenarios<br />
Stakeholders<br />
Architect<br />
State machines<br />
Maintenance<br />
Mistakes<br />
Developers<br />
Shortcuts<br />
Inconsistencies<br />
Tools/Developers<br />
Problems<br />
Components<br />
Product<br />
Figure 5.1:Typicaldevelopmentprocess<br />
Integrator<br />
behaviouralmodels. Theuse<strong>of</strong>suchspecificationsisillustratedbythe<br />
developmentprocessdepictedinFigure5.1.Itisbasedonthewell-known<br />
V-model[Bröhl<strong>and</strong>Dröschel,1995]<strong>and</strong>thestartingpoint<strong>of</strong>ourresearch.<br />
Ontheleftbranch<strong>of</strong>the‘V’analysisactivitiestakeplace.Basedon Requirements,thehigh-level<br />
Architectureisdefined.Thisarchitectureidentifies<br />
themaincomponents<strong>of</strong>thesystem<strong>and</strong>assignsresponsibilities.Inparallelrequirementsaremademoreconcreteby<br />
Use casesthatspecifytypical<br />
interactionsausermayhavewiththesystem. Onedistinctiveproperty<br />
<strong>of</strong>usecasesisthatthesystemisconsideredtobeablackbox[Jacobson,<br />
1992].Theseusecasesarethefirstinteraction-basedbehaviouralmodels.<br />
Basedontheusecasesaset<strong>of</strong> Scenariosisdefinedthatspecifiesthe<br />
interactions<strong>of</strong>thesystem’scomponentsinterms<strong>of</strong>exchangedmessages.<br />
Typically,everyusecaseresultsinone(normalbehaviour)ormore(includingexceptionalbehaviour)scenarios.Thesescenariosarealsointeractionbasedbehaviouralmodels,butnowthesystemisconsideredtobeawhitebox;<br />
theyshowtheinteractionsbetweenthecomponentsdefinedbythe<br />
architecture.<br />
Eventually,thearchitecture’scomponentsneedtobeimplemented.This<br />
requiresacompletebehaviouralspecification.Scenariosare,however,not<br />
intendedtoprovidesuchaspecificationforanindividualcomponent.First,<br />
thespecification<strong>of</strong>acomponent’sbehaviourisscatteredacrossmultiple<br />
scenarios.Second,theyareusuallyonlydefinedforthecomponents’most<br />
typical<strong>and</strong>importantbehaviours. Therefore,acompletestate-basedbehaviouralmodel,aState<br />
machine,iscreatedforeachcomponentbasedon<br />
theset<strong>of</strong>scenarios. Thisstatemachineisusedtoimplementorgener-
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)
80 Chapter5. <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
copiermanufacturer. AtOcéanimportantcopiersubsystemisdeveloped<br />
usingaprocesscorrespondingtoFigure5.1onpage78.Moreover,thecomponentsforthissubsystemaregeneratedfromstatemachinemodels.<br />
As<br />
such,debugging,forinstance,isperformedonthelevel<strong>of</strong>statemachines.<br />
Asaresultinconsistenciesbetweenscenarios<strong>and</strong>statemachinesbecome<br />
evenmorelikely,makingitaconcernforOcé.Otherworkontherelation<br />
betweenscenarios<strong>and</strong>statemachinesisdiscussedinSection5.3.Theenablingtechnologiesforourapproach,aswellas,therelevantpart<strong>of</strong>the<br />
underlyingUMLspecification,<strong>and</strong>ourprocessforconsistencycheckingare<br />
discussedinSection5.4.InSection5.5wecustomiseanexistingmapping<br />
betweenscenarios<strong>and</strong>statemachinesbasedonWhittle<strong>and</strong>Schumann<br />
[2000]forspecificationasmodeltransformations<strong>and</strong>consistencychecking.<br />
Theapplication<strong>of</strong>ourapproachtotheOcécaserequiresthatthescenariosasfoundinOcé’sarchitecturedocumentationarenormalisedintoaformsuitedforthemodeltransformations<strong>of</strong>ourapproach.Afternormalisation<strong>and</strong>application<strong>of</strong>ourapproachweidentifiedseveralinconsistenciesinthebehaviouralspecificationsthatcouldleadtointegration<strong>and</strong>maintenanceproblems.ThisisdiscussedinSection5.6.Finally,wereflectonour<br />
approachinSection5.7<strong>and</strong>concludewithanoverview<strong>of</strong>thecontributions<br />
<strong>of</strong>thischapter<strong>and</strong>opportunitiesforfutureworkinSection5.8.<br />
5.2 RunningExample<br />
Ourmotivationforinvestigatingtheconsistencybetweeninteraction-<strong>and</strong><br />
state-basedbehaviouralmodelscomesfromaproduct-linearchitecturefor<br />
s<strong>of</strong>twareincopiersdevelopedbyOcé.Weusethisarchitectureasourrunningexample<strong>and</strong>casestudy,<strong>and</strong>forthatreasonbrieflyexplainitfirst.<br />
AtOcéareferencearchitectureforcopierenginesisdeveloped. Ina<br />
copierboththescanning<strong>and</strong>printingsubsystemsarereferredtoasan<br />
engine. Thereferencearchitecturedescribesanabstractenginethatcan<br />
beinstantiatedfor(potentially)anyOcécopier.<br />
Asarunningexampleweuseone<strong>of</strong>thereferencearchitecture’scomponents:theEngineStatusManager(ESM).<br />
Thiscomponentisresponsible<br />
forh<strong>and</strong>lingstatusrequests<strong>and</strong>statusupdatesintheengine. ESM<strong>and</strong><br />
theothermaincomponents<strong>of</strong>thereferencearchitecturearedepictedin<br />
Figure5.2.<br />
Inacopierengine ESMcommunicateswithtwotypes<strong>of</strong>components:<br />
statuscontrol Clients,<strong>and</strong> Functions. Clientsrequestenginestatetransitions.<br />
Requestsbytheexternalstatuscontrolclient(Controller)aretranslatedby<br />
the EAI(EngineAdapterInterface)component.Toperformstatusrequests<br />
<strong>of</strong> Clients, ESMcontrolsthestatus<strong>of</strong>individual Functioncomponents. Functions,inturn,recursivelycontrolthestatus<strong>of</strong>theircomposing<br />
Functions.
5.2. RunningExample 81<br />
Figure 5.2:Architectureforcopierengines<br />
Forthedevelopment<strong>of</strong> ESM<strong>and</strong>othercomponents,aprocessisused<br />
similartotheprocessoutlinedinSection5.1.ForthisOcéreliesonamodeldrivenapproachbasedon<br />
UML[Dohmen<strong>and</strong>Somers,2003]. Architects<br />
specifyusecaserealisationsusingUMLsequencediagrams.Basedonthese<br />
diagrams,foreverycomponentaUMLstatechartdiagramiscreated.Using<br />
specialtooling 1 ,thesourcecodefortheenginecomponents(e.g., ESM)is<br />
largelygeneratedbasedonthosestatechartdiagrams.ForOcé’sdevelopers<br />
thesestatechartdiagramsactuallyaretheimplementation.<br />
One<strong>of</strong>thereasonsforintroducinga(automated)model-drivendevelopmentapproachwastoovercomeconsistencyproblemswithrespectto<br />
statemachinemodels<strong>and</strong>sourcecode[Dohmen<strong>and</strong>Somers,2003]. By<br />
automaticallygeneratingsourcecodefromstatemachinesthisproblemis<br />
effectivelymoved‘upwards’totheconsistencybetweenscenarios<strong>and</strong>state<br />
machines.<br />
ForESM,eachusecaseaddressesaspecificenginestatetransition. A<br />
usecaseisaccompaniedbyaUMLsequencediagram.Asanexample,considerthediagraminFigure5.7(a)onpage96.<br />
Itdepictstheinteraction<br />
thatoccurswhenacopierengineisrequestedtogotost<strong>and</strong>by,whileitis<br />
running. AtOcéthesesequencediagramsarepurelyusedforcommunicationpurposes,ratherthanasinputforautomaticprocessing(e.g.,model<br />
transformations,orcodegeneration).Because<strong>of</strong>this,theyarenotalways<br />
complete<strong>and</strong>precise. Furthermore,proprietary(non-UML)constructsare<br />
used. Asanexample,inthesesequencediagramsthelifeline<strong>of</strong>theESM<br />
componentisdecoratedwiththename<strong>of</strong>its(high-level)stateatthatpoint<br />
<strong>of</strong>theinteraction.<br />
Toensuresuccessfulevolution<strong>and</strong>maintenance<strong>of</strong>thereferencearchitecture<strong>and</strong>thecomponentsitdefines,ameanstoassesstheconsistencybetweentheinvolvedbehaviouralspecificationsisessential.Itisthischallengeweaddressinthischapter.<br />
1 IBMRationalRoseTechnicalDeveloper-http://www.ibm.com/s<strong>of</strong>tware/awdtools/<br />
developer/technical(June2007)
82 Chapter5. <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
5.3 RelatedWork<br />
Several formal approaches have been proposed that address problems<br />
similartoours. Lam<strong>and</strong>Padget[2003]translateUMLstatechartsinto πcalculustodeterminebehaviouralequivalenceusingbisimulation.Schäferetal.[2001]presentatoolthatusesmodelcheckingtoverifystatemachines<br />
against collaboration diagrams. The use <strong>of</strong> such tools <strong>and</strong> approachesrequirescomplete,precise<strong>and</strong>integratedinteraction-<strong>and</strong>statebasedbehaviouralmodels.<br />
Thisimplies,forinstance,thatsending<strong>and</strong><br />
reception<strong>of</strong>messagesinscenariosareexplicitlylinkedtoevents<strong>and</strong>effectsinstatemachines.<br />
Inourcase,forthesequencediagrams,thisis<br />
problematic. Theyarecreatedearlyinthedevelopmentprocess<strong>and</strong>not<br />
intendedtobecompleteorprecise.<br />
Totakethisintoaccount,wegenerateastatemachinefromaset<strong>of</strong><br />
inputscenarios,that,subsequently,iscomparedtothestatemachinethat<br />
wascreatedbythedevelopers.<br />
Manyapproacheshavebeendefinedforsynthesis<strong>of</strong>state-basedmodels<br />
fromscenario-basedmodels. Amyot<strong>and</strong>Eberlein[2003],<strong>and</strong>Liangetal.<br />
[2006]bothevaluateovertwenty<strong>of</strong>them.Evaluationcriteriaincludelanguages,meanstodefinescenariorelationships<strong>and</strong>statemodeltype.Our<br />
industrialcasegivesustherequirementswithrespecttothesecriteriafor<br />
asynthesisapproach.<br />
Instead<strong>of</strong>usingamorepowerfulscenariolanguagesuchaslivesequencecharts[Damm<strong>and</strong>Harel,2001],welimitourselvestoUMLsequence<br />
diagramsaugmentedwithdecorations,asdictatedbyourindustrialcase<br />
study.Thedecorationswithstateinformationcanbeinterpretedasconditionsfromwhichinter-scenariorelationshipscanbederived.Finally,with<br />
respecttostatemodeltype,weconsiderapproachesthatresultinstate<br />
modelsforindividualcomponents(instead<strong>of</strong>globalstatemodels). ConsideringLiangetal.[2006]oneapproachbestmeetstheserequirements,<br />
namelytheoneproposedbyWhittle<strong>and</strong>Schumann[2000].<br />
Whittle<strong>and</strong>Schumann[2000]presentanalgorithmtomap UMLsequencediagramstoUMLstatecharts.<br />
Inthismappingthemessagesina<br />
scenarioarefirstannotatedwithpre-<strong>and</strong>postconditionsonstatevariables,<br />
referredtoasadomaintheory. Themappingisbasedontheassumption<br />
thatamessageonlyaffectsastatevariableifitspre-orpostconditionexplicitlyspecifiesitdoes;thedomaintheorydoesnotneedtobecomplete.<br />
Thus,thisso-calledframeaxiom 1 ,togetherwiththepre-<strong>and</strong>postconditions,resultsinapair<strong>of</strong>statevectorsforeachmessage(before<strong>and</strong>after).<br />
1 Thenamederivesfromacommontechniqueusedbyanimatedcartoonmakerscalled<br />
framingwherethecurrentlymovingparts<strong>of</strong>thecartoonaresuperimposedonthe<br />
‘frame’,whichdepictsthebackground<strong>of</strong>thescene,whichdoesnotchange(http://en.<br />
wikipedia.org/wiki/Frame_problem(June2007)).
5.4. <strong>Model</strong>-<strong>Driven</strong>ConsistencyChecking 83<br />
Foreveryscenarioitischeckedwhetherthemessageorderingisconsistent<br />
withthedomaintheory. Ifnot,eitheronecanbereconsidered. Then,for<br />
eachscenarioa‘flat’statemachineisgeneratedforeverycomponent.Messagestowardsacomponentresultinaneventthattriggersatransition;messagesdirectedawayfromacomponentresultinanactionthatisexecuteduponatransition.Loopsareidentifiedbydetectingstatesthathaveunifiablestatevectors.Twostatesvectorsareunifiableiftheydonotspecifydifferentvaluesforthesamestatevariable.Subsequently,the‘flat’state<br />
machinesgeneratedforacomponentfromdifferentscenariosaremerged<br />
bymergingsimilarstates. Twostatesaresimilariftheirstatevectoris<br />
identical<strong>and</strong>theyhaveatleastoneincomingtransitionwiththesamelabel.<br />
Hierarchyisaddedtotheresultingstatechartsbyauserprovided<br />
subset<strong>and</strong>(partial)ordering<strong>of</strong>thestatevariables.<br />
V<strong>and</strong>erAalstetal.[2004]presentanapproachforthediscovery<strong>of</strong><br />
(business)processmodelsfromeventlogs. Instead<strong>of</strong>statemodels,they<br />
usePetrinetsasprocessmodels.Wheretheyonlyrelyonevent(message)<br />
sequencetomergedifferentworkflowinstances(scenarios),werelyonstate<br />
variablesaswell.<br />
Mostworkinthisareafocusesonthesynthesisalgorithm,whereasthe<br />
integrationinindustrialpracticeremainsimplicit. Infact,many<strong>of</strong>the<br />
approachesarenotsupportedbyatoolorvalidatedinindustrialpractice.<br />
Theirapplicationinpracticeonlybecomesrealisticwhentheyintegrate<br />
withexistingtools<strong>and</strong>st<strong>and</strong>ardsusedinindustry.Therefore,wefocusin<br />
thischapteronUMLsequencediagramsasanotationforscenarios,<strong>and</strong>on<br />
UMLstatemachines.<br />
5.4 <strong>Model</strong>-<strong>Driven</strong>ConsistencyChecking<br />
Inthissectionweoutlineourapproachforconsistencychecking<strong>of</strong>behaviouralspecifications,but,first,weintroducethetechnologiesthatenableourmodel-drivenapproach<strong>and</strong>theunderlyingstructure<strong>of</strong>theinvolvedbehaviouralmodels.<br />
5.4.1 EnablingTechnologies<br />
Ourapproachtakesadvantage<strong>of</strong>thest<strong>and</strong>ardsthatarewidelyusedin<br />
industry,suchasUML<strong>and</strong>XMLMetadataInterchange 1 (XMI),enablingeasy<br />
integrationwiththetoolsusedinindustrialpractice.XMIprovidesameans<br />
toserialiseUMLmodelstobemanipulated,forinstance,usingExtensible<br />
StylesheetLanguageTransformations 2 (XSLT). However,theXMIformat<br />
1 http://www.omg.org/mda/specs.htm#XMI(June2007)<br />
2 http://www.w3.org/TR/xslt(June2007)
84 Chapter5. <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
isveryverbose,makingitatedious<strong>and</strong>errorpronetasktodevelopsuch<br />
transformations[VanDijketal.,2005].<br />
<strong>Model</strong><strong>Driven</strong>Architecture 1 (MDA)developedbytheObjectManagement<br />
Group 2 (OMG)<strong>of</strong>fers,amongothers,asolutiontothisproblem.MDAisOMG’s<br />
incarnation<strong>of</strong>model-drivenengineering(MDE).WithMDE,s<strong>of</strong>twaredevelopmentlargelyconsists<strong>of</strong>aseries<strong>of</strong>modeltransformationsmappinga<br />
sourcetoatargetmodel. EssentialtoMDEaremodels,theirassociated<br />
metamodels,<strong>and</strong>modeltransformations.Inthecase<strong>of</strong>MDA,metamodels<br />
aredefinedusingtheMetaObjectFacility 3 (MOF). TheUMLmetamodelis<br />
onlyoneexample<strong>of</strong>suchmetamodels.Finally,modeltransformationlanguagesareusedtodefinetransformations.<br />
WeusetheAtlasTransformationLanguage[Jouault<strong>and</strong>Kurtev,2005]<br />
(ATL) 4 tospecify<strong>and</strong>implementthemappingbetweenscenarios<strong>and</strong>state<br />
machines. ATLisusedtodevelopmodeltransformationsthatareexecutedbyatransformationengine.<br />
WithATL,transformationsaredefined<br />
intransformationmodulesthatconsist<strong>of</strong>transformationrules<strong>and</strong>helper<br />
operations. Thetransformationrulesmatchmodelelementsinasource<br />
model<strong>and</strong>createelementsinatargetmodel.Tothisendtherulesdefine<br />
constraintsonmetamodelelementsinasyntaxsimilartothat<strong>of</strong>theObject<br />
ConstraintLanguage 5 (OCL).Ahelperisdefinedinthecontext<strong>of</strong>ametamodelelement,towhichiteffectivelyaddsafeature.Helperscanbeused<br />
inrules,<strong>and</strong>optionallytakeparameters.<br />
TheATLtransformationenginecanbeusedwithXMIserialisations<strong>of</strong><br />
models<strong>and</strong>metamodelsdefinedusingtheMOF.Forthesequencediagrams<br />
<strong>and</strong>statemachinesinthischapterweusedtheMOF-UMLmetamodelavailablefromtheOMG[OMG,2007a].Tocreatetheassociatedmodels,aUML<br />
modellingtoolsupportingXMIexportcanbeused(weusedPoseidonfor<br />
UML 6 forthispurpose).<br />
Oncethesourcemodel<strong>and</strong>metamodel,targetmetamodel,<strong>and</strong>transformationmodulearedefined<strong>and</strong>located,theATLtransformationengine<br />
generatesthetargetmodelinitsserialisedform,which,inturn,canbe<br />
importedintoaUMLmodellingtoolforvisualisation,orcanserveassource<br />
modelforanother(model)transformation.<br />
1 http://www.omg.org/mda(June2007)<br />
2 http://www.omg.org(June2007)<br />
3 http://www.omg.org/m<strong>of</strong>(June2007)<br />
4 ForamoredetailedintroductiontoATL,pleaserefertoSection2.3.3.<br />
5 http://www.omg.org/technology/documents/modeling_spec_catalog.htm#OCL(June2007)<br />
6 http://www.gentleware.com(June2007)
5.4. <strong>Model</strong>-<strong>Driven</strong>ConsistencyChecking 85<br />
5.4.2 Behavioural<strong>Model</strong>ling<br />
<strong>Model</strong>Element<br />
+name:Name<br />
+ constrainedElement * {ordered}<br />
+ constraint *<br />
Constraint<br />
+body:BooleanExpression<br />
Figure 5.3:Constraints<br />
Forthecreation<strong>of</strong>interaction-based<strong>and</strong>state-basedbehaviouralmodels<br />
weuseUMLsequence<strong>and</strong>statechartdiagrams. Theunderlyingstructure<br />
<strong>of</strong>thesediagramsisdescribedbytheCollaborations<strong>and</strong>StateMachines<br />
subpackages<strong>of</strong>theUMLmetamodel.Becauseourtransformationrulesare<br />
definedonthemetamodellevel,weintroducethesepackagebriefly. Althoughwediscussonlysimplifiedversions<strong>of</strong>thesepackages,theimplementation<strong>of</strong>ourtechnique<strong>and</strong>ourcasestudyarebasedonthecomplete<br />
UMLmetamodel(version1.4[OMG,2007a]).<br />
IngeneraltheUMLmetamodelallowseverymodelelementtobeassociatedwithanorderedset<strong>of</strong>constraintsascanbeseenfromFigure5.3.<br />
NotethateverymodelelementinUMLisaspecialisation<strong>of</strong> <strong>Model</strong>Element.<br />
Weusethistoaddpre-<strong>and</strong>postconditiontomessages<strong>and</strong>stateinvariants<br />
tostates.Todistinguishbetweenpreconditions,postconditions,<strong>and</strong>other<br />
constraintsthatmightbeusedinthemodelweusestereotypes.<br />
Source:Collaborations TheCollaborationpackage<strong>and</strong>someotherUMLelementsaredepictedinFigure5.4onthefollowingpage.<br />
Inthecontext<br />
<strong>of</strong>aCollaborationthecommunicationpatternsperformedby Objectsarerepresentedbyaset<strong>of</strong><br />
Messagesthatispartiallyorderedbythe predecessor<br />
relation. Foreachmessage, sender<strong>and</strong> receiver Objectsarespecified. The<br />
cause<strong>of</strong>aMessageisaCallAction(dispatchAction)thatisassociatedwithan<br />
Operation. Inturn,this Operationispart<strong>of</strong>the Classthatisthe classifier<strong>of</strong><br />
the Objectthatreceivesthe Message. Finally,aClassoptionallycontains<br />
Attributesthathaveatype.<br />
Target: StateMachines Usingthe(target)metamodelinFigure5.5onthe<br />
nextpage,UMLstatemachinescanbeconstructedthatmodelbehaviouras<br />
atraversal<strong>of</strong>agraph<strong>of</strong>statenodesinterconnectedbytransitionarcs.<br />
Astatenode,or StateVertex,isthe targetor source<strong>of</strong>anynumber<strong>of</strong> Transitions<strong>and</strong>canbe<strong>of</strong>differenttypes.A<br />
Staterepresentsasituationinwhich
86 Chapter5. <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
Collaboration<br />
Object<br />
Message<br />
CallAction<br />
−actualArgument:int<br />
Class<br />
+isActive:Boolean<br />
*<br />
dispatchAction<br />
+<br />
classifier<br />
+<br />
predecessor<br />
*<br />
sender<br />
+<br />
receiver<br />
+<br />
ownedElement<br />
+<br />
*<br />
*<br />
Operation<br />
Attribute<br />
operations<br />
+ *<br />
operation<br />
+<br />
type<br />
+<br />
attributes<br />
+<br />
*<br />
Figure 5.4:Collaborations(simplified)<br />
StateMachine<br />
State<br />
0..1<br />
top<br />
+<br />
CompositeState SimpleState<br />
StateVertex<br />
Pseudostate<br />
+kind:PseudostateKind<br />
Transition<br />
outgoing<br />
+<br />
*<br />
source<br />
+<br />
incoming<br />
+<br />
*<br />
target<br />
+<br />
Action<br />
+script:ActionExpression<br />
effect<br />
+<br />
0..1<br />
Event<br />
*<br />
trigger<br />
+<br />
0..1<br />
0..1<br />
transitions<br />
+<br />
*<br />
container<br />
+<br />
0..1<br />
subvertex<br />
+ *<br />
Figure 5.5:Statemachines
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,
88 Chapter5. <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
wefirstrequiremodelstobenormalised.ThisisdiscussedinSection5.6.1.<br />
Finally,thegeneratedstatemachineiscomparedtothestatemachine<br />
thatwasalreadydevelopedbasedonthesameset<strong>of</strong>scenarios,theimplementationstatemachine.Becausethesequencediagramsarecreatedearlyoninthedevelopmentprocess,itisnotexpectedthattheyareexactlycoveredbythestatemachines.<br />
Therefore,mismatchesareexpectedbetween<br />
thegenerated<strong>and</strong>implementationstatemachinewithrespecttotransition<br />
labels<strong>and</strong>order.Thismakesautomatingthecomparisonstepparticularly<br />
difficult.Fornowwemanuallycomparethegenerated<strong>and</strong>implementation<br />
statemachine<strong>and</strong>mainlyfocusoninconsistencieswithrespecttotop-level<br />
states<strong>and</strong>transitions.<br />
As such, we use three steps to check the consistency between behaviouralspecifications:<br />
normalise,transform,<strong>and</strong>compare. Inthecurrentapproachonlythetransformationisautomatic.<br />
Furthermore, the<br />
normalisationstepiscontext-specificasitdependsonthetype<strong>of</strong>input<br />
models.<br />
5.5 GeneratingStateMachines<br />
Giventhesource<strong>and</strong>targetmetamodelsdiscussedintheprevioussection,<br />
wenowdescribehowtoinstantiatesourcemodels,aswellasthemapping<br />
betweensource<strong>and</strong>targetmodels,expressedas ATLmodeltransformations.Wepublishedall(executable)ATLtransformationsthatweimplemented,aswellas(normalised)source<strong>and</strong>target(meta)modelsforthe<br />
ATMexample<strong>of</strong>Whittle<strong>and</strong>Schumann[2000]intheATLtransformations<br />
repository 1 .<br />
5.5.1 InstantiatingaSource<strong>Model</strong><br />
Ourapproachbasedonmodeltransformations<strong>and</strong>UMLrequiresthatall<br />
necessaryinformationisencodedinaUMLmodel.Whittle<strong>and</strong>Schumann<br />
[2000]requiresthefollowinginformationforitsmapping:scenarios,adomaintheory,aset<strong>of</strong>statevariables,<strong>and</strong>anorderedsubset<strong>of</strong>thatset.<br />
Theset<strong>of</strong>scenariosisspecifiedassequencediagrams. Thetypes<strong>of</strong><br />
theinteractingObjects(components)arespecifiedinaclassmodel. The<br />
Classthatcorrespondstothecomponent<strong>of</strong>interestismarkedactive. All<br />
Operationsinvolvedintherelevantscenariosarealsospecified. Thepre<strong>and</strong>postconditions<strong>of</strong>adomaintheoryareappliedtotheseOperationsas<br />
stereotypedConstraints.TheseConstraintshavetheform state variable<br />
= value.Wecurrentlydonotallowpre-<strong>and</strong>postconditionsinthedomain<br />
1 http://www.eclipse.org/gmt/atl/atlTransformations/UMLSD2STMD
5.5. GeneratingStateMachines 89<br />
theorythatrefert<strong>of</strong>ormalparameters<strong>of</strong>theoperationsinvolved,asthis<br />
wouldrequireinterpretation<strong>of</strong>theseconditions. Ifnecessary,suchconstraintscanbeaddeddirectlytotheMessagesthatspecifyanactualparameterinthesequencediagrams.TheactiveClasscontainsanAttributeforeachstatevariable.Thesubset<strong>of</strong>statevariablesusedforintroducinghierarchyisencodedbysetting<br />
thevisibility<strong>of</strong>allstatevariablesincludedinthesubsettopublic<strong>and</strong>the<br />
otherstoprivate.Finally,theorder<strong>of</strong>thestatevariableAttributesonthe<br />
Classrepresentstheprioritisation<strong>of</strong>statevariables(thetoponehaving<br />
thehighestpriority). Thispriorityindicatestheorderinwhichthestate<br />
variablesareusedtopartitiontheset<strong>of</strong>statesbyassigningthesestatesto<br />
CompositeStatesaccordingtothevalueassignedtothestatevariable.<br />
5.5.2 <strong>Model</strong>Transformations<br />
Ourtransformationsgenerateastatemachineforthecomponentthatis<br />
representedbytheactiveClassinthesourcemodel. Ascenariospecifiesoneparticularpaththroughthestatemachineforthatcomponent,on<br />
whichitproceedstothenextstateuponeachcommunication.Wereferto<br />
thestatemachinethatonlydescribesthatpathasa‘flat’statemachine.<br />
WetailoredtheapproachinWhittle<strong>and</strong>Schumann[2000](seeSection5.3)toaccountforthetype<strong>of</strong>inputintheOcécase,forourmodeldrivenstrategy,<strong>and</strong>forourgoal:<br />
consistencychecking. Forthisreason<br />
weintroducefewerabstractions,makingdetecting<strong>and</strong>resolvinginconsistenciesmoreconvenient.<br />
Ourmappingconsists<strong>of</strong>fourseparatesteps:1)<br />
applythedomaintheory,2)generateflatstatemachines,3)mergeflatstate<br />
machines,<strong>and</strong>4)introducehierarchyintothemergedstatemachine.<br />
WeformalisedourmappingfromscenariostostatemachinesasfourATL<br />
modeltransformationsthatcorrespondtothefoursteps<strong>of</strong>ourmapping.<br />
Everyconsecutivetransformationusesthetargetmodel<strong>of</strong>theprevious<br />
transformationasitssourcemodel.<br />
Together,thesetransformationsarespecifiedinlessthan700lines<strong>of</strong><br />
ATLcode. BeforethesetransformationscanbeappliedtotheOcécase,a<br />
normalisationstepisrequired,whichisdiscussedinSection5.6.1.<br />
ApplyDomainTheory Thisstepisspecifictoourapproach. UnlikeWhittle<br />
<strong>and</strong>Schumann[2000], butinaccordancewith UML, wedistinguishbetweenpre-<strong>and</strong>postconditionsontheOperations<strong>of</strong>aClass<strong>and</strong>thoseon<br />
theCallActionsassociatedwithMessagesinasequencediagram.Thishas<br />
twoadvantages. First,itallowsforsimplepre-<strong>and</strong>postconditionstobe<br />
specifiedonlyonce(i.e.,onaClass’Operations).Second,itcircumventsthe
90 Chapter5. <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
rule ConstrainedCallAction {<br />
from ca_in:UML!CallAction<br />
to ca_out:UML!CallAction(<br />
operation
5.5. GeneratingStateMachines 91<br />
rule EffectTransition {<br />
from m:UML!Message (m.sender.isActive)<br />
to t_effect: UML!Transition(<br />
effect
92 Chapter5. <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
Figure 5.6:Flatstatemachine<br />
subsequentlytothepostconditions<strong>of</strong>thecurrentMessage(’posts’),the<br />
preconditions<strong>of</strong>thecurrentMessage(pres), <strong>and</strong>thestatevectorafter<br />
thepreviousMessage(stateVectorPrev). Assuchconditionspropagatein<br />
‘forward’direction(i.e.,downwardsinasequencediagram).<br />
Additionallythe stateVectorhelpernotifiestheuserifaninconsistency<br />
isdetectedbetweenthestatevectorafterthepreviousMessage<strong>and</strong>the<br />
preconditionsforthecurrentMessage(thesesets<strong>of</strong>Constraintsshouldbe<br />
unifiable).<br />
The framehelpersimplyiteratesovertheConstraintsinthe frameargument<strong>and</strong>addseveryconstraintinvolvingastatevariablethatisnot<br />
referredtoin framedtothatset.<br />
UnlikeWhittle<strong>and</strong>Schumann[2000],wedonotapplyunification<strong>of</strong><br />
statevectorsatthisstage. Thedeclarativestyle<strong>of</strong>ourATLspecifications<br />
resultsinaninfiniterecursion:tocompleteastatevectorweneedtoknow<br />
whetheritcanbeunifiedwithotherstatevectors. Todeterminethiswe<br />
havetoconsiderstatevectorsin‘forward’aswellasin‘backward’direction.<br />
However,todeterminethestatevectorsin‘forward’direction,we,inturn,<br />
havetoconsiderstatevectorsin‘backward’directionbecause<strong>of</strong>theframe<br />
axiomstrategy.<br />
Application<strong>of</strong>thisstepyieldsaset<strong>of</strong>flatstatemachinesforacomponent.Asanexample,considerFigure5.6.Itdepictstheflatstatemachine<br />
correspondingtothesequencediagraminFigure5.7(b)onpage96. Note<br />
thattheexampleonlyinvolvesasinglestatevariable<strong>and</strong>thatthenames<br />
<strong>of</strong>theStatesarederivedfromtheparticularMessagethatwassentorreceivedbythecomponent.
5.5. GeneratingStateMachines 93<br />
rule MergedSimpleState {<br />
from s_in:UML!SimpleState (<br />
thisModule.mergedStates->includes(s_in))<br />
to s_out:UML!SimpleState(<br />
nameiterate(s; mss:Set(UML!StateVertex)=Set{} |<br />
if mss->exists(e|(e.mergeable(s)) then<br />
mss<br />
else<br />
mss->including(s)<br />
endif)<br />
;<br />
helper context UML!StateVertex def: mergeable(s:UML!StateVertex):<br />
Boolean =<br />
thisModule.unifiable(self.constraint,s.constraint) <strong>and</strong> self.name=s.<br />
name<br />
;<br />
helper def: unifiable(cset1:Set(UML!Constraint),cset2:Set(UML!<br />
Constraint)): Boolean =<br />
let sharedSVs:Set(UML!Attribute) = cset1->collect(c|c.stateVariable<br />
)->select(a|cset2->collect(c|c.stateVariable)->includes(a)) in<br />
sharedSVs->forAll(a|cset1->select(c|c.stateVariable=a)=<br />
cset2->select(c|c.stateVariable=a))<br />
;<br />
Listing 5.3:MergingSimpleStates<br />
MergingFlatStateMachines Inthisstepwemergetheflatstatemachines.<br />
Wemergeeveryset<strong>of</strong>stateswithunifiablestatevectors<strong>and</strong>atleastone<br />
identicalincomingtransition(interms<strong>of</strong>effectortrigger).<br />
Merging<strong>of</strong>statesisdonebytherule<strong>and</strong>helpersinListing5.3.Therule<br />
matchesallstatesselectedbythe mergedStateshelperthatiterativelyselectsoneSimpleStatefromeverygroup<strong>of</strong>equalSimpleStatesinthesource<br />
model. Acalltothe mergeablehelperresultsintruewhenthereceiving<br />
StateVertex<strong>and</strong>theparameterStateVertex1)(s)areunifiable,<strong>and</strong>2)have<br />
thesamename(i.e.,theincomingtransitionshadthesametriggeroreffect).<br />
The unifiablehelperevaluatestotruefortwosets<strong>of</strong>Constraints<br />
thatdonotspecifydifferentvaluesforthesamestatevariable,meaning<br />
thattheconstraintthatreferstoaparticularstatevariablethatisalso<br />
referredtointheotherset,isactuallyincludedinthatset.<br />
Transitionsarematchedbyanotherrule(notshown).TodiscardredundantTransitions,itonlymatchesoneTransition<strong>of</strong>theTransitionsbetween<br />
anytwosets<strong>of</strong>SimpleStatesthataremerged.
94 Chapter5. <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
IntroducingHierarchy AssuggestedbyWhittle<strong>and</strong>Schumann[2000],weuse<br />
anorderedsubset<strong>of</strong>theset<strong>of</strong>statevariablestoaddhierarchybymeans<br />
<strong>of</strong>CompositeStates.Thesestatevariablesdefineahierarchy<strong>of</strong>Composite-<br />
States.Forinstance,thestatevariablewiththehighestpriorityresultsin<br />
CompositeStatesinthetoplevelCompositeState:oneforeachvalue<strong>of</strong>that<br />
statevariable’sdomain(providedthatitoccursinone<strong>of</strong>thesimplestates’<br />
stateinvariants). Foreach<strong>of</strong>theresultingCompositeStates,thesecondhighestprioritystatevariable,inturn,resultsinCompositeStatesforeach<br />
value<strong>of</strong>thatstatevariable’sdomainthatoccursincombinationwiththe<br />
correspondingvalue<strong>of</strong>thehigher-prioritystatevariable.<br />
Theproblem<strong>of</strong>specifyingthismappingwithATListhatthereisnot<br />
alwaysamatchingsourcemodelelementtocreateaCompositeStatefor.<br />
Therefore,weuseanATLcalledrule(CompositeState). Acalledruleisan<br />
imperativerulethatisnotmatchedbyasourcemodelelement. Instead,<br />
itisexplicitlycalled<strong>and</strong>canhaveparameters.The CompositeStatecalled<br />
ruleinListing5.4 createsaCompositeStateforagivenset<strong>of</strong>Constraints<br />
(cset). TheseConstraints(i.e.,stateinvariants)aredeterminedbythe<br />
compositeStateConstraintSetsAthelperthattakesaset<strong>of</strong>Constraintsthat<br />
representsthecurrentCompositeState<strong>and</strong>determinesthesets<strong>of</strong>ConstraintsthatcorrespondtotheCompositeStatesatthatlevel.Foreach<strong>of</strong><br />
thosesetsaCompositeStateiscreated.Thiscalledruleisusedtoinitialise<br />
the subvertexfeatureintherulethatmatchesthetopCompositeState<strong>of</strong><br />
themergedStateMachine,aswellas(recursively)inthe CompositeState<br />
ruleitself. Thedoclauseinthe CompositeStaterulereturnsthecreated<br />
CompositeState.<br />
5.6 ApplicationtoOcé<br />
Inthissectionwefirstexplainwhatadditionalworkhastobedonetoapply<br />
ourapproachtotheOcécase. Subsequentlywegiveanoverview<strong>of</strong>the<br />
resultsobtainedbyapplication<strong>of</strong>ourapproach.<br />
5.6.1 Source<strong>Model</strong>Normalisation<br />
Inthecase<strong>of</strong>Océ,neitheradomaintheory,noraset<strong>of</strong>statevariables<br />
wereavailable. Toovercomethis,wenormaliseOcé’ssequencediagrams.<br />
Inparticular,weinterpretthedecorationsonobjectlifelinesaspre-<strong>and</strong><br />
postconditionsonasinglestatevariable<strong>of</strong>asuitableenumerationtype:<br />
state. Themessageprecedingastatedecorationapparentlyresultedin<br />
thecomponentmovingtotheindicatedstate.Hence,we(manually)attach<br />
acorrespondingpostconditiontothemessage(e.g., esm.state=starting).A<br />
messagesucceedingastatedecorationapparentlyrequiresthecomponent
5.6. ApplicationtoOcé 95<br />
rule TopCompositeState {<br />
from cs_in:UML!CompositeState<br />
using {<br />
sm:UML!StateMachine=thisModule.allStateMachines->select(sm|sm.top<br />
=cs_in);<br />
}<br />
to cs_out:UML!CompositeState (<br />
name collect(cs|thisModule.CompositeState(sm,cs))))<br />
}<br />
rule CompositeState (sm:UML!StateMachine, cset:Set(UML!Constraint))<br />
{<br />
to cs:UML!CompositeState(<br />
subvertex union(sm.<br />
compositeStateConstraintSeqsAt(cset)->collect(cs|thisModule.<br />
CompositeState(sm,cs))))<br />
do{cs;}<br />
}<br />
Listing 5.4:Addinghierarchytostatemachine<br />
tobeintheindicatedstate.Hence,weattachacorrespondingprecondition<br />
tothemessage. Figure5.7onthenextpageshowsanexample. Finally,<br />
weadda(public)attribute, state,totheclasscorrespondingtothe ESM<br />
component.<br />
5.6.2 Results<br />
Afragment<strong>of</strong>theresult<strong>of</strong>application<strong>of</strong>thetransformationstepstoOcé’s<br />
ESMcomponent,isdepictedinFigure5.8onpage97. Thedashedline<br />
indicatesthepaththroughthestatemachinethatistraversedwhenESM<br />
isrequestedtogotost<strong>and</strong>bywhileitisrunning.Thispathcorrespondsto<br />
thescenariodepictedinFigure5.7onthenextpage.<br />
Wecomparedthisderivedstatemachinewiththeimplementationstate<br />
machine,fromwhichOcégeneratescode. Therearemanyinconsistencieswithrespecttolow-levelstates<strong>and</strong>transitions.Intheimplementationstatemachinelow-levelstatesarenotonlydecomposedfurther,the<br />
sequence<strong>of</strong>states<strong>and</strong>transitionsisalsodifferentinmanycases. This<br />
isnotsurprisingconsideringthefactthatthesequencediagrams<strong>of</strong>the<br />
sourcemodelfromwhichwederivedastatemachine,constitutethefirst<br />
behaviouralmodelthatiscreatedforthe ESMcomponent,while,inthe<br />
implementationstatemachine,low-leveltransitions<strong>and</strong>states<strong>of</strong>tencorrespondtoasinglemethodcallinthegeneratedcode.<br />
Ifwerestrictthe
96 Chapter5. <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
aFunction :Function<br />
.m_Stop ()<br />
.m_StopDone ()<br />
aFunction :Function<br />
.m_Stop ()<br />
.m_StopDone ()<br />
esm:ESM<br />
running<br />
stopping<br />
st<strong>and</strong>by<br />
.set_Unit (st<strong>and</strong>by )<br />
.m_UnitStatus (stopping )<br />
.m_UnitStatus (st<strong>and</strong>by )<br />
acm:ACM<br />
(a)Sequencediagramwithdecoratedlifeline<br />
esm:ESM<br />
.set_Unit (st<strong>and</strong>by )<br />
.m_UnitStatus (stopping )<br />
.m_UnitStatus (st<strong>and</strong>by )<br />
acm:ACM<br />
(b)Normalisedsequencediagram<br />
{esm.state=running}<br />
{esm.state=stopping}<br />
{esm.state=stopping}<br />
{esm.state=st<strong>and</strong>by}<br />
{esm.state=st<strong>and</strong>by}<br />
Figure 5.7:Examplescenario:requestacopierenginetogotost<strong>and</strong>bywhileitis<br />
running
5.6. ApplicationtoOcé 97<br />
Figure 5.8:Mergedstatemodel<strong>of</strong>ESM(fragment)<br />
comparisonsteptothetop-levelstates,however,theimplementationstate<br />
machinelargelyconformstothederivedstatemachine.Althoughwecannotshowtheimplementationstatemachine,wewereabletomakeseveral<br />
otherinterestingobservations:<br />
•Severaltransitionsbetweentop-levelcompositestatesaremissingin<br />
thederivedstatemachine.Thisindicatesthatnotallscenarioshave<br />
beenspecifiedinasequencediagram.<br />
•Sometop-levelcompositestatesinthederivedstatemachinewere<br />
modelledaslow-level(sub)compositestatesintheimplementation<br />
statemachine.Thismerelyindicateschangestothedecomposition<strong>of</strong><br />
states,<strong>and</strong>doesnotnecessarilyresultindifferentbehaviour.<br />
•Inthederivedstatemachine,sometimesextrapathsexistbetween<br />
twocompositestates.Thisindicatesthatspecificsequences<strong>of</strong>events<br />
<strong>and</strong>actionsthatoccurindifferentscenariosarenotspecifiedconsistently.Thiswasthecase,forinstance,whentwoversions<strong>of</strong>ascenario<br />
existed:onefornormalbehaviour,<strong>and</strong>oneforexceptionalbehaviour.<br />
Fortwosuchversionsthefirstinteractionsshouldtypicallybeidentical(untilsomeexceptionoccurs),butinpracticethiswasnotthe<br />
case.<br />
•Thederivedstatemachinecontainsanumber<strong>of</strong>unconditionaltransi-
98 Chapter5. <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
tionsthatformaloop,resultinginnon-deterministicbehaviour.This<br />
hadthesamecauseasthepreviousobservation.<br />
AsaresponsetotheseobservationsOcéhastwooptions.Thefirstistoadd<br />
missingusecases<strong>and</strong>scenarios,<strong>and</strong>torefactoralternativesequencediagramstoremoveinconsistenciesinevent<strong>and</strong>actionsequences.Here,caremustbetaken,assuchmodificationsaffectthestatemachines<strong>of</strong>othercomponentsthatplayaroleintheinvolvedscenariosaswell.Thealternative<br />
optionistoonlyremovebehaviouralinconsistenciesintheimplementation<br />
statemachine.Thisalsorequirescarefulanalysis,sincedifferentdevelopmentgroups,responsiblefordifferentcomponents,mightdosodifferently,<br />
resultinginintegration<strong>and</strong>maintainabilityproblems.<br />
5.7 Discussion<br />
Generalisability<strong>of</strong>theapproach Toalargeextentourapproachisgeneric.<br />
Although,thenormalisedsourcemodelintheOcécaseonlycontainsa<br />
singlestatevariable,wealsoappliedourtransformationsteptotheATM<br />
exampleinWhittle<strong>and</strong>Schumann[2000] 1 . Thisexampleinvolvesthree<br />
statevariables.Byapplication<strong>of</strong>ourapproach(inbothcases)wedetected<br />
severalinconsistencies.<br />
We applied our approach successfully to both the ATM example <strong>of</strong><br />
Whittle<strong>and</strong>Schumann[2000]<strong>and</strong>Océ’sreferencearchitecture. Ourapproachisgenericwithrespecttoinputmodelsthatcomplytothemodel<br />
conventionsasoutlinedinSection5.5.1. Assuch,werequirea(manual)<br />
normalisationstepthatiscontextspecific; itdependsonthemodelling<br />
conventionsinuseataparticularcompany.<br />
Ourmodellingconventionsaremostrestrictivewithrespecttothetype<br />
<strong>of</strong>pre-<strong>and</strong>postconditionsusedinthedomaintheory.Aswedonotevaluate<br />
theseconditions,werequirethemtobe<strong>of</strong>theform stateVariable=value.<br />
InsomecasestheconditionsforanOperationrefertoaformalparameter.OurapproachcanstillbeappliediftheMessagesassociatedwiththatOperationinthesequencediagramsspecifyacorrespondingactualparameter.<br />
Then,we(manually)applytheconditiondirectlytotheMessagein<br />
thesequencediagram<strong>and</strong>substitutetheformalparameterfortheactual<br />
parameter.Morecomplicatedconditionsrequirefullinterpretation<strong>of</strong>OCL<br />
expressions.<br />
Ofcourse,pre-<strong>and</strong>postconditionshavetobeavailableforourapproach<br />
toproducemorethanonlyflatstatemachines. Inthecase<strong>of</strong>Océ,wede-<br />
1 Images<strong>of</strong>the(normalised)sourcemodel,aswellasall(intermediate)targetmodelsfor<br />
theATMexamplecanbedownloadedfromtheATLtransformationsrepository(http://<br />
www.eclipse.org/gmt/atl/atlTransformations/UMLSD2STMD)
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.
100 Chapter5. <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
Applicability<strong>of</strong>theapproach Ourapproachcanbeappliedtoiterativelydevelopbehaviouralspecifications.Wegeneratedastatemachinewiththepurpose<strong>of</strong>checkingtheconsistencybetweendifferentbehaviouralspecifications.However,ourapproach<br />
mighthaveotherapplicationsaswell. Ageneratedstatemachinecould<br />
alsobeusedforothertypes<strong>of</strong>analyses,suchasmodelcheckingorperformanceanalysis.<br />
Nexttoanalysispurposes,ourapproachisparticularlyinterestingfor<br />
forwardengineering,especiallyinthecontext<strong>of</strong>model-drivendevelopment<br />
approachesasinthecase<strong>of</strong>Océ.UsingourtransformationsbasedonUML,<br />
developerscaneasilygeneratedifferentviewsonthebehaviour<strong>of</strong>as<strong>of</strong>twaresystemorcomponent.Furthermore,thegenerationnotonlyprovides<br />
insightintheconsistency<strong>of</strong>thesequencediagramswithrespecttoeach<br />
other,italsoprovidesdeveloperswithafirstc<strong>and</strong>idatestatemachinethat<br />
canberefined.Assuch,ourtechniquecanbeappliediterativelytodevelop<br />
completebehaviouralspecifications<strong>of</strong>components:(1)specifytheinteractions<strong>of</strong>aninitialset<strong>of</strong>usecasesasscenarios,(2)generateastatemachine,(3)refactorscenariostoremoveinconsistenciesinevent<strong>and</strong>action<br />
sequences,<strong>and</strong>addmissingscenarios,(4)gotostep2.<br />
Themainreasontochooseforamodel-drivenapproachbasedonUML<br />
forourconsistencycheck,istheintegrationwithOcé’sdevelopmentprocess.ItcircumventstheneedtoextractinformationfromtheMDAdomain<br />
toanotherdomain,suchasthegrammarwareortheExtensibleMarkup<br />
Language 1 (XML)domain. Unfortunately,despitetheavailability<strong>of</strong>st<strong>and</strong>ards,currentlyavailabletoolsfor(meta)modelling<strong>and</strong>transformationsdonotintegratewell,hamperingactualintegration<strong>of</strong>ourapproachinpractice.Foralargepartthisisduetotheabundance<strong>of</strong>possiblecombinations<br />
<strong>of</strong>XMI,UML,<strong>and</strong>MOFversions,aswellasvendorspecificimplementations<br />
<strong>of</strong>thosest<strong>and</strong>ards. Otherproblemsoccurduetodifferentcapabilities<strong>of</strong><br />
modellingtools.Asanexample,weusedPoseidonforUMLtocreatesource<br />
modelsbecauseitsmetamodelisavailablefromthedeveloper’swebsite.<br />
However,theUMLmodelswegeneratedonotcontainlayoutinformation.<br />
Unfortunately,Poseidonisnotcapable<strong>of</strong>displayingUMLmodelsthatdo<br />
notcontainlayoutinformation. Asaconsequencewehadtouseanother<br />
toolforvisualisation. Fromalargeset<strong>of</strong>toolswetried,onlyBorl<strong>and</strong>’s<br />
Together 2 iscapable<strong>of</strong>generatingalayoutforaUMLmodel.However,the<br />
XMIrepresentationsusedbythistoolarenotcompatiblewiththosegeneratedbytheATLengine.AsaworkaroundwedevelopedaminimalXSLT<br />
transformationthatmapstheXMI‘flavour’generatedbytheATLengine<br />
tothat<strong>of</strong>Together. Analternativeistogeneratethelayoutinformation<br />
requiredbyPoseidonusingamodeltransformation.<br />
1 http://www.w3.org/XML(June2007)
5.8. Conclusions 101<br />
UMLvs. MOF Theuse<strong>of</strong> UMLinalimiteddomainmakestransformation<br />
definitionsunnecessarycomplex<br />
Thegenericity<strong>and</strong>resultingcomplexity<strong>of</strong>theUMLmetamodelresult<br />
in,sometimes,inconvenientnavigationthroughsource<strong>and</strong>targetmodels<br />
toselectacertainelement. Anopenquestioniswhethertreetraversal<br />
strategiesaspresentinStratego 1 ortheJJTraveller[VanDeursen<strong>and</strong><br />
Visser,2004]librarycouldhelptoalleviatethisnavigationproblem.Also,<br />
<strong>of</strong>tenrelationsaredefinedasn:mwhileinaspecificcase1:1wouldsuffice.<br />
Theresultisthatsetshavetobeconvertedtosequences<strong>of</strong>whichthefirst<br />
elementhastobeselected. Thisisrequiredveryfrequently,resultingin<br />
unnecessarycomplexATLcode.<br />
Incases,whereonlylimitedparts<strong>of</strong>theUMLmetamodelareused,analternativecouldbeconsidered.Instead<strong>of</strong>usingtheUMLmetamodel,custom<br />
MOF-basedmetamodelscouldbeused,forinstance,forscenarios<strong>and</strong>state<br />
machines.Thesemetamodelscouldbemuchsimpler,resultinginsimpler<br />
transformationdefinitions.Thepricetopayisthatinordertoestablisha<br />
connectionwithactualUMLmodels(e.g.,asusedbyOcé),amappingbetweensuchcustommetamodels<strong>and</strong>theUMLmetamodelmustbespecified.<br />
InChapter8wediscusshowtomakesuchamappingfordomain-specific<br />
modellinglanguages(DSMLs).<br />
5.8 Conclusions<br />
Inthischapterweexploredtheuse<strong>of</strong>modeltransformationstocheckthe<br />
consistencybetweenbehaviouralspecifications. Forthiswepresentedan<br />
approachthatconsists<strong>of</strong>normalisation,transformation,<strong>and</strong>comparison<br />
steps.Weconsiderthefollowingtobethemaincontributions<strong>of</strong>thischapter:<br />
•Aspecification<strong>of</strong>themappingbetweenscenarios<strong>and</strong>statemachines<br />
usingmodeltransformationsthatismadeavailableviatheATLtransformationsrepository.Anadvantage<strong>of</strong>suchaspecificationisthatit<br />
canbeexecutedbytheATLtransformationengine. Furthermore,it<br />
iscompletelybasedonUML,makingintegrationinindustrialpractice<br />
easier.<br />
•<strong>Model</strong>lingconventionsforencodingtheinformationrequiredforthe<br />
transformationstepinasingleUMLmodel.Additionally,asanexample,wediscussedtherequirednormalisationstepforOcé’sreference<br />
architecture.<br />
1 http://www.stratego-language.org
102 Chapter5. <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
•Validation<strong>of</strong>theproposedapproachbyapplicationtoanindustrial<br />
system,demonstratingthatevensmallindustrialspecifications(consisting<strong>of</strong>just10scenarios)containinconsistencies,whichareeffectivelyidentifiedbyourapproach.<br />
Finally, theproposedapproachcanbeappliedforotherpurposesthan<br />
consistencycheckingaswell,suchasforwardengineering<strong>and</strong>earlybehaviouralanalysisbasedonthegeneratedstatemachine.Currentlyweareextendingourworkwithadditionalcasestudies.Furthermore,weinvestigatethepossibilitiestodoconsistencycheckingautomatically,againbytheuse<strong>of</strong>MDAmodeltransformationtechnologies.
Chapter6<br />
<strong>Model</strong>-<strong>Driven</strong> Conformance Checking<br />
<strong>of</strong> Structural Specifications 1<br />
Nowadays,industryisconfrontedwithrapidlyevolvingsystems.Inorderto<br />
effectivelyreusedesignartefactssuchasrequirements,architecturalviews<br />
<strong>and</strong>analysisresults,aswellasthecodebase,itisimportanttohavea<br />
consistentoverviewineachphase<strong>of</strong>thedevelopmentprocess.Inthischapter<br />
weproposeaconformancecheckingsystembasedonviewstoevaluatethe<br />
conformance<strong>of</strong>animplementationwithrespecttoitsarchitecture.Wemap<br />
ourapproachontotechnologyformodel-drivenengineering. Anacademic<br />
casestudyillustratesapplication<strong>of</strong>ourframework.<br />
6.1 Introduction<br />
Thecurrenttrendinembeddedsystemsisproductfamiliesratherthan<br />
singleproducts. Today’scustomersareappealedtoproductsthathavea<br />
sense<strong>of</strong>uniqueness,productsthatarecompatiblebutslightlydifferent<br />
thanthose<strong>of</strong>theirfriends.Theanswerfromindustryistodevelopflexible<br />
productlines.Theextenttowhichtheevolution<strong>of</strong>s<strong>of</strong>twareisenabledby<br />
suchproduct-lineapproachesislargelydeterminedbytheamount<strong>and</strong>ease<br />
<strong>of</strong>reuse<strong>of</strong>existingartefacts.<br />
Themaintenancephase<strong>of</strong>aproducthasalwaysbeensignificant<strong>and</strong><br />
willincreasinglybeso[Lientzetal.,1978;Pigoski,1996].Thegrowth<strong>of</strong>the<br />
complexity<strong>of</strong>systemsisonereason[Lehman<strong>and</strong>Belady,1985],thetrend<br />
towardsproductfamiliesisanotherreason.FromthesurveyinChapter3<br />
1 Thischapterisbasedon:VanDijk,HylkeW.,BasGraaf,<strong>and</strong>RobBoerman.Onthesystematicconformancecheck<strong>of</strong>s<strong>of</strong>twareartefacts.<br />
InProceedings<strong>of</strong>the2 nd European<br />
WorkshoponS<strong>of</strong>twareArchitecture(EWSA2005),volume3047<strong>of</strong>LectureNotesonComputerScience,pages203–221.Springer-Verlag,2005<br />
103
104 Chapter6. ConformanceCheckingII<br />
Implementation<br />
alignment<br />
Design Space<br />
Architecture<br />
alignment<br />
Figure 6.1:Aligningarchitecture<strong>and</strong>implementation<br />
welearntthatnewproductsarerarelydevelopedfromscratch<strong>and</strong>that<br />
reuse<strong>of</strong>existingdevelopmentartefactsistypicallyadhoc. Theseobservationstriggeredourresearchinthefield<strong>of</strong>conformancecheckingasa<br />
secondstepinenhancingthefunctionality<strong>of</strong>aproductoradaptingittoa<br />
changedenvironment(seeFigure1.2onpage5).Inourviewaconsistent<br />
set<strong>of</strong>s<strong>of</strong>twaredevelopmentartefactsisaprerequisiteforsuccessfulreuse.<br />
Conformancecheckingisrequiredtodeterminethisconsistency.<br />
Ingeneral,conformancecheckingcouldbeappliedtoallrelatedartefactsproducedindifferentphases<strong>of</strong>thes<strong>of</strong>twaredevelopmentprocess.In<br />
thischapterwefocusontheconformancebetweens<strong>of</strong>twarearchitectural<br />
views<strong>and</strong>thecorrespondingimplementation.<br />
Anarchitecturalviewisadescription<strong>of</strong>as<strong>of</strong>twarearchitecturethat<br />
addressesaspecificset<strong>of</strong>concerns.Theguidelinesforthecreation<strong>of</strong>such<br />
viewsaredescribedbyassociatedviewpoints[IEEE-1471,2000].Viewsare<br />
developedduringthearchitecturephasetospecifyconstraintsoverdesign<br />
elements<strong>and</strong>relations[Perry<strong>and</strong>Wolf,1992]forthesubsequentproduct<br />
implementation,thatis,thedesignspace<strong>of</strong>Figure6.1.<br />
Tocheckwhetheranimplementationdoesnotviolatetheconstraints<br />
imposedbyaview,viewsneedtobecreated(reconstructed)fromimplementations[VanDeursenetal.,2004]todetermine(predicate)theproperties<strong>of</strong>theactualimplementationfromanarchitecturalperspective,for<br />
instance,todeterminehowimplementationunitsarerelatedtoeachother.<br />
Theconstraintsthatanarchitecturespecificationdefineseffectivelydeterminethebounds<strong>of</strong>thedesignspaceinwhichtheimplementationhastoberealised.Figure6.1illustratesthattheimplementationinthiscaseviolatessome<strong>of</strong>thearchitecturalconstraints<strong>and</strong>thusdoesnotcompletely<br />
fallwithinthepermitteddesignspace.Theseviolationscanberesolvedby<br />
eitherupdatingthearchitectureortheimplementation.<br />
Here,atechnical<strong>and</strong>aconceptualproblemarise. Firstthelanguages<br />
usedinimplementation(programminglanguages)<strong>and</strong>architecturalviews
6.2. RunningExample 105<br />
(modellinglanguages)differ. Second,thesemanticgapbetweentheelements<strong>and</strong>relationsusedinarchitecturalviews<strong>and</strong>theprogramminglanguageconstructsavailabletoimplementthemmakesitdifficulttoreconstructanarchitecturalviewfromanimplementation.Therefore,forcheckingtheconformance<strong>of</strong>animplementationwithrespecttoanarchitecture,<br />
weproposetodefineacommonconformanceviewpointatanintermediate<br />
level<strong>of</strong>abstraction.Whenarchitectural<strong>and</strong>implementationviewsareassociatedwithacommonviewpoint<strong>and</strong>usethesamemodellinglanguage<br />
(i.e.,metamodel)theidentification<strong>of</strong>discrepanciesbetweentheintended<br />
<strong>and</strong>implementedarchitecturebecomespossible.<br />
Weaddresstheproblem<strong>of</strong>conformancecheckingbymeans<strong>of</strong>aconformancecheckingsystem(CCS),describingthenecessarysteps.<br />
Inorderto<br />
bepracticallyapplicableinindustry,itisrequiredthatsuchaframework<br />
buildsonproventechnology,<strong>and</strong>thatitsapplicationisnon-intrusive.<br />
Inthischapterwepropose<strong>and</strong>experimentwithaconformancecheck<br />
system(CCS)thatfacilitatesconformancechecksthroughthedefinition<strong>of</strong><br />
adesign-spaceconformanceviewpointbridgingthesemanticgapbetween<br />
theimplementation<strong>and</strong>architecture. Suchaviewpointistobederived<br />
fromtheinvolvedarchitecturalviewpointinsuchawaythatviewsassociatedwiththisviewpointcanbothbeextractedfromtheimplementation<strong>and</strong>thearchitecture.WemaptheCCStotechnologyformodel-driven<br />
engineering(MDE)[Bézivin,2005],<strong>and</strong>applyitinanacademiccasestudy.<br />
Ourexperimentsillustratethedefinition<strong>of</strong>conformanceviewpoints,comparingassociatedviews,<br />
<strong>and</strong>visualisation<strong>of</strong>discrepanciesbetweenthe<br />
intended(specified)architecture<strong>and</strong>theimplemented(predicated)architecture.<br />
Thischapterisorganisedasfollows. OurrunningexampleisintroducedinSection6.2.InSection6.3wepresentourCCS<strong>and</strong>explainwhat<br />
needstobedonetomapittoMDE.Subsequently,wediscussthemapping<br />
<strong>of</strong>viewpointstometamodelsinSection6.4<strong>and</strong>themappings<strong>and</strong>model<br />
transformationsforconformancecheckinginSection6.5.InSection6.6we<br />
discussourCCS,theappliedtechnology,<strong>and</strong>relatedwork.Weconcludein<br />
Section6.8withanoverview<strong>of</strong>ourcontributions.<br />
6.2 RunningExample<br />
Therunningexampleinthischapteristhedevelopment<strong>of</strong>anacademic<br />
system:adigitalmusicbox(DMB)thatreadsdatafromapaperdisc(the<br />
record).Thedisccontainsaplottedspiraltrack<strong>of</strong>pulse-widthmodulated<br />
databits. Itrotateswithaconstantspeed. Thesystemtracksthespiral,readsthedatabits,<strong>and</strong>thenmapsthosebitstosymbols.<br />
Astring<br />
<strong>of</strong>symbolswillbefedtoanoutputdevicethattransformsthestringinto
106 Chapter6. ConformanceCheckingII<br />
audiblemusic.Here,wefocusontheprocess<strong>of</strong>readingtherecord<strong>and</strong>generatingthesymbolstream.Ahardwareview<strong>of</strong>thissystemisdepictedin<br />
Figure6.2. Thesystemiscomposed<strong>of</strong>atraditionalturntable<strong>and</strong>aset<br />
<strong>of</strong>simplelightsensorsthatcanbemovedaxiallybyamotor. Thecontrol<br />
isimplementedinJava<strong>and</strong>distributedbetweenasimplemicrocontroller<br />
<strong>and</strong>aPC.<br />
Track<br />
Sensor<br />
Data<br />
Sensor<br />
Symbol<br />
map<br />
Motor<br />
control<br />
Figure 6.2:Digitalmusicboxreadersystem<br />
Thes<strong>of</strong>twarearchitecturedocumentationconsists<strong>of</strong>aset<strong>of</strong>views.Two<br />
<strong>of</strong>themaredepictedinFigure6.3. Theirgoverningviewpointswillbe<br />
explainedinmoredetaillater.<br />
Figure6.3(a) depictsthesystemasaset<strong>of</strong>communicatingprocesses.<br />
Thisviewusesstereotyped[OMG,2007a]Unified<strong>Model</strong>ingLanguage 1<br />
(UML)objectstorepresentcomponents(processes)<strong>and</strong>stereotypeslinks<br />
torepresentconnectors(messages,<strong>and</strong>shareddata). Here,the trackmotor<br />
processcontrolsthespeed<strong>of</strong>themotorthatmovesthesensorsovertherotatingdisc(axially).<br />
The trackprocesscontrolsthe Track Sensor<strong>and</strong>uses,<br />
viaaMessageconnector,the trackmotorprocesstokeepthe Data Sensorpositionedoverthespiraltrack.<br />
The readprocessusesthe Data Sensorto<br />
readthedisc.ViaaSharedDataconnectorthe outputprocessplaystheread<br />
bitsonsomeoutputdevice.Finally,itwasforeseenthatthe read<strong>and</strong> track<br />
processesneededtocommunicateviaaMessageconnector,forinstanceto<br />
communicatethestatus<strong>of</strong>thereadprocess.<br />
Theplannedorganisation<strong>of</strong>implementationunits(modules)isgiven<br />
bythemodule-usesviewdepictedinFigure6.3(b).Here,modulesarerepresentedbystereotypedUMLclasses<strong>and</strong>usesrelationsbydependencies.<br />
Furthermore,alayeringisrepresentedusingthepackagestructure.Here,<br />
thelowerlayersareclosertothehardware(e.g.,motors<strong>and</strong>sensors),while<br />
theupperlayersareclosertotheuser.<br />
1 http://www.uml.org(June2007)<br />
M
6.2. RunningExample 107<br />
appLayer<br />
funcLayer<br />
<br />
output<br />
<br />
<br />
<br />
read<br />
<br />
track<br />
<br />
<br />
trackmotor<br />
(a)Communicating-processes<br />
<br />
DiskReader<br />
<br />
hwLayer <br />
<br />
DataSensor<br />
<br />
<br />
SpeedSensor<br />
<br />
PlayerControl<br />
<br />
ArmControl<br />
<br />
TrackSensor<br />
(b)Module-uses<br />
<br />
<br />
<br />
Figure 6.3:Architecturalviews<br />
<br />
TransMotor
108 Chapter6. ConformanceCheckingII<br />
6.3 Approach<br />
6.3.1 ConformanceCheckingSystem<br />
Ourconformancecheckingsystem(CCS)isbasedontheideanottocompare<br />
architecture<strong>and</strong>implementationdirectly,buttoderiveviewsfromimplementation<strong>and</strong>architecturegovernedbyasharedviewpointexpressedin<br />
thesamelanguage.Thisovercomesboththeconceptual<strong>and</strong>technological<br />
problemsmentionedinSection6.1.Assuch,aconformancecheckbetween<br />
implementation<strong>and</strong>architecturethatdoesnotrequirechangestocurrent<br />
ways<strong>of</strong>working(e.g.,withrespecttolanguages<strong>and</strong>viewsused)requires<br />
thedefinition<strong>of</strong>acommonviewpoint. Thesemantics<strong>of</strong>sucha“designspaceconformanceviewpoint”mustbecompatiblewiththat<strong>of</strong>botharchitectural<strong>and</strong>implementationviews.Thus,amappingbetweenthedesignspaceconformanceviewthearchitecture<strong>and</strong>implementationmustexist.<br />
OurapproachisbasedontheworkpresentedbyVanDeursenetal.[2004]<br />
<strong>and</strong>Murphyetal.[1995]onarchitecturereconstruction.<br />
Inthischapterweconsiderthearchitecturalviewasleading.Asinthe<br />
approachbyMurphyetal.[1995]therearethreeimportantsituationsfor<br />
anyelementorrelationintheimplementation: convergence,divergence,<br />
<strong>and</strong>absence. Aconvergenceindicateselementsorrelationsintheimplementationthathaveacorrespondingelementorrelationinthearchitecture.<br />
Adivergenceonlyexistsintheimplementation<strong>and</strong>anabsence<br />
onlyexistsinthearchitecture. Theresult<strong>of</strong>aconformancecheckisaset<br />
<strong>of</strong>entities<strong>and</strong>relationsthatareattributedaccordingtothethreetypes<br />
above;thesignificance<strong>of</strong>mismatches(divergences<strong>and</strong>absences)founddependsingeneralontheinvolveddesigndecisions.Therefore,discovery<strong>of</strong>mismatchesshouldserveasatriggertoinvestigatefurtheriftheyareallowed<strong>and</strong>possiblydocumentedelsewhere.Ifnot,theyareconsideredtobe<br />
discrepanciesthatreducetheconceptualintegrity[Brooks,Jr,1975]<strong>of</strong>a<br />
system<strong>and</strong>mayresultinunexpecteddependencies,reducingthesystem’s<br />
maintainability.<br />
Theconformancecheckingsystem(CCS)outlinedinFigure6.4 isbased<br />
ontheprocessforarchitecturereconstructionpresentedbyVanDeursen<br />
etal.[2004]. Usingarchitecture<strong>and</strong>implementationartefacts,viewsare<br />
populatedthatareassociatedwithadesign-spaceconformanceviewpoint.<br />
Theconformanceviewpointisdefinedsuchthatitsdistancetoboththe<br />
architectural<strong>and</strong>implementationviewpointsisminimised.Furthermore,<br />
itenablestoattributeelements<strong>and</strong>relationwiththeirconformancestatus<br />
inasubsequentcomparison<strong>of</strong>thederivedconformanceviews. Forthisa<br />
set<strong>of</strong>comparisonrulesisspecified.Finally,apresentationfiltervisualises<br />
thecomparisonresults.
6.3. Approach 109<br />
Architecture Implementation<br />
View<br />
Population<br />
Conformance<br />
viewpoint<br />
Comparison<br />
rules<br />
Comparison<br />
View<br />
Population<br />
Presentation Visual<br />
Figure 6.4:ConceptualConformanceCheckingSystem<br />
6.3.2 <strong>Model</strong>-<strong>Driven</strong>ConformanceChecking<br />
Inthefollowingsectionswediscusshowour CCScanbemappedtoan<br />
MDEtype<strong>of</strong>approach. Although,severaltypes<strong>of</strong>technologiesareavailabletodoso,wewillusetechnologiesrelatedtothe<strong>Model</strong><strong>Driven</strong>Architecture<br />
1 (MDA). Alternatively,wecouldhaveusedtechnologiesbasedon<br />
theExtensibleMarkupLanguage 2 (XML)orongrammars. Infact,inearlierworkweusedXMLtechnologies[VanDijketal.,2005].There,wemade<br />
theobservationthatspecifications<strong>of</strong>models<strong>and</strong>transformationsinXML<br />
tendtobeverbose,<strong>and</strong>hence,difficulttomaintain.<br />
UsingmodeltransformationtheXMLsyntaxremainshidden.Moreover,<br />
wechoseMDAbecause<strong>of</strong>theavailability<strong>of</strong>languages<strong>and</strong>toolstomanipulatearchitecturalmodelsspecifiedusingUML.<br />
KeytoMDEaremodels<strong>and</strong>(automatic)modeltransformations.Assuch,<br />
weconfineourconformancecheckforanarchitecturalviewtoitsprimary<br />
presentation. Here,weassumethatthisprimarypresentationconsists<strong>of</strong><br />
UMLdiagrams.Usingmodeltransformationswecanthenmanipulatethe<br />
underlyingUMLmodelinordertochecktheconformance<strong>of</strong>thecorrespondingimplementation.Tothisend,weassumethatviewpointsprescribethe<br />
modellinglanguagetobeusedfortheprimarypresentation<strong>of</strong>associated<br />
views.<br />
InMDE,modellinglanguagesarespecifiedbymetamodels.Inthecase<strong>of</strong><br />
thearchitecturalviewsthatarethesubject<strong>of</strong>ourconformancecheckthis<br />
typicallyisasubset<strong>of</strong>theUMLmetamodel.Fortheconformanceviewpoints<br />
wederivethesemetamodelsfromtheviewpointdescriptions.<br />
1 http://www.omg.org/mda(June2007)<br />
2 http://www.w3.org/XML(June2007)
110 Chapter6. ConformanceCheckingII<br />
Ingeneral,withMDEabstractmodelsaretransformedtomoreconcrete<br />
models(<strong>and</strong>eventuallyintocode).Inourcasewealsotransformmodelsin<br />
theoppositedirectiontoobtainaconformancemodelsfromtheimplementation.<br />
InaccordancewiththeMDAweusetheMetaObjectFacility 1 (MOF)for<br />
metamodelling<strong>and</strong>UMLformodelling. Forspecifyingtherequiredmodel<br />
transformationsweusedtheAtlasTransformationLanguage[Jouault<strong>and</strong><br />
Kurtev,2005](ATL).<br />
Assuch,weintendtochecktheconformance<strong>of</strong>anarchitecturalmodel<br />
withrespecttoitscorrespondingimplementationusingMDAmodeltransformations.Consequently,itisrequiredtoobtainanMDAtype<strong>of</strong>model<strong>of</strong><br />
theimplementation.<br />
Here,weusetheconcept<strong>of</strong>atechnologicalspacecoinedbyKurtevetal.<br />
[2002]<strong>and</strong>describedasaworkingcontextwithaset<strong>of</strong>associatedconcepts,<br />
body<strong>of</strong>knowledge,requiredskills,tools,<strong>and</strong>possibilities.MDAisonesuch<br />
technologicalspace,basedonMOF<strong>and</strong>modeltransformations. TheMDA<br />
technologicalspacecanbereferredtoasmodelware. Othertechnological<br />
spacesarethegrammarware(basedongrammars)<strong>and</strong>theXMLtechnologicalspace.<br />
Here,werefertothetranslation<strong>of</strong>onetechnologicalspaceto<br />
anotherasprojectionorbridging.Inparticular,fromtheperspective<strong>of</strong>the<br />
target<strong>of</strong>suchaprojectionwecallitinjection,<strong>and</strong>fromtheperspective<strong>of</strong><br />
thesourcewecallitextraction.<br />
We,thus,obtainamodelrepresentation<strong>of</strong>theimplementationbyinjectingitinamodelbasedonanappropriatemetamodel.<br />
6.4 Viewpoints<strong>and</strong>Metamodels<br />
Thearchitecturalviewsusedtodocumentas<strong>of</strong>twarearchitectureareassociatedwithviewpoints.<br />
Severalsets<strong>of</strong>architecturalviewpointshave<br />
beendefined. Toattainagoodcoverage<strong>of</strong>thedifficulties<strong>and</strong>possibilities<strong>of</strong>determiningarchitecturalconformance,weconsiderviewsfromthe<br />
twoprincipalcategories<strong>of</strong>viewsdescribedinliterature[Kruchten,1995;<br />
H<strong>of</strong>meisteretal.,1999;Clementsetal.,2002a]:component-<strong>and</strong>-connector<br />
views<strong>and</strong>moduleviews.Asdiscussedintheprevioussectionwederivea<br />
conformancemetamodelforeach<strong>of</strong>thoseviewpoints.Infact,thesemetamodelseachspecifyanarchitecturedescriptionlanguage(ADL).<br />
Viewpointsdefinetherestrictionontheelements<strong>and</strong>relationstobe<br />
usedintheirprimarypresentation.Inourcaseweassumethatdiagrams<br />
areUMLdiagrams,<strong>and</strong>,thus,basedon(asubset<strong>of</strong>)theUMLmetamodel.<br />
Wederiveitsconformancemetamodelfromtherestrictionsitspecifies.It<br />
1 http://www.omg.org/m<strong>of</strong>(June2007)
6.4. Viewpoints<strong>and</strong>Metamodels 111<br />
ViewPart<br />
−name:String<br />
−conformance:Conformance<br />
<br />
Conformance<br />
−convergent:int<br />
−divergent:int<br />
−absent:int<br />
Figure 6.5:Genericmetamodelelement<br />
istheseelements<strong>and</strong>relationsforwhichwewanttoestablishconformance<br />
asconvergent,divergentorabsent.<br />
First,wedefineagenericmodelelementforconformancemodelsinFigure6.5.<br />
Toavoidconfusion,werefertoitas ViewPart. Itincludesaconformanceattribute:<br />
anenumerationdatatype<strong>of</strong> convergent, divergent, absent.<br />
Inthefollowingwespecialise ViewPartforconcretemodelelements<br />
forwhichwewanttodetermineconformanceinmetamodelsforparticular<br />
viewpoints.<br />
6.4.1 Component-<strong>and</strong>-ConnectorViews<br />
Component-<strong>and</strong>-connector(C&C)viewsmainlyaddressthequestion: how<br />
doesthesystemwork? Thebox-<strong>and</strong>-linediagramscreatedearlyduring<br />
s<strong>of</strong>twaredesign, usuallyareincludedin C&Ctype<strong>of</strong>views. C&Cviews<br />
areruntimeviewsaddressingconcernssuchasconcurrency<strong>and</strong>flow<strong>of</strong><br />
data. MostADLsthathavebeendefinedareaimedatthistype<strong>of</strong>views<br />
(seeMedvidovic<strong>and</strong>Taylor[1997]foranoverview).ADLmodelsdefinethe<br />
structure<strong>of</strong>asysteminterms<strong>of</strong>runtimecomponents<strong>and</strong>theirinteractions<br />
(connectors). Architecturalcomponentsareloci<strong>of</strong>computation<strong>and</strong>state.<br />
Architecturalconnectorsareloci<strong>of</strong>interaction[Shawetal.,1995]. Both<br />
arearchitecturalabstractions<strong>of</strong>elementsthatconsumeresources,either<br />
processingtimeormemory.Assuch,acompleteC&Cviewisanabstraction<br />
asystem’sstructureatruntime.<br />
Anexample<strong>of</strong>aC&CviewwasdepictedinFigure6.3(a)onpage107.<br />
Itshowsconcurrentlyexecutingcomponentsascommunicatingprocesses.<br />
Thecomponentsinteractthroughdifferenttypes<strong>of</strong>connectors.<br />
Forthedefinition<strong>of</strong>aconformancemetamodelforaC&Cviewweadhere<br />
totheterminology<strong>of</strong> ADLs(see,e.g.,Garlanetal.[2000]). Wereferto<br />
theADLdescribedinFigure6.6(a)onpage113asCPADL(Communicating-<br />
Processes ADL). ThemetamodelstatesthataSystemconsists<strong>of</strong>sets<strong>of</strong><br />
components<strong>and</strong> connectors.Each Component<strong>and</strong> Connectorcaninteractwith<br />
itsenvironmentthroughassociatedinterfaces.Incase<strong>of</strong>acomponentthe<br />
interfaceiscalledaPort,whereasincase<strong>of</strong>connectorwecallitaRole.<br />
Inordertoestablishinteractionbetweentwocomponentsoveraconnectorwecanattachcomponentportstoconnectorroles,withthelimitation
112 Chapter6. ConformanceCheckingII<br />
thatsuchan Attachmentisonlyallowedifthecomponentinteractsusingthe<br />
portasinterface<strong>and</strong>accordingtotheexpectationsdescribedbytheconnectorrole,thatis,port<strong>and</strong>roleneedtobecompatible[Allen<strong>and</strong>Garlan,<br />
1994]. Allattachmentstogetherdeterminethe configuration<strong>of</strong>the System.<br />
Notethatalthoughan Attachmentisarelation,wedefineitasa‘first-class’<br />
modelelement(aViewPart)toallowmarkingitsconformanceinaCPADL<br />
model.<br />
Forseveralelementsweaddedspecialisationsforthespecification<strong>of</strong><br />
morespecificcommunicating-processesviews: OutputPort, InputPort, SinkRole,<br />
SourceRole, Process, SharedData,<strong>and</strong> Message.<br />
Finally,themodelelementsforwhichwewanttoestablishtheconformancearedefinedasspecialisations<strong>of</strong>thegenericmetamodelelements<strong>of</strong><br />
Figure6.5ontheprecedingpage.<br />
6.4.2 ModuleViews<br />
InordertoarriveatasystemfunctioningasdescribedbytheC&Cviews,<br />
viewsaredevelopeddrivingtheactualimplementation<strong>of</strong>s<strong>of</strong>tware<strong>and</strong><br />
hardware.Thoseviewsthatcapturethestructuralorganisation<strong>of</strong>theimplementationunitsareknownastheset<strong>of</strong>moduleviews<strong>and</strong>mainlyaddressthequestion:howisthesystemdeveloped?Theseviewsareusedto<br />
dividetheworkamongdevelopers<strong>and</strong>developmentteams. Additionally,<br />
moduleviewscanbeusedtoassessnon-operationalqualities<strong>of</strong>asystem,<br />
suchasmodifiability.Figure6.3(b)onpage107displaysamoduleviewfor<br />
theDMBsystem.Itdepictsthedecomposition<strong>of</strong>thes<strong>of</strong>twareimplementationunits(modules),theirusedependencies,<strong>and</strong>layering.Modulesaresupposedlycoherentunits<strong>of</strong>functionalitythatareeventuallyassignedtodevelopmentteams.Dependencyrelationsbetweenthe<br />
modules<strong>of</strong>adevelopmentviewareimportant. Severaltypes<strong>of</strong>themexists,suchasuses,allowed-to-use,<strong>and</strong>shares-data-withrelations.Here,we<br />
focusonusedependencies.<br />
ThecorrespondingconformancemetamodelisdepictedinFigure6.6(b).<br />
Here,an Implementationconsists<strong>of</strong>aset<strong>of</strong> modules<strong>and</strong> usesdependencies.A<br />
Modulehasaset<strong>of</strong> usesdependencies.InturnaUsesrelationisassociated<br />
withanother Module.Finally,aModuleconsist<strong>of</strong>aset<strong>of</strong> classes.Weadded<br />
theconcept<strong>of</strong> Classtosimplifythereconstruction<strong>of</strong>amodule-usesmodel<br />
fromsourcecode.Alternatively,wecouldhaveusedseparatemetamodels<br />
fortheresult<strong>of</strong>theextractionstep(classes<strong>and</strong>callsrelations)ontheone<br />
h<strong>and</strong>,<strong>and</strong><strong>of</strong>theabstractionstep(modules<strong>and</strong>usesrelations)ontheother.<br />
Again,themodelelementsforwhichwewanttocheckconformanceare<br />
specialisations<strong>of</strong>relevantelementsfromFigure6.5onthepreviouspage.<br />
WerefertothelanguagedefinedbythismetamodelasMADL(ModuleADL).
6.4. Viewpoints<strong>and</strong>Metamodels 113<br />
ViewPart<br />
(from Conformance)<br />
−name:String<br />
−conformance:Conformance<br />
SharedData<br />
+ connectors<br />
Connector *<br />
Component<br />
Message<br />
Attachment<br />
Process<br />
+ ports<br />
Role<br />
Port<br />
*<br />
+ roles *<br />
+ role<br />
attachment<br />
+<br />
+ configuration *<br />
+ attachment<br />
+ port<br />
SourceRole SinkRole<br />
+ calls<br />
*<br />
*<br />
System<br />
+ components<br />
(a)CPADLmetamodel<br />
Implementation<br />
−name:String<br />
Module Uses<br />
+ uses + uses *<br />
*<br />
+ modules *<br />
+ uses<br />
*<br />
+ classes<br />
*<br />
Class<br />
+<br />
*<br />
fieldAccess<br />
*<br />
InputPort OutputPort<br />
ViewPart<br />
(from Conformance)<br />
−name:String<br />
−conformance:Conformance<br />
(b)MADLmetamodel<br />
Figure 6.6:Metamodels
114 Chapter6. ConformanceCheckingII<br />
6.5 Mappings<strong>and</strong><strong>Model</strong>Transformations<br />
ThemodeltransformationsinvolvedinourCCScoverthreephases:model<br />
population,conformancechecking,<strong>and</strong>presentation.Wediscussthetransformationsinvolvedineachphasebelow.<br />
6.5.1 <strong>Model</strong>Population<br />
<strong>Model</strong>populationinvolvesinjection<strong>of</strong>sourceartefactsintoamodelrepresentation,which,subsequentlyistransformedinextraction<strong>and</strong>abstractionstepsintoamodelthatconformstoone<strong>of</strong>thedefinedconformance<br />
metamodels.<br />
Injection<br />
ForthearchitecturalUMLmodels,injectionisnotrequired;theyalready<br />
areinthemodelwaretechnologicalspace<strong>and</strong>,thus,canserveassource<br />
modelsinmodeltransformations.Tothisend,UMLtoolscanserialisethe<br />
UMLmodelstoXMLMetadataInterchange 1 (XMI)format,which,inturn,<br />
canbeusedbytransformationtools.<br />
Inthecase<strong>of</strong>theimplementation,wefirstcompiledarepresentation<strong>of</strong><br />
theabstractsyntaxtree(AST)<strong>of</strong>theJavasourcecodeinJavaML[Badros,<br />
2000],anXMLbasedrepresentation<strong>of</strong>Javasourcecode. Similartechnologyisavailableformanyotherprogramminglanguages[Al-Ekram<strong>and</strong><br />
Kontogiannis,2005]. Then,weinjectedthisXMLdocumentintoamodel<br />
representationconformingtoagenericmetamodelforXML.Wecouldreuse<br />
boththisinjection<strong>and</strong>theXMLmetamodel,astheywerealreadyavailable<br />
fromATL’smetamodel<strong>and</strong>transformationrepositories 2 .<br />
Extraction<strong>and</strong>Abstraction<br />
Inextraction<strong>and</strong>abstractionstepstheobtainedimplementation(XML-<br />
JavaML)model<strong>and</strong>thearchitectural(UML)modelareeachtransformed<br />
intoamodelconformone<strong>of</strong>theconformancemetamodelswedefined.<br />
Here, module <strong>and</strong> C&C views requireadifferent approach. Thisis<br />
mainlyduetothedifferentrelationsbetweenbothtypes<strong>of</strong>architectural<br />
viewsontheoneh<strong>and</strong><strong>and</strong>theimplementationontheother.Therelation<br />
betweenmoduleviews<strong>and</strong>theimplementationisarefinementrelation,<br />
astheseviewsareanabstraction<strong>of</strong>theimplementationunitsthatare<br />
tobe(havebeen)delivered(cf. therelationbetweenaclassdiagram<strong>and</strong><br />
1 http://www.omg.org/mda/specs.htm#XMI(June2007)<br />
2 http://www.eclipse.org/gmt/am3/zoos/atlanticZoo<strong>and</strong>http://www.eclipse.org/m2m/atl/<br />
atlTransformations(June2007)
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
116 Chapter6. ConformanceCheckingII<br />
invocations<strong>and</strong>fieldaccessestargetedatclasseswealsoimplemented.<br />
BecauseJavaMLdiscardscomments,weuseasimplePerl-scripttoretrieve<br />
@moduleclauses<strong>and</strong>generateanXML-documentconsisting<strong>of</strong> elements.Theprojection<strong>of</strong>thisdocument<br />
asXMLmodelservesasadditionalsourcemodeltoatransformationthat<br />
createsmodulesthatarecomposed<strong>of</strong>theclassescreatedbytheprevious<br />
transformation.Afinal(refining)modeltransformationliftsthefieldaccess<br />
<strong>and</strong>calldependenciestothelevel<strong>of</strong>modulesasUsesrelations.<br />
NexttotheJavasourcecode,thearchitecturalusesview<strong>of</strong>Figure6.3(b)<br />
onpage107wasanotherinputforourCCS,representingthe’as-designed’<br />
architecture.Population<strong>of</strong>aMADLmodelfromthisUMLmodelisstraightforwardbecause<strong>of</strong>theuse<strong>of</strong>stereotypestodenotemodules<strong>and</strong>usesrelations.<br />
Theresult(forimplementation<strong>and</strong>architecture)isrepresentedasa<br />
directedgraphasshowninFigure6.7.Here,boxesrepresentmodules,<strong>and</strong><br />
arrowsrepresentusesdependencies.Itcanbeseenthatthemodelderived<br />
fromtheimplementationconsists<strong>of</strong>twounconnectedsubgraphs. Infact,<br />
onesubgraphcorrespondstothepart<strong>of</strong>theimplementationdeployedon<br />
thePC,theothertothepartdeployedonthemicrocontroller. Obviously,<br />
nodirectmethodinvocations<strong>and</strong>fieldaccessesarepossiblebetweenthose<br />
parts.<br />
C&CViews Components,ports,connectors,<strong>and</strong>rolesarearchitecturalconceptsthatmayormaynothaveexplicitcounterpartsinthedevelopment<br />
viewsorimplementation.Theimplementationisnotmerelyarefinement<br />
<strong>of</strong>thesearchitecturalelementsasinthecase<strong>of</strong>developmentviews. This<br />
makesthemappingbetweenthearchitecturalC&Cviews<strong>and</strong>implementationconstructsindirect<strong>and</strong>moredifficult.Themainconcern<strong>of</strong>theC&CviewinFigure6.3(a)onpage107isconcurrency.<br />
Forsuchaviewthecomponentscorrespondtoimplementation<br />
mechanismsforconcurrency<strong>and</strong>parallelism,suchasprocesses,threads<br />
<strong>and</strong>tasks.Forexampleinthecase<strong>of</strong>asystemimplementedinJava,these<br />
componentscorrespondtothreads.Similarly,connectors,inthatcase,are<br />
abstractions<strong>of</strong>themechanismsthatallowthesethreadstointeract,forinstanceinter-process-communicationmechanisms,remote-procedurecalls,<br />
orshared-data.<br />
CreatingaC&Cviewfromstaticsourcesisveryapplicationspecific;it<br />
dependsonconventionsforimplementing,forinstance,concurrency<strong>and</strong><br />
communicationmechanisms.InthiscasewewanttoreconstructaCPADL<br />
modelrepresentingaset<strong>of</strong>communicatingprocesses. Assaid,inJava<br />
thistype<strong>of</strong>componentscorrespondstothreads. Javathreadsareclasses<br />
withamain-methodorclassesthatextendtheJava Threadclass. Inthis
6.5. Mappings<strong>and</strong><strong>Model</strong>Transformations 117<br />
PlayerControl<br />
DiskReader ArmControl<br />
DataSensor SpeedSensor TrackSensor TransMotor<br />
Play<br />
DiscReader<br />
DataSensor<br />
TrackSensor<br />
(a)Architecture<br />
PlayerControl<br />
ArmControl<br />
TransMotor<br />
(b)Implementation<br />
OutputControl<br />
NotePlayer<br />
Figure 6.7:ReconstructedMADLmodels<br />
casewealsoassumethatsuchclassesareinstantiatedonlyonce. Therefore,thefirsttransformationstepidentifiestheseclassesintheJavaML<br />
model. For each we create a Process component in the CPADL target<br />
model. Notethatbecauseinthiscasethereexistsaone-to-onemapping<br />
betweenanimplementationconstruct(Javathread)<strong>and</strong>thecomponentsin<br />
acommunicating-processesview,itisnotnecessarytorelyonannotations<br />
asforthemoduleview.<br />
Inaddition,wesearchinthefirsttransformationstepfortwotypes<br />
<strong>of</strong>interactions:messagepassing<strong>and</strong>shared-data. Thesetypes<strong>of</strong>connectorswereimplementedusingmethodinvocations<strong>and</strong>Javastreams,respectively.<br />
Foridentification<strong>of</strong>therelevantmethodinvocationswelargelyreuse<br />
theATLexpressionsforthepopulation<strong>of</strong>theMADLmodel. Onlynowwe<br />
justconsidermethodinvocationsbetweenidentifiedthreads.ForeachdistinctmethodinvocationbetweentwothreadswecreateaMessageconnector,<strong>and</strong>,ontheside<strong>of</strong>thesource<strong>of</strong>themessage,an<br />
OutputPortforthe<br />
involvedcomponent<strong>and</strong>aSinkRolefortheconnector;atthe‘targetside’we<br />
createan InputPort<strong>and</strong>aSourceRole.Finally,wecreate Attachmentsforthose<br />
ports<strong>and</strong>roles.
118 Chapter6. ConformanceCheckingII<br />
The Java platform for the micro controller <strong>of</strong>fers a special type <strong>of</strong><br />
(buffered)streamclassforwhichwecreateaSharedDataconnectorinthe<br />
CPADLtargetmodel.Byidentifyingeachthreadthatreadsfromorwrites<br />
toaninstance<strong>of</strong>thatclassweidentify Ports(inputoroutput), Roles(source<br />
orsink),<strong>and</strong> Attachments.<br />
Identification<strong>of</strong> Messageconnectorsinthetransformationexplained<br />
above,resultsinaseparateconnectorinstanceforeachdistinctmethodinvocationbetweentwothreads.Ingeneral,connectorsdescribeacomplete<br />
protocolfortheinteractionsallowedbetweentwocomponents. Therefore,<br />
usinganothermodeltransformation,weabstractall Messageconnectors<br />
betweentwocomponentsintoasingleconnectorrepresentingtheallowed<br />
message-basedinteractionbetweenthosecomponents.<br />
TheresultinggraphisgiveninFigure6.8(b).Werepresentcomponents<br />
byrectangles<strong>and</strong>connectorsbyellipses.Attachmentsarerepresentedby<br />
edges<strong>and</strong>theirarrowheadsindicatethe‘direction’<strong>of</strong>theinvolvedports<br />
<strong>and</strong>roles.<br />
ThearchitecturalinputwastheC&Cview<strong>of</strong>Figure6.3(a)onpage107.<br />
ToturnthisviewintoaCPADLmodel,wemapeachstereotyped Objecttoa<br />
ProcessintheCPADLtargetmodel.Each Linkismappedtoanappropriate<br />
Connectordependingontheappliedstereotype. Ports, Roles,<strong>and</strong> Attachments<br />
arecreatedwherenecessary.Notethatwecannotdistinguishbetweeninoroutputportsorsourceorsinkconnectorshere,asnodirectionisprovided.TheCPADLmodelpopulatedfromthearchitectureisgiveninFigure6.8(a).<br />
6.5.2 <strong>Model</strong>Comparison<br />
Thecomparisontransformationshavetwosourcemodels(derivedfrom<br />
implementation<strong>and</strong>fromarchitecture)<strong>and</strong>generateanattributedtarget<br />
model,containingtheelements<strong>of</strong>thesourcemodelsattributedwithone<strong>of</strong><br />
thefollowinglabels:convergent,divergent,orabsent.<br />
ModuleViews Foreachmoduleinbothsourcemodelsitischeckedwhether<br />
itisaconvergent,divergentorabsentmodule. Thisissimplydoneusing<br />
namematching.<br />
Ausesrelationintheimplementationsourcemodelisconsideredconvergentifausesrelationexistsbetweentwomodulesinthearchitecture<br />
sourcemodelthatcorrespondwiththetwomodulesinvolvedinthatuses<br />
relationintheimplementationsourcemodel. Theresultisvisualisedin<br />
Figure6.9.Convergent,divergent,<strong>and</strong>absententitiesarerepresentedby<br />
solid,dashed,<strong>and</strong>dottedlinesrespectively.
6.5. Mappings<strong>and</strong><strong>Model</strong>Transformations 119<br />
PlayerControl<br />
DiscReader<br />
DataSensor<br />
output<br />
read<br />
track<br />
trackmotor<br />
Message<br />
Message<br />
SharedData<br />
Message<br />
Message<br />
(a)Architecture<br />
DiscReader<br />
Play<br />
SharedData<br />
ArmControl Message<br />
(b)Implementation<br />
Message<br />
Figure 6.8:ReconstructedCPADLmodels<br />
Play<br />
DiskReader<br />
SpeedSensor<br />
PlayerControl<br />
ArmControl<br />
TrackSensor<br />
TransMotor<br />
Figure 6.9:MergedMADLconformancemodel<br />
OutputControl<br />
NotePlayer<br />
OutputControl<br />
TransMotor
120 Chapter6. ConformanceCheckingII<br />
PlayerControl<br />
Message<br />
Message<br />
Message<br />
Play<br />
DiscReader<br />
SharedData<br />
Message<br />
ArmControl Message<br />
Figure 6.10:MergedCPADLconformancemodel<br />
OutputControl<br />
TransMotor<br />
Notethatwedeterminemanuallywhichmismatchesactuallyinvolve<br />
discrepancies. Partly,theidentifiedmismatchesoriginatefromnaming,<br />
e.g. DiskReader<strong>and</strong>DiscReader. Oneentityhasnotbeenimplemented:<br />
theSpeedSensor.AdivergentusesrelationemergesbetweenPlayerControl<br />
<strong>and</strong>TransMotor.Infact,thisrelationviolatestheintendedlayering.<br />
C&Cview ComparingthegeneratedCPADLmodelsresultsintheidentification<strong>of</strong>convergences,divergences,<strong>and</strong>absencesasshowninFigure6.10.ComparingtheC&Cruntimeviews<strong>of</strong>Figure6.8ontheprecedingpageinvolvesmergingthenamespaces.<br />
Especiallyinthecase<strong>of</strong>aC&Cviewthis<br />
isnecessary,asthenamesinthesourcecodefromwhichwereconstruct<br />
the C&Cviewarederivedfromthemoduleviews<strong>and</strong>therefore<strong>of</strong>tendo<br />
notmatchthoseinthe C&Cview. Toremedythisweallowtheuser<strong>of</strong><br />
ourtransformationtoprovideamappingbetweenthetwoinvolvedname<br />
spaces.Again,weuseXMLtomakethispossible.Inthiscasethemapping<br />
consists<strong>of</strong><br />
<br />
<br />
<br />
<br />
<br />
<br />
AscanbeseeninFigure6.10,thePlayerControlcomponentisadivergence.<br />
Consultationwiththearchitectrevealedthatitwasintendedasa<br />
connectorbetweentheread<strong>and</strong>trackcomponents. However,intheimplementationitincludedh<strong>and</strong>linguserinteractionforwhichitrequireda<br />
separatethread.
6.6. Discussion 121<br />
6.5.3 <strong>Model</strong>Presentation<br />
ThefinalstepinourCCSisthepresentation<strong>of</strong>thegeneratedconformance<br />
models.AsthedefinedMADL<strong>and</strong>CPADLmetamodelonlydefinethestructure(abstractsyntax)<strong>of</strong>theassociatedmodels<strong>and</strong>nottheirgraphicalnotation(concretesyntax)additionaltransformationsarenecessarytoalanguagethathasanassociatedgraphicalnotation.<br />
Weusedthegraphdescriptionlanguage DOT 1 tovisualisetheresult.<br />
AlthoughDOTisatextual(grammar-based)language,aMOF-basedmetamodelisalsoavailable,allowingprocessingusingATL.WedefinedtransformationsfromCPADL<strong>and</strong>MADLtotheDOTmetamodel.Finally,thetextual<br />
representation<strong>of</strong>thegeneratedDOTmodelswasextractedbyaspecialtype<br />
<strong>of</strong>transformation. ThistransformationqueriesaDOTsourcemodel<strong>and</strong><br />
generatescorrespondingDOTcodeasoutput.Theresultcanbevisualised<br />
usingdot.ExamplesweredepictedinFigures6.7to6.10onpages117–120.<br />
6.6 Discussion<br />
Belowweaddressanumber<strong>of</strong>issuesrelatedtotheuse<strong>of</strong> MDEforour<br />
CCS.Subsequently,wediscussanumber<strong>of</strong>potentialimprovements<strong>of</strong>the<br />
approach.<br />
6.6.1 <strong>Model</strong>ware<br />
<strong>Model</strong>Population Inourexperimentweimplementedthepopulation<strong>of</strong>conformancemodelsviaXML.<br />
Weusedexistingbridgesfromgrammarware<br />
toXML(JavaML)<strong>and</strong>fromXMLtothemodelwaretechnologicalspace(the<br />
injectorforXMLdata). Thedrawback<strong>of</strong>usingthesebridges,isthatsubsequenttransformationsthatpopulatethe<br />
MADL<strong>and</strong> CPADLmodelsare<br />
specifiedinterms<strong>of</strong> XMLmetamodelelements(e.g.,Node,Element,Attribute),ratherthanelementsspecificforJava(e.g.,Class,Method,Field).Thismakesspecifyingthesetransformationspronetoerrors.Ahelperoperationtomanipulateaclass,forinstance,isspecifiedinthecontext<strong>of</strong>XML<br />
elementsthatrepresentclasses.Instead<strong>of</strong>usingthetypesystem,ithasto<br />
becheckedexplicitlythatanXMLelementindeedrepresentsaclass.<br />
Byconstruction<strong>of</strong>anATLlibrary<strong>of</strong>helperoperationsrelatedtotheXML<br />
modelrepresentation<strong>of</strong>Java(e.g.,anoperationtocollectallXMLelements<br />
thatrepresentamethodinvocationforan XMLelementthatrepresents<br />
aclass)wecouldraisetheabstractionlevelsomewhat. However,ideally,<br />
wewouldliketousearepresentationbasedona‘real’Javametamodel.<br />
Infact,suchametamodeliscurrentlyavailablefromtheATLmetamodel<br />
1 http://www.graphviz.org(June2007)
122 Chapter6. ConformanceCheckingII<br />
repository. Theproblemremainstopopulateamodelconformthismetamodelbasedonaset<strong>of</strong>Javasourcefiles.Asolutiontothisproblemcould<br />
beatransformationthattransformsXMLmodels(basedonJavaML)into<br />
modelsbasedontheJavametamodel.Thiswouldallowtospecifythemodel<br />
extractionatthedesiredlevel<strong>of</strong>abstraction. Ingeneral,suchatransformationwouldalsobeusefulforothers<strong>of</strong>twareevolutiontasksthatinvolve<br />
Javasourcecode<strong>and</strong>mightbesolvedinthemodelwaretechnologicalspace<br />
(e.g.,architecturereconstruction,programunderst<strong>and</strong>ing,metriccalculations).<br />
<strong>Model</strong>wareManagement Withtheapplication<strong>of</strong>modeltransformationsto<br />
more<strong>and</strong>morecomplicated<strong>and</strong>diverseproblems(see,e.g.,Chapters5,<br />
7,<strong>and</strong>8<strong>of</strong>thisthesis),managingtheinvolvedmodelartefactsbecomesan<br />
issue.<br />
Althoughwedidnotdiscussall<strong>of</strong>them,theapproachpresentedinthis<br />
chapteralreadyinvolvedsevendifferentmetamodels,11differenttransformations,<strong>and</strong>over20source,target,<strong>and</strong>intermediate(generated)models.<br />
Inaddition,thecompletesolutioninvolvedseveraltransformations<br />
executedoutsidethemodelwarespaceusingtoolssuchassed,Perl,<strong>and</strong><br />
java2xml(fortransformation<strong>of</strong>aJavaprogramtextintoaJavaMLrepresentation).<br />
Currently,wemanagealltheseartefactsusingtheJavabuild<br />
toolAnt 1 ,forwhichtheATLdevelopmenttoolsprovidespecialtaskstoexecutetransformations,save<strong>and</strong>load(meta)models,<strong>and</strong>applyprojectors.<br />
UsingAnt,wecompletelyautomatedourapproach,includingcompilation<br />
<strong>of</strong>anXMLrepresentationforJavasourcecode,execution<strong>of</strong>variousmodel<br />
transformations,<strong>and</strong>generation<strong>of</strong>PostScriptoutputforDOTgraphs.<br />
<strong>Model</strong>wareReuse Fortunately,notall<strong>of</strong>themodelwareartefactsmentioned<br />
abovehavetobedevelopedfromscratch.Wereused<strong>and</strong>adaptedmetamodelsfromATL’smetamodelrepository(e.g.,metamodelsforDOT<strong>and</strong>XML).Alsoprojectorswerereused(e.g.,theXMLinjector,<strong>and</strong>theDOTtotextextractor).Stillspecification<strong>of</strong>allremainingmetamodels<strong>and</strong>modeltransformationstakesconsiderableeffort.<br />
However,transformationsdefinedforthe<br />
modeltransformationphaseforinjection<strong>of</strong>Javasourcecodeintoamodel<br />
representationcanbereusedforconformancechecking<strong>of</strong>otherviews,as<br />
wellasfordifferenttypes<strong>of</strong>applicationsthatinvolvethemanipulation<strong>of</strong><br />
programs.<br />
Themetamodels<strong>and</strong>transformationsusedinthecomparison<strong>and</strong>presentationphasesarespecifictoaparticularviewpoint.Ontheotherh<strong>and</strong><br />
thesemetamodelsareeasilyextendedforotherviewpoints,forinstance,by<br />
1 http://ant.apache.org/(June2007)
6.6. Discussion 123<br />
addition<strong>of</strong>additionaltypes<strong>of</strong>connectorsordependencyrelations.Ifsuch<br />
additionsdonotrequireaspecificapproachforcomparison<strong>and</strong>presentation,thetransformationswespecifiedcanstillbeapplied.<br />
6.6.2 ImprovingtheApproach<br />
Generalisation Theuse<strong>of</strong>ATLmakesourapproachspecifictotheMDAtechnologicalspace.<br />
Thismeansthatwerequiresourcemodelstoconformto<br />
aMOF-basedmetamodel<strong>and</strong>tobeserialisedwithXMI. Inprinciplethis<br />
makesourapproachcompatiblewithmostUMLtools(viaXMI).However,in<br />
practiceadditionaltransformationsare<strong>of</strong>tenrequiredtoexchangesource<br />
<strong>and</strong>targetmodelsbetweenmodelling, visualisation<strong>and</strong>transformation<br />
tools(seealsoSections5.7<strong>and</strong>7.9).<br />
Thespecification<strong>of</strong>modelpopulationtransformationsisdependenton<br />
theapplied(programming<strong>and</strong>modelling)style(e.g.,usage<strong>of</strong>patterns<strong>and</strong><br />
codingconventions).Therequiredcomplexity<strong>of</strong>transformationrulesalso<br />
dependsontheprogrammingstyle. Forinstance,theuse<strong>of</strong>getter<strong>and</strong><br />
settermethodscircumventstheneedtolookfordirectfieldaccess.<br />
Togeneralisethecomparisonstep<strong>of</strong>ourapproachweconsideredthe<br />
definition<strong>of</strong>acompletegenericmetamodelfor(conformance)views.Sucha<br />
metamodelwoulddefineadditionalViewParts(seeFigure6.5onpage111)<br />
suchasElement,ConnectingElement,<strong>and</strong>Relation.TheseViewPartscan<br />
thenbespecialisedbymetamodelsforparticularviewpoints.Forexample,<br />
intheCPADLmetamodelaConnectorwouldbeaConnectingElement,<strong>and</strong><br />
anAttachmentaRelation.Allthiswouldmakesensewhenitispossibleto<br />
specifytransformationsforcomparison<strong>and</strong>presentationinterms<strong>of</strong>those<br />
genericViewParts. Thesetransformationscanthenbeusedforarbitrary<br />
conformancemodels.Theproblemwiththisapproachisthatitisnotpossibletoalsodefinegenericrelationsbetweenmetamodelelementsthatcanbe<br />
specialisedbyaconcretemetamodel.Soalthoughitispossibletodevelopa<br />
transformationtoalwayspresentaConnectingElementasanellipse,such<br />
atransformationcannotalsoinstantiateitsrelationsinagenericway.<br />
Wecanovercomethisproblembytheuse<strong>of</strong>higher-ordertransformations.<br />
Thesearetransformationsthathaveanothertransformationas<br />
sourceortargetmodel.ForATLthisismadepossiblebytheavailability<strong>of</strong><br />
ametamodelformodel-basedrepresentation<strong>of</strong>ATLtransformations<strong>and</strong><br />
correspondingprojectors. Suchahigher-ordertransformationwouldtake<br />
themetamodelinvolvedintheconformancecheckassourcemodel<strong>and</strong><br />
produceamodel<strong>of</strong>thetransformationsforcomparison<strong>and</strong>presentation<strong>of</strong><br />
theassociatedmodels.Thisappearstobefeasibleconsideringthefactthat<br />
thetransformationsweimplementedforthosestepsarequitesimilar.<br />
ThisapproachisinvestigatedinGraaf<strong>and</strong>vanDeursen[2007b],where<br />
weprovideamoreextensivegenericmetamodel,asdiscussedabove.Based
124 Chapter6. ConformanceCheckingII<br />
onthis(abstract)metamodelwedefineconcretemetamodelsforparticular<br />
views. Thehigher-ordertransformationgenerateshelpers<strong>and</strong>transformationrulesforconcreteinstances<strong>of</strong>theabstractmetamodelelementsin<br />
aparticularview’smetamodel. Theresulting ATLtransformationisappliedtomodelsconformingtotheconcretemetamodeltochecktheirconformance.<br />
Here,atrade-<strong>of</strong>fcanbeidentified.Addition<strong>of</strong>extradetailsinageneric<br />
metamodel (e.g., relations between metamodel elements), allows more<br />
transformationcodetobereused,forinstance,forvisualisation<strong>of</strong>conformancemodelswith<br />
DOT. Ontheotherh<strong>and</strong>,thispreventstomakethe<br />
conformancecheck<strong>and</strong>visualisationsspecificforaparticularmetamodel.<br />
Forinstance,wevisualisedconnectingelementsusingellipses<strong>and</strong>other<br />
elementsusingboxes. Inadifferentsituationitmightbenecessaryto<br />
visualisedifferenttypes<strong>of</strong>connectingelements(messageorshareddata)<br />
differently.<br />
IdentifyingDiscrepancies Inthemoduleviewexampleseveralmismatches<br />
occurredduetonaming(e.g.,DiskReadervs. DiscReader). Thiscanbe<br />
solvedbyallowingausertosupplyamappingbetweennamespacesin<br />
asimilarwayaswasdoneinthecase<strong>of</strong>the C&Cview. Fordetermining<br />
whetherothermismatchesarediscrepancies,designdecisionshavetobe<br />
considered.<br />
Ingeneral,definingwhatisamismatchdependsonthetype<strong>of</strong>views<br />
involved<strong>and</strong>theintentions<strong>of</strong>thearchitects. Wedid,forinstance,not<br />
reportmismatchesforattachmentsrelatedtodifferentporttypeswhena<br />
portinthemodelderivedfromtheimplementationisaspecialisation<strong>of</strong>a<br />
correspondingportinthemodelderivedfromthearchitecturalview.<br />
Staticconformancechecking<strong>of</strong>runtimeviews Although C&Cviewsdescribea<br />
systematruntime,weonlyusedstaticinformationforourconformance<br />
check. Asaresult,wecannotalwaysbesurethat,forinstance,twoidentifiedattachmentsconnectthesamecomponent<strong>and</strong>connectorinstances.<br />
Itwouldbeinterestingtoalsoconsiderdynamicinformation. Thisraises<br />
questionssuchashowtoinjectthatinformationintomodels,<strong>and</strong>whattype<br />
<strong>of</strong>metamodelsaresuitableforthat.Onepossibilitywouldbetousetraces<br />
toinstantiatemessagesequencecharttype<strong>of</strong>models,asisdonebyCornelissenetal.[2007].<br />
Introducing annotations Although we required our approach to be nonintrusive,wedidintroducetheuse<strong>of</strong>annotationstoregistermoredetailed<br />
decompositionsthanprescribedbythemoduleview. Assumingthatthe<br />
moduleviewsindeeddrivetheimplementationactivities, theadvent<strong>of</strong>
6.7. Relatedwork 125<br />
integrateddevelopmentenvironmentsmakesdealingwithsuchannotationsstraightforward.Eclipse<br />
1 could,forinstance,beeasilychangedsuch<br />
thatthisinformationisrequestedfromtheprogrammerinthewizardfor<br />
defininganewclass. Furthermore,althoughweuseJava1.4,inversion<br />
1.5annotationshavebecomeanintegralpart<strong>of</strong>theJavalanguage. Subsequently,thisinformationcouldbeincludedintheheader<strong>of</strong>thetemplate<br />
usedbythewizardtocreateclasses.<br />
6.7 Relatedwork<br />
Krikhaar[1999]<strong>and</strong>Mens[2000]independentlycomparedanumber<strong>of</strong><br />
approachestocheckarchitectureconformance. However,conformancebetweenmodelsatdifferentabstractionlevelsisnotaddressed.<br />
Moreover,<br />
mostapproachesdictatetheintroduction<strong>of</strong>specificmodellinglanguages,<br />
requiringachangetocurrentways<strong>of</strong>working.<br />
TheybothmentionMurphyetal.[1995]thatintroducess<strong>of</strong>twarereflexionmodels.Inthatworkahigh-levelmodeliscombinedwithasource<br />
model<strong>and</strong>auserprovidedmappingbetweenthetwotogenerateaso-called<br />
reflexionmodel. Thismodelindicateswheresourcemodel<strong>and</strong>high-level<br />
modelagree.Althoughourmergedconformancemodelisclearlybasedon<br />
theirreflexionmodel,theyonlyindicateconformanceforrelations. Their<br />
approachismoresuitedforcaseswhenthesemanticgapbetweenarchitecture<strong>and</strong>implementationisverylarge.OurapproachextendsthegenericprocessforarchitecturereconstructionproposedbyVanDeursenetal.[2004].<br />
Theirprocessisbasedon<br />
severalindustrialcasestudies<strong>and</strong>includesseparatestepsfordatagathering,knowledgeinference,<strong>and</strong>informationinterpretation.<br />
Weextended<br />
thisprocessforconformancecheckingbyaddition<strong>of</strong>acomparisonstep.<br />
Furthermore,wemakearchitecturalviewpointsconcretebythedefinition<br />
<strong>of</strong>metamodels.<br />
Hanetal.[2003]discussthestepsrequiredforthereconstruction<strong>of</strong><br />
webapplications. Althoughtheirapproachisnotautomated,theiruses<br />
relationisclosertothedefinition<strong>of</strong>Clementsetal.[2002b]thantheonewe<br />
implemented.Nexttousesrelationshipsbasedonmethodcallingtheyalso<br />
considersuchrelationshipsbasedonanothertype<strong>of</strong>logicalinterface,HTTP<br />
requestparameters. Furthermore,theyintroducethe’knows’relation,a<br />
weakertype<strong>of</strong>uses. Thelatterwecouldeasilyintroducebygenerating<br />
’knows’relationshipsbetweenelementsthatownalink(i.e.,reference)to<br />
eachotherthatisnoteffectuated(i.e.,byamethodcall).<br />
1 Eclipseisawidely-used,open-sourceintegrateddevelopmentenvironment,seehttp:<br />
//www.eclipse.org(June2007)
126 Chapter6. ConformanceCheckingII<br />
Analternativetocheckingconformanceafterdevelopment,wouldinvolvetheuse<strong>of</strong>MDEtogeneratesourcecodeorextendtheimplementation<br />
languagewitharchitecturalconstructsaswasdoneinArchJava[Aldrich<br />
etal.,2002]. Suchapproachesdirectlyconnectarchitecturetoimplementation,improvingconsistency.However,thisrequiresatleastachangein<br />
theway<strong>of</strong>working<strong>of</strong>theimplementationphase,forinstancetheuse<strong>of</strong>a<br />
newlanguage.Thisposesabarrierforimplementingsuchanapproachin<br />
practicalsettings.<br />
6.8 Conclusions<br />
Inthischapterweproposeaconformancecheckingsystem(CCS)tosystematicallydeterminediscrepanciesbetweenanintendedarchitecture<strong>and</strong><br />
therealisedarchitecture. Illuminatingthesedifferencesisapreparatory<br />
stepforarchitecturemigrationinwhichpreviouslydevelopedartefactsare<br />
reusedforreasons<strong>of</strong>efficiency. Ourtheconformancecheckingsystem<br />
(CCS)isnon-intrusive. Itcoordinatestheinteractionbetweenthearchitecture<strong>and</strong>theimplementationdomain<strong>of</strong>expertise,whileregardingthem<br />
autonomously. Itusesreadilyavailable,possiblytailored,technologyfor<br />
theactualimplementation<strong>of</strong>CCS.Assuch,themaincontributions<strong>of</strong>this<br />
chapterare:<br />
•agenericprocessforconformancechecking<strong>of</strong>architecturalviews;<br />
•extensible metamodels for C&C <strong>and</strong> module viewpoints, including<br />
mappingsfromimplementation<strong>and</strong>architecturalartefacts;<strong>and</strong><br />
•ademonstration<strong>of</strong>howtocombinedifferenttypes<strong>of</strong>technologies<br />
(inside<strong>and</strong>outsidethemodelwaretechnologicalspace)intoanintegratedapproach,<br />
whilereusingseveralexistingmetamodels<strong>and</strong><br />
transformations<br />
Althoughourapproachislargelyautomated,checkingtheconformance<br />
forparticulartype<strong>of</strong>viewsmightrequireaspecificapproach. Still,the<br />
CCSprovidesagenericprocessbasedonacommondesign-spaceviewpoint.<br />
TheCCSreliesonacleardefinition<strong>of</strong>associatedmetamodel<strong>and</strong>themappingsfromthearchitectural<strong>and</strong>implementationartefactstothiscommon<br />
metamodel.<br />
Thedesign-spacemetamodel(e.g., Figure6.6onpage113)captures<br />
checkableconcepts,whicharetheconsensusbetweenverifyingabstract<br />
properties<strong>of</strong>thearchitecture<strong>and</strong>emergingproperties<strong>of</strong>theimplementation.Possiblediscrepanciesbetweenthetwoarerevealedasmismatches<br />
betweenthederivedconformancemodels<strong>and</strong>theimpact<strong>of</strong>amismatch.
6.8. Conclusions 127<br />
Wegaveexamples<strong>of</strong>conformancemetamodelsforthetwoprincipalcategories<strong>of</strong>views<strong>and</strong>themappingsfromarchitecture<strong>and</strong>implementation<br />
artefacts.Inourcasestudyweused<strong>and</strong>configuredMDEtechnology.<br />
Althoughtheresultsarepromisingweencounteredintriguingresearch<br />
questions,suchastowhatextentwecanfurthergeneralisetheapproach<br />
(i.e.,theinvolvedmetamodels<strong>and</strong>transformations). Here,higher-order<br />
transformations<strong>and</strong>theuse<strong>of</strong>reflectionaretwopossibilitieswewillinvestigateinthefuture.Togetabetterunderst<strong>and</strong>ing<strong>of</strong>thescalability<strong>of</strong>theapproachweintendtoapplytheproposedapproachonanindustrialcase.Aninteresting<br />
possibilityistheapplication<strong>of</strong>thisapproachforcheckingtheconformance<br />
<strong>of</strong>thebehaviouralspecificationsdiscussedinChapter5<strong>of</strong>thisthesis.For<br />
thiswehavetoinvestigatewhetherourapproachcanbeappliedtoautomatethemanualcomparisonstep,inwhichthestatemachinewegenerate<br />
fromaset<strong>of</strong>scenariosarecomparedtothestatemachineusedforcode<br />
generation.
Chapter7<br />
<strong>Model</strong>-driven Migration <strong>of</strong> Supervisory<br />
Machine Control <strong>Architectures</strong> 1<br />
Supervisorymachinecontrolisthehigh-levelcontrolinadvancedmanufacturingmachinesthatisresponsibleforthecoordination<strong>of</strong>manufacturingactivities.Traditionally,thedesign<strong>of</strong>suchcontrolsystemsisbasedon<br />
finitestatemachines. Analternative,moreflexibleapproachisbasedon<br />
task-resourcemodels. Thischapterdescribesanapproachforthemigration<strong>of</strong>supervisorymachinecontrolarchitecturestowardsthisalternativeapproach.Weproposeagenericmigrationapproachbasedonmodeltransformationsthatincludesnormalisation<strong>of</strong>legacyarchitecturesbeforetheir<br />
actualtransformation.Tothisend,weidentifyanumber<strong>of</strong>keyconcernsfor<br />
supervisorymachinecontrol<strong>and</strong>acorrespondingnormaliseddesignidiom.<br />
Assuch,ourmigrationapproachconstitutesaseries<strong>of</strong>modeltransformations,forwhichwedefinetransformationrules.Weillustratetheapplicability<strong>of</strong>thismodel-drivenapproachbymigrating(part<strong>of</strong>)thesupervisorycontrolarchitecture<strong>of</strong>anadvancedmanufacturingmachine:awaferscanner<br />
developedbyASML.Thismigration,towardsaproduct-linearchitecture,<br />
includesachangeinarchitecturalparadigmfromfinitestatemachinesto<br />
task-resourcesystems.<br />
7.1 Introduction<br />
Ass<strong>of</strong>twareintensivesystemsevolvetheytendtobecomeincreasinglycomplex[Lehman<strong>and</strong>Belady,1985].Furthermore,thearchitecturedocumentation<strong>and</strong>itscorrespondingimplementationtendt<strong>of</strong>ollowasynchronous<br />
1 Thischapterwaspublishedearlieras:Graaf,Bas,SvenWeber,<strong>and</strong>ArievanDeursen.<br />
<strong>Model</strong>-drivenmigration<strong>of</strong>supervisorymachinecontrolarchitectures.Journal<strong>of</strong>Systems<br />
<strong>and</strong>S<strong>of</strong>tware,2007.Doi:10.1016/j.jss.2007.06.007<br />
129
130 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
evolutionarypaths. Consequently, theconformancebetweenthearchitecturespecification<strong>and</strong>s<strong>of</strong>twareimplementationdecreasesasas<strong>of</strong>tware<br />
systemevolves[Briletal.,2005].<br />
Inpractice,increasedcomplexity<strong>and</strong>loss<strong>of</strong>conformancebetweenthe<br />
architectureasintended<strong>and</strong>thearchitectureasimplementedmakeasystemmoredifficulttochange[Perry<strong>and</strong>Wolf,1992].<br />
Thisresultsinan<br />
increase<strong>of</strong>bothdevelopment<strong>and</strong>maintenanceeffort. Theinvolvedeffortcan,forinstance,bereducedbytheseparation<strong>of</strong>concerns,theuse<strong>of</strong><br />
product-linearchitectures,model-drivendevelopment<strong>and</strong>automaticcode<br />
generation.<br />
In this chapter we consider the migration <strong>of</strong> supervisory machine<br />
control(SMC)architecturestowardsaproduct-lineapproachthat,amongst<br />
others,supportsmodel-drivendevelopment<strong>and</strong>codegeneration. Inpractice,<br />
adopting such techniques requires architectural changes. When<br />
migratingtowardsaproductline,suchamigrationneedstobeappliedrepeatedlytomigratedifferentproductversionsintoproduct-linemembers.<br />
Therefore,ideally,onewouldliketomakesuchamigrationreproducibleby<br />
automaticallytransformingonearchitectureintoanother.Inthischapter<br />
weinvestigatehowthiscanbedoneusingmodeltransformations. Developingamodel-drivenmigrationapproachisparticularlybeneficialina<br />
settingwhereproductmigrationisnotaone-<strong>of</strong>fexercise.<br />
Inanadvancedmanufacturingmachine,supervisorycontrol [Ramadge<br />
<strong>and</strong>Wonham,1987;Gohari<strong>and</strong>Wonham,2003]isresponsibleforthecoordination<strong>of</strong>the(discrete)high-levelmachinebehaviour.<br />
Thisrequires,<br />
amongstothers, interpretation<strong>of</strong>manufacturingrequests, synchronisation,<br />
scheduling, conditionalexecution, <strong>and</strong>exploitation<strong>of</strong>concurrency<br />
withrespecttotheresultingmanufacturingactivities [Sabuncuoglu<strong>and</strong><br />
Bayiz,2000;Buttazzo,2002;Reveliotis,2005]. Foradvancedmanufacturingmachines,thecontrolsystemshaveanindicativeorder<strong>of</strong>magnitude<strong>of</strong><br />
10SMCcomponents,eachencompassing10 4 -10 5 lines<strong>of</strong>code.<br />
Thischapterwasmotivatedbytheprototypemigration<strong>of</strong>theSMCarchitecture<strong>of</strong>awaferscannerasdevelopedbyASML,amanufacturer<strong>of</strong>equipmentforthesemiconductorindustry.Weusethiswaferscannerasarunningexampletoillustratethemigration<strong>of</strong>alegacyarchitecture,basedonfinitestatemachines(FSMs),toanewarchitecturethatisbasedontaskresourcesystems(TRSs).ThismigrationisspurredbythefactthataTRSbased<br />
SMCarchitecture,asopposedtoan FSM-basedone,isdeclarative,<br />
separatesconcerns,<strong>and</strong>supportsrun-timedependentdecisions [V<strong>and</strong>en<br />
Nieuwelaar,2004]. Asaresult,themaintainability<strong>and</strong>flexibility<strong>of</strong>the<br />
migrateds<strong>of</strong>twaresystemsisimproved.<br />
Weconsiderthestart<strong>and</strong>endpoint<strong>of</strong>themigrationasdifferentarchitecturalviews[IEEE-1471,2000].<br />
Werefertotheseviewsasthesource<br />
<strong>and</strong>targetviewrespectively. Animportantelement<strong>of</strong>anarchitectural
7.1. Introduction 131<br />
viewisitsprimarypresentation[Clementsetal.,2002a],whichtypically<br />
containsoneormorediagram(s). Inthischapterwefocusonthemodels<br />
<strong>and</strong>theirgoverningmetamodelsunderlyingthosediagrams. Inourmigrationapproachweusethesemodelstoconsolidate<strong>and</strong>reuseasmuch<br />
existingdesignknowledgeaspossible. Assuch,weconsidermigrationto<br />
constituteaseries<strong>of</strong>modeltransformations,whichweimplementedusing<br />
<strong>Model</strong><strong>Driven</strong>Architecture 1 (MDA).Itshouldbenotedthatweonlyconsider<br />
theactualmigrationapproach;theparadigmsforthemigrationstartpoint<br />
<strong>and</strong>endpointareprescribedbyourindustrialcase.<br />
Inordertodefineareproduciblemapping<strong>and</strong>performthemigration,<br />
wedefinepracticaltransformationrulesinterms<strong>of</strong>patternsassociated<br />
withthesource<strong>and</strong>targetmetamodels. Thesetransformationrulesare<br />
practicalinthesensethattheyarebasedonanactualmigrationasperformedmanuallybyanexpert.Basedonthismigration,wehaveformulatedgeneric,concern-basedtransformationrules.Theserulesaredefined<br />
usingamodeltransformationlanguagemakingourapproachautomated.<br />
Duetopracticalreasons,whicharemainlyassociatedwiththeinformaluse<br />
<strong>of</strong>modellinglanguagesinindustry(seeChapter3<strong>and</strong>Langeetal.[2006]),<br />
wefirstnormalisethelegacymodelsbeforeapplyingourmodeltransformations.<br />
Althoughwefocusonthemigration<strong>of</strong>theSMCarchitecture<strong>of</strong>aparticularmanufacturingsystem,theASMLwaferscanner,thecontributions<strong>of</strong><br />
thischapterareapplicabletosimilar(paradigm)migrations<strong>of</strong>supervisory<br />
controlcomponentsingeneral.Thepresentedindustrialresultsserveasa<br />
pro<strong>of</strong>aconcept,additionalmigrationshavetobeperformedbeforetheresultscanbeproperlyquantified.Theexperiencesasoutlinedinthischapterare,toalesserextent,relevantforalls<strong>of</strong>twarearchitecturemigrations<br />
thatcanbeseenasmodeltransformationproblems.<br />
Theremainder<strong>of</strong>thischapterisstructuredasfollows.Section7.2discussesrelatedwork.<br />
InSection7.3weintroduce SMC,concernsspecific<br />
toSMCsystems,<strong>and</strong>ourrunningexample.Agenericmigrationapproach,<br />
whichweuseforthemigrationbetweentheintroducedarchitecturalparadigms,ispresentedinSection7.4.<br />
Thesourceparadigm<strong>of</strong>themigration<br />
<strong>and</strong>thenormalisation<strong>of</strong>itsassociatedviewsarediscussedinSections7.5<br />
<strong>and</strong>7.6.Thetargetparadigm<strong>and</strong>ourtransformationrulesaretreatedin<br />
Sections7.7<strong>and</strong>7.8.Weillustrateeachstep<strong>of</strong>themigrationbymeans<strong>of</strong>a<br />
runningexample.Section7.9reflectsonthemigrationresults.Finally,we<br />
concludeinSection7.10withasummary<strong>of</strong>contributions<strong>and</strong>anoverview<br />
<strong>of</strong>futurework.<br />
1 http://www.omg.org/mda(June2007)
132 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
7.2 RelatedWork<br />
Theprocessthatweproposeconsidersmigrationasamappingfroma<br />
sourcetoatargetview.ThisapproachisinspiredbytheapproachforarchitecturereconstructionasdescribedbyVanDeursenetal.[2004].<br />
There,<br />
architecturereconstructionisconsideredtobeamappingfromasource<br />
viewthatisextractedfromcodetoanarchitecturaltargetview.<br />
Ourprocesscanalsobeseenastheapplication<strong>of</strong>theMDAtos<strong>of</strong>tware<br />
migrationratherthantos<strong>of</strong>twaredevelopment. IntheMDA,s<strong>of</strong>twaredevelopmentisconceivedasaseries<strong>of</strong>transformationsfromsourcemodelstotargetmodels.Assuch,inbothprocesses,modeltransformationsareappliedbutinourcaseanessentialnormalisationstepisaddedtotheoriginal<br />
MDAframework.<br />
Fahmy<strong>and</strong>Holt[2000a,b]discussseveraltypes<strong>of</strong>genericarchitecture<br />
transformationsthatcanbeviewedasgraphtransformations. Inthis<br />
chapterweconsiderdomain-specifictransformationsonarchitecturalmodelsthataremorecomplexthantypedgraphs;<br />
nexttotypednodes,our<br />
modelsalsoincludeattributesonnodes<strong>and</strong>edges.Moreover,theirtransformations<br />
are intended for small, evolutionary changes to a s<strong>of</strong>tware<br />
architecture,whereasthetransformationsasdiscussedinthischapterare<br />
drivenbythemigrationtoadifferentarchitecturalparadigm.<br />
Bosch<strong>and</strong>Molin[1999]usearchitecturetransformationsduringarchitecturedesigntorealisethenon-functionalqualityrequirements<strong>of</strong>asystem.Ofthetransformationtypestheyidentify,theapplication<strong>of</strong>anarchitecturalstyleisclosesttoourwork.Tosomeextent,changingthearchitecturalparadigmfromFSMstoTRSs,asconsideredinthischapter,couldbe<br />
understoodassuchatransformation. Inourcase,however,thistransformationalsoresultsinaproduct-linearchitecture.<br />
Inotherwork,transformationsareappliedtothemigration<strong>of</strong>s<strong>of</strong>tware<br />
atthelevel<strong>of</strong>sourcecode.Baxteretal.[2004]presentatoolkitthatuses<br />
generalisedcompilertechnologyforthispurpose. Grayetal.[2004]use<br />
thistoolkitformodel-drivenprogramtransformationswherevertical<strong>and</strong><br />
horizontaltransformationsareidentified. Here,verticaltransformations<br />
concernthecreation<strong>of</strong>s<strong>of</strong>twareartefactsfromartefactsatdifferentabstractionlevels(translation).<br />
Application<strong>of</strong>the MDAtypicallyinvolves<br />
verticaltransformations,whereastheyinvestigateitsapplicabilitytohorizontaltransformations.Thearchitecturemigrationwediscusscanalsobe<br />
consideredahorizontaltransformation.However,wheretheyfocusonthe<br />
sourcecode,weconsidermigrationatthedesignlevel.
7.3. MigrationContext 133<br />
requests<br />
7.3 MigrationContext<br />
user<br />
supervisory controllers<br />
results<br />
activities triggers<br />
mechatronic subsystems<br />
regulative controllers<br />
transducers<br />
Figure 7.1:Machinecontrolcontext<br />
InthissectionwefirstdefinetheSMCcontext.Next,weintroducethemotivatingcase<strong>and</strong>runningexampleforthischapter:atypicalwaferscanner<br />
asproduced,forinstance,byASML.Inthissettingwebrieflydiscussthe<br />
keyconcernsforSMCsystemsingeneral. Theseconcernsneedtobeaddressedduringarchitecturemigration.Assuch,theyformthebasisforthe<br />
design<strong>of</strong>ournormalisation<strong>and</strong>transformationrules.<br />
7.3.1 SupervisoryMachineControl<br />
ThemachinecontrolcontextisclarifiedinFigure7.1.Fromasupervisory<br />
perspective,(sub)frames,transducers<strong>and</strong>associatedregulativecontrollers<br />
form mechatronic subsystemsthatexecute manufacturing activitiestoaddvalue<br />
toproducts.Therecipe-<strong>and</strong>customer-dependentrouting<strong>of</strong>multi-product<br />
flows,withvaryingoptimisationcriteria,constitutesone<strong>of</strong>thekey(supervisory)controlissues.Moreover,advancedmanufacturingmachinesmust<br />
respondcorrectly<strong>and</strong>reproduciblyto manufacturing requests,run-time events<br />
<strong>and</strong> results. Consequently,tointerpretmanufacturingrequests<strong>and</strong>toensurefeasiblemachinebehaviour,asupervisory<br />
machine controlcomponentis<br />
requiredtocoordinatetheexecution<strong>of</strong>manufacturingactivities[Ramadge<br />
<strong>and</strong>Wonham,1987;Sabuncuoglu<strong>and</strong>Bayiz,2000;V<strong>and</strong>enNieuwelaar,<br />
2004].<br />
Inpractice,ahigh-levelmanufacturingrequestistranslatedintovalid<br />
low-level machine behaviour using multiple, consecutive control-layers.<br />
This is supported by recursive application <strong>of</strong> the control context from<br />
Figure7.1: manufacturingactivities<strong>of</strong>onelevelbecomemanufacturing<br />
requestsforthenextleveluntilthelevel<strong>of</strong>themechatronicsubsystems.
134 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
x<br />
@Measure<br />
Figure 7.2:Simplifiedlayout<strong>of</strong>awaferscanner<br />
7.3.2 RunningExample:AWaferScanner<br />
@Expose<br />
InthischapterweconsidertheASMLwaferscannerasarepresentative<br />
example<strong>of</strong>anadvancedmanufacturingmachine.Waferscannersareused<br />
inthesemiconductorindustry<strong>and</strong>performthemostcriticalstepinthe<br />
manufacturingprocess<strong>of</strong>integratedcircuits(ICs).Figure7.2illustratesa<br />
scanner<strong>and</strong>itssubsystems.<br />
Aneighbouringmachine,thetrack(TR),performspre-processingsteps<br />
<strong>and</strong>deliverssiliconwaferstothepre-alignmentsystem(PA),wherethe<br />
waferorientation<strong>and</strong>alignmentaredetermined<strong>and</strong>adjusted. Next,the<br />
loadrobot(LR)transportsthewafertoone<strong>of</strong>thetwowaferstages(WS:0<br />
or WS:1). Here,thewafercharacteristicsaremeasured. Aftermeasurement,thewaferstagesareswapped<strong>and</strong>themeasuredwaferisexposed.<br />
Duringexposure,alaserprojectsanimage<strong>of</strong>therequiredICpatternonto<br />
thewafer’ssurfacethroughademagnificationlens.Awaferisexposedina<br />
scanningfashion,similartotheprocessusedinaphoto-copier.Eventually,<br />
thewafercomestoholdhundreds<strong>of</strong>smallcopies(i.e.,dies)<strong>of</strong>thispattern.<br />
Afterexposure,thestagesswapback<strong>and</strong>theunloadrobot(UR)transportstheexposedwafertothedischargeunit(DU)whereitisbuffered.Next,thewaferispickedupbythetrackagaintoundergovariouspostprocessingsteps.<br />
Now,thewaferisreadyforanotherexposureifneeded;<br />
theprocessisre-entrant.Witheachpassing,anotherlayerisaddedtoeach<br />
die.Oncethewaferhasbeenfullyprocessed<strong>and</strong>inspected,itisdicedinto<br />
individualdiesthatarepackagedt<strong>of</strong>ormICssuchasmicroprocessors.<br />
FortheSMCcomponent<strong>of</strong>thewaferscannerdepictedinFigure7.2,we<br />
canidentifythe‘processwaferw’manufacturingrequest,whichsupports<br />
concurrentmeasuring<strong>and</strong>exposing<strong>of</strong>twowafers.Toperformthisrequest<br />
manufacturingactivitiessuchas‘loadwaferwontowaferstageWS:0’<strong>and</strong><br />
‘unloadwaferwfromwaferstageWS:1’areexecuted.Forinstance,aftera
7.3. MigrationContext 135<br />
waferhasbeenexposed,<strong>and</strong>thestageshaveswapped,thewafermustbe<br />
unloadedfromitsstage.Inturn,theseactivitiesarerequestsforalowerlevelSMCcomponent.<br />
Inthischapterwewillusethe‘processwafer’<strong>and</strong><br />
‘unloadwafer’requestsasillustrativeexamples.<br />
7.3.3 ConcernsforSupervisoryMachineControlSystems<br />
Inadvancedmanufacturingmachines,multiplemanufacturingactivities<strong>and</strong>sequenceshere<strong>of</strong>-mayfulfilaparticularrequest<strong>and</strong>,inturn,multiplemechatronicsubsystemsmaybeavailabletoperformaparticularactivity.Thatis,multiplealternativesexistthatrequiretheselection<strong>of</strong>aspecificsubset<strong>of</strong>bothmanufacturingactivities<strong>and</strong>mechatronicsubsystems<br />
t<strong>of</strong>ulfilagivenmanufacturingrequest. Forinstance,whenconsidering<br />
Figure7.2,removingawaferfromDUcanbedoneusingeitherURorLR.<br />
Forsupervisorycontrol<strong>of</strong>advancedmanufacturingmachinesingeneral,<br />
thefollowingkeyconcernsareidentified.<br />
Theexecution<strong>of</strong>anactivityonaselectedsubsystemimpliesaspecific<br />
physicalstatetransition<strong>of</strong>thatsubsystem. Theselectedsequence<strong>of</strong>activitiesforasubsystemrequiresmatchingendstates<strong>and</strong>beginstates<strong>of</strong><br />
consecutivestatetransitions. Whenthesestatesdonotmatch,anadditionaltransition,asetup,hastobeexecutedbetweenconsecutiveactivities.<br />
Forinstance,whenURisidleatPA,arotationhastobeperformed<br />
beforeawafercanbeunloaded. InSMC,thesesequence-dependentsetups<br />
arecommon.<br />
Intuitively,controlledusage<strong>of</strong>mechatronicsubsystemsisanotherimportantconcern.Thecontrolsystemgenerallycheckstheavailability<strong>of</strong>a<br />
subsystemthatisrequiredforamanufacturingactivity. Onceavailable,<br />
thesubsystemshouldbeeffectivelyclaimedforthegivenactivity. When<br />
anactivityhasbeen(co)performedbyclaimedmechatronicsubsystem(s),<br />
allshouldbeunclaimedorreleased. Inourwaferscannerexample,the<br />
unloading<strong>of</strong>awaferrequiresbothUR<strong>and</strong>,forinstance,WS:0.<br />
Inordertotakefulladvantage<strong>of</strong>installedcapacity,concurrentexecution<strong>of</strong>activitiesisdonewherepossible.Inpractice,activitiescanbeexecutedconcurrentlyunlessthisisexplicitlyprohibitedbyprecedence(sequence)relationsbetweenmanufacturingactivitiesorusage<strong>of</strong>therequired<br />
mechatronicsubsystems.Inourwaferscannerexample,onewafercanbe<br />
measured<strong>and</strong>preparedforexposurewhileanotherwaferisbeingexposed.<br />
Synchronousexecutionisanothercommonconcern.Thisnotonlyrefers<br />
tosynchronisation<strong>of</strong>activitiessuchthattheyareexecutedoneafterthe<br />
other(e.g.,loadawaferbeforeprocessingit). Italsoappliestosynchronisation<strong>of</strong>specificsubsystemstatetransitionsrelatedtotwoactivities.Forinstance,physicalspaceis<strong>of</strong>tenlimited,resultinginmultiplemechatronicsubsystemsthatsimultaneouslyoperatewithinaconfinedspace.
136 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
Thisresultsinso-calledhazardousareasinwhichsubsystemscancollide<br />
<strong>and</strong>statetransitionsmustbeinducedsynchronouslytoensuresafety(e.g.,<br />
swappingWS:0<strong>and</strong>WS:1).<br />
Finally,conditionalexecution<strong>of</strong>manufacturingactivitiesneedstobe<br />
supported. Thatis,dependingoncertainconditionsinamachine,differentexecutionpathsforamanufacturingrequestmightbeactivated,each<br />
consisting<strong>of</strong>consecutivemanufacturingactivities. Anexample<strong>of</strong>sucha<br />
conditioninourwaferscannerexampleisthepresence<strong>of</strong>anotherwaferon<br />
thewaferstageatthemeasure-side.<br />
Duringmigration,sequence-dependentsetups,subsystemusage,concurrentexecution,<br />
synchronousexecution<strong>and</strong>conditionalexecutionare<br />
concernsthatneedtobeaddressed.Tothisend,wedefinedconcern-based<br />
transformationrulesthatmaptheseconcernsfromthelegacytothenew<br />
architecture.<br />
7.4 <strong>Model</strong>-<strong>Driven</strong>Migration<br />
Ideally,themigration<strong>of</strong>s<strong>of</strong>twarearchitecturesiscomplete,reproducible,<br />
reliable<strong>and</strong>automated. Weconsiderthestart<strong>and</strong>endpoint<strong>of</strong>themigrationasdifferentarchitecturalviews,referredtoasthesource<strong>and</strong>targetviewrespectively.ThisissimilartotheapproachforarchitecturereconstructionasdescribedbyVanDeursenetal.[2004].<br />
Anarchitecture<br />
viewisassociatedwithaviewpoint[IEEE-1471,2000],that,amongstothers,specifiesametamodelformodelsunderlyingtheprimarypresentation[Clementsetal.,2002a]<strong>of</strong>thatview.Inthischapterwefocusonthose<br />
models.<br />
Forthemigration<strong>of</strong>sourcemodelsintotargetmodelsweproposethe<br />
migrationapproachasshowninFigure7.3.Itusesatwo-stepprocessthat<br />
includesanormalisation<strong>and</strong>transformationstep.<br />
<strong>Model</strong>s<strong>and</strong>theirspecificationsare<strong>of</strong>tenincomplete<strong>and</strong>haveatendencytobecomeinconsistent<strong>and</strong>ambiguousovertime.Thismakesdirectlytranslatingasourcemodelintoatargetmodelinherentlydifficult.<br />
Thisisamplifiedfurtherbytoollimitations<strong>and</strong>thegenerallyinformal<br />
use<strong>of</strong>modellingparadigms<strong>and</strong>languagesinindustry(seeChapter3<strong>and</strong><br />
Langeetal.[2006]). Combinedwithincompleteorgenericmetamodels<br />
(e.g.,theUnified<strong>Model</strong>ingLanguage 1 (UML)metamodel),ornoexplicit<br />
metamodelsatall,amultitude<strong>of</strong>modelsbecomesconceivablethatallhave<br />
thesameintendedmeaning.<br />
Infact,ananalysis<strong>of</strong>howSMCconcernsareaddressedinthesource<br />
modelsforourmigration,revealedalargevariationintheusedidiom.This<br />
1 http://www.uml.org(June2007)
7.4. <strong>Model</strong>-<strong>Driven</strong>Migration 137<br />
Source<br />
view<br />
Source<br />
viewpoint<br />
specifies<br />
normalise<br />
specifies<br />
Normalised<br />
source view<br />
Canonical<br />
source viewpoint<br />
source<br />
specifies<br />
transform<br />
Transformation<br />
rules<br />
Figure 7.3:Generictwo-phasedmigrationapproach<br />
Target<br />
view<br />
Target<br />
viewpoint<br />
specifies<br />
target<br />
makesitinfeasibletospecifygenericcorrespondingtransformationrules.<br />
Assuch,weintroduceanintermediatenormalisationstepthatusesaset<strong>of</strong><br />
normalisationrulestoobtainanormalisedsourcemodel. Thenormalisationrulesaredefinedasmappingsfromthesourcemetamodeltothenormalisedsourcemetamodel.Thisnormalisedmetamodeldescribesasubset<br />
<strong>of</strong>themodelsdescribedbythesourcemetamodel. Next,aset<strong>of</strong>transformationrulescanbeappliedtotransformanormalisedsourcemodelinto<br />
thetargetmodel.Thesetransformationrulesaredefinedasmappingsfrom<br />
thenormalisedsourcemetamodeltothetargetmetamodel.<br />
Inall,weseemigrationasaseries<strong>of</strong>automatedmodeltransformationsthataredefinedonmetamodelstotransformasourcemodelintoa<br />
targetmodelusingadistinctnormalisationstep.Thisapproachisgeneric<br />
inthesensethatitcanbeappliedtoanyconformingsource<strong>and</strong>target<br />
modelwithoutloss<strong>of</strong>generality. Toactuallyimplementthisapproachwe<br />
require(normalised)source<strong>and</strong>targetmetamodels,normalisationrules,<br />
<strong>and</strong>transformationrules.<br />
Althoughtheapproachisgeneric, ourindustrialcaseimposessome<br />
practicalrestrictionsontheenablingtechnologies.Spurredbythefactthat<br />
theexistingarchitecturedocumentationcontainedsourcemodels(partly)<br />
in UMLstatecharts, wedecidedtoimplementthedifferentsteps<strong>of</strong>our<br />
migrationapproachusingMDAtechnologies. IntheMDAvision,s<strong>of</strong>tware<br />
developmentisconsideredtobeaseries<strong>of</strong>modeltransformations. Similarly,weconsiders<strong>of</strong>twaremigrationasaseries<strong>of</strong>modeltransformations.<br />
StartingfromUML,technologiescompatiblewithMDA<strong>of</strong>ferconvenient<strong>and</strong><br />
<strong>of</strong>f-the-shelfmeanstodefine<strong>and</strong>manipulatemodels. Furthermore,the<br />
MetaObjectFacility 1 (MOF)canbeusedforthedefinition<strong>of</strong>metamodels.<br />
1 http://www.omg.org/m<strong>of</strong>(June2007)
138 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
Finally, variousmodeltransformationlanguagesareavailabletodefine<br />
transformations.<br />
We defined all transformations in the Atlas Transformation Language[Jouault<strong>and</strong>Kurtev,2005](ATL).Anadvantage<strong>of</strong>ATLisitssyntax,<br />
whichissimilartothat<strong>of</strong>theObjectConstraintLanguage 1 (OCL). This<br />
allowspeoplethathavebeenworkingwiththeUMLmetamodeltounderst<strong>and</strong><strong>and</strong>createtransformationruleswithrelativeease.<br />
TheactualATL<br />
transformationenginereliesontwoimplementations<strong>of</strong>MOF:theEclipse<br />
<strong>Model</strong>ingFramework 2 (EMF)<strong>and</strong>theMetadataRepository 3 (MDR).TheATL<br />
transformationenginecanbeusedincombinationwithMOF-basedmodels<br />
<strong>and</strong>metamodelsserialisedwithXMLMetadataInterchange 4 (XMI).Asour<br />
sourcemetamodelweusedthe MOF-UMLmetamodelavailablefromthe<br />
ObjectManagementGroup 5 (OMG)[OMG,2007a].Tocreatesourcemodels,<br />
wecansimplyuseaUMLmodellingtoolthatsupportsXMIexport.Forthe<br />
targetmetamodelwealsousedEMFasitallowsforautomaticgeneration<br />
<strong>of</strong>aprimitive,tree-basededitorforanyarbitrarymetamodel. Thiseditor<br />
canthenbeusedtoinspecttheresults<strong>of</strong>ourtransformations.<br />
7.5 SourceMetamodel<br />
Inthischapter,weconsiderFSMsasthegivenstartingpointforthemigration.<br />
Theuse<strong>of</strong>FSMsasaparadigmforsupervisorycontrolhasbeen<br />
proposedby,forinstance,Ramadge<strong>and</strong>Wonham[1987]. Here,theset<strong>of</strong><br />
possiblemachinebehavioursisconsideredt<strong>of</strong>ormalanguage. Adiscrete<br />
supervisory FSMissynthesisedthatrestrictsthislanguagebydisabling<br />
asubset<strong>of</strong>eventstoenforcevalidmachinebehaviour. Thisrequiresthe<br />
behaviourinallpossiblestatesforallrequeststobespecifiedexplicitly<br />
using(un)conditionalstatetransitionswithassociatedtriggers(events),<br />
<strong>and</strong>effectsorstateactions(manufacturingactivities). Whenusingthis<br />
paradigm,concurrentexecutionistheresult<strong>of</strong>independentparts<strong>of</strong>concurrentlyexecutingstatemachinesthatcanoptionallyshareeventstosynchronise.<br />
Consequently,multipleFSMsareusedpercontroller(typically<br />
oneforeachtype<strong>of</strong>request).<br />
OursourcemodelsarespecifiedusingUMLstatechartdiagrams. The<br />
relevantpart<strong>of</strong>themetamodelisshowninFigure7.4. Apartfromthis<br />
metamodel,the UMLspecificationalsoprovidesalargenumber<strong>of</strong>wellformednessrules,specifiedinOCL,<strong>of</strong>whichafewarementionedbelow.<br />
1http://www.omg.org/technology/documents/modeling_spec_catalog.htm#OCL(June2007) 2http://www.eclipse.org/emf(June2007) 3http://mdr.netbeans.org(June2007) 4http://www.omg.org/mda/specs.htm#XMI(June2007) 5http://www.omg.org(June2007)
7.5. SourceMetamodel 139<br />
0..1<br />
0..1<br />
Event<br />
+ trigger<br />
StateMachine<br />
StateVertex<br />
+ transitions<br />
0..1<br />
+ incoming<br />
*<br />
+ target *<br />
+ outgoing<br />
Transition<br />
*<br />
*<br />
+ subvertex<br />
+ source<br />
+ top<br />
State<br />
*<br />
0..1<br />
0..1<br />
+ entry<br />
0..1<br />
+ exit<br />
0..1 + effect<br />
Action<br />
+ script :ActionExpression<br />
Pseudostate<br />
+ kind :PseudostateKind<br />
0..1<br />
CompositeState<br />
Guard<br />
+ expression :BooleanExpression<br />
+ isConcurrent :Boolean<br />
+ guard<br />
0..1<br />
SimpleState FinalState<br />
+ container<br />
Created with Poseidon for UML Community Edition. Not for Commercial Use.<br />
Figure 7.4:Sourcemetamodel(excerptfromOMG[2007a])<br />
Usingthismetamodel,UMLstatemachinescanbeconstructedthatmodel<br />
behaviourasatraversal<strong>of</strong>agraph<strong>of</strong>statenodesinterconnectedbytransitionarcs.<br />
InFigure7.4astatenode,or StateVertex,isthe targetor source<strong>of</strong>any<br />
number<strong>of</strong> Transitions<strong>and</strong>canbe<strong>of</strong>differenttypes. A Staterepresentsa<br />
situationinwhichsomeinvariantoverstatevariablesholds. Inaddition,<br />
anoptional entryor exit Actionisexecutedwhenthestateisenteredorexited.<br />
Themetamodeldefinesdifferenttypes<strong>of</strong>States.A CompositeStatecontains<br />
(owns)anumber<strong>of</strong>substates(subvertex).IfaCompositeStateisconcurrent<br />
(isConcurrent)itcontainsatleasttwocompositesubstatesthatexecutein<br />
parallel. A SimpleStateisaStatewithoutanysubstates. Execution<strong>of</strong>an<br />
enclosingCompositeStateendswhenaFinalStateisentered.<br />
Nexttostatenodesthatdescribeadistinctsituation,themetamodel<br />
also<strong>of</strong>fersatype<strong>of</strong>StateVertexthatmodelsatransientnode<strong>of</strong>astate<br />
graph: a Pseudostate. Itallowsmodelling<strong>of</strong>morecomplex(conditional)<br />
transitionpaths. Threetypes<strong>of</strong>pseudo-states(PseudostateKind)arerelevantforthestatemodelsinthischapter:initial,choice,<strong>and</strong>junction.AninitialPseudostateisthedefaultnode<strong>of</strong>aCompositeState.AchoicePseu-<br />
0..1
140 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
dostateisusedtocreateadynamicconditionalbranchthatdependsonthe<br />
actiononits incomingtransitions.Alternativepathsmaybejoinedusinga<br />
junctionPseudostate.<br />
Nodesinastatemachineareconnectedbytransitionsthatmodelthe<br />
TransitionfromoneState(source)toanother(target).ATransitionisfired<br />
byan Event(trigger). ATransitionwithoutsuchanexplicittriggerisfired<br />
byanimplicitcompletionEventthatisgenerateduponcompletion<strong>of</strong>all<br />
activitiesinthecurrentlyactiveState.A GuardisaBooleanexpressionattachedtoaTransitionthatdisablesorenablesitsfiringuponoccurrence<strong>of</strong><br />
itstrigger(dependingonwhetheritevaluatestotrueort<strong>of</strong>alse).The effect<br />
<strong>of</strong>aTransitionspecifiesanActiontobeexecuteduponitsfiring.Notethat,<br />
althoughtheremightbeacausalrelationshipbetweenactions<strong>and</strong>events<br />
(e.g.,acalleventgeneratedbyacallaction),UMLdoesnotallowtomake<br />
sucharelationshipexplicitwithouttheuse<strong>of</strong>OCL.Finally,aStateMachine<br />
consists<strong>of</strong>aset<strong>of</strong>transitions<strong>and</strong>atopStatethatisaCompositeState.<br />
Asanexample<strong>of</strong>howthismetamodelisusedinpractice,considerthe<br />
statemachinesinFigure7.5 <strong>and</strong>7.6onpage142,whichcorrespondto<br />
theprocesswafer<strong>and</strong>unloadwaferrequestsasintroducedinSection7.3.2.<br />
Suchstatemachinesarethesourcemodelsforthemigration. Notethat<br />
ourexamplerequestswereadoptedfromtwodistinctsupervisorycontrol<br />
componentswithanindicativeorder<strong>of</strong>magnitude<strong>of</strong>10requests,10-10 2<br />
states,<strong>and</strong>10 2 -10 3 transitions. Althoughweuseactualmanufacturing<br />
requestsasrunningexamples,wedonotdepictordiscusstheserequests<br />
infulldetailforreasons<strong>of</strong>confidentiality.<br />
Fromthenumber<strong>of</strong>choicepseudo-states<strong>and</strong>guardedtransitionsitbecomesclearthatconditionalexecutionisthedominantconcernintheprocesswaferrequestinFigure7.5.<br />
Inotherwords,theactivatedpathis<br />
dependentonconditionalsynchronisation(e.g., wafer@measure)withother,<br />
concurrentlyexecutingrequests.<br />
Figure7.6onpage142illustratesthataftertheactualtransfer<strong>of</strong>the<br />
wafer(TRANSFER_FINISHED)thealternativecompletionsequences<strong>of</strong>subsequent<br />
activities,whichareassociatedwiththe UR_moved<strong>and</strong> WS_movedevents,<br />
arespecifiedexhaustively. Furthermore,observetheuse<strong>of</strong>twodistinct<br />
resourceusagepatternsforWS<strong>and</strong>URinourunloadwaferrequest: for<br />
WSonlyanavailableEvent(WS available)<strong>and</strong>releaseAction(release WS)<br />
arespecified,forURalsoaclaimAction(claim UR)hasbeenspecified.<br />
Notethatforreasons<strong>of</strong>simplicity,wechoosenottoincluderesource<br />
usage<strong>and</strong>setupsinthespecification<strong>of</strong>theprocesswaferrequest. Even<br />
fromourexamplerequestsitbecomesclearthat,inpractice,concernsare<br />
addressedusingamultitude<strong>of</strong>idioms<strong>and</strong>constructs. Thisisthemain<br />
reasonfortheintroduction<strong>of</strong>ournormalisationstep.
7.5. SourceMetamodel 141<br />
WAIT_MEASURE_CLEARED<br />
EXPOSING<br />
entry / expose<br />
WAIT_WAFER_MEASURED_PREPARED<br />
WAIT_WAFER_MEASURED<br />
WAIT_MEASURE_CLEARED SWAPPING<br />
entry / swap<br />
WAIT_WAFER_PREPARED<br />
UNLOADING<br />
entry / unload_wafer<br />
WAIT_WAFER_ARRIVED<br />
exit / get_prealignment_<strong>and</strong>_measurement_data<br />
measure_cleared<br />
[wafer@measure ]<br />
[exposed_wafer@measure ]<br />
<br />
COMBINED_LOADING_UNLOADING<br />
loaded<br />
entry / load_while_unload<br />
[next_wafer2process ]<br />
[else]/ <br />
[else]<br />
/ measure_cleared<br />
exposed<br />
[else]<br />
[else]<br />
arrived<br />
[else]<br />
[wafer@measure ]<br />
[exposed_wafer@measure ]<br />
SWAPPING<br />
entry / swap<br />
MEASURE_AND_PREPARE<br />
entry / prepare, measure<br />
MEASURING<br />
measured<br />
[next_wafer2process ]<br />
prepared measured<br />
measured<br />
measure_cleared<br />
swapped<br />
prepared<br />
[else]<br />
/ measure_cleared<br />
Figure 7.5:Processwaferrequest<br />
LOADING<br />
entry / load_Wafer<br />
loaded<br />
prepared measured<br />
PREPARING<br />
prepared
142 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
IDLE do_unload<br />
[UR not ready ]<br />
WS available<br />
READY_TO_CLAIM_UR START_TO_CLAIM_UR<br />
CLAIM_UR<br />
entry / claim UR<br />
[UR ready]<br />
[combined_load ]<br />
WAIT_WS_MOVED<br />
exit / release WS<br />
FINISH_UR_WS_MOVED<br />
entry / check RCB comm.<br />
START_TRANSFER<br />
entry / start transfer W2U<br />
TRANSFER_FINISHED<br />
WAIT_FOR_UR_OR_WS_MOVED<br />
entry / UR move to rotate, WS finish exchange<br />
WAIT_UR_MOVED<br />
exit / release UR<br />
CHECK_RCB<br />
entry / check RCB comm.<br />
UR_moved WS_moved<br />
WS_moved UR_moved<br />
[RCB ok]<br />
FINISHED<br />
exit / report done<br />
Figure 7.6:Unloadwaferrequest<br />
transfer_finished<br />
[else]
7.6. NormalisationRules 143<br />
7.6 NormalisationRules<br />
UML,asagenericmodellinglanguage,lacksconstructstosupportitsapplicationinthedomain<strong>of</strong>SMCsystems.Thismakesthat,whenusing‘plain’UML,variousdesignidiomsareavailableforh<strong>and</strong>lingSMCconcerns.Forinstance,guards(e.g.,‘subsystemisavailable’)were<strong>of</strong>tenmodelledasevents(e.g.,‘subsystembecomesavailable’)althoughthesearefundamentallydifferent.<br />
Similarly,manufacturingactivitiescanbespecifiedasactionson<br />
statetransitionsorasactionsinseparatestates.Thisidiomdiversityisfuelledfurtherbytoollimitations.Forinstance,toolsthatsupportaspecific<br />
UMLversion,donotnecessarilysupportall<strong>of</strong>itsconstructs.<br />
Todefinearchitecturetransformations,weneedsourcemodelsinanormalisedform.<br />
Thesenormalisedmodelsareassociatedwithametamodel<br />
thataddsconstraintstothelegacysourcemetamodel<strong>and</strong>augmentsitwith<br />
SMC-specificconstructs. Theseconstraints<strong>and</strong>additionalmodelelements<br />
areusedinwell-formednessrulesthatprescribehowtospecifySMC-specific<br />
concerns.Forthis,UMLallowsattachingconstraintstomodelelementsusingOCL,<strong>and</strong>forthedefinition<strong>of</strong>additionalmodelelementsbystereotypes.<br />
Together,theseenablethedefinition<strong>of</strong>asuitableUML-SMCpr<strong>of</strong>ileforthe<br />
normalisedsourcemetamodel.Examplediagramsthatconformtothispr<strong>of</strong>ileareshowninFigures7.7onpage148<strong>and</strong>7.8onpage149.<br />
Normalisedsourcemodelshavetocomplytoaset<strong>of</strong>well-formedness<br />
rules. Mostimportantly,concernshavetobespecifiedinauniformway.<br />
Wehavedefinedast<strong>and</strong>ardisedidiomfortheconcernsasidentifiedinSection7.3.3.Weintroducethisidiombyexample<strong>of</strong>Figures7.7onpage148<strong>and</strong>7.8onpage149.Normalisationinvolvesmodifyingsourcemodelstoremoveanyviolation<strong>of</strong>thesewell-formednessrules.Notethat,duetothediversity<strong>of</strong>theidiomsusedinthesourcemodels,normalisationisperformed<br />
manuallyinourcasestudy.<br />
Table7.1onthefollowingpageliststhestereotypesthatwedefineas<br />
part<strong>of</strong>theSMCpr<strong>of</strong>ile.Nexttostereotypes,thepr<strong>of</strong>ilealsodefinesanumber<strong>of</strong>constraints.Listing7.1onthenextpagelistssome<strong>of</strong>theseconstraints,specifiedinOCLasinvariantsovertheUMLmetamodel(C1-C4).Wemerelyusetheconstraintsindicatedbythedefkeywordtodefineextrapropertiesontheelementsmentionedintheircontext.Thissimplifies<br />
thespecification<strong>of</strong>otherconstraints.Application<strong>of</strong>thesestereotypes<strong>and</strong><br />
constraintsisdiscussedbelow.<br />
Intuitively,thenormalisationiscontextdependent<strong>and</strong>requires(some)<br />
domainknowledge.Moreover,thenormalisationrulesnotonlydependon<br />
thespecificsourceparadigmbutalsoonthemodellingconventionsasencounteredinthespecific(industrial)migrationcontext.Therefore,weillustratethenormalisationstepbydefiningtheusedcontext-specificnormalisationrulesforourcasestudy.
144 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
Table 7.1:SMCpr<strong>of</strong>ilestereotypes<br />
Stereotype baseClass description<br />
≪wait≫ State wait for resource state<br />
≪claim≫ Action claim resource action<br />
≪release≫ Action release resources action<br />
≪available≫ Guard resource available guard<br />
≪available≫ Event resource becomes available event<br />
context Action def:<br />
-- an action is a release action if a stereotype named ’release’ is<br />
applied to it<br />
let isRelease : Boolean = self.stereotype->exists(s|s.name=’release<br />
’)<br />
context State def:<br />
-- a state is a wait state if a stereotype named ’wait’ is applied<br />
to it<br />
let isWait : Boolean = self.stereotype->exists(s|s.name=’wait’)<br />
context Event def:<br />
-- an event is an available event if a stereotype named ’available’<br />
is applied to it<br />
let isRelease : Boolean = self.stereotype->exists(s|s.name=’release<br />
’)<br />
-- C1: all release Actions are state exit actions<br />
context Action inv:<br />
isRelease implies State.allInstances->exists(s|s.exit=self))<br />
-- C2: a wait state has at least one outgoing transition triggered<br />
by an available event<br />
context State inv:<br />
isWait implies outgoing->exists(t|t.trigger.isAvailable))<br />
-- C3: state entry actions are actions that execute manufacturing<br />
activities (i.e., without stereotype)<br />
context State inv:<br />
entry.stereotype->isEmpty<br />
-- C4: all state nodes have no more than two incoming <strong>and</strong> outgoing<br />
transitions<br />
context StateVertex inv:<br />
outgoing->size() size()
7.6. NormalisationRules 145<br />
Subsystemsetups Inthesourcemodel,subsystemstateconsistencyisensuredbyspecifyingsetuptransitionsforeverypossiblesubsystemstateat<br />
design-time. Inpractice,thisisnotdoneexhaustively. Instead,domainknowledgeisusedtolimitthenumber<strong>of</strong>setuprelatedalternativetransitions.<br />
Althoughsubsystemsetupscanbeperformedautomaticallyusing<br />
theTRSparadigm<strong>and</strong>,thus,donotneedtobespecifiedexplicitly,wedo<br />
preservethemduringthenormalisationstep.Thisinfactensuresthatthe<br />
migratedcontrolsystemmimicsthebehaviour<strong>of</strong>thelegacycontrolsystem<br />
exactly. WhenreconsideringFigure7.6onpage142<strong>and</strong>7.8onpage149,<br />
the move to rotateActionisinfactaresourcesetup.<br />
Forthenormalisedsourcemodelwedonotuseaspecificidiomforsetup<br />
activities;setupsaremodelledasanyothermanufacturingactivity. Ifwe<br />
wouldbelessconcernedwithexactpreservation<strong>of</strong>behaviour,setupactivitiescouldbesimplyremovedduringnormalisation.Inthatcase,domainknowledgeisrequiredtodistinguishbetweensetupactivities<strong>and</strong>manufacturingactivities.<br />
Subsystemusage Thepatterntoaddressthe‘subsystemusage’concernis<br />
bestunderstoodfromone<strong>of</strong>theorthogonalregionsinthecompositestate<br />
inFigure7.8onpage149. Beforeamanufacturingactivity(e.g., finish exchange)thatrequiresacertainsubsystem(WS)isexecuted,achoicepseudostateisentered.Then,iftherequiredresourceisavailable([WS<br />
available]),<br />
itisclaimed(claim WS)bythetransitiontowardsthestateinwhichthe<br />
manufacturingactivityisexecuted(FINISH).Otherwise,astate(WAIT_FOR_WS)<br />
isenteredthatisonlyleftwhenaneventoccursindicatingtheresource<br />
hasbecomeavailable(WS available). Theresourceisclaimed(claim WS)on<br />
thetransitiontriggeredbythatevent.Oncethemanufacturingactivityis<br />
performed,claimedresourcesarereleasedagainbyareleaseactionthatis<br />
executedwhenexitingthestate(release).Thispatterncaneasilybegeneralised.<br />
WeusethestereotypesdefinedbytheSMCpr<strong>of</strong>ile(Table7.1)todistinguishbetweenActions,Guards,Events,<strong>and</strong>Statesrelatedtotheuse<strong>of</strong><br />
subsystems<strong>and</strong>thoserelatedtotheexecution<strong>of</strong>manufacturingactivities<br />
(towhichnostereotypesareapplied). Normalisationintroducesstereotypesforspecificmodelelementsthatarerelatedtothesubsystemusage<br />
concern. Furthermore,fromFigure7.6onpage142,<strong>and</strong>itsnormalised<br />
counterpartinFigure7.8onpage149,itcanbeseenthatadditionalmodel<br />
elementsareintroducedtocompletethepatterndescribedabove.Notethat<br />
inFigures7.7onpage148<strong>and</strong>7.8onpage149stereotypesaredisplayed<br />
onlyforstates:thisisalimitation<strong>of</strong>theUMLtoolweareusing(i.e.,’PoseidonforUML’).
146 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
Application<strong>of</strong>thestereotypestosourcemodelsrequiresdomainknowledgetorecognisethesubsystemusageconcern.<br />
Thisbecomesapparent<br />
whenreconsideringFigure7.8onpage149. Here, WAIT_FOR_WSisastate<br />
inwhichthesystemwaitsforasubsystemtobecomeavailable. Thisis<br />
intuitivelydifferentfromthe WAIT_WAFER_MEASUREDstatesinFigure7.7on<br />
page148,wheretheintentionistospecifythatthesystemwaitsforamanufacturingactivitytobecompleted.The<br />
≪wait≫stereotypeisonlyapplied<br />
totheformerstate.<br />
Fornormalisation<strong>of</strong>sourcemodelswerequirethatresourceusagepatternsaremadecomplete.<br />
InFigure7.6onpage142,forinstance,onlya<br />
releaseactionisspecifiedfor WS.InListing7.1onpage144C1,C2,<strong>and</strong>C3<br />
arerelatedtothesubsystemusagepattern. C1specifiesthata≪release≫<br />
ActiononlyoccursasastateexitAction. C2statesthatatleastone<strong>of</strong>the<br />
outgoingTransitionsfora≪wait≫Stateistriggeredbyan ≪available≫<br />
Event.Finally,toconformtoconstraintC3,allActionsrelatedtomanufacturingactivitiesaremovedtoStatesasentryActions.Anexample<strong>of</strong>thisis<br />
the report done(entry)ActioninFigure7.6onpage142thatwasnormalised<br />
toanexitAction(Figure7.8onpage149).<br />
Synchronousexecution Synchronisationbetweensubsequentmanufacturing<br />
activitiesinthesourcemodelsissimplyachievedbytheirorderinthestate<br />
machine. Furthermore,synchronisationbetweensubsystemstatetransitionsisnotmodelledatthislevel.<br />
Assuch,nospecificidiomisusedto<br />
specifythisconcern. Ingeneral,however,wehavetotakethisconcern<br />
intoaccountwhilenormalisingthepatternsassociatedwithotherconcerns.<br />
Whileinserting<strong>and</strong>movingactivitieswehavetomakesurethatwedonot<br />
changetheirorderinthenormalisedsourcemodel.<br />
Concurrentexecution Intheoriginalsourcemodels,concurrencywas<strong>of</strong>ten<br />
modelledusingStates,includingActionsthatstarttwoormoremanufacturingactivities<strong>and</strong>separatetransitionpathsforallpossiblecompletion<br />
sequences,whichareenabledby(external)completionEvents. Asanexample,considerstate<br />
MEASURE_AND_PREPARE<strong>and</strong>associatedcompletionsevents<br />
prepared<strong>and</strong> measuredinFigure7.5onpage141.Becausethoseeventscan<br />
onlybeassociatedwiththeircorrespondingmanufacturingactivitiesusing<br />
namingconventions,suchanapproachcomplicatesthedetermination<strong>of</strong><br />
thescope<strong>of</strong>concurrentexecution.Therefore,werequirethatconcurrency<br />
ismodelledusingaconcurrentCompositeStatecontaining(orthogonal)regions.<br />
Thisimpliesthatduringnormalisation,manufacturingactivities<br />
aremappedtoCompositeStateswhentheyarestartedinasingleState<br />
node<strong>and</strong>alternativecompletionsequencesarespecifiedexhaustively.Figure7.8onpage149containsanexample<strong>of</strong>concurrentexecution,where
7.7. TargetMetamodel 147<br />
tworesourceusagepatternsareexecutedinparallel.<br />
Conditionalexecution Theidiomforconditionalexecutionismorecomplicated.<br />
First,werequireittobespecifiedusingachoicePseudostatewith<br />
twooutgoingTransitions. OnespecifiessomeconditionasaGuard;the<br />
otherspecifies [else]asaGuard.Furthermore,werequire‘proper’nesting<br />
<strong>of</strong>conditionalactivationpathsinastatemachine.Thismeansthatwerequirepairs<strong>of</strong>corresponding,alternativepathsthroughthestatemachinetobemergedoneatatime(usingjunctionPseudostates),<strong>and</strong>inreverseorder.Figure7.7onthefollowingpagecontainsseveral(nested)examples<strong>of</strong><br />
thispattern(choice<strong>and</strong>junctionPseudostatesaredepictedusingdiamonds<br />
<strong>and</strong>thesmallerblackcircles,respectively).<br />
Withoutthisrequirementforpropernesting,findingtheset<strong>of</strong>States,<br />
<strong>and</strong>thusActions,whichareenabledwhensomeGuardevaluatestotrue<br />
wouldbecomerathercomplicated. Forthetransformation<strong>of</strong>oursource<br />
modelstotargetmodels,findingthisset<strong>of</strong>statesisanecessarystep.‘Nonproper’nestingoccurs,forinstance,inthebottom-half<strong>of</strong>theprocesswafer<br />
requestinFigure7.5onpage141. Thisresultsinreplication<strong>of</strong>theactivitiesperformedoneachpathduringnormalisation.ThethreeCompositeStatesinthebottom-half<strong>of</strong>Figure7.7onthefollowingpageillustrate<br />
thisreplication. Part<strong>of</strong>thisparticularnormalisationstepiscoveredby<br />
constraint C4,whichstatesthatapaththroughastatemachinecanonly<br />
splitintwopaths<strong>and</strong>thatnomorethantwopathscanbejoinedinasingle<br />
statenode.BecausetheOCLconstrainttoexpresspropernestingisrather<br />
lengthy,wedidnotincludeithere.<br />
7.7 TargetMetamodel<br />
Weconsider TRSasthegivenparadigmfortheend-point<strong>of</strong>themigration.Thisend-pointisbasedonaresearchprototype[V<strong>and</strong>enNieuwelaar,<br />
2004]. Usingthe TRSparadigm,amanufacturingrequestistranslated<br />
intovalidmachinebehaviourintwophases.First,uponarrival<strong>of</strong>amanufacturingrequest,aschedulingprobleminthecontext<strong>of</strong>thatrequestis<br />
instantiatedduringaplanningphase.Forthis,therequestisinterpreted<br />
throughrulesthatoperateoncapabilities(resourcetypes)<strong>and</strong>behaviours<br />
(tasktypes). Here,amanufacturingactivitycorrespondstoatask<strong>and</strong>a<br />
mechatronicsubsystemtoaresource. Thefirstphaseresultsinahierarchicaldigraphthatconsists<strong>of</strong>tasks<strong>and</strong>their(precedence)relations.Nodes<br />
inthisgraphcanbecompositetoeitherdenoteaset<strong>of</strong>tasksthatallneed<br />
tobeexecutedortodenoteaset<strong>of</strong>tasks<strong>of</strong>whichonlyonewillbeexecutedbasedonsomecondition.Second,aschedulingphaseconstructively<br />
assignstasksinthisdigraphtospecificresourcesovertime[Viennot,1986;
148 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
WAIT_WAFER_ARRIVED<br />
entry / get_prealignment_<strong>and</strong>_measurement_data<br />
arrived<br />
[wafer@measure ]<br />
WAIT_MEASURE_CLEARED<br />
[else]<br />
[else]<br />
WAIT_WAFER_MEASURED_PREPARED WAIT_WAFER_MEASURED_PREPARED WAIT_WAFER_MEASURED_PREPARED<br />
WAIT_MEASURE_CLEARED<br />
[else]<br />
[exposed_wafer@measure ]<br />
COMBINED_LOADING_UNLOADING<br />
@measure_cleared<br />
WAIT_WAFER_MEASURED<br />
measured<br />
WAIT_WAFER_PREPARED<br />
prepared<br />
LOADING<br />
entry / load_wafer<br />
[wafer@measure ]<br />
COMBINED_LOADING_UNLOADING<br />
[else]<br />
LOADING<br />
entry / load_wafer<br />
[wafer@measure ]<br />
[exposed_wafer@measure ]<br />
[next_wafer2process ]<br />
measure_cleared<br />
entry / load_while_unload<br />
entry / load_while_unload<br />
EXPOSING<br />
entry / expose<br />
/ @measure_cleared<br />
[else]<br />
WAIT_WAFER_MEASURED<br />
measured<br />
WAIT_WAFER_PREPARED<br />
prepared<br />
SWAPPING<br />
entry / swap<br />
SWAPPING<br />
entry / swap<br />
[else]<br />
/ @measure_cleared<br />
MEASURE_AND_PREPARE<br />
/ measured<br />
MEASURING<br />
entry / measure<br />
PREPARING<br />
entry / prepare<br />
/ prepared<br />
Figure 7.7:Normalisedprocesswaferrequest<br />
[else]<br />
[next_wafer2process ]<br />
WAIT_WAFER_MEASURED<br />
UNLOADING<br />
entry / unload<br />
measured<br />
WAIT_WAFER_PREPARED<br />
prepared
7.7. TargetMetamodel 149<br />
><br />
WAIT_FOR_WS<br />
WS available/ claim WS<br />
[else]<br />
><br />
WAIT_FOR_WS<br />
><br />
WAIT_FOR_UR<br />
CHECK_RCB<br />
entry / check RCB comm.<br />
[else]<br />
[UR available ]/ claim UR<br />
Concurrent_State<br />
[WS available]/ claim WS<br />
FINISH<br />
[UR available ]/ claim UR<br />
[else]<br />
[else]<br />
entry / finish_exchange<br />
exit / release<br />
/ WS_moved<br />
WS available/ claim WS<br />
MOVE<br />
entry / move UR to rotate<br />
exit / release<br />
/ UR_moved<br />
UR available / claim UR<br />
CHECK_RCB<br />
entry / check RCB comm.<br />
[WS available]/ claim WS<br />
><br />
WAIT_FOR_UR<br />
/ transfer_finished<br />
TRANSFER<br />
entry / transfer_W2U<br />
[combined_load ]<br />
exit / release<br />
[else]<br />
UR available / claim UR<br />
[RCB ok]<br />
REPORT<br />
entry / report done<br />
Figure 7.8:Normalisedunloadwaferrequest
150 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
Figure 7.9:Moduleviewfortheproduct-lineSMCarchitecture<br />
V<strong>and</strong>enNieuwelaar,2004].Thisresultsinafullytimed,coordinatedTRS<br />
thatcanbedispatchedforexecution.<br />
Theend-pointforourmigrationisaproduct-linearchitecture,<strong>of</strong>which<br />
Figure7.9displaysthemoduleview.Inthisarchitecture,thedecisionalresponsibilitiesareassignedtothreegeneric<strong>and</strong>reusablecomponents:Planner,<br />
Scheduler,<strong>and</strong> Dispatcher.Thisproduct-linearchitecture<strong>of</strong>fersvariabilitywithrespecttotasks<strong>and</strong>resources<strong>and</strong>canbeinstantiatedforaspecific<br />
controllerbyimplementing System definition<strong>and</strong> Subsystem interfacemodules.<br />
Thesemodulesdefinethespecificsystemundercontrol<strong>and</strong>implementthe<br />
interfacingwithlower-levelcomponents. The System definitionmoduleis<br />
amenableforcodegeneration,allowingforareduction<strong>of</strong>s<strong>of</strong>twaredevelopmenttime<strong>and</strong>effort.<br />
Inordertodefineourtargetmodels,weintroduceagoverningtarget<br />
metamodelasdepictedinFigure7.10. There,thesystemdefinitionfrom<br />
Figure7.9isrepresentedbythe SystemDefinition,whichservesasarootelement.<br />
Thissystemdefinitionconsists<strong>of</strong>astatic<strong>and</strong>dynamicpart. The<br />
staticpartdefinestheavailable Behaviours, Resources<strong>and</strong> Capabilities<strong>of</strong>the<br />
systemundercontrol. Theseareusedtomodeltypes<strong>of</strong>manufacturing<br />
activities,subsystems,<strong>and</strong>types<strong>of</strong>subsystems. Inaddition,toaddress<br />
thesubsystemusageconcern,itdefineswhichcapabilitiesarerequiredby<br />
whichbehaviour. Furthermore,thecorresponding beginState<strong>and</strong> endState<br />
arespecifiedin CapabilityUsage. Thesestatesare,forinstance,usedtodeterminesequencedependentsetups.<br />
Thedynamicpart<strong>of</strong>Figure7.10 representstherulesforuniquelymappingamanufacturing<br />
Requestto SimpleTasks,whichare<strong>of</strong>aspecificBehaviour,<strong>and</strong>assigningResourcesthat<br />
fulfilarequiredCapability.EveryTask
7.8. Transformation 151<br />
+ capability<br />
CapabilityUsage<br />
+ beginState :EInt<br />
+ endState :EInt<br />
+ requires<br />
Resource<br />
+ name :EString<br />
+ fulfils<br />
Capability<br />
+ name :EString<br />
*<br />
Behaviour<br />
+ name :EString<br />
*<br />
+ resources<br />
*<br />
+ capabilities<br />
1..*<br />
+ behaviours<br />
+ behaviour<br />
SystemDefinition<br />
+ requests<br />
+ id :EString<br />
*<br />
+ tasks<br />
+ iftrue<br />
AndTask<br />
Request<br />
+ name :EString<br />
OrTask<br />
+ condition :EString<br />
Static Dynamic<br />
1..*<br />
+ predecessors<br />
*<br />
+ tasks<br />
1..* + iffalse<br />
Task<br />
SimpleTask<br />
Created with Poseidon for UML Community Edition. Not for Commercial Use.<br />
Figure 7.10:Targetmetamodel<br />
includesaset<strong>of</strong>(direct) predecessors,thatis,otherTasksthatneedtobe<br />
executedbeforeitcanbedispatched.Thisrelationisusedto(dis)allowconcurrency<strong>and</strong>implysynchronisation;inprinciplealltasksareexecutedinparallel,unlesspreventedbythepredecessorrelation.Conditionalexecutioncanbespecifiedusing<br />
OrTasks,thatcontaintwo Tasks(iftrue<strong>and</strong> iffalse)<br />
thatmaybecomposite.Theevaluation<strong>of</strong>its conditiondetermineswhichone<br />
willbedispatched.Finally,toclusterTasksthatallneedtobeperformed,<br />
an AndTaskcanbeused.<br />
7.8 Transformation<br />
Our transformation rules are defined as mappings from a normalised<br />
sourcemetamodel(i.e.,our UMLpr<strong>of</strong>ile)toaTRSmetamodel. Weused<br />
MOFtodefinethetargetmetamodelratherthantailoringtheUMLusing<br />
yetanotherpr<strong>of</strong>ile. Inthissectionwefirstintroducethetransformation<br />
languagethatwasusedtodefinethetransformationstep<strong>of</strong>ourmigration<br />
approach.<br />
Forthedefinition<strong>of</strong>ourtransformationsweusedthefollowingstrategy.<br />
First,weindicatehowelementsinthenormalisedsourcemetamodelare<br />
relatedtotheprimaryelements<strong>of</strong>thetargetmetamodel.Second,foreach
152 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
rule Tasks {<br />
from s:UML!SimpleState (<br />
s.isTaskState <strong>and</strong> not thisModule.behaviourStates->includes(s))<br />
to t: TRS!SimpleTask (<br />
behaviour
7.8. Transformation 153<br />
Foreveryelementinthesourcemodelthatmatchesthesourcepattern<br />
<strong>of</strong>arule,theelementsspecifiedbythetargetpatternarecreatedinthetargetmodel.NotethatinATL,thesourcemodelisread-only<strong>and</strong>thetarget<br />
modeliswrite-only.ThiscanalsobeseenfromListing7.2,whereonlythe<br />
sourcemodelisnavigatedtoinitialisethefeaturesreferredtointhebindings<strong>of</strong>thetargetpattern.Therefore,aspecificvalue-resolutionalgorithm<br />
isusedtoinitialisefeatures:iftheexpression<strong>of</strong>abindingreferstoanother<br />
targetelement(createdbythesamerule)itissimplyassigned,ifitrefers<br />
toasourceelementitisresolvedbyapplication<strong>of</strong>therulethatmatches<br />
thatsourceelement<strong>and</strong>takingthedefault(first)targetelement.<br />
Forcaseswheretherequiredtargetelementisnotthedefaultelement<br />
<strong>of</strong>anotherrule,ATL<strong>of</strong>fersthe‘resolveTemp’construct,aso-calledhelper<br />
operation. Ittakesasourcemodelelement<strong>and</strong>areferencetoaspecific<br />
targetelement<strong>of</strong>thematchingruleasinputparameters.InListing7.2,for<br />
example,thisisdoneinthebinding<strong>of</strong>thebehaviourfeature.Inthiscases.<br />
behaviourStateevaluatestoaSimpleStatethatismatchedbyanotherrule<br />
withmultipletargetelements,<strong>of</strong>whichthe ‘b’targetelementisselected<br />
tobindtothatfeature.<br />
Helpersaretypicallydefinedinthecontext<strong>of</strong>ametamodelelement<strong>and</strong><br />
effectivelyaddafeatureoroperationtoinstances<strong>of</strong>thatelement(cf. the<br />
use<strong>of</strong>OCLdefinitionconstraintsinListing7.1onpage144).Alternatively,<br />
ahelpercanbedefinedwithoutanycontext. Then,thedefaultcontext<strong>of</strong><br />
thecompletetransformationmodule,representedbythe thisModuleelement,applies.<br />
The resolveTemphelperisalsodefinedinthisdefaultcontext.<br />
7.8.2 BasicTarget<strong>Model</strong>Elements<br />
SimpleTask<strong>and</strong>Behaviour SimpleTaskscorrespondtomanufacturingactivities,<strong>and</strong>Behaviourscorrespondtotypes<strong>of</strong>manufacturingactivitiesinSMC<br />
systems. Therefore,tocreateSimpleTasks<strong>and</strong>Behavioursinthetarget<br />
modelweneedtoidentifyActionscorrespondingtomanufacturingactivitiesinthesourcemodel.AccordingtotheUMLSMCpr<strong>of</strong>ile,anActionthatcorrespondstoamanufacturingactivityhasnostereotype<strong>and</strong>isexecutedasaStateentryAction(see<br />
C3inListing7.1onpage144). ForeverysuchAction,aSimple-<br />
Taskneedstobecreated. ThisisspecifiedbytheruleinListing7.3on<br />
thenextpage.Itcontainsaguardthatusesthe behaviourStateshelperto<br />
onlymatchSimpleStatesthatmaptoaBehaviour.Notethatinthespecification,wedonotmapActionstoSimpleTasks,butinsteadwemaptheSimpleStatesinwhichtheyareexecutedtoSimpleTasks.ThisdoesnotaffectourmigrationresultssinceActionscorrespondingtoSimpleTasksare<br />
alwaysStateentryActions(byconstraintC3<strong>of</strong>theSMCpr<strong>of</strong>ile).
154 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
rule Behaviours {<br />
from s: UML!SimpleState (<br />
thisModule.behaviourStates->includes(s))<br />
to t: TRS!SimpleTask (<br />
behaviour
7.8. Transformation 155<br />
SystemDefinition<strong>and</strong>Request TheSystemDefinitionrootelementinatarget<br />
modelcontainsallrequiredelementsthatdefinethedomainspecificpart<strong>of</strong><br />
anSMCcontroller.Assuch,thiselementcorrespondstoacompletesource<br />
model.<br />
ARequestencompassesrulesthatdeterminehowthatparticularmanufacturingrequest,suchasourunloadwaferfromFigure7.6onpage142,isplanned.Planningrulesinvolveaset<strong>of</strong>Tasks<strong>and</strong>correspondingpredecessorrelations.Additionally,aTaskcanbeanAndTaskoranOrTask.Inthesourcemodel,acompletestatemachineisusedtospecifyhowamanufacturingrequestistobeexecuted.So,wecreateaRequestelementinthe<br />
targetmodelforeveryStateMachineinthesourcemodel.<br />
Listing7.4onthenextpageshowstheATLspecification<strong>of</strong>thismapping.<br />
The RequestrulegeneratesaRequestelementforeveryStateMachinein<br />
thesourcemodel.ThisRequestcontainstaskswhicharecreatedbyother<br />
rules.Aswillbeexplainedlater,StatesorGuardsinthesourcemodelmay<br />
mapto Tasksinthetargetmodel. Becausethetasksinourtargetmodel<br />
maybecompositeinwhichcasetheyownothertasks,weshouldtakecare<br />
nottoselectallmodelelementsinthecompletestatemachinethatmap<br />
toaTask.Instead,foraRequestwediscardallStatesorGuardsinsidea<br />
CompositeStateotherthanthetop,<strong>and</strong>onpathsthatareonlyconditionally<br />
enabled(i.e.,byatransition’sguard).Tothisend,wedefinedtwoadditional<br />
generichelpers.First, rootOfSubTreetakesaset<strong>of</strong>statesasargument<strong>and</strong><br />
recursivelyselectsthe‘first’state<strong>of</strong>thatset(i.e.,theonewithoutincoming<br />
transitionsfromotherstatesintheset). Second, getTask<strong>Model</strong>Elementsis<br />
appliedtothat‘first’StatetocollectallmodelelementsthatmaptoaTask.<br />
Inessence,thishelpertakesaset<strong>of</strong>states<strong>and</strong>traversesthissetasa<br />
state‘tree’startingfromtheState(orGuard)itisappliedto,<strong>and</strong>bypassing<br />
CompositeStates<strong>and</strong>conditionalpaths.Duringthistraversalitcollectsall<br />
modelelementsitencountersthatmaptoaTask(i.e.,GuardsorStates).<br />
The SystemDefinitionrulegeneratesaSystemDefinitionelementthat<br />
correspondstothecompletesourcemodel.The behaviours, resources<strong>and</strong><br />
capabilityfeatures<strong>of</strong>theSystemDefinitionelementareboundtotheresult<strong>of</strong>otherrules.<br />
Inparticularfor behaviours<strong>and</strong> resourceswehadto<br />
usethe resolveTemphelperasthesearenotcreatedbythedefaulttarget<br />
elements<strong>of</strong>theinvolvedrules. Inthiscase,therelevantsourcemodelelementsareselectedbytwohelpersthataredefinedinthecontext<strong>of</strong>the<br />
transformationmoduleitself: behaviourStatesgivesallthesourcemodelelements(SimpleStates)thatmaptoaBehaviour,<strong>and</strong><br />
resourceActionsgives<br />
allthesourcemodelelements(≪claim≫Actions)thatmaptoaResource.<br />
TherequestfeatureisboundtotheelementscreatedbytheRequestrulefor<br />
allStateMachinesinthesourcemodel.
156 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
rule Request {<br />
from sm: UML!StateMachine<br />
to rq: TRS!Request (<br />
tasks asSequence()->first()).getTask<strong>Model</strong>Elements(sm.top.<br />
subvertex))<br />
}<br />
rule SystemDefinition {<br />
from sm: UML!<strong>Model</strong><br />
to sd: TRS!SystemDefinition (<br />
behaviours collect(e|thisModule.<br />
resolveTemp(e,’b’)),<br />
resources collect(e|thisModule.<br />
resolveTemp(e,’r’)),<br />
capabilities
7.8. Transformation 157<br />
rule ResourceUsage {<br />
from s:UML!SimpleState (s.isWait)<br />
to cu: TRS!CapabilityUsage (<br />
capability select(a|a.script.body=s.<br />
outgoing->select(t|t.effect.isClaim).effect.script.body))<br />
}<br />
Listing 7.5:Ruleforresourceusagepattern<br />
callthe getResourceClaimshelperthatrecursivelyfindsall ≪wait≫States<br />
bybackwardstraversal<strong>of</strong>thestatemachineuntila≪release≫Actionis<br />
encountered. A ≪release≫Actionreleasesallclaimedsubsystems. The<br />
≪wait≫StatesinthereturnedsetmatchtheResourceUsagerule<strong>and</strong>the<br />
BehaviourislinkedbyitsrequiresattributetothecorrespondingCapabilityUsageelements.<br />
Resourcesetups Inthetargetmodel,setupsareautomaticallyinsertedby<br />
thegeneric(solving)part<strong>of</strong>theproduct-linearchitecture. Thisisdoneat<br />
run-time,basedonmismatchingbeginState<strong>and</strong>endStateattributes<strong>of</strong>the<br />
CapabilityUsageelement.Tosomeextent,thesecouldbederivedfromthe<br />
explicitlyspecifiedsetupsinthesourcemodel.<br />
Inthischapter,however,wedonotdefineacorrespondingtransformationruleasitdependsheavilyondomainknowledge.Usingourtransformations,setupswillexplicitlyendupinthetargetmodelasjustanother<br />
task<strong>and</strong>behaviour.Assaid,thisensuresthatthemigratedcontrolsystem<br />
mimicsthebehaviour<strong>of</strong>thelegacycontrolsystemexactly,thusresulting<br />
inavalidated<strong>and</strong>acceptablebaseline.<br />
Synchronousexecution ThetargetmodeldefinesprecedencerelationsbetweenthoseTasksthatrequiresynchronisation(withinthesameRequest).Inprinciple,theserelationsfollowfromtheexecutionorder<strong>of</strong>themanufacturingactivities<strong>and</strong>thecorrespondingActionswithinanormalisedstatemachine.Inaddition,(virtual)resourcescanbeusedforexternalsynchronisation.<br />
ForsynchronisationwithinaRequest,predecessorrelationsarecreated<br />
foreverytaskbysearchingforitsset<strong>of</strong>(direct)predecessortasks. For<br />
thiswehavedefinedtwohelpersthatbothoperateontheelementsthat<br />
matchrulesthatcreateTasks.ThefirsthelperisdepictedinListing7.6on<br />
thefollowingpage<strong>and</strong>isdefinedonStateVertexwhereasthesecondone<br />
isdefinedonGuard. ForeachTask,one<strong>of</strong>these getPredecessorshelpers<br />
isinvokedonitscorrespondingStateVertexorGuard. Thesehelpersdeterminewhetherthecurrentelement(self)correspondstoatask.<br />
Ifso,<br />
thiselementisreturned. Otherwise,thehelperisrecursivelyappliedto
158 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
helper context UML!StateVertex def: getPredecessors:Set(UML!<br />
<strong>Model</strong>Element) =<br />
if self.incoming->isEmpty() then<br />
Set{}<br />
else if self.isOrTaskStateJoin then<br />
self.getFork.outgoing->collect(e|e.guard)->select(e|e.<br />
isOrTaskGuard)<br />
else if self.incoming->collect(e|e.guard)->select(e|not e.<br />
oclIsUndefined())->exists(e|e.isOrTaskGuard or if e.oppositeGuard.<br />
oclIsUndefined() then false else e.oppositeGuard.isOrTaskGuard<br />
endif) then<br />
Set{}<br />
else if self.incoming->collect(e|e.source)->select(e|e.isTaskState)<br />
->isEmpty() then<br />
self.incoming->collect(e|e.source.getPredecessors)->flatten()<br />
else<br />
self.incoming->collect(e|e.source)->select(e|e.isTaskState)<br />
endif endif endif endif;<br />
Listing 7.6:CollectpredecessorsonStateVertex<br />
thefiniteset<strong>of</strong>alldirectprecedingmodellingelementsthatmaymaptoa<br />
task.<br />
Concurrentexecution Thenormalisedpatternforconcurrency,asdiscussed<br />
inSection7.6,isaCompositeStatewithorthogonalregions.Toaddressthe<br />
concurrentexecutionconcernweneedtoidentifyinstances<strong>of</strong>suchpatterns<br />
inthesourcemodel.<br />
WedefinedatransformationrulethatcreatesanAndTaskforeveryconcurrentCompositeStateinthesourcemodelexceptforthetopComposite-State<strong>of</strong>theStateMachine.Basically,thepredecessorsrelationisthemechanismusedinthetargetmodelto(dis)allowconcurrency:iftwotasksare<br />
notrelatedbythetransitiveclosure<strong>of</strong>thepredecessorsrelation,theycan<br />
executeconcurrently.Now,thesepotentiallyconcurrenttasksareexecuted<br />
assoonasexecution<strong>of</strong>theirpredecessorshasfinished<strong>and</strong>therequired<br />
resourcesareavailable.Inturn,thisalsoimpliesthatataskcanhavemultiple(concurrent)predecessors.<br />
Collectingpredecessortaskswasalready<br />
discussedinthepreviousparagraph.<br />
ConditionalExecution AsdiscussedinSection7.6, thenormalisedsource<br />
modelusesastatewithtwooutgoingguardedtransitionstospecifyconditionalexecution.Everytwoalternativeconditionalbranchesinasource<br />
modelaremappedtoanOrTaskinthetargetmodel.ThisOrTaskcontains<br />
twosubtasks(iftrue<strong>and</strong>iffalse),whichmaybecomposite<strong>and</strong>representthe<br />
twoconditionallyexecutedbranchesfollowingaStatewithtwooutgoing
7.8. Transformation 159<br />
rule ConditionalExecution {<br />
from g:UML!Guard (g.isOrTaskGuard)<br />
to t: TRS!OrTask(<br />
condition
160 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
(a)TRStargetmodel<br />
check RCB comm.<br />
<br />
transfer W2U<br />
[combined_load]<br />
<br />
move UR to rotate<br />
check RCB comm.<br />
report done<br />
[not(combined_load)]<br />
<br />
finish exchange<br />
(b)ActivityDiagram<br />
Figure 7.11:Resultsforunloadwaferrequest<br />
unload_wafer.TheselectedelementunderthePropertiestabinthebottom<br />
partrevealsthat“SimpleTask check RCB comm.”canonlybedispatchedafter<br />
itspredecessor“OrTask combined_load”hasbeenexecuted.<br />
Theconsequence<strong>of</strong>usingacustommetamodelisthatweonlyhavethe<br />
basicgeneratededitortovisualise<strong>and</strong>documentourtransformationresults.Again,weturnedtomodeltransformationstosolvethisproblem.As<br />
thereisnosuitablegraphicalrepresentationforcompleteTRSmodelsyet,<br />
wedefinedatransformationthatmapsaTRSmodeltoUMLActivityGraphs<br />
forthedynamicpart(oneforeachrequest)<strong>and</strong>aUMLClassmodelforthe<br />
staticpart.Theresult<strong>of</strong>thistransformationcaneasilybedisplayedusing<br />
UMLtools. Figure7.11(b)onthispage,forinstance,showsthedynamic<br />
part<strong>of</strong>ourunloadwaferrequestdisplayedasanUMLActivityGraph.<br />
Notethat,wemerelyuseUMLnotationtorepresentpart<strong>of</strong>thetaskresourcemodel.Assuch,thesemanticsarenotidenticaltothat<strong>of</strong>UMLactivitygraphs,butonlysimilar.WerepresentTasksasActivitiesstereotyped<br />
withtheresourcetheyrequire. Thetransitionrepresentpredecessorrelationships(inreversedirection).ForAndTasksweuseforkPseudostates(representedbythehorizontalblackbar).AcompleteAndTaskisthusrep-
7.9. Evaluation 161<br />
resentedbythesubgraphthatstartswithafork<strong>and</strong>endswhenthetwo<br />
concurrentpathsarejoined. OrTasksarerepresentedusingchoicePseudostates(representedbyadiamondwithtwooutgoingarrows).Similarto<br />
theAndTaskacompleteOrTaskisthusrepresentedbythesubgraphthat<br />
startswithachoicePseudostate<strong>and</strong>endswhenthetwoconditionalpaths<br />
arejoined.Forconveniencewedidnotexplicitlyrepresentedthejoin<strong>of</strong>the<br />
twoconcurrentpaths(i.e.,usinganotherhorizontalbar);theyarejoinedin<br />
thesamenode(thediamondwiththreeincomingarrows)astheconditional<br />
paths.<br />
7.9 Evaluation<br />
Applicability Application<strong>of</strong>ourgeneric,model-drivenmigrationapproach<br />
requiresthatthesourceview<strong>and</strong>targetviewcanbedefinedusingametamodel.<br />
Whenthisispossible,theactualmigrationfromsourcetotarget<br />
constitutesaseries<strong>of</strong>modeltransformations.<br />
Inpractice,modelsareonlymadeascomplete<strong>and</strong>accurateasisdem<strong>and</strong>edbytheirapplication.However,thesedem<strong>and</strong>sbecomemorestringentwhenthesemodelsareusedasinputforautomatedprocessingsuch<br />
asmodeltransformations. Asaresult,thecontext-specificnormalisation<br />
stepiscrucialtotheapplicability<strong>of</strong>ourmigrationapproachinindustrial<br />
contextswhere(source)modelsaretypicallyusedforcommunication<strong>and</strong><br />
documentationpurposesonly.<br />
MOF-basedmetamodelsonlyprovidetheabstractsyntaxforconformingmodels<strong>and</strong>donotdefinehowtovisualisethem(concretesyntax).<br />
In<br />
factthisisadrawback<strong>of</strong>usingacustommetamodel:nomodeleditors<strong>and</strong><br />
viewersareavailable,apartfromthebasiceditorasgeneratedbytheEMF<br />
plugin.Inthischapterweagainturnedtomodeltransformationstodocument<strong>and</strong>visualiseourresults.Theuse<strong>of</strong>modeltransformationsprovides<br />
anelegant<strong>and</strong>flexibleway<strong>of</strong>generatingarchitecturedocumentationthat<br />
caneasilybetailoredtomeetspecificdocumentationrequirements<strong>of</strong>amigrationcontext.ThisisfurtherdiscussedinChapter8.<br />
Itturnedoutthatamodel-drivenmigrationapproachbasedon MDA<br />
isusefulforrapid(incremental)development<strong>of</strong>normalisationrules<strong>and</strong><br />
transformationrules. Thatis,resultscaneasilybevisualised<strong>and</strong>documentedgiventhewidevariety<strong>of</strong>availabletools.<br />
Scalability Withrespecttothescalability<strong>of</strong>ourapproachwecansafely<br />
statethatourexperimentsare<strong>of</strong>thesameorder<strong>of</strong>magnitudeasfullfledgedcomponentmigrationsforreal-worldwaferscannerapplications.<br />
Moreconcretely,thetworequeststhatweremigratedasapro<strong>of</strong><strong>of</strong>concept
162 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
accountforapproximately10-20%<strong>of</strong>thesourcecodeforourSMCcomponents.Theapplication<strong>of</strong>ourtransformationrulestothetworepresentativeexamplespresentedinthischapterrequireslessthan10secondsto<br />
completeona1.7GHznotebook. Furthermore,weexpecttheexecution<br />
timetobelinearwithrespecttothenumber<strong>of</strong>requests. Moreimportant<br />
fortheexecutiontimeisthenestingdepth<strong>of</strong>conditionalpaths. Forour<br />
industrialcasewehavenotencounteredrequestswithdeepernestingthan<br />
ourexamplerequests.<br />
Effectiveness Ourmodel-drivenapproachrequiresthatimplicitdesigndecisions<strong>and</strong>designknowledgeisconsolidated<strong>and</strong>madeexplicitforthedefinition<strong>of</strong>metamodels<strong>and</strong>transformationrules.<br />
Assuch,theapplication<br />
<strong>of</strong>ourapproachtothe SMCcomponents<strong>of</strong>ourcasestudyincreasedthe<br />
generalunderst<strong>and</strong>ing<strong>of</strong>concerns<strong>and</strong>theassociatedimplications(<strong>and</strong><br />
difficulties)surroundingthearchitecturemigration<strong>of</strong>SMCsystems.Moreover,theneedforexpertsonboththedomain<strong>and</strong>thetargetparadigmwas<br />
confinedtothedefinition<strong>of</strong>thenormalisation<strong>and</strong>transformationrules.<br />
Theeffectiveness<strong>of</strong>boththeMDAapproach<strong>and</strong>ourmodel-drivenmigrationapproachdependspartiallyontheability<strong>of</strong>modelling,transformation<strong>and</strong>codegenerationtoolstocooperate.<br />
Assuch,st<strong>and</strong>ardsinvolved<br />
withtheMDA,suchasMOF,UML,<strong>and</strong>particularlyXMI,playanimportant<br />
role. Inpractice,theavailability<strong>of</strong>differentversions<strong>of</strong>thesespecificationsmadeitdifficulttosetupanappropriatetoolchain.Forinstance,we<br />
couldnotusethelatestversion<strong>of</strong>ourUMLmodellingtool(i.e.,’Poseidonfor<br />
UML’)becausetheUMLmetamodelituses,wasincompatiblewiththeATL<br />
transformationengine.Althoughwetooktheliberty<strong>of</strong>selectingtoolsthat<br />
wereabletocooperate,westillneededtoimplementsomeadditionaltransformationsusingExtensibleStylesheetLanguageTransformations<br />
1 (XSLT)<br />
toovercomesomeincompatibilitiesbetweenthevarioustools.Inindustry<br />
itwillnotalwaysbepossibletoselectaspecificset<strong>of</strong>toolsforthemigrationgivenpracticalconsiderationssuchaslicensing,support,<strong>and</strong>training<br />
costs.<br />
Apartfromtoolsupport,therequiredhumaninterventionduringthe<br />
normalisationstepalsodeterminestheeffectiveness<strong>of</strong>ourmigrationapproach.Thecomplexity<strong>of</strong>thenormalisationstepdependsonthenumber<strong>of</strong>constraintsthattherestrictedsourcemetamodeladdstothelegacy<br />
sourcemetamodel(ifpresent).Here,atrade-<strong>of</strong>fapplies:fewerconstraints<br />
makethetransformation,whichistypicallyautomated,morecomplexbecausemorespecificationalternativeshavetobecovered.<br />
Forinstance,if<br />
wewouldallowActionscorrespondingtomanufacturingactivitiestooccur<br />
asActionsonTransitions,searchingforpredecessorswouldbecomemuch<br />
1 http://www.w3.org/TR/xslt(June2007)
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.
164 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
s20<br />
s21<br />
t43<br />
t42<br />
t44<br />
s10<br />
s18<br />
t40 t41<br />
t35<br />
t34<br />
t36 t83<br />
s19<br />
s14<br />
s17<br />
t79<br />
t37<br />
t19 t58 t20<br />
t82<br />
t31<br />
t33<br />
t32<br />
t18 s12 t60 t77 s15 s16 t23 s13 t85 t45 t63 t46 t64<br />
t21<br />
t78<br />
t29 t30 t59 t24t28<br />
t25 t26 t71<br />
t22<br />
t84<br />
t62<br />
Figure 7.12:One<strong>of</strong>threeconcurrentstatemodels(madeanonymous)<br />
s22<br />
s23<br />
s4<br />
t38 t39<br />
s11<br />
t56<br />
t61<br />
s24<br />
t47<br />
t48<br />
t53<br />
t76<br />
t51t80<br />
t50 t68 s2 t49 t67 s3 t17 t70 s5 t7 s6 s7<br />
t52 s8 t65<br />
s9<br />
t4<br />
t66<br />
t5<br />
t6 t73 t74<br />
t69<br />
t8<br />
t16<br />
t13 t14t15t57 t9t10<br />
t75<br />
t11<br />
t81<br />
t12<br />
t27 t72<br />
s1<br />
t55<br />
t0 t1 t2t54 t3<br />
s0
7.10. Conclusions<strong>and</strong>FutureWork 165<br />
Weextractedtheprocesswaferrequeststatemachinefromthethree<br />
implementedconcurrentstatemachines<strong>and</strong>thecorrespondingsourcecode<br />
byisolatingstatetransitionpaths<strong>and</strong>combiningthemintoarequeststate<br />
model. Theresultingextractedsourcemodelswereusedastheinputfor<br />
ournormalisationstep.Infact,suchanextractionstepinwhichweisolate<br />
requeststatemachines(i.e.,toobtainmodelstobenormalised)canbeseen<br />
asanextension<strong>of</strong>the‘front-end’<strong>of</strong>ourapproach.<br />
The‘back-end’<strong>of</strong>ourapproachcanbeextendedaswellbystepsthat<br />
furtherprocesstheresult<strong>of</strong>ourmodeltransformations.Wealreadymentionedthegeneration<strong>of</strong>documentation.Anotherpossibleextensionisthegeneration<strong>of</strong>sourcecodetoactuallygeneratetheSystemDefinitionmodule<strong>of</strong>theproduct-linearchitecture(Figure7.9onpage150).<br />
Bothcanbe<br />
specifiedusingmodeltransformations.<br />
Notethatwedidnotyetconsiderthedomainspecificinterfacemodules<br />
<strong>of</strong>theproduct-linearchitecture. However,thisonlyconstitutesaminor<br />
hurdlesincewecansimplyencapsulatetheexistingsourcecodebodiesfor<br />
eachbehavior(preservinginterfacefunctionality<strong>and</strong>behavior).<br />
7.10 Conclusions<strong>and</strong>FutureWork<br />
Inthischapterweformulatedthemigration<strong>of</strong>SMCsystemsasamodel<br />
transformationproblem. ThestartingpointisanSMCarchitecturebased<br />
onFSMs;theendpointisaproduct-lineSMCarchitecturebasedonTRSs.<br />
Ourapproachsupportsthegenericmigration<strong>of</strong>theproduct-linemembers.<br />
Wedemonstratedthatthedevelopmentframeworkforthe MDAcan<br />
besuccessfullyappliedinamigrationcontextaswell: migrationcanbe<br />
seenasaseries<strong>of</strong>modeltransformations. Weproposedagenerictwophased,model-drivenmigrationapproachthatusesdistinctnormalisation<br />
<strong>and</strong>transformationstepstoderivethemodulesrequiredtoinstantiatethe<br />
TRSproduct-linearchitectureforaparticular(sub)system.Thenormalisationstepiscrucialinovercomingsemi-formal,incomplete<strong>and</strong>ambiguous<br />
specificationsaswellastool<strong>and</strong>languagelimitations. Thisnormalisationsteprequiresdomainknowledge<strong>and</strong>manualeffort,butmakesour<br />
approachsuitedforindustrialapplication.<br />
Atrade-<strong>of</strong>fhasbeenidentifiedbetweentheinherentcomplexity<strong>of</strong>automatedtransformations<strong>and</strong>therequiredmanualeffortduringnormalisation.BasedonSMC-specificconcerns<strong>and</strong>anormalisedsourcemetamodel,<br />
wehavedefined<strong>and</strong>implementedaset<strong>of</strong>generictransformationrulesthat<br />
supportamigrationtowardsTRS-basedproduct-linearchitectures.Theapplicability<strong>of</strong>theseruleshasbeenillustratedforareal-worldindustrial<br />
case. Sinceourtransformationrulesoperateonnormalisations,theycan<br />
beappliedtoFSM-TRSmigrations<strong>of</strong>SMCsystemswithoutloss<strong>of</strong>generality.
166 Chapter7. <strong>Model</strong>-<strong>Driven</strong>Migration<br />
Theindustrialcasethatmotivatedthischapterimposesnotonlythe<br />
source<strong>and</strong>targetparadigmsbutplacespracticalconstraintsontheenablingtechnologiesaswell.<br />
StartingfromUML,weselectedtechnologies<br />
compatiblewiththe MDAtosetupaconvenienttool-chainthatsupports<br />
thedefinition<strong>and</strong>manipulation<strong>of</strong>models. Usingthistoolchain,several<br />
requestsfromdifferentSMCcomponentshavebeenmigratedasapro<strong>of</strong><strong>of</strong><br />
concept.Theexperienceswegainedfromthisexerciseindicatethattheapplication<strong>of</strong>modeltransformationsnotonlyincreasestheunderst<strong>and</strong>ability<br />
<strong>of</strong>suchamigration,butalsoreducestheneedfordomainexperts.<br />
Assuch,themaincontributions<strong>of</strong>thischapterare:<br />
•Theillustratedapplicability<strong>of</strong>theMDAapproachtoarchitecturemigrations.<br />
Tothisend,weintroducedavitalnormalisationstepthat<br />
enablesmigrationsinanindustrialsetting.<br />
•Apracticalviewontheuse<strong>of</strong>metamodels<strong>and</strong>pr<strong>of</strong>ilesformigrations<br />
ingeneral<strong>and</strong>,morespecifically,onthenormalisation,<strong>and</strong>transformation<strong>of</strong>SMCsourcemodels.<br />
•Thespecification<strong>of</strong>aset<strong>of</strong>modeltransformationrules,anSMCUML<br />
pr<strong>of</strong>ile,<strong>and</strong>aTRSmetamodelthatcanbeappliedtoFSM-TRSmigrations<strong>of</strong>SMCarchitectures.<br />
Weareintheprocess<strong>of</strong>extendingourworkalongthefollowinglines.<br />
First,wewantt<strong>of</strong>urtherinvestigatetheextraction<strong>of</strong>sourcemodelsfor<br />
ourtransformationdirectlyfromsourcecode. Thismayalsoenable(partial)formalisation<strong>and</strong>automation<strong>of</strong>ournormalisationstep.<br />
Second,at<br />
theotherend<strong>of</strong>themigration,wewanttoextendourapproachwithcode<br />
generationfromTRSmodelsfortheapplication-specificmodules<strong>of</strong>theTRS<br />
product-linearchitecture,againusingtechnologiesrelatedtotheMDA.This<br />
wouldprovideforafull-fledgedmodel-drivenmigrationapproach: from<br />
legacycodetonewcodethroughaseries<strong>of</strong>modeltransformations.
Chapter8<br />
Visualisation <strong>of</strong> Domain-Specific<br />
<strong>Model</strong>ling Languages Using UML 1<br />
Currently,general-purposemodellingtoolsare<strong>of</strong>tenonlyusedtodrawdiagramsforthepurpose<strong>of</strong>documentation.Theintroduction<strong>of</strong>model-driven<br />
s<strong>of</strong>twaredevelopmentapproachesinvolvesthedefinition<strong>of</strong>domain-specific<br />
modellinglanguagesthatallowcodegeneration. Althoughgraphicalrepresentations<strong>of</strong>theinvolvedmodelsareimportantfordocumentation,the<br />
development<strong>of</strong>requiredvisualisations<strong>and</strong>editorsiscumbersome. Inthis<br />
chapterweproposetoextendthetypicalmodel-drivenapproachwiththe<br />
automaticgeneration<strong>of</strong>diagramsfordocumentation. Weillustratethe<br />
approachusingthe<strong>Model</strong><strong>Driven</strong>Architectureinthedomains<strong>of</strong>s<strong>of</strong>tware<br />
architecture<strong>and</strong>controlsystems.<br />
8.1 Introduction<br />
<strong>Model</strong>-drivenengineeringreferstos<strong>of</strong>twaredevelopmentapproachesin<br />
whichmodelsareconsideredtheprimarydevelopmentartefacts[Bézivin,<br />
2005](instead<strong>of</strong>sourcecode). Intheseapproachess<strong>of</strong>twaremodelsare<br />
graduallytransformed(automatically)intosourcecodebymeans<strong>of</strong>model<br />
transformations.Additionally,suchmodelsareusedforother(automated)<br />
s<strong>of</strong>twareengineeringtasks,suchasperformanceanalysis.<br />
Typically, model-driven engineering (MDE) approaches are based on<br />
modellinglanguagesthat<strong>of</strong>ferabstractionsfocusedonaparticulardomain.<br />
Suchlanguagesarereferredtoasdomain-specificmodellinglanguages<br />
1 Thischapterwaspublishedearlieras:Graaf,Bas<strong>and</strong>ArievanDeursen. Visualisation<br />
<strong>of</strong>domain-specificmodellinglanguagesusingUML. InProceedings<strong>of</strong>the14 th Annual<br />
IEEEInternationalConference<strong>and</strong>WorkshopontheEngineering<strong>of</strong>ComputerBased<br />
Systems(ECBS2007),pages586–595.IEEEComputerSociety,2007c<br />
167
168 Chapter8. Visualisation<strong>of</strong>DSMLs<br />
(DSMLs). FromDSMLmodelscodeisgeneratedforaparticulars<strong>of</strong>tware<br />
platform. DSMLshavebeendevelopedforvarioustypes<strong>of</strong>domains,such<br />
ass<strong>of</strong>twareengineering(e.g.,s<strong>of</strong>twarearchitecture[Medvidovic<strong>and</strong>Taylor,1997])<strong>and</strong>applicationdomains(e.g.,insuranceproducts[Doyleetal.,<br />
2006]).<br />
In general, the use <strong>of</strong> DSMLs has clear advantages over the use <strong>of</strong><br />
general-purposelanguages(GPLs)[VanDeursen<strong>and</strong>Klint,1998].Morein<br />
particular,inthecontext<strong>of</strong>MDE,ourexperienceinindustrialcasestudies<br />
(seeChapters5<strong>and</strong>7)indicatesthattheuse<strong>of</strong>aGPL,suchastheUnified<br />
<strong>Model</strong>ingLanguage 1 (UML),leadsto(unnecessary)complexmodeltransformations,forinstancetogeneratecode.Assuch,theintroduction<strong>of</strong>MDE<br />
typicallyrequiresthedevelopment<strong>of</strong>DSMLs.<br />
Althoughmechanismsareavailabletodefine<strong>and</strong>implementtheabstractsyntax<strong>of</strong><br />
DSMLs,suchastheMetaObjectFacility 2 (MOF)<strong>and</strong>the<br />
Eclipse<strong>Model</strong>ingFramework 3 (EMF),notmuchsupportisavailableforthe<br />
definition<strong>of</strong>theirgraphicalnotation(concretesyntax). Asaresultdevelopment<strong>of</strong>adequategraphicaleditors<strong>and</strong>visualisationsrequiresconsiderableeffort.<br />
Forsomes<strong>of</strong>twareengineeringtasks,sucheditorsarenotrequired.For<br />
instance,developerscanuseatextualsyntaxforthecreation<strong>of</strong>models<br />
thatcansubsequentlybeprocessedbymodeltransformationtools. However,othertasks,suchasdocumentation,dorequiresomeform<strong>of</strong>graphical<br />
representation.Itisthisproblemthatmotivatesthischapter.<br />
Thebasicidea<strong>of</strong>thischapterissimple:whendevisinganewDSMLwe<br />
trytoleverageexistingvisualnotations<strong>and</strong>modellingtools. Wepropose<br />
toexp<strong>and</strong>thetypicalMDEprocessinwhichabstractmodelsaregradually<br />
transformedintocode,with(partial)generation<strong>of</strong>documentation.Tothis<br />
endwecombinetheuse<strong>of</strong>DSMLsforcodegeneration<strong>and</strong>otherautomated<br />
s<strong>of</strong>twareengineeringtasks,withtheuse<strong>of</strong>UMLfordocumentation.TheapproachusesmodeltransformationstospecifythemappingbetweenDSMLs<br />
<strong>and</strong> UML. Thediagramscorrespondingtotheresulting UMLmodels,as<br />
visualisedby<strong>of</strong>f-the-shelfUMLtools,areusedinthedocumentation. To<br />
investigatetheargumentsfor<strong>and</strong>againstthisidea,westudyhow<br />
•thisapproachworksforvariousarchitecturalviews;<br />
• UMLcanbeusedasthetargetlanguageforvisualisingtheseviews;<br />
<strong>and</strong><br />
•modeltransformationscanbeusedtospecify<strong>and</strong>automatethemapping.<br />
1 http://www.uml.org(June2007)<br />
2 http://www.omg.org/m<strong>of</strong>(June2007)<br />
3 http://www.eclipse.org/emf(June2007)
8.2. Background 169<br />
Inpractice,theextraeffortrequiredforthedevelopment<strong>of</strong>graphicaleditorscanhampertheintroduction<strong>of</strong>MDE.Considerthefollowingscenario.<br />
As<strong>of</strong>twaredevelopmentorganisationdecidestointroduceMDE.Currently,<br />
thedevelopersuseUML. However,asinmanyotherorganisations,they<br />
onlyuseUMLmodellingtoolsfordrawingdiagrams[Langeetal.,2006].<br />
Thesediagramsareimportantforthecommunicationwithotherstakeholders,astheyconstituteanessentialpart<strong>of</strong>thedocumentation.<br />
The<br />
introduction<strong>of</strong>MDEinvolvesthedefinition<strong>of</strong>DSMLsfromwhichcodewill<br />
begenerated. Furthermore,asthedevelopersarecomfortablewithusing<br />
atextualsyntaxfortheseDSMLs,nographicaleditorsaredeveloped.The<br />
resultisthattheynowhavetocreate DSMLmodelsforcodegeneration<br />
aswellasUMLdiagramsfordocumentation. Consideringthecurrentuse<br />
<strong>of</strong>UML,asinvestigatedbyLangeetal.[2006],<strong>and</strong>theupcoming<strong>of</strong>MDE<br />
approaches,suchasthe<strong>Model</strong><strong>Driven</strong>Architecture 1 (MDA),thisisnotan<br />
unlikelyscenario.<br />
Weinvestigatethefeasibility<strong>of</strong>ourapproachinthedomain<strong>of</strong>s<strong>of</strong>tware<br />
architecture.InSection8.2weintroducethelanguagesspecifictothisdomain,<strong>and</strong>thest<strong>and</strong>arddocumentationapproach.<br />
Ourapproachforthe<br />
model-drivendocumentation<strong>of</strong>s<strong>of</strong>twarearchitecture,MDAV,ispresented<br />
inSection8.3<strong>and</strong>wereportonasmallcasestudyinSection8.4.Theapproachiseasilyappliedtootherdomainsaswell.Anadditional(industrial)<br />
casestudyinvolvingadifferenttype<strong>of</strong>modelsispresentedinSection8.5.<br />
Wediscussthebenefits<strong>and</strong>limitations<strong>of</strong>theapproachinSection8.6.After<br />
discussingsomerelatedworkinSection8.7,weconcludewithanoverview<br />
<strong>of</strong>ourcontributions<strong>and</strong>opportunitiesforfutureworkinSection8.8.<br />
8.2 Background<br />
Inthissectionweintroducemodelling<strong>and</strong>documentationinthedomain<br />
<strong>of</strong>s<strong>of</strong>twarearchitecture.Furthermore,wediscusssome<strong>of</strong>thetechnologies<br />
thatenableourapproach.<br />
8.2.1 S<strong>of</strong>twareArchitecture<br />
<strong>Model</strong>ling Severalnotationshavebeendevelopedtospecifyarchitectural<br />
models. Thesearchitecturedescriptionlanguages(ADLs)(seeMedvidovic<br />
<strong>and</strong>Taylor[1997]foranoverview)mostlyconsideranarchitecturetobea<br />
configuration<strong>of</strong>runtimecomponents<strong>and</strong>connectors.<br />
Duetotheirformalsyntax<strong>and</strong>semanticsADLsenableautomaticcode<br />
generation<strong>and</strong>analysis. Despitethesebenefits,<strong>and</strong>althoughADLshave<br />
1 http://www.omg.org/mda(June2007)
170 Chapter8. Visualisation<strong>of</strong>DSMLs<br />
receivedmuchattentionfromthearchitectureresearchcommunity,they<br />
havenotbeenappliedmuchinindustry[Kruchtenetal.,2006].<br />
AlthoughUMLisaimedatobject-orientedmodelling,itallowspractitionerstoaddressawiderange<strong>of</strong>issues[Medvidovicetal.,2002].Therefore,<strong>and</strong>because<strong>of</strong>theavailability<strong>of</strong>supporting(graphical)modelling<br />
tools,itis<strong>of</strong>tenusedinpracticetodescribes<strong>of</strong>twarearchitectures(e.g.,see<br />
Chapter3<strong>and</strong>Langeetal.[2006]).<br />
Adrawback<strong>of</strong>using UMLforthispurposeisthesemanticmismatch<br />
betweenarchitecturalconcepts<strong>and</strong> UML’sconcepts,whichareaimedat<br />
object-orienteddesign.Thisresultsincompromisesbetweencompleteness<br />
<strong>and</strong>legibility[Garlanetal.,2002]. Furthermore,forautomaticprocessing<strong>of</strong>models(e.g.,forcodegeneration)thecomplexity<strong>of</strong>UMLresultsin<br />
complexmodeltransformations(seeChapters5<strong>and</strong>7).<br />
Documentation Becauseinindustrialpracticeas<strong>of</strong>twarearchitectureistoo<br />
complextodescribeinasinglestroke,differentviewsareusedforitsdocumentation.Differenttypes<strong>of</strong>viewshavebeendefinedtoaddressspecific<br />
concerns. Thetwomostprominentcategories<strong>of</strong>viewsaremoduleviews<br />
<strong>and</strong>component-<strong>and</strong>-connector(C&C)views[Clementsetal.,2002a].<br />
Amoduleviewaddressesthequestion<strong>of</strong>howasystemisdeveloped;it<br />
definesthemostimportantimplementationunits(modules)<strong>and</strong>theirrelations.Moduleviewsareused,forinstance,toevaluatethemaintainability<br />
<strong>of</strong>asystemasimpliedbyitsarchitecture.<br />
Acomponent-<strong>and</strong>-connector(C&C)view,ontheotherh<strong>and</strong>,addresses<br />
thequestion<strong>of</strong>howasystemworks. Itdescribesasysteminterms<strong>of</strong><br />
runtimecomponents<strong>and</strong>connectors. Acomponentisanabstraction<strong>of</strong>a<br />
computationalelement;aconnectorisanabstraction<strong>of</strong>thewaycomponentsinteract.Assuch,aC&Cviewismoresuitedforanalysis<strong>of</strong>runtime<br />
properties,suchasperformance.<br />
Morespecifictypes<strong>of</strong>viewsaredefinedbyimposingrestrictionsonthe<br />
type<strong>of</strong>elements<strong>and</strong>relationsallowedinaview.Inamodule-usesview,for<br />
instance,only‘uses’relationsareallowed.<br />
Intheterminology<strong>of</strong> IEEEStd1471-2000[IEEE-1471,2000],aview<br />
conformstoaviewpointthat“specifiestheconventionsforusing<strong>and</strong>constructingaview”.Aviewpointaddressesaset<strong>of</strong>stakeholderconcerns.A<br />
number<strong>of</strong>viewpointsetsisavailablefromliterature,suchas[Clements<br />
etal.,2002a].Furthermore,inpracticealsocustomviewpointsaredefined.<br />
Typically,aviewpointdefinitionprescribesamodellinglanguageornotationthatenablesthespecification<strong>of</strong>anarchitecturalmodelthataddresses<br />
theconcerns<strong>of</strong>theviewpoint.Asanexample,aC&Cviewpointmightrefer<br />
toaparticularADL.Insummary,aviewpointdefinesatype<strong>of</strong>views<strong>and</strong>a<br />
viewisaparticularrepresentation<strong>of</strong>aparticularsystem.
8.2. Background 171<br />
Inpracticethearchitecturalmodelforaviewisprimarilyusedasafigureordiagram(theview’sprimarypresentation[Clementsetal.,2002a])in<br />
adocumentthatdescribestheview.Because<strong>of</strong>theirwide-acceptance<strong>and</strong><br />
availabletoolsupport<strong>of</strong>tenUMLdiagramsareusedforthis(seeChapter3).<br />
8.2.2 EnablingMDETechnologies<br />
Ourapproachformodel-drivendocumentationisbasedonmodeltransformations.Thisrequirescapabilitiesfor(meta)modelling,modeltransformation,<strong>and</strong>modelinterchange.<br />
Forthedefinition<strong>of</strong>metamodelsweusetheMetaObjectFacility 1 (MOF)<br />
<strong>and</strong>itsimplementationasanEclipseplugin:theEclipse<strong>Model</strong>ingFramework<br />
2 (EMF).<br />
TheEMFplugingeneratesanimplementationforametamodelasaset<br />
<strong>of</strong>Javaclassesthat<strong>of</strong>fersaninterfacethatallowsdeveloperstomanipulateconformingmodels.<br />
Thesemodelscanbeserialisedtoadocument<br />
intheExtensibleMarkupLanguage 3 (XML)using XMLMetadataInterchange<br />
4 (XMI). Additionally,asimpletree-basededitorisgeneratedthat<br />
canbeusedasanEclipsepluginforthecreation<strong>and</strong>inspection<strong>of</strong>associatedmodels.<br />
Asanexampleconsiderthescreenshot<strong>of</strong>suchaneditorin<br />
Figure8.3(b)onpage175.Thiseditorisalsocapable<strong>of</strong>validatingamodel<br />
againstitsmetamodel.<br />
TheAtlasTransformationLanguage[Jouault<strong>and</strong>Kurtev,2005](ATL)is<br />
basedonEMF.Weuseittodefinemodeltransformationsthatareexecuted<br />
byatransformationengine. InATL,transformationsaredefinedinmodulesthatconsist<strong>of</strong>declarativetransformationrules<strong>and</strong>helperoperations.<br />
Usingasyntaxsimilartothat<strong>of</strong>theObjectConstraintLanguage 5 (OCL),<br />
thetransformationrulesmatchmodelelementsinasourcemodel<strong>and</strong>createelementsinatargetmodel.<br />
Ahelperisdefinedinthecontext<strong>of</strong>a<br />
metamodelelement,towhichiteffectivelyaddsafeature.<br />
Fortheirinput,modeltransformationtoolstypicallyuseXMIserialisations<strong>of</strong>MOF-based(meta)models.<br />
Inthecase<strong>of</strong>UML,thesemodelscan<br />
simplybecreated<strong>and</strong>visualisedusingst<strong>and</strong>ardUMLtooling.<br />
1 http://www.omg.org/m<strong>of</strong>(June2007)<br />
2 http://www.eclipse.org/emf(June2007)<br />
3 http://www.w3.org/XML(June2007)<br />
4 http://www.omg.org/mda/specs.htm#XMI(June2007)<br />
5 http://www.omg.org/technology/documents/modeling_spec_catalog.htm#OCL(June2007)
172 Chapter8. Visualisation<strong>of</strong>DSMLs<br />
Metamodel<br />
<strong>Model</strong><br />
*<br />
conformsTo<br />
used for:<br />
analysis<br />
code generation<br />
model transformations<br />
Concern<br />
* *<br />
*<br />
UML <strong>Model</strong><br />
*<br />
UML Diagram<br />
Architectural Description<br />
Architecture<br />
System<br />
Figure 8.1:MDAVframework<br />
8.3 <strong>Model</strong>-<strong>Driven</strong>ArchitecturalViews<br />
*<br />
Viewpoint<br />
View<br />
used for:<br />
documentation<br />
communication<br />
assessments<br />
*<br />
conformsTo<br />
Totakeadvantage<strong>of</strong>thepower<strong>of</strong> DSMLsforcodegeneration<strong>and</strong>other<br />
automateds<strong>of</strong>twareengineeringtasks<strong>and</strong>that<strong>of</strong> UMLfordocumentation,weexplicitlydistinguisharchitecturaldocumentation<strong>and</strong>architecturalmodels.Wemakethisconcretebyrevisitingtheconceptualmodel<strong>of</strong><br />
theindustryst<strong>and</strong>ardfordescription<strong>of</strong>s<strong>of</strong>twarearchitectures(IEEEStd<br />
1471-2000[IEEE-1471,2000]).Theresult,the<strong>Model</strong>-<strong>Driven</strong>Architectural<br />
Views(MDAV)framework,isdisplayedinFigure8.1.<br />
8.3.1 MDAVFramework<br />
InFigure8.1,forthedevelopment<strong>of</strong>as<strong>of</strong>tware System,an Architectureis<br />
definedthatincludesthemostimportantdesigndecisions.Thesearemade<br />
concreteinan Architectural Descriptionthatconsists<strong>of</strong> <strong>Model</strong>sontheoneh<strong>and</strong>,<br />
<strong>and</strong>architectural Viewsontheother.Inthespirit<strong>of</strong>MDE,modelsconform<br />
toaMetamodel<strong>and</strong>areusedforseveral(automated)taskssuchas,analysis<strong>and</strong>codegeneration.<br />
Viewsontheotherh<strong>and</strong>conformtoaViewpoint<br />
<strong>and</strong>areprimarilyusedforcommunicationpurposes.Bothmetamodels<strong>and</strong><br />
viewpointsaredevelopedtoaddressacertainset<strong>of</strong> Concerns.Aviewpoint<br />
prescribesthelanguagetobeusedtomodelthearchitecture.Ametamodel<br />
specifiestheabstractsyntax<strong>of</strong>thislanguage.Aviewincludesdiagramsin<br />
itsprimarypresentationthatrepresenttheassociatedarchitecturalmodels.
8.3. <strong>Model</strong>-<strong>Driven</strong>ArchitecturalViews 173<br />
Toallowtheuse<strong>of</strong>customdefinedDSMLswithouttheneedtospecifically<br />
developcorrespondinggraphicalrepresentations<strong>and</strong>editors,weuse UML<br />
Diagrams.Tothisend,wemapDSML <strong>Model</strong>sto UML <strong>Model</strong>sthatarevisualised<br />
asUMLdiagramsforinclusioninviewdocumentationwithst<strong>and</strong>ardUML<br />
tooling.Thus,inMDAVtheconnectionbetweenviews<strong>and</strong>modelsismade<br />
through(UML)diagrams.Thankstothisconnection,viewscanbe(partly)<br />
generatedfromthesamemodelsasthesourcecode;theybecomemodel<br />
driven.<br />
8.3.2 MDAVProcess<br />
Insummary,comparedtotheconceptualmodelasdescribedbyIEEEStd<br />
1471-2000,weaddtheconcept<strong>of</strong>adiagramthatallowstorelateaviewto<br />
amodel.Furthermore,in-linewithMDE,weexplicitlyaddedametamodel<br />
asadescription<strong>of</strong>themodellinglanguageusedinaview. Application<strong>of</strong><br />
thecorrespondingapproachinvolvesthreesteps:definition<strong>of</strong>1)asuitable<br />
metamodel,2)meanstocreatecorrespondingmodels,<strong>and</strong>3)amappingto<br />
UML.<br />
Asuitablemetamodelforaparticularviewpointcanbedefinedfrom<br />
scratchorbasedonanexistingADLthataddressestherelevantconcern.In<br />
theformercase,weuseadescription<strong>of</strong>theviewpoint(e.g.,fromClements<br />
etal.[2002a])<strong>and</strong>createcorrespondingelements<strong>and</strong>relationsinthemetamodel.Inthelattercase,webasethemetamodelontheADL’sgrammar(or<br />
otherlanguagespecificationmechanism). Giventhetypicallymodestsize<br />
<strong>and</strong>simplesyntax<strong>of</strong> ADLs<strong>and</strong>usingappropriatetooling,corresponding<br />
metamodelsareeasilycreated.<br />
Ameanstocreatemodelsassociatedwiththedefinedmetamodelisalso<br />
required.Dependingonthecomplexity<strong>of</strong>theassociatedmetamodeldifferentalternativesaresuitable,<strong>of</strong>whichwegiveexamplesinSection8.4.Wespecify<strong>and</strong>implementthemappingbetweentheprescribedmetamodel<strong>and</strong>UMLusingamodeltransformationlanguage.ForseveralADLsmappingstoUMLalreadyexist,thatwecanspecifyasmodeltransformations.<br />
Thisallowsustoautomaticallytransformanarchitectural(ADL)<br />
modeltoaUML <strong>Model</strong>. Assuch, ADL <strong>Model</strong>s<strong>and</strong> UML Diagramscanevolve<br />
simultaneously.<br />
AlthoughthecorrespondingUMLdiagrammightnotexactlyrepresent<br />
thearchitecturalmodel(e.g.,becausethelatterusesconceptsthatdonot<br />
correspondtoanyUMLconcept),itistypicallycompleteenoughformany<br />
communicationpurposes. Thiscanbeconcludedbyconsideringthewidespreaduse<strong>of</strong>UMLforarchitecturaldocumentationinindustrialpractice<br />
(e.g.,seeChapter3<strong>and</strong>Langeetal.[2006]). Moreover,inthecase<strong>of</strong>a<br />
semanticmismatch,weusestereotypestoindicatethetype<strong>of</strong>ADLelement<br />
aspecificUMLelementrepresents.
174 Chapter8. Visualisation<strong>of</strong>DSMLs<br />
Figure 8.2:C&Cmodel<strong>of</strong>CaPiTaLiZe(ACME)<br />
8.4 UsingMDAVtoGenerateViews<br />
WeappliedMDAVtotwoarchitecturalviewpoints:wedefinedanappropriatemetamodel(i.e.,amodelling‘language’),meanstocreate<strong>and</strong>manipulateassociatedmodels,<strong>and</strong>amappingtoUML,<br />
WeusetheCaPiTaLiZesystem, <strong>of</strong>tenusedins<strong>of</strong>twarearchitecture<br />
literature[Allen<strong>and</strong>Garlan,1997],asarunningexample. CaPiTaLiZe<br />
transformsacharacterstreambycapitalisingalternatecharacters.AC&C<br />
model<strong>of</strong>CaPiTaLiZedefinedusinganADL(ACME[Garlanetal.,2000])is<br />
visualisedinFigure8.2. CaPiTaLiZeisdesignedasapipe-<strong>and</strong>-filtersystem,withseparatecomponentsforsplittingastream<strong>of</strong>charactersintwo<br />
streams(split),(un)capitalisingcharacters(upper, lower),<strong>and</strong>mergingtwo<br />
streams<strong>of</strong>characters(merge).<br />
Thediagram<strong>of</strong>CaPiTaLiZe’smoduleviewisdepictedinFigure8.3(c)<br />
. In this UML class diagram we represent architectural modules with<br />
UMLPackages<strong>and</strong>use-relationswith UMLDependencies, assuggested<br />
byClementsetal.[2002a].<br />
8.4.1 Module-UsesView<br />
Metamodel Module-usesviewsarebasedonaspecialtype<strong>of</strong>dependency<br />
relation:theusesrelation. Assuch,theseviewsonlycontainonetype<strong>of</strong><br />
element<strong>and</strong>onetype<strong>of</strong>relation[Clementsetal.,2002a].<br />
Although UMLiswell-suited<strong>and</strong>thereforealsotypicallyusedinthe<br />
primary presentation <strong>of</strong> module views, we developed a small custom<br />
metamodeltoillustrateMDAV. ThisMADLmetamodelisspecifiedinFigure8.3(a)<br />
usingtheMOF.InadditiontoaModuleelement<strong>and</strong> userelation<br />
itdefinesan Implementationtoconsist<strong>of</strong>aset<strong>of</strong>modulesthatmay use<br />
othermodules.NotethatthismetamodelisdifferentthantheMADLmetamodelinFigure6.6(b)onpage113.Althoughbothareusedtoaddressthe<br />
sameconcerns,theirpurposeisdifferent(documentationvs.conformance<br />
checking). Forthatreason,theuse-relationismodelledbythelatterasa<br />
first-classmodellingelement(toallowspecifyingitsconformance).
8.4. UsingMDAVtoGenerateViews 175<br />
System<br />
−name :String<br />
+ modules<br />
(a)MADLmetamodel<br />
*<br />
Module<br />
−name :String<br />
+ use<br />
*<br />
(b)MADLmodel<strong>of</strong>CaPiTaLiZeinEMFeditor<br />
Driver<br />
Split Upper Lower<br />
Merge<br />
Config IOlib<br />
(c)MADLdiagram(UML)<br />
Figure 8.3:MADL
176 Chapter8. Visualisation<strong>of</strong>DSMLs<br />
rule Package {<br />
from m:MADL!Module<br />
to p:UML!Package (<br />
name
8.4. UsingMDAVtoGenerateViews 177<br />
8.4.2 Component-<strong>and</strong>-ConnectorView<br />
Metamodel ForC&Cviews,wedefineametamodelforasimpleADLsimilar<br />
toACME[Garlanetal.,2000],anADLinterchangelanguagethatcoversthe<br />
mostconstructsinawiderange<strong>of</strong>ADLs.<br />
ConsiderthemetamodelfortheADL(CCADL)inFigure8.4(a)onthefollowingpage.UsingCCADLthearchitecture<strong>of</strong>aSystemconsists<strong>of</strong>aStyle,a<br />
set<strong>of</strong> Components,<strong>and</strong>aset<strong>of</strong> Connectors.Acomponentownsaset<strong>of</strong> Ports<br />
viawhichitinteractswithitsenvironment.Similarlyaconnectorownsa<br />
set<strong>of</strong> Rolesthatdefinewhatbehaviourisexpectedfromtheparticipants<br />
intheinteractiontheconnectorrepresents.Byattachingconformingroles<br />
<strong>and</strong>ports,configurations<strong>of</strong>components<strong>and</strong>connectorscanbecreated.Finally,thestyledefinesthetypes<strong>of</strong>components(ComponentType),connectors<br />
(ConnectorType),roles(RoleType),<strong>and</strong>ports(PortType). Themaindifference<br />
withthe CPADLmetamodeldepictedinFigure6.6(a)onpage113isthat<br />
component,connector,role,<strong>and</strong>porttypesaredefinedonthemodellevel<br />
instead<strong>of</strong>onthemetamodellevel.<br />
<strong>Model</strong>creation Again,astraightforwardapproachtocreateCCADLmodels<br />
istousetheeditorgeneratedbyEMF.Figure8.4(b)onthefollowingpage<br />
displaysascreenshot<strong>of</strong>thiseditor,whileeditingtheCaPiTaLiZeCCADL<br />
model. Whenconsideringthecomplexity<strong>of</strong>the CCADLmetamodel(comparedtotheMADLmetamodel),itbecomesclearthateditingmodelsusing<br />
thiseditorisinconvenient.Usingthiseditoritisnotpossible,forinstance,<br />
toimmediatelydeterminethecomponent<strong>and</strong>connectortypes<strong>and</strong>underst<strong>and</strong>theirconfiguration.<br />
Asanalternative, weproposetouseasimple XMLDocumentType<br />
Definition(DTD)orschemathatallowstodescribeassociatedmodelsas<br />
simpleaspossible. Afragment<strong>of</strong>anXMLdocumentconformingtosucha<br />
DTDdescribingthesameCaPiTaLiZesystemisdepictedinListing8.2on<br />
page179. NotethattheDTDwedefinedallowstoseparatelyspecifythe<br />
configuration<strong>of</strong>components<strong>and</strong>connectorsasaset<strong>of</strong>attachments.<br />
IfweusesimpleXMLdocumentstospecifysystemsinCCADL,weseparatelyneedtopopulateamodelconformingtotheCCADLmetamodel.Severalapproachescanbeusedtopopulateamodel.<br />
Onepossibilityistodevelopaso-calledinjector,aprogramthatparses<br />
afile<strong>and</strong>usestheapplicationprogramminginterface(API)generatedby<br />
EMFtoinstantiateacorrespondingmodel. Ingeneral,aninjectorisused<br />
tobridgetwodifferentdomains,inthiscasetheXML<strong>and</strong>modelware(MOF)<br />
domains.Inthecontext<strong>of</strong>MDEsuchdomainsarealsoreferredtoasTechnologicalSpaces[Kurtevetal.,2002].
178 Chapter8. Visualisation<strong>of</strong>DSMLs<br />
RoleType<br />
−name :String<br />
+ roleTypes<br />
System<br />
−name :String<br />
+ portTypes * * + componentTypes<br />
PortType<br />
ComponentType<br />
−name :String<br />
*<br />
Style<br />
−name :String<br />
ConnectorType<br />
−name :String<br />
*<br />
+ connectorTypes<br />
+ style<br />
−name :String<br />
+ type<br />
+ type<br />
(a)CCADLmetamodel<br />
(b)CCADLmodel<strong>of</strong>CaPiTaLiZein<br />
EMFeditor<br />
Figure 8.4:CCADL<br />
*<br />
+ connectors<br />
+ components<br />
*<br />
><br />
upper<br />
Connector<br />
−name :String<br />
*<br />
Role<br />
−name :String<br />
0..1<br />
Port<br />
−name :String<br />
+ ports *<br />
+ roles<br />
+ role 0..1<br />
+ port<br />
Component<br />
−name :String<br />
input<br />
><br />
split<br />
> ><br />
><br />
><br />
merge<br />
output<br />
><br />
lower<br />
(c)CCADLdiagram<br />
(UML)<br />
>
8.4. UsingMDAVtoGenerateViews 179<br />
...<br />
<br />
<br />
<br />
<br />
...<br />
<br />
<br />
<br />
<br />
<br />
...<br />
<br />
<br />
<br />
<br />
...<br />
<br />
<br />
...<br />
<br />
<br />
Listing 8.2:C&Cmodel<strong>of</strong>CaPiTaLiZe(XML)<br />
Asanalternative,wereusetheXMLinjector,<strong>and</strong>XMLmetamodel(see<br />
Figure8.5onthefollowingpage)providedbytheATLproject 1 . Basedon<br />
anXMLdocumentthisinjectorinstantiatesamodelthatconformstothe<br />
XMLmetamodel.Subsequently,wetransformthismodelintoamodelthat<br />
conformstotheCCADLmetamodelusingATLmodeltransformations.The<br />
latterapproachrequiresthesmallesteffortbecauseitreusesexistinginjectors<strong>and</strong>metamodels,<strong>and</strong>onlyrequiresustospecifyatransformation<br />
thatmapstheXMLmetamodeltoourCCADLmetamodel.<br />
ThetransformationtoinstantiateaCCADLmodelbasedonan(injected)<br />
XMLsourcemodelisstraightforward. Listing8.3onthenextpagecontainsafragment<strong>of</strong>thistransformation.TherulematchesallXMLelements<br />
named ’Component’.ForeachitcreatesaComponentintheCCADLmodel.<br />
The type<strong>and</strong> namefeaturesareinitialisedusingtwohelpers, getType<strong>and</strong><br />
getName.TheynavigatetheXMLmodeltoextractthedesiredinformation.<br />
Forthe typefeaturethisisanotherXMLElementthat,inturn,matches<br />
arulethatcreatesComponentTypes. Theotherelements<strong>of</strong>the CCADL<br />
metamodelareinstantiatedbysimilarrules.<br />
1 http://www.eclipse.org/m2m/atl(June2007)
180 Chapter8. Visualisation<strong>of</strong>DSMLs<br />
Node<br />
−name :String<br />
−value :String<br />
+ children<br />
+ parent<br />
Attribute Text Element<br />
*<br />
Root<br />
Figure 8.5:XMLmetamodel<br />
rule Component {<br />
from el:XML!Element(<br />
el.name=’Component’)<br />
to c:CCADL!Component(<br />
type
8.5. IndustrialApplication 181<br />
rule Association {<br />
from conn:CCADL!Connector<br />
to asoc:UML!Association(<br />
name
182 Chapter8. Visualisation<strong>of</strong>DSMLs<br />
basedonamodel<strong>of</strong>anSMCsysteminterms<strong>of</strong>tasks<strong>and</strong>resources. The<br />
associatedmetamodelisshowninFigure8.6(a)onpage184.<br />
Task-resourcemodelsconsist<strong>of</strong>astatic<strong>and</strong>adynamicpart.Thestatic<br />
partmodelsthecontrolled Systembyspecifyingthe Behaviours(manufacturingactivities)itcanperform,the<br />
Capabilitiesthisrequires,<strong>and</strong>the Resources<br />
(subsystems)itcontrolsto<strong>of</strong>ferthosecapabilities.Thedynamicpartmodelsthemanufacturingrequeststhecomponentcanperforminterms<strong>of</strong><br />
(simple,conditional,orcompound) Tasksthatare<strong>of</strong>aspecificBehaviour.<br />
Precedencerelationsbetweentasksareusedtospecifyrestrictionsonexecutionorder.<br />
Basedonthemetamodel,toolscanbedevelopedforthegeneration<strong>of</strong><br />
sourcecode,modelvalidation,<strong>and</strong>others<strong>of</strong>twareengineeringtasksthat<br />
canbeautomated.Weusedit,forinstance,asthetarget<strong>of</strong>amodeltransformationthatautomatesthemigration<strong>of</strong>SMCcomponentsfromastatebasedtoatask-resource-basedarchitecture(seeChapter7).<br />
<strong>Model</strong>creation Inthiscase,task-resourcemodelswereobtainedbytheautomaticmigration<strong>of</strong>legacySMCmodels(basedonstatemachines)tomodelsbasedonthetask-resourcearchitecture.<br />
Assuch,ameanstocreate<br />
task-resourcemodelsdirectlywasnotyetrequired.WhenSMCsystemsare<br />
developedbasedonthetask-resourceapproachfromscratch,suchmeans<br />
wouldberequired. Inthatcase,one<strong>of</strong>thealternativespresentedinthe<br />
previoussectioncanbeused.<br />
Anexample<strong>of</strong>ageneratedtask-resourcemodel(asresult<strong>of</strong>theautomated<br />
migration) inspected using the EMF editor is depicted in Figure8.6(b)onpage184.Thiseditorwasgeneratedbasedonthemetamodel<br />
wedefined(Figure8.6(a)onpage184).Apartfromthiseditortherewasno<br />
(moreadvanced)editoravailableforthesemodels.<br />
UMLmapping Forthedocumentation<strong>of</strong> SMCsystemsbasedonthetaskresourcearchitecturewedefinedaviewpoint.Duetothelack<strong>of</strong>aconvenienteditortovisualisetask-resourcemodels<strong>and</strong>totakeadvantage<strong>of</strong>availabletooling<strong>and</strong>experience,theviewpointprescribesthatsuchmodelsaredepictedusingUMLdiagrams.Assuch,thealignment<strong>of</strong>thetaskresourceviewdocumentationwiththetask-resourcemodelsfromwhich<br />
codecanbegenerated,involvedamapping<strong>of</strong>thecorrespondingmetamodel<br />
toUML.<br />
Forthedocumentation<strong>of</strong>aconformingview, separatediagramsare<br />
usedforthestaticpart<strong>and</strong>foreach<strong>of</strong>thepossiblerequests<strong>of</strong>thedynamicpart.Fortheformer,aUMLClassDiagramisusedinwhichaClass<br />
withappropriateStereotypeisusedtorepresentaBehaviour,Capability,<br />
orResource. Forthelatter,UMLActivityDiagrams(oneforeachrequest)
8.5. IndustrialApplication 183<br />
rule ActionState {<br />
from st:TRS!SimpleTask<br />
to state:UML!ActionState (<br />
name
184 Chapter8. Visualisation<strong>of</strong>DSMLs<br />
+ capability<br />
CapabilityUsage<br />
+ beginState :EInt<br />
+ endState :EInt<br />
+ requires<br />
Resource<br />
+ name :EString<br />
+ fulfils<br />
Capability<br />
+ name :EString<br />
*<br />
Behaviour<br />
+ name :EString<br />
*<br />
+ resources<br />
*<br />
+ capabilities<br />
1..*<br />
+ behaviours<br />
+ behaviour<br />
SystemDefinition<br />
+ requests<br />
+ id :EString<br />
*<br />
+ tasks<br />
+ iftrue<br />
AndTask<br />
Request<br />
+ name :EString<br />
OrTask<br />
+ condition :EString<br />
Static Dynamic<br />
1..*<br />
+ predecessors<br />
*<br />
+ tasks<br />
1..* + iffalse<br />
Task<br />
SimpleTask<br />
Created with Poseidon for UML Community Edition. Not for Commercial Use.<br />
(a)Task-resourcemetamodel<br />
(b)Task-resourcemodel<br />
check RCB comm.<br />
<br />
transfer W2U<br />
[combined_load]<br />
<br />
move UR to rotate<br />
check RCB comm.<br />
report done<br />
[not(combined_load)]<br />
<br />
finish exchange<br />
(c)Task-resourcediagram(UML)<br />
Figure 8.6:Task-resourcemetamodel,model,<strong>and</strong>UMLrepresentation
8.6. Discussion 185<br />
8.6 Discussion<br />
Ourapproachhasseveralbenefits. Itreducestheeffortrequiredforthe<br />
introduction<strong>of</strong>MDEapproachesbycircumventingtheneedtospecifically<br />
developgraphicaleditorsforthevisualisation<strong>of</strong>DSMLmodels. FurthermoreitallowstointroduceanMDEapproachgradually;UMLdiagramscan<br />
continuetobeusedfordocumentationpurposes. Assuch,inthecase<strong>of</strong><br />
s<strong>of</strong>twarearchitecture,itfacilitatestheintegration<strong>of</strong>ADLs<strong>and</strong>supporting<br />
toolsinindustrialdevelopmentprocesses.<br />
AspresentedheretheapproachusesMDAtechnologyformodeltransformations<strong>and</strong>metamodelling.Theunderlyingideasareapplicabletoother<br />
MDEapproachesaswell:eitherbyusingtheavailabletransformation<strong>and</strong><br />
metamodellingtechnologiesforthatMDEapproach,orbyimplementinga<br />
bridgetoMDA.Wegaveanexample<strong>of</strong>thelatterinSection8.4.2forXML.<br />
Ofcourse,thediagramsthataregeneratedautomaticallyusingourapproach,onlyconstituteaminorpart<strong>of</strong>thecompletedocumentation.Architecturalviews,forinstance,typicallyalsodocument(some<strong>of</strong>)therationale<strong>and</strong>trade-<strong>of</strong>fsthatunderliedesigndecisions[Clementsetal.,2002a].<br />
Infact,anarchitecturalviewcanbeseenas‘diagrams+explainingtext’.<br />
Althoughthe‘explainingtext’isnotautomaticallyupdatedusingourapproach,itdoesprovideastartingpointfordoingso(i.e.,thenewlygenerateddiagram).<br />
WhetheramappingtoUMLisfeasible,dependsonthetype<strong>of</strong>models<br />
involved<strong>and</strong>thedocumentationrequirements.Apotentialrisk<strong>of</strong>ouruse<br />
<strong>of</strong> UML,isthatthe UMLsemanticsmightnotmatchwiththesemantics<br />
<strong>of</strong>therepresented(DSML)modelelements,resultinginambiguities. In<br />
thesecasesappropriatestereotypesshouldbeintroduced.Asanexample,<br />
considerthestereotypesinFigure8.4(c)onpage178. Thesestereotypes<br />
areincludedintheATLmappingswedefined.<br />
Inthecasethatthesemanticgapbetweentheinvolvedmetamodel<strong>and</strong><br />
UMListoolargetobesolvedwithstereotypes,instead<strong>of</strong>UML,moregeneric<br />
graphlanguagessuchasdot 1 <strong>and</strong>GXL 2 couldbeusedastarget<strong>of</strong>themapping.<br />
Theeffortrequiredforspecification<strong>of</strong>themappingstoUMLismainly<br />
determinedbythecomplexity<strong>and</strong>size<strong>of</strong>theDSMLmetamodel.Typically,<br />
thesearerelativelysmall(e.g.,comparedtoUML).Furthermore,suchmappingscanbeeitherspecificallydeveloped(asinthecase<strong>of</strong>task-resource<br />
models)orreused(asinthecase<strong>of</strong>ADLs).Inthelattercasetheyonlyneed<br />
tobespecifiedasamodeltransformation.<br />
1 dot-LanguageusedbyGraphviz(GraphVisualisationS<strong>of</strong>tware),seehttp://www.<br />
graphviz.org(June2007)<br />
2 GXL-GrapheXchangeLanguage,seehttp://www.gupro.de/GXL(June2007)
186 Chapter8. Visualisation<strong>of</strong>DSMLs<br />
Ourapproachfocusesonvisualisation<strong>of</strong>DSMLmodels.Itdoesnot<strong>of</strong>fer<br />
visualeditingformodelsconformingtocomplexmetamodels. Whenthat<br />
isrequired,editorshavetobedevelopedspecifically.Technologytopartly<br />
generatesucheditorsisprovidedintheEclipseGraphicalEditingFramework<br />
1 (GMF)usingEMF. Basedonthespecification<strong>of</strong>aconcretesyntax<br />
<strong>and</strong>theabstractsyntaxspecifiedbyametamodelthisplugincangenerateaneditor.However,inthecasethatonlyvisualisationisrequired,our<br />
approach<strong>of</strong>fersalightweightalternative.<br />
Anotheralternativeistosimplymanuallycreatedocumentationinstead<br />
<strong>of</strong>automaticallyasinourapproach.Inthatcasethediagramscorrespondingtosomes<strong>of</strong>twaremodelsarecreated(drawn)manuallyusingmodelling<br />
ormoregenerictools. Obviously,consistencybecomesanissuewithsuch<br />
anapproach.<br />
8.7 RelatedWork<br />
Fondement<strong>and</strong>Baar[2005]presentanapproachtospecify(graphical)concretesyntaxbyextendingmetamodels.Basedonthisapproachtoolscould<br />
bedevelopedto(partly)generatecorrespondingeditors. Instead,wetake<br />
advantage<strong>of</strong>existingUMLtools.<br />
Medvidovicetal.[2002]investigatetheuse<strong>of</strong> UMLinthedomain<strong>of</strong><br />
s<strong>of</strong>twarearchitecture. Moreinparticular,theyinvestigatehowmodelling<br />
constructsusedinADLs(i.e.,atype<strong>of</strong>DSML)canberepresentedusingUML.<br />
TheyconsidertwoapproachesforusingUMLtomodels<strong>of</strong>twarearchitectures:(1)useUML‘as-is’,<strong>and</strong>(2)useUML’sextensionmechanisms.<br />
They<br />
concludethatUMLhasanumber<strong>of</strong>limitationswhenusedtomodels<strong>of</strong>twarearchitectures.<br />
Thelack<strong>of</strong>architecturalmodellingconstructsmakes<br />
itnecessarytoadoptspecificinterpretations<strong>of</strong>UMLmodelelementsorto<br />
relyonOCLtoconstraintheuse<strong>of</strong>modelconstructs. Inthischapterwe<br />
investigatedathirdstrategythatisbasedonthedefinition<strong>of</strong>metamodels<br />
forADLs<strong>and</strong>theirmappingtoUMLusingmodeltransformations.<br />
FivestrategiesforrepresentingarchitecturalstructureinUMLaredescribedbyGarlanetal.[2002].Theyconcludethatthereisnosinglebest<br />
waytodothis. Furthermore,theyidentifyatrade-<strong>of</strong>fbetweencompleteness<strong>and</strong>legibility:strategiesthatassigndifferentUMLmodelelementsfor<br />
eachADLconstruct(completeness)tendtobeveryverbose<strong>and</strong>hencepoorly<br />
readable(legibility).One<strong>of</strong>theirrecommendationstosolvethis,istocontinuetouseADLsbuttoprovidemappingstoobject-orientednotations.Inthecurrentchapterwespecifiedsuchmappingsusingmodeltransformations,whichmakesthemautomated.<br />
1 http://www.eclipse.org/gmf(June2007)
8.8. ConcludingRemarks 187<br />
WhereweproposetouseMOFforthedefinition<strong>of</strong>DSMLs,Dash<strong>of</strong>yetal.<br />
[2005]useXMLforthedefinition<strong>of</strong>ADLs. Itprovidesgenerichigh-level<br />
XMLschemasthatcanbeextendedfordevelopment<strong>of</strong>ADLs.Theyleverage<br />
theavailabletoolsupportforXML. AsweuseMOF,weleverageavailable<br />
UML<strong>and</strong>MOFtoolsaswell.Thisenables,forinstance,thespecification<strong>of</strong><br />
transformationsonahigherlevel<strong>of</strong>abstractionbyamodeltransformation<br />
language.<br />
8.8 ConcludingRemarks<br />
InthischapterweproposedtocombineDSMLmodels<strong>and</strong>UMLdiagrams<br />
formodel-drivens<strong>of</strong>twaredocumentation.WhereMDEapproachestypically<br />
aimtouseDSMLmodelstoautomaticallycreatesourcecode,ourapproach<br />
complementsMDEwiththe(partial)creation<strong>of</strong>documentation.<br />
Themainmotivationforourapproachistheobservationthatalthough<br />
DSMLshaveclearadvantagesovergeneral-purposemodellinglanguages,<br />
itrequiresconsiderableefforttodevelopgraphicaleditors<strong>and</strong>representations.Inparticular,thedefinition<strong>and</strong>implementation<strong>of</strong>theirconcretesyntaxornotationismuchmoreinvolvedthanthat<strong>of</strong>theirabstractsyntax,whichissupportedbytechnologies,suchasMOF<strong>and</strong>EMF.<br />
Thisisa<br />
problem,asgraphicalrepresentations<strong>of</strong>modelsareanessentialpart<strong>of</strong><br />
s<strong>of</strong>twaredocumentation.<br />
Ourapproachusesmodeltransformationsto(automatically)mapDSML<br />
modelstoUMLmodels.TheseUMLmodelsareeasilyvisualisedasUMLdiagramsusingavailablemodellingtools.WhiletheDSMLmodelscanbeused<br />
forcodegeneration<strong>and</strong>otherautomateds<strong>of</strong>twareengineeringtasks,these<br />
diagramsareusedinthedocumentation.Assuch,ourapproachallowsto<br />
optimisebothcompleteness(bytheADLmodel)<strong>and</strong>legibility(bytheUML<br />
diagram)<strong>of</strong>architecturedescriptions. Furthermore,part<strong>of</strong>thedocumentationcanbeautomaticallyupdatedasthes<strong>of</strong>twaresystemevolves.<br />
Application<strong>of</strong>ourapproachrequiresthedefinition<strong>of</strong>aDSMLmetamodel<br />
usingMOF<strong>and</strong>mappingstoUMLusingmodeltransformations.Thisneeds<br />
tobedoneonceforeachDSMLused.Furthermore,ameanstocreateassociatedmodelsisrequired.Wegaveseveralexamplesforthis.Comparedto<br />
thedevelopment<strong>of</strong>acompletegraphicaleditorforthedefinedmetamodel,<br />
ourapproachismorelightweight.<br />
Weevaluatedourapproachinthedomain<strong>of</strong>s<strong>of</strong>twarearchitecture,for<br />
whichwedefinedMDAV. Itrefinestheindustryst<strong>and</strong>ardforarchitecture<br />
documentation(IEEEStd1471-2000)bylinkingarchitecturalviews(documentation)toarchitecturalmodelsusingmodeltransformations<strong>and</strong>UML.<br />
MDAViseasilygeneralisedtootherdomains.Asanexample,wediscussed<br />
anindustrialapplicationinthedomain<strong>of</strong>controlsystems.
188 Chapter8. Visualisation<strong>of</strong>DSMLs<br />
Currentlyweareinvestigatinghowtheproposedmodeltransformationscanbestbeintegratedwithexistingtooling<strong>and</strong>developmentprocesses.Anotherproblemweareinvestigatingisthe(automatic)derivation<br />
<strong>of</strong>metamodels(e.g.,basedonMOF)fromgrammars(e.g.,basedonEBNF).A<br />
solutiontothisproblemincreasestheeffectiveness<strong>of</strong>ourapproachwhen<br />
appliedtoexistingDSMLsthatarenotbasedonMDAtechnology.
Chapter9<br />
Conclusion<br />
Thegoal<strong>of</strong>thisthesisistoinvestigatetechniquesthatreducetherisks<br />
<strong>and</strong>costsinvolvedintheevolution<strong>of</strong>s<strong>of</strong>twarearchitectures.Tostructure<br />
thisproblemweintroducedfours<strong>of</strong>twareevolutiontaskstobeinvestigated<br />
further:evaluation,conformancechecking,migration,<strong>and</strong>documentation.<br />
Asaconclusion,inthischapterwerevisittheresearchquestionswe<br />
raisedintheintroduction<strong>of</strong>thisthesisusingourexperiences<strong>and</strong>observationsasdiscussedinthepreviouschapters.Themainquestionwas:<br />
RQ0Howcantheevolution<strong>of</strong>s<strong>of</strong>twarearchitecturesbesupported?<br />
Belowweaddressthisquestionbyfirstdiscussingthesubquestionswe<br />
raised:<br />
RQ1Howtointegratethesupportfors<strong>of</strong>twareevolutiontasksinpractice,<br />
consideringtheinformaluse<strong>of</strong>modellinglanguages<strong>and</strong>preference<br />
forproventechnologiesinindustry?<br />
RQ2Whatistheimpact<strong>of</strong>theuse<strong>of</strong>s<strong>of</strong>twareproductlines<strong>and</strong>platforms<br />
onthesupportfors<strong>of</strong>twareevolutiontasks?<br />
RQ3Towhatextentcanthesupportfors<strong>of</strong>twareevolutiontasksbeautomatedbytheuse<strong>of</strong>model-drivenengineering?<br />
Wherethechapters<strong>of</strong>thisthesisaremainlysetupaccordingtothe<br />
s<strong>of</strong>twareevolutiontasksintroducedinChapter1,theoutline<strong>of</strong>thisconclusionisbasedonourresearchquestions.Afteralist<strong>of</strong>ourcontributions,<br />
theresultsforeach<strong>of</strong>themarediscussedinaseparatesectionbelow.We<br />
concludewithafinallist<strong>of</strong>recommendations<strong>and</strong>futurework.<br />
189
190 Chapter9. Conclusion<br />
9.1 Contributions<br />
Intheprocess<strong>of</strong>findinganswerstoourresearchquestions,wesurveyed<br />
thecurrentstate<strong>of</strong>thepractice<strong>of</strong>s<strong>of</strong>twareengineeringinindustry<strong>and</strong><br />
developedsolutionsthatsupportthes<strong>of</strong>twareevolutiontaskswedefined.<br />
Togetherwiththeanswerstoourresearchquestions,thesearethemain<br />
contributions<strong>of</strong>thisthesis:<br />
•anoverview<strong>of</strong>thes<strong>of</strong>twareengineeringtechnologiesusedinindustry<br />
forthedevelopment<strong>of</strong>embeddeds<strong>of</strong>tware(seeChapter3);<br />
•an approach for the evaluation <strong>of</strong> product-line architectures (see<br />
Chapter4);<br />
•amodel-drivenapproachforcheckingtheconformancebetweenstatebased<strong>and</strong>interaction-basedbehaviouralmodels(seeChapter5);<br />
•amodel-driven <strong>and</strong> view-based approach for automatically checkingtheconformancebetweenimplementation<strong>and</strong>architecture(see<br />
Chapter6);<br />
•amodel-drivenapproachforthemigration<strong>of</strong>supervisorymachine<br />
controlarchitectures(seeChapter7);<strong>and</strong><br />
•amodel-drivenapproachforsimultaneousevolution<strong>of</strong>models<strong>and</strong><br />
documentation based on views, the Unified <strong>Model</strong>ing Language 1<br />
(UML),<strong>and</strong>the<strong>Model</strong><strong>Driven</strong>Architecture 2 (MDA)(seeChapter8)<br />
One<strong>of</strong>thedistinguishingcharacteristics<strong>of</strong>ourworkliesinthefactthat<br />
wetakeintoaccountseveraladvancesins<strong>of</strong>twaredevelopmentpractices,<br />
thatis,s<strong>of</strong>twareproductlines<strong>and</strong>model-drivenengineering(MDE).Atthe<br />
sametimeweconsidertheimpact<strong>and</strong>application<strong>of</strong>theseapproachesin<br />
terms<strong>of</strong>s<strong>of</strong>twareevolution,whichtakesupmost(upto90%)<strong>of</strong>thetime,effort,<strong>and</strong>money<strong>of</strong>s<strong>of</strong>twaredevelopmentprojects<strong>and</strong>organisations[Lientz<br />
etal.,1978;Pigoski,1996]. Furthermore,weexplicitlyensuredthatthe<br />
methods<strong>and</strong>techniquesweproposedareamenabletobeintegratedinindustrialdevelopmentpractices.<br />
9.2 IntegrationinPractice(RQ1)<br />
AnimportantobservationfromthesurveywereportedoninChapter3is<br />
thegapbetweens<strong>of</strong>twareengineeringtechnologiesactuallyusedinindustry<strong>and</strong>thosedevelopedbytheresearchcommunity.<br />
Toreducethisgap,<br />
1 http://www.uml.org(June2007)<br />
2 http://www.omg.org/mda(June2007)
9.2. IntegrationinPractice(RQ1) 191<br />
wecontinuouslyconsideredindustrialintegrationasanimportantaspect<br />
<strong>of</strong>thesolutionsweproposed. Inparticularweaimedatreducingtheorganisationalimpact<strong>of</strong>oursolutions<strong>and</strong>addressedtheadoption<strong>of</strong><br />
MDA<br />
st<strong>and</strong>ards.<br />
ReducingOrganisationalImpact Instead<strong>of</strong>definingnewlanguages<strong>and</strong>methods,weusedexistingindustrialst<strong>and</strong>ardsasmuchaspossible(i.e,those<br />
relatedtotheMDA)<strong>and</strong>tookintoaccountcurrentindustrialpractices,such<br />
astheinformaluse<strong>of</strong>modelling. Ingeneral,weaimedatusing<strong>and</strong>extending(similar)technologiesasalreadyusedinpractice.Additionally,we<br />
triedtominimisetheresourcesrequiredtoapplyoursolutions.<br />
Wedidnotadvocatetheuse<strong>of</strong>newlanguagesifnotstrictlynecessary.<br />
Inthecaseswherewediddefinenewlanguages,theseareusedalongside(Chapter6)oraremappedto(Chapters7<strong>and</strong>8)languagesalready<br />
used(i.e., UML). Moreover,fortheirdefinitionweusedtheMetaObject<br />
Facility 1 (MOF),themetamodellinglanguage<strong>of</strong> MDA. Theadvantageis<br />
thatMOFuseswell-knownobject-orientedconceptstodefinemodellinglanguages.<br />
Furthermore,MOFissupportedbyanincreasingnumber<strong>of</strong>tools<br />
<strong>and</strong>open-sourceimplementationsareavailable(e.g.,theEclipse<strong>Model</strong>ing<br />
Framework 2 (EMF)).<br />
AlthoughUMLisawell-definedlanguage(atleastsyntactically),even<br />
inorganisationswhereUMLisused,modelsare<strong>of</strong>tenveryinformal.Such<br />
models,aremoreusedasillustrativediagramsthanprecises<strong>of</strong>twarespecifications.Toaccountfortheinformaluse<strong>of</strong>modellinglanguagesingeneral,<strong>and</strong>inparticularthat<strong>of</strong>UML,oursolutionsforconformancechecking<br />
(Chapter5)<strong>and</strong>migration(Chapter7)involveaspecificnormalisationstep.<br />
Suchastepisnecessarybecauseouraimtoautomatethesetasksbymeans<br />
<strong>of</strong>modeltransformations,requiresthatinputmodelsstrictlyconformtoa<br />
metamodel.<br />
Currently,thenormalisationstepisessentialfortheapplication<strong>of</strong>our<br />
model-drivensolutionsforthes<strong>of</strong>twareevolutiontasksinindustry. The<br />
mainreasonisthatatpresentmodellinginindustrycanbecharacterised<br />
asimmature[Kleppeetal.,2003],whichwealsoobservedduringoursurvey(seeChapter3).However,whentheuse<strong>of</strong>MDEtechnologiesingeneral,<br />
<strong>and</strong>theassociatedst<strong>and</strong>ardsinparticularbecomesmorewide-spread,we<br />
expectthatthemodellingmaturitylevelinindustrywillrise. Asmodels<br />
becomemoreprecise,theneedfornormalisationisreduced.<br />
To increase the potential for integration in practice it is important<br />
thatas<strong>of</strong>twareengineeringtechniquedoesnotrequireas<strong>of</strong>twaredevelopmentorganisationtochangemuch<strong>of</strong>itscurrentway<strong>of</strong>working<strong>and</strong><br />
1 http://www.omg.org/m<strong>of</strong>(June2007)<br />
2 http://www.eclipse.org/emf(June2007)
192 Chapter9. Conclusion<br />
thattheorganisationalimpactinterms<strong>of</strong>resources<strong>of</strong>thetechniqueis<br />
minimal.Therefore,inChapter4wereducedthenumber<strong>of</strong>stakeholders<br />
involvedintheevaluationapproachasmuchaspossible. Furthermore,<br />
byreducingtheinvolvementperstakeholder,theorganisationalimpactis<br />
minimised. TheresultingarchitectureevaluationprocessisnamedDistributedSAAM(DSAAM)<strong>and</strong>isbasedontheS<strong>of</strong>twareArchitectureAnalysis<br />
Method(SAAM),whichisextensivelydocumented[Kazmanetal.,1994,<br />
1996;Clementsetal.,2002b]). Withstakeholderinvolvementreduced,<br />
DSAAMstillproducedvaluableresults.<br />
Adoption<strong>of</strong>MDASt<strong>and</strong>ards Ourproposaltogenerate UML-baseddocumentation<br />
from domain-specific language (DSL) models in Chapter 8 enables<br />
the adoption <strong>of</strong> MDE approaches. It is expected that in the future<br />
MDE approaches will be more based on domain-specific modelling<br />
languages(DSMLs)thanonUML[Boochetal.,2004;Bézivinetal.,2005].<br />
Thisrequiresaconsiderableshiftfromthecurrentwide-spreaduse<strong>of</strong>UML.<br />
Additionally,theimplementation<strong>of</strong>toolsupportforDSMLsrequiressignificanteffort,forinstance,toimplementmodeleditors<strong>and</strong>visualisations.ThisbecomesevenmoreproblematicwhenanMDEapproachrequiresmultipleDSMLstocompletelyspecify<strong>and</strong>subsequentlygenerateapplications.<br />
Insuchcases,amappingtoUMLcanbeused,whilemovingtocomplete<br />
supportforthoseDSMLswithrespecttomodelling<strong>and</strong>visualisationtools.<br />
Theuse<strong>of</strong>MDAtechnology,mostnotably<strong>of</strong>UML,MOF<strong>and</strong>XMLMetadata<br />
Interchange 1 (XMI),throughoutthechapters<strong>of</strong>thisthesisfurthersupports<br />
theintegration<strong>of</strong>oursolutionsinpractice. Theuse<strong>of</strong>thesest<strong>and</strong>ards<br />
takesadvantage<strong>of</strong>existingtooling<strong>and</strong>skills<strong>of</strong>present-days<strong>of</strong>twarepractitioners.However,althoughtheiruseisanimprovement,thelevel<strong>of</strong>interoperabilityaspromisedbythesest<strong>and</strong>ardsisnotachieved.Withoutinvestigatingtheunderlyingreasons,thiswasalsoobservedbyLundelletal.<br />
[2006]. Amongthereasonsweencounteredduringourresearchareincorrect<strong>and</strong>incompleteimplementation<strong>of</strong>st<strong>and</strong>ardsbytoolvendors(especially<strong>of</strong>UML),<strong>and</strong>theuse<strong>of</strong>differentversions<strong>of</strong>UML,MOF,XMI,<strong>and</strong>combinationsthere<strong>of</strong>.Theconsequenceisthatadditionaltransformationsarerequiredonmodelserialisationsbeforetheycanbeexchangedbetweendifferenttools.Because<strong>of</strong>thelow-levelmodificationsrequiredinsuchcases<br />
ExtensibleMarkupLanguage 2 (XML)processingtools,suchasExtensible<br />
StylesheetLanguageTransformations 3 (XSLT),canbeusedforthis.<br />
1 http://www.omg.org/mda/specs.htm#XMI(June2007)<br />
2 http://www.w3.org/XML(June2007)<br />
3 http://www.w3.org/TR/xslt(June2007)
9.3. S<strong>of</strong>twareProductLines(RQ2) 193<br />
9.3 S<strong>of</strong>twareProductLines(RQ2)<br />
InChapter3wesignalledatrendtowardsapproachesthatallowamore<br />
structuredform<strong>of</strong>reusecomparedtotheadhoctype<strong>of</strong>reusethatistypicalinindustry.<br />
Inthiscontextproductlines<strong>and</strong>MDEaretwoimportant<br />
developments. Weobservedthatdifferentcompaniesareorganisingtheir<br />
s<strong>of</strong>twaredevelopmentsuchthattheirproductsaredevelopedaspart<strong>of</strong>a<br />
s<strong>of</strong>twareproductline.<br />
Theimpact<strong>of</strong>aproduct-linearchitectureonours<strong>of</strong>twareevolution<br />
tasksistwo-fold:<br />
•Theuse<strong>of</strong>s<strong>of</strong>twareproductlinesmakesthetasksmorecomplicated<br />
becausethecorrespondingproduct-linearchitecturesaremoreabstract,applytomultipleproducts,<strong>and</strong>,hence,involvealargernumber<br />
<strong>of</strong>stakeholders;theirscopeislargerwithrespecttotheproducts<strong>and</strong><br />
stakeholdersinvolved.<br />
•Ontheotherh<strong>and</strong>,theuse<strong>of</strong>anarchitecturethatappliestoawhole<br />
set<strong>of</strong>productsimprovesthereturnoninvestmentforsolutionsthat<br />
applytoalltheseproduct-linemembers.<br />
Scope<strong>of</strong>S<strong>of</strong>twareProductLines In Chapter 4 we discuss how the use <strong>of</strong><br />
product-lineprinciplesmakess<strong>of</strong>twarearchitectureevaluationsmorecomplex.Thefindings<strong>of</strong>suchanevaluationaremorebasedonindirectevidence,asscenariosareidentifiedforproduct-linemembers<strong>and</strong>notforthe<br />
productlineasawhole. Furthermore,aproduct-linearchitecturehasa<br />
muchwiderscopethanasingle-productarchitecture,therebyincreasing<br />
thenumber<strong>of</strong>stakeholders. Ourapproachtakesintoaccountboththese<br />
effects.<br />
Werefinedthetypicalclassification<strong>of</strong>scenariosaseitherdirect(i.e.,<br />
scenariosthatdonotrequirechangestothecurrentarchitecture)orindirect(i.e.,scenariosthatdorequirechangestothecurrentarchitecture)<br />
bydistinguishingbetweentwotypes<strong>of</strong>directscenarios:concretescenarios<br />
<strong>and</strong>floatingscenarios.Theformerareexplicitlysupportedbytheproductlinearchitecture,whilethelatterarenotexplicitlysupported,butnotpreventedbyitaswell(rememberthatas<strong>of</strong>twarearchitectureisbothpermissive<strong>and</strong>restrictivewithrespecttotheimplementationsitallows).<br />
Thenumber<strong>of</strong>scenariosthatwillbecharacterisedasfloatingina<br />
product-linearchitectureevaluationdependsonitsmaturity.BythematurityscaleproposedbyBosch[2002],Océ’sproduct-linearchitecturecanbe<br />
characterisedasaplatform.Thismeansthatcommonalitiesareidentified<br />
<strong>and</strong>separatedoutasaplatform,butthatthevariabilitiesarenotmade<br />
explicit. Thisresultsinalargernumber<strong>of</strong>floatingscenarios. However,
194 Chapter9. Conclusion<br />
ifthematurityisraisedbytheidentification<strong>of</strong>variabilities<strong>and</strong>theirexplicitspecificationinaproduct-linearchitecture,alargernumber<strong>of</strong>direct<br />
scenarioscanbeclassifiedasconcrete. Thus,amorematureproduct-line<br />
allowsamorecompleteevaluation.<br />
A drawback <strong>of</strong> scenario-based architecture evaluation approaches is<br />
theirhighorganisationalimpactcausedbytheinvolvement<strong>of</strong>thearchitecture’sstakeholdersinajointevaluationsession,whichcantakeupto<br />
severaldays. Inthecase<strong>of</strong>aproduct-linearchitecturethisproblemis<br />
particularlyimportant.Sucharchitectureshavealargerscoperesultingin<br />
anincreasednumber<strong>of</strong>stakeholders.Therefore,werestrictedthenumber<br />
<strong>of</strong>stakeholdersinvolvedinthejointevaluationsession<strong>and</strong>consultedother<br />
stakeholders separately. This significantly reduced the organisational<br />
impact<strong>of</strong>theevaluation.<br />
IncreasedReturnonInvestment Aswehaveseeninthisthesis,theuse<strong>of</strong>MDE<br />
approachesrequiresconsiderableeffortforthedefinition<strong>of</strong>metamodels,<br />
<strong>and</strong>transformation<strong>and</strong>normalisationrules. Forevolutiontasksthatare<br />
carriedoutonaregularbasis,thiseffortmightbejustified.Evaluationor<br />
conformancecheckingareexamples<strong>of</strong>tasksthatarecarriedoutrepeatedly<br />
atdifferentpointsintime. Aparticularmigration,however,istypically<br />
carriedoutonlyonce. Theimprovedreliability<strong>of</strong>anautomaticmigration<br />
basedonMDEispossiblynotsufficienttomotivatetheextraeffortrequired.<br />
Theuse<strong>of</strong>productlinesallowstojustifytherequiredeffortalsointhe<br />
case<strong>of</strong>amigration,asthiseffortissplitovereach<strong>of</strong>theproduct-linemembers.Assuch,theincreasedreturnoninvestmentforproduct-lineassets,suchasarchitecturedesigns<strong>and</strong>implementations<strong>of</strong>architecturalcomponents,alsoappliestothemodeltransformations<strong>and</strong>metamodelsdevelopedfortheautomation<strong>of</strong>particulars<strong>of</strong>twareengineeringtasks.<br />
Asan<br />
example,inthecase<strong>of</strong>themigrationdiscussedinChapter7forwhichwe<br />
definedanapproachthatisdomainspecifictosomeextent,wecouldreuse<br />
theconcernsweidentified,theircorrespondingpatterns,metamodels,<strong>and</strong><br />
transformationrules.<br />
9.4 <strong>Model</strong>-<strong>Driven</strong>Engineering(RQ3)<br />
Ourgoalwastoreducetherisks<strong>and</strong>costs<strong>of</strong>architectureevolution.Tothis<br />
end,weaimedatautomatingoursolutionsusingMDEtechniques.Automationismadepossiblebyconsideringtheinvolvedmodels(inarchitectural<br />
views)asmodelsintheMDEsense,thatis,specifiedusingawell-defined<br />
(atleastsyntactically)modellinglanguage.WithMDE,modellinglanguages<br />
aredefinedusingmetamodels.Assuch,thisrequiresthecreationorreuse
9.4. <strong>Model</strong>-<strong>Driven</strong>Engineering(RQ3) 195<br />
Source Space MDE Space Target Space<br />
Metametamodel Metametamodel<br />
conforms to<br />
+ source<br />
Normalisation Rules<br />
Normalisation<br />
Transformation Rules<br />
Metamodel Metamodel Metamodel<br />
represented by<br />
conforms to conforms to<br />
Source<br />
+ source<br />
+ target<br />
conforms to conforms to<br />
Source <strong>Model</strong><br />
target<br />
source<br />
+ source + target<br />
represented by<br />
<strong>Evolution</strong> Transformation<br />
conforms to<br />
Generation Rules<br />
+ source<br />
represented by<br />
Generation<br />
Metametamodel<br />
conforms to<br />
+ target<br />
Metamodel<br />
conforms to<br />
Target <strong>Model</strong><br />
Target<br />
+ target + source + target<br />
Figure 9.1:Megamodelformodel-drivenevolution<strong>of</strong>s<strong>of</strong>twarearchitectures<br />
<strong>of</strong>suitablemetamodels. Inparticular,weemployed MDAst<strong>and</strong>ards<strong>and</strong><br />
theirsupportingtools.<br />
Interms<strong>of</strong>theeffortrequiredfortheapplication<strong>of</strong>MDE,theautomation<strong>of</strong>as<strong>of</strong>twareevolutiontaskinvolvesatrade-<strong>of</strong>fbetweentwoaspects:<br />
theprocess<strong>of</strong>(partly)automatingthetask,<strong>and</strong>thesubsequentexecution<br />
<strong>of</strong>the(partly)automatedtask.Theformerdeterminesthecosts<strong>of</strong>following<br />
amodel-drivenapproach,whilethelatterrelatestotheresultingbenefit.<br />
Weexplainallaspects<strong>of</strong>thedeployment<strong>of</strong>MDEtechniquesforthes<strong>of</strong>twareevolutiontasksbymeans<strong>of</strong>thegenericframeworkinFigure9.1.In<br />
Section2.3.2<strong>and</strong>Figure2.6onpage33wereferredtosuchaframeworkas<br />
amegamodel.<br />
AMegamodelfor<strong>Model</strong>-<strong>Driven</strong><strong>Evolution</strong><strong>of</strong>S<strong>of</strong>tware<strong>Architectures</strong> Thedifferent<br />
MDEsolutionsforthes<strong>of</strong>twareevolutiontaskswedefined<strong>and</strong>discussed<br />
inthisthesisleadtothegenericmegamodelformodel-drivenevolution<strong>of</strong><br />
s<strong>of</strong>twarearchitecturesdepictedinFigure9.1.Thismegamodelillustrates<br />
theartefacts<strong>and</strong>theirrelationshipsinvolvedinthemodel-drivensupport<br />
<strong>of</strong>as<strong>of</strong>twareevolutiontask.Werevised<strong>and</strong>extendedthetwo-phasedmigrationprocess<strong>of</strong>Figure7.3onpage137suchthattheprocessesweapplied<br />
intheotherchaptersfittheresultingevolutionmegamodelaswell.
196 Chapter9. Conclusion<br />
Themegamodelinvolvesthreetechnologicalspaces(seeSection2.3.4):a<br />
Source Space,whichcontainsthe Sourceartefactsforaparticularevolution<br />
task;an MDE Space(i.e.,modelware),inwhichweapplymodeltransformationstosupportas<strong>of</strong>twareevolutiontask;<strong>and</strong>aTarget<br />
Space,inwhich<br />
the Targetartefactsaregenerated.Dependingontheevolutioncontext,the<br />
Source<strong>and</strong>TargetmayalsobeintheMDEspace. Otherpossibilitiesinclude,theXML<strong>and</strong>grammarwarespaces.<br />
The <strong>Evolution</strong> TransformationiscarriedoutintheMDESpace<strong>and</strong>transformsaSource<br />
<strong>Model</strong>intoaTarget <strong>Model</strong>. Itisspecified(i.e., represented by)<br />
aset<strong>of</strong> Transformation RulesintheMDESpace.Thisimpliesthattheserules<br />
aredefinedusingamodeltransformationlanguage.This<strong>Evolution</strong>Transformationisspecifictothetaskath<strong>and</strong>.<br />
TheTransformationRulesare<br />
specifiedinterms<strong>of</strong>asource<strong>and</strong>atarget Metamodelassociatedwiththe<br />
source<strong>and</strong> targetmodel<strong>of</strong>thetransformation.<br />
Ascanbeseenfromthisthesis,<strong>of</strong>tennomodelisavailablethatissuitabletoserveassource<strong>of</strong>the<strong>Evolution</strong>Transformation.Insuchcasesan<br />
additionalstepisrequired. Normalisationistheexecution<strong>of</strong>aset<strong>of</strong> Normalisation<br />
Ruleswiththeaim<strong>of</strong>populatingaSource<strong>Model</strong>intheMDESpace<br />
suitableforfurthertransformationusingmodeltransformations.<br />
Finally,inthe Generationstepthe Targetfortheparticularevolutiontask<br />
iscreatedaccordingtoaset<strong>of</strong> Generation Rules.The target<strong>of</strong>theGeneration<br />
stepisinaspecificTargetSpace,forinstance,thegrammarwareorXML<br />
space.<br />
Allinvolvedmodel-levelartefacts(seeFigure2.3onpage30),thatis,<br />
theSource,Source<strong>Model</strong>,Target<strong>Model</strong>,<strong>and</strong>Target conform toaMetamodel.<br />
Itdependsonthetype<strong>of</strong>technologicalspacewhatkind<strong>of</strong>Metamodelis<br />
used,suchasagrammar,MOFmetamodel,orXMLschema.Inturn,these<br />
metamodels conform tothegoverning Metametamodelforthattechnological<br />
space,forinstance,MOFinthecase<strong>of</strong>theMDAspace.<br />
Normalisation Thenormalisationstepweintroducedinseveralcasesisnot<br />
alwaysfullyautomated. Itisthisnormalisationstepthatallowstoautomatesubsequentsteps.Normalisationisforalargepartcontextdependent.Theamount<strong>of</strong>normalisationrequireddependsonthetype<strong>of</strong>source<br />
artefacts,themodellingmaturitylevel,modellingconventions,thescope<strong>of</strong><br />
thesourcelanguage,<strong>and</strong>thetransformationrules.<br />
WhentheSourceSpace<strong>of</strong>thes<strong>of</strong>twareevolutiontaskisnotthesame<br />
astheMDESpace,normalisationatleastincludesabridgebetweenthat<br />
SourceSpace<strong>and</strong>theparticularMDESpace(e.g.,MDA).Insomecasesnormalisationinvolvesnotmorethanthatbridge.Ifthesourceisbasedona<br />
well-definedlanguagethebridgecanbefullyautomated.
9.4. <strong>Model</strong>-<strong>Driven</strong>Engineering(RQ3) 197<br />
NormalisationinChapter6wasslightlymoreinvolved.Here,afterthe<br />
bridgebetweenthegrammarware<strong>and</strong>MDAspaces,forwhichwereused<br />
existinggrammarwaretoXML<strong>and</strong>XMLtoMDAbridges,alsosomeabstractionstepswererequired.Wespecifiedtheseabstractionstepsusingmodel<br />
transformations.Hence,thisnormalisationstepwasals<strong>of</strong>ullyautomated.<br />
Inothercasesnormalisationismoredifficult<strong>and</strong>requiresreplacement<br />
<strong>of</strong>customannotations(seeChapter5),theapplication<strong>of</strong>aUMLpr<strong>of</strong>ile,<br />
ortheapplication<strong>of</strong>st<strong>and</strong>ardidiomsforparticularconcerns(seeChapter7).<br />
Thesecasesinvolvemanualeffortfornormalisationthatrequires<br />
domainknowledge. Asanexample,considertheuse<strong>of</strong>UML,ageneralpurposelanguage(GPL),inChapter7.UMLallowstoexpressaparticularconcernusingamultitude<strong>of</strong>differentidioms.<br />
Therefore,additional<br />
constraints<strong>and</strong>modellingconventionsarerequiredtoreducethecomplexity<strong>of</strong>modeltransformations.<br />
Otherwisesuchtransformationshave<br />
totakeintoaccounttoomanypossibleidiomsforaparticularconcern,as<br />
weillustratedinChapter7. Asasolutionweidentifiedtherelevantconcernsinthedomain<strong>of</strong>supervisorymachinecontrol(SMC)systems.<br />
For<br />
eachconcern,wedefinedasinglecorrespondingdesignidiom,whichconformsstrictlytoacorrespondingmetamodel.WedefinedaUML-SMCpr<strong>of</strong>ile,whichconsists<strong>of</strong>stereotypes<strong>and</strong>well-formednessrulesintheObjectConstraintLanguage<br />
1 (OCL)correspondingtothesedesignidioms. Normalisationinvolvesapplyingstereotypestoappropriatemodelelements<strong>and</strong><br />
modifyingthesourcemodelinsuchawaythatconcernsareconsistently<br />
addressedbytheircorrespondingdesignidiomwithoutviolatingany<strong>of</strong>the<br />
well-formednessrules<strong>of</strong>thepr<strong>of</strong>ile.<br />
Forcomplexnormalisations,weidentifiedatrade-<strong>of</strong>fbetweencomplex<br />
transformationrulestoaccountforalargeidiom<strong>of</strong>possibleinputpatterns,<br />
oramoreextensivenormalisationproceduretoaccountforalargenumber<br />
<strong>of</strong>restrictionsonthesourcemodels(i.e.,tolimitthesize<strong>of</strong>thesourcelanguage).<br />
So,evenincaseswherethesource<strong>of</strong>anevolutiontaskisavalidUML<br />
model(i.e.,amodelthatconformstotheUMLmetamodel),normalisation<br />
canberequiredtorestrictthenumber<strong>of</strong>possiblesourceidiomsresultingin<br />
alesscomplexevolutiontransformation.ThiswasnecessaryinChapter7<br />
<strong>and</strong>toalesserextentalsoinChapter5.<br />
TheneedforrestrictingUMLlikethis,raisesthequestionwhetherthe<br />
use<strong>of</strong>aDSMLdefinedusingMOFinsuchcaseswouldn’tbemoreappropriate.Thisisamatter<strong>of</strong>ongoingdebatebetweentwoschools<strong>of</strong>thoughtin<br />
theMDEcommunity[France<strong>and</strong>Rumpe,2007].Onearguesinfavour<strong>of</strong>the<br />
use<strong>of</strong>anextensiblegeneral-purposemodellinglanguage,whiletheother<br />
promotesthedefinition<strong>of</strong>DSMLs.Incurrentpractice,however,thelack<strong>of</strong><br />
1 http://www.omg.org/technology/documents/modeling_spec_catalog.htm#OCL(June2007)
198 Chapter9. Conclusion<br />
sufficienttoolsupportforthedefinition<strong>of</strong>DSMLs<strong>and</strong>thewide-spreaduse<br />
<strong>of</strong>UMLareforcompanies<strong>of</strong>tensufficientreasonsforusingUML.<br />
<strong>Evolution</strong>Transformation Exceptforevaluation, oursolutionsforthes<strong>of</strong>twareevolutionstaskswereatleastpartlyautomatedbyspecifyingthem<br />
asmodeltransformationsintheAtlasTransformationLanguage[Jouault<br />
<strong>and</strong>Kurtev,2005](ATL).Inoursolutionfortheconformancecheckingtasks<br />
inChapter6,wehadtwosourcemodels.Ingeneral,wespecifiedthedifferentsteps<strong>of</strong>anevolutiontaskinseparatemodeltransformations.Typically,<br />
multiple<strong>of</strong>suchtransformationsarerequired.<br />
NowthatMDEapproachesthatinvolvethedefinition<strong>and</strong>application<br />
<strong>of</strong>modeltransformationsgetmoreinuse,companiesmightwanttoreconsidertheiruse<strong>of</strong>UML.Inourresearchweexperiencedthattheuse<strong>of</strong>UML<br />
resultsincomplicateddefinitions<strong>of</strong>modeltransformations. Thereasons<br />
forthisaretheaforementionedsize<strong>of</strong>theUMLmetamodel,aswellasits<br />
complexity<strong>and</strong>thefactthatmostUMLmodellingtoolsonlypartiallyimplementtheUMLspecificationor,evenworse,incorrectly.Theformerrelatesto<br />
thetrade-<strong>of</strong>fweidentifiedbetweenthenumber<strong>of</strong>sourcemodelrestrictions<br />
involvedinthenormalisationprocedure<strong>and</strong>thecomplexity<strong>of</strong>subsequent<br />
modeltransformations.<br />
Becausethecurrentstate<strong>of</strong>modellinginindustryissuchthatlanguagesasUMLareonlyusedinformally<strong>and</strong>free-formbox-<strong>and</strong>-linediagramsarealso<strong>of</strong>tenused,theapplication<strong>of</strong>model-drivenapproachesinindustrialcontextstypicallyrequiresthedefinition<strong>of</strong>metamodels.Ofcourse,transformationrulesalsoneedtobespecified.Theextenttowhichtheeffortthatthisrequiresisjustifieddependsontheparticularcontext.<br />
As<br />
discussedaboveinthecase<strong>of</strong>productlinesthereturnoninvestmentfor<br />
thiseffortisincreased. Here,theuse<strong>of</strong>st<strong>and</strong>ardsformodelling,metamodelling,<strong>and</strong>modeltransformations,<strong>of</strong>fersaverystrongbenefit.<br />
They<br />
enable,forinstance,thecreation<strong>of</strong>repositoriestosharetheseMDEartefactsamongdifferentprojects,productlines,<strong>and</strong>companies.<br />
Infact,we<br />
contributedthemodeltransformationswedefinedinChapter5forthe<br />
generation<strong>of</strong>astatemodelfromaset<strong>of</strong>scenariostosucharepository 1 .<br />
Inothercases,wereusedmetamodels(e.g.,metamodelsforDOT<strong>and</strong>XML)<br />
<strong>and</strong>transformations(e.g.,DOTtotext)availablefromrepositoriesourselves<br />
aswell.<br />
Generation Thefinal(code)generationstepiswell-studiedintheMDEliterature.Forthatreason,wedecidednott<strong>of</strong>ocusonthisstepinthisthesis,directingourattentiontothenormalisation<strong>and</strong>transformationstepsinstead.Nevertheless,aftertheexecution<strong>of</strong>theevolutiontransformation(s),<br />
1 http://www.eclipse.org/gmt/atl/atlTransformations(June2007)
9.5. Supportfor<strong>Evolution</strong><strong>of</strong>S<strong>of</strong>tware<strong>Architectures</strong>(RQ0) 199<br />
typically,someoutputneedstobegenerated,possiblyinadifferenttechnologicalspace.Theresultcanbe,forinstance,sourcecode,diagrams,oran<br />
XMLrepresentation<strong>of</strong>thetargetmodel.Examples<strong>of</strong>suchgenerationsteps<br />
inthisthesisincludethefollowing:<br />
•InChapter5generationencompassesserialisingtheresult<strong>of</strong>theevolutiontransformationusingXMIintoXMLwiththeaim<strong>of</strong>loadingthe<br />
targetmodelinaUMLmodellingtoolforvisualisation. Essentially,<br />
theXMIst<strong>and</strong>ardprovidesthenecessarygenerationrulesinthiscase,<br />
<strong>and</strong>actsasabridgebetweentheMDA<strong>and</strong>XMLspace.<br />
•InChapter6wegenerateDOTcodeinthegrammarwarespacefrom<br />
thetargetmodel.Thegenerationrulesincluderulestomapthetargetmodel<strong>of</strong>theevolutiontransformationtoa(MOF-based)DOTmodel<strong>and</strong>rulestogenerateDOTsourcecodefromthatDOTmodel.Wedefinedtheformerourselves,<strong>and</strong>reusedthelatterfromarepository<strong>of</strong><br />
modeltransformations.<br />
•Finally,inChapter8,thegoal<strong>of</strong>theevolutiontaskistovisualise<br />
DSMLmodelsasUMLdiagramstobeincludedindocumentation.Here,<br />
thegenerationstepisthetransformation<strong>of</strong>aUMLmodelinsome<br />
graphicalformat,suchasScalableVectorGraphics 1 (SVG)(intheXML<br />
space)orPostScript(inthegrammarwarespace).<br />
9.5 Supportfor<strong>Evolution</strong><strong>of</strong>S<strong>of</strong>tware<strong>Architectures</strong>(RQ0)<br />
Havinglookedatthethreesubquestions,wereturntothemainquestion,<br />
howtosupporttheevolution<strong>of</strong>s<strong>of</strong>twarearchitectures.Wefirstrevisitthe<br />
fours<strong>of</strong>twareevolutiontasks,<strong>and</strong>thendiscussthescope<strong>of</strong>theindustrial<br />
casestudiesweconducted.<br />
S<strong>of</strong>tware<strong>Evolution</strong>Tasks Byvalidatingtheresearchresultsbymeans<strong>of</strong>industrialcasestudies,anevaluation<strong>of</strong>theapplicability<strong>of</strong>ourtechniquesin<br />
tothes<strong>of</strong>twareevolutiontasksinindustrialpracticewasobtained.<br />
For evaluations, in contrast with other approaches (e.g., Gallagher<br />
[2000];Olum<strong>of</strong>in<strong>and</strong>Mišlić[2006]),DSAAMspecificallytakesintoaccount<br />
thedifferenceinscope(i.e., withrespecttoproducts<strong>and</strong>stakeholders)<br />
betweensingle-productarchitectures<strong>and</strong>product-linearchitectures. In<br />
fact,Océusedtheresults<strong>of</strong>ourevaluationtodecidetocontinuewiththe<br />
development(evolution)<strong>of</strong>theirreference(product-line)architecture.<br />
1 http://www.w3.org/Graphics/SVG(June2007)
200 Chapter9. Conclusion<br />
Wediscussedtwoapproachesforconformancechecking. Oneisfully<br />
automatic,whiletheotherrequiresamanualcomparison.Weappliedthe<br />
latterinChapter5totheembeddeds<strong>of</strong>twareforcopiersdevelopedbyOcé<br />
<strong>and</strong>asmallATMexample.Inbothapplicationswedetectedinconsistencies<br />
thatwouldhavebeendifficulttodetectwithoutoursupport.Althoughthe<br />
actualcomparisonismanual,itismadepossiblebyourautomaticmapping<br />
betweentwotypes<strong>of</strong>architecturalmodels,whichwespecifiedusingmodel<br />
transformations. InChapter6wefocusedonalsoautomatingtheactual<br />
comparisonstep.<br />
Forthemigrationtaskourautomatic,model-drivensolution<strong>of</strong>fersclear<br />
benefitswithrespecttothealternative,amanualmigration.Theneedfor<br />
domainexpertsisreduced<strong>and</strong>thenecessarydefinition<strong>of</strong>asuitablemetamodelincreasestheunderst<strong>and</strong>ing<strong>of</strong>themigrationitself<strong>and</strong>thetarget<br />
architecture. Finally,becausethedefinedtransformation<strong>and</strong>normalisationrulesaregeneric,theycanbereusedforthemigration<strong>of</strong>otherSMCcomponents.Thiswasillustratedbythemigration<strong>of</strong>asecondSMCcomponent,forwhichweonlyhadtodefineafewextratransformationrulesto<br />
includefeatures<strong>of</strong>thetargetarchitecturethatwerenotrelevantinthefirst<br />
case.Here,theuse<strong>of</strong>product-lineprinciplesforthedevelopment<strong>of</strong>these<br />
SMCcomponents,justifiestheeffortrequiredforapplyingamodel-driven<br />
migrationapproach.<br />
Oursolutionforthedocumentationtask<strong>of</strong>fersanalternativefordevelopingacomplete(graphical)notation<strong>and</strong>correspondingeditorforaDSML.<br />
Althoughitmightnotalwaysbepossibletodefineasuitablemappingto<br />
UMLduetothesemanticgapbetweenUML<strong>and</strong>theDSML,oursolutionhas<br />
thebenefit<strong>of</strong>beingmorelight-weight. Assuch,ourapproachisparticularlysuitedforsituationswheregraphicalediting<strong>of</strong>DSMLmodelsisnot<br />
(yet)required,forexample,whenacompanyisgraduallymigratingfrom<br />
UMLt<strong>of</strong>ullDSMLsupport.<br />
Ourresultsdemonstratetheapplicability<strong>of</strong>model-drivensolutionsto<br />
specifics<strong>of</strong>twareevolutiontasks.Forthes<strong>of</strong>twareevolutiontasksweconsidered,weproposedsolutionsthattakeintoaccountproduct-linearchitectures(opposedtosingle-productarchitectures),aimtoreduceorganisationalimpact,oraremodel-driven.Furthermore,weextend<strong>and</strong>usetechnologiesthathavealreadyproventheirapplicabilityinpractice,suchas<br />
SAAM<strong>and</strong>MOF.<br />
EmbeddedS<strong>of</strong>tware Althoughoursolutionswereinvestigatedinthecontext<br />
<strong>of</strong>concrete(industrial)problems,ourevaluationsshowthattheycanbe<br />
applied(tosomeextent)toours<strong>of</strong>twareevolutiontasksforabroaderclass<br />
<strong>of</strong>systems. Intheintroductionwealsoraisedthequestionwhetherour<br />
resultsonlyapplytotheevolution<strong>of</strong>embeddeds<strong>of</strong>tware. Toanswerthis
9.6. FutureWork<strong>and</strong>Recommendations 201<br />
questionwehavetodecidewhetheras<strong>of</strong>twaresystem’s‘embeddedness’is<br />
relevantfromtheperspective<strong>of</strong>thes<strong>of</strong>twareevolutiontasksweidentified.<br />
Ourworkappliestoaspecialtype<strong>of</strong>s<strong>of</strong>twareinterms<strong>of</strong>thecasestudiesweconducted;allwereinthedomain<strong>of</strong>embeddeds<strong>of</strong>tware.Acommonperceptionisthatdevelopingembeddeds<strong>of</strong>twareisdifferentfromdevelopingotherkinds<strong>of</strong>s<strong>of</strong>twarebecause<strong>of</strong>somespecificcharacteristics:embeddeds<strong>of</strong>twarehasadedicatedfunction,<strong>and</strong>isembeddedin,<strong>and</strong>reactive<strong>and</strong>logicallyconnectedtoaphysicalsystemcomposed<strong>of</strong>hardware<br />
(e.g.,mechanical,electronic,oropticalcomponents)<strong>and</strong>s<strong>of</strong>tware. These<br />
characteristicsmakethatembeddeds<strong>of</strong>twarehassomespecificproperties<br />
thatmakedevelopingembeddeds<strong>of</strong>twaredifferentfromatechnicalpoint<br />
<strong>of</strong>view. Asanexample,inmanycasesreal-timeconstraintsplayanimportantrole,aswellassize<strong>of</strong>memoryfootprints.Furthermore,embedded<br />
s<strong>of</strong>tware<strong>of</strong>tenneedstocomplytosafetyconstraints(inthecaseitcontrols<br />
aphysicalsystemthatmightcausephysicaldamage).<br />
So,indeedembeddeds<strong>of</strong>twarehasmanyspecificcharacteristics. However,mostimportantfors<strong>of</strong>twareevolution,thetopic<strong>of</strong>ourresearch,isthe<br />
factthatthistype<strong>of</strong>s<strong>of</strong>twareisembeddedinaphysicalsystem.Although<br />
wecannotconcludefromthisthats<strong>of</strong>twareevolutionisdifferentforembeddedsystems,itdoesmakeevolutionunavoidable.Infact,thetwos<strong>of</strong>twareevolutionlawsdiscussedinSection2.1onlyapplytoaspecialclass<strong>of</strong>systems.<br />
Lehman[1980]definesthisclass<strong>of</strong>,so-called,E-typesystems,as<br />
theclass<strong>of</strong>systems<strong>of</strong>whichthespecificationincludesamodel<strong>of</strong>the‘real’<br />
world.Theembeddedsystemssuchasthosestudiedinourcasestudiesare<br />
prototypicalexamples<strong>of</strong>E-typesystems.Therefore,weconjecturethatour<br />
resultsarevalidforE-typesystemsingeneral,<strong>and</strong>notjustforembedded<br />
systems.<br />
9.6 FutureWork<strong>and</strong>Recommendations<br />
Inthisthesisweinvestigatedhowtosupportfourdifferents<strong>of</strong>twareevolutiontasks.<br />
Tothisend,wedefinedsolutionsthataremodel-driven<strong>and</strong><br />
takeintoaccounttheuse<strong>of</strong>productlines.Toenableindustrytointegrate<br />
oursolutionsintheirdevelopmentprocesses,weminimisedtheirorganisationalimpactbyreusingproventechnologies<strong>and</strong>st<strong>and</strong>ardsasmuchaspossible<strong>and</strong>limitingtherequiredadditionaleffort.Inmostcasesweinterpretedthes<strong>of</strong>twareevolutiontasksasmodeltransformationproblems<strong>and</strong>providedsuitabletransformationrules,whichcanbeexecutedautomatically.<br />
Inthechapters<strong>of</strong>thisthesisweraisedmanyissuestobeinvestigated<br />
furtherthatinclude,supportings<strong>of</strong>twareevolutiontasksinothertechnologicalspaces,development<strong>of</strong>hybridapproaches,<strong>and</strong>management<strong>and</strong>
202 Chapter9. Conclusion<br />
evolution<strong>of</strong>modelwareartefacts. Toconcludewebrieflyrevisitthembelow.WeprimarilyusedMDAmodeltransformationsinATLtosupports<strong>of</strong>tware<br />
evolution tasks. Similar support can also be developed in other<br />
technologicalspaces. Inthegrammarwarespace,forinstance,als<strong>of</strong>ormalisms<strong>and</strong>toolsareavailableforthedefinition<strong>of</strong>languages<strong>and</strong>transformations,<br />
suchastheASF+SDF Meta-Environment[Klint,1993]<strong>and</strong><br />
Stratego/XT[Visser,2004]. Astheprocesseswedefinedforthesupport<br />
<strong>of</strong> the different evolution tasks are technology independent, our work<br />
providesthestartingpointfordevelopingsimilarsupportbyusing<strong>and</strong><br />
combiningothertechnologies. Thisraisesinterestingresearchquestions<br />
withrespecttowhichtechnologicalspaceisbestsuitedfordevelopment<strong>of</strong><br />
supportforaspecificevolutiontask<strong>and</strong>howtobettercombinelanguages<br />
<strong>and</strong>transformationsdefinedindifferenttechnologicalspaces.<br />
Assumingthatsourcecoderemainsinthegrammarware<strong>and</strong>s<strong>of</strong>tware<br />
modelsremaininthemodelwaretechnologicalspaces,thiscombination<strong>of</strong><br />
artefactsfromdifferenttechnologicalspacesisunavoidableformostsolutionsfors<strong>of</strong>twareevolutiontasks.<br />
Unfortunately,therequiredbridges<br />
currentlyneedtobespecificallydeveloped,atleastpartially.Theproblem<br />
withthebridgesweusedisthattheyaredefinedonthemetamodellevel.<br />
Forsuchbridgestobegeneric<strong>and</strong>reusabletheyshouldbedefinedonthe<br />
metametamodellevel. Infact,for MDAto XMLsuchabridgeisalready<br />
availableintheform<strong>of</strong>XMI.Asimilarbridgebetweengrammarware<strong>and</strong><br />
MDAisessentialforcombiningthesetwotechnologicalspaces.Thisbridge<br />
wouldmapEBNFtoMOFsuchthatEBNFgrammarscanbeautomatically<br />
transformedincorrespondingMOFmetamodels<strong>and</strong>viceversa,aswellas<br />
theprograms<strong>and</strong>modelsconformingtothosegrammars<strong>and</strong>metamodels.<br />
Ourexperienceshowsthatforautomaticsupport<strong>of</strong>aparticulars<strong>of</strong>twareevolutiontaskmultiplemodeltransformationsarerequired.<br />
Each<br />
modeltransformationinvolvesitsowntransformationrules,source<strong>and</strong><br />
targetmodels,<strong>and</strong>correspondingmetamodels.Moreover,<strong>of</strong>tenthesupport<br />
<strong>of</strong>evolutiontasksalsoinvolvesoperationsoutsidetheMDAspace,suchas<br />
XSLTtransformationsintheXMLspace,orsed<strong>and</strong>Perlscripts.Thismakes<br />
thatthemanagement<strong>of</strong>alltheinvolvedartefact<strong>and</strong>transformationssteps<br />
requiresspecialattention.Althoughthisproblemwasnotthefocus<strong>of</strong>our<br />
research,inonecaseweusedabuildtool(Ant)tosolvethisproblem.However,withthisapproach,therequiredconfigurationfilesalsotendtoget<br />
verycomplex. Assuch,thisproblemcallsforadditionalsupport,which<br />
requiresadditionalresearch.<br />
Meansforthemanagement<strong>of</strong>modelwareartefactsareessentialforsuccessfulapplication<strong>of</strong>oursolutionsinindustry.<br />
Similartoothers<strong>of</strong>tware<br />
developmentartefactsthismodelwareisalsoexpectedtoevolve. Interestingpossibilitiestominimisetherequiredevolution<strong>of</strong>suchartefactsby
9.6. FutureWork<strong>and</strong>Recommendations 203<br />
raisingtheirgenerality,arehigher-ordertransformations. Suchtransformationsthathaveanothertransformationassourceortargetmodel,canbeusedfortheconformancecheckingtask,forinstance,togenerateconformancecheckingtransformationsfromthemetamodelsassociatedwiththeinvolvedmodels.Thisrequiresthatthereisametamodelforthetransformationlanguage,whichisthecaseforATL.Finally,forfurtherinvestigation<strong>of</strong>theissuesdiscussedabove,industrialcasestudiesshouldplayanessentialroleastheydidinthisthesis.Thefocusonrealindustrialproblemsenabledustodiscover<strong>and</strong>investigatedifficultiesthatareinherenttoindustrialpractice.Asanexample,the<br />
needfornormalisation,whichplaysaprominentroleinthisthesis,could<br />
nothavebeeninvestigatedwithoutsuchcasestudies.
Bibliography<br />
Abowd,Gregory,RobertAllen,<strong>and</strong>DavidGarlan. Usingstyletounderst<strong>and</strong>descriptions<strong>of</strong>s<strong>of</strong>twararchitecture.ACMSIGSOFTS<strong>of</strong>twareEngineeringNotes,18(5):pages9–20,1993.<br />
Al-Ekram,Raihan<strong>and</strong>KostasKontogiannis. AnXML-basedframework<br />
forlanguageneutralprogramrepresentation<strong>and</strong>genericanalysis. In<br />
Proceedings<strong>of</strong>the9 th EuropeanConferenceonS<strong>of</strong>twareMaintenance<strong>and</strong><br />
Reengineering(CSMR2005),pages42–51.IEEEComputerSociety,2005.<br />
Aldrich,Jonathan,CraigChambers,<strong>and</strong>DavidNotkin.Archjava:Connectings<strong>of</strong>twarearchitecturetoimplementation.<br />
InProceedings<strong>of</strong>the24 th<br />
InternationalConferenceonS<strong>of</strong>twareEngineering(ICSE2002),pages<br />
187–197.IEEEComputerSociety,2002.<br />
Allen,Robert<strong>and</strong>DavidGarlan.Formalizingarchitecturalconnection.In<br />
Proceedings<strong>of</strong>the16 th InternationalConferenceonS<strong>of</strong>twareEngineering.(ICSE1994),pages71–80.IEEEComputerSociety,1994.<br />
Allen, Robert<strong>and</strong>DavidGarlan. Aformalbasisforarchitecturalconnection.<br />
ACMTransactionsonS<strong>of</strong>twareEngineering<strong>and</strong>Methodology<br />
(TOSEM),6(3):pages213–249,1997.<br />
Amyot,Daniel<strong>and</strong>ArminEberlein. Anevaluation<strong>of</strong>scenarionotations<br />
<strong>and</strong> construction approaches for telecommunication systems development.TelecommunicationSystems,24(1):pages61–94,2003.<br />
Atkinson,Colin<strong>and</strong>ThomasKüne. <strong>Model</strong>-drivendevelopment: Ametamodelingfoundation.IEEES<strong>of</strong>tware,20(5):pages36–41,2003.<br />
ATLASgroup. ATLUserManual. LINA&INRIA,Nantes,2006. http:<br />
//www.eclipse.org/m2m/atl/doc/ATL_User_Manual[v0.7].pdf.<br />
Badros,GregJ.Javaml:amarkuplanguageforjavasourcecode.Computer<br />
Networks,33(1–6):pages159–177,2000.<br />
205
206 BIBLIOGRAPHY<br />
Bass,Len,PaulClements,<strong>and</strong>RickKazman. S<strong>of</strong>twareArchitecturein<br />
Practice.Addison-Wesley,2 nd edition,2003.<br />
Baxter,IraD.,ChristopherPidgeon,<strong>and</strong>MichaelMehlich.DMS:Program<br />
transformationsforpracticalscalables<strong>of</strong>twareevolution. InProceedings<strong>of</strong>the26<br />
th InternationalConferenceonS<strong>of</strong>twareEngineering(ICSE<br />
2004),pages625–634.IEEEComputerSociety,2004.<br />
Bengtsson, PerOl<strong>of</strong>, Nico Lassing, Jan Bosch, <strong>and</strong> Hans van Vliet.<br />
Architecture-levelmodifiabilityanalysis(ALMA). Journal<strong>of</strong>Systems<br />
<strong>and</strong>S<strong>of</strong>tware,69(1–2):pages129–147,2004.<br />
Bézivin,Jean. Ontheunificationpower<strong>of</strong>models. S<strong>of</strong>tware<strong>and</strong>Systems<br />
<strong>Model</strong>ling,4(2):pages171–188,2005.<br />
Bézivin,Jean.<strong>Model</strong>drivenengineering:Anemergingtechnicalspace.In<br />
Generative<strong>and</strong>TransformationalTechniquesinS<strong>of</strong>twareEngineering,<br />
InternationalSummerSchool,(GTTSE2005),volume4143<strong>of</strong>Lecture<br />
NotesinComputerScience,pages36–64.Springer-Verlag,2006.<br />
Bézivin,Jean,MikäelBarbero,<strong>and</strong>FrédériqueJouault. Ontheapplicabilityscope<strong>of</strong>modeldrivenengineering.InProceedings<strong>of</strong>the4<br />
th InternationalWorkshopon<strong>Model</strong>-basedMethodologiesforPervasive<strong>and</strong>EmbeddedS<strong>of</strong>tware(MOMPES2007),pages3–7.IEEEComputerSociety,<br />
2007.<br />
Bézivin, Jean <strong>and</strong> Olivier Gerbé. Towards a precise definition <strong>of</strong> the<br />
OMG/MDAframework.InProceedings<strong>of</strong>the16 th AnnualInternational<br />
ConferenceonAutomatedS<strong>of</strong>twareEngineering(ASE2001),pages273–<br />
280.IEEEComputerSociety,2001.<br />
Bézivin,Jean,FrédéricJouault,PeterRosenthal,<strong>and</strong>PatrickValduriez.<br />
<strong>Model</strong>inginthelarge<strong>and</strong>modelinginthesmall.In<strong>Model</strong><strong>Driven</strong>Architecture:<br />
EuropeanMDAWorkshops, volume3599<strong>of</strong>LectureNotesin<br />
ComputerScience,pages33–46.Springer-Verlag,2005.<br />
Bontemps,Yves,PatrickHeymans,<strong>and</strong>Pierre-YvesSchobbens.Fromlive<br />
sequencechartstostatemachines<strong>and</strong>back:Aguidedtour.IEEETransactionsonS<strong>of</strong>twareEngineering,31(12):pages999–1014,2005.<br />
Booch,Grady,AlanBrown,SridharIyengar,JamesRumbaugh,<strong>and</strong>Bran<br />
Selic.AnMDAmanifesto.InFrankel,DavidS.<strong>and</strong>JohnParodi,editors,<br />
TheMDAJournal:<strong>Model</strong><strong>Driven</strong>ArchitectureStraightfromtheMasters,<br />
chapter11.Meghan-KifferPress,2004.
BIBLIOGRAPHY 207<br />
Bosch,Jan.Design&Use<strong>of</strong>S<strong>of</strong>tware<strong>Architectures</strong>:Adopting<strong>and</strong>evolving<br />
aproduct-lineapproach.Addison-Wesley,2000.<br />
Bosch,Jan.Maturity<strong>and</strong>evolutionins<strong>of</strong>twareproductlines:Approaches,<br />
artefacts<strong>and</strong>organization.InProceedings<strong>of</strong>the2 nd InternationalConferenceonS<strong>of</strong>twareProductLines(SPLC2),volume2379<strong>of</strong>LectureNotes<br />
inComputerScience,pages257–271.Springer-Verlag,2002.<br />
Bosch,Jan<strong>and</strong>PeterMolin.S<strong>of</strong>twarearchitecturedesign:evaluation<strong>and</strong><br />
transformation.InProceedings<strong>of</strong>theIEEEConference<strong>and</strong>Workshopon<br />
Engineering<strong>of</strong>Computer-BasedSystems(ECBS’99),pages4–10.IEEE<br />
CS,1999.<br />
Bril,R.J.,R.L.Krikhaar,<strong>and</strong>A.Postma. Architecturalsupportinindustry:<br />
areflectionusingC-POSH. Journal<strong>of</strong>s<strong>of</strong>twaremaintenance<strong>and</strong><br />
evolution:research<strong>and</strong>practice,17:pages3–25,2005.<br />
Bröhl,A.P.<strong>and</strong>W.Dröschel. DasV-<strong>Model</strong>l.DerSt<strong>and</strong>ardfürdieS<strong>of</strong>twareentwicklungmitPraxisleitfaden.Oldenbourg-Verlag,München,2<br />
nd<br />
edition,1995.<br />
Brooks,FrederickP.,Jr.TheMythicalMan-Month.Addison-Wesley,1975.<br />
Buschmann,Frank,RegineMeunier,HansRohnert,PeterSommerlad,<strong>and</strong><br />
MichaelStal.Pattern-orienteds<strong>of</strong>twarearchitecture:asystem<strong>of</strong>patterns.<br />
JohnWiley&Sons,1996.<br />
Buttazzo,G.C. Hardreal-timecomputingsystems:predictablescheduling<br />
algorithms<strong>and</strong>applications.KluwerAcademicPublishers,2002.<br />
Chen,PeterPin-Shan. Theentity-relationshipmodel–towardaunified<br />
view<strong>of</strong>data. ACMTransactionsDatabaseSystems, 1(1):pages9–36,<br />
1976.<br />
Clarke, EdmundM., Jr., OrnaGrumberg, <strong>and</strong>DoranA.Peled. <strong>Model</strong><br />
Checking.MITPress,1999.<br />
Cleavel<strong>and</strong>,J.Craig. Buildingapplicationgenerators. IEEES<strong>of</strong>tware,<br />
5(4):pages25–33,1988.<br />
Clements,Paul,FelixBachmann,LenBass,DavidGarlan,JamesIvers,<br />
ReedLittle,RobertNord,<strong>and</strong>JudithStafford. DocumentingS<strong>of</strong>tware<br />
<strong>Architectures</strong>:Views<strong>and</strong>Beyond.Addison-Wesley,2002a.<br />
Clements,Paul,RickKazman,<strong>and</strong>MarkKlein. EvaluatingS<strong>of</strong>tware<strong>Architectures</strong>.Addison-Wesley,2002b.
208 BIBLIOGRAPHY<br />
Clements,Paul<strong>and</strong>LindaNorthrop.S<strong>of</strong>twareProductLines:Practices<strong>and</strong><br />
Patterns.Addison-Wesley,2002.<br />
Cornelissen,Bas,BasGraaf,<strong>and</strong>LeonMoonen.Identification<strong>of</strong>variation<br />
pointsusingdynamicanalysis. InProceedings<strong>of</strong>the1 st International<br />
WorkshoponReengineeringtowardsProductLines(R2PL2005),pages<br />
9–13.2005.<br />
Cornelissen,Bas,ArievanDeursen,LeonMoonen,<strong>and</strong>AndyZaidman.Visualizingtestsuitestoaidins<strong>of</strong>twareunderst<strong>and</strong>ing.<br />
InProceedings<strong>of</strong><br />
the11 th EuropeanConferenceonS<strong>of</strong>twareMaintenance<strong>and</strong>Reengineering(CSMR2007),pages213–222.IEEEComputerSociety,2007.<br />
Czarnecki,K.<strong>and</strong>S.Helsen.Feature-basedsurvey<strong>of</strong>modeltransformation<br />
approaches.IBMSystemsJournal,45(3):pages621–645,2006.<br />
Czarnecki,Krzyszt<strong>of</strong><strong>and</strong>UlrichW.Eisenecker.GenerativeProgramming:<br />
Methods,Tools,<strong>and</strong>Applications.Addison-Wesley,2000.<br />
Damm,Werner<strong>and</strong>DavidHarel. LSCs: Breathinglifeintomessagesequencecharts.FormalMethodsinSystemDesign,19:pages45–80,2001.<br />
Dash<strong>of</strong>y,EricM.,Andrév<strong>and</strong>erHoek,<strong>and</strong>RichardN.Taylor. Acomprehensiveapproachforthedevelopment<strong>of</strong>modulars<strong>of</strong>twarearchitecture<br />
descriptionlanguages. ACMTransactionsonS<strong>of</strong>twareEngineering<strong>and</strong><br />
Methodology,14(2):pages199–245,2005.<br />
Deelstra,Sybren,MarcoSinnema,<strong>and</strong>JanBosch. Productderivationin<br />
s<strong>of</strong>twareproductfamilies:acasestudy.Journal<strong>of</strong>Systems<strong>and</strong>S<strong>of</strong>tware,<br />
74(2):pages173–194,2005.<br />
Deelstra,Sybren,MarcoSinnema,JillesvanGurp,<strong>and</strong>JanBosch.<strong>Model</strong><br />
drivenarchitectureasapproachtomanagevariabilityins<strong>of</strong>twareproductfamilies.InProceedings<strong>of</strong>theWorkshopon<strong>Model</strong><strong>Driven</strong>Architecture:Foundations<strong>and</strong>Applications(MDAFA2003),numberTR-CTIT-<br />
03-27inCTITTechnicalReport,pages109–114.University<strong>of</strong>Twente,<br />
2003.<br />
Dijkstra,EdsgerW.Thestructure<strong>of</strong>the"THE"-multiprogrammingsystem.<br />
Communications<strong>of</strong>theACM,11(5):pages341–346,1968.<br />
Dijkstra,EdsgerW.Ontherole<strong>of</strong>scientificthought.PublishedinDijkstra<br />
[1982],1974.EWD447.<br />
Dijkstra,EdsgerW.Selectedwritingsoncomputing:apersonalperspective.<br />
Springer-Verlag,1982.
BIBLIOGRAPHY 209<br />
Dinther,Y.van,W.Schijfs,F.v<strong>and</strong>enBerk,<strong>and</strong>K.Rijnierse. Architecturalmodeling:IntroducingtheArchitectureMeta<strong>Model</strong>.<br />
InL<strong>and</strong>elijk<br />
ArchitectuurCongres.SERC,Utrecht,TheNetherl<strong>and</strong>s,2001.<br />
Dobrica,L.<strong>and</strong>E.Niemelä. Asurveyons<strong>of</strong>twarearchitectureanalysis<br />
methods.IEEETransactionsonS<strong>of</strong>twareEngineering,28(7):pages638–<br />
653,2002.<br />
Dohmen,L.A.J.<strong>and</strong>L.JSomers.Experiences<strong>and</strong>lessonslearnedusing<br />
UML-RTtodevelopembeddedprinters<strong>of</strong>tware.InProceedings<strong>of</strong>the4 th<br />
InternationalConferenceonProductFocusedS<strong>of</strong>twareProcessImprovement(PROFES2002),volume2559<strong>of</strong>LectureNotesinComputerScience,<br />
pages475–484.Springer-Verlag,2003.<br />
Doyle,Duncan,HansGeers,BasGraaf,<strong>and</strong>ArievanDeursen.Migrating<br />
adomain-specificmodelinglanguagetoMDAtechnology. InProceedings<strong>of</strong>the3<br />
rd InternationalWorkshoponMetamodels,Schemas,Grammars,<strong>and</strong>OntologiesforReverseEngineering(ateM2006),number1/<br />
2006inMainzerInformatik-Berichte,pages47–54.JohannesGutenberg-<br />
UniversitätMainz,2006.<br />
D’Souza,DesmondFrancis<strong>and</strong>AlanCameronWills.Objects,Components,<br />
<strong>and</strong>FrameworkswithUML:TheCatalysisApproach. Addison-Wesley,<br />
1998.<br />
Eden,A.H.,Y.Hirshfeld,<strong>and</strong>R.Kazman. Abstractionclassesins<strong>of</strong>tware<br />
design.IEEProceedingsS<strong>of</strong>tware,153(4):pages163–182,2006.<br />
Eden,AmnonH.<strong>and</strong>RickKazman.Architecture,design,implementation.<br />
InProceedings<strong>of</strong>the25 th InternationalConferenceonS<strong>of</strong>twareEngineering(ICSE2003),pages149–159.IEEEComputerSociety,2003.<br />
Emam,KhaledEl,Jean-Norm<strong>and</strong>Drouin,<strong>and</strong>WalcelioMelo.TheTheory<br />
<strong>and</strong>Practice<strong>of</strong>S<strong>of</strong>twareProcessImprovement<strong>and</strong>CapabilityDetermination.IEEEComputerSociety,1997.<br />
Endres,Albert<strong>and</strong>DieterRombach.AH<strong>and</strong>book<strong>of</strong>S<strong>of</strong>tware<strong>and</strong>Systems<br />
Engineering.AddisonWesley,2003.<br />
Fahmy,Hoda<strong>and</strong>RichardC.Holt.S<strong>of</strong>twarearchitecturetransformations.<br />
InProceedings<strong>of</strong>the16 th InternationalConferenceonS<strong>of</strong>twareMaintenance(ICSM2000),pages88–96.IEEEComputerSociety,2000a.<br />
Fahmy,Hoda<strong>and</strong>RichardC.Holt. Usinggraphrewritingtospecifys<strong>of</strong>twarearchitecturaltransformations.InProceedings<strong>of</strong>15<br />
th IEEEInternationalConferenceonAutomatedS<strong>of</strong>twareEngineering(ASE2000),pages<br />
187–196.IEEEComputerSociety,2000b.
210 BIBLIOGRAPHY<br />
Favre,Jean-Marie. Foundations<strong>of</strong>meta-pyramids: Languagesvs.metamodels–EpisodeII:Story<strong>of</strong>ThotustheBaboon.InLanguageEngineeringfor<strong>Model</strong>-<strong>Driven</strong>S<strong>of</strong>twareDevelopment,number04101inDagstuhlSeminarProceedings.InternationalesBegegnungs-undForschungszentrumfuerInformatik(IBFI),SchlossDagstuhl,Germany,2005a.<br />
Favre,Jean-Marie. Foundations<strong>of</strong>model(driven)(reverse)engineering:<br />
<strong>Model</strong>s–EpisodeI:Stories<strong>of</strong>TheFidusPapyrus<strong>and</strong><strong>of</strong>TheSolarus.In<br />
LanguageEngineeringfor<strong>Model</strong>-<strong>Driven</strong>S<strong>of</strong>twareDevelopment,number<br />
04101inDagstuhlSeminarProceedings.InternationalesBegegnungsundForschungszentrumfuerInformatik(IBFI),SchlossDagstuhl,Germany,2005b.<br />
Fondement,Frédéric<strong>and</strong>ThomasBaar.Makingmetamodelsaware<strong>of</strong>concretesyntax.<br />
InProceedings<strong>of</strong>the1 st EuropeanConferenceon<strong>Model</strong><br />
<strong>Driven</strong>Architecture-Foundations<strong>and</strong>Applications(ECMDA-FA2005),<br />
volume 3748 <strong>of</strong> Lecture Notes in Computer Science, pages 190–204.<br />
Springer-Verlag,2005.<br />
Forward,Andrew<strong>and</strong>TimothyC.Lethbridge. Therelevance<strong>of</strong>s<strong>of</strong>tware<br />
documentation,tools<strong>and</strong>technologies: asurvey. InProceedings<strong>of</strong>the<br />
2002ACMsymposiumonDocumentengineering(DocEng2002),pages<br />
26–33.ACMPress,2001.<br />
France,Robert<strong>and</strong>BernhardRumpe. <strong>Model</strong>-drivendevelopment<strong>of</strong>complexs<strong>of</strong>tware:Aresearchroadmap.<br />
InFuture<strong>of</strong>S<strong>of</strong>twareEngineering<br />
(FoSE2007),pages37–54.IEEEComputerSociety,2007.<br />
Gallagher,BrianP.Usingthearchitecturetrade<strong>of</strong>fanalysismethodtoevaluateareferencearchitecture:Acasestudy.TechnicalReportCMU/SEI-2000-TN-007,CarnegieMellonUniversity,S<strong>of</strong>twareEngineeringInstitute,2000.<br />
Garlan,David,RobertAllen,<strong>and</strong>JohnOckerbloom. Architecturalmismatchorwhyit’shardtobuildsystemsout<strong>of</strong>existingparts.InProceedings<strong>of</strong>the17<br />
th InternationalConferenceonS<strong>of</strong>twareEngineering(ICSE<br />
1995),pages179–185.ACMPress,1995.<br />
Garlan,David,Shang-WenCheng,<strong>and</strong>AndrewJ.Kompanek. Reconcilingtheneeds<strong>of</strong>architecturaldescriptionwithobject-modelingnotations.<br />
Science<strong>of</strong>ComputerProgramming,44:pages23–49,2002.<br />
Garlan,David,RobertT.Monroe,<strong>and</strong>DavidWile. ACME:architectural<br />
description<strong>of</strong>component-basedsystems. InFoundations<strong>of</strong>componentbasedsystems,pages47–67.CambridgeUniversityPress,2000.
BIBLIOGRAPHY 211<br />
Garlan,David<strong>and</strong>MaryShaw. Anintroductiontos<strong>of</strong>twarearchitecture.<br />
InAdvancesinS<strong>of</strong>twareEngineering<strong>and</strong>KnowledgeEngineering,volume2,pages1–39.WorldScientificPublishingCompany,1993.<br />
Gerber,Anna,MichaelLawley,KerryRaymond,JimSteel,<strong>and</strong>Andrew<br />
Wood.Transformation:Themissinglink<strong>of</strong>MDA.InProceedings<strong>of</strong>the<br />
1 st InternationalConferenceonGraphTransformation(ICGT2002),volume2505<strong>of</strong>LectureNotesinComputerScience,pages90–105.Springer-<br />
Verlag,2002.<br />
Gohari,P.<strong>and</strong>W.M.Wonham.Reducedsupervisorsfortimeddiscrete-event<br />
systems. IEEETransactionsonAutomaticControl,48(7):pages1187–<br />
1198,2003.<br />
Graaf, Bas. <strong>Model</strong>-drivenevolution<strong>of</strong>s<strong>of</strong>twarearchitectures. InProceedings<strong>of</strong>the11<br />
th EuropeanConferenceonS<strong>of</strong>twareMaintenance<strong>and</strong><br />
Reengineering(CSMR2007),pages357–360.IEEEComputerSociety,<br />
2007.<br />
Graaf,Bas,MarcoLormans,<strong>and</strong>HansToetenel. S<strong>of</strong>twaretechnologies<br />
forembeddedsystems:Anindustryinventory. InProceedings<strong>of</strong>the4 th<br />
InternationalConferenceonProductFocusedS<strong>of</strong>twareProcessImprovement(PROFES2002),volume2559<strong>of</strong>LectureNotesinComputerScience,<br />
pages453–465.Springer-Verlag,2002.<br />
Graaf,Bas,MarcoLormans,<strong>and</strong>HansToetenel. Embeddeds<strong>of</strong>twareengineering:Thestate<strong>of</strong>thepractice.<br />
IEEES<strong>of</strong>tware,20(6):pages61–69,<br />
2003.<br />
Graaf,Bas<strong>and</strong>ArievanDeursen. <strong>Model</strong>-drivenconsistencychecking<strong>of</strong><br />
behaviouralspecifications.InProceedings<strong>of</strong>the4 th InternationalWorkshopon<strong>Model</strong>-basedMethodologiesforPervasive<strong>and</strong>EmbeddedS<strong>of</strong>tware(MOMPES2007),pages115–126.IEEEComputerSociety,2007a.<br />
Graaf,Bas<strong>and</strong>ArievanDeursen. UsingMDEforgenericcomparison<strong>of</strong><br />
views. InProceedings<strong>of</strong>the4 th InternationalWorkshopon<strong>Model</strong>Design,Verification<strong>and</strong>Validation(MoDeVVa2007),pages57–66.INRIA,<br />
2007b.<br />
Graaf,Bas<strong>and</strong>ArievanDeursen. Visualisation<strong>of</strong>domain-specificmodellinglanguagesusingUML.<br />
InProceedings<strong>of</strong>the14 th AnnualIEEE<br />
InternationalConference<strong>and</strong>WorkshopontheEngineering<strong>of</strong>Computer<br />
BasedSystems(ECBS2007),pages586–595.IEEEComputerSociety,<br />
2007c.
212 BIBLIOGRAPHY<br />
Graaf,Bas,HylkevanDijk,<strong>and</strong>ArievanDeursen. Evaluatinganembeddeds<strong>of</strong>twarereferencearchitecture–industrialexperiencereport.<br />
InProceedings<strong>of</strong>the9 th EuropeanConferenceonS<strong>of</strong>twareMaintenance<br />
<strong>and</strong>Reengineering(CSMR2005),pages354–363.IEEEComputerSociety,2005.<br />
Graaf,Bas,SvenWeber,<strong>and</strong>ArievanDeursen. Migratingsupervisory<br />
controlarchitecturesusingmodeltransformations.InProceedings<strong>of</strong>the<br />
10thEuropeanConferenceonS<strong>of</strong>twareMaintenance<strong>and</strong>Reengineering<br />
(CSMR2006),pages151–160.IEEEComputerSociety,2006.<br />
Graaf,Bas,SvenWeber,<strong>and</strong>ArievanDeursen. <strong>Model</strong>-drivenmigration<br />
<strong>of</strong>supervisorymachinecontrolarchitectures. Journal<strong>of</strong>Systems<strong>and</strong><br />
S<strong>of</strong>tware,2007.Doi:10.1016/j.jss.2007.06.007.<br />
Gray,Jeff,JingZhang,SumanRoychoudhury,HuiWu,RajeshSudarsan,<br />
Aniruddha,S<strong>and</strong>eepNeema,FengShi,<strong>and</strong>TedBapty. <strong>Model</strong>-driven<br />
programtransformation<strong>of</strong>alargeavionicsframework.InProceedings<strong>of</strong><br />
the3 rd InternationalConferenceonGenerativeProgramming<strong>and</strong>ComponentEngineering(GPCE2004),pages361–378.Springer-Verlag,2004.<br />
Greenfield,Jack,KeithShort,SteveCook,<strong>and</strong>StuartKent.S<strong>of</strong>twareFactories:AssemblingApplicationswithPatterns,<strong>Model</strong>s,Frameworks,<strong>and</strong><br />
Tools.JohnWiley&Sons,2004.<br />
Grose,TimothyJ.,GaryC.Doney,<strong>and</strong>PhD.StephanA.Brodsky.Mastering<br />
XMI.JavaprogrammingwithXMI,XML,<strong>and</strong>UML.JohnWiley&Sons,<br />
2002.<br />
Han,Minmin,ChristineH<strong>of</strong>meister,<strong>and</strong>RobertL.Nord. Reconstructing<br />
s<strong>of</strong>twarearchitectureforJ2EEwebapplications. InProceedings<strong>of</strong>the<br />
10thWorkingConferenceonReverseEngineering(WCRE2003),pages<br />
67–78.IEEEComputerSociety,2003.<br />
Hatley,DerekJ.<strong>and</strong>ImtiazA.Pirbhai. StrategiesforReal-TimeSystem<br />
Specification.DorsetHousePublishing,1987.<br />
H<strong>of</strong>meister, C., R. Nord, <strong>and</strong> D. Soni. Applied S<strong>of</strong>tware Architecture.<br />
Addison-Wesley,1999.<br />
H<strong>of</strong>meister,Christine,PhilipeKruchten,RobertL.Nord,HenkObbink,<br />
Alex<strong>and</strong>erRan,<strong>and</strong>PierreAmerica. Generalizingamodel<strong>of</strong>s<strong>of</strong>tware<br />
architecturedesignfromfiveindustrialapproaches. InProceedings<strong>of</strong><br />
the5 th WorkingIEEE/IFIPConferenceonS<strong>of</strong>twareArchitecture(WICSA<br />
2005),pages77–88.IEEEComputerSociety,2005.
BIBLIOGRAPHY 213<br />
Horowitz,Ellis,AlfonsKemper,<strong>and</strong>BalajiNarasimhan.Asurvey<strong>of</strong>applicationgenerators.IEEES<strong>of</strong>tware,2(1):pages40–54,1985.<br />
Humphrey,WattsS.Managingthes<strong>of</strong>twareprocess.Addison-Wesley,1989.<br />
IEEE-1219. IEEEst<strong>and</strong>ardfors<strong>of</strong>twaremaintenance. IEEEStd1219–<br />
1998,1998.<br />
IEEE-1471. IEEErecommendedpracticeforarchitecturaldescription<strong>of</strong><br />
s<strong>of</strong>twareintensivesystems.IEEEStd1471–2000,2000.<br />
Jacobson,Ivar. Object-OrientedS<strong>of</strong>twareEngineering:AUseCase<strong>Driven</strong><br />
Approach.Addison-Wesley,1992.<br />
Jacobson,Ivar,GradyBooch,<strong>and</strong>JamesRumbaugh.TheUnifiedS<strong>of</strong>tware<br />
DevelopmentProcess.Addison-Wesley,1999.<br />
Jacobson,Ivar,MartinGriss,<strong>and</strong>PatrickJonsson.S<strong>of</strong>twareReuse:Architecture,Process<strong>and</strong>OrganizationforBusinessSuccess.Addison-Wesley,<br />
1997.<br />
Jansen,Anton.S<strong>of</strong>twarearchitectureasaset<strong>of</strong>architecturaldesigndecisions.InProceedings<strong>of</strong>the5<br />
th WorkingIEEE/IFIPConferenceonS<strong>of</strong>twareArchitecture(WICSA2005),pages109–120.IEEEComputerSociety,2005.<br />
Jouault,Frédéric<strong>and</strong>IvanKurtev.TransformingmodelswithATL.InProceedings<strong>of</strong>the<strong>Model</strong>TransformationsinPracticeWorkshopatMoDELS<br />
2005.2005.<br />
Kazman,Rick,GregoryAbowd,LenBass,<strong>and</strong>PaulClements. Scenariobasedanalysis<strong>of</strong>s<strong>of</strong>twarearchitecture.IEEES<strong>of</strong>tware,13(6):pages47–<br />
55,1996.<br />
Kazman,Rick,LenBass,<strong>and</strong>MarkKlein. Theessentialcomponents<strong>of</strong><br />
s<strong>of</strong>twarearchitecturedesign<strong>and</strong>analysis.Journal<strong>of</strong>Systems<strong>and</strong>S<strong>of</strong>tware,79(8):pages1207–1216,2006.<br />
Kazman, Rick, LenBass, MikeWebb, <strong>and</strong>GregoryAbowd. SAAM:A<br />
methodforanalyzingtheproperties<strong>of</strong>s<strong>of</strong>twarearchitectures. InProceedings<strong>of</strong>the16<br />
th InternationalConferenceonS<strong>of</strong>twareEngineering.<br />
ICSE1994,pages81–90.IEEEComputerSociety,1994.<br />
Kitchenham,Barbara,LesleyPickard,<strong>and</strong>ShariLawrencePfleeger.Case<br />
studiesformethod<strong>and</strong>toolevaluation.IEEES<strong>of</strong>tware,12(4):pages52–<br />
62,1995.
214 BIBLIOGRAPHY<br />
Klein, Mark H., Rick Kazman, Len Bass, Jeromy Carrierea, Mario<br />
Barbacci,<strong>and</strong>HowardLipson. Attribute-basedarchitecturestyles. In<br />
Proceedings<strong>of</strong>the1 st WorkingIFIPConferenceonS<strong>of</strong>twareArchitecture<br />
(WICSA2001),pages225–243.1999.<br />
Kleppe,Anneke,JosWarmer,<strong>and</strong>WimBast.MDAExplained:The<strong>Model</strong><br />
<strong>Driven</strong>Architecture:Practice<strong>and</strong>Promise.AddisonWesley,2003.<br />
Klint,Paul. Ameta-environmentforgeneratingprogrammingenvironments.ACMTransactionsonS<strong>of</strong>twareEngineering,2(2):pages176–201,<br />
1993.<br />
Klint, Paul,RalfLämmel,<strong>and</strong>ChrisVerhoef. Towardsanengineering<br />
disciplineforgrammarware.TransactionsonS<strong>of</strong>twareEngineering<strong>and</strong><br />
Methodology,14(3):pages331–380,2005.<br />
Kobryn,Cris. UML2001:ast<strong>and</strong>ardizationodyssey. Communications<strong>of</strong><br />
theACM,42(10):pages29–37,1999.<br />
Krikhaar,RenéL.S<strong>of</strong>twarearchitectureReconstruction.Ph.D.thesis,UniversiteitvanAmsterdam,1999.<br />
Kruchten,Philipe,HenkObbink,<strong>and</strong>JudithStafford. Thepast,present,<br />
<strong>and</strong>future<strong>of</strong>s<strong>of</strong>twarearchitecture. IEEES<strong>of</strong>tware,23(2):pages22–30,<br />
2006.<br />
Kruchten,PhilippeB.The4+1viewmodel<strong>of</strong>architecture.IEEES<strong>of</strong>tware,<br />
12(6):pages42–50,1995.<br />
Kruchten,Phillipe.TheRationalUnifiedProcess.Addison-Wesley,1998.<br />
Krueger,CharlesW.S<strong>of</strong>twarereuse.ACMComputingSurveys,24(2):pages<br />
131–183,1992.<br />
Kurtev, Ivan, Jean Bézivin, <strong>and</strong> Mehmet Aksit. Technological spaces:<br />
aninitialappraisal. InConfederatedInternationalConferencesCoopIS,<br />
DOA,<strong>and</strong>ODBASE2002,IndustrialTrack.Springer-Verlag,2002.<br />
Kuvaja, Pasi, Jouni Similä, Lech Krzanik, Adriana Bicego, Samuli<br />
Saukkonen,<strong>and</strong>GünterKoch. S<strong>of</strong>twareProcessAssessment<strong>and</strong>Improvement:TheBOOTSTRAPApproach.BlackwellPublishers,1994.<br />
Lam,VitusS.W.<strong>and</strong>JulianPadget. Analyzingequivalences<strong>of</strong>UMLstatechartdiagramsbystructuralcongruence<strong>and</strong>openbisimulations.<br />
In<br />
Proceedings<strong>of</strong>the2003IEEESymposiaonHumanCentricComputing<br />
Languages<strong>and</strong>Environments(HCC2003),pages137–144.IEEEComputerSociety,2003.
BIBLIOGRAPHY 215<br />
Lange,ChristianF.J.,MichelR.V.Chaudron,<strong>and</strong>JohanMuskens.Inpractice:UMLs<strong>of</strong>twarearchitecture<strong>and</strong>designdescription.IEEES<strong>of</strong>tware,<br />
23(2):pages40–46,2006.<br />
Lehman,M.M. Laws<strong>of</strong>programevolution-rules<strong>and</strong>toolsforprogrammingmanagement.InProceedings<strong>of</strong>theInfotechState<strong>of</strong>theArtConference,WhyS<strong>of</strong>twareProjectsFail?,pages11/1–11/25.1978.Reprintedas<br />
Chapter12in[Lehman<strong>and</strong>Belady,1985].<br />
Lehman,M.M.<strong>and</strong>L.A.Belady,editors. Programevolution:processes<strong>of</strong><br />
s<strong>of</strong>twarechange.AcademicPress,1985.<br />
Lehman,MeirM. Programs,lifecycles,<strong>and</strong>laws<strong>of</strong>s<strong>of</strong>twareevolution.<br />
IEEEProceedings,68(9):pages1060–1076,1980.<br />
Liang,Hongzhi,JuergenDingel,<strong>and</strong>ZinovyDiskin.Acomparativesurvey<br />
<strong>of</strong>scenario-basedtostate-basedmodelsynthesisapproaches.InProceedings<strong>of</strong>the5<br />
th InternationalWorkshoponScenarios<strong>and</strong>StateMachines:<br />
<strong>Model</strong>s,Algorithms<strong>and</strong>Tools(SCESM2006),pages5–11.ACM,2006.<br />
Lientz,B.P.,E.B.Swanson,<strong>and</strong>G.E.Tompkins.Characteristics<strong>of</strong>applications<strong>of</strong>twaremaintenance.<br />
Communications<strong>of</strong>theACM,21(6):pages<br />
466–471,1978.<br />
Liu,C.L.<strong>and</strong>JamesW.Layl<strong>and</strong>.Schedulingalgorithmsformultiprogramminginahardreal-timeenvironment.<br />
Journal<strong>of</strong>theAssociationfor<br />
ComputingMachinery,20(1):pages46–61,1973.<br />
Lundell,Björn,BrianLings,AnnaPersson,<strong>and</strong>AndersMattsson. UML<br />
modelinterchangeinheterogeneoustoolenvironments: Ananalysis<strong>of</strong><br />
adoptions<strong>of</strong>XMI2. InProceedings<strong>of</strong>the9 th InternationalConference<br />
on<strong>Model</strong><strong>Driven</strong>EngineeringLanguages<strong>and</strong>Systems(MoDELS2006),<br />
number4199inLectureNotesinComputerScience, pages619–630.<br />
Springer-Verlag,2006.<br />
Lutz,RobynR.<strong>and</strong>GeraldC.Gannod.Analysis<strong>of</strong>as<strong>of</strong>twareproductline<br />
architecture:anexperiencereport.TheJournal<strong>of</strong>Systems<strong>and</strong>S<strong>of</strong>tware,<br />
66(3):pages253–267,2003.<br />
Medvidovic,Nenad,DavidS.Rosenblum,DavidF.Redmiles,<strong>and</strong>JasonE.<br />
Robbins.<strong>Model</strong>ingS<strong>of</strong>tware<strong>Architectures</strong>intheUnified<strong>Model</strong>ingLanguage.<br />
ACMTransactionsonS<strong>of</strong>twareEngineering<strong>and</strong>Methodology,<br />
11(1):pages2–57,2002.<br />
Medvidovic,Nenad<strong>and</strong>RichardN.Taylor. Aframeworkforclassifying<br />
<strong>and</strong>comparingarchitecturedescriptionlanguages.InESEC’97/FSE-5:
216 BIBLIOGRAPHY<br />
Proceedings<strong>of</strong>the6 th Europeanconferenceheldjointlywiththe5 th ACM<br />
SIGSOFTinternationalsymposiumonFoundations<strong>of</strong>s<strong>of</strong>twareengineering,pages60–76.Springer-Verlag,1997.<br />
Mellor,StephenJ.,AnthonyM.Clark,<strong>and</strong>TakaoFutagami.Guesteditors’<br />
introduction: <strong>Model</strong>-drivendevelopment. IEEES<strong>of</strong>tware,20(5):pages<br />
14–18,2003.<br />
Mens,Kim. AutomatingArchitecturalConformanceCheckingbymeans<strong>of</strong><br />
LogicMetaProgramming.Ph.D.thesis,VrijeUniversiteitBrussel,2000.<br />
Mens,Tom<strong>and</strong>PietervanGorp. Ataxonomy<strong>of</strong>modeltransformation.<br />
ElectronicNotesinTheoreticalComputerScience,152:pages125–142,<br />
2006.<br />
Mernik, Marjan, Jan Heering, <strong>and</strong> Anthony M. Sloane. When <strong>and</strong><br />
howtodevelopdomain-specificlanguages. ACMComputingSurveys,<br />
37(4):pages316–344,2005.<br />
Monroe, R.T., A.Kompanek, <strong>and</strong>D.Melton, R.;Garlan. Architectural<br />
styles,designpatterns,<strong>and</strong>objects. IEEES<strong>of</strong>tware,14(1):pages43–52,<br />
1997.<br />
Murphy,GailC.,DavidNotkin,<strong>and</strong>KevinSullivan. S<strong>of</strong>twarereflexion<br />
models: bridgingthegapbetweensource<strong>and</strong>high-levelmodels. In<br />
SIGSOFT’95: Proceedings <strong>of</strong> the 3 rd ACMSIGSOFT symposium on<br />
Foundations<strong>of</strong>s<strong>of</strong>twareengineering,pages18–28.ACMPress,1995.<br />
Olum<strong>of</strong>in, FemiG.<strong>and</strong>VojislavB.Mišlić. ExtendingtheATAMarchitectureevaluationtoproductlinearchitectures.InProceedings<strong>of</strong>the5<br />
th<br />
WorkingIEEE/IFIPConferenceonS<strong>of</strong>twareArchitecture(WICSA2005),<br />
pages45–56.IEEEComputerSociety,2006.<br />
OMG. Meta Object Facility (MOF) 2.0 Query/View/Transformation<br />
Specification.FinalAdoptedSpecification. http://www.omg.org/docs/ptc/<br />
05-11-01.pdf,2005.<br />
OMG. OMGUnified<strong>Model</strong>ingLanguageSpecification,Version1.4. http:<br />
//www.omg.org/docs/formal/01-09-67.pdf,2007a.<br />
OMG. Unified<strong>Model</strong>ingLanguage: Superstructure,version2.1.1. http:<br />
//www.omg.org/docs/formal/07-02-05.pdf,2007b.<br />
Parnas,D.L.Onthecriteriatobeusedindecomposingsystemsintomodules.Communications<strong>of</strong>theACM,15(12):pages1053–1058,1972.
BIBLIOGRAPHY 217<br />
Partsch,H.<strong>and</strong>R.Steinbrüggen.Programtransformationsystems.ACM<br />
ComputingSurveys,15(3):pages199–236,1983.<br />
Perry, Dewayne E. <strong>and</strong> Alex<strong>and</strong>er L. Wolf. Foundations for the study<br />
<strong>of</strong>s<strong>of</strong>twarearchitecture. ACMSIGSOFTS<strong>of</strong>twareEngineeringNotes,<br />
17(4):pages40–52,1992.<br />
Pigoski,ThomasM. PracticalS<strong>of</strong>twareMaintenance: BestPracticesfor<br />
ManagingYourS<strong>of</strong>twareInvestment.JohnWiley&Sons,1996.<br />
Potts, Colin. S<strong>of</strong>twareengineeringresearchrevisited. IEEES<strong>of</strong>tware,<br />
10(5):pages19–28,1993.<br />
Poulin,J.S. MeasuringS<strong>of</strong>twareReuse: Principles,Practices,<strong>and</strong>Economic<strong>Model</strong>s.Addison-Wesley,1997.<br />
Ramadge,P.J.<strong>and</strong>W.M.Wonham.Supervisorycontrol<strong>of</strong>aclass<strong>of</strong>discrete<br />
eventprocesses.SIAMJournalonControl<strong>and</strong>Optimization,25(1):pages<br />
206–230,1987.<br />
Reveliotis,SpyrosA. Real-TimeManagement<strong>of</strong>ResourceAllocationSystems.ADiscreteEventSystemsApproach,volume79<strong>of</strong>InternationalSeriesinOperationsResearch&ManagementScience.<br />
Springer-Verlag,<br />
2005.<br />
Sabuncuoglu,I.<strong>and</strong>M.Bayiz. Analysis<strong>of</strong>reactiveschedulingproblems<br />
inajob-shopenvironment. EuropeanJournal<strong>of</strong>operationalresearch,<br />
126:pages567–586,2000.<br />
Schäfer,Timm,Alex<strong>and</strong>erKnapp,<strong>and</strong>StephanMerz.<strong>Model</strong>checkingUML<br />
statemachines<strong>and</strong>collaborations.ElectronicNotesinTheoreticalComputerScience,55(3):pages357–369,2001.<br />
Schmidt, Douglas C. <strong>Model</strong>-driven engineering. IEEE Computer,<br />
39(2):pages25–31,2006.<br />
Seidewitz,Ed. Whatmodelsmean. IEEES<strong>of</strong>tware,20(5):pages26–32,<br />
2003.<br />
Selic,Bran.Thepragmatics<strong>of</strong>model-drivendevelopment.IEEES<strong>of</strong>tware,<br />
20(5):pages14–25,2003.<br />
Selic,Bran,GarthGullekson,<strong>and</strong>PaulT.Ward.Real-TimeObject-Oriented<br />
<strong>Model</strong>ing.JohnWiley&Sons,1994.<br />
Sendall,Shane.<strong>Model</strong>transformation:Theheart<strong>and</strong>soul<strong>of</strong>model-driven<br />
s<strong>of</strong>twaredevelopment.IEEES<strong>of</strong>tware,20(5):pages42–45,2003.
218 BIBLIOGRAPHY<br />
Shaw,Mary,RobertDeLine,DanielV.Klein,TheodoreL.Ross,DavidM.<br />
Young, <strong>and</strong>GregoryZelesnik. Abstarctionsfors<strong>of</strong>twarearchitecture<br />
<strong>and</strong>toolstosupportthem.IEEETransactionsonS<strong>of</strong>twareEngineering,<br />
21(4):pages314–335,1995.<br />
Shaw,Mary<strong>and</strong>DavidGarlan. S<strong>of</strong>twareArchitecture:Perspectivesonan<br />
EmergingDiscipline.PrenticeHall,1996.<br />
S<strong>of</strong>tware Engineering Institute. Published s<strong>of</strong>tware architecture definitions.http://www.sei.cmu.edu/architecture/published_definitions.html,<br />
2006.<br />
Soni,D.,R.L.Nord,<strong>and</strong>C.H<strong>of</strong>meister. S<strong>of</strong>twarearchitectureinindustrialapplications.InProceedings<strong>of</strong>the17<br />
th InternationalConferenceon<br />
S<strong>of</strong>twareEngineering(ICSE1995).ACMPress,1995.<br />
Sonnenberg,C.J.Improvings<strong>of</strong>twaremaintainability:Acasestudy.Master’sthesis,TechnischeUniversiteitEindhoven,2005.<br />
Spanjers, Hans, Maarten ter Huurne, Dan Bendas, Bas Graaf, Marco<br />
Lormans,<strong>and</strong>RinivanSolingen. Toolsupportfordistributeds<strong>of</strong>tware<br />
engineering.InProceedings<strong>of</strong>the1 st InternationalConferenceonGlobal<br />
S<strong>of</strong>twareEngineering(ICGSE2006),pages187–198.IEEEComputerSociety,2006.<br />
Stevens,Perdita. OnassociationsintheUnified<strong>Model</strong>lingLanguage. In<br />
Proceedings<strong>of</strong>the4 th InternationalConferenceontheUnified<strong>Model</strong>ing<br />
Language,<strong>Model</strong>ingLanguages,Concepts,<strong>and</strong>Tools(≪UML≫2001),<br />
volume2185<strong>of</strong>LectureNotesinComputerScience.2001.<br />
Swanson,E.Burton. Thedimensions<strong>of</strong>maintenance. InProceedings2 nd<br />
InternationalConferenceonS<strong>of</strong>twareEngineering(ICSE1976),pages<br />
492–497.IEEEComputerSociety,1976.<br />
Terekhov,AndreyA.<strong>and</strong>ChrisVerhoef. Therealities<strong>of</strong>languageconversions.IEEES<strong>of</strong>tware,17(6):pages111–124,2000.<br />
PROGRESS. Embeddedsystemsroadmap2002: Visiononthetechnology<br />
forthefuture<strong>of</strong>PROGRESS. Technicalreport,TechnologyFoundation<br />
(STW),2002.http://www.stw.nl/Programmas/Progress/ESroadmap.htm.<br />
Van den Br<strong>and</strong>, M.G.J., A. van Deursen, J. Heering, H.A. de Jong,<br />
M.deJonge,T.Kuipers,P.Klint,L.Moonen,P.A.Olivier,J.Scheerder,<br />
J.J.Vinju,E.Visser,<strong>and</strong>J.Visser. TheASF+SDFmeta-environment:<br />
Acomponent-basedlanguagedevelopmentenvironment. InProceedings<strong>of</strong>the10thInternationalConferenceonCompilerConstruction(CC
BIBLIOGRAPHY 219<br />
2001),volume2027<strong>of</strong>LectureNotesinComputerScience,pages365–370.<br />
Springer-Verlag,2001.<br />
V<strong>and</strong>enNieuwelaar,N.J.M. SupervisoryMachineControlbyPredictive-<br />
ReactiveScheduling. Ph.D.thesis,TechnischeUniversiteitEindhoven,<br />
2004.<br />
V<strong>and</strong>enNieuwelaar,N.J.M.,J.M.v<strong>and</strong>eMortel-Fronczak,<strong>and</strong>J.E.Rooda.<br />
Design <strong>of</strong> supervisory machine control. In Glover, Keith <strong>and</strong> Jan<br />
Maciejowski, editors, Proceedings<strong>of</strong>theEuropeanControlConference<br />
ECC2003.2003.<br />
V<strong>and</strong>erAalst,Wil,TonWeijters,<strong>and</strong>LauraMaruster. Workflowmining:Discoveringprocessmodelsfromeventlogs.<br />
IEEETransactionson<br />
Knowledge<strong>and</strong>DataEngineering,16(9):pages1128–1142,2004.<br />
VanDeursen, A., C.H<strong>of</strong>meister, R.Koschke, L.Moonen, <strong>and</strong>C.Riva.<br />
Symphony: View-drivens<strong>of</strong>twarearchitecturereconstruction. InProceedings<strong>of</strong>the4<br />
th WorkingIEEE/IFIPConferenceonS<strong>of</strong>twareArchitecture(WICSA4),pages122–134.IEEEComputerSociety,2004.<br />
VanDeursen,Arie.Des<strong>of</strong>tware-evolutieparadox.http://homepages.cwi.nl/<br />
~arie/intreerede/,2005.InaugurallectureDelftUniversity<strong>of</strong>Technology.<br />
VanDeursen,Arie,JanHeering,<strong>and</strong>PaulKlint,editors.LanguagePrototyping:AnAlgebraicSpecificationApproach,volume5<strong>of</strong>AMASTSeries<br />
inComputing.WorldScientificPublishingCo.,1996.<br />
VanDeursen,Arie<strong>and</strong>PaulKlint. Littlelanguages:Littlemaintenance?<br />
Journal<strong>of</strong>S<strong>of</strong>twareMaintenance:Research<strong>and</strong>Practice,10(2):pages75–<br />
92,1998.<br />
VanDeursen, Arie, PaulKlint, <strong>and</strong>JoostVisser. Domain-specificlanguages:Anannotatedbibliography.ACMSIGPLANNotices,35(6):pages<br />
26–36,2000.<br />
VanDeursen,Arie<strong>and</strong>JoostVisser. SourcemodelanalysisusingtheJJ-<br />
Travelervisitorcombinatorframework. S<strong>of</strong>tware:Practice<strong>and</strong>Experience,34(14):pages1345–1379,2004.<br />
VanDijk,HylkeW.,BasGraaf,<strong>and</strong>RobBoerman.Onthesystematicconformancecheck<strong>of</strong>s<strong>of</strong>twareartefacts.InProceedings<strong>of</strong>the2<br />
nd European<br />
WorkshoponS<strong>of</strong>twareArchitecture(EWSA2005),volume3047<strong>of</strong>Lecture<br />
NotesonComputerScience,pages203–221.Springer-Verlag,2005.<br />
VanGenuchten,Michiel.Theimpact<strong>of</strong>s<strong>of</strong>twaregrowthontheelectronics<br />
industry.IEEEComputer,40(1):pages106–108,2007.
220 BIBLIOGRAPHY<br />
VanOmmering,Rob,Frankv<strong>and</strong>erLinden,JeffKramer,<strong>and</strong>JeffMagee.<br />
TheKoalacomponentmodelforconsumerelectronicss<strong>of</strong>tware. IEEE<br />
Computer,33(3):pages78–85,2000.<br />
Viennot,GérardXavier.Heaps<strong>of</strong>pieces,I:Basicdefinitions<strong>and</strong>combinatoriallemmas.InProceedings<strong>of</strong>theColloquedecombinatoireénumérative(UQAM1985),Montreal,Canada,volume1234<strong>of</strong>LectureNotesin<br />
Mathematics,pages321–350.Springer-Verlag,1986.<br />
Visser,Eelco. Programtransformationwithstratego/xt:Rules,strategies,<br />
tools,<strong>and</strong>systemsinstratego/xt0.9. InDomain-SpecificProgramGeneration,number3016inLectureNotesinComputerScience,pages216–<br />
238.Springer-Verlag,2004.<br />
Wang,Yingxu,GrahamKing,HakanWickberg,<strong>and</strong>AlecDorling.Whatthe<br />
s<strong>of</strong>twareindustrysaysaboutthepracticesmodelledincurrents<strong>of</strong>tware<br />
processmodels? InProceedings<strong>of</strong>the25 th EUROMICROConference,<br />
volume2,pages162–168.IEEEComputerSociety,1999.<br />
Whittle,Jon<strong>and</strong>JohannSchumann. Generatingstatechartdesignsfrom<br />
scenarios. InProceedings<strong>of</strong>the22 nd InternationalConferenceonS<strong>of</strong>twareEngineering(ICSE2000),pages314–323.IEEEComputerSociety,<br />
2000.<br />
Wirth,Niklaus.Programdevelopmentbystepwiserefinement.Communications<strong>of</strong>theACM,14(4):pages221–227,1971.<br />
Yin,RobertK. CaseStudyResearch:Design<strong>and</strong>Methods. SagePublications,2003.
Summary<br />
Twowell-knowns<strong>of</strong>twareengineeringlawsstatethat1)s<strong>of</strong>twarehasto<br />
bechangedconstantlyinresponsetonewuserrequirementsorachanged<br />
environment,thatis,s<strong>of</strong>twareevolvescontinuously<strong>and</strong>2)s<strong>of</strong>twarethat<br />
ischanged,becomesmorecomplicated. Theconsequence<strong>of</strong>thistrend<strong>of</strong><br />
increasingcomplexityisthatthemaintainability<strong>of</strong>s<strong>of</strong>twaresystemsdecreasesovertime:<br />
itbecomesmore<strong>and</strong>moredifficulttomakechanges.<br />
Thecomplexity<strong>of</strong>as<strong>of</strong>twaresystemisforalargepartdeterminedbyits<br />
structure,<strong>of</strong>tenreferredtoasarchitecture.Thisthesisfocusesontheevolution<strong>of</strong>s<strong>of</strong>twarearchitectures.Thistype<strong>of</strong>evolution,whilecommon,comes<br />
withaconsiderablerisk<strong>and</strong>cost.Ouraimistoreducethisrisk<strong>and</strong>cost.<br />
Twoobviousstrategiestoremedytheproblem<strong>of</strong>reducedmaintainability<strong>of</strong>s<strong>of</strong>twaresystemsare:1)applytechniquestomanagetheincreasing<br />
complexity,or2)applytechniquestoreducethecomplexity. Automation<br />
<strong>and</strong>abstractionaretwobasics<strong>of</strong>twareengineeringtechniquestosupport<br />
thesestrategies. Inthisthesisweinvestigatedtheapplicability<strong>of</strong>technologiesforanewapproach<strong>of</strong>s<strong>of</strong>twaredevelopment,basedonautomation<br />
<strong>and</strong>abstraction,tosupporttheevolution<strong>of</strong>s<strong>of</strong>twarearchitectures. This<br />
newapproachisreferredtoasmodel-drivens<strong>of</strong>twaredevelopment.<br />
Themainresearchquestionaddressedinthisworkis: Howcanevolution<strong>of</strong>s<strong>of</strong>twarearchitecturebesupported?<br />
Weclarifiedthescope<strong>of</strong>our<br />
workbydefiningthreerelatedsubquestionsthatdealwithintegration<strong>of</strong><br />
evolutionsupportinindustrialpractice,theimplication<strong>of</strong>theuse<strong>of</strong>productlineprinciplesontheevolutionsupport,<strong>and</strong>theautomation<strong>of</strong>evolutionsupportusingmodel-drivens<strong>of</strong>twaredevelopmenttechniques.Togetabetterunderst<strong>and</strong>ing<strong>of</strong>theuses<strong>of</strong>twareengineeringtechnologiesfordifferenttypes<strong>of</strong>tasksinindustry,westartedbyconductingasurvey.Inthissurveyweaskeds<strong>of</strong>twarepractitioners<strong>of</strong>eights<strong>of</strong>twaredevelopmentorganisationsaboutthes<strong>of</strong>twareengineeringtechnologiesthey<br />
use. Wealsopaidattentiontothesituationinwhichcertaintechnologies<br />
areapplied<strong>and</strong>potentialproblems. Thetrendsweobservedduringthis<br />
surveyinclude:theuse<strong>of</strong>product-lineapproaches,theinformaluse<strong>of</strong>mod-<br />
221
222 Summary<br />
elling<strong>and</strong>theimportance<strong>of</strong>theevolutionaryaspect<strong>of</strong>s<strong>of</strong>tware(i.e.,s<strong>of</strong>twareisseldomdevelopedfromscratch).<br />
Partlytheresults<strong>of</strong>thissurvey<br />
motivatedtheaforementionedresearchquestions.<br />
Then,bycasestudiesatOcé<strong>and</strong>ASML,weinvestigatedhowtheevolution<strong>of</strong>s<strong>of</strong>twarearchitecturescanbesupported.Inparticularweconsidered<br />
fourtypes<strong>of</strong>s<strong>of</strong>twareengineeringtasksrelatedtos<strong>of</strong>twareevolution<br />
EvaluationAfirststepwhenperformingchangestoas<strong>of</strong>twaresystem,<br />
istheevaluation<strong>of</strong>whetherthesechangescanberealisedwithinthe<br />
currentarchitecture.Here,wemainlyinvestigatedhowsuchanevaluationcanbeconductedinthecontext<strong>of</strong>as<strong>of</strong>twareproductline.<br />
ConformancecheckingWhenanarchitecturehastobechangeditis<br />
usefultoknowtoextenttowhichitisconsistentwithotherdevelopmentartefacts.Wefocusedonhowmodel-drivens<strong>of</strong>twaredevelopmenttechnologiescanbeappliedtoanswerthatquestion.<br />
MigrationWeinvestigatedhowanactualmigrationcanbepartlyautomatedbytheuse<strong>of</strong>modeltransformations.<br />
DocumentationAdisadvantage<strong>of</strong>theapplication<strong>of</strong>domain-specificlanguagesformodel-drivens<strong>of</strong>twaredevelopmentisthatthedefinition<br />
<strong>of</strong>a(graphical)notationrequiresconsiderableeffort.Weinvestigated<br />
howmodeltransformationscanbedeployedtomapsuchlanguagesto<br />
UMLnotation.<br />
Westudiedeach<strong>of</strong>thesetasksseparatelyinacasestudy.<br />
Theinformaluse<strong>of</strong>modellinginindustrymakesitnecessarytointroduceanormalisationsteptoenabletheintegration<strong>of</strong>evolutionsupportinindustrialpractice.Thisthesisincludesseveralexamples<strong>of</strong>howtoimplementthisstep,whichistypicallycontextspecific.Additionallybytheuse<br />
<strong>of</strong>severalst<strong>and</strong>ardsinthearea<strong>of</strong>model-drivens<strong>of</strong>twaredevelopmentwe<br />
furtherimprovethepotentialintegration<strong>of</strong>ourresultsinpractice.<br />
Inseveralchaptersweaddresstheimpact<strong>of</strong>theuse<strong>of</strong>product-line<br />
principlesforthedevelopment<strong>of</strong>s<strong>of</strong>twaresystemsonthes<strong>of</strong>twareevolutionsupportweintroduce.<br />
Althoughtheincreasedscope<strong>of</strong>s<strong>of</strong>tware<br />
product-linesmakessuchsupportmoredifficulttodevelop,atthesame<br />
timethereturnoninvestment(e.g.,fortheuse<strong>of</strong>amodel-drivenapproach)<br />
ismuchimproved.<br />
Themodel-drivensupportfortheevolutiontasksthatwepresentin<br />
thisthesisfollowsasimilarthree-steppattern. Aset<strong>of</strong>sourcemodelsis<br />
first’preprocessed’intoaformsuitableformodeltransformations. This<br />
preprocessingincludesanormalisationstepaswellasatranslationinto
Summary 223<br />
arepresentationbasedonthesametechnologyasthemodeltransformations.Then,modeltransformationsareappliedthataredefinedinamodel<br />
transformationlanguage. Thesetransformationsdotheactualworksuch<br />
asconformancechecking(i.e.,usingtwosourcemodels)ormigration. Finally,theresultingtargetmodelsarepostprocessedintothedesiredtargetform.Thismightbeagraphicalrepresentationorsomerepresentationintendedforfurtherprocessing.
Samenvatting<br />
Tweebekendewettenindes<strong>of</strong>tware-engineeringzeggendat: 1)s<strong>of</strong>tware<br />
voortdurendmoetwordenaangepastaannieuweengewijzigdeomgevingsengebruikerseisen;met<strong>and</strong>erewoordens<strong>of</strong>twareevolueertcontinuen2)<br />
s<strong>of</strong>twarediegewijzigdwordt,wordtsteedsingewikkelder.Hetgevolgvan<br />
dezetoenemendecomplexiteitisdatdeonderhoudbaarheidvans<strong>of</strong>twaresystemenafneemtmetdetijd:hetwordtsteedsmoeilijkerver<strong>and</strong>eringenaantebrengen.Vooreengrootdeelwordtdecomplexiteitvaneens<strong>of</strong>twaresysteembepaalddoorzijnstructuur,ookwelarchitectuurgenoemd.<br />
De<br />
focusinditproefschriftisopdeevolutievans<strong>of</strong>twarearchitecturen. Hoewelditsoortevolutievaakvoorkomt,iszerisicovolenkostbaar.Onsdoelishetrisicoendekostendiegepaardgaanmetdeevolutievans<strong>of</strong>twarearchitecturenteverminderen.Voorhetprobleemdatdeonderhoudbaarheidvans<strong>of</strong>twaresystemenafneemtbestaantweevoordeh<strong>and</strong>liggendeoplossingsstrategieën:<br />
1)het<br />
gebruikvantechniekenomdetoenemendecomplexiteittebeheersenen2)<br />
hetgebruikvantechniekenomdecomplexiteitteverminderen.Automatiseringenabstractiezijntweebekendes<strong>of</strong>tware-engineeringtechniekendievoordezetweestrategieëningezetkunnenworden.Inditproefschrifthebbenweonderzochthoetechniekenvooreennieuweaanpakvoors<strong>of</strong>tware<br />
ontwikkeling,diegebaseerdisopautomatiseringenabstractie,toegepast<br />
kunnenwordenvoordeevolutievans<strong>of</strong>twarearchitecturen. Dezenieuwe<br />
aanpakwordtmodelgedrevens<strong>of</strong>twareontwikkelinggenoemd.<br />
Deho<strong>of</strong>donderzoeksvraagdiewebeh<strong>and</strong>elenis:Hoek<strong>and</strong>eevolutievan<br />
s<strong>of</strong>twarearchitecturenwordenondersteund?.Eendrietalgerelateerdesubvragenbakenenonsonderzoekverderaf.<br />
Dezesubvragengaanoverde<br />
integratievanpotentiëleevolutieondersteuningindeindustriëlepraktijk,<br />
degevolgenvanhetgebruikvanproductlijnenopdeevolutieondersteuning<br />
endeautomatiseringv<strong>and</strong>eevolutieondersteuningdoormiddelvanmodelgedrevens<strong>of</strong>twareontwikkeltechnologieën.<br />
Ombetertebegrijpenwelkes<strong>of</strong>twareontwikkeltechnologieënopwelke<br />
manierwordeningezetvoorverschillendesoortentaken,zijnwebegon-<br />
225
226 Samenvatting<br />
nenmeteenenquête.Indezeenquêtehebbenwemenseninverschillende<br />
rollenbijeenachttalorganisatiesindes<strong>of</strong>tware-industriegevraagdnaar<br />
deontwikkeltechnologieëndiezegebruiken.Belangrijkea<strong>and</strong>achtspunten<br />
hierbijwarenookdesituatiewaaringebruikwordtgemaaktvaneenbepaaldetechnologieendeproblemendiedaarbijoptreden.<br />
Enkeletrends<br />
diewetijdensdeenquêtehebbenopgemerktzijn:hettoenemendegebruik<br />
vanproductlijnen,deinformelewijzevanmodellerenenhetbelangvanhet<br />
evolutionaireaspectvans<strong>of</strong>tware(s<strong>of</strong>twaresystemenwordenzeldenvanuit<br />
hetnietsontwikkeld).Deelshebbenderesultatenv<strong>and</strong>ezeenquêtegeleid<br />
toteerdergenoemdeonderzoeksvragen.<br />
Vervolgenshebbenwemetbehulpvancasestudy’sbijOcéenASMLonderzochthoedeevolutievans<strong>of</strong>twarearchitectuurondersteundkanworden.<br />
Wehebbenonshierbijgerichtopviertypens<strong>of</strong>twareontwikkeltaken<br />
dietemakenhebbenmets<strong>of</strong>tware-evolutie<br />
EvaluatieEeneerstestapbijwijzigingenishetvaststellen<strong>of</strong>zijbinnen<br />
dehuidigearchitectuurgerealiseerdkunnenworden.Hierhebbenwe<br />
vooralonderzochthoezo’nevaluatieindecontextvaneenproductlijn<br />
gemaaktkanworden.<br />
ConsistentieWanneerdearchitectuurmoetwordenaangepastishetnuttigteweteninwelkematedezeconsistentismet<strong>and</strong>ereontwikkelartefacten.Wijhebbenonsgeconcentreerdopdemogelijkhedenvan<br />
modelgedrevens<strong>of</strong>twareontwikkeltechniekenvoorhetvindenvaneen<br />
antwoordopdievraag.<br />
MigratieWijhebbenonderzochthoeeendaadwerkelijkemigratiegedeeltelijkgeautomatiseerdkanwordenmetbehulpvanmodeltransformaties.<br />
DocumentatieDetoepassingv<strong>and</strong>omeinspecifieketalenvoormodelgedrevens<strong>of</strong>twareontwikkelingheeftalsnadeeldatdeontwikkelingvan<br />
een(grafische)notatieveelinspanningvergt.Wijhebbenonderzocht<br />
hoemodeltransformatieskunnenwordeningezetomzulketalenaf<br />
tebeeldenopdeUMLnotatie.<br />
Wehebbenelkv<strong>and</strong>ezetakenbestudeerdineenapartecasestudy.<br />
Deinformelewijzevanmodellerenindeindustriemaakthetnoodzakelijkeennormalisatiestapteintroducerenomdeintegratievanevolutieondersteuningindeindustriëlepraktijkmogelijktemaken.Ditproefschrift<br />
bevatverscheidenevoorbeeldenvanhoedezestap,diecontextafhankelijk<br />
is,terealiseren. Verderverbeterenwedeintegreerbaarheidvanonzeresultatenindepraktijkdoorhetgebruikvaneenaantalst<strong>and</strong>aardenophet<br />
gebiedvanmodelgedrevens<strong>of</strong>twareontwikkeling.
Samenvatting 227<br />
Inmeerdereho<strong>of</strong>dstukkenkomenweterugopdeinvloedvanhetgebruikvanproductlijnenvoordeontwikkelingvans<strong>of</strong>twaresystemenopde<br />
evolutieondersteuningdieweontwikkelen.Alhoeweldegroterereikwijdte<br />
vanproductlijnenditmoeilijkermaakt,nemendemogelijkhedendenoodzakelijkeinvesteringen(bv.voorhetgebruikvaneenmodelgedrevenaanpak)terugteverdieneneveneenstoe.<br />
Demodelgedrevenondersteuningvoordes<strong>of</strong>tware-evolutietakendiewe<br />
inditproefschriftpresenterenvolgteenvergelijkbaardriestappenpatroon.<br />
Eenverzamelingbronmodellenwordteerstzodaniggeprepareerddatde<br />
modelleneenformaatkrijgendatgeschiktisomtetransformerenmetmodeltransformaties.Depreparatiestapomvateennormalisatieeneenvertalingnaareenrepresentatiediegebaseerdisopdezelfdetechnologieals<br />
detoetepassenmodeltransformaties. Vervolgenswordendezetransformaties,diegedefinieerdwordenineenmodeltransformatietaal,toegepast.<br />
Dezetransformatiesdoenheteigenlijkewerk,zoalshetcontrolerenvan<br />
consistentie(dusmettweebronmodellen)<strong>of</strong>eenmigratie.Tenslottewordt<br />
hetresultaatnogbewerktomhetineengewenstformaattebrengen.Dit<br />
kanbijvoorbeeldeengrafischerepresentatiezijn<strong>of</strong>eentijdelijkerepresentatiebedoeldvoorverderebewerking.
Curriculum Vitae<br />
BasGraafwasborninTheHagueonFridaythe13 th <strong>of</strong>Januaryin1978.<br />
There,hegraduatedgymnasium(highschool)in1996atCSGOvervoorde.<br />
SubsequentlyheenrolledinthecomputerscienceprogramatDelftUniversity<strong>of</strong>Technology.<br />
Afterspecialisingins<strong>of</strong>twareengineeringhereceived<br />
hismaster’sdegreein2002. Hewrotehismaster’sthesisoncomponentbaseds<strong>of</strong>twaredevelopment<strong>and</strong>theUnified<strong>Model</strong>ingLanguageundersupervision<strong>of</strong>Dr.P.G.Kluit<strong>and</strong>Pr<strong>of</strong>.dr.ir.J.L.G.Dietz.In2002hestartedhisPh.D.researchatthes<strong>of</strong>twaretechnologydepartment<strong>of</strong>DelftUniversity<strong>of</strong>Technology.<br />
Duringthisresearchunder<br />
supervision<strong>of</strong>Pr<strong>of</strong>.dr.A.vanDeursenheinvestigatedtheapplicability<strong>of</strong><br />
model-drivens<strong>of</strong>twaredevelopmenttechnologiestosupports<strong>of</strong>twareevolution.<br />
229
TitlesintheIPADissertationSeriessince2002<br />
M.C.vanWezel.NeuralNetworks<br />
forIntelligentDataAnalysis: theoretical<strong>and</strong>experimentalaspects.Faculty<strong>of</strong>Mathematics<strong>and</strong>NaturalSciences,UL.2002-01<br />
V.Bos<strong>and</strong>J.J.T.Kleijn. Formal<br />
Specification <strong>and</strong> Analysis <strong>of</strong> IndustrialSystems.Faculty<strong>of</strong>Mathematics<strong>and</strong>ComputerScience<strong>and</strong><br />
Faculty<strong>of</strong>MechanicalEngineering,<br />
TU/e.2002-02<br />
T. Kuipers. Techniques for Underst<strong>and</strong>ingLegacyS<strong>of</strong>twareSystems.<br />
Faculty<strong>of</strong>NaturalSciences,<br />
Mathematics <strong>and</strong> Computer Science,UvA.2002-03<br />
S.P. Luttik. Choice Quantification<br />
in Process Algebra. Faculty<br />
<strong>of</strong>NaturalSciences,Mathematics,<br />
<strong>and</strong>ComputerScience,UvA.2002-<br />
04<br />
R.J.Willemen. SchoolTimetable<br />
Construction: Algorithms <strong>and</strong><br />
Complexity. Faculty<strong>of</strong>Mathematics<br />
<strong>and</strong> Computer Science, TU/e.<br />
2002-05<br />
M.I.A.Stoelinga. AleaJactaEst:<br />
Verification <strong>of</strong> Probabilistic, Realtime<strong>and</strong>ParametricSystems.Faculty<strong>of</strong>Science,<br />
Mathematics<strong>and</strong><br />
ComputerScience,KUN.2002-06<br />
N.vanVugt.<strong>Model</strong>s<strong>of</strong>Molecular<br />
Computing. Faculty<strong>of</strong>Mathematics<strong>and</strong>NaturalSciences,UL.2002-<br />
07<br />
A.Fehnker.Citius,Vilius,Melius:<br />
Guiding <strong>and</strong> Cost-Optimality in<br />
<strong>Model</strong>Checking<strong>of</strong>Timed<strong>and</strong>HybridSystems.<br />
Faculty<strong>of</strong>Science,<br />
Mathematics <strong>and</strong> Computer Science,KUN.2002-08<br />
R.vanStee. On-lineScheduling<br />
<strong>and</strong>BinPacking.Faculty<strong>of</strong>Mathematics<strong>and</strong>NaturalSciences,UL.<br />
2002-09<br />
D. Tauritz. Adaptive InformationFiltering:Concepts<strong>and</strong>Algorithms.<br />
Faculty <strong>of</strong> Mathematics<br />
<strong>and</strong>NaturalSciences,UL.2002-10<br />
M.B.v<strong>and</strong>erZwaag.<strong>Model</strong>s<strong>and</strong><br />
LogicsforProcessAlgebra.Faculty<br />
<strong>of</strong>NaturalSciences,Mathematics,<br />
<strong>and</strong>ComputerScience,UvA.2002-<br />
11<br />
J.I. den Hartog. Probabilistic<br />
Extensions <strong>of</strong> Semantical <strong>Model</strong>s.<br />
Faculty <strong>of</strong> Sciences, Division <strong>of</strong><br />
Mathematics <strong>and</strong> Computer Science,VUA.2002-12<br />
L. Moonen. Exploring S<strong>of</strong>tware<br />
Systems. Faculty<strong>of</strong>NaturalSciences,Mathematics,<strong>and</strong>Computer<br />
Science,UvA.2002-13<br />
J.I.vanHemert.Applying<strong>Evolution</strong>aryComputationtoConstraintSatisfaction<strong>and</strong>DataMining.Faculty<br />
<strong>of</strong> Mathematics <strong>and</strong> Natural<br />
Sciences,UL.2002-14<br />
S.Andova. ProbabilisticProcess<br />
Algebra. Faculty<strong>of</strong>Mathematics<br />
<strong>and</strong>ComputerScience,TU/e.2002-<br />
15<br />
Y.S. Usenko. Linearization in<br />
µCRL.Faculty<strong>of</strong>Mathematics<strong>and</strong><br />
ComputerScience,TU/e.2002-16<br />
J.J.D.Aerts. R<strong>and</strong>omRedundant<br />
StorageforVideoonDem<strong>and</strong>.Fac-
ulty<strong>of</strong>Mathematics<strong>and</strong>Computer<br />
Science,TU/e.2003-01<br />
M. de Jonge. To Reuse or To<br />
Be Reused: Techniques for component<br />
composition <strong>and</strong> construction.<br />
Faculty<strong>of</strong>NaturalSciences,<br />
Mathematics, <strong>and</strong> Computer Science,UvA.2003-02<br />
J.M.W.Visser. GenericTraversal<br />
overTypedSourceCodeRepresentations.<br />
Faculty <strong>of</strong> Natural Sciences,Mathematics,<strong>and</strong>Computer<br />
Science,UvA.2003-03<br />
S.M.Bohte. SpikingNeuralNetworks.Faculty<strong>of</strong>Mathematics<strong>and</strong><br />
NaturalSciences,UL.2003-04<br />
T.A.C.Willemse. Semantics<strong>and</strong><br />
Verification in Process Algebras<br />
with Data <strong>and</strong> Timing. Faculty<br />
<strong>of</strong>Mathematics<strong>and</strong>ComputerScience,TU/e.2003-05<br />
S.V.Nedea. Analysis<strong>and</strong>Simulations<strong>of</strong>CatalyticReactions.Faculty<strong>of</strong>Mathematics<strong>and</strong>Computer<br />
Science,TU/e.2003-06<br />
M.E.M. Lijding. Real-time<br />
Scheduling <strong>of</strong> Tertiary Storage.<br />
Faculty <strong>of</strong> Electrical Engineering,<br />
Mathematics&ComputerScience,<br />
UT.2003-07<br />
H.P. Benz. Casual MultimediaProcessAnnotation–CoMPAs.<br />
Faculty <strong>of</strong> Electrical Engineering,<br />
Mathematics&ComputerScience,<br />
UT.2003-08<br />
D.Distefano. On<strong>Model</strong>checking<br />
theDynamics<strong>of</strong>Object-basedS<strong>of</strong>tware:<br />
a Foundational Approach.<br />
Faculty <strong>of</strong> Electrical Engineering,<br />
Mathematics&ComputerScience,<br />
UT.2003-09<br />
M.H.terBeek. TeamAutomata<br />
–AFormalApproachtothe<strong>Model</strong>ing<strong>of</strong>CollaborationBetweenSystemComponents.Faculty<strong>of</strong>Mathematics<strong>and</strong>NaturalSciences,UL.<br />
2003-10<br />
D.J.P. Leijen. The λ Abroad –<br />
AFunctionalApproachtoS<strong>of</strong>tware<br />
Components. Faculty <strong>of</strong> Mathematics<strong>and</strong>ComputerScience,UU.<br />
2003-11<br />
W.P.A.J. Michiels. Performance<br />
RatiosfortheDifferencingMethod.<br />
Faculty<strong>of</strong>Mathematics<strong>and</strong>ComputerScience,TU/e.2004-01<br />
G.I. Jojgov. Incomplete Pro<strong>of</strong>s<br />
<strong>and</strong>Terms<strong>and</strong>TheirUseinInteractive<br />
Theorem Proving. Faculty<br />
<strong>of</strong>Mathematics<strong>and</strong>ComputerScience,TU/e.2004-02<br />
P. Frisco. Theory <strong>of</strong> Molecular<br />
Computing – Splicing <strong>and</strong> Membranesystems.Faculty<strong>of</strong>Mathematics<strong>and</strong>NaturalSciences,UL.<br />
2004-03<br />
S.Maneth. <strong>Model</strong>s<strong>of</strong>TreeTranslation.Faculty<strong>of</strong>Mathematics<strong>and</strong><br />
NaturalSciences,UL.2004-04<br />
Y. Qian. Data Synchronization<br />
<strong>and</strong> Browsing for Home Environments.Faculty<strong>of</strong>Mathematics<strong>and</strong><br />
Computer Science <strong>and</strong> Faculty <strong>of</strong><br />
IndustrialDesign,TU/e.2004-05<br />
F.Bartels. OnGeneralisedCoinduction<br />
<strong>and</strong> Probabilistic Specification<br />
Formats. Faculty <strong>of</strong> Sciences,Division<strong>of</strong>Mathematics<strong>and</strong><br />
ComputerScience,VUA.2004-06
L.Cruz-Filipe. ConstructiveReal<br />
Analysis: a Type-Theoretical Formalization<strong>and</strong>Applications.Faculty<strong>of</strong>Science,<br />
Mathematics<strong>and</strong><br />
ComputerScience,KUN.2004-07<br />
E.H. Gerding. Autonomous<br />
AgentsinBargainingGames: An<br />
<strong>Evolution</strong>aryInvestigation<strong>of</strong>Fundamentals,<br />
Strategies, <strong>and</strong> BusinessApplications.Faculty<strong>of</strong>TechnologyManagement,TU/e.<br />
2004-<br />
08<br />
N. Goga. Control <strong>and</strong> Selection<br />
TechniquesfortheAutomatedTesting<br />
<strong>of</strong> Reactive Systems. Faculty<br />
<strong>of</strong>Mathematics<strong>and</strong>ComputerScience,TU/e.2004-09<br />
M. Niqui. Formalising Exact<br />
Arithmetic: Representations,Algorithms<strong>and</strong>Pro<strong>of</strong>s.Faculty<strong>of</strong>Science,<br />
Mathematics<strong>and</strong>Computer<br />
Science,RU.2004-10<br />
A.Löh.ExploringGenericHaskell.<br />
Faculty<strong>of</strong>Mathematics<strong>and</strong>ComputerScience,UU.2004-11<br />
I.C.M.Flinsenberg. RoutePlanning<br />
Algorithms for Car Navigation.<br />
Faculty<strong>of</strong>Mathematics<strong>and</strong><br />
ComputerScience,TU/e.2004-12<br />
R.J.Bril.Real-timeSchedulingfor<br />
MediaProcessingUsingConditionallyGuaranteedBudgets.<br />
Faculty<br />
<strong>of</strong>Mathematics<strong>and</strong>ComputerScience,TU/e.2004-13<br />
J. Pang. Formal Verification <strong>of</strong><br />
Distributed Systems. Faculty <strong>of</strong><br />
Sciences,Division<strong>of</strong>Mathematics<br />
<strong>and</strong>ComputerScience,VUA.2004-<br />
14<br />
F.Alkemade.<strong>Evolution</strong>aryAgent-<br />
BasedEconomics.Faculty<strong>of</strong>TechnologyManagement,TU/e.<br />
2004-<br />
15<br />
E.O.Dijk. IndoorUltrasonicPosition<br />
Estimation Using a Single<br />
Base Station. Faculty <strong>of</strong> Mathematics<br />
<strong>and</strong> Computer Science,<br />
TU/e.2004-16<br />
S.M.Orzan. OnDistributedVerification<strong>and</strong>VerifiedDistribution.<br />
Faculty <strong>of</strong> Sciences, Division <strong>of</strong><br />
Mathematics <strong>and</strong> Computer Science,VUA.2004-17<br />
M.M. Schrage. Proxima - A<br />
Presentation-oriented Editor for<br />
StructuredDocuments. Faculty<strong>of</strong><br />
Mathematics <strong>and</strong> Computer Science,UU.2004-18<br />
E. Eskenazi <strong>and</strong> A. Fyukov.<br />
Quantitative Prediction <strong>of</strong> QualityAttributesforComponent-Based<br />
S<strong>of</strong>tware<strong>Architectures</strong>. Faculty<strong>of</strong><br />
Mathematics <strong>and</strong> Computer Science,TU/e.2004-19<br />
P.J.L. Cuijpers. Hybrid Process<br />
Algebra. Faculty<strong>of</strong>Mathematics<br />
<strong>and</strong>ComputerScience,TU/e.2004-<br />
20<br />
N.J.M. van den Nieuwelaar.<br />
Supervisory Machine Control by<br />
Predictive-Reactive Scheduling.<br />
Faculty<strong>of</strong>MechanicalEngineering,<br />
TU/e.2004-21<br />
E.Ábrahám.AnAssertionalPro<strong>of</strong><br />
System for Multithreaded Java -<br />
Theory <strong>and</strong> Tool Support- . Faculty<br />
<strong>of</strong> Mathematics <strong>and</strong> Natural<br />
Sciences,UL.2005-01
R.Ruimerman.<strong>Model</strong>ing<strong>and</strong>RemodelinginBoneTissue.<br />
Faculty<br />
<strong>of</strong> Biomedical Engineering, TU/e.<br />
2005-02<br />
C.N. Chong. Experiments in<br />
Rights Control - Expression <strong>and</strong><br />
Enforcement. Faculty<strong>of</strong>Electrical<br />
Engineering,Mathematics&ComputerScience,UT.2005-03<br />
H.Gao.Design<strong>and</strong>Verification<strong>of</strong><br />
Lock-freeParallelAlgorithms.Faculty<strong>of</strong>Mathematics<strong>and</strong>ComputingSciences,RUG.2005-04<br />
H.M.A. van Beek. Specification<br />
<strong>and</strong> Analysis <strong>of</strong> Internet Applications.<br />
Faculty<strong>of</strong>Mathematics<strong>and</strong><br />
ComputerScience,TU/e.2005-05<br />
M.T.Ionita. Scenario-BasedSystemArchitecting-ASystematicApproachtoDevelopingFuture-Pro<strong>of</strong><br />
System <strong>Architectures</strong>. Faculty <strong>of</strong><br />
Mathematics <strong>and</strong> Computing Sciences,TU/e.2005-06<br />
G.Lenzini. Integration<strong>of</strong>Analysis<br />
Techniques in Security <strong>and</strong><br />
Fault-Tolerance. Faculty <strong>of</strong> ElectricalEngineering,Mathematics&<br />
ComputerScience,UT.2005-07<br />
I.Kurtev. Adaptability<strong>of</strong><strong>Model</strong><br />
Transformations. Faculty<strong>of</strong>ElectricalEngineering,Mathematics&<br />
ComputerScience,UT.2005-08<br />
T.Wolle. ComputationalAspects<br />
<strong>of</strong>Treewidth-LowerBounds<strong>and</strong><br />
NetworkReliability.Faculty<strong>of</strong>Science,UU.2005-09<br />
O. Tveretina. Decision ProceduresforEqualityLogicwithUninterpreted<br />
Functions. Faculty <strong>of</strong><br />
Mathematics <strong>and</strong> Computer Science,TU/e.2005-10<br />
A.M.L.Liekens. <strong>Evolution</strong><strong>of</strong>FinitePopulationsinDynamicEnvironments.<br />
Faculty <strong>of</strong> Biomedical<br />
Engineering,TU/e.2005-11<br />
J.Eggermont. DataMiningusingGeneticProgramming:Classification<br />
<strong>and</strong> Symbolic Regression.<br />
Faculty<strong>of</strong>Mathematics<strong>and</strong>NaturalSciences,UL.2005-12<br />
B.J.Heeren.TopQualityTypeErrorMessages.<br />
Faculty<strong>of</strong>Science,<br />
UU.2005-13<br />
G.F. Frehse. CompositionalVerification<br />
<strong>of</strong> Hybrid Systems using<br />
Simulation Relations. Faculty <strong>of</strong><br />
Science, Mathematics <strong>and</strong> ComputerScience,RU.2005-14<br />
M.R.Mousavi.StructuringStructuralOperationalSemantics.Faculty<strong>of</strong>Mathematics<strong>and</strong>Computer<br />
Science,TU/e.2005-15<br />
A.Sokolova. CoalgebraicAnalysis<strong>of</strong>ProbabilisticSystems.Faculty<strong>of</strong>Mathematics<strong>and</strong>Computer<br />
Science,TU/e.2005-16<br />
T.Gelsema. Effective<strong>Model</strong>sfor<br />
the Structure <strong>of</strong> pi-Calculus Processes<br />
with Replication. Faculty<br />
<strong>of</strong> Mathematics <strong>and</strong> Natural Sciences,UL.2005-17<br />
P. Zoeteweij. Composing ConstraintSolvers.<br />
Faculty<strong>of</strong>Natural<br />
Sciences, Mathematics, <strong>and</strong>ComputerScience,UvA.2005-18<br />
J.J.Vinju.Analysis<strong>and</strong>Transformation<strong>of</strong>SourceCodebyParsing<br />
<strong>and</strong>Rewriting. Faculty<strong>of</strong>Natural
Sciences, Mathematics, <strong>and</strong>ComputerScience,UvA.2005-19<br />
M.Valero Espada. Modal Abstraction<br />
<strong>and</strong> Replication <strong>of</strong> ProcesseswithData.Faculty<strong>of</strong>Sciences,Division<strong>of</strong>Mathematics<strong>and</strong><br />
ComputerScience,VUA.2005-20<br />
A. Dijkstra. Stepping through<br />
Haskell. Faculty <strong>of</strong> Science, UU.<br />
2005-21<br />
Y.W.Law. Keymanagement<strong>and</strong><br />
link-layersecurity<strong>of</strong>wirelesssensor<br />
networks: energy-efficient attack<strong>and</strong>defense.Faculty<strong>of</strong>ElectricalEngineering,Mathematics&<br />
ComputerScience,UT.2005-22<br />
E.Dolstra.ThePurelyFunctional<br />
S<strong>of</strong>twareDeployment<strong>Model</strong>. Faculty<strong>of</strong>Science,UU.2006-01<br />
R.J. Corin. Analysis <strong>Model</strong>s for<br />
SecurityProtocols.Faculty<strong>of</strong>ElectricalEngineering,Mathematics&<br />
ComputerScience,UT.2006-02<br />
P.R.A. Verbaan. The ComputationalComplexity<strong>of</strong>EvolvingSystems.Faculty<strong>of</strong>Science,UU.2006-<br />
03<br />
K.L. Man <strong>and</strong> R.R.H. Schiffelers.<br />
Formal Specification <strong>and</strong><br />
Analysis<strong>of</strong>HybridSystems. Faculty<strong>of</strong>Mathematics<strong>and</strong>Computer<br />
Science<strong>and</strong>Faculty<strong>of</strong>Mechanical<br />
Engineering,TU/e.2006-04<br />
M.Kyas. VerifyingOCLSpecifications<strong>of</strong>UML<strong>Model</strong>s:ToolSupport<strong>and</strong>Compositionality.Faculty<br />
<strong>of</strong> Mathematics <strong>and</strong> Natural Sciences,UL.2006-05<br />
M. Hendriks. <strong>Model</strong> Checking<br />
TimedAutomata-Techniques<strong>and</strong><br />
Applications. Faculty <strong>of</strong> Science,<br />
Mathematics <strong>and</strong> Computer Science,RU.2006-06<br />
J.Ketema. Böhm-LikeTreesfor<br />
Rewriting. Faculty <strong>of</strong> Sciences,<br />
VUA.2006-07<br />
C.-B. Breunesse. OnJML:topics<br />
in tool-assisted verification <strong>of</strong><br />
JML programs. Faculty <strong>of</strong> Science,<br />
Mathematics<strong>and</strong>Computer<br />
Science,RU.2006-08<br />
B. Markvoort. Towards Hybrid<br />
Molecular Simulations. Faculty<br />
<strong>of</strong> Biomedical Engineering, TU/e.<br />
2006-09<br />
S.G.R. Nijssen. Mining StructuredData.Faculty<strong>of</strong>Mathematics<strong>and</strong>NaturalSciences,UL.2006-<br />
10<br />
G. Russello. Separation <strong>and</strong><br />
Adaptation<strong>of</strong>ConcernsinaShared<br />
DataSpace. Faculty<strong>of</strong>Mathematics<br />
<strong>and</strong> Computer Science, TU/e.<br />
2006-11<br />
L.Cheung.ReconcilingNondeterministic<strong>and</strong>ProbabilisticChoices.<br />
Faculty <strong>of</strong> Science, Mathematics<br />
<strong>and</strong>ComputerScience,RU.2006-<br />
12<br />
B. Badban. Verification techniques<br />
for Extensions <strong>of</strong> Equality<br />
Logic.Faculty<strong>of</strong>Sciences,Division<br />
<strong>of</strong>Mathematics<strong>and</strong>ComputerScience,VUA.2006-13<br />
A.J. Mooij. Constructive formal<br />
methods<strong>and</strong>protocolst<strong>and</strong>ardization.<br />
Faculty<strong>of</strong>Mathematics<strong>and</strong><br />
ComputerScience,TU/e.2006-14<br />
T.Krilavicius.HybridTechniques<br />
for Hybrid Systems. Faculty <strong>of</strong>
ElectricalEngineering,Mathematics&ComputerScience,UT.2006-<br />
15<br />
M.E. Warnier. Language Based<br />
SecurityforJava<strong>and</strong>JML.Faculty<br />
<strong>of</strong>Science,Mathematics<strong>and</strong>ComputerScience,RU.2006-16<br />
V.Sundramoorthy. AtHomeIn<br />
ServiceDiscovery. Faculty<strong>of</strong>ElectricalEngineering,Mathematics&<br />
ComputerScience,UT.2006-17<br />
B.Gebremichael. Expressivity<strong>of</strong><br />
TimedAutomata<strong>Model</strong>s. Faculty<br />
<strong>of</strong>Science,Mathematics<strong>and</strong>ComputerScience,RU.2006-18<br />
L.C.M. van Gool. Formalising<br />
Interface Specifications. Faculty<br />
<strong>of</strong>Mathematics<strong>and</strong>ComputerScience,TU/e.2006-19<br />
C.J.F. Cremers. Scyther - Semantics<strong>and</strong>Verification<strong>of</strong>Security<br />
Protocols. Faculty<strong>of</strong>Mathematics<br />
<strong>and</strong>ComputerScience,TU/e.2006-<br />
20<br />
J.V. Guillen Scholten. Mobile<br />
ChannelsforExogenousCoordination<br />
<strong>of</strong> Distributed Systems: Semantics,Implementation<strong>and</strong>Composition.<br />
Faculty<strong>of</strong>Mathematics<br />
<strong>and</strong>NaturalSciences,UL.2006-21<br />
H.A.deJong. FlexibleHeterogeneous<br />
S<strong>of</strong>tware Systems. Faculty<br />
<strong>of</strong>NaturalSciences,Mathematics,<br />
<strong>and</strong>ComputerScience,UvA.2007-<br />
01<br />
N.K.Kavaldjiev. Arun-timereconfigurable<br />
Network-on-Chip for<br />
streamingDSPapplications. Faculty<br />
<strong>of</strong> Electrical Engineering,<br />
Mathematics&ComputerScience,<br />
UT.2007-02<br />
M.vanVeelen.Considerationson<br />
<strong>Model</strong>ingforEarlyDetection<strong>of</strong>AbnormalitiesinLocallyAutonomous<br />
Distributed Systems. Faculty <strong>of</strong><br />
Mathematics <strong>and</strong> Computing Sciences,RUG.2007-03<br />
T.D.Vu. Semantics<strong>and</strong>Applications<strong>of</strong>Process<strong>and</strong>ProgramAlgebra.<br />
Faculty<strong>of</strong>NaturalSciences,<br />
Mathematics, <strong>and</strong> Computer Science,UvA.2007-04<br />
L. Br<strong>and</strong>án Briones. Theories<br />
for<strong>Model</strong>-basedTesting:Real-time<br />
<strong>and</strong>Coverage.Faculty<strong>of</strong>Electrical<br />
Engineering,Mathematics&ComputerScience,UT.2007-05<br />
I.Loeb.NaturalDeduction:SharingbyPresentation.Faculty<strong>of</strong>Science,<br />
Mathematics<strong>and</strong>Computer<br />
Science,RU.2007-06<br />
M.W.A.Streppel.Multifunctional<br />
GeometricDataStructures.Faculty<br />
<strong>of</strong>Mathematics<strong>and</strong>ComputerScience,TU/e.2007-07<br />
N.Trčka. SilentStepsinTransitionSystems<strong>and</strong>MarkovChains.Faculty<strong>of</strong>Mathematics<strong>and</strong>ComputerScience,TU/e.2007-08<br />
R. Brinkman. Searching in encrypteddata.<br />
Faculty<strong>of</strong>Electrical<br />
Engineering,Mathematics&ComputerScience,UT.2007-09<br />
A.vanWeelden. Puttingtypesto<br />
gooduse.Faculty<strong>of</strong>Science,Mathematics<strong>and</strong>ComputerScience,RU.<br />
2007-10<br />
J.A.R. Noppen. ImperfectInformation<br />
in S<strong>of</strong>tware Development
Processes. Faculty <strong>of</strong> Electrical<br />
Engineering,Mathematics&ComputerScience,UT.2007-11<br />
R.Boumen. Integration<strong>and</strong>Test<br />
plansforComplexManufacturing<br />
Systems. Faculty <strong>of</strong> Mechanical<br />
Engineering,TU/e.2007-12<br />
A.J. Wijs. What to do Next?:<br />
Analysing<strong>and</strong>OptimisingSystem<br />
BehaviourinTime. Faculty<strong>of</strong>Sciences,Division<strong>of</strong>Mathematics<strong>and</strong><br />
ComputerScience,VUA.2007-13<br />
C.F.J.Lange. Assessing<strong>and</strong>ImprovingtheQuality<strong>of</strong><strong>Model</strong>ing:A<br />
Series<strong>of</strong>EmpiricalStudiesabout<br />
theUML.Faculty<strong>of</strong>Mathematics<br />
<strong>and</strong>ComputerScience,TU/e.2007-<br />
14<br />
T. van der Storm. Componentbased<br />
Configuration, Integration<br />
<strong>and</strong>Delivery. Faculty<strong>of</strong>Natural<br />
Sciences, Mathematics, <strong>and</strong>ComputerScience,UvA.2007-15<br />
B.S. Graaf. <strong>Model</strong>-<strong>Driven</strong> <strong>Evolution</strong><br />
<strong>of</strong> S<strong>of</strong>tware <strong>Architectures</strong>.<br />
Faculty <strong>of</strong> Electrical Engineering,<br />
Mathematics, <strong>and</strong> Computer Science,TUDelft.2007-16
Change language