ملخص تقني: التطوير القائم على البروتوكول (PDD)

بيان المشكلة

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

• التطوير القائم على المواصفات (SDD): المواصفات المكتوبة باللغة الطبيعية تتسم بالغموض الدلالي، مما يؤدي إلى انحراف في التفسير وتضارب في الافتراضات بين مختلف المهندسين أو الأنظمة التوليدية.
• التطوير القائم على الاختبار (TDD): رغم أن الاختبارات توفر أدلة قابلة للتنفيذ، إلا أنها وصفية خارجية (تتحقق من حالات مختارة) وليست وصفية داخلية (تحدد كامل فضاء التنفيذ المقبول). وغالباً ما تفشل في التقاط العقود الهيكلية، أو حدود السلطة، أو القيود التشغيلية مثل حدود زمن الاستجولة (latency) أو قيود الآثار الجانبية.
• "ضريبة اللغة الطبيعية": التكلفة المتكررة لتفسير وتوفيق وصيانة الأوصاف النصية الغامضة تخلق فجوة بين القصد والقيود القابلة للإنفاذ.

عندما يمكن توليد الكود وتجديده بتكلفة منخفضة، يصبح الكود المصدري أقل ديمومة من القيود التي تحدد مدى قبوله. لذا، ينتقل التحدي المركزي من "كيفية التنفيذ" إلى "ما هي القيود التي يجب أن يستوفيها كل تنفيذ مقبول".

المنهجية: التطوير القائم على البروتوكول (PDD)

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

الصياغة البروتوكولية

يُعرف البروتوكول $P$ بأنه ثلاثية $P = (S, B, O)$، حيث يحدد تلازم هذه الفئات الثلاث من الثوابت فضاء التنفيذ المقبول ($I_P$):

1. الثوابت الهيكلية ($S$): قيود صارمة على الأنواع والمخططات (schemas) للمدخلات، والمخرجات، وتواقيع الواجهات، وقواعد الإصدار (مثل JSON Schema، أو OpenAPI، أو Protocol Buffers). تضمن هذه الثوابت عملية مصافحة (handshake) محددة النوع.
2. الثوابت السلوكية ($B$): محمولات دلالية (semantic predicates) يجب أن تتحقق لجميع المدخلات والحالات الصالحة (مثل: التكرارية/idempotence، الحتمية/determinism، الرتابة/monotonicity). يتم ترميز هذه كادعاءات قائمة على الخصائص أو قوانين منطقية بدلاً من حالات اختبار محددة.
3. الثوابت التشغيلية ($O$): حدود القدرات الصريحة التي تغطي الآثار الجانبية، والاعتمادات الخارجية، وزمن الاستجولة، واستهلاك الذاكرة، وحصص الموارد. تعمل هذه كبيانات إعلان للقدرات (capability manifests) أو حدود للسياسات.

حلقة التحقق (The Validator Loop)

يقدم PDD نمطاً معمارياً يفصل دورة حياة البرمجيات إلى أدوار متميزة:

1. تأليف البروتوكول: ترجمة القصد المعماري إلى الثلاثية القابلة للإنفاذ آلياً $(S, B, O)$.
2. توليد التنفيذ: تبحث المولدات الآلية في فضاء التنفيذ عن نماذج مرشحة تستوفي البروتوكول.
3. التحقق: يقوم محرك التحقق بإجراء ثلاثة مستويات من الفحص:
   • التحقق الهيكلي (مطابقة الواجهة).
   • التحقق السلوكي (الاختبار القائم على الخصائص، والعلاقات التحولية).
   • التحقق التشغيلي (التنفيذ داخل بيئة معزولة للتحقق من حدود القدرات).
4. القبول القائم على إنتاج الأدلة: لا يُقبل التنفيذ إلا إذا أصدر المحقق سلسلة أدلة (Evidence Chain) موقعة. تربط هذه السلسلة تشفيرياً إصدار البروتوكول، وقطعة التنفيذ، وهوية المحقق، ونتائج التحقق.

الأسس النظرية

يصيغ البحث PDD من خلال عدة علاقات رئيسية:

• مجموعة التنفيذ المقبول: $I_P = I_S \cap I_B \cap I_O$. يحدد البروتوكول منطقة في فضاء التنفيذ، وليس برنامجاً واحداً.
• القابلية للاستبدال على مستوى البروتوكول: يكون التنفيذان قابلين للاستبدال إذا استوفى كلاهما البروتوكول $P$ وكان العميل يعتمد فقط على الضمانات التي يقتضيها $P$. يسمح هذا بإعادة التوليد والتحسين دون كسر التبعات، طالما أن تلك التبعات "تحترم البروتوكول".
• السلامة (Soundness): يكون المحقق سليماً إذا لم يقبل إلا التنفيذات التي تستوفي البروتوكول. ويفترض البحث أن القبول لا يكون ذا معنى إلا بالنسبة لمحقق سليم وبروتوكول محدد.

المساهمات الرئيسية

يقدم البحث المساهمات المحددة التالية:

1. اقتراح الإطار العملي: تقديم PDD كإطار عمل يعامل البروتوكولات، لا الكود، كمنتج دائم للهندسة المؤتمتة.
2. الصياغة الرسمية: تعريف البروتوكول كثلاثية من الثوابت الهيكلية والسلوكية والتشغيلية التي تحدد مجتمعة فضاء التنفيذ المقبول.
3. العلاقات الجوهرية: تعريف الامتثال للبروتوكول، والقابلية للاستبدال على مستوى البروتوكول، والقبول القائم على إنتاج الأدلة كعلاقات حاكمة للقبول.
4. النمط المعماري: رسم حلقة التحقق، التي تفصل بين تأليف البروتوكول، والتوليد، والتحقق، وحفظ الأدلة.
5. المنتجات الجديدة: تقديم سلاسل الأدلة (Evidence Chains) وسجلات الاكتشاف (Discovery Logs) لربط المرشحين بنتائج التحقق والمنشأ، مما يتيح إمكانية التدقيق وإعادة التشغيل.
6. التحليل المفاهيمي: توصيف "ضريبة اللغة الطبيعية" والمجادلة بأن البروتوكولات القابلة للإنفاذ آلياً توفر مساراً منضبطاً من القصد السردي إلى شروط القبول الصريحة.
7. التوليف: ربط PPD بكل من الأساليب الرسمية، والاختبار القائم على الخصائص، والسياسة ككود، ومنشأ البرمجيات، والحوكمة وقت التشغيل للأنظمة المستقلة.

النتائج والادعاءات

لا يقدم البحث نتائج تجريبية (مثل أداء الاختبارات المعيارية أو مقاييس دراسة الحالة) بل يقدم مقترحاً نظرياً ومعمارياً. وتأتي ادعاءاته في إطار فرضيات للتحقق التجريبي المستقبلي:

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

الأهمية والتموضع

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

• التميز عن العمل الحالي: على عكس التطوير القائم على المخططات (الذي يركز على الهيكل)، أو التطوير القائم على الاختبار (الذي يركز على الأمثلة الوظيفية)، أو السياسة ككود (التي تعمل غالباً وقت التشغيل)، يرفع PDD حزمة البروتوكول لتكون المنتج الأساسي الذي يحكم مجتمعاً من الهيكل، والسلوك، والسلطة التشغيلية، وأدلة القبول.
• الفلسفة: الأطروحة الجوهرية هي "الكود عابر؛ والبروتوكول سيادي". عندما تقترب تكاليف التنفيذ من الصفر، يصبح المنتج الفكري لهندسة البرمجيات هو مجموعة القيود الرسمية التي تحدد السلوك المقبول والأدلة على احترام تلك القيود.
• العمل المستقبلي: يحدد البحث أجندة تجريبية لاختبار PDD مقابل خطوط الأساس لـ SDD و TDD، مع التركيز على تقليل الغموض، وموثوقية إعادة التوليد، والقابلية للاستبدال، وتكاليف التحقق، وفعالية الحوكمة. كما يقترح اتجاهات مستقبلية تشمل سجلات البروتوكول القابلة لإعادة الاستخدام، والتوليد الآلي للبروتوكولات، والاندماج الأعمق مع أدوات التحقق الرسمي.

باختصار، يقترح PDD طبقة حوكمة للهندسة البرمجية المؤتمتة حيث يكون "القانون" هو البروتوكول، و"المواطنون" هم التنفيذات المولدة التي لا تُقبل إلا من خلال أدلة قابلة للتحقق من الامتثال.