OOM

Software Design & Architecture

Prof. Dr. O.P.Vyas

DAAD Fellow (Germany), AOTS Fellow(Japan)

Professor
Indian Institute of Information Technology, Allahabad

1
 OOM
● Software Design: Design Patterns
● OO Modeling with class diagrams: Creating quality Classes
● Patterns in Engineering: Concepts wrt Software Engineering
● Design Patterns: Inheritance, Composition & Aggregation
● Design Principles
● Open Close Principles
● Dependency Inversion Principles
● Interface Segregation Principle
● Single Responsibility Principle
● Creating Quality Classes
● Liskov's Substitution Principle

● Design Patterns: Concepts

● Concepts & patterns
● Inheritance Vs Composition 2
● OOSE: Implementation issues
 OO Design for Software Projects
● Software Design: Design Patterns
● Modeling Vs Design : Role of OOM
● Software Design Vs Algorithm Vs Design patterns
● OO Design & GoF design patterns
● OO Design Principles
Open Closed Principle
Dependency Inversion Principle
Interface Segregation Principle
Single Responsibility Principle
Liskov's Substitution Principle
● Patterns: GoF Design Patterns….
● Design Patterns: Concepts & Applications

● Architectural Consideration
● Concepts & Implementation issues
3
● Recent trends in Architecture
Real World: Modeling to Design
 Enhancing Software Design Quality with
Object-Oriented Principles and Patterns
In the realm of medium and large-scale software projects, the quality of class design plays a
pivotal role in determining the system's overall success.

While class diagrams serve as essential tools for modeling system structure, they alone are not
sufficient to ensure a robust and extensible design.
To create systems that can evolve gracefully without compromising existing functionality,
software developers must delve deeper into advanced object-oriented methodologies.
Object-Oriented Modeling (OOM) has emerged as a cornerstone in addressing these
challenges, offering a rich set of design principles and patterns. These concepts provide
developers with powerful techniques to craft high-quality, maintainable, and scalable
software architectures.

By leveraging OOM principles and design patterns, teams can significantly enhance
their ability to create flexible systems that stand the test of time and changing
requirements.
OO Design Principles

6
OO Design Principles & Design Patterns

– To build a robust, flexible and maintainable

Software, the OO Design Principles were
formulated
– There are some patterns in software
which are used, tested and proved
successful in solving some commonly
occurring problems.
– These design patterns are based on the
principles of OO Design Principles…
Core Object-Oriented Design
Principles
Object-Oriented Design Principles form the backbone of high-quality software architecture. These principles guide developers
in creating systems that are modular, flexible, and easier to maintain. Among the most crucial principles are SOLID, which
stands for Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion.

Adhering to these principles helps in creating loosely coupled systems where classes have well-defined responsibilities and
interact through clear interfaces. This approach not only improves code readability but also enhances testability and makes the
system more resilient to changes. By following these principles, developers can create software that is easier to extend and less
prone to bugs when modifications are needed.

Single Responsibility Principle Open-Closed Principle (OCP) Liskov Substitution Principle (LSP)
(SRP) Software entities should be open for Objects of a superclass should be
A class should have only one reason to extension but closed for modification. replaceable with objects of its
change, meaning it should have only This principle encourages the use of subclasses without affecting the
one job or responsibility. This principle abstractions and polymorphism to correctness of the program. This
promotes high cohesion and helps in allow new functionality to be added principle ensures that inheritance is
creating more maintainable and without altering existing code. used correctly and promotes the
understandable code. creation of well-designed class
hierarchies.
Advanced Object-Oriented Design Principles
Beyond the core SOLID principles, there are additional advanced object-oriented design principles that further enhance
software quality. These principles focus on creating more flexible, maintainable, and scalable systems by promoting loose
coupling and high cohesion among components.

Principles such as the Dependency Inversion Principle (DIP) and the Interface Segregation Principle (ISP) play crucial roles
in creating modular and easily extensible systems. The DIP promotes the use of abstractions to decouple high-level
modules from low-level implementations, while the ISP encourages the creation of fine-grained interfaces tailored to
specific client needs. These principles, when applied correctly, lead to systems that are more resilient to change and easier
to test and maintain.

Dependency Inversion Interface Segregation Encapsulation Composition Over

High-level modules should Clients should not be forced Hide internal state and Inheritance
not depend on low-level to depend on interfaces require all interaction to be Favor object composition

modules. Both should they do not use. performed through an over class inheritance to

depend on abstractions. object's methods. achieve better flexibility and

reusability.
 Design Patterns Overview
●Object-oriented design patterns typically show relationships and
interactions between classes or objects, without specifying the final
application classes or objects that are involved.
● modules and interconnections.
● In software engineering, a design pattern is a general reusable
solution to a commonly occurring problem in software design.
● A design pattern is not a finished design that can be
transformed directly into code. It is a description or template
for how to solve a problem that can be used in many different
situations.
● Effective software design requires considering issues that may
not become visible until later in the implementation.
● Reusing design patterns helps to prevent subtle issues that can
cause major problems and improves code readability for
coders and architects familiar with the patterns.
10
 Software Design Vs Design Patterns
