مقاله پیشنهاد یک مدل عمومی برای مهندسی نیازمندیهای جنبه گرا

بخشی از مقاله

پیشنهاد یک مدل عمومی برای مهندسی نیازمندیهای جنبه گرا

چکیده - مهندسی نیازمندیهای مؤثر باید لزوم دستیابی به تفکیک دغدغهها را با لزوم اجرای محدودیتها و نیازمندیهای حوزه وسیعی باهم تطبیق کند (وفق دهد). تکنیک هایی مثل موارد کاربری و دیدگاهها به دستیابی برای تفکیک دغدغههای ذینفعان کمک میکنند بدون اینکه سازگاری آنها را با نیازمندیهای سراسری و محدودیتها مطمئن کند. در این مقاله، یک مدل عمومی برای مهندسی نیازمندیهای جنبه گرا پیشنهاد میکنیم. این مدل تفکیک ویژگیهای وظیفهمندی و غیروظیفهمندی مداخلهای را در سطح نیازمندیها حمایت میکند. بحث میکنیم که تفکیک اولیه چنین ویژگیهای مداخلهای تعیین موثری از نگاشت و تأثیرشان روی محصول (اثر تصنعی) در مراحل توسعه بعدی را پشتیبانی میکند. تحقیق این مدل بر اساس مطالعه موردی یک سیستم جمعآوری عوارض ارائه شده است.

کلید واژه- مهندسی نیازمندی، دغدغه، موارد کاربری، دیدگاه، جنبه.

-1 مقدمه

تمرکز این مقاله روی دغدغههـایی اسـت کـه در تـداخل بـا دغدغههای دیگر میباشد. این دغدغههـای مداخلـهای مسـئول بــرای تولیــد نمــایشهــای پیچیــدهای هســتند کــه درک و نگهداریشان دشوار میباشند. مثالهایی از چنین دغدغـههـایی در سطح پیـادهسـازی، کـد همزمـان و توزیـعشـده هسـتند کـه نمیتوانند در یک کلاس کپسوله شـوند و بـه صـورت نمونـه در سرتاسر چندین کلاس پراکنده میشوند.

توسعه نرمافـزار جنبـه گـرا [3] تشـخیص و تعیـین چنـین دغدغههای مداخلهای در پیمانههای جداگانه را ارزیـابی مـیکنـد که به عنوان جنبـه هـا شـناخته شـدند، بطوریکـه محلـی سـازی میتواند ارتقا داده شود. این نتایج در حمایت بهتـر بـرای پیمانـه بندی است از اینرو هزینه نگهداری، تکامـل و توسـعه را کـاهش میدهد.

بــا توجــه بــه گســتردگی میــدان دغدغــههــای مداخلــهای، نیازمندیها از دیدگاهها به وجود مـیآینـد. در پیـادهسـازی ایـن روش، دغدغههایی که شناساییشدهاندعموماًیازمندی های غیـر وظیفهمندی سطح بـالا هسـتند. فراتـر از آمـاده بـودن مهنـدس نیازمندیها، خطری وجود دارد که ممکن اسـت نیازمنـدیهـای

جنبه و دغدغهها موجب ناسازگاری شوند، ایـن روش نگاشـت یـا تأثیر ویژگیهای مداخلـهای روی محصـول را در مراحـل توسـعه بعدی شناسایی نمیکند.

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

توضـیح جزیــی دربــاره اســتخراج نیازمنــدیهــا را ملاحظــه میکنید، نیازمندیهای جمعآوری شده ممکـن اسـت بـه جنبـه تبدیل شوند.

این مقاله شامل 5 بخش میباشد که به ترتیب زیر است: بخش اول: مقدمه در این بخش یک مقدمه از این تحقیق ارائه شده است.

بخـــش دوم: روشهـــای مختلـــف بـــه ســـمت مهندســـی نیازمندیهای جنبهگرا

بخش سوم: یک مدل برای مهندسی نیازمندیهای جنبه گرا بخش جهارم: بکار بردن مدل در مطالعه موردی بخش پنجم: نتیجهگیری و کار در آینده

در این بخش یک نتیجه گیری کلی و بـه صـورت خلاصـه از تمام بخشهای این مقاله انجـام مـیدهـیم، سـپس فرصـتهـای تحقیقاتی و کار در آینده متناسب با موضوع مورد تحقیق مـان را

1

پیشنهاد میکنیم.

