व्यवहार में औपचारिक कार्यक्रम सत्यापन


66

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

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

क्या कोई व्यक्ति औपचारिक प्रमाण उपकरण टिप्पणी के अधिक अनुभव के साथ कर सकता है? फिर से - मैं एक औपचारिक उपकरण का उपयोग करने के लिए प्यार करता हूँ, मुझे लगता है कि वे महान हैं, लेकिन मुझे लगता है कि वे एक हाथी दांत टॉवर में हैं कि मैं जावा / सी ++ ... (PS: I) के नीच खाई से नहीं पहुंच सकता यह भी पसंद हास्केल, OCaml ... गलत विचार नहीं मिलता है: मैं कथात्मक भाषाओं और औपचारिक प्रमाण के एक प्रशंसक रहा हूँ, मैं सिर्फ देखने के लिए कि कैसे मैं वास्तविक सॉफ्टवेयर इंजीनियरिंग करने के लिए है कि उपयोगी बना सकता है कोशिश कर रहा हूँ)

अपडेट: चूंकि यह काफी व्यापक है, इसलिए निम्न निम्नलिखित विशिष्ट प्रश्नों का प्रयास करें: 1) औद्योगिक जावा / सी ++ कार्यक्रमों की शुद्धता साबित करने के लिए प्रवाहों का उपयोग करने के उदाहरण हैं? 2) क्या कोक उस कार्य के लिए उपयुक्त होगा? 3) अगर Coq उपयुक्त है, तो क्या मुझे पहले Coq में प्रोग्राम लिखना चाहिए, फिर Coq से C ++ / Java जेनरेट करें? 4) क्या यह दृष्टिकोण सूत्रण और प्रदर्शन अनुकूलन को संभाल सकता है?


3
मुझे आपकी समस्या की सराहना और सराहना मिल रही है, लेकिन मुझे यह समझ में नहीं आ रहा है कि यह प्रश्न क्या है (एसई पोस्ट के रूप में)। चर्चा? अनुभव? न ही एसई के लिए उपयुक्त है। "मैं जो भी कर सकता हूं?" टोन मुझे लगता है कि यह बहुत व्यापक प्रश्न है।
राफेल

3
मैं देख रहा हूँ ... मैं मानता हूँ कि यह प्रश्न स्पष्ट रूप से तैयार नहीं किया गया था। तो, आइए बताते हैं: 1) औद्योगिक जावा / सी ++ कार्यक्रमों की शुद्धता साबित करने के लिए प्रूवर्स का उपयोग करने के उदाहरण हैं? 2) क्या कोक उस कार्य के लिए उपयुक्त होगा? 3) अगर Coq उपयुक्त है, तो क्या मुझे पहले Coq में प्रोग्राम लिखना चाहिए, तो क्या Coq ने C ++ / Java उत्पन्न किया है? 4) क्या यह दृष्टिकोण थ्रेडिंग और प्रदर्शन अनुकूलन के साथ सामना कर सकता है?
फ्रैंक

2
तो यह चार प्रश्न हैं। 1) सॉफ्टवेयर इंजीनियरिंग से बेहतर है क्योंकि आप यहाँ (कई) उद्योग के पेशेवरों को चलाने की संभावना नहीं है। 2) कुछ व्यक्तिपरक है, लेकिन हमारे यहाँ ऐसे लोग हो सकते हैं जो एक उद्देश्यपूर्ण दृष्टिकोण प्रस्तुत कर सकते हैं। 3) है, जहाँ तक मैं बता सकता हूँ, पूरी तरह से व्यक्तिपरक। 4) इस साइट के लिए एक अच्छा सवाल है। संक्षेप में: कृपया अपने प्रश्नों को अलग करें, पहले सॉफ्टवेयर इंजीनियरिंग पर जाएं और इस बारे में कठिन सोचें कि क्या आप 2 पोस्ट करने से पहले यहां एक उद्देश्य (!) का जवाब दे सकते हैं।
राफेल

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

