參考軟件工程

Object-OrientedAnalysisandDesignwithUML2andRationalSoftwareModelerPARTII–Object-OrientedAnalysis2TableofContents05.IntroductiontoRUP06.RequirementsOverview07.AnalysisandDesignOverview08.ArchitecturalAnalysis09.Use-CaseAnalysisp.03p.17p.43p.55p.79Object-OrientedAnalysisandDesignwithUML2andRationalSoftwareModeler05.IntroductiontoRUP4SuccessRatesofSoftwareDevelopmentProjects“StandishGroup”CHAOSChroniclesYearSuccessRateFirst“Chaos”Report199416%“ExtremeChaos”200028%Last“Chaos”Report200334%Success=projectdeliveredontime,withinbudgetandmeetingtheneedsoftheusers“Weknowwhyprojectsfail,weknowhowtopreventtheirfailure--sowhydotheystillfail?”-MartinCobb5SymptomsofSoftwareDevelopmentProblemsUserorbusinessneedsnotmetRequirementsnotaddressedModulesnotintegratingDifficultieswithmaintenanceLatediscoveryofflawsPoorqualityofend-userexperiencePoorperformanceunderloadNocoordinatedteameffortBuild-and-releaseissues6TraceSymptomstoRootCausesNeedsnotmetRequirementschurnModulesdon’tfitHardtomaintainLatediscoveryPoorqualityPoorperformanceCollidingdevelopersBuild-and-releaseInsufficientrequirementsAmbiguouscommunicationsBrittlearchitecturesOverwhelmingcomplexityUndetectedinconsistenciesPoortestingSubjectiveassessmentWaterfalldevelopmentUncontrolledchangeInsufficientautomationSymptomsRootCausesBestPracticesDevelopIterativelyManageRequirementsUseComponentArchitecturesModelVisually(UML)ContinuouslyVerifyQualityManageChange7DefinitionofIterativeDevelopmentIterativedevelopment=steeringaprojectbyusingperiodicobjectiveassessments,andre-planningbasedonthoseassessmentsGooditerativedevelopmentmeans:AddressingrisksearlyUsinganarchitecture-drivenapproachMeasuringobjectivelyPlanningRequirementsAnalysis&DesignImplementationDeploymentTestEvaluationManagementEnvironmentEachiterationresultsinanexecutablerelease8ContrastingTraditionalandIterativeProcessesWaterfallProcessIterativeProcessRequirements-drivenandmostlycustomdevelopmentLateriskresolutionDiseconomyofscaleArchitecture-drivenandcomponent-basedEarlyriskresolutionEconomyofscaleRequirementsAnalysisDesignCodeandUnitTestSubsystemIntegrationSystemTest9IterationsandPhasesInception:ToachieveconcurrenceamongallstakeholdersonthelifecycleobjectivesfortheprojectElaboration:TobaselinearchitectureprovidingastablebasisforthedesignandimplementationeffortsinConstructionConstruction:TocompletethedevelopmentoftheproductTransition:ToensuretheproductisavailableforitsendusersInceptionElaborationConstructionTransitionPreliminaryIterationArchitectureIterationArchitectureIterationDevelopmentIterationDevelopmentIterationDevelopmentIterationTransitionIterationTransitionIteration10ManagingRequirementsEnsuresthatyou:SolvetherightproblemBuildtherightsystemBytakingasystematicapproachtoElicitingOrganizingDocumentingManagingThechangingrequirementsofasoftwareapplication11UseComponent-BasedArchitecturesBasisforreuseComponentreuseArchitecturereuseBasisforprojectmanagementPlanningStaffingDeliveryIntellectualcontrolManagecomplexityMaintainintegritySystem-softwareMiddlewareBusiness-specificApplication-specificComponent-basedarchitecturewith

layers12ModelVisually(UML)CapturesstructureandbehaviorShowshowsystemelementsfittogetherKeepsdesignandimplementationconsistentHidesorexposesdetailsasappropriatePromotesunambiguouscommunicationTheUMLprovidesonelanguageforallpractitioners13ContinuouslyVerifyQualityCostTimeSoftwareproblemsare

