كارگاه مهندسي نرم افزار مدرس : شهراد رضايي

متدولوژي قانونمند كردن توليد نرم افزار براي جلوگيري از بروز مشكل فرمولي را كه براي توليد و توسعه نرم افزار ارائه مي دهند را متدولوژي مي گويند. يك متدولوژي چرخه حيات نرم افزار را مشخص مي كند .

انواع متدولوژی متدولوژی سنتی متدولوژی فرآیند گرا متدولوژی ساختمان داده متدولوژی مدل سازی اطلاعات متدولوژی شیءگرا

چرخه حيات توليد و توسعه نرم افزار يا SDLC مخفف System Development Life Cycle مي‌باشد . مراحلي را كه طي توليد و توسعه نرم افزار به كار مي‌روند را چرخه حيات توليد و توسعه نرم افزار مينامند . System Development Life Cycle

انواع چرخه‌هاي حيات توليد و توسعه نرم افزار چرخه حيات سيستم‌هاي قديمي يا TLC چرخه حيات سيستم‌هاي شي گرا يا OODLC

چرخه حيات سيستم‌هاي قديمي يا TLC TLC مخفف Traditional Life Cycle است . در گذشته چون برنامه ها به صورت فرايند گرا يا Process Oriented نوشته مي‌شدند از روش TLC براي توليد و توسعه نرم افزار استفاده مي شد . در اين روش بيشتر از نمودارهاي DFD و ERD استفاده مي‌شد

مدلهای مورد استفاده در TLC روش حلزونی (Spiral) تولید پیش الگو (Prototyping) RAD SCRUM DSDM

مدل آبشاري يا Water Fall مدل آبشاري از معروف ترين متدولوژي هاي TLC است كه كاربرد زيادي در گذشته داشته و مبناي اساسي براي مدل هاي شي گرا هم همين مدل WaterFall است .

