ПЗ Влад

Министерство образования Республики Беларусь
Учреждение образования
БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ИНФОРМАТИКИ И РАДИОЭЛЕКТРОНИКИ
Факультет компьютерных систем и сетей

Кафедра программного обеспечения информационных технологий
К защите допустить:
Заведующая кафедрой ПОИТ
__________________ Н. В. Лапицкая
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к дипломному проекту
на тему:
ПРОГРАММНОЕ СРЕДСТВО «ЕДИНЫЙ РЕЕСТР ЛИЦЕНЗИЙ»

С ИСПОЛЬЗОВАНИЕМ СТЕКА ТЕХНОЛОГИЙ BACKEND: JAVA,
SPRING BOOT
БГУИР ДП 1-40 01 01 01 031 ПЗ
Студент В. А. Грамович
Руководитель И. М. Марина
Консультанты:
от кафедры ПОИТ И. М. Марина
по экономической части К. Р. Литвинович
Нормоконтролер С. В. Болтак
Рецензент
Минск 2018
РЕФЕРАТ
ПРОГРАММНОЕ СРЕДСТВО «ЕДИНЫЙ РЕЕСТР ЛИЦЕНЗИЙ» С

ИСПОЛЬЗОВАНИЕМ СТЕКА ТЕХНОЛОГИЙ BACKEND: JAVA, SPRING
BOOT: дипломный проект / В. А. Грамович. – Минск: БГУИР, 2018, – п.з. –
95 с., чертежей (плакатов) – 7 л. формата А1.
Цель работы – разработка программного средства «единый реестр

лицензий» с использованием стека технологий Backend: Java, Spring Boot.
Разработка данного программного средства обеспечит формирование
единого реестра лицензий, в котором будут храниться лицензии со всех
лицензирующих органов Республики Беларусь. Также программное средство
предоставит удобный интерфейс для просмотра, добавления, поиска и
редактирования лицензий.
Проведен анализ государственных информационных систем.
Разработана база данных для удобного хранения и использования
лицензий, лицензирующих органов и лицензиатов.
Реализовано добавление лицензий в реестр с помощью веб-формы, xml-
файла и excel-файла.
Реализован алгоритм создания электронного номера лицензий.
Создана возможность регистрации пользователей в системе с помощью
электронно-цифровой подписи, так же подтверждение отправленных
лицензий с помощью ЭЦП.
В результате был создан веб-сайт для упрощённого просмотра,
добавления и поиска лицензий.
Министерство образования Республики Беларусь
Учреждение образования
БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ИНФОРМАТИКИ
И РАДИОЭЛЕКТРОНИКИ
Факультет КС и С Кафедра ПОИТ
Специальность 1-40 01 01 Специализация 01
УТВЕРЖДАЮ
Н.В.Лапицкая
« » 2018 г.
ЗАДАНИЕ
по дипломному проекту студента
Грамовича Владислава Александровича

(фамилия, имя, отчество)
1. Тема проекта: Программное средство «Единый реестр лицензий» с использова-

нием стека технологий BackEnd: Java, Spring Boot
утверждена приказом по университету от « 30 » марта 2018 г. № 549-c

2. Срок сдачи студентом законченной работы 01 июня 2018 года
3. Исходные данные к проекту Тип приложения: веб-приложение

Язык программирования – Java; Перечень выполняемых функций: регистрация,
аутентификация, поддержка системы ролей, добавление, удаление и редактирование
лицензий, создание электронного номера лицензии, поиск по лицензиям, загрузка и
обработка excel и xml файлов, связь с сторонним сервисом
Назначение разработки: разработка государственной информационный системы «Единый
реестр лицензий» для упрощённого доступа к реестрам лицензий
4. Содержание пояснительной записки (перечень подлежащих разработке вопросов)
Введение
1 Анализ современных государственных информационных систем и определение цели
дипломного проектирования
2 Моделирование предметной области и разработка функциональных требований
3 Проектирование программного средства
4 Реализация программного средства
5 Тестирование программного средства
6 Руководство пользователя
7 Технико-экономическое обоснование
Заключение
Список использованных источников
Приложение А Текст программного средства
5. Перечень графического материала (с точным указанием наименования) и обозначения
вида и типа материала)
Диаграмма базы данных. Плакат – формат А1, лист 1.
Диаграмма прецедентов. Плакат – формат А1, лист 1.
Диаграмма компонентов. Плакат – формат А1, лист 1.
Результат работы программы. Плакат – формат А1, лист 1.
Алгоритм работы приложения. Схема алгоритма – формат А1, лист 1.
Алгоритм добавления лицензии. Алгоритм формирования электронного номера лицензии
Схема алгоритма – формат А1, лист 1.
Алгоритм добавления нового пользователя. Схема алгоритма – формат А1, лист 1.
6. Содержание задания по технико–экономическому обоснованию

Расчет экономической эффективности от внедрения программного средства
Задание выдал / К. Р. Литвинович /
КАЛЕНДАРНЫЙ ПЛАН
Наименование этапов дипломного проекта Объём Срок Примечан
(работы) этапа в выполнения ие
% этапа
Аналитический обзор программных продуктов,
моделей и методов по теме дипломного
проектирования 15-20 23.03–01.04
Моделирование предметной области и
разработка функциональных требований 20-15 02.04–08.04
Проектирование программного средства 20-15 09.04–15.04
Разработка программного средства 15-20 16.04–29.04
Тестирование программного средства и
создание руководства пользователя 10 30.04–13.05
Оформление пояснительной записки
и графического материала 20 14.05–31.05
Дата выдачи задания 23 марта 2018 г. Руководитель / И.М. Марина /
Задание принял к исполнению / В. А. Грамович /

СОДЕРЖАНИЕ
Введение ................................................................................................................... 8
1 Анализ современных государственных информационных систем и
определение цели дипломного проектирования .............................................. 9
1.1 Анализ предметной области ........................................................................ 9
1.2 Общая информация о государственных информационных системах ... 10
1.3 Обзор существующих аналогов ................................................................. 10
1.4 Цель и задачи дипломного проекта ........................................................... 20
2 Моделирование предметной области и разработка функциональных
требований ......................................................................................................... 24
2.1 Описание функциональности программного средства ........................... 24
2.2 Спецификация функциональных требований .......................................... 27
3 Проектирование программного средства ........................................................ 33
3.1 Проектирование взаимодействия модулей ПС ........................................ 33
3.2 Обоснование выбора СУБД ....................................................................... 34
3.3 Проектирование модели базы данных ...................................................... 35
3.4 Разработка архитектуры ПС ...................................................................... 40
3.5 Алгоритм работы приложения................................................................... 44
3.6 Алгоритм добавления лицензий ................................................................ 45
3.7 Алгоритм формирования электронного номера лицензии ..................... 47
3.8 Алгоритм добавления нового пользователя ............................................. 48
4 Реализация программного средства ................................................................. 50
4.1 Обоснование выбора языка и среды программирования ........................ 50
4.2 Разработка моделей данных ....................................................................... 53
4.3 Описание классов и методов серверной части приложения .................. 54
5 Тестирование программного средства ............................................................. 58
6 Руководство пользователя ................................................................................. 63
7 Технико-экономическое обоснование разработки и внедрения ПС ............. 69
7.1 Расчёт сметы затрат и цены программного средства .............................. 69
7.2 Расчёт заработной платы исполнителей ................................................... 73
7.3 Оценка экономической эффективности применения программного
средства у пользователя ............................................................................. 76
7.4 Расчёт капитальных затрат......................................................................... 78
7.5 Расчёт экономического эффекта................................................................ 78
7.6 Выводы по технико-экономическому обоснованию ............................... 81
Заключение ............................................................................................................ 82
Список использованных источников .................................................................. 84
Приложение A (обязательное). Исходный код .................................................. 85
5
ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ
В настоящей пояснительной записке применяются следующие опреде-

ления и сокращения:
База данных – совокупность взаимосвязанных данных, организованных
в соответствии со схемой базы данных таким образом, чтобы с ними мог
работать пользователь.
Интерфейс программирования приложений – набор готовых классов,
процедур, функций, структур и констант, предоставляемых приложением для
использования во внешних программных продуктах.
Прикладная программа – программа, предназначенная для решения
Система управления базами данных – совокупность программ и
языковых средств, предназначенных для управления данными в базе данных,
ведения базы данных и обеспечения взаимодействия с программами.
Системная программа – программа, предназначенная для поддержания
работоспособности системы обработки информации или повышения
эффективности ее использования в процессе выполнения программ.
Язык программирования – формальная знаковая система, предназна-
ченная для записи компьютерных программ.
Лицензирующие органы – республиканские органы государственного
управления и иные государственные организации, подчиненные
Правительству Республики Беларусь, местные исполнительные и
распорядительные органы, другие государственные органы,
уполномоченные осуществлять лицензирование.
Лицензиат – юридическое лицо Республики Беларусь, индивидуальный
предприниматель, зарегистрированный в Республике Беларусь, иностранное
юридическое лицо, иностранная организация, адвокат, физическое лицо,
осуществляющее деятельность, связанную с коллекционированием и
экспонированием оружия и боеприпасов, которые имеют специальные
разрешения (лицензии).
Заинтересованные лица – юридические и физические лица, а также
государственные органы и иные государственные организации, которые
запрашивают информацию из реестра лицензий.
Информационная система – совокупность содержащейся в базах
данных информации и обеспечивающих ее обработку информационных
технологий и технических средств.
6
БД – база данных
ОС – операционная система
ПС – программное средство
СУБД – система управления базами данных
ЭВМ – электронно-вычислительная машина
AJAX – Asynchronous JavaScript and XML («асинхронный JavaScript и
XML»)
API – Application Programming Interface (интерфейс программирования
приложений)
HTTP – HyperText Transfer Protocol (протокол передачи гипертекста)
MVC – Model–View–Controller («Модель–Вид–Контроллер»)
JSON – JavaScript Object Notation (текстовый формат обмена данными,
основанный на JavaScript)
REST – Representational State Transfer («передача состояния представле-
ния» – архитектурный стиль взаимодействия компонентов распределенного
приложения в сети)
UML – Unified Modeling Language (унифицированный язык моделиро-
вания)
XML – Xtensible Markup Language (расширяемый язык разметки)
ГИС – государственная информационная система
ЕРЛ – единый реестр лицензий
ЭЦП – электронно-цифровая подпись
7
ВВЕДЕНИЕ
Информационные технологии все больше затрагивают сферы

деятельности человека. И сейчас под натиском информационных и
телекоммуникационным технологиям необходимо введение информационных
систем в те области, где они не применяются или слабо развиты и которые
помогут уменьшить затраты, время на обработку данных, и увеличить
производительность труда.
В настоящее время Республика Беларусь входит в топ ведущих «ИТ -
стран» в Восточно-Европейском регионе в сфере ИТ-аутсорсинга и
высокотехнологичных услуг. В тоже время в государственных органах
используются устаревшие технологи или не используются совсем. Из-за этого
в последнее время в стране начали полномасштабно разрабатывать различные
информационные системы с целью реализации полномочий государственных
органов и обеспечения обмена информацией между этими органами, а также
в иных установленных законами целях.
Одним из видов государственной деятельности является
лицензирование [1], как форма государственного регулирования,
направленная на защиту национальной безопасности, общественного порядка,
защиты прав и свобод, нравственности, здоровья населения, охраны
окружающей среды.
Целью данного дипломного проекта является создание программного
средства для объединения данных лицензирующих органов различных видов
деятельности Республики Беларусь, а также для предоставления сведений из
реестра лицензий государственным органам и физическим, юридическим
лицам, индивидуальным предпринимателям.
8
1 АНАЛИЗ СОВРЕМЕННЫХ ГОСУДАРСТВЕННЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ И ОПРЕДЕЛЕНИЕ ЦЕЛИ
ДИПЛОМНОГО ПРОЕКТИРОВАНИЯ
1.1 Анализ предметной области
Государственные информационные системы – системы, созданные на

основании законов субъектов Республики Беларусь, на основании правовых
актов государственных органов.
При использовании государственных информационных систем должны
быть обеспечены:
– доступность для пользователей;
– авторизованный, гарантированный и безопасный доступ
пользователей к информации, содержащейся в них;
– своевременность предоставления информации пользователям;
– авторизованный и безопасный обмен всей возможной информацией
между различными пользователями;
– конфиденциальность использования информации в государственных
информационных системах на основе разграничения доступа к ресурсам,
содержащимся в них, в пределах предоставленных полномочий;
– целостность данных при формировании, передаче, использовании,
обработке и хранении информации;
– реализация мер по защите информации.
Понять, что информационная система относится к государственной,
можно, используя следующую диаграмму, представленную на рисунке 1.1.
Рисунок 1.1 – Диаграмма ГИС
9
Единый реестр лицензий представляет информационный ресурс,
обеспечивающий автоматизированную обработку и хранение сведений о
лицензиатах и выданных им лицензиях.
1.2 Общая информация о государственных информационных

системах
Использование государственных информационных систем

осуществляется субъектами информационных отношений, имеющими к ним
доступ, в целях получения, распространения и предоставления информации,
реализации права на пользование информацией.
Государственные информационные системы создаются в целях
реализации полномочий государственных органов и обеспечения обмена
информацией между этими органами, а также в иных установленных
государственными законами целях.
ГИС создаётся и эксплуатируется на основе статистической и иной
документированной информации, предоставляемой гражданами
(физическими лицами), организациями, государственными органами,
органами местного самоуправления.
Правительство Республики Беларусь определяет случаи, при которых
доступ с использованием сети «Интернет» к информации, содержащейся в
государственных информационных системах, предоставляется
исключительно пользователям информации, прошедшим авторизацию в
единой системе идентификации и аутентификации, а также порядок
использования единой системы идентификации и аутентификации.
Если иное не установлено решением о создании государственной
информационной системы, функции ее оператора осуществляются
заказчиком, заключившим государственный контракт на создание такой
информационной системы. При этом ввод государственной информационной
системы в эксплуатацию осуществляется в порядке, установленном
указанным заказчиком.
1.3 Обзор существующих аналогов
1.3.1 Информационная система Эстонии

Это самый большой и самый важный портал, про который должен знать
каждый гражданин Эстонии.
Через этот портал можно просмотреть любые Ваши данные вплоть до
10
логов переводов человека из класса в класс.
Главная страница портала показана на рисунке 1.2.
Рисунок 1.2 – Эстонский государственный портал
Данная система представляет собой веб-сайт, через который возможно

выполнить следующие услуги:
1) услуги гражданина:
– предоставлять данные о месте жительства;
– получать данные из инфосистемы образования Эстонии;
– регистрация на уровневый экзамен по эстонскому языку;
– войти в инфосистему Общества охотников Эстонии;
– получить данные о пенсионном фонде;
– сделать заказ европейской карточки медицинского страхования;
– получить извещение о домашнем завещании;
– получить данные о медицинском страховании и семейном враче;
– подать ходатайство об услуге по специальному уходу;
– подать ходатайства об отсрочке от срочной службы;
– получить информационный запрос данных о земельном налоге;
2) услуги предпринимателя:
– вход в регистр строений;
11
– извещение о месте несения альтернативной службы;
– поиск транспортного средства без договора страхования;
– запрос о задолженности по алиментам;
– проверка действительности электронного свидетельства;
– дополнение листов нетрудоспособности;
3) услуги чиновника:
– проверка действительности электронного свидетельства;
– ожидающие подписания регистрации места жительства;
– запрос об удостоверениях личности;
– вход в базу данных безопасной трудовой среды;
– вход в клиентский портал Инспекции труда;
– запись об охранительных мерах по наследному имуществу.
Портал «eesti.ee» [2] можно отнести к универсальным средствам
поддержки деятельности граждан практически во всех сферах деятельности.
Данное программное средство имеет довольно обширный набор функций и со-
держит некоторые специфичные особенности, которые отличают его от дру-
гих подобных средств, применяемых в этой сфере.
В государственный портал можно зайти с помощью ID карты, которая
есть у любого гражданина, достигшего 15 летнего возраста, через мобильный
телефон. Вход можно так же осуществить через интернет-банк. Форма входа
на сайт показана на рисунке 1.3.
Рисунок 1.3 − Форма входа на сайт «eesti.ee»
К достоинствам Эстонского государственного портала можно отнести:

– специфичность;
– универсальность;
– многофункциональность;
12
– нахождение контактов государственных органов;
– поддержка трёх языков;
– версия сайта для слабовидящих.
Недостатков информационный системы пока обнаружено не было.
Универсальность – государственный портал может использоваться не
только госслужащим, но и обычными гражданами и частными
предпринимателями.
Многофункциональность − государственный портал имеет обширный
набор функций для решения целого ряда прикладных задач.
Нахождение контактов государственных органов − государственный
портал имеет страницу «Контакты» на которой находятся информация для
связи с любым госорганом.
Версия сайта для слабовидящих – портал имеет функцию перехода в
режим для людей со слабым зрение, с выбором стилей.
1.3.2 Информационная система электронного лицензирования

Республики Беларусь
Цели разработки − повышение эффективности деятельности
лицензирующих органов, упрощение процедур лицензирования отдельных
видов деятельности с целью придания качественно нового импульса развитию
бизнеса в Республике Беларусь путем совершенствования административных
процедур, связанных с лицензированием, предоставление посредством web-
портала сервисов для электронного лицензирования.
Информационная система разработана в соответствии с Указом
Президента Республики Беларусь от 1 сентября 2010 г. № 450 «О
лицензировании отдельных видов деятельности».
Участники системы:
– лицензирующий орган;
– соискатель лицензии;
– лицензиат;
– заинтересованное лицо – юридическое и физическое лицо,
государственный орган.
Функциональные подсистемы ИСЭЛ:
– лицензирование;
– получение информации из реестра лицензий;
– нормативная справочная информация;
– статистика.
13
Функциональные возможности информационного взаимодействия
участников системы – для информационного взаимодействия пользователей
ИСЭЛ реализован сервис личного кабинета. Личный кабинет предоставляет
возможность авторизованным пользователям использовать функциональность
ИСЭЛ согласно назначенной им роли. Информация о прилегающей
инфраструктуре включает в себя данные об учреждениях образования и
медицинских учреждениях.
Программное средство «ИСЭЛ» [3] представлено на рисунке 1.4.
Рисунок 1.4 − Программное средство «ИСЭЛ»
Сервисы, доступные зарегистрированному пользователю:

1) Электронные услуги, в том числе:
– подача заявления о выдаче лицензии;
– подача заявления о внесении изменений и дополнений в
существующую лицензию;
– подача заявления о выдаче дубликата лицензии;
– направление уведомления о прекращении осуществления
лицензируемого вида деятельности;
– направление заявления о получении информации из реестра.
2) Информационный блок пользователя. Предоставляется возможность
просмотра следующих сведений:
– о выданных лицензиях;
– об обособленных подразделениях;
14
– о документах, отправленных лицензирующему органу;
– о документах, полученных от лицензирующего органа;
3) Сообщения от лицензирующего органа. Предоставляется
возможность получать сообщения (уведомления) от лицензирующего органа
о статусах рассмотрения поданных пользователем заявлений.
В личном кабинете пользователя лицензирующий орган может
выполнять следующие функции:
– получает заявления и документы по вопросам лицензирования от
соискателей лицензий (лицензиатов);
– направляет уведомления о результатах рассмотрения заявлений
соискателям лицензий (лицензиатам);
– осуществляет формирование информационных ресурсов – реестр
лицензий и других;
– получает от заинтересованных лиц запросы о предоставлении сведений
о лицензиатах из реестра лицензий и предоставляет сведения о лицензиях;
– формирует информацию статистического и аналитического характера;
– получает информацию о юридических лицах и индивидуальных
предпринимателях, содержащуюся в Едином государственном регистре
юридических лиц и индивидуальных предпринимателей;
– осуществляет формирование и ведение НСИ;
– обновляет правовую информацию;
– размещает новости по вопросам лицензирования;
– обновляет рекомендуемые формы заявлений поступающим по
вопросам лицензирования.
К достоинствам программного средства «ИСЭЛ» можно отнести:
– специфичность;
– поиск и фильтрация по реестру лицензий.
Среди недостатков программного средства «ИСЭЛ» можно выделить:
– отсутствие возможности регистрации в системе;
– отсутствие возможности изменения поданных заявлений;
– отсутствие тесной интеграции со сторонними сервисами;
– имеется только один язык.
Специфичность − программное средство «ИСЭЛ» имеет характерные
отличительные особенность: возможность подавать заявления о выдаче
лицензий соответствующему органу, осуществляет формирование
информационного ресурса – реестра лицензий.
15
Универсальность − программное средство «ИСЭЛ» может быть полезен
в использовании для всех участников лицензирования, включая
лицензирующий орган, соискателя лицензии, лицензиата, юридическое и
физическое лицо, государственный орган.
Многофункциональность − программное средство «ИСЭЛ» имеет
гораздо более обширный функционал для решения целого ряда прикладных
задач по сравнению с аналогичными программными средствами.
Поиск и фильтрация по реестру лицензий − программное средство
«ИСЭЛ» имеет возможность производить поиск лицензий по номеру
лицензии, наименованию лицензиата и по УНП.
Отсутствие возможности регистрации в системе − программное
средство «ИСЭЛ» не имеет возможности регистрации нового пользователя без
посторонней помощи.
Отсутствие возможности изменения поданных заявлений −
программное средство «ИСЭЛ» не позволяет изменять данные после их
отправки соответствующему госоргану.
Имеется только один язык − программное средство «ИСЭЛ»
поддерживает только русский язык, что может отталкивать некоторые группы
пользователей, которые используют другой язык.
1.3.3 Веб-портал Единого государственного регистра юридических лиц

и индивидуальных предпринимателей
Веб-портал ЕГР [4] (рисунок 1.5) предоставляет возможность:
– Согласовать наименование организации. Cогласование наименования
коммерческой или некоммерческой организации является первым шагом к
созданию юридического лица. Посредством веб-портала возможно не выходя
из дома согласовать наименование организации либо скачать форму заявления
для подачи лично или по почте.
– Создать юридическое лицо или зарегистрироваться в качестве
индивидуального предпринимателя.
– Уведомить регистрирующий орган об изменении местонахождения
юридического лица либо о назначении (замене) его руководителя.
– Запросить информацию из ЕГР в отношении юридического лица,
индивидуального предпринимателя, гражданина (юридического лица) на
предмет его участия в создании организации и (или) управлении ею.
– Проверить статус субъекта хозяйствования.
– Подготовить соответствующее заявление или уведомление для
последующего их представления в регистрирующий орган путем личного
16
обращения или по почте.
– Ознакомиться с нормативными правовыми актами, на основе которых
осуществляется государственная регистрация и ликвидация.
Работать с порталом ЕГР можно как с авторизацией, так и без неё.
Без авторизации с помощью веб-портала ЕГР пользователь может:
– согласовать наименование юридического лица;
– получить информацию юрлица из Единого государственного регистра
юридических лиц и индивидуальных предпринимателей;
– заполнить электронные формы различных заявлений в режиме онлайн
для последующего их представления на бумажном носителе в
регистрирующий орган.
Рисунок 1.5 − Веб-портал Единого государственного регистра юридических

лиц и индивидуальных предпринимателей
Авторизованный пользователь – владелец личного ключа электронной

цифровой подписи (резидент Республики Беларусь) с помощью веб-портала
ЕГР может выполнить следующие действия:
– создать юридическое лицо;
– зарегистрироваться в качестве индивидуального предпринимателя.
Для того, чтобы пройти авторизацию, обязательно потребуется:
– сертификат пользователя;
– установить и настроить программное обеспечение для работы с ЭЦП
«Персональный менеджер сертификатов Авест» (ПО выдается при получении
17
сертификата пользователя);
– настроить браузер MS Internet Explorer версии 9.0 и выше.
К достоинствам веб-портала единого государственного регистра
юридических лиц и индивидуальных предпринимателей можно отнести:
– карта сайта.
Среди недостатков программного средства можно выделить:
– отсутствие возможности регистрации в системе;
– устаревший внешний вид веб-портала;
– отсутствие тесной интеграции со сторонними сервисами;
– ограниченность.
Универсальность – веб-портал ЕГР может быть полезен для
юридических лиц, как для авторизованных пользователей, так и не
авторизованных пользователей.
Многофункциональность − веб-портал ЕГР имеет обширный
функционал для решения ряда прикладных задач для решения юридических
вопросов по сравнению с аналогичными программными средствами.
Отсутствие возможности регистрации в системе – в веб-портале ЕГР нет
возможности, самостоятельной регистрации для пользователей.
Устаревший внешний вид веб-портала – устаревший дизайн выглядит
отталкивающим и не удобно пользоваться панелью навигации.
Ограниченность – для использования портала ЕГР необходимо
использовать специальное дополнительное ПО и возможность правильной
работы только через один браузер.
1.3.4 Единый портал электронных услуг ОАИС

Единый портал электронных услуг portal.gov.by [5] (рисунок 1.6) – это
удобная платформа для получения электронных услуг гражданами и бизнесом,
единая точка доступа к различным электронным сервисам, а также источник
информации об административных процедурах, выполняемых тем или иным
белорусским ведомством.
Широкий спектр услуг представлен для юридических лиц: является ли
индивидуальный предприниматель действующим плательщиком, каков
размер уставного фонда предприятия, не затеваете ли вы сотрудничество с
компанией-банкротом – эти и другие сведения доступны на Портале.
В современной версии Портала реализованы электронные услуги в
сфере налогообложения, учета и обращения недвижимого имущества, труда и
18
социальной защиты на основе информации из ГИР – государственных
информационных ресурсов – информационных систем, баз данных, которые
наполняет и ведет то или иное ведомство.
Рисунок 1.6 – Единый портал электронных услуг ОАИС
Сегодня в ОАИС интегрированы следующие ГИР:

– единый государственный регистр юридических лиц и индивидуальных
предпринимателей;
– единый государственный регистр недвижимого имущества, прав на
него и сделок с ним;
– государственный реестр плательщиков;
– торговый реестр Республики Беларусь;
– реестр бытовых услуг Республики Беларусь;
– регистрация доменных имен в национальной доменной зоне;
– информационные объекты автоматизированной системы «Паспорт»;
– сведения по делам об экономической несостоятельности (банкротстве);
– единый государственный банк данных о правонарушениях;
– реестр индивидуальных лицевых счетов застрахованных лиц в системе
индивидуального (персонифицированного) учета в системе государственного
социального страхования;
– реестр контроля сроков действия таможенных процедур.
Одни Услуги на Портале доступны широкому кругу пользователей,
19
бесплатны и не требуют регистрации на портале, другие открыты лишь после
проверки идентификационных данных Оператором Портала.
К достоинствам программного средства ОАИС можно отнести:
– удобство использования;
– поиск и фильтрация услуг.
Недостатком программного средства ОАИС является платный
функционал некоторых его частей.
Универсальность – портал ОАИС позволяет пользоваться услугами веб-
сайта физическим и юридическим лицам, государственным органам и любым
другим организациям.
Удобство использования – портал ОАИС оформлен в современном
дизайне, котором просто и понятно пользоваться.
Поиск и фильтрация услуг производится на основании следующих
заданных критериев:
– тип услуги;
– категория пользователя;
– только услуги ОАИС.
Функционал платный – портал ОАИС имеет услуги, которые можно
получить только платно.
1.4 Цель и задачи дипломного проекта
1.4.1 Назначение разработки

Назначением дипломного проектирования является разработка
государственной информационный системы единый реестр лицензий. На
основании произведенного обзора существующих аналогов, выявленных
преимуществ и недостатков данных средств, сделан вывод, что для решения
поставленной цели необходимо выполнить следующие задачи:
– проектирование архитектуры программного средства;
– проектирование базы данных программного средства;
– разработка алгоритмов поиска, добавления, редактирования лицензий
из реестров лицензий;
– разработка пользовательского интерфейса;
– тестирование программного средства.
Программное средство ГИС ЕРЛ должно выполнять следующие
основные функции:
– поиск лицензий по заданным критериям;
20
– добавление реестров лицензии;
– редактирование реестров лицензии;
– формирование и ведение информационных ресурсов нормативно-
справочной информации системы;
– подготовка и отправление электронных документов, связанных с
осуществлением электронного лицензирования и выдачей информации из
реестра лицензий;
– регистрация пользователей в системе.
1.4.2 Состав выполняемых функций

Целью разработки программного средства ГИС ЕРЛ является
объединение основных достоинств рассмотренных существующих аналогов, а
также компенсация недостатков этих средств. В результате разработки
программного средства необходимо предоставить возможность выполнения
следующих функций:
– поиск лицензий по заданным критериям;
– добавление реестров лицензий;
– редактирование реестров лицензий;
– загрузка данных через xml файл;
– загрузка данных через excel файл;
– загрузка данных через веб-форму;
– формирование документов о выдаче информации из реестра лицензий;
регистрация пользователей.
Поиск лицензий в реестре должен осуществляться по следующим
заданным критериям:
– УНП;
– название организации;
– номер лицензии.
Добавление реестров лицензий – для каждого лицензирующего органа
должна быть возможность загружать свои данные через сервисы приложения.
Редактирование реестров лицензий – необходимо, чтобы была
реализована возможность онлайн редактирования данных из реестра
специальными пользователями.
Формирование документов о выдаче информации из реестра лицензий –
для получения определённых данных необходимо создавать документы, в
которых будут записываться данные получателей информации и о самой
выданной информации.
21
1.4.3 Входные и выходные данные
Входными параметрами для программного средства являются
следующие данные:
– поисковый запрос пользователя, вносимый в поле для поиска; – личные
данные пользователей;
– личные данные пользователей;
– данные лицензирующего органа, поданные с помощью форматов XML,
EXCEL или с помощью веб-формы.
Выходными параметрами для программного средства являются
следующие данные:
– реестры лицензий;
– документы с информацией.
1.4.4 Требования к составу и параметрам технических и

программных средств
Программное средство государственная информационная система
единый реестр лицензий должна функционировать на ЭВМ со следующими
минимальными характеристиками:
– процессор Intel Core i5 или лучше;
– оперативная память 4 GB 1600 MHz DDR4 или лучше;
– накопитель HDD или SSD объемом 1 GB или больше.
Программное средство государственная информационная система
единый реестр лицензий должна функционировать в окружении со
следующими характеристиками:
– операционная система Ubuntu Server версии 14.04;
– веб-сервер Apache Tomcat версии 7.0.86;
– СУБД PostgreSQL версии 10.3;
– Java SE версии 10.0.1;
– накопитель HDD или SSD объемом 1 GB или больше.
– оперативная память 16 GB 1600 MHz DDR4 или лучше;
– Apache Maven версии 3.5.3.
В данном разделе указаны минимальные технические требования для
запуска программного средства.
1.4.5 Требования к безопасности

