خانه / مقالات / برنامه نویسی / برنامه نویسی وب / متدولوژی عامل‌گرا : پرومته

متدولوژی عامل‌گرا : پرومته

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

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

۱-۱- برنامه نویسی شیءگرا
زبان‌های برنامه‌نویسی از دهه ۵۰ میلادی با کامپیوترهای اولیه پا به عرصه وجود نهادند و در دهه ۷۰ میلادی با معرفی زبان Simula ،الگوهای برنامه‌نویسی شیءگرا موجب پیشرفت در مهندسی نرم افزار گردیدند .برنامه‌نویسی شیءگرا بدین گونه است که نرم‌افزار باید با توجه به مدل‌های موضوع‌های حقیقی و فرضی که ارائه می‌کنند نوشته شود. برای یک شیء تعاریف متفاوتی ذکر شده است که دو تعریف در زیر مشاهده می‌‌شود.
• تعریف شیء توسط بوش : يك انتزاع از چيزي در حوزه مساله كه قابليت‌هايي از سيستم را كه اطلاعات آن را نگه مي‌دارد نشان مي‌دهد كه داراي رفتار ، هويت و حالت است. [۱] • تعریف شیء توسط کود و یواردان : شيء يك چيز مشهود وملموس در شكلي پايدار است ، كه مي‌تواند به شكلي عقلايي بيان شود، چيزي كه فكر مي‌شود يا عملي كه هدايت شود نيز مي‌تواند باشد. به شكل يك واحد از يك ساختار و رفتار كه شامل خصوصياتي است مي‌تواند بيان گردد. [۲] ساختار اصلي دو تعریف فوق ، شیء است . هر شیء متشکل از يک سري صفات است که به آنها خصلت گفته مي‌شود که توصيف کننده ساختار شیء مي‌باشند .همچنين شیء داراي يکسري تابع است که به آنها متد گفته ميشود که در واقع توصيف کننده رفتار آن شيء مي‌باشند. در اين ساختار ديگر مشکل پيچيدگي گذرها وجود ندارد . همچنين به راحتي مي‌توان اشیاء را استفاده مجدد نمود و با انتقال يک شیء به يک سيستم ديگر تمامي ساختار و رفتارهاي آن نيز انتقال يابد.
با توجه به توضیحات ارائه شده یک شیء می‌تواند خصوصیات زیر را داشته باشد:
• یک انتزاع از سیستم
• قابلیت نگه داری اطلاعات دارد
• یک عمل هدایت شده
• یک واحد از یک ساختار
• دارای خصوصیات است
• رفتار دارد
• هویت اختصاصی دارد
• می‌تواند از اشیاء دیگر ساخته شده باشد

۱-۲٫ برنامه نویسی عامل‌گرا
هوش مصنوعی در بسیاری از دانش‌های امروزی کاربردهای وسیعی دارد.هوش مصنوعی به هوش یک ماشین و یا به دانشی کامپیوتر که سعی در ایجاد آن دارد گفته می‌شود. در هوش مصنوعی توزیع شده که در سال ۱۹۸۰ توسط دانشگاه MIT معرفی شد ، به مطالعه و ساخت و به کارگیری سیستم‌هایی که در آنها چندین عامل در حال تعامل با یکدیگر است و مجموعه‌ای از اهداف را دنبال می‌کنند می‌پردازند. [۳]

