UML: مخططات حالات الاستخدام والسيناريوهات

حالات الاستخدام مقابل قصص المستخدمين

18 دقيقة الدرس 8 من 10

حالات الاستخدام مقابل قصص المستخدمين

تصف كلٌّ من حالات الاستخدام وقصص المستخدمين ما يجب أن يفعله النظام من منظور المستخدم. غير أنهما نشآ من تقاليد مختلفة، ويُكتبان على مستويات تفصيل مختلفة، ويؤديان أدواراً متباينة في المشروع. إتقان معرفة متى يُفضَّل كل منهما، وكيفية التحويل بينهما، مهارة أساسية لأي محلل أنظمة.

جذور كل منهج

قنَّن حالات الاستخدام إيفار جاكوبسون في مطلع التسعينيات ضمن العملية الموحدة (Unified Process). وهي وثائق منظَّمة تحدد الجهة الفاعلة الرئيسية، والهدف، والسيناريو الناجح الرئيسي (خطوة بخطوة)، وكل مسار بديل أو استثنائي ذي معنى. وتنتمي إلى عالم التحليل المنظَّم والموجه نحو الكائنات.

ظهرت قصص المستخدمين ضمن البرمجة المتطرفة (XP) حوالي عام 1999، وانتشرت مع إطار Scrum. وهي عبارات قصيرة مدروسة بحجم بطاقة فهرس، تؤجل التفاصيل إلى الحوار. وتنتمي إلى عالم التسليم الرشيق.

الصيغتان الكلاسيكيتان

تُحدَّد حالة الاستخدام في مخطط (القطع الناقص المسمى حجز موعد) ثم تُوثَّق في قالب منظَّم:

حالة الاستخدام: حجز موعد الجهة الفاعلة: المريض الشروط المسبقة: المريض مسجّل دخول؛ العيادة لديها مواعيد متاحة. السيناريو الناجح الرئيسي: 1. يختار المريض التخصص والتاريخ المفضل. 2. يعرض النظام الأطباء المتاحين والمواعيد الحرة. 3. يختار المريض طبيباً وموعداً. 4. يؤكد النظام الحجز ويرسل بريداً إلكترونياً تأكيدياً. المسار البديل (أ1 – لا توجد مواعيد متاحة): 2أ. يعرض النظام "لا توجد مواعيد متاحة" ويقترح التاريخ الأقرب. المسار الاستثنائي (ه1 – فشل الدفع): 4أ. تُعيد بوابة الدفع خطأً؛ يُخطر النظام المريض ويلغي الحجز المؤقت. الشروط اللاحقة: سجل الموعد مُنشأ؛ تقويم الطبيب مُحدَّث.

تتبع قصة المستخدم صيغة البطاقة الثلاثية الأجزاء:

بوصفي مريضاً، أريد أن أحجز موعداً مع طبيب عبر الإنترنت، كي أتجنب الانتظار على الهاتف. معايير القبول: - يمكنني التصفية حسب التخصص والتاريخ. - أتلقى بريداً تأكيدياً خلال دقيقتين. - إذا لم يكن ثمة موعد متاح، أرى التاريخ الأقرب.
الفارق الهيكلي الأساسي: حالة الاستخدام وثيقة ذات شروط مسبقة ولاحقة ومسارات مرقَّمة. قصة المستخدم مبادرة للحوار — التفاصيل تعيش في معايير القبول والنقاش الجماعي، لا في البطاقة ذاتها.

جدول المقارنة

Use Cases vs User Stories Comparison Dimension Use Case User Story Origin methodology Unified Process / RUP (Jacobson, 1992) XP / Scrum (Beck/Cohn, 1999+) Format Structured document with flows & tables Short card sentence + acceptance criteria Detail level High — all flows specified up front Low initially; grows via conversation Best for Safety-critical, regulated, fixed-price contracts Evolving products, Agile sprints Diagram Yes — UML Use Case Diagram No standard diagram; Story maps are informal Ownership Business / Systems Analyst Product Owner / Team
مقارنة جانبية بين حالات الاستخدام وقصص المستخدمين عبر ستة أبعاد.

