To control and manage software configuration items, each must be separately named and then organized using an object-oriented approach. Two...
To control and manage software configuration items, each must be separately named and then organized using an object-oriented approach. Two types of objects can be identified : basic objects and aggregate objects.A basic object is a "unit of text" that has been created by a software engineer during analysis, design, code, or test. For example, a basic object might be a section of a requirements specification, a source listing for a component, or a suite of test cases that are used to exercise the code. An aggregate object is a collection of basic objects and other aggregate objects. Design Specification is an aggregate object. Conceptually, it can be viewed as a named (identified) list of pointers that specify basic objects such as data model and component N.
Each object has a set of distinct features that identify it uniquely: a name, a description, a list of resources, and a "realization." The object name is a character string that identifies the object unambiguously. The object description is a list of data items that identify • the SCI type (e.g., document, program, data) represented by the object
• a project identifier
• change and/or version information
Resources are "entities that are provided, processed, referenced or otherwise required by the object ." For example, data types, specific functions, or even variable names may be considered to be object resources. The realization is a pointer to the "unit of text" for a basic object and null for an aggregate object. Configuration object identification must also consider the relationships that exist between named objects. An object can be identified as <part-of> an aggregate object. The relationship <part-of> defines a hierarchy of objects. For example, using the simple notation
E-R diagram 1.4 <part-of> data model;
data model <part-of> design specification;
we create a hierarchy of SCIs.
It is unrealistic to assume that the only relationships among objects in an object hierarchy are along direct paths of the hierarchical tree. In many cases, objects are interrelated across branches of the object hierarchy. For example, a data model is interrelated to data flow diagrams (assuming the use of structured analysis) and also interrelated to a set of test cases for a specific equivalence class. These cross structural relationships can be represented in the following manner:
data model <interrelated> data flow model;
data model <interrelated> test case class m;
In the first case, the interrelationship is between a composite object, while the second relationship is between an aggregate object (data model) and a basic object (test case class m).
The interrelationships between configuration objects can be represented with a module interconnection language. A MIL describes the interdependencies among configuration objects and enables any version of a system to be constructed automatically.
The identification scheme for software objects must recognize that objects evolve throughout the software process. Before an object is baselined, it may change many times, and even after a baseline has been established, changes may be quite frequent. It is possible to create an evolution graph for any object. The evolution graph describes the change history of an object. Configuration object 1.0 undergoes revision and becomes object 1.1. Minor corrections and changes result in versions 1.1.1 and 1.1.2, which is followed by a major update that is object 1.2. The evolution of object 1.0 continues through 1.3 and 1.4, but at the same time, a major modification to the object results in a new evolutionary path, version 2.0.Both versions are currently supported.
Changes may be made to any version, but not necessarily to all versions. How does the developer reference all components, documents, and test cases for version 1.4? How does the marketing department know what customers currently have version 2.1? How can we be sure that changes to the version 2.1 source code are properly reflected in the corresponding design documentation? A key element in the answer to all these questions is identification.
A variety of automated SCM tools has been developed to aid in identification (and other SCM) tasks. In some cases, a tool is designed to maintain full copies of only the most recent version. To achieve earlier versions (of documents or programs) changes (cataloged by the tool) are "subtracted" from the most recent version . This scheme makes the current configuration immediately available and allows other versions to be derived easily.
