Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
24.7 ● Use case driven implementation 24.8 Discussion 319 A use case is a single independent function that a system provides for a user. For example, the word processor (Appendix A) provides tens of functions to carry out the tasks of editing, formatting and displaying text. Each of these is a use case. This approach takes one use case at a time and implements it. In the word processor example, we might first choose to implement the save file function. This is a good choice because, once it is implemented, this feature is useful in providing a mechanism for testing the other use cases. Implementing this function means single-mindedly concentrating on it to the exclusion of all the other functions. Only the methods necessary to achieving this end are implemented. Drivers are not needed and a minimal number of stubs are required. The use case approach is different to the top-down approach explained above. Topdown starts with the user interface and implements each of the various functions in a breadth-first fashion. It creates a forest of trees that grow simultaneously. In contrast, the use case approach is a depth-first approach. It creates individual trees one after the other. The stages of the use case approach are: 1. choose an initial use case to implement 2. implement the use case 3. test the use case 4. demonstrate the use case to the client. These stages are repeated until the user is satisfied with the product. The strengths of this approach are: ■ the system acts as its own drivers ■ there are immediate and repeated, visible products. SELF-TEST QUESTION 24.2 Suggest a second use case for implementation. 24.8 ● Discussion We have assumed in the above explanation that architectural design is complete prior to incremental implementation. This is one approach, but an alternative is to allow the architectural structure to emerge from the implementation. This means that the structure will probably be subject to frequent refactoring (see Chapter 13). This takes some courage and it might be too risky an approach for a large project.
320 Chapter 24 ■ Incremental development Summary The aim of incremental development is easier bug detection. The mechanism is incorporation of components one by one. Incremental methods include: ■ top-down ■ bottom-up ■ middle-out ■ use case based. Use case based development provides early and frequent functionality. This in turn means: ■ improved confidence by the client and the developer ■ the opportunity for the user to change their requirements ■ the opportunity for the user to decide what should be implemented next. Use case based development also reduces the work of creating test drivers and stubs. • Exercises 24.1 Draw up an incremental process model for preparing a meal, including buying the ingredients and washing up afterwards. Don’t forget to identify the product at each stage. 24.2 Draw up an incremental process model for writing a student assignment. The assignment is to write an essay reviewing the process models that are explained in this book. The non-incremental approach is: Step 1 read and digest all the relevant chapters Step 2 write the review. 24.3 Draw up an incremental process model for a large civil engineering project, such as building a road bridge across the channel between England and France. Identify similarities and differences between this project and a large software development project. 24.4 Create an outline plan for developing each of the systems in Appendix A, using an incremental approach. 24.5 Compare and contrast the following approaches to development: ■ top-down ■ bottom-up
- 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 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: 360 Chapter 29 ■ Software metrics
- Page 385 and 386: 362 Chapter 29 ■ Software metrics
- Page 387 and 388: 364 Chapter 29 ■ Software metrics
- Page 389 and 390: 366 Chapter 29 ■ Software metrics
- Page 391 and 392: 368 Chapter 29 ■ Software metrics
24.7 ● Use case driven implementation<br />
24.8 Discussion 319<br />
A use case is a single independent function that a system provides <strong>for</strong> a user. For example,<br />
the word processor (Appendix A) provides tens of functions to carry out the tasks of<br />
editing, <strong>for</strong>matting and displaying text. Each of these is a use case. This approach takes<br />
one use case at a time and implements it.<br />
In the word processor example, we might first choose to implement the save file<br />
function. This is a good choice because, once it is implemented, this feature is useful in<br />
providing a mechanism <strong>for</strong> testing the other use cases. Implementing this function<br />
means single-mindedly concentrating on it to the exclusion of all the other functions.<br />
Only the methods necessary to achieving this end are implemented. Drivers are not<br />
needed and a minimal number of stubs are required.<br />
The use case approach is different to the top-down approach explained above. Topdown<br />
starts with the user interface and implements each of the various functions in a<br />
breadth-first fashion. It creates a <strong>for</strong>est of trees that grow simultaneously. In contrast, the<br />
use case approach is a depth-first approach. It creates individual trees one after the other.<br />
The stages of the use case approach are:<br />
1. choose an initial use case to implement<br />
2. implement the use case<br />
3. test the use case<br />
4. demonstrate the use case to the client.<br />
These stages are repeated until the user is satisfied with the product.<br />
The strengths of this approach are:<br />
■ the system acts as its own drivers<br />
■ there are immediate and repeated, visible products.<br />
SELF-TEST QUESTION<br />
24.2 Suggest a second use case <strong>for</strong> implementation.<br />
24.8 ● Discussion<br />
We have assumed in the above explanation that architectural design is complete prior<br />
to incremental implementation. This is one approach, but an alternative is to allow the<br />
architectural structure to emerge from the implementation. This means that the structure<br />
will probably be subject to frequent refactoring (see Chapter 13). This takes some<br />
courage and it might be too risky an approach <strong>for</strong> a large project.