CS427: Software Engineering IAdministrative infoTopics this weekSlide 4UML sequence diagramsSequence diagram for claimSummary of class diagramActivities in RUPResult of requirements captureWorkers and their artifactsWorkflow for requirementsSystem analystArchitectUse-case specifierUI designRequirements specificationAnalysis modelStereotypesPackagesSlide 20Packages and dependenciesWorkflow for analysisSlide 23Slide 24Use case engineerComponent engineerOutline of RUP process for analysisObject diagramExample class diagramExample object diagramSummaryXPNext: Exam, specifications1CS427:Software Engineering IDarko Marinov(slides from Ralph Johnson)CS427 11-2Administrative infoHW1: Ask for regrading if you think we erredProject groups forming slowlyProject fair: Oct 6 or Oct 13?Oct 13: Deadline for 8-student groupsMidterm reminder7pm on Oct 10 (Tue) in 1404 SC (not DCL!)Makeup exam: 12:30pm on Oct 10 in 1310 DCLLet us know if you have other conflicts“Study guide” and samples available on WikiCS427 11-3Topics this weekUnified Modeling Language (UML) introGraphical modeling notations for describing and designing (OO software) systems, 13 diagramsStructure•Class diagrams (previous lecture)•Object diagrams (today)•Package diagrams (today)Behavior•Use-case diagrams (previous lectures)•Sequence diagrams (today)Analysis and design in RUPCS427 11-4A 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 . . nReminder: Example class diagramWhere do multiplicites go? Correct here?Questions? Come to office hours (Thu 2-3, Mon 3-4) or email us!CS427 11-5UML sequence diagramsModel how a set of objects communicateDescribe sequence of events (traces)A line for each objectTime goes from top to bottomArrows represent communication eventsCS427 11-6Sequence diagram for claima u t o m a t i cc l a i m p r o c .a n A d j u d . a c l a i mm a i n f r a m es y s t e mp o s t a ls y s t e mh a n d l e c l a i m* g e t d a t aa c c e p t o rr e j e c t[ a c c e p t ] h a n d l e c l a i m[ r e j e c t ] s e n d l e t t e rCorrect lifetime and activation?CS427 11-7Summary of class diagramCentral model for OO systemsDescribes data and behaviorIn UML, used along with Use Cases and Packages for analysisAlso used to describe implementationDon’t confuse analysis and implementation!Separate “what” from “how”CS427 11-8Activities in RUPRequirements capture: learning what the system is to doAnalysis: transform requirements closer to the software design; classes and subsystemsEnsure that functional requirements are metDesign: move closer to implementationEnsure that non-functional requirements are metCS427 11-9Result of requirements captureVisionUse-case model with detailed description of each use caseSet of user interface sketches and prototypesRequirements document for generic requirementsCS427 11-10Workers and their artifactsSystem analystUse-case model (diagram)ActorsGlossaryArchitect - Architecture description Use-case specifier - Use-casesUser interface designer User interface prototypeCS427 11-11Workflow for 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-12System analystDetermines actors and use cases based on knowledge of systemInterviews users to discover more use cases and actorsCS427 11-13ArchitectDetermine which use cases need to be developed firstHigh priority use casesDescribe important and critical functionalitySecurityDatabaseHard to retrofit laterCS427 11-14Use-case specifierCreate detailed descriptions of use casesWorks closely with real users of use caseCS427 11-15UI 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 paperTest on real usersCS427 11-16Requirements specificationNot all requirements go in a use caseExample: securityExample: global performanceRequirements document describes all other requirements that are not suitable for use casesCS427 11-17Analysis 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-18StereotypesA 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-19PackagesLogical grouping Used toDivide large system into smaller subsystemsShow dependencies between subsystemsCan containClass diagrams or packagesUse cases, sequence diagrams, etc.CS427 11-20PackagesI 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-21Packages 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-22Workflow 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 …
View Full Document