efrei m1 jakartaee projet
1.0.0
بطولة Rolland Garos هي بطولة تنس دولية.
تطوير إدارة الويب للمباريات في بطولة رولاند جاروس.
الدور الوظيفي للمشروع ، يجب أن يجعل التطبيق من الممكن التخطيط للمباريات والتخطيط الذي سيشارك فيه اللاعبون ، والتي سيشرف عليها الحكم. بعد ذلك ، يجب أن تكون قادرًا على إبلاغ نتائج المباراة (عشرات كل فريق). يجب أن يكون الزوار قادرين على استشارة نتائج المباريات النهائية.
عند تنفيذ مشروعنا ، وضعنا العديد من الافتراضات حول العملية التي تخيلناها لتطبيقنا ، ومن أجل ضمان اتساق الأخير:
الفرضية 1:
يعرّف المنظم نفسه إذا كانت المباريات المزدوجة من الذكور أو الإناث أو المباريات المختلطة عندما سجل اللاعبين في المباراة. وهذا يعني أنه إذا سجل في مباراة مزدوجة رجل وامرأة في نفس الفريق ، فإن المباراة مختلطة. بالنسبة للمباريات البسيطة ، لا يمكن للرجل مواجهة امرأة ، ومع ذلك لا يحظر على الزوجي أن يواجه فريق من رجلين فريقًا من امرأتين.
الفرضية 2:
لدينا طلب واحد فقط للصحفيين والمنظمين وليس تطبيقين منفصلين. لذلك لدينا صفحة رئيسية بالإضافة إلى صفحة تسمح لك بمشاهدة المباريات المنتهية ، وتكون الإجراءات الأخرى (مثل إضافة اللاعبين ، ومباريات التخطيط ، وما إلى ذلك) يمكن الوصول إليها إلا بعد الاتصال (لمعرفة المزيد عن السلامة المستخدمة ، راجع الجزء الأمات من التقرير).
الفرضية 3:
افترضنا أن المباريات يمكن أن تستمر بحد أقصى 4 ساعات. لقد أضفنا ميزة تتحقق من أن الدورة التدريبية مجانية قبل أن نتمكن من تحديدها لمباراة جديدة. لذلك يمكننا التأكد من أنه لا يمكن لعب مباراتين مختلفين في نفس الوقت في نفس المسار. يتيح لنا الحد الأقصى لمدة 4 ساعات وضع حد لكي نكون قادرين على اختيار دورة ، حتى لو تم التخطيط لمباراة ، ولكن لم ينته بعد 4 ساعات قبل بدء المباراة الجديدة.
لتنفيذ هذا المشروع ، قمنا بتنظيم أنفسنا باستخدام طريقة Agile.
في بداية المشروع ، كتبنا حسابات المستخدمين للتطبيق التالي:
هذا يتوافق مع مخطط حالة الاستخدام التالي:
ثم قمنا بتقسيم قصص المستخدم هذه إلى مهام التطوير.
تتوافق كل جلسة مع سباق العدو: لقد عقدنا اجتماعًا في بداية الجلسة لتحديد المهام التي يجب أن تكون جزءًا من المشروع. لتسهيل المهمة ، استخدمنا أدوات إدارة المشروع المدمجة مع Github: المنافذ ، سترة الطلب وطاولة Kanban.
تم تمثيل المهام بالنتائج ، والتي يمكن تعيينها لمتعاون. وأعقب تقدم المهام وجود منافذ على طاولة كانبان. عندما أنهى الموظف مهمة ، قاموا بإنشاء سترة طلب مرتبطة ، وقدموها لمراجعة رمز.
كان سير العمل على النحو التالي:
JSTL: مكون من منصة JEE لتوسيع مواصفات JSP عن طريق إضافة مكتبة من المنارات للمهام الحالية ، مثل العمل على الإفراج المشروط والحلقات والتدويل.
MariaDB : Implémentation Open Source du Système de Gestion de
Base de Données Relationnel MySQL.
جاكارتاي: مواصفات المصدر المفتوح لـ Java EE. نستخدم JSP على وجه الخصوص ، حاويات Servlet ، 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 (المواصفات) / السبات (التنفيذ) هو ORM الذي يسمح لك بتسلسل كائنات JAVA (كيان EJB) في نظام إدارة قاعدة البيانات العلائقية.
استخدمنا بنية "العمارة النظيفة" التي تسمى SO أيضًا تسمى بنية "البصل" ، والتي تتكون من طبقات مختلفة ، مفصول عن بعضها البعض من خلال عقود الخدمة الموصوفة في الواجهات. عند وصول الطلب ، تتم معالجته أولاً بواسطة وحدة التحكم ، لإنشاء كائنات من البيانات ، ثم يمر عبر طبقة الخدمة التي تحتوي على منطق العمل. تدعو طبقة الخدمة إلى طبقة الحفلات التي تحتوي على تفاعلات مع قاعدة البيانات. تستخدم طبقة الحافظة فئات كيانات نموذج البيانات.
في تطبيقنا ، كل طبقة تتوافق مع المكونات التالية:
استخدمنا برمجة الواجهة بالإضافة إلى آلية حقن التبعيات التي تسمح بها شركات Java Beans من أجل الحصول على اقتران منخفض بين مكونات التطبيق.
لقد كنا حريصين على عدم تخزين كلمات مرور المستخدم في قاعدة البيانات. وبالتالي ، إذا تم اختراق الأخير ، فلن يتمكن المهاجمون من الوصول إلى كلمات المرور. لقد اخترنا تقطيع كلمات المرور باستخدام خوارزمية التجزئة المملحة BCrypt ، لأنها المعيار في هذه المسألة. للقيام بذلك ، قمنا باستيراد مكتبة JBCrypt في مشروعنا (عبر Maven) الذي ينفذ الخوارزمية في Java.
في التطبيق ، يجب الوصول إلى معظم الطرق فقط من قبل مستخدم مصادق عليه. لذلك قمنا بإعداد صفحة مصادقة لمصادقة المستخدم. نستخدم جلسة HTTP لتخزين ملف تعريف المستخدم المصادق عليه.
للسماح للمستخدم على الطرق المحمية ، قمنا بإعداد مرشح ترخيص HTTP ، والذي يتحقق مما إذا كانت جلسة HTTP الحالية تحتوي على ملف تعريف مستخدم مصادق عليه. إذا كان الأمر كذلك ، يسمح المرشح للمستخدم ، وإلا فإنه يعيد توجيهه إلى صفحة الاتصال.
لقد بدأنا تنفيذ المشروع من خلال إنشاء فصول أعمال (كيانات حزمة المشروع الخاصة بنا) كما حددناها أثناء النمذجة. ثم أنشأنا الفئات ، والواجهات ، مما يسمح لنا بالوصول إلى قاعدة البيانات (حزم التثبيت). أخيرًا ، قمنا بتنفيذ إمكانية التعرف على تطبيقنا معًا من أجل الاتفاق على بعض الاتفاقيات للحفاظ على مشروعنا متماسكًا. بمجرد الانتهاء من هذه الخطوات ، قمنا بتقسيم العمل ، من خلال منح الجميع عددًا معينًا من قصص المستخدم التي يتعين القيام بها ، تم القيام بذلك حتى يتم تنفيذ جميع قصص المستخدم.
تم صنع معظم قصص المستخدم بسهولة ، باستثناء قصة المستخدم: قم بإعداد مباراة. خلال نمذجة التطبيق الأولية لدينا ، قمنا بتمثيل "العديد من الروابط الكثيرة" التي تربط اللاعبين بالمباريات ، نحن لسنا مفتونين بفصل يمثل الفرق (فصول المشاركة في مشروعنا). لذلك عندما نحاول إضافة لاعبين إلى ألعاب خلال مرحلة التحضير ، تم إطلاق استثناء ولم يتم إعداد المباراة. بعد أن نظرت بمزيد من التفصيل ، فإن أداء العلاقات "الكثيرين للعديد" ، أدركنا أنه كان من المستحيل إجراء علاقتين من هذا النوع بين نفس الفئتين (هنا علاقتان يربطان اللاعبين بالألعاب ، لأن هناك دائمًا فريقان) دون أن يمروا بفصل وسيطة (هنا المشاركة) حتى تتمكن من ربط اللاعبين بشكل صحيح بالمباريات. لذلك ، اضطررنا إلى تعديل الرسم البياني الخاص بنا من أجل أن نكون قادرين على تصميم تنفيذنا الجديد بشكل صحيح ، بالإضافة إلى تعديل فصول الأعمال واللاعبين وإضافة فئة المشاركة من أجل جعل تطبيقنا يعمل بشكل مثالي.
الصعوبة الثانية التي واجهتها لم تهم قصة المستخدم على وجه الخصوص ، ولكن مشكلة تشفير البيانات. بعد الانتهاء من جميع قصص المستخدمين لدينا ، خلال اختباراتنا المختلفة ، وخلال التحسينات ، لاحظنا أن لهجات ، التي تدعمها عادة UTF8 ، لم يتم تخزينها بشكل صحيح في قاعدة البيانات. في الواقع ، تم استبدال جميع الشخصيات لهجة في القاعدة بتنسيق آخر. بعد النظر إلى الإنترنت ، فهمنا أن المشكلة جاءت من Wildfly ، وحلها ، لذلك اضطررنا ببساطة إلى تغيير ترميز حاوية Servlet في تكوين الألياف البرية. للقيام بذلك ، كان علينا فقط الذهاب إلى تكوين Wildfly وتعديل إعدادات الترميز الافتراضية لحاوية Servlet بواسطة UTF-8.
لقد واجهنا أيضًا مشاكل في إدارة تنسيق التواريخ. نحن نستخدم نوع LocalDate (أحدث API Date في Java) في درجة الأعمال لدينا ، لتخزين التاريخ المقرر للمباراة على سبيل المثال. الآن لا يوجد لدى JSTL وظيفة لتنسيق هذا النوع من التواريخ ، لأنه لا يزال يستخدم واجهة برمجة تطبيقات تاريخ Java القديم. لذلك ، اضطررنا إلى إجراء تنسيق يدوي في صفحات JSP التي تعرض التواريخ (يمكنك الذهاب رؤية هذا التنسيق في صفحة الاستشارات. jsp على سبيل المثال).
بمجرد التغلب على هذه الصعوبات ، تمكنا من التركيز على تحسين تطبيقنا وضبط الأخطاء البسيطة.
خلال هذا المشروع ، تعرفنا على تطوير تطبيقات الأعمال مع Jakarta EE. على الرغم من أن بعضًا من بعضهم كان لديه بالفعل خبرة على الخادم على جانب الخادم ، إلا أن هذا المشروع كان لهذا المناسبة لتولينا معايير تطوير النظام الأساسي
لقد تمكنا بشكل ملحوظ من إنشاء مهارات على تقنية ORM JPA التي تقدم واجهة برمجة تطبيقات غنية للغاية قوية. لقد منحتنا بعض الآليات مثل العلاقات "الكثيرة للعديد من" الصعوبات ، لكن علينا التغلب عليها.
أخيرًا ، الجانب التعاوني لهذا المشروع هو أحد نقاط قوته. في الواقع ، الدافع المتبادل هو محرك قوي يسمح لك بالتغلب على أي نوع من الصعوبة. وقد أتاح لنا ذلك أيضًا الفرصة لتطبيق مهارات إدارة المشاريع Agile التي تم الحصول عليها في وحدات أخرى ، من أجل التعاون بأكثر الطرق كفاءة ممكنة.
