कार्यक्रम की शुद्धता, विनिर्देश

Question

विकिपीडिया से: सैद्धांतिक कंप्यूटर विज्ञान में, एल्गोरिथ्म की शुद्धता पर जोर दिया जाता है जब यह कहा जाता है कि विनिर्देश के संबंध में एल्गोरिथ्म सही है।

लेकिन समस्या यह है कि "उपयुक्त" विनिर्देश प्राप्त करना कोई तुच्छ कार्य नहीं है, और सही पाने के लिए कोई 100% सही तरीका नहीं है (जहाँ तक मुझे पता है), यह सिर्फ एक अनुमान है, इसलिए यदि हम जा रहे हैं एक विनिर्देश के रूप में एक विधेय ले लो क्योंकि यह "एक" की तरह "दिखता है", कार्यक्रम को केवल इसलिए सही नहीं लेना चाहिए क्योंकि यह "सही" दिखता है?

Comments

क्योंकि उम्मीद है कि विनिर्देश कार्यक्रम की तुलना में कम जटिल है इसलिए इसमें कार्यक्रम की तुलना में कम गलतियाँ होंगी।

— user253751

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

— बाग़

@ मिनीबिस लेकिन अगर इसमें सिर्फ एक ही गलती है तो पूरी बात गलत है

— मेकेल जैक्सन

@MaykelJakson सच ... मैंने एक बार रोडिन में एक स्वयंसिद्ध खंडन गलती से किया था (जो मैं करने की कोशिश कर रहा था वह सही था लेकिन वाक्य रचना गलत थी)। इससे पहले कि मुझे लगता है कि "ऑटो हम्म ऑटो-असामान्य रूप से अच्छी तरह से काम कर रहा है", इससे पहले कि मुझे ध्यान आए कुछ समय हो गया।

— user253751

Answer 1

सबसे पहले, आप बिल्कुल सही हैं: आप एक वास्तविक चिंता पर हैं। औपचारिक सत्यापन कार्यक्रम की शुद्धता में विश्वास की समस्या को विनिर्देशन शुद्धता में विश्वास की समस्या को स्थानांतरित करता है, इसलिए यह एक चांदी की गोली नहीं है।

कई कारण हैं कि यह प्रक्रिया अभी भी उपयोगी हो सकती है, हालांकि।

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

2. असफलता का एक भी बिंदु नहीं है। मान लीजिए कि आपके पास एक व्यक्ति एक विनिर्देश लिख रहा है, और दूसरा व्यक्ति स्रोत कोड लिखता है, और फिर औपचारिक रूप से सत्यापित करता है कि कोड कल्पना से मिलता है। तब किसी भी अनिर्धारित दोष को युक्ति और कोड दोनों में उपस्थित होना होगा । कुछ मामलों में, कुछ प्रकार की खामियों के लिए, यह कम संभावना महसूस करता है: यह कम संभावना है कि जब आप ऐनक का निरीक्षण करेंगे और स्रोत कोड का निरीक्षण करते समय दोष की अनदेखी करेंगे। सभी नहीं, लेकिन कुछ।

3. आंशिक चश्मा कोड की तुलना में काफी सरल हो सकता है। उदाहरण के लिए, इस आवश्यकता पर विचार करें कि प्रोग्राम बफर ओवररन कमजोरियों से मुक्त है। या, आवश्यकता है कि कोई सरणी इंडेक्स आउट-ऑफ-बाउंड त्रुटियां नहीं हैं। यह एक सरल कल्पना है जो स्पष्ट रूप से साबित करने में सक्षम होने के लिए एक अच्छी और उपयोगी चीज है। अब आप यह साबित करने के लिए औपचारिक तरीकों का उपयोग करने की कोशिश कर सकते हैं कि पूरा कार्यक्रम इस कल्पना से मिलता है। यह एक काफी शामिल कार्य हो सकता है, लेकिन यदि आप सफल हैं, तो आप कार्यक्रम में आत्मविश्वास बढ़ाते हैं।

