Технологии разработки программного обеспечения

Этап РАЗВИТИЕ (Elaboration)


Главное назначение этапа — создать архитектурный базис системы.

Цели этапа РАЗВИТИЕ:

q       определить оставшиеся требования, функциональные требования формулировать как элементы Use Case;

q       определить архитектурную платформу системы;

q       отслеживать риск, устранить источники наибольшего риска;

q       разработать план итераций этапа КОНСТРУИРОВАНИЕ.

Основные действия этапа РАЗВИТИЕ:

q       развитие спецификации представления, полное формирование критических элементов Use Case, задающих дальнейшие решения;

q       развитие архитектуры, выделение ее компонентов.

В итоге этапа РАЗВИТИЕ создаются следующие артефакты:

q       модель Use Case (80% от полного представления);

q       дополнительные требования (нефункциональные требования, а также другие требования, которые не связаны с конкретным элементом Use Case);

q       описание программной архитектуры;



q       выполняемый архитектурный макет;

q       пересмотренный список элементов риска и пересмотренный бизнес-вариант;

q       план разработки для всего проекта, включающий крупноблочный проектный план и показывающий итерации и критерий эволюции для каждой итерации.

Обсудим более подробно главную цель этапа РАЗВИТИЕ — создание архитектурного базиса.

Архитектура объектно-ориентированной системы многомерна — она описывается множеством параллельных представлений. Как показано на рис. 15.4, обычно используется «4+1»-представление [44].

Рис. 15.4. «4+1»-представление архитектуры

Представление Use Case описывает систему как множество взаимодействий с точки зрения внешних актеров. Это представление создается на этапе НАЧАЛО жизненного цикла и управляет оставшейся частью процесса разработки.


Логическое представление содержит набор пакетов, классов и отношений. Изначально создается на этапе развития и усовершенствуется на этапе конструирования.

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

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

Представление размещения содержит физические узлы системы и соединения между узлами. Создается на этапе развития.

В качестве примера рассмотрим порядок создания логического представления архитектуры. Для решения этой задачи исследуются элементы Use Case, разработанные на этапе НАЧАЛО. Рассматриваются экземпляры элементов Use Case — сценарии. Каждый сценарий преобразуется в диаграмму последовательности. Далее в диаграммах последовательности выделяются объекты. Объекты группируются в классы. Классы могут группироваться в пакеты.

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

В качестве другого примера рассмотрим разработку плана итераций для этапа КОНСТРУИРОВАНИЕ. Такой план должен задавать управляемую серию архитектурных реализаций, каждая из которых увеличивает свои функциональные возможности, а конечная — покрывает все требования к полной системе. Главным источником информации являются элементы Use Case и диаграммы последовательности. Будем называть их обобщенно — сценариями. Сценарии группируются так, чтобы обеспечивать реализацию определенной функциональности системы. Кроме того, группировки должны устранять наибольший (в данный момент) риск в проекте.



План итераций включает в себя следующие шаги:

1.      Определяются все элементы риска в проекте. Устанавливаются их приоритеты.

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

3.      В результате анализа сценариев формируются классы и отношения, которые их реализуют.

4.      Программируются сформированные классы и отношения.

5.      Разрабатываются тестовые варианты.

6.      Тестируются классы и отношения. Цель — проверить выполнение функционального назначения сценария.

7.      Результаты объединяются с результатами предыдущих итераций, проводится тестирование интеграции.

8.      Оценивается итерация. Выделяется необходимая повторная работа. Она назначается на будущую итерацию.

 


Содержание раздела