UML - مفاهیم مقدماتی

سلام
مطلب ذیل برای افرادی که هیچ آشنائی با UML ندارند مفید خواهد بود و هدف صرفا" معرفی اصول و ارائه تعاریف مقدماتی است .

---

لزومی نداره در مورد فوائد طراحی شیء گرای یک سیستم نرم افزاری توضیحات مفصلی ارائه بشه ، همگی کم و بیش در این باب مطالعاتی داشتید و واضح و مبرهنه که برای پیاده سازی صحیح و استفاده بهینه منابع باید طراحی ساختارمند و شیء گرای سیستم در اولویت باشه . کلید و راهیافت طراحی شیء گرا و مناسب یک سیستم نرم افزاری ، مدل ، است ! مدل ، ابزاری "بصری" ( Visual ) است ، برای چینش اجزاء مختلف سیستم نرم افزاری و نمایش روابط بین آنها و سایر موجودیتهای سیستم نرم افزاری . برای اینکه طراحی مدل برای سیستمهای نرم افزاری قالبی یکدست و یکپارچه و جهان شمول داشته باشد و تبادل اطلاعات بین مدلهای طراحی شده توسط افراد مختلف امکان پذیر باشد تلاشهای متعددی صورت گرفته است که UML یکی از آنهاست ، که در حال حاضر متداولترین استاندارد تولید مدل برای سیستمهای نرم افزاری در سراسر دنیاست . UML مخفف Unified Modeling Language است . UML برای مدل سازی سیستمهای نرم افزاری و تسهیل طراحی شیء گرای سیستم 9 دیاگرام ( و استانداردهای مرتبط با هرکدام ) را ارائه مینماید . قبل از توضیح بیشتر و ارائه تعاریف مقدماتی به نکته ذیل توجه کنید : دوستان کم تجربه اغلب سوال میکنند که چرا UML مهم است و این روزها مانور زیادی روی آن میشود ؟ آیا لزومی دارد که به UML مسلط شویم ؟ آیا اصولا" این جانور به درد ما میخورد ؟ :arrow: جوابی که من به این دوستان میدهم اینه : تا حالا دیده اید که کسی یک ساختمان بزرگ با پیچیدگیهای مختلف را "بدون نقشه" و الگوی از پیش معین شده بسازد و این پروژه موفقیت آمیز باشد ؟ آیا تا کنون شنیده اید که هیچ کدام از کارخانه های تلوزیون سازی بودن هیچ نقشه و پیش بینی فنی موفق به ساخت تلوزیونی شوند که کار کند ؟ یا اصلا" ساخته شود ؟ آیا تا کنون دیده اید کشوری بدون سیاستهای کلان و بدون سنجش جوانب امر ، موفق به مدیریت امور داخلی خود شود ؟ و ده ها سوال از این دست ! خواندن این سوالها بدون اینکه حتی ثانیه ای به جواب انها فکر کنید ، خود ، جواب به سوالات اولی است که عرض کردم ! UML به عنوان استانداردی برای طراحی و پیش بینی جزئیات فنی سیستم نرم افزاری ، نحوه ارتباط اجزاء ، نوع و نحوه کارکرد قسمتهای مختلف و ... یکی از ملزومات تولید کنندگان نرم افزار در دنیای امروز است . حتی اگر مستقل کار میکنید و نرم افزارهای کوچک تولید میکنید با استفاده از UML در "اغلب" موارد به بالاترین حد بهینگی مراحل طراحی و تولید نرم افزارتون خواهید رسید و نکته آخر این که UML و استانداردهای آن ( که در موردشون صحبت خواهم کرد ) و ابزارهای آن ( CASE Tool ها که موضوع مقاله بعدی هستند ) آنقدر ساده و سهل هستند که صرف هزینه و وقت برای یادگیری و تسلط بر آنها نسبت به مزایائی که در قبال آن کسب خواهید کرد تقریبا غیر قابل توجه است !

---

تعریف کلمات کلیدی و عناصر اصلی UML :

مدل : علاوه بر تعریفی که در قسمت قبلی ارائه شد ، مدل از تعدادی "شیء" تشکیل شده است .

شیء : هر یک از اجزاء نرم افزار یک "شیء" نام دارد .

