Software Engineering for Students A Programming Approach

More documents

Recommendations

Info

6.2 Why modularity? 69 observed fault. Similarly, the correction to a single component should not produce “knock-on” effects, provided that the interfaces to and from the component are not affected. Testing Testing a large system made up of a large number of components is a difficult and timeconsuming task. It is virtually impossible to test an individual component in detail once it has been integrated into the system. Therefore testing is carried out in a piecemeal fashion – one component at a time (see Chapter 19 on testing). Thus the structure of the system is crucial. Maintenance This means fixing bugs and enhancing a system to meet changed user needs. This activity consumes enormous amounts of software developers’ time. Again, modularity is crucial. The ideal would be to make a change to a single component with total confidence that no other components will be affected. However, too often it happens that obvious or subtle interconnections between components make the process of maintenance a nightmare. Independent development Most software is implemented by a team of people, often over months or years. Normally each component is developed by a single person. It is therefore vital that interfaces between components are clear and few. Damage control When an error occurs in a component, the spread of damage to other components will be minimized if it has limited connections with other components. Software reuse A major software engineering technique is to reuse software components from a library or from an earlier project. This avoids reinventing the wheel, and can save enormous effort. Furthermore, reusable components are usually thoroughly tested. It has long been a dream of software engineers to select and use useful components, just as an electronic engineer consults a catalog and selects ready-made, tried-and-tested electronic components. However, a component cannot easily be reused if it is connected in some complex way to other components in an existing system. A heart transplant from one human being to another would be impossible if there were too many arteries, veins and nerves to be severed and reconnected.
70 Chapter 6 ■ Modularity There are therefore three requirements for a reuseable component: ■ it provides a useful service ■ it performs a single function ■ it has the minimum of connections (ideally no connections) to other components. 6.3 ● Component types Components can be classified according to their roles: ■ computation-only ■ memory ■ manager ■ controller ■ link. A computation-only component retains no data between subsequent uses. Examples are a math method or a filter in a Unix filter and pipe scheme. A memory component maintains a collection of persistent data, such as a database or a file system. (Persistent data is data that exists beyond the life of a particular program or component and is normally stored on a backing store medium, such as disk.) A manager component is an abstract data type, maintaining data and the operations that can be used on it. The classical examples are a stack or a queue. A controller component controls when other components are activated or how they interact. A link component transfers information between other components. Examples are a user interface (which transfers information between the user of a system and one or more components) and network software. This is a crude and general classification, but it does provide a language for talking about components. 6.4 ● Component size and complexity How big should a software component be? Consider any piece of software. It can always be constructed in two radically different ways – once with small components and again with large components. As an illustration, Figure 6.1 shows two alternative structures for the same software. One consists of many small components; the other a few large components. If the components are large, there will only be a few of them, and therefore there will tend to be only a few connections between them. We have a structure which is a network with few branches and a few very big leaves. The complexity of the interconnections is minimal, but the complexity of each component is high.
Page 1 and 2:
Software Engineering for Students D
Page 3 and 4:
We work with leading authors to dev
Page 5 and 6:
Pearson Education Limited Edinburgh
Page 7 and 8:
vi Contents Part D ● Verification
Page 9 and 10:
viii Detailed contents 3 The feasib
Page 11 and 12:
x Detailed contents 9 Data flow des
Page 13 and 14:
xii Detailed contents 14.7 Repetiti
Page 15 and 16:
xiv Detailed contents 19.7 Unit tes
Page 17 and 18:
xvi Detailed contents 26 Agile meth
Page 19 and 20:
xviii Detailed contents 32.4 Softwa
Page 21 and 22:
xx Preface Software Engineering and
Page 23 and 24:
xxii Preface are engaged on a proje
Page 26 and 27:
CHAPTER 1 This chapter: ■ reviews
Page 28 and 29:
1.3 The cost of software production
Page 30 and 31:
100% 10% 1970 SELF-TEST QUESTION Ha
Page 32 and 33:
Analysis and design 1 /3 Coding 1 /
Page 34 and 35:
SELF-TEST QUESTION 1.7 Maintenance
Page 36 and 37:
1.8 Reliability 13 in the first pla
Page 38 and 39:
1.8 Reliability 15 contain a comma
Page 40 and 41:
Ease of maintenance Reliability Con
Page 42 and 43: Exercises 19 • Exercises These ex
Page 44 and 45: Further reading 21 Analyses of the
Page 46 and 47: ■ documentation ■ maintenance
Page 48 and 49: 2.2 The tasks 25 An important examp
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 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 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
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
Page 156 and 157:
10.5 Structure clashes 133 Let us r
Page 158 and 159:
10.6 Discussion 135 ■ teachable -
Page 160 and 161:
Exercises 137 2. a control block, s
Page 162 and 163:
CHAPTER 11 Object-oriented design T
Page 164 and 165:
Figure 11.1 The cyberspace invaders
Page 166 and 167:
SELF-TEST QUESTION 11.1 Derive info
Page 168 and 169:
11.5 Class-responsibility-collabora
Page 170 and 171:
11.7 ● Discussion Summary 147 OOD
Page 172 and 173:
11.11 Compare and contrast the prin
Page 174 and 175:
CHAPTER 12 This chapter explains: 1
Page 176 and 177:
12.3 Delegation 153 The concepts of
Page 178 and 179:
12.5 Factory method 155 The followi
Page 180 and 181:
12.8 Model, view controller (observ
Page 182 and 183:
Figure 12.4 Pipe and Filter pattern
Page 184 and 185:
Figure 12.6 Layers in a distributed
Page 186 and 187:
Answers to self-test questions 163
Page 188 and 189:
CHAPTER 13 Refactoring This chapter
Page 190 and 191:
13.3 ● Move Method 13.6 Inline Cl
Page 192 and 193:
class Sprite Instance variables x y
Page 194 and 195:
Summary Summary 171 it is making po
Page 196:
PART C PROGRAMMING LANGUAGES
Page 199 and 200:
176 Chapter 14 ■ The basics and a
Page 201 and 202:
178 Chapter 14 ■ The basics > > >
Page 203 and 204:
180 Chapter 14 ■ The basics > Ear
Page 205 and 206:
182 Chapter 14 ■ The basics > Cas
Page 207 and 208:
184 Chapter 14 ■ The basics > > >
Page 209 and 210:
186 Chapter 14 ■ The basics > } }
Page 211 and 212:
188 Chapter 14 ■ The basics Unfor
Page 213 and 214:
190 Chapter 14 ■ The basics Ada d
Page 215 and 216:
192 Chapter 14 ■ The basics The w
Page 217 and 218:
194 Chapter 14 ■ The basics In a
Page 219 and 220:
196 Chapter 14 ■ The basics > str
Page 221 and 222:
198 Chapter 14 ■ The basics Answe
Page 223 and 224:
CHAPTER 15 Object-oriented programm
Page 225 and 226:
202 Chapter 15 ■ Object-oriented
Page 227 and 228:
Page 229 and 230:
Page 231 and 232:
Page 233 and 234:
Page 235 and 236:
Page 237 and 238:
Page 239 and 240:
Page 241 and 242:
Page 243 and 244:
Page 245 and 246:
222 Chapter 16 ■ Programming in t
Page 247 and 248:
Page 249 and 250:
Page 251 and 252:
Page 253 and 254:
Page 255 and 256:
Page 257 and 258:
Page 259 and 260:
Page 261 and 262:
238 Chapter 17 ■ Software robustn
Page 263 and 264:
Page 265 and 266:
Page 267 and 268:
Page 269 and 270:
Page 271 and 272:
Page 273 and 274:
Page 275 and 276:
Page 277 and 278:
Page 279 and 280:
Page 281 and 282:
Page 283 and 284:
260 Chapter 18 ■ Scripting GNU/Li
Page 285 and 286:
262 Chapter 18 ■ Scripting In sum
Page 288:
PART D VERIFICATION
Page 291 and 292:
268 Chapter 19 ■ Testing We begin
Page 293 and 294:
270 Chapter 19 ■ Testing within a
Page 295 and 296:
272 Chapter 19 ■ Testing Test num
Page 297 and 298:
274 Chapter 19 ■ Testing if (a >=
Page 299 and 300:
276 Chapter 19 ■ Testing 3. apply
Page 301 and 302:
278 Chapter 19 ■ Testing made con
Page 303 and 304:
280 Chapter 19 ■ Testing 19.3 Dev
Page 305 and 306:
282 Chapter 19 ■ Testing 19.2 The
Page 307 and 308:
284 Chapter 20 ■ Groups The term
Page 309 and 310:
286 Chapter 20 ■ Groups Of course
Page 311 and 312:
288 Chapter 20 ■ Groups • Exerc
Page 314 and 315:
CHAPTER 21 This chapter explains: 2
Page 316 and 317:
Stage Input Output 21.3 Feedback be
Page 318 and 319:
Summary The essence and the strengt
Page 320 and 321:
CHAPTER 22 This chapter: 22.1 ● I
Page 322 and 323:
22.2 The spiral model 299 to try to
Page 324 and 325:
22.4 ● Discussion Exercises 301 A
Page 326 and 327:
CHAPTER 23 Prototyping This chapter
Page 328 and 329:
Therefore, in summary: ■ the prod
Page 330 and 331:
23.5 Evolutionary prototyping 307 U
Page 332 and 333:
Reuse components 23.6 Rapid prototy
Page 334 and 335:
Pitfalls For users, the problems of
Page 336 and 337:
Answers to self-test questions 313
Page 338 and 339:
24.2 ● Big-bang implementation 24
Page 340 and 341:
Tested component Figure 24.1 Top-do
Page 342 and 343:
24.7 ● Use case driven implementa
Page 344 and 345:
■ middle-out ■ use case based.
Page 346 and 347:
SELF-TEST QUESTION 25.1 What is the
Page 348 and 349:
sharing of software or their own re
Page 350 and 351:
Summary 327 Inappropriate patches,
Page 352 and 353:
Further reading 329 Cathedral and t
Page 354 and 355:
These are qualified by the statemen
Page 356 and 357:
26.3 Extreme programming 333 develo
Page 358 and 359:
SELF-TEST QUESTION 26.3 Which of th
Page 360 and 361:
CHAPTER 27 This chapter explains:
Page 362 and 363:
Figure 27.1 The phases of the unifi
Page 364 and 365:
27.5 ● Iteration 27.6 Case study
Page 366 and 367:
The transition phase Summary 343 Th
Page 368:
PART F PROJECT MANAGEMENT
Page 371 and 372:
348 Chapter 28 ■ Teams The commun
Page 373 and 374:
350 Chapter 28 ■ Teams Level of s
Page 375 and 376:
352 Chapter 28 ■ Teams A chief pr
Page 377 and 378:
354 Chapter 28 ■ Teams benefits o
Page 379 and 380:
356 Chapter 28 ■ Teams • Furthe
Page 381 and 382:
358 Chapter 29 ■ Software metrics
Page 383 and 384:
Page 385 and 386:
Page 387 and 388:
Page 389 and 390:
Page 391 and 392:
Page 393 and 394:
Page 395 and 396:
372 Chapter 30 ■ Project manageme
Page 397 and 398:
Page 399 and 400:
Page 401 and 402:
Page 403 and 404:
Page 405 and 406:
Page 408 and 409:
Page 410 and 411:
31.3 Case study - assessing verific
Page 412 and 413:
31.5 A single development method? 3
Page 414 and 415:
Further reading 391 31.2 Draw up a
Page 416 and 417:
32.3 ● The world of programming l
Page 418 and 419:
32.5 ● The real world of software
Page 420 and 421:
32.6 Control versus skill 397 Final
Page 422 and 423:
Formal methods 32.7 Future methods
Page 424 and 425:
Summary 401 In the short-term futur
Page 426:
Further reading 403 An extensive tr
Page 430 and 431:
APPENDIX A Case studies are used th
Page 432 and 433:
Figure A.1 Cyberspace invaders A.4
Page 434 and 435:
APPENDIX B Glossary Within the fiel
Page 436 and 437:
C.2 ● Class diagrams C.2 Class di
Page 438 and 439:
util Figure C.6 A package diagram S
Page 440 and 441:
References to books and websites ar
Page 442 and 443:
abstraction 99, 107 acceptance test
Page 444 and 445:
fork 324 formal methods 276, 388, 3
Page 446 and 447:
quality 18, 362 quality assurance 1
show all

Software Engineering for Students A Programming Approach

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?