efrei m1 jakartaee projet
1.0.0
Rolland Garos 토너먼트는 국제 테니스 토너먼트입니다.
Rolland Garos 토너먼트에서 경기의 웹 관리를 개발하십시오.
프로젝트의 기능적 역할 응용 프로그램은 경기를 계획하고 플레이어가 참여할 선수를 계획 할 수 있어야합니다. 그런 다음 경기 결과 (각 팀의 점수)를 알릴 수 있어야합니다. 방문객들은 완성 된 경기 결과를 참고 할 수 있어야합니다.
프로젝트를 수행 할 때, 우리는 응용 프로그램에 대해 상상했던 작업에 대해 몇 가지 가정을했으며 후자의 일관성을 보장하기 위해 다음과 같습니다.
가설 1 :
주최자는 더블 경기가 경기에서 플레이어를 득점했을 때 남성, 여성 또는 혼합 경기 인 경우 자신을 정의합니다. 즉, 그가 같은 팀의 더블 경기에서 남자와 여자를 득점하면 경기가 혼합되어 있습니다. 단순한 경기의 경우 남자가 여자를 향할 수는 없지만, 두 남자로 구성된 팀이 두 여자로 구성된 팀을 대면한다는 두 배로는 금지되어 있지 않습니다.
가설 2 :
우리는 언론인과 주최자를위한 신청서가 하나 뿐이며 두 개의 별도 응용 프로그램이 아닙니다. 따라서 우리는 홈페이지와 경기가 끝나는 것을 볼 수있는 페이지를 보유하고 있으며, 다른 작업 (예 : 플레이어 추가, 계획 매치 등)은 연결 후에 만 액세스 할 수 있습니다 (사용 된 안전에 대한 자세한 내용은 보고서의 보안 부분을 참조하십시오).
가설 3 :
우리는 경기가 최대 4 시간 동안 지속될 수 있다고 가정했다. 우리는 코스가 새 경기를 위해 선택하기 전에 무료인지 확인하는 기능을 추가했습니다. 따라서 우리는 같은 코스에서 동시에 두 개의 다른 게임을 동시에 재생할 수 없도록 할 수 있습니다. 최대 4 시간의 최대 기간을 통해 경기가 계획되어 있지만 새 경기가 시작되기 4 시간 전에 아직 끝나지 않은 경우에도 코스를 선택할 수 있도록 한도를 제한 할 수 있습니다.
이 프로젝트를 수행하기 위해 우리는 민첩한 방법을 사용하여 조직을 조직했습니다.
프로젝트가 시작될 때 다음 응용 프로그램의 사용자 계정을 작성했습니다.
이것은 다음과 같은 유스 케이스 다이어그램에 해당합니다.
그런 다음 이러한 사용자 스토리를 개발 작업으로 나눕니다.
각 세션은 스프린트에 해당했습니다. 우리는 세션이 시작될 때 회의를 통해 프로젝트의 일부가되어야하는 작업을 결정했습니다. 작업을 용이하게하기 위해 Github (아울렛, 요청 스웨터 및 Kanban 테이블)과 통합 된 프로젝트 관리 도구를 사용했습니다.
작업은 결과로 표시되었으며 공동 작업자에게 할당 할 수 있습니다. 작업의 진행 상황에 이어 Kanban 테이블에 매장이있었습니다. 직원이 작업을 마치면 관련 요청 스웨터를 만들어 코드 검토를 위해 제출했습니다.
워크 플로는 다음과 같습니다.
JSTL : 가석방, 루프 및 국제화와 같은 현재 작업에 대한 비콘 라이브러리를 추가하여 JEE 플랫폼의 구성 요소.
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 (Specification) / Hibernate (구현)는 관계형 데이터베이스 관리 시스템에서 Java (EJB Entity) 객체를 직렬화하고 earialize 할 수있는 ORM입니다.
우리는 인터페이스에 의해 설명 된 서비스 계약에 의해 서로 분리 된 다른 레이어로 구성된 "양파"아키텍처라고도 불리는 소위 "깨끗한 건축"아키텍처를 사용했습니다. 요청이 도착하면 먼저 컨트롤러가 처리하여 데이터로부터 개체를 빌드 한 다음 비즈니스 로직이 포함 된 서비스 계층을 통과합니다. 서비스 계층은 데이터베이스와의 상호 작용을 포함하는 Restitory 계층을 요구합니다. Restitory 레이어는 데이터 모델의 엔터티 클래스를 사용합니다.
우리의 응용 프로그램에서 각 층은 다음 구성 요소에 해당합니다.
우리는 응용 프로그램 구성 요소간에 커플 링이 적을 수 있도록 Java Beans 회사가 허용하는 종속성 주입 메커니즘뿐만 아니라 인터페이스 프로그래밍을 사용했습니다.
데이터베이스에 사용자 비밀번호를 명확하게 저장하지 않도록주의를 기울였습니다. 따라서 후자가 해킹되면 공격자는 암호에 액세스 할 수 없습니다. 우리는 BCrypt 소금에 절인 해시 알고리즘으로 암호를 자르기로 선택했습니다. 왜냐하면 그것이 문제의 표준이기 때문입니다. 이를 위해 Java의 알고리즘을 구현하는 프로젝트 (Maven을 통해)에서 JBCrypt 라이브러리를 가져 왔습니다.
응용 프로그램에서 대부분의 도로는 인증 된 사용자 만 액세스 할 수 있어야합니다. 따라서 사용자를 인증하기 위해 인증 페이지를 설정했습니다. HTTP 세션을 사용하여 인증 된 사용자 프로필을 저장합니다.
보호 도로에서 사용자를 허용하기 위해 권한 부여 HTTP 필터를 설정하여 현재 HTTP 세션에 인증 된 사용자 프로필이 포함되어 있는지 확인합니다. 그렇다면 필터를 사용하면 사용자를 허용합니다. 그렇지 않으면 연결 페이지로 리디렉션됩니다.
우리는 모델링 중에 정의한 것처럼 비즈니스 클래스 (프로젝트 패키지의 엔터티)를 만들어 프로젝트 구현을 시작했습니다. 그런 다음 클래스와 인터페이스를 만들어 데이터베이스 (Restitories 패키지)에 액세스 할 수 있습니다. 마지막으로, 우리는 프로젝트를 일관성있게 유지하기위한 특정 계약에 동의하기 위해 응용 프로그램을 모두 함께 식별 할 가능성을 구현했습니다. 이러한 단계가 완료되면 모든 사람에게 특정 수의 사용자 스토리를 제공함으로써 작업을 나누었습니다. 모든 사용자 스토리가 수행 될 때까지 작업이 수행되었습니다.
사용자 스토리를 제외한 대부분의 사용자 스토리는 쉽게 만들어졌습니다. 경기 준비. 초기 애플리케이션 모델링 동안, 우리는 플레이어를 경기에 연결하는“많은 사람들과 많은”링크를 제대로 표현하지 못했으며 팀을 대표하는 수업에 매료되지 않습니다 (프로젝트의 참여 수업). 따라서 준비 단계에서 플레이어를 게임에 추가하려고 할 때 예외가 시작되었고 경기 준비가 완료되지 않았습니다. “많은 것들에 대한 많은”관계의 기능을 더 자세히 살펴본 후 우리는 플레이어를 경기와 적절하게 연관시키기 위해 중간 클래스 (여기에서 참여)를 거치지 않고 동일한 두 클래스 (게임에 항상 두 팀이 있기 때문에 플레이어를 게임에 연결하는 두 가지 관계) 사이 에서이 유형의 두 가지 관계를 만드는 것이 불가능하다는 것을 깨달았습니다. 따라서 우리는 새로운 구현을 올바르게 모델링하고 경기 및 플레이어 비즈니스 클래스를 수정하고 응용 프로그램을 완벽하게 작동시키기 위해 참여 클래스를 추가하기 위해 클래스 다이어그램을 수정해야했습니다.
두 번째 어려움은 특히 사용자 스토리에 관한 것이 아니라 데이터 인코딩 문제에 관한 것이 었습니다. 모든 사용자 스토리를 마친 후 다양한 테스트 중에 및 개선 중에 우리는 일반적으로 UTF8에서 지원하는 악센트가 데이터베이스에 제대로 저장되지 않았 음을 알았습니다. 실제로,베이스의 모든 악센트 문자는 다른 형식으로 교체되었습니다. 인터넷을 살펴본 후, 우리는 문제가 Wildfly에서 나온 것을 이해했으며,이를 해결하기 위해서는 Servlet 컨테이너의 인코딩을 Wildfly 구성에서 변경해야했습니다. 이렇게하려면 Wildfly 구성으로 이동하여 UTF-8에 의해 서블릿 컨테이너의 기본 인코딩 설정을 수정해야했습니다.
또한 날짜 형식 관리에 문제가 발생했습니다. 비즈니스 클래스에서 LocalDate 유형 (Java의 최신 날짜 API)을 사용하여 예를 들어 매치 예정일을 저장합니다. 이제 JSTL은 기존 Java Date API를 사용하기 때문에 이러한 유형의 날짜를 형식화하는 기능이 없습니다. 따라서 날짜가 표시된 JSP 페이지에서 핸드 포맷을 수행해야했습니다 (예 : ConsondMatches.jsp 페이지 에서이 형식을 볼 수 있습니다).
이러한 어려움이 극복되면 응용 프로그램을 개선하고 사소한 버그 조정에 집중할 수있었습니다.
이 프로젝트에서 우리는 Jakarta EE와 함께 비즈니스 응용 프로그램 개발을 소개했습니다. 그들 중 일부는 이미 서버 측에서 서버에서 경험이 있었지만이 프로젝트는 플랫폼 개발 표준을 적절히 적절하게 할 수있었습니다.
우리는 매우 풍부한 API를 제공하는 ORM JPA 기술에 대한 기술을 설정할 수있었습니다. "많은 것"관계와 같은 특정 메커니즘은 우리에게 어려움을 겪었지만 우리는 그것들을 극복해야합니다.
마지막으로,이 프로젝트의 공동 작업 측면은 그 강점 중 하나입니다. 실제로, 상호 동기는 모든 유형의 난이도를 극복 할 수있는 강력한 엔진입니다. 이를 통해 가장 효율적인 방법으로 협력하기 위해 다른 모듈에서 획득 한 민첩한 프로젝트 관리 기술을 적용 할 수있는 기회가 제공되었습니다.
