CASE-средство RationalRose

Программное средство RationalRose, использующее нотацию UML, предназначено для автоматизации этапов анализа и проектирования программного обеспечения, а также для генерации кодов на различных языках и выпуска проектной документации. RationalRose использует синтез-методологию объектно-ориентированного анализа и проектирования. Кроме того, RationalRose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

Преимущества подхода к моделированию бизнес-процессов с помощью UML заключаются в следующем:

· модель бизнес-процессов строится вокруг участников процессов и их целей;

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

CASE-средство Designer/2000

CASE-средство Designer/2000 2.0 фирмы ORACLE является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного ЖЦ ПО для систем, использующих СУБД ORACLE.

Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов. Базовая методология Designer/2000 (CASE*Method) - структурная методология проектирования систем, полностью охватывающая все этапы жизненного цикла ИС.

Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (ApplicationProgrammingInterface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами.

Определение критериев оценки:

1. Моделирование организационных функций и процессов -

· Наличие большого числа стандартных объектов для описания бизнес процессов.

· Наличие инструмента имитационного моделирования.

· Наличие внутреннего языка управления

2. Разработка технического задания -

· Генерация и печать технической документации создаваемого проекта

3. Функционально-стоимостной анализ -

· определение и проведение общего анализа себестоимости бизнес-процессов на предприятии (маркетинг, производство продукции и оказание услуг, сбыт, менеджмент качества, техническое и гарантийное обслуживание и др.);

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

· определение и анализ основных, дополнительных и ненужных функциональных затрат;

· сравнительный анализ альтернативных вариантов снижения затрат в производстве, сбыте и управлении за счет упорядочения функций структурных подразделений предприятия;

· анализ интегрированного улучшения результатов деятельности предприятия.

4. Генерация кода приложения -

· Генерация кода для его применения в разработке приложений на различных языках программирования

5. Оформление проектной документации -

· Наличие генератора для оформления проектной документации

6. Хранение моделей деятельности предприятий -

· История моделей

7. Ведение библиотеки типовых бизнес моделей -

· Наличие репозитория бизнес моделей

8. Генерация отчетов -

· Встроенный генератор отчетов

9. Возможность групповой работы -

· Возможность работы со средством коллективно

Сравнительный анализ программных средств представлен в таблице 2.1.

Таблица 2.1 Сравнительный анализ программных средств

	Фактор важности	BPwin	RationalRose	Designer/2000
		Степень соотв.	Оценка	Степень соотв.	Оценка	Степень соотв.	Оценка
Моделирование организационных функций и процессов	10	100	10	100	10	100	10
Разработка технического задания	8	80	6,4	70	5,6	60	4,8
Функционально-стоимостной анализ	7	100	7	90	6,3	90	6,3
Генерация кода приложения	10	90	9	90	9	80	8
Оформление проектной документации	8	60	4,8	100	8	100	8
Хранение моделей деятельности предприятий	6	100	6	100	6	100	6
Ведение библиотеки типовых бизнес моделей	8	90	7,2	100	8	100	8
Генерация отчетов	7	100	7	100	7	100	7
Возможность групповой работы	8	100	8	100	8	60	4,8
Итоговый балл:		65,4		67,9		62,9

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

1) Для каждого требования, бизнес процесса, функционального направления проставляется «Фактор важности» (максимальный балл равен 10), который показывает важность рассматриваемого требования к системе;

2) Каждое требование оценивается по 100-балльной шкале ("Степень соответствия", то есть это степень реализации требуемой функциональности в системе: насколько функциональность реализована в стандартной поставке);

3) Для каждого требования вычисляется интегральный показатель:

(1)

где E - оценка (балл);

F - фактор важности;

С - степень соответствия

4) Для каждого бизнес-процесса и функционального направления вычисляется общий интегральный показатель (как среднее арифметическое) ("Оценка (балл)") на основании Фактора важности и интегральной Оценки для каждого бизнес-процесса и функционального направления вычисляется степень соответствия ERP-системы требованиям:

(2)

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

Необходимо отметить, что нотация IDEF0/IDEF3, которую использует CASE-средство BPWin, определяет более жесткие правила построения моделей процессов, чем нотация UML, и содержит существенные ограничения на количество объектов и связей, отображаемых на одной диаграмме.

Поэтому окончательным средством для моделирования бизнес процессов будет выбран RationalRose и соответственно методология UML.

2.2 Визуальная модель предметной области

Для наглядного представления процессов, происходящих в описанной предметной области, было произведено ее визуальное моделирование с использованием методологий «Дракон» и UML.

Реализация модели согласно «Дракону» представляет собой блок-схему гостиницы. На первой схеме выделены основные функции отеля: планирование, распределение и контроль работ по отелю (см. рисунок 2.1).

В выполнение функции планирования входят следующие действия:

· Формирование плана загрузки номеров;

· Учет клиентов;

· Учет выполняемых работ.

