X
تبلیغات
دکتر وقردوست

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

با تشکر مدیریت

Stereotype کلاسها

انواع Stereotype های کلاسها در درس هشتم توضیح داده شده است . ما فقط بطور مختصری آنها را یادآوری می کنیم .

Actor یا عامل ، Boundary : که به معنای User Interface   هستند ، Control : این آبجکت ها همان اشیاء کنترلی هستند ، Entity : اشیای هستند که در سیستم وجود دارند ، Table : جدول از پایگاه داده هستند .

صفات کلاس و افزودن صفات به کلاس

برای یافتن صفات می توان به Use Case ها رجوع کرده و در جریان رخدادها اسامی را پیدا نمود .

برای افزودن صفات به کلاس کافی است بر روی کلاس مورد نظر کلیک راست نموده و سپس گزینه New Attribute را انتخاب کنید . به این ترتیب می توانید به کلاس خود صفات جدید اضافه کنید .

 

یک صفت از لحاظ Visibility چهار وضعیت زیر را می تواند داشته باشد :

  • عمومی ( Public ) : صفت برای تمامی کلاسهای دیگر نیز قابل روئیت است . در UML از علامت + برای نمایش دادن این صفات استفاده می شود .
  • خصوصی ( Private ) : این نوع صفات برای کلاسهای دیگر قابل روئیت نیست . در UML از علامت - برای نمایش دادن این صفات استفاده می شود .
  • محافظت شده ( Protected ) : این نوع کلاس فقط بتوسط همان کلاس و فرزندانش قابل روئیت است . در UML از علامت # برای نمایش دادن این صفات استفاده می شود .
  • Implementation : فقط کلاسهای یک بسته می توانند به صفات یکدیگر دسترسی داشته باشند .

عملیات و یافتن عملیاتها

رفتارها و عملکردهای مربوط به یک کلاس هستند . با رجوع به نمودارهای توالی و همکاری می توان عملیاتها را استخراج کرد . بعد از مشخص شدن عملیلتها موارد زیر را در مورد کلاسها بررسی می نمائیم .

  1. کلاسهایی که دارای یک یا دو عملیات هستند بهتر است با هم ترکیب شوند .
  2. کلاسهایی که فاقد عملیات هستند بهتراست به عنوان یک یا چند صفت مدلسازی شوند .
  3. کلاسهایی که عملیاتهای زیادی دارند را بهتر است به دو یا چند کلاس کوچکتر تقسیم نمود .

برای افزودن عملیات به کلاس کافی است بر روی کلاس مورد نظر کلیک راست نموده و سپس گزینه New Operation را انتخاب کنید . به این ترتیب می توانید به کلاس خود عملیات جدید اضافه کنید .

 

فایل PDF درس پانزدهم

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

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

نمودارهای کلاس ( Class )

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

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

بطور پیش فرض یک نمودار کلاس وجود دارد که Main ( اصلی ) نامیده شده و مستقیماً زیر نظر نمای Logical است . این نمودار کلاس بسته ها و کلاس های موجود در مدلتان را نمایش می دهد .داخل هر بسته ای نمودار دیگری است که Main ( اصلی ) نامیده می شود ، که شامل همه کلاس های داخل آن بسته است .

نمودار کلاس یک ابزار طراحی خوب برای تیم می باشند . آنها به برنامه نویسان کمک می کنند تا ساختار سیستم را قبل از اینکه کدی نوشته شود ، ببینند و طراحی کنند و کمک می کنند تا مطمئن شوند که سیستم از ابتدا خوب طراحی شده است .

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

  1. نام کلاس که می توان در ادامه نام کلاس نام بسته را نیز بکار برد .
  2. صفات که می تولند به سه صورت Private , Public , Protected باشند .
  3. اعمال که می توانند به سه صورت Private , Public , Protected باشند .

منابعی جهت استخراج کلاسها

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

 