9
C ++ प्रोग्राम्स को सत्यापित करने में परेशानी यह है कि C ++ एक अच्छी तरह से परिभाषित भाषा नहीं है। मुझे नहीं लगता कि बड़े पैमाने पर सत्यापन तब तक संभव है जब तक कि सॉफ्टवेयर सिस्टम (ओएस, लाइब्रेरी, प्रोग्रामिंग लैंग्वेज) के कई हिस्से वास्तव में सत्यापन का समर्थन करने के लिए फिर से डिज़ाइन नहीं किए जाते। जैसा कि सर्वविदित है, आप किसी पर कोड की 200000 पंक्तियों को डंप नहीं कर सकते हैं और कह सकते हैं कि "सत्यापित करें!"। आपको कोड को एक साथ सत्यापित करने और लिखने की आवश्यकता है, और आपको अपनी प्रोग्रामिंग आदतों को इस तथ्य के अनुकूल बनाना होगा कि आप भी सत्यापित कर रहे हैं।
बाउर

जवाबों:


35

मैं आपके कुछ सवालों के जवाब देने की कोशिश करूंगा। कृपया ध्यान रखें कि यह कड़ाई से मेरे शोध का क्षेत्र नहीं है, इसलिए मेरी कुछ जानकारी पुरानी / गलत हो सकती है।

  1. कई उपकरण हैं जो विशेष रूप से जावा और सी ++ के गुणों को औपचारिक रूप से साबित करने के लिए डिज़ाइन किए गए हैं।

    हालाँकि मुझे यहाँ एक छोटा सा विषयांतर करने की आवश्यकता है: किसी कार्यक्रम की शुद्धता साबित करने का क्या मतलब है? जावा प्रकार चेकर एक जावा प्रोग्राम की एक औपचारिक संपत्ति साबित होता है, अर्थात् कुछ त्रुटियां, जैसे कि a floatऔर जोड़ना int, कभी नहीं हो सकती हैं! मुझे लगता है कि आप बहुत मजबूत गुणों में रुचि रखते हैं, अर्थात् आपका कार्यक्रम कभी भी अवांछित स्थिति में प्रवेश नहीं कर सकता है, या यह कि एक निश्चित फ़ंक्शन का आउटपुट एक निश्चित गणितीय विनिर्देश के अनुरूप है। संक्षेप में, "सुरक्षा को सही साबित करने" का एक व्यापक ढाल हो सकता है, सरल सुरक्षा गुणों से लेकर एक पूर्ण प्रमाण तक कि कार्यक्रम एक विस्तृत विनिर्देश पूरा करता है।

    अब मैं मानने जा रहा हूं कि आप अपने कार्यक्रमों के बारे में मजबूत गुण साबित करने में रुचि रखते हैं। यदि आप सुरक्षा गुणों में रुचि रखते हैं (आपका कार्यक्रम एक निश्चित स्थिति तक नहीं पहुंच सकता है), तो सामान्य तौर पर यह सबसे अच्छा तरीका है मॉडल की जाँच । हालाँकि, यदि आप एक जावा प्रोग्राम के व्यवहार को पूरी तरह से निर्दिष्ट करना चाहते हैं, तो आपका सबसे अच्छा शर्त उस भाषा के लिए विनिर्देशन भाषा का उपयोग करना है, उदाहरण के लिए JML । उदाहरण के लिए , CSL कार्यक्रमों के व्यवहार को निर्दिष्ट करने के लिए ऐसी भाषाएँ हैं , लेकिन मुझे C ++ के बारे में जानकारी नहीं है।

  2. एक बार आपके विनिर्देशों के अनुसार, आपको यह साबित करने की आवश्यकता है कि कार्यक्रम उस विनिर्देश के अनुरूप है।

    इसके लिए आपको एक ऐसे उपकरण की आवश्यकता होती है, जिसमें आपके विनिर्देशन और आपकी भाषा (जावा या C ++) के संचालन शब्दार्थ की औपचारिक समझ हो, ताकि पर्याप्तता प्रमेय को व्यक्त किया जा सके , अर्थात कार्यक्रम का निष्पादन विनिर्देशन का सम्मान करता है।

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

    • एक उपकरण जो कोड को पार्स करता है, विनिर्देश और पर्याप्तता प्रमेय उत्पन्न करता है। जैसा कि फ्रैंक ने उल्लेख किया है, क्राकाटोआ ऐसे उपकरण का एक उदाहरण है।

    • एक उपकरण जो प्रमेय (ओं) को स्वतः या अंतःक्रियात्मक रूप से सिद्ध करता है। Coq इस तरीके से क्राकाटो के साथ बातचीत करता है, और Z3 जैसे कुछ शक्तिशाली स्वचालित उपकरण हैं जिनका उपयोग भी किया जा सकता है।

    एक (मामूली) बिंदु: कुछ प्रमेय हैं जो स्वचालित विधियों के साथ सिद्ध होने के लिए बहुत कठिन हैं, और स्वचालित प्रमेय साबित करने वाले को कभी-कभी ध्वनि कीड़े होते हैं जो उन्हें कम भरोसेमंद बनाते हैं। यह एक ऐसा क्षेत्र है जहां Coq तुलना में चमकता है (लेकिन यह स्वचालित नहीं है!)।

  3. यदि आप Ocaml कोड जनरेट करना चाहते हैं, तो पहले Coq (गैलिना) में जरूर लिखें, फिर कोड निकालें। हालाँकि, Cq सी ++ या जावा उत्पन्न करने में भयानक है, यदि यह संभव है।

  4. क्या उपरोक्त उपकरण थ्रेडिंग और प्रदर्शन समस्याओं को संभाल सकते हैं? शायद नहीं, प्रदर्शन और थ्रेडिंग चिंताओं को विशेष रूप से डिज़ाइन किए गए टूल द्वारा नियंत्रित किया जाता है, क्योंकि वे विशेष रूप से कठिन समस्याएं हैं। मुझे यकीन नहीं है कि मेरे पास यहां सिफारिश करने के लिए कोई उपकरण है, हालांकि मार्टिन हॉफमैन की पॉलीनी परियोजना दिलचस्प लगती है।

