Построение модели гастиницы с использованием графических и математических методологий

CASE – средства. Сравнение и выбор.

Case-средства

Моделирование работы информационной системы особенно важно на первых этапах её создания. Так как исправление  допущенных на этом этапе ошибок обходится  наиболее дорого, то и польза на этапе  анализа задачи и разработки логической модели её решения значительна.

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

CASE - это инструментарий для системных аналитиков, разработчиков и программистов. Они позволяют получить описание работы создаваемой системы раньше, чем ее построили. Затем с их помощью можно анализировать работу системы и оптимизировать подготавливаемые решения. С помощью CASE-инструментария создаются аналитические схемы, которые не только показывают понимание требований заказчика, но и заставляют понять всю глубину разрабатываемой системы, обнаружить пропущенные детали.

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

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

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

• локальные, поддерживающие один-два типа моделей и методов
• малые интегрированные средства моделирования, поддерживающие несколько типов моделей и методов (ERwin, BPwin);
• средние интегрированные средства моделирования, поддерживающие от 4 до 10—15 типов моделей и методов (Rational Rose, Paradigm Plus, Designer/2000);
• крупные интегрированные средства моделирования, поддерживающиеболее 15 типов моделей и методов (ARIS Toolset).

Сравнение CASE-средств

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

Microsoft Visio 2007. Это наиболее простое и доступное средство моделирования. Данный продукт имеет стандартные, привычные всем панели управлении в стиле MS Office и легко интегрируется с любыми приложениями этого пакета, что упрощает работу с ним для неопытных пользователей.

CASE-средство Microsoft Visio 2007 поставляется в комплекте с базовым пакетом Microsoft Office и не требует дополнительных затрат на приобретение. Помимо этого данный продукт поддерживает все виды диаграмм языка UML.

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

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

Из существующих CASE-средств, ориентированных на построение моделей по методологии IDEF0, BPwin является наиболее известным и распространенным, а удобный интерфейс пользователя облегчает работу с программой

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

 

 

 

 

 

 

 

 

Таблица 1

Сравнительный анализ CASE-средств

Параметры сравнения	Microsoft Visio 2007	BPwin
Платформа	Windows	Windows
Системные требования	Процессор не менее 600 МГц; ОЗУ от 256 Мб; Свободное дисковое пространство 300 Мб.	Процессор не менее 500 МГц; ОЗУ от 256 Мб; Свободное дисковое пространство 100 Мб.
Поддержка методологий	UML 2.0,	IDEF0, DFD, IDEF3
Удобство в работе	Удобный и эргономичный интерфейс  MS Office, наличие справки	Интуитивно понятный интерфейс, наличие справки
Доступность	Широко распространенное средство, относительно небольшая цена	Широко распространенное средство.

 

 

 

 

 

 

 

 

Функциональная  модель предметной области

Навигатор модели – Model Explorer

Диаграммы функциональной декомпозиции

Контекстная диаграмма

На контекстной диаграмме  мы видим самое общее описание системы и ее взаимодействие с  внешней средой

Диаграмма декомпозиции А0

На данной диаграмме мы видим первый уровень декомпозиции нашей системы. 6 основных функций и их взаимодействие друг с другом и внешней средой.

Диаграмма декомпозиции блока А1

При декомпозиции блока «  Предоставление номеров» получаются 5 основных функций: бронирование номеров, регистрация гостя, приём оплаты, администрирование ключей и оформление выезда.

Диаграмма декомпозиции блока А2

На диаграмме А2 отражено то, что функция обслуживание номеров делится на 4 более мелких: оказание услуг связи, уборка номера, стирка белья и доставка пищи в номер.

 

Декомпозиция  блока А21

Блок А21 ещё больше детализирует функциональный блок А2. А именно на нём мы можем видеть что функция  «Оказание услуг связи» состоит  из 4 более мелких.

Декомпозиция  блока А4

