Онлайновая театральная касса "Билетов.Нет" представляет собой web-сайт службы бронирования и доставки билетов на спектакли и концерты.
Перед тем как впервые воспользоваться услугами кассы клиент должен зарегистрироваться. В ходе регистрации он указывает данные о себе (ф. и. о., телефон, адрес электронной почты) и получает логин и пароль (логины и пароли разных клиентов не должны совпадать).
Войдя в систему, клиент может ознакомиться с афишей, выбрать интересующее его мероприятие, указав название, дату и место проведения. Получив от системы сведения о билетах имеющихся в наличии, пользователь может забронировать нужное ему количество билетов. Билеты бывают разных типов: партер, балкон, ложа, бельэтаж, 1-2-3 ярус, vip-места и т. п. Цена билета зависит от его типа и расположения зрительского места. Билеты могут быть выкуплены в течение трех суток с момента бронирования, но не позднее пяти суток до начала спектакля. Клиент может самостоятельно выкупить забронированные билеты, приехав в офис, или заказать доставку билетов курьером, сделав пометку в заявке и указав адрес доставки. Стоимость доставки зависит от дальности: центр / спальный район / дальний пригород. Клиент может получить информацию обо всех своих заявках с web-страницы онлайновой кассы.
Заявки клиентов хранятся в системе. В каждой указаны: сведения о клиенте, название спектакля, место и время проведения, количество и тип забронированных билетов, стоимость билетов, время создания заявки, время оплаты, вид доставки (самовывоз / курьер), адрес доставки, стоимость доставки, статус заявки (новая / рабочая / оплаченная / аннулированная). По истечении 12 месяцев с момента создания заявки данные автоматически удаляются из системы.
В обязанности работников онлайновой кассы входит внесение в систему сведений о мероприятиях и об имеющихся в продаже билетах. Данные о мероприятии – вид: концерт / шоу / спектакль; название; описание; место проведения; дата; – хранятся в системе. Один и тот же спектакль может идти в разные дни и в разных местах, но разные спектакли не могут пересекаться по времени и месту проведения. Запись о билете содержит название спектакля, дату, время, место проведения, тип билета, ряд и место, цену билета, статус билета (есть в наличии / забронирован / продан / передан для реализации). По истечении 12 месяцев с даты, указанной в билете, данные автоматически удаляются из системы.
Работник кассы, получив новую заявку клиента, связывается с ним для подтверждения и уточнения мест. Согласовав с клиентом места, работник делает пометку о бронировании билетов в системе (тем самым уменьшается количество билетов, имеющихся в наличии) и меняет статус заявки на "рабочая". После оплаты и/или доставки "рабочей" заявки билеты из заявки помечаются как проданные, а заявка – как оплаченная. За 5 суток до начала спектакля все не проданные билеты передаются для реализации в обычные кассы, в системе они автоматически помечаются как "передан для реализации", заявки на них аннулируются, клиенты, не успевшие оплатить заказанные билеты, информируются о снятии брони. Через 4 суток после создания "рабочие" заявки автоматически аннулируются, бронирование с билетов снимается, клиентам посылается соответствующее сообщение. Также должна быть возможность аннулирования заявок вручную работниками онлайновой кассы. При аннулировании заявки вручную работник должен уведомить клиента, изменить статус заявки, снять бронирование билетов (количество билетов в наличии возрастает).


В каждом из предложенных вариантов требуется построить модель программного обеспечения в среде TopCased. Процесс создания модели состоит из нескольких этапов:
Составление глоссария проекта.
Создание модели вариантов использования.
Анализ вариантов использования (по окончании производится промежуточная сдача задания).
Проектирование системы.
Процесс создания модели должен проходить так, как это описано в методическом пособии (см. TopCased) Структура модели должна соответствовать структуре, предусмотренной Rational Unified Process.
После выполнения третьего этапа модель должна удовлетворять перечисленным ниже требованиям. Глоссарий проекта должен иметь вид таблицы и храниться в отдельном файле. Каждое действующее лицо (actor) и вариант использования должны сопровождаться описанием. Описание действующего лица должно коротко (в одну-две строки) сообщать о роли данного лица. Описание варианта использования должно включать в себя краткое описание, предусловие, потоки событий (основной и альтернативные -- один или более) и постусловие. Все описания действующих лиц и вариантов использования следует собрать в один текстовый файл. Описания должны быть составлены на русском языке. Для одного из вариантов использования должна быть составлена диаграмма деятельности, моделирующая его основной поток и альтернативные потоки. В Analysis Model следует создать диаграмму KeyAbstractions, на которой отображены все классы -- ключевые абстракции и связи между ними. Следует создать пакет, названный Usecase realizations внутри Analysis Model. В этом пакете следует для каждого варианта использования создать кооперацию с диаграммами последовательности, реализующими вариант использования, а также диаграмму классов View of Participating Classes с классами анализа, участвующими в реализации варианта использования. Все классы анализа следует разместить в пакете Analysis Model (на верхнем уровне). В Analysis Model следует создать диаграмму Main, на которой отображены все классы анализа и все связи между ними. Все созданные диаграммы должны содержать необходимые пояснения в виде примечаний. В сложных потоках событий ветвления и циклы должны быть промоделированы с помощью блоков на диаграммах последовательности.
В ходе работы рекомендуется перед переходом к анализу вариантов использования согласовать модель вариантов использования с преподавателем.
При проектировании системы (4й этап) требуется:
Разбить систему на уровни.
Создать структуру пакетов внутри Design model, как это описано в методичке.
Разработать диаграмму размещения, в зависимости от варианта задания диаграмма размещения должна показывать расположение процессов системы в вычислительной среде или связи между процессором и устройствами.
Разместить классы по пакетам в Design model, как это описано в методичке и рассказано в лекциях.
Рассмотреть возможность выделения подсистемы, в частности, в большинстве вариантов предусмотрена работа с устойчивыми объектами, её следует поручить системе обеспечения устойчивости (взаимодействия с БД).
Создать интерфейс подсистемы, дать полные сигнатуры его операциям. Описание интерфейса поместить в текстовый файл, где указать краткое описание (ответственность подсистемы) и таблицу с описанием операций (полная сигнатура, описание).
Для подсистемы создать класс-фасад и другие классы подсистемы, связи между подсистемой и другими частями системы показать на отдельной диаграмме классов, связи между классами подсистемы показать на еще одной диаграмме классов, создать диаграммы последовательности для описания реализации операций интерфейса подсистемы.
Изменить реализации вариантов использования, указав на них «экземпляры» интерфейсов подсистем.
Уточнить связи между классами системы, заменяя ассоциации на агрегации и композиции или зависимости.
Уточнить типы атрибутов классов и дать полные сигнатуры операциям классов.
Каждый класс снабдить описанием, помещенном общий текстовый файл, где ранее описан интерфейс подсистемы, которое должно включать в себя краткое описание (ответственность класса), описание атрибутов в виде таблицы (имя, тип, описание), таблицу с описанием операций (полная сигнатура, описание).
Для описания поведения экземпляров отдельных классов со сложным поведением построить диаграммы состояний (в модели должна быть хотя бы одна нетривиальная диаграмма состояний).
Построить диаграммы деятельности для моделирования сложных методов с альтернативами и/или циклами (в проектной модели должна быть хотя бы одна нетривиальная диаграмма деятельности).
Разработать схему базы данных и отобразить ее на диаграмме классов (во всех вариантах, кроме 5, 18).