Events and Use Cases

2. Events and Use Cases • Use case • Activity the system carries out • Entry point into the modeling process • Event decomposition: help identify use cases • Elementary business processes (EBPs) • Basic unit of analysis • Initiated by event occurring at specific time and place • Discrete system response that adds business value Object-Oriented Analysis and Design with the Unified Process

3. Figure 5-1 Identifying Use Cases by Focusing on Users and their Goals Object-Oriented Analysis and Design with the Unified Process

4. Event Decomposition • Event decomposition • Develops use cases based on system response to events • Perceives system as black box interfacing with external environment • Keeps focus on EBPs and business requirements • Analysts delegated particular events to decompose • Result of the decomposition: • List of use cases triggered by business events • Use cases at the right level of analysis Object-Oriented Analysis and Design with the Unified Process

5. Figure 5-2 Events Affecting a Charge Account Processing System that Lead to Use Cases Object-Oriented Analysis and Design with the Unified Process

6. Types of Events • External Events • Occur outside the system • Usually caused by external agent • Temporal Events • Occurs when system reaches a point (deadline) in time • State Events • Asynchronous events responding to system trigger Object-Oriented Analysis and Design with the Unified Process

7. Figure 5-3 External Event Checklist Object-Oriented Analysis and Design with the Unified Process

8. Figure 5-4 Temporal Event Checklist Object-Oriented Analysis and Design with the Unified Process

9. Identifying Events • Three rules of thumb • Distinguish events from prior conditions • Can the transaction complete without interruption? • Is the system waiting for next transaction? • Trace sequence of events initiated by external agent • Isolate events that actually touch the system Object-Oriented Analysis and Design with the Unified Process

10. Figure 5-5 Temporal Event Checklist Object-Oriented Analysis and Design with the Unified Process

11. Figure 5-6 The Sequence of “Transactions” for One Specific Customer Resulting in Many Events Object-Oriented Analysis and Design with the Unified Process

12. Identifying Events (continued) • Identify technology dependent events • Example: logon depending on system controls • Defer specifying technology dependent events • Perfect technology assumption: • Separates technology dependent events from functional requirements • Unlimited processing and storage capacity • Equipment does not malfunction • Users have ideal skill sets Object-Oriented Analysis and Design with the Unified Process

13. Figure 5-7 Events Deferred until Later Iterations Object-Oriented Analysis and Design with the Unified Process

14. Events in the Rocky Mountain Outfitters Case • Developing list of external events • Identify all people and organizational units that want something from the system • Developing list of temporal events • Identify regular reports and statements that system must produce at certain times Object-Oriented Analysis and Design with the Unified Process

15. Figure 5-8 External Events for the RMO Customer Support System Object-Oriented Analysis and Design with the Unified Process

16. Figure 5-9 Temporal Events for the RMO Customer Support System Object-Oriented Analysis and Design with the Unified Process

17. Looking At Each Event and the Resulting Use Case • Enter use cases in an event table • Event table includes rows and columns • Each row is a record linking an event to a use case • Columns represent key information   • RMO event table anatomizes customer support system Object-Oriented Analysis and Design with the Unified Process

18. Figure 5-10 Information about each Event and the Resulting Use Case in an Event Table Object-Oriented Analysis and Design with the Unified Process

19. Figure 5-11 The Complete Event Table for the RMO Customer Support System Object-Oriented Analysis and Design with the Unified Process

20. Problem Domain Classes • Problem domain • Set of work-related “things” in system component • Things have data representation within system • Examples: products, orders, invoices, customers • OO approach to things in problem domain • Objects that interact in the system • Identify and understand things in problem domain • Key initial steps in defining requirements Object-Oriented Analysis and Design with the Unified Process

21. Types of Things • Things can be identified with methodology • Separate the tangible from the intangible • Include information from all types of users • Ask important questions about nature of event • “What actions upon things should be acknowledged and recorded by the system?” • Example case: customer placing an order Object-Oriented Analysis and Design with the Unified Process

22. Figure 5-12 Types of Things Object-Oriented Analysis and Design with the Unified Process

23. Procedure for Developing an Initial List of Things • List nounsusers mention when discussing system • Event table as source of potential things • Use cases, external agents, triggers, response • Select nouns with questions concerning relevance • Further research may be needed Object-Oriented Analysis and Design with the Unified Process

24. Figure 5-13a Partial List of “Things” Based on Nouns for RMO Object-Oriented Analysis and Design with the Unified Process

25. Figure 5-13b Partial List of “Things” Based on Nouns for RMO Object-Oriented Analysis and Design with the Unified Process

26. Figure 5-13c Partial List of “Things” Based on Nouns for RMO Object-Oriented Analysis and Design with the Unified Process

27. Associations among Things • Analyst document entity associations ( relationships) • Example: “Is placed by” and “works in” • Associations apply in two directions • Customer places an order • An order is placed by a customer • Multiplicity: the number of associations • One to one or one to many  • The associations between types of things • Unary (recursive), binary, n-ary Object-Oriented Analysis and Design with the Unified Process

