U of I CS 427 - Analysis and Design in RUP

Unformatted text preview:

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 RUPRequirements : learning what the system is to doAnalysis: 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 CaptureVisionUse-case model with detailed description of each use caseSet of user interface sketches and prototypesRequirements document for generic requirementsCS427 11-4Workers and their artifactsSystem analystuse-case model (diagram)actorsglossaryArchitect - Architecture description Use-case specifier - Use-casesUser 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 analystDetermines actors and use cases based on knowledge of system.Interviews users to discover more use cases and actors.CS427 11-7ArchitectDetermine which use cases need to be developed first.High priority use casesdescribe important and critical functionalitysecuritydatabasehard to retrofit laterCS427 11-8Use-case specifierCreate detailed descriptions of use casesWorks closely with real users of use caseCS427 11-9UI designLogical designWhich user-interface elements are needed for each use case?What information does the actor need to receive from or give to the system?PrototypingOften is on paper.Test on real usersCS427 11-10Requirements SpecificationNot all requirements go in a use case.Example: securityExample: global performanceRequirements document describes all other requirements that are not suitable for use cases.CS427 11-11Analysis modelClass diagramsvague interfaces (“responsibilities”)vague associations (ignore navigability)stereotype classes: boundary - UI, associated with actorcontrol - control associated with a use caseentity - persistent, the “real” objectsUse-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-13PackagesLogical grouping Used todivide large system into smaller subsystemsshow dependencies between subsystemsCan containclass diagrams or packagesuse 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 dependenciesReduce couplingIncrease cohesionIn packagescohesion is between classes in a packagecoupling is between classes in different packagesIn classescohesion is between methods in a classcoupling 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-17ArchitectResponsible for the integrity of analysis modelMakes sure packages fit togetherMakes sure each package is goodIdentifies obvious entity classesLets other classes be defined during use-case realizations and component analysisCS427 11-18ArchitectIdentify common special requirementsPersistenceDistribution and concurrencySecurityFault toleranceTransaction managementCS427 11-19Use case engineerIdentify analysis classes needed by use-caseBoundary classes, control classes, entity classesDistribute behavior of use-case to classesMake use-case realization: a precise description of use-casesequence diagramcollaboration diagramCS427 11-20Component EngineerAnalyze classesGather information from use casesMake sure class is coherentMake model as simple as possible, but no simpler.Analyze a packageRelationships between classesRelationships between packagesCS427 11-21Outline of RUP process for analysisFind use casesArchitect determines orderRepeatedly, take next use casechange class diagram to accommodate use casesimplify class diagramCS427 11-22Object diagramSnapshot of objects in a system at a point in timeIf there is just one object of each class, the class diagram and the object diagram are the sameAs 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-25SummaryAnalysis 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-26XPCustomer


View Full Document

U of I CS 427 - Analysis and Design in RUP

Download Analysis and Design in RUP
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Analysis and Design in RUP and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Analysis and Design in RUP 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?