Practical – 6

Aim: Identify the objects for SCM in term project.

Theory:

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.

(Fig 6.1 - interrelationships between objects )

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 (catalogued 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.

Object Types for SCM

SCM objects can be categorized into two main types: basic objects and aggregate objects.

1. Basic Objects: These are the individual units created during various stages of the software
development process (e.g., requirements, code, design). Each object must have a unique
identifier and may include:
o Requirements Specification Document: Contains the functional and non-functional
requirements of the project.
o Source Code Files: Files for backend logic (e.g., Python, Java), frontend code (e.g.,
HTML/CSS, JavaScript).
o Test Cases: Unit and integration test cases created to verify the functionality of the
software.
o Database Schema: SQL or NoSQL scripts defining the database structure (e.g.,
vehicle registration, entry/exit logs).
o Configuration Files: Files that define environment-specific settings like server
configurations.
 2. Aggregate Objects: These are collections of basic objects that represent higher-level
components or documents. Aggregate objects are often complex and made up of related
basic objects. Examples include:
o Design Specification: This may aggregate the ER diagrams, data models, and design
patterns used.
o Module Components: Groupings of related source code files (backend, frontend).
o Test Suites: A collection of all test cases (unit, integration, system tests).
o Deployment Package: Includes all code, configuration files, and scripts necessary for
deployment.

Identification Scheme
Each object must have a unique identifier that specifies its type, version, and any interdependencies.
This helps to manage changes effectively. Here are examples of identifiers:
 Requirement Document v1.0: REQ_DOC_V1.0
 Backend Code Module v2.0: BACKEND_MODULE_V2.0
 Frontend Code (HTML/CSS) v1.1: FRONTEND_MODULE_V1.1
 Test Case Suite (Unit Tests) v1.2: TEST_SUITE_UNIT_V1.2

Relationships Between Objects

 Part-of Relationships: A basic object can be part of an aggregate object. For example:
o ER Diagram 1.1 <part-of> Data Model
o Data Model <part-of> Design Specification
 Interrelated Relationships: Objects may be interrelated across different branches of the
object hierarchy. For example:
o Data Model <interrelated> Test Case Suite
o Source Code <interrelated> Test Case Suite
These relationships help manage dependencies and ensure consistency across project components.

Evolution of Objects
Software objects evolve as they undergo changes. SCM tools track object versions to maintain
history and manage concurrent updates. For example:
 Object Evolution:
o Version 1.0 (Initial version)
o Version 1.1 (Minor changes)
o Version 1.2 (Major update)
o Branching may also occur, creating version paths (e.g., 2.0, 2.1).

Object Evolution for SCM:

Object Version Change Description

Requirements Specification v1.0 Initial draft
Requirements Specification v1.1 Minor corrections
Backend Module v1.0 Initial implementation
Backend Module v1.1 Bug fixes
Backend Module v2.0 New feature additions
Frontend UI Design v1.0 Initial design
Frontend UI Design v1.1 UI enhancements

(Table 6.1 – Object Evolution)

 SCM Tools for Tracking
SCM tools like Git, Subversion (SVN), or Perforce are used to:
 Track versions of objects (e.g., code, requirements, tests).
 Manage concurrent updates (e.g., multiple developers working on the same object).
 Maintain a history of changes and revert to previous versions when necessary.

Conclusion
For your term project, identifying and organizing basic and aggregate objects within SCM will ensure
that all components are properly tracked and managed. Key objects include requirements
documents, code, test cases, and database schemas, all of which must have clear versioning and
relationships to maintain project consistency.

Rubric wise marks obtained:

Sr. Needs
Criteria Acceptable Good Total
No. Improvement
Content [0-1] [2-5] [6-8]
Poor Fairly understands Clearly understands
1 understanding of project configuration project specific
configuration aspects and identifies configuration
management. objects of SCM. management aspects.
Representation [1] [2]
Fairly presented the SCM Neatly presented the
2 objects and relevant in SCM objects and relevant
diagram form. in diagram form.

Signature of Faculty: