مشروع: نمذجة عملية بثلاث طرق

مشروع: نمذجة عملية بثلاث طرق

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

السيناريو: طلب صيدلية إلكترونية

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

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

المخطط الأول — مخطط التسلسل: تفاعل التحقق

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

القرارات النمذجية الرئيسية في هذا المخطط:

• يلتقط إطار alt فرع القبول والرفض — كلا النتيجتين مرئيتان في مخطط واحد.
• شريط التنشيط للصيدلاني يُظهر بدقة المدة التي يحتلها استدعاء verifyPrescription().
• رسائل الإرجاع (الأسهم المتقطعة) تجعل بيانات الاستجابة صريحة: يتدفق approvalResult مرة أخرى إلى النظام الذي يُبلّغ العميل.

المخطط الثاني — مخطط النشاط: تدفق الطلب الكامل

يُفضَّل مخطط النشاط عندما تحتاج إلى إظهار تدفق العملية الكاملة — جميع الخطوات، وجميع نقاط القرار، ومن المسؤول عن كل شيء. هنا يجيب عن: ما هو التسلسل الكامل للإجراءات من تقديم الطلب حتى التسليم، وأي دور يُنفّذ كل خطوة؟

القرارات النمذجية الرئيسية:

• تقسّم ثلاثة مسارات سباحة المسؤوليات: العميل، نظام الطلبات، الصيدلاني+المستودع (مجمّعان للإيجاز).
• تقسّم معينة القرار عند "التحقق من الوصفة" التدفق بوضوح إلى مسار القبول والرفض.
• تنتهي العملية عند عقدتَي نهاية مختلفتين: تسليم ناجح وطلب ملغى. كلاهما حالات نهائية صحيحة.

المخطط الثالث — مخطط آلة الحالة: دورة حياة الطلب

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

القرارات النمذجية الرئيسية:

• الحالات مثل Pending Verification وShipped هي أماكن استراحة مستقرة — يبقى الطلب فيها حتى يصل حدث ما.
• الانتقالات مُعنوَنة بالصيغة حدث [حارس] / إجراء: مثلًا verificationResult [rejected] / notifyCustomer.
• حالتا النهاية (Delivered وCancelled) تجعلان كلا النتيجتين صريحتين.

مقارنة المنظورات الثلاثة

يجيب كل مخطط عن سؤال مختلف حول نفس السيناريو:

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

متى تُرسم المخططات الثلاثة

في الممارسة العملية، لا تحتاج دائمًا إلى الثلاثة معًا لكل عملية. إرشاد مفيد:

• ارسم مخطط التسلسل كلما كنت تُحدد تكاملًا أو واجهة برمجية بين نظامين أو فريقين.
• ارسم مخطط النشاط كلما سأل أصحاب مصلحة الأعمال "كيف تعمل العملية؟" — فهو الأكثر قابلية للقراءة من قِبل الجمهور غير التقني.
• ارسم مخطط الحالة كلما كان كائن في نظامك يحمل عمود status (order_status، ticket_state، account_status). يصبح المخطط المواصفة المباشرة للقيم المسموح بها وانتقالاتها.