4. कोड की तुलना में ऐनक कम बार बदल सकता है। औपचारिक तरीकों के बिना, हर बार जब हम स्रोत कोड को अपडेट करते हैं, तो हमें मैन्युअल रूप से जांचना होगा कि अपडेट किसी बग या दोष का परिचय नहीं देगा। औपचारिक तरीके इस बोझ को संभावित रूप से कम कर सकते हैं: मान लें कि कल्पना नहीं बदलती है, ताकि सॉफ़्टवेयर अद्यतनों में केवल कोड में परिवर्तन हो और युक्ति में परिवर्तन न हो। फिर प्रत्येक अपडेट के लिए, आप यह जांचने के लिए कि क्या अभी भी सही है (यह नहीं बदला है, इसलिए यह सुनिश्चित करने के लिए कि कोई नया कीड़े नहीं पेश किया गया है) जांच करने के लिए बोझ से छुटकारा पा लिया गया है और बोझ की जाँच करने के लिए कि क्या कोड अभी भी है सही (प्रोग्राम सत्यापनकर्ता आपके लिए जाँच करता है)। आपको अभी भी यह जांचने की आवश्यकता है कि मूल कल्पना सही है, लेकिन तब आपको यह देखने की ज़रूरत नहीं है कि हर बार एक डेवलपर एक नया पैच / अपडेट / परिवर्तन करता है।

अंत में, याद रखें कि ऐनक आमतौर पर घोषणात्मक होते हैं और इसे आवश्यक रूप से निष्पादित नहीं किया जा सकता है और न ही कोड को सीधे संकलित किया जा सकता है। उदाहरण के लिए, फिर से छंटाई पर विचार करें: युक्ति कहती है कि आउटपुट बढ़ रहा है और इनपुट का एक क्रमचय है, लेकिन इस युक्ति को सीधे "निष्पादित" करने का कोई स्पष्ट तरीका नहीं है और संकलक के लिए कोई स्पष्ट तरीका स्वचालित रूप से इसे कोड करने के लिए संकलित नहीं करता है। तो बस कल्पना को सही मानें और इसे निष्पादित करना अक्सर एक विकल्प नहीं होता है।

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

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

Comments

एक तरफ के रूप में, एक कल्पना के रूप में और अधिक विस्तृत हो जाता है, संभावना है कि इसे स्यूडोकोड उगता के रूप में लिखा जा सकता है। अपने सॉर्टिंग उदाहरण का उपयोग करते हुए, "आउटपुट में बढ़ते क्रम में होना चाहिए" का एक अधिक विस्तृत संस्करण "आउटपुट में हर पूर्णांक होगा, पहले के बाद, पिछले संख्या से बड़ा होना चाहिए"। यह, बदले में, आसानी से for each integer I<उप> N</ उप> in set S (where N > 1) { assert I<उप> N</ उप> > I<उप> N - 1</ उप> की तरह कुछ लिखा जा सकता है }। अंकन के बारे में 100% निश्चित नहीं है।

— जस्टिन टाइम - मोनिका

तो, एक अच्छा चश्मा भी एक कोड बनाने में मदद कर सकता है, न कि केवल इसे सत्यापित करने के लिए।

— जस्टिन टाइम -

छँटाई युक्ति को निष्पादित करने का स्पष्ट तरीका इनपुट के सभी क्रमपरिवर्तन की गणना करना और आदेशित एक को चुनना है। के साथ समस्या यह है, हालांकि, स्पष्ट किया जाना चाहिए ...

— डेरेक Elkins एसई छोड़ दिया

Answer 2

डीडब्ल्यू का जवाब बहुत अच्छा है , लेकिन मैं एक बिंदु पर विस्तार करना चाहता हूं। एक विनिर्देश केवल एक संदर्भ नहीं है जिसके खिलाफ कोड सत्यापित है। औपचारिक विनिर्देश होने के कारणों में से एक यह है कि कुछ मूलभूत गुणों को साबित करके इसे मान्य किया जाए। बेशक, विनिर्देश पूरी तरह से मान्य नहीं किया जा सकता है - सत्यापन विनिर्देश के रूप में ही जटिल होगा, इसलिए यह एक अंतहीन प्रक्रिया होगी। लेकिन सत्यापन हमें कुछ महत्वपूर्ण गुणों पर एक मजबूत गारंटी प्राप्त करने की अनुमति देता है।

उदाहरण के लिए, मान लीजिए कि आप एक कार ऑटोपायलट डिजाइन कर रहे हैं। यह एक बहुत जटिल चीज है जिसमें बहुत सारे पैरामीटर शामिल हैं। ऑटोपायलट की शुद्धता गुणों में "कार एक दीवार के खिलाफ दुर्घटनाग्रस्त नहीं होगी" और "कार को वह स्थान बताएगा जहां इसे जाना है"। "कार एक दीवार के खिलाफ दुर्घटना नहीं होगी" जैसी संपत्ति वास्तव में महत्वपूर्ण है, इसलिए हम यह साबित करना चाहेंगे। चूंकि सिस्टम भौतिक दुनिया में संचालित होता है, इसलिए आपको कुछ भौतिक बाधाओं को जोड़ना होगा; कम्प्यूटेशनल प्रणाली की वास्तविक संपत्ति कुछ इस तरह होगी "सामग्री विज्ञान के बारे में इन धारणाओं के तहत, और कार के सेंसर द्वारा बाधाओं की धारणा के बारे में ये धारणाएं, कार एक दीवार के खिलाफ दुर्घटनाग्रस्त नहीं होगी"। लेकिन फिर भी, परिणाम अपेक्षाकृत सरल संपत्ति है जो स्पष्ट रूप से वांछनीय है।