راههای تجربی جهت شناسایی کلاسها

    1. کلاسها معمولاً حاوی اطلاعاتی هستندکه سیستم قصد دارد بصورت دارز مدت آنها را ثبت و پردازش کند .
    2. یک کلاس حتماً باید دارای صفت باشد .
    3. یک کلاس حتماً یک کلید داشته باشد که کلاس و اجزاء آن را تفکیک نماید .
    4. یک کلاس باید بیش از یک نمونه را تولید کند .

 فایل PDF درس چهاردهم

RUP Phases 

 Inception (آغازین)

هدف اصلی این فاز دستیابی به توافق میان کلیه‌ی ذینفعان بر روی اهداف چرخه‌ی حیات پروژه است. فاز Inception به دلیل تلاشهای تولید و توسعه جدید به صورت پایه‌ای اهمیت فراوانی دارد که در آن ریسک‌های نیازسنجی و تجاری مهمی وجود دارد که باید پیش از اینکه اجرای پروژه مورد توجه قرار گیرد، بررسی شوند. برای پروژه‌هایی که بر توسعه سیستم موجود متمرکزند، فاز Inception کوتاهتر است، با اینحال این فاز برای حصول اطمینان از اینکه پروژه ارزش انجام دادن دارد و امکان‌پذیر نیز هست، انجام می‌شود. اهداف اصلی فاز آغازین شامل موارد زیر است :‌
  • بدست‌ آوردن محدوده نرم‌افزاری پروژه و محدودیت‌های آن که شامل یک دید عملیاتی، معیار پذیرش و اینکه چه چیز باید در محصول باشد و چه چیز نباید باشد، می‌شود
  • مشخص کردن Use-Case های اساسی سیستم، سناریوهای اصلی عملیات که مسائل مربوط به طراحی اصلی را ایجاد می‌کند.
  • نمایش و شاید توضیح حداقل یک معماری کاندیدا برای بعضی سناریوهای اصلی
  • برآورد هزینه و زمان کلی برای کل پروژه
Elaboration (جزییات)
هدف فاز جزئیات تعیین معماری کلی سیستم به منظور فراهم آوردن یک زمینه‌ی مناسب برای قسمت عمده‌ی طراحی و پیاده‌سازی در فاز Construction است. معماری با درنظرگرفتن بیشتر نیازمندی‌های مهم (آن دسته از نیازمندی‌ها که تأثیر زیادی بر معمار سیستم دارد) و نیز ارزیابی ریسک کامل می‌شود. پایداری معماری از طریق یک یا چند نمونه‌ی اولیه ساختاری ارزیابی می‌‌شود. اهداف اصلی فاز جزئیات شامل موارد زیر است :
  • اطمینان از اینکه معماری، نیازمندی‌ها و طرح‌ها به اندازه‌ی کافی پایدارند و ریسک‌ها به اندازه‌ی کافی کاهش یافته‌اند بطوریکه بتوان هزینه و زمان‌بندی لازم برای تکمیل تولید را پیش‌بینی کرد. برای اکثر پروژه‌ها، گذر از این مرحله‌ی مهم مانند انتقال از یک عملیات سبک و سریع و با ریسک پایین به یک عملیات با هزینه و ریسک بالا همراه با اجبار سازمانی است.
  • بیان همه‌ی ریسک‌های پروژه که از نظر ساختاری اهمیت دارند.
  • ایجاد یک معماری پایه، مشتق شده از سناریوهای مهم که از لحاظ ساختاری اهمیت دارند، که این معماری ریسک‌های فنی عمده پروژه را نیز مشخص می‌کند.
  • تولید یک نمونه‌ی اولیه‌ی تکاملی از مولفه‌های با کیفیت تولیدی خوب، و همچنین یک یا چند نمونه‌ی اولیه‌ی اکتشافی و نمونه‌های اولیه‌ی غیر قابل استفاده جهت کاهش ریسکهای خاص مانند :‌
    • سازش‌های مربوط به نیازمند‌ی‌ها یا طراحی
    • استفاده‌ی مجدد از مؤلفه‌ها
    • عملی بودن محصول یا توضیحات برای سرمایه گذاران، مشتریان و کاربران نهایی
  • توضیح اینکه معماری پایه از نیازمندی‌های سیستم با هزینه‌ی منطقی و در زمان منطقی پشتیبانی می‌کند
  • ایجاد یک محیط پشتیبانی کننده
  Construction (ساخت)
