Portrait of Darwin


An Architectural Description Language

"The formation of different languages and of distinct species, and the proofs that both have been developed through a gradual process, are curiously the same." - Charles Darwin.

Darwin is a language for describing software structures which has been around, in various syntactic guises, since 1991. It was originally developed as a configuration language for the REX project building on experience obtained from the earlier CONIC configuration language. Concisely, this experience taught us that a clear separation of program structure and algorithmic behaviour is a good thing. This separation is enforced by requiring structural aspects to be specified in a configuration language.

In its first incarnation, Darwin possessed many powerful (though sadly expensive to implement) constructs for structural change and evolution. More recently, it has been used to as a configuration language for the Regis distributed programming environment. Currently, we are investigating the use of labelled transition systems for reasoning about the behaviour of Darwin-structured programs.


Darwin encourages a component- or object-based approach to program structuring in which the unit of structure (the component) hides its behaviour behind a well-defined interface. Programs are constructed by creating instances of component types and binding their interfaces together. Darwin considers such compositions also to be types and hence encourages hierarchical composition. The general form of a Darwin program is therefore the tree in which the root and all intermediate nodes are composite components; the leaves are primitive components encapsulating behavioural as opposed to structural aspects.

Component interfaces are composed of one or more elements each of which represents a service provided or required by that component. Specification of a service requirement is an unusual but extremely powerful aspect of the language as it not only reduces components' implicit dependencies on their environment increasing clarity but also increases re-use through this added level of indirection.

Primitive components represent algorithmic units with well-defined interfaces. More complex behaviour is achieved by composite components creating peer instances of primitive components and binding their interfaces together. If overall functionality is not completely specified by a single level of composition, a composite may expose its subcomponents' interface elements in its interface using hierarchical binding. It is irrelevant from without whether a component is a composition or merely primitive; this structural transparency is a pleasing aspect of the language.

One of Darwin's early motivations was to describe the highly-regular structures of parallel programs. To this end, it also permits a degenerate form of the composite component to describe network topologies. Such interconnection components are degenerate because they do not instantiate anything, they merely specify internal bindings between their external interfaces.

Darwin possesses both a textual and graphical notation. The textual form is richer because it permits specification of conditionals and iterations which are evaluated (perhaps using component parameters) when the configuration is elaborated at run-time. The graphical form essentially describes the structure after condition-evaluation and loop-unrolling.

For portability reasons, the compiler for the current language is written in Java. It is decoupled from its environment through an abstract definition of its code generator. Code generators exist for most of the application areas (see below) and we hope to make these available for non-commercial use soon.

Here is the Language Reference Manual (pdf)


Darwin's areas of application are representative of the general trend in the DSE section towards a broader software engineering perspective.

Further information on these and other externally-funded projects in which DSE participates can be found here.

Relevant Publications


A Darwin Miscellany

This page written by Stephen Crane (jsc@doc.ic.ac.uk) and maintained by Dan Chalmers (dc@doc.ic.ac.uk).

Up to: DSE Software, DSE Group, Department of Computing, Imperial College