From Modules to Objects
Professor James Landay
CS169: Software Engineering
Spring 2001
February 14, 2001
2/14/2001
1
Outline
Review
Modules
Cohesion
Administrivia
Coupling
Encapsulation & ADTs
2/14/2001
2
Review
Testing doesn’t show the absence of bugs
Major assumptions of testing
inference from behavior, known environment, choosing
the right test cases
Why shouldn’t SEs do all their own testing?
What to test?
utility, reliability, robustness, performance, correctness
Why is correctness not enough?
the spec might be bad!
When are correctness proofs useful?
if the benefits outweigh the costs (lives, space, etc.)
2/14/2001
3
Modules
What is a module?
lexically contiguous sequence of program
statements, bounded by boundary elements,
with aggregate identifier
Examples
procedures & functions in classical PLs
objects & methods within objects in OO PLs
2/14/2001
4
Good vs. Bad Modules
Modules in themselves are not “good”
Must design them to have good properties
i) CPU using 3 chips (modules)
ii) CPU using 3 chips (modules)
Chi p 2
Chi p 1
Chi p 1
Chi p 2
OR ga te s
AND g ates
Reg iste rs
ALU
ALU
Chi p 3
Shi fte r
SHIFTER
Chi p 3
2/14/2001
What is the problem here?
NOT g ate s
5
Good vs. Bad Modules
Two designs functionally equivalent, but the 2nd is
hard to understand
hard to locate faults
difficult to extend or enhance
cannot be reused in another product. Implication?
-> expensive to perform maintenance
Good modules must be like the 1st design
maximal relationships within modules (cohesion)
minimal relationships between modules (coupling)
this is the main contribution of structured design
2/14/2001
6
Modules to Objects
2/14/2001
Objects with high cohesion and low coupling

Objects

Information hiding

Abstract data types

Data encapsulation

Modules with high cohesion and low coupling

Modules
7
Cohesion
?
Degree of interaction within module
Seven levels of cohesion
7. Functional | Informational
5. Communicational
4. Procedural
3. Temporal
2. Logical
1. Coincidental
2/14/2001
(best)
(worst)
8
1. Coincidental Cohesion
Def.
?
module performs multiple, completely unrelated actions
Example
module prints next line, reverses the characters of the
2nd argument, adds 7 to 3rd argument
How could this happen?
hard organizational rules about module size
Why is this bad?
degrades maintainability & modules are not reusable
Easy to fix. How?
break into separate modules each performing one task
2/14/2001
9
2. Logical Cohesion
Def.
module performs series of related actions, one of which
is selected by calling module
Example
function code = 7;
new operation (op code, dummy 1, dummy 2, dummy 3);
// dummy 1, dummy 2, and dummy 3 are dummy variables,
// not used if function code is equal to 7
Why is this bad?
interface difficult to understand
code for more than one action may be intertwined
difficult to reuse
2/14/2001
10
3. Temporal Cohesion
Def.
?
module performs series of actions related in time
Initialization example
open old db, new db, transaction db, print db, initialize
sales district table, read first transaction record,
read first old db record
Why is this bad?
actions weakly related to one another, but strongly
related to actions in other modules
code spread out -> not maintainable or reusable
Initialization example fix
define these intializers in the proper modules & then
have an initialization module call each
2/14/2001
11
4. Procedural Cohesion
Def. ?
module performs series of actions related by
procedure to be followed by product
Example
update part number and update repair record in
master db
Why is this bad?
actions are still weakly related to one another
not reusable
Solution
break up!
2/14/2001
12
5. Communicational Cohesion
Def.
module performs series of actions related by procedure
to be followed by product, but in addition all the actions
operate on same data
Example 1
update record in db and write it to audit trail
Example 2
calculate new coordinates and send them to window
Why is this bad?
still leads to less reusability -> break it up
2/14/2001
13
7. Informational Cohesion
Def.
module performs a number of actions, each with its
own entry point, with independent code for each action,
all performed on the same data structure
Defi ni tio n o f
sa le s_re gi on _ta bl e
Entry
•• •
Entry
•• •
This is an ADT!
i ni ti al i ze_ sal e s_reg i on _tab l e
Exi t
u pd ate_ sal e s_reg i on _tab l e
•• •
•• •
Exi t
Entry
•• •
•• •
2/14/2001
p ri n t_ sal e s_reg i on _tab l e
14
Exi t
7. Functional Cohesion
Def.
module performs exactly one action
Examples
 get temperature of furnace
 compute orbital of electron
 calculate sales commission
