Chapter 1

Object-Oriented Analysis
About This Course

Introductions
 Your organization
 Your role
 Your background,
experience
 Object Technology
experience
 Software Development
experience
 Course expectations
Intended Audience and Prerequisites
 Intended Audience
 Software developers who are making the
paradigm shift to object technology
 Software managers who need to better
understand object technology to be more
effective leaders
 Data modelers who need to better communicate
with object modelers
 Prerequisite
 A desire to learn about object technology
Course Objectives
 After completing this course, you will be
able to
 Define the Best Practices of Software
Engineering.
 Model system behavior with use cases.
 Demonstrate the differences between analysis
and design.
 Identify classes, objects, associations and show
how to create simple interaction and class
diagrams.
 Produce a class diagram with analysis classes
and their stereotypes.
Rational University Curriculum
Fundamentals of Visual Modeling
Object-Oriented Rose
Analysis Fundamentals
Object-Oriented Database
Design Design with
Rational Rose
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?
 Key Concepts
 Use-Case Model
 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?
 Key Concepts
 Use-Case Model
 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
The person who is

responsible for the
maintenance of the
Registrar course registration
system
Finding Use Cases: Focus on the Actor
 The system exists only for its users
 Use cases should be based on the user’s
needs
Useful Questions in Finding Use Cases
 Answer the following questions
to find use cases.
 For each actor you have identified,
what are the tasks the system
would be involved in?
 Does the actor need to be informed
about certain occurrences in the
system?
 Will the actor need to inform the
system about sudden, external
changes?
 What information must be modified
or created in the system?
Naming the Use Case
 The name indicates what is
achieved by its interactions
with the actor(s).
Register for  The name may be several
Courses words in length.
 No two use cases should
have the same name.
Login
Maintain Student
Information
Practice: Finding Use Cases
 In the Course Registration System
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
Register for View Report Login Select Courses

Courses Card To Teach
Maintain Maintain Close

Submit Professor Student Registration
Grades Information Information
Use Cases and Actors
 A use case models a dialog between actors
and the system.
 A use case is initiated by an actor to invoke
a certain functionality in the system.
Concept: Communicate-Association
 Use cases and actors interact by sending
signals to one another.
 To indicate such interactions, use a
communicate-association.
Actor Use Case

Communicate-Association
Practice: Use Case and Actor Communication
 In the Course Registrations System
Statement for the Course Registration case
study.
 As a group, using the actors and use cases
identified in the earlier practice session,
identify:
 Communicate-associations between the actors
and the use cases.
Solution: Use Case and Actor Communication
View Report Card
Student
Register for Courses Maintain Professor Information

Course Catalog
Login
Maintain Student Information

Select Courses to Teach
Registrar
Professor
Submit Grades Close Registration
Billing System
Where Are We?
 Key Concepts
 Use-Case Model
 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
Course Registration System Glossary

1. Introduction
This document is used to define terminology specific to the problem
domain, explaining terms, which may be unfamiliar to the reader of the
use-case descriptions or other project documents. Often, this document
can be used as an informal data dictionary, capturing data definitions so
that use-case descriptions and other project documents can focus on
what the system must do with the information.
2. Definitions
The glossary contains the working definitions for the key concepts in the
Course Registration System.
2.1 Course: A class offered by the university.
2.2 Course Offering: A specific delivery of the course for a specific
Glossary semester – you could run the same course in parallel sessions in the
semester. Includes the days of the week and times it is offered.
2.3 Course Catalog: The unabridged catalog of all courses offered
by the university.
Supplementary Specification
 Functionality
 Usability
 Reliability
 Performance
 Supportability
 Design constraints Supplementary
Specification
Example: Glossary And Supplementary Specification
 Review the Glossary
and Supplementary
Specification provided
in the Course
Registration
Requirements
Document.
Course Registration System

Where Are We?
 Key Concepts
 Use-Case Model
 Checkpoints
Checkpoints: Use-Case Model
 Is the use-case model
understandable?
 By studying the use-case model, can
you form a clear idea of the system's
functions and how they are related?
 Have all functional requirements
been met?
 Does the use-case model contain
any superfluous behavior?
 Is the division of the model into use-
case packages appropriate?
Checkpoints: Actors
 Have all the actors been identified?
 Is each actor involved with at least
one use case?
 Is each actor really a role? Should
any be merged or split?
 Do two actors play the same role in
relation to a use case?
 Do the actors have intuitive and
descriptive names? Can both users
and customers understand the
names?
Checkpoints: Use Cases
 Is each use case involved with at
least one actor?
 Is each use case independent of the
others?
 Do any use cases have very similar
behaviors or flows of events?
 Do the use cases have unique,
intuitive, and explanatory names so
that they cannot be mixed up at a
later stage?
 Do customers and users understand
the names and descriptions of the
use cases?
Checkpoints: Use-Case Specifications
 Is it clear who wishes to perform a use
case?
 Is the purpose of the use case also
clear?
 Does the brief description give a true
picture of the use case?
 Is it clear how and when the use-
case's flow of events starts and ends?
 Does the communication sequence
