Object Oriented Analysis and Design Using the UML Version 4.2

Object Oriented Analysis and Design
Using the UML
Analysis and Design Overview
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
1
Objectives: Analysis and Design Overview
 Introduce the analysis and design process,
including roles, artifacts and workflow
 Understand the difference between analysis
and design
 Note that the details of each of the Analysis
and Design activities will be covered later.
 Present a context for the detailed analysis
and design activities.
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
2
Analysis and Design in Context
Inception Elaboration
Construction
Transition
Requirements
Analysis & Design
Test
Configuration & Change Mgmt
Management
Environment
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
The purposes of Analysis and Design are:
To transform the requirements into a design of the
system to-be.
To evolve a robust architecture for the system.
Note: Analysis and Design taken ‘together.’ WHY?????
Olden days versus Modern Times…..
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
3
Iter.
#m
Iter.
#m+1
Requirements  Analysis and Design
Input Artifacts – from Requirements Workflow
Ultimately, we wish to produce a Design Model
Use-Case Model
Design Model
Analysis
and Design
Architecture
Document
Glossary
Supplementary
Specification
(additional ‘features’ &
non-functional requirements…)
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
Data Model
4
Analysis and Design Overview (continued)
 Design model is an abstraction of source
code and serves as the blue print for
Construction.
 Design Model consists of Design Classes
structured into Design packages
 Design Model also contains descriptions as to
how objects of these design classes interact to
perform Use Cases (Use Case Realizations)
 The Use Case Realizations are:
• Class diagrams and
• Interaction Diagrams
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
5
Analysis and Design Overview (continued)
 Design activities are centered around the
notion of an architecture.
 Production and validation of this architecture
is the main focus of early design iterations.
 Architectural design takes place during
Elaboration.
 Architecture is represented by a number of
architectural views that capture the major
structural design decisions.
 Architectural views are the abstractions
or simplifications of the entire design, in
which important characteristics are made
more visible by leaving details aside.
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
6
Analysis and Design Overview (continued)
 We will create an Analysis Model as the first
part of Analysis and Design.
 We create Analysis Classes from Use Cases and
other sources of requirements (Vision, Domain
Model, …)
 Our Design Model will then take the artifacts
from Analysis Modeling (analysis classes) and
create our Use Case Realizations:
 Static View: Design classes, and
 Dynamic View: showing how objects
collaborate in ‘realizing’ each flow in a use
case.
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
7
Analysis & Design Overview Topics
 Key Concepts
 Analysis & Design Workflow Overview
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
8
Analysis Versus Design
Difference is on emphases
 Design
 Analysis
 Focus on understanding
the problem
 Idealized design
 (Generalized) Behavior
 Separation of Concerns
 System structure
 Functional requirements
 Some recognition for nonAnalysis: understanding the problem; develop a visual model of
functional requirements
What you are trying to build
 A small model
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
9
 Focus on
understanding the
solution
 Operations and
Attributes
 Performance,
Efficiency…
 Close to real code
 Object lifecycles
 Non-functional
requirements in detail
 A large model
Goal of Analysis
 Understand the problem; try to build a visual model of what
you are trying to do independent of implementation or
technology concerns.
 Focus on translating the functional requirements into software
concepts Note: Nothing in Use Cases says ‘Objects.’
 Get rough cut at objects that from our system but focusing on
behavior and separation of Concerns…
 Some authors include an Analysis Model here –
  I consider analysis modeling as the prelude to architectural
design.




Sometimes considered first part of Design;
Sometimes merely considered part of Design itself.
In some circles, there is ‘only’ Requirements and then Design…
Many ‘organizations’ tailor activities to their own ‘interpretations.’
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
10
Goal of Design
 Refine Analysis Model with a goal of creating
a Design Model that will facilitate our moving
“quickly and seamlessly” into more detailed
design and implementation. (Morph Analysis
Classes into Design ‘components,’
specific classes or other…)
 Note that design model elements are
abstractions of code / implementation.
 Design Model constitutes the ‘Solution Space’
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
11
Use Case Realization
 A Use Case Realization describes how a particular use case
is implemented in the design model in terms of collaborating
objects.
  In the RUP, each use case has a use case realization!!
  They are one-to-one.
 A Use-Case Realization maps use cases from the use-case
model to design model in terms of classes and other related
design entities and relationships.
 A Use-Case Realization specifies what classes must be built,
how they collaborate (relationships, dependencies…), and the
messages passed between objects necessary to implement
each use case
 Use Case Realizations have a static component and a dynamic
component.
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
12
What is a Use-Case Realization?
 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 use-case realization
