Software Engineering for Students A Programming Approach

318 Chapter 24 ■ Incremental development
Component
1
Figure 24.3 Bottom-up implementation
Test
bed
Component
under
test
■ there is no visible, working system until a very late stage, system testing, is complete.
True there are tested components and subsystems, but there is normally nothing
that can be demonstrated to the client as even providing a limited vision of what the
system will eventually do.
■ not all systems have a bottom.
24.6 ● Middle-out implementation
Component
2
Middle-out development starts with an architectural design for the software. It then
chooses some central component as the starting point for testing. A driver and stubs are
written and the component is tested. Then some adjoining component is added to the
system and testing carried out. The system emerges from its centre.
This approach could be useful in developing a large software system that involves a
number of developers. In such a development, the work needs to be divided among a
number of people who work concurrently. Hopefully the architecture can be cleanly
divided into weakly coupled subsystems, which are initially developed independently.
These subsystems need to be surrounded by drivers and stubs, developing in a middleout
fashion.
This approach suffers from all the combined drawbacks of bottom-up and top-down
development.
SELF-TEST QUESTION
24.1 Suggest a drawback of middle-out development