Object oriented analysis and

design
Module 10: Use Case Analysis
 Objectives: Use-Case Analysis
• Explain the purpose of Use-Case Analysis
and where in the lifecycle it is performed
• Identify the classes which perform a use-
case flow of events
• Distribute the use-case behavior to those
classes, identifying responsibilities of the
classes
• Develop Use-Case Realizations that model
the collaborations between instances of the
identified classes
Use-Case Analysis in Context
[Early
Elaboration [Inception
Iteration] Iteration (Optional)]

Define a Candidate Perform

Architecture Architectural
Synthesis

Use-Case
Designer Analysis
Analyze Behavior

(Optional)
Refine the
Architecture

Design Design the

Components Database
 Use-Case Analysis Overview

Project Specific Software Use-Case Realization

Glossary Guidelines Architecture
Document

Use-Case
Supplementary
Specifications Analysis
Analysis Model

Use-Case Model Analysis Classes

 Use-Case Analysis Steps
• Supplement the Use-Case Description
• For each Use-Case Realization
– Find Classes from Use-Case Behavior
– Distribute Use-Case Behavior to Classes
• For each resulting analysis class
– Describe Responsibilities
– Describe Attributes and Associations
– Qualify Analysis Mechanisms
• Unify Analysis Classes
• Checkpoints
Supplement the Use-Case
Description

• The system
• The system retrieves and
displays a list displays a list of
of course current course
offerings. offerings from the
course catalog
legacy database.
 Use-Case Analysis Steps
• Supplement the Use-Case Description
• For each Use-Case Realization
– Find Classes from Use-Case Behavior
– Distribute Use-Case Behavior to Classes
• For each resulting analysis class
– Describe Responsibilities
– Describe Attributes and Associations
– Qualify Analysis Mechanisms
• Unify Analysis Classes
• Checkpoints
 Review: Class
• An abstraction
• Describes a group of objects with common:
– Properties (attributes)
– Behavior (operations)
– Relationships Class Name Professor
name
– Semantics Attributes ProfessorId : UniqueId

create()
Operations save()
delete()
change()
Review: Use-Case Realization
Use-Case Model Design Model

Use Case Use-Case Realization

Communication
Sequence Diagrams
Diagrams

Use Case
Class Diagrams
 Analysis Classes: A First Step
Toward Executables

Use Cases Analysis Design Source Exec

Classes Elements Code

Use-Case Analysis
 Find Classes from Use-Case
Behavior
• The complete behavior of a use case has
to be distributed to analysis classes
 What Is an Analysis Class?
<<boundary>> <<entity>>

System System
boundary information

<<control>> <<boundary>>

System
Use-case
boundary
behavior
coordination <<entity>>

System
information
 What Is a Boundary Class?
• Intermediates between the interface and
something outside the system
• Several Types
– User interface classes
– System interface classes
– Device interface classes
• One boundary class per actor/use-case
pair
Analysis class stereotype

Environment dependent.
 The Role of a Boundary Class

<<control>>
<<boundary>> <<boundary>>
Actor 1 Actor 2

<<entity>> <<entity>>

Model interaction between the system and its environment.

 Example: Finding Boundary
Classes
• One boundary class per actor/use case
pair

Student Register for Courses Course Catalog

RegisterForCoursesForm CourseCatalogSystem
 Guidelines: Boundary Class
• User Interface Classes
– Concentrate on what information is presented
to the user
– Do NOT concentrate on the UI details
• System and Device Interface Classes
– Concentrate on what protocols must be
defined
– Do NOT concentrate on how the protocols will
be implemented
Concentrate on the responsibilities, not the details!
 What Is an Entity Class?
• Key abstractions of the system

Analysis class
stereotype

Business-Domain
Use Case Model

Architectural Analysis
Abstractions Glossary
Environment independent.
 The Role of an Entity Class

<<control>>
<<boundary>> <<boundary>>
Actor 1 Actor 2

<<entity>> <<entity>>

Store and manage information in the system.