هدف این فاز واضح سازی نیازمندی‌های باقیمانده و تکمیل تولید سیستم بر اساس معماری مبنا می‌باشد. فاز ساخت به نوعی یک فرآیند ساخت است که در آن تأکید بر مدیریت منابع و کنترل عملیات به منظور بهینه‌سازی هزینه‌ها، زمان‌بندی‌ها و کیفیت است. در این حالت یک انتقال از تولید یک نمونه‌ی ذهنی در طی فازهای Inception و Elaboration به تولید محصولات قابل استقرار در طی Construction وTransition می‌شود. اهداف اصلی فاز Construction شامل موارد زیر می‌باشد :
  • کمینه کردن هزینه‌های تولید با بهینه‌سازی منابع و پرهیز از دور انداختن و دوباره‌کاری غیر ضروری
  • دستیابی هرچه سریعتر به کیفیت کافی
  • دستیابی هر جه سریعتر به ویرایش‌های مفید (آلفا، بتا و سایر نسخه‌های تست)
  • کامل کردن تحلیل، طراحی، تولید و تست کارآیی مورد نیاز
  • تولید تکراری و گام به گام یک محصول کامل که آماده‌ی انتقال به محیط کاربران باشد
  • تصمیم در مورد اینکه آیا نرم‌افزار، سایت‌ها و کاربران همه برای استقرار طرح آمادگی دارند
  • دستیابی به میزانی از موازی سازی در کار تیم‌های تولید.
  Transition (انتقال)
تمرکز این فاز بر این است که تضمین نماید نرم‌افزار برای کاربران نهایی آماده می‌باشد. فاز Transition می‌تواند به چندین تکرار تقسیم شود، و شامل تست کردن محصول برای آماده‌سازی جهت انتشار و ایجاد تنظیمات کوچک بر اساس بازخورد کاربر می‌باشد. در این نقطه از چرخه‌ی حیات، بازخورد کاربر باید بطور عمده بر تنظیم دقیق محصل، پیکربندی، نصب و نکات مربوط به قابلیت استفاده تمرکز یابد، و همه‌ی نکات ساختاری اصلی باید هرچه زودتر در چرخه‌ی حیات پروژه طرح شوند. با به اتمام رسیدن فاز Transition اهداف چرخه‌ی حیات باید برآورده شده باشند و پروژه در موقعیتی باشد که بتوان آنرا خاتمه داد. در برخی موارد، پایان چرخه‌ی حیات فعلی ممکن است با آغاز چرخه‌ی حیات بعدی در مورد همان محصول همزمان شود و ما را به سمت تولید یا ویرایش دیگری هدایت کند. برای پروژه‌های دیگر، پایان فاز Transition ممکن است با تحویل کامل خروجی‌ها به گروه سومی که ممکن است مسؤول عملیات نگهداری و پیشرفت سیستم تحویل دهده شده می‌باشند، همزمان شود. این فاز بر اساس نوع محصول در فاصله‌ی بسیار ساده تا بی‌نهایت پیچیده قرار دارد. نصب یک نسخه‌ی جدید از یک بسته نرم‌افزاری موجود ممکن است بسیار ساده باشد، در حالیکه جایگزینی سیستم کنترل ترافیک هوایی یک کشور ممکن است بسیار پیچیده باشد. فعالیت‌هایی که در طول یک تکرار در فاز Transition انجام می‌گیرد به هدف بستگی دارند. برای مثال معمولاً در هنگام رفع اشکالات، پیاده‌سازی و تست کافی هستند. با این وجود اگر ویژگیهای جدیدی باید اضافه شوند، این تکرار شبیه به تکراری در فاز Construction می‌شود که نیازمند تحلیل و طراحی و غیره است. فاز Transition زمانی وارد عمل می‌شود که یک خط مبنا آنقدر بالغ شده که بتواند در دامنه‌ی کاربر نهایی استقرار یابد. این امر بطور نمونه نیازمند این است که تعدادی زیر مجموعه‌ی قابل استفاده از سیستم با کیفیت قابل قبول و مستندات کاربر، کامل شده باشند، تا انتقال به کاربر نتایج مثبتی را برای همه‌ی گروه‌ها در بر داشته باشد. اهداف مهم فاز Transition عبارتند از :
  • تست بتا برای تشخیص اعتبار سیستم جدید با توجه به انتظارات کاربر
  • تست بتا و عملیات موازی همراه با یک سیستم قدیمی که در حال جایگزینی می‌باشد.
  • تبدیل پایگاه‌های داده‌ی عملیاتی
  • آموزش کاربران و نگهداری کنندگان
  • بازاریابی، توزیع و فروش برای نخستین انتشار محصول
  • تنظیم فعالیت‌ها از قبیل رفع اشکال، افزایش کارایی و قابلیت استفاده
  • ارزیابی خط مبناهای استقرار در مقایسه با تصویر کلی و معیار قابلیت قابل قبول برای محصول
  • دستیابی به موافقت ذینفع در مورد اینکه خط مبناهای استقرار کامل می‌باشند
  • دستیابی به موافقع ذینفع در مور اینکه خط مبناهای استقرار با معیار ارزیابی تصویر کلی سازگارند.
