software design principles

Illustrate general good design principles in software engineering such as low coupling, high cohesion, modularity, abstraction, separation of interface and implementation. With examples.

1. SOFTWARE DESIGN PRINCIPLES
C
RISTAL
N
GO
ICT2106 –S
OFTWARE
D
ESIGN
–W
EEK
2

2. PREVIOUSLY IN ICT2106
–What is software design?
–Importance of software design
–Software design process
–What is a good design/software/process
2

3. READING
–Software engineering design, Carlos Otero,
Chapter 1 (Software Design Fundamentals)
4

4. GENERAL DESIGN PRINCIPLES
1.Modularization
2.Abstraction
3.Encapsulation
4.Coupling 5.Cohesion 6.Separation of interface and implementation 7.Sufficiency 8.Completeness
5

5. PRINCIPLE #1: MODULARIZATION
Modularization is the process of continuous decomposition
of the software system until fine-grainedcomponents are
created.
When you modularize a design, you are also modularizing the
requirements, programming and test cases.
6

6. PRINCIPLE #2: ABSTRACTION
Abstraction is “a
view
of an object
that focuses on the information
relevant
to a particular purpose and
ignores the remainder of the
information”
7

7. ABSTRACTION
Abstraction can be employed to extract essential
characteristics of:
Procedures or
behavior
Data
8

8. PROCEDURAL ABSTRACTION
SEND(client, server, message)
1. Client retrieves the serverʼs information,
2. opens a TCP/IP connection,
3. sends the message, waits for response, and
4. closes the connectionSimplifies reasoning about behavioural
operations containing a sequence of
steps
9

9. DATA ABSTRACTION
MESSAGEis an example of the data abstraction; the details of a
MESSAGEcan be deferred to later stages of the design phase.
SEND(client, server, message)
Simplifies reasoning
about structural
composition of data
objects
10

10. PRINCIPLE #3: ENCAPSULATION
Encapsulation
deals with providing access to
services
of
abstracted entities by exposing only the information that is
essentialtocarryoutsuchserviceswhile
hidingdetails
ofhowthe
servicesarecarriedout.
Information hiding
: Internal details (state,
structure, behavior) become the objectʼs
secret
11

11. ENCAPSULATION & INFORMATION HIDING
–One can think of information hiding as the
principle and encapsulation as the technique
–Encapsulation is the public interface that
defines how an object can be used, and how
its data is derived.
–Information Hiding prevents an external object
from using the derived data altogether
13

12. ENCAPSULATION & INFORMATION HIDING
class Automobile extends Vehicle {
public final static int EMPTY = 0;
public final static int FULL = 1;
public int tank = EMPTY;
}
Neither Encapsulation nor Information Hiding
14

13. ENCAPSULATION & INFORMATION HIDING
class Automobile extends Vehicle {
public final static int EMPTY = 0;
public final static int FULL = 1;
private int tank = EMPTY;
public int getTankStatus() {
return this.tank;
}
public void setTankStatus( int status ){
this.tank = status;
}
}
The status of the
tank is now
encapsulated
, but
NOT HIDDEN
from the
rest of the system.
15

14. class Automobile extends Vehicle {
private final static int EMPTY = 0;
private final static int FULL = 1;
private int tank = EMPTY;
private int tank() {…}
private void tank( int status ) {…}
public void fillUp() {
tank( FULL );
}
public void depleteOzone() throws GasExhaustedException {
if( tank() == FULL ) {
tank( EMPTY );
}
else {
throw new GasExhaustedException();
}
}
}
A simple interface fully
Encapsulates and Hides
Information:
fillUp()
and
depleteOzone().
No other object in the
system can use, or know
the state of, the gas
tank.
16

15. MODULARIZATION, ABSTRACTION & ENCAPSULATION
Focus on
essential
characteristics
of entities
Enforce that we
only expose
essential information
17

16. PRINCIPLE #4: COUPLING The
higher
the
coupling
The
higher the
dependency
Refers to the manner and degree of
interdependence
between software modules.
Measurement of
dependency
between units.
18

17. COUPLING: DEGREE OF DEPENDENCE AMONG COMPONENTS
No dependenciesLoosely coupled-
some dependencies
Highly coupled-
many
dependencies
High coupling
makes modifying parts of the system
difficult
, e.g.,
modifying
a

component affects all the components to which the component is connected
19

18. Content
Common
Control
Stamp
Data
TIGHT COUPLING LOOSE COUPLING More interdependency
More coordination
More information flow
Less interdependency
Less coordination
Less information flow
21

19. CONTENT COUPLING
Definition: A module directly references the
content of another module
1.Module pmodifies a statement of module q
2.Module prefers to local data of module q(in terms of a
numerical displacement)
3.Module pbranches to a local label of module q
22

20. COMMON COUPLING
–Using global variables (i.e.,
global coupling
)
–All modules have read/write access to a global
data block
–Modules exchange data using the global data
block (instead of arguments)
Single module with
write access
where all other modules have

read access
is not common coupling
23

21. COMMON COUPLING -
EXAMPLE
while( global_variable> 0 ){ 
switch( global_variable){ 
case 1: function_a(); break;
case 2: function_b(); break;
...
case n: ...
}
global_variable++;
}
If
function_a(),
function_b(),
etc
can modify the

value of global

v
ariable,

then

