Slide 7.1

© The McGraw-Hill Companies, 2002

Object-Oriented and Classical Software

Engineering

Fifth Edition, WCB/McGraw-Hill, 2002

Stephen R. Schachsrs@vuse.vanderbilt.edu

Slide 7.2

© The McGraw-Hill Companies, 2002

CHAPTER 7

INTRODUCTION TO OBJECTS

Slide 7.3

© The McGraw-Hill Companies, 2002

Overview

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

Slide 7.4

© The McGraw-Hill Companies, 2002

Introduction to Objects

What is a module?– A lexically contiguous sequence of program statements,

bounded by boundary elements, with an aggregate identifier

Slide 7.5

© The McGraw-Hill Companies, 2002

Design of Computer

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.

Slide 7.6

© The McGraw-Hill Companies, 2002

Design of Computer (contd)

Architect designs 3 silicon chips

Slide 7.7

© The McGraw-Hill Companies, 2002

Design of Computer (contd)

Redesign with one gate type per chip

Resulting “masterpiece”

Slide 7.8

© The McGraw-Hill Companies, 2002

Computer Design (contd)

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

Slide 7.9

© The McGraw-Hill Companies, 2002

Composite/Structured Design

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

Slide 7.10

© The McGraw-Hill Companies, 2002

Function, Logic, and Context of module

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

Slide 7.11

© The McGraw-Hill Companies, 2002

Cohesion

Degree of interaction within a module Seven categories or levels of cohesion

(non-linear scale)

Slide 7.12

© The McGraw-Hill Companies, 2002

1. Coincidental Cohesion

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”

Slide 7.13

© The McGraw-Hill Companies, 2002

Why Is Coincidental Cohesion So Bad?

Degrades maintainability Modules are not reusable This is easy to fix

– Break into separate modules each performing one task

Slide 7.14

© The McGraw-Hill Companies, 2002

2. Logical Cohesion

A module has logical cohesion when it performs a series of related actions, one of which is selected by the calling module

Example 1function 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

Slide 7.15

© The McGraw-Hill Companies, 2002

Why Is Logical Cohesion So Bad?

The interface is difficult to understand Code for more than one action may be intertwined Difficult to reuse

Slide 7.16

© The McGraw-Hill Companies, 2002

Why Is Logical Cohesion So Bad? (contd)

A new tape unit is installed What is the effect on the laser printer?

Slide 7.17

© The McGraw-Hill Companies, 2002

3. Temporal Cohesion

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)

Slide 7.18

© The McGraw-Hill Companies, 2002

Why Is Temporal Cohesion So Bad?

Actions of this module are weakly related to one another, but strongly related to actions in other modules. – Consider sales district table

Not reusable

Slide 7.19

© The McGraw-Hill Companies, 2002

4. Procedural Cohesion

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

Slide 7.20

© The McGraw-Hill Companies, 2002

Why Is Procedural Cohesion So Bad?

Actions are still weakly connected, so module is not reusable

Slide 7.21

© The McGraw-Hill Companies, 2002

5. Communicational Cohesion

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

Slide 7.22

© The McGraw-Hill Companies, 2002

Why Is Communicational Cohesion So Bad?

Still lack of reusability

Slide 7.23

© The McGraw-Hill Companies, 2002

7. Informational Cohesion

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

Slide 7.24

© The McGraw-Hill Companies, 2002

Why Is Informational Cohesion So Good?

Essentially, this is an abstract data type (see later)

Slide 7.25

© The McGraw-Hill Companies, 2002

7. Functional Cohesion

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

Slide 7.26

© The McGraw-Hill Companies, 2002

Why is functional cohesion so good?

More reusable Corrective maintenance easier

– Fault isolation– Fewer regression faults

Easier to extend product

Slide 7.27

© The McGraw-Hill Companies, 2002

Cohesion Case Study

Slide 7.28

© The McGraw-Hill Companies, 2002

Coupling

Degree of interaction between two modules Five categories or levels of coupling

(non-linear scale)

Slide 7.29

© The McGraw-Hill Companies, 2002

1. Content Coupling

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

Slide 7.30

© The McGraw-Hill Companies, 2002

Why Is Content Coupling So Bad?

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

Slide 7.31

© The McGraw-Hill Companies, 2002

2. Common Coupling

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

Slide 7.32

© The McGraw-Hill Companies, 2002

2. Common Coupling (contd)

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

Slide 7.33

© The McGraw-Hill Companies, 2002

Why Is Common Coupling So Bad?

Contradicts the spirit of structured programming – The resulting code is virtually unreadable

Slide 7.34

© The McGraw-Hill Companies, 2002

Why Is Common Coupling So Bad? (contd)

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

Slide 7.35

© The McGraw-Hill Companies, 2002

3. Control Coupling

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

Slide 7.36

© The McGraw-Hill Companies, 2002

Why Is Control Coupling So Bad?

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

