Файл: Исследование функций и целей организации. 3 Постановка задачи. 4.doc

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

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

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

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

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

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

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

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

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

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

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

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

2. Создание модели данных с помощью

AllFusionErwinDataModeler 4.1

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

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

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

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

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

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

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

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

Например, на рис.10 сущность “Телефонные переговоры” однозначно идентифицирует первичный ключ “ Порядковый номер звонка (РК)”.

При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (FK). Пример такой миграции атрибутов с участием дочерней сущности “Оказанные услуги”, родительской сущности “Тариф услуг” и первичного ключа родительской сущности “Код услуги” представлен на рис. 11 :

Рис. 11 Пример миграции атрибутов

Сущности и атрибуты, определенные в информационной модели представлены в отчете (на рис. 12), сгенерированном с помощью пункта меню Tools/Data Browser/Erwin Repots .

Рис. 12 Отчет , сгенерированный с помощью ERwin

3. Поиск и исправление ошибок с помощью ErwinExaminer

Для автоматизированного поиска ошибок моделирования данных мы использовали инструмент, входящий в пакет AllFusion – AllFusion Data Modeler Validator (Erwin Examiner ). Как показано на рис. 13, с помощью пункта меню File/New мы создали проект:

Рис. 13 Создание проекта ERwin Examiner

В диалоге Select Project Type выбираем источник метаданных будущего проекта – модель Erwin 4.1. После выбора модели данных появляется диалог Select Tables for Model, в котором можно отобрать таблицы для включения в проект Erwin Examiner (рис. 14) :

Рис. 14 диалог Select Tables for Model

После импорта модели во вкладках Tables (рис. 15) и Relationships (рис. 16) отображаются объекты модели:

Рис. 15 Вкладка Tables ERwin Examiner

Рис. 16 Вкладка Relationships ERwin Examiner

После нахождения и исправления ошибок 3-ей (Normalization) и 4-ой (Relationships) категории вкладка Diagnostics Erwin Examiner выглядит, как показано на рис.17:

Рис. 17 Вкладка Diagnostics Erwin Examiner

4. Модели в нотации языка UML

Помимо этого было проведено моделирование на языке UML в среде Component Modeler, входящей в состав пакета All Fusion Data Modeling Suite (Маклаков С.В. “Создание информационных систем с AllFusion Modeling Suite”). Были спроектированы диаграммы классов, компонентов и размещения.

4.1 Диаграмма размещения (Deployment diagram)

При построении диаграмм размещения используют три вида основных ус-ловно-графических обозначений: Processor (процессор), Device (устройство), Connection (соединение). На рис.18 показана диаграмма Deployment, на которой изображена схема сети «Гостиница». Сеть состоит из 4-х компьютеров (администратора, бухгалтера, отдела обслуживания и отдела учета телеф. переговоров), которые соединены с главным компьютером по хранению информации «Сервером». К компьютеру администратора гостиницы подключен принтер, остальные служащие гостиницы могут распечатать информацию по сети.

Рис. 18 Диаграмма размещения

4.2 Диаграмма компонентов (Component diagram)

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

Рис. 19 Диаграмма компонентов

У каждого класса имеется свой собственный заголовочный файл и файл с расширением *.СРР, так что каждый класс преобразуется в свои собственные компоненты на диаграмме. Например, класс Client преобразуется в два компонента: client.h и client.cрp. Вместе эти компоненты представляют тело и заголовок класса Client. Компонент Hotel.exe представляет поток обработки информации (thread of processing). В данном случае поток обработки — это исполняемая программа.

4.3 Диаграмма классов (Class diagram)

На рис. 20 представлена диаграмма классов:

Рис. 20 Диаграмма классов

На диаграмме представлены 4 класса. У каждого из них есть методы (operations) – некоторые действия, которые описывают поведение методов класса. Так у класса Client есть методы: Delete() – для удаления данных о клиенте, CostRoom() – для подсчета итоговой стоимости проживания в гостинице. В классе Phone есть класс для выяснения времени разговора (Time()) и номера , по которому звонили (Number()).

5. Связь с СУБД Access

Далее средствами ERwin была проведена генерация файла базы данных программы Microsoft Access. В окне выбора баз данных выбираем СУБД Access. Затем производим подключение через меню Файл/Подключение. (рис. 21)

В открывшемся окне необходимо прописать имя сервера, имя пользователя, пароль, а также название базы данных, с которой необходимо установить связь. После подключения созданная база данных станет доступна в СУБД Access.

Рис. 21 Осуществление доступа к выбранной СУБД

Далее проводим генерацию схемы доступа в выбранную базу данных(рис. 22):

Рис. 12 Генерация базы данных

После нажатия кнопки Generate генерируется база данных в выбранной СУБД.

6. Разработка экранных форм

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

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

Для более удобного доступа ко всем формам и запросам, выполняемым ИС была разработана главная форма (рис. 23):

Рис. 23 Форма "Постоялец"

С главной формы есть доступ к:

 запросу, который позволяет узнать все оказанные услуги по фамилии постояльца (рис. 24);

SELECT [Оказанные услуги].[Название услуги (FK)], [Оказанные услуги].[Стоимость услуги (FK)]

FROM Постоялец INNER JOIN [Оказанные услуги] ON Постоялец.[Код постояльца (РК)] =

[Оказанные услуги].[Код постояльца (FK)]

WHERE ((([Оказанные услуги].[Код постояльца (FK)])=(SELECT Постоялец.[Код постояльца (РК)] FROM Постоялец WHERE Постоялец.Фамилия=family)));

Рис. 24 Результат выполнения запросы "Фамилия услуги"

 запросу, сообщающему суммарную стоимость всех услуг, оказанных постояльцу (рис. 25);

SELECT Sum([Оказанные услуги].[Стоимость услуги (FK)]) AS [Суммарная стоимость услуг]

FROM Постоялец INNER JOIN [Оказанные услуги] ON Постоялец.[Код постояльца (РК)] =

[Оказанные услуги].[Код постояльца (FK)]

WHERE ((([Оказанные услуги].[Код постояльца (FK)])=(SELECT [Постоялец].[Код постояльца (РК)] FROM [Постоялец] WHERE [Постоялец].[Фамилия]=family)));

Рис. 25 Результат выполнения запроса "Суммарная стоимость услуг"

 запросу, показывающему все телефонные переговоры (рис. 26, 27);

SELECT Постоялец.Фамилия, Постоялец.Имя, Постоялец.Отчество, Постоялец.[Номер апартаментов (FK)], Апартамент.[Категория апартаментов], [Телефонные переговоры].[Дата разговора],

[Телефонные переговоры].[Время разговора (мин)], [Телефонные переговоры].Телефон,

[Телефонные переговоры].Стоимость