كل مفهوم تناولناه في هذه الوحدة التدريبية — الانتقال من التحليل إلى التصميم، وطبقات المعمارية، وتفكيك الوحدات، وعقود الواجهات، وتصميم طبقة البيانات، وتصميم المدخلات والمخرجات، والوثيقة المكتوبة — يتقاطع في مخرج نهائي واحد: وثيقة مواصفات التصميم. في هذا الدرس ستبني وثيقة مواصفات مدمجة لكنها متكاملة لنظام واقعي، وستعمل عبر كل قسم خطوة بخطوة. الأسلوب قابل للتكرار: بمجرد إتقانه يمكنك تطبيقه على أي مشروع بأي حجم.
دراسة الحالة هي منصة لوجستية لشركة صغيرة تُسمى SwiftRoute. تستخدمها شركة بريد إقليمية لإدارة شحنات العملاء وتعيين السائقين وتتبع التسليمات في الوقت الفعلي. اكتمل تحليل المتطلبات ومخطط العلاقات الكيانية في المراحل السابقة؛ وهنا ينتقل فريق المحللين من التحليل إلى تصميم متسق.
القسم الأول: نظرة عامة على النظام ونطاقه
يوجّه القسم الأول في أي وثيقة مواصفات تصميم القارئ نحو فهم النظام، إذ يحدد ما يفعله النظام، وأي نسخة تغطيها هذه الوثيقة، وأي أصحاب المصلحة وافقوا عليها.
SwiftRoute Logistics Platform — Design Specification v1.0
System: Shipment management, driver dispatch, and real-time delivery tracking
Scope: Customer-facing web portal + internal dispatch console + driver mobile app
In scope: Shipment lifecycle (create → assign → in-transit → delivered/failed)
Out of scope: Billing/invoicing (Phase 2), fleet maintenance module (Phase 3)
Prepared by: Systems Analysis Team
Approved by: Head of Operations, CTO
Date: 2024-09-01
حدود النطاق بالغة الأهمية: فهي تمنع زحف النطاق من إعادة دخوله أثناء التصميم، وتجعل الوثيقة قابلة للمراجعة في إطار زمني معقول.
القسم الثاني: التصميم المعماري
يشرح السرد المعماري الموجز لماذا اختير الهيكل المحدد بدلاً من البدائل. بالنسبة لـ SwiftRoute اختار الفريق معمارية ويب ثلاثية الطبقات مع طبقة واجهة برمجة تطبيقات مخصصة للتطبيق المحمول للسائقين. المبرر: يعمل فريق العمليات على وحدة التعيين من متصفحات سطح المكتب، لكن الأربعين سائقاً النشطاً يستخدمون هواتف أندرويد عبر شبكات خلوية — ملامح الكمون وعرض النطاق الترددي المختلفة تستدعي واجهة برمجة تطبيقات خفيفة الوزن مخصصة.
المعمارية ثلاثية الطبقات لـ SwiftRoute: عملاء العرض، وخدمات التطبيق (بما فيها واجهة برمجة مخصصة للسائق)، ومخازن البيانات.
القسم الثالث: تفكيك الوحدات
تسمّي المعمارية الطبقات؛ أما تفكيك الوحدات فيسمّي ما يسكن داخل كل طبقة وما تتحمله كل وحدة من مسؤوليات. يظهر هذا في الوثيقة على شكل جدول أو قائمة منظمة — لا وصف مبهم، بل تعيين مسؤوليات دقيق.
MODULE REGISTER — Application Tier (Tier 2)
┌──────────────────────┬───────────────────────────────────────────────────────┐
│ Module │ Responsibilities │
├──────────────────────┼───────────────────────────────────────────────────────┤
│ Shipment Service │ Create, update, cancel shipments; validate addresses; │
│ │ calculate ETAs; expose REST endpoints for portal. │
├──────────────────────┼───────────────────────────────────────────────────────┤
│ Dispatch Service │ Assign drivers to shipments; enforce zone rules; │
│ │ requeue failed assignments; expose console endpoints. │
├──────────────────────┼───────────────────────────────────────────────────────┤
│ Driver API │ Accept driver location pings; accept status updates │
│ │ (picked-up, delivered, failed); optimised for mobile. │
├──────────────────────┼───────────────────────────────────────────────────────┤
│ Notification Service │ Send email/SMS on shipment events; queue-based; │
│ │ retryable; no direct DB writes. │
└──────────────────────┴───────────────────────────────────────────────────────┘
القسم الرابع: مواصفات الواجهات الرئيسية
توثّق الوثيقة الكاملة كل واجهة؛ وفي وثيقة المشروع المدمجة هذه نغطي الواجهتين الأكثر أهمية — نقطة نهاية إنشاء شحنة العميل ونقطة نهاية تحديث حالة السائق — لأنهما تحملان أعلى مخاطر التكامل.
قواعد انتقال الحالة تنتمي إلى الوثيقة. يعني خطأ INVALID_STATUS_TRANSITION أن النظام يشترط ألا يُعلّم السائق شحنةً على أنها delivered دون أن تمر أولاً بحالة picked_up. التقط هذه القواعد المستمدة من آلة الحالة في الوثيقة — لا كملاحظات مؤجلة في تعليقات الكود.
القسم الخامس: تصميم طبقة البيانات
يربط قسم طبقة البيانات كيانات مخطط ERD بجداول ملموسة، ويشير إلى المفاتيح الأساسية والأجنبية، ويُبرز أي قرارات تتعلق بالأداء (فهارس، تقسيم، نسخ قراءة). بالنسبة لـ SwiftRoute:
TABLE: shipments
shipment_id BIGINT PK AUTO_INCREMENT
sender_id INT FK → customers(customer_id)
recipient_name VARCHAR(120) NOT NULL
recipient_addr TEXT NOT NULL
weight_kg DECIMAL(6,2) NOT NULL
service_level ENUM('standard','express','same-day') NOT NULL
status ENUM('created','assigned','picked_up','in_transit','delivered','failed')
tracking_code VARCHAR(20) UNIQUE NOT NULL
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
INDEX: (sender_id), (status), (tracking_code)
TABLE: driver_locations
location_id BIGINT PK
driver_id INT FK → drivers(driver_id)
shipment_id BIGINT FK → shipments(shipment_id)
lat DECIMAL(9,6), lng DECIMAL(9,6)
recorded_at TIMESTAMP
NOTE: High-frequency insert table — partitioned by MONTH(recorded_at).
Only last 30 days retained in primary partition; older rows archived.
القسم السادس: تصميم المدخلات والمخرجات
تشمل الوثيقة أوصافاً بمستوى النماذج الأولية للواجهات الرئيسية. التصاميم الكاملة بدقة البكسل تنتمي إلى النموذج الأولي لواجهة المستخدم، لكن يجب أن توثق الوثيقة أسماء الحقول وقواعد التحقق وصيغ المخرجات حتى يتمكن أي مطور — أو مراجع يفحص التتبع — من التحقق من التوافق مع المتطلبات.
نموذج أولي: نموذج إنشاء الشحنة (يسار) مع ملاحظات التحقق، وعرض التتبع (يمين) مع جدول الحالة الزمني المباشر.
القسم السابع: ملخص التتبع
يُعدّ القسم الأخير في وثيقة المواصفات المدمجة لقطة للتتبع: جدول يربط كل متطلب وظيفي بعنصر التصميم الذي يحققه. حتى جدول قصير يُثبت أنه لم يُغفل شيء ويمنح المراجعين مكاناً لتحدي الثغرات.
TRACEABILITY SNAPSHOT (selected rows)
┌────────┬─────────────────────────────────────┬────────────────────────┬──────────────┐
│ Req ID │ Requirement │ Design Element │ Status │
├────────┼─────────────────────────────────────┼────────────────────────┼──────────────┤
│ FR-01 │ Customer books a shipment online │ IF-1, Shipment Service │ Designed │
│ FR-02 │ Dispatcher assigns driver to order │ Dispatch Service UI │ Designed │
│ FR-03 │ Driver updates status from mobile │ IF-2, Driver API │ Designed │
│ FR-04 │ Customer tracks shipment in real- │ Tracking View, Redis │ Designed │
│ │ time via tracking code │ cache layer │ │
│ FR-05 │ System sends SMS on delivery │ Notification Service │ Designed │
│ NFR-01 │ Tracking page loads in < 1 second │ Redis cache + CDN │ Designed │
│ NFR-02 │ Driver API available on 2G/3G │ Lightweight REST API │ Designed │
└────────┴─────────────────────────────────────┴────────────────────────┴──────────────┘
أبقِ الوثيقة حيّة، لا محفوظة في أرشيف. بعد مراجعة التصميم، حدّث جدول التتبع مع تنفيذ كل عنصر تصميم واختباره. الوثيقة التي تعكس النظام المبني هي أصل صيانة لا يُقدَّر بثمن؛ أما الوثيقة التي تنحرف عن الكود فهي التزام مثقل. عيّن مالكاً ودورة مراجعة قبل أن ينتقل المشروع إلى التطوير.
ما الذي يجعل وثيقة التصميم جيدة؟
بالنظر إلى SwiftRoute، الخصائص التي تجعل هذه الوثيقة فعّالة هي: أنها محددة النطاق (العناصر خارج النطاق مدرجة صراحةً)، منظمة البنية (لكل قسم غرض محدد)، قابلة للتتبع (كل متطلب يرتبط بعنصر تصميم)، وقابلة للمراجعة (الرسوم البيانية والجداول تتيح للمراجع اكتشاف الثغرات في دقائق لا ساعات). لا تحتاج وثيقة التصميم إلى أن تكون طويلة — بل تحتاج أن تكون متكاملة ضمن نطاقها.
نمط الفشل الأكثر شيوعاً هو وثيقة قوية في مخططات المعمارية لكنها صامتة بشأن حالات أخطاء الواجهات وقواعد التحقق من صحة البيانات. يتخذ المطورون حينئذٍ افتراضات مستقلة حول هذه الثغرات فيفشل التكامل. أعطِ دائماً لكل واجهة قائمة أخطاء مسماة، ولكل حقل إدخال قاعدة تحقق مصرّح بها — حتى لو كانت مجرد "الحد الأقصى 255 حرفاً".
اكتمل الدرس!
تهانينا! لقد أكملت جميع الدروس في هذا البرنامج التعليمي.
نستخدم ملفات تعريف الارتباط لتشغيل هذا الموقع وتحليل الزيارات وعرض إعلانات مخصّصة. يمكنك قبول كل ملفات تعريف الارتباط أو رفض غير الأساسية منها.
سياسة الخصوصية