IntroductionThisworkispartofabookonhowtoproducehighqualitydocumentationforsoftwarearchitecturesThebookisintendedtobealanguageindependentguidanceTwoessentialsteps1documentingthesetofrelevantviews ID: 258483
Download Pdf The PPT/PDF document "DocumentingSoftwareArchitecture:Document..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
DocumentingSoftwareArchitecture:DocumentingBehaviorF.Bachman,L.Bass,P.Clements,D.Garlan,J.Ivers,R.Little,R.NordandJ.StaffordDocumentingSoftwareArchitecture:DocumentingBehaviorp.1 IntroductionThisworkispartofabookonhowtoproducehigh-qualitydocumentationforsoftwarearchitectures.Thebookisintendedtobealanguage-independentguidance.Twoessentialsteps:1.documentingthesetofrelevantviewsofthatarchitecture2.documentinginformationthattranscendsanysingleview.Thisthirdpartdescribeswaystodocumentthebehaviorofasystem.DocumentingSoftwareArchitecture:DocumentingBehaviorp.2 BeyondstructureTheclassicalapproachtoorganizethedocumentationofanarchitectureusesacollectionofviews.Aviewisdescribedmostlyintermsofstructuralrelationshipsamongtheelementsitcontains.However,architectureextendsbeyondstructure.Tobesurethatthesystemwillworkasintended,thebehavioroftheelementsofaviewhastobetakenintoaccount.Addmoresemanticdetailtoelementsandtheirinteractionsthathavetime-relatedcharacteristics.DocumentingSoftwareArchitecture:DocumentingBehaviorp.3 Beyondstructure:whatdoweneed?Whatdoweneed?Asortoftime-line.Structuralrelationshipsprovideaviewofthesystemthatreectsallpotentialinteractions.Onlyalimitednumberoftheseinteractionswillbeactuallyactiveduringanyinstantofthesystemexecution.Itisthesystembehaviorthatdescribeshowelementinteractionsmayaffectoneanotheratanypointintimeinagivensystemstate.Everyviewisassociatedwithadescriptionthatdocumentthebehaviorofitselements.DocumentingSoftwareArchitecture:DocumentingBehaviorp.4 Beyondstructure:whatdowehavetodescribe?Somesystemattributescanbeanalyzedentirelyusingastructuraldescription.Forexample:anomalieslikeinputsforwhichthereisnosourceavailable.Ontheotherhand,propertieslikepotentialdeadlockcontaininformationaboutboththebehaviorofelementsandinteractionsamongthem.Abehavioraldescriptionaddsinformationaboutorderingofinteractionsamongtheelements,opportunitiesforconcurrency,timedependenciesofinteractionsExample:statechartsdenedbytheUniedModelingLanguage(UML).DocumentingSoftwareArchitecture:DocumentingBehaviorp.5 WheretodocumentbehaviorBehaviorcanbeshowninanumberofplaces,dependingonwhatisbeingshown:Inaview'ssupportingdocumentation:Behaviorhasitsownsectionintheelementcatalog.Behaviorcanbepartofanelement'sinterfacedocumentation.Forexampleintheusageguidesectionofaninterfacedocument.DesignBackgroundsection,wheretheresultsoftheanalysisareshown.Inthedocumentationthatappliesacrossviews,therationaleforwhythearchitecturesatisesitsrequirementscanincludebehavioralspecications.DocumentingSoftwareArchitecture:DocumentingBehaviorp.6 Whydocumentbehavior?Systemanalysis.Drivingdevelopmentactivities.DocumentingSoftwareArchitecture:DocumentingBehaviorp.7 SystemanalysisWithabehavioraldescriptionwecanreasonaboutthesystem'scompleteness,correctness,andqualityattributes.Itispossibletosimulatethebehavioroftheproposedsysteminordertoreasonaboutthearchitecture'sabilitytosupportsystemrequirements.Documentingsystembehaviorprovidessupportforexploringthequalityattributesofasystemveryearlyinthedevelopmentprocess.Compositional-reasoningtechniquesthatareavailabletodayrequireinformationaboutboththeinternalbehaviorofasystemelementsandinteractionsamongthem.DocumentingSoftwareArchitecture:DocumentingBehaviorp.8 DrivingdevelopmentactivitiesBehavioraldocumentationplaytheroleofavehicleofcommunicationamongstakeholdersduringsystem-developmentactivities.Systemdecomposition.Thebehaviorofanelementhasanimportantinuenceonthestructureofitsdecomposition.Implementingasystemusingadenedarchitectureisacontinuousprocessofdecompositioninsmallerandmoredetailedelementsuntilitispossibletodescribethebehaviorinaprogramminglanguage.Simulationcanbeusedduringthedevelopmentofthesystem.DocumentingSoftwareArchitecture:DocumentingBehaviorp.9 WhattodocumentAtaminimum,wehavetomodelthestimulationofactions,thetransferofinformationfromanelementtoanother,thetime-relatedandorderingconstraintsoftheseinteractions.Forexample:Typesoflinesinterconnectingtwoelements:owofdataorowofcontrol.Typesofcommunication:sync,async.Typesofsupportforcommunication:channel,sharedmemory.Typesofreactionsofanelementtoitsinput:requiresallofjustsomeofitsinputtobepresentbeforeitbeginscalculating.DocumentingSoftwareArchitecture:DocumentingBehaviorp.10 Howtodocumentbehavior:notationsandlanguagesAnynotationfordocumentingsystembehaviormustincludeconstructsfordescribingsequencesofinteractions.Sequencesofinteractionsaredisplayedasasetofstimuliandthetriggeredactivitiesorderedbysomemeans,forexamplealine,numbering,orderingfromtoptobottom.Asadescriptionofbehaviorreferstostructure,thestructuralelementscanbepartofthenotation.Therearetwotypebehavioraldocumentationtools:staticviews,traces.Oftentoolsofbothtypescanbeusedtogethertosupportthedesignprocess.DocumentingSoftwareArchitecture:DocumentingBehaviorp.11 StaticviewsThiskindofbehavioraldocumentation,showsthecompletebehaviorofastructuralelementorsetofelements.Oftentoolsofthistypearestatebased.Itisreferredasstaticbecauseitispossibletoinferallpossibletracesthroughasystem.Thetoolsofthistypeneedtosupportthedescriptionofalternativesandrepetitionstoprovidethecompletecomputingpower.Thistypeofdocumentationshouldbechosenwhensimulationisrequiredorwhenstatic-analysistechniqueswillbeused.Theauthorsdescribefourtoolsofthiskind:statechartsROOMchartsSpecicationDescriptionLanguage(SDL)Zlanguage(pronouncedzed)DocumentingSoftwareArchitecture:DocumentingBehaviorp.12 StatechartsFormalismdevelopedbyDavidHarelinthe80sfordescribingreactivesystems.Powerfulgraphicnotationthatallowustotracethebehaviorofasystemgivenspecicinputs.Alotofusefulextensionstotraditionalstatediagrams.Nestingofstates:whenthesuperstateisentered,allsubstatesareinitiatedattheirrespectivedefaultstartstateandtheyremainactiveuntilthesuperstateisexited.Orthogonalregions:substatesinorthogonalregionsareactivatedconcurrentlyuponentrytothesuperstate....Expressivepowertomodelabstractionandconcurrency.DocumentingSoftwareArchitecture:DocumentingBehaviorp.13 Statecharts:exampleSequenceisrepresentedbyasingle-headedarrowleadingfromthesourcestatetothetargetstate.Anarrowisannotatedwithapair(causeevent/generatedevent).Concurrencyisrepresentedbygroup-ingsetsofstatesintoasuperstate.DocumentingSoftwareArchitecture:DocumentingBehaviorp.14 LimitationsofstatechartsSeveralsimplifyingassumptionsareincorporatedintothestatechartmodel.Alltransitionstakezerotime.Thisallowsasetoftransitionswithinasubstatetoreplaceasingletransitionatthesuperstatelevel.Alltransitionsarereliable.Therefore,thereisnotanybuilt-insupportformodelingprotocols.DocumentingSoftwareArchitecture:DocumentingBehaviorp.15 ROOMAsitsnamesays,theReal-timeObject-OrientedModeling(ROOM)environmentisanapproachtodevelopingreal-timesoftwareusingobject-orienteddesigntechniques.SoROOMsupportstheuseofdataabstraction,encapsulation,andinheritance.InROOMdescriptionsthereareactorsthatcommunicatebyexchangingmessages.ThebehaviorofanactorisdocumentedasahierarchicalstatemachineandisincorporatedintoaROOMchart.DocumentingSoftwareArchitecture:DocumentingBehaviorp.16 ROOMchartsAROOMchartisagraphicalnotationthatisacousintothestatechartTheconceptinROOMchartsareveryclosetotheonesinlanguagesthusallowingasmoothtransitionfromthehigh-leveldesigndowntotheimplementation.UnlikestatechartsROOMchartssupportthemodelingofprotocols.UnlikestatechartsROOMchartsdonotsupportANDstates.Howevertherearefeaturesforsupportingconcurrencybutwithmoreeffort.Supportforinheritanceandencapsulation.Simulationiswidelysupported:ROOMchartsrunonavirtualmachineprovidedbytheROOMenvironment.DocumentingSoftwareArchitecture:DocumentingBehaviorp.17 SDLSpecicationDescriptionLanguage(SDL)isanobject-oriented,formallanguagedenedbytheInternationalTelecommunicationUnion(ITU).Itisintendedforthespecicationofcomplex,event-driven,real-time,andinteractiveapplications.Themostcommonlyapplicationisinthetelephonyareaand,ingeneral,incommunicationsystems.ThestrengthofSDLisindescribingwhathappenswithinasystem.TheweaknessofSDLisindescribingtheinteractionsbetweensub-systems.DocumentingSoftwareArchitecture:DocumentingBehaviorp.18 SDL:structuraldescriptionInSDL,structureisdescribedintermsofahierarchyofblocksthatcanberenedintosetsofprocesses.Theowofdataandstimulationamongblocksandprocessesisdescribedassignalsovernamedchannels.Communicationisasynchronousandspeciedtextuallyasanannotationattachedtoacommunicationchannel.Signalarevisibletootherblocks/processesatlowerlevelsinthehierarchy.DocumentingSoftwareArchitecture:DocumentingBehaviorp.19 SDL:behavioraldescriptionTheinternalbehaviorofaprocessisdescribedusingaow-chartnotation.Processesrunconcurrentlyandinde-pendently;concurrentprocesseshavenoknowledgeofeachother'sstate.SDLsupportsuser-deneddatatypesandprovidesseveralpredenedtypes(integers,real,natural,Boolean...)withtheusualmeanings.Oncebothstructuralviewandsystembehaviorhavebeendocumented,itispossibletosimulatethesystemandobservecontrolanddataow.DocumentingSoftwareArchitecture:DocumentingBehaviorp.20 ZlanguageZ(pronouncedzed)isamathematicallanguagebasedonpredicatelogicandsettheory.TheZlanguagefocusesondataanditstransformations.Systemsarespeciedassetsofschemas.Schemascanbecombinedusingtheschemacalculustocreateacompletebehavior.Theschemacalculusallowstypechecking.TheZlanguageisparticularlyusefulwhenyoudesiretoprovepropertiesbasedonthespecication.Lastbutnotleast,alotofcommercialtoolsisavailabletosupportdevelopingsystemwithZlanguage.DocumentingSoftwareArchitecture:DocumentingBehaviorp.21 Zlanguage:exampleTheScheduleClassschemadeneswhatitmeanstoaddaclasstoaschedule.Abovethecenterhorizontallinetherearethevariabledenitions.TheletterDsigniesthataschemanamedScheduleexistsandthatallofitsvariablesareavailabletoScheduleClass.Thevariablesthatendinaquestionmarkareinputvariables.Belowthecenterhorizontallinetherearerstthepre-conditionsforanoperationandthenthepromisedresultsofthetransformations.Inthisexampletheclasswillbeaddedtothescheduleandwillbeassociatedwiththespeciedtime.DocumentingSoftwareArchitecture:DocumentingBehaviorp.22 TracesTrace-orientedrepresentationsconsistofsequencesofactivitiesorinteractionsthatdescribethesystem'sresponsetoaspecicstimulus.Itisdocumentedthetraceofactivitiesthroughasystemdescribedintermsofitsstructuralelementsandtheirinteractions.Tracedescriptionscanbeusedwhenwehavetoanalyzespecicdifcultsituationthatthesystemhastodealwith.Therearedifferenttechniquesthatemphasizeparticularaspects.Message-orientedtechniquesfocusondescribingthemessageexchangebetweeninstances.Component-orientedtechniquesfocusondescribingwhichbehavioralfeaturesanelementhastohavetoaccommodatethesystemperformingitsfunctions.Activity-orientedtechniquesfocusondescribingwhichactivitieshavetobeperformedinordertoachievethepurposeofthesystem.Flow-orientedtechniquesfocusondescribingthesequencingofresponsibilitiesofelementsforaspecicscenarioortrace.DocumentingSoftwareArchitecture:DocumentingBehaviorp.23 Traces:specictechniquesSpecictrace-basedtechniquesexamined.Use-casediagrams:activity-oriented.Use-casemaps(UCM):ow-oriented.Sequencediagramsandproceduralsequencediagrams:respectivelymessage-orientedandcomponent-oriented.Collaborationdiagrams:component-oriented.MSC:message-oriented.DocumentingSoftwareArchitecture:DocumentingBehaviorp.24 Use-casediagramsUse-casediagramsshowhowusersinteractwithusecasesandhowthelatterareinterrelated.Thepurposeofausecaseistodeneapieceofthebehaviorofanelement.Ausecasedoesnottakecountoftheinternalstructureoftheelement.Eachusecaserepresentsaspecicwayofusinganelement(aservice).Theserviceisinitiatedbyanuserandiscomposedbyasequenceofinteractionsbetweentheuserandtheelement.Usecasescannotbedecomposedthus,inasystemdecomposition,theusecasesforthechildrenelementsarethebasisfortheusecasesoftheparentelement.Use-casediagramsdonothavemeanstodocumentconcurrency.DocumentingSoftwareArchitecture:DocumentingBehaviorp.25 Use-casediagrams:exampleThetopportionshowshowphoneterminalsinteractwiththeEstablishPoint-to-PointConnectionusecase.Users(inthiscasephoneterminals)arerepresentedbyactors.Anactorisasetofrolesthatexternalentitiesassumewheninteractingwithusecases.Linesbetweenactorsandusecasesrepresentthepossibleinteractions.Usecasescanhaverelationshipwitheachother.Inparticular,anextendrelation(dashedarrow)denesthatinstancesofausecasemaybeextendedwithadditionalbehaviordenedinanotherusecase.WiththeincluderelationshipwehaveatoolliketheinheritanceofOOlanguages.DocumentingSoftwareArchitecture:DocumentingBehaviorp.26 Use-casemaps(UCMs)DevelopedatCarletonUniversityin1992.UCMsallowdynamicbehaviorandstructurestoberepresentedandevaluated.TheUCMsconcentrateonvisualizingexecutionpathsthroughasetofelement:thisisapath-centricviewofsystemfunctionalities.ThebasisforUCMsisbuiltonthefollowingnotation.Theexecutionpathsdescribehowelementsareorderedaccordingtotheirresponsibilitiesinthecomputation.ThemUCMnotationaimstolinkbehaviorandstructureinanexplicitandvisualway.DocumentingSoftwareArchitecture:DocumentingBehaviorp.27 Use-casemapsLiketheotherrepresentations,UCMsshowinstancesofstructuralelements.InadditionUCMshaveanotationforcontainmentthatisnormallyshowninstructuraldescription.Anexecutionpaththatentersanelementstatesthatnowthiselementhasaresponsibilityintheexecution.Thenotationincludemeanstorepre-sentthedecompositionofexecutionpaths.DocumentingSoftwareArchitecture:DocumentingBehaviorp.28 SequencediagramsSequencediagramsdocumentasequenceofstimuliexchanges.Asequencediagramhastwodimensions:1.Theverticaldimensionrepresentstime.2.Thehorizontaldimensionrepresentdifferentobjects.Associationsamongobjectsarenotshownandthereisnosignicanceinthehorizontalorderingoftheobjects.Sequencediagramsdonotfurnishtoolstodenepreciselythetemporalconstraintincaseofconcurrency.DocumentingSoftwareArchitecture:DocumentingBehaviorp.29 Sequencediagrams:exampleInstanceshavealifelinedrawnasaverticallinealongthetimeaxis.Thearrowsbetweenlifelinescandescribecreationordestructionofinstances.Anyotherstimulusisdepictedasanarrowsbetweenlifelines.Astimuluscanbeannotatedwithanameofafunction.Astimulusrepresentedasadottedar-rowdescribesareturnofcontroltothesenderofapreviousstimulus.DocumentingSoftwareArchitecture:DocumentingBehaviorp.30 ProceduralsequencediagramsThisvariationfocusesontheinterfaceinteractionsofelementsandismoresuitabletoshowconcurrency,becauseithasmeanstoshowowofcontrol.Thinboxesoverthelifelinearethefocusofcontrolandareusedtoshowthatsomecomputationisdonebytheinstanceinapreciseintervaloftime.Alternativepathsandparallelexecu-tioncanbedescribed(inthegurere-spectivelyforOriginatingConnectionandDestinatingConnection.DocumentingSoftwareArchitecture:DocumentingBehaviorp.31 CollaborationdiagramsCollaborationdiagramsshowtherelationshipsamongtheinterfacesofinstances.Collaborationdiagramsareveryusefulwhenthetaskistoverifythatastructuredesigncanfulllthefunctionalrequirements.Collaborationdiagramsarenotusefuliftheunderstandingofconcurrentactionsisimportant(forexampleinperformanceanalysis).Therelationshipsamongtheinstances,calledlinks,arealsoshownincollaborationsdiagram.Linksaresimplelinesandonlystatethatthetwoinvolvedinstancescaninteract.Sequencediagramsandcollaborationdiagramsexpresssimilarinformations.DocumentingSoftwareArchitecture:DocumentingBehaviorp.32 Collaborationdiagrams:exampleThestimuliareshownasarrowsattachedtoalinkbetweeninstances.Sequencenumberscanbeaddedtostimulitoshowwhichstimulusfollowwhich.Sub-numberingcanbeusedtoshownestedstimuliand/orparallelism.Withnumbering,theinformationcon-tainedinthiskindofdiagramsisanal-ogoustothatobtainablefromase-quencediagrambutwiththecomplex-itythediagramsbecomeunreadable.DocumentingSoftwareArchitecture:DocumentingBehaviorp.33 MSCsAnMSCisamessage-orientedrepresentationthatcontainsthedescriptionoftheasynchronouscommunicationbetweeninstances.SimpleMSCscanlooklikesequencediagrams,buttheyhaveamorespecicdenitionandarichernotation.Theirmainareaofapplicationisintelecommunicationswitchingsystems.AbigadvantageofMSCsisthatinadditiontographicalrepresentations,theyhaveatextualspecicationlanguagedenedforthem.MSCscanoftenbeseeninconjunctionwiththeSDL(theyarebothdenedbytheInternationalTelecommunicationUnion).MSCsfocustorepresentthemessageexchangebetweeninstances(systems,processes).SDLisusedtodescribewhathappeninasystemorprocess.DocumentingSoftwareArchitecture:DocumentingBehaviorp.34 MSCs:exampleInstancesareboxwithaverticalline.Themessageowispresentedbyarrowsthatcanbehorizontal,withadownwardslopewithrespecttothedirectiontoindicatethelowoftime.Atotalorderingofthedescribedcommunicationeventsisassumedalongeachinstanceaxis.Theframerepresentthescopeofthediagram.DocumentingSoftwareArchitecture:DocumentingBehaviorp.35