مهندسی نرم افزار عامل گرا
مقدمه
در بخش مربوط به کیس (computer aided software engineering) دانستیم یکی از ابزار های کمک کننده در فرآیند تولید نرم افزار هوش مصنوعی است زیرا با توجه به اینکه در مهندسی نرم افزار به کمک رایانه ، می خواهیم توسط یک نرم افزار ، کار مهندس نرم افزار را تقلید کنیم عملا ایجاد این نرم افزار ها در حوزه هوش مصنوعی قرار می گیرد
حال می خواهیم بگوییم حتی می توانیم دیدگاه عامل گرا داشته باشیم. در حقیقت مهندسی نرم افزار عامل گرا توسعه یافته و بست مهندسی نرم افزار شی گرا است
تعریف عامل :
واژه عامل یک سطح انتزاع از نرم افزار را بیان می کند مثل همان مفاهیم شی و توابع. به صورت غیر رسمی می توان گفت عامل علاوه بر داشتن ویژگی های یک شی توانایی انجام کار هایی را با درجه ای از خود مختاری به منظور به انجام رساندن آن کار به جای کاربرش را دارد. یک شی ، که با یک سری method ها و attribute ها تعریف می شود اما یک عامل با رفتارش !!
یک تعریف دیگر از عامل : عامل چیزی است که می تواند برای یا به جای کسی عمل کند
یک عامل به عنوان هر چیزی که می تواند بوسیله ی حسگرهایش محیط اطرافش را درک کرده و عمل خاصی را انجام دهد و حتی محیط را تحت تاثیر خود قرار دهد تعریف می شود .
مثال هایی از عامل نرم افزاری
1- آیتم انیمیشنی موجود در مایکروسافت office
2- ویروس های کامپیوتری ( عاملهای مخرب )
3- بازیکن های مصنوعی در بازی های کامپیوتری
عنکبوت های وب ( مثل google.com
مهندسی نرم افزار عامل گرا:
هدف اصلی مهندسی نرم افزار عامل گرا ساختن متدلوژی ها و ابزار هایی است تا توسعه و نگهداری نرم افزار های عامل به صورت ارزان ممکن شود.. به اضافه ی اینکه نرم افزار حاصل انعطاف پذیر بوده و کار کردن با آن ساده و آسان باشد و در ضمن از کیفیت و کارایی بالایی هم برخوردار با شد .
وجه تمایز عامل و شی
1- یک شی یک ترکیب منطقی از ساختمان داده ها و متد های مربوطه هست و عامل ها می توانند یک جانشین ممکن برای شی باشند.عامل ها با اشیاء شبیه هستند اما عامل ها از ساختار هایی برای پشتیبانی از مولفه های ذهنی مثل باور ها و تعهد ها پشتیبانی می کنند.
2- تفاوت مهم دیگر بین عامل و شی این است که اشیاء از بیرون کنترل می شوند.در مقابل عامل ها می توانند درجه ای از خودمختاری را داشته باشند. به طوریکه ممکن است به طور مستقیم از بیرون نتوانیم آن را کنترل کنیم. به عبارت دیگر عامل این حق را دارد که بگوید نه !!
متدلوژی های سطح بالا
در این قسمت متدلوژی هایی را توضیح می دهیم که از روش بالا به پایین و تکراری برای مدل کردن و گسترش سیستم های عامل گرا استفاده می کند
Wooldridage و Jennings و Kinny1 اشخاصی بودند که متدلوژی حاضر را در مورد تجزیه و تحلیل سیستم های عامل گرا بیان داشتند.
متدلوژی Gaia
متدلوژی Gaia یک متدلوژی عامل گرا برای آنالیز و طراحی است
اولین قدم در پروسه آنالیز گایا پیدا کردن نقش ها در سیستم است و قدم دوم مدل کردن واکنش متقابل بین نقش های پیدا شده است.هر نقش 4 صفت دارد : مسئولیت پذیری ، مجوز ها ، فعالیت ها و پروتکل ها.
نقش باید چیز خوبی را به سیستم اضافه کند و مسئولیت ها از اتفاق افتادن یک چیز بد جلوگیری می کنند.مجوز ها تعیین می کنند که چه نقشی اجازه چه کاری را دارد . به طور دقیق تر به چه اطلاعاتی دسترسی دارد و فعالیت ها وظایفی هستند که یک نقش بدون داشتن کنش متقابل با سایر نقش ها انجام می دهد.پروتکل ها الگوی اصلی کنش ها هستند
متدلوژی مهندسی نرم افزار چند عامله
Wood2 و3 deloach اولین کسانی بودند که متدلوژی سیستمهای چند عاملی را پیشنهاد کردند.
متدلوژی مهندسی نرم افزار چند عامله شبیه gaia هست اما این متدلوژی توجه بیشتر به پشتیبانی برای تولید کد اتوماتیک به وسیله ابزار هایی MaSE دارد. هدف MaSE این بود که طراح را از مراحل اولیه تعریف سیستم تا پیاده سازی سیستم عامل گرا هدایت کند.
متدلوژی MaSE به هفت فاز در یک خط لوله منطقی تقسیم شده.
مرحله ی اول ) جمع آوری اهداف .
برای این منظور باید مشخصات لازم برای ایجاد سیستم اولیه تعیین شده و در طی یک ساختار سلسله مراتبی به سیستم نهایی تبدیل شود. این کار به وسیله تعریف اهداف بر مبنای نیازمندی های مشخص سیستم اولیه و سپس مرتب سازی اهداف بر اساس اهمیت شان صورت می گیرد.
مرحله ی دوم ) تعیین موارد کاربرد
.مورد کاربرد ها نشان دهنده واکنش متقابل منطقی نقش های مختلف خود سیستم با یکدیگر است. برای حداقل سازی تعداد پیام هایی که باید بین سیستم ها رد و بدل شود ، دیاگرام ترتیب به کار برده می شود .
فاز سوم )پالایش نقش ها
این مرحله نقشهایی را به وجود می آورد که پاسخگوی اهداف تعیین شده در فاز اول خواهند بود. معمولا هر هدف توسط یک نقش نمایش داده می شود اما ممکن است یک مجموعه از اهداف مرتبط به یک نقش داده شوند . نقشها با همدیگر مجموعه ایی از وظایف را به وجود می آورند. این وظایف میتوانند چگونگی رسیدن به اهداف مربوط به هر نقش را بیان کنند. وظایف به وسیله نمودار وضعیت تعریف می شوند.
فاز چهارم )ایجاد کلاس های عامل
نقش ها را به کلاس های عامل تبدیل می کنیم.
این دیاگرام ها شبیه دیاگرام های کلاسهای شیء می باشند اما معنای روابط آنها در سطح های بالا مخالف دیاگرام های کلاسهای اشیاء و ساختار وراثتی که بین آنها وجود دارد می باشد .
فاز پنجم ) ایجاد یک گفتگو
تعریف یک پروتکل هماهنگ به فرم نمودارهای حالت برای بیان وضعیت هر گفتگو در تاثیر متقابل عامل ها
فاز ششم ) اسمبل کردن کلاسهای عامل
یعنی توابع و وظایف داخل کلاسهای عامل در این مرحله ایجاد می شوند . توابع و کاربردهای تعریف شده برگرفته از 5 معماری متفاوت برای عاملها است .واکنش پذیری ، طرح ریزی ، مبنی بر دانش و معماری تعریف کاربر
فاز هفتم )طراحی سیستم
ایجاد یک نمونه ی واقعی از عامل بر اساس کلاسهای عامل صورت می گیرد. نتیجه ی نهایی در یک نمودار گسترش نمایش داده می شود .
بینش های آینده برای MASE ایجاد کد کاملا اتوماتیک را براساس نمودار گسترش فراهم می آورد .
UML
زبان مدلسازی جهانی، اساسا این زبان به صورت نمایش ترسیمی ایجاد شده و توسعه داده شده است تا اشیاء را به صورت استاندارد طراحی کند . اما این زبان بعدا بسیار گسترده شد به وسیله پشتیبانی که از مراحل طراحی مولفه ها انجام می داد و غیره .
. YIM یک معماری مرکز گرا را برای طراحی سیستم ها ی چند عاملی پیشنهاد کرد .
متدلوژی OCL Object Constraints Language
این متدلوژی بر اساس گسترش استاندارد UML به وسیله Object Constraints Language (OCL) , که تبدیل مسائل را از عامل گرا به شی گرا انجام می دهد.در مرحله تبدیل ، ارتباطات بین عامل ها به الگوی های طراحی تیدیل می شوند.این الگوها بعدا به عنوان ارتباطات بین کلاس ها ی اشیاء به کار گرفته می شوند. به طور دقیق تر به انواع ارتباطات معمول بین کلاس ها به کار گرفته می شود مثل ارث بری.
نتیجه ی این روش ایجاد یکسری از روشهایی می باشد که تولید کنند گان را قادر می سازد که به وسیله ی ابزارهایUML به اضافه ی دانش و تجربه ، سیستمهای مورد نظر خود را بسط و گسترش دهند .
تاریخچه مهندسی نرم افزار
مهندسی نرم افزار پیشه ای است که به یاری دانش رایانه و دیگر فناوری ها و روش ها به آفریدن و نگاهداری نرم افزار رایانه ای می پردازد.
مسائل اصلی مهندسی نرم افزار تولید نرم افزار بر اساس موارد زیر است:
* الزامات تعیین شده
* در زمان تعیین شده
* در محدودهٔ بودجه پیش بینی شده
مهندسی نرم افزار طراحی، برنامه نویسی، توسعه، مستندسازی و نگهداری نرم افزار با بکارگرفتن روشهای فنی و عملی از علوم کامپیوتر ، مدیریت پروزه ، مهندسی ، محدوده کاربرد، طراحی رابط، مدیریت تجهیزات دیجیتال و سایر زمینه ها است.
کاربردهای مهندسی نرم افزار دارای ارزش های اجتماعی و اقتصادی هستند، زیرا بهره وری مردم را بالا برده، چند و چون زندگی آنان را بهتر می کنند. مردم با بهره گیری از نرم افزار، توانایی انجام کارهایی را دارند که قبل از آن برایشان شدنی نبود. نمونه های از این دست نرم افزارها عبارت اند از: سامانه های توکار، نرم افزار اداری، بازی های رایانه ای، و اینترنت.
فناوری ها و خدمات مهندسی نرم افزار به کاربران برای بهبود بهره وری و کیفیت یاری میرساند. نمونه هایی از زمینه های بهبود: پایگاه داده ها، زبان ها، کتابخانه ها، الگوها، فرآیندها و ابزار.
پیشینه مهندسی نرم افزار
اصطلاح مهندسی نرم افزار بعد از سال ۱۹۶۸ شناخته شد. این اصطلاح طی کنفرانس "مهندسی نرم افزار ناتو ۱۹۶۸" (که در گارمیش آلمان برگزار شد) توسط ریاست کنفرانس F.L. Bauer معرفی شد و از آن پس بطور گسترده مورد استفاده قرار گرفت.
اصطلاح مهندسی نرم افزار عموماً به معانی مختلفی به کار می رود:
* به عنوان یک اصطلاح غیر رسمی امروزی برای محدوده وسیع فعالیت هایی که قبلا برنامه نویسی و تحلیل سیستم ها نامیده میشد.
* به عنوان یک اصطلاح جامع برای تمامی جنبه های عملی برنامه نویسی کامپیوتر، در مقابل تئوری برنامه نویسی کامپیوتر، که علوم کامپیوتر نامیده می شود.
* به عنوان اصطلاح مجسم کننده طرفداری از یک رویکرد خاص نسبت به برنامه نویسی کامپیوتر که اصرار می کند، مهندسی نرم افزار، بجای انکه هنر یا مهارت باشد، باید به عنوان یک رشته عملی مهندسی تلقی شود و از جمع کردن و تدوین روش های عملی توصیه شده به شکل متدولوژی های مهندسی نرم افزار طرفداری می کند.
* مهندسی نرم افزار عبارتست از : الف) کاربرد یک رویکرد سیستماتیک، انتظام یافته، قابل سنجش نسبت به توسعه، عملکرد و نگهداری نرم افزار، که کاربرد مهندسی در نرم افزار است و ب) مطالعه روشهای موجود در استاندارد IEEE
محدوده مهندسی نرم افزار و تمرکز آن
مهندسی نرم افزار به مفهوم توسعه و بازبینی یک سیستم نرم افزاری مربوط می باشد. این رشته علمی با شناسایی، تعریف، فهمیدن و بازبینی خصوصیات مورد نیاز نرم افزار حاصل سر و کار دارد. این خصوصیات نرم افزاری ممکن است شامل: پاسخگویی به نیازها، اطمینان پذیری، قابلیت نگهداری، در دسترس بودن، آزمون پذیری، استفاده آسان، قابلیت حمل و سایر خصوصیات باشد.
مهندسی نرم افزار ضمن اشاره به خصوصیات فوق، مشخصات معین طراحی و فنی ای را آماده می کند که اگر بدرستی پیاده سازی شود، نرم افزاری را تولید خواهد کرد که می تواند بررسی شود که آیا این نیازمندی ها را تامین می کند یا خیر.
مهندسی نرم افزار همچنین با خصوصیات پروسه توسعه نرم افزاری در ارتباط است. در این رابطه، با خصوصیاتی مانند هزینه توسعه نرم افزار، طول مدت توسعه نرم افزار و ریسک های توسعه نرم افزار درگیر است.
نیاز به مهندسی نرم افزار
نرم افزار عموماً از محصولات و موقعیتهایی شناخته می شود که قابلیت اطمینان زیادی از آن انتظار میرود، حتی در شرایط طاقت فرسا، مانند نظارت و کنترل نیروگاههای انرژِی هسته ای، یا هدایت یک هواپیمای مسافربری در هوا، چنین برنامه هایی شامل هزاران خط کد هستند، که از نظر پیچیدگی با پیچیده ترین ماشینهای مدرن قابل مقایسه اند. به عنوان مثال یک هواپیمای مسافربری چند میلیون قطعه فیزیکی دارد (و یک شاتل فضایی خدود ده میلیون بخش دارد)، در حالی که نرم افزار هدایت چنین هواپیمایی میتواند تا ۴ میلیون خط کد داشته باشد.
تکنولوژی ها و روشهای عملی
مهندسین نرم افزار طرفدار تکنولوژی ها و روشهای عملی بسیار متفاوت و مختلفی هستند، که با هم ناسازگارند. این بحث در سالهای دهه ۶۰ میلادی شروع شد و ممکن است برای همیشه ادامه پیدا کند. مهندسین نرم افزار از تکنولوژی ها و روشهای عملی بسیار متنوعی استفاده می کنند. کسانی که کار عملی می کنند از تکنولوژی های متنوعی استفاده می کنند : کامپایلرها، منابع کد، پردازشگرهای متن. کسانی که کار عملی می کنند از روشهای عملی بسیار متنوعی استفاده می کنند تا تلاشهایشان را اجرا و هماهنگ کنند : برنامه نویسی در دسته های دونفری، بازبینی کد، و جلسات روزانه. هدف هر مهندس نرم افزار بایستی رسیدن به ایده های جدید خارج از مدلهای طراحی شده قبلی باشد، که باید شفاف بوده و بخوبی مستند شده باشد.
با وجود رشد فزاینده اقتصادی و قابلیت تولید فزاینده ای که توسط نرم افزار ایجاد شده ، هنوز هم بحث و جدل های ماندگار درباره کیفیت نرم افزار ادامه دارند.
ماهیت مهندسی نرم افزار
دیوید پارناس گفته است که مهندسی نرم افزار یک شکل از مهندسی است. استیو مک کانل گفته است که هنوز اینطور نیست، ولی مهندسی نرم افزار باید یک شکل از مهندسی بشود. دونالد کنوت گفته است که برنامه نویسی یک هنر است.
دیوان فعالیتهای آماری آمریکا مهندسان نرم افزار را به عنوان زیرگروهی از "متخصصین کامپیوتر"، با فرصت های شغلی ای مانند "دانشمند کامپیوتر"، "برنامه نویس" و "مدیر شبکه" دسته بندی کرده است. BLS تمام مهندسین دیگر این شاخه علمی، که شامل مهندسین سخت افزار کامپیوتر نیز هست، را به عنوان "مهندسین" دسته بندی می کند.
مهندسی نرم افزار مبتنی بر مولفه :
برخی اوقات COP (Component Oriented Programming ) و CBSE (Component Based Software Engineering ) در نوشتار با همدیگر اشتباه گرفته می شوند . هر چند که CBSE یک مفهوم کلی است در صورتیکه COP فقط یه عنوان قسمتی از CBSE به کار برده می شود.
CBSE= COA+COD+COP+COM
* COA : Component Oriented Analysis
* COD : Component Oriented Design
* COP : Component Oriented Programming
* COM : Component Oriented Management
COA ، COD ، COM به ترتیب نشان دهنده تحلیل مبتنی بر مولفه ، طراحی مبتنی بر مولفه و مدیریت مبتنی بر مولفه می باشند . CBSE ، به تسریع کردن توسعه نرم افزار و کاهش دادن هزینه سیستم با ترکیب نمودن مولفه های نرم افزاری از پیش ساخته شده تاکید دارد . طراحی ، توسعه و نگهداری مولفه ها ، برای استفاده مجدد فرآیند پیچیده ای است . CBSE شیوه های مهندسی نرم افزار و تکنیکهای مختلف نرم افزار را پوشش می دهد چه از نظر عملی و چه از دیدگاه تئوریک که هنوز هم به طور کامل تعریف و توسعه نیافته اند.
در مهندسی نرم افزار سنتی فرآیند توسعه نرم افزار در برگیرنده فعالیتها یا مراحل متوالی بود که عبارتنـد از : تحلیل ، طراحی ، برنامه نویسی ، تست و مجتمع سازی ( یکپارچه سازی ) . در CBSE ، مراحل اصلی توسعه ، تحلیل ، تولید و آماده سازی و اسمبل کردن می باشند. که در برنامه نویسی سنتی فعالیتهای تست و مجتمع سازی ( یکپارچه سازی ) جایگزین فعالیتهای تولید و آماده سازی مولفه و اسمبل کردن مولفه در CBSE شده است .
دو نوع اصلی از فعالیتها در CBSE وجود دارند :
* DF ( Developing For reuse) : توسعه برای استفاده مجدد.
* DW ( Developing Withr reuse) : توسعه با استفاده مجدد.
برای DF ، فعالیت توسعه می تواند با دنبال نمودن رویکردها یا دیدگاههای مهندسی نرم افزار سنتی تاکید بر استانداردهای مولفه ای سازماندهی گردد. برای نمونه هر مولفه ارائه کننده در برگیرنده دو نوع واسط می باشد :
1. واسط تامیین کننده : که خدمات ارائه شده توسط مولفه را تعریف می کند.
2. واسط مورد نیاز (ضروری ): که مشخص می کند سیستم استفاده کننده از مولفه ، چه خدماتی را باید ارائه کند.
اگر این واسطها مهیا نشوند ،مولفه کار نخواهد کرد . برای DW ، جستجو و بازیابی مولفه نرم افزار ، فعالیتهای تعیین کننده ای برای ساختن برنامه کاربردی دارند.
از دیدگاه فرآیند مهندسی نرم افزار ، مولفه ها می توانند به 5 فرم مختلف طبقه بندی شوند ( یعنی مولفه در طی گذراندن 5 مرحله حاصل می شود ):
1. مشخصه (ویژگی ) مولفه : این فرم مشخصه (ویژگی ) یک واحد نرم افزاری را ارائه میکند که رفتار مجموعه ای از اشیا مولفه ای را توصیف می کند و یک واحد پیاده سازی را تعریف می کند. رفتار به عنوان یک مجموعه از واسطها تعریف می شود مشخصات مولفه نهایتا در غالب پیاده سازی مولفه خواهد بود.
2. واسط مولفه : فرم واسط تعریفی از مجموعه رفتارهای مولفه را ارائه می کند که می توانند توسط اشیا مولفه ای ارائه شوند.
3. پیاده سازی مولفه : پیاده سازی مـولفه شکـلی از مـشخصه (ویژگی ) مولفه می باشد. این بدین معنی است که می توانند به طور مستقل جایگزین دیگر مولفه ها شده و نصب گردد. آن بدین معنی نیست که مولفه مستقل از دیگر مولفه هاست .بلکه ممکن است وابستگیهای زیادی داشته باشد.
4. مولفه نصب شده : فرم نصب شده که یک نسخه نصب شده یا توسعه یافته از پیاده سازی مولفه می باشد کـه با مستقر کـردن آن در مـحیط اجـرایی تـوسعـه می یابد.استقرار مولفه در محیط اجرائیش ، محیط اجرایی را قادر به شناسایی مولفه نصب شده برای استفاده از آن می کند .
5. شی مولفه ای : نمونه ای از مولفه نصب شده می باشد . مشابه OOP یک شی مولفه در COP یک شی با داده ها و مـشخصات ( ویـژگیها ی) منحصر به فرد می باشد ، که رفتار پیاده سازی شده را اجرا می کند یک مولفه نصب شده ممکن است چند شی مولفـه ای داشته باشد کـه نیازمـند ویـژگیهای صـریح و روشن می باشد.
سیستمهای چند عامله (Multi Agent Systems )
بسیاری از سیستم های تجاری اولیه عامل را برای هدف جستجو مورد استفاده قرار دادند . در این سیستم ها عاملهای منفرد به مراکز معینی متصل می شدند ، اطلاعات لازم را جمع آوری می کردند و در نهایت به نزد کاربر درخواست کننده بر می گشتند. به عبارت دیگر عاملها یک کار انفرادی داشتند و در مقیاس بسیار کمی – اگر بود – با عاملهای دیگر تعامل داشتند. این روش باوجودیکه کاربردهای زیاد خاص خود را دارد نمی تواند به تنهایی یک اجتماع یا یک سازمان ایجاد کند که بتواند نیازهای دیگر کاربران را برآورده سازد . در عوض در محیط های انسانی ما یک شبکه از افراد را داریم که برای منظورهای مختلف با یکدیگر در تعامل می باشند. بدین ترتیب برای ایجاد یک جامعه از عاملها نه تنها نیاز است که بین آنها ارتباط برقرار کرد بلکه عاملها باید بتوانند با یکدیگر هماهنگ هم باشند. این هماهنگی می تواند جنبه های مختلف همکاری و یا رقابتی داشته باشد. این جوامع، سیستمهای چند عامله (MAS) نامیده می شوند.
به عبارت دیگر "یک سیستم چند عامله یک پیاده سازی با تاکید بر همکاری از برنامه ها (عاملها) است که با یکدیگر هماهنگ شده اند برای رسیدن به همگرایی روی پاسخ یک یا چند وظیفه"
سیستم های چند عامله، سیستم هایی هستند که از جمع شدن عاملهای هماهنگ شده با هم و روابط بین آنها تشکیل شده اند. در این سیستم هر کس وظیفه خود را می داند و می داند که چه زمانی با دیگری باید ارتباط برقرار کند.
برخی دلایل منطقی وجودی سیستم های چند عامله عبارتند از:
– یک عامل می تواند همه چیز را بسازد اما عاملهای چاق (!) باعث بروز نارسایی هایی در سرعت ، قابلیت اطمینان ، قابلیت نگهداری و نظایر آن می شوند. (به عبارت دیگر عامل همه کاره وجود ندارد.) تقسیم کارکرد ها بین عاملهای مختلف مزایای واحدبندی شدن ، قابلیت انعطاف ، قابلیت تغییرپذیری و قابلیت توسعه را فراهم می سازد.
– دانش های تخصصی اغلب از یک عامل بدست نمی آیند (به عبارت دیگر عامل عالم مطلق وجود ندارد ) دانشی که در بین منابع (عاملهای) مختلف گسترده شده است می تواند در هنگام نیاز در یک دیدگاه بسیار کاملتر جمع گردد.
– کاربردهایی که به محاسبات توزیع شده نیاز دارند بهتر توسط MAS حمایت می شوند. در اینجا عاملها می توانند به صورت مولفه های خودمختار ریز شده ای طراحی شوند که به صورت موازی عمل می کنند. پردازش همزمان و حل مساله می تواند برای بسیاری از مسائل که تاکنون به صورت خطی حل می شدند راه حل های مناسب تری ارائه کند. بدین ترتیب فن آوری عاملها نهایی ترین حد را در فن آوری مولفه های توزیع شده فراهم می سازد.
– MAS برای کاربردهایی که ذات توزیع شده و غیر همگن دارند مانند تجارت الکترونیک و نظایر آن مناسب ترین گزینه است. در این گونه محیط ها , عاملها می توانند مستقل از یکدیگر و توسط توسعه دهندگان مختلف طراحی و تولید شوند و با وضع قوانین تعامل با یکدیگر هماهنگ گردند واهداف طراحی را برآورده سازند.
منابع :
http://fa.wikipedia.org/wiki/
http://weblog.radmanitd.com/archives/cat_oeuoeoeuuoeu_uuoeuuoe.html
http://saeedv.persiangig.ir/aose/aose.doc
—————
————————————————————
—————
————————————————————
23