Object Oriented Analysis and Design: Use Case Analysis Use Case Analysis
Object Oriented Analysis and Design: Use Case Analysis Use Case Analysis
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)]
Use-Case
Designer Analysis
Analyze Behavior
(Optional)
Refine the
Architecture
Use-Case
Supplementary
Specifications Analysis
Analysis Model
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
Communication
Sequence Diagrams
Diagrams
Use Case
Class Diagrams
Analysis Classes: A First Step
Toward Executables
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>>
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>>
CourseOffering Schedule
Student
What Is a Control Class?
Use-case behavior coordinator
More complex use cases generally require
one or more control cases
<<control>>
<<boundary>> <<boundary>>
Actor 1 Actor 2
<<entity>> <<entity>>
RegistrationController
Example: Summary: Analysis
Classes
Use-Case Model
Design Model
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
Object Lifeline
Reflexive Message
1: PerformResponsibility
Hierarchical Message
Numbering
ref
Interaction Occurrence
Example: Sequence Diagram
1: // create schedule( )
2: // get course offerings( )
Create a new 3: // get course offerings(forSemester)
schedule
4: // get course offerings( )
A blank schedule
is displayed for the 6: // display blank schedule( )
students to select
offerings
:Client :Supplier
PerformResponsibility
Message
Example: Communication
Diagram
5: // display course offerings( )
6: // display blank schedule( )
: Course Catalog
4: // get course offerings( )
: RegisterForCoursesForm : CourseCatalogSystem
: 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
<<boundary>>
CourseCatalogSystem
<<entity>>
CourseOffering
Link
Client Supplier
Class Diagram
Client 0..* 0..* Supplier
PerformResponsibility()
Association
1 0..2,4
1 0..2,4
Role Name
<<entity>>
Course
Prerequisites
What Does Multiplicity Mean?
0..*
Prerequisites 0..3
Example: Multiple Associations
primaryCourses
<<entity>> <<entity>>
Schedule CourseOffering
alternateCourses
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.
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