1. Slide 7A.1 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach srs@vuse.vanderbilt.edu

2. Slide 7A.2 © The McGraw-Hill Companies, 2005 CHAPTER 7 — Unit A FROM MODULES TO OBJECTS

3. Slide 7A.3 © The McGraw-Hill Companies, 2005 Overview l What is a module? l Cohesion l Coupling l Data encapsulation l Abstract data types l Information hiding l Objects l Inheritance, polymorphism, and dynamic binding l The object-oriented paradigm

4. Slide 7A.4 © The McGraw-Hill Companies, 2005 7.1 What Is a Module? l A lexically contiguous sequence of program statements, bounded by boundary elements, with an aggregate identifier  “Lexically contiguous” Adjoining in the code  “Boundary elements” {... } begin... end  “Aggregate identifier” A name for the entire module

5. Slide 7A.5 © The McGraw-Hill Companies, 2005 Design of Computer l 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. Figure 7.1

6. Slide 7A.6 © The McGraw-Hill Companies, 2005 Design of Computer (contd) l The architect designs 3 silicon chips Figure 7.2

7. Slide 7A.7 © The McGraw-Hill Companies, 2005 Design of Computer (contd) l Redesign with one gate type per chip l Resulting “masterpiece” Figure 7.3

8. Slide 7A.8 © The McGraw-Hill Companies, 2005 Computer Design (contd) l The two designs are functionally equivalent  The second design is Hard to understand Hard to locate faults Difficult to extend or enhance Cannot be reused in another product l Modules must be like the first design  Maximal relationships within modules, and  Minimal relationships between modules

9. Slide 7A.9 © The McGraw-Hill Companies, 2005 Composite/Structured Design A method for breaking up a product into modules to achieve  Maximal interaction within a module, and  Minimal interaction between modules l Module cohesion  Degree of interaction within a module l Module coupling  Degree of interaction between modules

10. Slide 7A.10 © The McGraw-Hill Companies, 2005 Function, Logic, and Context of a Module l In C/SD, the name of a module is its function l Example:  A module computes the square root of double precision integers using Newton’s algorithm. The module is named compute_square_root l The underscores denote that the classical paradigm is used here

11. Slide 7A.11 © The McGraw-Hill Companies, 2005 7.2 Cohesion l The degree of interaction within a module l Seven categories or levels of cohesion (non-linear scale) Figure 7.4

12. Slide 7A.12 © The McGraw-Hill Companies, 2005 7.2.1 Coincidental Cohesion l A module has coincidental cohesion if it performs multiple, completely unrelated actions l Example:  print_next_line, reverse_string_of_characters_comprising_second_ parameter, add_7_to_fifth_parameter, convert_fourth_parameter_to_ floating_point l Such modules arise from rules like  “Every module will consist of between 35 and 50 statements”

13. Slide 7A.13 © The McGraw-Hill Companies, 2005 Why Is Coincidental Cohesion So Bad? l It degrades maintainability l A module with coincidental cohesion is not reusable l The problem is easy to fix  Break the module into separate modules, each performing one task

14. Slide 7A.14 © The McGraw-Hill Companies, 2005 7.2.2 Logical Cohesion l A module has logical cohesion when it performs a series of related actions, one of which is selected by the calling module

15. Slide 7A.15 © The McGraw-Hill Companies, 2005 Logical Cohesion (contd) l 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 l Example 2:  An object performing all input and output l Example 3:  One version of OS/VS2 contained a module with logical cohesion performing 13 different actions. The interface contains 21 pieces of data

16. Slide 7A.16 © The McGraw-Hill Companies, 2005 Why Is Logical Cohesion So Bad? l The interface is difficult to understand l Code for more than one action may be intertwined l Difficult to reuse

17. Slide 7A.17 © The McGraw-Hill Companies, 2005 Why Is Logical Cohesion So Bad? (contd) l A new tape unit is installed  What is the effect on the laser printer? Figure 7.5

18. Slide 7A.18 © The McGraw-Hill Companies, 2005 7.2.3 Temporal Cohesion l A module has temporal cohesion when it performs a series of actions related in time l Example:  open_old_master_file, new_master_file, transaction_file, and print_file; initialize_sales_district_table, read_first_transaction_record, read_first_old_master_record (a.k.a. perform_initialization)

19. Slide 7A.19 © The McGraw-Hill Companies, 2005 Why Is Temporal Cohesion So Bad? l The actions of this module are weakly related to one another, but strongly related to actions in other modules  Consider sales_district_table l Not reusable

20. Slide 7A.20 © The McGraw-Hill Companies, 2005 7.2.4 Procedural Cohesion l A module has procedural cohesion if it performs a series of actions related by the procedure to be followed by the product l Example:  read_part_number_and_update_repair_record_on_ master_file

21. Slide 7A.21 © The McGraw-Hill Companies, 2005 Why Is Procedural Cohesion So Bad? l The actions are still weakly connected, so the module is not reusable

22. Slide 7A.22 © The McGraw-Hill Companies, 2005 7.2.5 Communicational Cohesion l 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 l Example 1: update_record_in_database_and_write_it_to_audit_trail l Example 2: calculate_new_coordinates_and_send_them_to_terminal

23. Slide 7A.23 © The McGraw-Hill Companies, 2005 Why Is Communicational Cohesion So Bad? l Still lack of reusability

24. Slide 7A.24 © The McGraw-Hill Companies, 2005 7.2.6 Functional Cohesion l A module with functional cohesion performs exactly one action

25. Slide 7A.25 © The McGraw-Hill Companies, 2005 7.2.6 Functional Cohesion l Example 1:  get_temperature_of_furnace l Example 2:  compute_orbital_of_electron l Example 3:  write_to_floppy_disk l Example 4:  calculate_sales_commission

26. Slide 7A.26 © The McGraw-Hill Companies, 2005 Why Is Functional Cohesion So Good? l More reusable l Corrective maintenance is easier  Fault isolation  Fewer regression faults l Easier to extend a product

27. Slide 7A.27 © The McGraw-Hill Companies, 2005 7.2.7 Informational Cohesion l 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

28. Slide 7A.28 © The McGraw-Hill Companies, 2005 Why Is Informational Cohesion So Good? l Essentially, this is an abstract data type (see later) Figure 7.6

29. Slide 7A.29 © The McGraw-Hill Companies, 2005 7.2.8 Cohesion Example Figure 7.7

30. Slide 7A.30 © The McGraw-Hill Companies, 2005 Continued in Unit 7B