28. Figure 5-14 Associations Naturally Occur between Things Object-Oriented Analysis and Design with the Unified Process

29. Figure 5-15 Multiplicity of Relationships Object-Oriented Analysis and Design with the Unified Process

30. Attributes of Things • Specific details of things are called attributes • Analyst should identify attributes of things • Identifier (key): attribute uniquely identifying thing • Examples: Social Security number, vehicle ID number, or product ID number • Compound attribute is a set of related attributes • Example: multiple names for the same customer Object-Oriented Analysis and Design with the Unified Process

31. Figure 5-16 Attributes and Values Object-Oriented Analysis and Design with the Unified Process

32. Classes and Objects • Domain model class diagram as UML class • OOA applies domain model class diagram to things • Problem domain objects have attributes • Software objects encapsulate attributes and behaviors • Behavior: action that the object processes itself • Software objects communicate with messages • Information system is a set of interacting objects Object-Oriented Analysis and Design with the Unified Process

33. Figure 5-17 Objects Encapsulate Attributes and Methods Object-Oriented Analysis and Design with the Unified Process

34. Domain Model Class Diagram Notation • Class diagram key • General class symbol: rectangle with three sections • Sections convey name, attributes, and behaviors • Methods (behaviors) not shown in domain model class diagram • Lines connecting rectangles show associations • Multiplicity reflected above connecting lines • Domain class objects reflect business concern, policies, and constraints Object-Oriented Analysis and Design with the Unified Process

35. Figure 5-21 An Expanded Domain Model Class Diagram Showing Attributes Object-Oriented Analysis and Design with the Unified Process

36. Figure 5-24 A Refined University Course Enrollment Domain Model Class Diagram With an Association Class Object-Oriented Analysis and Design with the Unified Process

37. Hierarchies in Class Diagram Notation • Generalization/specialization notation • Inheritance hierarchy • Rank things the more general to the more special • Motor vehicle class includes trucks, cars, buses • Classification: means of defining classes of things • Superclass: generalization of a class • Subclass: specialization of a class Object-Oriented Analysis and Design with the Unified Process

38. Figure 5-25 A Generalization/Specialization Hierarchy Notation for Motor Vehicles Object-Oriented Analysis and Design with the Unified Process

39. Hierarchies in Class Diagram Notation (continued) • Whole-part Hierarchy Notation • “The whole is equal to the sum of the parts” • Two types of whole-part hierarchies • Aggregation: association with independent parts • Example: keyboard is part of computer system • Composition: association with dependent part • Example: CRT and monitor • Multiplicity applies to whole-part relationships Object-Oriented Analysis and Design with the Unified Process

40. Figure 5-27 Whole-part (Aggregation) Associations Between a Computer and Its Parts Object-Oriented Analysis and Design with the Unified Process

41. Hierarchies in Class Diagram Notation (continued) • Design Class Diagrams • Models classes into precise software analogs • Includes domain class information plus methods • Triangle symbol between classes indicates inheritance • Properties of attributes are shown with curly braces • Class fundamentals • Instances of a class (objects) manage their own data • Abstract classes are not instantiated (created) • Subclasses inherit attributes/behaviors from superclass Object-Oriented Analysis and Design with the Unified Process

42. Figure 5-29 University Course Enrollment Design Class Diagram (With Methods) Object-Oriented Analysis and Design with the Unified Process

43. The Rocky Mountain Outfitters Domain Class Diagram • Derives from noun list developed in Figure 5-13 • RMO domain class diagram shows attribute • Models do not show methods • Problem domain classes reflect high-level view of RMO use cases Object-Oriented Analysis and Design with the Unified Process

44. Figure 5-31 Rocky Mountain Outfitters Domain Model Class Diagram Object-Oriented Analysis and Design with the Unified Process

45. Locations and the Crud Matrix • Location diagrams store data for future reference • Shows need for network connections • Creates awareness of geographic reach • Use case–location matrix: shows where use cases are performed • Use case–domain class matrix: highlights access requirements  • Example: The RMO CRUD (create, read, update, and delete) Object-Oriented Analysis and Design with the Unified Process

46. Figure 5-32 Rocky Mountain Outfitters Location Diagram Object-Oriented Analysis and Design with the Unified Process

47. Figure 5-33a Use Case–location Matrix for the Rocky Mountain Outfitters Customer Support System Object-Oriented Analysis and Design with the Unified Process

48. Figure 5-33b Use Case–location Matrix for the Rocky Mountain Outfitters Customer Support System Object-Oriented Analysis and Design with the Unified Process

49. Use Cases, the Domain Model, and Iteration Planning • Select use cases for further development • Identify risks to determine priority • Core architecture typically selected/implemented first • Transition into elaboration phase • Converting use cases into software • Iteratively integrate software components into more complex systems • Begin testing of software Object-Oriented Analysis and Design with the Unified Process