Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Унифицированный процесс: управляемый варианта....docx
Скачиваний:
4
Добавлен:
03.11.2018
Размер:
401.68 Кб
Скачать
    1. Необходимость вариантов использования

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

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

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

    1. Определение вариантов использования

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

    1. Анализ, проектирование и разработка при реализации варианта использования

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

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

Модель анализа последовательно разрастается по мере анализа все новых и новых вариантов использования. На каждой итерации мы выбираем варианты использования, которые будем включать в модель анализа. Мы строим систему в виде структуры, состоящей из классификаторов (классов анализа) и отношений между ними. Мы также описываем кооперации, реализующие варианты использования, то есть реализации вариантов использования. На следующей итерации мы выбираем для проработки следующие варианты использования и добавляем их к результатам предыдущей итерации. В подразделах «Итеративный подход —управляемый рисками» и «Расстановка приоритетов вариантов использования» мы рассматриваем, как на первых итерациях идентифицировать и выбрать «важнейшие» варианты использования, чтобы построить стабильную архитектуру на ранних стадиях жизненного цикла системы.

Работа обычно выполняется так: сначала идентифицируются и описываются варианты использования текущей итерации, затем в соответствии с описанием для каждого варианта использования предлагаются классификаторы и ассоциации, необходимые для реализации этого варианта использования. Мы проделываем эту работу для всех вариантов использования текущей итерации. В зависимости от того, в какой точке жизненного цикла мы находимся и с какой итерацией работаем, архитектура может уже быть определена, тогда она поможет нам обнаруживать новые классификаторы и повторно использовать существующие. Каждый классификатор играет в реализации варианта использования одну или несколько ролей. Каждая роль классификатора определяет обязанности, атрибуты и другие характеристики, которыми классификатор будет обладать в реализации варианта использования. Мы можем считать эти роли зародышами классификаторов. В UML роль является классификатором сама по себе. Например, мы можем думать о роли класса как о представлении этого класса. Таким образом, она включает содержимое этого класса, то есть обязанности, атрибуты и другие характеристики, но только те, которые имеют отношение к его роли в реализации варианта использования. Другой способ описать роль класса состоит в том, чтобы рассматривать ее как то, что остается от класса после наложения на него фильтра, отсекающего все то, что относится к другим ролям класса, за исключением совместно выполняемых обязанностей. Такой подход к роли кратко описан в этой главе. Для упрощения понимания материала во второй части этой книги, где классификаторы обсуждаются подробнее, этот подход не используется.