Software Engineering for Students A Programming Approach

Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach

web.firat.edu.tr
from web.firat.edu.tr More from this publisher
21.08.2013 Views

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.

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.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!