- •Оглавление
- •Унифицированный процесс: управляемый вариантами использования, архитектурно- ориентированный, итеративный и инкрементный
- •Введение
- •Унифицированный процесс в двух словах
- •Унифицированный процесс управляется вариантами использования
- •Унифицированный процесс ориентирован на архитектуру
- •Унифицированный процесс является интеративным и инкрементным
- •Жизненный цикл Унифицированного процесса
- •Продукт
- •Разделение цикла на фазы
- •Интегрированный процесс
- •Процесс, направляемый вариантами использования
- •Введение в разработку управляемую вариантами использования
- •Необходимость вариантов использования
- •Определение вариантов использования
- •Анализ, проектирование и разработка при реализации варианта использования
- •Создание по вариантам использования аналитической модели
- •Тестирование вариантов использования
- •Архитектурно-центрированный процесс
- •Введение в архитектуру
- •Необходимость архитектуры
- •Варианты использования и архитектура
- •Описание архитектуры
- •Интеративный и инкрементный процесс
- •Введение в итеративность и инкрементность
- •Необходимость использования итеративной и инкрементной разработки
- •Итеративный подход управляемый рисками
- •Обобщенная итерация
- •Заключение
- •Список использованной литературы
-
Необходимость вариантов использования
Существует несколько объяснений удобства, популярности и повсеместного применения вариантов использования. Две основные причины таковы:
-
Варианты использования дают систематический и интуитивно понятный способ определения функциональных требований, ориентированный на получение необходимых пользователю результатов.
-
Варианты использования управляют всем процессом разработки. Все основные виды деятельности — анализ, проектирование и тестирование — выполняются на основе определенных вариантов использования. Проектирование и тестирование к тому же планируются и координируются в понятиях вариантов использования. Это особенно хорошо видно после выполнения первых итераций, когда архитектура системы стабилизируется.
-
Определение вариантов использования
В ходе рабочего процесса определения требований мы идентифицируем потребности пользователей и клиентов в виде требований. Функциональные требования описываются вариантами использования, входящими в модель вариантов использования. Прочие же требования могут присоединяться к тем вариантам использования, к которым они относятся, сохраняться в отдельном списке или фиксироваться каким-либо иным образом.
-
Анализ, проектирование и разработка при реализации варианта использования
В ходе анализа и проектирования мы преобразуем модель вариантов использования через модель анализа в модель проектирования, то есть в структуру, состоящую из классификаторов и реализаций вариантов использования. Цель состоит в том, чтобы реализовать варианты использования так, чтобы система имела в результате устраивающую нас эффективность и перспективы развития, не выходя при этом за рамки бюджета.
-
Создание по вариантам использования аналитической модели
Модель анализа последовательно разрастается по мере анализа все новых и новых вариантов использования. На каждой итерации мы выбираем варианты использования, которые будем включать в модель анализа. Мы строим систему в виде структуры, состоящей из классификаторов (классов анализа) и отношений между ними. Мы также описываем кооперации, реализующие варианты использования, то есть реализации вариантов использования. На следующей итерации мы выбираем для проработки следующие варианты использования и добавляем их к результатам предыдущей итерации. В подразделах «Итеративный подход —управляемый рисками» и «Расстановка приоритетов вариантов использования» мы рассматриваем, как на первых итерациях идентифицировать и выбрать «важнейшие» варианты использования, чтобы построить стабильную архитектуру на ранних стадиях жизненного цикла системы.
Работа обычно выполняется так: сначала идентифицируются и описываются варианты использования текущей итерации, затем в соответствии с описанием для каждого варианта использования предлагаются классификаторы и ассоциации, необходимые для реализации этого варианта использования. Мы проделываем эту работу для всех вариантов использования текущей итерации. В зависимости от того, в какой точке жизненного цикла мы находимся и с какой итерацией работаем, архитектура может уже быть определена, тогда она поможет нам обнаруживать новые классификаторы и повторно использовать существующие. Каждый классификатор играет в реализации варианта использования одну или несколько ролей. Каждая роль классификатора определяет обязанности, атрибуты и другие характеристики, которыми классификатор будет обладать в реализации варианта использования. Мы можем считать эти роли зародышами классификаторов. В UML роль является классификатором сама по себе. Например, мы можем думать о роли класса как о представлении этого класса. Таким образом, она включает содержимое этого класса, то есть обязанности, атрибуты и другие характеристики, но только те, которые имеют отношение к его роли в реализации варианта использования. Другой способ описать роль класса состоит в том, чтобы рассматривать ее как то, что остается от класса после наложения на него фильтра, отсекающего все то, что относится к другим ролям класса, за исключением совместно выполняемых обязанностей. Такой подход к роли кратко описан в этой главе. Для упрощения понимания материала во второй части этой книги, где классификаторы обсуждаются подробнее, этот подход не используется.
