‐1‐

Tightly Integrated Views: Overcoming the Gap betweenSoftware Engineering Concepts and Practice in SoftwareArchitecture–APositionPaper

MichaelGoedicke,UniversityofDuisburgEssen,Paluno–TheRuhrInstituteforSoftwareTechnology,45117Essen,Germany,michael.goedicke@s3.uni‐due.de

Abstract:Ithastobestatedthatthesoftwareindustryhasnotpickedupsoftwarearchitectureconceptsandmethods, which have been developed during recent decades. While the key requirements for modularsoftware structures are known since the 1970ties and various Architecture Description Languages (ADLs)have been developed, these concepts have not been used in designing programming languages and/orframeworksforlargescalesoftwaredevelopments.SoftwareIndustry,however,hasacceptedtheapproachtouseframeworksandpatternstoimposesomestructureontheirsoftwaresystemsinordertokeepworkabledevelopment artefacts. This position paper proposes a research path, which uses the inclination ofpractitioners towardsprogramcode, frameworksandpatternsontheonehandandabstractmodelsontheotherhandasawaytospecifyanddocumenthighleveldesigndecisions.Thisisaccomplishedbyembeddingabstract specifications into code. Such annotated and structured code serves as the basis for programdevelopment and architecting the code at an abstract level using the embedded specifications. This isregarded as a first step towards a more software architecture centric way of structuring code and entiresoftwaresystemsduringdesignandruntime.

IntroductionWeseethesoftwaredevelopmentprocessisstructuredintostagesandnotphases.Thismeans,thatthestagesasdepictedinfig.1interactandthesketchisnotmeanttoindicateatemporalorderingofactivities.

Fig.1StagesofSoftwareDevelopment

Animportantissueofcontemporarysoftwaredevelopmentprocessescanalsobeinterpretedintermsofthepicture sketched in fig. 1. Usually software engineering methods and techniques assume green fielddevelopment.Thestagesofruntimeandmaintenance/evolutionareregardedasalessinterestingspecialcaseofagreenfielddevelopment.Thishowever,neglectstheimportantdataregardingactualusagescenariosandproblemsdetectedduringtheso‐calledproductionphaseofasoftwaresystem.Inaddition,ithastobenotedthat the connection between abstract specification and design models of the system in question and theinformationgatheredduringthesystem’sruntimeishardlymade.Thisisduetothefactthatthelastminute

‐2‐

fixesofthesystem(beforeitgoesinto“production”)arenotreflectedinthosedevelopmentartefacts,nottomention the development steps occurring during evolution after the first release. Model driven SoftwareDevelopmentisinitscurrentformlimitedbythelackofgoodroundtripengineeringconcepts,whichreallywork[0].

We have pointed out in [1] this kind of software aging which requires new attempts to cover the entirelifecycle including production till decommission of the software system. Also the newway of constructingsoftwaresystemusingmanypre‐existingso‐calledservicesprovidesnewchallenges.

Insummary,athoroughunderstandingoftherelationshipsbetweenthestagesdepictedinfig.1providethebasisfornewapproachestoexplainthenatureofsoftwaredevelopmentandinferrelatedconcepts,methodsandtools.

Herewewouldliketofocusonarchitectureandcodeinordertosketchhowhighlevelspecificationscanbetightly integratedintocode.Thisprovidesanopportunitytostudytherelationships inmoredetailandgivehintsfornewconceptsandmethodsinthisareaofsoftwaredevelopment.

GeneralApproachThe general approach is depicted in fig. 2. It shows for the various stages related to design andimplementation that specifications (models) and code are intertwined in such a way that the abstractspecificationsareavailableduringruntime.Thustheycanbeusedtoexecutepiecesofthespecifiedsoftwarefragmentandareinstrumentalduringtheevolutionforthepurposeofdesignrecovery.

Fig.2Relationshipbetweenspecificationsandprogramcodeoverthelifetimeofasoftwaresystem

Therelationshipbetweenspecificationsandcode[2] is formulatedasannotationscontained inthecode i.e.codefragmentsarearrangedinpatternsderivedfromconceptsandconstructofthespecificationlanguage/modelsusedattheabstractdescriptionlevel.

Thisapproachcanalsobeviewedasanattempttouseabstractspecificationconceptsinordertoformspecificpatternsattheimplementationlevel.Thusthespecificationstatementcontainedinapieceofprogramcodeprovidestheframe/patternforthecodeatthedetailedlevel.Theadvantageisthatthecodecanbecheckedwrt. therequiredpropertiesof theusedspecificationconstructcontained intheannotation.Ausuallysmallframeworkusestheannotationduringruntimeviareflectionandexecutesthefragmentencapsulatedbytheannotations.

