Analysis and Design in RUPActivities in RUPResult of Requirements CaptureWorkers and their artifactsWorkflow for capturing requirementsSystems analystArchitectUse-case specifierUI designRequirements SpecificationAnalysis modelStereotypesPackagesSlide 14Packages and dependenciesWorkflow for analysisSlide 17Slide 18Use case engineerComponent EngineerOutline of RUP process for analysisObject diagramClass diagramClass and object diagramsSummaryXPSlide 27Next time1Analysis and Design in RUPCS427 11-2Activities in RUPRequirements : learning what the system is to doAnalysis: transform requirements to something that maps well to the software designers area of concern; classes and subsystems. Ensures that functional requirements are met.Design: move closer to implementation. Ensure that non-functional requirements are met.CS427 11-3Result of Requirements CaptureVisionUse-case model with detailed description of each use caseSet of user interface sketches and prototypesRequirements document for generic requirementsCS427 11-4Workers and their artifactsSystem analystuse-case model (diagram)actorsglossaryArchitect - Architecture description Use-case specifier - Use-casesUser interface designer User interface prototypeCS427 11-5Workflow for capturing requirementsS y s t e m A n a l y s tA r c h i t e c tU s e - C a s e s p e c i f i e rU I D e s i g n e rF i n d A c t o r s a n dU s e C a s e sD e s c r i b e U s eC a s e i n D e t a i lP r i o r i t i z eU s e C a s e sP r o t o t y p e U . I .S t r u c t u r e t h eU s e C a s e M o d e lCS427 11-6Systems analystDetermines actors and use cases based on knowledge of system.Interviews users to discover more use cases and actors.CS427 11-7ArchitectDetermine which use cases need to be developed first.High priority use casesdescribe important and critical functionalitysecuritydatabasehard to retrofit laterCS427 11-8Use-case specifierCreate detailed descriptions of use casesWorks closely with real users of use caseCS427 11-9UI designLogical designWhich user-interface elements are needed for each use case?What information does the actor need to receive from or give to the system?PrototypingOften is on paper.Test on real usersCS427 11-10Requirements SpecificationNot all requirements go in a use case.Example: securityExample: global performanceRequirements document describes all other requirements that are not suitable for use cases.CS427 11-11Analysis modelClass diagramsvague interfaces (“responsibilities”)vague associations (ignore navigability)stereotype classes: boundary - UI, associated with actorcontrol - control associated with a use caseentity - persistent, the “real” objectsUse-case realization (Analysis)CS427 11-12StereotypesA d j u d i c a t o r+ h a n d l e c l a i m ( )+ I D : s t r i n gC l a i m+ a c c e p t / r e j e c t ( )- f i e l d 1 : a n y- f i e l d 2 : a n yP o s t a l s y s t e m+ s e n d l e t t e r ( )M a i n f r a m e s y s t e m+ h a n d l e c l a i m ( )0 . . 10 . . nA u t o m a t i c c l a i m p r o c e s s o r+ h a n d l e c l a i m ( )0 . . n<<boundary>><<entity>><<boundary>><<control>><<boundary>>CS427 11-13PackagesLogical grouping Used todivide large system into smaller subsystemsshow dependencies between subsystemsCan containclass diagrams or packagesuse cases, sequence diagrams, etc.CS427 11-14PackagesI m a g e p r o c e s s i n g C l a i m s« F a c a d e »C l a i m s p r o c e s s i n g s y s t e mM a i n f r a m e i n t e r f a c eCS427 11-15Packages and dependenciesReduce couplingIncrease cohesionIn packagescohesion is between classes in a packagecoupling is between classes in different packagesIn classescohesion is between methods in a classcoupling is between methods in different classesCS427 11-16Workflow for analysisA r c h i t e c tU s e - C a s e E n g i n e e rC o m p o n e n t E n g i n e e rA r c h i t e c t u r a lA n a l y s i sA n a l y z e a c l a s sA n a l y z e a U s eC a s eA n a l y z e ap a c k a g eCS427 11-17ArchitectResponsible for the integrity of analysis modelMakes sure packages fit togetherMakes sure each package is goodIdentifies obvious entity classesLets other classes be defined during use-case realizations and component analysisCS427 11-18ArchitectIdentify common special requirementsPersistenceDistribution and concurrencySecurityFault toleranceTransaction managementCS427 11-19Use case engineerIdentify analysis classes needed by use-caseBoundary classes, control classes, entity classesDistribute behavior of use-case to classesMake use-case realization: a precise description of use-casesequence diagramcollaboration diagramCS427 11-20Component EngineerAnalyze classesGather information from use casesMake sure class is coherentMake model as simple as possible, but no simpler.Analyze a packageRelationships between classesRelationships between packagesCS427 11-21Outline of RUP process for analysisFind use casesArchitect determines orderRepeatedly, take next use casechange class diagram to accommodate use casesimplify class diagramCS427 11-22Object diagramSnapshot of objects in a system at a point in timeIf there is just one object of each class, the class diagram and the object diagram are the sameAs classes become more reusable, object diagram becomes more interestingCS427 11-23Class diagramA d j u d i c a t o r+ h a n d l e c l a i m ( )+ I D : s t r i n gC l a i m+ a c c e p t / r e j e c t ( )- f i e l d 1 : a n y- f i e l d 2 : a n yP o s t a l s y s t e m+ s e n d l e t t e r ( )M a i n f r a m e s y s t e m+ h a n d l e c l a i m ( )0 . . 10 . . nA u t o m a t i c c l a i m p r o c e s s o r+ h a n d l e c l a i m ( )0 . . n<<boundary>><<entity>><<boundary>><<control>><<boundary>>CS427 11-24Class and object diagramsJan:AdjudicatorJim:Adjudicator:Claim Processor102:Claim103:Claim104:Claim105:Claim101:ClaimId:301478334Id:620194211CS427 11-25SummaryAnalysis is converting vague user needs into a precise model of what the system should do.Analysis is incremental; look at one piece of the problem at a time.Requires continually changing the model until you are done.CS427 11-26XPCustomer
View Full Document