Dev475 Stud Vol1 PDF

Rational
Product Training
DEV475 Mastering
Object-Oriented Analysis
and Design with UML
Student Manual
Version 2003.06.00
Volume 1
Part# 800-026320-000
Rational University
DEV475 Mastering Object-Oriented Analysis and Design with UML
Student Manual
Version 2003.06.00
Volume 1
February, 2003
Copyright 2002, 2003 Rational Software Corporation. All rights reserved.
The contents of this manual and the associated software are the property of
Rational Software and/or its licensors, and are protected by United States copyright laws,
patent laws, and various international treaties. Any reproduction in whole or in part
is strictly prohibited. For additional copies of this manual or software, please contact
Rational Software.
Rational, the Rational logo, ClearQuest, ClearCase, Purify, PureCoverage, Rational Unified
Process, ClearDDTS, and Quantify are trademarks or registered trademarks of Rational
Software Corporation in the United States and in other countries. All names are used for
identification purposes only and are trademarks of their respective companies.
Microsoft Visual Basic, Windows NT, Windows 2000, and Visual SourceSafe are trademarks
or registered trademarks of Microsoft Corporation.
Java and all Java-based marks, among others, are trademarks or registered trademarks of Sun
Microsystems in the United States and/or other countries. All other names are used for
identification purposes only and are trademarks of their respective companies.
Printed in the United States of America.
This manual prepared by:

Rational Software
Rational University
18880 Homestead Road
Cupertino, CA 95014-0721
USA
Tel: 408-863-9900
Fax: 408-863-4099
Register: 888-RATL-444
Web: http://www.rational.com
Contents
Module 0 About This Course
0-1
Course Objectives.......................................................................................... 0-3

Prerequisites .................................................................................................. 0-6
Rational University Curriculum....................................................................... 0-7
Module 1 Best Practices of Software Engineering
1-1
Practice 1: Develop Iteratively ....................................................................... 1-7

Practice 2: Manage Requirements ................................................................ 1-11
Practice 3: Use Component Architectures .................................................... 1-15
Practice 4: Model Visually............................................................................ 1-18
Practice 5: Continuously Verify Quality ........................................................ 1-22
Practice 6: Manage Change ......................................................................... 1-27
Module 2 Concepts of Object Orientation
2-1
What Is Object Technology? .......................................................................... 2-4

Basic Principles of Object Orientation .......................................................... 2-15
Representing Classes in the UML.................................................................. 2-24
Review ........................................................................................................ 2-51
Module 3 Requirements Overview
3-1
Introduction .................................................................................................. 3-3

Key Concepts ................................................................................................ 3-7
Use-Case Model .......................................................................................... 3-10
Glossary....................................................................................................... 3-19
Supplementary Specifications....................................................................... 3-22
Review ........................................................................................................ 3-31
Module 4 Analysis and Design Overview
4-1
Key Concepts ................................................................................................ 4-5

Analysis and Design Workflow ..................................................................... 4-11
Module 5 Architectural Analysis
5-1
Architectural Analysis Overview ..................................................................... 5-4

Key Concepts ................................................................................................ 5-5
Define the high-level Organization of Subsystems......................................... 5-10
Identify Analysis Mechanisms ....................................................................... 5-19
Identify Key Abstractions.............................................................................. 5-28
Create Use-Case Realizations ....................................................................... 5-32
Review ........................................................................................................ 5-38
Module 6 Use-Case Analysis
6-1
Use-Case Analysis Overview .......................................................................... 6-4

Supplement The Use-Case Description .......................................................... 6-6
Find Classes From Use-Case Behavior ............................................................ 6-8
Distribute Use-Case Behavior to Classes ....................................................... 6-26
Describe Responsibilities.............................................................................. 6-36
Describe Attributes and Associations ............................................................ 6-40
Use-Case Analysis Steps ............................................................................... 6-52
Unify Analysis Classes .................................................................................. 6-57
Review ........................................................................................................ 6-63
Acknowledgments
The development of this course was made possible with the help of many individuals, but I would
particularly like to thank the following for their exceptional participation:
Alex Kutsick of Rational University for his course development standards, instructional design
expertise, attention to detail, and correcting my misuse of the English language. Alex is
personally responsible for ensuring that there is a high-level of consistency throughout this
course.
Dan Machado of Rational University for his graphics support.
Kelli Houston of Rational University for her incredible work on OOADv4.0 and OOADv4.2;
all I had to do was carry on what she had started.
The OOAD Steering Committee: Eric Aker, Sinan Alhir, Alex Barclay, Francesco Bonfiglio,
Jerome Desquilbet, Fredrik Ferm, Yves Holvoet, Sean Kelley, Pan Wei Ng, Davyd Norris, Jim
Ruehlin, Jean-Pierre Schoch and Mike Tudball.
Paul Dreyfus and his team of editors for assisting in reviewing the material.
Last but certainly not least, DeAnna Roberts of the Rational University production team for her
fulfillment and logistical support.
January, 2003
Lee Ackerman
Rational University Sr. Product Manager/ OO Curriculum
lackerman@rational.com
Works Cited
The following sources were used to develop this courseware. When quoted directly, we cite the source
after the quoted passage. For all other uses, we respectfully acknowledge below the authors
contributions in the development of this courseware.
The Deadline: A Novel About Project Management, Tom DeMarco, Dorset House Publishing,
1997.
Dictionary of Object Technology: The Definitive Desk Reference, Donald G. Firesmith and Edward
M. Eykholt, Prentice Hall, 1995.
Meta Fax, 09/15/97.
news@sei, Vol. 1, No. 2.
Object Technology: A Managers Guide, David A. Taylor, Addison-Wesley, 1999.
Pattern-Oriented Software Architecture: A System of Patterns, Frank Buschman et al., John Wiley &
Sons, 1996.
The Rational Unified Process, An Introduction, Phillippe Kruchten, Addison-Wesley, 1999.
UML Distilled, Martin Fowler and Kendall Scott, Addison-Wesley, 1997.
UML Toolkit, Hans-Erik Eriksson and Magnus Penker, John Wiley & Sons, 1997.
The Unified Modeling Language User Guide, Grady Booch, James Rumbaugh, Ivar Jacobson,
Addison-Wesley, 1999.
Visual Modeling with Rational Rose and UML, Terry Quatrani, Addison-Wesley, 1998.
Module 0
About This Course
Mastering Object-Oriented Analysis

and Design with UML
Module 0: About This Course
Topics
Course Objectives ................................................................................................ 0-3
Prerequisites......................................................................................................... 0-6
Rational University Curriculum ............................................................................. 0-7
0-1
Introductions
Introductions
Your organization
Your role
Your background, experience
Object technology experience
Software development experience
Implementation language experience
Your expectations for this course
Mastering Object Oriented Analysis and Design with UML

Copyright 2003 Rational Software, all rights reserved
0-2
Module 0 - About This Course
Course Objectives
Course Objectives
Upon completion of the course, participants
will be able to:
Apply an iterative, use case-driven,
architecture-centric process to the development
of a robust design model
Use the Unified Modeling Language (UML) to
represent the design model
Apply Object-Oriented (OO) concepts:
abstraction, encapsulation, inheritance,
hierarchy, modularity, and polymorphism to the
development of a robust design model
During this course, you will be introduced to the concepts, process, and notation for
developing a design model. You will be using the Rational Unified Process Analysis
and Design workflow as your framework. These concepts can also be applied within
any software development process.
0-3
Course Objectives (cont.)
Course Objectives (cont.)

Upon completion of the course, participants
will be able to:
Describe the different views of software
architecture, key mechanisms that are defined
in support of that architecture, and the effect of
the architecture on the produced design
Define basic design considerations, including
the use of patterns

The concentration will be on those activities that are performed by the objectoriented designer. Architectural concepts will be introduced and discussed, as they
drive the design, but this is not an architecture course.
0-4
Intended Audience
Intended Audience
Intended Audience
Practitioners who want a basic explanation of
Object-Oriented Analysis and Design (OOAD)
concepts, as well as hands-on practical
experience in applying the techniques
Analysts, designers, software developers

0-5
Prerequisites
Prerequisites
Some experience applying the following
techniques in a software development
environment
An exposure to object technology including, how to:
Read a use-case model

Add classes, objects, associations and how to create simple
interaction and class diagrams
Find classes and distribute class behavior
Distinguish between the UML Analysis class stereotypes:
boundary, control, and entity
Prerequisites can be achieved through attendance in

Essentials of Visual Modeling with UML or
equivalent experience

0-6
Rational University Curriculum

Curriculum Flow:
Designer
Instructor-led
Web-based
Optional
Path 1
DEV110
Principles of
Modeling
DEV111
Principles of
UC Modeling
with UML
DEV112
Principles of
Analysis I
DEV113
Principles of
Analysis II
DEV305
Essentials of
Rational
Rose
2 hours
2 hours
2 hours
2 hours
5 hours
OR
OR
Path 2
DEV275
Essentials
of Visual
Modeling
with UML
1 day
DEV475
Mastering Object
Oriented
Analysis &
Design with UML
4 days
Fund. of
Rational
Rose
1 day
The Rational University curriculum offers the courses shown here and on the next
two slides. As you can see, for each major software development team role, Rational
University offers a professional development course.
The Requirements Management with Use Cases may be particularly interesting to you,
as it is where you will learn to develop use cases, the artifacts that drive much of what
you do in Analysis and Design.
0-7

Curriculum Flow:
Enterprise Architect
Instructor-led
Web-based
Optional
Path 1
PRJ110
Principles of
Rational
Unified
Process
3 hours
DEV275
Essentials
of Visual
Modeling
with UML
DEV111
Principles of
UC Modeling
with UML
DEV112
Principles of
Analysis I
DEV113
Principles of
Analysis II
1 day
2 hours
2 hours
2 hours
OR
Path 2
DEV475
Mastering Object
Oriented
Analysis &
Design with UML
4 days
DEV110
Principles of
Modeling
2 hours
0-8
Principles of
Architecting
Software
Systems
3 days

Curriculum Flow:
Analyst
Req.
Management
with Use
Cases
3 days
Instructor-led
Web-based
Optional
REQ310
Essentials of
Rational
RequisitePro
DEV110
Principles of
Modeling
DEV305
Essentials of
Rational
Rose
5 hours
2 hours
2 hours
OR
OR
Fund. Of
Rational
RequisitePro
DEV275
Essentials
of Visual
Modeling
with UML
Fund. of
Rational
Rose
1 day
1 day
1 day
OR

0-9
Course Materials
Course Materials
Student Manual, Books 1, 2, and 3
Additional Information Appendix
Course Registration Requirements
Document
Payroll Requirements Document
Payroll Architecture Handbook
Payroll Solution Appendix
Course Registration Models and Payroll
Solutions Models CD
UML Users Guide by Grady Booch
10
The Student Manual contains copies of the slides, as well as detailed Student Notes.
The Student Manual is comprised of two books.
The Additional Information Appendix contains a collection of additional topics that
are not general enough to be included in the base course, or may be considered too
advanced for the introductory audience. These topics may or may not be covered by
the instructor. This appendix contains the UML-To-Language Maps that show the
map from the UML to implementation language constructs for the following
languages: C++, Java, PowerBuilder, and Visual Basic. It also contains information
on several additional Architectural Mechanisms.
The requirements that drive the development of the example and exercise design
models are documented in the Course Registration Requirements Document and
the Payroll Requirements Document, respectively.
The architectural givens that guide the students in the development of the exercise
design model are documented in the Payroll Architecture Handbook.
The Payroll Solution Appendix contains the hard-copy of the course exercise
solutions. The Rose models for the course example and course solutions are provided
on the Course Registration Models and Payroll Solutions Models CD.
0 - 10
Other Sources of Information
Other Sources of Information

Student Manual
Detailed reference list provided
Rational Unified Process

www.rational.com/products/rup/index.jsp
Rational Web Site

www.rational.com
Rational Developer Network

www.rational.net

11
0 - 11
Logistics
Logistics
Morning
2-Fifteen-minute breaks
Lunch
1 Hour
Afternoon
2-Fifteen-minute breaks

0 - 12
12
Module 1
Best Practices of Software Engineering

and Design with UML
Module 1: Best Practices of Software
Engineering
Topics
Practice 1: Develop Iteratively .............................................................................. 1-7
Practice 2: Manage Requirements ...................................................................... 1-11
Practice 3: Use Component Architectures........................................................... 1-15
Practice 4: Model Visually (UML)........................................................................ 1-18
Practice 5: Continuously Verify Quality............................................................... 1-22
Practice 6: Manage Change ................................................................................ 1-27
1-1
Objectives
Objectives
Identify activities for understanding and
solving software engineering problems.
Explain the Six Best Practices.
Present the Rational Unified Process (RUP)
within the context of the Six Best Practices.

In this module, you learn about recommended software development Best Practices
and the reasons for these recommendations. Then you see how the Rational Unified
Process (RUP) is designed to help you implement the Six Best Practices.
1-2
Module 1 - Best Practices of Software Engineering
Module 1 Content Outline

Software development problems
The Six Best Practices
RUP within the context of the Six Best
Practices

1-3
Symptoms of Software Development Problems
Symptoms of Software Development Problems

9User or business needs not met
9Requirements not addressed
9Modules not integrating
9Difficulties with maintenance
9Late discovery of flaws
9Poor quality of end-user experience
9Poor performance under load
9No coordinated team effort
9Build-and-release issues
1-4
Trace Symptoms to Root Causes
Trace Symptoms to Root Causes

Symptoms
Root Causes
Needs not met
Insufficient requirements
Requirements churn
Ambiguous communications
Modules do
notfitfit
dont
Brittle architectures
Hard to maintain
Overwhelming complexity
Late discovery
Undetected inconsistencies
Poor quality
Poor testing
Poor performance
Subjective assessment
Colliding developers
Waterfall development
Build-and-release
Uncontrolled change
Insufficient automation

Best Practices
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually
Visually (UML)
(UML)
Model
Continuously Verify
Verify Quality
Quality
Continuously
Manage Change
Treat these root causes, and you will eliminate the symptoms. Eliminate the
symptoms, and youll be in a much better position to develop quality software in a
repeatable and predictable fashion.
Best practices are a set of commercially proven approaches to software development,
which, when used in combination, strike at the root causes of software development
problems. These are called Best Practices, not because we can precisely quantify
their value, but because they are observed to be commonly used in the industry by
successful organizations. The Best Practices are harvested from thousands of
customers on thousands of projects and from industry experts.
1-5

Practices

1-6
Practice 1: Develop Iteratively

Practice 1: Develop Iteratively
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component
Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Developing iteratively is a technique that is used to deliver the functionality of a

system in a successive series of releases of increasing completeness. Each release is
developed in a specific, fixed time period called an iteration.
Each iteration is focused on defining, analyzing, designing, building, and testing a set
of requirements.
1-7
Waterfall Development Characteristics
Waterfall Development Characteristics

Delays confirmation of
critical risk resolution
Measures progress by
assessing work
products that are poor
predictors of time-tocompletion
Delays and aggregates
integration and testing
Precludes early
deployment
Frequently results in
major unplanned
iterations
Waterfall Process
Requirements
analysis
Design
Code and unit test
Subsystem integration
System test

Waterfall development is conceptually straightforward because it produces a single

deliverable. The fundamental problem of this approach is that it pushes risk forward
in time, when it is costly to undo mistakes from earlier phases. An initial design may
be flawed with respect to its key requirements, and late discovery of design defects
may result in costly overruns and/or project cancellation. The waterfall approach
tends to mask the real risks to a project until it is too late to do anything meaningful
about them.
1-8
Iterative Development Produces an Executable
Iterative Development Produces an Executable

Requirements
Analysis & Design
Planning
Implementation
Initial
Planning
Management
Environment
Test
Evaluation
Deployment
Each iteration
results in an
executable release

The earliest iterations address the greatest risks. Each iteration includes integration
and testing and produces an executable release. Iterations help:
Resolve major risks before making large investments.
Enable early user feedback.
Make testing and integration continuous.
Focus project short-term objective milestones.
Make possible deployment of partial implementations.
Iterative processes were developed in response to these waterfall characteristics. With

an iterative process, the waterfall steps are applied iteratively. Instead of developing
the whole system in lock step, an increment (for example, a subset of system
functionality) is selected and developed, then another increment, and so on. The
selection of the first increment to be developed is based on risk, with the highest
priority risks first. To address the selected risk(s), choose a subset of use cases.
Develop the minimal set of use cases that will allow objective verification (that is,
through a set of executable tests) of the risks that you have chosen. Then select the
next increment to address the next-highest risk, and so on. Thus you apply the
waterfall approach within each iteration, and the system evolves incrementally.
1-9
Risk Profiles
Risk Profiles
Risk
Waterfall Risk
Risk Reduction
Iterative Risk
Time
10
Iterative development produces the architecture first, allowing integration to occur as

the verification activity of the design phase, and allowing design flaws to be
detected and resolved earlier in the lifecycle. Continuous integration throughout the
project replaces the big bang integration at the end of a project. Iterative
development also provides much better insight into quality, because system
characteristics that are largely inherent in the architecture (for example, performance,
fault tolerance, and maintainability) are tangible earlier in the process. Thus, issues
are still correctable without jeopardizing target costs and schedules.
1 - 10
Practice 2: Manage Requirements

