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

Текст из файла (страница 5)

Рисунок 3.10 – Схема взаимодействия элементов паттерна MVC

Разберем составные элементы взаимодействия подробнее. Модель инкапсулирует данные приложения и в целом состоит из классов, предназначенных для связи записей в базе данных с объектами в памяти приложения. Эта связь реализована посредством ORM (Object-Relational-Mapping или объектно-реляционное отображение). В качестве ORM при разработке приложения используется библиотека Hibernate. Архитектура модели приложения изображена на рисунке 3.11.

Класс BaseEntity является абстрактным, т.е. напрямую не соотносится с таблицей в базе данных. Он предназначен в первую очередь для определения общих атрибутов модели в один класс, в данном случае поля идентификатора, имеющего типа UUID. В случае, если в будущем понадобиться добавление общего атрибута для каждой сущности модели (например, даты создания записи), наследование от общего предка избавляет от необходимости объявления нового поля в каждом классе.

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

Рисунок 3.11 – Диаграмма классов модели

Для доступа к данным используется технология Spring JPA (Java Persistence API), предоставляющая интерфейс для доступа к записям в базе данных. Существует несколько реализаций этого интерфейса, в разрабатываемом приложении используется реализация Hibernate. Использование этого интерфейса избавляет от необходимости ручного написания SQL запросов для тривиальных операций, типа чтения, обновления или удаления записей, и переписывания этих запросов в случае смены СУБД. Однако эта гибкость в некоторых случаях нивелируется снижением производительности. Для того, чтобы при необходимости с минимальными трудозатратами изменить технологию хранения или доступа к данным в приложении используется дополнительный уровень абстракции – уровень сервиса. Например, для доступа к данным класса модели Message используется структура классов, представленная на рисунке 3.12.

Рисунок 3.12 – Доступ к данным класса Message

Изменение данных модели происходит через контроллер. Контроллер принимает HTTP запрос, отправленный браузером клиента, далее происходит его обработка управляющими классы приложения и формирование ответа, который возвращается клиенту. Взаимодействие контроллера и клиента в Spring реализовано в соответствии с архитектурным принципом REST (Representational State Transfer или "передач состояния управления"). Одним из главных отличий сервисов, реализующих REST является то, что в период между запросами клиента никакая информация о состоянии клиента на сервере не хранится. Все запросы от клиента должны быть составлены так, чтобы сервер получил всю необходимую информацию для выполнения запроса. Состояние сессии при этом хранится клиентом. Информация о состоянии сессии может быть передана сервером какому-либо другому сервису (например, в службу базы данных) для поддержания устойчивого состояния, например, на период установления аутентификации. Клиент инициирует отправку запросов, когда он готов (возникает необходимость) перейти в новое состояние.

На рисунке 3.13 представлено взаимодействие контроллера с управляющими классами приложения. Каждый управляющий класс в независимости от уровня абстракции является реализацией определенного интерфейса. Это необходимо для реализации механизма внедрения зависимостей (Dependency Injection).

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

Разберем подробнее логику взаимодействия управляющих классов. Класс MessageApplicationServiceImpl, является реализацией интерфейса предоставляющего методы для работы с хеш-сообщениями. Эта реализация основана на использовании других классов, отвечающих за конкретные функции. Так, класс MessageBuilder предназначен для поиска в базе данных подходящих хеш-сумм, на основе скрываемых данных и параметров ключа.

Класс FileBuilder на основе информации из базы данных позволяет записать в изображение необходимые значения тегов, и после этого при необходимости вычислить его хеш-сумму.

Для работы с некоторыми системными классами было реализовано несколько классов-оберток, приводящих интерфейс сторонних библиотек к интерфейсу, подходящему для использования управляющими классами приложения. Например, класс Cryptography реализует метод вычисляющий значение хеш-функции, соотнося значение перечисления HashFunction с строковым значением названия алгоритма хеширования, необходимым для использования классов из библиотеки java.Security.MessageDigest.

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

Последняя часть взаимодействия – представление является HTML страницей создания и чтения сообщений.

­	Рисунок 3.13 – Диагра­мма классов приложения

3.2.4 Диаграмма развертывания

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

Главными элементами диаграммы являются узлы, связанные информационными путями. Узел (node) – это то, что может содержать программное обеспечение. Узлы бывают двух типов:

• устройство – это физическое оборудование: компьютер или устройство, связанное с системой;

• среда выполнения – это программное обеспечение, которое само может включать другое программное обеспечение, например, операционную систему.

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

На диаграмме развертывания изображенной на рисунке 3.14, представлен один из вариантов топологии информационной системы. Доступ к программному комплексу с АРМ осуществляется через браузер. АРМ с сервером объединены в локальную сеть, путем соединения с коммутатором.

На одном физическом сервере расположены сервер веб-приложения, и СУБД, необходимые для работы программного комплекса.

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

4 Руководство администратора

4.1 Развертывания приложения

В данном руководстве рассматривается процесс установки и развертывания приложения.

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

• Java8, необходимая для исполнения Java приложений;

• PostgreSQL 9.4, система управления базами данных

• Apache Tomcat 8.5, контейнер сервлетов, предназначенный для развертывания веб-приложений.

Дальнейший процесс настройки будет производиться для операционной системы семейства Windows.

Для работы приложения необходима база данных с названием hash_steg. Ее наличие можно проверить с помощью программы pgAdmin, идущей в комплекте вместе с PostgreSQL. На рисунке 4.1 представлен список баз данных.

Рисунок 4.1 – Базы данных

В случае если база данных отсутствует в списке, ее необходимо создать, например, с помощью формы создания, представленной на рисунке 4.2

Рисунок 4.2 – Создание новой базы данных

Далее war файл, полученный этапе упаковки приложения, необходимо скопировать в специальную папку. В случае стандартной установки Tomcat 8.5, путь к этой папке следующий – \Tomcat 8.5\webapps\. Для корректной работы приложения, этому файлу необходимо задать наименование ROOT.war.

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

Для отключения кэширования, в текстовом редакторе в конфигурационный файл context.xml добавляется строка, изображенная на рисунке 4.3

Рисунок 4.3 – Отключение кэширования

Последним шагом является запуск сервера Tomcat. В случае использования графического интерфейса, для запуска сервера требуется нажать кнопку Start. Окно запуска представлено на рисунке 4.4.

Рисунок 4.4 – Запуск сервераTomcat

В случае успешного запуска, при открытии в браузере страницы расположенной по адресу http://localhost:8080, отобразится главная страница приложения.

4.2 Администрирование приложения

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

Добавление новых файлов, производиться путем их копирования в папку развернутого приложения \WEB-INF\classes\image\. Далее необходимо инициализировать добавление информации о новых изображениях в базу данных, а также расчет их хеш-сумм. Для этого производится перезапуск сервера Tomcat.

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

Иными словами, время необходимое на создание сообщения, при пересчете индекса многократно увеличивается.

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

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

В ходе тестирования приложения, для этих целей использовалась бесплатная программа FILEminimizer Pictures. Главное меню программы представлено на рисунке 4.5.

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

Характеристики

Список файлов ВКР