Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
> } public void setY(int newY) { y = newY; } 6.10 Object-oriented programming 83 Here the private and public elements are clearly distinguished. A third description, protected, means that the item is not accessible to clients but is accessible to subclasses, as we shall see shortly. Not shown in this example are private methods that are used by a class as necessary to carry out its work. It is of course possible to misuse objects, by grouping ingredients that are not related. However it is the purpose of a good design approach to ensure that this does not arise (see Chapter 11). Object-oriented programming (OOP) completely eliminates global data; all data is encapsulated within objects. The open-closed principle If you need to modify a class (or object), there is no need to make a separate edited copy. Instead you can use the inheritance mechanism of OOP. So the original copy of the class remains intact, but is reused with additional or changed methods. This is called the open-closed principle. Using the example above, we can create a new class called MovingBall with additional methods that cause the ball to move left and right: class MovingBall extends Ball { } public void moveLeft(int distance) ) x = x - distance; } public void moveRight(int distance) { x = x + distance; } The new class MovingBall has all the features of the class Ball, but as the keyword extends denotes, the new class has additional methods. The variables x and y in the superclass are accessible in this subclass because they were declared as protected. MovingBall makes use of Ball without altering it. Thus the modularity and integrity of the original component remain intact. There is a snag: inheritance creates an additional type of coupling between a class and its superclasses. Thus if a subclass is changed, the programmer needs to re-examine all the superclasses. >
84 Chapter 6 ■ Modularity 6.11 ● Discussion In this chapter we have discussed a range of considerations about the design of components. The ideas can be grouped into two areas: 1. those that deal with interactions within components – length, cohesion 2. those that deal with interactions between components – information hiding, coupling, shared components. These guidelines help us in three ways: 1. they help us decide what to do during the act of design, guiding us to software that is clear, simple and flexible 2. they provide us with criteria for assessing the structure of some completed software 3. they assist us in refactoring (restructuring) software in order to improve it. This book describes a number of methods for software design – creating a structure for the software. Unfortunately no method can claim to lead the designer to an ideal structure, and so guidelines for modularity supplement design methods in providing guidance during the process of design. In addition, they enable us to make judgments on the quality of a piece of software that has been designed. They may enable the designer to improve the software structure. A problem with these guidelines is that they are largely qualitative rather than quantitative. In Chapter 29 on metrics we look at one attempt to establish a quantitative measure for the complexity of a component. We shall see more on the nature of the relationships between components in Chapter 12 on patterns. Summary Modularity is important throughout software development including design, testing and maintenance. Restricting component size is one crude way of reducing complexity. An extreme view is to restrict all components to no more than seven statements. The principle of information hiding is that data should be inaccessible other than by means of the methods that are specially provided for accessing the data. Coupling and cohesion are terms that describe the character of the interaction between components and within components, respectively. Coupling and cohesion are complementary. Strong coupling and weak cohesion are bad; weak coupling and strong cohesion are good. Thus coupling and cohesion provide a terminology and a qualitative analysis of modularity. Object-oriented programming explicitly supports information hiding, weak coupling and strong cohesion.
- 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 100 and 101: 6.8 ● Coupling 6.8 Coupling 77 We
- Page 102 and 103: 6. Method calls with parameters tha
- Page 104 and 105: 3. Temporal cohesion 6.9 Cohesion 8
- 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
- Page 150 and 151: 10.4 Multiple input and output stre
- Page 152 and 153: Process header Process issue 10.4 M
- Page 154 and 155: 10.5 Structure clashes 131 As seen
><br />
}<br />
public void setY(int newY) {<br />
y = newY;<br />
}<br />
6.10 Object-oriented programming 83<br />
Here the private and public elements are clearly distinguished. A third description,<br />
protected, means that the item is not accessible to clients but is accessible to subclasses,<br />
as we shall see shortly. Not shown in this example are private methods that are used by<br />
a class as necessary to carry out its work.<br />
It is of course possible to misuse objects, by grouping ingredients that are not related.<br />
However it is the purpose of a good design approach to ensure that this does not arise<br />
(see Chapter 11).<br />
Object-oriented programming (OOP) completely eliminates global data; all data is<br />
encapsulated within objects.<br />
The open-closed principle<br />
If you need to modify a class (or object), there is no need to make a separate edited<br />
copy. Instead you can use the inheritance mechanism of OOP. So the original copy<br />
of the class remains intact, but is reused with additional or changed methods. This<br />
is called the open-closed principle. Using the example above, we can create a new<br />
class called MovingBall with additional methods that cause the ball to move left and<br />
right:<br />
class MovingBall extends Ball {<br />
}<br />
public void moveLeft(int distance) )<br />
x = x - distance;<br />
}<br />
public void moveRight(int distance) {<br />
x = x + distance;<br />
}<br />
The new class MovingBall has all the features of the class Ball, but as the keyword<br />
extends denotes, the new class has additional methods. The variables x and y in the<br />
superclass are accessible in this subclass because they were declared as protected.<br />
MovingBall makes use of Ball without altering it. Thus the modularity and integrity<br />
of the original component remain intact.<br />
There is a snag: inheritance creates an additional type of coupling between a class<br />
and its superclasses. Thus if a subclass is changed, the programmer needs to re-examine<br />
all the superclasses.<br />
>