अनुबंध द्वारा डिजाइन: Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|Approach for designing software}} thumbnail|अनुबंध योजना द्वारा एक डिजाइन...")
 
No edit summary
 
(12 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Short description|Approach for designing software}}
{{Short description|Approach for designing software}}
[[File:Design by contract.svg|thumbnail|अनुबंध योजना द्वारा एक डिजाइन]]अनुबंध द्वारा डिजाइन (डीबीसी), जिसे अनुबंध प्रोग्रामिंग, अनुबंध द्वारा प्रोग्रामिंग और डिजाइन-दर-अनुबंध प्रोग्रामिंग के रूप में भी जाना जाता है, [[सॉफ्टवेर डिज़ाइन]] के लिए एक दृष्टिकोण है।
[[File:Design by contract.svg|thumbnail|अनुबंध योजना द्वारा एक डिजाइन]]'''अनुबंध द्वारा डिजाइन''', जिसे अनुबंध प्रोग्रामिंग, अनुबंध द्वारा प्रोग्रामिंग और डिज़ाइन-बाय-कॉन्ट्रैक्ट (डीबीसी) प्रोग्रामिंग के रूप में भी जाना जाता है, जो [[सॉफ्टवेर डिज़ाइन|डिजाइनिंग सॉफ्टवेयर]] के लिए एक दृष्टिकोण जैसा है।


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


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


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