between actor and use case conform
to the user's expectations?
 Are the actor interactions and
exchanged information clear?
 Are any use cases overly complex?
Checkpoints: Glossary
 Does each term have a clear and
concise definition?
 Is each glossary term included
somewhere in the use-case
descriptions?
 Are terms used consistently in the brief
descriptions of actors and use cases?
Review
 What are the main artifacts of
Requirements?
 What are the Requirements artifacts used
for?
 What is a use-case model?
 What is an actor?
 What is a use case? List examples of use-
case properties.
 What is the difference between a scenario
and a use case?
Exercise: System Behavior
 Given the following
 The Payroll System Problem Statement
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?
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
The purposes of Analysis and Design are to:

Transform the requirements into a design of the system
to be.
Evolve a robust architecture for the system.
Adapt the design to match the implementation
environment, designing it for performance.
Analysis and Design Overview
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
Behavior Operations and

attributes
Object life cycles
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
Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational

(derived from Mary Shaw)
Architecture Constrains
 Architecture involves a set of strategic
design decisions, rules or patterns that
constrain design and construction
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
Logical View Implementation View
End-user
Analysts/Designers Programmers
Structure Functionality
Software management
Use-Case View
Process View Deployment View

System integrators System engineering
Performance System topology
Scalability Delivery, installation
Throughput communication
Review: Analysis and Design Is Use-Case Driven
 Use cases defined for a system are the
basis for the entire development process.
 Benefits of use cases:
 Concise, simple, and understandable by a wide range of
stakeholders.
 Help synchronize the content of different models.
Check Balance
Customer
Withdraw Money
Concept: Use-Case Realization
Use-Case Model Design Model
Use Case Use-Case Realization
Sequence Diagrams Collaboration Diagrams
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
Start of Use Case A Use Case B Use Case C

iteration
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?
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
Design Software Architecture

Glossary Document
Guidelines
Supplementary
Specification
Architectural
Analysis
Use-Case Realization
(identified)
Use-Case Model
Design Model
Business Model
Review: What Is Architecture: The “4+1 View” Model
Logical View Implementation View
End-user
Analysts/Designers Programmers
Functionality
Structure Software management
Use-Case View
Process View Deployment View

System integrators System engineering
Performance System topology
Scalability Delivery, installation
Throughput communication
Where Are We?
 Define the High-Level
Organization of Subsystems
 Identify Analysis Mechanisms
 Identify Key Abstractions
 Create Use-Case Realizations
 Checkpoints
Define the High-Level Organization of Subsystems
 The purpose of this step is to
create an initial structure for
the design model.
Patterns and Frameworks
 Pattern
 A common solution to a common problem in a
context
 Analysis/Design Pattern
 A solution to a narrowly-scoped technical problem
 A fragment of a solution or a piece of the puzzle
 Framework
 Defines the general approach to solving the
problem
 Skeletal solution, whose details may be
analysis/design patterns
Concept: Design Patterns
 A design pattern
 Describes common design problems
 Is a solution to a common design problem
 Discusses results and trade-offs of applying patterns
 Design patterns provide the capability to reuse
successful designs.
Template
Parameters
Pattern Name
Parameterized Structural Aspect Behavioral Aspect

collaboration
What Is an Architectural Pattern?
 An architectural pattern expresses a fundamental
structural organization schema for software
systems. It provides a set of predefined
subsystems, specifies their responsibilities, and
includes rules and guidelines for organizing the
relationships between them. – Buschman et al,
Pattern-Oriented Software Architecture – A System of
Patterns
 Layers
 Model-view-controller (M-V-C)
 Pipes and filters
 Blackboard
Architectural Pattern: Layers
Typical Layering Approach
Specific
functionality
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
Client Package Supplier

Package
 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?
 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?
 To define the analysis

mechanisms and services
used by designers that give
“life” to their objects.
 To provide design solutions for
common architectural
problems:
 Persistence
 Distribution
 Security
 Legacy interface
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 use?
That’s why we have a persistence

analysis mechanism. We don’t
know enough yet, so bookmark it
and come back to it later.
Analysis mechanisms are used during analysis to reduce the complexity of

analysis and to improve its consistency by providing designers with a short-
hand representation for complex behavior.
Sample Analysis Mechanisms
 Persistence
 Communication (IPC and RPC)
 Message routing
 Distribution
 Transaction management
 Process control and synchronization (resource
contention)
 Information exchange, format conversion
 Security
 Error detection / handling / reporting
 Redundancy
 Legacy Interface
Examples of Analysis Mechanism Characteristics
 Persistence mechanism
 Granularity
 Volume
 Duration
 Access mechanism
 Access frequency (creation/deletion, update, read)
 Reliability
 Inter-process Communication mechanism
 Latency
 Synchronicity
 Message Size
 Protocol
Example of Analysis Mechanism Characteristics (cont.)
 Legacy interface mechanism

 Latency
 Duration
 Access frequency
 Security mechanism
 Data granularity
 User granularity
 Security rules
 Privilege types
 etc.
