मिशन क्रिटिकल सॉफ्टवेयर कैसे बनाएं?

15

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

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

लेकिन फिर यह कैसे सत्यापित किया जाए कि सॉफ्टवेयर (न केवल विनिर्देशन) वास्तव में सही है?

अस्वीकरण: जब मैं सैद्धांतिक कंप्यूटर विज्ञान की बात करता हूं तो मैं 90% बेवकूफ हूं। इसलिए उत्तर देते समय कृपालु बनो।

program-verification formal-methods se.software-engineering

— fajrian
स्रोत

2

आप वास्तव में "... कि सॉफ्टवेयर वास्तव में सही है ..." के साथ क्या मतलब है ? निम्नलिखित 2 में से आपका क्या मतलब है: 1) सॉफ्टवेयर विनिर्देश 2 के साथ पालन करता है ) कोड के विशिष्ट ब्लॉक कुछ दिए गए संपत्ति या कुछ इनपुट - आउटपुट संबंध का सम्मान करते हैं।

— जियोर्जियो कैमरानी

@ जियोर्जियोकैमेरानी: पहले एक

— फाजरियन

2

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

— रादु GRIGore

@RaduGRIGore: वास्तव में मुझे समझ नहीं आ रहा है कि "मॉडल" क्या है। लेकिन मुझे लगता है कि आप मेरे प्रश्न को काफी बारीकी से संबोधित करते हैं। मूल रूप से, जो मैं सोच रहा हूं वह विनिर्देश और प्रोग्राम स्रोत कोड के बीच का अंतर है। कई बेवकूफ चीजें हो सकती हैं जब प्रोग्रामर (मेरे जैसे) विनिर्देश को लागू कर रहे हैं।

— फज्रियन

1

@fajrian: मुझे संदेह है कि आप 'मॉडल' के लिए 'विनिर्देश' कहते हैं। ऐसे उपकरण हैं जो सी या जावा, या मशीन कोड जैसी भाषाओं में लिखे गए कार्यक्रमों पर काम करते हैं। (यह अभी भी एक मॉडल है, हालांकि, जैसा कि उन्हें कुछ शब्दार्थों को ग्रहण करना है , जो कि करना चाहिए , लेकिन संकलक / प्रोसेसर के अनुरूप नहीं हो सकता है।)

— रादू ग्रिगोर

11

सवाल बल्कि व्यापक है। एक उचित जगह में इसका जवाब देने के लिए मैं कई ओवरसिंप्लिमेंट्स बनाऊंगा।

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

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

(छोटा कदम) परिचालनात्मक शब्दार्थ : यह एक प्रोग्रामिंग भाषा को परिभाषित करने के लिए एक दुभाषिया लिखकर बहुत पसंद है। इसके लिए आपको यह कहने की आवश्यकता है कि राज्य क्या है , और यह भाषा के प्रत्येक कथन से प्रभावित होता है। (आप आश्चर्यचकित कर सकते हैं कि आप किस भाषा में दुभाषिया लिखते हैं, लेकिन मैं दिखावा करूँगा कि आप नहीं हैं।)
स्वयंसिद्ध शब्दार्थ : यहाँ प्रत्येक कथन प्रकार एक स्वयंसिद्ध स्कीमा के साथ आता है। तो, मोटे तौर पर, जब भी उस प्रकार के किसी विशेष कथन का उपयोग किया जाता है, तो वह कुछ स्वयंसिद्ध शब्दों का उपयोग करने में सक्षम होने में अनुवाद करता है। उदाहरण के लिए, असाइनमेंट स्कीमा साथ आता है ${\bf x}:={\bf e}$ ; विशेष असाइनमेंट स्वयंसिद्ध साथ आता है $\{P[{\bf x}/{\bf e}]\}\,{\bf x}:={\bf e}\,\{P\}$ $x:=x+1$ यदि हम स्कीमा को त्वरित करते हैं। $\{x+1=1\}\,x:=x+1\,\{x=1\}$ $P=(x=1)$

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

नेचुला, ली, प्रूफ-कैरिंग कोड , 1996

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

सारांश में, मैं आपके प्रश्न के तीन कारणों के बारे में सोच सकता था:

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

