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

  только снабжать информацией систему;

  только получать информацию из системы;

  снабжать информацией и получать информацию из системы.

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

1. Кто заинтересован в определенном системном требовании?

2. Какую роль система будет выполнять в организации?

3. Кто получит преимущества от использования системы?

4. Кто будет снабжать систему информацией, использовать информацию и получать информацию от системы?

5. Кто будет осуществлять поддержку и обслуживание системы?

6. Использует ли система внешние ресурсы?

7. Выступает ли какой-либо участник системы в нескольких ролях?

8. Выступают ли различные участники в одной роли?

9. Будет ли новая система взаимодействовать со старой?

В языке UML актер изображается в виде фигуры человечка — см. рис. 3.1.

Рис. 3.1. Нотация языка UМL для изображения актера

 

Определение «хорошего» актера

Необходимо внимательно подходить к вопросу определения актеров для системы. Такое определение обычно происходит итеративным образом — первый из утвержденных списков актеров часто далек от конечного. Например, является ли новый студент актером другого вида нежели студент, вернувшийся из академического отпуска? Допустим, вы сначала ответили утвердительно. Следующий шаг — выяснить, как актер взаимодействует с системой. Если новый студент использует систему не так, как вернувшийся студент, то это разные актеры. Если они используют систему одинаковым образом — это один и тот же актер.

Другой вариант — создание актера для каждой роли, исполняемой участником. Здесь тоже можно получить избыточность. Хороший пример — ассистенты преподавателей в системе регистрации курсов университета. Ассистенты тоже проводят занятия с группами студентов. Средства, требующиеся для выбора курсов, уже заложены в языке для актеров в роли студентов и актеров в роли преподавателей. Таким образом, нет необходимости в актерах, исполняющих роль ассистентов преподавателей.

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

 

Актеры в системе регистрации курсов университета

Перечислим ответы на ранее поставленные вопросы:

1. Студент хочет зарегистрироваться на курсы.

2. Преподаватель хочет выбрать курсы, которые он будет читать.

3. Регистратор должен создать учебный план и составить каталог на семестр.

4. Регистратор должен хранить информацию о курсах, преподавателях и студентах.

5. Система оплаты должна получать необходимую информацию из системы регистрации.

Основываясь на полученных ответах, можно выделить следующих актеров: студент (Student), преподаватель (Professor), регистратор (Register) и система оплаты (Billing system).

Алгоритм создания актеров в программе Rational Rose:

1. Щелкните правой кнопкой мыши по разделу Use Case View (Представление прецедентов) в окне браузера.

2. В появившемся контекстно-зависимом меню выберите команду New => Actor (Создать => Актер). В список окна браузера будет добавлен новый актер с именем New Class.

3. Выбрав новый пункт списка, введите нужное имя актера.

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

Рис. 3.2. Актеры

 

Описание актеров

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

Для системы регистрации курсов описание актеров может быть следующим:

  студент — человек, который регистрируется для посещения занятий в университете;

  преподаватель — человек, который читает лекции в университете;

  регистратор — человек, управляющий системой регистрации курсов;

  система оплаты — внешняя система, выполняющая функции расчетов за курсы.

Описание актеров в программе Rational Rose осуществляется при выполнении следующих действий:

1. Если окна описания нет на экране, откройте его, выбрав команду меню View => Documentation (Вид => Описание).

2. Из списка браузера выберите актера, щелкнув по нему мышью.

3. Установите курсор в окне описания и введите текст описания актера.

Пример описания актера студент показан на рис. 3.3.

Рис. 3.3. Описание актера студент

 

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

Чтобы выделить прецеденты для системы, можно использовать следующую серию вопросов:

1. Каковы задачи каждого актера?

2. Будет ли актер создавать, хранить, изменять, удалять или получать информацию из системы?

3. Какой прецедент будет создавать, хранить, изменять, удалять или получать эту информацию?

4. Должен ли актер информировать систему о внезапных изменениях внешней среды?

5. Должен ли актер быть проинформирован об изменениях состояния системы?

6. Какие прецеденты будут поддерживать и обслуживать систему?

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

В языке UML прецедент изображается в виде овала — см. рис. 3.4.

Рис. 3.4. Нотация языка UML для прецедента

 

Основа правильного прецедента

