زبان مدلسازی یکنواخت (2)


نمودارهای UML :

در این بخش به معرفی نمودارهای UML  می پردازیم و علاقمندان به آشنایی بیشتر را ، دعوت به مطالعه مراجع معرفی شده ، می نمائیم :

1. نمودار کلاس ( Class Diagram ) :

این نمودار ، کلاسها ، واسطه ها و همکاری و روابط بین آنها را نمایش می دهد . و نمودارهای اصلی و مرکزی UML می باشد که بیان کننده ساختار ایستای سیستم    نرم افزاری می باشند .

2. نمودار اشیاء ( Object Diagram ) :

این نمودار ، اشیاء سیستم و روابط بین آنها را نمایش می دهد . در واقع یک تصویر لحظه ای از نمودار کلاس می باشد .

3. نمودار مورد کاربرد ( Usecase Diagram ) :

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

4. نمودارهای تعامل ( Interaction Diagram ) :

این نمودارها ، بیان کننده تعامل هستند که شامل اشیاء مختلف و روابط بین آنها و همچنین پیغامهایی که بینشان رد وبدل می شود می باشند . این نمودارها جنبه های پویای یک سیستم را مدل می کنند و خود بر دو نوعند : نمودار توالی                          ( Sequence Diagram ) که ترتیب زمانی تعامل ها را نشان می دهد و نمودار همکاری ( Collaboration Diagram ) که تأکید بر نمایش ساختاری تعامل ها دارد .

5. نمودار حالت ( Start chart Diagram ) :

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

6. نمودار فعالیت ( Activity Diagram ) :

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

7. نمودار اجزاء ( Component Diagram ) :

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

8. نمودار به کارگماری ( Deployment Diagram ) :

پیکربندی گره های پردازشی زمان اجرا را نمایش می دهد که برای مدل کردن     جنبه های ایستای به کار گماری یک معماری بکار می رود . همچنین نمایش دهنده ی اجزای استفاده شده زمان اجرا مثل کتابخانه های DLL ، فایل های اجرایی ، کدهای مبدأ و روابط بین آنها می باشد . البته این نمودارها تمام نمودارهای UML نیستند بلکه بسته به نیاز و با کمک ابزارهای Case می توان نمودارهای دیگری نیز تعریف و استفاده کرد .

در پروژه چهار فاز را پشت سر می گذاریم :  Inception  ( شناخت )  ،  Elaboration  ( مهارت ) ، Construction ( ساختار ) و Transition ( انتقال ) . Inception شروع پروژه است . ما اطلاعات را جمع آوری کرده و مفهوم و برداشت کلی را اثبات          می نماییم . پایان Inception تصمیم درباره انجام / عدم انجام پروژه است . در Elaboration  ، بطور مفصل use case ها توضیح داده شده و تصمیمات معماری گرفته می شوند . Elaboration  شامل مقداری تجزیه و تحلیل ، طراحی ، کد نویسی و تست می باشد . Construction ( ساختار ) جایی است که قسمت عمده کد نویسی انجام شده است . Transition آمادگی و تولید نهایی سیستم برای کاربران است .

Inception ( شناخت ) :

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

فاز Inception  پروژه به طور اساسی دنباله دار و غیر تکراری است . حالتهای دیگر چندین بار در طول پروژه تکرار می شوند . به دلیل اینکه در حقیقت پروژه فقط یکبار می تواند شروع شود ، Inception  نیز فقط یکبار روی پروژه انجام شده است . به همین دلیل ، بیش از یک وظیفه در Inception  می ماند . تولید یک طرح تکراری ، یک طرح تکراری طرحی است که توضیح می دهد چه use case  در طول تکرار انجام     می شود . اگر ما در طول تکرار ده تا use case را پیدا کنیم ، ممکن است یک نقشه تکراری مانند این را بکشیم .

Inception One                            Use Case 1,5,6

Inception Two                            Use Case 7,9

Inception Three                          Use Case 2,4,8

Inception Four                            Use Case 3,10

طرح به ما می گوید که کدام use case اول انجام شده است . مشخص کردن این طرح نیازمند این است که به وابستگیهای بین  use case  نگاه کنیم و براساس آن برنامه ریزی نماییم . اگر برای کاربران use case 5  نیاز به use case 3 داشته باشد ، پس طرح توضیح داده شده بالا شدنی و امکان پذیر نیست زیرا use case 3  باید در دور 4 اجرا شده باشد ، در حالی که use case 5 در اولین دوره قرار دارد . ما باید طرحمان را تنظیم کنیم تا با وابستگیها وفق داده شود .

Elaboration ( مهارت ) :

فاز مهارت ( Elaboration ) پروژه شامل مقداری طراحی ، تجزیه و تحلیل و طرح معماری است . همراه با طرح تکرار ، فاز مهارت برای هر use case در تکرار جاری انجام می شود . فاز مهارت شامل چندین جنبه از یک پروژه است . مانند کد کردن ، اثبات مفاهیم ( proofs-of-concept ) ، تولید نمونه های آزمایشی و ایجاد تصمیمات طراحی .