यह उत्तर केवल तीन अलग-अलग तरीकों की पहचान करने की कोशिश कर रहा है जिसमें मैंने प्रश्न को समझा। इनमें से किसी भी बिंदु पर गहराई में जाने के लिए बहुत अधिक जगह की आवश्यकता होगी।

— राडू ग्रिगोर
स्रोत

8

एक कार्यक्रम और इसके विनिर्देश के बीच अंतर को कम करने के लिए एक दृष्टिकोण एक औपचारिक शब्दार्थ के साथ एक भाषा का उपयोग करना है। यहां एक दिलचस्प उदाहरण एस्टेरेल होगा । अपने काम के बारे में कुछ दिलचस्प बातचीत के लिए जेरार्ड बेरी के वेब पेज पर एक नज़र डालें ताकि वास्तविक दुनिया में औपचारिक तरीके ला सकें। http://www-sop.inria.fr/members/Gerard.Berry/

ps एक एयरबस पर किया गया है? आप औपचारिक तरीकों से बह गए हैं!

— रॉस डंकन
स्रोत

1

एयरबस औपचारिक तरीकों का उपयोग कैसे करता है पर कोई भी मददगार होगा। (समझते हैं कि इसके स्वामित्व की जानकारी है।)

— vzn

@RossDuncan मुझे बेरी के वेब पेज और कुछ खोजों पर जाने के बाद यह वेब पेज मिला । क्या यह औपचारिक तरीके एयरबस का उपयोग कर रहे थे जिसका आप उल्लेख कर रहे थे?

— स्काउहू

मुझे एस्टरेल के एयरबस उपयोग के बारे में कोई जानकारी नहीं है; मेरी टिप्पणी बस एक टिप्पणी दोहराती है जो बेरी ने एक व्याख्यान के दौरान की थी। हालांकि यह पेज एयरबस के साथ SCADE उत्पाद के सफल उपयोग को ट्रम्पेट करता है। यदि आप एस्टेरेल के इतिहास को देखते हैं, तो इसे डसॉल्ट ने काफी पहले ही अपना लिया था। Google आपका मित्र है

— रॉस डंकन

2

Airbus भी astree.ens.fr

— Radu GRIGore

7

"वास्तविक दुनिया" में विश्वसनीय सॉफ़्टवेयर के निर्माण का विज्ञान अभी भी विकसित हो रहा है और कुछ हद तक एक अंतर्निहित सांस्कृतिक या मानवशास्त्रीय अध्ययन पर निर्भर है, क्योंकि कंप्यूटर और सॉफ़्टवेयर "बग" के कारण मनुष्य नहीं करते हैं! यह उत्तर सामान्य क्यू / ए दृष्टिकोण पर केंद्रित होगा जिसमें औपचारिक सॉफ्टवेयर सत्यापन को एक तत्व के रूप में देखा जा सकता है।

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

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

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

यह मदद करता है अगर टीम बी में अच्छी सॉफ्टवेयर इंजीनियरिंग पृष्ठभूमि है, यानी खुद कोड हार्नेस / प्रोग्रामेटिक टेस्ट वगैरह लिख सकते हैं। उस मामले में टीम बी के पास दूसरी तरफ टीम ए के रूप में लगभग समान संसाधन थे, यह दृष्टिकोण महंगा है क्योंकि यह सॉफ्टवेयर के निर्माण की लागत को लगभग दोगुना कर सकता है। अधिक सामान्यतः, विकास टीम की तुलना में एक छोटी QA टीम होती है।

— vzn
स्रोत

8

किसी को विनिर्देशन के संबंध में शुद्धता के लिए अपने ओएस की जांच करनी चाहिए कि शिफ्ट कुंजी को दबाने और एक पत्र एक बड़े अक्षर का उत्पादन करता है।

— बाउर

1

