Проектирование информационной системы “Гостиница”

 

Activity Name: Аминистр-ние  ключей 

Activity Definition: Администрирование  ключей  осуществляется в согласии с законом РФ и включает в себя: хранение ключей от номеров, их охрану и выдачу только лично постояльцу в руки. Этот вид деятельности мы не автоматизируем в ходе нашего курсового проектирования.

 

Activity Status: WORKING

Activity Author: ЕфановаЮ.Н.

Object Type: Activity

Activity Number: A14 

 

Activity Name: Оформление выезда

Activity Definition: Оформление  выезда включает в себя   формирование итогового счёта за вычетом предоплат, 

Activity Status: WORKING

Activity Author: ЕфановаЮ.Н.

Object Type: Activity

Activity Number: A15

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

Слабые связи, не представленные на диаграмме высшего уровня:

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

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

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

Ключи от номеров – получаемые при въезде ключи от номера.

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

 

 

 

 

 

 

 

 

Рис. 4 Диаграмма декомпозиции IDEF0. Обслуживание номеров.

Опишем диаграмму, представленную на рис. 4, с помощью отчета, сгенерированного BPwin

Activity Name: Подготовка номеров

Activity Definition: Подготовка  -  это уборка номера перед въездом следующего постояльца.

Activity Status: WORKING

Activity Author: ЕфановаЮ.Н.

Object Type: Activity

Activity Number: A21 

 

Activity Name: Плановое  обслуживание  номеров

Activity Definition: Плановое обслуживание номеров - регулярное обслуживание номеров во время  проживания постояльцев в гостинице.

Activity Status: WORKING

Activity Author: ЕфановаЮ.Н.

Object Type: Activity

Activity Number: A22

Эта диаграмма напоминает контекстную диаграмму (рис. 1). Обе работы (на рис. 4)  не зависят друг от друга и имеют на  входах -  “Клиентов” и ”Плату за услуги”, на выходах -  “Оказанные услуги” и “Прибыль”, на управлении - “Законы РФ” и “Устав гостиницы”, влияющие на всю деятельность гостиницы, и на механизмах –

 

“Материальную базу”, “Помещение”  и “Персонал” –  ресурсы, необходимые для выполнения этих работ).

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

 

 

 

Опишем диаграмму, представленную на рис. 5, с помощью отчета, сгенерированного Bpwin:

Report for Diagram: A3, Обеспечение  телефонных переговоров  

 

Activity Name: Оповещение о  пропущенных  звонках

Activity Definition: Персонал  оповещает постояльца номера  о пропущенных звонках и оставленных  сообщениях. Эту деятельность мы не намерены автоматизировать, поэтому интереса она для нашего курсового проектирования не представляет. 

Activity Status: WORKING

Activity Author: Ефанова Ю.Н.

Object Type: Activity

Activity Number: A31

Эта функция возлагается  на персонал и не автоматизируется в ходе нашего курсового проектирования.

Activity Name: Соединение с  номером

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

Activity Status: WORKING

Activity Author: Ефанова Ю.Н.

Object Type: Activity

Activity Number: A32

Эта услуга осуществляется вне нашего курсового проекта  и предоставляется бесплатно.

Activity Name: Ведение статистики  телефонных  переговоров

Activity Definition: В статистике переговоров  учитывается  количество переговоров постояльца по гостиничному телефону и их тарифы.

Activity Status: WORKING

Activity Author: ЕфановаЮ.Н.

Object Type: Activity

Activity Number: A33

 

 

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

Activity Name: Оплата телефонных  переговоров.

Activity Definition: Оплата телефонных переговоров  по междугородней связи, а также  доплата за пользование телефоном  гостиницы.

Activity Status: WORKING

Activity Author: ЕфановаЮ.Н.

Object Type: Activity

Activity Number: A34

Эта деятельность не автоматизируется нашим клиентским приложением. Оплата переговоров производится при оформлении выезда.

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

Переговоры – данные о времени, номере телефонного звонка.  

 

Рис.  5 Диаграмма декомпозиции IDEF0. Обеспечение телефонных переговоров.

1.2 Дополнение  созданной модели процессов организационными диаграммами

Если в процессе моделирования  нужно осветить специфические стороны  технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель.

1.2.1 Диаграммы  потоков данных (Data Flow Diagramming)

Диаграммы потоков данных (DFD) используются для описания документооборота и обработки информации. Нотация DFD включает такие понятия, как "внешняя ссылка" и "хранилище данных", что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота.

На рис. 6 представлена “Диаграммы декомпозиции в нотации DFD. Резервирование номеров.”, описывающая деятельность по резервированию номеров. На диаграмме представлены:

1)           “Клиента” и ”Персонал ” – это внешние ссылки, источник данных из вне модели.

2)           “Устав гостиницы” и ”Данные о номерах гостиницы” – хранилища данных.

Эти данные хранятся на данный момент в бумажном эквиваленте. Наше клиентское приложение позволит все эти данные хранить в электронном виде и облегчит обновление данных о номерах гостиницы и постояльцах.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис.  6 Диаграммы декомпозиции в нотации DFD. Резервирование номеров.

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Например, “Заказ” в какой-либо форме (телеф. звонок или электрон. письмо на адрес гостиницы), приходит от клиента и инициирует процедуру “Обработки заказа” . Эту процедуру выполняет “Персонал”, в чьи обязанности это входит. Персонал запрашивает “Данные о номерах” из хранилища данных (гостиничный журнал или электрон. БД) и, согласуясь с “Правилами предоставления номеров” (содержащимися в уставе гостиницы ), отказывает клиенту в резервировании номера  или:

