Professional Documents
Culture Documents
Object-Oriented Rose
Analysis Fundamentals
Object-Oriented Database
Design Design with
Rational Rose
Object-Oriented Analysis
Modeling System Behavior with Use
Cases
Objectives
Identify actors from a problem statement.
Identify use cases from a problem
statement.
Demonstrate how to create a use-case
diagram that accurately models the system.
Recognize a use-case specification,
glossary, and supplementary specification
document.
Where Are We?
Introduction to Requirements
Key Concepts
Use-Case Model
Other Requirements Artifacts
Checkpoints
The Purpose of the Requirements Discipline
The Requirements discipline intends to:
• Find agreement on what the system should do.
• Provide a better understanding of the system
requirements.
• Define the boundaries of the system.
• Provide a basis for planning the technical
contents of iterations.
• Provide a basis for estimating cost.
• Define a user-interface for the system.
Requirements in Context
Relevant Requirements Artifacts
Use-Case Model
Glossary
Actors
Use Cases
...
Supplementary
Specification
Use-Case Specifications
Case Study: Course Registration Problem Statement
Review the problem statement provided in
the Course Registration Requirements
Document
Where Are We?
Introduction to Requirements
Key Concepts
Use-Case Model
Other Requirements Artifacts
Checkpoints
What Is System Behavior?
System behavior is how a system acts and
reacts.
It is an outwardly visible and testable activity of
a system.
System behavior is captured in use cases.
Use cases describe the system, its
environment, and the relationship between the
system and its environment.
Major Concepts in Use-Case Modeling
An actor represents anything
that interacts with the system.
A use case defines a set of
use-case instances, where
each instance is a sequence
of actions a system performs Actor
that yields an observable
result of value to a particular
actor.
Use Case
Where Are We?
Introduction to Requirements
Key Concepts
Use-Case Model
Other Requirements Artifacts
Checkpoints
Review: What Is a Use-Case Model?
A model that describes a
system’s functional
requirements in terms of
use cases. View Report
Card
A model of the system’s
intended functionality
(use cases) and its
environment (actors). Register for
Student Courses
Login
Review: What Are the Benefits of Use-Case Models?
Used to communicate with the end users and
domain experts
Provides buy-in at an early stage of system
development
Insures a mutual understanding of the requirements
Used to identify
Who interacts with the system and what the system
should do
The interfaces the system should have
Used to verify
All requirements have been captured
The development team understands the requirements
Useful Questions in Finding Actors
Who will supply, use, or remove
information?
Who will use this functionality?
Who is interested in a certain
requirement?
Where in the organization is the system
used?
Who will support and maintain the
system?
What are the system’s external Actor
resources?
What other systems will need to interact
with this one?
Focus on the Roles
An actor
represents a role
that a human,
hardware device,
or another system
can play.
?
A User May Have Different Roles
Charlie as
Professor
Professor
Charlie as
Charlie Student Student
System Surroundings and Actors
Users who execute the system’s
Main functions
Secondary functions, such as system
administration
External hardware that the system uses
Other systems interacting with the system
Name and Describe Each Actor
Actor names should clearly denote the
actor’s role
Actor description:
Area of responsibility
Dependency of the actor on the system
Practice: Find the Actors
In the Course Registration System
Requirements document, read the Problem
Statement for the Course Registration case
study.
As a group, identify the following:
Actors
Description of the actor
Practice: Solution
A person who is
The external system
registered to take
responsible for
courses at the
student billing
Billing System Student University
The unabridged
A person who is catalog of all
teaching classes at courses offered by
the University the University
Course Catalog
Professor
Login
Maintain Student
Information
Practice: Finding Use Cases
In the Course Registration System
Requirements document, read the Problem
Statement for the Course Registrations
case study.
As a group, using the actors identified in the
earlier practice session, identify the
following:
Use Cases
Use-Case names
Practice: Solution
Student
Login
Registrar
Professor
Billing System
Where Are We?
Introduction to Requirements
Key Concepts
Use-Case Model
Other Requirements Artifacts
Checkpoints
Use-Case Specifications
Name Use-Case
Brief description Model
Flows of Events
Relationships
Activity diagrams Actors
Use Cases
Use-Case diagrams
Special
requirements
Preconditions ...
Postconditions
Other diagrams Use-Case Specifications
Use Case Flow of Events
Has one normal, basic flow
Several alternative flows
Regular variants of the basic flow
Odd cases
Exceptional flows handling error situations
What Are Scenarios ?
A scenario is an instance of a use case
Glossary
Continued…
Exercise: System Behavior (cont.)
Identify for the Payroll System
Actors
Use cases
Name the use cases
Continued….
Exercise: System Behavior (cont.)
Produce the use-case model
for the Payroll System.
Provide:
Actor descriptions
Brief use-case descriptions
Exercise: Review
Compare your results to
other groups.
Are there differences?
Why? How would you
resolve these differences?
Compare the final model
to the course solution.
Payroll System
Are there differences? Do
you agree with the
differences? Why?
Object-Oriented Analysis
Module 3: Analysis and Design Overview
Objectives
Define key analysis, design terms and
concepts
Describe the roles, artifacts and workflow
for analysis and design
Define the difference between analysis and
design
Explain the role of architecture in analysis
and design
Describe the concept of use-case
realization
Where Are We?
Analysis and Design Discipline
Overview
Key Concepts
Analysis and Design in Context
Design Model
Use-Case Model Analysis and
Design
Architecture
Document
Glossary
Supplementary
Specification
Data Model
Analysis and Design Discipline
Role: Software Architect
The
Software
Architect
leads and Architect
coordinates
technical
activities
and artifacts.
Design Model
Software Architecture
Document
Role: Designer
The Designer
must know
use-case
modeling Use-Case
techniques, Realization
system Designer
requirements,
and software
design
techniques. Package/
Subsystem
Class
Analysis and Design Activity Overview
Where Are We?
Analysis and Design
Discipline Overview
Key Concepts
Analysis vs. Design
Analysis Design
Focuses on Focuses on
understanding the understanding the
problem solution
Idealized design Close to real code
Functional Nonfunctional
requirements requirements
A small model A large model
Analysis and Design Is Not Top-Down or Bottom-Up
Subsystems
Top
Down
Use Cases
Bottom
Design Classes
Up
Review: Analysis and Design Is Architecture-Centric
A system’s architecture is a:
Primary artifact for conceptualizing,
constructing, managing, and evolving the
system under development.
Benefits:
Intellectual control over projects.
Manages complexity and maintains system
integrity.
Provides an effective basis for large-scale
reuse.
Provides a basis for project management.
Helps with component-based development.
Concept: Architecture
Software architecture encompasses a set of
significant decisions about the organization
of a software system
Selection of the structural elements and their
interfaces by which a system is composed
Behavior as specified in collaborations among
those elements
Composition of the structural and behavioral
elements into larger subsystems
Architectural style that guides the organization
architecture
design
implementation
CODE
Architecture decisions are the
most fundamental decisions
and changing them has
significant ripple effects.
Software Architecture: The “4+1 View” Model
End-user
Analysts/Designers Programmers
Structure Functionality
Software management
Use-Case View
Check Balance
Customer
Withdraw Money
Concept: Use-Case Realization
Use-Case Model Design Model
Use Case
Class Diagrams
The Value of Use-Case Realizations
Provides traceability from analysis and
design back to requirements
Review: Analysis and Design Is Iterative
Critical risks are resolved before making
large investments.
Initial iterations enable early user feedback.
Testing and integration are continuous.
Objective milestones focus on the short
term.
Progress is measured by assessing
implementations.
Partial implementations can be deployed.
Analysis and Design in an Iterative Process
End of
iteration Use-Case Use-Case Use-Case
Realization A Realization B Realization C
Iteration n Iteration n + 1 Iteration n + 2
Review
What is the purpose of Analysis and
Design?
What are the input and output artifacts?
Name and briefly describe the 4+1 Views of
Architecture.
What is the difference between Analysis
and Design?
What is architecture?
Object-Oriented Analysis
Module 4: Architectural Analysis
Objectives
Define the purpose of architectural
analysis and show where it is performed
in the lifecycle.
Describe how a representative
architectural pattern and a set of analysis
mechanisms affect the architecture.
Demonstrate how to read and interpret:
Architectural layers and their relationships.
Key abstractions.
Analysis mechanisms.
Architectural Analysis in Context
Architectural
Analysis Architect
Architectural Analysis Overview
Supplementary
Specification
Architectural
Analysis
Use-Case Realization
(identified)
Use-Case Model
Design Model
Business Model
Review: What Is Architecture: The “4+1 View” Model
End-user
Analysts/Designers Programmers
Functionality
Structure Software management
Use-Case View
Pattern Name
General
functionality
Layering Considerations
Level of abstraction
Group elements at the same level of abstraction
Separation of concerns
Group like things together
Separate disparate things
Application vs. Domain model elements
Resiliency
Loose coupling
Concentrate on encapsulating change
User interface, business rules, and retained data tend
to have a high potential for change
Review: What Is a Package?
A general-purpose mechanism for
organizing elements into groups.
A model element that can contain other
model elements.
A package can be used
To organize the model under
University
development
Artifacts
As a unit of configuration
management
Modeling Architectural Layers
Architectural layers can be modeled using
stereotyped packages
<<layer>> stereotype
<<layer>>
Package Name
Package Relationships: Dependency
Packages can be related to one another using a
dependency relationship
Dependency relationship
Dependency Implications
• Changes to the Supplier package may affect the
Client package
• The Client package cannot be reused independently
because it depends on the Supplier package
Avoiding Circular Dependencies
A
A
B
Hierarchy
should be B
acyclic
A
C
B
A'
C
Circular dependencies make it impossible to reuse
one package without the other.
Example: Upper Level Layers
<<layer>>
Presentation
Logic
<<layer>>
Business
Logic
Architectural Pattern: M-V-C
Database
Typical Approach for M-V-C
Observer
Model View
<<subscribe>>
// Encapsulates application data() // Render the models()
// Responds to state queries() // Request updates from models()
// Exposes application functionality() // Send user gestures to controller()
// Notifies view of changes() // Allows controller to select view()
Controller
<<subscribe>>
// Defines application behavior()
// Maps user actions to model updates()
// Selects view for response()
// One for each use-case()
Where Are We?
Define the High-Level
Organization of Subsystems
Identify Analysis Mechanisms
Identify Key Abstractions
Create Use-Case Realizations
Checkpoints
Concept: Architectural Mechanisms
Required Implementation
Functionality Environment
“realized by client
classes using” “constrained by”
COTS Products
Mechanisms Databases
IPC Technology
etc.
Supplementary
Specification
“responsible for”
Use-Case Model
Architect
Architectural Mechanisms: Three Categories
Architectural Mechanism Categories
Analysis Mechanisms (conceptual)
Design Mechanisms (concrete)
Implementation Mechanisms (actual)
• Example
Analysis mechanism = Persistence
Design mechanism = RDBMS
Implementation mechanism = Oracle
What is the Purpose of Defining Analysis Mechanisms?
Professor Student
Schedule
Use Case
Class Diagrams
Creating Use-Case Realizations
Provides traceability from Analysis and Design
back to Requirements
The Architect creates the Use-Case Realization
Use-Case
Analysis Designer
Use-Case Analysis Overview
Software Architecture
Glossary Use-Case Document
Modeling Guidelines Analysis Classes
Supplementary
Specifications
• The system
• The system
retrieves and
displays a displays a list of
list of current course
course offerings from the
offerings. course catalog
legacy database.
Do the Requirements Change?
Yes – if you are not careful with the
following:
Changes in the order of the flow of events
Adding or deleting steps from the flow of events
No – if done properly, the requirements do
not change
Focus on enhancing the current flow with
internal details
Where Are We?
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
Find Classes from Use-Case Behavior
Identify a candidate set of model elements
(analysis classes) which are capable of
performing the behavior described in use
cases.
The complete behavior of a use case has to
be distributed to analysis classes.
Remember: one of RUP’s characteristics is
that it is use-case driven.
Review: Class
An abstraction
Describes a group of objects with common:
Properties (attributes)
Behavior (operations)
Relationships
Class Name Professor
Semantics name
Attributes ProfessorId : UniqueId
create()
Operations save()
delete()
change()
Guidelines for Class Discovery
Classes should:
Reflect the business.
Have descriptive names.
Have a clear description.
Have a set of related responsibilities.
Where Do You Find Classes?
Use-case documentation
Use-case models
Glossary
Stakeholder Requests
Supplemental Specification
Vision document
Any project documentation
How Do Classes Relate to the Business Domain?
Classes should reflect the model of
business domain.
Classes should capture the vocabulary of
the development of the system.
Classes should identify those things users
or implementers use to describe the
problem or solution.
Example: Classes and the Business Domain
Student CourseCatalogSystem
Schedule
CourseOffering
Professor BillingSystem
Course
GraduationGown
Dormitory Fraternity
What Should You Name Your Classes?
Name classes to reflect what they represent.
The name should be a noun and not have a prefix
or suffix.
Typically, capitalize the first letter in every word in
the class name.
CourseOffering
Schedule
Path Name
Concept: Stereotypes
Stereotypes define a new model element in
terms of another model element.
Sometimes, you need to introduce new
things that speak the language of your
domain and look like primitive building
blocks.
<<stereotype>> Stereotype
Class
Example: Stereotype
<<jock>> Description:
Class Athletic, academics are not
important, not always the most
intelligent person, bully
Jock
Description:
<<child>>
Young, innocent, playful, cute
Class and desires to please the
significant adult in their life
Child
<<geek>> Description:
Class Intelligent, likes science fiction,
enjoys reading technical books,
weird sense of humor, usually
works in the software industry
Geek
What Are Analysis Classes?
<<boundary>>
= Boundary
=
<<control>>
Control
<<entity>>
= Entity
Analysis Classes: A First Step Toward Executables
<<boundary>>
<<control>>
<<boundary>>
Customer
<<boundary>>
<<entity>> <<entity>>
ClassSpecificationForm
Boundary Classes and System Interfaces
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
RegisterForCoursesForm CourseCatalogSystem
Practice: Finding Boundary Classes
There should be at least one boundary object for
each actor/use-case pair.
How many boundary classes do you see?
Student
Maintain Professor Information
Register for Courses
Course Catalog
Login
Maintain Student Information
Select Courses to Teach
Registrar
Professor
Billing System
Practice Solution: Boundary Classes
RegistrationController
Practice: Finding Control Classes
There is one control class for each complex use
case.
How many control classes do you see?
Student
Maintain Professor Information
Register for Courses
Course Catalog
Login
Maintain Student Information
Select Courses to Teach
Registrar
Professor
Billing System
Practice: Solution
CloseRegistrationController SelectCoursesToTeachController
ViewReportCardController SubmitGradesController
What Is an Entity Class?
Models the key concepts of
the system
Usually models information
that is long-lived (persistent)
Is environment independent
Entity
Can be used in multiple use
cases
The Role of an Entity Class
taken courses
Course: An offering for a semester
BillingInformation: Information
StudentRecord Course
needed by the billing system actor
CourseRoster: List of students for a
specific course offering
BillingInformation CourseRoster
Analysis Classes and the MVC Architectural Pattern
Improves Resiliency
Example: Object Interaction
The OrderEntryForm wants Order to
calculate the total dollar value for the order.
l()
ta
o
e rT
rd
calculateOrderTotal()
eO
at
ul
orderID
lc
Ca
date
salesTotal
tax
shipDate
Message
OrderEntryForm Order
:Client :Supplier
Object Lifeline
Reflexive Message
1: PerformResponsibility
This is a
sample script.
1.1: PerformAnother
Responsibility
Message
Hierarchical Message
Numbering
Focus of Control
Review: The Anatomy of Collaboration Diagrams
Client Object
Link Supplier Object
:Client
:Supplier
1: PerformResponsibility
Message
Concept: Link
Client Object
Link Supplier Object
:Client
:Supplier
1: PerformResponsibility
Message
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
(continued)
Guidelines: Allocating Responsibilities to Classes (cont.)
: Course Catalog
1: // create schedule( )
7: // select 4 primary and 2 alternate offerings( ) 3: // get course offerings(forSemester)
: RegistrationController
: Student
One Collaboration 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
Review
What is the purpose of Use-Case Analysis?
What is an analysis class? Name and
describe the three analysis stereotypes.
Describe some considerations when
allocating responsibilities to analysis
classes.
How many interaction diagrams should be
produced during Use-Case Analysis?
Exercise: Use-Case Analysis
Given the following:
Use-Case Model, especially the
use-case flows of events
Key abstractions/classes
(continued)
Exercise: Distribute Behavior to Classes
Identify the following for a particular
use case:
The analysis classes, along with their:
• Brief descriptions
• Stereotypes
• Responsibilities
The collaborations needed to
implement the use case
Exercise: Distribute Behavior to Classes
Produce the following for a
particular use case:
Use-case realization collaboration
diagram for at least one of the use-
case flows of events
Exercise: Review
Compare your use-case
realization with the rest of the
class
Do the collaboration diagrams
carry out the use-case flow of
events?
Are the stereotypes behaving
properly?
Payroll System
Object-Oriented Analysis
Module 6: Describe the Analysis Class
(Use-Case Analysis)
Objectives
Describe how to model the static view of a
use case
Create a class diagram
Model class relationships on the class
diagram
Define initial attributes for an analysis class
Describe event dependencies between
classes
Qualify analysis mechanisms for analysis
classes
Where Are We?
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
Purpose of Describe Responsibilities
To describe the
responsibilities of a class of
objects identified from use-
case behavior
Example: View of Participating Classes (VOPC) Class Diagram
<<control>>
RegistrationController
<<entity>>
Student
// get course offerings()
// get current schedule()
// get tuition()
// delete current schedule()
// add schedule()
// submit schedule()
// get schedule()
// is registration open?()
// delete schedule()
// save schedule()
// has pre-requisites()
// create schedule with offerings()
// update schedule with new selections()
<<boundary>>
<<entity>> CourseCatalogSystem
Schedule
// get course offerings()
// commit()
// select alternate()
// remove offering()
// level()
// cancel()
// get cost() <<boundary>>
// delete() RegisterForCoursesForm
// submit()
// save() // display course offerings()
// any conflicts?() // display blank schedule()
// create with offerings() // update offering selections()
// update with new selections()
Maintaining Consistency: What to Look For
In order of criticality
Redundant responsibilities across classes
Disjointed responsibilities within classes
Class with one responsibility
Class with no responsibilities
Better distribution of behavior
Class that interacts with many other classes
Where Are We?
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 Attributes and Associations Purpose
By defining :
The other classes on which the
analysis class depends
The events in other analysis
classes about which the class
must know
The information that the analysis
class is responsible for
maintaining
Review: What Is an Attribute?
<<stereotype>>
ClassName
Attribute : Type = InitValue
Attribute : Type = InitValue
Attribute : Type = InitValue
:Client
:Supplier
1: PerformResponsibility
Message
How Do You Find an Association?
1: PerformResponsibility
Class
Diagram Client Supplier
PerformResponsibility()
Association
3: // save( )
4: // submit( )
6: // has pre-requisites(CourseOffering)
:CourseOffering
: Student
5: // is selected?( )
10: // mark as enrolled in( )
:PrimaryScheduleOfferingInfob
Practice: Solution
<<boundary>> <<control>>
RegisterForCoursesForm RegistrationController
<<entity>> <<entity>>
Schedule CourseOffering
<<entity>> <<entity>>
PrimaryScheduleOfferingInfob Student
What Is an Association Name?
To clarify its meaning, an association may
be named.
The name is represented as a label placed
midway along the association line.
An association name is usually a verb or
verb phrase.
<<control>> manages <<entity>>
RegistrationController Schedule
What Is a Role?
A role specifies the face that a class plays
in an association.
Role names are typically nouns or noun
phrases.
A role name is placed along the association
line close to the class it modifies.
One or both ends of an association may have
role names.
<<entity>> Instructor
<<entity>> <<entity>>
CourseOffering Professor Department
Department
Head
Reflexive Associations and Roles
In a reflexive association, objects in the
same class are related.
Reflexive associations indicate that multiple
objects in the same class collaborate together
in some way.
Role names must be used in a reflexive
association.
<<entity>>
Course
+preRequisites
Good and Bad Examples of Association Names
Poor examples
A student has a schedule
A department contains a professor
Good examples
A student creates a schedule
A department employs a professor
Example: Roles and Association Names
<<boundary>> <<control>>
RegisterForCoursesForm RegistrationController
currentSchedule
creates
<<entity>>
Student
Review: What Is Multiplicity?
Multiplicity is the number of instances in which one
class relates to ONE instance of another class.
For each association, there are two multiplicity
decisions to make, one for each end of the
association.
For each instance of Professor, many Course Offerings
may be taught.
For each instance of Course Offering, there may be either
one or zero Professor as the instructor.
<<boundary>> <<control>>
RegisterForCoursesForm RegistrationController
1 1
0..1
+currentSchedule
1 0..1
Shared Aggregation
Multiplicity is greater than one for the
aggregate
Destroying the aggregate does not
necessarily destroy the parts
“Weak ownership”
Aggregation Tests
Is the phrase “part of” used to describe the
relationship?
A door is “part of” a car.
Are some operations on the whole automatically
applied to its parts?
Move the car, move the door.
Are some attribute values propagated from the
whole to all or some of its parts?
The car is blue, therefore the door is blue.
Is there an intrinsic asymmetry to the relationship
where one class is subordinate to the other?
A door IS part of a car. A car IS NOT part of a door.
Association or Aggregation?
If two objects are tightly bound by a whole-part
relationship
The relationship is an aggregation.
Car Door
1 0..1
Car Door
1 0..1
Example: Aggregation
<<boundary>> <<control>>
RegisterForCoursesForm RegistrationController
1 1
0..1
+currentSchedule
<<entity>>
Schedule
1 0..*
Example: Multiple Associations
primaryCourses
<<entity>> <<entity>>
Schedule CourseOffering
alternateCourses
add student to
<<entity>> <<entity>>
Schedule remove student from CourseOffering
Database
<<subscribe>>
Subscribing Class Associated Class
Subscribe-Association and MVC
In the MVC pattern, the model (entity
classes) should notify all views (boundary
classes) whenever its data changes.
The subscribe-association is the mechanism
that makes this communication possible.
Observer
Model View
Controller
<<subscribe>> // Defines application behavior()
// Maps user actions to model updates()
// Selects view for response()
// One for each use-case()
Subscribe-Association from Boundary Classes
Boundary objects need to be informed if an
event takes place in an entity object.
TransferalHandler
<<subscribe>> NoticeWriter
Account
Subscribe-Association from Entity Classes
Usually an existing association is used
<<subscribe>>
Station Line
Subscribe-Association from Control Classes
Usually, the instance of the control object
that deals with the event in the entity object
is not created until the event actually takes
place.
<<subscribe>> <<subscribe>>
1 1
RegisterForCoursesForm RegistrationController
0..1 0..1
<<subscribe>>
currentSchedule 0..1
registrant
0..1 <<subscribe>>
0..* 1
Schedule Student
Association Type Usage Guidelines
Class Association Class Location
Boundary Communicate or From a boundary to an
subscribe entity class
Communicate Between boundary
classes
Communicate From a boundary to a
control class
Control Communicate or Between control and
subscribe entity classes
Communicate Between control classes
Communicate Between control and
boundary classes
Entity Communicate or Between entity classes
subscribe
Where Are We?
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
Purpose of Qualify Analysis Mechanisms
To identify analysis
mechanisms (if any) used
by the class
To provide additional
information about how the
class applies the analysis
mechanism.
Review: Why Use Analysis Mechanisms?
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?
(continued)
Exercise: Use-Case Analysis
Identify the following for a particular
use case:
Analysis class relationships
Analysis class analysis mechanisms
(continued)
Exercise: Use-Case Analysis
Produce the following:
A class diagram with
• Analysis classes and their
stereotypes
• Relationships (association,
aggregation)
• Multiplicity
• Role and association names
Analysis class to analysis
mechanism map
Exercise: Review
Homogenize all results into one
class diagram:
Does the multiplicity support the use
case?
Are all relationships supported by a link
in an interaction diagram?
Do role and association names make
sense?
Payroll System
Are there classes that are “working” too
much?
Object-Oriented Analysis
Module 7: Review the Analysis Model
Objective
Demonstrate that the analysis model meets
general and layer checkpoints.
Define the criteria for examining the layers
of a system.
Provide a checklist for enforcing model
consistency.
Where Are We?
Review the Design Purpose
Review the Design Steps
Review the design model as a
whole
Review each use-case
realization
Documenting Results
Purpose of Review the Design
Verify that the design model
fulfills the requirements on
the system, and that it
serves as a good basis for
its implementation.
Ensure that the design
model is consistent with
respect to the general design
guidelines.
Ensure that the design
guidelines fulfill their
objectives.
Role: Design Reviewer
Same profile as the software architect
Needs strong communication skills
Design Reviewer
When Do You Conduct A Review?
One review per iteration
Review
Iteration
Where Are We?
Review the Design Purpose
Review the Design Steps
Review the design model as a
whole
Review each use-case
realization
Documenting Results
Purpose of Review the Design Model as a Whole
To ensure that the overall
structure for the design
model is well formed.
To detect large-scale quality
problems not visible by
looking at lower-level
elements.
Layering Defects
A sample layering
Layer
Definitions
and
rationale
defined
Loose
Coupling
Package Coupling: Package Dependencies
Packages should not
X
A B
be cross-coupled
Layer
In general,
dependencies should
not skip layers (unless
specified by the C
architecture)
X = Coupling violation
Package Coupling: Class Relationships
Strive for the loosest coupling possible
PackageA PackageA
Class A1 Class A1
Class A3 Class A3
PackageB PackageB
+ Class B3 + Class B3
- Class B2 - Class B2
+ Class B1 + Class B1
- Class B4 - Class B4
PackageA
<<entity>>
Class A1
0..* CourseOffering
Course
Schedule
0..*
0..4
1
// Create schedule
Student
// Close course
// Open course
// Delete schedule
Functional Nonfunctional
requirements requirements
A small model A large model
Where Are We?
Design Overview
Architectural activities
• Identify Design Elements
• Identify Subsystems and Interfaces
• Model design and implementation mechanisms
Designer activities
From Analysis Classes to Design Elements
Analysis Classes Design Elements
<<boundary>>
<<control>>
<<entity>>
<<boundary>>
Many-to-Many Mapping
Identifying Design Classes
An analysis class maps directly to a design
class if:
It is a simple class
It represents a single logical abstraction
More complex analysis classes may
Split into multiple classes
Become a package
Become a subsystem (discussed later)
Any combination of the above
Where Are We?
Design Overview
Architectural activities
• Identify Design Elements
• Identify Subsystems and Interfaces
• Model design and implementation
mechanisms
Designer activities
Subsystems and Interfaces
Subsystems:
Are a cross between a package (that can contain other
model elements) and a class (that has behavior)
Realize one or more interfaces that define its behavior
<<subsystem>>
Interface Subsystem
Name
W() X()
<<Interface>>
InterfaceK
X() <<subsystem>>
W() SubsystemB
ClassB1 ClassB2 ClassB3
Note: JDBC is the standard Java API for talking to a SQL database.
Example: Persistence: RDBMS: JDBC
<<role>>
PersistentClient
The designer fills these roles <<role>>
(from SamplePersistency Client) PersistentClassList
by applying the mechanism (from SamplePersistentClass)
new()
add(c: PersistentClass)
<<role>>
DBClass 1
0..*
create() : PersistentClass
<<role>>
read(searchCriteria : string) : PersistentClassList
PersistentClass
update(c : PersistentClass) (from SamplePersistentClass)
delete(c : PersistentClass)
1 getData()
setData()
command()
new()
DriverManager
(from java.sql)
Statement
ResultSet (from java.sql)
Connection
(from java.sql)
(from java.sql)
1.4. new()
Repeat these
operations for each 1.5. getString( )
called for each
element returned from
attribute in the
the executeQuery() 1.6. setData( ) class
command.
The
PersistentClassList is 1.7. add(PersistentClass)
loaded with the data
retrieved from the
database. Add the retrieved course offering
to the list to be returned
Where Are We?
Design Overview
Architectural activities
• Identify Design Elements
• Identify Subsystems and Interfaces
• Model design and implementation mechanisms
Designer activities
Use-Case Realization Refinement
Identify participating objects
Allocate responsibilities among objects
Model messages between objects
Describe processing resulting from
messages
Model associated class relationships
X
1: Message 1 1: Message 1
2: Message 2 2: Message 2
BillingSystem
IBillingSystem
//submit bill()
submitBill(forTuition : Double, forStudent : Student)
<<boundary>> <<subsystem>>
Course Catalog
CourseCatalogSystem System
1. // create schedule( )
1.1. // get course offerings( )
Student wishes to
create a new 1.1.1. // get course offerings(forSemester)
schedule
1: // create schedule( )
1.1: // get course offerings( )
Student wishes to
create a new 1.1.1: getCourseOfferings(Semester)
schedule
Subsystem responsibility
Distributing Subsystem Responsibilities
Identify new or reuse existing design elements (for
example, classes and/or subsystems)
Allocate subsystem responsibilities to design elements
Incorporate applicable mechanisms (for example,
persistence, distribution, etc.)
Document design element collaborations in “interface
realizations”
One or more interaction diagrams per interface
operation
Class diagrams containing the required design
element relationships
Revisit “Identify Design Elements”
Adjust subsystem boundaries and/or dependencies,
as needed
Modeling Convention: Subsystem Interaction Diagrams
Subsystem Client Subsystem Proxy Design Element 1 Design Element 2
performResponsibility( )
Op1()
Internal subsystem
Op3() interactions
Op4()
1: // create schedule( )
2: // get course offerings( )
Student wishes to
create a new 3: getCourseOfferings(Semester)
schedule
9: // add schedule(Schedule)
Mt. Design…just
getting started!
Mt. Analysis …
Analysis
already conquered!