مقاله مقدمه ای بر UM1

توجه : به همراه فایل word این محصول فایل پاورپوینت (PowerPoint) و اسلاید های آن به صورت هدیه ارائه خواهد شد

  مقاله مقدمه ای بر UM1 دارای ۶۳ صفحه می باشد و دارای تنظیمات در microsoft word می باشد و آماده پرینت یا چاپ است

فایل ورد مقاله مقدمه ای بر UM1  کاملا فرمت بندی و تنظیم شده در استاندارد دانشگاه  و مراکز دولتی می باشد.

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

---

بخشی از متن مقاله مقدمه ای بر UM1 :

مقدمه ای بر UM1

– یادگیری متد object- oriented برنامه نویسی شی گرا و visual modeling (مدلسازی بصری)
– بررسی انواع نمادهای گرافیکی
– نگاهی به انواع نمودارهای (UML Diagrams) UML
– توسعه نرم افزار با استفاده رز مدلسازی بصری (visual modeling)
مقدمه ای بر متد object- oriented (شی گرایی)

در متد شی گرایی (۰۰) برنامه به قطعات بسیار کوچک یا آبجکت هایی تقسیم می‌شود که تا اندازه ای مستقل از یکدیگرند مانند ساختمانی از بلوک ها.
در اولین گام تعدادی آبجکت های اساسی (انوع مختلف بلوک ها) را بسازید یا به دست آزمایشی آورید. اولین باری که شما این بلوک های ساختمانی را دارید, می‌توانید آنها را کنار هم گذاشته تا قصرتان را بسازید. به محض اینکه تعدادی آبجکت های اساسی در دنیای کامپیوتر ساختید یا به دست آورید می‌توانید به سادگی آنها را کنار هم بگذارید تا برنامه های جدید را ایجاد نمایید. یکی از امتیازات اساسی متد شی گرایی این است که می‌توانید یک بار component (اجزا) را ساخته و بارها و بارها از آنها استفاده کنید. درست مانند زمانی که می‌توانید یک بلاک ساختمانی را در یک قصر, یک خانه یا یک سفید فضایی دوباره استفاده کنید, می‌توانید از یک قطعه طرح یا کد شی گرایی در یک سیستم حسابداری, یک سیستم بازرگانی یا یک سیستم پردازش سفارش استفاده مجدد نمایید.

تفاوت شی گرایی با روش سنتی: در روش سنتی, روش توسعه به همراه اطلاعاتی که سیستم نگهداری خواهد کرد به خودتان وابسته است. در این روش پایگاه داده بر اساس نیازهای اطلاعاتی کار بران طراحی می‌کنیم و صفحاتی تهیه می‌کنیم تا اطلاعات را بگیرد, و گزارشاتی را چاپ می‌کنیم تا اطلاعات را برای کاربر نمایش دهد. یعنی بر روی اطلاعات متمرکز می‌شویم و کم توجه می‌کنیم که چه کاری با این اطلاعات انجام شده است یا رفتار سیستم چگونه است. این روش data- centric (مبتنی بر داده) نامیده شده است. مدلسازی data- centric مخصوص طراحی پایگاه داده و گرفتن اطلاعات خیلی سهم می‌باشد, اما انتخاب این روش در زمان طراحی برنامه های تجاری با مشکلاتی همراه است. یک چالش بزرگ این است که در خواهشهای سیستم چندین بار تغییر خواهند کرد.

سیستمی که روش data- centric استفاده می‌نماید, می‌تواند به آسانی تغییر در پایگاه داده را مدیریت نماید. اما اجرای تغییرات در قوانین تجاری یا رفتار (behavior) سیستم آن قدر آسان نمی باشد.
با استفاده از متد شی گرایی هم بر اطلاعات و هم بر رفتار متمرکز شویم.
مزیت این انعطاف پذیری با طراحی یک سیستم شی گرایی به خوبی شناخته شده است.
اصول شی گرایی عبارتند از: نهان سازی (Encapsulation), وراثت (Inheritance) و چند ریختی (Polymorphism)

Enlopsulation (نهان سازی)

در سیستم های شی گرایی, اطلاعات و رفتارها را در یک آبجکت بسته بندی می‌کنیم. این مطلب در قالب اطلاعات Encapsulation (پنهان سازی) ارجاع داده شده است و یا می‌توانیم برنامه را به بخشهای کوچکی از توابع وابسته, تقسیم کنیم. مثلا یک حساب بانکی شامل: شماره حساب, تراز جاری, نام مشتری, آدرس., نوع حساب, نرخ بهره و تاریخ باز کردن حساب می‌باشد. رفتارهایی هم برای یک حساب بانک داریم مانند: باز کردن حساب, بستن حساب, به حساب گذاشتن, برداشت از حساب, تغییر نوع حساب, تغییر مشتری و تغییر آدرس ما این اطلاعات و رفتارها را باهم در یک آبجکت account پنهان می‌کنیم. در نتیجه, همه تغییرات سیستم بانکی تاثیرات اعمال شده به سیستم را محدود می‌کند. یک مفهوم مشابه نهان سازی,Information Hiding است, پنهان سازی اطلاعات توانایی است که جزئیات مبهم یک آبجکت را در نیای خارج پنهان می‌نماید. دنیای خارج به معنی هر چیزی از خارج از همان آبجکت دست حتی اگر چه دنیای خارج شامل بقیه سیستم باشد Inheritance (وراثت)

