
информацию. Клиент реализует пользовательский интерфейс написанный используя HTML, CSS, Bootstrap и шаблонизатор freemarker.
Бизнес-логика курсового проекта выполняется в серверной части. Клиент посылает запросы на сервер, SQL-запросы используются для добавления, обновления, удаления и выбора необходимой информации из базы данных.
Вкачестве основной среды разработки была выбрана IDE IntelliJ IDEA;
вкачестве СУБД использовалась PostgreSQL; для проектирования и построения UML-диаграмм использовался Enterprise Architect; для проектирования IDEF0-модели использовалось CASE-средство CA AllFusion.
Использовался Process Modeler r7 (BPwin).
2.3 Архитектурные решения
Диаграмма классовопределяет типы классовсистемы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Вид и интерпретация диаграммыклассовсущественнозависитотточкизрения (уровняабстракции): классы могут представлять сущности предметной области (в процессе анализа) или элементы программной системы (в процессах проектирования и реализации).
В данном курсовом проекте были реализованы следующие классы, диаграммы классов показаны на рисунке 2.1.
25

Рисунок 2.1 – Диаграмма классов пакета CarSalesWebapp.
Паттерн проектирования – часто встречающееся решение определённой проблемы при проектировании архитектуры программ. В отличие от готовых функций или библиотек, паттерн нельзя просто взять и скопировать в программу.Паттернпредставляетсобойне какой-токонкретный код, аобщую концепцию решения той или иной проблемы, которую нужно будет ещё подстроить под нужды вашей программы.
Можно выделить следующие основные группы паттернов:
порождающие паттерны;
структурные паттерны;
поведенческие паттерны.
Паттерны, использованные в данном курсовом проекте, рассмотрены
ниже.
Паттерн проектирования Factory Method.
Фабричный метод - это порождающий паттерн проектирования, который позволяет объекту создавать другие объекты, не раскрывая свою логику создания. Это означает, что класс делегирует процесс создания объектов другому классу, который называется Фабрикой. Фабрика знает, какой класс необходимо создать и какой конструктор использовать. Фабричный метод упрощает создание объектов и позволяет соблюдать принципы SOLID, такие как единство ответственности и открытость/закрытость принцип.
Диаграммы классов показана на рисунке 2.2.
26

Рисунок 2.2 – Диаграмма классов пакета carHierarchy.
Паттерн проектирования Singleton.
Singleton - это порождающий паттерн проектирования, который гарантирует, что класс имеет только один экземпляр и предоставляет глобальную точку доступа к этому экземпляру. Таким образом, создается класс-синглтон, который может использоваться в приложении для доступа к некоторым общим данным или сервисам, таким как база данных, файловая система, логирование и т. д.
Разрабатываемый программный продукт представляет собой клиентсерверное приложение для работы с СУБД PostgreSQL через веб-сервис. Предполагается развертывание в организации, имеющей локальную вычислительную сеть с выделенным сервером. В таком случае на выделенном сервере устанавливается СУБД, на которой развертывается база данных системы, и создается директория для хранения документов. Экземпляры клиентских приложений размещаются на машинах сотрудников организации, на которых предварительно должен быть установлен JDK 1.8 и выше. Доступ клиентских приложений к базе данных осуществляется при помощи драйвера jdbc data provider for PostgreSQL, входящего в состав JDK. Данные,
необходимые для установки соединения с сервером, хранятся в конфигурационномфайле клиентского приложенияи доступны длянастройки пользователем. Настройки, используемые всеми приложениями системы,
27

хранятся в одной из таблиц базы данных. Это позволяет производить изменения, которые распространяются сразу на все экземпляры приложений, с другой стороны, доступ к настройкам системы закрыт для рядовых пользователей.
Диаграмма компонентов описывает особенности физического представления системы. Она позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный и исполняемый код.Основнымиграфическимиэлементамидиаграммыкомпонентовявляются компоненты, интерфейсы и зависимости между ними. Диаграмму можно увидеть на рисунке 2.3.
Рисунок 2.3 – Диаграмма компонентов.
Разделение приложения на составные части, каждая из которых реализует определенную часть функциональности, позволяет повысить структурированность системы, позволяет повторно использовать компоненты; обеспечивает большую гибкость продукта и облегчает его изменение.
28

2.4Описание алгоритмов, реализующих ключевую бизнес-логику разрабатываемого программного средства
Бизнес логика данного курсового проекта - это организация процесса подачи и просмотра объявлений, а также процесс создания отзыва пользователем, остальной функционал является вспомогательным, поэтому в этой главе рассмотрим два процесса: процесс создания нового обявление и процесс создания отзыва.
При входе в программу нужно нажать на кнопку «Добавить объявление». Для создания объявления необходимо заполнить все поля, нужно учесть, что два одинаковых объявления существовать не могут.
Если при создании объявления были допущены ошибки, то на экран выводится соответствующее сообщение и можно попытаться создать объявление снова.
Алгоритм работы программы представлен на рисунке 2.4.
Рисунок 2.4 – Создание объявления
29

