Object-Oriented Analysis

& Design
面向对象的分析与设计
修佳鹏
xiujiapeng@bupt.edu.cn
计算机学院（国家示范性软件学院）
北京邮电大学
Part 1.Introduction

• Chapter 1. Object-Oriented Analysis and Design

• Chapter 2. Iterative, Evolutionary and Agile
• Chapter 3. Case Studies
Chapter 1. Object-Oriented Analysis and Design

Objectives:

1. Describe the book goals and scope

2. Define object-oriented analysis and design (OOAD).
3. Illustrate a brief OOAD example
4. Overview UML and visual agile modeling
Chapter 1. Object-Oriented Analysis and Design

Software Engineering Theory (Abstract)

OOAD

Implementation
Java Programming
(Concrete)
(OOP，C++/C#/Java)

4
What Will You Learn? Is it Useful?

5
The Most Important Learning Goal

• A critical, fundamental ability in OOAD is to skillfully assign

responsibilities to software component.
• Responsibility Assignment is emphasized because it strongly
influences the robustness, maintainability, and reusability of
software components.
• GRASP patterns，nine fundamental principles in object design and
responsibilities assignment.
What is Analysis and Design

• Analysis emphasizes an investigation of the problem

rather than how a solution is defined (WHAT?).For
example , if a new online trading system is desired , how
will it be used ? What are its functions?——Do the right
thing.
• Design emphasizes a logical solution, how the system
fulfills the requirements rather than its implementation
(HOW?).——Do the thing right.
 Analysis and Design

• Division between A&D is fuzzy

• A&D activities exist on a continuum(连续体)
• Some practitioners can classify an activity as
analysis while others put it into design category

More analysis oriented More design oriented

-what -how
-requirements -logical solution
-investigation of domain -understanding and
-understanding of problem description of solution

8
What is Object-Oriented Analysis and Design

• The essence of OOAD is to consider a problem

domain and logical solution from the perspective of
objects (things, concepts, or entities).
• OO Analysis emphasizes finding and describing the
objects – or concepts- in the problem domain.
• OO Design emphasizes defining logical software objects
(things, concepts, or entities) that have attributes and
methods and how they collaborate to fulfill the
requirements.
OO Analysis

• OOA requires domain knowledge and OOA expertise

• Hence, there is a need for both a domain expert and an OO
analysis expert
• Domain expert is always right about decisions relating to
problem domain
• If you are lucky, these two experts are the same person

• OOA identifies
• Concepts in the problem domain
• Relationships among those concepts
• Attributes of those concepts

10
OO Design

• OOD defines a logical software solution for the problem

• Solution is defined based on findings of OOA phase.
• It includes definition of class methods that represent a logical
software solution.
• New concepts, attributes or relationship among concepts are
often discovered during design phase. They are iteratively
reflected back into analysis phase.

11
 Object vs. Function Oriented Analysis

Library Info
System

O-O A&D Structured A&D

Decompose by objects and concepts Decompose by functions and processes

System
Catalog Librarian

Book Library Record Loans Add Resource Report Fines

12
 OOAD

Larman

Requirements Collaboration Code

Use Cases Conceptual System Class Design
Analysis Diagrams &
Model Behavior Diagrams
Test

OO Analysis OO Design Construction

Requirements
Study

13
 Flight Information System Example

Domain Plane
visualization of
Concept:Plane,Flight, tailNumber domain concept
Pilot……

public class Plane

{
representation in an private String tailNumber;
object-oriented
programming language public List getFlightHistory()
{...}
}
A Short Example: A Dice Game

• The "Dice game" software simulates a player rolling two

dice. If the total is seven,they win; otherwise,they lose.
• We use this example to present a few key steps and
diagrams in OOA/D.
• The OOAD Process:
• Define use cases
• Define domain model
• Define interaction diagrams
• Define design class diagrams

15
Define use cases

• Requirements analysis may include stories or scenarios

of how people use the application; these can be written
as use cases, for Use Case Model is a very popular tool
in requirements analysis.

Use Case Play a Dice Game

Primary Player
Actor
Description Player requests to roll the dice.
System Presents results:. If the dice
total is seven, player wins;
otherwise player loses.
16
Define a domain model

• Object-oriented analysis is concerned with creating a

description of the domain from the perspective of objects .
• There is an identification of the concepts , attributes , and
associations that are considered noteworthy.
• The result can be expressed in a domain model that shows
the noteworthy domain concepts or objects.

17
Define a domain model

• A domain model is not a description of software objects.

• It is a visualization of the concepts or mental models of a
real-world.
• It is also called a conceptual object model.

18
Define Interaction Diagrams

• Object-oriented design is concerned with defining software

objects their responsibilities and collaborations.
• A common notation to illustrate these collaborations is the
sequence diagram ( a kind of UML interaction diagram) .
• It shows the flow of messages between software objects , and
the invocation of methods.
Define Interaction Diagrams
Define Design Class Diagrams

• In addition to a dynamic view of collaborating objects shown in

interaction diagram, a static view of the class definitions is usefully
which illustrates the attributes and methods of the classes.
What is the UML?

• “The Unified Modeling Language is a visual

language for specifying, constructing and documenting
the artifacts of systems” [OMG03a].
• It is a notational system aimed at modeling systems
using OO concepts
• not a methodology
• not a process

22
Three Ways to Apply UML

• UML as sketch
– Informal and incomplete diagrams
• often hand sketched on whiteboards
– created to explore difficult parts of the problem or solution
space, exploiting the power of visual languages.

• UML as blueprint
– Relatively detailed design diagrams used either for
1. reverse engineering to visualize and better understanding
existing code in UML diagrams
2. code generation (forward engineering).

23
Three Ways to Apply UML

• UML as programming language

– Complete executable specification of a software system in
UML.
– Executable code will be automatically generated, but is not
normally seen or modified by developers; one works only in
the UML “programming language.”
– This use of UML requires a practical way to diagram all
behavior or logic (probably using interaction or state
diagrams),
– Still under development in terms of theory, tool robustness
and usability

24
Agile Modeling and UML

• Agile modeling emphasizes UML as sketch; this is a

common way to apply the UML , often with a high return
on the investment of time (which is typically short ) .
• UML tools can be useful, but people should also
consider an agile modeling approach to applying UML.
Three Perspectives to Apply UML

• 1. Conceptual perspective: the diagrams are interpreted as

describing things in a situation of the real World or domain of
interest.
• 2. Specification (software ) perspective: the diagrams (using
the same notation as in the conceptual perspective) describe
software abstractions or components with specifications and
interfaces, but no commitment to a particular implementation
( for example , not specifically a class in C # or Java ).
• 3. Implementation ( software ) perspective: the diagrams
describe software implementations in a particular technology
( such as Java ).
Three Perspectives to Apply UML
Three Perspectives to Apply UML

• To keep things clear, this book will use class-related

terms consistent with the UML and the UP , as follows :
• Conceptual class: real-world concept or thing . A conceptual or
essential perspective. The UP Domain Model cont ai ns
conceptual classes.
• Software class: a class representing a specification or
implementation perspective of a software component , regardless
of the process or method.
• Implementation class: a class implemented in a specific OO
language such as Java.
UML 1 and UML 2

• This is not primarily a https://www.omg.org/spec/UML

UML notation book, but
one that explores the
larger picture of applying
th UML patterns , and an
iterative process in the
context of OOA / D and
related requirements
analysis.
• This text is based on UML
2; the notation used here
was carefully reviewed
with key members of the
UML 2 specification team.
UML Diagrams

Nodes: Actor, Use (case)

Use Case Diagrams
Links: Involvement, Extension, Inclusion, Generalization
Nodes: Class
Class Diagrams
Links: Association, Generalization
Nodes: Object
Interaction Diagrams
Links: Message, Lifeline
Nodes: State, Sub-State
State Diagrams
Links: Transition
Nodes: Activity
Activity Diagrams
Links: Guard, Synchronization
Nodes: Package
Package Diagrams
Links: Dependency
Nodes: Processor, Node
Deployment Diagrams
Links: Dependency

30
UML Diagrams
Visual Modeling is a Good Thing

• At the risk of stating the blindingly obvious, drawing or

reading UML implies we are working more visually ,
exploiting our brains strength to quickly grasp symbols ,
units, and relationships in( predominantly ) 2D box-and-
line notations.
• Diagrams help us see or explore more of the big picture
and relationships between analysis or software elements,
while allowing us to ignore or hide uninteresting details.
Part 1.Introduction

• Chapter 1. Object-Oriented Analysis and Design

• Chapter 2. Iterative, Evolutionary and Agile
• Chapter 3. Case Studies

33
What is and isn’t Covered in the Case Studies?

• Focuses on the core application logic layer

minor focus
User Interface
explore how to connect to
other layers

primary focus
of case studies
application Sale Payment
logic layer explore how to
design objects

other layers or secondary

Logging ... Database Access ...
components focus

34
Case Study Strategy

• Iteraltive Development + Iterative Learning

Iteration 1

Iteration 2
Introduces just those
analysis and design Iteration 3
skills related to Additional analysis and
iteration one. design skills introduced.
Likewise.

35
 Case One: The NextGen POS System

• POS – Point Of Sale （收银机）

• A computerized application used to record sales and handle
payments
• It interfaces to various service applications
• Bank (credit card system)
• Inventory control
• Third party tax calculator
• Increasingly must support multiple and varied terminals and
interfaces
• A commercial POS system that will serve different clients with
disparate needs in terms of business rule processing.

36
 Case Two: The Monopoly Game System

• 大富翁游戏
• 买地
• 盖房子
• 银行存钱/投资股票
• 获得奖励/惩罚
• 收/交过路费
• 幸运卡/机会卡
• 进监狱

37
Homework

• Review the Chapter 1 of the textbook.

• Preview the Chapter 2 and 3 of the textbook.
• Read the textbook 1.8 History by yourself and reply to
the content of the forum.
• Participate in forum discussions.
• Review the main key steps and diagrams in OOA/D.
• You can find related resources in Section1.9.