Stepwise Refinement

Stepwise Refinement

The historical role of stepwise:

Strengths and weaknesses of refinement the stepwise strategy Architectural consequences -

Historically, this can be regarded as the first form of ‗design method‘ to be used for software design on any scale. Although much of its importance lies in its influence upon the form and strategy employed in many later methods, its universality has also meant that it has been used widely for software development, and so it does merit a short chapter in its own right. We review both its role and form, and consider some of the consequences that arise from its use.

The historical role of stepwise refinement: Since the early days of computing, the designer of software has been faced with the need to address complex problems using a medium that is enormously powerful and flexible, and yet is also ill-defined in terms of the way in which its detailed form is organized. As already observed, the subprogram (whether termed a subroutine, procedure, function or method . . . ) has probably formed the most important mechanism for providing structural organization in many programming languages.

In this approach, a top-down 'process of successive refinement of specifications‘ led to ‗the decomposition of tasks into sub-tasks and of data into data structures‘. The latter phrase is significant, since Wirth sought to consider how both function and data could be structured within the same process, although subsequent thinking would appear to have placed much more emphasis upon the question of function. This may be partly because in his example solution to the classical eight-queens problem,* the refinement of ideas about data representations was performed at a relatively late stage in the process. Indeed, Wirth argued that, because it could be difficult to foresee the operations on the data that might eventually be needed, it was 'advisable to delay decisions about data representation as long as possible‘.