پایان نامه ارائه راهکاری به منظور بهبود متدولوژی های مبتنی بر معماری سرویسگرا

تعداد صفحات: 116 فرمت فایل: word کد فایل: 10001993
سال: 1388 مقطع: مشخص نشده دسته بندی: پایان نامه مهندسی کامپیوتر
قیمت قدیم:۱۸,۲۰۰ تومان
قیمت: ۱۶,۱۰۰ تومان
دانلود فایل
  • خلاصه
  • فهرست و منابع
  • خلاصه پایان نامه ارائه راهکاری به منظور بهبود متدولوژی های مبتنی بر معماری سرویسگرا

    پایان نامه کارشناسی ارشد (M.Sc.)   رشته مهندسی کامپیوتر- گرایش نرم افزار  

    چکیده 

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

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

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

    مدل دید معماری پیشنهادی از یک دید مرکزی (مثلث مرکزی) و 3 دید جانبی (مثلثهای مجاور) تشکیل شده است. دید مورد کسب و کار نقش کلیدی را در این مدل داراست و در مرکز مثلث قرار       می گیرد. دیدهای مدل سرویس، مؤلفه سرویس و سرویس اسمبلی دیدهای جانبی هستند و مثلثهای کناری را تشکیل می دهند. سعی شده است دیدها به نحوی درنظر گرفته شوند که بتوانند تمام چرخه حیات یک راه حل سرویس گرا را پوشش دهند و علاوه بر خصوصیاتی که یک مدل دید معماری باید داشته باشد بتوانند در سطح کاربردی نیز مفید باشند. یعنی مدل دید ارائه شده صرفاً یک مدل نظری محض نباشند بلکه در چارچوب یک متدولوژی سرویس گرا مانند SOMA قابل پیاده سازی باشد. در مدل دید معماری پیشنهادی، دیدهای اختصاصی برای اعضای تیم توسعه نیز معین گردیده است. این مدل، برخلاف مدلهای دید معماری سرویس گرای موجود می تواند در سطح سازمان نیز مورد استفاده قرار گیرد.  

     

    کلمات کلیدی: متدولوژی، معماری سرویس گرا، متدولوژی های سرویس گرا، مدل دید معماری

    فصل اوّل: 

    طرح مسأله 

    1-1 مقدمه 

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

    با توجه به توضیحات فوق برای تعریف دقیق روش[1] خواهیم داشت: 

    فرآیندی منظم که با استفاده از مجموعه ای از نمادگذاریهای خوش تعریف مجموعه ای از مدلها را ایجاد می کند که هر کدام بخشی از سیستم نرم افزاری در دست تولید (یا توسعه) را توصیف می کند [3]. 

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

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

    عموماً اصول مهندسی که در نرم افزار بکار می بندیم در ویژگیهای متدولوژی نهفته است برای اینکه: 

    الف) متدولوژی خودتعریف است و مفاهیم بنیادین و اصولی خود را تعریف می کند. 

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

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

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

    ه) پیچیدگی سیستم های نرم افزاری روز به روز در حال افزایش است و تولیدکنندگان در مواجهه با آن ناکام بوده اند بنابر این باید تدبیری اندیشیده می شد تا امکان غلبه بر این بحران فراهم می گردید.   متدولوژی این نقیصه را با ابزارهایی جهت کنترل پیچیدگی و رهیافتی  برای پیاده سازی آسانتر مهیا کرد. 

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

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

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

    » وقتی سرویس گرائی با معماری در کنار هم قرار می گیرد معنائی فنی پیدا می کند. معماریسرویس گرا اصطلاحی است برای نشان دادن مدلی که در آن منطق خودکارسازی به واحدهای کوچکتر(واحدهای مشخص دارای منطق کسب و کار) تجزیه می شود. این واحدها با یکدیگر بخش بزرگتری ازمنطق اتوماسیون   کسب و کار را تشکیل  می دهند و هر یک از آنها می توانند جداگانه توزیع شوند.« [5]  معماری سرویس گرا به عنوان یک نمونه از سبکهای معماری مطرح است[6]. این معماری دارای تمرکز بر روی سه عنصر اصلی است که شامل: سرویس، پیام و توصیفات سرویسها می شود. برای تحلیل یک سیستم بر پایه معماری سرویس گرا به یک متدولوژی نیاز است و در چنین متدولوژیهائی، سرویس نقش اساسی ایفاء می کند. مدل سرویس، مدلی است که بیشتر رفتارهای ایستا و پویای سیستم مبتنی بر معماری سرویس را منعکس می کند. 

     

    1-2 تعریف مسأله 

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

    در مورد مشکل مطرح شده منباب مثال آقایErl  در [5] می نویسد: 

    » . . . در حالیکه بر روی پروژه مبتنی بر معماری سرویس گرا کار می کنیم، معمار فکر می کند آن پروژه سرویس گراست، توسعه دهندگان اصرار دارند که شیءگراست و تحلیلگران امیدوارند که پروژه حرفه گرا باشد . . . . «  

    یا آقای Mantell در [7] می نویسد: 

    تحلیلگر، SOA را مجموعه ای از سرویسها می داند که کسب و کار، خواستار نمایاندن این سرویسها به مشتریان، شرکاء یا بخشهای دیگر سازمان است. معمار فناوری اطلاعات آن را  یک سبک معمارانه می داند که نیازمند فراهم کننده سرویس، تقاضادهنده و توصیف سرویس است و SOA را مجموعه ای از اصول معمارانه، الگوها و ملاکهائی می داند که مشخصات و ویژگیهائی از جمله واحدبندی، محصورسازی،اتصال سست، تجزیه وابستگیها، استفاده مجدد و قابلیت ترکیب را آدرس دهی می کند. از سوی دیگرتوسعه دهنده سیستم نرم افزاری، آن را یک مدل برنامه نویسی می داند که با استانداردها، ابزارها وتکنولوژیهائی مانند وب سرویسها کامل می شود و SOA را راه حل میان افزار بهینه شده برای تجمیع سرویس اسمبلی، همنواسازی[4]  و نظارت[5] مدیریت می داند. 

    در این تحقیق قصد ما ارائه یک مدل دید معماری برای پوشش این خلأ مهم در متدولوژیهای مبتنی بر معماری سرویس گراست که موجب بهبود  این متدولوژیها خواهد شد. 

     

    1-3 محدوده تحقیق 

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

     

    1-4 ساختار پایان نامه 

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

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

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

    فصل د وم: 

    ادبیات تحقیق 

    2-1 معماری نرم افزار 

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

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

    Abstract:

     Service-Oriented Architecture is an instance of software architecture style which is a bridge between business and Information Technology. This architecture has some principles which are the piers of this bridge. In order to apply these principles during analysis, design and implementation of serviceoriented solutions, a service-oriented methodology should be executed step-bystep for creating the required artifacts.

     Many service-oriented methodologies have been introduced up to now but they have not been able to implement all service-oriented principles. These methodologies have faced insufficiency of models and approaches in document and artifacts management, creation of proper viewpoints for the members of development team, controlling the complexity, facilitation in common understanding of the problems and their solution and many other cases. One of the most important models that assist each methodology in responding the similar cases is architectural view model. 

     Service-oriented methodologies need this model to compensate for the insufficiencies. Some architectural view models have been introduced for service-oriented architecture. These models also have many insufficiencies such that there are few scientific documents for some of them. In this study, we have tried to offer an architectural view model based on service-oriented architecture that makes the service-oriented methodologies more integrated and efficient. Triangular architectural view is a model suggested for service-oriented architecture which will take effective steps for solving the mentioned problems with its 4 views. 

     The suggested architectural view model consists of a central view (central triangle) and three side views (adjacent triangles). The business use-case view has the key role in this model and is in the center of the triangle. The views of service model, service component and service assembly are the side views and constitute the adjacent triangles. It has been tried to consider the views such that they can cover the whole life-cycle of a service-oriented solution and it can be useful in application level beside the characteristics that an architectural view model should have. That is, the proposal view model is not a pure theoretical method and it can be implemented in the framework of a service-oriented methodology like SOMA.

     Specific views have been determined for the members of development team in the suggested architectural view model. Unlike the available serviceoriented architectural view models, this model can be used in the enterpriselevel applications.

     

    Keywords: Methodology, Service-Oriented Architecture, Service-Oriented Methodologies, Architectural View Model. 

  • فهرست و منابع پایان نامه ارائه راهکاری به منظور بهبود متدولوژی های مبتنی بر معماری سرویسگرا

    فهرست:

    چکیده

    فصل اول: طرح مسأله

    1- 1 مقدمه                                                                                                     3

    1- 2 تعریف مسأله                                                                                            5

    1- 3 محدوده تحقیق                                                                                          6

    4 ساختار پایان نامه    6

    فصل دوم: ادبیات تحقیق                                                                                     8

    1 معماری نرم افزار  9

    2- 2 سبک در معماری نرم افزار                                                                           10

    2- 3 معماری سرویس گرا و معرفی اصول آن                                                            11

    2- 4 متدولوژیهای توسعه نرم افزار                                                                         16

    2- 5 تعامل بین متدولوژی و معماری نرم افزار                                                           17

    2- 6 مدل دید معماری: فصل مشترک متدولوژی و معماری نرم افزار                                  18

    2- 7 معرفی چند مدل دید معماری                                                                        20

    20   (Kruchten’s view model) 4+1 مدل دید 1-7 -2

    2- 7-2 مدل توصیف صفات اختصاصی معماری نرم افزار (Margaret’s Architecture)     22

    2- 7-3 مدل معماری نرم افزار در کاربردهای صنعتی (Soni’s architecture)                   23

    8 نتیجه گیری          24

    فصل سوم: متدولوژیها و مدلهای دید معماری مبتنی بر معماری سرویس گرا                      25

    1 مقدمه       26

    3- 2 معرفی متدولوژیهای مبتنی بر معماری سرویس گرا                                                26

    3- 2-1 تحلیل و طراحی سرویس گرا (SOAD)                                                       26

    3- 2-2 معماری و مدلسازی سرویس گرا (SOMA)                                                  26

    و

    3- 2-3 متدولوژی کیفیت تکرارپذیر سرویس گرا (SOA RQ Methodology)                27

    27   (The Service Oriented Process) فرآیند سرویس گرا 4-2 -3

    3- 2-5 چارچوب معماری سرویس گرا (SOAF)                                                     27

    3- 2-6 فرآیند یکپارچه سرویس گرا (SOUP)                                                         28

    3- 2-7 متدولوژی طراحی و توسعه سرویس گرا                                                         28

    3- 2-8 متدولوژی Erl                                                                                      28

    3- 2-9 نماد مدلسازی فرآیند کسب و کار به زبان اجرائی فرآیند کسب و کار                       29

    3- 2-10 متدولوژی برای معماریهای سرویس                                                            29

    3- 3 معرفی SOMA                                                                                      30

    3- 3-1 چشم انداز حرکت به سوی راه حلهای سرویس گرا                                            30

    3- 3-2 ابزار حمایتی Rational برای SOA                                                           34

    (Rational Method Composer) سازنده روش 3-3 -3

    RUP SOMA 4-3 -3

    3- 3-4-1 شناسائی سرویسهای کاندیدا و جریانها                                                       39

    3- 3-4-2 تجزیه دامنه                                                                                      39

    3- 3-4-3 مدلسازی سرویس هدف                                                                       42

    3- 3-4-4 تحلیل دارائیهای موجود                                                                         43

    3- 3-5 مشخصه سازی سرویس ها، مؤلفه ها و جریانها                                                   44

    3- 3-6 عینیت بخشی سرویسها                                                                            49

    3- 3-7 RUP SOMA- تعریف فراساختار سرویس                                                  50

    3- 4 نقاط قوت و ضعف متدولوژیهای مبتنی بر معماری سرویس گرا                                 52

    3- 5 معرفی مدلهای دید معماری مبتنی بر معماری سرویس گرا                                        54

    3- 6 نتیجه گیری                                                                                             59

    فصل چهارم: راهکار پیشنهادی به منظور بهبود متدولوژیهای مبتنی بر معماری سرویس گرا     61

    4- 1 نمای کلی مدل دید معماری پیشنهادی                                                              62

    ز

    4- 2 دید مورد کاربری کسب و کار                                                                       64

    4- 3 دید مدل سرویس                                                                                      67

    4- 4 دید مؤلفه سرویس                                                                                     69

    4- 5 دید سرویس اسمبلی                                                                                  71

    4- 6 نتیجه گیری                                                                                             74

    فصل پنجم: مطالعه موردی                                                                                 76

    5- 1 مقدمه                                                                                                   77

    5- 2 مطالعه موردی: شرکت فروشگاه های زنجیره ای رفاه                                              77

    5- 3 تحلیل و مقایسه                                                                                        90

    فصل ششم: نتیجه گیری و کارهای آینده                                                                94

    6- 1 نتیجه گیری و جمع بندی نهائی                                                                      95

    6- 2 ارزیابی پارامترهای مدل پیشنهادی                                                                   96

    6- 3 کارهای آینده                                                                                           98

    منابع                                                                                                           99

     

    منبع:

    1.            براآنی، احمد، . . . (و دیگران)، 1384، مرجع کاربردی متدولوژی RUP برای تولید و توسعه سیستمهای نرم افزاری، انتشارات دانشگاه اصفهان. 

     

    2.            پرسمن، راجر اس.، سالخورده حقیقی، محمدمهدی، 1386، مهندسی نرم افزار، ویرایش پنجم، انتشارات خراسان.   

     

    3.            شمس علیئی، فریدون، 1385، جزوه آموزشی مهندسی نرم افزار پیشرفته. 

     

    4.            هاشمیان، حسین، 1385، سبکهای معماری نرم افزار، گزارش سمینار کارشناسی ارشد دانشگاه آزاد اسلامی واحد علوم و تحقیقات تهران. 

     

    5.            Erl, Thomas, 2005, Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall PTR.

     

    6.            Fielding, R.T., 2000, Ph.D. dissertation: Architectural Styles and The Design of Network based Software Architectures, University of California, Irvine.

     

    7.            Mantell, Keith, 2008, SOMA, RUP and RMC: the right combination for Service Oriented Architecture, IBM® WebSphere® User Group, Bedfont. 

     

    8.            Garlan, D., Shaw, M., 1994, An introduction to Software Architecture, Technical Report, CMU/SEI-94-TR-21.

     

    9.            Bloomberg, J., 2003, the role of service-oriented architect, The Rational Edge.

     

    10.        Ibrahim, D., Misic, V. B., 2006, Service Views: a Coherent View Model of the SOA in the Enterprise, IEEE International Conference on Services Computing (SCC'06), IEEE Press.

     

    11.        Kruchten, P., 1995, Architectural Blueprints-The “4+1” View Model of Software Architecture, IEEE Software 12 (6), pp. 42-50.

     

    12.        Kennaley, M., 2008, “The 3+1 Views of Architecture (in 3D)”: An Amplification of the 4+1 Viewpoint Framework, Seventh Working IEEE/IFIP Conference on Software

    Architecture, pp. 299-302, IEEE Press.

     

    13.        Davis, M.J., Williams, R.B., 1997, Software Architecture Characterization, SSR'97, pp. 30-38, ACM Press, Massachusetts.

     

    14.        Soni, D., Nord, R.L., Hofmeister C., 1995, Software Architecture in Industrial Applications, ICSE'95, pp. 196-207, ACM Press, Seattle.

     

    15.        Zimmermann, O., Krogdahl, P., Gee, C., 2004, Elements of Service-Oriented Analysis and Design, http://www.ibm.com/developerworks/webservices/library/ws-soad1/.

     

    16.        Ramollari, E., Dranidis, D., Simons, A. J. H., 2007, A Survey of Service Oriented Development Methodologies, Proceeding of the 2nd European Young Researcher Workshop on Service Oriented Computing, p. 85-90, Leicester, UK.

     

    17.        Arsanjani, A., Ghosh, S., Allam, A., Abdollah, T., Ganapathy, S., Holley, K., 2008, SOMA: A method for developing service-oriented solutions, IBM systems Journal, vol. 47, no. 3, 377-396.

     

    18.        Arsanjani, A., [et al.], 2004, “Service-Oriented Modeling and Architecture (SOMA)”, IBM®    developerWorks®,      available          at: http://www.ibm.com/developerworks/webservices/library/ws-soa-design1.

     

    19.        SUN Microsystems, SOA RQ methodology - A pragmatic approach, http://www.sun.com/products/soa/soa methodology.pdf.

     

    20.        Allen,     P.,        2007,   the       service             oriented           process,           in         CBDi   Journal, http://www.cbdiforum.com/report        summary.php3?page=/secure/interact/2007-02/service oriented process.php&area=silver.

     

    21.        Erradi, A., [et al], 2006, SOAF: An architectural framework for service definition and realization, Proceedings of the IEEE International Conference on Services Computing, pp 151-158, Chicago, USA.

     

    22.        Mittal,    K.,       2006,   Service            Oriented          Unified            Process            (SOUP), http://www.kunalmittal.com/html/soup.shtml.

     

    23.        Papazoglou, M. P., van den Heuvel, W. J., 2006, Service-oriented design and development methodology, International Journal of Web Engineering and Technology (IJWET).

     

    24.        Erl, Thomas, 2008, SOA: Principles of Service Design, Prentice Hall.

     

    25.        Emig, C., [et al], 2006, Development of SOA-based software systems - and evolutionary programming approach, Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services, p 182, Guadeloupe, French Caribbean.

     

    26.        Jones, S., 2005, A Methodology for Service Architectures, Capgemini UK plc, http://www.oasisopen.org/committees/download.php/15071/A%20methodology%20for%20Service%20Archit ectures%201%202%204%20-%20OASIS%20Contribution.pdf.

     

    27.        Zhang, Liang-Jie, 2007, SOA Solution Reference Architecture, available at:

    doi.ieeecomputersociety.org/10.1109/ICWS.2007.166

     

    28.        Bieberstein, N., [et al.], 2008, Executing SOA: a practical guide for the service-oriented architecture, International Business Machines Corporation.

     

    29.        Arsanjani, A., Zhang, L.J., Ellis, M., Allam, A., Channabasavaiah. K., 2007, S3: A Service-Oriented Reference Architecture, IEEE Computer Society, pp. 10-17.

     

    30.        Simmons, Scott, 2007, Designing SOA with a business focus, IBM® WebSphere

    Developer       Technical         Journal,            available          at: http://www.ibm.com/developerworks/websphere/techjournal/0706_col_simmons/0706_col_simmons.html. 

     

    31.        Amsden, Jim, 2007, Modeling SOA: Part 3. Service Realization, available at:

    http://www.ibm.com/developerworks/rational/library/07/1023_amsden/index.html.

     

    32.        Eeles, P., Houston, K., Kozaczynski, W., 2002, Building J2EE™ Applications with the Rational Unified Process, Addision-Wesley.

     

    33.        Park, J., Moon, M., Yeom, K., 2008, The BCD view model: Business analysis view, service Composition view and service Design view for service-oriented software design and development, 12th IEEE International Workshop on Future Trends of Distributed Computing Systems, pp. 37-43, IEEE Press.

     

    34.        Wahli, U., Ackerman, L., Di Bari, A., Hodgkinson, G., Kesterton, A., Olson, L., Portier, B., 2007, Building SOA Solutions Using the Rational SDP, IBM Redbooks.

     

    35.        Ganci, J., Acharya, A., Adams, J., de Eusebio, P.D., Rahi, G., Strachan, D., Utsumi, K., Washio, N., 2006, Patterns: SOA Foundation Service Creation Scenario, IBM Redbooks.

     

    36.        Johnston,           S.,        2005,   UML   2.0       Profile for       Software         Services, http://www.ibm.com/developerworks/rational/library/05/419_soa/.

     

    37.        http://www.refah.ir

     

    38.        Bass, L., Clements, P., Kazman, R., 2003, Software Architecture in Practice, Second Edition, Addison Wesley. 

ثبت سفارش
عنوان محصول
قیمت