ExampleAsafirstexperimentinthisdirectionwehaveusedstatemachinestoexpressabstractbehaviouralmodelsinJavaCode[3].HereJavaclassesserveasarepresentationofstates,transitionarespecifiedusingappropriatelyannotatedmethods.Anumberoftoolshavebeendeveloped,whichsupportthisapproachatvariouslevelsofspecificationandimplementation.Atransformationtoolextractsthestatemachinemodel,whichcanbeusedintheUPPAL‐toolforfurtheranalysis.Designchangesarereflectedbackattheimplementationstage.AJavafragmentspecifiedandimplementedusingthisapproachcanbemonitoredatruntime.Thisallowstoobservetheprogrambehaviournotonlyintermsoftheusedprogramminglanguage(Java)conceptslikeassignmentsbutalsointermsofstatesandtransitionsandrelatedconditionsenabling/disablingtransitions.

!"#$%"%&'

()(*+&,)$*-)(*+&./

,%0*12)(*+&34%25(*+& 6+&*(+0*&7

!"#"$%&'"()*+,'" -.(*+,'"

8%9*7&./

:02;*(%2(50%

!"/,0(*+,'"

!" !"#$#$#

$#$#$

#$#$#

<)&75)7%9

/.6+-%$9

=+502%.>+-% =+502%.>+-%

/.6+-%$9?@(%.>+-% A0)2*&7

%

8%9*7&

B%2+C%0@

-"&$12"'"()

% "$#

:$$

D+()(*+&9

‐3‐

Workinprogressistocomplementthisbyacomponentconcept,whichisalsoembeddableintoprogramcodeinasimilarway.Firstanalysisresultsarein[4]andrelatedexperimentsareavailablesoon,whichwillbeanextensiontoOSGi.

Nextstep:beyondcurrentprogramminglanguagesOfcourse, theapproachsketchedaboveisaimingatthechallengesoftoday’ssoftwaredevelopment. I.e.welimit ourselves to contemporaryprogramming languages and available specification concepts.As such, thisapproach serves as an immediate step to join both worlds: abstract specifications and implementationpatterns.Ofcoursethiswillnotbethefinalanswer.

The immediate goal beyond the current experimentation is to find proper component models includingaspects like persistence, transactions, performance, and security,which address awhole range of softwaredevelopmentissues.Thisismeanttoaddressnotonlytheenterpriselevelbutalsotheembeddedworldwithitsownpeculiarcharacteristics.

Thiswillentail inourviewthedevelopmentofnewprogramming languageconcepts,whichallowthe tightintegration of architecture views. Related tools allow then the extraction of abstract views for design andanalysisactions.Thiswillalsohelptodeepenourknowledgeregardingtherelationshipbetweenarchitectureanddesignstages.

ConclusionWe believe that the approach sketched above will lead to a deeper understanding how (architectural)specificationand implementationare intertwinedandhowdesign timeandrun timecanbenefit fromeachother.Thecurrentapproachisbasedoncurrenttechnologiesandwillprovideinsightshowcurrentconceptscanbedevelopedfurtherinordertoincreasetheproductivityofsoftwareengineersbyrelatedpowerfultools.

Ofcourse,thestageofrequirementsmanagementneedstobeintegratedproperlyaswell.Hereitisnecessaryto address issues like constant change, ambiguity and diversity of different stakeholder views and/or thesimple explicit lackof knowledge in additional views (c.f. [5]). Suchviewsare certainlynot embeddable assketched above for the architecture and implementation stage. But a deeper understanding of therelationshipsandhowrequirementsaremappedand traced to thearchitectural/implementation stageandreversewillprovidemoreeffectivewaysofdevelopmenthereaswell.

References[0] MartinFowler,PlatformIndependentMalapropism(2003)

http://www.martinfowler.com/bliki/PlatformIndependentMalapropism.html.

[1] GregorEngels,MichaelGoedicke,UrsulaGoltz,AndreasRausch,RalfReussner:DesignforFuture‐Legacy‐Problemevonmorgenvermeidbar?in:Informatik‐Spektrum:Volume32,Issue5(2009),Page393,2009

[2] MichaelGoedicke,MichaelStriewe,MoritzBalz:SupportforEvolutionofSoftwareSystemsusingEmbeddedModels,inProc.Workshop"DesignforFuture‐LanglebigeSoftwaresysteme",October15th‐16th,Karlsruhe,CEURWorkshopProceedingsVol537,2009

[3] MoritzBalz,MichaelStriewe,MichaelGoedicke:EmbeddingBehavioralModelsintoObject‐OrientedSourceCode,in:Proceedingsof"SoftwareEngineering2009",Kaiserslautern,Germany,LNIVolP‐143,2009

[4] MarcoMüller,MoritzBalz,MichaelGoedicke:RepresentingFormalComponentModels,inOSGi,in:Proceedingsof"SoftwareEngineering2010",Paderborn,Germany,pages45‐56,LNIVolP‐159,2010

[5] MichaelGoedicke,ThomasHerrmann:ACaseforViewPointsandDocuments,in:InnovationsforRequirementAnalysis.FromStakeholdersNeedstoFormalDesigns14thMontereyWorkshop2007,Monterey,CA,USA,September10‐13,2007.RevisedSelectedPapersLNCS5320,pp62‐84,SpringerVerlag2008