প্রোগ্রামের সঠিকতা, স্পেসিফিকেশন

Question

উইকিপিডিয়া থেকে: তাত্ত্বিক কম্পিউটার বিজ্ঞানে একটি অ্যালগরিদমের সংক্ষিপ্ততা জোর দেওয়া হয় যখন বলা হয় যে কোনও স্পেসিফিকেশনের ক্ষেত্রে আলগোরিদিম সঠিক।

তবে সমস্যাটি হ'ল "যথাযথ" স্পেসিফিকেশন পাওয়া তুচ্ছ কাজ নয়, এবং সঠিকটি পাওয়ার জন্য 100% সঠিক পদ্ধতি নেই (যতদূর আমি জানি) সঠিক এটি পাওয়া যায়, এটি কেবলমাত্র একটি অনুমান, তাই যদি আমরা যাচ্ছি একটি স্পেসিফিকেশন হিসাবে একটি প্রাকদর্শন হিসাবে এটি "এক" মত "দেখাচ্ছে" ঠিক আছে, কেন প্রোগ্রামটিকে ঠিক "দেখায়" সঠিক বলে গ্রহণ করা হচ্ছে না?

Comments

কারণ আশা করি স্পেসিফিকেশনটি প্রোগ্রামের চেয়ে কম জটিল তাই প্রোগ্রামের চেয়ে এতে কম ভুল হবে।

— ব্যবহারকারী 253751

নোট করুন যে একটি টাইপ সিস্টেম হ'ল এক ধরণের স্পেসিফিকেশন - আমরা প্রোগ্রামগুলির কিছু অ-তুচ্ছ বৈশিষ্ট্য প্রমাণ করতে এটি ব্যবহার করতে পারি। প্রকারের ধরণের সিস্টেমটি যত বেশি সমৃদ্ধ, আমরা প্রমাণ করতে সক্ষম গুণাবলী।

— বাগান প্রধান

@ মিমিবিস তবে এতে যদি একটি মাত্র ভুল হয় তবে পুরো জিনিসটি ভুল

— মাইকেল জ্যাকসন

@ মাইকেল জ্যাকসন ট্রু ... আমি একবার ভুল করে রডিনের একটি অ্যালিকোমে একটি বৈপরীত্য রেখেছি (আমি যা করার চেষ্টা করছিলাম তা সঠিক ছিল তবে বাক্য গঠনটি ভুল ছিল)। আমার নজরে আসার আগে "hmm অটো-প্রভারটি এখন অস্বাভাবিকভাবে ভালভাবে কাজ করছে বলে মনে হয়েছে" এর জন্য আমাকে কিছুটা সময় লেগেছিল।

— ব্যবহারকারী 253751

Answer 1

প্রথমত, আপনি একেবারে ঠিক: আপনি একটি সত্য উদ্বেগ উপর। আনুষ্ঠানিক যাচাইকরণ প্রোগ্রামের নির্ভুলতার মধ্যে আস্থার সমস্যাটিকে নির্দিষ্টকরণের নির্ভুলতার মধ্যে আস্থার সমস্যাটিতে স্থানান্তর করে, তাই এটি কোনও রূপালী বুলেট নয়।

যদিও এই প্রক্রিয়াটি এখনও কার্যকর হতে পারে তার বেশ কয়েকটি কারণ রয়েছে।

1. কোডগুলি নিজের চেয়ে স্পেসিফিকেশনগুলি প্রায়শই সহজ। উদাহরণস্বরূপ, পূর্ণসংখ্যার অ্যারের বাছাইয়ের সমস্যাটি বিবেচনা করুন। পারফরম্যান্সের উন্নতি করার জন্য মোটামুটি পরিশীলিত বাছাই করা অ্যালগরিদম রয়েছে যা চালাক জিনিস করে। তবে স্পেসিফিকেশনটি বলতে মোটামুটি সহজ: আউটপুট অবশ্যই ক্রমবর্ধমান ক্রমে হওয়া উচিত এবং অবশ্যই ইনপুটটির ক্রমবিন্যাস হতে হবে। সুতরাং কোডের যথার্থতার চেয়ে স্পষ্টতার যথাযথতার উপর আস্থা অর্জন করা তর্কযোগ্যভাবে সহজ is

