DESIGN PRINCIPLES

DCIT 26
SOFTWARE DESIGN

 Softwaredesign is a mechanism to transform user requirements

into some suitable form, which helps the programmer in software
coding and implementation.

 In
software design, we consider the system to be a set of
components or modules with clearly defined behaviors &
boundaries.
OBJECTIVES OF SOFTWARE DESIGN

 Correctness: As for requirement the design should be accurate.

 Completeness:It should have the complete components, like

modules and data.

 Efficiency: Resources ought to be utilized efficiently by the

program.
 Flexibility: It can be modified when needed.

 Consistency: There shouldn't be any inconsistency within the

design.

 Maintainability:The design should be so simple so that it can be

easily maintainable by other designers.
OVERVIEW OF DESIGN PRINCIPLES

 Software design principles involved with imparting method to

address the complexity of the layout method effectively.

 Effectively
dealing with the complexity will now no longer lessen
the attempt needed for design but also can lessen the scope of
introducing mistakes for the duration of design.
FOLLOWING ARE THE PRINCIPLES OF SOFTWARE
DESIGN
Problem Partitioning
 divide
the problems into small pieces and conquer the problems
one by one.

Benefits of Problem Partitioning

1. Understandable
2. It becomes simple
3. Testing is easy
4. It is easy to modify
5. Maintainable
6. Software is easy to expand
Abstraction
a tool that enables a designer to consider a component at an
abstract level without bothering about the internal details of the
implementation

Here, there are two common abstraction mechanisms

1. Functional Abstraction
Functional abstraction forms the basis for function-oriented design
approaches.
2. Data Abstraction
Details of the data elements are hidden to the users of data. It
forms the basis for Object Oriented design approaches.
Modularity
 Modularity are the divisions of software that are into separate
modules, which has named and addressed and are embedded
later on in a completely functional software.
The desirable properties of a modular system are:
 Each module is a well-defined system that can be used with
other applications.
 Each module has single specified objectives.
 Modules can be separately compiled and saved in the library.
 Modules should be easier to use than to build.
 Modules are simpler from outside than inside.
Advantages of Modularity

 Itallows large programs to be written by several or different

people

 It simplifies the overlay procedure of loading a large program

into main storage.
Disadvantages of Modularity

 Execution time maybe, but not certainly, longer

 Compilation and loading time may be longer

MODULAR DESIGN

Functional Independence
 Functionalindependence is achieved by developing functions
that perform only one kind of task and do not excessively interact
with other modules

• Cohesion: It measures the relative function strength of a module.

• Coupling: It measures the relative interdependence among
modules.
Information Hiding
 The fundamental of Information hiding suggests that modules
can be characterized by the design decisions that protect from
the others.
Strategy of Design
A good system design strategy is to organize the program
modules in such a method that are easy to develop and latter
too, change.

1. Top-down Approach: This approach starts with the identification

of the main components and then decomposing them into their
more detailed sub-components.
2. Bottom-up Approach: This approach with the lower details and
moves up the hierarchy and is suitable to an existing system.
THE SOLID PRINCIPLES

 Single Responsibility Principle (SRP)

 Open/Closed Principle (OCP)
 Liskov Substitution Principle (LSP)
 Interface Segregation Principle (ISP)
 Dependency Inversion Principle (DIP)
SINGLE RESPONSIBILITY PRINCIPLE (SRP)

 This
principle says that a class should have one, and only one,
reason to change. SRP is about designing your classes so that
each does just one thing, and does it very well.

 Everyobject should have a single responsibility, and all the

object’s services are targeted towards carrying out that
responsibility. Each class should have only one reason to change
MobilePhone Class

 Thisclass seems to incorporate a lot of what

we would want a mobile phone to do, but it
violates the SRP in several different ways.

 Thisclass is not trying to do a single thing—it’s

trying to do way too many things:
Mobile phone class each with single responsibility.
OPEN/CLOSED PRINCIPLE (OCP)

 The
Open-Closed Principle (OCP) says that classes should be
open for extension and closed for modification.

 What this means is to find the behavior in a class that doesn’t

vary and abstract that behavior up into a super/base class.
 The classic BankAccount example for OCP
LISKOV SUBSTITUTION PRINCIPLE (LSP)

 TheLiskov Substitution Principle (LSP), named after Turing Award–

winner Dr. Barbara Liskov of MIT, tells us that all sub-classes must
be substitutable for their base class.

 This
principle says that inheritance should be well designed and
well behaved.
 Imagine managing two types of coffee machine.

 According to the user plan, we will use a basic or a premium

coffee machine, the only difference is that the premium
machine makes a good vanilla coffee plus than the basic
machine.

 The main program behavior must be the same for both

machines.
INTERFACE SEGREGATION PRINCIPLE (ISP)

A client should never be forced to implement an interface that it

doesn’t use or clients shouldn’t be forced to depend on methods
they do not use.
 Thisprinciple defines that a class should never implement an
interface that does not go to use.

 In
that case, means that in our implementations we will have
methods that don’t need.

 Thesolution is to develop specific interfaces instead of general-

purpose interfaces.
 Imagine we invent the FutureCar that can both fly and drive.

 The
main issue, is that the Car and Airplane have methods that
don’t use.
DEPENDENCY INVERSION PRINCIPLE (DIP)

 Entities must depend on abstractions not on concretions.

 Itstates that the high-level module must not depend on the low
level module, but they should depend on abstractions.

 Thisprinciple means that a particular class should not depend

directly on another class but on an abstraction of this class.
 Thank you.