Lecture 1

Chapter 07
From Modules to Objects
Topics:
• What is a Module?
• Cohesion.
• Coupling.
• Data Encapsulation.
• Abstract Data Types.
• Information Hiding.
• Objects.
• Inheritance, Polymorphism, and Dynamic Binding.
• The Object-Oriented Paradigm.
What is a Module?
• Software products are broken down into smaller pieces, called modules.
• Object-oriented paradigm is the development of theory of modularity.
• Operation of a module - What it does?
• Logic of a module - How it performs its operation?
• Context of a module - Specific use of module?
Cohesion
• Module cohesion - Degree of interaction within a module.
• Defined at seven levels.
• Figure 7.4

1- Coincidental Cohesion
• Module performs multiple, unrelated operations.
• Consequence of enforcing minimum or maximum size limits.
• Drawbacks.
o Degrading maintainability.
o Lack of reusability.
2- Logical Cohesion
• Module performs a series of related operations, one of which is selected by calling module.
• E.g., performing all input and output.
• Drawbacks
o Interface difficult to understand.
o Maintenance problems with intertwined operations.
3- Temporal Cohesion
• Module performs a series of operations related in time.
• E.g., open old master file, open new master file, open transaction file.
• Unlikely to be reusable in a different product.
4- Procedural Cohesion
• Module performs a series of operations related by sequences of steps to be followed by the product.
• E.g., read part number, update record.
• Better than temporal cohesion, but still weakly connected.
• Unlikely to be reusable in another product.
• Should be broken into separate modules.
5- Communicational Cohesion
• Module performs a series of operations related by the sequence of steps to be followed by the product, and all operations are performed on same data.
• E.g., update record in database, write it to audit trail.
• Better than procedural cohesion, but modules cannot be reused.
• Should be broken into separate modules.
• Flowchart cohesion refers to temporal, procedural, and communication cohesion.
• Operation performed by modules adjacent in the product flowchart.
6- Functional Cohesion
• Module performs exactly one operation or achieves a single goal.
• E.g., calculate sales commission.
• Modules often can be reused.
• Maintenance easier to perform.
• Valuable when extending a product.
7- Informational Cohesion
• Module performs a number of operations, each with its own entry point, with independent code for each operation, and all operations are performed on same data structure
• Different from logical cohesion: Operations not intertwined.
• Example of separation of concerns.
• Implementation of an abstract data type.
Cohesion Example


Coupling
• Module coupling - Degree of interaction between two modules.
• Defined at five levels.
• Figure 7.8

1- Content Coupling
• One module directly references contents of the other.
• Any change to a module requires changing the other.
• Reuse of one module requires reusing the other.
2- Common Coupling
• Both modules have access to the same global data.
• Drawbacks.
o Contradicts spirit of structured programming: Resulting code unreadable.
o Entire module must be read to find out what it does.
o Change in global variable requires changes in all accessing modules.
o Difficult to reuse without identical listing of global data.
o Number of instances of common coupling can change drastically.
o New modules using same global data (clandestine common coupling).
o A module may be exposed to more data than it needs.
• If absolutely necessary: Must be done in a controlled way.
o Large number of descriptors to be used by many modules.
o Without having to be passed as arguments.
o Initialized in one module.
o No other module changes the value.
3- Control Coupling
• One module passes an element of control to the other module: One module explicitly controls the logic of the other.
• E.g., a function code is passed to a module.
• Two modules are not independent, reducing possibility of reuse.
• Generally associated with logical cohesion: Similar drawbacks.
4- Stamp Coupling
• One module passes a data structure as an argument to the other module, and the called module operates on only some of the components of that data structure.
• Drawbacks
o Difficult to understand the interface.
o Uncontrolled data access.
5- Data Coupling
• All arguments are homogenous data items (simple arguments or data structures in which all elements are used by the called module).
• Example of separation of concerns.
• A desirable goal.
• Maintenance is easier
Coupling Example
• Figure 7.11

• Figure 7.12 and Figure 7.13

