Use-Case Analysis. Architecture Oriented Analysis. R. Kuehl/J. Scott Hawker p. 1 R I T. Software Engineering

Transcription

1 Use-Case Analysis Architecture Oriented Analysis R. Kuehl/J. Scott Hawker p. 1

2 Notes The slides are based on UML use-case analysis techniques This is an introduction detailed techniques and notation will not be covered (see UML references) Learning the general use case analysis thought process is more important than any specific technique R. Kuehl/J. Scott Hawker p. 2

3 Use-Case Analysis - Steps Supplement the Use-Case Description For each use-case Find classes from use-case behavior Distribute use-case behavior to classes Model analysis class interactions in interaction diagrams For each resulting analysis class Describe responsibilities and attributes Describe associations Unify analysis classes Review checkpoints R. Kuehl/J. Scott Hawker p. 3

4 Step: Supplement the Use-Case Description Use-Case Specification The system displays a list of course offerings. Supplemented Use-Case Specification The system retrieves a list of course offerings from the course catalog legacy database. The system displays the course offerings. Capture additional information needed to understand the required internal behavior of the system Note: more detail may expose some solution structure R. Kuehl/J. Scott Hawker p. 4

5 Step: Find Classes from Use-Case Behavior The complete behavior of a use-case must be allocated to analysis classes Use-Case Specification I.e., functional decomposition R. Kuehl/J. Scott Hawker p. 5

6 Stereotypes as Analysis Classes Separation of concerns - system interface from application logic/control flow from persistent information as specialized class objects (in UML) Stereotype classes: Boundary Boundary classes: system boundary Interaction between the system and its actors Entity Control Entity classes: system information and associated behavior Control classes: system behavior coordination and sequencing Use-case flow of events R. Kuehl/J. Scott Hawker p. 6

7 Stereotype Class Collaboration Pattern Use Case <<actor>> Boundary Control Boundary External System Actor Boundary Entity Entity R. Kuehl/J. Scott Hawker p. 7

8 Why Stereotype Analysis Classes? Class stereotypes help Clarify and separate class roles - encapsulate Separate things that tend to change independently - modularize Class stereotypes are conceptually straightforward to begin analysis Supplement with non stereotype classes in future elaborations as needed Stereotype classes tend to go away in design Design pattern analogy model-view-controller R. Kuehl/J. Scott Hawker p. 8

9 Alternate Visualizations of the Same Thing <<boundary>> Boundary Boundary Boundary <<control>> Control Control Control <<entity>> Entity Entity Entity UML allows multiple graphical representations ( syntax ) of the same conceptual (semantic) model element R. Kuehl/J. Scott Hawker p. 9

10 Boundary Classes Model interaction between the system and its external environment Human user interaction External system interfaces External device interfaces Transform interchanged information and events Isolate internal and external system changes Changes to a communication protocol or GUI are isolated R. Kuehl/J. Scott Hawker p. 10

11 Finding Boundary Classes Student RegisterForCoursesForm Register For Courses <<actor>> Course catalog system CourseCatalogSystem Start with one boundary class per actor/use-case pair Consider all external information and events Concentrate on the responsibilities (NOT the details) User interface classes What information is presented and collected (NOT the GUI) System and device interface classes What protocols must be defined NOT how they are implemented R. Kuehl/J. Scott Hawker p. 11

12 Entity Classes Entity objects represent the information and resources managed inside the system Data (usually persistent) Structure (relationships) within and between objects Behavior associated with the information - passive Typically not specific to one use-case; examples: Banking: Account, Loan Actor related information: Student, Customer A technique: study the nouns Glossary, business/domain model, use-case flow of events, key abstractions (from architectural analysis) R. Kuehl/J. Scott Hawker p. 12

13 Key Abstractions Identify Key Objects in the Domain (e.g., Noun/Verb Analysis ) Student Professor Schedule Example: Wylie College Course Registration System CourseOffering Course CourseCatalog R. Kuehl/J. Scott Hawker p. 13

14 Control Classes Student Register For Courses <<actor>> Course catalog system Control classes model work flow Directs, coordinates tasks or jobs Typically, one control class per use case Delegates actor-visible behavior to the entity classes Orchestrate and Delegate Behavior Examples of control class responsibilities RegistrationController Decision logic (control the flow of events; state-dependent flows) Exception handling Computational algorithms Resource coordination Transaction management R. Kuehl/J. Scott Hawker p. 14

15 Analysis Classes for Register for Courses Student Register For Courses External system Course catalog system Requirements (Use-Case) Model Analysis Model View of Participating Classes in Use-Case Realization Register for Courses Student RegisterForCoursesForm RegistrationController External system CourseCatalogSystem Course catalog system Student Schedule CourseOffering R. Kuehl/J. Scott Hawker p. 15

16 Step: Distribute Use-Case Behavior to Classes For each use-case flow of events (primary and exceptions) Identify participating analysis classes Allocate use-case responsibilities to those analysis classes Use analysis class stereotypes as a starting point and guide Boundary classes Entity classes Control classes Add supporting classes as necessary to expand and clarify model R. Kuehl/J. Scott Hawker p. 16

