আমরা কীভাবে জানতে পারি যে আনুষ্ঠানিক পদ্ধতিগুলি কাজ করে?


20

আনুষ্ঠানিক পদ্ধতির একটি গুরুত্বপূর্ণ লক্ষ্য হ'ল স্বয়ংক্রিয় বা মানব-নির্দেশিত উপায় দ্বারা সিস্টেমগুলির যথার্থতা প্রমাণ করা। তবে, মনে হচ্ছে আপনি সঠিকতার প্রমাণ দিতে পারলেও, সিস্টেমটি ব্যর্থ হবে না এমন গ্যারান্টি দিতে সক্ষম হতে পারবেন না। উদাহরণ স্বরূপ:

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

4
1 এবং 3 ইস্যুগুলি পদ্ধতি বিশ্লেষণের অন্তর্নিহিত বলে মনে হচ্ছে, পদ্ধতি যাই হোক না কেন। আনুষ্ঠানিক পদ্ধতিগুলি অন্যান্য পদ্ধতির চেয়ে কমপক্ষে তাদের সুস্পষ্ট করে তোলে। আমি যতদূর জানি সংখ্যা 2 অস্তিত্বহীন; আমি যে আনুষ্ঠানিক সিস্টেমগুলি দেখেছি সেগুলি সঠিক প্রমাণিত হয়েছে; আপনি অবশ্যই প্রতিটি সংশোধন সিস্টেমটিকে নিজেরাই সংশোধন করে এবং ভুল করে ভুল করতে পারেন
রাফেল

8
এই প্রশ্নটি বরং বিষয়গতভাবে বর্ণিত, এবং একভাবে উস্কানি দেওয়ার জন্য। আমি rephrasing বা বন্ধ সুপারিশ করব।
সুরেশ ভেঙ্কট

4
আমার রায়টিতে প্রশ্নটি আরও কার্যকর করার জন্য আমি কয়েকটি বড় সংশোধন করেছি। আপনি যদি মনে করেন এটি খুব আক্রমণাত্মক পরিবর্তন ছিল, দয়া করে মেটাতে পোস্ট করুন।
নীল কৃষ্ণস্বামী

1
@ নীল: সুন্দর সম্পাদনা করুন। আপনার পরিবর্তনটি যে জিনিসটি বাদ দেয় তা হ'ল সিস্টেম সুরক্ষার একটি উল্লেখ, যা মূল প্রশ্নের মূল অংশ ছিল। সম্ভবত জেনি আবার এটি নিজের প্রশ্ন তৈরি করতে পারেন।
ডেভ ক্লার্ক

1
নতুন বুলেট 4 হিসাবে: বড় ভুল ধারণা: (বাস্তববাদী) পরীক্ষা ত্রুটিগুলির অনুপস্থিতি কখনই প্রদর্শন করতে পারে না।
রাফেল

উত্তর:


11

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

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

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


9

আপনার পয়েন্ট ক্রম:

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

9

আনুষ্ঠানিক পদ্ধতিগুলি ইতিমধ্যে বড়-সময় কাজ করার জন্য দেখানো হয়েছে। এগুলি না থাকলে আমরা আধুনিক ডিজিটাল সিস্টেমগুলি (মাইক্রোপ্রসেসর) ডিজাইনের জটিলতা মোকাবেলা করতে পারতাম না।

কার্যক্ষম সমতুল্য যাচাইকরণের সাথে যুক্তিযুক্ত কোনও মাইক্রো জাহাজ নেই; এর এফপিইউ ছাড়াই এফভি সাপেক্ষে; এর ক্যাশে সুসংহত প্রোটোকল ছাড়া এফভি সাপেক্ষে (1995 সাল থেকে এটি এরকম হয়েছে)।

সফ্টওয়্যার এবং ইঞ্জিনিয়ারড ফিজিক্যাল সিস্টেমের মধ্যে সুস্পষ্ট পার্থক্য বাদ দিয়ে (যেমন সেতুগুলি, যেখানে কেউ সুরক্ষার কারণ যুক্ত করতে পারে), তারা সিএসে ইঞ্জিনিয়ারিং গণিতের ভূমিকা পালন করে। তবে এফএম এর ব্যবহার সর্বদা সুবিধা / ব্যয়ের উপর নির্ভর করে। মাইক্রোসফ্টের মতো সংস্থাগুলিতে (এক স্লাইডে গুগল এসএজি) ফজ টেস্টিং বিগ-টাইম প্রদান করে।

এমনকি একটি মাইক্রো এর মধ্যেও সাবসিস্টেম রয়েছে (যেমন মাইক্রোপ্রসেসর পাইপলাইন), যেখানে এফভি অন্য কোথাও এর মতো প্রভাব ফেলেনি (যেমন এফপিইউ, যেখানে প্রচলিত পরীক্ষামূলক পরীক্ষামূলক মূল্যায়ন ত্রুটির অনুপস্থিতির প্রমাণিত হলে অনেক ক্ষেত্রে প্রথাগত পরীক্ষা করা হয়নি)। : কাইভোলা এট আল CAV'09)।

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


8

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


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

6

তবে, মনে হচ্ছে আপনি সঠিকতার প্রমাণ দিতে পারলেও, সিস্টেমটি ব্যর্থ হবে না এমন গ্যারান্টি দিতে সক্ষম হতে পারবেন না।

হ্যাঁ, সম্ভবত কোনও গ্যারান্টি নেই । আনুষ্ঠানিক পদ্ধতিগুলি ত্রুটিগুলি সন্ধান এবং নির্মূল করার জন্য এবং মানুষকে বোঝানোর জন্য।

কোন কৌশলটি কোনও স্পেসিফিকেশন আদৌ কোনও অর্থবোধ করে কিনা তা পরীক্ষা করার জন্য জানা যায়?

আপনি আনুষ্ঠানিক সিস্টেমগুলির নির্দিষ্টকরণের জন্য মডেল চেকিং সরঞ্জামগুলিতে আগ্রহী হতে পারেন ।

প্রমাণ প্রক্রিয়াটিও ত্রুটিযুক্ত হতে পারে! কে জানে যে এই অনুমানের নিয়মগুলি সঠিক এবং বৈধ?

আমি মনে করি (গোয়েদেলের অসম্পূর্ণতা উপপাদ্যের কারণে) অনুমানের নিয়মগুলির একটি সিস্টেম দেখানো অবিচ্ছেদ্যভাবে আরও বেশি শক্তিশালী আনমন বিধিগুলির জন্য আবেদন করে।

তদতিরিক্ত, প্রমাণগুলি খুব বড় হতে পারে এবং আমরা কীভাবে জানব যে সেগুলিতে ত্রুটি নেই?

আশা করি, বিশাল প্রমাণগুলি একটি ছোট প্রুফ চেকার দ্বারা চেক করা হয় যা মানুষের কাছে যুক্তিসঙ্গত সময়ে পড়া এবং বুঝতে পারে। এটিকে কখনও কখনও "ডি ব্রুইজন মাপদণ্ড" বলা হয়। আপনি যদি বিশ্বাস করেন যে প্রুফ চেকার একটি ভুল প্রমাণকে প্রমাণীকরণ করবেন না, আপনার কেবলমাত্র পরীক্ষককে পরীক্ষা করা দরকার।

সত্যিকারের হার্ডওয়্যারটির পতনের জন্য অ্যাকাউন্টে পরিচিত এমন কোনও কৌশল রয়েছে কি?

ফল্ট সহনশীল টাইপ করা সমাবেশ ভাষা সম্পর্কে কীভাবে ?

তবে, আমি বেশিরভাগ গবেষণা দেখি যা হয় আনুষ্ঠানিক পদ্ধতি বা পরীক্ষার উপর দৃষ্টি নিবদ্ধ করে। দুজনের সংমিশ্রণ সম্পর্কে কী জানা যায়?