System Engineering يا مهندسي سيستم اولين فاز از مدل آبشاري مي باشد مثلا شركتي درخواست ايجاد وبسايتي براي معرفي كالاهاي خود را دارد . در مرحله مهندسي سيستم ما بايد كليات سيستم مثلا اينكه از PHP استفاده كنيم يا از ASP يا پايگاه داده ما Access باشد يا Oracle  باشد يا SQL Server  كدام براي ما صرفه بيشتري دارد و بسياري از سوالات ديگر كه پاسخ آنها بسته به سيستم درخواستي دارد را بررسي مي كنيم . مثلا بحث هاي امنيتي ، هزينه ها و سرعت و مسائل ديگر همه و همه مي توانند در پاسخ ارائه شده تاثير گذار باشند . امروزه مهندسي سيستم با عنوان IT Master Plan در پروژه ها مطرح مي شود و بخش مهم و اساسي سيستم را تشكيل مي‌دهد. IT Master Plan به اين معني است كه سيستم اطلاعاتي از ديد سخت افزار و نرم افزار بررسي شود و نقشه سيستم به طور واضح و روشن مشخص گردد. Requirement Analysis فاز دوم Requirement Analysis يا آناليز نيازمنديها مي‌باشد . در واقع اين قسمت از نرم افزار به جمع آوري نيازهاي كاربران مي پردازد. يعني ما در اين فاز بيشتر به دنبال "چه؟" يا "What?" هستيم.  يعني بعد از اين فاز نيازهاي كاربران بايد مشخص شده باشد . جمع آوري نيازمنديها يكي از اساسي ترين فعاليت ها در فرايند توليد و توسعه نرم افزار است كه هر چه اين شناخت از نيازمنديها بيشتر باشد تغييرات در سيستم كمتر خواهد بود. Design Design يا طراحي فاز سوم از مدل آبشاري مي باشد . خروجي فاز قبل يعني Requirement Analysis مجموعه اي از نيازهاي كاربران بود كه نشان مي داد كاربران از سيستم چه مي خواهند در فاز Design بايد به دنبال "چگونه؟"  يا "Who?" برويم . به اين معني كه "سيستم بايد چگونه در جهت رفع نيازمنديها گام بردارد؟" يا "بايد چگونه كاركند تا آنچه كابران نياز دارند را برآورده كند؟" در واقع فاز Design در مورد برآورده كردن نيازها صحبت مي كند. مثلا در يك مثال به اين نتيجه رسيده ايم كه كاربران نياز به كار با يك سري اشيا دارند . حال بايد بگوييم اين مجموعه از چه نوعي بايد باشد . آيا بايد به صورت صف پياده سازي شود ؟ آيا نياز است به صورت پشته پياده سازي شود ؟ با آرايه باشد بهتر است ؟ يا با ليست هاي پيوندي ؟ و بسياري از موارد ديگر اين چنيني ! Construction Construction يا مرحله ساخت فاز چهارم در مدل آبشاري مي باشد . حال كه مسائل طراحي حل شد و ما نحوه پياده سازي را هم مشخص كرديم نياز داريم كه عملا مسائل طراحي را پياده سازي نماييم. فاز Construction در واقع آنچه را در فاز Design تشخيص داده شده است ، به كد تبديل مي كند . در يك نگاه كلي مي توان  فاز Design را فازي دانست كه سيستم روي كاغذ يا ابزارهاي مستند سازي پياده مي شود و تبديل آن به سيستم واقعي در فاز Construction انجام مي گيرد. فاز پنجم از مدل آبشاري مرحله Testing است در اين مرحله سيستمي كه ساخته شده است را از لحاظ كمي و كيفي آزمايش مي كنند . در فاز Testing سعي مي شود قبل از تحويل سيستم به مشتري مشكلات يافت شوند و قبل از نصب برنامه برطرف گردند. در اين قسمت به بررسي انواع خطاها مي پردازيم : دسته اول خطاها Error ها هستند . Error ها اتفاقاتي مي باشند كه كل سيستم را از كار مي اندازند . مثلا در يك ماشين حساب تقسيم بر صفر منجر به از كار افتادن عمليات كل سيستم مي شود. دسته ديگر Bug ها هستند . Bugها اتفاقاتي مي باشند كه كل سيستم را از كار نمي اندازند ولي سيستم را با مشكل مواجه مي كنند . در واقع Bug ها فقط قسمتي از سيستم را مختل مي كنند نه تمام آن را . مثلا عمل سرريز شدن در بعضي عمليات محاسباتي يك Bug است. دسته ديگر Warning ها هستند اين ها در ظاهر خطا مي باشند اما در روند سيستم تاثيري ندارند . بعنوان مثال اگر قرار باشد در يك TextBox حتما رشته وارد شود اما ما عدد وارد كرده ايم در هر حال مجموعه اي از ارقام يك رشته است، پس اين نوع خطا نيست بلكه يك Warning را بايد ايجاد نمايد. Installation فاز ششم در مدل آبشاري مرحله Installation است . در مرحله نصب يا Installation سيستمي كه تست شده است را بايد به مشتري يا Client تحويل دهيم آن را براي او نصب كنيم و در صورت لزوم آموزش لازم را به نيروهايي كه قرار است با سيستم كار كنند يعني همان End User ها ارائه دهيم . Maintenance   آخرين فاز از فازهاي هفتگانه مدل آبشاري فاز Maintenance يا نگهداري است . اين فاز طولاني ترين قسمت چرخه عمر يك پروژه نرم افزاري است . همچنين پرهزينه ترين قسمت هم مي باشد . در اين مرحله اگر نيازهاي جديدي براي كاربران ايجاد شد ، Developer بايد اين نيازمندي ها را در برنامه لحاظ كند . اگر Error ، Bug و يا هر مشكل ديگري پيش آمد بايد از طرف Developer برطرف گردد .

چرخه حيات سيستم هاي شي گرا يا OODLC اين نوع چرخه حيات بعد از بوجود آمدن روش جديد برنامه نويسي يعني روش شي گرا بوجود آمد. زبانهايي مانند C# ، JAVA و C++ و بسياري ديگر از زبانهاي برنامه نويسي كه قابليت پياده سازي خواص Object Oriented (شي گرايي) را دارا هستند امروزه از مهمترين زبانهاي برنامه نويسي دنيا محسوب مي شوند .

مهمترين عامل برتري روشObject Oriented نسبت به روش Process Oriented استقلال هويتي دارند . يعني هر بخش عملا از ساير بخشها مجزا است . پايداري سيستم يا System Stability است. به اين معني كه سيستم در مقابل تغييرات مقاومت داشته باشد . يعني پيدايش نيازمنديهاي جديد منجر به اين نشود كه سيستم نياز به تغييرات كلي داشته باشد. قابليت نگهداري يا Main ability : به دليل جدا بودن اشيا ، نگهداري سيستم پس از ارائه به مشتري نيز به راحتي امكان پذير است . مثلا ورژن هاي جديد برنامه هايي كه با شماره هاي پشت سر هم وارد بازار مي شوند به همين دليل است .

