Змеев О.А. Фаза проектирования. Часть 2

«Введение в Унифицированный
процесс разработки ПО».
Лекция № 11.
Тщательное планирование – ключ
к безопасному и быстрому путешествию.
Одиссей.
Фаза Проектирование (Elaboration ).
Девиз фазы: Необходимо разобраться, а как мы это будем
разрабатывать?
Мы тут!
Начало
Проектирование
Реализация
Тестирование
Контрольная точка.
Архитектуры ЖЦ.
Вспоминаем о целях фазы:
1. Более глубоко понять требования.
2. Спроектировать, реализовать и оттестировать базовый
уровень архитектуры.
3. Снизить существенные риски и дать более точную оценку
сроков и стоимости.
4. Уточнить процесс и установить среду разработки. У нас есть
полный набор результирующих артефактов первой фазы,
проработанных в необходимом объеме для данного проекта.
Фаза Проектирование (Elaboration ).
Девиз фазы: Необходимо разобраться, а как мы это будем
разрабатывать?
Цель № 1. Более глубоко понять требования:
Что есть:
1.
Приемлемая концепция.
2.
Спецификации для некоторых вариантов использования (1020 %)
3.
Остальные варианты использования в виде кратких описаний.
Что необходимо:
1.
Завершить описание большинства вариантов использования.
2.
Учесть особенности приложения, которое разрабатывается.
3.
Возможно, разработать прототип интерфейса пользователя.
4.
Дополнение и (или) структурирование модели вариантов
использования.
5.
Наполнение бизнес-модели.
Фаза Проектирование (Elaboration ).
Девиз фазы: Необходимо разобраться, а как мы это будем
разрабатывать?
Цель № 2. Спроектировать, реализовать и оттестировать базовый
уровень архитектуры:
Архитектура как некоторый набор принципиальных решений,
которые необходимо разработать:
1.
2.
3.
4.
5.
Выбор наиболее важных подсистем или компонентов
системы.
Определение их интерфейсов.
Принятие решения о разработке, повторному использованию
или покупке этих компонентов.
Описание того, каким образом эти компоненты будут
взаимодействовать друг с другом в ходе работы
разрабатываемой системы, проиллюстрированной
выполнением ряда ключевых функциональных сценариев.
Реализация и тестирование архитектурного прототипа с
целью оценить, а он работает?
Фаза Проектирование (Elaboration ).
Девиз фазы: Необходимо разобраться, а как мы это
будем разрабатывать?
Базовый уровень архитектуры –

это не только что-то существующее на бумаге или в голове.

это исполняемый эволюционный прототип, который можно
запустить, проверить и убедиться, что это то самое, что
соответствует нуждам проекта и будет надежным скелетом
для последующей реализации.
Исполняемый архитектурный прототип – это частичная реализация
системы, разработанная специально для того, чтобы
продемонстрировать, что совокупность принятых решений может
обеспечить ключевые функции системы.
Но более важно, при этом демонстрирует необходимые показатели в
смысле производительности, пропускной способности, мощности,
надежности и прочих способностей.
Создание базового уровня архитектуры позволяет на следующей фазе
Реализации разрабатывать систему, которая основывается на
прочном фундаменте.
Базовый уровень архитектуры разрабатывается как эволюционный
прототип, в нем стараются аккумулировать уже проверенные
свойства, и те, которые будут удовлетворять потребностям готовой
системы с большой вероятностью.
Будет реализован
весьма частично
Код, специфичный
для оборудования
или нужд клиента
Будет реализован
весьма частично
Процессы и другой
код приложения
Скорее всего уже
существует
Механизмы, службы
(например ORB,
QBE)
Аппаратноспецифичный код,
платформенноспецифичный код,
код общего
применения
Основа приложения
Либо уже существует,
либо будет
разработан, куплен
Главные
абстракции, классы
и т.л.
Инфраструктура
Будет разработан
Приложение
Фаза Проектирование (Elaboration ).
Фаза Проектирование (Elaboration ).
Девиз фазы: Необходимо разобраться, а как мы это
будем разрабатывать?
Архитектура: определение подсистем, ключевых компонентов и их
интерфейсов:
Вспоминаем, что было:

Потенциальная архитектура, которая по оценке на тот момент
времени позволяла реализовать систему с приемлемым
уровнем качества, за приемлемые сроки и разумную цену.

В некоторых исключительных случаях в рамках фазы начало
были реализованы некоторые элементы архитектуры.

