74
Подсистема приема информации отвечает за сбор данных по передающим
каналам различными методами: смешанным, автоматизированным, ручным.
Оператор отвечает за первичный сбор и разделение данных. Все
полученные данные изучаются на предмет нахождения сущностей, служащих
шаблонами для таблиц БД. Затем все данные направляются в системы управления,
хранения и анализа данных.
Эта подсистема реализует предмашинную подготовку данных и заносит их
в БД, которая является информационной моделью предметной области. Оператор
вместе с админом БД по отлаженной схеме заполняют БД требуемыми данными.
Тут же проверяется честность и непротиворечивость всех данных и выполняется
обработка, корректировка, сохранение всех данных, и восстановление, если
необходимо. Базовая часть такой подсистемы – сама БД, которая управляется
СУБД.
БД сама выражается как именованная сущность построенных и
разделенных данных, позволяющая отразить состояние объектов и их отношения
в выделенной предметной области.
В рамках контроля компанией главная задача руководства идет на
получение данных, их изучение и передачу сотрудникам. Для результативного
управления фирмой важно наперед знать ситуацию. Помимо интуитивных оценок
сегодня также используется обоснованная оценка состояния компании в рамках
проведенных изменений, другим словами, экстраполяция. [37]
Сценарии диалога системы приведен на рисунке 2.3.
75
Рисунок 2.3 Сценарий диалога
Сценарии диалога для администратора системы и пользователя отличаются
только возможностью редактирования списка пользователей у администратора. В
остальном пункты меню, а также порядок регистрации клиентов, договоров,
регистрации выполнения договора, заполнения и редактирования справочников
одинаков.
2.3.2 Характеристика базы данных
Весь путь создания БД включает 3 фазы: концепция, логическая модель и
проектирование прототипа. Любая фаза состоит из необходимой модели данных,
которая становится источником данных для другой фазы. Основное значение тут
возложено на концепцию, реализуемую в ракмкх параметров, указанных в
спецификации пользовательских требований. Подготовка концепции БД никак не
пересекается в такие подробности ее реализации, как тип применяемой целевой
СУБД, тип используемой вычислительной платформы и т.п., но качество
концепции тут уже имеет решающее значение, позволяющее отразить
трудозатраты на создание системы, ее скорость работы и текущий успех. Опыт
Выход
Отчеты
Модули
Заказы
Каталог услуг
Главное меню
Авторизация
Печать
Услуги по
заказу
Пользователи
Просмотр заказа
Загрузить
изображения
Список заказов
Отчет по работе
менеджеров
Удаление
Прайс-лист
Просмотр
Журнал учета заявок
Редактирование
Отчет Договор
Добавление
услуги
Отчет Заявка
Список услуг
76
создания и использования ИС говорит о том, что ошибки, возможные в процессе
этого этапа, очень трудно выявить и устранить, поскольку они встречаются
обычно уже на последующих этапах создания системы – при реализации и
поддержке.
На этапе проектирования логической модели концепция данных переходит
в логическую модель, создаваемую в рамках указанной модели хранения
информации основной СУБД. По итогу, этот этап отражает, какая СУБД
используется в качестве целевой - иерархическая, сетевая, реляционная или
объектно-ориентированная. Тут проходят все остальные аспекты начальной
СУБД – к примеру, некие особенности физической реализации хранения данных.
Логическая модель, отражающая особенности отображения о создаваемой
системе больше одного типа пользователей, считается глобальной логической
моделью данных. Есть пара базовых подходов для создания совокупной
логической модели: метод внедрения представлений и централизованный способ.
Если создается крупная ИС, лучше и эффективнее использовать второй подход,
когда общая логическая модель реализуется методом слияния отдельных моделей,
показывающих представления отдельных групп пользователей.
В процессе создания прототипа принимаются решения о вариантах
реализации текущей БД. Поэтому физическое проектирование очень сильно
завязано на конкретной СУБД. Между разработкой логической модели и
подготовкой прототипа есть постоянная обратная связь, т.к. все решения,
принимаемые на этапе создания прототипа для повышения производительности
системы, очень влияют и на структуру логической модели. Цель создания
прототипа БД заключается в описании варианта итоговой реализации проекта
всей БД.
Для отображения отношений между сущностями используются связи.
Связи существуют, если экземпляры сущностей логически взаимосвязаны.
Схема базы данных показана на рисунке 2.4.
77
Рисунок 2.4 Схема базы данных
Характеристика каждой таблицы приведена ниже.
Таблица 2.5
Структура таблицы request
Поле
Тип
Null
По умолчанию
id
int(11)
Нет
registration_date
datetime
Да
NULL
id_creator
int(11)
Да
NULL
id_request_status
int(11)
Да
NULL
id_client
int(11)
Да
NULL
order_date
datetime
Да
NULL
order_number
int(11)
Да
NULL
cost
double
Да
NULL
description
longtext
Да
NULL
id_executor
int(11)
Да
NULL
78
paid
bit(1)
Да
NULL
Таблица 2.6
Структура таблицы request_service
Поле
Тип
Null
По умолчанию
id
int(11)
Нет
id_request
int(11)
Да
NULL
registration_date
datetime
Да
NULL
id_service
int(11)
Да
NULL
amount
double
Да
NULL
cost
double
Да
NULL
total
double
Да
NULL
description
longtext
Да
NULL
id_creator
int(11)
Да
NULL
Таблица 2.7
Структура таблицы request_status
Поле
Тип
Null
По умолчанию
id
int(11)
Нет
title
varchar(255)
Да
NULL
Таблица 2.8
Структура таблицы service
Поле
Тип
Null
По умолчанию
id
int(11)
Нет
title
varchar(255)
Да
NULL
cost
double
Да
NULL
description
longtext
Да
NULL
Таблица 2.9
Структура таблицы user
Поле
Тип
Null
По умолчанию
id
int(11)
Нет
username
varchar(255)
Нет
79
password_hash
varchar(255)
Нет
auth_key
varchar(32)
Нет
password_reset_token
varchar(255)
Да
NULL
activation_token
varchar(255)
Да
NULL
email
varchar(255)
Нет
status
smallint(6)
Нет
10
created_at
int(11)
Нет
updated_at
int(11)
Нет
nikname
varchar(255)
Да
NULL
id_user_type
int(11)
Да
NULL
last_name
varchar(255)
Да
NULL
first_name
varchar(255)
Да
NULL
middle_name
varchar(255)
Да
NULL
phone
varchar(255)
Да
NULL
report_date_1
datetime
Да
NULL
report_date_2
datetime
Да
NULL
id_request
int(11)
Да
NULL
Таблица 2.10
Структура таблицы user_type
Поле
Тип
Null
По умолчанию
id
int(11)
Нет
title
varchar(255)
Да
NULL
2.3.3 Структурная схема пакета (дерево вызова программных
модулей)
Схема вызова программных модулей представлена на Рисунке 2.5.
80
Рисунок 2.5 Схема вызова программных модулей
Описание программных модулей представлено в Таблице 2.11.
Таблица 2.11
Описание программных модулей
№
п/п
Наименование модуля
Функции модуля
1)
ПМ Авторизация
Выполняет авторизацию пользователей при
их доступе в систему
2)
ПМ Главное меню
Производит вызов меню, для каждого вида
пользователей - своего
3)
ПМ работы со
справочниками
Содержит определенные процедуры,
позволяющие осуществлять редактирование
справочников
ПМ Вывода на
печать
ПМ Справочника
Услуга
ПМ формирования
отчетов
ПМ Справочника
Пользователь
ПМ работы с
договорами
ПМ Справочника
Клиент
ПМ работы с
учетом заявок
ПМ работы с со
справочниками
ПМ Главное меню
ПМ Авторизация
81
№
п/п
Наименование модуля
Функции модуля
4)
ПМ Работа с отчетами
Формирует документы в соответствии с
заданными критериями, регистрирует
документы, добавляет записи
5)
ПМ получения отчетов
Содержит заранее определенные процедуры
формирования отчетных документов
6)
ПМ вывода на печать
Выводит результатные документы на печать
2.3.4 Описание программных модулей
На рисунке 2.6 представлена блок-схема обобщенного алгоритма работы
информационной системы. Дадим пояснения относительно данной схемы:
-
после запуска пользователем клиентской части ИС последняя пытается
считать настройки из конфигурационного файла;
-
если настройки соединения считать не удалось, то используются
настройки соединения по умолчанию;
-
затем клиентская часть создает клиентский сокет и пытается соединиться
с сокетом сервера, соединение осуществляется посредством протокола TCP/IP;
-
если соединиться с сокетом сервера не удалось, то выдается
соответствующее сообщение об ошибке и приложение завершает работу;
-
вызывается диалог авторизации;
-
в случае успешной авторизации клиент запрашивает у сервера начальные
данные (в зависимости от стартовой экранной формы клиентского приложения);
Впоследствии пользователь в ходе работы с клиентским приложением
может модифицировать данные ИС, просматривать их и запрашивать отчеты;
-
клиентское приложение в случае каких-либо действий пользователя,
требующих обновления данных, запрашивает эти данные у сервера, после чего
отображает их и ожидает дальнейших действий пользователя;
-
считается, что серверная часть ИС уже запущена и ожидает подключений
клиентов.
82
Данный алгоритм не отражает стандартные действия приложений, не
относящиеся к их бизнес-логике: создание приложения, обновление данных
элементов управления и так далее, так как большинство этих действий
обрабатывается уже существующими функциями, реализованными
разработчиками php.
Начало
Считывание настроек
для соединения с
сервером из файла
нет
Настройки
считаны?
да
Авторизация
успешна?
нет
Соединение
установлено?
да
нет
Вывод
сообщения
об ошибке
П
Пользователь
да
корректирует
данные?
нет
Пользователь да
запрашивает
отчеты?
нет
Пользователь
хочет завершить
работу?
да
нет
П
П
Конец
Закрытие
соединения
Формирование
отчетов
Обновление
модифицированны
х данных
Запрос данных у
сервера
Корректировка
данных ПС
Запрос
начальных
данных
да
Авторизация
Соединение с
серверным
сокетом
Создание сокета
клиента
Задание настроек
по умолчанию
83
Рисунок 2.6 Блок-схема обобщенного алгоритма работы информационной
системы
2.4 Контрольный пример реализации проекта и его описание
В данном пункте рассмотрим пример работы ИС. Форма авторизации
приведена на рисунке 2.7.
Рисунок 2.7 Форма авторизации
После авторизации пользователь видит главную форму программы,
которая приведена на рисунке 2.8.