UML 2 Class Diagram Guidelines - Agile Modeling

Interfaces are implemented, "realized" in UML parlance, by classes and components - to realize an interface a class or component must implement the ... Home StartHere AnIntroductiontoAgileModeling AgileModelDrivenDevelopment(AMDD) AgileModeling:CorePractices FrequentlyAskedQuestions(FAQ) ValuesofAM PrinciplesofAM PracticesofAM CorePractices ActiveStakeholderParticipation AgileModelingSession ArchitectureEnvisioning DocumentContinuously DocumentLate ExecutableSpecifications InclusiveToolsandTechniques IterationModeling JustBarelyGoodEnough(JBGE)artifacts LookAheadModeling ModelStorming MultipleModels PrioritizedRequirements RequirementsEnvisioning SingleSourceInformation Test-DrivenDesign(TDD) Disciplines Requirements Analysis Design Architecture Documentation EnterpriseModeling Artifacts AgileModelsDistilled ModelingStyle AgileDocumentation IntroductiontoUML2.X Resources AgileData Ambysoft DownloadsSitemap ContactMe UMLclassdiagrams showtheclassesofthesystem,their inter-relationships,andtheoperationsandattributesoftheclasses. Classdiagramsaretypicallyused,althoughnotallatonce,to: Exploredomainconceptsintheformofadomainmodel Analyzerequirementsintheformofaconceptual/analysismodel Depictthedetaileddesignofobject-orientedorobject-basedsoftware Aclassmodeliscomprisedofoneormoreclassdiagrams andthesupportingspecificationsthatdescribemodelelementsincluding classes,relationshipsbetweenclasses,andinterfaces.There areguidelinesfor: General issues Classes Interfaces Relationships Inheritance Aggregationand Composition 1. GeneralGuidelines Becauseclassdiagramsareusedforavarietyofpurposes -fromunderstandingrequirementstodescribingyourdetaileddesign-you willneedtoapplyadifferentstyleineachcircumstance.Thissectiondescribesstyleguidelinespertainingto differenttypesofclassdiagrams. Figure 1.Analysisanddesignversionsofaclass. Figure 2.Modelingassociationclasses. IdentifyResponsibilitiesonDomainClassDiagrams. IndicateVisibilityOnlyOnDesignModels. IndicateLanguage-DependentVisibilityWithPropertyStrings. IndicateTypesOnlyOnDesignModels. IndicateTypesOnAnalysisModelsOnlyWhenTheTypeisanActual Requirement. DesignClassDiagramsShouldReflectLanguageNamingConventions.In Figure1youseethatthedesign versionofthe Order classusesnamesthatconformtocommon Javaprogramming conventionssuchas placementDate and calculateTaxes(). ModelAssociationClassesOnAnalysisDiagrams.Figure2showsthatassociationclassesaredepictedasclass attachedviaadashedlinetoanassociation-theassociationline,the class,andthedashedlineareconsideredonesymbolintheUML. DoNotNameAssociationsThatHaveAssociationClasses. CenterTheDashedLineofanAssociationClass. 2. ClassStyleGuidelines Aclassiseffectivelyatemplatefromwhichobjectsare created(instantiated).Althoughin therealworldDoug,Wayne,John,andBillareallstudentobjectswewould modeltheclassStudentinstead.Classesdefineattributes,informationthatispertinenttotheir instances,andoperations,functionalitythattheobjectssupport.Classeswillalsorealizeinterfaces(moreonthislater).Notethatyoumayneedtosoftensomeofthenaming guidelinestoreflectyourimplementationlanguageorsoftwarepurchasedfroma third-partyvendor. Figure 3.TheOrderItemclasswithandwithoutscaffoldingcode. Figure 4.Indicatingtheexceptionsthrownbyanoperation. +findAllInstances():Vector {exceptions=NetworkFailure,DatabaseError} UseCommonTerminologyforNames PreferCompleteSingularNounsforClassNames NameOperationswithaStrongVerb NameAttributesWithaDomain-BasedNoun DoNotModelScaffoldingCode.Scaffoldingcodereferstotheattributesandoperations requiredtoimplementbasicfunctionalitywithinyourclasses,suchasthecode requiredtoimplementrelationshipswithotherclasses.Figure 3depictsthedifferencebetweenthe OrderItem classwithoutscaffoldingcodeandwithit. NeverShowClassesWithJustTwoCompartments LabelUncommonClassCompartments IncludeanEllipsis(...)AtTheEndofIncompleteLists ListStaticOperations/AttributesBeforeInstanceOperations/Attributes ListOperations/AttributesinDecreasingVisibility ForParametersThatAreObjects,OnlyListTheirType DevelopConsistentMethodSignatures AvoidStereotypesImpliedByLanguageNamingConventions IndicateExceptionsInAnOperation'sPropertyString.ExceptionscanbeindicatedwithaUMLpropertystring,anexampleof whichisshowninFigure4. 3. Interfaces An interfaceisacollectionofoperationsignatureand/or attributedefinitionsthatideallydefinesacohesivesetofbehaviors.Interfacesareimplemented,"realized"inUMLparlance,byclasses andcomponents-torealizeaninterfaceaclassorcomponentmustimplement theoperationsandattributesdefinedbytheinterface.Anygivenclassorcomponentmayimplementzeroormoreinterfacesand oneormoreclassesorcomponentscanimplementthesameinterface. Figure 5.InterfacesonUMLclassdiagrams. InterfaceDefinitionsMustReflectImplementationLanguageConstraints.In Figure5youseethatastandard classboxhasbeenusedtodefinetheinterface PersistentObject (notetheuseofthe <> stereotype). NameInterfacesAccordingToLanguageNamingConventions Apply"Lollipop"NotationToIndicateThatAClassRealizesan Interface DefineInterfacesSeparatelyFromYourClasses DoNotModeltheOperationsandAttributesofanInterfaceinYour Classes.InFigure5you'llnoticethatthe Shipmentclassdoesnotincludetheattributesoroperationsdefinedbythetwo interfacesthatitrealizes. ConsideranInterfacetoBeaContract 4. RelationshipGuidelines Foreaseofdiscussionthetermrelationshipsshallinclude allUMLconceptssuchasassociations,aggregation,composition,dependencies, inheritance,andrealizations-inotherwords,ifit'salineonaUML classdiagramwe'llconsideritarelationship. Figure 6.Shippinganorder. Figure 7.Modelinganorder. Figure 8.Professorsandseminars. Figure 9.Modelingpeopleatauniversity. ModelRelationshipsHorizontally CollaborationIndicatesNeedforaRelationship ModelaDependencyWhenTheRelationshipisTransitory DepictSimilarRelationshipsInvolvingACommonClassAsATree.In Figure6youseethatboth Delivery and Orderhavea dependencyon OIDGenerator.Notehowthetwodependenciesaredrawnincombinationin"tree configuration",insteadofastwoseparatelines,toreduceclutterinthe diagram. AlwaysIndicatetheMultiplicity AvoidaMultiplicityof"*" ReplaceRelationshipsByIndicatingAttributeTypes.In Figure7youseethatCustomer hasa shippingAddress attributeoftype Address- partofthescaffoldingcodetomaintaintheassociationbetweencustomer objectsandaddressobjects. DoNotModelImpliedRelationships DoNotModelEverySingleDependency CenterNamesonAssociations WriteConciseAssociationNamesInActiveVoice IndicateDirectionalityToClarifyAnAssociationName NameUnidirectionalAssociationsInTheSameDirection WordAssociationNamesLeft-To-Right IndicateRoleNamesWhenMultipleAssociationsBetweenTwoClassesExist IndicateRoleNamesonRecursiveAssociations MakeAssociationsBi-DirectionalOnlyWhenCollaborationOccursInBoth Directions.ThelivesatassociationofFigure 9isuni-directional. RedrawInheritedAssociationsOnlyWhenSomethingChanges QuestionMultiplicitiesInvolvingMinimumsAndMaximums 6. InheritanceGuidelines Inheritancemodels"isa"and"islike" relationships,enablingyoutoeasilyreuseexistingdataandcode.When"A" inheritsfrom"B"wesaythat"A"isthesubclassof"B"andthat "B"isthesuperclassof"A."Furthermore, wesaythatwehave"pureinheritance"when"A"inheritsallofthe attributesandmethodsof"B."TheUMLmodelingnotationforinheritanceis alinewithaclosedarrowheadpointingfromthesubclasstothesuperclass. ApplytheSentenceRuleForInheritance PlaceSubclassesBelowSuperclasses BewareofData-BasedInheritance ASubclassShouldInheritEverything 7. AggregationandCompositionGuidelines Sometimesanobjectismadeupofotherobjects.Forexample,anairplaneismadeupofafuselage,wings,engines, landinggear,flaps,andsoon.A deliveryshipmentcontainsoneormorepackages.Ateamconsistsoftwoormoreemployees.Theseareallexamplesoftheconceptofaggregation,whichrepresents "ispartof"relationships.An engineispartofaplane,apackageispartofashipment,andanemployeeis partofateam.Aggregationisa specializationofassociation,specifyingawhole-partrelationshipbetweentwo objects.Compositionisastronger formofaggregationwherethewholeandpartshavecoincidentlifetimes,andit isverycommonforthewholetomanagethelifecycleofitsparts.Fromastylisticpointofview,becauseaggregationandcompositionare bothspecializationsofassociationtheguidelinesforassociationsapply. Figure10.Examplesof aggregationandcomposition. ApplytheSentenceRuleforAggregation YouShouldBeInterestedInBothTheWholeAndThePart DepicttheWholetotheLeftofthePart ApplyCompositiontoAggregatesofPhysicalItems ApplyCompositionWhenthePartsShareThePersistenceLifecycleWiththe Whole Don'tWorryAboutGettingtheDiamondsRight