Object Oriented Analysis and Design Using The UML

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.

Analysis and Design in Context
Inception Elaboration Construction Transition
Requirements
Analysis & Design
Test
Configuration & Change Mgmt
Management
Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
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…..

Requirements  Analysis and Design
Input Artifacts – from Requirements Workflow
Ultimately, we wish to produce a Design Model
Design Model
Use-Case Model Analysis
and Design
Architecture
Document
Glossary Supplementary
Specification
(additional ‘features’ &
non-functional requirements…)
Data Model
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
 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.
 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.

Analysis & Design Overview Topics
 Key Concepts
 Analysis & Design Workflow Overview

Analysis Versus Design Difference is on emphases
 Analysis  Design
 Focus on understanding  Focus on
the problem understanding the
solution
 Idealized design
 Operations and
 (Generalized) Behavior Attributes
 Separation of Concerns  Performance,
 System structure Efficiency…
 Functional requirements  Close to real code
 Object lifecycles
 Some recognition for non-  Non-functional
functional requirements
Analysis: understanding the problem; develop a visual model of
What you are trying to build
requirements in detail
 A small model  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.’
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’

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.

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 Design Model

(realizes relationship)
Use Case Use-Case Realization

What is a Use-Case Realization?
Interaction Diagrams
Use Case 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.
Class Diagrams

Software Architecture Model: The “4+1 Architectural View”
Logical View Implementation View
End-user
Analysts/Designers Programmers
Structure Functionality
Software management
Use-Case View
Process View Deployment View

System integrators System engineering
Performance System topology
Scalability Delivery, installation
Throughput communication
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 view.
A project may document all views, a subset, or additional views. But EACH VIEW is
complete
OOAD Using from
the UML - Analysis the Overview,
and Design perspective
v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
of specific stakeholder(s).
15
Analysis & Design Overview Topics
 Key Concepts
 Analysis & Design Workflow Overview

Analysis and Design Workflow
Architectural
Analysis
Architectural Describe Describe Review the Architecture

Architect Design Concurrency Distribution Architecture Reviewer
Subsystem Design
Use-Case
Analysis
Use-Case Review the
Designer (Analysis Modeling) Design Design Design
Reviewer
(Interaction Diagrams
Use Case Realizations  And Class Diagrams) 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.
Look at the activities of the architect and the designer (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.

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

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!

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
Software Architecture persistent data
Document Design
Reviewer
Database Designer Data Model
Designer: Responsible for the operations, attributes, and Architecture
relationships of one or several classes and how Reviewer
they are implemented; Design packages; UC Realizations
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?


Object Oriented Analysis and Design Using The UML

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Object Oriented Analysis and Design Using The UML

Uploaded by

Copyright:

Available Formats

Object Oriented Analysis and Design

Using the UML

Analysis and Design Overview

OOAD Using the UML - Analysis and Design Overview, v 4.2

OOAD Using the UML - Analysis and Design Overview, v 4.2

The purposes of Analysis and Design are:

Note: Analysis and Design taken ‘together.’ WHY?????

OOAD Using the UML - Analysis and Design Overview, v 4.2

Ultimately, we wish to produce a Design Model

OOAD Using the UML - Analysis and Design Overview, v 4.2

OOAD Using the UML - Analysis and Design Overview, v 4.2

OOAD Using the UML - Analysis and Design Overview, v 4.2

 Focus on translating the functional requirements into software

 Some authors include an Analysis Model here –

 Note that design model elements are

 Design Model constitutes the ‘Solution Space’

 A Use-Case Realization maps use cases from the use-case model to

 A Use-Case Realization specifies what classes must be built, how

OOAD Using the UML - Analysis and Design Overview, v 4.2

 A use-case realization in the design model can be traced to

A “realization relationship” is drawn from the use-case realization

Use-Case Model Design Model

Use Case Use-Case Realization

OOAD Using the UML - Analysis and Design Overview, v 4.2

Use Case Sequence Diagrams Collaboration Diagrams

A use case realization can be represented using a set

OOAD Using the UML - Analysis and Design Overview, v 4.2

Logical View Implementation View

Process View Deployment View

OOAD Using the UML - Analysis and Design Overview, v 4.2

Architectural Describe Describe Review the Architecture

OOAD Using the UML - Analysis and Design Overview, v 4.2

 This information is maintained in the Data

OOAD Using the UML - Analysis and Design Overview, v 4.2

 The Design reviewer plans and conducts the

 Can be project manager in consultation with

OOAD Using the UML - Analysis and Design Overview, v 4.2

OOAD Using the UML - Analysis and Design Overview, v 4.2

You might also like