گزارش سمینار بررسی تعاملی متدولوژی RUP با معماری سرویس گرا

تعداد صفحات: 102 فرمت فایل: word کد فایل: 10002048
سال: 1388 مقطع: مشخص نشده دسته بندی: پایان نامه مهندسی کامپیوتر
قیمت قدیم:۱۶,۸۰۰ تومان
قیمت: ۱۴,۷۰۰ تومان
دانلود فایل
  • خلاصه
  • فهرست و منابع
  • خلاصه گزارش سمینار بررسی تعاملی متدولوژی RUP با معماری سرویس گرا

    گزارش سمینار مقطع کارشناسی ارشد

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

    گرایش مهندسی نرم افزار  

    چکیده

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

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

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

    فصل اول  کلیات 

    1-1 مقدمه 

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

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

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

    اما چرا مهندسی؟! در برخورد اول شاید به نظر برسد که مهندسی فقط مختص رشته هائی است که با ادوات

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

    همانطور که می دانید واژه مهندسی از کلمه هندسه به عاریت گرفته شده است. کلمه هندسه معادل لغت اندازه در فارسی است. علت استفاده از آن اینست که مهندسان همیشه ابزارهائی را برای محاسبۀ اندازۀ ساختۀ خود بکار می برند برای مثال مهندس عمران از متر برای اندازه گیری استفاده می کند. اما این چهارتباطی به نرم افزار دارد؟ 

    تولیدکنندگان نرم افزار چون از مهندسی بهره نمی بردند فاقد ابزاری برای محاسبۀ اندازۀ ساختۀ خود یعنی

    نرم افزار بودند به همین خاطر نه در ابتدای تولید نرم افزار، نه در اواسط کار و نه حتی در انتهای کار از

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

    یکی دیگر از نشانه های استفاده از مهندسی در هر عرصه ای استفاده از ماکتها یا مدلهای از پیش ساخته ای

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

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

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

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

    این مثال در مورد نرم افزار نیز صادق است مگر نه اینکه نرم افزار بنای تولیدی سازندگان است پس باید در طی این طریق از روشها و اسلوب خاصی استفاده شود تا مقصود نظر هر دو طرف حاصل شود پس تولیدکنندگان نرم افزار از مهندسین سایر رشته ها فراگرفتند که برای تولید هر بنائی (چه سخت افزاری و چه نرم افزاری) باید روش یا روشهائی را طی نمود تا کیفیت محصول نهائی تضمین شود. 

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

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

     

    1-2 فرآیند نرم افزار و مهندسی نرم افزار 

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

    » فرآیند نرم افزار زمینه ای است برای کارهایی که لازمه ایجاد نرم افزاری با کیفیت بالا هستند.« [2] برای

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

    تضمین شده است. اما سئوالی که پیش می آید این است که در مقدمه، بحث مهندسی نرم افزار پیش آمد.

    مهندسی نرم افزار چه تفاوتی با فرآیند نرم افزار دارد؟  

    در فرآیند نرم افزار هدف بستری است که در آن بستر نرم افزار تولید می شود اما در مهندسی نرم افزار

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

    اما چه تعریف کامل و جامعی می توان برای مهندسی نرم افزار بیان کرد.  

    » مؤسسه IEEE تعریف مناسبی را ارائه نموده است: 

    مهندسی نرم افزار: (1) بکارگیری روشی سیستماتیک، اصولی و قابل بررسی برای توسعه، اجرا و پشتیبانی نرم افزار می باشد: یعنی بکارگیری اصول مهندسی در نرم افزار. (2) مطالعه گرایشهای بخش (1).«[2] از

    جمله فوق برمی آید که مهندسی باعث شد که نرم افزار از یک حالت بی سامان به حالتی سامانمند تبدیل شود اما با چه روشی این عمل رخ داده است؟ 

    اولاً مهندسی نرم افزار متدهائی ارائه می کند که این متدها باعث می شوند که طریقه تولید و توسعه نرم

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

    ثانیاً همانطور که از تعریف سیستم ( مجموعه یا ترتیبی از عناصر که سازماندهی شده اند تا هدف از پیش تعریف شده ای را با پردازش اطلاعات تأمین نمایند. [2] ) برمی آید روش سیستماتیک، سازمانی برای اجرای فرآیند نرم افزار فراهم می کند تا هدف مهندسان نرم افزار را که از پیش تعیین شده است را مهیا کند. 

    1-3 مهندسی نرم افزار: یک تکنولوژی لایه ای  

    عموماً افراد خبره می دانند که لایه بندی باعث می شود پیچیدگی مسأله رفته رفته کاهش پیدا کند و هر لایه باری از حل مسأله را برعهده بگیرد. شکل زیر لایه های مهندسی نرم افزار را نمایش می دهد. (تصاویر و نمودار در فایل اصلی موجود است) 

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

    افزارهای تحویلی به مشتری بود. شاید بیشترین تأکید مهندسی نرم افزار بر روی بالا بردن کیفیت نرم افزار

    باشد و براین اساس سایر لایه ها بنیان گذاشته شده است. مثلاً هدف از لایه فرآیند، فراهم کردن بستری

    برای مهندس نرم افزار جهت بالا بردن کیفیت نرم افزار است، هدف از متد ارائه روشی برای کیفی کردن

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

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

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

    همانطور که در لایه های مهندسی نرم افزار دیده شد یکی از لایه های اساسی آن، لایه روش می باشد که در این لایه مهندس نرم افزار سئوالات تکنیکی را برای ایجاد نرم افزار مطرح می کند. » روشها شامل مجموعه

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

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

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

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

  • فهرست و منابع گزارش سمینار بررسی تعاملی متدولوژی RUP با معماری سرویس گرا

    فهرست:

         عنوان                                                              صفحه

    فصل اول (کلیات)           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             

    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.                   براآنی، احمد، . . . (و دیگران)، 1384، مرجع کاربردی متدولوژی RUP برای تولید و توسعۀ سیستمهای نرم افزاری، انتشارات دانشگاه اصفهان. 

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

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

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

    5.                   Zhang, Liang-Jie, 2007, SOA Solution Reference Architecture, available at: doi.ieeecomputersociety.org/10.1109/ICWS.2007.166

    6.                   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_simmon s/0706_col_simmons.html.  

    7.                   Amsden, Jim, 2007, Modeling SOA: Part 3. Service Realization, available at: http://www.ibm.com/developerworks/rational/library/07/1023_amsden/index.ht ml.

    8.                   Ferris, C., Farrell J., 2003, What are Web Services?, Communication of the  ACM, June 2003, Vol. 46, No. 6.

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

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

    11.                Arsanjani, A., Zhang, L.J., Ellis, M., Allam, A., Channabasavaiah. K.: S3: A Service-Oriented Reference Architecture. IEEE Computer Society, pp. 10--17, (May/June 2007). 

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