Материал: Разработка автоматизированной системы учета электронных подписей

Интерпретатор PHP имеет специальный конфигурационный файл - php.ini, содержащий множество настроек, изменение которых влияет на поведение интерпретатора. Имеется возможность отключить использование ряда функций, изменить ограничения на используемую скриптом оперативную память, время выполнения, объём загружаемых файлов, настроить журналирование ошибок, работу с сессиями и почтовыми сервисами, подключить дополнительные расширения, а также многое другое.

Yii2 - объектно-ориентированный компонентный фреймворк, написанный на PHP и реализующий парадигму MVC.

Возможности фреймворка Yii2:

высокая производительность относительно других фреймворков, написанных на PHP;

парадигма Модель-представление-контроллер;

интерфейсы DAO и ActiveRecord для работы с базами данных (PDO);

поддержка интернационализации;

кэширование страниц и отдельных фрагментов;

перехват и обработка ошибок;

ввод и валидация форм;

аутентификация и авторизация (RBAC и ACL);

использование AJAX и интеграция с jQuery;

генерация базового PHP-кода для CRUD-операций.

MySQL - свободная реляционная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle, получившая права на торговую марку вместе с поглощённой Sun Microsystems, которая ранее приобрела шведскую компанию MySQL AB.

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей [8]. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

MySQL портирована на большое количество платформ: AIX, BSDi, FreeBSD, HP-UX, Linux, Mac OS X, NetBSD, OpenBSD, OS/2 Warp, SGI IRIX, Solaris, SunOS, SCO OpenServer, UnixWare, Tru64, Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Server 2003, WinCE, Windows Vista, Windows 7 и Windows 10.

MySQL имеет API для языков Delphi, C, C++, Эйфель, Java, Лисп, Perl, PHP, Python, Ruby, Smalltalk, Компонентный Паскаль и Tcl, библиотеки для языков платформы .NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.

Максимальный размер таблиц в MySQL 3.22 до 4 гигабайт, в последующих версиях ограничений нет.

Размер таблицы ограничен её типом. В общем случае тип MyISAM ограничен предельным размером файла в файловой системе операционной системы. Например, в NTFS этот размер теоретически может быть до 32 эксабайт. В случае InnoDB одна таблица может храниться в нескольких файлах, представляющих единое табличное пространство. Размер последнего может достигать 64 терабайт.

В отличие от MyISAM, в InnoDB имеется значительное ограничение на количество столбцов, которое можно добавить в одну таблицу. Размер страницы памяти по умолчанию составляет 16 килобайт, из которых под данные отведено 8123 байта. Размер указателя на динамические поля составляет 20 байт. Таким образом, в случае использования динамического формата строки, одна таблица может вместить максимум 409 столбцов типа blob или text.

2. ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ ПО УЧЕТУ ЭЛЕКТРОННЫХ ПОДПИСЕЙ

2.1 Выбор модели проектирования

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

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

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

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

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

каскадная модель - особенность данной модели в том, что каждый этап разработки начинается только после завершения предыдущего этапа разработки;

поэтапная модель с промежуточным контролем - разработка приложения ведется итерациями с циклами обратной связи между этапами;

спиральная модель - суть данной модели в том, что выполняется множество итераций разработки и в каждой итерации реализуется какая-либо версия продукта, производится проверка системы (приложения) и уточнение требований к ней для их реализации в следующей итерации [9].

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

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

2.2 Разработка структурной схемы приложения

Структурная схема - это совокупность элементарных звеньев объекта и связей между ними, один из видов графической модели. Под элементарным звеном понимают часть объекта, системы управления и так далее, которая реализует элементарную функцию [10].

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

составе изделия;

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

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

Структурная схема приложения для определения качества подготовки специалистов приведена на рисунке 2.1.

Рисунок 2.1 - Структурная схема приложения

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

приложения для ПК;

Web-приложения для администрирования.

Модель «клиент-сервер» была выбрана для данного приложения, потому что таким приложением значительного легче управлять, чем если бы приложение полностью (со всей необходимой базой данных) устанавливалось на каждый ПК.

2.3 Диаграмма прецедентов

Диаграмма вариантов использования (диаграмма прецедентов) - диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему или приложение на концептуальном уровне.

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

Основное назначение диаграммы - описание функциональности и поведения, позволяющее всем лицам, так или иначе участвующим в разработке, совместно обсуждать проектируемую или существующую систему [12].

Диаграмма прецедентов приложения для проверки качества подготовки специалистов приведена на рисунке 2.2.

Как видно из диаграммы вариантов использования, в приложении имеется два актера:

пользователь;

администратор.

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

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

Администратор представляет собой сотрудника компании, который имеет полномочия управлять программным продуктом (добавлять и редактировать удостоверяющие центры в список, добавлять и удалять пользователей).

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

Диаграмма компонентов приложения для учета электронных подписей приведена на рисунке 2.3.

Рисунок 2.3 - Диаграмма компонентов приложения

Как видно из диаграммы компонентов, приложение будет состоять из следующих элементов:

контроллер;

модель;

база данных;

представление;

сеть Интернет;

API-адаптер;

программный код приложения, реализующий его логику.

Сеть Интернет можно отнести к приложению лишь условно, однако без них приложение не сможет функционировать. Без сети Интернет приложение для ПК не сможет получить информацию от Web-приложения, а также передать ему результаты своей работы (добавление, редактирование, удаление информации об электронных подписях в организации).

2.4 Диаграммы классов

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

Диаграмма классов является ключевым элементом в объектно-ориентированном моделировании. На диаграмме классы представлены в рамках, содержащих три компонента:

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

посередине располагаются поля (атрибуты) класса, выровненные по левому краю и начинающиеся с маленькой буквы;

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

Если предполагается использовать модификаторы доступа к членам класса (полям и методам), то используются следующие обозначения перед их наименованиями (таблица 2.1).

Таблица 2.1 - Обозначение модификаторов доступа

Диаграммы классов приложения приведены на рисунках 2.4 и 2.5. На рисунке 2.4 приведена диаграмма классов Web-приложения. На рисунке 2.5 приведена диаграмма классов приложения для ПК.

Как видно из диаграммы на рисунке 2.4, в Web-приложении будут реализованы следующие классы:

Users - класс-модель, применяемый для авторизации и работы со списком пользователей и с отдельными их учетными записями;

Files - класс-модель, используемый для работы со списком загруженных в приложение файлов и с каждым файлом по отдельности;

Logs - класс-модель, применяемый для работы со списком записей истории действий пользователя, а также работы с отдельными записями истории (добавление, удаление);

CertCentres - класс-модель, предназначенный для работы со списком удостоверяющих центров, выдающих сертификаты электронной подписи, а также работы с отдельными элементами этого списка;

Certificates - класс-модель, применяемый для работы со списком сертификатов электронной подписи пользователей, а также для работы с отдельными элементами этого списка;

Рисунок 2.4 - Диаграмма классов Web-приложения

 - класс-модель, используемый для работы с таблицей связи файлов электронных подписей с файлами, которые были использованы для подписания;- класс-контроллер для авторизации администратора в приложении;- класс-контроллер для взаимодействия приложения для ПК с Web-приложением;- абстрактный класс-контроллер, в котором реализована проверка авторизации пользователя-администратора перед обработкой запросов от него; все контроллеры, которые расположены в панели администрирования приложения, наследуются от этого контроллера;