۱-۲-۱٫ عامل
در سال ۱۹۹۱ میلادی یاو شوهام به معرفی مفهومی جدید در برنامه‌نویسی به عنوان عامل پرداخت. البته این عامل به در ابتدا به عنوان موجودیتی ساده در نظر گرفته شد، در سال ۱۹۹۳ تعریف آن دچار تغییراتی شد و خصوصیات بیشتری به آن افزوده گردید. مطابق تعریف شوهام ، عامل یک سیستم کامپیوتری کپسوله شده است که در محیطی قرار دارد و قادر است کارهای خودمختار برای رسیدن به اهداف خود انجام دهد.عامل‌ها قادرند با یکدیگر تعامل داشته و نسبت به کارهای دیگر عامل‌ها واکنش نشان دهند[۱۴].
استوارت راسل عامل را بدین صورت تعریف می نماید که «عامل یک واحد محاسباتی مانند برنامه نرم‌افزاری یا یک روبات است که قابل مشاهده است و با محیط خود در ارتباط بوده و نسبت به تجارب به دست آمده رفتار خود را تنظیم نموده و نسبت به محیط واکنش نشان داده وخودمختار است.عامل‌ها اهدافی دارند که اعمال‌شان در جهت رسیدن به آنها است.» [۴] با توجه به دو تعریف فوق می‌توان گفت عامل چيزي است كه محيط خود را باحس‌گرها درك مي‌كند و در محيط با کنش‌گرها تاثير دارد. اين تعريف بسيار وابسته به محيط است. همچنین عامل می‌تواند سيستمي محاسباتي باشد،كه در محيطي پويا و پيچيده قرار دارد. عامل به‌صورت خودگردان محيط را حس نموده و با توجه به اهداف خود ، کنش يا کنش‌هايي را صورت می دهد . [۴] در تصویر ۱ یک دید انتزاعی از عامل را مشاهده می نمائید.
در علم کامپیوتر ، عامل نرم‌افزاری یک قطعه از نرم‌افزار است که مانند یک آژانس در ارتباط با یک برنامه ، کاربر یا عامل دیگر عمل مینماید. همچنین یک توافق در مورد این‌که چه کاری باید انجام شود بین آن دو صورت می پذیرد. ایده این است که عامل‌ها به صورت محدود برای کاری بیدار نمی‌شوند بلکه خودکار فعال می شوند. واژه عامل یک تجرید نرم افزاری ، یک ایده یا یک قاعده مانند توابع ، متدها و اشیا در OOP را بیان میکند. مفهوم یک عامل ، راهی قدرتمند و راحت را برای تشریح نهادهای نرم‌افزارهای پیچیده فراهم میکند که قادر است درجه‌ای از خودمختاری را به منظور کامل نمودن کارها در تعامل با کاربر مهیا کند. [۵] عامل‌های نرم‌افزاری برای اولین بار با هدف ایجاد شیوه‌ای راحت و مطمئن برای انجام خودکار کارهایی به نیابت از طرف کاربر بوجود آمد. عامل‌ها از رده‌هاي مختلف و قابليت‌هاي متفاوتي مي‌توانند باشند از جمله يك برنامه روميزي ساده و عامل‌هايي كه براي جستجوي خودكار اطلاعات و بازيابي آنها به كار مي‌روند.
مفاهيم و مفروضات عامل‌ها در مهندسي نرم‌افزار شامل مفهوم‌هاي اشاره شده در حوزه مسئله مانند عامل‌های هوشمند ، عامل‌های توزیع شده ، سیستم‌های چندعاملی ، عامل‌های همراه ، افزايش محلي‌سازي و بسته‌بندي مانند به كار بردن كنترل بر روي وضعيت و رفتار خود و در نهايت حمايت از طراحي بر پايه قابليت استفاده مجدد با ارائه عامل‌ها و ارتباطات انعطاف‌پذير است. چندين عامل درکنار یکدیگر که به صورت طبيعي غيرمتمركز، دارای چندين مكان كنترلي، چندين ديدگاه و علايق متفاوتي هستند ، براي رسيدن به اهداف خود بايد با هم تعامل داشته باشند. این عامل‌ها در کنار یکدیگر تشکیل یک سیستم چندعامله را میدهند.مفهومي كردن سطح دانش بدین معنا كه چه اهدافي، در چه زماني، توسط چه كسي و به چه علت انجام می پذیرد ، در سیستم‌های چند عامله مطرح می‌شود.
عامل‌ها به دو دسته پیشكارهای قوی و ضعیف دسته بندی می‌شوند، پیشكار ضعیف خصوصیاتی همچون واقع در محیط،خودمختاری ، واکنشی ، کنش‌گرایی و قابلیت اجتماعی دارد. [۵] پیشكار قوی تمامی خصوصیات یك پیشكار ضعیف را دارد اما نشانه های آن گسترده‌ترند. مانند دیدن یك عامل به شكلی كه وضعیت ذهنی و نشانه‌های اراده مانند اعتقاد ، میل ، هدف ، خواستن و تمكین را داشته باشد . [۶] خصوصیات دیگر مانند قابلیت تحرك ، قابلیت اعتماد و فرمان‌پذیری نیز بعضی مواقع جزء خاصیت های یك پیشكار قوی هستند.وولدریج و جنینگ در مقاله خود[۵] مفاهیم ذیل را برای عامل ارائه نموده‌اند:
• واقع در محیط: عامل‌ها در محیط‌ها قرار دارند و برای درك محیط از حسگرهایشان استفاده می‌كنند. مانند یك ربات كه از حسگرهای متفاوتی مانند دوربین برای دیدن اطراف استفاده می‌نماید.
• مانایی : که به صورت پیوسته عامل اجرا گردد و تصمیم‌گیری نماید که بعضی از کارها را انجام دهد. به عبارت دیگرانجام مستمر وظایف محول شده و گرفتن تصمیمات مربوط به این که چه زمانی باید عکس العمل نشان دهد.
• خودمختاری : عامل بدون دخالت مستقيم انسان‌ها يا ديگران قابلیت انتخاب کارها ، اولویت‌دهی ، رفتار هدف‌دهی
شده ، تخصیص میزان اهمیت ، و تصمیم سازی را دارد، انجام وظيفه مي نمايد و بركنش‌ها و وضعيت داخلي خود نوعي كنترل دارد.
• قابلیت اجتماعی : عامل ها قادرند دیگر مولفه ها را درگیر نموده و بعضی از انواع ارتباطات را به کار گیرند یا اینکه در انجام کاری مشارکت کنند. عامل با ساير عامل ها و يا انسان ها از طريق نوعي زبان ارتباط برقرار مي كند.
• فعالیت مجدد : عامل‌ها ممکن است نسبت به متن کاری خویش واکنش نشان داده و کار جدیدی انجام دهند. عامل محيط اطراف خود را درك كرده كه اين محيط ممكن است: دنياي فيزيكي، كاربر با واسط كاربر ، مجموعه اي از ساير عوامل ، اينترنت يا احتمالا مجموعه اي از همه اينها و درزمان مناسب به تغييرات رخ داده در آن پاسخ مي دهد. در کل داشتن توانایی درک نسبی مفاهیمی که برای آنها کار میکنند و واکنش میدهند.
• کنش‌گرا : قابلیت پیش‌بینی اهداف آینده را داشته باشد. همچنین می‌توان گفت که باید قابلیت واکنش به تغییرات محیط را داشته باشند. عامل‌ها در صورتی‌كه اهداف‌ را در طول زمان تعقیب كنند کنش گرا هستند،هدف نهایی یك ربات فوتبالیست برنده شدن تیم است.پس به همین علت تصمیمات مانند ضربه زدن به توپ و پاس دادن و گل زدن را در یك هدف كلی انجام می دهد.
• از جمله خصوصیات دیگر عامل‌ها میتوان به انعطاف‌پذیری، عقلانیت، یادگیری، هدف‌گرایی و قابلیت استدلال اشاره نمود.
خصوصیات ذكر شده به عامل‌ها آن ها را به نهاد‌هایی محكم با قابلیت انعطاف تبدیل می كند. انعطاف‌پذیری از توانایی عامل‌ها در پاسخ به تغییرات محیطی ناشی می شود. تعقیب كردن اهداف و بهبود كارها منجر به استحكام عامل‌ها می شود این كیفیت ها در سیستم های پیچیده ، پویا ، باز و محیط‌های خطا خیز مفید هستند.
عامل‌های نرم‌افزاری یک تکامل مستقیم از سیستم چند عامله هستند. خود MAS شامل و نشات گرفته ازهوش مصنوعی توزیع شده و موازی ، و همچنین حل مساله توزیع شده است که خصوصیات بد و خوب همه آنها را با هم دارد. یکی دیگر از مفاهیم عامل‌ها ، عامل‌های هوشمند است که در علم کامپیوتر به عامل نرم‌افزاری که هوشمندی به خرج دهد گفته می‌شود.عامل‌های هوشمند نرم‌افزاری را می‌توان به چهار دسته تقسیم نمود :
۱٫ عامل‌های خریدار : این عامل‌ها در طول شبکه حرکت میکنند. اطلاعات و سرویس‌ها را استخراج می‌کنند.برای محصولاتی مانند کتاب ، قطعات الکترونیکی و غیره مناسب هستند. این نرم‌افزارها به کاربران اینترنتی در پیدا کردن محصولات و خدمات مورد نیاز کمک می‌کنند. به طور مثال زمانی که فردی برای خرید محصولی به سایت خرید الکترونیکی می‌رود ، در پایین صفحه لیستی از محصولات را مشاهده می‌نماید که دیگر خریدارانی که به دنبال آن محصول بودند، به آن‌ها نیز توجه داشته‌اند. دلیل انجام این عمل این است که سلیقه کاربران به صورت نسبی به هم شبیه است و آنها به دنبال محصولات مشابهی هستند. به این تکنولوژی که با کمک عامل‌ها امکان پذیر است، فیلتر مشترک می‌گویند.
۲٫ عامل‌های شخصی : عامل‌های هوشمندی هستند که در ارتباط با انسان کارهای زیر را انجام می‌دهند : با انسان بازی کامپیوتری انجام می‌دهند ، بنابر نیاز کاربر اطلاعات را پیدا می‌کنند ، صفحات وب را به صورت خودکار برای کاربر پر می‌کنند. همچنین این عامل‌ها به منظور انجام کارهای کاربر به طور اتوماتیک به وجود آمده‌اند. مثلا بعضی از این عامل‌ها ، ایمیل‌های کاربران را با توجه به نوع درخواست کاربر ، طبقه بندی و مرتب می‌کنند.
۳٫ عامل‌های نظاره گر : برای مشاهده یک گزارش بر روی یک تجهیزات خاص(معمولا رایانه‌ای) استفاده می‌شوند. عامل‌ها ممکن است که مراحل تولید را در یک کارخانه یا در یک شرکت از نقطه تولید تا پشتیبانی را پیگیری نمایند، یا اینکه اتفاقات بازار سرمایه را نظاره‌گر باشند.
۴٫ عامل‌های داده کاوی : این عامل‌ها از فن‌آوری اطلاعات برای پیدا کردن الگوها از چند منبع مختلف استفاده می‌کنند. کاربر میتواند از اطلاعات طبقه‌بندی شده این عامل‌ها استفاده نموده تا اطلاعات مورد نیاز خود را بدست آورد. مثالی از این نوع عامل‌ها ، عامل‌هایی هستند که شرایط بازار را دائما بررسی و آن شرایط را به کاربر یا کارخانه گزارش می‌دهند تا کاربر یا کارخانه بتواند با توجه به آن شرایط تصمیمات صحیح بگیرد.
با توجه به توضیحات ارائه شده ، عامل هوشمند نرم‌افزاری یک نهاد خودکار است که محیط اطراف خود را نظاره می‌کند ، به آن واکنش نشان داده و فعالیتهای خود را برای دسترسی به اهداف مسیردهی می‌کند. [۴] عامل‌های هوشمند همچنین ممکن است عمل یادگیری را انجام دهند و از دانش خود برای رسیدن به اهداف استفاده نمایند. آنها می‌توانند ساده یا بسیار پیچیده باشند مانند یک ترموستات ماشین یا انسان‌ها در جامعه بشری. مثال‌های دیگر از عامل‌های هوشمند شامل فیلتر کنندگان هرزنامه‌ها و یا عامل‌های موتورهای جستجوگر می‌باشد.عامل‌های هوشمند به شیوه‌های متفاوتی تعریف شده‌اند ولی در کل می‌توان گفت یک عامل هوشمند بایستی خصوصیات زیر را داشته باشد: [۴] • تطبیق راه‌حل‌های جدید با قواعد افزایشی.
• تطبیق به صورت بَرخط و در زمان .
• قادر بودن به تحلیل رفتار ، خطا و موفقیت‌های خود.
• یادگیری و بهبود خود در تعامل با محیط .
• به سرعت از حجم عظیمی از داده یادگیری انجام می‌دهند.
• داشتن یک نمایشگر حافطه و مخزن بازیابی اطلاعات.
• داشتن پارامترهایی جهت نمایش حافظه کوتاه‌مدت و بلند‌مدت و فراموش کردن.
بنا به تعریف راسل ، عامل‌ها بر اساس درجه هوش و قابلیت‌های‌ به پنج طبقه تقسیم می شوند: [۴] ۱٫ عامل‌های بازتابی ساده
۲٫ عامل‌های بازتابی بر اساس مدل
۳٫ عامل‌های پایه هدف
۴٫ عامل‌های پایه ابزار
۵٫ عامل‌های یادگیری
عامل‌های بازتابی ساده بر اساس شرط- عمل ، کار خود را انجام می‌دهند به این معنا که اگر شرطی اتفاق افتاد آنگاه عمل مرتبط انجام گردد.در این حالت تمام محیط مشاهده می‌گردد و واکنش نشان داده می‌شود. در عامل‌های بازتابی بر اساس مدل محیط به صورت جزئی مشاهده می گردد و حالت کنونی درون عامل ذخیره می‌شود تا تصمیم‌گیری نماید. عامل‌های پایه هدف مانند براساس مدل است درحالی که ذخیره حالتی صورت می‌پذیرد که مورد رضایت و مد نظر عامل باشد. عامل‌های یادگیری در محیط‌های ناشناخته به کار می‌رود تا آگاهی عامل در آن محیط افزایش یابد.
عامل‌های هوشمند اغلب به صورت شماتیک به عنوان یک سیستم کاربردی انتزاعی مانند یک برنامه کامپیوتری در نظر گرفته می‌شوند به همین دلیل بعضی اوقات AIA نامیده میشوند. اما هنوز خیلی‌ها ترجیح میدهند که جوهره اصلی عامل‌ها را رفتار هدف‌دهی شده آنها در نظر بگیرند ، از این رو آنها را عامل‌های منطقی می نامند.
۱ -۲ -۲ . محیط عامل
از دیگر مفاهیمی که در بررسی مفهوم عامل اهمیت زیادی دارد «محیط» است. عامل‌ها را نمی‌توان به صورت مستقل ، بدون توجه به محیطی که در آن فعالیت می‌کنند در نظر گرفت. محیطی که عامل در آن به تعامل با دیگر عامل‌ها می‌پردازد در انتخاب مدل معماری و همچنین متدولوژی مهندسی نرم‌افزار تاثیر گذار است. خصوصیات محیط بنابر دسته‌بندی کلاسیک هوش مصنوعی توسط راسل ، شامل موارد زیر است:[۴] • قابل دسترس/غیرقابل دسترس : آیا عامل قادر به درک کامل حالات جهان پیرامون خود می‌باشد؟
• قطعی / غیرقطعی : آیا تغییر حالت محیط در وضعیت کنونی کاملا در نظر گرفته شده است؟
• ایستا/پویا : آیا تغییر حالت محیط در کنکاش‌های عامل در نظر گرفته شده است؟
• مقطعی/ غیرمقطعی : آیا رشته تعاملات عامل با محیط مستقل هستند؟
• گسسته/پیوسته : آیا تعامل عامل با محیط محدود است؟
بر اساس تحقیقات انجام شده محیط به عنوان یک انتزاع کلاس مرتبه اول در نظر گرفته می‌شود ،که عامل‌ها را احاطه و شرایط گفتگو بین عامل‌ها و دسترسی به منابع را فراهم می‌نماید. همچنین محیط باید قابلیت‌های زیر را داشته باشد:
• ارائه نمودن یک ساختار برای سیستم چند عامله.
• داشتن خدمات و منابع.
• پویا بودن.
• به صورت محلی قابل مشاهده باشد.
• به صورت محلی قابل دسترس باشد.
• تعریف و نظارت بر قواعد محیطی.
علاوه بر دسته‌بندی‌های فوق که دسته بندی کلاسیک هوش مصنوعی برای محیط‌های بسته است , عامل می‌تواند در محیطی باز فعالیت نماید و تمامی یا بخشی از خصوصیات و قابلیت‌های گفته شده را دارا باشد .درمحیط‌های باز دقیقا مشخص نیست که عامل با چه مواردی در آینده برخورد خواهد نمود و همین امر موجب انتخاب معماری‌های خاص عامل یا متدولوژی‌های طراحی سیستم چند عامله متفاوتی می‌گردد.

۱-۲-۳ . معماری عامل
معماری نرم‌افزار یک تجرید سطح بالا یا یک چهارچوب از ساختمان یک یا چند سیستم نرم‌افزاری که شامل اجزای سخت افزاری و نرم‌افزاری است که سیستم ، واسط‌ها ، روابط بین اجزا و رفتاری از اجزا را که قابل مشاهده توسط دیگر اجزا است را نشان می‌دهد. [۸] همچنین شامل تصمیمات مهم طراحی است که مجموعه‌ای از کیفیت‌های منجر به موفقیت سیستم را پشتیبانی می‌کند. اختصاص قسمتی از نیازهای سطح بالا به اجزای نرم افزاری در معماری سیستم تعریف می‌شود.
مطالعه معماری دیدگاه‌های مختلفی را مهیا می‌کند که مانند نمونه‌سازی به صحت نیازمندی‌ها وتنظیم دقت آنها کمک می‌نماید. معماری برای سیستمی که شامل سخت‌افزار و نرم‌افزار یا بسیار پیچیده است امری حیاتی به شمار می‌آید چرا که خاصیت ردیابی اطلاعات به تیم توسعه کمک میکند نیازهایی را که در طراحی آن مشخص گردیده پیگیری نمایند. معماري شامل تكنيك‌ها و الگوريتم‌هايي است كه اين متدولوژي را حمايت مي كند.
به بیان دیگر معماری عامل نقشی تعیین کننده درخصوصیات و رفتار عامل دارد.معماری عامل به عنوان یک برنامه کاری برای طراحی عامل نرم‌افزاری و سیستم هوشمند عمل می‌نماید. این تعریف از معماری در عامل‌های هوشمند به نام معماری ادراکی شناخته می‌شود.در نهایت می‌توان عنوان نمود که انواع معماری عامل می‌توانند به صورت ذیل دسته‌بندی شوند:
۱٫ مدل منطقی : سمبولیک است و از مکانیزم Reasoning استفاده می‌کند.
۲٫ مدل واکنشی : بر اساس انجام یک عمل پاسخ می‌دهد.
۳٫ مدل لایه ای : این مدل تر کیبی از مدل‌های دیگر است.
۴٫ BDI : دارای ساختار ذهنی و یکی از معروفترین مدلهایش PRS است.
معروفترین مدل‌های استفاده در معماری که در متدولوژی‌های مختلف مد نظر قرار می‌گیرد ، مدل معماری لایه‌ای و BDI است. در مدل لایه‌ای پیشنهاد ، تشکیل یک سیستم چند لایه است که هر لایه یکی از وظایف را بر عهده دارد. نحوه قرار گرفتن لایه‌ها می‌تواند به صورت افقی یا سلسله مراتب عمودی ویا ترکیبی از این دو باشد.در معماری مبتنی بر باورها ، تمایلات و قصدها رسیدن به هدف مشخصی بر اساس یک استدلال عملی است.در این معماری ، جریان کاری از دریافت از حسگرها تا پاسخ وجود دارد که نحوه ادامه کار را مشخص می‌نماید.

