Managing the Construction of Large Computerized Systems, Jean-Raymond Abrial

Managing the Construction of Large Computerized Systems

Prof. Jean-Raymond Abrial

The subject mentioned in the title of this short article does not seem, at first glance, to be a genuine research subject. Although there are, from time to time, some famous breakdowns of large computerized systems as, for instance, recently at SBB in Zurich, it seems nevertheless that these systems are working nowadays in a satisfactory fashion. As a consequence, their construction process must have been mastered, otherwise such disasters would have occurred more frequently. This was clearly the case at the beginning of last century with an emerging technology such as avionics. There were lots of crashes due to the fact that people did not know how to construct good airplanes. The main reason for this was that they did not understand yet the theory of flight mechanics, which was in its infancy.

In our case, however, the situation is a bit different from that of early avionics in that there is no clear theory (yet) related to large computerized systems. The most obvious indication supporting this fact is that, most of the time, experts cannot clearly explain why such systems indeed work correctly. When a serious breakdown occurs, the corresponding superficial reason is normally found after some time (not always however), and it is usually “repaired” in a very ad-hoc fashion. But people are never sure that another breakdown will not occur some time later, precisely because they do not know the more profound reason for that earlier breakdown. It is my belief that such a state of the art is not satisfactory.

From (almost) the beginning of Informatics, the main tools used to develop computer systems was a, so-called, High Level Programming Language and a corresponding Compiler. There has been many of them (far too many in fact) proposing new features that pretended to solve the problem of constructing better programs than the previous generation of High Level Programming Languages and Compilers did. It does not seem however to have solved the problem since, over the years, the famous “software crisis” is still with us.

An interesting research is then to investigate whether there could exist some other intellectual means and tools that could be used instead of High Level Programming Languages and Compilers. It does not mean of course that we believe that we can replace final computer programs by something else. But, we would like to investigate whether we could invent some other ways to obtain such final programs.

When High Level Programming Languages were invented in the sixties (i.e. Algol), the idea was to make abstract programming patterns such as conditionals, loops, procedure calls, and the like be first class citizens in the programming methodology. In the more restricted realm of Assembly Code, such programming patterns did not exist explicitly but were all implemented by means of a single feature, namely the conditional goto instruction. The High Level Programming Language was then an abstraction of the more concrete Assembly Code. And the Compiler was the tool that allows us to move from this abstraction to a concrete implementation. Note in passing that the goto instruction still remained for a while as a proper feature of High Level Programming Languages before eventually disappearing for ever (e.g. Eiffel).

An interesting statistics that can be obtained from high level source programs is the ratio of the number of lines of code devoted to “pure” algorithms over the total number of lines of code, excluding comments and the like. Of course, the figures differ from one application to the other but it is usually far less than 1/2. This means that such abstract “relational” features as components, classes, methods, inheritance, visibility, assertions and the like describing the objects, their properties, and their relationships are becoming far more important than pure algorithmic features such as conditionals, loops, and more generally “calculations”. It is my belief that such abstract relational features are not well handled in a High Level Programming Languages, whereas pure algorithmic calculations are in my opinion still well handled in such languages.

In other engineering disciplines (i.e. mechanical construction) people do not hesitate to use languages when they are clearly needed and other means when they are not needed. For instance, they use the language Mathematica to define the formal computations related to their usage of the Calculus. But they do not use languages to describe the complex relationships between the components of their future system, their properties, their links, etc.. In fact they store the various components of their product in one form or another and express the relationships that hold between them. We can consider that they thus build a Database of their future system.

What is wrong is to have the semantics of the High Level Programming Language being the medium defining the properties of the offered features. This is far more easily handled (and modifiable) as the invariant properties of a Database. Note that this Database could then be boostrapped formally. It might still be useful to have some “pretty printing” of the contents of the database. This would resemble a high level program but would be produced as an additional output of the construction process rather than as its input.

The Database approach can offer quite a number of other advantages over High Level Programming Languages. Here are a few of them:

1. The system construction Database can be used not only to store future software components but also their various (mathematical) abstractions, and even their initial requirements (described in non-formal ways). And here the tools that replace the compiler and even the computer executing the final program are a proof obligation generator and a prover. Requirements, specification, and design, and corresponding tools, are put together with implementation and corresponding tools.

2. The Database approach will also induce a rather more appropriate way of elaborating the final product than that given by the usage of a High Level Programming Language. Unless it is very small, you shall never write a program and subsequently submit it to the compiler. This sequential approach to construction will be replaced by a more reactive approach. You rather interact with the Database by entering components, their properties, and their relationships with other components. Such an interaction is permanently supported in the background by some tools working in a differential fashion without being explicitly even invoked by the user.

3. The Database approach will allow us to store and update components which can be quite different in nature from computer programs, namely models of pieces of equipments which might interact with the future software components. Such models will be able to be refined as other future software components are. This will allow us to construct embedded systems by elaborating the software components in strong relationships with some modeling of their environment.

In conclusion, we question the present usage of High Level programming Languages for constructing large and complex computerized systems. We propose instead to partially replace it by defining and using a System Construction Database. As a matter of fact, this proposal is not really new: EiffelStudio is a proposal that has been made for a number of years and that goes clearly in that direction.

 https://www.vstte.ethz.ch/Files/abrial.pdf

© 2011 ETH Zurich | Imprint | 22 August 2005