2Object-Oriented Analysis and Design with the Unified Process Events and Use Cases Use case Activity the system carries out Entry point into the

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


Figure 5-1Identifying Use Cases by Focusing on Users and their Goals


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


Figure 5-2Events Affecting a Charge Account Processing System that Lead to Use Cases


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


Figure 5-3External Event Checklist


Figure 5-4Temporal Event Checklist


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


Figure 5-5Temporal Event Checklist


Figure 5-6The Sequence of “Transactions” for One Specific Customer

Resulting in Many Events


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


Figure 5-7Events Deferred until Later Iterations


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


Figure 5-8External Events for the RMO Customer Support System


Figure 5-9Temporal Events for the RMO Customer Support System


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


Figure 5-10Information about each Event and the Resulting Use Case in an Event Table


Figure 5-11The Complete Event Table for the RMO Customer Support System


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


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


Figure 5-12Types of Things


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


Figure 5-13aPartial List of “Things” Based on Nouns for RMO


Figure 5-13bPartial List of “Things” Based on Nouns for RMO


Figure 5-13cPartial List of “Things” Based on Nouns for RMO


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


Figure 5-14Associations Naturally Occur between Things


Figure 5-15Multiplicity of Relationships


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


Figure 5-16Attributes and Values


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


Figure 5-17Objects Encapsulate Attributes and Methods


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


Figure 5-21An Expanded Domain Model Class Diagram Showing Attributes


Figure 5-24A Refined University Course Enrollment Domain Model Class

Diagram With an Association Class


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


Figure 5-25A Generalization/Specialization Hierarchy Notation for Motor Vehicles


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


Figure 5-27Whole-part (Aggregation) Associations Between a Computer and Its Parts


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


Figure 5-29University Course Enrollment Design Class Diagram (With Methods)


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


Figure 5-31Rocky Mountain Outfitters Domain Model Class Diagram


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)


Figure 5-32Rocky Mountain Outfitters Location Diagram


Figure 5-33aUse Case–location Matrix for the Rocky Mountain Outfitters

Customer Support System


Figure 5-33bUse Case–location Matrix for the Rocky Mountain Outfitters

Customer Support System


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

Documents

2Object-Oriented Analysis and Design with the Unified Process Events and Use Cases Use case Activity the system carries out Entry point into the