كيفاش تحول Workflow ديال البيزنس لـ Use Cases واضحة

من الـ Workflow للمنطق (Logic)

بزاف ديال المشاكل فالسوفتوير كتجي حيت كنحولو عملية ديال البيزنس (Business Process) اللي ما واضحاش نيشان للكود بلا ما نبينو القواعد اللي مخبية. الـ Workflow هو الترتيب ديال الخطوات اللي كدير الشركة؛ أما الـ Use Case فهي التفاعل اللي كيوقع بين Actor (فاعل) والسيستيم باش يوصل لواحد الهدف. باش تربط بيناتهم، خاصك تخرج من الهضرة العامة وتمشي لواحد التوصيف منظم فيه القواعد والحالات اللي كيكون فيها مشكل.

كيفاش تخرج الـ Workflow: مثال ديال المكتبة

تخيل سيستيم ديال مكتبة. الوصف السطحي كيقول: “المستخدمين كيسلفو الكتوبة ويقدروا يجددوا السلف (renew) إلا ما كانوش معطلين”. باش ترد هادشي مواصفات تقنية، خاصك تسول الناس اللي فاهمين البيزنس باش تكتشف الطرق اللي كيكون فيها بلوكاج.

أسئلة باش تخرج المنطق المخبي:

• “شنو كيوقع إلا بغا المستخدم يجدد كتاب وهو ديجا محجوز (reserved) من طرف شخص آخر؟”
• “واش يقدر المستخدم يجدد السلف وهو عندو خطايا (fines) ما مخلصاش؟”
• “شنو هو الشرط بالضبط اللي كيخلي السلف يتسما ‘معطل’ (overdue)؟”

من هاد الأسئلة، كنلقاو قاعدة مهمة: التجديد كيكون مبلوكي إلا كان الكتاب محجوز أَوْ إلا كان المستخدم عندو خطايا كتر من 10 دولار، واخا يكون الكتاب متاح.

تنظيم الـ Use Case النصي

الـ Use Case خاصو يركز على التفاعل، ماشي على كيفاش دايرة الصفحة (UI). كيكون فيه الـ Actor (الدور)، الـ Preconditions (شنو خاص يكون واجد)، الـ Main Success Scenario (الطريق الساهلة)، والـ Extensions (الحالات اللي فيها مشكل).

Use Case: تجديد كتاب من المكتبة

• Actor: عضو في المكتبة (Library Member)
• Precondition: العضو مكونيكتي وعندو كتاب مسلف حالياً.
• Main Success Scenario:
  1. العضو كيطلب تجديد كتاب معين.
  2. السيستيم كيتأكد بلي الكتاب ماشي محجوز.
  3. السيستيم كيتأكد بلي الحساب ديال العضو نقي (الخطايا ≤ 10 $).
  4. السيستيم كيزيد 14 يوم فالتاريخ ديال الترجيع.
  5. السيستيم كيعلم العضو بالتاريخ الجديد.
• Extensions: 2a. الكتاب محجوز → السيستيم كيقول للعضو بلي التجديد مبلوكي حيت كاين حجز سابق. 3a. الخطايا كتر من 10 $ → السيستيم كيقول للعضو بلي خاصو يخلص الخطايا عاد يجدد. 3b. الكتاب من نوع ‘طلب مرتفع’ (High Demand) → السيستيم كيرفض التجديد (كاينين كتوبة ما كيتجددوش).

رسم المنطق المعقد بـ Decision Tables

ملي كيكونوا بزاف ديال الشروط متداخلة، الهضرة كتولي تخلط. الـ Decision Table كيربط كل مجموعة ديال الشروط بنتيجة وحدة، باش ما تنسى حتى حالة (edge case).

الشرط	القاعدة 1	القاعدة 2	القاعدة 3	القاعدة 4
الكتاب محجوز؟	لا	نعم	لا	لا
الخطايا > 10 $؟	لا	لا	نعم	لا
غير قابل للتجديد؟	لا	لا	لا	نعم
القرار: السماح بالتجديد	نعم	لا	لا	لا
القرار: إظهار خطأ	والو	”محجوز"	"خطايا"	"قانون”

تحليل هاد الطريقة

هاد الخدمة كتحميك من الغلط ديال أنك تكودي غير ‘الطريق الساهلة’ وتصدم فـ QA بلي نسيتي الحالات ديال الحجز أو الخطايا. ملي كدير Decision Table، الديفلوبور كيعرف بالضبط شنو هما الـ if/else اللي خاصو يكتب فـ service layer قبل ما يبدا يكتب حتى سطر ديال Java. الحالات ديال الفشل (Extensions) كتولي متطلبات أساسية ماشي شي حاجة كتفكر فيها من بعد.

تمرين تطبيقي

السيناريو: المكتبة زادت ‘فترة سماح’ (Grace Period). إلا رجع الكتاب معطل بـ 1 حتى لـ 3 أيام، ما كاينش خطية. إلا فات 4 أيام، كتبدا الخطية اليومية. ولكن، إلا كان المستخدم ‘عضو مميز’ (Premium Member)، فترة السماح كتولي 7 أيام.

المطلوب: دير Decision Table باش تعرف واش نطبقو الخطية بناءً على: أيام التأخير و نوع العضوية (Standard/Premium).

الجواب:

الشرط	القاعدة 1	القاعدة 2	القاعدة 3	القاعدة 4
أيام التأخير	1-3	4-7	4-7	8+
نوع العضوية	Standard	Standard	Premium	أي نوع
تطبيق الخطية؟	لا	نعم	لا	نعم