2. ব্যর্থতার কোনও একক পয়েন্ট নেই। ধরুন আপনার কাছে একজন ব্যক্তি একটি স্পেসিফিকেশন লিখেছেন এবং অন্য কোনও ব্যক্তি উত্স কোডটি লিখেছেন এবং তারপরে আনুষ্ঠানিকভাবে যাচাই করুন যে কোডটি অনুমান করে। তারপরে কোনও অনির্দিষ্ট ত্রুটিযুক্ত বৈশিষ্ট্য এবং কোড উভয়ই উপস্থিত থাকতে হবে । কিছু কিছু ক্ষেত্রে, সংক্রান্ত ত্রুটিগুলি কিছু ধরনের, সম্ভাবনা কম এই মতানুযায়ী জন্য: এটা সম্ভাবনা কম যে আপনার খুঁত যখন বৈশিষ্ট পরিদর্শন উপেক্ষা চাই এবং ত্রুটি উপেক্ষা যখন সোর্স কোড পরিদর্শন। সব না, কিছু।

3. আংশিক চশমা কোডের চেয়ে বিস্তৃত সহজ হতে পারে। উদাহরণস্বরূপ, প্রয়োজনীয়তাটি বিবেচনা করুন যে প্রোগ্রামটি বাফার ওভাররন দুর্বলতাগুলি থেকে মুক্ত। বা, প্রয়োজনীয়তা হ'ল কোনও অ্যারে সূচক বাইরে-সীমার ত্রুটি নেই। এটি একটি সাধারণ অনুমান যা প্রমাণ করতে সক্ষম হবার জন্য অবশ্যই একটি ভাল এবং দরকারী জিনিস useful পুরো প্রোগ্রামটি এই অনুকূলে মেলে তা প্রমাণ করার জন্য এখন আপনি আনুষ্ঠানিক পদ্ধতিগুলি ব্যবহার করার চেষ্টা করতে পারেন। এটি মোটামুটিভাবে জড়িত কোনও কাজ হতে পারে তবে আপনি যদি সফল হন তবে আপনি প্রোগ্রামটির প্রতি আস্থা বাড়িয়ে তুলবেন।

4. কোডের তুলনায় স্পেস কম ঘন ঘন পরিবর্তন হতে পারে। আনুষ্ঠানিক পদ্ধতি ছাড়াই, প্রতিবার উত্স কোডটি আপডেট করার সময়, আমাদের ম্যানুয়ালি পরীক্ষা করে দেখতে হবে যে আপডেটটি কোনও ত্রুটি বা ত্রুটিগুলি প্রবর্তন করবে না। আনুষ্ঠানিক পদ্ধতিগুলি এই বোঝাটি কমিয়ে আনতে পারে: ধরুন অনুমানটি পরিবর্তিত হয় না, যাতে সফ্টওয়্যার আপডেটগুলি কেবল কোডে পরিবর্তনগুলি জড়িত করে এবং অনুমিত পরিবর্তন না করে। তারপরে প্রতিটি আপডেটের জন্য, অনুমানটি এখনও ঠিক আছে কিনা তা পরীক্ষা করার জন্য আপনি বোঝা থেকে মুক্তি পেয়েছেন (এটি পরিবর্তন হয়নি, সুতরাং চশমাটিতে কোনও নতুন বাগ প্রবর্তিত হয়নি) এবং কোডটি এখনও রয়েছে কিনা তা পরীক্ষা করে দেখুন সঠিক (প্রোগ্রাম যাচাইকারী আপনার জন্য এটি পরীক্ষা করে)। আপনার এখনও মূল পরীক্ষাটি সঠিক কিনা তা যাচাই করা দরকার তবে প্রতিবার কোনও বিকাশকারী কোনও নতুন প্যাচ / আপডেট / পরিবর্তন করার সময় আপনাকে এটি পরীক্ষা করে দেখার দরকার নেই।

