با عرض سلام خدمت دوستان

از دوستانی که ما را در بهتر و پر بارتر کردن مطالب وبلاگ یاری می رسانند کمال سپاس گذاری را د اریم . یک نکته که شما عزیزان باید در جریان آن باشید این است که من هم مثل خیلی از شماها دانشجو هستم و تنها در آخر هفته وقت می کنم به وبلاگ سر بزنم و ایمیلهایم را چک کنم . لذا دوستان مطمئن باشند که نظرات ارسالی شما حتماً بررسی خواهد شد ( با فاصله زمانی دو سه روز ) .

یکی از دوستان در رابطه با آموزش SSADM مطلب خواسته بودند که به زودی آموزش این متدولوژی را با یک مثال عملی شروع می کنیم . در یکی از یادداشتهای مربوط به SSADM به مراحل کار را به ترتیب اشاره کرده ایم .

مهندسی معکوس با استفاده از Rational Rose :

مهندسی معکوس عبارت است از توانایی گرفتن اطلاعات از کد منبع و ایجاد یا ارتقاء مدل Rose .

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

در فرایند مهندسی معکوس ، Rose نسبت به خواندن بسته ، Component ها ، کلاسها رابطه ها ، صفات و عملیات از کد اقدام خواهد کرد . هنگامی که این مدل در یک مدل Rose قرار می گیرد ، می توانید هر تغییر لازمی را ایجاد کرده سپس کد را از طریق امکانات مهندسی مستقیم Rose مجدداً تولید کنید .

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

• Rose Modeler : شامل هیچ گونه عملیات مهندسی معکوس نخواهد بود .
• Rose Professional : شامل قابلیت های مهندسی معکوس به یک زبان است .
• Rose Enterprise : شامل مهندسی معکوس C++ ،  Visual C++ ، Visual Basic و جاوا خواهد بود .همانطور مهندسی معکوس شمای Oracle 8 را نیز شامل خواهد بود .
• Add_ins : متعلق به Rose قابلیتهای مهندسی معکوس در زبانهای دیگر نظیر PowerBuilder یا Forte را به شما خواهند داد .

عناصر مدل ایجاد شده در طول مهندسی معکوس :

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

• کلاسها
• صفات
• روابط
• عملیات
• بسته ها
• component ها

با استفاده از این اطلاعات ، Rose اقدام به ایجاد یا ارتقاء یک مدل Object خواهد کرد .

مستندات Use Case ( بخش اول )

دوستان بخش اول مستندات Use Case جهت استفاده شما آماده شده است . با توجه به این که این متن توسط مدیر ترجمه شده ، به دلیل اشکالات احتمالی در جمله بندی از شما عزیزان پوزش می طلبیم .

هر یک از مستندات Use Case برای نمایش ضمیمه ها بکار می روند . در این بخش شرح کاملی از هر یک از بخشهای الگوی Use case آماده شده است .

  تعیین هویت Use Case

        ·        شماره Use Case  : هر یک از Use Case ها باید توسط یک عدد   صحیح بی همتا مشخص شود . برای شماره گذاری متناوب Use Case هایی که در یک گروه قرار دارند از شکل X:Y استفاده می شود .

·        نام Use Case  : توضیح مختصری برای نامی که برای Use Case انتخاب شده است . این نام ها وظیفه های مورد نیاز که برای انجام نیازهای سیستم که شامل یک کار یا اسمی که شبیه مثالهای زیر است را منعکس می کند .

1)     نمایش اطلاعات قسمت عددی

2)     نشانه گذاری دستی منابع و فرامتنها و ایجاد لینک به مقصد

3)     مکان یک دستورالعمل برای CD با بروز شدن نسخه نرم افزار

·        تاریخچه Use Case  :

1)     چه کسی Use Case را ایجاد کرده است .

2)     در جه تاریخی Use Case ایجاد شده است .

3)     آخرین بار توسط چه کسی به روز شده است .

4)     تاریخ آخرین به روز رسانی چه موقع بوده است .

با عرض سلام خدمت دوستان