100to1000timesmorecostly

tofindandrepairafterdeploymentCosttoRepairSoftwareCostofLostOpportunitiesCostofLostCustomers14ManageChangeToavoidconfusion,have:SecureworkspacesforeachdeveloperAutomatedintegration/buildmanagementParalleldevelopmentWorkspaceManagementProcessIntegrationParallelDevelopmentBuildManagementConfigurationManagementismorethanjustcheck-in

andcheck-out15RationalUnifiedProcessImplementsBestPracticesIterativeapproachGuidanceforactivitiesandartifactsProcessfocusonarchitectureUsecasesthatdrivedesignandimplementationModelsthatabstractthesystem16BringingItAllTogetherDisciplinesgroupactivitieslogicallyInaniteration,youwalkthroughalldisciplinesObject-OrientedAnalysisandDesignwithUML2andRationalSoftwareModeler06.RequirementsOverview18WhereAreWe?IntroductiontoUse-CaseModelingFindActorsandUseCasesOtherRequirementsManagementArtifacts19RequirementsinContextThepurposeofRequirementsisto:ElicitstakeholderrequestsandtransformthemintoasetofrequirementsworkproductsthatscopethesystemtobebuiltandprovidedetailedrequirementsforwhatthesystemmustdoRUPmendsause-casedrivenapproach20WhatIsUse-CaseModeling?LinksstakeholderneedstosoftwarerequirementsDefinesclearboundariesofasystemCapturesandcommunicatesthedesiredbehaviorofthesystemIdentifieswhoorwhatinteractswiththesystemValidates/verifiesrequirementsIsaplanninginstrumentUseCase2SpecificationActor2Usecase1ModelUsecase2Usecase321AUse-CaseModelisMostlyTextUsecase1Usecase2Usecase3Use-Case-ModelSurvey-surveydescription-listofallactors-listofallusecasesUse-Case2Spec-briefdescription-flowofeventsUse-Case3Spec-briefdescription-flowofeventsActor1Actor2Actor3Use-Case1Spec-briefdescription-flowofeventsTheSystem22MajorConceptsinUse-CaseModelingAnactorrepresentsanythingthatinteractswiththesystemAusecaseisasequenceofactionsasystemperformsthatyieldsanobservableresultofvaluetoaparticularactorActorUseCase23Use-CaseDiagramBank

ConsortiumBankCustomerAnAutomatedTellerMachine(ATM)CashierWithdrawCashTransferFundsDepositFundsMaintainATMMaintenance

CrewCollectDeposits24UseCasesContainSoftwareRequirementsEachusecase:DescribesactionsthesystemtakestodeliversomethingofvaluetoanactorShowsthesystemfunctionalityanactorusesModelsadialogbetweenthesystemandactorsIsacompleteandmeaningfulflowofeventsfromtheperspectiveofaparticularactor25BenefitsofUseCasesGivecontextforrequirementsPutsystemrequirementsinlogicalsequencesIllustratewhythesystemisneededHelpverifythatallrequirementsarecapturedAreeasytounderstandUseterminologythatcustomersandusersunderstandTellconcretestoriesofsystemuseVerifystakeholderunderstandingFacilitateagreementwithcustomersFacilitatereuse:test,documentation,anddesign26WhereAreWe?IntroductiontoUse-CaseModelingFindActorsandUseCasesOtherRequirementsManagementArtifacts27DefineActors:FocusontheRolesAnactorrepresentsarolethatahuman,hardwaredevice,oranothersystemcanplayinrelationtothesystemActornamesshouldclearlydenotetheactor’srole?28CaseStudy:CourseRegistrationSystemReviewtheproblemstatementprovidedintheCourseRegistrationRequirementsDocumentActorYStudentCourseRegistrationSystemActorXActorYRegisterforCoursesAnotherUseCaseUseCase329HowShouldINameaUseCase?IndicatethevalueorgoaloftheactorUsetheactiveform;beginwithaverbImagineato-dolistExamplesofvariations