Example: Finding Entity Classes
• Use use-case flow of events as input
• Key abstractions of the use case
• Traditional, filtering nouns approach
– Underline noun clauses in the use-case flow
of events
– Remove redundant candidates
– Remove vague candidates
– Remove actors (out of scope)
– Remove implementation constructs
– Remove attributes (save for later)
– Remove operations
 Example: Candidate Entity
Classes
• Register for Courses (Create Schedule)

CourseOffering Schedule

Student
 What Is a Control Class?
• Use-case behavior coordinator
– More complex use cases generally require
one or more control cases

Use Case Analysis class

stereotype
Use-case dependent. Environment independent.
 The Role of a Control Class

<<control>>
<<boundary>> <<boundary>>
Actor 1 Actor 2

<<entity>> <<entity>>

Coordinate the use-case behavior.

 Example: Finding Control
Classes
• In general, identify one control class per use
case.
– As analysis continues, a complex use case’s control
class may evolve into more than one class

Student Register for Courses Course Catalog

System

RegistrationController
 Example: Summary: Analysis
Classes

Student Register for Courses Course Catalog

System

Use-Case Model

Design Model

RegisterForCoursesForm CourseCatalogSystem Student Schedule

CourseOffering RegistrationController
 Use-Case Analysis Steps
• Supplement the Use-Case Descriptions
• For each Use-Case Realization
– Find Classes from Use-Case Behavior
– Distribute Use-Case Behavior to Classes
• For each resulting analysis class
– Describe Responsibilities
– Describe Attributes and Associations
– Qualify Analysis Mechanisms
• Unify Analysis Classes
• Checkpoints
Distribute Use-Case Behavior to
Classes
• For each use-case flow of events:
– Identify analysis classes
– Allocate use-case responsibilities to analysis classes
– Model analysis class interactions in Interaction
diagrams
Use-Case Realization

Communication
Sequence Diagrams
Diagrams

Use Case
Class Diagrams
 Guidelines: Allocating
Responsibilities to Classes
• Use analysis class stereotypes as a guide
– Boundary Classes
• Behavior that involves communication with an
actor
– Entity Classes
• Behavior that involves the data encapsulated
within the abstraction
– Control Classes
• Behavior specific to a use case or part of a very
important flow of events
 Guidelines: Allocating Responsibilities to
Classes (cont.)
• Who has the data needed to perform the
responsibility?
– If one class has the data, put the responsibility with
the data
– If multiple classes have the data:
• Put the responsibility with one class and add a
relationship to the other
• Create a new class, put the responsibility in the
new class, and add relationships to classes
needed to perform the responsibility
• Put the responsibility in the control class, and
add relationships to classes needed to perform
the responsibility
 The Anatomy of Sequence
Diagrams
Client Object Supplier Object

:Client Message :Supplier

Object Lifeline
Reflexive Message
1: PerformResponsibility

Event Occurrence 1.1: PerformAnother

Execution Responsibility
Occurrence

Hierarchical Message
Numbering
ref
Interaction Occurrence
 Example: Sequence Diagram

: RegisterForCoursesForm : RegistrationController : CourseCatalogSystem : Course Catalog

: Student

1: // create schedule( )
2: // get course offerings( )
Create a new 3: // get course offerings(forSemester)
schedule
4: // get course offerings( )

A list of the available 5: // display course offerings( )

course offerings for this
semester are displayed

A blank schedule
is displayed for the 6: // display blank schedule( )
students to select
offerings

ref Select Offerings

ref Submit Schedule

The Anatomy of Communication
Diagrams
Client Object Link Supplier Object

:Client :Supplier

PerformResponsibility

Message
 Example: Communication
Diagram
5: // display course offerings( )
6: // display blank schedule( )

: Course Catalog
4: // get course offerings( )

: RegisterForCoursesForm : CourseCatalogSystem

2: // get course offerings( )

3: // get course offerings(forSemester)

1: // create schedule( )

: RegistrationController

: Student
 One Interaction Diagram Is Not
Good Enough
Basic Flow
Alternate Flow 1 Alternate Flow 2 Alternate Flow 3
AF3

AF1

