CS 494 Object-Oriented Analysis

4/8/03G-1©2001T.HortonCS494Object-OrientedAnalysis&DesignOntoDesign4/8/03G-2Reminder:Analysismodels•Earlierwemodeledrequirementsusing...•ClassDiagrams:KnownastheConceptualModel–Sometimesknownasthelogicalmodel.–Classesrepresentdomain-levelentities.(E.g.thingsintheuser’sworld.)•Thusnoclassesforimplementation-levelthings.–Associationsmodeldomain-levelrelationships.(E.g.user-understoodrelationshipsbetweenthingsintheuser’sworld.)•Usuallydon’tshownavigationonassociations4/8/03G-3Reminder:Analysismodels(2)•UseCasesandSequenceDiagrams–ScenariosinaUseCasecanberepresentedbyUMLsequencediagrams–Objectsinthesequencediagramcouldbeeither:•Thesystemandtheactors,or...•Domain-levelentitiesmodeledintheconceptualmodel(aclassdiagram)–Messagesbetweenobjectsare:•Again,atahigh-levelofabstraction•Scenariodescriptionsbecomemessages4/8/03G-4Reminder:Goalsfordesign•Createdetailed“plans”(likeblueprints)forimplementation•Buildthesefromrequirementsmodelssoweareconfidentthatalluserneedswillbemet•Createdesignmodelsbeforecodingsothatwecan:–Comparedifferentpossibledesignsolutions–Evaluateefficiency,easeofmodification,maintainability,etc4/8/03G-5UMLNotationsforDesign•SeveralUMLnotationsprovidevariousviewsofadesign•Classdiagrams:Possiblycreatedattwodifferentlevelsofabstractionfordesign:–Specificationlevel:Classesmodeltypes,andwefocussolelyoninterfacesbetweensoftwaremodules–Implementationlevel:Thinkofthisasatrue“softwareblueprint”.Wecangodirectlytocodefromthismodel.•TwotypesofInteractionDiagrams:–SequencediagramsandCollaborationdiagrams4/8/03G-6UMLNotationsforDesign(2)•Sequencediagrams–Objectswillbevariablesimplementedincode–Messagesareoperations(e.g.C++memberfunctions)appliedtoobjects–Sequencediagramsthusshowhowasequenceofoperationscalledbetweenasetofobjectsaccomplishesalargertask–Sequencediagramsforaparticularscenariohelpidentifyoperationsneededinclasses–Theyalsoallowustoverifythatadesigncansupportrequirements(e.g.ause-casescenario)4/8/03G-7UMLNotationsforDesign(3)•Statediagrams–Modelshowaparticularobjectrespondstomessagesaccordingtoitsstate–Forasingleobject,showstatesandtransitionsbetweenstates–Transitionsmaybeconditionalbasedonaguardcondition–Mayshowanactionanobjecttakesontransition,oralsoactivitycarriedoutwithinastate–Occasionallyusedtomodelasystem’sorsubsystem’sbehavior(notjustoneobject’s)4/8/03G-8UMLNotationsforDesign(4)•Packages–Asimplenotationthatgroupsclassestogether–Possibletousethistoshowcontentsofasubsystem•Showdependenciesbetweenpackages•Showvisibilityofclassesbetweenpackages–Notreallyarichenoughnotationfordiagrammingsoftwarearchitectures•ComponentDiagrams–Modelsphysicalmodulesofcode(e.g.files,DLLs,physicaldatabases)4/8/03G-9DesignProcess•Therearemanydifferentapproachestodesign,buthereissomethingtypical.•First,createamodelofthehigh-levelsystemarchitecture–UMLdoesnotreallyprovideanotationthis•Next,usetheconceptualclassmodeltobuildadesign-levelclassmodelormodels–Herewe’llassumewe’rejustbuildinganimplementation-levelclassmodel•Also,modeldynamicbehaviorusinginteractiondiagrams.4/8/03G-10DesignProcess(cont’d)•We’llusesequencediagramswithobjectsfromtheimplementation-levelclassmodel–Sequencediagramsshowhowdesign-levelobjectswillcarryoutactionstoimplementscenariosdefinedaspartofuse-caseanalysis–Messagesbetweenobjectsaremember-functioncallsbetweenobjects–Important:Onlymember-functioncallsareshown,butotherlanguagestatements(e.g.assignments)areexecutedbetweencalls(ofcourse).4/8/03G-11DesignProcess(cont’d)•Important:Developmentofclassandsequencediagramsisiterativeandconcurrent•Whenwecreatesequencediagramsforanewscenarios,wediscoverclassesandoperationsthatneedtobeaddedtotheclassmodel•Thetwomodelsgrowtogether.Neitherisacompleteviewofthesystem.•Otherdocumentationintextformisoftenusedtoprovidedetailsaboutclassdiagramsandsequencediagrams4/8/03G-12Specification-LevelClassDiagrams•Howdoesadesign-levelclassdiagramdifferfromaconceptual-leveldiagram?–Nolongerjustanexternalview!–Wearenowmodeling“how”notjust“what”.•Thisclassdiagrammustdocument:–Additionalclasses–Howyouwillimplementassociations•Multiplicity,NavigabilityorDirection;Associationclasses4/8/03G-13AdditionalClassesinaDesign•Areadditionalclassesneeded?Ofcourse!Ingeneral...•Design-level“internal”classes–Datamanagerclasses.E.g.collectionobjectsthatweresimplyassociationsbefore–Facilitatororhelperclassesthatassistwithcomplextasks(e.g.ObservableComponent)–Factoryclassesthatassistincreatingnewobjects–Classestoimplementotherdesignpatterns•Isthereanyguidanceorstrategyfordeterminingthese?4/8/03G-14ClassTypesinaLayeredArchitecture•FromAmbler,Sect.7.1•5-layermodel•Classesonlyinteractwithinlayers,orasshownbyarrows–Directionmatters!•NextslidedescribestheseUserInterfaceClassesSystemClassesController/ProcessClassesBusiness/DomainClassesPersistenceClassesPersistentStore(s)4/8/03G-15PossibleDesignClassTypes•UIclasses•Business/Domainclasses–Implementdomain-objectsfromAnalysis–Dataobjectsplustheirbehaviors•Controller/Processclasses–implementbusinesslogic,collaborationsbetweenbusinessobjectsand/orothercontroller•Pe