مهندسی نرم افزار UML ویدیو کلوب بخش دو
مدل های نرم افزاری که قصد بحث در مورد آن ها را داریم عبارتند از :
1- مدل آبشاری : این مدل، فعالیت های اساسی فرآیند تعیین مشخصات، توسعه، اعتبار سنجی و تکامل را در نظر می گیرد و آن ها را به صورت مراحل جدا گانه ای از فرآیند مثل تعیین مشخصات خواسته ها، راحتی نرم افزار، پیاده سازی، تست و غیره نمایش می دهد.
2- توسعه تکاملی : این رهیافت، فعالیت های تعیین مشخصات، توسعه و اعتبارسنجی را جایگذاری (Interleave) می کند. یک سیستم اولیه با استفاده از مشخصات انتزاعی ساخته می شود. سپس این سیستم با ورودیهای مشتری اصلاح می شود تا سیستمی ایجاد شود که خواسته های کاربر را برآورده کند.
3- توسعه سیستم رسمی : در این رهیافت یک مشخصات رسمی ریاضی از سیستم ایجاد می شود و سپس این مشخصات با استفاده از روش های ریاضی، به برنامه تبدیل می شوند. بازبینی مولفه های سیستم با مفاهیم ریاضی صورت می گیرد.
4- توسعه مبتنی بر استفاده مجدد : در این رهیافت فرض می شود که تعدادی از مولفه های سیستم وجود دارند که دوباره قابل استفاده اند. فرآیند توسعه سیستم این مولفه ها را جامعیت می بخشد. در این رهیافت حداکثر بهره را از امکانات و مولفه های آماده و قابل استفاده می بریم. بسیاری از نرم افزارها که بر پایه یک نرم افزار دیگر توسعه می یابند از همین روش استفاده می کنند و برای رسیدن به اهداف تعیین شده ی خود از مولفه های آماده استفاده می کنند. مولفه های نرم افزاری آماده رهیافت توسعه ی یک نرم افزار را سرعت بخشیده و باعث کاهش خطا و باگ در آن می شود.
فرآیندهای مبتنی بر مدل آبشاری و توسعه تکاملی، برای توسعه ی سیستم های عملی به کار می روند. توسعه سیستم رسمی دربسیاری از پروژه ها با موفقیت به کار گرفته شد، اما فرآیندهای مبتنی بر این رهیافت، به ندرت در سازمان ها به کار گرفته می شوند. استفاده مجدد در بسیاری از فرآیندها مرسوم است اما سازمان ها چندان به آن تمایل ندارند. بدیهی است که می توان این رهیافت ها را با هم ترکیب یا از رهیافت ابداعی خود برای توسعه ی یک نرم افزار استفاده نمود.
اولین مدل معروف فرآیند توسعه نرم افزار، رهیافت آبشاری است که از سایر فرآیندهای مهندسی ناشی شده است. مراحل اصلی این مدل، به فعالیت های اساسی توسعه نرم افزار نگاشت می شود.
1- تحلیل و تعریف خواسته ها : خدمات سیستم، محدودیت ها و اهداف از طریق مشورت با کاربر یا کاربران مشخص می شوند. این ها به طور مشروح تعریف می شوند و به صورت مشخصات سیستم مورد استفاده قرار می گیرند.
2- طراحی سیستم و نرم افزار : فرآیند طراحی سیستم ها، خواسته ها را به سیستم های نرم افزاری و سخت افزاری تقسیم می می کند. بدین ترتیب، یک معماری کلی بوجود می آید. طراحی نرم افزار شامل شناسایی و توصیف انتزاع های سیستم نرم افزار و روابط آن هاست.
3- پیاده سازی و تست واحد : در این مرحله، طراحی نرم افزار به صورت مجموعه ای از برنامه ها و یونیت های جدا از هم در می آیند. در تست واحد بازبینی می شود که هر واحد خواسته های مورد نظر را برآورده می کند.
4- جامعیت و تست سیستم : واحدهای اولیه برنامه یا برنامه ها جامعیت پیدا می کنند و به عنوان یک سیستم کامل تست می شود تا تضمین شود که خواسته های نرم افزار برآورده شده اند. پس از تست، سیستم نرم افزار به مشتری تحویل داده می شود.
5- به کارگیری و نگهداری : این مرحله، معمولاً طولانی ترین مرحله چرخه حیات نرم افزار است. سیستم نرم افزاری نصب و به کار گرفته می شود. نگهداری شامل تصحیح خطاهایی است که در مراحل اولیه چرخه حیات برطرف نشدند، شامل بهبود پیاده سازی های واحدهای سیستم و اصلاح خدمات سیستم جهت پاسخگویی به نیازهای جدید نیز است.
در واقع، نتیجه هر مرحله یک یا چند سند است که مورد موافقت قرار گرفته اند. هر مرحله فقط با پایان یافتن مرحله قبلی شروع می شود. در هنگام طراحی، مشکلات مربوط به خواسته ها شناسایی می شوند، در هنگام کدنویسی مشکلات طراحی پیدا می شوندو الا آخر. فرآیند نرم افزار یک مدل ساده ی خطی نیست، بلکه دنباله ای از فعالیت ها تکرار می شوند.
به دلیل هزینه های تولید و پذیرش اسناد، هر تکرار شامل دوباره کاری است و هزینه ی آن بالاست. بنابراین، پس از چند تکرار، باید آن مرحله را پذیرفت و به مراحل بعدی پرداخت. مشکلات احتمالی به مراحل بعدی یا برنامه نویسی واگذار می شود. بدین ترتیب، ممکن است سیستم تمام خواسته های کاربر را برآورده نکند یا ساختار خوبی برای سیستم طراحی نشود.
در هنگام آخرین مرحله چرخه ی حیات (به کار گیری و نگهداری)، نرم افزار به کار گرفته می شود. خطاها و کمبودهای مربوط به خواسته های اصلی نرم افزار مشخص می شوند. خطاهای برنامه و طراحی، ظاهر می شوند و نیاز به عملکردهای جدید شناسایی می گردند. بنابراین، سیستم باید تکامل یابد تا مورد استفاده قرار گیرد. انجام این تغییرات (نگهداری نرم افزار) ممکن است منجر به تکرار مراحل قبلی فرآیند شود.
مشکل عمده ی مدل آبشاری این است که تقسیم بندی پروژه به این مراحل مجزا، اصلاً کار آسانی نیست. معنایش این است که این تقسیم بندی خود به تجزیه و تحلیل بعضاً پیچیده ای نیازمند می باشد. به هر حال، رهیافت آبشاری نشانگر عمل مهندسی است. در نتیجه، فرآیندهای نرم افزار مبتنی بر این رهیافت، هنوز برای توسعه نرم افزار به کار می روند، به خصوص اگر به عنوان بخشی از پروژه مهندسی سیستم های بزرگ باشد.
پ.ن : این مدل، قدیمی ترین مدل توسعه ی نرم افزار است که هنوز هم توسط شرکت ها و گروه های نرم افزاری سراسر دنیا مورد استفاده قرار می گیرد.
روشهای پیاده سازی نرم افزار
UML در جريان شكل گيري روشهاي تحليل سيستم و طراحي شيء گرا بوجود آمده است. تمامي اين روشها عبارت اند از تركيبي از يك زبان مدلسازي گرافيكي و فرآيندي كه مراحل توسعه نرم افزار را توصيف مي كند. بعد از بوجود آمدن UML شركتهاي ايجاد كننده آن دريافتند كه اگر چه مي توان بر سر زبان مدلسازي گرافيكي بوجود آمده به توافق برسند ولي نمي توانند يك فرآيند مشترك و جامع جهت فرآيند پياده سازي نرم افزار ايجاد كنند. در نتيجه UML به يك استاندارد تبديل شد در حاليكه هيچگونه استانداردي براي توصيف فرآيند پياده سازي نرم افزار شكل نگرفت.
به نظر مي رسد كه تكنيكهاي مدلسازي بدون توصيف فرآيندي كه از اين تكنيكها استفاده خواهد كرد معنايي ندارد. روشي كه شما از UML استفاده خواهيد كرد به مقدار زيادي به فرآيندي بستگي دارد كه شما جهت پياده سازي نرم افزار خود استفاده مي كنيد.
اغلب اوقات UML ، در رابطه با RUP يا Rational Unified Process مطرح مي شود. RUP در واقع يك فرآيند يا به عبارت ديگر يك چارچوب فرآيند توسعه نرم افزار مي باشد كه از UML استفاده مي كند. ولي بياد داشته باشيد كه مي توان UML را در روشهاي مختلف توسعه نرم افزار استفاده كرد و RUP تنها يكي از اين روشها مي باشد.
نمودارهای UML
UML2 داراي 13 نمودار رسمي مي باشد. در جدول زير مي توانيد انواع اين نمودارها را همراه با نسخه اي از UML كه ارائه شده اند را ببينيد. علي رقم اينكه هر كدام از اين نمودارها بصورت مجزا قواعد و نمادهاي مخصوص به خود را دارند ولي در اصل نمودارهاي UML قابليت انعطاف زيادي داشته و مي توان از انواع نمادها و نمودارها در نمودارهاي ديگر استفاده كرد. استاندارد UML بيان مي كندكه از عناصر مخصوص به يك نمودار تنها مي توان در آن نوع نمودار خاص استفاده كرد ولي اين يك قانون كلي نيست.
|
نمودار
|
هدف نمودار
|
نسخه
|
|
Activity
|
نمايش نحوه رفتار و رويه اجراي يك كار
|
UML 1
|
|
Class
|
نمايش كلاس ، مشخصات كلاس و روابط بين كلاسها
|
UML 1
|
|
Communication
|
تراكنشهاي بين آبجكتها را نمايش مي دهد و تأكيد آن بر ارتباط بين اشياء مي باشد
|
UML 1
|
|
Component
|
ساختار و نحوه ارتباط بين مؤلفه ها
|
UML 1
|
|
Composite structure
|
تجزيه ساختاري يك كلاس در حال اجرا
|
New to UML 2
|
|
Deployment
|
نحوه استقرار فيزيكي سيستم
|
UML 1
|
|
Interaction overview
|
تركيب نمودار فعاليت و نمودار توالي
|
New to UML 2
|
|
Object
|
مثالي براي نحوه پيكربندي نمونه ها
|
Unofficially in UML 1
|
|
Package
|
ساختار سلسله مراتبي نحوه كامپايل نرم افزار
|
Unofficially in UML 1
|
|
Sequence
|
تعامل بين اشياء ، تأكيد اين نمودار بر توالي انجام كارها است
|
In UML 1
|
|
State machine
|
چگونه رويدادها يك شيء را در طول دوره عمرش تغيير مي دهند
|
In UML 1
|
|
Timing
|
تعامل بين اشياء ، تأكيد اين نمودار بر زمان مي باشد
|
New to UML 2
|
|
Use case
|
نمايش نحوه تعامل كاربران با سيستم
|
In UML 1
|