المخططات الانسيابية مقابل DFD ومقابل النماذج الأخرى
المخططات الانسيابية مقابل DFD ومقابل النماذج الأخرى
في هذه المرحلة من الدرس، رسمت مخططات انسيابية تتبع المنطق التسلسلي للعملية، ومخططات DFD تكشف عن البيانات المتدفقة بين العمليات والمخازن والكيانات الخارجية. كلاهما نماذج للعمليات — لكنهما يجيبان على أسئلة مختلفة تمامًا. في الواقع العملي، يجد المحلل نفسه أمام لوح فارغ ويجب أن يقرر: أي مخطط سيساعد أصحاب المصلحة والمطورين فعلًا على فهم هذا النظام؟
اختيار النموذج الخاطئ ليس مجرد إزعاج بسيط. إنه يُهدر ساعات من وقت النمذجة، ويُربك المراجعين، وقد يؤدي إلى قرارات تصميمية مبنية على صورة ناقصة أو مضللة عن المشكلة. يمنحك هذا الدرس إطارًا عمليًا لاتخاذ القرار — ويُعرّفك على ثلاثة أنواع أخرى من المخططات ستصادفها في العمل — لتختار الأداة المناسبة في كل مرة.
ما الغرض الحقيقي من كل نموذج؟
قبل المقارنة، ثبّت في ذهنك صورة دقيقة لغرض كل نموذج:
- المخطط الانسيابي (Flowchart): يُظهر تسلسل الخطوات والقرارات داخل عملية واحدة. السؤال المحوري: "ما الذي يحدث بعد ذلك، وبأي شرط؟" المخططات الانسيابية تُقدّم المنطق أولًا. وهي ممتازة لوصف الخوارزميات وقواعد العمل والإجراءات.
- مخطط تدفق البيانات (DFD): يُظهر ما هي البيانات التي تتحرك وإلى أين — بين العمليات والمخازن والعالم الخارجي. السؤال المحوري: "ما البيانات التي يستقبلها هذا الجزء من النظام ويحولها وينتجها؟" مخططات DFD تُقدّم البيانات أولًا. وهي ممتازة لتحديد نطاق النظام وتوصيل متطلبات البيانات لمصمم قاعدة البيانات أو المطور.
اختبار بسيط: إذا سأل شخص "كيف تعمل حسابات الغرامات في المكتبة؟" ترسم مخططًا انسيابيًا. أما إذا سأل "ما المعلومات التي يتعامل معها نظام المكتبة، ومن أين تأتي وإلى أين تذهب؟" فترسم DFD.
مقارنة جنبًا إلى جنب
تأمل السيناريو ذاته من زاويتين مختلفتين: مريض يحجز موعدًا في عيادة طبية عبر الإنترنت.
كمخطط انسيابي ستتتبع: يزور المريض صفحة الحجز ← يُدخل التفاصيل ← يتحقق النظام من التوفر ← إذا كان الموعد متاحًا، يؤكد ويحفظ؛ وإن لم يكن، يعرض البدائل ← يُرسل رسالة تأكيد ← نهاية. يُظهر المخطط كل نقطة قرار وكل فرع.
كـDFD ستُظهر: الكيان الخارجي المريض يُرسل بيانات طلب الحجز إلى عملية معالجة الحجز، التي تقرأ من مخزن بيانات جدول المواعيد وتكتب إليه، ثم تُرسل سجل التأكيد إلى مخزن الإشعارات الذي يُغذّي الكيان الخارجي خدمة البريد الإلكتروني. يُظهر المخطط كل عنصر بيانات وكل مكان يستقر فيه.
نماذج أخرى ستصادفها
المخططات الانسيابية والـDFD تمحورت حول العمليات، لكن ارتباط التحليل الشامل يستلزم أنواعًا إضافية من المخططات. إليك ملخصًا عمليًا موجزًا للأكثر شيوعًا — مع توجيه لمتى تستخدم كل منها.
مخططات حالات الاستخدام (Use Case Diagrams)
السؤال الذي تجيب عليه: من يفعل ماذا مع هذا النظام؟ تُعدّ مخططات حالات الاستخدام (UML) الحد الوظيفي للنظام من خلال إظهار الأطراف الفاعلة (أشخاص أو أنظمة أخرى) وحالات الاستخدام (الأهداف) التي يتفاعلون معها. هي ممتازة لمحادثات أصحاب المصلحة حول النطاق — سريعة القراءة ولا تستلزم خلفية تقنية. ارسمها مبكرًا للاتفاق على ما هو داخل النظام وما هو خارجه.
مخططات الفئات (Class Diagrams)
السؤال الذي تجيب عليه: ما الكيانات الرئيسية وخصائصها وكيف ترتبط ببعضها؟ مخططات الفئات (UML) هي الأداة المثلى للتواصل مع المطورين حول بنية النظام. تُظهر الفئات والخصائص والأساليب والعلاقات (ارتباط، وراثة، تركيب). استخدمها عند تسليم المتطلبات لفريق التطوير أو عند تصميم مخطط قاعدة البيانات.
مخططات التسلسل (Sequence Diagrams)
السؤال الذي تجيب عليه: بأي ترتيب زمني تتناقل الرسائل بين المكونات لسيناريو محدد؟ تُظهر مخططات التسلسل التفاعل بين الأطراف الفاعلة ومكونات النظام على خط زمني. لا غنى عنها لتوثيق تكاملات API والأنظمة القائمة على الرسائل والمنطق الداخلي لحالات الاستخدام المعقدة.
مخططات علاقة الكيانات (ERDs)
السؤال الذي تجيب عليه: ما البيانات التي يخزنها النظام بشكل دائم وكيف تُهيكَل؟ تُنمذج مخططات ERD طبقة البيانات الدائمة: الكيانات والخصائص وعلاقات الأساس. كل تصميم قاعدة بيانات يبدأ بـERD.
إطار القرار: أي نموذج تستخدم؟
استخدم جدول القرار التالي حين تجلس أمام اللوح:
سيناريو واقعي: نظام مكتبة إلكترونية
تريد مكتبة مدينة نظامًا جديدًا لاستعارة الكتب. إليك كيف يُسلسل المحلل النماذج عبر مراحل المشروع:
- الاتفاق على النطاق (الأسبوع الأول): ارسم مخطط حالات استخدام يُظهر الأطراف الفاعلة (العضو، أمين المكتبة، نظام الغرامات المتأخرة) وحالات الاستخدام (البحث في الفهرس، استعارة كتاب، إعادة كتاب، دفع غرامة، إدارة المخزون). اعرضه على أصحاب المصلحة لتأكيد ما هو في النطاق.
- حدود النظام والبيانات الخارجية (الأسبوع الثاني): ارسم DFD السياق (المستوى 0) لإظهار جميع الكيانات الخارجية وتدفقات البيانات التي تعبر حدود النظام — العضو، أمين المكتبة، بوابة الدفع، خدمة إشعارات البريد الإلكتروني، مع تدفقات بيانات مسماة. يُثبّت هذا الواجهات التي يجب بناؤها.
- تحليل العمليات (الأسبوعان الثاني والثالث): ارسم DFD المستوى الأول للمجالات الوظيفية الرئيسية: إدارة الفهرس، الاستعارة، الإعادة، الغرامات. أظهر مخازن البيانات (فهرس الكتب، سجلات الاستعارة، سجلات الأعضاء). يقود هذا تصميم قاعدة البيانات وهيكل الوحدات.
- توثيق قواعد العمل (الأسبوع الثالث): لعملية "حساب الغرامة"، ارسم مخططًا انسيابيًا: تحقق من أيام التأخير ← إذا صفر، لا غرامة؛ إذا 1–7 أيام، طبّق السعر الأساسي؛ إذا 8–30 يومًا، سعر تصاعدي؛ إذا أكثر من 30، علّق الحساب. يُوضّح هذا منطق العمل بدقة.
- تصميم البيانات (الأسبوع الرابع): ارسم ERD مبنيًا على مخازن بيانات الـDFD: كيانات العضو، الكتاب، النسخة، الاستعارة، الغرامة مع قيم الأساس والخصائص الرئيسية.
- تصميم التكامل (الأسبوع الخامس): لتكامل الدفع، ارسم مخطط تسلسل يُظهر تدفق الرسائل: العضو ← نظام المكتبة ← بوابة الدفع ← نظام المكتبة ← خدمة البريد الإلكتروني.
أخطاء شائعة في اختيار النموذج
- استخدام مخطط انسيابي حين يحتاج أصحاب المصلحة لمعرفة النطاق: مخطط انسيابي من 40 خطوة يُقدَّم لراعٍ تجاري للاتفاق على نطاق النظام سيُهمَل. استخدم مخطط حالات استخدام بدلًا منه — يستغرق قراءته 10 دقائق.
- استخدام DFD حين يحتاج المطورون للمنطق: مخطط DFD المستوى الثاني لا يُخبر المطور كيف يُنفّذ حسابًا معينًا. اكتب قاعدة العمل كمخطط انسيابي أو كود زائف.
- خلط الرموز: رسم DFD بمعيّنات القرار الخاصة بالمخطط الانسيابي يُنشئ مخططًا ينتهك كلتا المجموعتين من القواعد ويُربك الجميع. اختر رموزًا واحدة واتبع معيارها.
- الإفراط في النمذجة: رسم كل المخططات الممكنة لطلب تغيير بسيط لا يُضيف قيمة. بالنسبة لتعديل شاشة إدارة بسيطة، قد يتفوق نموذج أولي موضّح بتعليقات على ثلاثة مخططات رسمية.
اختيار النموذج حكم مهني يتطور مع الخبرة. كقاعدة عمل: انطلق من السؤال الذي يطرحه أصحاب المصلحة فعليًا، حدد من سيقرأ المخطط، واختر الرموز التي تُجيب على السؤال بأكثر الطرق مباشرةً دون إلزام القارئ بتعلم لغة جديدة أولًا.