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

بخشی از مقاله

مقدمه اي بر UM1

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

در متد شي گرايي (0.0) برنامه به قطعات بسيار كوچك يا آبجكت هايي تقسيم مي‌شود كه تا اندازه اي مستقل از يكديگرند مانند ساختماني از بلوك ها.
در اولين گام تعدادي آبجكت هاي اساسي (انوع مختلف بلوك ها) را بسازيد يا به دست آزمايشي آوريد. اولين باري كه شما اين بلوك هاي ساختماني را داريد, مي‌توانيد آنها را كنار هم گذاشته تا قصرتان را بسازيد. به محض اينكه تعدادي آبجكت هاي اساسي در دنياي كامپيوتر ساختيد يا به دست آوريد مي‌توانيد به سادگي آنها را كنار هم بگذاريد تا برنامه هاي جديد را ايجاد نماييد. يكي از امتيازات اساسي متد شي گرايي اين است كه مي‌توانيد يك بار 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 اشتباه و غيره طرح معمولي برداشت 20 دلار پول و بدون هيچ مشكلي مانند وارد كردن PIN اشتباه يا وجوه ناكافي در حاسب در شكل زير نشان داده شده است.

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

.صفحه نمايش از joe مي‌خواهد كه PIN را وارد نمايد. او 1234 را وارد مي‌كند. صفحه PIN را با آبجكت حساب تاييد مي‌كند و آنها را به هم جفت وجور مي‌كند. صفحه انتخابهايش را براي joe آماده مي‌كند و او 20 دلار را انتخاب مي‌كند. سپس صفحه وجوه را از حساب بر مي‌دارد. اين سري از پردازشهايي كه آبجكت حساب (account) به انجام مي‌رساند را مقدار دهي مي‌كند. ابتدا، حساب joe تاييد مي‌كند كه حساب، حداقل شامل 20 دلار است سپس وجوه را از حساب كسر مي‌كند بعدا به صندوق اطلاع مي‌دهد كه 20 دلار را آماده كند. همچنين حساب 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 ما يك سبك معماري سه طبقه دارند به همراه يك طبقه پايگاه داده، سرويس دهنده اصلي و سرويس گيرنده.

مدلسازي بصري و پردازش توليد و توسعه نرم افزار
توليد نرم افزار مي‌تواند به چندين روش انجام شود. چندين نوع متفاوت از پردازشهاي توليد شامل هر چيزي از پردازشهاي آبشاري گرفته تا شي گرايي وجود دارد كه پروژه ها آنها را دنبال مي‌كنند و هر يك مزايا و امتيازات خودش را دارد.
در پردازش شي گرا، ما در سراسر مراحل تجزيه و تحليل، طراحي، توليد، تست و توليد درمقاطع كوچك، بارها حركت خواهيم كرد. اين غير ممكن است كه همه درخواستها را در طول بخش نخست پروژه بفهميم چيزهاي جديدي ظاهر مي‌شوند، بنابراين با طراحي پروژه به صورت تكراري آنها را برنامه ريزي مي‌كنيم اين مفهوم، يك پروژه مي‌تواند به عنوان يك سري از آبشارهاي كوچك ديده شود. در پروژه 4 فاز را پشت سر مي‌گذاريم: 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
- خانه اي در 7638 main street
- گل زردي كه در بيرون از پنجريه خانه منحني قرار دارد.

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

