Change Set:
The Aide-De-Camp (ADC) system takes one of the basic mechanisms of a file repository with version control and makes it accessible to the user for supporting the easy creation of a particular version of a product (or part thereof).
It does this by extending the notion of a delta. The delta is given a name and the user defines a formula that indicates which deltas should be combined to make up a particular version of a file or part of the product.
The combination of the deltas and the files to which they are applied and the reasons for each delta make up the change set. That is, the user can designate a change set that represents all the changes to a group of files (such as a configuration) and the reasons for each change (which could be the same across the whole group); ADC keeps track as to which delta is associated with which file in the group.
The user can then treat this group as a whole and perform operations on the group. At any time, the user can create a version of a product by defining a base version plus a combination of change sets. The change sets reflect an audit trail of changes to a configuration of files as well as a means of accessing any version of a configuration that is not dependent on the latest version of that configuration.
System Model:
The Cedar System Modeller was one of the first systems to explicitly define the structure of a configuration, i.e., a set of related components that make up the product under development. The System Modeller tracks the changes to components and controls the compiling and loading of configurations. The system model makes it clear to the environment what components are relevant and what relationships they have.
It has a readable textual representation that can be edited by a user at any time and can be used by tools such as browsers, debuggers, and inter-module analyzers. In fact, the environment can use this model to perform some analysis on the components and make sure that the product is in a sensible state.
For instance, a user changing a file may invalidate several other related files. The System Modeller recognizes this automatically and can automatically recompile the related (out-of-date) files, thereby creating a new latest version of the product. By defining the static structure of a product, the System Modeller allows the environment to assist in maintaining the integrity of the product.
Sub Systems:
The Rational environment adds to the notion of a system model and repository by incorporating features for dealing with a very large product.
Rational provides for partitioning a large Ada product into parts, allowing for confining the scope of the effects of changes. The parts are called subsystems. Subsystems have interface specifications and represent a configuration item; therefore, they can be treated as a whole.
Engineers can work on a subsystem making changes and as long as none of the interface specification is changed, any recompilations will happen only to components within that subsystem. Changes to the interface will possibly require the whole product to be recompiled.
Subsystems have version control on their components, and subsystems themselves can be of a particular version. Subsystems thus minimize the need for recompiling the complete product. Also, due to the interface specification, the user can mix-and-match subsystems to make up a particular version of the product. The Rational environment checks that only compatible versions of subsystems are combined. Subsystems represent a way for having users limit the scope of their changes and for the environment to check the validity of combined configurations.
Configuration Thread:
The Domain Software Engineering Environment (DSEE) takes the notion of a system model and enhances it by incorporating derived objects (i.e., object files as well as source files) and tools that do the derivation to the model.
This allows the user to capture more precisely the static components involved in building a product. These components include: the versions of tools, the parameters used to invoke the tools, and the versions of components, along with other specific parameters that are worthwhile recording.
As the product is compiled, DSEE automatically captures all the time and the versions of the components used and keeps this information in the repository in an object known as the configuration thread. Each configuration thread is given a unique identifier by DSEE. This identifier can then be used by DSEE as the permanent, all-encompassing history of the components necessary to build the product.
At any point in time, the user can simply request that a particular version of the product be regenerated. Users no longer need to keep multiple copies of the same version of files and tools and any intermediate files in some central location: DSEE has a complete inventory of all components, their versions and their timestamps, thereby reducing the need for multiple copies and, hence, wasted space. Much of the management of derived objects as well as source objects is under the control of the CM system.
Object Pool:
Using its notions of system model and configuration thread, DSEE has all the necessary information to recognize what is required to generate a particular version of a derived object.
By associating this information with each derived object, all the objects can be put into a pool. Thus, whenever a user needs a particular derived object (or a compatible one), DSEE can automatically check whether one already exists in the pool, thereby obviating the need for regenerating the object.
The user need not know that that derived object exists: DSEE does all the checking based on both the generation information the user gives and on existing configuration threads. This saves on the amount of compiling time and space required, and reuses work already done. In effect, the CM system has knowledge of how to optimally and exactly regenerate a particular version of the product.
Attributes:
The Adele System generalizes upon the repository, system model and configuration thread notions by using a database and data modeling capabilities. Thus the repository becomes more object oriented and the user can describe a product in terms of a data model.
Essentially, the components of a product are represented as database objects with attributes and relationships. Attributes are user-defined information about an object, for example, a certain object is a debugging object and its target system is VMS.
Relationships define dependencies between objects, such as object A depends on object B. Hence, the user can describe a configuration in terms of characteristics of objects, rather than in terms of a composition of specific versions of objects. That is, by using selection rules and constraints centered around the attributes, the system can compose an appropriate configuration.
The user can define any structure to a product (rather than just a hierarchical structure) and can designate a product in terms of desired characteristics. Thus, the user can describe a product at a higher level of abstraction (instead of in terms of a long list of instances of files).
Consistency Checking:
The Configuration Management Assistant (CMA) enhances data modeling for CM with the addition of certain classes of attributes and relationships. Based on the meaning of the attributes and relationships, CMA can check to determine whether a configuration (which is a set of instances of objects) is valid.
To be valid means that all the objects in the configuration make up a workable set; they are consistent with each other. It is the semantics of the attributes and relationships that permits CMA to determine the consistency. The classes of attributes represent user-defined characteristics including constraints, typing, and versions of configurations. Classes of relationships represent logical dependency, consistency, compatibility, component, instance, and inheritable dependency.
These allow CMA to ensure that all instances of objects have compatible attributes and relationships in the formation of a configuration. In particular, CMA checks to determine whether configurations are complete, consistent, unambiguous, and have no version skews. With the formation of a configuration, CMA can add that configuration's characteristics to its database. Then, for subsequent use of that configuration or parts of it, CMA has enough information to check their consistency. The user can rely on the system to identify any inconsistencies and to preserve consistencies in creating and re-using configurations.
