Введение
Гостиничный бизнес связан с оказанием услуг в сфере гостеприимства и ориентирован главным образом на удовлетворение потребностей туристов, в том числе отдыхающих, прибывающих с деловыми целями и др.
Современный отель должен быть не просто местом для ночлега, но предоставлять клиенту весь комплекс необходимых услуг.
Имитационное моделирование — метод исследования объектов, основанный на том, что изучаемый объект заменяется имитирующим объектом. С имитирующим объектом проводят эксперименты (не прибегая к экспериментам на реальном объекте) и в результате получают информацию об изучаемом объекте. Имитирующий объект при этом являет из себя информационный объект. Обычно имитационные модели строятся для поиска оптимального решения в условиях ограничения по ресурсам, когда другие математические модели оказываются слишком сложными.
Характеристика системы «Отель»:
Основной вид деятельности отеля, это работа с клиентами.
Клиент может сам забронировать номер, заказывать дополнительные услуги и просматривать основную информацию о его поселении через личный кабинет.
Для начала работы администратору необходимо авторизироваться в системе. Для этого необходимо иметь рабочую карту, ведь только с помощью её можно получить доступ к данным отеля.
Администратор принимает клиентов на ресепшен. Клиент может как зарегистрироваться на ресепшен, так и забронировать самостоятельно через личный кабинет. В таком случае администратор должен проверить бронь клиента и провести автоматическую регистрацию по данной брони.
По мере необходимости администратор может добавлять, изменять и просматривать информацию о поселении клиентов, а также основные характеристики номеров. К тому же в его полномочия входит ведение базы данных.
Диаграмма прецедентов
Use case diagram (диаграммы прецедентов) - позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Use case - это описание сценария поведения, которому следуют действующие лица (Actors). Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые.
Исходя из поиска ответов на следующие вопросы:
- кто взаимодействует с системой или использует систему?
- кто передает или принимает информацию в/из системы?
- кто является внешним по отношению к системе?
В данной ситуации существуют следующие субъекты:
Прецедент представляет собой целостный набор функций, имеющих определенную ценность для субъекта. Прецеденты можно вывести в результате определения задач для субъекта. Для этого следует задаться вопросом: "Каковы обязанности субъекта по отношению к системе и чего он ожидает от системы?" Каждый вариант использования (прецедент) определяет набор действий, совершаемых системой при диалоге с актером. При этом ничего не говорится о том, как конкретно будет реализовано взаимодействие актеров с системой и собственно выполнение вариантов использования.
Достоинства модели вариантов использования заключаются в том, что она:
- определяет пользователей и границы системы;
- определяет системный интерфейс;
- удобна для общения пользователей с разработчиками;
- используется для написания тестов;
- является основой для написания пользовательской документации;
- хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные).
Варианты использования и субъекты, выделенные для данной модели, можно представить в виде следующей диаграммы прецедентов:
Диаграмма прецедентов системы " Отель"
Описание потока событий варианта использования
«Заселение клиента по брони»
Основной поток:
1) Активация экрана
2) Запрос авторизации администратора через рабочую карту
3) Авторизация через рабочую карту
4) Авторизация администратора
5) Ввод номера брони
6) Трансляция номера брони
7) Поиск брони по номеру
8) Информация о состоянии брони
9) Запрос на подтверждение регистрации
10) Подтверждение регистрации
11) Обновление данных клиента
12) Сообщение об упешной проверке брони и автоматической регистрации клиента
Альтернативный поток A1:
1) Экран системы не запустился
2) Прекращение действий
Альтернативный поток A2:
1) Авторизация администратора не прошла успешно
2) Прекращение действий
Альтернативный поток A3:
1) Поиск брони по номеру не привел ни к какому к результату
2) Стандартная регистрация
3) Ввод паспортных данных клиента и выбор номера из списка свободных
4) Расчёт
Альтернативный поток A4:
1) Автоматическая регистрация не прошла успешно
2) Прекращение действий.
Диаграмма последовательностей
Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. Чтобы отразить последовательность передачи сообщений между объектами, для каждого прецедента использования может быть построена модель динамического взаимодействия объектов, которая представляется в одной из двух форм:
- в форме диаграммы последовательностей (sequence diagram), на которой основное внимание уделяется временной упорядоченности событий. На них изображают множество объектов и посланные или принятые ими сообщения. Объекты, как правило, представляют собой экземпляры классов.
- в форме диаграммы кооперации (collaboration diagram), которая отражает структурную организацию объектов, принимающих или отправляющих сообщения. На диаграмме кооперации показано множество объектов, связи между ними и сообщения, которые они посылают или получают.
Для диаграммы последовательностиключевым моментом является динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно представлено слева направо в виде линии жизни (lifeline) (период времени существования) отдельного объекта, участвующего во взаимодействии, а второе - вертикальной временной осью, направленной сверху вниз. Взаимодействие объектов реализуется посредством сообщений, посылаемые одними объектами другим. Сообщения появляются в том порядке, в котором они показаны - сверху вниз. Диаграмма последовательности для варианта использования
"Заселение клиента брони"
Для заселение клиента брони администратору необходимо авторизироваться через рабочую карту. По полученным данным о номере брони от клиента администратор должен обратиться к серверу с базой данных, чтобы получить информацию состоянии брони. Если все данные соответствуют регламенту, администратор делает запрос на автоматическую регистрацию клиента в базе данных отеля.
Диаграмма активности
Модели видов деятельности (Activity Diagram) строятся для описания общей последовательности действий для нескольких объектов и вариантов использования. На диаграммах этого типа представляются переходы потока управления от одной деятельности к другой внутри системы. Этот вид диаграмм относится к динамическим представлениям системы, и является наиболее полезным при моделировании ее функционирования, так как отражает передачу потока управления между объектами.
Диаграмма активности предоставляет свободу выбора порядка выполнения. Другими словами, она только устанавливает основные правила последовательности, которым необходимо следовать. Такая возможность важна при моделировании бизнес-процессов. Среди бизнес-процессов нередко встречаются такие, которые не обязаны выполняться последовательно. В таких ситуациях данный метод хорошо работает, так как он позволяет реализовывать процессы параллельно.
Диаграммы активности являются также полезными при параллельном программировании, поскольку можно графически изобразить все ветви и определить, когда их необходимо синхронизировать.
Диаграммы активности можно применять для описания потоков событий в вариантах использования. С помощью текстового описания можно достаточно подробно рассказать о потоке событий, но в сложных и запутанных потоках с множеством альтернативных ветвей будет трудно понять логику событий. Диаграммы активности предоставляют ту же информацию, что и текстовое описание потока событий, но в наглядной графической форме.
Теперь рассмотрим диаграмму активности варианта использоания, построенную для проектируемой системы.
Диаграмма активности варианта использования «Заселение клиента по брони» информационной системы «Отель».
Администратор включает экран и авторизируется в системе. Если проблем не возникло, он проверяет наличие брони, полученной от клиента, в базе данных отеля. Если бронь отсутствует в базе, клиенту будет отказано. Если бронь найдена, то администратор проверяет данные об оплате в полученном из базы данных информационном окне. Далее администратор делает запрос на подтверждение регистрации. Если автоматическая регистрация прошла успешно, то система выдаст сообщение о завершении регистрации
Заключение
В результате проделанной мною работы была спроектирована имитационная модель информационной системы "Отель" с помощью инструмента «PlantUML». Таким образом, поставленная задача была выполнена.