در سیستم های شی گرا وراثت به شما اجازه می‌دهد تا آبجکت های جدید را بر پای ابجکت های قدیمی ایجاد کنید. آبجکت CHILD ویژگی هایی یک آبجکت PARENT را به ارث می‌برد.
یکی از مزایای اصل وراثت، سهولت در نگهداری است. وقتی چیزی تغییر می‌کند و بر همه تاثیر می گذارد، فقط آبجکت والد نیاز به تغییر دارد و آبجکت های فرزند به طور خورکار تغییرات را به ارث می برند. مثلا در طبعیت، اگر پستانداران به طور ناگهانی خونسرد شوند، فقط آبجکت پستانداران (mamaal) باید تغییر نماید. در یک سیستم بانکداری ممکن است از وراثت برای انواع مختلفی از حسابهایی که داریم استفاده کنیم.
این نوع مختلف حسابها شباهتهایی نیز دارند. هر کدام دارای یک شماره حساب، نرخ بهره و نام مالک می‌باشند بنابراین می‌توانیم یک آبجکت والد بنام account (حساب) را ایجاد نماییم تا ویژگی های مشترک همه این حسابها را نگهداری می‌کنیم آبجکت های فرزند (child) می‌توانند علاوه بر ویژگی هایی که به ارث برده اند، ویژگی ها منحصر به فرد خودشان راداشته باشند، مثلا حساب اعتباری یک حد موجودی و حداقل میزان پرداخت را خواهد داشت. سپرده گذاری نیز دارای یک موعد پرداخت می‌باشد.
تغییرات آبجکت والد بر روی همه فرزندان اثر خواهد گذاشت اما بچه ها آزاد هستند که بدون بر هم زدن آرامش فرزند دیگر یا والدشان تغییر نمایند.
Polymorphism (چند درختی)
سومین اصلی شی گرایی، ploymor phism است که به این معنی است که شکل ها یا پیامدهای زیادی از یک تابع ویژه را داشته باشیم. همانند وراثت، چند ریختی نیز در دنیای طبیعی دید می‌شود. چند ریختی در اصطلاحات یک سیستم شی گرایی به این معنی است که ما می‌توانیم بسیاری از رخداد ها یا پیامدهای یک عمل ویژه را داشته باشیم.
مثلا ممکن است یک سیستم رسم اشکال گرافیکی را بسازیم.
مدلسازی بصری (visual modeling) چیست؟
یک طرح کلی به شما کمک می‌کند تا قبل از اینکه سیستم را بسازید آن را طراحی نمایید و در این صورت سیستم می‌تواند حتی در مقابل کوهی از تغییرات درخواست، مقاومت نماید. پس از جمع ‌آوری درخواستهای خود، آن ها را تبدیل به کد می‌نمایید با تبدیل رسمی درخواستها به کد، می‌توانید مطمئن شوید که واقعا درخواستها به وسیله که مطرح شده اند و آن کد می‌تواند به آسانی راه برگشت به درخواستها را طی کند این پردازش modeling (مدلسازی) نامیده شده است.
نتیجه پردازش مدلسازی این توانایی است که نیازهای تجاری را به درخواستهایی تبدیل کند تا در کد به صورت مدل در آید و آن را دوباره برگردند بدون اینکه درطول راه چندی گم شود.

مدلسازی بصری (visual modeling) پردازش گرفتن اطلاعات از مدل است و آن را با استفاده از مجموعه ای از عناصر گرافیکی استاندارد به صورت گرافیکی نشان می‌دهد. هدف اصلی مدلسازی بصری، ارتباط میان کاربران، برنامه نویسان، تحلیلگران، آزمایش کننده ها، مدیران و هر شخص دیگری که با پروژه در گیر شده است می‌باشد بعد از ایجاد این مدلها، می‌توانیم آنها را به همه بخشهای وابسته نشان دهیم و آن بخشها می‌توانند اطلاعات را از مدل به دست آورند. در مدلسازی بصری از نمادهای گرافیکی (مثل object modeling technolohy oM T, Booch تکنولوژی مدلسازی شی و unified Modeling Language زبان مدلسازی یکپارچه) برای نشان دادن چره های مختلف یک سیستم استفاده می‌شود.

• نمودارهای UML
• نمودار use case
• نمودار sequence (توالی)
• نمودار collaboration (همکاری)
• نمودار class (کلاس)
• نمودار state transition (در حالت)
• نمودار component
• نمودار Deployment
این نمودار ها جنبه های مختلفی از سیستم را نشان می‌دهند.

نمودارهای use case
نمودار های use case محاورات میان use case ها را نشان میدهد که عملیات سیستمی و عاملها (Actor) که نشان دهنده افراد یا سیستم هایی است که اطلاعات را برای سیستم فراهم کرده است و یا از آن دریافت می‌کنند را نمایش می‌دهند. use case ها درخواستهای سیستم را از دید کاربر نشان می‌دهند. بنابراین vse case ها عملیاتی هستند که سیستم فراهم می‌کند. عامل ها در واقع نگهدارنده پول (بانکدار) یک سیستم هستند. این نمودارها نشان می‌دهند که چه عاملهایی به use case ها مقدار اولیه می‌دهند. همچنین آنها نشان می‌دهند که چه موقع یک عامل، اطلاعات را از یک use case دریافت می‌کند.

تعدادی از ارتباطات این ارزش را دارند که بیشتر به آنها اشاره می‌شود. کارمند بانک همچنین، به use case تغییر PIN مقدار اولیه می‌دهد. use case پرداخت، فلشی را نشان می‌دهد که به سیستم اعتباری می‌رود سیستم های خارجی ممکن است عاملهایی باشند و در این مورد، سیستم اعتباری به عنوان یک عامل نشان می‌دهد که use case اطلاعاتی را تولید می‌کند که یک عامل از آن استفاده می‌کند. در این مورد use case پرداخت، اطلاعات پرداختی کارت اعتباری را برای سیستم اعتباری آماده می‌کند. اکثر اطلاعات دزدیدن نمودارهای use case قابل فهم می‌باشند زیر این نمودار همه عملیات سیستم را نشان می‌دهد. کاربران، مدیران پروژه، تحلیلگران، برنامه نویسان، مهندسان تضمین کیفیت و هر شخص دیگری که به سیستم وابسته است، می‌تواند مانند همه، این نمودارها را ببیند و بفهمد که چه سیستمی قرار است به انجام برسد.