قابليت استفاده مجدد اجزا يا Reusable Component داشتن ديد واقعي به دنياي اطراف. قابليت دسترسي به اطلاعات و داده ها دوستانه بودن از نظر كاربر يا User Friendly بودن برنامه.

خواص اساسی متدولوژی شیءگرا روش های متداول برای سازماندهی تجرید کپسوله کردن یا مخفی سازی اطلاعات وراثت چند شکلی ارتباطات پیامی همروندی قابلیت استفاده مجدد 1- همان کلاسها و اشیا - صفات

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

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

وراثت وراثت، روشی برای بیان شباهت ها است. به عنوان مثال“ برای مدل سازی انسان های یک دانشگاه می توانیم آنها را به اشیاء“ دانشجو، استاد و کارمند“ تفکیک کنیم. اما برخی خصوصیات این اشیاء، مشابه یکدیگر می باشند، نظیر: ” نام، نام خانوادگی، تلفن و. .“ برای اجتناب از تکرار خصوصیات مشترک اشیاء کلاسی به نام ” انسان“ ایجاد می کنیم که صفات آن همان صفات تکراری سه کلاس اصلی دانشگاه است. سپس هر یک از آن سه کلاس، تمام خصوصیات این کلاس جدید را به ارث می گیرند.

شکل وراثت

5. چند شکلی چند شکلی یا چند ریختی، به معنای یک چیز بودن و چند شکل داشتن است. مثل آب که دارای چند شکلِ جامد، مایع و گاز ظاهر می شود.

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

7. همروندی همروندی، اجرای هم زمان دو یا چند فعالیت سیستم است. برای مثال در یک چاپگر، می توانیم هم زمان با چاپ نامه مورد نظرمان، نشانه(آرم) شرکت را نیز به عنوان زمینه نامه و هم زمان با متن نامه به چاپ برسانیم.

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

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

مدل up همانگونه كه در روش هاي قديمي يك مدل خاص مثل مدل آبشاري را بررسي كرديم و مزايا و معايب آن را بررسي نموديم در اين بخش نيز از ميان مدل هاي موجود در سيستم هاي شي گرا به بررسي مدل معروف و نامي UP مي پردازيم .

مخفف Unified Processing است

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

خلاصه

فازها آغاز ( Inception ): در انتهای این فاز تصمیم گرفته ایم که آیا پروژه را آغاز کنیم یا خیر و این تصمیم پس از تولید یک Business Case گرفته می شود. اجرا ( Elaboration) : در انتهای این فاز اکثر نیازمندیهای باقی مانده شناسایی شده اند و یک معماری مانع (sound architecture) برای نرم افزار بناشده است. ساخت ( Construction): در این فاز با کار روی معماری حاصل از فاز قبل و تولید یک سری افزایش بر روی نرم افزار در طی تعدادی تکرار، نسخه اول محصول برای اجرا در محیط کاربر ساخته می شود. انتقال ( Transition): نرم افزار ساخته شده به سایت مشتری انتقال داده می شود و بررسی میگردد که آیا کاملا نیازمندیهای مشتری برطرف شده است؟ مستندات کاربری نیز تحویل می شود.

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

دیسیپلینهای فرایند تحلیل و طراحی: پیاده سازی: طراحی سیستم نهایی بر اساس نیازمندیها ایجاد یک معماری قوی برای سیستم تطبیق طراحی و پیاده سازی (وارد ساختن ملاحظات خاص پیاده سازی )، ایجاد یک طراحی کارآ پیاده سازی: لایه بندی زیرسیستم های پیاده سازی کلاسها و موجودیتها پیاده سازی می شوند (به شکل فایلهای source، باینریها، اجرایی ها و ...) انجام آزمون واحد بر روی مولفه ها مجتمع کردن مولفه ها و ایجاد یک سیستم اجرایی

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

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

تکرار Iteration)) تکرار یک گذر کامل از همه Disciplineها شامل حداقل تشخیص نیازمندیها، تحلیل و طراحی، پیاده سازی و آزمون است. تکرار مانند یک پروژه کوچک مدل آبشاری است

نمودار هاي Rational Rose

Use-case

Class diagram

Sequence diagram

Colaboration Diagram

State digram

Activity diagram

Physical diagrams