۱-۲-۴٫ معماری BDI
در معماری BDI رسيدن به هدف و انجام عمل از طرف عامل بر اساس نحوه تصميم‌گيری انسان‌ها درباره مسائل مختلف زندگی است که هر روزه انجام می‌دهند. انسان‌ها در هر موقعيتی بر اساس باورهايی که از موقعيت خود و دنيای بيرون دارند، به بررسی انتخاب‌های ممکن ( یا تمايلات) می‌پردازند و در نهايت يکی از گزينه های ممکن انتخاب می‌شود تا رسيدن به آن هدف حاصل آيد. به بیان ديگر در اين معماری رسيدن به هدف با توجه به مفهوم «استدلال عملی» صورت می‌گيرد. از ديدگاه فلسفی، استدلال عملی مستلزم دو فعاليت مهم تصميم‌گيری در مورد اهداف موردنظر و چگونگی رسيدن به اين اهداف می‌باشد. بحث اول تحت عنوان بررسی و قياس و بحث دوم نتيجه گيری بر مبنای تحليل استدلال عملی مطرح است.
يک عامل می‌تواند تصميم‌گيری کند که چه کاری را انجام دهد و چگونه به اين کار برسد. در اين راستا عامل سعی در فهم انتخاب‌های مختلف و سپس يکی از آنها را انتخاب می‌کند. مساله اصلی در استدلال عملی دستيابی به قصدهای صحيح با توجه به تغييرات محيط است. ممکن است قصد در زمان‌های مختلف تغيير کند و لذا نياز به تجديد نظر نمودن قصد خواهد بود. تجديد نظر خود با هزينه‌هايی همراه است. با توجه به موضوع عنوان شده، برای عامل‌های BDI تابعی تحت عنوان تابع تبادل نظر در نظر گرفته می‌شود که به دو جزء تقسيم می‌گردد. بخش اول ايجاد کننده انتخاب‌های و بخش دوم فيلتر کردن انتخاب‌ها. بخش ايجاد کننده انتخاب‌ها به‌گونه‌ای است که هر عامل مجموعه‌ای از پيشنهادهای مختلف را توليد می‌کند. اينکار از طريق تابعی بنام Option که باورهای جاری عامل و قصدهای جاری آنرا می‌گيرد، صورت می‌پذيرد و بر اين اساس مجموعه انتخاب‌ها (تمايلات) تعيين می‌شود. در بخش فيلتر کردن، عامل بين حالت‌ها و پيشنهادهای مختلف، انتخاب انجام داده و برای رسيدن به آنها به توافق می‌رسد. به عبارتی دیگر از تابعی که فيلتر ناميده می‌شود برای انتخاب حالت‌های مختلف استفاده می‌نمايد. در ادامه نياز به بازنمايی اهداف/ قصد برای رسيدن به آنها و نيز اعمالی که می‌تواند انجام بدهد و بازنمايی محيط خواهد داشت. بطوريکه برای رسيدن به هدف برنامه‌ريزی نموده و اين‌کار به‌صورت برنامه‌سازی اتوماتيک صورت می‌پذيرد. همانگونه که قبلا نيز مطرح شد، معماری BDI بر مبنای استدلال عملی است. در اين معماری، تصميم‌گيری بر اساس ساختارهای داده‌ای است که باورها، تمايلات و قصد عامل را بيان می‌کنند. باورها بيانگر اطلاعات عامل در مورد وضعيت‌های جاری بوده و تمايلات مجموعه‌ای است که کانون فعاليت عامل را بيان کرده ، بطوريکه همان اهداف ممکن است. انتخاب اهداف نيز همان قصد است. فرآيند استدلال عملی در عامل BDI در تصویر ۳ مشاهده می‌شود. يک معماری BDI شامل هفت جزء می‌باشد:
• يک تابع بازنگری باورها (brf) که بعنوان ورودی درک عامل را با نگاشت بر روی محيط دريافت نموده و باورهای جاری را بهنگام می‌سازد.
• پايگاه دانش ، باورهای جاری که اطلاعات عامل را در محيط جاری‌اش بيان می‌کند.
• تابع توليد گزينه های انتخاب (Option) که ورودی آن باورها و قصد عامل بوده و بر اساس آنها انتخاب‌های ممکن برای عامل را که در واقع همان تمايلات وی است، تعيين می کند. توصيف صوری اين تابع بصورت زير است:
• مجموعه‌ای از گزينه‌های معتبر که مبين اعمالی است که عامل می‌تواند انجام دهد.
• Filter : يک تابع فيلتر که ورودی آن عقايد، باورها و قصدهای عامل بوده و خروجی آن بر اساس فرآيند تبادل نظر (قياس) اهداف (قصد) جديد عامل است:
• مجموعه‌ای از قصدهای جاری که کانون فعاليت عامل را تعيين می‌نماید.
• Execute : تابع انتخاب عمل بر پايه قصد و اهداف فعلی که عملی را که بايد انجام شود، تعيين می‌کند:
۱-۲-۵ . ارتباطات و هماهنگی در عامل‌ها
از آنجا که عامل‌ها در محیط مشترکی برای رسیدن به یک هدف فعالیت می‌کنند، نیازمند زبان مشترک برای درک یکدیگر هستند. همچنین قراردادهایی جهت هماهنگی و جلوگیری از هرج و مرج هستند ، هرچند که در یک اجتماع گاهی تا حد خاصی هرج و مرج قابل تحمل است. هماهنگی علاوه بر جلوگیری از هرج و مرج میتواند جهت افزایش کارآیی استفاده شود.برای ایجاد هماهنگی میان عامل‌ها در سیستم‌های چندعامله از قالب تعریف شده سازمان یا قراردادهای مشخص استفاده می‌گردد. در یک اجتماع عامل‌های سازماندهی شده ، هماهنگی را در قالب همکاری و یا رقابت تعریف می‌نمایند.
عامل‌ها براي رسيدن به هدف ، تحت ارتباطات سازماندهي شده تعامل دارند .اين بستر سازماندهي ، رفتار عامل‌ها را تحت تاثير قرار مي‌دهد ودر این حالت است که نياز به تيم‌ها، يكپارچگي و صلاحيت در ارتباطات ضرورت پیدا می‌کند. روش ایجاد ساختار سازمانی برای عامل‌ها میتواند به دو شکل سنتی مشتری/ خدمت گذار و یا تخته سیاه باشد. البته روش‌های دیگری همچون ایجاد قراردادها در سیستم‌های توزیع شده مبتنی برعامل نیز به کار می‌رود.جهت ایجاد همکاری میان عامل‌ها در سیستم‌های متنوع امروزی ، زبان‌های استانداردی به وجود آمده‌اند.گفتگوی میان عامل‌ها در قالب مذاکره معنا می‌یابد.گفتگوی میان عامل‌ها در محیط و ارتباط آنها مستلزم درک معنا از گفتگوی انجام شده است. حال این ارتباط تعریف شده می‌تواند مختص به یک برنامه و یا سراسری باشد. در ارتباط میان عامل‌ها ، فهم یکسان از یک پدیده امری مهم است به همین جهت از هستان شناسی در ارتباطات عامل‌ها استفاده میگردد.
۱-۳٫ مقایسه عامل و شیء
عامل و شيء متفاوت هستند. بدین صورت که يك عامل علاوه بر مفاهيمي همچون خصلت و متد ، شامل حالات ذهني مانند مفاهيم نقشه و هدف . مورد تفاوت ديگر ، نحوه ارتباطات در شيء و عامل است. عامل‌ها از يك روش با معني و با ساختار با استفاده ار پروتکل ، پيغام مبادله مي‌كنند در حالي‌كه در شيء این فرآیند شامل بيدار نمودن يك متد يا انتقال ساده يك داده است که براساس خصوصیات آن دو در نمایش‌های مختلف استوار است. در ابتدا از روی تعاریف مطرح شده می‌توان در جدول ذیل خصوصیات شیء و عامل را مقایسه نمود.
بر اساس جدول ۱ در می‌یابیم که تفاوت عامل و شیء در تعریف می‌باشد که یک عامل تمامی خصوصیات یک شیء را دارا می‌باشد ، اما علاوه بر آن خصوصیات ، عامل دارای ارتباطات اجتماعی قانونمند است و خودمختاری آن بر اساس یک هدف بوده و در موقعیت‌های زمانی خاص بر اساس حالات خود واکنش نشان می‌دهد.
• عامل‌ها نسبت به اشياء خود مختار هستند. عامل‌ها خودشان نسبت به انجام درخواست عامل ديگر تصميم می گيرند.
•عامل‌ها قابليت رفتار انعطاف پذير دارند. در مدل استاندارد شیءگرا اين قابليت‌ها در نظر گرفته نمی شود.
بدین ترتیب می‌توان نتیجه گرفت یک عامل به شکلی فعال‌تر میتواند موجودیت‌هایی را که در محیط اطراف وجود دارند را مدل‌سازی نماید.
۱-۴ مقایسه برنامه نویسی شیءگرا و برنامه نویسی عامل گرا
در بررسی برنامه‌نویسی شیءگرا در مقابل برنامه‌نویسی عامل‌گرا می‌توان مقایسه‌ای مانند جدول ۳ انجام داد.
در برنامه‌نویسی عامل‌گرا و شیءگرا تفاوت‌های نوع پیغام و واحدهای مورد استفاده قابل توجه است ، که در بعضی موارد موجب پیچیدگی‌هایی در استفاده از روش عامل‌گرا می‌گردد. اما سادگی آن در ارائه ساختارهای مشخص است که در بعضی از خصوصیات موجب برتری برنامه نویسی عامل‌گرا می‌شود. در جدول ۲ مشاهده می شود که در برنامه‌نویسی عامل‌گرا تفاوت‌هایی در مقایسه با برنامه‌نویسی شیءگرا وجود دارد ، که باعث ایجاد تفاوت‌هایی در روش برنامه‌نویسی آن دو می‌گردد.
جیمز اودل در مقاله خود[۹] تکامل روش های برنامه‌نویسی را که منجر به برنامه‌نویسی عامل‌گرا شد را در قالب جدول ۴ ، تقسیم‌بندی نمود.
در جدول ۴ ، خصوصیات و وجه تمایز روش‌های برنامه‌نویسی در قالب واحدهایی که برایشان کُد نوشته می‌شود به شکلی ساده مشاهده است.در این جدول اگر هر واحد را به عنوان یک موجودیت در نظر گرفته شود ، درخواست‌ها می‌توانند از نهادهای خارجی یا داخلی باشند. در ُبعد مقایسه معماری می‌توان به این امر اشاره نمود که در طراحی عامل‌ها ، با توجه به تفکیکی که انجام می‌گیرد ، در مقایسه با اشیاء ، پیچیدگی کمتری را در روابط و ساختار قابل مشاهده است.چرا که در بزرگ شدن سیستم‌ها و افزایش پیچدگی ، در طراحی شیءگرا ، تعداد روابط افزایش می‌یابد و به طبع پیچیدگی و تداخلات زیاد می‌شود. به تصویر ۴ توجه نمائید.

