فرمت فایل: ورد –Word و قابل ویرایش تعداد صفحات: 125     چکیده RUP یک متدولوژی شیءگرا محسوب می شود که توانسته مقبولیت بسیاری در بین مهندسین نرم افزار کسب کند. این متدولوژی یک روش تولید و توسعه نرم افزار می باشد که تکراری، معماری محور و مبتنی بر مواردکاربری است از سوی دیگر یک فرآیند مهندسی نرم افزار خوش ساختار و خوش تعریف نیز به حساب می آید. RUP یک محصول فرآیندی است که یک چارچوب با قابلیت سفارشی شدن را برای مهندسی نرم افزار فراهم می کند. SOA نمونه ای از سبک معماری است که در آن سرویس مفهوم کلیدی و اساسی محسوب می شود. این معماری توجه ویژه ای بر روی کسب و کار دارد به همین خاطر خلأ موجود بین حرفه و IT را می توان توسط این معماری پوشش داد. این پاردایم فارغ از نوع پیاده سازی توانسته در بین شرکتهای بزرگ تجاری نقش کلیدی برعهده بگیرد و بسیاری از مشکلات تحلیل و طراحی را برطرف کند. SOA به عنوان یک معماری کاربردی با نبود یک متدولوژی تمام عیار روبرو است که در این زمینه فعالیتهای متعددی صورت گرفته است که بعضی از آنها در حال شکل گیری هستند. مسأله ای که در این گزارش سعی در واکاوی آن داریم این است که RUP به عنوان یک متدولوژی تا چه اندازه می تواند به SOA در ایفای نقش خطیرش یاری رساند؟ تعامل مابین RUP به عنوان یک متدولوژی و SOA به عنوان یک معماری تا چه حد می تواند SOA را در فرآیند تولید و توسعه نرم افزار همراهی کند؟ و فهرست مطالب   عنوان صفحه فصل اول (کلیات) 1 1- 1 مقدمه 1 1- 2 فرآیند نرم افزار و مهندسی نرم افزار 3 1- 3 مهندسی نرم افزار: یک تکنولوژی لایه ای 5 1- 4 متدولوژی در مهندسی نرم افزار 6 1- 5 معماری نرم افزار 9 1- 6 صورت مسأله 11 فصل دوم (آشنائی کلی با RUP و SOA) 13 2- 1 مقدمه 13 2- 2 معرفی RUP 14 2- 3 معرفی SOA 17 24 فصل سوم (متدولوژی RUP) 24 RUP روش 1 -3 3- 2 تاریخچه RUP 26 3- 3 RUP و تولید تکراری 28 3- 4 RUP یک فرآیند مهندسی نرم افزار خوش تعریف 32 3- 4-1 ساختار دینامیک RUP 33 3- 4-2 ساختار استاتیک RUP 34 3- 5 RUP یک فرآیند با قابلیت سفارشی شدن 37 3- 6 ابزار پیکربندی و تألیف فرآیند 39 3- 7 کمبودهای متدولوژی RUP 41 فصل چهارم (سرویس گرائی) 43 4- 1 مفاهیم اولیه در سرویس گرائی 43 4- 2 ساختارکلی معماری سرویس گرا، عناصر اصلی و ابزار وب سرویسها 45 ز 4- 3 سرویس و شیء 47 فصل پنجم (SOMA) 55 5- 1 مقدمه 55 5- 2 چشم انداز حرکت به سوی راه حلهای سرویس گرا 56 5- 3 ابزار حمایتی Rational برایSOA 61 64 (Rational Method Composer) سازنده روش 4 -5 65 RUP SOMA 5 -5 5- 5-1 شناسائی سرویسهای کاندید و جریانها 67 5- 5-1-1 تجزیه دامنه 68 5- 5-1-2 مدلسازی سرویس هدف 71 5- 5-1-3 تحلیل دارائیهای موجود 73 5- 5-2 مشخصه سازی سرویسها، مؤلفه ها و جریانها 74 5- 5-3 عینیت بخشی سرویسها 80 5- 5-4 RUP SOMA - تعریف فراساختار سرویس 82 فصل ششم (نتیجه گیری) 84 منابع 86   ح   فصل اول کلیات   1-1 مقدمه اگر به چند دهه قبل برگردیم، خواهیم دید که تولید نرم افزار به سختی انجام می شد. فرآیند تولید نرم افزار شکننده می نمود. تیم تولیدکننده با مشکلات عدیده ای درگیر بود. تحویل محصول به موقع صورت نمیگرفت. نرم افزار تولیدی بسیار گرانقیمت بود و دست آخر نه سهامدار از محصول نهائی راضی بود و نه مشتری. این علائم به همراه نشانه های دیگر که به علائم بحران نرم افزار شهرت پیدا کردند برنامه نویسان و تولیدکنندگان نرم افزار را به این فکر واداشت که تا جای ممکن از این بحران رهائی یابند. تولیدکنندگان نرم افزار و شرکت های بزرگ کامپیوتری و دانشگاهیان در پی آن شدند که فنون مهندسی را وارد این عرصه کنند چراکه سایر رشته ها توانسته بودند با الهام از این موضوع بحرانهای به مراتب سخت تر از این را پشت سر بگذارند. اما چرا مهندسی؟! در برخورد اول شاید به نظر برسد که مهندسی فقط مختص رشته هائی است که با ادوات و ابزارهای مکانیکی و فیزیکی سروکار دارند اما اینگونه نیست. امروزه واژه مهندسی در بسیاری از علوم، حتی علوم انسانی نیز وارد شده است بطوریکه مهندسی اجتماعی، مهندسی فرهنگی و مانند اینها بسیار به گوش می رسد. همانطور که می دانید واژه مهندسی از کلمه هندسه به عاریت گرفته شده است. کلمه هندسه معادل لغت اندازه در فارسی است. علت استفاده از آن اینست که مهندسان همیشه ابزارهائی را برای محاسبۀ اندازۀ ساختۀ خود بکار می برند برای مثال مهندس عمران از متر برای اندازه گیری استفاده می کند. اما این چهارتباطی به نرم افزار دارد؟ تولیدکنندگان نرم افزار چون از مهندسی بهره نمی بردند فاقد ابزاری برای محاسبۀ اندازۀ ساختۀ خود یعنی نرم افزار بودند به همین خاطر نه در ابتدای تولید نرم افزار، نه در اواسط کار و نه حتی در انتهای کار از کیفیت و کمیت ساخته خود هیچ معیار و محک فیزیکی در دست نداشتند و به طور دقیق نمی دانستند که در چه مرحله ای از تولید نرم افزار به سر می برند. به همین خاطر از مدیریت دقیق و ریزبینانه ای بر روی ساخته خود بی بهره بودند. یکی دیگر از نشانه های استفاده از مهندسی در هر عرصه ای استفاده از ماکتها یا مدلهای از پیش ساخته ای است که به عنوان الگو و سرمشق مهندسان استفاده می شد منباب مثال مهندسین عمران قبل از شروع ساخت هر سازه ای اقدام به تولید آن سازه در سطح بسیار کوچک می نمایند بطوریکه این مدل شبیه پروژه نهایی است اما عین آن نیست. این مدل در همه مراحل کار، جلوی روی سازندگان آن قرار داشت و هر نقصی در تولید سازه اصلی در مقایسه با آن قابل یافتن بود. تولیدکنندگان نرم افزار بایستی از طراحی و تولید ضمنی دست برمی داشتند و اقدام به ساخت ماکتهائی شبیه به نرم افزار اصلی می نمودند تا این ماکت چراغ راه آنها در لحظات حساس باشد. نکته دیگر اینکه مهندسین عمران سعی می کنند کار را از پشت میز شروع کنند نه اینکه به یکباره با حضور در محل موردنظر اقدام به ساخت نمایند. آنها در ابتدا می سنجند که آیا ساخت بنای موردنظر در این محل اصلاً امکان پذیر است یا نه؟ و اگر آری آیا از عهده نیروی انسانی موجود برمی آید یا نه؟ اگر پاسخ به این دو سئوال آری بود، کار با ایجاد نقشه ها و پلانها آغاز می شد و در همه این مراحل مشتری و کارفرما را از چند و چون کار آگاه می کردند. پس از تثبیت نقشه ها و رضایت طرفین اقدام به ساخت ماکتی هر چند کوچک از بنای موردنظر می نمایند تا مقصود حاصل شود. اکنون نوبت آن رسیده است که اقدام به فعالیتفیزیکی و ساخت و ساز واقعی نمایند. این مثال در مورد نرم افزار نیز صادق است مگر نه اینکه نرم افزار بنای تولیدی سازندگان است پس باید در طی این طریق از روشها و اسلوب خاصی استفاده شود تا مقصود نظر هر دو طرف حاصل شود پس تولیدکنندگان نرم افزار از مهندسین سایر رشته ها فراگرفتند که برای تولید هر بنائی (چه سخت افزاری و چه نرم افزاری) باید روش یا روشهائی را طی نمود تا کیفیت محصول نهائی تضمین شود. نکته دیگر اینکه تولیدکنندگان به این فکر افتادند که از مدیریت نیز در این عرصه استفاده کنند چراکه هم منابع فیزیکی (سخت افزاری) و هم منطقی (نرم افزاری) وجود دارند که باید به درستی مدیریت شوند پس تولیدکنندگان علاوه بر نقشهائی که جهت برآورده کردن خواسته های فوق ایجاد کردند فرد یا افرادی را مؤظف به مدیریت منابع انسانی (تیم تولیدکننده نرم افزار) و همچنین مدیریت پروژه نمودند. با این تفاسیر واژه هائی چون متدولوژی، امکان سنجی، مدلسازی و در رأس همه اینها اصطلاح مهندسی وارد حیطه نرم افزار شد و واژه مهندسی نرم افزار ماحصل این تلاش بود. با بوجود آمدن مهندسی نرم افزار تولید و توسعه نرم افزار هدفمند، نظام مند گردید و مهندسی نرم افزار باعث ایجاد تحولی شگرف در این عرصه گردید.   1-2 فرآیند نرم افزار و مهندسی نرم افزار همانطور که ذکر شد تولیدکنندگان در تلاش بودند که تولید نرم افزار را به نحوی قانونمند کنند تا تولید و توسعه نرم افزار با قدرت و بدون هیچ نقصی انجام شود. به همین خاطر مفهوم فرآیند نرم افزار مطرح شد. » فرآیند نرم افزار زمینه ای است برای کارهایی که لازمه ایجاد نرم افزاری با کیفیت بالا هستند.« [2] برای اینکه نرم افزار تولیدی بتواند جوابگوی نیازهای کاربر، مشتری و فرامین کارفرما باشد باید در بستری مناسب اقدام به تولید نرم افزار نمود تا هم کاربر و مشتری از نرم افزار راضی باشند و هم سهامداران. این بسترتوسط فرآیند نرم افزار ایجاد می شود و تا زمانی که تیم توسعه در این بستر گام برمی دارند کیفیت نرم افزار تضمین شده است. اما سئوالی که پیش می آید این است که در مقدمه، بحث مهندسی نرم افزار پیش آمد. مهندسی نرم افزار چه تفاوتی با فرآیند نرم افزار دارد؟ در فرآیند نرم افزار هدف بستری است که در آن بستر نرم افزار تولید می شود اما در مهندسی نرم افزار فناوریهائی که در این بستر برای تولید و توسعه نرم افزار مفید فایده هستند، لحاظ می شود. به طور خلاصه مهندسی نرم افزار در بستر فرآیند نرم افزار معنی و مفهوم خود را پیدا می کند. اما چه تعریف کامل و جامعی می توان برای مهندسی نرم افزار بیان کرد. » مؤسسه IEEE تعریف مناسبی را ارائه نموده است: مهندسی نرم افزار: (1) بکارگیری روشی سیستماتیک، اصولی و قابل بررسی برای توسعه، اجرا و پشتیبانی نرم افزار می باشد: یعنی بکارگیری اصول مهندسی در نرم افزار. (2) مطالعه گرایشهای بخش (1).«[2] از جمله فوق برمی آید که مهندسی باعث شد که نرم افزار از یک حالت بی سامان به حالتی سامانمند تبدیل شود اما با چه روشی این عمل رخ داده است؟ اولاً مهندسی نرم افزار متدهائی ارائه می کند که این متدها باعث می شوند که طریقه تولید و توسعه نرم افزار روشمند شود و طراحی از حالت ضمنی به حالت صریح تبدیل شود. حالت صریح به این معنی که تولیدکنندگان صریحاً و دقیقاً در هر فاز و مرحله ای از تولید نرم افزار که باشند (توسعه، اجرا و پشتیبانی) باید مشخص کنند که روش بکارگرفته شده چه کمکی به تولیدکنندگان می نماید. ثانیاً همانطور که از تعریف سیستم ( مجموعه یا ترتیبی از عناصر که سازماندهی شده اند تا هدف از پیش تعریف شده ای را با پردازش اطلاعات تأمین نمایند. [2] ) برمی آید روش سیستماتیک، سازمانی برای اجرای فرآیند نرم افزار فراهم می کند تا هدف مهندسان نرم افزار را که از پیش تعیین شده است را مهیا کند. 1-3 مهندسی نرم افزار: یک تکنولوژی لایه ای عموماً افراد خبره می دانند که لایه بندی باعث می شود پیچیدگی مسأله رفته رفته کاهش پیدا کند و هر لایه باری از حل مسأله را برعهده بگیرد. شکل زیر لایه های مهندسی نرم افزار را نمایش می دهد.   شکل 1- 1: لایه های مهندسی نرم افزار [2] در این لایه بندی از ابزار، روش، فرآیند و تمرکز بر روی کیفیت بحث می شود. سنگ زیربنای مهندسی نرم افزار تمرکز بر روی کیفیت نرم افزار است چراکه یکی از علایم بحران نرم افزار بی کیفیت بودن نرم افزارهای تحویلی به مشتری بود. شاید بیشترین تأکید مهندسی نرم افزار بر روی بالا بردن کیفیت نرم افزار باشد و براین اساس سایر لایه ها بنیان گذاشته شده است. مثلاً هدف از لایه فرآیند، فراهم کردن بستری برای مهندس نرم افزار جهت بالا بردن کیفیت نرم افزار است، هدف از متد ارائه روشی برای کیفی کردن محصول نهائی است و دست آخر مقصود از لایه ابزار ایجاد و استفاده از ادواتی است که با استفاده از این ادوات محصول نهائی به راحتی تولید و توسعه داده شود. به همین خاطر کیفیت در مهندسی نرم افزار از اهمیت بسیار بالائی برخوردار است.       1-4 متدولوژی در مهندسی نرم افزار راه برونرفت از بحران نرم افزار استفاده از اصول مهندسی نرم افزار بود که باعث ایجاد تحولات شگرف در عرصه تولید و توسعه نرم افزار گردید. یکی از نکات اساسی که در این راه به آن بسیار پرداخته شد بحث روش و متدولوژی بود. همانطور که در لایه های مهندسی نرم افزار دیده شد یکی از لایه های اساسی آن، لایه روش می باشد که در این لایه مهندس نرم افزار سئوالات تکنیکی را برای ایجاد نرم افزار مطرح می کند. » روشها شامل مجموعه گسترده ای از کارهایی هستند که هر یک شامل امکان سنجی و تحلیل، طراحی، ایجاد برنامه، آزمایش و پشتیبانی می باشند. روشهای مهندسی نرم افزار بر روی چند اصل بنا شده اند که شامل مدلسازی فعالیتها و روشهای توصیف دیگر هستند. « [2] با توجه به توضیحات فوق برای تعریف دقیق روش یا متد خواهیم داشت: فرآیندی منظم که با استفاده از مجموعه ای از نمادگذاریهای خوش تعریف مجموعه ای از مدلها را ایجاد می کند که هر کدام بخشی از سیستم نرم افزاری در دست تولید (یا توسعه) را توصیف می کند. حال می توان به اهمیت متد پی برد چراکه متد باعث می شود که از اولین گام تا آخرین گام در توسعه نرم افزار فرآیندی منظم ساری و جاری باشد. روش یا متد در مهندسی نرم افزار امکانی فراهم می کند که با استفاده از آن تولیدکننده نرم افزار همیشه و در همه حال از یک سری قواعد و قوانین تبعیت کند تا کیفیت محصول نهائی تأمین شود. اکنون می توان متدولوژی را تعریف کرد: متدولوژی مجموعه ای از روشهاست که در طول چرخه حیات سیستم نرم افزاری از زمانیکه ایده تولید نرم افزار در ذهن تهیه کنندگان مطرح می شود تا لحظه ای که نرم افزار فرسوده و مستعمل می گردد، اعمال شده و بر یک جهان بینی و نگرش کلی درباره جهان نرم افزار متکی است. با این تفاسیر، وجود متدولوژی در هر پروژه نرم افزاری یک جزوء لاینفک و غیرقابل چشم پوشی است چراکه متدولوژی خوب متضمن کیفیت بالای نرم افزار است اگر به خوبی پیاده سازی شود. متدولوژی یک نگرش و آرمان جدید برای توسعه دهندگان نرم افزار ایجاد می کند که این نگرش باعث فراهم کردن افقهای نو و تازه در مهندسی نرم افزار گردید. یک متدولوژی مطلوب دارای ویژگیهای اساسی زیر است: [2] الف) ارائه تعاریف از مفاهیم اولیه بکار رفته در متدولوژی ب) مدل یا مدلهائی برای فرآیند تولید ارائه می کند. ‌ج) مدلی زیربنائی (مدل معماری) نرم افزار را شامل می شود. ‌د) از نمادگذاری استاندارد در کل سیستم بهره می برد. هـ) شامل تکنیکهایی برای پیاده سازی و کنترل پیچیدگی سیستمهای کنونی است. ‌و) از معیارها و سنگ محکهائی برای ارزیابی نتایج حاصل از کاربرد متدولوژی استفاده می کند. ‌ز) از ابزارهای اتوماتیک برای تسهیل در امر تولید و اجرای مدلهای مبتنی بر متدولوژی بهره می برد. با کمی دقت در این ویژگیها درمی یابیم که اصول مهندسی که در نرم افزار بکار می بستیم در متدولوژی نهفته است برای اینکه (به ترتیب): الف) متدولوژی خودتعریف است و مفاهیم بنیادین و اصولی خود را تعریف می کند. ‌ب) دانستیم که مهندسان عمران و معماری از مدلها و ماکتها برای تعریف راه حل اولیه پروژه بهره می برند در متدولوژی نیز این ویژگی درنظر گرفته شده است و متدولوژی این امر خطیر را برعهده می گیرد و مجموعه ای از مدلها را برای هر مرحله از تولید فراهم کرده تا امر تجزیه، تحلیل و طراحی راحت تر صورت پذیرد. ‌ج) همانطور که مهندس عمران اول اسکلت ساختمان را طراحی و پیاده سازی می کند مهندس نرم افزار نیزباید اسکلت و شاکله درستی برای نرم افزار درنظر گرفته و قادر به پیاده سازی آن به کمک سایر اعضای تیم توسعه باشد. این مدل به مدل زیربنائی یا مدل معماری معروف است و زیرساخت اصلی هر پروژه نرم افزاری تلقی می شود و جزوء یکی از مدلهای اساسی در مهندسی نرم افزار بطور عام و متدولوژی بطور خاص است. ‌د) برای اینکه فهم مدلها و فرآورده های خروجی برای همه اعضای تیم میسر باشد متدولوژی اقدام به ارائه نمادهائی در کل مسیر نموده است. البته لازم به ذکر است که این نمادها استاندارد هستند و این استاندارد بودن فهم آن را سهل می کند بطوریکه افرادی که در پروژه دخیلند و افرادی که خارج از تیم قرار دارند با اندک معلوماتی از این نمادها می توانند به راحتی از کل جریان حاکم بر پروژه مطلع باشند. هـ) به یاد داریم که پیچیدگی سیستم های نرم افزاری روز به روز در حال افزایش بود و تولیدکنندگان در مواجهه با آن ناکام بودند بنابراین باید تدبیری اندیشیده می شد تا امکان غلبه بر این بحران فراهم می گردید. متدولوژی این نقیصه را با ابزارهایی جهت کنترل پیچیدگی و طریقه پیاده سازی مهیا کرد. ‌و) پیشتر دانستیم که در بحران نرم افزار هیچ معیار و محکی برای اینکه تیم، مشتری و سهامدار از چند و چون کار مطلع باشند در اختیار نبود و اگر وجود داشت قابل لمس نبود بنابراین متدولوژی این نقیصه را نیز با ایجاد فرسنگ شمارهائی فراهم نمود تا همه اعضای درگیر از پیشرفت یا توقف پروژه مطلع شوند همچنین بدانند محصول از چه سطح کیفی برخوردار است. ‌ز) رفته رفته باید به فکر آینده نیز بود چراکه تکنیکهای نسل چهارم اقدام به خودکارسازی بخشی از سیستم موردنظر نموده اند بنابراین متدولوژی از CASE Tools برای این منظور بهره برد. هدف از آن یاری گرفتن از کامپیوتر برای سازماندهی و کنترل توسعه نرم افزار است همچنین باعث می شود که اعضای تیم از نقطه ای که پروژه در حال حاضر در آن مرحله قرار دارد مطلع شوند همینطور کمک می کند تا از منظمبودن و فرآیند بررسی نقاط آزمایش (check-point) مطمئن شوند. سعی خواهد شد در این سمینار از بین متدولوژیهای مطرح اقدام به توصیف متدولوژی RUP نمائیم تا از این رهگذر راهی برای تعامل مستقیم این متدولوژی با سایر اصول مهندسی نرم افزار از جمله معماری نرم افزار و در بین آنها معماری سرویس گرا مهیا گردد.   1-5 معماری نرم افزار هر بنای ساختمانی دارای شاکله و ساختاری منحصر به خود است یعنی اینکه از معماری مخصوص به خود بهره می برد و این معماری منحصربفرد است که ساختمانی را از ساختمانهای دیگر متمایز می سازد یعنی اینکه اگر بخواهیم دو ساختمان را با هم مقایسه کنیم بهترین و مهمترین عامل برای قیاس آنها معماری و ساختار آن ساختمانهاست. در تولید و توسعه نرم افزار نیز وضع برهمین منوال و بلکه حساستر است. هر نرم افزاری که تولید می شود اولاً باید دارای معماری باشد ثانیاً این معماری با کار لازم برای تولید آن پروژه تناسب داشته باشد. اگر نرم افزاری معماری نداشته باشد به مانند ساختمانی است که شاکله ندارد و اگر ساختمانی شاکله نداشته باشد از پای بست ویران خواهد بود هرچند نقش و نمای ظاهری آن فریبنده باشد در نتیجه با کوچکترین لرزه ای فرو خواهد ریخت. اما اگر معماری داشت ولیکن این معماری با پروژه هم خوانی نداشت در آنصورت این ناهماهنگی و واگرائی در گوشه ای از کار خود را نشان خواهد داد. اما برای تعریف معماری نرم افزار چند اصطلاح باید ابتدا به عنوان پیش نیاز توضیح داده شوند اولین آنها پیمانه یا ماژول می باشد. در فراهم کردن راه حل برای یک مسأله پیچیده و بزرگ که اولین بار با آن مواجه می شویم یکی از بهترین راه حلها استفاده از ایده تقسیم و حل است براین اساس مسأله را به چندین زیر مسأله تقسیم می کنیم که ممکن است این زیر مسأله ها برای ما آشنا باشند سپس راه حل هر یک از این زیرمسأله ها را مهیا می کنیماکنون نوبت به یکپارچه کردن تمام زیرمسأله هاست به همین منظور عمل جمع کردن یا یکپارچه کردن انجام می شود پس حل مسأله به 3 قسمت مجزا تقسیم شد ابتدا تقسیم مسأله به زیرمسأله ها سپس حل زیرمسأله ها و نهایتاً جمع کردن راه حلها به صورت یک راه حل کلی برای مسأله اولیه. از این ایده در مهندسی نرم افزار به واحدبندی (modularity) نام برده می شود. براین اساس سعی می کنیم مسأله را به واحدهائی به تعداد مناسب تقسیم کنیم که به این واحدها پیمانه گفته می شود و این عمل را واحدبندی گویند. در مورد رابطه پیمانه و معماری نرم افزار Shaw و Garlan معتقدند: » حتی اولین برنامه ها نیز به پیمانه ها تقسیم می شدند، سیستم های نرم افزاری دارای معماری بودند، برنامه نویسها مسئول ارتباط بین پیمانه ها و خصوصیات کلی مونتاژ بودند. از نظر تاریخی، معماریها، اعمال ضمنی پیاده سازی سیستمهای گذشته محسوب می شدند . . . و هدفی برای بیان صریح آنها در سیستم نهایی وجود نداشت.« [2] بنابراین متوجه می شویم که معماری از همان ابتدا در سیستم های نرم افزاری وجود داشت اما این حضور، حضوری غیرملموس به حساب می آمد و برنامه نویسان ندانسته از آن بهره می بردند. پس از این تاریخ مهندسان نرم افزار پی به اهمیت معماری نرم افزار بردند حتی برای این منظور نقشی به نقشهای موجود در تیم توسعه به نام معمار نرم افزار افزودند و شرح وظایف مبسوطی نیز برای وی تدارک دیدند و با این اوصاف باعث شدند که معماری از پشت پرده نرم افزار به روی صحنه وارد شود و از حالت ضمنی به حالت صریح مبدل گردد. اما اصطلاح دیگری که ارتباط تنگاتنگی با معماری دارد اصطلاح مؤلفه (component) می باشد. Bass، Clements و Kazman اینگونه بیان می کنند: » معماری نرم افزار برای یک برنامه یا سیستم محاسباتی عبارتست از ساختار یا ساختارهائی از سیستم کهشامل مؤلفه های نرم افزار، خواص قابل رؤیت آن مؤلفه ها و رابطه بین آنها می باشد. « [2] با توجه به توضیحات فوق اقدام به معرفی معماری سرویس گرا به عنوان یکی از معماریهای جدید در عرصه مهندسی نرم افزار خواهیم نمود و در این خصوص بیشتر توجه خود را معطوف به معماری نرم افزار سرویس گرا خواهیم نمود. پس از توصیف مناسبی از این نوع معماری سعی خواهیم نمود که این معماری را با متدولوژی RUP که از روش شیءگرائی بهره می برد در یک بررسی تعاملی مورد مداقه قرار دهیم.   1-6 صورت مسأله هر نرم افزاری در حین تولید دارای دو وجه است: وجهی مربوط به متدولوژی توسعه و وجهی مربوط به معماری نرم افزار، بنابراین برای توسعه بهتر یک نرم افزار باید هر دو جنبه لحاظ شود. بر این اساس، سعی ما در این گزارش براینست که متدولوژی RUP را به عنوان یک متدولوژی شیء گرای موفق با نمونه ای از سبک معماری جدید به نام SOA به چالش رودررو بکشیم و از این رهگذر نقاط ضعف و قوت این دو مقوله را دریابیم و تاحدامکان نقاط ضعف یکی را با نقاط قوت دیگری پوشش دهیم تا در توسعه نرم افزارهای آتی بیشتر مثمرثمر واقع شوند. سعی ما بر اینست که به این سئوالها، پاسخ مناسبی در این گزارش داده شود: آیا تعامل این دو مقوله، تعاملی یکطرفه است که باعث حذف یکی از طرفین می شود؟ آیا این دو مقوله با هم قابل جمعند یا نه؟ نقاط اشتراک و افتراق این دو مقوله چیست؟ آیا تجمیع آن دو ارزش افزوده ای ایجاد می کند یا نه؟ متدولوژیهای سرویس گرای موجود آیا توانسته اند به نحو مقتضی و مانند RUP پاسخگوی نیازمندیهایکاربران باشند؟ آنچه مسلم است اینکه، در این بین به تعامل دو پارادایم شیء گرائی و سرویس گرائی نیز خواهیم پرداخت. در فصل بعد یک شناخت کلی از طرفین بحث یعنی RUP و SOA فراهم می کنیم تا در فصل 3 جزئیات بیشتری از متدولوژی RUP تشریح نمائیم. آنچه در این فصل با تأکید بیشتری مطرح شده است قابلیت سفارشی شدن RUP و ابزارهای پیکربندی آن است که RUP را به عنوان یک محصول و نه یک فرآیند دستخوش تغییرات می سازد. در فصل 4 سرویس گرائی را معرفی کرده ایم و به تفاوت دو مفهوم شیء و سرویس که از مفاهیم اساسی پارادایم های شیء گرائی و سرویس گرائی است، پرداخته ایم. در فصل 5، SOMA به عنوان یک متدولوژی سرویس گرا معرفی شده است و همچنین RUP SOMA تشریح گردیده است و RMC به عنوان ابزار Rational برای ساختن روش معرفی شده است. در فصل 6 نیز نتیجه گیری، جمع بندی و ترسیم رهیافتهای آینده مطرح شده است.