The Importance of Coupling
• Coupling is an important metric.
• Changing modules during integration and post delivery maintenance.
• Stronger the coupling: The greater the fault-proneness.
• A design in which modules have high cohesion and low coupling is a good design.
How can such a design be achieved?
Qualities that identify a good design achieved.
Data Encapsulation
• Data encapsulation - A data structure, together with the operations to be performed on that data structure.
• An example of separation of concerns.
• An example of abstraction: Means of achieving stepwise refinement by suppressing unnecessary details and accentuating relevant details.
o Data encapsulation: An example of data abstraction.
o Functions: Examples of procedural abstraction.
Abstract Data Types
• Abstract data type - A data type with the operations performed on instantiations of that data type.
• Widely applicable design tool.
• Supports both data abstraction and procedural abstraction.
Information Hiding
• Information hiding - Structuring the design so that the resulting implementation details are hidden from other modules
• A more general design concept including abstraction.
Objects
• Object - An instantiation (instance) of a class.
• Class - An abstract data type that supports inheritance.
• Class X a subclass of Class Y
o X derived class of Y
o X inherits (has all) attributes of Y
o X is A Y
• Four basic relationships of classes
o Specialization - X class a specialization of Y class.
o Generalization - Y class a generalization of X class.
o Aggregation - Components of a class: Group related items.
o Association - A relationship of some kind between two apparently unrelated classes.
Inheritance, Polymorphism, and Dynamic Binding
• Inheritance - New data types can be defined as extensions of previously defined types.
o Supported by all object-oriented programming languages (Smalltalk, C++, Java).
• Dynamic binding - Connecting an object to the appropriate method at run time.
• Polymorphism - Methods that can be applied to objects of different classes.
• Advantage of polymorphism and dynamic binding:
o Developers not concerned with precise argument types when a message is sent.
• Disadvantages of polymorphism and dynamic binding:
o Invoked method not known at compile time, resulting in difficulty in determining the cause of failures.
o Negative impacts on maintenance, due to multiple possibilities.
The Object-Oriented Paradigm
• Classical paradigm classified into two groups:
o Operation-oriented - Considering the operations of the product, and data are of secondary importance.
o Data-oriented - Emphasis on the data of the product, and operations are considered within the framework of the data.
• Object-oriented technique gives equal weight to data and operations: Operations work on data and data cannot change without operations.
• Data and operations given equal importance during workflows.
• Advantages of object-oriented paradigm:
o A well- designed object models all aspects of one physical entity Clear mapping between real-world entity and the object, High cohesion and low coupling.
o Hidden details and well-defined interface: Communication through messages.
o Can be maintained easily and safely.
o Objects are reusable.
o Objects are independent components of a product: Combined to construct a large-scale product.
o Development of the product and management of that development is easier and less likely to induce faults.
Why has classical paradigm had so much success?
• Adopted at the time when software engineering not widely practiced: software simply written.
• As products grow in size, inadequacies become apparent.
How to know object-oriented paradigm is superior?
• No data to prove beyond all doubt.
• Overwhelming majority of organization that adopted paradigm report favorably.
Issues are with object-oriented paradigm.
• Learning curve.
o High initial cost in terms of effort and time.
o Particularly noticeable when the product has a graphical user interface.
o Great improvements after initial use.
• Inheritance.
o Fragile base class problem: A change to a class directly affects all its descendants in the inheritance hierarchy.
o Storage problem: Objects lower in the inheritance hierarchy can get large.
o Inheritance wherever appropriate, not wherever possible.
• Polymorphism and dynamic binding.
o Difficulty in maintenance.
o Considerations by the programmers.
• Possible to write bad code in any language
o Ensuring the code is of highest quality
• Possibility of someday having something better than the object-oriented paradigm
o Object-oriented not the ultimate answer.
o Software engineers are looking beyond objects.
o Will be superseded by methodologies of the future.
o Aspect-oriented programming (AOP) may play a role.

Reference
• Schach, S.R. (2010). Object-Oriented and Classical Software Engineering, Eighth Edition. McGraw-Hill, ISBN: 978-0-07-337618-9.