ایران ترجمه – مرجع مقالات ترجمه شده دانشگاهی ایران

افزونه اکیلیپس مهندسی معکوس برنامه های نرم افزاری

افزونه اکیلیپس مهندسی معکوس برنامه های نرم افزاری

افزونه اکیلیپس مهندسی معکوس برنامه های نرم افزاری – ایران ترجمه – Irantarjomeh

 

مقالات ترجمه شده آماده گروه کامپیوتر
مقالات ترجمه شده آماده کل گروه های دانشگاهی

مقالات رایگان

مطالعه ۲۰ الی ۱۰۰% رایگان مقالات ترجمه شده

۱- قابلیت مطالعه رایگان ۲۰ الی ۱۰۰ درصدی مقالات ۲- قابلیت سفارش فایل های این ترجمه با قیمتی مناسب مشتمل بر ۳ فایل: pdf انگیسی و فارسی مقاله همراه با msword فارسی -- تذکر: برای استفاده گسترده تر کاربران گرامی از مقالات آماده ترجمه شده، قیمت خرید این مقالات بسیار کمتر از قیمت سفارش ترجمه می باشد.  

چگونگی سفارش

الف – پرداخت وجه بحساب وب سایت ایران ترجمه (شماره حساب) ب- اطلاع جزئیات به ایمیل irantarjomeh@gmail.com شامل: مبلغ پرداختی – شماره فیش / ارجاع و تاریخ پرداخت – مقاله مورد نظر -- مقالات آماده سفارش داده شده عرفا در زمان اندک یا حداکثر ظرف مدت چند ساعت به ایمیل شما ارسال خواهند شد. در صورت نیاز فوری از طریق اس ام اس اطلاع دهید.

قیمت

قیمت این مقاله: ۱۰۰۰۰ تومان (ایران ترجمه - irantarjomeh)

توضیح

بخش زیادی از این مقاله بصورت رایگان ذیلا قابل مطالعه می باشد.

مقالات ترجمه شده کامپیوتر - ایران ترجمه - irantarjomeh

www.irantarjomeh.com

افزونه اکیلیپس برای مهندسی معکوس اتوماتیک برنامه های نرم افزاری

