Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Otchet.doc
Скачиваний:
27
Добавлен:
29.10.2018
Размер:
194.56 Кб
Скачать

9

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУК УКРАИНЫ

Государственный университет информатики и искусственного интеллекта

Д 050301.1.01.09/144.РР

Кафедра ПОИС

РАСЧЕТНАЯ РАБОТА

по дисциплине: «Проектный практикум»

Тема: «Онлайновая театральная касса»

должность: программист

Проверили:

__________ асс. В. А. Чепурко

(дата, подпись)

Выполнил:

__________ ст.гр. ПО-О9в Ю.А. Кузнецов

(дата, подпись)

Донецк – 2011

СОДЕРЖАНИЕ

1Описание предметной области ……………………………………………..3

Д050103.1.01.09/144.КП 2

Разработал

Фамилия

Подпись

Дата

Д050103.1.01.09/144.КП

Лист

Ст.гр.ПО-09в

Кузнецов Ю.А.

2

1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

Онлайновая театральная касса "Билетов.Нет" представляет собой web-сайт службы бронирования и доставки билетов на спектакли и концерты.

Перед тем как впервые воспользоваться услугами кассы клиент должен зарегистрироваться. В ходе регистрации он указывает данные о себе (ф. и. о., телефон, адрес электронной почты) и получает логин и пароль (логины и пароли разных клиентов не должны совпадать).

Войдя в систему, клиент может ознакомиться с афишей, выбрать интересующее его мероприятие, указав название, дату и место проведения. Получив от системы сведения о билетах имеющихся в наличии, пользователь может забронировать нужное ему количество билетов. Билеты бывают разных типов: партер, балкон, ложа, бельэтаж, 1-2-3 ярус, vip-места и т. п. Цена билета зависит от его типа и расположения зрительского места. Билеты могут быть выкуплены в течение трех суток с момента бронирования, но не позднее пяти суток до начала спектакля. Клиент может самостоятельно выкупить забронированные билеты, приехав в офис, или заказать доставку билетов курьером, сделав пометку в заявке и указав адрес доставки. Стоимость доставки зависит от дальности: центр / спальный район / дальний пригород. Клиент может получить информацию обо всех своих заявках с web-страницы онлайновой кассы.

Заявки клиентов хранятся в системе. В каждой указаны сведения о клиенте, название спектакля, место и время проведения, количество и тип забронированных билетов, стоимость билетов, время создания заявки, время оплаты, вид доставки (самовывоз / курьер), адрес доставки, стоимость доставки, статус заявки (новая / рабочая / оплаченная / аннулированная). По истечении 12 месяцев с момента создания заявки данные автоматически удаляются из системы.

В обязанности работников онлайновой кассы входит внесение в систему сведений о мероприятиях и об имеющихся в продаже билетах. Данные о мероприятии: вид (концерт / шоу / спектакль), название, описание, место проведения, дата; – хранятся в системе. Один и тот же спектакль может идти в разные дни и в разных местах, но разные спектакли не могут пересекаться по времени и месту проведения. Запись о билете содержит название спектакля, дата, время, место проведения, тип билета, зрительский ряд, зрительское место, цену билета, статус билета (есть в наличии / забронирован / продан / передан для реализации). По истечении 12 месяцев с даты, указанной в билете, данные автоматически удаляются из системы.

Работник кассы, получив новую заявку клиента, связывается с ним для подтверждения и уточнения мест. Согласовав с клиентом зрительские места, работник делает пометку о бронировании билетов в системе (тем самым уменьшается количество билетов, имеющихся в наличии) и меняет статус заявки на "рабочая". После оплаты и/или доставки "рабочей" заявки билеты из заявки помечаются как проданные, а заявка – как оплаченная. За 5 суток до начала спектакля все не проданные билеты передаются для реализации в обычные кассы, в системе они автоматически помечаются как "передан для реализации", заявки на них аннулируются, клиенты, не успевшие оплатить заказанные билеты, информируются о снятии брони. Через 4 суток после создания "рабочие" заявки автоматически аннулируются, бронирование с билетов снимается, клиентам посылается соответствующее сообщение. Также должна быть возможность аннулирования заявок вручную работниками онлайновой кассы. При аннулировании заявки вручную работник должен уведомить клиента, изменить статус заявки, снять бронирование билетов (количество билетов в наличии возрастает).

2 Описание rational rose

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования.

Текущая версия Rational Rose реализует генерацию кодов программ для С++, Visual C++, Visual Basic, Java, PowerBuilder, CORBA Interface Definition Language (IDL), генерацию описаний баз данных для ANSI SQL, Oracle, MS SQL Server, IBM DB2, Sybase, а также позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций.

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

В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (браузер), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ. Rational Rose. Популярное средство визуального моделирования объектно-ориентированных информационных систем компании Rational Software Corp. Работа продукта основана на универсальном языке моделирования UML (Universal Modeling Language). Благодаря уникальному языку моделирования Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования. Только Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое. Только Rational Rose имеет весь необходимый набор визуальных средств проектирования. Только Rose поможет решить проблемы с кодогенерацией на определенном языке программирования. Только Rational Rose осуществляет такие подходы, как прямое и обратное проектирование, а так же Round Trip Engineering. Такой арсенал позволит не только проектировать новую систему, но и доработать старую, произведя процесс обратного проектирования. Для того чтобы наиболее полно покрыть весь сегмент рынка средств проектирования и разработки, компания Rational выпускает несколько версий своего продукта. Каждый из них может решать как строго определенный круг задач, так и весь спектр проблем проектирования и разработки.

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

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.

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

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

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

Также для диаграммы классов выделяются стереотипы классов.

Стереотипы – это механизм, позволяющий разделять классы на категории. В языке UML определены три основных стереотипа классов: Boundary (граница), Entity (сущность) и Control (управление).

Диаграмма классов данной предметной области содержит пять классов: «Клиент», «Афиша», «Заявка», «Работник», «Сайт».

Афиша

-Название мероприятия

-Дата проведения мероприятия

-Вид мероприятия

-Описание мероприятия

-Место проведения мероприятия

+Добавляется()

+Изменяется()

+Просматривается()

1

1

1

1

1

1

N

1…N

1…N

1…N

1…N

1…N

1…N

1…N

Рисунок 3.1 – Диаграмма классов

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]