Проектирование информационных систем
Конспект лекций
назад | содержание | вперед

7. СОЗДАНИЕ МОДЕЛИ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

План:

  1. Функциональное моделирование в UML
  2. Правила построения модели вариантов использования
  3. Применение операций обобщения и конкретизации

Функциональное моделирование в UML

Функциональные требования к системе моделируются и документируются с помощью вариантов использования (use case), которые трактуются следующим образом:

- вариант использования фиксирует соглашение между участниками проекта относительно поведения системы;

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

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

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

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

- краткое изложение варианта использования (в один абзац) или основной поток событий (без анализа возможных ошибок);

- условия отказа (анализ мест возникновения возможных ошибок в основном потоке событий);

- обработка отказа (написание альтернативных потоков событий).

 

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

 

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

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

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

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

 

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

  1. регистратор — формирует учебный план и каталог курсов, записывает студентов на курсы, ведет все данные о курсах, профессорах, успеваемости и студентах;
  2. расчетная система - получает информацию по оплате курсов от данной системы.
  3. каталог курсов - база данных, содержащая информацию о курсах.

Исходя из потребностей действующих лиц, выделяются следующие варианты использования:

  1. Войти в систему.
  2. Зарегистрироваться на курсы.
  3. Просмотреть табель успеваемости.
  4. Выбрать курсы для преподавания.
  5. Проставить оценки.
  6. Вести информацию о профессорах.
  7. Вести информацию о студентах.
  8. Закрыть регистрацию.

В среде Rose диаграммы вариантов использования создаются в представлении вариантов использования. Главная диаграмма (Global View of Actors and Use Cases) предлагается no умолчанию. Затем для моделирования системы можно разработать столько дополнительных диаграмм, сколько необходимо.

Начальная версия диаграммы вариантов использования показана на рисунке 7.1.

Рисунок 7.1 – Исходная диаграмма вариантов использования

Применение операций обобщения и конкретизации

Согласно постановке задачи в состав пользователей системы следует ввести студентов и профессоров. При этом в описание действующих лиц и вариантов использования вносятся изменения. Модифицированная версия диаграммы вариантов использования показана на рис. 7.2. Поскольку вход в систему абсолютно одинаков для регистратора, студента и профессора, их поведение можно обобщить и ввести новое действующее лицо "Пользователь" (супертип) с общим вариантом использования "Войти в систему", подтипами которого являются Регистратор, Студент и Профессор.

Действующие лица:

  1. Студент — записывается на курсы и просматривает табель успеваемости.
  2. Профессор — выбирает курсы для преподавания и ставит оценки.
  3. Регистратор — формирует учебный план и каталог курсов, ведет все данные о курсах, профессорах и студентах.
  4. Расчетная система — получает от данной системы информацию по оплате за курсы.
  5. Каталог курсов — база данных, содержащая информацию о курсах.

Варианты использования:

  1. Войти в систему;
  2. Зарегистрироваться на курсы;
  3. Просмотреть табель успеваемости;
  4. Выбрать курсы для преподавания;
  5. Проставить оценки;
  6. Вести информацию о профессорах;
  7. Вести информацию о студентах;
  8. Закрыть регистрацию.

Рисунок  7.2 – Модифицированная диаграмма вариантов использования



Контрольные вопросы и упражнения

  1. В чем заключатся функциональное моделирование системы?
  2. Что такое вариант использования и что он отображает?
  3. Каковы преимущества диаграммы вариантов использования перед функциональной схемой?
  4. Перечислите основные отношения между двумя вариантами и между вариантом и актером?
  5. Возможны ли отношения между двумя действующими лицами на диаграмме вариантов использования?
  6. Перечислите основные правила построения диаграммы вариантов использования.
  7. Проведите моделирование вариантов использования для произвольного бизнес-процесса.



наверх



назад | содержание | вперед