শেষ অবধি, মনে রাখবেন যে চশমা সাধারণত ঘোষিত হয় এবং অগত্যা কার্যকর করা যায় না বা সরাসরি কোডে সংকলিত হতে পারে না। উদাহরণস্বরূপ, আবার বাছাইয়ের বিষয়টি বিবেচনা করুন: অনুমানটি বলছে যে আউটপুট বৃদ্ধি পাচ্ছে এবং ইনপুটটির ক্রমবিন্যাস, তবে এই স্পেসটিকে সরাসরি "সম্পাদন" করার কোনও সুস্পষ্ট উপায় নেই এবং কোনও সংকলক স্বয়ংক্রিয়ভাবে কোডটিতে এটি সংকলিত করার কোনও সুস্পষ্ট উপায় নেই। তাই কেবলমাত্র অনুমিতটিকে সঠিক হিসাবে গ্রহণ করা এবং প্রায়শই এটি সম্পাদন করা কোনও বিকল্প নয়।

যাইহোক, নীচের লাইনটি একই থাকে: আনুষ্ঠানিক পদ্ধতিগুলি কোনও প্যানিসিয়া নয়। কোড স্পষ্টতার সাথে আত্মবিশ্বাসের (খুব শক্ত) সমস্যাটিকে তারা স্পষ্টতই নির্ভুলতার আস্থার (কেবলমাত্র কঠিন) আত্মবিশ্বাসের সমস্যায় স্থানান্তর করে। বৈশিষ্টগুলিতে থাকা বাগগুলি সত্যিকারের ঝুঁকি, এগুলি সাধারণ এবং এগুলি উপেক্ষা করা যায় না। প্রকৃতপক্ষে, আনুষ্ঠানিক পদ্ধতিগুলি সম্প্রদায় কখনও কখনও সমস্যাটিকে দুটি টুকরো করে পৃথক করে: যাচাইকরণ কোডটি নির্দিষ্টভাবে পূরণ করে তা নিশ্চিত করার বিষয়ে; বৈধকরণটি অনুমানটি সঠিক (আমাদের প্রয়োজন মেটাচ্ছে) তা নিশ্চিত করার বিষয়ে।

আপনি অনুশীলনে আনুষ্ঠানিক প্রোগ্রাম যাচাইকরণ উপভোগ করতে পারেন এবং আমরা কেন সময় গ্যারান্টি সংকলনের দিকে আরও গবেষণা করছি না? এটি সম্পর্কে কিছু ধারন করার সাথে আরও দৃষ্টিভঙ্গির জন্য।

Comments

একটি সরু হিসাবে, একটি অনুমান আরও বিস্তারিত হয়ে ওঠে, সম্ভবত এটি সিউডোকোড বৃদ্ধি হিসাবে লেখা যেতে পারে। আপনার বাছাইয়ের উদাহরণটি ব্যবহার করে, "আউটপুট অবশ্যই ক্রমবর্ধমান ক্রমে হতে হবে" এর আরও বিশদ সংস্করণ হবে "আউটপুটটির প্রতিটি পূর্ণসংখ্যার প্রথমটির পরে অবশ্যই পূর্ববর্তী সংখ্যার চেয়ে বড় হতে হবে"। এগুলি পরিবর্তে সহজেই for each integer I_N in set S (where N > 1) { assert I_N > I_N - 1 এর মতো কিছু হিসাবে লেখা যেতে পারে }। স্বরলিপি সম্পর্কে 100% নিশ্চিত নয়।

— জাস্টিন সময় - মনিকা

সুতরাং, একটি ভাল অনুমান কেবল কোডটি তৈরি করতে সহায়তা করতে পারে, এটি কেবল যাচাই করা নয়।

— জাস্টিন সময় - মনিকা

বাছাইকরণ বৈশিষ্টটি কার্যকর করার সুস্পষ্ট উপায় হ'ল ইনপুটটির সমস্ত ক্রমশক্তি গণনা করা এবং আদেশযুক্তটিকে বাছাই করা। সঙ্গে সমস্যা এই , যদিও, স্পষ্ট হওয়া উচিত ...