17 Guidelines: Allocating Responsibilities to Classes (continued) Who has the information needed to perform the responsibility? If one class, put the responsibility with the information If multiple classes, one class to model information with relationships to classes needed to perform the responsibility Cohesion and coupling rules Keep the client-supplier responsibilities clear clients need information and suppliers provide and manage information Re-factor Re-allocate data and responsibility among classes Reuse: Assign new responsibility to a class that has similar responsibility R. Kuehl/J. Scott Hawker p. 17

18 Step: Model Analysis Class Interactions in Interaction Diagrams Model analysis class behavior in UML communication and/or sequence interaction diagrams One interaction diagram for each variant of a usecase s flow of events Communication diagrams help focus on class responsibilities and relationships Sequence diagrams to capture details and trace flow of control Interaction diagrams should be traceable from use case flow steps Other behavioral modeling can also be used; e.g., state machines R. Kuehl/J. Scott Hawker p. 18

19 Sequence Diagrams The classes Client Supplier Client object Supplier object PerformResponsibility() PerformAnotherResponsibility() Object Lifeline : Client : Supplier 1. PerformResponsibility Reflexive message (Message to self) 1.1. PerformAnotherResponsibility Message Focus of Control (Activation) Hierarchical message numbering Sequence diagrams illustrate how objects interact with each other dynamically R. Kuehl/J. Scott Hawker p. 19

20 Build a Sequence Diagram for Register for Courses : Student Student wishes to create a new schedule A list of the available course offerings for this semester are displayed A blank schedule is displayed for the students to select offerings 1: // create schedule( ) : RegisterForCoursesForm 2: // get course offerings( ) 5: // display course offerings( ) 6: // display blank schedule( ) : RegistrationController : CourseCatalogSystem 3: // get course offerings() 4: // get course offerings( ) : Course Catalog : Schedule : Student Basic flow, create a schedule portion 7: // select 4 primary and 2 alternate offerings( ) 8: // create schedule with offerings( ) 9: // create with offerings( ) 10: // add schedule(schedule) At this, point the Submit Schedule subflow is executed. Sequence Diagram: Register for Courses / Register for Courses - Basic Flow (Submit Schedule) R. Kuehl/J. Scott Hawker p. 20

21 Communication Diagrams Communication diagrams show the static interactions and links among a set of collaborating objects. Message 1.1. PerformAnotherResponsibility : Client 1. PerformResponsibility : Supplier Client object Link Note: The client initiates the behavior and needs it done, the supplier is responsible for carrying out the behavior at the client s request. Supplier object R. Kuehl/J. Scott Hawker p. 21

22 Communication Diagram for Register for Courses Basic flow, create a schedule portion 5: // display course offerings( ) 6: // display blank schedule( ) 1: // create schedule( ) 7: // select 4 primary and 2 alternate offerings( ) : RegisterForCoursesForm : Student 2: // get course offerings( ) 8: // create schedule with offerings( ) 4: // get course offerings( ) : Course Catalog : RegistrationController 3: // get course offerings() : CourseCatalogSystem 9: // create with offerings( ) 10: // add schedule(schedule) : Student : Schedule R. Kuehl/J. Scott Hawker p. 22

23 Use-Case Analysis - Steps Supplement the Use-Case Description For each use-case Find classes from use-case behavior Distribute use-case behavior to classes Model analysis class interactions in interaction diagrams For each resulting analysis class add more detail Describe responsibilities and attributes Describe associations Unify analysis classes Review checkpoints R. Kuehl/J. Scott Hawker p. 23

24 Step: Describe Responsibilities A responsibility is an action an object can be invoked to provide or do Actions the object can perform on request Associated knowledge the object maintains and provides to other objects Messages on interaction diagrams define responsibilities Responsibilities evolve into one or more operations on classes in design Document responsibilities in one of two ways As analysis operations in diagrams Class operations with // pre-pended as a naming convention As textual description of the analysis class : Client // PerformAnotherResponsibility // PerformResponsibility Supplier : Supplier // PerformResponsibility // PerformAnotherResponsibility R. Kuehl/J. Scott Hawker p. 24

25 Communication Diagram for Register for Courses Basic flow, create a schedule portion with responsibilities 5: // display course offerings( ) 6: // display blank schedule( ) 1: // create schedule( ) 7: // select 4 primary and 2 alternate offerings( ) <<boundary>> RegisterForCoursesForm // submit schedule() // display course offerings() // display schedule() // create schedule() // select 4 primary 1: and // 2 create alternate schedule( offerings() ) // display blank schedule() 4: // get course offerings( ) : Course Catalog : Student 2: // get course offerings( ) 8: // create schedule with offerings( ) <<control>> RegistrationController // get course offerings() 1 // submit schedule() // create schedule with offerings() 3: // get course offerings() 9: // create with offerings( ) <<boundary>> CourseCatalogSystem // get course offerings() <<entity>> Student // add schedule() // has pre-requisites() 10: // add schedule(schedule) <<entity>> Schedule // create with offerings() // submit() // save() R. Kuehl/J. Scott Hawker p. 25