Describing Analysis Mechanisms
 Collect all analysis
mechanisms in a list
 Draw a map of classes
to analysis mechanisms
 Identify characteristics
of analysis mechanisms
 Model using
collaborations
Example: Course Registration Analysis Mechanisms
 Persistence
 Distribution
 Security
So…How Do I Discover Analysis Mechanisms?
 By identifying that a common subproblem
exists and assigning a name to name it.
 The software architect is responsible for
identifying analysis mechanisms. These
mechanisms are identified by:
 Previous knowledge and experience.
 A common thread emerging from a set of
solutions to various problems.
Where Are We?
 Checkpoints
What Are Key Abstractions?
 A key abstraction is a concept normally
uncovered in Requirements that the
system must be able to handle.
 Sources for key abstractions
 Domain knowledge
 Requirements
 Glossary
 Domain Model, or the Business
Model (if one exists)
Purpose of Identifying Key Abstractions
 To ‘prime the pump’ for
analysis by identifying the
key abstractions
(representation of concepts
identified during business
modeling and requirement
activities) that the system
must handle.
Defining Key Abstractions
 Define analysis class relationships
 Model analysis classes and relationships
on class diagrams
 Include brief description of
analysis class
 Map analysis classes to
necessary analysis
mechanisms
Example: Key Abstractions
Professor Student
Schedule
CourseCatalog CourseOffering Course

Where Are We?
 Checkpoints
Review: What Is a Use-Case Realization?
Use Case
Class Diagrams
Creating Use-Case Realizations
 Provides traceability from Analysis and Design
back to Requirements
 The Architect creates the Use-Case Realization
Requirements Analysis & Design
Use Case Use-Case

Realization
Example: Use-Case Realization
<<use-case realization>> Login

Login (from Use Case View)
(from Use-Case Realization - Login)
<<use-case realization>> Register for Courses

Register for Courses (from Use Case View)
(from Use-Case Realization - Register for Courses)
<<use-case realization>> Close Registration

Close Registration (from Use Case View)
(from Use-Case Realization - Close Registration)
Where Are We?
 Checkpoints
Checkpoints
 General
 Is the package partitioning and
layering done in a logical and
consistent way?
 Have you identified the necessary
analysis mechanisms?
 Packages
 Have you provided a comprehensive
picture of the services of the
packages in upper-level layers?
Checkpoints (cont.)
 Classes
 Are the key entity classes and their
relationships identified and
accurately modeled?
 Does the name of each class clearly
reflect the role it plays?
 Are the key abstractions/classes
and their relationships consistent
with the business model, domain
model, requirements, glossary, etc.?
Review
 What is the purpose of architectural
analysis?
 What is a package?
 What are analysis mechanisms? Give
examples.
 What key abstractions are identified during
architectural analysis? Why are they
identified here?
 What is a layered architecture? Give
examples of typical layers.
Exercise: Architectural Analysis
 Given the following:
 Some results from the requirements
workflow:
• Problem statement
• Use-Case model main diagram
• Glossary
 Some architectural decisions:
• (Textually) The upper-level
architectural layers and their
dependencies
(continued…)
Exercise: Architectural Analysis (cont.)
 Identify the following:
 The key abstractions
Exercise: Architectural Analysis (cont.)
 Produce the following:
 A list of the key abstractions
 Class diagram containing the
upper-level architectural layers
and their dependencies
Exercise: Review
 Compare your key abstractions
with the rest of the class
 Are the key concepts identified?
 Does the name of each class
reflect the role it plays?
 Compare your class diagram
showing the upper-level layers
Payroll System
 Do the package relationships
support the Payroll System
architecture?
Module 5: Distribute Behavior to Classes
(Use-Case Analysis)
Objectives
 Identify analysis classes from a use-case
diagram and use-case specifications
 Demonstrate how to use the analysis class
stereotypes: boundary, control, and entity
 Describe how objects collaborate to realize
system behavior
 Describe class responsibilities
 Demonstrate how to create interaction
diagrams that accurately model use-case
behavior
Use-Case Analysis in Context
Use-Case
Analysis Designer
Use-Case Analysis Overview
Software Architecture
Glossary Use-Case Document
Modeling Guidelines Analysis Classes
Supplementary
Specifications
Use-Case Use-Case Realization

Use-Case Realization
(identified) Analysis (developed)

Analysis Model (optional)
Purpose of Use-Case Analysis
 To identify the classes which
perform the flow of events for
a use case.
 To distribute the use-case
behavior to those classes,
using use-case realizations.
 To identify the responsibilities,
attributes and associations of
the classes.
 To note the usage of
architectural mechanisms.
Overview: 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
Where Are We?
 Supplement the Use-Case
Description
 Distribute Use-Case Behavior to
Classes
 Checkpoints
Supplement the Use-Case Description
• 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?
Description
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
Simple Names java::awt::Rectangle
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
Use Cases Analysis Design Source Exec

Classes Elements Code
Use-Case Analysis
What Is a Boundary Class?
 Models the interaction
