گزارش سمینار بررسی روش های شناسایی سرویس های نرم افزاری

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

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

چکیده 

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

با مطالعه سیر تکاملی روش های تولید و توسعه نرم افزار، می توان به دغدغه های موجود در این زمینه پی برد. دغدغه های اصلی در زمینه تولید و توسعه نرم افزار عبارتند از: پیچیدگی نرم افزار، هزینه تولید نرم افزار، زمان تولید نرم افزار و ... . برای رفع این مشکلات با استفاده از ایده ICهای سخت افزاری روش های جدیدی مطرح شدند. از جمله این روش ها می توان استفاده از مولفه های نرم افزاری (component)، و روش های سرویس گرا را نام برد.  

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

فصل اول – تعریف هدف 

مقدمه 

برای توسعه نرم افزارها در سطح یک سازمان، به منظور جلوگیری از بروز پیچیدگی، نیاز به انتخاب سطح تجرید مناسب است. یکی از روش های موجود برای این کار استفاده از سرویس ها و معماری سرویس گرا است. به طور کل می توان گفت معماری سرویس گرا رهیافتی است برای ساخت سیستم های توزیع شده که نیازمندی های نرم افزاری را به صورت سرویس ارائه می کند. این سرویس ها هم توسط دیگر نرم افزارها قابل فراخوانی هستند و هم برای ساخت سرویس های جدید مورد استفاده قرار می گیرند.[6] بررسی تاریخچه توسعه مبتنی بر شی گرایی (OO) و توسعه برپایه مولفه (CBD) می تواند در درک نحوه گسترش معماری سرویس گرا در برابر توسعه مبتنی بر سرویس کمک کند. همانگونه که روش های شی گرا در ابتدا با زبان های برنامه نویسی شی گرا معرفی شدند و سپس با ارائه روش های مدلسازی، تحلیل و طراحی  شی گرا (OOAD) به بلوغ رسیدند، در دنیای سرویس گرایی نیز مفاهیم سرویس، ابزارها و روش های مدلسازی و طراحی مبتنی بر سرویس منجر به پیدایش معماری سرویس گرا شدند. [7]  

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

1.1 تعریف معماری سرویس گرا 

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

برای معماری سرویس گرا تعاریف متنوع و بعضا مختلفی ارائه شده که هر کدام از نگاهی به تبین خصوصیات آن پرداخته اند که با بررسی کلی  آنها می توان موارد زیر را به عنوان فصل مشترک این تعاریف استنباط کرد

هم راستای کسب و کار سازمان است. 

هم موضوعی فنی است و هم نوعی سبک تفکر است. 

مبتنی بر اتصال سست است و از پیام رسانی استفاده می کند. 

قادر به ساخت سیستم های ترکیبی است. 

مهمترین دستاورد آن انعطاف پذیری و چابکی فناوری اطلاعات در برابر تغییرات حرفه است. 

منجر به تعامل پذیری سامانه ها/سازمانها می گردد. 

امکان ارائه یک سرویس با واسطه های متنوع را محقق می سازد. 

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

به طور کل معماری سرویس گرا مجموعه ای از قواعد، الگوها و معیارها در حیطه تولید و توسعه نرم افزار و فرآیندهای سازمان است که باعث حصول واحدمندی(modularity)، قابلیت استفاده مجدد(reusability)، مستقل از سکو بودن(platform independent) و ارتباط سست(loose coupling) در محصول می گردد.

2.1 بیان چرخه حیات معماری سرویس گرا 

بر اساس طرح IBM برای معماری سرویس گرا می توان یک چرخه حیات در نظر گرفت. در شکل 1 این چرخه نشان داده شده است[9]:

(نمودار و تصاویر در فایل اصلی موجود است)

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

همانطور که در شکل شماره 1 نشان داده شده است، اولین گام در چرخه حیات معماری گام مدلسازی می باشد. در این گام سرویس های مورد نیاز برای پاسخگویی به نیازهای حرفه تعیین شده و ویژگی های اصلی آنها مشخص می شود. به عبارت دیگر در این گام دو فعالیت اصلی انجام می شوند: 1. تشخیص سرویس ها (service identification) و 2. تعیین ویژگی های سرویس ها (service specification) و 3. عینیت بخشی به سرویس ها (service realization) 

در ادامه برای آشنایی بیشتر با فرآیند تولید سیستم های نرم افزاری با استفاده از روش معماری سرویس گرا، به بیان فازهای پایه ای در معماری سرویس گرا می پردازیم. 

3.1 فازهای پایه ای SOA  

اصولا فازهای اصلی برای توسعه پروژه های مبتنی بر سرویس گرایی همانند فازهای متداول در توسعه پروژه های مبتنی بر روش های پیشین برای تولید سیستم های توزیع شده هستند. فازهای اصلی در سرویس گرایی در شکل زیر نشان داده شده اند

(نمودار و تصاویر در فایل اصلی موجود است)

در شکل فوق دو فاز ابتدایی (service-oriented analysis , service-oriented design ) مسئول تطابق رهیافت در دست ساخت با ویژگی های شمرده شده برای سرویس گرایی هستند. در این دو فاز ایتدایی سرویس ها شناسایی شده و از میان مجموعه سرویس های کاندید، سرویس هایی که وارد مرحله توسعه سرویس ها می گردند تعیین می شوند. به مجموعه این فعالیت ها شناسایی سرویس ها (service

  [1].می گویند (identification

1.3.1 تحلیل سرویس گرا 

اهداف اصلی از تحلیل سرویس گرا عبارتند از[1]: 

مشخص کردن مجموعه اصلی عملیات کاندید سرویس ها

گروه بندی عملیات کاندید در بسته های منطقی. این بسته ها نشان دهنده سرویس های کاندید هستند.

مشخص کردن مرزهای اصلی سرویس های کاندید به منظور جلوگیری از بروز رویهم افتادگی سرویس ها

مشخص کردن درصد قابلیت استفاده مجدد برای هر بسته منطقی

حصول اطمینان از وجود تناسب بین بسته های منطقی و کارکرد مورد انتظار آنها

تعیین تمامی مدل های ترکیبی ممکن مراحل تحلیل سرویس گرا عبارتند از: 

مرحله 1- تعیین نیازمندی های [خودکارسازی] حرفه: با توجه به اینکه نیازمندی های حرفه (که به منظور پوشش آنها دست به طراحی و توسعه سیستم ها می زنیم) جمع آوری شده اند، مستندات موجود در این زمینه به عنوان گام آغازین در فرآیند تحلیل سرویس گرا استفاده می شوند. در این روش تنها نیازمندی های مرتبط با رهیافت سرویس گرا ( آنچه می خواهیم برایش راه حل سرویس گرا ارائه کنیم) در نظر گرفته می شوند.

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

مرحله 3- مدلسازی سرویس های کاندید: پس از اینکه واحدهای کاری شناسایی شد و این واحدها در غالب منطق های عملیاتی (سرویس ها) بسته بندی گردید، این بسته ها به صورت سرویس های کاندید در آمده و به منظور نمایش یک مدل ابتدایی از ترکیب سرویس ها به منظور پیاده سازی سیستم مورد نظر استفاده می گردند.

2.3.1 طراحی سرویس گرا 

در ادامه 12 مرحله به عنوان فرآیند مدلسازی سرویس ها مشخص می گردند.[1] 

مرحله 1- تجزیه فرآیندهای حرفه  

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

مرحله 2- تعیین عملیات کاندید سرویس های حرفه

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

مرحله 3- تعیین هم نواسازی (orchestration)

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