— ডেরেক Elkins দঃপূঃ বাম

Answer 2

ডিডাব্লু এর উত্তর দুর্দান্ত , তবে আমি একটি পয়েন্টে প্রসারিত করতে চাই। একটি স্পেসিফিকেশন কেবল একটি রেফারেন্স নয় যার বিরুদ্ধে কোড যাচাই করা হয়। আনুষ্ঠানিক নির্দিষ্টকরণের অন্যতম কারণ হ'ল কিছু মৌলিক বৈশিষ্ট্য প্রমাণ করে এটি যাচাই করা। অবশ্যই, স্পেসিফিকেশন সম্পূর্ণরূপে যাচাই করা যায় না - বৈধকরণটি স্পেসিফিকেশনের মতোই জটিল হবে, সুতরাং এটি একটি অন্তহীন প্রক্রিয়া হবে। তবে বৈধতা কিছু সমালোচিত বৈশিষ্ট্যের উপর আমাদের আরও শক্তিশালী গ্যারান্টি পেতে দেয়।

উদাহরণস্বরূপ, ধরুন আপনি একটি গাড়ী অটোপাইলট ডিজাইন করছেন। এটি অনেকগুলি পরামিতিগুলিতে জড়িত একটি খুব জটিল জিনিস। অটোপাইলটের যথাযথ বৈশিষ্ট্যগুলির মধ্যে "গাড়ি কোনও দেয়ালের সাথে ক্র্যাশ হবে না" এবং "গাড়ি যেখানে যেতে বলা হবে সেখানে চালিত হবে" এর মতো জিনিসগুলি অন্তর্ভুক্ত করে। "গাড়ি কোনও দেয়ালের সাথে ক্র্যাশ হবে না" এর মতো একটি সম্পত্তি সত্যই গুরুত্বপূর্ণ, তাই আমরা এটি প্রমাণ করতে চাই। যেহেতু সিস্টেমটি শারীরিক বিশ্বে পরিচালনা করে, তাই আপনাকে কিছু শারীরিক বাধা যুক্ত করতে হবে; কম্পিউটেশনাল সিস্টেমের আসল সম্পত্তি হ'ল কিছু হবে "উপাদান বিজ্ঞান সম্পর্কিত এই অনুমানের অধীনে, এবং গাড়ির সেন্সরগুলির দ্বারা প্রতিবন্ধকতাগুলির উপলব্ধি সম্পর্কে এই অনুমানগুলি, গাড়ি কোনও দেয়ালের সাথে ক্র্যাশ করবে না"। তবে তবুও, ফলাফলটি তুলনামূলকভাবে সহজ সম্পত্তি যা স্পষ্টভাবে কাম্য।

আপনি কোড থেকে এই সম্পত্তি প্রমাণ করতে পারেন? আপনি যদি পুরোপুরি একটি আনুষ্ঠানিক পদ্ধতির অনুসরণ করেন তবে শেষ পর্যন্ত তা হচ্ছে ¹ তবে কোডটির বিভিন্ন অংশ রয়েছে; ব্রেক, ক্যামেরা, ইঞ্জিন ইত্যাদি সমস্ত স্বায়ত্তশাসিতভাবে নিয়ন্ত্রণ করা হয়। ব্রেকগুলির একটি নির্ভুলতা সম্পত্তি হ'ল এমন কিছু হবে "যদি 'ব্রেক প্রয়োগ' সংকেত চালু থাকে তবে ব্রেক প্রয়োগ করা হয়"। ইঞ্জিনের একটি নির্ভুলতা সম্পত্তি হবে "যদি ক্লাচ সিগন্যালটি বন্ধ থাকে তবে ইঞ্জিন চাকাগুলি চালাচ্ছে না"। এগুলি একসাথে রাখার জন্য এটি খুব উচ্চ-স্তরের মতামত নেয়। একটি স্পেসিফিকেশন একটি মধ্যবর্তী স্তর তৈরি করে যেখানে সিস্টেমের বিভিন্ন উপাদান এক সাথে যুক্ত করা যায়।