منبع : http://www.smhoseyni.com/rup_phases.htm

شهادت مولی الموحدین حضرت علی (ع) بر تمام شیعیان جهان تسلیت باد .

 

بهبود سازماندهی زبان
با پیمانه‌ای (Modular) کردن زبان، علاوه بر اینکه برای کاربران جدید امکان شناخت و استفاده ساده‌تر خواهد بود، همکاری میان ابزارها را نیز تسهیل می‌کند. در واقع معماری بهتری برای زبان ایجاد شده است. با توجه به افزایش دقت UML 2.0، تعاریف زبان بزرگ‌تر شده‌اند و در نتیجه چنانچه از همان ساختار و معماری UML 1 برای آن استفاده می‌شد، فهم و استفاده از آن را بسیار مشکل می‌ساخت. به منظور مقابله با مشکل پیچیدگی زبان، UML 2.0 بصورت پیمانه‌ای درآمده است تا امکان استفادة انتخابی از پیمانه‌های زبان فراهم شود. شکل کلی این ساختار در شکل 2 نمایش داده شده است. همانطور که مشاهده می‌شود از یک پایه که شامل عناصر به اشتراک گذاشته شده است (مانند کلاس‌ها و روابط association)، که بر روی آن مجموعه‌ای از زیر-زبان‌ها یا عناصر زبان وجود دارد. هر کدام از این زیر-زبان‌ها برای مدل‌سازی یک قالب یا جنبة بخصوص مناسب هستند. این عناصر در Error! Reference source not found. نمایش داده‌شده اند. این عناصر افقی زبان بطور معمول از یکدیگر مستقل هستند و بنابر‌این شما می‌توانید آنها را بصورت مستقل استفاده کنید (برخلاف UML 1 که بعنوان مثال activity diagram بطور کامل بر روی state diagram قرار گرفته بود).
UML 2 Architecture
شکل 2- معماری زبان UML 2.0
علاوه‌بر این عناصر افقی زبان بصورت سلسله‌مراتبی در سه سطح سازمان‌دهی شده‌اند که سطح بالاتر قابلیت‌های بیشتری نسبت به سطح پایین‌تر دارد. به این ترتیب زبان از یک بعد دیگر نیز پیمانه‌ای است و شما را قادر می‌سازد که حتی در یک واحد زبان هم یک زیرمجموعة بخصوص را انتخاب کنید. این ساختار معماری زبان شما را قادر می‌سازد که تنها یک زیر مجموعه از UML را بیاموزید و بکار ببرید که مناسب کار شما است و به مرور زمان و کسب تجارب بیشتر می‌توانید با عناصر قدرتمند‌تر زبان آشنا شوید و در هنگام نیاز از آنها استفاده کنید.
جدول 1- عناصر زبان UML 2.0
Purpose Language Unit
(Foundation) modeling of fine-grained actions Actions
Data and control flow behavior modeling Activities
(Foundation) modeling of basic structures Classes
Complex structure modeling for component technologies Components
Deployment modeling Deployments
(Foundation) common behavioral semantic base and time modeling General Behaviors
Abstract data flow modeling Information Flows
Inter-object behavior modeling Interactions
Model organization Models
Language customization Profiles
Event-driven behavior modeling State Machines
Complex structure modeling Structures
Pattern modeling Templates
Informal behavioral requirements modeling Use Cases

