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

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

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.

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

Saved successfully!

Ooh no, something went wrong!