0% found this document useful (0 votes)
26 views60 pages

Object Oriented Analysis and Design: Use Case Analysis Use Case Analysis

Use-case analysis identifies the classes needed to implement the system by analyzing use case descriptions, finding boundary, entity, and control classes, and distributing use case behavior and responsibilities to these classes. Interaction diagrams show how classes collaborate. The resulting analysis classes form the basis for subsequent design activities.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
26 views60 pages

Object Oriented Analysis and Design: Use Case Analysis Use Case Analysis

Use-case analysis identifies the classes needed to implement the system by analyzing use case descriptions, finding boundary, entity, and control classes, and distributing use case behavior and responsibilities to these classes. Interaction diagrams show how classes collaborate. The resulting analysis classes form the basis for subsequent design activities.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 60

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 cases 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
dont even know what database we are
going to be using?

That is why we have a persistence


analysis mechanism. We dont
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?

You might also like