Presentation is loading. Please wait.

Presentation is loading. Please wait.

Coupling and Cohesion Schach, S, R. Object-Oriented and Classical Software Engineering. McGraw-Hill, 2002.

Similar presentations


Presentation on theme: "Coupling and Cohesion Schach, S, R. Object-Oriented and Classical Software Engineering. McGraw-Hill, 2002."— Presentation transcript:

1 Coupling and Cohesion Schach, S, R. Object-Oriented and Classical Software Engineering. McGraw-Hill, 2002

2 2 Characteristics of Good Design Component independence – Exception identification and handling Fault prevention and fault tolerance Design for change M3 M1M2

3 3 Cohesion Definition: The degree to which all elements of a component are directed towards a single task and all elements directed towards that task are contained in a single component. All elements of component are directed toward and essential for performing the same task High is good

4 4 Range of Cohesion High Cohesion Low Functional Informational Sequential Communicational Procedural Temporal Logical Coincidental

5 5 Coincidental Cohesion Definition: Elements needed to achieve some functionality are scattered throughout the system. Accidental Worst form Functional Informational Sequential Communicational Procedural Temporal Logical Coincidental

6 6 Example Print next line Reverse string of characters in second argument Add 7 to 5 th argument Convert 4 th argument to float

7 7 Logical Cohesion Definition: Several logically related elements are in the same component and one of the elements is selected by the client component. Functional Informational Sequential Communicational Procedural Temporal Logical Coincidental

8 8 Example A component reads inputs from tape, disk, and network. All the code for these functions are in the same component. Operations are related, but the functions are significantly different.

9 9 Example A component reads inputs from tape, disk, and network. All the code for these functions are in the same component. Operations are related, but the functions are significantly different. Improvement

10 10 Temporal Cohesion Definition: Difficult to change because you may have to look at numerous components when a change in a data structure is made. Increases chances of regression fault Component unlikely to be reusable. Functional Informational Sequential Communicational Procedural Temporal Logical Coincidental

11 11 Example A system initialization routine: this routine contains all of the code for initializing all of the parts of the system. Lots of different activities occur, all at init time.

12 12 Example A system initialization routine: this routine contains all of the code for initializing all of the parts of the system. Lots of different activities occur, all at init time. Improvement

13 13 Procedural Cohesion Definition: Actions are still weakly connected and unlikely to be reusable Functional Informational Sequential Communicational Procedural Temporal Logical Coincidental

14 14 Example... Read part number from data base update repair record on maintenance file....

15 15 Communicational Cohesion Definition: Module performs a series of actions (a sequence of steps to be followed by the product) and all actions are performed on the same data Functional Informational Sequential Communicational Procedural Temporal Logical Coincidental

16 16 Example Module determine customer details use customer account no find customer name find customer loan balance return customer name, customer loan balance endmodule

17 17 Sequential Cohesion The output of one component is the input to another. Occurs naturally in functional programming languages Good situation Functional Informational Sequential Communicational Procedural Temporal Logical Coincidental

18 18 Informational Cohesion Definition: Module performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data. Different from logical cohesion –Each piece of code has single entry and single exit –In logical cohesion, actions of module intertwined Functional Informational Sequential Communicational Procedural Temporal Logical Coincidental

19 19 Functional Cohesion Definition: Every element in the component is essential to the computation. Ideal situation. Functional Informational Sequential Communicational Procedural Temporal Logical Coincidental

20 20 Examples of Cohesion-1 Function A Function B Function D Function C Function E Coincidental Parts unrelated Function A Function A’ Function A’’ logic Logical Similar functions Time t 0 Time t 0 + X Time t 0 + 2X Temporal Related by time Function A Function B Function C Procedural Related by order of functions

21 21 Examples of Cohesion-2 Function A part 1 Function A part 2 Function A part 3 Functional Sequential with complete, related functions Function A Function B Function C Communicational Access same data Function A Function B Function C Sequential Output of one is input to another

22 22 Coupling: Degree of dependence among components No dependencies Loosely coupled-some dependencies Highly coupled-many dependencies High coupling makes modifying parts of the system difficult, e.g., modifying a component affects all the components to which the component is connected.

