Model-Driven Evolution of Software Architectures - Software and ...
Model-Driven Evolution of Software Architectures - Software and ...
Model-Driven Evolution of Software Architectures - Software and ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
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
Change language