التصميم حسب العقد

التصميم عن طريق العقد ( DbC )، والمعروف أيضًا باسم برمجة العقد ، والبرمجة عن طريق العقد ، وبرمجة التصميم عن طريق العقد ، هو نهج لتصميم البرمجيات .

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

يفترض نهج DbC أن جميع مكونات العميل التي تستدعي عملية على مكون الخادم ستلبي الشروط المسبقة المحددة على أنها مطلوبة لتلك العملية.

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

تم صياغة المصطلح بواسطة برتراند ماير فيما يتعلق بتصميمه للغة برمجة إيفل وتم وصفه لأول مرة في مقالات مختلفة بدءًا من عام 1986 ^{[1] [2] [3]} والطبعتين المتتاليتين (1988، 1997) من كتابه بناء البرمجيات الموجهة للكائنات . تقدمت شركة إيفل للبرمجيات بطلب تسجيل العلامة التجارية للتصميم بالعقد في ديسمبر 2003، وتم منحها في ديسمبر 2004. ^{[4] [5]} المالك الحالي لهذه العلامة التجارية هو شركة إيفل للبرمجيات. ^{[6] [7]}

يعود أصل التصميم بالتعاقد إلى العمل على التحقق الرسمي والمواصفات الرسمية ومنطق هوار . تشمل المساهمات الأصلية ما يلي:

• استعارة واضحة لتوجيه عملية التصميم
• التطبيق على الميراث ، وخاصة الصيغة الخاصة بإعادة التعريف والربط الديناميكي
• تطبيق لمعالجة الاستثناءات
• الاتصال مع توثيق البرامج التلقائي

الفكرة الأساسية لـ DbC هي استعارة لكيفية تعاون عناصر نظام البرمجيات مع بعضها البعض على أساس الالتزامات والفوائد المتبادلة. تأتي الاستعارة من الحياة التجارية ، حيث يتفق "العميل" و"المورد" على "عقد" يحدد، على سبيل المثال، ما يلي:

• يجب على المورد توفير منتج معين (التزام) ويحق له أن يتوقع من العميل أن يدفع رسومه (الفائدة).
• يجب على العميل دفع الرسوم (الالتزام) وله الحق في الحصول على المنتج (الاستفادة).
• يتعين على الطرفين الوفاء بالتزامات معينة، مثل القوانين واللوائح، التي تنطبق على كافة العقود.

وبالمثل، إذا كانت طريقة الفئة في البرمجة الموجهة للكائنات توفر وظيفة معينة، فقد:

• توقع وجود شرط معين يجب ضمانه عند الدخول بواسطة أي وحدة عميل تستدعيه: الشرط المسبق للطريقة - وهو التزام على العميل، وفائدة للمورد (الطريقة نفسها)، لأنه يحرره من الاضطرار إلى التعامل مع الحالات خارج الشرط المسبق.
• ضمان خاصية معينة عند الخروج: الشرط اللاحق للطريقة - التزام على المورد، ومن الواضح أنه فائدة (الفائدة الرئيسية لاستدعاء الطريقة) للعميل.
• الحفاظ على خاصية معينة، مفترضة عند الدخول ومضمونة عند الخروج: الفئة الثابتة .

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

• ماذا يتوقع العقد؟
• ماذا يضمن العقد؟
• ماذا يحافظ العقد؟

تتمتع العديد من لغات البرمجة بإمكانيات تقديم تأكيدات مثل هذه. ومع ذلك، تعتبر DbC هذه العقود بالغة الأهمية لصحة البرمجيات بحيث يجب أن تكون جزءًا من عملية التصميم. في الواقع، تؤيد DbC كتابة التأكيدات أولاً . ^{[ بحاجة لمصدر ]} يمكن كتابة العقود من خلال تعليقات التعليمات البرمجية ، أو فرضها من خلال مجموعة اختبار ، أو كليهما، حتى إذا لم يكن هناك دعم لغوي خاص للعقود.

يمتد مفهوم العقد إلى مستوى الطريقة/الإجراء؛ حيث يحتوي العقد الخاص بكل طريقة عادةً على المعلومات التالية: ^{[ بحاجة لمصدر ]}

• قيم أو أنواع الإدخال المقبولة وغير المقبولة ومعانيها
• قيم الإرجاع أو الأنواع ومعانيها
• قيم أو أنواع حالات الخطأ والاستثناء التي يمكن أن تحدث ومعانيها
• تأثيرات جانبية
• الشروط المسبقة
• الشروط اللاحقة
• الثوابت
• (نادرًا ما) ضمانات الأداء، على سبيل المثال للوقت أو المساحة المستخدمة

يُسمح للفئات الفرعية في التسلسل الهرمي للوراثة بإضعاف الشروط المسبقة (ولكن ليس تقويتها) وتعزيز الشروط اللاحقة والثوابت (ولكن ليس إضعافها). تقترب هذه القواعد من التصنيف الفرعي السلوكي .

