Файл: Моделирование предметной области «Организация концертов музыкальной группы с помощью UML (Описание предметной области. Постановка задачи).pdf

Диаграмма вариантов использования (диаграмма прецедентов, use casediagram) — это одна из диаграмм, на которой показываются взаимоотношения между актерами, и вариантами использования.[2]

На данном этапе мы отразим перечень функций всех действующих лиц. (Рисунок 1.).

Используя данную диаграмму мы можем:

Назначить совместные границы и контекст моделируемой предметной области при первоначальных периодах проектирования информационной системы;
Выразить совместные требования к функциональному поведению разрабатываемой системы;
Разработать отправную концептуальную модель информационной системы для ее последующей дефрагментации в форме логических и физических моделей;
Разработать исходную документацию для согласования разработчиков системы с ее заказчиками и пользователями.

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

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

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

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

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

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

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

На следующем этапе проектирования проводиться составной анализ частей проекта. Диаграмма последовательности создается для каждого варианта использования, но в данном случае буду представлены только две, остальные, будем считать, делаются по аналогии. Это диаграмма, которая показывает взаимодействия объектов в хронологическом порядке, что позволяет более детально понять, как взаимодействуют объекты в рамках одного варианта использования (Рисунок 2).

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

На данной диаграмме появляется линия жизни объекта, а также события упорядочены по времени [4] (См. Рисунок 2). То есть объект может появляться после определенного события, или наоборот, уничтожаться.

Рисунок 2 - Диаграмма последовательности

Посетитель запрашивает интересующую его информацию о номерных билетах и концертах у кассира концертного зала;
Кассир концертного зала обращается за получением информации, интересующую посетителя, в информационную систему по всем номерным билетам и проходящим концерте в данном концертном зале;
Информационная система выдает запрашиваемую информацию кассиру концертного зала;
Кассир концертного зала передает информацию полученную от информационной системы посетителю;
Получивши надобную информацию от кассира концертного зала, посетитель принимает решение о покупке номерного билета;
Получивши надобную информацию от кассира концертного зала, посетитель принимает для себя решение об отказе покупать номерной билет;
Приняв решение совершить покупку, посетитель производит процедуру прямой покупки, обратившись к кассиру концертного зала;
Приняв решение совершить покупку, посетитель производит процедуру бронирования номерной билета.обратившись к кассиру концертного зала;
Кассир концертного зала проводит в информационной системе процедуру бронирования билета посетителем;
После внесения информации о бронирование в информационной системе происходит оплата номерного билета через кассу концертного зала, в удобное для посетителя время;
Совершается оплата в кассе концертного зала номерного билета при прямой покупке, либо при выкупе брони, через кассу, касса выдает чек о произведении оплаты;
После оплаты стоимости номерного билета, кассир концертного зала выдает посетителю купленный им номерной билет.

2.2.3 Моделирование диаграммы кооперации

Рисунок 3 - Диаграмма кооперации

Диаграмма кооперации строится на основе диаграммы последовательности и является ее зеркальным отражением.

2.2.4 Диаграмма состояний

Рисунок 4 - Диаграмма состояний Номерные билеты

Номерные билеты считаются поступившими в билетную кассу, тогда когда они поступили в кассу и приходовались кассиром концертного зала. Номерные билеты могут иметь в два состояния: забронированные и реализованные.

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

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

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

Также, как и диаграмма состояний, диаграмма деятельности имеет начальное событие (См. Рисунок 6), которое символизирует начало процесса. Далее начинается сам процесс, который указан в диаграмме.

После завершения обслуживания, работа системы прекращается.

Рисунок 5 - Диаграмма деятельности

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

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

Диаграмма классов представляет собой часть логической модели информационной системы и препровождает статическую картину системы. В каждой информационной системе строится не одна, а несколько диаграмм классов: возможно, что для каждого прецедента или сценария своя.[4]

На данных диаграммах представляют подмножества классов, которые объединены в пакеты, и отношения между ними, на других диаграммах – отображают те же подмножества, но с атрибутами и операциями классов.

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

Объект – это некоторая сущность реального мира или концептуальная (абстрактная) сущность.

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

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

Некоторые возможные классы будут выявлены при рассмотрении трех стереотипов: сущность (entity), граница (boundary) и управление (control).

Создадимдиаграмму классовдля работы системы, на которой отображаютсявсе классы, атрибуты и связимежду ними рисунок 6.

Рисунок 6 - Диаграмма классов информационной системы

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

Klass «Consert-zal» включает в себя такие Attributes:

Code_Consert-zal

Title_Consert-zal

Type_Consert-zal

Theater_director

And operations:

Add (+)

Update (+)

Delete (+)

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

KlassConsertотображает перечень всех концертов в концертных залах и включает следующиеAttributes:

Kod_Consert

Nazvanye_Consert

Vyd_aktera

Postanovschyk

And operations:этогоKlass :

Toopenthe (+)

Close (+)

Change (+)

KlassAfisha зависит от Klassspektaklya.

Attributes класса Afisha:

1. Kod_Conser

2. Kod_Consert-zal

3. Data_Consert

And operations:

Add (+)

Delete (+)

Puttingthe (+)

KlassNomernыeTickets содержит все номерные билеты на все концерты и включает следующие Attributes:

1. Kod_ licenseticket

2. Data_realyzatsyyticket

3. Tsena_byleta

And operations:данногоKlass:

1. Indetail

2. Cancel

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

1. Kod_sotrudnyka

2. Surename

3. Name

4. Otchestvo

And operations:

1. Accept (+)

2. Change (+)

3. humidif (+)

KlassGenre. Attributes:

1. Kod_zhanra

2. Title

3. Description

And operations:

1. Add (+)

2. Delete (+)

3. Refresh (+)

Разработанная диаграмма классов представляет собой это набор статических, а также декларативных элементов модели.

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

Информация с диаграммы классов мы напрямую преобразовываем в исходный код приложения – во всех существующих инструментов используемых для UML-моделирования предоставлена возможность генерации кода для выбранного языка программирования (обычно Java или C++). Следовательно, диаграмма классов - являет собой конечный результат проектирования системы и будет отправной точкой процесса ее разработки.

2.2.7 Моделирование диаграммы компонентов

Созданная диаграмма будет включать в себя 7 компонентов рисунок 7.

Рисунок 7 - Диаграмма компонентов ИС «Организация концертов»

Созданная диаграмма будет включать в себя 7 компонентов.

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

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

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

Спроектированный компонент БД номерных билетов – содержит в себе всю информацию о номерных билетах.

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