The Software Process

1
CHAPTER 7
INTRODUCTION TO OBJECTS
2
Overview

• 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

3
Introduction to Objects

• What is a module?
• A lexically contiguous sequence of program
  statements, bounded by boundary elements, with an
  aggregate identifier (name)

4
Design 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.

5
Design of Computer (contd)

• Architect designs 3 silicon chips

6
Design of Computer (contd)

• Redesign with one gate type per chip
• Resulting masterpiece

7
Computer 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 interactions within modules, minimal
  interactions between modules

8
Composite/Structured Design (C/SD)

• 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
• High Cohesion but Low Coupling is
  desirable

9
Action, Logic, and Context of Module

• The action of a module what it does
• The logic of a module how the module performs
  its action
• The context of a module is the specific usage of
  that module
• In C/SD, the name of a module is its action
• Example
• Module computes square root of double precision
  integers using Newtons algorithm. Module is
  named compute square root

10
Cohesion

• The degree of interaction within a module
• Seven categories or levels of cohesion
• Functional cohesion is optimal for the structured
  paradigm
• Informational cohesion is optimal for OO paradigm

11
1. 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

12
Why Is Coincidental Cohesion So Bad?

• Degrades maintainability
• Modules are not reusable
• This is easy to fix
• Break into separate modules each performing one
  task

13
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
• 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

14
Why Is Logical Cohesion So Bad?

• The interface is difficult to understand
• Code for more than one action may be intertwined,
  leading to maintenance problems
• Difficult to reuse

15
Why Is Logical Cohesion So Bad? (contd)

• Example If a new tape unit is installed, what
  sections of code should be modified?

16
3. 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)

17
Why 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

18
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
• read part number and update repair record on
  master file

19
Why Is Procedural Cohesion So Bad?

• Actions are still weakly connected, so module is
  not reusable

20
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
• update record in database and write it to audit
  trail
• Example 2
• calculate new coordinates and send them to
  terminal

21
Why Is Communicational Cohesion So Bad?

• Still lack of reusability

22
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

23
Why Is Informational Cohesion So Good?

• Essentially, this is an abstract data type
• Optimal for the OO paradigm
  

24
7. 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

25
Why is functional cohesion so good?

• More reusable
• Corrective maintenance easier
• Fault isolation
• Fewer regression faults
• Easier to extend product

26
Cohesion Case Study
27
Coupling

• Degree of interaction between two modules
• Five categories or levels of coupling

28
1. 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

29
Why Is Content Coupling So Bad?

• Almost any change to b, even recompiling b with
  new compiler or assembler, requires change to a

30
2. Common Coupling

• Two modules are common coupled if they have write
  access to the same global data
• Example 1
• Modules cca and ccb can access and change value
  of global variable

31
2. 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

32
Why Is Common Coupling So Bad?

• Contradicts the spirit of structured programming
• The resulting code is virtually unreadable

33
Why Is Common Coupling So Bad? (contd)

• Modules can have side effects
• This affects their readability
• If a maintenance change is made to a global data
  in a module then every module that can access
  that global data has to be changed
• Difficult to reuse
• Module exposed to more data than necessary

34
3. 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

35
Why 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

36
4. 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

37
4. 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

38
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
• 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
• e.g., - invert matrix (original matrix, inverted
  matrix)
• - print inventory record (warehouse
  record)

39
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
• display time of arrival (flight number)
• compute multiplication (first number, second
  number, result)
• get job with highest priority (job queue)

40
Why Is Data Coupling So Good?

• The difficulties of content, common, control, and
  stamp coupling are not present
• Maintenance is easier

41
Coupling Case Study
42
Coupling Case Study (contd)

• Interface description

43
Coupling Case Study (contd)

• Coupling between all pairs of modules

44
Data 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

45
Data Encapsulation Design 1
46
Data Encapsulation Design 2
47
Data 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 of using data encapsulation
• Development
• Maintenance

48
Data 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

49
Stepwise 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

50
Data 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

51
Implementation of Class JobQueue

• C
• Java

52
Implementation of queueHandler

• C Java

53
Data 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

54
Abstract 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

55
Abstract Data Type

• (Problems caused by public attributes solved
  later)

56
Information 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 (or details hiding)
• Design the modules in way that items likely to
  change are hidden
• Future change is localized
• Changes cannot affect other modules

57
Information Hiding (contd)

• C abstract data type implementation with
  information hiding

58
Information Hiding (contd)

• Effect of information hiding via private
  attributes

59
Major Concepts of Chapter 7
60
Objects

• 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

61
Inheritance

• 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)

62
Inheritance (contd)

• UML notation
• Inheritance is represented by a large open
  triangle

63
Java implementation
64
Aggregation

• UML Notation

65
Association

• UML Notation

66
Equivalence of Data and Action

• Classical paradigm
• record_1.field_2
• Object-oriented paradigm
• thisObject.attributeB
• thisObject.methodC ()

67
Polymorphism and Dynamic Binding

• Classical paradigm
• Must explicitly invoke correct version

68
Polymorphism and Dynamic Binding (contd)

• Object-oriented paradigm

69
Polymorphism 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

70
Polymorphism and dynamic binding (contd)

• Method checkOrder (b Base) can be applied to
  objects of any subclass of Base

71
Polymorphism 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
• The cause of a failure can be very difficult to
  determine
• Polymorphism and dynamic binding
• Strength and weakness of the object-oriented
  paradigm

72
Cohesion and Coupling of Objects

• No new forms of cohesion or coupling
• 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

73
Advantages of Objects

• Same 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

74
Summary
75
Summary