مقدمه­ ای بر عامل

//مقدمه­ ای بر عامل

مقدمه­ ای بر عامل

با گسترش تكنولوژی اطلاعات و  تغییر سریع سیستم­های اطلاعاتی و همچنین افزایش استفاده از سیستم­های غیر متمرکز همانند تلفن­های همراه و سیستم­های بر پایه وب ، استفاده از روشی موثر برای توسعه این سیستم­ها لازم به نظر می­رسد. دلايل زيادي براي علاقه به عاملها وجود دارد كه مهمترينشان اين مفهوم است كه انها ميتوانند با يكديگر براي براورده نمودن اهدافشان همكاري نمايند و راه معمولي انتقال سيستمهاي قديمي به سيستمهاي توزيعي امروزي مجهز كردن انها به عاملهاست، يعني اينكه در طرف هركدام عاملهايي گذاشته شود كه توانايي ارتباط با يكديگر را داشته باشند. به دلیل خصوصیات عامل­ها و تفاوت­های آنها با اشیاء ، روش­های شیءگرایی مورد استفاده جوابگو نیستند. به همین جهت استفاده از روش­های مهندسی مبتنی بر عامل ضروری به نظر می­رسد. برای استفاده از مهندسی نرم­افزار مبتنی برعامل بایستی متدولوژی را که بیانگر راهنمایی­هایی در این راستا باشد معرفی نمود.

در این سمینار هدف بررسی روش­های توسعه موثر مبتنی برعامل است، تا در نهایت بتوان متدولوژی مناسب برای حوزه کاربردی مد نظر انتخاب نمود. بر همین اساس چهارچوب سمینار در سه فصل ارایه می­گردد. در فصل اول به بررسی مفاهیم برنامه­نویسی شی­ءگرا و عامل می­پردازیم. سپس عامل­ها به طور کامل تشریح می­گردند. در فصل دوم مهندسی نرم­افزار مبتنی بر عامل  و متدولوژی­های موجود معرفی می­گردند. در فصل آخر متدولوژی­ها در یک چهارچوب خاص ارزیابی می­گردند.

 

فصل 1

مقدمه­ای بر عامل

در ابتدا بایستی به ماهیت و چرایی ارایه مفاهیم جدیدی همچون عامل  که در این سمینار مورد توجه است بپردازم. بر این اساس در ادامه مطالب این بخش به تاریخچه­ای از پیدایش و تکمیل روشهای برنامه­نویسی جدید و تعاریف آنها، و مقایسه عامل[1] و شیء به عنوان دو مفهوم مطرح در این زمینه می­پردازم.  در ادامه مباحث تکمیلی در معرفی عامل و  مفاهیم مرتبط با آن ارایه خواهد شد.

1-1.        برنامه نویسی شیءگرا

زبان­های برنامه­نویسی از دهه 50 میلادی با کامپیوترهای اولیه پا به عرصه وجود نهادند و در دهه 70 میلادی با معرفی سیمولا ،الگوهای برنامه نویسی شیءگرا موجب پیشرفت در مهندسی نرم­افزار گردیدند .برنامه نویسی شیء‌گرا به این گونه‌ است که نرم افزار باید با توجه به مدلهای موضوع‌های حقیقی و فرضی که ارایه می‌کنند نوشته شود. برای یک شیء تعاریف متفاوتی ذکر شده است که بعضی از آنها را در زیر مشاهده مینمایید:

نویسنده

تعریف

بوش

يك انتزاع از چيزي در حوزه مساله كه قابليتهايي از سيستم را كه اطلاعات ان را نگه ميدارد نشان ميدهد  كه داراي رفتار ،هويت  و حالت است.

کود و یاردان

 شيء يك چيز مشهود وملموس در شكلي پايدار است ، كه ميتواند به شكلي عقلايي بيان شود، چيزي كه فكر ميشود يا عملي كه هدايت شود نيز ميتواند باشد. به شكل يك واحد از يك ساختار و رفتار كه شامل خصوصياتي است ميتوتند بيان گردد.

کولبرت

شيء يك شخص ، مكان يا چيزيست  كه ميتواند ذهني و يا فيزيكي باشد. ايده اينست كه شيء ميتواند يك نهاد يا نشان باشد كه يك هويت اختصاصي دارد. شيء ميتواند از اشياء ديگر ساخته شده باشد.

ساختار اصلي تعریف­های بالا شیء است . هر شیء متشکل از يکسري صفات است که به آنها خصلت[2] گفته ميشود که توصيف کننده ساختار شيئ ميباشند همچنين داراي يکسري تابع است که به آنها متد گفته ميشود که در واقع توصيف کننده رفتار آن شيئ مي باشند . در اين ساختار ديگر مشکل پيچيدگي گذرها را نداريم . همچنين به راحتي مي توانيم اشیاء را استفاده مجدد کنيم و با انتقال يک شيئ به يک سيستم ديگر تمامي ساختار و رفتارهاي آن نيز انتقال يابد .با توجه به توضیحات فوق یک شیء میتواند خصوصیات زیر را داشته باشد:

  • یک انتزاع از سیستم
  • قابلیت نگه داری اطلاعات دارد
  • یک عمل هدایت شده
  • یک واحد از یک ساختار
  • دارای خصوصیات است
  • رفتار دارد
  • هویت اختصاصی دارد
  • میتواند از اشیاء دیگر ساخته شده باشد

1-2.        برنامه نویسی عاملگرا

هوش مصنوعی در بسیاری از دانشهای امروزی کاربردهای وسیعی دارد ،هوش مصنوعی به هوشی یک ماشین و یا به دانشی  کامپیوتر که سعی در ایجاد آن دارد گفته می‌شود.   در هوش مصنوعی توزیع شده[3]  که واژه­ای است که در سال 1980 در دانشگاه ام آی تی معرفی شد ، به مطالعه و ساخت و به کارگیری سیستمهای که در آنها چندین عامل در حال تعامل با یکدیگر است و مجموعه­ای از اهداف را دنبال میکنند میپردازند. (شیرازی 1384)

1-2-1.           عامل

 در سال 1990 آقای “یاو شوهام” به معرفی مفهومی جدیدی در برنامه­نویسی به عنوان عامل پرداخت. البته این عامل به در ابتدا به عنوان موجودیتی ساده در نظر گرفته شد، در سال 1993 تعریف آن دچار تغییراتی شد و خصوصیات بیشتری به آن افزوده شدند. تعاریف مرتبط با عاما را میتوانید در جدول زیر مشاهده نمایید:

نویسنده

تعریف

وولدریج

عامل یک سیستم کامپیوتری کپسوله شده, که در محیطی قرار دارد و قادر است کارهای خودمختار برای رسیدن به اهدافش انجام دهد.عاملها قادرند  با یکدیگر تعامل داشته ونسبت کارهای دیگر عاملها واکنش نشان دهند.

راسل

عامل یک واحد محاسباتی مانند برنامه نرم افزاری یا یک روبات است که قابل مشاهده است و با محیط خود در ارتباط بوده و نسبت به تجارب به دست  امده رفتارش را تنظیم میکند  و نسبت به محیط واکنش نشان داده وخودمختار است.عاملها اهدافی دارند که اعمالشان در جهت رسیدن به آنهاست.

سوفر

عامل موجودیت نرم افزاری مانایی است که برای رسیدن به هدف[4] خاصی طراحی شده است.

 

بنابر تعریف دیكشنری آكسفورد یك عامل شخصی است كه برای انجام كاری در یك محل از طرف شخص دیگری دارای صلاحیت باشد. اما در نهایت می­توان گفت عامل هر چيزي است كه محيط خود را باحسگرها درك مي كند و در محيط با کنشگرها تاثير مي گذارد. اين تعريف بسيار وابسته به محيط است. همچنین عامل میتواند سيستمي محاسباتي باشد،كه در محيطي پويا و پيچيده قرار دارد. بصورت خودگردان محيط را حس کرده و با توجه به اهداف خود کنش يا کنشهايي را صورت می دهد .[i] در شکل زیر یک دید انتزاعی از عامل را میبینید.

در علم کامپیوتر عامل نرم­افزاری[5] یک قطعه از نرم­افزار است که مانند یک آژانس در ارتباط با یک برنامه ، کاربر یا عامل دیگر عمل مینماید.  همچنین یک توافق در مورد اینکه چه کاری بایستی انجام گیرد بین آن دو صورت می­پذیرد. ایده این است که عاملها به صورت محدود برای کاری بیدار نمیشوند بلکه خودکار فعال می­شوند. واژه عامل یک تجرید نرم­افزاری ، یک ایده یا یک قاعده مانند توابع ، متدها و اشیا در OOP را بیان میکند. مفهوم یک عامل راهی قدرتمند و راحت را برای تشریح نهادهای نرم­افزارهای پیچیده فراهم میکند که قادر است درجه­ای از خودمختاری را به منظور کامل نمودن کارها در تعامل با کاربر مهیا کند.[ii] هدف از این برنامه ها، سهولت کشف اطلاعات در اینترنت و جایگزینی انسان در این فرآیند طولانی به وجود آوردن دانش است.عاملهای نرم­افزاری برای اولین بار با هدف ایجاد شیوه‌ای راحت و مطمئن برای انجام خودکار کارهایی به نیابت از کاربر بوجود آمد. عاملها از رده هاي مختلف و قابليتهاي متفاوتي ميتوانند باشند از جمله يك برنامه روميري ساده تاوعاملهايي كه براي جستجوي خودكار اطلاعات و بازيابي انها به كار ميروند.

مفاهيم و مفروضات عاملها در مهندسي نرم افزار  شامل مفهومهاي اشاره شده در حوزه مساله مانند عاملهای هوشمند ، عاملهای توزیع شده ، سیستمهای چند عاملی[6] ، عاملهای همراه ،افزايش محلي سازي و بسته بندي مانند به كار بردن كنترل بر روي وضعيت و رفتار خود و در نهايت حمايت از طراحي بر پايه قابليت استفاده مجدد با ارايه عاملها و ارتباطات انعطاف پذير است. چندين عامل درکنار یکدیگرکه به صورت طبيعي غير متمركز، دارای چندين مكان كنترلي، چندين ديدگاه و علايق متفاوتي هستند ،براي رسيدن به اهداف خود بايستي با هم تعامل داشته باشند. این عاملها در کنار یکدیگر تشکیل یک سیستم چندعامله را میدهند.مفهومي كردن سطح دانش به اين معنا كه چه اهدافي، در چه زماني ، توسط چه كسي و به چه علت انجام می­پذیرد ، در سیستمهای چند عامله مطرح میشود.

بیشتر تعاریف ، عامل ها  را به دو دسته پیشكارهای قوی و ضعیف دسته بندی می کنند؛ پیشكار ضعیف خصوصیاتی همچون واقع در محیط،خودمختاری ، واکنشی ، کنش­گرایی و قابلیت اجتماعی دارد دارد[iii]. پیشكار قوی تمامی خصوصیات یك پیشكار ضعیف را دارد اما نشانه های آن گسترده ترند مانند دیدن یك عامل به شكلی كه وضعیت ذهنی و نشانه های اراده مانند اعتقاد،میل،هدف،خواستن و تمكین را داشته باشد .[iv]خصوصیات دیگر مانند قابلیت تحرك و قابلیت اعتماد ،فرمانپذیری نیز بعضی مواقع جزء خاصیت های یك پیشكار قوی هستند.از تعاریف ارایه گردیده در مقالات  و کتابها میتوان مفاهیم زیر را استنتاج نمود[v] :

  • واقع در محیط: عامل ها در محیط ها قرار دارند و برای درك محیط از حسگرهایشان استفاده می كنند. مانند یك ربات كه از حسگرهای متفاوتی مانند دوربین برای دیدن اطراف استفاده می نماید.
  • مانایی[7] : که به صورت پیوسته عامل اجرا گردد و تصمیم­گیری نماید که بعضی از کارها را انجام دهد.  به عبارت دیگرانجام مستمر وظایف[8] محول شده و گرفتن تصمیمات مربوط به این که چه زمانی باید عکس العمل نشان دهد.
  • خودمختاری[9] : عامل بدون دخالت مستقيم انسانها يا ديگران قابلیت انتخاب کارها ، اولویت دهی ، رفتار هدف­دهی شده ، تخصیص میزان اهمیت[10]، و تصمیم­سازی را دارد، انجام وظيفه مي نمايد و بر كنشها و وضعيت داخلي خود نوعي كنترل دارد.
  • قابلیت اجتماعی : عامل­ها قادرند دیگر مولفه­ها را درگیر نموده و بعضی از انواع ارتباطات را به کار گیرند یا اینکه در انجام کاری مشارکت کنند. عامل با ساير عامل­ها  و يا انسان­ها  از طريق نوعي زبان ارتباط برقرار مي كند.
  • فعالیت مجدد [11]: عاملها ممکن است نسبت به متن کاری خویش واکنش نشان داده و کار جدیدی انجام دهند. عامل محيط اطراف خود را درك كرده كه اين محيط ممكن است: دنياي فيزيكي، كاربر با واسط كاربر ، مجموعه اي از ساير عوامل ، اينترنت يا احتمالا مجموعه اي از همه اينها و درزمان مناسب به تغييرات رخ داده در آن پاسخ مي دهد. در کل داشتن توانایی درک نسبی مفاهیمی که برای آن‌ها کار می‌کنند و واکنش می‌دهند.
  • کنش گرا [12]: قابلیت پیش بینی اهداف آینده را داشته باشد. همچنین میتوان به بیان دیگر گفت که بایستی قابلیت واکنش به تغییرات محیط را داشته باشند. عامل ها در صورتی كه اهدافشان را در طول زمان تعقیب كنند کنش­گرا هستند،هدف نهایی یك ربات فوتبالیست برنده شدن تیمش است.پس به همین علت تصمیمات مانند ضربه زدن به توپ و پاس دادن و گل زدن را در یك هدف كلی انجام می دهد.
  • از جمله خصوصیات دیگر عامل­ها میتوان به انعطاف­پذیری، عقلانیت، یادگیری، هدف گرایی و قابلیت استدلال اشاره نمود. البته خصوصیات زیادی برای عاملها ذکر گردیده که با توجه به سیستمهای مختلف امکان دارد به کار گرفته شوند یا خیر، که در اینجا اشاره نمیگردد.

خصوصیات ذكر شده به عامل ها آن ها را به نهاد هایی محكم با قابلیت انعطاف تبدیل می كند. انعطاف پذیری از توانایی عامل ها در پاسخ به تغییرات محیطی ناشی می شود. تعقیب كردن اهداف و بهبود كارها منجر به استحكام عامل ها می شود این كیفیت ها در سیستم های پیچیده،پویا، باز و محیط های خطا خیز مفید هستند.

عاملهای نرم­افزاری یک تکامل مستقیم از سیستم چند عامله هستند. خود MAS شامل و نشات گرفته ازهوش مصنوعی توزیع شده و موازی ، و همچنین حل مساله توزیع شده است که خصوصیات بد و خوب همه آنها را با هم دارد. یکی دیگر از مفاهیم عامل­ها ، عامل­های هوشمند[13] است  که در علم کامپیوتر به عامل نرم­افزاری که هوشمندی به خرج دهد عموما عامل هوشمند می­گویند. در این قسمت چند مثال از عاملها را ذکر می کنیم تا در حین آن نحوه کمک رسانی آن‌ها به کاربران را توضیح دهیم.عامل­های هوشمند نرم­افزاری را  میتوان به چهار دسته تقسیم نمود :

  1. عامل­های خریدار : این عاملها در طول شبکه حرکت میکنند. اطلاعات و سرویس­ها را استخراج می­کنند.برای محصولاتی مانند کتاب ، قطعات الکترونیکی و غیره مناسب هستند. این نرم‌افزارها به کاربران اینترنتی در پیدا کردن محصولات و خدمات مورد نیازشان کمک می‌کنند. به طور مثال زمانی که فردی برای خرید محصولی به سایت eBay می‌رود، در پایین صفحه لیستی از محصولات است که دیگر خریدارانی که به دنبال آن محصول بودند، به آن‌ها نیز توجه داشته اند. دلیل انجام این عمل این است که سلیقهٔ کاربران به صورت نسبی به هم شبیه است و آنها به دنبال محصولات مشابهی هستند. به این تکنولوژی که با کمک عاملها امکان پذیر است،  فیلتر مشترک [14]می‌گویند.
  2. عامل­های شخصی : عامل­های هوشمندی هستند که در ارتباط با انسان کارهای زیر را انجام میدهند : با ما بازی کامپیوتری انجام میدهند ، بنابر نیاز ما اطلاعات را پیدا میکنند ، صفحات وب را به صورت  خودکار برای ما پر میکنند. همچنین این عامل­ها به منظور انجام کارهای کاربر به طور اتوماتیک به وجود آمده اند. مثلا بعضی از این عاملها ایمیل‌های کاربران را با توجه به نوع درخواستشان طبقه بندی و مرتب می‌کنند.
  1. عامل­های نظاره­گر : برای مشاهده یک گزارش بر روی یک تجهیزات خاص(معمولا رایانه­ای) استفاده می­شوند. عاملها ممکن است که مراحل تولید را در یک کارخانه یا در یک شرکت از نقطه تولید تا پشتیبانی را پیگیری نمایند، یا اینکه اتفاقات بازار سرمایه را نظاره­گر باشند.
  1. عامل­های داده­کاوی : این عاملها از فن­آوری اطلاعات برای پیدا کردن الگوها از چند منبع مختلف استفاده می­کنند. کاربر میتواند از اطلاعات طبقه­بندی شده این عاملها استفاده نماید تا اطلاعات مورد نیاز خود را بدست آورد. مثالی از این نوع عامل ها، عامل هایی هستند که شرایط بازار را دائما بررسی می‌کنند و آن شرایط را به کاربر یا کارخانه گزارش می‌دهند تا کاربر یا کارخانه بتواند با توجه به آن‌ها تصمیمات صحیح بگیرد.

با توجه به توضیحات بالا عامل هوشمند نرم­افزاری یک نهاد خودکار است که محیط اطراف خود را نظاره میکند ، به آن واکنش نشان میدهد و فعالیتهایش را برای دسترسی به اهدافش مسیردهی میکند[vi].  عاملهای هوشمند همچنین ممکن است عمل یادگیری را انجام دهند و از دانش خود برای رسیدن به اهداف استفاده نمایند. آنها میتوانند ساده یا بسیار پیچیده باشند مانند یک ترموستات ماشین یا انسانها در جامعه بشری، مثالهای دیگر از عاملهای هوشمند شامل فیلتر کنندگان هرزنامه­ها و یا عاملهای موتورهای جستجوگر نام برد.

عاملهای هوشمند به شیوه­های متفاوتی تعریف شده­اند[vii]، در کل میتوان گفت یک عامل هوشمند بایستی خصوصیات زیر را داشته باشد [viii]:

  • تطبیق راه­حل­های جدید با قواعد افزایشی
  • تطبیق به صورت آن­لاین و در زمان
  • قادر بودن به تحلیل  رفتار ، خطا و موفقیت­های خود
  • یادگیری و بهبود خود در تعامل با محیط [15]
  • به سرعت از حجم عظیمی از داده یادگیری انجام می­دهند
  • داشتن یک نمایشگر حافطه و مخزن بازیابی اطلاعات
  • داشتن پارامترهایی جهت نمایش حافظه کوتاه­مدت و بلند­مدت و فراموش کردن

به صورت ریاضی یک عامل ساده به عنوان یک تابع عامل تعریف میگردد که هر رشته  مفاهیم  را به عمل ممکنی که عامل قادر به انجام آن است نگاشت می­کند :                  f : P→ A

بنابر تعریف راسل عاملها بر اساس درجه هوش و قابلیتهایشان به پنج طبقه از کلاسها تقسیم می­شوند:

  1. عاملهای بازتابی ساده [16]
  2. عاملهای بازتابی بر اساس مدل[17]
  3. عاملهای پایه هدف[18]
  4. عاملهای پایه ابزار[19]
  5. عاملهای یادگیری[20]

