वे कौन सी बाधाएँ हैं जो औपचारिक तरीकों को व्यापक रूप से अपनाने से रोकती हैं? [बन्द है]

Question

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

हम रोज़मर्रा की प्रोग्रामिंग के लिए, या वेब एप्लिकेशन आदि में इसका अधिक उपयोग क्यों नहीं करते ...?

संदर्भ:

• औपचारिक तरीके
• B विधि
• होरे तर्क

Comments

हम 5 फुट मोटी दीवारों वाले घरों का निर्माण कर सकते थे - जैसे मध्यकालीन महल। अधिकांश समय, कि यह इसके लायक है की तुलना में अधिक परेशानी होगी।

— बाल्ड्रिक

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

— आमोन

तो आप प्रोग्रामिंग भाषा में प्रोग्रामिंग के बजाय एक विनिर्देश भाषा में निर्दिष्ट करना पसंद करेंगे? ठीक है, आप यह साबित करने में सक्षम होंगे कि यह चश्मा के अनुसार काम करता है। लेकिन आप कैसे साबित करने जा रहे हैं कि विनिर्देश वास्तविक समस्या को दर्शाता है?

— क्रिस्तोफ़े

@ सवाल यह है: चीजों को सही करना (चश्मे के अनुसार काम करना) या सही चीजें करना (अच्छे चश्मे होना)। : एक ओर जहां सिद्धांत रूप में कल्पना हम क्या चाहते है, व्यवहार में हम शायद ही कभी यकीन के लिए पता है कि वास्तव में जरूरत है beyssonmanagement.com/2012/10/29/...

— क्रिस्टोफ़

उन लोगों के लिए जो निराश हैं कि यह बंद हो गया है अब एक महान ब्लॉग पोस्ट है: व्हाई डोंट पीपल यूज़ फॉर्मल मेथड्स?

— icc97

Answer 1

एक इंजीनियर एक ऐसा व्यक्ति है जो एक डॉलर के साथ क्या कर सकता है जो कोई भी बेवकूफ 10 के साथ कर सकता है।

संसाधन की कमी, बजट की कमी, समय की कमी, वे सभी महत्वपूर्ण हैं।

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

उस कारण से, औपचारिक तरीकों, साक्ष्यों, कार्यक्रम सत्यापन और इसी तरह की तकनीकों का उपयोग आम तौर पर "सामान है कि मायने रखता है" तक सीमित है, अर्थात एविओनिक्स सॉफ्टवेयर, चिकित्सा उपकरणों के लिए नियंत्रण प्रणाली, बिजली संयंत्र, आदि।

Comments

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

— jk।

मैं इस उत्तर को स्वीकार करता हूं, लेकिन मैं यह भी चाहता था कि औपचारिक तरीकों को अभी भी 'महंगा' और 'समय लेने वाला' क्यों माना जाता है, खासकर जब हम जानते हैं कि बड़ी परियोजनाओं पर रखरखाव और कोड ट्रैकिंग / डिबगिंग कितना महंगा है।

— टोटो

TDD और BDD, होरे तर्क के सिद्धांतों पर निर्मित दृष्टिकोण हैं, जो औपचारिक दृष्टिकोण की एक नींव है। वे दक्षता में सुधार करते हैं इससे अलग नहीं होते हैं।

— मार्टिन स्पैमर

@ टोटो प्रूफ वास्तव में, वास्तव में कठिन हैं। गणितज्ञों के लिए बहुत सी चीजें प्रमाणों में दी गई हैं जो कार्यक्रमों में लागू नहीं होती हैं। उदाहरण के लिए, C ++, इसके अलावा नहीं साहचर्य है: (-1 + 1) + INT_MAX = INT_MAX, -1 + (1 + INT_MAX)अपरिभाषित व्यवहार है।

— होवरकच

@toto: उन्हें "महंगी" और "समय लेने वाली" माना जाता है, क्योंकि हम उन परियोजनाओं को देख सकते हैं जो औपचारिक तरीकों का उपयोग करके विकसित की जाती हैं और अनुभवजन्य रूप से सत्यापित करती हैं कि उन परियोजनाओं को विकसित होने में अधिक समय लगता है। SeL4 / L4.verified के विकास समय को देखें, उदाहरण के लिए, L4 के किसी भी अन्य कार्यान्वयन की तुलना में ।

— जोर्ग डब्ल्यू मित्तग

Answer 2

प्रोग्राम करना है या नहीं?

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

चीजें सही कर रहे हैं या सही चीजें कर रहे हैं?

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

