Slide 7.

Object-Oriented and
Classical Software
Engineering
Fifth Edition, WCB/McGraw-Hill, 2002

Stephen R. Schach
srs@vuse.vanderbilt.edu

© The McGraw-Hill Companies, 2002

 CHAPTER 7 Slide 7.2

INTRODUCTION TO
OBJECTS

© The McGraw-Hill Companies, 2002

 Overview Slide 7.3

● What is a module?
● Cohesion
● Coupling
● Data encapsulation product maintenance
● Abstract data types
● Information hiding
● Objects
● Inheritance, polymorphism and dynamic
binding
● Cohesion and coupling of objects

© The McGraw-Hill Companies, 2002

 Introduction to Objects Slide 7.4

● What is a module?
– A lexically contiguous sequence of program statements,
bounded by boundary elements, with an aggregate
identifier

© The McGraw-Hill Companies, 2002

 Design of Computer Slide 7.5

● A highly incompetent
computer architect
decides to build an
ALU, shifter and 16
registers with AND,
OR, and NOT gates,
rather than NAND or
NOR gates.

© The McGraw-Hill Companies, 2002

 Design of Computer (contd) Slide 7.6

● Architect designs
3 silicon chips

© The McGraw-Hill Companies, 2002

 Design of Computer (contd) Slide 7.7

● Redesign
with one gate
type per chip
● Resulting
“masterpiece”

© The McGraw-Hill Companies, 2002

 Computer Design (contd) Slide 7.8

● The two designs are functionally

equivalent
– Second design is
» Hard to understand
» Hard to locate faults
» Difficult to extend or enhance
» Cannot be reused in another product
● Modules must be like the first design
– Maximal relationships within modules,
minimal relationships between modules

© The McGraw-Hill Companies, 2002

 Composite/Structured Design Slide 7.9

● Method for breaking up a product into modules for

– Maximal interaction within module, and
– Minimal interaction between modules
● Module cohesion
– Degree of interaction within a module
● Module coupling
– Degree of interaction between modules

© The McGraw-Hill Companies, 2002

 Function, Logic, and Context of module Slide 7.10

● In C/SD, the name of a module is its function

● Example
– Module computes square root of double precision
integers using Newton’s algorithm. Module is
named compute square root

© The McGraw-Hill Companies, 2002

 Cohesion Slide 7.11

● Degree of interaction within a module

● Seven categories or levels of cohesion
(non-linear scale)

© The McGraw-Hill Companies, 2002

 1. Coincidental Cohesion Slide 7.12

● A module has coincidental cohesion if it performs

multiple, completely unrelated actions
● Example
– print next line, reverse string of characters comprising second
parameter, add 7 to fifth parameter, convert fourth parameter to
floating point
● Arise from rules like
– “Every module will consist of between 35 and 50
statements”

© The McGraw-Hill Companies, 2002

 Why Is Coincidental Cohesion So Bad? Slide 7.13

● Degrades maintainability
● Modules are not reusable
● This is easy to fix
– Break into separate modules each performing one task

© The McGraw-Hill Companies, 2002

 2. Logical Cohesion Slide 7.14

● A module has logical cohesion when it performs a

series of related actions, one of which is selected
by the calling module
● Example 1
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
● Example 2
– Module performing all input and output
● Example 3
– One version of OS/VS2 contained logical cohesion
module performing 13 different actions. Interface
contained 21 pieces of data
© The McGraw-Hill Companies, 2002
 Why Is Logical Cohesion So Bad? Slide 7.15

● The interface is difficult to understand

● Code for more than one action may be intertwined
● Difficult to reuse

© The McGraw-Hill Companies, 2002

Why Is Logical Cohesion So Bad? (contd) Slide 7.16

● A new tape unit is installed

● What is the effect on the laser printer?

© The McGraw-Hill Companies, 2002

 3. Temporal Cohesion Slide 7.17

● A module has temporal cohesion when it

performs a series of actions related in time
● Example
– open old master file, new master file, transaction file, print file,
initialize sales district table, read first transaction record, read first
old master record (a.k.a. perform initialization)

© The McGraw-Hill Companies, 2002

 Why Is Temporal Cohesion So Bad? Slide 7.18

● Actions of this module are weakly related to

one another, but strongly related to actions in
other modules.
– Consider sales district table

● Not reusable

© The McGraw-Hill Companies, 2002

 4. Procedural Cohesion Slide 7.19

● A module has procedural cohesion if it

performs a series of actions related by the
procedure to be followed by the product
● Example
– read part number and update repair record on master file

