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

تصميم المدخلات والمخرجات

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

تصميم المدخلات والمخرجات

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

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

مبادئ تصميم المدخلات

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

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

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

تشريح تصميم النموذج

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

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

قواعد التحقق كمنتجات تصميمية

التحقق من صحة البيانات ليس شاغلاً يُضاف لاحقاً بعد التصميم — بل هو قرار تصميمي جوهري. لكل حقل مدخلات، يجب على المحلل تحديد قاعدة تحقق تحدد القيم التي يقبلها النظام. تظهر هذه القواعد في مواصفة التصميم وتصبح مرجعاً للتنفيذَين الأمامي والخلفي معاً.

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

Field             | Rule Type       | Constraint                     | Error Message
------------------|-----------------|--------------------------------|-----------------------------------
firstName         | required        | not empty                      | "First name is required."
firstName         | length          | 2 – 60 characters              | "Name must be 2 to 60 characters."
dateOfBirth       | required        | not empty                      | "Date of birth is required."
dateOfBirth       | range           | >= 1900-01-01, <= today  | "Enter a valid date of birth."
email             | format          | RFC 5322 pattern               | "Enter a valid email address."
phone             | format (opt.)   | E.164 or local pattern         | "Enter a valid mobile number."
documentFile      | file type       | PDF, JPG, PNG only             | "Only PDF, JPG, or PNG files are accepted."
documentFile      | file size       | <= 2 MB                     | "File must not exceed 2 MB."

حدّد قواعد التحقق المشتركة بين حقول متعددة بوضوح. بعض التحقق يمتد عبر أكثر من حقل: "إذا كانت paymentMethod تساوي Bank Transfer، فإن bankAccountNumber مطلوب." هذه القواعد الشرطية يسهل إغفالها إذا تحققت من كل حقل على حدة. وثّقها كقاعدة عمل مسمّاة في المواصفة.

مبادئ تصميم المخرجات

يحكم تصميم المخرجات التقارير ولوحات المعلومات وشاشات التأكيد والمطبوعات وتصدير البيانات. المخرجات توصّل القيمة التي يولّدها النظام. التصميم السيء للمخرجات يدفن هذه القيمة تحت أعمدة غير ذات صلة وتسميات متضاربة وتنسيق يتفاوت بين الشاشات والمطبوعات.

وافق الجمهور المستهدف. مدير العمليات يريد مؤشرات أداء رئيسية موجزة مع إمكانية التعمق. موظف المستودع يريد قائمة تحضير صنف بصنف مرتّبة حسب موقع الرف. مدقق الحسابات يريد تفاصيل على مستوى كل معاملة مع إجماليات تراكمية. صمّم كل مخرج لمستهلكه، لا لمخطط قاعدة البيانات.
حدّد مصدر البيانات. كل رقم محسوب في تقرير يحتاج إلى قاعدة اشتقاق موثّقة في المواصفة: "الإيراد الشهري = SUM(orderTotal) حيث orderDate يقع ضمن الشهر المحدد وstatus = Paid."
حدّد التجميع والترتيب. تقرير يسرد 2,000 طلب بترتيب المفتاح الأساسي غير قابل للاستخدام. حدّد: تجميع حسب المنطقة، ترتيب تنازلي حسب الإيراد، إجماليات فرعية لكل مجموعة.
حدّد الفلاتر والمعاملات. التقرير المفيد يقبل معاملات — المستخدم يختار نطاقاً زمنياً أو قسماً أو فئة منتج قبل تشغيله. وثّق اسم كل معامل ونوعه وقيمته الافتراضية وما إذا كان مطلوباً.
تعامل مع الاستثناءات. ماذا يعرض التقرير حين لا توجد بيانات للفترة المحددة؟ صمّم الحالة الفارغة — رسالة مثل "لا توجد طلبات للربع الثاني من 2025" أفضل بكثير من صفحة فارغة.

مواصفة تخطيط التقرير

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

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

ربط المدخلات والمخرجات بالتصميم الأشمل

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

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

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

خلاصة

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