В выполнение функции распределения входят следующие действия:

· Координация деятельности персонала и служб отеля (обеспечение их согласованной работы);

· Принятие оперативных мер по отклонениям от плана;

· Распределение номеров.

В выполнение функции контроля входит следующее действие:

· Контроль за выполнением плана загрузки;

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

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

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

· вариантов использования;

· последовательности.

Диаграмма прецедентов (рис. 2.3) была разработана для визуализации поведения элементов системы при взаимодействии с сущностями извне. На ней представлена реакция системы на действия 4 актеров:

· Директора;

· Администратора отеля;

· Портье;

· Супервайзера.

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

Диаграмма последовательности (рис. 2.4)составлена для представления последовательности действий в процессе функционирования системы. На ней представлены следующие объекты:

· Портье;

· Супервайзер;

· Администратор отеля;

· Директор отеля.

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

2.3 Математическая модель предметной области

2.3.1 Базовая математическая модель

При построении базовой модели будем исходить из следующих предположений.

Относительно этапа разработки плана считаем, что загрузка каждого номера не зависима от загрузки остальных номеров и для каждого номера (комнаты) задана длительность его загрузки, которая не может быть изменена. Финансированиепроцесса разработки плана загрузки номеров осуществляется равномерно по времени проведения работ.

Считаем, что все работы по размещению клиентов в номерах выполняются однородными нарядами средств независимо и одновременно (параллельно).

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

Для формальной записи задачи с учетом сделанных предположений введем следующие обозначения:

Т = {1 , . . . ,Т} -- множество единичных отрезков, составляющих рассматриваемый план.

I = {1 , . . . , m} -- множество комнат, принимаемых к рассмотрению на предмет их возможной загрузки.

Комнаты, соответствующие номеру i I, назовем i-м номером.

J = {1 , . . . ,n} -- полный перечень работ, составляющих все возможные варианты реализации по загрузке номеров. Работу, соответствующую номеру , назовем j-й работой. Обозначим черезсовокупность работ, которые должны быть произведены при реализации s-ro варианта.

Пусть

li-- длительность этапа планирования для i-ro номера;

Сit-- затраты на разработку плана загрузки i-го номера на t-м отрезке;

цjt-- количество единичных работ по размещению клиентов j-й разновидности, предлагаемых к выполнению на t-м отрезке времени;

fjt-- коэффициент важности выполнения работы j-й разновидности на t-м отрезке;

pij-- количество средств на i-й номер в составе однородного наряда для выполнения единичной работы j-й разновидности;

git -- затраты на съём однойi-й комнаты (номера) на t-м отрезке;

hit -- затраты на содержание однойi-й комнаты (номера) на t-м отрезке;

dit -- затраты на текущий ремонт однойi-й комнаты (номера) на t-м отрезке;

Vit -- ограничение сверху на возможный объем денежных средств на съем одной i-й комнаты на t-м отрезке;

Uit -- ограничение сверху на допустимое количество денежных средств на содержание одной i-й комнаты на t-м отрезке;

Wit -- ограничение сверху на возможный объем денежных средств на текущий ремонт одной i-й комнаты на t-м отрезке

u0i -- количество средств для i-го номера (комнаты)на начальном этапе плана;

bt-- объем выделяемых ресурсов (ассигнований) на развитие плана на t-м единичном отрезке;

Ft -- указанное значение загрузки комнат наt-м единичном отрезке.

Введем также следующие переменные.

Переменные выбора момента начала размещения клиентов по плану. Переменная xit принимает значение 1, если планирование загрузки i-го номера начинается на t-м отрезке, и xit - 0 в противном случае.

Переменные загрузки номера. Величина uit равняется количеству средств на размещение на i-й номер в составе отеля на t-м отрезке.

Переменные пополнения номеров . Величина vit равняется количеству комнат (номер), освобождаемых клиентами на t-м отрезке.

Переменные уменьшения количества номеров. Величина uit равняется количеству комнат, занимаемых клиентами на t-м отрезке.

Переменные назначения. Величина xijt равняется доле работ j-й разновидности по размещению клиентов в i-м номере на t-м отрезке.

С использованием введенных обозначений задача планирования записывается следующим образом.

Максимизировать

Z =

при ограничениях



В этой задаче целевая функция (1.1) выражает оценку загруженности номеров. Соотношения (1.2) связывают загрузку отеля по плану на данном и предыдущем отрезках времени, а неравенства (1.3)--(1.5) ограничивают соответственно число комнат в отеле, его пополнение и уменьшение. Неравенство (1.6) означает, что планирование загрузки для каждой комнаты не может начинаться на двух и более отрезках времени, а неравенство (1.7) запрещает производить размещение клиентов, если номер не может быть сдан в эксплуатацию. Ограничения (1.8) показывают, что работы по планированию загрузки не могут выполняться в большем объеме, чем заданный, а неравенства (1.9) означают, что на каждом отрезке можно использовать только такое количество комнат, какое имеется в отеле. Наконец, неравенства (1.10) ограничивают суммарные затраты, связанные с составлением плана загрузки, на каждом отрезке времени.

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