== इतिहास ==
== इतिहास ==
यह शब्द [[बर्ट्रेंड मेयर]] द्वारा [[एफिल (प्रोग्रामिंग भाषा)]] के अपने डिजाइन के संबंध में गढ़ा गया था और पहली बार 1986 से शुरू होने वाले विभिन्न लेखों में वर्णित है।<ref>Meyer, Bertrand: ''Design by Contract'', Technical Report TR-EI-12/CO, Interactive Software Engineering Inc., 1986</ref><ref>Meyer, Bertrand: ''Design by Contract'', in ''Advances in Object-Oriented Software Engineering'', eds. D. Mandrioli and B. Meyer, Prentice Hall, 1991, pp. 1–50</ref><ref>Meyer, Bertrand: ''Applying "Design by Contract"'', in Computer (IEEE), 25, 10, October 1992, pp. 40–51, also available [http://se.ethz.ch/~meyer/publications/computer/contract.pdf online]</ref> और उनकी पुस्तक [[वस्तु-उन्मुख सॉफ्टवेयर निर्माण]] के दो लगातार संस्करण (1988, 1997)एफिल सॉफ्टवेयर ने दिसंबर 2003 में अनुबंध द्वारा डिजाइन के लिए ट्रेडमार्क पंजीकरण के लिए आवेदन किया था, और इसे दिसंबर 2004 में प्रदान किया गया था।<ref name=DbC_tm_words>{{cite web|url=http://tess2.uspto.gov/bin/showfield?f=doc&state=4010:lsqmmo.2.2|title="डिज़ाइन बाय कॉन्ट्रेक्ट" के लिए संयुक्त राज्य पेटेंट और ट्रेडमार्क कार्यालय पंजीकरण|access-date=2009-06-22|archive-date=2016-12-21|archive-url=https://web.archive.org/web/20161221062729/http://tess2.uspto.gov/bin/showfield?f=doc&state=4010:lsqmmo.2.2|url-status=dead}}</रेफरी><ref name=DbC_tm_design>{{cite web|url=http://tess2.uspto.gov/bin/showfield?f=doc&state=4010:lsqmmo.2.1|title=संयुक्त राज्य अमेरिका पेटेंट और ट्रेडमार्क कार्यालय पंजीकरण "अनुबंध द्वारा डिजाइन" शब्दों के साथ ग्राफिक डिजाइन के लिए|access-date=2009-06-22|archive-date=2016-12-21|archive-url=https://web.archive.org/web/20161221062436/http://tess2.uspto.gov/bin/showfield?f=doc&state=4010:lsqmmo.2.1|url-status=dead}}</ref> इस ट्रेडमार्क का वर्तमान स्वामी एफिल सॉफ्टवेयर है।<ref name=DbC_tm_words2>{{cite web|url=http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=78342277|title=ट्रेडमार्क स्थिति और दस्तावेज़ पुनर्प्राप्ति|website=tarr.uspto.gov}}</रेफरी><ref name=DbC_tm_design2>{{cite web|url=http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=78342308|title=ट्रेडमार्क स्थिति और दस्तावेज़ पुनर्प्राप्ति|website=tarr.uspto.gov}}</रेफरी>
यह शब्द [[बर्ट्रेंड मेयर]] द्वारा [[एफिल (प्रोग्रामिंग भाषा)]] के अपने डिजाइन के संबंध में गढ़ा गया था और पहली बार 1986 से प्रारंभ होने वाले विभिन्न लेखों <ref>Meyer, Bertrand: ''Design by Contract'', Technical Report TR-EI-12/CO, Interactive Software Engineering Inc., 1986</ref><ref>Meyer, Bertrand: ''Design by Contract'', in ''Advances in Object-Oriented Software Engineering'', eds. D. Mandrioli and B. Meyer, Prentice Hall, 1991, pp. 1–50</ref><ref>Meyer, Bertrand: ''Applying "Design by Contract"'', in Computer (IEEE), 25, 10, October 1992, pp. 40–51, also available [http://se.ethz.ch/~meyer/publications/computer/contract.pdf online]</ref> और उनकी पुस्तक [[वस्तु-उन्मुख सॉफ्टवेयर निर्माण]] के दो लगातार संस्करण (1988, 1997) में वर्णित है। एफिल सॉफ्टवेयर ने दिसंबर 2003 में अनुबंध द्वारा डिजाइन के लिए ट्रेडमार्क पंजीकरण के लिए आवेदन किया था, और इसे दिसंबर 2004 में प्रदान किया गया था।<ref name=DbC_tm_words>{{cite web|url=http://tess2.uspto.gov/bin/showfield?f=doc&state=4010:lsqmmo.2.2|title="डिज़ाइन बाय कॉन्ट्रेक्ट" के लिए संयुक्त राज्य पेटेंट और ट्रेडमार्क कार्यालय पंजीकरण|access-date=2009-06-22|archive-date=2016-12-21|archive-url=https://web.archive.org/web/20161221062729/http://tess2.uspto.gov/bin/showfield?f=doc&state=4010:lsqmmo.2.2|url-status=dead}}</ref><ref name=DbC_tm_design>{{cite web|url=http://tess2.uspto.gov/bin/showfield?f=doc&state=4010:lsqmmo.2.1|title=संयुक्त राज्य अमेरिका पेटेंट और ट्रेडमार्क कार्यालय पंजीकरण "अनुबंध द्वारा डिजाइन" शब्दों के साथ ग्राफिक डिजाइन के लिए|access-date=2009-06-22|archive-date=2016-12-21|archive-url=https://web.archive.org/web/20161221062436/http://tess2.uspto.gov/bin/showfield?f=doc&state=4010:lsqmmo.2.1|url-status=dead}}</ref> इस ट्रेडमार्क का वर्तमान अधिष्ठाता एफिल सॉफ्टवेयर है।<ref name=DbC_tm_words2>{{cite web|url=http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=78342277|title=ट्रेडमार्क स्थिति और दस्तावेज़ पुनर्प्राप्ति|website=tarr.uspto.gov}}</ref><ref name=DbC_tm_design2>{{cite web|url=http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=78342308|title=ट्रेडमार्क स्थिति और दस्तावेज़ पुनर्प्राप्ति|website=tarr.uspto.gov}}</ref>


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


कई प्रोग्रामिंग भाषाओं में, अनुबंधों को अभिकथन (सॉफ्टवेयर विकास) के साथ कार्यान्वित किया जाता है। आवेषण डिफ़ॉल्ट रूप से सी/सी ++ में रिलीज मोड में संकलित किए जाते हैं, और इसी तरह सी # में निष्क्रिय होते हैं<ref>{{cite web|url=https://msdn.microsoft.com/en-us/library/ttcc4x86.aspx|title=Assertions in Managed Code|website=msdn.microsoft.com}}</ref> और जावा।
कई प्रोग्रामिंग भाषाओं में, अनुबंधों को अभिकथन (सॉफ्टवेयर विकास) के साथ कार्यान्वित किया जाता है। आवेषण डिफ़ॉल्ट रूप से सी/सी ++ में रिलीज मोड में संकलित किए जाते हैं, और इसी तरह सी # में निष्क्रिय होते हैं<ref>{{cite web|url=https://msdn.microsoft.com/en-us/library/ttcc4x86.aspx|title=Assertions in Managed Code|website=msdn.microsoft.com}}</ref>
 
एक तर्क के रूप में -O ("ऑप्टिमाइज़" के लिए) के साथ पायथन निर्वचक को प्रक्षेपित करने से इसी तरह पायथन कोड जनरेटर को अभिकथन के लिए किसी भी बायटेकोड का उत्सर्जन नहीं करने का कारण बनता है।<ref>[https://docs.python.org/3/reference/simple_stmts.html#grammar-token-assert-stmt Official Python Docs, ''assert statement'']</ref>
 
यह प्रभावी रूप से उत्पादन कोड में अभिकथनों की रन-टाइम मूल्य को समाप्त करता हैl विकास में उपयोग किए गए अभिकथनों की संख्या और कम्प्यूटेशनल व्यय के बावजूद-संकलक द्वारा उत्पादन में ऐसे कोई निर्देश सम्मिलित नहीं किए जाते हैं।
 
 
 
 
 
 
 
 
 
 


एक तर्क के रूप में -O (ऑप्टिमाइज़ के लिए) के साथ पायथन दुभाषिया को लॉन्च करने से पाइथन कोड जेनरेटर को दावा करने के लिए किसी भी बाइटकोड को उत्सर्जित नहीं करने का कारण बनता है।<ref>[https://docs.python.org/3/reference/simple_stmts.html#grammar-token-assert-stmt Official Python Docs, ''assert statement'']</ref>
यह प्रभावी रूप से उत्पादन कोड में अभिकथनों की रन-टाइम लागतों को समाप्त करता है-विकास में उपयोग किए गए अभिकथनों की संख्या और कम्प्यूटेशनल व्यय के बावजूद-संकलक द्वारा उत्पादन में ऐसे कोई निर्देश शामिल नहीं किए जाएंगे।


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


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


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


== भाषा समर्थन ==
== भाषा समर्थन ==


=== देशी समर्थन वाली भाषाएं ===
=== देशी समर्थन वाली भाषाएं ===
अधिकांश डीबीसी सुविधाओं को मूल रूप से लागू करने वाली भाषाओं में शामिल हैं:
अधिकांश डीबीसी सुविधाओं को मूल रूप से लागू करने वाली भाषाओं में सम्मिलित हैं:
* एडीए प्रोग्रामिंग भाषा
* एडीए 2012 प्रोग्रामिंग भाषा
* [[सियाओ (प्रोग्रामिंग भाषा)]]
* [[सियाओ (प्रोग्रामिंग भाषा)]]
* [[क्लोजर]]
* [[क्लोजर]]
Line 102: Line 114:
* एफिल (प्रोग्रामिंग भाषा)
* एफिल (प्रोग्रामिंग भाषा)
* [[किले (प्रोग्रामिंग भाषा)]]
* [[किले (प्रोग्रामिंग भाषा)]]
* कोटलिन_(प्रोग्रामिंग_भाषा)
* कोटलिन (प्रोग्रामिंग_भाषा)
* बुध (प्रोग्रामिंग भाषा)
* मरकरी (प्रोग्रामिंग भाषा)
* [[ऑक्सीजन (प्रोग्रामिंग भाषा)]] (पूर्व में क्रोम और डेल्फी प्रिज्म<ref>{{cite web | url=http://edn.embarcadero.com/article/39398 | title=Write Cleaner, Higher Quality Code with Class Contracts in Delphi Prism | publisher=Embarcadero Technologies | access-date=20 January 2016 | author=Hodges, Nick}}</ref>)
* [[ऑक्सीजन (प्रोग्रामिंग भाषा)]] (पूर्व में क्रोम और डेल्फी प्रिज्म<ref>{{cite web | url=http://edn.embarcadero.com/article/39398 | title=Write Cleaner, Higher Quality Code with Class Contracts in Delphi Prism | publisher=Embarcadero Technologies | access-date=20 January 2016 | author=Hodges, Nick}}</ref>)
* [[रैकेट (प्रोग्रामिंग भाषा)]] (उच्च आदेश अनुबंधों सहित, और अनुबंध के उल्लंघन पर जोर देते हुए दोषी पार्टी को दोष देना चाहिए और सटीक स्पष्टीकरण के साथ ऐसा करना चाहिए<ref>Findler, Felleisen [http://www.eecs.northwestern.edu/~robby/pubs/papers/ho-contracts-icfp2002.pdf Contracts for Higher-Order Functions]</ref>)
* [[रैकेट (प्रोग्रामिंग भाषा)]] (उच्च आदेश अनुबंधों सहित, और अनुबंध के उल्लंघन पर जोर देते हुए दोषी पक्ष को निदा देना चाहिए और सटीक स्पष्टीकरण के साथ ऐसा करना चाहिए<ref>Findler, Felleisen [http://www.eecs.northwestern.edu/~robby/pubs/papers/ho-contracts-icfp2002.pdf Contracts for Higher-Order Functions]</ref>)
* [[सथर]]
* [[सथर]]
* स्काला_ (प्रोग्रामिंग_भाषा)<ref name="scala-assertions-dbc">
* स्काला (प्रोग्रामिंग_भाषा)<ref name="scala-assertions-dbc">
{{cite web
{{cite web
| title = Scala Standard Library Docs - Assertions
| title = Scala Standard Library Docs - Assertions
Line 122: Line 134:


===तृतीय-पक्ष समर्थन वाली भाषाएं===
===तृतीय-पक्ष समर्थन वाली भाषाएं===
{{multiple issues|section=yes|
मौजूदा प्रोग्रामिंग भाषाओं के लिए मूल डिजाइन के बिना अनुबंध समर्थन द्वारा विभिन्न लाइब्रेरीज, [[preprocessor|पूर्वप्रक्रमक]] और अन्य उपकरणों का विकास किया गया है:
{{External links|section|date=January 2022}}
* एडा (प्रोग्रामिंग लैंग्वेज), जीएनएटी प्रागमास के माध्यम से पूर्वापेक्षा और पोस्टकंडिशन के लिए।
{{cleanup list|section|date=January 2022}}
* [[सी (प्रोग्रामिंग भाषा)|C (प्रोग्रामिंग भाषा)]] और [[सी ++|C ++]]:
}}
** [https://www.boost.org/doc/libs/master/libs/contract/doc/html/index.html बूस्ट.कॉन्ट्रैक्ट]
मौजूदा प्रोग्रामिंग भाषाओं के लिए मूल डिजाइन के बिना अनुबंध समर्थन द्वारा विभिन्न पुस्तकालयों, [[preprocessor]]ों और अन्य उपकरणों का विकास किया गया है:
** C प्रीप्रोसेसर के लिए डीबीसी
* एडा (प्रोग्रामिंग लैंग्वेज), जीएनएटी प्रागमास के माध्यम से पूर्व शर्त और पोस्टकंडिशन के लिए।
* [[सी (प्रोग्रामिंग भाषा)]] और [[सी ++]]:
** [https://www.boost.org/doc/libs/master/libs/contract/doc/html/index.html Boost.Contract]
** सी प्रीप्रोसेसर के लिए डीबीसी
** जीएनयू नाना
** जीएनयू नाना
** eCv और eCv++ औपचारिक सत्यापन उपकरण
** eCv और eCv++ औपचारिक सत्यापन उपकरण
** C के [[CTESK]] एक्सटेंशन के माध्यम से [[डिजिटल मंगल]] C++ कंपाइलर
** C के [[CTESK]] एक्सटेंशन के माध्यम से [[डिजिटल मंगल]] C++ कंपाइलर
** लोकी (सी ++) कॉन्ट्रैक्ट चेकर नामक एक तंत्र प्रदान करता है जो एक वर्ग को अनुबंध द्वारा डिजाइन का सत्यापन करता है।
** लोकी (C ++) कॉन्ट्रैक्ट चेकर नामक तंत्र प्रदान करता है जो वर्ग को अनुबंध द्वारा डिजाइन का सत्यापन करता है।
** [https://github.com/Bambofy/dbc_cpp DBC C++] C++ के लिए अनुबंध द्वारा डिजाइन
** [https://github.com/Bambofy/dbc_cpp डीबीसी C++] C++ के लिए अनुबंध द्वारा डिजाइन
* सी शार्प (प्रोग्रामिंग लैंग्वेज) | सी # (और अन्य .NET लैंग्वेज), कोड कॉन्ट्रैक्ट्स के माध्यम से<ref>{{cite web|url=https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/code-contracts|title=Code Contracts|website=msdn.microsoft.com}}</ref> (एक Microsoft अनुसंधान परियोजना .NET फ्रेमवर्क 4.0 में एकीकृत)
* C # (और अन्य .NET लैंग्वेज), कोड कॉन्ट्रैक्ट्स के माध्यम से<ref>{{cite web|url=https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/code-contracts|title=Code Contracts|website=msdn.microsoft.com}}</ref> (एक माइक्रोसॉफ्ट अनुसंधान परियोजना .NET फ्रेमवर्क 4.0 में एकीकृत)
* [[ग्रूवी (प्रोग्रामिंग भाषा)]] GContracts के माध्यम से
* [[ग्रूवी (प्रोग्रामिंग भाषा)]] जी कॉन्ट्रैक्ट के माध्यम से
*[[जाओ (प्रोग्रामिंग भाषा)]] [https://github.com/drblez/dbc dbc] या [https://github.com/Parquery/gocontracts gocontracts] के माध्यम से
*[[जाओ (प्रोग्रामिंग भाषा)]] [https://github.com/drblez/dbc डीबीसी] या [https://github.com/Parquery/gocontracts गोकोन्ट्रेक्ट्स] के माध्यम से
* [[जावा (प्रोग्रामिंग भाषा)]]:
* [[जावा (प्रोग्रामिंग भाषा)]]:
** सक्रिय:
** सक्रिय:
*** [https://sebthom.github.io/oval/ OVal] [[AspectJ]] के साथ
*** [https://sebthom.github.io/oval/ ओवल] [[AspectJ|आस्पेक्ट जे]] के साथ
*** [https://github.com/nhatminhle/cofoja Java के लिए अनुबंध] (Cofoja)
*** [https://github.com/nhatminhle/cofoja जावा] [https://github.com/nhatminhle/cofoja के लिए अनुबंध] (Cofoja)
*** [[जावा मॉडलिंग भाषा]] (JML)
*** [[जावा मॉडलिंग भाषा]] (जेएमएल)
*** [[बीन सत्यापन]] (केवल पूर्व और बाद की स्थिति)<ref>{{cite web|url=http://beanvalidation.org/1.1/spec/|title=Bean Validation specification|website=beanvalidation.org}}</ref>
*** [[बीन सत्यापन]] (केवल पूर्व और बाद की स्थिति)<ref>{{cite web|url=http://beanvalidation.org/1.1/spec/|title=Bean Validation specification|website=beanvalidation.org}}</ref>
*** [http://www.valid4j.orgValid4j]
*** [http://वैलिड4]
*** [https://swdes.net/en/content/safer-project SafeR] (सुरक्षित संदर्भ के साथ)
*** [https://swdes.net/en/content/safer-project सेफआर] (सुरक्षित संदर्भ के साथ)
** निष्क्रिय/अज्ञात:
** निष्क्रिय/अज्ञात:
*** [[Jtest]] (सक्रिय लेकिन DbC अब समर्थित नहीं लगता है)<ref>{{Cite web|url=https://www.parasoft.com/wp-content/uploads/pdf/JtestDataSheet.pdf |archive-url=https://ghostarchive.org/archive/20221009/https://www.parasoft.com/wp-content/uploads/pdf/JtestDataSheet.pdf |archive-date=2022-10-09 |url-status=live|title=Software Testing Help from the Experts &#124; Parasoft Resources}}</ref>
*** [[Jtest|जेटेस्ट]] (सक्रिय लेकिन डीबीसी अब समर्थित नहीं लगता है)<ref>{{Cite web|url=https://www.parasoft.com/wp-content/uploads/pdf/JtestDataSheet.pdf |archive-url=https://ghostarchive.org/archive/20221009/https://www.parasoft.com/wp-content/uploads/pdf/JtestDataSheet.pdf |archive-date=2022-10-09 |url-status=live|title=Software Testing Help from the Experts &#124; Parasoft Resources}}</ref>
*** iContract2/JContracts
*** आईकॉन्ट्रैक्ट2/जेकॉन्ट्रैक्ट्स
*** अनुबंध 4 जे
*** अनुबंध 4जे
*** जे ठेकेदार
*** जेकॉन्ट्रैक्ट्स
*** सी4जे
*** सी4जे
*** गूगल कोडप्रो एनालिटिक्स
*** गूगल कोडप्रो एनालिटिक्स
Line 157: Line 165:
*** [http://csd.informatik.uni-oldenburg.de/~jass/ जस]
*** [http://csd.informatik.uni-oldenburg.de/~jass/ जस]
*** [http://modernjass.sourceforge.net आधुनिक जस] (उत्तराधिकारी Cofoja है)<ref>{{cite web |url=https://cofoja.googlecode.com/files/cofoja-20110112.pdf |title=Archived copy |access-date=2016-03-25 |url-status=dead |archive-url=https://web.archive.org/web/20160328164727/http://cofoja.googlecode.com/files/cofoja-20110112.pdf |archive-date=2016-03-28 }} p. 2</ref><ref>{{cite web|url=https://github.com/nhatminhle/cofoja/issues/5|title=No chance of releasing under Apache/Eclipse/MIT/BSD license? · Issue #5 · nhatminhle/cofoja|website=GitHub}}</ref>
*** [http://modernjass.sourceforge.net आधुनिक जस] (उत्तराधिकारी Cofoja है)<ref>{{cite web |url=https://cofoja.googlecode.com/files/cofoja-20110112.pdf |title=Archived copy |access-date=2016-03-25 |url-status=dead |archive-url=https://web.archive.org/web/20160328164727/http://cofoja.googlecode.com/files/cofoja-20110112.pdf |archive-date=2016-03-28 }} p. 2</ref><ref>{{cite web|url=https://github.com/nhatminhle/cofoja/issues/5|title=No chance of releasing under Apache/Eclipse/MIT/BSD license? · Issue #5 · nhatminhle/cofoja|website=GitHub}}</ref>
*** JavaDbC AspectJ का उपयोग कर
*** जावाडीबीसी आस्पेक्ट जे का उपयोग कर
*** [[JavaTESK]] जावा के विस्तार का उपयोग कर रहा है
*** [[JavaTESK|जावाटेस्क]] जावा के विस्तार का उपयोग कर रहा है
*** javassist का उपयोग कर chex4j
*** जावस्सिस्ट का उपयोग कर chex4j
*** अत्यधिक अनुकूलन योग्य जावा-ऑन-कॉन्ट्रैक्ट
*** अत्यधिक अनुकूलन योग्य जावा-ऑन-कॉन्ट्रैक्ट
* [[जावास्क्रिप्ट]], [https://github.com/final-hill/decorator-contracts डेकोरेटर-कॉन्ट्रैक्ट्स] के माध्यम से, AspectJS (विशेष रूप से, AJS_Validator), Cerny.js, ecmaDebug, jsContract, [https://www.npmjs.com /पैकेज/डीबीसी-कोड-अनुबंध डीबीसी-कोड-अनुबंध] या jscategory.
* [[जावास्क्रिप्ट]], [https://github.com/final-hill/decorator-contracts डेकोरेटर-कॉन्ट्रैक्ट्स] के माध्यम से, आस्पेक्टजेएस (विशेष रूप से, एजेएस_वैलिडेटर), Cerny.js, ecmaDebug,जेएसकॉन्ट्रैक्ट, [https://www.npmjs.com /पैकेज/डीबीसी-कोड-अनुबंध डीबीसी-कोड-अनुबंध] याजेएसकेटेगरी.
* [[सामान्य लिस्प]], मैक्रो सुविधा या कॉमन लिस्प ऑब्जेक्ट सिस्टम [[metaobject]] के माध्यम से।
* [[सामान्य लिस्प]], मैक्रो सुविधा या कॉमन लिस्प ऑब्जेक्ट सिस्टम [[metaobject|मेटा ऑब्जेक्ट]] के माध्यम से।
* [[नेमर्ले]], मैक्रोज़ के माध्यम से।
* [[नेमर्ले]], मैक्रोज़ के माध्यम से।
* [[निम (प्रोग्रामिंग भाषा)]], [https://github.com/Udiknedormin/NimContracts मैक्रोज़] के माध्यम से।
* [[निम (प्रोग्रामिंग भाषा)]], [https://github.com/Udiknedormin/NimContracts मैक्रोज़] के माध्यम से।
* [[पर्ल]], [[सीपीएएन]] मॉड्यूल के माध्यम से वर्ग :: अनुबंध ([[डेमियन कॉनवे]] द्वारा) या कार्प :: डेटम (राफेल मैनफ्रेडी द्वारा)।
* [[पर्ल]], [[सीपीएएन]] मॉड्यूल के माध्यम से वर्ग :: अनुबंध ([[डेमियन कॉनवे]] द्वारा) या कार्प :: डेटम (राफेल मैनफ्रेडी द्वारा)।
* [[PHP]], [https://github.com/php-deal/framework PhpDeal], [[क्रिसमस पार्टी]] या स्टुअर्ट हर्बर्ट के कॉन्ट्रैक्टलिब के माध्यम से।
* [[PHP|पीएचपी]], पीएचपीडील, [[क्रिसमस पार्टी|क्रिसमस पक्ष]] या स्टुअर्ट हर्बर्ट के कॉन्ट्रैक्टलिब के माध्यम से।
* [[पायथन (प्रोग्रामिंग भाषा)]], [https://github.com/life4/deal Deal], [https://pypi.org/project/icontract/ icontract], [https://pypi.org/ जैसे पैकेजों का उपयोग करके project/PyContracts3/ PyContracts], [https://pypi.org/project/dpcontracts/ dpcontracts], या [https://pypi.org/project/zope.interface/ zope.interface]। 2003 में [https://peps.python.org/pep-0316/ PEP-316] में अनुबंधों द्वारा डिजाइन का समर्थन करने के लिए पायथन में एक स्थायी परिवर्तन प्रस्तावित किया गया था, लेकिन इसे स्थगित कर दिया गया है।
* [[पायथन (प्रोग्रामिंग भाषा)]], [https://github.com/life4/deal डील],आईकॉन्ट्रैक्ट, [https://pypi.org/ जैसे पैकेजों का उपयोग करके प्रोजेक्ट/पीईकॉन्ट्रैक्ट्स3/ पीईकॉन्ट्रैक्ट्स], [https://pypi.org/project/dpcontracts/ डीपीकॉन्ट्रैक्ट्स], या [https://pypi.org/project/zope.interface/ zope.इंटरफेस]। 2003 में [https://peps.python.org/pep-0316/ पीईपी-316] में अनुबंधों द्वारा डिजाइन का समर्थन करने के लिए पायथन में एक स्थायी परिवर्तन प्रस्तावित किया गया था, लेकिन इसे स्थगित कर दिया गया है।
* [[रूबी (प्रोग्रामिंग भाषा)]], ब्रायन मैकक्लिस्टर के DesignByContract, रूबी DBC रूबी-कॉन्ट्रैक्ट या कॉन्ट्रैक्ट्स.रूबी के माध्यम से।
* [[रूबी (प्रोग्रामिंग भाषा)]], ब्रायन मैकक्लिस्टर केडिजाइन द्वारा अनुबंध , रूबी डीबीसी रूबी-कॉन्ट्रैक्ट या कॉन्ट्रैक्ट्स.रूबी के माध्यम से।
* [[जंग (प्रोग्रामिंग भाषा)]] [https://crates.io/crates/contracts अनुबंध] क्रेट के माध्यम से।
* [[जंग (प्रोग्रामिंग भाषा)]] [https://crates.io/crates/contracts अनुबंध] क्रेट के माध्यम से।
* [[स्विफ्ट (प्रोग्रामिंग भाषा)]] [https://github.com/busybusy/DBC-Apple कोकोपॉड जिम बॉयड द्वारा] के माध्यम से।
* [[स्विफ्ट (प्रोग्रामिंग भाषा)]] [https://github.com/busybusy/DBC-Apple कोकोपॉड जिम बॉयड द्वारा] के माध्यम से।
* [[Tcl]], [[XOTcl]] ऑब्जेक्ट-ओरिएंटेड एक्सटेंशन के माध्यम से।
* [[Tcl|टीसीएल]], [[XOTcl|एक्सओटीसीएल]] ऑब्जेक्ट-ओरिएंटेड एक्सटेंशन के माध्यम से।


== यह भी देखें ==
== यह भी देखें ==
* घटक आधारित सॉफ्टवेयर इंजीनियरिंग
* कॉम्पोनेन्ट आधारित सॉफ्टवेयर इंजीनियरिंग
* शुद्धता (कंप्यूटर विज्ञान)
* शुद्धता (कंप्यूटर विज्ञान)
* रक्षात्मक प्रोग्रामिंग
* रक्षात्मक प्रोग्रामिंग
Line 200: Line 208:


==बाहरी संबंध==
==बाहरी संबंध==
* [https://www.eiffel.com/values/design-by-contract/ The Power of Design by Contract(TM)] A top-level description of DbC, with links to additional resources.
* [https://www.eiffel.com/values/design-by-contract/ The Power of Design by Contract(TM)] A top-level description of डीबीसी, with links to additional resources.
* [http://archive.eiffel.com/doc/manuals/technology/contract/ Building bug-free O-O software: An introduction to Design by Contract(TM)] Older material on DbC.
* [http://archive.eiffel.com/doc/manuals/technology/contract/ Building bug-free O-O software: An introduction to Design by Contract(TM)] Older material on डीबीसी.
* [http://www.rps-obix.com/docs/manuals/design_by_contract_contract_programming.html Benefits and drawbacks; implementation in RPS-Obix]
* [http://www.rps-obix.com/docs/manuals/design_by_contract_contract_programming.html Benefits and drawbacks; implementation in RPS-Obix]
* Bertrand Meyer, [http://se.ethz.ch/~meyer/publications/computer/contract.pdf  ''Applying "Design by Contract"''], IEEE Computer, October 1992.
* Bertrand Meyer, [http://se.ethz.ch/~meyer/publications/computer/contract.pdf  ''Applying "Design by Contract"''], IEEE Computer, October 1992.
Line 208: Line 216:


{{DEFAULTSORT:Design By Contract}}
{{DEFAULTSORT:Design By Contract}}
<!--Categories-->[[Category: सॉफ्टवेर डिज़ाइन]] [[Category: प्रोग्रामिंग प्रतिमान]]
<!--Categories-->
 
 


[[Category: Machine Translated Page]]
[[Category:All articles with unsourced statements|Design By Contract]]
[[Category:Created On 19/02/2023]]
[[Category:Articles with unsourced statements from June 2019|Design By Contract]]
[[Category:Articles with unsourced statements from September 2012|Design By Contract]]
[[Category:CS1 maint|Design By Contract]]
[[Category:Collapse templates|Design By Contract]]
[[Category:Created On 19/02/2023|Design By Contract]]
[[Category:Lua-based templates|Design By Contract]]
[[Category:Machine Translated Page|Design By Contract]]
[[Category:Navigational boxes| ]]
[[Category:Navigational boxes without horizontal lists|Design By Contract]]
[[Category:Pages with reference errors|Design By Contract]]
[[Category:Pages with script errors|Design By Contract]]
[[Category:Short description with empty Wikidata description|Design By Contract]]
[[Category:Sidebars with styles needing conversion|Design By Contract]]
[[Category:Template documentation pages|Documentation/doc]]
[[Category:Templates Vigyan Ready|Design By Contract]]
[[Category:Templates generating microformats|Design By Contract]]
[[Category:Templates that add a tracking category|Design By Contract]]
[[Category:Templates that are not mobile friendly|Design By Contract]]
[[Category:Templates that generate short descriptions|Design By Contract]]
[[Category:Templates using TemplateData|Design By Contract]]
[[Category:Wikipedia metatemplates|Design By Contract]]
[[Category:प्रोग्रामिंग प्रतिमान|Design By Contract]]
[[Category:सॉफ्टवेर डिज़ाइन|Design By Contract]]

Latest revision as of 12:16, 28 August 2023

अनुबंध योजना द्वारा एक डिजाइन

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

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

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

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

इतिहास

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

औपचारिक सत्यापन, औपचारिक विनिर्देश और होरे तर्क पर काम में अनुबंध द्वारा डिजाइन की जड़ें हैं। मूल योगदान में शामिल हैं:

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

विवरण

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

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

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

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

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

  • अनुबंध क्या अपेक्षा करता है?
  • अनुबंध क्या गारंटी देता है?
  • अनुबंध क्या रखता है?

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

एक अनुबंध की धारणा विधि/प्रक्रिया स्तर तक फैली हुई है; प्रत्येक विधि के अनुबंध में आम तौर पर निम्नलिखित जानकारी शामिल होगी:[citation needed]

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

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

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

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

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

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

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

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

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

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

प्रदर्शन निहितार्थ

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

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

एक तर्क के रूप में -O ("ऑप्टिमाइज़" के लिए) के साथ पायथन निर्वचक को प्रक्षेपित करने से इसी तरह पायथन कोड जनरेटर को अभिकथन के लिए किसी भी बायटेकोड का उत्सर्जन नहीं करने का कारण बनता है।[9]

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







सॉफ्टवेयर परीक्षण से संबंध

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

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

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

भाषा समर्थन

देशी समर्थन वाली भाषाएं

अधिकांश डीबीसी सुविधाओं को मूल रूप से लागू करने वाली भाषाओं में सम्मिलित हैं:

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

तृतीय-पक्ष समर्थन वाली भाषाएं

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

यह भी देखें

टिप्पणियाँ

  1. Meyer, Bertrand: Design by Contract, Technical Report TR-EI-12/CO, Interactive Software Engineering Inc., 1986
  2. Meyer, Bertrand: Design by Contract, in Advances in Object-Oriented Software Engineering, eds. D. Mandrioli and B. Meyer, Prentice Hall, 1991, pp. 1–50
  3. Meyer, Bertrand: Applying "Design by Contract", in Computer (IEEE), 25, 10, October 1992, pp. 40–51, also available online
  4. ""डिज़ाइन बाय कॉन्ट्रेक्ट" के लिए संयुक्त राज्य पेटेंट और ट्रेडमार्क कार्यालय पंजीकरण". Archived from the original on 2016-12-21. Retrieved 2009-06-22.
  5. "संयुक्त राज्य अमेरिका पेटेंट और ट्रेडमार्क कार्यालय पंजीकरण "अनुबंध द्वारा डिजाइन" शब्दों के साथ ग्राफिक डिजाइन के लिए". Archived from the original on 2016-12-21. Retrieved 2009-06-22.
  6. "ट्रेडमार्क स्थिति और दस्तावेज़ पुनर्प्राप्ति". tarr.uspto.gov.
  7. "ट्रेडमार्क स्थिति और दस्तावेज़ पुनर्प्राप्ति". tarr.uspto.gov.
  8. "Assertions in Managed Code". msdn.microsoft.com.
  9. Official Python Docs, assert statement
  10. Bright, Walter (2014-11-01). "D Programming Language, Contract Programming". Digital Mars. Retrieved 2014-11-10.
  11. Hodges, Nick. "Write Cleaner, Higher Quality Code with Class Contracts in Delphi Prism". Embarcadero Technologies. Retrieved 20 January 2016.
  12. Findler, Felleisen Contracts for Higher-Order Functions
  13. "Scala Standard Library Docs - Assertions". EPFL. Retrieved 2019-05-24.
  14. Strong typing as another "contract enforcing" in Scala, see discussion at scala-lang.org/.
  15. "Code Contracts". msdn.microsoft.com.
  16. "Bean Validation specification". beanvalidation.org.
  17. "Software Testing Help from the Experts | Parasoft Resources" (PDF). Archived (PDF) from the original on 2022-10-09.
  18. "Archived copy" (PDF). Archived from the original (PDF) on 2016-03-28. Retrieved 2016-03-25.{{cite web}}: CS1 maint: archived copy as title (link) p. 2
  19. "No chance of releasing under Apache/Eclipse/MIT/BSD license? · Issue #5 · nhatminhle/cofoja". GitHub.


ग्रन्थसूची

  • 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.


बाहरी संबंध