INTRODUCTION TO OBJECTS
Chapter 6
UHD::CS3320::CHAP6
1
WHAT IS A MODULE?
• A lexically contiguous sequence of program
statements, bounded by boundary elements,
with aggregate identifier.
• Methods for breaking up product into
modules?
UHD::CS3320::CHAP6
2
EXAMPLE
• A computer architect decides to build an ALU,
shifter and 16 registers using AND, OR and
NOT gates (rather than NAND or NOR gates).
UHD::CS3320::CHAP6
3
UHD::CS3320::CHAP6
4
COMPUTER DESIGN--CNTD
• Computer architect realizes that it is better to
build a chip using one type of gates
==> Partitions the system so that one gate type on
each chip.
UHD::CS3320::CHAP6
5
COMPUTER DESIGN--CNTD
• Two designs functionally equivalent
• Second design
– hard to understand
– hard to locate faults
– difficult to extend or enhance
– cannot be reused in another product
• Modules must be selected with
– maximal relationships within modules
– minimal relationships between modules
UHD::CS3320::CHAP6
6
COMPOSITE/STRUCTURED
DESIGN
• Method for breaking up product into modules
for
– maximal relationships within modules
– minimal relationships between modules
• Module cohesion
– Degree of interaction within module
• Module coupling
– Degree of interaction between modules
UHD::CS3320::CHAP6
7
C/SD--CONTD
• Module: function, logic, and context
• A module is identified with its function
Example: a module computes square root of
double precision integers using Newton’s
algorithm
• Module should be names compute square root
UHD::CS3320::CHAP6
8
MODULE COHESION
• Seven categories or levels of cohesion:
1. Coincidental cohesion
(worst)
2. Logical cohesion
should be avoided
3. Temporal cohesion
4. Procedural cohesion
5. Communicational cohesion
6. Informational cohesion
7. Functional cohesion
desirable
(best)
UHD::CS3320::CHAP6
9
1. Coincidental Cohesion
• Module performs multiple, completely
unrelated actions
• Example:
– Module: print next line, reverse string of
characters in second argument, add 7 to
third argument, convert fourth argument to
floating point
• Why is Coincidental Cohesion so bad?
– Degrades maintainability
– No reuse
UHD::CS3320::CHAP6
10
2. Logical Cohesion
• Module performs series of related actions, each
is selected by setting the value of a parameter
• Example:
– Module performs all input and output ops
• Why is logical Cohesion so bad?
– Interface difficult to understand
– Code for more than one action may be
intertwined
– Difficult to reuse
UHD::CS3320::CHAP6
11
3. Temporal Cohesion
• Module performs a series of actions related in
time
• Example:
– open input file, open output file, initialize
table of records, read first record (i.e.
Initialization actions)
• Why is temporal cohesion so bad?
– Actions weakly related to one another, but
strongly related to other actions in other
modules
UHD::CS3320::CHAP6
12
4. Procedural cohesion
• Module performs series of actions related by
procedure to be followed in product.
• Example:
– read part number then update repair record
• Why is procedural cohesion so bad?
– Actions still weakly connected, so not
reusable.
UHD::CS3320::CHAP6
13
5. Communicational Cohesion
• Module performs series of actions related by
procedure to be followed by product, but in
addition all the actions operate on same data
• Example:
– calculate new coordinates and send them to
terminal
• Still lack of reusability
UHD::CS3320::CHAP6
14
6. Informational Cohesion
• Module performs a number of actions, each
with its own entry point, with independent code
for each action, all performed on same data
structure.
• This is essentially an Abstract Data Type
UHD::CS3320::CHAP6
15
7. Functional Cohesion
• Module with functional cohesion performs
exactly one action
• More reusable
• Maintenance easier
UHD::CS3320::CHAP6
16
Cohesion Case Study
• Compute average daily temperatures at various
sites.
UHD::CS3320::CHAP6
17
Cohesion Case Study
UHD::CS3320::CHAP6
18
Coupling
• Degree of interaction between modules
• File categories of coupling ( some goo some
bad):
1. Content coupling
Worst
2. Common coupling
3. Control coupling
4. Stamp coupling
5. Data coupling
Best
UHD::CS3320::CHAP6
19
Content Coupling
• One module directly references content of
another module.
Example:
– One module branches into local label of
another
– One module references local data of another
UHD::CS3320::CHAP6
20
Common Coupling
• Two modules are commonly coupled if they
have access to global data.
UHD::CS3320::CHAP6
21
Control Coupling
• Two modules are control coupled if one passes
an element of control to another
• Example:
– Module p calls module q
– Module q is supposed count the number of
characters in a text file and return the result
to module p.
– If module q fails (e.g. Can read from file) it
return -1.
==> the two modules are data coupled
UHD::CS3320::CHAP6
22
Control Coupling--Example CNTD
Suppose:
– Module p calls module q
– Module q is supposed count the number of
characters in a text file and return the result
to module p.
– If module q fails (e.g. Can read from file)
returns a message that module p is supposed
to output.
==> the two modules are control coupled
UHD::CS3320::CHAP6
23
Control Coupling-- CNTD
• If q passes information back to p and p decides
what actions to take ==> data coupling
• If q passes information back to p but also
informs p what actions to take ==> control
coupling
• What’s so bad about control coupling
– module are not independent: module q must
know structure and logic of p.
– Affects reuse
UHD::CS3320::CHAP6
24
Stamp Coupling
• Two modules are stamp coupled if data
structure is passed as parameter, but called
module operates on some but not all of
individual components of data structure.
• What’s so bad about Stamp coupling
– Not clear, without reading entire module
which part of data structure is changed
– Pass more data than necessary
• uncontrolled data access can lead to
security problems
UHD::CS3320::CHAP6
25
Data Coupling
• Two modules are data coupled is all parameters
are homogeneous data items (i.e. Simple data
items, or data structures all of whose elements
are used by called module)
Examples:
• display_time_of_arrival(flight_number)
• Compute_product(first_num, second_num)
• get_job_with_highest_priority(job_queue)
UHD::CS3320::CHAP6
26
Data Coupling--CNTD
• Why is data coupling so good?
– Difficulties of all other couplings not present
– Module interface is explicit
– No side effects
– Maintenance is easier
UHD::CS3320::CHAP6
27
Object-Oriented Paradigm
•
•
•
•
Data Encapsulation
Information Hiding
Inheritance
Polymorphism
UHD::CS3320::CHAP6
28
Data Encapsulation
• Data structure together with the actions done
on those data are encapsulated in the same
“module”--the class
• A class is an Abstract Data Type
• An object is an instance of a class
• Why is encapsulation so good?
– A class is a module with informational
cohesion
– functional cohesion: at the method level
UHD::CS3320::CHAP6
29
UML Representation
ClassName
Data members
Actions
•Short hand notation
ClassName
UHD::CS3320::CHAP6
30
UML Representation
<instance of>
ClassName
objectName
Watch
myHandWatch
UHD::CS3320::CHAP6
31
Data Encapsulation and
Development
• Data Encapsulation allows abstraction during
product analysis and design
• When extracting and design the classes:
– what objects are needed to be modeled?
– what are the data attributes of each object?
– what actions are to be performed on the data
of each object? What are the interactions
between objects
UHD::CS3320::CHAP6
32
Stepwise Refinement
Step 1. Design in terms of high level concepts
– concern with behavior of data structure
Step 2. Design low level components
– concern with implementation of the that
behavior
UHD::CS3320::CHAP6
33
Information Hiding
• Implementation details of the data attributes
and methods of a class are hidden from outside
the class.
• Control access to data attributes
– thru public methods
– private members
• Why is information hiding good ?
– Interaction between classes occurs through explicitly
declared interfaces.
– No side effects: change in one module does not effect
others
– I.e. data coupling between classes.
UHD::CS3320::CHAP6
34
Inheritance
Define HumanBeing to be a class
• A HumanBeing has attributes, such as name, age,
height, gender
• Assign values to attributes when describing object
Define Teacher to be a subclass of HumanBeing
• A Teacher has all attributes if HumanBeing,
plus attributes of his/her own (discipline, school,
department)
• A Teacher inherits all attributes of
HumanBeing
UHD::CS3320::CHAP6
35
UML Representation
HumanBeing
<Sub-class of>
Teacher
UHD::CS3320::CHAP6
36
Inheritance
• Inheritance is essential to object-oriented
language such as Smalltalk, C++, and JAVA
• Does it improve cohesion? Coupling?
• Provides further data abstraction
• Improves reuse
UHD::CS3320::CHAP6
37
Composition/Aggregation
• A class may contain other classes
Example:
A State contains many Counties which contain
many townships
A PoliceState is composed of PoliceOfficers
A Directory contain Files
UHD::CS3320::CHAP6
38
UML Representation-Aggregation
State
County
UHD::CS3320::CHAP6
Township
39
Polymorphism
• Classical paradigm
– function sort_integer_list
– function sort_float_list
– function sort_string_list
• must explicitly invoke correct version
UHD::CS3320::CHAP6
40
ListClass
virtual method sort
IntListClass
StringListClass
Implementation of
method integer sort
Implementation of
method string sort
FloatListClass
Implementation of
method float sort
• All that is needed is myList.sort( )
– correct method is invoked dynamically
– Method sort() is polymorphic
UHD::CS3320::CHAP6
41
Summary
Objects with high cohesion and low coupling
Objects
Information Hiding
Abstract Data Types
Data Encapsulation
Modules with high cohesion and low coupling
Modules
UHD::CS3320::CHAP6
42