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

با تبریک عید سعید فطر بر همه مسلمانان جهان به ویژه هم وطنان عزیزمان و قبولی طاعات و عبادات شما به درگاه حق تعالی به اطلاع شما کاربران محترم می رسانم که دروره آموزش 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

UML 2.0 ( بخش اول )

مقدمه
شاید برای شما هم این سؤال پیش آمده باشد که چه تغییر مهمی در UML رخ داده است که پس از UML 1.5، UML 2.0 عرضه شد؟ آیا اضافه شدن دیاگرام‌های جدید (مثل Timing Diagram) یا بهبود دیاگرام‌های موجود (مانند افزودن امکانات بیشتر به Sequence Diagram ) موجب این ارتقاء قابل توجه شده است؟ حقیقت این است که آنچه که موجب این ارتقاء‌ نسخه قابل توجه از 1 به 2 شده است، فراتر از این جزئیات است. آنچه که تولید مدل‌گرا (Model Driven Development) نامیده می‌شود، که بر پایه سطح تجرد بالاتر و استفادة بیشتری از تولید خودکار کد نسبت به روش‌های سنتی قرار دارد، اثر قابل توجه خود در بهبود کیفیت نرم‌افزار و بهره‌وری تولید نشان داده است. از آنجاییکه نقش زبان مدل‌سازی برای موفقیت MDD بسیار مهم است، یک تجدید نظر عمده در زبان استاندارد UML انجام شده است که منجر به عرضه UML 2.0 گردیده است. درعین حال که چندین قابلیت جدید مدل‌سازی اضافه شده است – مانند قابلیت بیان دقیق‌‌تر معماری نرم‌افزار - خصوصیت غالب این بازبینی عمده، زیاد کرد دقچت قابلیت تعریف زبان است که سطح بالاتری از خودکارسازی را فراهم می‌کند. در ادامه شرح خواهیم داد که UML2.0 چگونه به این موارد دست یافته است و سایر جنبه‌های مهم آنرا نیز بیان خواهیم کرد. همان‌گونه که می‌دانید UML بوسیله تولیدکنندگان بزرگ ابزارهای مدل‌سازی پذیرفته و پشتیبانی می‌شود، و بصورت یک بخش ضروری از دانش مهندسی نرم‌افزار در‌آمده است و در دانشگاه‌ها نیز تدریس می‌شود. همچنین نقش مهمی در مدل‌سازی نرم‌افزارهای پیچیده ایفا می‌کند. اما با وجود همه این مزایا همچنان مقاومت‌هایی در برابر استفاده از UML وجود دارد. دلایل زیادی برای این وضعیت وجود دارد، لکن یکی از مهمترین آنها این است که مدل‌های نرم‌افزار ممکن است در بعضی موارد بسیار نادقیق باشند و ارزش کاربردی هر مدلی با میزان دقت و صحت آن تناسب مستقیم دارد. چنانچه شما نتوانید به یک مدل از یک سیستم‌ نرم‌افزار اعتماد کنید، بدتر از حالتی است که مدلی وجود نداشته باشد، زیرا ممکن است منجر به تصمیم‌گیری غلط شما شود. بنابراین بهترین راه‌حل افزایش ارزش مدل‌های نرم‌افزاری کم کردن فاصلة میان آنها و سیستمی است که آنرا مدل‌ کرده‌اند. جالب است بدانید - همانطور که در ادامه بیان خواهیم کرد- در مهندسی نرم‌افزار بیش از سایر رشته‌های مهندسی این کاهش فاصله امکان‌پذیر است.
Model-Driven Development
راه‌حل این معما اتصال دقیق یک مدل به معادل پیاده‌سازی نرم‌افزاری آن با استفاده از یک یا چند تبدیل مدل خودکار است. شاید بهترین مثال یک کامپایلر باشد، که یک برنامه که به زبان سطح بالا نوشته شده است را به متناظر سطح ماشین آن برنامه تبدیل می‌کند. مدل، در این حالت، نقش آن زبان سطح بالا را ایفا می‌کند که جزئیات غیر ضروری را نمایش می‌دهد. جالب است توجه کنید در هیچ یک از رشته‌های مهندسی دیگر نمی‌توانند این ارتباط قوی بین مدل و فرآوردة مهندسی آن ایجاد کنند. زیرا فرآورده‌ای که شما آنرا مدل می‌کنید نرم‌افزار است و نه سخت‌افزار. یک مدل از هر نوع از فرآورده‌های فیزیکی (بعنوان مثال، یک اتومبیل، ساختمان، پل و موارد دیگر) هنگام مدل‌کردن نیاز به یک‌سری حذف جزئیات و مجرد‌سازی است که بصورت غیر دقیق انجام می‌شود و هنگام ساخت یک فرآورده مهندسی از روی مدل مجرد نیز لازم است یک سری تبدیل‌های غیر دقیق انجام شود. ماهیت این تبدیل‌ها به دلیل عدم دقتی که دارند ممکن است مدل‌ها را به یک موجودیت ناکارا یا حتی مزاحم تبدیل کنند. حال آنکه در نرم‌افزار این تبدیل‌ها، بطور کلی، می‌توانند بصورت کاملا دقیق و قاعده‌مند انجام شوند. پتانسیلی که در ورای این ترکیب قدرتمند تجرد و خودکارسازی وجود دارد منجر به ظهور تکنولوژی مدل‌سازی جدیدی به همراه روش‌های تولید متناظر با آن شده است که با عنوان تولید مدل‌گر (model-driven development) شناخته می‌شود. ویژگی اصلی MDD این است که مدل‌ها به فرآوردة اصلی طراحی نرم‌افزار بدل گشته‌اند، که منجر به انتقال تمرکز بیشتر از کد برنامه به مدل می‌شود. با دقیق‌تر شدن مدل‌ها (که UML 2.0 این قابلیت را فراهم می‌آورد) سطح خودکارسازی تولید کد از روی مدل افزایش پیدا می‌کند و مزایای MDD بیشتر نمایان می‌شوند. لازم به ذکر است که پیش از این هم در عمل MDD مورد استفاده قرار گرفته است، لکن در حال حاضر به دلیل رشد و افزایش قابلیت تکنیک‌ها و استانداردها (مانند UML 2) این امکان بیشتر فراهم شده است و MDD بیشتر مورد توجه قرار گرفته است.

