بخشی از مقاله
ارزيابي و مقايسه تکنيک هاي عامل گراي MESSAGE و TROPOS با سه ديدگاه مختلف
چکيده
تکنولوژي عامل گرا يکي از پيشرفت هاي جديد در تکنولوژي نرم افزار کامپيوتر مي باشد و به طور گسترده در چند سال اخيـر رشـد نموده است . اين تکنولوژي به بررسي فعل و انفعالات بين عامل ها و محاسبات مبتني بر عامل مي پردازد . تکنولوژي عامل گـرا داراي متدولوژي هاي فراواني مي باشد اما هيچ کدام از آن ها به اندازه کافي ، به طور کامل و جامع از توسعه سيستم هـاي مبتنـي بـر عامـل پشتيباني نمي کنند. ارزيابي و مقايسه متدولوژي ها و شناخت نقاط قوت و ضعف آن ها، نقش مهمي در انتخاب و همچنـين پيشـرفت آن ها و توسعه ي نسل بعدي متدولوژي ها ايفا مي کند. در اين مقاله قصد ما مشخص نمودن نقاط قوت و ضعف متدولوژي هـاي عامـل گرا MESSAGE و TROPOS از سه ديدگاه ايجاد کنندگان متدولوژي ، افراد داراي تجربه عملي استفاده از متـدولوژي کـه در قالـب تحقيق بيان شده و افراد خبره مي باشدکه در قالب يک چارچوب ارزيابي بيان مي شود.اين چارچوب چهار ناحيه عمـده متـدولوژي مهندسي نرم افزار عامل گرا شامل مفاهيم و ادراکات ، زبان مدل سازي ، فرآيند و عمل گرايي را در بردارد. با تحليل متـدولوژي هـاي عامل گراي MESSAGE و TROPOS نقاط قوت و ضعف آن ها بر اساس روش ها و معيارهاي ارزيابي ، بدست مي آيد. همچنين تشابه و تفاوت هاي آن ها در رابطه با تکنيک ها و مدل ها، مورد بررسي قرار مي گيرد.
کلمات کليدي
مهندسي نرم افزار عامل گرا، عامل ، متدولوژي ، MESSAGE،TROPOS
١- مقدمه
از ١٩٨٠ به بعـد تکنولـوژي عامـل P١ مـورد توجـه شـديد انجمـن هـاي تحقيقاتي و تجاري قرار گرفت . سـپس در آخـرين دهـه قـرن بيسـتم ، زبان ها، معماري ها و تئوري هاي متفاوت عامل ها و نيز متـدولوژي هـاي عامل گرا توسعه يافت . اين رشد در تکنولوژي عامل هـا اساسـاً ناشـي از پتانسيل آن براي بهبود توسعه سيستم هاي پيچيـده و بـا کيفيـت بـالا باشد. در اين زمان تعداد زيادي متـدولوژي بـر حسـب زمينـه هـاي مختلف تئوري مانند P٢P1F OO و P٣P2F KB ارائه شد[١]. امروزه دامنه وسيعي از مدل هاي مهندسي نرم افزار (مانند برنامه نويسي ساختاري ، مدل هاي شي گرا، روش هاي بر اساس مؤلفه و ...) با هـدف ايجـاد تسـهيلاتي در پروسه مهندسي براي توليد نرم افزار يا کاهش پيچيـدگي کاربردهـايي که مي توانند ساخته شوند، مطرح مي باشد. در حـالي کـه هـيچ کـدام از مدل هاي جاري مهندسي نرم افزار نمي توانند به طور کامـل تکنولـوژي نرم افزار را با نيازهاي تجاري هماهنگ کنند، مهندسي نرم افزار عامـل گرا به عنوان مدل قدرتمند جديد در سيسـتم هـا و محاسـبات پديـدار گشته است . هدف اصلي آن ايجاد متدولوژي ها و ابزارهـايي اسـت ، کـه توسعه و پشتيباني از نرم افزارهاي مبتني بـر عامـل هـا را معقـول و بـه صرفه نمايد ٢]. مفاهيم متدولوژي ها و ابزارها، از مدل هاي عامل ، يکي از مناسب ترين کانديدها براي پايه گذاري نسل بعدي سيستم هـاي نـرم افزاري مي باشد ٣]. در حقيقت مهندسي نرم افـزار عامـل گـرا مرحلـه بعدي در سير تکاملي مهندسي نرم افـزار اسـت ، کـه قـدرت و مزايـاي تکنيک هاي ديگـر مهندسـي نـرم افـزار ماننـد شـي گرايـي را افـزايش مي دهد. مهندسي نرم افزار شي گـرا نمـي توانـد خاصـيت هـاي مشـابه عامل ها از قبيل هوشمندي و انعطاف پذيري ، ارتباطات و قدرتمند بودن را در محيط هاي پيچيده ، پويا و محيط هـاي حسـاس و توزيـع شـده و اينترنت داشته باشـد[٤]. يکـي از اساسـي تـرين مسـائل در تکنولـوژي عامل ها فقدان متدولوژي توسعه نرم افزاري کامل ، براي سيستم هاي بـر اساس عامل مي باشد. گرچه تعداد زيادي متدولوژي AOSE3PF٤P پيشـنهاد شده است با اين حال تعداد کمي از آن ها کامل مـي باشـند (منظـور از کامل بودن ، پوشش همه ي فعاليت ها در مهندسي نرم افزار مـي باشـ ).
هيچ کدام از آن ها به طور کامل ، نيازمنـدي هـاي توسـعه سيسـتم هـاي مبتنـي بـر عامــل را پشـتيباني نمــي کننـد. گرچــه دامنـه وســيعي از متدولوژي هاي بـر اسـاس عامـل قابـل دسـترس هسـتند امـا کمبـود مطالعات مناسب و ارزيابي و مقايسه متدولوژي هـاي موجـود احسـاس مـي شـود[٥] ٦][٧].بـا بررسـي انـواع ارزيـابي هـاي انجـام شـده روي متدولوژي هاي عامل گرا در مي يـابيم کـه فقـدان روش سيسـتماتيک ، براي ارزيابي متدولوژي ها، وجود دارد. يعني مقايسه بين دو متدولوژي صورت مي گيرد، ولي هنوز ارزيابي روشـني از ايـن متـدولوژي هـا و يـا ايجاد تکنيک هايي براي انجام ارزيابي صورت نگرفته است . البته بعضـي مقايسه ها توسط ايجاد کنندگان متدولوژي ها صورت گرفته ، ولي نقـاط قوت و ضعف متدولوژي را مشخص نمي نمايـد و از طرفـي مـورد وثـوق منبع بي طرف نمي باشند، بعضي از مقايسه ها نيـز کامـل نمـي باشـند و همه ي معيارها را در نظر نمي گيرند. در اين مقاله بيشتر کوشش خود را روي ارزيابي تحليلي متدولوژي ها و نتايج آن معطـوف مـي نمـاييم . در قسمت اول اين مقاله مقدمـه اي از مهندسـي نـرم افـزار عامـل گـرا و کارهاي صورت گرفته در اين حيطه مطرح گرديد. در ادامه به توصـيف متــدولوژي MESSAGE و TROPOS مــي پــردازيم . در قســمت چهارم ، ارزيابي اين دو متدولوژي بر اسـاس پارامترهـاي بسـتر ارزيـابي ارائه شده در اين مقاله انجام شده است .
٢- متدولوژي MESSAGE
هدف اصلي متدولوژي MESSAGE توسعه يک متدولوژي عامل گرا به عنوان گسترش متدولوژي هاي موجود ( ,GAIA, AUML, MAS common KADS) براي پشتيباني از AOSE مي باشد. مدل چرخه حيات متدولوژي MESSAGE از RUP براي توسعه نرم افزار استفاده مي نمايد، که چارچوب چرخه حيات براي متدولوژي هاي مهندسي نرم افزار عمومي مي باشد. وضعيت جاري متدولوژي MESSAGE محدود به فعاليت هاي تحليل و طراحي مي شود. فازهاي ديگر چرخه حيات RUP مانند پياده سازي ، تست و استقرار براي آن توصيف نمي شود.
اين امر ناشي از محدوديت هاي زماني و منابع پروژه مي باشد. همچنين اين متدولوژي به صورت کامل عامل گرا نيست . UML به عنوان پايه ايي براي زبان مدل سازي MESSAGE انتخاب شده است و به وسيله مفاهيم ارتباطات و موجوديت هاي لازم براي مدل سازي عامل گرا گسترش يافته است [ ]. MESSAGE متدولوژي است که به طور خاص براي نيازهاي صنعت ارتباطات راه دور توسعه داده شده است . با اين حال اغلب جنبه هاي اساسي توسعه چند عاملي را تحت پوشش قرار مي دهد و مي تواند، به عنوان يک متدولوژي عمومي قابل کاربرد در دامنه هاي ديگرمانند تجارت الکترونيک به خوبي مورد استفاده قرار گيرد [١٠].
٢-١) مرحله تحليل
تحليل عامل گرا مجموعه زيادي از مفاهيم را شامل مي شود و اين موضوع فهم همه ي جنبه هاي مدل تحليل را از ديدگاه خاص ، مشکل مي سازد. به همين دليل بهتر است ، تعدادي ديدگاه که روي جنبه هاي مختلف مدل کامل ، تاکيد دارند، تعريف شود. اين ديدگاه ها جنبه هاي مختلفي را در بر مي گيرند اما به خودي خود کامل نيستند بنابراين با کنار هم قرار دادن آن ها، يک ديدگاه کامل و فابل فهم حاصل مي شود. اصولاً متدولوژي MESSAGE بر اساس روش ديدگاه گرا توسعه داده مي شود. مدل تحليل به کمک پنج ديدگاه مختلف توصيف مي شود. اين ديدگاه ها عبارتند از[١٠]:
الف ) ديدگاه سازماني : اين ديدگاه موجوديت هاي واقعي و سازنده شامل عامل ها، سازمان ها، نقش ها و منابع را در سازمان ها و محيط هاي عملياتي نشان مي دهند. همچنين روابط ميان اين موجوديت ها در سطح بالا نمايش داده مي شود. ب ) ديدگاه هدف . عمل : اين ديدگاه ساختار اهداف را نشان مي دهد. يعني نحوه تجزيه يک هدف به زير هدف ها را مشخص مي کند. به علاوه چگونگي اجراي اعمال توسط عامل ها يا نقش ها، براي رسيدن به اهداف را بيان مي کند. يعني اين ديدگاه اهداف ، اعمال و وابستگي آن ها را نمايش مي دهد. ج ) ديدگاه عامل . نقش : بر خلاف ديدگاه سازماني که کل ساختار سيستم را ارائه مي نمايد، اين ديدگاه روي عامل هاي منفرد و نقش ها متمرکز است . اين متدولوژي از يک شمّا PPF٤، همراه نمودارهايي براي تعريف ويژگي هاي نقش ها يا عامل ها استفاده مي کند. اين چنين ويژگي هايي اهدافي که يک نقش . عامل نيازمند رسيدن به آن است را شامل مي شود. اين اهداف منابعي که مي تواند مورد استفاده قرار دهند، را دريافت مي نمايد.
د) ديدگاه تعامل : اين ديدگاه محدوديت ها و تعامل هاي ميان عامل ها يا نقش ها را نشان مي دهد و شامل چندين نمودار مي باشد. در اين نمودارها، بخ هايي که در ارتباط با هم مي باشند، توصيف شده و نيز اطلاعات ديگر مانند انگيزه ، ارتباط ميان آن ها و حوادثي که باعث ايجاد ارتباط شده ، نمايش داده مي شود. بعلاوه اطلاعات مرتبط که هر قسمت در طول ارتباط ، رد و بدل مي نمايد، مشخص مي گردد. ه ) ديدگاه دامنه :
اين ديدگاه ، مفاهيم خاص و ارتباطات مربوط به دامنه ي سيستم تحت توسعه را نشان مي دهد. توسعه دهنده متدولوژي MESSAGE مجبور به رعايت ترتيب خاصي به منظور ساختن پنج ديدگاه فوق نيست و اين متدولوژي رهنمودهايي را در اين زمينه ارائه مي دهد.
٢-٢) مرحله طراحي
در مقابل فاز تحليل که پروسه مراحل آن ، به روشني تعريف مي شود،
مرحله طراحي MESSAGE به خوبي مستند نشده است [١١].
MESSAGE پنج مرحله طراحي را براي فرآيند انتقال ارائه دهد[١٠ [١١]: در اولين مرحله ، همه موجوديت هاي تعريف شده در فاز تحليل ، بررسي مجدد و تحليل مي موجوديت هاي می شوند و به محاسباتي که شامل کلاس ها، رابط ها و ويژگي هاي متدها هستند، منتقل مي شوند. طبق متدولوژي MESSAGE اين مرحله مي تواند با استفاده از تکنيک هاي مهندسي نرم افزار رايج مانند توليد و پالايش ، مورد کاربر و نمودار توالي انجام گيرد. به هر حال اين متدولوژي هيچ مثال يا تکنيکي براي شرح بيشتر نحوه انجام آن ارائه نمي دهد. در مرحله دو، طراح بايد در مورد معماري عامل که مي خواهد استفاده کند، تصميم گيري نمايد. اين تصميم گيري بسيار مهم مي باشد زيرا روي فعاليت هاي ديگر طراحي اثر مي گذارد. MESSAGE طراحان را در جستجوي معماري پيشنهادي ياري مي دهد. بر طبق متدولوژي MESSAGE، چندين فاکتور ممکن است براي تعيين معماري عامل موثر باشد. يکي از آن ها عمليات در نظر گرفته شده ، شامل عمليات سيستم که در فاز تحليل تعريف شده است ، مي باشد. پس از انتخاب معماري عامل ، طراح وارد مرحله ي بعدي مي شود که در آن کاربرد هاي عامل ايجاد مي شود. اين عامل ها، معماري انتخاب شده براي نقش ها در سيستم را مشخص مي کنند. اين مرحله از فاز طراحي ، اجازه اين فعاليت ها را مي دهد. به هر حال سازگاري و همبستگي ميان فاز تحليل و ساختارهاي طراحي شديدً ا نياز مي باشد. در نهايت نتايج از مراحل قبلي بر اساس ديد ساختاري ، سازماندهي مي شود. اين مرحله داراي اهميت مي باشد زيرا نمايش معماري از سيستم بر حسب گروه عامل ها ارائه مي شود. روش فوق خيلي با طراحي سطح بالا (ترتيب فازها از بالا به پايين ) در ساختارهاي طراحي مستقل از بستر مرتبط مي باشد. MESSAGE همچنين روش ديگري را ارائه مي دهد که شامل طراحي سيستم مقصد در سطوح پايين مي باشد که به طور کامل مستقل از بستر نيست . در واقع در اين سطوح ، بستر عامل داراي تأثير بزرگتري در تصميمات طراحي مي باشد.
٣) متدولوژي TROPOS
TROPOS يک متدولوژي توسعه نرم افزاري عامل گرا مي باشد که توسط گروهي از محققين و توسعه دهندگان از دانشگاه هاي مختلف کانادا و ايتاليا ايجاد شده است . TROPOS از چارچوب مدل سازي Eric Yc'SI به دست آمده است . سمبل هاي کنشگرها، اهداف و وابستگي ميان آن ها را پيشنهاد مي کند و به عنوان چارچوبي براي نيازهاي اوليه ، ثانويه ، طراحي معماري و طراحي تفصيلي به کار مي رود[١٢]. TROPOS بر اساس سه ايده اصلي مي باشد[١٣]:
الف ) تصور و درک عامل و همه تصورات ذهني مرتبط ( براي مثال اهداف ، برنامه ريزي ها و ...) که در همه ي فازهاي توسعه نرم افزار از تحليل اوليه تا پياده سازي حقيقي مورد استفاده قرار مي گيرد و از معماري عامل PBDIPF٥ استفاده مي کند. ب ) TROPOS همه ي فازهاي اوليه تحليل نيازمندي ها را پوشش مي دهد و بنابراين فهم عميق تري از محيطي که نرم افزار بايد در آن پياده شود و انواع تعامل ميان نرم افزار و عامل انساني را فراهم مي آورد. ج ) اين متدولوژي روش انتقالي براي ساخت مدل هاي سيستم را ، به طور تکراري و بر اساس سطوح ادراکي به محصولات اجرايي ، ارائه مي دهد. اين کار از طريق پالايش و گسترش صورت مي گيرد .
مشابه ديگر متدولوژي هاي AOSE اين متدولوژي مفاهيم مرتبط با عامل ها مانند اهداف ، برنامه ريزي ها و اعمال را در همه ي فازهاي توسعه در بر دارد. يکي از تفاوت هاي عمده ميان TROPOS و ديگر متدولوژي ها تمرکز قوي اين متدولوژي روي تحليل نيازمندي هاي اوليه مي باشد، که در آن مرز دامنه و اهداف سيستم مشخص و تحليل مي گردد[٢٥].
٣-١) مرحله تحليل
فاز تحليل در TROPOS به دو فاز اصلي شکسته مي شود[١٣]: الف ) تحليل نيازمندي هاي اوليه ، ب ) تحليل نيازمندي هاي ثانويه نيازمندي هاي اوليه : هدف اصلي تحليل نيازمندي هاي اوليه ، فهم سيستم و مشخص نمودن دامنه و مقاصد آن مي باشد. يعني اهداف و مرز بندي سيستم را مشخص مي کند. TROPOS مفاهيم اهداف و کنشگرها را براي مدل نمودن ، اهداف و مرز بندي سيستم ، به طور مرتبط استفاده مي کند. در TROPOS اهداف به دو گروه مختلف تقسيم مي شوند: ١) اهداف سخت : مرتبط با نيازمندي هاي عملياتي مي باشند. ٢) اهداف نرم : مرتبط با نيازمندي هاي غير عملياتي مي باشند. هيچ معياري براي تصميم گيري و انجام آن ها وجود ندارد.
متدولوژي TROPOS سه تکنيک اصلي براي تحليل اهداف و طرح ريزي ها ارائه مي دهد[١٣][١٤]:
. تحليل معنا- هدف PPF٦ : تکنيکي براي پالايش اهداف مي باشد و شامل شکستن يک هدف به زير اهداف مي باشد. به طوري که برنامه ريزي ها، منابع و هدف هاي نرم افزاري ، ابزارهايي براي به انجام رساندن هدف ، تعريف نمايند.
. تحليل همکاري : مطالعه ي تعامل ميان اهداف مي باشد. يعني چطور يک هدف خاص به طور مثبت يا منفي بر روي اهداف ديگر اثر مي گذارد. کشف اهداف طرح ريزي ، توسط منابعي که مي تواند به طور مثبت يا منفي براي انجام اهداف ( اجراي طرح ها) مورد استفاده قرار گيرند صورت مي پذيرد.
. تجزيه هدف . طرح ريزي : براي ترکيب يا تجزيه هدف هاي اصلي به زير هدف ها به کار مي رود. اين تکنيک بر اساس تکنيک هاي تجزيه OR .AND اجرا مي شود.
نمودار کنشگر (اثر متقابل عامل ها بر يکديگر) و نمودار اهداف دو مدل مجزا براي TROPOS نيستند. هر چند توصيف تفصيلي تر براي هر کنشگر در قالب نمودار کنشگرها عرضه مي شود[١٣]. به علت آن که وابستگي کنشگرها از اهداف و طرح ريزي ها نتيجه مي شود، فعاليت هاي ساختن دو مدل ، ارتباط آن ها را نشان مي دهد. ب ) نيازمندي هاي ثانويه : مشابه وضعيت نيازمندي هاي اوليه ، تحليل نيازمندي هاي ثانويه ، روش ها و متدهاي ادراکي مشابهي دارد. از نکات مهم در اين فاز مدل نمودن سيستم مقصد (سيستمي که به دست خواهد آمد PPF٧ ) در محيط مي باشد. سيستم هايي که به عنوان يک يا چند کنشگر، مدل مي شود.
وابستگي اين کنشگر هاي خاص توسط پروسه هاي مشابهي که در فاز نيازمندي هاي اوليه به انجام رسيد، مشخص مي گردد. اين وابستگي ها در حقيقت نيازمندي هاي عملياتي و غير عملياتي را تعريف مي کند[١٣].
٣-٢) مرحله طراحي
مرحله بعدي در متدولوژي TROPOS طراحي معماري مي باشد. زير سيستم ها (کنشگرها)، داده ها و ارتباط داخلي داده ها و جريان کنترل ها براي طراحي معماري سيستم ، تعريف مي شوند. متدولوژي TROPOS براي فاز طراحي سه مرحله مشخص مي نمايد. الف ) هدف اصلي و اولين مرحله ، تعريف سازمان و معماري کل سيستم است که بر حسب کنشگرها و وابستگي ها نمايش داده مي شود. ب ) مشخص نمودن قابليت هاي مورد نياز توسط کنشگرها براي انجام اهداف و طرح ريزي ها مي باشد. ج ) پس از آنکه همه ي قابليت هاي کنشگرها مشخص و ليست شد، طراح به مرحله بعد که مرحله ي نهايي فاز طراحي معماري است ، مي رود. در اين مرحله نوع عامل ها، تعريف و قابليت ها به آن ها تخصيص داده مي شود[١٥].
٣-٣) طراحي تفصيلي
فاز طراحي تفصيلي در مشخص نمودن عامل ها و قابليت هاي عامل (مؤلفه ها) و تعامل ها کمک مي نمايد. در اين نقطه ، معمولاً بستر پياده سازي قبلاً انتخاب شده و به منظور اجراي طراحي تفصيلي ، مستقيماً به کد نگاشت مي شود[١٦].
٣-٤) پياده سازي
پس از اتمام فاز طراحي تفصيلي ، توسعه دهندگان مي توانند به مرحله نهايي متدولوژي TROPOS يعني فاز پياده سازي وارد شوند.
TROPOS براي پياده سازي عامل ها بستر BDI را انتخاب مي کند.
فعاليت پياده سازي به وسيله مشخصات طراحي تفصيلي مرحله به مرحله دنبال مي شود و بر طبق باز شناسي نگاشت ميان ساختارهاي بستر پياده سازي و تصورات طراحي ، انجام مي شود[١٥].
٤) معيارها و روش ارزيابي
در اين بخش يک چارچوب ارزيابي متدولوژي ، با مقايسه بر اساس خصوصيات ارائه مي گردد. اين چارچوب شامل مجموعه اي از معيارها و ضوابط مي باشد و نه تنها ويژگي هاي مهندسي نرم افزار کلاسيک را شامل مي شود بلکه خصوصيات انحصاري AOSE را نيز در بر دارد. به منظور اجتناب از به کار بردن يک چارچوب مقايسه اي نادرست براي متدولوژي هاي AOSE، معيارها و خصوصيات در چارچوب کاري اين ارزيابي ، از بررسي کارهاي انجام شده روي مقايسه متدولوژي هاي AOSE نتيجه مي شود.شکل (١) چارچوب کلي ارزيابي را نشان مي دهد[١٧][٢٠].