بهبود قابل توجه در توانایی برای مدل کردن سیستم‌های نرم‌افزاری بزرگ
برخی از نرم‌افزارهای کاربردی مدرن تجمیع برنامه‌های کاربردی مستقل را در قالب سیستمی از سیستم‌ها نمایان می‌سازند و این روندی است ادامه دار که منجر به پیچیده‌تر شدن سیستم‌ها خواهد شد. برای پشتیبانی از چنین روند‌هایی، قابلیت‌های جدید انعطاف‌پذیرِ سلسله‌مراتبی به زبان اضافه شده است تا از مدل‌سازی نرم‌افزار در سطوح دلخواه پیچیدگی پشتیبانی کند. بطور کلی تعداد قابلیت‌های جدید اضافه شده به UML 2.0 کم است تا از بزرگ شدن زیاد زبان جلوگیری شود و بخش عمده‌ای از این قابلیت‌های جدید مدل‌سازی، گسترشی بر استفاده از قابلیت‌های جدید است که به شما امکان مدل‌سازی سیستم‌های نرم‌افزاری بزرگ را می‌دهد. علاوه‌براین، این گسترش‌ها با استفاده از یک راهکار پایه‌ای یکسان بدست‌ آمده‌اند : استفادة بازگشتی از مجموعة یکسانی از مفاهیم در سطوح مختلف تجرد. بدین معنی که شما می‌توانید عناصر مدل‌سازی مربوط به یک گونه بخصوص را با یکدیگر ترکیب کنید تا واحد‌هایی ایجاد شود که بعنوان بلوک‌های سازنده در سطح بعدی تجرد مورد استفاده قرار گیرند. این وضعیت قابل مقایسه با روشی است که در برنامه‌نویسی procedure ها می‌توانند تا چندین سطح در داخل یکدیگر فراخوانی شوند(Nested Procedure Call). بطور مشخص، قابلیت‌های مدل‌سازی زیر بدین روش توسعه یافته‌اند :
  • ساختارهای پیچیده (Complex Structures)
  • فعالیت‌ها (Activities)
  • تعامل‌ها (Interactions)
  • ماشین‌های حالت (State machines)
سه تای اول از لیست بالا 90% قابلیت‌های جدید UML 2.0 را شکل می‌دهند.
ساختارهای پیچیده (Complex Structures)
به این منظور عناصر پایه‌ای ساختاری که part نامیده می‌شوند ممکن است یک یا چند درگاه (port) داشته باشند که با استفاده از کانال‌های ارتباطی که اتصال‌دهنده (connector) نامیده می‌شوند (همانگونه که درشکل 3 نمایش داده شده است) به یکدیگر متصل شده‌اند. این ساختار تجمعی می‌تواند در داخل عناصر سطح بالاتر کپسوله شود که port های خود را دارند و می‌توانند با عناصر سطح‌بالاتری متصل شوند و به همین ترتیب عناصر سطح بالاتری می‌توانند ساخته شوند.
UML 2 Complex Structure
شکل 3- مفاهیم مدل‌سازی ساختارهای پیچیده