عاملهای بازتابی ساده بر اساس شرط عمل کار خود را انجام می­دهند به این معنا که اگر شرطی اتفاق افتاد آنگاه عمل مرتبط انجام گردد.در این حالت تمام محیط مشاهده میگردد و واکنش نشان داده می­شود. در عاملهای بازتابی بر اساس مدل محیط به صورت جزئی مشاهده می­گردد و حالت کنونی درون عامل ذخیره می­شود تا تصمیم­گیری نماید. عاملهای پایه هدف مانند براساس مدل است درحالی که ذخیره حالتی صورت می­پذیرد که مورد رضایت و مد نظر عامل باشد. عاملهای یادگیری در محیطهای ناشناخته به کار می­رود تا آگاهی عامل در آن محیط افزایش یابد.

عاملهای هوشمند اغلب به صورت شماتیک به عنوان یک سیستم کاربردی انتزاعی مانند یک برنامه کامپیوتری در نظر گرفته می­شوند به همین دلیل بعضی اوقات AIA[21] نامیده میشوند.  اما هنوز خیلی­ها ترجیح میدهند که جوهره اصلی عاملها را رفتار هدف­دهی شده آنها در نظر بگیرند از این رو با واژه به عاریت گرفته شده از اقتصاد آنها را عاملهای منطقی[22] می­نامند.

1 -2 -2 .  محیط عامل

از دیگر مفاهیمی که در برخورد با عاملها میتوان مشاهده نمود،واژه محیط است. بر اساس گفته “مولر” عاملها را نمی­توان به صورت مستقل ، بدون توجه به محیطی که در آن فعالیت می­کنند در نظر گرفت[ix]  . محیطی که عامل در آن به تعامل با دیگر عاملها می­پردازد در انتخاب مدل معماری و همچنین متدولوژی مهندسی نرم­افزار تاثیر گذار است. خصوصیات محیط بنابر دسته بندی کلاسیک هوش مصنوعی شامل موارد زیر است[x]:

  • قابل دسترس/غیرقابل دسترس : عامل قادر به درک کامل حالات جهان پیرامون خود هست ؟
  • قطعی / غیرقطعی : آیا تغییر حالت محیط در وضعیت کنونی کاملا در نظر گرفته شده است؟
  • ایستا/پویا : تغییر حالت محیط در کنکاشهای عامل در نظر گرفته شده؟
  • مقطعی/ غیرمقطعی : رشته تعاملات عامل با محیط مستقل هستند؟
  • گسسته/پیوسته : تعامل عامل با محیط محدود است؟

بر اساس تحقیقات جدید انجام شده محیط به عنوان یک انتزاع کلاس مرتبه اول در نظر گرفته می­شود ،که عاملها را احاطه کرده است ، و شرایط گفتگو بین عاملها و دسترسی به منابع را محیا می­نماید. همچنیین محیط بایستی قابلیتهای زیر را داشته باشد[xi] :

  • ارایه نمودن یک ساختار برای سیستم چند عامله
  • داشتن خدمات و منابع
  • پویا بودن
  • به صورت محلی قابل مشاهده باشد
  • به صورت محلی قابل دسترس باشد
  • تعریف و نظارت بر قواعد محیطی

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

1-2-3 .  معماری عامل

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

نیازهای یک محصول ، کیفیت خصوصیات آن و مشخصات کاربر معماری آن را میسازد.[xiv] مطالعه معماری مفروض دیدگاههای مختلفی را مهیا میکند که مانند نمونه سازی به صحت نیازمندیها  وتنظیم دقت آنها کمک مینماید. معماری برای سیستمی که شامل سخت­افزار و نرم­افزار یا بسیار پیچیده است امری حیاتی به شمار می­آید چرا که خاصیت ردیابی اطلاعات به تیم توسعه کمک میکند  نیازهایی را که در طراحی آن مشخص گردیده  پیگیری نمایند.[xv] دیگر دلایل اهمیت معماری در مواردی همچون  : ارتباط بین سهامداران سیستم ، تصمیمات  طراحی اولیه ، تجرید قابل انتقال سیستم   است. بنا بر گفته ” مایز” معماری عامل يك متدولوژي ويژه براي ساخت عاملها است كه مشخص مي سازد، چگونه عاملها مي توانند به مجموعه اي از ماژولها شكسته شوند و چگونه اين ماژولها با هم ارتباط داشته باشند. مجموعة ماژولها و روابط بين آنها پاسخي به اين سؤال هستند؛ كه چگونه داده حسگرهاو وضعيت فعلي، كنش ها و حالت بعدي را مشخص ميكنند. معماري شامل تكنيكها و الگوريتمهايي است كه اين متدولوژي را حمايت مي كند.

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

  1. مدل منطقی : سمبولیک است و از مکانیزم Reasoning  استفاده میکند.
  2. مدل واکنشی : بر اساس انجام یک عمل پاسخ میدهد.
  3. مدل لایه ای : این مدل تر کیبی از مدلهای دیگر است.
  4. BDI : دارای ساختار ذهنی و یکی از معروفترین مدلهایش PRS است.

معروفترین مدلهای استفاده در معماری که در متدولوژیهای مختلف مد نظر قرار میگیرد. مدل معماری لایه ای و BDI است. در مدل لایه ای پیشنهاد , تشکیل یک سیستم چند لایه است که هر لایه یکی از وظایف را بر عهده دارد. نحوه قرار گرفتن لایه ها میتواند به صورت افقی یا سلسله مراتب عمودی ویا ترکیبی از این دو باشد.در معماری مبتنی بر باورها , تمایلات و قصدها[24] رسیدن به هدف مشخصی بر اساس یک استدلال عملی است.در این معماری جریان کاری از دریافت از حسگرها تا پاسخ وجود دارد که نحوه ادامه کار را مشخص مینماید.

1-2-4 . ارتباطات و هماهنگی در عاملها

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

عاملها براي رسيدن به هدف تحت ارتباطات سازماندهي شده تعامل دارند .اين بستر سازماندهي رفتارعاملها را تحت تاثير قرار ميدهد ودر این حالت است که نياز به جفتها،. تيمها، يكپارچگي و صلاحيت در ارتباط ضرورت پیدا میکند. روش ایجاد ساختار سازمانی  برای عاملها میتواند به دو شکل سنتی مشتری/ خدمت گذار و یا تخته سیاه باشد , البته  روشهای  دیگری همچون ایجاد قراردادها در سیستمهای توزیع شده مبتنی برعامل نیز به کار میرود.جهت ایجاد همکاری میان عاملها در سیستمهای متنوع امروزی زبانهای استانداردی به وجود آمده اند.گفتگوی میان عاملها در قالب مذاکره[25] معنا میابد.گفتگوی میان عاملها در محیط و ارتباط آنها مستلزم درک معنا از گفتگوی انجام شده است. حال این ارتباط تعریف شده میتواند مختص به یک برنامه و یا سراسری باشد. در ارتباط میان عاملها , فهم یکسان از یک پدیده امری مهم است به همین جهت از هستان شناسی[26] در ارتباطات عاملها استفاده میگردد.

شرکتها و موسسات بسیاری برای ایجاد زبان گفتگوی میان عاملها و ایجاد استاندارد فعالیت نموده اند. از آن جمله میتوان به ACL توسط موسسه FIPA و یا KQML , WSDL اشاره نمود. در ادامه به مقایسه عامل و شیء می­پردازیم.

1-3.       مقایسه عامل و شیء

تفاوتي كه ميان عامل وشيء وجود دارد،  اين است كه يك عامل علاوه بر مفاهيمي همچون خصلت و متد شامل حالات ذهني مانند مفاهيم نقشه و هدف است ,مورد تفاوت ديگر نحوه ارتباطات در شيء و عامل است ، عاملها از يك روش با معني و با ساختار پيغام مبادله ميكنند و از پروتكل و همكاري استفاده ميكنند در حالي كه در شيء فقط بيدار كردن يك متد يا انتقال ساده يك داده است.که براساس خصوصیات آن دو در نمایشهای مختلف استوار است. در ابتدا از روی تعریف آن دو میتوان در جدول زیر خصوصیات آن دو را  بیان نمود:

عامل

شیء

خصوصیت

هست

هست

یک انتزاع از سیستم

دارد

دارد

قابلیت نگه داری اطلاعات

خودمختار

هست

یک عمل هدایت شده

دارد

دارد

رفتار

دارد

دارد

هویت اختصاصی

هست

نیست

اجتماعی

هست

نیست

هدف گرا

قانونمند

بر اساس تعریف کاربر

ارتباطات

دارد

ندارد

تداوم زمانی

دارد

ندارد

حالت

بر اساس جدول پیشین میشود گفت که تفاوت عامل و شیء در تعریف اینست که یک عامل تمامی خصوصیات یک شیء را دارد ، اما علاوه بر آن خصوصیات عامل دارای ارتباطات اجتماعی قانونمند است و خودمختاری آن بر اساس یک هدف است و در موقعیتهای زمانی خاص بر اساس حالات خود واکنش نشان میدهد. یک عامل تداوم زمانی دارد که یک شیء از آن بی بهره است. هردوي شيء و عامل در محيط هستند، هردو ميتوانند واكنشي باشند، عاملها خودمختار هستند، عاملها ميتوانند چند هدف داشته باشند، عاملها اجتماعي هستند و قواعد گفتگو دارند. به این ترتیب میتوان گفت که یک عامل به شکلی فعالتر میتواند موجودیتهایی را که در محیط اطراف ما وجود دارند را مدلسازی نماید. در بررسی برنامه­نویسی شیءگرا در مقابل عامل­گرا میتوان به جدول زیر اشاره نمود:

 

OOP

AOP

واحد اولیه

شیء

عامل

تعریف حالت واحد

نامحدود

اعتقادات، قابلیتها، تاییدات ، انتخابها و ….

فرایند محاسبات

روش عبور پیغام و پاسخ

روش عبور پیغام و پاسخ

نوع پیغام

نامحدود

اطلاع­رسانی، درخواست، قبول ، رد کردن و …

محدودیت بر روی روشها

محدودیتی ندارد

امانتداری ، سازگاری …

در برنامه­نویس عاملگرا [27]و شیءگرا تفاوت­های نوع پیغام و واحدهای مورد استفاده قابل ذکر است ، که در بعضی موارد موجب پیچیدگی­هایی در استفاده از روش عاملگرا می­گردد. اما سادگی آن در ارایه ساختارهای مشخص است که در بعضی از خصوصیات موجب برتری برنامه نویسی عاملگرا است.همانگونه که در جدول فوق می­بینید ،در برنامه­نویسی عامل­گرا تفاوتهایی در مقایسه با برنامه­نویسی شیءگرا وجود دارد، که باعث ایجاد تفاوتهایی در روش برنامه­نویسی آن دو می­گردد.

 

برنامه­نویسی یکپارچه

برنامه­نویسی پیمانه­ای

برنامه­نویسی شیءگرا

برنامه­نویسی  عامل­گرا

رفتار هر واحد

غیرپیمانه­ای

پیمانه­ای

پیمانه­ای

پیمانه­ای

وضعیت هر واحد

خارجی

خارجی

داخلی

داخلی

بیدار نمودن واحد[28]

خارجی

خارجی (فراخوانی)

خارجی (پیغام)

داخلی (قاعده ، هدف)

در جدول بالا[xvi] میتوان تکامل روشهای برنامه نویسی را که به AOP ختم می­شود مشاهد نمود.در این جدول خصوصیات و وجه تمایز روشهای برنامه­نویسی در قالب واحدهایی که برایشان کدی نوشته می­شود به شکلی ساده مشاهده نمود.در جدول فوق اگر هر واحد را به عنوان یک موجودیت در نظر بگیریم درخواستها میتوانند از نهادهای خارجی یا داخلی باشند. در بعد مقایسه معماری میتوان به این امر اشاره نمود که در طراحی عاملها با توجه به تفکیکی که انجام میگردد، در مقایسه با اشیاء، پیچیدگی کمتری را در روابط و ساختار میتوان مشاهده نمود.چرا که در بزرگ شدن سیستمها و افزایش پیچدگی ، در طراحی شیءگرا تعداد روابط افزایش میابد و به طبع پیچیدگی و تداخلات زیاد میشود. در شکل زیر معماری یک سیستم چند عامله با تقسیم بندی وظایف را میتوان دید.

 

 

 

 

 

 

 

1-4.          رابطه برنامه نویسی سرویس گرا و عاملگرا

پس از تكامل الگوريتمهاي محاسباتي امروزه به سمت تعامل ميان محاسبات ميرويم، اين امر مستلزم خودمختاري عاملهای محاسباتی و توانايي عاملهای واسط براي تعامل با محيطشان است.سرويسها بایستی کنش­گرا باشند و این امر نیاز به عامل دارد و خود عاملها نياز به درك بر اساس هستان شناسی دارند. پيچيدگيهي موجود در ارايه برنامه نويسي سرويس گرا كه مواردي همچون ساختار ، پيغام رساني، امنيت و …  را در برميگيرد ما را به سوي استفاده از هستان شناسي و عاملها ميبرد. تكنولوژيهايي كه به اين سمت حركت كرده اند عبارتند از : OAG, OASIS,BizTalk,RostteNet . داشتن يك هستان­شناسي سراسري جهت كار كردن با عاملها باعث میشود که  يك وب سرويس به چند روش ارايه شود .در جدول زیر میتوان ساختار واحدهای مختلف برنامه نویسی سرویسگرای مبتنی بر عامل را در مقایسه با روشهای پیشین دید.

مفهوم

زبان رویه ای

زبان شیء

زبان سرویس مبتنی بر عامل

انتزاع

نوع

کلاس

سرویس/ تعامل

واحد سازنده

نمونه ، داده

شیء

عامل

مدل محاسباتی

رویه/فراخوانی

متد/پیغام

درک/دلیل /عمل

موارد طراحی

درخت رویه ها

الگوهای تعامل

تعاملات همکار

معماری

تجزیه کاربردی

وراثت و چند ریختی

مدیران، وردستها ، جفتها

حالات رفتاری

کدنویسی

طراحی و استفاده

فعال و تصویب کردن

واژگان

پیاده­سازی

مهندسی

فعال­سازی

در برنامه­نويسي سرويس­گرا دو مزيت ساختن برنامه هاي انعطاف پذير و بازدهي برنامه نويسي و مديريت برنامه كاربردي در سيستمهاي باز وجود دارد. مزیتهای دیگری در ترکیب با سیستم چندعامله از جمله موارد زیر دارد :

  • ارايه ابزار براي مدلسازي اطلاعات كه امكان همكاري درون يك سازمان را فراهم ميكند
  • اجازه خودمختاري درون سازمان را به هر فرايند ميدهد
  • اجازه خصوصي سازي برنامه هاي جديد را از طريق واسطشان با سرويس ميدهد
  • اجازه انتخاب بر اساس كيفيت سرويس را ميدهد
  • اجازه استقاده موثر از منابع توزيعي را ميدهد
  • در عاملها درباره خود ميدانند و ميتوانند از عاملهاي ديگر اگاه شوند و اين مزيتي براي ارايه سرويس است
  • عاملها برخلاف سرويسها ميتوانند از يك هستانشناسي براي ارتباط استفاده كنند
  • عاملها براي ارتباط ساخته شده اند در حالي كه سرويسها تا فراخوانده نشوند غيرفعالند
  • وب سرويس به صورت اوليه خودمختار نيستند و همانطوري كه نوشته ميشود استفاده ميگردد
  • عاملها با يكديگر همكاري ميكنند تا هدف بزرگتري دست يابند

با توجه به موارد گفته شده ، براي اينكه[29] SOA مزيتهاي فوق را داشته باشد نيازمند موارد زير است : جفتگيري ضعيف، پياده سازي بي طرف، تنظيمات انعطاف پذير، دوره حيات طولاني، دانه دانه بودن،  محاسبات تيمي. در واقع یک همکاری دوطرفه میان برنامه­نویسی سرویس­گرا و چندعامله اتفاق می­افتد.انچه برنامه نويسي سرويسگرا به چند عامله ميدهد ، ارايه تكنولوژي اطلاعات سنتي و رفتارهاي استاندارد براي تسهيل ابزارهاي توسعه است.كه معماري سيستمها را ميتوان در قالب مدل علي، مدل فرايند، جريان كاري و گراف هدف-زيرهدف يا مدلهاي رسمي بيان نمود. مساله مورد توجه در طراحي چنين سيستمهایي برآورد ارتباط سراسري اجزا است بدون اينكه با كنترل سراسري درگير شويم

 

فصل 2

مهندسی نرم­افزار مبتنی بر عامل

 

مهندسی نرم افزار[30] ، عملیاتی است مربوط به طراحی ، پیاده سازی و تغییردادن نرم افزار ، به گونه­ای که از کیفیت بالاتر، با بهره­وری بیشتر ،قابلیت نگهداری  و سرعت ساخت برخوردار باشد. از این رو  رویکرد سیستماتیک به تجزیه و تحلیل ، طراحی ، ارزیابی ، اجرا ، تست ، نگهداری و مهندسی مجدد به عنوان کاربردهایی در مهندسی نرم افزار مورد توجه می­باشند. (Phillip Laplante 2007)

2-1. مهندسی نرم­افزار مبتنی بر عامل

 

با گسترش تكنولوژی اطلاعات در دهه ٨٠ تعداد زیادی برنامه های نرم افزاری برای نیازمندی های پیچیده بوجود آمد و تكنیك های تحلیل ساخت­یافته آنچنان مؤثر نبودند، و به همین جهت روش های شی گرا معرفی شدند. این روش ها جنبه هایی مانند مخفی سازی اطلاعات،انتزاع داده ای، تلفیق داده ها و همزمانی را در خود دارند. همچنین شی گرایی تلاش نمود تا فاصله جهان حقیقی و بازنمایی آن را پر كند این امر در برنامه های كاربردی بوسیله مدل های نهاد های واقعی توسط اشیا انجام میگیرد.به همین جهت قابلیت های بسیاری مانند افزایش كاربر،بهبود تغییرپذیری و نگهداری از این روش نتیجه شده است. مهندسی نرم افزار شیء گرا[31] که یک متدولوژی و زبان مدلسازی شیء است، توسط ایوار یاکوبسون در سال ۱۹۹۲ وقتی که در شرکت” آبجکتری ای بی “کار می‌کرد طراحی شد. این اولین متدولوژی طراحی شیءگراست که از”مورد کاربرد”[32] برای طراحی نرم افزار استفاده مینماید. همچنین عناصر طراحی دیگری نیز شبیه به عناصر مورد کاربرد درمدل­سازی اشیاء دارد.درروند تکمیل این روش مفاهیم و نمادهای OOSE در UML[33] استفاده شدند و درشکل متدولوژی یا یک محصول دیگر به نام [34]RUP  به بلوغ رسید. با توجه به اثبات قدرت شی گرایی باز سیستم های نرم افزاری پیچیده تر شده اند و این مفهوم قادر به پاسخ به نیازهای جدید نبود.

یكی از آن ها تغییرات سریع محیط سیستم های اطلاعاتی است. سیستم های نرم افزاری هم اكنون به یكدیگر بیشتر متصل هستند و غیر متمركز شده اند این تغییرات با توجه به افزایش محبوبیت اینترنت پیچیدگی های پیشرو را افزایش داده است.

با افزایش پیچیدگی سیستمها و پیشرفت روزافزون اینترنت و سیستمهای همراه, نیاز به ارایه روشی مهندسی برای برخورد با آنها لازم به نظر می­رسید .در سيستم­هاي پيچيده مفاهيمي همچون ارتباطات ميان زير سيستمها و درون سيستمها بر پيچيدگي مي­افزايد.با توجه به توضیحات داده شده و همچنین دو دلیل  زیر برای برخورد با سیستمهای پیچیده از روشهاي سنتي مهندسي نرم افزار استفاده نميشود[xvii] :

١.چون طراحي سطح بالا براي هر روش برنامه نويسي ،انتزاعهاي متفاوتي دارد مانند در برنامه نويسي رويه اي ميگوييم چه كاري انجام ميدهد؟شيء گرا ميگويد چه اشيايي انجا هستند ،داده و عمليات کدام است؟عامل ميگويد چه اهدافي وجود دارند؟ چه رابطه اي بين عاملها است؟