© The McGraw-Hill Companies, 2002

 Why Is Procedural Cohesion So Bad? Slide 7.20

● Actions are still weakly connected, so module is

not reusable

© The McGraw-Hill Companies, 2002

 5. Communicational Cohesion Slide 7.21

● A module has communicational cohesion if it

performs a series of actions related by the
procedure to be followed by the product, but in
addition all the actions operate on the same
data
● Example 1
– update record in database and write it to audit trail
● Example 2
– calculate new coordinates and send them to terminal

© The McGraw-Hill Companies, 2002

Why Is Communicational Cohesion So Bad? Slide 7.22

● Still lack of reusability

© The McGraw-Hill Companies, 2002

 7. Informational Cohesion Slide 7.23

● A module has informational cohesion if it performs

a number of actions, each with its own entry point,
with independent code for each action, all
performed on the same data structure

© The McGraw-Hill Companies, 2002

Why Is Informational Cohesion So Good? Slide 7.24

● Essentially, this is an abstract data type

(see later)
© The McGraw-Hill Companies, 2002
 7. Functional Cohesion Slide 7.25

● Module with functional cohesion performs

exactly one action
● Example 1
– get temperature of furnace

● Example 2
– compute orbital of electron

● Example 3
– write to floppy disk

● Example 4
– calculate sales commission
© The McGraw-Hill Companies, 2002
 Why is functional cohesion so good? Slide 7.26

● More reusable
● Corrective maintenance easier
– Fault isolation
– Fewer regression faults
● Easier to extend product

© The McGraw-Hill Companies, 2002

Cohesion Case Study Slide 7.27

© The McGraw-Hill Companies, 2002

 Coupling Slide 7.28

● Degree of interaction between two modules

● Five categories or levels of coupling
(non-linear scale)

© The McGraw-Hill Companies, 2002

 1. Content Coupling Slide 7.29

● Two modules are content coupled if one

directly references contents of the other

● Example 1
– Module a modifies statement of module b

● Example 2
– Module a refers to local data of module b in terms
of some numerical displacement within b

● Example 3
– Module a branches into local label of module b
© The McGraw-Hill Companies, 2002
 Why Is Content Coupling So Bad? Slide 7.30

● Almost any change to b, even recompiling b with

new compiler or assembler, requires change to a
● Warning
– Content coupling can be implemented in Ada through
use of overlays implemented via address clauses

© The McGraw-Hill Companies, 2002

 2. Common Coupling Slide 7.31

● Two modules are common coupled if they have

write access to global data

● Example 1
– Modules cca and ccb can access and change value of
global variable
© The McGraw-Hill Companies, 2002
 2. Common Coupling (contd) Slide 7.32

● Example 2
– Modules cca and ccb both have access to same database,
and can both read and write same record
● Example 3
– FORTRAN common
– COBOL common (nonstandard)
– COBOL-80 global

© The McGraw-Hill Companies, 2002

 Why Is Common Coupling So Bad? Slide 7.33

● Contradicts the spirit of structured programming

– The resulting code is virtually unreadable

© The McGraw-Hill Companies, 2002

Why Is Common Coupling So Bad? (contd) Slide 7.34

● Modules can have side-effects

– This affects their readability
● Entire module must be read to find out what it
does
● Difficult to reuse
● Module exposed to more data than necessary

© The McGraw-Hill Companies, 2002

 3. Control Coupling Slide 7.35

● Two modules are control coupled if one passes

an element of control to the other
● Example 1
– Operation code passed to module with logical
cohesion
● Example 2
– Control-switch passed as argument

© The McGraw-Hill Companies, 2002

 Why Is Control Coupling So Bad? Slide 7.36

● Modules are not independent; module b  

 (the called module) must know internal
structure and logic of module a.
– Affects reusability
● Associated with modules of logical
cohesion

© The McGraw-Hill Companies, 2002

 4. Stamp Coupling Slide 7.37

● Some languages allow only simple

variables as parameters
– part number
– satellite altitude
– degree of multiprogramming
● Many languages also support passing of
data structures
– part record
– satellite coordinates
– segment table

© The McGraw-Hill Companies, 2002

 4. Stamp Coupling (contd) Slide 7.38

● Two modules are stamp coupled if a data

structure is passed as a parameter, but the
called module operates on some but not all of
the individual components of the data structure

© The McGraw-Hill Companies, 2002

 Why Is Stamp Coupling So Bad? Slide 7.39

● It is not clear, without reading the entire module,