کلاس: مشخصه ها و تعاریف عمومی یک "شیء" در کلاس مربوط به آن تعریف میشود . هر شیء نمونه ساخته شده از یک کلاس است . کلاس ، وظایف ، قابلیتها ، خصوصیتهای آن موجودیت نرم افزاری را تعریف میکند و طراح با ساختن یک نمونه از کلاس ( شیء ) و ارائه مقادیر مرتبط با محل خاص استفاده آن یا قرار دادن آن در مسیر وقایع لازم ، محیط مورد نظر خود را طراحی میکند . نمونه های مختلفی از یک کلاس در قالب اشیاء مختلف ساخته میشوند ، ضمن اینکه میتوان یک شیء را بطور همزمان از دو یا تعداد بیشتری کلاس ساخت . یعنی شی مذکور تمام مشخصه های کلاسهای فوق خود را به "ارث" خواهد برد .

در یک مدل شیء گرا ، شیء ها از طریق Message ها با یک دیگر ارتباط برقرار میکنند . یک نمونه Message ، فشرده شدن کلید چپ ماوس وقتی اشاره گر آن روی یک Button ، میباشد . اینجا ماوس ( به عنوان یکی از اشیاء موجود در هر سیستم نرم افزاری ) به شیء دیگری بنام Button ( که مثلا" از CButton یا TButton که کلاسهای فوق آن هستند ساخته شده است ) یک Message ارسال نموده است .

هر شیء دارای تعدادی مشخصه یا Attribute است . مشخصه های یک شیء حاوی مقادیر مختلف اجزاء آن شیء هستند . به عنوان یک مثال ساده وقتی مختصات یک کلید روی فرم 20 و 40 است ، یعنی مشخصه های طول و ارتفاع آن 20 و 40 هستند . ( مشخصه تعاریف پیچیده تری هم داره که خواهید دید . اول کار فقط خیلی ساده مثال میزنم )

اشیاء "میتوانند" کارهائی انجام دهند که به آنها اصطلاحا" Behavior میگویند . به عنوان مثال وقتی ماژول رمزنگاری نرم افزار شما میتواند درهم سازی با متد MD5 هم انجام دهد ، این توانائی یکی از Behavior های این شیء محسوب میگردد .

---

دیاگرامهای UML :

1.Use Case Diagram
2.Class Diagram
3.Object Diagram
4.Sequence Diagram
5.Collaboration Diagram
6.StateChart Diagram
7.Activity Diagram
8.Component Diagram
9.Deployment Diagram

---

در مطالب بعدی هر کدام از این دیاگرامهای شرح داده میشود و برای هر کدام مثالهائی ارائه میشود .

موفق و سلامت باشید


---

چند روز پیش میخواستم بنویسم پس ادامه اش چی شد ... که دیدم کتاب UML هم تو بازار هست ....

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

Use Case Diagram

این نوع نمودارها برای پاسخگوئی به این سوال فراهم میشوند : " این سیستم نرم افزاری چه میکند ؟ "

فکر میکنم جمله فوق کوتاه ترین تعریفی بود که میشه برای نمودارهای Use Case ارائه کرد . در طراحی اینگونه نمودارها باید توجه کنید که یک "بیننده خارجی" قرار است سیستم شما را بررسی کند ، یعنی باید کلیه رفتارهای سیستم به وضوح روشن و قابل درک باشد . به عنوان مثال فرض کنید برای اتوماسیون یک شرکت فرضی تهیه کرده اید و قرار است حالا آن را به یک شرکت مشخص بفروشید و باید در جلسه اول به مدیران اون شرکت شرح مختصر و قابل درکی از تمام سیستم ارائه کنید . یقینا اینجا نمودار Use Case بهترین گزینه است ، ضمن اینکه اگر قرار شد شرکت دیگری نیز همین کار را برای مشتری خود انجام دهد اما با روند اتوماسیون آشنائی نداشت ( مثلا" اتوماسیون خاصی که در شرکت نفت انجام میشود ) میتوانید Use Case طراحی شده را در اختیار آنها قرار دهید . یقینا متخصصین نرم افزار اون شرکت با داشتن دانش UML میتونن بخوبی سیستم طراحی شده توسط شما رو درک کنند و یک دید جامع و کاملی نسبت به " انچه نرم افزار شما انجام میدهد" داشته باشند . ( اینکه یک نرم افزار چه میکند محتوی آن کار را "چگونه" میکند نیست ! یعنی در یک جمله ، Use Case ها فقط نشان میدهند که این برنامه چه کار میکند )

یکی از جدی ترین کاربردهای Use Case برای شرکتهای تولید نرم افزار ، تولید محتوی و مستندات لازم برای مدارک فنی HLR است ( High Level Requirments ) . مدارک فنی HLR بین طراح نرم افزار و سفارش دهندهء نرم افزار ، در فاز بحث و بررسی ویژگی های نرم افزار تولید میشود و طرفین بعد از تولید این سند فنی ، میدانند دقیقا چه باید بکنند .

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

خوش باشید

با عرض معذرت از اینپرایز
یک مشکلی که هست ما خیلی کم از بحث انالیز استفاده میکنیم . شما همینجا رای گیری کنین ببینید چند نفر از دوستانی که برنامه نویسی کار میکنن از این ابزار استفاده کردند . آقا میشه یه کاری کرد که ما برنامه نویس ها هم مثل مهندسین ساختمان به جای اینکه اول ساختمان را بسازیم بعد نقشه اش را بکشیم :shock: درست و حسابی کار کنیم ؟؟؟
اصلا برای اینکه استفاده از انالیز و تجزیه و تحلیل به صورت یه فرهنگ در بیاد چکار باید کرد ؟ چرا مهندسی به نرم افزار توی ایران اهمیت داده نمیشه :(

Class Diagram

نمودار "کلاس" یکی از مهمترین نمودارهای UML است . برای توسعه دهندگان نرم افزار ( Software Developers ) نمودار کلاس پرکاربردترین و مفیدترین نمودار است . نمودار کلاس ، سیستم نرم افزاری را با توجه به "کلاس" های طراحی شده برای انجام هر وظیفه و ارتباط بین آنها ، نمایش میدهد . ( دقت کنید که اینجا هم کلاس و ماهیت آن و ارتباط بین آنها مطرح است و هنوز هیچ اثری از "چگونگی" انجام وظایف مشاهده نمیشود )

جزئیات موجود در نمودار کلاس بسیار زیاد است و یکی از اصلی ترین بخشهائی که در یادگیری UML حائز اهمیت است درک نحوه طراحی نمودارهای کلاس یا فهم یک نمودار کلاس و درک روابط بین کلاسهاست . هر کلاس با یک مستطیل نمایش داده میشود که به سه قسمت تقسیم شده است : نام کلاس - مشخصه های کلاس - توانائی های کلاس . نام کلاسهای مجرد ( abstract ) باید بصورت ایتالیک نوشته شود . ارتباط بین کلاسها به سه دسته تقسیم میشوند :

1. Association

هر وقت لازم باشه اشیاء ساخته شده از یک کلاس با اشیاء ساخته شده از کلاس دیگه ای ( یا کلاسهای دیگه ای ) ارتباط داشته باشند تا سیستم درست و صحیح کار کنه ( به عنوان مثال برای اینکه کنار هر آیتم منوی اصلی شما یک شکل کوچک نمایش داده بشه باید یک شی نگهدارنده لیست عکس به منو مرتبط بشه ) بین آن دو کلاس یک رابطهء Association وجود خواهد داشت . در نمودار این نوع رابطه ها با یک خط ساده نمایش داده میشوند ( خط ساده یعنی یک خط بدون هیچ ضمیمه یا اشاره گری )

2. Generalization

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

3. Aggregation

هر وقت نسخه ساخته شده از یک کلاس با مجموعه ای از نسخه های ساخته شده از کلاس دیگر در ارتباط باشد این نوع رابطه بین دو کلاس برقرار است . ( به عنوان مثال یک فرم ، نگه دارندهء تعداد زیادی کلید است . نتیجتا بین CDHtmlDialog و CButton ( ام اف سی ) یا مثلا TForm و TButton ( وی سی ال ) در نمودار فرضی و مثالی رابطهء نوع سوم برقرار است ) . در نمودار این نوع رابطه با یک خط ساده ( که متضمن رابطه نوع اول هم هست ) به همراه یک لوزی در طرف اصلی ( طرفی که یک نسخه از آن با نسخ متعدد دیگری ارتباط دارد ) نمایش داده میشود .


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

توضیح الف. وقتی بین دو کلاس رابطه نوع اول برقرار باشد ( که اگر بین دو کلاس رابطه ای وجود داشته باشد آن رابه الزاما رابطه نوع اول "هم" هست ) میتوان برای ارجاعات آینده یا بخاطر سپارسی رابطه یا اهمیت خاصی که آن رابطه دارد ( یا برای خوانائی بیشتر ) نامی برای آن تعیین نمائیم که در یکی از دو انتهای خط رابطه نوشته میشود و اصطلاحا" به آن Role Name میگویند .

توضیح ب. در یک رابطه بین کلاسی میتوان جهت برقراری ارتباط را نیز با یک فلش ساده ( که با فلش مذکور در رابطه نوع 2 فرق میکنه ) مشخص کرد ، منظور از جهت برقراری ارتباط است که نمودار حاوی منطق طراح نرم افزار در رابطه با ارتباط بین دو کلاس و مفهوم آن باشد . به عنوان مثال ممکن است کلاس فرضی TAdam با کلاس فرضی TShenas-nameh ارتباط داشته باشه و طراح بخواهد نشان دهد که جهت خواندن و درک این ارتباط از طرف آدم است به طرف شناسنامه ، یک خط صاف بین آنها میکشد و فلش را به سمت شناسنامه میگذارد . در واقع اینجا وجود هر شناسنامه با وجود یک آدم معنا پیدا میکند ( ساختار کلاس شناسنامه منطقا ارتباطی با ساختار کلاس آدم ندارد لذا نمیتوان تصور کرد کلاس شناسنامه فرزند کلاس ادم باشد . این رو توضیحا عرض کردم برای درک بهتر مفهوم رابطه ) .

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

1..0 | یعنی یک یا صفر نمونه - اصولا اگر قرار باشد از ساختن نمونه از کلاس از یک تعداد تا تعداد دیگری محدود باشد ، اعداد مربوطه را اینچنین مینویسند .

*..0 | هیچ محدودیتی وجود ندارد

1 | دقیقا" یکی !

*..1 | حداقل یکی


نمودار ضمیمه یک نمونه Class Diagram است . کسی که بتواند به خوبی و با جزئیات کامل این نمودار را شرح و توضیح دهد ده ساعت اینترنت جایزه خواهد گرفت ( فقط برای تهران ) :wink:

با تشکر از دوستانی که حقیر رو مورد لطف قرار دادن . :roll:

نقل قول:

---

نوشته شده توسط M@hdi

با عرض معذرت از اینپرایز
یک مشکلی که هست ما خیلی کم از بحث انالیز استفاده میکنیم . شما همینجا رای گیری کنین ببینید چند نفر از دوستانی که برنامه نویسی کار میکنن از این ابزار استفاده کردند . آقا میشه یه کاری کرد که ما برنامه نویس ها هم مثل مهندسین ساختمان به جای اینکه اول ساختمان را بسازیم بعد نقشه اش را بکشیم :shock: درست و حسابی کار کنیم ؟؟؟
اصلا برای اینکه استفاده از انالیز و تجزیه و تحلیل به صورت یه فرهنگ در بیاد چکار باید کرد ؟ چرا مهندسی به نرم افزار توی ایران اهمیت داده نمیشه :(

---

الف. خوب ، داریم در موردش بحث میکنیم تا دوستانی که آشنا نیستند علاقه مند و آشنا بشن . سابقهء علم مهندسی نرم افزار هر چند کمتر از سابقه خود نرم افزار نیست اما برخورد جدی و سیستماتیک فعلی که مشاهده میکنید عمر طولانی ای نداره لذا ما خیلی خیلی عقب نیستیم .

ب. آزمایشات قبل از ازدواج برای جلوگیری از بیماری های ژنی چطور به فرهنگ تبدیل شد ؟ تبلیغات و معرفی فوائد و اشاره به خطرات عدم توجه که بهش میگن فرهنگ سازی به همراه برخی الزامات . اینجا هم به نظرم باید همینطور باشه

ج. در ایران به خیلی چیزها اصولا" اهمیت داده نمیشه ! زیاد غصه نخور :mrgreen:

اینپرایز غربزده :evil2:

Object Diagram

به این نوع از نمودارهای UML اغلب Package Diagram هم گفته میشه . نمانطور که در نمودار کلاس دیدید ، یکی از قرائتهای تحلیل یک سیستم نرم افزاری ، رهیافت نرم افزار محور به سیستم است . یعنی بدون توجه به مفاهیم کاربردها و نحوه انجام وظایف ، به نرم افزار مانند یک مجموعه از اجزاء نرم افزاری ( Component ) نگاه کنیم . نمودار اشیاء هم به همین ترتیب به سیستم نگاه میکنه اما اینبار قدری کلی تر . یعنی کلاسهای مربوط به هم یا کلاسهای مربوط و نامربوط به شرطی که به انجام وظیفه خاص و مستقلی مربوط باشند با هم در یک Package قرار میگیرن و نمودار اشیاء نحوه برقراری این اجزاء و برهم کنش بین آنها را مورد بررسی قرار میدهد .

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

موفق باشید

Sequence Diagram

نمودار توالی وقایع سیستم نرم افزاری یکی از مهمترین نمودارهای UML است . این نمودار ترتیب اتفاق افتادن وظایف مختلف سیستم نرم افزاری با نگرش شیء گرا را نمایش میدهد ، یعنی با مشاهده نمودار توالی وقایع یک ماژول یا کل یک نرم افزار میتوانید درک کنید اتفاقات مورد نظر "قرار" است با چه ترتیبی بیفتند ، این نمودار برای بهینه سازی تبادل اطلاعات بین اجزاء خصوصا در معماری های توزیع شده کاربرد گسترده ای دارد .

عکس ضمیمه یک نمودار توالی وقایع را نمایش میدهد که مربوط به قسمت رزرو اتقاق در سیستم پذیرش یک هتل است ، با کمی دقت جزئیات را متوجه خواهید شد

Collaboration diagram

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

شکل ضمیمه یک نمودار همکاری اشیاء را نمایش میدهد . حالا با توضیحاتی که دادم میتونید بین این نمودار و نمودار توالی وقایع مطلب قبلی ارتباطی برقرار کنید ؟ :roll:

StateChart Diagram

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

عکس ضمیمه یک نمودار وضعیت را نمایش میدهد .

Activity diagram

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

به عنوان مثالی دیگر شیء الف ورودی های کاربر را میگیرد . صلاحیت آنها را بررسی میکند ، آنها را به شیء ب ارسال میکند که با بانک اطلاعاتی مرتبط است . شیء ب بانک اطلاعاتی را جستجو میکند در صورتیکه کاربر معتبر بود : گواهی الکترونیکی عبور به شیء اول بازگردانده میشود اگر معتبر نبود 0 بازگردانده میشود . شیء الف اگر گواهی را دریافت کرد به شیء ج که مسئول ترسیم بر صفحه نمایش است ارتباط برقرار میکند و از او میخواهد صفحه دسترسی به اطلاعات را برای کاربر نمایش دهد و الا یک پیام خطا به وی نشان دهد و ... این شرح کوچکی از یک نمودار فعالیت بود .

نمودار فعالیت یکی از مهمترین نمودارهای UML است :!:

عکس ضمیمه یک نمودار فعالیت است .

Component Diagram

نمودار بستهء نرم افزاری شباهت بسیاری با نمودار کلاس ( Class Diagram ) دارد . اما از اونجائیکه کامپوننتها اغلب شامل تعداد زیادی کلاس هستند که عموما لزومی ندارد کاربر با جزئیات آنها درگیر یا حتی آشنا باشد و با هدفی خاص کنار هم جمع شده اند ، نمودار بسته نرم افزاری یا کامپوننت اغلب طرح جمع و جور تری از کلیت سیستم نرم افزاری ارائه میکند ( نه به آن جزئیتی که نمودار کلاس بر عهده دارد ) و در واقع شمای کلی نرم افزار در نمودار بسته نرم افزاری ارائه میشود . نمودار بسته نرم افزاری متضمن وابستگی بسته های نرم افزاری کل سیستم به همدیگه هم هست . به عنوان مثال نرم افزار شما یک فایل DLL است که توسعه دهندگان نهائی باید بتوانند توسط کلاسهای موجود در آن به مسنجر یاهو متصل شوند و پیام ارسال کنند یا پیامهای آفلاینشان را دریافت کنند . حالا این جزء نرم افزاری خود از چند کامپوننت تشکیل شده ، یکی برای ایجاد سوکت ( که خودش احتمالا" از چند کلاس تشکیل شده ) یکی برای حمایت از پروتکل ymsg ، یکی برای درک رشته های یونیکد و ... نهایتا" کل نرم افزار شما ( یعنی همون DLL کذائی ) شامل 10 کامپوننت اصلی است . عموما "توسعه دهندگان" نرم افزار وقتی میخواهند درک اولیه ای راجع به ساختار و بدنه نرم افزار پیدا کنند "اول" از همه نمودار بستهء نرم افزاری را "میخوانند" .

شکل زیر یک نمودار بستهء نرم افزاری ساده است . یک DLL اسمبلی دات نت شامل دو کلاس مختلف سی شارپ .

Deployment Diagram

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

به عنوان مثال اگر یک نرم افزار گستردهء COM-Based دریافت کرده اید میتوانید مطمئن باشید که در نمودار توزیع آن ، Interface هائی که استفاده شده اند ، نوع پروتکل برقراری ارتباط بین شبکه ای برنامه ، اشیائی که باید با هم ارتباط داشته باشند و بدون این ارتباط اساسا" نرم افزار محقق نمیشود ( لذا مثلا" باید حتما" اون اشیاء یا اینترفیسهای مورد استفاده رجیستر شده باشند ) و ... همگی در نمودار توزیع قابل "خواندن" هستند .

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

شکل ضمیمه یک نمودار توزیع را نشان میدهد .

خوب ، بحمدالله ، درسهای مقدماتی آشنائی با UML تموم شد . حالا دیگه با الفبای UML آشنائید و میتونید نمودار ها رو از هم تشخیص بدید ، کاربرد هر کدوم رو میشناسید و برای کاربردهای ویژه و خاص منظور میدونید کدوم مورد مناسب تره . حرفه ای شدن به عهده خودتون ، اگر سوال خاصی بود بپرسید . امیدوارم براتون مفید بوده باشه . آدم وقتی یک کار ، هر چند خیلی کوچولو رو تموم میکنه حس خوبی بهش دست میده :roll: اما ... همه پنجره ها خاموشن ، انگار این کوچهء خلوت خوابه ، بی صدا اسمتو فریاد میزنم ، ...

خوش و موفق باشید
اینپرایز

:|

تمام مطالب رو از اینجا کپی کردم یکجا و بصورت PDF ذخیره اش کردم و میتونید براحتی ازش استفاده کنید .

http://sharemation.com/inprise/uml.pdf


موفق باشید

http://www.delphishop.com/upload/UML.pdf.gz

خواهش میکنم . مطلب بعدی نگاهی به CASE Tool ها ست و بررسی اجمالی رشنال رز و بورلند توگدر .

شرمنده ، کمی گرفتار بودم .


-----

باید ؟ منظورت رو از "باید" نمیفهمم . :roll: اما از اونجائیکه بانک اطلاعاتی هم یکی از عناصر مهم یک نرم افزار یا روند نرم افزاری است میشه برای اعمال "مهندسی" روی کل روند ، از روشهای متداول نوتیشن مثل یو ام ال هم برای مدل سازی طرح و شمای بانک اطلاعاتی استفاده کرد . مثلا" نمودار همکاری اشیاء ( Colaboration ) کاربرد زیادی در طراحی بانکهای اطلاعاتی رابطه ای داره . شاید دوست داشته باشی در این زمینه بیشتر مطالعه کنی لذا، شاید این کتاب به دردت بخوره :


http://images.amazon.com/images/P/02...1.LZZZZZZZ.jpg

دو تا از فصلهاش رو میتونی بصورت پی دی اف از اینجا بگیری : http://www-106.ibm.com/developerwork...brary/302.html

خوش باشی