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

بخشی از مقاله

چکیده

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

واژههای کلیدی: عاملهای هوشمند، برنامه نویسی جنبه گرا، آزمون پویا، زمان اجرا، عامل ناظر، مهاجرت عاملها.

مقدمه

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

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

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

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

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

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

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

عاملهای هوشمند

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

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

تا کنون زبانهای مختلفی جهت پیادهسازی عاملهای مبتنی بر هدف تهیه شده است. برخی از این زبانها به صورت اعلانی5  بوده    مانند CLAIM، FLUX، KABUL، DALI و ... و برخی به صورت    امری6 هستند مانند JAL و برخی به صورت ترکیبی از هر دو رویکرد استفاده میکنند مانند 3APL، Jason، IMPACT و .GO همچنین محیطهای توسعه مختلفی مانند 3APL IDE، Jason، JDE، CAFnE، VisualSoar، Agent Builder، Agent Factory و ... معرفی شدهاند. علاوه بر آن، چهارچوبها7 و بسترهای مختلفی جهت توسعه عاملها با استفاده از زبانهای مطرح شده بوجود آمدهاند که از آن جمله میتوان به TuCSoN، جید، Jadex و DESIRE اشاره کرد.[7] به عنوان مثال جید یکی از بهترین سکوهای نرمافزاری است که تا کنون برای توسعه عاملهای هوشمند در زبان جاوا طراحی شده است و میتوان با استفاده از جاوا به راحتی در آن عاملهای مختلف تعریف کرده و وظایفی به آنها محول کرد.

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

نخ مربوط به برنامههای عامل، مادامی که وضعیت عامل در حالت فعال است، دائم اجرا شده و منتظر اهدافی است که به عامل محول شود تا آنها را انجام دهد. اهداف توسط رفتارهایی9 به عامل معرفی میشود. نخ مربوط به هر عامل طبق شکل 1 رفتار میکند. در ابتدا که نخ راه اندازی میشود، رفتارهای اولیهای به لیست آن اضافه میشود که جهت کنترل عامل از پیش تعریف شده است. سپس نخ عامل بررسی میکند که آیا بایستی به کار خود خاتمه داده و پاک شود؟ چنانچه پاسخ مثبت بود، عملیات پاکسازی را انجام داده و نخ تخریب میشود. اعمالی که در شکل 1 به صورت انگلیسی نوشته شده است، نام توابعی است که جید استفاده میکند و کاربر میتواند روال این توابع را بازنویسی10 کند و تعاریف جدید از خود به آنها اضافه کند. چنانچه نیاز به تخریب نخ نباشد، از صف رفتارهای عامل، یک رفتار انتخاب شده و تابع انجام عملیات آن رفتار فراخوانی میشود.

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

در این حالت نخ عامل بیکار بوده و بیهوده منابع نگهدارنده را هدر میدهد به همین علت ممکن است عامل معلق شود تا کار جدیدی پیدا شود و عامل دیگری آن را از حالت تعلیق خارج کرده و رفتاری به آن محول کند. در وضعیتی که فعال است بررسی میکند چنانچه هدفی برای آن تعریف شده باشد، آن هدف را دنبال کرده و تا لحظه رسیدن به آن، تلاش میکند.[8] با توجه به توضیحات بیان شده، چرخه حیات هر عامل در شکل 2 نشان داده شده است.[9] یک عامل توسط منبعی میتواند ایجاد و یا نابود شود که این منبع میتواند به دستور رفتار یک عامل دیگر و یا فردی باشد که دسترسی به محیط کنترل عاملها دارد. به محض ایجاد یک عامل، وضعیت آن در حالت آغازی قرار میگیرد که با احضار شدن آن توسط محیط کنترل عاملها شروع به فعالیت کرده و در وضعیت فعال قرار میگیرد. حال چندین حالت ممکن است برای عامل رخ دهد:

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

-2 همچنین یک عامل میتواند به دلیل عملیاتهای مختلف مانند ورودی و خروجی یا ارتباط با عاملهای دیگر، به حالت انتظار رفته و منتظر