На протяжении многих лет велись дискуссии на тему правильности прецедентов. Одной из проблем, с которой я столкнулась, является уровень их детализации. Насколько мал или велик он должен быть? Здесь нет однозначного ответа. Я обычно использую следующее правило: «Прецедент обычно определяет основной элемент функциональности и совершается от начала до конца. Он должен приносить что-то значимое для актера».

Например: в системе регистрации учебных курсов студент должен выбрать курсы для наступающего семестра; студент должен быть прикреплен к предлагаемым курсам; студенту должен быть выставлен счет. Это три прецедента или только один? Я бы сделала один, потому что функциональность действия определяет происходящее от начала до конца. Что бы получилось, если студента не прикрепили бы к выбранным курсам (или, по крайней мере, не известили об этом)? Или что произошло бы, если студент не получил бы счет (университет наверняка бы разорился, если бы курсы стали бесплатными)?

Другая проблема в том, как объединить функциональность различных действий, которые кажутся едиными. Например, регистратор должен добавлять курсы, удалять и изменять их. Три прецедента или один? Здесь я опять сделала бы один — работа с учебным планом, потому что действия инициируется одним актером (регистратором) и выполняются над одной сущностью системы (расписанием).

 

Прецеденты в системе регистрации курсов университета

В системе должны обеспечиваться следующие потребности:

  актер студент использует систему для регистрации на курсы;

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

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

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

На основании перечисленных потребностей можно выделить следующие прецеденты:

  регистрация на курсы;

  выбор курсов для преподавания;

  запрос расписания курсов;

  управление информацией о курсах;

  управление информацией о преподавателях;

  управление информацией о студентах;

  создание каталога курсов.

Для создания прецедентов в программе Rational Rose выполните следующие действия:

1. Щелкните правой кнопкой мыши по разделу Use Case View (Представление прецедентов) в окне браузера.

2. В появившемся контекстно-зависимом меню выберите команду New => Use Case (Создать => Прецедент). В списке браузера появится новый прецедент.

3. Введите для него нужное название.

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

Рис. 3.5. Прецеденты

 

Краткое описание прецедентов

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

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

Рис. 3.6. Краткое описание прецедента

Этот прецедент инициируется студентом. Он обеспечивает возможность создавать, изменять, удалять и просматривать расписание студента в определенном семестре.

Для добавления краткого описания прецедента в программе Rational Rose:

1. В списке браузера выберите прецедент, щелкнув по нему мышью.

2. Установите курсор в окне описания и наберите краткое описание прецедента. Если окно невидимо, откройте его с помощью команды меню View => Documentation (Вид => Описание).

 

Поток событий для прецедента

Поток событий (flow of events) для прецедента — это последовательность событий, необходимых для обеспечения требуемого поведения. Поток событий описывается в терминах того, «что» система должна делать, а не «как» она должна это делать. То есть он описывается на языке предметной области, а не терминами реализации. Поток событий должен определять:

  когда и как прецедент начинается и заканчивается;

  как он взаимодействует с актером;

  какие данные ему нужны;

  нормальную последовательность событий для прецедента;

  описание потоков в альтернативных и исключительных ситуациях.

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

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

X. Поток событий для прецедента <имя>.

X.1. Предусловия.

X.2. Главный поток.

X.3. Под-потоки (если применимы).

X.4. Альтернативные потоки.

Здесь X — число от единицы до количества прецедентов.

Рассмотрим пример полного документа с описанием потока событий для прецедента выбор курсов для преподавания (Select Courses to Teach).

Поток событий для прецедента «выбор курсов для преподавания»

1.1. Предусловия

Под-поток создание учебных курсов (Create Course Offerings) прецедента управление информацией о курсах (Maintain Course Information) должен быть выполнен перед его началом.

1.2. Главный поток

Прецедент начинает выполняться, когда преподаватель подключается к системе регистрации и вводит свой пароль. Система проверяет правильность пароля (Е-1) и просит преподавателя выбрать текущий или будущий семестр (Е-2). Преподаватель вводит нужный семестр. Система предлагает выбрать требуемую операцию: добавить (Add), удалить (Delete), просмотреть (Review), напечатать (Print) или выйти (Quit).

Если выбрана операция добавить (Add), S-1: выполняется поток добавить учебный курс (Add a Course Offering).

Если выбрана операция удалить (Delete), S-2: выполняется поток удалить учебный курс (Delete a Course Offering).

Если выбрана операция просмотреть (Review), S-3: выполняется поток просмотреть расписание (Review Schedule).

Если выбрана операция напечатать (Print), S-4: выполняется поток напечатать расписание (Print Schedule).

Если выбрана операция выйти (Quit): прецедент завершается.

1.3. Под-потоки

S-1: добавить учебный курс (Add a Course Offering)

Система отображает диалоговое окно, содержащее поле для ввода названия и номера предмета. Преподаватель вводит название и номер предмета (Е-3). Система отображает список учебных курсов для указанного предмета (Е-4). Преподаватель выбирает учебный курс. Система закрепляет за преподавателем выбранный учебный курс (Е-5). Затем прецедент начинается сначала.

S-2: удалить учебный курс (Delete a Course Offering)

Система отображает диалоговое окно, содержащее поле для ввода названия и номера учебного курса. Преподаватель выбирает название и номер учебного курса (Е-6). Система удаляет взаимосвязь курса с преподавателем (Е-7). Затем прецедент начинается сначала.

S-3: просмотреть расписание (Review Schedule)

Система получает (Е-8) и отображает следующую информацию для всех учебных курсов, за которыми закреплен данный преподаватель: название предмета, номер предмета, номер учебного курса, день недели, время и место проведения занятий. Когда преподаватель отмечает, что просматривает список, прецедент начинается сначала.

S-4: напечатать расписание (Print Schedule)

Система распечатывает расписание преподавателя (Е-9). Прецедент начинается сначала.

1.4. Альтернативные потоки

Е-1: введен неверный идентификационный номер преподавателя. Пользователь должен повторить ввод идентификационного номера или завершить прецедент.

Е-2: введен неверный семестр. Пользователь должен повторить ввод семестра или завершить прецедент.

Е-3: введено неверное название или номер предмета. Пользователь должен повторить ввод названия и номера предмета или завершить прецедент.

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

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

Е-6: введено неверное название или номер учебного курса. Пользователь должен повторить ввод названия и номера учебного курса или завершить прецедент.

Е-7: система не может удалить связь курса с преподавателем. Информация сохраняется, система удалит связь позже. Выполнение прецедента продолжается.

Е-8: система не может получить информацию о расписании. Прецедент начинается сначала.

Е-9: расписание не может быть распечатано. Пользователю сообщается, что данная опция в данный момент недоступна. Прецедент начинается сначала.

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

Для связи документов, описывающих потоки событий, с прецедентами в программе Rational Rose выполните следующие действия:

1. Щелкните правой кнопкой мыши по прецеденту в списке браузера.

2. В появившемся контекстно-зависимом меню выберите команду Open Specification (Открыть параметры).

3. Щелкните по вкладке Files (Файлы).

4. Щелкните правой кнопкой мыши по списку файлов.

5. В появившемся контекстно-зависимом меню выберите команду Insert File (Добавить файл).

6. Укажите нужный файл в стандартном диалоговом окне выбора файла.

7. Щелкните по кнопке Open (Открыть), чтобы добавить указанный файл в список.

8. Щелкните по кнопке OK, чтобы закрыть диалоговое окно настройки параметров прецедента.

Связанные документы добавляются в список браузера. Связанный документ с описанием потока событий показан на рис. 3.7.

Рис. 3.7. Связанный документ с описанием потока событий

 

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

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

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

Рис. 3.11. Нотация языка UML для элементов диаграммы действий

Диаграммы действий в программе Rational Rose создаются следующим образом:

1. Щелкните правой кнопкой мыши по разделу Use Case View (Представление прецедентов) в списке браузера.

2. В появившемся контекстно-зависимом меню выберите команду New => Activity Diagram (Создать => Диаграмма действий). В список будет добавлена новая диаграмма с именем New Diagram.

3. Введите название диаграммы.

4. Чтобы открыть диаграмму, дважды щелкните по ней мышью в браузере. Окно браузера с диаграммой действий изображено на рис. 3.12.

Рис. 3.12. Диаграмма действий в окне браузера

 

Действия

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

Для создания действий в программе Rational Rose:

1. Щелкните по кнопке Activity (Действие) на панели инструментов.

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

3. Введите имя нового действия.

Рис. 3.13. Действия

 

Переходы

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

Чтобы получить переходы в программе Rational Rose:

