अनुबंध द्वारा डिजाइन

अनुबंध द्वारा डिजाइन (डीबीसी), जिसे अनुबंध प्रोग्रामिंग, अनुबंध द्वारा प्रोग्रामिंग और डिजाइन-दर-अनुबंध प्रोग्रामिंग के रूप में भी जाना जाता है, सॉफ्टवेर डिज़ाइन के लिए एक दृष्टिकोण है।

यह निर्धारित करता है कि सॉफ्टवेयर डिजाइनरों को घटक-आधारित सॉफ़्टवेयर इंजीनियरिंग # सॉफ़्टवेयर घटक के लिए औपचारिक तरीकों, सटीक और सत्यापन योग्य इंटरफ़ेस विनिर्देशों को परिभाषित करना चाहिए, जो सार डेटा प्रकारों की सामान्य परिभाषा को पूर्व शर्त, शर्त लगाना और अपरिवर्तनीय (कंप्यूटर विज्ञान) के साथ विस्तारित करता है। व्यावसायिक अनुबंधों की शर्तों और दायित्वों के साथ एक वैचारिक रूपक के अनुसार, इन विशिष्टताओं को अनुबंध के रूप में संदर्भित किया जाता है।

DbC एप्रोच ऑफेंसिव_प्रोग्रामिंग सभी क्लाइंट कंपोनेंट्स जो एक सर्वर कंपोनेंट पर एक ऑपरेशन शुरू करते हैं, उस ऑपरेशन के लिए आवश्यक पूर्व शर्तों को पूरा करेंगे।