26 Step: Describe Attributes UML Notation Attributes represent information relevant to the domain During analysis, attribute types should be from the domain, not from the programming language Attribute names should clearly state what information the attribute holds Supplement with attribute description if necessary Use case Nouns that did not become classes Significant information for the class <<stereotype>> ClassName - (Private) Name : Type = InitialValue + (Public) Name: Type = InitialValue # (Protected) Name : Type = InitialValue <<entity>> CourseOffering coursenumber : String starttime : Time endtime : Time days : Enumeration numstudents : Integer R. Kuehl/J. Scott Hawker p. 26

27 Step: Describe Associations Associated with - a contextual relationship between objects of different classes They know about each other They are connected to each other For each X there is a Y An instance of an association between two objects (instances) is called a link The line between them Arrows show navigation J Clark : Professor Student. 1 CourseOffering courses Professor instructor n 0..n 0..n 1 Schedule prerequisites Course 0..n BIO_ : CourseOffering 0..n R. Kuehl/J. Scott Hawker p. 27

28 Association Labels Association names label the association link Verb phrase with one class the verb subject and the other the verb object Association roles define the contextual role an object instance plays for its associated object instance The face it presents to its associated object Acts like an alternative class name <<entity>> CourseOffering instructor teaches <<entity>> Professor departmenthead works in <<entity>> Department prerequisites <<entity>> Course 0..n (Class object Instances) R. Kuehl/J. Scott Hawker p. 28

29 Association Multiplicities There can be multiple associations between classes R. Kuehl/J. Scott Hawker p. 29

30 Finding Associations Start with a use-case realization interaction diagram Every link indicates that the object classes are related Define association name and role labels Define association multiplicities Navigability is optional Only model the more relevant domain links R. Kuehl/J. Scott Hawker p. 30

31 Associations Example 1 1 RegisterForCoursesForm RegistrationController currentschedule +registrant alternatecourses n n 1 0..n +primarycourses Student. Schedule CourseOffering R. Kuehl/J. Scott Hawker p. 31

32 <<boundary>> RegisterForCoursesForm // submit schedule() // display course offerings() // display schedule() // create schedule() // select 4 primary and 2 alternate offerings() // display blank schedule() <<entity>> Student // add schedule() // has pre-requisites() Register for Courses Realization (Complete View of Participating Classes) Show the classes, attributes, responsibilities, and associations involved in realizing this use case +registrant 0..1 <<control>> RegistrationController // get course offerings() 1 1 // submit schedule() // create schedule with offerings() currentschedule 0..1 <<entity>> Schedule grade <<boundary>> CourseCatalogSystem 0..n 1 // get course offerings() <<entity>> PrimaryScheduleOfferingInfob // is enrolled in?() // mark as enrolled in() <<entity>> CourseOffering number : String = "100" starttime : Time endtime : Time days : Enum +primarycourses // create with offerings() 1 0..n 0..n 0..4 // submit() // save() // add student() 0..n 0..2 // still open?() +alternatecourses // save().. The final object model for realizing the use case <<entity>> ScheduleOfferingInfo status // mark as selected() // is selected?() R. Kuehl/J. Scott Hawker p. 32

33 Step: Unify Analysis Classes Derive One Analysis Model Identify classes in the context of individual use cases for all the system s use cases Unify the individual results across all the use cases Merge classes that define similar behavior or represent the same phenomenon Merge entity classes that define the same attributes, even if their behavior is different (merge the behaviors) R. Kuehl/J. Scott Hawker p. 33

34 Step: Review Checkpoints Use-Case Level Have all use case main and sub-flows been handled, including exceptional cases? Have all the required classes been found? Has all behavior been unambiguously distributed to the right classes? Are all interaction diagram relationships clear and consistent? Can you trace class behavior back to use case scenarios? Have classes been unified across all use cases? R. Kuehl/J. Scott Hawker p. 34

35 Review Checkpoints Analysis Class Level Does the class represent a single, well-defined abstraction of the required behavior? Are all appropriate class collaborative relationships identified? Does the name of each class clearly reflect the role it plays? Are all attributes and responsibilities addressed and functionally cohesive? Are there unnecessary attributes or relationships? (remove them!) R. Kuehl/J. Scott Hawker p. 35

36 Conclusion Use-Case Analysis is a useful technique for requirements validation From the use case requirements can I identify a feasible interaction of objects? Are the requirements complete, correct, etc.? A side-effect is developing one possible object design approach The Rational Unified Process provides a useful technique for use-case analysis Boundary, Entity, and Control classes in collaboration Judge in context how much breadth and depth of use case analysis is valuable. R. Kuehl/J. Scott Hawker p. 36