2.3.2 Оптимизированная математическая модель

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

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

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

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

Для формальной записи сформулированной задачи введем следующие обозначения:

Т = {1 , . . . ,Т} -- множество единичных отрезков, составляющих рассматриваемый план.

I = {1 , . . . , m} -- множество комнат, принимаемых к рассмотрению на предмет их возможной загрузки.

Комнаты, соответствующие номеру i I, назовем i-м номером.

S={1 , . . . ,S} -- полный список вариантов реализации всех рассматриваемых номеров (комнат). Вариант, соответствующий номеру sS, будем называть s-м вариантом.

J = {1 , . . . ,n} -- полный перечень работ, составляющих все возможные варианты реализации по загрузке номеров. Работу, соответствующую номеру , назовем j-й работой. Обозначим черезсовокупность работ, которые должны быть произведены при реализации s-ro варианта.

Пусть

-- коэффициент важности i-го номера для клиента;

- суммарные затраты на выполнение j-й работы, если она начинается с t-гo единичного отрезка;

-- ограничения снизу и сверху на объемы финансирования j-й работы на t-м отрезке;

-- ограничения снизу и сверху на длительность выполнения j-й работы;

dj-- наименьший номер единичного отрезка, начиная с которого может выполняться j - я работа;

bt-- объем выделенных ассигнований для проведения работ на t-м единичном отрезке.

Введем следующие переменные.

Переменные выбора варианта реализации .

Переменная ys принимает значение 1, если реализуется s-й вариант размещения (загрузки) номера, и ys= 0 в противном случае.

Переменные выбора времени начала выполнения (финансирования) работ . Переменная принимает значение 1, если финансирование j-й работы начинается на t-м единичном отрезке, и = 0 в противном случае.

Переменные выбора длительности выполнения работ.

Величина равняется числу единичных отрезков плана загрузки, в течение которых финансируется выполнение j -й работы.

Переменные распределения финансирования работ по единичным отрезкам . Величина равняется объему средств, выделяемых на финансирование j-й работы на t-м единичном отрезке.

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

Максимизировать

(2.1)

при ограничениях



Целевая функция данной задачи выражает величину ожидаемой суммарной прибыли для отеля по выбранным вариантам реализации размещения людей (загрузки) в номерах. Ограничения (2.2) означают, что каждый способ загрузки номера может быть реализован не более чем по одному варианту, а неравенства (2.3) связывают выбор варианта реализации с необходимостью начать на каком-то единичном отрезке финансирование каждой работы из числа образующих этот вариант. Ограничения (2.4) означают, что суммарное финансирование каждой работы, осуществляемое на различных единичных отрезках, не может быть меньше величины суммарных затрат выполнения данной работы. Двухсторонние неравенства (2.5) и (2.6) показывают, что длительность выполнения работы и объемы ее финансирования на каждом единичном отрезке должны находиться в заданных пределах, а неравенства (2.7) означают, что выполнение работы не может быть начато раньше установленного срока. Наконец, ограничения (2.8) показывают, что затраты на проведение работ на каждом единичном отрезке не могут превышать выделенных ресурсов.

Построенная математическая модель предназначена:

· для построения оптимального плана загрузки номеров в отеле с целью получения максимальной прибыли;

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

Таким образом, математическое моделирование позволяет получить четкий ответ: как оптимально распределить номера в отеле и в соответствии с каким планом, на основании имеющихся ресурсов.

2.4 Реинжиниринг бизнес процессов гостиницы «Бастион» с учетом оптимизированных параметров

В результате детального исследования предметной области было выявлено, что для более успешной работы предприятия необходимо произвести некоторые изменения процессов, связанных с составлением плана загрузки номеров в отеле. Для этого была разработана и оптимизирована математическая модель, описывающая данную задачу (см. п. 2.3). На основе оптимизированной модели предлагается разработать информационную систему гостиницы «Бастион», которая помимо фиксации данных и автоматизированного составления отчетов для последующего анализа будет включать модуль «Планирование номерного фонда». Данный модуль системы на основе вводимых параметров будет выбирать наиболее подходящий вариант загрузки номеров в отеле из списка всех возможных и предоставлять его пользователю. Наилучший вариант - тот, который приносит наибольшую прибыль, а значит соответствует максимальному значению функции Z, выражающей величину ожидаемой суммарной прибыли для отеля.

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

Для визуализации представления о производимых изменениях на языке UMLбыли спроектированы следующие диаграммы:

· диаграмма вариантов использования (прецедентов);

· диаграмма последовательности;

· диаграмма классов.

Диаграмма прецедентов (рис. 2.5) была разработана для визуализации поведения элементов системы при взаимодействии с сущностями извне. На ней представлена реакция системы на действия 5 актеров:

· Директор отеля

