Explain how events can be used to identify use cases that define requirements Identify and analyze events and resulting use cases Explain how the

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 2

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


Objective: refine information gathered

Identify use cases and problem domain classes

Model problem domain classes with UML notation

Introduce use case modeling


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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)

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

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

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



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


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


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

Documents

Explain how events can be used to identify use cases that define requirements Identify and analyze events and resulting use cases Explain how the