Полная версия

Главная arrow Информатика arrow Автоматизированная информационная система отеля

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ   >>

Требования к видам обеспечения

К информационному обеспечению системы

Уровень хранения данных в системе должен быть построен на платформе СУБД MS SQL Server. Данные системы хранятся на одной локальной машине.

Требования к программному обеспечению системы

Система должна работать в операционных системах WindowsXP/Vista/7

Требования к техническому обеспечению системы

В комплекс технических средств должны входить следующие элементы:

  • - рабочие станции;
  • - источник бесперебойного питания;
  • - среда передачи данных между рабочими станциями (например, витая пара UTP 5e);
  • - принтер.

Технические средства приобретаются Заказчиком самостоятельно.

Рабочие станции должны иметь характеристики не ниже указанных:

Процессор IntelPentiumIV 1.8 ГГц и выше, оперативная память не менее 1Гб, объем жесткого диска не менее 200 Гбайт.

5 Стадии и этапы разработки

Основные этапы разработки ИС КС по ГОСТ 34.601-90

Разработка технического задания на систему: октябрь 2014 г.

Технический проект: январь 2015 г.

Разработка и адаптация ПО АИС «Спецификации»: апрель 2015 г.

Разработка эксплуатационной документации: май 2015 г.

Проведение приемочных испытаний: июль 2015 г.

Сопровождение АИС «Отель»

Исполнитель: Коробицын А. В.

Описание потоков данных и бизнес процессов

Моделирование бизнес-процессов.

Бизнес-процесс -- это совокупность взаимосвязанных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей. Моделирование бизнес-процессов - деятельность по формированию моделей организаций, включающая описание деловых объектов (подразделений, должностей, ресурсов, ролей, процессов, операций, информационных систем, носителей информации и т. д.) и указание связей между ними.Функциональное моделирование бизнес-процессов представлено методологией IDEF0. Она описывает те деловые процессы, которые протекают в объекте автоматизации.Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в IDEF0 представлена совокупностью иерархически упорядоченных и логически связанных диаграмм. Каждая диаграмма располагается на отдельном листе. Построение модели ИС начинается с описания функционирования предприятия (системы) в целом в виде контекстной диаграммы. На Рис. 1 представлена контекстная диаграмма АИС «Отель»:

Контекстная диаграмма IDEF0. Функционирование отеля

Рис. 1Контекстная диаграмма IDEF0. Функционирование отеля

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

“Клиенты” - те, для кого гостиница работает. Они платят гостинице деньги в качестве платы за оказываемые услуги. Получение прибыли - цель коммерческой деятельности. Значит, чтобы добиться этой цели гостиница должна оказать услуги клиентам.

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

В оказании услуг принимает участие “Персонал” отеля. Чтобы предоставить номера и получить прибыль, в деятельности отеля должны участвовать “Помещение” и “Материальная база” - обстановка здания, техника в номерах, инвентарь и т.д.

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

Диаграмма декомпозиции IDEF0. Функционирование отеля

Рис. 2 Диаграмма декомпозиции IDEF0. Функционирование отеля.

Весь процесс “Функционирования отеля” разбивается 2:

  • 1) “Предоставление номеров” иллюстрирует деятельность сдачи номеров с предварительной регистрацией;
  • 2) “Обслуживание номеров” представляет собой процесс поддержания персоналом отеля порядка в номерах;

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

Диаграмма декомпозиции IDEF0. Предоставление номеров

Рис. 3 Диаграмма декомпозиции IDEF0. Предоставление номеров.

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

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

Диаграмма потоков данных

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

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

  • 1) “Клиента” и ”Персонал ” - это внешние ссылки, источник данных из вне модели.
  • 2) “Устав гостиницы” и ”Данные о номерах отеля” - хранилища данных.

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

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

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

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

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

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

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

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

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

  • 3) “Клиента” и ”Персонал ” - это внешние ссылки, источник данных из вне модели.
  • 4) “Устав отеля” , “Документы клиенты” (паспорт в бумажном виде или другой удостоверяющий личность документ), ”Законы РФ”, ”Данные о номерах отеля” - хранилища данных.

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

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

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

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

Построение ER-диаграммы

Для хранения данных в информационной системе используется реляционная база данных под управлением СУБДMS SQL Server. Концептуальная схема структуры информационной базы приведена на рис. 7.

информационный отель данные резервирование

ER-диаграмма

Рис. 7 ER-диаграмма

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

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

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

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

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

 
Перейти к загрузке файла
<<   СОДЕРЖАНИЕ   >>