जिन आवश्यकताओं पर आप काम कर रहे हैं वे अपूर्ण या अस्पष्ट हो सकती हैं। वे छोटी गाड़ी भी हो सकती हैं। सबसे खराब स्थिति में, वास्तविक जरूरतों को भी व्यक्त नहीं किया जाता है। लेकिन एक चित्र एक हजार शब्दों के लायक है, बस "ग्राहक क्या चाहता है" के लिए Google चित्र, उदाहरण के लिए इस लेख से :

औपचारिकता की लागत

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

व्यवहार में, यह शायद ही कभी वास्तविकता है! यही कारण है कि इतने सारे झरने की परियोजनाएं विफल हो गईं , और क्यों पुनरावृत्ति विकास विधियों (फुर्तीली, रेड, आदि) ने नेतृत्व किया: वे अपूर्ण और अपूर्ण आवश्यकताओं को संभाल सकते हैं, डिजाइन और कार्यान्वयन कर सकते हैं और उन्हें ठीक कर सकते हैं जब तक कि वे ठीक न हों।

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

प्रयोग में

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

अद्यतन: मापा प्रयास

एसीएम के संचार के अक्टूबर 2018 के अंक में प्रयास के कुछ अनुमानों के साथ वास्तविक दुनिया में औपचारिक रूप से सत्यापित सॉफ्टवेयर के बारे में एक दिलचस्प लेख है ।

दिलचस्प रूप से (सैन्य उपकरणों के लिए ओएस विकास पर आधारित), ऐसा लगता है कि औपचारिक रूप से सिद्ध सॉफ्टवेयर का निर्माण पारंपरिक इंजीनियरिंग तकनीकों की तुलना में 3.3 गुना अधिक प्रयास की आवश्यकता है । तो यह वास्तव में महंगा है।

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

seL4 डिजाइन और कोड विकास में दो व्यक्ति-वर्ष लगे। पिछले कुछ वर्षों में सी कोड की 8,700 लाइनों के लिए कुल 18 व्यक्ति-वर्ष आते हैं। इसकी तुलना में, L4Ka :: L4 परिवार में एक और माइक्रोकर्नल, पिस्ता, seL4 के आकार में तुलनीय है, इसे विकसित करने और आश्वासन का कोई महत्वपूर्ण स्तर प्रदान करने के लिए छह व्यक्ति-वर्ष लगे। इसका मतलब है कि सत्यापित सॉफ्टवेयर और पारंपरिक रूप से इंजीनियर सॉफ्टवेयर के बीच केवल एक कारक 3.3 है । Colbert और Boehm द्वारा अनुमान पद्धति के अनुसार, C कोड की 8,700 लाइनों के लिए एक सामान्य कॉमन क्राइटेरिया EAL7 प्रमाणन 45 से अधिक व्यक्ति-वर्ष लेगा। इसका मतलब है कि औपचारिक बाइनरी-स्तरीय कार्यान्वयन सत्यापन पहले से ही 2.3 के एक कारक से अधिक है आम मानदंड के उच्चतम प्रमाणीकरण स्तर की तुलना में कम महंगा अभी तक काफी मजबूत आश्वासन प्रदान करता है।

Comments

अनुबंध आधारित प्रोग्रामिंग कम से कम अनौपचारिक साक्ष्यों का उपयोग करती है।

— फ्रैंक हिलमैन

@FrankHileman हाँ! और पूर्व शर्त, स्पष्टवादिता और अपरिवर्तन को स्पष्ट करने का सरल तथ्य कोड को कुशलतापूर्वक समीक्षा करने, त्रुटियों को कम करने और व्यवस्थित परीक्षण में बहुत मदद करता है।

— क्रिस्टोफ

यह अब तक का सबसे अच्छा जवाब होना चाहिए।

— हाशिम

Answer 3

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

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

निचले स्तर के विवरण के लिए उच्च स्तर की आवश्यकताओं की मैपिंग वास्तविक प्रोग्रामिंग के बारे में जानकारी है। यह आश्चर्य की बात नहीं होनी चाहिए कि प्रोग्रामर द्वारा पढ़ने और विशिष्टताओं की व्याख्या करने वाले मुख्य कार्य को हाथ से लहराते हुए प्रतिस्थापित नहीं किया जा सकता है और कहा जा सकता है कि 'अब यह देखें कि क्या यह उच्च स्तरीय औपचारिक विनिर्देश इस नमूना कार्यक्रम द्वारा अनुपालन किया जाता है'।

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