INTRODUCTION TO OBJECTS

1
INTRODUCTION TO OBJECTS

• Chapter 6

2
WHAT IS A MODULE?

• A lexically contiguous sequence of program
  statements, bounded by boundary elements, with
  aggregate identifier.
• Methods for breaking up product into modules?

3
EXAMPLE

• A computer architect decides to build an ALU,
  shifter and 16 registers using AND, OR and NOT
  gates (rather than NAND or NOR gates).

4
(No Transcript)
5
COMPUTER DESIGN--CNTD

• Computer architect realizes that it is better to
  build a chip using one type of gates
• gt Partitions the system so that one gate type
  on each chip.

6
COMPUTER DESIGN--CNTD

• Two designs functionally equivalent
• Second design
• hard to understand
• hard to locate faults
• difficult to extend or enhance
• cannot be reused in another product
• Modules must be selected with
• maximal relationships within modules
• minimal relationships between modules

7
COMPOSITE/STRUCTURED DESIGN

• Method for breaking up product into modules for
• maximal relationships within modules
• minimal relationships between modules
• Module cohesion
• Degree of interaction within module
• Module coupling
• Degree of interaction between modules

8
C/SD--CONTD

• Module function, logic, and context
• A module is identified with its function
• Example a module computes square root of double
  precision integers using Newtons algorithm
• Module should be names compute square root

9
MODULE COHESION

• Seven categories or levels of cohesion
• 1. Coincidental cohesion (worst)
• 2. Logical cohesion should be avoided
• 3. Temporal cohesion
• 4. Procedural cohesion
• 5. Communicational cohesion
• 6. Informational cohesion desirable
• 7. Functional cohesion (best)

10
1. Coincidental Cohesion

• Module performs multiple, completely unrelated
  actions
• Example
• Module print next line, reverse string of
  characters in second argument, add 7 to third
  argument, convert fourth argument to floating
  point
• Why is Coincidental Cohesion so bad?
• Degrades maintainability
• No reuse

11
2. Logical Cohesion

• Module performs series of related actions, each
  is selected by setting the value of a parameter
• Example
• Module performs all input and output ops
• Why is logical Cohesion so bad?
• Interface difficult to understand
• Code for more than one action may be intertwined
• Difficult to reuse

12
3. Temporal Cohesion

• Module performs a series of actions related in
  time
• Example
• open input file, open output file, initialize
  table of records, read first record (i.e.
  Initialization actions)
• Why is temporal cohesion so bad?
• Actions weakly related to one another, but
  strongly related to other actions in other modules

13
4. Procedural cohesion

• Module performs series of actions related by
  procedure to be followed in product.
• Example
• read part number then update repair record
• Why is procedural cohesion so bad?
• Actions still weakly connected, so not reusable.

14
5. Communicational Cohesion

• Module performs series of actions related by
  procedure to be followed by product, but in
  addition all the actions operate on same data
• Example
• calculate new coordinates and send them to
  terminal
• Still lack of reusability

15
6. Informational Cohesion

• Module performs a number of actions, each with
  its own entry point, with independent code for
  each action, all performed on same data
  structure.
• This is essentially an Abstract Data Type

16
7. Functional Cohesion

• Module with functional cohesion performs exactly
  one action
• More reusable
• Maintenance easier

17
Cohesion Case Study

• Compute average daily temperatures at various
  sites.

18
Cohesion Case Study
19
Coupling

• Degree of interaction between modules
• File categories of coupling ( some goo some bad)
• 1. Content coupling Worst
• 2. Common coupling
• 3. Control coupling
• 4. Stamp coupling
• 5. Data coupling Best

20
Content Coupling

• One module directly references content of another
  module.
• Example
• One module branches into local label of another
• One module references local data of another

21
Common Coupling

• Two modules are commonly coupled if they have
  access to global data.

22
Control Coupling

• Two modules are control coupled if one passes an
  element of control to another
• Example
• Module p calls module q
• Module q is supposed count the number of
  characters in a text file and return the result
  to module p.
