Файл: Разработка регламента выполнения процесса «Реализация билетов через розничные кассы»..pdf

MDA (MODEL DRIVEN ARCHITECTURE)

MDA - это технология, разработанная OMG. Чтобы максимально использовать преимущества MDA, утилиты для моделирования должны поддерживать множество настроек различных атрибутов. StarUML поддерживает MDA и предоставляет возможность настройки множества атрибуто

АРХИТЕКТУРА PLUG-IN

Чтобы соответствовать быстро растущим потребностям пользователей в увеличении функциональных возможностей утилит моделирования, утилита должна иметь хорошо определенную платформу, предусматривающую подключение плагинов. StarUML имеет простую и мощную архитектуру с поддержкой плагинов, так что любой имеет возможность принять участие в расширении функций утилиты, разработав и подключив собственный модуль, используя COM-совместимые языки (С++, Delphi, C#, VB, ...). Это дает платформе много большие перспективы развития, нежели ее коммерческим аналогам.

Вывод:

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

3. РАЗРАБОТКА ПРОЕКТА ИС С ПОМОЩЬЮ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА (UML-диаграммы)

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

Рис.1. Поток событий. Билетная касса.

Вариант использования «Информировать» заключается в том, что клиент получает от Администратора информацию, соответствующую его запросу. Администратор в свою очередь обращается к БД, что бы информировать клиента точными и полными данными о том или ином направлении или поезде.

Вариант использования «Выбрать» клиент, после полученных данных от Администратора, определяется с выбором билетов на заинтересованный им маршрут.

Вариант использования «Бронировать» выполняется в том случае, если клиент определился с выбором, но не может в данный момент приобрести выбранные им билеты, а сможет это сделать позже. В этом случае Администратор вносит в БД изменения, о том, что данные места забронированы и купить их другой человек не может (по крайней мере, до тех пор, пока не снимется бронь).

---

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

Предусловия

Вариант использования «Выбрать» имеет предусловие. Клиент сможет сделать свой выбор после того как Администратор предоставит ему перечень возможных вариантов, естественно соответственно отвечающих запросу клиента, то есть после варианта использования «Информировать».

Так же вариант использования «Оплатить» и «Бронировать» могут выполниться лишь после того, как клиент сделает выбор либо оплатить сейчас за билеты, либо сделать это через некоторое время, когда он придет снимать бронь.

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

Поток событий варианта использования «Выбрать» выглядит следующим образом:

1. Вариант использования начинается, когда клиент обращается к Администратору с просьбой выдать ему информацию о поездах.
2. Администратор обращается к БД и делает запрос.
3. Ответ на запрос выводит на внешний дисплей.
4. Клиент ознакомляется с ней и решает, что делать дальше.
5. Клиент выбирает название спектакля, день, место.
6. Если клиент решает купить билеты.
7. Администратор отмечает в БД места, которые он выбрал.
8. Клиент оплачивает стоимость билетов.
9. Администратор принимает деньги, вносит их в кассовый аппарат.
10. Выдает клиенту билеты, чек, свидетельствующий о купле-продаже и сдачу, если таковая имеется.
11. Процесс завершен.

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

1. Вариант использования начинается, когда клиент обращается к Администратору с просьбой выдать ему информацию о маршруте и поездах.
2. Администратор обращается к БД и делает запрос.
3. Ответ на запрос выводит на внешний дисплей.
4. Клиент ознакомляется с ней и решает, что делать дальше.
5. Клиент выбирает название маршрута, день, место.
6. У клиента нет возможности расплатиться за билеты в данный момент, и решает забронировать места.
7. Администратор отмечает в БД нужные места галочкой, с пометкой бронь.
8. БД сохраняет изменения, которые клиент может проследить на внешнем дисплее.
9. Администратор узнает фамилию клиента, чтобы тот мог прийти в другой раз и выкупить данные места.
10. БД сохраняет бронирование мест ровно на три дня. Если клиент не выкупит их в течении положенного срока, то бронирование автоматически убирается и данные места может приобрести уже другой клиент.

Постусловия

После совершения Администратором всех операций с БД все изменения автоматически сохраняются. Свободные места на дисплее закрашиваются зеленым цветом, занятые красным, а забронированные выделяются галочками.

---

3.2 Диаграмма классов

Выделим основные классы

Рис 2 Классы

Укажем связи и атрибуты

Рис.3 Диаграмма классов

В этой диаграмме классов представлены основные элементы предметной области, а также их атрибуты и операции.

Класс Город включает в себя следующие атрибуты:

• Город
• Поезд

И операции:

• Добавить()
• Изменить()
• Удалить()

Класс Поезд включает атрибуты:

• Название
• Дата
• Время

И операции этого класса:

• Добавить()
• Изменить()
• Удалить()

Класс Продажа билетов зависит от классов Поезд, Клиент, Билет, Город и Сотрудники. Атрибуты класса Продажа билетоа:

• Билет
• Город
• Поезд
• Клиент
• Сотрудник

Операции:

• Добавить()
• Изменить()
• Удалить()

Класс Билет включает следующие атрибуты:

• Город
• Дата
• Время
• Цена

Операции данного класса:

• Добавить
• Обновить
• Закрыть

Также в нашей базе данных имеются данные о всех сотрудниках театра именно это отражает класс Сотрудники. Атрибуты:

• ФИО
• Адрес
• Телефон

Операции:

• Добавить()
• Изменить()

Удалить()

Класс Клиент. Атрибуты:

• ФИО
• Паспорт

Описание:

• Добавить()
• Удалить()

Диаграмма деятельности

Рис. 4 Диаграмма деятельности

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

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

Рис.5 Диаграмма последовательности

1. Клиент запрашивает интересующую его информацию о билетах и спектаклях у Администратора;
2. Администратор обращается за получением информации, интересующую клиента, в базу данных по всем билетам и проходящим поездам
3. База данных выдает запрашиваемую информацию Администратору;
4. Администратор передает информацию полученную от базы данных клиенту;
5. Поучив необходимую информацию от Администратора, клиент принимает решение покупать билет;
6. Поучив необходимую информацию от Администратора, клиент принимает решение не покупать билет;
7. Решив совершить покупку клиент производит процедуру прямой покупки обратившись к Администратору;
   1. Администратор проводит в базе данных процедуру прямой покупки билета клиентом;
      1. После внесения информации о покупке билета в базу данных происходит оплата билета через кассу;
8. Решив совершить покупку клиент производит процедуру бронирования билета обратившись к Администратору;
   1. Администратор проводит в базе данных процедуру бронирования билета клиентом;
      1. После внесения информации о бронирование в базу данных происходит оплата билета через кассу, в удобное для клиента время;
9. Происходит оплата билета при прямой покупке, либо при выкупе брони, через кассу, касса выдает чек о произведении оплаты;
10. После оплаты стоимости билета, Администратор выдает клиенту купленный им билет.

---

Диаграмма кооперации

Рис. 6 Диаграмма кооперации

1. Клиент запрашивает интересующую его информацию о билетах и поездах у Администратора;
2. Администратор обращается за получением информации, интересующую клиента, в базу данных по всем билетам и проходящим поездам;
3. База данных выдает запрашиваемую информацию Администратору;
4. Администратор передает информацию полученную от базы данных клиенту;
5. Поучив необходимую информацию от Администратора, клиент принимает решение покупать билет;
6. Поучив необходимую информацию от Администратора, клиент принимает решение не покупать билет;
7. Решив совершить покупку клиент производит процедуру прямой покупки обратившись к Администратору;
   1. Администратор проводит в базе данных процедуру прямой покупки билета клиентом;
      1. После внесения информации о покупке билета в базу данных происходит оплата билета через кассу;
8. Решив совершить покупку клиент производит процедуру бронирования билета обратившись к Администратору;
   1. Администратор проводит в базе данных процедуру бронирования билета клиентом;
      1. После внесения информации о бронирование в базу данных происходит оплата билета через кассу, в удобное для клиента время;
9. Происходит оплата билета при прямой покупке, либо при выкупе брони, через кассу, касса выдает чек о произведении оплаты;
10. После оплаты стоимости билета, Администратор выдает клиенту купленный им билет.

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

Рис. 7 Диаграмма компонентов

Данная диаграмма включает в себя 6 компонентов.

Компонент Головной модуль – является главным, служит для выдачи необходимой информации клиенту.

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

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

Компонент БД билетов – содержит в себе всю информацию о билетах на поезда.

Компонент БД поездов - содержит в себе всю информацию о театрах города.

Диаграмма состояний объекта Билет

---