efrei m1 jakartaee projet
1.0.0
Rolland Garos Tournamentは、国際的なテニストーナメントです。
Rolland Garos Tournamentで試合のWeb管理を開発します。
プロジェクトの機能的役割アプリケーションは、プレイヤーが参加する試合と計画を計画し、審判が監督することを可能にするはずです。次に、試合の結果（各チームのスコア）を通知できる必要があります。訪問者は、完成した試合の結果を参照できるはずです。
プロジェクトを実行するとき、私たちはアプリケーションのために想像した操作について、また後者の一貫性を保証するために、いくつかの仮定を立てました。
仮説1：
オーガナイザーは、ダブルマッチが試合で選手を獲得したときに男性、女性、または混合試合であるかどうかを定義します。つまり、彼が同じチームの男性と女性をダブルマッチで得点した場合、試合は混ざっています。簡単な試合では、男性が女性に直面することは不可能ですが、2人の男性のチームが2人の女性のチームに直面していることを2倍にすることは禁止されていません。
仮説2：
ジャーナリストと主催者向けのアプリケーションは1つだけで、2つの別々のアプリケーションはありません。そのため、ホームページと、試合が終了するのを見ることができるページがあり、他のアクション（プレイヤーの追加、試合の計画など）は、接続後にのみアクセスできます（使用される安全性について詳しく調べるには、レポートのセキュリティ部分を参照）。
仮説3：
試合は最大4時間持続する可能性があると仮定しました。新しい試合に合わせて選択する前に、コースが無料であることをチェックする機能を追加しました。したがって、同じコースで2つの異なるゲームを同時にプレイできないようにすることができます。 4時間の最大期間により、試合が計画されていても、新しい試合の開始の4時間前にまだ終了していない場合でも、コースを選択できるように制限を設けることができます。
このプロジェクトを実行するために、アジャイルメソッドを使用して自分自身を整理しました。
プロジェクトの開始時に、次のアプリケーションのユーザーアカウントを書きました。
これは、次のユースケース図に対応しています。
次に、これらのユーザーストーリーを開発タスクに分割しました。
各セッションはスプリントに対応していました。セッションの開始時に会議を行い、どのタスクがプロジェクトの一部であるべきかを決定しました。タスクを容易にするために、GitHubに統合されたプロジェクト管理ツール：アウトレット、リクエストセーター、およびカンバンテーブルを使用しました。
タスクは結果によって表され、コラボレーターに割り当てることができます。タスクの進捗状況に続いて、カンバンテーブルにアウトレットが付いていました。従業員がタスクを終了したとき、彼らは関連するリクエストセーターを作成し、コードレビューのためにそれを提出しました。
ワークフローは次のとおりでした：
JSTL：JEEプラットフォームのコンポーネントで、PAROLE、ループ、国際化の作業など、現在のタスクにビーコンのライブラリを追加して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（仕様） / hibernate（実装）は、リレーショナルデータベース管理システムでJava（EJBエンティティ）オブジェクトをシリアル化およびDearializeすることを可能にするORMです。
インターフェイスで説明されているサービス契約によって互いに切り離されたさまざまなレイヤーで構成される「タマネギ」アーキテクチャとも呼ばれる、SO -Calcaledの「クリーンアーキテクチャ」アーキテクチャを使用しました。リクエストが届くと、最初にコントローラーによって処理され、データからオブジェクトを構築するために、ビジネスロジックを含むサービスレイヤーを通過します。サービスレイヤーは、データベースとの相互作用を含む残りのレイヤーを必要とします。残りのレイヤーは、データモデルのエンティティのクラスを使用します。
当社のアプリケーションでは、各レイヤーは次のコンポーネントに対応しています。
インターフェイスプログラミングと、アプリケーションコンポーネント間のカップリングが低いために、Java Beans企業が許可する依存関係の注入メカニズムを使用しました。
ユーザーパスワードをデータベースにクリアしないように注意しています。したがって、後者がハッキングされた場合、攻撃者はパスワードにアクセスできません。それが問題の標準であるため、Bcryptの塩漬けハッシュアルゴリズムでパスワードをチョップすることを選択しました。これを行うために、Javaのアルゴリズムを実装するプロジェクト（Maven経由）にJBCryptライブラリをインポートしました。
アプリケーションでは、ほとんどの道路は、認証されたユーザーがのみアクセスできる必要があります。したがって、ユーザーを認証するために認証ページを設定しました。 HTTPセッションを使用して、認証されたユーザープロファイルを保存します。
保護された道路でユーザーを許可するために、現在のHTTPセッションに認証されたユーザープロファイルが含まれているかどうかを確認する承認HTTPフィルターを設定しました。その場合、フィルターはユーザーを許可します。それ以外の場合は、接続ページにリダイレクトします。
モデリング中に定義したように、ビジネスクラス（プロジェクトパッケージのエンティティ）を作成することにより、プロジェクトの実装を開始しました。次に、クラスとインターフェイスを作成し、データベース（Restitoriesパッケージ）にアクセスできるようにしました。最後に、プロジェクトを一貫した保持するための特定の契約に同意するために、アプリケーションをすべて一緒に識別する可能性を実装しました。これらの手順が完了したら、すべての数のユーザーストーリーを提供することにより、作業を分割しました。すべてのユーザーストーリーが実行されるまで作業は行われました。
ユーザーストーリーを除いて、ほとんどのユーザーストーリーは簡単に作成されました。最初のアプリケーションモデリング中に、プレイヤーを試合につなぐ「多くの多くの」リンクを不十分に表現していましたが、チームを代表するクラス（プロジェクトへの参加クラス）に魅了されません。そのため、準備フェーズ中にプレイヤーをゲームに追加しようとすると、例外が起動され、試合の準備は行われませんでした。 「多くの多くの」関係の機能をより詳細に調べた後、私たちは、同じ2つのクラスの間でこのタイプの2つの関係を作ることが不可能であることに気付きました（ここでは、プレイヤーを常に2つのチームがあるため、2つのチームが常に2つのチームがあるためです。したがって、新しい実装を適切にモデル化するためにクラス図を変更し、マッチとプレーヤーのビジネスクラスを変更し、アプリケーションを完全に機能させるために参加クラスを追加できるようにする必要がありました。
遭遇する2番目の難しさは、特にユーザーストーリーではなく、問題をエンコードする問題に関係していました。すべてのユーザーストーリーを完了した後、さまざまなテスト中、および改善中に、通常はUTF8によってサポートされているアクセントがデータベースに適切に保存されていないことに気付きました。実際、ベースのすべてのアクセント文字は別の形式で置き換えられました。インターネットを見た後、問題はWildflyから来たことを理解し、それを解決するために、Wildfly構成のサーブレット容器のエンコードを変更する必要がありました。これを行うには、Wildfly構成に移動し、UTF-8でサーブレットコンテナのデフォルトのエンコード設定を変更する必要がありました。
また、日付形式の管理に問題が発生しました。たとえば、マッチのスケジュールされた日付を保存するために、ビジネスクラスのLocalDateタイプ（Javaの最新のAPI）を使用します。 JSTLには、古いJava Date APIを使用しているため、このタイプの日付をフォーマットする機能がありません。したがって、日付を表示するJSPページでハンドフォーマットを実行する必要がありました（たとえば、このフォーマットをConsultMatches.jspページで表示できます）。
これらの困難が克服されると、アプリケーションの改善とマイナーなバグの調整に集中することができました。
このプロジェクトでは、Jakarta EEとのビジネスアプリケーション開発を紹介されました。それらのいくつかはすでにサーバー側のサーバーで経験を持っていましたが、このプロジェクトはプラットフォーム開発基準を私たちに適切にする機会のためでした
非常に豊富なAPIを提供するORM JPAテクノロジーのスキルをセットアップすることができました。 「多くの多くの」関係などの特定のメカニズムは、私たちに困難を与えてくれましたが、私たちはそれらを克服しなければなりません。
最後に、このプロジェクトの共同の側面はその強みの1つです。実際、相互の動機は、あらゆる種類の困難を克服できる強力なエンジンです。これにより、可能な限り最も効率的な方法で協力するために、他のモジュールで取得したアジャイルプロジェクト管理スキルを適用する機会も与えられました。