প্রকৃতপক্ষে, গাড়ী অটোপাইলট হিসাবে এ জাতীয় জটিল ব্যবস্থায় বিভিন্ন পরিমাণের পরিশোধনগুলির সাথে বিভিন্ন স্তরের স্পেসিফিকেশন থাকবে। একটি পরিশোধন পদ্ধতির প্রায়শই নকশায় ব্যবহৃত হয়: কিছু উচ্চ-স্তরের বৈশিষ্ট্য যেমন "গাড়ি কোনও দেয়ালের সাথে ক্র্যাশ হবে না" দিয়ে শুরু করুন, তারপরে এটি সেন্সর এবং ব্রেক প্রয়োজন এবং সেন্সরগুলির জন্য কিছু প্রাথমিক প্রয়োজনীয়তা, ব্রেকগুলি তৈরি করে এবং পাইলট সফ্টওয়্যার, তারপরে সেই মৌলিক প্রয়োজনীয়তাগুলিকে উপাদানটির নকশায় পুনরায় পরিমার্জন করুন (সেন্সরের জন্য, আমি একটি রাডার, একটি ডিএসপি, একটি চিত্র প্রসেসিং লাইব্রেরি,…) ইত্যাদি আনুষ্ঠানিক বিকাশ প্রক্রিয়াতে, প্রতিটি স্তরের স্পেসিফিকেশন তার উপরের স্তরের দ্বারা নির্ধারিত প্রয়োজনীয়তা মেটাতে প্রমাণিত হয়, সর্বোচ্চ স্তরের বৈশিষ্ট্য থেকে শুরু করে কোড পর্যন্ত সমস্ত উপায়।

স্পেসিফিকেশনটি সঠিক কিনা তা নিশ্চিত হওয়া অসম্ভব। উদাহরণস্বরূপ, যদি আপনি পদার্থবিজ্ঞান ভুল করে থাকেন তবে ব্রেকগুলি আনুষ্ঠানিক প্রয়োজনীয়তার সাথে ব্রেক কোড সম্পর্কিত গণিতটি সঠিক হলেও ব্রেকগুলি কার্যকর নাও হতে পারে। আপনার যদি 5000,000 কেজি থাকে তবে ব্রেকগুলি 500 কেজি লোডের সাথে কার্যকর তা প্রমাণ করার পক্ষে ভাল নয়। তবে এটি দেখতে আরও সহজ যে 500 কেজিটি ভুল কোডের ভিতরে দেখার চেয়ে ভুল যে তারা গাড়ির শারীরিক পরামিতিগুলির পক্ষে যথেষ্ট ভাল হবে না।

Fully _{সম্পূর্ণ আনুষ্ঠানিক পদ্ধতির বিপরীতটি হল "আমি অনুমান করি এটি কাজ করে তবে আমি নিশ্চিত হতে পারি না"। আপনি যখন নিজের জীবন বাজি ধরছেন তখন তা এত দুর্দান্ত বলে মনে হয় না।}

Comments

আমার কোডের কেবলমাত্র একটি সম্পত্তি প্রমাণ করা এবং এটি সর্বদা সঠিক হবে কিনা তা নিশ্চিত করা সম্ভব, উদাহরণস্বরূপ আমি কেবল প্রমাণ করতে চাই যে অ্যারের সূচকটি কখনই অ্যারের সীমানার বাইরে নয়, এবং আমি তার সম্পর্কে চিন্তা করি না অন্য জিনিস?

— মেকেল জ্যাকসন

নিবন্ধন করুন আপনি এটি আপনার অনুমান হিসাবে ব্যবহার করুন। এটি সম্ভবত একটি দুর্বল বৈশিষ্ট, তবে কিছুই এটি ব্যবহারে আপনাকে থামায় না এবং এটি প্রমাণের জন্য আনুষ্ঠানিক পদ্ধতিগুলি ব্যবহার করে।

— চি