نمودارهای sequence (توالی)
این نمودارها، برای نشان دادن جریان عملیات در یک use case استفاده شده اند، مثلا use case برداشت پول چند توالی sequences دارد مانند برداشت پول، تلاش برای برداشت پول از حساب بدون موجودی، تلاش برای برداشت پول با PIN اشتباه و غیره طرح معمولی برداشت ۲۰ دلار پول و بدون هیچ مشکلی مانند وارد کردن PIN اشتباه یا وجوه ناکافی در حاسب در شکل زیر نشان داده شده است.

نمودار sequence جریان پردازش را در use case برداشت پول نشان می‌دهد عاملهای وابسته در بالای نمودار نشان داده شده اند، عامل مشتری هم در آن نشان داده شده است. هر فلش یک پیغام ارسالی بین عامل و آبجکت، یا آبجکت را نمایش می‌دهد تا عملیات مورد نیاز را به انجام برساند. نمودارهای sequence آبجکت ها را نمایش می‌دهند و نه کلاسها use case بدین ترتیب شروع می‌شود که مشتری کارتش را وارد کارت خوان می‌کند. کارت خوان شماره کارت را می‌خواند. آبجکت حساب joe را باز می‌کند و صفحه نمایش ATM را مقدار دهی می‌نماید.

.صفحه نمایش از joe می‌خواهد که PIN را وارد نماید. او ۱۲۳۴ را وارد می‌کند. صفحه PIN را با آبجکت حساب تایید می‌کند و آنها را به هم جفت وجور می‌کند. صفحه انتخابهایش را برای joe آماده می‌کند و او ۲۰ دلار را انتخاب می‌کند. سپس صفحه وجوه را از حساب بر می‌دارد. این سری از پردازشهایی که آبجکت حساب (account) به انجام می‌رساند را مقدار دهی می‌کند. ابتدا، حساب joe تایید می‌کند که حساب، حداقل شامل ۲۰ دلار است سپس وجوه را از حساب کسر می‌کند بعدا به صندوق اطلاع می‌دهد که ۲۰ دلار را آماده کند. همچنین حساب joe به صندوق اطلاع می‌دهد با یک رسید آماده کند. سرانجام به کارت خوان اطلاع می‌دهد تا کارت را باز پس دهد

. بنابراین، این نمودار sequence تمام جریان پردازشی use case برداشت پول را با نشان دادن یک مثال مشخصی از اینکه joe دلار از حسابش بر می‌دارد را توضیح می‌دهد. کاربران می‌توانند به این نمودارها نگاه کنند مشخصات پردازش تجاریشان را ببیند. تحلیلگران جریان پردازش را در نمودار sequence می‌بینند. برنامه نویسان آبجکت هایی که به کد نویسی نیاز دارند را به همراه عملکردهای آن آبجکت ها می‌بینند. مهندسین تضمین کیفیت می‌توانند جزئیات پردازش و تولید test cas مبتنی بر پردازش را ببیند. نمودارهای sequence برای همه کسانی که در پروژه مسئول نگهداری پول هستند، مفید است.

نمودارهای Callaboration

نمودارهای collaboration دقیقا همان اطلاعات نمودارهای sequence را نشان می‌دهند. اگر چه نمودارهای collaboration اطلاعات را به روشی متفاوت و با یک هدف متفاوت نشان می‌دهند. در نمودارهای sequence آبجکت ها و ارتباطات عامل ها به ترتیب زمان توضیح داده شده اند، در حالی که در نمودار collaboration آبجکت ها و فعل و انفعالات عامل ها را بدون توجه به زمان نشان میدهد. در نمودارهای Collaboratim افراد به دلایل مختلف به این نمودارها مراجعه می‌کنند.

نمودارهای class (کلاس)
نمودارهای (class) کلاس ارتباطات بین کلاسها را در سیستم نشان می‌دهند. کلاسها می‌توانند بدون طرحی کلی برای آبجکت ها دیده شوند مثلا حساب joe یک کلاس است کلاسها شامل اطلاعات و رفتاری هستند که بر روی اطلاعات عمل می‌نمایند. کلاس حساب (account) شامل PIN مشتری و رفتاری که PIN را کنترل می‌کند .در نمودار کلاس برای هر نوع آبجکتی در نمودار collaboration , sequence یک کلاس ایجاد شده است.

این نمودار مربوط به برداشت پول از حساب متعلق به سیستم ATM است و با چهار کلاس شامل card reader (کارت خوان)، Account (حساب)، Atmscreen صفحه نمایش cash Dispenser , ATM (صندوق) است. بخشهای مختلف یک کلاس در این مثال شامل: نام کلاس، صفات کلاس و عملگرهای کلاس است. همچنین در صفت ها عملگرها، قفلهای کوچکی در سمت چپشان دارند که فقط می‌توانند از طریق کلاسی که شامل ‌آنهاست قابل دستیابی می‌باشند.
برنامه نویسان از نمودارهای class استفاده می‌کنند تا که کلاسها را به طور واقعی تولید نمایند. ابزارهایی مانند Rose چهار چوب کلاسها را تولید می‌کنند، سپس برنامه نویسان جزئیات را در زبان انتخابی خود نشان می‌دهند.

