68
- служебные функции (управление окнами, проверка пароля и пр.);
- ключевые функции обработки данных (ведения справочников, ввода
первичной информации, обрабатывания, подготовки и распечатки
документов и пр.).
Сценарий диалога системы приведен на рисунке 28.
Главное меню
Справочники Документы Отчеты Выход
Клиенты
Виды заявок
Сотрудники
Ввод заявок
Передача на
исполнение
Неисполненные
заявки
Отчет о
состоянии
отработки заявок
Сводный отчет
Рисунок 28 Сценарий диалога системы
Таким образом, интерфейс разрабатываемого программного продукта
должен соответствовать показанной структуре и включать перечень
указанных основных и служебных функций (ведения справочной,
оперативной, отчетной информации).
2.3.2. Характеристика базы данных
Разрабатываемая система предназначена для автоматизации контроля
заявок компании. Главной целью данного проекта является создание web-
приложения с разделенным доступом в режиме администратора,
менеджера, клиента и исполнителя.
Основные цели создания web-приложения:
упорядочить процесс учета заявок;
быстро и оперативно находить нужную информацию;
представлять информацию в оптимально удобном виде;
69
рационально хранить информацию;
ускорить работу организации;
хранить все данные в единой компьютерной базе данных.
В результате разработки необходимо достигнуть таких показателей:
1. Организация учёта информации, которая будет основана на
применении СУБД.
2. Разработка пользовательского интерфейса для работы с web-
приложением, которое сможет обеспечить интуитивно-понятные
процедуры вызова ключевых функций системы и незамедлительный доступ
к БД.
3. Надежное сохранение информационных массивов,
реализованное при помощи обеспечения целостности данных и
разграничения доступа к информации.
4. Сокращение времени на проведение основных операций
персоналом организации, что, безусловно, должно повлечь за собой
качественные улучшения в деятельности предприятия.
Основными функциями web-приложения являются:
1. Учет клиентов, которым оказываются услуги;
2. Добавление заявок партнеров, смена статуса, назначение
исполнителя;
3. Учет услуг, которые оказывает организация;
4. Экспорт данных в Excel по заявкам;
Регистрация и авторизация пользователей. В систему необходимо
также установить библиотеки или драйвера для работы с web-приложением:
а) сервер БД с установленной MySQL;
б) транслятор PHP версии 5.1;
в) web-сервер Apache версии 1.3.
Базой данных должны обеспечиваться: надёжность сохранения
информации; предоставляться незамедлительный доступ к ней; целостность
данных средствами СУБД. Структура таблиц БД должна быть не
70
избыточной и поддерживать сохранение всех без исключения необходимых
параметров. К тому же СУБД обязана обеспечивать интерфейс для работы
с приложением.
Входные данные web-приложения:
1. Информация о клиентах, сотрудниках, отделах;
2. Информация о заявках.
Выходные данные:
1. Отчетная excel-форма c перечнем заявок.
2. Отчетная excel-форма с данными по выбранной заявке.
Диаграмма вариантов применения играет ключевую роль в
моделировании поведения ИС или подсистемы (рисунок 29). Ею
отображается множество прецедентов, пользователей, а также и отношения
между ними. Данный вид диаграмм облегчают понимание системы,
подсистемы или класса, представляя взгляд со стороны на то, что данные
компоненты могут применять в соответствующем контексте.
Рисунок 29 Диаграмма вариантов применения
На диаграмме вариантов применения изображены следующие
пользователи:
1. Администратор;
71
2. Менеджер;
3. Исполнитель;
4. Клиент.
На диаграмме вариантов применения изображены работы:
1. Работа с пользователями (режим администратора);
2. Работа с заявками;
2.1 Добавление заявки (режим клиента);
2.3 Печать ведомости (режим менеджера);
2.4 Смена статуса (режим исполнителя, менеджера);
2.5 Печать заявки (режим исполнителя, менеджера);
3. Регистрация (режим клиента);
Диаграмма классов представляет статическую структуру модели ИС в
терминологии классов объектно-ориентированного программирования.
Диаграммой классов отражаются, в частности, многообразные взаимосвязи
между такими отдельными сущностями предметной области, как объекты и
подсистемы, а также предоставляется описание их внутренней структуры и
типов отношений.
Данная диаграмма, как правило, используется на стадии анализа,
чтобы выделить общие роли и обязанности сущностей, которыми
обеспечивается требуемое поведение системы. Диаграмма классов
используется для того, чтобы передать структуру классов, которыми
формируется архитектура системы. Диаграмма выполнена в среде
проектирования программного комплекса MS Visio (рисунок 30).
Были выделены следующие классы:
1. Request – заявка клиента на предоставление услуг службы;
2. Client – клиент службы;
3. District – отделы, выполняющие заявки;
4. Worker – сотрудник службы.
72
Рисунок 30 Диаграмма классов
Методы классов реализуются программно и описаны в таблице 10.
Таблица 10
Методы классов
Кнопка
Назначение
Действие
insert
Добавить
В таблицу базы данных добавляется новая запись
delete
Удалить
Удаляется текущая запись из таблицы базы данных
edit
Редактирование
Устанавливает режим редактирования текущей
записи
post
Сохранить
Изменения, внесенные в текущую запись,
записываются в таблицу базы данных
cancel
Отменить
Отменяет внесенные в текущую запись изменения
refresh
Обновить
Обновляет информацию из базы данных
export
Экспорт
Экспортирует данные из базы данных в Excel
Диаграмма размещения в UML моделирует физическое
развертывание артефактов на узлах.
Узлы представляются как прямоугольные параллелепипеды с
артефактами, расположенными в них, изображенными в виде
прямоугольников.
Как модель доступа к данным была избрана модель удалённого
доступа. Предполагаемая организация архитектуры аппаратной платформы
– клиент-серверная, которая изображена на рисунке 31.
+insert()
+edit()
+delete()
+refresh()
+post()
+cancel()
+export()
district
1..*
1..*
+insert()
+edit()
+delete()
+refresh()
+post()
+cancel()
+filter()
+export()
request
+insert()
+edit()
+delete()
+refresh()
+post()
+cancel()
client
1..*
1..1
+insert()
+edit()
+delete()
+refresh()
+post()
+cancel()
worker
1..*
1..1
73
Рисунок 31 Диаграмма размещения
Серверная часть состоит из:
а) сервер БД с установленной MySQL;
б) транслятор PHP версии 5.1;
в) web-сервер Apache версии 1.3.
Клиентская часть системы представлена пользовательским
браузером.
Описание логической модели данных лучше всего представить в виде
диаграммы «сущность-связь» (ER - диаграммы).
На рисунке 32 представлена ER-диаграмма данных.
Связи между сущностями неидентифицирующие, мощность 1 к n. Все
внешние ключи не входят в составной первичный ключ сущности.
Для обеспечения нормальной работы БД, устранения избыточности и
других аномалий необходимо произвести нормализацию БД и привести ее,
как минимум, к третьей нормальной форме.
Признаки принадлежности к нормальным формам:
Первая нормальная форма: Все атрибуты должны быть атомарными.
Вторая нормальная форма: Выполнение условий первой нормальной
формы. Каждый не ключевой атрибут функционально полно зависит от
составного ключа.
Третья нормальная форма: Выполнение условий второй нормальной
формы. Каждый не ключевой атрибут нетранзитивно зависит от первичного
ключа.
Сервер
СУБД
{ПО=MySQL}
Apache
{ПО=PHP}
Клиент
Пользователь
{ПО=Браузер}
74
Рисунок 32 ER-диаграмма
Проанализировав структуру отношений на предмет выполнения
условий нормальных форм, заключим, что все таблицы БД приведены к
третьей нормальной форме.
Диаграмма физической модели данных генерируется автоматически
программой Data Modeler (рисунок 33)
Рисунок 33 Физическая модель данных
Описание физической модели приведено в таблицах 11-14.
Заявка
Заявка_Номер
ОтделНомер (FK)
ТипЗаявкиНомер (FK)
СотрудникНомер (FK)
Клиент_Номер (FK)
Наименование
ОписаниеЗаявки
Дата заявки
Дата выполнения
Стату с
Примечание
Клиент
Клиент_Номер
ФИО
Email
Телефон
Реквиз иты
Логин
Пароль
Органиизация
Сотрудник
СотрудникНомер
ФИО
Должность
Телефон
Логин
Пароль
Отдел
ОтделНомер
Отдел
request
idrequest: Number
iddistrictend: Number (FK)
iddistrictstart: Number (FK)
idworker: Number (FK)
idclient: Number (FK)
name: String
date: Datetime
term: Datetime
status: String
package: String
cost: Number
client
idclient: Number
fio: String
mail: String
phone: String
info: String
login: String
parol: String
enterprise: String
worker
idworker: Number
fio: String
post: String
phone: String
login: String
parol: String
district
iddistrict: Number
district: String
75
Таблица 11
Таблица client
Таблица 12
Таблица worker
Таблица 13
Таблица request
Наименование
Описание
Тип поля
Разме
р поля
Ключ или
индекс
idclient
Номер клиента
Int,
автоинкремент
4
Первичный ключ
fio
ФИО
varchar
80
enterprise
Организация
varchar
80
mail
Электронная
почта
varchar
80
phone
Телефон
varchar
80
info
Реквизиты
varchar
80
login
Логин
varchar
80
parol
Пароль
varchar
80
Наименование
Описание
Тип поля
Разме
р поля
Ключ или
индекс
idworker
Номер клиента
Int,
автоинкремент
4
Первичный ключ
fio
ФИО
varchar
80
post
Должность
varchar
80
phone
Телефон
varchar
80
login
Логин
varchar
80
parol
Пароль
varchar
80
Наименовани
е
Описание
Тип поля
Разме
р поля
Ключ или
индекс
idrequest
Номер заявки
Int,
автоинкремент
4
Первичный ключ
idworker
Номер
исполнителя
Int
4
Внешний ключ,
таблица «worker»
idclient
Номер клиента
Int
4
Внешний ключ,
таблица «client»
iddistrict
Номер отдела
Int
4
Внешний ключ,
таблица «district»
iddistrict
Номер типа
заявки
Int
4
Внешний ключ,
таблица «district»
name
Наименование
varchar
80
date
Дата
date
3
term
Сроки
date
3
status
Статус
varchar
80
package
Описание
заявки
varchar
80
addressstart
Примечание
varchar
80
76
Таблица 14
Таблица district
2.3.3 Структурная схема пакета (дерево вызова программных
модулей)
В состав системы включены два модуля – БД MySQL и приложение
для обеспечения взаимодействия с БД, которое реализовано на языке
программирования PHP.
Работу с системой осуществляют при помощи любого браузера, для
чего потребуется установка локального сервера в локальной сети
предприятия, где также будет расположена и БД. Доступ к БД
реализовывается набором адреса в адресной строке браузера. Архитектура
сайта представлена на рис. 34.
Состоит система из 2-х модулей – из БД MySQL и приложения для
взаимодействия с информационной базой, которое выполнено на языке PHP
c применением HTML.
Информационным обеспечением web-приложения являются:
1. БД, в которой сохраняется вся необходимая информация.
2. Документы предприятия, на котором работает web-приложение,
на базе которых регламентируется введение информации в БД web-
приложении.
3. Требования к БД: поддержка обеспечения целостности данных,
соответствие третьей форме нормализации таблиц, оптимизированная
структура, контроль и предотвращение занесения неточной информации.
4. Требования к документам: непротиворечивость и полнота
информации для ввода ее в БД web-приложения.
Наименование
Описание
Тип поля
Разме
р поля
Ключ или
индекс
iddistrict
Номер отдела
Int,
автоинкремент
4
Первичный ключ
district
Отдел
string
80
77
База
данных
Сервер MySQL
Сценарии PHP
Сервер Apache
Локальная или публичная
сеть
Браузер пользователя
Пользователь
Организация хранения и
доступа к данным в базе
данных
Программный интерфейс для
построения системы
взаимодействия с базой
данных
Веб-сервер для обработки
запросов клиента
Передача данных
Отображение интерфейса,
данных и взаимодействия с
пользователем
Рисунок 34 Архитектура информационной системы
Информационными связями web-приложения считаются:
1. Внешние входящие связи: входные документы, вводимые в web-
приложение для сохранения в БД и дальнейших манипуляций.
2. Связи со СКУД: информация, которая о определённым
протоколам передаётся на сервер.
3. Внешние исходящие связи: результата поиска данных, экспорт
данных в Excel, генерируемые системой.