between the system’s
surroundings and its inner
workings
 User-interface classes Boundary
 Device-interface classes
 System-interface classes
 Environment-dependent
 GUI-dependent
 Communication protocol-
dependent
The Role of a Boundary Class
<<boundary>>
<<control>>
<<boundary>>
Customer
<<boundary>>
<<entity>> <<entity>>
Model interaction between the system and its environment

Boundary Classes and the User Interface
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
Concentrate on the responsibilities, not the details.

Finding Boundary Classes
 One boundary class per actor/use-case pair
Student Register for Courses Course Catalog System
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?
View Report Card
Student
Maintain Professor Information
Register for Courses
Course Catalog
Login
Registrar
Professor
Billing System
Practice Solution: Boundary Classes
RegisterForCoursesForm CourseCatalogSystem SelectCoursesForm MaintainStudentInfoForm
LoginForm BillingSystem SubmitGradeForm
CloseRegistrationForm ReportCardForm MaintainProfessorForm

What Is a Control Class?
 Controls the behavior of a use
case
 Delegates the work of the use
case to other classes
 Use-case dependent,
environment independent Control
The Role of a Control Class
Coordinate the use-case behavior.

Guidelines: Control Class
 Control classes should only do sequencing.
 A control class should tell other classes to
do something and should never do anything
except for directing.
 Use control classes to decouple boundary
and entity classes.
Finding Control Classes
 One control class per use case
Student Register for Courses Course Catalog System
RegistrationController
Practice: Finding Control Classes
 There is one control class for each complex use
case.
 How many control classes do you see?
View Report Card
Student
Maintain Professor Information
Register for Courses
Course Catalog
Login
Registrar
Professor
Billing System
Practice: Solution
RegistrationController MaintainProfessorController MaintainStudentController
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
Store and manage information in the system.

Guidelines: Entity Class
 Model the key concepts of the system
 Entity classes should contain calculation or
validation logic to solve the system problem
Finding Entity Classes
 Potential Sources
 Glossary
 Business domain model
 Use cases
 Entity objects identified by examining the
nouns and noun phrases in use cases
 Nouns found may be
 Objects
 Descriptions of an object’s state
 External entities and/or actors
 None of the above
How Do You Filter Nouns?
 Traditional, filtering nouns approach
 Underline noun clauses in the use-case flow of
events
 Remove:
• Redundant candidates
• Vague candidates
• Actors (out of scope)
• Implementation constructs
• Attributes (save for later)
• Operations
Pitfalls when Filtering Nouns
 When identifying nouns, be aware that
 Several terms may refer to the same object.
 One term may refer to more than one object.
 Natural language is very ambiguous.
 Any noun can be disguised as a verb and any
verb can be disguised as a noun.
• Results are dependent on the author’s writing
skills.
 Filtering nouns can identify many
unimportant objects.
Practice: Finding Entity Classes
 The “Create a Schedule Scenario”
John enters the Student ID number 369-52-3449 and the system validates the
number. The system asks which semester. John indicates the current
semester and chooses “create a new schedule.”
From a list of available courses, John selects the primary courses: English
101, Geology 110, World History 200, and College Algebra 110. He then
selects the alternate courses: Music Theory 110 and Introduction to Java
Programming 180.
The system determines that John has all the necessary prerequisites by
examining the student record and adds him to the course rosters. The system
indicates that the activity is complete. The system prints the student schedule
and sends billing information for four courses to the billing system for
processing.
 Filter the nouns from this description.

Practice: Solution
 Catalog: List of all courses being
taught in a semester
 Schedule: A list of courses for a
semester for a student
Schedule
 StudentRecord: List of previously Catalogue
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
 Entity class = Model

 Boundary class = View
 Control class = Controller
Where Are We?
Descriptions
Classes
 Checkpoints
Distribute Use-Case Behavior to Classes
 Purpose of this step:
 To express the use-case behavior in terms of
collaborating analysis classes.
 To determine the responsibilities of analysis
classes.
Objects Need to Collaborate
 Objects are useless unless they can
collaborate together to solve a problem.
 Each object is responsible for its own behavior
and status.
 No one object can carry out every responsibility
on its own.
 How do objects interact with each other?
 They interact through messages.
Concept: Messages
 A message is the specification
of a communication among
objects that conveys
information with the
expectation that activity
ensues.
 One object asks another object
to perform an operation.
 Objects communicate with
messages.
Review: Encapsulation
 Hides implementation from clients.

 Clients depend on interface.
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
The class Order has the responsibility to calculate the

total dollar value.
What Is Class Responsibility?
 A responsibility is a
contract or obligation of the
class.
 The class responsibilities
are carried out by the
corresponding attributes
and operations.
 Responsibilities translate
into operations and
attributes as models are
refined.
How Does an Object “Advertise” Responsibilities?
Objects advertise responsibilities through operation
signatures.
 Each operation has a unique signature.

 Each operation specifies the name of the operation,
return type, and the parameters.
 Operations have visibility.
 Visibility describes if the operation is visible and can be
referenced from classes other than the one they are
defined.
• (+) Public visibility can be referenced from other
classes.
• (-) Private visibility cannot be accessed from another
class.
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