٢.در طراحي سطح پايين با اعمال غيرقطعي و شكستها روبرو هستيم كه نيازمند نقشه هاي جايگزين، و بيش از يك راه حل مورد نياز است.

با توجه به خصوصیات سیستم های پیچیده استفاده از مجموعه ای از اشیا غیر فعال منطقی به نظر نمی رسد به همین علت علاقه به عامل ها و مفهوم مهندسی نرم افزار آن افزایش پیدا كرده است.دو مفهوم قابلیت های پیشرفته عامل ها و سیستم های چند عامله و قابلیت بازنمایی قوی آن ها راه حل­های خوبی را برای سیستم های پیچیده فراهم می كند.

سه ابزاری كه عاملگرایی برای توسعه و مدیریت پیچیدگی در اختیار استفاده كنندگان قرار می دهد عبارتند از: شكستن،انتزاع و سازمان؛ با شكستن فضای مسئله سیستم پیچیده به بخش های عامل و ارتباطات شكسته می شود ، با انتزاع عامل ها، برای طراحی و ساخت سیستم ها مناسب به نظر می رسند و مورد سوم بیانگر كارایی آن ها برای مدل سازی و مدیریت روابط سازمانی برای رسیدن به وابستگی ها و روابط درون سیستم پیچیده است.در جدول زیر تفکیک مفاهیم در مقایسه سیستم برپایه عامل با سیستم پیچیده را میبینید.

سیستم پیچیده

سیستم بر پایه عامل

زیر سیستمها

سازمان عاملها

مولفه­های زیر سیستمی

عاملها

تعامل میان زیرسیستمها و مولفه­های زیرسیستمی

همکاری برای رسیدن به یک هدف،هماهنگی اعمال،گفتگو برای رفع تداخلها

تعاملات میان زیرسیستمها و مولفه­های زیرسیستمی در طول زمان تغییر می­کند و  آنها به عنوان یک مجموعه واحد عمل مینمایند.

یک روش مجزا برای مدیریت و بازنمایی روابط سازمانی ، و همچنین ساختاری برای مدل­سازی مجموعه­ها وجود دارد.

با توجه به دلایل فوق و همچنین مزایای دیگر استفاده از سیستمهای چندعامله در حل مسایل مهندسی مانند افزایش قابلیت اطمینان، توسعه­پذیری، استفاده مجدد، امکان اجرای موازی ، تعامل سیستمهای متفاوت، امکان پیاده­سازی نظریه­های  علمی رشته­های دیگر ,  سیستمهای پیچیده مهندسی نرم­افزار مبتنی بر عامل [35]،  به عنوان راهکاری جدید در مهندسی نرم­افزار مطرح شده اند.

 در سال ۱۹۹۲  آقای “وولدریج” متدولوژی MADE را معرفی نمودند و در سال۱۹۹۸  تحت مقاله­ای به نام مهندسی نرم­افزار مبتنی بر عامل برای اولین بار به بیان  مفهوم جدید مهندسی نرم­افزار مبتنی برعامل پرداخت[xviii].در AOSE اجزای مطرح و پایه­ای عاملها هستند، و این روش مهندسی بر روی بعضی از سیستمهایی که مبتنی بر عامل نیستند نیز قابل اعمال است . در متدولوژی­های مهندسی نرم­افزار مبتنی بر عامل تمامی یا قسمتی از زیربخشهایی که در علم مهندسی نرم­افزار مطرح هستند ، پوشش داده می­شوند. برای روشن شدن معانی واژگان  و ارتباط میان آنها در مطالب ارایه شده در این سمینار توضیحاتی در زیر می­آید:

2-1-1.    فرايند توسعه:[36] مجموعه­اي از گام­هایی است كه شامل فعاليت­ها ، محدوديت­ها و منابعي براي رسيدن به يك خروجي مطلوب می­باشد كه يك سري از نيازهاي ورودي  را پاسخگو است. فرايند معمولا شامل چند فاز يا قدم است كه هر كدام يك فعاليت را نشان مي­دهند.

2-1-2.    فرايند توسعه­ی نرم افزار[37]: مجموعه­اي همسان از سياست­ها، ساختارهاي سازماني، فن­آوری­ها،روش­ها و محصولاتي كه براي توسعه ، نگهداري، تجهيز و درك سيستم نر­م ­افزاري مورد نياز هستند.(fuggeta 2000)فرایند توسعه­ی نرم­افزار شامل مراحلي براي رسيدن به محصول نهايي است، که گام­های تعریف شده در آن ، با فرايند توسعه، سه تفاوت اساسی دارد :

  • بايستي نيازمندي­ها درك شوند
  • بايد در محيط عملياتي كارگذاشته شود
  • بنا بر درخواستهای کاربران و نياز به تغييرنرم­افزار، نگهداري از ان انجام می­شود.

فرآیند توسعه­ی نرم افزار که با عنوان چرخه­ی حیات[38] تولید نرم افزار نیز شناخته می‌شود، ساختاری است که روی توسعه و تولید محصولات نرم افزاری اعمال می‌شود. عبارت­های همانندی چون چرخه­ی حیات نرم افزارو فرآیند نرم افزار در این رابطه استفاده می‌شود. مدلهای گوناگونی همچون فرآیندهای خاص وجود دارند که هر کدام خط مشی مختص آن فرآیندها را برای انجام کارها و فعالیت‌های متنوع در طول فرآیندها  مشخص می‌کنند.

به يکسري از راه حل ها و تکنيک­هايي که نيازهاي هر مرحله از فرآيند توسعه نرم افزار را پیدا نماید، شناسایي[39] گفته مي شود . حال پس از شناسایی بايد راهي براي نمايش آنچه که در دست است، داشته باشيم . براي اين منظور نياز به قواعدي براي نمايش داريم که براي همگان قابل درک باشد که به اين اصول، بازنمايي[40] گفته مي شود . 
بازنمايي بايد دو شرط داشته باشد ؛ يکي اينکه کامل باشد و ديگر اينکه کمترین ابهام را داشته باشد .

2-1-3.    مدل فرايند نرم افزاري:[41] مدل فرايند بيان كننده اين مطلب است كه كدام فاز از فرايند بايستي سازماندهي شود ،و در چه مرتبه اي اجرا گردد و چه هماهنگي ميان كارهاي مختلف فازها اتفاق افتد. در ادامه انواع مدل فرايند به اختصار توضیح داده خواهد شد:

 

 

 

  • ·         مدل فرایند آبشاری

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

  • ·         مدل فرایند حلزونی

ویژگی مهم مدل حلزونی ، مدیریت ریسک در تمام مراحل چرخه­ی تولید نرم افزار است .مدل حلزونی،  فرایند تولید نرم­افزار را با چهار نمودار که نشان دهنده­ی فعالیت­های تدوین و فرموله کردن، تحلیل ریسک و مشکلات سیستم  ، و پیاده سازی است،که آنها را به تصویر می کشد و فرآیند ها در چندین مرحله تکرار ، به پایان می رسند.مدل حلزونی مبتنی بر ریسک، در انتخاب گزینه ها و همچنین محدودیت در سفارشها برای پشتیبانی بهره بردن دوباره از  نرم­افزار  ، مختار است .مدل حلزونی بیان می­کند که کیفیت نرم افزار می تواند در ادغام اهداف ویژه در تولید نرم افزار کمک نماید.

  • مدل فرایند تکراری و افزایشی

روش  تکراری تولید نرم افزار، اجازه­ می­دهد که پروژه در ابتدا از بخشهای کوچک آغاز شود و به مرور زمان که سیستم رشد می­کند ،کمک می­نماید که مشکلات مهم پیدا شوند و پیش از آن­که فرضیه­های نادرست ،سبب خراب شدن سیستم شوند. مدل تکرار فرآیند ها بوسیله­ی تولید کنندگان نرم افزارهای تجاری انتخاب و استفاده می شود، چون این مدل اجازه می دهد تا نیازهای کاربرانی -که در زمان طراحی دقیقا نمی دانند که چگونه نیازمندی­هایشان را  از سیستم  معرفی کنند- به­گونه­ی بالقوه برآورده شود.

افزون بر روشهای بالا که به اختصار گفته شد ، روش­های معروف دیگری همچون روش چابک وجود دارد که روش تکراری را به­عنوان پایه­ی کار استفاده می کند.مدل چابک از بازخوردها به جای برنامه ریزی به­عنوان مکانیزم اصلی کنترل پروژه استفاه می کند.بازخورد ها بوسیله­ی آزمونهای مرتب و انتشار نرم افزارهای در حال تکامل تولید می شوند.

2-1-4.    زبان مدل سازی : برای مدل­سازی از زبان استاندارد آن  UMLاستفاده میشود.همانطور كه از نامش پيدا است يك زبان مدلسازي است تا يك متدلوژي كه در فاز تحليل و طراحي مورد استفاده قرار مي‌گيرد.. بطور معمول، هر متدلوژي شامل حداقل يك زبان مدل­سازي و يك فرایند ساخت است.  زبان مدلسازي شامل نمودارهايي است كه هر متدلوژي براي نمايش تحليل و طراحي سيستم‌‌ها از آن استفاده مي‌‌كند. 
اما يك پروسه ساخت شامل دستورات، راهنمايي ها و قدم هاي لازم براي انجام تحليل و طراحي سيستم‌‌ها مي‌‌باشد. افرادي كه يك متدلوژي را به كار مي برند معمولاً بيشتر با زبان مدلسازي آن سروكار دارند. همچنین گستره­هایی برای این زبان تعریف شده که قابلیت آن را برای متدولوژیهای متفاوت افزایش میدهد، از جمله میتوان به AML[42] اشاره نمود. این گستره یک سری نشانه­ها[43] را به نشانه­های استاندارد UML می­افزاید تا قابلیت بیان و مدل سازی عاملها را داشته باشد.

2-1-5.    متد :[44] بيان كننده نحوه انجام يك كار مشخص درون فرايند براي توليد يك خروجي است.

2-1-6.    متدولوژي:[45] يك متدولوژي مجموعه اي از متدها است كه مراحل مختلف يك فرايند را پوشش و به هم متصل ميكنند. هدف متدولوژي بيان يك روش مشخص براي حل مساله در فرايند نرم افزاري و ايجاد ارتباط ميان متدهاي مختلف است.(Ghezzi et all., 1991) متدولوژی شیوه ای است که به وسیله آن سازمانها و تیم پروژه به چهارچوب تعریف شده اعمال میگردند , مانند برنامه نویسی ساخت یافته , SSADM , OOP , RAD . . يا به عبارت ديگر به چهار چوب و روش کاري معيني که شامل علائم و نمودارهاي گرافيکي و نحوه استخراج اين علائم و تبديل آنها حين فرآيند توسعه است متدولوژي گويند.

یک متدولوژی کامل علاوه بر ابزار،نشانه و فرایند بایستی موارد زیر را نیز تهیه نماید :

  • راهنمایی­هایی جهت تخمین هزینه
  •  کارهای مدیرت پروژه
  •  اندازه گیریها و متریکها
  • قالبهای تعریف شده وقابل تحویل
  • سیاستهای اطمینان از صحت نرم­افزاز
  • تشریح جزیی نقشها
  •  مثالهای عملی
  •  تمرینات نمونه
  •  تکنیکهایی جهت ارزیابی روشها
  • تعریف روشها

در تکمیل توضیحات ارایه شده بایستی گفت که هردوي فرايند و متدولوژي بر روي سوال what تمركز ميكنند، در حالي كه فرايند بر روي فرايندهاي سراسري و زمانبندي تمركز دارد، متدولوژي بيشتر بر روي تكنيكها و محصولات تمركز ميكند. در متدولوژي علاوه بر سوال قبلي موارد who, how, when و how much  نيز مطرح ميگردد.

در متدولوژي ما درباره مفهوم ,مدل ، فرايند و ابزارهاي ان حرف ميزنيم.و متدولوژیهای موردنظر براي توسعه عاملهاي هوشمند به طور معمول بایستی از ابتدا تا انتهاي فرايند توليد محصول را حمايت کنند. برای شروع نكردن از نقطه صفر در طراحی متدولوژیهای عاملگرا ,سعي نمودند كه   از روي كارهاي پيشين حركت كنند .اما با توجه به تفاوت های شیء و عامل متدولوژی های شیءگرا تكنیك های مناسبی را برای مدل سازی رفتار عامل های هوشمند مهیا نمی كند از این رو متدولوژی هایی برای بیان سیستم بر پایه عامل ها معرفی گردیده است كه به دو دسته گسترش شی گرایی و مهندسی دانش تقسیم می شوند.

  • گسترش متدولوژی های شی گرایی: متدولوژی های عامل گرا كه به این دسته متعلق هستند خصوصیاتی از قبیل داشتن تشابهات عامل و شی و استفاده از بلوغ متدولوژی های شی گرا را در خود دارند همچنین از تكنیك هایی مانند موارد كاربرد كه برای تشخیص اشیا استفاده می شود در تشخیص عامل استفاده می كند. به دلايلی همچون عمومي بودن و ارتباط نزديكي با  DAI ، ازگسترش روشهاي شيء گرا استفاده می نماييم.
  • گسترش تكنیك های مهندسی دانش: به هر حال جنبه هایی از عامل در متدولوژی های شی گرا گفته نشده است مانند حالات ذهنی یا جنبه های اجتماعی به همین جهت جنبه های مهندسی دانش برای گرفتن این خصوصیات مناسب به نظر می رسد مانند كتابخانه های هستان شناسی و كتابخانه های متدهای حل مسئله كه در متدولوژی های شی گرا استفاده می شود.

از زماني كه عاملها شخصيت شناختي پيدا كردند دانش عامل به عنوان يك تكنيك مورد استفاده قرار گرفت.ارايه تعريف دانش به عنوان فرايند گرفتن دانش در اين متدولوژيها مورد اشاره قرار گرفته است. گستره اضافه شده به متدولوژيهاي مهندسي دانش مزيت به كار بردن تجربيات در اين زمينه را دارند و همچنين امكان استفاده مجدد از ابزارها، كتابخانه هاي هستان شناسي  و متدهاي حل امكانپذير است . اما اكثر موارد و مشكلاتي كه در مهندسي دانش با آنها روبرو هستيم در طراحي سيستمهاي چندعامله هم وجود دارد مانند: گرفتن دانش، مدلسازي و استفاده مجدد . هستیم.که میتوان از متدولوژی­های مبتنی بر دانش که برای این دسته به کار میروند نام برد.

مزايای استفاده از متدولوژیهای مبتنی بر دانش ، توانايي مدل سازي وضعيت ذهني عامل‌ها از طريق مدل سازي دانش و همچنین امكان استفاده مجدد از ابزار‌ها و كتاب‌خانه‌هاي مربوط به هستان شناسی است. بایستی مواردي مانند روش‌هایی که براي سيستم مبتني بر دانش مركزي هستند[46] مد نظر قرار گيرد البته در اين روش‌ها به ويژگي‌هاي خودمختاري و پاسخ گويي به تغييرات محيط توجهي نشده است البته میتوان مدلهای دیگر را نیز مد نظر قرار داد.علاوه بر روشهای گفته شده, تكنيكهايي بر پايه تجربه توسعه دهندگان عامل نیز همچون تجربیات زیر وجود دارند:

  • تجربه Archon : محيطي كامل جهت توسعه سيستمها چندعامله، كه يك روش بالا به پايين كه قادر به تشخيص اهداف و وظايف اصلي با شكستن پايين به بالاي انها و قابليت استفاده مجدد است.
  • تجربه Made: محيطي براي نمونه سازي سريع عاملهاست،  يك متدولوژي پنج بخشي شامل: تشخيص، مفهوم سازي، شكستن، فرمال سازي، پياده سازي و تست دارد.
  • روش Awic: در اين روش طراحي به صورت تكراري است كه در هر چرخه حيات پنج مدل توسعه داده ميشود: Aمدل عامل، W مدل جهان، I مدل قابليت همكاري، C مدل هماهنگي.

همچنین روشهاي زيادي جهت پركردن تئوري رسمی[47] عاملها و پياده سازي انها ارايه شده است. تئوري رسمی شامل مشخصات عاملها كه اجازه مشخصات كامل سيستم را ميدهد. تئوري رسمی براي تحليل و صحت سنجي سيستمهاي حياتي يا پيچيده مفيد است .متدهاي رسمي در سه بخش مشخصات سيستم، برنامه نويسي مستقيم سيستم و صحت سنجي سيستم به كار گرفته ميشوند . روشهاي ديگری براي مدلسازي منطق وجود دارند، كه براي بازنمايي جنبه هاي پوياي عاملها استفاده ميشوند. در کل میتوان گفت هر  متدولوژی عاملگرا با هر شرایطی که برای طراحی آن در نظر گرفته میشود, بایستی شامل ۵ مرحله زیر که هر کدام تاثیر خود را دارند باشد :

  1.  تشخیص نقشها[48] در حوزه برنامه کاربردی
  2.  تشخیص مهارتهای اصلی برای نقش عاملها
  3. مدل سازی دانش درباره حوزه برنامه های کاربردی با نقشها
  4. پویا بودن  ساختار معماری که در جریان اطلاعات تحلیل شود.
  5.  ساختار سازمانی یا همان معماری سیستمهای چند عامله که طراحی گردد.

در اریه  متدولوژيهای مبتنی بر شیءگرایی براي تحليل عاملها سه مدل عامل، سازمان و همكاري درنظر گرفته شد و قدمهاي فرایند آنها به سمت مدلسازي این موارد پیش رفت. ازجمله متدولوژیهای مبنتنی بر شیءگرایی میتوان به MASE یا GAIA اشاره نمود. و از متدولوژیهای مبتنی بر دانش نیز به Tropos و یا CoMoMAS [49] را میتوان نام برد.از سال ۱۹۹۲ تا کنون بیش از ۷۰ متدولوژی با کاربردهای متفاوت معرفی گردیده است.نکته قابل توجه اینست که در سال ۲۰۰۲ نزدیک به ۱۵ متدولوژی معرفی گردید و سپس معرفی  متدولوژیهای جدید  کاهش یافت و بیشتر تحقیقات به تکمیل متدولوژیهای پیشین پرداختند.

بعضي از متدولوژيهاي AOSE جداي از مدل فرايند پياده سازي شده اند و قابليت كار در چند مدل فرايند به صورت همزمان را دارند. در اين مبحث متدولوژيها را بر اساس نزديكي انها در قالب مدل فرايند در نظر گرفته شده , زمان ارایه وکاربردیتر را مورد بررسي قرار ميدهيم.اهمیت مدل از آن جهت است که در صورتی متدولوژي در مدل فرايند قرار نگيرد ، امكان انجام پروژه در زمان و هزينه مشخص وجود نخواهد داشت.او اين رو بنا بر دسته بنديهاي پنج گانه CMM توسط paulk et al 1995 متدولوژيهايي مود بررسي قرار ميگيرند كه تجربيات كافي بر روي انها وجود داشته باشد تا قابليت ارزيابي را دارا باشند.

 

2-2.           متدولوژی CoMoMAS : ” گلاسر” در سال ۱۹۹۶ يك گسترش را درزمينه اضافه کردن  مدل عامل براي بيان معماري عامل , مدل تخصص براي بيان رقابت شناخت و بازخورد  شناخت حل مساله , مدل وظيفه براي تقسيم وظايف، مدل همكاري، مدل سيستم براي سازمان، مدل طراحي براي در كنار هم قرار دادن مدلهاي قبلي ارایه نموده است که CoMoMAS نام دارد. این متدولوژی مبتنی بر دانش است .

 

