Motivation


Introduction

Darwinian evolution relies on very simple mechanisms. Evolution is achieved by the copying of the building blocks of living organisms, the grouping and re-grouping of these building blocks to form new building blocks, and the gradual change in the roles of the building blocks within larger building blocks. The programs that drive this evolution (DNA, RNA) are themselves subjected to the same evolutionary mechanisms. Occasionally, external influences introduce evolutionary steps that are outside the control of the programs.

This document starts by describing problems encountered by the designers of software, hardware and business process systems. We show that these problems can only be tackled if we root our system design methods in a very simple model of system structure. The evolution of systems within this very simple model is then similar to Darwinian evolution, as we have presented it above.


Background

In the 1960s, some of us were involved in the development of early multi-access operating systems. The developers of these systems wanted to describe the structure of the systems by defining the interactions between the major components of the systems. At the highest level, they easily identified applications, such as stock control, payroll, etc., and the interactions amongst these applications, and readily recognised that these interactions were supported by high level operating system mechanisms, such as files, message streams, etc. But, it then became clear that the interactions between and amongst the applications and the high level mechanisms were, in their turn, supported by lower level mechanisms, such as device handlers, interrupt mechanisms, semaphores, etc. Below this, there were other levels of support, and eventually the hardware. Nowadays, we would understand that they were exploring a complex fractal-like structure and would anticipate the problems inherent in describing such a structure.

In the 1970s, some of us were involved in the development of the ICL VME operating system. This development used a design approach, structural modelling, that was the precursor to IDEF0. The structural design of VME was represented by a set of diagrams similar to IDEF0 diagrams. Each diagram represented the structure of a component of the system in terms of lower level components and the interactions between these lower level components, with the boxes in the diagram denoting the lower level components and the lines denoting the interactions. When we examined the use of this design method, in practice, we discovered that it was quite remarkably effective as an implementation partitioning and control method, but limited as a design method. Much of the design was to be found in separate documents, most of which took views that were orthogonal to the structural model. We believe that this happened because the structural model was tree-structured. This meant that the lines in the diagrams represented much weaker abstractions (closer to the implementation) than the boxes. Boxes were expanded into complex networks of boxes and lines, while lines were expanded into sets of lines. We were hitting that same problem - systems were fractal-like in structure and our tree-structured design methods were incapable of capturing this richness of structure.

In the 1970s, we had an opportunity to talk to a designer of the seven-layer-model of inter-computer communications and found that he readily understood the fractal-like structure that we were developing. We found database systems designers did not understand, even though the message was applicable to them (in a perhaps less obvious way).

In the 1980s, we had an opportunity to work with hardware engineers. We observed that they used diagrams that looked very similar to the IDEF0 style of diagrams. However, we soon realised that these diagrams had a curious constraint that we referred to as the wire-syndrome. The lines in the diagram always corresponded (in the minds of the engineers) with wires or bundles of wires. The hardware engineers had the same problem with their diagrams as the software engineers.

Our work with the hardware engineers also introduced us to the idea of pipe-lining and its implications for our work. The software programmer sees the building blocks of his or her program as a set of atomic machine-code instructions, and sees the program as defining the order in which these instructions are obeyed. However, the hardware engineer breaks these instructions down into lower level instructions, and allows the hardware to obey them in a different order to that shown in the program, though it ends up with the effect that was required by the program. For instance, the hardware may obey both branches of an if-then-else statement and only decide late in the day which branch to follow further. In contrast, the hardware may delay evaluation of some variables until their values are actually needed.

In the late 1980s and the 1990s, we were involved in the development of a business process support system. This showed us that the problems that engineers encountered in the design of software and hardware systems, also applied to business processes. Lines in the diagrams (produced by systems analysts) always corresponded to low level concepts, such as documents or events, while boxes corresponded to powerful concepts like processes and organisations. Therefore, when we talk of systems below, we have in mind software, hardware and business process systems, and hybrids of these systems. Our experience with business process systems also had a major impact on our ideas for modelling and tooling, as described below.

In the 1970s, we had explored notations for representing our fractal-like view of system structure. In the 1990s, we had an opportunity to revisit this work. Our colleagues were developing a system for the Inland Revenue. They needed a model that represented the business system of the Inland Revenue (“customers” and tax collectors and their many interactions, welcome or otherwise), and that also showed how this business system was supported by software and hardware systems. Work on this model led to us creating a notation that we called POSD (process oriented systems design). The diagrams used in this notation were similar, in appearance, to IDEF0 diagrams. However, we ensured that the lines in the diagrams had the same abstraction power as the boxes. We achieved this by saying that, though each line represented an interaction between two components, this interaction could only be realised by a lower level component shared between the two components. This lower level component could then be expanded in lower level diagrams. We were thereby recognising that there was no difference in nature between the boxes and the lines. Our systems were structured from just one type of object and were fractal-like in structure.

POSD could only represent a static view of the structure of a system. In the last decade we have been exploring a more dynamic view of system structure. We have explored ways of representing the fractal-like structure of systems and representing how these structures evolve over time.


Fractal-Like but not Fractal

In the Background section we carefully used the phrase “fractal-like” rather than the word “fractal”. This was because the word “fractal” captured the spirit of our view of system structure (just as it captures the image of the much quoted coast-line-of-Britain example). However our view (like the coast-line-of-Britain image) is not a pure fractal structure so we could not simply use the word “fractal” so we used the phrase “fractal-like” (perhaps meaning “fractal-lite”).