در rose آبجكت ها به نمودارهاي interaction افزوده مي شوند. هنگام كشيدن يك عامل يا كشيدن ديگر كلاس ها به نمودار interaction يك نمونه ابجكت از آن كلاس به طور خودكار ساخته مي شود در rose حذف يك آبجكت از يك نمودار كلاس را از كل مدل حذف خواهد نمود.
طرح كلي براي يك آبجكت را كلاس آن فراهم مي كند. به عبارت ديگر يك كلاس تعيين كننده اطلاعاتي است كه يك آبجكت مي تواند نگهداري كند و نشان دهنده رفتارهايي است كه مي تواند داشته باشد.
يك راه براي يافتن برخي آبجكت ها اين است كه نام ها را در جريان رخدادها در نظر بگيريد. يك جاي خوب ديگر براي بدست آوردن آنها سناريوي اسناد مي باشند. يك سناريو حالت خاصي از جريان رخدادها مي باشد. جريان رخدادها براي Use case مربوط به برداشت پول از حساب درباره فردي در ATM صحبت مي كند كه در حال برداشت پول از حساب است. يكي از سناريوها براي اين مورد مي تواند برداشت joe از حساب به مقدار 20 دلار باشد سناريوي ديگر مي تاند سعي jane در برداشت 20 دلار از حساب باشد در حالي كه او pin را اشتباه وارد كرده است.
يك نمودار sequence و collaboration يكي از اين سناريوها را شرح مي دهد. هنگامي كه در سناريوي خود به اسامي نگاه مي كنيد برخي از اسامي عامل خواهند بود برخي از آنها آبجكت خواهند بود و برخي صفات براي يك آبجكت خواهند بود.
همه آبجكت ها در جريان رخدادها وجود نخواهند داشت. به طور مثال form ها ممكن است در روند رويدادها ظاهر نشوند، ولي بايد بر نمودار ظاهر شوند تا به عامل اجازه دهد كه اطلاعات را وارد كرده و يا ببيند. آبجكت هاي ديگري كه در جريان رخداد ها ظاهر نمي شوند. آبجكت هاي كنترل هستند اينها آبجكت هايي هستند كه تناوب روند در Use case را كنترل مي كنند.
نمودارهاي collaboration زماني مفيد واقع مي شوند كه بخواهيد به تاثير تغييرات دست يابيد. اينكه بفهميد چه آبجكت هايي با چه آبجكت هاي ديگري تبادل اطلاعاتي انجام مي دهند. به راحتي با نگاه به نمودارهاي collaboration قابل انجام است. اگر نياز داريد كه يك آبجكت را تغيير دهيد مي توانيد به راحتي ببينيد كه چه آبجكتهاي ديگري ممكن است در ارتباط با آن باشند.
نمودارهاي sequence موارد زير را در بر مي گيرند:
Objects: يك نمودار interaction مي تواند از نام ابجكت ها نام كلاس ها و يا هر دوي آنها استفاده كند.
Messages: با استفاده از يك پيغام يك آبجكت يا كلاس مي تواند از يك آبجكت يا كلاس ديگر،
در هنگام ساختن نمودار sequence بايد به اين نكته توجه داشته باشيد كه در حال تخصيص مسئوليت به ابجكت ها مي باشيد. وقتي پيغامي را به يك نمودار interaction مي افزاييد، در حقيقت به ابجكت در حال دريافت پيغام يك مسئوليت را واگذار مي كنيد.
نمودارهاي sequence نمودارهاي interaction هستند كه بر مبناي زمان تنظيم مي شوند. شما نمودار ار از بالا به پايين مشاهده مي كنيد.
هر ابجكت براي خودش يك خط عمر دارد كه به صورت خطوط عمومي خط چين در زير آبجكت كشيده مي شود يك پيام بين دو خط عمر موجود بين دو آبجكت قرار داده مي شود تا ارتباط بين آبجكت ها را نشان دهد. هر پيغامي نشان دهنده يك آبجكت است كه توسط تابع ابجكت ديگر صدا زده مي شود.
براي الصاق فايل به نمودار sequence:
1- در مرورگر بر روي نمودار sequence كليك راست كنيد.
2- از منوي new گزينه file را انتخاب كنيد.
3- با استفاده از كادر محاوره اي open فايلي را كه مي خواهيد الصاق نماييد انتخاب كنيد.
4- 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 هر صفت و عملگر نوع داده اي هر صفت و علامت مشخصه هر عملگر روي اين نمودارها را نشان دهيد.
يك آبجكت نمونه اي از يك كلاس است.