2-3.           متدولوژي MASCommonKADS  : در سال ١٩٩٧ توسط” ايگلاسياس” با گسترش مدل تعريف شده شيءگرا براي سيستمهاي چند عامله معرفي شد كه كاملا از مدل فرايند حلقوي پيروي ميكند. با فاز مفهوم سازي براي جمع آوري نيازهاي كاربر آغاز ميشود، و مدل موارد كاربرد ايجاد ميگردد. براي تحليل و طراحي مدلهاي زير را ايجاد ميكند: مدل عامل، مدل وظيفه، مدل تخصص، مدل هماهنگي،مدل سازماني، مدل ارتباطي و مدل طراحي. تطبيق اين متدولوژي با سيستمهاي چند عامله جديد مشكل است.  در اينجا فاز مفهوم سازي كه فازي غير رسمي از گرفتن نيازمنديهاست در کامل نمودن جد خود  CommonKADS به ان اضافه شده است . به صورت کلی میتوان گفت كه متدولوژيهاي شيء گرا و پروتكلها نيز به ان اضافه شده اند که اولين تشريح ان از ديد كاربر است و به وسيله چارت توالي پيغامها رسمي میشود.این متدولوژی مبنتی بر دانش است.

 

2-4.           متدولوژی [50]DESIRE :اين متدولوژي در سال ۱۹۹۷ توسط برازير معرفي شد كه شامل طراحي و مشخصات اجزاي منطقي ارتباطي است.به جاي سطح پياده سازي ، مشخصات سيستم تكنيكهاي مبتني بر دانش را استخراج ميكند. اين متدولوژي ديگاهي از يك عامل تنها و قابليتهاي تعاملات بين عاملها و درون عاملها را ارايه ميكند. اين متدولوژي به صورت جزيي جنبه هاي سازماني را در قالب قواعد كنترل وظايف و در سطح دانش در قالب ارتباطات اطلاعاتي  ميگيرد.

در اين متدولوژي مدلهاي زير حمايت ميشوند: تشريح مساله، طراحي مفهومي، طراحي جزييات و منطق طراحي .همچنيين محيط مدلسازي آن اجازه طراحي جديد و نمونه جديد به صورت تكراري را ميدهد. در طول فاز مشخصات نيازهاي غير رسمي به رسمي تبديل ميشوند و عمل صحت سنجي با نمادهاي رياضي انجام ميگردد . مدل فرایند آن تبدیلی است و بر پایه مهندسی دانش طراحی شده است.از جمله زبانهای فرمال براي بيان مشخصات عاملها ميتوان به DESIRE اشاره نمود.

2-5.           متدولوژی MASE : درسال۱۹۹۹ توسط “دلوچ” معرفی شد. از متدولوژيهاي قديمي شيء گرا است كه از چرخه كامل توسعه پشتيباني ميكند. اين متدولوژي عاملها را به عنوان موجوديتهاي خودمختار و پيشرو نميبيند بلكه به عنوان فرايندهاي ساده نرم افزاري به آنها نگاه ميكند كه خصوصيات پيشكارهاي ضعيف را دارند. در واقع اشياء با خصوصيات پيشكارهاي ضعيف هستنداست.در اين متدولوژي به جاي صحبت درباره اهداف كاربر در باره اهداف سيستم بحث ميشود. اين متدولوژي دياگرام اهداف دارد اما بازنمايي براي باور عامل ندارد. خصوصياتي همچون بررسي ثبات و قابليت رديابي به وسيله اين متدولوژي حمايت ميشود. در زمان ارایه, اين  تنها متدولوژي بود كه به گسترش عاملها ميپرداخت. متدولوژی MASE , در هفت مرحله مساله را به پیاده­سازی میرساند.  ويژگي‌هاي عامل نظير ”خود مختاري“، ”خلاقيت“، ”پيش فعال بودن“ در آن مورد توجه نمي‌باشد. عامل ها به صورت موجوديت‌هاي نرم‌افزاري فرض مي‌شوند كه براي رسيدن به يك هدف خاص با هم همكاري مي‌كنند. هفت قدم دارد كه سه تاي آن در مرحله تحليل و چهارتاي آن در طراحي است.

گرفتن اهداف: يكي از تكنيكهاي شيءگرايي گرفتن اهداف است.در اين متدولوژي هدف يك انتزاع از نيازمنديهاي كاركردي يا غيركاركردي است. در اين متدولوژي نيازمنديها از ديد سيستم درنظر گرفته ميشوند. اين مرحله خود دو بخش دارد،در اولين قدم تحليلگر اهداف در سطح سيستم را از مشخصات نيازمنديها پيدا ميكند در قدم بعدي به آنها ساختار ميدهد و سلسله مراتب اهداف ايجاد ميشود.

به كارگيري موارد كاربرد: سيستم به عنوان يك سازمان در نظر گرفته ميشود.بر اين اساس با انجام قدم اول به تعريف سناريوها و موارد كاربرد جهت مشخص نمودن نقشها ، تعاملات و روابط درون سيستم ميپردازيم. در قدم دوم بر اساس سلسه حوادثي كه اتفاق مي افتد دياگرام توالي را ميكشيم.

بازتعريف نقشها: اين قدم آخرين كاريست كه در فاز تحليل انجام ميشود ، در اينجا امكان دارد نقشها تركيب شده  ، شكسته شوند يا نامگذاري مجدد انجام پذيرد. در اينجا نگاشت اهداف به نقشها انجام ميگيرد و كاري را كه يك نقش بايستي انجام دهد تا به هدف معيني دست يابد تعريف ميكنند. براي اين منظور مدل وظايفي كه بايستي براي رسيدن به هدف انجام شود كشيده ميشود.

ايجاد كلاس عامل: در اينجا با دو خصوصيت كلاس عامل تعريف ميشود. ابتدا در كلاس عاملها بر اساس اهداف مشخص شده نقشها مشخص ميشوند. در بخش دوم مكالمه ميان عاملها در سطح بالا تعريف ميشود، كه بر اساس ارتباطات خارجي نقشها تعريف ميشوند. اين كار دياگرام كلاسهاي عامل را ميسازد.  بازنمايي عاملها در MASE به وسيله كلاس عامل است.

ايجاد مكالمه: در اينجا جزييات ارتباطات دياگرام وظايف در قالب ماشين حالت مشخص ميشود.هر مكالمه با دو دياگرام كلاس مشخص ميشود، يكي براي آغاز مكالمه و ديگري براي پاسخ آن ، كه هركدام توالي رشته پيغامها را نشان ميدهد.

نصب عاملها: تا حالا طراحي كلي كلاس عاملها انجام گرفته اما ريز طراحي ساختار آنها انجام نشده است از اين رو MASE با استفاده از دياگرام معماري عاملها كه ميتوان از BDI  در آن استفاده نمود به بيان جزييات ميپردازد.

طراحي سيستم: چهارمين قدم نهايي از فاز طراحي، طراحي سيستم است كه با توجه به نصب و توزيع عاملها در مرحله قبل انجام ميپذيرد. محصول طراحي اين بخش دياگرام نصب است كه تعداد، نوع و محل عاملها را در سازمان مشخص مينمايد.

به صورت کلی در گرفتن اهداف بخش دريافت نيازمنديها به صورت جزيي مورد توجه قرار ميگيرد. فاز تحليل بر روي مشخص نمودن نقشها ، وظايف و تعاملاتشان تمركز دارد.در فاز طراحي مواردي همچون كلاس عاملها، گفتگوهايشان و دياگرامها مطرح ميشوند. اين متدولوژي براي سيستمهاي بسته مناسب است. سيستم بسته سيستمي است كه مشخصات ان مخفي باقي ميمانند و با سيستمهاي ديگر نميتواند ارتباط برقرار نمايد.در اين سيستم به دليل بسته بودن عاملها بايستي از قبل شناخته شده باشند و هر عامل به عامل ديگر اعتماد داشته باشد. به همين جهت بر روي مباحث سازماني تكيه ندارد و در فاز صحت سنجي و اعتبار و تست به صورت جزيي بحث مينمايد.

این متدولوژی با ارایه گسترش­های جدید مشکلات موجود در متدولوژی را تا حدودی حل نموده است.بنابر نظر نويسنده اي متدولوژي به صورت تكراري و تكاملي ميتواند به كار گرفته شود، اما در كارهاي ارايه شده به صورت ابشاري استفاده گرديده است.از دو زبان agml و AgDl براي بيان عامل استفاده ميكند. متدولوژي ان تكراري است و هر شيء كه ايجاد ميشود در دو مسير رو به عقب و جلو تعقيب ميشود. ابزار حمايتي ان AgentTool است.

2-6.           متدولوژي MASSIVE : در سال ۱۹۹۹ توسط “لیند” معرفي شد كه يك متدولوژي عملگراست.  بر روي روشهاي بر پايه ديد استوار است و ديدهاي آن عبارتند از: محيط، وظيفه، نقش، تعامل، اجتماع، معماري، سيستم. به همين دليل ميتوان مدلهاي مختلفي را بر پايه ديدها به صورت افزايشي  ارايه نمود. ديدها به صورت مرحله اي كامل ميشوند، كه مهندسي ديد تكراري ناميده ميشود. بخش قابل توجه ديگر اين متدولوژي كه “كارخانه تجربه” ناميده ميشود، چهارچوبي مفهومي را براي فرايند يادگيري در سازمان مهيا مينمايد. اين كار اجازه توسعه مدل براي پروژه ها را بر اساس تجربه به دست آمده ميدهد . اين متدولوژي تمامي فازها را به جز نيازمنديها پوشش ميدهد. اين متدولوژي همچنين در بخش نوتيشنهاي AUML دچار كمبودهايي است، اما با توجهي كه به مدل فرايند ميكند يك متدولوژي مورد توجه است.

2-7.           متدولوژی  GAIA  : در سال ٢٠٠٠ توسط “وولدریج” معرفي گرديد كه گستره هاي آن بر روي انتزاع سازماني براي تحليل و طراحي سيستمهاي چند عامله تمركز دارند. دو جنبه ماكرو و ميكرو دارد كه بيانگر جنبه هاي اجتماعي و درون عامل هستند. براي نشان دادن رفتار عامل در سازمان ، ساختار سازمان و قواعد سازماني مدل ميشوند. اين خاصيت، متدولوژي را براي حالتهايي كه عاملها از ذينفعان مختلف هستند و قرار است با سلايق مختلف در يك محيط باز عمل كنند مناسب نشان ميدهد.Gaia سيستم عاملگرا را شبيه به يك سازمان در نظرميگیرد كه در آن هر عامل نقشي را بر عهده دارد. در حين عمل طراحي هرچند مدل آن خطي است ولي پيشنهاد شده كه حركت روبه عقب جهت برطرف نمودن كاستيها انجام گردد . Gaia اولين متدولوژي بود كه فرايند تحليل و طراحي mas را از نيازها شروع كرد.

تنها دو فاز  تحليل و طراحي را پوشش میدهد. در اين متدولوژي تعامل ميان فازها تعريف نشده و در فاز تحليل چهار خروجي توليد ميشود: مدل محيطي،مدل اوليه نقشها، مدل اوليه تعاملات، مجموعه قواعد سازمانی . و فاز طراحي موارد مقابل را تعريف ميكند: ساختار سازماني كلي، مدل نقشها و تعاملات كامل شده، مدل عاملها و مدل سرويسها. با توجه به اينكه اين متدولوژي از انهاييست كه اميدبخش به نظر ميرسد اما به دليل پوشش تعداد كم فازهاي براي حالاتي كه حوزه محدود و يا نيازمنديها پايدار باشند مناسب است.

در فاز تحليل در قدم اول نقشها به وسيله تحليلگر تعيين ميشوند، و مدل اوليه نقشها از آن ساخته ميشود. پس از آن تعاملات مشخص شده و مدل اوليه تعاملات كه شامل پروتكلهاي ارتباطات است مشخص ميگردد. در نهايت محصول آن مدل نقشها است.

در فاز طراحي نگاشت مفهوم دريافت شده به موجوديتها انجام ميپذيرد. ابتدا مدل عاملها بر اساس نگاشت نقشها به آنها ايجاد ميگردد. سپس بر اساس سرويسهايي كه هر نقش ارايه ميكند مدل سرويس ايجاد ميشود، كه خود شامل ورودي ، خروجيها و فعاليتهاييست كه از پروتكلها استنباط ميشود. در نهايت بر اساس محدوديتهاي مشخص شده مدل آشنايي كه مشخص كننده ارتباطات ميان عاملهاست تعيين ميشود و به اين ترتيب ساختار سيستم و عاملها هردو طراحي ميشود. در مقاله GAIA4E ابزار معرفي شده است كه از توسعه اين متدولوژي در بخش طراحي حمايت ميكند.اين كار به وسيله يك افزونه كه به نرم افزار ECLIPSE اضافه ميگردد مهيا ميشود.یکی دیگر از ابزارهای  مورد حمايت ان MASDK است.این متدولوژی 3 سال بعد توسط همین نویسنده بهبود یافت و به گایا گسترش یافته نامیده شد. در گایا گسترش یافته بعضی از مفاهیم سازمانی همچون ساختار و پویایی اضافه شدند، به گونه­ای که مانع از تداخل نقش­ها در یکدیگر شوند. در این ساختار می­توان یک یا چند ساختار سازمانی دیگر نیز تعریف نمود وعامل­ها با یکدیگر ارتباط داشته باشند.  اين متدولوژي در ادامه با تعريف متدولوژي ROADMAP و اضافه نمودن قابليتهاي مدلسازي براي برنامه هاي اينترنتي بهبود يافته است.

 

2-8.           متدولوژی MESSAGE : اين متدولوژي در سال ۲۰۰۰ توسط “کایر” معرفی شد. MESSAGE كار نهايي تحقيقات دوساله EURESCOM است.هدف آن توسعه متدولوژي براي حمايت از توسعه سيستمهاي چندعامله است.از مدل چرخه حيات RUP حمايت ميكند . متدولوژي به فعاليتهاي تحليل و طراحي محدود شده است. زبان UML  به عنوان پايه توسعه اين متدولوژي و نهادهايي جهت گسترش آن به عاملها  در نظر گرفته شده است. برنامه هاي كاربردي كه بر مبناي اين متدولوژي ساخته ميشوند در حوزه ارتباطات سيار هستند.

 

فاز تحليل: اين متدولوژي بر اساس ديدگاه توسعه يافته  و مدل تحليلي آن شامل پنج ديد است. ديد سازماني كه بر نهادها موجود در سيستم و محيط اجرايي تمركز دارد. در اينجا عاملها با بياني سطح بالا از روابطشان براي رسيدن به يك هدف همكاري ميكنند.ديد هدف/ وظيفه كه مانند سلسله مراتب اهداف در MASE است و ساختار اهداف را بيان مينمايد. اضافه بر آن چگونگي بازنمايي يك وظيفه جهت نيل به هدف را نيز بيان ميكند.ديد عامل در ادامه ديد سازماني ساختار كلي سيستم را گررفته و عاملها و نقشها به صورت مجزا را شبيه به Gaia با حمايت از دياگرامها و شكلها بيان ميكند.        ديد تعاملات به روابط ميان عامل و نقش ميپردازد و در قالب دياگرامهاي تعاملات آنها را بيان مينمايد.  در اينجا دلايل ايجاد تعامل نيز به عنوان انگيزه در نظر گرفته ميشوند. ديد حوزه به بيان مفهومها و روابطي مشخص كه بايستي در سيستم مورد نظر به كار گرفته ميشود ميپردازد.

فاز طراحي:  برعكس فاز تحليل اين فاز به خوبي مستند نشده است، نظر نويسنده بر اينست كه اين امر باعث انعطاف پذيري بيشتر ميشود. در مستنداتي كه بر پايه پروژه هاي انجام شده با اين متدولوژي جمع آوري شده ، دو شيوه براي اين كار در نظر گرفته شده است. يكي معماري گرا كه بر اساس آن سيستم سازماني شامل چندين عامل است و ارتباطات داخل عاملها ساختار داخلي را ميسازد.در مدل ديگر طراح بايستي تصميم بگيرد كه چه ساختاري را انتخاب نمايد.يكي از راهكارهايي كه اين متدولوژي انتخاب كرده به كارگيري چهارچوب FIPA  است تا فعاليتهاي ريز طراحي را پوشش دهد. ابزار ان MetaEdit است و از روشهای مبتنی بر مهندسی نرم افزار به شمار میرود.

 

2-9.           متدولوژي TROPOS : توسط “برشیانی” و همکاران در سال ۲۰۰۱ این متدولوژی معرفی گردید. اين متدولوژي به وسيله افراد دانشگاهي از كانادا و ايتاليا نوشته شده است. در تمامي فازها مفاهيم عاملگرا به كار رفته است و  يكي از تفاوتهاي عمده آن با متدولوژيهاي ديگر در نظر گرفتن نيازمنديهاي ابتدايي در حوزه تحليل و تشخيص براي ذينفعان است. از تمامي فازهاي توسعه نرم افزار حمايت ميكند. TROPOS  مدل i* را كه نشانه­هایي براي اكتور، هدف و وابستگيهاي اكتورها ارايه ميكند سازگار كرده است . I* چهارچوبی جهت مهندسي نياز‌ها بر اساس روش‌هاي مبتني بر عامل است.اين چهارچوب براي مدل‌سازي نياز‌ها در يك سيستم كه داراي چندين عامل با خواست‌هاي متفاوت باشند، قابل استفاده است ، همچنین این مدل در يافتن اهداف سيستم، اولويت بازيگران سيستم و ارتباط آنها با يكديگر، نحوه و امكان سنجي دستيابي به اهداف سيستم سودمند است. مفهومات اين متدولوژي بر پايه بازيگران و اهداف و نقشه هاي آنهاست. اهداف كاربران به عنوان منبع اصلي مورد تحليل قرارميگيرد و در قالب الگوريتمهاي غيرقطعي بيان ميشود

در تحلیل نیازمندیها ، نیازمندیها به دو دسته نیازمندیهای اولیه و آخر تقسیم میشوند. نيازمنديهاي اوليه: درك اوليه از مساله و سازمان كه نتيجه ان ساخت مدل سازماني براي اهداف و اكتورها و وابستگي ميان انهاست.نيازمنديهاي آخر سيستم را در محيط عملياتي تشريح ميكنند.

نيازمنديهاي ابتدايي: فاز نيازمنديهاي اين متدولوژي از چهارچوب مدلسازي *i استفاده مينمايد. هدف از تحليل نيازمنديهاي ابتدايي ، مشخص نمودن ذينفعان در حوزه هاي مربوطه و علايقشان است. TROPOS  از مفهوم بازيگر و اهدافش جهت مدلسازي ذينفعان و علايق استفاده ميكند. اهداف به دو دسته اهداف سخت كه نيازها كاركردي هستند و اهداف نرم كه نيازهاي غيركاركردي تقسي ميشوند. دو مدل براي بازنمايي وجود دارد، اولي دياگرام بازيگران كه به ذينفعان و روابطشان اشاره ميكند و دياگرام اهداف كه نمايانگر تحليل اهداف و نقشه ها است اهداف به صورت سلسله مراتبي با علامات And و Or تجزيه ميشوند كه تركيب آنها دستيابي كامل يا جزيي به يك هدف را بيان مينمايد.

نيازمنديهاي انتهايي: اين نيازمنديها شبيه به اوليه مراحل تحليل و مدلسازي را در خود دارند. مهمترين كاري كه در اينجا صورت ميگيرد مدلسازي سيستم هدف ومحيط آن است . در اينجا همچنين وابستگيهاي بازيگران و نيازمنديهاي كاربردي و غيركاربردي نيز مشخص ميشد.

طراحي معماري:مرحله بعدي در TROPOS است. زيرسيستمها، داده ها و جريانهاي كنترلي در اينجا تعريف ميشوند. هدف اصلي قدم اول تعريف سازمان كلي از سيستم است، كه با دياگرام بازيگران توسعه يافته نمايش داده ميشود. در اينجا بنا بر تحليل انجام شده ممكن است بازيگران جديدي اضافه شوند. همانند اهداف هر بازيگر ممكن است به زير بازيگراني شكسته شود. قدم دوم شامل مشخص كردن تواناييهاي بازيگران براي انجام وظايفشان است كه بر اساس همان دياگرام قدم اول انجام ميشود. در قدم سوم تمامي عاملها با قابليتهايشان بايستي توانايي رسيدن به اهداف كلي سيستم را داشته باشند. براي اين كار ميتوان از الگوهاي از پيش تعريف شده اين متدولوژي استفاده نمود.