از کارهای اصلی فاز Elaboration  تکمیل use case است . درخواستهای سطح پائین یک use case  شامل جریان پردازش در طول use case  می باشد ، چه عامل هایی با    use case درخواست شده اند و نمودارهای Interaction  جریان پردازش را به صورت گرافیکی نشان می دهد و کلاً هر حالتی که تغییر می کند ممکن است در زمان          use case  اتفاق بیفتد . در خواستها ، به شکل use case های کامل و با جزئیات ، در یک سند جمع شده اند که یک Software Requirement Specification (SRS )             ( مشخصات درخواست نرم افزار ) نامیده شده است . SRS شامل همه جزئیات درخواستهای سیستم می باشد . کارهای دیگری در فاز مهارت ( Elaboration ) انجام می شود مانند اصلاح تخمینهای اولیه ، بررسی کیفیت SRS  و مدل Use Case  و بررسی کردن خطرها .

Rational Rose  می تواند به مدل Use Case کمک کند و نمودارهای Sequence  ، Collaboration را ایجاد کند تا جریان گرافیکی پردازش را نشان دهد . نمودارهای Class ، آبجکت هایی که ساخته شده اند یا در طول فاز مهارت ( Elaboration ) طراحی شده اند را نشان می دهد . فاز مهارت ( Elaboration ) زمانی تمام شده است که use case ها کاملاً وارد جزئیات شده اند و بوسیله کاربران پذیرفته شده اند ، اثبات مفاهیم ( proofs-of-concept ) کامل شده اند تا شدت خطرها را کاهش دهند و نمودارهای Class کامل می باشند . به عبارت دیگر این فاز زمانی کامل است که سیستم طراحی شده ، بازبینی شده و آماده است تا برنامه نویسان آن را تولید نمایند .

 

 

Construction ( ساختار ) :

Construction ( ساختار ) به روند تولید و تست نرم افزار بر می گردد . مانند Elaboration این فاز برای هر مجموعه از use case ها ، در یک بار تکرار کامل شده است . کارهای فاز Construction شامل مشخص کردن درخواستهای ثابت ، تولید   نرم افزار و تست نرم افزار می باشد . از آنجایی که نرم افزار در طول فاز Elaboration بطور کامل طراحی شده است ، Construction نباید درگیر تصمیمهای طراحی زیادی باشد . این به گروه پروژه کمک می کند تا تولید موازی را به انجام رسانند . تولید موازی به این معنی است که چند برنامه نویس بتوانند بر روی     آبجکت های مختلف نرم افزاری کار کنند و بدانند که کل سیستم با هم جمع خواهد شد . در  Elaboration، ما آبجکت هایی را در سیستم طراحی کردیم و اینکه آنها چگونه بر روی هم اثر می گذارند . Construction فقط موضوع گذاشتن آن طرح در action است ، تا تصمیمات طراحی جدید که می توانند آن فعل و انفعالات را تغییر دهند ، ایجاد شوند . مزیت دیگر مدل کرد سیستم این است که Rational Rose می تواند کد اولیه را برای سیستم تولید کند .

Transition ( انتقال ) :

فاز Transition زمانی است که محصول نرم افزاری کامل شده ، به سمت اجتماع کاربر بر می گردد . کارها در این فاز شامل کامل کردن محصول نرم افزاری نهایی ، تکمیل تست تأیید نهایی ، کامل کردن مستند سازی کاربر و فراهم کردن آموزش  برای کاربر می باشند . باید مشخصات درخواست نرم افزار                                         ( Software Requirement Specification )  ، نمودارهای Use Case ، نمودارهای Class ، نمودارهای Component و نمودارهای Deployment بروزرسانی شده باشند تا تغییرات نهایی را منعکس کنند . مهم است که این مدلها با محصول نرم افزاری همزمان شده باشند زیرا مدلهایی که یکبار در محصول نرم افزاری استفاده خواهند شد به مد پشتیبانی می روند . چند ماه بعد از اتمام پروژه ، این مدلها در کمک به ارتقاء نرم افزار ، گرانبهاتر خواهند بود .

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

 

 

  1. هنوز دیدگاهی داده نشده است.
  1. No trackbacks yet.

پاسخی بگذارید

در پایین مشخصات خود را پر کنید یا برای ورود روی شمایل‌ها کلیک نمایید:

نشان‌وارهٔ وردپرس.کام

شما در حال بیان دیدگاه با حساب کاربری WordPress.com خود هستید. بیرون رفتن / تغییر دادن )

تصویر توییتر

شما در حال بیان دیدگاه با حساب کاربری Twitter خود هستید. بیرون رفتن / تغییر دادن )

عکس فیسبوک

شما در حال بیان دیدگاه با حساب کاربری Facebook خود هستید. بیرون رفتن / تغییر دادن )

عکس گوگل+

شما در حال بیان دیدگاه با حساب کاربری Google+ خود هستید. بیرون رفتن / تغییر دادن )

درحال اتصال به %s

%d وب‌نوشت‌نویس این را دوست دارند: