3 Описание диаграмм
Диаграмма в UML - это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Основная цель диаграмм - визуализация разрабатываемой системы с разных точек зрения. Диаграмма - в самом общем смысле некоторый срез системы. Обычно, за исключением самых простых моделей, диаграммы дают свернутое представление элементов, из которых состоит разрабатываемая система.
В проекте используется семь видов диаграмм:
Диаграммы вариантов использования;
Диаграммы взаимодействия;
Диаграммы коопераций;
Диаграммы классов;
Диаграммы состояний;
Диаграммы компонентов;
Диаграмма размещения;
3.1 Диаграммы вариантов использования (Use-case диаграмма)
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру.
Разработка диаграммы вариантов использования преследует цели:
Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.
Сформулировать общие требования к функциональному поведению проектируемой системы.
Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров, возможно, некоторых интерфейсов, и отношений между этими элементами. Базовыми элементами диаграммы являются вариант использования и актер.
Актер представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач.
Вариант использования - конструкция или стандартный элемент языка UML, применяется для спецификации общих особенностей поведения системы или любой другой сущности предметной области без рассмотрения внутренней структуры этой сущности.
На рисунке 1 приведена диаграмма использования, спроектированная в среде RationalRose. Основным действующим лицом (актером) является секретарь деканата, выполняющий три основных действия:
составить ведомость. Периодичность: в соответствии с учебным планом;
просмотр итогов сессии. Подразумевает поиск информации по необходимости;
добавление студента в базу данных. Предполагает внесение информации о студенте, при хороших результатах сдачи экзаменационной сессии, обновление записей в базе данных при изменении этой информации.
Для создания диаграммы последовательности:
Нужно открыть интегрированную среду разработки Rational Rose.
С помощью кнопки Use Case (вариант использования) панели инструментов поместим на диаграмму новый вариант использования, который назовем «Секретарь деканата: просмотр данных сессии».
Затем поместим на диаграмму остальные варианты использования:
Авторизация;
Просмотреть данные сессии;
Составить ведомость;
Внести результаты сессии;
Добавить студента в БД;
С помощью кнопки Actor (действующее лицо) на панели инструментов поместим на диаграмму новое действующее лицо.
Рисунок 1 – Диаграмма вариантов использования (Секретарь деканата: просмотр данных сессии)
Назовем его «Секретарь деканата».
С помощью кнопки Unidirectional Association (Однонаправленная ассоциация) добавим ассоциацию между действующим лицом «Секретарь деканата» и вариантом использования «Авторизация».
С помощью кнопки Unidirectional Association (Однонаправленная ассоциация) добавим ассоциации между вариантом использования «Авторизация» и оставшимися вариантами использования.
Эти варианты использования инициируют последовательность действий в базе данных в ответ на действия со стороны «Секретарь деканата».
Аналогично были составлены еще две диаграммы вариантов использования:
Диаграмма вариантов использования для актера «Диспетчер» (Рисунок 2);
Диаграмма вариантов использования для актера «Ректор» (Рисунок 3);
Рисунок 2 – Диаграмма вариантов использования для актера «Диспетчер»
Рисунок 3 – Диаграмма вариантов использования для актера «Ректор»
Выводы:
1. В ходе выполнения работы были разработаны 3 диаграммы прецедентов. Основными действующими лицами являются: секретарь деканата, ректор, диспетчер.
Актер «Секретарь деканата» выполняет пять действий: «авторизация», «просмотреть данные сессии», «добавить студента в БД», «составить ведомость», «внести результаты сессии».
Актер «Диспетчер» выполняет четыре действия: «авторизация», «добавление данных в БД», «изменение данных в БД», «удаление данных из БД».
Актер «Ректор» выполняет три действия: «авторизация», «просмотр данных», «поиск данных».
2. Просмотрев диаграммы использования видно, что важной и сложной задачей информационной подсистемы является ввод и обработка информации о студентах, поскольку от правильности выполнения этого прецедента будет зависеть в дальнейшем успешность оперативного учета.
Создание диаграммы последовательности
Диаграмма последовательности (англ. sequence diagram) — диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. Используется в языке UML.
Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники), вертикальные линии (англ. lifeline), отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. На данной диаграмме объекты располагаются слева направо. Ее недостатком является то, что она занимает много места.
Рассмотрим вариант использования «Добавить студента в БД». Диаграмма последовательности приведена на рисунке 4.
Рисунок 4 – Диаграмма последовательности для варианта использования «Добавить студента в БД»
На приведенной выше диаграмме выделены следующие объекты соответствующих классов:
Авторизация – объект класса AuthForm;
форма обучения – объект класса FormStudent;
Выбор экзаменационной формы – объект класса FormExems, отвечающий за выбор необходимой формы;
управляющий БД – объект управляющего класса DBManager, выполняющий функции СУБД;
добавление данных студента – объект класса Information, инкапсулирующего в себе всю необходимую информацию оcтуденте и результатах сессии;
управляющий транзакциями – объект класса TransactionManager, берущий на себя функции СУБД по управлению транзакциями.
Последовательность действий основного потока выглядит следующим образом:
Секретарь деканата проходит авторизацию в программе.
Создает новую запись о студенте в БД.
При этом он открывает необходимую форму для ввода данных студента.
Вводит все необходимые поля в открытую форму.
Нажимает на клавишу «Сохранить».
При этом информация отправляется в СУБД, которая обозначена на диаграмме как «Управляющий БД».
СУБД создает новую пустую запись.
Генерирует изменяет значения полей в соответствии с введенными секретарем данными.
Передает эту запись системе управления транзакциями, которая обозначена на диаграмме как «Управляющий транзакциями».
Система управления транзакциями осуществляет транзакцию.
Система управления транзакциями возвращает сообщение об успешности проведения транзакции или ошибке при её выполнении.
Рассмотрим вариант использования «Добавить расписание в БД». Диаграмма последовательности приведена на рисунке 5.
Рисунок 5 – Диаграмма последовательности для варианта использования «Добавить расписание в БД»
На приведенной выше диаграмме выделены следующие объекты соответствующих классов:
Авторизация – объект класса AuthForm;
Группа – объект класса GroupStud;
Выбор наименования предмета – объект класса Lesson;
управляющий БД – объект управляющего класса DBManager, выполняющий функции СУБД;
добавление данных о расписании занятий – объект класса TimetableInfo, инкапсулирующего в себе всю необходимую информацию о расписании занятий;
управляющий транзакциями – объект класса TransactionManager, берущий на себя функции СУБД по управлению транзакциями.
Последовательность действий основного потока выглядит следующим образом:
Диспетчер проходит авторизацию в программе.
Создает новые записи о занятиях в БД.
При этом он открывает необходимую форму для выбора предмета.
Вводит все необходимые поля в открытую форму.
Нажимает на клавишу «Сохранить».
При этом информация отправляется в СУБД, которая обозначена на диаграмме как «Управляющий БД».
СУБД создает новую пустую запись.
Генерирует изменяет значения полей в соответствии с введенными диспетчером данными.
Передает эту запись системе управления транзакциями, которая обозначена на диаграмме как «Управляющий транзакциями».
Система управления транзакциями осуществляет транзакцию.
Система управления транзакциями возвращает сообщение об успешности проведения транзакции или ошибке при её выполнении.
Рассмотрим вариант использования «Поиск данных актером «Ректор»». Диаграмма последовательности приведена на рисунке 6.
Рисунок 6 – Диаграмма последовательности для варианта использования «Поиск данных актером «Ректор»»
На приведенной выше диаграмме выделены следующие объекты соответствующих классов:
Авторизация – объект класса AuthForm;
Форма выбора категории поиска – объект класса CategoryOfSearch;
Поиск данных – объект класса SearchInfo;
управляющий транзакциями – объект класса TransactionManager, берущий на себя функции СУБД по управлению транзакциями.
Последовательность действий основного потока выглядит следующим образом:
Ректор проходит авторизацию в программе.
Осуществляет выбор категории поиска интересующей его информации.
При этом он открывает необходимую форму для выбора категории поиска.
Вводит все необходимые поля в открытую форму.
Нажимает на клавишу «Поиск».
Система управления транзакциями осуществляет транзакцию.
Система управления транзакциями возвращает сообщение об успешности проведения транзакции или ошибке при её выполнении.
Выводы:
1.Разработаны диаграммы последовательности для вариантов использования «Добавить студента в БД», «Добавить расписание в БД», «Поиск данных актером «Ректор»». Данные варианты использования являются самыми важными и сложно реализуемыми задачами информационной подсистемы.
2.При создании диаграмм были созданы следующие классы:
для варианта использования «Добавить студента в БД»:
AuthForm,
FormStudent,
FormExems,
DBManager,
Information,
TransactionManager.
для варианта использования «Добавить расписание в БД»:
AuthForm,
GroupStud,
Lesson,
DBManager,
TimetableInfo,
TransactionManager.
для варианта использования «Поиск данных актером «Ректор»»:
AuthForm,
CategoryOfSearch, -SearchInfo, -TransactionManager.
Создание диаграммы сотрудничества
Диаграмма кооперации – это диаграмма, на которой также как и на диаграмме последовательности указан обмен сообщениями между объектами при реализации любого варианта использования. На ней изображается та же информация, но в другой системе обозначений. Ось времени в явной форме отсутствует, поэтому важна нумерация сообщений. Одни и те же объекты могут выступать в различных ролях.
Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта, и типы этих сообщений.
Диаграмма кооперации «Добавить студента в БД» представлена на рисунке 7.
Рисунок 7 - Диаграмма кооперации «Добавить студента в БД»
Диаграмма кооперации «Добавить расписание в БД» представлена на рисунке 8.
Рисунок 8 - Диаграмма кооперации «Добавить расписание в БД»
Диаграмма кооперации «Поиск данных актером «Ректор»» представлена на рисунке 9.
Рисунок 9- Диаграмма кооперации «Поиск данных актером «Ректор»»