● Class diagram forms the significant basis of Software design.
● Class diagram gives an overview of a system
by showing its classes and the relationships
among them.
● Software design researches are also influenced by the
development: Design Patterns are general reusable solution to
a commonly occurring problem in software design.
● It is a description or template for how to solve a problem
that can be used in many different situations.
● All software patterns are not design patterns.
● For instance, algorithms solve computational
problems rather than software design problems.
● Design Patterns as proposed by GoF are
Classic Patterns
10/21/24 11
 GoF has significant impact on OO
practices and Researches

The Concept of OO Design Patterns was introduced by GoF

and became instantly popular worldwide. The book has the first
two chapters exploring the capabilities and pitfalls of
object-oriented programming, and the remaining chapters
describing 23 classic software design patterns.
 GoF & OO Software
● GoF proposed many useful techniques related to
Object Oriented Software in the popular Book
● Authors Erich Gamma, Richard Helm, Ralph Johnson and
John Vlissides with a foreword by Grady Booch. They are
often referred to as the Gang of Four, or GoF.

▪ The book has been influential to the field of OO Software and is

regarded as an important source for object-oriented design
theory and practice. More than 500,000 copies have been sold in
English and in 13 other languages.
● Effective software design requires considering issues that
may not become visible until later in the implementation
and thus Principles of OO Design and Design Patterns
provides a tested Solution paradigm to many often
occurring situations.
● What
10/21/24 are the significant influences of GoF in Object Orientation?
 GoF-Design Patterns

•Design Patterns: Elements of

Reusable Object-Oriented
Software
Book by Ralph Johnson, John
Vlissides, Richard Helm, and Erich
Gamma

•Published: October 21, 1994

● Describing 23 classic
software design patterns.
● Regarded as an
important source for
object-oriented design
theory and practice.
 Design Patterns
● Not all software patterns are design patterns.

● For instance, A Class Diagram represents a

Software design for a Transaction Processing
system but it does not provide solution to
software design problems of all Transaction
Processing systems in the software
world !!
● At a higher level there are architectural patterns that are
larger in scope, usually describing an overall pattern
followed by an entire system.
● Design patterns were originally grouped into the categories:
creational patterns, structural patterns, and behavioral
patterns, and described using the concepts of delegation,
aggregation, and consultation.
10/21/24 15
Design Patterns: Reusable Solutions to Common
Problems
Design patterns represent tried-and-tested solutions to recurring problems in software design. They provide a common
vocabulary for developers to discuss and implement elegant solutions to complex design challenges. By leveraging design
patterns, developers can create more flexible, reusable, and maintainable code structures.

The Gang of Four (GoF) design patterns, categorized into Creational, Structural, and Behavioral patterns, offer a comprehensive
toolkit for addressing various architectural concerns. Creational patterns deal with object creation mechanisms, Structural
patterns focus on composing classes and objects into larger structures, and Behavioral patterns are concerned with
communication between objects and the assignment of responsibilities.

Category Examples Primary Focus

Creational Patterns Singleton, Factory Method, Abstract Object creation mechanisms

Factory

Structural Patterns Adapter, Decorator, Composite Composition of classes and objects

Behavioral Patterns Observer, Strategy, Command Communication between objects

Design Patterns use the OO Design
Principles
 OOSE Design Principles
Based on concepts of Object Orientation, these Design Principles
are considered instrumental in developing a robust, flexible
and maintainable Software ;

Open Closed Principle

Dependency Inversion Principle
Interface Segregation Principle
Single Responsibility Principle
Liskov's Substitution Principle

18
 OO Design Principles
Based on concepts of Object Orientation, these Design
Principles are considered instrumental in developing a robust,
flexible and maintainable Software ;

Open Closed Principle

Single Responsibility Principle
Liskov's Substitution Principle
Dependency Inversion Principle
Interface Segregation Principle

19
Data 3.19 Prof.Dr.
 Open Closed Principle
● OCP aims at achieving OO design objectives.

● Software entities like classes, modules and functions should

be

● open for extension

but
● closed for modifications.

● OCP is a generic principle.

● You can consider it when writing your classes to make sure
that when you need to extend their behavior you don’t have to
change the class but to extend it.

20
Data 3.20 Prof.Dr.
 OCP
● To extend the behavior of the system, we add new code. We
do not modify old code.
Modules that conform to the OCP meet two criteria:
● Open For Extension - The behavior of the module can be
extended to meet new requirements
● Closed For Modification - the source code of the module is not
allowed to change
● How can we do this?
● Abstraction
● Polymorphism
● Inheritance
● Interfaces

21
Data 3.21 Prof.Dr.
 Open Closed Principle
● The Open Closed Principle (OCP) is undoubtedly the most
important of all the class category principles. In fact, each of
the remaining class principles are derived from OCP.
● It originated from the work of Bertrand Meyer, who is
recognized as an authority on the object-oriented paradigm.
● When referring to the classes Open Closed Principle can be
ensured by use of Abstract Classes and concrete classes for
implementing their behavior.
● Some ways to do this include Polymorphism / Inheritance,
Composition, Inversion of Control, Aspect-Oriented
Programming, and many other principles, patterns, and
techniques of OOAD.
● It is not possible to have all the modules of a software system
satisfy the OCP, but we should attempt to minimize the
number of modules that do not satisfy it

22
Data 3.22 Prof.Dr.
 OCP
● OCP Principle is basis for many other OO designs
● The same principle can be applied for modules,
packages, libraries.
● If you have a library containing a set of classes
there are many reasons for which you’ll prefer to
extend it without changing the code that was
already written (backward compatibility, regression
testing, …).
● This is why we have to make sure our modules follow Open
Closed Principle.
● Suppose we have to prepare Software for Graphics Editor..

23
Data 3.23 Prof.Dr.
 ● // Open-Close Principle
OCP
class GraphicEditor { Example to highlight Open Close Principle.
public void drawShape(Shape s) { It implements a graphic editor which handles the
if (s.m_type==1) drawing of different shapes.
drawRectangle(s);
else if (s.m_type==2) There are several disadvantages:
drawCircle(s);
} ✔for each new shape added the unit testing of the
public void drawCircle(Circle r) {....} GraphicEditor should be redone.
public void drawRectangle(Rectangle r)
{....} ✔when a new type of shape is added the time for
} adding it will be high since the developer who add
it should understand the logic of the GraphicEditor.
class Shape {
int m_type; ✔adding a new shape might affect the existing
} functionality in an undesired way, even if the new
shape works perfectly
class Rectangle extends Shape {
Rectangle() {
super.m_type=1;
}
}

class Circle extends Shape {

Circle() {
super.m_type=2;
}
} 24
Data 3.24 Prof.Dr.
 OCP
It's obviously that it does not follow the Open Closed Principle since
the GraphicEditor class has to be modified for every new shape class
that has to be added.

In order to have more dramatic effect, just imagine that the Graphic Editor is a big class, with
a lot of functionality inside, written and changed by many developers, while the shape might
be a class implemented only by one developer.

In this case it would be great improvement to allow the adding of a new shape without
changing the GraphicEditor class.
25
Data 3.25 Prof.Dr.
 OCP

● // Open-Close Principle - Good example ● Now is a example which supports the

class GraphicEditor { Open Close Principle.
public void drawShape(Shape s) {
s.draw(); ● In the new design we use abstract draw()
} method in GraphicEditor for drawing
} objects, while moving the implementation
in the concrete shape objects. Using the
class Shape { Open Close Principle the problems from
abstract void draw(); the previous design are avoided, because
} GraphicEditor is not changed when a new
shape class is added:
class Rectangle extends Shape {
public void draw() { No unit testing required.
// draw the rectangle No need to understand the sourcecode
} from GraphicEditor.
}
Since the drawing code is moved to
the concrete shape classes, it's a
reduced risk to affect old functionality
when new functionality is added.

26
Data 3.26 Prof.Dr.
 OCP

Like every principle OCP is only a principle.

Making a flexible design involves additional time and effort spent for it and it introduce new
level of abstraction increasing the complexity of the code.

So this principle should be applied in those area which are most likely to be changed.

There are many design patterns that help us to extend code without changing it. For instance
the Decorator pattern help us to follow Open Close principle. Also the Factory Method or the
Observer pattern might be used to design an application easy to change with minimum 27
changes in the existing code.
Data 3.27 Prof.Dr.
 Single Responsibility Principle

● A class should have only one reason to change.

● In this context a responsibility is considered to be one
reason to change.

● This principle states that if we have 2

reasons to change for a class, we have
to split the functionality in two classes.
● Each class will handle only one responsibility and on future
if we need to make one change we are going to make it in
the class which handle it.

28
Data 3.28 Prof.Dr.
 Single Responsibility Principle

● When we need to make a change in a class having more

responsibilities the change might affect the other
functionality of the classes.

● Single Responsibility Principle was

introduced Tom DeMarco in his book
Structured Analysis and Systems
Specification, 1979.
● Robert Martin reinterpreted the concept
and defined the responsibility as a
reason to change.

29
Data 3.29 Prof.Dr.
 Real World: Modeling to Design

Data 3.30 Prof.Dr.

 31
Data 3.31 Prof.Dr.
 The most single important ability in
object oriented analysis and design is;

to skilfully assign responsibilities

to software components.
By creating appropriate
Abstractions

Data 3.32 Prof.Dr.