-2 روشهای مختلف به سمت مهندسی نیازمندیهای جنبهگرا

بعد از معرفی شدن مهندسی نیازمنـدیهـای جنبـه گـرا در سال 1999 در مقاله آقای گراندی [2]، کارهـای زیـادی در ایـن حوزه انجامشده است که نقطه شروع آنهـا مقالـهای بـود کـه در کنفرانس مهندسی نیازمندیهای سال 2002 ارائه شد .[1] ایـن مقاله یک مدل عمومی برای مهندسی نیازمندیهـای جنبـه گـرا پیشنهاد داد و باعث پدیدار شدن یک دید اولیـه بـرای مهندسـی نیازمندیهای جنبه گرا شد.

با مشخص شدن اهداف و مزایای مهندسـی نیازمنـدیهـای جنبه گرا کارهای مختلفـی در ایـن زمینـه صـورت پـذیرفت کـه مهمترین آنها به شرح زیر هستند:

1. روش Cosmos کـــه در آن یـــک طـــرح مـــدلســـازی چندمنظوره برای دغدغه ها ارائه شده است .[3] در این روش یک تقسیم بندی از انواع دغدغه ها صورت پذیرفته است که جنبهها در یکی از این دستهبندیها قرار دادهشدهاند.

2. روش ARCADE که در آن نویسندگان، مدل مطرح شده در [1] را کاملتر کرده و روشهایی برای مشـخص کـردن شـیوه ترکیب و حـل تـداخل هـای مـابین جنبـه هـا پیشـنهاد داده انـد. همچنین همراه ایـن روش ابـزاری نیـز بـدین منظـور طراحـی و پیادهسازی شده است.

3. روشTheme/Doc که در آن از Theme و تحلیـل لغـوی برای مشخص کردن جنبهها استفاده شـده اسـت .[4] ایـن روش پیشنهادی علاوه بر ابزار، دارای نمادها و مفـاهیمی اسـت کـه بـه شناسایی جنبـه هـای پنهـان در سیسـتم کمـک مـیکنـد. روش Theme همچنین شیوهای برای تحلیل و طراحی ارائه میکند.

4. روش جداسازی چندبعـدی کـه در آن، روش چندبعـدی
برای مشخص کردن دغدغه ها و جنبهها پیشنهاد داده شده است. این روش علاوه بر پوشش اهداف مهندسی نیازمندیهـای جنبـه گرا، مکانیزمی برای مشخص کردن نقاط مصالحه برای فاز بعـدی (معماری) ارائه کرده است.

.5 روش توسعه نرمافزاری جنبه گرا با موارد کاربری [6] که در آن از قابلیتهای موارد کاربری برای مشخص کردن جنبـه هـا استفاده شده است. در این روش، دو مفهـوم تحـت عنـوان بـرش موارد کاربری و ماژول موارد کـاربری معرفـیشـده انـد کـه کلیـه فرآیندهای مهندسی نیازمندیها و معماری جنبـه گـرا پیرامـون

این دو مفهوم حرکت میکنند.

-3 یک مدل عمومی برای مهندسی نیازمندیهای جنبهگرا

اصل تفکیک دغدغـههـا [20] کپسـوله کـردن ویژگـی در موجودیتهای جداگانه برای رسیدن به محلی کردن تغییـرات و مواجه با یک مسئله مهم را در زمان پیشنهاد میکند . بـه عنـوان مثال UML از مدل های مختلفی استفاده میکند تا ویژگیهـای مختلفی از حوزه یک مسئله را به صورت جداگانه رسیدگی کنـد. در مهندســی نیازمنــدیهــا، دیــدگاه [12] توانــایی جــزء بنــدی نیازمندیها را به عنوان مجموعه ای از مشخصات جزیـی حمایـت میکند که به قابلیت ردیابی و مدیریت سازگاری کمک میکنـد (که به خطایابی و ثبات مدیریت کمک میکند).

تمرکز این تحقیق روی دغدغههایی است کـه در تـداخل بـا دغدغههای دیگر میباشد. ایـن دغدغـههـای مداخلـهای مسـئول بــرای تولیــد نمــایشهــای پیچیــدهای هســتند کــه درک و نگهداریشان دشوار میباشند. مثالهایی از چنین دغدغـههـایی در سـطح پیـادهسـازی کـد همزمــان و توزیـعشـده هسـتند کــه نمیتوانند در یک کلاس کپسـوله شـوند و بـه صـورت نمونـه در سرتاسر چندین کلاس پراکنده میشوند.