to the use case it “realizes.”
Use-Case Model
(realizes relationship)
Use Case
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
Design Model
Use-Case Realization
13
What is a Use-Case Realization?
Interaction Diagrams
Use Case
Class Diagrams
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
Sequence Diagrams
Collaboration Diagrams
A use case realization can be represented
using a set of diagrams which model the
context of the collaboration – class diagrams
and
the interactions of these collaborations:
communications and sequence diagrams.
14
Software Architecture Model: The “4+1 Architectural View”
Logical View
Analysts/Designers
Structure
Implementation View
End-user
Functionality
Programmers
Software management
Use-Case View
Process View
System integrators
Performance
Scalability
Throughput
Deployment View
System engineering
System topology
Delivery, installation
communication
This diagram describes how Rational Software Corporation models
software architecture.
Projects have multiple stakeholders – each with unique concerns and views.
Rational has defined a 4+1 architectural view – a series of simplified descriptions
views (abstractions) from particular perspectives – omitting entities not relevant to this vie
A project may document all views, a subset, or additional views. But EACH VIEW is
OOAD
Using the UMLfrom
- Analysis and
Design
Overview, v 4.2
complete
the
perspective
of specific stakeholder(s).
15
Copyright  1998-1999 Rational Software, all rights reserved
Analysis & Design Overview Topics
 Key Concepts
 Analysis & Design Workflow Overview
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
16
Analysis and Design Workflow
Architectural
Analysis
Describe
Architectural
Concurrency
Design
Architect
Designer
Review the Architecture
Architecture Reviewer
Subsystem Design
Use-Case
Analysis
(Analysis Modeling)
Describe
Distribution
Review the
Design
Use-Case
Design
(Interaction Diagrams
Use Case Realizations And Class Diagrams)
Design
Reviewer
Class
Design
Remember, we start off with the Use Case Model and Supplementary info (Glossary;
Domain model; business model…) from Requirements Workflow and ultimately end up
with a Design Model – an abstraction of the source code produced via an Analysis and
Design Workflow.
Design activities center around architecture – the main focus of early design
iterations.
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyrightat
 1998-1999
Rational Software, all
reserved
Look
the activities
ofrightsthe
architect and the 17designer (roles!!)
The Architect (See RUP Textbook)
Establishes the overall structure for each
architectural view: This includes layers, if a
layered approach…
 the decomposition of the view,
 the grouping of elements, and the interfaces between
these major groupings.
 In contrast with the other workers, the Architect's
view is one of breadth, as opposed to depth
 Frequently, the architect is the most experienced
member of the team. (likely a good idea)
 Architect must constantly observe all design
activities to ensure that they are compatible with
the overall architecture.
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
18
The Designer (See RUP Textbook)
 Defines the responsibilities, operations,
attributes, and relationships of one or several
classes and determines how they should be
adjusted (modified, refined, morphed into
other design / implementation artifacts (like
packages, subsystems, etc.)) to support
the implementation environment with the
software architecture.
 Must be compatible with overall architecture!
  Is usually responsible for Use-Case
Realizations, in order to ensure the overall
consistency of how a particular use case is
realized using design elements.
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
19
The Database Designer (See RUP Textbook)
 Defines the tables, indexes, views,
constraints, triggers, stored procedures,
table spaces or storage parameters, and
other database-specific constructs needed
to store, retrieve, and delete persistent
objects.
 Will be familiar with design / implementation
support from, say, APIs, such as java.sql,
etc.
 This information is maintained in the Data
Model.
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
20
Reviewers
 Architecture Reviewer plans and conducts
the formal reviews of the software
architecture in general.
 The Design reviewer plans and conducts
the formal reviews of the design model.
 Can be project manager in consultation with
these other roles…Team efforts!
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
21
Workers and Their Responsibilities
Architect: Establishes overall
structure of each of the views.
Decomposition; Breadth
Use-Case
Realization
Architect
Designer
Package/
Subsystem
Design Model
Class
DB Designer: Designs tables,
stored procedures, Indexes,
etc. needed to store, maintain
persistent data
Software Architecture
Document
Design
Reviewer
Database Designer
Data Model
Designer: Responsible for the operations, attributes, and
relationships of one or several classes and how
they
are implemented; Design packages; UC Realizations
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
22
Architecture
Reviewer
Review: Analysis and Design Overview
 What is the purpose of Analysis and Design?
 What are the input and output artifacts?
 Name and briefly describe the 4+1 Views of
Architecture.
 What is the difference between Analysis and
Design?
 What is the purpose of Architectural Analysis?
 What is the purpose of Use-Case Analysis?
 What are the major responsibilities of the
Architect, Developer, Database workers?
OOAD Using the UML - Analysis and Design Overview, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
23