شماره      
۱۲۶
کد مقاله
COM126
مترجم
گروه مترجمین ایران ترجمه – irantarjomeh
نام فارسی
افزونه اکیلیپس برای مهندسی معکوس اتوماتیک برنامه های نرم افزاری
نام انگلیسی
A Eclipse Plugin for the Automated Reverse Engineering of Software Programs
تعداد صفحه به فارسی
۲۵
تعداد صفحه به انگلیسی
۶
کلمات کلیدی به فارسی
مهندسی معکوس, ابزار تحلیل, درک نرم افزاری, آنالیز دینامیک, اکیلیپس
کلمات کلیدی به انگلیسی
everse engineering, analysis tool, software understanding, dynamic analysis, Eclipse
مرجع به فارسی
ششمین کنفرانس بین المللی فناوری اطلاعات: نسل های جدید دپارتمان سیستم های اطلاعاتی، دانشگاه علوم کاربردی HEG، سوئیس
مرجع به انگلیسی
IEEE; Dept. information systems, Univ. Applied Sciences, Geneva, Switzerland
سال
۲۰۰۹
کشور
سوئیس
یک افزونه اکیلیپس برای مهندسی معکوس اتوماتیک برنامه های نرم افزاری
چکیده
در مهندسی معکوس یک برنامه نرم افزاری، یکی از مشکلات کلیدی درک نرم افزار می باشد. در عین آن که تکنیک های انتشار یافته بیشتر راهکارهای طراحی بالا به پایین یا پایین به بالا را مد نظر قرار می دهند، روش ما به صورت یک طراحی میانه مطرح می شود: قبل از سعی در درک کد سطح پایین، ما در ابتدا اقدام به ایجاد یک مدل آنالیز فرضی از موارد استفاده شده سیستمی می نماییم. این مدل متعاقبا معرف اهداف ما در خصوص  درک  چنین  راهکاری  می باشد. در حقیقت ما سعی در نگاشت / ترسیم عناصر کد به آبجکت های تحلیلی می نماییم. برای آنکه این رویکرد در سیستم های بزرگ نرم افزاری صنعتی قابل استفاده باشد، لازم است تا آن را به وسیله یک ابزار قدرتمند مورد پشتیبانی قرار دهیم. این مقاله نسبت به ارائه افزونه اکیلیپس[۱]، که ما آن را جهت پشتیبانی از روش خود ایجاد نمودیم، همراه با یک سناریوی مهندسی معکوس با استفاده از این ابزار، اقدام می نماید. پس از آن فناوری استفاده شده و نتایج حاصله خود را مورد بحث قرار می دهیم.
کلمات کلیدی: مهندسی معکوس، ابزار تحلیل، درک نرم افزاری، آنالیز دینامیک، اکیلیپس
[۱] Eclipse
۱- مقدمه
جهت گسترش عمر یک سیستم موروثی، به منظور مدیریت پیچیدگی آن و کاهش هزینه نگهداری سیستم ها، یکی از گزینه های مطرح شده اعمال فرآیند مهندسی مجدد می باشد. اخیرا، ما فرآیند مهندسی معکوس را بر مبنای مدل «پردازش یکپارچه»[۱] ایجاد نمودیم که برمبنای آنالیز دینامیکی برنامه اجرایی می باشد. چارچوب تئوریکی تکنیک ما در جای دیگر تشریح شده است [۷] [۸]. اولین آزمایشات با این فرآیند مهندسی معکوس به صورت دستی انجام شده است. با وجود ترغیب بهره گیری از چنین مواردی، اندازه نرم افزار صنعتی دنیای حقیقی ضروریت پشتیبانی از یک ابزار توانمند را گوشزد می نماید. هدف این مقاله ارائه ابزار توسعه یافته و ایجاد روشی می باشد که قابلیت اتوماتیک سازی غالب مشکل ترین وظایف حین فرآیند را خواهد داشت: یعنی طراحی و نگاشت این سیستم از اجزای کد منبع سطح پایین به اجزای مدل تحلیلی. در ادامه، بخش ۲ معرف خلاصه کوتاهی از روش ما می باشد و بخش ۳ دیدگاه ما با توجه به تلاش جهت درک نرم افزاری این مبحث را توجیه می نماید. بخش ۴ نیز معرف موتوری است که قابلیت نگاشت اجزای کد منبع به اجزای مدل تحلیلی را داشته و بخش ۵ اقدام به معرفی این ابزار با رابطه کاربری آن می نماید. بخش ۶ نیز ارائه دهنده یک سناریوی مهندسی معکوس است که از این ابزار در آن استفاده می گردد و بخش ۷ نتایج حاصله تاکنون و تحقیقات آتی را برمی شمارد. بخش ۸ نیز متعاقبا تحقیقات مرتبط را عرضه می نماید.
[۱] Unified Process
 
۲- خلاصه روش ما
به طور کلی، مستند سازی سیستم های موروثی در بهترین حالت یک مبحث قدیمی تلقی شده  و در بدترین حالت دیگر حتی نشانی از آن نیز وجود ندارد. غالبا، دسترسی به توسعه دهندگان چنین سیستم هایی، جهت فراهم آوردن اطلاعات این  گونه سیستم ها، امکان پذیر نمی باشد. در چنین موقعیت هایی اشخاصی که هنوز دورنمای مناسبی را در این مبحث تصور می کنند همچنان کاربران آن باقی می مانند. در حقیقت آنها غالبا به خوبی از محتوای تجاری و ارتباطات تجاری برنامه ها آگاه می باشند. بنابراین، روش تکراری و افزایشی ما، که برمبنای پردازش یکپارچه است [۱۱]، کار خود را از بازیافت مجموعه ای از رویدادهای[۱] سیستمی از کاربران حقیقی آن آغاز می نماید. راهکارهای اصلی به شرح ذیل هستند [۸]:
  • مستند سازی مجدد مجموعه ای از رویدادهای سیستم
  • طراحی مدل های تحلیلی مرتبط با کلیه مجموعه رویدادها
  • مستند سازی مجدد ساختار کد / برنامه بطور مشهود
  • اجرای سیستم بر حسب مجموعه ای از رویدادهای سیستم و ثبت رویه های اجرایی
  • تحلیل رویه های اجرایی و مشخص نمودن کلاس هایی که در آن شامل شده اند.
  • نگاشت / مسیردهی کلاس ها در طرح های اجرایی به آبجکت های مدل تحلیلی
  • مستند سازی مجدد معماری سیستم از طریق خوشه بندی کلاس ها برمبنای نقش آنها در پیاده سازی مجموعه ای از رویدادهای سیستمی.