Review: The Anatomy of Sequence Diagrams
Client Object Supplier Object
: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
Message
Concept: Link
Client Object
:Client
:Supplier
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.)
 Who has the data needed to perform the

responsibility? If:
 One class has the data - put the responsibility
with the data
 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
Why Collaboration Diagrams?
 Patterns of collaboration emerge.
 Objects can be physically arranged to
represent collaborations.
 Objects can help identify generalization
hierarchies among the classes.
 Collaboration diagrams are most effective
for groups new to OO techniques because
they
 Prevent focusing on procedural design.
 Prevent premature generalization.
 Encourages “Object Think.”
How Are You Doing?
 Things are going well if:
 All classes have meaningful, domain-specific
names.
 Each class has a small set of collaborators.
 There are no “indispensable” classes. A class
that collaborates with everyone needs to be
redefined.
 The classes can handle a change in
requirements.
How Are You Doing? (cont.)
 Things are NOT going well if:
 A number of classes have no
responsibilities.
 A single responsibility gets
assigned to several entity
classes.
 All classes collaborate with
all other classes.
Example: Collaboration Diagram
5: // display course offerings( )
6: // display blank schedule( )
: Course Catalog
4: // get course offerings( )

: RegisterForCoursesForm
: CourseCatalogSystem

8: // create schedule with offerings( )
1: // create schedule( )
7: // select 4 primary and 2 alternate offerings( ) 3: // get course offerings(forSemester)
: RegistrationController
10: // add schedule(Schedule)

: Student
9: // create with offerings( )

:
Schedule
: 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
 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
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?
Descriptions
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?
Descriptions
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
In analysis, do not spend

time on attribute signatures
<<entity>>
CourseOffering
number : String = "100"
startTime : Time
attribute endTime : Time
days : Enum
numStudents : Int
Attribute Usage
 Attributes are used when information is:
 Referred to by value.
 Uniquely “owned” by the objects to which it
belongs and no other object references it.
 Accessed by operations that only get, set, or
perform simple transformations on the
information.
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
Concept: 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
The Relationship Between Links and Associations
 An object is an instance of a class
 In the same way, a link is an instance of an
association
Client Object
:Client
:Supplier
Message
How Do You Find an Association?
Collaboration :Client :Supplier

Diagram
Link
Client Supplier
Class
Diagram Client Supplier
PerformResponsibility()
Association
A relationship for every link.

Practice: What Associations Can You Find?
1: // submit schedule( ) 2: // submit schedule( )
: Student
: RegisterForCoursesForm : RegistrationController
: Student
8: // any conflicts?( )
3: // save( )
4: // submit( )
:Schedule 7: // still open?( )

9: // add student(Schedule)
6: // has pre-requisites(CourseOffering)
:CourseOffering
: Student
5: // is selected?( )
10: // mark as enrolled in( )
:PrimaryScheduleOfferingInfob
Practice: Solution
<<boundary>> <<control>>
RegisterForCoursesForm RegistrationController
Schedule CourseOffering
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
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
currentSchedule
<<entity>> primaryCourses <<entity>>

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.
<<entity>> instructor <<entity>>

Professor CourseOffering
0..1 0..*
Multiplicity Indicators
 Unspecified
 Exactly one
1
 Zero or more (many,
unlimited) 0..*
 One or more 1..*

 Zero or one (optional 0..1
scalar role)
 Specified range 2..4
 Multiple, disjoint
2, 4..6
ranges
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>> 0..* 1 <<entity>>

CourseOffering Course
0..*
preRequisites
0..3
Guidelines: Multiplicity and Role Names
 Focus on realizing the use case
 Role names should be nouns
 Assume a 0..* multiplicity unless there is
clear evidence otherwise
 Within ranges, probabilities may be
specified
Example: Multiplicity
1 1
0..1
+currentSchedule
<<entity>> <<entity>> 0..1 +primaryCourses <<entity>>

Student Schedule CourseOffering
1 0..*
0..* 0..4
What Is Aggregation?
 An aggregation is a special form of
association that models a whole-part
relationship between an aggregate (the
whole) and its parts.
 An aggregation “Is a part-of” relationship.
 Multiplicity is represented like other
associations.
Whole Part
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
 If two objects are usually considered as

independent, although they are often linked
 The relationship is an association.
Car Door
1 0..1
Example: Aggregation
1 1
0..1
+currentSchedule
<<entity>> <<entity>> 0..1 +primaryCourses <<entity>>

Student Schedule CourseOffering
1 0..*
0..* 0..4
<<entity>>
Schedule
1 0..*
Example: Multiple Associations
primaryCourses
alternateCourses
add student to
Schedule remove student from CourseOffering
Multiple associations must reflect multiple roles

Describe Event Dependencies
 Inform objects when an event occurs in
another object
Database
When the database is updated with new information, the graph

needs to be be notified so that it can decide if it needs to update
itself.
Concept: Subscribe-Association
 Objects of the subscribing class are
informed when a particular event has
occurred in objects of the associated class
<<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
// Encapsulates application data() <<subscribe>> // 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()
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>>
StationSupervisor Station Line

Example: Subscribe-Association
1 1
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?
Descriptions
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?
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.
Analysis mechanisms are used during analysis to reduce the complexity of

analysis, and to improve its consistency by providing designers with a short-
hand representation for complex behavior.
Describing Analysis Mechanisms
 Collect all analysis mechanisms in a list
 Draw a map of the client classes to the
analysis mechanisms
Analysis Class Analysis Mechanism(s)
 Identify characteristics of the Analysis

Mechanisms
Example: Describing Analysis Mechanisms
 Analysis class to analysis mechanism map
Analysis Class Analysis Mechanism(s)
Student Persistence, Security

Schedule Persistence, Security
CourseOffering Persistence, Legacy Interface
Course Persistence, Legacy Interface
RegistrationController Distribution
Example: Describing Analysis Mechanisms (cont.)
 Analysis mechanism characteristics
 Persistence for Schedule class:
 Granularity: 1 to 10 Kbytes per product
 Volume: up to 2,000 schedules
• Create: 500 per day
• Read: 2,000 access per hour
• Update: 1,000 per day
• Delete: 50 per day
Where Are We?
Descriptions
Classes
 Checkpoints
Unify Analysis Classes
Where Are We?
Descriptions
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?
(continued)
Checkpoints: Use-Case Realizations
 Have all the main and/or subflows 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
 What is the relationship between a link and
an association?
 What is a subscribe-association?
 What is the difference between an
association and a role name?
 Use-Case Model, especially the
use-case flows of events
 Key abstractions/classes
 The Supplementary Specification
 The possible analysis
mechanisms
 Model from the previous exercise
(continued)
 Identify the following for a particular
use case:
 Analysis class relationships
 Analysis class analysis mechanisms
(continued)
 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?
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?
whole
realization
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
Each layer encapsulates a

conceptual boundary
Concept: Coupling
 Coupling describes how strongly one
element relates to another element
 The goal is to achieve “loose coupling”
• Loose coupling between classes is small,
direct, visible, and has flexible relations with
other classes
Loose
Coupling
Package Coupling: Package Dependencies
 Packages should not
X
A B
be cross-coupled
 Packages in lower Upper

A
layers should not be Layer

dependent upon
packages in upper
layers
X X
Lower B
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 A4 Class A2 - Class A4 Class A2
Class A3 Class A3
PackageB PackageB
+ Class B3 + Class B3
- Class B2 - Class B2
+ Class B1 + Class B1
- Class B4 - Class B4
Strong Coupling Loose Coupling

Concept: Cohesion
 Cohesion describes how strongly related
the responsibilities between design
elements can be described
 The goal is to achieve “high cohesion”
• High cohesion between classes is when class
responsibilities are highly related
Examples: Cohesion
PackageA
<<entity>>
Class A1
0..* CourseOffering
Course
Schedule
0..*
0..4
1
// Create schedule
Student
// Close course
// Open course
// Delete schedule
High package cohesion Low class cohesion

General Checkpoints
 The model is as simple as possible
while still achieving the goals of the
model.
 The model appears to be able to
accommodate reasonably
expected future change.
 The design is appropriate to the
task at hand (neither too complex
nor too advanced).
 The design appears to be
understandable and maintainable.
Layers Checkpoints
 The rationale for layer definition is
clearly presented and consistently
applied.
 Layer boundaries are respected
within the design.
 Layers are used to encapsulate
conceptual boundaries between
different kinds of services and
provide useful abstractions that
make the design easier to
understand.
Where Are We?
whole
realization
Purpose of Review Each Use-Case Realization
 To ensure that the behavior
of the system (as expressed
in use-case realizations)
matches the required
behavior of the system (as
expressed in use cases). Is it
complete?
 To ensure that the behavior is
allocated appropriately
among model elements. Is it
correct?
Check For Missing Behavior and Distribution of Behavior
 Has all use-case behavior been captured in
a diagram?
John enters the Student ID number 369-52-3449 and
the system validates the number. The system asks
which semester. John indicates the current semester
and chooses “create a new schedule.”
From a list of available courses, John selects the
primary courses: English 101, Geology 110, World
History 200, and College Algebra 110. He then
selects the alternate courses: Music Theory 110 and
Introduction to Java Programming 180.
The system determines that John has all the
necessary prerequisites by examining the student
record and adds him to the course rosters. The
system indicates that the activity is complete. The
system prints the student schedule and sends billing :
information for four courses to the billing system for

processing.
Enforcing Consistency
 Check for:
 Duplication of behavior in classes
 Consistent responsibilities
 Updated collaborations if a class has been split
 A class with only one responsibility
Where Are We?
whole
realization
Documenting Results: The Review Record
 Filled out for each
review
 Used as a control
document
Review
 What is the purpose of reviewing the design
model?
 When and how often do you conduct a
review?
 What criteria should you use to examine the
layers of a system?
 What is cohesion? Name three kinds of
cohesion.
Exercise: Review the Design Model
 Given: The design model that you
