Slide 7.1 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen R. Schach

Slide 7.2 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. CHAPTER 7 FROM MODULES TO OBJECTS

Slide 7.3 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Overview l What is a module? l Cohesion l Coupling l Data encapsulation l Abstract data types l Information hiding l Objects l Inheritance, polymorphism, and dynamic binding l The object-oriented paradigm

Slide 7.4 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. 7.1 What Is a Module? l A lexically contiguous sequence of program statements, bounded by boundary elements, with an aggregate identifier – “Lexically contiguous” » Adjoining in the code – “Boundary elements” » {... } » begin... end – “Aggregate identifier” » A name for the entire module

Slide 7.5 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Design of Computer l 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 Figure 7.1

Slide 7.6 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Design of Computer (contd) l The architect designs three silicon chips Figure 7.2

Slide 7.7 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Design of Computer (contd) l Redesign with one gate type per chip l Resulting “masterpiece” Figure 7.3

Slide 7.8 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Computer Design (contd) l The two designs are functionally equivalent – The second design is » Hard to understand » Hard to locate faults » Difficult to extend or enhance » Cannot be reused in another product l Modules must be like the first design – Maximal relationships within modules, and – Minimal relationships between modules

Slide 7.9 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Composite/Structured Design A method for breaking up a product into modules to achieve – Maximal interaction within a module, and – Minimal interaction between modules l Module cohesion – Degree of interaction within a module l Module coupling – Degree of interaction between modules

Slide 7.10 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Function, Logic, and Context of a Module l In C/SD, the name of a module is its function l Example: – A module computes the square root of double precision integers using Newton’s algorithm. The module is named computeSquareRoot

Slide 7.11 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. 7.2 Cohesion l The degree of interaction within a module l Seven categories or levels of cohesion (non-linear scale) Figure 7.4

Slide 7.12 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Coincidental Cohesion l A module has coincidental cohesion if it performs multiple, completely unrelated actions l Example: – printTheNextLine, reverseStringOfCharactersComprisingSecondparameter, add7ToFifthParameter, convertFourthParameterTofloatingPoint l Such modules arise from rules like – “Every module will consist of between 35 and 50 statements”

Slide 7.13 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Coincidental Cohesion So Bad? l It degrades maintainability l A module with coincidental cohesion is not reusable l The problem is easy to fix – Break the module into separate modules, each performing one task

Slide 7.14 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Logical Cohesion l A module has logical cohesion when it performs a series of related actions, one of which is selected by the calling module

Slide 7.15 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Logical Cohesion (contd) l Example 1: functionCode = 7; newOperation (functionCode, dummy1, dummy2, dummy3); // dummy1, dummy2, and dummy3 are dummy variables, // not used if functionCode is equal to 7 l Example 2: – An object performing all input and output l Example 3: – One version of OS/VS2 contained a module with logical cohesion performing 13 different actions. The interface contains 21 pieces of data

Slide 7.16 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Logical Cohesion So Bad? l The interface is difficult to understand l Code for more than one action may be intertwined l Difficult to reuse

Slide 7.17 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Logical Cohesion So Bad? (contd) l A new tape unit is installed – What is the effect on the laser printer? Figure 7.5

Slide 7.18 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Temporal Cohesion l A module has temporal cohesion when it performs a series of actions related in time l Example: – openOldMasterFile, newMasterFile, transactionFile, and printFile; initializeSalesDistrictTable, readFirstTransactionRecord, readFirstOldMasterRecord (a.k.a. performInitialization)

Slide 7.19 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Temporal Cohesion So Bad? l The actions of this module are weakly related to one another, but strongly related to actions in other modules – Consider salesDistrictTable l Not reusable

Slide 7.20 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Procedural Cohesion l A module has procedural cohesion if it performs a series of actions related by the procedure to be followed by the product l Example: – readPartNumberAndUpdateRepairRecordOnMasterFile

Slide 7.21 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Procedural Cohesion So Bad? l The actions are still weakly connected, so the module is not reusable

Slide 7.22 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Communicational Cohesion l 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 l Example 1: updateRecordInDatabaseAndWriteItToAuditTrail l Example 2: calculateNewCoordinatesAndSendThemToTerminal

Slide 7.23 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Communicational Cohesion So Bad? l Still lack of reusability

Slide 7.24 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Functional Cohesion l A module with functional cohesion performs exactly one action