RegisterforCoursesRegisteringforCoursesAcknowledgeRegistrationCourseRegistrationUseRegistrationSystemWhichvariationsshowthevaluetotheactor?Whichdonot?Whichwouldyouchooseastheuse-casename?Why?30StepsforCreatingaUse-CaseModelFindactorsandusecasesIdentifyandbrieflydescribeactorsIdentifyandbrieflydescribeusecasesWritetheusecasesOutlineallusecasesPrioritizetheuse-caseflowsDetailtheflowsinorderofpriorityOutsidethescopeofthiscourse31FindActorsWhoispressingthekeys(interactingwiththesystem)?StudentRegistrarRegistrationSystemThestudentnevertouchesthesystem;theregistraroperatesit.Or,areyoubuildinganInternetapplication?OnlineRegistrationSystem()Student32IdentifyActorsWho/whatusesthesystem?Who/whatgetsinformationfromthissystem?Who/whatprovidesinformationtothesystem?Whereinthecompanyisthesystemused?Who/whatsupportsandmaintainsthesystem?Whatothersystemsusethissystem?33FindUseCasesActorGOAL1GOAL2WhatgoalamItryingtoachievebyusingthesystem?34IdentifyUseCasesWhatarethegoalsofeachactor?Whydoestheactorwanttousethesystem?Willtheactorcreate,store,change,remove,orreaddatainthesystem?Ifso,why?Willtheactorneedtoinformthesystemaboutexternaleventsorchanges?Willtheactorneedtobeinformedaboutcertainoccurrencesinthesystem?Doesthesystemsupplythebusinesswithallofthecorrectbehavior?35GroupExerciseIdentifytheactorswhointeractwiththeCourseRegistrationSystemIdentifyusecasesforthesystemSketchause-casediagram36WhereAreWe?IntroductiontoUse-CaseModelingFindActorsandUseCasesOtherRequirementsManagementArtifacts37Use-CaseSpecificationsNameBriefdescriptionFlowofEventsRelationshipsActivitydiagramsUse-CasediagramsSpecialrequirementsPre-conditionsPost-conditionsOtherdiagramsUse-CaseSpecifications...Use-CaseModelActorsUseCases38Use-CaseFlowofEventsHasonenormal,basicflow

SeveralalternativeflowsRegularvariantsOddcasesExceptionalflows

for

handlingerrorsituations39AScenarioIsaUse-CaseInstanceScenario1Logontosystem.Approvelogon.Entersubjectinsearch.Getcourselist.Displaycourselist.Selectcourses.Confirmavailability.Displayfinalschedule.Scenario2Logontosystem.Approvelogon.Entersubjectinsearch.Invalidsubject.Re-entersubject.

Getcourselist.Displaycourselist.Selectcourses.Confirmavailability.Displayfinalschedule.StudentCourseCatalogSystemRegisterforCourses40GlossaryGlossaryCourseRegistrationSystemGlossary1.

IntroductionThisdocumentisusedtodefineterminologyspecifictotheproblemdomain,explainingterms,whichmaybeunfamiliartothereaderoftheuse-casedescriptionsorotherprojectdocuments.Often,thisdocumentcanbeusedasaninformaldatadictionary,capturingdatadefinitionssothatuse-casedescriptionsandotherprojectdocumentscanfocusonwhatthesystemmustdowiththeinformation.2.

DefinitionsTheglossarycontainstheworkingdefinitionsforthekeyconceptsintheCourseRegistrationSystem.2.1

Course:Aclassofferedbytheuniversity.2.2

CourseOffering:Aspecificdeliveryofthecourseforaspecificsemester–youcouldrunthesamecourseinparallelsessionsinthesemester.Includesthedaysoftheweekandtimesitisoffered.2.3