Второй процесс - это публикация. После просмотра каталога можно выбрать авто отзыв на которые вы хотите оставить. Далее вам нужно нажать на кнопку оставить отзыв и заполнить все поля. Введенные данные отправляются на сервер, который начинает их обрабатывать, подключаясь к базе данных. Если там есть соответствующие данные, то отзыв на авто публикуется, а на клиента отправляется сообщение об успешной публикации отзыва, в противном случае сообщение об ошибке.
Алгоритм работы программы представлен на рисунке 2.5.
Рисунок 2.5 – Публикация отзыва
2.5 Проектирование пользовательского интерфейса
Пользовательский интерфейс представляет собой совокупность средств для взаимодействия пользователя и компьютера, которая основана на представлении всех возможных вариантов использования, доступных пользователю, в виде графических компонентов экрана.
30
Хороший пользовательский интерфейс (UI) - это интерфейс, который удобен и легок в использовании для пользователя. Он должен быть функциональным, реактивным и интуитивно понятным. Хороший UI должен предоставлятьлегкийдоступкнеобходимойинформации ифункциям,атакже обладать удобной навигацией и четкими инструкциями для пользователя. Такой интерфейс помогает повысить удовлетворенность и лояльность пользователей, способствует увеличению эффективности и уменьшению количества ошибок при использовании приложения.
2.6Методы и средства, используемые для обеспечения безопасности данных
SpringSecurity—этофреймворк,которыйсфокусированнаобеспечение как аутентификации, так и авторизации в Java-приложениях. Как и все Spring проекты, настоящая сила Spring Security в том, что он может быть легко дополнен нужным функционалом.
Возможности:
1.Комплексная и расширяемая поддержка как аутентификации, так и авторизации;
2.Защита от атак типа фиксация сессии, кликджекинг, межсайтовая подделка запроса и др;
3.Интеграция с Servlet API;
4.Интеграция с Spring Web MVC при необходимости.
Самым фундаментальным являются SecurityContextHolder. В нем мы храниминформациюотекущемконтекстебезопасностиприложения,который включает в себя подробную информацию о доверителе (принципале/пользователе) работающем в настоящее время с приложением. По умолчанию SecurityContextHolder использует ThreadLocal для хранения такой информации, что означает, что контекст безопасности всегда доступен для методов исполняющихся в том же самом потоке, даже если контекст безопасности явно не передается в качестве аргумента этих методов. Использование ThreadLocal таким образом, вполне безопасно, если принимаются меры для очистки потока после завершения обработки запроса текущего доверителя. Естественно Spring Security делает это за вас автоматически, поэтому нет необходимости беспокоиться об этом.
31

3ТЕСТИРОВАНИЕ И ПРОВЕРКА РАБОТОСПОСОБНОСТИ ПРОГРАММНОГО СРЕДСТВА
Тестирование – это процесс проверки функционала программы с целью
подтверждения того, что она работает в соответствии с определёнными требованиями.
Unit-тестирование – это тестирование, которые пишутся, непосредственно, на уровне разработчика (тестирование определённой сущности – метод или класс). Это крайне важный этап разработки ПО, который помогает создавать качественный продукт [9].
Для тестирования использовался JUnit.
Для тестирования методов создания объекта класса Car класс TestCreateAdd. Для проверки работы классов отвечающих за отправку электронных писем использовался класс TestSendMail, класс TestCheckRules проверяет работу методов изменяющих права пользователей.
Результат отработки тестов прдеставлен на рисуноке 3.1.
Рисунок 3.1 – Результат отработки тестов.
Для того чтобы убедиться, что программное средство может корректно выполнять работу и устойчиво к ошибкам пользователя было проведено ручное тестирование (manual testing), отражающие все возможные исключительные ситуации.
Во-первых, было рассмотрена возможность не корректной регистрации пользователя, а именно:
попытка регистрации без указания логина;
попытка регистрации без указания пароля;
попытка регистрации с указанием уже существующего логина.
32

Программа реагирует на все три ситуации, выводится сообщение об ошибке (рисунки 3.2, 3.3, 3.4).
Далее была рассмотрена ситуация неправильной авторизации пользователя, а именно:
ввод неверных данных.
Программа реагирует на все ситуации аналогично реакции в форме для регистрации (рисунки 3.5)
Рисунок 3.2 – Ошибки при регистрации.
Рисунок 3.3 – Ошибки при регистрации.
Рисунок 3.4 – Ошибки при регистрации.
33

Рисунок 3.5 – Ошибки при авторизации пользователя.
Далее была протестирован процесс добавления объявления. Программа реагирует если в поля не вводятся значения или если значения не соответствуют типу запрашиваемых данных. (рисунок 3.6).
Рисунок 3.6 – Ошибки при не заполнении формы.
По результатам тестирования можно сделать вывод, что разработанное программное средство удовлетворяет функциональным требованиям и функции выполняются корректно.
34