· Администратор отеля

· Портье

· Администратор ИС

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

Портье оформляет документы клиентов и фиксирует в системе данные по ним, ведет учет движения номерного фонда.

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

Администратор ИС следит за корректной работой ИС, а также проводит работу по устранению неполадок в системе при их возникновении.

Диаграмма последовательности составлена для представления последовательности действий в процессе функционирования системы. На ней представлены следующие объекты:

· Портье;

· Администратор отеля;

· Модуль ИС «Планирование номерного фонда»;

· Директор отеля.

Данная диаграмма представлена на рис. 2.6.

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

· Номер в отеле;

· Работа;

· Вариант размещения;

· Клиент;

· Сотрудник;

· Оплата;

· Дополнительные услуги;

· Бронь;

· Выбывшие постояльцы.

Класс «Номер в отеле» описывает все номера в отеле и содержит атрибуты:

· № комнаты;

· Число мест в номере;

· Класс номера;

· Стоимость;

· Описание номера.

и операции над ним:

· Редактировать номер.

Класс «Работа» описывает все работы, которые необходимо выполнить перед размещением клиентов в номерах. Данный класс представлен атрибутами:

· Наименование работы;

· Начало выполнения;

· Конец выполнения;

· Стоимость выполнения работы.

и операциями над ним:

· Добавить работу;

· Удалить работу;

· Редактировать работу.

Элементами класса «Вариант размещения» являются все возможные варианты размещения клиентов в отеле на данный момент времени. Атрибуты класса:

· № варианта размещения;

· Номер комнаты;

· Класс;

· Дата ликвидности;

операция над классом:

· Редактировать вариант размещения.

Класс «Клиент» содержит сведения о клиентах отеля; он представлен атрибутами:

· Фамилия;

· Имя;

· Отчество;

· Номер удостоверения;

· Дополнительные данные;

и операциями над ним:

· Добавить клиента;

· Удалить клиента;

· Редактировать клиента.

Класс «Сотрудник» содержит информацию о всех сотрудниках отеля; класс описывается атрибутами:

· Фамилия;

· Имя;

· Отчество;

· Должность;

· Дата рождения

и операциями:

· Добавить сотрудника;

· Удалить сотрудника;

· Редактировать сотрудника.

Класс «Бронь» представлен атрибутами:

· Код брони;

· Состояние;

· Фамилия заказчика;

операциями:

· добавить;

· удалить;

· редактировать.

Класс «Дополнительные услуги» описывается атрибутами:

· Код услуги;

· Наименование услуги;

· Стоимость услуги

Операции над данным классом возможны следующие:

· добавить;

· удалить;

· редактировать.

Класс «Выбывшие постояльцы» представляет собой архив данных о всех клиентах, пользовавшихся услугами отеля. Он представлен атрибутами:

· Фамилия;

· Имя;

· Отчество;

· Номер удостоверения;

· Номер в отеле;

· Срок проживания

и операциями над ним:

· добавить;

· удалить;

· редактировать.

Класс «Оплата» необходим для учета выставленных клиентам счетов и оплаты по ним. Данный класс представлен атрибутами:

· Код оплаты;

· Предоплата;

· Полная стоимость;

· Дата оплаты;

· Полная стоимость

и операциями:

· добавить;

· удалить;

· редактировать.

3. Проектирование информационной системы регистратуры гостиницы«Бастион»

3.1 Способ организации информационной системы

3.1.1 Выбор архитектуры информационной системы

Архитектура информационной системы -- концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы. Рассмотрим особенности типовых архитектур, их преимущества и недостатки.

Архитектура файл-сервер представляет собой наиболее простой случай распределенной обработки данных, согласно которой на сервере располагаются только файлы данных, а на клиентской части находятся приложения пользователей вместе с СУБД. Файл-сервер представляет собой достаточно мощную по производительности и оперативной памяти ПЭВМ, являющуюся центральным узлом локальной сети. Файл-сервер в среде сетевой операционной системы организует доступ к файлам, полностью эквивалентным файлам операционной системы и расположенным во внешней памяти файл-сервера. При данном подходе программы СУБД располагаются в оперативной памяти рабочих станций локальной сети, а файлы базы данных - на магнитных дисках файл-сервера. Специальный интерфейсный модуль распознает, где находятся файлы, к которым осуществляется обращение. В связи с этим данная СУБД может работать как с локальными базами данных, так и с центральной базой данных. Синхронизация совместного использования базы данных файл-сервера возлагается на систему управления базами данных, которая должна обеспечивать блокирование записей на время их корректировки, чтобы сделать их недоступными с других рабочих станций.

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

Архитектура клиент-сервер основана на использовании серверов баз данных. Она используется при создании ИС, предназначенной для решения тесно связанных функциональных задач (число клиентов до 100 человек).