Защита технических средств, на которых реализован «единый реестр
лицензий», от воздействий электрического тока, электромагнитных полей,
акустических шумов и т.п. должна осуществляться в соответствии с
22
требованиями по эксплуатации программного средства, предъявляемыми к
оборудованию его разработчиками.
Комплекс технических средств должен соответствовать требованиям
техники безопасности, основными из которых являются:
– все внешние элементы технических устройств, находящиеся под
напряжением, должны иметь защитное заземление;
– технические устройства должны быть установлены в местах,
обеспечивающих свободный и безопасный доступ к ним при эксплуатации и
проведении профилактического обслуживания;
– сотрудники, которые работают на технических средствах, должны
проходить обучение, инструктаж, проверку знаний правил, норм и инструкций
по технике безопасности;
– в помещении, предназначенном для эксплуатации технических
средств, должны быть обеспечены противопожарные меры безопасности.
23
2 МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ И
РАЗРАБОТКА ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ
2.1 Описание функциональности программного средства
Для описания функциональности программного средства была выбрана

диаграмма вариантов использования в спецификации языка графического
описания UML [6].
2.1.1 Диаграмма вариантов использования

Функциональная модель представляется в виде диаграммы вариантов
использования, которая отражает отношения актеров и прецедентов.
Диаграмма позволяет описать систему на концептуальном уровне. На
диаграмме актером является множество логически связанных ролей, испол-
няемых при взаимодействии с прецедентами или сущностями (система, под-
система или класс). Актером может быть человек или другая система, под-
система или класс, которые представляют нечто вне сущности. Прецедентом
является спецификация последовательностей действий, которая может осу-
ществлять система, подсистема или класс, взаимодействуя с внешними
действущими лицами (актерами). Диаграмма представлена на рисунке 2.1.
uc Actors
Создание Редактирование
Пользователь
Авторизация «include»
«include» Удаление
Обращение к
сервису ЕГР «include»
Управление
пользователями
Поиск в реестре
лицензий
Поиск по названию «include»
органиазации «include» Назначене роли
«include»
Гость
Регистрация «include»
Поиск по УНП
Администратор
Поиск по номеру
лицензии
Просмотр
информации по
лицензиям
Редактирование
реестра
«include»
Менеджер Управление
реестром
лицензий
«include»
Добавление новых
данных
Рисунок 2.1 – Диаграмма вариантов использования
24
На представленной диаграмме вариантов использования присутствует
четыре основных актера:
– гость;
– менеджер;
– пользователь;
– администратор.
Гость − данный актер ограничен в перечне функций. Он может выпол-
нять следующие функции:
– регистрация в системе;
– авторизация в системе;
– просмотр информации о лицензиях.
Менеджер − данный актер имеет больше всего привилегий в системе. Он
может выполнять следующие функции:
– управление реестром лицензий;
– поиск информации в реестре лицензий.
Пользователь − данный актер может выполнять функцию поиска
информации в реестре лицензий.
Поиск лицензий пользователем может осуществляться по следующим
заданным критериям:
– название предприятия;
– номер лицензии;
– УНП.
Администратор − данный актер имеет возможность управления пользо-
вателями в системе. Управление пользователями в системе включает в себя
следующие функции:
– просмотр;
– добавление;
– удаление;
– назначение роли пользователя.
2.1.2 Инфологическая модель базы данных

Основной целью инфологического проектирования является построение
семантической модели предметной области, то есть информационной модели
наиболее высокого уровня абстракции. Такая модель создается без ориентации
на какую-либо конкретную СУБД и модель данных. Конкретный вид и
содержание инфологической модели базы данных определяется выбранным
для этого формальным аппаратом.
Инфологическая модель базы данных [7] включает в себя:
25
– описание информационных объектов или понятий предметной области
и связей между ними;
– описание ограничений целостности, то есть требований к допустимым
значениям данных и к связям между ними.
Инфологическая модель базы данных представлена на рисунке 2.2.
Основными сущностями системы являются пользователь и лицензии.
Дополнительные сущности отражают результат взаимодействия между двумя
основными сущностями.
Рисунок 2.2 – Инфологическая модель базы данных
26
Сущность «пользователь» содержит следующие данные:
– логин для входа в систему;
– зашифрованный пароль для входа в систему.
Пользователь имеет возможность просматривать реестр лицензий,
обратиться к пользователю с ролью «Администратор» для изменения его
личных данных или роли.
Сущность «Лицензия» хранит в себе информацию о выданной лицензии.
Объект лицензии содержит следующие данные:
– регистрационный номер лицензии в реестре лицензий;
– номер принятия решения о выдаче лицензии;
– дата принятия решения о выдаче лицензии;
– номер бланка лицензии;
– срок действия лицензии (дата окончания).
Данная сущность связана с сущностью «Лицензирующий орган».
Сущность «Лицензиат» содержит информацию, об организации,
которой выдали лицензию. С этой сущностью связана сущность
«Обособленное подразделение лицензиата», в которой хранятся данные об
дополнительных филиалах организации.
Сущность «История лицензии» хранит в себе информацию о всех
действиях, проводимых над определённой лицензией.
Сущность «Сервисы лицензии» содержит данные о функциях лицензии,
срок её действия и территория, на которой возможны эти функции.
2.2 Спецификация функциональных требований
Для описания требуемых характеристик программного средства была

составлена функциональная спецификация. Данная спецификация включает в
себя следующие функциональные требования, которые должны быть
реализованы в разрабатываемом программном средстве:
– регистрация пользователя;
– авторизация пользователя;
– редактирование профиля пользователя;
– восстановление пароля;
– управление реестром лицензий;
– просмотр подробной информации о лицензии;
– поиск лицензий;
– управление пользователями.
27
Требования к регистрации пользователей:
1) права доступа:
– данная функция должна быть доступна любому неавторизован-
ному пользователю приложения;
– доступ к данной функции должны иметь только пользователи с
ролью «гость»;
2) регистрационная форма:
– производиться путем заполнения регистрационной формы;
– с помощью ЭЦП;
3) регистрационные поля:
– имя пользователя (логин);
– пароль;
– данные пользователя (ФИО, Email, место работы).
Требования к авторизации пользователя:
– данная функция должна быть доступна любому зарегистрирован-
ному пользователю приложения;
– доступ к данной функции должны иметь пользователи с ролями
«пользователь», «администратор» и «менеджер»;
2) авторизационная форма:
– авторизация пользователя в приложении должна производиться
путем заполнения авторизационной формы;
– с помощью ЭЦП;
3) проверка авторизации:
– проверка авторизации должна осуществляться после ввода ло-
гина и пароля со стороны пользователя;
– проверка авторизации должна производиться путем сравнения
введенных пользователем данных с данными, указанными при регистрации
пользователя в приложении;
– с помощью данных, содержащихся в ЭЦП.
Требования к редактированию профиля пользователя:
– доступ к данной функции должны иметь пользователи с ролями:
«пользователь» и «администратор»;
2) форма редактирования:
– редактирование профиля пользователя в приложении должно
осуществляться через форму редактирования;
3) данные для редактирования:
28
– данные пользователя.
Требования к восстановлению пароля:
– данная функция должна быть доступна любому зарегистриро-
ванному пользователю приложения;
2) форма восстановления пароля:
– восстановление пароля пользователя в приложении должно
осуществляться через форму восстановления пароля;
3) данные для восстановления пароля:
– адрес электронной почты;
– логин пользователя.
Требования к управлению реестром лицензий:
– данная функция должна быть доступна только менеджерам от
лицензирующих органов;
2) формы управления реестром лицензий:
– форма добавления может представлять собой заполнение всех
полей лицензии, либо загрузки целых реестров с помощью XML или Excel;
– форма редактирования должна представлять собой форму
изменения любых данных в выбранной лицензии;
– форма удаления должна позволять удалять саму лицензию, либо
частичную информацию о ней;
3) данные о лицензии:
– номер решения;
– номер формы;
– УНП;
– регистрационный номер;
– комментарий;
– дата принятия решения;
– срок действия.
Требования к просмотру реестра лицензий:
– данная функция должна быть доступна всем авторизованным
пользователям приложения;
2) форма просмотра реестра лицензий:
– через таблицу на сайте;
29
– с помощью скачивания excel файла.
Требования к просмотру подробной информации о лицензии:
2) страницы просмотра информации о лицензии:
– просмотр краткой информации должен осуществляться на
странице поиска лицензий;
– просмотр детальной информации о лицензии должен
осуществляться на новой странице;
3) просмотр краткой информации о лицензии:
– для просмотра краткой информации пользователю достаточно
навести курсором на соответствующую лицензию в списке объектов.
Требования к поиску лицензий:
2) поиск по названию организации, УНП или номеру лицензии:
– воспользоваться данной функций можно будет путем ввода
поисковой информации в специальное поле.
Требования к управлению пользователями:
– доступ к данной функции должен иметь только пользователь с
ролью «администратор»;
2) список функций:
– создание новых пользователей;
– редактирование уже существующих пользователей;
– установление роли пользователя;
– удаление пользователей.
2.2.1 Требования к пользовательскому интерфейсу

Для удобства использования программного средства был составлен ряд
требований к пользовательскому интерфейсу:
1) список лицензий:
30
а) должен представлять собой перечень краткой информации:
– УНП;
– сервисы;
– вид деятельности;
2) поле поиска лицензий:
а) допустимые значения:
– цифры;
– латинские символы;
– кириллические символы;
б) входные данные:
– УНП;
в) выходные данные:
– список лицензий;
3) страница лицензии:
а) детальная информация о лицензии:
– УНП;
– срок действия;
– адрес лицензиата;
б) страница детальной информации о лицензии:
– пользователь должен иметь возможность просматривать
детальную информацию о лицензии на отдельной странице;
4) страница редактирования профиля пользователя:
а) данные профиля пользователя:
– информация о себе;
– контактные данные;
б) страница редактирования:
– пользователь должен иметь возможность на отдельной
странице редактировать свой профиль и изменять информацию о себе, а также
свои контактные данные;
5) контактная форма – пользователь должен иметь возможность
31
связаться с администратором приложения через контактную форму.
2.2.2 Требования к интерфейсу администратора

Помимо вышеперечисленных требований к интерфейсу пользователя,
были составлены также требования к интерфейсу администратора:
1) форма добавления, изменения, удаления лицензирующего органа:
а) поля формы добавления лицензирующего органа:
– название органа;
– название видов деятельности;
2) форма редактирования профиля пользователя:
а) поля формы редактирования профиля пользователя:
– адрес электронной почты;
– установление роли пользователя;
– контактные данные пользователя;
б) страница редактирования профиля пользователя:
– администратор должен иметь возможность на отдельной
странице редактировать данные других пользователей и ограничивать доступ
пользователям к приложению.
2.2.3 Роли пользователей

В приложении должна быть построена политика управления доступом
на основе ролей:
1) необходимо обеспечить четыре основных роли пользователей:
– гость (неавторизованный пользователь);
– пользователь (авторизованный пользователь);
– администратор;
– менеджер;
2) гость должен иметь доступ к форме регистрации в приложении;
3) гость, пользователь, администратор и менеджер должны иметь доступ
к форме авторизации в приложении;
4) гость и авторизованный пользователь должны иметь доступ к
главному интерфейсу приложения;
5) авторизованный пользователь должен иметь доступ к поиску
лицензий в реестре;
6) администратор должен иметь доступ к интерфейсу приложения, а
также к панели администратора;
7) менеджер должен иметь доступ к панели управления реестром
лицензий с помощью формы.
32
3 ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО СРЕДСТВА
3.1 Проектирование взаимодействия модулей ПС
Взаимодействие модулей программного средства можно представить в

виде контекстной диаграммы по методологии IDEF0 [8].
IDEF0 – методология функционального моделирования и графическая
нотация, предназначенная для формализации и описания бизнес-процессов.
Отличительной особенностью IDEF0 является ее акцент на соподчиненность
объектов. В IDEF0 рассматриваются логические отношения между работами,
а не их временная последовательность (поток работ).
Контекст – абстрактное описание программного средства. Контекст
включает в себя:
– субъект моделирования;
– цели моделирования;
– входные данные;
– выходные данные.
Субъектом моделирования является само программное средство.
Контекстная диаграмма, представленная на рисунке 3.1,
рассматривается со стороны менеджера по продаже недвижимости.
Рисунок 3.1 – Контекстная диаграмма
Также на рисунке 3.2 представлена декомпозиция контекстной

диаграммы на основные модули программного средства.
33
Декомпозиции контекстной диаграммы включает следующие функции:
– регистрация;
– авторизация;
– поиск лицензий;
– просмотр списка лицензий;
– добавление новых лицензий.
Рисунок 3.2 – Декомпозиция модулей взаимодействия

программного средства
3.2 Обоснование выбора СУБД
Выбор СУБД напрямую связан с анализом и выбором аппаратных

ресурсов. Стандартные тесты проводятся на современных
быстродействующих системах, в то время как целью клиента может быть
просто работоспособная система в рамках отведенного бюджета. Не менее
важны и взаимодействие с унаследованными системами, и возможности
переноса накопленных данных на новую систему.
Важным критерием выбора с точки зрения перспектив становится
наличие эффективных средств разработки. Такие средства, обладающие
удобным интерфейсом, позволяют специалистам предприятия самостоятельно
и быстро настраивать информационные системы в соответствии с
требованиями бизнеса.
PostgreSQL это мощная объектно-реляционная система управления
34
базами данных с открытыми исходными текстами. Она разрабатывается на
протяжении более 15 лет и улучшает архитектуру, чем завоевала репутацию
надежной, интегрированной и масштабируемой СУБД. Она запускается на
всех основных платформах, включая Linux, UNIX и Windows. Она полностью
соответствует ACID, имеет полную поддержку ключей, объединений,
представлений, триггеров, и хранимых процедур. Она включает большинство
типов данных SQL92 и SQL9. Она имеет API для C/C++, Java, Perl, Python,
Ruby, Tcl, ODBC и др.
Являясь СУБД класса предприятия, PostgreSQL [10] предоставляет
такие особенности как Multi-Version Concurrency Control, восстановление по
точке во времени, табличное пространство, асинхронная репликация,
вложенные транзакции, горячее резервирование, планировщик/оптимизатор
запросов, и упреждающее журналирование на случай поломки. Он
поддерживает международные кодировки, в том числе и многобайтовые, при
использовании различных кодировок можно использовать сортировку и
полнотекстовый поиск, различать регистр. Большое количество
подконтрольных данных и большое число одновременно работающих
пользователей, тем не менее, не сильно влияет на масштабируемость системы.
Реализация SQL в PostgreSQL соответствует ANSI-SQL 92/99
стандартам. Он имеет полную поддержку вложенных запросов (включая
выбор из FROM), уровень чтения только зафиксированных данных и
сериализуемые транзакции. И так как PostgreSQL имеет полностью
реляционный системный каталог, поддерживающий множество схем баз
данных, его каталог также доступен посредством информационной схемы в
соответствии со стандартом SQL.
3.3 Проектирование модели базы данных
Даталогическая модель [10] – модель предметной области в привязке к

СУБД определенного вида или конкретной СУБД. Описывает способ
организации данных безотносительно их физического размещения.
Соглашения, распространяющиеся на всю работу по созданию
даталогической модели:
– в таблице с описанием таблиц и полей БД тип данных указывается
явно, если из названия полей и здравого смысла не очевидно, что нужно
использовать «обычные» текстовые или числовые типы данных;
– все типы данных при создании полей таблиц БД формируются из
расчёта совместимости с PostgreSQL версии 10.3;
35
– имя первичного ключа формируется из названия таблицы в
единственном числе и суффикса «ID»;
– в именах таблиц каждое новое слово пишется с заглавной буквы;
– имена полей и таблиц начинаются с маленьких букв;
– все поля, содержащие дату и/или время, имеют тип timestamp;
– все поля, содержащие названия категорий имеют тип varchar (50);
– все поля, содержащие целые числа, имеют тип Integer.
Названия и назначения таблиц базы данных приведены в таблице 3.1
Таблица 3.1– Список таблиц в БД

№ п/п Название таблицы Назначение
Содержит информацию пользователя
1 User
для входа в систему
Содержит личную информацию
2 UserInfo
пользователя
3 Role Содержит роли пользователей
Таблица для разрешения связи многоие-
4 UserRole
ко-мнгоим
5 License Содержит информацию о лицензии
6 LicenseServices Содержит список сервисов лицензии
Содержит данные о территории
7 LicenseTerritory
действия лицензии
Содержит информацию о
8 LicenseAuthotiry
лицензирующем органе
Содержит данные о изменения в
9 LicenseHistory
лицензии
Содержит информацию о всех
10 LicensePrint
распечатываниях лицензии
Содержит данные о владелеце лицнзии
11 LicenseOwner
(лицензиате)
Содержит данные о лицензирующем
12 KindOfActivity
виде деятельности
Содержит информацию о выводимых
13 News
новостях
36
В каждой таблице существу поля, которые в программе наследуются от
базового класса BasicData, которые представлены в таблице 3.2.
Таблица 3.2 – Описание полей, содержащихся во всех таблицах

Обязатель-
Имя поля Тип поля Комментарий
ность
Datecreate timestamp Нет Дата создания таблицы
DataLastEdit timestamp Да Дата последнего изменения
OwnerId bigint Нет Id владельца таблицы
Id человека, который внёс
LastEditorId bigint Да
последние изменения
Описание полей таблицы «User» приведено в таблице 3.3
Таблица 3.3 – содержание таблицы «User»

Обязатель-
ность
UserId bigint Да Идентификатор
UserName Varchar(50) Да Имя пользователя
Encrypted
Varchar(128) Да Зашифрованный пароль
Password
Описание полей таблицы «UserInfo» приведено в таблице 3.4
Таблица 3.4 – содержание таблицы «UserInfo»

Обязатель-
ность
UserInfoId bigint Да Идентификатор
Name Varchar(50) Да Имя пользователя
SurName Varchar(50) Да Фамилия
MiddleName Varchar(50) Да Отчество
Job Varchar(255) Да Место работы
Position Varchar(255) Да Должность
Email Varchar(255) Да Электронная почта
37
Описание полей таблицы «License» приведено в таблице 3.5
Таблица 3.5 – содержание таблицы «License»

Обязатель-
ность
LicenseId bigint Да Идентификатор
RoleName Varchar(50) Да Название роли
NumberOfD
Varchar(3) Да Номер решения
ecision
NumberForm Varchar(8) Да Номер формы
UNP Varchar(9) Да Учётный номер плательщика
Comment Varchar(250) Нет Комментарий
DateDecision timestamp Да Дата принятия решения
Дата конца срока действия
DateEnd timestamp Да
лицензии
Описание полей таблицы «LicenseOwner» приведено в таблице 3.6
Таблица 3.6 – содержание таблицы «LicenseOwner»

Обязательн
ость
License
bigint Да Идентификатор
OwnerId
Name Varchar(50) Да Название лицензиата
Address Varchar(250) Да Адрес лицензиата
UNP Varchar(13) Да Учётный номер плательщика
Registration
timestamp Да Дата регистрации
Date
TaxAuthority Varchar(255) Да Наименование налогового органа
Phone Varchart(13) Да Номер телефона
38
Описание полей таблицы «Role» приведено в таблице 3.7
Таблица 3.7 – содержание таблицы «Role»

Обязатель-
ность
RoleId bigint Да Идентификатор
RoleName Varchar(50) Да Название роли
Описание полей таблицы «LicenseHistory» приведено в таблице 3.8
Таблица 3.8 – содержание таблицы «LicenseHistory»

Обязатель-
ность
License
bigint Да Идентификатор
HistoryId
EditData Varchar(255) Нет Данные об изменении лицензии
Данные о приостановлении
StopData Varchar(255) Нет
лицензии
EndData Varchar(255) Нет Данные о прекращении лицензии
Resumption Данные о возобновлении
Varchar(255) Нет
Data лицензии
Cancellation Данные об аннулировании
Varchar(255) Нет
Data лицензии
LossData Varchar(255) Нет Данные об утрате лицензии
Данные о выданных дубликатах
DuplicateData Varchar(255) Нет
лицензии
Дата начала действия с
DateStart timestamp Да
лицензией
Дата окончания действия с
DateEnd timestamp Да
лицензией
Сomment Varchar(255) Да Комментарий
39
Описание полей таблицы «KindOfActivity» приведено в таблице 3.9
Таблица 3.9 – содержание таблицы «KindOfActivity»

Обязатель-
ность
KActivityId bigint Да Идентификатор
Name Varchar(50) Да Название
Обязательн
ость
License
Varchar(250) Да Составляющие лицензии
Components
License
Varchar(250) Да Требования к лицензии
Requirements
License
Varchar(250) Да Территория действия лицензии
Territory
3.4 Разработка архитектуры ПС
Архитектура программного обеспечения [11] − это структура

программы или вычислительной системы, которая включает программные
компоненты, видимые свойства компонентов, а также отношения между ними.
Для представления архитектуры используются два вида диаграмм:
– диаграмма развертывания;
– диаграмма компонентов.
3.4.1 Обоснование выбора архитектурного шаблона

Для разработки архитектуры программного средства единый реестр
лицензий был выбран архитектурный шаблон MVC [12].
Различают две основные модификации:
– пассивная модель;
– активная модель.
Пассивная модель – модель не имеет никаких способов воздействовать
на представление или контроллер, и используется ими в качестве источника
данных для отображения. Все изменения модели отслеживаются
контроллером, и он же отвечает за перерисовку представления, если это
необходимо. Такая модель чаще используется в структурном
40
программировании, так как в этом случае модель представляет просто
структуру данных, без методов их обрабатывающих.
Активная модель – модель оповещает представление о том, что в ней
произошли изменения, а представления, которые заинтересованы в
оповещении, подписываются на эти сообщения. Это позволяет сохранить
независимость модели как от контроллера, так и от представления.
Классической реализацией паттерна MVC принято считать версию
именно с активной моделью.
С развитием объектно-ориентированного программирования и понятия
о шаблонах проектирования было создано ряд модификаций концепции MVC,
которые при реализации у разных авторов могут отличаться от оригинальной.
Основная цель применения этой концепции состоит в разделении
бизнес-логики (модели) от её визуализации (представления, вида). За счет
такого разделения повышается возможность повторного использования.
Наиболее полезно применение данной концепции в тех случаях, когда
пользователь должен видеть те же самые данные одновременно в различных
контекстах и/или с различных точек зрения. В частности, выполняются
следующие задачи:
– К одной модели можно присоединить несколько видов, при этом не
затрагивая реализацию модели. Например, некоторые данные могут быть
одновременно представлены в виде электронной таблицы, гистограммы и
круговой диаграммы.
– Не затрагивая реализацию видов, можно изменить реакции на действия
пользователя (нажатие мышью на кнопке, ввод данных), для этого достаточно
использовать другой контроллер.
– Ряд разработчиков специализируются только в одной из областей: или
разрабатывают графический интерфейс или разрабатывают бизнес-логику.
Поэтому возможно добиться, что программисты, занимающиеся разработкой
бизнес-логики (модели), вообще не будут осведомлены о том, какое
представление будет использоваться.
Концепция MVC позволяет разделить данные, представление и
обработку действий пользователя на три отдельных компонента:
– Модель. Предоставляет знания: данные и методы работы с этими
данными, реагирует на запросы, изменяя своё состояние. Не содержит
информации, как эти знания можно визуализировать.
– Представление, вид. Отвечает за отображение информации
(визуализацию). Часто в качестве представления выступает форма (окно) с
графическими элементами.
41
– Контроллер. Обеспечивает связь между пользователем и системой:
контролирует ввод данных пользователем и использует модель и
представление для реализации необходимой реакции.
3.4.2 Диаграмма развёртывания

Физическое моделирования позволяет определить структуру
программного средства и взаимосвязи между его компонентами, как
физические, так и логические. Это важно для дальнейшей работы
архитекторов и разработчиков.
Для наглядного представления системы, в которой будет работать
будущее программное средство, удобно использовать диаграмму
развёртывания, которая имеет вид, представленный на рисунке 3.3.
Рисунок 3.3 – Диаграмма развертывания
Важным является полное соответствие версий, используемых на сервере

и на компьютере администратора пакетов, языка и фреймворков, так как это
непосредственно влияет на функционирование приложения. Стандартно, при
развертывании приложения на сервере, туда будут перенесены недостающие
пакеты той версии, которая используется на компьютере администратора.
Если же этого не произошло, то нужные пакеты можно установить через
консоль на самом сервере.
Пользователю для работы с приложением необходим компьютер,
42
доступ в интернет и веб-браузер.
3.4.3 Диаграмма компонентов

Диаграмма компонентов – статическая структурная диаграмма,
показывает разбиение программной системы на структурные компоненты и
связи (зависимости) между компонентами. В качестве физических
компонентов могут выступать файлы, библиотеки, модули, пакеты.
Для графического представления архитектуры программного средства
была составлена диаграмма компонентов. На диаграмме представлены «Mo-
dels», «Views» и «Controllers». Помимо перечисленных компонентов,
диаграмма включает в себя также «Repositories». Диаграмма компонентов
представлена на рисунке 3.4.
Рисунок 3.4 – Диаграмма компонентов
На представленной диаграмме указаны следующие модели:

– AppUser – модель пользователя;
– UserRole – модель связи между пользователем и его ролью;
– AppRole – модель ролей пользователя;
– LicenseTerritory – модель территории на которой действует лицензия;
– LicenseAuthority – модель лицензирующего органа;
– LicenseHistory – модель изменений в лицензии;
– License – модель лицензии;
– LicenseServices – модель сервисов лицензии;
43
– LicensePrint – модель печати копий лицензии;
– LicenseOwner – модель организации;
– OwnerBranch – модель филиала организации.
На представленной диаграмме указаны следующие представления:
– Index – представление начальной страницы;
– Login – представление страницы авторизации;
– Registration – представление страницы регистрации;
– LicenseList – представление списка лицензий;
– LicenseDetail – представление всех данных определённой лицензии;
– EGR – представление для связи с сервисом ЕГР;
– AddLicense – представление для добавления новой лицензии;
– EditUserInfo – представление изменения данных пользователя;
– Menu – частичное представление меню;
– News – представление страницы новостей;
– 403 – представление страницы для неавторизованного пользователя;
– 404– представление ошибочной страницы.
На представленной диаграмме указаны следующие контроллеры:
– UserController – контроллер пользователя;
– LicenseController – контроллер лицензий;
– EGRController – контроллер сервиса ЕГР;
– AuthentificationController – контроллер авторизации и регистрации;
– HomeController – домашний контроллер;
– AdminController – контроллер администратора.
3.5 Алгоритм работы приложения
Приведенная в этом подразделе схема отображает алгоритм работы с

программным средством «Единый реестр лицензий» в режиме онлайн, она
изображена на рисунке 3.5.
Этапы работы алгоритма программы:
1) на данном этапе происходит запуск приложения;
2) после старта приложения пользователь переходит на главную
страницу приложения;
3) далее пользователь должен сделать выбор его действий;
4) пользователь решает закрыть приложение;
5) отображается страница авторизации пользователя;
6) отображается страница регистрации пользователя;
7) проверка введённых логина и пароля;
44
8) проверка введённых данных для регистрации;
9) переход в личный кабинет;
10) отображение страницы с успешной регистрацией;
11) начала цикла, в которой пользователь работает в системе;
12) выбор действия пользователя после авторизации;
13-18) выполнение различных действий на сайте;
19) пользователь решает выйти из системы.
Рисунок 3.5 – Алгоритм работы приложения
3.6 Алгоритм добавления лицензий
Чтобы сформировать реестр лицензий необходима возможность

добавлять новые лицензии. Алгоритм добавления новых лицензий
представлен на рисунке 3.6.
Этапы добавления лицензии:
1) начинается схема программы с блока «Начало», на данном этапе
приложение уже запущено;
2) далее следует блок «Отображение формы добавления лицензии», на
данном этапе контроллер перенаправляет на представление с формой для
ввода лицензии;
3) на этом этапе пользователь вводи все необходимые данные лицензии;
45
4) далее следует блок условия «Все поля заполнены правильно?», на
этапе которого происходит проверка введённых данных лицензии;
5) если данные лицензии были неправильно введены, то выводится
сообщение об ошибке и необходимо ввести их заново;
6) если все данные правильно введены, тогда они преобразуются в json
формат и с помощью Ajax запроса, передаются на контроллер;
7) прибывшие данные преобразуются из json формата в объект;
Рисунок 3.6 – Алгоритм добавления лицензии
8) на этом этапе в контроллере проверяются наличие лицензиата с

введённым УНП и даты срока действия лицензии;
9) если данные о лицензии были введены неправильно, то формируется
сообщение о неправильных введённых данных и отправляется на
соответствующее представление;
10) на этом этапе обрабатывается сообщение об ошибке и выводится
46
сообщение пользователю;
11) если УНП и даты верны, то формируется электронный номер
лицензии и прикрепляется к этой лицензии;
12) далее следует этап, на котором лицензия добавляется в базу данных
13) после успешного добавления лицензии в базу данных, на
контроллере формируется ответ об успешном добавлении лицензии и
передаётся на представление;
14) в этом этапе на представлении обрабатывается сообщение об
успешном добавлении лицензии и выводится пользователю.
3.7 Алгоритм формирования электронного номера лицензии
При добавлении лицензий необходимо формирование электронного

номера. Схема алгоритма формирования электронного номера лицензии
приведена на рисунке 3.7.
Рисунок 3.7 – Алгоритм формирования электронного номера лицензии
Этапы формирования электронного номера лицензии:

47
2) на этом этапе передаются данные из лицензии;
3) далее происходит получение УНП из данных лицензии;
4) из даты начала действия лицензии извлекается номер года;
5) на этом этапе происходит запрос в базу данных с помощью УНП и
года начала действия лицензии для получения количества выданных лицензий
определённому лицензиату в определённом году;
6) из приходящих данных о лицензии получают код лицензирующего
вида деятельности;
7) на данном этапе происходит формирование лицензии с помощью
УНП, кода вида деятельности, года начала действия лицензии и количестве
выданных лицензий в этом году;
8) полученный электронный номер лицензии передаётся обратно в
вызывающую функцию.
3.8 Алгоритм добавления нового пользователя
Алгоритм добавления нового пользователя показан на рисунке 3.8

Этапы добавления нового пользователя:
2) на данном этапе происходит отображение формы для регистрации
нового пользователя;
3) для идентификации, каждому пользователю необходимо иметь логин,
на этом этапе происходит ввод логина;
4) на этом этапе происходит проверка логина;
5) так как пользователь с введёнными логином существует, то выводится
сообщение об ошибке и необходимо ввести заново другой логин;
6) пользователя с введённым логином не существует, поэтому
пользователю предлагается выбор регистрации c помощью ЭЦП или без неё;
7) на этом этапе происходит получение данных из ЭЦП;
8) из-за того, что была выбрана форма регистрации без ЭЦП, то
отображается форма для заполнения данных о пользователе;
9) на данном этапе происходит ввод данных о пользователе;
10) далее происходит проверка введённых пользователем данных;
11) если данные введены некорректно, то выводится сообщения ошибке
и просьба ввести данные заново;
12) на данном этапе пользователь заносится в базу данных;
13) после добавления пользователя в базу данных, появляется
48
сообщение о запросе администратору для изменения роли;
14) происходит отправка запроса администратору;
15) так как пользователь успешно добавлен в базу данных, то выводится
сообщение об успешной регистрации.
Рисунок 3.8 – Алгоритм добавления нового пользователя
49
4 РЕАЛИЗАЦИЯ ПРОГРАММНОГО СРЕДСТВА
4.1 Обоснование выбора языка и среды программирования
Для разработки программного средства «Единый реестр лицензий»

будут использованы следующие технологии:
– Java EE;
– JavaScript;
– IntelliJ IDEA 18.1;
– Spring Boot;
– Junit 4;
– Log4j2;
– Hibernate Framework.
4.1.1 Платформа Java

Одними из самых важных критериев разработки является открытость
платформы и надежность. Платформа JavaEE [13] давно зарекомендовала
себя, как один из лидеров разработки в веб секторе. Основными
достоинствами данной платформы являются:
– открытость платформы, что требуется согласно указу
правительства №2299;
– строгая типизация;
– кроссплатформенность;
– объектная ориентированность языка;
– богатая библиотека классов;
– встроенная и прозрачная модель безопасности;
– богатый набор технологий для параллельной обработки данных, что
является важным критерием в выборе технологии для использования на
серверной части.
Java – объектно-ориентированный язык программирования,
разрабатываемый компанией SunMicrosystems с 1991 года и официально
выпущенный 23 мая 1995 года.
Объектно-ориентированный подход языка Java даёт следующие
преимущества:
– классы позволяют проводить конструирование из полезных
компонент, обладающих простыми инструментами, что дает возможность
абстрагироваться от деталей реализации;
– данные и операции вместе образуют определенную сущность, и они не
50
разбросаны по всей программе, как это нередко бывает в случае процедурного
программирования;
– локализация кода и данных улучшает наглядность и удобство
сопровождения программного обеспечения;
– инкапсуляция информации защищает наиболее критичные данные от
несанкционированного доступа.
4.1.2 Язык программирования JavaScript

JavaScript [14] – прототипно-ориентированный сценарный язык
программирования. JavaScript обычно используется как встраиваемый язык
для программного доступа к объектам приложений. Наиболее широкое
применение находит в браузерах как язык сценариев для придания
интерактивности веб-страницам.
Основные архитектурные черты:
авторизованным динамическая типизация;
– слабая типизация;
– автоматическое управление памятью;
– прототипное программирование;
– функции как объекты первого класса.
На JavaScript оказали влияние многие языки, при разработке была цель
сделать язык похожим на Java, но при этом лёгким для использования
непрограммистами.
4.1.3 Выбор среды разработки

IntelliJ IDEA – среда разработки для платформ Java SE, Java EE и Java
ME. Разработчик – компания JetBrains. Распространяется в двух версиях:
свободной бесплатной (Community Edition) и коммерческой проприетарной
(Ultimate Edition). В IntelliJ IDEA 18.1 уже доступны такие возможности
работы с JDK 9 и 10, как помощь в написании кода применительно к новому
синтаксису, включая лямбда-выражения, ссылки на методы и методы по
умолчанию, а также удобное подсвечивание кода.
4.1.4 Фреймворк Spring Boot

В качестве основы сервера выбран фреймворк Spring Boot [15]. Spring
Boot – это фреймворк для быстрой разработки приложений на основе Spring
Framework и его компонентов, входящих в Spring Data, Spring Security и другие
подпроекты. Spring Boot предоставляет огромное количество
сконфигурированных компонентов, что позволяет сократить время,
51
затрачиваемое на конфигурирование приложения и сосредоточиться
непосредственно на разработке, а также упрощает работу с зависимостями.
Некоторые возможности, предоставляемые Spring Boot:
– создание полноценных Spring приложений;
– встроенный Tomcat или Jetty;
– обеспечивает начальные POMs для упрощения Maven конфигурации;
– автоматическая конфигурация Spring когда это возможно;
– обеспечивает такими возможностями, как метрики, мониторинг
состояниями и расширенная конфигурация;
– абсолютно без генерации кода и без написания XML конфигурация.
Для инициализации Spring Boot приложения в pom файл в качестве
проекта «родителя» установлен «spring-boot-starter-parent». Точкой входа в
приложение является класс Main.java, отмеченный аннотацией
SpringBootApplication. Он содержит единственный метод public static void main
в котором вызывается Start.run. По вызову метода run начинается
инициализация контейнера Spring, сканируются пакеты проекта на наличие
компонентов Spring Framework и их инициализация.
4.1.5 Использование ORM фреймворка Hibernate

Hibernate [16] – библиотека для языка программирования java,
предназначенная для решения задач объектно-реляционного отображения
(ORM). Целью Hibernate является освобождение разработчика от
значительного объёма низкоуровневого программирования при работе в
объектно- ориентированных средствах в реляционной базе данных.
Библиотека не только решает задачу связи классов java с таблицами базы
данных, но и также предоставляет средства для автоматической генерации и
обновления набора таблиц, построения запросов и обработки полученных.
Hibernate обеспечивает прозрачную поддержку сохранности данных для
стандартных java-объектов.
Для создания объектно-реляционного отображения класса java таблицу
базы данных, необходимо выполнить несколько действий. В приложении А
представлен пример конфигурации класса License. Рассмотрим основные
настройки маппинга:
1) аннотация @Entity указывает на то, что объект данного класса
соответствует сущности базы данных из таблицы license;
2) аннотация @Id определяет уникальный идентификатор объекта,
данное поле отображается в первичный ключ в таблице базы данных.
Аннотация @GeneratedValue говорит о том, что значение первичного ключа,
52
при сохранении объекта в базу данных будет сгенерировано автоматически;
3) аннотация @ManyToOne указывает на то, что сущность License
связана с сущностью Ulandie отношением многие к одному, с помощью
аннотации @JoinColumn указывается, какой атрибут таблицы license будет
внешним ключом на таблицу ulandie.
Свойства класса License не помеченные аннотациями отображаются в
атрибуты таблицы license соответствующих типов.
4.2 Разработка моделей данных
Программное средство «Единый реестр лицензий» использует сущности

предметной области. Для описания этих сущностей используются модели
данных. Модели данных описывают структуру базы данных, в которой будут
храниться данные приложения.
Были созданы следующие модели:
– AppUser;
– AppRole;
– AppUserInfo;
– License;
– LicenseAction;
– LicenseActivity;
– LicenseServices;
– AdministrativeTerritories;
– TypeOfCompany.
Модель AppUser представляет пользователя приложения. Содержит
идентификатор, имя пользователя (логин), зашифрованный пароль,
коллекцию ролей и ссылку на личную информацию.
Модель AppRole представляет роль пользователя приложения.
Содержит идентификатор, название роли и список пользователей.
Модель AppUserInfo представляет личную информацию пользователя.
Содержит идентификатор, ФИО, email, место работы, номер телефона,
должность и ссылку на пользователя.
Модель License представляет лицензию. Содержит идентификатор, дату
начала и конца действия лицензии, дату принятия решения, комментария,
предварительный запрос, электронный номер, номер формы,
регистрационный номер, УНП лицензиата, ссылку на вид деятельности,
ссылку на лицензиата.
53
Модель LicenseAction представляет собой информацию об изменении в
лицензии. Содержит идентификатор, дату начала и конца действия, код
изменения и название действия.
Модель LicenseActivity представляет вид деятельности. Содержит
идентификатор, код вида деятельности и название вида деятельности.
Модель LicenseServices представляет собой услуги, которые даёт
лицензия. Содержит идентификатор, дату начала и конца действия, код услуги
и название услуги.
Модель AdministrativeTerritories представляет собой административные
территории. Содержит идентификатор, код области, код района, код
сельсовета, код города, название города, название района, СОАТО, название
области и сокращённые названия.
Модель TypeOfCompany представляет тип компании. Содержит
идентификатор, дату начала, дату конца действия, название типа и
сокращённое название типа.
4.3 Описание классов и методов серверной части приложения
При разработке классов программного средства для графического

представления была использована диаграмма классов. Данная диаграмма
Класс EgrController используется для того, чтобы запрашивать данные
из системы «Единый государственный регистр юридических лиц и
индивидуальных предпринимателей» и отображать данные о лицензиате. В
классе EgrController находится только одна функция:
– public String index() – функция, которая связывает контроллер и
представление на котором происходит запрос на сторонний ресурс.
Класс LicenseController используется для вывода лицензий и
осуществления поиска по ним. В него входят следующие приватные поля:
– gson – поле, с помощью которого данные преобразуются в json формат
и обратно (тип поля – Gson);
– entityManager – поле, используемое для доступа к базе данных,
например, с помощью метода entityManager.createNativeQuery(«Запрос в базу
данных») можно вызывать хранимые процедуры и функции базы данных (тип
поля – EntityManager);
– licenseRepository – поле, через которое происходит связь с таблицей
licenserepository в базе данных, для получения, изменения или удаления
лицензии из базы данных (тип поля - LicenseRepository);
54
– licenseActivityRepository – поле, через которое происходит связь с
таблицей licenseactivityrepository в базе данных, для получения, изменения или
удаления вида деятельности лицензии из базы данных (тип поля -
LicenseActivityRepository);
– log – поле, с помощью которого происходит логирование действий
приложения (тип поля - Logger).
Класс LicenseController имеет единственный конструктор, который
отвечает за его инициализацию:
– public LicenseController(Gson g, EntityManager entityManager,
LicenseRepository licenseRepository, LicenseActivityRepository
licenseActivityRepository) – конструктор, задачей которого является создание
объекта LicenseController, а так же инициализация его приватных полей.
Так же в классе LicenseController имеются следующие методы,
отвечающие за вывод и поиск лицензий:
– public String index() – публичный метод, отвечающий за вывод
начальной страницы с лицензиями;
– public AjaxResponse getLicense(String page) – публичный метод, с
помощью которого из базы берутся 20 лицензий с отступом, переданным в
параметр page;
– public void getPage() – метод, для получения количества страниц;
– private ArrayList<License> ParseLicense(ArrayList<License> License,
List Services) – приватный метод, использующийся, для обработки лицензий,
взятых из базы данных;
– private List parseServices(List<Object[]> serviceList) – приватный метод
для обработки услуг лицензий, взятых из базы данных;
– public AjaxResponse Search(String jsonSearchCriterion) – публичный
метод, с помощью которого происходи поиск по лицензиям.
Класс LicenseInputController используется для вывода лицензий и
осуществления поиска по ним. В него входят приватное поле ulandieRepository
и поля как в классе LicenseController:
– gson;
– entityManager;
– licenseRepository;
– licenseActivityRepository;
– ulandieRepository - поле, через которое происходит связь с таблицей
ulandierepository в базе данных, для получения, изменения или удаления
организации из базы данных (тип поля - UlandieRepository).
Класс LicenseInputController имеет единственный конструктор, который
55
отвечает за его инициализацию:
– public LicenseInputController (LicenseActivityRepository
licenseActivityRepository, UlandieRepository ulandieRepository,
LicenseRepository licenseRepository, UserRepository userRepository, Gson g,
EntityManager entityManager) – конструктор, задачей которого является
создание объекта LicenseInputController, а также инициализация его
приватных полей.
Так же в классе LicenseInputController имеются следующие методы,
отвечающие добавление новой лицензии:
– public String index() – публичный метод, отвечающий за вывод
начальной страницы формой ввода лицензии;
– public DropDown getActivities() – публичный метод, с помощью
которого в представление загружается список видов деятельности;
– private String createElectronicNumberFotLicense(License license) –
приватный метод, формирующий электронный номер лицензии;
– public AjaxResponse saveLicense (String jsonLicense) – публичный
метод, с помощью которого происходи добавление лицензии в базу данных.
Класс WebSecurityConfig используется для авторизации, регистрации и
доступом пользователей. В него входят следующие поля:
– userDetailsService – поле для получения и использования пользователя
(тип поля - UserDetailsService);
– bCryptPasswordEncoder – поле, c помощью которого происходит
шифрование пароля пользователя.
Так же в классе WebSecurityConfig имеются следующие методы:
– public void configureGlobal() – публичный метод, отвечающий за поиск
пользователя в базе данных и установки метода шифрования пароля;
– protected void configure (HttpSecurity http) – метод, в котором
формируется доступ пользователей к различным функциям приложения.
56
Рисунок 4.1 – Диаграмма классов
57
5 ТЕСТИРОВАНИЕ ПРОГРАММНОГО СРЕДСТВА
Перед тем, как предоставить конечным пользователям возможность

работать с приложением, требуется провести его тестирование.
Для выполнения юнит-тестирования в Java существует Фреймворк под
названием Junit [17]. Он предоставляет нам следующие возможности:
– базовые классы и Аннотации для написания юнит-тестов;
– базовый класс для запуска тестов – TestRunnerclass;
– поддержка классов и аннотаций для написания «test-suits» – @RunWith
(Suite.Class);
– отчет о результатах тестирования.
В случае успешного выполнения, которого считается, что тест пройден.
Тестовые методы выделяются с помощью аннотации @org.junit.Test. Проверка
соответствия полученного значения ожидаемому происходит в методах
assertEquals, assertNotNull и assertTrue. Существует целая группа методов вида
assertXxx. Для того чтобы тест считался пройденным успешно, ему нужно
успешно пройти все «ассерты», которые в нем есть.
Однако такое тестирование не может проверить некоторые этапы,
поэтому проводится ручное тестирование. Проведённые тест-кейсы
приведены в таблице 5.1.
Таблица 5.1 – Тестирование программного средства