۱-۵٫ رابطه برنامه نویسی سرویس‌گرا و عامل‌گرا
امروزه پس از تكامل الگوريتم‌هاي محاسباتي ، حرکت به سمت تعامل ميان محاسبات از اهمیت برخوردار است. اين امر مستلزم خودمختاري عامل‌های محاسباتی و توانايي عامل‌های واسط براي تعامل با محيط است.سرويس‌ها بایستی کُنش‌گرا باشند و این امر نیاز به عامل دارد و خود عامل‌ها نیز نياز به درك بر اساس هستان شناسی دارند.
پيچيدگي موجود در ارائه برنامه نويسي سرويس‌گرا كه مواردي همچون ساختار ، پيغام رساني، امنيت و … را در برمي‌گيرد راه را به سوی استفاده از هستان شناسي و عامل‌ها برده است. تكنولوژي‌هايي كه به اين سمت حركت كرده‌اند عبارتند از : OAG, OASIS,BizTalk,RostteNet . داشتن يك هستان شناسي سراسري جهت كار كردن با عامل‌ها باعث میشود که يك وب‌سرويس به چند روش ارائه شود .در جدول ۵ می‌توان ساختار واحدهای مختلف برنامه نویسی سرویس‌گرای مبتنی بر عامل را در مقایسه با روش‌های پیشین دید.
در برنامه‌نويسي سرويس‌گرا دو مزيت ساختن برنامه‌هاي انعطاف‌پذير و بازدهي برنامه‌نويسي و مديريت برنامه كاربردي در سيستم‌هاي باز وجود دارد.
مزیت‌های دیگری در ترکیب با سیستم چندعامله از جمله موارد زیر دارد :
• ارائه ابزار براي مدل‌سازي اطلاعات كه امكان همكاري درون يك سازمان را فراهم مي‌كند.
• اجازه خودمختاري درون سازمان را به هر فرآيند مي‌دهد.
• اجازه خصوصي‌سازي برنامه‌هاي جديد را از طريق واسط با سرويس مي‌دهد.
• اجازه انتخاب بر اساس كيفيت سرويس را مي‌دهد.
• اجازه استفاده موثر از منابع توزيعي را ميدهد.
• عامل‌ها درباره خود مي‌دانند و مي‌توانند از عامل‌هاي ديگر آگاه شوند و اين مزيتي براي ارائه سرويس است.
• عامل‌ها برخلاف سرويس‌ها مي‌توانند از يك هستان‌شناسي براي ارتباط استفاده كنند.
• عامل‌ها براي ارتباط ساخته شده‌اند در حالي كه سرويس‌ها تا فراخوانده نشوند غيرفعال هستند.
• وب سرويس به صورت اوليه خودمختار نيست و همانطوري كه نوشته مي‌شود استفاده مي‌گردد.
• عامل‌ها با يكديگر همكاري ميكنند تا هدف بزرگتري دست يابند.
با توجه به موارد گفته شده ، براي اينكه SOA مزيت‌هاي فوق را داشته باشد نيازمند موارد زير است : جفتگيري ضعيف، پياده سازي بي طرف، تنظيمات انعطاف پذير، دوره حيات طولاني، دانه دانه بودن، محاسبات تيمي. در واقع یک همکاری دوطرفه میان برنامه‌نویسی سرویس‌گرا و چندعامله اتفاق می افتد.آنچه برنامه نويسي سرويس‌گرا به چند عامله مي‌دهد ، ارائه تكنولوژي اطلاعات سنتي و رفتارهاي استاندارد براي تسهيل ابزارهاي توسعه است.كه معماري سيستم‌ها را مي‌توان در قالب مدل عِلي، مدل فرآيند، جريان كاري و گراف هدف-زيرهدف يا مدل‌هاي رسمي بيان نمود. مساله مورد توجه در طراحي چنين سيستم‌هایي برآورد ارتباط سراسري اجزاء است بدون اينكه درگیری با كنترل سراسري بوجود آید.

۱-۶٫ سيستم‌های چندعامله
سيستم‌های چندعامله، زير حوزه‌ای در حال رشد از هوش مصنوعی است که هدف آن فراهم ساختن اصول ساخت سيستم‌های پيچيده‌ای است که شامل چند عامل و ساز و کارهايی برای هماهنگ سازی رفتارهای اين عامل‌ها می‌باشد. چگونگی هماهنگ‌سازی دانش، اهداف، مهارت‌ها و برنامه‌ريزی‌های عامل‌ها برای حل مسائل در اين مقوله می گنجد. عامل‌ها در محيط ممکن است در راستای هدفی خاص و مشترک و يا در راستای اهداف خاص و جداگانه ای که در تعامل با يکديگر باشند، کار کنند. بحث هماهنگی در سيستم‌های چندعامله از مباحث اساسی بوده و بدون آن مزايای تعامل و رفتارهای اجتماعی عامل‌ها محو می گردد. از ديدگاه هوش مصنوعی توزيع شده، سيستم چندعامله اجتماعی از عامل‌های مستقل برای حل مساله است که هر عامل کليه خصوصيات مطرح شده را داراست. سيستم های چندعامله دارای مشخصات زير هستند : [۱۰] • دانش کافی و لازم برای حل يک مساله در يک عامل وجود ندارد.
• کنترل سيستم توزيع شده است(يک سيستم کنترل کلی وجود ندارد.)
• داده‌ها غيرمتمرکز می باشند.
سيستم‌های چندعامله راه حل‌هايی را برای مسائل توزيع‌شده در محيط‌های محاسباتی باز و پويا فراهم می‌آورند. راه حل چنين مسائلی می‌تواند بر مبنای چندين عامل که توزيع‌شدگی مساله، وجود چندين نقطه کنترل، چندين ديدگاه يا علائق در حالت رقابت را پوشش دهند، ارائه گردد. علاوه بر اين عامل‌ها برای رسيدن به اهداف خود نياز به تعامل با يکديگر خواهند داشت. اين تعاملات که در سطح دانش صورت می‌پذيرد، می‌تواند يک تبادل عقايد ساده، تمايلات، قصدها برای درخواست انجام عمل باشد که لازم است از طريق هماهنگی، همکاری و يا مذاکره برای مديريت اعمال وابسته بهم صورت گيرد[۱۰]. اين تعامل با تعامل در ساير سيستم‌های محاسباتی دو تفاوت عمده دارد: اول آنکه تعامل ميان عامل‌ها در سطح دانش صورت می‌گيرد [۱۱][۱۰].اين تعاملات بر حسب اينکه چه هدفی بايد در چه زمانی، توسط چه افرادی دنبال شود بيان می‌شوند و دوم اينکه چون عامل‌ها موجوديت‌هايی انعطاف پذير هستند که در محيطی که تنها بر روی بخشی از آن کنترل دارند عمل می‌کنند، تعاملات بين آنها نيز بايد انعطاف پذيرتر باشد. بنابراین عامل‌ها بايد بتوانند درباره محدوده تعاملات خود در زمان اجرا تصميم گيری داشته و تعاملاتی را که در زمان طراحی نيز ديده نشده اند، آغاز کنند و يا به آنها پاسخ دهند. تعامل اجتماعی در عامل‌ها بدين معنی است که روابط موجود ميان عامل‌ها در حال تکامل بوده و روابط جديدی ايجاد می گردد. بدين منظور لازم است تا قوانينی به منظور شکل دهی به روابط سازمانی و مکانيزم‌هايی به منظور تضمين انسجام گروهی و ساختارهايی برای مشخص کردن رفتار کلان مجموعه ها در نظر گرفته شود. به عبارتی دیگر عامل‌ها ، تعاملات سطح بالا و روابط سازمانی، مفاهيم اساسی در سيستم‌های چندعامله را بوجود می آورند. يک سيستم چند عامله، از اجزای زير تشکيل شده است:
• محیط : يک محيط که در بر گيرنده اجزاء تاثيرگذار در سيستم چند عامله می باشد. اما لزوما تمام عوامل تاثيرگذار در حالت سيستم چند عامله، درون آن قرار ندارند.
• تعداد عامل : به طور معمول هيچ گونه پيش فرضی در مورد نوع، معماری و تعداد عامل ها در يک سيستم چندعامله وجود ندارد. از اين جهت می توان يک سيستم چند عامله را به يک جامعه انسانی تشبيه نمود.
• مجموعه ای از اشياء درون محيط : هيچ پيش فرض اوليه ای در مورد اين اشياء نيز وجود ندارد.
• مجموعه ای از روابط : اين روابط ، که می توان آن ها را به قوانين نيز تعبير نمود، ارتباطات ميان اشياء با اشياء ديگر و نيز ارتباطات بين عامل ها با اشياء را مشخص می نمايند.
• مجموعه عمليات قابل انجام توسط عامل ها : اين مجموعه شامل دو دسته کلی از عمليات می باشد. عمليات حس (دريافت اطلاعات) از محيط و عمليات تاثيرگذار بر محيط.
البته بطور رسمی و دقيق سيستم چندعامله به صورت يک چهارتايی است که در آن مجموعه عامل‌های تشکيل دهنده سيستم چندعامله می باشد. Env محيطی است که سيستم چندعامله در آن عمل می کند. Org سازمان سيستم چندعامله و D قلمروی آن سيستم چندعامله است.