التفاصيل: الأهداف مقابل المهام

نموذج ذهني مفيد هو مستويات الأهداف لـ Alistair Cockburn. تقع قصص المستخدمين عادةً على مستوى المهمة أو الميزة — قصة واحدة لكل عنصر في السبرينت. يمكن لحالات الاستخدام أن تمتد عبر مستويات هدف متعددة: حالة استخدام واحدة على مستوى البحر (Process Checkout) قد تنقسم إلى عدة قصص مستخدم (أضف عنصراً إلى السلة، أدخل عنوان الشحن، ادفع بالبطاقة).

Goal Level Mapping: Use Cases to User Stories Goal Level Mapping: Use Cases decompose into User Stories USE CASE (sea level) Process Checkout Goal: complete a purchase USER STORY As a Shopper, I want to add items to my cart... USER STORY As a Shopper, I want to enter my shipping address... USER STORY As a Shopper, I want to pay by credit card... ACCEPTANCE CRITERIA bridge the gap: - Cart persists across sessions - Address validated on entry - 3DS2 authentication used - Confirmation email sent - Inventory decremented Key insight: one sea-level use case often maps to 3-8 user stories Use cases capture the COMPLETE goal including all alternate paths. User stories slice that goal into independently deliverable increments. Acceptance criteria on each story carry the detail that use case flows provide.
حالة استخدام واحدة على مستوى البحر (إتمام الدفع) مقسَّمة إلى ثلاث قصص مستخدم، كل منها بمعايير قبول تقابل مسارات حالة الاستخدام البديلة والاستثنائية.

متى يتألق كل منهج

اختر حالات الاستخدام حين:

  • يكون المشروع حرجاً من ناحية السلامة أو منظَّماً (أجهزة طبية، بنوك، طيران) وتحتاج إلى قاعدة متطلبات قابلة للتدقيق.
  • تكتب عقداً بسعر ثابت أو طلب اقتراح رسمي يستلزم نطاقاً دقيقاً وغير غامض.
  • يتضمن النظام معالجة استثناءات معقدة يجب تعدادها (استرداد أخطاء الصراف الآلي، التراجع عن الدفع).
  • تُنشئ حالات الاختبار مباشرةً من المتطلبات (انظر الدرس القادم).

اختر قصص المستخدمين حين:

  • تعمل في بيئة Agile/Scrum بسبرينتات أسبوعين وصاحب منتج يقود تحديد الأولويات.
  • تتطور المتطلبات وتحتاج إلى تسليم القيمة بصورة تدريجية.
  • الفريق صغير ومجتمع في مكان واحد — الحوار يحل محل التوثيق.
  • تريد الحفاظ على خفة قائمة المهام والتركيز على قيمة الأعمال بدلاً من اكتمال المواصفات.
المنهج الهجين — أفضل نقطة توازن لمعظم المحللين: ارسم مخطط حالة استخدام لتحديد حدود النظام وجرد الجهات الفاعلة والأهداف. ثم اكتب قصص مستخدمين لكل حالة استخدام (أو لكل سيناريو ضمن حالة استخدام معقدة) لقيادة تخطيط السبرينت. تؤدي معايير القبول على القصص دور المسارات البديلة في حالات الاستخدام — تُلتقط عند الحاجة لا دفعةً واحدة.

التحويل بين الأسلوبين

من حالة الاستخدام إلى قصص المستخدمين — وصفة ثلاثية الخطوات:

  1. خذ السيناريو الناجح الرئيسي: كل خطوة مرقَّمة تقدم قيمة مرئية للجهة الفاعلة تصبح قصة مستخدم مرشَّحة.
  2. ارفع المسارات البديلة الجوهرية إلى قصص مستقلة (مثل: بوصفي مريضاً، أريد الانضمام إلى قائمة انتظار حين لا يتوفر موعد).
  3. حوِّل مسارات الاستثناء إلى معايير قبول على القصة ذات الصلة، أو إلى قصة مستقلة إذا كانت معالجة الاستثناء جوهرية.