№ Описание тест-кейса Ожидаемый результат Фактический
результат
1 1 Запустить приложение Открылась форма ввода Совпадает с
2 Нажать кнопку Войти логина и пароля ожидаемым.
2 1 Запустить приложение Авторизация в системы Совпадает с
2 Нажать на гиперссылку выполнена успешно ожидаемым.
Войти
3 Ввести правильный логин
и пароль
3 1 Запустить приложение Появление сообщения об Совпадает с
2 Нажать кнопку Войти ошибке, авторизация не ожидаемым.
3 Ввести неправильный выполнена
логин или пароль
58
Продолжение таблицы 5.1
результат
4 1 Запустить приложение Открылась страница со Совпадает с
2 Успешно войти в систему списком лицензий ожидаемым.
3 Нажать на гиперссылку
Личный кабинет
посмотреть все лицензии
5 1 Запустить приложение Открылась другая Совпадает с
2 Успешно войти в систему страница с лицензиями ожидаемым.
3 Нажать кнопку Личный
кабинет
4 Нажать кнопу посмотреть
все лицензии
5 Нажать на кнопки
пагинации под списком
лицензий
6 1 Запустить приложение Появляется форма для Совпадает с
2 Успешно войти в систему поиска по лицензиям ожидаемым.
3 Нажать кнопку Личный
кабинет
5 Нажать кнопку Поиск по
лицензиям
7 1 Запустить приложение Вывод лицензий с Совпадает с
2 Успешно войти в систему заданными критериями ожидаемым.
лицензиям
6 Ввести критерии поиска и
нажать кнопку поиск
59
результат
8 1 Запустить приложение Появляется сообщение с Совпадает с
2 Успешно войти в систему ошибкой, поиск не ожидаемым.
3 Нажать на гиперссылку производится
лицензиям
6 Ввести неправильные
критерии поиска и нажать
кнопку поиск
9 1 Запустить приложение Отображение формы с Совпадает с
2 Успешно войти в систему вводом УНП и вывод ожидаемым.
3 Нажать на гиперссылку информации о введённой
Личный кабинет организации
Единый государственный
регистр юридических лиц и
индивидуальных
предпринимателей
5 Ввести УНП
6 Нажать на кнопку Поиск
10 1 Запустить приложение Открывается страница с Совпадает с
2 Успешно войти в систему формой для ввода ожидаемым.
3 Нажать на гиперссылку информации о лицензии
Загрузить лицензии
11 1 Запустить приложение Срабатывание Совпадает с
2 Успешно войти в систему выпадающего списка с ожидаемым.
3 Перейти на страницу видами деятельности и
загрузки лицензии успешный выбор одного
4 Нажать на поле Вид из них
деятельности
60
результат
12 1 Запустить приложение Появляется окно с Совпадает с
2 Успешно войти в систему сообщение об успешном ожидаемым.
3 Перейти на страницу добавлении лицензии
загрузки лицензии
4 Ввести правильные
данные и нажать на кнопку
добавить
13 1 Запустить приложение Неправильные Совпадает с
2 Успешно войти в систему введённые поля ожидаемым.
3 Перейти на страницу подсвечиваются
загрузки лицензии красным, под кнопкой
4 Ввести неправильные появляется сообщение с
данные и нажать на кнопку ошибкой
добавить
14 1 Запустить приложение Открывается страница с Совпадает с
2 Успешно войти в систему формой добавления ожидаемым.
в качестве Администратора нового пользователя
Управление пользователями
Добавление нового
15 1 Запустить приложение Появляется окно с Совпадает с
2 Успешно войти в систему сообщение об успешном ожидаемым.
в качестве Администратора добавлении пользователя
3 Перейти на страницу
добавления нового
4 Правильно заполнить
форму и нажать на кнопку
добавить
61
результат
16 1 Запустить приложение Подсвечиваются Совпадает с
2 Успешно войти в систему в красным неправильно ожидаемым.
качестве Администратора заполненные поля и
3 Перейти на страницу вывод сообщения об
добавления нового ошибке
4 Неправильно заполнить
форму и нажать на кнопку
добавить
17 1 Запустить приложение Открывается страница Совпадает с
2 Успешно войти в систему в со списком ожидаемым.
качестве Администратора пользователей
3 Перейти на страницу
управления пользователями
Просмотр списка всех
пользователей
18 1 Запустить приложение Пользователь исчезает Совпадает с
2 Успешно войти в систему в из списка ожидаемым.
качестве Администратора 3
Создать тестового
4 Перейти на страницу списка
всех пользователей
5 Удалить пользователя
19 1 Запустить приложение После редактирования Совпадает с

2 Успешно войти в систему в пользователя, его ожидаемым.
качестве Администратора данные должны быть
4 Перейти на страницу списка изменены в таблице
всех пользователей всех пользователей
5 Редактировать пользователя
6 Удалить пользователя
62
6 РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ
Для возможности использования функций приложения пользователь

должен быть авторизован. Окно авторизации пользователя в системе
представлено на рисунке 6.1.
Рисунок 6.1 – Окно авторизации
С помощью этого окна пользователь может войти в систему с помощью

логина и пароля, если он уже зарегистрирован, может войти с помощью
электронно-цифровой подписи или может перейти на форму регистрации.
Если пользователь ввёл неверный логин и пароль, то появляется
сообщение об ошибке. Пример приведён на рисунке 6.2.
Рисунок 6.2 – Ошибка авторизации
После того, как пользователь успешно авторизуется в системе, ему

станет доступен личный кабинет, в котором находится меню, через которое он
может перейти на страницы:
– просмотра всех лицензий;
– просмотра информации об лицензиате, через сервис ЕГР;
63
– загрузки лицензии через xml файл;
– загрузки лицензии через форму;
– страница управления пользователями.
В зависимости от роли пользователя ему доступны различные страницы
приложения. Только пользователю с ролью «Менеджер» доступна
возможность загружать лицензии и только пользователю с ролью
«Администратор» доступна функция управления другими пользователями.
Страница просмотра лицензий доступна для всех пользователей. Она
Рисунок 6.3 – Страница просмотра всех лицензий
На этой странице возможно просматривать весь реестр лицензий, а

также проводить поиск по лицензиям (рисунок 6.4).
Рисунок 6.4 – Поиск по лицензиям
64
Поиск может быть выполнен по 4 полям:
– УНП;
– электронный номер лицензии;
– вид деятельности.
Можно производить поиск как по всем критериям, так и по нескольким.
Поиск по названию организации регистронезависимый и возможен по любой
части названия организации. Критерий «Вид деятельности» – это выпадающий
список, который загружается из базы данных.
Страница просмотра лицензиатов представлена на рисунке 6.5
Рисунок 6.5 – Страница информации об лицензиате
Страница загрузки лицензий через форму представлена на рисунке 6.6.

Для того, чтобы добавить лицензию нужно ввести обязательные поля:
– дата начала действия лицензии;
– предварительный запрос;
– номер решения о выдаче лицензии;
65
– регистрационный номер;
– УНП.
Если эти поля не будут заполнены или заполнены неправильно, то, по
нажатию на кнопку «Добавить», они будут подсвечены красны цветом и
появится сообщения об ошибке (рисунок 6.7).
Рисунок 6.6 – Страница добавления лицензии
Так же имеются необязательные поля:

– дата окончания действия лицензии;
– номер формы;
– комментарии.
Рисунок 6.7 – Сообщения об ошибке при добавлении лицензии
66
На странице управления пользователями доступны две гиперссылки:
– создание нового пользователя;
– просмотр списка пользователей.
Страница добавления нового пользователя показана на рисунке 6.8. На
этой странице находится форма из девяти обязательных полей:
– логин;
– пароль;
– повтор пароля;
– email;
– фамилия;
– полное имя;
– отчество;
– место работы;
– должность.
Все девять полей должны быть правильно заполнены, иначе, при
нажатии на кнопку «Создать», появится сообщение об ошибке выполненном в
стиле, как показано на рисунке 6.7.
Рисунок 6.8 – Страница добавления нового пользователя
67
На странице просмотра списка пользователей (рисунок 6.9) находится
таблица со всеми пользователями и их личными данными. С помощью этой
таблицы можно удалить пользователя или перейти на страницу
редактирования его данных.
Рисунок 6.9– Страница со списком всех пользователей
При нажатии на кнопку «Редактировать» пользователь переходит на

страницу редактирования (рисунок 6.10), в которой может изменять данные,
введённые при регистрации и изменять роль пользователя в системе.
Рисунок 6.10 – Страница редактирования данных пользователя
68
7 ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ
РАЗРАБОТКИ И ВНЕДРЕНИЯ ПС
Целью дипломного проекта является разработка программного средства

государственной информационной системы «Единый реестр лицензий».
Использование данного программного средства позволит сократить
время и расходы, выделенные на администрирование и управление
лицензиями.
Целью технико-экономического обоснования ПС является определение
экономической выгодности создания данного продукта и его дальнейшего
применения для разработчика и пользователя.
Для достижения поставленной цели необходимо рассчитать смету затрат
и цену программного средства.
7.1 Расчёт сметы затрат и цены программного средства
Исходные данные для разрабатываемого проекта представлены в

таблице 7.1.
Таблица 7.1 – Исходные данные

Условное
Наименование Значение
обозначение
Коэффициент новизны, ед. Кн 0,7
Группа сложности, ед. 2
Дополнительный коэффициент сложности, ед. Кс 1,26
Поправочный коэффициент, учитывающий
Кт 0,6
использование типовых программ, ед.
Установленная плановая продолжительность
Тр 0,17
работ, лет
Продолжительность рабочего дня, ч Тч 8
Тарифная ставка 1-го разряда, руб. Тм1 33
Коэффициент премирования, ед. Кп 3,91
Норматив дополнительной заработной платы
Нд 20
исполнителей, %
Отчисления в фонд социальной защиты, % Нсз 34
Отчисления в Белгосстрах, % 0,6
Норматив расходов на командировки, % 18
69
Объём программного средства определяется с помощью подбора
аналогов на основании классификации типов программных средств, каталога
функций программных средств и каталога аналогов программных средств в
разрезе функций, которые постоянно обновляются и утверждаются в
установленном порядке. На основании информации о функциях
разрабатываемого программного средства по каталогу функций определяется
объём функций. Объем программного средства определяется на основе
нормативных данных, приведённых в таблице 7.2.
Таблица 7.2 – Перечень и объём функций программного средства

№ функции Наименование (содержание) Объём функции
101 Организация ввода информации 160
Контроль, предварительная обработка и
102 600
ввод информации
Организация ввода / вывода информации в
109 430
интерактивном режиме
111 Управление вводом / выводом 1900
201 Генерация структуры базы данных 1450
203 Формирование баз данных 630
207 Манипулирование данными 500
208 Организация поиска и поиск в базе данных 4740
305 Обработка файлов 1220
306 Обработка файлов в диалоговом режиме 600
308 Управление файлами 1900
506 Обработка ошибочных и сбойных ситуаций 930
707 Графический вывод результатов 420
Итого 15480
Общий объем программного продукта определяется исходя из

количества и объёма функций, реализованных и считается по формуле 7.1:
𝑉о = ∑ 𝑉𝑖 , (7.1)
𝑖=0
где 𝑉𝑖 – объём отдельной функции ПС;

𝑛 – общее число функций.
70
На основе данных, приведённых в таблице 7.1, общий объём ПО
составил 𝑉о = 15480 (строк кода).
На основании общего объема ПС определяется нормативная
трудоёмкость (Тн ) с учётом сложности ПС. Для ПС 1-ой группы, к которой
относится разрабатываемый программный продукт, нормативная
трудоёмкость составит 406 человеко-дней.
Нормативная трудоёмкость служит основой для оценки общей
трудоёмкости То . Общая трудоёмкость определяется по формуле 7.2:
Tо = Tн ∙ Кс ∙ Кт ∙ Кн , (7.2)
где Кс – коэффициент, учитывающий сложность ПС;

Кт – поправочный коэффициент, учитывающий степень использования
при разработки стандартных модулей;
Кн – коэффициент, учитывающий степень новизны ПС.
Дополнительные затраты труда на разработку ПС учитываются через
коэффициент сложности, который вычисляется по формуле 7.3:
Кс = 1 + ∑ К𝑖 , (7.3)
𝑖=1
где К𝑖 – коэффициент, соответствующий степени повышения сложности ПО

за счёт конкретной характеристики;
𝑛 – количество учитываемых характеристик.
Наличие двух характеристик сложности позволяет вычислить
коэффициент сложности, используя формулу 7.4:
Кс = 1 + 0,06 + 0,08 + 0,12 = 1,26. (7.4)
Разрабатываемое ПО использует стандартные компоненты.

Степень использования стандартных компонентов определяется
коэффициентом использования стандартных модулей – Кт . Указанный
коэффициент для разрабатываемого приложения Кт = 0,6. Трудоёмкость
создания ПО также зависит от его новизны и наличия аналогов.
Разрабатываемое ПО не является новым, существуют аналогичные
более зрелые разработки у различных компаний и университетов по всему
71
миру. Влияние степени новизны на трудоёмкость создания ПО определяется
коэффициентом новизны – Кт . Для разрабатываемого ПО Кн = 0,7.
Подставив приведённые выше коэффициенты для разрабатываемого ПО
в формулу (7.2) получим общую трудоёмкость разработки, рассчитываемую
по формуле 7.5:
То = 406 ∙ 1,26 ∙ 0,6 ∙ 0,7 ≈ 215 чел./дн. (7.5)
На основе общей трудоёмкости и требуемых сроков реализации проекта

вычисляется плановое количество исполнителей. Численность исполнителей
проекта рассчитывается по формуле 7.6:
То
Чр = , (7.6)
Тр ∙ Фэф
где То – общая трудоёмкость разработки проекта, чел./дн.;

Фэф – эффективный фонд времени работы одного работника в течение
года, дн.;
Тр – срок разработки проекта, лет.
Эффективный фонд времени работы одного разработчика вычисляется
по формуле 7.7:
Фэф = Дг − Дп − Дв − До , (7.7)
где Дг – количество дней в году, дн.;

Дп – количество праздничных дней в году, не совпадающих с
выходными днями, дн.;
Дв – выходных дней в году, дн.;
До – количество дней отпуска, дн.
Согласно данным, приведённым в производственном календаре для
пятидневной рабочей недели году для Беларуси, используя формулу 7.8, фонд
рабочего времени составит:
Фэф = 365 − 8 − 104 − 24 = 229 дн. (7.8)
72
Учитывая срок разработки проекта Тр = 2 мес. = 0,17 года, общую
трудоёмкость и фонд эффективного времени одного работника, вычисленные
ранее, можно рассчитать численность исполнителей проекта по формуле 7.9:
229
Чр = ≈ 6 человек. (7.9)
0,17 ∙ 215
7.2 Расчёт заработной платы исполнителей
Расчёт основной заработной платы осуществляется в следующей

последовательности.
Определим месячные (Тм ) и часовые (Тч ) тарифные ставки ведущего
инженера-программиста (тарифный разряд – 15; тарифный коэффициент –
3,48), двух инженеров-программистов 1-й категории (тарифный разряд – 14;
тарифный коэффициент – 3,25) и инженера-программиста 2-ой категории
(тарифный разряд – 13; тарифный коэффициент – 3,04).
Месячная тарифная ставка каждого исполнителя (Тм ) определяется
путём умножения действующей месячной тарифной ставки 1-ого разряда (Тм1 )
на тарифный коэффициент (Тк ), соответствующий установленному
тарифному разряду.
Определим часовую тарифную ставку ведущего инженера-
программиста по формуле 7.10:
вед.прогр. 33 ∙ 3,48
Тч = = 0,68 руб./ч. (7.10)
168
Определим часовую тарифную ставку инженера-программиста первой

категории по формуле 7.11:
прогр.Ι−кат. 33 ∙ 3,25
Тч = = 0,64 руб./ч. (7.11)
168
Определим часовую тарифную ставку инженера-программиста второй

категории по формуле 7.12:
прогр.ΙΙ−кат. 33 ∙ 3,04
Тч = = 0,6 руб./ч. (7.12)
168
73
Расчёт месячных и почасовых тарифных ставок сведен в таблицу 7.3.
Таблица 7.3 – Исполнители и трудоёмкость проекта

Тарифный Месячная Часовая
Чел./дн. Тарифный
Должность коэффицие тарифная тарифная
занятости разряд
нт ставка ставка
Ведущий
инженер- 35,8 15 3,48 119 0,68
программист
Инженер-
35,8 14 3,25 110,5 0,64
1-й
категории
Инженер-
35,8 14 3,25 110,5 0,64
1-й
категории
Инженер-
35,8 13 3,04 103,7 0,6
2-й
категории
Инженер-
программист 0,6
35,8 13 3,04 103,7
2-й
категории
Инженер-
35,8 13 3,04 103,7 0,6
2-й
категории
Основная заработная плата рассчитывается по формуле 7.13:
Зо = ∑ Т𝑖ч ∙ Тч ∙ Фп ∙ Кп , (7.13)
𝑖=1
где Т𝑖ч – часовая тарифная ставка i-ого исполнителя, руб./ч.;

Тч – количество часов работы в день, ч.;
74
Фп – плановый фонд рабочего времени i-ого исполнителя, дн.;
Кп – коэффициент премирования.
Сумма основной заработной платы считается по формуле 7.14:
Зо = 0,68 ∙ 8 ∙ 35,8 ∙ 3.91 + 2 ∙ (0,64 ∙ 8 ∙ 35,8 ∙ 3.91)