23 23 Range of Coupling High Coupling Loose Low Content Common Control Stamp Data Uncoupled

24 24 Content coupling Definition: Example: –Component directly modifies another’s data –Component refers to local data of another component in terms of numerical displacement –Component modifies –another’s code, e.g., jumps into the middle of a routine High Coupling Loose Low Content Common Control Stamp Data Uncoupled

25 25 Example of Content Coupling Part of program handles lookup for customer. When customer not found, component adds customer by directly modifying the contents of the data structure containing customer data.

26 26 Example of Content Coupling Part of program handles lookup for customer. When customer not found, component adds customer by directly modifying the contents of the data structure containing customer data. Improvement:

27 27 Common Coupling Definition: –Global data structures –Common blocks Usually a poor design choice because –Lack of clear responsibility for the data –Reduces readability –Difficult to determine all the components that affect a data element (reduces maintainability) –Difficult to reuse components –Reduces ability to control data accesses High Coupling Loose Low Content Common Control Stamp Data Uncoupled

28 28 Example Each source process writes directly to global data store. Each sink process reads directly from global data store. Process control component maintains current data about state of operation. Gets data from multiple sources. Supplies data to multiple sinks.

29 29 Example Each source process writes directly to global data store. Each sink process reads directly from global data store. Improvement Process control component maintains current data about state of operation. Gets data from multiple sources. Supplies data to multiple sinks.

30 30 Control Coupling Definition: May be either good or bad, depending on situation. –Bad when component must be aware of internal structure and logic of another module –Good if parameters allow factoring and reuse of functionality High Coupling Loose Low Content Common Control Stamp Data Uncoupled

31 31 Example Acceptable: Module p calls module q and q passes back flag that says it cannot complete the task, then q is passing data Not Acceptable: Module p calls module q and q passes back flag that says it cannot complete the task and, as a result, writes a specific message.

32 32 Stamp Coupling Definition: Component passes a data structure to another component that does not have access to the entire structure. Requires second component to know how to manipulate the data structure (e.g., needs to know about implementation) May be necessary due to efficiency factors: this is a choice made by insightful designer, not lazy programmer. High Coupling Loose Low Content Common Control Stamp Data Uncoupled

33 33 Example The print routine of the customer billing accepts a customer data structure as an argument, parses it, and prints the name, address, and billing information. Customer billing system

34 34 Example The print routine of the customer billing accepts a customer data structure as an argument, parses it, and prints the name, address, and billing information. Improvement Customer Billing System

35 35 Data Coupling Definition: Two components are data coupled if there are homogeneous data items. Every argument is simple argument or data structure in which all elements are used Good, if it can be achieved. Easy to write contracts for this and modify component independently. High Coupling Loose Low Content Common Control Stamp Data Uncoupled

36 36 Key Idea in Object-Oriented Programming Object-oriented designs tend to have low coupling.

37 37 Problem: Classify cohesion for each module Input control items, add the items, and verify totals. Initialize sums and open files. Print transaction and copy transaction to tape. Open files, obtain first transaction and first master record, and print page headings. Update record on file and get next transaction. Produce either a sales report, a project status report, or a customer transaction report. Check syntactic correctness of vehicle guidance parameters.

38 38 p q t r s u 1 2 3 4 5 6 1Aircraft typeStatus flag 2-----List of aircraft parts 3Function code----- 4 List of aircraft parts 5Part numberPart manufacturer 6Part numberPart name No. In Out Interface Description p, t, u access the same database in update mode Problem: Define coupling between pairs of modules.

39 39 qrstu p --- q ------- r ---- --- s ---- --- t ---- Coupling between pairs of modules

40 40 In Class P1: What is the effect of cohesion on maintenance? P2: What is the effect of coupling on maintenance? P3: Produce an example of each type of cohesion. Justify your answers. P4: Produce an example of each type of coupling. Justify your answers. P5: Is there a tradeoff between cohesion and coupling? Justify your answer.


Download ppt "Coupling and Cohesion Schach, S, R. Object-Oriented and Classical Software Engineering. McGraw-Hill, 2002."

Similar presentations


Ads by Google