efrei m1 jakartaee projet
1.0.0
Турнир Rolland Garos - это международный теннисный турнир.
Разработать веб -управление матчами в турнире Ролланда Гарос.
Функциональная роль проекта Приложение должно позволить планировать матчи и планировать, в которых будут участвовать игроки, в котором судья будет контролировать его. Затем вы должны быть в состоянии сообщить результаты матча (оценки каждой команды). Посетители должны быть в состоянии проконсультироваться с результатами готовых матчей.
При выполнении нашего проекта мы сделали несколько предположений об операции, которую мы представляли для нашего применения, и чтобы гарантировать согласованность последнего:
Гипотеза 1:
Организатор определяет себя, являются ли двойные матчи мужских, женских или смешанных матчей, когда он забил игроков в матче. То есть, если он забил в двойном матче мужчины и женщину в той же команде, матч смешан. Для простых матчей мужчина не может встретиться с женщиной, однако ему не запрещено вдвое, что команда из двух мужчин сталкивается с командой из двух женщин.
Гипотеза 2:
У нас есть только одно приложение для журналистов и организаторов, а не два отдельных приложения. Таким образом, у нас есть домашняя страница, а также страница, которая позволяет вам видеть завершенные совпадения, а другие действия (такие как добавление игроков, планирование совпадений и т. Д.) Доступны только после подключения (чтобы узнать больше об использованной безопасности, см. Часть безопасности отчета).
Гипотеза 3:
Мы предположили, что матчи могут длиться максимум 4 часа. Мы добавили функцию, которая проверяет, что курс будет бесплатным, прежде чем мы сможем выбрать ее для нового матча. Поэтому мы можем убедиться, что две разные игры не могут быть сыграны одновременно на одном и том же курсе. Максимальная продолжительность 4 часа позволяет нам установить лимит, чтобы иметь возможность выбрать курс, даже если матч запланирован, но еще не завершен за 4 часа до начала нового матча.
Чтобы выполнить этот проект, мы организовали себя, используя гибкий метод.
В начале проекта мы написали учетные записи пользователей следующего приложения:
Это соответствует следующей диаграмме вариантов использования:
Затем мы разделили эти пользовательские истории на задачи разработки.
Каждая сессия соответствовала спринту: мы проводили встречу в начале сессии, чтобы определить, какие задачи должны быть частью проекта. Чтобы облегчить задачу, мы использовали инструменты управления проектами, интегрированные с GitHub: The Outlets, запрос -свитер и таблицу Kanban.
Задачи были представлены результатом, который может быть назначен сотруднику. За ходом задач последовал наличие торговых точек на столе Канбана. Когда сотрудник выполнил задачу, он создал связанный свитер запроса и отправил его для проверки кода.
Рабочий процесс был следующим:
JSTL: компонент платформы JEE для расширения спецификации JSP путем добавления библиотеки маяков для текущих задач, таких как работа по условно -досрочному освобождению, петли и интернационализации.
MariaDB : Implémentation Open Source du Système de Gestion de
Base de Données Relationnel MySQL.
Jakartaee: Спецификация с открытым исходным кодом Java EE. В частности, мы используем JSP, контейнеры сервлетов, EJB и JPA.
Bootstrap est un framework CSS permettant de facilement implémenter des styles
prédéfinis
Wildfly (ранее JBoss) - это сервер приложений с открытым исходным кодом, реализующий спецификацию Java EE / Jakarta EE.
EJB / Enterprise JavaBeans est une API de composants logiciels coté serveur
permettant d’encapsuler la logique métier des applications d’entreprise.
JPA (Speciation) / Hibernate (реализация) - это ORM, который позволяет вам сериализовать и убедиться в объектах Java (EJB) в системе управления реляционной базой данных.
Мы использовали таковую архитектуру «чистой архитектуры», также называемую архитектурой «лука», состоящей из разных слоев, отделенных друг от друга по контрактам на обслуживание, описанные интерфейсами. Когда запрос прибывает, он сначала обрабатывается контроллером, чтобы создать объекты из данных, затем проходит через уровень сервиса, который содержит бизнес -логику. Служба уровня требует упорного уровня, который содержит взаимодействие с базой данных. Уровенный слой использует классы объектов модели данных.
В нашем приложении каждого слоя соответствует следующим компонентам:
Мы использовали интерфейсное программирование, а также механизм впрыска зависимостей, разрешенный компанией Java Beans, чтобы иметь низкую связь между компонентами приложения.
Мы были осторожны, чтобы не хранить пароли пользователей в очистке в базе данных. Таким образом, если последнее будет взломан, у злоумышленников не было бы доступа к паролям. Мы решили нарезать пароли с помощью алгоритма соленой хэш -хэша BCRYPT, потому что это стандарт в этом вопросе. Для этого мы импортировали библиотеку JBCrypt в нашем проекте (через Maven), который реализует алгоритм в Java.
В приложении большинство дорог должны быть доступны только аутентифицированным пользователям. Поэтому мы настроили страницу аутентификации для аутентификации пользователя. Мы используем сеанс HTTP для хранения аутентифицированного профиля пользователя.
Чтобы разрешить пользователю на защищенных дорогах, мы настроили авторизацию HTTP -фильтр, который проверяет, содержит ли текущий сеанс HTTP аутентифицированный профиль пользователя. Если это так, фильтр позволяет пользователю, в противном случае он перенаправляет его на страницу подключения.
Мы начали реализацию проекта, создав бизнес -классы (объекты нашего пакета проекта), поскольку мы определили их во время моделирования. Затем мы создали классы и интерфейсы, позволяя нам получить доступ к базе данных (пакеты Restitories). Наконец, мы реализовали возможность выявления с нашим приложением вместе, чтобы согласовать определенные соглашения, чтобы сохранить наш проект. После того, как эти шаги будут выполнены, мы разделили работу, предоставив всем определенное количество пользовательских историй, работа была выполнена для этого до тех пор, пока все пользовательские истории не будут выполнены.
Большинство пользовательских историй были легко изготовлены, за исключением пользовательской истории: подготовить совпадение. Во время нашего первоначального моделирования приложений мы плохо представляли ссылки «многие ко многим», соединяющие игроков с матчами, мы не очарованы классом, представляющим команды (классы участия в нашем проекте). Поэтому, когда мы пытаемся добавить игроков в игры на этапе подготовки, было запущено исключение, и подготовка матча не была сделана. Посмотрев более подробно, функционирование отношений «многие ко многим», мы поняли, что невозможно установить две отношения этого типа между теми же двумя классами (здесь две отношения, соединяющие игроков с играми, потому что всегда есть две команды), не проходя через промежуточный класс (здесь участие), чтобы правильно ассоциировать игроков с матчами. Поэтому нам пришлось изменить нашу классовую диаграмму, чтобы иметь возможность правильно моделировать нашу новую реализацию, а также изменить бизнес -классы матча и игроков и добавить класс участия, чтобы заставить наше приложение работать отлично.
Вторая сложность, возникшая, в частности, не касалась пользовательской истории, а проблема кодирования данных. После завершения всех наших пользовательских историй во время наших различных тестов и во время наших улучшений мы заметили, что акценты, обычно поддерживаемые UTF8, не хранятся должным образом в базе данных. Действительно, все акцентные символы в базе были заменены в другом формате. Посмотрев на Интернет, мы поняли, что проблема возникла из Wildfly, и для его решения нам просто пришлось изменить кодирование контейнера сервлета в конфигурации Wildfly. Для этого нам просто нужно было перейти к конфигурации Wildfly и изменить настройки кодирования по умолчанию контейнера сервлета с помощью UTF-8.
Мы также столкнулись с проблемами с управлением форматом дат. Мы используем тип LocalDate (самый последний API даты в Java) в нашем бизнес -классе, чтобы хранить, например, запланированную дату совпадения. Теперь у JSTL нет функции для форматирования дат этого типа, потому что он все еще использует старый API даты Java. Поэтому нам пришлось выполнить форматирование рук на страницах JSP, на которых отображались даты (вы можете увидеть это форматирование на странице ConsultMatches.jsp, например).
Как только эти трудности были преодолены, мы смогли сосредоточиться на улучшении нашего приложения и настройке незначительных ошибок.
Во время этого проекта мы были представлены в разработку бизнес -приложений с Jakarta EE. Хотя некоторые из них уже имели опыт работы на сервере на стороне сервера, этот проект был по этому поводу, чтобы присвоить нам стандарты разработки платформы
Мы, в частности, смогли создать навыки на технологии ORM JPA, которая предлагает очень богатый API, является мощным. Определенные механизмы, такие как отношения «многие ко многим», дали нам трудности, но мы должны их преодолеть.
Наконец, совместный аспект этого проекта является одной из его сильных сторон. Действительно, взаимная мотивация - это мощный двигатель, который позволяет вам преодолеть любые трудности. Это также дало нам возможность применить гибкие навыки управления проектами, приобретенные в других модулях, чтобы сотрудничать наиболее эффективным способом.