1. Щелкните по кнопке State Transition (Переход) на панели инструментов.

2. Щелкните по начальному действию на диаграмме и переместите стрелку перехода на последующее действие.

Рис. 3.14. Переходы

 

Элементы выбора

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

Для создания элементов выбора в программе Rational Rose выполните следующие действия:

1. Щелкните по кнопке Decision (Элемент выбора) на панели инструментов.

2. Щелкните по диаграмме действий, чтобы поместить на нее элемент выбора.

3. Введите имя нового элемента.

4. Щелкните по кнопке State Transition на панели инструментов.

5. Щелкните по начальному действию на диаграмме и переместите стрелку перехода на элемент выбора.

Элемент выбора показан на рис. 3.15.

Последовательность создания условных переходов в программе Rational Rose:

1. Щелкните по кнопке State Transition на панели инструментов.

2. Щелкните по элементу выбора на диаграмме и переместите стрелку перехода на последующее действие.

3. Дважды щелкните по стрелке перехода, чтобы открыть диалоговое окно Specification (Параметры).

4. Щелкните по вкладке Detail (Подробно).

5. В поле ввода Guard Condition (Условие) введите условие перехода.

6. Щелкните по кнопке OK, чтобы закрыть диалоговое окно.

Указатель перехода с условием изображен на рис. 3.16.

Рис. 3.15. Элементы выбора на диаграмме действий

Рис. 3.16. Условные переходы

Чтобы получить прямолинейные линии переходов в программе Rational Rose:

1. Выберите линии переходов, которые вы хотите сделать прямолинейными (для выбора нескольких линий можно использовать клавишу Shift).

2. Выберите команду меню Format => Style => Rectilinear (Формат => Стиль => Прямолинейный).

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

Прямолинейные линии переходов показаны на рис. 3.17.

Рис. 3.17. Прямолинейные линии

 

Линии синхронизации

В потоке обычно существуют действия, выполняемые параллельно. Линия синхронизации (synchronization bar) позволяет указать на необходимость их одновременного выполнения, а также обеспечивает единое выполнение действий в потоке (то есть указывает на необходимость завершения определенных действий для перехода к следующему) — см. рис. 3.18. Таким образом, линии перехода могут иметь несколько входящих линий переходов и одну исходящую либо одну входящую и несколько исходящих.

Для создания линий синхронизации в программе Rational Rose:

1. Щелкните по кнопке Horizontal Synchronization (Горизонтальная линия синхронизации) или Vertical Synchronization (Вертикальная линия синхронизации) на панели инструментов.

2. Щелкните по диаграмме действий, чтобы поместить на нее линию синхронизации.

3. Щелкните по кнопке State Transition (Переход) на панели инструментов и добавьте необходимые входящие и исходящие линии переходов к линии синхронизации.

Линии синхронизации показаны на рис. 3.18.

Рис. 3.18. Линии синхронизации

 

Секции

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

Алгоритм создания секций в программе Rational Rose:

1. Щелкните по кнопке Swimlane (Секция) на панели инструментов.

2. Щелкните по диаграмме действий, чтобы создать на ней новую секцию с названием New Swimlane.

3. Дважды щелкните по названию новой секции, чтобы открыть диалоговое окно Specification (Параметры).

4. Введите нужное название секции в поле ввода Name (Название).

5. Щелкните по кнопке OK, чтобы закрыть диалоговое окно.

6. Для изменения размеров секции переместите ее границу с помощью мыши.

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

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

Рис. 3.19. Секции

 

Начальное и конечное состояния

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

Последовательность создания начального и конечного состояний в программе Rational Rose:

1. Щелкните по кнопке Start State (Начальное состояние) или End State (Конечное состояние) на панели инструментов.

2. Щелкните по диаграмме действий, чтобы поместить на нее символ конечного или начального состояния.

3. Если вы добавили начальное состояние, щелкните по кнопке State Transition (Переход) на панели инструментов, а затем на символе начального состояния и выполните переход к первому действию в потоке.

4. Если вы добавили конечное состояние, щелкните по кнопке State Transition на панели инструментов, а затем на предшествующем действии и выполните переход к символу конечного состояния на диаграмме.

Диаграмма действий с начальным и конечным состояниями показана на рис. 3.20.

Рис. 3.20. Начальное и конечное состояния