efrei m1 jakartaee projet
1.0.0
Turnamen Rolland Garos adalah turnamen tenis internasional.
Kembangkan manajemen web pertandingan di turnamen Rolland Garos.
Peran fungsional dari proyek ini aplikasi harus memungkinkan untuk merencanakan pertandingan dan merencanakan pemain mana yang akan berpartisipasi, wasit mana yang akan mengawasinya. Kemudian, Anda harus dapat menginformasikan hasil pertandingan (skor masing -masing tim). Pengunjung harus dapat berkonsultasi dengan hasil pertandingan yang sudah selesai.
Saat melaksanakan proyek kami, kami membuat beberapa asumsi tentang operasi yang kami bayangkan untuk aplikasi kami, dan untuk menjamin konsistensi yang terakhir:
Hipotesis 1:
Seorang penyelenggara mendefinisikan dirinya sendiri jika pertandingan ganda adalah pertandingan pria, wanita atau campuran ketika ia mencetak gol pemain dalam pertandingan. Artinya jika dia mencetak gol dalam pertandingan ganda seorang pria dan seorang wanita di tim yang sama, pertandingan dicampur. Untuk pertandingan sederhana tidak mungkin bagi seorang pria untuk menghadapi seorang wanita, namun ia tidak dilarang untuk ganda bahwa tim yang terdiri dari dua pria menghadapi tim dua wanita.
Hipotesis 2:
Kami hanya memiliki satu aplikasi untuk jurnalis dan penyelenggara dan bukan dua aplikasi terpisah. Jadi kami memiliki halaman beranda serta halaman yang memungkinkan Anda untuk melihat pertandingan selesai, dan tindakan lainnya (seperti menambahkan pemain, pertandingan perencanaan, dll.) Hanya dapat diakses setelah koneksi (untuk mengetahui lebih lanjut tentang keamanan yang digunakan, lihat bagian keamanan dari laporan).
Hipotesis 3:
Kami berhipotesis bahwa pertandingan dapat bertahan maksimal 4 jam. Kami telah menambahkan fitur yang memeriksa bahwa kursus gratis sebelum kami dapat memilihnya untuk kecocokan baru. Karena itu kami dapat memastikan bahwa dua game yang berbeda tidak dapat dimainkan pada saat yang sama pada kursus yang sama. Durasi maksimum 4 jam memungkinkan kita untuk membatasi agar dapat memilih kursus, bahkan jika kecocokan direncanakan, tetapi belum selesai 4 jam sebelum dimulainya pertandingan baru.
Untuk melaksanakan proyek ini, kami mengatur diri kami menggunakan metode Agile.
Pada awal proyek, kami menulis akun pengguna dari aplikasi berikut:
Ini sesuai dengan diagram kasus penggunaan berikut:
Kami kemudian membagi cerita pengguna ini menjadi tugas pengembangan.
Setiap sesi berkorespondensi dengan sprint: kami melakukan pertemuan di awal sesi untuk menentukan tugas mana yang harus menjadi bagian dari proyek. Untuk memfasilitasi tugas, kami menggunakan alat manajemen proyek yang terintegrasi dengan GitHub: outlet, sweter permintaan dan tabel Kanban.
Tugas -tugas tersebut diwakili oleh hasil, yang dapat ditugaskan ke kolaborator. Kemajuan tugas diikuti dengan memiliki outlet di meja Kanban. Ketika seorang karyawan telah menyelesaikan tugas, mereka membuat sweater permintaan terkait, dan mengirimkannya untuk tinjauan kode.
Alur kerja adalah sebagai berikut:
JSTL: Komponen platform JEE untuk memperluas spesifikasi JSP dengan menambahkan perpustakaan suar untuk tugas saat ini, seperti pekerjaan pembebasan bersyarat, loop dan internasionalisasi.
MariaDB : Implémentation Open Source du Système de Gestion de
Base de Données Relationnel MySQL.
Jakartaee: Spesifikasi Open Source Java EE. Kami menggunakan JSP khususnya, wadah servlet, EJB dan JPA.
Bootstrap est un framework CSS permettant de facilement implémenter des styles
prédéfinis
Wildfly (sebelumnya JBoss) adalah server aplikasi open source yang menerapkan spesifikasi 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 (Spesifikasi) / Hibernate (Implementasi) adalah ORM yang memungkinkan Anda untuk membuat serial dan dearialize objek Java (EJB Entity) dalam sistem manajemen database relasional.
Kami menggunakan arsitektur "arsitektur bersih" yang disebut SO yang juga disebut arsitektur "bawang", terdiri dari lapisan yang berbeda, dipisahkan satu sama lain dengan kontrak layanan yang dijelaskan oleh antarmuka. Ketika sebuah permintaan tiba, pertama kali diproses oleh pengontrol, untuk membangun objek dari data, kemudian melewati lapisan layanan yang berisi logika bisnis. Lapisan layanan panggilan untuk lapisan pemulihan yang berisi interaksi dengan database. Lapisan pemulihan menggunakan kelas entitas model data.
Dalam aplikasi kami, setiap lapisan sesuai dengan komponen berikut:
Kami menggunakan pemrograman antarmuka serta mekanisme injeksi dependensi yang diizinkan oleh perusahaan Java Beans untuk memiliki kopling rendah antara komponen aplikasi.
Kami berhati -hati untuk tidak menyimpan kata sandi pengguna di Clear di database. Jadi, jika yang terakhir akan diretas, para penyerang tidak akan memiliki akses ke kata sandi. Kami telah memilih untuk memotong kata sandi dengan algoritma hash asin bcrypt, karena itu adalah standar dalam masalah ini. Untuk melakukan ini, kami mengimpor Perpustakaan JBCrypt dalam proyek kami (via Maven) yang mengimplementasikan algoritma di Java.
Dalam aplikasi, sebagian besar jalan hanya boleh diakses oleh pengguna yang diautentikasi. Karena itu kami telah mengatur halaman otentikasi untuk mengotentikasi pengguna. Kami menggunakan sesi HTTP untuk menyimpan profil pengguna yang diautentikasi.
Untuk mengizinkan pengguna di jalan yang dilindungi, kami telah mengatur filter HTTP otorisasi, yang memeriksa apakah sesi HTTP saat ini berisi profil pengguna yang diautentikasi. Jika demikian, filter memungkinkan pengguna, jika tidak ia mengarahkannya ke halaman koneksi.
Kami memulai implementasi proyek dengan menciptakan kelas bisnis (entitas paket proyek kami) karena kami telah mendefinisikannya selama pemodelan. Kami kemudian membuat kelas, dan antarmuka, memungkinkan kami untuk mengakses database (paket resitori). Akhirnya, kami telah menerapkan kemungkinan mengidentifikasi dengan aplikasi kami bersama -sama untuk menyetujui perjanjian tertentu agar proyek kami tetap koheren. Setelah langkah -langkah ini selesai, kami membagi pekerjaan, dengan memberi semua orang sejumlah cerita pengguna untuk dilakukan, pekerjaan itu dilakukan sampai semua cerita pengguna dilakukan.
Sebagian besar cerita pengguna mudah dibuat, kecuali cerita pengguna: Siapkan kecocokan. Selama pemodelan aplikasi awal kami, kami telah dengan buruk mewakili tautan "banyak hingga banyak" yang menghubungkan para pemain ke pertandingan, kami tidak terpesona oleh kelas yang mewakili tim (kelas partisipasi dalam proyek kami). Jadi ketika kami mencoba menambahkan pemain ke game selama fase persiapan, pengecualian diluncurkan dan persiapan pertandingan tidak dilakukan. Setelah melihat lebih detail fungsi dari hubungan "banyak ke banyak", kami menyadari bahwa tidak mungkin untuk membuat dua hubungan jenis ini antara dua kelas yang sama (di sini dua hubungan yang menghubungkan para pemain dengan permainan, karena selalu ada dua tim) tanpa melalui kelas menengah (di sini partisipasi) agar dapat dengan tepat mengaitkan para pemain dengan pertandingan. Oleh karena itu kami harus memodifikasi diagram kelas kami agar dapat memodelkan implementasi baru kami dengan benar, serta memodifikasi kelas pertandingan dan kelas bisnis dan menambahkan kelas partisipasi untuk membuat aplikasi kami bekerja dengan sempurna.
Kesulitan kedua yang dihadapi tidak menyangkut kisah pengguna pada khususnya, tetapi masalah pengkodean data. Setelah menyelesaikan semua cerita pengguna kami, selama berbagai tes kami, dan selama perbaikan kami, kami memperhatikan bahwa aksen, biasanya didukung oleh UTF8, tidak disimpan dengan benar dalam database. Memang, semua karakter aksen di pangkalan diganti dalam format lain. Setelah melihat internet, kami memahami bahwa masalahnya berasal dari Wildfly, dan untuk menyelesaikannya, kami hanya harus mengubah pengkodean wadah servlet dalam konfigurasi Wildfly. Untuk melakukan ini, kami hanya harus pergi ke konfigurasi Wildfly dan memodifikasi pengaturan pengkodean default dari wadah servlet oleh UTF-8.
Kami juga mengalami masalah dengan manajemen format tanggal. Kami menggunakan tipe LocalDate (API tanggal terbaru di Java) di kelas bisnis kami, untuk menyimpan tanggal yang dijadwalkan pertandingan misalnya. Sekarang JSTL tidak memiliki fungsi untuk memformat jenis tanggal ini, karena masih menggunakan API tanggal Java lama. Karena itu kami harus melakukan pemformatan tangan di halaman JSP yang menampilkan tanggal (Anda dapat melihat pemformatan ini di halaman ConsultMatches.jsp misalnya).
Setelah kesulitan ini diatasi, kami dapat fokus pada peningkatan aplikasi kami dan menyesuaikan bug minor.
Selama proyek ini, kami diperkenalkan dengan pengembangan aplikasi bisnis dengan Jakarta EE. Meskipun beberapa dari mereka sudah memiliki pengalaman di server di sisi server, proyek ini adalah untuk kesempatan untuk sesuai dengan standar pengembangan platform
Kami benar -benar dapat mengatur keterampilan pada teknologi ORM JPA yang menawarkan API yang sangat kaya sangat kuat. Mekanisme tertentu seperti hubungan "banyak untuk banyak" telah memberi kita kesulitan tetapi kita harus mengatasinya.
Akhirnya, aspek kolaboratif dari proyek ini adalah salah satu kekuatannya. Memang, motivasi timbal balik adalah mesin yang kuat yang memungkinkan Anda untuk mengatasi segala jenis kesulitan. Ini juga memberi kami kesempatan untuk menerapkan keterampilan manajemen proyek yang gesit yang diperoleh dalam modul lain, untuk berkolaborasi dengan cara yang seefisien mungkin.
