UHD::CS3320::CHAP61 INTRODUCTION TO OBJECTS Chapter 6.

UHD::CS3320::CHAP6 1

INTRODUCTION TO OBJECTS

Chapter 6


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?


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).



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.


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


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


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


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 desirable

7. Functional cohesion (best)


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


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


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


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.


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


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


7. Functional Cohesion

• Module with functional cohesion performs exactly one action

• More reusable• Maintenance easier


Cohesion Case Study

• Compute average daily temperatures at various sites.


Cohesion Case Study


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


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


Common Coupling

• Two modules are commonly coupled if they have access to global data.


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


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


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


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


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)


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


Object-Oriented Paradigm

• Data Encapsulation• Information Hiding• Inheritance• Polymorphism


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


UML Representation

•Short hand notation

ClassName

Data members

Actions

ClassName


UML Representation

objectName ClassName<instance of>

myHandWatch Watch


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


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


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.


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


UML Representation

HumanBeing

Teacher

<Sub-class of>


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


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


UML Representation--Aggregation

State County Township


Polymorphism

• Classical paradigm– function sort_integer_list– function sort_float_list– function sort_string_list

• must explicitly invoke correct version


• All that is needed is myList.sort( )– correct method is invoked dynamically– Method sort() is polymorphic

ListClass

virtual method sort

StringListClass

Implementation of method string sort

FloatListClass

Implementation of method float sort

IntListClass

Implementation of method integer sort


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::CHAP61 INTRODUCTION TO OBJECTS Chapter 6.

Documents

module module

logical cohesion module

procedural cohesion

temporal cohesion module

coincidental cohesion

chap69 module cohesion

levels of cohesion

contd module