Runtime verification
রানটাইম ভেরিফিকেশন হল একটি কম্পিউটিং সিস্টেম বিশ্লেষণ এবং কার্যকর করার পদ্ধতি যা একটি চলমান সিস্টেম থেকে তথ্য উত্তোলনের উপর ভিত্তি করে এবং নির্দিষ্ট বৈশিষ্ট্যগুলি সন্তোষজনক বা লঙ্ঘন করে পর্যবেক্ষণ করা আচরণগুলি সনাক্ত করতে এবং সম্ভবত প্রতিক্রিয়া জানাতে এটি ব্যবহার করে। কিছু খুব নির্দিষ্ট বৈশিষ্ট্য, যেমন ডেটারাস এবং ডেডলক ফ্রিডম, সাধারণত সমস্ত সিস্টেম দ্বারা সন্তুষ্ট হতে চায় এবং অ্যালগরিদম হিসাবে সর্বোত্তমভাবে প্রয়োগ করা যেতে পারে। অন্যান্য বৈশিষ্ট্যগুলি আনুষ্ঠানিক বৈশিষ্ট্য হিসাবে আরও সুবিধাজনকভাবে ধরা যেতে পারে। রানটাইম যাচাইকরণ নির্দিষ্টকরণগুলি সাধারণত ট্রেস প্রেডিকেট আনুষ্ঠানিকতায় প্রকাশ করা হয়, যেমন সীমাবদ্ধ রাষ্ট্র মেশিন, নিয়মিত অভিব্যক্তি, প্রসঙ্গ-মুক্ত নিদর্শন, রৈখিক সাময়িক যুক্তি ইত্যাদি, বা এগুলির সম্প্রসারণ। এটি স্বাভাবিক পরীক্ষার তুলনায় কম অ্যাড-হক পদ্ধতির অনুমতি দেয়। যাইহোক, একটি এক্সিকিউটিভ সিস্টেম পর্যবেক্ষণের জন্য যে কোনও প্রক্রিয়া রানটাইম যাচাইকরণ হিসাবে বিবেচিত হয়, যার মধ্যে রয়েছে পরীক্ষার ওরাকল এবং রেফারেন্স বাস্তবায়নের বিরুদ্ধে যাচাইকরণ। যখন আনুষ্ঠানিক প্রয়োজনীয়তার নির্দিষ্টকরণ সরবরাহ করা হয়, তখন মনিটরগুলি তাদের থেকে সংশ্লেষিত হয় এবং যন্ত্রের মাধ্যমে সিস্টেমের মধ্যে প্রবেশ করানো হয়। রানটাইম যাচাইকরণ অনেক উদ্দেশ্যে ব্যবহার করা যেতে পারে, যেমন নিরাপত্তা বা নিরাপত্তা নীতি পর্যবেক্ষণ, ডিবাগিং, পরীক্ষা, যাচাইকরণ, বৈধতা, প্রোফাইলিং, ত্রুটি সুরক্ষা, আচরণ পরিবর্তন (যেমন, পুনরুদ্ধার) ইত্যাদি। রানটাইম ভেরিফিকেশন ঐতিহ্যবাহী আনুষ্ঠানিক যাচাইকরণ কৌশলগুলির জটিলতা এড়িয়ে চলে, যেমন মডেল চেকিং এবং উপপাদ্য প্রমাণ, শুধুমাত্র একটি বা কয়েকটি এক্সিকিউশন ট্রেস বিশ্লেষণ করে এবং প্রকৃত সিস্টেমের সাথে সরাসরি কাজ করে, এইভাবে তুলনামূলকভাবে ভাল স্কেলিং করে এবং ফলাফলের উপর আরও আস্থা দেয় বিশ্লেষণ (কারণ এটি কম কভারেজের ব্যয়ে সিস্টেমটিকে আনুষ্ঠানিকভাবে মডেল করার ক্লান্তিকর এবং ত্রুটি-প্রবণ পদক্ষেপকে এড়িয়ে চলে)। উপরন্তু, তার প্রতিফলিত ক্ষমতার মাধ্যমে রানটাইম যাচাইকরণকে লক্ষ্য ব্যবস্থার একটি অবিচ্ছেদ্য অংশ করা যেতে পারে, স্থাপনার সময় এর কার্যকারিতা পর্যবেক্ষণ ও পরিচালনা করা যেতে পারে। সিস্টেম বা প্রোগ্রামগুলি কার্যকর করার বিরুদ্ধে আনুষ্ঠানিকভাবে বা অনানুষ্ঠানিকভাবে নির্দিষ্ট বৈশিষ্ট্যগুলি পরীক্ষা করা একটি পুরানো বিষয় (উল্লেখযোগ্য উদাহরণ হল সফ্টওয়্যারে গতিশীল টাইপিং, বা ব্যর্থ-নিরাপদ ডিভাইস বা হার্ডওয়্যারে নজরদারি টাইমার), যার সুনির্দিষ্ট শিকড়গুলি সনাক্ত করা কঠিন। আনুষ্ঠানিক যাচাইকরণ এবং পরীক্ষার মধ্যে সীমানায় সমস্যা সমাধানের লক্ষ্যে 2001 সালের একটি কর্মশালার নাম হিসাবে টার্মিনোলজি রানটাইম ভেরিফিকেশন আনুষ্ঠানিকভাবে চালু করা হয়েছিল। বড় কোড বেসগুলির জন্য, ম্যানুয়ালি টেস্ট কেসগুলি লিখতে খুব সময় লাগে। উপরন্তু, উন্নয়নের সময় সমস্ত ত্রুটি সনাক্ত করা যায় না। মহাকাশযান, রোভার এবং এভিওনিক্স প্রযুক্তিতে উচ্চ নিরাপত্তা মান সংরক্ষণের জন্য নাসা আমেস গবেষণা কেন্দ্রে ক্লাউস হ্যাভেলান্ড এবং গ্রিগোর রোসু দ্বারা স্বয়ংক্রিয় যাচাইকরণে প্রাথমিক অবদান রাখা হয়েছিল। তারা সাময়িক যুক্তিতে নির্দিষ্টকরণগুলি যাচাই করার জন্য এবং একক সম্পাদন পথ বিশ্লেষণ করে জাভা প্রোগ্রামগুলিতে রেসের পরিস্থিতি এবং ডেডলকগুলি সনাক্ত করার জন্য একটি সরঞ্জামের প্রস্তাব দেয়। বর্তমানে, রানটাইম যাচাইকরণ কৌশলগুলি প্রায়শই বিভিন্ন বিকল্প নামের সাথে উপস্থাপন করা হয়, যেমন রানটাইম পর্যবেক্ষণ, রানটাইম চেকিং, রানটাইম প্রতিফলন, রানটাইম বিশ্লেষণ, গতিশীল বিশ্লেষণ, রানটাইম/গতিশীল প্রতীকী বিশ্লেষণ, ট্রেস বিশ্লেষণ, লগ ফাইল বিশ্লেষণ ইত্যাদি, সবই বিভিন্ন ক্ষেত্রে বা বিভিন্ন সম্প্রদায়ের পণ্ডিতদের দ্বারা প্রয়োগ করা একই উচ্চ-স্তরের ধারণার উদাহরণগুলিকে বোঝায়। রানটাইম যাচাইকরণ অন্যান্য সুপ্রতিষ্ঠিত ক্ষেত্রগুলির সাথে ঘনিষ্ঠভাবে সম্পর্কিত, যেমন স্থাপনার আগে ব্যবহার করা হলে পরীক্ষা (বিশেষত মডেল-ভিত্তিক পরীক্ষা) এবং স্থাপনার সময় ব্যবহার করা হলে ত্রুটি-সহনশীল ব্যবস্থা। রানটাইম যাচাইকরণের বিস্তৃত ক্ষেত্রের মধ্যে, কেউ বিভিন্ন বিভাগকে আলাদা করতে পারে, যেমনঃ "নির্দিষ্টকরণ-কম" পর্যবেক্ষণ যা পারমাণবিকতার মতো বেশিরভাগ সমান্তরাল-সম্পর্কিত বৈশিষ্ট্যগুলির একটি নির্দিষ্ট সেটকে লক্ষ্য করে। এই ক্ষেত্রে অগ্রণী কাজটি করেছেন স্যাভেজ এবং অন্যান্যরা। সাময়িক যুক্তি নির্দিষ্টকরণের ক্ষেত্রে ইরেজার অ্যালগরিদম পর্যবেক্ষণের সাথে; এই দিকে প্রাথমিক অবদান লি, কান্নান এবং তাদের সহযোগী এবং হ্যাভেলান্ড এবং রোসু দ্বারা করা হয়েছে। মৌলিক পন্থা রানটাইম যাচাইকরণ পদ্ধতির বিস্তৃত ক্ষেত্রকে তিনটি মাত্রা দ্বারা শ্রেণীবদ্ধ করা যেতে পারেঃ সিস্টেমটি কার্যকর করার সময় (অনলাইন) বা কার্যকর করার পরে যেমন পর্যবেক্ষণ করা যেতে পারে। লগ বিশ্লেষণের আকারে (অফলাইন)। যাচাইকরণ কোডটি সিস্টেমে সংহত করা হয় (যেমনটি এস্পেক্ট-ওরিয়েন্টেড প্রোগ্রামিং-এ করা হয়) অথবা একটি বাহ্যিক সত্তা হিসাবে সরবরাহ করা হয়। মনিটর পছন্দসই নির্দিষ্টকরণের লঙ্ঘন বা বৈধতা রিপোর্ট করতে পারে। তবুও, রানটাইম যাচাইকরণের মৌলিক প্রক্রিয়াটি একই রকম থাকেঃ একটি মনিটর কিছু আনুষ্ঠানিক নির্দিষ্টকরণ থেকে তৈরি করা হয়। এই প্রক্রিয়াটি সাধারণত স্বয়ংক্রিয়ভাবে করা যেতে পারে যদি বৈশিষ্ট্যটি নির্দিষ্ট করা আনুষ্ঠানিক ভাষার সূত্রের জন্য সমতুল্য স্বয়ংক্রিয় থাকে। একটি নিয়মিত অভিব্যক্তি রূপান্তর করতে, একটি সসীম-অবস্থা যন্ত্র ব্যবহার করা যেতে পারে; রৈখিক সাময়িক যুক্তির একটি বৈশিষ্ট্যকে বুচি অটোম্যাটনে রূপান্তরিত করা যেতে পারে (এছাড়াও বুচি অটোম্যাটনের রৈখিক সাময়িক যুক্তি দেখুন)। সিস্টেমটি তার এক্সিকিউশন অবস্থা সম্পর্কিত ইভেন্টগুলি মনিটরের কাছে পাঠানোর জন্য যন্ত্রযুক্ত। সিস্টেমটি কার্যকর করা হয় এবং মনিটর দ্বারা যাচাই করা হয়। মনিটর প্রাপ্ত ইভেন্ট ট্রেস যাচাই করে এবং নির্দিষ্টকরণটি সন্তুষ্ট কিনা তা একটি রায় দেয়। উপরন্তু, মনিটর সম্ভবত মিথ্যা আচরণ সংশোধন করার জন্য সিস্টেমে প্রতিক্রিয়া পাঠায়। অফলাইন পর্যবেক্ষণ ব্যবহার করার সময় কারণের ব্যবস্থা কোনও প্রতিক্রিয়া গ্রহণ করতে পারে না, কারণ যাচাইকরণ পরবর্তী সময়ে করা হয়। উদাহরণগুলি নীচের উদাহরণগুলি কিছু সহজ বৈশিষ্ট্য নিয়ে আলোচনা করে যা এই লেখার সময় (এপ্রিল 2011) বেশ কয়েকটি রানটাইম যাচাইকরণ গোষ্ঠী দ্বারা সম্ভবত ছোট বৈচিত্র্য সহ বিবেচনা করা হয়েছে। এগুলিকে আরও আকর্ষণীয় করার জন্য, নীচের প্রতিটি বৈশিষ্ট্য একটি ভিন্ন নির্দিষ্টকরণ আনুষ্ঠানিকতা ব্যবহার করে এবং সেগুলি সবই প্যারামেট্রিক। প্যারামেট্রিক বৈশিষ্ট্যগুলি প্যারামেট্রিক ইভেন্টগুলির সাথে গঠিত ট্রেস সম্পর্কে বৈশিষ্ট্য, যা এমন ইভেন্ট যা ডেটা প্যারামিটারগুলির সাথে আবদ্ধ করে। এখানে একটি প্যারামেট্রিক বৈশিষ্ট্যের রূপ রয়েছে, যেখানে জেনেরিক (অনির্ধারিত) প্যারামেট্রিক ঘটনাগুলিকে উল্লেখ করে কিছু উপযুক্ত ফর্মালিজমে একটি নির্দিষ্টকরণ রয়েছে। এই ধরনের প্যারামেট্রিক বৈশিষ্ট্যগুলির জন্য অন্তর্দৃষ্টি হল যে দ্বারা প্রকাশিত বৈশিষ্ট্যটি অবশ্যই পর্যবেক্ষিত ট্রেসে (প্যারামেট্রিক ইভেন্টগুলির মাধ্যমে) সম্মুখীন হওয়া সমস্ত প্যারামিটার দৃষ্টান্তের জন্য ধরে রাখতে হবে। নিম্নলিখিত উদাহরণগুলির কোনওটিই কোনও নির্দিষ্ট রানটাইম যাচাইকরণ ব্যবস্থার জন্য নির্দিষ্ট নয়, যদিও পরামিতিগুলির জন্য সমর্থন অবশ্যই প্রয়োজন। নিম্নলিখিত উদাহরণগুলিতে জাভা বাক্যবিন্যাস অনুমান করা হয়, সুতরাং "= =" যৌক্তিক সমতা, এবং "=" অ্যাসাইনমেন্ট। কিছু পদ্ধতি (যেমন, আনসেফএনুমএক্সাম্পলে আপডেট ()) ডামি পদ্ধতি, যা জাভা এপিআই-এর অংশ নয়, যা স্বচ্ছতার জন্য ব্যবহৃত হয়। হ্যাশন্যাক্সট জাভা ইটারেটর ইন্টারফেসের জন্য প্রয়োজন যে হ্যাশন্যাক্সট () পদ্ধতিটি কল করা হবে এবং পরবর্তী () পদ্ধতিটি কল করার আগে সত্য ফিরে আসবে। যদি এটি না ঘটে, তবে এটি খুব সম্ভব যে কোনও ব্যবহারকারী কোনও সংগ্রহের "শেষের দিকে" পুনরাবৃত্তি করবেন। ডানদিকের চিত্রটি একটি সীমাবদ্ধ স্টেট মেশিন দেখায় যা রানটাইম যাচাইয়ের সাথে এই বৈশিষ্ট্যটি পরীক্ষা এবং প্রয়োগ করার জন্য একটি সম্ভাব্য মনিটরকে সংজ্ঞায়িত করে। অজানা অবস্থা থেকে, পরবর্তী () পদ্ধতিতে কল করা সর্বদা একটি ত্রুটি কারণ এই ধরনের অপারেশন অনিরাপদ হতে পারে। যদি নেক্সট () কল করা হয় এবং সত্য ফিরে আসে, তাহলে নেক্সট () কল করা নিরাপদ, তাই মনিটর আরও বেশি অবস্থায় প্রবেশ করে। তবে, যদি নেক্সট () পদ্ধতিটি মিথ্যা হয়, তবে আর কোনও উপাদান থাকে না এবং মনিটরটি নন অবস্থায় প্রবেশ করে। আরো এবং কোনও রাজ্যে, হ্যাজনেক্সট () পদ্ধতিতে কল করা কোনও নতুন তথ্য সরবরাহ করে না। আরও অবস্থা থেকে পরবর্তী () পদ্ধতিতে কল করা নিরাপদ, তবে আরও উপাদান বিদ্যমান থাকলে এটি অজানা হয়ে যায়, তাই মনিটর প্রাথমিক অজানা অবস্থায় পুনরায় প্রবেশ করে। পরিশেষে, নন স্টেট থেকে পরবর্তী () পদ্ধতিতে কল করার ফলে ত্রুটি অবস্থায় প্রবেশ করে। প্যারামেট্রিক পাস্ট টাইম লিনিয়ার টেম্পোরাল লজিক ব্যবহার করে এই বৈশিষ্ট্যটির একটি উপস্থাপনা নিম্নরূপ। এই সূত্রটি বলে যে পরবর্তী () পদ্ধতিতে যে কোনও কলের আগে অবশ্যই হ্যাজ নেক্সট () পদ্ধতিতে কল করতে হবে যা সত্য বলে প্রমাণিত হবে। এখানে বৈশিষ্ট্যটি ইটারেটর i-এর প্যারামেট্রিক। ধারণাগতভাবে, এর অর্থ হল যে একটি পরীক্ষা প্রোগ্রামে প্রতিটি সম্ভাব্য ইটারেটরের জন্য মনিটরের একটি অনুলিপি থাকবে, যদিও রানটাইম যাচাইকরণ ব্যবস্থাগুলির তাদের প্যারামেট্রিক মনিটরগুলি এইভাবে প্রয়োগ করার প্রয়োজন নেই। এই বৈশিষ্ট্যের জন্য মনিটরটি একটি হ্যান্ডলারকে ট্রিগার করার জন্য সেট করা হবে যখন সূত্রটি লঙ্ঘন করা হয় (সমতুল্যভাবে যখন সীমাবদ্ধ অবস্থা মেশিনটি ত্রুটি অবস্থায় প্রবেশ করে), যা তখন ঘটবে যখন পরবর্তী () প্রথমে কল না করে কল করা হয় নেক্সট (), বা যখন নেক্সট () পরবর্তী () এর আগে কল করা হয়, কিন্তু মিথ্যা ফিরে আসে। জাভাতে ভেক্টর শ্রেণীর উপাদানগুলির উপর পুনরাবৃত্তি করার জন্য দুটি উপায় রয়েছে। আগের উদাহরণে যেমন দেখা গেছে, কেউ ইটারেটর ইন্টারফেস ব্যবহার করতে পারে, অথবা কেউ গণনা ইন্টারফেস ব্যবহার করতে পারে। ইটারেটর ইন্টারফেসের জন্য একটি অপসারণ পদ্ধতি যোগ করা ছাড়াও, প্রধান পার্থক্য হল ইটারেটর "দ্রুত ব্যর্থ" হয় এবং গণনা হয় না। এর অর্থ হ 'ল যদি কেউ ভেক্টরকে পরিবর্তন করে (ইটারেটর অপসারণ পদ্ধতি ব্যবহার করা ছাড়া) যখন কেউ ইটারেটর ব্যবহার করে ভেক্টরের উপর পুনরাবৃত্তি করে, তখন একটি কনকারেন্টমডিফিকেশন এক্সসেপশন নিক্ষেপ করা হয়। যাইহোক, একটি গণনা ব্যবহার করার সময় এটি একটি ক্ষেত্রে নয়, যেমন উল্লেখ করা হয়েছে। এর ফলে একটি প্রোগ্রাম থেকে অনির্ধারিত ফলাফল আসতে পারে কারণ গণনার দৃষ্টিকোণ থেকে ভেক্টর একটি অসঙ্গতিপূর্ণ অবস্থায় থাকে। এখনও গণনা ইন্টারফেস ব্যবহার করে এমন লিগ্যাসি প্রোগ্রামগুলির জন্য, কেউ তাদের অন্তর্নিহিত ভেক্টর সংশোধন করার সময় গণনাগুলি ব্যবহার করা হয় না তা প্রয়োগ করতে চাইতে পারে। এই আচরণটি কার্যকর করার জন্য নিম্নলিখিত প্যারামেট্রিক নিয়মিত প্যাটার্নটি ব্যবহার করা যেতে পারেঃ β ভেক্টর v, গণনা e: (e = v.elements ()) (e.nextElement ()) * v.update () e.nextElement () এই প্যাটার্নটি গণনা এবং ভেক্টর উভয় ক্ষেত্রেই প্যারামেট্রিক। স্বজ্ঞাতভাবে, এবং যেহেতু উপরের রানটাইম যাচাইকরণ ব্যবস্থাগুলির এইভাবে তাদের প্যারামেট্রিক মনিটরগুলি প্রয়োগ করার প্রয়োজন নেই, তাই কেউ এই বৈশিষ্ট্যের জন্য প্যারামেট্রিক মনিটরকে ভেক্টর এবং গণনার প্রতিটি সম্ভাব্য জুটির জন্য একটি অ-প্যারামেট্রিক মনিটরের উদাহরণ তৈরি এবং অনুসরণ হিসাবে ভাবতে পারে। কিছু ইভেন্ট একই সময়ে একাধিক মনিটরের সাথে সম্পর্কিত হতে পারে, যেমন v.update (), তাই রানটাইম যাচাইকরণ ব্যবস্থাকে অবশ্যই (আবার ধারণাগতভাবে) তাদের সমস্ত আগ্রহী মনিটরের কাছে পাঠাতে হবে। এখানে বৈশিষ্ট্যটি নির্দিষ্ট করা হয়েছে যাতে এটি প্রোগ্রামের খারাপ আচরণগুলি বর্ণনা করে। এই বৈশিষ্ট্যটি, তারপর, প্যাটার্নের মিলনের জন্য পর্যবেক্ষণ করা আবশ্যক। ডানদিকের চিত্রটি জাভা কোড দেখায় যা এই প্যাটার্নের সাথে মেলে, এইভাবে সম্পত্তি লঙ্ঘন করে। ভেক্টর, ভি, গণনা, ই, তৈরি হওয়ার পরে আপডেট করা হয় এবং তারপর ই ব্যবহার করা হয়। সেফলক পূর্ববর্তী দুটি উদাহরণ সীমাবদ্ধ অবস্থার বৈশিষ্ট্য দেখায়, তবে রানটাইম যাচাইকরণে ব্যবহৃত বৈশিষ্ট্যগুলি অনেক বেশি জটিল হতে পারে। সেফলক সম্পত্তি এই নীতি প্রয়োগ করে যে একটি প্রদত্ত পদ্ধতি কলের মধ্যে একটি (পুনঃপ্রবেশকারী) লক শ্রেণীর অর্জন এবং মুক্তির সংখ্যা মিলে যায়। এটি, অবশ্যই, যে পদ্ধতিগুলি তাদের অর্জন করে সেগুলি ছাড়া অন্য পদ্ধতিতে লকগুলি মুক্ত করার অনুমতি দেয় না, তবে এটি খুব সম্ভবত পরীক্ষিত সিস্টেমের অর্জনের জন্য একটি কাঙ্ক্ষিত লক্ষ্য। নীচে একটি প্যারামেট্রিক প্রসঙ্গ-মুক্ত প্যাটার্ন ব্যবহার করে এই বৈশিষ্ট্যটির একটি নির্দিষ্টকরণ দেওয়া হয়েছেঃ থ্রেড t, লক l: S → ε। S শুরু (t) S শেষ (t)। S l.acquire (t) S l.release (t) প্যাটার্নটি প্রতিটি থ্রেড এবং লকের জন্য নেস্টেড শুরু/শেষ এবং অর্জন/মুক্তি জোড়ার সুষম ক্রম নির্দিষ্ট করে (খালি ক্রম)। এখানে শুরু এবং শেষ প্রোগ্রামের প্রতিটি পদ্ধতির শুরু এবং শেষকে বোঝায় (নিজেদের অর্জন এবং মুক্তি করার আহ্বান ব্যতীত)। এগুলি থ্রেডে প্যারামেট্রিক কারণ পদ্ধতির শুরু এবং শেষকে সংযুক্ত করা প্রয়োজন যদি এবং শুধুমাত্র যদি তারা একই থ্রেডের অন্তর্গত হয়। অ্যাকুয়ার এবং রিলিজ ইভেন্টগুলিও একই কারণে থ্রেডে প্যারামেট্রিক। এগুলি অতিরিক্তভাবে, লক-এ প্যারামেট্রিক কারণ আমরা একটি লকের রিলিজকে অন্যটির অধিগ্রহণের সাথে যুক্ত করতে চাই না। চরমভাবে, এটি সম্ভব যে থ্রেডের সাথে লকের প্রতিটি সম্ভাব্য সংমিশ্রণের জন্য সম্পত্তির একটি উদাহরণ, অর্থাৎ প্রসঙ্গ-মুক্ত পার্সিং পদ্ধতির একটি অনুলিপি থাকবে; এটি আবার স্বজ্ঞাতভাবে ঘটে, কারণ রানটাইম যাচাইকরণ সিস্টেমগুলি একই কার্যকারিতা ভিন্নভাবে প্রয়োগ করতে পারে। উদাহরণস্বরূপ, যদি কোনও সিস্টেমে থ্রেড থাকে, এবং লক সহ এবং, তাহলে জোড়াগুলির জন্য সম্পত্তি দৃষ্টান্ত বজায় রাখা সম্ভব <,>, <,>, <,>, <,>, <,>, <,>, এবং <,>। এই বৈশিষ্ট্যটি প্যাটার্নের সাথে মেলে ব্যর্থতার জন্য পর্যবেক্ষণ করা উচিত কারণ প্যাটার্নটি সঠিক আচরণ নির্দিষ্ট করে। ডানদিকের চিত্রটি একটি চিহ্ন দেখায় যা এই সম্পত্তির দুটি লঙ্ঘন ঘটায়। চিত্রের নিচের ধাপগুলি একটি পদ্ধতির সূচনার প্রতিনিধিত্ব করে, যেখানে উপরের ধাপগুলি হল শেষ। চিত্রের ধূসর তীরগুলি একই লকের প্রদত্ত অর্জন এবং মুক্তির মধ্যে মিল দেখায়। সরলতার জন্য, ট্রেস শুধুমাত্র একটি থ্রেড এবং একটি লক দেখায়। গবেষণা চ্যালেঞ্জ এবং প্রয়োগগুলি বেশিরভাগ রানটাইম যাচাইকরণ গবেষণা নীচে তালিকাভুক্ত এক বা একাধিক বিষয়কে সম্বোধন করে। রানটাইম ওভারহেড হ্রাস করা একটি এক্সিকিউটিভ সিস্টেম পর্যবেক্ষণ সাধারণত কিছু রানটাইম ওভারহেড বহন করে (হার্ডওয়্যার মনিটর একটি ব্যতিক্রম করতে পারে)। রানটাইম যাচাইকরণ সরঞ্জামগুলির ওভারহেড যতটা সম্ভব হ্রাস করা গুরুত্বপূর্ণ, বিশেষত যখন উত্পন্ন মনিটরগুলি সিস্টেমের সাথে মোতায়েন করা হয়। রানটাইম ওভারহেড হ্রাস করার কৌশলগুলির মধ্যে রয়েছেঃ উন্নত যন্ত্রপাতি। এক্সিকিউটিভ সিস্টেম থেকে ইভেন্টগুলি বের করা এবং সেগুলিকে মনিটরের কাছে পাঠানো যদি সরলভাবে করা হয় তবে একটি বড় রানটাইম ওভারহেড তৈরি করতে পারে। যে কোনও রানটাইম ভেরিফিকেশন টুলের জন্য ভাল সিস্টেম ইন্সট্রুমেন্টেশন গুরুত্বপূর্ণ, যদি না টুলটি বিদ্যমান এক্সিকিউশন লগগুলিকে স্পষ্টভাবে লক্ষ্য করে। বর্তমান ব্যবহারে অনেকগুলি যন্ত্রের পদ্ধতি রয়েছে, যার প্রত্যেকটির সুবিধা এবং অসুবিধাগুলি রয়েছে, কাস্টম বা ম্যানুয়াল যন্ত্রপাতি থেকে শুরু করে বিশেষ গ্রন্থাগার পর্যন্ত, দিক-ভিত্তিক ভাষায় সংকলন করা, ভার্চুয়াল মেশিনকে বৃদ্ধি করা, হার্ডওয়্যার সমর্থন তৈরি করা পর্যন্ত। স্থির বিশ্লেষণের সঙ্গে সংমিশ্রণ। স্ট্যাটিক এবং ডাইনামিক বিশ্লেষণের একটি সাধারণ সংমিশ্রণ, বিশেষত কম্পাইলারগুলিতে দেখা যায়, এমন সমস্ত প্রয়োজনীয়তা পর্যবেক্ষণ করা যা স্ট্যাটিকভাবে ডিসচার্জ করা যায় না। একটি দ্বৈত এবং শেষ পর্যন্ত সমতুল্য পদ্ধতি রানটাইম যাচাইয়ের ক্ষেত্রে আদর্শ হয়ে ওঠে, যথা অন্যথায় সম্পূর্ণ পর্যবেক্ষণের পরিমাণ কমাতে স্ট্যাটিক বিশ্লেষণ ব্যবহার করা। স্থির বিশ্লেষণ পর্যবেক্ষণ করার জন্য সম্পত্তির উপর এবং পর্যবেক্ষণ করার জন্য সিস্টেমের উপর উভয়ই করা যেতে পারে। পর্যবেক্ষণের জন্য সম্পত্তির স্থিতিশীল বিশ্লেষণ প্রকাশ করতে পারে যে নির্দিষ্ট কিছু ঘটনা পর্যবেক্ষণের জন্য অপ্রয়োজনীয়, নির্দিষ্ট কিছু মনিটর তৈরি করতে বিলম্ব হতে পারে এবং নির্দিষ্ট কিছু বিদ্যমান মনিটর কখনই ট্রিগার করবে না এবং এইভাবে আবর্জনা সংগ্রহ করা যেতে পারে। মনিটর করার জন্য সিস্টেমের স্ট্যাটিক বিশ্লেষণ এমন কোড সনাক্ত করতে পারে যা কখনও মনিটরকে প্রভাবিত করতে পারে না। উদাহরণস্বরূপ, উপরের হ্যাসনেক্সট বৈশিষ্ট্যটি পর্যবেক্ষণ করার সময়, কোডের যন্ত্রের অংশগুলির প্রয়োজন হয় না যেখানে প্রতিটি কল i.next () অবিলম্বে একটি কল i.hasnext () দ্বারা যে কোনও পথে আগে আসে যা সত্য (নিয়ন্ত্রণ-প্রবাহ গ্রাফে দৃশ্যমান) ফেরত দেয়। দক্ষ মনিটর জেনারেশন এবং ম্যানেজমেন্ট। উপরের উদাহরণগুলির মতো প্যারামেট্রিক বৈশিষ্ট্যগুলি পর্যবেক্ষণ করার সময়, পর্যবেক্ষণ ব্যবস্থাকে প্রতিটি প্যারামিটার দৃষ্টান্তের সাপেক্ষে পর্যবেক্ষণকৃত সম্পত্তির অবস্থার উপর নজর রাখতে হবে। এই ধরনের দৃষ্টান্তের সংখ্যা তাত্ত্বিকভাবে সীমাহীন এবং বাস্তবে প্রচুর হতে থাকে। একটি গুরুত্বপূর্ণ গবেষণা চ্যালেঞ্জ হল কীভাবে পর্যবেক্ষিত ঘটনাগুলিকে সঠিকভাবে সেই উদাহরণগুলিতে প্রেরণ করা যায় যার তাদের প্রয়োজন। একটি সম্পর্কিত চ্যালেঞ্জ হল কিভাবে এই ধরনের দৃষ্টান্তের সংখ্যা কম রাখা যায় (যাতে প্রেরণ দ্রুত হয়), অথবা অন্য কথায়, কিভাবে যতদিন সম্ভব অপ্রয়োজনীয় দৃষ্টান্ত তৈরি করা এড়ানো যায় এবং দ্বৈতভাবে, কিভাবে ইতিমধ্যে তৈরি দৃষ্টান্তগুলি অপ্রয়োজনীয় হয়ে যাওয়ার সাথে সাথে অপসারণ করা যায়। পরিশেষে, প্যারামেট্রিক মনিটরিং অ্যালগরিদমগুলি সাধারণত অ-প্যারামেট্রিক মনিটর তৈরির জন্য অনুরূপ অ্যালগরিদমগুলিকে সাধারণীকরণ করে। সুতরাং, উৎপাদিত অ-প্যারামেট্রিক মনিটরের গুণমান ফলস্বরূপ প্যারামেট্রিক মনিটরের গুণমান নির্ধারণ করে। যাইহোক, অন্যান্য যাচাইকরণ পদ্ধতির (যেমন, মডেল চেকিং) বিপরীতে, রানটাইম যাচাইকরণে অবস্থার সংখ্যা বা উত্পন্ন মনিটরের আকার কম গুরুত্বপূর্ণ; প্রকৃতপক্ষে, কিছু মনিটরের অসীম সংখ্যক অবস্থা থাকতে পারে, যেমন উপরের সেফলক সম্পত্তির জন্য, যদিও যে কোনও সময়ে শুধুমাত্র সীমিত সংখ্যক অবস্থা ঘটতে পারে। যা গুরুত্বপূর্ণ তা হল মনিটরটি একটি রাজ্য থেকে তার পরবর্তী অবস্থায় কতটা দক্ষতার সাথে স্থানান্তরিত হয় যখন এটি এক্সিকিউটিভ সিস্টেম থেকে একটি ইভেন্ট গ্রহণ করে। বৈশিষ্ট্য নির্দিষ্ট করা সমস্ত আনুষ্ঠানিক পদ্ধতির একটি প্রধান ব্যবহারিক বাধা হল যে তাদের ব্যবহারকারীরা নির্দিষ্টকরণ পড়তে বা লিখতে অনিচ্ছুক, বা জানেন না এবং শিখতে চান না। কিছু ক্ষেত্রে নির্দিষ্টকরণগুলি অন্তর্নিহিত, যেমন ডেডলক এবং ডেটা-রেসের জন্য, তবে বেশিরভাগ ক্ষেত্রে সেগুলি তৈরি করা প্রয়োজন। একটি অতিরিক্ত অসুবিধা, বিশেষত রানটাইম যাচাইয়ের প্রসঙ্গে, অনেক বিদ্যমান নির্দিষ্টকরণের ভাষাগুলি কাঙ্ক্ষিত বৈশিষ্ট্যগুলি ক্যাপচার করার জন্য যথেষ্ট অভিব্যক্তিপূর্ণ নয়। আরও ভালো আনুষ্ঠানিকতা। রানটাইম ভেরিফিকেশন কমিউনিটিতে উল্লেখযোগ্য পরিমাণে কাজ করা হয়েছে নির্দিষ্টকরণের আনুষ্ঠানিকতার নকশায় যা প্রচলিত নির্দিষ্টকরণের আনুষ্ঠানিকতার চেয়ে রানটাইম যাচাইয়ের জন্য পছন্দসই অ্যাপ্লিকেশন ডোমেনের সাথে মানানসই। এর মধ্যে কয়েকটি প্রচলিত আনুষ্ঠানিকতায় সামান্য বা কোনও বাক্যবিন্যাসগত পরিবর্তন নিয়ে গঠিত, তবে কেবল তাদের শব্দার্থবিজ্ঞানের পরিবর্তন (যেমন, সীমাবদ্ধ ট্রেস বনাম অসীম ট্রেস শব্দার্থবিজ্ঞান ইত্যাদি)। এবং তাদের বাস্তবায়নের জন্য (বুচি অটোমাটার পরিবর্তে অপ্টিমাইজড ফাইনাইট স্টেট মেশিন ইত্যাদি)। অন্যরা বিদ্যমান আনুষ্ঠানিকতাগুলিকে এমন বৈশিষ্ট্যগুলির সাথে প্রসারিত করে যা রানটাইম যাচাইয়ের জন্য উপযুক্ত তবে অন্যান্য যাচাইকরণ পদ্ধতির জন্য সহজেই নাও হতে পারে, যেমন প্যারামিটার যুক্ত করা, যেমন উপরের উদাহরণগুলিতে দেখা গেছে। পরিশেষে, নির্দিষ্টকরণের আনুষ্ঠানিকতা রয়েছে যা বিশেষভাবে রানটাইম যাচাইয়ের জন্য ডিজাইন করা হয়েছে, এই ডোমেনের জন্য তাদের সেরা অর্জন করার চেষ্টা করা হয়েছে এবং অন্যান্য অ্যাপ্লিকেশন ডোমেন সম্পর্কে খুব কম যত্ন নেওয়া হয়েছে। রানটাইম যাচাইয়ের জন্য সর্বজনীনভাবে আরও ভাল বা ডোমেন-বিশেষত আরও ভাল নির্দিষ্টকরণের আনুষ্ঠানিকতা ডিজাইন করা এর অন্যতম প্রধান গবেষণা চ্যালেঞ্জ এবং তা অব্যাহত থাকবে। পরিমাণগত বৈশিষ্ট্য। অন্যান্য যাচাইকরণ পদ্ধতির তুলনায়, রানটাইম যাচাইকরণ সিস্টেম স্টেট ভেরিয়েবলের সুনির্দিষ্ট মানগুলিতে কাজ করতে সক্ষম, যা প্রোগ্রামের কার্যকারিতা সম্পর্কে পরিসংখ্যানগত তথ্য সংগ্রহ করা এবং জটিল পরিমাণগত বৈশিষ্ট্যগুলি মূল্যায়নের জন্য এই তথ্যটি ব্যবহার করা সম্ভব করে তোলে। এই ক্ষমতাকে পুরোপুরি কাজে লাগানোর সুযোগ করে দেবে এমন আরও অভিব্যক্তিপূর্ণ ভাষার প্রয়োজন রয়েছে। আরও ভালো ইন্টারফেস। অ-বিশেষজ্ঞদের জন্য সম্পত্তির নির্দিষ্টকরণ পড়া এবং লেখা সহজ নয়। এমনকি বিশেষজ্ঞরাও প্রায়শই কয়েক মিনিটের জন্য তুলনামূলকভাবে ছোট সাময়িক যুক্তি সূত্রের দিকে তাকান (বিশেষত যখন তারা "পর্যন্ত" অপারেটরদের নেস্ট করে)। একটি গুরুত্বপূর্ণ গবেষণার ক্ষেত্র হল বিভিন্ন নির্দিষ্টকরণের আনুষ্ঠানিকতার জন্য শক্তিশালী ব্যবহারকারী ইন্টারফেসগুলি বিকাশ করা যা ব্যবহারকারীদের আরও সহজে বুঝতে, লিখতে এবং এমনকি বৈশিষ্ট্যগুলি কল্পনা করার অনুমতি দেবে। খনির নির্দিষ্টকরণ। ব্যবহারকারীদের নির্দিষ্টকরণ তৈরি করতে সাহায্য করার জন্য যে কোনও সরঞ্জাম সমর্থন উপলব্ধ থাকুক না কেন, তারা প্রায় সবসময়ই কোনও নির্দিষ্টকরণ লিখতে না পেরে খুশি হবে, বিশেষত যখন তারা তুচ্ছ হয়। সৌভাগ্যবশত, এমন প্রচুর প্রোগ্রাম রয়েছে যা ক্রিয়া/ইভেন্টগুলির সঠিক ব্যবহার করে যা সম্পর্কে কেউ বৈশিষ্ট্য রাখতে চায়। যদি তাই হয়, তাহলে এটা কল্পনা করা যেতে পারে যে কেউ সেই সঠিক প্রোগ্রামগুলি থেকে স্বয়ংক্রিয়ভাবে কাঙ্ক্ষিত বৈশিষ্ট্যগুলি শিখতে চাইবে। এমনকি যদি স্বয়ংক্রিয়ভাবে খনন করা নির্দিষ্টকরণগুলির সামগ্রিক গুণমান ম্যানুয়ালি উত্পাদিত নির্দিষ্টকরণগুলির তুলনায় কম বলে আশা করা হয়, তবে তারা পরেরটির জন্য একটি সূচনা বিন্দু হিসাবে বা স্বয়ংক্রিয় রানটাইম যাচাইকরণ সরঞ্জামগুলির ভিত্তি হিসাবে কাজ করতে পারে যা বিশেষত বাগগুলি খুঁজে বের করার লক্ষ্যে (যেখানে একটি দুর্বল নির্দিষ্টকরণ ভুল ইতিবাচক বা নেতিবাচক হয়ে যায়, যা প্রায়শই পরীক্ষার সময় গ্রহণযোগ্য)। এক্সিকিউশন মডেল এবং ভবিষ্যদ্বাণীমূলক বিশ্লেষণ একটি রানটাইম ভেরিফায়ারের ত্রুটি সনাক্ত করার ক্ষমতা কঠোরভাবে এক্সিকিউশন ট্রেস বিশ্লেষণ করার ক্ষমতার উপর নির্ভর করে। যখন মনিটরগুলি সিস্টেমের সাথে মোতায়েন করা হয়, তখন যন্ত্রপাতি সাধারণত ন্যূনতম হয় এবং রানটাইম ওভারহেড কম রাখার জন্য এক্সিকিউশন ট্রেসগুলি যতটা সম্ভব সহজ হয়। যখন পরীক্ষার জন্য রানটাইম যাচাইকরণ ব্যবহার করা হয়, তখন কেউ আরও ব্যাপক যন্ত্রপাতি বহন করতে পারে যা গুরুত্বপূর্ণ সিস্টেম তথ্যের সাথে ইভেন্টগুলিকে বাড়িয়ে তোলে যা মনিটর দ্বারা এক্সিকিউটিভ সিস্টেমের আরও পরিমার্জিত মডেলগুলি তৈরি করতে এবং বিশ্লেষণ করতে ব্যবহার করা যেতে পারে। উদাহরণস্বরূপ, ভেক্টর ঘড়ির তথ্যের সাথে এবং তথ্য এবং নিয়ন্ত্রণ প্রবাহের তথ্যের সাথে ইভেন্টগুলি বাড়ানোর ফলে মনিটরগুলি চলমান সিস্টেমের একটি কার্যকারণ মডেল তৈরি করতে পারে যেখানে পর্যবেক্ষিত এক্সিকিউশন শুধুমাত্র একটি সম্ভাব্য উদাহরণ ছিল। মডেলের সাথে সামঞ্জস্যপূর্ণ ঘটনাগুলির অন্য যে কোনও ক্রমাঙ্কন সিস্টেমের একটি সম্ভাব্য সম্পাদন, যা একটি ভিন্ন থ্রেড ইন্টারলিভিংয়ের অধীনে ঘটতে পারে। এই ধরনের অনুমিত মৃত্যুদণ্ডগুলিতে সম্পত্তি লঙ্ঘন সনাক্ত করা (তাদের পর্যবেক্ষণ করে) মনিটরকে এমন ত্রুটিগুলির পূর্বাভাস দেয় যা পর্যবেক্ষিত সম্পাদনে ঘটেনি, তবে একই সিস্টেমের অন্য সম্পাদনে যা ঘটতে পারে। একটি গুরুত্বপূর্ণ গবেষণা চ্যালেঞ্জ হল এক্সিকিউশন ট্রেস থেকে মডেলগুলি বের করা যা যতটা সম্ভব অন্যান্য এক্সিকিউশন ট্রেস নিয়ে গঠিত। আচরণ পরিবর্তন পরীক্ষা বা সম্পূর্ণ যাচাইকরণের বিপরীতে, রানটাইম যাচাইকরণ সিস্টেমটিকে সনাক্ত করা লঙ্ঘন থেকে পুনরুদ্ধারের প্রতিশ্রুতি দেয়, পুনর্গঠন, মাইক্রো-রিসেট বা সূক্ষ্ম হস্তক্ষেপ ব্যবস্থার মাধ্যমে যা কখনও কখনও টিউনিং বা স্টিয়ারিং হিসাবে উল্লেখ করা হয়। রানটাইম যাচাইয়ের কঠোর কাঠামোর মধ্যে এই কৌশলগুলির বাস্তবায়ন অতিরিক্ত চ্যালেঞ্জের জন্ম দেয়। ক্রিয়াগুলির নির্দিষ্টকরণ। একটি বিমূর্ত যথেষ্ট ফ্যাশনে সম্পাদিত হওয়ার জন্য পরিবর্তনটি নির্দিষ্ট করতে হবে যার জন্য ব্যবহারকারীকে অপ্রাসঙ্গিক বাস্তবায়নের বিবরণ জানতে হবে না। উপরন্তু, সিস্টেমের অখণ্ডতা বজায় রাখার জন্য এই ধরনের পরিবর্তন কখন হতে পারে তা নির্দিষ্ট করা প্রয়োজন। হস্তক্ষেপের প্রভাব সম্পর্কে যুক্তি। এটা জানা গুরুত্বপূর্ণ যে একটি হস্তক্ষেপ পরিস্থিতির উন্নতি করে, অথবা অন্তত পরিস্থিতি আরও খারাপ করে না। অ্যাকশন ইন্টারফেস। পর্যবেক্ষণের জন্য যন্ত্রের মতো, আমাদের ব্যবস্থাটিকে কর্মের আহ্বান গ্রহণ করতে সক্ষম করতে হবে। আহ্বান প্রক্রিয়া অবশ্যই সিস্টেমের বাস্তবায়নের বিবরণের উপর নির্ভরশীল হতে চলেছে। যাইহোক, নির্দিষ্টকরণ স্তরে, আমাদের ব্যবহারকারীকে কোন শর্তে কোন ক্রিয়া প্রয়োগ করা উচিত তা নির্দিষ্ট করে সিস্টেমে প্রতিক্রিয়া প্রদানের একটি ঘোষণামূলক উপায় প্রদান করতে হবে। সংশ্লিষ্ট কাজ এস্পেক্ট-ওরিয়েন্টেড প্রোগ্রামিং রানটাইম ভেরিফিকেশনের গবেষকরা এস্পেক্ট-ওরিয়েন্টেড প্রোগ্রামিংকে মডুলার উপায়ে প্রোগ্রাম ইন্সট্রুমেন্টেশন সংজ্ঞায়িত করার কৌশল হিসাবে ব্যবহারের সম্ভাবনাকে স্বীকৃতি দিয়েছেন। এস্পেক্ট-ওরিয়েন্টেড প্রোগ্রামিং (এওপি) সাধারণত ক্রসকাটিং উদ্বেগের মডুলারাইজেশনকে উৎসাহিত করে। রানটাইম ভেরিফিকেশন স্বাভাবিকভাবেই এমনই একটি উদ্বেগের বিষয় এবং তাই এওপি-র কিছু বৈশিষ্ট্য থেকে উপকৃত হতে পারে। এস্পেক্ট-ওরিয়েন্টেড মনিটরের সংজ্ঞাগুলি মূলত ঘোষণাত্মক, এবং তাই একটি অপরিহার্য প্রোগ্রামিং ভাষায় লিখিত প্রোগ্রাম রূপান্তরের মাধ্যমে প্রকাশিত যন্ত্রের চেয়ে যুক্তি করা সহজ। উপরন্তু, স্থির বিশ্লেষণগুলি অন্যান্য ধরনের প্রোগ্রাম যন্ত্রের তুলনায় পর্যবেক্ষণের দিকগুলি সম্পর্কে আরও সহজে যুক্তি দিতে পারে, কারণ সমস্ত যন্ত্র একটি একক দিকের মধ্যে রয়েছে। অনেক বর্তমান রানটাইম যাচাইকরণ সরঞ্জাম তাই নির্দিষ্টকরণ সংকলকের আকারে নির্মিত হয়, যা ইনপুট হিসাবে একটি অভিব্যক্তিপূর্ণ উচ্চ-স্তরের নির্দিষ্টকরণ গ্রহণ করে এবং কিছু দিক-ভিত্তিক প্রোগ্রামিং ভাষায় (যেমন অ্যাস্পেক্টজে) লিখিত আউটপুট কোড হিসাবে তৈরি করে। আনুষ্ঠানিক যাচাইকরণের সাথে রানটাইম যাচাইকরণের সংমিশ্রণ, যদি প্রমাণযোগ্যভাবে সঠিক পুনরুদ্ধার কোডের সাথে সংমিশ্রণে ব্যবহার করা হয়, তবে প্রোগ্রাম যাচাইয়ের জন্য একটি অমূল্য পরিকাঠামো সরবরাহ করতে পারে, যা পরেরটির জটিলতা উল্লেখযোগ্যভাবে হ্রাস করতে পারে। উদাহরণস্বরূপ, আনুষ্ঠানিকভাবে হিপ-সাজানো অ্যালগরিদম যাচাই করা খুব চ্যালেঞ্জিং। এটি যাচাই করার জন্য একটি কম চ্যালেঞ্জিং কৌশল হল এর আউটপুটকে সাজানোর জন্য পর্যবেক্ষণ করা (একটি রৈখিক জটিলতা মনিটর) এবং যদি সাজানো না হয়, তবে কিছু সহজে যাচাইযোগ্য পদ্ধতি ব্যবহার করে এটি সাজানো, যেমন সন্নিবেশ সাজানো। ফলস্বরূপ বাছাই প্রোগ্রামটি এখন আরও সহজে যাচাইযোগ্য, হিপ-টাইপ থেকে কেবলমাত্র যে জিনিসটি প্রয়োজন তা হল এটি মাল্টিসেট হিসাবে বিবেচিত মূল উপাদানগুলিকে ধ্বংস করে না, যা প্রমাণ করা অনেক সহজ। অন্য দিক থেকে দেখলে, রানটাইম যাচাইকরণের ওভারহেড কমাতে আনুষ্ঠানিক যাচাইকরণ ব্যবহার করা যেতে পারে, যেমনটি আনুষ্ঠানিক যাচাইকরণের পরিবর্তে স্ট্যাটিক বিশ্লেষণের জন্য ইতিমধ্যে উপরে উল্লেখ করা হয়েছে। প্রকৃতপক্ষে, কেউ একটি সম্পূর্ণ রানটাইম যাচাইকৃত, কিন্তু সম্ভবত ধীর প্রোগ্রাম দিয়ে শুরু করতে পারে। তারপরে কেউ ডিসচার্জ মনিটরের জন্য আনুষ্ঠানিক যাচাইকরণ (বা স্ট্যাটিক বিশ্লেষণ) ব্যবহার করতে পারে, একইভাবে একটি সংকলক টাইপ সঠিকতা বা মেমরি সুরক্ষার রানটাইম চেকগুলি স্রাব করতে স্ট্যাটিক বিশ্লেষণ ব্যবহার করে। আরও ঐতিহ্যবাহী যাচাইকরণ পদ্ধতির তুলনায় কভারেজ বৃদ্ধি, রানটাইম যাচাইকরণের একটি তাৎক্ষণিক অসুবিধা হল এর কভারেজ হ্রাস। যখন রানটাইম মনিটরগুলি সিস্টেমের সাথে মোতায়েন করা হয় তখন এটি সমস্যাযুক্ত হয় না (সম্পত্তি লঙ্ঘিত হলে যথাযথ পুনরুদ্ধার কোডের সাথে একসাথে কার্যকর করা হয়), তবে সিস্টেমে ত্রুটিগুলি খুঁজে পেতে ব্যবহার করা হলে এটি রানটাইম যাচাইয়ের কার্যকারিতা সীমাবদ্ধ করতে পারে। ত্রুটি সনাক্তকরণের উদ্দেশ্যে রানটাইম যাচাইকরণের কভারেজ বাড়ানোর কৌশলগুলির মধ্যে রয়েছেঃ ইনপুট জেনারেশন। এটি সুপরিচিত যে ইনপুটগুলির একটি ভাল সেট তৈরি করা (প্রোগ্রাম ইনপুট পরিবর্তনশীল মান, সিস্টেম কল মান, থ্রেড সময়সূচী ইত্যাদি)। পরীক্ষার কার্যকারিতা ব্যাপকভাবে বৃদ্ধি করতে পারে। এটি ত্রুটি সনাক্তকরণের জন্য ব্যবহৃত রানটাইম যাচাইকরণের ক্ষেত্রেও প্রযোজ্য, তবে ইনপুট জেনারেশন প্রক্রিয়া চালানোর জন্য প্রোগ্রাম কোড ব্যবহার করার পাশাপাশি, রানটাইম যাচাইকরণে কেউ যখন পাওয়া যায় তখন সম্পত্তি নির্দিষ্টকরণগুলিও ব্যবহার করতে পারে এবং পর্যবেক্ষণ কৌশলগুলিও ব্যবহার করতে পারে পছন্দসই আচরণগুলি প্ররোচিত করতে। রানটাইম যাচাইকরণের এই ব্যবহার এটিকে মডেল-ভিত্তিক পরীক্ষার সাথে ঘনিষ্ঠভাবে সম্পর্কিত করে তোলে, যদিও রানটাইম যাচাইকরণ নির্দিষ্টকরণগুলি সাধারণত সাধারণ উদ্দেশ্যে হয়, পরীক্ষার কারণে অপরিহার্যভাবে তৈরি করা হয় না। উদাহরণস্বরূপ, বিবেচনা করুন যে কেউ উপরের সাধারণ-উদ্দেশ্যের আনসেফএনুম বৈশিষ্ট্যটি পরীক্ষা করতে চায়। সিস্টেমের কার্যকারিতা নিষ্ক্রিয়ভাবে পর্যবেক্ষণ করার জন্য কেবল উপরে উল্লিখিত মনিটর তৈরি করার পরিবর্তে, কেউ একটি স্মার্ট মনিটর তৈরি করতে পারে যা দ্বিতীয় e.nextElement () ইভেন্ট তৈরি করার চেষ্টা করা থ্রেডটিকে হিমশীতল করে দেয় (এটি তৈরি করার ঠিক আগে), অন্য থ্রেডগুলিকে এই আশায় কার্যকর করতে দেয় যে তাদের মধ্যে একটি v.update () ইভেন্ট তৈরি করতে পারে, যে ক্ষেত্রে একটি ত্রুটি পাওয়া গেছে। গতিশীল প্রতীকী কার্যকরকরণ। প্রতীকী কার্যকরকরণ প্রোগ্রামগুলি প্রতীকীভাবে কার্যকর করা হয় এবং পর্যবেক্ষণ করা হয়, অর্থাৎ, সুনির্দিষ্ট ইনপুট ছাড়াই। সিস্টেমের একটি প্রতীকী এক্সিকিউশন কংক্রিট ইনপুটগুলির একটি বড় সেটকে অন্তর্ভুক্ত করতে পারে। অফ-দ্য-শেল্ফ সীমাবদ্ধতা সমাধান বা সন্তোষজনকতা পরীক্ষা করার কৌশলগুলি প্রায়শই প্রতীকী মৃত্যুদন্ড কার্যকর করতে বা পদ্ধতিগতভাবে তাদের স্থান অন্বেষণ করতে ব্যবহৃত হয়। যখন অন্তর্নিহিত সন্তোষজনক চেকাররা একটি পছন্দের পয়েন্ট পরিচালনা করতে পারে না, তখন সেই পয়েন্টটি পাস করার জন্য একটি কংক্রিট ইনপুট তৈরি করা যেতে পারে; কংক্রিট এবং প্রতীকী সম্পাদনের এই সংমিশ্রণটিকে কনকোলিক এক্সিকিউশন হিসাবেও উল্লেখ করা হয়। আরও দেখুন গতিশীল প্রোগ্রাম বিশ্লেষণ প্রোফাইলিং (কম্পিউটার প্রোগ্রামিং) রানটাইম ত্রুটি সনাক্তকরণ রানটাইম অ্যাপ্লিকেশন স্ব-সুরক্ষা (আরএএসপি) রেফারেন্স আনুষ্ঠানিক পদ্ধতি কম্পিউটার বিজ্ঞানে যুক্তি