have been working on
 Identify: Any quality concerns with
the model using the questions in the
student notes
 Produce: A recommendation to
either
 Continue work – the model is considered
complete and work should continue
 Raise change requests – the model is
incomplete and work should not continue
until the defects in the model are
addressed
Module 8: A Look Ahead to Design
Objective
 Provide an overview of design activities that
still need to be performed:
 Define some of the key tasks required in design
 Identify how an analysis class maps to a design
class
 Distinguish the similarities and differences
between subsystems and packages
Where Are We?
 Design Overview
 Architectural activities
• Identify Design Elements
• Identify Subsystems and Interfaces
• Model design and implementation
mechanisms
 Designer activities
Design: A Step Closer to Source Code
Use Cases Analysis Design Source Exec

Classes Elements Code
Design
Design: Tasks to Complete
 Identification of interfaces
 Identification and design of subsystems
 Identification and design of design classes
 Modeling design and implementation
mechanisms
 Modeling nonfunctional requirements (for
example, concurrency and distribution)
Review: Analysis vs. Design
Analysis Design
Focuses on Focuses on
understanding the understanding the
problem solution
Idealized design Close to real code
Behavior Operations and

attributes
Object lifecycles
Functional Nonfunctional
requirements requirements
A small model A large model
Where Are We?
 Design Overview
• Model design and implementation mechanisms
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
mechanisms
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
Realization (Canonical form)

Interface Subsystem
<<subsystem>>
Subsystem
Name
Interface
Realization (Elided form)

Subsystems and Interfaces (cont.)
 Subsystems :
 Completely encapsulate behavior
 Represent an independent capability with clear
interfaces (potential for reuse)
 Model multiple implementation variants
<<subsystem>>
SubsystemA
ClassA1 ClassA2
W() X()
<<Interface>>
InterfaceK
X() <<subsystem>>
W() SubsystemB
ClassB1 ClassB2 ClassB3
W() X() Z()

Y()
Subsystems vs. Packages
Subsystems Packages
 Provide behavior  Don’t provide
 Completely behavior
encapsulate their  Don’t completely
contents encapsulate their
 Are easily contents
Client Class
replaced  May not be easily
replaced
Package B
ClassB1
<<subsystem>> ClassB2
Subsystem A
Encapsulation is the key.

Subsystem Usage
 Subsystems can be used to partition the system into parts
which can be independently:
 ordered, configured, or delivered
 developed, as long as the interfaces remain
unchanged
 deployed across a set of distributed computational
nodes
 changed without breaking other parts of the systems
 Subsystems can also be used to:
 partition the system into units which can provide
restricted security over key resources
 represent existing products or external systems in the
design (for example, components)
Subsystems raise the level of abstraction
Where Are We?
 Design Overview
mechanisms
Review: Course Registration Analysis Mechanisms
 Persistence
 Distribution
 Security
Design Mechanisms: Persistence: RDBMS: JDBC
 Persistence characteristics
 Granularity
 Volume
 Duration
(creation/deletion, update,
read)
 Reliability
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)
1 getConnection(url, user, pass) : Connection
Statement
ResultSet (from java.sql)
Connection
(from java.sql)
(from java.sql)
executeQuery(sql : String) : ResultSet

createStatement() : Statement
getString() : string executeUpdate(sql : String) : int
Example: Persistence: RDBMS: JDBC: Read
: PersistentClient : DBClass : Connection : Statement : ResultSet : PersistentClassList : PersistentClass
1. read(string) returns a The SQL statement

Statement built by the DBClass
1.1. createStatement( ) using the given
criteria is passed to
The criteria used to executeQuery()
access data for the 1.2. executeQuery(string)
persistent class Create a list to hold all
1.3. new( ) retrieved data
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
• Model design and implementation mechanisms
Use-Case Realization Refinement
 Identify participating objects
 Allocate responsibilities among objects
 Model messages between objects
 Describe processing resulting from
messages
 Model associated class relationships
Sequence Diagrams Class Diagrams

Use-Case Realization Refinement Steps
 Identify each object that participates in the
flow of the use-case
 Represent each participating object in a
sequence diagram
 Incrementally incorporate applicable

architectural mechanisms
Representing Subsystems on a Sequence Diagram
 Interfaces
 Represent any model element that realizes the interface
 Should not send messages
 Proxy classes
 Represent a specific subsystem
 Can send messages
Object A Interface Object B Object A Proxy Object B
X
1: Message 1 1: Message 1
2: Message 2 2: Message 2
Invalid message Valid message

Example: Incorporating Subsystem Interfaces
Analysis Classes Design Elements
<<subsystem>>
<<boundary>> Billing System
BillingSystem
IBillingSystem
//submit bill()
submitBill(forTuition : Double, forStudent : Student)
<<boundary>> <<subsystem>>
Course Catalog
CourseCatalogSystem System
//get course offerings()

ICourseCatalogSystem
getCourseOfferings(forSemester : Semester, forStudent : Student) : CourseOfferingList

initialize()
All other analysis classes mapped directly to design classes

