9.Макропроцесс проектирования. Концептуализация. Анализ. Проектирование. Эволюция. Сопровождение. Универсальная система обработки функционального описания.Макропроцесс проектирования

Макропроцесс является контролирующим по отношению к микропроцессу. Макропроцесс предписывает ряд измеримых результатов и действий, которые позволяют команде разработчиков оценить риск, внести заблаговременные изменения в микропроцесс и сосредоточиться на коллективном анализе и проектировании. Макропроцесс - это деятельность всего коллектива в масштабе от недель до месяцев. Макропроцесс включает в себя следующие действия:

-Выявление сущности требований к программному продукту (концептуализация). -Разработка модели требуемого поведения системы (анализ).

-Создание архитектуры для реализации (проектирование). -Итеративное выполнение реализации (эволюция). -Управление эволюцией продукта в ходе эксплуатации (сопровождение). Концептуализация Цель: Концептуализация должна установить основные требования к системе.Результаты.Первичными продуктами концептуализации являются прототипы системы. Концептуализация - творческая деятельность, она не должна быть скована жесткими правилами разработки.Самое важнее для организации - создать структуру, которая обеспечивала бы достаточные ресурсы для возникновения и исследования новых идей.

Для руководства важно вести регистрацию этих идей, располагая их по приоритетами распределяя ограниченные ресурсы.Когда для исследования выбрано конкретное направление, типичен следующий порядок дальнейших действий: Необходимо решить, какие цели преследуются при опробовании концепции и каковы критерии того,что считать благополучным исходом.

Сбор подходящей команды для разработки прототипа. Часто она состоит из единственного члена (который и есть тот самый мечтатель). Оценить готовый прототип и принять ясное решение о проектировании конечного продукта или о дальнейшем исследовании.

Довольно часто концепции опробуются на одном языке (например, на Smalltalk),а разработка конечного продукта ведется на другом скажем,С++).

Важно, чтобы для оценки прототипа были установлены четкие критерии. Работу над прототипом чаще планируют по срокам, чем по требованиям.

Анализ.Цель - дать описание задачи (представить модель поведения системы).Результаты:- описание назначения системы, сопровождаемое характеристиками производительности и перечислением требуемых ресурсов. В обьектно-ориентированном проекгировании такие описания получаются с помощью сценариев.

Для более точной иллюстрации семантики каждого сценария применяются диаграммы объектов. Они демонстрируют взаимодействие обьектов, обеспечивающее выполнение функций системы, и упорядоченный процесс этоговзаимодействия, состоящий в посылке объектами сообщений друг другу.Кроме диаграмм объектов, врассмотрение можно включить диаграммы классов (чтобы показать существующие ассоциации между классами объектов) и состояний (чтобы показать жизненный цикл важнейших объектов).Часто эти результаты анализа объединяют в один формальный документ.Побочным результатом анализа будет оценка риска. Обнаружение имеющегося риска в начале процесса проектирования облегчит возможные архитектурные компромиссы на поздних этапах разработки.

С анализом связаны два основных вида деятельности: анализ предметной области и планирование сценариев. Порядок действий (планирование сценариев):Идентификация основных функциональных точек системы и, если возможно, группировка функционально связанных видов поведения.Для каждого представляющего интерес набора функциональных точек необходимо сделать раскадровку сценария. Кроме того, необходимо перечислить все предположения, ограничения и показатели эффективности для каждого сценария.

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

и выработать единые тактические приемы,которыми должны пользоваться различные элементы системы.Процесс проектирования начинается сразу после появления некоторой приемлемой модели поведения системы. Важно не начинать проектирование до завершения анализа.

Результаты проектирования.Имеется два основных результата проектирования: описание архитектуры и выработка общих тактических приемов.

Можно описывать архитектуру путем построения диаграмм или создавая последовательные архитектурные релизы системы.Для описания архитектуры важно наглядно продемонстрировать группирование классов в категории классов (для логической архитектуры) и группирование модулей в подсистемы (для физической архитектуры).Используются архитектурные релизы системы как осязаемые демонстрации строения архитектуры. Архитектурный релиз представляет собой как бы вертикальный разрез архитектуры, передающий важнейшую (но не полную)семантику существенных категорий и подсистем.Архитектурный релиз системы должен быть работающей программой, что позволяет измерять, изучать и оценивать архитектуру.Общие тактические приемы -это локализованные механизмы, которые проявляются всюду в системе. К ним относятся такие аспекты проектирования, как:

-принципы обнаружения и обработки ошибок

-управление памятью

-хранение и представлениеданных

-подходы к управлению.

