efrei m1 jakartaee projet
1.0.0
The Rolland Garos tournament is an international tennis tournament.
Develop a web management of matches in the Rolland Garos tournament.
Functional role of the project The application should make it possible to plan the matches and plan which players will participate in, which referee will supervise it. Then, you must be able to inform the results of the match (the scores of each team). Visitors should be able to consult the results of the finished matches.
When carrying out our project, we made several assumptions about the operation we imagined for our application, and in order to guarantee the consistency of the latter:
Hypothesis 1:
An organizer defines himself if the double matches are male, female or mixed matches when he scored the players in a match. That is to say that if he scored in a double match a man and a woman in the same team, the match is mixed. For simple matches it is not possible for a man to face a woman, however he is not prohibited for doubles that a team of two men face a team of two women.
Hypothesis 2:
We have only one application for journalists and organizers and not two separate applications. So we have a home page as well as a page that allows you to see the matches finished, and the other actions (such as adding players, planning matches, etc.) are only accessible after a connection (to find out more about the safety used, refer to the security part of the report).
Hypothesis 3:
We hypothesized that the matches could last a maximum of 4 hours. We have added a feature that checks that a course is free before we can select it for a new match. We can therefore ensure that two different games cannot be played at the same time on the same course. The maximum duration of 4 hours allows us to put a limit in order to be able to select a course, even if a match is planned, but not yet finished 4 hours before the start of the new match.
To carry out this project, we organized ourselves using the Agile method.
At the start of the project, we wrote user accounts of the following application:
This corresponds to the following use case diagram:
We then divided these user stories into development tasks.
Each session corresponded to a sprint: we did a meeting at the start of the session to determine which tasks should be part of the project. To facilitate the task, we used the project management tools integrated with Github: the outlets, the Request sweater and the Kanban table.
The tasks were represented by outcome, which can be assigned to a collaborator. The progress of the tasks was followed by having the outlets on the Kanban table. When an employee had finished a task, they created an associated request sweater, and submitted it for a code review.
The workflow was as follows:
JSTL: A component of the JEE platform to extend the JSP specification by adding a library of beacons for current tasks, such as work on parole, loops and internationalization.
MariaDB : Implémentation Open Source du Système de Gestion de
Base de Données Relationnel MySQL.
Jakartaee: Open Source Specification of Java EE. We use JSP in particular, the servlet containers, the EJB and JPA.
Bootstrap est un framework CSS permettant de facilement implémenter des styles
prédéfinis
Wildfly (formerly JBOSS) is an open source application server implementing the Java EE / Jakarta EE specification.
EJB / Enterprise JavaBeans est une API de composants logiciels coté serveur
permettant d’encapsuler la logique métier des applications d’entreprise.
JPA (Specification) / Hibernate (Implementation) is an ORM which allows you to serialize and dearialize Java (EJB Entity) objects in a relational database management system.
We used the so -called “clean architecture” architecture also called “onion” architecture, made up of different layers, decoupled from each other by service contracts described by interfaces. When a request arrives, it is first processed by the controller, to build objects from the data, it then passes through the service layer which contains the business logic. The service layer calls for the restitory layer which contains interactions with the database. The restitory layer uses the classes of the entities of the data model.
In our ours application, each layer corresponds to the following components:
We used interface programming as well as the dependencies injection mechanism allowed by Java Beans companies in order to have a low coupling between the application components.
We have been careful not to store user passwords in clear in the database. Thus, if the latter were to be hacked, the attackers would not have access to passwords. We have chosen to chop passwords with the BCRYPT salted hash algorithm, because it is the standard in the matter. To do this, we imported the JBCRYPT library in our project (via Maven) which implements the algorithm in Java.
In the application, most roads should only be accessible by an authenticated user. We have therefore set up an authentication page to authenticate the user. We use the HTTP session to store the authenticated user profile.
To allow a user on the protected roads, we have set up an authorization HTTP filter, which checks whether the current HTTP session contains an authenticated user profile. If so, the filter allows the user, otherwise it redirects it to the connection page.
We started the implementation of the project by creating the business classes (ENTITIES of our project package) as we had defined them during modeling. We then created the classes, and the interfaces, allowing us to access the database (Restitories packages). Finally, we have implemented the possibility of identifying with our application all together in order to agree on certain agreements to keep our project coherent. Once these steps have been completed, we divided the work, by giving everyone a certain number of User Stories to do, the work was done so until all user stories are carried out.
Most User Stories were easily made, except User Story: prepare a match. During our initial application modeling, we had poorly represented the “Many to Many” links connecting the players to the matches, we are not fascinated by a class representing the teams (participation classes in our project). So when we try to add players to games during the preparation phase, an exception was launched and the match preparation was not done. After having looked in more detail the functioning of the “Many to Many” relationships we realized that it was impossible to make two relationships of this type between the same two classes (here two relationships connecting the players to the games, because there are always two teams) without going through an intermediate class (here participation) in order to be able to properly associate the players with the matches. We therefore had to modify our class diagram in order to be able to properly model our new implementation, as well as modify the Match and Players business classes and add the participation class in order to make our application work perfectly.
The second difficulty encountered did not concern a User Story in particular, but a data encoding problem. After finishing all our user stories, during our various tests, and during our improvements we noticed that the accents, normally supported by the UTF8, were not properly stored in the database. Indeed, all accent characters in the base were replaced in another format. After looking at the Internet, we understood that the problem came from Wildfly, and to solve it we therefore simply had to change the encoding of the servlet container in the Wildfly configuration. To do this, we just had to go to the WildFly configuration and modify the default encoding settings of the servlet container by UTF-8.
We have also encountered problems with the management of the dates format. We use the Localdate type (most recent date API in Java) in our business class, to store the scheduled date of a match for example. Now JSTL does not have a function to format this type of dates, because it still uses the old Java date API. We therefore had to perform a hand formatting in the JSP pages which displayed dates (you can go see this formatting in the consultmatches.jsp page for example).
Once these difficulties have been overcome, we were able to focus on improving our application and adjusting minor bugs.
During this project, we were introduced to business application development with Jakarta EE. Although some of some of them already had experience on server on the server side, this project was for the occasion to appropriate us the platform development standards
We have notably been able to set up skills on Orm JPA technology which offers a very rich API is powerful. Certain mechanisms such as the "Many to Many" relationships have given us difficulties but we have to overcome them.
Finally, the collaborative aspect of this project is one of its strengths. Indeed, mutual motivation is a powerful engine that allows you to overcome any type of difficulty. This has also given us the opportunity to apply agile project management skills acquired in other modules, in order to collaborate in the most efficient way possible.