CourseCatalog:Theunabridgedcatalogofallcoursesofferedbytheuniversity.41SupplementarySpecificationFunctionalityUsabilityReliabilityPerformanceSupportabilityDesignconstraintsSupplementarySpecification42ExercisePerformtheexerciseprovidedbytheinstructorObject-OrientedAnalysisandDesignwithUML2andRationalSoftwareModeler07.AnalysisandDesignOverview44AnalysisandDesigninContextThepurposesofAnalysisandDesignareto:Transformtherequirementsintoadesignofthesystem-to-beEvolvearobustarchitectureforthesystemAdaptthedesigntomatchtheimplementationenvironment,designingitforperformance45AnalysisandDesignOverviewSupplementarySpecificationUse-CaseModelAnalysisModelDataModel(optional)ArchitectureDocument(outsidethescopeofthiscourse)AnalysisandDesignGlossaryDesignModel46TheAnalysisandDesignWorkflowDefineSystemContextArchitecturalAnalysisAssessViabilityofArchitecturalPoCConstructArchitecturalPoCDefineSystemContextArchitecturalAnalysisUse-CaseAnalysisOperationAnalysisIdentifyDesignElementsUse-CaseAnalysisOperationAnalysisPrototypetheUser-InterfaceDesigntheUser-InterfaceIdentifyDesignMechanismsIdentifyDesignElementsOperationAnalysisIdentifyServices

IncorporateExistingDesignElements

StructuretheImplementationModelDescribetheRun-timeArchitectureDescribeDistributionUse-CaseDesign

SubsystemDesignOperationDesignClassDesignDefineTestabilityElementsDesignTestabilityElements

CapsuleDesign

SoftwareArchitectDesignerrolesOtherroles47SimplifiedWorkflowfortheOOADCourseEarlyElaborationiterationGoalofElaboration:TobuildarobustarchitecturethatwillsupporttherequirementsofthesystematareasonablecostandinareasonabletimeToachievethisgoal,weneed:Toproduceanevolutionaryexecutableofproduction-qualitycomponentsthatwilladdressallarchitecturallysignificantrisksoftheprojectAddressingarchitecturallysignificantrisksmeansselectingfortheiterationtheuse-casescenariosthatexposethoserisks48AComponent-BasedArchitectureInRUP,thearchitectureofasoftwaresystemis:Theorganizationorstructureofthesystem'ssignificantcomponentsinteractingthroughinterfaces,WithcomponentscomposedofsuccessivelysmallercomponentsandinterfacesTheactivitiesoftheAnalysisandDesigndisciplineareorganizedaroundtwomajorthemes:Structure,undertheresponsibilityofthesoftwarearchitectArchitecturallayersComponentsandinterfacesContents,undertheresponsibilityofthedesignersAnalysisanddesignclasses49RoadmapfortheOOADCourseAnalysisArchitecturalAnalysis(DefineaCandidateArchitecture)Use-CaseAnalysis(AnalyzeBehavior)DesignIdentifyDesignElements(RefinetheArchitecture)IdentifyDesignMechanisms(RefinetheArchitecture)ClassDesign(DesignComponents)SubsystemDesign(DesignComponents)DescribetheRun-timeArchitectureandDistribution(RefinetheArchitecture)DesigntheDatabaseAnalysisDesign50AnalysisVersusDesignAnalysisDesignFocusonunderstandingtheproblemIdealizeddesignBehaviorSystemstructureFunctionalrequirementsAsmallmodelFocusonunderstandingthesolutionOperationsandattributesPerformanceClosetorealcodeObjectlifecyclesNonfunctionalrequirementsAlargemodel51ArchitecturalViews:The4+1ViewModelProcessViewDeploymentViewLogicalViewUse-CaseViewImplementationViewEnd-userFunctionalityProgrammersSoftwaremanagementPerformance,scalability,throughputSystemintegratorsSystemtopology,delivery,installation,communicationSystemengineeringAnalysts/DesignersStructure52OrganizingModelsinRSA/RSMNeedforwell-definedguidelinestorepresentthearchitecturalviewsinyourmodelinganddevelopmentenvironmentWhitepaper:“ModelStructureGuidelinesForRationalSoftwareModelerAndRationalSoftwareArchitect(2004Release)”AvailableonIBMdeveloperWorks()ModelsandpackagescancontainanynumberofdiagramsOnediagramisthe“default”diagram,i.e.thediagramthatwilldisplaywhentheowningmodelorpackageisopenedThedefaultdiagramshouldcontainallthenecessaryinformationtonavigateinthepackage,forinstance:Ownedpackages(double-clickopensthepackage)Othermajorownedelements,e.g.publicclassesandinterfacesShortcutstootherdiagrams(createdbydrag-and-drop)Explanatoryfreetextand/ornotesOtherguidelineswillbeintroducedaswegoalong53Determiningthe(Elaboration)IterationScopeTheiterationscopeisdefinedintermsofuse-casescenariosthatbestaddressthedriversfortheiterationIntheElaborationphase,thefocusisonarchitecturallysignificantuse-casescenariosTheimplementationofaspecificusecasewillbeinmostcasesspreadoverseveraliterations–andinfactphasesTherearethreemaindriversfordefiningtheobjectivesofaniterationinelaboration:RiskCriticalityCoverage54Object-OrientedAnalysisandDesignwithUML2andRationalSoftwareModeler08.ArchitecturalAnalysis56RoadmapfortheOOADCourseAnalysisArchitecturalAnalysis(DefineaCandidateArchitecture)Use-CaseAnalysis(AnalyzeBehavior)DesignIdentifyDesignElements(RefinetheArchitecture)IdentifyDesignMechanisms(RefinetheArchitecture)ClassDesign(DesignComponents)SubsystemDesign(DesignComponents)DescribetheRun-timeArchitectureandDistribution(RefinetheArchitecture)DesigntheDatabaseAnalysisDesign57ArchitecturalAnalysisPurposeTodefineacandidatearchitectureforthesystembasedonexperiencegainedfromsimilarsystemsorinsimilarproblemdomainsTodefinethearchitecturalpatterns,keymechanisms,andmodelingconventionsforthesystemRoleSoftwareArchitectMajorStepsDefinetheHigh-LevelOrganizationofSubsystemsIdentifyKeyAbstractionsDevelopDeploymentOverview