تحلیلگران از نمودارهای کلاس استفاده می‌کند تا جزئیات سیستم را نشان می‌دهند. همچنین طراحان به نمودارهای class نگاه می‌کنند تا طرح سیستم را ببیند. اگر یک کلاس شامل چند تابع باشد، یک معمار می‌تواند این را در نمودار class دیده و توابع را به چند کلاس بشکند. نباید هیچ وابستگی بین کلاسهایی که با یکدیگر ارتباط دارند وجود داشته باشد. یک طراح یا برنامه نویس نیز می‌تواند این را ببیند. نمودارهای کلاس برای این ایجاد شده اند تا کلاسهایی را نشان دهنده که باهم در هر use case کار می‌کنند و نمودارهای جامع (camper hensive) شامل کل سیستم با زیر سیستم را می‌توان به همین ترتیب ایجاد نمود.

نمودارهای حالت (state transition digrmm)
نمودارهای حالت راهی را ‌آماده می‌کنند تا حالتهای مختلف یک آبجکت را مدل کنند. در حالی که نمودارهای کلاس یک تصویر ثابت از کلاسها و وابستگی آنها را نشان می‌دهند، نمودارهای حالت استفاده می‌شوند تا بیشتر رفتارهای پویای یک و نیم را نمایش دهند. یک نمودار حالت رفتار یک آبجکت را نشان می‌دهد. مثلا یک حساب بانکی می‌تواند به چنین حالت متفاوت وجود داشته باشد. می‌تواند باز باشد، بسته شود یا به طور اضافی (بیشتر از موجودی) از حساب برداشته شود یک حساب ممکن است در هر یک از این حالتها، به طور متفاوتی رفتار کند از نمودارهای حالت برای نشان دادن این اطلاعات استفاده می‌شود.

مثلا وقتی که حساب باز است و مشتری درخواست بستن حساب را می‌کند، حساب به حالت بسته منتقل می‌شود. در خواست مشتری Event (رخداد) نامیده می‌شود. اگر حساب باز است و مشتری برداشت از حساب را انتخاب می‌کند، حساب ممکن است به حالت برداشت بروز این فقط زمانی رخ می‌دهد که تراز (موجودی) حساب کمتر در صفر باشد که با علامت < تراز نشان داده شده است یک شرط که در براکت محصور شده است شرط حفاظتی Guard condition نامیده می‌شود و وقوع یک انتقال اینکه بتواند یا نتواند اتفاق بیفتد را کنترل می‌کند.

در حالت ویژه start state (حالت شروع) و stop state (حالت پایان) وجود دارد حالت شروع با دایره توپر سیاه نشان داده شده و نشان می‌دهد چه حالتی از آبجکت در ابتدا ایجاد شده است حالت پایانی بوسیله یک خال هدف نمایش داده شده است و نشان می‌دهد که آبجکت درست قبل از اینکه از بین برود، در چه حالتی می‌باشد. بر روی یک نمودار حالت، فقط یک حالت شروع وجود دارد در حالی که شما می‌توانید حالت پایانی نداشته باشید یا اینکه هر چند حالت پایانی که نیاز دارید ؟ را داشته باشید.
نمودارهای حالت فقط برای مستند سازی ایجاد شده اند. همچنین نمودارهای حالت برای هر کلاسی ایجاد نمی شوند و فقط برای کلاسهای پیچیده استفاده می‌شوند.

نمودارهای اجزاء (component Diagrams)
نمودارهای compnent یک دید فیزیکی از مدلتان را به شما نشان می‌دهند. یک نمودار component اجزای نرم افزاری سیستم شما و روابط بین آنها را به شما نشان می‌دهد دو نوع companent در نمودار وجود دارد.
Component های قابل اجرا و کتابخانه های کد.

در Rose، هر یک از کلاسهای موجود در مدل به یک component کد منبع نگاشت شده اند. اولین باری که Companent ها ایجاد می‌شوند آنها به نمودار component اضافه می‌شوند. سپس وابستگی های میان component ها کشیده می‌شود. وابستگی های co,ponent، وابستگی های زمان اجرا و زمان ت؟ میان component ها را نشان ی می‌دهد.

این نمودار component برای سرویس گیرنده ATM/ client است.
Component هایی که به هم وصل شده اند، با خطر چین، وابستگی روابط بین آنها را نشان می‌دهد. مثلا کلاس card Reader به کلاسATM screen وابسته است به این معنی که کلاس ATM screen باید موجود باشد تا کلاس card Reader ترجمه شود. فایل اجرایی ATM client . exe اولین باری که همه کلاسها ترجمه شده اند می‌تواند ایجاد شده باشد مثال ATM دو نخ پردازش دارد، بنابراین به دو صورت قابل اجرا است. یک مجموعه اجرایی ATM client شامل ATM screen , card Reader, cash Dispenser می‌باشد. دومین مجموعه اجرایی ATM screen شامل component حساب است. یک سیستم شبیه به تعداد زیر سیستم ها با قابلیت اجرایی می‌تواند چندین نمودار component داشته باشد. به طور عمومی بسته ها مجموعه‌هایی از آبجکت ها هستند. در این مورد، بسته ها مجموعه ای از component ها می‌باشند ATM شامل دو بسته است ATM screen , ATM client.

نمودارهای component به وسیله هر شخصی که مسئول تنظیم و تدوین سیستم است، استفاده می‌شود. نمودارها این ویژگی را بیان می‌نمایند که به چه منظوری نیاز به کامپایل component وجود دارد. همچنین نمودار نشان خواهد داد که چه component هایی در زمان اجرا به عنوان نتیجه کامپایل ایجاد خواهند شد. نمودارهای component، نگاشته شدن کلاسها به اجزای اجرا شده را نشان می‌دهد. این نمودارها در جایی که تولید تمام شده است رسم می‌شوند.
نمودارهای Deployment