من قصص المستخدمين إلى حالات الاستخدام — تجميع ورفع:

  1. اجمع القصص ذات الصلة وفق الهدف الذي تحققه معاً.
  2. سمِّ المجموعة اسم حالة الاستخدام (اسم الهدف).
  3. ارفع معايير قبول كل قصة إلى مسارات بديلة/استثنائية في سرد حالة الاستخدام.
  4. حدد الجهة الفاعلة وارسم القطع الناقص في مخطط حالة الاستخدام.
خطأ شائع — كتابة حالات الاستخدام بأسلوب قصص المستخدمين: تكتب بعض الفرق "بوصفي مريضاً، أريد حجز موعد" على بطاقة وتسميها حالة استخدام. هذه قصة مستخدم. حالة الاستخدام تتطلب القالب المنظَّم الكامل مع الشروط المسبقة واللاحقة والمسارات المرقَّمة. طمس هذا التمييز يُضعف كلا الأثرين.

مثال نظام المكتبة

لنأخذ نظام إدارة مكتبة. ترسم محللة الأعمال أولاً مخطط حالة استخدام وتحدد استعارة كتاب حالةَ استخدامٍ على مستوى البحر. ثم تكتب الأثرين:

-- حالة الاستخدام: استعارة كتاب -- الجهة الفاعلة: عضو المكتبة الشرط المسبق: العضو مصادق؛ الكتاب متاح. السيناريو الناجح الرئيسي: 1. يمسح العضو الباركود الخاص بالكتاب. 2. يتحقق النظام من حد الإعارة للعضو (5 كتب كحد أقصى). 3. يسجل النظام الإعارة: رقم العضو، رقم الكتاب، تاريخ الاستحقاق (14 يوماً). 4. يطبع النظام إيصالاً. مسار بديل أ: وصل العضو إلى حد الإعارة → يعرض النظام تحذيراً ولا يسجل الإعارة. استثناء ه1: الباركود غير مقروء → يطلب إدخال رقم ISBN يدوياً. الشرط اللاحق: سجل الإعارة مُنشأ؛ حالة الكتاب = مُعار. -- قصص المستخدمين (من الهدف ذاته) -- القصة 1: بوصفي عضواً، أريد مسح باركود الكتاب لاستعارته، كي يكون تسجيل الخروج سريعاً. معايير القبول: المسح يستغرق أقل من ثانيتين؛ الإيصال يُطبع تلقائياً. القصة 2: بوصفي عضواً، أريد رؤية تحذير إذا وصلت إلى حد الـ 5 كتب، كي أفهم سبب رفض الاستعارة. معايير القبول: يظهر التحذير فوراً؛ لا تُنشأ إعارة جزئية.

لاحظ أن مسار الاستثناء ه1 (الباركود غير مقروء) لا يستحق قصة مستقلة — يُلتقط كمعيار قبول على القصة الأولى.

ملخص

  • حالات الاستخدام وثائق منظَّمة تحدد هدفاً كاملاً بجميع مساراته؛ قصص المستخدمين بطاقات خفيفة تؤجل التفاصيل إلى الحوار.
  • تتفوق حالات الاستخدام في السياقات الرسمية والتعاقدية والحرجة للسلامة؛ تتفوق قصص المستخدمين في التسليم الرشيق والتطوري.
  • تتوافق حالة استخدام واحدة غالباً مع عدة قصص مستخدمين؛ ومعايير القبول تحمل تفاصيل المسارات.
  • يستخدم كثير من المشاريع الناجحة نهجاً هجيناً: مخططات حالة الاستخدام لتحديد النطاق، وقصص المستخدمين لتنفيذ السبرينت.