2. Objectives
Explain how events can be used to identify use cases that define requirements
Identify and analyze events and resulting use cases
Explain how the concept of problem domain classes also defines requirements
Identify and analyze domain classes needed in the system
Object-Oriented Analysis and Design with the Unified Process

3. Objectives (continued)
Read, interpret, and create a Unified Modeling Language (UML) domain model class diagram and design class diagram
Use a CRUD matrix to study the relationships between use cases and problem domain classes
Object-Oriented Analysis and Design with the Unified Process

4. Overview Objective: refine information gathered
Identify use cases and problem domain classes
Model problem domain classes with UML notation
Introduce use case modeling
Object-Oriented Analysis and Design with the Unified Process

5. 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

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

7. 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

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

9. Types of Events External Events Temporal Events State 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

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

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

12. 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

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

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

15. 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

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

17. 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

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

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

20. 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

21. 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

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

23. Problem Domain Classes
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

24. 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

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

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

27. Procedure for Developing an Initial List of Things
Ask these question about each noun to decide inclusion: Is it a unique “Thing” the System needs to know about? - Is it inside the Scope of the System under question? - Does the System need to remember more than one of these items?
Ask these question about each noun to decide exclusion: Is it really just a synonym for some other things already identified? - Is it just an Output produced from other identified information? - Is it just an Input that results in recording some other information?
Ask these questions about each Noun to decide further research: Is it likely to be an Attribute about some other Thing already Identified? - Is it something that I might need if assumptions changed?
Object-Oriented Analysis and Design with the Unified Process

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

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

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

31. 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

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

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

34. 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

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

36. 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

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

38. 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

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

40. 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

41. 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

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

43. 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

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

45. 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

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

47. 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

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

49. 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

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

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

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

53. 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

54. Summary Requirements discipline defines business functions
Key concepts: use cases and problem domain classes
Use cases derive from elementary business processes (EBPs)
Three event types: external, temporal, and state
Problem domain class: category based on OOA
Object-Oriented Analysis and Design with the Unified Process

55. Summary (continued) Multiple associations among classes
Attributes: specific information about a thing
Actual software classes include behaviors (methods) and attributes
UML class diagrams show classes, attributes, methods, and associations
Domain model class diagram show domain classes in the users’ work environment
Object-Oriented Analysis and Design with the Unified Process

56. Summary (continued) Design class diagram models software classes
Generalization/specialization hierarchies allow inheritance from a superclass to a subclass
Whole-part hierarchies allow a collection of objects to be associated as a whole and its parts
Requirements are also defined with location diagrams, and matrices
Object-Oriented Analysis and Design with the Unified Process