مهندسی نرم افزار و روشهای آن
چکیده
با توجه به نیاز روز افزون به استفاده از کامپیوتر و ضرورت توسعه و فراگیری علوم و فنون مربوط به آن به ویژه در زمینه مهندسی نرم افزار و با توجه به فقدان مطالب و منابع در این زمینه، بر آن شدیم تا گامی هرچند کوچک اما سازنده در این زمینه برداریم. مطالبی که پیش روی دارید حاصل تحقیقات مطالعات و گردآوری نکات مهم و اساسی در زمینه توسعه مهندسی نرم افزار به روش RUP می باشد. امید است که حاصل تلاش مان موثر و مفید واقع شود.
فصل اول
مهندسی نرم افزار وروش های آن
1-1 مهندسی نرم افزار چیست ؟
مهندسی نرم افزار، مدیریت برای به نظم درآوردن وقاعده مند نمودن وابستگی ها وارتباطات همه جنبه های محصول نرم افزاری که درتمامی مراحل سیستم شنا سایی وتعیین می گردد ، می باشد .
درواقع مهندسی نرم افزارفرایند تولید نرم افزار براساس فهم مسائل ومشکلات ، دستیابی به راه حل ها ودستیابی به تئوریها ، روش ها وابزارهای مورد نیاز ودرانتها رسیدن به هدف مطلوب می باشد .
مهندسی نرم افزارباید درطول ساخت ، نگهداری توسعه وانفصال یک نرم افزار برهمه عملکردها نظارت داشته باشد .
2-1 ساخت یافتگی ومهندسی نرم افزارساخت یافته
در رهیافت طراحی نرم افزار بر اساس روش ساحت یافته، ابتدا به مسئله در حالت کلی نگاه می شود، آنگاه مسئله به قسمت های کوچکتر شکسته می شود، این کار آنقدر تکرار می گردد تا مسائل خرد شده به اندازه کافی قابل فهم و ساده باشند. این مراحل به تجزیه عملیاتی معروف است. بیشتر اجزاء (توابع) در این روش نیاز به داده ها دارند که در سیستم عملیات در بانک های اطلاعاتی نگهداری می شوند. در واقع در این روش داده ها و توابع عملیاتی از هم تفکیک می گردند. پس از حل مسائل کوچکتر و ترکیب آنها با هم، مسئله اصلی قال حل خواهد بود.
مشکل اساسی در این رهیافت این است که اگر مسائل پیچیده باشد، سیستم در نگهداری اطلاعات با مشکل مواجه می شود. اگر در این سیستم ها نیاز باشد که تغییری صورت گیرد، این تغییر در مکان های زیادی باید اعمال گردد. در این صورت مشکلات تقریباً بزرگی به وجود می آید.
مهندسی نرم افزار ساخت یافته نیز بر اصول ذکر شده فوق مبتنی است. از جمله متدلوژی های مهندسی نرم افزار می توان به دو روش
( (structured Systems Analysis & Design Method SSADM روش تحلیل و طراحی سیستم های ساخت یافته و (Jackson System Development) JSD توسعه سیستم جکسون، اشاره نمود.
3-1 شی ء گرایی و مهندسی نرم افزار شیء گرا
از دید شیء گرایی داده ها و توابع به هم مرتبط هستند و در یک ماژول قرار می گیرند. در واقع هریک از این ماژول ها که مجموعه داده ها و توابع هستند که شیء نامیده می شوند. اشیاء در دنیای واقعی نیز می توانند به وسیله دو چیز مشخص گردند (مشخصه و رفتار).
اصول بنیادی که در شیء گرایی با آن مواجه هستیم، اشیاء، کلاس ها و وراثت می باشند. ایده شیء گرایی نیز به دنیای مهندسی نرم افزار راه یافته است و بر این اساس روش های مختلف مهندسی نرم افزار به وجود آمده است. که از آن جمله می توان به موارد ذیل اشاره نمود :
- (object Modeling Technique) OMT
- (Real – time Object – Oriented Modeling ) ROOM
-Object – Oriented Software Engineering ) OOSE)
-(Unified Modeling Language) UML
بدلیل آنکه از UML در مراحل توسعه نرم افزار (RUP) استفاده می گردد، در این قسمت جا دارد که در مورد UML توضیحات بیشتری بدهیم.
4-1 معرفی Unified Modeling Language
در میانه دهه نود، سه روش وجود داشت که از بقیه قویتر به نظر می رسید. این سه زبان که شروع به همگرایی کرده بودند، هریک دارای عناصری از دو روش دیگر نیز بود و دارای توانایی های منحصر بفردی نیز بودند :
- Booch برای طراحی و پیاده سازی عالی به نظر می رسید. گرچه روش بوچ خیلی قوی بود ولی علائم زبان به سختی درک می شد.
- OMT (تکنیک مدل سازی اشیاء) برای تجزیه و تحلیل بسیار عالی بود و بهترین روش برای سیستم های اطلاعاتی دارای داده های حساس به نظر می رسید.
- OOSE (مهندسی نرم افزار به روش شیء گرا) به عنوان یک مزیت به مدل Use Case معروف است. Use Case تکنیک توانمندی برای درک رفتار کل سیستم هستند. (محدوده ای که شیء گرایی به طور سنتی در آن ضعیف بود)
در سال 1994 Gim Rumbaugh تاسیس کننده OMT و در سال 1995 Ivar Jacobson بنیانگذار OOSE هم به گروه Booch در شرکت Rational پیوست. بدین ترتیب گروه سه نفر بوچ ، رامبو و جاکوبسن مدل یکپارچه UML را به وجود آوردند.
UML یک زبان استاندارد برای مدل سازی اشیاء در توسعه سیستم های شی ء گرا می باشد. UML از ترکیب و اتحاد سه متدلوژی و طراحی شیء گرای فوق به وجود آمده است.
هدف اصلی UML ایجاد یک زبان مشترک برای مهندسان و تولیدکنندگان نرم افزار در تحلیل و طراحی سیستم های شیء گراست.
5-1 تصورات غلط در رابطه با Rational Unified Process
علی رغم آنکه اغلب افراد تصور می کنند RUP یک متدلوژی و یا روش مهندسی نرم افزار است، باید اظهار داشت که این تصور و برداشت کاملاً نادرست می باشد.
RUP خود یک مدل از مهندسی نرم افزار است که بر تکرار و توسعه استوار است و هریک از متدها می تواند در قالب این مدل تکرار و توسعه نقش بگیرد. چنانچه قبلاً اظهار شد UML به عنوان زبان یکپارچه ساز و روشی شی ء گرا در مدل RUP استفاده می گردد. در واقع RUP استفاده می گردد. در واقع RUP رویکردها، وظایف و مسئولیت ها را در یک سازمان توسعه یافته نظام دهی می کند و هدف آن تضمین تولید محصول نرم افزاری خروجی با کیفیت بالا و منطبق بر نیازمندی های کاربران در زمان و هزینه پیش بینی شده می باشد. در واقع RUP پروسه تولید است و توسط شرکت نرم افزاری Rational پشتیبانی می گردد.
-3 فاز Elaboration
هدف از این فاز تعیین خط مشی معماری سیستم برای تهیه یک اساس و بنیان پایدار برای طراحی و پیاده سازی در فاز بعدی یعنی فاز Constrution می باشد. معماری سیستم به واسطه توجه نیازمندی های پایدار و تخمینی از ریسک ها توسعه و رشد می یابد.
دید کلی در ابتدای این فاز (Elaboration) شامل موارد زیر می باشد :
اطمینان از پایداری و ثبات معماری، نیازمندی ها و طراح ها به اندازه کافی و کاهش خطرات و ریسک ها در مورد تعیین هزینه ها و زمان تا حد امکان تا فرآیند توسعه، باید تکامل یابد. برای بیشتر پروژه ها گذر از این گلوگاه ها و بدست آوردن مفاهیم شفاف نیاز به صرف هزینة بالا دارد. گاهی اوقات هم برخی از معمارها و ساختارها ذاتاً دارای خطرات و ریسک های زیادی هستند.
شناسایی همه ریسک های مهم وابسته به ساختار و معماری پروژه
پایداری خط مشی های معماری که برگرفته از شناسایی سناریوهای اساسی و مهم معماری هستند که عموماً همراه با ریسک ها و خطرات زیادی می باشند.
برای آنکه بتوان یک نمونه با کیفیت مناسب برای Componentها ساخت و همچنین از ریسک های احتمالی جلوگیری نمود باید موارد زیر را مورد توجه رار داد.
1- به وجود آوردن تعادل بین طراحی و نیازمندیها
2- استفاده مجدد از کامپوننتها
3- امکان استفاده برنامه برای مشتریان و کاربران ناحیه سیستم
نشان دادن معماری خط مشی هایی که نیازمندی های سیستم را در یک محدوده زمانی و به همراه هزینه های مناسب و معمول، پشتیبانی کند.
برپایی یک محیط حمایتی، به منظور دستیابی به این ذهنیت مقدماتی، خیلی مهم است که محیطی را فراهم نماییم که پروژه ما را حمایت و پشتیبای کند؛ این کار مستلزم خلق یک حالت توسعه یافته و به وجود آوردن نمونه ها و راهنماها و فراهم نمودن ابزارهای مناسب می باشد.
فهرست مطالب
عنوان صفحه
فصل اول
مهندسی نرم افزار و روشهای آن 7
1-1 مهندسی نرم افزارچیست ؟ 7
2-1 ساخت یافتگی ومهندسی نرم افزارساخت یافته 7
3-1 شیء گرایی ومهندسی نرم افزار شیء گرا 8
4-1 معرفی Unified Modeling Language 8
5-1 تصورات غلط دررابطه با Rational Unified Process 9
فصل دوم
مقدمه ای بر( RUP)RationalUnified Process 11
1-2 RUP چیست ؟ 11
2-2 اصول ضروری RationalUnified Process 11
3-2 RUP وچرخه تکرار 12
4-2 فازها، اهداف ونکات اصلی 14
- فازشروع ( Inception ) 14
- فازشناخت ( Elaboration ) 15
- فازساخت (Constructin) 15
- فازانتقال ( Transition ) 15
5-2 نکات اصلی 15
- چهارعنصراصلی مدل سازی 15
6-2 نقش ها، فعالیت ها ومحصولات وجریان های کاری 16
- نقش ها(Roles ) 16
- فعالیت ها(Activites) 16
- محصولات (Artifacts ) 17
- جریان های کاری (Workflows ) 17
7-2 عناصردیگرموجود در RUP 17
8-2 ساختارایستای RUP 18
9-2 اصول RUP (جریان کاری ) 18
10-2 تعریف کلی RUP 19
11-2 چگونه می توان از RUPنهایت استفاده راکرد 19
12-2 مواردضروری دریک پروژه RUP 20
1-12-2 توسعه دید ونگرش 20
2-12-2 مدیریت برای اهداف 21
3-12-2 شناسایی وامکان سنجی ریسک ها 22
4-12-2 عوامل مورد پیگیری 22
5-12-2 امتحان کردن حالت تجاری 22
6-12-2 طراحی معماری قطعات سیستم 23
7-12-2 مراحل ساخت وآزمایش محصول 24
8-12-2 تصحیح وبازبینی نتیجه ها 24
9-12-2 مدیریت وکنترل تغییرات 24
10-12-2 مهیا کردن پشتیبانی ازکاربر 25
13-2 چرخه اصلی Rational Unified Process 25
1-13-2 تصورغلط 25
2-13-2 نکته مهم 26
3-13-2 جریان های کاری غیرثابت 27
فصل سوم
فازهای RUP 28
1-3 مقدمه 28
2-3 فاز Inception 28
1-2-3 فعالیت های لازم وضروری درفاز Inception 29
2-2-3 حیاتی ترین نکات (گلوگاه ها) درچرخۀ حیات Inception 30
3-2-3- ارزیابی معیارها وضوابط 30
4-2-3 خروجی های الزامی فاز Inception 31
5-2-3 طرح توسعه نرم افزار (Software Development Plan ) 31
6-2-3 خروجی های اختیاری فاز Inception 33
3-3 فاز Elaboration 33
1-3-3 فعالیت های ضروری درفاز Elaboration 34
2-3-3 ساختارچرخه حیات فاز Elaboration 35
3-3-3 ارزیابی معیارها 35
4-3-3 محصولات وخروجی های الزامی این فاز 36
5-3-3 خروجی های اختیاری این فاز 38
4-3 فازساخت Construction 39
1-4-3 ذهنیت مقدماتی ازفاز Constructin 39
2-4-3 فعالیت های ضروری درفاز Constructin 40
3-4-3 نکات مهم درفاز Constructin 40
4-4-3 معیارارزیابی 40
5-4-3 خروجی های الزامی فاز Constructin 41
6-4-3 خروجی های اختیاری فاز Constructin 42
5-3 فاز انتقال Transition 42
1-5-3 فعالیت های ضروری فاز Transition 44
2-5-3 ارزیابی معیارها 44
3-5-3 خروجی های فاز Transition 45
منابع و مأخذ 47