طراحي جزييات: فاز طراحي جزييات شامل تعريف مشخصات يك عامل در ريزخصوصيات است. براي نمايش اين جزييات از دياگرام فعاليت استفاده مينمايد.هر نقشه يك گره فعاليت است و لبه هاي انتقال حوادث هستند. تعاملات ميان عاملها با دياگرام تعاملات عامل نمايش داده ميشود كه در حقيقت همان ديگرام توالي در AUML هستند.

پياده سازي: اين متدولوژي چهارچوب BDI و به صورت ويژه JACK را انتخاب نموده است. JACK از برنامه نويسي عاملگرا حمايت مينمايد و شامل پنج ساختار عامل، قابليت ، رابطه پايگاه داده، حادثه و نقشه است. پس از تحليل تعداد مشخصي  از اهداف ، زيرهدفها استخراج ميگردند و در تكرارهاي متفاوت كاملتر ميشوند.فاز پياده سازي آن بر اساس ابزارهاي AUML است.

ساختار ديگري كه از طراحي برپايه مفهومات عامل و مراحل اين متدولوژي كار ميكند ، يك گستره براي ابزار StarUML است. اين متدولوژي تمامي فازها را در بر ميگيرد و براي سيستمهايي مناسب است كه در آنها تغييرات رخ ميدهد و ناپايدار هستند. و براي پروژه هايي كه سريع توسعه داده ميشوند مناسب نيست. همچنین به وسيله Taom و OpenOme حمايت ميشود.

 

 

 

 

 

2-10.      متدولوژی ADELFE :براي توسعه سيستمهاي چند عامله سازگار[51]به كار ميرود ADELFE. يك پروژه ملي در فرانسه است كه در سال ٢٠٠٠ آغاز شد و پايه آن متدولوژيهاي شيءگرا هستند. از RUP پيروي ميكند و از نشانه هاي UML و AUML استفاده مينمايد. نرم افزار سازگار در محيطهايي كه شرايط پيش بيني نشده وجود دارد يا در سيستمهاي باز به كار گرفته ميشود.

در اين متدولوژي نوع خودمختار بودن عامل براي سازگار شدن با محيط خاصيت ضعيفي در نظر گرفته شده و سعي بر اين است كه نوع سازگاري آن با محيط در حال تكامل را قوي نمايند.به همين منظور از تئوري AMAS  استفاده مينمايد عاملهايي كه در اينجا به عنوان عاملهاي همكار در نظر گرفته ميشوند در AMAS رفتارشان پنج بخش مهارت، بازنمايي جهان، زبان تعامل، استعداد و نگرش اجتماعي را دارد.

اصل تئوريAMAS  ميگويد كه براي هر سيستم مياني كه يك همكاري تعاملي را به عنوان يك قابليت عرضه ميكند، قابليت برابري در محيط خارج آن وجود دارد. اين متدولوژي به همين دليل بر روي طراحي سيستم هاي مياني جهت همكاري تعاملي تاكيد دارد. به همين دليل تمامي كدنويسي  در عاملها انجام نميشود چرا كه بعضي قابليتها به صورت همكاري در سيستم به وجود مي آيند و عاملها قابليت سازگار كردن خود را دارند. تغيير تعاملات عاملها ممكن است سيستم را به يك سطح و كاربرد ديگر ببرد. همچنين سيستم بايستي در شرايط شكستي كه تعاملي اتفاق[52] نميافتد ،خود را سازگار نمايد. به صورت روشن تر يك عامل بايستي سه نوع NCS را تشخيص دهد:

  • وقتي كه سيگنالي از محيط مي آيد و آن را درست تشخيص نميدهد
  • هنگامي كه اطلاعات درك شده در فرايند عامل تاثير نميگذارد
  • هنگامي كه نتايج بدست آمده تاثير بي خاصيتي در محيط مي نهد

فرایند آن شامل 6 جريان كاري است که عبارتند از نيازمنديها اولیه،نیازمندیهای نهایی، تحليل ، طراحي،پیاده­سازی و تست، كه هركدام در پايان ميتوانند بازگشت و تصحيح داشته باشند. تعریفهای کاری 4 مرحله را به همراه زیر بخشهای آن در شکل میتوانید ببینید.

فاز نيازمنديها كه از TROPOS گرفته شده است قدم اصلي و ابتدايي كار است و براي AMAS سازگار شده است. در نیازمندیهای اولیه به تعریف نیازمندیهای کاربر، صحت سنجی نیازمندیها، تعریف نیازمندیهای مورد قبول ، تعیین کلیدواژه­ها و مشخص کردن محدودیتها انجام می­پذیرد.در نیازمندیهای نهایی مهم است كه مدل محيطي ايجاد گردد. سپس بایستی از موارد کاربرد و دیاگرامهای آن اطمینان حاصل نمود. سپس نمونه­های واسط کاربر بهتری ساخته خواهد شد و صحت سنجی آن انجام می­پذیرد. اين متدولوژي بر اساس RUP توسعه يافته و با انجام فاز نيازمنديها توسعه دهند در مرحله تحليل به سوي انتخاب فن آوري چندعامله سازگار هدايت ميشود.

در فاز تحليل ساختار سيستم در قالب مولفه ها ايجاد ميشود . در فاز تحليل دو فاز تشخيص عامل و سنجش تئوري به فازهاي RUP اضافه شده است . در AMAS تشخيص عامل مانند متدولوژيهاي MESSAGE و PASSI است، البته اينجا توجه به پيدا كردن عاملهاي همكار است.جريان كاري تحليل شامل قدمهاي تحليل حوزه و مطالعه معماري سيستم، مشخص كردن تئوري AMAS ، تشخيص عاملها و مطالعه رابطه تعاملات نهادها است، تا طراح از كفايت آن در حل مساله اطمينان حاصل نمايد.خروجيهاي اين قسمت دو دياگرام فعاليت و توالي هستند كه جهت نشان دادن تعامل محيط با موارد كاربرد به كار ميروند. در نهايت در فاز طراحي به سوي انتخاب مدل عامل و تشريح رفتار آن پيش ميرود.

در فاز طراحي مدل عامل و NCS به RUP اضافه ميشوند. در فاز طراحي كه چهار بخش است: ريز معماري و مدل عاملها، معماري عامل، مدل غير همكاري عاملها و دياگرام كلاس مشخص ميگردند. معماري مورد نظر اين متدولوژي همكاري است.در مرحله اول اين فاز به ايجاد مدل عامل و معماري به صورت جزييات ميپردازيم كه از الگوي خاص معماري عامل همكار در اينجا استفاده ميشود. معماري عامل همكار بر اساس AMAS يك عامل را شامل مدلهاي مهارت،بازنمايي، زبان تعامل، استعداد و نگرش اجتماعي هستند ، كه به وسيله ابزار بايستي نمايش داده شوند. در قدم بعدي مدل NCS براي هر عامل ايجاد ميشود. در مرحله بعدي دياگرام كلاس هاي متفاوت بازتعريفي براي دياگرامهاي قبلي هستند .

در قسمت طراحی از ابزار نمونه سازي سريع OpenTool استفاده ميشود كه ابزاري شبيه به RationalRose است. ابزار دیگر این متدولوژی ADELFE interactive tool  است که از تئوری AMAS حمایت می­نماید.

 

2-11.      متدولوژی INGENIAS :در سال ٢٠٠٢ توسط “گومزسانز” بر روي كار قبلي كه متدولوژي MESSAGE  انجام داده معرفي شده است. هدف آن حمايت از توسعه سيستمهاي چندعامله با حمايت از فازهاي مختلف است . سيستمهای مورد نظر این متدولوژی در زمينه هاي نظارت محيط، پيش آگاهي از يك وضعيت و انجام يك عمل در تعامل با كاربر به كار ميروند. مانند سيستمهاي نظاره و جستجوي ترافيك شهري كه بايستي چندين شيء را نظارت كنند.نوتيشنهاي AUML در آن سازگار شده است. مستندات و ابزار بسياري دارد، از شيوه مدل گرا استفاده ميكند كه استقلال پياده سازي از پلت فرم را حمايت ميكند مدل آن به صورت فرايند تكراري است، كه شامل زمان – بيانگر چرخه حيات و محتوا- كه محصولات را مدل ميكند.پنج متا مدل دارد: مدل عامل، مدل تعاملات ، مدل اهداف و وظيفه، مدل سازمان، و مدل محيطي.

اين متدولوژي با سازگار كردن [53]USDP به دو شكل تكراري و افزايشي فازهاي تحليل ، طراحي، كد وپياده سازي را پوشش ميدهد. مانند متدولوژي MASSIVE براي توسعه سريع مناسب است. و ابزارها و نشانه هاي استاندارد براي آن موجود است .

 در مدل سازمان چگونگي گروه شدن عاملها ، ساختار و رفتار مورد بررسي و مدلسازي قرار ميگيرد.براي دادن منابع از جريانهاي كاري استفاده ميشود.در مدل سازماني نقشه هاي مرتبط با وظايف در نظر گرفته ميشوند.در مدل عامل ، يك عامل بدون درنظر گرفتن تعاملش با محيط قابليتهايش تشريح ميشود.در مدل وظيفه و كار ، انگيزه ها و نحوه تاثير آنها بر مسوليتها مورد توجه است. در مدل تعاملات ، عاملها، نقشها، اهداف و واحدهاي تراكنش در جزييات نحوه تعامل و هماهنگي مدل ميشوند. در مدل محيطي آنچه در اطراف سيستم است مدل شده و فقط شامل عناصر عامل، منابع و برنامه هاي كاربردي است.

جنبه هاي اجتماعي مانند ارتباطات، منطق، وسايل، احساسات و سنتها هستند كه بايستي مدلسازي شوند. ابزار ساخته شده در جهت حمايت از اين مفاهيم در قالب متدولوژي INGENIAS پرداخته است. كارهايي كه در آينده در اين متدولوژي ميتوان انجام داد، گسترش متا مدل آن براي ساخت زبان مشخصات بر اساس حوزه هاي مورد استفاده است، كه منجر به راحت تر نمودن مدلسازي فعاليتها براي دانشمندان حوزه اجتماع ميشود.

اين تنها يك متدولوژي نيست بلكه با ابزار همراه است. سعي آن در كامل كردن متامدلهاي MESSAGE است و از ادامه كار آن شروع كرده است. همچنين در اين متدولوژي خصوصيات مهم متدولوژيهاي پيشين در فازهای متفاوت نيز درنظر گرفته شده است. ساختار اين متدولوژي از سه جنبه مشخصات و نشانه ها، فرايند چرخه حيات UP سازگار شده، و ابزارهاي حمايتي تشكيل ميشود.متامدلهاي آن هركدام يك ديدگاه از سيستم چندعامله را بيان مي­نمايند.

سيستمهاي اجتماعي كاربردهاي روزمره بسياري دارند و بيشترين توجه بر روي مدلسازي رفتار جوامع انساني است كه در اين­باره از متدولوژي INGENIAS و ابزار حمايتي آن[54] IDK  استفاده ميشود، كه قابليت پياده سازي بر روي پلت فرمهاي مختلف را دارد. اين متدولوژي از سه عنصر براي مهندسي سيستم استفاده ميكند: زبان بصري براي تعريف سيستم چند عامله [55]، مجتمع سازي با فازها و جريان كاری با  USDP، و ابزار توسعه نمونه هاي متا[56]  .

 

2-12.      متدولوژي [57] PASSI : در سال ٢٠٠۲ ، متدولوژي جدید PASSI  كه تمامي فازها را پوشش ميداد توسط كازتينو معرفي گرديد. يك متدولوژي قدم به قدم تبديل نيازمندي به كد است و پنج فاز را به صورت متوالي دارد: نيازمنديهاي سيستم ،جامعه عاملها كه تحليل آن ، پياده سازي عاملها ، پياده سازي سطح كد، گسترش براي مدلسازي توزيع اجزاي سيستم در  بستر نصب.تست محصول به دو شكل تست عاملها و تست اجتماع عاملها انجام ميگردد. اين متدولوژي براي سيستمهايي كه كدنويسي انها در مراحل آخر انجام مي­شود و تغييرات كمي در نيازمنديها دارند مناسب است.براي پروژه هاي كوچك ميتوان از مدل سريع آن استفاده نمود.

  • مدل نيازمنديهاي سيستم: براي توليد موارد كاربرد و شكستن سيستم به عاملها  شامل تشريح حوزه، تشخيص عاملها، تشخيص نقشها، مشخصات وظايف
  • مدل اجتماع عاملها: براي ساخت مدل تعاملات است  و شامل تشخيص نقشها، تشريح هستان­شناسي، تشريح نقش، تشريح پروتكل است.
  • مدل پياده سازي عامل:  براي مدل سازي معماري به دو شكل تعريف ساختار عامل، تشريح رفتار عامل
  • مدل كدنويسي: جمع اوري و كامل كردن كد
  • مدل گسترش: مدل توزيع اجزاي سيستم و مهاجرت انها با اجراي تنظيمات .

مدل فرایند این متدولوژی تکاملی افزایشی است و در آن اهمیت زیادی به اهداف داده نشده است .از زبانها ی XML و UML پشتیبانی مینماید.ابزار مورد حمايت ان PTK است طراحي جزئيات كه بر روي قابليتها داخلي و نقشه و حوادث تمركز دارد.

2-13.      متدولوژیPrometheus :در سال ۲۰۰۲ توسط کرونکا معرفي گرديد و تمركزش بر روي ساخت عاملها با استفاده از چهارچوب BDI است، و راهنماييهايي را براي افراد كم تجربه جهت تحويل سيستمهاي چند عامله ميدهد. متدولوژي با ريز جزييات جهت پوشاندن تمامي فعاليتهاي توسعه سيستمهاي چندعامله است در قسمت­های تشخيص ،طراحي و پياده سازي كاركرده است. فازهاي مورد پوشش ان مشخصات سيستم، طراحي معماري و طراحي جزييات هستند.

مشخصات سيستم: اولين فاز است و هدف آن ساخت مدل محيطي است كه در آن اهداف و قابليتهايشان به همراه سناريوهاي موارد كاربرد توضيح داده ميشود.مدلسازي محيط به عنوان يكي از خصوصياتي كه عاملها در آن واقع شده اند مهم است از اين رو ابتدا با دو فعاليت اين كار انجام ميگردد، اول مشخص كردن ادراكاتي كه با اطلاعاتي كه از محيط مي آيند ايجاد ميگردند و اعمالي كه يك عامل تحت تاثير محيط انجام ميدهد.اين دو به وسيله توصيفگرها بيان ميشوند.دوم اهداف و قابليتهاي سيستم كه در هر مرحله بايد گرفته شوند، اين اهداف بر اساس مشخصات نيازمنديها پيدا ميشوند.

طراحي معماري : بين فاز گرفتن نيازها و ريز طراحي ساختار محاسباتي عاملها اين متدولوژي به فاز مياني طراحي معماري ميپردازد كه شامل سه فعاليت تعريف نوع عاملها، طراحي ساختار كلي سيستم و تعريف روابط ميان عاملها است.

در اينجا عاملها پايه اصلي طراحي هستند و بنا بر مشخصات سيستم قابليتها و محدوده آنها كه به دو بخش  آنهايي كه با يكديگر رابطه دارند و آنهايي كه رابطه بارزي با يكديگر دارند تقسيم ميشوند. بنا بر آن دو دياگرام جفت داده و آشنايي با عامل معرفي ميشوند. دياگرام جفت داده رابطه قابليتها با داده نمايش ميدهد و دياگرام آشنايي عامل تعاملات ميان عاملها را مانند لينك مشخص ميكند.در نهايت ساختار سيستم در قالب دياگرام كلي سيستم بيان ميشود، اين دياگرام حالت ايستا سيستم را نمايش ميدهد. جهت نشان دادن حالت پويا از دياگرامهاي تعاملات شيءگرا استفاده ميشود.

طراحي جزييات: مرحله نهايي متدولوژي Prometheus طراحي جزييات است، كه در آن ساختار و رفتار يك عامل نمايش داده ميشود. اين مرحله بر روي تعريف قابليتها، حوادث داخلي، نقشه ها و ساختار داده هاي جزيي براي هر عامل تاكيد دارد. ابتدا قابليتها با توصيفگر قابليت نمايش داده ميشوند كه شامل اطلاعاتي درباره حوادث است، سپس در سطح پايينتر انواع ديگر توصيفگرها به بيان موارد ديگر ميپردازند. همچنين اين فاز شامل دياگرام بررسي عامل نيز هست كه بيانگر قابليتهاي سطح بالاي عامل است.

در کل می­توان گفت که فاز مشخصات ، مدلسازي اهداف سيستم و سناريوها را پوشش ميدهد. فاز طراحي معماري:مدلسازي عاملها، بررسي سيستم و پروتكلهاي ميان عاملها را با AUML نشان ميدهد. فاز ريز طراحي بر روي توسعه ساختار داخلي هر عامل در قالب قابليتها تمركز دارد. هر قابليت نيز با يكي از توصيفگرهاي داده، حادثه و يا نقشه بيان ميگردد. اين متدولوژي اجازه بيان چندين مدل انتزاعي سطح بالا به صورت سلسله مراتبي را نيز ميدهد. راهكارهاي اشكال­زدايي نيز در ان درنظر گرفته شده است. به صورت جزيي به فعاليتهاي مهندسي نيازمنديها پرداخته است.علاوه بر اينها با ابزارهاي مهيا شده كد نويسي را حمايت ميكند و فرايند انجام ان خطي است. به همين جهت مشكلات مدل ابشاري را دارد. سناريوهاي ان با UML  مشخص ميشوند و ابزارهايش JDE و PDTهستند.

2-14.      متدولوژي  Roadmap : توسط “خوان و همکاران”  در سال 2002 معرفي گرديد .تمركزش بر روي جنبه هاي اجتماعي سيستمهاي باز[58] است. در واقع يك گسترش از متدولوژي Gaia است كه موارد كاربرد و سلسله مراتب نقشهاي پويا و يك سري مدل به ان اضافه شده است.تمركز زيادي بر تحليل و طراحي دارد ، در فاز تحليل تشخيص موارد كاربرد، مدل محيطي، مدل دانش، مدل نقشها و پروتكلها و مدل تعاملات انجام ميشود. هدف فاز طراحي توليد مدل عامل و مدل سرويس است.اين متدولوژي در طراحي جزئيات ضعيف است و از فازهاي ديگر نيز حمايت نميكند و با معرفي موارد كاربرد به صورت جزئي وارد فاز نيازمنديها شده است.ابزار طراحی آن Rebel  است.

2-15.      متدولوژي OPM/MAS : توسط “اشتورم و همكاران” در سال ٢٠٠٣ معرفي شد كه قابليتهاي خود را از مفاهيم شيءگرايي به ارث برده است. از مفاهيم شيءگرا براي توصيف سيستم استفاده ميكند و انها گسترش يافته اند تا خصوصيات ويژه عاملها را پوشش دهند.  همچنین خصوصيات اجتماعي و ديگاه سازماني به آن افزوده شده است. اين متدولوژي اجازه داشتن ديدهاي متفاوت از سيستم چندعامله را ميدهد و براي سيستمهاي در مقياس بزرگ كه نياز به تكامل تدريجي يا تكراري دارند مناسب است. ابزارهاي ان در حال توسعه هستند. همچنین يك نوتيشن براي توضيح ساختار و رفتار دارد كه به صورت تكاملي بازتعريف ميگردد.

