Chapter 5

Object Oriented System

Analysis and Design

Ch - 5: Design 1
 5.1 System Analysis
 Object-oriented (O-O) analysis and
design is an approach that is intended to
facilitate the development of systems that
must change rapidly in response to
dynamic business environments. Each
object is a computer representation of some
actual thing or event.
 In an object-oriented system, all data is
represented as discrete objects with which
the user and other objects may interact. ...
An object-oriented system allows the user
to focus completely on tasks rather than
tools. Ch - 5: Design 2
 Object Modelling
Object modelling develops the static structure of the
software system in terms of objects. It identifies the objects,
the classes into which the objects can be grouped into and
the relationships between the objects. It also identifies the
main attributes and operations that characterize each class.
The process of object modelling can be visualized in the
following steps −
• Identify objects and group into classes
• Identify the relationships among classes
• Create user object model diagram
• Define user object attributes
• Define the operations that should be performed on the
classes

Ch - 5: Analysis 3
 Structured Analysis vs. Object
Oriented Analysis
The Structured Analysis/Structured Design (SASD)
approach is the traditional approach of software
development based upon the waterfall model. The
phases of development of a system using SASD are −
• Feasibility Study
• Requirement Analysis and Specification
• System Design
• Implementation
• Post-implementation Review
Now, we will look at the relative advantages and
disadvantages of structured analysis approach and
object-oriented analysis approach
analysis approach and object-oriented analysis approach
Ch - 5: Analysis 4
Advantages/Disadvantages of
Object Oriented Analysis

Ch - 5: Analysis 5
5.2 Design
• Topics to be covered include:
• System Design: Design Principles, Module-
level Concepts, Design Notation and
Specification, Structured Design
Methodology
• Fundamentals of Object- Orientation:
Objects, Classes, Encapsulation,
Inheritance, Polymorphism, Aggregation,
Abstract classes
• Detailed Design
• Estimated time: 12 hrs.

Ch - 5: Analysis 6
…
• Design activity begins with a set of requirements.
• Design is done before the system is implemented.
• Design is the intermediate language between
requirements and code.
• Design is the first step in moving from problem domain
to solution domain.
• Proceeding from abstract to more concrete
representations.
• The result of this phase is the design to be used for
implementing the system.
• Design of a system is a blueprint for a solution for the
system.

Ch - 5: Analysis 7
…

• Req. spec Design

Ch - 5: Design 8
…
• Design is a creative activity
• Goal: to create a plan to satisfy
requirements.
• Design is perhaps the most critical activity
during system development
• Design determines the major
characteristics of a system
• Has great impact on testing and
maintenance.
• Design document forms reference for later
phases.
Ch - 5: Design 9
Design Principles

• The goals during the design phase are:

• Choosing the best possible design (in terms
of time, complexity, space, etc.)
• Completeness: - implements all the
specifications.
• Efficiency: - optimal use of scarce resources
by the system.

Ch - 5: Design 10
…
• Simplicity: - easily understandable design;
shouldn’t be complex; unless simple,
collecting and fixing bugs will be difficult;
makes maintenance easier.
• Modularity: - implementing partitioning. If a
system is partitioned into modules so that
the modules are solvable and modifiable
separately. It will be even better if the
modules are also separately compilable. It
does not mean simply chopping a system
into modules.

Ch - 5: Design 11
Module-Level Concepts

• Module: - is a logically separable

part of a program.
• It is a program unit that is discrete
and identifiable with respect to
compiling and loading.
• In terms of programming language
constructs, it can be a function, or a
procedure (or a subroutine).

Ch - 5: Design 12
…
• Two criteria for modularity: Coupling and
Cohesion.
1) Coupling: - the strength of interconnections
between modules or a measure of
interdependency among modules.
• In general, the more we must know about module A in
order to understand module B, the more closely
connected A is to B.
• “Highly coupled” modules are joined by strong
interconnections, while “loosely coupled” modules
have weak interconnections.

Ch - 5: Design 13
…
• Question: What do you think the aim of
design is: to have “highly coupled” or
“loosely coupled”? Why?
• Answer: Loosely coupled! To solve and
modify a module separately.
• Coupling is an abstract concept and is
not easily quantifiable.
• So, no formulas can be given to
determine the coupling between two
modules.

Ch - 5: Design 14
…
• However, some major factors
influencing coupling can be identified:
• Type of connection between modules: - should be
simple as much as possible.
• Number of data to be passed:- minimize as much
as possible, minimize the number of interfaces
per module and the complexity of each interface.
• Type of data (information) to be passed: -
minimize data item.
− Having only flow of control or only flow of data will
make coupling loose compared to having both flow
of control and flow of data.

