۲٫۲٫ انواع مخازن داده
۱٫۲٫۲٫کد اصلی:
کد اصلی بخش قابل اجرا و رفتار یک توسعه نرمافزاری است. که در نهایت به صورت فرمت اجرایی به مشتری تحویل داده می شود. که عموما به عنوان مهمترین داده از سوی توسعهدهندگان مورد توجه قرار میگیرد. مخزن حاوی این اطلاعات شامل تعدادی از منابع کد و اسناد در یک یا چند زبان مختلف برنامهنویسی است. این اسناد معمولا به موجودیتهای منطقی به نامهای ماژول[۱۳]یا بسته گروهبندی میشوند. تمام این مجموعه اطلاعات کد اصلی سیستم نامیده می شود. برای کاوش این متون تمرکز روی شناسهها (متغیر، نام)، توضیحات و رشته های اصلی داخل کد اصلی است. معمولا کلمات کلیدی و نمادها در نظر گرفته نمیشوند.
۲٫۲٫۲٫ مخازن خطا(سیستم ردیابی خطا BTS[14])
این مخازن برای ذخیره اطلاعات مربوط به ایجاد و حل خطا، مشخصات ارتقاء سیستم و کلیه اقدامات دیگر در مرحله تعمیر و نگهداری استفاده میشوند. معمولا هنگامیکه توسعهدهندگان و کاربران به مشکل یا خطایی در یک سیستم نرمافزاری مواجه میشوند، یادداشتی درباره این خطا در پایگاه داده خطا در موضوع مربوطه ذخیره می شود. این اطلاعات شامل: علت و مکان وقوع خطا در برنامه و اینکه چگونه خطا باعث ایجاد اشکال و خلل در روند برنامه شده است. پس از آن یک یا چند متخصص، موضوع ایجاد شده را برای رفع مشکل بررسی می کنند. چنانچه خطا برطرف شود موضوع در فرم مربوطه بسته می شود. تمام این اطلاعات در مخازن و پایگاههای خطا ذخیره میشوند. عمومیترین سیستمهای مخازن خطا Bugzilla ، Trac هستند.
اگرچه تا به امروز سیستمهای متعددی ساخته شده اند. در حالت عادی بین خطا[۱۵]، نقص[۱۶]، عیب[۱۷] تفاوت قائل میشویم، اما در این تحقیق همه را با لفظ خطا و هم معنی در نظر میگیریم.
۳٫۲٫۲٫ لیست نامه ها و گفتگوهای ثبت شده
لیست ایمیلها (یا آرشیو بحثها) همراه با گفتگوهای ثبت شده بین افراد دخیل در یک پروژه آرشیوی از ارتباطات متنی توسعهدهندگان ، مدیران و ذینفعان آن پروژه هستند. لیست متنی متشکل از بستههای الکترونیکی که شامل سه قسمت:
سرآیند (فرستنده ،گیرنده و زمان ارسال)
بدنه پیغام(متن داخل ایمیل)
مجموعه ایاز فایلهای پیوستشده(مستندات اضافی که همراه ایمیل فرستاده می شود) میباشد.
شرح گفتگوها شامل ثبت مکالمات فوری بین ذینفعان پروژه، که بر حسب زمان یا نویسنده دستهبندی شده اند، میباشد.
۴٫۲٫۲ .پایگاه داده کنترل منبع (پایگاه داده کنترل ویرایش ها)
سیستمی برای ثبت تاریخ تغییرات (ویرایشها) بههمراه خود ویرایش و اطلاعات دیگر به صورت اسناد و اطلاعات متنی است. توسعهدهندگان معمولا تاریخ و زمان ویرایش یک کد اصلی را در پایگاه دادههایی ذخیره می کنند. پایگاه داده های کنترل کد رایج مانند] cvs 13[ و] svn 14[ ، به توسعه دهندگان اجازه می دهند به یک کپی از مخزن سراسری و جهانی، در سیستم فایلهای محلی خود، دسترسی داشته باشند. اسناد موجود را ویرایش کند، یا اطلاعاتی اضافه یا کم کند و یا ساختار دایرکتوری این مخازن را تغییر دهند. همچنین می تواند در مخزن اصلی سند یا اطلاعات جدید محلی ایجاد کند.
بنابراین کنترل بازبینیها دو نتیجه مهم در بر خواهد داشت:
اول اینکه به توسعهدهندگان اجازه میدهد، مستقل از کسانی که به مخازن دسترسی دارند، فایلهای روی سیستمهای خود را تغییر دهند . پس از آن که تغییرات تایید شده ایجاد شد بقیه میتوانند این تغیرات را بررسیکنند. این استقلال کاری اجازه میدهد که یک چرخه کار موازی بدون نیاز به ارسال ایمیل و گفتگو و نیز بدون تغیرات ورژن برنامه به عقب و جلو تشکیل شود.
دوم اینکه زمان و تاریخ همه اطلاعات و مستندات به صورت خودکار ثبت و نگهداری می شود. اگر نسخههای قبل نرمافزار نیاز بود، توسعهدهندگان بهراحتی میتوانند به نسخههای قبل سیستم دسترسی داشته باشند و سیستم را به نسخه قبلی برگردانند.
۵٫۲٫۲٫ اطلاعات طراحی و نیازمندیهای سیستم
مستندات نیازمندیها، معمولا در ارتباط با مشتری و یا با تاییدهای او تنظیم می شود. این اسناد لیستی از نیازهای مشتری است که خواهان انجام آن توسط سیستم است. این نیازها به دو صورت دستهبندی میشوند. اینکه چه نیازهایی را سیستم باید برطرف کند و چگونه و با چه کیفیتی موردانتظار مشتری است. اطلاعات طراحی نیز شامل تمام اطلاعات مربوط به طراحیمعماری و الگوریتمهای مهم و مورد استفاده[۱۸] سیستم است. طراحی سیستم می تواند به شکل نمودار(مانند UML) و یا به صورت متون جریان کار نمایش داده شوند.
۶٫۲٫۲٫ مخازن شرح اجرا
اطلاعات مربوط به خروجی یک برنامه در حین یک یا چند بار اجرا، بر حسب آن چه که در قسمت تست مشخص شده ثبت می شود. این اطلاعات شامل لیستی از زمان و دلیل اجرا شدن متدهای یک سیستم، مقادیر قطعی متغیرها و جزئیات مربوط به شرایط اجراست. این لیست هنگامی مفید است که فرایند اشکالزدایی در مقیاس وسیع همزمان با هزاران یا میلیونها فرایند دیگر از سوی افراد مختلف انجام شود. در این هنگام پیدا کردن اشکالات فردی لازم اما کاری دشوار و زمان بر است. این مخازن کمک می کنند به تک تک این اجراها با جزئیات دسترسی داشته باشیم.
۷٫۲٫۲٫ مخازن سیستم نرم افزار
مخازن سیستم نرمافزار شامل مجموعه ای از سیستمهای مختلف به همراه کد اصلی آنها که افراد علاقهمند میتوانند بهراحتی در آن جستجو کرده و از آنها استفاده نمایند. از مخازن مهم رایج در این حوزه میتوان به Source Forge ]15 [وGoogle Code ]16[ اشاره کرد.
این مخازن شامل آرایه وسیعی از اطلاعات در حوزه های مختلف پروژه های نرمافزاری است که میتوان اطلاعات غنی را در فازهای مختلف آن استخراج کرد. آنچه بهعنوان منابع داده در این تحقیق مورد استفاده قرار میگیرد همان مخازن خطا است. که با بهره گرفتن از یک سیستم ردیابی خطا نمونههای آماری لازم استخراج می شود]۱۷[.
۳٫۲٫ خطای نرمافزاری
اشکال نرمافزاری، خطا، نقص و یا شکست ایجاد شده در برنامه کامپیوتری است، که باعث تولید یک نتیجه نادرست یا غیرمنتظره می شود. یا باعث بروز رفتار ناخواسته از سیستم میگردد. رفع این مشکلات در پروژه های نرمافزاری از سختترین و پر هزینهترین مراحل مهندسی نرمافزار است. این خطاها می تواند در پروژه های بزرگ ومخصوصا پروژه های متن باز[۱۹] از سوی همه کاربران و توسعهدهندگان گزارش شوند. از این رو نرم افزارهای ردیابی خطا به کمک آمده تا بتوان این گزارشات را ثبت و پیگیری کرد. خاطر نشان میکنم که در این تحقیق همانطور که قبلا گفتیم مشکلات اعم از نقص، شکست یا خطا با عنوان خطای نرمافزاری معرفی می شود.
۱٫۳٫۲٫سیستم ردیابی خطا
سیستم ردیابی خطا یک برنامه نرمافزاری است که برای کمک در سهولت پیگیری خطاهای نرم افزاری در طول عمر پروژه طراحی و ارائه شدهاست. این سیستم یک نرمافزار کاربردی برای تیم توسعه است به طوری که به آنها در تضمین کیفیت و کاهش هزینه ها و پیشرفت سریع پروژه کمک می کند. این سیستمها به کلیه افراد دخیل در یک پروژه اعم از کاربران، توسعهدهندگان و ذینفعان دیگر اجازه میدهد که خطای رویت شده در نرمافزار را در هر مرحله از روند تولید که باشد گزارش داده و پیگیری کنند. بسیاری از پروژه های بزرگ از این نرمافزارها استفادهکرده و پروژه های خود را در نسخههای مختلف ارائه می دهند. تا در مراحل مختلف از ارائه نسخه جدید خطاهای نسخه قبلی که دیگران گزارش دادهاند پیگیری و رفع کنند. پروژه در هر حالتی ارائه شود، چه به صورت مرحله ای یا کامل، متنباز یا بسته و با هر متد استفاده شده در مهندسی نرمافزار ، یک سیستم ردیابی خطا در پیشبرد بهتر و سریعتر فرایند مهندسی نرمافزار بسیار ارزشمند است.
بسیاری از این نرمافزارها برای استفاده عموم طراحی شده و بقیه تنها برای استفاده در یک پروژه طراحی میشوند. معمولا سیستمهای ردیابی خطا با دیگر اپلیکیشنهای مدیریت پروژه یکپارچه و مجتمع میشوند]۱۸[. مهمترین قسمت این سیستمها مخازن اطلاعاتی آنهاست که کلیه اطلاعات مربوط به خطا را در خود ذخیره می کنند. باید دید در یک سیستم ردیابی خطا ایدهال چه اتفاقی میافتد و یک خطا چه چرخهای را در طول عمر خود در آن طی می کند. بهعنوان مثال باگزیلا[۲۰]یک سیستم ردیابی خطا است که در سال ۱۹۹۸ توسط تری ویسمن[۲۱] برای شرکت موزیلا[۲۲] نوشته شد.
در ابتدا باگزیلا بهعنوان یک سیستم ردیابی خطا متنباز از داخل خانه برای کاربران مرتبط با نت اسکیپ[۲۳] طراحی شد. ابتدا به زبان TCL[24] و سپس به Perl برای راحتی و سهولت استفاده و دخالت همگان در پیشرفت کار برگردانده شد. این سیستم برای استفاده در پروژه های متن باز بهینهسازی شد. به طوری که شرکتها و پروژه های بزرگی چون یاهو، ناسا،Gnome ، KDE ، Apache ، RedHat، ویکی مدیا و خود موزیلا از آن استفاده کردند هر خطا یک شناسه(ID)، عنوان، تاریخ، وضعیت، نام محصول و مولفه، میزان شدت سختی و پیچیدگی، اولویت و غیره را در خصوصیات خود دارد]۹ [(شکل۲-۱).
شکل۲- ۱-مشخصات یک موضوع (خطا)در نرم افزار Bugzilla
یک خطا از زمان ایجاد تا زمان بستهشدن(حل مشکل) چرخهای را در سیستم دارد(شکل۲-۲) نمودار فعالیت برای یک مخزن خطا در شکل۲-۳ نشان داده شدهاست.
شکل۲- ۲ - چرخه یک خطا در یک سیستم مدیریت خطا]۱۹[
شکل۲- ۳ – نمودار جریان کار[۲۵] یک سیستم ردیابی خطا
خطا جدید (NEW ) یا تایید شده وارد سیستم می شود(unconfirmed) اگر اعتبار خطا توسط یکی از اعضای تیم یا هسته مدیریتی تایید شد، بهعنوان یک گروه جدید ثبت می شود.
مدیران وکسانی که مسئول ارزیابی خطاها هستند باید وجود خطا را تایید کنند. اعتبار و غیرتکراری بودن آن را نیز بررسیکنند. اگر خطا تایید شد به قسمت تایید شدهها (Assigned) رفته، تا در اختیار تیم توسعه برای حل و فصل و رفع خطا قرار گیرد. در غیر این صورت به قسمت تایید نشده ( unconfirmed ) برای بررسی بیشتر میرود.
اگر خطا رفع شد برچسب حل شده ( Resolved ) خورده و آن را به وضعیت حل شده انتقال می دهند.
اعضای تیم ممکن است یک خطا حلشده را به یکی از حالتهای سازگار(Verified) و سپس بسته (Closed) اتصال دهند. یا دوباره به شکلی در رابطه با این خطا مواجه شدند و آن را به حالت دوباره باز یا تایید شده بفرستند.
خطاهایی که به مرحله Resolved بازگردانده میشوند یا نامعتبرند یا تکراری هستند و نیاز به بررسی مجدد دارند و یا به طور کامل رفع شده اند. چرخه عمر یک خطا از مرحله جدید تا مرحله خروج از حل تعریف می شود. شکل۲-۴ وظایف هر یک از اشخاص در ارتباط با مخزن خطا را نشان میدهد. دو کادر قرمز دردو نمودار شکل۲-۴ و شکل۲-۳ محدوده کاری این تحقیق را نشان می دهند.
شکل۲-۴- نمودار مورد کاربرد[۲۶] یک سیستم ردیابی خطا
همانطور که در شکل۲-۵ میبینید، یک خطا دارای مشخصات متنی است. برچسب، وضعیت خلاصه و در قسمت جزئیات توضیحات و راه حلهای ارائه شده با ذکر نام نویسنده و تاریخ برای هر خطا درج شده است. همین اطلاعات و متون ثبت شده دامنه کار تحقیقاتی ماست. این داده ها منبع غنی اطلاعات و دانش سودمند است. اینکه چگونه این داده ها را کاوش کنیم و چه اطلاعاتی در آنها نهفته است، گامهای تحقیق ما را میسازند. از آنجایی که این داده ها توسط افراد مختلف و با بهره گرفتن از قوانین نحوی صحیح و ناصحیح و گاه کلمات مشابه دریک حوزه استفاده شده اند نیاز به یک جستجو معنایی به شدت احساس میشوند.
شکل۲- ۵-مشخصات یک خطا
پایه و اساس این تحقیق جستجو جملات مشابه معنایی است. بهصورتی که آندسته از جملات که دارای تشابه معنایی بیشتری با جمله یا کلمه کاندیدای ما هستند، جداسازی شوند. چگونگی این کار در سه مرحله خلاصه می شود: ابتدا با بهره گرفتن از تکنیکهایی که در ادامه پیشنهاد می شود از میان داده های آماریکه از یک مخزن خطا انتخاب شده، میزان تشابه هر خطا (بر اساس داده های متنی مانند توضیحات، سرآمد، راهحل و غیره) با خطای جدید اندازه گیری می شود. در مرحله بعد این خطا با بهره گرفتن از یک الگوریتم خوشهبندی که سعی شده یک الگوریتم بهینه باشد به دستههای جدا بر اساس ضریب تشابه محاسبه شده تقسیم میشوند.
این کار به کاربر کمک می کند که نمونههای مشابه گزینش شده را در خوشههای طبقه بندی شده از نظر سختی و پیچیدگی کار در اختیار داشتهباشد.گاهی ممکن است کاربر خود بر اساس تجربه حدس بزند که مشکل زیاد پیچیده نیست. یا برعکس مشکل به زمان زیادی برای حل نیاز داشته باشد، در این حالت این خوشهبندی می تواند در کاستن زمان یافتن راهحل کمک قابل توجهی داشته باشد. آنچه این کار را از کارهای انجام شده قبلی متمایز می کند توجه به بهرهوری و بهبود کارایی است. یک مخزن خطا مجموعه ای گسترده و بزرگ از دادههاست که هر روز بزرگتر می شود. با بزرگ شدن نمونه آماری و نیاز به دقت در کار ابعاد پیچیدگی این عمل روشن خواهد شد. هدف اصلی این کار استفاده از تکنیکی است که دقت بالاتری داشته باشد. جستجو در یک بانک داده که متون در آن از قانون خاص برای رعایت اصول تحریر و قواعد نحوی استفاده نشده است، و کسانی که داده ها را ثبت کرده اند ممکن است از کلمات مشابه زیادی استفاده کرده باشند، نیاز بیشتری به یک جستجوی معنایی دارد.
۴٫۲٫تحقیقات پیشین در حوزه داده کاوی در مخازن خطا
در سال ۱۹۹۲ اولین نرمافزار ردیابی خطا GNATS[27] شروعی برای MSR بود. با ارائه اولین نرمافزار ردیابی خطا، مدیریت و استفاده از دانش نهفته در خطاها اولین قدمهای خود را برداشت. در این مدت محققان سعیکردند برای استخراج بهینه و مفیدتر دانش، مدلها و روشهای جدیدی با استفاده از الگوریتمهای مختلف ارائه کنند. بیشتر این روشها از الگوریتمهای دستهبندی برای دستهبندی اطلاعات و استفاده از دانش آنها به صورت طبقه بندی شده استفاده کردند. ابتدا مروری کوتاه بر تحقیقات قبلی و روش های بررسی شده خواهیم داشت. نواقص و کمبودهایی که به موجب آن ها این تحقیق انجام شده و روش ارائه شدهاست نیز بررسی خواهد شد.
سال ۲۰۰۰، JunzoWatada به منظور برآورد تعداد خطاها در یک پروژه نرمافزاری از رگرسیون فازی استفادهکرد]۶[. وی مجموعه سئوالاتی را برای استفاده در سیستم فازی در مراحل مختلف از یک پروژه مطرح کرد. در این روش تمام داده ها برای جستجو هدف قرار نمیگیرد و این خود ضعف بزرگی است.
Lucas D.Panger در سال ۲۰۰۷ مقایسه ای برای دستهبندی مخازن خطا با بهره گرفتن از پنج الگوریتم دسته بندی ۰-R ،۱-R، درخت تصمیم گیری C4.5 ،Naïve Bayes و رگرسیون لجستیک، در داده های گرفته شده از Bugzilla انجام دادهاست]۵[. این کار با محاسبه درصد خطاهایی که دستهبندی شده اند و ضریب Kappa برای هر کدام با بهره گرفتن از نرمافزار Weka انجام داده است. داده ها بر اساس طول عمروتوضیحات متنی دستهبندی شده اند. این تحقیق تنها مقایسه ای بین الگوریتمهای مختلف در یک دستهبندی ساده برای داده های موجود در یک مخزن است، که کمتر به شباهت بین یک خطا جدید و خطاهای دیگر پرداخته شده است.