اهمِ موارد جدید در UML 2.0
توسعه‌های جدیدی که در UML 2.0 انجام شده است را می‌توان در این پنج دسته عمده گروه‌بندی کرد که در ادامه به ترتیب اهمیت بیان شده‌اند.
افزایش قابل توجه میزان دقت در تعاریف زبان ‌
که نتیجه نیاز به پشتیبانی از خودکار‌سازی سطح بالاتری است که برای MDD لازم است. لازمة خود کار‌سازی رفع ابهام و عدم دقت از مدل‌ها (و در نتیجه از زبان مدل‌سازی) است تا برنامه‌های کامپیوتر ی بتوانند مدل‌های را تبدیل به کد کنند. یکی از اقداماتی که به منظور کمینه کردن ابهامات و افزایش دقت مدل انجام شده است استفاده از metamodel است. این مدل خصوصیات هر عنصر مدل‌سازی UML و ارتباط آن با سایر مفاهیم مدل‌سازی را تعریف می‌کند. این metamodel با استفاده از یک زیرمجموعه از عناصر UML - که بیشتر مفاهیم Class Diagram هستند و اصطلاحا Meta-Object Facility (MOF)   نامیده می‌شوند - تعریف شده است و بوسیله یک مجموعه از محدودیت‌های رسمی که به زبان Object Constraint Language (OCL)   نوشته شده است پشتیبانی می‌شود. بطور خلاصه میزان دقت تعاریف زبان UML 2.0 با روش‌های زیر بطور قابل توجهی افزایش یافته است :

• یک سازماندهی مجدد عمده در فراساختار metamodel
• توصیف‌های معنایی توسعه یافته و دقیق‌تر
• یک چارچوب معنایی پویا و شفاف به منظور پرکردن خلاء‌هایی که در این زمینه وجود داشت

شکل 1 - چارچوب معنایی UML 2.0

 

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

درس سیزدهم{ نمودار حالت ۳( State Chart Diagram ) }

همانطور که در درس گذشته بیان کردیم ، عمده کاربرد نمودار حالت در مدل سازی اشیاء سخت افزاری می باشد . به همین دلیل ما در این درس قصد داریم رفتار یک عابربانک را با نمودار حالت ( StateChart Diagram ) مدل کنیم .

فرض کنید یک Use Case به نام "پرداخت اتوماتیک" داریم که می خواهیم برای آن یک نمودار حالت را بر اساس فایل الصاقی به آن رسم کنیم . با هم دیگر نگاهی به این فایل الصاقی می اندازیم .

رفتار عابربانک

1. دستگاه منتظر ورود کارت می ماند .
2. با ورود کارت کلمه عبور و نام کاربری پرسیده می شود .
3. درصورت صحت کلمه عبور و نام کاربری منویی برای فرد نمایش داده می شود که شامل سه گزینه برداشت پول ، کنترل موجودی و خروج است .
4. اگر کلمه عبور و نام کاربری اشتباه بود دستگاه بوق می زند و تا دو بار این کار را انجام می دهد و برای بار سوم اگر کلمه عبور و نام کاربری اشتباه بود کارت را مصادره می کند .
5. اگر منوی کنترل موجودی انتخاب شد میزان موجودی برای فرد نشان داده می شود .
6. اگر برداشت انتخاب شد دستگاه صفحه ای را نشان می دهد که منتظر دریافت مبلغ برداشتی است .
7. مشتری مبلغ را نوشته و Enter می کند .
8. اگر میزان برداشتی بیشتر از موجودی بود یک پیغام به کاربر نمایش داده شود .
9. اگر میزان برداشتی کمتر از موجودی بود پول را از خروجی دستگاه به مشتری می دهد .

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

قسمت اول :

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

قسمت دوم :

با انتخاب گزینه نمایش موجودی در State " نمایش عملیات ممکن " به State " نمایش موجودی " می رویم . در این State به محض ورود مشتری از میزان موجودی در حساب خود آگاه می شود و گزینه برای خروج در ادامه کار برای او نمایان می شود . با انتخاب گزینه خروج دوباره به State " نمایش عملیات ممکن بر می گردیم .

قسمت سوم :

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

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