Ch - 5: Design 15
…
• In coupling, relationship among
elements of different modules needs
to be minimized.
2) Cohesion: - represents how tightly
bound the internal elements of a
module are to one another.
• The strength among elements of the same
module needs to be maximized.

Ch - 5: Design 16
…
• Question: What level of cohesion is
needed in design: low or high?
• Answer: high!
• A cohesive module needs to be simple,
and specific (perform specific task). E.g.
“Sort”, “Compute square root”.
• As it has been observed practically, the
greater the cohesion of each module in
the system, the lower the coupling
between modules is.

Ch - 5: Design 17
Design Notation and
Specification
• During the design phase, we will have the design of
the system and the process of designing.
• It is for the process of designing that principle and
methods are needed.
• Design notations are largely meant to be used during
the process of design and are used to represent
design or design decisions.
• Design notations are largely meant for the designer
so that he can quickly represent his decisions in a
compact manner that he can evaluate and modify.
• These notations are frequently graphical.
• One of the most common notations is structure chart.

Ch - 5: Design 18
…
• Structure Chart: is a
hierarchical organization that
shows:
• the modules of the system.
• the interconnection between modules.
• Symbols of structure chart:
• Module:- named rectangle (the module
name inside a rectangle)

Ch - 5: Design 19
…
• Invocation: - represented by an arrow
from the calling module to the called
(invoked) one.
•A B means module A invokes
module B. A is called superordinate
module, and B is called subordinate
module.
• Data:- represented by an arrow with
empty circle with data labeling. Data
name

Ch - 5: Design 20
…
• Control: - represented by an arrow
with filled circle at the tail. Flag
• Loop:- represented by a circular
arrow around the arrows joining
the subordinates that are
repeatedly called.
A repeatedly calls C and D.

Ch - 5: Design 21
…

• Decision: - represented by a
diamond in the invoking module
from which modules whose
invocation depends on the
outcome of some decision
originate.
The invocation of C and D depend
on the outcome of some decision

Ch - 5: Design 22
Design Specification
• The above design method is alright while the
designer is designing but in adequate when
the design is to be communicated to other
programmers or archived for future reference.
• To avoid this problem the design needs to be
formally specified.
• A design specification should contain:
• Problem specification
• Major data structures
• Modules and their specifications
• Design decisions.

Ch - 5: Design 23
Reading Assignment

• Fundamentals of Object- Orientation:

• Objects, Classes, Encapsulation,
Inheritance, Polymorphism,
Aggregation, Abstract classes

Ch - 5: Design 24
Verification (in Detailed Design)

• The focus of verification in the detailed

design phase is on showing that the
detailed design meets the specifications
laid down in the system design.
• Three methods of verification: design
walkthroughs, critical design review,
and consistency checkers.

Ch - 5: Design 25
A. Design Walkthroughs
• It is a manual method of verification
• A design walkthrough is done in an informal meeting
called by the designer or the leader of the designer’s
group.
• The walkthrough group contains the designer, and
group leader or other designer group.
• In a walkthrough the designer explains the logic step
by step, and the members of the group ask
questions, point out possible errors or seek
clarification.
• Benefit – during explaining, the designer may
uncover some errors.
• Side effect – since it is a form of peer review, it may
not be effective as of design review.

Ch - 5: Design 26
B. Critical Design Review
• The purpose of critical design review is to ensure that
the detailed design satisfies the specifications laid
down during system design.
• It is same as inspection process in which a group of
people get together to discuss the design with the
aim of revealing design errors or undesirable
properties
• The review group includes: author, member of
system design team, the programmer, and an
independent software engineer.
• During design review, the aim is to uncover errors,
not to fix, fixing will be done later
• Checklist will be used.
Ch - 5: Design 27
Sample check list during
design review
• Does each module in system design
exist in detailed design?
• Performance requirement met?
• Data formats consistent with the system
design?
• Each statements codable?
• Loops terminates properly?
• Conditions in loop okay?
• Is the nesting proper?
• Modules highly cohesive?
Ch - 5: Design 28
C. Consistency checkers
• Both walkthrough and design review are manual
processes
• If the design is specified in PDL it is possible to detect
some design defects by using consistency checkers
• Consistency checkers are compilers that takes as
input the design specified in a design language (PDL).
• A consistency checker can ensure that any modules
invoked or used by a given module actually exist in
the design and that the interface used by the caller is
consistent with the interface definition of the called
module.

Ch - 5: Design 29