И. Соммервилл - Инженерия программного обеспечения (1133538), страница 156
Текст из файла (страница 156)
29.5. Ввсста иввлекие версий Я. Средство региетрации игменеиий. Регистрирует все изменения, сделанные в коде системных компонентов. В некоторых системах управления версиями это средство используется для поиска нужной версии системы. 4. Средевгвв пвддержхи иаралвельивй ргпрабовгки, Различные версии системы могут разра- батываться параллельно и изменяться независимо друг от друга. Система управле- 600 Насть 7П. Эволюция нрограыыногп обеспечения ния версиями должна отслеживать компоненты, которые изменяются, и контролировать, чтобы на один и тот жс компонент нс накладывались изменения, сделанные разными группами рааработчиков.
Некоторые системы позволяют единовременно изменлть только один экземпляр компонента, другие автоматически разрешают возникшие коллизии, когда измененные компоненты возвращаются в систему управления версиями. 29.5.3. Средства сборки систем Сборка систем — это очень трудоемкий вычислительный процесс. Например, процесс компиллции большой системы, состоянгсй из сотен компонентов„может занять несколько часов. Если компиляцию и связывание компонентов такой системы выполнять вручную, то оператор неизбежно сделает какие-либо ошибки.
Срсдства сборки систем автоматизируют этот процесс, что исключает потенциальные ошибки, совершаемые прн ручном компилировании, и, возможно, сокращает время сборки системы. Срелсгва сборки систем могут быть как автономными, например соответствующие утилиты а системе ()п)х [114), так и интегрированными со средствами управления версиями. Как правило, САБЕ-средства сборки систем состоят из следующих компонентов. 1.
Язык слевифиииУзооляил злвисииоетей и аютвеозствуюзбий инте)зя(зеэттор. Описывает и управляет эависилгостями между систсмными компонснтами и минимизирует воэможныс перекомпиляции. 2. С)зедетвл выбора и ~еллизлиии. Это компиляторы и другие средства работы с файлами исходного кода.
3. Средалвл умел)зедевениой илилиляции. Нскоторыс компоновщики систем, особенно интсгрированныс с системами управления конфигурациями, могут поддерживать распределенную (сетсвую) компиляцию. Вместо выполнения всего процесса компиляции на одной машине компоновщик находит свободные процессоры в компьютерной сети и организует параллельную компиляцию. Это значительно сокращает время сборки системы. 4. Средеомо улутлюиия вэт)эичнмни обэеиоинос Вторичные — это объекты, которые сот даются на основе других, исходных, объектов. Средство управления такими объектами связывает исходный код и вторичные объекты и создает новые объекты только тогда, когда изменяется исходный код. Управление вторичными объектами и минимизацию количества перекомпиляций лучше всего объяснить на простом примере. Рассмотрим ситуацию, когда программа спшр соэдастсл из объектных модулей зсап.о, зуп.о, зеш.о и сдеп.о.
Для объектных модулей существуют модули, содержащие исходный код и имеющие имена соответственно всяп.с, вуп.с, вепъс и сдеп.с. Эти модули используют общий файл объявлений бе(в.)ъ Зависимости между модулями показаны стрелками на рис. 29.6 (стрелки можно "прочитать" как "зависит от"). Допустим, в модуль зсап.с внесены изменения. Система сборки должна определить, что вторичный объект зсап.о необходимо создать заново, и вызвать соответствующий компилятор для псрскомпиляции модуля всяп.с и создания нового экземпляра объекта всяп.о. Далее система сборки на основании связи между согпр и эсап.о определяет, что необходимо заново создать также программу согпр путем связывания модулей зсап.о, вуп.о, зепъо и сдеп.о.
При этом система определяет, что объектный код других компонентов нс изменялся, поэтому перекомпиляция их исходного кода не требуется. 29. Управление конфигурациями бтУ1 Рис. 29.6. Скоко эаоиснкосзмй модумсй Некоторые системы сборки используют дату изменения файла как ключевой атрибут, определяющий, требуется или нет псрскоипиляция.
Если дата изменения файла исходного кода более поздняя, чем дата изменения соответсгвующего файла объектного кода, то этот объектный код необходимо создать заново. Зто гарантирует, что вторичный объект будет создан на основе самой последней версии исходного кода. Если псрекомпилнрустся ранняя версия исходного кода, то изменяется дата ее модификации и система сборки по этой дате определяет, какие компоненты должны быть перекомпилированы нли созданы заново. Другие системы сборки используют более сложные подходы к управлению вто. ричными объектами.
Они вводят дополнительный атрибут для вторичных объектов, где указывается версия исходного кода, на основе которого создан этот объект, и по возможности сохраняются все версии вторичных объектов. Это позволяет иметь объектный код всех версий исходного кода без дополнительной перекомпиляции. сего зтцттеадо лами о ссчйаь ее|Фоло и . с сь =озоне сакэя л.;е кэвтээ .*.;.; «:стояние,ээча ,, КЛЙЧЕВЫЁПОНЯТИЯ оэЯФ:--"-Ф!ОРН4ВФМФВНО ЙУ-.:ндФ:ЕфФ~ЯЩ7', 44 рр':; В-бриащ проектигдаян отслаливания различных'вврснэ6'всяко йровктйькцдокуцвйтов рззрабаты'-','. ,~Фф "вав~сн и используется'фарманыая схема имвнования документов „"7:.':, Ф,"'„'".
' ~» '~;. Длл,уйрввления конфигурасивй' 'необходима база'димых,донфдгурвций,'1гдтлв цтситиусяеатся Йтйфтр;.*".,' .ф!„.миди о проввдвйных в'система тммвнв»йп н аитРосы нй'й~омммння.," .',й';::,~!;;„~,:.'..::„", ,'-"„' ",.;е7."-:-'дят уойрквввт~йтдснфигурацивй'йеобитдима схема Йдипифиюцйи 'вврчдтй. Йррйй'майо'идантифй.:: ~~;ЦИРОВИЪРР йаЮЕРВМ, На ОСИИЕ ааЧЕай атРИбУТСВ И На ОСНСВВ тММВНВНИУЬ ~НЕСВННЦХ ВоСИСТВТ~У. „' ';,о'..." "'Выходят версэйт систеый включает исполняемый код, файлы длаэйных,'конфистураццоннйв 4ййы' й.' ~~~за УУИУйЕНТНЦИКТ,:УПРМПЕНИЕ ВЫХОДНЫМИ ВЕРСИЯМИ, ПРВДУСМатднааат ОПРВДВЛЕНИВ ДатЫ ВЫПУСКа'' СЙСТОМйаПОДГОТОНКУ ВСВЙ ИНфОРМВЦИИ ДЛЯ РНСПРОСТРВНаэййя СИСТВМЫ И ДОКУМВНТНРОВНННВ ЯЖДСНО ', 3::.;".,'ьиодйойвв~ ий.'~4 стинФ';";:": К~''я:"""": эъ"-'6Утьч' ' ".'-"'"с':!."!."" "':.'"..! .,'Ь,:'.:::.'- 602 тхаг "Сборка системы' —,,зто процесс компоновки,,системныгкокпоненще':в,вид~:" " ' ь """ ;..:Я: ' ДГЮ ЩцтДЕРжКИ ПРОЦЕССа УПРЗШЮНИЯ ЮНФаУРЕЦИЕй ПРИМВШГЮтов СДВЕгСРЗД~ййЦЗНИ,'Й~4Щат:„ ~-:;-;.:.
'средства для управления версиями и изме«еииями и средства дги,сбойки систгйги' ',:.,',:~фЩф':-'„' Упражнения 29.1. 29.2. 29.3. 29.4. 29.5, 29.6. 29.7. 29.8. хХаств 1ГП. Эволюция программного обеспечения Обзвоните, почему в системе управления конфигурацией для идентификации документов не используются названия документов. Предложите схему идентификации документов, которую можно было бы использовать во всех проектах вашей органиэации.
Используя модель "сущность-связь" или обьектно-ориентированный подход (см. главу 7), разработайте модель базы данных конфигураций, которая должна содержать информацию о системных компонентах, мг версиях, выходных версиях системы и об изменениях, реализованных в системе. База данных должна обладать следующими функциями: ° извлечение всех версий илн отдельной указанной версии компонента; ° извлечение последней па времени изменения версии компонента; ° поиск запросов на изменения, которые были реализованы в указанной версии системы; ° определение версий компонентов, включенных в указанную версию системы; ° извлечение выходной версии системы, определяемой по дате выпуска или по имени заказчика, которому она поставлена.
С помощью диаграммы потока данных представьте модель управления измененгвми, которую моию было бы применить в большой организации, занимающейся разработкой ПО для внешних заказчиков. Запросы на изменении могут поаулать как от внешних, так и ст внуцюннмх источников. Опишите трудности, которые могут встретиться при сборке системы. В частности, рассмотрите проблемы сборки системы на хост. компьютере. Со ссылкой на систему сборки обьпсните, почему иногда необходимо сохранять устаревшие компьютеры, на которых разрабатывались большие программные системы.
При сборке систем часто возникает сложная проблема, состоацая в том, что имена физических файлов встроены в системный код и используемая файловая структура отличается от файловой структуры на конечной машине, где будет установлена система. Составьте руководство для программистов, которое поможет избежать этой и подобных проблем при сборке систем. Приведите пять факторов, которые необходимо учитывать прн сборке выходных версий больших программных систем.
Опишите два способа оптимизации процесса сборки системы из ее компонентов с помощью соответствующих СДВЕ-средств компоновки систем. 603 Литература Литература 1. АЬЬои К. Ргобзат йеь!Кп Ьу !п(оппа) ЕпКГЬЬ йсзсприопз // Саят. АСМ. — 1983.— 26 (11). — Р. 882-976. 2. АЬйе! СЬа!у А. А., СЬап Р. г". и а! Еча!ш!оп оГсотрег!пК ьойшагс гс!таЬ!Гйу ргей!сбопз // !ЕЕЕ Ттааз. ен 5а/)шатт ЕттЕГпеелле. — 1986.
— БЕ-12 (9). — Р. 950-1017. 3. АсМгоуй Б., Натрет К. ет а1 5/лшайел Тес!тттаЬА» алй Ртаегтеа! Ре!ие Итат(с — Муйоп Ксупсз Орсо 1!шчсгягу Ргем, 1992. 4. Айать Е. Х. Орбт!гитб ргсчепгабче ьепйсе оГ ьоГичагс ргойиси // !ВМ/ Вез Гь* !теи— 1984. — 28 (1). — Р. 2 — 16. 5. А1т А. Ч., Кегп!КЬап В.
Чт. ег а! Т)шйшй Ртеетаппп!лбуетнбиабе — ЕпК!сисой С!!Кь, Щ: Ргепйсе-НаП, 1988. б. Л)Ьгесйг А. /. Меаьипп8 аррбсагюи йсше!ортепг ргойисгпиу // 5НАЕЕ/СГЛ1»Е !ВМ АГфб 7 8 9 10 11 12 13 14 1э 16 17 18 19 20 21 22 23 24 габен Гусит!а(тттшнг Я»тря(ит, 1979. А1Ьгссзп Л./. апй Са((псу ). Е. БоГпчаге бтптюп, !!пеь оГ сос1е апй йсче!орптспс с!Гак рге- й!сг!оп: а зойшагс ьоспсе чйи!айоп // !ЕЕЕ Ттати. ел 5е/!шаге Еттбтнееллб — 1983. — БЕ-9 (6), — Р. 639-686. А1ехапйсг С., 1ьМЬава Б. ае аг А Раиетл Еаттдиабл — ОхГоп1: ОхГоп1 Нп!чеп!гу Ргем, 1977. А1Гоп1 М.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
