Object Oriented Analysis and

Design
Introduction
 Questions
• From user’s point of view, criticize a hardware or software system that has
a flaw that especially annoys you. Describe the system, the flaw, how it was
overlooked, and how it could have been avoided with a bit more thought
during design.
• What major problems have you encountered during past software
projects? How much time you have spend on analysis, design, coding and
testing/debugging/fixing. How do you go about estimating how much
effort a project will require?
• Recall a past system that you created. Briefly describe it. What obstacles
did you encounter in the design? What software engineering methodology,
if any, did you use? What were your reasons for choosing or not choosing a
methodology? Are you satisfied with the system as it exists? How difficult is
it to add new features to the system? Is it maintainable?
• Describe a recent large software system that was behind schedule, over
budget, or failed to perform as expected. What factors were blamed? How
could the failure have been avoided?
2
Aug 2015
 System/Software Life Cycle (SLC)
• Life cycle is the series of steps that software
undergoes from concept exploration through
retirement

• Intended to develop information systems in a

very deliberate, structured and methodical
way, reiterating each stage of the life cycle.

• Maturity of the process is some gauge of

success of organization
3
Aug 2015
Source: http://upload.wikimedia.org/wikipedia/commons/b/bb/Systems_Development_Life_Cycle.jpg
4
Aug 2015
 Importance of Lifecycle Models
• Provide guidance for project management
– what major tasks should be tackled next? milestones!
– what kind of progress has been made?
• The necessity of lifecycle models
– characteristics of software development has changed
• early days: programmers were the primary users
• modest designs; potential of software unknown
– more complex systems attempted
• more features, more sophistication  greater complexity, more
chances for error
• heterogeneous users

5
Aug 2015
 Object Oriented Approach
• Software development based on modeling objects from
the real world and then use the models to build a language
independent design organized around those objects.
• Promote better understanding of requirements, cleaner
designs, and more maintainable systems.
• Use language-independent graphical notation for analyzing
problem requirements, design a solution to the problem
and then implement the solution.
• Same concept and notation throughout the software
development process.
• Object oriented concepts throughout the software life
cycle, from analysis through design to implementation.
6
Aug 2015
 Cont.
• Coding - last stage in the process of development.
• A good design technique defers implementation details
until later stages of deign to preserve flexibility.
• Mistakes in the front of development process have a large
impact on the ultimate product and on the time needed
to finish.
• OOT is a way of thinking abstractly about a problem using
real world concepts, rather than a computer concepts.
• Graphical notations helps developer to visualize a
problem without prematurely resorting to
implementation
7
Aug 2015
 Why Modeling..?

Aug 2015
 Modeling
• A model is a simplification of reality
• A hypothetical description of a complex entity or process

• A good model includes those elements that have broad

effect and omits minor elements

• A model of a system is not the system!

• Modeling is used in many disciplines – architecture,

aircraft building, …

9
Aug 2015
 Why Modeling..?

 Models help us to visualize a system as it is or as we want it

to be.
 Models permit us to specify the structure or behavior of a
system.
 Models give us a template that guides us in constructing a
system.
 Models document the decisions we have made.

Aug 2015
 Why Models are needed?
• Symptoms of inadequacy: the software crisis
– scheduled time and cost exceeded
– user expectations not met
– poor quality

Aug 2015
 Build and Fix Model

Build first
version

Modify until
client is satisfied

Operations
mode

Retirement

Development

Maintenance

12
Aug 2015
 a systematic, sequential approach to
Waterfall Model software development that begins at the
system level and progresses through
analysis, design, coding, testing, and
support
Requirements
Requirements
Phase Description

Specification Specification,
Phase SPMP

Design
Phase Design Docs
Verify
output of stages Implementation
Flaw?
Flaw? & Integration Product
Phase
original model didn’t
original model didn’t
let you go back! Operations
let you go back! Retirement
Aug 2013
Mode
 14
Aug 2013
 Rapid Application Development (RAD)
Model

Makes heavy use of reusable software components with an extremely

short development cycle
Aug 2015
 Prototype Model

Aug 2015
 Incremental Model
(combines elements of the
linear sequential model (applied
repetitively) with the iterative
philosophy of prototyping)

C- Communication
P - Planning
M – Modeling
C - Construction
D - Deployment

Delivers software in small but usable pieces, each piece builds on

pieces already delivered
Aug 2015
 Spiral Model

Aug 2015
Spiral Model

Aug 2015
Concurrent Development Model

20
Aug 2015
 CBD Model

Aug 2015
The difference between procedural and object-
oriented analysis….??

Aug 2015
 Object-Oriented Vs Traditional analysis

• Traditional procedural systems separate data

and procedures, and model these separately
• Object orientation –views data and functions
together; data abstraction is the basis
– OO view more closely reflects the real world where humans are used to
think in terms of things which possess both attributes and behaviors.
– OO provides reuse possibility from the class hierarchy views of the
system.
– OO analysis centers on objects which combines data and methods.
– Software extensibility is easy.

23
Aug 2015
 Object-orientation : Four important aspects

• Identity
• Classification
• Polymorphism or Encapsulation and
• Inheritance.

Aug 2015
 Contd..
• Identity
– data is quantized into discrete, distinguishable entities called
“objects”.
– Each object has its own inherent identity
• Classifications
– objects with the same data structure (attributes) and
behavior (operations) are grouped into a class.
– A class is an abstraction that describes properties important
to an application and ignores the rest

Aug 2015
• Inheritance
– is sharing of attributes and operations among classes based on a hierarchical
relationship.
– A superclass has general information that subclasses refine and elaborate
– Subclasses need not repeat features of its superclass and add its own unique
features
– The ability to factor out common features of several classes into a superclass
can greatly reduce repetition within designs and programs and is one of the
main advantages of OO technology
• Polymorphism
– means that the same operation may behave differently for different classes.
– Operation and method???

26
Aug 2015
 Importance of Objects

• The single most important principle of object

oriented computing is that "objects are responsible
for their own actions".

• If used properly, OOD improves the maintenance,

reusability, and modifiability of the software.

Aug 2015
The Basic Principles of Object Orientation

Four basic principles:

• Abstraction
• Encapsulation
• Modularity
• Hierarchy

28
Aug 2015
 Abstraction
• An abstraction denotes the essential characteristics of
an object that distinguish it from all other kinds of
objects and thus provide crisply defined conceptual
boundaries, relative to the perspective of the viewer.

• Key concepts:
• Concentrating only on essential characteristics
 Allows complexity to be more easily managed
• Abstraction is relative to the perspective of the viewer
 Many different views of the same object are possible.

29
Aug 2015
 30
Aug 2015
 Encapsulation
• Encapsulation is the practice of including in an object
everything it needs hidden from other objects. The internal
state is usually not accessible by other objects.

Key concepts:
• Packaging structure and behavior together in one unit
 Makes objects more independent
• Objects exhibit an interface through which others can interact
with it
• Hides complexity from an object’s clients

31
Aug 2015
 Modularity
Modularity is the property of a system that has been
decomposed into a set of cohesive and loosely coupled
modules.

Module: a collection of related classes of objects

Key concepts:
• Modules are cohesive (performing a single type of tasks)
 Makes modules more reusable
• Modules are loosely coupled (highly independent)
 Makes modules more robust and maintainable

32
Aug 2015
 33
Aug 2015
 Hierarchy
•Hierarchy is a ranking or ordering of abstractions
OR
•Organizing things into different levels of abstraction

• Types of hierarchies:
• Class
• Aggregation
• Containment
• Inheritance
• Partition
• Specialization
34
Aug 2015
 Example: Hierarchy

35
Aug 2015
 Example: Class hierarchy

36
Aug 2015
 Basic Concepts of Object Orientation

• Object
• Class
• Attribute
• Operation
• Component
• Package

37
Aug 2015
 Object
• An object represents an individual, identifiable item, unit, or
entity, either real or abstract, with a well-defined role in the
problem domain.
Or
• An "object" is anything to which a concept applies.
• Also, object is an instance of a class

An object can be
• A physical entity (car, fan, man, etc)
• A conceptual entity (A chemical process)
• A software entity (stack, queue, linked list)
38
Aug 2015
Objects have the following qualities:

Identity: Objects are distinguishable from one another

Behavior: Objects can perform tasks

State: Objects store information that can vary over time

39
Aug 2015
 Class
• A class is a blueprint that describes an object
and defines attributes and operations for the
object
• Classes use abstraction to make available only
the elements essential to defining the object
• Classes use encapsulation to enforce an
abstraction
• Simple terms: It is a collection of objects

40
Aug 2015
Relations between Objects and Classes
• A class is an abstract definition of an object

It defines the structure and behavior of each object in the
class

It serves as a template for creating the objects

• Objects are grouped into classes

41
Aug 2015
Difference between Structures and Classes

42
Aug 2015
Attributes:
It describes the state (data) of an object

Operation:
Define its behavior

What an object is capable of doing

43
Aug 2015
 Component:
• A non-trivial, nearly independent and replaceable part of a
system that fulfills a clear function in the context of a well
defined architecture.
• A component may be
 A source code component
 A run time component
 An executable component

44
Aug 2015
 Package:
• A package is a general purpose mechanism for
organizing elements into groups.
• A model element which can contain other
model elements.

45
Aug 2015
 Strengths of Object Orientation:
• Facilitates architectural and code reuse
• Models more closely reflect the real world
– More accurately describe corporate data and processes
– Decomposed based on natural partitioning
– Easier to understand and maintain
• Stability
– A small change in requirements does not mean massive changes in the
system under development

