2/14/2001 1

From Modules to Objects

Professor James LandayCS169: Software EngineeringSpring 2001February 14, 2001

2/14/2001 2

Outline

ReviewModulesCohesionAdministriviaCouplingEncapsulation & ADTs

2/14/2001 3

ReviewTesting doesn’t show the absence of bugsMajor 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, correctnessWhy 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 4

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 5

Good vs. Bad Modules

Modules in themselves are not “good”Must design them to have good properties

ALU

SHIFTER

RegistersALU

Shifter

Chip 1 Chip 2

Chip 3

i) CPU using 3 chips (modules)

Chip 1 Chip 2

Chip 3

AND gates OR gates

NOT gates

ii) CPU using 3 chips (modules)

What is the problem here?

2/14/2001 6

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 7

Modules to Objects

Objects with high cohesion and low coupling

Objects

Information hiding

Abstract data types

Data encapsulation

Modules with high cohesion and low coupling

Modules

2/14/2001 8

Cohesion ?

Degree of interaction within moduleSeven levels of cohesion

7. Functional | Informational (best) 5. Communicational 4. Procedural 3. Temporal 2. Logical 1. Coincidental (worst)

2/14/2001 9

1. Coincidental CohesionDef. ?

module performs multiple, completely unrelated actions

Example module prints next line, reverses the characters of the

2nd argument, adds 7 to 3rd argumentHow could this happen?

hard organizational rules about module sizeWhy is this bad?

degrades maintainability & modules are not reusableEasy to fix. How?

break into separate modules each performing one task

2/14/2001 10

2. Logical CohesionDef.

module performs series of related actions, one of which is selected by calling module

Examplefunction 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 11

3. Temporal CohesionDef. ?

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 12

4. Procedural Cohesion

Def. ? module performs series of actions related by

procedure to be followed by productExample

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 13

5. Communicational CohesionDef.

module performs series of actions related by procedure to be followed by product, but in addition all the actions operate on same data

Example 1update record in db and write it to audit trail

Example 2calculate new coordinates and send them to window

Why is this bad? still leads to less reusability -> break it up

2/14/2001 14

7. Informational CohesionDef.

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

initialize_sales_region_table

update_sales_region_table

print_sales_region_table

••

••

••

••

•

••

••

••

••

•

Entry

Entry

Entry

Exit

Exit

Exit

Definition of sales_region_table

This is an ADT!

2/14/2001 15

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 isolationreduced regression faults

easier to extend product

2/14/2001 16

Coupling ?

Degree of interaction between two modules

Five levels of coupling 5. Data (best) 4. Stamp 3. Control 2. Common 1. Content

(worst)

2/14/2001 17

1. Content CouplingDef.

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 18

2. Common CouplingDef.

two modules have write access to the same global dataExample

two modules have access to same database, and can both read and write same record

use of Java public statementWhy is this bad?

resulting code is unreadablemodules can have side-effectsmust read entire module to understand

difficult to reuse module exposed to more data than necessary

cca

ccb

global variable

while (global variable == 0)if (argument xyz > 25)

module 3 ();else

module 4 ();

2/14/2001 19

3. Control CouplingDef.

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 aaffects reusability

2/14/2001 20

4. Stamp CouplingDef.

data structure is passed as parameter, but called module operates on only some of individual components

Examplecalculate 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 reusableother products have to use the same higher level data structures

passes more data than necessarye.g., uncontrolled data access can lead to computer crime

2/14/2001 21

5. Data CouplingDef.

every argument is either a simple argument or a data structure in which all elements are used by the called module

Exampledisplay 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 22

Modules to Objects

Objects with high cohesion and low coupling

Objects

Information hiding

Abstract data types

Data encapsulation

Modules with high cohesion and low coupling

Modules

2/14/2001 23

Data Encapsulation ?

Def. data structure together with actions to

be performed on that structure Bad job queue example

define job queue w/ 1 op together in module (repeat for init, add, etc.)

low cohesion Better job queue example

put all job queue ops together w/ 1 definition of job queue in 1 module

informational cohesion & data encapsulation

Abstraction or stepwise refinement easier development & maintenance helps us cope w/ change

initialize_job_queue ();

add_job_to_queue (job_a);

m_encapsulationm_123

implementation ofjob_queue

initialize_job_queue () { }

••

•

••

•

add_job_to_queue (job j) { }

••

•

••

•

remove_job_from_queue (job j) { }

••

•

••

•

••

•

remove_job_from_queue (job_b);

••

••

••

••

•

••

•

••

•

••

•

••

•

{ job job_a, job_b;

}

2/14/2001 24

Abstract Data Types

Def. data type together with actions to be performed on instantiations of that data type subtle difference with encapsulation

Exampleclass JobQueue {

public int queueLength; // length of job queuepublic int queue = new int[25]; // up to 25 jobs

  // methodspublic void initializeJobQueue (){

// body of method}public void addJobToQueue (int jobNumber){

// body of method }

} // JobQueue

2/14/2001 25

Information Hiding

Really “details hiding” hiding implementation details, not information

Example design modules so that items likely to change

are hiddenfuture change localizedchange cannot affect other modules

data abstractiondesigner thinks at level of ADT

2/14/2001 26

Information hiding

Exampleclass JobQueue {

private int queueLength; // length of job queueprivate int queue = new int[25]; // up to 25 jobs

  // methodspublic void initializeJobQueue (){// body of method}public void addJobToQueue (int jobNumber){// body of method }

} // JobQueue

Now queue and queueLength are inaccessible

2/14/2001 27

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 classA humanBeing has attributes, such as age, height, genderAssign values to attributes when describing object 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)A parent inherits all attributes of humanBeing

2/14/2001 28

Inheritance (UML)

(base class)

(derived class)

inherits from (“isA ”)

derived part

incremental part

HumanBeing

Parent

UML notation: boxes represent classes open triangle represent inheritance

2/14/2001 29

Inheritance (Java)

class HumanBeing{

private int age;private float height;

 public

// declarations of operations on HumanBeing} // class HumanBeing class Parent extends HumanBeing{

private String nameOfOldestChild;private int numberOfChildren;

 public

// declarations of operations on Parent} // class Parent

2/14/2001 30

Inheritance

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

Base

2/14/2001 31

Aggregation (UML)

UML notation: diamond (1 or more) no diamond (1)

PersonalComputer

MonitorCPU 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 32

Polymorphism & Dynamic Binding

Classical paradigm

must explicitly invoke the correct version

function draw_linefunction draw_circlefunction draw_rectangle

2/14/2001 33

Polymorphism & Dynamic Binding Object-oriented paradigm

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

GraphObjClass

LineClassCircleClass

Implementation of method draw for a rectangle

method draw

Implementation of method draw for a line

Implementation of method draw for a circle

RectClass

2/14/2001 34

Polymorphism & Dynamic Binding

Advantages ?

can build for the futureeasy 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 objectsdraw 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 35

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 36

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 37

Next Time

Questions?Friday’s lecture on Requirements

read Chapter 9 from Schach