Top-down programming methodology is sometimes related to an incremental specification of problems. We are interested in including in the language a set of operations to assist programmers in the process of development, beginning with the first prototype and ending with the final version of the program.
Incremental programming consists in writing a first (rough) prototype, test it, then write a second as a modification (refinement) of the first, and go on until a final version is achieved. In classical programming languages the way of doing it is by changing the code of the program whenever a non-desired behaviour is observed ora more specialised performance is required. But, the complete code has to be ready and at hand before performing any testing. A step forward in helping programmers in Milord II is by requiring: 1) that the partial specifications of modules, incompletely defined modules, must be executable to test them, and 2) a set of operations between modules for overseeing this process of incremental building of programs.
If you observe the syntax of modules you can notice that many components of modules are optional. Any module declaration is executable. For instance, we can declare modules without control component, or without import interface, etc. In some cases we do not declare some components of modules because we want to define them incrementally. For instance, if we execute a module which contains only an export interface, it will answer to all the questions about the value of exported facts with the constant unknown. Later on we can fill in the module with code details by refining it.
When we program a new version of a previous program we are interested in
checking and declaring what is the relation with the old version. In
Milord II this relation is defined between modules and can be either a
refinement, a contraction or an expansion. Roughly speaking, we say that a
module is a refinement of another one when the set of
accessible
facts is the same that the previous one but the code
is a particularisation. When we expand a module the accessible facts in
the next version will be extended, and reduced when we constrain it.
In Figure 16 we extend the previous syntactical declarations of modules in Figure 15 with these new module operations. The symbols ``:'', ``>'' and ``<'' stand respectively for the module refinement, expansion and contraction operations. They can be used in all module declarations including the parameter declaration of generic modules.
Figure 16: Syntax of operations among modules definition.
All these modular operations are based in three basic functions: enrichment verification, inheritance and information hiding. Next, we explain the refinement of modules that is the most important operation and makes use of these three basic functions in its definition. The other two operations are slight modifications of this refinement operation.