دانلود پایان نامه ارشد درباره عاملهای هوشمند، مدل پیشنهادی، دانش سازمانی

دانلود پایان نامه ارشد

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

شکل ‏326 ساختار عامل ترسیمگر وضعیت موردانتظار

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

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

شکل ‏327 بخش اول از کلاس دیاگرام چارچوب پیشنهادی

در ابتدا سه کلاس فرعی مطابق شکل ‏327 تعریف شدهاند که توسط سایر کلاسها که در واقع عاملهای هوشمند چارچوب پیشنهادی میباشند، مورداستفاده قرار خواهند گرفت. از این میان کلاس AgentAction خصوصیات و رفتار یک رویداد قابل اجرا توسط عاملها را کپسوله میکند، کلاس AgentMemory بیانگر ویژگیها و عملگرهای حافظهی درونی هر عامل است. این کلاس دارای یک حافظهی درونی است که در واقع محلی برای ذخیرهسازی دانش درونی اکتسابی آن عامل است (در واقع یک پایگاه دانش میباشد). از وهلههای اشیای ایجاد شده از روی کلاس AgentMessage نیز به عنوان ابزاری جهت ارتباط میان عاملها استفاده میشود.

شکل ‏328 کلاس Intelligent Agent

کلاس بعدی با نام Intelligent Agent یک کلاس انتزاعی یا Abstract است (بدین معنا که قابل Instantiation نمیباشد) که عملیات و صفات مشترک در میان تمامی عاملهای هوشمند را در خود داراست. سایر عاملهای هوشمند از این کلاس ارثبری مینمایند، به بیان دیگر یک رابطهی Generalization بین این کلاس و کلاسهای پیادهسازی کننده سایر عاملهای هوشمند در معماری چارچوب پیشنهادی برقرار است. امکانات کلی موردنیاز تمامی عاملها از قبیل متدهای ارتباطی و مکانیزمهای مشترک تصمیمگیری میتوانند در این کلاس قرار گیرند. همانگونه که در شکل ‏328 مشخص است، بیشتر متدهای این کلاس از نوع محافظت شده یا Protected میباشند، بدین معنا که تنها توسط کلاسهای فرزند این کلاس قابل دسترسی میباشند و نمیتوان از محیط خارج بدانها دسترسی داشته و آنها را اجرا نمود که این به دلیل ماهیت خودمختار عامل هوشمند است و اجازهی دخالت مستقیم عامل خارجی در تصمیمات درونی عامل مستقل خودمختار را سلب خواهد نمود.
برای عامل هوشمند انطباق دهنده رسالت و چشمانداز، کلاسی با نام Mission and Vision Adaptor درنظر گرفته شده است (شکل ‏329) که این عامل هوشمند در چارچوب پیشنهادی را پیادهسازی میکند.

شکل ‏329 کلاس Mission and Vission Adaptor

در این کلاس، عمل بررسی عملیات موردنظر سایر عاملها به منظور تأیید صحت و سازگاری آنها با رسالت و چشمانداز سازمان صورت میپذیرد. همانگونه که مشاهده میشود، بیشتر متدهای این کلاس به صورت خصوصی یا Private میباشند، بدان معنا که دسترسی به آنها تنها در درون همان کلاس امکانپذیر میباشد. با اینحال یکی از متدها با نام AllowExecuteAction که مجاز بودن یا نبودن اجرای یک عملیات موردنظر را تعیین میکند، به صورت عمومی یا Public تعریف شده و دلیل این امر نیز آن است که این متد بایست توسط سایر عاملهای هوشمند قابلیت اجرا داشته باشد. همین قابلیت اجرا توسط سایر عاملهای هوشمند نوعی وابستگی میان این عامل و سایر عاملها ایجاد مینماید که به شکل نماد dependency در نمودار UML موردنظر ما نمایش داده خواهد شد. پس بین این کلاس و تمامی کلاسهای دیگر مدل (به جز کلاس مراقب PESTEL) رابطهی dependency برقرار است (اما به دلیل بزرگی ابعاد دیاگرام در اینجا کل دیاگرام به صورت یکجا و با تمامی عاملهای آن، قابل ترسیم نمیباشد).

شکل ‏330 کلاس PESTEL Watcher