توسعه نرمافزار جنبه گـرا [11] تشـخیص و تعیـین چنـین دغدغههای مداخلهای در پیمانههای جداگانه را ارزیـابی مـیکنـد که به عنوان جنبـه هـا شـناخته شـدند، بطوریکـه محلـی سـازی مــیتوانــد ارتقــا داده شــود. ایــن نتــایج در حمایــت بهتــر بــرای پیمانهبندی است از اینرو هزینه نگهـداری ، تکامـل و توسـعه را کاهش میدهد.
بسیاری از روشهای برنامهنویسی جنبه گرا مطرحشدهاند. از مکانیزم زبانی [7] تـا تکنیـکهـای مبتنـی بـر فیلتـر [11] در روشهای پیمایش گرا [11] و چندبعدی 17]،[19 میتـوان نـام برد. این کار همچنین انجامشده تا جنبهها را متحد و یکی کند و از اینرو تفکیک دغدغههای مداخلهای در سطح طراحیاساسـاً از طریق گسترش مدل UML میباشد .[9]
تحقیق روی کاربرد جنبهها در فـاز مهندسـی نیازمنـدیهـا هنوز بیتجربه است و توافقی درباره اینکه یـک جنبـه در مرحلـه اولیه توسعه نرمافزار و نگاشت آن به محصول در مراحـل توسـعه بعدی چگونه است وجود ندارد.
هدفگذاری روش مهندسی نیازمندیهای جنبـه گـرا بـرای توسعه سیستم مبتنی بر مؤلفه در [13] مطرحشـده اسـت، یـک

2

توصیف صفات اختصاصی از جنبههای مختلف سیستم وجود دارد که هر مؤلفه بـرای کـاربران نهـایی یـا مؤلفـههـای دیگـر فـراهم میکند. بهر حال شناسایی جنبهها بـرای هـر مؤلفـه بـه صـورت واضح تعریف نشده است. تفکیک ویژگیهای مداخلهای همچنین در [18] مطرحشده که روش مهندسی نیازمندیهای دیدگاه گـرا را پیشنهاد میکند که پیشنمایش (PreView) نامیده مـیشـود. دیـدگاه PreView اطلاعــات جزیــی دربــاره سیســتم را کپســوله میکند. نیازمندیها در غالب چندین دیدگاه سـازمانیافتـه انـد و تجزیه و تحلیلها در برابر یـک مجموعـه از دغدغـههـای کاندیـد هدایت شده تا به طور وسـیع در سرتاسـر اهـداف سیسـتم رابطـه داشــته باشــند (برابــر باشــند). بــا توجــه بــه گســتردگی میــدان دغدغه های مداخله ای، نیازمندیها از دیدگاه ها به وجود میآینـد. در پیاده سازی این روش، دغدغه هایی که شناسایی شده اندعمومـاً نیازمندیهای غیر وظیفه مندی سطح بالا هستند. فراتر از آمـاده بودن مهندس نیازمندیها، خطری وجود دارد کـه ممکـن اسـت نیازمندیهای جنبه و دغدغههـا موجـب ناسـازگاری شـوند، ایـن روش نگاشت یا تأثیر ویژگیهای مداخلـه ای روی محصـول را در مراحل توسعه بعدی شناسایی نمیکند.

توصیف بالا لزوم گنجاندن جنبه هـا بـه عنـوان مـدل سـازی بنیادی اولیه در سطح مهندسی نیازمندیها را مشخص مـیکنـد. دو انگیزه برای این کار وجود دارد:

-1 تهیه پشتیبانی پیشرفته برای تفکیک ویژگیهای وظیفـه منــدی و غیــر وظیفــه منــدی مداخلــهای در طــول مهندســی نیازمندیها سپس وسیله (توانـایی) بهتـری را بـرای شناسـایی و مدیریت برخوردهای (ناسازگاریهـای) بـه وجـود آمـده ناشـی از نمایش پیچیده پیشنهاد میکند.
-2 شناسایی نگاشت و تأثیر جنبههـای سـطح نیازمنـدیهـا روی خروجی (محصول مصنوعی) در مراحل توسعه بعدی سـپس ایجاد تعادل حیاتی (بحرانی) قبل از معماری به وجود آمده است.

سیستم های مدرن باید در محیطهای خیلی حساس و فـرار اجرا شوند جایی که قوانین کسبوکار به سرعت تغییر مـیکننـد؛ بنابراین سیستمها میبایست به آسانی قابل سـازگاری و اسـتنتاج باشند. اگر به درستی مدیریت نشوند، دغدغههای مداخلهای مـانع سازگاری میشوند؛ بنابراین ضروری است که درباره دغدغه هـای مداخلهای هرچه سریع تر فکری شود. مدلی که ما برای مواجه بـا دغدغههای مداخلهای در سطح نیازمندیها در نظر داریم از شش فعالیت تشکیل شده است (شـکل.(1 ایـن مـدل بـر مبنـای رفـع دغدغههای PREVIEW بـه عنـوان سـازگاری مفهـوم جنبـه در

برنامهنویسی جنبهگرا میباشد.

شکل-1 مدل مهندسی نیازمندیهای جنبه گرا

برای شـروع، مـا نیـاز بـه شناسـایی دغدغـه هـا و اسـتخراج نیازمندیها داریم. ترتیب انجام شدن در این دو فعالیت به پویایی تعامل بین مهندسان نیازمندی ها و ذینفعان وابسته است. در هـر صورت، ارتباط دغدغه ها با نیازمندیها مفیـد اسـت. گـام بعـدی تعیین دغدغهها با جزییات بیشتر میباشـد. اگـر یـک دغدغـه بـا چندین نیازمندی تداخل داشته باشد (به عنوان مثال یک دغدغه ممکن است روی بیش از یک دیـدگاه تـأثیر بگـذارد) بـه عنـوان جنبه کاندیـد مطـرح مـی شـود. ایـن مرحلـه اسـتخراج جزئیـات جنبههای کاندید میباشد. ایـن کـار، مـا را بـه تصـحیح (خـالص کردن) جنبههـا، متمرکـز کـردن آن هـا و شناسـایی تعامـل هـا و برخوردهای (ناسازگاری های) بین آنها سوق میدهد .[15] برای رفع مشکل برخورد در میان جنبـه هـا، روشهـای الویـت بنـدی استفاده میشوند. گام آخر در مدل، شناخت ابعاد جنبه می باشـد. ما مشاهده میکنیم که جنبهها در این مراحـل اولیـه مـی تواننـد دارای تأثیر باشند که میتوان در دو بعد آن را توصیف کرد:

· نگاشــت: یــک جنبــه مــیتوانــد بــر روی یــک سیســتم ویژگی/وظیفــه منــدی (مثــل یــک روش ســاده)، یــک تصمیم (مثل یـک تصـمیم بـرای انتخـاب معمـاری) و طراحی (در نتیجه پیاده سـازی و اجـرا)، جنبـه (زمـان پاسخ) نگاشت شود. این دلیلی است که ما جنبـه هـا را در مرحله مهندسی نیازمندی ها به عنوان جنبه کاندیـد بنامیم. با وجود تداخل ذاتی آنها در این مرحله، آنهـا شاید نتوانند به طـور مسـتقیم بـه روی یـک جنبـه در مراحل بعدی نگاشت شوند.

· تأثیر: جنبه می تواند در نقاط مختلفی از چرخـه توسـعه

تأثیر بگذارد. مثل قابلیـت دسترسـی کـه مـی توانـد در

3

معماری سیستم تأثیر بگذارد، هنگامی که زمـان پاسـخ بر هردوی معماری و جزئیات طراحی تأثیرگذار است.
توجه کنید که الویت بندی جنبهها باید جلوتر از شناسـایی ابعـاد آن ها به عنوان راه حل برخورد (ناسازگاری) صورت گیـرد، چـون امکان دارد که هنگام مشخص کردن تأثیر مورد نیاز باشد.

-4 بکار بردن مدل در مطالعه موردی

مطالعه موردی یک نسخه سادهشـده از سیسـتم جمـعآوری عوارض در بزرگراههای کشور میباشد :[8]

»در سیســتم قیمــتگــذاری ترافیــک جــادهای، راننــدگان خودروهای مجاز به صورت اتوماتیک در دروازههای عوارض هزینه را پرداخــت مــیکننــد. ایــن دروازههــا در مســیرهای خاصــی واقعشدهاند که مسیرهای سبز نامیده میشوند. راننده بایـد یـک دســتگاهی بــه نــام Gizmo را در خــودرویش نصــب کنــد. ثبــت خودروهای مجاز شامل اطلاعات شخصی مالکان، شـماره حسـاب بانکی و مشخصات خـودرو مـیشـود. Gizmo اطلاعـات را بـرای مشتری ارسال مـیکنـد کـه اسـتفاده از ATM را فعـال کنـد تـا سیســتم، فعــالســازی Gizmo را اطــلاع دهــد. Gizmo توســط سنسورهای دروازه عوارض خوانده میشود. اطلاعات خوانده شـده توسط سیستم ذخیره و استفاده میشوند تا میزان عوارض حساب مربوطه محاسبه شود. وقتی یک خودرو مجاز از مسیر سبز عبـور میکند، چراغ سبزی روشن میشود و میزان عوارض نمایش داده میشود. اگر یک خودرو غیرمجاز از آن عبور کند، یک چـراغ زرد روشن میشود و دوربین یک عکس از پلاک میگیرد (برای پیـدا کردن مالک خودرو استفاده میشود).

سه نوع دروازه عوارض وجود دارند:
· انتخاب عوارض: خودروهای مشابه مبلغ ثابتی را پرداخـت مینمایند.

· ورودی عوارض: وارد شدن به بزرگراه

· خروجی عوارض: ترک کردن آن

میزان پرداختی در بزرگـراه بـه نـوع خـودرو و مسـافتی کـه پیموده شده است بستگی دارد.

برای کمک به شـناخت دغدغـههـای مداخلـهای مـا از ابـزار استخراج نیازمنـدیهـای JPREView اسـتفاده کـردیم. در ایـن روش، دیدگاه ها از طریق یک الگو مشخص شـده انـد. یـک الگـوی دیدگاه عبارت است از نام دیدگاه، مرکز، یـک لیسـت انتخـابی از زیر دیدگاه ها، یک لیست از دغدغه ها و یک لیست از نیازمندیها. دغدغه ها به وسیله استنتاج کردن یک مجموعه از نیازمندیها به

زحمت درست شده انـد کـه مـا آن هـا را نیازمنـدیهـای خـارجی مینامیم.

روش مـا بـه دیـدگاههــا محـدود نمـیباشــد. مـا مـیتــوانیم نیازمندیهای هدف گرایی که دغدغههـای وظیفـه منـدی و غیـر وظیفــه منــدی را پوشــش مــیدهنــد را اســتفاده کنــیم [16]، روشهای مبتنی بر سناریو یا موارد کاربری را به وسیله مشـخص کردن هر کدام از آن ها استفاده کنیم، سناریو ها موارد کاربری که به وسیله دغدغهها در تداخل هستند را استفاده کنیم، مسـئلهای که میتواند به عنوان دغدغهها دیده شود را بیان کنیم .[14]

-1-4 شناسایی دغدغهها

دغدغههـا توسـط بررسـی نیازمنـدیهـای اولیـه شناسـایی میشوند. برای مثال، از آن جـایی کـه صـاحب خـودرو اطلاعـات بانکی خود را برای ثبت نام نشان میدهد، امنیت موضـوعی اسـت که سیستم نیاز دارد تا تأمین کند. دغدغههـای دیگـر در مطالعـه مــوردی (موضــوع مــورد بحــث) مــا کــه بــا روشهــای مشــابه شناساییشدهاند عبارتاند از: زمان پاسخ، سیستم چند کـاربری، سازگاری، مسائل قانونی، صحت و قابلیت دسترسی.

-2-4 مشخص کردن (تعیین) دغدغهها

برای سهولت ما تنها تعیین دو دغدغه را انتخـاب مـیکنـیم: سازگاری و زمان پاسخ. هدف از ایـن انتخـاب نشـان دادن دامنـه ابعاد است.

دغدغه: سازگاری

نیازمندی های خارجی:

-1 کاربران با استفاده از ATM، Gizmo را فعال خواهند کرد.

-2 پلیس با خودروهایی که از سیستم Gizmo استفاده نمیکنند برخورد میکند.

دغدغه: زمان پاسخ

نیازمندی های خارجی:

(1 دروازه عوارض باید به موقع واکنش نشان دهد در نتیجه:

1-1 شناسه Gizmo را می خواند.

2-1 چراغ را روشن می کند (سبز یا زرد) قبل از این که راننده منطقه دروازه عوارض را ترک کند.

3-1 مقدار عوارض را قبل از اینکه راننده منطقه دروازه عوارضی را ترک کند، نشان می دهد.

4