Saturday 23 June 2007

a short reflection on models and programs.

Today I may not be able to continue the discussions on the previous post (link). Instead I wish to present a short reflection on the meaning of "description of behaviour".

Modelling or programming, we describe how software behaves. While what matters is how it works, that is, what effects it has on people, on machines, on other programs and processes, one basic significance of models/software development lies in that, apart from their ultimate execution, apart from the use of a model for its translation into a program, it has an independent status as a description. This is so in many levels.

For example Matthew Rawlings told me how this is so in real corporate architecting: a high-level documentation, or a model, is used not only as a top-level specification from which executable programs are constructed through refinement: high-level description has its own function, is used when architects think about the general principles of the design of corporate information systems, when corporate business strategy is discussed among management.
Such descriptions will be updated and augmented independently from its lower or higher layers (even though basic consistency needs be naturally maintained), since they offer the representation of general ideas of computing behaviour in question.

The situation is the same in executable programs. Executable programs do not exist solely for execution: the central point in programs is that, before execution, it has the shape of program texts, to be read and perused and edited by others: their details will be re-examined, designs will be appreciated and evaluated, the texts will be re-formatted for readability, refined in the use of algorithms, models extracted and program analysis applied, and of course they will be used for debugging and as a result will be repeatedly re-rewritten, as if it were a piece of a poem, a piece of a short story, or a section in a long-winding novel.

Software models/specifications and programs present a quintessential form of hyper text. Their nature is more functional than literary texts, to be sure, but still they are nothing but texts, and this is how they allow engineers and analysts and managers to communicate and collaborate, in order to design, build and think about software systems which do function. With0ut this material basis, it is almost impossible for people to discuss design, effects, side-effects and future prospects of computing systems.

Of course not all information are in the texts: without those implicit knowledge, communication never works (as in any communication activities). But they have a central place in all our works about systems design and development.

This special nature of models and programs is one of the reasons why it is worth treating the design of description languages for them seriously, why I believe that it may deserve a scientific basis. On this last point --- what I mean by "scientific basis" --- I will be able to discuss again in later posts: but it is worth stressing that, at each level of description hierarchy (which may be looked either from the viewpoint of chief software architects or from the viewpoint of proud programmers), the result of description, be it a C-program or a UML model, plays a fundamental role in practice, over and over again and through a long period of time (in fact the identity of a program/model resembles identity of a poem which is revised again and again) . There are many things we can say from this observation such as authorship of programs and models, but we leave these discussions to later occasions.