Object Oriented Analysis and Design Using the UML

(1)

Object Oriented Analysis and Design

Using the UML

Analysis and Design Overview

(2)

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

Objectives: Analysis and Design Overview

 Introduce the analysis and design process,

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

(3)

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

(4)

Supplementary Specification

(additional ‘features’ &

non-functional requirements…)

Use-Case Model Design Model

Data Model

Architecture Document

Analysis and Design

Glossary

Input Artifacts – from Requirements Workflow

Ultimately, we wish to produce a Design Model

Requirements  Analysis and

Design

(5)

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

(6)

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.

(7)

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.

(8)

Analysis Versus Design

 Analysis

 Focus on understanding the problem

 Idealized design

 (Generalized) Behavior

 Separation of Concerns

 System structure

 Functional requirements

 Some recognition for non- functional requirements

 A small model

 Design

 Focus on understanding the solution

 Operations and Attributes

 Performance, Efficiency…

 Close to real code

 Object lifecycles

 Non-functional

requirements in detail

 A large model

Difference is on emphases

Analysis: understanding the problem; develop a visual model of What you are trying to build

(9)

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, abstractions 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…

(10)

Goal of Design

 Refine the Analysis Model with goal to 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’

(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 UP, 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 software 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.

(12)

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

(realizes relationship)

(13)

Class Diagrams

Sequence Diagrams

Use Case Collaboration Diagrams

What is a Use-Case Realization?

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

Interaction Diagrams

(14)

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 Model: The “4+1 Architectural View”

This diagram describes how architectural views model software architecture.

Projects have multiple stakeholders – each with unique concerns and views.

Here we define 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 from the perspective of specific stakeholder(s).

(15)

Analysis & Design Overview Topics

 Key Concepts

 Analysis & Design Workflow Overview

(16)

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 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!!)

(Analysis Modeling)

(Interaction Diagrams And Class Diagrams) Use Case Realizations 

(17)

The Software Architect

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.

(18)

The Designer

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

 Software Architect works carefully here to

ensure compatibility!!

(19)

The Database Designer

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

(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!

(21)

DB Designer: Designs tables, stored procedures, Indexes, etc. needed to store, maintain persistent data

Architect

Software Architecture Document

Design Model

Designer Use-Case

Realization

Package/

Subsystem

Class

Database Designer Data Model

Architecture

Design Reviewer

Workers and Their Responsibilities

Architect: Establishes overall structure of each of the views.

Decomposition; Breadth

Designer: Responsible for the operations, attributes, and

(22)