2. 2Object-Oriented Analysis and Design with the Unified Process 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

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

4. 4Object-Oriented Analysis and Design with the Unified Process 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

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

6. 6Object-Oriented Analysis and Design with the Unified Process 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

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

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

9. 9Object-Oriented Analysis and Design with the Unified Process 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

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

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

12. 12Object-Oriented Analysis and Design with the Unified Process 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

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

14. 14Object-Oriented Analysis and Design with the Unified Process 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

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

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

17. 17Object-Oriented Analysis and Design with the Unified Process 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

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

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

20. 20Object-Oriented Analysis and Design with the Unified Process 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

21. 21Object-Oriented Analysis and Design with the Unified Process 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

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

23. 23Object-Oriented Analysis and Design with the Unified Process Procedure for Developing an Initial List of Things  List nouns users 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

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

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

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

27. 27Object-Oriented Analysis and Design with the Unified Process 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

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

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

30. 30Object-Oriented Analysis and Design with the Unified Process 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

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

32. 32Object-Oriented Analysis and Design with the Unified Process 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

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

34. 34Object-Oriented Analysis and Design with the Unified Process 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

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

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

37. 37Object-Oriented Analysis and Design with the Unified Process 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

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

39. 39Object-Oriented Analysis and Design with the Unified Process 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

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

41. 41Object-Oriented Analysis and Design with the Unified Process 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

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

43. 43Object-Oriented Analysis and Design with the Unified Process 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

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

45. 45Object-Oriented Analysis and Design with the Unified Process 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)

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

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

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

49. 49Object-Oriented Analysis and Design with the Unified Process 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