निष्कर्ष में: "वास्तविक दुनिया" जावा और सी ++ कार्यक्रमों का औपचारिक सत्यापन एक बड़ा और अच्छी तरह से विकसित क्षेत्र है, और कोक उस कार्य के कुछ हिस्सों के लिए उपयुक्त है। आप उदाहरण के लिए यहां एक उच्च-स्तरीय अवलोकन पा सकते हैं ।


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

6
समस्या यह है कि उपयोगकर्ता "क्या चाहता है" आमतौर पर एक औपचारिक भाषा में व्यक्त नहीं किया जाता है! आम तौर पर इस सवाल का कोई औपचारिक जवाब नहीं है : "क्या यह औपचारिक विनिर्देश मेरे अनौपचारिक विचार के अनुरूप है?"। एक औपचारिक विनिर्देश का परीक्षण करना संभव है , और यह साबित करना है कि इसमें कुछ गणितीय गुण हैं, लेकिन अंततः आपको गणित को वास्तविक दुनिया से संबंधित करना होगा, जो एक गैर-औपचारिक प्रक्रिया है।
कोड़ी

हां, बिल्कुल - मुझे हमेशा एहसास हुआ कि औपचारिक तरीके केवल एक अच्छी तरह से परिभाषित बिंदु से शुरू हो सकते हैं। यदि वह विनिर्देश वास्तविक जीवन के उपयोगकर्ताओं की सचेत / अचेतन / अनदेखे जरूरतों के अनुरूप है या नहीं है, तो यह एक और समस्या है, जो औपचारिक तरीकों से पता करने योग्य नहीं है (लेकिन निश्चित रूप से इंजीनियरों के लिए एक समस्या है)।
फ्रैंक

एक प्रमेय एक सिद्ध प्रस्ताव द्वारा परिभाषा है। तो, आप शायद "प्रमेय साबित करने" के लिए नहीं हैं।
नबंर