Slide 7.37

© The McGraw-Hill Companies, 2002

4. Stamp Coupling

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

Slide 7.38

© The McGraw-Hill Companies, 2002

4. Stamp Coupling (contd)

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

Slide 7.39

© The McGraw-Hill Companies, 2002

Why Is Stamp Coupling So Bad?

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

Slide 7.40

© The McGraw-Hill Companies, 2002

5. Data Coupling

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

Slide 7.41

© The McGraw-Hill Companies, 2002

Why Is Data Coupling So Good?

The difficulties of content, common, control, and stamp coupling are not present

Maintenance is easier

Slide 7.42

© The McGraw-Hill Companies, 2002

Coupling Case Study

Slide 7.43

© The McGraw-Hill Companies, 2002

Coupling Case Study (contd)

Interface description

Slide 7.44

© The McGraw-Hill Companies, 2002

Coupling Case Study (contd)

Coupling between all pairs of modules

Slide 7.45

© The McGraw-Hill Companies, 2002

Coupling Case Study (contd)

Good design has high cohesion and low coupling– What else characterizes good design?

Slide 7.46

© The McGraw-Hill Companies, 2002

Summary

Slide 7.47

© The McGraw-Hill Companies, 2002

Data Encapsulation

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

Slide 7.48

© The McGraw-Hill Companies, 2002

Data Encapsulation — Design 1

Slide 7.49

© The McGraw-Hill Companies, 2002

Data Encapsulation — Design 2

Slide 7.50

© The McGraw-Hill Companies, 2002

Data Encapsulation

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

Slide 7.51

© The McGraw-Hill Companies, 2002

Data Encapsulation and Development

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

Slide 7.52

© The McGraw-Hill Companies, 2002

Stepwise Refinement

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

Slide 7.53

© The McGraw-Hill Companies, 2002

Data Encapsulation and Maintenance

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

Slide 7.54

© The McGraw-Hill Companies, 2002

Implementation of Class JobQueue

C++

Java

Slide 7.55

© The McGraw-Hill Companies, 2002

Implementation of queueHandler

C++ Java

Slide 7.56

© The McGraw-Hill Companies, 2002

Data Encapsulation and Maintenance (contd)

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

Slide 7.57

© The McGraw-Hill Companies, 2002

Abstract Data Types

Problem with both implementations– Only one queue

Need– We need:

Data type + operations performed on instantiations of that data type

Abstract data type

Slide 7.58

© The McGraw-Hill Companies, 2002

Abstract Data Type

(Problems caused by public attributes solved later)

Slide 7.59

© The McGraw-Hill Companies, 2002

Information Hiding

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

Slide 7.60

© The McGraw-Hill Companies, 2002

Information Hiding (contd)

C++ abstract data type implementation with information hiding

Slide 7.61

© The McGraw-Hill Companies, 2002

Information Hiding (contd)

Effect of information hiding via private attributes

Slide 7.62

© The McGraw-Hill Companies, 2002

Major Concepts of Chapter 7

Slide 7.63

© The McGraw-Hill Companies, 2002

Objects

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

Slide 7.64

© The McGraw-Hill Companies, 2002

Inheritance

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)

Slide 7.65

© The McGraw-Hill Companies, 2002

Inheritance (contd)

UML notation– Inheritance is represented by a large open triangle

Slide 7.66

© The McGraw-Hill Companies, 2002

Java implementation

Slide 7.67

© The McGraw-Hill Companies, 2002

Aggregation

UML Notation

Slide 7.68

© The McGraw-Hill Companies, 2002

Association

UML Notation

Slide 7.69

© The McGraw-Hill Companies, 2002

Equivalence of Data and Action

Classical paradigm– record_1.field_2

Object-oriented paradigm– thisObject.attributeB– thisObject.methodC ()

Slide 7.70

© The McGraw-Hill Companies, 2002

Polymorphism and Dynamic Binding

Classical paradigm– Must explicitly invoke correct

version

Slide 7.71

© The McGraw-Hill Companies, 2002

Polymorphism and Dynamic Binding (contd)

Object-oriented paradigm

Slide 7.72

© The McGraw-Hill Companies, 2002

Polymorphism and Dynamic Binding (contd)

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

Slide 7.73

© The McGraw-Hill Companies, 2002

Polymorphism and dynamic binding (contd)

Method checkOrder (b : Base) can be applied to objects of any subclass of Base

Slide 7.74

© The McGraw-Hill Companies, 2002

Polymorphism and Dynamic Binding (contd)

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

Slide 7.75

© The McGraw-Hill Companies, 2002

Cohesion and Coupling of Objects

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

Slide 7.76

© The McGraw-Hill Companies, 2002

Object-Oriented Metrics (contd)

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

Slide 7.77

© The McGraw-Hill Companies, 2002

Summary

Slide 7.78

© The McGraw-Hill Companies, 2002

Advantages of Objects

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)