IdentifyAnalysisMechanisms58WhereAreWe?DefinetheHigh-LevelOrganizationofSubsystemsIdentifyKeyAbstractionsDevelopDeploymentOverviewIdentifyAnalysisMechanisms59DefinetheHigh-LevelOrganizationofSubsystemsPurposeTocreateaninitialstructurefortheDesignModelNormallythedesignmodelisorganizedinlayers–acommonarchitecturalpatternformoderatetolarge-sizedsystemsDuringarchitecturalanalysis,youusuallyfocusonthetwohigh-levellayers,thatis,theapplicationandbusiness-specificlayersThisiswhatismeanbythehigh-levelorganizationofsubsystems60PatternsandFrameworksPatternProvidesacommonsolutiontoacommonprobleminacontextAnalysis/DesignpatternProvidesasolutiontoanarrowly-scopedtechnicalproblemProvidesafragmentofasolution,orapieceofthepuzzleFrameworkDefinesthegeneralapproachtosolvingtheproblemProvidesaskeletalsolution,whosedetailsmaybeAnalysis/Designpatterns61WhatIsanArchitecturalPattern?AnarchitecturalpatternexpressesafundamentalstructuralorganizationschemaforsoftwaresystemsItprovidesasetofpredefinedsubsystems,specifiestheirresponsibilities,andincludesrulesandguidelinesfororganizingtherelationshipsbetweenthem–Buschmanetal,“Pattern-OrientedSoftwareArchitecture—ASystemofPatterns”Examples:LayersModel-view-controller(MVC)PipesandfiltersBlackboard62TheModel-View-Controller(MVC)ArchitectureConceivedinthemid-1980'sExtensivelyappliedinmostobject-orienteduserinterfacesAdaptedtorespondtospecificplatformrequirements,suchasJ2EEModelManagestheapplicationdomain’sconcepts,bothbehaviorandstateControllerCapturesusereventsanddetermineswhichactionstotakeViewRetrievesthedatafromthemodelorreceivesitfromthecontroller,anddisplaysittotheuserinawaytheuserUserEventChangeNotificationStateQueryViewSelectionStateChange63AnMVCExample:StrutsComponents(FromtheIBMRedbook,RationalApplicationDeveloperV6ProgrammingGuide,June2005)64LayeredArchitecturesEquipmentandcustomerspecificcodeProcessesandotherapplicationcodeMajorabstractions,classes,etc.Mechanisms,servicesH/Wspecificcode,O/Sspecificcode,general-purposecode(ex.ORB,MQS,etc.)ApplicationframeworkApplicationInfra-structureMoreGenericMoreReuseMoreSpecificLessReuse65LayeringConsiderationsLevelofabstractionGroupelementsatthesamelevelofabstractionSeparationofconcernsGrouplikethingstogetherSeparatedisparatethingsApplicationvs.domainmodelelementsResiliencyLoosecouplingConcentrateonencapsulatingchangeUserinterface,businessrules,andretaineddatatendtohaveahighpotentialforchange66ModelingArchitecturalLayersArchitecturallayerscanbemodeledusingpackagesstereotyped<<layer>>SoftwareLayersforaGenericJ2EEApplication