"টিএপি সম্মেলন প্রমাণ এবং পরীক্ষার একীকরণের জন্য উত্সর্গীকৃত"

"প্রমাণ এবং পরীক্ষার জন্য" কেবল গুগলিংয়ের ভাঁজের উপরে বেশ কয়েকটি দুর্দান্ত হিট রয়েছে।


5

কোন কৌশলটি কোনও স্পেসিফিকেশন আদৌ কোনও অর্থবোধ করে কিনা তা পরীক্ষা করার জন্য জানা যায়?

এটি অবশ্যই রায় রায় is সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ে, লোকেরা নির্দিষ্টকরণগুলি খুঁজে পেতে / লিখতে / নিশ্চিত করতে খুব কড়া পদ্ধতি তৈরি করেছে। এটি প্রকৃত মানুষের দ্বারা এবং একটি অ-আনুষ্ঠানিক (অর্থে অ গাণিতিক প্রক্রিয়া) ব্যবহার করে করা হয়, সুতরাং এটি এখনও অসঙ্গতি সাপেক্ষে, তবে দিনের শেষে, এটি লোকে যা যাচাই করতে চায় তার সাথে এটি মিলিয়ে যায়, আর কম নয়।

সত্যিকারের হার্ডওয়্যারটির পতনের জন্য অ্যাকাউন্টে পরিচিত এমন কোনও কৌশল রয়েছে কি?

অবশ্যই, রানটাইম যাচাইকরণ হিসাবে পরিচিতি যাচাইয়ের একটি ক্ষেত্র রয়েছে , আপনি নির্দিষ্ট দৃশ্যের সাপেক্ষে সম্পূর্ণ ভার্চুয়াল পরিবেশে চলমান বাস্তব সিস্টেমে এক্সিকিউশন ভিত্তিক মডেল চেকিং ব্যবহার করতে পারেন (আমি ভি-ডিএস + এপিএমসির সাথে এতে নিজেকে অবদান রেখেছি )। তবে, যাচাইকরণের প্রক্রিয়াতে সিস্টেম এবং পরিবেশের মধ্যে মিথস্ক্রিয়া যুক্ত করার জন্য এটি স্পষ্টতই একটি বড় সমস্যা।

তবে, আমি বেশিরভাগ গবেষণা দেখি যা হয় আনুষ্ঠানিক পদ্ধতি বা পরীক্ষার উপর দৃষ্টি নিবদ্ধ করে। দুজনের সংমিশ্রণ সম্পর্কে কী জানা যায়?

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


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

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

তবে আপনি কমপক্ষে অসঙ্গতিগুলি পরীক্ষা করতে পারেন, তাই না? "আপনি যা চান তা" সম্পর্কে আপনার অভিজ্ঞতাগুলি কী হয়েছে?
রাফেল

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

5

আপনি পিভিএস উপপাদ্য প্রবাদটির অন্যতম ডিজাইনার জন রাশবির কাজের প্রতি আপনার খুব আগ্রহী হতে পারেন , যিনি আপনার উল্লিখিত পয়েন্টগুলির সাথে যথাযথ আগ্রহী who আপনি এই ক্লাসিক পড়া ভোগ পারে আনুষ্ঠানিক পদ্ধতি ব্যবহার এবং ক্রিটিক্যাল সিস্টেম সার্টিফিকেশন (1993) সম্পর্কে এফএএ প্রতিবেদন , এবং তার নতুন লেখা (প্রদত্ত প্রমাণ বিভিন্ন উপায়ে টেস্টিং, প্রমাণাদি থেকে একটি সম্ভাব্য প্রথাগত নিরাপত্তা ক্ষেত্রে একত্রিতকরনের সম্পর্কে, বিশ্লেষণ ইত্যাদি)

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.