परिशिष्ट: अनुसूची की कमी गुणवत्ता को प्रभावित कर सकती है। यह भी देखें कि mgt त्रिभुज परियोजना से बना है, जो लागत, गुणवत्ता से युक्त है, "3" से प्रभावित "क्षेत्र" 3. यह भी देखें कि "आईटी उद्योग बड़े, दोषरहित परियोजनाओं को अन्य उद्योगों की तरह जल्दी क्यों नहीं दे सकता है?" । एन-संस्करण आइटम को स्वयं [इसके कवर किए गए अन्य उत्तर] में शामिल नहीं किया गया था, लेकिन ध्यान दें कि फेनमैन ने उल्लेख किया कि नासा ने अंतरिक्ष शटल डिजाइन में भी इसका इस्तेमाल किया था।

— vzn

1

यह भी, "क्यों isnt सॉफ्टवेयर एक कार के रूप में विश्वसनीय"?

— vzn

1

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

— vzn

6

एक पुराना दृष्टिकोण (लेकिन यह अभी भी कुछ अनुप्रयोगों में उपयोग किया जाता है) एन-संस्करण प्रोग्रामिंग है

विकिपीडिया से:

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

उदाहरण के लिए देखें: " बिल्डिंग फॉल्ट में चुनौतियां - सिविल एयरक्राफ्ट के लिए सहिष्णु उड़ान नियंत्रण प्रणाली "

— मारजियो दे बियासी
स्रोत

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

— नील कृष्णस्वामी

@ नीलकृष्णस्वामी: मैं सहमत हूँ! हालांकि मुझे लगता है (लेकिन मैं एक विशेषज्ञ नहीं हूं) जो काम नहीं करता है, उसे प्रतिस्थापित किया जाना चाहिए क्योंकि यह अन्य दृष्टिकोणों की तुलना में विश्वसनीयता में सुधार नहीं करता है । के एंड एल का हवाला देते हुए: " ... हमने कभी यह सुझाव नहीं दिया कि हमारे परिणाम को एन-संस्करण प्रोग्रामिंग की प्रभावशीलता के बारे में निर्णय के लिए एक आधार के रूप में उपयोग किया जाना चाहिए। हमने केवल सुझाव दिया है कि सावधानी उपयुक्त होगी ... "। मुझे लगता है कि NVP दृष्टिकोण महत्वपूर्ण प्रणाली के डिजाइन के लिए कितना उपयोगी हो सकता है, इस पर बहस अभी भी खुली है (खुरई एट अल का हालिया काम देखें)

— Marzio De Biasi

4

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

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

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

केवल परीक्षण एक औपचारिक तरीका नहीं है, ऐसा करने से विश्वसनीयता में सुधार होता है लेकिन शुद्धता की जांच नहीं होती है।

3

दो या तीन साल पहले मैंने सॉफ्टवेयर पर लागू औपचारिक तरीकों पर एक नज़र रखना शुरू किया। यह जिज्ञासा से प्रेरित एक खोज थी, और इस भावना से कि मुझे प्रोग्रामिंग टूल और तरीकों को लंबे समय तक सीखना है। हालाँकि मैं सिल्वर बुलेट के बारे में इच्छा से सपने देखता था, लेकिन मैंने वास्तव में सोचा था कि इस सवाल का जवाब नहीं था: "मैं एक सही कार्यक्रम कैसे कर सकता हूं?"।

कुछ उपकरण (Z, B, VHDL, और एस्टेल) आज़माने के बाद इस खोज के बिंदु पर, मैं TLA + का उपयोग कर रहा हूँ । यह मॉडल जाँच और मैकेनिक सबूत के लिए सॉफ्टवेयर टूल के साथ एक अस्थायी तर्क है। मुझे लगता है कि मैं इस दृष्टिकोण को चुनता हूं क्योंकि एल। लेम्पपोर्ट इसके पीछे था, वाक्यविन्यास सरल था, बहुत सारे उदाहरण थे, एक समुदाय था जो इसकी देखभाल कर रहा था, और भाषा और उपकरण काफी अच्छी तरह से प्रलेखित थे।

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

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

इस खोज के दौरान, मैंने निम्नलिखित संसाधनों को उपयोगी पाया है:

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

सौभाग्य!

— marcmagransdeabril
स्रोत

1

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

मिशन क्रिटिकल सॉफ्टवेयर कैसे बनाएं?

