Identification of Objects in the Software Configuration

To manage and control software configuration items each must be different named and then build using an object-oriented approach. 2 kinds of objects can be identified [CHO89] that are aggregate objects and basic objects.  A basic objects air a unit of text which has been develop through a software engineer during design, analysis, coding of testing. Example for a basic object might be a section of a needs specification a source listing for a module or a suite of test cases which are used to exercise the code. Aggregate object is a collection of other aggregate objects and basic objects. The Figure 11.3 is defining design specification which is an aggregate object. By the concept it can be viewed as a named list of pointers which specify basic objects like as module N and data model.

Every object has a group of distinct features which identify it uniquely like a description a name a list of resources and a realization. The object name is a character string which identifies the object unambiguously and the object description is a list of data items which identify:

1.     The SCI type example for document, program, data which is represented through the object;
2.     A project identifier, change and /or edition information.

The Resources are entities which are processed, provided, referenced or otherwise needed through the object [CHO 89]. Example for specific functions, data types or even variable names may be considered to be null and object for an aggregate object.

To configure object identification must also consider the relationships which exist among named objects. An object can be identified as a <part-of> describe a hierarchy of objects. Example for through using the simple notation which is given below.

E-R diagrams 1-4 <part-of> data model;

Data model <part-of> Design Specification;

We create a hierarchy of SCIs.

It is not realistic to suppose that the only relationship between objects in an object hierarchy is aligning striate paths of the hierarchical tree. In various other cases objects are interrelated across branches of the objects hierarchy. Example for data model is interrelated to data flow diagrams like supposing the use of structured analysis and also interrelated to a group of test cases for a specific equivalence class. These relationships cross-structural can be presented in the following manner:

Data model <interrelated> data flow model;

Data model <interrelated> test case class m;

In the 1^st case the interrelationship is among a composite object although the 2^nd relationship is among an aggregate object data basic object and model a test case class m. 

The interrelationship among configuration objects can be presented with a module interconnection language MIL [NAR87].  MIL description interdependency between enables any version system and configuration objects to be automatically constructed. The scheme of identification for software objects must recognize in which objects evolve by the software procedure. Previously an object is baseline it is change various times and even further a baseline has been build modification may be quite frequent. It is possible to build an evolution graph [GUS89] any object. The evolution graph defines the modified history of the come and objects 1.1. Minor changes and corrections result in versions1.1.1 and 1.1.2 that is followed through a major update which is object1.2. The evolution or object1.0 continues by 1.3 and 1.4 but at the similar time a major changes to the object results in a new evolutionary path version 2.0 Both versions are presently supported.

It is quite possible that modification may be made to any version but not necessarily to all editions. How does the developer reference all modules like test cases and documents for version1.4? How does the marketing department know what customers presently have version 2.1? How can we be sure which changes to version2.1 source code are properly reflected in corresponding design documentation? A key feature in the answer to all of the above questions is identification.

A variety of automated SCM tools example for RCS, CCC, SCCS, and Aide-de-Camp have been created to aid in identification and other SCM tasks. Some cases a tool is designed to maintain full copies of only the most present edition. To achieve earlier versions of documents of programs changes catalogued through the tool are subtracted from the most recent version [TIC82]. Scheme makes the current configuration immediately available and other versions simply available.