Configuration management Projects in Computing and Information Systems A Student's Guide 0273721313 Pearson 2009

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. 6.11 Top-down and bottom-up development 135 In order to test your system as you proceed with a top-down approach, you would have to develop a number of stubs in order to replicate the behaviour of lower level components of the program before they are actually written. According to Knott and Dawson 1999: 162, a stub can be: n a dummy routine that simply returns, doing nothing; n a routine that simulates the behaviour of a module by returning constant values; or n a routine that simulates a module by asking the user to input suitable return values. The advantages of using a top-down approach are that a working version of the system is produced quickly, enabling the user to get an idea of the overall look-and-feel of the system. In addition, by providing a working system early the user can spot any serious omissions in the top level design of the system. However, there are some drawbacks to this approach. First, some of the ‘difficult’ components of the system will probably be at the lower levels. Leaving these until later may prove costly if they lead to problems that are difficult to overcome. Second, as lower levels are often concerned with data input and output it may not be possible to get a feel of how the system is working until these components are written and the system is able to handle appropriate data.

6.11.3 Bottom-up development

The bottom-up approach is the opposite of the top-down approach in that you begin by coding the lowest levels first before bringing these components together to produce the fully working system. For example, in the case of Figure 6.7, you might begin by working on the Long-Term Analysis component of the system first. This may involve the develop- ment and implementation of a complex algorithm so you might want to ensure that you can get this working sooner rather than later in your project. You will probably under- stand that the higher level components for example, the Main Menu will be easy to complete, so it would make sense to tackle the harder parts of the system first rather than leave these until the end. Applying a bottom-up development approach to the program in Figure 6.7 results in coding the modules in the order shown in Table 6.3. As you continue to build the lower-level components of your system, you need to consider how you will bring these together in the final system. This should be done incrementally, where the components are added to the system as they are completed and the system ‘grows’ over time. However, before a module is added to the system it should be tested in isolation to ensure that it behaves in the way it is intended. Quite often, developers will produce test harnesses – structures of code that enable lower level modules to be tested in isolation. However, these structures take time to write and you may be better coding higher levels of the system to act as harnesses to save time. While the bottom-up approach enables you to test out the lower levels of detail in your program sooner, it does have a number of disadvantages. For example, there is no visible system until the end of the development when the higher levels are developed. This can mean that progress appears slow and may mean that any major design omis- sions are not spotted until near the end of the project when it is too late. In theory, you could swap the implementation of some modules around and still be pursuing a particular top-down or bottom-up development approach. For example, there would be no harm in swapping over the implementation of Long-Term Analysis and