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

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

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

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

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

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

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

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

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

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

1) “Предоставление номеров” иллюстрирует деятельность сдачи номеров с предварительной регистрацией;

2) “Обслуживание номеров” представляет собой процесс поддержания персоналом отеля порядка в номерах;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

В результате курсового проекта была спроектирована и реализована автоматизированная информационная система «Отель».

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

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

* освобождению работников от рутинной работы за счет ее автоматизации;

* обеспечению достоверности информации;

* замене бумажных носителей данных на магнитные и оптические, что приводит к более рациональной организации переработки информации на компьютере и снижению объемов бумажных документов;

* уменьшению затрат на производство продуктов и услуг.

Список использованной литературы

1. Методическое пособие для курсового проектирования «Проектирование информационной системы», К.А. Паршин, Е.В. Паршина, 2006 г.

2. Маклаков С.В. BPWin и ERWin. CASE - средства разработки информационных систем

Размещено на Allbest.ru