uhd::cs3320::chap61 introduction to objects chapter 6
TRANSCRIPT
UHD::CS3320::CHAP6 1
INTRODUCTION TO OBJECTS
Chapter 6
UHD::CS3320::CHAP6 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?
UHD::CS3320::CHAP6 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).
UHD::CS3320::CHAP6 4
UHD::CS3320::CHAP6 5
COMPUTER DESIGN--CNTD
• Computer architect realizes that it is better to build a chip using one type of gates
==> Partitions the system so that one gate type on each chip.
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 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 Newton’s algorithm
• Module should be names compute square root
UHD::CS3320::CHAP6 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)
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 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.
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 16
7. Functional Cohesion
• Module with functional cohesion performs exactly one action
• More reusable• Maintenance easier
UHD::CS3320::CHAP6 17
Cohesion Case Study
• Compute average daily temperatures at various sites.
UHD::CS3320::CHAP6 18
Cohesion Case Study
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 21
Common Coupling
• Two modules are commonly coupled if they have access to global data.
UHD::CS3320::CHAP6 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.
==> the two modules are data coupled
UHD::CS3320::CHAP6 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.
==> the two modules are control coupled
UHD::CS3320::CHAP6 24
Control Coupling-- CNTD
• If q passes information back to p and p decides what actions to take ==> data coupling
• If q passes information back to p but also informs p what actions to take ==> control coupling
• What’s so bad about control coupling– module are not independent: module q must
know structure and logic of p.– Affects reuse
UHD::CS3320::CHAP6 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.
• What’s 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
UHD::CS3320::CHAP6 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)
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 28
Object-Oriented Paradigm
• Data Encapsulation• Information Hiding• Inheritance• Polymorphism
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 30
UML Representation
•Short hand notation
ClassName
Data members
Actions
ClassName
UHD::CS3320::CHAP6 31
UML Representation
objectName ClassName<instance of>
myHandWatch Watch
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 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.
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 36
UML Representation
HumanBeing
Teacher
<Sub-class of>
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 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
UHD::CS3320::CHAP6 39
UML Representation--Aggregation
State County Township
UHD::CS3320::CHAP6 40
Polymorphism
• Classical paradigm– function sort_integer_list– function sort_float_list– function sort_string_list
• must explicitly invoke correct version
UHD::CS3320::CHAP6 41
• All that is needed is myList.sort( )– correct method is invoked dynamically– Method sort() is polymorphic
ListClass
virtual method sort
StringListClass
Implementation of method string sort
FloatListClass
Implementation of method float sort
IntListClass
Implementation of method integer sort
UHD::CS3320::CHAP6 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