Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
6.8 ● Coupling 6.8 Coupling 77 We are familiar with the idea of one component making a method call on another, but what other types of interaction (coupling) are there between components? Which types are good and which bad? First, an important aspect of the interaction between components is its “size”. The fewer the number of elements that connect components, the better. If components share common data, it should be minimized. Few parameters should be passed between components in method calls. It has been suggested that no more than about 2–4 parameters should be used. Deceit should not be practiced by grouping together several parameters into a record and then using the record as a single parameter. What about the nature of the interaction between components? We can distinguish the following ways in which components interact. They are listed in an order that goes from strongly coupled (least desirable) to weakly coupled (most desirable): 1. altering another component’s code 2. branching to or calling a place other than at the normal entry point 3. accessing data within another component 4. shared or global data 5. method call with a switch as a parameter 6. method call with pure data parameters 7. passing a serial data stream from one component to another. We now examine each of these in turn. 1. Altering another component’s code This is a rather weird type of interaction and the only programming language that normally allows it is assembler. However, in Cobol the alter statement allows a program to essentially modify its own code. The problem with this form of interaction is that a bug in one component, the modifying component, appears as a symptom in another, the one being modified. 2. Entering at the side door In this type of interaction, one component calls or branches to another at a place other than the normal entry point of the component. Again, this is impossible in most languages, except assembler, Cobol and early versions of Basic. The objection to this type of interaction is part of the argument for structured programming. It is only by using components that have a single entry (at the start) and one exit (at the end) that we can use the power of abstraction to design and understand large programs.
78 Chapter 6 ■ Modularity 3. Modifying data within another component Allowing one component to alter another component’s data seems rather less harmful than changing another component’s code. However, the objection is the same and the coupling is strong because a fault that appears in one component may be caused by another. 4. Shared or global data Shared data is data that two or more components have access to. The data is in a distinct component. Global data means a collection of data that is accessible to a large number of, perhaps all, components. The facility to access data in this way is present in nearly all widely used programming languages. We have already seen why this is undesirable. SELF-TEST QUESTION 6.1 Give one reason why global data is undesirable. 5. A method call with a parameter that is a switch We have seen that both shared data and unusual transfers of control result in strong coupling between components. The solution is, of course, to use method calls with their attendant parameters. Even so, it is possible to worsen the coupling by passing as a parameter not pure data but an element of control. An example is where a component is passed an indicator telling the method which action to take from among a number of available actions. (This indicator is sometimes called a switch.) Here is an example of a method call on a general-purpose input-output method: inputOutput(command, device, buffer, length); The parameter command has values 0, 1, 2, etc. that specify whether the operation is a read, write, open, etc. This is undesirable simply because it is unnecessarily complicated. This method can be divided into several methods – each carrying out a single action. As an alternative to calling a single method and passing it a switch, we can instead call the individual appropriate method, like this: read(device, buffer, length); We have eliminated a parameter from the interaction and at the same time created well-defined methods, each with a specific function. This contrasts with a single, multipurpose method. Arguably this modularization is easier to understand and maintain.
- Page 50 and 51: 2.4 Methodology 27 reality. Like an
- Page 52 and 53: ■ error free ■ fault ■ tested
- Page 54 and 55: 3.2 ● Technical feasibility 3.3 C
- Page 56 and 57: 3.5 Case study 33 The hardware cost
- Page 58 and 59: Answers to self-test questions 3.1
- Page 60 and 61: 4.2 The concept of a requirement 37
- Page 62 and 63: 4.3 The qualities of a specificatio
- Page 64 and 65: 4.5 The requirements specification
- Page 66 and 67: 4.6 The structure of a specificatio
- Page 68 and 69: 4.7 ● Use cases 4.7 Use cases 45
- Page 70 and 71: Summary The ideal characteristics o
- Page 72: Further reading 49 Further reading
- Page 76 and 77: CHAPTER 5 This chapter explains: 5.
- Page 78 and 79: 5.3 Styles of human-computer interf
- Page 80 and 81: 5.5 Design principles and guideline
- Page 82 and 83: 5.5 Design principles and guideline
- Page 84 and 85: SELF-TEST QUESTION 5.2 What problem
- Page 86 and 87: 5.8 Help systems 63 Our plan is to
- Page 88 and 89: Further reading 65 5.5 Design a use
- Page 90 and 91: CHAPTER 6 Modularity This chapter e
- Page 92 and 93: 6.2 Why modularity? 69 observed fau
- Page 94 and 95: Figure 6.1 Two alternative software
- Page 96 and 97: ■ a simple program is more likely
- Page 98 and 99: 6.6 Information hiding 75 The class
- Page 102 and 103: 6. Method calls with parameters tha
- Page 104 and 105: 3. Temporal cohesion 6.9 Cohesion 8
- Page 106 and 107: > } public void setY(int newY) { y
- Page 108 and 109: • Exercises 6.1 What is modularit
- Page 110 and 111: CHAPTER 7 Structured programming Th
- Page 112 and 113: 7.2 Arguments against goto 89 If we
- Page 114 and 115: ■ if-then-else ■ while-do or re
- Page 116 and 117: 7.3 Arguments in favor of goto 93 l
- Page 118 and 119: 7.4 Selecting control structures 95
- Page 120 and 121: while do if endif then else endWhil
- Page 122 and 123: • Exercises 7.1 Review the argume
- Page 124 and 125: count = 0 loop: count = count + 1 i
- Page 126 and 127: > 8.2 Case study 103 A statement th
- Page 128 and 129: start button event create defender
- Page 130 and 131: 8.3 ● Discussion Abstraction One
- Page 132 and 133: Exercises 109 skill. On the other h
- Page 134 and 135: CHAPTER 9 This chapter explains: 9.
- Page 136 and 137: 9.2 Identifying data flows 113 Noti
- Page 138 and 139: 9.3 Creation of a structure chart 1
- Page 140 and 141: SELF-TEST QUESTION 9.4 Discussion 1
- Page 142 and 143: Exercises 119 During the second sta
- Page 144 and 145: CHAPTER 10 This chapter explains:
- Page 146 and 147: In English, this reads: 10.2 A simp
- Page 148 and 149: 10.2 A simple example 125 Now comes
78 Chapter 6 ■ Modularity<br />
3. Modifying data within another component<br />
Allowing one component to alter another component’s data seems rather less harmful<br />
than changing another component’s code. However, the objection is the same and the<br />
coupling is strong because a fault that appears in one component may be caused by<br />
another.<br />
4. Shared or global data<br />
Shared data is data that two or more components have access to. The data is in a distinct<br />
component. Global data means a collection of data that is accessible to a large<br />
number of, perhaps all, components. The facility to access data in this way is present in<br />
nearly all widely used programming languages.<br />
We have already seen why this is undesirable.<br />
SELF-TEST QUESTION<br />
6.1 Give one reason why global data is undesirable.<br />
5. A method call with a parameter that is a switch<br />
We have seen that both shared data and unusual transfers of control result in strong<br />
coupling between components. The solution is, of course, to use method calls with<br />
their attendant parameters. Even so, it is possible to worsen the coupling by passing as<br />
a parameter not pure data but an element of control. An example is where a component<br />
is passed an indicator telling the method which action to take from among a<br />
number of available actions. (This indicator is sometimes called a switch.) Here is an<br />
example of a method call on a general-purpose input-output method:<br />
inputOutput(command, device, buffer, length);<br />
The parameter command has values 0, 1, 2, etc. that specify whether the operation is<br />
a read, write, open, etc. This is undesirable simply because it is unnecessarily complicated.<br />
This method can be divided into several methods – each carrying out a single<br />
action. As an alternative to calling a single method and passing it a switch, we can<br />
instead call the individual appropriate method, like this:<br />
read(device, buffer, length);<br />
We have eliminated a parameter from the interaction and at the same time created<br />
well-defined methods, each with a specific function. This contrasts with a single, multipurpose<br />
method. Arguably this modularization is easier to understand and maintain.