Why is this good?
more reusable
corrective maintenance easier
fault isolation
reduced regression faults
easier to extend product
2/14/2001
15
Coupling
?
Degree of interaction between two
modules
Five levels of coupling
5.
4.
3.
2.
1.
2/14/2001
Data
Stamp
Control
Common
Content
(best)
(worst)
16
1. Content Coupling
Def.
one module directly references contents of the other
Example
module a modifies statements of module b
module a refers to local data of module b in terms of
some numerical displacement within b
module a branches into local label of module b
Why is this bad?
almost any change to b requires changes to a
2/14/2001
17
ccb
cca
2. Common Coupling
Def.
g lo ba l vari ab le
two modules have write access to the same global data
Example
two modules have access to same database, and can
both read and write same record
use of Java public statement
while (global variable == 0)
if (argument xyz > 25)
Why is this bad?
module 3 ();
resulting code is unreadable
else
modules can have side-effects
module 4 ();
must read entire module to understand
difficult to reuse
module exposed to more data than necessary
2/14/2001
18
3. Control Coupling
Def.
one module passes an element of control to the other
Example
control-switch passed as an argument
Why is this bad?
modules are not independent
module b must know the internal structure of module a
affects reusability
2/14/2001
19
4. Stamp Coupling
Def.
data structure is passed as parameter, but called module
operates on only some of individual components
Example
calculate withholding (employee record)
Why is this bad?
affects understanding
not clear, without reading entire module, which fields of record
are accessed or changed
unlikely to be reusable
other products have to use the same higher level data structures
passes more data than necessary
2/14/2001
e.g., uncontrolled data access can lead to computer crime
20
5. Data Coupling
Def.
every argument is either a simple argument or a data
structure in which all elements are used by the called
module
Example
display time of arrival (flight number)
get job with highest priority (job queue)
Slippery slope between stamp & data (see queue)
Why is this good?
maintenance is easier
good design has high cohesion & weak coupling
2/14/2001
21
Modules to Objects
2/14/2001
Objects with high cohesion and low coupling

Objects

Information hiding

Abstract data types

Data encapsulation

Modules with high cohesion and low coupling

Modules
22
Data Encapsulation
?
 Def.