۲- مهندسی نرم افزار مبتنی بر عامل
مهندسی نرم‌افزار ، عملیاتی است مربوط به طراحی ، پیاده سازی و تغییردادن نرم‌افزار ، به گونه ای که از کیفیت بالاتر، با بهره-وری بیشتر ،قابلیت نگهداری و سرعت ساخت برخوردار باشد. از این رو رویکرد سیستماتیک به تجزیه و تحلیل ، طراحی ، ارزیابی ، اجراء ، تست ، نگهداری و مهندسی مجدد به عنوان کاربردهایی در مهندسی نرم‌افزار مورد توجه می باشند.
با گسترش تكنولوژی اطلاعات در دهه ٨٠ میلادی تعداد زیادی برنامه های نرم‌افزاری برای نیازمندی های پیچیده بوجود آمد و تكنیك های تحلیل ساخت یافته آنچنان مؤثر نبودند. به همین دلیل ، روش‌های شیءگرا معرفی شدند. این روش ها جنبه‌هایی مانند مخفی سازی اطلاعات ، انتزاع داده ای، تلفیق داده ها و همزمانی را در خود دارند. همچنین شیءگرایی تلاش نمود تا فاصله جهان حقیقی و بازنمایی آن را پر نماید. این امر در برنامه‌های كاربردی بوسیله مدل‌های نهاد‌های واقعی توسط اشیاء انجام می‌گیرد.به همین دلیل قابلیت‌های بسیاری مانند افزایش كاربر ، بهبود تغییرپذیری و نگهداری از این روش نتیجه شده است. مهندسی نرم‌افزار شیءگرا که یک متدولوژی و زبان مدلسازی شیء است، توسط ایوار یاکوبسون در سال ۱۹۹۲ طراحی شد. این اولین متدولوژی طراحی شیءگراست که از»مورد کاربرد» برای طراحی نرم‌افزار استفاده می‌نماید. همچنین عناصر طراحی دیگری نیز شبیه به عناصر مورد کاربرد درمدل سازی اشیاء دارد.در روند تکمیل این روش مفاهیم و نمادهای OOSE در UMLاستفاده شدند و درشکل متدولوژی دیگر به نام RUP به بلوغ رسید. با توجه به اثبات قدرت شیءگرایی ، سیستم های نرم‌افزاری پیچیده‌تر شده اند و این مفهوم قادر به پاسخ به نیازهای جدید نبود.
یكی از آن ها تغییرات سریع محیط سیستم‌های اطلاعاتی است. سیستم‌های نرم‌افزاری هم اكنون به یكدیگر بیشتر متصل هستند و غیر متمركز شده اند این تغییرات با توجه به افزایش محبوبیت اینترنت پیچیدگی‌های پیش‌ رو را افزایش داده است.
با افزایش پیچیدگی سیستم‌ها و پیشرفت روزافزون اینترنت و سیستم‌های همراه ، نیاز به ارائه روشی مهندسی برای برخورد با آنها لازم به نظر می رسید .در سيستم هاي پيچيده مفاهيمي همچون ارتباطات ميان زيرسيستم‌ها و درون سيستم‌ها بر پيچيدگي مي-افزايد.با توجه به توضیحات داده شده و همچنین دو دلیل زیر برای برخورد با سیستم‌های پیچیده از روش‌هاي سنتي مهندسي نرم‌افزار استفاده نمي‌شود[۱۲] :
١.زیرا طراحي سطح بالا براي هر روش برنامه‌نويسي ، انتزاع‌هاي متفاوتي دارد مانند این مسئله که در برنامهنويسي رويه‌اي مي‌گوييم چه كاري انجام مي‌دهد؟شيءگرا مي‌گويد چه اشيايي آنجا هستند؟ داده و عمليات کدام است؟عامل مي‌گويد چه اهدافي وجود دارند؟ چه رابطه‌اي بين عامل‌ها وجود دارد؟
٢.در طراحي سطح پايين با اعمال غيرقطعي و شكست‌ها روبرو هستيم كه نيازمند نقشه‌هاي جايگزين و بيش از يك راه حل مورد نياز است.
با توجه به خصوصیات سیستم‌های پیچیده ، استفاده از مجموعه‌ای از اشیا غیر فعال منطقی به نظر نمی رسد به همین علت علاقه به عامل‌ها و مفهوم مهندسی نرم‌افزار آن افزایش پیدا كرده است.دو مفهوم قابلیت های پیشرفته عامل‌ها و سیستم‌های چند عامله و قابلیت بازنمایی قوی آن ها راه‌حل های خوبی را برای سیستم‌های پیچیده فراهم می كند.
سه ابزاری كه عامل‌گرایی برای توسعه و مدیریت پیچیدگی در اختیار استفاده كنندگان قرار می دهد عبارتند از: شكستن،انتزاع و سازمان. با شكستن فضای مسئله ، سیستم پیچیده به بخش‌های عامل و ارتباطات شكسته می شود. با انتزاع عامل ها، برای طراحی و ساخت سیستم ها مناسب به نظر می‌رسند و مورد سوم بیانگر كارایی آن ها برای مدل‌سازی و مدیریت روابط سازمانی برای رسیدن به وابستگی‌ها و روابط درون سیستم پیچیده است.در جدول ۶ مقایسه سیستم مبتنی بر عامل با سیستم پیچیده مشاهده می‌شود.
با توجه به دلایل فوق و همچنین مزایای دیگر استفاده از سیستم‌های چندعامله در حل مسائل مهندسی مانند افزایش قابلیت اطمینان، توسعه پذیری، استفاده مجدد، امکان اجرای موازی ، تعامل سیستم‌های متفاوت، امکان پیاده‌سازی نظریه‌های علمی رشته-های دیگر ، سیستم‌های پیچیده مهندسی نرم‌افزار مبتنی بر عامل ، به عنوان راهکاری جدید در مهندسی نرم افزار مطرح شدند.
در سال ۱۹۹۲ میلادی «وولدریج» متدولوژی MADE را معرفی نمود و در سال ۱۹۹۸ تحت مقاله ای به نام مهندسی نرم افزار مبتنی بر عامل برای اولین بار به بیان مفهوم جدید مهندسی نرم افزار مبتنی برعامل پرداخت.[۱۳].
در AOSE اجزای مطرح و پایه ای عامل‌ها هستند، و این روش مهندسی بر روی بعضی از سیستم‌هایی که مبتنی بر عامل نیستند نیز قابل اعمال است . در متدولوژی های مهندسی نرم افزار مبتنی بر عامل ، تمامی یا قسمتی از زیربخش‌هایی که در علم مهندسی نرم-افزار مطرح هستند ، پوشش داده می شوند. در ادامه برای تکمیل مبحث ، به توضیحات ذیل توجه بفرمائید.
الف) فرآيند توسعه: مجموعه اي از گام هایی است كه شامل فعاليت ها ، محدوديت ها و منابعي براي رسيدن به يك خروجي مطلوب می باشد كه يك سري از نيازهاي ورودي را پاسخگو است. فرآيند معمولا شامل چند مرحله يا قدم است كه هر كدام يك فعاليت را نشان مي دهند.
ب) فرآيند توسعه نرم‌افزار : مجموعه اي همسان از سياست ها، ساختارهاي سازماني، فن آوری ها،روش ها و محصولاتي كه براي توسعه ، نگهداري، تجهيز و درك سيستم نرم‌افزاري مورد نياز هستند. فرآیند توسعه ی نرم افزار شامل مراحلي براي رسيدن به محصول نهايي است، که گام های تعریف شده در آن ، با فرآيند توسعه، سه تفاوت اساسی دارد :
• بايد نيازمندي ها درك شوند.
• بايد در محيط عملياتي كارگذاشته شود.
• بنا بر درخواستهای کاربران و نياز به تغييرنرم افزار، نگهداري از آن انجام می شود.
فرآیند توسعه نرم‌افزار که با عنوان چرخه ی حیات تولید نرم‌افزار نیز شناخته میشود، ساختاری است که روی توسعه و تولید محصولات نرم‌افزاری اعمال میشود. عبارت های همانندی چون چرخه حیات نرم‌افزار و فرآیند نرم‌افزار در این رابطه استفاده میشود. مدل‌های گوناگونی همچون فرآیندهای خاص وجود دارند که هر کدام خط مشی مختص آن فرآیندها را برای انجام کارها و فعالیتهای متنوع در طول فرآیندها مشخص میکنند.
به يکسري از راه‌حلها و تکنيک هايي که نيازهاي هر مرحله از فرآيند توسعه نرم‌افزار را پیدا نماید، شناسایي گفته مي‌شود.حال پس از شناسایی ، بايد راهي براي نمايش آنچه که در دست است، داشته باشيم. براي اين منظور نياز به قواعدي براي نمايش داريم که براي همگان قابل درک باشد که به اين اصول، بازنمايي گفته مي شود . بازنمايي بايد دو شرط داشته باشد : ۱) کامل باشد. ۲) کمترین ابهام را داشته باشد .
پ) مدل فرآيند نرم‌افزاري: مدل فرآيند بيان كننده اين مطلب است كه كدام فاز از فرآيند بايد سازماندهي شود و در چه مرتبه‌اي اجرا گردد و چه هماهنگي ميان كارهاي مختلف مراحل اتفاق افتد. در ادامه انواع مدل فرآيند به اختصار شرح داده خواهند شد.

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

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