it

can be
extremely
difficult to
track the
execution of

this loop
24

22. STAMP COUPING
Occurs when too much information is passed to
a function.
typedef struct rectangle
{
int length;
int width; 
int area;
int perimeter;
int color;
double diagonal;
char symbol;
} RECTANGLE;
RECTANGLE CalcArea (RECTANGLE r)
{
r.area = r.width * r.length;
return r;
}
We are passing an entire RECTANGLE to this function,
even though the function really does not need to see or
modify all of the members.
25

23. DATA COUPLING
Process
Results
Calculate
Grade
mark grade
Two modules are data coupled if they communicate by passing parameters and no extra data are passed.
Data coupling exhibits the properties
that all parameters to a module are
either simple data types, or in the case
of a record
being passed as a parameter
,
all
data members
of that record are
used/required
by the module.
26

24. DATA COUPLING –MORE EXAMPLE
typedef struct rectangle
{
int length;
int width; 
int area;
int perimeter;
int color;
double diagonal;
char symbol;
} RECTANGLE;
int CalcArea(int width, int length)
{
int area;
area = width * length;
return area;
}
This is a better way to write the previous program. Here
we will be passing and returning only primitive data types.
They are all that is really needed by the functions and
now the functions are more general, too.
27

25. PRINCIPLE #5: COHESION
–The manner and degree to which the tasks
performed by a single software module are
related to one another.
–Measures how well design units are put
together for achieving a particular tasks.
28

26. COUPLING AND COHESION
–Cohesion
isdefinedasthedegreetowhichallelements
of a module, class, or component work together as a
functionalunit.Highcohesionisgood,andlowcohesionis
bad.
–Coupling
is defined as the degree of interdependence
between two or more classes, modules, or
components. Tight coupling is bad, and loose coupling is
good.
29

27. LOOSE COUPLING -HIGH COHESION
30
In essence, high cohesion meanskeeping parts of a code base that are
related to each other in a single place. Low coupling, at the same
time, is aboutseparating unrelated parts of the code base as much
as possible.

28. DEGREE OF
COHESION
High Cohesion
Low Cohesion
31

29. COINCIDENTAL COHESION
This is the weakest form of cohesion. Its
element have no meaningful relationship.
32

30. PROCEDURAL COHESION
–A module has procedural cohesion if all the
operations it performs are related to a sequence of
steps performed in the program.
–For example, if one of the sequence of operations in
the program was “read input from the keyboard,
validate it, and store the answers in global variables”,
that would be procedural cohesion.
33

31. operationA(){
readData(data,filename1);
processAData(data);
storeData(data,filename2);
}
readData(data,filename){ 
f = openfile(filename);
readrecords(f, data);
closefile(f);
}
storeData(data,filename)
{...}
processAData(data)
{...}
Module A
PROCEDURAL
COHESION EXAMPLE
34

32. INFORMATIONAL COHESION
–Information cohesion describe a module performing
a number of operations, each with a unique entry
point and independent code, and all operations are
performed on the same data.
–In information cohesion, each function in a module
must perform exactly one action
35

33. INFORMATIONAL COHESION
The Object-oriented approach naturally produce
designs with informational cohesion
–Each object in general has its own source code/file
–Each object operates on its own data which are
defined within the object.
–Each member function of the object should perform
one unique action/operation/function.
36

34. INFORMATIONAL COHESION EXAMPLE
class Airplane{
private double speed, altitude;
public void takeoff() {…}
public void fly() {…}
public void land() {…}
}
class Airplane
37

35. TYPES OF CODE
FROM A COHESION
AND COUPLING
PERSPECTIVE
38
http://enterprisecraftsmanship.co
m/2015/09/02/cohesion-
coupling-difference/

36. POORLY SELECT BOUNDARIES
as the result of High Coupling Low Cohesion
39
The problem here is that they
are selected improperly and
often do not reflect the actual
semanticsofthedomain.

37. DESTRUCTIVE DECOUPLING
as the result of low coupling, low cohesion
40
It sometimes occurs when a
programmer tries to decouple
a code base so much that the
code completely loses its
focus:

38. SEPARATION OF INTERFACE AND IMPLEMENTATION
This principle involves
defining a component
by specifying a
public
interface
(known to the
client of the
component) that is
separate
from the
details
of how the component
is realized.
Interface Implementation
42

39. SEPARATION VS. ENCAPSULATION
How is this principle different from Encapsulation?
43

40. SEPARATION VS. ENCAPSULATION
“
During encapsulation, interfaces are created to provide
public access to services provided by the design unit while
hiding unnecessary details, which include implementation.
While encapsulation dictates hiding the details of
implementation, the principle of separation dictates their
separation, so that different implementation of the same
interface can be swapped to provide modified or new
behavior.”
44

41. PRINCIPLE #7,8:
COMPLETENESS AND
SUFFICIENCY
–Completeness
measures how well
designed units provide
the required services to
achieve the intent (no
less).
–Sufficiency
measures
how well the designed
units are at providing
only the services that
are sufficient for
achieving the intent
(no more).
45

42. Apple has really come up with lots of smart ideas
to improve simple app like photo editing which
reduces the number of clicks required and still get
the work done.
Completeness and sufficiency
46

43. PRACTICAL DESIGN CONSIDERATIONS Design for minimizing complexity Design for change
49