Slide 7.25 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Functional Cohesion l Example 1: – getTemperatureOfFurnace l Example 2: – computeOrbitalOfElectron l Example 3: – writeToDiskette l Example 4: – calculateSalesCommission

Slide 7.26 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Functional Cohesion So Good? l More reusable l Corrective maintenance is easier – Fault isolation – Fewer regression faults l Easier to extend a product

Slide 7.27 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Informational Cohesion l 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.28 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Informational Cohesion So Good? l Essentially, this is an abstract data type (see later) Figure 7.6

Slide 7.29 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Cohesion Example Figure 7.7

Slide 7.30 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Figure Coupling l The degree of interaction between two modules – Five categories or levels of coupling (non-linear scale)

Slide 7.31 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Content Coupling l Two modules are content coupled if one directly references contents of the other l Example 1: – Module p modifies a statement of module q l Example 2: – Module p refers to local data of module q in terms of some numerical displacement within q l Example 3: – Module p branches into a local label of module q

Slide 7.32 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Content Coupling So Bad? Almost any change to module q, even recompiling q with a new compiler or assembler, requires a change to module p

Slide 7.33 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Common Coupling l Two modules are common coupled if they have write access to global data l Example 1 – Modules cca and ccb can access and change the value of globalVariable Figure 7.9

Slide 7.34 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Common Coupling (contd) l Example 2: – Modules cca and ccb both have access to the same database, and can both read and write the same record l Example 3: – FORTRAN common – COBOL common (nonstandard) – COBOL-80 global

Slide 7.35 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Common Coupling So Bad? l It contradicts the spirit of structured programming – The resulting code is virtually unreadable – What causes this loop to terminate? Figure 7.10

Slide 7.36 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Common Coupling So Bad? (contd) l Modules can have side-effects – This affects their readability – Example: editThisTransaction (record7) – The entire module must be read to find out what it does l A change during maintenance to the declaration of a global variable in one module necessitates corresponding changes in other modules l Common-coupled modules are difficult to reuse

Slide 7.37 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Common Coupling So Bad? (contd) Common coupling between a module p and the rest of the product can change without changing p in any way – “Clandestine common coupling” – Example: The Linux kernel l A module is exposed to more data than necessary – This can lead to computer crime

Slide 7.38 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Control Coupling l Two modules are control coupled if one passes an element of control to the other l Example 1: – An operation code is passed to a module with logical cohesion l Example 2: – A control switch passed as an argument

Slide 7.39 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Control Coupling (contd) Module p calls module q l Message: – I have failed — data l Message: – I have failed, so write error message ABC123 — control

Slide 7.40 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Control Coupling So Bad? l The modules are not independent – Module q (the called module) must know the internal structure and logic of module p – This affects reusability l Associated with modules of logical cohesion

Slide 7.41 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Stamp Coupling l Some languages allow only simple variables as parameters – partNumber – satelliteAltitude – degreeOfMultiprogramming l Many languages also support the passing of data structures – partRecord – satelliteCoordinates – segmentTable

Slide 7.42 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Stamp Coupling (contd) l 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.43 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Stamp Coupling So Bad? l It is not clear, without reading the entire module, which fields of a record are accessed or changed – Example calculateWithholding (employeeRecord) l Difficult to understand l Unlikely to be reusable l More data than necessary is passed – Uncontrolled data access can lead to computer crime

Slide 7.44 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Stamp Coupling So Bad? (contd) l However, there is nothing wrong with passing a data structure as a parameter, provided that all the components of the data structure are accessed and/or changed l Examples: invertMatrix (originalMatrix, invertedMatrix); printInventoryRecord (warehouseRecord);

Slide 7.45 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Data Coupling l 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) l Examples: – displayTimeOfArrival (flightNumber); – computeProduct (firstNumber, secondNumber); – getJobWithHighestPriority (jobQueue);

Slide 7.46 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Why Is Data Coupling So Good? l The difficulties of content, common, control, and stamp coupling are not present l Maintenance is easier

Slide 7.47 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved Coupling Example Figure 7.11

Slide 7.48 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Coupling Example (contd) l Interface description Figure 7.12

Slide 7.49 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Coupling Example (contd) l Coupling between all pairs of modules Figure 7.13

Slide 7.50 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved The Importance of Coupling l As a result of tight coupling – A change to module p can require a corresponding change to module q – If the corresponding change is not made, this leads to faults l Good design has high cohesion and low coupling – What else characterizes good design? (see over)