46
Aug 2015
 Analysis
• Analysis - investigation of the problem.
 What does the system do?

• Requirements Analysis is discovering the

requirements that a system must meet in
order to be successful.

• Object Analysis is investigating the object in a

domain to discover information important to
meet the requirements.
47
Aug 2015
 Requirements Analysis
• One of the basic principles of good design is to
defer decisions as long as possible.
• The more you know before you make a design
decision, the more likely it will be that the
decision is a good one.

• TFCL: Think First, Code Later!

48
Aug 2015
 Design
• Design emphasizes a conceptual solution that
fulfills the requirements.
 How a system is to be built?

• A design is not an implementation, although a

good design can be implemented when it is
complete.

• There are subsets of design, including

architectural design, object design, and database
design.
49
Aug 2015
 Analysis Vs Design
 Analysis
 Design
 Focus on

Focus on understanding
understanding the the solution
problem 
Operations and
 (Generalized) Attributes
Behavior 
Performance,
 Separation of Efficiency…
Concerns

Close to real code
 System structure

Object lifecycles
 Functional

Non-functional
requirements requirements in detail
 Some recognition for

non-functional 
A large model
50
requirements
Aug 2015
 51
Aug 2013
 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

52
Aug 2015
 Goal of Design
 OOD enables a software engineer to

Indicate the objects that are derived from each class

How these objects interrelate with one another
 OOD depicts how

Relationships among objects are achieved

Behavior is to be implemented

Communication among objects is to be implemented

53
Aug 2015

OO analysis
Essence of OO analysis –
and design
► consider a problem domain from the perspective of
objects (real world things, concepts)
Ex: In a Library Management System, some of the concepts
include Book, Library, and Patron.

 Essence of OO design –
► define the solution as a collection of software objects
(allocating responsibilities to objects)
Ex: In a Library Management System, a Book software object may
have a title attribute and a getChapter method.

Book
______
title
getChapter()
54
Aug 2013
 The End

55
Aug 2013
 Coupling
• Coupling is an inter-module concept, captures
the strength of interconnection between
modules
• More tightly coupled the modules, the more
they depend on each other, more difficult to
modify one
• Low coupling is desirable for making systems
understandable and modifiable
• In OO, three types of coupling exists –
interaction, component, and inheritance

OO Design 56
Aug 2015
 Coupling…
• Interaction coupling occurs due to methods of
a class invoking methods of other classes
– Like calling of functions
– Worst form if methods directly access internal
parts of other methods
– Still bad if methods directly manipulate variables
of other classes
– Passing information through temporary variables
is also bad

OO Design 57
Aug 2015
 Coupling…
• Least interaction coupling if methods
communicate directly with parameters
– With least number of parameters
– With least amount of information being passed
– With only data being passed
• I.e. methods should pass the least amount of
data, with least number of parameters

OO Design 58
Aug 2015
 Coupling…
• Component coupling – when a class A has
variables of another class C
– A has instance variables of C
– A has some parameters of type C
– A has a method with a local variable of type C
• When A is coupled with C, it is coupled with all
subclasses of C as well
• Component coupling will generally imply the
presence of interaction coupling also

OO Design 59
Aug 2015
 Coupling…
• Inheritance coupling – two classes are coupled
if one is a subclass of other
• Worst form – when subclass modifies a
signature of a method or deletes a method
• Coupling is bad even when same signature but
a changed implementation
• Least, when subclass only adds instance
variables and methods but does not modify
any
OO Design 60
Aug 2015
 Cohesion
• Cohesion is an intra-module concept
• Focuses on why elements are together
– Only elements tightly related should exist together in a
module
– This gives a module clear abstraction and makes it easier to
understand
• Higher cohesion leads to lower coupling – many
interacting elements are in the module
• Goal is to have higher cohesion in modules
• Three types of cohesion in OO – method, class, and
inheritance

OO Design 61
Aug 2015
 Cohesion…
• Method cohesion – why different code
elements are together in a method (like
cohesion in functional modules)
– Highest form is if each method implements a clearly
defined function with all elements contributing to
implementing this function
– Should be able to state what the module does by a
simple statement

OO Design 62
Aug 2015
 Cohesion…
• Class cohesion – why different attributes and
methods are together in a class
– A class should represent a single concept with all
elements contributing towards it
– Whenever multiple concepts encapsulated,
cohesion is not as high
– A symptom of multiple concepts – different groups
of methods accessing different subsets of
attributes

OO Design 63
Aug 2015
 Cohesion…
• Inheritance cohesion – focuses on why
classes are together in a hierarchy
– Two reasons for subclassing
• generalization-specialization
• reuse
– Cohesion is higher if the hierarchy is for
providing generalization-specialization

OO Design 64
Aug 2015