Общее представление информационной системы в архитектуре "клиент-сервер" показано на рисунке 3.2. На стороне клиента выполняется код приложения, в который обязательно входят компоненты, поддерживающие интерфейс с конечным пользователем, производящие отчеты, выполняющие другие специфичные для приложения функции. Клиентская часть приложения взаимодействует с клиентской частью программного обеспечения управления базами данных, которая, фактически, является индивидуальным представителем СУБД для приложения. Благодаря организации репозитария БД в данной архитектуре гарантируется обеспечение целостности хранимых данных.

ИС на основе Internet-Intranet технологий - это корпоративная система, в которой используются методы и средства Internet. Такая система может быть локальной, изолированной от остального мира Internet, или опираться на виртуальную корпоративную подсеть Internet. В последнем случае особенно важны средства защиты информации от несанкционированного доступа. Создание intranet-сетей с внутреннимиWeb-серверами существенно облегчает сотрудникам предприятия доступ к разнообразной информации. Благодаря связям с корпоративными базами данных, файл-серверами и хранилищами документов Web-серверы предоставляют сотрудникам компании самые различные виды информации через единый интерфейс - Web-браузер. Несколько начальных страниц служат гипертекстовыми связями со всеми видами документов и данных.

Однако, при всех своих преимуществах (простота организации, удобство использования, стандартность интерфейсов и т.д.) эта архитектура обладает сильными ограничениями. Прежде всего, в информационной системе отсутствует прикладная обработка данных. Все, что может пользователь, это только просмотреть информацию, поддерживаемую Web-сервером. Далее, гипертекстовые структуры трудно модифицируются. Для того, чтобы изменить наполнение Web-сервера, необходимо приостановить работу системы, внести изменения в HTML-описания и только затем продолжить нормальное функционирование. Наконец, далеко не всегда достаточен поиск информации в стиле просмотра гипертекста. Базы данных и соответствующие средства выборки данных по-прежнему часто необходимы.

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

Выделим критерии для сравнения описанных архитектур:

· Число клиентов - характеризует число клиентских станций, которые позволяет использовать архитектура;

· Простота установки - характеризует простоту установки и настройки системы при выборе той или иной архитектуры;

· Простота администрирования - показывает, не усложнено ли обслуживание и администрирование системы;

· Легкость модернизации - характеризует процесс внесения изменений после внедрения системы;

· Обеспечение целостности данных - необходимое условие для организации ИС;

· Поддержка совместного доступа к данным - одновременная работа с данными нескольких сотрудников - значительно ускоряет процессы на предприятии;

· Поддержка прикладной обработки данных - для разрабатываемой системы необходима организация внесения изменений сотрудниками в информацию, хранимую в БД системы;

· Количество хранимой информации - показывает соответствие объема информации, необходимой для функционирования системы, и информации, хранение которой обеспечивается архитектурой;

· Стоимость реализации - также важный критерий при выборе архитектуры.

Таблица 3.1 Сравнительный анализ архитектур

	Фактор важности	Файл-сервер	Клиент-сервер	Internet-Intranet	Многоуровневая
		Степень соотв.	Оценка	Степень соотв.	Оценка	Степень соотв.	Оценка	Степень соотв.	Оценка
Число клиентов	9	40	3,6	100	9	100	9	80	7,2
Простота установки	7	100	7	95	6,65	100	7	0	0
Простота администрирования	8	80	6,4	100	8	100	8	85	6,8
Легкость модернизации	9	70	6,3	90	8,1	40	3,6	80	7,2
Стабильность работы	10	65	6,5	100	10	90	9	100	10
Обеспечение целостности данных	10	60	6	100	10	85	8,5	100	10
Поддержка совместного доступа к данным	10	0	0	100	10	100	10	100	10
Поддержка прикладной обработки данных	9	100	9	100	9	0	0	100	9
Количество хранимой информации	9	60	5,4	100	9	90	8,1	90	8,2
Стоимость реализации	7	70	4,9	100	7	90	6,3	70	4,9
Итоговый балл:		55,1		86,75		69,5		73,3

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

1) Для каждого требования, бизнес процесса, функционального направления проставляется «Фактор важности» (максимальный балл равен 10), который показывает важность рассматриваемого требования к системе;

2) Каждое требование оценивается по 100-балльной шкале ("Степень соответствия", то есть это степень реализации требуемой функциональности в системе: насколько функциональность реализована в стандартной поставке);

3) Для каждого требования вычисляется интегральный показатель:

(1)

где E - оценка (балл);

F - фактор важности;

С - степень соответствия

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

По результатам сравнения наиболее подходящая архитектура для ИС «Отель» - клиент-сервер (она поддерживает необходимое число клиентских станций; обеспечивает хранение достаточного количества информации, прикладную обработку данных; несложна для установки и администрирования).

3.1.2 Схема типовой архитектуры

Исходя из выбранной архитектуры системы, построим ее типовую схему (рис. 3.5). В данном случае диалоговые компоненты (средства представления и логика представления) размещаются на «тонком »клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными находятся на сервере. Для реализации данной архитектуры необходимо определить:

