रनटाइम सत्यापन

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

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

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

रनटाइम सत्यापन के व्यापक क्षेत्र के भीतर, कई श्रेणियों में अंतर किया जा सकता है, जैसे:
 * विनिर्देश-रहित निगरानी जो अधिकांशतः संगामिति-संबंधित गुणों जैसे परमाणुता के निश्चित सेट को लक्षित करती है। सैवेज एट अल द्वारा इस क्षेत्र में अग्रणी कार्य किया गया है। इरेज़र एल्गोरिथ्म के साथ
 * लौकिक तर्क विशिष्टताओं के संबंध में निगरानी; इस दिशा में प्रारंभिक योगदान ली, कन्नन और उनके सहयोगियों द्वारा किया गया है, और Havelund और Rosu,।

मूल दृष्टिकोण
रनटाइम सत्यापन विधियों के व्यापक क्षेत्र को तीन आयामों द्वारा वर्गीकृत किया जा सकता है: * निष्पादन के दौरान ही (ऑनलाइन) या निष्पादन के बाद सिस्टम की निगरानी की जा सकती है। लॉग विश्लेषण (ऑफ़लाइन) के रूप में।
 * सत्यापन कोड सिस्टम में एकीकृत है (जैसा कि रनटाइम सत्यापन#आस्पेक्ट-ओरिएंटेड प्रोग्रामिंग|एस्पेक्ट-ओरिएंटेड प्रोग्रामिंग में किया गया है) या बाहरी इकाई के रूप में प्रदान किया गया है।
 * मॉनिटर वांछित विनिर्देश के उल्लंघन या सत्यापन की रिपोर्ट कर सकता है।

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

उदाहरण
नीचे दिए गए उदाहरण कुछ सरल गुणों पर चर्चा करते हैं, जिन पर इस लेखन के समय (अप्रैल 2011) तक कई रनटाइम सत्यापन समूहों द्वारा संभवतः छोटे बदलावों के साथ विचार किया गया है। उन्हें और अधिक रोचक बनाने के लिए, नीचे दी गई प्रत्येक संपत्ति अलग विनिर्देश औपचारिकता का उपयोग करती है और ये सभी पैरामीट्रिक हैं। पैरामीट्रिक गुण पैरामीट्रिक घटनाओं के साथ बनने वाले निशान के बारे में गुण हैं, जो ऐसी घटनाएँ हैं जो डेटा को मापदंडों से बाँधती हैं। यहाँ पैरामीट्रिक संपत्ति का रूप है $$\forall parameters : \varphi$$, कहाँ $$\varphi$$ सामान्य (अस्थिर) पैरामीट्रिक घटनाओं का जिक्र करते हुए कुछ उचित औपचारिकता में विनिर्देश है। ऐसे पैरामीट्रिक गुणों के लिए अंतर्ज्ञान यह है कि संपत्ति द्वारा व्यक्त की गई $$\varphi$$ देखे गए ट्रेस में सभी पैरामीटर उदाहरणों (पैरामीट्रिक घटनाओं के माध्यम से) का सामना करना चाहिए। निम्नलिखित में से कोई भी उदाहरण किसी विशेष रनटाइम सत्यापन प्रणाली के लिए विशिष्ट नहीं है, हालांकि मापदंडों के लिए समर्थन स्पष्ट रूप से आवश्यक है। निम्नलिखित उदाहरणों में जावा सिंटैक्स माना जाता है, इस प्रकार == तार्किक समानता है, जबकि = असाइनमेंट है। कुछ तरीके (जैसे,  UnsafeEnumExample में) डमी तरीके हैं, जो जावा एपीआई का हिस्सा नहीं हैं, जिनका उपयोग स्पष्टता के लिए किया जाता है।

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

$$\forall ~ \text{Iterator} ~ i \quad i.\text{next} ~ \rightarrow ~ \odot (i.\text{hasNext} == true)$$ यह सूत्र कहता है कि किसी भी कॉल को  विधि को तुरंत कॉल से पहले होना चाहिए   विधि जो सत्य लौटाती है। यहां की संपत्ति इटरेटर में पैरामीट्रिक है. संकल्पनात्मक रूप से, इसका मतलब है कि परीक्षण कार्यक्रम में प्रत्येक संभावित इटरेटर के लिए मॉनिटर की प्रति होगी, हालांकि रनटाइम सत्यापन सिस्टम को अपने पैरामीट्रिक मॉनिटर को इस तरह लागू करने की आवश्यकता नहीं है। इस संपत्ति के लिए मॉनिटर हैंडलर को ट्रिगर करने के लिए सेट किया जाएगा जब सूत्र का उल्लंघन किया जाता है (समकक्ष जब परिमित राज्य मशीन त्रुटि स्थिति में प्रवेश करती है), जो कि तब होगा  पहले कॉल किए बिना कॉल किया जाता है , या जब   पूर्व कहा जाता है  , लेकिन false लौटाया।

असुरक्षित ईनम
जावा में वेक्टर वर्ग के अपने तत्वों पर पुनरावृति के लिए दो साधन हैं। कोई भी इटरेटर इंटरफ़ेस का उपयोग कर सकता है, जैसा कि पिछले उदाहरण में देखा गया है, या कोई Enumeration इंटरफ़ेस का उपयोग कर सकता है। Iterator इंटरफ़ेस के लिए निकालने की विधि को जोड़ने के अलावा, मुख्य अंतर यह है कि Iterator तेजी से विफल होता है जबकि Enumeration नहीं है। इसका मतलब यह है कि यदि कोई वेक्टर को संशोधित करता है (इटरेटर हटाने की विधि का उपयोग करने के अलावा) जब कोई इटरेटर का उपयोग करके वेक्टर पर पुनरावृति करता है, तो /java/util/ConcurrentModificationException.html ConcurrentModificationException फेंका गया है। हालाँकि, गणना का उपयोग करते समय यह मामला नहीं है, जैसा कि उल्लेख किया गया है। इसका परिणाम कार्यक्रम से गैर-नियतात्मक परिणाम हो सकता है क्योंकि वेक्टर को गणना के परिप्रेक्ष्य से असंगत स्थिति में छोड़ दिया जाता है। लीगेसी प्रोग्राम के लिए जो अभी भी गणना इंटरफ़ेस का उपयोग करते हैं, कोई यह लागू करना चाह सकता है कि जब उनके अंतर्निहित वेक्टर को संशोधित किया जाता है तो गणना का उपयोग नहीं किया जाता है। इस व्यवहार को लागू करने के लिए निम्नलिखित पैरामीट्रिक नियमित पैटर्न का उपयोग किया जा सकता है:


 * ∀ वेक्टर वी, गणना ई: (ई = v.elements ) (e.nextElement )* v.update e.nextElement

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

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


 * ∀ थ्रेड टी, लॉक एल: एस → ε | एस शुरू (टी) एस अंत (टी) | एस एल अधिग्रहण (टी) एस एल रिलीज (टी)

पैटर्न प्रत्येक थ्रेड और लॉक के लिए नेस्टेड प्रारंभ/समाप्ति और अधिग्रहण/रिलीज जोड़े के संतुलित अनुक्रम निर्दिष्ट करता है ($$\epsilon$$ खाली क्रम है)। यहां प्रारंभ और अंत कार्यक्रम में प्रत्येक विधि की शुरुआत और अंत को संदर्भित करता है (स्वयं को प्राप्त करने और जारी करने के लिए कॉल को छोड़कर)। वे थ्रेड में पैरामीट्रिक हैं क्योंकि विधियों की शुरुआत और अंत को जोड़ना आवश्यक है यदि और केवल तभी जब वे ही थ्रेड से संबंधित हों। उसी कारण से थ्रेड में अधिग्रहण और रिलीज़ इवेंट भी पैरामीट्रिक हैं। वे, अतिरिक्त रूप से, लॉक में पैरामीट्रिक हैं क्योंकि हम लॉक की रिलीज़ को दूसरे के अधिग्रहण के साथ संबद्ध नहीं करना चाहते हैं। अत्यधिक में, यह संभव है कि संपत्ति का उदाहरण होगा, अर्थात, थ्रेड के साथ लॉक के प्रत्येक संभावित संयोजन के लिए संदर्भ-मुक्त पार्सिंग तंत्र की प्रति; यह फिर से, सहज रूप से होता है, क्योंकि रनटाइम सत्यापन सिस्टम समान कार्यक्षमता को अलग तरीके से लागू कर सकते हैं। उदाहरण के लिए, यदि किसी सिस्टम में थ्रेड्स हैं $$t_1$$, $$t_2$$, और $$t_3$$ ताले के साथ $$l_1$$ और $$l_2$$, तो जोड़े < के लिए संपत्ति के उदाहरणों को बनाए रखना संभव है$$t_1$$,$$l_1$$>, <$$t_1$$,$$l_2$$>, <$$t_2$$,$$l_1$$>, <$$t_2$$,$$l_2$$>, <$$t_3$$,$$l_1$$>, और <$$t_3$$,$$l_2$$>। पैटर्न से मिलान करने में विफलताओं के लिए इस संपत्ति की निगरानी की जानी चाहिए क्योंकि पैटर्न सही व्यवहार निर्दिष्ट करता है। दाईं ओर का आंकड़ा निशान दिखाता है जो इस संपत्ति के दो उल्लंघनों का उत्पादन करता है। नीचे दिए गए चरण विधि की शुरुआत का प्रतिनिधित्व करते हैं, जबकि ऊपर के चरण अंत हैं। चित्र में ग्रे तीर ही लॉक के दिए गए अधिग्रहण और रिलीज के बीच मिलान दिखाते हैं। सादगी के लिए, ट्रेस केवल थ्रेड और लॉक दिखाता है।

अनुसंधान चुनौतियाँ और अनुप्रयोग
अधिकांश रनटाइम सत्यापन शोध नीचे सूचीबद्ध या अधिक विषयों को संबोधित करते हैं।

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


 * बेहतर उपकरण। निष्पादन प्रणाली से घटनाओं को निकालने और उन्हें मॉनिटर पर भेजने से बड़े रनटाइम ओवरहेड उत्पन्न हो सकते हैं यदि भोलेपन से किया जाता है। किसी भी रनटाइम सत्यापन उपकरण के लिए अच्छा सिस्टम इंस्ट्रूमेंटेशन महत्वपूर्ण है, जब तक कि उपकरण मौजूदा निष्पादन लॉग को स्पष्ट रूप से लक्षित न करे। वर्तमान उपयोग में कई इंस्ट्रूमेंटेशन दृष्टिकोण हैं, प्रत्येक अपने फायदे और नुकसान के साथ, कस्टम या मैनुअल इंस्ट्रूमेंटेशन से लेकर विशेष पुस्तकालयों तक, आस्पेक्ट-ओरिएंटेड भाषाओं में संकलन करने के लिए, वर्चुअल मशीन को बढ़ाने के लिए, हार्डवेयर सपोर्ट पर निर्माण करने के लिए।
 * स्थैतिक विश्लेषण के साथ संयोजन। साधारण स्थैतिक और गतिशील विश्लेषणों का संयोजन, विशेष रूप से संकलकों में सामना करना, उन सभी आवश्यकताओं की निगरानी करना है जिन्हें स्थिर रूप से निर्वहन नहीं किया जा सकता है। दोहरी और अंततः समतुल्य दृष्टिकोण आदर्श बन जाता है रनटाइम सत्यापन में, अर्थात् संपूर्ण निगरानी की मात्रा को कम करने के लिए स्थैतिक कार्यक्रम विश्लेषण का उपयोग करने के लिए। निगरानी की जाने वाली संपत्ति और निगरानी की जाने वाली प्रणाली दोनों पर स्थैतिक विश्लेषण किया जा सकता है। मॉनिटर करने के लिए संपत्ति के स्थैतिक विश्लेषण से पता चलता है कि कुछ घटनाएं निगरानी के लिए अनावश्यक हैं, कि कुछ मॉनिटरों के निर्माण में देरी हो सकती है, और यह कि कुछ मौजूदा मॉनिटर कभी ट्रिगर नहीं होंगे और इस प्रकार कचरा एकत्र किया जा सकता है। मॉनिटर करने के लिए सिस्टम का स्थिर विश्लेषण कोड का पता लगा सकता है जो मॉनिटर को कभी प्रभावित नहीं कर सकता है। उदाहरण के लिए, उपरोक्त HasNext संपत्ति की निगरानी करते समय, किसी को कोड के उपकरण भागों की आवश्यकता नहीं होती है जहां प्रत्येक कॉल होती है  कॉल द्वारा किसी भी रास्ते पर तुरंत पहले होता है   जो true लौटाता है (नियंत्रण-प्रवाह ग्राफ़ पर दिखाई देता है)।
 * कुशल मॉनिटर निर्माण और प्रबंधन। उपरोक्त उदाहरणों में पैरामीट्रिक गुणों की निगरानी करते समय, निगरानी प्रणाली को प्रत्येक पैरामीटर उदाहरण के संबंध में निगरानी की गई संपत्ति की स्थिति का ट्रैक रखने की आवश्यकता होती है। ऐसे उदाहरणों की संख्या सैद्धांतिक रूप से अबाध है और व्यवहार में बहुत अधिक हो जाती है। महत्वपूर्ण शोध चुनौती यह है कि कैसे देखी गई घटनाओं को कुशलतापूर्वक उन घटनाओं को ठीक से प्रेषित किया जाए जिनकी उन्हें आवश्यकता है। संबंधित चुनौती यह है कि ऐसे उदाहरणों की संख्या को कैसे कम रखा जाए (ताकि प्रेषण तेजी से हो), या दूसरे शब्दों में, यथासंभव लंबे समय तक अनावश्यक उदाहरण बनाने से कैसे बचा जाए और साथ ही, पहले से बनाए गए उदाहरणों को जल्द से जल्द कैसे हटाया जाए वे अनावश्यक हो जाते हैं। अंत में, पैरामीट्रिक मॉनिटरिंग एल्गोरिदम आम तौर पर गैर-पैरामीट्रिक मॉनिटर बनाने के लिए समान एल्गोरिदम का सामान्यीकरण करते हैं। इस प्रकार, उत्पन्न गैर-पैरामीट्रिक मॉनिटर की गुणवत्ता परिणामी पैरामीट्रिक मॉनिटर की गुणवत्ता तय करती है। हालाँकि, अन्य सत्यापन विधियों (जैसे, मॉडल जाँच) के विपरीत, रनटाइम सत्यापन में राज्यों की संख्या या उत्पन्न मॉनिटर का आकार कम महत्वपूर्ण है; वास्तव में, कुछ मॉनिटरों में असीम रूप से कई अवस्थाएँ हो सकती हैं, जैसे कि उपरोक्त SafeLock संपत्ति के लिए, हालाँकि किसी भी समय केवल राज्यों की सीमित संख्या हो सकती है। महत्वपूर्ण यह है कि निष्पादन प्रणाली से घटना प्राप्त होने पर मॉनिटर राज्य से अपने अगले राज्य में कितनी कुशलता से स्थानांतरित होता है।

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


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

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

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


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

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

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

बढ़ता कवरेज
अधिक पारंपरिक सत्यापन दृष्टिकोणों की तुलना में, रनटाइम सत्यापन का तत्काल नुकसान इसकी कम कवरेज है। यह समस्याग्रस्त नहीं है जब रनटाइम मॉनिटर सिस्टम के साथ तैनात किए जाते हैं (संपत्ति का उल्लंघन होने पर निष्पादित किए जाने वाले उपयुक्त पुनर्प्राप्ति कोड के साथ), लेकिन यह सिस्टम में त्रुटियों को खोजने के लिए उपयोग किए जाने पर रनटाइम सत्यापन की प्रभावशीलता को सीमित कर सकता है। त्रुटि का पता लगाने के उद्देश्यों के लिए रनटाइम सत्यापन के कवरेज को बढ़ाने की तकनीकों में शामिल हैं:


 * इनपुट जनरेशन। यह सर्वविदित है कि इनपुट्स का अच्छा सेट (प्रोग्राम इनपुट वेरिएबल वैल्यू, सिस्टम कॉल वैल्यू, थ्रेड शेड्यूल आदि) उत्पन्न करने से परीक्षण की प्रभावशीलता में काफी वृद्धि हो सकती है। यह त्रुटि का पता लगाने के लिए उपयोग किए जाने वाले रनटाइम सत्यापन के लिए भी सही है, लेकिन इनपुट जनरेशन प्रक्रिया को चलाने के लिए प्रोग्राम कोड का उपयोग करने के अलावा, रनटाइम सत्यापन में संपत्ति विनिर्देशों का उपयोग भी किया जा सकता है, जब उपलब्ध हो, और प्रेरित करने के लिए निगरानी तकनीकों का भी उपयोग कर सकता है। वांछित व्यवहार। रनटाइम सत्यापन का यह उपयोग इसे मॉडल-आधारित परीक्षण से निकटता से संबंधित बनाता है, हालांकि रनटाइम सत्यापन विनिर्देश आमतौर पर सामान्य उद्देश्य होते हैं, जरूरी नहीं कि परीक्षण कारणों से तैयार किए गए हों। उदाहरण के लिए, विचार करें कि कोई उपरोक्त सामान्य-उद्देश्य UnsafeEnum गुण का परीक्षण करना चाहता है। सिस्टम निष्पादन को निष्क्रिय रूप से देखने के लिए उपर्युक्त मॉनिटर को उत्पन्न करने के बजाय, कोई भी स्मार्ट मॉनिटर उत्पन्न कर सकता है जो थ्रेड को दूसरे e.nextElement ईवेंट (इसे उत्पन्न करने से ठीक पहले) उत्पन्न करने का प्रयास करता है। अन्य धागे इस उम्मीद में निष्पादित होते हैं कि उनमें से v.update घटना उत्पन्न कर सकता है, जिस स्थिति में त्रुटि पाई गई है।
 * गतिशील प्रतीकात्मक निष्पादन। प्रतीकात्मक निष्पादन में कार्यक्रमों को प्रतीकात्मक रूप से क्रियान्वित और मॉनिटर किया जाता है, अर्थात, बिना ठोस इनपुट के। सिस्टम के प्रतीकात्मक निष्पादन में ठोस इनपुट का बड़ा सेट शामिल हो सकता है। ऑफ-द-शेल्फ बाधा समाधान या संतुष्टि जांच तकनीकों का उपयोग अक्सर प्रतीकात्मक निष्पादन चलाने या उनके स्थान को व्यवस्थित रूप से एक्सप्लोर करने के लिए किया जाता है। जब अंतर्निहित संतुष्टि जांचकर्ता विकल्प बिंदु को संभाल नहीं सकते हैं, तो उस बिंदु को पास करने के लिए ठोस इनपुट उत्पन्न किया जा सकता है; 'कॉन्स' रीटे और सिम्ब'ऑलिक निष्पादन के इस संयोजन को कॉनकोलिक निष्पादन भी कहा जाता है।

यह भी देखें

 * गतिशील कार्यक्रम विश्लेषण
 * प्रोफाइलिंग (कंप्यूटर प्रोग्रामिंग)
 * रनटाइम त्रुटि का पता लगाना
 * रनटाइम एप्लिकेशन सेल्फ-प्रोटेक्शन (RASP)