یکی از متدولوژی های معروف دنیا که کارآئی و کارآمدی خود را در طی سالها و پروژه های مختلف اثبات کرده است متدولوژی RUP است . RUP از چهار فاز آغازین ، جزئیات ، تولید و استقرار تشکیل شده ، که با توجه به حجم پروژه می توان هر فاز را به دوره های تکراری تقسیم کرد و سیستم را در مراحل تکراری توسعه داد. این متدولوژی سیستم را بر اساس موارد استفاده سیستم برای کاربران آن توسعه می دهد و از این جهت تاکید زیادی بر درک صحیح نیازمندیها و مدیریت آن ها دارد.
متدولوژی های ساخت یافته ، طی سال ها برای انجام انواع پروژه ها مورد استفاده قرارگرفته بود.مهمترین مشکل این متدولوژی ها ،پیاده سازی آن در محیط واقعی و دنیای شی گرا است و مشتری تا انتهای کار، نمی تواند نسخه عملی و کاربردی از سیستم را ببیند .در RUP که مبتنی بر تحلیل و طراحی شیء گراست ، دوره زندگی یک نرم افزار به چندین سیکل شکسته می شود کـه هـر سـیکل بـر روی یک نسل جدید از محصول کار می کند و در طول پروژه چندین نسخه از محصول را مشاهده کرده و درباره آن نظر می دهد .مهمترین مزیت تکراری و تکاملی بودن RUP کاهش ریسک انجام پروژه است ، چرا که ریسک ها در ابتدای پروژه شناسایی شده و تیم درصدد رفع آن بر می آید و از این جهت برای پروژه های بزرگ و با امکان ریسک بالا مناسب است، البته برای پروژه های کوچک نیز می توان آن را سفارشی کرده و مورد استفاده قرار داد.
واژه های کلیدی : مورد استفاده (usecase) ، کاربر (actor) ، تکرار (iteration) ، متاثر (stakeholder) ، مستند دیدگاه (vision)، نیازمندیهای تکمیلی (supplementalry)، آغازین (inception) ، جزئیات (elaboration) ، تولید (construction) ، استقرار (transition)
تاریخچه RUP
مدل RUP طی سالها تکامل یافته و تجربه شرکت ها و افراد متخصص زیادی که در پروژه های مختلفی شرکت داشته اند را به همراه دارد.
Rational Objectory Process 4.0 از ترکیب و ادغام دو روش به نام های Rational Approach و Objectory Process 3.8 به وجود آمد که مفهوم اصلی موارد استفاده و ساختار فرایند را از آن ها به ارث برد .و ساختار توسعه تکراری و معماری را از پیش زمینه های قبلی به همراه داشت .این نسخه RUP مفهوم مدیریت نیازمندی ها را نیز شامل می شدو فرایند کامل تست را از SQA – شرکتی که بعد ها با شرکت Rational ادغام شد- به ارث برده بود. و اولین مدل فرایند بود که از زبان تازه ابداع شده UML 0.8 برای مدلسازی استفاده می کرد.Objectory Process در سوئد و توسط شخصی به نام ایوار جکوبسون ابداع شده بود که نتیجه تجربه کاری وی با اریکسون بود.این مدل فرایند با نام Objectory AB محصول شرکت وی شد که عمده تمرکز آن بر مفهوم موارد استفاده و متدهای طراحی شیء گرا بود ، که به سرعت مورد توجه و استقبال بسیاری از شرکت های جهان قرارگرفت . در4.1 Rational Objectory Process مفهوم دقیق بر جمع آوری نیازمندیها به آن اضافه شد . و مفاهیم مدیریت تغییرات ، مهندسی و مدلسازی فرایند مربوط به تجارت و کسب و کار ، تست کارآیی ، مهندسی داده ها و طراحی شیءگرا در نسخه Rational Unified Process 5.0 به آن اضافه شد.
به طور کلی مدل فرایند RUP حاصل تلاش و تجربه ایوار جکوبسون ، گردی بوچ و جیمز رام باو در زمینه تحلیل و طراحی شیءگرا می باشد.
مفاهیم پایه فرایند
یک مدل فرایند توصیف می کند که چه کسی ، چه کاری را ، چگونه و در چه مدت زمانی طی می کند . RUP از چهار عنصر پایه زیر برای توصیف این مفاهیم استفاده می کند.
• Worker ، چه کسی
• Artifact ، چه چیزی
• Activity ، چگونه
• Workflow ، چه مدت زمانی
Worker : رفتار و مسئولیت یک شخص یا گروهی از افراد که با هم به عنوان یـک تـیم کـار می کنند را تعریف می کند . می توان worker را به عنوان یک کلاه در نظر گرفت که یـک شخص می تواند در پروژه آن را به سر بگذارد ، با توجه به این که یک شـخص مـی توانـد چندین کلاه متفاوت نیز به سربگذارد . در واقع یک تعریف رول است که مشخص می کند اشخاص کار را چگونه پیش ببرند .
Artifact : هر نوع محصولی که در طول پروژه تولید می شود و در مراحلی دیگر مصرف می شود تا محصول نهائی تولید شود. مدل طراحی ، مدل موارد استفاده ، مستند معماری نرم افزار و یا سورس برنامه ، همه مواردی از artifact هستند.
Activity : واحد کاری که به شخص در رول خاص واگذار می شود و معمولا به صورت ایجاد یا به روزرسانی چند artifact تعریف می شود.
Workflow : روندکاری مراحل انجام قسمت های مختلف پروژه را مشخص می کند.
مدل معماری لایه ای از چند لایه به شکل زیر تشکیل شده:
این لایه ، لایه ایست که کاربر مستقیما با آن سروکار دارد و خود از دو مولفه تشکیل شده :
اگر با مفهوم User Experience Model در تحلیل و طراحی شیء گرا آشنا باشید story board همان UI Component و navigation map همان UI Process Component را شامل می شود.
Business Logic Layer(BLL)
نرم افزارهائی قدرتمند هستند که مستقل از لایه واسط کاربری بتوانند به ارائه سرویس بپردازند. اگر درخواستی از مولفه دیگری در یک سازمان که نرم افزار ما در آن نصب و راه اندازی شده وارد سیستم ما شود ، سیستم باید توانائی پاسخگوئی به آن را داشته باشد . مسائلی از این قبیل در بخش service interface راه اندازی می شود.
سطح بعدی در BLL شامل سه قسمت اصلی است :
موارد دیگری که باید در BLL قرار گیرند عبارتند از :
که Object ها در قسمت Business Entity ، ارتباط میان اشیا ، قواعد و فرایند ها در قسمت Business Component و رویه و ترتیب انجام کارها در قسمت Business Workflow جای می گیرند.
Data Access Layer
ارتباط application با داده ها و data base در لایه Data Access Layer انجام می گیرد. و نتیجه حاصل در اختیار لایه های بالاتر و یا سیستم های دیگر قرار می گیرد. داده هائی که یک application از آن ها استفاده می کند می تواند توسط خود سیستم نگهداری شود و یا از داده هائی باشد که در سیستم ها و application های دیگر تولید و نگهداری می شود .
Service Gateway قسمتی است که سرویسی را از لایه BLL در جای دیگر فراخوانی می کنیم .
به طور خلاصه، فرآیند مورد نظر ما این گونه کار می کند:
مزیت های استفاده از معماری لایه ای
1. لایه های بالائی نتوانند مستقیما به داده ها دسترسی داشته باشند
2. از لایه BLL به بالاتر به نوعData Base وابستگی نداشته باشد.
3. و اگر بخواهیم تکنولوژی مورد استفاده در یک لایه را تغییر دهیم ، نیاز به تغییر در هیچ یک از لایه های دیگر نیست.
تذکر این نکته نیز مهم است که ارتباط بین لایه های مختلف با یکدیگر باید در سطح سرویس باشد . و هر لایه تنها از سرویسی که از لایه های دیگر می گیرد اطلاع دارد و به هیچ وجه به چگونگی عملیات درون لایه بالاتر یا پایین تر کاری ندارد.