آموزش تخصصی نمودارهای UML

ارسال شده توسط administrator
15. جوان 2010 14:55

در سال 1997، گروه مدیریت شی (Object Management Group) یا ((OMG، زبان مدل سازی یکپارچه (Unified Modeling Language) یا (UML) را عرضه کرد. یکی از اهداف UML، فراهم کردن یک زبان طراحی ثابت و رایج برای جامعه برنامه نویسان است که می توان برای توسعه و ساخت برنامه های کامپیوتری استفاده کرد. UML، یک روش نشانه گذازی برای مدل سازی استاندارد و یکپارچه تولید کرد که سالها بود مهندسین IT در انتظارش بودند. حالا مهندسین IT، می توانند با استفاده از UML، ساختار سیستم و طرح های طراحی را بخوانند و منتشر کنند.

الان قرن 21 است و UML جایش را در حرفه ما باز کرد ه است. در 75 درصد رزومه هایی که من می بینم، افراد ادعا می کنند با UML آشنایی دارند ولی بعد از اینکه با آنها صحبت می کنم، مشخص می شود که آنها واقعاً نمی دانند UML چیست. آنها معمولاً از اصطلاح UML، به عنوان واژه ای دهان پرکن استفاده می کنند. این فقدان دانش درباره UML، باعث شد که من این مفاله درباره را بنویسم. این مفاله روی دیاگرام های پایه ای که در مدل سازی بصری (visual) استفاده می شود، بحث می کند. بعد اتمام خواندن مقاله، شما دانش کافی نخواهید داشت که بخواهید UML را در رزومه کاری تان قرار دهید، اما این مقاله می تواند نقطه شروعی برای کسب دانش بیشتر درمورد این زبان باشد.

پیش زمینه

همانطور که ذکر کردم، هدف UML، یکپارچه کردن زبان ها است تا حرفه ای ها را قادر به مدل سازی برنامه های کامپیوتری می کند. نو یسندگان اولیه Jim Rumbaugh، Ivar Jacobson، و Grady Booch بودند که ابتداً صاحب متدهای رقابتی خودشان بودند (OMT، OOSE، و Booch). نهایتاً، با هم متحد شدند و زبانی استاندارد را پدید آوردند. دلیلی که UML، زبان مدل سازی استاندارد شده این است که زبانی مستقل است. همچنین، مجموعه نشانه های UML، یک زبان است نه یک متدولوژی. این موضوع دارای اهمیت است، زیرا، بر عکس متدلوژی، یک زبان می تواند به راحتی با روش هدایت تجارت هر شرکتی سازگار شود، بدون اینکه نیاز به تغییر داشته باشد.

از آنجاییکه UML، متدلوژی نیست، نیازی به محصولات کاری رسمی ندارد (مثلاً، مصنوعات "artifact" در زبان پردازش یکپارچه منطقی IBM، "IBM Rational Unified Process® lingo"). اما هنوز چندین نوع دیاگرام را که، هنگام استفاده شدن در یک متدلوژی مشخص، باعث افزایش راحتی درک برنامه ای تحت توسعه می شود، فراهم نمی کند. UML، چیزی فراتر از این دیاگرامها هستند، اما در اینجا، دیاگرام ها مقدمه خوبی برای این زبان و اصولی هستند که فراتر از استفاده از آن هستند. با قراردادن دیاگرام های UML در محصولات کار متدلوژی تان، پیوستن افراد متبحر در UML را به پروژه تان آسانتر می کنید وپروژه تان سریعاً ثمربخش می شود. مفیدترین و استانداردترین دیاگرام های UML عبارتند از: use case diagram، class diagram، sequence diagram، statechart diagram، activity diagram، omponent diagram، و deployment diagram.

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


Use-case diagram

use case، واحد عملکردی را که سیستم فراهم می کند، نشان می دهد. هدف اصلی دیاگرام use-case، کمک کردن به تیم های development برای به تصویر کشیدن نیازهای کاربردی یک سیستم است، مثلاً، رابطه actorها (افرادی که با سیستم در تعامل هستند) با فرایندهای ضروری، و همچنین روابط میان use caseهای مختلف. دیاگرام های use case، معمولاً گروه های use caseها را نشان می دهند — یا همه use caseهای سیستم، یا قسمتی از گروهی خاص از use caseهایی که عملکرد مرتبطی دارند. برای نشان دادن یک use case روی یک دیاگرام use case، باید یک بیضی در وسط دیاگرام رسم کنید اسم use case را در مرکز یا زیر بیضی قرار دهید. برای رسم کردن یک actor (که نشان دهنده کاربر سیستم است)، روی دیاگرام use case، باید یک آدمک در سمت چپ یا راست دیاگرام تان رسم کنید. برای نشان دادن روابط بین actorها و use caseها، از خطوط ساده استفاده کنید؛ همان گونه که در شکل یک نشان دا ده شده.

شکل 1: use-case diagram نمونه

clip_image001

معمولاً از use caseها برای رابطه با تابع های سطح بالای سیستم و گستره سیستم استفاده می شود. با نگاه به دیاگرام ها در شکل 1، به راحتی می توان تابع هایی را این مثال در اختیار می گذارد، تشخیص داد. این سیستم به مدیر گروه اجازه می دهد گزارش آمار فروش و گزارش Billboard 200 برای CDهای گروه را مشاهده کند. همچنین به مدیر ضبط اجازه مشاهده گزارش آمار فروش و گزارش Billboard 200 برای یکCD خاص را می دهد. همچنین این دیاگرام به ما می گوید که سیستم ما، گزارش های Billboard را از یک سیستم خارجی به نام سرویس گزارش گیری Billboard (Billboard Reporting Service)، تحویل می دهد.

به علاوه، عدم حضور use caseها در این دیاگرام نشان می دهد سیستم چه کاری را انجام نمی دهد. مثلاً، راهی را برای گوش دادن به آهنگهای آلبوم های مختلف در Billboard 200، پیش روی مدیر گروه نمی گذارد. این عدم حضور، موضوع کم اهمیتی نیست. با توصیفاتی واضح و ساده از use case که روی چنین دیاگرامی مهیا شده، اسپانسر پروژه می تواند به راحتی بفمهد آیا کارکرد مورد نیاز، در سیستم حاضر است یا خیر.


Class diagram

این دیاگرام نشان می دهد ماهیت های مختلف (افراد، اشیاء، و داد ه ها) چگونه بهم مربوط هستند؛ به عبارت دیگر، ساختار static سیستم را نشان می دهد. یک class diagram را می توان برای نشان دادن کلاسهای logical استفاده کرد که معمولاً موضوعاتی هستند که افراد دارای business در یک سازمان درباره آنها صحبت می کنند — گروه های موسیقی راک (rock)، CDها، برنامه های رادیو، یا وامها، رهن خانه، وام ماشین، و موضوعات جالب دیگر. همچنین می توان از Class diagramها، برای نشانه دادن پیاده سازی های کلاس ها استفاده کرد؛ کلاسها، چیزهایی هستند معمولاً برنامه نویسان با آنها سرو کار دارند. یک implementation class diagram، احتمالاً تعدادی از کلاسهای شبیه به logical classes diagramها را نشان خواهد داد. اما implementation class diagram ، با همان صفات ترسیم نمی شود، زیرا یه احتمال زیاد، به چیزهایی مانند Vectorها و HashMapها گرایش خواهد داشت.

یک کلاس، به صورت یم مستطیل با سه بخش افقی نشان داده می شود، مانند شکل 2. بخش بالایی، نام کلاس را نشان می دهد؛ بخش میانی حاوی صفات کلاس است؛ و بخش پایینی، حاوی عملیات ها (یا متدهای) کلاس خواهد بود.

شکل 2: class object ساده در یک class diagram

clip_image003

تجربه من نشان می دهد که تقریباً هد برنامه نویسی می داند این دیاگرام چیست، اما متوجه شدم که اکثر برنامه نویسان خطوط ارتباطی را صحیح رسم نمی کنند. برای یک class diagram، مانند شکل 3، رابطه وراثت را باید با استفاده از یک خط و فلش در بالا که به سمت superclass اشاره دارد، رسم کنید؛ و فلش باید یک مثلث کامل باشد. اگر هر در class، از وجود هم آگاه باشند، یک رابطه association، باید یک خط مستقیم نشان داده شود، و اگر فقط یکی از classها از وجود association آگاه باشد، باید با یک فلش باز نشان داده شود.

شکل 3: یک class diagram کامل، شامل class object که در شکل 2 نشان داده شده.

2772_fig3

در شکل 3، ما هم رابطه وراثت و هم دو رابطه association می بینیم. کلاس CDSalesReport، از کلاس Report ارث می برد. CDSalesReport، با یک CD در ارتباط است ، اما کلاس CD، چیزی در مورد کلاس CDSalesReport نمی داند، کلاس های CD و Band، هر دو از وجود هم اطلاع دارند، و هر دو کلاس می توانند با یک چند کلاس از خودشان مرتبط شوند.

یک class diagram می تواند چندین مفهوم را ترکیب کند که بعداً مورد بحث قرار خواهد گرفت.


Sequence diagram

Sequence diagramها، جریانی مفصل از یک use case معین یا حتی بخشی از use case معین را نشان می دهد. آنها تقریباً خود تشریح هستند؛ آنها فراخوانی های بین اشیاء را در sequenceشان نشان می دهند و می تواند فراخوانی های اشیاء مختلف را نشان دهند.

sequence diagram دارای دو بعد است: بعد عمودی که ترتیب پیام ها/فراخوانی ها را به ترتیبی که اتفاق می افتند، نشان می دهد؛ بعد افقی که نمونه اشیاء را که پیام ها به آنها ارسال می شوند را نشان می دهد.

رسم کردن sequence diagram بسیار ساده است. در بالای دیاگرامتان، کلاس نمونه ها (اشیاء) را با قرار دادن هر class instance در یک جعبه، شناسایی کنید (شکل4). در این جعبه، نام class instance را که با space/colon /space " : " جدا شده است، قرار دهید (مثلاً: myReportGenerator : ReportGenerator). اگر یک class instance، پیامی را به class instance دیگر ارسال کند، خطی را با یک فلش باز که به class instance دریافت کننده اشاره می کند، رسم کنید؛ نام پیام یا متد را در بالای خط قرار دهید. برای پیام های مهم، می توانید یک خط نقطه چین با فلشی که به class instance اشاره می کند، رسم کنید؛ مقدار برگشتی را بالای خط قرار دهید. من همیشه شخصاً دوست دارم مقدلر بازگشتی را با خط مشخص کنم زیرا جزییات اضافی، خواندن آن را آسانتر می کند.

خواندن sequence diagram خیلی ساده است. با کلاس class instance "driver" در بالای گوشه چپ شروع کنید که sequence را آغاز می کند. سپس هر پیام را در پایین دیاگرام دنبال کنید. به یاد داشته باشید: گرچه مثال sequence diagram در شکل 4، یک پیام بازگشتی را برای هر پیام ارسالی نشان می دهد، اما این موضوع اختیاری است.

شکل 4: نمونه ای از یک sequence diagram

2772_fig4

با خواندن این sequence diagram، می توان متوجه شد چگونه می توان یک گزارش CD Sales ایجاد کرد. شی aServlet، driver مثال ماست. aServlet پیامی را به ReportGenerator class instance بنام gen ارسال می کند. پیام دارای لیبل generateCDSalesReport است که به معنای این است که شی generateCDSalesReport این پیام را پیاده سازی میکند. در نگاهی دقیق تر می بینیم که در لیبل پیام generateCDSalesReport، cdId در پرانتز است، که بدین معنی است که aServlet در حال ارسال متغیری به نام cdId همراه با پیام است. وقتی gen instance، یک پیام generateCDSalesReport دریافت می کند، کلاس های CDSalesReport را فرا می خواند، و نمونه ای واقعی از یک CDSalesReport بنام aCDReport بازگردانده می شود. سپس نمونه gen، نمونه بازگردانده شده aCDReport را فرا می خواند. در پایان sequence، نمونه gen، aCDReport را به aServlet فراخوانش باز می گرداند.

لطفاً به خاطر داشته باشید: sequence diagram در شکل 4، برای یک sequence diagram معمولی بیش از حد پرجزییات است. اما، من معتقدم که فهمیدنش به اندازه کافی ساده است، و نشان می دهد nested calls چگونه رسم می شوند.


Statechart diagram

این دیاگرام، حالتهای مختلفی را که یک کلاس ممکن در آنها باشد، و چگونگی انتفال آن کلاس از حالتی به حالت دیگر را نشان می دهد. می توان گفت که هر کلاس دارای یک حالت است، اما هر کلاسی نباید دارای یک statechart diagram باشد. فقط کلاس هایی با حالتهای "جالب" — یعنی کلاسهایی با سه یا چند حالت بالقوه درطول فعالیت سیستم — باید مدل سازی شوند.

همانگونه که در شکل 5 نشان داده شده، مجموعه علامت گذاری های statechart diagram، دارای 5 عنصر اصلی است: نقطه شروع ابتدایی، که با استفاده از یک دایره توپر رسم می شود؛ انتقال بین حالتها، که با استفاده از یک خط با فلشی باز رسم می شود؛ یک حالت، که با استفاده از مستطیل با زاویه های گرد رسم می شود؛ یک نقطه تصمیم، که با یک دایره باز رسم می شود؛ و یک یا چند نقطه اتمام، که با استفاده از یک دایره و یک دایره توپر درون آن رسم می شود. جهت رسم یک statechart diagram، با یک نقطه آغازین و یک خط انتقال به حالت اولیه کلاس شروع کنید. خود حالتها را می توانید هرجای دیاگرام رسم کنید، و سپس می توانید با استفاده از خطوط حالت انتقال، آهنا را بهم وصل کنید.

شکل 5: دیاگرام Statechart که حالتهای مختلفی را که یک کلاس در یک سیستم عمل کننده سپری می کند

2772_fig5

statechart diagram نمونه ای که در شک 5 نشان داده شده، قسمتی از اطلاعات بالقوه ای را که می توانند فراهم کنند را نشان می دهد. مثلاً، می توانید بگویید فرایند وام در حالت "تقاضا برای وام" شروع می شود. وقتی فرآیند قبل از تایید تمام می شود، بسته به نتیجه، شما یا به حالت قبل از تایید یا به حالت رد وام، منتقل می شوید. این بخش، که در طول فرآیند انتقال انجام می شود، با یک نقطه تصمیم نشان داده می شود — دایره خالی در خط انتقال. با نگاه به مثال، می توان گفت که یک وام نمی تواند از حالت "قبل از تایید" به حالت "نگهداری وام" بدون گذر از حالت "بستن وام" برود. همچنین، با نگاه به این مثال، می توان گفت همه وامها یا در حالت "رد وام" یا حالت "نگهداری وام" به پایان می رسند.


Activity diagram

این دیاگرام، جریان رویه ای کنترل بین دو یا چند شی کلاس را هنگام پردازش یک فعالیت نشان می دهد. ازActivity diagramها می توان برای مدل سازی فرآیند یک تجارت سطح بالا در سطح واحد تجارت، یا مدل سازی actionهای درون کلاسی سطح پایین استفاده کرد. به نظر من، activity diagramها، برای مدل سازی فرآیند های سطح بالا استفاده می شوند. تجربه من نشان می دهد که از activity diagramها می توان برای مدل سازی فرایند های سطح بالا بهتر استفاده کرد، فرآیندهایی مانند اینکه یک کمپانی در حال حاضر چگونه تجارت خود را انجام می دهد، یا چگونه دوست دارد تجارتش را انجام دهد. دلیلش این است که activity diagramها در مقایسه با sequence diagramها، در ظاهر کمتر تکنیکی هستند، و کسانی که ذهن اقتصادی دارند، تمایل دارند آنها را زودتر درک کنند.

مجموعه علایم نشانه گذاری های activity diagram شبیه علایم statechart diagram است. این دیاگرام نیزمانند statechart diagram، با یک دایره توپر شروع می شود که به فعالیت ابتدایی وصل است. این فعالیت با رسم یک مستطیل با زاویه های گرد که نام فعالیت را در برمی گیرد، مدل سازی می شود. از طریق خطوط ارتباطی، می توان فعالیتها را به فعالیتهای دیگر یا به نقاط تصمیم گیری ای که به فعالیتهای مختلفی که توسط شرایط نقطه تصمیم گیری متصل می شوند، متصل کرد. فعالیتهایی که فرایند های مدل سازی شده را تمام می کنند، به نقطه اتمام وصل می شوند. می توان فعالیتها را به swimlaneها گروه بندی کرد، که برای نشان دادن شی ای که واقعاً فعالیت را اجرا می کند بکار می رود، همانگونه که در شکل 6 نشان داده است.

شکل 6: یک Activity diagram ، با دو swimlane جهت نشان دادن کنترل فعالیت با دو object: مدیر گروه و ابزار گزارس دهی

clip_image007

در این activity diagram نمونه، دو swimlane وجود دارد زیرا دو شی وجود دارند که فعالیتهای مجزا را کنترل می کنند: مدیر گروه و ابزار گزارش گیری. این فرآیند با مدیر گروه شروع می شود که گزارش های فروش یکی از گروه هایش را مشاهده می کند. سپس ابزار گزار ش گیری، همه گروه هایی را که آن شخص مدیریت می کند بازیابی و نمایش می دهد و از او می خواهد یکی را انتخاب کند. بعد از اینکه مدیر گروه یکی را انتخاب کرد، ابزار گزارش گیری اطلاعات فروش را بازیابی می کند و گزارش فروش را نمایش می دهد. activity diagram نشان می دهد که نمایش دادن گزارش، آخرین مرحله این فرآیند است.

Component diagram

این دیاگرام، نمایی فیزیکی از سیستم را در اختیار می گذارد. هدف این دیاگرام نشان دادن dependencyهایی است که یک نرم افزار روی componentهای نرم افزار دیگر در سیستم دارد. می توان این دیاگرام را در سطحی بسیار بالا با componentهای دانه درشت نشان داد؛ یا می توان در سطح بسته component (component package level) نشان داد. [نکته: اصطلاح component package level، یک روش زبان برنامه نویس خنثی برای ارجاع به سطوح حاوی کلاس از قبیل فضاهای اسمی .NET (مثلاً، System.Web.UI) یا بسته های Java (مثل java.util) است.

مدل سازی component diagram را می توان با یک مثال بهتر توضیح داد. شکل 7، چهار component را نشان می دهد: ابزار گزارش گیری، سرویس Billboard، Servlet 2.2 API، و JDBC API. فلشهای از طرف component ابزار گزارش گیری به طرف Service Billboard، Servlet 2.2 API، و componentهای JDBC API، بدین معنی است که ابزار گزارش گیری وابسته به این سه جزء دارد.

شکل 7: component diagram، interdependencyهای componentهای نرم افزارهای مختلفی را نشان می دهد که سیستم در بر گرفته است.

clip_image008


Deployment diagram

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

علامت گذاری در deployment diagram، شامل همان عناصر نشانه گذاری های component diagram، به علاوه چند علامت دیگر مثل مفهوم یک node است. Node، یا یک ماشین فیزیکی یا یک ماشین مجازی را نشان می د هد. برای مدل سازی یک node، کافیست یک مکعب سه بعدی با نام node در بالای مکعب، رسم کنید. از قواعد نام گذاری که در sequence diagramها استفاده می شوند، استفاده کنید؛ [instance name] : [instance type]، (مثلاً "w3reporting.myco.com : Application Server")

شکل 7: Deployment diagram

2772_fig8

deployment diagram در شکل 8 نشان می دهد که کاربران، با استفاده از یک مرورگر که روی کامپوتر داخلی شان اجرا می شود و از طریق HTTP اینترانت شرکتشان به Reporting Tool متصل می شوند، به Reporting Tool دسترس ییدا می کنند. این ابزار به طور فیزیکی روی Application Server به نام w3reporting.myco.com اجرا می شود. این دیاگرام، component ابزار گزارش گیری را که درون IBM WebSphere رسم شده است نشان می دهد، که به نوبت درون node w3.reporting.myco.com رسم می شوند.

Reporting Tool با استفاده از Java language to IBM DB2's JDBC interface به بانک اطلاعاتی گزارش وصل می شود، که بعداً با بانک اطلاعاتی واقعی DB2 که با استفاده از native DB2 communication روی سروری به نام db1.myco.com اجرا می شود، ارتباط برقرار می کند. علاوه بر این، component ابزار گزارش گیری از طریق SOAP روی HTTPS با Billboard Service ارتباط برقرار می کند.


نتیجه گیری

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