UML: مخططات التسلسل والنشاط والحالة

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

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

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

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

السيناريو: إتمام الدفع في متجر إلكتروني

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

الخطوة الأولى — تحديد المشاركين

ابدأ بإدراج كل جهة فاعلة ومكوّن نظام يتبادل الرسائل خلال السيناريو. في تدفق الدفع، المشاركون هم:

  • Customer — الجهة الفاعلة البشرية التي تبدأ عملية الدفع.
  • Browser — واجهة المستخدم الأمامية (تُعرَض كجهة فاعلة أو كائن حدودي).
  • OrderController — المكوّن التطبيقي الذي ينسّق التدفق.
  • CartService — يتحقق من محتويات السلة وتوفر المخزون.
  • PaymentGateway — معالج الدفع الخارجي.
  • NotificationService — يرسل بريد تأكيد الطلب.

كل مشارك يصبح خطًا حيويًا (Lifeline): مستطيل معنوَن في الأعلى وخط عمودي متقطع يمتد منه إلى أسفل، يمثّل وجود ذلك الكائن عبر الزمن.

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

الخطوة الثانية — رسم الخطوط الحيوية ومحور الزمن

في مخطط التسلسل يتدفق الزمن نحو الأسفل. لكل خط حيوي مستطيل مشارك في الأعلى وخط عمودي متقطع تحته. عندما يكون المشارك نشطًا — يعالج استدعاءً — يُرسَم مستطيل تفعيل رفيع على الخط الحيوي. مستطيلات التفعيل تساعد القارئ على رؤية متى يكون كل مكوّن مشغولًا بالضبط.

الخطوة الثالثة — إضافة الرسائل

الرسائل أسهم أفقية بين الخطوط الحيوية، تُرسَم عند الموضع العمودي المناسب لتعكس التسلسل. يحدد UML عدة أنواع من الأسهم:

  • الاستدعاء المتزامن — خط صلب برأس سهم مملوء. المُرسِل ينتظر الرد قبل المتابعة. استخدمه للاستدعاءات العادية لتوابع أو واجهات برمجة.
  • رسالة الإعادة — خط متقطع برأس سهم مفتوح. تُظهر القيمة أو الإقرار المُعاد للمستدعي.
  • الرسالة غير المتزامنة — خط صلب برأس سهم مفتوح (عصاوي). المُرسِل لا ينتظر. شائعة للأحداث والإشعارات "أطلق وانسَ" أو طوابير الرسائل.

ضع على كل سهم اسم الرسالة وأبرز المعاملات عند الحاجة. اجعل التسميات مختصرة — placeOrder(cartId, paymentToken) مناسب؛ نسخ حمولة JSON كاملة ليس كذلك.

الاستدعاء الذاتي: يمكن للمشارك إرسال رسالة لنفسه — تُرسَم كسهم يحلّق على نفس الخط الحيوي. استخدمه لإظهار حساب داخلي أو استدعاء تابع مساعد، مثل قيام OrderController باستدعاء validateSession() الداخلية قبل تنفيذ الطلب.

مخطط التسلسل الكامل لعملية الدفع

يوضح المخطط أدناه تدفق الدفع بالكامل. اقرأه من أعلى إلى أسفل: يُقدّم العميل الطلب، وينسّق OrderController عملية التحقق، ويفحص CartService المخزون، وتعالج PaymentGateway الدفع، وأخيرًا ترسل NotificationService بريد التأكيد.

Online Store Checkout — Full Sequence Diagram Customer Browser OrderController CartService PaymentGateway Notification Service submitCheckout() POST /orders validateCart(cartId) cartOK, items[] checkStock(items) stockAvailable = true chargeCard(token, amount) verifyToken() chargeResult: success sendConfirmation(orderId) «async» composeEmail() 201 Created, orderId showConfirmationPage() Synchronous call Return / async Activation
مخطط تسلسل UML الكامل لعملية الدفع في المتجر الإلكتروني: ستة مشاركين، استدعاءات متزامنة، رسائل إعادة، استدعاء ذاتي، وإشعار غير متزامن.

قراءة المخطط خطوة بخطوة

  1. الرسالة 1 — ينقر العميل على "تأكيد الطلب"؛ يستقبل Browser حدث submitCheckout(). يبدأ شريط تفعيل Browser، مما يشير إلى انشغاله الآن.
  2. الرسائل 2–6 — يرسل Browser طلب POST /orders إلى OrderController، الذي يتفعّل ويفوّض فورًا إلى CartService. يجري استدعاءان متزامنان: validateCart() وcheckStock(). يُعيد كل منهما سهمًا متقطعًا يحمل نتيجته قبل بدء الاستدعاء التالي.
  3. الرسائل 7–9 — يستدعي OrderController التابع chargeCard() في PaymentGateway. لاحظ حلقة الاستدعاء الذاتي: تتحقق البوابة من الرمز داخليًا قبل المعالجة. بعد الانتهاء ترجع سهمًا متقطعًا يحمل chargeResult: success.
  4. الرسالة 10 — يُطلق OrderController sendConfirmation(orderId) كرسالة غير متزامنة (رأس سهم مفتوح، باللون الأزرق). لا ينتظر — يُقيَّد البريد في الخلفية بينما يجهّز المتحكم استجابة HTTP فورًا.
  5. الرسائل 12–13 — يعيد المتحكم 201 Created إلى Browser، الذي يعرض صفحة التأكيد للعميل.
لا تُظهر كل تفصيل داخلي. مخطط التسلسل نموذج تواصل، ليس شفرة مصدرية. احذف الاستدعاءات الداخلية منخفضة المستوى (التسجيل، التخزين المؤقت، استعلامات ORM) ما لم تكن ذات صلة مباشرة بالتفاعل المُحلَّل. المخططات المفرطة في التفاصيل تحجب التدفق التجاري الفعلي وتُرهق المراجعين.

عرض مبسّط: تسلسل تسجيل الدخول

لترسيخ التدوين بمثال أقصر، إليك تدفق تسجيل دخول المستخدم. ثلاثة مشاركين — Customer وAuthController وUserRepository — يتبادلون خمس رسائل. هذا قالب جيد لتقديمه لأصحاب المصلحة قبل عرض مخطط الدفع الكامل؛ يُعرّف بجميع التدوين الرئيسي دون إرهاق القارئ.

User Login — Sequence Diagram Customer AuthController UserRepository login(email, password) findByEmail(email) user record verifyPassword(hash) sessionToken (success) 1 2 3 4 5
تسلسل تسجيل الدخول المبسّط: Customer وAuthController وUserRepository — خمس رسائل تتضمن استدعاءً ذاتيًا للتحقق من كلمة المرور.

قائمة التحقق عند رسم مخططاتك

قبل تقديم أي مخطط تسلسل لأصحاب المصلحة، تحقق من كل ما يلي:

  1. كل مشارك لديه مستطيل معنوَن وخط حيوي متقطع.
  2. كل فترة نشاط لها مستطيل تفعيل على الخط الحيوي.
  3. الاستدعاءات المتزامنة تستخدم رؤوس أسهم مملوءة؛ الإعادات تستخدم خطوطًا متقطعة برؤوس أسهم مفتوحة.
  4. الرسائل غير المتزامنة واضحة التمييز (رأس سهم عصاوي مفتوح، أو محاطة بـ«async»).
  5. تسميات الرسائل تحمل معلومات كافية لتكون لا لبس فيها دون إسهاب.
  6. للمخطط عنوان والسيناريو الذي يصوّره محدد النطاق بوضوح (المسار السعيد، مسار الخطأ، أو كلاهما — محددًا بإطار).

ملخص

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