क्या आप कोड से इस संपत्ति को साबित कर सकते हैं? अंत में, यह वही है जो चल रहा है, यदि आप पूरी तरह से औपचारिक दृष्टिकोण का पालन कर रहे हैं। लेकिन कोड के कई अलग-अलग हिस्से हैं; ब्रेक, कैमरा, इंजन आदि सभी को स्वायत्त रूप से नियंत्रित किया जाता है। ब्रेक की शुद्धता संपत्ति कुछ इस तरह होगी "यदि 'ब्रेक लागू होता है' संकेत है तो ब्रेक लागू होते हैं"। इंजन की शुद्धता संपत्ति "यदि क्लच सिग्नल बंद है तो इंजन पहियों को नहीं चला रहा है"। उन सभी को एक साथ रखने के लिए यह एक बहुत ही उच्च-स्तरीय दृश्य है। एक विनिर्देश एक मध्यवर्ती परत बनाता है जहां सिस्टम के विभिन्न घटकों को एक साथ जोड़ा जा सकता है।

वास्तव में, कार ऑटोपायलट के रूप में इस तरह की एक जटिल प्रणाली में कई प्रकार के विनिर्देश होंगे जिनमें अलग-अलग मात्रा में परिशोधन होते हैं। एक परिशोधन दृष्टिकोण अक्सर डिजाइन में उपयोग किया जाता है: कुछ उच्च-स्तरीय गुणों के साथ शुरू करें जैसे "कार एक दीवार के खिलाफ दुर्घटनाग्रस्त नहीं होगी", फिर यह पता लगाएं कि इसके लिए सेंसर और ब्रेक की आवश्यकता होती है और सेंसर के लिए कुछ बुनियादी आवश्यकताओं को पूरा करता है, ब्रेक और पायलट सॉफ्टवेयर, फिर घटक की डिज़ाइन में उन बुनियादी आवश्यकताओं को फिर से परिष्कृत करें (सेंसर के लिए, मुझे एक रडार, एक डीएसपी, एक छवि प्रसंस्करण पुस्तकालय, ...), आदि की आवश्यकता है, एक औपचारिक विकास प्रक्रिया में, विनिर्देश का प्रत्येक स्तर इसके ऊपर के स्तर से निर्धारित आवश्यकताओं को पूरा करने के लिए सिद्ध होता है, सभी उच्चतम स्तर के गुणों से लेकर कोड तक।

यह सुनिश्चित करना असंभव है कि विनिर्देश सही है। उदाहरण के लिए, यदि आपको भौतिकी गलत लगी है, तो ब्रेक प्रभावी नहीं हो सकता है, जबकि औपचारिक आवश्यकताओं के लिए ब्रेक कोड से संबंधित गणित सही है। यह साबित करने के लिए अच्छा नहीं है कि ब्रेक 500 किलोग्राम भार के साथ प्रभावी हैं यदि आपके पास वास्तव में 5000 किलोग्राम है। लेकिन यह देखना आसान है कि 500 ​​किलोग्राम ब्रेक कोड के अंदर देखने की तुलना में गलत है कि वे कार के भौतिक मापदंडों के लिए पर्याप्त नहीं होंगे।

A _{पूरी तरह से औपचारिक दृष्टिकोण के विपरीत "मुझे लगता है कि यह काम करता है, लेकिन मुझे यकीन नहीं हो सकता है"। जब आप इस पर अपना जीवन दांव पर लगा रहे हैं, तो यह इतना अच्छा नहीं लगता।}

Comments

क्या मेरे कोड की सिर्फ एक संपत्ति को साबित करना संभव है, और सुनिश्चित करें कि यह हमेशा सही होगा, उदाहरण के लिए मैं सिर्फ यह साबित करना चाहता हूं कि किसी सरणी का सूचकांक कभी भी सरणी के बाउंड के बाहर नहीं है, और मुझे इसकी परवाह नहीं है अन्य सामान?

— मेकेल जेक्सन

@MaykelJakson ज़रूर! तुम बस अपनी कल्पना के रूप में उपयोग करते हो। यह शायद एक कमजोर कल्पना है, लेकिन कुछ भी आपको इसका उपयोग करने से रोकता नहीं है और इसे साबित करने के लिए औपचारिक तरीकों का उपयोग करें।

— ची