مخططات التسلسل: خطوط الحياة والرسائل

مخططات التسلسل: خطوط الحياة والرسائل

مخطط التسلسل (Sequence Diagram) هو الأداة الرئيسية في UML لنمذجة كيفية تفاعل مجموعة من المشاركين عبر الزمن لتنفيذ سيناريو بعينه. على عكس مخطط حالات الاستخدام الذي يخبرك بما يفعله النظام، يوضح مخطط التسلسل كيف تتعاون المكونات خطوة بخطوة — والأهم بأي ترتيب. لهذا يُعدّ لا غنى عنه حين تحتاج إلى التحقق من المتطلبات، أو تصميم عقد API، أو توصيل سير عمل تجاري للمطورين.

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

المشاركون

المشارك (Participant) هو أي كيان يأخذ دوراً في التفاعل. في سياق أنظمة الأعمال قد يكون ذلك مستخدماً، أو متصفح ويب، أو فئة تحكم (Controller)، أو طبقة خدمة (Service Layer)، أو قاعدة بيانات، أو واجهة برمجية خارجية (API). يظهر كل مشارك على شكل مستطيل مُعنوَن في أعلى المخطط — يُسمى هذا صندوق المشارك (يُسميه UML أيضاً رأس خط الحياة).

تتبع أسماء المشاركين تقليد ثنائي: instanceName : ClassName. في الواقع العملي، يكتب المحللون اسم الدور أو النظام فحسب — Customer، BookingService، Database — لأنهم في مرحلة التحليل يُنمذجون أدواراً لا كائنات تنفيذية. القاعدة المهمة هي أن يحظى كل مشارك مختلف بصندوقه الخاص.

خطوط الحياة

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

خط الحياة الذي يُنشأ في منتصف التفاعل يبدأ في منتصف المخطط (يظهر صندوق مشاركه عند نقطة الإنشاء لا في الأعلى). أما خط الحياة الذي يُدمَّر قبل انتهاء التفاعل فيُظهر علامة X في أسفله. هذان ميزتان متقدمتان؛ في معظم سيناريوهات الأعمال يمتد كل خط حياة بالارتفاع الكامل للمخطط.

أشرطة التنشيط

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

أشرطة التنشيط مهمة لأنها تُظهر أزواج الاستدعاء والإرجاع بوضوح: يمكنك أن ترى دفعة واحدة أي مشارك "يتحكم" في أي لحظة ومتى يُعيد التحكم. الأشرطة المتداخلة تشير إلى استدعاءات متداخلة، كما حين تستدعي خدمة ما مستودعاً (Repository) الذي يستدعي بدوره قاعدة البيانات.

الرسائل

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

الرسائل المتزامنة

الرسالة المتزامنة (Synchronous Message) تمثل استدعاءً يُجمِّد فيه المُرسِل ويظل منتظراً حتى يُكمل المستقبِل عمله قبل المتابعة. هذا هو الاستدعاء القياسي للدوال أو الأساليب في معظم لغات البرمجة، وأيضاً كيفية عمل معظم طلبات API من منظور المُستدعي. في UML، تُرسم الرسالة المتزامنة كـخط متصل برأس سهم مملوء.

يجب إقران كل استدعاء متزامن بـرسالة إرجاع — خط متقطع برأس سهم مفتوح — تتدفق عائدة إلى المستدعي. تحمل رسالة الإرجاع النتيجة (نص الاستجابة، أو قيمة الإرجاع، أو التأكيد). حذف الإرجاع مسموح به تقنياً في UML لكنه ممارسة سيئة في مخططات تحليل الأعمال لأنه يخفي القيمة التي جرى تبادلها.

الرسائل غير المتزامنة

الرسالة غير المتزامنة (Asynchronous Message) تُرسَل ويُكمل المُرسِل عمله فوراً دون انتظار رد. فكر في نشر رسالة إلى قائمة انتظار، أو إرسال بريد إلكتروني إشعار، أو إطلاق webhook. المُرسِل لا يتوقف. في UML، تُرسم الرسالة غير المتزامنة كـخط متصل برأس سهم مفتوح (غير مملوء).

لا يوجد سهم إرجاع مقترن برسالة غير متزامنة نقية، لأن المُرسِل لا يتوقع استجابة في التدفق. إذا وصل إقرار لاحقاً، يُرسم كرسالة غير متزامنة منفصلة في الاتجاه المعاكس في موضع أدنى على المخطط.

المخطط 1 — مرجع التدوين

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

المخطط 2 — حجز موعد في العيادة (سيناريو واقعي)

طبّق التدوين الآن على سيناريو حقيقي. يستخدم مريض تطبيق ويب لحجز موعد في عيادة. الخطوات:

1. يرسل المريض طلب حجز عبر المتصفح.
2. يستدعي BookingController العملية AppointmentService.book() بشكل متزامن.
3. يستعلم AppointmentService قاعدة البيانات للتحقق من توفر الموعد (متزامن).
4. تُعيد قاعدة البيانات نتيجة التوفر.
5. يحفظ AppointmentService الحجز الجديد (متزامن).
6. يُطلق AppointmentService إشعاراً غير متزامن إلى EmailService — لا ينتظر إرسال البريد قبل الإرجاع.
7. يُرجع AppointmentService الحجز المُنشأ إلى المتحكم.
8. يعرض المتحكم صفحة التأكيد للمريض.

قراءة المخطط

اعمل عبر المخطط من أعلى إلى أسفل ومن يسار إلى يمين:

1. حدد كل صندوق مشارك — هذه هي الجهات الفاعلة ومكونات النظام في هذا السيناريو.
2. اتبع خطوط الحياة إلى الأسفل لتتبع مرور الزمن.
3. لاحظ أشرطة التنشيط — تخبرك من مشغول بالمعالجة في كل لحظة. المتحكم نشط من الخطوة 1 حتى 8؛ والخدمة نشطة من الخطوة 2 حتى 7.
4. اقرأ كل سهم رسالة من خلال تسميته ونوع سهمه. رأس مملوء = استدعاء متزامن؛ رأس مفتوح متقطع = إرجاع؛ رأس مفتوح متصل = غير متزامن.
5. لاحظ أنه بعد الخطوة 6 (رسالة البريد غير المتزامنة) لا تنتظر الخدمة — إذ تتقدم فوراً إلى الخطوة 7 وتُرجع الحجز إلى المتحكم.

اختيار دقة المشاركين المناسبة

أحد الاختيارات التي ستتخذها مراراً هو مدى تفصيل المشاركين. في مراجعة المتطلبات مع أصحاب مصلحة غير تقنيين، استخدم مشاركين على مستوى الأدوار: Patient، Booking System، Email Notification. في مراجعة التصميم مع المطورين، فصّل أكثر: BookingController، AppointmentService، SlotRepository، Database. كلا المنظورين صحيح؛ اختر الدقة التي تخدم جمهورك.

خلاصة

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