Требования к системе

Дата: 2025-05-25; Просмотры: 6

Оценка:

0.00 из 5.00 — оценок

Скачиваний: 0

Скачать

К разрабатываемой системе представляются следующие требования:

ИС должна представлять собой клиент-серверное приложение.

1) Клиентская часть

Используемая технология: библиотека React;

Используемый язык: TypeScript;

Требуется выводить список сертификатов с постраничным разбиением;

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

Требуется функционал для добавления / редактирования сертификатов;

Требуется функционал для предоставления печатной формы сертификата (файл в формате pdf);

2) Серверная часть

Используемая технология: Spring Boot;

Обработка всех видов запросов, необходимых для работы клиентского приложения;

Разработка интерфейса взаимодействия с базой данных.

Сертификаты должны соответствовать стандарту E-cert BRS[1].

Печатная форма сертификата должна соответствовать формату (рис 4) (Приложение В).

Рисунок 4 - Печатная форма сертификата

3.1 Клиентская часть

Для начала необходимо определить концептуальную модель работы подсистемы сбора, передачи и визуализации данных мониторинга ИТ-инфраструктуры и ИС Россельхознадзора. Она представлена на рисунке 2.1.

Рисунок 2.1 – Концептуальная модель системы мониторинга

3.2.1 Анализ используемых технологий

Клиентская сторона должна быть реализована при помощи библиотеки React [2]. Это библиотека, используемая для создания одностраничных web-приложений.

Задачей данной библиотеки является эффективная перерисовка компонентов DOM браузера. Хотя React и является библиотекой, её использование требует специфической организации и работы с файлами и их содержимым. По мере усложнения приложения можно избежать управления состоянием в каждом из компонентов (или одного основного / родительского компонента) и вместо этого управлять им с помощью Redux рис 2.2.

Рисунок 2.2. Управление с помощью Redux.

Эта библиотека позволяет разрабатывать удобные для тестирования компоненты, имеет большую поддержку сообщества разработчиков и алгоритмы решения для практически всех возникающих задач, огромный набор библиотек компонентов для создания пользовательского интерфейса.

Одним из требований является использование языка Typescript. Обусловлено это тем, что изначально React работает с JavaScript. Однако, данный язык не типизирован и могут возникнуть ошибки использования не существующих полей, с чем и борется Type Script.

Однако в ходе разработки было выяснено, что при использовании React возникают операции, на которые проверка типов не применяется. Для простых же типов в React существуют способы предварительной проверки (на этапе сборки).

Так же использование Type Script ограничивает использование сторонних библиотек, которыми являются практически все используемые в проектах, основанных на React. Данная проблема обусловлена тем, что React заточен под JavaScript, как и все библиотеки, работающие с ним. Для использования библиотеки, не поддерживающий TypeScript требуется написать отдельный файл экспорта для данного языка. Разумеется, написать подобный файл может и сторонний разработчик, однако разбираться в исходном коде библиотеки это очень плохая идея, при условии, что при изменении версии библиотеки она может полностью измениться, например, библиотеки для роутинга. Как итог, разработчик может использовать лишь библиотеки, изначально поддерживающие TypeScript.

TypeScript — язык программирования, представленный Microsoft в 2012 году и позиционируемый как средство разработки веб-приложений, расширяющее возможности JavaScrip

Из этого можно сделать вывод, что использование языка TypeScript является негативным.

3.2.2 Анализ страниц сайта

На клиентской стороне достаточно показать 2 страницы:

1) Основная страница.

На данной странице располагается список сертификатов.

На ней должны быть следующие элементы:

¾ Таблица, в которой выведены сертификаты. Вывод сертификатов должен быть постраничным. В таблице должен быть указан номер сертификата, продукт, на который распространяется сертификат. По этим полям должна быть возможность установки сортировки и фильтрации.

¾ Элемент поиска сертификата по его коду.

¾ Кнопка добавления сертификата

2) Страница редактирования сертификата.

Требуются поля для редактирования всех данных сертификата. Для данных подразумевающих выбор из списка доступных ввести требуется ввести выпадающий список.

Должны присутствовать кнопки сохранения сертификата и открытие печатной формы.

Данная страница также должна выполнять функцию добавления начальных данных сертификата, то есть при открытии данной страницы на добавление, она открывается с пустыми значениями и после сохранения данная страница остаётся при изменении сгенерированных значений.

3.2 Анализ стандарта E-cert BRS

Стандарт E-cert BRS [1] предоставляет множества данных относительно сертификатов (рис 2 ).

Рисунок .2.3. Стандарт E-cert BRS

Первая часть стандарта рассматривает правил работы с сертификатом для пользователей: иностранное агентство выдавшее сертификат подаёт заявку на предоставление аналогичного сертификата в нашей стране клиенту. В нашей стране уполномоченные органы, подчиненные Россельхознадзору, проводят проверку и, в случае отсутствия проблем предоставляют российский сертификат. Владелец товара, получив известие об одобрении сертификата, способен получить данный сертификат в органах Россельхознадзора.

Для сертификата предоставляются состояния, представленные на рисунке 2.4.

Рисунок 2.4 – Диаграмма состояний сертификатов

Вторая часть стандарта рассматривает типовой состав данных сертификата.

Вот данные необходимые в сертификатах для нашей системы.

¾ Номер сертификата

¾ Статус сертификата

¾ Компания импортер

¾ Страна импортер

¾ Компания экспортер

¾ Страна экспортер

¾ Транзитные страны (должна быть возможность выбора нескольких стран)

¾ Страна ЕС, выдавшая сертификат

¾ Ведомство ЕС, выдавшее сертификат

¾ Компетентное ведомство ЕС

¾ Цель экспорта

¾ Транспорт

¾ Продукт

¾ Тип продукта

3.3 Серверная часть

3.3.1 Анализ используемых технологий

Согласно заданию используемой технологией является Spring Boot. Данный фреймворк, поддерживаемый сообществом и официальными разработчиками, обеспечивает несколько функций: масштабируемость, инъекцию зависимостей.

Масштабируемость является крайне важной функцией: производительность ИС практически полностью лежит на сервере. Система использует следующий стек технологий: какая-либо база данных->Spring Boot-> React Api:

При правленой настройке практически любая база данных очень производительна. Разумеется, при возникновении большого количества распределённых транзакций возникнут ещё и ограничения со стороны базы данных, однако при правильной настройке данные действия будут весьма производительны.

React Api, в силу своей деятельности, практически не требует ресурсов: дерево графических элементов изменяется не более одного раза за запрос, все вычисления идут в фоновом режиме.

В качестве канала связи используется интернет. Использование формата Json при работе системы снизит нынешнюю нагрузку. Да и качество интернета на территории РФ, можно считать хорошим.

Как следствие производительность системы зависит от производительности сервера практически на прямую.

3.3.2 Обработка запросов

В ходе анализа стандарта были выделены данные, необходимые для сертификата. Функция сервера – предоставление этих данных по требованию клиентского приложения.

Наиболее распространенный формат работы сервера это формат RestFull. Данный формат определяет формат запросов в систему, ожидаемый результат, формат ответа.

Полное использование формата RestFull невозможно:

¾ Во-первых, до сих пор не определены некоторые принципы касательно данного формата: использование кодов ответов, множественное или единственное число в запросах;

¾ Во-вторых, некоторые вещи по-разному поддерживаются различными браузерами. Реальный пример: в браузере Safari существовала проблема, что при получении страницы, код ответа которой означал “пользователь не зарегистрирован ”, то пользователь автоматически перенаправлялся дефолтную для браузера страницу регистрации, не давая обработать запрос.

Исходя из вышесказанного:

Будет использоваться единственное число при определении URL ресурса.

Параметры для запроса передаются через Url в виде “?key=value”

Если параметр определяет функционал, то он передаётся в формате “/value”. Например “http://data.foo” вернёт список данных, тогда как “http://data.foo/1” должен вернуть не список, но единственный элемент.

Обрабатываемые запросы

¾ Получение списка данных: GET запрос. Ответ: список всех данных по данному объекту в формате Json [3].

¾ Получение списка данных с постраничным разбиением: GET запрос с параметрами номера страницы и количеством элементов на странице. Ответ: список данных согласно полученным параметрам в формате Json.

¾ Получение объекта по идентификатору: GET запрос с параметром идентификатора. Ответ: найденный объект в формате Json

¾ Обновление данных: POST запрос. Идентификатор объекта передается в самом объекте, а не через URL. Получает в качестве тела запроса новые значение для объекта в формате Json. Ответ: результат пересохранения объекта; в случае удачного сохранения вернуть объект после сохранения.

¾ Добавление данных: PUT запрос. Получает в качестве тела запроса объект в формате Json. Ответ: результат добавления объекта. В случае удачного сохранения вернуть объект после сохранения

¾ Удаление данных: DELETE запрос. Получает в качестве тела запроса идентификатор удаляемого объекта. Ответ: результат удаления. Формально, удалять данные нигде не нужно, но для полноты функционала добавить метод нужно.

В качестве идентификатора объекта выступает значение “id”.

Конечные точки для обработки:

1) Сертификат;

2) Состояние сертификата;

3) Продукция;

4) Продукт;

5) Тип продукта;

6) Страна;

7) Регион.

Все вышеуказанные конечные точки обработки должны реализовывать функционал для всех видов запросов.

Для сертификатов требуется обработка дополнительных запросов:

¾ Поиск сертификата коду: GET запрос. В качестве параметра поступает значение номера сертификата. Ответ сертификата в формате Json с параметром id найденного сертификата. В случае если сертификат, с таким кодом не был найден, то значение параметра должно быть 0;

¾ Печатная форма сертификата (следует из пункта 2.4): GET запрос. В качестве параметра выступает идентификатор сертификата. В качестве ответа должен быть предоставлен PDF документ, с заполненными полями в соответствии с параметрами сертификата, идентификатор которого был послан.

3.4 База данных

Так как база данных не указана, то в качестве БД будет использована mock система- “Json-server” [4].

Причиной отсутствия задач для работы с базой данных является то, что оригинал системы является закрытым. В оригинальной системе уже существует способ доступа к базе данных. Однако, доступ к рабочей базе недопустим:

Система находится в рабочем состоянии и, логично, её нельзя использовать для тестирования.

В целях безопасности: нельзя открывать даже версию базы данных так как это способно нанести урон безопасности.

Так как информационная система Россельхознадзора поддерживается государственными разработчиками, а сама система существует довольно давно, то взаимодействие с базой данных уже написано.

3.5 . Генерация печатной формы сертификата

Одна из задач системы – генерировать печатную форму сертификата. Заниматься этим можно как на клиентской стороне, так и на стороне сервера.

В случае реализации на клиентской стороне:

1) Будет повышенная нагрузка на клиентскую часть, а компьютеры, на которых выполняется программа, вероятно, обладают низкой производительностью. Помимо этого, на клиентскую часть придётся передавать дополнительную библиотеку для генерации файлов Pdf, да одна библиотека это не много, но ведь в идеале и её бы передавать не хотелось. Логично, что дополнительная нагрузка была бы лишней;

2) Единственной официальной библиотекой занимающейся генерацией PDF документов для React приложений является библиотека PDF.js [5] однако официального перевода для TypeScript нет [6] (существуют несколько реализаций, но без документации, и от сомнительных разработчиков).

В случае реализации на стороне сервера:

1) Нагрузка на сервер увеличится не сильно: у сервера появится дополнительная конечная точка для обработки запросов, что для сервера практически не заметно. Для обработки этого запроса потребуется производить выборку данных из базы данных, чем опять же сервер будет заниматься в любом из двух случаев. Сгенерировать ответ: опять-же для сервера незаметная нагрузка. Во время генерации ответа применить дополнительную библиотеку, которая будет всегда находится на сервере;

2) Для сервера, который используется (Spring Boot), существует официальная библиотека IText [7]. Она оттестирована, содержит полную документацию;

3) Невозможно получить печатную форму сертификата, если он не сохранен на сервере. Так как сервер извлекает данные из базы данных а не из запроса, то нет никакой возможности распечатать не существующий сертификат. Это, помимо прочего, повышает безопасность системы.

В результате анализа печатная форма сертификата будет генерироваться на стороне сервера.

Вот аналог того, как должна выглядеть печатная форма: http://fsvps.ru/fsvps-docs/ru/importExport/crt/es/41.pdf (приложение В).

3.6 . Управление пользователями

Заказчик не требует систему управления пользователями. Данное условие является следствием закрытости системы: Россельхознадзор – это государственная организация. Данной системы и не будет.

Собственно, для проектирования весьма скудные возможности – практически все исходные данные приходят от заказчика. Данная система будет клиент-серверным приложением.

3.7 .Классы

В ходе анализа стандарта и требуемой формы сертификата сформирована структура классов, представленная на рисунке 2.5. Данную модель придётся реализовать как на стороне сервера, так и на стороне клиента.

Рисунок 2.5. – Диаграмма классов

3.8 . Прецеденты.

По результатам анализа были сформированы прециденты, представленные на рисунке 3.1.

Рисунок 3.1 – Диаграмма прецедентов

Описание прецедентов:

1) Просмотр списка сертификатов.

Действующее лицо: Пользователь.

Основной поток: пользователь заходи на основную страницу сайта и просматривает список сертификатов.

2) Просмотр сертификата.

Действующее лицо: Пользователь.

Основной поток: во время просмотра сертификатов пользователь нажимает на кнопку просмотра.

Если пользователь знает номер сертификата, то может ввести его и перейти на страницу сертификта.

Постусловие: Пользователь переходит на страницу просмотра конкретного сертификата.

3) Редактирование сертификата.

Действующее лицо: Пользователь.

Основной поток: во время просмотра сертификата пользователь может редактировать поля сертификата.

После окончания редактирования пользователь сохраняет изменения.

Альтернативный поток: если данные небыли сохранены, то изменения будут утеряны.

Постусловие: Пользователь переходит на страницу просмотра конкретного сертификата.

4) Получение печатной формы сертификата.

Действующее лицо: Пользователь.

Основной поток: во время просмотра сертификата пользователь нажать на кнопку получения печатной формы сертификата.

Постусловие: Пользователю откроется новая страница, на которой будет представлена печатная форма данного сертификата.

3.9 .Развертка системы

Так как базы данных нет, то вовремя разработки вместо неё будет использоваться “json-server”.

Для получения данных используются компоненты DAO. Эти компоненты используют универсальный интерфейс для того, чтобы при смене базы данных приложение этого практически не заметило. К таму-же данный паттерн используется по умолчанию во всех приложения Spring Boot при работе с базами данных.

Данные, полученные из DAO, обрабатываются контроллером и, как следствие произошло отделение контроллеров от используемой базы данных.

Большинство DAO не связано вместе, однако Certificate DAO связано со всеми остальными DAO. Это обусловлено тем, что при извлечении данных в чистом виде на месте объектов будут находиться лишь номера объектов, а не сам объекты. Данная особенность применима для NoSql баз данных, которой пользуется “json-server”

Диаграмма развертки предствленна рисунке 3.9..

Рисунок3.9. – Диаграмма развертывания

Диаграмма поледоватлености для получинея очередной страницы сертификатов имеет вид, представленный на рисуноке 5.

Рисунок 3.10. – Диаграмма последовательности

4.
ъРЕАЛИЗАЦИЯ

2.1.Клиентская часть

Рисунок 2.1. Архитектура подсистемы сбора, отправки и визуализации данных.

4.1.1 Сборка проекта

Для сборки проекта используется Web-pack [8]. Настроено два способа сборки:

1) Сборка для разработчика. Для этого используется библиотека “webpack-dev-server” [9]. Данная библиотека позволяет развернуть собранный проект на машине разработчика. Это позволяет в режиме реального времени редактировать файлы, которые будут автоматически пересобраны, и проверить работоспособность системы.

2) Сборка для установки на сервер. Изначально в React [1] существует большое количество опций для помощи разработчику, но замедляющие процесс работы системы. В Release версии данный функционал не нужны.

Одним из условий разработки клиентской части является использование TypeScript [10]. Для этого используется библиотека “ts-loader” [11]. Использование данной библиотеки прописано в webpack.config.js, раздел module/loaders. Помимо этого, был добавлен файл tsconfig.json, который устанавливает некоторые опции для работы ts-loader, например, не включать комментарии в конечный файл сборки рис

Любое веб приложение использует стили (файлы css). Изначально Webpack не умеет этого делать. Для того, чтобы прогрузить стили используются библиотеки “style-loader”, “css-loader” [12]. Библиотека Css-loader позволяет webpack прочитать файл стилей. Библиотека Style-loader нужен для того, чтобы применить данный стиль в на странице. Файл css это не JavaScript код который нужно просто прочитать и выполнить, его нужно передать браузеру в приемлемом формате и месте, так же применить к нужному компоненту, так как на странице может быть множество компонентов и их стили могут перекрывать друга

.

4.1.2 Организация системы

В процессе реализации React приложения требовалось решить 2 важных задачи:

1) Хранение данных на стороне клиента: библиотека React предоставляет функционал для эффективного изменения страниц приложения, однако никак не освещает вопрос хранения данных.

Данная задача решается при помощи паттерна Flex и его рализации Redux. Библиотекой, занимающейся реализацией паттерна является “react-redux” [13]. Данная библиотека обеспечивает корректное хранение и изменение информации, а также изменение страницы для корректного отображения имеющихся данных.

Для понимания принципа redux привожу диаграмму с сайта quira.com – рисунок 6.

Рисунок 6 – Диаграмма работы паттерна Redux.

2) Роутинг системы: задача корректного отображения страниц в зависимости от URL: так как это одностраничное приложение, то при смене URL отправки данных на сервер, для получения новых страниц не происходит. Однако изменить страницу все-же нужно.

Решается данная проблема библиотеками роутинга.

Существуют две широко распространенных библиотеки: “react-router” и “react-router-redux”.

Эти библиотеки очень похожи, отличие лишь в том, что “react-router” не способна работать вместе с “react-redux”. Это обусловлено тем, что при использовании “react-redux” все данные хранятся в store. Разумеется, “react-router” ничего о ней не знает и передать сообщение об изменении URL не может. Данная библиотека используется для случаев, собственной реализации патерна Flex.

С другой стороны, библиотека “react-router-redux” изначально задумывалась для работы в паре с “react-redux”, что выражается даже в названии. Библиотека “react-router-redux” обеспечивает корректное отображение элементов в зависимости от URL, а так же способна извлекать данные из URL для корректной работы “react-redux”.

4.1.3 Дизайн

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

4.1.4 Реализация страниц

1) Главная страница

Вид страницы полученный поле рализации представлен на рисунке 7.

Рисунок 7 – Вид главной страницы

Для реализации таблицы был выбрана библиотека “react-data-grid” [14].

На момент создания существует проблема версий данной библиотеки: последняя официальная версия пакета “react-data-grid-addons”, требуемая для функционала не работает с последней версией самой библиотеки “react-data-grid”. Для решения данной проблемы используется версия пакета "^3.0.11-next3891"-это версия ещё не прошла полное тестирования и некоторые функции в ней ещё не отмечены как стабильные, однако требуемый функционал уже выполняется. К тому же данное решение предлагают сами разработчики библиотеки, до тех пор, пока версия пакета не будет окончательно доработана.

Библиотека “react-data-grid” [14] обладает небольшой особенностью: таблица не может выводить на экран поля вложенных объектов, что в данном проекте необходимо. Для решения данного затруднения был использован следующий алгоритм: элементы таблицы предварительно переводятся в дополнительный список, в котором нет вложенных объектов (все вложенные поля переводятся в обычные поля объекта), таблица же получает на вход этот дополнительный список.

Для добавления в таблицу кнопки “Подробно” использовалась одна из функций библиотеки, называемая “custom formatter”. Это функция, которая позволяет переопределить стандартную отрисовку компонента, позволяя отрисовать в ячейках таблицы практически любые данные. Созданный компонент, для отрисовки кнопки называется “ButtonFormatter”. Он получает на вход данные об идентификаторе таблицы и метод перехода на другую страницу при помощи функции GetRowMetadata. Это важно объяснить здесь потому-что официальная документация довольно плохо рассказывает о данном пункте.

Помимо таблицы на данной странице есть ещё два компонента:

a) Компонент перелистывания страниц

В данном компоненте нет ничего сложного: две кнопки, отвечающие за перелистывание страниц, и элемент выведения нынешней страницы.

b) Компонент открытия сертификата по его номеру

Введя номер сертификата можно перейти страницу данного сертификата, разумеется, при условии существования такого сертификата.

2) Страница редактирования сертификата.

Вид страницы редактирования сертификата представлен на рисунке 8.

Рисунок 8 – Вид страницы редактирования сертификата

В качестве параметров сертификата часто приходится выбирать элементы из списка: страна импортер/экспортер, компания импортер/экспортер, продукт, тип продукта, состояние... Для этого используется библиотека "react-select" [15]. Основная причина для этого: множественный выбор элементов (например, транзитные страны) довольно сложно реализовать при помощи стандартного html. Настроить стили для этого ещё сложнее. Данная библиотека позволяет добиться обоих пунктов автоматически. Остальные компоненты выбора сделаны при помощи этой библиотеки для соответствия стилей.

Остальные задачи реализации для данной системы, такие как сетевое взаимодействие, инициализация данных используют стандартные алгоритмы действий соответственно: библиотека http, множественные асинхронные сетевые вызовы в файле index.tsx.

4.1. Серверная часть

Для обработки запросов используются контроллеры. Так как функционал контроллеров, согласно заданию схож, то большая часть функций выведена в абстрактный класс “AbstractController”. Вот его функции:

1) Запрос на получение данных Get.

Метод: GET.

Параметры, которые может принимать в URL:

¾ Имя: _page; требуется: нет; тип: число; смысл: определяет номер страницы.

¾ Имя: _limit; требуется: нет; тип: число; смысл: определяет количество элементов на одной странице.

Если один из параметров не получен, то должен быть возвращен весь список элементов.

Возвращаемое значение: список запрашиваемых элементов в формате Json.

2) Запрос на получение элемента GetById

Метод: GET.

Параметр, передаваемый в URL:

¾ Имя: отсутствует; требуется: да; тип: число; формат: ”URL_элимента_запрашиваемого_пользователем/идентификатор”; смысл: определяет идентификатор элимента.

Возвращаемое значение: запрашиваемый элемент в формате Json.

3) Запрос на получение количетсва элементов GetCount

Метод: POST.

Параметр, передоваемые в URL:

¾ Имя: отсутствует; требуется: да; тип: строка; формат: ”URL_элиментов/ItemsCount”; смысл: определяет новую конечную точку для обработки согласно формату RestFull.

Возвращаемое значение: строка в формате “{count: количестов_элиментов}”.

4) Запрос на изменение данных Update

Метод: PUT.

Параметр, передаваемый в URL:

¾ Имя: отсутствует; требуется: да; тип: число; формат: ”URL_элимента_запрашиваемого_пользователем/идентификатор”; смысл: определяет идентификатор элимента.

Тело запроса:

Новое значение данных в формате Json.

Возвращаемое значение: результат после изменения. В случае успешного изменения возвращает изменённый объект.

5) Запрос на изменение данных Add

Метод: POST.

Параметр, передоваемые в URL:

¾ Имя: отсутствует; требуется: да; тип: число; формат: ”URL_элимента_запрашиваемого_пользователем/идентификатор”; смысл: определяет идентификатор элимента.

Тело запроса:

Новое значение данных в формате Json.

Возвращаемое значение: результат изменения. В случае успешного изменения возвращает изменённый объект.

6) Запрос на удаление данных Delete

Метод: DELETE.

Параметр, передаваемый через URL:

¾ Имя: отсутствует; требуется: да; тип: число; формат: ”URL_элимента_запрашиваемого_пользователем/идентификатор”; смысл: определяет идентификатор элимента.

Возвращаемое значение: результат удаления данных.

Конкретные контроллеры его расширяют абстрактый контроллер, указывая какой именно URL обрабатывать, к какому классу приводить входные данные и с каким DAO работать.

CertificateController расширяет стандартное поведение:

1) Запрос на получение печатной формы сертфиката Pdf

Метод: GET.

Параметр, передаваемый в URL:

¾ Имя: id; требуется: да; тип: число; смысл: определяет идентификатор запрашиваемого сертификата.

Возвращаемое значение: PDF файл.

2) Запрос на получение сертифика по номеру Get

Метод: GET.

Параметр, передаваемый через URL:

¾ Имя: отсутствует; требуется: да; тип: число; формат: ”URL_элимента_запрашиваемого_пользователем/code”; смысл: определяет новую конечную точку для обработки согласно формату RestFull.

¾ Имя: _code; требуется: да; тип: число; смысл: определяет код запрашиваемого сертификата.

Возвращаемое значение: Номер найденного сертификата.

Для работы с базой данных использовался похожий способ: был создан интерфейс IDAO, но вся реализация была сделана в классах, реализующих интерфейс. Данный способ позволяет не привязываться к какой-то конкретной базе данных.

Генерация PDF.

Полноценного формата для PDF предоставлено не было: все отступы, шрифты, стили сделаны на глазок. Генерация PDF происходи три помощи библиотеки iText [7].

4.3 Mock сервис

В качестве замены базы данных используется библиотека json-server [4]. Она является по сути NoSql базой данных с предустановленным сетевым интерфейсом: автоматически способна принимать и обрабатывать сетевые запросы в формате RestFull.

Для работы с данной системой серверу потребуется внешнее сетевое взаимодействие, организованное при помощи RestTemplate.

1 ИНФОРМАЦИОННЫЙ МЕНЕДЖМЕНТ

5.1 Разработка системы

5.1.1 Схема финансирования

Инвестирование будет совершаться со стороны администрации иститута. Проект может инвестироваться по частям.

Жизненный цикл проекта представлен на рисунке 9.

Рисунок 9 – Жизненный цикл проекта

5.1.2 Работы и их стоимости

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

Таблица 1

Общая стоимость запуска проекта: 330 000

5.1.3 Оценка рисков и мероприятия по их ограничению

При разработке системы могут возникнуть риски. Эти риски и методы их решения представлены в таблице 2.

Таблица 2

5.2 Аналоги

Данная система является специфичной и реализуется, в каком либо виде, в любой стране, однако, данные системы являются закрытыми и, как следствие, доступных аналогов нет.

Единственный пример системы, про существование который доподлинно известно это аналог из Аргенты. На данный момент состояние данной системы неизвестно.

5.3 Текущее состояние проекта

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

У системы есть несколько проблем:

¾ Действующая система разработана с использованием устаревших технологий и не учитывает ныне существующие принципы построения системы.

¾ Система сильно устарела. Система разрабатывалась более 10 лет назад, новый функционал добавлялся в уже готовую систему и, как следствие, возникают ошибки системы.

¾ Система не справляется с существующей нагрузкой. Было выявлено, что обработка данных на стороне клиента плохо справляется со своей задачей – медленно работает.

5.4 Развитие

Собственно цель разработки является создание новой ИС, основанной на использовании новых технологий, и учете жилаемого функционала. Новую систему будет проще тестировать и модернизировать.

5.5 Оценка ожидаемых результатов

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

Используемые в работе разработанной системы документы имеют объем представленный в таблице 3.

Таблица 3

Стоимость до внедрения системы 1 272 000 000 / 30 * 230 = 9 752 000 000 рублей.

Так как происходит не автоматизация системы, а её модернизация, то ожидаемое снижение трудоёмкости составит примерно 10%. Это результирует в коэффициент снижения трудовых затрат равный 90%.

Так как не происходит принципиального изменения работы с системой, то операции останутся теми же но вот ожидаемая производительность работников повысится до 33 операций в час.

Стоимость работ после внедрения системы составит 8 865 454 545 рублей.

Изменения сервера и принципов ведения документации не предвидится.

Показатель снижения стоимостных затрат

DС=9 752 000 000 – 8 865 454 545 = 886 545 455 рубля

Срок окупаемости затрат на внедрение проекта машинной обработки информации:

Ток =330 000 / 886 545 455= 1,71 года

Окупаемость затрат на внедрение проекта составляет около 1 года 10 месяцев.

Из этих вычислений можно сделать вывод, что система окупаема.

ЗАКЛЮЧЕНИЕ

В ходе выполнения выпускной квалификационной работы мною выполнены все поставленные задачи: были созданы клиентская и серверная части информационной системы, произведён анализ сертификата и образована система классов, было произведено экономическое обоснование проекта.

2 СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

1. Официальный сайт UNICEF [Электронный ресурс]: Файл, описывающий рекоминдации к параметрам сертифика: [web-сайт]. URL: https://www.unece.org/fileadmin/DAM/cefact/brs/BRS_ExportCertificate__eCert__v5.1.0.pdf (дата обращения: 13.03.2018)

2. Официальный сайт библиотеки “React” [Электронный ресурс]: [web-сайт]. URL: https://reactjs.org (дата обращения: 13.03.2018)

3. Официальный сайт Json [Электронный ресурс]: [web-сайт]. URL: https://www.json.org (дата обращения: 13.03.2018)

4. Официальный сайт Json-server [Электронный ресурс]: [web-сайт]. URL: https://github.com/typicode/json-server (дата обращения: 13.03.2018)

5. Официальный сайт PDF.js [Электронный ресурс]: [web-сайт]. URL: https://mozilla.github.io/pdf.js/ (дата обращения: 13.03.2018)

6. Официальный сайта PDF.js [Электронный ресурс]: Форум обсуждения проблемы возможности использования PDF.js вместе с Type: [web-сайт]. URL: https://github.com/mozilla/pdf.js/issues/7909 (дата обращения: 13.03.2018).

7. Официальный сайт библиотеки “iText” [Электронный ресурс]: [web-сайт]. URL: https://itextpdf.com (дата обращения: 13.03.2018)

8. Официальный сайт Webpack [Электронный ресурс]: [web-сайт]. URL: https://webpack.js.org (дата обращения: 13.03.2018)

9. Официальный сайт Webpack-dev-server [Электронный ресурс]: [web-сайт]. URL: https://github.com/webpack/webpack-dev-server (дата обращения: 13.03.2018)

10. Официальный сайт языка TypeScript [Электронный ресурс]: [web-сайт]. URL: https://www.typescriptlang.org (дата обращения: 13.03.2018)

11. Официальный сайт Ts-loader [Электронный ресурс]: [web-сайт]. URL: https://github.com/TypeStrong/ts-loader (дата обращения: 13.03.2018)

12. Официальный сайт библиотеки “CSS-loader” [Электронный ресурс]: [web-сайт]. URL: https://github.com/webpack-contrib/css-loader (дата обращения: 13.03.2018)

13. Официальный сайт React-redux [Электронный ресурс]: [web-сайт]. URL: https :// github . com / reduxjs / react - redux (дата обращения: 13.03.2018)

14. Официальный сайт библиотеки “React-data-grid” [Электронный ресурс]: [web-сайт]. URL: https://github.com/adazzle/react-data-grid (дата обращения: 13.03.2018)

15. Официальный сайт библиотеки “React-select” [Электронный ресурс]: [web-сайт]. URL: https://github.com/JedWatson/react-select (дата обращения: 13.03.2018)

16. Официальный сайт React-router-redux [Электронный ресурс]: [web-сайт]. URL: https :// github . com / reactjs / react - router - redux (дата обращения: 13.03.2018)

17. Официальный сайт Spring Boot [Электронный ресурс]: [web-сайт]. URL: https://spring.io/projects/spring-boot (дата обращения: 13.03.2018)

ПРИЛОЖЕНИЕ В