در غیاب هر نوع فرآیند مستند سازی در خصوص چنین سیستمی جهت اعمال رویه مهندسی مجدد، مدل آنالیز پردازش یکپارچه که در ارتباط با مجموعه ای از رویدادها می باشد معرف بهترین فرضیه ما در خصوص معماری حقیقی چنین سیستمی خواهد بود. شکل ۱ معرف مثال یک مدل تحلیلی همراه با کلاس های متعارف آن (آبجکت تحلیلی) می باشد که خود معرف نقش نرم افزار برای این کلاس ها خواهد بود. این نقش را می توان به شرح ذیل مشخص ساخت: مرزها یا کرانه ها (رابط با دنیای، همانند صفحات نمایشگر)، هویت ها (ذخیره سازهای اطلاعاتی) و آبجکت های کنترل (مختصات اجرایی مجموعه ای از رویدادها) [۱۱].
[۱] use-cases
۳- توجیه درک نرم افزار
تئوری های درک نرم افزار مدت زمان مدیدی است که در مباحث مرتبط مطرح می شوند [۱، ۲، ۱۳، ۱۴، ۱۷، ۱۸]. به طور کلی نویسندگان تمایزی را بین پروسه های بالا به پایین (از اطلاعات کاربردی به پایین بسمت کد) و پروسه های پایین به بالا (از کد به سمت تابع) قائل می شوند. با این وجود، تئوری های اندکی برای درک برنامه مدل – مبنا انتشار یافته اند که ما آن را تحت عنوان برنامه های سطح میانه طبقه بندی می نماییم. در دیدگاه ما، مهندس مسئول فرآیند نگهداری سیستم ها در ابتدا اقدام به بازسازی مدل تحلیلی مرتبط با مجموعه ای از رویدادها، قبل از تلاش جهت درک کد برنامه، می نماید. این مدل معرف هدف درک کدهای برنامه می باشد، چرا که ارتباط بین ضروریات کاربری (مجموعه ای از رویدادها) و مدل تحلیلی به صورت مستقیم در نظر خواهد بود. از طریق انجام این فرآیند، ما به سمت درک کاربردی قیاسی سیستمی که نزدیکتر به کد / برنامه است حرکت می نماییم (یعنی آنکه ما اقدام به «انتقال» درک کاربردی از مدل – کاربری به سمت مدل تحلیلی می نماییم که قرابت نزدیکتری با کد برنامه دارد). بنابراین شکافی که می بایست جهت درک این کد پر نمود کوچکتر می باشد. این دقیقا رویه ای است که محیط جامع ما قابلیت انجام آن را خواهد داشت. در حقیقت، نگاشت کلاس های پیاده سازی به سمت آبجکت های تحلیلی سبب ایجاد لینکی بین مجموعه ای از رویدادها و کلاس های پیاده سازی خواهد شد. با این وجود، ذکر این نکته مهم است که یک کلاس پیاده سازی واحد را می توان در فرآیند پیاده سازی چندین آبجکت تحلیلی به کار گرفت. به علاوه، یک آبجکت تحلیلی واحد را می توان به وسیله چندین کلاس به کار گرفت. به طور خلاصه، نگاشت بین آبجکت تحلیلی و کلاس های پیاده سازی به صورت چند به چند می باشد. غالبا، ما می توانیم برخی از روش های کلاس های پیاده سازی را با هر آبجکت تحلیلی که آنها اعمال می دارند مرتبط سازیم. بنابراین مهم است تا از این نکته آگاه باشیم که می بایست به کدامیک از روش ها در فرآیند دنبال نمودن ویژگی های اجرایی و نگاشت از یک آبجکت تحلیلی به یک کلاس اجرایی متکی باشیم. در نهایت ضروری است تا اجازه استفاده آزادانه از محیط تحت بررسی با بهره گیری از قابلیت گشت و گذار بین کلیه مدل ها و منابع اطلاعاتی را داشته باشیم و بتوانیم اقدام به مشخص نمودن اجزای منطبق در کلیه مدلها و منابع اطلاعاتی نماییم.
۴- اتوماتیک سازی نگاشت
در حقیقت، برای هر نوع سیستم صنعتی با اندازه منطقی، نگاشت بین آبجکت های تحلیلی و کلاس های پیاده سازی را نمی توان به صورت دستی انجام داد که علت آن تعداد  کلاس های شامل شده و اندازه برنامه های اجرایی که می بایست اقدام به رهگیری و مشخص سازی آنها نماییم می باشد. بنابراین، جهت اتوماتیک سازی این رویه، ما اقدام به طراحی یک سیستم تولیدی نمودیم که در آن قواعد تولید قابلیت پیاده سازی ویژگی های ابتکاری ما در طی بکارگیری این روش به وسیله دست را فراهم می سازد [۱]. با این وجود، از آنجایی که این سیستم های نگاشت که خود نشات گرفته از رویه های ابتکاری ما هستند غالبا خود به عنوان ویژگی های محتمل و نه قطعی در نظر گرفته شده اند، لازم است تا اقدام به تکمیل سیستم تولید با استفاده از یک سیستم نگهداری درست سیستم (TMS) [۶] نماییم تا قابلیت تعامل با ویژگی های نامعمول حقایق حاصله را داشته باشند. به طور خلاصه، یک TMS را می توان به عنوان نموداری فرض نمود که گره های آن به عنوان حقایق مشخص شده در نظر گرفته شده و لبه های آن وابستگی های استنتاجی بین این حقایق خواهند بود. به هنگامی که ارزش قطعیت یک حقیقت مشخص تصحیح می شود، این مقدار به کلیه حقایق مرتبط در نمودار سرایت نموده تا آنکه همبستگی و انسجام کلی  حقایق استنباطی حفظ گردد.
۵- آنالیز معکوس افزونه اکیلیپس
ابزار ما، که به عنوان یک افزونه برای پلتروم اکیلیپس توسعه یافته است، دارای ۵ مولفه اصلی می باشد:
  1. کاوشگر فایل گسترش یافته
  2. ادیتور فایل گسترش یافته
  3. ادیتور مدل تحلیلی
  4. ادیتور مجموعه ای از رویدادها
  5. نگارنده مدل که شامل سیستم تولید و TMS می باشد.