فعالیت‌ها (Avtivities)
Activity ها در UML برای مدل‌کردن انواع مختلفی از جریان مورد استفاده قرار می‌گیرد : جریان signal یا data، و نیز جریان‌های algorithmic یا procedural. در UML 1 یک محدودیت عمده برای Activity ها وجود داشت و آن هم این بود که آنها بر پایه ماشین حالت قرار گرفته‌ بودند و بنابراین در حوزة معنایی ماشین‌های حالت محدود شده بودند. در UML 2.0 پایة ماشین‌ حالت با یک چارچوب معنایی عمومی دیگر که تمام این محدودیت‌ها را حذف کرده است جایگزین شده است. (در واقع، پایة معنایی با استفاده از petri net colored های عمومی‌شده جایگزین شده است). علاوه‌ بر این از برخی استانداردهای صنعتی برای مدل‌سازی فرآیندهای کسب و کار مانند BPEL4WS الهام گرفته است.
تعامل‌ها (Interactions)
تعامل‌های میان اشیاء در UML 1 یا با استفاده از collaboration diagram و یا با استفاده از sequence diagram نمایش داده می‌شدند. لکن متأسفانه دو قابلیت اساسی جا افتاده بودند :‌
  1. امکان استفادة مجدد از توالی‌ها که ممکن بود در متن دنباله‌های دیگر تکرار شوند. بعنوان مثال، یک دنباله که هویت‌شناسی کاربر را انجام می‌دهد ممکن است در چندین جای مختلف یک برنامة کاربردی رخ دهد. بدون امکان بسته‌بندی این دنباله‌های تکرار شونده در عناصر جداگانه، لازم بود که آنها را چندین مرتبه بیان کنید که علاوه بر افزودن سربار اضافی، نگهداری مدل‌ را نیز مشکل‌تر می‌کرد.
  2. امکانات کافی برای مدل‌کردن جریان‌های پیچیده مختلف که در بازنمایی تعاملات سیستم‌های پیچیده رایج هستند. این قابلیت‌ها شامل تکرارکردن یک زیردنباله، مسیرهای اجرایی آلترناتیو، اجراهای همروند و مستقل از ترتیب، حلقه، شرط و موارد مشابه می‌شود.
مهمترین نوآوری در این زمینه معرفی تعامل‌ها (Interaction) بصورت یک واحد مدل‌سازی جداگانه نامگذاری شده است که امکان پارامتری کردن آنها نیز وجود دارد و بنابراین می‌توان هر سطح پیچیدگی دلخواهی از تعامل‌های میان اشیاء را در یک نمودار تعامل مدل کرد.
UML 2 Complex Sequence Diagram
شکل 4 - مثالی از یک مدل تعاملی پیچیده
همانگونه که در شکل 4 نشان داده شده است شما می‌توانید این تعاملات بسته‌بندی شده را در تعاملات سطح بالاتر بصورت بازگشتی فراخوانی کنید.
ماشین‌های حالت (State Machine)
مهمترین قابلیتی که ماشین‌های حالت در UML 2.0 اضافه شده است کاملا مشابه موارد قبلی است. ایدة اصلی این است که شما می‌توانید یک ماشین حالت پیچیده را کاملا بصورت پیمانه‌ای مدل کنید که دارای نقاط مشخصی برای ورود و خروج است. به این ترتیب شما می‌توانید تجزیه داخلی یک ماشین حالت را بوسیله یک مجموعه از ماشین‌‌های حالت جداگانه و قابل استفاده انجام دهید. به این ترتیب توصیف یک الگوی رفتاری مشترک در چند حوزة مختلف به سادگی انجام می‌پذیرد.
UML 2 State Diagram
شکل 5- نمونه‌ای از نمودار حالت در UML 2.0


بهبود پشتیبانی برای سفارشی سازی برای یک حوزه بخصوص
تجارب عملی استفاده از UML ارزش مکانیزم‌های توسعه (Extension) آنرا نمایان ساخته است. در UML 1.x‌ فقط از مکانیزم‌های توسعة stereotype و profile استفاده می‌شد، لکن در UML 2.0 مکانیزم توسعة جدید metamodel اضافه شده است که امکانات توسعة سطح بالاتری را فراهم می‌کند.
تقویت، تطابق با اصول، روشنی و وضوح بیشتر برای مفاهیم مختلف مدل‌سازی
زبان ساده‌تر و سازگارتر شده است. اقدامات جدید شامل تقویت و تثبیت مفایهم و – در بعضی موارد – حذف مفاهیم تکراری، پالایش چندین تعریف و افزودن توضیحات متنی و مثال بوده است.

منبع : www.smhoseyni.com/notes/uml2.htm