2-16.      متدولوژي AOR :  در سال ۲۰۰۳ توسط واگنر  معرفی شد. متدولوژي كاملا متفاوت از بقيه است، با مدلهايي كه خارجي و داخلي ناميده ميشوند. انتزاع اصلي اين متدولوژي نهادها و روابط ميانشان هستند. روابط تعريف شده شامل همان مدلهاي UML هستند. ديد خارجي براي بيان ديدگاه يك ناظر خارجي براي توليد حوزه عاملها، قالب تعاملات، توالي تعاملات و دياگرام الگوي تعاملات است. هدف از ديد داخلي گرفتن قابليتهاي سيستم است. براي حمايت از ان ابزارهايي مانند Microsoft Visio  و AORML  وجود دارند. فرايند اصلي آن ۵ بخش دارد : تحليل حوزه، تبديل مدل خارجي به داخلي، تبديل مدل داخلي به طراحي پايگاه داده و تعريف ساختار داده، بازتعريف مدل طراحي به پياده سازي، جمع اوري كد به زبان مقصد.مدل ان چيزي شبيه به آبشاري افزايشي با كارهاي تكراري در هر مرحله است.

2-17.      متدولوژیASPECS[59]  : در سال ۲۰۰۷ توسط “کزنتینو و همکاران” معرفی گردید . در اينجا قصد نويسندگان ارايه راهكار مهندسي براي فرايند توسعه HMAS و MAS است. كه متدولوژي ASPECS با زبان بيان و مدلسازي  UML کار میکند.اين متدولوژي را ميتوان كامل شده PASSI دانست. فرايند مدلسازي HMAS از روش RIO آمده است[xix]. متامدل اوليه كه براي اين متدولوژي در نظر گرفته شده است شامل جريان كاري، راهنمايي و فعاليت است ،كه قدم به قدم از نيازمندي به كد حركت مينمايد.

در ابتدا واژه هولون[60] را بایستی تعريف كنم ، هولون يك واژه يوناني است كه به يك سيستم يا پديده اطلاق ميشود كه شامل ساختار جزء و كل است و داراي ساختاري خودسازمانده يا بازگشتي است و شامل هولونهاي ديگر نيز است وبين يك نظم و هرج و مرج متوازن است. سلسله مراتب هولون ، هولارچي خوانده ميشود. در سيستمهاي چند عامله كه شامل نهادهاي خودمختار هستند، هولونها ميتوانند به عنوان يك سري عامل با خصوصيات بازگشتي باشند كه هر عامل خصوصياتش را از رفتار عامل زيرمجموعه ميگيرد. واژه هلون از دو بخش Holos به معني كل و پسوند on به معني جزء يا نهاد كه معناي كل آن هم شامل كل است و هم جزء تشكيل ميشود

در اصل ميتوان گفت بر اساس متا مدل[61] CRIO كه شامل ظرفيت، نقش، تعامل و سازمان است طراحي اين متدولوژي براي پوشش  مراحل مشخصات، طراحي و پياده سازي انجام شده است.  يكي از اهداف اصلي اين متدولوژي پر نمودن فاصله ميان طراحي و پياده سازي واقعي در سيستمهاي چندعامله است.

در متدولوژيهاي ديگر مانند Gaia، RIO،MESSAGE و INGENIAS فرايند ساخت سيستم چندعامله با فرايند ساخت سيستمهاي قديمي متفاوت است.در اين متدولوژيها دو مفهوم جداي اجتماع عاملها و خود عامل در نظر گرفته ميشود.مزيت آنها استفاده از ديد سازماني است كه در اين متدولوژي قصد بر اينست كه مزيتهاي ديدگاه هولوني و سازماني با يكديگر تركيب شود، و يك انتزاع عاملگرا را ايجاد نمايد.

با استفاده از ديدگاه هولوني طراح با دانه بنديهاي مختلف نهادها، به مدلسازي بازگشتي زيرمولفه ها ميپردازد. كه معماري هولون راهي براي به مشاركت گذاشتن ساختار كلي و محلي در كنار يكديگر است. مدلها وچهارچوبهاي بسياري در اين زمينه از جمله PROSA[xx] و [xxi]MetaMorph به كار گرفته شده اند.

خصوصيات كليدي اين متدولوژي عبارتند از: درنظر گرفته شدن براي سيستمهاي باز و پيچيده-محدوديت آن در مدل سلسله مراتبي آن است-، سازگاركردن روش سازماني در تقسيم كردن قابليتها به صورت سلسله مراتبي،دانش هستان­شناسي مرتبط با حوزه براي بالا بردن كيفيت ميتواند استفاده شود،سه انتزاع در طراحي بر پايه مهندسي مدل گرا به كار رفته : مساله، آژانس و حل،تركيب مفهومات هولون و آژانس جهت مدلسازي سازمان و عامل استفاده بسیاری در این متدولوژی دارد . دو بخش مهم  در این متدولوژی وجود دارد:

2-17-1.فرايند: چرخه حيات اين متدولوژي به صورت تكراري-افزايشي است، از نشانه هاي گسترش يافته UML براي بيان مفهومات و از مشخصات SPEM  براي بيان ساختار فرايند استفاده مينمايد. فرايند آن شامل سه بخش فازها، فعاليتها و وظايف است. چرخه حيات آن شامل سه قسمت نيازمنديهاي سيستم،اجتماع عاملها و پياده سازي و گسترش است كه در شكل زير به تفصيل مشاهده مينماييد.

2-17-2.متامدل و مفهومات كليدي: ASPECS با سازگار كردن معماري مدل گرا MDA سه سطح مدل را بازتعريف نموده است كه هركدام حوزه ناميده ميشوند: حوزه مساله براي تشريح سازمان در بخش تحليل، حوزه آژانس براي مفهومات هولون و چندعامله در حوزه مساله، حوزه حل مساله براي پياده سازي و گسترش.

 

  • حوزه مساله : متامدل حوزه مساله شامل عناصري براي گرفتن نيازمنديهاي مساله است. يك سازمان از تعدادي نقش كه در سناريو اجرا ميشوند ميباشد و همچنين يك متن دارد كه با آنتالوژي نمايش داده ميشود. رفتاري كه براي يك نقش تعريف ميشود به عنوان مجموعه اي از وظايف و نقشها براي رسيدن به هدف تعريف ميشود . نقشها ظرفيت هايي دارد كه مشخصات انتقال قسمتي از سيستم طراحي شده يا محيطش را بيان مي نمايد. يك ظرفيت خود بيانگر رفتاري است كه قابليت انجام داشته باشد كه شامل مفهوم هاي تعاملات نقش ، و انتزاعي از رفتارهاي نقش هاي پيچيده كه شكسته ميشود ميباشد. در اين جا سازمان از ديدگاه كاركردي بررسي ميشود و به عنوان يك انتزاع سطح بالا از مجموع رفتارهاي تعاملي در نظر گرفته ميشود. مفهومات حوزه مساله عبارتند از : هستان­شناسی ،مفهوم ، پیشوند ،عمل ، سازمان ،نقش ،تعامل ، ظرفیت ،وظیفه نقش،طرح نقش وسناریو.
  • حوزه آژانس : متامدل حوزه آژانس شامل عناصري است كه ميتوانند يك راه حل عاملگرا را براي مساله تحليل شده ارايه نمايد. جواب ميتواند شامل ساختار اجتماعي به روش چند ديدگاهي باشد. فرآيند طراحي ASPECS هولون را به عنوان عنصر اصلي در نظر ميگيرد. هر هلون يك نهاد خودمختار است كه اهداف جمعي دارد، كه از تعدادي هولون ديگر تشكيل شده است. هولون اصلي را Superholon و بقيه را زير هولون مينامند. آنها را در كنار يكديگر گروه هولونيك تشكيل ميدهند. براي هولونها نقش هايي تعريف ميشود كه وضعيت عناصر عضو و غير عضو را مشخص مينمايند. مفهومات حوزه آژانس عبارتند از : ارتباطات ، گروه ،نقش عامل ،گروه هولونی ،وظیفه عامل، عمل عامل ،نهادهای خودمختار ،عامل ، هدف ،اهداف اختصاصی ، هدف جمعی ، خدمات و منابع .
  • حوزه جواب: متامدل حوزه جواب شامل عناصري است كه براي پياده سازي حل مساله طراحي شده به كار ميرود. اين عناصر براي پياده سازي چندين پلت فرم مختلف كافي به نظر ميرسد. Janus براي مهيا كردن شرايط انتقال ميان طراحي و پياده سازي هولونيك به كار ميرود. كه زبان برنامه نويسي و پياده سازي آن جاوا است . پنج مفهوم كليدي در آن حمايت ميشوند كه عبارتند از سازمان، گروه ، نقش، هولون و ظرفيت.سازمان به عنوان نهد كلاس مرتبه اول كه شامل مجموعه اي از كلاس نقشهاست تعريف ميشود. گروه شامل مجموعه اي از كلاسهاي نقش متفاوت مرتبط با سازمان در نظر گرفته ميشود. يك نقش به عنوان يك كلاس كاملا آماده انجام عمليات ديده ميشود و هولونها به ٢دسته هولون سنگين كه نخ كشي شده و هولون سبك كه غيرنخ كشي است تقسيم ميشوند. نشانه ظرفيت اجازه بازنمايي هولون با خصوصيات ابتدايي آن اجراي نقشها را ميدهد.

2-18.  نمودار تکامل متدولوژی­ها

در ادامه میتوانید رابطه میان متدولوژیهای مختلف مبتنی برعامل را ببینید. در این شکل بر اساس وابستگی یک متدولوژی به هرکدام از روشهای مهندسی و همچنین نسبت تکامل یک متدولوژی در قالب متدولوژیهای پیشین ، یالها و جهت­های گراف مشخص شده­اند.

ADELFE

ASPECS

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

فصل سوم

 

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

 

 

 

مشكلات انتخاب متدولوژی كه تلاش بسیاری را صرف تكامل و مقایسه متدولوژی های مهندسی نرم افزار كرده است ما را نیازمند ارائه چارچوب ها و تكنیك هایی جهت تحقیق در این زمینه می كند. برای این امر می توان از روش های مقایسه ای شی گرایی نیز استفاده نمود. براي مقايسه بايستي مطالعه اي نسبت به هر متدولوژي داشت و مقالات مرتبط با ان را تا حدي خواند كه امكان دارد بعضي از مطالب قديمي باشند. استفاده از چهارچوب نامتناسب براي براورد مانند استفاده از مفروضات قبلي مانند شیءگرایی نیز ممكن است منجر به مشكلاتي گردد.مشكل ديگر در ارزیابی استفاده از واژگان جايگزين در خلاصه كردنها است كه امكان دارد حس درست را به خواننده ندهد و همچنين دراستفاده ازمعنای يك واژه امكان دارد متدولوژي موردنظر از ان حمايت نكند.مورد ديگر در ارزیابی اينست كه براساس هر تعريف يك سري محدوديتها و ديد نسبت به متدولوژي استنباط ميشود. که این کار خود مستلزم متریك ها و چهارچوب های استاندارد است.

3-1 روش­های ارزیابی

با توجه به مشکلات گفته شده  و روش­های متنوع در ارزیابی ، در این بخش به ارایه چهارچوب­های استاندارد معرفی شده جهت ارزیابی متدولوژی­ها می­پردازیم :

١. كتاب روش هایی برای مقایسه متد ها نوشته شده توسط دیوید لا در سال ١٩٨٨ كه هدف اصل آن ارائه روشی علمی برای مقایسه متدولوژی ها در بخش طراحی و مشخصات نیازمندی ها است.

٢. پروژه Desmetكه در سال ١٩٩٠ آغاز شد و در سال ١٩٩٤ جزئیات آن منتشر شد كه هدف آن توسعه یك چهارچوب ابزار و تكنیك هایی در حوزه های مهندسی نرم افزار می باشد.

٣. چارچوب Nimsad كه در كتاب درك تكامل متدولوژی ها در سال ١٩٩٤ معرفی شده است.كه روش هایی را برای مشخص نمودن تفاوت ها در دیدگاه كلی،فلسفییا تئوری ارائه می كند.

٤.كتاب توسعه سیستم های اصلاعاتی ، متدولوژی،ابزار و تكنیك كه در سال ١٩٨٨ چاپ شد و هدف آن باز بینی و ارائه طرحی از یك چارچوب كلی برای طبقه بندی متدولوژی هاست.

3-1-1. تحلیل خصوصیات:

 این یك روش كیفی است كه شامل ساخت یك چارچوب و بیان خصوصیات و مشخصات در قالب آن كه قابلیت ارزیابییك متدولوژی بر اساس اهداف مشخص را دارد.بطور مثال یك نفر می تواند مدل ها، فرآیند ،تكنیك ها و تعاملات را به عنوان پارامترها در نظر بگیرد. یك راه دیگر این است كه از دید تخصصی خصوصیات كلیدییك متدولوژی مورد مقایسه قرار بگیرد. به همین جهت از دیدگاه “کیچن” [xxii] چهار طبقه اصلی ارائه شده است:

١. شیوه نمایش: بر اساس درك یك شخص و مستند سازی وی از متدولوژی مقایسه انجام می شود در این حالت زمان و هزینه بالا باید صرف شود و نتیجه نا مطمئن است.

٢. روش نمونه كاربرد: در این حالت بر اساس یك پروژه واقعی ارزیابی متدولوژی انجام می شود كه نقش ارزیابی كننده و توسعه دهندگان نرم افزار بر اساس تجاربشان در یك پروژه فرضی می تواند مد نظر قرار گیرد.

٣. روش های تجربه رسمی: شبیه به نمونه كاربرد است كه نقشهای متفاوتی دارد. در این حالت ارزیابی كنندگان متدولوژی را انتخاب می كنند مجموعه ای از خصوصیات، نقشه ها و اجرای آزمایشات و تحلیل نتایج را می سازند. در این مدل نتایج قابل اطمینانی ایجاد می شود.البته افراد زیادی را نیز بایستی درگیر كرد.

٤. روش جمع آوری اطلاعات: در این حالت كار عملی انجام نمی شود و بر اساس تجارب اشخاصی كه بعضی از متدولوژی ها را ارزیابی كرده اند و استخراج نتایج آن ها مستندات ایجاد می شود و به تحلیل آن ها می پردازد. مزیت آن صرف زمان كمتر و درگیری افراد كمتر است . صفحه ٥٤

3-1-2. شیوه برآورد قابل شمارش:

تكنیك های ارزیابی بر اساس خصوصیات معمولاً تحلیل كیفی ارائه می كند. در روش های كمی فرآیندها همانند برآورد كیفی است تنها تفاوتی را كه می توان در روش Desmet مثال زد این است كه قبل از اجراییك نمونه كاربرد یك تجربه یا یك جمع آوری كه منجر به ایجاد یك فرمول برای ارزیابی میگردد. به این شكل می توان به صورت عددی طبقه بندی را انجام داد و نتایج دقیق تری را ارائه نمود.

3-1-3. چارچوب Nimsad :

دو روش پیشین تحلیل هایی را به صورت عملی بر روی متدولوژی ها انجام می دادند. یكی از راه های بررسی به صورت تئوری چارچوب Nimsad است. این چارچوب شامل ٤ عنصر اصلی ؛ متن متدولوژی، كاربر متدولوژی، خود متدولوژی و ارزیابی این سه است. بطور مةال سؤالات مربوط به مورد اول به تشخیص و فهم مشتریان و تجارب آن ها از متدولوژی، فرهنگ و متن سیستم مورد نظر می پردازد.

علاوه بر موارد گفته شده میتوان بر اساس گفته ( k.siau& m.rossi) تكنيكهاي ارزيابي براي متدولوژيها را به شرح زير عنوان نمود:

  • بررسي بر پايه خصوصيات
  • بررسي بر اساس متا مدل
  • بر اساس متريكها
  • ارزيابي انتالوژي
  • تكنيكهاي ارزيابي تجربي

 

3-2. چهارچوب ارزیابی

 

با توجه به اینكه نتایج از آزمایشات قبلی بر روی متدولوژی­ها موجود است و همچنین معیارهایی از قبل بیان شده است. اولین معیار ارزیابی كیفی برای متدولوژی های مختلف بر پایه سه موردنزدیكی آن­ها به متدولوژی های عامل گرا تا شیءگرا، مستندات به گونه ای كه مقالات و نمونه های زیادی وجود داشته باشد و حمایت ابزار به گونه ای كه برای یك متدولوژی انتخاب شده ابزار هایی برای حمایت فازهای مختلف آن متدولوژی وجود داشته باشد را می­توان در نظر گرفت. استفاده از يك جدول و نشان دادن اينكه يك مفهوم يا يك نشانه در مقايسه چند متدولوژي،  فقط بیان کننده آن مورد خاص است که دراین متدولوژی حمايت ميشود يا نه اما به  چه اندازه را نه نشان نمیدهد.دراكثر مواقع تكرار نتايج مقايسه با همان دقت قبلی مشكل است. از این رو یک چهارچوب در نظر گرفته میشود.

همانگونه که در شکل میبینید چهارچوب ارزیابی شامل مفهوم، زبان مدل سازی، فرآیند، عملگرایی  و قابلیت عرضه در بازا و ابزار توسعه می باشد.علاوه بر موارد فوق به مسایل حمایتی  و زیربخشهای موجود را نیز به عنوان وجهی دیگر مورد بررسی قرار خواهیم داد.در اين سند هدف بررسي و ارزيابي متدولوژيهاي عامل گرا با رهيافتي وابسته به نظرات نويسنده­گان مختلف است كه به ارايه قالبی کلی  از ديدگاه­های متفاوت آنها پرداخته است. که در این چهارچوب خصوصياتي همچون خودمختاري،واكنشي، پرواكتيو، اجتماعي بودن بايستي مورد بررسي قرار گيرند.علاوه بر اين بايستي متدولوژي ازمايش شود كه آیا مواردی همچون عامل، بيليف،ديساير،اينتنشن، پيغام، نرم،سازمان، پروتكل، نقش، سرويس ، اجتماع، كار رادر بر ميگيرددر بعد فرايند موارد پوشش چرخه حیات و متن توسعه مد نظر قرار ميگيرند.از بعد عمل گراي به بررسی منابع، نياز به تخصص، مناسب بودن زبان معماري و مثالها، كاربردي بودن محدوده، مقياس پذيري میپردازیم. برای هر کدام از موارد فوق که بایسیتی مورد ارزیابی قرار گیرد، مجموعه­ای از سوالات مطرح میگردد ، تا معیاری مناسب جهت ارزیابی موجود باشد.

همچنین بایستی در باره متدولوژی­های مورد استفاده استانداردی مدنظر قرارگیرد. “IEEE ” یک سازمان مهم است ،که به ارایه­ی استانداردهایی در زمینه راهنمایی مهندسی نرم­افزار می­پردازد، که می­توان آنها را در کتابچه ­ای در این زمینه (Society 2004) مشاهده نمود. بر همین اساس می­توان یک چهار چوب اولیه را به عنوان نظم و راهکاری پیش رو در ادامه­ی کار، مد نظر قرار داد. بر این اساس مهندسی نرم­افزار به یازده زیرگروه تقسیم می شود، که عبارتند از :

▪     نیازمندی­های نرم­افزار

▪      طراحی نرم­افزار

▪     توسعه نرم­افزار

▪      تست نرم­افزار

▪      تعمیر و نگه­داری نرم­افزار

▪      مدیریت پیکربندی نرم­افزار

▪      فرایند مهندسی نرم­افزار

▪     روشها و ابزارمهندسی نرم­افزار

▪      کیفیت نرم­افزار .

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

3-2-1.  پرسش­های مرتبط با مفهوم

معماری عامل : آیا زبان مدل­سازی یا متدولوژی بر روی یک معماری خاص تاکید دارد؟

وابستگی به پلت­فرم : آیا فاز توسعه بر روی یک پلت فرم خاص تاکید دارد؟

خودمختاری : آیا مدلها وبازنمایی از خصوصیات خودمختاری عامل حمایت می­کنند؟ با چه تکنولوژی؟

واکنش مجدد : آیا مدلها از واکنش به تغییرات محیط حمایت می­کنند؟

کنش­گرایی : آیا مدلها از رسیدن به اهداف در بازه زمانی خاص حمایت می­کنند؟

رفتار همکاری : آیا مدلها از همکاری عاملها جهت رسیدن به هدف مشترک حمایت می­کنند؟

