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

From Vigyanwiki
No edit summary
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|अनुबंध योजना द्वारा एक डिजाइन]]अनुबंध द्वारा डिजाइन (डीबीसी), जिसे अनुबंध प्रोग्रामिंग, अनुबंध द्वारा प्रोग्रामिंग और डिज़ाइन-बाय-कॉन्ट्रैक्ट प्रोग्रामिंग '''के रूप में भी जाना जाता है, [[सॉफ्टवेर डिज़ाइन]] के लिए दृष्टिकोण है।'''


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


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


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


== इतिहास ==
== इतिहास ==
यह शब्द [[बर्ट्रेंड मेयर]] द्वारा [[एफिल (प्रोग्रामिंग भाषा)]] के अपने डिजाइन के संबंध में गढ़ा गया था और पहली बार 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 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}}</रेफरी>


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


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


== सॉफ्टवेयर परीक्षण से संबंध ==
== सॉफ्टवेयर परीक्षण से संबंध ==
Line 147: Line 147:
*** [[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>
*** [[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>
*** आईकॉन्ट्रैक्ट2/जेकॉन्ट्रैक्ट्स
*** आईकॉन्ट्रैक्ट2/जेकॉन्ट्रैक्ट्स
*** अनुबंध 4 जे
*** '''अनुबंध 4 जे'''
*** जेकॉन्ट्रैक्ट्स
*** जेकॉन्ट्रैक्ट्स
*** C4जे
*** '''C4जे'''
*** गूगल कोडप्रो एनालिटिक्स
*** गूगल कोडप्रो एनालिटिक्स
*** [[स्प्रिंग फ्रेमवर्क]] के लिए स्प्रिंगकॉन्ट्रैक्ट्स
*** [[स्प्रिंग फ्रेमवर्क]] के लिए स्प्रिंगकॉन्ट्रैक्ट्स

Revision as of 12:16, 14 March 2023

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

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

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

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

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

इतिहास

यह शब्द बर्ट्रेंड मेयर द्वारा एफिल (प्रोग्रामिंग भाषा) के अपने डिजाइन के संबंध में गढ़ा गया था और पहली बार 1986 से शुरू होने वाले विभिन्न लेखों [1][2][3] और उनकी पुस्तक वस्तु-उन्मुख सॉफ्टवेयर निर्माण के दो लगातार संस्करण (1988, 1997) में वर्णित है। एफिल सॉफ्टवेयर ने दिसंबर 2003 में अनुबंध द्वारा डिजाइन के लिए ट्रेडमार्क पंजीकरण के लिए आवेदन किया था, और इसे दिसंबर 2004 में प्रदान किया गया था।Cite error: Closing </ref> missing for <ref> tag इस ट्रेडमार्क का वर्तमान अधिष्ठाता एफिल सॉफ्टवेयर है।Cite error: Closing </ref> missing for <ref> tag

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

यह प्रभावी रूप से उत्पादन कोड में अभिकथनों की रन-टाइम मूल्य को समाप्त करता है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. Official Python Docs, assert statement
  5. Bright, Walter (2014-11-01). "D Programming Language, Contract Programming". Digital Mars. Retrieved 2014-11-10.
  6. Hodges, Nick. "Write Cleaner, Higher Quality Code with Class Contracts in Delphi Prism". Embarcadero Technologies. Retrieved 20 January 2016.
  7. Findler, Felleisen Contracts for Higher-Order Functions
  8. "Scala Standard Library Docs - Assertions". EPFL. Retrieved 2019-05-24.
  9. Strong typing as another "contract enforcing" in Scala, see discussion at scala-lang.org/.
  10. "Code Contracts". msdn.microsoft.com.
  11. "Bean Validation specification". beanvalidation.org.
  12. "Software Testing Help from the Experts | Parasoft Resources" (PDF). Archived (PDF) from the original on 2022-10-09.
  13. "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
  14. "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.


बाहरी संबंध