· платформу для серверной части системы;

· платформу для клиентской части системы;

· протоколы связи между серверной и клиентской частями системы;

· СУБД.

3.1.3 Выбор платформы для реализации

Для успешной реализации выбранной архитектуры одно из наиболее важных условий - правильный выбор операционной системы для сервера. Выбор будем осуществлять между UNIX-системами, т.к., несмотря на огромную популярность и простоту использования и администрирования систем Windows, открытость и универсальность платформы операционной системы Linux делает возможным ее настройку практически под любые нужды и конкретную ситуацию. Этим же обеспечивается совместимость практически со всеми платформами, а не только Intel или AMD (это не ограничивает нас в выборе аппаратной части для сервера). Также необходимо отметить довольно большую гибкость, наличие большого количества свободного программного обеспечения; неплохую техническую поддержку при использовании коммерческих версий Linux; систему безопасности, которая благодаря оригинальности обеспечивает неплохой уровень защиты.

Выбор ОС будем проводить среди следующих систем: SUSE Linux Enterprise Server 9, ALT Linux 4.0 Server, Debian GNU/Linux.

Debian GNU/Linux - свободная, высококачественная Unix-совместимая операционная система, обладающая полным набором приложений. Все пакеты, которые являются частью Debian GNU/Linux, свободны для распространения, согласно положениям GNU GeneralPublicLicense. Установленная на сервере Debian GNU/Linux также может включать приблизительно 450 программных пакетов (из разделов non-free и contrib), которые распространяются по особым правилам. Все пакеты очень хорошо интегрированы. Также необходимо отметить легкость модернизации и стабильность работы ОС.

AL TLinux 4.0 Server - предоставляет готовую техническую базу для решения актуальных задач любой организации в сфере информационных технологий. Для каждой из наиболее распространенных задач в состав дистрибутива входят специально подготовленные серверные решения -- виртуальные серверы. Решаемые задачи: организация среды обмена информацией (почтовый сервер с защитой от нежелательных сообщений и вирусов, сервер обмена мгновенными сообщениями, файловые серверы, сервер печати, веб-сервер, серверы баз данных); организация корпоративной сети (сетевой шлюз, прокси-сервер, централизованная аутентификация, синхронизация времени).Дистрибутив ALT Linux 4.0 сопровождается гарантированной поддержкой обновлениями по безопасности в течение 3-х лет с момента выпуска, имеется простой веб-интерфейс для работы с обновлениями.

SUSE Linux Enterprise Server 9 - масштабируемая и высокопроизводительная основа для защищенного функционирования вычислительных систем масштаба предприятия. Благодаря широким функциональным возможностям этот продукт компании Novell® отвечает требованиям современных сетей и запросам пользователей. Развертывание, настройка и обслуживание продукта SUSE Linux Enterprise Server 9 в масштабах предприятия не вызывает затруднений. SLES поддерживает широкий спектр аппаратных платформ и сертифицирован ведущими мировыми разработчиками ПО, например, корпорацией Oracle. Благодаря уникальным и открытым средствам управления, можно легко устанавливать, распространять, конфигурировать, защищать и обновлять Linux-серверы в любой части корпоративной сети.

Сравнение будем проводить по следующим критериям:

ь Техническая поддержка - очень важный критерий при выборе Unix-системы;

ь Простота администрирования - характеризует объем знаний, необходимый для администрирования ОС;

ь Простота настройки ОС - характеризует объем знаний, необходимый для настройки ОС;

ь Легкость модернизации - для будущей системы уже на стадии разработки необходимо учитывать возможность и простоту ее модернизации;

ь Безопасность - критерий особенно важен при выборе серверной ОС;

ь Наличие драйверов устройств - определяет, какой оборудование можно использовать с ИС;

ь Наличие разнообразного ПО - для любой ОС важно наличие разнообразного пользовательского ПО;

ь Простота установки.

Сравнительный анализ серверных ОС представлен в таблице 3.2.

Таблица 3.2

	Фактор важности	SUSE Linux Enterprise Server 9	ALT Linux 4.0 Server	Debian GNU/Linux
		Степень соотв.	Оценка	Степень соотв.	Оценка	Степень соотв.	Оценка
Техническая поддержка	10	100	10	90	9	100	10
Простота администрирования	8	80	6,4	75	6	80	6,4
Простота настройки ОС	6	85	5,1	80	4,8	90	5,4
Легкость модернизации	6	90	5,4	85	5,1	85	5,1
Безопасность	10	90	9	90	9	90	9
Наличие драйверов устройств	8	70	5,6	70	5,6	80	6,4
Наличие разнообразного ПО	8	90	7,2	80	6,4	100	8
Простота установки ПО	7	75	5,25	60	4,2	100	7
Стабильность работы системы	10	85	8,5	90	9	100	10
Сеть	7	90	6,3	95	6,65	95	6,65
Итоговый балл:		68,75		65,75		73,95