AF2
Alternate Flow 4 Alternate Flow 5 Alternate Flow n
 Use-Case Analysis Steps
• Supplement the Use-Case Descriptions
• For each Use-Case Realization
– Find Classes from Use-Case Behavior
– Distribute Use-Case Behavior to Classes
• For each resulting analysis class
– Describe Responsibilities
– Describe Attributes and Associations
– Qualify Analysis Mechanisms
• Unify Analysis Classes
• Checkpoints
 Describe Responsibilities
• What are responsibilities?
• How do I find them?
Interaction Diagram

:Client :Supplier

// PerformResponsibility

Class Diagram
Supplier

// PerformResponsibility
Example: View of Participating Classes (VOPC)
Class Diagram

<<boundary>> <<control>>
RegisterForCoursesForm RegistrationController

// display course offerings() // get course offerings()

// display blank schedule()
// create schedule()

<<boundary>>
CourseCatalogSystem

// get course offerings()

 Maintaining Consistency: What
to Look For
• In order of criticality
– Redundant responsibilities across classes
– Disjoint responsibilities within classes
– Class with one responsibility
– Class with no responsibilities
– Better distribution of behavior
– Class that interacts with many other classes
 Use-Case Analysis Steps
• Supplement the Use-Case Descriptions
• For each Use-Case Realization
– Find Classes from Use-Case Behavior
– Distribute Use-Case Behavior to Classes
• For each resulting analysis class
– Describe Responsibilities
– Describe Attributes and Associations
– Qualify Analysis Mechanisms
• Unify Analysis Classes
• Checkpoints
Review: What Is an Attribute?
<<stereotype>>
ClassName
Attribute : Type = InitValue
Attribute : Type = InitValue
Attribute : Type = InitValue

<<entity>>
CourseOffering

number : String = "100"

startTime : Time
attribute endTime : Time
days : Enum
numStudents : Int

In analysis, do not spend time on attribute signatures.

 Finding Attributes
• Properties/characteristics of identified
classes
• Information retained by identified classes
• “Nouns” that did not become classes
– Information whose value is the important thing
– Information that is uniquely "owned” by an
object
– Information that has no behavior
 Review: What Is an
Association?

The semantic relationship between two or
more classifiers that specifies
connections among their instances
• A structural relationship, specifying that objects of
one thing are connected to objects of another

<<entity>> <<entity>> <<entity>>

Student Schedule Course
 Finding Relationships
Communication Diagram
PerformResponsibility
:Client :Supplier

Link
Client Supplier

Class Diagram
Client 0..* 0..* Supplier

PerformResponsibility()
Association

Relationship for every link!

 Review: What Is Aggregation?
• A special form of association that models
a whole-part relationship between an
aggregate (the whole) and its parts
Whole/aggregate Part

<<entity>> <<entity>> <<entity>>

Student Schedule 0..* 0..2 CourseOffering
1 0..*
 Association or Aggregation?
• If two objects are tightly bound by a whole-part
relationship
– The relationship is an aggregation.
Car Door

1 0..2,4

• If two objects are usually considered as

independent, although they are often linked
– The relationship is an association.
Car Door

1 0..2,4

When in doubt, use association.

 What Are Roles?
• The “face” that a class plays in the
association
<<entity>> <<entity>> <<entity>>
CourseOffering Instructor Professor Department
Department Head

Role Name
<<entity>>
Course

Prerequisites
 What Does Multiplicity Mean?

• Multiplicity answers two questions:

– Is the association mandatory or optional?
– What is the minimum and maximum number of
instances that can be linked to one instance?
<<entity>> <<entity>>
0..* 1
CourseOffering Course

0..*

Prerequisites 0..3
Example: Multiple Associations
primaryCourses
<<entity>> <<entity>>
Schedule CourseOffering

alternateCourses

<<entity>> add student to <<entity>>

Schedule CourseOffering
remove student from

Multiple associations must reflect multiple roles.

 Example: VOPC: Finding
Relationships
<<boundary>> <<control>>
RegisterForCoursesForm RegistrationController
1 1
0..1