К концу первой фазы у команды было достаточно грубое
представление о рисках, с которыми предстоит столкнуться,
мы не прорабатывали тщательно вопросы, связанные с
использованием и приобретением технологий, повторного
использования архитектурных каркасов, программных
пакетов и т.д.

Большинство из этих проблем были только зафиксированы,
либо ответы на эти проблемы были приблизительными.
Фаза Проектирование (Elaboration ).
Девиз фазы: Необходимо разобраться, а как мы это
будем разрабатывать?
Архитектура: определение подсистем, ключевых компонентов и их
интерфейсов:
Чего делаем:

На ранних итерациях фазы Проектирования стоит достаточно
хорошо понять, какую систему команда разрабатывает.

Не надо изобретать велосипед: вместо того, чтобы с места в
карьер придумывать архитектуру, стоит рассмотреть вопрос о
повторном использовании либо на уровне покупного
архитектурного каркаса, либо на уровне архитектуры
предыдущих разработок команды.

Если такой возможности нет, то нужно попытаться определить
главные структурные элементы системы, то есть подсистемы
и основные компоненты.

Искать их можно на базе основных абстракций, которые
зафиксированы в модели предметной области. Для каждой
выявленной таким образом подсистемы или компонента
зафиксируйте ключевые возможности, которые этот элемент
должен обеспечивать, таким образом определяются
начальные наброски интерфейсов подсистем и компонентов.
Фаза Проектирование (Elaboration ).
Девиз фазы: Необходимо разобраться, а как мы это
будем разрабатывать?
Для разработки архитектуры используем АЗ ВИ:
Вспоминаем, что было:
В ходе первой фазы команда определяла критичные варианты
использования по трем направлениям:
1. Были определены варианты использования, которые получили
наиболее высокие оценки с точки зрения их привлекательности
для пользователей.
2. Попытались определить наиболее сложные, неизвестные или
рискованные элементы требований, которые, вполне возможно,
относятся к нефункциональной части требований.
3. Необходимо рассмотреть варианты использования, которые не
получили критического статуса, но позволяют охватить не раскрытую
часть системы.
Теперь необходимо убедиться, что предложенное решение позволяет
реализовать архитектурно-значимые варианты использования. Для
этого необходимо сделать очень простую вещь: спроектировать,
реализовать столько вариантов использования, сколько будет
нужно для того, чтобы уменьшить связанные с ними риски.
Варианты
использования
A
B
C
D
E
F
Приложение
Код, специфичный
для оборудования
или нужд клиента
Процессы и другой
код приложения
Аппаратноспецифичный код,
платформенноспецифичный код,
код общего
применения
Основа приложения
Механизмы, службы
(например ORB,
QBE)
Инфраструктура
Главные
абстракции, классы
и т.л.
Фаза Проектирование (Elaboration ).
Девиз фазы: Необходимо разобраться, а как мы это будем
разрабатывать?
Проектируем критичные варианты использования:
Определение: Представление варианта использования в рамках
модели проектирования называется реализацией варианта
использования.
Для документирования реализации используем – кооперации и
диаграммы взаимодействия.
Основные шаги:
1.
2.
3.
Создаем предварительную схему объектов модели анализа, которые
используются в рамках данной кооперации.
Выполняем высокоуровневое распределение обязанностей,
распределяя действия по классам модели анализа.
Подробно расписываем классы анализа и определяем область
ответственности для каждого класса. Проводим рецензирование
модели анализа для того, чтобы гарантировать, что обязанности
никаких двух классов не перекрываются, а взаимоотношения между
классами модели имеют смысл.
4.
Дорабатываем классы модели анализа до классов модели
проектирования. Чаще всего один класс модели анализа
соответствует нескольким классам модели проектирования.




5.
во-первых, выполнить это разбиение,
во-вторых, распределить обязанности класса анализа между
составляющими его классами проектирования.
После этого детализируем каждый класс модели проектирования,
добавляя в него атрибуты и операции.
Ррецензируем модель проектирования, чтобы убедиться, что классы
проектирования не дублируют функциональность друг друга, а
взаимоотношения между ними имеют смысл. .
Проектируем варианты использования. Другими словами
перерабатываем диаграммы взаимодействия, полученные на
этапе анализа варианта использования, в аналогичные, но
реализованные уже в рамках модели проектирования. Обратите
внимание, что такой способ декомпозиции варианта
использования на набор взаимодействующих элементов модели
проектирования можно использовать не только в объектноориентированных системах.