1. Lecture 5 Introduction to Use Case Analysis and the Analysis Model Introduction to the UML

2. Elaboration Phase in Detail 4 Use Case Analysis –Find and understand 80% of architecturally significant use cases and actors by the end of the Elaboration Phase –Prototype User Interfaces –Prioritize Use Cases within the Use Case Model –Detail the architecturally significant Use Cases (write and review them) 4 Prepare Domain Model of architecturally significant classes, and identify their responsibilities and central interfaces (View of Participating Classes)

3. Use Case Analysis 4 What is a Use Case? –A sequence of actions a system performs that yields a valuable result for a particular actor. 4 What is an Actor? –A user or outside system that interacts with the system being designed in order to obtain some value from that interaction 4 Use Cases describe scenarios that describe the interaction between users of the system and the system itself. 4 Use Cases describe WHAT the system will do, but never HOW it will be done.

4. What’s in a Use Case? 4 Define the start state and any preconditions that accompany it 4 Define when the Use Case starts 4 Define the order of activity in the Main Flow of Events 4 Define any Alternative Flows of Events 4 Define any Exceptional Flows of Events 4 Define any Post Conditions and the end state 4 Mention any design issues as an appendix 4 Accompanying diagrams: State, Activity, Sequence Diagrams 4 View of Participating Objects (relevant Analysis Model Classes) 4 Logical View: A View of the Actors involved with this Use Case, and any Use Cases used or extended by this Use Case

5. Use Cases Describe Function not Form 4 Use Cases describe WHAT the system will do, but never HOW it will be done. 4 Use Cases are Analysis Products, not Design Products.

6. Use Cases Describe Function not Form 4 Use Cases describe WHAT the system should do, but never HOW it will be done 4 Use cases are Analysis products, not design products

7. Benefits of Use Cases 4 Use cases are the primary vehicle for requirements capture in RUP 4 Use cases are described using the language of the customer (language of the domain which is defined in the glossary) 4 Use cases provide a contractual delivery process (RUP is Use Case Driven) 4 Use cases provide an easily-understood communication mechanism 4 When requirements are traced, they make it difficult for requirements to fall through the cracks 4 Use cases provide a concise summary of what the system should do at an abstract (low modification cost) level.

8. Difficulties with Use Cases 4 As functional decompositions, it is often difficult to make the transition from functional description to object description to class design 4 Reuse at the class level can be hindered by each developer “taking a Use Case and running with it”. Since UCs do not talk about classes, developers often wind up in a vacuum during object analysis, and can often wind up doing things their own way, making reuse difficult 4 Use Cases make stating non-functional requirements difficult (where do you say that X must execute at Y/sec?) 4 Testing functionality is straightforward, but unit testing the particular implementations and non-functional requirements is not obvious

9. Use Case Model Survey 4 The Use Case Model Survey is to illustrate, in graphical form, the universe of Use Cases that the system is contracted to deliver. 4 Each Use Case in the system appears in the Survey with a short description of its main function. –Participants: Domain Expert Architect Analyst/Designer (Use Case author) Testing Engineer

10. Sample Use Case Model Survey

11. Analysis Model 4 In Analysis, we analyze and refine the requirements described in the Use Cases in order to achieve a more precise view of the requirements, without being overwhelmed with the details 4 Again, the Analysis Model is still focusing on WHAT we’re going to do, not HOW we’re going to do it (Design Model). But what we’re going to do is drawn from the point of view of the developer, not from the point of view of the customer 4 Whereas Use Cases are described in the language of the customer, the Analysis Model is described in the language of the developer: –Boundary Classes –Entity Classes –Control Classes

12. Why spend time on the Analysis Model, why not just “face the cliff”? 4 By performing analysis, designers can inexpensively come to a better understanding of the requirements of the system 4 By providing such an abstract overview, newcomers can understand the overall architecture of the system efficiently, from a ‘bird’s eye view’, without having to get bogged down with implementation details. 4 The Analysis Model is a simple abstraction of what the system is going to do from the point of view of the developers. By “speaking the developer’s language”, comprehension is improved and by abstracting, simplicity is achieved 4 Nevertheless, the cost of maintaining the AM through construction is weighed against the value of having it all along.

13. Boundary Classes 4 Boundary classes are used in the Analysis Model to model interactions between the system and its actors (users or external systems) 4 Boundary classes are often implemented in some GUI format (dialogs, widgets, beans, etc.) 4 Boundary classes can often be abstractions of external APIs (in the case of an external system actor) 4 Every boundary class must be associated with at least one actor:

14. Entity Classes 4 Entity classes are used within the Analysis Model to model persistent information 4 Often, entity classes are created from objects within the business object model or domain model

15. Control Classes 4 The Great Et Cetera 4 Control classes model abstractions that coordinate, sequence, transact, and otherwise control other objects 4 In Smalltalk MVC mechanism, these are controllers 4 Control classes are often encapsulated interactions between other objects, as they handle and coordinate actions and control flows.

16. Relationships in UML 4 Dependency 4 Association 4 Generalization 4 Realization

17. The Dependency Relationship 4 A dependency is a semantic relationship between two things, where a change in interface affects the dependent 4 One object is dependent on the interface of another, either because: –it instantiates the other object (constructor dependence), cf. A factory –it parameterizes the other class (interface dependence) 4 Dependency relationships are usually short-lived in terms of lifespan

18. The Association Relationship 4 An association is a structural relationship between two things, indicating some type of relationship exists between the two things 4 Two types: –generic association –aggregation (whole/part)

19. Aggregation 4 Aggregation specifies a particular type of relationship, one where one class aggregates, or contains, another. 4 Aggregation specifies a whole/part relationship 4 Aggregation specifies a has a relationship, one thing has another –A Department has Instructors –A School has Students (is a collection of students) 4 Lifespan association indeterminate

20. Composition 4 A stronger form of aggregation, which implies: –that the lifetimes of the whole and part are simultaneous (implicit construction/destruction of parts with whole) –the nonshareability of parts belonging to a single whole (No my dear, that’s my hand you’re holding!) 4 Longest lifespan relationship

21. Generalization Relationship 4 Specifies an inheritance of type relationship 4 Specifies an is-a relationship 4 States that a reference to a base class can stand for any derived type at any time. Or, objects of a derived type can be used anywhere the parent type is used. This is polymorphism.

22. Realization Relationship 4 A realization is a semantic relationship between classes, stating that one class contracts to implement the interface of another. 4 In RUP, a class can realize the interface of another, a design can realize a Use Case, and the Design Model can realize the Use Case Model