از اینکه با نظرات خود ما را در پربار تر کردن وبلاگ خود یاری می رسانید بسیار سپاس گذاریم . متاسفانه به دلیل حجم زیاد درسها حدود یک ماهی است که مطلب جدیدی در وبلاگ قرار نگرفته است . ولی انشاالله در هفته جاری متنی را با عنوان " یوزکیس ها برای پروژه " که در بر گیرنده مطالب مفیدی در مورد به کار گیری یوزکیس ها در پروژه و نحوه مستند سازی یوزکیس های پروژه می باشد ، ترجمه و برای استفاده شما عزیزان در وبلاگ قرار خواهد گرفت. یکی از دوستان مطالبی در مورد مهندسی معکوس در زمینه دیاگرامهای UML در خواست کرده که باز هم سعی می کنم در چند روز آینده مطلب را آماده کنم . یکی دیگر از دوستان مباحث مربوط به طراحی را درخواست کرده اند . در مورد طراحی ، به خصوص طراحی بانکهای اطلاعاتی ما باید پس از تجزیه و تحلیل صحیح و دقیق به سراغ طراحی پایگاه داده خود برویم و با یک مدل ( مثل EER ) ، بانک اطلاعات خود را ترسیم و سپس پیاده سازی کنیم . همچنین با یکی از زبانهای برنامه نویسی موجود ( مثل VB یا دلفی ) کدهای برنامه خود را ایجاد نمائیم ( در مورد زبانهای برنامه نویسی سایتهای زیادی وجود دارند که دوستان می توانند از آنها استفاده کنند ) . انشاالله بزودی نیز در مورد چگونه مدل کردن بانک اطلاعاتی ، مطالبی برای استفاده در وبلاگ مهندسی نرم افزار قرار خواهد گرفت . در پایان از کلیه دوستان دعوت می شود که مطالب و مقالات خود را در زمینه های مربوط به مهندسی نرم افزار ، برنامه نویسی ، پایگاه داده و ... را برای ما ارسال تا سایر کاربران از آن استفاده کنند .

با تشکر

عید سعید فطر مبارک باد

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

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

درس پانزدهم{ کلاس دیاگرام ۲ ( Class Diagram ) }

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 Diagram )}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

فازها و milestone های یک پروژه در RUP

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

شهادت حضرت علی (ع)

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

UML 2.0 ( بخش دوم)

بهبود سازماندهی زبان
با پیمانه‌ای (Modular) کردن زبان، علاوه بر اینکه برای کاربران جدید امکان شناخت و استفاده ساده‌تر خواهد بود، همکاری میان ابزارها را نیز تسهیل می‌کند. در واقع معماری بهتری برای زبان ایجاد شده است. با توجه به افزایش دقت UML 2.0، تعاریف زبان بزرگ‌تر شده‌اند و در نتیجه چنانچه از همان ساختار و معماری UML 1 برای آن استفاده می‌شد، فهم و استفاده از آن را بسیار مشکل می‌ساخت. به منظور مقابله با مشکل پیچیدگی زبان، UML 2.0 بصورت پیمانه‌ای درآمده است تا امکان استفادة انتخابی از پیمانه‌های زبان فراهم شود. شکل کلی این ساختار در شکل 2 نمایش داده شده است. همانطور که مشاهده می‌شود از یک پایه که شامل عناصر به اشتراک گذاشته شده است (مانند کلاس‌ها و روابط association)، که بر روی آن مجموعه‌ای از زیر-زبان‌ها یا عناصر زبان وجود دارد. هر کدام از این زیر-زبان‌ها برای مدل‌سازی یک قالب یا جنبة بخصوص مناسب هستند. این عناصر در Error! Reference source not found. نمایش داده‌شده اند. این عناصر افقی زبان بطور معمول از یکدیگر مستقل هستند و بنابر‌این شما می‌توانید آنها را بصورت مستقل استفاده کنید (برخلاف UML 1 که بعنوان مثال activity diagram بطور کامل بر روی state diagram قرار گرفته بود).
شکل 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 های خود را دارند و می‌توانند با عناصر سطح‌بالاتری متصل شوند و به همین ترتیب عناصر سطح بالاتری می‌توانند ساخته شوند.
شکل 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) بصورت یک واحد مدل‌سازی جداگانه نامگذاری شده است که امکان پارامتری کردن آنها نیز وجود دارد و بنابراین می‌توان هر سطح پیچیدگی دلخواهی از تعامل‌های میان اشیاء را در یک نمودار تعامل مدل کرد.
شکل 4 - مثالی از یک مدل تعاملی پیچیده همانگونه که در شکل 4 نشان داده شده است شما می‌توانید این تعاملات بسته‌بندی شده را در تعاملات سطح بالاتر بصورت بازگشتی فراخوانی کنید.
ماشین‌های حالت (State Machine)
مهمترین قابلیتی که ماشین‌های حالت در UML 2.0 اضافه شده است کاملا مشابه موارد قبلی است. ایدة اصلی این است که شما می‌توانید یک ماشین حالت پیچیده را کاملا بصورت پیمانه‌ای مدل کنید که دارای نقاط مشخصی برای ورود و خروج است. به این ترتیب شما می‌توانید تجزیه داخلی یک ماشین حالت را بوسیله یک مجموعه از ماشین‌‌های حالت جداگانه و قابل استفاده انجام دهید. به این ترتیب توصیف یک الگوی رفتاری مشترک در چند حوزة مختلف به سادگی انجام می‌پذیرد.
شکل 5- نمونه‌ای از نمودار حالت در UML 2.0

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

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