بررسی روش ARJA-e برای ترمیم خودکار نرم افزار

مقاله مورد بررسی در فصل 19 کتاب Genetic Programming Theory and Practice XVII آمده است در این مقاله روش جدیدی به نام ARJA-e توصیف و بررسی می شود که برای ترمیم خودکار نرم افزار کارایی داردبرای ترمیم خودکار نرم افزار همیشه به 3 چالش جلوی ابزارها و روش های انجام این کار قرار دارد که به صورت خلاصه در زیر آمده است:1- چالش اول مربوط به پیدا کردن فضای جستجوی مناسب جهت انجام تست و پیدا کردن خطا یا به عبارتی باگ های نرم افزاری برنامه است مقاله روش های موجود این کار را بررسی کرده و روش قبلی همین مجموعه یعنی روش ARJA و GenProg را برای روش ارائه شده انتخاب می کند2- چالش دوم مربوط به طراحی و پیاده سازی الگوریتم است که بتواند فضای جستجو بصورت بهینه جستجو کند تا زمان اجرای ترمیم کاهش پیدا کند و نیز همچنین بتواند فضاهای جستجوی بزرگتر را نیز در زمان مناسب بررسی نماید مقاله از روش GP که اختصار Genetic Programming است استفاده می کند در قدم بعد یک fitness function برای بررسی روش ارائه می کند.3- چالش سوم در واقع در مرحله بعدی ترمیم یا repair است که باید بررسی شود ترمیم انجام شده با مجموعه تست های ما به اصطلاح overfit نشده باشد و بتواند مجموعه تست های دیگر را به درستی پاسخ دهد در این مرحله است که روش ARJA-e راهکار جدیدی ارائه می دهد.در ادامه مراحل کار ARJA-e را بصورت خلاصه مرور می کنیم:روش ARJA-e برای ترمیم برنامه های جاوا معرفی شده است در ابتدا برای تعیین فضای جستجو که تغییرات لازم جهت ترمیم را داشته باشد از 2 منبع مختلف استفاده می کند مانند روش statement-level redundancy و repair templates همچنین در ادامه فضای نمونه را با استفاده از contextual analysis کاهش می دهد در ادامه از یک تابع سازگاری یا fitness function استفاده می کند که از اطلاعات معنایی مجموعه تست ها استفاده کند برای همین انتظار می رود این روش از روش GP بهتر باشد همچنین همانطور که پیشتر ذکر شد این روش مراحل post processing دارد تا ترمیم overfit شده را شناسایی و از آن استفاده نکند.برای ورودی یک برنامه دارای خطا یا به اصطلاح buggy با یک مجموعه تست JUnit دریافت میکند و در خروجی برنامه ترمیم شده را ارائه می دهد.روش بدست آوردن fitness function این روش به اینصورت است که برای هر خط برنامه بطور مثال x از تابع bi-objective روش ARJA اصلی استفاده می کنیم که بطور مثال (f(x است تابع دومی مثل (g(x با روش محاسباتی ارائه شده در مقاله به دست می آوریم در صورتی که ‏از تابع اولی نرم تر یا به اصطلاح smoother بود از آن استفاده می کنیم مانند شکل زیر:تصویر نمای پچ جدید lower-granularityروش های بعدی برای محدود کردن و کوچک کردن فضای جستجو استفاده از اوپراتورهای ژنتیک و جستجو چندین شی همزمان (Multi-Objective Search) است که در مقاله ذکر شده است و در اینجا تنها به نام بردن آنها اکتفا کردیم.برای مرحله نهایی که پیدا کردن و تشخیص ترمیم های overfit شده است بدین صورت عمل می کنیم که برنامه و یک مجموعه تست مثبت و یک اصلاح پیدا شده را بصورت ورودی می دهیم می خواهیم بررسی کنیم که آیا این اصلاح به مجموعه تست ما overfit شده است یا خیر در صورت overfit بودن این اصلاح مناسب برنامه نخواهد بود روش تشخیص و انجام این کار بصورت تصویری در شکل زیر آمده است:خلاصه روش تشخیص overfit بودن یا نبودن اصلاح پیدا شدهبا بررسی تمام اصلاحات پیدا شده به هرکدام یک عددی نسبت داده می شود و در نهایت اصلاحات رتبه بندی می شوند یا به عبارتی عمل Patch Ranking را انجام می دهیم و اصلاحی که بتواند رتبه بهتری بدست آورد به عنوان اصلاح نهایی منتشر می شود.در ادامه به بررسی راندمان این روش و مقایسه آن با روش های دیگر می پردازیم.دیتاست مورد استفاده به نام Drfects4J از باگ های واقعی تشکیل شده است.روش ارائه شده در مقابل روش های State-of-the-art در مواجه با خطاهای واقعی چگونه است؟بهترین نتیجه بصورت Bold شده آمده استهمانطور که در جدول بالا مشاهده می شود روش ARJA-e نسبت به تمام روش های موجود دیگر نتیجه بهتری می دهد.روش ARJA-e با توجه به اصلاح تولید کرده برای خطای M94 و L61 نسبت به اصلاح انسانی نیز بهتر استروش ARJA-e در مقابله با overfit شدن چه راندمانی دارد؟مقایسه ARJA-e با روش های دیگرهمانطور که در جدول بالا مشخص است روش ARJA-e نسبت به روش های دیگر توانسته بهتر از overfit شدن پچ های برنامه جلوگیری کند.در نهایت با توجه به روش ارائه شده می توان نتیجه گرفت که روش ARJA-e نسبت به 13 روش موجود برای ترمیم خودکار نرم افزار بهتر بوده و با توجه به تعداد باگ و تعداد رفع باگ نسبت به بقیه عملکرد بهتری داشته باشداین مقاله تمرین درس اشکال زدایی دانشگاه شهید بهشتی است و جهت انتشار محتوای فارسی بیشتر است