Chapter 5 - Missouri State University
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 2
Figure 5-1
Identifying Use Cases by Focusing on Users and their Goals
Object-Oriented Analysis and Design with the Unified Process 3
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 4
Figure 5-2
Events Affecting a Charge Account Processing System that Lead to Use Cases
Object-Oriented Analysis and Design with the Unified Process 5
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 6
Figure 5-3
External Event Checklist
Object-Oriented Analysis and Design with the Unified Process 7
Figure 5-4
Temporal Event Checklist
Object-Oriented Analysis and Design with the Unified Process 8
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 9
Figure 5-5
Temporal Event Checklist
Object-Oriented Analysis and Design with the Unified Process 10
Figure 5-6
The Sequence of “Transactions” for One Specific Customer
Resulting in Many Events
Object-Oriented Analysis and Design with the Unified Process 11
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 12
Figure 5-7
Events Deferred until Later Iterations
Object-Oriented Analysis and Design with the Unified Process 13
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 14
Figure 5-8
External Events for the RMO Customer Support System
Object-Oriented Analysis and Design with the Unified Process 15
Figure 5-9
Temporal Events for the RMO Customer Support System
Object-Oriented Analysis and Design with the Unified Process 16
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 17
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 18
Figure 5-11
The Complete Event Table for the RMO Customer Support System
Object-Oriented Analysis and Design with the Unified Process 19
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 20
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 21
Figure 5-12
Types of Things
Object-Oriented Analysis and Design with the Unified Process 22
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 23
Figure 5-13a
Partial List of “Things” Based on Nouns for RMO
Object-Oriented Analysis and Design with the Unified Process 24
Figure 5-13b
Partial List of “Things” Based on Nouns for RMO
Object-Oriented Analysis and Design with the Unified Process 25
Figure 5-13c
Partial List of “Things” Based on Nouns for RMO
Object-Oriented Analysis and Design with the Unified Process 26
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 27
Figure 5-14
Associations Naturally Occur between Things
Object-Oriented Analysis and Design with the Unified Process 28
Figure 5-15
Multiplicity of Relationships
Object-Oriented Analysis and Design with the Unified Process 29
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 30
Figure 5-16
Attributes and Values
Object-Oriented Analysis and Design with the Unified Process 31
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 32
Figure 5-17
Objects Encapsulate Attributes and Methods
Object-Oriented Analysis and Design with the Unified Process 33
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 34
Figure 5-21
An Expanded Domain Model Class Diagram Showing Attributes
Object-Oriented Analysis and Design with the Unified Process 35
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 36
Hierarchies in Class Diagram
Notation
Generalization/specialization notation
I nheritance 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 37
Figure 5-25
A Generalization/Specialization Hierarchy Notation for Motor Vehicles
Object-Oriented Analysis and Design with the Unified Process 38
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 39
Figure 5-27
Whole-part (Aggregation) Associations Between a Computer and Its Parts
Object-Oriented Analysis and Design with the Unified Process 40
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 41
Figure 5-29
University Course Enrollment Design Class Diagram (With Methods)
Object-Oriented Analysis and Design with the Unified Process 42
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 43
Figure 5-31
Rocky Mountain Outfitters Domain Model Class Diagram
Object-Oriented Analysis and Design with the Unified Process 44
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 45
Figure 5-32
Rocky Mountain Outfitters Location Diagram
Object-Oriented Analysis and Design with the Unified Process 46
Figure 5-33a
Use Case–location Matrix for the Rocky Mountain Outfitters
Customer Support System
Object-Oriented Analysis and Design with the Unified Process 47
Figure 5-33b
Use Case–location Matrix for the Rocky Mountain Outfitters
Customer Support System
Object-Oriented Analysis and Design with the Unified Process 48
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 49