ऐसे उपकरण मौजूद हैं जो त्रुटियों के लिए स्वचालित रूप से आपके कोड का विश्लेषण करते हैं (विनिर्देश, या "विशिष्ट बग" का उल्लंघन)। मेरे ज्ञान के लिए, ये विधियाँ ज्यादातर स्थैतिक विश्लेषण पर आधारित हैं और आपके द्वारा उल्लिखित सिद्धांतों (LTL / CTL / ...) से संबंधित नहीं हैं, लेकिन वे वास्तविक कोड में त्रुटियां पाते हैं और यह व्यावहारिक रूप से व्यावहारिक रूप से पहले से ही संभव है औद्योगिक परियोजनाओं में ऐसे उपकरणों का उपयोग करने के लिए देखें। मैंने व्यक्तिगत रूप से उनमें से कई का उपयोग नहीं किया है, लेकिन ऐसा लगता है कि ये उपकरण चिकित्सकों द्वारा स्वीकार किए जाने लगे हैं। आगे पढ़ने के लिए, मैं निम्नलिखित ब्लॉग लेख की सिफारिश कर सकता हूं:

http://www.altdevblogaday.com/2011/12/24/static-code-analysis/

— मार्कस
स्रोत

उदाहरण के जावा के साथ कार्यान्वयन, खुला स्रोत अपाचे- फाइंडबग्स

— vzn

0

मिशन महत्वपूर्ण सॉफ़्टवेयर का निर्माण करते समय प्रमाणित एल्गोरिदम उपयोगी हो सकते हैं।

एक प्रमाणित एल्गोरिथ्म एक एल्गोरिथ्म है जो प्रत्येक आउटपुट के साथ, एक प्रमाणिक ate केट या गवाह (आसान-से-सत्यापित प्रमाण) का उत्पादन करता है, जो विशेष आउटपुट बग से समझौता नहीं किया गया है।

मैककोनेल, आरएम और मेहरॉर्न, के। और नाहर, एस। और श्वित्ज़र, पी। द्वारा इस सर्वेक्षण पत्र को प्रमाणित करने वाले एल्गोरिदम में और पढ़ें ।

— प्रतीक देवघर
स्रोत

1998 में, पन्नेली, सीगल और सिंगरमैन ने नाम ट्रांसलेशन सत्यापन के तहत कंपाइलरों पर लागू इस विचार का वर्णन किया । संकलक स्वाभाविक रूप से उच्च-क्रम हैं (इनपुट एक प्रोग्राम है, आउटपुट एक प्रोग्राम है), इसलिए वे सत्यापित करने के लिए कठिन हो जाते हैं। लेकिन X. Leroy जैसे पागल लोग हैं जो वैसे भी सत्यापित कंपाइलर विकसित करते हैं। (सबसे अच्छा संभव अर्थों में पागल!)

— रादू ग्रिगोर

-2

लेकिन फिर यह कैसे सत्यापित किया जाए कि सॉफ्टवेयर (न केवल विनिर्देशन) वास्तव में सही है?

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

सैद्धांतिक रूप से कहें तो, यदि आपके यूनिट परीक्षणों में 100% कोड कवरेज है (अर्थात आपके कोड की हर एक विधि का परीक्षण किया जाता है) तो आपका सॉफ्टवेयर सही होना चाहिए, बशर्ते परीक्षण स्वयं सटीक और यथार्थवादी हों।

— gillesv
स्रोत

5

किसी भी यथोचित जटिल कार्यक्रम के लिए, कोड कवरेज (परीक्षण द्वारा) शुद्धता सुनिश्चित नहीं कर सकता है। आपको सभी संभावित निष्पादन को कवर करना होगा; कोड की सभी पंक्तियाँ पर्याप्त नहीं हैं।

— रादु GRIGore

1

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

— मार्टिन बर्गर

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

— फज्रियन 14

2

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

— नीचा

1

@vzn: क्या मैंने कहा कि आपने अन्यथा कहा? मैं बस यह समझाने की कोशिश कर रहा था कि मुझे क्यों विश्वास है कि अन्य लोग इस उत्तर को नहीं बढ़ा रहे हैं। इस समय मैं इस प्रश्न का उत्तर नहीं दे सकता, क्योंकि मैं इसे नहीं समझता।

— रादु GRIGore