قابلیت ارتباط : آیا مدلها از توانایی عاملها جهت ارتباط با یکدیگر حمایت می­کنند؟

زبان ارتباطی : زبان ارتباطی سطح بالا است یا پایین ؟ مشخص کنید.

جنبه­های ذهنی : آیا مدل از بازنمایی جنبه­های ذهنی مانند اعتقاد،میل و منظور پشتیبانی میکند؟

سازگاری: آیا مدل از قابلیت عامل در جهت یادگیری حمایت می­کند؟

ادامه در شرایط زودگذر : آیا مدل از ادامه کار در شرایط زودگذر پشتیبانی می­کند؟

قابلیت کنکاش : آیا مدل از کنکاش عامل در پیدا کردن راه­حل مناسب برای حل مساله پشتیبانی می­کند؟

3-2-2.   پرسش­های مرتبط با زبان مدل­سازی

 

بازنمایی زبان مدل­سازی: چه نوعی از زبان مدل­سازی استفاده می­شود؟ رسمی ، غیررسمی ، ترکیبی

متامدل : آیا متدولوژی بر اساس متامدل است؟

انواع مدل : چه مدلهایی استفاده می­شود؟

وابستگی مدلها : میزان وابستگی مدلها بالا است؟

کامل بودن نشانه­ها : آیا زبان مدلسازی از بیان تمامی مفهمومات متدولوژی پشتیبانی می­کند؟

همزمانی : آیا زبان مدلسازی از بیان فرایندهای همزمان پشتیبانی می­کند؟

وضوح : آیا برای بیان هر مفهوم یک دیاگرام جداگانه وجود دارد؟

کامل بودن : آیا مدل تمامی مفهوماتی مورد نیازی را که در متدولوژیهای مشابه بیان شده پشتیبانی می­کند؟

قراردادها:آیا مدل قادر به بازنمایی و حمایت از قراردادها است؟

سطوح مختلف انتزاع: آیا متدولوژی و مدلهایش قادر به حمایت از سطوح مختلف انتزاع و جزییات آنها هستند؟

تعامل انسان ماشین : آیا مدل از واسط کاربر در ارتباط با ماشین پشتیبانی می­کند؟

پیمانه­ای: آیا مدل از نوشتن مولفه­ها به صورت پیمانه­ای پشتیبانی می­کند؟

گسترش: آیا زبان مدل­سازی قابل گسترش است؟

محیط : آیا زبان مدلسازی از درک عامل از محیط و مدلسازی محیط حمایت می­کند؟

محیط پویا : آیا زبان مدل­سازی از مدل کردن تغییرات محیطی حمایت می­کند؟

منابع: آیا زبان مدلسازی از مدل کردن منابع خارجی و داخلی عاملها به همراه محدودیت­هایشان حمایت می­کند؟

 

 

 

 

 

 

3-2-3.  پرسش­های مرتبط با فرآیند

چرخه حیات توسعه: چه مدل فرایند نرم­افزاری در متدولوژی استفاده می­شود؟

پوشش چرخه حیات : چه فازهایی از چرخه حیات و به چه میزان پوشش داده می­شود؟

روش توسعه: از کدام روش توسعه حمایت می­کند؟ بالا به پایین ، پایین به بالا ، هردو ، میانی

روش توسعه MAS : از روشهای بر پایه شیءگرایی استفاده می­کند یا مهندسی دانش یا هردو؟

حوزه برنامه کاربردی: آیا در حوزه خاصی از برنامه­ها قابل استفاده است؟

عنصر اصلی مدلها : پایه اصلی مدل آن چیست؟ عامل ،سازمان ، سرویس و ..

آیا برای موارد نام برده شده راهنمایی دارد؟

سازگاری درون و بیرون مدلها

سازگاری میان سطوح مختلف انتزاع

تخمین از زمان ، تعداد عامل مورد نیاز

حمایت از تصمیم سازی جهت انتقال میان فازها

تبدیل مدل به مدل دیگر

حمایت از اعتبار وصحت سنجی

ارتباط با مشتری: آیا از ازتباط طراح با مشتری حمایت می­کند؟

استفاده مجدد از مدل : آیا امکان استفاده از کتابخانه­ای از مدلهای با قابلیت استفاده مجدد را می­دهد؟

3-2-4.  پرسش­های مرتبط با عملگرایی

نداشتن ابهام : آیا نشانه­های زبان مدل­سازی به صورت شفاف مفاهیم را به نشانه­ها و قواعد نگاشت می­نمایند؟

دقت مدل : آیا نگاشت میان نشانه­ها و معنا به وضوح مشخص شده است؟

بیان­کننده : آیا مدل­ها قادر به گرفتن مفاهیم در بالاترین سطح جزییات هستند؟

چک کردن سازگاری: آیا بازنمایی مدل­ها قادر به چک کردن سازگاری میان عناصر هستند؟

سادگی نشانه­ها: آیا نشانه­ها از لحاظ معنایی و نحوی ساده هستند؟

بازتعریف : آیا متدولوژی از روشهای طراحی مبتنی بر بازتعریف حمایت می­کند؟

مستندات : آیا استفاده ، خصوصیات و ابزار متدولوژی به خوبی مستند شده است؟

مثالها : آیا مثالهای کافی از متدولوژی در دست است؟

3-2-5.  پرسش­های مرتبط با ابزار مدل­سازی

نوع بازنمایی : چه نوع بازنمایی استفاده می­شود ؟ گرافیکی ، رسمی ، ترکیبی

جمع­آوری خودکار بخشهایی از مدل: آیا ابزار قادر به جمع­آوری خودکار بخش­هایی از مدل است؟

جمع­آوری خودکار بخشهای  مدل از نیازمندی­ها : آیا ابزار قادر است از تعاریف نیازمندی­ها بخش­هایی از مدل را تولید نماید؟

ذخیره کردن زبان مدل­سازی: آیا ابزار قادر است با زبانهای استاندارد مدل­ها را ذخیره نماید؟

حمایت از بررسی مدل : آیا ابزار امکانات بررسی مدل را فراهم می­کند؟

حمایت از هستان­شناسی : آیا ابزار امکان استفاده از هستان­شناسی در مدل را فراهم می­کند؟

ابزار ارزیابی ایستا : آیا ابزار از صحت سنجی ایستا همچون تشخیص ناسازگاری در مدل­ها حمایت می­کند؟

ابزار ارزیابی پویا : آیا ابزاز از صحت سنجی رفتارهای سیستم حمایت می­کند؟

3-2-6.  پرسش­های مرتبط با ابزار پیاده­سازی

استقلال از پلت­فرم : آیا ابزار پیاده­سازی امکان نوشتن کد برای همه پلت­فرمها را مهیا می­کند؟

امکانات اشکال­زدایی : آیا ابزار امکان اشکال­زدایی را مهیا می­کند؟

جمع­آوری واسط گرافیکی : آیا ابزار امکان ایجاد واسط گرافیکی را مهیا می­کند؟

سیستم­های محدود :آیا ابزار امکان برنامه­نویسی برای سیستم­هایی با محدودیت مانند موبایل را فراهم می­کند؟

کنترل بلادرنگ : آیا ابزار امکان کنترل بلادرنگ را مهیا می­کند؟

مسایل امنیتی : آیا ابزار امکان پیاده­سازی مسایل امنیتی در کد را فراهم می­کند؟

مدل­های محیط فیزیکی : آیا ابزار امکان ایجاد شرایط تست برنامه در محیط فیزیکی را فراهم می­کند؟

عامل­های کمکی : آیا ابزار عامل­های کمکی را مستقل از برنامه پیشنهاد می­کند؟

مهندسی مجدد: آیا ابزار امکان استفاده از تکنیک­های مهندسی مجدد را فراهم می­کند؟

3-2-7.  پرسش­های مرتبط با قابلیت عرضه در بازار

ارزش نرم­افزار : برنامه با چه قیمتی قرار است عرضه شود؟

فروشندگان : چه سازمان فروشندگانی مسولییت عرضه آن را بر عهده دارد؟

به روز رسانی : نحوه به روز رسانی نرم­افزار به چه شکلی است ؟

خدمات فنی : آیا سازمان فروشندگان ، خدمات فنی به مشتریان ارایه می­کند؟

مثال­های دانشگاهی : چه تعداد مثال دانشگاهی و تحقیقاتی  از ابزار وجود دارد؟

مثال­های صنعتی : چه تعداد برنامه صنعتی از ابزار و مدل­ها وجود دارد؟

 

3-2-8.  پرسش­های مرتبط با جنبه­های حمایتی

سیستم­های باز : آیا متدولوژی از توسعه سیستم­های باز حمایت می­کند؟

امنیت : آیا متدولوژی به توسعه سیستم با در نظر گرفتن جنبه­های امنیتی کمک می­کند؟

مقیاس پذیری : متدولوژی از ارایه چه سیستم­های حمایت می­کند؟ کوچک ،متوسط ، بزرگ یا همه

سازمان پویا : آیا متدولوژی از توسعه سیستم بر اساس قابلیت تغییر سازمان حمایت می­کند؟

حمایت از هستان­شناسی : آیا پایه هستان­شناسی در متدولوژی وجود دارد؟

حمایت از سازمان MAS : آیا متدولوژی از ساختار سازمانی MAS حمایت می­کند؟

مدل سازی دانش : آیا متدولوژی از مدل سازی دانش حمایت می­کند؟

3-3. مقایسه متدولوژی­ها

 

در پاسخ به پرسشهای مطرح شده، جهت ارزیابی متدولوژی­های مختلف ، نمونه پاسخ­های داده شده برای متدولوژی ADELFE در ادامه می­آید . سپس تمامی متدولوژی­ها در چهارچوب گفته شده مقایسه می­شوند.

متدولوژی ADELFE در بیان خصوصیات همچون کنش­گرایی،خودمختاری انسان در مقابل نرم­افزار،منظق خودمختاری،پیداکردن نیازمندیها ، تعامل ماشین با انسان،جنبه­های مختلف نیازمندیهای غیرکارکردی،صحت سنجی مشخصات در چرخه حیات ، همزمانی وحمایت ابزار قوی عمل کرده است.

 سطوح مختلف انتزاع، شرکت کنندگان در حوزه ، گرفتن و فهم واژگان ،تحلیل حوزه،طراحی و ارزیابی پایگاه داده، طراحی واسط کاربر،جمع­آوری نمونه تست،منظق و طراحی معماری،گرفتن و منطق نیازهای غیرکارکردی،انعطاف­پذیری معماری،هزینه و اطمینان از طراحی معماری،تعقیب تغییرات از طراحی به کد،پیمانه­ای بودن، صحت سنجی رسمی، بيان دوباره مدلها ، دستكاري دياگرامها براي جامعيت بخشيدن، کار توزیعی تیمی و ترکیب با متدولوژیهای دیگر ضعیف عمل کرده است. و به جنبه­هایی همچون قابلیت تحرک، تعقیب تغییر نیازمندیها به طراحی و مدیریت پروژه  نپرداخته است.

در ADELFE از دياگرام مورد كاربرد و نوتيشنهاي UML استفاده ميشود و دياگرام توالي و يك تشريح متني به همراه پروتوتايپ وجود دارد.متدولوژي TROPOS پويايي و باز بودن برنامه كاربردي در حوزه نيازمنديها با مدلسازي محيط و اهداف نرم تشريح مينمايد.اما درباره خاصيت سازگاري عامل در قسمت طراحي حرفي نميزند. متدولوژي GAIA حوزه كاري را به صورت ايستا در نظر ميگيرد كه اين اتفاق در متدولوژيهاي ديگر مانند MASE, MESSAGE هم وجود دارد.متدولوژي ADELFE تمامي چرخه حيات سنتي و نشانه هاي استفاده مجدد را در نظر گرفته شده است.

در GAIA,MASE و AUML مدل خاصي براي بيان كردن محيط وجود ندارد. در TROPOS محيط در قالب بازيگران، اهدافشان و وابستگي هايشان مدل ميگردد. در MESSAGE مدل حوزه عناصر مشابهي را ميگيرد و تعاملات با محيط براي هر نقش تعريف شده و حق دسترسي ها، اعمال و وظایف مشخص ميگردند. در صنعت نكته مهم در سرمايه گذاري اين است كه آيا بايستي از فن آوري توسعه نرم افزار سازگار استفاده نمود يا خير كه ADELFE در اين امر كاربران را راهنمايي ميكند.  همچنيين اين متدولوژي به صورت تكراري و بازگشتي است. اجازه طراحي هر برنامه كاربردي عاملگرا را نميدهد و از متدولوژيهاي ديگر بايستي استفاده نمود.

درباره مدل فرایند می­توان گفت که متدولوژيهايOPM/MAS, Ingenias, TROPOS,PASSI  در دسته ميتوان تكاملي و افزايشي هستند.متدولوژیهای شبيه به آبشاري: Gaia,Roadmap,Prometheus,MASE,AOR كه سه تاي آخري ميتوانند در دسته تكاملي و افزايشي نيز جاي بگيرند و در مرز قرار دارند.

PASSI ،MASE  و Gaia از زبان xml  پشتیبانی می­کنند و ADELFE ،MESSAGE  وTROPOS  از زبان مدل­سازی UML  و AUML  استفاده می­کنند. و متدولوژی Prometheus  از UML بدون حمايت از زبان استاندارد آن پشتیبانی می­کند.

درمتدولوژی MASE فاز مورد كاربرد وجود دارد و پس از ساخت سناريو ، دياگرام توالي ايجاد ميشود. به این ترتیب ساختاری مانند شيءگر دارد.در Prometheus شبيه به MASE سناريو از موارد كاربرد استخراج شده، سپس در فاز طراحي معماري تراكنشهاي ميان عاملها در قالب دياگرام و پروتكل تعاملات بيان ميشود.

 در TROPOS مفاهيم در قالب دياگرامهاي UML بيان ميشوند كه در بخش جزئيات طراحي از دياگرام فعاليت براي بيان قابليتها و نقشه ها و تعاملات عاملها با دياگرام تعاملات بيان ميگردد.در PASSI در فاز تشريح حوزه مدل نيازمنديها با استفاده از دياگرام مورد كاربرد، در تشخيص عاملها با استريوتايپ­هاي UML و در مشخصات وظايف با دياگرام فعاليت کار می­کند .در MESSAGE همانند   MASE از دياگرام فعاليت و متامدلهاي گسترش يافته UML استفاده ميگردد. در   gaia از UML نيز استفاده مي­شود.

در TROPOS  براي بيان اهداف از دو نوع متفاوت استفاده ميشود اهداف سخت براي بيان نيازهاي كاركردي و اهداف نرم براي نيازهاي غيركاركردي و دياگرام اهداف براي انها ساخته ميشود.در اينجا ميشود نقشه و هدف را ترسيم نمود و به تحليل ان پرداخت كه اهداف به زير اهداف شكسته ميشوند.براي متدولوژي MASE نيز امر پيدا كردن اهداف حياتي است و هميشه ره عنوان يك هدف سيستم شناخته ميشودمتدولوژي كه كمتر از MASE هدف گرا است Prometheus است كه در مشخصات سيستم اهداف پيدا ميشوند كه اهداف و زير اهداف در دياگرام اهداف بيان ميشوند.در دو متدولوژي بالا عاملها رابطه وابستگي نسبت به اهداف دارند در حالي كه در TROPOS بيئتر هدفگرايي وجود دارد.

در gaia اهداف سازمان  در فاز تحليل براي كليت سيستم و براي زيرسيستمها زيراهداف تشخيص داده ميشوند .در MESSAGE اهداف به وسيله حالت به عاملها پيوند ميخورند، در اينجا ديد كاملا متفاوت از TROPOS و MASE است و يك ديد وظيفه/هدف بيانگر كاري است كه بر اساس عامل/نقش بايستي انجام پذيرد.اهداف در ADELFE  و PASSI زياد مورد توجه قرار نگرفته اند.

در مقايسه متدولوژيها از ٣ ديدگاه هدف ، دياگرام و زبان استاندارد می­توان در نهایت گفت که متدولوژی TROPOS بیشتر هدف­گرا است. متدولوژی ADELFE به دیاگرام­ها اهمیت بیشتری داده است ، و متدولوژی PASSI درباره  زبان استاندارد کارهای بیشتری ارایه نموده است.

در جدول هایی [xxiv]که در ادامه می­آیند، می­توان شرایط مختلف مقایسه را برای 9 متدولوژی­ متفاوت دید.برای نشان دادن میزان حمایت از یک خصوصیت از اعداد مابین 0 تا 3 استفاده شده است، که عدد صفر نمایانگر ضعف و کاستی در آن خصوصیت و عدد 3 نشان دهنده حمایت بالا از آن مفهوم یا خصوصیت است. نتایج ارایه شده از مقایسه گزارش­های متعدد ، متن نویسندگان وکار با بعضی از متدولوژی­ها به دست آمده است.

3-3-1.          مقایسه از لحاظ مدل فرآیند و پوشش چرخه حیات

            چرخه حیات

متدولوژی  

مدل فرآیند

گرفتن نیازمندی

تحلیل نیازمندی

طراحی معماری

طراحی جزییات

پیاده­سازی

صحت سنجی/ تست

توزیع[62]

MASE

آبشاری

1

3

3

3

2

2

2

GAIA

آبشاری میان فازها / تکراری درون فازها

0

2

3

1

0

0

1

TROPOS

تکاملی/افزایشی

3

2

2

2

2

0

0

ADELFE

UP

3

3

2

2

2

1

0

INGENIAS

UP

0

2

2

2

2

0

0

PASSI

تکراری

0

2

2

3

3

2

2

PROMETHEUS

آبشاری

1

3

3

3

1

3

0

ROADMAP

آبشاری میان فازها / تکراری درون فازها

1

3

3

1

0

0

0

ASPECS

تکراری

2

2

3

3

3

3

2

در مقایسه شرایط پوشش چرخه حیات می­توان گفت که متدولوژی­های ADELFE و TROPOS دربخش گرفتن نیازمندی­ها نسبت به بقیه متدولوژی­ها کاملتر عمل نموده­اند.در تحلیل نیازمندی­ها و طراحی معماری تقریبا تمام متدولوژی­ها روش­ها و راهنمایی­های مناسبی را عرضه کرده­اند. در طراحی جزییات مربوط به ساختار عامل دو متدولوژی GAIA وROADMAP نسبت به بقیه ضعیف­تر عمل کرده­اند. در فازهای بعدی نسبت پوشش برای بعضی از متدولوژی­های کاهش می­یابد یا به اتمام می­رسد. پیاده­سازی را دو متدولوژی ASPECS و PASSI که در این زمینه از راه­کارهای تقریبا یکسانی استفاده می­نمایند به خوبی پشتیبانی می­کنند. در فاز صحت سنجی دو متدولوژی APSECS و PROMETHEUS به طور کامل از عملیات صحت سنجی در طراحی و نیازمندی­ها حمایت می­کنند اما متدولوژی  MASE بیشتر از صحت سنجی نیازمندی­ها حمایت می­کند. ارایه راه­کار برای حمایت از توزیع در سه متدولوژی نشان داده در جدول به صورت متوسط پشتیبانی می­شود.

3-3-2.          مقایسه از لحاظ پوشش مفهوم

 

            مفهوم

متدولوژی

خودمختاری

جنبه­های ذهنی

همزمانی

سازگاری

واکنش مجدد

قابلیت ارتباط

معماری

شرایط زودگذر

زبان ارتباط

وابستگی به پلت­فرم ندارد

کنکاش

کنش­گرایی

MASE

3

2

۳

1

۲

2

۳

1

2

3

2

3

GAIA

3

2

۱

۲

۲

0

2

0

0

2

1

2

TROPOS

3

3

۲

۲

۲

۲

۳

2

3

3

3

3

ADELFE

3

3

3

۳

3

2

1

3

3

1

3

3

INGENIAS

2

1

۱

1

۲

2

2

1

3

1

1

2

PASSI

3

2

1

1

2

2

2

0

2

2

1

2

PROMETHEUS

3

3

۱

2

۲

1

۳

1

2

2

2

3

ROADMAP

3

3

1

