CS3201/2: Software Engineering Project I

and II

Design Principles*
LN Set #7
* Some slides are shared by Dr. Bimlesh and are used in CS3219

From Mud to Structure

30/8/2016

CS3201_02 LN Set #7 Design Principles

From Mud to Structure

A Well Structured
Sustainable System

A muddy set of
requirements

30/8/2016

CS3201_02 LN Set #7 Design Principles

Design Principles

Design principles help us manage complexity of the

product and of the process.

30/8/2016

CS3201_02 LN Set #7 Design Principles

Design Principles

Abstraction
Information hiding
Cohesion
Coupling
Redundancy
Separation of Concerns (SoC)
Design to Interface (D2I)

30/8/2016

CS3201_02 LN Set #7 Design Principles

Abstraction
An abstraction denotes the essential characteristics of
an object that distinguish it from all other kinds of object
and thus provide crisply defined conceptual
boundaries, relative to the perspective of the viewer.
Abstraction denotes a model, a view, or some other
focused representation for an actual item.
G. Booch,
leader in object-oriented analysis and the development of
the Unified Modeling Language [UML]
30/8/2016

CS3201_02 LN Set #7 Design Principles

Abstraction
Manage complexity
Emphasize essential characteristics
Suppress implementation details

Useful for developers

Decompose complex systems into smaller
components

Two points of view

What it does from how it does it
30/8/2016

CS3201_02 LN Set #7 Design Principles

Information Hiding (IH)

.the primary criteria for system modularization should
concern the hiding of critical design decisions. [David
Parnas]
Hide "difficult design decisions or design decisions which are
likely to change."
Isolates clients from requiring intimate knowledge of the
design to use a module, and from the effects of changing
those decisions
What you hide you can change

30/8/2016

CS3201_02 LN Set #7 Design Principles

Cohesion
Quality of single-mindedness or singleness
of purpose
How much (or how little) the internal parts of
something are working on the same issue
and how well they relate to each other
Signs of weak cohesion:
Difficulty in naming
Large tests
Large classes and methods
30/8/2016

CS3201_02 LN Set #7 Design Principles

Method Cohesion
Be as cohesive as possible in levels of
perspective
Methods accomplish functionality by
Code logic in the method (implementation
perspective)
Calling other methods (specification perspective)
Martin Fowlers Perspectives :
conceptual, specification, implementation
30/8/2016

CS3201_02 LN Set #7 Design Principles

10

Fowlers perspectives
Conceptual
What I am responsible for?

Specification
How I am used by others ?

Implementation
How I accomplish my responsibilities ?
Martin Fowlers Blog:
http://www.martinfowler.com/
30/8/2016

CS3201_02 LN Set #7 Design Principles

11

Class Cohesion
A strongly cohesive class is difficult to break
up into multiple classes.
Ask :
How hard it would be?
How much of each component class would have
to be exposed through public methods to other
component classes ? If the number is high, then
likely the class is cohesive to begin with.
30/8/2016

CS3201_02 LN Set #7 Design Principles

12

Coupling
One part of a system affects another part of
the system
Its not bad in all cases
We do not want coupling that
We did not intend
We did intend but we dont actually need

Intentional vs Accidental | Good vs Bad |

Loose vs Tight
30/8/2016

CS3201_02 LN Set #7 Design Principles

13

Coupling
Indicators of accidental coupling
Unexpected side effects of a change
Hesitancy in making a change
Comments about what the code is doing

30/8/2016

CS3201_02 LN Set #7 Design Principles

14

Coupling and Cohesion

We want:
high cohesion and
low coupling

But not:
low cohesion and
high coupling

CS3201_02 LN Set #7 Design Principles

15

Separation of Concerns (SoC)

The term separation of concerns was
coined by Edsger W. Dijkstra in his 1974
paper "On the role of scientific thought.

30/8/2016

CS3201_02 LN Set #7 Design Principles

17

SoC
Understand one concern separately from
other concerns
Some concerns are easier to separate than
other:
User interface from business logic
But, it is difficult to separate performance concern
from other aspects of a software system (i.e.,
other concerns)

Separating Use from Creation

30/8/2016

CS3201_02 LN Set #7 Design Principles

18

SoC
Example: Loan Quote System(LQS) Roles
When shopping for a loan, a customer may call several banks to find the
deal with the best possible interest rate. Each bank asks the customer for
his/her IC number, the amount of the loan and the desired term. Each bank
then investigates the customers credit background and responds with an
interest rate quote to the customer (or declines). Once the customer has
received quotes from all banks, he or she can then select the best offer.
Because contacting multiple banks is a tedious task, loan brokers offer this
service to customers. A loan broker is not affiliated with any one bank but
has access to many lending institutions. The broker gathers the customer
data once and contact the credit bureau to obtain the customers credit
history. Based on the credit history, the broker presents the request to a
number of banks that are best suited to meet the customers criteria. The
broker gathers the resulting quotes from the banks and select the best offer to
30/8/2016
19
pass
back to the customer.

SoC
Example: Loan Quote System(LQS)
Responsibilities and Interactions

SoC - Perspective of use

In order for one object to use another, it must
have access to the public methods it exports
The using object should ideally be
coupled only to an abstraction ie it must
usually know one of the following:
An interface the object being used implements
A base class the object being used is derived
from
30/8/2016

CS3201_02 LN Set #7 Design Principles

21

SoC - Perspective of creation

An object could also be coupled with
another object by the way of creation
Principle: Relationship between two
entities A and B should be limited so that A
makes B or A uses B, but never both.

30/8/2016

CS3201_02 LN Set #7 Design Principles

22

More Design Principles

You are encouraged to self-learn and use
these
Interface
Segregation
(IS)

Dependency
Inversion (DI)

SOLID
(SRP, OCP,
LSP, IS, DI)
30/8/2016

Liskov
Substitution
Principle (LSP)

Redundancy
Dont Repeat
Yourself (DRY)
CS3201_02 LN Set #7 Design Principles

Open Close
Principle
(OCP)

Design to
Interface (D2I)

24

Applying Design Principles

Design for change
How do we design programs for ease of
change?

Techniques
Decomposition, modularization, layered design
Low coupling and high cohesion
Information hiding and APIs

Inheritance (sometimes)
Parameterization
Function parameters
Class: generics (Java) or templates (C++)
Typedef

Table-driven technique
Store many related parameters in a data structure (table)
Implement generic code that refers to the parameter table
CS3202 Set#3 Design

26

How to Decompose?
This is the key to success
Most experienced developers in a company do that!

1. Make modules highly cohesive

Focused on a group of highly related tasks
An easy test: describe the modules role and function

2. Minimize couplings among modules

Any interactions or dependencies

3. Organize modules into layers

Strive for simple interactions among layers
CS3202 Set#3 Design

27

Coupling and Cohesion

We want this:
high cohesion and
low coupling

Why?

But not that:

low cohesion and
high coupling

CS3202 Set#3 Design

28

High Cohesion and Low Coupling

Treat modules as black boxes, independently
of each other
But why is it good to have black-box
modules?
Work on modules independently
Change one module with minimum impact on
other modules (ripple effects of changes)

Can we achieve total module independence?

Zero module coupling?
CS3202 Set#3 Design

29

Modules API and Private Part

API
Module

Public: interface
Hidden, Private:
implementation

Let others use the module without knowing all the

module details
Change a module without affecting other modules
API: A description of what you can do with a module.
Abstraction and information hiding
CS3201 LN Set #3

30

Reminder
Do not shift all the principles to extremes,
because in real cases it is impossible to
achieve them from all point of views.

--The End--