science-review.ru
Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы [1]. Для достижения этих целей вначале строится модель в форме диаграммы вариантов использования, которая описывает функциональное назначение системы или, другими словами, что система будет делать в процессе своего функционирования [2]. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки [3].
В данной статье объектом исследования является система продажи билетов на футбол. Для данной системы необходимо выполнить следующее:
– построить диаграмму использования, которая включает Клиента, Организатора и Администратора, а также функции, которые каждый из этих акторов выполняет в данной системе;
– расписать спецификации вариантов использования для функций каждого из акторов.
Цель данной статьи – построить и описать модель системы продажи билетов на футбол с помощью диаграммы использования, раскрыть спецификации вариантов использования.
В качестве материала исследования выступает программное обеспечение WhiteStarUML.
В статье используется эмпирический метод исследования, поскольку основной источников результатов – анализ данных.
Описание моделируемой системы
Разрабатываемая система представляет собой программный комплекс для продажи билетов на футбол. Данная система позволяет покупать и сдавать билеты и абонементы на матчи, проходящие на одном стадионе с нумерованными местами.
Система имеет три вида пользователей: Клиент, Организатор и Администратор. Клиент представляет собой пользователя, который приобретает или сдает билеты / абонементы. В задачи Организатора входит формирование расписания на матчи. Администратор открывает доступ зарегистрированным Клиентам / Организаторам.
Клиент имеет возможность выбирать тип места (VIP или обычное место) в зависимости от своих предпочтений. Кроме этого, он может узнавать расписание предстоящих матчей и наличие свободных билетов / абонементов. После изучения расписания и выбора места на матч Клиент приобретает билет / абонемент, и информация об успешной покупке билета / абонемента поступает в базу данных, которая хранится на сервере Администратора.
Организатор имеет возможность вносить корректировки в существующее расписание, а также получать отчеты о продажах билетов на тот или иной матч (информация хранится на сервере Администратора).
Администратор также обеспечивает интеграцию между системой и банковским центром, с помощью которого осуществляется оплата за билет.
Таким образом, основная цель разрабатываемой системы – обеспечение удобного, быстрого и качественного взаимодействия между организаторами и клиентами для продажи / сдачи билетов / абонементов на футбольные матчи.
Разработка диаграммы использования
Диаграмма вариантов использования предназначена для моделирования представления системы с точки зрения вариантов использования и действующих лиц в их взаимодействии. Варианты использования понимаются как множество возможных последовательной действий (событий), приводящих к значимому для действующего лица результату [4].
С помощью WhiteStarUml в соответствии с техническим заданием разработана диаграмма использования, которая представлена на рис. 1–3 для каждого из акторов системы продажи билетов на футбол [5; 6].
Рис. 1. Диаграмма использования для Клиента
Рис. 2. Диаграмма использования для Организатора
Рис. 3. Диаграмма использования для Администратора
Представленная выше диаграмма содержит три вида акторов: Клиент, Организатор и Администратор.
Клиент системы может выполнить следующие функции:
1. Зарегистрироваться.
2. Авторизоваться.
3. Узнать расписание.
4. Купить билет / абонемент (включает проверку на наличие свободных мест и содержит расширение в виде выбора типа места (VIP или обычное место)).
5. Сдать билет / абонемент.
Функции организатора:
1. Зарегистрироваться.
2. Авторизоваться.
3. Сформировать расписание (включает функцию «Корректировать расписание»).
4. Сообщить о наличии (содержит расширение проверить наличие билетов / абонементов).
5. Получить отчет (по матчу / сезону).
Функции администратора:
1. Авторизоваться.
2. Открыть доступ.
3. Сформировать отчет (по матчу / сезону).
4. Обеспечивать взаимодействие между системой и банковским центром.
Разработанная диаграмма имеет следующие типы соединений:
1. Ассоциация, которая указывает, что субъект принимает участие в варианте использования.
2. Включение (include), использующееся для того, чтобы показать, как разбить вариант использования.
3. Расширение (extend), показывающее, что вариант использования расширяет базовую последовательность действий и вставляет собственную последовательность.
Виды кратности ассоциаций [7; 8]:
– 1 – чтобы указать, что только один экземпляр этой роли может участвовать в каждой связи.
– 1..* – чтобы указать, что в каждой связи может участвовать один или несколько экземпляров этой роли.
– 0..1 – чтобы указать, что участие не является обязательным.
– * – чтобы указать, что в связи участвует 0 или более экземпляров этой роли.
Спецификация вариантов использования
В разработанной диаграмме используются следующие компоненты:
Имя прецедента (= Зарегистрироваться);
ID прецедента = 1;
Краткое описание – регистрация пользователя (Клиента, Организатора) в системе продажи билетов на футбол;
Акторы – Клиент, Организатор;
Предусловия – наличие кнопки «Регистрация»;
Основной поток – нажатие на кнопку «Регистрация» в случае если пользователь не зарегистрирован, выбор статуса пользователя (Клиент или Организатор), ввод данных;
Постусловия – авторизация пользователя в системе продажи билетов на футбол.
Имя прецедента (= Авторизоваться);
ID прецедента = 2;
Краткое описание – авторизация пользователя (Клиента, Организатора, Администратора) в системе продажи билетов на футбол;
Акторы – Клиент, Организатор, Админ- истратор;
Предусловия – наличие кнопки «Войти в систему»;
Основной поток – нажатие на кнопку «Регистрация», выбор статуса пользователя (Клиент или Организатор), ввод данных, авторизация;
Постусловия – возможность пользоваться соответствующими функциями сервиса в зависимости от статуса пользователя (Клиент или Организатор).
Имя прецедента (= Узнать расписание);
ID прецедента = 3;
Краткое описание – Клиент узнает расписание интересующего матча;
Акторы – Клиент;
Предусловия – авторизованный Клиент, наличие расписания матчей;
Основной поток – Клиент узнает расписание интересующего матча;
Постусловия – Клиент может приступить к покупке билета / абонемента на интересующий его матч.
Имя прецедента (= Купить билет / абонемент);
ID прецедента = 4;
Краткое описание – Клиент покупает билет / абонемент;
Акторы – Клиент;
Предусловия – Клиент узнал расписание на матч / матчи, и билет / абонемент имеется в наличии;
Основной поток – Прецедент содержит следующие этапы:
– Клиент нажимает на кнопку «Купить билет / абонемент».
– Система проверяет наличие билетов / абонементов и отправляет пользователю соответствующее сообщение; в случае если билеты отсутствуют, Клиент не имеет возможности посетить выбранный матч.
– Клиент выбирает тип места (VIP или обычное место).
– Клиент оплачивает билет / абонемент.
– Клиент получает билет / абонемент.
Постусловия – Клиент получает возможность посетить матч / сезон.
Имя прецедента (= Сдать билет / абонемент);
ID прецедента = 5;
Краткое описание – Клиент сдает билет / абонемент;
Акторы – Клиент;
Предусловия – У Клиента есть купленный ранее билет;
Основной поток – Клиент сдает билет / абонемент в случае, если он больше не хочет идти на футбольный матч;
Постусловия – Другой Клиент получает возможность приобрести сданный билет.
Имя прецедента (= Сформировать рас- писание);
ID прецедента = 6;
Краткое описание – Организатор формирует расписание на матчи;
Акторы – Организатор;
Предусловия – Авторизованный Орга- низатор;
Основной поток – Организатор формирует расписание на матчи; в случае если матч терпит какие-то изменения в расписании, Организатор имеет возможность его скорректировать;
Постусловия – Клиенты имеют возможность узнать расписание на интересующие их матчи.
Имя прецедента (= Сообщить о на- личии);
ID прецедента = 7;
Краткое описание – Организатор сообщает о наличии / отсутствии свободных билетов / абонементов;
Акторы – Организатор;
Предусловия – авторизованный Орга- низатор;
Основной поток – Организатор сообщает о наличии / отсутствии свободных билетов / абонементов;
Постусловия – Клиент узнает информацию о наличии / отсутствии свободных билетов / абонементов.
Имя прецедента (= Получить отчет);
ID прецедента = 8;
Краткое описание – Организатор получает отчетность по матчам (количество проданных билетов и пр.);
Акторы – Организатор;
Предусловия – Администратор сформировал отчет по матчу / сезону, который хранится в базе данных;
Основной поток – Организатор получает отчетность по матчу / сезону;
Постусловия – Организатор может сделать выводы по проделанной организаторской работе.
Имя прецедента (= Открыть доступ);
ID прецедента = 9;
Краткое описание – открытие доступа администратором зарегистрированным пользователям;
Акторы – Администратор;
Предусловия – Администратор авторизовался в системе;
Основной поток – открытие доступа администратором зарегистрированным пользователям;
Постусловия – получившие доступ пользователи получают возможность использовать соответствующие функции сервиса в зависимости от статуса пользователя (Клиент или Организатор).
Имя прецедента (= Обеспечить интеграцию с банком);
ID прецедента = 10;
Краткое описание – Администратор обеспечивает взаимодействие с банковским центром, который позволяет провести оплату за билет / абонемент;
Акторы – Администратор;
Предусловия – Администратор авторизовался в системе;
Основной поток – обеспечение интеграции с банком для возможности оплаты за билет / абонемент;
Постусловия – Клиент имеет возможность произвести оплату.
Имя прецедента (= Сформировать отчет);
ID прецедента = 11;
Краткое описание – формирование отчета по матчу / сезону, который будет храниться в базе данных;
Акторы – Администратор;
Предусловия – матч / сезон проведен;
Основной поток – Администратор формирует отчет по прошедшему матчу / сезону, который хранится в базе данных;
Постусловия – Организатор имеет возможность получить отчетность по матчу / сезону.
Заключение
В данной статье проведена работа с моделью системы продажи билетов на футбол с помощью программного обеспечения WhiteStarUML. Данная система включает в себя трех акторов (Клиента, Организатора и Администратора), а также их функции.
Для данной системы выполнено следующее:
– построена диаграмма использования, которая включает Клиента, Организатора и Администратора, а также функции, которые каждый из этих акторов выполняет в данной системе;
– расписаны спецификации вариантов использования для функций каждого из акторов.