1. Danil Eremeev
  2. booking

Overview

HTTPS SSH

Сервис бронирования билетов

Комментарии к выполнению задания

Консольное приложение + Unit тесты для тестирования, у каждого теста или понятное название метода, или описание что тестируем.

Задача очень обширная поэтому я принял кучу "условностей" например:

  1. Поезда ходят только в одну сторону - если хочется в обратную- это другой маршрут который нужно добавлять в базу.
  2. Лишнего ничего (например данные покупателя) в базу не засовывал за ненадобностью при разработке алгоритма
  3. Использовал не совсем "хорошую" структуру базы. Самому она не очень нравится - но остановился на ней - т.к. она дает выйгрыш в относительной простоте запросов к ней. Если все делать по правильному (такая таблица осталась в базе и называется routes) - там начинаются проблемы с запросами - мне кажется они чересчур сложны, к тому же там еще остается много вопросов по поводу хранения доп. информации о каждом участке маршрута.

База данных:

routes - старый "остаток" от первоначального варианта - по логике правильный но в реализации более сложный - поэтому брошенный (но оставленный для того чтобы показать что я понимаю недостатки текущей схемы)

routes_schedule - Расписание поездов - Если необходимо добавить новый маршрут на какую то дату - необходимо добавить запись в эту таблицу ( дата времяидентификатор маршрутаколичество мест на маршруте)

stations_link - "новая" реализация - не совсем красивая, зато удобная, и в принципе если подумать то может даже и лучше правильного варианта.

Допустим добавляем маршрут " Свердловск-Саратов-Москва-Питер" В эту таблицу цепочка станций попадет в следующем виде (естественно в таблице будут только идентификаторы)

Столбцы:

  • (номер станции от какой отправляемся по порядку)
  • 2 (номер станции до какой едем по порядку),
  • 0 (время "отбытия" от этой остановки в часах, тоесть каждая последующая станция в зависимости от длительности хода поезда до нее будет иметь разное время),
  • 1 - Номер маршрута

Записи:

  • 1 запись: Свердловск - Саратов - 1
  • 2 запись: Свердловск - Москва - 1 -3 -0ч-1
  • 3 запись: Свердловск - Питер - 1 - 4 - 0 ч- 1
  • 4 запись: Саратов - Москва - 2-3 - 1ч - 1
  • 5 запись: Саратов - Питер - 2 -4 - 1ч- 1
  • 6 запись: Москва - Питер - 3-4 - 2ч - 1

Тоесть имеем для каждого "подмаршрута" отдельную запись. Что позволяет нам моментально определить присутствие маршрута необходимого клиенту (при этом не ошибиться в "последовательности" станций). Узнать точное время прибытия поезда на конкретную станцию. Задать для каждого маршрута отдельную стоимость и т.д.

Tickets - тут хранятся купленные клиентами места - при этом учитывается от какой и до какой станции куплен билет.

Что учитывается:

  1. Если поезд отправляется от 1й станции 10.01.2010 в 23:00 а к 3й станции он прибудет только через 3 часа - и в запросе мы желаем купить билет на этот поезд на 10.01.2010 от 3й станции до какой то - то у нас этого не получится - т.к. посадка на 3й станции будет происходить уже 11.01.2010
  2. При выяснении количества проданных билетов учитываются следующие моменты

Имеем вот такой порядок станций: .. code-block:

 ХХХХ                             ХХХХХ
|---|---|---|---|----|----|---|----|-----|   (тут билет будет успешно куплен)
             000000
  • XX..XX - Билетов раскуплено по максимуму между этими станциями
  • 00..00 - Мы хотим купить билетов между этими станциями

Теперь если понять схему ( что верт. линии это станции - X закрывают раскупленные полностью места в поезде, 0 - где мы хотим купить билет) То можно построить кучу разных "подводных камней" .. code-block:

      ХХХХXXXXXXXX          ХХХХХ
|---|---|---|---|----|----|---|----|-----|    (здесь купить не можем - места заняты)
          0000000000

 ХХХX                ХХХХХ
|---|---|---|---|----|----|---|----|-----|   (здесь купить не можем - места заняты)
          000000000

 ХХХX          ХХХХХ
 |---|---|---|---|----|----|---|----|-----|  (здесь купить не можем - места заняты)
          00000000000000

Ну вобщем последнее это уже лишнее конечно - но для примера.

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

Все эти ситуации обрабатываются 1м sql запросом. - собственно к чему я и стремился отойдя от более правильной структуры бд. Хотя конечно количество записей будет расти очень быстро в зависимости от длинны маршрутов. Но думаю для тестового задания нормально ).

В базе для тестов заведены следующие маршруты

  1. Москва - Саратов - Волгоград - Свердловск - Тюмень
  2. Барнаул - Бобруйск- Волгоград - Астрахань - Новосибирск
  3. Симферополь - Свердловск - Бобруйск - Саратов - Москва

А так же для 1го маршрута на дату 10.02.2010 с 1й по 2ю станцию "куплено" 5 мест с 3й по 5ю - 7 мест.

Тестовая входящая xml лежит в папке test/testFiles она одна и только для проверки валидатора.

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

Используется бд mysql. Приложил sql dump для возможности восстановить копию В коде не переживал за защищенность - поэтому сервис не "многозадачен", по идее туда надо добавить блокировку на время получения количества билетов и бронирования новых. Использовал MySQL connector стандартный + обычные запросы.

Архитектура

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

BookingService агрегирует: InputParams и IConnector

InputParams – Получаем после того как распарсим принятую XML Классом InputParser – заодно там же проведем валидацию XML IConnector – Подсовываем в BookingService для того чтобы при необходимости заменить базу на другую

Все ошибки и еще что то отлавливаем с помощью BSException наследуемого от Exception На самом верхнем уровне если поймали BSException – через класс OutputFormatter формируем xml ответа с ошибкой. Если Exception'a не было – считаем что ошибки не было и забронировалось все замечательно.

Условие задачи

Дано:

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

Сервису на вход поступает XML-документ содержащий:

пункт отправления; пункт назначения; количество бронируемых мест; данные пассажиров; желаемая дата отправления;

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

1. Описать бизнес-процесс сервиса (IDEF0 или UML диаграмма), описать архитектуру решения (рисунок с пояснениями), форматы обмена (XML-схема), структуру БД (ERWin-схема).

2. Разработать работающее приложение и примерами входных и выходных документов;