برای عامل مراقب PESTEL نیز وضع به همین منوال است. در اینجا نیز کلاسی با نام PESTEL WATCHER ایجاد شده که از کلاس Intelligent Agent ارثبری نموده و متدهای خاص خود را داراست و وظیفهی این متدها همانگونه که از نام کلاس مشخص است، رصد عوامل مختلف سیاسی، اقتصادی، اجتماعی، تکنولوژیکی، محیطی، قانونی و بررسی میزان تأثیر آنها در نیل به وضعیت موردانتظار سازمان است. مشابه کلاس قبلی، میان این کلاس و تمامی کلاسهای دیگر مدل (به جز کلاس انطباق دهنده رسالت و چشمانداز) رابطهی dependency برقرار است.
متناظر با سایر عاملهای چارچوب پیشنهادی نیز، کلاسهای موردنیاز در دیاگرام مربوطه ترسیم شدهاند که به ترتیب در شکل ‏331 کلاس مربوط به عامل تحلیلگر بازار، در شکل ‏332 کلاس مربوط به عامل ناظر محصولات و خدمات، در شکل ‏333 کلاس مربوط به عامل ناظر مالی، در شکل ‏334 کلاس مربوط به عامل تحلیلگر ذینفعان، در شکل ‏335 کلاس مربوط به عامل تنظیمکننده منابع انسانی و در شکل ‏336 کلاس متناظر با عامل ترسیمگر وضعیت موردانتظار را ملاحظه میکنید. از آنجایی که ترسیم تمامی عاملها در کنار هم و نمایش روابط میان آنها به صورت یکجا با کیفیت بالا امکانپذیر نمیباشد (گرچه در شکل ‏337 شمای کلی این نمودار کلاس را ملاحظه میکنید)، به ذکر این نکته در مورد روابط بین عاملها در کلاس دیاگرام موردنظر بسنده میکنیم که به صورت کلی، روابط یک طرفه در چارچوب پیشنهادی (شکل ‏33) به صورت رابطهی dependency و روابط دوطرفه به صورت aggregation در کلاس دیاگرام موردنظر ترسیم شدهاند، به علاوه آن رابطه generalization میان تمامی کلاسهای متناظر با عاملها و کلاس Intelligent Agent برقرار است.

شکل ‏331 کلاس Market Analyzer

شکل ‏332 کلاس Product and Services Supervisor

شکل ‏333 کلاس Financial Supervisor

شکل ‏334 کلاس Stakeholder Analyzer

شکل ‏335 کلاس Human Resource Regulator

شکل ‏336 کلاس Desired Situation Designer

شکل ‏337 کلاس دیاگرام کلی چارچوب پیشنهادی

به دلیل وضوع اسامی متدهای هر کلاس، از توضیح بیشتر در این خصوص اجتناب میکنیم. ضمنا توجه به این نکته ضروری به نظر میرسد که ویژگیها و متدهای ذکرشده در بالا برای کلاسهای متناظر با عاملهای هوشمند چارچوب پیشنهادی، تنها گوشهای از ضروریترین و بدیهیترین موارد میباشد و مسلما برای پیادهسازی واقعی کلاسها، احتمالا به تعداد بیشتری متد و ویژگی نیاز خواهیم داشت که بیان تکتک آنها در اینجا لزومیندارد.
آخرین نکتهای که پیش از پایان این فصل بدان اشاره میکنیم، توضیح مختصری در مورد کدهایی است که چه از روی نمودار UML تشریح شده و چه به صورت دستی در هر زبان برنامهنویسی شیئگرا قابل ایجاد است. گرچه برای انجام کامل پیادهسازی اکیدا استفاده از یک زبان برنامهسازی سطح بالا مانند جاوا توصیه میشود. در ادامه تنها کدهای ایجاد شده به زبان جاوا برای دو کلاس Intelligent Agent و Desired Situation Designer ذکر شدهاند:

public abstract class IntelligentAgent {
protected String name;
protected Memory memory;

public String getName()
{
return name;
}

protected void initializeAgent()
{
//TO-DO
}

protected void ModifyBehavioralRules()
{
//TO-DO
}

protected void ExecuteAction(AgentAction action)
{
//TO-DO
}

protected void SendMessageToAnotherAgent(IntelligentAgent agent, AgentMessage message)
{
//TO-DO
}

protected void ReceiveMessageFromAnotherAgent()
{
//TO-DO
}

}
شکل ‏338 کد کلاس IntelligentAgent به زبان جاوا

همانطور که در شکل ‏338 ملاحظه میکنید، این یک کلاس abstract جاوا با متدهای عمدتا محافظت شده است که سایر کلاسهای موردنظر از قبیل DesiredSituationDesigner که در ادامه کد آن را مشاهده میکنید، از آن به عنوان کلاس والد ارثبری نموده و از امکانات آن پس

پایان نامه
Previous Entries دانلود پایان نامه ارشد درباره نیروی انسانی، تحقیق و توسعه، وضعیت مالی Next Entries دانلود پایان نامه ارشد درباره تحلیل داده