1

Introduction to Object Oriented

Analysis and Design
 2

Overview

 Why do we need Modelling ”Blue prints” ?

 Object Oriented Analysis and Design - OOAD.

 Object Oriented vs. Functional Oriented Analysis and Design.

 Unified Modelling Language - UML.

 UML Models.

 Steps to OOAD.
 3

The Need for Software Blueprints

 Knowing an object-oriented language and having access to a library is

necessary but not sufficient in order to create object software.

 In between a nice idea and a working software, there is much more than
programming.

 Analysis and design provide software “blueprints”, illustrated by a modeling

language.

 Blueprints serve as a tool for thought and as a form of communication with

others.

 These blueprints can then be transferred into code using any specific OO
language.
 4

Object Oriented Analysis and Design

(OOAD)
 It’s a structured method for analyzing, designing a system by
applying the object-orientated concepts, and develop a set
of graphical system models during the development life
cycle of the software.

 OOAD essential for creating well-designed, robust & maintainable

software system using OO Programming Language (e.g. Java,
C++, Python etc…).

 It is the latest and most used way of design now.

 UML (Unified Modeling Language) is a modeling language for

OOS.
 5

OOAD in the SDLC

 The software life cycle is typically divided up into stages

going from abstract descriptions of the problem to designs
then to code and testing and finally to deployment.
 6

What is Analysis and Design?

• Analysis (or requirements analysis) involves studying the

problem to be solved. It identifies what the problem is
without addressing how it will be solved.

• Design is the creative process that transforms a problem

into a solution. It identifies how the problem will be solved.
It is a conceptual solution rather than an implementation.
 7

Object Oriented Analysis

 An investigation of the problem (rather than how a solution is

defined).

 During OO analysis, there is an emphasis on finding and describing

the objects (or concepts) in the problem domain.
 Example: Concepts in a Library Information System include; Book and
Catalog.
 8

Object Oriented Design

 Emphasizes a conceptual solution that fulfills the requirements

specified in the analysis.

 Need to define software objects and how they collaborate to fulfill

the requirements.

 Designs are implemented in a Programming Language.

 Example: in the Library Information System, a Book software object may
have a title attribute and a display() method. And implemented using any
OO programming language; e.g. Java.
 9

From Analysis to Implementation

Analysis Design Construction

Investigation of Logical Solution Code
the problem

Domain Concept Logical Software Objects Representation in an

Ex: Book (Concept) OO Programming Language
Book
public Class Book {
Attribute: Title private String Title;
public void Display();
Method: Display() }
 10

Analysis and Design Activities

More Analysis Oriented

More Design Oriented

Analysis Oriented Design Oriented

 What  How
 Requirements  Logical Solution
 Investigation of Domain
 11

What is OOAD?

 In essence, to consider a problem domain and logical

solution from the perspective of objects (things, concepts, or
entities)
 OOA: emphasis on finding and describing the objects in the
problem domain
 OOD: emphasis on defining logical software objects and
how they should collaborate (via method calls) to fulfill the
requirements
 OOP: commitment to code.
 12

Consider a flight information system:

 OOA: Finding and defining the objects or concepts:

Plane, Flight, Pilot etc;

 OOD: Assigning responsibilities to those objects and

determining how they collaborate:
a Plane object must have a tailNumber attribute and a
getFlightHistory method;

 OOP : Implementing the design in code:

e.g. a Plane class in Java.
 Ex. (Cont.)

2
Plane visualization of

1
domain concept domain concept
tailNumber

public class Plane

