Next: 3 The RASSP Authorization Model Up: Appnotes Index Previous: 1 Introduction

RASSP Information Management Appnote

2.0 The RASSP Configuration Management Model

2.1 Workspaces and Configurations

The RASSP Configuration Management (CM) model is based upon the concept of workspaces, and the concept of configurations. Workspaces are partitions of the design object space to allow designers working on the various parts of a project to selectively make their design objects visible to others in the project [Cattell_1991]. Workspaces are organized in a hierarchical fashion as shown in figure 2 - 1, with a global workspace at the root of the hierarchy, shared workspaces as the intermediate nodes in the hierarchy, and private workspaces as the leaves in the hierarchy. The links in a workspace hierarchy represent a parent-child relationship between the linked workspaces. For example, in figure 2 the workspace "Private WS2" is a child of the workspace "Shared WS1" (and the workspace "Shared WS1" is the parent of the workspace "Private WS2"). Workspaces provide for varying levels of sharing of data objects. A user of a workspace has visibility to all the objects residing in the workspace and the objects residing in the ancestor workspaces of the workspace. Thus all users of the database have visibility to data objects residing in the global workspace.

Figure 2 - 1: A Workspace Hierarchy

Configurations are related data objects that evolve at the same time and are grouped together for the purpose of versioning. New configuration objects are typically created in a private workspace, at which point the configuration is considered a transient version of the configuration. A transient version may be updated or deleted. Once the transient version of a configuration reaches a state of maturity suitable for sharing with other designers in a project, it is promoted to a working version of the configuration, by checking in the configuration from the private workspace where it resides, to its parent workspace. A working version may not be updated but may be deleted. Working versions of configurations that are considered to represent the final state of design are promoted to released versions by checking in them to the global workspace. A released version may not be updated nor deleted. We use the notation statei > statej to denote that statei is a higher state that statej. Thus released > working > transient.

A new transient version cj of a configuration c, may be created by checking out an existing version ci residing in a workspace wm to a workspace wn that is a direct or indirect descendent of wm. The source version ci may be in one of the three states prior to checkout -- released, working or transient. If the state of ci prior to checkout is released or working, the state of ci remains unchanged after checkout. However, if the state of ci is transient prior to the checkout, ci is promoted by the system to a working version as part of the checkout operation.

The versions of a configuration are organized as a directed acyclic graph (DAG), as shown in figure 2 - 2, and is commonly referred to as a version tree. The new nodes in the tree start out as a transient version and progressively become working versions and then released versions. A version in a version tree may be deleted only if it is a transient or a working version, and it is a leaf node in the tree. A directed link between two versions i and j in a version tree represents the is-derived-from relationship, i.e., version j is derived from version i. Also, version i is said to be the parent of version j, and version j is said to be a child of version i. We use the notation ci -> cj to represent the parent-child relationship between the two versions i and j of the configuration c.

Figure 2 - 2: A Version Tree

The following rule applies to a version tree:
VT-Rule1: Given two version ci and cj of a configuration c, such that ci -> cj, then the state of cj should be less than or equal to the state of ci.

2.2 The RASSP CM Mechanisms

We describe in this section a minimal set of CM mechanisms that needs to be supported to implement the RASSP CM model. This set will provide the basis for configuration management of design data in the different phases of the RASSP design process. The set of CM mechanisms listed here is intended to serve as a common minimal set; an individual CAD tool may support more than the minimal set proposed here.

We categorize the CM mechanisms into two classes -- workspace functions and version management functions. In the following sections we use a C-like pseudo code to describe the functions. For example,

Bar my_func (Foo a_foo);

describes a function "my_func" that takes as a parameter an object of type "Foo" and returns an object of type "Bar". We use names starting with capital letters, such as "Workspace" to denote the type of object, and names starting with small letters, such as "create_workspace" and "parent_workspace" to denote a function name or a parameter name.

Bar another_func (foo *a_foo=0);

describes a function "another_func" that takes as a parameter a pointer (denoted by the *) to an object of type "foo&334. The "= 0 " is a default value for the parameter if one is not provided. Thus the parameter "a_foo" is an optional parameter for the function "another_func", while it is a required parameter for the function "my_func".

The C-like style we are using to describe the mechanisms is for the brevity of the descriptions, and does not have any implications as to the implementations of these functions, nor the user interface provided by the systems to these functions.

2.2.1 Workspace Functions

2.2.1.1 Creating a workspace

Workspace *create_workspace (char *workspace_name,
Workspace *parent_workspace=0);

Creates a child workspace of the specified parent workspace, and assigns it the supplied name. If a parent workspace is not specified, the new workspace is made a child of the global workspace. The global workspace is a system-created workspace that exists in every database, and has the name "global_workspace" assigned to it.

2.2.2 Accessing an arbitrary workspace

Workspace *get_workspace (char *workspace_name);

Returns a pointer to the workspace with the specified name.

2.2.3 Accessing child workspaces

Workspace_List child_workspaces (Workspace *a_workspace);

Returns a list of pointers to child workspaces of the specified workspace.

2.2.4 Accessing the parent workspace

Workspace *parent_workspace (Workspace *a_workspace);

Returns a pointer to the parent workspace of the specified workspace.

2.2.5 Making a workspace visible

void set_current_workspace (Workspace *a_workspace);

Sets the specified workspace to be the current workspace for the application program. The application program can access only objects that reside in the current workspace, or in the ancestor workspaces of the current workspace.

2.3 Version Management Functions

2.3.1 Creating a configuration

Configuration *create_configuration ();

Creates a new configuration and returns a pointer to it.

2.3.2 Inserting data objects into a configuration

void insert_into_configuration (Configuration *a_configuration,
void *a_design_object);

Inserts the design object pointed to by "a_design_object" into the specified configuration.

2.3.3 Checkout

Configuration *checkout (Configuration *a_configuration,
char *version_name=0);

Creates a new version of the configuration pointed to by "a_configuration", and makes the new version visible in the current workspace. The new version may also be provided an optional version name. The version name is an arbitrary name provided by the user. If the configuration pointed to by a_configuration is a transient version, it is promoted by the system to a working version, by performing a checkin operation (see section 2.3.4), before performing the checkout. The configuration pointed to by "a_configuration" may reside in the current workspace, or in any of the ancestor workspaces of the current workspace. This function returns a pointer to the newly created version of the configuration.

2.3.4 Checkin

void checkin (Configuration *a_configuration);

Checks in the configuration pointed to by "a_configuration". This results in the configuration being made visible to the parent workspace of the current workspace. If the parent workspace is the global workspace, then the configuration is promoted to a released version, otherwise it is promoted to a working version. A working version of a configuration that is checked in to a non global workspace is not promoted in the process of checkin, but is made visible to the parent workspace.