این نمودار ها، لایه فیزیکی شبکه و جایی که Deployment های مختلف مقیم می‌شوند را نشان می‌دهد.

در مثال ATM, ATM از بسیاری زیر سیستم های در حال اجرا بر روی وسایل فیزیکی مجزا یا گره ها تشکیل شده است نمودار Layout, Deployment سیستم را به ما بیشتر نشان می‌دهد. سرویس گیرنده قابل اجرای ATM، بر روی چندین ATM که بر روی محلهای مختلف ایجاد شده اند، اجرا خواهد شد. سرویس گیرنده ATM بر روی یک شبکه خصوصی، با سرویس دهنده ATM اصلی ارتباط برقرار خواهد کرد. سرویس دهنده ATM قابل اجرا بر روی سرویس دهنده ATM اصلی، اجرا خواهد شد. سرویس دهنده ATM اصلی، بر روی شبکه محلی با سرویس دهنده پایگاه داده بانکداری که proje را اجرا می‌کند ارتباط برقرار خواهد کرد. سرانجام، یک چاپگر به سرویس دهنده ATM اصلی وصل شده است این نمودار به ما نصب فیزیکی سیستم را نشان می‌دهد سیستم ATM ما یک سبک معماری سه طبقه دارند به همراه یک طبقه پایگاه داده، سرویس دهنده اصلی و سرویس گیرنده.

مدلسازی بصری و پردازش تولید و توسعه نرم افزار
تولید نرم افزار می‌تواند به چندین روش انجام شود. چندین نوع متفاوت از پردازشهای تولید شامل هر چیزی از پردازشهای آبشاری گرفته تا شی گرایی وجود دارد که پروژه ها آنها را دنبال می‌کنند و هر یک مزایا و امتیازات خودش را دارد.
در پردازش شی گرا، ما در سراسر مراحل تجزیه و تحلیل، طراحی، تولید، تست و تولید درمقاطع کوچک، بارها حرکت خواهیم کرد. این غیر ممکن است که همه درخواستها را در طول بخش نخست پروژه بفهمیم چیزهای جدیدی ظاهر می‌شوند، بنابراین با طراحی پروژه به صورت تکراری آنها را برنامه ریزی می‌کنیم این مفهوم، یک پروژه می‌تواند به عنوان یک سری از آبشارهای کوچک دیده شود. در پروژه ۴ فاز را پشت سر می‌گذاریم: Inception (انتقال)، Elaboration (مهارت)، constraction (ساختار)، Transitian (انتقال).

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

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

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

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

درخواستها به شکل use case های کامل و با جزئیات، در یک سند جمع شده اند که یک (SRS) software Requirement spencification (مشخصات درخواست نرم افزار) نامیده شده است. SRS شامل هم جزئیات درخواستهای سیستم می‌باشد.
کارهای دیگری در فاز مهارت (Elaboration) انجام می‌شود مانند اصلاح تخمین های اولیه، بررسی کیفیت SRS و مدل use case و بررسی کردن خطرها فاز مهارت (Elaboration) زمانی تمام شده است که use case کاملا وارد جزئیات شده اند و به وسیله کار بران پذیرفته شده اند، اثبات مفاهیم (proofs- of –concept) کامل شده اند تا شدت خطرها را کاهش دهند نمودارهای کلاس کامل می‌باشند به عبارت دیگر این فاز زماین کامل است که سیستم طراحی شده بازبینی شده و آماده است تا برنامه نویسان آن را تولید نمایند.

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

مزیت دیگر مدل کردن سیستم آن است که Rational Rose می‌تواند کد اولیه را برای سیستم تولید کند به منظور استفاده از این شکل، شما نیاز دارید تا componet ها و یک نمودار component را به عنوان یک بخش اولیه constraetion ایجاد کنید. construction جایی است که اکثر کد نویسی پروژه انجام شده است. از Rose برای ایجاد component بر حسب طول آبجکت، استفاده شده است. نمودارهای component ایجاد شده اند تا وابستگی های زمان کامپایل را میان component ها نشان دهند بعد از اینکه زبانها برای هر component انتخاب شدند، تولید کد اولیه می‌تواند انجام شود.

Transtion (انتقال)
فازTransition زمانی است که محصول نرم افزاری کامل شده، به سمت اجتماع کاربر بر می‌گردد کارها در این فاز شامل کامل کردن محصول نرم افزاری نهایی، تکمیل تست تایید نهایی، کامل کردن مستند سازی کاربرد فراهم کردن آموزش برای کاربرد می‌باشد. باید مشخصات درخواستهای نرم افزار (software requirement specification)، نمودارهای Deployment , component , class , use case بروز رسانی شده باشند تا تغییرات نهایی را منعکس نمایند. مهم است که این مدلها با محصول نرم افزاری همزمان شده باشند زیرا مدلهایی که یکبار در محصول نرم افزاری استفاده خواهند شد به مد پشتیبانی می‌روند. چند ماه بعد از اتمام پروژه، این مدلها در کمک به ارتقا نرم افزار، گرانبها تر خواهند بود.

Use case شامل تمام آن چیزهایی است که درون سیستم قرار دارد. عامل شامل تمام آن چیزهایی است که خارج از سیستم قرار دارد.
نمودار use case برخی از use case های موجود در سیستم مورد نظر شما برخی از عامل های موجود در سیستم شما و رابطه های بین تمامی اینها را مشخص می کند. Use case عملیات سطح بالایی است که سیستم مهیا می کند عامل هر چیز و یا هر کسی است که بر سیستمی که در حال ساخت است اثر می گذارد.

یکی از مزیت های بزرگ نمودارهای Use case تبادل اطلاعات است. مراجعه کنندگان شما می توانند به این نمودارها نگاه کرده و اطلاعات وسیعی را بدست آورند. با نگاه به نمودار Use case خواهند فهمید که چه عملیاتی در سیستم انجام می شود. با نگاه به عامل ها خواهند فهمید که چه کسی بر سیستم کنش دارند. با نگاه به مجموعه Use case و عامل می فهمند که چه محدوده ای از پروژه انجام خواهد شد. بنابر این کمکی به آنها خواهد بود تا از هر عملیات از قلم افتاده ای یک ذهنیت اولیه داشته باشند.

یک نمودار سطح بالا که در main, rational rose نامیده می شود. فقط بسته های نرم افزاری یا گروه بندی Use case ها را نشان می دهد.
نمودارهای Use case کار مشخصی را برای مستند سازی عامل ها ( هر چیز خارج از محدوده سیستم ) Use case (هرچیز درون محدوده سیستم و ارتباط آنها انجام می دهد.
نکاتی را که باید به عنوان کسی که یک نمودار Use case را ایجاد می نماید به خاطر داشته باشید بدین ترتیب می باشند.
– ارتباطات عامل با عامل را مدل سازی نکنید.

– هیچ گاه مستقیما با فلش، Use case را به هم وصل نکنید ( بجز در ارتباطات extends or uses
– هر Use case باید توسط یک عامل آغاز به کار کند.
– بانک اطلاعاتی را به عنوان لایه زیرین تکمیل نمودار Use case در نظر بگیرید.

کار با Use case ها
Use caseبخش سطح بالایی از عملیاتی است که سیستم مهیا می کند به عبارت دیگر Use case، اینکه شخص چگونه سیستم استفاده می کند را شرح می دهد. یک ماشین ATM یک سری عملیات اصلی را برای مشتری انجام می دهد. به مشتری اجازه می دهد تا پول به حساب بریزد نقدا از حساب برداشت کند پول را از یک حساب به حساب دیگر منتقل نماید مقدار موجودی را مشاهده کند، pin را تعویض نماید و یا توسط کارت اعتباری پول پرداخت نماید. هر کدام از این transaction ها روش متفاوت استفاده مشتری از سیستم می باشد. به هر حال هر کدام از آنها یک Use case متفاوت هستند در uml یک Use case با استفاده از عملیات زیر نمایش داده می شود.ژ:

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

اولا Use case به طور مستقل عمل می کنند.
دوما Use case ها یک دید سطح بالا از سیستم هستند.
نباید انقدر زیاد Use case باشید که مشتری به زحمت بتواند سند را بررسی کند فقط در این حد باشد که بفهمد سیستم چه کاری انجم می دهد.
نهایتا تمرکز Use case باید بر آنچه که کاربر از سیستم به دست می اورد باشد.

مشاهده شرکت کنندگان در یک Use case
ممکن است بخواهید لیستی از تمام کلاس ها و عملیات ک هدر Use case شرکت می کنند را داشته باشید. در حالی که پروژه در حال پیشروی است و شما نیازهایی را تغییر و یا اضافه می کنید اینکه بدانید چه کلاس هایی ممکن است تحت تاثیر این تغییرات قرار گیرند کمک زیادی به شما خواهد نمود.

ساختن Use case های Abstract (مجرد)
یک Abstract Use case یک Use case است که مستقیما توسط یک عامل شروع به کار نمی کند. درعوض برخی عملیات اضافی که می تواند توسط دیگر Use case ها استفاده شود را مهیا می کند. Use case های abstract، Use case هایی هستند که در ارتباطات گسترده و مورد استفاده شرکت می کنند.

مشاهده رابطه های متعلق به یک Use case
برگه relation در پنجره Use case specification تمام رابطه هایی که Use case در آنها مشارکت دارد و یا ارتباط با دیگر Use case و یا عامل ها را لیست می کند.

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

سومین نوع عامل که زیاد استفاده می شود زمان است هنگامی زمان تبدیل به یک عامل می شود که زمان در حال گذر باعث ایجاد رخدادی در سیستم گردد.
افزودن عامل ها
دو راه برای افزودن یک عامل وجود دارد: یا آن را به یک نمودار Use case باز شده بیفزایید و یا این کار را مستقیما در مرورگر انجام دهید. در حالت دوم عامل موجود در مرورگر می تواند به یک یا تعداد بیشتری نمودار Use case افزوده شود.
یک عامل abstract عاملی است که هیچ مصداق واقعی ندارد به عبارت دیگر کاردینالیتی عامل، دقیقا صفر است به طور مثال ممکن است چندین عامل داشته باشید: کارمند ساعتی، کارمند ثابت و کارمند موقتی. تمامی اینها نوعی از عامل چهارم هستند که عامل کارمند می باشد. با وجود این هیچ کس در شرکت فقط یک کارمند نیست. هر کسی یا کارمند ساعتی است یا کارمند ثابت است و یا کارمند موقتی. دلیل وجود عاملی با نام کارمند این است که رابطه معمول استخدام ساعتی، استخدام با حقوق ثابت و استخدام موقتی نشان داده شود. هیچ مرحله و مصداق واقعی برای عامل کارمند وجود ندارد پس آن یک عامل abstract‌خواهد بود.
برگه relations موجود در پنجره actor specification تمام رابطه های عامل های شرکت کننده را لیست می کند. این برگه دارای تمام رابطه هایی است که یک عامل با Use case ها و یا عامل های دیگر دارد لیست شامل نام رابطه و نام Use case یا عامل های مرتبط می باشد.
UML از انواع متعددی از رابطه ها برای Use case ها و عامل ها پشتیبانی می کند. این شامل رابطه های communication رابطه های uses رابطه های extend و رابطه های generalization برای عامل می باشد. رابطه های uses, extend رابطه های بین Use case ها را تعریف می کنند. رابطه های actor generalization رابطه بین عامل ها را تعریف می کند.
به رابطه بین Use case و عامل، رابطه communication می گویند. در UML رابطه های اطلاعاتی با استفاده از فلش به حالت نمودار در می آیند:
رابطه uses به یک Use case اجازه استفاده از عملیات مهیا شده توسط یک Use case دیگر را می دهد. رابطه های Use case برای مدل سازی برخی عملیاتی که بین دو یا تعداد بیشتری Use case استفاده می شوند، به کار می روند.

رابطه های extend
یک رابطه extend به یک Use case اجازه می دهد که بطور دلخواه عملیات مهیا شده توسط دیگر Use case ها را بسط دهد که بسیار مشابه رابطه uses عمل می کند. در هر دو نوع این رابطه ها برخی عملیات معمول را در Use case های مجزای خودشان قرار می دهید.
Actor generalization برای نشان دادن همانندی چندین عامل به کار می رود.
در حین ساخت نمودارهای خود افزودن یادداشت هایی به Use case و یا عامل ها کمک زیادی به شما خواهد کرد.
دو نوع یادداشت توضیحی برای افزودن وجود دارد،یادداشت و کادر متن.

در uml آیتم هایی چون عامل ها، Use case ها کلاسها، component ها می توانند به صورت بسته هایی نرم افزاری گروه بندی شده تا سازماندهی شوند. ممکن است هنگام مشاهده Use case بخواهید Use case ها و عامل ها را به صورت بسته بندی شده گروه بندی نمایید.

نمودارهای interaction
یک نمودار interaction روندی در یک Use case را مرحله به مرحله نشان می دهد.
دو نوع نمودار interaction وجود دارند که آنها را بررسی خواهید نمود: نمودارهای sequence و نمودارهای collaboration.
هر دو نمودار sequence, collaboration اطلاعات یکسانی را نشان خواهند داد با وجود این چند تفاوت کوچک بین نمودارهای بالا وجود دارد. نمودارهای sequence نشان دهنده مرکز کنترل هستند نمودارهای collaboration نشان دهنده یک روند داده ای هستند.
آبجکت آن چیزی است که اطلاعات و روشها را در خود کپسوله می کند. روشی است که برخی چیزهای عینی در دنیای واقعی را نشان می دهد. مثالهایی از آبجکت به صورت زیر می باشد:

– حساب joe
– خانه ای در ۷۶۳۸ main street
– گل زردی که در بیرون از پنجریه خانه منحنی قرار دارد.

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

در rose آبجکت ها به نمودارهای interaction افزوده می شوند. هنگام کشیدن یک عامل یا کشیدن دیگر کلاس ها به نمودار interaction یک نمونه ابجکت از آن کلاس به طور خودکار ساخته می شود در rose حذف یک آبجکت از یک نمودار کلاس را از کل مدل حذف خواهد نمود.
طرح کلی برای یک آبجکت را کلاس آن فراهم می کند. به عبارت دیگر یک کلاس تعیین کننده اطلاعاتی است که یک آبجکت می تواند نگهداری کند و نشان دهنده رفتارهایی است که می تواند داشته باشد.
یک راه برای یافتن برخی آبجکت ها این است که نام ها را در جریان رخدادها در نظر بگیرید. یک جای خوب دیگر برای بدست آوردن آنها سناریوی اسناد می باشند. یک سناریو حالت خاصی از جریان رخدادها می باشد. جریان رخدادها برای Use case مربوط به برداشت پول از حساب درباره فردی در ATM صحبت می کند که در حال برداشت پول از حساب است. یکی از سناریوها برای این مورد می تواند برداشت joe از حساب به مقدار ۲۰ دلار باشد سناریوی دیگر می تاند سعی jane در برداشت ۲۰ دلار از حساب باشد در حالی که او pin را اشتباه وارد کرده است.
یک نمودار sequence و collaboration یکی از این سناریوها را شرح می دهد. هنگامی که در سناریوی خود به اسامی نگاه می کنید برخی از اسامی عامل خواهند بود برخی از آنها آبجکت خواهند بود و برخی صفات برای یک آبجکت خواهند بود.
همه آبجکت ها در جریان رخدادها وجود نخواهند داشت. به طور مثال form ها ممکن است در روند رویدادها ظاهر نشوند، ولی باید بر نمودار ظاهر شوند تا به عامل اجازه دهد که اطلاعات را وارد کرده و یا ببیند. آبجکت های دیگری که در جریان رخداد ها ظاهر نمی شوند. آبجکت های کنترل هستند اینها آبجکت هایی هستند که تناوب روند در Use case را کنترل می کنند.
نمودارهای collaboration زمانی مفید واقع می شوند که بخواهید به تاثیر تغییرات دست یابید. اینکه بفهمید چه آبجکت هایی با چه آبجکت های دیگری تبادل اطلاعاتی انجام می دهند. به راحتی با نگاه به نمودارهای collaboration قابل انجام است. اگر نیاز دارید که یک آبجکت را تغییر دهید می توانید به راحتی ببینید که چه آبجکتهای دیگری ممکن است در ارتباط با آن باشند.
نمودارهای sequence موارد زیر را در بر می گیرند:
Objects: یک نمودار interaction می تواند از نام ابجکت ها نام کلاس ها و یا هر دوی آنها استفاده کند.
Messages: با استفاده از یک پیغام یک آبجکت یا کلاس می تواند از یک آبجکت یا کلاس دیگر،
در هنگام ساختن نمودار sequence باید به این نکته توجه داشته باشید که در حال تخصیص مسئولیت به ابجکت ها می باشید. وقتی پیغامی را به یک نمودار interaction می افزایید، در حقیقت به ابجکت در حال دریافت پیغام یک مسئولیت را واگذار می کنید.
نمودارهای sequence نمودارهای interaction هستند که بر مبنای زمان تنظیم می شوند. شما نمودار ار از بالا به پایین مشاهده می کنید.
هر ابجکت برای خودش یک خط عمر دارد که به صورت خطوط عمومی خط چین در زیر آبجکت کشیده می شود یک پیام بین دو خط عمر موجود بین دو آبجکت قرار داده می شود تا ارتباط بین آبجکت ها را نشان دهد. هر پیغامی نشان دهنده یک آبجکت است که توسط تابع ابجکت دیگر صدا زده می شود.
برای الصاق فایل به نمودار sequence:
۱- در مرورگر بر روی نمودار sequence کلیک راست کنید.
۲- از منوی new گزینه file را انتخاب کنید.
۳- با استفاده از کادر محاوره ای open فایلی را که می خواهید الصاق نمایید انتخاب کنید.
۴- Open را انتخاب کنید تا فایل را الصاق نمایید.

نمودار collaboration برای نشان دادن جریان در سناریوی مشخص یک Use case استفاده می شوند. نمودارهای sequence برحسب زمان منظم می شوند، نمودارهای collaboration بیشتر بر روی رابطه بین آبجکت ها متمرکز می شوند.
هر نمودار sequence, collaboration باید دارای آبجکت عامل باشد. آبجکت عامل یک محرک خارجی است که به سیستم اعلام می کند تا یک عملیات را راه اندازی کند. آبجکت های عامل برای نمودار interaction عامل هایی که در نمودار Use case یا use Case ارتباط دارند را نشان می دهند.

نگاشت یک آبجکت به یک کلاس
در یک نمودار sequence یا نمودار collaboration هر آبجکتی که ممکن است به یک کلاس شود. به طور مثال حساب joe ممکن است به یک کلاس به نام account نگاشت شود. در پنجره object specification می توانید از فیلد class برای تنظیم کلاس آبجکت استفاده کنید. به طور پیش فرض کلاس به unspecified تنظیم شده است.

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

جریان های داده ای برای نشان دادن اطلاعات برگشتی، وقتی که آبجکتی به آبجکت دیگر پیغام ارسال می کند استفاده می شوند. عموما به هر پیغام موجود بر روی نمودار collaboration جریان داده ای اضافه نکنید زیرا باعث ازدحام و شلوغی نمودار می شود، آن هم به وسیله یک سری اطلاعاتی که ارزش زیادی ندارند.
نام پیغام و نام آبجکت اطلاعات زیادی را در نمودار interaction در اختیار شما قرار می دهند. به هر حال ممکن است در زمان هایی بخواهید اطلاعات مضاعفی را به نمودار بیفزایید. می توانید این کار را با استفاده از یادداشت و یا اسکریپت انجام دهید.

یادداشت ها برای متصل کردن تفاسیر و توضیحات به آبجکت روی نمودار استفاده می شوند. به طور مثال برای روشن شدن هدف یک ابجکت استفاده می شوند.
اسکریپت ها برای افزودن توضیح به پیغام اضافه می شوید همان گونه که می خواهید در نمودار sequence می توانید از اسکریپت برای افزودن شرایط منطقی استفاده کنید.
در Rose یادداشت ها معمولا برای افزودن توضیح به آبجکت استفاده می شوند. از طرف دیگر اسکریپت ها معمولا برای افزودن توضیح پیغام استفاده می شوند. اسکریپت ها فقط در نمودار sequence استفاده می شوند. آنها در سمت چپ نمودار و رو به روی پیغامی که به آن ارجاع می شوند ظاهر می شوند. می توانید از یک اسکریپت برای نشان دادن معنی یک پیغام استفاده کنید.

نمودارهای interaction آبجکت نشان می دهد چگونه آبجکت ها برای پیاده سازی عملکرد یک use case با یکدیگر کار می کنند. دو نوع از نمودارهای interaction وجود دارند: نمودارهای sequence و collaboration. هر دو نوع این نمودارها اطلاعات یکسان ولی با زوایای متفاوتی را نشان می دهند.
نمودارهای sequence اطلاعات را به ترتیب زمانی نشان می دهند. نمودار sequence برای مسیرهای متناوب به یک use case ساخته شده اند. آنها برای مشاهده پیشرفت عملیات یک use case مفید می باشند. نمودارهای collaboration روند اطلاعات را نشان می دهند ولی در اینجا ترتیب زمانی در نظر گرفته نشده است. نمودارهای collaboration رابطه بین آبجکت ها و پیغام های بین آبجکت ها را شرح می دهد. یک طراح سیستم توسط نمودار sequence می تواند ببیند که کدام آبجکت ها حساس هستند و کدام آبجکت ها نیاز به برقراری ارتباط مستقیم با یکدیگر دارند. نمودارهای collaboration هم می توانند جریان داده ای را بین آبجکت ها نشان دهند نمودارهای sequence و نمودارهای collaboration قابل تغییر هستند وقتی تغییراتی روی یکی انجام شود آن یکی هم تغییر خواهد کرد.

 

یک نمودار class برای نمایش تعدادی از کلاس ها و بسته های کلاس در سیستم شما استفاده شده است این نمودار یک تصویر ایستا از قطعات سیستم و ارتباطات بین آنها را به شما می دهد.
به طور پیش فرض یک نمودار class وجود دارد که main نامیده شده و مستقمیا زیر نظر نمای logical است این نمودار class بسته های کلاس های موجود در مدلتان را نشان می دهد. داخل هر بسته ای نمودار دیگری است که main نامیده می شود. که شامل همه کلاس های داخل آن بسته است در rose با دوبار کلیک بر روی یک بسته در یک نمودار class بطور خودکار نمودار main class باز خواهد شد.

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