52
Рисунок 2.6 – Формат списка зарегистрированных в системе заявок
Рисунок 2.7 – Формат временной сводки по работе с той или иной заявкой
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
Представим дерево функций на рисунке 2.8.
Рисунок 2.8 – Дерево функций
53
Дерево функций показывает иерархию функций управления и обработки
данных, которые автоматизирует разрабатываемая информационная система [14].
Представим сценарий диалога, определим состав элементов диалога,
содержание каждого элемента и их соподчиненность (рисунок 2.9).
Рисунок 2.9 – Дерево диалога
2.3.2. Характеристика базы данных
Инфологическая модель
В рамках инфологического проектирования следует выделить такие
сущности:
● Пользователи
● Запросы
● Статусы запросов
● Типы запросов
● Приоритеты запросов
● История запросов
● Файлы
Сущность «Запросы» обладает такими атрибутами:
● Идентификатор.
● Статус запроса.
● Тип запроса.
54
● Тип проблемных ситуаций.
● Приоритет запроса.
● Заголовок
● Описание проблемы (информация).
● Работник, обнаруживший поломку/уязвимость
● Комментарий службы ИТ
● Оценочная стоимость работ
● Ответственное лицо
● Хеш-строка (идентификатор для просмотра пользователем)
Сущность «Статусы запросов» обладает такими атрибутами:
● Идентификатор.
● Наименование.
● Сущность «Типы запросов» обладает такими атрибутами:
● Идентификатор.
● Наименование.
Сущность «Типы проблемных ситуаций» обладает такими атрибутами:
● Идентификатор.
● Наименование.
● Информация.
Сущность «История запросов» обладает такими атрибутами:
● Идентификатор.
● Дата.
● Новый статус.
● Сущность «Файлы» обладает такими атрибутами:
● Идентификатор.
● Ссылка на запись в истории.
● Имя файла.
Даталогическая модель
После построения инфологической модели данных перейдем к разработке
даталогической и физической моделей данных.
55
Ранее была выбрана реляционная модель данных. Эта модель подразумевает
табличное хранение информации. Отметим, что эта модель исключает связь М-М,
разбивая ее на две связи 1-М.
Также при построении даталогической модели данных учтем и принципы
нормализации.
Нормализация представляет процесс разделения данных по отдельным
связанным таблицам. Нормализация устраняет избыточность данных (data
redundancy) и тем самым избежать нарушения целостности данных при их
изменении, то есть избежать аномалий изменения (update anomaly) [16].
Как правило, нормализация преимущественно применяется при восходящем
подходе проектировании базы данных, то есть когда мы все атрибуты, которые
надо сохранить в бд, группируем по сущностям, для которых затем создаются
таблицы. Однако при нисходящем подходе, когда вначале выявляются сущности, а
затем их атрибуты и связи между ними, нормализация также может применяться,
например, для проверки корректности спроектированных таблиц.
В ненормализованной форме таблица может хранить информацию о двух и
более сущностях. Также она может содержать повторяющиеся столбцы. Также
столбцы могут хранить повторяющиеся значения. В нормализованной же форме
каждая таблица хранит информацию только об одной сущности [15].
Нормализация предполагает применение нормальных форм к структуре
данных. Существуют 7 нормальных форм. Каждая нормальная форма (за
исключением первой) подразумевает, что к данным уже была применена
предыдущая нормальная форма. Например, прежде чем применить третью
нормальную форму к данным должна быть применена вторая нормальная форма. И
строго говоря, база данных считается нормализованной, если к ней применяется
третья нормальная форма и выше [17].
Перечислим нормальные формы [25]:
● Первая нормальная форма (1NF) предполагает, что сохраняемые
данные на пересечении строк и столбцов должны представлять скалярное значение,
а таблицы не должны содержать повторяющихся строк.
● Вторая нормальная форма (2NF) предполагает, что каждый столбец,
не являющийся ключом, должен зависеть от первичного ключа.
56
● Третья нормальная форма (3NF) предполагает, что каждый столбец, не
являющийся ключом, должен зависеть только от первичного ключа.
Произведем разработку даталогической модели данных в программе
AllFusion ERWin Data Modeler 7 [30].
Разработанная модель представлена на рисунке 2.10.
Рисунок 2.10 – Даталогическая модель
Поскольку для проектирования базы данных используется CASE-средство
ERWin, то автоматически перейдем к физической модели посредством выбора
меню (рисунок 2.11).
Рисунок 2.11 – Переход к физической модели
Так как выбрана СУБД MySql и она может некорректно работать с русскими
названиями таблиц и атрибутов, то русские имена были заменены английскими
(рисунок 2.12).
57
Рисунок 2.12 – Физическая модель в ERWin
Далее был получен скрипт создания базы данных, который был
импортирован в клиент СУБД MySql – phpmyadmin. В его графическом дизайнере
разработанная база данных выглядит так (рисунок 2.13).
Рисунок 2.13 – База данных в СУБД MySql
58
Скрипт SQL создания базы данных представлен в приложении А.
2.3.3. Структурная схема пакета (дерево вызова программных модулей)
Для построения структурной схемы пакета воспользуемся специальной
бесплатной программой NikFileTree (рисунок 2.14).
Рисунок 2.14 – Построение структурной схемы пакета
Поскольку следует показать иерархию подчиненности программных
модулей, то в качестве расширения файлов указаны «*.php».
Дерево вызова программных модулей представлено на рисунке 2.15.
59
Рисунок 2.15 – Дерево вызова программных модулей
2.3.4. Описание программных модулей
В результате проектирования выделены такие логические модели ИС:
● Модуль инициализации приложения
● Модуль системной логики приложения
● Модуль пользовательского интерфейса приложения
● Модуль взаимодействия с БД приложения
Представим таблицу описания функций модулей (таблица 2.11).
Таблица 2.11
Описание функций модулей
№ п/п
Наименование модуля
Функции модуля
2
Модуль инициализации
Содержит функции по первоначальной
настройке ИС. Осуществляет также
инициализацию вспомогательных подмодулей.
3
Модуль системной
логики
Содержит в себе иерархию подчиняющихся
форм приложения, что обеспечивает логичную
60
и интуитивно понятную программную
навигацию
4
Модуль взаимодействия
с БД
Отвечает за обеспечение связи приложения с
БД MySql.
Отвечает за выполнение запросов к БД и
предоставление для других модулей ИС
унифицированных процедур для выполнения
основных операций над данными: чтение,
запись, изменение, удаление.
5
Модуль
пользовательского
интерфейса
Содержит функции, включающие:
Формирование пользовательского интерфейса
согласно хранимым шаблонам
Данное разделение больше логическое, чем физическое, поскольку в
реальности присутствуют несколько десятков файлов, каждый из которых отвечает
за определенный набор специфических функций. Однако все эти файлы могут быть
разделены на логические группы, представленные в таблице выше.
Для того чтобы обеспечить возможность доступа многих сотрудников к ИС,
система должна иметь клиент-серверную архитектуру, что подразумевает наличие
серверного вычислительного ресурса и клиентских машин.
Схема архитектуры системы с точки зрения логического взаимодействия
представлена на рисунке 2.16.
Рисунок 2.16 – Логическая архитектура системы
Пользователь системы осуществляет некоторое действие через
пользовательский интерфейс. Модуль интерфейса передает это действие
61
логическому модулю системной логики, который в случае необходимости
обращается к модулю взаимодействия с БД, который, в свою очередь, посылает
SQL запрос к СУБД с заданными параметрами (база данных, таблицы и т.д.).
От СУБД поступает ответ – результат выполнения запроса, который затем
поступает обратно в модуль системной логики и при необходимости
результирующие данные через модуль интерфейса отображаются оператору ИС.
Программные модули разработаны в рамках парадигмы MVC.
Model-View-Controller (MVC, «Модель-Представление-Контроллер»,
«Модель-Вид-Контроллер») – схема разделения данных приложения,
пользовательского интерфейса и управляющей логики на три отдельных
компонента: модель, представление и контроллер – таким образом, что
модификация каждого компонента может осуществляться независимо.
Модель (Model) предоставляет данные и реагирует на команды контроллера,
изменяя свое состояние.
Представление (View) отвечает за отображение данных модели
пользователю, реагируя на изменения модели.
Контроллер (Controller) интерпретирует действия пользователя, оповещая
модель о необходимости изменений.
Схему работы шаблона проектирования MVC для разработанного
приложения можно изобразить на рисунке 2.17.
Рисунок 2.17 – Схема работы шаблона проектирования MVC