شکل ۶ نشان دهنده محیط مهندسی معکوس جامع در چارچوب اکیلیپس است. از بین ۵ مولفه فوق، تنها ۴ مورد در این تصویر مشهود می باشند. نقشه بردار یا نگارنده مدل[۱] در زمینه اجرا شده و دارای یک نمای خاصی نمی باشد. در قسمت فوقانی سمت راست، می توان مناسبترین مورد را Violet خواند [۱۹]. ادیتور مجموعه ای از رویدادها در بخش پایینی ارائه شده است. این ادیتور دارای سه نمای فرعی می باشد. در قسمت سمت چپ، آبجکت های تحلیلی که در مجموعه ای از رویدادها  شامل هستند نشان داده شده اند. این موارد همگی آبجکت های حضور داشته در مدل تحلیلی در قسمت فوقانی سمت راست می باشند. در مرکز ما می توانیم ادیتور مرتبط با جریان مجموعه ای از رویدادها را بیابیم. در قسمت سمت راست ما آبجکت های تحلیلی مرتبط با مرحله عمل انتخابی در جریان مجموعه ای از رویدادها را نشان می دهیم. آبجکت های نشان داده شده در قسمت پایین سمت راست جزء آن دسته از آبجکت های مرتبط با ششمین مرحله عمل در نمودار مجموعه ای از رویدادها می باشند. ستون «stat» ارائه دهنده تعداد آبجکت های تحلیلی در ارتباط با هر مرحله عمل است. با توجه به اطلاعات ما، این مورد به عنوان تنها ابزاری به شمار می آید که قابلیت  اهرم بندی رویه تحلیل UP، از طریق لینک دادن آبجکت های آنالیز به مراحل عملیاتی مجموعه رویدادها، را خواهد داشت.
[۱] model mapper
 
 
۶- سناریوی مهندسی معکوس
پس از بازیافت مجموعه ای از رویدادهای سیستم، ما معماری آشکار آن را مجددا مستند سازی می نماییم. در مورد برنامه های جاوا، این مورد را می توان به صورت اتوماتیک از طریق استفاده از یک محیط مهندسی نرم افزار نظیر RSA انجام داد. سپس ما کد منبع سیستم را به گونه ای تجهیز می نماییم تا قابلیت ایجاد فرآیند رهگیری اجرایی را داشته باشد. کد تجهیز شده کامپایل شده و برحسب سناریوهای منطبق با مجموعه رویدادها  اجرا می شود. فرآیند رهگیری اجرایی سپس ثبت می گردد. به هنگامی که این کار مقدماتی به اتمام رسید، ما می توانیم اقدام به تحلیل سیستم با استفاده از ابزار خود نماییم. در ابتدا ما فایل های منبع سیستم جهت تحلیل را انتخاب می کنیم، که برای این کار از منوی فایل این ابزار بهره می جوییم. سپس، برای هر مورد از مجموعه ای از رویدادها، به شرح ذیل اقدام خواهیم نمود:
  1. در ابتدا با استفاده از ابزار ادیتور مجموعه رویدادها به جریان رخدادهای مرتبط با آن وارد می شویم.
  2. سپس به صورت دستی اقدام به تحلیل مجموعه ای از رویدادها نموده و مدل تحلیلی آن را در ادیتور مدل آنالیز طراحی می نماییم.
  3. متعاقبا، هریک از آبجکت های تحلیلی این مدل را به مرحله عملرد جریان مجموعه رویدادها متصل می سازیم. این امر از طریق برداشت یک یا چند آبجکت موجود لیست شده در بخش چپ در ادیتور مرتبط انجام می شود.
  4. پس از انجام این کار می توانیم نگاشت گر آبجکت را آغاز نماییم. این مورد در جستجوی فایل رهگیر اجرایی جهت لیست نمودن به عنوان ورودی خواهد بود.
  5. پس از تکمیل فرآیند نگاشت، نتیجه را می توان به صورت حاشیه در مدلها و ادیتورها نشان داد.
