CSCI 6231 Software Engineering Chapter 7 From Modules to Objects Instructor: Morris Lancaster

Overview Show the transition from the more classical models of software design and implementation to object oriented approaches. Focus on the changes in the implementation of modularity Convince the student that the object oriented design paradigm is superior January 2011 CSCI 6231 Chapter 7

OO Approach OO Analysis Understand the customer’s requirements Describe the problem domain as a set of classes and relationships January 2011 CSCI 6231

OO Approach (continued) OO Design Complete the basic set of classes (fill out and add detail) Looks for opportunities for reuse Addresses performance issues, both for system and users Designs UI, database, networking, as needed Designs ADT to describe the semantics of classes in more detail Develops unit test plans based on class diagrams and ADT design January 2011 CSCI 6231

Modularity Module a “lexically contiguous sequence of program statements.” Per Glenford Myers (with renames from Yourdon/Constantine) we examine “cohesion and coupling” and their “effects” on modularity. January 2011 CSCI 6231

Modularity Alternatives presented here (2nd and 3rd diagrams) represent some desired characteristics at each level The author’s approach is to discuss modularity in terms of Complexity Maintainability Extendibility January 2011 CSCI 6231

Modularity The discussion centers around : cohesion – the degree of interaction within a module coupling - the degree of interaction between two modules January 2011 CSCI 6231

Module Cohesion Coincidental cohesion – performs multiple, completely unrelated operations Logical cohesion – performs a series of related operations, one of which is selected by the calling module. Temporal cohesion – performs a series of operations related in time Procedural cohesion – performs a series of operations related by the sequence of steps followed by the product Communicational cohesion – performs a series of operations related by the sequence of steps to be followed by the product and if all the operations are performed on the same data Functional cohesion – performs exactly one operation or achieves a single goal. January 2011 CSCI 6231

7.2 Cohesion The degree of interaction within a module Seven categories or levels of cohesion (non-linear scale) Figure 7.4 Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

7.2.1 Coincidental Cohesion A module has coincidental cohesion if it performs multiple, completely unrelated actions Example: printTheNextLine, reverseStringOfCharactersComprisingSecondarameter, add7ToFifthParameter, convertFourthParameterTofloatingPoint Such modules arise from rules like “Every module will consist of between 35 and 50 statements” Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

Why Is Coincidental Cohesion So Bad? It degrades maintainability A module with coincidental cohesion is not reusable The problem is easy to fix Break the module into separate modules, each performing one task Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

7.2.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 Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

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

Why Is Logical Cohesion So Bad? The interface is difficult to understand Code for more than one action may be intertwined Difficult to reuse Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

Why Is Logical Cohesion So Bad? (contd) A new tape unit is installed What is the effect on the laser printer? Figure 7.5 Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

7.2.3 Temporal Cohesion A module has temporal cohesion when it performs a series of actions related in time Example: openOldMasterFile, newMasterFile, transactionFile, and printFile; initializeSalesDistrictTable, readFirstTransactionRecord, readFirstOldMasterRecord (a.k.a. performInitialization) Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

Why Is Temporal Cohesion So Bad? The actions of this module are weakly related to one another, but strongly related to actions in other modules Consider salesDistrictTable Not reusable Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

7.2.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: readPartNumberAndUpdateRepairRecordOnMasterFile Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

Why Is Procedural Cohesion So Bad? The actions are still weakly connected, so the module is not reusable Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

7.2.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: updateRecordInDatabaseAndWriteItToAuditTrail Example 2: calculateNewCoordinatesAndSendThemToTerminal Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

Why Is Communicational Cohesion So Bad? Still lack of reusability Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

7.2.6 Functional Cohesion A module with functional cohesion performs exactly one action Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

7.2.6 Functional Cohesion Example 1: Example 2: Example 3: Example 4: getTemperatureOfFurnace Example 2: computeOrbitalOfElectron Example 3: writeToDiskette Example 4: calculateSalesCommission Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