• مدل فرآیند تکراری و افزایشی
روش تکراری تولید نرم‌افزار، اجازه می دهد که پروژه در ابتدا از بخش‌های کوچک آغاز شود و به مرور زمان که سیستم رشد می کند ،کمک می نماید که مشکلات مهم پیدا شوند ، پیش از آن که فرضیه های نادرست ،سبب خراب شدن سیستم شوند. مدل تکرار فرآیند ها بوسیله ی تولید کنندگان نرم‌افزارهای تجاری انتخاب و استفاده می‌شود، چون این مدل اجازه می دهد تا نیازهای کاربرانی -که در زمان طراحی دقیقا نمی دانند که چگونه نیازمندی هایشان را از سیستم معرفی کنند- به گونه ی بالقوه برآورده شود.
افزون بر روش‌های بالا که به اختصار گفته شد ، روش های معروف دیگری همچون روش چابک وجود دارد که روش تکراری را به عنوان پایه کار استفاده می‌کند.مدل چابک از بازخوردها به جای برنامه‌ریزی به عنوان مکانیزم اصلی کنترل پروژه استفاده می نماید.بازخوردها بوسیله آزمون‌های مرتب و انتشار نرم‌افزارهای در حال تکامل تولید می شوند.
ج) زبان مدل سازی : برای مدل سازی از زبان استاندارد آن UMLاستفاده می‌شود.همانطور كه از این نام پيدا است يك زبان مدل‌سازي است تا يك متدلوژي كه در فاز تحليل و طراحي مورد استفاده قرار ميگيرد.. بطور معمول، هر متدلوژي شامل حداقل يك زبان مدل سازي و يك فرآیند ساخت است. زبان مدل‌سازي شامل نمودارهايي است كه هر متدلوژي براي نمايش تحليل و طراحي سيستمها از آن استفاده ميكند. اما يك پروسه ساخت شامل دستورات، راهنمايي‌ها و قدم‌هاي لازم براي انجام تحليل و طراحي سيستمها ميباشد. افرادي كه يك متدلوژي را به كار مي‌برند معمولاً بيشتر با زبان مدل‌سازي آن سروكار دارند. همچنین گستره هایی برای این زبان تعریف شده که قابلیت آن را برای متدولوژی‌های متفاوت افزایش می‌دهد، از جمله می‌توان به AML اشاره نمود. این گستره یک سری نشانه ها را به نشانه های استاندارد UML می افزاید تا قابلیت بیان و مدل‌سازی عامل‌ها را داشته باشد.
د) متد : بيان كننده نحوه انجام يك كار مشخص درون فرآيند براي توليد يك خروجي است.
ذ)متدولوژي: يك متدولوژي مجموعه‌اي از متدها است كه مراحل مختلف يك فرآيند را پوشش داده و به هم متصل مي‌كنند. هدف متدولوژي ، بيان يك روش مشخص براي حل مساله در فرآيند نرم‌افزاري و ايجاد ارتباط ميان متدهاي مختلف است. متدولوژی شیوه‌ای است که به‌وسیله آن سازمان‌ها و تیم پروژه به چهارچوب تعریف شده اعمال می‌گردند ، مانند برنامه‌نویسی ساخت یافته ، SSADM ، OOP و RAD . به بیان ‌ديگر ، به چهارچوب و روش کاري معيني که شامل علائم و نمودارهاي گرافيکي و نحوه استخراج اين علائم و تبديل آنها حين فرآيند توسعه است ، متدولوژي گفته می‌شود.
یک متدولوژی کامل علاوه بر ابزار ، نشانه و فرآیند بایدی موارد زیر را نیز فراهم نماید :
• راهنمایی هایی جهت تخمین هزینه
• کارهای مدیریت پروژه
• اندازه گیری‌ها و شاخص‌ها
• قالب‌های تعریف شده وقابل تحویل
• سیاست‌های اطمینان از صحت نرم افزاز
• تشریح جزیی نقش‌ها
• مثال‌های عملی
• تمرینات نمونه
• تکنیک‌هایی جهت ارزیابی روش‌ها
• تعریف روش‌ها
هردوي فرآيند و متدولوژي بر روي سوال ( what ) تمركز مي‌كنند، در حاليكه فرآيند بر روي فرآيندهاي سراسري و زمانبندي تمركز دارد و متدولوژي بيشتر بر روي تكنيك‌ها و محصولات تمركز مي‌كند. در متدولوژي علاوه بر سوال قبلي موارد who, how, when و how much نيز مطرح مي‌گردد.
در متدولوژي درباره مفهوم ، مدل ، فرآيند و ابزارهاي متدولوژی بحث می‌شود . متدولوژی‌های موردنظر براي توسعه عامل‌هاي هوشمند به طور معمول باید از ابتدا تا انتهاي فرآيند توليد محصول را حمايت کنند. برای شروع نكردن از نقطه صفر در طراحی متدولوژیهای عامل‌گرا ، سعي شد كه از روي كارهاي پيشين حركت شود اما با توجه به تفاوت های شیء و عامل، متدولوژی های شیءگرا ، تكنیك‌های مناسبی را برای مدل سازی رفتار عامل‌های هوشمند مهیا نمی كنند. از این رو متدولوژی‌هایی برای بیان سیستم بر پایه عامل ها معرفی گردیده است كه به دو دسته گسترش شیءگرایی و مهندسی دانش تقسیم می شوند.
• گسترش متدولوژی‌های شی‌ءگرایی: متدولوژی‌های عامل‌گرا كه به این دسته متعلق هستند خصوصیاتی از قبیل داشتن تشابهات عامل و شیء و استفاده از بلوغ متدولوژی‌های شیءگرا را در خود دارند همچنین از تكنیك‌هایی مانند موارد كاربرد كه برای تشخیص اشیا استفاده می‌شود در تشخیص عامل استفاده می‌كند.
• گسترش تكنیك‌های مهندسی دانش: به هر حال جنبه‌هایی از عامل در متدولوژی‌های شیءگرا گفته نشده است مانند حالات ذهنی یا جنبه های اجتماعی. به همین دلیل جنبه‌های مهندسی دانش برای گرفتن این خصوصیات مناسب به نظر می رسد مانند كتابخانه‌های هستان‌شناسی و كتابخانه‌های متدهای حل مسئله كه در متدولوژی‌های شیءگرا استفاده می شود.
از زماني كه عامل‌ها شخصيت شناختي پيدا كردند دانش عامل به عنوان يك تكنيك مورد استفاده قرار گرفت.ارائه تعريف دانش به عنوان فرآيند گرفتن دانش در اين متدولوژي‌ها مورد اشاره قرار گرفته است. گستره اضافه شده به متدولوژي‌هاي مهندسي دانش مزيت به كار بردن تجربيات در اين زمينه را دارند و همچنين امكان استفاده مجدد از ابزارها، كتابخانههاي هستان‌شناسي و متدهاي حل امكانپذير است . اما اكثر موارد و مشكلاتي كه در مهندسي دانش با آنها روبرو هستيم در طراحي سيستم‌هاي چندعامله هم وجود دارد مانند: گرفتن دانش، مدل‌سازي و استفاده مجدد .
مزايای استفاده از متدولوژی‌های مبتنی بر دانش ، توانايي مدل‌سازي وضعيت ذهني عامل‌ها از طريق مدل‌سازي دانش و همچنین امكان استفاده مجدد از ابزار‌ها و كتاب‌خانه‌هاي مربوط به هستان شناسی است. باید مواردي مانند روشهایی که براي سيستم مبتني بر دانش مركزي هستند مد نظر قرار گيرد البته در اين روشها به ويژگيهاي خودمختاري و پاسخ‌گويي به تغييرات محيط توجهي نشده است البته می‌توان مدل‌های دیگر را نیز مد نظر قرار داد.علاوه بر روش‌های گفته شده ، تكنيك‌هايي بر پايه تجربه توسعه دهندگان عامل نیز همچون تجربیات زیر وجود دارند:
• تجربه Archon : محيطي كامل جهت توسعه سيستمها چندعامله، كه يك روش بالا به پايين كه قادر به تشخيص اهداف و وظايف اصلي با شكستن پايين به بالاي انها و قابليت استفاده مجدد است.
• تجربه Made: محيطي براي نمونه‌سازي سريع عامل‌ها است، يك متدولوژي پنج بخشي شامل: تشخيص، مفهوم سازي، شكستن، فرمال سازي، پياده سازي و تست دارد.
• روش AWIC: در اين روش طراحي به صورت تكراري است كه در هر چرخه حيات پنج مدل توسعه داده مي‌شود. A مدل عامل ، W مدل جهان ، I مدل قابليت همكاري و C مدل هماهنگي .
همچنین روش‌هاي زيادي جهت پركردن تئوري رسمی عامل‌ها و پياده‌سازي آنها ارائه شده است. تئوري رسمی شامل مشخصات عامل‌ها كه اجازه مشخصات كامل سيستم را مي‌دهد. تئوري رسمی براي تحليل و صحتسنجي سيستم‌هاي حياتي يا پيچيده مفيد است .متدهاي رسمي در سه بخش مشخصات سيستم، برنامه نويسي مستقيم سيستم و صحت‌سنجي سيستم به كار گرفته مي‌شوند . روش‌هاي ديگری براي مدل‌سازي منطق وجود دارند، كه براي بازنمايي جنبه‌هاي پوياي عامل‌ها استفاده مي‌شوند. در کل می‌توان گفت هر متدولوژی عامل‌گرا با هر شرایطی که برای طراحی آن در نظر گرفته می‌شود، باید شامل پنج مرحله ذیل که هر کدام تاثیر خود را دارند باشد :
۱٫ تشخیص نقش‌ها در حوزه برنامه کاربردی.
۲٫ تشخیص مهارت‌های اصلی برای نقش عامل‌ها.
۳٫ مدل سازی دانش درباره حوزه برنامه‌های کاربردی با نقش‌ها.
۴٫ پویا بودن ساختار معماری که در جریان اطلاعات تحلیل شود.
۵٫ ساختار سازمانی یا همان معماری سیستم‌های چند عامله که طراحی گردد.
در ارائه متدولوژي‌های مبتنی بر شیءگرایی براي تحليل عامل‌ها سه مدل عامل ، سازمان و همكاري درنظر گرفته شد و قدم‌هاي فرآیند آنها به سمت مدل‌سازي این موارد پیش رفت. ازجمله متدولوژی‌های مبتنی بر شیءگرایی می‌توان از MASE یا GAIA نام برد. از متدولوژی‌های مبتنی بر دانش نیز می توان به Tropos و یا CoMoMAS اشاره نمود.از سال ۱۹۹۲ تا کنون بیش از ۷۰ متدولوژی با کاربردهای متفاوت معرفی شده است.نکته قابل توجه این است که در سال ۲۰۰۲ نزدیک به ۱۵ متدولوژی معرفی گردید و سپس معرفی متدولوژی‌های جدید کاهش یافت و بیشتر تحقیقات بر تکمیل متدولوژی‌های پیشین متمرکز شد.بعضي از متدولوژيهاي AOSE جداي از مدل فرآيند پياده‌سازي شده‌اند و قابليت كار در چند مدل فرآيند به صورت همزمان را دارا می‌باشند.

۳) متدولوژی پرومته
امروزه مهندسی نرم‌افزار مبتی بر عامل به عنوان رویکردی بعد از رویکرد شئ‌گرایی مطرح شده و در این راستا متدولوژی‌های مبتی بر عامل نیز در کانون توجه قرار گرفته‌اند. از آنجائیکه متدولوژی‌های مختلفی برای سیستم‌های مبتنی بر عامل ارائه شده ، تحقیقات متعددی نیز برای ارزیابی این دسته از متدولوژی‌ها صورت پذیرفته است. در تحقیقات صورت پذیرفته سه معیار اصلی میزان مستندات موجود در ارتباط با متدولوژی ، میزان شناخته بودن در جامعه محققان و کاربران و خاص منظوره نبودن متدولوژی برای ارزیابی در نظر گرفته شده و متدولوژی های MASSIVE ، Agent SE ، Tropos ، MaSE ، Gaia ، PASSI ، MAS-CommonKADS و Promethus به عنوان متدولوژی‌های برتر شناخته شده‌اند.[۱۵] اجازه دهید با واژه پرومته بیشتر آشنا شویم. پرومته یکی از اساطیر یونان و خدای آتش است. خدای خدایان زئوس در عصر آفرینش انسان‌ها ، پرومته را برگزید، تا همه چیز بجز آتش را به انسان دهد. پرومته این کار را انجام داد و بسیاری از مشکلات آدمیان را برطرف کرد. پرومته به انسان‌ها عشق می‌ورزید و نمی‌توانست ناراحتی و رنج آنها را ببیند.به همین علت به دور از چشم زئوس ، آتش را به انسان داد.هنگامی‌که خبر به زئوس رسید ، پرومته را برسر قله قاف در قفقاز برد و زنجیر کرد تا او را به سزای نافرمانی برساند . طبق مجازات تعیین شده ، هر روز عقابی می‌آمد و جگر پرومته را می‌خورد و شب جگر از نو می‌روئید . همین موقع بود که پرومته به زئوس گفت: روزی خواهد آمد که پادشاهی و خدائی تو از میان برود و کسی به تخت تو تکیه نزند. زئوس که از پیش‌گوئی‌های پرومته مطمئن بود ، دائم در پی این بود که بپرسد چه کسی ؟ اما پرومته هرگز پاسخ نمی داد ، تا این‌که این موضوع بوقوع پیوست.
ریمون آرون فیلسوف و روشنفکر فرانسوی در کتاب جریان‌های مهم در تاریخ تفکر جامعه‌شناسی ، شخصیت رفتاری انسان آگاه را، به شخصیت پرومته تشبیه می کند. منظور آن‌دسته انسان‌هایی است که شعور و آگاهی و خرد‌گرائی را به جامعه منتقل می‌کنند تا توده‌های ًمردم بتوانند ، خدایگان قدرت ، جهل ، خرافات و جنایات را هرچه سریع‌تر از اریکه قدرت پائین بکشند .
متدولوژی پرومته در سال ۲۰۰۲ میلادی توسط کرونکا با تمرکز بر روي ساخت عامل‌ها با استفاده از چهارچوب BDI ارائه گردید. در سال ۲۰۰۴ میلادی وینکوف و پادقان از انیستیتو تکنولوژی پادشاهی ملبورن استرالیا با ارائه کتاب Developing Intelligent Agent System : A Practical Guide این متدولوژی را به صورت کاربردی معرفی نمودند.[۲۱] در دنیای امروزی شاهد هستیم که نیاز به یک متدولوژی رشد یافته مهندسی نرم‌افزار برای تعریف و طراحی عامل‌ها ، موضوع اصلی در گذار عامل‌ها از آزمایشگاه‌های تحقیقاتی از دانشگاه‌ها به دنیای واقعی و صنعت است. متدولوژی پرومته هر آن چیزی را که برای تعریف و طراحی عامل‌ها مورد نیاز است ، فراهم نموده و دامنه‌ای از فعالیت‌ها شامل تعیین نیازمندی‌ها تا طراحی دقیق را پوشش می دهد.
متدولوژی پرومته شامل مفاهیم ذیل است:
• توصیفی از مفاهیم برای طراحی عامل‌ها
• یک فرآیند
• تعدادی نمادگذاری برای نمایش طرح‌ها
• نکات کاربردی یا تکنیک‌ها
اجازه دهید مجددا به تعاریف مطرح شده در بخش ۱ این نوشتار مراجعه داشته باشیم. در ابتدا تعریف عامل هوشمند را دوباره مرور می نمائیم. عامل هوشمند نرم‌افزاری است که دارای ویژگی‌های واقع شده ، خودمختار ، انفعالی ، پیش قدم ، انعطاف پذیر ، مستحکم و اجتماعی می‌باشد.
می‌دانیم که عامل‌ها در محیط واقع شده‌اند و عامل‌ها انفعالی و پیش قدم هستند. عامل پیش قدم عاملی است که اهداف را پیگیری می‌نماید. بنابراین اهداف ، یکی از مفاهیم کلیدی در طراحی عامل‌ها است.
عامل انفعالی ، عاملی است که به رویدادها پاسخ می‌دهد. رویدادها ممکن است ادراکاتی از محیط یا پیام‌هایی از سایر عامل‌ها و حتی رخدادهای داخلی باشند.
عنوان شد که عامل‌ها اجتماعی هستند. مفاهیم زیادی وجود دارند که می‌توانند برای تحقق بخشیدن به عامل‌های اجتماعی بکار روند. این مفاهیم عبارتند از : تعهدات ، هنجارها و تیم‌ها.
متدولوژی پرومته از سه مرحله تعیین سیستم ، طراحی معماری و طراحی دقیق تشکیل می‌شود.
۱) مرحله تعیین سیستم : در این مرحله ، سیستم بوسیله اهداف و سناریوهای مشخص شده ، واسطِ سیستم با محیط بر حسب اعمال ، ادراکات ، کارکردها و داده های خارجی توصیف می‌شوند.
۲) مرحله طراحی معماری : در این مرحله ، نوع عامل‌ها شناسایی شده و ساختار کلی سیستم بوسیله نمودار اجمالی سیستم مشخص و سناریوها به قراردادهای تعاملی بسط داده می‌شوند.
۳) مرحله طراحی دقیق : در این مرحله ، جزئیات درون هر عامل بر حسب قابلیت‌ها ،داده‌ها،رویدادها ، و برنامه‌ها تعریف و توسعه داده می شوند.نمودار فرآیند به عنوان یک جای پا بین قراردادهای تعاملی و برنامه‌ها بکار می‌رود.
هر یک از مراحل فوق شامل موارد ذیل می‌باشند:
• مدل‌هایی که بر روی پویایی سیستم تمرکز می کنند.
• مدل‌های گرافیکی که بر روی ساختار یا مولفه‌های سیستم تمرکز دارند.
• توصیف‌گرهای متنی که جزئیات موجودیت‌های منحصر بفرد را شرح می‌دهند.