+ 3 ∙ (0,6 ∙ 8 ∙ 35,8 ∙ 3.91) = 4210 руб. (7.14)
Дополнительная заработная плата (Зд ) определяется по нормативу в

процентах к основной заработной плате по формуле 7.15:
Зо ∙ Нд
Зд = , (7.15)
100%
где Нд – норматив дополнительной заработной платы в целом по организации,

равный 20%.
Таким образом, дополнительная заработная плата (Зд ) вычисляется по

формуле 7.16:
4210 ∙ 20%
Зд = ≈ 842руб. (7.16)
100%
Расчёт себестоимости и отпускной цены ПС приведён в таблице 7.4.
Таблица 7.4 – Расчёт себестоимости и отпускной цены ПС

Значение,
Наименование статей Норматив Методика расчёта
руб.
Отчисление в фонд (Зо + Зд ) ∙ Нсз
Нсз = 34% Зсз = 1717
социальной защиты 100%
Отчисления в (Зо + Зд ) ∙ Нне
Нне = 0,6% Не = 30
Белгосстрах 100%
Материалы и Нм ∙ 𝑉𝑜
Нм = 0,38% М= 59
комплектующие 100%
Цм
Цм ∙ 𝑉𝑜
Машинное время = 0,56 руб Рм = 7,2
100 ∙ Нмв
Нмв = 12
75
Расходы на научные Зо ∙ Нк
Нк = 18% Рк = 757,8
командировки 100%
Прочие прямые Зо ∙ Нпз
Нпз = 21% Пз = 884,1
расходы 100%
Зо ∗ Нрн
Накладные расходы Нрн = 100% Рн = 4210
100%
Сп = Зо + Зд + Зсз +
Полная себестоимость – +Не + М + Рм + Рк + 12717,1
+Пз + Рн
Прогнозируемая С п ∙ Ур
Ур = 30% Ппс = 3815,13
прибыль 100%
Прогнозируемая цена
– Цп = Сп + Ппс 16532,23
без налогов
Отчисления и налоги в
местный и Цп ∙ Нмр
Нмр = 3,9% Омр = 644,76
республиканский 100% − Нмр
бюджеты
Отчисления и налоги в
местный и Цп ∙ Нмр
Нмр = 3,9% Омр = 644,76
республиканский 100% − Нмр
бюджеты
Налог на добавленную (Цп + Омр ) ∙ Ндс
Ндс = 20% НДС = 3435,4
стоимость 100%
Прогнозируемая
– Цо = Цп + Омр + НДС 20612,39
отпускная цена
Сп ∙ Но
Освоение ПС Но = 10% Ро = 1271,71
100%
Сп ∙ Нс
Сопровождение ПС Нс = 20% Рс = 2543,42
100%
7.3 Оценка экономической эффективности применения

программного средства у пользователя
Для расчёта экономического эффекта применения нового ПС

необходимы данные имеющегося внедрённого на производстве аналога
(базового варианта). Некоторые показатели базового варианта не могут быть
получены (составляют коммерческую тайну либо защищены авторскими
76
правами разработчиков). Поэтому расчёт экономического эффекта будем
проводить, опираясь на известные данные показателей базового и нового
варианта ПС. Показатели обоих вариантов приведены в таблице 7.5.
Таблицы 7.5 – Исходные данные для расчёта экономического эффекта

Базовый Новый
Наименование показателей Обозначение
вариант вариант
Капитальные вложения, руб. Кпр – 20612,39
Затраты на освоение ПС,
Кпс – 1271,71
руб.
Затраты на сопровождение
Кс – 2543,42
ПС, руб.
Всего затрат, руб. 24427,52
Стоимость одного часа
Сп 14 14
простоя, руб.
Время простоя сервиса,
обусловленное ПО, в день, П1 , П2 18 13
мин
Среднемесячная зарплата
Зсм 1500 1500
одного программиста, руб.
Коэффициент начислений на
Кн 1,5 1,5
зарплату
Среднемесячное количество
Др 22 22
рабочих дней, дн.
Количество типовых задач,
Зт1 , Зт2 3100 3100
решаемых за год
Объем выполняемых работ А1 , А2 4600 4600
Средняя трудоёмкость работ
Тс1 , Тс2 1 0,75
в расчёте на задачу
Количество часов работы в
Тч 8 8
день, ч
Ставка налога на прибыль, % Нп 18 18
77
7.4 Расчёт капитальных затрат
Общие капитальные вложения (Ко ) заказчика (потребителя), связанные

с приобретением, внедрением и использованием программного средства,
представлены в таблице 7.6.
Таблица 7.6 – Расчёт капитальных затрат

Наименование Методика расчёта Значение (руб.)
Затраты пользователя на
приобретение ПС по отпускной Кпр 20612,39
цене разработчика
Затраты на освоение ПС Кос 1271,71
Затраты на сопровождение ПС Кс 2543,42
Общие капитальные вложения Ко = Кпр + Кос + Кс 24427,52
Экономия затрат на Зсм ∙ (Тс1 − Тс2 )
заработную плату на одну Сзе = 2,13
Тч ∙ Др
задачу
Экономия на заработную плату
Сз = Сзе ∙ А2 9798
при использовании нового ПС
Экономия с учётом начисления
Сн = Сз ∙ Кн 14697
на заработную плату
Экономия за счёт сокращения (П1 − П2 ) ∙ Сп ∙ Др
Сс = 25.67
простоя сервиса 60
Общая годовая экономия
текущих затрат, связанных с Со = Сн +Сс 14722,67
использованием нового ПС
Исходя из расчетов, внедрение нового программного средства позволит

пользователю сэкономить на текущих затратах 14722,67руб.
7.5 Расчёт экономического эффекта
Для пользователя в качестве экономического эффекта выступает лишь

чистая прибыль – дополнительная прибыль, остающаяся в его распоряжении
(Пч ), которая определяется по формуле 7.17:
78
Нп
 Пч = Со − Со ∙ , (7.17)
100
где Нп – ставка налога на прибыль, равная 18%.

Тогда чистая прибыль будет высчитана по формуле 7.18:
Пч = 14722,67 − 14722,67 ∙ 0,18 = 12072,59 руб. (7.18)
В процессе использования нового ПС чистая прибыль в конечном итоге

возмещает капитальные затраты. Однако полученные при этом суммы
результатов (прибыль) и затрат (капитальных вложений) по годам приводят к
единому времени – расчётному году (за расчётный принят 2018 год) путём
умножения результатов и затрат за каждый год на коэффициент приведения
(𝛼1 ), который рассчитывается по формуле 7.19:
𝛼1 = (1 + Е𝑖 )𝑡𝑝−𝑡 , (7.19)
где Е – норматив дисконтирования разновременных затрат и результатов;

𝑡𝑝 – расчётный период;
𝑡 – период, потоки которого приводятся к расчётному.
Коэффициентам приведения (𝛼1 ) по годам будут соответствовать
значения, высчитанные по формуле 7.19. За основу принимается 2018 год и
расчеты ведутся до 2021 года по формулам 7.20 – 7.23, соответственно:
𝛼1 = (1 + 0,15)1−1 = 1 – расчетный год; (7.20)
𝛼2 = (1 + 0,15)1−2 = 0.8696 – 2019 год; (7.21)
𝛼3 = (1 + 0,15)1−3 = 0.7561 – 2020 год; (7.22)
𝛼4 = (1 + 0,15)1−4 = 0.6575 – 2021 год. (7.23)
Расчёт экономического эффекта от использования программного

средства представлен в таблице 7.7
79
Таблица 7.7 – Расчёт экономического эффекта от использования нового
программного средства
Показатели 2018 2019 2020 2021
Результаты
Прирост прибыли
за счет экономии – 12072,59 12072,59 12072,59
затрат, руб.
Прирост прибыли
с учетом фактора – 10498,32 9128,09 7937,73
времени, руб.
Затраты
Приобретение
20612,39 – – –
ПС, руб.
Освоение ПС,
1271,71 – – –
руб.
Сопровождение
2543,42 – – –
ПС, руб.
Всего затрат, руб. 24427,52 – – –
С учётом фактора
24427,52 – – –
времени, руб.
Экономический эффект
Превышение
результата над 24427,52 10498,32 9128,09 7937,73
затратами, руб.
То же с
нарастающим -24427,52 -13929,2 -42a01,11 3736,62
итогом, руб.
Коэффициент
1 0,8696 0,7561 0,6575
приведения, ед.
Из приведённой выше таблицы видно, что затраты на разработку

программного средства окупаются к 2021 году.
80
7.6 Выводы по технико-экономическому обоснованию
Чистая прибыль от реализации ПС (Пч = 12072,59 руб.) остаётся

организации-разработчику и представляет собой экономический эффект от
создания нового программного средства. Положительный экономический
эффект главным образом достигается за счёт уменьшения трудоёмкости работ
пользователей в расчёте на одну задачу.
Прогнозируемая отпускная цена (Цо ) составляет 20612,39 рублей.
Продукт является экономически выгодным, так как он окупается менее
чем за три года эксплуатации, что означает экономическую целесообразность
данной разработки.
81
ЗАКЛЮЧЕНИЕ
В ходе разработки программного средства был проведен анализ

предметной области, в том числе были проанализированы существующие
аналоги различных реестров.
Выбраны оптимальные технологии для использования в ходе
разработки, такие как язык и платформа разработки (JavaEE и Spring Boot) и
способы хранения данных (PostgreSQL)
Смоделирована информационная модель разрабатываемого
программного средства, а также разработана структура базы данных.
Произведено проектирование программного средства, разработана
программная архитектура, схема развертывания программного средства, а
также разработаны алгоритмы основных функций программного средства, в
том числе общий алгоритм работы приложения.
Произведено тестирование программного средства, которое показало
полное соответствие разработанного программного средства спецификации
требований.
В завершение, разработаны методики использования программного
средства для пользователя.
Рассмотрено технико-экономическое обоснование дипломного проекта,
которое показало, что разработка экономически выгодна.
Итогом выполнения дипломного проекта является программное
средство единый реестр лицензий, которое полностью соответствует
спецификации требований к программному средству.
В новой версии программного средства планируется добавить возможность
просмотра, редактирования и добавления справочников и подачи документов для
утверждения новых лицензий.
82
83
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
[1] Национальный правовой интернет-портал Республики Беларусь