currentSchedule
0..1
<<entity>> <<entity>> <<entity>>
primaryCourses
Student Schedule CourseOffering
1 0..* 0..* 0..4
 Use-Case Analysis Steps
• Supplement the Use-Case Descriptions
• For each Use-Case Realization
– Find Classes from Use-Case Behavior
– Distribute Use-Case Behavior to Classes
• For each resulting analysis class
– Describe Responsibilities
– Describe Attributes and Associations
– Qualify Analysis Mechanisms
• Unify Analysis Classes
• Checkpoints
 Review: Why Use Analysis
Mechanisms?
Analysis mechanisms are used during analysis to reduce the
complexity of analysis and to improve its consistency by providing
designers with a shorthand representation for complex behavior.

Oh no! I found a group of classes that

has persistent data. How am I
supposed to design these things if I
don’t even know what database we are
going to be using?

That is why we have a persistence

analysis mechanism. We don’t
know enough yet, so we can
bookmark it and come back to it
later.
 Describing Analysis
Mechanisms
• Collect all analysis mechanisms in a list
• Draw a map of the client classes to the
analysis mechanisms
• Identify characteristics of the analysis
mechanisms
 Example: Describing Analysis
Mechanisms
• Analysis class to analysis mechanism map

Analysis Class Analysis Mechanism(s)

Student Persistency, Security

Schedule Persistency, Security
CourseOffering Persistency, Legacy Interface
Course Persistency, Legacy Interface
RegistrationController Distribution
Example: Describing Analysis Mechanisms
(continued)
• Analysis mechanism characteristics
• Persistency for Schedule class:
– Granularity: 1 to 10 Kbytes per product
– Volume: up to 2,000 schedules
– Access frequency
• Create: 500 per day
• Read: 2,000 access per hour
• Update: 1,000 per day
• Delete: 50 per day
– Other characteristics
 Use-Case Analysis Steps
• Supplement the Use-Case Descriptions
• For each Use-Case Realization
– Find Classes from Use-Case Behavior
– Distribute Use-Case Behavior to Classes
• For each resulting analysis class
– Describe Responsibilities
– Describe Attributes and Associations
– Qualify Analysis Mechanisms
• Unify Analysis Classes
• Checkpoints
 Unify Analysis Classes
RegisterFor Course Registration
RegisterFor
CoursesForm Catalog
System
CoursesForm Controller
Registration
Controller
Register for Courses
Student Student
Course
Offering Course
Schedule Offering

Course
CloseRegistration Course Schedule
Catalog
Form Catalog
Close Registration System System
CloseRegistration
Billing Controller
System CloseRegistration Student
Controller Billing
System

Course CloseRegistration
Offering Form
Schedule
 Evaluate Your Results

Glossary
Design Model

Supplementary
Specification

Use-Case Model Analysis Classes

 Use-Case Analysis Steps
• Supplement the Use-Case Descriptions
• For each Use-Case Realization
– Find Classes from Use-Case Behavior
– Distribute Use-Case Behavior to Classes
• For each resulting analysis class
– Describe Responsibilities
– Describe Attributes and Associations
– Qualify Analysis Mechanisms
• Unify Analysis Classes
• Checkpoints
 Checkpoints: Analysis Classes
• Are the classes reasonable?
• Does the name of each class clearly
reflect the role it plays?
• Does the class represent a single well-
defined abstraction?
• Are all attributes and responsibilities
functionally coupled?
• Does the class offer the required
behavior?
• Are all specific requirements on the class
addressed?
 Checkpoints: Use-Case
Realizations
• Have all the main and/or sub-flows been
handled, including exceptional cases?
• Have all the required objects been found?
• Has all behavior been unambiguously
distributed to the participating objects?
• Has behavior been distributed to the right
objects?
• Where there are several Interaction diagrams,
are their relationships clear and consistent?
 Review: Use-Case Analysis
• What is the purpose of Use-Case Analysis?
• What is a Use-Case Realization?
• What is an analysis class? Name and
describe the three analysis stereotypes.
• Describe some considerations
when allocating responsibilities
to analysis classes.
• What two questions does multiplicity
answer?