Добавлен: 27.04.2024
Просмотров: 306
Скачиваний: 18
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Изм.
У
Лист
№ докум.
Подпись Дата
Лист
34
КР-02069964-43.04.01-08-22 6. Поучив необходимую информацию от кассира, клиент принимает решение не покупать билет;
7. Решив совершить покупку клиент производит процедуру прямой покупки обратившись к кассиру;
Кассир проводит в базе данных процедуру прямой покупки билета клиентом;
После внесения информации о покупке билета в базу данных происходит оплата билета через кассу.
Рисунок 9 – Диаграмма последовательности
8. Решив совершить покупку клиент производит процедуру бронирования билета обратившись к кассиру;
Кассир проводит в базе данных процедуру бронирования билета клиентом;
После внесения информации о бронирование в базу данных происходит оплата билета через кассу, в удобное для клиента время;
9. Происходит оплата билета при прямой покупке, либо при выкупе брони,
Изм.
У
Лист
№ докум.
Подпись Дата
Лист
35
КР-02069964-43.04.01-08-22 через кассу, касса выдает чек о произведении оплаты;
10. После оплаты стоимости билета, кассир выдает клиенту, купленный им билет.
Рисунок 10 – Диаграмма кооперации
5.3 Построение диаграммы активностей
Диаграмма активностей (видов деятельности) – отражает динамические аспекты поведения системы, то есть отображает потоки работ во взаимосвязанных вариантах использования. По существу, эта диаграмма представляет собой блок – схему, которая наглядно показывает, как поток управления переходит от одной деятельности к другой.
Диаграммы деятельности позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних действий и деятельности. Разработка диаграммы деятельности необходима:
– для детализации особенностей алгоритмической и логической реализации выполняемых системой операций прецедентов;
– выделение последовательных и параллельных потоков управления;
– подготовки детальной документации для взаимодействия разработчиков системы с ее заказчиками и проектировщиками.
Диаграмма активности представляется в виде графа деятельности,
Изм.
У
Лист
№ докум.
Подпись Дата
Лист
36
КР-02069964-43.04.01-08-22 вершинами которого являются состояния деятельности, а дуги показывают переходы от одного состояния деятельности к другому [16].
Рисунок 11– Диаграмма деятельности
Рисунок 12 – Диаграмма состояний Билеты
Клиенту, пришедшему в кассу, выдается информация о спектаклях, уточняется информация о билетах. Далее у клиента есть варианты: если его что- то не устраивает, то он может уйти, либо, если информация о билетах его устроила, то может совершить операцию покупки, которая, в свою очередь,
Изм.
У
Лист
№ докум.
Подпись Дата
Лист
37
КР-02069964-43.04.01-08-22 также имеет 2 варианта: клиент может забронировать, интересующий его билет, либо сразу купить. Если клиент принимает решение забронировать, то ему позже
(в оговоренные сроки) необходимо будет произвести выкуп брони и оплатить билет.
5.4 Построение диаграммы классов
Диаграмма классов - статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами. Это один из наиболее часто используемых видов диаграмм UML. Обычно создание диаграммы классов знаменует собой окончание процесса анализа и начало процесса проектирования.
Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области [4].
Для создания диаграммы классов модели требуется выполнить следующие действия:
Маркируем в левом верхнем углу вкладку «Diagrams» и через кнопку
«Add class diagram» создаем в главном окне новую диаграмму классов, имя которой будет «Диаграмма классов».
Перетаскиваем мышью из браузера классы в окно диаграммы классов.
Затем выделим один из классов, например, «T_arend». Далее, при помощи контекстного меню зайдем в свойство класса Diagram properties и перейдем на вкладку Symbol style. В раскрывающемся списке Member list style выберем значение Auto Member list.
Необходимые атрибуты и методы классов определяются на основе анализа диаграмм последовательностей. Для включения их в класс воспользуемся кнопками просмотрщика интерфейса классов, находящегося в нижнем левом углу окна. Кнопка Add Property открывает диалоговое окно создания в классе нового свойства.
Изм.
У
Лист
№ докум.
Подпись Дата
Лист
38
КР-02069964-43.04.01-08-22
Рисунок 13 – Диаграмма классов
В этой диаграмме классов представлены основные элементы предметной области, а также их атрибуты и операции.
Класс Театр включает в себя следующие атрибуты:
Код театра
Название театра
Вид театра
Директор театра
И операции:
Добавить()
Обновить()
Удалить()
Данный класс необходим для описания общих сведений о театрах, которые предлагают свои билеты на продажу.
Класс Спектакль отражает перечень всех спектаклей во всех театрах и включает атрибуты:
Код спектакля
Название спектакля
Вид актера
Изм.
У
Лист
№ докум.
Подпись Дата
Лист
39
КР-02069964-43.04.01-08-22
Постановщик
И операции этого класса:
Открыть()
Закрыть()
Изменить()
Класс Афиша зависит от класса Спектакль. Атрибуты класса Афиша:
Код спектакля
Код театра
Дата
Операции:
Добавить()
Удалить()
Убрать()
Класс Билеты содержит все билеты на все спектакли и включает следующие атрибуты:
Код билета
Дата
Цена
Операции данного класса:
Заказать
Отменить
Также в нашей базе данных имеются данные о всех сотрудниках театра именно это отражает класс Сотрудники. Атрибуты:
Код сотрудника
Фамилия
Имя
Отчество
Операции:
Принять()
Изменить()
Изм.
У
Лист
№ докум.
Подпись Дата
Лист
40
КР-02069964-43.04.01-08-22
Уволить()
Класс Жанр. Атрибуты:
Код жанра
Название
Описание
Описание:
Добавить ()
Удалить ()
Обновить ()
5.5 Создание базы данных
Одним из важных этапов проектирования реляционных баз данных является построение диаграммы «сущность-связь». Диаграмма показывает зависимости сущностей базы данных. Для получения диаграммы сущность связь в CASE-средстве Rational Rose мы используем «Data Modeler».
Данная система непосредственно предназначена для театров, а именно для их билетных касс. Различные люди каждый день ходят на театральные спектакли, посещают балеты и многие другие культурные мероприятия. Но чтобы попасть на них, ему необходим билет. Именно для этого и созданы кассы, они открывают мир искусства человеку, а театр и актеры показывают его.
Основными понятиями ER-диаграммы являются сущность, связь и атрибут. Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности.
Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. В нашей диаграмме сущностями являются: театр, спектакль, билет, афиша, жанр, сотрудник, вид. Причем вид и жанр играют в системе роль справочника. Это сделано для того, чтобы не загромождать и без этого большие таблицы «театр» и «спектакль».
Изм.
У
Лист
№ докум.
Подпись Дата
Лист
41
КР-02069964-43.04.01-08-22
Для большей выразительности и лучшего понимания, имя сущности может сопровождаться примерами конкретных объектов этого типа. Например, сущность театры: Драматический, Современник, Оперы и балета, Юного зрителя.
Рисунок 14 – Диаграмма баз данных
Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности.
Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности. Например сущность «Билет» содержит следующие атрибуты: место, цена, дата продажи, продан (логическое да или нет), бронь(логическое да или нет).
Сущность «Театр» содержит другие атрибуты: название, адрес, директор, телефон, количество мест в партере, количество мест в амфитеатре, количество мест на балконе, вид театра.
Ключ сущности - это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности.
Неизбыточность заключается в том, что удаление любого атрибута из ключа нарушается его уникальность. Сущность может иметь несколько различных ключей.
Изм.
У
Лист
№ докум.
Подпись Дата
Лист
42
КР-02069964-43.04.01-08-22
К примеру, у сущности «Театр» ключом является idТеатра, сущность
«Спектакль» имеет ключ idСпектакля, сущности «Билет» и «Жанр»- idБилет и idЖанр, и т.д..
Теперь что касаемо связей, связь - это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою. Связи позволяют по одной сущности находить другие сущности, связанные с нею.
Связь типа один-к-одному означает, что один экземпляр первой сущности связан с одним экземпляром второй сущности. Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две. В нашей ER-диаграмме данный тип связи отсутствует.
Связь типа один-ко-многим означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности. Это наиболее часто используемый тип связи. В ER-диаграмме театральной билетной кассы все связи между сущностями относятся именно к этому тип.
Посмотрите сами, связь между сущностями «Театр» и «Спектакль» один- ко-многим, так как в одном театре может проходить несколько спектаклей.
Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности.
Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.
5.6 Построение диаграммы компонентов
Диаграмма компонентов – это один из двух видов диаграмм, используемых при моделировании физических аспектов объектно-ориентированной системы.
Изм.
У
Лист
№ докум.
Подпись Дата
Лист
43
КР-02069964-43.04.01-08-22
На ней изображено разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. С помощью диаграммы компонентов представляются инкапсулированные классы вместе с их интерфейсными оболочками, портами и внутренними структурами (которые тоже могут состоять из компонентов и коннекторов). Компоненты связываются через зависимости, когда соединяется требуемый интерфейс одного компонента с имеющимся интерфейсом другого компонента. Таким образом, иллюстрируются отношения клиент-источник между двумя компонентами [16].
Рисунок 15 – Диаграмма компонентов
Данная диаграмма включает в себя 7 компонентов.
Компонент Головной модуль – является главным, служит для выдачи необходимой информации клиенту.
Компонент Справка – связан с компонентом Головной модуль, служит для выдачи необходимой справки клиенту.
Компонент Обработка запроса клиента – служит для обработки запроса клиента, полученного от головного модуля, через него поступает информация в базу данных билетов, базу данных театров, базу данных спектаклей и на экран выводится интересующая клиента информация.
Компонент БД билетов – содержит в себе всю информацию о билетах театров города.
Компонент БД театров - содержит в себе всю информацию о театрах города.
Изм.
У
Лист
№ докум.
Подпись Дата
Лист
44
КР-02069964-43.04.01-08-22
Компонент БД спектаклей - содержит в себе всю информацию о спектаклях в театрах города.
Визуальный компонент, отображающий запрос – позволяет вывести всю информацию о запросе клиента.
1 2 3 4