1

2

0

2

0

0

2

1

2

ASPECS

۳

۲

۲

۱

3

1

3

2

3

1

3

3

در مقایسه پوشش مفاهیم مرتبط با پیاده­سازی سیستم­های چند عامله می­توان گفت که کم و بیش تمامی متدولوژی­ها در این زمینه به تعریف راه­کار پرداخته­اند. در جنبه­های ذهنی متدولوژی INGENIAS نسبت به بقیه ضعیف­تر عمل نموده است. در همزمانی عامل­ها دو متدولوژی ADELFE و MASE نسبت به بقیه کامل­تر هستند. در سازگاری متدولوژی ADELFE به ارایه راه­کارها و تعاریف دقیقتری پرداخته است. در قابلیت ارتباط دو متدولوژی GAIA وROADMAP به ارایه راه­کار نپرداخته­اند. در برخورد با شرایط زودگذر و رهایی ازحالت­های شکست متدولوژی ADELFE بسیار دقیق عمل می­نماید. در وابستگی به پلت فرم می­توان گفت متودولوژی ADELFE و ASPECS برای ارایه به پلت فرم­ها و سیستم­های خاص مطرح شده­اند و در نظر گرفتن کاربردهای همه منظوره برای آنها سخت است.در جدول فوق می­توان بقیه موارد را با اندازه­های تعیین شده پیگیری نمود.

3-3-3.          مقایسه زبان مدلسازی

    متدولوژی

 

خصوصیات

MASE

GAIA

TROPOS

ADELFE

INGENIAS

PASSI

PROMETHEUS

ROADMAP

ASPECS

بازنمایی

هردو

غیر رسمی

هردو

غیر رسمی

غیر رسمی

غیر رسمی

غیر رسمی

غیر رسمی

هردو

متامدل

خیر

بله

بله

بله

خیر

بله

بله

بله

بله

وابستگی مدل­ها

بله

بله

خیر

خیر

خیر

خیر

بله

بله

خیر

وضوح

بله

خیر

بله

بله

بله

بله

بله

بله

بله

همزمانی

خیر

بله

بله

بله

بله

بله

بله

بله

بله

کامل بودن نشانه­ها

خیر

خیر

خیر

بله

بله

بله

بله

خیر

بله

کامل بودن

خیر

خیر

بله

بله

خیر

بله

بله

خیر

بله

سطوح مختلف انتزاع

1

1

1

2

1

1

1

n

n

تعامل انسان با ماشین

خیر

خیر

خیر

خیر

بله

بله

بله

بله

بله

گسترش

بله

بله

بله

بله

بله

بله

بله

خیر

بله

محیط

خیر

بله

بله

بله

بله

خیر

بله

بله

بله

محیط پویا

خیر

بله

خیر

بله

خیر

خیر

خیر

بله

بله

پیمانه­ای

بله

بله

بله

بله

بله

بله

بله

بله

بله

در بررسی زبان­های مدل­سازی ارایه گردیده برای متدولوژی­های فوق می­توان گفت خصوصیات پیمانه­ای و انواع بازنمایی در همه رعایت می­گردد.در باره مدل­سازی محیط بایستی گفت که دو متدولوژیMASE و PASSI در این باره راهنمایی ارایه نکرده­اند.همچنین مدل­سازی محیطی از دیدگاه­های متفاوتی مطرح می­شود، به طور مثال در INGENIAS محیط از دید حوزه تحلیل می­شود و در PROMETHEUS از دید سیستم. متدولوژی MASE در زبان مدل­سازی نسبت به بقیه ضعیف عمل کرده است، و دو متدولوژی PROMETHEUS و ASPECS بهترین پوشش را دارند . در این میان متدولوژی ASPECS با عدم وابستگی مدل­ها به یکدیگر و ارایه چندین سطح انتزاع به صورت سلسله مراتب سازمانی و شکستن عامل­ها بسیار قوی عمل کرده است.

3-3-4.          مقایسه عمل­گرایی

   خصوصیت

 

متدولوژی

نداشتن ابهام

دقت مدل

بیان­کننده

سازگاری

سادگی نشانه­ها

بازتعریف

مستندات

مثالها

MASE

2

2

2

3

3

1

3

3

GAIA

2

2

1

1

1

0

3

0

TROPOS

2

2

2

3

3

3

3

2

ADELFE

1

3

3

3

2

3

3

1

INGENIAS

2

1

2

2

3

3

2

1

PASSI

3

2

3

2

3

2

2

0

PROMETHEUS

2

3

3

2

0

2

2

3

ROADMAP

3

2

2

1

2

0

1

0

ASPECS

3

3

3

0

2

1

1

0

همانگونه که در جدول می­بینید، جنبه­های عملیاتی متدولوژی­هایی که سابقه بیشتری دارند وضعیت بهتری دارند. از لحاظ پوشش این جنبه­ها متدولوژی GAIA و ROADMAP خیلی ضعیف عمل کرده­اند.  در نهایت می­توان گفت متدولوژی­های MASE ، TROPOS و ADELFE  در ارایه عملگرایی موارد بیشتری را پوشش داده­اند.

3-3-5.          مقایسه ابزار مدل­سازی

   خصوصیات

 

متدولوژی

نام ابزار

نوع بازنمایی

جمع­آوری مدل

حمایت از هستان­شناسی

ذخیره زبان مدل­سازی

ارزیابی

جمع­آوری کد

MASE

AgentTool

گرافیکی

خیر

خیر

بله

بله

بله

GAIA

GAIA4E

رسمی

خیر

خیر

خیر

بله

بله

TROPOS

StarUML plugin

T-Tool

گرافیکی

بله

بله

بله

بله

خیر

ADELFE

OpenTool

گرافیکی

بله

بله

بله

بله

بله

INGENIAS

IDK

گرافیکی

بله

خیر

بله

بله

بله

PASSI

PTK & Agent factory

گرافیکی

بله

بله

بله

بله

بله

PROMETHEUS

PDT

گرافیکی

خیر

خیر

بله

بله

بله

ROADMAP

REBEL

گرافیکی

خیر

خیر

بله

خیر

خیر

ASPECS

در زمینه ابزارهای مدل­سازی هرکدام از متدولوژی­ها به معرفی یک ابزار با خصوصیات مختلف پرداخته­اند. ابزارمتدولوژی ASPECS بنابرگفته ارایه دهندگان در حال طراحی است. در میان ابزارهای فوق ابزار جدید GAIA4E خصوصیت متمایز نسبت به بقیه دارد که آن نوع بازنمایی آن با استفاده از زبان رسمی است، اما در خیلی از موارد هنوز راه­کاری معرفی نکرده است.

3-3-6.          مقایسه ابزار پیاده­سازی

   خصوصیت

 

متدولوژی

نام ابزار

استقلال از پلت­فرم

عامل­های کمکی

مدل­های محیط فیزیکی

امکانات اشکال­زدایی

مهندسی مجدد

سیستم­های محدود

کنترل بلادرنگ

مسایل امنیتی

MASE

JADE

بله

بله

بله

بله

بله

بله

بله

بله

GAIA

JADE

بله

بله

بله

بله

بله

بله

بله

بله

TROPOS

JACK

بله

بله

بله

بله

بله

بله

بله

بله

ADELFE

INGENIAS

JADE

بله

بله

بله

بله

بله

بله

بله

بله

PASSI

JADE

بله

بله

بله

بله

بله

بله

بله

بله

PROMETHEUS

JACK

بله

بله

بله

بله

بله

بله

بله

بله

ROADMAP

JADE

بله

بله

بله

بله

بله

بله

بله

بله

ASPECS

JANUS

بله

بله

بله

بله

خیر

بله

بله

بله

در مقایسه ابزارهای مورد استفاده بایستی گفت که دو ابزار JACK و JADE بسیار مورد استفاده قرار می­گیرند. زبان برنامه نويسي هردو بر پايه جاوا است و عامل­های استفاده شده هوشمند هستند. در هردو ابزارهای کمکی بر روی پلت­فرمهای متنوع مورد استفاده قرار می­گیرند و به بلوغ رسیده­اند. ابزار JANUS که مختص متدولوژی ASPECS است به تازگی عرضه شده است، اما کارکرد آن نیز شبیه به دو ابزار فوق است.

3-3-7.          مقایسه قابلیت عرضه در بازار

    قابلیت

 

خصوصیت

ارزش نرم­افزار

فروشندگان

به روز رسانی

خدمات فنی

مثال­های دانشگاهی

مثال­های صنعتی

MASE

مدل cocomo II

بسته به قرارداد

تولید کننده

20+

خیر

GAIA

مدل cocomo II

بسته به قرارداد

تولید کننده

0

TROPOS

مدل cocomo II

بسته به قرارداد

تولید کننده

5+

بله

ADELFE

مدل cocomo II

بسته به قرارداد

تولید کننده

5+

INGENIAS

مدل cocomo II

بسته به قرارداد

تولید کننده

5+

خیر

PASSI

مدل cocomo II

بسته به قرارداد

تولید کننده

PROMETHEUS

مدل cocomo II

بسته به قرارداد

تولید کننده

20+

خیر

ROADMAP

مدل cocomo II

بسته به قرارداد

تولید کننده

1-5

ASPECS

مدل cocomo II

بسته به قرارداد

تولید کننده

1-5

در تخمین هزینه سیستم­های مبتنی بر عامل از مدل Cocomo II استفاده می­شود. در این روش عامل­ها و تعداد تقسیم آن­ها به وظایف مشخص شده ، پیچیدگی را مشخص می­نماید.از آنجا که  اطلاعات زیادی از سیستم­های مبتنی برعامل پیاده­سازی شده توسط شرکت­های مختلف در دست نیست ، ارایه مشخصات دقیق در این زمینه مشکل است. تنها متدولوژی که به تعداد محدود مثال­های صنعتی از آن در دست است متدولوژی TROPOS است.

3-3-8.          مقایسه جنبه­های حمایتی

 

      جنبه حمایتی

 

متدولوژی

سیستم باز

امنیت

مقیاس پذیری

هستان­شناسی

سازمان

پویایی سازمان

مدل دانش

MASE

خیر

بله

بله

بله

بله

خیر

بله

GAIA

بله

خیر

بله

خیر

خیر

خیر

بله

TROPOS

خیر

بله

بله

خیر

خیر

خیر

خیر

ADELFE

بله

بله

بله

خیر

خیر

خیر

خیر

INGENIAS

خیر

خیر

بله

خیر

خیر

خیر

بله

PASSI

خیر

خیر

بله

بله

بله

خیر

بله

PROMETHEUS

خیر

خیر

بله

خیر

خیر

خیر

خیر

ROADMAP

بله

خیر

بله

خیر

خیر

خیر

بله

ASPECS

بله

بله

بله

بله

بله

بله

بله

در مقایسه جنبه­های حمایتی می­توان گفت که متدولوژی ASPECS بنا برخصوصیاتی که در جریان کاری آن ارایه گردیده است، از تمامی موارد ذکر گردیده حمایت می­کند. و ضعیف­ترین حمایت­ها از این خصوصیات از جانب متدولوژی PROMETHEUS است. متدولوژی­هایی که از پایه برای آنها استفاده از هستان­شناسی تعریف گردیده ، سه متدولوژی MASE ، PASSI و ASPECS هستند. تنها متدولوژی که از پویایی سازمان و تغییر ان در حالات مختلف حمایت می­نماید متدولوژی ASPECS است.

3-4. نتیجه گیری

روش­های مبتنی بر عامل مفهومات مهندسی نرم­افزار را به گونه­ای بازنمایی می­کنند ، که توسعه دهندگان قادر به ارایه راه­حل برای سیستم­های صنعتی پیچیده باشند. در این مقوله نقش متدولوژی­های مبتنی بر عامل مهم است ، هر چند که هیچ کدام از آنها به اندازه­ای کامل و دقیق نیستند که تمامی جنبه­ها ونیازها را پوشش دهند.

به همین جهات به بررسی 9 متدولوژی مختلف و مقایسه آنها با یکدیگر پرداختیم تا اینکه نقاط قوت و ضعف، حوزه­های کاربرد، شباهت­ها و تفاوت­های آنها مشخص گردد ، تا بتوان متدولوژی مناسب را برای حوزه کاربرد مد نظر انتخاب نمود. به همین جهت به مطالعه متدولوژی­های مختلف از دید نویسندگان و بررسی کنندگان آنها پرداخته و خصوصیات متدولوژی­ها را در چهارچوبی مشخص که قابلیت ارزیابی عددی داشته باشد ارایه نمودیم. البته در بعضی موارد منابع موجود امکام مقایسه عددی را به ما ندادند. در این سمینار از مقایسه بر اساس آزمایشات قبلی استفاده شده است كه از متدهای ارزیابی مبتنی بر خصوصیات و ارزیابی های كمی درون آن به صورت مشترك استفاده گردیده است  .در نهایت میتوان ازاهداف ارزیابی متدولوژی های AOSE موارد زیر را بیان نمود:

  • درك بهتر طبیعت متدولوژی­های AOSE شامل فلسفه آن­ها، اهداف، خصوصیات و…
  • مشخص نمودن نقاط قوت و ضعفشان و همچنین تفاوت های آن ها برای طبقه بندی و بهبود خصوصیات توسعه سیستم های مبتنی بر عامل

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

 

مراجع :

Process model for agent  baeed development. Luca cernuzzi part2

.

Service oriented agent methodologies – giacomo cabri

Evalution of Agent oriented methodologies

Arnon sturm

Process model for agent baeed development. Luca cernuzzi

Software deelopment with obects,عاملs,and services michael n.huhns

 Comparing agent  oriented methodologies. Khan hoa dam

ASPECS:an Agent oriented software for engineering complex systems

Massimo cossetino et all 2009

The INGENIAS methodology for advanced surveillance systems modelling -jose m.cascuena et al

Modeling of social systems with ingenias -juan pavon et al

Agent oriented software engineering with INGENIAS -juan pavon

ADELFE: a methodology for adaptive multi agents systems engineering -carole bernon

Evaluting ADELFE methodology in the requirement identification-  v.m.b. werneck et al

Evaluting and comparing agent-oriented software engineering methodologies -khanh hoa dam

Aagent oriented software engineering:state of the art -michael wooldridge


[1] Agent

[2] Attribute

[3] Distributed Artificial Intelligence (DAI)

[4] Goal

[5]  Software agent

[6] Multi Agent System (MAS)

[7]  Persistence

[8] Tasks

[9]  Autonomy

[10]  prioritization

[11]  Reactivity

[12]  Proactive

[13] Intelligent Agent

[14] collaborative filtering

[15]  Embodiment

[16]  Simple reflex agents

[17]  Model-based reflex agents

[18]  Goal-based agents

[19]  Utility-based agents

[20]  Learning agents

[21]  Abstract Intelligent Agents

[22]  Rational agents

[23] cognitive Architecture

[24] Belief ,Desire ,Intention (BDI)

[25] Negotioation

[26] Ontology

[27] Agent Oriented Programming (AOP)

[28] Uint Invocation

[29] Service Oriented Architecture

[30] Software Engineering (SE)

[31] Object Oriented Software Engineering (OOSE)

[32] Use Case

[33] Unified Modelling Language

[34] Rational Unified Process

[35] Agent Oriented Software Engineering (AOSE)

[36] Development Process

[37] Software Development Process

[38] Life Cycle

[39] Identification

[40] Representation

[41] Software Process Model

[42] Agent Modelling Language

[43] Notation

[44] Method

[45] Methodology

[46]  CommonKADS، MASCommonKADS، CoMoMAS

[47] Formal

[48] Role

[49] Conceptual Modeling of Multi-Agent Systems

[50] Framework for DEsign and Specification of Interacting REasoning

[51] Adaptive  Multi Agent System (AMAS)

[52] None Cooperative Situation (NCS)

[53] Unified Software Development Process

[54] Ingenias Development Kit

[55] GOPRR

[56] METAEDIT+

[57] Process for Agent Societies Specification and Implementation

[58]  سيستم باز سيستمي است كه تركيبي از اجرا و همكاري، قابليت حمل، تعامل پيوسته با محيط را دارد و اجازه مشاركت ذينفعان مختلف در ان داده ميشود.

[59] an Agent-oriented Software Process for Engineering Complex Systems

 

[60] Holon

[61] Concepts: Capacity, Role, Interaction and Organization

[62] Deployment


[i]  [Russel ] [ Maes, editor. Designing Autonomous Agents. The MIT Press,1990.]

[ii]  M.Wooldridge & N.R.Jennings, “Intelligent Agents :teory And Practice “ (1995)

[iii] M. Wooldridge and N. R. Jennings. Intelligent agents: Theory and practice. The Knowl-

edge Engineering Review, 10(2):115{152, 1995.

[iv] H. S. Nwana. Software agents: An overview. Knowledge Engineering Review, 11(2):205{

244, 1995.

[v]  Jennings  & wooldridge

[vi]  Russel & Norvig 2003 chpt. 2

[vii]  Franklin & Grasser 1996 , Kasabov 1998

[viii]  Kasabov 1998

[ix] Müller, J. P. (1996). The Design of Intelligent Agents, Springer Berlin / Heidelberg.

[x] Russell, S. J. & Norvig, P. (1995). Artificial Intelligence: A Modern Approach, Prentice-Hall International.

[xi] Weyns, D., Omicini, A. & Odell, J. (2006). Environment as a first class abstraction in multiagent systems, Autonomous Agents and Multi-Agent Systems 14(1): 5–30.

[xii] Agent-Environment Interaction in MAS – Introduction and Survey , Joonas Kesäniemi and Vagan Terziyan

[xiii]  [perry & wolf 92],[fielding &taylor 00],[Garlan 96],[Bass 03],[IEEE 1471-00],[Boehm 95],[Hayes 94],[McGocern 03], [Bhagtani 03]

[xiv]  Bass, Clements, and Kazman 1998

[xv]  Leffingwell and Widrig 2000

[xvi] Object and Agents :How do they differ? James odell 1999

[xvii] Agent oriented software engoneering and the sacproject

Michael winikoff 2002 rmit university

[xviii] 25 Apr 1998 – Wooldridge, M. and Ciancarini, P., “Agent-Oriented Software Engineering: The State of the. Art,” Handbook of Software Engineering and Knowledge Engineering

 

 

A survay of Agent oriented methodologies

Carlos a.iglesias

 

[xix] V. Hilaire, A. Koukam, P. Gruer, and J.-P. M¨uller. Formal specification and

prototyping of multi-agent systems. In A. Omicini, R. Tolksdorf, and F. Zambonelli,

editors, ESAW, number 1972 in LNAI. Springer Verlag, 2000.

[xx] H. V. Brussel, J. Wyns, P. Valckenaers, L. Bongaerts, and P. Peeters. Reference

architecture for holonic manufacturing systems: PROSA. Computers in

Industry, 37:255–274, 1998.

[xxi] W. Shen, F. Maturana, and D. H. Norrie. MetaMorph II: an agent-based architecture

for distributed intelligent design and manufacturing. Journal of

Intelligent Manufacturing, 11(3):237–251, June 2000.

[xxii] Barbara Kitchenham. DESMET: a method for evaluating software engineering methods

and tools. Technical Report TR96-09, University of Keele, U.K., August 1996.

[xxiii] Towards an Evaluation Framework for MAS Software Engineering, Emilia Garcia, Adriana Giret, and Vicente Botti

[xxiv] PROCESS MODELS FOR

AGENT-BASED DEVELOPMENT

Luca Cernuzzi1,2, Massimo Cossentino3, Franco Zambonelli1

 

۱۳۹۲-۱۰-۱۱ ۱۸:۲۱:۰۳ +۰۳:۳۰آذر ۷ام, ۱۳۹۲|متلب دسته بندی ها|۱ ديدگاه

ثبت ديدگاه

پرداخت

1-پرداخت آنلاین
برای پرداخت آنلاین از لینک زیر استفاده کنید
پرداخت آنلاین
2- پرداخت آفلاین
برای پرداخت آفلاین مبلغ مورد نظر را به یکی از شماره کارت
6037997245888723بانک ملی