@nbro विकिपीडिया आपसे सहमत नहीं दिख रहा है। मैथवर्ल्ड, हालांकि, एक प्रमेय को एक प्रस्ताव के रूप में परिभाषित करता है जिसे " स्वीकृत गणितीय कार्यों द्वारा सच होने के लिए प्रदर्शित किया जा सकता है"। इस मामले में, प्रमेयों का प्रमाण देना न केवल संभव है, बल्कि उन्हें कॉल करने के औचित्य के लिए आवश्यक है! :) (यह एक जवाबी कार्रवाई है, निश्चित रूप से)
कोड़ी

15

मैं उद्योग या गैर-तुच्छ वास्तविक प्रणालियों में औपचारिक तरीकों / औपचारिक सत्यापन उपकरणों के तीन उल्लेखनीय अनुप्रयोगों का उल्लेख करना चाहता हूं। ध्यान दें कि मुझे इस विषय पर बहुत कम अनुभव है और मैं उन्हें केवल कागजात पढ़ने से सीखता हूं।

  1. 2005 में नासा द्वारा जारी ओपन-सोर्स टूल जावा पाथफाइंडर (शॉर्ट के लिए जेपीएफ) निष्पादन योग्य जावा बाइटकोड कार्यक्रमों को सत्यापित करने के लिए एक प्रणाली है ( जावा पाथफाइंडर @ विकी देखें )। इसका उपयोग नासा एम्स में K9 रोवर के लिए कार्यकारी सॉफ्टवेयर में विसंगतियों का पता लगाने के लिए किया गया है।

  2. यह पत्र: गंभीर फ़ाइल सिस्टम त्रुटियों को खोजने के लिए मॉडल जाँच का उपयोग करना @ OSDI'04 दिखाता है कि फ़ाइल सिस्टम में गंभीर त्रुटियों को खोजने के लिए मॉडल की जाँच कैसे करें। FiSC नामक प्रणाली को तीन व्यापक रूप से उपयोग किए जाने वाले, भारी-परीक्षण किए गए फ़ाइल सिस्टम पर लागू किया जाता है: ext3, JFS और ReiserFS, और 32 गंभीर बग पाए जाते हैं। इसने बेस्ट पेपर अवार्ड जीता।

  3. यह पत्र: अमेज़न वेब सेवा औपचारिक तरीकों का उपयोग कैसे करती है @ CACM'15 बताता है कि कैसे AWS अपने उत्पादों जैसे S3, DynamoDB, EBS और आंतरिक वितरित लॉक मैनेजर के लिए औपचारिक तरीके लागू करता है। यह लामपोर्ट के टीएलए + टूल पर केंद्रित है । वैसे, लैम्पपोर्ट ने अपने टीएलए टूलबॉक्स का गहन उपयोग किया है। वह अक्सर कागजात के परिशिष्ट में स्वयं (साथ ही साथ coauthors) द्वारा प्रस्तावित एल्गोरिदम / प्रमेय के टीएलए में एक (काफी पूर्ण) औपचारिक सत्यापन देता है।


4

एक कार्यक्रम का एक औपचारिक विनिर्देश (कम या ज्यादा) एक अन्य प्रोग्रामिंग भाषा में लिखा गया कार्यक्रम है। नतीजतन, विनिर्देश निश्चित रूप से अपने स्वयं के कीड़े शामिल होंगे।

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

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

मुझे लगता है कि परीक्षण मामलों को स्थापित करने और उन्हें स्वचालित रूप से चलाने के लिए मचान आपके समय का बेहतर उपयोग होगा।


औपचारिक सत्यापन का लाभ यह है कि .... औपचारिक सत्यापन का एक दूसरा नुकसान यह है ... यह भ्रामक है।
hengxin

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

3

