116
117
2.3.2. Характеристика базы данных
Как уже упоминалось ранее в главе о выборе средств программирования,
используемая мной для разработки Системы учета контрольных и экспертно-
аналитических проверок база данных MongoDB, документоориентированная
система управления базами данных с открытым исходным кодом, не требующая
описания схемы таблиц. Классифицирована как NoSQL, использует JSON-
подобные документы и схему базы данных.
Для удобства разработки и маштабирования мною так же используется
Document-Object Mapper - MongoEngine. Он использует простой декларативный
API. Все коллекции описаны классами на языке Python. База данных для моего
приложения в конечном итоге состоит из 5 коллекций (таблиц), однако в коде
Python описана 11 классами, 6 из которых описаны как встроенные документы
(EmbeddedDocument), остальные 5 как основные документы (Document):
1. Класс Roles – роли (Document) (Таблица 3)
2. Класс Users – пользователи (Document) (Таблица 4)
3. Класс ChecksObjects – объекты проверок (Document) (Талица 5)
4. Класс Checks – проверки (Document) (Таблица 6)
5. Класс Classifier – классификатор нарушений (Document) (Таблица 7)
6. Класс ClassifierSide – раздел классификатора (EmbeddedDocument)
(Таблица 8)
7. Класс ClassifierSubSide – подраздел классифкатора (EmbeddedDocument)
(Таблица 9)
8. Класс ClassifierItem – запись классификатора (EmbeddedDocument)
(Таблица 10)
9. Класс repHistory – история изменений и комментариев
(EmbeddedDocument) (Таблица 11)
10. Класс AssignedUsr – пользователи допущенные к проверке
(EmbeddedDocument) (Таблица 12)
11. Класс Offenses – нарушения объектов (EmbeddedDocument) (Таблица 13)
118
Таблица 3
Структура класса Roles привилегий
Наименование
поля
Идентифика
тор
поля
Тип
поля
Описание
Уникальный
идентификатор
id
ObjectID
Автогенерируемый
Название роли
roleName
StringField
Обязательное, Уникальное
Описание роли
description
StringField
Доступ
access
DictField
Обязательное
Коллекция ролей пользователей хранит название, описание роли, а так же
словарь ключ-значение описывающий доступ к модулям ({Название
модуля:Уровень доступа}).
Таблица 4
Структура класса Users пользователей
Наименование
поля
Идентификатор
поля
Тип
поля
Описание
Уникальный
идентификатор
id
ObjectID
Автогенерируемый
Логин пользователя
login
StringField
Обязательное,
Уникальное
Имя пользователя
name
StringField
Уникальное
Должность
office
StringField
Роль
role
ReferenceField
Обязательное
Состояние
state
StringField
Обязательное
Причина блокировки
blockReason
StringField
Попытки входа
loginAttempt
IntLield
Хэш пароля
passwordHash
StringField
Обязательное
Коллекция пользователей хранит описание пользователей, их логин,
пароль, роль и прочую необходимую информацию.
Таблица 5
Структура класса ChecksObjects объектов проверок
Наименование
поля
Идентиф
икатор
поля
Тип
поля
Описание
Уникальный идентификатор
id
ObjectID
Автогенерируемый
Название организации
orgName
StringField
Обязательное
119
Коллекция содержит объекты проверок (организации), их названия, тип, а
так же встроенную коллекцию нарушений данного объекта проверки.
Таблица 6
Структура класса Checks проверок
Наименование
поля
Идентификат
ор
поля
Тип
поля
Описание
Уникальный идентификатор
id
ObjectID
Автогенерируемый
Создатель проверки
creator
ReferenceField
Обязательное
Дата создания
created
DateTimeField
Обязательное,
Автогенерируемое
Состояние проверки
state
StringField
Обязательное
Назначенные пользователи
assignedUsers
EmbeddedDocume
ntListField
AssignedUsr
Тип проверки
checkType
StringField
Участники проверки
members
ListField
список StringField
Поручители
commissioned
ListField
список StringField
Редакция плана
plan
StringField
Обязательное
Пункт плана
planItem
StringField
Обязательное
Название проверки
planText
StringField
Обязательное
Объекты проверки
checkObjects
ListField
ReferenceField(Che
cksObjects)
Контроль
control
StringField
История изменений
reportsHistory
EmbeddedDocume
ntListField
repHistory
Коллекция содержит данные о проверках, их названия согласно плана
проверок, коллекцию ссылок на свои объекты и остальную необходимую
информацию.
Таблица 7
Структура класса Classifier классификатора нарушений
Наименование
поля
Идентифи
катор
поля
Тип
поля
Описание
Уникальный идентификатор
id
ObjectID
Автогенерируемый
Название плана
title
StringField
Обязательное
Редакция плана
redaction
StringField
Обязательное,
Уникальное
Разделы плана
sides
EmbeddedDocument
ListField
ClassifierSide
Тип организации
orgType
StringField
Обязательное
Нарушения организации
offenses
EmbeddedDocumentList
Field
Offenses
120
Коллекция содержит необходимую информацию о классификаторе
нарушений, и встроенную коллекцию разделов плана.
Таблица 8
Структура класса ClassifierSide разделов классификатора нарушений
Наименование
поля
Идентиф
икатор
поля
Тип
поля
Описание
Номер раздела
nomber
StringField
Обязательное
Название раздела
title
StringField
Обязательное
Подразделы
subSides
EmbeddedDocument
ListField
ClassifierSubSide
Встроенная коллекция содержит название раздела классификатора
нарушений, его номер и встроенную коллекцию подразделов.
Таблица 9
Структура класса ClassifierSubSide подразделов классификатора нарушений
Наименование
поля
Идентиф
икатор
поля
Тип
поля
Описание
Номер раздела
nomber
StringField
Обязательное
Название раздела
title
StringField
Обязательное
Подразделы
items
EmbeddedDocument
ListField
ClassifierItem
Встроенная коллекция содержит название подраздела классификатора
нарушений, его номер и встроенную коллекцию записей классификатора.
Таблица 10
Структура класса ClassifierItem записей кассификатора
Наименование
поля
Идентификатор
поля
Тип
поля
Описание
Номер записи
nomber
StringField
Обязательное
Вид нарушения
typeViolation
StringField
Правовые основания
qualificationViolations
StringField
Единица измерения
unit
StringField
Группа нарушения
violationGroup
StringField
Мера ответственности
liabilityMeasure
StringField
Встроенная коллекция содержит информацию о нарушении.
Таблица 11
Структура класса repHistory истории изменений проверки и комментариев
121
Наименование
поля
Идентификатор
поля
Тип
поля
Описание
Дата добавление
date
StringField
Обязательное
Запись\комментарий
report
StringField
Обязательное
Встроенная коллекция содержит дату и текс записей и комментариев
попроверке.
Таблица 12
Структура класса AssignedUsr списка пользователей
Наименование
поля
Идентиф
икатор
поля
Тип
поля
Описание
Пользователь
user
ReferenceField
Обязательное
Тип доступа
access
StringField
Обязательное
Встроенная коллекция содержит идентификатор пользователя допущенного
к проверке и тип доступа
Таблица 13
Структура класса Offenses нарушений объектов проверок
Наименование
поля
Идентификато
р
поля
Тип
поля
Описание
Тип нарушения
offenseType
StringFiel
d
Обязательное
Количество нарушений
offenseNumber
IntField
Количество нарушений
с финансовой оценкой
financialAssess
mentNumber
IntField
Количество нарушений
без оценки
notFinancialAss
essmentNumber
IntField
Денежная сумма
moneySumm
IntField
Основание нарушения
groundText
StringFiel
d
Комментарий
comment
StringFiel
d
Описание по классификатору
classifier
DictField
Встроенная коллекция содержит информацию о нарушении, тип,
количество нарушений, описание нарушения в случае отсутствия его в
классификаторе или описание из классификатора.
ER модель базы данных определяет состав и зависимость связей таблиц,
отражающих содержание информационной модели. Рисунок 16.
122
Рис. 16 ERмодель базы данный
123
2.3.3. Структурная схема пакета (дерево вызова процедур и
программ)
На основе результатов, полученных в предыдущем пункте, построено
дерево программных модулей, отражающих структурную схему проекта Flask
фреймворка. Данные представлены в виде таблицы 14.
Таблица 14
Модули серверной части системы
№
п/п
Наименование
модуля/файла
Функции модуля/файла
1 app
Основной модуль серверной части, содержит остальные
модули проекта: auth, users, checks, main, reports, static,
models.py
2 models.py Содержит классы описывающие модели базы данных
3 auth Содержит шаблон и логику страницы авторизации
4 users
Содержит шаблоны и логику страниц управления
пользователями и ролями
5 main
Содержит шаблоны и логику управления нарушениями
проверок, а так же базовый шаблон страниц и главной
панели навигации
6 checks
Модуль содержит шаблоны и логику управления
проверками и объектами проверок
7 reports Содержит шаблон и логику генерации отчетов
8 static
Папка для размещения статических файлов сервера,
вспомогательных библиотек, временных файлов.
2.3.4. Описание программных модулей
Поскольку проект системы реализован на базе web-фреймворка Flask, все
программные модули имеют схожую структуру и подчиняются общим
правилам. Что касается выбора структуры Flask приложения, то фреймворк дает
возможность определять структуру в зависимости от потребностей
124
разработчика. Таким образом мной был выбран вариант полного разделения
проекта на модули по их назначению. Каждый модуль имеет собственную папку
template, которая содержит шаблоны страниц использованные в модуле, не
смотря на то что средствами встроенного шаблонизатора Jinja2 страницы
модулей наследуются от общего шаблона base.html (расположенного в модуле
main и задающего базовую структуру веб страниц и импортирующего
необходимые JavaScript библиотеки) шаблоны модулей находятся в
соответствующих им папках папках.
Такой структуры web приложения удалось легко достичь используя
плагин flask-blueprints.
По этому же принципу в проекте разделены и расположены файлы
маршрутов routes.py. Каждый файл маршрутов отвечает за свой модуль.
Исключениями являются папка проекта static, в которой хранятся JS
библиотеки для реализации интерфейса на стороне клиента. Эта папка является
общей для всех модулей приложения. И файл models.py где объявлены классы
структуры базы данных, которые используются в каждом модуле проекта.
В целом модули имеют схожий принцип работы. Это обработка
поступившего на сервер запроса пользователя, его обработка, запрос к базе
данных, генерация страницы ответа. И имеют различия работы в частных
случаях, например при проверке прав доступа пользователя или при генерации
файлов отчетов, где вместо страницы ответа пользователю возвращается файл
отчета.
2.4. Контрольный пример реализации проекта
Как уже говорилось выше, вход в систему осуществляется по средствам
авторизации пользователей. Пример формы авторизации показан на рисунке 17.
Рис. 17 авторизация пользователей
125
В случае не правильного ввода авторизационных данных Система сообщает
пользователю об ошибке (рисунок 18).
Рис.18 Уведомление об ошибке ввода авторизационных данных
После успешного вода логин и пароля пользователю открывается главная
страница (рисунок 19).
Рис. 19 Главная страница приложения
На этом этапе пользователю доступны функции редактирования доступных
ему проверок.