| Component Repository Management |
Article Index for Component |
Website Links For Component |
Information AboutComponent Repository Management |
| CATEGORIES ABOUT COMPONENT REPOSITORY MANAGEMENT | |
| configuration management | |
| software components | |
|
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 Object s and their Relationships . 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 Specification s, Design s, documentations, program Code , Test plans, test cases, user Manual s, project plans and so on. 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 Specification s, designs and module Implementation s. VERSION MODEL A version model defines the items to be versioned, the common properties shared by all versions of an item, and the Delta s. It also determines the way version sets are organized. It introduces dimensions of evolution such as Revision s 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. 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 Version s 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. 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. |
|
|