Сравнение было проведено по методу SMART, описанному выше.

По результатам сравнения наиболее оптимальной операционной системой для сервера является Debian GNU/Linux.

В качестве СУБД, из которых будет производиться выбор для использования их в ИС, выбраны следующие:

Oracle занимает лидирующие позиции на рынке СУБД и, что особенно важно, лидирует на платформах Unix и Windows. В России также обозначилось лидерство Oracle, особенно в области крупномасштабных информационных систем государственных структур. Фактически в нашей стране СУБД Oracle стала стандартом для государственных информационных систем. Причина широкой распространенности Oracle заключается прежде всего в высоких эксплуатационных характеристиках СУБД, большом количестве подготовленных отечественных специалистов по Oracle, наличию поддерживающей инфраструктры - учебных центров, широкой сети партнеров Oracle, большому числу технических курсов по Oracle в высших учебных заведениях и т.д. Так, только в Москве имеется более десятка учебных центров, предоставляющих широкий спектр технических курсов практически по всем линиям программных продуктов Oracle. Партнерская сеть по всей стране насчитывает более 160 организаций, что гарантирует поддержку ПО Oracle практически в любой точке страны. На русском языке уже издано достаточно много качественных книг по СУБД Oracle.

Microsoft SQL Server

В комплект средств административного управления данной СУБД входит целый набор специальных мастеров и средств автоматической настройки параметров конфигурации. Также данная БД оснащена замечательными средствами тиражирования, позволяющими синхронизировать данные ПК с информацией БД и наоборот. Входящий в комплект поставки сервер OLAP дает возможность сохранять и анализировать все имеющиеся у пользователя данные. В принципе данная СУБД представляет собой современную полнофункциональную база данных, которая идеально подходит для малых и средних организаций.

Необходимо заметить, что SQL Server уступает другим рассматриваемым СУБД по двум важным показателям: программируемость и средства работы. При разработке клиентских БД приложений на основе языков Java, HTML часто возникает проблема недостаточности программных средств SQL Server и пользоваться этой СУБД будет труднее, чем системами DB2, Informix, Oracle или Sybase. Общемировой тенденцией в XXI веке стал практически повсеместный переход на платформу LINUX, а SQL Server функционирует только в среде Windows. Поэтому использование SQL Server целесообразно, по нашему мнению, только если для доступа к содержимому БД используется исключительно стандарт ODBC, в противном случае лучше использовать другие СУБД.

MicrosoftAccess -- реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, сортировку по разным полям, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.

MS Access является файл-серверной СУБД и потому применима лишь к маленьким приложениям. Отсутствует ряд механизмов необходимых в многопользовательских БД, таких, например, как транзакции. Опыт показывает, что даже для проектов на 5-20 пользователей предпочтительно использовать клиент-серверные решения.

Выбор критериев для сравнения:

1. Работа под управлением различных ОС -

· Возможность работы на различных платформах

2. Сопряжение с другими БД -

· Возможность импорта экспорта данных в другие БД

3. Функциональная совместимость -

· Совместимость со сторонними программными средствами на уровне фунциональности

4. Одновременный доступ нескольких пользователей -

· Возможность работы с БД сразу нескольким авторизированным пользователям

5. Подключение к Web -

· Работа в сети интернет

6. Построение баз данных -

· Генерация скрипта БД

7. Распределенная обработка транзакций -

· Возможность работы в распределенной системе

Сравнительный анализ СУБД представлен в таблице 3.3.

Таблица 3.3

	Фактор важности	Oracle 9i	MS Access	MS SQL Server 2000
		Степень соотв.	Оценка	Степень соотв.	Оценка	Степень соотв.	Оценка
Работа под управлением различных ОС	10	100	10	10	1	100	10
Сопряжение с другими БД	10	100	10	50	5	80	8
Функциональная совместимость	9	100	9	60	5,4	80	7,2
Одновременный доступ нескольких пользователей	9	100	9	0	0	100	9
Подключение к Web	10	100	10	100	10	100	10
Построение баз данных	8	80	6,4	100	8	90	7,2
Распределенная обработка транзакций	9	80	7,2	0	0	100	9
Итоговый балл:	61,6	29,4	60,4

Методика и порядок расчета показателей таблицы 3.3 методом SMART был приведен выше.

В сводной таблице представлены сравнительные характеристики рассмотренных СУБД. Клиентские места при этом могут функционировать практически на любой платформе (кроме СУБД Access), средством доступа клиентов к СУБД является либо CGI (Perl) либо JAVA приложения.

Пакет Oracle наделен самым развитым набором функций для работы с языком Java и доступа к данным через Интернет, системой оптимизации одновременного доступа. Единственным недостатком данной СУБД является сложность администрирования, однако все затраты на ее внедрение и освоение в последствии окупятся эффективной и надежной работой. В соответствии с чем, выбор пал на СУБД Oracle 9i.

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