Example: Incorporating Subsystem Interfaces (Before)
Analysis class that is to be replaced with an interface
: RegisterForCoursesForm : RegistrationController : CourseCatalogSystem : Schedule : Student
: Student
1. // create schedule( )
1.1. // get course offerings( )
Student wishes to
create a new 1.1.1. // get course offerings(forSemester)
schedule
1.2. // display course offerings( )

A list of the available
course offerings for this
semester are displayed
A blank schedule 1.3. // display blank schedule( )

is displayed for the
students to select
offerings
2. // select 4 primary and 2 alternate offerings( )
2.1. // create schedule with offerings( )

2.1.1. // create with offerings( )
2.1.2. // add schedule(Schedule)
At this point, the Submit Schedule subflow is executed

Example: Incorporating Subsystem Interfaces (After)
Replaced with subsystem interface
: RegisterFor : Registration : ICourseCatalog : Student
: Schedule
: Student CoursesForm Controller System
1.1: // get course offerings( )
Student wishes to
create a new 1.1.1: getCourseOfferings(Semester)
schedule
1.2: // display course offerings( )

A blank schedule 1.3: // display blank schedule( )

students to select
offerings
2: // select 4 primary and 2 alternate offerings( )
2.1: // create schedule with offerings( )

2.1.1: // create with offerings( )
2.1.2: // add schedule(Schedule)
At this, point the Submit Schedule subflow is executed.

Subsystem Responsibilities
 Subsystem responsibilities defined by
interface operations
 Model interface realizations
 Interface operations may be realized by
 Internal class operations
 Internal subsystem operations
<<interface>>
ICourseCatalogSystem <<subsystem>>
CourseCatalogSystem
getCourseOfferings()
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()
subsystem responsibility Op2()
Internal subsystem
Op3() interactions
Op4()
Subsystem interface not shown

Example: CourseCatalogSystem Subsystem In Context
subsystem interface
: RegisterFor : Registration : ICourseCatalog : Schedule : Student
: Student CoursesForm Controller System
Student wishes to
create a new 3: getCourseOfferings(Semester)
schedule
4: // display course offerings( )

subsystem responsibility
A blank schedule 5: // display blank schedule( )

Legacy RDBMS Database Access
students to select
offerings
6: // select 4 primary and 2 alternate offerings( )
7: // create schedule with offerings( )

8: // create with offerings( )
9: // add schedule(Schedule)
At this, point the Submit Schedule subflow is executed.

Review
 List two differences between analysis and
design.
 When does an analysis class map directly
to a design class?
 What is a subsystem? In order to represent
the subsystem, what are your two choices?
 What is an interface?
Where Are You?
 Analysis is the half-way point on the road to
a final design
 Design is covered in Rational University’s
Object-Oriented Design (OOD) course
Design
Mt. Design…just
getting started!
Mt. Analysis …
Analysis
already conquered!

Chapter 1

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 1

Uploaded by

Copyright:

Available Formats

Object-Oriented Analysis

About This Course

Fundamentals of Visual Modeling

The person who is

Register for View Report Login Select Courses

Maintain Maintain Close

Actor Use Case

View Report Card

Register for Courses Maintain Professor Information

Maintain Student Information

Submit Grades Close Registration

Course Registration System Glossary

Course Registration System

The purposes of Analysis and Design are to:

Behavior Operations and

Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational

Logical View Implementation View

Process View Deployment View

Use Case Use-Case Realization

Sequence Diagrams Collaboration Diagrams

Start of Use Case A Use Case B Use Case C

Design Software Architecture

Logical View Implementation View

Process View Deployment View

Parameterized Structural Aspect Behavioral Aspect

Client Package Supplier

 To define the analysis

That’s why we have a persistence

Analysis mechanisms are used during analysis to reduce the complexity of

 Legacy interface mechanism

CourseCatalog CourseOffering Course

Use Case Use-Case Realization

Sequence Diagrams Collaboration Diagrams

Requirements Analysis & Design

Use Case Use-Case

<<use-case realization>> Login

<<use-case realization>> Register for Courses

<<use-case realization>> Close Registration

Use-Case Use-Case Realization

Use-Case Model Design Model

Simple Names java::awt::Rectangle

Use Cases Analysis Design Source Exec

Model interaction between the system and its environment

Concentrate on the responsibilities, not the details.

Student Register for Courses Course Catalog System

View Report Card

Submit Grades Close Registration

RegisterForCoursesForm CourseCatalogSystem SelectCoursesForm MaintainStudentInfoForm

LoginForm BillingSystem SubmitGradeForm

CloseRegistrationForm ReportCardForm MaintainProfessorForm

Coordinate the use-case behavior.

Student Register for Courses Course Catalog System

View Report Card

Submit Grades Close Registration

RegistrationController MaintainProfessorController MaintainStudentController

Store and manage information in the system.

 Filter the nouns from this description.

 Entity class = Model

 Hides implementation from clients.

The class Order has the responsibility to calculate the

 Each operation has a unique signature.

Sequence Diagrams Collaboration Diagrams

 Who has the data needed to perform the