Why Is Functional Cohesion So Good? More reusable Corrective maintenance is easier Fault isolation Fewer regression faults Easier to extend a product Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

7.2.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 Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

Why Is Informational Cohesion So Good? Essentially, this is an abstract data type (see later) Figure 7.6 Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

Module Coupling Content coupled – one directly references the contents of another Common coupling – both have access to the same global data Control coupling – if one module explicitly controls the logic of the other Stamp coupling – data structure is passed as an argument but the called module operates on only one of many individual components of that data structure Data coupling – all arguments are homogeneous data items, every argument is either a simple argument or a data structure in which all elements are used by the called module. January 2011 CSCI 6231

7.3.1 Content Coupling Two modules are content coupled if one directly references contents of the other Example 1: Module p modifies a statement of module q Example 2: Module p refers to local data of module q in terms of some numerical displacement within q Example 3: Module p branches into a local label of module q Copyright 2008 – 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 Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

7.3.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 the value of globalVariable Figure 7.9 Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

7.3.2 Common Coupling (contd) Example 2: Modules cca and ccb both have access to the same database, and can both read and write the same record Example 3: FORTRAN common COBOL common (nonstandard) COBOL-80 global Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

Why Is Common Coupling So Bad? It contradicts the spirit of structured programming The resulting code is virtually unreadable What causes this loop to terminate? Figure 7.10 Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

Why Is Common Coupling So Bad? (contd) Modules can have side-effects This affects their readability Example: editThisTransaction (record7) The entire module must be read to find out what it does A change during maintenance to the declaration of a global variable in one module necessitates corresponding changes in other modules Common-coupled modules are difficult to reuse Copyright 2008 – 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 A module is exposed to more data than necessary This can lead to computer crime Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

7.3.3 Control Coupling Two modules are control coupled if one passes an element of control to the other Example 1: An operation code is passed to a module with logical cohesion Example 2: A control switch passed as an argument Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

Control Coupling (contd) Module p calls module q Message: I have failed — data I have failed, so write error message ABC123 — control Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

Why Is Control Coupling So Bad? The modules are not independent Module q (the called module) must know the internal structure and logic of module p This affects reusability Associated with modules of logical cohesion Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

7.3.4 Stamp Coupling Some languages allow only simple variables as parameters partNumber satelliteAltitude degreeOfMultiprogramming Many languages also support the passing of data structures partRecord satelliteCoordinates segmentTable Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

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 Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

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 calculateWithholding (employeeRecord) Difficult to understand Unlikely to be reusable More data than necessary is passed Uncontrolled data access can lead to computer crime Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

Why Is Stamp Coupling So Bad? (contd) 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 Examples: invertMatrix (originalMatrix, invertedMatrix); printInventoryRecord (warehouseRecord); Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

7.3.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: displayTimeOfArrival (flightNumber); computeProduct (firstNumber, secondNumber); getJobWithHighestPriority (jobQueue);

Why Is Data Coupling So Good? The difficulties of content, common, control, and stamp coupling are not present Maintenance is easier Copyright 2008 – The McGraw Hill Companies, Inc All Rights Reserved

Causes? While there is disagreement with respect to the degree that language influences thinking, it can be clearly seen above that the representation structures can clearly limit our freedom of representation. Older programming languages were mostly procedurally oriented, with a few data oriented languages interspersed. We had to use the sentences in the language and the descriptors for data as given. Real world objects were decomposed into their data and procedural components, then rebuilt by using the programming language and its data structures. We suffered multiple translations. Poor designs were more difficult to identify as poor designs without applying some agreed upon metrics. More design permutations possible. January 2011 CSCI 6231

Extending the Thinking Data Encapsulation – restricting access to data within a module. The data structure was put together with the operations to be performed on the data structure. Moving toward minimization of the global impact of changes made in the internals of a module Data Abstraction and Abstract Data Types – moved toward OO in terms of putting the information about some real world or conceptual entity along with the operations associated with that entity and performing only a “contracted” set of operations. We are now at the point that we can identify real world entities, flesh them out with data and actions with out having to rebuild/re-link the data elements and code routines into “something” that acts as we desired. January 2011 CSCI 6231