data structure together with actions
to be performed on that structure
m_ 12 3
 Bad job queue example
{
j o b j ob _a , j ob _b ;
im pl em en ta tio n o f
j ob _q ue ue
• • •
i ni tia l ize_ jo b_ qu eu e ()
{
•• •
•• •
•• •
•• •
}
ad d_ j ob _to_ qu eu e (j ob j )
{
•• •
•• •
•• •
}
}
remo ve _j ob _from _q ue ue (j ob
{
•••
•• •
2/14/2001
re move_ jo b_ fro m_ qu eu e (jo b_ b);
•• •
easier development & maintenance
helps us cope w/ change
a dd _j o b_ to _q ue ue (j o b_ a);
•• •
 Abstraction or stepwise refinement
i n iti al i ze _j ob _q ue ue ();
•• •
put all job queue ops together w/ 1
definition of job queue in 1 module
informational cohesion & data
encapsulation
•• •
define job queue w/ 1 op together in
module (repeat for init, add, etc.)
low cohesion
 Better job queue example
m_ en cap sul a ti o n
}
23
Abstract Data Types
Def.
data type together with actions to be performed on
instantiations of that data type
subtle difference with encapsulation
Example
class JobQueue {
public int
queueLength;
// length of job queue
public int
queue = new int[25];
// up to 25 jobs
// methods
public void initializeJobQueue (){
// body of method
}
public void addJobToQueue (int jobNumber){
// body of method
}
} // JobQueue
2/14/2001
24
Information Hiding
Really “details hiding”
hiding implementation details, not information
Example
design modules so that items likely to change are
hidden
future change localized
change cannot affect other modules
data abstraction
designer thinks at level of ADT
2/14/2001
25
Information hiding
Example
class JobQueue {
private int
queueLength;
// length of job queue
private int
queue = new int[25];
// up to 25 jobs
// methods
public void initializeJobQueue (){
// body of method
}
public void addJobToQueue (int jobNumber){
// body of method
}
} // JobQueue
Now queue and queueLength are inaccessible
2/14/2001
26
Objects
 Def.
class – abstract data type which supports inheritance
objects are instantiations of classes
 Inheritance
new data types defined as extensions to previously defined types
don’t have to define from scratch -> provides more data abstraction
Example
Define humanBeing to be a class
A humanBeing has attributes, such as age, height, gender
Assign values to attributes when describing object
2/14/2001
Define parent to be a subclass of humanBeing
A parent has all attributes of humanBeing, plus attributes of his/her own
(name of oldest child, number of children)
27
A parent inherits all attributes of humanBeing
Inheritance (UML)
HumanBeing
(base class)
UML notation:
boxes represent classes
open triangle represent inheritance
inherits from(“isA ”)
Parent
derived
part
(derived class)
incremental
part
2/14/2001
28
Inheritance (Java)
class HumanBeing
{
private
int
private
float
age;
height;
public
// declarations of operations on HumanBeing
} // class HumanBeing
class Parent extends HumanBeing
{
private
String
private
int
nameOfOldestChild;
numberOfChildren;
public
// declarations of operations on Parent
} // class Parent
2/14/2001
29
Inheritance
Bas e
Method Foo (b : Base) can be applied to
objects of any subclass of Base
2/14/2001
30
Aggregation (UML)
PersonalComputer
UML notation:
diamond (1 or more)
no diamond (1)
CPU
Monitor
Keyboard
Printer
Aggregation refers to the components of a class
- used to group related items
- each of these (CPU, etc.) would be instance var
2/14/2001
31
Polymorphism & Dynamic Binding
Classical paradigm
function draw_rectangle
function draw_circle
function draw_line
must explicitly invoke the correct version
2/14/2001
32
Polymorphism & Dynamic Binding
 Object-oriented paradigm
GraphObjClass
method draw
RectClass
Implementation of
method draw
for a rectangle
CircleClass
Implementation of
method draw
for a circle
LineClass
Implementation of
method draw
for a line
all that is needed is myGraphObj.draw()
 Dynamic binding
correct method invoked at run-time (dynamically)
 Polymorphic
method draw can be applied to objects of different classes
2/14/2001
33
Polymorphism & Dynamic Binding
Advantages
?
can build for the future
easy to add a new shape w/o changing previous code
• don’t ever want to mess w/ code that works
easy to iterate over similar but distinct objects
draw all GraphObjs
Disadvantages
?
performance (have to look things up at run time)
have to design classes better
have to understand how it will be extended over time
harder to understand the code
must understand multiple possibilities for specific method
2/14/2001
34
Advantages of Objects
Same as abstract data types
information hiding
data abstraction
procedural abstraction
start code design at high level & continue down
levels until using primitives
Inheritance provides further data abstraction
easier and less error-prone product development
easier maintenance
2/14/2001
35
Summary
Good modules have strong cohesion and
weak coupling
Data encapsulation, ADTs, information
hiding, & objects ease maintenance & reuse
Polymorphism has advantages &
disadvantages
2/14/2001
36
Next Time
Questions?
Friday’s lecture on Requirements
read Chapter 9 from Schach
2/14/2001
37