Управление конфигурации программного обеспечения, страница 4

10  Тип SCI (например, документ, программа, данные) представленный объектом

11  Проектный идентификатор

12  Изменение и / или информационная версия

Ресурсы - " объекты, которые обеспечены, обработаны, упомянуты или иначе требуемые объектом ". Например, типы данных, определенные функции, или даже переменные могут рассматриваться, в качестве ресурсов объекта. Реализация - указатель на " единицу текста " для основного объекта и пустого указатель для совокупного объекта.

Конфигурация определения объекта должна также рассмотреть отношения, которые существуют между названными объектами. Объект может быть идентифицирован как < часть - > совокупного объекта Соотношение < часть - > определяет иерархию объектов. Например, используя простое примечание

E-R диаграмма 1.4 < часть - > модель данных;

Данные моделируют < часть - > особенность проекта;

Мы создаем иерархию SCIs.

Нереалистично предположить, что единственные отношения среди объектов в иерархии объектов- по прямым дорожкам иерархического дерева. Во многих случаях, объекты находятся во взаимосвязи в пределах отраслей иерархии объекта. Например, модель данных находится во взаимосвязи с диаграммами потока данных (принятие использования структурированного анализа) и также находится во взаимосвязи с набором тестов для определенного эквивалентного класса. Эти пересекающиеся структурные отношения могут быть представлены в следующей манере:

Модель данных < взаимосвязана> модель потока данных;

Модель данных < взаимосвязана> тест класс м.;

В первом случае, взаимосвязь - между сложным объектом, в то время как вторые отношения - между совокупным объектом (модель данных) и основной объект (тест класс m).

Взаимосвязи между объектами конфигурации могут быть представлены модульным языком взаимосвязи (МИЛ). МИЛ описывает взаимозависимости конфигурации объектов и позволяет любой версии системы быть построенной автоматически.

Схема идентификации объектов программного обеспечения должна признать, что объекты развиваются в течение процесса программного обеспечения. Прежде, чем объект определен, он может измениться много раз, и даже после того, как определение было установлено, изменения могут быть весьма часты. Для любого объекта возможно создать граф развития. Граф развития описывает историю изменения объекта, как иллюстрировано в Части8.3. Объект Конфигурации 1.0 подвергается пересмотру и становится объектом 1.1. Незначительные исправления и изменения кончаются версиями I.I.I и 1.1.2, которые сопровождаются главной модернизацией, которая является объектом 1.2. Развитие объекта 1.0 продолжается до 1.3 и 1.4, но в то же самое время, главная модификация ведет к объективным результатам в новом эволюционном пути, версия 2.0. В настоящее время поддерживаются обе версии.

Изменения могут быть сделаны в любой версии, но не обязательно ко всем версиям. Как разработчик ссылается на все компоненты, документы, и тесты для версии 1.4? Как отдел маркетинга узнает, что клиенты в настоящее время имеют версию 2.1? Как мы можем убедиться, что изменения к коду источника версии 2.1 должным образом отражены в соответствующей документации проекта? Ключевой элемент в ответе на все эти вопросы - идентификация.

Часть 8.3. Графа Развития

Разнообразие автоматизированных SCM инструментов было развито, чтобы помочь в идентификации (и другой SCM) текстов. В некоторых случаях, инструмент предназначен, чтобы поддержать полные копии только самой современной версии. Чтобы достичь более ранних версий (документов или программ) изменения (занесенные инструментом) "вычтены из самой современной версии. Эта схема делает текущую конфигурацию немедленно доступной и позволяет другим версиям быть легко полученными.

8.4 КОНТРОЛЬ ВЕРСИИ

Контроль Версии объединяет процедуры, и инструменты, чтобы управлять различными версиями конфигурации объктов, которые созданы в течение процесса программного обеспечения. Clemm описывает контроль версии в контексте SCM: