Extreme programming XP Projects in Computing and Information Systems A Student's Guide 0273721313 Pearson 2009

6.11 Top-down and bottom-up development 133 Language Criteria Weighting A B C D Maintainability 2 3 4 3 4 Support 4 4 5 4 4 HCI capability 5 5 3 5 3 Database connectivity 4 4 3 3 3 Simplicity 4 3 4 3 5 Learning 1 4 5 2 2 Score – 79 76 73 73 Table 6.2 Example comparison table evaluating overall suitability of programming languages for a project then awarded to each language are subjective estimates of how each language meets the criteria specified again on a scale of 1 to 5. For example, in this case it is felt that language A has an average rating for maintainability and is thus assigned a value of 3 in the table. The overall scores for each language are then calculated by multiplying each language’s criterion score by the associated weighting, and summing them. This score provides us with a relative measure that we can use to compare each language. In this example, language A has the highest overall score and we may, therefore, justify choosing this language for our project based on this comparison. Be aware, however, that by reducing the comparison of programming languages to a simple table such as this may mean that other important aspects are overlooked. You should, therefore, justify your choice of programming language in more depth, using a table like this to support your arguments. •

6.11 Top-down and bottom-up development

6.11.1 Introduction

If you are producing a conventional software system with a number of components for example, modules, functions, screens that can be broken down into lower levels of detail, you will have to decide whether to use a top-down or bottom-up approach for the development. These development approaches are applicable to third-generation languages where the software may be constructed with a number of functions, subroutines or procedures, fourth-generation languages, web-based appli- cations and multimedia applications all of which could be broken down into differ- ent levels of screens and sub-screens from different menus. Figure 6.7, which is an example program breakdown structure, helps to illustrate the difference between these two techniques in the following sections. The program in Figure 6.7 is a data handling system that generates long- and short-term statistical results from a data set selected by the user. 134 Chapter 6 n Software development Figure 6.7 An example program breakdown structure Order Vertical top-down Horizontal top-down Bottom-up 1 Main Menu Main Menu Long-Term Analysis 2 Data Entry Data Entry Short-Term Analysis 3 Data Analysis Data Analysis Plot Graphs 4 Long-Term Analysis Results Output Save Results to File 5 Short-Term Analysis Long-Term Analysis Data Entry 6 Results Output Short-Term Analysis Data Analysis 7 Plot Graphs Plot Graphs Results Output 8 Save Results to File Save Results to File Main Menu Table 6.3 Order of development for different approaches for example program shown in Figure 6.7

6.11.2 Top-down development

In a top-down approach you work your way down through the program structure, coding successively lower level modules of the program until the entire system is complete. You can achieve this in one of two ways – vertically or horizontally. In vertical top-down devel- opment you work down each branch as far as you can go before moving back up through the structure and working your way down again. In Figure 6.7, a vertical top-down approach would lead you to code the modules in the order shown in Table 6.3. Horizontal top-down development involves progressively coding an entire level of the system before moving down to the next level and so on. Table 6.3 shows how the modules would be coded in the example program shown in Figure 6.7. Vertical top-down development attempts to get particular components of the system working early rather than providing an overall working system. For example, in Figure 6.7, we would have the Data Analysis section of the system in place before any work on the Results Output section was even started. A horizontal top-down approach would test the look and feel of the system, only adding in lower detail when an entire layer of functionality was completed. In Figure 6.7 we would get an idea of how the Main Menu worked and how the three main options Data Entry, Data Analysis and Results Output would look, even though they would not actually work, before we began work on the lower working levels.