This document discusses key software design principles: 1. Modularization, abstraction, and encapsulation aim to break down a system into independent and cohesive modules that hide unnecessary details. 2. Coupling and cohesion measure the interdependence between modules - loose coupling and high cohesion where related code is grouped together are ideal. 3. Other principles like separation of interface and implementation, sufficiency, and completeness focus on defining clean interfaces and providing only necessary functionality. The document provides examples and comparisons to explain these fundamental software design concepts.

1. SOFTWARE DESIGN PRINCIPLES
CRISTAL NGO
ICT2106 – SOFTWARE DESIGN – WEEK 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-grained components 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 connection
Simplifies reasoning about behavioural
operations containing a sequence of
steps
9

9. DATA ABSTRACTION
MESSAGE is an example of the data abstraction; the details of a
MESSAGE can 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
essential to carry out such services while hiding details of how the
services are carried out.
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 dependencies Loosely 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 p modifies a statement of module q
2. Module p refers to local data of module q (in terms of a
numerical displacement)
3. Module p branches 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
variable, 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 is defined as the degree to which all elements
of a module, class, or component work together as a
functional unit. High cohesion is good, and low cohesion is
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 means keeping parts of a code base that are
related to each other in a single place. Low coupling, at the same
time, is about separating 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
semantics of the domain.

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.
Completenessandsufficiency
46

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