Title: Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vanderbilt.edu
1Object-Oriented and Classical Software
Engineering Fifth Edition, WCB/McGraw-Hill,
2002Stephen R. Schachsrs_at_vuse.vanderbilt.edu
2CHAPTER 7
INTRODUCTION TO OBJECTS
3Overview
- What is a module?
- Cohesion
- Coupling
- Data encapsulation product maintenance
- Abstract data types
- Information hiding
- Objects
- Inheritance, polymorphism and dynamic binding
- Cohesion and coupling of objects
4Introduction to Objects
- What is a module?
- A lexically contiguous sequence of program
statements, bounded by boundary elements, with an
aggregate identifier
5Design of Computer
- 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.
6Design of Computer (contd)
- Architect designs 3 silicon chips
7Design of Computer (contd)
- Redesign with one gate type per chip
- Resulting masterpiece
8Computer Design (contd)
- The two designs are functionally equivalent
- Second design is
- Hard to understand
- Hard to locate faults
- Difficult to extend or enhance
- Cannot be reused in another product
- Modules must be like the first design
- Maximal relationships within modules, minimal
relationships between modules
9Composite/Structured Design
- Method for breaking up a product into modules for
- Maximal interaction within module, and
- Minimal interaction between modules
- Module cohesion
- Degree of interaction within a module
- Module coupling
- Degree of interaction between modules
10Function, Logic, and Context of module
- In C/SD, the name of a module is its function
- Example
- Module computes square root of double precision
integers using Newtons algorithm. Module is
named compute square root
11Cohesion
- Degree of interaction within a module
- Seven categories or levels of cohesion
(non-linear scale)
121. Coincidental Cohesion
- A module has coincidental cohesion if it performs
multiple, completely unrelated actions - Example
- print next line, reverse string of characters
comprising second parameter, add 7 to fifth
parameter, convert fourth parameter to floating
point - Arise from rules like
- Every module will consist of between 35 and 50
statements
13Why Is Coincidental Cohesion So Bad?
- Degrades maintainability
- Modules are not reusable
- This is easy to fix
- Break into separate modules each performing one
task
142. Logical Cohesion
- A module has logical cohesion when it performs a
series of related actions, one of which is
selected by the calling module - Example 1
- function 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
- Example 2
- Module performing all input and output
- Example 3
- One version of OS/VS2 contained logical cohesion
module performing 13 different actions.
Interface contained 21 pieces of data
15Why Is Logical Cohesion So Bad?
- The interface is difficult to understand
- Code for more than one action may be intertwined
- Difficult to reuse
16Why Is Logical Cohesion So Bad? (contd)
- A new tape unit is installed
- What is the effect on the laser printer?
173. Temporal Cohesion
- A module has temporal cohesion when it performs a
series of actions related in time - Example
- open old master file, new master file,
transaction file, print file, initialize sales
district table, read first transaction record,
read first old master record (a.k.a. perform
initialization)
18Why Is Temporal Cohesion So Bad?
- Actions of this module are weakly related to one
another, but strongly related to actions in other
modules. - Consider sales district table
- Not reusable
194. 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
- read part number and update repair record on
master file
20Why Is Procedural Cohesion So Bad?
- Actions are still weakly connected, so module is
not reusable
215. 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
- update record in database and write it to audit
trail - Example 2
- calculate new coordinates and send them to
terminal
22Why Is Communicational Cohesion So Bad?
- Still lack of reusability
237. 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
24Why Is Informational Cohesion So Good?
- Essentially, this is an abstract data type
(see later)
257. Functional Cohesion
- Module with functional cohesion performs exactly
one action - Example 1
- get temperature of furnace
- Example 2
- compute orbital of electron
- Example 3
- write to floppy disk
- Example 4
- calculate sales commission
26Why is functional cohesion so good?
- More reusable
- Corrective maintenance easier
- Fault isolation
- Fewer regression faults
- Easier to extend product
27Cohesion Case Study
28Coupling
- Degree of interaction between two modules
- Five categories or levels of coupling
(non-linear scale)
291. Content Coupling
- Two modules are content coupled if one directly
references contents of the other - Example 1
- Module a modifies statement of module b
- Example 2
- Module a refers to local data of module b in
terms of some numerical displacement within b - Example 3
- Module a branches into local label of module b
30Why Is Content Coupling So Bad?
- Almost any change to b, even recompiling b with
new compiler or assembler, requires change to a - Warning
- Content coupling can be implemented in Ada
through use of overlays implemented via address
clauses
312. 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 value
of global variable
322. Common Coupling (contd)
- Example 2
- Modules cca and ccb both have access to same
database, and can both read and write same record - Example 3
- FORTRAN common
- COBOL common (nonstandard)
- COBOL-80 global
33Why Is Common Coupling So Bad?
- Contradicts the spirit of structured programming
- The resulting code is virtually unreadable
34Why Is Common Coupling So Bad? (contd)
- Modules can have side-effects
- This affects their readability
- Entire module must be read to find out what it
does - Difficult to reuse
- Module exposed to more data than necessary
353. Control Coupling
- Two modules are control coupled if one passes an
element of control to the other - Example 1
- Operation code passed to module with logical
cohesion - Example 2
- Control-switch passed as argument
36Why Is Control Coupling So Bad?
- Modules are not independent module b (the
called module) must know internal structure and
logic of module a. - Affects reusability
- Associated with modules of logical cohesion
374. Stamp Coupling
- Some languages allow only simple variables as
parameters - part number
- satellite altitude
- degree of multiprogramming
- Many languages also support passing of data
structures - part record
- satellite coordinates
- segment table
384. 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
39Why Is Stamp Coupling So Bad?
- It is not clear, without reading the entire
module, which fields of a record are accessed or
changed - Example
- calculate withholding (employee record)
- Difficult to understand
- Unlikely to be reusable
- More data than necessary is passed
- Uncontrolled data access can lead to computer
crime - There is nothing wrong with passing a data
structure as a parameter, provided all the
components of the data structure are accessed
and/or changed - invert matrix (original matrix, inverted matrix)
- print inventory record (warehouse record)
405. 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
- display time of arrival (flight number)
- compute product (first number, second number)
- get job with highest priority (job queue)
41Why Is Data Coupling So Good?
- The difficulties of content, common, control, and
stamp coupling are not present - Maintenance is easier
42Coupling Case Study
43Coupling Case Study (contd)
44Coupling Case Study (contd)
- Coupling between all pairs of modules
45Coupling Case Study (contd)
- Good design has high cohesion and low coupling
- What else characterizes good design?
46Summary
47Data Encapsulation
- Example
- Design an operating system for a large mainframe
computer. It has been decided that batch jobs
submitted to the computer will be classified as
high priority, medium priority, or low priority.
There must be three queues for incoming batch
jobs, one for each job type. When a job is
submitted by a user, the job is added to the
appropriate queue, and when the operating system
decides that a job is ready to be run, it is
removed from its queue and memory is allocated to
it - Design 1 (Next slide)
- Low cohesionoperations on job queues are spread
all over product
48Data Encapsulation Design 1
49Data Encapsulation Design 2
50Data Encapsulation
- m_encapsulation has informational cohesion
- m_encapsulation is an implementation of data
encapsulation - Data structure (job_queue) together with
operations performed on that data structure - Advantages
- Development
- Maintenance
51Data Encapsulation and Development
- Data encapsulation is an example of abstraction
- Job queue example
- Data structure
- job_queue
- Three new functions
- initialize_job_queue
- add_job_to_queue
- delete_job_from_queue
- Abstraction
- Conceptualize problem at higher level
- job queues and operations on job queues
- not lower level
- records or arrays
52Stepwise Refinement
- 1. Design in terms of high level concepts
- It is irrelevant how job queues are implemented
- 2. Design low level components
- Totally ignore what use will be made of them
- In 1st step, assume existence of lower level
- Concern is the behavior of the data structure
- job_queue
- In 2nd step, ignore existence of high level
- Concern is the implementation of that behavior
- In a larger product, there will be many levels of
abstraction
53Data Encapsulation and Maintenance
- Identify aspects of product likely to change
- Design product so as to minimize the effects of
change - Data structures are unlikely to change
- Implementation may change
- Data encapsulation provides a way to cope with
change
54Implementation of Class JobQueue
55Implementation of queueHandler
56Data Encapsulation and Maintenance (contd)
- What happens if queue is now implemented as a
two-way linked list of JobRecord? - Module that uses JobRecord need not be changed at
all, merely recompiled -
C -
- Java
57Abstract Data Types
- Problem with both implementations
- Only one queue
- Need
- We need
- Data type operations performed on
instantiations of that data type - Abstract data type
58Abstract Data Type
- (Problems caused by public attributes solved
later)
59Information Hiding
- Data abstraction
- Designer thinks at level of an ADT
- Procedural abstraction
- Define a procedureextend the language
- Instances of a more general design concept,
information hiding - Design the modules in way that items likely to
change are hidden - Future change is localized
- Changes cannot affect other modules
60Information Hiding (contd)
- C abstract data type implementation with
information hiding
61Information Hiding (contd)
- Effect of information hiding via private
attributes
62Major Concepts of Chapter 7
63Objects
- First refinement
- Product is designed in terms of abstract data
types - Variables (objects) are instantiations of
abstract data types - Second refinement
- Class abstract data type that supports
inheritance - Objects are instantiations of classes
64Inheritance
- Define humanBeing to be a class
- A humanBeing has attributes, such as age, height,
gender - Assign values to attributes when describing
object - Define Parent to be a subclass of HumanBeing
- A Parent has all attributes of a HumanBeing, plus
attributes of his/her own (name of oldest child,
number of children) - A Parent inherits all attributes of humanBeing
- The property of inheritance is an essential
feature of object-oriented languages such as
Smalltalk, C, Ada 95, Java (but not C, FORTRAN)
65Inheritance (contd)
- UML notation
- Inheritance is represented by a large open
triangle
66Java implementation
67Aggregation
68Association
69Equivalence of Data and Action
- Classical paradigm
- record_1.field_2
- Object-oriented paradigm
- thisObject.attributeB
- thisObject.methodC ()
70Polymorphism and Dynamic Binding
- Classical paradigm
- Must explicitly invoke correct version
71Polymorphism and Dynamic Binding (contd)
72Polymorphism and Dynamic Binding (contd)
- All that is needed is myFile.open()
- Correct method invoked at run-time (dynamically)
- Method open can be applied to objects of
different classes - Polymorphic
73Polymorphism and dynamic binding (contd)
- Method checkOrder (b Base) can be applied to
objects of any subclass of Base
74Polymorphism and Dynamic Binding (contd)
- Can have a negative impact on maintenance
- Code is hard to understand if there are multiple
possibilities for a specific method - Polymorphism and dynamic binding
- Strength and weakness of the object-oriented
paradigm
75Cohesion and Coupling of Objects
- No such thing!
- Object-oriented cohesion and coupling always
reduces to classical cohesion - The only feature unique to the object-oriented
paradigm is inheritance - Cohesion has nothing to do with inheritance
- Two objects with the same functionality have the
same cohesion - It does not matter if this functionality is
inherited or not - Similarly, so-called object-oriented coupling
always reduces to classical coupling
76Object-Oriented Metrics (contd)
- Two types of so-called object-oriented metric
- Not related to inheritance
- Reduces to a classical metric
- Inheritance-related
- May reduce to a classical metric
- No problem
- Classical metrics work just fine
- But dont mislead others by calling them
object-oriented
77Summary
78Advantages of Objects
- Same as as advantages of abstract data types
- Information hiding
- Data abstraction
- Procedural abstraction
- Inheritance provides further data abstraction
- Easier and less error-prone product development
- Easier maintenance
- Objects are more reusable than modules with
functional cohesion - (See next chapter)