Windows 7 -- операционная система семейства Microsoft Windows NT, линейки операционных систем, используемых на пользовательских персональных компьютерах.

В Windows 7 обновлена подсистема управления памятью и вводом-выводом. Новой функциональностью также является «Гибридный спящий режим» или режим «гибернации», при использовании которого содержимое оперативной памяти дополнительно записывается на HDD, но и из памяти также не удаляется. В результате если подача энергии не прекращалась, то компьютер восстанавливает свою работу, пользуясь информацией из ОЗУ. Если питание компьютера выключалось, операционная система использует сохранённую на HDD копию ОЗУ и загружает информацию с неё (аналог спящего режима). Режим реализован благодаря так называемым «файлам гибернации», которые занимают объём на жёстком диске, равный объёму установленной на компьютере оперативной памяти. Возможно пользовательское удаление этих файлов с утратой функции гибернации. При этом восстановление этих файлов без особых затруднений возможно путём вызова специальных команд из командной строки.

MacOSX Show Leopard

Mac OS (Macintosh Operating System) - семейство проприетарных операционных систем с графическим интерфейсом. Разработана корпорацией Apple (ранее -- AppleComputer) для своей линейки компьютеров Macintosh. Популяризация графического интерфейса пользователя в современных операционных системах часто считается заслугой Mac OS. Она была впервые представлена в 1984 году вместе с оригинальным Macintosh 128K.

Ранние версии Mac OS были совместимы только с Макинтошами, основанными на процессорах Motorola 68k, следующие версии были совместимы с архитектурой PowerPC (PPC). С недавних пор Mac OS X стала совместима с архитектурой Intel x86. Но политика фирмы Apple такова, что она разрешает устанавливать систему Mac OS только на компьютеры Apple.

Mac OS X официально сертифицирована как UNIX-система. Так как Mac OS X и Mac OS 9 значительно отличаются друг от друга, программы для Mac OS 9 работают в Mac OS X в режиме эмуляции. Для запуска приложений Mac OS 9 в Mac OS X была создана виртуальная машина, называемая «Classic».

Linux- Debian -- операционная система, состоящая как из свободного ПО с открытым исходным кодом, так и из закрытых компонентов.Debian может использоваться, как операционная система для серверов, так и для рабочих станций.

Debian имеет наибольшее среди всех дистрибутивов хранилище пакетов -- готовых к использованию программ, -- и если даже не по их числу, то по числу поддерживаемых архитектур: начиная с ARM, используемой во встраиваемых устройствах, наиболее популярных x86 и PowerPC, новых 64-разрядных AMD и заканчивая IBM S/390, используемой в мейнфреймах. Хранилище разделено на три ветки:

§ стабильную (stable), содержащую пакеты, вошедшие в последний официальный дистрибутив;

§ тестируемую (testing), из которой будет формироваться следующий стабильный дистрибутив;

§ нестабильную (unstable), в которой пакеты готовятся к помещению в тестируемую ветку.

Существует также ветка, называемая экспериментальной (experimental); в неё помещаются пакеты, претерпевающие особо большие изменения. Для работы с хранилищем разработаны разные средства, самое популярное из которых -- APT.

Выбор критериев оценки:

1. Техническая поддержка - возможность предоставления услуг технической поддержки пользователей через интернет или телефонную линию;

2. Исходный код - возможность внесение изменений в код ОС;

3. Наличие прикладного ПО и драйверов - возможности установки дополнительного прикладного ПО, а также драйверов для различного оборудования;

4. Сеть - поддерживаемые сетевые протоколы;

5. Безопасность - наличие способов защиты персональных данных и самой системы;

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

Анализ по выбранным критериям приведен в таблице 3.4.

Таблица 3.4

	Фактор важности	Windows 7	Mac OS X Show Leopard	Debian
		Степень соотв.	Оценка	Степень соотв.	Оценка	Степень соотв.	Оценка
Техническая поддержка	10	100	10	100	10	90	9
Исходный код	6	0	0	90	5,4	100	6
Наличие прикладного ПО и драйверов	9	100	9	70	6,3	80	7,2
Сеть	9	100	9	100	9	100	9
Безопасность	10	50	5	100	10	100	10
Администрирование	10	100	10	100	10	100	10
Итоговый балл:	43	50,7	51,2

Методика и порядок расчета показателей таблицы 3.4 методом SMART был приведен выше.

Результаты сравнения:

Не смотря на то, что ОС Macintosh Leopard имеет очень хорошую совместимость с аппаратной частью компьютера, а так же у него хорошая техническая поддержка пользователей и безопасность находится на довольно высоком уровне, эта ОС не будет использована для разрабатываемой ИС, так как оборудование от компании Apple в области ПК немного дороже других фирм производителей, а так же существуют проблемы с его приобретением (так оно не так широко распространено на территории России) и обучением сотрудников предприятия работе на MACOS.

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

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