С проектированием связано три действия: архитектурное планирование, тактическое проектирование и планирование релизов.При архитектурном планировании мы занимаемся вертикальным и горизонтальным расчленением системы.Оно охватывает логическую декомпозицию, состоящую в группировании классов, и физическую декомпозицию, состоящую в разбиении на модули и назначении заданий процессорам. Порядок действий: Необходимо рассмотреть группирование функциональных точек (наиденных в анализе) и распределить их по слоям и разделам архитектуры.Проверка архитектуры созданием действующих релизов, которые частично удовлетворяют семантике нескольких важнейших сценариев, предоставленных анализом.Оценка достоинств и недостатков архитектуры. Определение риска изменения каждого ключевого архитектурного интерфейса (чтобы можно было заранее распределить ресурсы при эволюции системы).Архитектурное планирование сконцентрировано на том,чтобы создать в самом начале жизненного цикла каркас системы, а потом постепенно развивать его. Тактическое проектирование состоит в принятии решений о множестве общих приемов. Плохое тактическое проектирование может разрушить даже очень продуманную архитектуру.Программные релизы закладывают основы архитектурной эволюции системы.Эволюция.Цель- наращивать и изменять реализацию, последовательно совершенствуя ее, чтобы в конечном счете создать готовую систему.Эволюция архитектуры в значительной степени состоит в попытке удовлетворить нескольким взаимоисключающим требованиям ко времени,памяти и т.д. Результаты.Основным результатом эволюции является серия исполнимых релизов, представляющих итеративные усовершенствования изначальной архитектурной модели.Вторичным продуктом следует признать выявление поведения, которое используется для исследования альтернативных подходов и дальнейшего анализа темных углов системы.Действующие релизы выпускаются по графику, намеченному в начале планирования.

Для более сложных проектов, требующих больше усилий разработчиков, можно выпускать релиз каждые шесть месяцев и реже.Подразумевается, что документация системы зволюционирует вместе с архитектурными релизами.Эволюция связана с двумя видами деятельности: микропроцесс и управление изменениями.Работа, выполняемая между релизами, представляет процесс разработки в сжатом виде (это и есть один цикл микропроцесса). Порядок действий:Определение функциональных точек, которые попадут новый релиз, и области наивысшего риска (особенно те,которые были выявлены еще при эволюции предыдущего релиза).Распределение задач по релизам среди членов команды. Необходимо начать новый микропроцесс.Когда потребуется понять семантику требуемого поведения системы, необходимо поручить разработчикам сделать прототип поведения. Четко установить назначение каждого прототипа и определить критерии готовности.После завершения необходимо решить, как включить результаты прототипирования в,этот или последующие релизы.

Завершение микропроцесса интеграцией и очередным действующим релизом.При эволюции системы на практике ожидаются следующие типы изменений: Добавление нового класса или нового взаимодействия между классами. Изменение реализации класса.Изменение представления класса. Реорганизация структуры классов.Изменение интерфейса класса.Две других основных меры качества - скорость обнаружения ошибок и показатель изменчивости ключевых архитектурных интерфейсов и тактических принципов.

Сопровождение Цель:Сопровождение - это деятельность по управлению эволюцией продукта в ходе его эксплуатации.Она в значительной степени продолжает предыдущие фазы, за исключением того,что вносит меньше архитектурных новшеств.Вместо этого делаются более локализованные изменения, возникающие по мере учета новых требований и исправления старых ошибок. Леман и Белади сделали несколько неоспоримых наблюдений:

Эксплуатируемая программа должна непрерывно изменяться; в противном случае она будет становиться все менее и менее полезной (закон непрерывного изменения.Когда эволюционирующая программа изменяется, ее структура становится более сложной, если не прилагаются активные усилия, чтобы этого избежать (закон возрастающей сложности). Нужно различать понятие сохранения системы программного обеспечения от ее сопровождения.При сопровождении разработчики вносят непрерывные усовершенствования в существующую систему; сопровождением обычно занимается другая группа людей, отличная от группы разработчиков.Сохранение же основано на привлечении дополнительных ресурсов для поддержания устаревшей системы Сопровождение несколько отличается от эволюции системы.Если первоначальная архитектура удалась, добавление новых функций изменение существующего поведения происходят естественным образом.

Порядок действий:Упорядочение по приоритетам предложений о крупных изменениях и сообщений об ошибках, связанных с системными проблемами, и оценка стоимости переработки. Составление списка этих изменений (необходимо принять их за функциональные точки в дальнейшей эволюции).Если позволяют ресурсы, нужно запланировать в следующем релизе менее интенсивные, более локализованные улучшения.Необходимо начать разработку следующего зволюционного релиза программы.