Practice 2: Manage Requirements
Best Practices
Develop Iteratively
Manage Requirements
Use Component
Architectures
Manage Change
11
A report from the Standish Group confirms that a distinct minority of software
development projects is completed on-time and on-budget. In their report, the
success rate was only 16.2%, while challenged projects (operational, but late and
over-budget) accounted for 52.7%. Impaired (canceled) projects accounted for
31.1%. These failures are attributed to incorrect requirements definition from the start
of the project to poor requirements management throughout the development
lifecycle. (Source: Chaos Report, http://www.standishgroup.com)
1 - 11
Requirements Management
Requirements Management
Making sure you
solve the right problem
build the right system
by taking a systematic approach to
eliciting
organizing
documenting
managing
the changing requirements of a
software application.

1 - 12
12
Aspects of Requirements Management
Aspects of Requirements Management

Analyze the Problem
Understand User Needs
Define the System
Manage Scope
Refine the System Definition
Manage Changing Requirements

13
1 - 13
Map of the Territory
Map of the Territory

Problem
Space
Problem
Needs
Solution
Space
Tr
bil
ea
ac
Features
it y
The
Product
to Be
Built
Software
Requirements
Test Scripts

Design
User
Docs
14
Managing requirements involves the translation of stakeholder requests into a set of

key stakeholder needs and system features. These in turn are detailed into
specifications for functional and nonfunctional requirements. Detailed specifications
are translated into test procedures, design, and user documentation.
Traceability allows us to:
1 - 14
Assess the project impact of a change in a requirement.
Assess the impact of a failure of a test on requirements (that is, if the test fails, the
requirement may not be satisfied).
Manage the scope of the project.
Verify that all requirements of the system are fulfilled by the implementation.
Verify that the application does only what it is intended to do.
Manage change.
Practice 3: Use Component Architectures

Practice 3: Use Component Architectures
Best Practices
Develop Iteratively
Manage Requirements
Use Component
Architectures
Manage Change
15
Software architecture is the development product that gives the highest return on
investment with respect to quality, schedule, and cost, according to the authors of
Software Architecture in Practice (Len Bass, Paul Clements and Rick Kazman [1998]
Addison-Wesley). The Software Engineering Institute (SEI) has an effort underway
called the Architecture Tradeoff Analysis (ATA) Initiative that focuses on software
architecture, a discipline much misunderstood in the software industry. The SEI has
been evaluating software architectures for some time and would like to see
architecture evaluation in wider use. As a result of performing architecture
evaluations, AT&T reported a 10 percent productivity increase (from news@sei, Vol.
1, No. 2).
1 - 15
Resilient Component-Based Architectures
Resilient Component-Based Architectures

Resilient
Meets current and future requirements
Improves extensibility
Enables reuse
Encapsulates system dependencies
Component-based
Reuse or customize components
Select from commercially available components
Evolve existing software incrementally

16
Architecture is a part of Design. It is about making decisions on how the system will
be built. But it is not all of the design. It stops at the major abstractions, or, in other
words, the elements that have some pervasive and long-lasting effect on system
performance and ability to evolve.
A software systems architecture is perhaps the most important aspect that can be
used to control the iterative and incremental development of a system throughout its
lifecycle.
The most important property of an architecture is resilience flexibility in the face of
change. To achieve it, architects must anticipate evolution in both the problem
domain and the implementation technologies to produce a design that can gracefully
accommodate such changes. Key techniques are abstraction, encapsulation, and
object-oriented Analysis and Design. The result is that applications are fundamentally
more maintainable and extensible.
1 - 16
Purpose of a Component-Based Architecture
Purpose of a Component-Based Architecture

Basis for reuse
Component reuse
Architecture reuse
Basis for project management

Planning
Staffing
Delivery
Applicationspecific
Businessspecific
Intellectual control
Middleware
Manage complexity
Maintain integrity
Component-based
architecture with
layers
Systemsoftware
17
Definition of a (software) component:

RUP Definition: A nontrivial, nearly independent, and replaceable part of a system
that performs a clear function in the context of a well-defined architecture. A
component conforms to and provides the physical realization of a set of interfaces.
UML Definition: A physical, replaceable part of a system that packages
implementation, and that conforms to and provides the realization of a set of
interfaces. A component represents a physical piece of the implementation of a
system, including software code (source, binary, or executable) or equivalents such as
scripts or command files.
1 - 17
Practice 4: Model Visually

Practice 4: Model Visually (UML)
Best Practices
Develop Iteratively
Manage Requirements
Use Component
Architectures
Manage Change
18
A model is a simplification of reality that provides a complete description of a system

from a particular perspective. We build models so that we can better understand the
system we are building. We build models of complex systems because we cannot
comprehend any such system in its entirety.
1 - 18
Why Model Visually?
Why Model Visually?

Captures structure and behavior
Shows how system elements fit together
Keeps design and implementation
consistent
Hides or exposes details as appropriate
Promotes unambiguous communication
The UML provides one language for all
practitioners

19
Modeling is important because it helps the development team visualize, specify,

construct, and document the structure and behavior of system architecture. Using a
standard modeling language such as the UML (the Unified Modeling Language),
different members of the development team can communicate their decisions
unambiguously to one another.
Using visual modeling tools facilitates the management of these models, letting you
hide or expose details as necessary. Visual modeling also helps you maintain
consistency among system artifacts - its requirements, designs, and implementations.
In short, visual modeling helps improve a teams ability to manage software
complexity.
1 - 19
Visual Modeling With the Unified Modeling Language
Visual Modeling With the Unified Modeling Language

Multiple views
Precise syntax and
semantics
Sequence
Diagrams
Collaboration
Diagrams
Dynamic
Diagrams
Static
Diagrams
Class
Diagrams
Use-Case
Diagrams
Object
Diagrams
Component
Diagrams
Models
Statechart
Diagrams

Activity
Diagrams
Deployment
Diagrams
20
In building a visual model of a system, many different diagrams are needed to

represent different views of the system. The UML provides a rich notation for
visualizing models. This includes the following key diagrams:
1 - 20
Use-Case diagrams to illustrate user interactions with the system
Class diagrams to illustrate logical structure
Object diagrams to illustrate objects and links
Component diagrams to illustrate physical structure of the software
Deployment diagrams to show the mapping of software to hardware

configurations
Activity diagrams to illustrate flows of events
Statechart diagrams to illustrate behavior
Interaction diagrams (that is, collaboration and sequence diagrams) to illustrate

behavior
Visual Modeling Using UML Diagrams
Visual Modeling Using UML Diagrams

Use-Case
Diagram
Class Diagram
Statechart
Diagram
add file
Docu me ntList
Use Case 1
FileMgr
Actor A
Actor B
Document
ad d( )
del ete( )
fetchD oc( )
sortB yName( )
name : i nt
doci d : int
numFiel d : int
get( )
open( )
close( )
read( )
sortFileList( )
create( )
fillDocu me nt( )
Use Case 2
FileList
fList
add( )
del ete( )
add file [ numberOffile==MAX ] /

flag OFF
read() fill the
cod e..
Writing
Openning
close file
Use Case 3
close file
Closing
Reading
rep
Rep ositor y
(from Persiste nce)
File
read( )
GrpFile
na me : c har * = 0
readD oc( )
readFil e( )
Collaboration
Diagram
9: sortByN ame ( )
Repository
mainWnd : MainWnd
1: Doc vi ew request ( )
read( )
op en( )
create( )
fillFile( )
DocumentList
Deployment
Diagram
Windows95
Window95
FileManager
W indow s95
2: fetc hDoc( )
-
.EXE
Document
gFile : GrpFile
4: create ( )
8: fillFile ( )
W indow s
NT
user : Clerk
S olaris
fileMgr : FileMgr
- .EXE
GraphicFile
3: create ( )
Alpha
UN IX
-.EXE
6: fillDoc ument ( )
File
FileList
Windows
NT
IBM
Mainfra me
7: readFile ( )
5: readDoc ( )
document : Document
repository : Repository
mainWnd
user
-
.
fileMgr :
FileMgr
document :
Document
gFile
repository
1: Doc v iew request ( )
2: fetchDoc ( )
Component
Diagram
Target
System
3: create ( )
4: create ( )
5: readDoc ( )
-
- .
6: fill Document ( )
7: readFile ( )
8: fillFile ( )
-

-
Forward and
Reverse
Engineering
9: sortByName ( )
Sequence
Diagram
21
Visual modeling with the UML makes application architecture tangible, permitting us
to assess it in multiple dimensions. How portable is it? Can it exploit expected
advances in parallel processing? How can you modify it to support a family of
applications?
We have discussed the importance of architectural resilience and quality. The UML
enables us to evaluate these key characteristics during early iterations at a point
when design defects can be corrected before threatening project success.
Advances in forward and reverse engineering techniques permit changes to an
applications model to be reflected automatically in its source code, and changes to
its source code to be automatically reflected in its model. This is critical when using
an iterative process, in which we expect such changes with each iteration.
1 - 21
Practice 5: Continuously Verify Quality

Practice 5: Continuously Verify Quality
Best Practices
Develop Iteratively
Manage Requirements
Use Component
Architectures
Continuously
Verify Quality
Manage Change
22
Quality, as used within RUP, is defined as "The characteristic of having demonstrated

the achievement of producing a product which meets or exceeds agreed-upon
requirements, as measured by agreed-upon measures and criteria, and is produced
by an agreed-upon process." Given this definition, achieving quality is not simply
"meeting requirements" or producing a product that meets user needs and
expectations. Quality also includes identifying the measures and criteria (to
demonstrate the achievement of quality), and the implementation of a process to
ensure that the resulting product has achieved the desired degree of quality (and can
be repeated and managed).
In many organizations, software testing accounts for 30% to 50% of software
development costs. Yet most people believe that software is not well-tested before it
is delivered. This contradiction is rooted in two clear facts. First, testing software is
enormously difficult. The different ways a particular program can behave are almost
infinite. Second, testing is typically done without a clear methodology and without
the required automation or tool support. While the complexity of software makes
complete testing an impossible goal, a well-conceived methodology and use of stateof-the-art tools can greatly improve the productivity and effectiveness of the software
testing.
1 - 22
Continuously Verify Your Softwares Quality
Continuously Verify Your Softwares Quality

Software problems are
100 to 1000 times more costly
to find and repair after deployment
Cost to Repair Software
Cost of Lost Opportunities
Cost
Cost of Lost Customers
Inception
Elaboration

Construction
Transition
23
This principle is driven by a fundamental and well-known property of software

development: It is a lot less expensive to correct defects during development than to
correct them after deployment.
Tests for key scenarios ensure that all requirements are properly implemented.
Poor application performance hurts as much as poor reliability.
Verify software reliability memory leaks, bottlenecks.
Test every iteration automate test.
1 - 23
Testing Dimensions of Quality
Testing Dimensions of Quality

Usability
Test application
from the perspective
of convenience to
end user.
Functionality
Reliability
Test the accurate

workings of each
usage scenario.
Test that the application

behaves consistently
and predictably.
Supportability
Performance
Test the ability to

maintain and support
application under
production use.
Test the online response

under average and
peak loading.

24
Functional testing verifies that a system executes the required use-case scenarios as
intended. Functional tests may include the testing of features, usage scenarios, and
security.
Usability testing evaluates the application from the users perspective. Usability tests
focus on human factors, aesthetics, consistency in the user interface, online and
context-sensitive Help, wizards and agents, user documentation, and training
materials.
Reliability testing verifies that the application performs reliably and is not prone to
failures during execution (crashes, hangs, and memory leaks). Effective reliability
testing requires specialized tools. Reliability tests include tests of integrity, structure,
stress, contention, and volume.
Performance testing checks that the target system works functionally and reliably
under production load. Performance tests include benchmark tests, load tests, and
performance profile tests.
Supportability testing verifies that the application can be deployed as intended.
Supportability tests include installation and configuration tests.
1 - 24
Test Each Iteration
Test Each Iteration

Iteration 1
Iteration 2
Iteration 3
Iteration 4
Test Suite 1
Test Suite 2
Test Suite 3
Test Suite 4
UML Model
and
Implementation
Tests

25
In each iteration, automated tests are created that test the requirements addressed in
that iteration. As new requirements are added in subsequent iterations, new tests are
generated and run. At times, a requirement may be changed in a later iteration. In
that case, the tests associated with the changed requirement may be modified or
simply regenerated by an automated tool.
1 - 25
Test Within the Product Development Lifecycle
Test Within the Product Development Lifecycle

Iteration
X
Iteration
X+1
Iteration
X+2
Requirements Capture
Analysis and Design
Project
Planning
Define
Mission
Implementation
Build
Validate
Build
Test and
Evaluate
Achieve
Mission
Improve
Assets
Verify Approach
Time

26
The testing lifecycle is a part of the software lifecycle; both should start in an
equivalent time frame. The design and development process for tests can be as
complex and arduous as the process for developing the software product itself. If tests
do not start in line with the first executable software releases, the test effort will back
load the discovery of potentially important problems until late in the development
cycle.
1 - 26
Practice 6: Manage Change

Practice 6: Manage Change
Best Practices
Develop Iteratively
Manage Requirements
Use Component
Architectures
Manage Change
27
You cannot stop change from being introduced into a project. However, you must
control how and when changes are introduced into project artifacts, and who
introduces those changes.
You must also synchronize changes across development teams and locations.
Unified Change Management (UCM) is the Rational Software approach to managing
change in software system development, from requirements to release.
1 - 27
What Do You Want to Control?
What Do You Want to Control?

Secure workspaces for each developer
Automated integration/build management
Parallel development
Workspace
Management
Configuration
Management is
more than just
check-in and
check-out
Parallel
Development
REPORT
Process
Integration

ALERT
Build
Management
28
Establishing a secure workspace for each developer provides isolation from changes
made in other workspaces and control of all software artifacts models, code,
documents and so forth.
A key challenge to developing software-intensive systems is the need to cope with
multiple developers, organized into different teams, possibly at different sites, all
working together on multiple iterations, releases, products, and platforms. In the
absence of disciplined control, the development process rapidly degrades into chaos.
Progress can come to a stop.
Three common problems that result are:
1 - 28
Simultaneous update: When two or more roles separately modify the same
artifact, the last one to make changes destroys the work of the former.
Limited notification: When a problem is fixed in shared artifacts, some of the

users are not notified of the change.
Multiple versions: With iterative development, it would not be unusual to have

multiple versions of an artifact in different stages of development at the same
time. For example, one release is in customer use, one is in test, and one is still in
development. If a problem is identified in any one of the versions, the fix must be
propagated among all of them.
Aspects of a CM System
Aspects of a CM System
Change Request Management (CRM)
Configuration Status Reporting
Configuration Management (CM)
Change Tracking
Version Selection
Software Manufacture

29
Change Request Management (CRM) addresses the organizational infrastructure

required to assess the cost and schedule impacts of a requested change to the existing
product. CRM addresses the workings of a Change Review Team or Change Control
Board.
Configuration Status Reporting (Measurement) is used to describe the state of
the product based on the type, number, rate and severity of defects found and fixed
during the course of product development. Metrics derived under this aspect,
through either audits or raw data, are useful in determining the overall completeness
of the project.
Configuration Management (CM) describes the product structure and identifies its
constituent configuration items, which are treated as single versionable entities in the
configuration management process. CM deals with defining configurations, building
and labeling, and collecting versioned artifacts into constituent sets, as well as with
maintaining traceability among these versions.
Change Tracking describes what is done to components for what reason and at what
time. It serves as the history of and rationale for changes. It is quite separate from
assessing the impact of proposed changes as described under Change Request
Management.
Version Selection ensures that the right versions of configuration items are selected
for change or implementation. Version selection relies on a solid foundation of
configuration identification.
Software Manufacture covers the need to automate the steps to compile, test, and
package software for distribution.
1 - 29
Unified Change Management (UCM)
Unified Change Management (UCM)

UCM involves:
Management across the lifecycle
System
Project Management
Activity-Based Management
Tasks
Defects
Enhancements
Progress Tracking
Charts
Reports
30
Unified Change Management (UCM) is Rational Software's approach to managing

change in software system development, from requirements to release. UCM spans
the development lifecycle, defining how to manage change to requirements, design
models, documentation, components, test cases, and source code.
One of the key aspects of the UCM model is that it unifies the activities used to plan
and track project progress and the artifacts undergoing change.
1 - 30
Best Practices Reinforce Each Other
Best Practices Reinforce Each Other

Best Practices
Develop Iteratively
Ensures users are involved
as requirements evolve
Manage Requirements
Validates architectural
decisions early on
Addresses complexity of
design/implementation incrementally

Measures quality early and often
Manage Change
Evolves baselines incrementally

31
In the case of our Six Best Practices, the whole is much greater than the sum of the
parts. Each of the Best Practices reinforces and, in some cases, enables the others.
This slide shows just one example: how iterative development leverages the other five
Best Practices. However, each of the other five practices also enhances iterative
development. For example, iterative development done without adequate
requirements management can easily fail to converge on a solution. Requirements
can change at will, users cannot agree, and the iterations go on forever.
When requirements are managed, this is less likely to happen. Changes to
requirements are visible, and the impact on the development process is assessed
before the changes are accepted. Convergence on a stable set of requirements is
ensured. Similarly, each pair of Best Practices provides mutual support. Hence,
although it is possible to use one Best Practice without the others, it is not
recommended, since the resulting benefits will be significantly decreased.
1 - 31

Practices

1 - 32
32
Rational Unified Process Implements Best Practices
Rational Unified Process Implements Best Practices
Best Practices

Develop Iteratively
Manage Requirements
Manage Change

33
Why have a process?
Provides guidelines for efficient development of quality software
Reduces risk and increases predictability
Promotes a common vision and culture
Captures and institutionalizes Best Practices
The Rational Unified Process (RUP) is a generic business process for object-oriented
software engineering. It describes a family of related software-engineering processes
sharing a common structure and a common process architecture. It provides a
disciplined approach to assigning tasks and responsibilities within a development
organization. Its goal is to ensure the production of high-quality software that meets
the needs of its end users within a predictable schedule and budget. The RUP
captures the Best Practices in modern software development in a form that can be
adapted for a wide range of projects and organizations.
The UML provides a standard for the artifacts of development (semantic models,
syntactic notation, and diagrams): the things that must be controlled and exchanged.
But the UML is not a standard for the development process. Despite all of the value
that a common modeling language brings, you cannot achieve successful
development of todays complex systems solely by the use of the UML. Successful
development also requires employing an equally robust development process, which
is where the RUP comes in.
1 - 33
Achieving Best Practices
Achieving Best Practices

Iterative approach
Guidance for activities
and artifacts
Process focus on
architecture
Use cases that drive
design and
implementation
Models that abstract
the system

34
Examples:
1 - 34
The dynamic structure (phases and iterations) of the Rational Unified Process
creates the basis of iterative development.
The Project Management discipline describes how to set up and execute a

project using phases and iterations.
The Use-Case Model of the Requirements discipline and the risk list determine
what functionality you implement in an iteration.
The Workflow Details of the Requirements discipline show the activities and
artifacts that make requirements management possible.
The iterative approach allows you to progressively identify components, and to

decide which one to develop, which one to reuse, and which one to buy.
The Unified Modeling Language (UML) used in the process represents the basis
of visual modeling and has become the de facto modeling language standard.
The focus on software architecture allows you to articulate the structure: the
components, the ways in which they integrate, and the fundamental mechanisms
and patterns by which they interact.
A Team-Based Definition of Process
A Team-Based Definition of Process

A process defines Who is doing What,
When, and How, in order to reach a certain
goal.
New or changed
requirements

Software Engineering
Process
New or changed
system
35
1 - 35
Process Structure - Lifecycle Phases
Process Structure - Lifecycle Phases

Inception
Elaboration
Construction
Transition
time
Rational Unified Process has four phases:

Inception - Define the scope of project
Elaboration - Plan project, specify features and
baseline architecture
Construction - Build the product
Transition - Transition the product into end-user
community

36
During Inception, we define the scope of the project: what is included and what is
not. We do this by identifying all the actors and use cases, and by drafting the most
essential use cases (typically 20% of the complete model). A business plan is
developed to determine whether resources should be committed to the project.
During Elaboration, we focus on two things: getting a good grasp of the requirements
(80% complete) and establishing an architectural baseline. If we have a good grasp of
the requirements and the architecture, we can eliminate a lot of the risks, and we will
have a good idea of how much work remains to be done. We can make detailed
cost/resource estimations at the end of Elaboration.
During Construction, we build the product in several iterations up to a beta release.
During Transition, we move the product to the end user and focus on end-user
training, installation, and support.
The amount of time spent in each phase varies. For a complex project with many
technical unknowns and unclear requirements, Elaboration may include three-to-five
iterations. For a simple project, where requirements are known and the architecture
is simple, Elaboration may include only a single iteration.
1 - 36
Phase Boundaries Mark Major Milestones
Phase Boundaries Mark Major Milestones
Inception
Elaboration
Construction
Transition
time
Lifecycle
Objective
Milestone
(LCO)

Lifecycle
Architecture
Milestone
(LCA)
Initial Operational
Capability
Milestone
(IOC)
Product
Release
37
At each of the major milestones, we review the project and decide whether to
proceed with it as planned, to cancel the it, or to revise it. The criteria used to make
these decisions vary by phase.
LCO: scope is agreed upon and risks are understood and reasonable
LCA: high risks are addressed and architecture is stable
IOC: product is complete and quality is acceptable
The evaluation criteria for the Inception phase (LCO) include: stakeholder
concurrence on scope definition and cost/schedule estimates; requirements
understanding as evidenced by the fidelity of the primary use cases; credibility of
cost/schedule estimates, priorities, risks, and development process; depth and
breadth of any architectural prototype; actual expenditures versus planned
expenditures.
The evaluation criteria for the Elaboration phase (LCA) include: stability of the
product vision and architecture; resolution of major risk elements; adequate planning
and reasonable estimates for project completion; stakeholder acceptance of the
product vision and project plan; and acceptable expenditure level.
The evaluation criteria for the Construction phase (IOC) include: stability and
maturity of the product release (that is, is it ready to be deployed?); readiness of the
stakeholders for the transition; and acceptable expenditure level.
At the end of the Transition phase, we decide whether to release the product. We
base this primarily on the level of user satisfaction achieved during the Transition
phase. Often this milestone coincides with the initiation of another development
cycle to improve or enhance the product. In many cases, this new development cycle
may already be underway.
1 - 37
Iterations and Phases
Iterations and Phases

Inception
Elaboration
Construction
Preliminary Architect. Architect. Devel.

Iteration
Iteration Iteration Iteration
Devel.
Iteration
Transition
Devel. Transition Transition

Iteration Iteration Iteration
Minor Milestones: Releases
An iteration is a distinct sequence of activities based on

an established plan and evaluation criteria, resulting in an
executable release (internal or external).
38
Within each phase, there is a series of iterations. The number of iterations per phase
will vary. Each iteration results in an executable release encompassing larger and
larger subsets of the final application.
An internal release is kept within the development environment and (optionally)
demonstrated to the stakeholder community. We provide stakeholders (usually users)
with an external release for installation in their environment. External releases are
much more expensive because they require user documentation and technical
support because of this, they normally occur only during the Transition phase.
The end of an iteration marks a minor milestone. At this point, we assess technical
results and revise future plans as necessary.
1 - 38
Bringing It All Together: The Iterative Approach
Bringing It All Together: The Iterative Approach

In an
iteration,
you walk
through all
disciplines.
Disciplines
group
activities
logically.
39
This slide illustrates how phases and iterations (the time dimension) relate to the
development activities (the discipline dimension). The relative size of each color area
in the graph indicates how much of the activity is performed in each phase or
iteratino.
Each iteration involves activities from all disciplines. The relative amount of work
related to the disciplines changes between iterations. For instance, during late
Construction, the main work is related to Implementation and Test and very little
work on Requirements is done.
Note that requirements are not necessarily complete by the end of Elaboration. It is
acceptable to delay the analysis and design of well-understood portions of the system
until Construction because they are low in risk.
1 - 39
Disciplines Produce Models
Disciplines Produce Models
Business
Modeling
Disciplines
Requirements
Analysis &
Design
Implementation
Use-Case
Model
Realized By
Implemented
By
Models
Realized
By
Business UseCase Model

B
B
Business
Object Model

Automated
By
Design Model Implementation

Model
40
The RUP takes a model-driven approach. Several models are needed to fully describe
the evolving system. Each major discipline produces one of those models. The models
are developed incrementally across iterations.
The Business Model is a model of what the business processes are and of the
business environment. It can be used to generate requirements of supporting
information systems.
The Use-Case Model is a model of what the system is supposed to do and of the
system environment.
The Design Model is an object model describing the realization of use cases. It
serves as an abstraction of the implementation model and its source code.
The Implementation Model is a collection of components and the

implementation subsystems that contain them.
Test Suites are derived from many of these models.
1 - 40
Disciplines Guide Iterative Development
Disciplines Guide Iterative Development

Business
Modeling:
Workflow
Requirements:
Workflow
41
Within a discipline, workflows group activities that are done together. Discipline
workflows will be present in varying degrees, depending on the phase.
1 - 41
Overview of Rational Unified Process Concepts
Overview of Rational Unified Process Concepts

Divided into
Phase
Considers
Described by
Iteration
Workflow
Detail
Discipline
Participates in
References
Role
Activity
Responsible for
Document
Modifies
Model
Model
Element
Artifact
42
Basic Concepts in the RUP

A software lifecycle in the RUP is decomposed over time into four sequential phases,
each concluded by a major milestone. Each phase is essentially a span of time
between two major milestones.
An iteration is a pass through a sequence of process disciplines. Each iteration
concludes with the release of an executable product.
A discipline shows all the activities that you may go through to produce a particular
set of artifacts. We describe these disciplines at an overview level a summary of all
roles, activities, and artifacts that are involved.
A workflow detail is a grouping of activities that are done "together," presented with
input and resulting artifacts.
A role defines the behavior and responsibilities of an individual, or a set of individuals
working together as a team.
An activity is the smallest piece of work that is relevant.
Artifacts: These are the modeling constructs and documents that activities evolve,
maintain, or use as input.
Documents: These record system requirements, including usability, reliability,
performance, and supportability requirements.
Model: This is a simplified view of a system. It shows the essentials of the system
from a particular perspective and hides the non-essential details.
Model elements: These help the team visualize, construct, and document the
structure and behavior of the system, without getting lost in complexity.
1 - 42
Review
Review
Best Practices guide software engineering
by addressing root causes.
Best Practices reinforce each other.
Process guides a team on who does what,
when, and how.
The Rational Unified Process is a means of
achieving Best Practices.

43
1 - 43
1 - 44
Module 2
Concepts of Object Orientation

and Design with UML
Module 2: Concepts of Object Orientation
Topics
What Is Object Technology?................................................................................. 2-4
Basic Principles of Object Orientation................................................................. 2-15
Representing Classes in the UML ........................................................................ 2-24
Review............................................................................................................... 2-51
2-1
Objectives: Concepts of Object Orientation
Objectives: Concepts of Object Orientation

Explain the basic principles of object
orientation
Define the basic concepts and terms of
object orientation and the associated UML
notation
Demonstrate the strengths of object
orientation
Present some basic UML modeling notation

2-2
Module 2 - Concepts of Object Orientation
Best Practices Implementation
Best Practices Implementation

Object technology helps implement
these Best Practices.
Develop Iteratively: tolerates changing
requirements, integrates elements
progressively, facilitates reuse.
Use Component-Based Architectures:
architectural emphasis, componentbased development.
Model Visually: easy understanding,
easy modification.

Iterative development allows you to account for technological changes. If a

technology changes, becomes a standard, or new technology appears, the project
can take advantage of it. This is particularly true for platform changes or lowerlevel infrastructure changes.
Integration is not one "big bang" at the end. Elements are integrated progressively.
Actually, the iterative approach is almost continuous integration. Noniterative
integration takes up to 40% of the total effort at the end of a project and is hard
to plan accurately. What used to be a long, uncertain, and difficult process is
broken down into six-to-nine smaller integrations that start with far fewer
elements to integrate.
By clearly articulating the major components and the critical interfaces between
them, an architecture allows you to plan for reuse, both internally, (the
identification of common parts) and externally (the incorporation of off-the-shelf
components). On a larger scale, it also allows the reuse of the architecture itself
in the context of a line of products that addresses different functionality in a
common domain.
An object-oriented model aims at reflecting the world we experience in reality.
Thus, the objects themselves often correspond to phenomena in the real world
that the system is to handle. For example, an object can be an invoice in a
business system or an employee in a payroll system.
A model, correctly designed using object technology, is easy to understand and
modify. It clearly corresponds to reality, and changes in a particular phenomenon
concern only the object that represents that phenomenon.
2-3
What Is Object Technology?

What Is Object Technology?
Object technology
A set of principles guiding
software construction
together with languages,
databases, and other tools
that support those
principles. (Object
Technology: A Managers
Guide, Taylor, 1997)

2-4
Object technology is used for creating models that reflect a specific domain using
the terminology of the domain.
Models created using object technology are easy to create, change, expand,
validate, and verify.
Systems built using object technology are flexible to change, have well-defined
architectures, and allow reusable components to be created and implemented.
Models created using object technology are conveniently implemented in

software using object-oriented programming languages.
Object technology is not just a theory, but a well-proven technology used in a

large number of projects and for building many types of systems.
Successful implementation of object technology requires a method that integrates

a development process and a modeling language with suitable construction
techniques and tools. (UML Toolkit, Eriksson and Penker, 1997)
Strengths of Object Technology
Strengths of Object Technology

Provides a single paradigm
A single language used by users, analysts, designers,
and implementers
Facilitates architectural and code reuse

Models more closely reflect the real world
More accurately describes corporate entities
Decomposed based on natural partitioning
Easier to understand and maintain
Provides stability
A small change in requirements does not mean massive
changes in the system under development
Is adaptive to change
The UML represents a convergence of Best Practices throughout the objecttechnology industry. It provides a consistent language that can be applied to both
system and business engineering.
Object technology can help a company change its systems almost as fast as the
company itself changes.
2-5
What Is a Model?
What Is a Model?
A model is a simplification of reality.

According to Grady Booch, a model provides the blueprints of a system. It can

encompass detailed plans, as well as more general plans that give a 30,000-foot view
of the system under construction. A good model includes those elements that are not
relevant to the given level of abstraction. Every system can be described from
different aspects using different models, and each model is therefore a semantically
closed abstraction of the system. A model can be structural, emphasizing the
organization of the system, or it can be behavioral, emphasizing the dynamics of the
system.
2-6
Why Do We Model?
Why Do We Model?
We build models to better understand the system
we are developing.
Modeling achieves four aims. It:
Helps us to visualize a system as we want it to be.
Permits us to specify the structure or behavior of a
system.
Gives us a template that guides us in constructing a
system.
Documents the decisions we have made.
We build models of complex systems because we

cannot comprehend such a system in its entirety.

According to The Unified Modeling Language Use Guide (Booch, Rumbaugh, and
Jacobson, 1998), modeling achieves four aims:
Models help us to visualize a system as we want it to be. A model helps the

software team communicate the vision for the system being developed. It is very
difficult for a software team to have a unified vision of a system that is only
described in specification and requirement documents. Models bring about
understanding of the system.
Models permit us to specify the structure or behavior of a system. A model

allows us to document system behavior and structure before coding the system.
Models give us a template that guides us in constructing a system. A model is an

invaluable tool during construction. It serves as a road map for a developer. Have
you experienced a situation where a developer coded incorrect behavior
because there was confusion over the wording in a requirements document?
Modeling helps alleviate that situation.
Models document the decisions that have been made. Models are valuable tools
in the long term because they give hard information on design decisions. You
dont need to rely on someones memory.
2-7
What Is an Object?
What Is an Object?
Informally, an object represents an entity,
either physical, conceptual, or software.
Physical entity
Truck
Conceptual entity
Chemical Process
Software entity
Linked List

2-8
Objects allow the software developer to represent real-world concepts in the

software design. These real-world concepts can represent a physical entity such
as a person, truck, or space shuttle.
Objects can be concepts like a chemical process or algorithms.
Objects can even represent software entities like a linked list.
A More Formal Definition
A More Formal Definition

An object is an entity
with a well-defined
boundary and identity
that encapsulates state
and behavior.
Attributes
State is represented by
attributes and
relationships.
Behavior is represented
by operations, methods,
and state machines.
Object
Operations

An object is an entity that has a well-defined boundary. That is, the purpose of
the object should be clear.
An object has two key components: attributes and operations.
Attributes represent an objects state, and operations represent the behavior of

the object.
Object state and behavior are discussed on the next few slides.
2-9
An Object Has State
An Object Has State

The state of an object is one of the possible
conditions in which the object may exist.
The state of an object normally changes over
time.
Name: J Clark
Employee ID: 567138
HireDate: 07/25/1991
Status: Tenured
Discipline: Finance
MaxLoad: 3
Name: J Clark
Employee ID: 567138
Date Hired: July 25, 1991
Status: Tenured
Discipline: Finance
Maximum Course Load: 3 classes
2 - 10
Professor Clark
10
The state of an object is one of the possible conditions that an object may exist
in, and it normally changes over time.
The state of an object is usually implemented by a set of properties called

attributes, along with the values of the properties and the links the object may
have with other objects.
State is not defined by a state attribute or set of attributes. Instead, state is

defined by the total of an objects attributes and links. For example, if Professor
Clarks status changed from Tenured to Retired, the state of the Professor Clark
object would change.
An Object Has Behavior
An Object Has Behavior
Ac
ce
pt
C
ou
rs
eO
Su
bm
itF
in
al
G
ra
de
s(
Behavior determines how an object acts and

reacts.
The visible behavior of an object is modeled by
the set of messages it can respond to (operations
the object can perform).
Se
tM
ax
Lo
ad
()
Professor Clarks behavior

Submit Final Grades
Accept Course Offering
Take Sabbatical
Maximum Course Load: 3 classes
ffe
ri n
g(
TakeSabbatical()
Professor Clark
11
The second characteristic of an object is that it has behavior. Objects are

intended to mirror the concepts that they are modeled after, including behavior.
Behavior determines how an object acts and reacts to requests from other
objects.
Object behavior is represented by the operations that the object can perform.
For example, Professor Clark can choose to take a sabbatical once every five
years. The Professor Clark object represents this behavior through the
TakeSabbatical() operation.
2 - 11
An Object Has Identity
An Object Has Identity

Each object has a unique identity, even if
the state is identical to that of another
object.
Professor J Clark
teaches Biology

Professor J Clark
teaches Biology
12
In the real world, two people can share the same characteristics: name, birth date,
job description. Yet, there is no doubt that they are two individuals with their own
unique identities.
The same concept holds true for objects. Although two objects may share the same
state (attributes and relationships), they are separate, independent objects with their
own unique identity.
2 - 12
Representing Objects in the UML
Representing Objects in the UML

An object is represented as a rectangle
with an underlined name.
J Clark : Professor
Named Object
: Professor
Professor J Clark
Unnamed Object

13
An object is represented as a rectangle.
Within the rectangle, underlined, is the name of the class. To name an object,
add its name before the colon.
To keep an object unnamed (anonymous), do not include a name.
2 - 13
What Are Stereotypes?
What Are 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

14
A stereotype can be defined as:

An extension of the basic UML notation that allows you to define a new modeling
element based on an existing modeling element.
2 - 14
The new element may contain additional semantics but still applies in all cases
where the original element is used. In this way, the number of unique UML
symbols is reduced, simplifying the overall notation.
The name of a stereotype is shown in guillemets (<< >>).
A unique icon may be defined for the stereotype, and the new element may be
modeled using the defined icon or the original icon with the stereotype name
displayed, or both.
Stereotypes can be applied to all modeling elements, including classes,

relationships, components, and so on.
Each UML element can only have one stereotype.
Stereotype uses include modifying code generation behavior and using a

different or domain-specific icon or color where an extension is needed or
helpful to make a model more clear or useful.
Basic Principles of Object Orientation

Basic Principles of Object Orientation

Hierarchy
Modularity
Encapsulation
Abstraction
Object Orientation
15
There are four basic principles of object orientation. They are:
Abstraction
Encapsulation
Modularity
Hierarchy
2 - 15
What Is Abstraction?
What Is Abstraction?
The essential characteristics
of an entity that distinguish it
from all other kinds of entities
Defines a boundary relative to
the perspective of the viewer
Is not a concrete manifestation,
denotes the ideal essence of
something

16
Abstraction can be defined as:

Any model that includes the most important, essential, or distinguishing aspects of
something while suppressing or ignoring less important, immaterial, or diversionary
details. It is the result of removing distinctions so as to emphasize commonalties.
(Dictionary of Object Technology, Firesmith, Eykholt, 1995)
2 - 16
Abstraction allows us to manage complexity by concentrating on the essential

characteristics of an entity that distinguish it from all other kind of entities.
An abstraction is domain - and perspective - dependent. That is, what is

important in one context, may not be in another.
OO allows us to model our system using abstractions from the problem domain
(for example, classes and objects).
Example: Abstraction
Example: Abstraction
Student
Professor
Course Offering (9:00 AM,

Monday-Wednesday-Friday)
Course (e.g., Algebra)

17
The following are examples of abstraction.
A student is a person enrolled in classes at the university.
A professor is a person teaching classes at the university.
A course is a class offered by the university.
A course offering is a specific offering for a course, including days of the week
and times.
2 - 17
What Is Encapsulation?
What Is Encapsulation?
Hide implementation from clients.
Clients depend on interface.
Improves Resiliency
18
Encapsulation can be defined as:

The physical localization of features (for example, properties, behaviors) into a single
blackbox abstraction that hides their implementation (and associated design
decisions) behind a public interface. (Dictionary of Object Technology, Firesmith,
Eykholt, 1995)
2 - 18
Encapsulation is often referred to as information hiding, making it possible for

the clients to operate without knowing how the implementation fulfills the
interface.
Encapsulation eliminates direct dependencies on the implementation (clients

depend on/use the interface). Thus, it is possible to change the implementation
without updating the clients as long as the interface is unchanged.
Clients will not be affected by changes in implementation. This reduces the

ripple effect, which happens when a correction to one operation forces the
corresponding correction in a client operation and so on. As a result of
encapsulation, maintenance is easier and less expensive.
Encapsulation offers two kinds of protection. It protects an objects internal state

from being corrupted by its clients and client code from changes in the objects
implementation.
Encapsulation Illustrated
Encapsulation Illustrated
SetMaxLoad(4)
i tF
in
al
G
ra
de
s
()
Professor Clark
Su
bm
Professor Clark
needs to be able
to teach four
classes in the
next semester.
Se
tM
Ac
ce
pt
Co
ur
se
O
Name: J Clark
Employee ID: 567138
HireDate: 07/25/1991
Status: Tenured
Discipline: Finance
MaxLoad:4
ff e
ri n
g(
ax
Lo
ad
()
TakeSabbatical()

19
The key to encapsulation is an objects message interface. The object interface

ensures that all communication with the object takes place through a set of
predefined operations. Data inside the object is only accessible by the objects
operations. No other object can reach inside of the object and change its
attribute values.
For example, Professor Clark needs to have her maximum course load increased
from three classes to four classes per semester. Another object will make a
request to Professor Clark to set the maximum course load to four.The attribute,
MaxLoad, is then changed by the SetMaxLoad() operation.
Encapsulation is beneficial in this example because the requesting object does

not need to know how to change the maximum course load. In the future, the
number of variables that are used to define the maximum course load may be
increased, but that does not affect the requesting object. The requesting object
depends on the operation interface for the Professor Clark object.
2 - 19
What Is Modularity?
What Is Modularity?
Modularity is the breaking
up of something complex into
manageable pieces.
Modularity helps people to
understand complex systems.

20
Modularity can be defined as:

The logical and physical decomposition of things (for example, responsibilities and
software) into small, simple groupings (for example, requirements and classes,
respectively), which increase the achievements of software-engineering goals.
(Dictionary of Object Technology, Firesmith, Eykholt, 1995)
2 - 20
Another way to manage complexity is to break something that is large and

complex into a set of smaller, more manageable pieces. These pieces can then
be independently developed as long as their interactions are well understood.
Packages (described later in the course) support the definition of modular

components.
Example: Modularity
Example: Modularity
For example, break
complex systems into
smaller modules.
Billing
System
Course
Catalog
System
Course Registration
System

Student
Management
System
21
Often, the system under development is too complex to understand. To further

understanding, the system is broken into smaller blocks that are each maintained
independently. Breaking down a system in this way is called modularity. It is critical
for understanding a complex system.
For example, the system under development is a Course Registration system. The
system itself is too large and abstract to allow an understanding of the details.
Therefore, the development team broke this system into three modular systems, each
independent of the others.
The Billing System
Course Catalog System
Student Management System
2 - 21
What Is Hierarchy?
What Is Hierarchy?
Asset
Increasing
abstraction
BankAccount
Savings
Decreasing
abstraction
Security
Checking
Stock
RealEstate
Bond
Elements at the same level of the hierarchy

should be at the same level of abstraction.

22
Hierarchy can be defined as:

Any ranking or ordering of abstractions into a tree-like structure. Kinds: Aggregation
hierarchy, class hierarchy, containment hierarchy, inheritance hierarchy, partition
hierarchy, specialization hierarchy, type hierarchy. (Dictionary of Object Technology,
Firesmith, Eykholt, 1995)
2 - 22
Hierarchy organizes items in a particular order or rank (for example, complexity

and responsibility). This organization is dependent on perspective. Using a
hierarchy to describe differences or variations of a particular concept provides for
more descriptive and cohesive abstractions and a better allocation of
responsibility.
In any one system, there may be multiple abstraction hierarchies (for example, a
financial application may have different types of customers and accounts).
Hierarchy is not an organizational chart or a functional decomposition.
Hierarchy is a taxonomic organization. The use of hierarchy makes it easy to

recognize similarities and differences. For example, botany organizes plants into
families. Chemistry organizes elements in a periodic table.
What Is a Class?
What Is a Class?
A class is a description of a set of objects that
share the same attributes, operations,
relationships, and semantics.
An object is an instance of a class.
A class is an abstraction in that it

Emphasizes relevant characteristics.
Suppresses other characteristics.
Class
+ attribute
+ operation()

23
A class can be defined as:

A description of a set of objects that share the same attributes, operations,
relationships, and semantics. (The Unified Modeling Language User Guide, Booch,
1999)
There are many objects identified for any domain.
Recognizing the commonalties among the objects and defining classes helps us
deal with the potential complexity.
The OO principle of abstraction helps us deal with complexity.
2 - 23
Representing Classes in the UML

Representing Classes in the UML
A class is represented using a rectangle with
compartments.
Professor
- name
- employeeID : UniqueID
- hireDate
- status
- discipline
- maxLoad
+ submitFinalGrade()
+ acceptCourseOffering()
+ setMaxLoad()
+ takeSabbatical()

2 - 24
Professor J Clark
24
The UML notation for a class permits you to see an abstraction apart from any
specific programming language, which lets you emphasize the most important
parts about an abstraction its name, attributes, and operations.
Graphically, a class is represented by a rectangle.
The Relationship Between Classes and Objects
The Relationship Between Classes and Objects

A class is an abstract definition of an object.
It defines the structure and behavior of each object in
the class.
It serves as a template for creating objects.
Classes are not collections of objects.
Professor
Professor Torpie
Professor Meijer
Professor Allen
25
A class is a description of a set of objects that share the same responsibilities,

relationships, operations, attributes, and semantics.
An object is defined by a class. A class defines a template for the structure and
behavior of all its objects. The objects created from a class are also called the
instances of the class.
The class is the static description; the object is a run-time instance of that class.
Since we model from real-world objects, software objects are based on the realworld objects, but they exist only in the context of the system.
Starting with real-world objects, abstract out what you do not care about. Then,
take these abstractions and categorize, or classify them, based on what you do
care about. Classes in the model are the result of this classification process.
These classes are then used as templates within an executing software system to
create software objects. These software objects represent the real-world objects
we originally started with.
Some classes/objects may be defined that do not represent real-world objects.

They are there to support the design and are "software only.
2 - 25
What Is an Attribute?
What Is an Attribute?
An attribute is a named property of a class that
describes a range of values that instances of
the property may hold.
A class may have any number of attributes or no attributes at all.
Student
Attributes

- name
- address
- studentID
- dateOfBirth
26
An attribute can be defined as:

A named property of a class that describes the range of values that instances of the
property may hold. (The Unified Modeling Language User Guide, Booch, 1999)
2 - 26
A class may have any number of attributes or no attributes at all. At any time, an
object of a class will have specific values for every one of its class attributes.
An attribute defined by a class represents a named property of the class or its

objects. An attribute has a type that defines the type of its instances.
An attribute has a type, which tells us what kind of attribute it is. Typical
attributes are integer, Boolean, real, and enumeration. These are called primitive
types. Primitive types can be specific for a certain programming language.
What Is an Operation?
What Is an Operation?
An operation is the implementation of a service
that can be requested from any object of the
class to affect behavior.
A class may have any number of operations or
none at all.
Student
Operations
+ getTuition()
+ addSchedule()
+ getSchedule()
+ deleteSchedule()
+ hasPrerequisites()

27
An operation can be defined as:

The implementation of a service that can be requested from any object of the class to
affect behavior. (The Unified Modeling Language User Guide, Booch, 1999)
The operations in a class describe what the class can do.
An operation can be either a command or a question. Only a command can

change the state of the object; a question should never change it.
An operation is described with a return-type, name, and zero or more

parameters. Together, the return-type, name, and parameters are called the
signature of the operation.
The outcome of the operation depends on the current state of the object. Often,
but not always, invoking an operation on an object changes the objects data or
state.
2 - 27
What Is Polymorphism?
What Is Polymorphism?
The ability to hide many different
implementations behind a single interface
Manufacturer A
Manufacturer B
Manufacturer C
OO Principle:
Encapsulation
28
The Greek term polymorphos means having many forms. There may be one or
many implementations of a given interface. Every implementation of an interface
must fulfill the requirements of that interface. In some cases, the implementation can
perform more than the basic interface requirements.
For example, the same remote can be used to control any type of television
(implementation) that supports the specific interface that the remote was designed to
be used with.
2 - 28
Example: Polymorphism
Example: Polymorphism
financialInstrument.getCurrentValue()
ge
tC
urr
en
tVa
lue
()
Stock

ge
tCu
rre
ntV
a
lue
()
Bond
ge
tCu
rre
ntV
a
lue
()
Mutual Fund
29
In this example, a requesting object would like to know the current value of a
financial instrument. However, the current value for each financial instrument is
calculated in a different fashion. The stock needs to determine the current asking
price in the financial market that it is listed under. The bond needs to determine the
time to maturity and interest rates. A mutual fund needs to look up the closing price
for the day from the fund management company.
In a non object-oriented development environment, we would write code that may
look something like this:
IF financialInstrument = Stock THEN
calcStockValue()
IF financialInstrument = Bond THEN
calcBondValue()
IF financialInstrument = MutualFund THEN
calcMutualFundValue()
With object technology, each financial instrument can be represented by a class, and
each class will know how to calculate its own value. The requesting object simply
needs to ask the specific object (for example, Stock) to get its current value. The
requesting object does not need to keep track of three different operation signatures.
It only needs to know one. Polymorphism allows the same message to be handled in
different ways, depending on the object that receives it.
2 - 29
What Is an Interface?
What Is an Interface?
Interfaces formalize polymorphism
Interfaces support plug-and-play architectures
Tube
<<interface>>
Shape
Pyramid
+ draw()
+ move()
+ scale()
+ rotate()
Cube
Realization relationship
(stay tuned for realization relationships)
30
From the UML Users Guide (Booch, 1999): An interface is a collection of operations
that are used to specify a service of a class or a component.
Interfaces formalize polymorphism. They allow us to define polymorphism in a
declarative way, unrelated to implementation. Two elements are polymorphic with
respect to a set of behaviors if they realize the same interfaces. In other words, if two
objects use the same behaviors to get different, but similar results, they are
considered to be polymorphic. A cube and a pyramid can both be drawn, moved,
scaled, and rotated, but they look very different.
You have probably heard that polymorphism is one of the big benefits of object
orientation, but without interfaces there is no way to enforce it, verify it, or even
express it except in informal or language-specific ways. Formalization of interfaces
strips away the mystery of polymorphism and gives us a good way to describe, in
precise terms, what polymorphism is all about. Interfaces are testable, verifiable, and
precise.
Interfaces are the key to the plug-and-play ability of an architecture: Any classifiers
(for example, classes, subsystems, components) that realize the same interfaces may
be substituted for one another in the system, thereby supporting the changing of
implementations without affecting clients.
Realization relationships are discussed later in this module.
2 - 30
How Do You Represent an Interface?
How Do You Represent an Interface?

Tube
Elided/Iconic
Representation
(lollipop)
Pyramid
Shape
Cube
Canonical
(Class/Stereotype)
Representation
<<interface>>
Tube
Shape
Pyramid
+ draw()
+ move()
+ scale()
+ rotate()

Cube
31
The lollipop notation is best used when you only need to denote the existence of an
interface. If you need to see the details of the interface (for example, the operations),
then the class/stereotype representation is more appropriate.
From The Random House Collegiate Dictionary:
Elide: to pass over; omit; ignore.
Canonical: authorized; recognized; accepted.
2 - 31
What Is a Package?
What Is a Package?
A package is a general-purpose mechanism for
organizing elements into groups.
It is a model element that can contain other
model elements.
UniversityArtifacts
A package can be used:

To organize the model under development.
As a unit of configuration management.
32
A package can be defined as:

A general purpose mechanism for organizing elements into groups. (The Unified
Modeling Language User Guide, Booch, 1999)
2 - 32
Models can contain hundreds and even thousands of model elements. The sheer
number of these elements can quickly become overwhelming. Therefore, it is
critical to group model elements into logical collections to maintain and easily
read the model (application of modularity and hierarchy).
Packages are a general grouping mechanism for grouping elements into

semantically related groups. A package contains classes that are needed by a
number of different packages, but are treated as a behavioral unit.
A package is simply a grouping mechanism. No semantics are defined for its

instances. Thus, packages do not necessarily have a representation in
implementation, except, maybe, to represent a directory.
In the UML, a package is represented as a tabbed folder.
What Is a Subsystem?
What Is a Subsystem?
A combination of a package (can contain other
model elements) and a class (has behavior)
Realizes one or more interfaces which define
its behavior
Subsystem
Realization
Interface
<<subsystem>>
SubsystemName
Interface1
OO Principles: Encapsulation and Modularity

(stay tuned for realization relationships)
33
A subsystem is a model element that has the semantics of a package, such that it can
contain other model elements, and a class, such that it has behavior. (The behavior of
the subsystem is provided by classes or other subsystems it contains.) A subsystem
realizes one or more interfaces, which define the behavior it can perform.
From the UML Users Guide (Booch, 1999): A subsystem is a grouping of elements of
which some constitute a specification of the behavior offered by the other contained
elements.
A subsystem may be represented as a stereotyped package.
The realization relationship will be discussed later in this module.
2 - 33
What Is a Component?
What Is a Component?
A non-trivial, nearly independent, and
replaceable part of a system that fulfills
a clear function in the context of a welldefined architecture
A component may be
A source code component
A run time component
Source File
Name
<<DLL>>
Component
Interface
An executable component
Component
Name
<<EXE>>
Executable
Name
OO Principle: Encapsulation
34
From the UML Users Guide (Booch, 1999): A component is a physical and
replaceable part of a system that conforms to and provides the realization of a set of
interfaces.
Software components include:
Source code components (for example, .h, .cpp files, shell scripts, data files),
Binary code components. Examples include: Java Beans, ActiveX controls, COM
objects (DLL's and OCX's from VB), CORBA objects), and
Executable components (.exes).
Stereotypes (with alternate icons) may be used to define these specific kinds of
components.
Component-based development is the creation and deployment of software-intensive
systems assembled from components. Component software development should not
be confused with object-oriented programming (OOP). OOP is a way to build
object-based software components. Component-based development (CBD) is a
technology that allows you to combine object-based components. OOP is concerned
with creating objects, CBD is concerned with making objects work together.
A component conforms to and provides the physical realization of a set of interfaces.
Components are implementation things. They are the physical realization of an
abstraction in your design. Interfaces were discussed earlier in this module.
2 - 34
Subsystems and Components
Subsystems and Components

Components are the physical realization of
an abstraction in the design
Subsystems can be used to represent the
component in the design
Design Model
Implementation Model
<<subsystem>>
Component Name
Component
Interface
Component
Interface
Component
Name
OO Principles: Encapsulation and Modularity

35
A component conforms to and provides the physical realization of a set of interfaces.

Components are implementation things. They are the physical realization of an
abstraction in your design. A subsystem can be used to represent the component in
the design.
A subsystem is the design representation of a component. They both encapsulate a
set of replaceable behaviors behind one or more interfaces. Subsystems and
interfaces will be discussed later in the course.
2 - 35
Components UML 1.4 and Beyond
Components UML 1.4 and Beyond

UML 1.4 introduces concept of Artifacts:
An Artifact represents a physical piece of
information that is used or produced by a
software development process. Examples of
Artifacts include models, source files, scripts,
and binary executable files.
To distinguish between artifacts in general,

and the artifacts that make up the
implementation, we introduce a new term:
Implementation Element - the physical parts
(UML artifacts) that make up an
implementation, including software code files
(source, binary or executable), and data files.
2 - 36
36
Components UML 1.4 and Beyond (cont.)
Components UML 1.4 and Beyond (cont.)

Component becomes similar to subsystem:
can group classes to define a larger granularity
units of a system
can separate the visible interfaces from internal
implementation
can have instances that execute at run-time
The distinction between "component" and

"artifact" is new in UML 1.4.
Many tools, profiles, and examples continue to
use "component" to represent implementation
elements.
37
2 - 37
What Is an Association?
What Is an Association?
The semantic relationship between two or
more classifiers that specifies connections
among their instances
A structural relationship, specifying that objects of one
thing are connected to objects of another
<<Entity>>
<<Entity>>
<<Entity>>
Student
Schedule
Course

38
An association can be defined as:

The semantic relationship between two or more classifiers that specifies connections
among their instances. In other words, an association is a structural relationship that
specifies that objects (instances of classes) are connected to other objects.
2 - 38
The way that we show relationships between classes is through the use of
associations. Associations are represented on class diagrams by a line connecting
the associating classes. Data may flow in either direction or in both directions
across a link.
Most associations are simple. That is, they exist between exactly two classes.
They are drawn as solid paths connecting pairs of class symbols. Ternary
relationships are also possible.
Sometimes, a class has an association to itself. This does not always mean that an
instance of that class has an association to itself. More often, it means that one
instance of the class has associations to other instances of the same class.
This example shows that a student object is related to a schedule object. The
course class demonstrates how a course object can be related to another course
object.
What Is Multiplicity?
What Is Multiplicity?
Multiplicity is the number of instances 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>>
Professor
<<Entity>>
+ instructor
CourseOffering
0..1

0..*
39
Multiplicity can be defined as:

The number of instances of one class that relate to one instance of another class.
For each role, you can specify the multiplicity of its class and how many objects
of the class can be associated with one object of the other class.
Multiplicity is indicated by a text expression on the role. The expression is a

comma-separated list of integer ranges.
It is important to remember that multiplicity is referring to instances of classes

(objects) and their relationships. In this example, a Course Offering object can
have either zero or one Professor object related to it. Conversely, a Professor
object can have zero or more Course Offering objects related to it.
Multiplicity must be defined on both ends of the association.
2 - 39
Multiplicity Indicators
Multiplicity Indicators
Unspecified
Exactly One
Zero or More
0..*
Zero or More
One or More
1..*
Zero or One (optional scalar role)
0..1
Specified Range
2..4
Multiple, Disjoint Ranges

2 - 40
2, 4..6
40
Multiplicity is indicated by a text expression on the role.
The expression is a comma-separated list of integer ranges.
A range is indicated by an integer (the lower value), two dots, followed by

another integer (the upper value).
A single integer is a valid range, and the symbol * indicates "many. That is, an
asterisk * indicates an unlimited number of objects.
The symbol * by itself is equivalent to 0..* That is, it represents any number,
including none. This is the default value.
An optional scalar role has the multiplicity 0..1.
What Is Aggregation?
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 an Is a part-of relationship.
Multiplicity is represented like other

associations.
Whole
Part
1

0..1
41
An aggregation can be defined as:

A special form of association that models a whole-part relationship between an
aggregate (the whole) and its parts.
Aggregation is used to model relationships between model elements. There are

many examples of aggregation: a library contains books, departments are made
up of employees, a computer is composed of a number of devices. To model an
aggregation, the aggregate (department) has an aggregation association to the its
constituent parts (employee).
A hollow diamond is attached to the end of an association path on the side of the
aggregate (the whole) to indicate aggregation.
An aggregation relationship that has a multiplicity greater than one for the
aggregate is called shared. Destroying the aggregate does not necessarily destroy
the parts. By implication, a shared aggregation forms a graph or a tree with many
roots. Shared aggregations are used where there is a strong relationship between
two classes. Therefore, the same instance can participate in two different
aggregations.
2 - 41
What Is Navigability?
What Is Navigability?
Indicates that it is possible to navigate from a
associating class to the target class using the
association
<<Control>>
RegistrationController
<<Entity>>
<<Entity>>
Schedule
CourseOffering

2 - 42
42
The navigability property on a role indicates that it is possible to navigate from a

associating class to the target class using the association. This may be
implemented in a number of ways: by direct object references, associative arrays,
hash-tables, or any other implementation technique that allows one object to
reference another.
Navigability is indicated by an open arrow placed on the target end of the

association line next to the target class (the one being navigated to). The default
value of the navigability property is true (associations are bi-directional by
default).
In the course registration example, the association between the Schedule and the
Course Offering is navigable in both directions. That is, a Schedule must know
the Course Offering assigned to the Schedule, and the Course Offering must
know the Schedules it has been placed in.
When no arrowheads are shown, the association is assumed to be navigable in

both directions.
In the case of the association between Schedule and Registration Controller, the
Registration Controller must know its Schedules, but the Schedules have no
knowledge of the Registration Controllers (or other classes). As a result, the
navigability property of the Registration Controller end of the association is
turned off.
Relationships: Dependency
Relationships: Dependency
A relationship between two model elements
where a change in one may cause a change in
the other
Non-structural, using relationship
Dependency
relationship
Client
Class
Supplier
Dependency
relationship
Component
Client
Supplier
Dependency
relationship
Package
ClientPackage

SupplierPackage
43
A dependency relationship is a weaker form of relationship showing a relationship

between a client and a supplier where the client does not have semantic knowledge
of the supplier.
A dependency relationship denotes a semantic relationship between model elements,
where a change in the supplier may cause a change in the client.
2 - 43
What Is Generalization?
What Is Generalization?
A relationship among classes where one
class shares the structure and/or behavior
of one or more classes
Defines a hierarchy of abstractions in which
a subclass inherits from one or more
superclasses
Single inheritance
Multiple inheritance
Is an is a kind of relationship

44
Generalization can be defined as:

A specialization/generalization relationship in which objects of the specialized
element (the child) are substitutable for objects of the generalized element (the
parent). (The Unified Modeling Language User Guide, Booch, 1999)
The subclass may be used where the superclass is used, but not vice versa.
The child inherits from the parent.
Generalization is transitive. You can always test your generalization by applying
the is a kind of rule. You should always be able to say that your specialized
class is a kind of the parent class.
The terms generalization and inheritance are generally interchangeable. If
you need to distinguish, generalization is the name of the relationship, while
inheritance is the mechanism that the generalization relationship
represents/models.
Inheritance can be defined as:
The mechanism by which more-specific elements incorporate the structure and
behavior of more-general elements. (The Unified Modeling Language User Guide, Booch,
1999)
2 - 44
Single inheritance: The subclass inherits from only one superclass (has only one
parent).
Multiple inheritance: The subclass inherits from more than one superclass (has
multiple parents).
Example: Single Inheritance
Example: Single Inheritance

One class inherits from another
Account
- balance
- name
- number
Superclass
(Parent)
(Ancestor)
+ withdraw()
+ createStatement()
Savings
Generalization
Relationship
Checking
Subclass
(Child)
(Descendents)
45
The generalization is drawn from the subclass class to the superclass/parent class.
The terms ancestor and descendent can be used instead of superclass and
subclass.
2 - 45
Example: Multiple Inheritance
Example: Multiple Inheritance

A class can inherit from several other classes.
FlyingThing
Animal
Multiple Inheritance
Airplane
Helicopter
Bird
Wolf
Horse
Use multiple inheritance only when needed and

always with caution!
2 - 46
46
Multiple inheritance means that a class can inherit from several other classes.
For example, Bird inherits from both FlyingThing and Animal.
Multiple inheritance is conceptually straight forward and may be needed to

model the real world accurately. However, there are potential implementation
problems when you use multiple inheritance, and not all implementation
languages support it. Thus, be judicious with your use of multiple inheritance.
Use it only where it accurately describes the concept you are trying to model and
reduces the complexity of your model. Be aware, however, that this
representation will probably need to be adjusted in design and implementation.
Generally, a class inherits from only one class.
What Gets Inherited?
What Gets Inherited?

A subclass inherits its parents attributes,
operations, and relationships
A subclass may:
Add additional attributes, operations,
relationships
Redefine inherited operations (use caution!)
Common attributes, operations, and/or

relationships are shown at the highest
applicable level in the hierarchy
Inheritance leverages the similarities among classes
47
Generalization is much more than just finding common attribute, operations, and
relationships. It should be more about the responsibilities and essence of the classes.
2 - 47
Example: What Gets Inherited
Example: What Gets Inherited
+ owner
GroundVehicle
Superclass
(Parent)
0..*
Person
generalization
Car
Truck
Trailer
Subclass
(Child)

48
In the above example, a truck is defined as a vehicle with tonnage and a car is a
vehicle with a size (for example, compact or mid-size).
Specifically, attributes:
A GroundVehicle has two attributes: weight and licenseNumber
A Car has three attributes: licenseNumber, weight, and size
A Truck has three attributes: licenseNumber, weight, and tonnage
Operations:
A GroundVehicle has one operation: register()
A Car has one operation: register()
A Truck has two operations: register() and getTax()
Relationships:
2 - 48
A Car is related to a Person (the owner)
A Truck is related to a Person (the owner)
A Truck also has a Trailer and is related to a Person (the owner)
What Is Realization?
What Is Realization?
One classifier serves as the contract that the other
classifier agrees to carry out, found between:
Interfaces and the classifiers that realize them
Component
Interface
Class
Interface
<<subsystem>>
Interface
Subsystem
Use cases and the collaborations that realize them

Collaboration

UseCase
49
Realization is a semantic relationship between two classifiers. One classifier serves as

the contract that the other classifier agrees to carry out.
The realizes relationship is a combination of a dependency and a generalization. It is
not true generalization, as only the contract (that is to say, operation signature) is
inherited. This mix is represented in its UML form, which is a combination of
dependency and generalization.
The realizes relationship may be modeled as a dashed line with a hollow arrowhead
pointing at the contract classifier (canonical form), or when combined with an
interface, as a lollipop (elided form).
Again, from The Random House Collegiate Dictionary:
Elide: to pass over; omit; ignore.
Canonical: authorized; recognized; accepted.
2 - 49
What Are Notes?
What Are Notes?

A comment that can be added to include more
information on the diagram
May be added to any UML element
A dog eared rectangle
May be anchored to an element with a dashed
line
There can be up to one
MaintainScheduleForm
per user session.
MaintainScheduleForm

2 - 50
50
Review
Review: Concepts of Object Orientation
What are the four basic principles of object
orientation? Provide a brief description of
each.
What is an object and what is a class?
What is the difference between the two?
What is an attribute?
What is an operation?
What is polymorphism? What
is an interface?

51
2 - 51
Review: Concepts of Object Orientation (cont.)
Review: Concepts of Object Orientation (cont.)

What is a package?
What is a subsystem? How does it relate to
a package? How does it relate to a class?
Name the four basic UML relationships and
describe each.
Describe the strengths of object orientation
What are stereotypes?

2 - 52
52
Module 3
Requirements Overview

and Design with UML
Module 3: Requirements Overview
Topics
Introduction ......................................................................................................... 3-3
Key Concepts ....................................................................................................... 3-7
Use-Case Model................................................................................................. 3-10
Glossary ............................................................................................................. 3-19
Supplementary Specifications ............................................................................. 3-22
Review............................................................................................................... 3-31
3-1
Objectives: Requirements Overview
Objectives: Requirements Overview

Describe the basic Requirements concepts
and how they affect Analysis and Design
Demonstrate how to read and interpret the
artifacts of Requirements that are used as a
starting point for Analysis and Design

This Requirements Overview module provides an overview of the activities that

immediately precede Analysis and Design. It is meant to describe the interface
between the Requirements and the Analysis and Design discipline.
This Requirements Overview module will provide enough information to give you an
appreciation for the Requirements discipline, and enable you to read and interpret
the Requirements artifacts that serve as the starting point for the Analysis and Design
activities.
3-2
Module 3 - Requirements Overview
Introduction
Requirements Overview Topics
Introduction
Key Concepts
Use-Case Model
Glossary
Supplementary Specifications
Checkpoints

We will start with an introduction to the Requirements discipline, followed by a

review of the key concepts in use-case modeling. Then we will look briefly at each of
the Requirements artifacts and discuss how to read and interpret their contents. We
will close by reviewing a series of checklists that will assist you in assessing the quality
and completeness of the Requirements artifacts.
3-3
Requirements in Context
Requirements in Context
The purpose of Requirements is to:
Establish and maintain agreement

with the customers and other
stakeholders on what the system
should do.
Give system developers a better

understanding of the requirements
of the system.
Delimit the system.
Provide a basis for planning the

technical contents of the iterations.
Provide a basis for estimating cost

and time to develop the system.
Define a user interface of the

system.

The Business Modeling discipline provides organizational context for the system. This
is the context in which the requirements are defined and analyzed.
The purpose of the Requirements discipline is:
To establish and maintain agreement with the customers and other stakeholders
on what the system should do.
To provide system developers with a better understanding of the system

requirements.
To define the boundaries of (delimit) the system.
To provide a basis for planning the technical contents of iterations.
To provide a basis for estimating cost and time to develop the system.
To define a user-interface for the system, focusing on the needs and goals of the
users.
The Analysis and Design discipline gets its primary input (the Use-Case Model and
the Glossary) from Requirements. Flaws in the Use-Case Model can be discovered
during Analysis and Design; change requests are then generated, and applied to the
Use-Case Model.
3-4
Relevant Requirements Artifacts
Relevant Requirements Artifacts

Use-Case Model
Glossary
Actors
Use Cases
...
Supplementary
Specification
Use-Case Specifications
The Use-Case Model describes what the system will do. The Use-Case Model serves
as a contract between the customer, the users, and the system developers. It allows
customers and users to validate that the system will become what they expected and
allows system developers to ensure that what they build is what is expected. The UseCase Model consists of use cases and actors. Each use case in the model is described
in detail, showing step-by-step how the system interacts with the actors and what the
system does in the use case. The Use-Case Specification is the document where all of
the use-case properties are documented (for example, brief description and use-case
flows of events).
Note: The OOAD course requirements documentation includes Use-Case
Specifications because it is the textual description that will drive Analysis and Design
activities. (Use-case specifications only include the textual use-case properties.)
The Glossary defines a common terminology for all models and contains textual
descriptions of the required system.
The Supplementary Specification contains those requirements that do not map to a
specific use case (for example, nonfunctional requirements). The Supplementary
Specification is an important complement to the Use-Case Model. Together they
capture all requirements (functional and nonfunctional) that need to be described for
a complete System Requirements Specification.
3-5
Case Study: Course Registration Problem Statement
Case Study: Course Registration Problem Statement

Review the problem statement provided in
the Course Registration Requirements
Document.
Course Registration
Requirements Document

Before we discuss the details of the artifacts that drive the Analysis and Design
discipline, it is important that you understand the problem domain that all of the
course exercises will be based on.
With regards to the formal Requirements artifacts, the Problem Statement is part of
the Vision document. The other sections have been omitted for scoping reasons. For
more information on the Vision document, see the Requirements discipline of the
Rational Unified Process.
3-6
Key Concepts
Introduction
Key Concepts
Use-Case Model
Glossary
Checkpoints

In this section, we will discuss the key concepts of use-case modeling the actor
and the use case, as well as what relationships can exist between them. We will also
look at the artifacts that make up the Use-Case Model: Use-Case Specifications, and
activity diagrams.
3-7
What Is System Behavior?
What Is System Behavior?

System behavior is how a system acts and
reacts.
It is the 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.

3-8
No system exists in isolation. Every system interacts with people or automated

systems for some purpose. These interactions result in some sort of predictable
result. This predictable result is system behavior.
Use cases are the mechanism for capturing the desired behavior for the system
that is under development, but they do not specify how the behavior is to be
implemented.
The UML specifies a model for communicating system behavior the Use-Case
Model.
Major Concepts in Use-Case Modeling
Major Concepts in Use-Case Modeling

An actor represents anything that interacts with
the system.
Actor
A use case is a sequence of actions a system

performs that yields an observable result of
value to a particular actor.
UseCase
An actor represents a coherent set of roles that users of the system play when
interacting with these use cases. Typically, an actor represents a role that a human, a
hardware device, or even another system plays with a system.
A use case is a sequence of actions a system performs to yield an observable result
that is of value to a particular actor. A use case describes what a system does, but it
does not specify how it does it.
3-9
Use-Case Model
Introduction
Key Concepts
Use-Case Model
Glossary
Checkpoints

3 - 10
10
What Is a Use-Case Model?
What Is a Use-Case Model?

A model that describes a systems functional
requirements in terms of use cases
A model of the systems intended functionality
(use cases) and its environment (actors)
View Report Card
Register for Courses

Student
Login

11
A Use-Case Model describes a systems functional requirements in terms of use

cases. It is a model of the system's intended functionality and its environment.
The Use-Case Model serves as a contract between the customer and the
developers. Because it is a very powerful planning instrument, the Use-Case
Model is generally used in all phases of the development cycle.
When the customer approves the Use-Case Model, you know the system is what
the customer wants. You can also use the model to discuss the system with the
customer during development.
Potential users use the Use-Case Model to better understand the system.
Designers use it as a basis for their work and to get a system overview.
Testers use it to plan testing activities (use case and integration testing) as early as
possible.
Those developing the next version of the system use it to understand how the
existing version works.
Documentation writers use the use cases as a basis for writing the system user
guides.
The architect uses the Use-Case Model to identify architecturally significant

functionality.
The manager uses it to plan and follow up on use-case modeling and subsequent
design.
3 - 11
What Are the Benefits of a Use-Case Model?
What Are the Benefits of a Use-Case Model?

Communication
Identification
Verification
Communication
Use Case
Verification
Identification
End User
Users
Domain Expert

12
There are many ways to model a system, each of which may serve a different
purpose. However, the most important role of a Use-Case Model is to communicate
the system's behavior to the customer or end user. Consequently, the model must be
easy to understand.
Communication with the end users and domain experts:
Provides buy-in at an early stage of system development.
Ensures a mutual understanding of the requirements.
Identification of system users and what the system should do:
Establishes the requirements for the system interfaces.
Verification that all requirements have been captured:
Ensures that the development team understands the requirements.
The Use-Case Model is also used to identify the actors that interact with the system.
Because they represent system users, actors help delimit the system and give a clearer
picture of what it is supposed to do. Use cases are developed on the basis of the
actors' needs, ensuring that the system will turn out to be what the users expected.
3 - 12
How Would You Read This Diagram?
How Would You Read This Diagram?

View Report Card
Course Catalog
Maintain Professor
Information
Student
Maintain Student
Information
Login
Registrar
Select Courses to
Teach
Close Registration
Professor
Submit Grades
Billing System

13
Answer the following questions:

1. Which use cases will a student be able to perform? A professor? The Course
Catalog?
2. If Charlie is a student and professor, which use cases will he be able to execute?
3. Describe the functionality of this system.
4. Describe the actor relationships for the Close Registration and Select Courses To
Teach use cases.
5. What doesnt this model say?
6. Which use case needs to run first Register for Courses or View Report Card?
3 - 13
Name
Brief description
Flow of Events
Relationships
Activity diagrams
Use-Case diagrams
Special
requirements
Pre-conditions
Post-conditions
Other diagrams

Use-Case Model
Actors
Use Cases
...
14
The use case has a set of properties as shown in the graphic. The use-case properties
may be documented in use-case specifications, which can include the items listed
below:
3 - 14
Brief description describes the role and purpose of the use case.
Flow of events are textual descriptions of what the system does with regard to
the use case. There can be multiple flows of events for example, a basic flow
and alternative flows.
Relationships are communicates-associations. The use case includes and extends

relationships that the use case participates in.
Activity diagrams can be used to illustrate the structure of the flow of events.
Use-case diagrams can be used to show the relationships involving the use case.
Special requirements is a textual description that collects all use-case

requirements, like nonfunctional requirements, that are not considered in the
Use-Case Model, yet need to be taken care of during design or implementation.
Pre-conditions define a constraint on the system regarding when the use case
may start.
Post-conditions define a constraint on the system that applies after the use case
has terminated.
Other diagrams can be used to illustrate the use case, like hand-drawn sketches
or screen captures from an user-interface prototype.
Use-Case Flow of Events
Use-Case Flow of Events

Has one normal, basic flow
Several alternative flows
Regular variants
Odd cases
Exceptional flows for handling error situations

15
A use case flow of events:
Contains the most important information derived from use-case modeling work.
Should describe the use case's flow clearly enough for an outsider to easily
understand it.
Should present what the system does, not how the system is designed to perform
the required behavior.
Guidelines for the flow of events. Specify that the content must:
Detail the flow of events. All "what questions should be answered. Remember
that test designers will use this text to identify test cases.
Describe how the use case starts and ends.
Describe the flow of events, not only the functionality. To reinforce this, start
every action with "When the actor. . . .
Describe only the events that belong to the use case and not what happens in
other use cases or outside of the system.
Describe the data exchanged between the actor and the use case.
Avoid describing the details of the user interface unless they are needed to
provide an understanding the behavior of the system.
Avoid vague terminology such as "for example", "etc.," and "information."
3 - 15
What Is a Scenario?
What Is a Scenario?
A scenario is an instance of a use case.

16
A scenario is an instance of a use case. It is one flow through a use case.

Each use case has a web of flow of events with a scenario being an instance of a
particular flow of events. The scenario may involve the basic flow and any number of
alternative flows in any number of combinations.
In the example, the bold lines highlight some possible scenarios for the basic and
alternative flows previously described.
How many scenarios are needed?
As many as one needs to understand the system being developed. You must
elaborate the scenarios of the interesting and high-risk use cases. Scenarios can be
used to understand, as well as to validate, the use-case flows of events. Some people
write scenarios first and extract use cases, while others find use cases first and validate
those use cases by writing scenarios.
Scenarios make excellent test cases.
3 - 16
What Is an Activity Diagram?
What Is an Activity Diagram?

An activity diagram in the Use-Case Model can be used to
capture the activities in a use case.
It is essentially a flow chart, showing flow of control from
activity to activity.
Flow of Events
This use case starts when the Registrar requests that the
system close registration.
Activity2
1. The system checks to see if registration is in progress. If it

is, then a message is displayed to the Registrar and the use
case terminates. The Close Registration processing cannot
be performed if registration is in progress.
Activity1
2. For each course offering, the system checks if a professor

has signed up to teach the course offering and at least three
students have registered. If so, the system commits the
course offering for each schedule that contains it.

Activity3
17
The workflow of a use case describes what needs to be done by the system to
provide the value that the served actor is looking for.
It consists of a sequence of activities that, together, produce something for the

actor.
The workflow often consists of a basic flow and one or several alternative flows.
The structure of the workflow can be described graphically with the help of an
activity diagram.
3 - 17
Example: Activity Diagram
Example: Activity Diagram

Decision
Select Course
Concurrent
Threads
[ delete course ]
Activity
State
Delete Course
[ add course ]
Synchronization
Bar (Fork)
Guard
Condition
Check
Schedule
[ checks completed ]
Assign to
Course
Check
Pre-requisites
[ checks failed ]
Resolve
Conflicts
Synchronization
Bar (Join)
Transition
Update
Schedule

18
An activity diagram may include the following elements:
3 - 18
Activity states represent the performance of an activity or step within the

workflow.
Transitions show what activity state follows after another.
Decisions evaluate conditions defined by guard conditions. These guard

conditions determine which of the alternative transitions will be made and, thus,
which activities are performed. You may also use the decision icon to show
where the threads merge again. Decisions and guard conditions allow you to
show alternative threads in the workflow of a use case.
Synchronization bars show parallel sub-flows. They allow you to show

concurrent threads in the workflow of a use case.
Glossary
Introduction
Key Concepts
Use-Case Model
Glossary
Checkpoints

19
3 - 19
Glossary
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
Glossary
Course: A class offered by the university.
2.2
Course Offering: A specific delivery of the course for a specific
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.

20
The Glossary defines important terms used in the project.

There is one Glossary for the system. This document is important to many developers,
especially when they need to understand and use the terms that are specific to the
project. The Glossary is used to facilitate communications between domain experts
and developers.
The Glossary is developed primarily during the Inception and Elaboration phases,
because it is important to agree on a common terminology early in the project. In
Inception and Elaboration, it is used by domain experts (for example, business
analysts) to explain all the domain-specific terminology used in their use cases. In
Elaboration and Construction, developers use the Glossary to explain technical terms
used in the other four models.
A system analyst is responsible for the integrity of the Glossary, ensuring that it is
produced in a timely manner and is continuously kept consistent with the results of
development.
The above is just a sample outline for the Glossary. Not all of these elements need to
be in it. A project needs to establish the template to be used on that particular
project.
Introduction: Provides a brief description of the Glossary and its purpose.
Terms: Define the term in as much detail as necessary to completely and
unambiguously characterize it.
3 - 20
Case Study: Glossary
Case Study: Glossary

Review the Glossary
provided in the Course
Registration
Requirements Document
Glossary

21
The idea is not to go over the Glossary in vivid detail, but to demonstrate how to read
it, where to look for information you will need during the Analysis and Design
activities, as well as how to detect if it is insufficient.
3 - 21
Introduction
Key Concepts
Use-Case Model
Glossary
Checkpoints

3 - 22
22
Supplementary Specification
Supplementary Specification
Functionality
Usability
Reliability
Performance
Supportability
Design constraints

Supplementary
Specification
23
The nonfunctional requirements and functional requirements not captured by the use
cases are included in the Supplementary Specifications. The Supplementary
Specifications include constraints on the implementation.
Functionality: List of the functional requirements that are general to many use cases.
Usability: Requirements that relate to, or affect, the usability of the system. Examples
include ease-of-use requirements or training requirements that specify how readily
the system can be used by its actors.
Reliability: Any requirements concerning the reliability of the system. Quantitative
measures such as mean time between failure or defects per thousand lines of code
should be stated.
Performance: The performance characteristics of the system. Include specific
response times. Reference related use cases by name.
Supportability: Any requirements that will enhance the supportability or
maintainability of the system being built.
Design Constraints: Any design constraints on the system being built.
Supplementary Specifications go hand-in-hand with the Use-Case Model, implying
that:
They are initially considered in the Inception phase as a complement to defining
the scope of the system.
They are refined in an incremental fashion during the Elaboration and
Construction phases.
3 - 23
Example: Supplementary Specification
Example: Supplementary Specification

Review the
Supplementary
Specification provided
in the Course
Registration
Requirements
Document.
Course
Registration
Requirements
Document
Supplementary
Specification
24
The idea is not to go over the Supplementary Specification in vivid detail, but to
demonstrate how to read it, where to look for information you will need during the
Analysis and Design activities, as well as how to detect if it is insufficient.
3 - 24

Introduction
Key Concepts
Use-Case Model
Glossary
Checkpoints

25
3 - 25
Checkpoints: Requirements: Use-Case Model
Checkpoints: Requirements: 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 usecase packages appropriate?
26
The above, as well as the remaining checklists in this section, is a sample of the kinds
of things to look for when reviewing the Use-Case Model. Explicit, detailed checklists
should be established for the project to support the review of the Use-Case Model.
Verify that there are no open questions. The use cases you found must be able to
perform all system behaviors; if not, some use cases are missing. If you intentionally
left any requirements to be dealt with in the object models, such as nonfunctional
requirements, you must mention this. Put the reference in the Supplementary
Specification(s) unless the requirement concerns a specific use case, in which case
state it in the Special Requirements section of the use case.
The Use-Case Model should not present more functions than were called for in the
requirements.
Traceability from the original requirements to the use cases and the Supplementary
Specification is critical for project management and impact assessment as well as to
make sure nothing has been missed.
The packaging should make the Use-Case Model simple and intuitive to understand
and maintain.
3 - 26
Checkpoints: Requirements: Actors
Checkpoints: Requirements: 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?

27
Make sure that all the roles in the system's environment have been accounted for and
modeled. You will not be able to do this fully until you have found and described all
the use cases.
Remove any actors not mentioned in the use-case descriptions or that have no
communicates-associations with a use case. However, an actor mentioned in a usecase description is likely to have a communicates-association with that particular use
case.
You should be able to name at least two people who would be able to perform as a
particular actor. If not, see if the role the actor models is part of another role. If so,
you should merge the actors.
If any actors play similar roles in relation to the system, they should be merged into a
single actor. If a particular actor will use the system in several completely different
ways, or has several completely different purposes for using the use case, then there
should probably be more than one actor.
If two actors play the same role in relation to a use case, then actor-generalizations
should be used to model their shared behavior.
It is important that actor names correspond to their roles.
3 - 27
Checkpoints: Requirements: Use-Cases
Checkpoints: Requirements: 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 alike
understand the names and
descriptions of the use cases?

28
A use case that does not interact with an actor is superfluous. You should remove it.
If two use cases are always activated in the same sequence, you should probably
merge them into one use case.
Use cases that have very similar behaviors or flows of events, or will be similar in the
future, should be merged into a single use case. This makes it easier to introduce
future changes.
Note: You must involve the users if you decide to merge use cases because the users,
who interact with the new, merged use case will probably be affected.
If some part of the flow of events is already part of another use case, the sub-flow
should be extracted and then be used by all of the use cases in question.
Note: You must involve the users if you decide to "reuse" the sub-flow, because the
users of the existing use case will probably be affected.
Each use-case name must describe the behavior the use case supports. The names
and descriptions must be understood by the users and customers.
3 - 28
Checkpoints: Requirements: Use-Case Specifications
Checkpoints: Requirements: Use-Case Specifications

Is it clear who wants 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?
29
Include any (nonfunctional) requirements to be handled in the object models in the

use-case Special Requirements.
Behavior might exist that is activated only when a certain condition is not met. There
should be a description of what will happen in such a case.
If you want your Use-Case Model to be easy to understand, you might have to split
up complex use cases. A use case that contains disparate flows of events will be very
difficult to understand and to maintain. It is best to divide such use cases into two or
more separate ones.
3 - 29
Checkpoints: Requirements: Glossary
Checkpoints: Requirements: 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?

30
If each Glossary term is not included somewhere in the use-case descriptions, that
may imply that a use case is missing or that the existing use cases are not complete. It
is more likely, though, that the term is not included because it is not needed, and it
should be removed from the Glossary.
A term should represent the same thing in all use-case descriptions.
3 - 30
Review
Review: Requirements Overview
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 use case and a
scenario?
What is a Supplementary Specification
and what does it include?
What is a Glossary and what does
it include?

31
3 - 31
Exercise: Requirements Overview
Exercise: Requirements Overview

Given the following Requirements artifacts:
Problem statement
Use-Case Model main diagram
Supplementary specification
Glossary
Review the given Requirements artifacts,

noting any questions, issues,
inconsistencies.

32
These artifacts will be used as the basis for the remainder of the examples and
exercises in this course, so you need to have a good foundation for moving forward.
All questions, issues, etc. regarding the Requirements artifacts will be recorded and
addressed here.
You will not be reviewing the use-case flow of events at this point. They will be
reviewed in detail later in the course.
The Requirements artifacts for this exercise can be found in the Payroll Requirements
Document. See the documents table of contents for specific page numbers.
3 - 32
Module 4
Analysis and Design Overview

and Design with UML
Module 4: Analysis and Design Overview
Topics
Key Concepts ....................................................................................................... 4-5
Analysis and Design Workflow............................................................................ 4-11
4-1
Objectives: Analysis and Design Overview
Objectives: Analysis and Design Overview

Review the key Analysis and Design terms
and concepts
Introduce the Analysis and Design process,
including roles, artifacts and workflow
Explain the difference between Analysis
and Design

This Analysis and Design Overview module provides an overview of the Analysis and
Design Discipline. It also defines the terms that span all Analysis and Design activities.
The details of each of the Analysis and Design activities will be described in
subsequent modules. This module is meant to provide context for these detailed
Analysis and Design activity modules.
4-2
Module 4 - Analysis and Design Overview
Analysis and Design in Context
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.

The purposes of Analysis and Design are to:
Transform the requirements into a system design.
Evolve a robust architecture for the system.
Adapt the design to match the implementation environment, designing it for

performance.
The Analysis and Design Discipline is related to other process disciplines.
The Business Modeling Discipline provides an organizational context for the

system.
The Requirements Discipline provides the primary input for Analysis and Design.
The Test Discipline tests the system designed during Analysis and Design.
The Environment Discipline develops and maintains the supporting artifacts that
are used during Analysis and Design.
The Management Discipline plans the project and each iteration (described in
an Iteration Plan).
4-3
Use-Case Model
Glossary
Analysis
and Design
Design Model
Architecture
Document
Supplementary
Specification
Data Model

The input artifacts are the Use-Case Model, Glossary, and Supplementary
Specification from the Requirements Discipline. The result of Analysis and Design is
a Design Model that serves as an abstraction of the source code; that is, the Design
Model acts as a blueprint of how the source code is structured and written. The
Design Model consists of design classes structured into design packages; it also
contains descriptions of how objects of these design classes collaborate to perform
use cases (use-case realizations).
The design activities are centered around the notion of architecture. The production
and validation of this architecture is the main focus of early design iterations.
Architecture is represented by a number of architectural views that capture the major
structural design decisions. In essence, architectural views are abstractions or
simplifications of the entire design, in which important characteristics are made more
visible by leaving details aside. The architecture is an important vehicle not only for
developing a good Design Model, but also for increasing the quality of any model
built during system development. The architecture is documented in the Architecture
Document.
The development of the Architecture Document is out of the scope of this course, but
we will discuss it is contents and how to interpret them.
4-4
Key Concepts
Analysis & Design Overview Topics
Key Concepts
Analysis and Design Workflow

We will start out by defining some key terms and concepts needed to describe the
Analysis and Design workflow. These terms will be explained in more detail, along
with other important terms and concepts in later modules of the course.
Once we have a common vocabulary, then we will walk through the Analysis and
Design workflow.
4-5
Analysis Versus Design
Analysis Versus Design

Analysis
Design
Focus on
understanding the
problem
Idealized design
Behavior
System structure
Functional
requirements
A small model

Focus on
understanding the
solution
Operations and
attributes
Performance
Close to real code
Object lifecycles
Nonfunctional
requirements
A large model
The differences between Analysis and Design are ones of focus and emphasis. The
above slide lists the things that you focus on in Analysis versus Design.
The goal in Analysis is to understand the problem and to begin to develop a visual
model of what you are trying to build, independent of implementation and
technology concerns. Analysis focuses on translating the functional requirements into
software concepts. The idea is to get a rough cut at the objects that comprise our
system, but focusing on behavior (and therefore encapsulation). We then move very
quickly, nearly seamlessly, into Design and the other concerns.
A goal of Design is to refine the model with the intention of developing a Design
Model that will allow a seamless transition to the coding phase. In design, we adapt
to the implementation and the deployment environment. The implementation
environment is the developer environment, which is a software superset and a
hardware subset of the deployment environment
In modeling, we start with an Object Model that closely resembles the real world
(Analysis), and then find more abstract (but more fundamental) solutions to a more
generalized problem (Design). The real power of software design is that it can create
more powerful metaphors for the real world that change the nature of the problem,
making it easier to solve.
4-6
Analysis and Design Are Not Top-Down or Bottom-Up

Analysis and Design Are Not Top-Down or Bottom-Up
Analysis and Design
Top
Down
Subsystems
Use Cases
Bottom
Up
Analysis Classes
(Define a
middle level)
Design Classes
The Analysis and Design Discipline is not top-down or bottom-up.

The use case comes in from the left and defines a middle level.
The analysis classes are not defined in a top-down pattern or a bottom-up pattern;
they are in the middle. From this middle level one may move up or down.
Defining subsystems is moving up and defining design classes is moving down.
Analysis is both top-to-middle, middle-up, middle-down and bottom-to-middle.
There is no way of saying that one path is more important than another you have
to travel on all paths to get the system right.
All of these four paths are equally important. That is why the bottom-up and topdown question cannot be solved.
4-7
What Is Architecture?
What Is 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 these structural and behavioral
elements into larger subsystems
Architectural style that guides this organization
Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational
(derived from Mary Shaw)
Based on extensive research, Rational has established a definition of architecture.

Significant in this context implies strategic, of major impact.
The architecture has a static and a dynamic perspective.
The architecture for similar systems should be similar (a particular style is used).
An equation we have used is:
Architecture = Elements + Form + Rationale.
Rationale is essential for justifying a good architecture.
Patterns are the guidelines for assembling elements in some form. We will discuss
patterns in the architecture modules.
4-8
Architecture Constrains Design and Implementation
Architecture Constrains Design and Implementation

Architecture involves a set of strategic
design decisions, rules or patterns that
constrain design and construction.
Code
Implementation
Design
Architecture
Architecture decisions are the most fundamental

decisions, and changing them will have significant effects.
Architectures can be viewed as a set of key design decisions.

The architecture is the initial set of constraints placed on the system. Such constraints
are the the most important ones. They constitute the fundamental decisions about
the software design. Architecture puts a framework around the design. Architecture
has been called strategic design.
An architects job is to eliminate unnecessary creativity. As you move closer to code,
creativity is eliminated. (The architecture constrains the design which constrains the
implementation.) This is good because during Implementation, the creativity can be
spent elsewhere (for example, for improving the quality, and performance) of the
implementation (for example, code).
4-9
Software Architecture: The 4+1 View Model
Software Architecture: The 4+1 View Model
Logical View
Analysts/Designers
Structure
Implementation View
End-user
Functionality
Programmers
Software management
Use-Case View
Process View
Deployment View
System integrators
Performance
Scalability
Throughput

System engineering
System topology
Delivery, installation
communication
10
The above diagram shows the model Rational uses to describe the software
architecture.
Architecture is many things to many different interested parties. On a particular
project, there are usually multiple stakeholders, each with their own concerns and
view of the system to be developed. The goal is to provide each of these stakeholders
with a view of the system that addresses their concerns, and suppresses the other
details.
To address these different needs, Rational has defined the 4+1 view architecture
model. An architectural view is a simplified description (an abstraction) of a system
from a particular perspective or vantage point, covering particular concerns, and
omitting entities that are not relevant to this perspective. Views are slices of models.
Not all systems require all views (for example, single processor: drop Deployment
View; single process: drop Process View; small program: drop Implementation View,
and so forth). A project may document all of these views or additional views. The
number of views is dependent on the system you are building.
Each of these views, and the UML notation used to represent them, will be discussed
in subsequent modules.
4 - 10

Analysis & Design Overview Topics
Key Concepts

11
Because we have a common vocabulary, we can now briefly discuss the activities of
Analysis and Design and how they work together.
4 - 11

[Early
Elaboration
Iteration]
[Inception
Iteration (Optional)]
Perform
Architectural
Synthesis
Define a Candidate
Architecture
Analysis
Analyze Behavior
(Optional)
Refine the
Architecture
Design

Define
Components
Design the
Database
12
A mere enumeration of all workers, activities, and artifacts does not constitute a
process. We need a way to describe the activities, some valuable result, and
interactions between workers. A workflow is a sequence of activities that produces a
result of observable value.
In UML terms, a workflow can be expressed as a sequence diagram, a collaboration
diagram, or an activity diagram. We use a form of activity diagram in the Rational
Unified Process. For each core workflow, an activity diagram is presented. This
diagram shows the workflow, expressed in terms of workflow details.
This slide shows the Analysis and Design workflow. The early Elaboration Phase
focuses on creating an initial architecture for the system (Define a Candidate
Architecture) to provide a starting point for the main analysis work. If the architecture
already exists (because it was produced in previous iterations, or projects, or is
obtained from an application framework), the focus of the work changes to refining
the architecture (Refine the Architecture) analyzing behavior, and creating an initial
set of elements that provide the appropriate behavior (Analyze Behavior).
After the initial elements are identified, they are further refined. Design Components
and Design Real-Time Components produce a set of components that provide the
appropriate behavior to satisfy the requirements on the system. In parallel with these
activities, persistence issues are handled in Design the Database. The result is an
initial set of components that are further refined in the Implementation Discipline.
4 - 12
Analysis and Design Activity Overview
Analysis and Design Activity Overview
Architect
Designer

13
Remember, for Analysis and Design, we start out with the Use-Case Model and the
supplementary specifications from the Requirements Discipline and end up with the
Design Model that serves as an abstraction of the source code.
The design activities are centered around the notion of architecture. The production
and validation of this architecture are the main focal points of early design iterations.
The architecture is an important vehicle not only for developing a good Design
Model, but also for increasing the quality of any model built during system
development.
The focus of this course is on the activities of the designer. The architect activities are
discussed, but many of the architectural decisions will be given. Each of the architect
and designer activities will be addressed in individual course modules.
4 - 13
Software Architects Responsibilities
Software Architects Responsibilities

The
Software
Architect
leads and
coordinates
technical
activities
and artifacts.
Analysis Model
Architect
Design Model
Deployment Model
Reference
Architecture
Software
Architecture
Document
14
The software architect role leads and coordinates technical activities and artifacts
throughout the project. The software architect establishes the overall structure for
each architectural view: the decomposition of the view, the grouping of elements,
and the interfaces between these major groupings. Therefore, in contrast to the other
roles, the software architect's view is one of breadth as opposed to one of depth.
In summary, the software architect must be well-rounded and possess maturity,
vision, and a depth of experience that allows for grasping issues quickly and making
educated, critical judgment in the absence of complete information. More
specifically, the software architect, or members of the architecture team, must
combine these skills:
Experience in both the problem domain, through a thorough understanding of
the requirements, and the software engineering domain. If there is a team, these
qualities can be spread among the team members, but at least one software
architect must provide the global vision for the project.
Leadership in order to drive the technical effort across the various teams, and to
make critical decisions under pressure and make those decisions stick. To be
effective, the software architect and the project manager must work closely
together, with the software architect leading the technical issues and the project
manager leading the administrative issues. The software architect must have the
authority to make technical decisions.
Communication to earn trust, to persuade, to motivate, and to mentor. The
software architect cannot lead by decree only by the consent of the rest of the
project. In order to be effective, the software architect must earn the respect of
the project team, the project manager, the customer, and the user community, as
well as the management team.
Goal orientation and being proactive with a relentless focus on results. The
software architect is the technical driving force behind the project, not a visionary
or dreamer. The career of a successful software architect is a long series of suboptimal decisions made in uncertainty and under pressure. Only those who can
focus on doing what needs to be done are successful in this environment of the
project.
4 - 14
Designers Responsibilities
Designers Responsibilities
The designer
must know
use-case
modeling
techniques,
system
requirements,
and software
design
techniques.

Use-Case
Realization
Package/
Subsystem
Designer
Class
15
The designer role defines the responsibilities, operations, attributes, and relationships
of one or several classes, and determines how they are adjusted to the
implementation environment. In addition, the designer role may have responsibility
for one or more design packages, or design subsystems, including any classes owned
by the packages or subsystems.
The designer must have a solid working knowledge of:
Use-case modeling techniques
System requirements
Software design techniques, including object-oriented Analysis and Design

techniques, and the Unified Modeling Language
Technologies with which the system will be implemented
In addition, the designer must:
Understand the architecture of the system, as represented in the Software

Architecture Document.
4 - 15
Review: Analysis and Design Is Use-Case Driven
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
16
Use cases are one recommended method for organizing your requirements. Instead
of a bulleted list of requirements, you organize them in a way that tells how someone
may use the system. By doing so, you make a requirement more complete and
consistent. You can also better understand the importance of a requirement from a
users perspective.
It is often difficult to tell how a system does what it is supposed to do from a
traditional object-oriented system model. This stems from the lack of a common
thread through the system when it performs certain tasks. Use cases are that thread,
because they define the behavior performed by a system.
Use cases are not part of "traditional" object orientation, but their importance has
become more and more apparent, further emphasizing the fact that use cases are
part of the UML.
4 - 16
What Is a Use-Case Realization?
What Is a Use-Case Realization?

Use-Case Model
Design Model
Use Case
Use-Case Realization
Sequence Diagrams
Collaboration Diagrams
Use Case
Class Diagrams
17
A use-case realization describes how a particular use case is realized within the
Design Model, in terms of collaborating objects. A use-case realization ties together
the use cases from the Use-Case Model with the classes and relationships of the
Design Model. A use-case realization specifies what classes must be built to
implement each use case.
In the UML, use-case realizations are stereotyped collaborations. The symbol for a
collaboration is an ellipsis containing the name of the collaboration.The symbol for a
use-case realization is a dotted line version of the collaboration symbol.
A use-case realization in the Design Model can be traced to a use case in the UseCase Model. A realization relationship is drawn from the use-case realization to the
use case it realizes.
Within the UML, a use-case realization can be represented using a set of diagrams
that model the context of the collaboration (the classes/objects that implement the
use case and their relationships class diagrams), and the interactions of the
collaborations (how these classes/objects interact to perform the use cases
collaboration and sequence diagrams).
The number and types of the diagrams that are used depend on what is needed to
provide a complete picture of the collaboration and the guidelines developed for the
project under development.
4 - 17
Analysis and Design in an Iterative Process
Analysis and Design in an Iterative Process

Start of
iteration
Use Case A
Scenarios 1 & 2
Use Case B
Scenario 1
Use Case A
Scenario 3
Use-Case
Realization A
End of
iteration
Use-Case
Realization A
Use-Case
Realization B
Iteration n
Iteration n + 1
18
This course assumes the developer is using an iterative process. Remember, each
pass through the sequence of process workflows is called an iteration. Thus, from a
development perspective, the software lifecycle is a succession of iterations, through
which the software develops incrementally.
During the Analysis and Design workflow in an iteration a use case will serve as the
primary input artifact. By going through the a series of activities defined in the
Analysis and Design workflow, the development team will create an associated usecase realization that describes how a particular use case will be realized.
4 - 18
Review: Analysis and Design Overview
Review: Analysis and Design Overview

What is the purpose of the Analysis and
Design Discipline?
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?

19
4 - 19
4 - 20
Module 5
Architectural Analysis

and Design with UML
Module 5: Architectural Analysis
Topics
Architectural Analysis Overview............................................................................ 5-4
Key Concepts ....................................................................................................... 5-5
Define the high-level Organization of Subsystems ............................................... 5-10
Identify Analysis Mechanisms.............................................................................. 5-19
Identify Key Abstractions .................................................................................... 5-28
Create Use-Case Realizations ............................................................................. 5-32
Review............................................................................................................... 5-38
5-1
Objectives: Architectural Analysis
Objectives: Architectural Analysis

Explain the purpose of Architectural Analysis
and where it is performed in the lifecycle.
Describe a representative architectural pattern
and set of analysis mechanisms, and how they
affect the architecture.
Describe the rationale and considerations that
support the architectural decisions.
Show how to read and interpret the results of
Architectural Analysis:
Architectural layers and their relationships
Key abstractions
Analysis mechanisms

A focus on software architecture allows you to articulate the structure of the software
system (the packages/components), and the ways in which they integrate (the
fundamental mechanisms and patterns by which they interact).
Architectural Analysis is where we make an initial attempt at defining the
pieces/parts of the system and their relationships, organizing these pieces/parts into
well-defined layers with explicit dependencies, concentrating on the upper layers of
the system. This will be refined, and the lower layers will be defined during
Incorporate Existing Design Elements.
5-2
Module 5 - Architectural Analysis
Architectural Analysis in Context
Architectural Analysis in Context

[Early
Elaboration
Iteration]
Architecture
Analysis
Architect
[Inception
Perform
Architectural
Synthesis
Define a Candidate
Architecture
Analyze Behavior
(Optional)
Refine the
Architecture
Define
Components

Design the
Database
As you may recall, the above diagram illustrates the workflow that we are using in this
course. It is a tailored version of the Analysis and Design core workflow of the
Rational Unified Process. Architectural Analysis is an activity in the Define a
Candidate Architecture workflow detail.
Architectural Analysis is how the project team (or the architect) decides to define
the projects high-level architecture. It is focused mostly on bounding the analysis
effort in terms of agreed-upon architectural patterns and idioms, so that the analysis
work is not working so much from first principles. Architectural Analysis is very
much a configuring of Use-Case Analysis.
During Architectural Analysis, we concentrate on the upper layers of the system,
making an initial attempt at defining the pieces/parts of the system and their
relationships and organizing these pieces/parts into well-defined layers with explicit
dependencies.
In Use-Case Analysis, we will expand on this architecture by identifying analysis
classes from the requirements. Then, in Incorporate Existing Design Elements, the
initial architecture is refined, and the lower architecture layers are defined, taking
into account the implementation environment and any other implementation
constraints.
Architectural Analysis is usually done once per project, early in the Elaboration
phase. The activity is performed by the software architect or architecture team.
This activity can be skipped if the architectural risk is low.
5-3
Architectural Analysis Overview

Architectural Analysis Overview
Supplementary
Specification
Glossary
Software
Architecture Doc
Reference
Architecture
Vision
Document
Architectural
Analysis
Project-Specific
Guidelines
Design Model
Use-Case Model
Deployment Model
4
Purpose:
To define a candidate architecture for the system based on experience gained
from similar systems or in similar problem domains.
To define the architectural patterns, key mechanisms, and modeling conventions
for the system.
To define the reuse strategy.
To provide input to the planning process.
Input Artifacts:
Use-Case Model
Glossary
Design Model
Reference Architecture
Vision Document
Project Specific Guidelines
Software Architecture Document
Resulting Artifacts:
Design Model
Deployment Model
5-4
Key Concepts
Architectural Analysis Steps
Key Concepts
Define the High-Level Organization of
Subsystems
Identify Analysis mechanisms
Identify Key Abstractions
Create Use-Case Realizations
Checkpoints

The above are the topics we will be discussing within the Architectural Analysis
module. Unlike the designer activity modules, you will not be discussing each step of
the activity, as the objective of this module is to understand the important
Architectural Analysis concepts, not to learn HOW to create an architecture.
Before you discuss Architectural Analysis in any detail, it is important to
review/define some key concepts.
5-5
Review: What Is Architecture: The 4+1 View Model
Review: What Is Architecture: The 4+1 View Model
Logical View
Analysts/Designers
Structure
Implementation View
End-user
Functionality
Programmers
Software management
Use-Case View
Process View
Deployment View
System integrators
Performance
Scalability
Throughput

System engineering
System topology
Delivery, installation
communication
The above diagram describes the model Rational uses to describe the software
architecture. This is the recommended way to represent a software architecture.
There may be other precursor architectures that are not in this format. The goal is
to mature those architectural representations into the 4+1 view representation.
In Architectural Analysis, you will concentrate on the Logical View. The other views
will be addressed in later architecture modules:
5-6
The Logical View will be refined in the Identify Design Mechanisms, Identify
Design modules.
The Process View will be discussed in the Describe Run-time Architecture

module.
The Deployment View will be discussed in the Describe Distribution module.
The Implementation View is developed during Implementation and is thus

considered out of scope for this Analysis and Design course.
Review: What Is a Package?
Review: What Is a Package?

A package is a general-purpose mechanism
for organizing elements into groups.
It is a model element that can contain other
model elements.
University
Artifacts
A package can be used

To organize the model under development.
As a unit of configuration management.
Packages were first introduced in the Introduction to Object Orientation module.

The slide is repeated here for review purposes.
Packages can be used to group any model elements. However, in this module, we
will be concentrating on how they are used within the Design Model.
5-7
Package Relationships: Dependency
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.
Elements in one package can import elements from another package. In the UML,
this is represented as a dependency relationship.
The relationships of the packages reflect the allowable relationships between the
contained classes. A dependency relationship between packages indicates that the
contents of the supplier packages may be referenced by the client. In the above
example, if a dependency relationship exists between the Client package and the
Supplier package, then classes in the Client package may access classes in the
Supplier package.
Some of the implications of package dependency are:
Whenever a change is made to the Supplier package, the Client package must,
potentially, be recompiled and re-tested.
The Client package cannot be reused independently because it depends on the

Supplier package.
The grouping of classes into logical sets and the modeling of their relationships can
occur anywhere in the process when a set of cohesive classes is identified.
5-8
Avoiding Circular Dependencies
Avoiding Circular Dependencies

A
Hierarchy
should be
acyclic
A
C
B
A'
C
Circular dependencies make it impossible

to reuse one package without the other.
It is desirable that the package hierarchy be acyclic. This means that the following
situation should be avoided (if possible):
Package A uses package B, which uses package A.
If a circular dependency exists between Package A and Package B, if you change

Package A it might cause a change in Package B, which might cause a change in
Package A, etc. A circular dependency between packages A and B means that they
will effectively have to be treated as a single package.
Circles wider than two packages must also be avoided. For example, package A uses
package B, which uses package C, which uses package A.
Circular dependencies may be able to be broken by splitting one of the packages into
two smaller ones. In the above example, the elements in package A that were
needed by the other packages were factored out into their own package, A, and the
appropriate dependencies were added.
5-9
Define the High-Level Organization of Subsystems

Key Concepts
Subsystems
Checkpoints

10
Early in the software development lifecycle, it is important to define the modeling

conventions that everyone on the project should use. The modeling conventions
ensure that the representation of the architecture and design are consistent across
teams and iterations.
5 - 10
Patterns and Frameworks
Patterns and Frameworks

Pattern
Provides a common solution to a common problem
in a context
Analysis/Design pattern
Provides a solution to a narrowly-scoped technical
problem
Provides a fragment of a solution, or a piece of the
puzzle
Framework
Defines the general approach to solving the
problem
Provides a skeletal solution, whose
details may be Analysis/Design patterns
11
The selection of the upper-level layers may be affected by the choice of an

architectural pattern or framework. Thus, it is important to define what these terms
mean.
A pattern codifies specific knowledge collected from experience. Patterns provide
examples of how good modeling solves real problems, whether you come up with the
pattern yourself or you reuse someone elses. Design patterns are discussed in more
detail on the next slide.
Frameworks differ from Analysis and Design patterns in their scale and scope.
Frameworks describe a skeletal solution to a particular problem that may lack many
of the details, and that may be filled in by applying various Analysis and Design
patterns.
A framework is a micro-architecture that provides an incomplete template for
applications within a specific domain. Architectural frameworks provide the context
in which the components run. They provide the infrastructure (plumbing, if you will)
that allows the components to co-exist and perform in predictable ways. These
frameworks may provide communication mechanisms, distribution mechanisms,
error processing capabilities, transaction support, and so forth.
Frameworks may range in scope from persistence frameworks that describe the
workings of a fairly complex but fragmentary part of an application to domain-specific
frameworks that are intended to be customized (such as Peoplesoft, SanFransisco,
Infinity, and SAP). For example, SAP is a framework for manufacturing and finance.
5 - 11
What Is a Design Pattern?
What Is a Design Pattern?

A design pattern is a solution to a common
design problem.
Describes a common design problem
Describes the solution to the problem
Discusses the results and trade-offs of applying the
pattern
Design patterns provide the capability to reuse

successful designs.
Template
Parameters
Pattern Name
Parameterized
Collaboration
Structural Aspect
Behavioral Aspect
12
We will look at a number of design patterns throughout this course. Thus, it is

important to define what a design pattern is up front.
Design patterns are being collected and cataloged in a number of publications and
mediums.You can use design patterns to solve issues in your design without
reinventing the wheel. You can also use design patterns to validate and verify your
current approaches.
Using design patterns can lead to more maintainable systems and increased
productivity.They provide excellent examples of good design heuristics and design
vocabulary. In order to use design patterns effectively, you should become familiar
with some common design patterns and the issues that they mitigate.
A design pattern is modeled in the UML as a parameterized collaboration.Thus it has
a structural aspect and a behavioral aspect. The structural part is the classes whose
instances implement the pattern, and their relationships (the static view).The
behavioral aspect describes how the instance collaborate usually by sending
messages to each other to implement the pattern (the dynamic view).
A parameterized collaboration is a template for a collaboration.The Template
Parameters are used to adapt the collaboration for a specific usage.These parameters
may be bound to different sets of abstractions, depending on how they are applied in
the design.
5 - 12
What Is an Architectural Pattern?
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

13
Architectural Analysis is where you consider architectural patterns, as this choice

affects the high-level organization of your object model.
Layers: The layers pattern is where an application is decomposed into different levels
of abstraction. The layers range from application-specific layers at the top to
implementation/technology-specific layers on the bottom.
Model-View-Controller: The MVC pattern is where an application is divided into
three partitions: The Model, which is the business rules and underlying data, the
View, which is how information is displayed to the user, and the Controllers, which
process the user input.
Pipes and Filters: In the Pipes and Filters pattern, data is processed in streams that
flow through pipes from filter to filter. Each filter is a processing step.
Blackboard: The Blackboard pattern is where independent specialized applications
collaborate to derive a solution, working on a common data structure.
Architectural patterns can work together. (That is, more than one architectural pattern
can be present in any one software architecture.)
The architectural patterns listed above imply certain system characteristics,
performance characteristics, and process and distribution architectures. Each solves
certain problems but also poses unique challenges. For this course, you will
concentrate on the Layers architectural pattern.
5 - 13
Typical Layering Approach
Typical Layering Approach

Specific
functionality
Application Subsystems
Distinct application subsystems that make

up an application contains the value
adding software developed by the
organization.
Business-Specific
Business specific contains a number of

reusable subsystems specific to the type of
business.
Middleware
Middleware offers subsystems for utility

classes and platform-independent services
for distributed object computing in
heterogeneous environments and so on.
System Software
System software contains the software

for the actual infrastructure such as
operating systems, interfaces to specific
hardware, device drivers, and so on.
General
functionality
14
Layering represents an ordered grouping of functionality, with the application-specific

functions located in the upper layers, functionality that spans application domains in
the middle layers, and functionality specific to the deployment environment at the
lower layers.
The number and composition of layers is dependent upon the complexity of both the
problem domain and the solution space:
There is generally only a single application-specific layer.
In domains with existing systems, or that have large systems composed of interoperating smaller systems, the Business-Specific layer is likely to partially exist
and may be structured into several layers for clarity.
Solution spaces, which are well-supported by middleware products and in which
complex system software plays a greater role, have well-developed lower layers,
with perhaps several layers of middleware and system software.
This slide shows a sample architecture with four layers:
The top layer, Application layer, contains the application-specific services.
The next layer, Business-Specific layer, contains business-specific components
used in several applications.
The Middleware layer contains components such as GUI-builders, interfaces to
database management systems, platform-independent operating system services,
and OLE-components such as spreadsheets and diagram editors.
The bottom layer, System Software layer, contains components such as
operating systems, databases, interfaces to specific hardware, and so on.
5 - 14
Architectural Pattern: Layers
Architectural Pattern: Layers

Equipment and
customer-specific
code
5
Application
Processes and other

application code
Major abstractions,
classes, etc.
3
Application
Framework
Mechanisms,
services
H/W specific code, O/S

specific code, generalpurpose code (for
example, ORB, MQS)

Infrastructure
15
Context
A large system that requires decomposition.
Problem
A system that must handle issues at different levels of abstraction; for example:
hardware control issues, common services issues, and domain-specific issues. It
would be extremely undesirable to write vertical components that handle issues at all
levels. The same issue would have to be handled (possibly inconsistently) multiple
times in different components.
Forces
Parts of the system should be replaceable.
Changes in components should not ripple.
Similar responsibilities should be grouped together.
Size of components complex components may have to be decomposed.
Solution
Structure the systems into groups of components that form layers on top of each
other. Make upper layers use services of the layers below only (never above). Try not
to use services other than those of the layer directly below. (Do not skip layers unless
intermediate layers would only add pass-through components.)
A strict layered architecture states that design elements (classes, components,
packages, and subsystems) only utilize the services of the layer below them. Services
can include event-handling, error-handling, database access, and so forth. It contains
more palpable mechanisms, as opposed to the raw operating system level calls
documented in the bottom layer.
5 - 15
Layering Considerations
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
16
Layers are used to encapsulate conceptual boundaries between different kinds of

services and provide useful abstractions that make the design easier to understand.
When layering, concentrate on grouping things that are similar together, as well as
encapsulating change.
There is generally only a single Applicationlayer. On the other hand, the number of
domain layers is dependent upon the complexity of both the problem and the
solution spaces.
When a domain has existing systems, complex systems composed of inter-operating
systems, and/or systems where there is a strong need to share information between
design teams, the Business-Specific layer may be structured into several layers for
clarity.
In Architectural Analysis, we are concentrating on the upper-level layers (the
Application and Business-Specific layers). The lower level layers (infrastructure and
vendor-specific layers) will be defined in Incorporate Existing Design Elements.
5 - 16
Modeling Architectural Layers
Modeling Architectural Layers

Architectural layers can be modeled using
stereotyped packages.
<<layer>> stereotype
<<layer>>
Package Name

17
Layers can be represented in Rose as packages with the <<layer>> stereotype. The
layer descriptions can be included in the documentation field of the specification of
the package.
5 - 17
Example: High-Level Organization of the Model
Example: High-Level Organization of the Model

<<layer>>
Application
<<layer>>
Business Services

18
The above example includes the Application and Business-Specific layers for the
Course Registration System.
The Application layer contains the design elements that are specific to the Course
Registration application.
We expect that multiple applications will share some key abstractions and common
services. These have been encapsulated in the Business Services layer, which is
accessible to the Application layer. The Business Services layer contains businessspecific elements that are used in several applications, not necessarily just this one.
5 - 18
Identify Analysis Mechanisms

Key Concepts
Subsystems
Checkpoints

19
The architecture should be simple, but not simplistic. It should provide standard
behavior through standard abstractions and mechanisms. Thus, a key aspect in
designing a software architecture is the definition and the selection of the
mechanisms that designers use to give "life" to their objects.
In Architectural Analysis, it is important to identify the analysis mechanisms for the
software system being developed. Analysis mechanisms focus on and address the
nonfunctional requirements of the system (that is, the need for persistence, reliability,
and performance), and builds support for such non-functional requirements directly
into the architecture.
Analysis mechanisms are used during analysis to reduce the complexity of analysis,
and to improve its consistency by providing designers with a shorthand representation
for complex behavior. Mechanisms allow the analysis effort to focus on translating the
functional requirements into software abstractions without becoming bogged down in
the specification of relatively complex behavior that is needed to support the
functionality but which is not central to it.
5 - 19
What Are Architectural Mechanisms?
What Are Architectural Mechanisms?

Required
Functionality
Implementation
Environment
realized by client
classes using
constrained by
Mechanisms
Supplementary
Specification
COTS Products
Databases
IPC Technology
etc.
responsible for
Use-Case Model
Architect
20
In order to better understand what an analysis mechanism is, we have to understand

what an architectural mechanism is.
An architectural mechanism is a strategic decision regarding common standards,
policies, and practices. It is the realization of topics that should be standardized on a
project. Everyone on the project should utilize these concepts in the same way, and
reuse the same mechanisms to perform the operations.
An architectural mechanism represents a common solution to a frequently
encountered problem. It may be patterns of structure, patterns of behavior, or both.
Architectural mechanisms are an important part of the "glue" between the required
functionality of the system and how this functionality is realized, given the constraints
of the implementation environment.
Support for architectural mechanisms needs to be built in to the architecture.
Architectural mechanisms are coordinated by the architect. The architect chooses
the mechanisms, validates them by building or integrating them, verifies that they do
the job, and then consistently imposes them upon the rest of the design of the
system.
5 - 20
Architectural Mechanisms: Three Categories
Architectural Mechanisms: Three Categories

Architectural Mechanism Categories
Analysis mechanisms (conceptual)
Design mechanisms (concrete)
Implementation mechanisms (actual)

21
There are three categories of architectural mechanisms. The only difference between
them is one of refinement.
Analysis mechanisms capture the key aspects of a solution in a way that is
implementation-independent. They either provide specific behaviors to a domainrelated class or component, or correspond to the implementation of cooperation
between classes and/or components. They may be implemented as a framework.
Examples include mechanisms to handle persistence, inter-process communication,
error or fault handling, notification, and messaging, to name a few.
Design mechanisms are more concrete. They assume some details of the
implementation environment, but are not tied to a specific implementation (as is an
implementation mechanism).
Implementation mechanisms specify the exact implementation of the mechanism.
Implementation mechanisms are are bound to a certain technology, implementation
language, vendor, or other factor.
In a design mechanism, some specific technology is chosen (for example, RDBMS vs.
ODBMS), whereas in an implementation mechanism, a VERY specific technology is
chosen (for example, Oracle vs. SYBASE).
The overall strategy for the implementation of analysis mechanisms must be built into
the architecture. This will be discussed in more detail in Identify Design mechanisms,
when design and implementation mechanisms are discussed.
5 - 21
Why Use Analysis Mechanisms?
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
dont even know what database we are
going to be using?
That is why we have a persistence

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

analysis and to improve its consistency by providing designers with a
shorthand representation for complex behavior.
22
An analysis mechanism represents a pattern that constitutes a common solution to a

common problem. These mechanisms may show patterns of structure, patterns of
behavior, or both. They are used during analysis to reduce the complexity of the
analysis, and to improve its consistency by providing designers with a shorthand
representation for complex behavior. Analysis mechanisms are primarily used as
placeholders for complex technology in the middle and lower layers of the
architecture. When mechanisms are used as placeholders in the architecture, the
architecting effort is less likely to become distracted by the details of mechanism
behavior.
Mechanisms allow the analysis effort to focus on translating the functional
requirements into software concepts without bogging down in the specification of
relatively complex behavior needed to support the functionality but which is not
central to it. Analysis mechanisms often result from the instantiation of one or more
architectural or analysis patterns.
Persistence provides an example of analysis mechanisms. A persistent object is one
that logically exists beyond the scope of the program that created it. The need to
have object lifetimes that span use cases, process lifetimes, or system shutdown and
startup, defines the need for object persistence. Persistence is a particularly complex
mechanism. During analysis we do not want to be distracted by the details of how we
are going to achieve persistence. This gives rise to a persistence analysis mechanism
that allows us to speak of persistent objects and capture the requirements we will
have on the persistence mechanism without worrying about what exactly the
persistence mechanism will do or how it will work.
Analysis mechanisms are typically, but not necessarily, unrelated to the problem
domain, but instead are "computer science" concepts. As a result, they typically
occupy the middle and lower layers of the architecture. They provide specific
behaviors to a domain-related class or component, or correspond to the
implementation of cooperation between classes and/or components.
5 - 22
Sample Analysis Mechanisms
Sample Analysis Mechanisms
Persistency
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

23
Analysis mechanisms either provide specific behaviors to a domain-related class or

component, or they correspond to the implementation of cooperation between
classes and/or components.
Some examples of analysis mechanisms are listed on this slide. This list is not meant
to be exhaustive.
Examples of communication mechanisms include inter-process communication (IPC)
and inter-node communication (a.k.a. remote process communication or RPC). RPC
has both a communication and a distribution aspect.
Mechanisms are perhaps easier to discuss when one talks about them as patterns
that are applied to the problem. So the inter-process communication pattern (that is,
the application is partitioned into a number of communicating processes) interacts
with the distribution pattern (that is, the application is distributed across a number of
nodes) to produce the RPC pattern (that is, the application is partitioned into a
number of processes, which are distributed across a number of nodes). This process
provides us a way to implement remote IPC.
5 - 23
Examples of Analysis Mechanism Characteristics
Examples of Analysis Mechanism Characteristics

Persistency mechanism
Granularity
Volume
Duration
Access mechanism
Access frequency (creation/deletion, update, read)
Reliability
Inter-process Communication mechanism
Latency
Synchronicity
Message size
Protocol

24
Analysis mechanism characteristics capture some nonfunctional requirements of the

system.
Persistency: For all classes whose instances may become persistent, we need to
identify:
Granularity: Range of size of the persistent objects
Volume: Number of objects to keep persistent
Duration: How long to keep persistent objects
Access mechanism: How is a given object uniquely identified and retrieved?
Access frequency: Are the objects more or less constant; are they permanently
updated?
Reliability: Shall the objects survive a crash of the process, the processor; the
whole system?
Inter-process Communication: For all model elements that need to communicate
with objects, components, or services executing in other processes or threads, we
need to identify:
Latency: How fast must processes communicate with another?
Synchronicity: Asynchronous communication
Size of message: A spectrum might be more appropriate than a single number.
Protocol, flow control, buffering, and so on.
5 - 24
Example of Analysis Mechanism Characteristics (cont.)

Example of Analysis Mechanism Characteristics (cont.)
Legacy interface mechanism
Latency
Duration
Access mechanism
Access frequency
Security mechanism
Data granularity
User granularity
Security rules
Privilege types
Others
25
Security:
Data granularity: Package-level, class-level, attribute level
User granularity: Single users, roles/groups
Security Rules: Based on value of data, on algorithm based on data, and on
algorithm based on user and data
Privilege Types: Read, write, create, delete, perform some other operation
5 - 25
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
Classes
Analysis
Mechanisms
Flight
Aircraft
Mission
Persistency
Communication
Schedule
Parsing
Route
Authentication
Load

26
The process for describing analysis mechanisms is:

1. Collect all analysis mechanisms in a list. The same analysis mechanism may
appear under several different names across different use-case realizations, or
across different designers. For example, storage, persistency, database, and
repository might all refer to a persistency mechanism. Inter-process
communication, message passing, or remote invocation might all refer to an
inter-process communication mechanism.
2. Draw a map of the client classes to the analysis mechanisms (see graphic on
slide).
3. Identify Characteristics of the analysis mechanisms. To discriminate across a
range of potential designs, identify the key characteristics used to qualify each
analysis mechanism. These characteristics are part functionality, part size, and
performance.
4. Model Using Collaborations. Once all of the analysis mechanisms are identified
and named, they should be modeled through the collaboration of a society of
classes. Some these classes do not directly deliver application functionality, but
exist only to support it. Very often, these support classes are located in the
middle or lower layers of a layered architecture, thus providing a common
support service to all application-level classes.
5 - 26
Example: Course Registration Analysis Mechanisms
Example: Course Registration Analysis Mechanisms

Persistence
Distribution
Security
Legacy Interface

27
The above are the selected analysis mechanisms for the Course Registration System.
Persistency: A means to make an element persistent (that is, exist after the
application that created it ceases to exist).
Distribution: A means to distribute an element across existing nodes of the system.
Security: A means to control access to an element.
Legacy Interface: A means to access a legacy system with an existing interface.
These are also documented in the Payroll Architecture Handbook, Architectural
Mechanisms section.
5 - 27

Key Concepts
Subsystems
Checkpoints

28
This is where the key abstractions for the problem domain are defined. Furthermore,
this is where the vocabulary of the software system is established.
The purpose of this step is to "prime the pump" for analysis by identifying and
defining the key abstractions that the system must handle. These may have been
initially identified during business modeling and requirement activities. However,
during those activities, the focus was on the problem domain. During analysis and
design, our focus is more on the solution domain.
5 - 28
What Are Key Abstractions?
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)

29
Requirements and Business Modeling activities usually uncover key concepts that the
system must be able to handle. These concepts manifest themselves as key design
abstractions. Because of the work already done, there is no need to repeat the
identification work again during Use-Case Analysis. To take advantage of existing
knowledge, we identify preliminary entity analysis classes to represent these key
abstractions on the basis of general knowledge of the system. Sources include the
Requirements, the Glossary, and in particular, the Domain Model, or the Business
Object Model, if you have one.
5 - 29
Defining Key Abstractions
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

30
While defining the initial analysis classes, you can also define any relationships that
exist between them. The relationships are those that support the basic definitions of
the abstractions. It is not the objective to develop a complete class model at this
point, but just to define some key abstractions and basic relationships to kick off the
analysis effort. This will help to reduce any duplicate effort that may result when
different teams analyze the individual use cases.
Relationships defined at this point reflect the semantic connections between the
defined abstractions, not the relationships necessary to support the implementation
or the required communication among abstractions.
The analysis classes identified at this point will probably change and evolve during the
course of the project. The purpose of this step is not to identify a set of classes that
will survive throughout design, but to identify the key abstractions the system must
handle. Do not spend much time describing analysis classes in detail at this initial
stage, because there is a risk that you might identify classes and relationships that are
not actually needed by the use cases. Remember that you will find more analysis
classes and relationships when looking at the use cases.
5 - 30
Example: Key Abstractions
Example: Key Abstractions

Professor
Student
Schedule
CourseCatalog
CourseOffering

Course
31
Professor: A person teaching classes at the university.

Student: A person enrolled in classes at the university.
Schedule: The courses a student has enrolled in for a semester.
CourseCatalog: Unabridged catalog of all courses offered by the university.
CourseOffering: A specific offering for a course, including days of the week and
times.
Course: A class offered by the university.
5 - 31

Key Concepts
Subsystems
Checkpoints

32
A use-case realization represents the design perspective of a use case. It is an

organization model element used to group a number of artifacts related to the usecase design. Use cases are separate from use-case realizations, so you can manage
each individually and change the design of the use case without affecting the baseline
use case. For each use case in the Use-Case Model, there is a use-case realization in
the design model with a dependency (stereotyped realize) to the use case.
5 - 32
Review: What is a Use-Case Realization?
Review: What is a Use-Case Realization?

Use-Case Model
Design Model
Use Case
Sequence Diagrams
Use Case
Class Diagrams
33
A use-case realization is the expression of a particular use case within the Design
Model. It describes the use case in terms of collaborating objects. A use-case
realization ties together the use cases from the Use-Case Model with the classes and
relationships of the Design Model. A use-case realization specifies what classes must
be built to implement each use case.
In the UML, use-case realizations are stereotyped collaborations. The symbol for a
collaboration is an oval containing the name of the collaboration. The symbol for a
use-case realization is a dotted line version of the collaboration symbol.
A use-case realization in the Design Model can be traced to a use case in the UseCase Model. A realization relationship is drawn from the use-case realization to the
use case it realizes.
Within the UML, a use-case realization can be represented using a set of diagrams
that model the context of the collaboration (the classes/objects that implement the
use case and their relationships class diagrams), and the interactions of the
collaborations (how these classes/objects interact to perform the use cases
collaboration and sequence diagrams).
The number and types of the diagrams that are used depend on what is needed to
provide a complete picture of the collaboration and the guidelines developed for the
project under development.
5 - 33
The Value of Use-Case Realizations
The Value of 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
34
Use cases form the central focus of most of the early analysis and design work. To
enable the transition between requirements-centric activities and design-centric
activities, the use-case realization serves as a bridge, providing a way to trace
behavior in the Design Model back to the Use-Case Model, as well as organizing
collaborations in the Design Model around the Use-Case concept.
For each Use Case in the Use Case Model, create a use-case realization in the Design
Model. The name for the use-case realization should be the same as the associated
use case, and a trace dependency should be established from the use case realization
to its associated use case.
5 - 34

Key Concepts
Subsystems
Checkpoints

35
This is where the quality of the architecture modeled up to this point is assessed
against some very specific criteria.
In this module, we will concentrate on those checkpoints that the designer is most
concerned with (that is, looks for). The architect should do a much more detailed
review of the Architectural Analysis results and correct any problems before the
project moves on to the next activity. We will not cover those checkpoints, as they
are out of scope of this course. (Remember, this is not an architecture course.)
5 - 35
Checkpoints
Checkpoints
General
Is the package partitioning and
layering done in a logically
consistent way?
Have the necessary analysis
mechanisms been identified?
Packages
Have we provided a comprehensive
picture of the services of the
packages in upper-level layers?
(continued)
36
The next few slides contains the key things a designer would look for when assessing
the results of Architectural Analysis. An architect would have a more detailed list.
A well-structured architecture encompasses a set of classes, typically organized into
multiple hierarchies
Note: At this point, some of the packages/layers may not contain any classes, and that
is okay. More classes will be identified over time, starting in the next activity, UseCase Analysis.
5 - 36
Checkpoints (cont.)
Checkpoints (cont.)
Classes
Have the key entity classes and
their relationships been 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.?
37
A well-structured class provides a crisp abstraction of something drawn from the

vocabulary of the problem domain or the solution domain.
5 - 37
Review
Review: Architectural Analysis
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.

5 - 38
38
Exercise: Architectural Analysis
Exercise: Architectural Analysis

Given the following:
Some results from the Requirements
discipline:
Problem statement
Use-Case Model main diagram
Glossary
Some architectural decisions:
(textually) The upper-level
architectural layers and their
dependencies
(continued)
39
The goal of this exercise is to jump-start analysis.

References to givens:
Requirements Results: Payroll Requirements Document
Architectural Decisions: Payroll Architecture Handbook, Logical View,

Architectural Analysis section.
Note: This exercise has been tightly scoped to emphasize the Analysis and Design
modeling concepts and reduce the emphasis on architectural issues. Thus, much of
the architecture has been provided to you, rather than asking you to provide it as part
of the exercise. Remember, this is not an architecture course.
5 - 39
Exercise: Architectural Analysis (cont.)

Identify the following:
The key abstractions
(continued)
40
To identify the key abstractions, you can probably concentrate on the Problem
Statement and the Glossary.
Create a class to represent each key abstraction Be sure to include a brief
description for each class. You do not need to allocate the classes to packages. That
will occur in the next module. You do not need to define relationships between the
classes at this point. We will concentrate on class relationships in later modules.
The class diagrams of the upper-level layers and their dependencies should be drawn
using the given textual descriptions.
References to sample diagrams within the course that are similar to what should be
produced are:
Refer to the following slides if needed;
5 - 40
What Are Key Abstractions p. 5-29
Defining Key Abstractions p. 5-30

Produce the following:
Class diagram containing the key
abstractions
Class diagram containing the
upper-level architectural layers
and their dependencies

41
You will need to create two different class diagrams in this solution: one showing the
key abstractions and one showing the architectural layers and their dependencies.
Refer to the following slides if needed;
Package Relationships: Dependency p. 5-8
Example: Key Abstractions p. 5-30
Example: High-level Organization of the Model p. 5-18
5 - 41
Exercise: Review
Exercise: Review
Compare your key abstractions
with the rest of the class
Have the key concepts been
identified?
Does the name of each class
reflect the role it plays?
Compare your class diagram

showing the upper-level layers
Do the package relationships
support the Payroll System
architecture?
5 - 42
42
Module 6
Use-Case Analysis

and Design with UML
Module 6: Use-Case Analysis
Topics
Use-Case Analysis Overview................................................................................. 6-4
Supplement The Use-Case Description ................................................................. 6-6
Find Classes From Use-Case Behavior................................................................... 6-8
Distribute Use-Case Behavior to Classes.............................................................. 6-26
Describe Responsibilities .................................................................................... 6-36
Describe Attributes and Associations................................................................... 6-40
Use-Case Analysis Steps...................................................................................... 6-52
Unify Analysis Classes ......................................................................................... 6-57
Review............................................................................................................... 6-63
6-1
Objectives: Use-Case Analysis
Objectives: Use-Case Analysis

Explain the purpose of Use-Case
Analysis and where in the lifecycle it is
performed
Identify the classes which perform a usecase flow of events
Distribute the use-case behavior to those
classes, identifying responsibilities of the
classes
Develop Use-Case Realizations that
model the collaborations between
instances of the identified classes
Use-Case Analysis is where we identify the initial classes of our system.

As the analysis classes are defined and the responsibilities are allocated to them, we
will also note the usage of architectural mechanisms, more specifically, the usage of
any analysis mechanisms defined in Architectural Analysis.
The analysis classes and the initial Use-Case Realizations are the key model elements
being developed in this activity. These will be refined in the remaining Analysis and
Design activities.
6-2
Module 6 - Use-Case Analysis
Use-Case Analysis in Context
Use-Case Analysis in Context

[Early
Elaboration
Iteration]
[Inception
Perform
Architectural
Synthesis
Define a Candidate
Architecture
Designer
Analyze Behavior
(Optional)
Refine the
Architecture
Define
Components

Use-Case
Analysis
Design the
Database
As you may recall, the above diagram illustrates the workflow that we are using in this
course. It is a tailored version of the Analysis and Design core workflow of the
Rational Unified Process. Use-Case Analysis is an activity in the Analyze Behavior
workflow detail.
At this point, we have made an initial attempt at defining our architecture we have
defined the upper layers of our architecture, the key abstractions, and some key
analysis mechanisms. This initial architecture, along with the software requirements
defined in the Requirements discipline, guides and serves as input to the Use-Case
Analysis activity.
An instance of Use-Case Analysis is performed for each use case to be developed
during an iteration. The focus during Use-Case Analysis is on a particular use case.
In Use-Case Analysis, we identify the analysis classes and define their
responsibilities. As the analysis classes and their responsibilities are defined, we will
also note the usage of any architectural (more specifically, analysis) patterns defined
in Architectural Analysis. The architectural layers and their dependencies may affect
the allocation of responsibility to the defined analysis classes.
The allocation of responsibility is modeled in Use-Case Realizations that describe how
analysis classes collaborate to perform use cases. The Use-Case Realizations will be
refined in the Use-Case Design Model.
6-3
Use-Case Analysis Overview

Use-Case Analysis Overview
Glossary
Project Specific
Guidelines
Supplementary
Specifications
Software
Architecture
Document
Use-Case
Analysis
Use-Case Model
Analysis Model
Analysis Classes
4
Use-Case Analysis is performed by the designer, once per iteration per Use-Case
Realization. What event flows, and therefore what Use-Case Realizations you are
going to work on during the current iteration are defined prior to the start of UseCase Analysis in Architectural Analysis.
Purpose
To identify the classes that perform a use cases flow of events
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
Input Artifacts
Glossary
Use-Case
Use-Case Model
Analysis Class
Analysis Model
Project Specific Guidelines
Resulting Artifacts
Analysis Classes
Analysis Model
Use-Case Realizations
Note: We will not be developing a separate Analysis Model in this course.
6-4
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
The above are the major steps of the Use-Case Analysis activity.
First we must review the use-case descriptions developed in the Requirements
discipline. Chances are, they will need some enhancements to include enough detail
to begin developing a model.
Next, we study the use-case flow of events, identify analysis classes, and allocate usecase responsibilities to the analysis classes. Based on these allocations, and the
analysis class collaborations, we can begin to model the relationships between the
identified analysis classes.
Once the use case has been analyzed, we need to take a good look at the identified
classes, making sure they are thoroughly documented and identify which analysis and
mechanisms they implement.
Last, but not least, we need to make sure that our developed Analysis Model is
consistent.
6-5
Supplement The Use-Case Description



Checkpoints
The purpose of the Supplement the Descriptions of the Use Case is to capture
additional information needed in order to understand the required internal behavior
of the system that may be missing from the Use-Case Description written for the
customer of the system. This information will be used as input to the rest of the steps
in Use-Case Analysis and is used to assist in the allocation of responsibility.
Note: In some cases, we may find that some requirements were incorrect or not wellunderstood. In those cases, the original use-case flow of events should be updated
(for example, iterate back to the Requirements discipline).
6-6
The system
displays a
list of
course
offerings.

The system
retrieves and
displays a list of
current course
offerings from the
course catalog
legacy database.
The description of each use case is not always sufficient for finding analysis classes
and their objects. The customer generally finds information about what happens
inside the system uninteresting, so the use-case descriptions may leave such
information out. In these cases, the use-case description reads like a black-box
description, in which internal details on what the system does in response to an
actors actions is either missing or very summarily described. To find the objects that
perform the use case, you need to have the white box description of what the
system does from an internal perspective.
For example, in the case of the Course Registration System, the student might prefer
to say the system displays a list of course offerings. While this might be sufficient for
the student, it gives us no real idea of what really happens inside the system. In order
to form an internal picture of how the system really works, at a sufficient level of
detail to identify objects, we might need additional information.
Taking the Register for Courses use case as an example, the expanded description
would read as: The system retrieves a list of current course offerings from the course
catalog legacy database. This level of detail gives us a clear idea of what information
is required and who is responsible for providing that information.
6-7
Find Classes From Use-Case Behavior



Checkpoints
Now that we have a more detailed understanding of the Requirements, as

documented in the use case, we can identify the candidate analysis classes for our
system.
The purpose of the Find Classes from Use-Case Behavior step is to identify a
candidate set of model elements (analysis classes) that will be capable of performing
the behavior described in the use case.
6-8
Review: Class
Review: Class
An abstraction
Describes a group of objects with common:
Properties (attributes)
Behavior (operations)
Relationships
Semantics
Class Name
Attributes
Operations

Professor
name
ProfessorId : UniqueId
create()
save()
delete()
change()
As discussed in the Concepts of Object Orientation module, a class is a description of

a group of objects with common properties (attributes), common behavior
(operations), common relationships, and common semantics.
A class is an abstraction in that it:
Emphasizes relevant characteristics.
Suppresses other characteristics.
A class is comprised of three sections:
The first section contains the class name.
The second section shows the structure (attributes).
The third section shows the behavior (operations).
6-9
Review: Use-Case Realization
Review: Use-Case Realization

Use-Case Model
Design Model
Use Case
Sequence Diagrams
Use Case
Class Diagrams
10
As discussed in the Analysis and Design Overview module, a Use-Case Realization

describes how a particular use case is realized within the Design Model in terms of
collaborating objects. A Use-Case Realization in the Design Model can be traced to a
use case in the Use-Case Model. A realization relationship is drawn from the UseCase Realization to the use case it realizes.
A Use-Case Realization is one possible realization of a use case. A Use-Case
Realization can be represented using a set of diagrams (the number and type may
vary by project).
Interaction diagrams (Sequence and/or Collaboration diagrams) can be used to
describe how the use case is realized in terms of collaborating objects. These
diagrams model the detailed collaborations of the Use-Case Realization.
Class diagrams can be used to describe the classes that participate in the
realization of the use case, as well as their supporting relationships. These
diagrams model the context of the Use-Case Realization.
During analysis activities (Use-Case Analysis), the Use-Case Realization diagrams are
outlined. In subsequent design activities (Use-Case Design), these diagrams are
refined and updated according to more formal class interface definitions.
A designer is responsible for the integrity of the Use-Case Realization. He or she must
coordinate with the designers responsible for the classes and relationships employed
in the Use-Case Realization. The Use-Case Realization can be used by class designers
to understand the classs role in the use case and how the class interacts with other
classes. This information can be used to determine or refine the class responsibilities
and interfaces.
6 - 10
Analysis Classes: A First Step Toward Executables
Analysis Classes: A First Step Toward Executables
Use Cases Analysis Design

Classes Elements
Source
Code
Exec
Use-Case Analysis
11
Finding a candidate set of roles is the first step in the transformation of the system
from a mere statement of required behavior to a description of how the system will
work.
The analysis classes, taken together, represent an early conceptual model of the
system. This conceptual model evolves quickly and remains fluid for some time as
different representations and their implications are explored. Formal documentation
can impede this process, so be careful how much energy you expend on maintaining
this mode in a formal sense; you can waste a lot of time polishing a model that is
largely expendable. Analysis classes rarely survive into the design unchanged. Many
of them represent whole collaborations of objects, often encapsulated by subsystems.
Analysis classes are proto-classes, which are essentially "clumps of behavior." These
analysis classes are early conjectures of the composition of the system; they rarely
survive intact into Implementation. Many of the analysis classes morph into
something else later (subsystems, components, split classes, or combined classes).
They provide you with a way of capturing the required behaviors in a form that we
can use to explore the behavior and composition of the system. Analysis classes
allow us to "play" with the distribution of responsibilities, re-allocating as necessary.
6 - 11

The complete behavior of a use case has to
be distributed to analysis classes

12
The technique for finding analysis classes described in this module uses three
different perspectives of the system to drive the identification of candidate classes.
These three perspectives are:
The boundary between the system and its actors
The information the system uses
The control logic of the system
The use of stereotypes to represent these perspectives (for example, boundary,

control, and entity) results in a more robust model because they isolate those things
most likely to change in a system: the interface/environment, the control flow, and
the key system entities. These stereotypes are conveniences used during Analysis that
disappear in Design.
Identification of classes means just that: They should be identified, named, and
described briefly in a few sentences.
The different stereotypes are discussed in more detail throughout this module.
6 - 12
What Is an Analysis Class?
What Is an Analysis Class?
<<entity>>
<<boundary>>
System
information
System
boundary
<<control>>
Use-case
behavior
coordination
<<boundary>>
System
boundary
<<entity>>
System
information

13
Analysis classes represent an early conceptual model for things in the system that
have responsibilities and behavior. Analysis classes are used to capture a first-draft
rough-cut of the Object Model of the system.
Analysis classes handle primarily functional requirements. They model objects from
the problem domain. Analysis classes can be used to represent "the objects we want
the system to support" without making a decision about how much of them to
support with hardware and how much with software.
Three aspects of the system are likely to change:
The boundary between the system and its actors
The information the system uses
The control logic of the system
In an effort to isolate the parts of the system that will change, the following types of
analysis classes are identified with a canned set of responsibilities:
Boundary
Entity
Control
Stereotypes may be defined for each type. These distinctions are used during
Analysis, but disappear in Design.
The different types of analysis classes can be represented using different icons or with
the name of the stereotype in guillemets (<< >>): <<boundary>>, <<
control>>, <<entity>>.
Each of these types of analysis classes are discussed on the following slides.
6 - 13
What Is a Boundary Class?
What Is a Boundary Class?

Intermediates between the interface and
something outside the system
Several Types
User interface classes
System interface classes
Device interface classes
One boundary class per actor/use-case pair

Analysis class
stereotype

Environment Dependent
14
A boundary class intermediates between the interface and something outside the
system. Boundary classes insulate the system from changes in the surroundings (for
example, changes in interfaces to other systems and changes in user requirements),
keeping these changes from affecting the rest of the system.
A system can have several types of boundary classes:
User interface classesClasses that intermediate communication with human

users of the system.
System interface classesClasses that intermediate communication with other

systems. A boundary class that communicates with an external system is
responsible for managing the dialog with the external system; it provides the
interface to that system for the system being built.
Device interface classesClasses that provide the interface to devices which

detect external events. These boundary classes capture the responsibilities of the
device or sensor.
One recommendation for the initial identification of boundary classes is one

boundary class per actor/use-case pair.
6 - 14
The Role of a Boundary Class
The Role of a Boundary Class
<<control>>
Actor 1
<<boundary>>
<<boundary>>
Actor 2
<<entity>>
<<entity>>
Model interaction between the system and its environment

15
A boundary class is used to model interaction between the system's surroundings and
its inner workings. Such interaction involves transforming and translating events and
noting changes in the system presentation (such as the interface).
Boundary classes model the parts of the system that depend on its surroundings. They
make it easier to understand the system because they clarify the system's boundaries
and aid design by providing a good point of departure for identifying related services.
For example, if you identify a printer interface early in the design, you will realize that
you must also model the formatting of printouts.
Because boundary classes are used between actors and the working of the internal
system (actors can only communicate with boundary classes), they insulate external
forces from internal mechanisms and vice versa. Thus, changing the GUI or
communication protocol should mean changing only the boundary classes, not the
entity and control classes.
A boundary object (an instance of a boundary class) can outlive a use-case instance if,
for example, it must appear on a screen between the performance of two use cases.
Normally, however, boundary objects live only as long as the use-case instance.
6 - 15
Example: Finding Boundary Classes
Example: Finding Boundary Classes

One boundary class per actor/use case pair
Student
RegisterForCoursesForm

Course Catalog System
CourseCatalogSystem
16
The goal of Analysis is to form a good picture of how the system is composed, not to
design every last detail. In other words, identify boundary classes only for phenomena
in the system or for things mentioned in the flow of events of the Use-Case
Realization.
Consider the source for all external events and make sure there is a way for the
system to detect these events.
One recommendation for the initial identification of boundary classes is one
boundary class per actor/use-case pair. This class can be viewed as having
responsibility for coordinating the interaction with the actor. This may be refined as a
more detailed analysis is performed. This is particularly true for window-based GUI
applications where there is typically one boundary class for each window, or one for
each dialog box.
In the above example:
6 - 16
The RegisterForCoursesForm contains a Student's "schedule-in-progress." It

displays a list of Course Offerings for the current semester from which the
Student may select courses to be added to his or her Schedule.
The CourseCatalogSystem interfaces with the legacy system that provides the
unabridged catalog of all courses offered by the university. This class replaces the
CourseCatalog abstraction originally identified in Architectural Analysis.
Guidelines: Boundary Class
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!
17
When identifying and describing analysis classes, be careful not to spend too much
time on the details. Analysis classes are meant to be a first cut at the abstractions of
the system. They help to clarify the understanding of the problem to be solved and
represent an attempt at an idealized solution (Analysis has been called idealized
Design).
User Interface Classes: Boundary classes may be used as holding places for GUI
classes. The objective is not to do GUI design in this analysis, but to isolate all
environment-dependent behavior. The expansion, refinement and replacement of
these boundary classes with actual user-interface classes (probably derived from
purchased UI libraries) is a very important activity of Class Design and will be
discussed in the Class Design module. Sketches or screen captures from a userinterface prototype may have been used during the Requirements discipline to
illustrate the behavior and appearance of the boundary classes. These may be
associated with a boundary class. However, only model the key abstractions of the
system; do not model every button, list, and widget in the GUI.
System and Device Interface Classes: If the interface to an existing system or device
is already well-defined, the boundary class responsibilities should be derived directly
from the interface definition. If there is a working communication with the external
system or device, make note of it for later reference during design.
6 - 17
What Is an Entity Class?
What Is an Entity Class?

Key abstractions of the system
Analysis class
stereotype
Use Case
Architectural Analysis
Abstractions
Business-Domain
Model
Glossary
Environment Independent
18
Entity objects represent the key concepts of the system being developed. Entity
classes provide another point of view from which to understand the system, because
they show the logical data structure. Knowing the data structure can help you
understand what the system is supposed to offer its users.
Frequent sources of inspiration for entity classes are the:
Glossary (developed during requirements)
Business-Domain Model (developed during business modeling, if business

modeling has been performed)
Use-case flow of events (developed during requirements)
Key abstractions (identified in Architectural Analysis)
As mentioned earlier, sometimes there is a need to model information about an actor

within the system. This is not the same as modeling the actor (actors are external. by
definition). In this case, the information about the actor is modeled as an entity
class. These classes are sometimes called surrogates.
6 - 18
The Role of an Entity Class
The Role of an Entity Class
<<control>>
Actor 1
<<boundary>>
<<boundary>>
Actor 2
<<entity>>
<<entity>>
Store and manage information in the system

19
Entity classes represent stores of information in the system. They are typically used to
represent the key concepts that the system manages. Entity objects (instances of entity
classes) are used to hold and update information about some phenomenon, such as
an event, a person, or a real-life object. They are usually persistent, having attributes
and relationships needed for a long period, sometimes for the lifetime of the system.
The main responsibilities of entity classes are to store and manage information in the
system.
An entity object is usually not specific to one Use-Case Realization and sometimes it
is not even specific to the system itself. The values of its attributes and relationships
are often given by an actor. An entity object may also be needed to help perform
internal system tasks. Entity objects can have behavior as complicated as that of other
object stereotypes. However, unlike other objects, this behavior is strongly related to
the phenomenon the entity object represents. Entity objects are independent of the
environment (the actors).
6 - 19
Example: Finding Entity Classes
Example: Finding Entity Classes

Use use-case flow of events as input
Key abstractions of the use case
Traditional, filtering nouns approach
Underline noun clauses in the use-case flow of
events
Remove redundant candidates
Remove vague candidates
Remove actors (out of scope)
Remove implementation constructs
Remove attributes (save for later)
Remove operations
20
Taking the use-case flow of events as input, underline the noun phrases in the flow of
events. These form the initial candidate list of analysis classes.
Next, go through a series of filtering steps where some candidate classes are
eliminated. This is necessary due to the ambiguity of the English language. The result
of the filtering exercise is a refined list of candidate entity classes. While the filtering
approach does add some structure to what could be an ad-hoc means of identifying
classes, people generally filter as they go rather than blindly accepting all nouns and
then filtering.
6 - 20
Example: Candidate Entity Classes
Example: Candidate Entity Classes

Register for Courses (Create Schedule)
CourseOffering
Schedule
Student

21
The following are the definitions for each of the classes shown in the above diagram:
CourseOffering: A specific offering for a course, including days of the week and
times.
Schedule: The courses a student has selected for the current semester.
Student: A person enrolled in classes at the university.
As mentioned earlier, sometimes there is a need to model information about an actor
within the system. This is not the same as modeling the actor. (Actors are external by
definition.) These classes are sometimes called surrogates.
For example, a course registration system maintains information about the student
that is independent of the fact that the student also plays a role as an actor in the
system. This information about the student is stored in a Student class that is
completely independent of the actor role the student plays. The Student class will
exist whether or not the student is an actor to the system.
6 - 21
What Is a Control Class?
What Is a Control Class?

Use-case behavior coordinator
More complex use cases generally require one
or more control cases
Analysis class
stereotype
Use Case
Use-case dependent, Environment independent

22
Control classes provide coordinating behavior in the system. The system can perform
some use cases without control classes by using just entity and boundary classes. This
is particularly true for use cases that involve only the simple manipulation of stored
information. More complex use cases generally require one or more control classes
to coordinate the behavior of other objects in the system. Examples of control classes
include transaction managers, resource coordinators, and error handlers.
Control classes effectively decouple boundary and entity objects from one another,
making the system more tolerant of changes in the system boundary. They also
decouple the use-case specific behavior from the entity objects, making them more
reusable across use cases and systems.
Control classes provide behavior that:
Is surroundings-independent (does not change when the surroundings change).
Defines control logic (order between events) and transactions within a use case.
Changes little if the internal structure or behavior of the entity classes changes.
Uses or sets the contents of several entity classes, and therefore needs to
coordinate the behavior of these entity classes.
Is not performed in the same way every time it is activated (flow of events
features several states).
Although complex use cases may need more than one control class it is
recommended, for the initial identification of control classes, that only one control
class be created per use case.
6 - 22
The Role of a Control Class
The Role of a Control Class
<<control>>
Actor 1
<<boundary>>
<<boundary>>
Actor 2
<<entity>>
<<entity>>
Coordinate the use-case behavior

23
A control class is a class used to model control behavior specific to one or more use
cases. Control objects (instances of control classes) often control other objects, so
their behavior is of the coordinating type. Control classes encapsulate use-casespecific behavior.
The behavior of a control object is closely related to the realization of a specific use
case. In many scenarios, you might even say that the control objects "run" the UseCase Realizations. However, some control objects can participate in more than one
Use-Case Realization if the use-case tasks are strongly related. Furthermore, several
control objects of different control classes can participate in one use case. Not all use
cases require a control object. For example, if the flow of events in a use case is
related to one entity object, a boundary object may realize the use case in
cooperation with the entity object. You can start by identifying one control class per
Use-Case Realization, and then refine this as more Use-Case Realizations are
identified, and commonality is discovered.
Control classes can contribute to understanding the system, because they represent
the dynamics of the system, handling the main tasks and control flows.
When the system performs the use case, a control object is created. Control objects
usually die when their corresponding use case has been performed.
6 - 23
Example: Finding Control Classes
Example: Finding Control Classes

In general, identify one control class per
use case.
As analysis continues, a complex use cases
control class may evolve into more than one
class
Student
Course Catalog
System
24
One recommendation is to identify one control class per use case. However, this can
become more than one use case as analysis continues. Remember that more
complex use cases generally require one or more control cases. Each control class is
responsible for orchestrating/controlling the processing that implements the
functionality described in the associated use case.
In the above example, the RegistrationController <<control>> class has been
defined to orchestrate the Register for Courses processing within the system.
6 - 24
Example: Summary: Analysis Classes
Example: Summary: Analysis Classes
Student
Course Catalog
System
Use-Case Model
Design Model
CourseCatalogSystem
CourseOffering
Student
Schedule
25
For each Use-Case Realization, there is one or more class diagrams depicting its
participating classes, along with their relationships. These diagrams help to ensure
that there is consistency in the use-case implementation across subsystem boundaries.
Such class diagrams have been called View of Participating Classes diagrams
(VOPC, for short).
The diagram on this slide shows the classes participating in the Register for Courses
use case. [Note: The Part-time Student and Full-time Student classes from the Rose
solution have been omitted for brevity. (They both inherit from Student.) Class
relationships will be discussed later in this module.]
6 - 25

Supplement the Use-Case Descriptions


Checkpoints
26
Now that we have identified the candidate analysis classes, we need to allocate the
responsibilities of the use case to the analysis classes and model this allocation by
describing the way the class instances collaborate to perform the use case in UseCase Realization.
The purpose of Distribute Use-Case Behavior to Classes is to:
6 - 26
Express the use-case behavior in terms of collaborating analysis classes
Determine the responsibilities of analysis 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
Sequence Diagrams
Use Case
27
You can identify analysis classes responsible for the required behavior by stepping
through the flow of events of the use case. In the previous step, we outlined some
classes. Now it is time to see exactly where they are applied in the use-case flow of
events.
In addition to the identified analysis classes, the Interaction diagram should show
interactions of the system with its actors. The interactions should begin with an actor,
since an actor always invokes the use case. If you have several actor instances in the
same diagram, try keeping them in the periphery of that diagram.
Interactions between actors should not be modeled. By definition, actors are external,
and are out of scope of the system being developed. Thus, you do not include
interactions between actors in your system model. If you need to model interactions
between entities that are external to the system that you are developing (for example,
the interactions between a customer and an order agent for an order-processing
system), those interactions are best included in a Business Model that drives the
System Model.
Guidelines for how to distribute behavior to classes are described on the next slide.
6 - 27
Guidelines: Allocating Responsibilities to Classes
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)
28
The allocation of responsibilities in analysis is a crucial and sometimes difficult

activity. These three stereotypes make the process easier by providing a set of canned
responsibilities that can be used to build a robust system. These predefined
responsibilities isolate the parts of the system that are most likely to change: the
interface (boundary classes), the use-case flow of events (control classes), and the
persistent data (entity classes).
6 - 28
Guidelines: Allocating Responsibilities to Classes (cont.)
Guidelines: Allocating Responsibilities to Classes (cont.)

Who has the data needed to perform the
responsibility?
If one class has the data, put the responsibility with
the data
If multiple classes have the data:
Put the responsibility with one class and add a
relationship to the other
Create a new class, put the responsibility in the
new class, and add relationships to classes
needed to perform the responsibility
Put the responsibility in the control class, and add
relationships to classes needed to perform the
responsibility
29
A driving influence on where a responsibility should go is the location of the data

needed to perform the operation.
The best case is that there is one class that has all the information needed to perform
the responsibility. In that case, the responsibility goes with the data (after all, that is
one of the tenets of OO data and operations together).
If this is not the case, the responsibility may need to be allocated to a third party
class that has access to the information needed to perform the responsibility. Classes
and/or relationships might need to be created to make this happen. Be careful when
adding relationships all relationships should be consistent with the abstractions
they connect. Do not just add relationships to support the implementation without
considering the overall effect on the model. Class relationships will be discussed later
in this module.
When a new behavior is identified, check to see if there is an existing class that has
similar responsibilities, reusing classes where possible. You should create new classes
only when you are sure that there is no existing object that can perform the behavior.
6 - 29
The Anatomy of Sequence Diagrams
The Anatomy of Sequence Diagrams

This is a sample script.
Client Object
Supplier Object
:Client
:Supplier
Object Lifeline
1: PerformResponsibility
Message
Focus of Control
Reflexive Message
1.1: PerformAnother
Responsibility
Hierarchical Message
Numbering
30
A Sequence diagram describes a pattern of interaction among objects, arranged in a

chronological order. It shows the objects participating in the interaction and the
messages they send.
An object is shown as a vertical dashed line called the "lifeline." The lifeline
represents the existence of the object at a particular time. An object symbol is drawn
at the head of the lifeline, and shows the name of the object and its class separated
by a colon and underlined.
A message is a communication between objects that conveys information with the
expectation that activity will result. A message is shown as a horizontal solid arrow
from the lifeline of one object to the lifeline of another object. For a reflexive
message, the arrow starts and finishes on the same lifeline. The arrow is labeled with
the name of the message and its parameters. The arrow may also be labeled with a
sequence number.
Focus of control represents the relative time that the flow of control is focused in an
object, thereby representing the time an object is directing messages. Focus of
control is shown as narrow rectangles on object lifelines.
Hierarchical numbering bases all messages on a dependent message. The
dependent message is the message whose focus of control the other messages
originate in. For example, message 1.1 depends on message 1.
Scripts describe the flow of events textually.
6 - 30
Example: Sequence Diagram
Example: Sequence Diagram

: Student
: RegisterForCoursesForm
: RegistrationController
: CourseCatalogSystem
: Schedule
: Student
: Course Catalog
1: // create schedule( )
2: // get course offerings( )
3: // get course offerings(forSemester)
Create a new
schedule
A list of the available

course offerings for this
semester are displayed
A blank schedule
is displayed for the
students to select
offerings

5: // display course offerings( )
6: // display blank schedule( )
7: // select 4 primary and 2 alternate offerings( )

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

Sequence Diagram: Register for

Courses / Register for Courses - Basic
Flow (Submit Schedule)
31
The above example shows the object interactions to support the Create a Schedule
sub-flow of the Register for Courses use case. Some of the rationale for responsibility
allocation is as follows:
The RegisterForCoursesForm knows what data it needs to display and how to

display it. It does not know where to go to get it. That is one of the
RegistrationControllers responsibilities.
Only the RegisterForCoursesForm interacts with the Student actor.
The RegistrationController understands how Students and Schedules are related.
Only the CourseCatalogSystem class interacts with the external legacy Course
Catalog System.
Note the inclusion of the actors. This is important as the diagram explicitly
models what elements communicate with the outside world.
6 - 31
The Anatomy of Collaboration Diagrams
The Anatomy of Collaboration Diagrams

Client Object
Link
Supplier Object
:Client
PerformResponsibility
:Supplier
Message

32
A Collaboration diagram describes a pattern of interaction among objects. It shows

the objects participating in the interaction by their links to each other and the
messages that they send to each other.
An object is represented in one of three ways:
Objectname:Classname
ObjectName
:ClassName
A link is a relationship between objects that can be used to send messages. In
Collaboration diagrams, a link is shown as a solid line between two objects. An object
interacts with, or navigates to, other objects through its links to these objects. A link is
defined as an instance of an association.
A message is a communication between objects that conveys information with the
expectation that activity will result. In Collaboration diagrams, a message is shown as
a labeled arrow placed near a link. This means that the link is used to transport or
otherwise implement the delivery of the message to the target object. The arrow
points along the link in the direction of the target object (the one that receives the
message). The arrow is labeled with the name of the message and its parameters. The
arrow may also be labeled with a sequence number to show the sequence of the
message in the overall interaction. Sequence numbers are often used in Collaboration
diagrams because they are the only way of describing the relative sequencing of
messages. A message can be unassigned, meaning that its name is a temporary string
that describes the overall meaning of the message. You can later assign the message
by specifying the operation of the message's destination object. The specified
operation will then replace the name of the message.
6 - 32
Example: Collaboration Diagram
Example: Collaboration Diagram

5: // display course offerings( )
6: // display blank schedule( )
: Course Catalog
: RegisterForCoursesForm
: CourseCatalogSystem

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

9: // create with offerings( )
: Schedule
: Student

33
The above example shows the collaboration of objects to support the Register for
Courses use case, Create a Schedule subflow. It is the Collaboration diagram
equivalent of the Sequence diagram shown earlier.
6 - 33
One Interaction Diagram Is Not Good Enough
One Interaction Diagram Is Not Good Enough

Basic Flow
Alternate Flow 1
Alternate Flow 2
Alternate Flow 3
Alternate Flow 4
Alternate Flow 5
Alternate Flow n
AF3
AF1
AF2

34
Model most of the flow of events to make sure that all requirements on the
operations of the participating classes are identified. Start with describing the basic
flow, which is the most common or most important flow of events. Then describe
variants such as exceptional flows. You do not have to describe all the flow of events,
as long as you employ and exemplify all operations of the participating objects. Very
trivial flows can be omitted, such as those that concern only one object.
Examples of exceptional flows include the following:
Error handling. What should the system do if an error is encountered?
Time-out handling. If the user does not reply within a certain period, the use case
should take some special measures.
Handling of erroneous input to the objects that participate in the use case (for
example, incorrect user input).
Examples of optional flows include the following:
The actor decides-from a number of options what the system is to do next.
The subsequent flow of events depends on the value of stored attributes or

relationships.
The subsequent flow of events depends on the type of data to be processed.
You can use either Collaboration or Sequence diagrams.
6 - 34
Collaboration Diagrams vs. Sequence Diagrams
Collaboration Diagrams vs. Sequence Diagrams

Collaboration
Diagrams
Sequence Diagrams
Show the explicit
sequence of messages
Better for visualizing
overall flow
Better for real-time
specifications and for
complex scenarios
Show relationships in
addition to interactions
Better for visualizing
patterns of collaboration
Better for visualizing all
of the effects on a given
object
Easier to use for
brainstorming sessions

35
Sequence diagrams and Collaboration diagrams express similar information, but show
it in different ways.
Collaboration diagrams emphasize the structural collaboration of a society of objects
and provide a clearer picture of the patterns of relationships and control that exist
amongst the objects participating in a use case. Collaboration diagrams show more
structural information (that is, the relationships among objects). Collaboration
diagrams are better for understanding all the effects on a given object and for
procedural design.
Sequence diagrams show the explicit sequence of messages and are better for realtime specifications and for complex scenarios. A Sequence diagram includes
chronological sequences, but does not include object relationships. Sequence
numbers are often omitted in Sequence diagrams, in which the physical location of
the arrow shows the relative sequence. On Sequence diagrams, the time dimension is
easier to read, operations and parameters are easier to present, and a larger number
of objects are easier to manage than in Collaboration diagrams.
Both Sequence and Collaboration diagrams allow you to capture semantics of the
use-case flow of events; they help identify objects, classes, interactions, and
responsibilities; and they help validate the architecture.
6 - 35


Checkpoints
36
At this point, analysis classes have been identified and use-case responsibilities have
been allocated to those classes. This was done on a use-case-by-use-case basis, with
a focus primarily on the use-case flow of events. Now it is time to turn our attention
to each of the analysis classes and see what each of the use cases will require of
them. A class and its objects often participate in several Use-Case Realizations. It is
important to coordinate all the requirements on a class and its objects that different
Use-Case Realizations may have.
The ultimate objective of these class-focused activities is to to document what the
class knows and what the class does. The resulting Analysis Model gives you a big
picture and a visual idea of the way responsibilities are allocated and what such an
allocation does to the class collaborations. Such a view allows the analyst to spot
inconsistencies in the way certain classes are treated in the system, for example, how
boundary and control classes are used.
The purpose of the Describe Responsibilities step is namely to describe the
responsibilities of the analysis classes.
6 - 36
What are responsibilities?
How do I find them?
Interaction Diagram
:Client
:Supplier
// PerformResponsibility
Class Diagram
Supplier
// PerformResponsibility
37
A responsibility is a statement of something an object can be asked to provide.

Responsibilities evolve into one (or more) operations on classes in design; they can be
characterized as:
The actions that the object can perform.
The knowledge that the object maintains and provides to other objects.
Responsibilities are derived from messages on Interaction diagrams. For each
message, examine the class of the object to which the message is sent. If the
responsibility does not yet exist, create a new responsibility that provides the
requested behavior.
Other responsibilities will derive from nonfunctional requirements. When you create
a new responsibility, check the nonfunctional requirements to see if there are related
requirements that apply. Either augment the description of the responsibility, or
create a new responsibility to reflect this.
Analysis class responsibilities can be documented in one of two ways:
As analysis operations: When this approach is chosen, it is important that
some sort of naming convention be used. This naming convention indicates that
the operation is being used to describe the responsibilities of the analysis class
and that these analysis operations WILL PROBABLY change/evolve in design.
Textually: In this approach, the analysis class responsibilities are documented in
the description of the analysis classes.
For the OOAD course example, we will use the analysis operation approach. The
naming convention that will be used is that the analysis operation name will be
preceded by '//'.
6 - 37
Example: View of Participating Classes (VOPC) Class Diagram

Example: View of Participating Classes (VOPC) Class Diagram
<<control>>
<<entity>>
Student
// get tuition()
// add schedule()
// get schedule()
// delete schedule()
// has pre-requisites()
// get course offerings()

// get current schedule()
// delete current schedule()
// submit schedule()
// is registration open?()
// save schedule()
// create schedule with offerings()
// update schedule with new selections()
<<entity>>
Schedule
<<boundary>>
CourseCatalogSystem
// commit()
// select alternate()
// remove offering()
// level()
// cancel()
// get cost()
// delete()
// submit()
// save()
// any conflicts?()
// create with offerings()
// update with new selections()

// get course offerings()
<<boundary>>
// display course offerings()
// display blank schedule()
// update offering selections()
38
The View of Participating Classes (VOPC) class diagram contains the classes whose
instances participate in the Use-Case Realization Interaction diagrams, as well as the
relationships required to support the interactions. We will discuss the relationships
later in this module. Right now, we are most interested in what classes have been
identified, and what responsibilities have been allocated to those classes.
6 - 38
Maintaining Consistency: What to Look For
Maintaining Consistency: What to Look For

In order of criticality
Redundant responsibilities across classes
Disjoint responsibilities within classes
Class with one responsibility
Class with no responsibilities
Better distribution of behavior
Class that interacts with many other classes

39
Examine classes to ensure they have consistent responsibilities. When a classs

responsibilities are disjoint, split the object into two or more classes. Update the
Interaction diagrams accordingly.
Examine classes to ensure that there are not two classes with similar responsibilities.
When classes have similar responsibilities, combine them and update the Interaction
diagrams accordingly.
Sometimes a better distribution of behavior becomes evident while you are working
on another Interaction diagram. In this case, go back to the previous Interaction
diagram and redo it. It is better (and easier) to change things now than later in design.
Take the time to set the diagrams right, but do not get hungup trying to optimize the
class interactions.
A class with only one responsibility is not a problem, per se, but it should raise
questions on why it is needed. Be prepared to challenge and justify the existence of
all classes.
6 - 39



Checkpoints
40
Now that we have defined the analysis classes and their responsibilities, and have an
understanding of how they need to collaborate, we can continue our documentation
of the analysis classes by describing their attributes and associations.
The purpose of Describe Attributes and Operations is to:
6 - 40
Identify the other classes on which the analysis class depends.
Define the events in other analysis classes that the class must know about.
Define the information that the analysis class is responsible for maintaining.
Review: What Is an Attribute?
Review: What Is an Attribute?

<<stereotype>>
ClassName
Attribute : Type = InitValue
In analysis, do not spend

time on attribute signatures
<<entity>>
CourseOffering
attribute
number : String = "100"

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

41
Attributes are used to store information. They are atomic things with no
responsibilities.
The attribute name should be a noun that clearly states what information the attribute
holds. The description of the attribute should describe what information is to be
stored in the attribute; this can be optional when the information stored is obvious
from the attribute name.
During Analysis, the attribute types should be from the domain, and not adapted to
the programming language in use. For example, in the above diagram, enum will
need to be replaced with a true enumeration that describes the days the
CourseOffering is offered (for example, MWF or TR).
6 - 41
Finding Attributes
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

42
Sources of possible attributes:

Domain knowledge
Requirements
Glossary
Domain Model
Business Model
Attributes are used instead of classes where:
Only the value of the information, not it's location, is important
The information is uniquely "owned" by the object to which it belongs; no other
objects refer to the information.
The information is accessed by operations that only get, set, or perform simple
transformations on the information; the information has no "real" behavior other
than providing its value.
If, on the other hand, the information has complex behavior, or is shared by two or
more objects, the information should be modeled as a separate class.
Attributes are domain-dependent. (An object model for a system includes those
characteristics that are relevant for the problem domain being modeled.)
Remember, the process is use-case-driven. Thus, all discovered attributes should
support at least one use case. For this reason, the attributes that are discovered are
affected by what functionality/domain is being modeled.
6 - 42
Review: What Is an Association?
Review: What Is an Association?

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

<<entity>>
Schedule
<<entity>>
Course
43
Associations represent structural relationships between objects of different classes;

they connect instances of two or more classes together for some duration.
You can use associations to show that objects know about other objects. Sometimes,
objects must hold references to each other to be able to interact; for example, to
send messages to each other. Thus, in some cases, associations may follow from
interaction patterns in Sequence diagrams or Collaboration diagrams.
Most associations are simple (exist between exactly two classes), and are drawn as
solid paths connecting pairs of class symbols. Ternary relationships are also possible.
Sometimes a class has an association to itself. This does not necessarily mean that an
instance of that class has an association to itself; more often, it means that one
instance of the class has associations to other instances of the same class.
An association may have a name that is placed on, or adjacent to the association
path. The name of the association should reflect the purpose of the relationship and
be a verb phrase. The name of an association can be omitted, particularly if role
names are used.
Avoid names like "has" and "contains," as they add no information about what the
relationships are between the classes.
6 - 43
Finding Relationships
Finding Relationships
PerformResponsibility
Collaboration
Diagram
:Client
:Supplier
Link
Client
Class
Diagram
Client
Supplier
0..*
0..*
Prime suppliers
Supplier
PerformResponsibility()
Association
Relationship for every link!

44
To find relationships, start studying the links in the Collaboration diagrams. Links
between classes indicate that objects of the two classes need to communicate with
one another to perform the use case. Thus, an association or an aggregation is
needed between the associated classes.
Reflexive links do not need to be instances of reflexive relationships; an object can
send messages to itself. A reflexive relationship is needed when two different objects
of the same class need to communicate.
The navigability of the relationship should support the required message direction. In
the above example, if navigability was not defined from the Client to the Supplier,
then the PerformResponsibility message could not be sent from the Client to the
Supplier.
Focus only on associations needed to realize the use cases; do not add associations
you think "might" exist unless they are required based on the Interaction diagrams.
Remember to give the associations role names and multiplicities. You can also
specify navigability, although this will be refined in Class Design.
Write a brief description of the association to indicate how the association is used, or
what relationships the association represents.
6 - 44
Review: What Is Aggregation?
Review: What Is Aggregation?

A special form of association that models a
whole-part relationship between an
aggregate (the whole) and its parts
Whole/aggregate
Part
<<entity>>
Student
<<entity>>
Schedule 0..*

<<entity>>
0..2 CourseOffering
0..*
45
Aggregation is a stronger form of association which is used to model a whole-part

relationship between model elements. The whole/aggregate has an aggregation
association to the its constituent parts. A hollow diamond is attached to the end of an
association path on the side of the aggregate (the whole) to indicate aggregation.
Since aggregation is a special form of association, the use of multiplicity, roles,
navigation, and so forth is the same as for association.
Sometimes a class may be aggregated with itself. This does not mean that an instance
of that class is composed of itself (that would be silly). Instead, it means that one
instance if the class is an aggregate composed of other instances of the same class.
Some situations where aggregation may be appropriate include:
An object is physically composed of other objects (for example, car being

physically composed of an engine and four wheels).
An object is a logical collection of other objects (for example, a family is a

collection of parents and children).
An object physically contains other objects (for example, an airplane physically

contains a pilot).
In the example on the slide, the relationship from Student to Schedule is modeled as
an aggregation, because a Schedule is inherently tied to a particular Student. A
Schedule outside of the context of a Student makes no sense in this Course
Registration System. The relationship from Schedule to CourseOffering is an
association because CourseOfferings may appear on multiple Schedules.
6 - 45
Association or Aggregation?
Association or Aggregation?
If two objects are tightly bound by a whole-part
relationship
The relationship is an aggregation.
Car
Door
0..2,4
If two objects are usually considered as

independent, although they are often linked
The relationship is an association.
Car
Door
0..2,4
When in doubt use association

46
Aggregation should be used only where the "parts" are incomplete outside the context
of the whole. If the classes can have independent identity outside the context
provided by other classes, or if they are not parts of some greater whole, then the
association relationship should be used.
When in doubt, an association is more appropriate. Aggregations are generally
obvious. A good aggregate should be a natural, coherent part of the model. The
meaning of aggregates should be simple to understand from the context. Choosing
aggregation is only done to help clarify; it is not something that is crucial to the
success of the modeling effort.
The use of aggregation versus association is dependent on the application you are
developing. For example, if you are modeling a car dealership, the relationship
between a car and the doors might be modeled as aggregation, because the car
always comes with doors, and doors are never sold separately. However, if you are
modeling a car parts store, you might model the relationship as an association, as the
car (the body) might be independent of the doors.
6 - 46
What Are Roles?
What Are Roles?

The face that a class plays in the
association
<<entity>>
CourseOffering
<<entity>>
Professor
instructor
<<entity>>
Department
Department Head
Role Name
<<entity>>
Course
preRequisites

47
Each end of an association has a role in relationship to the class on the other end of
the association. The role specifies the face that a class presents on each side of the
association. A role must have a name, and the role names on opposite sides of the
association must be unique. The role name should be a noun indicating the
associated object's role in relation to the associating object.
The use of association names and role names is mutually exclusive: one would not
use both an association name and a role name. For each association, decide which
conveys more information.
The role name is placed next to the end of the association line of the class it
describes.
In the case of self-associations, role names are essential to distinguish the purpose for
the association.
In the above example, the Professor participates in two separate association
relationships, playing a different role in each.
6 - 47
Review: Multiplicity
Review: Multiplicity
Unspecified
Exactly One
Zero or More
0..*
Zero or More
One or More
1..*
Zero or One (optional scalar role)
0..1
Specified Range
2..4
Multiple, Disjoint Ranges

2, 4..6
48
For each role you can specify the multiplicity of its class. Multiplicity is the number of
objects of the class that can be associated with one object of the other class.
Multiplicity is indicated by a text expression on the association line. The expression is
a comma-separated list of integer ranges. A range is indicated by an integer (the lower
value), two dots, and an integer (the upper value). A single integer is a valid range.
You may also specify narrower limits such as 2..4.
During Analysis, assume a multiplicity of 0..* (zero to many) unless there is some
clear evidence of something else.
A multiplicity of zero implies that the association is optional. When you use this
notation, make sure this is what you mean. If an object might not be there,
operations that use the association will have to adjust accordingly.
Within multiplicity ranges, probabilities may be specified. Thus, if the multiplicity is
0..*, and is expected to be between 10 and 20 in 85% of the cases, make note of it.
This information will be of great importance during Design. For example, if persistent
storage is to be implemented using a relational database, narrower limits will help
better organize the database tables.
6 - 48
What Does Multiplicity Mean?
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>>
CourseOffering
0..*
<<entity>>
Course
0..*
preRequisites

0..3
49
Multiplicity lets you know the lower and the upper bound number of
relationships that a given object can have with another object. Many times you
do not know what the maximum number of instances may be, and you will use
the * to specify that this number is unknown.
The most important question that multiplicity answers: Is the association is

mandatory? A lower bound number that is greater than zero indicates that the
relationship is mandatory.
This example indicates that a course object can be related to zero or more course
offerings. You can tell that the relationship is optional because the lower bound
number is zero. The upper bound number of the relationship is unknown, as
indicated by the *. If you read the association the other way, you will see that a
given course offering object can be related to only one course. This relationship is
mandatory and indicates that it is not possible for a course offering object to exist
without an associated course object.
6 - 49
Example: Multiple Associations
Example: Multiple Associations

primaryCourses
<<entity>>
Schedule
<<entity>>
CourseOffering
alternateCourses
<<entity>>
Schedule
add student to
remove student from
<<entity>>
CourseOffering
Multiple associations must reflect multiple roles.

50
There can be multiple associations between the same two classes, but they should
represent distinct relationships, and DIFFERENT ROLES; they should not be just for
invoking different operations.
If there is more than one association between two classes then they MUST be named.
It is unusual to find more than one association between the same two classes.
Occurrences of multiple associations should be carefully examined.
To determine if multiple associations are appropriate, look at instances of the classes.
ClassA and ClassB have two associations between them, Assoc1 and Assoc2. If an
instance of ClassA has a link with two SEPARATE instances of ClassB, then multiple
associations are valid.
In the above example, the top diagram is an appropriate use of multiple associations,
but the bottom diagram is not. In the valid case, two associations are required
between Schedule and CourseOffering, as a Schedule can contain two kind of
CourseOfferings, primary and alternate. These must be distinguishable, so two
separate associations are used. In the invalid case, the two relationships represent
two operations of CourseOffering, not two roles of CourseOffering.
Remember, Students and CourseOfferings are related via the Schedule class. Students
are enrolled in a CourseOffering if there is a relationship between the Students
Schedule and the CourseOffering.
6 - 50
Example: VOPC: Finding Relationships
Example: VOPC: Finding Relationships

<<control>>
<<boundary>>
1
1
0..1
currentSchedule
0..1
<<entity>>
<<entity>>
Student
1
0..*

Schedule
0..*
primaryCourses
0..4
<<entity>>
CourseOffering
51
The diagram on this slide shows classes that collaborate to perform the Register for
Courses use case, along with their relationships. As noted earlier, this type of
diagram is called a View of Participating Classes (VOPC) diagram.
The relationships in this diagram are defined using the Interaction diagrams for the
Register for Courses use case provided earlier in this module.
Rationale for relationships:
From RegisterForCoursesForm to RegistrationController: There is one controller

for each Schedule being created (for example, each Student registration session).
From RegistrationController to Schedule. A RegistrationController deals with one

Schedule at a time (the current Schedule for the Student registering for courses).
Note the use of the currentSchedule role name. Note: Many
RegisterForCoursesForms can be active at one time (for different
sessions/students), each with their own RegistrationController.
From Schedule to CourseOffering: Each Schedule may have up to four primary

Course Offerings and up to two alternate Course Offerings. A particular Course
Offering may appear on many Schedules as either a primary or an alternate.
From Student to Schedule: A Student may have many schedules or none. A

Schedule is only associated with a single Student and does not exist without a
Student to be associated to.
6 - 51



Checkpoints
52
At this point, we have a pretty good understanding of the analysis classes, their
responsibilities, and the collaborations required to support the functionality described
in the use cases.
Now we must look into how each of the defined analysis classes implements the
analysis mechanisms identified in Architectural Analysis.
The purpose of the Qualify Analysis Mechanisms step is to:
Identify analysis mechanisms (if any) used by the class.
Provide additional information about how the class applies the analysis
mechanism.
For each such mechanism, qualify as many characteristics as possible, giving ranges
where appropriate, or when there is still much uncertainty.
Different architectural mechanisms will have different characteristics, so this
information is purely descriptive and need only be as structured as necessary to
capture and convey the information. During Analysis, this information is generally
quite speculative, but the capturing activity has value, since conjectural estimates can
be revised as more information is uncovered. The analysis mechanism characteristics
should be documented with the class.
6 - 52
Review: Why Use Analysis Mechanisms?
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
dont even know what database we are
going to be using?
That is why we have a persistence

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

analysis, and to improve its consistency by providing designers with a
shorthand representation for complex behavior.
53
An analysis mechanism represents a pattern that constitutes a common solution to a

common problem. These mechanisms may show patterns of structure, patterns of
behavior, or both. They are used during Analysis to reduce the complexity of
Analysis, and to improve its consistency by providing designers with a shorthand
representation for complex behavior. Analysis mechanisms are primarily used as
placeholders for complex technology in the middle and lower layers of the
architecture. By using mechanisms as placeholders in the architecture, the
architecting effort is less likely to become distracted by the details of mechanism
behavior.
Mechanisms allow the Analysis effort to focus on translating the functional
requirements into software concepts without bogging down in the specification of
relatively complex behavior needed to support the functionality but which is not
central to it. Analysis mechanisms often result from the instantiation of one or more
architectural or analysis patterns. Persistence provides an example of analysis
mechanisms. A persistent object is one that logically exists beyond the scope of the
program that created it. During analysis, we do not want to be distracted by the
details of how we are going to achieve persistence.This gives rise to a persistence
analysis mechanism that allows us to speak of persistent objects and capture the
requirements we will have on the persistence mechanism without worrying about
what exactly the persistence mechanism will do or how it will work.
Analysis mechanisms are typically, but not necessarily, unrelated to the problem
domain, but instead are "computer science" concepts. As a result, they typically
occupy the middle and lower layers of the architecture. They provide specific
behaviors to a domain-related class or component, or correspond to the
implementation of cooperation between classes and/or components.
6 - 53

Collect all analysis mechanisms in a list
Draw a map of the client classes to the
analysis mechanisms
Identify characteristics of the analysis
mechanisms

54
In Architectural Analysis, the possible analysis mechanisms were identified and

defined.
From that point on, as classes are defined, the required analysis mechanisms and
analysis mechanism characteristics should be identified and documented. Not all
classes will have mechanisms associated with them. Also, it is not uncommon for a
client class to require the services of several mechanisms.
A mechanism has characteristics, and a client class uses a mechanism by qualifying
these characteristics. This is to discriminate across a range of potential designs. These
characteristics are part functionality, and part size and performance.
6 - 54
Example: Describing Analysis Mechanisms
Example: Describing Analysis Mechanisms

Analysis class to analysis mechanism map
Analysis Class
Analysis Mechanism(s)
Student
Persistency, Security
Schedule
Persistency, Security
CourseOffering
Persistency, Legacy Interface
Course
Persistency, Legacy Interface
Distribution

55
As analysis classes are identified, it is important to identify the analysis mechanisms

that apply to the identified classes.
The classes that must be persistent are mapped to the persistency mechanism.
The classes that are maintained within the legacy Course Catalog system are mapped
to the legacy interface mechanism.
The classes for which access must be controlled (that is, control who is allowed to
read and modify instances of the class) are mapped to the security mechanism.
Note: The legacy interface classes do not require additional security as they are readonly and are considered readable by all.
The classes that are seen to be distributed are mapped to the distribution mechanism.
The distribution identified during analysis is that which is specified/implied by the
user in the initial requirements. Distribution will be discussed in detail in the
Describe Distribution module. For now, just take it as an architectural given that all
control classes are distributed for the OOAD course example and exercise.
6 - 55
Example: Describing Analysis Mechanisms (cont.)
Example: Describing Analysis Mechanisms (cont.)

Analysis mechanism characteristics
Persistency for Schedule class:
Granularity: 1 to 10 Kbytes per product
Volume: up to 2,000 schedules
Access frequency
Create: 500 per day
Read: 2,000 access per hour
Update: 1,000 per day
Delete: 50 per day
Other characteristics
56
The above is just an example of how the characteristics for an analysis mechanism
would be documented for a class. For scoping reasons, the analysis mechanisms and
their characteristics are not provided for all of the analysis classes.
6 - 56



Checkpoints
57
At this point, we have a pretty good understanding of the analysis classes, their
responsibilities, the analysis mechanisms they need to implement, and the
collaborations required to support the functionality described in the use cases.
Now we must review our work and make sure that it is as complete and as consistent
as possible before moving on to the architecture activities.
The purpose of Unify Analysis Classes is to ensure that each analysis class represents a
single well-defined concept, with non-overlapping responsibilities.
6 - 57

Course
Catalog
System
RegisterFor
CoursesForm
RegisterFor
CoursesForm
Registration
Controller
Registration
Controller
Register for
Courses
Course
Offering
Schedule
Course
Catalog
System
CloseRegistration
Form
Close
Registration
Student
Student
Course
Offering
Billing
System
Course
Offering
CloseRegistration Student
Controller
Schedule
Course
Catalog
System
Schedule
CloseRegistration
Controller
CloseRegistration
Form
Billing
System
58
Before the Design work can be done, the analysis classes need to be filtered to ensure
that a minimum number of new concepts have been created.
Different use cases will contribute to the same classes. In the example above, the
classes CourseCatalogSystem, CourseOffering, Schedule and Student participate in
both the Register for Courses and Close Registration use cases.
A class can participate in any number of use cases. It is therefore important to
examine each class for consistency across the whole system.
Merge classes that define similar behaviors or that represent the same phenomenon.
Merge entity classes that define the same attributes, even if their defined behavior is
different; aggregate the behaviors of the merged classes.
When you update a class, you should update any supplemental use-case
descriptions (described earlier in this module), where necessary. Sometimes an
update to the original Requirements (that is, use cases) may be necessary, but this
should be controlled, as the Requirements are the contract with the user/customer,
and any changes must be verified and controlled.
6 - 58
Evaluate Your Results
Evaluate Your Results
Glossary
Design Model
Supplementary
Specification
Analysis Classes

Use-Case Model
59
We now have a pretty good feeling about our Analysis Model. Now it is time to
review our work for completeness and consistency.
Be sure to:
Verify that the analysis classes meet the functional requirements made on the
system.
Verify that the analysis classes and their relationships are consistent with the
collaborations they support.
It is very important that you evaluate your results at the conclusion of the Use-Case
Analysis.
The number of reviews, the formality of the reviews, and when they are performed
will vary, depending on the process defined for the project.
6 - 59



Checkpoints
60
This is where the quality of the model up to this point is assessed against some very
specific criteria.
In this module, we will concentrate on those checkpoints that the designer is most
concerned with (that is, looks for).
6 - 60
Checkpoints: Analysis Classes
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)
61
The above checkpoints for the analysis classes might be useful.

Note: All checkpoints should be evaluated with regards to the use cases being
developed for the current iteration.
The class should represent a single well-defined abstraction. If not, consider splitting
it.
The class should not define any attributes or responsibilities that are not functionally
coupled to the other attributes or responsibilities defined by that class.
The classes should offer the behavior the Use-Case Realizations and other classes
require.
The class should address all specific requirements on the class from the requirement
specification.
Remove any attributes and relationships if they are redundant or are not needed by
the Use-Case Realizations.
6 - 61
Checkpoints: Use-Case Realizations
Checkpoints: Use-Case Realizations

Have all the main and/or sub-flows
been handled, including exceptional
cases?
Have all the required objects been
found?
Has all behavior been unambiguously
distributed to the participating objects?
Has behavior been distributed to the
right objects?
Where there are several Interaction
diagrams, are their relationships clear
and consistent?
62
The above checkpoints for the Use-Case Realizations might be useful.

Note: All checkpoints should be evaluated with regards to the use cases being
developed for the current iteration.
The objects participating in a Use-Case Realization should be able to perform all of
the behavior of the use case.
If there are several Interaction diagrams for the Use-Case Realization, it is important
that it is easy to understand which Interaction diagrams relate to which flow of
events. Make sure that it is clear from the flow of events description how the
diagrams are related to each other.
6 - 62
Review
Review: Use-Case Analysis
What is the purpose of Use-Case Analysis?
What is an analysis class? Name and
describe the three analysis stereotypes.
What is a Use-Case Realization?
Describe some considerations
when allocating responsibilities
to analysis classes.
How many Interaction diagrams
should be produced during
Use-Case Analysis?
63
6 - 63
Exercise: Use-Case Analysis
Exercise: Use-Case Analysis

Given the following:
Use-Case Model, especially the
use-case flows of events
Key abstractions/classes
The Supplementary Specification
The possible analysis
mechanisms
(continued)
64
The goal of this exercise is to identify classes that must collaborate to perform a use
case, allocate the use-case responsibilities to those classes, and diagram the
collaborations.
Good sources for the analysis classes are the Glossary and any analysis classes defined
during Architectural Analysis.
References to the givens:
6 - 64
Use-Case Model: Payroll Requirements Document, Use-Case Model section.
Key abstractions: Payroll Exercise Solution, Architectural Analysis section.
Supplementary Specification: Payroll Requirements Document, Supplementary

Specification section.
The analysis mechanisms we are concentrating on in this course include:

persistency, distribution, security, and legacy interface). See the Payroll
Architecture Handbook, Architectural Mechanisms, Analysis Mechanisms section
for more information on these analysis mechanisms.
Exercise: Use-Case Analysis (cont.)

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
Analysis class attributes and
relationships
Analysis class analysis mechanisms (continued)
65
When identifying analysis classes from the use-case flows of events, use the analysis
stereotypes for guidance (boundary, control, and entity).
Be sure to define the identified classes. These definitions become very important as
you start to allocate responsibilities to those classes.
The relationships to be identified are those needed to support the collaborations
modeled in the use-case Interaction diagrams. The attributes to be identified are the
obvious properties of the identified classes. More attributes may be defined during
later Class Design.
For each identified analysis class, determine if any of the analysis mechanisms apply.
To make this decision, the Supplementary Specification may be needed.
Refer to the following slides if needed:
Example: Finding Boundary Classes p. 6-16
Example: Finding Entity Classes p. 6-20
Example: Finding Control Classes p. 6-24
Describe Responsibilities p. 6-37
Finding Attributes p. 6-42
Finding Relationships p. 6-44
Example: Describing Analysis Mechanisms p. 6-55
6 - 65

Produce the following for a
particular use case:
Use-Case Realization Interaction
diagram for at least one of the usecase flows of events
VOPC class diagram, containing
the analysis classes, their
stereotypes, responsibilities,
attributes, and relationships
Analysis class to analysis
mechanism map
66
Start with diagramming the basic flow and then do the other sub-flows if you have
time.
The Interaction diagrams may be collaboration or Sequence diagrams. On an
Interaction diagram, sending a message to an object means that you are allocating
responsibility for performing that task to the object.
Be sure to use the // naming convention for responsibilities.
Refer to the following slides if needed:
6 - 66
Review: What is a Use-Case Realization? p. 6-10
Example: Sequence Diagram p. 6-31
Example: Collaboration Diagram p. 6-33
Example: VOPC Finding Relationship p. 6-52
Exercise: Review
Exercise: Review
Compare your Use-Case
Realization with the rest of the class
Do the Interaction diagrams carry out
the use-case flow of events?
Are the stereotypes behaving properly?
Is each association supported by a
link?
Does each association have multiplicity
assigned?
Have role names been assigned? Do
they accurately represent the face the
class plays in the relationship?

Payroll System
67
After completing a model, it is important to step back and review your work. Some
helpful questions are the following:
Has the use case behavior been successfully represented in the model? In other
words, is the flow of events the same in the specifications as it is in the model?
Has there been any significant behavior that was added? Removed? Changed?
The model should reflect the intent of the Use-Case Specifications.
Is each stereotype behaving properly? Are actors only interfacing with boundary
classes? Are control classes controlling the use-case flow of events only? Are any
classes doing operations on data (attributes) that are not owned by that class?
6 - 67
6 - 68

Dev475 Stud Vol1 PDF

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Dev475 Stud Vol1 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Rational

Printed in the United States of America.

This manual prepared by:

Course Objectives.......................................................................................... 0-3

Module 1 Best Practices of Software Engineering

Practice 1: Develop Iteratively ....................................................................... 1-7

Module 2 Concepts of Object Orientation

What Is Object Technology? .......................................................................... 2-4

Module 3 Requirements Overview

Introduction .................................................................................................. 3-3

Module 4 Analysis and Design Overview

Key Concepts ................................................................................................ 4-5

Module 5 Architectural Analysis

Architectural Analysis Overview ..................................................................... 5-4

Module 6 Use-Case Analysis

Use-Case Analysis Overview .......................................................................... 6-4

Mastering Object-Oriented Analysis

DEV475 Mastering Object-Oriented Analysis and Design with UML

Your expectations for this course

Mastering Object Oriented Analysis and Design with UML

Module 0 - About This Course

DEV475 Mastering Object-Oriented Analysis and Design with UML

Course Objectives (cont.)

Course Objectives (cont.)

Mastering Object Oriented Analysis and Design with UML

Module 0 - About This Course

Mastering Object Oriented Analysis and Design with UML

DEV475 Mastering Object-Oriented Analysis and Design with UML

An exposure to object technology including, how to:

Read a use-case model

Prerequisites can be achieved through attendance in

Mastering Object Oriented Analysis and Design with UML

Module 0 - About This Course

Rational University Curriculum

DEV475 Mastering Object-Oriented Analysis and Design with UML

Rational University Curriculum

Rational University Curriculum

Module 0 - About This Course

Rational University Curriculum

Rational University Curriculum

Mastering Object Oriented Analysis and Design with UML

DEV475 Mastering Object-Oriented Analysis and Design with UML

Module 0 - About This Course

Other Sources of Information

Other Sources of Information

Rational Unified Process

Rational Web Site

Rational Developer Network

Mastering Object Oriented Analysis and Design with UML

DEV475 Mastering Object-Oriented Analysis and Design with UML

Mastering Object Oriented Analysis and Design with UML

Mastering Object-Oriented Analysis

DEV475 Mastering Object-Oriented Analysis and Design with UML

Mastering Object Oriented Analysis and Design with UML

Module 1 - Best Practices of Software Engineering

Module 1 Content Outline

Module 1 Content Outline

Mastering Object Oriented Analysis and Design with UML

DEV475 Mastering Object-Oriented Analysis and Design with UML

Symptoms of Software Development Problems

Symptoms of Software Development Problems

Module 1 - Best Practices of Software Engineering