۳-۱) مرحله تعیین سیستم
در این مرحله نیازمندی‌های سیستم بر حسب اهداف ، سناریوهای مورد کاربرد ، کارکردها و واسط سیستم با محیط تعریف می‌شود. با توجه به این مسئله که عامل‌ها پیش‌قدم و هدف‌دار هستند ، استفاده از اهداف سیستم برای توصیف نیازمندی‌ها الزامی است. اهداف یک سیستم ، یک نقطه شروع برای توسعه سناریوها هستند و در حالت برعکس ، توسعه سناریوها معمولا زیرهدف‌هایی پیشنهاد می‌کند که نیاز است تا مطرح شوند. با توضیحات ارائه شده می‌توان نتیجه گرفت که مرحله تعیین سیستم ، فرآیندی تکرار شونده است.
استفاده از اهداف با توجه به پیش قدم و هدف‌دار بودن عامل‌ها برای توصیف نیازمندی‌ها امری طبیعی است.فرآیند استخراج اهداف سیستم ، کار را با استخراج یک مجموعه اولیه اهداف از توصیفِ سطح بالای سیستم شروع می‌نماید. توصیف « ما مایل به توسعه سیستم زمانبندی گروهی هستیم که به کاربران اجازه می‌دهد جلسات خود را با دیگر کاربران ثبت نمایند» منجر به استخراج اهداف اولیه‌ای نظیر زمانبندی ، زمانبندی جلسات و مدیریت تقویم کاربران می‌شود. اهداف اولیه با در نظر گرفتن هر یک از اهداف و این که چگونه می‌توان به آن هدف دست یافت ، به مجموعه کامل‌تری از اهداف بسط داده می‌شود.به عنوان نمونه با پرسش این که چگونه زمان‌بندی جلسات محقق می‌شود؟ به این مسئله پی برده می‌شود که نیاز به یافتن یک زمان آزاد مشترک وجود دارد. این زیرهدف یک زیر هدف از هدفِ سطح بالای زمانبندی جلسات است.
در کنار شناسایی اهداف دیگر ، مجموعه اهداف جهت یافتن زیر هدف‌های مشترک بازبینی می‌شوند. هنگامی‌که در این مرحله دسته‌بندی اهداف بازبینی می‌شود ، شناسایی کارکردها نیز صورت می‌پذیرد. کارکردها ، تکه‌های منسجم از رفتارهای سیستم هستند.یک کارکرد شامل تعدادی هدف مرتبط به هم ، ادراکات مربوط به کارکرد مورد نظر ، اعمالی که اجرا می‌شود و داده‌های استفاده شده است. به بیان دیگر کارکرد را می‌توان به عنوان قابلیت‌هایی تصور نمود که سیستم به منظور دستیابی به اهداف طراحی ، نیاز دارد. کارکردهای سیستم به عنوان قابلیت‌های عامل‌های موجود در سیستم شناخته می‌شوند.
یک مجموعه اولیه از کارکرد با دسته‌بندی اهداف تعیین می‌شوند. سپس کارکردهای اولیه به عنوان نتیجه‌ای از در نظر گرفتن نوع عامل‌ها ، در مرحله طراحی معماری ، بازبینی و اصلاح می‌شوند. کارکردها با توصیف‌گرهای متنی توصیف می‌شوند. این توصیف‌گرها ، فرم‌های متنی هستند که اطلاعات ضروری را شامل می‌شوند. فرم توصیف‌گرِ یک کارکرد علاوه بر توصیف متنیِ خلاصه به زبان طبیعی ، شامل اهداف مرتبط به کارکرد ، اعمالی که ممکن است انجام شود ، ادراکات از محیط و یادداشت‌هایی در مورد اطلاعاتی که کارکرد مورد نظر استفاده یا تولید می‌نماید می‌باشد.
سناریوهای مورد کاربرد ، سومین جنبه از مرحله تعیین سیستم هستند. سناریوی مورد کاربرد ، یک شرح تفضیلی از یک مثال خاص از توالی رویدادهای مرتبط با دستیابی به یک هدف خاص یا مرتبط به پاسخ به یک رویداد خاص است.در نهایت ، محیطی که عامل در آن قرار می گیرد تعریف می شود. این کار با توصیف ادراکاتِ در دسترس سیستم، اعمالی که عامل قادر به انجام است و داده‌های خارجی قابل دسترس ، انجام می‌شود.
۳-۲ مرحله طراحی معماری
در این مرحله تمرکز بر روی موارد ذیل است:
• تصمیم گیری در مورد انواع عامل در سیستم : نوع عامل‌ها به وسیله دسته‌بندی کارکردها بر اساس میزان اتصال بین کارکردها تعیین می شود.هنگامیکه یک دسته‌بندی انتخاب می‌شود ، عامل‌های حاصل با توصیف‌گرهای عامل توصیف می‌شوند.
• توصیف تعاملات بین عامل‌ها با استفاده از نمودارهای تعاملی و قراردادهای تعاملی : نمودارهای تعاملی از سناریوهای مورد کاربرد استخراج شده و سپس بازبینی می‌شوند. نتیجه برای تولید قراردادهای تعاملی تعمیم داده می‌شوند.
• طراحی ساختار کلی سیستم: ساختار کلی سیستم با استفاده از نمودار اجمالی سیستم نمایش داده می‌شود. از نمودار اجمالی سیستم برای بدست آوردن نوع عامل‌ها ، مرزهای سیستم و واسط‌های سیستم برحسب اعمال و ادراکات و برحسب داده‌ها و کدهای خارج از سیستم استفاده می‌شود.
تعیین نوع عامل‌های موجود سیستم مهمترین فعالیتی است که در این مرحله وجود دارد.
در متدولوژی پرومته ، یک نوع ِعامل از ترکیب یک یا تعداد بیشتری کارکرد تشکیل شده است. نمودار اتصال داده‌ها یک ابزار مفید برای دسته‌بندی کارکردها است. در این نمودار هرکارکرد با یک مستطیل و هر مخزن داده با یک نماد داده نمایش داده می شود.
قدم بعدی در مرحله طراحی معماری ، کار بر روی تعاملات بین عامل‌ها با استفاده از نمودارهای تعاملی و قرارداد‌های تعاملی است.نمادگذاری‌های استفاده شده در نمودار‌های تعاملی یک نوع ساده شده از نمودار توالی UML است. برای بیان قراردادهای تعاملی از AUML استفاده می شود.
در نهایت معماری کلی سیستم با استفاده از نمودار اجمالی سیستم استخراج می شود.نمودار اجمالی سیستم یکی از مهمترین ابزارهای طراحی شده در متدولوژی پرومته است. نمودار اجمالی سیستم عامل‌ها ، ادراکات ، اعمال ، پیام‌ها و داده‌های خارجی را با استفاده از نماد‌های تصویر ۷ نمایش می‌دهد.
بردارهای جهت‌دار بین اشکال ، به پیام‌هایی که بین عامل‌ها رد‌و‌بدل می‌شوند ، اعمالی که عامل‌ها انجام می‌دهند ، ادراکاتی که عامل‌ها دریافت می‌کنند و داده‌هایی که عامل‌ها می خوانند یا می‌نویسند اشاره دارد.

