Описание потоков событий

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

2.1 Потоки событий варианта использования «авторизация»

Вариант использования «авторизация» позволяет определить пользователя приложения, и в зависимости от этого, открыть начальную форму пользователя (поскольку у коменданта и воспитателя она своя).

Основной поток А.

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

2. Приложение предлагает ввести пользователю свой персональный логин и пароль.

3. Пользователь вводит логин и пароль.

4. Приложение подтверждает введенный логин и пароль. Если логин и пароль не подтверждены выполняется альтернативный поток событий А1.

5. Приложение выводит список доступных категорий.

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

1. Приложение информирует пользователя о том, что введенный логин или пароль не верны.

2. Вариант использования завершается.

2.2 Потоки событий варианта использования «формирование списка студентов»

Вариант использования «формирование списка студентов» позволяет воспитателю внести или отредактировать информацию о студентах.

Основной поток событий Б.

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

2. Воспитатель вводит информацию о студенте. Если же студент уже зарегистрирован, и нужно редактировать уже имеющуюся информацию о нем, выполняется альтернативный поток Б1.

3. Воспитатель сохраняет информацию.

4. Вариант использования завершается.

Альтернативный поток событий Б1.

1. Если воспитателю необходимо отредактировать информацию об уже зарегистрированном студенте, воспитатель из списка студентов выбирает нужного.

2. Воспитатель вводит новую информацию.

3. Сохраняет информацию.

4. Вариант использования завершается.

2.3 Потоки событий варианта использования «формирование списка должников»

Вариант использования «формирование списка должников» позволяет коменданту сформировать список должников, если такие имеются.

Основной поток событий В.

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

2. Коменданту предлагается ввести дату и время входа.

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

4. Приложение сохраняет информацию.

5. После сохранения коменданту предлагается выбрать функцию оповещение воспитателя.

6. Приложение отправляет список должников воспитателю.

7. Вариант использования заканчивается.

Альтернативный поток В1.

1. Если список должников не генерируется (должники отсутствуют), коменданту предлагается выбрать функцию сохранить.

2. Приложение сохраняет информацию.

3. Вариант использования заканчивается.

2.4 Потоки событий варианта использования «формирование списка нарушителей»

Вариант использования «формирование списка нарушителей» позволяет воспитателю сформировать список нарушителей, если такие имеются.

Основной поток событий Г.

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

2. Воспитателю предлагается ввести дату и время входа.

3. После ввода даты и времени воспитателю предлагается ввести информацию о нарушениях и тем самым сформировать список нарушителей. Если нарушений не было, выполняется альтернативный поток Г1.

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

5. Приложение сохраняет информацию.

6. После сохранения воспитателю предлагается выбрать функцию оповещение коменданта.

7. Приложение отправляет список нарушителей коменданту.

8. Вариант использования заканчивается.

Альтернативный поток Г1.

1. Если список нарушителей пустой, (т.е. нарушений нет), воспитателю предлагается выбрать функцию сохранить.

2. Приложение сохраняет информацию.

3. Вариант использования заканчивается.

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

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

Основной поток событий Д.

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

2. Пользователю предлагается выбрать категорию поиска по блоку/по ФИО.

3. После выбора категории пользователю предлагается ввести №блока / ФИО студента, информацию о котором нужно найти.

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

5. Приложение выводит информацию. Если же нужной информации нет, выполняется альтернативный поток Д1.

6. После пользователю предлагается выбрать функцию выход/назад.

7. Приложение возвращает пользователя на начальную форму/ приложение закрывается.

8. Вариант использования заканчивается.

Альтернативный поток Д1.

1. Если в списке не существует ФИО введенного пользователем студента, либо не существует блока, так же введенного пользователем, приложение выводит сообщение, о том, что информация не найдена.

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

3. Вариант использования заканчивается.

Выводы по главе 2

В данной главе были описаны потоки событий пяти вариантов использования. При описании были определены процессы обработки данных, реализуемые в рамках вариантов использования. Поток событий были разбиты две главные части основной поток событий и альтернативные потоки событий. Основной поток событий описывает, что "обычно" происходит, когда вариант использования выполняется. Альтернативные потоки событий описывают поведение дополнительного, необязательного или исключительного характера по отношению к обычному поведению.

Описание диаграмм

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

В проекте используется семь видов диаграмм:

− Диаграммы вариантов использования;

− Диаграммы взаимодействия;

− Диаграммы коопераций;

− Диаграммы классов;

− Диаграммы состояний;

− Диаграммы компонентов;

− Диаграмма размещения;

Диаграммы вариантов использования (Use-case диаграмма)

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

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

− Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.

− Сформулировать общие требования к функциональному поведению проектируемой системы.

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

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

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

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

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

На рисунке 1 приведена диаграмма использования, спроектированная в среде RationalRose. Основным действующим лицом (актером) является секретарь деканата, выполняющий три основных действия:

- составить ведомость. Периодичность: в соответствии с учебным планом;

- просмотр итогов сессии. Подразумевает поиск информации по необходимости;

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

Для создания диаграммы последовательности:

1. Нужно открыть интегрированную среду разработки Rational Rose.

2. С помощью кнопки Use Case (вариант использования) панели инструментов поместим на диаграмму новый вариант использования, который назовем «Секретарь деканата: просмотр данных сессии».

3. Затем поместим на диаграмму остальные варианты использования:

– Авторизация;

– Просмотреть данные сессии;

– Составить ведомость;

– Внести результаты сессии;

– Добавить студента в БД;

4. С помощью кнопки Actor (действующее лицо) на панели инструментов поместим на диаграмму новое действующее лицо.

Рисунок 1 – Диаграмма вариантов использования (Секретарь деканата: просмотр данных сессии)

5. Назовем его «Секретарь деканата».

6. С помощью кнопки Unidirectional Association (Однонаправленная ассоциация) добавим ассоциацию между действующим лицом «Секретарь деканата» и вариантом использования «Авторизация».

7. С помощью кнопки Unidirectional Association (Однонаправленная ассоциация) добавим ассоциации между вариантом использования «Авторизация» и оставшимися вариантами использования.

Эти варианты использования инициируют последовательность действий в базе данных в ответ на действия со стороны «Секретарь деканата».

Аналогично были составлены еще две диаграммы вариантов использования:

– Диаграмма вариантов использования для актера «Диспетчер» (Рисунок 2);

– Диаграмма вариантов использования для актера «Ректор» (Рисунок 3);

Рисунок 2 – Диаграмма вариантов использования для актера «Диспетчер»

Рисунок 3 – Диаграмма вариантов использования для актера «Ректор»

Выводы:

1. В ходе выполнения работы были разработаны 3 диаграммы прецедентов. Основными действующими лицами являются: секретарь деканата, ректор, диспетчер.

Актер «Секретарь деканата» выполняет пять действий: «авторизация», «просмотреть данные сессии», «добавить студента в БД», «составить ведомость», «внести результаты сессии».

Актер «Диспетчер» выполняет четыре действия: «авторизация», «добавление данных в БД», «изменение данных в БД», «удаление данных из БД».

Актер «Ректор» выполняет три действия: «авторизация», «просмотр данных», «поиск данных».

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

Не нашли, что искали? Воспользуйтесь поиском: