Software Department
Lecture 1
Advanced Software Engineering
Dr. Ahmed Saleem
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
Software Department
Lecture 1
Advanced Software Engineering
Dr. Ahmed Saleem
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
2
Software Department
Lecture 1
Advanced Software Engineering
Dr. Ahmed Saleem
 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.
3
Software Department
Lecture 1
Advanced Software Engineering
Dr. Ahmed Saleem
 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
4
Software Department
Lecture 1
Advanced Software Engineering
Dr. Ahmed Saleem
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
5
Software Department
Lecture 1
Advanced Software Engineering
Dr. Ahmed Saleem
 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
6
Software Department
Lecture 1
Advanced Software Engineering
Dr. Ahmed Saleem
 Figure 7.12 and Figure 7.13
The Importance of Coupling
 Coupling is an important metric.
7
Software Department
Lecture 1
Advanced Software Engineering
Dr. Ahmed Saleem
 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.
8
Software Department
Lecture 1
Advanced Software Engineering
Dr. Ahmed Saleem
 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
9
Software Department
Lecture 1
Advanced Software Engineering
Dr. Ahmed Saleem
 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.
10
Software Department
Lecture 1
Advanced Software Engineering
Dr. Ahmed Saleem
 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.
11