which fields of a record are accessed or changed
– Example
calculate withholding (employee record)
● Difficult to understand
● Unlikely to be reusable
● More data than necessary is passed
– Uncontrolled data access can lead to computer crime
● There is nothing wrong with passing a data
structure as a parameter, provided all the
components of the data structure are accessed
and/or changed
invert matrix (original matrix, inverted matrix);
print inventory record (warehouse record);
© The McGraw-Hill Companies, 2002
 5. Data Coupling Slide 7.40

● Two modules are data coupled if all

parameters are homogeneous data items
[simple parameters, or data structures all of
whose elements are used by called module]

● Examples
– display time of arrival (flight number);
– compute product (first number, second number);
– get job with highest priority (job queue);

© The McGraw-Hill Companies, 2002

 Why Is Data Coupling So Good? Slide 7.41

● The difficulties of content, common, control, and

stamp coupling are not present
● Maintenance is easier

© The McGraw-Hill Companies, 2002

Coupling Case Study Slide 7.42

© The McGraw-Hill Companies, 2002

 Coupling Case Study (contd) Slide 7.43

● Interface description
© The McGraw-Hill Companies, 2002
 Coupling Case Study (contd) Slide 7.44

● Coupling between all pairs of modules

© The McGraw-Hill Companies, 2002

 Coupling Case Study (contd) Slide 7.45

● Good design has high cohesion and low coupling

– What else characterizes good design?

© The McGraw-Hill Companies, 2002

 Summary Slide 7.46

© The McGraw-Hill Companies, 2002

 Data Encapsulation Slide 7.47

● Example
– Design an operating system for a large mainframe
computer. It has been decided that batch jobs
submitted to the computer will be classified as high
priority, medium priority, or low priority. There must be
three queues for incoming batch jobs, one for each job
type. When a job is submitted by a user, the job is
added to the appropriate queue, and when the operating
system decides that a job is ready to be run, it is
removed from its queue and memory is allocated to it
● Design 1 (Next slide)
– Low cohesion—operations on job queues are spread all
over product

© The McGraw-Hill Companies, 2002

Data Encapsulation — Design 1 Slide 7.48

© The McGraw-Hill Companies, 2002

Data Encapsulation — Design 2 Slide 7.49

© The McGraw-Hill Companies, 2002

 Data Encapsulation Slide 7.50

●
m_encapsulation has informational cohesion
●
m_encapsulation is an implementation of data
encapsulation
– Data structure (job_queue) together with
operations performed on that data structure
● Advantages
– Development
– Maintenance

© The McGraw-Hill Companies, 2002

 Data Encapsulation and Development Slide 7.51

● Data encapsulation is an example of

abstraction
● Job queue example
– Data structure
» job_queue
– Three new functions
» initialize_job_queue
» add_job_to_queue
» delete_job_from_queue
● Abstraction
– Conceptualize problem at higher level
» job queues and operations on job queues
– not lower level
» records or arrays
© The McGraw-Hill Companies, 2002
 Stepwise Refinement Slide 7.52

● 1. Design in terms of high level concepts

– It is irrelevant how job queues are implemented
● 2. Design low level components
– Totally ignore what use will be made of them
● In 1st step, assume existence of lower level
– Concern is the behavior of the data structure
» job_queue
● In 2nd step, ignore existence of high level
– Concern is the implementation of that behavior
● In a larger product, there will be many levels
of abstraction

© The McGraw-Hill Companies, 2002

 Data Encapsulation and Maintenance Slide 7.53

● Identify aspects of product likely to change

● Design product so as to minimize the effects of
change
– Data structures are unlikely to change
– Implementation may change
● Data encapsulation provides a way to cope with
change

© The McGraw-Hill Companies, 2002

Implementation of Class JobQueue Slide 7.54

C++

Java
© The McGraw-Hill Companies, 2002
Implementation of queueHandler Slide 7.55

C++ Java

© The McGraw-Hill Companies, 2002

Data Encapsulation and Maintenance (contd) Slide 7.56

● What happens if queue is now implemented as a

two-way linked list of JobRecord?
– Module that uses JobRecord need not be changed at
all, merely recompiled

– C++

Java
© The McGraw-Hill Companies, 2002
 Abstract Data Types Slide 7.57

● Problem with both implementations

– Only one queue
● Need
– We need:
Data type + operations performed on instantiations of
that data type
● Abstract data type

© The McGraw-Hill Companies, 2002

 Abstract Data Type Slide 7.58

● (Problems caused by public attributes solved later)

© The McGraw-Hill Companies, 2002
 Information Hiding Slide 7.59

