13. Пояснительная записка
Портал экскурсий - информационная система, которая позволяет автоматизировать прием и обработку заказов для проведения различных экскурсий.
В информационной системе "Портал экскурсий" предусмотрены роли:
-
Клиент - осуществляет проведение экскурсий
-
Экскурсовод - проводит экскурсии
-
Администратор - выполняет управление содержимым портала
ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ:
1. для Клиента:
- Регистрация и авторизация в системе
- Указывание контактной информации
- Поиск экскурсий по различным типам
- Сортировка и фильтрация данных
- Оформление заявки
2. для Экскурсовода
- Регистрация и авторизация в системе
- Указывание контактной информации
- Редактирование заявки
3. для Администратора
- Возможности клиента и администратора
- Просмотр и изменение текущих заявок
- Обновление базы экскурсоводов
ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ для разных ролей: Клиент:
Экскурсовод:
Администратор:
1. Клиент
1.1 Регистрация нового пользователя
- Пользователь вводит логин и пароль;
- После проверки регистрация завершается успешно;
- _Альтернатива:_пользователь с таким логином уже существует в системе или введен недопустимый пароль (менее четырех символов). Система предложит ввести иной логин или пароль.
1.2 Авторизация пользователя
- Пользователь вводит свои регистрационные данные;
- Данные проходят проверку, авторизация завершается успешно, затем система переходит на страницу пользователя;
- Альтернатива: данные не проходят проверку (например, если такого пользователя не существует в базе). Система предложит заново ввести логин и пароль.
1.3 Заполнение личной информации
- Авторизованный пользователь, заходит на свою страницу;
- Пользователь нажимает "изменить личные данные", после этого система переводит его на страницу редактирования личных данных;
- Пользователь вводит информацию о себе(Имя, фамилия, пол, возраст, город по которому он проводит экскурсии и т.д.), а затем подтверждает ввод данных;
- Измененные данные сохраняются и выводится сообщение "данные успешно изменены".
1.4 Просмотр информации об экскурсии
- Система выводит информацию об экскурсиях;
- Пользователь задает условия поиска (по названию, цене и др.);
- Пользователь имеет возможность отсортировать результаты поиска.
1.5 Оформление заказа
- Клиент просматривает и выбирает экскурсию;
- Клиент указывает дату и время выполнения заказа;
- Клиент указывает продолжительность экскурсии;
- Клиент указывает место отправной точки, куда необходимо прибыть экскурсоводу;
- Клиент подтверждает окончание оформления заявки.
2. Экскурсовод
2.1 Регистрация экскурсовода
- Ввод логина и пароля;
- После проверки данных регистрация успешно завершается;
- _Альтернатива:_пользователь с таким логином уже существует в системе или введен недопустимый пароль (менее четырех символов). Система предложит ввести иной логин или пароль.
2.2 Авторизация экскурсовода
- Администратор вводит свои регистрационные данные;
- Данные проходят проверку, авторизация завершается успешно, затем система переходит на страницу администратора;
- Альтернатива: данные не проходят проверку (например, если такого пользователя не существует в базе). Система предложит заново ввести логин и пароль.
2.3 Просмотр информации об экскурсии
- Система выводит информацию об экскурсиях;
- Пользователь задает условия поиска (по названию, цене и др.);
- Пользователь имеет возможность отсортировать результаты поиска.
2.4 Просмотр и изменение статуса заказов
- Просмотр заказов, имеющихся у экскурсовода на данных момент;
- Изменение статуса заказа (Принят/Не принят);
- Удаление заказа, если заказ имеет статус "Выполнен".
3. Администратор
3.1 Регистрация
- Ввод логина и пароля;
- После проверки данных регистрация успешно завершается;
- _Альтернатива:_пользователь с таким логином уже существует в системе или введен недопустимый пароль (менее четырех символов). Система предложит ввести иной логин или пароль.
3.2 Авторизация администратора
- Администратор вводит свои регистрационные данные;
- Если данные проходят проверку, авторизация завершается успешно и система переходит на страницу администратора;
- Альтернатива: данные не проходят проверку (например, если такого пользователя не существует в базе). Система предложит заново ввести логин и пароль.
3.3 Действия с экскурсиями
- После авторизации, администратор может выполнить следующее: добавить новую экскурсию или изменить уже существующую;
- Задать условия поиска, очуществить сортировку и фильтрацию.
3.4 Действия с заказами
- Просмотр заказов, имеющихся на данных момент;
- Изменение статуса заказа (Принят/Не принят);
- Удаление заказа, если заказ имеет статус "Выполнен".
Диаграмма последовательности для Клиента:
Диаграмма последовательности для Экскурсовода:
Диаграмма последовательности для Администратора:
Для реализации бизнес-логики выбран паттерн Domain Model (модель области определения). Данный шаблон лучше всего подходит для отображения объектно-ориентированной модели приложения. Тем не менее, паттерн имеет недостатками (сложность взаимодействия с БД, сложность реализации), которые необходимо учесть при дальнейшей разработке. В сочетании с паттерном "Domain Model" был использован архитектурный шаблон "Сценарий транзакции". Данный шаблон подразумевает выделение каждого действия клиента относительно программы в отдельную процедуру. Данный шаблон хорошо подходит для небольших приложений с достаточно простой бизнес-логикой, в которых все операции легко разбиваются на транзакции, каким и является разрабатываемое приложение. Разработанные классы, реализующие бизнес-логику, можно найти в пакете logic.
Бизнес-логика портала экскурсий представлена в папке logic. Бизнес-логика включает в себя следующие классы:
- User - абстрактный класс для наследников: Admin, Client, Guide
- Admin - класс администратора
- Client- класс клиента
- Guide - класс экскурсовода
- Order - класс заказа
- UserTransaction - класс, реализующий взаимодействие пользователя с системой
- OrderTransaction - класс, реализующий взаимодействие пользователей заказами
Unit-тесты находятся в папке Тесты: OrderTest и UserTest.
8. Проектирование слоя источников данных (выбор архитектурного шаблона уровня доступа к данным: DB внешний сервис)
Для реализации слоя источников данных в качестве паттерна было решено выбрать шаблон Data Mapper так как:
- Поля объектов бизнес логики совпадают с именами колонок в таблице БД
- Шаблон Data Mapper хорошо сочетается с шаблоном Domain Model
- Обмен с Базой Данных будет простым ("считать из таблицы/записать в таблицу")
- В отличие от Active Record, шаблон Data Mapper позволяет отделить слой доступа к данным от слоя бизнес логики.
Наследование было реализовано с использованием шаблона Single Table Inheritance. Применение этого шаблона оправдано, поскольку только в классах Client, Guide и Admin используется наследование, поля этих классов практически совпадают и могут быть вынесены в один класс: UserTypesEnum. Файлы с классами располагаются в пакете "db".
В проекте использовалась база данных Apache Derby версии 10.1.1.0. Для работы с базой реализованы методы, обеспечивающие:
- выборку всех записей в таблицей
- выборку записей по заданному критерию
- добавление записи в таблицу
- удаление записи из таблицы
- изменение записи по заданному критерию
Классы, реализующие эти методы располагаются в пакете "db":
- AbstractMapper - абстрактный класс, объявляющий общие методы для коммуникации с бд;
- ConnectionManager - класс, обеспечивающий соединение с бд;
- UserMApper - класс, обеспечивающий работу с таблицей USERSTABLE, содержащей информацию о пользователях;
- OrderMapper - класс, обеспечивающий работу с таблицей, содержащей информацию о заказанных экскурсиях.
Сервисный слой
Сервисный слой содержится в классе Service и предоставляет набор доступных действий над приложением. Фактически этот слой отвечает за проверку корректности входных данных, а также за перенаправление этих данных в слой бизнес-логики. Данный слой реализован с использованием шаблона Фасад.
Слой представления
Слой интерфейса. Интерфейс приложения является оконным. Реализован при помощи библиотеки Swing. Интерфейс предлагает следующие возможные действия:
- регистрацию новых пользователей
- авторизацию существующих пользователей
- оформление заказа на экскурсию
- поиск по экскурсиям
- поиск по заказам. Данные, полученные из бд, представляются в виде таблицы. Для разных пользователей доступны различные действия. Так, например, редактировать экскурсии может только администратор. Всем остальным соответствующие кнопки будут недоступны.
Сервисный слой. Сервисный слой реализован в классе Service.java в пакете Service. В классе представлены методы, обеспечивающие перенаправление запросов к бизнес-логике. Таким образом класс предоставляет интерфейс для классов, отвечающих за логику приложения.
Слой интерфейса. GUI приложения представляет собой окна, реализованные при помощи библиотеки Swing. Классы, реализующие интерфейс, располагаются в пакете GUI
- LoginFrame - окно авторизации
- RegisterFrame - окно регистрации
- Excursions - окно "экскурсии"
- OrdersFrame - окно "список заказов"
- AddOrderFrame - окно оформления заказа
- AddExcursionFrame - окно добавления экскурсий
Для упрощения работы используются классы ExcursionTableModel и OrdersTableModel. В этих классах описана связь интерфейсных сущностей с сущностями приложения.
Формы приложения:
Окно ввода логина и пароля:
Окно регистрации:
Главное окно приложения:
Окно добавления экскурсии:
Окно списка всех заказов:
Окно оформления заказа:
Приложение прошло систему тестов. Помимо тестов, которые проводились вручную, приложение прошло автоматическое тестирование. Unit-тесты содержатся в пакете "Тесты/logic":
- OrderTest - тестирование слоя работы с Заказами.
- UserTest - тестирование слоя работы с Пользователями.
В процессе разработки информационной системы "Портал экскурсий" были изучены основные паттерны проектирования, часть из них использована на практике. Также, изучены типовые решения организации различных слоев приложения: бизнес-логики, слоя доступа к данным, сервисного слоя. В результате проект реализован в соответствии с исходными требованиями. Использование архитектурных шаблонов проектирования эффективно ввиду того, что позволяет более просто писать код и повышает его читаемость.