Использование моделей UML в процессе разработки программных систем

Введение

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

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

Для создания моделей используются диаграммы в нотации Unified Modeling Language (UML).

Модели могут быть связаны между собой. В UML такая связь называется трассировкой. Подробнее о UML моделях в RUP читайте здесь.

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

Процесс разработки согласно Rational Unified Process представляет собой совокупность следующих базовых рабочих процессов:

• Определение требований;

• Анализ;

• Проектирование;

• Реализация;

• Тестирование.

Определение требований

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

Процесс определения требований включает создание следующих моделей:

• Модели вариантов использования;

• Концептуальной модели.

Основной в этом случае является модель вариантов использования, которая предназначена для определения требований к системе. Она включает в себя актантов, варианты использования и связи между ними. Для отображения этой модели язык UML предлагает использовать диаграммы Use Case (вариант использования) совместно с моделями State Diagram (диаграммы состояний). Последние используются для конкретизации вариантов использования системы.

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

Анализ

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

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

Таблица 1 Сравнение модели вариантов использования и аналитической модели

Модель вариантов использования	Аналитическая модель
Использует язык заказчика	Использует язык разработчика
Внешний вид системы	Внутренний вид системы
Структурирована по вариантам использования. Описывает структуру внешнего вида	Структурирована по стереотипным классам и пакетам, описывает структуру внутреннего вида
Используется в первую очереди как соглашение меду заказчиком и разработчиками о том, что должна делать система, а чего не должна	Используется в первую очередь разработчиками, для того чтобы понять, как система должна быть оформлена, т. е. Спроектирована и разработана
Может содержать избыточность, несовместимые требования и т.п.	Не должна содержать избыточность, несовместимые требования  и т.п.
Определяет функциональность системы, в т.ч. зависящую от архитектуры	Описывает как функциональность реализуется в системе, включая функциональность, зависящую от архитектуры; дает наметки для проектирования
Определяет варианты использования	Определяет реализации вариантов использования, каждая из которых представляет собой анализ вариантов использования из модели вариантов использования

 Для отображения модели используется диаграмма классов с применением стереотипов «граничный класс», «класс управления», «класс сущности».

Для детализации взаимодействия между классами используется диаграмма Collaboration (кооперации) классов.

Проектирование

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

В процессе проектирования систем используются следующие модели:

• Модель проектирования;

• Модель развертывания.

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

Модель анализа	Модель проектирования
Концептуальная модель, так как она является абстракцией системы и не затрагивает вопросов реализации	Физическая модель, так как она является наброском реализации
Не зависит от проекта (подходит разным проектам)	Специфична для данной реализации
Три концептуальных стереотипа – «сущность», «управление» и «граница»	Любое число физических стереотипов в классах, зависит от языка реализации
Слабо формализована	Сильно формализована
Невелика	Значительна (примерно 5:1 с моделью анализа)
Мало уровней	Много уровней
Динамическая (но последовательности уделяется мало внимания)	Динамическая, больше внимания к последовательности
Набросок проекта системы, включая архитектуру	Описание проекта системы, включая архитектуру
Может не поддерживаться в течение всего жизненного цикла системы	Должна поддерживаться в течение всего жизненного цикла системы
Определяет структуру, которая будет использована при оформлении системы, включая создание классов проектирования	Оформляет систему, сохраняя насколько это возможно, структуру, определенную моделью анализа

Модель проектирования представляется диаграммами классов, диаграммами взаимодействия.

Модель развертывания – объектная модель, которая определяет физическое размещение системы, то есть то, каким образом функциональность системы распределена по вычислительным узлам.

Для создания этой модели используется диаграмма топологии (развертывания)

 

 

 

 

 

 

Реализация

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

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

Модель реализации представляется диаграммой компонентов.

Тестирование

В процессе тестирования проверяются созданные компоненты и версии системы на целостность и проводятся системные тесты. Возможно создание тестовых компонентов для автоматизации тестирования.

В процессе тестирования проверяются результаты реализации.

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

Подробнее о диаграммах UML в рабочих процессах RUP читайте здесь