1 / 42

INTRODUCTION TO OBJECTS

INTRODUCTION TO OBJECTS. Chapter 6. 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?. EXAMPLE.

hpelayo
Download Presentation

INTRODUCTION TO OBJECTS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 ClassName ClassName Data members Actions • Short hand notation UHD::CS3320::CHAP6

  31. UML Representation ClassName <instance of> objectName Watch myHandWatch 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. ListClass virtual method sort IntListClass Implementation of method integer sort StringListClass Implementation of method string sort FloatListClass Implementation of method float sort • All that is needed is myList.sort( ) • correct method is invoked dynamically • Method sort() is polymorphic 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 UHD::CS3320::CHAP6

More Related