رسم مخطط حالات الاستخدام

رسم مخطط حالات الاستخدام

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

يتناول هذا الدرس كل عنصر من عناصر الترميز التي تحتاجها ويصحبك خطوة بخطوة في بناء مخطط كامل باستخدام سيناريو عيادة طبية واقعي.

العناصر الأربعة للترميز

يحدد معيار UML أربعة عناصر بصرية فحسب لمخططات حالات الاستخدام. أتقن هذه العناصر وستتمكن من رسم أي مخطط بشكل صحيح.

١. الطرف (Actor) — الشخصية العصوية

يمثل الطرف أي كيان خارج النظام يتفاعل معه. يُرسم الطرف كشخصية عصوية بسيطة مع اسم تحتها. الطرف ليس شخصاً بالمعنى الحرفي — بل هو دور. قد يؤدي الشخص الواحد أدوار طرف متعددة (موظف الاستقبال في عيادة يراجع التقارير أيضاً يؤدي دورين). والأنظمة الخارجية التي تستدعي نظامك تُرسم هي أيضاً كأطراف.

٢. حالة الاستخدام (Use Case) — البيضاوي

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

٣. حدود النظام (System Boundary) — المستطيل

حدود النظام مستطيل عادي يُحيط بجميع حالات الاستخدام التابعة للنظام قيد التحليل. تقع حالات الاستخدام داخل الحدود؛ وتقع الأطراف خارجها. يظهر اسم النظام في أعلى المستطيل. تُوضّح الحدود ما هو في النطاق وما هو خارجه — وهي أداة تواصل بالغة الأهمية عند التفاوض على نطاق المشروع مع الرعاة.

٤. الارتباط (Association) — الخط العادي

الارتباط خط صلب يصل طرفاً بحالة الاستخدام التي يشارك فيها. لا توجد رؤوس أسهم على الارتباط الأساسي — الخط يقول ببساطة أن علاقة قائمة. يمكن للطرف الارتباط بحالات استخدام متعددة؛ ويمكن لحالة الاستخدام الارتباط بأطراف متعددة.

المخطط الأول — مرجع الترميز

يُظهر المخطط أدناه كل عنصر من عناصر الترميز مُعلَّماً بوضوح قبل الانتقال إلى مثال كامل.

خطوة بخطوة: رسم نظام حجز العيادة

لنطبق الترميز على سيناريو واقعي. تريد عيادة صحية مجتمعية تحويل نظام حجز مواعيدها إلى نظام رقمي. بعد مقابلات أصحاب المصلحة، رصد المحلل الحقائق التالية:

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

اتبع هذه الخطوات الأربع لتحويل هذه المعلومات إلى مخطط حالات استخدام:

1. حدد جميع الأطراف. أدرج كل دور يُبادر بالتفاعل مع النظام أو يستقبل مخرجاته. هنا: المريض، موظف الاستقبال، الطبيب، بوابة الرسائل النصية.
2. حدد جميع حالات الاستخدام. لكل طرف اسأل: "ما الهدف الذي يريد تحقيقه؟" كل هدف مستقل يصبح بيضاوياً واحداً.
3. ارسم حدود النظام. أنشئ مستطيلاً بعنوان "نظام حجز العيادة". ضع جميع حالات الاستخدام داخله وجميع الأطراف خارجه.
4. ارسم الارتباطات. صل كل طرف بحالات الاستخدام التي يشارك فيها بخط صلب عادي.

المخطط الثاني — مخطط حالات الاستخدام لنظام حجز العيادة

قراءة المخطط

بمجرد رسمه، يمكن لأي صاحب مصلحة — تقنياً كان أم غير تقني — قراءة مخطط حالات الاستخدام. اقرأه بشكل منهجي:

• تحديد النطاق. كل بيضاوي داخل المستطيل هو في النطاق. أما ما هو خارجه فهو خارج النطاق صراحةً. يُظهر المخطط أن الرواتب والفواتير ليست جزءاً من هذا النظام.
• تحديد من يفعل ماذا. تتبع كل خط ارتباط: المريض يستطيع التسجيل، وتسجيل الدخول، والبحث، والحجز، والإلغاء. موظف الاستقبال يستطيع تسجيل الدخول، والحجز، والإلغاء، وعرض الجدول. الطبيب يستطيع فقط عرض الجدول.
• تحديد حالات الاستخدام المشتركة. Book Appointment مرتبطة بكل من المريض وموظف الاستقبال — كلا الطرفين يشاركان في نفس الهدف من خلال النظام ذاته. وهذا يدفع المحلل فوراً للتساؤل: هل يتبع كلاهما نفس الخطوات أم أن تدفق إلغاء موظف الاستقبال يختلف؟
• تحديد تفاعلات الأنظمة الخارجية. بوابة الرسائل النصية مرتبطة بـ Send SMS Reminder — فهي مستقبل للمخرجات لا شخصاً.

ما يقع داخل الحدود وما يقع خارجها

سؤال يُربك المبتدئين: أين أرسم الخط؟ طبّق هذا الاختبار: إذا كان النظام الذي تبنيه يمتلك وينفذ السلوك، فيقع داخل الحدود. أما إذا كان طرف أو نظام آخر مجرد مُحفّز أو مستقبل أو مُزوّد ببيانات لذلك السلوك، فيبقى خارجها.

• داخل الحدود: Register Account، وSearch Available Slots، وBook Appointment، وCancel Appointment، وView Schedule، وSend SMS Reminder (نظام العيادة يُحرّك بوابة الرسائل لكن البوابة تنفذ الإرسال — هذا حكم تقديري؛ إن كنت تمتلك منطق الرسائل، ضعه داخل الحدود).
• خارج الحدود: تطبيق بوابة المريض (عميل وليس النظام نفسه)، التقويم الشخصي للطبيب (نظام خارجي قد يُدمج لاحقاً)، معالجة المدفوعات (سياق منفصل).

خلاصة

• يستخدم مخطط حالات الاستخدام أربعة عناصر ترميز فحسب: الطرف (الشخصية العصوية)، وحالة الاستخدام (البيضاوي)، وحدود النظام (المستطيل)، والارتباط (الخط العادي).
• الأطراف أدوار لا أفراداً؛ وتعيش خارج الحدود.
• حالات الاستخدام أهداف لا ميزات أو وظائف؛ وتعيش داخل الحدود.
• الارتباطات بلا رؤوس أسهم — الأسهم محجوزة للـ include والـ extend (الدرس التالي).
• مستطيل حدود النظام أداة قوية لإدارة النطاق — أبقه مرئياً في كل مراجعة مع أصحاب المصلحة.