الانتقال من التحليل إلى التصميم

الانتقال من التحليل إلى التصميم

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

يرسم هذا الدرس ذلك الجسر بدقة: ما الذي تحمله معك من التحليل، وما الذي تتركه وراءك، وكيف يتلاءم الانضباطان دون أن يتداخل أحدهما في منطقة الآخر.

انضباطان على خط واحد متصل

التحليل هو انضباط الفهم. مهمته بناء نموذج كامل ومحايد تقنياً يصف ما يجب أن يفعله النظام المقترح — المتطلبات، وقواعد الأعمال، والبيانات التي يجب تذكّرها، والجهات الفاعلة التي تتفاعل معه، والعمليات التي يجب دعمها. مخرجاته أدوات مثل مخططات حالات الاستخدام، وERDs، وDFDs، ومخططات الأصناف، ومواصفات متطلبات البرمجيات (SRS). التحليل خالٍ من التنفيذ عن قصد: لا يسأل أبداً عن قاعدة البيانات التي ستستخدمها، أو الإطار الذي ستختاره، أو كيف ستبدو الشاشات.

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

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

ما الذي يُنقل — ولماذا

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

• نموذج حالات الاستخدام → حدود المكونات ونقاط نهاية API. كل حالة استخدام تصف هدفاً للمستخدم؛ يجب أن يُحدد التصميم أي مكوّن يُعالج ذلك الهدف، وفي الأنظمة الموزعة أي نقطة نهاية API تُعرضه. حالة الاستخدام "حجز موعد" في نظام عيادة ستُعيَّن إلى مكوّن خدمة الحجز مع نقطة نهاية POST /appointments.
• المتطلبات الوظيفية → ميزات النظام ومسؤوليات الوحدات. كل متطلب وظيفي (FR) يصبح قدرة مُعيَّنة لوحدة محددة. إذا نصّت SRS على "يجب على النظام إرسال بريد تأكيد عند تأكيد الحجز"، يجب أن يُعيّن التصميم تلك المسؤولية لوحدة إشعارات صريحة.
• المتطلبات غير الوظيفية (NFRs) → قيود معمارية. تقود المتطلبات غير الوظيفية أكبر الخيارات المعمارية. متطلب وقت استجابة أقل من 200 ميلي ثانية للبحث يدفع التصميم نحو طبقة تخزين مؤقت (caching). ومتطلب الاحتفاظ بالبيانات يقود استراتيجية تقسيم قاعدة البيانات والأرشفة. المتطلبات غير الوظيفية هي المدخل الأقل استغلالاً في التصميم — تجاهلها هو السبب في نجاح الأنظمة في اختبار قبول المستخدم ثم فشلها في الإنتاج.
• ERD المنطقي → مخطط قاعدة البيانات الفعلي. الكيانات والسمات والعلاقات في ERD تصبح جداول وأعمدة ومفاتيح خارجية. تُضيف طبقة التصميم أنواع البيانات والفهارس ومحركات التخزين. لا ينبغي أن يكون أي شيء في المخطط الفعلي غير قابل للتتبع في ERD.
• نموذج الأصناف → تصميم أصناف البرنامج / الخدمات. مخطط الأصناف التحليلي — الذي يُظهر المفاهيم والعلاقات دون توابع — يصبح أساس مخطط الأصناف في التصميم البرمجي، الذي يُضيف العمليات ومُعدّلات الوصول وأنماط التنفيذ.
• كتالوج قواعد الأعمال → منطق التحقق والقيود. كل قاعدة أعمال (مثل "لا يجوز للمريض حجز موعدين في اليوم ذاته في التخصص ذاته") يجب تطبيقها في مكان ما من التصميم: قيد قاعدة بيانات، أو تحقق على مستوى التطبيق، أو قاعدة موثقة في عقد API.

ما الذي لا يُنقل

بنفس القدر من الأهمية هو فهم ما يتجنبه التحليل عن قصد، حتى لا يُخطئ التصميم في اعتبار حريته فجوة في التحليل:

• اختيارات التقنية — يقول التحليل "يجب على النظام تخزين سجلات المرضى"؛ ويقول التصميم "سنستخدم MySQL مع InnoDB". اللحظة التي يُحدد فيها التحليل محرك قاعدة بيانات يكون قد تجاوز دوره وربما قيّد قراراً تصميمياً دون دليل كافٍ.
• آليات التنفيذ — يُظهر التحليل أن إشعاراً يجب إرساله؛ ويختار التصميم ما إن كان بريداً إلكترونياً أو رسالة نصية أو إشعار دفع أو الثلاثة معاً — وأي مزود خدمة يُستخدم.
• تخطيطات الشاشة والنماذج الأولية — قد يلتقط التحليل متطلبات الإدخال/الإخراج (ما الحقول التي تظهر في نموذج الحجز)، لكن الترتيب البصري والتصميم وتدفق تجربة المستخدم هي مخاوف تصميمية.
• تفاصيل ضبط الأداء — يُحدد التحليل متطلبات وقت الاستجابة (NFRs)؛ ويقرر التصميم ما إن كان يُحققها بشبكة CDN أو نسخة قراءة أو ذاكرة تخزين مؤقت أو طابور انتظار. المتطلب هو NFR؛ والآلية هي التصميم.

الانتقال في الممارسة: مثال شركة لوجستية

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

1. نموذج حالات استخدام يضم 14 حالة (تتبع الطرد، إنشاء شحنة، تعيين سائق، الإبلاغ عن تلف، إلخ)
2. SRS تحتوي على 47 متطلباً وظيفياً و12 متطلباً غير وظيفي (بما فيها: يجب تحديد موقع الطرود في غضون 30 ثانية من تسجيل حدث المسح)
3. ERD منطقي يضم 9 كيانات: Parcel، Shipment، Leg، Driver، Vehicle، Depot، ScanEvent، Customer، Address
4. مخططات تسلسل لحالات الاستخدام الثلاث الأكثر تعقيداً
5. كتالوج قواعد أعمال يحتوي على 23 قاعدة

الآن يتولى فريق التصميم المهمة. لا يبدأون من صفحة بيضاء — بل من تلك الأدوات الخمس. الـ14 حالة استخدام توجّه أين تذهب حدود المكونات. متطلب تحديد الموقع في 30 ثانية (NFR) يُشير فوراً إلى أن أحداث المسح تحتاج نهجاً لـ event-sourcing أو تخزين السلاسل الزمنية، لا جدول OLTP عادي. الكيانات التسعة في ERD تُعيَّن لـ11 جدولاً (جدولا ربط إضافيان لحل علاقات الكثير بالكثير). كل قرار تصميمي يمكن تبريره بالإشارة إلى متطلب محدد أو كيان ERD.

أكثر أخطاء الانتقال شيوعاً

ثلاثة أنماط من الفشل تحدث في كل فريق يُجري هذا الانتقال للمرة الأولى تقريباً:

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

ملخص

• التحليل يُجيب على ماذا — يُنتج نموذجاً محايداً تقنياً للسلوك المطلوب والبيانات.
• التصميم يُجيب على كيف — يتخذ قرارات معمارية وهيكلية ملموسة، كلها قابلة للتتبع إلى مخرجات التحليل.
• منطقة التسليم تتألف من مواصفة التصميم ومصفوفة قابلية التتبع التي تُعيّن كل عنصر تصميمي إلى أداة تحليل واحدة على الأقل.
• حالات الاستخدام تُعيَّن لمكونات ونقاط نهاية API؛ والمتطلبات الوظيفية لمسؤوليات الوحدات؛ والمتطلبات غير الوظيفية تقود القيود المعمارية؛ وكيانات ERD تصبح جداول؛ وقواعد الأعمال تصبح منطق تحقق وقيوداً.
• اختيارات التقنية وتخطيطات الشاشة وآليات التنفيذ هي منطقة التصميم — يجب ألا يُقرّها التحليل صراحةً أو ضمنياً.
• أخطاء الانتقال الثلاثة — التصميم المبكر، وإعادة فتح المتطلبات، وفقدان قابلية التتبع — كلها قابلة للوقاية بالانضباط وبروتوكولات فريق واضحة.