Об унифицированном процессе и языке моделирования

В данном разделе использованы материалы из книг:

Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. – СПб.: Питер, 2002. – 496с.;

Скотт К. UML. Основные концепции. – М.: Издательский дом «Вильямс», 2002. -144 с.

Общие сведения.

Унифицированный процесс (УП), предназначенный для получения ПО, представляет собой сумму различных видов деятельности, необходимых для преобразования требований пользователей в программную систему (см. рис. ниже).

Рис. Процесс разработки ПО.

УП – это обобщенный каркас процесса, который может быть специализирован для:

1) широкого круга программных систем,

2) различных областей применения,

3) размеров проекта

УП компонентно-ориентирован, т.е. создаваемая программная система строится на основе программных компонентов, связанных хорошо определенными интерфейсами.

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

1) управляемый вариантами использования;

2) архитектурно-ориентированный;

3) итеративный и инкрементный.

Краткие пояснения.

УП управляется вариантами использования

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

Всю полноту функциональности системы описывает модель вариантов использования, состоящая из совокупности всех вариантов использования, заменяя традиционное описание функций системы. Утверждение -Управляемый вариантами использования - означает, что процесс разработки проходит серию рабочих процессов, порожденных вариантами использования.

Так как варианты использования управляют процессом разработки, то они не выделяются изолировано, а разрабатываются в паре с архитектурой системы. Причем варианты использования управляют архитектурой системы, а архитектура системы оказывает влияние на выбор вариантов использования.

УП ориентирован на архитектуру

Понятие архитектуры программы включает в себя наиболее важные аспекты системы. Архитектура программной системы описывается различными представлениями будущей системы.

Архитектура вырастает из требований к результату пользователей и других заинтересованных лиц, которые отражаются в вариантах использования. Однако на требования также влияют такие факторы, как:

1) выбор платформы для работы программы (т.е. компьютерной архитектуры, ОС, СУБД, сетевых протоколов);

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

3) и т.д.

Архитектура – это представление всего проекта с выделением важных характеристик.

Связь архитектуры с вариантами использования в ПО представляет собой единство функций, соответствующих вариантам использования, и формы – архитектуры.

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

На первом этапе создает приблизительная архитектура, которая не связана с вариантами использования (так называемая платформа).

Затем ведется работа с подмножеством выделенных вариантов использования, каждый из которых соответствует одной из ключевых функций разрабатываемой системы, и уточняется архитектура системы.

Окончанием этапа создания архитектуры является момент, когда варианты использования описаны и полностью разработаны. Уточненная архитектура в свою очередь будет базой для полной разработки других вариантов использования.

УП является итеративным и инкрементным

Для экономии времени разработки проекта и правильного распределения работы между исполнителями предлагается разделить проект на отдельные мини-проекты.

Каждый мини-проект является итерацией, результатом которой будет приращение (инкремент).

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

1) требования,

2) варианты использования,

3) нефункциональные требования,

4) варианты тестирования.

Полное представление готового продукта состоит из:

м одели вариантов использования, содержащей все варианты использования и их связи с пользователями;

м одели анализа, уточняющей детали вариантов использования и создающей первичное распределение поведения системы по набору объектов;

модели проектирования, определяющей статическую структуру системы, такую как подсистемы, классы, интерфейсы, и варианты использования, реализованные в виде коопераций между подсистемами, классами и интерфейсами;

модели реализации, включающей в себя компоненты (представленные исходным кодом) и распределения классов по компонентам;

модели развертывания, представляющей физические компьютеры (узлы сети) и распределение компонентов по этим узлам;

модели тестирования, описывающей тесты для проверки вариантов использования;

представления архитектуры.

Полное представление готового продукта позволяет эффективно выполнить новый цикл разработки программного продукта.

Система также может включать в себя модель предметной области или бизнес-модель, описывающую контекст системы.

Все эти модели связаны. Вместе они полностью описывают систему.