DocumentingSoftwareArchitecture:DocumentingBehaviorF.Bachman,L.Bass,P. - PDF document

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