Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 61
Текст из файла (страница 61)
Эти характеристики используютсяпри уточнении цели очередного релиза.Показатель изменчивости архитектурного интерфейса или тактическихпринципов является основной характеристикой стабильности архитектуры[30]. Локальные изменения вероятны в течение всего процесса эволюции, ноесли структуры наследования или границы между категориями классов илиподсистем постоянно перестраиваются, то это признак нерешенных проблем вархитектуре, что должно быть учтено как область риска при планированииследующего релиза.СопровождениеЦель. Сопровождение - это деятельность по управлению эволюциейпродукта в ходе его эксплуатации.
Она в значительной степени продолжаетпредыдущие фазы, за исключением того, что вносит меньше архитектурныхновшеств. Вместо этого делаются более локализованные изменения,возникающие по мере учета новых требований и исправления старых ошибок.Леман и Белади сделали несколько неоспоримых наблюдений,рассматривая процесс "созревания" уже внедренной программной системы:•"Эксплуатируемая программа должна непрерывно изменяться; впротивном случае она будет становиться все менее и менееполезной (закон непрерывного изменения).•Когда эволюционирующая программа изменяется, ее структурастановится более сложной, если не прилагаются активные усилия,чтобы этого избежать (закон возрастающей сложности)" [З].Мы отличаем понятие сохранения системы программного обеспеченияот ее сопровождения.
При сопровождении разработчики вносят непрерывныеусовершенствования в существующую систему; сопровождением обычнозанимается другая группа людей, отличная от группы разработчиков.Сохранение же основано на привлечении дополнительных ресурсов дляподдержания устаревшей системы (которая часто имеет плохо разработаннуюархитектуру и, следовательно, трудна для понимания и модификации).
Итак,нужно принять деловое решение: если цена владения программнымпродуктом выше, чем цена разработки новой системы, то наиболее гуманныйобраз действий - оставить старую систему в покое или покончить с ней.Результаты. Поскольку сопровождение является в определенномсмысле продолжением эволюции системы, ее результаты похожи на то, чегомы добивались на предыдущих этапах. В дополнение к ним, сопровождениесвязано также с управлением списком новых заданий. Кроме тех требований,которые по каким-либо причинам не были учтены, вероятно, уже вскоре послевыпуска работающей системы, разработчики и конечные пользователиобменяются множеством пожеланий и предложений, которые они хотели быувидеть воплощенными в следующих версиях системы. Заметим, что когда ссистемой поработает больше пользователей, выявятся новые ошибки инеожиданные методы использования, которых не смогли предвидетьконтролеры качества.28 В список заносятся обнаруженные дефекты и новыетребования, которые будут учтены при планировании новых релизов всоответствии с их приоритетом.Виды деятельности.
Сопровождение несколько отличается отэволюции системы. Если первоначальная архитектура удалась, добавлениеновых функций и изменение существующего поведения происходятестественным образом.Кроме обычных действий по эволюции, при сопровождении нужноопределить приоритеты задач, собранных в список замечаний и предложений.Типичный порядок действий таков:•Упорядочить по приоритетам предложения о крупных изменениях исообщения об ошибках, связанных с системными проблемами, иоценить стоимость переработки.•Составить список этих изменений и принять их за функциональныеточки в дальнейшей эволюции.•Если позволяют ресурсы, запланировать в следующем релизе менееинтенсивные, более локализованные улучшения.•Приступить к разработке следующего эволюционного релизапрограммы.Путевые вехи и характеристики.
Путевыми вехами сопровожденияявляются продолжающееся производство эволюционирующих релизов иустранение ошибок.Мы считаем, что занимаемся именно сопровождением системы, еслиархитектура выдерживает изменения; мы определим, что вошли в стадиюсохранения, когда количество ресурсов, требуемых для достижения нужногоулучшения, начнет резко нарастать.28Пользователи проявляют чудеса изобретательности в использовании системысамым необычным образом.Выводы•Удачные проекты обычно характеризуются ясным представлением обархитектуре и хорошо управляемым итеративным жизненнымциклом.•Идеально рациональный процесс проектирования невозможен, но егоможно имитировать, сочетая микро- и макропроцесс разработки.•Микропроцесс объектно-ориентированной разработки приводится вдвижение потоком сценариев и продуктов архитектурного анализа(макропроцесс); микропроцесс представляет ежедневнуюдеятельность команды разработчиков.•Первый шаг в микропроцессе связан с идентификацией классов иобъектов на данном уровне абстракции; основными видамидеятельности являются открытие и изобретение.•Второй шаг микропроцесса состоит в выявлении семантики классов иобъектов; основными видами деятельности здесь являютсяраскадровка сценариев, проектирование изолированных классов ипоиск шаблонов.•Третий шаг микропроцесса - выявление связей между классами иобъектами; основными действиями являются спецификацияассоциаций, выявление взаимодействий и уточнение ассоциаций.•Четвертый шаг микропроцесса связан с реализацией классов иобъектов; основное действие - выбор структур данных иалгоритмов.•Макропроцесс объектно-ориентированной разработки управляетмикропроцессом, определяет измеримые характеристики проекта ипомогает контролировать риск.•Первый шаг макропроцесса - концептуализация, котораяустанавливает основные требования к системе; она служит дляопробования концепций и, по большей части, не должнаконтролироваться, чтобы предоставить неограниченную свободуфантазии.•Второй шаг макропроцесса - анализ.
Его цель - получить модельповедения системы. Основными действиями на этом этапеявляются анализ предметной области и планирование сценариев.•Третий шаг макропроцесса - проектирование. На этом шаге создаетсяархитектура реализации и вырабатываются единые тактическиеприемы; основными действиями являются архитектурноепланирование, тактическое проектирование и планированиерелизов.•Четвертый шаг макропроцесса - эволюция, последовательноприближающая систему к желаемому результату. Основныедействия - применение микропроцесса и управление изменениями.•Пятый шаг макропроцесса - сопровождение, то есть управлениеэволюцией системы в ходе ее эксплуатации; основные действияпохожи на действия предыдущего шага, но к ним добавляетсяработа со списком улучшений и исправлений.Дополнительная литератураРанняя форма процесса, описанного в этой главе, была впервыеопубликована Бучем (Booch) [F 1982].
Берард (Berard) позднее развил этуработу в статье [F 1986]. Среди родственных подходов можно назвать GOOD(General Object-Oriented Design) Сейдвица и Старка (Seidewitz and Stark) [F1985,1986,1987], SOOD (Structured Object-oriented Design) корпорация Локхид(Lockheed) [С 1988], MOOD (Multipleview Object-oriented Design) Керта (Kerth)[F 1988], и HOOD (Hierarchical Object-oriented Design), предложенный CISIIngenierie и Matra для европейской космической станции [F 1987]. Болеесвежие ссылки: Страуструп (Stroustrup) [G 1991] и Microsoft [G 1992], гдепредложены сходные процессы.В дополнение к работам, упомянутым в дополнительной литературе кглаве 2, ряд других методологов предложил специфические процессыобъектно-ориентированного развития.
На эти работы есть многобиблиографических ссылок. Вот наиболее интересные из них: Алабио(Alabios) [F 1988], Бойд (Boyd) [F 1987], Бур (Buhr) [F 1984], Черри (Cherry) [F1987,1990], деШампо (deChampeaux) [F 1992], Фелсингер (Felsinger) [F 1987],Файерсмит (Firesmith) [F 1986,1993], Хайнс и Юнгер (Hines and Unger) [G1986], Дже-кобсон (Jacobson) [F 1985], Джамса (Jamsa) [F 1984], Кади (Kadie)[F 1986], Мазиеро и Германо (Masiero and Germano) [F 1988], Ниелсен(Nielsen) [F 1988], Ниес (Nies) [F 1986], Рэйлич и Сильва (Railich and Silva) [F1987], Грэхем (Graham) [F 1987].Сравнение различных процессов объектно-ориентированного развитияможно найти в работах Арнольда (Arnold) [F 1991], Боем-Дэвиса и Росса(Boehm-Davis and Ross) [H 1984], деШампо (deChampeaux) [В 1991], Криббса,Муна и Ро (Cribbs, Moon, and Roe) [F 1992], Фоулер (Fowler) [F 1992], Келли(Kelly) [F 1986], Манино (Mannino) [F 1987], Сонга (Song) [F 1992], Вебстера(Webster) [F 1988].
Брукман (Brookman) [F 1991] и Фичмэн (Fichman) [F 1992]сравнили структурные и объектно-ориентированные методы.Эмпирические исследования процессов создания программногообеспечения можно найти в работе Кертис (Curtis) [H 1992], а также в трудахSoftware Process Workshop [H 1988]. Еще одно интересное исследованиепринадлежит Гвиндону (Guindon) [H 1987], изучавшему процессы, которыеразработчики использовали раньше.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
