1
Software Design
Lecture : 11
2
Software Design Components
Ø
Principle
Ø
Criteria(this lecture)
Ø
Techniques (this lecture)
3
4
Range of Cohesion
High Cohesion
Functional
Sequential
Communicational
Procedural
Temporal
Logical
Coincidental
Low
5
Sequential Cohesion
Ø
The output of one component is the input to
another.
Ø
Occurs naturally in functional programming
languages
Ø
6
Example
i.
Retrieve customer Data
ii.
Retrieve customer order
iii.
Generate invoice
iv.
Get and edit input data.
7
Functional Cohesion – Highly
cohesive
Ø
Definition: Every essential element to a single
computation is contained in the component.
Ø
A functionally cohesive module performs one
and only one problem related task.
8
Examples
Ø
Calculate Net Pay
Ø
A complex module with numerous sub modules
may still be functionally cohesive if all of its
subordinate modules are only performed to carry
out the task of the parent module.
9
Scale of Cohesion Vs
Maintainability
10
General Rule of Cohesion
ü
A module will be cohesive if most of the methods defined
in a class use most of the data members most of the time.
If we find different subsets of data within the same
module being manipulated by separate groups of
functions then the module is not cohesive and should be
broken down as shown below.
11
12
Extensibility
ü
Extendibility is the ease of adapting software
products to changes of specification.
13
Extensibility
ü
For small programs change is usually not a
difficult issue; but as software grows bigger, it
becomes harder and harder to adapt.
ü
A large software system often looks to its
maintainers as a giant house of cards in which
pulling out any one element might cause the
14
Extensibility
ü
We need extendibility because at the basis of all
software lies some human phenomenon and
hence indecisiveness
15
Principles for achieving Extensibility
ü
Design simplicity: a simple architecture will always
be easier to adapt to changes than a complex one
ü
Decentralization: the more autonomous the modules,
the higher the likelihood that a simple change will affect
just one module, or a small number of modules, rather
than triggering off a chain reaction of changes over the
whole system.
16
Problem Statement
Ø
In the electric subsystem of the house where
there are electric wires and appliances
running. Each appliance is having it’s own
functionality and working. Each appliance is
having it’s own clear boundary into which it
works.
17
Solution to example
ü
The given scenario is having no interdependency
and each appliance is encapsulated within its
own boundary so the system is having low or no
coupling but high level of cohesion.
ü
Hint for Task ii: “Central”
18
19
20
Open / Close Principle
Ø
Bertrand Meyer: “Software entities like classes,
modules and functions should be closed but open
for extension.
ü
Closed
§
The source code of the module inviolate; no one
is allowed to make changes to the code the
module can be used without risk
21
Open / Close Principle
Ø
Open
§
The module is open for extension according to
new requirements the module can be extended
to behave in new and different ways.
22
Open / Closed Principle
ü
A module that is open for extension is a module
whose behavior can be altered to suit new
requirements.
ü
A module that is closed for modification is a
module whose source code is frozen and cannot
23
The “Open/Closed principle” –
Usage in an object oriented
paradigm
Ø
The Open/Closed principle can be applied in
object oriented paradigms with the help of
inheritance and polymorphism:
ü
The interface of the module becomes an abstract
class A
24
What is Class
ü
Basic implementation unit in OOP.
ü
It encapsulate data members and methods.
ü
ü
Classes have objects or classes are assessed via
their objects.
Data members are accessed through getters and
setters methods.
25
public class test
{
int a ;
float b;
public class()
{}
void seta(int a)
{