3
representation in an {

private String tailNumber ;

object - oriented

programming language
public List getFlightHistory () { ... }

Fig: Object-orientation revolves around

objects.
 14

Unified Modeling Language

 A notational system aimed at modeling systems using object oriented
concepts.

 A language for specifying, visualising and constructing the artifacts of

software systems

 A de facto standard; We focus on diagrams that are used frequently:

Refer to the UML 2.0 standard (2003) for the details of the language.
 15

Unified Modeling Language

 The unified modeling language become the standard modeling language
for object-oriented modeling. It has many diagrams, however, the most
diagrams that are commonly used are:
 Use case diagram: It shows the interaction between a system and it’s
environment (users or systems) within a particular situation.
 Class diagram: It shows the different objects, their relationship, their
behaviors, and attributes.
 Sequence diagram: It shows the interactions between the different
objects in the system, and between actors and the objects in a system.
 State machine diagram: It shows how the system respond to external
and internal events.
 Activity diagram: It shows the flow of the data between the processes in
the system.
 16

Steps to OOAD

1-Define use 2-Conceptual 3-Collaboration 4-Design Class

cases Model Diagrams Diagram
 A Short Example: A Dice Game
• In this dice game: a player rolls two dice, if the total is
seven he/she wins; otherwise he/she loses.

• For this example, we will utilize Four Steps:

• 1. Defining Use Cases:

2. Defining a Domain Model
3. Defining Interaction Diagrams
4. Defining Design Class Diagrams
 1.Defining Use Cases:
 Understanding the requirements includes first
understanding the domain processes and the external
environment (external actors who participate in
processes).
 Use Case: Play a Game
Actors: Player
Description: Player requests to roll the dice. System presents
results. If the dice face value totals seven, player wins;
otherwise player loses.
 2. Defining a Domain Model

• A decomposition of the problem domain involves

identifying the important concepts, attributes and
associations in the domain.
• The conceptual model is not a description of
software components; it represents concepts in the
real-world problem domain.
The Conceptual Model

Player Die
1 Rolls 2
name faceValue
1 2
Plays
1

DiceGame
1 Includes

Fig 1.3 Partial domain model of the dice game.

 3. Defining Interaction Diagrams

• The next step in in OOD is allocating responsibilities to objects

and illustrating how they interact via messages, expressed in
sequence diagrams.
• Sequence diagrams show the flow of messages between
instances and the invocation of methods.
• In our EX, a simulation in software of the dice game
• Fig 1.4 illustrates the essential step of playing by sending
messages to instances of the Die class.
• Note that in the real world a player rolls the dice, in the software
design the DiceGame object rolls the dice (ie, sends messages to
the Die objects)
Fig 1.4 Sketched sequence diagram
 4. Defining Design Class Diagrams
 What are the methods of a class?
• How do objects connect to other objects?
• Inspect the sequence diagrams (dynamic view) for the necessary
connections between objects and the methods that each software class
must define
• Add this information to a design class diagram (a static view).
• Since a play message is sent to the DiceGame instance, the DiceGame
class requires a play method, while the Die class requires a roll and
getFaceValue method. See Fig 1.5.
• Design class diagrams describe software components.
 The Resulting Design Class Diagram

DiceGame Die

die1 : Die 1 2 faceValue : int

die2 : Die
getFaceValue() : int
play() roll()

Fig 1.5 Partial design class diagram

Summary of the Dice Game Example

• A very simple example : gives an overview of

the steps and artifacts in OOA&D
 26

Object Oriented vs. Function Oriented AD

OOAD SAD

Catalog Librarian Library

System

Record Add Report

Book Library Loans Resource Fines
 OO vs Function-Oriented A&D
• Prior to OOA&D structured analysis and design was popular :
decomposition of a problem by function or process resulting in a
hierarchical breakdown of processes rather than by objects
• OOA&D : emphasis on decomposing a problem space by objects rather
than functions
• The boundary between OOA and OOD is fuzzy (even more so than in
traditional SWE):
– There is a difference between investigation (analysis) and solution
(design)
– During analysis we emphasize understanding the problem while
deferring issues related to the solution, performance, and so on to the
design.
 Advantages/Disadvantages of Object Oriented Analysis

Advantages Disadvantages
Focuses on data rather than the procedures as in Functionality is restricted within objects. This may pose
Structured Analysis. a problem for systems which are intrinsically procedural
or computational in nature.

The principles of encapsulation and data hiding help the The object-oriented models do not easily show the
developer to develop systems that cannot be tampered communications between the objects in the system.
by other parts of the system.

It allows effective management of software complexity All the interfaces between the objects cannot be
by the virtue of modularity. represented in a single diagram.

It can be upgraded from small to large systems at a

greater ease than in systems following structured
analysis.
Advantages/Disadvantages of Structured Analysis

Advantages Disadvantages
As it follows a top-down approach in In traditional structured analysis models,
contrast to bottom-up approach of object- one phase should be completed before the
oriented analysis, it can be more easily next phase. This poses a problem in
comprehended than OOA. design, particularly if errors crop up or
requirements change.

It is based upon functionality. The overall The initial cost of constructing the system
purpose is identified and then functional is high, since the whole system needs to be
decomposition is done for developing the designed at once leaving very little option
software. The emphasis not only gives a to add functionality later.
better understanding of the system but
also generates more complete systems.

The specifications in it are written in It does not support reusability of code. So,
simple English language, and hence can be the time and cost of development is
more easily analyzed by non-technical inherently high.
personnel.
Class and Terminology

• The term ‘class’ is used a lot, but it can have a precise meaning
depending on the context:
– Within OOA, developing a Domain Model via a domain
diagram, classes are called domain concepts or conceptual
classes;
– Within OOD, developing a Design Model via a design
diagram, classes are called design classes or software
classes;
– Within OOP, developing an implementation model via code
in an OOPL, classes are called implementation classes.
 31

Stakeholders in software engineering

 32

Attributes of Software Quality

 Usability

 Efficiency

 Reliability

 Maintainability

 Reusability