Skip to content

Home

Jump to bottom
DaniilStepanov edited this page May 30, 2017 · 25 revisions

1)Сбор функциональных требований

Описание бизнес-процессов:

Экскурсия Участники: пользователь, транспортировщик, маршрутная система. Сущности: маршрут, автомобиль, фотоотчёт

Этапы:

1) Указание основных объектов и дополнительной информации (дата, кол-во и т.д.)

2) Назначение транспортировщика 

3) Добавление в маршрутную систему

4) Добавление туристов

5) Формирование фотоотчётов

Регистрация транспортировщика Участники: транспортировщик, маршрутная система, БД ГИБДД. Сущности: автомобиль

Этапы:

1) Подача заявки на оформление транспортировщиком

2) Проверка введенных данных

3) Добавление в маршрутную систему

Оплата услуг транспортировщика Участники: организатор экскурсии, маршрутная система, транспортировщик Сущности: договор, квитанция, экскурсия, банковская карта Этапы:

1) Организатор экскурсии и транспортировщик договариваются о цене транспортировки

2) Организатор вводит информацию о своей банковской карте

3) Маршрутная система осуществляет оплату транспортировки

4) Система отправляет квитанции транспортировщику и организатору

Система должна:

• Обеспечивать авторизованный доступ к своим сервисам;

• Позволять пользователям создавать экскурсионные маршруты и присоединяться к уже созданным;

• Давать возможность пользователям выкладывать фотографии экскурсионных маршрутов;

• Позволять транспортировщикам зарегистрировать своё ТС;

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

• Выводить дополнительную информацию об экскурсионном маршруте, взятую из открытых источников (википедия или картинки google);

• Формировать фотоотчёты после завершения экскурсии.

  1. Разработка вариантов использования (обобщенная диаграмма прецедентов)

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

Создание экскурсионного маршрута

  1. Организатор экскурсии пишет текстовое описание маршрута с указанием основных экскурсионных объектов

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

  3. Система выводит список транспортировщиков, выделяя более подходящих.

  4. Организатор выбирает транспортировщика

  5. Транспортировщик подтверждает участие и договаривается о цене с организатором

  6. Организатор производит оплату услуг транспортировщика

  7. Маршрут добавляется в маршрутную систему

Альтернатива

На шаге 2 при вводе некорректной даты система выдает предложение её исправить, после чего переходит на шаг 3

Если на шаге 4 организатор не находит подходящего транспортировщика, то он может отменить создание маршрута

Если на шаге 5 транспортировщик не подтверждает участие или не договаривается о цене, то возвращение на шаг 4

Регистрация ТС

  1. Транспортировщик вводит информацию о своём ТС, включая страховку и номер свидетельства о регистрации

  2. Производится проверка действительности введенных данных с помощью внешнего запроса

  3. Добавление ТС в маршрутную систему

Альтернатива

Если на шаге 2 проверка действительности не прошла, то возвращение на шаг 1 с указанием поля, где проверка не прошла

Присоединение к маршруту

  1. Пользователь присоединяется к маршруту

  2. Система изменяет количество туристов в указанном маршруте

  3. Система добавляет пользователя к участникам похода

Альтернатива

Если на шаге 2 превышено максимальное количество туристов, то операция отменяется

Добавление фотографий

  1. Пользователь выбирает каким образом будет добавлять фотографии (загружать с диска или добавлять ссылки)

  2. Пользователь добавляет фотографии

  3. Система добавляет фотографии к маршруту

Просмотр информации о маршруте

  1. Производится запрос к внешнему ресурсу для информации об основных экскурсионных объектах

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

  1. Моделирование предметной области при помощи диаграммы классов

  1. Моделирование предметной области при помощи диаграмм последовательностей

Реализация

Бизнес-логика Для написания бизнес-логики был использован паттерн "Модель предметной области". Для создания пользователей и экскурсий был применен паттерн "Фабричный метод". Это порождающий шаблон проектирования, предоставляющий подклассам интерфейс для создания экземпляров некоторого класса. В момент создания наследники могут определить, какой класс создавать. Иными словами, данный шаблон делегирует создание объектов наследникам родительского класса. Это позволяет использовать в коде программы не специфические классы, а манипулировать абстрактными объектами на более высоком уровне.

Весь код бизнес-логики находится в пакетах UserFactory и ExcursionObject. Диаграммы классов данных пакетов представлены ниже:

Все бизнес процессы были протестированы с помощью JUnit. JUnit — библиотека для модульного тестирования программного обеспечения на языке Java. Функциональность:

  • assertEquals
  • assertFalse
  • assertNotNull
  • assertNull
  • assertNotSame
  • assertSame
  • assertTrue

Слой источников данных В качестве СУБД была выбрана MySQL ввиду её популярности. Для создания базы данных используется скрипт createDB.sql, который создаёт необходимые таблицы и добавляет в них некоторое количество данных. Для создания и подключения к базе данных используется класс Gateway. Для работы с базой данных был применен паттерн "data mapper" --- для каждого класса бизнес-логики был написан свой преобразователь.

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

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

Все классы слоя источников данных расположены в пакете storage. Диаграмма классов представлена ниже:

Сервисный слой Сервисный слой был реализован с помощью паттерна фасад. Реализация находится в пакете facade пакета GUI. Фасад — это простой интерфейс работы со сложной подсистемой, содержащей множество классов. Фасад может иметь урезанный интерфейс, не имеющий 100% функциональности, которую можно достичь, используя сложную подсистему напрямую. Но он предоставляет именно те функции, которые нужны клиенту, и скрывает все остальное. Схема паттерна представлена ниже:

Clone this wiki locally