گزارش سمینار بررسی تلفیق مفاهیم جنبه گرایی و معماری سرویس گرا

گزارش  سمینار کارشناسی  ارشد

 رشته  مهندسی  کامپیوتر گرایش  نرم  افزار

چکیده 

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

فصل  اول

تعریف  مساله

۱-۱- مقدمه

یکی از بزرگترین  دشواریها در راستای دستیابی به  سرویس  گرایی جداسازی نیازهای سرویس  از نیازهای برنامه  کاربردی است . درحالیکه  سرویس ها تنها باید با دغدغه  وظیفه مندی حرفه ای که  ارائه  میکنند، مواجه  باشند اما گاها ویژگیهای وابسته  به  برنامه  در لایه  سرویس  "نشت " میکنند. با به  کارگیری مفاهیم  ارائه  شده  در  جنبه  گرایی،  اکنون  معماران  میتوانند  از  نشت  دغدغه های  متداخل  در  سرویسهایی  که  طراحی میکنند، جلوگیری کنند.

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

۱-۲- اهمیت  قابلیت  استفاده  مجدد

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

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

۱-۳- چالشهای نظری

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

جنبه ها  در  پیاده سازیهای  معمول  با  مشکلات  قابلیت  مشاهده ١٢ مواجه  هستند.  جنبه ها  میتوانند  در سراسر یک  برنامه  کاربردی مستقر شوند. در بسیاری از موارد نمیتوان  با مشاهده  کد تشخیص  داد که  آیا جنبه ها در روند اجرایی برنامه  حضور دارند یا نه .

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

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

می شوند. به عبارت  دیگر، فضای  نیازمندی ها یک  فضای  چند بعدی  است ، در صورتی  که  فضای  پیاده سازی یک  بعدی  است . چنین  عدم  تطابقی  باعث  یک  نگاشت  نامناسب  بین  پیاده سازی  و نیازمندی ها می شود.

در صورتی  که  از روش های  متداول  کنونی  استفاده کنیم  چند عارضه  ممکن  است  در پیاده سازی  چنین 

دغدغه های  متداخلی  پیش بیاید. می توان این  مشکلات  را به  طور کلی  به  دو دسته  تقسیم  کرد:

١)  در هم  پیچیدگی  کد: ماژول های  مختلف  برنامه  ممکن  است  به  طور هم زمان  با چندین  نیازمندی  سروکار داشته باشند. مث ًلا اغلب  برنامه نویسان  هم زمان درباره ی  منطق  کاری ، کارایی ، هم زمانی ، ثبت  وقایع ، و امنیت  فکر می کنند. تجمع  همه ی این  نیازمندی ها باعث  می شود در هر بخش  از برنامه  قسمتی  از هر کدام  از این  دغدغه ها پیاده سازی  شوند که  باعث  در هم  پیچیدگی  کد می شود.

٢)   پراکندگی  کد:  چون  دغدغه های  متداخل ،  طبق  تعریف ،  بین ماژول های  مختلف  پخش  هستند، پیاده سازی  مربوط  به  آنها نیز بین  این  ماژول ها پراکنده است . مث ًلا در یک  سیستم  که  از یک  پایگاه  داده  استفاده  می کند، دغدغه ی کارایی  ممکن  است  روی  تمامی  ماژول هایی  که  به  پایگاه داده  دسترسی  دارند تأثیر بگذارد.

برای  اینکه  برنامه نویسان  با دغدغه های  متداخل به  صورت  ماژول شده  سروکار داشته باشند، راه  حل هایی  با دامنه ی  محدود  مانند  چارچوب ها١٤ و سرویس دهنده های  برنامه  کاربردی ١٥ وجود  دارد.  مث ًلا  معماری JavaBeans Enterprise دغدغه های  متداخلی  مانند امنیت ، سرپرستی ، کارایی  و ماندگارکردن  داده ها را برعهده می گیرد. برنامه  نویسان  روی  منطق  کاری  تمرکز می کنند و مسئولان  جای گذاری  روی  مسائل مربوط  به  جای گذاری ،  مانند  نگاشت  داده های  اشیاء  بر  روی  پایگاه داده ،  کار  می کنند.  در  این  صورت  برنامه نویس  دیگر لازم  نیست  به  مشکلات  مربوط  به  ماندگاری  داده ها توجه کند. در این  روش  دغدغه ی  ذخیره ی  داده ها در پایگاه داده ، در یک  واصف  مبتنی  بر XML پیاده سازی  می شود.

فصل  دوم

معرفی مفهوم  جنبه گرایی و نقش  آن  در توسعه  نرم افزار

۲-۱- مقدمه

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

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

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

نتایج  مثبت  حاصل  از تحقیقات  در حوزه  برنامه نویسی جنبه گرا در سالهای اخیر، ایده  استفاده  از جنبه - گرایی در کل  فرآیند توسعه  نرم افزار را تقویت  کرده  است . یکی از فازهایی که  تکنیکهای "توسعه  نرم افزار جنبه گرا" (AOSD) در آن  قابل  اعمال  است ، قسمت  مربوط  به  طراحی می باشد و این  مساله  میتواند طراحی سیستمهای پیچیده  را ساده تر کند و ضمنا هزینه  توسعه ، نگهداری، استفاده  مجدد و ... را کاهش  دهد. طبیعت  متنوع  جنبه هایی که  یک  برنامه  میتواند شامل  آنها باشد و نیازمندیهای متفاوتی که  برنامه - های کاربردی در جهت  هدایت  جنبه ها اعمال  میکنند، مدیریت  یکپارچه  جنبه ها را به  صورتی که  سادگی فرآیند طراحی نیز حفظ  شود، دشوار میکند. شاید ارائه  راهکارهایی در سطح  معماری راهگشا باشد. روش  جدید برنامه نویسی  جنبه گرا١٩ (AOP) باعث  می شود که  تقسیم بندی  بخش های  مختلف  برنامه  به  نحوی  ساده  شود که  برطرف  کردن  دغدغه ها باعث  پیچیدگی  زیادی  نشود. این  کار باعث  راحت تر شدن  طراحی ، فهم ، و نگهداری  سیستم  خواهد شد. علاوه  بر این ، AOP باعث  تولید محصولاتی  با بهره وری  بالاتر، کیفیت  بهتر، و امکان  اضافه  کردن  قابلیت های  بیشتری  می شود.

برنامه نویسی  جنبه گرا بهتر از روش های  متداول  قبلی  دغدغه ها را از ماژول های  سیستم  جدا می کند. به  همین  دلیل  بهتر می توان  از تداخل  دغدغه ها جلوگیری  کرد.

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