Surface Subsurface Air Objects Finally? Not much different from Abstract Data Types. Informational cohesion. But now additional properties. The recognition that hierarchies of objects exist, the concept of a class (a type definition), …. Reuse becomes a key factor. We are reusing more than code. We can use inheritance to specialize objects. We can use polymorphism to adapt functions to different types of objects. Game Object Inanimate Object Animate Object Artifact Mineral Vegetable Natural Animal NPC Player Platform Surface Subsurface Air January 2011 CSCI 6231

Objective of OOA OO design develops the analysis into a blueprint of a solution OO design starts by fleshing the class diagrams Coad & Nicola call this "the continuum of representation principle: use a single underlying representation, from problem domain to OOA to OOD to OOP," i.e., class diagrams *** Reworks and adds detail to class diagrams, e.g., attribute types, visibility (public/private), additional constraints Looks for opportunities for reuse Addresses performance issues, both for system and users Designs UI, database, networking, as needed Designs ADT to describe the semantics of classes in more detail Develops unit test plans based on class diagrams and ADT design ***UML Developed by James Rumbaugh, Grady Booch and Ivar Jacobson January 2011 CSCI 6231

Hints for OO Analysis Design (Coad) Improve domain analysis: reuse and performance OOA focuses primarily on the describing problem domain itself OOD reexamines the domain with an eye to practical concerns Reuse: factor out common code in abstract classes Performance tradeoffs: efficiency vs. effectiveness January 2011 CSCI 6231

Hints for OO Analysis Design (Coad) Human interaction: encapsulates user interface HIC knows how to present data, not how to compute it Separation of concerns principle: Keep problem domain classes distinct from human interaction classes. Why? Loose coupling facilitates software reuse and maintenance An example: the Smalltalk Model-View-Controller framework: model is the problem domain view is the human interface (windows that view the problem domain objects) controller is the mouse or keyboard input, also interacting with P.D. objects C++ Interviews is two part framework: subject (problem domain) & views (UI) January 2011 CSCI 6231

Hints for OO Analysis Design (Coad) Task management Multi‑tasking and concurrency considerations Data management Storage and retrieval of external data Database design (relational or object-oriented) Or database interface (JDBC, CORBA) January 2011 CSCI 6231

Reworking the Class Diagram Add new relations implied in classes Inverse operations (e.g., undo/redo, getData/setData) Factor complex behaviors out as classes themselves If only difference between subclasses is presentation of data, use a service Should we derive HexCount, BinaryCount, OctCount from Count? Rather, add a service, asBase, to present data in different bases Distinguish client (has-a) and inheritance (is-a) relations Misuse of multiple inheritance is when a derived class is "composed of" several parent classes I.e., class AIRPLANE has parents WINGS, ENGINE, TAIL) But the behavior of AIRPLANE is not just the sum of its parts Bjarne Stroustrup's heuristic: "can it have two?" Then it's a containment, or has-a relation January 2011 CSCI 6231

Reworking the Class Diagram Heuristic: use inheritance to extend existing classes E.g., ComplexMatrix adapts Array or OrderedCltn But avoid adapting parents for the sake of their heirs (open‑closed principle) Generalize common behaviors in abstract classes E.g., Mouse, Tablet and Keyboard can all inherit behavior from an abstract class, InputDevice Use multiple inheritance for compound classes TeachingAssistant inherits from both Instructor and Student Window as a compound of Rectangle (graphical behaviors) and Tree (hierarchical behaviors) Note: many OO languages don’t support multiple inheritants January 2011 CSCI 6231

The Future Aspect Oriented Programming ? http://en.wikipedia.org/wiki/Aspect-oriented_programming When the machines arrive? http://en.wikipedia.org/wiki/Automatic_programming January 2011 CSCI 6231