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

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

Рисунок 8 – Диаграмма деятельности «Продажа билетов»

Данная диаграмма описывает поток событий, происходящий в системе при выполнении клиентом запроса на Приобретение билета.

5. Спецификация состояния проектируемого ПО

Проведем выявление классов в нашей системе для этого:

А) Выпишем все существительные:

Кинотеатр

сеанс

кассир

билет

зрительный_зал

цена

название_сеанса

Время_начала

Место

описание_сеанса

Длительность_сеанса

А(VIP)

Б(Comfort)

С(Normal)

Бронь

Номер_места

расписание_сеансов

Б) Выделим кандидатов в классы:

Расписание_сеансов

Зрительный_зал

Место

С) Определим атрибуты каждого класса

1)Расписание_сеансов

-название_сеанса

-время_начала

-зрительный_зал

-цена А(VIP) Б(Comfort) С(Normal)

-длительность_сеанса

-описание_сеанса

2)Зрительный_зал

- А(VIP)

- Б(Comfort)

- С(Normal)

3)Место

- Номер места

- бронь

Д) В ходе анализа выявленно что Клиент и Кассир не являются членами классов, Класс Зрительный_зал необходимо доопределить Названием_зала, Класс Место необходимо допределить добавив параметр куплено и преведя его параметр бронь к тому же виду что и куплено - забронировано.

1)Расписание_сеансов

- название_сеанса

- время_начала

- зрительный_зал

- цена А(VIP) Б(Comfort) С(Normal)

- длительность_сеанса

- описание_сеанса

2)Зрительный_зал

- Название_зала

- А(VIP)

- Б(Comfort)

- С(Normal)

3)Место

- Номер места

- Куплено

- Забронировано

Для спецификации состояния системы построим диаграмму классов для данной системы.

Рисунок 9 – Диаграмма классов для системы «Продажи билетов в кинотеатре»

Получившиеся классы не относятся к системе продажи билетов, а относятся к внешним базам данных: База данных Репертуара и База данных сеансов. А это означает, что создание собственной базы данных для реализации системы продажи билетов в кинотеатре не требуется.

Приложение А

Спецификация требований к информационной системе «ПРОДАЖА БИЛЕТОВ В КИНОТЕАТРЕ»

1. Введение

1.1 Цель

Цель этого документа – в том, чтобы сформулировать требования к разрабатываемой АИС Продажи билетов в кинотеатре. Данные требования описаны в форме прецедентов, кратких описаний функциональных требований и описаний нефункциональных требований.

1.2 Определения, акронимы и сокращения

Основные определения приведены в документе Glossary.doc.

1.3 Ссылки

Сопутствующая информация представлена в следующих документах:

требованиях совладельцев (Пользовательские требования.doc);

глоссарии (Glossary.doc).

2. Обзор системы

2.1 Обзор прецедентов

Краткое представление актеров представлено в таблице 1.

Табл. 1. Актеры системы

Актер	Краткое описание
Кассир	Служащий Кинотеатра осуществляющий денежные операции с Клиентом. Занимается продажей билетов, установкой/снятием брони. Предназначено для обслуживания Клиента и является представителем Кинотеатра для Клиента. Построение ИС подразумевает возможную замену человека-Кассира на Автомат-Кассир.
Клиент	Лицо являющееся потребителем. В функции Клиента входит все что касается выбора сеанса из доступных предложений. Может покупать, возвращать, бронировать и осуществлять все допустимые операции с билетом при обращении к Кассиру

Список вариантов использования показан в таблице 2.

Табл. 2. Реестр вариантов использования.

Код	Основной автор	Наименование	Формулировка
1	Клиент	ZapolnenieZakaza	Клиент указывает в билете необходимую информацию, для последующего бронирования билета или его заказа
2	Клиент	ProdazhaBiletov	Клиент совершает операцию купли-продажи с целью получения билета на конкретный сеанс
3	Клиент	SeeInformation	Клиент смотрит наиболее полную информацию о сеансах, ценах, расписании сеансов чтобы определиться что именно он хочет от Кинотеатра.
4	Клиент	VernutBilet	Клиент возвращает билет Кассиру с целью возврата денег
5	Клиент	BronirovanieBileta	Клиент закрепляет за собой право покупки конкретного билета
6	Клиент	SnyatBron	Клиент снимает бронь с билета

2.2 Предположения и зависимости

Система будет использоваться на территориально сосредоточенном (без внешних филиалов) предприятии.

В случае изменений в формах документов АИС должна претерпеть малосущественные изменения (нужно будет модифицировать отчётные формы).

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

3. Описание требований

3.1 Краткие описания вариантов использования

3.1.1 Заполнение Заказа

1

Клиент

ZapolnenieZakaza

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

Основное действующее лицо: Клиент.

Другие участники прецедента: нет

Связи с другими вариантами использования: отсутствуют

Краткое описание.

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

Основой для генерирования билета и послужит этот набор предпочтений – заказ, который Клиент составляет сам (для примера – выбирает на какой сеанс пойти, какое место в зале приобрести).

Для Атомата-Кассира этот Заказ может представлять собой таблицу с полями, которые заполняются Клиентом на основе имеющихся в ИС предложений.