lab-1.md

Предисловие

В рамках лабораторных работ курса вам предстоит разработать информационную систему для мультибрендового, частного, (юридически не принадлежит ни одной автомобильной компании), автосалона с широким спектром услуг. В этот проект вы будете постепенно добавлять новую функциональность и технологии. И по выполнению всех лабораторных работ у вас получится back-end часть системы, которая должна вполне соответствовать современным тенденциям разработки ПО.

Лабораторная работа 1

Цель лабораторной работы:

• проверить освоение студентом языка программирования Java;
• проверить освоение студентом системы сборки Gradle.

Задание

• спроектировать и разработать домен автосалона;
• реализовать конфигуратор автомобилей;
• настроить систему сборки.

Описание системы

Сущности:

Клиент:

Имеет имя, идентификатор, дату рождения, номер и почту.

Сотрудник:

Имеет имя, идентификатор, а также сотрудника роль. Роль может быть:

• администратор склада
• администратор автосалона
• администратор системы

Запчасти

• Кузов
• Двигатель
• КПП
• Руль
• Интерьер
• Колёса

Каждая запчасть имеет имя; идентификатор; цену; свои какие-то характеристики (очевидно для двигателя и руля они разные)*; список идентификаторов моделей автомобилей, с которыми она совместима.

Модель автомобиля

Имеет имя; идентификатор; бренд; базовая цена (без учета запчастей); тип привода; кузов, двигатель, кпп, руль, интерьерь, колёса, являющиеся стандартными для этой модели.

Заказ готовой модели автомобиля

Связан с клиентом, совершившим заказ; связан с сотрудником, работающим над заказом; модель автомобиля; цена модели на момент создания заказа. Может находиться в одном из статусов:

• оформлен;
• согласован сотрудником;
• автомобиль готов к выдаче;
• завершен;
• отменен.

Заказ кастомного автомобиля

Имеет идентификатор клиента, совершившего заказ; идентификатор сотрудника, работающего над заказом; модель модифицируемого автомобиля; кузов, двигатель, кпп, руль, интерьер, колёса; цена модели на момент создания заказа.

Может находиться в одном из статусов:

• оформлен;
• согласован сотрудником;
• автомобиль готов к выдаче;
• завершен;
• ошибка комплектации;
• отменен.

Функциональные требования

Должна быть возможность:

• создать конкретную модель автомобиля**;
• просмотреть конкретную модель автомобиля;
• просмотреть список доступных моделей автомобилей с фильтрацией по:
  • базовая цена;
  • итоговая цена;
  • бренд;
  • тип кузов автомобиля: седан, универсал, купе и т.д.;
  • тип топлива двигателя: бензин, дизель, электричество;
  • мощность двигателя;
  • тип КПП, (коробка переключения передач): механическая, автоматическая;
  • привод автомобиля: передний, задний, полный;
  • цвет салона
• создать новую запчасть;
• обновить цену запчасти;
• обновить список доступных моделей для запчасти (только расширение);
• посмотреть конкретную запчасть;
• посмотреть список запчастей;
• создать заказ готовой модели автомобиля;
• просмотреть заказы готовых автомобилей с фильтрацией по:
  • идентификатор сотрудника
  • идентификатор клиента
• создать заказ кастомного автомобиля;
• просмотреть заказы кастомных автомобилей с фильтрацией по:
  • идентификатор сотрудника
  • идентификатор клиента

---

Заказ автомобиля с определенной комплектацией

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

Комплектацию можно поменять и заменить базовые элементы автомобиля на те, которые больше подходят конкретному клиенту. При оформлении заказа кастомного автомобиля указывается модель, кузов, двигатель, кпп, руль, интерьер, колёса (всё кроме модели автомобиля опционально), итоговая стоимость зависит от модели и комплектующих.

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

---

Нефункциональные требования

• кодовая база должна быть реализована в многослойной архитектуре (опционально)***;
• реализовать хранилище данных в виде репозиториев (in memory), использовать стандартные коллекции: Map, List, Set и др.
• обеспечить валидацию входных данных. При нарушении — бросать предметные исключения (DomainValidationException, EntityNotFoundException);
• везде, где возможно использовать StreamAPI и лямбда выражений;
• обеспечить покрытие unit-тестами;
• системой сборки: Gradle.
• реализовать запускаемый файл, с использованием всех функциональных требований

Задачи лабораторной работы:

Реализовать систему, в которой будут соблюдены все функциональные и нефункциональные требования,

---

* Без бредика, хотя бы 1-2 атрибутика.

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

*** Мне окей если всё будет в одном модуле, так будет всем проще.