Note:<<global>>isamereconventionusedheretoindicatelayersthatcanbeusedbyallothers67WhereAreWe?DefinetheHigh-LevelOrganizationofSubsystemsIdentifyKeyAbstractionsDevelopDeploymentOverviewIdentifyAnalysisMechanisms68WhatAreKeyAbstractions?Akeyabstractionisaconcept,normallyuncoveredinRequirements,thatthesystemmustbeabletohandleSourcesforkeyabstractionsDomainknowledgeRequirementsGlossaryDomainModel,ortheBusinessModel(ifoneexists)69DescribingKeyAbstractionsKeyabstractionsaremodeledasanalysisclassesForeachclass,provideAshortdescriptionoftheclassItsmainattributesItsrelationshipswithotherclassesDon'tspendtoomuchtimedescribingclassesindetailatthisinitialstageThepurposeisnottoidentifyclassesthatwillsurvivethroughoutdesignYouwillprobablyidentifyclassesandrelationshipsnotactuallyneededbytheusecasesThisinitialsetofclassesisusefulto“jump-start”theUse-CaseAnalysistaskDonotturnthenextpagebeforebeingtoldtodoso!70GroupExerciseIdentifythekeyabstractionsfortheCourseRegistrationSystem71KeyAbstractionsfortheCourseRegistrationSystem72WhereAreWe?DefinetheHigh-LevelOrganizationofSubsystemsIdentifyKeyAbstractionsDevelopDeploymentOverviewIdentifyAnalysisMechanisms73DevelopDeploymentOverviewPurpose:TogainanunderstandingofthegeographicaldistributionandoperationalcomplexityofthesystemDevelopthehighleveloverviewofhowthesoftwareisdeployedtoshow:RemoteaccessDistributionacrossmultiplenodesExistinghardwareandsoftwarecomponents74WhereAreWe?DefinetheHigh-LevelOrganizationofSubsystemsIdentifyKeyAbstractionsDevelopDeploymentOverviewIdentifyAnalysisMechanisms75WhatAreAnalysisMechanisms?Analysismechanismsarearchitecturalmechanisms*usedearlyintheAnalysisandDesignprocess:CapturethekeyaspectsofasolutioninawaythatisimplementationindependentAre“computerscience”concepts,usuallyunrelatedtotheproblemdomainProvidespecificbehaviorstoadomain-relatedclassorcomponentExamples:PersistenceInter-processcommunicationErrororfaulthandlingNotificationMessagingEtc.*Architecturalmechanisms=Commonconcretesolutionstofrequentlyencounteredproblems76WhyUseAnalysisMechanisms?AnalysismechanismsareusedduringanalysistoreducethecomplexityofanalysisandtoimproveitsconsistencybyprovidingdesignerswithashorthandrepresentationforcomplexbehaviorOhno!Ifoundagroupofclassesthathaspersistentdata.HowamIsupposedtodesignthesethingsifIdon’tevenknowwhatdatabasewearegoingtobeusing?Thatiswhywehaveapersistenceanalysismechanism.Wedon’tknowenoughyet,sowecanbookmarkitandcomebacktoitlater.77IdentifyingandDescribingAnalysisMechanismsAnalysismechanismscanbeidentifiedtop-down(aprioriknowledge)orbottom-up(discoveredasyougoalong)Initiallythenamemightbeallthatexists(forinstance,persistence)Asclientclassesgetidentify,itesnecessarytoqualifytheuseofeachmechanismForpersistence,identifycharacteristicslikegranularity(size),volume(number),retrievalmechanism,updatefrequency,etc.Eventually,analysismechanismswillberefinedintodesignmechanismsAdesignmechanismassumessomedetailsoftheimplementationenvironment,butitisnottiedtoaspecificimplementationExample:DBMSasthedesignmechanismforpersistenceAnddesignmechanismsintoactualimplementationmechanismsExample:Oracle78ExercisePerformtheexerciseprovidedbytheinstructorObject-OrientedAnalysisandDesignwithUML2andRationalSoftwareModeler09.Use-CaseAnalysis80RoadmapfortheOOADCourseAnalysisArchitecturalAnalysis(DefineaCandidateArchitecture)Use-CaseAnalysis(AnalyzeBehavior)DesignIdentifyDesignElements(RefinetheArchitecture)IdentifyDesignMechanisms(RefinetheArchitecture)ClassDesign(DesignComponents)SubsystemDesign(DesignComponents)DescribetheRun-timeArchitectureandDistribution(RefinetheArchitecture)DesigntheDatabaseAnalysisDesign81Use-CaseAnalysisPurposeToidentifytheanalysisclassesofoursystem,including:their“responsibilities”,attributesandassociationstootherclasses,andusageofanalysismechanismsRoleDesignerMajorStepsCreateAnalysisUse-CaseRealizationSupplementtheUse-CaseDescriptionModelUse-CaseScenarioswithInteractionDiagramsModelParticipatingClassesinClassDiagramsReconciletheAnalysisUse-CaseRealizationsQualifyAnalysisMechanisms82AnalysisClasses:AFirstStepTowardExecutablesUseCasesAnalysis

