Object Oriented Analysis and Design
Using the UML
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
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.
Management Management Environment Environment TestTest Analysis & Design Analysis & Design
Preliminary
Iteration(s) Iter.
#1 Iter.
#2 Iter.
#n Iter.
#n+1 Iter.
#n+2 Iter.
#m Iter.
#m+1
Configuration & Change Mgmt Configuration & Change Mgmt Requirements Requirements
Elaboration
Elaboration TransitionTransition Inception
Inception ConstructionConstruction
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.
Analysis and Design in Context
Note: Analysis and Design taken ‘together.’ WHY?????
Olden days versus Modern Times…..
Supplementary Specification
Use-Case Model Design Model
Architecture Document
Analysis and Design
Glossary
Analysis and Design Overview
Input Artifacts – from Requirements Workflow
Ultimately, we wish to produce a Design 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)
• Class diagrams and
• Interaction Diagrams do this for us…
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 is found in 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.
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
Our Design Model will take the artifacts from Analysis Modeling (analysis classes) and
create
Design classes (static view) and
Use Cases realizations (dynamic view) – showing how objects collaborate in ‘realizing’ each use
case.
Analysis & Design Overview Topics
Key Concepts – Get a common vocabulary
Recall: Use Cases are developed using the language (jargon) of the end-user / other
stakeholders….
Have a Glossary / Domain Model already…
Analysis & Design Workflow Overview
Analysis Versus Design
Analysis
Focus on understanding the problem
Idealized design
(Generalized) Behavior
System structure
Functional requirements
Lip service for non-
functional requirements
A small model
Design
Focus on
understanding the solution
Operations and Attributes
Performance
Close to real code
Object lifecycles
Non-functional requirements
A large model
Difference is on emphases
Analysis: understanding the problem; develop a visual model of What you are trying to build
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.’
We are capturing Requirements! (the Whats!)
Get rough cut at objects that from our system but focusing on behavior and therefore encapsulation.
Some authors (and me) include an Analysis Model here –
sometimes considered first part of Design (preliminary 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
Goal of Design
Refine Analysis Model with a goal of creating a
Design Model that will facilitate our moving “quickly and seamlessly” into coding. (Morph Analysis
Classes into Design classes and more!)
Design Model will help us adapt to implementation (and deployment) environments.
Note that design model elements are abstractions of code / implementation.
Analysis Design Solution
In modeling, we will start with an object model that resembles the real world
(analysis) then,
Find more abstract (but more fundamental) solutions to a more general problem
(design)
Top Down
Bottom Design Classes Up
Subsystems
Use Cases
Analysis and Design is not Top-Down not or Bottom-Up
Use cases come in from the left and
define a middle level
Analysis Classes are not defined in a
top-down or bottom-up pattern;
they are in the middle .
Defining Subsystems is moving ‘up;’ defining design classes is moving down.
Analysis Classes
Design Model
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!!
A Use-Case Realization ties use cases from the use-case model and ‘analysis classes’ to design classes and related design entities
and relationships of a Design Model.
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
Sequence Diagrams
Use Case Collaboration Diagrams
What is a Use-Case Realization?
Use-Case Model Design Model
Use Case 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.”
A use case realization can be represented using a set of diagrams which model the context
(realizes relationship)
Process View Deployment View Logical View
Use-Case View
Implementation View
End-user
Functionality Programmers
Software management
Performance Scalability Throughput
System integrators
System topology Delivery, installation communication System engineering Analysts/Designers
Structure
Software Architecture: The “4+1 View” Model
This diagram describes how Rational Software Corporation models software architecture Projects have multiple stakeholders – each with unique concerns and views.
Rational has defined the 4+1 architectural model – a series of simplified descriptions (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
Analysis & Design Overview Topics
Key Concepts
Analysis & Design Workflow Overview
Architect
Designer
Architectural Analysis
Architecture Reviewer
Review the Design Review the Architecture
Use-Case Analysis
Architectural
Design Describe
Concurrency Describe Distribution
Class Design Subsystem Design Use-Case
Design Design
Reviewer
Analysis and Design Workflow
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.
Design activities center around architecture – the main focus of early design iterations.
We here, however, will concentrate on the activities of the Designer.
(Analysis Modeling)
(Interaction Diagrams And Class Diagrams) Use Case Realizations
Read and study remaining slides on your own. (This does not mean ignore them, please…)
The Architect (very briefly)
Establishes the overall structure for each architectural view:
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
The Designer (briefly)
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.
Is usually responsible for Use-Case
Realizations, in order to ensure the overall consistency of how a particular use case
The Database Designer (briefly)
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.
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.
Architect
Software Architecture Document
Design Model
Designer Use-Case
Realization
Package/
Subsystem
Class
Database Designer Data Model
Architecture Reviewer
Design Reviewer
Workers and Their Responsibilities
Architect: Establishes overall structure of each of the views.
Decomposition; Breadth
Designer: Responsible for the operations, attributes, and relationships of one or several classes and how
they are implemented; Design packages; UC Realizations
DB Designer: Designs tables, stored procs Indexes, etc.
needed to store, maintain persistent data
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?