[Электронный ресурс]. – Режим доступа: www.pravo.by/pravovaya-informatsiya
/normativnye-dokumenty/litsenzirovanie/. Дата доступа: 13.04.2018.
[2] Эстонский государственный инфопротал [Электронный ресурс]. –
Режим доступа: https://www.eesti.ee/ru/ . Дата доступа: 13.04.2018.
[3] Информационная система электронного лицензирования Республики
Беларусь [Электронный ресурс]. – Режим доступа: http://e-license.gov.by . Дата
доступа: 13.04.2018.
[4] Единый государственный регистр юридических лиц и
индивидуальных предпринимателей [Электронный ресурс]. – Режим доступа:
http://egr.gov.by/egrn/ . Дата доступа: 13.04.2018.
[5] Общегосударственная автоматизированная информационная
система [Электронный ресурс]. – Режим доступа: https://nces.by/
service/services_oais/ . Дата доступа: 13.04.2018.
[6] Рамбо, Дж. UML 2.0 Объектно-ориентированное моделирование и
разработка / Дж. Рамбо. – Санкт-Петербург : Питер, 2007. – 544 с.
[7] Информационная модель предметной области базы данных
[Электронный ресурс]. – Электронные данные. – Режим доступа:
http://www.intuit.ru. Дата доступа: 23.04.2018
[8] Маклаков С. BPwin и Erwin. CASE-средства для разработки
информационных систем / С. Маклаков. – Москва : МИФИ, 2000. – 256 с.
[9] Диаграмма вариантов использования [Электронный ресурс]. –
Электронные данные. – Режим доступа : http://www.business-process.ru. Дата
доступа: 23.04.2018
[10] Черемных С.В. Моделирование и анализ систем. IDEF-технологии /
С.В. Чремных. – Москва : Финансы и статистика, 2006. – 188 с.
[11] Аксенов К.А., Клебанов Б.И. Работа с CASE-средствами BPwin,
Erwin. / К.А. Аксенов, Б.И. Клебанов – Екатеринбург : ГОУ, 2004. – 50 с.
[12] Многослойная архитектура [Электронный ресурс]. – Электронные
данные. – Режим доступа : http://softwaredesignart.net. Дата доступа: 27.04.2018
[13] Java | Введение [Электронный ресурс]. – Электронные данные. –
Режим доступа : http://metanit.com/java/1.php. Дата доступа: 27.04.2018
[14] PostgreSQL[Электронный ресурс]. – Электронные данные. – Режим
доступа : . Дата доступа: 29.04.2018
[15] Савин, Р. Тестирование Дот Ком / Р. Савин. – Минск : Дело, 2007.
– 312 с.
[16] Технико-экономическое обоснование дипломных проектов:
Методическое пособие для студентов всех специальностей БГУИР. В 4-ч. Ч.
4: Проекты программного обеспечения / В. А. Палицын. – Минск : БГУИР,
2006 г. – 76 с
84
ПРИЛОЖЕНИЕ А
(обязательное)
Исходный код
package ipps.slr.controllers;
import com.google.gson.Gson;
import ipps.slr.helper.AjaxResponse;
import ipps.slr.model.Licenseactivity;
import ipps.slr.repository.LicenseActivityRepository;
import ipps.slr.repository.LicenseRepository;
import lombok.Data;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.*;
import javax.persistence.EntityManager;
import javax.servlet.http.HttpServletResponse;
import java.math.BigInteger;
import java.util.ArrayList;
import java.util.Calendar;
import java.util.Date;
import java.util.List;
/**
* Created by Gramovich_V on 19.03.2018.
*/
@Controller
@RequestMapping({"/License", "/license"})
public class LicenseController {
protected final Logger log =

LogManager.getLogger(Class.class);
private final Gson g;

private final EntityManager entityManager;
private LicenseRepository licenseRepository;
private LicenseActivityRepository licenseActivityRepository;
public LicenseController(Gson g, EntityManager

entityManager, LicenseRepository licenseRepository,
LicenseActivityRepository licenseActivityRepository) {
this.g = g;
this.entityManager = entityManager;
this.licenseRepository = licenseRepository;
this.licenseActivityRepository =
licenseActivityRepository;
}
85
@RequestMapping(value = {"", "/", "/Index"}, method =
RequestMethod.GET)
public String index() {
return "license/AllLicense";
}
@RequestMapping(value = "/getLicense", method =

RequestMethod.GET)
public @ResponseBody
AjaxResponse getLicenses(@RequestParam("page") String page)
{
try {
/**
* Берём данные лицензий по номеру текущей страницы
**/
String hql = "SELECT * FROM
sisslr_test.get_license_list( ?1 );";
ArrayList<License> licenses =
ParseLicense(entityManager.createNativeQuery(hql).setParameter(1
, Integer.parseInt(page) - 1).getResultList());
hql = "SELECT * FROM sisslr_test.get_service_list(
?1 , ?2 );";
List<Object[]> serviceList =
entityManager.createNativeQuery(hql).setParameter(1,
Integer.parseInt(licenses.get(0).getId()))
.setParameter(2,
Integer.parseInt(licenses.get(licenses.size() -
1).getId())).getResultList();
List services = parseServices(serviceList);
licenses = ParseLicense(licenses, services);
return new AjaxResponse(licenses);
} catch (Exception e) {
log.error(e.getMessage());
return new AjaxResponse(e);
}
}
@RequestMapping(value = "/getPageCount", method =

RequestMethod.GET)
public void getPage(HttpServletResponse response) {
response.setCharacterEncoding("UTF-8");
try {
String hql = "SELECT count(*) FROM

sisslr_test.license WHERE sisslr_test.license.dateend > now()";
List licensesCount =
entityManager.createNativeQuery(hql).getResultList();
86
response.getWriter().write(g.toJson(licensesCount.get(0)));
log.error(e.getMessage());
}
private ArrayList<License> ParseLicense(ArrayList<License>

License, List Services) {
for (int i = 0; i < Services.size(); i++) {
License.get(i).setServices(Services.get(i).toString().substring(
0, 1).toUpperCase() + Services.get(i).toString().substring(1));
}
return License;
}
private ArrayList<License> ParseLicense(List<Object[]> list)

{
ArrayList<License> licenses = new ArrayList<>();
for (Object[] aList : list) {
licenses.add(new License(
aList[0].toString(),
aList[5].toString()));
}
return licenses;
}
private List parseServices(List<Object[]> serviceList) {

List<List<Object[]>> resList = new ArrayList<>();
Integer index =
Integer.parseInt(serviceList.get(0)[0].toString());
resList.add(new ArrayList<>());
int i = 0;
for (Object[] service : serviceList) {
if ((Integer.parseInt(service[0].toString())) ==
index) {
resList.get(i).add(service);
} else {
i++;
resList.add(new ArrayList<>());
//
System.out.println(service[0].toString());
resList.get(i).add(service);
index = Integer.parseInt(service[0].toString());
}
}
87
List<List<StringBuilder>> stringList = new
ArrayList<>();
List<StringBuilder> resultList = new ArrayList<>();
i = 0;
for (List<Object[]> tempList : resList) {
stringList.add(new ArrayList<>());
stringList.get(i).add(new StringBuilder());
index = 0;
stringList.get(i).get(index).append(tempList.get(0)[1].toString(
)).append(" (").append(tempList.get(0)[2].toString()).append("
").append(tempList.get(0)[3].toString()).append(", ");
for (int y = 1; y < tempList.size(); y++) {
if
(tempList.get(y)[1].toString().equals(tempList.get(y -
1)[1].toString())) {
stringList.get(i).get(index).append(tempList.get(y)[2].toString(
)).append(" ").append(tempList.get(y)[3].toString()).append(",
");
} else {
stringList.get(i).get(index).setLength(stringList.get(i).get(ind
ex).length() - 2);
stringList.get(i).get(index).append("), ");
stringList.get(i).add(new StringBuilder());
index++;
stringList.get(i).get(index).append(tempList.get(y)[1].toString(
)).append(" (").append(tempList.get(y)[2].toString()).append("
").append(tempList.get(y)[3].toString()).append(", ");
}
}
stringList.get(i).get(index).setLength(stringList.get(i).get(ind
ex).length() - 2);
stringList.get(i).get(index).append(")");
resultList.add(new StringBuilder());
for (StringBuilder str : stringList.get(i)) {
resultList.get(i).append(str);
}
i++;
}
return resultList;
}
@RequestMapping(value = {"/search", "/Search"}, method =

RequestMethod.POST)
@ResponseBody
private AjaxResponse Search(@RequestBody String
jsonSearchCriterion) {
try {
88
SearchCriterion searchCriterion =
g.fromJson(jsonSearchCriterion, SearchCriterion.class);
StringBuilder sql = new StringBuilder("select * from
sisslr_test.get_license_list() where ");
if (!searchCriterion.getName().equals("")) {
sql.append("ulanidename ilike
'%").append(searchCriterion.Name).append("%' ");
}
if (!searchCriterion.getUNP().equals("")) {
if (!searchCriterion.getName().equals("")) {
sql.append("and ");
}
sql.append("unp =
").append(searchCriterion.getUNP()).append(" ");
}
if
(!searchCriterion.getElectronicNumber().equals("")) {
if ((!searchCriterion.getName().equals("")) ||
(!searchCriterion.getUNP().equals(""))) {
sql.append("and ");
}
sql.append("electronicnumber ilike
'%").append(searchCriterion.getElectronicNumber()).append("%'
");
}
if (!searchCriterion.getActivity().equals("")) {
if ((!searchCriterion.getName().equals("")) ||
(!searchCriterion.getUNP().equals("")) ||
(!searchCriterion.getElectronicNumber().equals(""))) {
sql.append("and ");
}
sql.append("activity_id =
").append(searchCriterion.getActivity());
}
entityManager.createNativeQuery("set search_path =
\"sisslr_test\";");
List<Object[]> licenseList =
entityManager.createNativeQuery(sql.toString()).getResultList();
return new AjaxResponse(licenseList);
}
}
@Data
private class SearchCriterion {
private String Name;
private String UNP;
// private String City;
89
private String ElectronicNumber;
private String Activity;
}
@Data
private class License {
public String Id;

public String Numberform;
public String Desiction;
public String ActivityName;
public String UlandieName;
public String UNP;
public String Services;
public License(String id, String numberform, String

desiction, String activityName, String ulandieName, String UNP)
{
Id = id;
Numberform = numberform;
Desiction = desiction;
ActivityName = activityName;
UlandieName = ulandieName;
this.UNP = UNP;
package ipps.slr.controllers;
import com.google.gson.Gson;
import ipps.slr.helper.AjaxResponse;
import ipps.slr.helper.DropDown;
import ipps.slr.helper.DropdownValues;
import ipps.slr.model.AppUser;
import ipps.slr.model.License;
import ipps.slr.model.Licenseactivity;
import ipps.slr.model.Ulandie;
import ipps.slr.repository.LicenseActivityRepository;
import ipps.slr.repository.LicenseRepository;
import ipps.slr.repository.UlandieRepository;
import ipps.slr.repository.UserRepository;
import lombok.Data;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.ResponseBody;
90
import javax.persistence.EntityManager;
import java.math.BigInteger;
import java.security.Principal;
import java.sql.Timestamp;
import java.util.ArrayList;
import java.util.Calendar;
import java.util.List;
@Controller
@RequestMapping({"/LicenseInput", "/licenseInput"})
public class LicenseInputController {
public LicenseInputController(LicenseActivityRepository
licenseActivityRepository,
UlandieRepository
ulandieRepository, LicenseRepository licenseRepository,
UserRepository userRepository,
Gson g, EntityManager entityManager) {
this.licenseActivityRepository =
licenseActivityRepository;
this.ulandieRepository = ulandieRepository;
this.licenseRepository = licenseRepository;
this.userRepository = userRepository;
this.g = g;
this.entityManager = entityManager;
}
private LicenseActivityRepository licenseActivityRepository;

private UlandieRepository ulandieRepository;
private LicenseRepository licenseRepository;
private UserRepository userRepository;
private final EntityManager entityManager;
private Gson g;
@RequestMapping(value = {"", "/", "/Index"}, method =

RequestMethod.GET)
public String index() {
return "licenseInput/index";
}
@RequestMapping(value = {"getActivities"}, method =

RequestMethod.GET)
DropDown getActivities() {
List<Licenseactivity> licenseactivityList =
licenseActivityRepository.findAll();
List<DropdownValues> dropdownValuesList = new
ArrayList<>();
for (Licenseactivity licenseActivity :
licenseactivityList) {
dropdownValuesList.add(new
DropdownValues((int)licenseActivity.getId(),
91
licenseActivity.getName()));
}
return new DropDown(dropdownValuesList);
}
@RequestMapping(value = {"/saveLicense", "/SaveLicense"},

method = RequestMethod.POST)
AjaxResponse saveLicense(@RequestBody String jsonLicense,
Principal principal) {
try {
FormLicense formLicense = g.fromJson(jsonLicense,

FormLicense.class);
Ulandie ulandie =
ulandieRepository.findByUnp(formLicense.UNP);
if (ulandie == null) {
return new AjaxResponse(new
Exception("Лицензиата с таким УНП не существует."));
}
String[] startYear=
formLicense.getDateStart().split(" ");
List LastLicenseNumber =
entityManager.createNativeQuery("select * from
sisslr_test.getLicenseCountByUNP(?1,?2)")
.setParameter(1,
formLicense.getUNP()).setParameter(2,
Integer.parseInt(startYear[2])).getResultList();
Licenseactivity licenseactivity =
licenseActivityRepository.findById(formLicense.getActivity());
String name = principal.getName();
AppUser appUser =
userRepository.findByUserName(name);
String electronicNumber =
createElectronicNumberFotLicense(licenseactivity.getCodeactivity
(), formLicense.getUNP(),startYear[2],
(BigInteger)(LastLicenseNumber.get(0)));
String dateEnd;
if(formLicense.getDateEnd().equals("")){
dateEnd="Январь 1, 2100";
}else {
dateEnd= formLicense.getDateEnd();
}
License license = new License();
license.setOwnerid(appUser.getUserId());
license.setAdvancedrequests(formLicense.getAdvancedRequest());
license.setNumberdesicion(formLicense.getDecisionNumber());
license.setNumberform(formLicense.getNumberForm());
license.setUnpegr(formLicense.getUNP());
92
license.setRegisternumber(Integer.parseInt(formLicense.getRegist
erNumber()));
license.setComment(formLicense.getComments());
license.setElectronicnumber(electronicNumber);
license.setDatestart(parseDate(formLicense.getDateStart()));
license.setDateend(parseDate(dateEnd));
license.setDatedecision(parseDate(formLicense.getDateDecision())
);
license.setLicenseactivityByLicenseactivityId(licenseactivity);
license.setUlandieByUlandiEId(ulandie);
licenseRepository.save(license);
return new AjaxResponse();
}
}
private Timestamp parseDate(String parseDate){

String[] Date= parseDate.split(" ");
String month=Date[0];
String day=Date[1];
String year=Date[2];
day= day.substring(0,day.length()-1);
int monthNumber=0;
switch (month){
case "Январь":{
monthNumber=1;
break;
}
case "Февраль":{
monthNumber=2;
break;
}
case "Март":{
monthNumber=3;
break;
}
case "Апрель":{
monthNumber=4;
break;
}
case "Май":{
monthNumber=5;
break;
}
case "Июнь":{
monthNumber=6;
93
break;
}
case "Июль":{
monthNumber=7;
break;
}
case "Август":{
monthNumber=8;
break;
}
case "Сентябрь":{
monthNumber=9;
break;
}
case "Октябрь":{
monthNumber=10;
break;
}
case "Ноябрь":{
monthNumber=11;
break;
}
case "Декабрь":{
monthNumber=12;
break;
}
}
Calendar calendar= Calendar.getInstance();
calendar.set(Calendar.YEAR,Integer.parseInt(year));
calendar.set(Calendar.MONTH,monthNumber-1);
calendar.set(Calendar.DAY_OF_MONTH,Integer.parseInt(day));
calendar.set(Calendar.HOUR, 0);
calendar.set(Calendar.MINUTE, 0);
calendar.set(Calendar.SECOND, 0);
calendar.set(Calendar.MILLISECOND,0);
calendar.set(Calendar.HOUR_OF_DAY, 0);
return new Timestamp(calendar.getTime().getTime());
}
private String createElectronicNumberFotLicense(Long

Activity, Long UNP, String year, BigInteger lastId) {
year=year.substring(2,year.length());
return
parseNumber(Activity)+Long.toString(UNP)+year+parseNumber(lastId
.longValue());
}
private String parseNumber(Long number){

if (number<10){
return "00"+Long.toString(number);
}
94
else {
if(number<100){
return "0"+Long.toString(number);
}
else
return Long.toString(number);
}
}
@Data
private class License {
public String Id;

public String Numberform;
public String Desiction;
public String ActivityName;
public String UlandieName;
public String UNP;
public String Services;
public License(String id, String numberform, String

desiction, String activityName, String ulandieName, String UNP)
{
Id = id;
Numberform = numberform;
Desiction = desiction;
ActivityName = activityName;
UlandieName = ulandieName;
this.UNP = UNP;
95

ПЗ Влад

Загружено:

Сведения о документе

Описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Описание:

Авторское право:

Доступные форматы

ПЗ Влад

Загружено:

Описание:

Авторское право:

Доступные форматы

Министерство образования Республики Беларусь

Факультет компьютерных систем и сетей

ПРОГРАММНОЕ СРЕДСТВО «ЕДИНЫЙ РЕЕСТР ЛИЦЕНЗИЙ»

БГУИР ДП 1-40 01 01 01 031 ПЗ

ПРОГРАММНОЕ СРЕДСТВО «ЕДИНЫЙ РЕЕСТР ЛИЦЕНЗИЙ» С

Цель работы – разработка программного средства «единый реестр

Грамовича Владислава Александровича

1. Тема проекта: Программное средство «Единый реестр лицензий» с использова-

утверждена приказом по университету от « 30 » марта 2018 г. № 549-c

3. Исходные данные к проекту Тип приложения: веб-приложение

6. Содержание задания по технико–экономическому обоснованию

Задание выдал / К. Р. Литвинович /

Дата выдачи задания 23 марта 2018 г. Руководитель / И.М. Марина /

Задание принял к исполнению / В. А. Грамович /

В настоящей пояснительной записке применяются следующие опреде-

Информационные технологии все больше затрагивают сферы

1.1 Анализ предметной области

Государственные информационные системы – системы, созданные на

Рисунок 1.1 – Диаграмма ГИС

1.2 Общая информация о государственных информационных

Использование государственных информационных систем

1.3 Обзор существующих аналогов

1.3.1 Информационная система Эстонии

Рисунок 1.2 – Эстонский государственный портал

Данная система представляет собой веб-сайт, через который возможно

Рисунок 1.3 − Форма входа на сайт «eesti.ee»

К достоинствам Эстонского государственного портала можно отнести:

1.3.2 Информационная система электронного лицензирования

Рисунок 1.4 − Программное средство «ИСЭЛ»

Сервисы, доступные зарегистрированному пользователю:

1.3.3 Веб-портал Единого государственного регистра юридических лиц

Рисунок 1.5 − Веб-портал Единого государственного регистра юридических

Авторизованный пользователь – владелец личного ключа электронной

1.3.4 Единый портал электронных услуг ОАИС

Рисунок 1.6 – Единый портал электронных услуг ОАИС

Сегодня в ОАИС интегрированы следующие ГИР:

1.4 Цель и задачи дипломного проекта

1.4.1 Назначение разработки

1.4.2 Состав выполняемых функций

1.4.4 Требования к составу и параметрам технических и

1.4.5 Требования к безопасности

2.1 Описание функциональности программного средства

Для описания функциональности программного средства была выбрана

2.1.1 Диаграмма вариантов использования

Рисунок 2.1 – Диаграмма вариантов использования

2.1.2 Инфологическая модель базы данных

Рисунок 2.2 – Инфологическая модель базы данных

2.2 Спецификация функциональных требований

Для описания требуемых характеристик программного средства была

2.2.1 Требования к пользовательскому интерфейсу

2.2.2 Требования к интерфейсу администратора

2.2.3 Роли пользователей

3.1 Проектирование взаимодействия модулей ПС

Взаимодействие модулей программного средства можно представить в

Рисунок 3.1 – Контекстная диаграмма

Также на рисунке 3.2 представлена декомпозиция контекстной

Рисунок 3.2 – Декомпозиция модулей взаимодействия

3.2 Обоснование выбора СУБД

Выбор СУБД напрямую связан с анализом и выбором аппаратных

3.3 Проектирование модели базы данных

Даталогическая модель [10] – модель предметной области в привязке к