• If module q fails (e.g. Can read from file) it
  return -1.
• gt the two modules are data coupled

23
Control Coupling--Example CNTD

• Suppose
• Module p calls module q
• Module q is supposed count the number of
  characters in a text file and return the result
  to module p.
• If module q fails (e.g. Can read from file)
  returns a message that module p is supposed to
  output.
• gt the two modules are control coupled

24
Control Coupling-- CNTD

• If q passes information back to p and p decides
  what actions to take gt data coupling
• If q passes information back to p but also
  informs p what actions to take gt control
  coupling
• Whats so bad about control coupling
• module are not independent module q must know
  structure and logic of p.
• Affects reuse

25
Stamp Coupling

• Two modules are stamp coupled if data structure
  is passed as parameter, but called module
  operates on some but not all of individual
  components of data structure.
• Whats so bad about Stamp coupling
• Not clear, without reading entire module which
  part of data structure is changed
• Pass more data than necessary
• uncontrolled data access can lead to security
  problems

26
Data Coupling

• Two modules are data coupled is all parameters
  are homogeneous data items (i.e. Simple data
  items, or data structures all of whose elements
  are used by called module)
• Examples
• display_time_of_arrival(flight_number)
• Compute_product(first_num, second_num)
• get_job_with_highest_priority(job_queue)

27
Data Coupling--CNTD

• Why is data coupling so good?
• Difficulties of all other couplings not present
• Module interface is explicit
• No side effects
• Maintenance is easier

28
Object-Oriented Paradigm

• Data Encapsulation
• Information Hiding
• Inheritance
• Polymorphism

29
Data Encapsulation

• Data structure together with the actions done on
  those data are encapsulated in the same
  module--the class
• A class is an Abstract Data Type
• An object is an instance of a class
• Why is encapsulation so good?
• A class is a module with informational cohesion
• functional cohesion at the method level

30
UML Representation
Data members Actions

• Short hand notation

31
UML Representation
ltinstance ofgt
objectName
Watch
myHandWatch
32
Data Encapsulation and Development

• Data Encapsulation allows abstraction during
  product analysis and design
• When extracting and design the classes
• what objects are needed to be modeled?
• what are the data attributes of each object?
• what actions are to be performed on the data of
  each object? What are the interactions between
  objects

33
Stepwise Refinement

• Step 1. Design in terms of high level concepts
• concern with behavior of data structure
• Step 2. Design low level components
• concern with implementation of the that behavior

34
Information Hiding

• Implementation details of the data attributes and
  methods of a class are hidden from outside the
  class.
• Control access to data attributes
• thru public methods
• private members
• Why is information hiding good ?
• Interaction between classes occurs through
  explicitly declared interfaces.
• No side effects change in one module does not
  effect others
• I.e. data coupling between classes.

35
Inheritance

• Define HumanBeing to be a class
• A HumanBeing has attributes, such as name, age,
  height, gender
• Assign values to attributes when describing
  object
• Define Teacher to be a subclass of HumanBeing
• A Teacher has all attributes if HumanBeing, plus
  attributes of his/her own (discipline, school,
  department)
• A Teacher inherits all attributes of HumanBeing

36
UML Representation
ltSub-class ofgt
37
Inheritance

• Inheritance is essential to object-oriented
  language such as Smalltalk, C, and JAVA
• Does it improve cohesion? Coupling?
• Provides further data abstraction
• Improves reuse

38
Composition/Aggregation

• A class may contain other classes
• Example
• A State contains many Counties which contain many
  townships
• A PoliceState is composed of PoliceOfficers
• A Directory contain Files

39
UML Representation--Aggregation
40
Polymorphism

• Classical paradigm
• function sort_integer_list
• function sort_float_list
• function sort_string_list
• must explicitly invoke correct version

41

• All that is needed is myList.sort( )
• correct method is invoked dynamically
• Method sort() is polymorphic

42
Summary

• Objects with high cohesion and low coupling
• Objects
• Information Hiding
• Abstract Data Types
• Data Encapsulation
• Modules with high cohesion and low coupling
• Modules