Component repository management
From Wikipedia, the free encyclopedia
Component repository management is a field of configuration management that seeks to ensure the safe storage of different components of a software product and all its versions. This topic includes product model, revision control, and software configuration management.
Contents |
[edit] Product model
The product model describes the structure of a software product in a single version system, which means the version model is not taken into consideration. It can be represented by a product graph in which nodes and edges represent the software objects and their relationships.
[edit] Software object
A software object records the result of a development or maintenance activity. A SCM system has to manage all kinds of software objects created throughout the software lifecycle, including requirements specifications, designs, documentations, program code, test plans, test cases, user manuals, project plans and so on.
[edit] Relationship
Relationships are the connectors of software objects. in the product model diagram, they are the edges between nodes. Composition relationships and dependency relationships are the two main relationships used in the product model.
Composition relationships are used to organize software objects with respect to their granularity. For example, the subsystems of a software product which in turn consist of modules.
Dependency relationships or in short dependency establish directed connections between objects that are orthogonal to composition relationships. They include lifecycle dependencies between requirements specifications, designs and module implementations.
[edit] Version model
A version model defines the items to be versioned, the common properties shared by all versions of an item, and the deltas. It also determines the way version sets are organized. It introduces dimensions of evolution such as revisions and variants, it defines whether a version is characterized in terms of the state it represents or in terms of some changes relative to some baseline, it selects a suitable representation for the version graphs, and it also provides operations for retrieving old versions and constructing new versions.
Another field related to version model is software history. It records all the versions of a software product safely and properly, it also records who created the revision along with what comment. Delta is used to reduce the spaces needed for storage, since two successive versions are often very similar (98% same on average).
It also provides supports for multi-user management. The traditional locking method is still used while a new advanced synchronizing method can greatly improve the efficiency.
[edit] Version and product model structures
Because product model only considers the software structure of a single version model, and the version model does not take software structure in to consideration, methods to integrate the two models will be discussed in this section. In particular, we will investigate which items are put under version control and how versions of different items are interrelated with each other.
According to the selection order during the configuration process, we can classify the structures into 3 categories, product first, version first and intertwined:
Product first means that the product structure is selected before the version models of components. This approach is followed, for example, by SCCS and RCS. But this method suffers from the restriction that structural versioning can not be expressed (it is because the product structure is fixed for all configurations).
Version first means the version of product is selected first and uniquely determines the component versions. Different product versions may be structured in different ways. For example, a version of a component is contained only in the product version 1.0 but not 2.0. PCTE is an example of an SCM system using this organization.
Intertwined means that the selections of version model and component structure are performed in alternating order. Intertwined structure is relatively more flexible than the two methods mentioned above, because when a new change happens or a new component need to be added in the configuration, for most of time it is not necessary to change the whole configuration structure.
In addition, version first and intertwined both take in to account that different versions of a certain object may vary with respect to their relationships of other objects. This means that in addition to objects, relationships are versioned as well.
[edit] A meta-model of the AND / OR method
As shown in the intertwined configuration structure, an AND / OR graphs can be used to illustrate the interplay of product model and version model. The graphs consist of nodes and edges, and selections of the nodes represent the configuration of a certain software product of a certain version. There are two types of nodes — AND nodes and OR nodes. Analogously, a distinction is made between AND and OR edges, which emanate from AND and OR nodes, respectively. A meta-model is presented in the following figure:
An unversioned product graph can be represented by exclusively AND nodes/edges. Then this AND/OR graph will be the same as the product model or product compositions. While versioning of the product graph is modeled by introducing OR nodes. Versioned objects and their versions are represented by OR nodes and AND nodes, respective.
The dependency relationships and composition relationships can be both represented by AND edges.
