Software Engineering for Students A Programming Approach

More documents

Recommendations

Info

Formal methods 32.7 Future methods and tools 399 Formal (mathematical) methods are beginning to be used and may become popular, particularly for safety-critical systems. There are two related techniques – formal specification and formal verification. These methods offer the promise of completely reliable software – software that has been proved to meet its specification. These approaches begin by documenting the users requirements in a formal mathematically based language such as Z. Two factors seem to have inhibited the take-up of these methods: one is the problem of communication with the user, when the specification is expressed in a specialist language such as Z. The second problem is the training of developers in the non-trivial methods used to transform the specification into an implementation. Declarative programming languages Logic programming languages, such as Prolog, are used in developing expert systems. Functional programming languages such as LISP and Haskell, offer the promise of directly expressing what a program should do rather than how it should do it. These languages exist and have an excellent pedigree, but there are problems with executing the programs at an acceptable speed. Their acceptance into mainstream software development therefore remains speculative. UML After years of rivalry with competing notations, the “three amigos”, Ivar Jacobson, Grady Booch and James Rumbaugh, came together with the single diagrammatic notation UML. It is now the prevalent notation for describing software, but it is only a documentation notation, not a method or a technique. The unified process, suggested by the same authors, came along soon afterwards. There can be no doubt that UML will continue to be important and, indeed, dominate the scene for some time. There are, however, problems with UML. First, it is a graphical notation and therefore there are limitations on the ease with which diagrams can be processed using a software tool. For example, it is desirable to convert diagrams into code and to check for consistency between diagrams. Second, the semantics – the real meaning – of UML has not been defined with the same thoroughness that the semantics of programming languages has been analyzed. This limits any fundamental understanding of the meaning of UML diagrams. Third, while UML is a large and comprehensive notation, there are some things it cannot describe. For example, data flow diagrams are not a part of UML, and the information in a data flow diagram cannot be described in UML. Now it may be that diagrams such as dataflow are redundant, but alternatively it may be that they still have a useful role in design. Components and reuse If only complex software could be constructed by simply taking existing components off the shelf and combining them. This is the aim of component-based software
400 Chapter 32 ■ Conclusion engineering. Such components need to be useful, easy to use and interoperable. They also need to be reliable, fast, secure and scalable. They need to work across networks, the internet and with web browsers. At the time of writing, the major players in the software industry are offering technologies that claim to meet these goals. 32.8 ● History Let us look at some of the history of software development methods. In the early days of computing, the hardware was the challenge and programming was considered to be easy – an undemanding activity very similar to clerical work. The first programmers were exclusively women because it was considered unsuitable work for men. Fairly soon it was realized that programming demanded a logical approach and abstract thinking. (Regrettably, sexism asserted itself and the women were replaced by men.) As the problems of software production began to restrict the application of computers, the principle of the division of labor was applied to software development. First, the job of the analyst was separated from that of the programmer. Later, with the invention of high-level languages, operating systems and packages, the work of applications programmers was distinguished from that of systems programmers. Sometimes looking at the past helps us to visualize the future. Arguably there have been a number of significant milestones in the history of software engineering. The first was high-level languages, such as Fortran and Cobol, that allowed programmers to express solution in problem-oriented rather than machine-oriented notations. Next was structured programming, the idea that some constructs (such as goto) are dangerous and that design is important. Then came object-oriented design and programming as a way of modularizing software. While each of these innovations was significant, none of them has dramatically solved the problem of ensuring that software is reliable and useful. Perhaps the lesson of history is that there is no silver bullet that can be applied to these problems. Arguably this is because software has an inherent complexity which cannot be eliminated. 32.9 ● The future of software engineering The demise of applications programming has been regularly predicted for many years, and yet the demand for programmers is ever-increasing. What methods are likely to be used in the future? What is likely to happen to the jobs of those involved in software development? Today, the cost of software generally overwhelms the cost of the hardware it runs on. Software production is labor-intensive and developers are in short supply. A major remedy offered is to provide developers with more powerful tools – usually computer based. Examples are UML editors, high-level languages and software development environments.
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 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 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 393 and 394: CHAPTER 30 This chapter: 30.1 ● I
Page 395 and 396: 372 Chapter 30 ■ Project manageme
Page 408 and 409: CHAPTER 31 This chapter: 31.1 ● I
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 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?