Файл: Информатики и вычислительной техники.docx

После определения действующих лиц (таблица 4) на основе анализа требований к информационной системе строится диаграмма вариантов использования системы [5-6] (рис.2) и определяется перечень вариантов использования системы (таблица 5).



Рисунок 2 - Диаграмма вариантов использования системы (use-case)
Таблица 4 - Перечень действующих лиц

Идентификатор	Актер
AC-1	Менеджер
AC-2	Руководитель

Таблица 5 - Перечень вариантов использования

Действующее лицо	Идентификатор			Описание
AC-1	UC-1			Ведение справочника сотрудников
AC-1	UC-2			Ведение реестра заказов
AC-1		UC-3	Ведение реестра клиентов
AC-1		UC-4	Ведение реестра заказанных номеров
AC-1		UC-5	Ведение справочника сотрудников
AC-1		UC-6	Просмотр отчет по заказанным номерам
AC-2		UC-6	Просмотр отчет по заказанным номерам
AC-1		UC-7	Просмотр финансового отчета
AC-2		UC-7	Просмотр финансового отчета

Для каждого из вариантов использования системы определяется сценарий использования системы.
Наименование прецедента. UC-1 Ведение справочника сотрудников. Добавление нового сотрудника (рис.3).

Актеры. Менеджер

Предусловия. Пользователь зарегистрирован и вошел в систему. Открыто окно Справочник сотрудников.

Краткое описание.

Основной поток событий

1.Менеджер: вводит ФИО сотрудника, его должность, телефон и адрес	Все поля заполнены
3. Менеджер: После заполнения полей нажимает кнопку Сохранить для сохранения данных в БД.	Если поля заполнены правильно данные сохраняются в БД. Иначе выводится сообщение об ошибке.
4. Менеджер: Если данные сохранены успешно	Завершения сеанса.

---

Альтернативный поток 1.

1. Менеджер: Если поля заполнены не правильно.

Выдать сообщение: Ошибка ввода данных.

Альтернативный поток 2.

1. Менеджер: При сохранении данных утеряна связь с БД.

Выдать сообщение: Ошибка сохранения данных.

Рисунок 3 – Реализация варианта использования при помощи диаграммы деятельности
Наименование прецедента. UC-5 Ведение реестра заказов. Добавить заявку (рис.4).

Актеры. Менеджер

Предусловия. Пользователь зарегистрирован и вошел в систему. Открыто окно Реестр заказов.

Краткое описание.

Основной поток событий

1.Менеджер: Выбирает из выпадающего списка номер.	Если есть соединение с БД, выбирает нужный номер.
2. Менеджер: Выбирает клиента из выпадающего списка	Если есть соединение с БД, выбирает нужного клиента.
3. Менеджер: Заполняет поля заказа. После заполнения полей нажимает кнопку Сохранить для сохранения данных в БД.	Если поля заполнены правильно данные сохраняются в БД. Иначе выводится сообщение об ошибке.
4. Менеджер: Если данные сохранены успешно	Завершения сеанса.

Альтернативный поток 1.

1. Менеджер: Если клиента нет в БД.

Выдать сообщение: Добавить клиента в БД. Открывается окно Справочник клиентов.

Альтернативный поток 2.

1. Менеджер: При сохранении данных утеряна связь с БД.

Выдать сообщение: Ошибка сохранения данных.

---

Рисунок 4 – Реализация варианта использования при помощи диаграммы деятельности

---

1.2.4 Создание логической модели информационной системы

Определение объектов. Объекты - это люди или предметы, описанные в сценариях использования системы. На основе объектов создаются сервисы, атрибуты и отношения. Объекты проектируемой информационной системы представлены в таблице 6.
Таблица 6 - Объекты проектируемой системы.

Объект	Описание
Менеджер	Менеджер формирует данные в БД
Заявки	Данные по заявкам для бронирования номеров
Номера	Данные по номерам гостиницы
Сотрудники	Данные о сотрудниках гостиницы
Заказ	Данные по заказанным номерам гостиницы
Оплата	Данные по оплатам за заказанные номера
Клиенты	Данные о клиентах гостиницы

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

Граничные классы (Boundary) - служат посредником при взаимодействии внешних объектов с системой.

Классы-сущности (Entity) - представляют собой ключевые абстракции (понятия) разрабатываемой системы.

Управляющие классы (Control) - обеспечивают координацию поведения объектов в системе.

Пример набора классов, приведен на рисунке 5.


Рисунок 5 – Диаграмма классов для прецедента

2 Проектирование базы данных информационной системы

2.1 Структура базы данных

Для того чтобы спроектировать реляционную БД нужно выделить определенную совокупность таблиц, которые содержат необходимую информацию, и установить связи между этими таблицами. Для того, чтобы спроектировать БД таким образом, применяют два подхода: сверху вниз или снизу вверх. При первом подходе сначала определяются основные задачи, для решения которых строится БД и потребности этих задач в определенных данных. А уже потом эти данные распределяются по таблицам и связываются между собой. При втором подходе изучается предметная область, реквизиты всех документов, проводится анализ данных и устанавливаются типовые объекты этой области. После чего строятся реляционные таблицы и связи между ними. Вообще процесс проектирования БД распределяется на следующие этапы [8]:

---

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

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

3 этап. Определение структуры данных. На этом этапе все данные распределяются по объектам, и эти объекты сопоставляются с таблицами нашей БД. Для каждого из данных надо указать его имя в таблице, тип и формат. В реляционной БД на этом этапе проводят процесс нормализации, с помощью которого выбирается наиболее эффективный и гибкий способ хранения информации.

Правила нормализации:

• 
  Каждое поле любой таблицы должно быть уникальным (не дублировать данные).
  
• 
  Информационный объект должен иметь уникальный идентификатор - первичный ключ (простой или сложный).
  
• 
  Всё не ключевые поля должны быть независимы.
  
• 
  Все поля, которые входят в составленный ключ, тоже должны быть взаимно независимыми.
  
• 
  Каждому значению первичного ключа должно соответствовать только одно значения не ключевого поля, и это значение должно относиться к объекту таблицы.
  

4 этап. Формирование связей между таблицами БД.

Выполним логическое проектирование базы данных Оформление командировок сотрудниками

1 этап. На первом этапе формируем перечень задач.

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

• 
  автоматизированное формирование заявок на бронирование номеров;
  
• 
  автоматизированное формирование и печать квитанции на оплату;
  
• 
  автоматизированное ведение реестра заявок;
  
• 
  автоматизированное ведение реестра клиентов;
  
• 
  автоматизированное ведение реестра номеров;
  
• 
  автоматизированное ведение реестра брони
  

2 этап. Для каждой из задач, которые были выделены на первом этапе, определяют объекты и их атрибуты (рис.6).



Рисунок 6 – ER-диаграмма данных

3 этап. На этом этапе осуществляется переход от объектов в таблицы. Перед созданием таблиц необходимо провести анализ данных и выполнить нормализацию данных. С учетом этих замечаний таблицы имеют вид представлен на рисунке 7.

---