INTRODUCTION TO OBJECTS Chapter 6 UHD CS 3320

INTRODUCTION TO OBJECTS Chapter 6 UHD: : CS 3320: : CHAP 6 1

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: : CS 3320: : CHAP 6 2

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: : CS 3320: : CHAP 6 3

UHD: : CS 3320: : CHAP 6 4

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: : CS 3320: : CHAP 6 5

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: : CS 3320: : CHAP 6 6

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: : CS 3320: : CHAP 6 7

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: : CS 3320: : CHAP 6 8

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 7. Functional cohesion desirable (best) UHD: : CS 3320: : CHAP 6 9

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: : CS 3320: : CHAP 6 10

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: : CS 3320: : CHAP 6 11

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: : CS 3320: : CHAP 6 12

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: : CS 3320: : CHAP 6 13

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: : CS 3320: : CHAP 6 14

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: : CS 3320: : CHAP 6 15

7. Functional Cohesion • Module with functional cohesion performs exactly one action • More reusable • Maintenance easier UHD: : CS 3320: : CHAP 6 16

Cohesion Case Study • Compute average daily temperatures at various sites. UHD: : CS 3320: : CHAP 6 17

Cohesion Case Study UHD: : CS 3320: : CHAP 6 18

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: : CS 3320: : CHAP 6 19

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: : CS 3320: : CHAP 6 20

Common Coupling • Two modules are commonly coupled if they have access to global data. UHD: : CS 3320: : CHAP 6 21

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: : CS 3320: : CHAP 6 22

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: : CS 3320: : CHAP 6 23

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: : CS 3320: : CHAP 6 24

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: : CS 3320: : CHAP 6 25

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: : CS 3320: : CHAP 6 26

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: : CS 3320: : CHAP 6 27

Object-Oriented Paradigm • • Data Encapsulation Information Hiding Inheritance Polymorphism UHD: : CS 3320: : CHAP 6 28

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: : CS 3320: : CHAP 6 29

UML Representation Class. Name Data members Actions • Short hand notation Class. Name UHD: : CS 3320: : CHAP 6 30

UML Representation <instance of> Class. Name object. Name Watch my. Hand. Watch UHD: : CS 3320: : CHAP 6 31

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: : CS 3320: : CHAP 6 32

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: : CS 3320: : CHAP 6 33

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: : CS 3320: : CHAP 6 34

Inheritance Define Human. Being to be a class • A Human. Being has attributes, such as name, age, height, gender • Assign values to attributes when describing object Define Teacher to be a subclass of Human. Being • A Teacher has all attributes if Human. Being, plus attributes of his/her own (discipline, school, department) • A Teacher inherits all attributes of Human. Being UHD: : CS 3320: : CHAP 6 35

UML Representation Human. Being <Sub-class of> Teacher UHD: : CS 3320: : CHAP 6 36

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: : CS 3320: : CHAP 6 37

Composition/Aggregation • A class may contain other classes Example: A State contains many Counties which contain many townships A Police. State is composed of Police. Officers A Directory contain Files UHD: : CS 3320: : CHAP 6 38

UML Representation-Aggregation State County UHD: : CS 3320: : CHAP 6 Township 39

Polymorphism • Classical paradigm – function sort_integer_list – function sort_float_list – function sort_string_list • must explicitly invoke correct version UHD: : CS 3320: : CHAP 6 40

List. Class virtual method sort Int. List. Class String. List. Class Implementation of method integer sort Implementation of method string sort Float. List. Class Implementation of method float sort • All that is needed is my. List. sort( ) – correct method is invoked dynamically – Method sort() is polymorphic UHD: : CS 3320: : CHAP 6 41

Summary Objects with high cohesion and low coupling Objects Information Hiding Abstract Data Types Data Encapsulation Modules with high cohesion and low coupling Modules UHD: : CS 3320: : CHAP 6 42