● Data abstraction
– Designer thinks at level of an ADT
● Procedural abstraction
– Define a procedure—extend the language
● Instances of a more general design
concept, information hiding
– Design the modules in way that items likely to
change are hidden
– Future change is localized
– Changes cannot affect other modules

© The McGraw-Hill Companies, 2002

 Information Hiding (contd) Slide 7.60

● C++ abstract
data type
implementation
with information
hiding

© The McGraw-Hill Companies, 2002

 Information Hiding (contd) Slide 7.61

● Effect of information hiding via private attributes

© The McGraw-Hill Companies, 2002
Major Concepts of Chapter 7 Slide 7.62

© The McGraw-Hill Companies, 2002

 Objects Slide 7.63

● First refinement
– Product is designed in terms of abstract data
types
– Variables (“objects”) are instantiations of
abstract data types
● Second refinement
– Class: abstract data type that supports
inheritance
– Objects are instantiations of classes

© The McGraw-Hill Companies, 2002

 Inheritance Slide 7.64

● Define humanBeing to be a class

– A humanBeing has attributes, such as age, height,
gender
– Assign values to attributes when describing object
● Define Parent to be a subclass of HumanBeing
– A Parent has all attributes of a HumanBeing, plus attributes
of his/her own (name of oldest child, number of children)
– A Parent inherits all attributes of humanBeing
● The property of inheritance is an essential feature
of object-oriented languages such as Smalltalk,
C++, Ada 95, Java (but not C, FORTRAN)

© The McGraw-Hill Companies, 2002

 Inheritance (contd) Slide 7.65

● UML notation
– Inheritance is represented by a large open triangle
© The McGraw-Hill Companies, 2002
Java implementation Slide 7.66

© The McGraw-Hill Companies, 2002

 Aggregation Slide 7.67

● UML Notation

© The McGraw-Hill Companies, 2002

 Association Slide 7.68

● UML Notation

© The McGraw-Hill Companies, 2002

 Equivalence of Data and Action Slide 7.69

● Classical paradigm
– record_1.field_2
● Object-oriented paradigm
– thisObject.attributeB
– thisObject.methodC ()

© The McGraw-Hill Companies, 2002

Polymorphism and Dynamic Binding Slide 7.70

● Classical paradigm
– Must explicitly invoke correct
version

© The McGraw-Hill Companies, 2002

Polymorphism and Dynamic Binding (contd) Slide 7.71

● Object-oriented paradigm

© The McGraw-Hill Companies, 2002

Polymorphism and Dynamic Binding (contd) Slide 7.72

● All that is needed is myFile.open()

– Correct method invoked at run-time (dynamically)
● Method open can be applied to objects of
different classes
– Polymorphic

© The McGraw-Hill Companies, 2002

Polymorphism and dynamic binding (contd) Slide 7.73

● Method checkOrder (b : Base) can be applied

to objects of any subclass of Base
© The McGraw-Hill Companies, 2002
Polymorphism and Dynamic Binding (contd) Slide 7.74

● Can have a negative impact on maintenance

– Code is hard to understand if there are multiple
possibilities for a specific method
● Polymorphism and dynamic binding
– Strength and weakness of the object-oriented
paradigm

© The McGraw-Hill Companies, 2002

 Cohesion and Coupling of Objects Slide 7.75

● No such thing!
– Object-oriented cohesion and coupling always reduces
to classical cohesion
● The only feature unique to the object-oriented
paradigm is inheritance
– Cohesion has nothing to do with inheritance
– Two objects with the same functionality have the same
cohesion
– It does not matter if this functionality is inherited or not
– Similarly, so-called object-oriented coupling always
reduces to classical coupling

© The McGraw-Hill Companies, 2002

 Object-Oriented Metrics (contd) Slide 7.76

● Two types of so-called object-oriented metric

– Not related to inheritance
» Reduces to a classical metric
– Inheritance-related
» May reduce to a classical metric
● No problem
– Classical metrics work just fine
– But don’t mislead others by calling them object-
oriented

© The McGraw-Hill Companies, 2002

 Summary Slide 7.77

© The McGraw-Hill Companies, 2002

 Advantages of Objects Slide 7.78

● Same as as advantages of abstract data types

– Information hiding
– Data abstraction
– Procedural abstraction
● Inheritance provides further data abstraction
– Easier and less error-prone product development
– Easier maintenance
● Objects are more reusable than modules with
functional cohesion
– (See next chapter)

© The McGraw-Hill Companies, 2002