UML: مخططات حالات الاستخدام والسيناريوهات
مشروع: نموذج حالات الاستخدام
مشروع: نموذج حالات الاستخدام
هذا الدرس الأخير مشروع نمذجة متكامل من البداية إلى النهاية. ستبني نموذج حالات الاستخدام الكامل لنظام واقعي — المكتبة الإلكترونية — انطلاقاً من وصف موجز لأصحاب المصلحة، مروراً بمخطط حالات استخدام شامل يتضمن كل العلاقات، وصولاً إلى سيناريوهين بالغَي التفصيل يمكن لفريق التطوير تسليمهما مباشرةً للمطور أو المختبِر. كل ما تدربت عليه خلال هذه الوحدة يتقاطع هنا.
ما ستنتجه: (١) مخطط حالات استخدام كامل يُظهر الأطراف وحالات الاستخدام وحدود النظام وعلاقات include/extend والتعميم بين الأطراف؛ (٢) سيناريوان بالغا التفصيل مكتوبان وفق القالب المعياري مع التدفق الرئيسي والتدفقات البديلة وتدفقات الاستثناء.
الخطوة الأولى — وصف المشروع
أجرى المحلل مقابلات مع أصحاب المصلحة في مكتبة إلكترونية. أبرز الحقائق:
- يستطيع الزائر (غير المسجل) تصفح الكتالوج، والبحث عن الكتب، وعرض صفحة تفاصيل الكتاب، والتسجيل في الموقع.
- يستطيع العميل المسجل (يُعمّم الزائر — يرث كل قدراته ويزيد عليها) تسجيل الدخول، وإضافة كتب إلى قائمة الأمنيات، وإضافة كتب إلى سلة التسوق، وتقديم طلب شراء. تقديم الطلب يستلزم دائماً تأكيد بيانات الدفع — سلوك فرعي إلزامي.
- عند تقديم كل طلب، يجب أن يرسل النظام بريداً إلكترونياً للتأكيد تتولاه خدمة البريد الإلكتروني، وهي نظام خارجي.
- يستطيع مدير المتجر تسجيل الدخول في لوحة الإدارة، وإدارة كتالوج الكتب (إضافة وتعديل وحذف)، ومعالجة طلبات استرداد المبالغ.
- معالجة الاسترداد تستلزم دائماً التحقق من الطلب الأصلي — سلوك فرعي إلزامي.
- قد يكتب العميل المسجل مراجعةً بعد تقديم الطلب — اختيارياً فحسب.
- يتولى بوابة الدفع الخارجية الخصم الفعلي عند تأكيد العميل للدفع.
الخطوة الثانية — تحديد الأطراف وحالات الاستخدام
من الوصف، يُحدد المحلل الأطراف والأهداف التالية:
- الأطراف: الزائر، العميل المسجل (يُعمّم الزائر)، مدير المتجر، خدمة البريد الإلكتروني، بوابة الدفع.
- حالات الاستخدام: Browse Catalog، Search Books، View Book Details، Register Account، Log In، Add to Wishlist، Add to Cart، Place Order، Confirm Payment، Write Review، Manage Book Catalog، Process Refund، Verify Order، Send Confirmation Email.
- العلاقات:
Place Order«include»Confirm Payment— إلزامي دائماً.Confirm Paymentيُشغّل بوابة الدفع (ارتباط بطرف خارجي).Place Order«include»Send Confirmation Email— خدمة البريد تُشغَّل دائماً.Place Order«extend»Write Review— اختياري بعد الطلب.Process Refund«include»Verify Order— إلزامي دائماً.- العميل المسجل يُعمّم الزائر — يرث التصفح والبحث والعرض والتسجيل.
الخطوة الثالثة — مخطط حالات الاستخدام الكامل
قراءة المخطط: ابدأ بسهم التعميم — العميل المسجل يرث جميع ارتباطات الزائر (تصفح الكتالوج، البحث، عرض التفاصيل، التسجيل) دون تكرار الخطوط. تُشير الأسهم المتقطعة «include» إلى السلوكيات الفرعية الإلزامية، بينما يشير السهم المتقطع «extend» إلى Write Review كنشاط اختياري بعد الطلب. كل طرف يقع خارج مستطيل حدود النظام.
الخطوة الرابعة — السيناريو الأول بالغ التفصيل: Place Order
السيناريو بالغ التفصيل وثيقة نثرية منظمة تُحدد كل خطوة وشرط ومسار بديل واستثناء لحالة استخدام واحدة. فيما يلي السيناريو الكامل لحالة الاستخدام Place Order، أكثر حالات الاستخدام أهميةً من الناحية التجارية في هذا النظام.
Use Case ID: UC-05
Name: Place Order
Actor(s): Registered Customer (primary); Payment Gateway, Email Service (supporting)
Preconditions:
1. Customer is logged in.
2. Shopping cart contains at least one item with sufficient stock.
Goal: Customer successfully purchases all items in the cart.
Trigger: Customer clicks "Proceed to Checkout."
MAIN SUCCESS FLOW (Basic Path)
1. System displays the order summary: items, quantities, unit prices, subtotal, tax, total.
2. Customer reviews the summary and confirms.
3. System prompts for payment details (card number, expiry, CVV).
[INCLUDE: Confirm Payment]
4. Payment Gateway authorizes the charge.
5. System decrements stock for each ordered item.
6. System creates an order record with status "Confirmed."
7. System triggers the Email Service.
[INCLUDE: Send Confirmation Email]
8. System displays the order confirmation page with order ID and estimated delivery date.
[EXTEND: Write Review — available after order is confirmed, at customer\'s discretion]
ALTERNATE FLOWS
A1 — Customer edits the cart (step 2):
A1.1 Customer clicks "Edit Cart."
A1.2 System returns to the cart page.
A1.3 Use case resumes from step 1 when customer returns to checkout.
A2 — Customer applies a discount code (step 2):
A2.1 Customer enters a discount code.
A2.2 System validates the code; if valid, recalculates the total.
A2.3 If invalid, system displays "Invalid or expired code" and keeps the original total.
A2.4 Use case resumes from step 2.
EXCEPTION FLOWS
E1 — Payment is declined (step 4):
E1.1 Payment Gateway returns "Declined."
E1.2 System displays "Payment declined. Please check your card details or use a different card."
E1.3 System does NOT decrement stock or create an order record.
E1.4 Customer may re-enter payment details (return to step 3) or cancel the order.
E2 — Item goes out of stock between cart and checkout (step 5):
E2.1 System detects zero available stock for at least one cart item.
E2.2 System cancels the charge via the Payment Gateway (refund request).
E2.3 System displays "Sorry, [item] is no longer in stock. Your payment has not been taken."
E2.4 System removes the out-of-stock item from the cart.
E2.5 Customer may continue with remaining items (return to step 1) or cancel.
E3 — Email Service is unavailable (step 7):
E3.1 Email Service returns a timeout or error.
E3.2 System logs the failure and queues the email for retry.
E3.3 Order is still confirmed; customer sees the confirmation page without email mention.
Postconditions (success): Order record created, stock decremented, confirmation email sent.
Postconditions (failure): No order record; stock unchanged; card not charged.
الخطوة الخامسة — السيناريو الثاني بالغ التفصيل: Process Refund
Use Case ID: UC-12
Name: Process Refund
Actor(s): Store Administrator (primary); Payment Gateway (supporting)
Preconditions:
1. Administrator is logged in to the admin panel.
2. A customer has submitted a refund request through the customer portal.
Goal: Administrator issues a full or partial refund and closes the request.
Trigger: Administrator opens a pending refund request from the queue.
MAIN SUCCESS FLOW (Basic Path)
1. System displays the refund request: customer name, order ID, items, reason, requested amount.
2. Administrator reviews the request.
[INCLUDE: Verify Order]
3. System retrieves and displays the original order record: payment status, items shipped, amount charged.
4. Administrator confirms the refund amount (full or partial) and clicks "Approve Refund."
5. System sends a refund instruction to the Payment Gateway for the approved amount.
6. Payment Gateway confirms the refund is processed.
7. System updates the order status to "Refunded" (full) or "Partially Refunded."
8. System notifies the customer by email that the refund has been approved.
9. System closes the refund request with status "Resolved."
ALTERNATE FLOWS
A1 — Administrator issues a partial refund (step 4):
A1.1 Administrator enters a custom amount less than the original charge.
A1.2 System validates the amount is not greater than the original charge.
A1.3 Use case continues from step 5 with the partial amount.
A2 — Administrator rejects the refund request (step 4):
A2.1 Administrator clicks "Reject" and enters a rejection reason.
A2.2 System notifies the customer by email with the rejection reason.
A2.3 System closes the request with status "Rejected."
A2.4 Use case ends.
EXCEPTION FLOWS
E1 — Original order not found (step 3):
E1.1 System cannot locate the order record.
E1.2 System displays "Order record not found. Contact database administration."
E1.3 Use case is suspended; administrator escalates to technical support.
E2 — Payment Gateway rejects the refund (step 6):
E2.1 Gateway returns an error.
E2.2 System displays the gateway error message to the administrator.
E2.3 System marks the refund request as "Pending — Gateway Error."
E2.4 Administrator contacts the payment provider directly to resolve.
Postconditions (success): Refund issued, order status updated, customer notified.
Postconditions (failure): No refund issued; request remains open or rejected.
ما يُشكّل نموذج حالات الاستخدام الكامل
نموذج حالات الاستخدام المكتمل ليس مجرد مخطط. يتألف من ثلاث طبقات:
- المخطط — يعطي الصورة الكبيرة: النطاق والأطراف والأهداف والعلاقات دفعةً واحدة. هذه أداة التواصل في مراجعات أصحاب المصلحة.
- وثائق السيناريو — سيناريو بالغ التفصيل لكل حالة استخدام مهمة. هذه هي الجسر بين المتطلبات والتصميم: يقرأ المطور السيناريو فيعرف بالضبط ما يبنيه؛ ويقرأه المختبر فيعرف كل مسار يجب التحقق منه.
- المسرد وقواعد العمل — تعريفات مصطلحات المجال (ماذا يعني "متوفر في المخزون"؟ ما مدة نافذة الاسترداد؟) التي تُشير إليها السيناريوهات دون أن تعرّفها في السياق. تُحفظ في وثيقة مواصفات المتطلبات.
لا تكتب سيناريوهات بالغة التفصيل لكل حالة استخدام. حدد الأولويات: اكتب سيناريوهات تفصيلية لحالات الاستخدام عالية الخطورة أو المعقدة أو الحرجة تجارياً (Place Order، Process Refund، Register Account). أما حالات الاستخدام البسيطة (Browse Catalog، View Book Details) فيكفيها سيناريو موجز أو مجرد ارتباط في المخطط. الإفراط في التوثيق يُضيّع الوقت ويُنتج مواصفات لا يقرأها أحد.
قائمة التحقق — قبل تسليم النموذج
- كل طرف مُسمّى كدور لا كشخص أو مسمى وظيفي.
- كل حالة استخدام مُسماة بعبارة فعلية من منظور الطرف.
- جميع الأطراف خارج حدود النظام؛ جميع حالات الاستخدام داخلها.
- علاقات «include» تشير إلى السلوكيات الفرعية الإلزامية؛ علاقات «extend» تشير إلى الامتدادات الاختيارية مع نقطة امتداد مُلاحَظة.
- أسهم التعميم ذات رأس مثلث مجوف يشير نحو الطرف أو حالة الاستخدام الأب.
- كل سيناريو بالغ التفصيل يحتوي على: المعرّف، الاسم، الأطراف، الشروط المسبقة، المُحفّز، التدفق الرئيسي، تدفقاً بديلاً واحداً على الأقل، تدفق استثناء واحداً على الأقل، والشروط اللاحقة.
- النموذج جرت مراجعته مع صاحب مصلحة في المجال — لا مع فريق التطوير فحسب.
خلاصة
لقد أنتجت الآن نموذج حالات استخدام كاملاً ومحترفاً: مخطط بجميع العناصر الخمسة (الطرف، حالة الاستخدام، حدود النظام، الارتباط، include/extend/generalization)، وسيناريوان بالغا التفصيل يغطيان أهم التدفقات مع مساراتها البديلة وتدفقات الاستثناء. هذا هو المُنتَج الذي يُسلّمه المحلل إلى فريق المشروع قبل بدء التصميم التفصيلي — وهو الأداة التي يستخدمها المختبرون لاشتقاق حالات الاختبار في المرحلة التالية من دورة حياة تطوير البرمجيات.