پس از اجرای برنامه نگاشتگر، در صورتی که فردی یک آبجکت تحلیلی را در لیست بخش چپ ادیتور مجموعه ای از رویدادها انتخاب کرد (به شکل ۶ رجوع شود) سپس:
  1. کاوشگر فایل یک نقطه قرمز کوچک را در قسمت انتهایی سمت راست آیکون فایل نشان می دهد. این موارد در حقیقت فایل هایی هستند که حاوی کلاس های نگاشت شده به آبجکت تحلیلی انتخابی می باشند.
  2. به هنگامی که یکی از این فایل ها را باز می کنیم، ادیتور اطلاعات مربوط به نشان یا امضای[۱] کلیه روش هایی که در این برنامه نگاشت شامل شده اند را مشخص  می سازد.
[۱] signature
۷- نتیجه گیری و تحقیقات آتی
در این مقاله ما ابزار مهندسی معکوس که به عنوان یک افزونه برای محیط اکیلیپس توسعه داده ایم را معرفی می نماییم. این افزونه قابلیت پیاده سازی راهکار ما در خصوص درک از نرم افزار موروثی را خواهد داشت. اولین مرحله مشخص نمودن کلاس هایی می باشدکه قابلیت پیاده سازی مجموعه ای از رویدادها خاص را خواهد داشت. این مورد نسبتا آسان است چرا که می توانیم آنها را در ویژگی رهگیری اجرایی مرتبط با مجموعه ای از رویدادها مشخص سازیم. اما این مورد کفایت ندارد چرا که لازم است تا مقادیر زیادی از این کلاس ها، همراه با مسئولیت های بسیار، را شامل نمود. ما خواستار دانستن نقش این کلاس ها در خصوص پیاده سازی مجموعه ای از رویدادها هستیم. از آنجایی که قابلیت طراحی یک مدل تحلیلی برای هر یک از مجموعه های رویدادها را خواهیم داشت، ما روشی را جهت معرفی نقش این کلاس ها در نظر می گیریم. بنابراین، در صورتی که قابلیت نگاشت آبجکت تحلیلی به کلاس های پیاده سازی را داشته باشیم، می توانیم نقش مورد آخری را در خصوص فرآیند پیاده سازی به دست آوریم. این مورد در حقیقت چیزی است که ابزار ما می تواند آن را انجام دهد. با این وجود، از آنجایی که پیاده سازی یک سیستم ممکن است شامل صدها کلاس و هزاران ویژگی رهگیری اجرایی باشد، حتی در صورتی که نخواسته باشیم از میلیون ها رخداد صحبت کنیم، به طور کلی نمی توانیم چنین اطلاعاتی را به وسیله دست مورد تحلیل و پردازش قرار دهیم. بر این مبنا ما یک موتور نگاشت گر را توسعه دادیم که برمبنای فناوری های AI می باشد. ابزار ما در محیط جاوا به عنوان یک افزونه ایکیلیپس توسعه یافته است. تجاربی که ما تاکنون بر روی یک سیستم دارای اندازه متوسط (۳۶۰کلاس، ۲۵ هزار رخداد) به دست آورده ایم نشان دهنده آن است که تطبیق گر اتوماتیک قابلیت حصول نتایج بهتر در مقایسه با نگاشت کننده دستی را خواهد داشت. در حقیقت نتایج آن بسیار دقیق تر از موردی است که می توانیم به وسیله دست انجام دهیم. علت این امر آن است که نگاشت کننده اتوماتیک از قابلیت سیستماتیک بیشتری برخوردار بوده و همچنین می تواند کلیه اطلاعات موجود را به صورت عمیق مورد پردازش قرار دهد. به طور مثال، در این آزمایش، ما مشخص ساختیم که برخی از نگاشت ها را به هنگام پردازش اطلاعات به صورت دستی از دست داده ایم. به علاوه، آنالیزهای ما همراه با ابزار همچنین منجر به مشخص  ساختن  کلاس هایی  می شود  که  نقش های  ترکیبی  را  ایفا می نمایند. به طور مثال برخی از کلاس ها نقش یک کرانه را به عهده داشته و یا نقش یک آبجکت هویت را در عین حال به عهده دارند. چنین موردی غالبا به عنوان علامت یک طراحی بد می باشد. بنابراین، ابزار ما را همچنین می توان جهت ارزیابی کیفیت یک طرح مورد استفاده قرار داد. برای مرحله بعدی در این تحقیقات، ما روش خود را گسترش داده و ابزاری را به کار گرفتیم که اجازه مقایسه قواعد کلیه کلاس ها در بین کلیه مجموعه های رویدادهای یک سیستم نرم افزاری را خواهد داد. به عنوان یک توصیه نهایی، ذکر این نکته با ارزش خواهد بود که ابزار ما قابلیت «تشریح» (یعنی تخصیص نقش به) کلیه کلاس ها در سیستم موروثی را نخواهد داشت. در حقیقت، برخی از کلاس هایی که معرف موقعیت هایی استثنایی هستند و یا معرف مسیرهای اجرایی جایگزین هستند را نمی توان به آسانی مشخص ساخت چرا که آنها احتمالا شامل سناریوهای انجام شده به وسیله کاربران نمی باشند. بنابراین، مرحله دیگر در تحقیقات ما تکمیل ابزاری با قابلیت تکنیک های تحلیلی  استاتیک  جهت  باز کردن  کدی  می باشد که احتمالا به صورت بالقوه قابلیت اجرا در موارد استثنایی را خواهد داشت. در نهایت، ما همچنین از فرآیندهای هستی شناسی حوزه جهت ارتقای جستجوی دینامیکی برای مشخص سازی هویت های آن در برنامه ها استفاده خواهیم نمود.
۸- تحقیقات مرتبط
مدت های مدیدی است که مدلهای حوزه به عنوان روشی مناسب جهت ارتقای مهندسی معکوس و درک برنامه مدنظر قرار گرفته اند [۱۴، ۱۵]. نویسندگان غالبا ابزاری را جهت پشتیبانی از دیدگاه خود پیشنهاد می نمایند. تحقیق پیشرو را قطعا می توان در ارتباط با سیستم معروف RIGI وابسته به Muller و همکاران [۱۲] دانست که منجر به حصول سیستم های اخیر SHriMP و Creole شده است [۱۶]. به علاوه، DeBaud و Rugaber [۵] و DeBaud [۴] را می توان به عنوان یک مدل حوزه  قابل اجرایی در قالب یک چارچوب شیء گرا به عنوان هدفی جهت درک راهکارها مشخص در نظر گرفت. این چارچوب معرف مفهوم حوزه می باشد و در جستجو برای یافتن مفهوم منطبق در برنامه ها کمک می نماید. در تحقیق Gold [۹]، یک مبنای اطلاعاتی از مفاهیم برنامه نویسی جهت کمک به درک مشکل به کار گرفته شده است. اما  این  مفاهیم  در سطح  بسیار کمتری از  مدل تحلیلی که ما  استفاده  می نماییم می باشند. این دیدگاه به وسیله ابزار HB-CA پشتیبانی شده است. Rugaber و Stirewalt از یک مشخصه رسمی با استفاده از یک زبان مشخصه جبری جهت مدلسازی هر دوی حوزه و برنامه با استفاده از مهندسی معکوس بهره مند گردیدند [۱۴]. در دیدگاه تحلیل دینامیک برای درک نرم افزار، ابزارهای بسیاری توسعه یافته اند نظیر تحقیق Benett و همکاران [۳]، HamouLahdj [۱۰]، Zeidman و همکاران [۲۱]. در اینجا نویسندگان اقدام به ایجاد مدلهای مفهومی بالاتر سیستم موروثی ننموده اند. در عوض، نگرانی اصلی تعامل با مقدار اطلاعات جهت نمایش می باشد، تا آنکه مهندسین فرآیندهای نگهداری سیستم ها قابلیت «درک» شمولیت کلاسها در فرآیند پیاده سازی سیستم را داشته باشند.  

افزونه اکیلیپس برای مهندسی معکوس اتوماتیک برنامه های نرم افزاری

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

لطفا به جای کپی مقالات با خرید آنها به قیمتی بسیار متناسب مشخص شده ما را در ارانه هر چه بیشتر مقالات و مضامین ترجمه شده علمی و بهبود محتویات سایت ایران ترجمه یاری دهید.
تماس با ما

اکنون آفلاین هستیم، اما امکان ارسال ایمیل وجود دارد.

به سیستم پشتیبانی سایت ایران ترجمه خوش آمدید.