page 3  (4 pages)
to previous section2
4to next section

class Type {
Set<InternalPort> internalPorts;
Ptr<InfoNode> infoGraph;
Ptr<EvolState> evolTree;
};

class Interface {
Set<ExternalPort> externalPorts;
Ptr<Type> type;
Ptr<ConfigBlock> configBlock;
};

class ConfigBlock {
Ptr<Interface> interface;
Ptr<EvolState> implementation;
Set<ConfigBlock> components;
};

Figure 2: Outline design reuse classes.

specifies a single interface/implementation pair. Outlines of these classes are shown in Fig. 2.

At the bottom of every partition branch must be a leaf" interface that does not represent a lower level design | these are called primitives. The amount of data represented by a primitive determines the granularity of the data, but this may vary across parts of a design.

Design Evolution

Since the purpose of the design process is to make progress by refining designs, the database must not just model static designs but also the way those designs change[6].

When a design action is performed on an existing predecessor design state, a new successor state is produced. Since this new state cannot be derived from more than one immediate predecessor, and since a state can be used to derive any number of successors, the pattern of states for a single design forms a tree structure with design state nodes and design action edges.

Each Type object maintains one evolution tree. Design versions and alternatives are made accessible through this tree | each node represents a different implementation. Where a node has a single successor, the successor represents a more recent version of the design; where a node has more than one successor, the successors represent alternative paths of design (many of which will be discarded mistakes). Each node is modelled by an object of class EvolState, and it is to one of these objects that a ConfigBlock points to identify an implementation. After a certain lifetime, each state is deleted, unless it has been marked as important or is referred to by a ConfigBlock.

It would take a great deal of space to store the whole design state on each state node. Instead, the evolution tree is mapped onto another data structure in such a way that no information is replicated[5]. Each evolution tree has a corresponding directed acyclic

class EvolState {
Ptr<EvolState> predecessor;
Set<EvolState> successors;
Ptr<InfoNode> infoNode;
Boolean important;
int configCount;
};

class InfoNode {
Set<InfoNode> basisNodes;
Set<InfoNode> dependentNodes;
Information increment;
int stateCount;
};

Figure 3: Outline design tracking classes.

+

EvolStates InfoNodes

evolTree infoGraph

F(A,B)

addition of E

etc.

An instance of a subclass of Type

EDCB
A

+

Figure 4: The evolution mechanism.

graph of InfoNode objects. Each InfoNode contains an increment of information and a set of references to other basis" InfoNodes upon whose information the increment depends, as shown in Fig. 3. The total information represented by an InfoNode is the sum of its own increment, those of its basis nodes, and their basis nodes, and so on back to the (single) root of the graph. Some InfoNodes contain no increment, and exist simply to sum their basis nodes.

Each EvolState points to an InfoNode in this graph that represents the total information in that design state. A design step appends a new EvolState to the evolution tree, pointing to an InfoNode found or created to represent the total information in the new design state (see Fig. 4). If the InfoNode graph is extended, this happens in such a way that the sum of information at each of the existing nodes is not changed, and previous design states are therefore preserved. Since most design states are transient, states that have not been used as implementations and have not been marked as important" expire at a certain age and are deleted; this deletion may result in a clean-up of the InfoNode graph to get rid of redundant data.

The evolution tree completely abstracts over the