كل علاقات الفئات تكون بين فئات العميل وفئات المورد. فئة العميل ملزمة بإجراء مكالمات إلى ميزات المورد حيث لا يتم انتهاك الحالة الناتجة للمورد من خلال استدعاء العميل. بعد ذلك، يكون المورد ملزمًا بتوفير حالة إرجاع وبيانات لا تنتهك متطلبات حالة العميل.

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

عند استخدام العقود، لا ينبغي للمورد أن يحاول التحقق من استيفاء شروط العقد - وهي ممارسة تُعرف باسم البرمجة الهجومية - والفكرة العامة هي أن الكود يجب أن "يفشل بشدة"، مع اعتبار التحقق من العقد بمثابة شبكة الأمان.

تعمل خاصية "الفشل الشديد" في DbC على تبسيط عملية تصحيح سلوك العقد، حيث يتم تحديد السلوك المقصود لكل طريقة بوضوح.

يختلف هذا النهج بشكل كبير عن نهج البرمجة الدفاعية ، حيث يكون المورد مسؤولاً عن معرفة ما يجب فعله عند كسر شرط مسبق. في أغلب الأحيان، يطرح المورد استثناءً لإبلاغ العميل بأن الشرط المسبق قد تم كسره، وفي كلتا الحالتين - DbC والبرمجة الدفاعية على حد سواء - يجب على العميل معرفة كيفية الاستجابة لذلك. في مثل هذه الحالات، يجعل DbC مهمة المورد أسهل.

يحدد التصميم عن طريق العقد أيضًا معايير صحة وحدة البرنامج:

• إذا كانت الفئة الثابتة AND الشرط المسبق صحيحًا قبل استدعاء المورد بواسطة العميل، فإن الفئة الثابتة AND الشرط اللاحق سيكونان صحيحين بعد اكتمال الخدمة.
• عند إجراء مكالمات إلى المورد، يجب ألا تنتهك وحدة البرنامج الشروط المسبقة للمورد.

يمكن أن يسهل التصميم بالعقد أيضًا إعادة استخدام التعليمات البرمجية، حيث يتم توثيق العقد الخاص بكل جزء من التعليمات البرمجية بشكل كامل. يمكن اعتبار العقود الخاصة بوحدة ما بمثابة شكل من أشكال توثيق البرامج لسلوك هذه الوحدة.

لا ينبغي انتهاك شروط العقد مطلقًا أثناء تنفيذ برنامج خالٍ من الأخطاء. لذلك، عادةً ما يتم فحص العقود في وضع التصحيح أثناء تطوير البرنامج. وفي وقت لاحق من الإصدار، يتم تعطيل عمليات فحص العقد لتحقيق أقصى قدر من الأداء.

في العديد من لغات البرمجة، يتم تنفيذ العقود باستخدام assert . يتم تجميع التأكيدات افتراضيًا في وضع الإصدار في C/C++، ويتم تعطيلها بشكل مماثل في C# ^[8] وJava.

سيؤدي تشغيل مُفسِّر Python باستخدام "-O" (لـ "optimize") كحجة أيضًا إلى عدم إصدار مُنشئ كود Python لأي بايت كود للتأكيدات. ^[9]

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

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

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

يمكن اعتبار استخدام التأكيدات بمثابة شكل من أشكال اختبار أوراكل ، وهي طريقة لاختبار التصميم من خلال تنفيذ العقد.

تتضمن اللغات التي تنفذ معظم ميزات DbC بشكل أصلي ما يلي:

• آدا 2012
• وداعا
• كلوجور
• كوبرا
• د ^[10]
• دافني
• ايفل
• قلعة
• كوتلين
• الزئبق
• الأكسجين (سابقًا Chrome وDelphi Prism ^[11] )
• الابتزاز (بما في ذلك العقود من الدرجة الأعلى، والتأكيد على أن انتهاكات العقد يجب أن تلقي باللوم على الطرف المذنب ويجب أن تفعل ذلك مع تفسير دقيق ^[12] )
• ساثر
• سكالا ^{[13] [14]}
• SPARK (عبر التحليل الثابت لبرامج Ada )
• فالا
• في دي ام

بالإضافة إلى ذلك، فإن مجموعة الطرق القياسية في نظام كائنات Common Lisp تحتوي على مؤهلات الطريقة :before، :afterوالتي :aroundتسمح بكتابة العقود كطرق مساعدة، من بين استخدامات أخرى.

• هندسة البرمجيات القائمة على المكونات
• صحة (علوم الكمبيوتر)
• البرمجة الدفاعية
• نظام سريع الفشل
• الأساليب الرسمية
• منطق هواري
• البرمجة المعيارية
• اشتقاق البرنامج
• تحسين البرنامج
• كتابة قوية
• التطوير الموجه بالاختبار
• تحليل الحالة النوعية

• قوة التصميم بالعقد(TM) وصف رفيع المستوى لـ DbC، مع روابط لموارد إضافية.
• بناء برامج OO خالية من الأخطاء: مقدمة إلى التصميم عن طريق العقد (TM) مواد قديمة على DbC.
• الفوائد والعيوب؛ التنفيذ في RPS-Obix
• استخدام عقود الكود من أجل كود أكثر أمانًا