И. Соммервилл - Инженерия программного обеспечения (1133538), страница 154
Текст из файла (страница 154)
Выходная версия (гс!еэзе) систсиы — это та версия, которая поставляется заказчику. В каждой выходной версии либо обязательно присутствуют новые функциональные возможности, либо она разработана под новую платформу. Количество версий обычно намного превышает количсство выходных версий, поскольку версии создаются в основном для внутреннего пользования и нс поставляются заказчику. В настоящее время для поддержки управления версиями разработано много разнообразных САБЕсрслств (см.
раздел 29.5). С помощью этих средств осуществляется управление хранением каждой версии и контроль за допуском к компонентам системы. Компоненты могут извлекаться из системы для внесения в них изменений. После введения в сис. тему измененных ком понснтов получается новая версия, для которой с помощью системы управления версиями создается новое имя. 29.3.1. Идентификация версий Любая большая программная систсиа состоит из сотен компонентов, каждый нз которых может иметь несколько версий. Процедуры управления версиями должны четко идентифицировать каждую версию компонента.
Существует три основных способа идентификации версий. 1. ггуиерпцил вержй. Каждый компонент имеет уникальный и явный номер версии. Эта схема идентификации используется наиболее широко. 2. Идеитификп пил, основе кипя ип зипченилх пофидувим.
Каждый компонент идентифицирует. ся имснсм, которое, однако, пс является уникальным для разных версиИ, н набором значений атрибутов, разных для каждой версии коипонснта [110). Здесь версия компонента идентифицируется комбинацией им спи и набора значений атрибутов. 3. Ндеитификпхил нп основе кммиеиий Кажлая версия системы именуется так жс, как в способе идентификации, основанном па значениях атрибутов, плюс ссылки на запросы на изменения, которые реализованы в данной версии системы [244).
Таким образом, версия системы идентифицируется именем н теми изменениями, которые реализованы в системных компонснтах. Нумерация версий По самой простой схеме нумерации персий к имени компонента или системы добавляется номер версии. Например, бо!аг!з 2.б обозначасг версию 2.б системы Бо!апэ. Первая версия обычно обозначается 1.0, последующими версиями будут 1. 1, 1.2 и т.д. На каком-то этапе создастся новая выходная версия — версия 2.0, нумерация этой версии начинается заново — 2.1, 2.2 и т.д.
Эта линейная схема нумерации основана на предположении о последовательности создания версий. Подобный подход к идентификации версий поддерживается многими программными сродствами управления всрсияин, например КСВ (см, раздел 29.5). 394 Часть 7П. Эволзоциа программного обеспечения На рис.29.3 графически проиллюстрирован описанный способ нумерации версий. Стрелки на рисунке проведены от исходной версии к новой, которал создается на сс основе. Отметим, что последовательность версий нс обязательно линейнал — версии с последовательными номерами могут создаваться на основе разных базовых версий. Например, на рис.
29З видно, что версия 2.2 создана иа основе версии 1.2, а нс версии 2.1. В принципе каждая существующая версии может служить основой для создания новой версии системы. Рис. 29З. Структура скстемяык версий Данная схема идентификации версий достаточно проста, однако она требует довольно большого количсспт информации для сопоставления версий, что позволяло бы отслеживать различия между версиями и связи между запросами на изменения и версиями. Поэтому поиск отдельной версии системы нли компонента может быть достаточно трудным, особенно при отсутствии интеграции между базой данных конфигураций и системой хранения версий. Идентификация, основанная на значениях атрибутов Основная проблема схсм явного именования версий заключается в том, что такие схемы нс отображают тех признаков, которые можно использовать для идентификации версий, например: ° заказчик; ° язык программирования; ° состоянис разработки; ° аппаратная платформа; ° лата создания.
Если каждая версия определяется единым набором атрибутов, нетрудно добавить новыс версии, основанные на любой из существующих версий, поскольку они будут идентифицироваться единым набором значений атрибутов. При этом значения многих атрибутов новой версии булуг совпадать со значениями атриб1тов исходной всРсин; таким образом можно прослеживать взаикюотиошсния между версиями. Поиск версий осуществляется на основс значений атрибутов. При этом возможны такие запросы, как "самая последняя всрсия", "версия, соэданнал между определенными датами" и т.п. Например, обозначение для версии системы АС3Р, разработанной на языке 3ата для использования под управлением 1т1пдовв ХТ в январе 1999 года, будет выглядеть следующим образом: АСЗР (язык 1ава, платформа = ХТ4, дата январь 1999).
29. Управление конфигурациями 595 Идентификация, основанная на значениях атрибутов, системой управления версиями может применяться непосредственно. Однако болев распространено использование только части имени версии, при этом база данных конфигураций поддерживает связь между значениями атрибутов и версиями системы и компонентов. Идентификация на основе изменений Идентификация, основанная на значениях атрибутов, устраняет проблему поиска версий, свойственную простым схемам нумерации, когда для поиска версии трсбустсл знание сс атрибутов. Но в этом случае для рспгстрации взаимосвязей между версиями и изменениями необходимо использованис отдсльной системы управления изменениями. Идентификация на основс изменений применяется скорее к системам, чем к системным компонентам; версии отлсльных компонентов скрыты от пользователей системы управления конфигурацией. Каждое изменение в системе описывастсл массивам эзмелснкй, где указаны измснсния в отдельных компонентах, реализующие данное системное изменение.
Массивы изменений могут применяться последовательно таким образом, чтобы создать версию системы, в которой реализованы все нсобходимыс изменения. В этом случае нс требуется точного обозначсния версии. Команда управления конфигурацисй рабо. чает с системой управления всрснямн посредством системы управления изменениями. Естественно, применение нескольких пассивов измснсний к системе должно быть согласовано, поскольку отдельные массивы изменений могут быть нссавл~сстимыми н их последовательное примснснис может привести к появлению неработоспособной системы. Кроме того, массивы изменений мо1уг конфликтовать, если они прслполагают разные изменения в одном компонснтс. Для устрапснил этих проблслг примсняются средства управления версиями, поддерживающие идентификацию на осповс изменений, что позволлст установить точные правила согласовангюсти последовательности системных версий и что, в свою очередь, ограничивает способы комбинирования массивов изменений.
29.3.2. Управление выходными версиями Выходной версией системы называется всрсия, поставляемая заказчику. Мснсджсры по выпуску выкодных версий отвсчают за решение о дате выпуска, за управление процессом создания выходной версии, а также за созданис документации. Выходная версия системы включает в ссбл нс только системный код, но также ряд компонентов. 1. Конфигуракионнмг факльь определяющие способ конфигурирования системы для каждой инсталляции. 2. Флклы длннмх, нсобходииыс для работы системы.
3. уурогряммя усэганавкк, которав полюгаст инсталлировать систему. 4. Докумпгэюция в электронном и печатном виде, описывающая систему. 5. Упаковка иреклаиныгллэиркллм„разработанные специально для этой версии системы. Менеджеры по выпуску выходных версий нс мокнут быть уверены, что заказчики всегда будут заменять старые версии системы новыми. Нскоторыс пользователи вполне удовлс" творсны установленными у них версиями н считают, что установка новых версий нс стоит затрат.
Поэтому новыс выходные версии системы нс должны зависсть от предыдущих. Рассмотрим следующую ситуацию. 1. Версия 1 системы находится в эксгиуатации. 2. Выпускается версия 2, требующая установки новых файлов данных. Однако неко торыс пользователи нс нуждаются в дополнительных возможностях всрсии2 и продолжают использовать версию 1.
3. Версия 3 требует файлов, содержащихся в версии 2, но сама нс содержит этих файлов. 596 Часть УП. Эволюция программного обеспечения Дистрибьютор ПО не может знать наверняка, что файлы данных, требующиеся для версии 3, уже установлены: некоторые пользователи будут переходить от версии 1 к версии 3, минуя версию 2. У других пользователей вследствие каких-либо обстоятельств файлы данных, связанные с версией 2, мо~ут быть изменены.
Отсюда следует простой вывод: версия 3 должна содержать все файлы данных, Таблица 29.1. Факторы, влияющие на стратегию выпуска версий системы Фактор Описаяяе Необходимость выпуска новой версии обусловлена зарегист- рированными ошибками в существующей версии системы. Неболыяие дефекты можно устранить с помощью заплат (расспез), которые часто распространяются через 1пгегпег Техническое качество системы Пятый закон Лемана (см. главу 27) Этот закон постулирует постоянство приращения функцио. иальных возможностей в каждой выходной версии по сравне- нию с предыдущей. Однако существуют и исключения, напри- мер за версией с достаточно большими изменениями следует версия с исправлением ошибок Конкуренция Необходимость новой версии объясняется наличием на рын- ке конкурирующих продуктов Требования рынка Отдел маркетинга компании может приурочить выход новой версии к определенной дате Предложения заказчика об изменениях в системе Для разработанных под заказ систем заказчик может предло.
жить внести в систему ряд изменений, тогда новая версия выйдет сразу после реализации этих изменений Создание выходной версии Создание выходной версии — это процесс сбора всех необходимых файлов и документации, составляющих выходную версию системы. Требуется определить нужные исполняемые коды программ и файлы с данными. Конфигурация выходной версии должна определяться под конкретный тип аппаратных средств и операционной системы. Также нужно подготовить ннстр>кции лля пользователей по инсталляции системы, в том числе Принятие решения о выпуске выходной версии Подготовка и распространение программных систем требуют больших затрат, осо.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
