Overview

Although the CEDAR design methodology draws on a long history of software modelling diagrams its origins lie with Shlaer-Mellor; using domain charts, information models and state models from that methodology. However, to the modern practitioner of UML, these will probably be more familiarly known as package, class and state diagrams respectively.

Although the basic concepts will seem familiar, there are details which are different. The most significant of these is a complete specification of bridges, the connections between domains, which are not well defined in previous methodologies. Assigners, as used in Shlaer-Mellor, have also been scrapped in favour of separate singletons.

The actions of states and operations are specified in Action Specification Language (ASL), which is not a programming language. A pseudo-code has been chosen as it maintains a logical separation between the design and code and doesn’t prejudice any specific subsequent implementation.

Overview

A domain chart separates out the broad functionality of the system, conventionally with the application at the top and with other more generic domains, which could potentially be reused in other systems, below. Examples of these latter domains could be logging or alarms, for instance, which are more generic. Each domain may have a connection, a bridge, to another domain if it requires functionality from that domain. So a logging domain may require a comms domain in order to send its logs for instance. Reuse, a long established goal of software design, is at the domain-level in this methodology.

Each domain is modelled from two points of view: its data (information model) and its processing ("behaviour" in UML).

Data

The information model can be considered to be similar to a relational database. Each object (table in an DB), has instances (rows in that DB table), which has 2 or more attributes (columns in that table). All objects have an attribute called "instance_id" (of type "Identifier"), which is used to formalise all relationships (a surrogate DB key). Relationships between objects can be binary, a one-to-one or one-to-many relationship ("associative" in UML) or associative, a many-to-many relationship (uses an "association class" to formalise the relationship). In addition, objects may be sub-types and/or super-types ("specialisation" and "generalisation" in UML) which group common data in the super-type and differences in the sub-types. Singletons are single instance objects, commonly used for status updates.

Processing

The behaviour of a model is defined by actions taken by states, and the events they generate.

Events

Processing (behaviour) is achieved using a state model (aka state transition diagram or state machine in UML), which is associated with an object (in the information model). It is not required for all objects to have a state model. Therefore an information model may contain both active objects, i.e. those which have an associated state model, and passive objects i.e. those which don’t and are purely there to store data. Active objects can modify data for any object in its domain, using actions defined in ASL in a state (or operation). Passive objects must be modified by active objects.

The primary dynamic processing mechanism is via events ("signals" in UML). Events drive an object's state model around and pass data between objects. They can be sent to other active objects within the same domain (internal events) and, in this methodology, to other domains via a bridge (external events). In the case of objects in a super-/sub-type relationship, if a super-type receives an event that isn't handled by its state model, then the event is passed to the sub-type and the event will be processed by the sub-type. This is termed a polymorphic event and allows for the same event to instigate different behaviours depending on the sub-type.

Bridges

The important feature of a bridge is that, it can access both domains, allowing definition of mappings whose input types are defined in one domain and output types defined in another. A bridge, acting as a translator between the "languages" of the two domains, contains an event mapping table. This maps external events from one object to the internal event of an object in another domain.

Event mappings can be one-to-one (a single external event is mapped to a single internal event), one-to-many (a single external event is mapped to multiple internal events), many-to-one (multiple external events map to a single internal event), or many-to-many (multiple external events map to multiple internal events). Every event mapping in a bridge has additional ASL: a mapping function. This additional design facilitates the translation of the event between domains (data types, ranges, logic inversion and so on) and also defines the handling of the -many- mappings.

An external event can be mapped by multiple bridges. For example, an application domain might generate an external event: "status change occurred". This could be mapped to a logging domain object's "here’s some data to be logged" internal event and to an alarms domain object's "here’s some data to create an alarm" internal event. This example would be a single one-to-one mapping, in 2 bridges.

Actions

When an active object receives an event it is in a state to handle, the action for the state will be executed. This action, specified in ASL, defines implementation logic. Actions can navigate relationships, create and destroy object instances, read and write object attributes, and generate internal and external events.

An action may invoke other units of ASL, called operations, of which there are 3 types. Object operations may be called by any state of an object, domain operations may be called by any state (or operation) in a domain, and bridge operations may be called by any state (or operation) in a domain mapped in the bridge. Bridge operations serve the purpose of "asking a question of another domain"; they are defined by the calling domain, and must be mapped in a bridge to any other domain that can provide the answer. The mapping function, with access to both domains in the bridge, can retrieve the required data and return it to the caller.