Our view of system structure has the zooming-in characteristic of fractals, as does the coast-line-of-Britain example. When we look closely at (or zoom-in on) the boundaries between systems, we find more systems emerging. This was the characteristic that first intrigued us in our 1960s memory.

As we zoom-in on a system structure we can observe a weak form of self-similarity, in that we always find systems composed of smaller systems. However, the nature of the systems and the numbers of them varies, just as the nature and the number of entities (e.g. bays, cliffs, rocks, and grains of sand) varies in the coast-line-of-Britain example.

It is difficult to claim that our zooming-in goes on indefinitely. Like the coast-line-of-Britain example it must eventually end up with indivisible entities.

Even though our system structures (and the coast-line-of-Britain) are not pure fractal structures, it seems reasonable to use the phrase “fractal-like” in order to suggest the zooming-in and weak self-similarity characteristics that we explore in our project.


Why

The memories given in the Background section have one thing in common. In each of them we needed to relate together different structural views of a system.

Our pipe-lining memory of the hardware engineers from the 1980s was the most clear-cut. The software engineers view of the system (as represented in a program) was mapped in a complex way onto the hardware engineers view (effectively a program built from much lower level instructions).

The operating system memory from the 1960s appears very different, but is in fact similar in nature. There we started with a view of the operating system involving just the applications of the operating system. This had to be mapped down onto a view involving high level operations of the operating system. This in turn had to be mapped onto a view involving lower level operations. Each of these views could have been captured as a program and then we would have been concerned with the complex mapping between programs, just as we were with our pipe-lining memory.

The structural modelling memory from the 1970s is somewhat different. Here we were relating together views of system structure in two very different ways. Firstly, as the designers of VME developed their tree structured model through a number of levels of the tree (about 6), they were expected to provide an algorithmic description of their part of the system. At the higher levels this was a sketch algorithm involving pseudo operations on large scale data objects. At the lowest level of the tree the algorithms were the actual code of the operating system. In practise, the higher level algorithms were weak and were not effectively maintained once the real code was in place. However, in some cases these levels of description and the mappings between them could have been similar to the levels and mappings of our pipe-lining memory.

The second way in which the structural modelling memory related together views of system structure was more interesting. Early in the VME design process it became clear that designers needed some way of describing capabilities that cut right across the operating system. A good example of this was the directory or catalogue structure. The catalogue structure of VME held descriptions of the objects managed and used by the operating system (i.e. files, directories, devices, etc.). There had to be rules for the use and change of this catalogue structure (for instance that a user could not open a file before he or she had created it and attached it to a device). With VME these rules were defined in documents, but implemented in the various branches of the structural model with the catalogue providing their shared state definition.

The work on aspect oriented programming, as encapsulated in the AspectJ extensions of Java, if included in the VME implementation language, would have allowed aspects (like catalogue handling), that cut across the main line code, to be captured in a more satisfactory way. In theory we could have gone a step further and written a program which defined the order in which human beings (and parts of the operating system) could change the catalogue structure. This program would then have cut across and met the structural model at various points. There would have needed to be a program like this for each aspect that cut across the structural model (e.g. catalogue, security, …).

The business process memory of the 1990s took this a step further. Here the aim was to define a human-computer business process that drove, constrained and responded to computer systems and humans. In the VME memory described in the previous paragraph (even if formalised with Aspect) the operating system code was the driving force and the aspects cutting across were simply constraints on it. The Business Process Model turns this view around. It treats the process model as an active agent interacting with (or cutting across in our parlance) other agents (humans and computer systems) but being on equal terms with them. The catalogue “program” of VME could have been viewed in a similar way – seen as a process that encapsulates the way the human user interacts with the operating system. Of course for the foreseeable future (until the famous singularity arrives), the humans always operate at a higher level of functionality than the other active agents, because it is the humans that provide those other agents with their functionality.


What

The above gives the motivation for our work. We want to have many views of system structure relating to each other in the ways introduced above. We can think of these views as programs. In some cases, one program maps onto a more detailed program, just as the software engineer’s program mapped onto the hardware engineer’s program in the pipe-lining memory. In some cases, a program cuts across a number of other programs, meeting each of them at particular points with mutual constraints and responses. Our catalogue/directory and business process memories were of this form.

Thus, we want to be able to relate together many different views of system structure, expressed in many different languages. However, our memories, spanning fifty years, tell us that the languages get in the way of this "relating together". They make strong distinctions between things that are not fundammentally different, eg programs and data, procedures and interfaces, types and instances, processes and transactions, etc. Worse still, the strong distinctions made by each language are inconsistent with the distinctions made by other languages. We therefore want to get away from these distinctions and start from an extremely simple semantics.

We recognise that the many interacting program views combine to form a fractal-like structure. We start with an extremely primitive modelling semantics that captures our fractal-like view of system structure and enables us to represent the many interacting views. This primitive semantics has just one type of object - a system, and one type of relationship connecting such objects - a role of a system as a component in another system. It is the roles, that systems play within other systems, that are vital and that allow evolution to proceed. For instance, multiple copies of the mitochondrial capability existed as independent microbes for many millions of years. The capability became vital to most living things when it was captured in the first living cells and given the power generation role it has now.

Our very simple semantics is captured more formally in basic concepts. In human interface we introduce a modelling language that allows humans to interact with our fractal-like model. Other documents enhance this language and experiment with its use.