UML provides a variety of constructs to represent different kinds of modules. Figure 9.5 shows some examples. UML has a class construct, which is the object- ...
9.6UnifiedModelingLanguage
Wehaveconcentratedonthekindofinformationthatshouldbeincludedinarchitecturedocumentation.Architectureinsomesenseexpresseswhatisessentialaboutasoftwaresystem,andthatessenceisindependentoflanguagesandnotationstocaptureit.Nevertheless,todaytheUnifiedModelingLanguage(UML)hasemergedasthedefactostandardnotationfordocumentingasoftwarearchitecture.However,itmustbesaidthatUMLmakesitsmaincontributioninaview'sprimarypresentation,anditssecondarycontributioninthebehaviorofanelementorgroupofelements.ItisuptothearchitecttoaugmenttheUMLpictureswiththenecessarysupportingdocumentation(theelementcatalog,therationale,andsoforth)thataresponsiblejobrequires.UMLprovidesnodirectsupportforcomponents,connectors,layers,interfacesemantics,ormanyotheraspectsofasystemthataresupremelyarchitectural.
Still,inmostcaseswecanusetheconstructsthatUMLdoesoffertoachievesatisfactoryeffects,atleastincraftingtheprimarypresentationsofarchitecturalviews.Webeginbydiscussingmoduleviews.
MODULEVIEWS
Recallthatamoduleisacodeorimplementationunitandamoduleviewisanenumerationofmodulestogetherwiththeirinterfacesandtheirrelations.
Interfaces
Figure9.4showshowmoduleinterfacescanberepresentedinUML.UMLusesa"lollipop"todenoteaninterface,whichcanbeappendedtoclassesandsubsystems,amongotherthings.
UMLalsoallowsaclasssymbol(box)tobestereotypedasaninterface;theopen-headeddashedarrowshowsthatanelementrealizesaninterface.Thebottomoftheclasssymbolcanbeannotatedwiththeinterface'ssignatureinformation:methodnames,arguments,argumenttypes,andsoforth.Thelollipopnotationisnormallyusedtoshowdependenciesfromelementstotheinterface,whiletheboxnotationallowsamoredetaileddescriptionoftheinterface'ssyntax,suchastheoperationsitprovides.
Modules
UMLprovidesavarietyofconstructstorepresentdifferentkindsofmodules.Figure9.5showssomeexamples.UMLhasaclassconstruct,whichistheobject-orientedspecializationofamodule.Packagescanbeusedincaseswheregroupingoffunctionalityisimportant,suchastorepresentlayersandclasses.Thesubsystemconstructcanbeusedifaspecificationofinterfaceandbehaviorisrequired.
Figure9.5.ExamplesofmodulenotationsinUML
Figure9.6showshowtherelationsnativetomoduleviewsaredenotedusingUML.Moduledecompositionreliesonthe"is-part-of"relation.Themoduleusesviewreliesonthedependencyrelation,andthemoduleclassviewreliesonthegeneralization,or"is-a"relation(alsocalled"inheritance").
Figure9.6.ExamplesofrelationnotationsinUML.ModuleBispartofmoduleA,moduleDdependsonmoduleC,andmoduleFisatypeofmoduleE.
Aggregation
InUML,thesubsystemconstructcanbeusedtorepresentmodulesthatcontainothermodules;theclassboxisnormallyusedfortheleavesofthedecomposition.Subsystemsareusedbothaspackagesandasclassifiers.Aspackages,theycanbedecomposedandhencearesuitableformoduleaggregation.Asclassifiers,theyencapsulatetheircontentsandcanprovideanexplicitinterface.AggregationisdepictedinoneofthreewaysinUML:
Modulesmaybenested(seeFigure9.7left).Figure9.7.DecompositioninUMLwithnesting.Theaggregatemoduleisshownasapackage(left);decompositioninUMLwitharcs(right).
Asuccessionoftwodiagrams(possiblylinked)canbeshown,wherethesecondisadepictionofthecontentsofamoduleshowninthefirst.
Anarcdenotingcompositionisdrawnbetweentheparentandthechildren(seeFigure9.7right).
InUML,compositionisaformofaggregationwithimpliedstrongownership-thatis,partsliveanddiewiththewhole.IfmoduleAiscomposedofmodulesBandC,thenBorCcannotexistwithoutA,andifAisdestroyedatruntime,soareBandC.Thus,UML'scompositionrelationhasimplicationsbeyondthestructuringoftheimplementationunits;therelationalsoendowstheelementswitharuntimeproperty.Asanarchitect,youshouldmakesureyouarecomfortablewiththispropertybeforeusingUML'scompositionrelation.
Generalization
ExpressinggeneralizationisattheheartofUMLinwhichmodulesareshownasclasses(althoughtheymayalsobeshownassubsystems).Figure9.8showsthebasicnotationavailableinUML.
Figure9.8.DocumentinggeneralizationinUMLwithtwolinestyles
ThetwodiagramsinFigure9.8aresemanticallyidentical.UMLallowsanellipsis(…)inplaceofasubmodule,indicatingthatamodulecanhavemorechildrenthanshownandthatadditionalonesarelikely.ModuleShapeistheparentofmodulesPolygon,Circle,andSpline,eachofwhichisasubclass,child,ordescendantofShape.Shapeismoregeneral,whileitschildrenarespecializedversions.
Dependency
ThebasicnotationfordependencywasshowninFigure9.6.Themostarchitecturallysignificantmanifestationofdependencyisfoundinlayers.Sadly,UMLhasnobuilt-inprimitivecorrespondingtoalayer.However,itcanrepresentsimplelayersusingpackages,asshowninFigure9.9.Thesearegeneral-purposemechanismsfororganizingelementsintogroups.UMLhaspredefinedpackagesforsystemsandsubsystems.Wecanintroduceanadditionalpackageforlayersbydefiningitasapackagestereotype.AlayercanbeshownasaUMLpackagewiththeconstraintsthatitgroupsmodulestogetherandthatthedependencybetweenpackagesis"allowedtouse."Wecandesignatealayerusingthepackagenotationwiththestereotypename<>precedingthelayername,orintroduceanewvisualform,suchasashadedrectangle.
Figure9.9.AsimplerepresentationoflayersinUML
COMPONENT-AND-CONNECTORVIEWS
Thereisnosinglepreferredstrategytodocumentcomponent-and-connector(C&C)viewsinUML,butanumberofalternatives.Eachalternativehasitsadvantagesanddisadvantages.Onenaturalcandidateforrepresentingcomponent-and-connectortypesbeginswiththeUMLclassconcept.
Figure9.10illustratesthegeneralideausingasimplepipe-and-filtersystem.Here,thefilterarchitecturaltypeisrepresentedastheUMLclassFilter.Instancesoffilters,suchasSplitter,arerepresentedascorrespondingobjectsinanobjectinstancediagram.Toprovideanamespaceboundary,weenclosethedescriptionsinpackages.TherepresentationofMergeAndSort,denotedDetails,wouldbeshownasanotherpackageelsewhere.
Figure9.10.Typesasclasses,andinstancesasobjects,exemplifiedwithasimplepipeandfilter
Wenowtakeacloserlookatthisstrategy.
Components
Thetype/instancerelationshipinarchitecturaldescriptionsisaclosematchtotheclass/objectrelationshipinaUMLmodel.UMLclasses,likecomponenttypesinarchitecturaldescriptions,arefirst-classentitiesandarerichstructuresforcapturingsoftwareabstractions.ThefullsetofUMLdescriptivemechanismsisavailabletodescribethestructure,properties,andbehaviorofaclass,makingthisagoodchoicefordepictingdetailandusingUML-basedanalysistools.Propertiesofarchitecturalcomponentscanberepresentedasclassattributesorwithassociations;behaviorcanbedescribedusingUMLbehavioralmodels;andgeneralizationcanbeusedtorelateasetofcomponenttypes.Thesemanticsofaninstanceortypecanalsobeelaboratedbyattachingoneofthestandardstereotypes;forexample,the«process»stereotypecanbeattachedtoacomponenttoindicatethatitrunsasaseparateprocess.NotethattherelationshipbetweenMergeAndSortanditssubstructureisindicatedusingadependencyrelation.
Interfaces
Interfacestocomponents,sometimescalledports,canbeshowninfiveways,asshowninFigure9.11,describedinincreasingorderofexpressiveness.However,asexpressivenessrisessodoescomplexity,soyoushouldpickthefirststrategythatwillserveyourpurposes.
Option1:Noexplicitrepresentation.
Leavingoutinterfacesleadstothesimplestdiagramsbutsuffersfromtheobviousproblemthatthereisnowaytocharacterizethenamesorthepropertiesoftheinterfacesintheprimarypresentation.Still,thischoicemightbereasonableifthecomponentshaveonlyoneinterface,iftheinterfacescanbeinferredfromthesystemtopology,orifthediagramisrefinedelsewhere.
Option2:Interfacesasannotations.
Representinginterfacesasannotationsprovidesahomeforinformationaboutthem,althoughannotationshavenosemanticvalueinUMLsocannotbeusedasabasisforanalysis.Again,ifthedetailedpropertiesofaninterfacearenotofconcern,thisapproachmightbereasonable.
Option3:Interfacesasclass/objectattributes.
Treatinginterfacesasattributesofaclass/objectmakesthempartoftheformalstructuralmodel,buttheycanhaveonlyasimplerepresentationinaclassdiagram-essentially,anameandatype.Thisrestrictionlimitstheexpressivenessofthisoption.
Option4:InterfacesasUMLinterfaces.
TheUMLlollipopnotationprovidesacompactdescriptionofaninterfaceinaclassdiagramdepictingacomponenttype.Inaninstancediagram,aUMLassociationrole,correspondingtoaninterfaceinstanceandqualifiedbytheinterfacetypename,providesacompactwaytoshowthatacomponentinstanceisinteractingthroughaparticularinterfaceinstance.Thisapproachprovidesvisuallydistinctdepictionsofcomponentsandinterfaces,inwhichinterfacescanclearlybeseenassubservient.
However,thisstrategyprovidesnomeanstodepicttheservicesrequiredfromacomponent'senvironment,oftenakeypartofaninterface.Furthermore,itismeaningfulforacomponenttypetohaveseveralinstancesofthesameinterfacetype,butitisnotmeaningfultosaythataclassrealizesseveralversionsofoneUMLinterface.Forexample,thereisnoeasywaytodefineaSplitterfiltertypethathastwooutputportsofthesame"type"usingthistechnique.Finally,unlikeclasses,UMLinterfacesdonothaveattributesorsubstructure.
Option5:Interfacesasclasses.
Describinginterfacesasclassescontainedbyacomponenttypeovercomesthelackofexpressivenessofthepreviousalternatives:Wecannowrepresentinterfacesubstructureandindicatethatacomponenttypehasseveralinterfacesofthesametype.Acomponentinstanceismodeledasanobjectcontainingasetofinterfaceobjects.However,byrepresentinginterfacesasclasses,wenotonlyclutterthediagrambutalsoloseclearvisualdiscriminationbetweeninterfacesandcomponents.Wecoulduseanotationalvariationinwhichtheinterfacesarecontainedclasses,asshowninthelowerpartofoption5inFigure9.11.Indicatingpointsofinteractioniscounterintuitive,however,ascontainmentusuallyindicatesthataclassownsotherclasseswhoseinstancesmayormaynotbeaccessiblethroughinstancesoftheparentclass.
Figure9.11.Fivewaystorepresentinterfacestocomponents(ports)
Connectors
Therearethreereasonableoptionsforrepresentingconnectors.Again,thechoiceisbetweenexpressivenessandsemanticmatchontheonehandandcomplexityontheother.
Option1:Connectortypesasassociationsandconnectorinstancesaslinks.
Inanarchitecturalbox-and-linediagramofasystem,thelinesbetweencomponentsareconnectors.OnetemptingwaytorepresentconnectorsinUMLisasassociationsbetweenclassesorlinksbetweenobjects.Thisapproachisvisuallysimple,providesacleardistinctionbetweencomponentsandconnectors,andusesthemostfamiliarrelationshipinUMLclassdiagrams:association.Moreover,associationscanbelabeled,andadirectionassociatedwiththeconnectorcanbeindicatedwithanarrow.Unfortunately,connectorsandassociationshavedifferentmeanings.Asysteminanarchitecturaldescriptionisbuiltupbychoosingcomponentswithbehaviorexposedthroughtheirinterfacesandconnectingthemwithconnectorsthatcoordinatetheirbehaviors.Asystem'sbehaviorisdefinedasthecollectivebehaviorofasetofcomponentswhoseinteractionisdefinedandlimitedbytheconnectionsbetweenthem.
Incontrast,althoughanassociation,orlink,inUMLrepresentsapotentialforinteractionbetweentheelementsitrelates,theassociationmechanismisprimarilyawayofdescribingaconceptualrelationshipbetweentwoelements.Inaddition,anassociationisarelationshipbetweenUMLelements,soitcannotstandonitsowninaUMLmodel.Consequently,aconnectortypecannotberepresentedinisolation.Instead,youmustresorttonamingconventionsortostereotypeswhosemeaningsarecapturedbydescriptioninUML'sobjectconstraintlanguage.Further,theapproachdoesnotallowyoutospecifyaconnector'sinterfaces.
Option2:Connectortypesasassociationclasses.
Onesolutiontothelackofexpressivenessistoqualifytheassociationwithaclassthatrepresentstheconnectortype.Inthisway,theconnectortypeorconnectorattributescanbecapturedasattributesofaclassorobject.Unfortunately,thistechniquestilldoesnotprovideanywayofexplicitlyrepresentingconnectorinterfaces.
Option3:Connectortypesasclassesandconnectorinstancesasobjects.
Onewaytogiveconnectorsfirst-classstatusinUMListorepresentconnectortypesasclassesandconnectorinstancesasobjects.Usingclassesandobjects,wehavethesamefouroptionsforrepresentingrolesaswehadforinterfaces:notatall,asannotations,asinterfacesrealizedbyaclass,oraschildclassescontainedbyaconnectorclass.Givenaschemeforrepresentinginterfaces,anattachmentbetweenacomponent'sinterfaceandaconnector'sinterfacemayberepresentedasanassociationoradependency.
Systems
Inadditiontorepresentingindividualcomponentsandconnectorsandtheirtypes,wealsoneedtoencapsulategraphsofcomponentsandconnectors:systems.Threeoptionsareavailable.
Option1:SystemsasUMLsubsystems.
TheprimaryUMLmechanismforgroupingrelatedelementsisthepackage.Infact,UMLdefinesastandardpackagestereotype,called«subsystem»,togroupUMLmodelsthatrepresentalogicalpartofasystem.Thechoiceofsubsystemsisappropriateforanymappingofcomponentsandconnectors,anditworksparticularlywellforgroupingclasses.Oneoftheproblemswithusingsubsystems,asdefinedinUML1.4,isthat,althoughtheyarebothaclassifierandapackage,themeaningisnotentirelyclear.Somehavearguedthatweshouldbeabletotreatasubsystemasanatomicclass-likeentityatcertainstagesinthedevelopmentprocessandlaterbeabletorefineitintermsofamoredetailedsubstructure.Havingtheabilitytodothiswouldmakethesubsystemconstructmoreappropriateformodelingarchitecturalcomponents.
Option2:Systemsascontainedobjects.
Objectcontainmentcanbeusedtorepresentsystems.Componentsarerepresentedasinstancesofcontainedclasses,andconnectorsaremodeledusingoneoftheoptionsoutlinedearlier.Objectsprovideastrongencapsulationboundaryandcarrywiththemthenotionthateachinstanceoftheclasshastheassociated"substructure."However,thisapproachhasproblems,themostseriousbeingthatassociations,usedtomodelconnectors,betweencontainedclassesarenotscopedbytheclass.Thatis,itisnotpossibletosaythatapairofclassesinteractsviaaparticularconnector,modeledasanassociation,onlyinthecontextofaparticularsystem.So,forexample,indicatingthattwocontainedclassesinteractviaanassociationisvalidforinstancesofclassesusedanywhereelseinthemodel.
Option3:Systemsascollaborations.
AsetofcommunicatingobjectsconnectedbylinksisdescribedinUMLusingacollaboration.Ifwerepresentcomponentsasobjects,wecanusecollaborationstorepresentsystems.Acollaborationdefinesasetofparticipantsandrelationshipsthataremeaningfulforagivenpurpose,whichinthiscaseistodescribetheruntimestructureofthesystem.Theparticipantsdefineclassifierrolesthatobjectsplay,orconformto,wheninteracting.Similarly,therelationshipsdefineassociationrolesthatlinksmustconformto.
Collaborationdiagramscanbeusedtopresentcollaborationsateitherthespecificationortheinstancelevel.Aspecification-levelcollaborationdiagramshowstheroles,definedwithinthecollaboration,arrangedinapatterntodescribethesystemsubstructure.Aninstance-levelcollaborationdiagramshowstheobjectsandlinksconformingtotherolesatthespecificationlevelandinteractingtoachievethepurpose.Therefore,acollaborationpresentedattheinstancelevelisbestusedtorepresenttheruntimestructureofthesystem.Figure9.12illustratesthisapproach.TheFilterarchitecturaltypeisrepresentedaspreviously.Instancesoffiltersandpipesarerepresentedascorrespondingclassifierroles-forexample,/SplitterindicatestheSplitterrole-andassociationroles.Theobjectsandlinksconformingtothoserolesareshowninthecollaborationdiagramattheinstancelevel,indicatedbyunderscorednames.
Figure9.12.Systemsascollaborations
Althoughthisisanaturalwaytodescriberuntimestructures,itleavesnowaytoexplicitlyrepresentsystem-levelproperties.Thereisalsoasemanticmismatch;acollaborationdescribesarepresentativeinteractionbetweenobjectsandprovidesapartialdescription,whereasanarchitecturalconfigurationismeanttocaptureacompletedescription.
ALLOCATIONVIEWS
InUML,adeploymentdiagramisagraphofnodesconnectedbycommunicationassociations.Figure9.13providesanexample.Nodesmaycontaincomponentinstances,whichindicatesthatthecomponentlivesorrunsonthenode.Componentsmaycontainobjects,whichindicatesthattheobjectispartofthecomponent.Componentsareconnectedtoothercomponentsbydashed-arrowdependencies(possiblythroughinterfaces).Thisindicatesthatonecomponentusestheservicesofanother;astereotypemaybeusedtoindicatetheprecisedependencyifneeded.Thedeploymenttypediagrammayalsobeusedtoshowwhichcomponentsmayrunonwhichnodes,byusingdashedarrowswiththestereotype«supports».
Figure9.13.AdeploymentviewinUML
Anodeisaruntimephysicalobjectthatrepresentsaprocessingresource,generallyhavingatleastamemoryandoftenprocessingcapabilityaswell.Nodesincludecomputingdevicesbutalsohumanormechanicalprocessingresources.Nodesmayrepresenttypesofinstances.Runtimecomputationalinstances,bothobjectsandcomponents,mayresideonnodeinstances.
Nodesmaybeconnectedbyassociationstoothernodes.Anassociationindicatesacommunicationpathbetweenthem.Theassociationmayhaveastereotypetoindicatethenatureofthecommunicationpath(forexample,thekindofchannelornetwork).
Thenestingofsymbolswithinthenodesymbolsignifiesacompositionassociationbetweenanodeclassandconstituentclassesoracompositionlinkbetweenanodeobjectandconstituentobjects.