۳-۳ مرحله طراحی دقیق
مرحله طراحی دقیق شامل موارد ذیل است:
• توسعه داخل عامل‌ها برحسب قابلیت‌ها که با استفاده از نمودارهای اجمالی سیستم و توصیف‌گرهای قابلیت انجام می‌شود.
• توسعه نمودارهای فرآیند با استفاده از قراردادهای تعاملی.
• توسعه جزئیات قابلیت‌ها برحسب دیگر قابلیت‌ها با استفاده از نمودارهای اجمالی قابلیت و توصیف‌گرهای مختلف.
ساختار هر عامل بوسیله نمودار اجمالی عامل نمایش داده می شود. نمادهایی که در این نمودار استفاده می شوند در تصویر ۸ نمایش داده شده است.
در مرحله طراحی معماری ، پویای سیستم با قرارداد‌های تعاملی توصیف می‌شود. در این مرحله ، نمودارهای فرآیند بر اساس قراردادهای تعاملی توسعه داده می‌شوند. نمودارهای فرآیند ، دیدگاه محلی برای هر عامل را نمایش می‌دهند. هر قرارداد تعاملی مطابق با دیدگاه عامل‌های مختلف ، نمودارهای فرآیند متعددی خواهد داشت. در این مرحله از یک توسعه از نمودار فعالیت UML برای نماد‌گذاری نمودارهای فرآیند استفاده می‌شود.نمادهای قابل استفاده در نمودارهای فرآیند را در تصویر ۹ مشاهده می‌نمائید.
در یک نگاه مراحل متدولوژی پرومته عبارتند از :
۱٫ System Specification
۱٫۱٫ Goal Overview Diagram
۱٫۲٫ Functionalities (Functionalities Diagram)
۱٫۳٫ Scenarios
۱٫۴٫ Percepts
۱٫۵٫ Actions
۱٫۶٫ Data
۲٫ Architectural Design
۲٫۱٫ System Overview Diagram
۲٫۲٫ Agents
۲٫۳٫ Percepts
۲٫۴٫ Actions
۲٫۵٫ Protocols
۲٫۶٫ Messages
۳٫ Detailed Design
۳٫۱٫ Agents
۳٫۱٫۱٫ Capabilities
۳٫۱٫۲٫ Processes
۳٫۱٫۳٫ External Messages
۳٫۱٫۴٫ Internal Messages
۳٫۱٫۵٫ Plans
۴ – بررسی موردی : کتاب‌فروشی الکترونیکی
در این قسمت به بررسی موردی نتایج متدولوژی پرومته برای یک کتاب فروشی بَرخط الکترونیکی می پردازیم.[۲۱] ۱٫ System Specification
۱٫۱٫ Goal Overview Diagram
۱٫۲ Functionalities
در این مرحله به عنوان نمونه توضیحات مربوط به مدیریت اجناس گمشده را ملاحظه می‌نمائید.
Functionality Lost goods management
Name Lost goods management
Description Manages queries about books that have not arrived. Does tracking and arranges duplicate books if needed.
Triggers Tracking info, No tracking response
Actions Request delivery tracking
Information used Delivery Problems
Information produced Delivery Problems, (Customer DB, Customer Orders)
Goals Log delivery problems, Delivery tracking, Log tracking information, Update delivery problem

گام بعدی ، سناریوها است. به عنوان نمونه سناریوی مربوط به سفارش کتاب را ملاحظه می نمائید.
۱٫۳ Scenarios
Scenario Order book
Name Order book
Description An order is received from the WWW page interface (goal Place order) Information is obtained in order to place the order and the order is placed.
Trigger Goal: Place order
Steps

Variation 1: Book is not currently available. Include information with delivery options. Replace steps 7-12 with steps to add the order to an orders pending file.
قدم بعدی تعیین و تشریح ادراکات است. به عنوان نمونه ادراک پاسخ تراکنش بانک را ملاحظه می نمائید.
۱٫۴ Percepts
Percept Bank transaction response
Name Bank transaction response
Description Response to request for credit card payment
Defined: Page nnn
هر ادراک تعیین شده در این بخش ، در مرحله دوم متدولوژی پرومته به صورت کامل‌تر تشریح می‌شود.
گام بعدی شناسایی فعالیت‌ها است. به عنوان نمونه فعالیت ردیابی درخواست ارسال را مشاهده می نمائید.
۱٫۵ Actions
Action Request delivery tracking
Name Request delivery tracking
Description send request to courier or postal service to track an item which has not
arrived.
Defined: Page nnn
هر فعالیت شناسایی شده در این بخش ، در مرحله دوم متدولوژی پرومته به صورت کامل‌تر تشریح می‌شود.
قدم بعدی شناسایی داده است. به عنوان نمونه توضیحات مربوط به پایگاه داده مشتریان را ملاحظه می‌نمائید.
۱٫۶ Data
Customer DB
contains information about customers, their profile, their history of visits to the site and orders, etc.

۲٫ Architectural Design
گام دوم این مرحله شناسایی عامل‌ها است. به عنوان نمونه توضیحات مربوط به عامل مدیریت تحویل را مشاهده می‌نمائید.
۲٫۲ Agents
Agent Delivery Manager
Name Delivery Manager
Description Arranges all aspects of delivery to customer. Deals with any problems with deliveries, including notifying customer relations agent of issues that affect customers.
Cardinality minimum 1
Cardinality maximum 1
Lifetime ongoing
Initialization
Demise Write out all internal data structures.
Percepts No tracking response, Tracking info
Actions Request delivery tracking, Place delivery request
Uses data Postal DB, Courier DB
Produces data Postal DB, Courier DB
Internal data Customer Orders
Goals Fill pending order, Obtain delivery options, Arrange delivery, Calculate delivery time estimates, Determine delivery status, Log outgoing delivery, Log delivery problems, Delivery tracking, Log tracking information, Update delivery problem
Functionalities Delivery handling, Lost goods management
Protocols Query late books protocol, Order status querying protocol, Stock arrival protocol, Stock delay protocol, Book ordering protocol

قدم سوم این مرحله ، تشریح تکمیل‌تر ادراکات لیست شده در بخش ۴٫۱ مرحله اول متدولوژی پرومته است. به عنوان مثال تشریح ادراک پاسخ تراکنش بانک را ملاحظه می‌نمائید.
۲٫۳ Percepts
Percept Bank transaction response
Name Bank transaction response
Description Response to request for credit card payment
Information carried Accept/Reject, fraud (optional), amount, account ID
Knowledge updated none
Source bank processing system
Processing none
Agents responding Sales Assistant
Expected frequency Individual agent unlikely to receive more than 1 in total. Certainly
no more than 1 every few minutes, maximum. System as a whole could potentially receive around 10 per minute maximum.
گام چهارم این مرحله ، شرح تکمیلی فعالیت‌های لیست شده در بخش ۵٫۱ می‌باشد. به عنوان نمونه شرح فعالیت ردیابی درخواست ارسال را مشاهده می نمائید.
۲٫۴ Actions
Action Place delivery request
Name Place delivery request
Description Send an email request for delivery pick-up, either by courier, or by the postal room.
Parameters email address (postal room, courier company, etc), delivery address, goods list
Duration Immediate (action to send request is immediate – results will take time)
Failure Mail may bounce. May also not be received without visible bounce.
Partial change None
Side effects None
قدم پنجم این مرحله شناسایی ، قراردادها است. به عنوان مثال قرارداد سفارش کتاب را مشاهده می‌نمائید.
۲٫۵ Protocols
Protocol Book ordering protocol
Name Book ordering protocol
Description Interactions as a result of customer placing an order.
Included messages Get delivery information message, Delivery options information, Book purchase, Book required, Not in stock, Book available, Book delivery information
Scenarios Order book
Agents Sales Assistant, Delivery Manager, Stock Manager, Customer Relations
Notes

گام ششم این مرحله ، شناسایی پیام‌ها می‌باشد. به عنوان نمونه پیام مربوط به محل قرارگیری‌ کتاب را مشاهده می‌نمائید.
۲٫۶ Messages
Message Book located
Name Book located
Description Message resulting from tracking of books that have not arrived.
Distribution Delivery Manager→ Customer Relations
Purpose To enable Customer Relations agent to tell customer that books have been located and should arrive shortly.
Carried information Date, Order ID, Customer ID
مرحله سوم متدولوژی پرومته ، مرحله طراحی دقیق است. در این مرحله عامل‌ها با جزئیات تشریح می‌شوند. به عنوان نمونه عامل مدیریت انبار را مشاهده می نمائید.

۲٫ Detailed Design
در گام دوم برای هر عامل ، قابلیت‌ها مشخص می‌شود. به عنوان نمونه برای عامل مدیریت انبار خواهیم داشت:
Name Stock managing
Description Ensures that stock levels are satisfactory, either by placing regular orders, or by placing immediate orders if stock runs out and the book is ordered.
Goals Order stock, Log books outgoing, Log books arriving
Processes
Protocols Stock arrival, Stock delay, Book ordering
Incoming messages Book required
Outgoing messages Stock arrival info, Stock arrival delayed, Book available, Not in stock
Internal messages
Percepts Stock order delay, Failed stock arrival, Stock arrival, Regular order trigger
Actions Email stock order
Data used: Imported Books DB
Data produced: Exported
Data internal Stock DB, Stock Orders, Pending Orders
Included plans
Included capabilities Delay handling, Ordering, Handling new stock
Notes
سایر قابلیت‌های عامل مدیریت انبار عبارتند از :
• Capability Ordering
• Capability Handling new stock
• Capability Delay handling
• Capability Cataloging
• Capability Managing competition
• Capability Pricing

قدم دوم ، تعیین فرآیندهای هر عامل است. به عنوان نمونه فرآیند نگهداری انبار را در عامل مدیریت انبار مشاهده می‌نمائید.
Name Stock maintenance
description The activity whereby there is an attempt to maintain sufficient stock to immediately fill orders. The activity is responsive to immediate demands as well as maintaining stock levels from month to month.
Triggers Book required, Monthly timer
Activities Check Stock DB, Immediate order, Add to monthly order, Produce order list.
Messages ,
Protocols Order book protocol, Stock Arrival Protocol, Query Late Order
Capabilities Stock Management.
Notes
گام سوم ، شناسایی پیام‌های خارجی هستند.به عنوان مثال پیام درخواست کتاب را مشاهده می نمائید.
۳٫۱٫۳ External Messages
Message Book required
Defined Page 166
Description Book ID required for delivery to customer.
Additional fields:
Coverage and overlap Full coverage, no overlap
Information carried: fields and value types/ranges:

سایرپیام‌های خارجی عامل مدیریت انبار عبارتند از :
• Message Book available
• Message Not in stock
• Message Stock arrival info
• Message Stock arrival delayed
• Message Book query message
• Message Book query response message

قدم چهارم برای عامل مدیریت انبار ، پیام های داخلی می‌باشد.
۳٫۱٫۴ Internal Messages
Message Temporary reduction
Name Temporary reduction
Description Message to temporarily reduce a book price
Distribution Managing competition → Pricing
Purpose To temporarily reduce a book price due to a lower price elsewhere.
Information carried New price, Book ID
Coverage and overlap Full coverage, no overlap
سایرپیام‌های داخلی عامل مدیریت انبار عبارتند از :
• Message Remove reduction
• Message Stock low
• Message No stock
• Message Get number required
• Message Decide supplier
• Message Modify monthly order

گام پنجم ، طرح‌های یک عامل می‌باشد. به عنوان نمونه طرح مربوط به بررسی موجودی انبار را به همراه شبه‌کد مشاهده می‌نمائید.
Plan Check stock
Name Check stock
Description Determines whether book required is available in stock.none
Trigger
Context none
Incoming messages
Outgoing messages
Percepts
Actions
Used data
Produced data
Goal
Failure can’t read file
Failure recovery email system support
Procedure:
Access stock record for book ID (from message)
If stock number > 0
send reply «Book available»
Else
Send reply «not in stock»
Post message «No stock»
If reorder threshold exists
If stock number -1 < reorder threshold post message stock low endif Else if stock number -1 > standard reorder threshold
Post message stock low
endif
سایر طرح‌های عامل مدیریت انبار عبارتند از :
• Plan Respond book query
• Plan Add to order
• Plan Out of stock response
• Plan Get number by index
• Plan get number by price
• Plan get number by sale
• Plan Decide supplier by time
• Plan Decide supplier by price
• Plan Add to supplier order
• Plan Delete items
• Plan Build monthly orders

گام‌های پنجگانه شرح داده شده فوق برای عامل‌های Sales Assistant ، Delivery Manager و Customer Relations انجام می‌شود.

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

دیدگاهتان را ثبت کنید

آدرس ایمیل شما منتشر نخواهد شدعلامتدارها لازمند *

*

x

شاید بپسندید

افکت‌های انیمیشنی بر روی منوها

افکت‌های انیمیشنی بر روی منوها

از CSS برای ساخت انواع افکت و …   استفاده کنید ،بدون آن ...