При декомпозиции блока А 4 мы видим процесс ведения бухгалтерии  в нашей гостинице.

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

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

 

Диаграммы  IDEF3

Эта диаграмма описывает  сценарий бизнес-процесса «Проверка  счетов»

 

 

 

Математическая  модель

В качестве математической модели используем формализацию системы  с помощью СМО.

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

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

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

«Recepcion»представляет собой СМО с одним каналом обслуживания.

Наиболее загруженная  работа отеля наблюдается во время  летне-осеннего сезона. Когда в гостинице  постоянно проживает 100-120%  от вместимости, то есть – 500-600 человек. В остальные сезоны загруженность не высока, поток заявок средний и работы 1 администратора хватает, поэтому их не будем рассматривать подробно. Во время летне-осеннего сезона в среднем в день поступает около 100 заявок на оказание услуг.

Смоделируем данную ситуацию при потоке заявок в 100 штук. Но так  как заявки поступают не сразу, а  в течение дня(будем считать  рабочий день с 8 до 22), то пусть в  час поступает среднее значение заявок, то есть 100/14=7  заявок в час.

Поток заявок от клиентов, поступающих  к администратору имеет интенсивность  λ=7 (7 заявок в час). Процесс выполнения услуги или регистрации продолжается в среднем 25 минут = 0.42 часа. В связи с тем, что у нас безотказная СМО, вероятность отказа Р_отк = 0 . на рисунке 3 представлен граф состояний СМО в СПиР.

Рис.3 Граф состояний одноканальной СМО в службе приёма и размещения

 

Для удобства представления  характеристик одноканальной СМО, можем свести данные в таблицу. В  этой таблице укажем все необходимые  нам характеристики.

Таблица 1.

Характеристики одноканальной  СМО СПиР.

Обозначение	Физический  смысл	Формула для вычисления	Результат измерения	Размерность
λ	Интенсивность поступления потока заявок от клиентов	Задана  самостоятельно	7	заявок/час
μ	Интенсивность обслуживания заявок	μ =	2.38	заявок /час
tобс	Время обслуживания одной заявки	Задана  самостоятельно	0.42	Часы
Ротк	Вероятность отказа обслуживания заявки	Задана  самостоятельно	0
ρ	Количество  обслуженных заявок в единицу  времени	ρ =	2.9	заявок
q	Относительная пропускная способность системы  обслуживания	q = 1 – Pотк	1	заявок
А	Абсолютная  пропускная способность – среднее  число заявок, которое может обслужить  система обслуживания в единицу  времени	A = λ*q	7	заявок
r	Среднее число заявок в очереди	r = ρ2/(1 – ρ), при ρ<1 и r = ρ2/(ρ – 1), при ρ>1	4.42	заявок
k	Среднее число заявок в системе	k = r + ρ	7.32	заявок
tож	Среднее время ожидания заявки в очереди	tож = ρ/μ*( ρ – 1) = ρ2/λ*( ρ – 1)	0.64	Часы
tсмо	Среднее время пребывания заявки в СМО (включая время ожидания и  время обслуживания)	tсмо = tож + tобс	1.056	Часы

В итоге, посчитав характеристики, мы можем проанализировать полученные данные и увидеть, что среднее время ожидания на обслуживание составляет  чуть меньше 40 минут, а все время нахождения заявки в ожидании – немного больше часа. Среднее число клиентов, ожидающих выполнения из заявки-7. В гостиничном  бизнесе очень важно, чтобы клиент был доволен качеством и скоростью обслуживания его желаний, поэтому необходимо максимально сократить неудобства, связанные с ожиданием выполнения заявки. К тому же, иногда поступают заявки, требующие немедленного реагирования. Чтобы сократить очередь заявок и ускорить прохождение процесса их обработки, следует пересмотреть работу системы и провести реинжиниринг.

Реинжиниринг

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

• увеличения количества администраторов;
• применения интернет технологий, для заказа номеров.

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

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