ClassesSourceCodeExecDesign

ElementsUse-CaseAnalysis83WhereAreWe?CreateAnalysisUse-CaseRealizationSupplementtheUse-CaseDescriptionModelUse-CaseScenarioswithInteractionDiagramsModelParticipatingClassesinClassDiagramsReconciletheAnalysisUse-CaseRealizationsQualifyAnalysisMechanisms84WhatIsaUse-CaseRealization?ThebridgebetweenRequirements-centrictasksandAnalysis/Design-centrictasksItprovides:AwaytotracebehaviorintheAnalysisandDesignModelsbacktotheUse-CaseModelAconstructintheAnalysisandDesignModels,whichorganizesworkproductsrelatedtotheusecasebutwhichbelongtothedesignmodelTypicallyconsistofsequenceandclassdiagramsShownasacollaboration*stereotyped<<use-caserealization>>* UMLCollaboration=structureofcollaboratingelements(roles),eachperformingaspecializedfunction,whichcollectivelyplishsomedesiredfunctionality85WhatIsaUse-CaseRealization?ClassDiagramsCommunicationDiagramsUse-CaseModelAnalysis/DesignModelUseCaseUse-CaseRealizationSequence

DiagramsRealizationRelationship86WhereAreWe?CreateAnalysisUse-CaseRealizationSupplementtheUse-CaseDescriptionModelUse-CaseScenarioswithInteractionDiagramsModelParticipatingClassesinClassDiagramsReconciletheAnalysisUse-CaseRealizationsQualifyAnalysisMechanisms87SupplementtheUse-CaseDescriptionPurpose:Tocaptureadditionalinformationneededin