औपचारिक सत्यापन अब उन कार्यक्रमों के लिए संभव है, जिन्हें C ++ का सबसेट लिखा गया है, जो सुरक्षा-महत्वपूर्ण एम्बेडेड सिस्टम के लिए डिज़ाइन किया गया है। एक छोटी प्रस्तुति के लिए http://eschertech.com/papers/CanCPlusPlusBeMadeAsSafeAsSpark.ppt और पूर्ण पेपर के लिए http://eschertech.com/papers/CanCPlusPlusBeMadeAsSafeAsark.pdf देखें ।


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

2

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

आप कहते हैं "मैं परीक्षण से थक गया हूं" लेकिन औपचारिक सत्यापन वास्तव में परीक्षण का विकल्प नहीं है। एक तरह से परीक्षण पर इसका बदलाव

आप जावा का उल्लेख करें। कई उन्नत औपचारिक सत्यापन विधियां हैं, जिन्हें FindBugs नामक एक जावा सत्यापन कार्यक्रम में बनाया गया है, जिसे वास्तव में बड़े कोडबेस पर चलाया जा सकता है। ध्यान दें कि यह "गलत सकारात्मक और गलत नकारात्मक" दोनों को बदल देगा और परिणामों की समीक्षा / विश्लेषण एक मानव डेवलपर द्वारा करने की आवश्यकता है। लेकिन ध्यान दें, भले ही यह वास्तविक कार्यात्मक दोषों को चालू नहीं कर रहा है, यह आम तौर पर "एंटीपैटर्न" को चालू करता है जिसे कोड में वैसे भी टाला जाना चाहिए।

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

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

यहाँ लार्स फिलिप्सन द्वारा ईई क्षेत्र में औपचारिक सत्यापन उपकरणों के सर्वेक्षण का एक उदाहरण है ।


2
यह कहना भ्रामक है कि "बहुत सारे" औपचारिक सत्यापन "सिद्धांतों को प्रोग्रामर में शुद्धता का निर्माण करने के लिए बनाया गया है"। आप जिस चीज़ का उल्लेख करते हैं वह स्थिर प्रकार की जाँच है जो कुछ संकलक करते हैं, लेकिन गुण सत्यापित करते हैं कि तरीका सरल है, जैसे कि एक संख्या और एक स्ट्रिंग जोड़ने से बचें। यह सहायक है, लेकिन "औपचारिक सत्यापन" द्वारा आमतौर पर समझे जाने वाले कार्यों से बहुत दूर है।
मार्टिन बर्जर

2
विशेष रूप से स्थैतिक प्रकार की जाँच का उल्लेख नहीं किया, हालांकि यह एक सरल / सामान्य उदाहरण है। imho संकलक अनुकूलन तकनीक, जो व्यापक और उन्नत हैं, लगभग औपचारिक सत्यापन सिद्धांतों के समान हैं, क्योंकि वे अनुकूलित कार्यक्रम वेरिएंट की तुल्यता निर्धारित करने / दिखाने के लिए उन्नत तकनीकों को शामिल करते हैं। इसलिए ऐसा लगता है कि यहां "चलती गोलपोस्ट" के मुद्दे से बचना महत्वपूर्ण है और यह नहीं मानें कि केवल एक संकलक ऐसा करता है या इसके संकलक में निर्मित, इसका औपचारिक सत्यापन नहीं है।
vzn

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

2
वैसे JRE, जावा रनटाइम इंजन, जैसे डायनामिक ऑप्टिमाइज़ेशन, आदि में कुछ औपचारिक सत्यापन सिद्धांत भी लगते हैं ...
vzn

3
xy

1

शायद, एक मॉडल चेकर सहायक हो सकता है।

http://alloytools.org/documentation.html मिश्र धातु एक मॉडल चेकर है।

मिश्र धातु का उपयोग करके मॉडल की जाँच की अवधारणा को समझाने वाली एक अच्छी प्रस्तुति: https://www.youtube.com/watch?v=FvNRlE4B930Q

उपकरणों के एक ही परिवार में 'संपत्ति-आधारित परीक्षण' आता है, वे सभी आपके सॉफ़्टवेयर के दिए गए विनिर्देश मॉडल के लिए एक काउंटर-उदाहरण खोजने की कोशिश करते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.