ü     резервирует номер;

ü     после “оформления заказа номера” обновляет данные о номерах – заносит “Обновленные данные о номерах” в хранилище “Данных о номерах гостиницы”.

На рис. 7 представлена “Диаграммы декомпозиции в нотации DFD. Оформление поселения.”,  описывающая деятельность по оформлению поселения. На диаграмме представлены:

3)           “Клиента” и ”Персонал ” – это внешние ссылки, источник данных из вне модели.

4)           “Устав гостиницы” , “Документы клиенты” (паспорт в бумажном виде или другой удостоверяющий личность документ), ”Законы РФ”, ”Данные о номерах гостиницы” – хранилища данных.

 

 

 

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

ü                постоялец предъявляет свои “Документы”, выбирает тарифы проживания, проходит регистрацию и получает ключи от номера:

ü                “Персонал” оформляет въезд постояльца и обновляет данные о номерах гостиницы в хранилище “Данных о номерах гостиницы”

Все это “Персонал”  делает, руководствуясь “правилами поселения”, прописанными в “Уставе гостиницы”, и “Законами и постановлениями ” РФ, регламентирующими, например, обязательную идентификацию личности граждан при поселении в гостинице .

Рис.  7 Диаграммы декомпозиции в нотации DFD. Оформление поселения.

1.2.2 Диаграммы  методологии IDEF3 (Workflow Diagramming)

 

            Для описания логики взаимодействия информационных потоков более подходит workflow diagramming (Маклаков С.В. “Создание информационных систем с AllFusion Modeling Suite”). Диаграммы Workflow могут быть использованы в моделировании  бизнес-процессов для анализа завершенности процедур обработки информации.

 

 

На Диаграмме декомпозиции в нотации IDEF3. Проверка счетов. (на рис. 8) иллюстрируется ”Проверка счетов”. Эту деятельность мы почти полностью автоматизируем в нашем клиентском приложении.

Как только счет запрошен, запускаются все последующие  за перекрестком (AND) процессы:

ü     “Формирование счета за тел. переговоры”;

ü     “Формирование счета за услуги”;

ü     запускается “Анализ сроков пребывания” постояльца в гостинице, по окончании которого запускается процесс “Формирования счет за проживание”, учитывающий в своей работе “Результаты анализа”.

“Учет” – это стрелка  отношения (Relational Link). Мы использовали ее  для изображения связи между процессом “Формирования счета за проживание” объектом ссылки “Внесенная предоплата”, учет которого важен для результатов процесса.

Стрелки с двумя наконечниками: “Счет за проживание”, “Счет за тел. переговоры” и “Счет за услуги” – обозначают потоки объектов (Object Flow). В данном случае, мы их применяем  для описания того факта, что эти объекты порождается в одной работе(“Формирование счета…”) и используется в процессе “Формирования итогового счета”.

В ходе курсового проектирования мы автоматизируем работы 2, 3, 4, 5

Рис.  8 Диаграммы декомпозиции в нотации IDEF3. Проверка счетов.

 

 

 

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

На рис. 9 представлено итоговое расположение работ в дереве узлов:

ü      диаграмма “Функционирование гостиницы” – 1-ый уровень дерева узлов (top level activity);

ü      диаграммы “Предоставление номеров”, “обслуживание номеров” и “Обеспечение телефонных переговоров” – 2-ой уровень дерева узлов;

ü      диаграммы “Резервирование номеров”, “Оформление поселения”, “Прием предоплаты”, “Проверка счетов”, “Подготовка номеров” – 3-ий уровень;

ü      диаграммы “Обработка заказа”, “Обновление данных о номерах”, “Обработка запроса”, “Обновление данных” и “Оформление въезда” – 4-ый уровень дерева узлов, последний уровень декомпозиции – необходимая в ходе нашего курсового проектирования степень подробности.

Рис.  9 Диаграмма дерева узлов.

 

Глава II. Создание модели данных с помощью AllFusion Erwin Data Modeler 4.1

Информационная модель в нотации IDEF1X

Для представления информационной модели данных используется CASE-средство ERWin. С его помощью при проектировании модели ИС «Гостиница» была создана физическо-логическая модель базы данных (рис. 10).

Рис.  10 Модель данных в нотации IDEF1X (физический уровень)

БД представлена в виде сущностей, их атрибутов и  связей между ними. Каждая сущность представляет множество подобных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных. Атрибут выражает определенное свойство объекта. С точки зрения физической модели БД сущности соответствует таблица (например, “Резервирование”, “Постоялец”, “Телефонные переговоры”), экземпляру сущности – строка в таблице, а атрибуту – колонка таблицы (например, строка

 

“Код резерва” в таблице “Резервирование”). В  результате проектирования было выделено шесть сущностей.

Связь на диаграмме  отображает логическую зависимость  одной сущности от другой. В IDEF1X различают  зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между  независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Экземпляр зависимой сущности определяется только через отношение к родительской сущности. Зависимая сущность изображается на диаграмме прямоугольником со скругленными углами.

На нашей  диаграмме зависимыми сущностями являются: “Оказанные услуги” и “Резервирование”. Родительскими для них являются сущности “Тариф услуг ” и “Апартамент ” соответственно.

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

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