जहां इस धारणा को बहुत जोखिम भरा माना जाता है (मल्टी-चैनल या वितरित कंप्यूटिंग में), रक्षात्मक_प्रोग्रामिंग लिया जाता है, जिसका अर्थ है कि 'सर्वर घटक' परीक्षण करता है कि सभी प्रासंगिक पूर्व शर्त सही हैं (पहले, या 'ग्राहक को संसाधित करते समय) घटक अनुरोध) और यदि नहीं तो एक उपयुक्त त्रुटि संदेश के साथ उत्तर दें।

इतिहास
यह शब्द बर्ट्रेंड मेयर द्वारा एफिल (प्रोग्रामिंग भाषा) के अपने डिजाइन के संबंध में गढ़ा गया था और पहली बार 1986 से शुरू होने वाले विभिन्न लेखों में वर्णित है।  और उनकी पुस्तक वस्तु-उन्मुख सॉफ्टवेयर निर्माण के दो लगातार संस्करण (1988, 1997)। एफिल सॉफ्टवेयर ने दिसंबर 2003 में अनुबंध द्वारा डिजाइन के लिए ट्रेडमार्क पंजीकरण के लिए आवेदन किया था, और इसे दिसंबर 2004 में प्रदान किया गया था। इस ट्रेडमार्क का वर्तमान स्वामी एफिल सॉफ्टवेयर है।

औपचारिक सत्यापन, औपचारिक विनिर्देश और होरे तर्क पर काम में अनुबंध द्वारा डिजाइन की जड़ें हैं। मूल योगदान में शामिल हैं:
 * डिजाइन प्रक्रिया का मार्गदर्शन करने के लिए एक स्पष्ट रूपक
 * वंशानुक्रम के लिए आवेदन (कंप्यूटर विज्ञान), विशेष रूप से पुनर्परिभाषा और गतिशील बंधन (कंप्यूटर विज्ञान) के लिए एक औपचारिकता
 * अपवाद के लिए आवेदन (कंप्यूटर विज्ञान)
 * स्वचालित सॉफ्टवेयर प्रलेखन के साथ कनेक्शन

विवरण
DbC का केंद्रीय विचार एक रूपक है कि कैसे अभिकथन (सॉफ्टवेयर विकास) के तत्व आपसी दायित्वों और लाभों के आधार पर एक दूसरे के साथ सहयोग करते हैं। रूपक व्यावसायिक जीवन से आता है, जहां एक ग्राहक और आपूर्तिकर्ता एक अनुबंध पर सहमत होते हैं जो परिभाषित करता है, उदाहरण के लिए, कि:


 * आपूर्तिकर्ता को एक निश्चित उत्पाद (दायित्व) प्रदान करना चाहिए और यह अपेक्षा करने का हकदार है कि ग्राहक ने अपने शुल्क (लाभ) का भुगतान कर दिया है।
 * ग्राहक को शुल्क (दायित्व) का भुगतान करना होगा और उत्पाद (लाभ) प्राप्त करने का हकदार होगा।
 * दोनों पक्षों को सभी अनुबंधों पर लागू होने वाले कानूनों और विनियमों जैसे कुछ दायित्वों को पूरा करना चाहिए।

इसी तरह, यदि ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में एक वर्ग (कंप्यूटर प्रोग्रामिंग) का मेथड_(कंप्यूटर_साइंस) एक निश्चित कार्यक्षमता प्रदान करता है, तो यह हो सकता है:


 * किसी भी ग्राहक मॉड्यूल द्वारा प्रविष्टि पर एक निश्चित शर्त की गारंटी की अपेक्षा करें जो इसे कहते हैं: विधि की पूर्व शर्त - ग्राहक के लिए एक दायित्व, और आपूर्तिकर्ता के लिए एक लाभ (स्वयं विधि), क्योंकि यह इसे बाहर के मामलों को संभालने से मुक्त करता है। पूर्व शर्त का।
 * निकास पर एक निश्चित संपत्ति की गारंटी दें: विधि की पोस्टकंडीशन-आपूर्तिकर्ता के लिए एक दायित्व, और स्पष्ट रूप से ग्राहक के लिए एक लाभ (विधि को कॉल करने का मुख्य लाभ)।
 * एक निश्चित संपत्ति बनाए रखें, प्रवेश पर ग्रहण किया गया और बाहर निकलने पर गारंटी: वर्ग अपरिवर्तनीय।

अनुबंध अर्थपूर्ण रूप से एक होरे ट्रिपल के बराबर है जो दायित्वों को औपचारिक रूप देता है। इसे तीन प्रश्नों द्वारा संक्षेप में प्रस्तुत किया जा सकता है कि डिजाइनर को अनुबंध में बार-बार उत्तर देना चाहिए:
 * अनुबंध क्या अपेक्षा करता है?
 * अनुबंध क्या गारंटी देता है?
 * अनुबंध क्या रखता है?

कई प्रोग्रामिंग भाषाओं में इस तरह के दावे (सॉफ्टवेयर डेवलपमेंट) करने की सुविधा है। हालाँकि, DbC इन अनुबंधों को शुद्धता (कंप्यूटर विज्ञान) के लिए इतना महत्वपूर्ण मानता है कि उन्हें डिज़ाइन प्रक्रिया का हिस्सा होना चाहिए। वास्तव में, DbC परीक्षण-संचालित_विकास की वकालत करता है। अनुबंध टिप्पणी (कंप्यूटर प्रोग्रामिंग) द्वारा लिखे जा सकते हैं, परीक्षण सूट द्वारा लागू किया जा सकता है, या दोनों, भले ही अनुबंधों के लिए कोई विशेष भाषा समर्थन न हो।

एक अनुबंध की धारणा विधि/प्रक्रिया स्तर तक फैली हुई है; प्रत्येक विधि के अनुबंध में आम तौर पर निम्नलिखित जानकारी शामिल होगी:
 * स्वीकार्य और अस्वीकार्य इनपुट मान या प्रकार, और उनके अर्थ
 * वापसी मूल्य या प्रकार, और उनके अर्थ
 * त्रुटि और अपवाद हैंडलिंग स्थिति मान या प्रकार जो हो सकते हैं, और उनके अर्थ
 * साइड इफेक्ट (कंप्यूटर विज्ञान)
 * पूर्व शर्त
 * पोस्टकंडिशन
 * अपरिवर्तनीय (कंप्यूटर विज्ञान)।
 * (शायद ही कभी) प्रदर्शन की गारंटी, उदा। समय या स्थान के लिए उपयोग किया जाता है

एक वंशानुक्रम (वस्तु-उन्मुख प्रोग्रामिंग) में उपवर्गों को पूर्व शर्त को कमजोर करने की अनुमति है (लेकिन उन्हें मजबूत नहीं) और पोस्टकंडिशन और इनवेरिएंट को मजबूत करें (लेकिन उन्हें कमजोर नहीं करें)। ये नियम लिस्कोव प्रतिस्थापन सिद्धांत का अनुमान लगाते हैं।

सभी वर्ग संबंध ग्राहक वर्ग और आपूर्तिकर्ता वर्ग के बीच हैं। एक ग्राहक वर्ग आपूर्तिकर्ता सुविधाओं के लिए कॉल करने के लिए बाध्य है जहां ग्राहक कॉल द्वारा आपूर्तिकर्ता की परिणामी स्थिति का उल्लंघन नहीं किया जाता है। इसके बाद, आपूर्तिकर्ता वापसी की स्थिति और डेटा प्रदान करने के लिए बाध्य है जो ग्राहक की राज्य आवश्यकताओं का उल्लंघन नहीं करता है।

उदाहरण के लिए, एक आपूर्तिकर्ता डेटा बफ़र के लिए यह आवश्यक हो सकता है कि डिलीट फ़ीचर को कॉल करने पर डेटा बफ़र में मौजूद हो। इसके बाद, आपूर्तिकर्ता क्लाइंट को गारंटी देता है कि जब कोई डिलीट फीचर अपना काम पूरा कर लेता है, तो डेटा आइटम वास्तव में बफर से हटा दिया जाएगा। अन्य डिजाइन अनुबंध वर्ग अपरिवर्तनीय की अवधारणाएं हैं। वर्ग अपरिवर्तनीय गारंटी (स्थानीय वर्ग के लिए) कि प्रत्येक सुविधा निष्पादन के अंत में वर्ग की स्थिति को निर्दिष्ट सहनशीलता के भीतर बनाए रखा जाएगा।

अनुबंधों का उपयोग करते समय, एक आपूर्तिकर्ता को यह सत्यापित करने का प्रयास नहीं करना चाहिए कि अनुबंध की शर्तें संतुष्ट हैं - एक अभ्यास जिसे आपत्तिजनक प्रोग्रामिंग के रूप में जाना जाता है - सामान्य विचार यह है कि कोड को विफल होना चाहिए, अनुबंध सत्यापन सुरक्षा जाल होने के साथ।

डीबीसी की असफल हार्ड संपत्ति अनुबंध व्यवहार के डिबगिंग को सरल बनाती है, क्योंकि प्रत्येक विधि का इच्छित व्यवहार स्पष्ट रूप से निर्दिष्ट है।

यह दृष्टिकोण रक्षात्मक प्रोग्रामिंग से काफी हद तक अलग है, जहां आपूर्तिकर्ता यह पता लगाने के लिए जिम्मेदार है कि जब पूर्व शर्त टूट जाती है तो क्या करना है। अधिकतर नहीं, आपूर्तिकर्ता ग्राहक को सूचित करने के लिए अपवाद फेंकता है कि पूर्व शर्त टूट गई है, और दोनों मामलों में-डीबीसी और रक्षात्मक प्रोग्रामिंग समान रूप से-ग्राहक को यह पता लगाना चाहिए कि इसका जवाब कैसे दिया जाए। ऐसे मामलों में डीबीसी आपूर्तिकर्ता का काम आसान कर देता है।

अनुबंध द्वारा डिजाइन सॉफ्टवेयर मॉड्यूल के लिए शुद्धता के मानदंड को भी परिभाषित करता है:
 * यदि ग्राहक द्वारा आपूर्तिकर्ता को बुलाए जाने से पहले वर्ग अपरिवर्तनीय और पूर्व शर्त सत्य हैं, तो सेवा पूर्ण होने के बाद अपरिवर्तनीय और पश्च शर्त सत्य होगी।
 * आपूर्तिकर्ता को कॉल करते समय, सॉफ़्टवेयर मॉड्यूल को आपूर्तिकर्ता की पूर्व शर्तों का उल्लंघन नहीं करना चाहिए।

अनुबंध द्वारा डिजाइन भी कोड पुन: उपयोग की सुविधा प्रदान कर सकता है, क्योंकि कोड के प्रत्येक टुकड़े के लिए अनुबंध पूरी तरह से प्रलेखित है। एक मॉड्यूल के अनुबंधों को उस मॉड्यूल के व्यवहार के लिए सॉफ्टवेयर प्रलेखन के रूप में माना जा सकता है।

प्रदर्शन निहितार्थ
बग-मुक्त कार्यक्रम के निष्पादन के दौरान अनुबंध की शर्तों का कभी भी उल्लंघन नहीं किया जाना चाहिए। अनुबंध इसलिए आमतौर पर केवल सॉफ्टवेयर विकास के दौरान डिबग मोड में चेक किए जाते हैं। बाद में रिलीज़ होने पर, प्रदर्शन को अधिकतम करने के लिए अनुबंध जाँच अक्षम कर दी जाती है।

कई प्रोग्रामिंग भाषाओं में, अनुबंधों को अभिकथन (सॉफ्टवेयर विकास) के साथ कार्यान्वित किया जाता है। आवेषण डिफ़ॉल्ट रूप से सी/सी ++ में रिलीज मोड में संकलित किए जाते हैं, और इसी तरह सी # में निष्क्रिय होते हैं और जावा।

एक तर्क के रूप में -O (ऑप्टिमाइज़ के लिए) के साथ पायथन दुभाषिया को लॉन्च करने से पाइथन कोड जेनरेटर को दावा करने के लिए किसी भी बाइटकोड को उत्सर्जित नहीं करने का कारण बनता है। यह प्रभावी रूप से उत्पादन कोड में अभिकथनों की रन-टाइम लागतों को समाप्त करता है-विकास में उपयोग किए गए अभिकथनों की संख्या और कम्प्यूटेशनल व्यय के बावजूद-संकलक द्वारा उत्पादन में ऐसे कोई निर्देश शामिल नहीं किए जाएंगे।

सॉफ्टवेयर परीक्षण से संबंध
अनुबंध द्वारा डिज़ाइन नियमित परीक्षण रणनीतियों को प्रतिस्थापित नहीं करता है, जैसे इकाई परीक्षण, एकीकरण परीक्षण और सिस्टम परीक्षण। इसके बजाय, यह बाहरी परीक्षण को आंतरिक स्व-परीक्षणों के साथ पूरक करता है जिसे परीक्षण-चरण के दौरान पृथक परीक्षणों और उत्पादन कोड दोनों में सक्रिय किया जा सकता है।

आंतरिक स्व-परीक्षणों का लाभ यह है कि वे क्लाइंट द्वारा देखे गए अमान्य परिणामों के रूप में स्वयं को प्रकट करने से पहले त्रुटियों का पता लगा सकते हैं। इससे पहले और अधिक विशिष्ट त्रुटि का पता चलता है।

अभिकथन के उपयोग को परीक्षण ऑरेकल का एक रूप माना जा सकता है, अनुबंध कार्यान्वयन द्वारा डिजाइन का परीक्षण करने का एक तरीका।

देशी समर्थन वाली भाषाएं
अधिकांश डीबीसी सुविधाओं को मूल रूप से लागू करने वाली भाषाओं में शामिल हैं:
 * एडीए प्रोग्रामिंग भाषा
 * सियाओ (प्रोग्रामिंग भाषा)
 * क्लोजर
 * कोबरा (प्रोग्रामिंग भाषा)
 * डी (प्रोग्रामिंग भाषा)
 * डैफनी (प्रोग्रामिंग भाषा)
 * एफिल (प्रोग्रामिंग भाषा)
 * किले (प्रोग्रामिंग भाषा)
 * कोटलिन_(प्रोग्रामिंग_भाषा)
 * बुध (प्रोग्रामिंग भाषा)
 * ऑक्सीजन (प्रोग्रामिंग भाषा) (पूर्व में क्रोम और डेल्फी प्रिज्म )
 * रैकेट (प्रोग्रामिंग भाषा) (उच्च आदेश अनुबंधों सहित, और अनुबंध के उल्लंघन पर जोर देते हुए दोषी पार्टी को दोष देना चाहिए और सटीक स्पष्टीकरण के साथ ऐसा करना चाहिए )
 * सथर
 * स्काला_ (प्रोग्रामिंग_भाषा)
 * स्पार्क (प्रोग्रामिंग भाषा) (एडा (प्रोग्रामिंग भाषा) कार्यक्रमों के स्थिर कोड विश्लेषण के माध्यम से)
 * वाला (प्रोग्रामिंग भाषा)
 * वीडीएम विनिर्देश भाषा

इसके अतिरिक्त, कॉमन लिस्प ऑब्जेक्ट सिस्टम में मानक विधि संयोजन में विधि क्वालिफायर हैं,   और   जो अन्य उपयोगों के साथ अनुबंधों को सहायक तरीकों के रूप में लिखने की अनुमति देता है।

तृतीय-पक्ष समर्थन वाली भाषाएं
मौजूदा प्रोग्रामिंग भाषाओं के लिए मूल डिजाइन के बिना अनुबंध समर्थन द्वारा विभिन्न पुस्तकालयों, preprocessorों और अन्य उपकरणों का विकास किया गया है:
 * एडा (प्रोग्रामिंग लैंग्वेज), जीएनएटी प्रागमास के माध्यम से पूर्व शर्त और पोस्टकंडिशन के लिए।
 * सी (प्रोग्रामिंग भाषा) और सी ++:
 * Boost.Contract
 * सी प्रीप्रोसेसर के लिए डीबीसी
 * जीएनयू नाना
 * eCv और eCv++ औपचारिक सत्यापन उपकरण
 * C के CTESK एक्सटेंशन के माध्यम से डिजिटल मंगल C++ कंपाइलर
 * लोकी (सी ++) कॉन्ट्रैक्ट चेकर नामक एक तंत्र प्रदान करता है जो एक वर्ग को अनुबंध द्वारा डिजाइन का सत्यापन करता है।
 * DBC C++ C++ के लिए अनुबंध द्वारा डिजाइन
 * सी शार्प (प्रोग्रामिंग लैंग्वेज) | सी # (और अन्य .NET लैंग्वेज), कोड कॉन्ट्रैक्ट्स के माध्यम से (एक Microsoft अनुसंधान परियोजना .NET फ्रेमवर्क 4.0 में एकीकृत)
 * ग्रूवी (प्रोग्रामिंग भाषा) GContracts के माध्यम से
 * जाओ (प्रोग्रामिंग भाषा) dbc या gocontracts के माध्यम से
 * जावा (प्रोग्रामिंग भाषा):
 * सक्रिय:
 * OVal AspectJ के साथ
 * Java के लिए अनुबंध (Cofoja)
 * जावा मॉडलिंग भाषा (JML)
 * बीन सत्यापन (केवल पूर्व और बाद की स्थिति)
 * 
 * SafeR (सुरक्षित संदर्भ के साथ)
 * निष्क्रिय/अज्ञात:
 * Jtest (सक्रिय लेकिन DbC अब समर्थित नहीं लगता है)
 * iContract2/JContracts
 * अनुबंध 4 जे
 * जे ठेकेदार
 * सी4जे
 * गूगल कोडप्रो एनालिटिक्स
 * स्प्रिंग फ्रेमवर्क के लिए स्प्रिंगकॉन्ट्रैक्ट्स
 * जस
 * आधुनिक जस (उत्तराधिकारी Cofoja है)
 * JavaDbC AspectJ का उपयोग कर
 * JavaTESK जावा के विस्तार का उपयोग कर रहा है
 * javassist का उपयोग कर chex4j
 * अत्यधिक अनुकूलन योग्य जावा-ऑन-कॉन्ट्रैक्ट
 * जावास्क्रिप्ट, डेकोरेटर-कॉन्ट्रैक्ट्स के माध्यम से, AspectJS (विशेष रूप से, AJS_Validator), Cerny.js, ecmaDebug, jsContract, /पैकेज/डीबीसी-कोड-अनुबंध डीबीसी-कोड-अनुबंध या jscategory.
 * सामान्य लिस्प, मैक्रो सुविधा या कॉमन लिस्प ऑब्जेक्ट सिस्टम metaobject के माध्यम से।
 * नेमर्ले, मैक्रोज़ के माध्यम से।
 * निम (प्रोग्रामिंग भाषा), मैक्रोज़ के माध्यम से।
 * पर्ल, सीपीएएन मॉड्यूल के माध्यम से वर्ग :: अनुबंध (डेमियन कॉनवे द्वारा) या कार्प :: डेटम (राफेल मैनफ्रेडी द्वारा)।
 * PHP, PhpDeal, क्रिसमस पार्टी या स्टुअर्ट हर्बर्ट के कॉन्ट्रैक्टलिब के माध्यम से।
 * पायथन (प्रोग्रामिंग भाषा), Deal, icontract, जैसे पैकेजों का उपयोग करके project/PyContracts3/ PyContracts, dpcontracts, या zope.interface। 2003 में PEP-316 में अनुबंधों द्वारा डिजाइन का समर्थन करने के लिए पायथन में एक स्थायी परिवर्तन प्रस्तावित किया गया था, लेकिन इसे स्थगित कर दिया गया है।
 * रूबी (प्रोग्रामिंग भाषा), ब्रायन मैकक्लिस्टर के DesignByContract, रूबी DBC रूबी-कॉन्ट्रैक्ट या कॉन्ट्रैक्ट्स.रूबी के माध्यम से।
 * जंग (प्रोग्रामिंग भाषा) अनुबंध क्रेट के माध्यम से।
 * स्विफ्ट (प्रोग्रामिंग भाषा) कोकोपॉड जिम बॉयड द्वारा के माध्यम से।
 * Tcl, XOTcl ऑब्जेक्ट-ओरिएंटेड एक्सटेंशन के माध्यम से।

यह भी देखें

 * घटक आधारित सॉफ्टवेयर इंजीनियरिंग
 * शुद्धता (कंप्यूटर विज्ञान)
 * रक्षात्मक प्रोग्रामिंग
 * असफल-तेज
 * औपचारिक तरीके
 * होरे तर्क
 * मॉड्यूलर प्रोग्रामिंग
 * कार्यक्रम व्युत्पत्ति
 * कार्यक्रम शोधन
 * मजबूत और कमजोर टाइपिंग
 * परीक्षण संचालित विकास
 * टाइपस्टेट विश्लेषण

ग्रन्थसूची

 * Mitchell, Richard, and McKim, Jim: Design by Contract: by example, Addison-Wesley, 2002
 * A wikibook describing DBC closely to the original model.
 * McNeile, Ashley: A framework for the semantics of behavioral contracts. Proceedings of the Second International Workshop on Behaviour Modelling: Foundation and Applications (BM-FA '10). ACM, New York, NY, USA, 2010. This paper discusses generalized notions of Contract and Substitutability.

बाहरी संबंध

 * The Power of Design by Contract(TM) A top-level description of DbC, with links to additional resources.
 * Building bug-free O-O software: An introduction to Design by Contract(TM) Older material on DbC.
 * Benefits and drawbacks; implementation in RPS-Obix
 * Bertrand Meyer, Applying "Design by Contract", IEEE Computer, October 1992.
 * Using Code Contracts for Safer Code