Week 03

Software Design &

Architecture
 Design Goals and Principles
• Goals of Software Design • SOLID Design Principles
 Correct  Single Responsibility Principle
 Robust
 Flexible  Opened Closed Principle
 Reusable  Liskov Substitution Principle
 Efficient
 Interface Segregation Principle
 Reliable
 Usable  Dependency Inversion Principle

2
Design
(Recap)
• The purpose of design is to produce a solution to a problem:
• The problem: requirements specification.
• The solution: your description of how the requirements are to
be met.

• Design is the creative process of describing and transforming

a problem into a solution.

• A set of documents on whose basis a software can be fully

programmed.

3
 Design
(Cont...)
Design
Design Solution

A system that
provide complete
detail of airline
.reservation system

Reference [1] *

4
Software Design

:Software design describe •

without seriousbuild it coders canenough thatsystem wellThe –
.problems
All the parts of the system and how they fit together (architecture, –
high-level design)
(Detailed, low-level codedcan beso that itin detailpartEach –
.design)

5
Goals of Software Design

• Design faces many challenges to produce a good product, e.g.

shifting requirements.

• But what do we mean by good?

• We need some clear goals here …

6
 Goals of Software Design (Cont...)

• Good design leads to software that is:

– Correctness
– Robustness
– Attributes /Factors for estimating
Flexibility
– Reusability the quality of software design. Good
Design must fulfil following factors.
– Efficiency
– Reliability
– Usability

Reference [3] *

12
Correctnes
s
• Software is correct, if it satisfies its requirements.

• The more specific a question, the more precisely we can verify

the correctness of a design that answers it

• Precise and imprecise questions:

– What number adds to 3 to get 5? (precise)
– What bridge design gets cars from point A to point B? (imprecise)

• Correctness of design usually means sufficient design

8
Approaches to Correctness

• How can know that a design is or even

we correct
sufficient?
• Informal Approaches
– To be convinced that the design covers the required
functionality. (Sufficient Design)

• Formal Approaches
– Involve applying logic to analyzing the way in which the variables
change
– Usually applied when the design enters the detailed stage

9
Informal Approach: Sufficient Design

A design sufficient
Minimum to implement the a Correct Design
Goal requirements Sometimes
called ....

... It follows that

the design must Key Concept

be easily 1. Simplify
understandable 2. Modularize
A Common way to designs until
achieve this is to they are
make... convincing.
the very
design
modular
10
Robustness
• Robustness --- ability to handle anomalous situations even
in the presence of errors

• Sources of error ???

• Faulty input
– User input
– Inputs not from Users (Function Parameters etc)
• Developer errors
– Faulty design
– Faulty implementation

11
Flexibility
• Flexible design implies a design that can easily accommodate
the changes

12
 Aspects of Flexibility

1. Adding more of the same kind of functionality

– Example(bankingapplication): handle more of
kinds without having to change the existing design or accounts
code
2. –Adding different
Example: functionality
add withdraw function to existing deposit functionality to
user
3. Changing functionality

Reference [4] *

13
Flexibility: Designs for Adding More of
the Same Kind of Functionality
• Registering members at online shopping website
Design 1
WebSite n . .0
Member
)(Register

Design 2: Flexible Design

WebSite n . .0
Member
)(Register

Customer Visitor

14
Flexibility: Design for Adding Different
Functionality
• Case 1: Handled by adding the new method to an existing set
of methods of a class
WebSite
n . .0
Register() Member
)(maintainRecord

• Case 2: adding functionality through a base class

WebSite n . .0 Member
)(Register Log-
)(in

Customer Visitor
)( Log-in )(Log-in
15
Flexibility: Changing Functionality

• Flexible enough to accommodate functionality changing

WebSite n . .0 Member
)(Register Log-
)(in

Customer Visitor
Log-in() )(Log-in
)(AddCart
Product
)(ItemList

16
Reusability
• Designing a software system such that components of a
developed system can be used again in developing new
applications

• Reusability is an important factor in producing low cost

applications.

17
Modularity

• Use modularity
Shape

D Shape-2 D Shape-3

Rectangle Triangle Sphere Cube

Circle

Square

18
 Reusability: Promoting Source Code
Reuse (Cont...)
• Use Classes

Reference [5] *

19
Efficiency
• Applications must execute functionality within
required required time constraints.

• Two dimensions of efficiency:

1. Time
Major Factors of Data
2. Space structures and Algorithms

20
Reliability
• Reliability– mean time to failure (system crash, error)

• backup servers, multiple processors, etc

21
Usability
.Users must find software easy to easy •

Intuitive GUI, standard layout & meanings •

,Good documentation •

Hard to define and measure, user interviews, questionnaires, •

.etc

22
Today’s Agenda

• Software Design Principles

– Single Responsibility Principle
– Opened Closed Principle
– Liskov Substitution Principle
– Interface Segregation Principle
– Dependency Inversion Principle

2
SOLID
• Five principles of OOD Oriented
fundamental (Object
Design)...
• What is OOD ??
– In software development, OOD addresses the bigger picture. You need
to design your software in a way that your classes and code are
modularized, re-usable, and flexible.
– There are some design principles that you can apply to design your
classes and objects.

• The principles when applied together intend to make it more

likely that a programmer will create a system that is easy to
maintain and extend over time.

2
 Why
?OOD

Your software does what it is supposed to do today and does it

good enough. But, is your software smart enough to support
"changes"? If not, you don't have a smartly designed software.
1. object oriented.
2. Re-usable.
3. Can be changed with Applying a good "Object
minimal effort.
Oriented Design" is the key to
4. Can be extended without
achieve such a smart design
changing existing code.
Reference [1] *

2
Principles of OOD
1. Single Responsibility Principle
2. Opened Closed Principle
3. Liskov Substitution Principle
4. Interface Segregation Principle
5. Dependency Inversion Principle

2
 Single Responsibility Principle

Principle:
A class should have
one and only one
responsibility.

Reference [2] *

10
 Single Responsibility Principle

Principle:
A class should have
one and only one
responsibility.

Reference [3] *

11
Example Rectangle class performs
two things

• Separate the responsibilities

into two different classes,
such as:

1. Rectangle: class
Thisshould
the area() method. define

2. RectangleUI: This class

should

inherit
the

Rectangle

class

and define the Draw()

method. 29
 Open-Closed Principle

Principle:
Software entities (classes,
modules, ,functions etc.)
should be open
extension, for closed
modification.
but
for

Reference [4] *

30
Open-Closed Principle (Cont...)
• Example: we should strive to write code that doesn’t have
to be changed every time the requirements change

31
 Liskov's Substitution Principle

Principle:
Subclasses should be
substitutable for their base
classes.

32
Liskov's Substitution Principle
(Cont...)
Design
Bird Violate
)(Fly s LSP

Eagle Ostrich There should be a

separate class for birds
that can't really fly and
Ostrich should inherit
Class hierarchy showing an example of that.
Liskov Substitution Principle
The "Liskov's Substitution Principle" is just a way
of ensuring that inheritance is used correctly.

33
The Interface Segregation Principle

Principle:
Subclasses should not
be forced to depend
upon interfaces that
they do not use

34
The Interface Segregation Principle
(Cont...)

• Similarly in classes , if any class show unwanted methods or

functions then it leads to Fat Interface

• Fat Interface: interface with more member functions and

friends than are logically necessary

35
Fat interface
Example of an interface violating the
Interface Segregation principle
Bird
)(Eat Bird interface has many bird
behaviours along
Walk() defined the Fly() with
behaviour.
Chirp() Now, if a Bird class (say, Ostrich
)( Fly class) implements this interface, it
has to implement the Fly() behaviour
unnecessarily (Ostrich doesn't fly).

Eagle Ostrich

36
Solution: Fat Interface
• The "Fat Interface" should be broken down into two
different interfaces.

Bird
)(Eat
)(Walk Correct version of the interface in the Interface
Segregation principle example
)(Chirp

FlyingBird
)(Fly

37
Example

Bird
)(Eat
Walk()
)(Chirp

FlyingBird Ostrich
)(Fly

Eagle

38
The Interface Segregation Principle
(Cont...)
• This principle ensures that Interfaces are developed so that
each of them have their own responsibility and thus they are
specific, easily understandable, and re-usable.

39
The Dependency Inversion Principle

:Principle
"High level modules
should not upon
low level modules. Rather,
depend
both should depend upon
abstractions."

40
The Dependency Inversion Principle

41
The Dependency Inversion Principle

42
References

1. http://www.stefanolocati.it/blog/?p=1173
2. http://wilmurphy.com/what-can-setting-goals-do-
for-you/
3. http://www.codesimplicity.com/post/the-goals-of
- software-design/
4. http://en.wikipedia.org/wiki/Overdraft
5. http://shivasoft.in/blog/java/difference-between-
interfaceinheritance-abstract-class/
6. http://www.softwaremetrics.com/Articles/estima
ting
.htm 43