دیاگرام های collaboration/communication در UML، ماتند دیاگرامهای sequence، برای مرور طبیعت دینامیک نرم افزار شما بکار می رود. Collaboration diagramها، تبادل پیامها (message flow) بین اشیا را در یک برنامه OO نشان می دهند. از Collaboration diagramها معمولاً برای موارد زیر استفاده می شود:

· جهت فراهم کردن نمایی نزدیک از مجموعه ای از اشیاء همکار، مخصوصاً در یک محیط واقعی (real-time environment).

· جهت احتصاص دادن عملکردهایی به کلاسها با مرور جنبه های رفتاری یک سیستم.

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

· جهت مرور نقش هایی اشیایی که درون یک سیستم می گیرند، و همچنین روابط مختلفی که، هنگامی که در این نقش ها هستند، با آنها درگیر هستند.

در زیر راهنمایی هایی برای موارد زیر آورده شده:

1. مسایل عمومی

2. پیام ها

3. لینکها

1. مسایل عمومی

شکل 1: نمونه ای از دیاگرام Collaboration

1. Instance-Level Diagrams To Explore Object Design Issues. دیاگرام های Collaboration در سطح نمونه (Instance-level)، مانند مثال شکل 1، روابط بین اشیا را نشان می دهند. معولاً از این دیاگرام ها جهت مرور طراحی داخلی نرم افزار شی گرا، ایجاد می شوند.

2. Use Specification-Level Diagrams to Explore Roles. دیاگرام های Collaboration در سطح ویژه (Specification-level)، مانند مثال شکل 6، جهت تحلیل و مرور نقش هایی بکار میز رود که کلاس domain در سیستم می گیرد.

3. Collaboration Diagrams Do Not Model Process Flow.

4. When Sequence Is Important Use a Sequence Diagram.

5. Apply Sequence Diagram Guidelines To Instance-Level Collaboration Diagrams. از آنجاییکه دیاگرام های collaboration، نمایی جایگزین از همان اطلاعات دیاگرام sequence را نمایش می دهند، اکثر همان سبک ها در اینجا نیز قابل اعمال است. لیست زیر راهنمایی ها، که ابتداً برای دیاگرام های sequence ارایه شدند، برای دیاگرام های collaboration نیز قابل اعمال هستند:

· Name Objects When Your Reference Them In Messages

· Name Objects When Several of the Same Type Exist

· Apply Textual Stereotypes Consistently

· Apply Visual Stereotypes Sparingly

· Focus on Critical Interactions

· Prefer Names Over Types for Parameters

· Indicate Types as Parameter Placeholders

· Do Not Model a Return Value When it is Obvious What is Being Returned

· Model a Return Value Only When You Need to Refer to it Elsewhere

· Model Return Values as Part of a Method Invocation

· Indicate Types as Return Value Placeholders

2. پیام ها

شکل 2، علامت گذاری برای فراخوانی پیام ها در دیاگرام collaboration را نشان می دهد. مثلاً در شکل 1، پیام 1.2: orderTotal := calculateTotal() ، ترتیب اعداد 1. 2، را نشان می دهد، هیچ تکراری اتفاق نمی افتد، مقدار برگشتی orderTotal و متد فراخوانده شده ای بنام calculateTotal().

شکل 3: یک Collaboration diagram که فراخوانی های پیام همزمان را نشان می دهد.

1. Indicate a Return Value Only When It Isn’t Clear.

2. Indicate Parameters Only When They Aren’t Clear.

3. Depict an Arrow For Each Message.

4. Consolidate Getter Invocations. وقتی چندین getter در یک ردیف فراخوانده می شود، بهترین میانبر، مدل سازی یک پیام مستقل از قبیل getInfo() در شکل 1 است.

5. Indicate Concurrent Threads With Letters. در شکل 3 می بینید که قبل از بعضی از پیام ها حروف A، B، و C وجود دارد که نشان می دهد آن پیام ها به طور همزمان پردازش می شوند.

لینک ها

خطوط بین classifierهایی که در یک دیاگرام collaboration در UML، نشان دهنده نمونه ایی از روابط بین classifierها –شامل associationها، aggregationها، compositionها، و dependencyها– است.

شکل 4: یک دیاگرام Collaboration در سطح ویژه.

Model “Bare” Links On Instance-Level Collaboration Diagrams.

Show Role-Pertinent Information on Specification-Level Diagrams. در شکل 4 می بینید که نقش هایی که کلاس ها می گیرند، و کثرت های سطح بالا، نشان داده شده اند.

Prefer Roles on Links Instead of Within Classes.

Links Should Be Consistent Static Relationships.

مقدمه

مدل سازی فعالیتی است که سالهاست در توسعه نرم افزار انجام می شود. هنگام نوشتن برنامه ها با استفاده از ساده ترین تا پیچیده ترین زبانها، به مدل سازی نیاز دارید. مدل سازی می تواند به سادگی ترسیم یک flowchart باشد که مراحلی را که یک برنامه انجام می دهد لیست می کند. چرا ما از مدل سازی استفاده می کنیم؟ تعریف یک مدل، تقسیم یک برنامه پیچیده یا یک سیستم عظیم را به اجزای ساده، راحت می کند؛ اجزای مجزایی که می توان به صورت منفرد مطالعه کرد. می توان راحت تر روی قسمت های کوچکتر یک سیستم تمرکز کرد و سپس مفهوم "عکس بزرگ" را درک کرد. از این رو، می توان دلایل مدل سازی را در دو کلمه خلاصه کرد:

• قابل خواندن بودن
• قابل استفاده مجدد بودن

قابل خواندن بودن

باعث وضوح و سادگی در فهمیدن می شود. فهمیدن یک سیستم، قدم اول در ساختن یا بهبود یک سیستم است. این موضوع مستلزم این است که بدانیم یک سیستم از چه چیزی درست شده، چگونه رفتار می کند، و غیره. مدل سازی یک سیستم تضمین می کند که آن سیستم قابل خواندن شود، و مهمتر از همه، راحت document می شود. نشانه گذاری (depict) یک سیستم برای قابل خواندن کردن آن، مستلزم capture کردن ساختار و رفتار آن سیستم است.

قابل استفاده مجدد بودن، محصول جانبی قابل خواندن کردن یک سیستم است. بعد از اینکه یک سیستم جهت راحت فهمیده شدن مدل سازی می شود، ما به شناسایی شباهتها یا مازاد بودن (redundancy)، بر اساس عملکرد، ویژگی، یا ساختار، تمایل پیدا می کنیم.

با وجود اینکه تکنیکها و ابزارهای زیادی برای مدل سازی وجود دارد، در این مقاله ما روی سیستمها و برنامه هایی مدل سازی شی گرایی که از زبان واحد مدل سازی استفاده می کنند، تمرکز می کنیم. زبان واحد مدل سازی، یا UML، زبانی است که می توان برای مدل سازی سیستمها استفاده و آنها را قابل خواندن کرد. این لزوماً بدین معناست که UML، قابلیت capture کردن مشخصه های یک سیستم را با استفاده از نشانه گذاری ها (notation) فراهم میکند. UML، طیف وسیعی از نشانه گذاری های ساده و قابل فهم برای document کردن سیستمها بر اساس اصول طراحی شی گرا در اختیار می گذارد. این نشانه گذاری ها، نه دیاگرام UML نامیده می شوند.

حالا سوال اینجاست؟ "چرا باید از UML، به عنوان انتخابی ارجح، برای مدل سازی استفاده کرد؟" خوب، جواب یک کلمه است: "استاندارد سازی"! زبانهای مختلفی برای depict کردن سیستمهایی که از متدلوژی شی گرا استفاده می کنند، مورد استفاده قرار گرفته اند. برجسته ترین این متدولوژی ها، Rumbaugh، Booch، و Jacobson است. با وجود اینکه هر متدولوژی مزایای خود را داشت، اما مشکل این بود که آنها اساساً ناهمخوان بودند. از این رو، اگر مجبور بودید روی پروژه های زیادی که از هر یک از این متدولوژی ها استفاده می کردند، کار کنید، باید به خوبی با همه این متدولوژی ها آشنا می شدید. چه کار واقعاً مشکلی! مدل برنامه نویسی واحد دقیقاً همین کار را میکند. این زبان، اصول طراحی این متدولوژی ها را به یک زبان متحد، ساده، و استاندارد تبدیل می کند که براحتی به همه سیستمهای شی گرا اعمال می شود. اما، برخلاف متدولوژی های مختلفی که بیشتر به طراحی جزییات سیستم گرایش دارند، UML، نیازها، تحلیل، طراحی و همچنین پیاده سازی را محدود می کند. زیبایی UML این است که هر نه دیاگرام UML را می توان در صورت نیاز، در مدل افزایشی استفاده کرد. مثلاً اگر نیاز به مدل سازی کردن نیازهای یک سیستم معین دارید، می توانید فقط از دیاگرامهای use case، بدون استفاده از دیاگرامهای دیگر در UML، استفاده کنید. با در نظر گرفتن همه این دلایل، جای تعجب نیست که UML، "زبان منتخب" به حساب می آید.

UML، نسبت به هر تکنولوژی و زبان دیگری، هیچ گونه وابستگی (dependency) ندارد. این بدین معناست که می توان از UML، برای مدل سازی برنامه ها و سیستمهایی که بر پایه هر یک از تکنولوژی های روز از قبیل J2EE، و .NET هستند، استفاده کرد. تلاشهای زیادی صورت گرفته تا UML به عنوان زبانی ساده و دقیق برای مدل سازی کردن، بدون وابستگی به هیچ تکنولوژی ای، باقی بماند.

هدف این مقاله، پوشش دادن مقدمات UML، یعنی هر نه دیاگرام UML است. به علاوه، با ابزارهایی آشنا خواهید شد که UML را ساپورت می کنند. مطالعه UML، به دو بخش Rational Unified Process، و Design Patterns گسترش خواهد یافت.

دیاگرام های UML

ویژگی اساسی UML این است که هیچ دیاگرام دیگری نمی تواند عناصر مخنلف یک سیستم را با کلیاتش، capture کند. از این رو، UML متشکل از 9 دیاگرام است که می توان برای مدل سازی یک سیستم در زمانهای مختلف در چرخه حیاتی یک سیستم نرم افزاری استفاده کرد. نه دیاگرام UML عبارتند از:

Use case diagram: این دیاگرام جهت شناسایی عناصر و فرآیندهای مقدماتی که سیستم را شکل می دهند، استفاده می شود. برای عناصر مقدماتی از عبارت "actorها" استفاده می شود، و فرآیندها "use cases" نامیده می شوند. دیاگرام use case، نشان می دهد کدام actorها با هر use case در تعامل هستند.

دیاگرام کلاس (Class Diagram): این دیاگرام جهت refine کردن دیاگرام use case و تعریف جزییات طراحی یک سیستم استفاده می شود. دیاگرام کلاس، actorهایی را که در use case diagram تعریف شده است، در مجموعه ای از کلاسهای وابسته به هم طبقه بندی می کند. رابطه بین کلاسها ممکن است یک رابطه "is-a" یا یک "has-a" باشد. ممکن است هر کلاس در دیاگرام کلاس، دارای عملکردهای زیادی باشد. برای قابلیت هایی که توسط کلاسها فراهم می شوند، از عبارت "متدهای کلاس" استفاده می شود. غیر از این، هر کلاس ممکن است "صفاتی ((attribute" داشته باشد که به طور منحصر فردی آن کلاس را معرفی می کند.

Object diagram: این دیاگرام، نوع بخصوصی از کلاس دیاگرام است. یک object، نمونه ای از یک کلاس است. لزوماً، این بدین معناست که یک object، هنگامی که سیستم در حال اجرا است، نشانگر حالت یک کلاس در نقطه مشخصی از زمان است. object diagram، حالت کلاسهای مختلف در سیستم و روابطشان در نقطه مشخصی از زمان، را capture می کند.

State diagram: یک state diagram، همانگونه که از نامش مشخص است، نمایانگر حالتهای مختلفی است که objectهای درون سیستم، در طول چرخه حیاتی شان با آنها روبرو می شوند. Objectهای درون یک سیستم، در واکنش به رویدادها، تغییر می کنند. علاوه بر این، یک state diagram، تغییر حالت یک object از حالتی ابتدایی به حالتی نهایی، در واکنش به رویدادهایی که سیستم را تحت تاثیر قرار می دهند، را نیز capture می کند.

Activity diagram: در activity diagram، جریانهای فرایند درون سیستم، capture می شوند. مانند یک state diagram، یک activity diagram، از فعالیتها، اقدامات، تغییر حالتها، حالتهای ابتدایی و نهایی، و چهارچوب تصمیم گیری تشکیل شده است.

Sequence diagram: این دیاگرام، نمایانگر تعامل بین objectهای مختلف در سیستم است. جنبه مهم یک sequence diagram، این است که بر به ترتیب زمان است. این بدین معناست که ترتیب دقیق تعاملهای بین objectها، پله به پله نمایش داده می شوند. Objectهای مختلف در sequence diagram، با ارسال پیام، با یکدیگر در تعامل هستند.

Collaboration diagram: یک collaboration diagram، تعاملهای بین objectهای مختلف را با گروه بندی می کند. این تعاملها، به صورت تعاملهای شماره داری لیست می شنود که به ردیابی ترتیب تعاملها کمک می کند. collaboration diagram، به معرفی همه تعاملهای محتملی که هر object با objectهای دیگر دارد، کمک می کند.

Component diagram: این دیاگرام، نمایانگر اجزای سطح بالایی است که سیستم را درست می کنند. این دیاگرام، نشان می دهد چه اجزایی، سیستم را شکل می دهد و چگونه به هم وابسته هستند. یک component diagram، اجزای جمع آوری شده ای را که بعد از اینکه سیستم مرحله توسعه یا ساخته شدن را گذراند، نشان می دهد.

Deployment diagram: این دیاگرام، پیکربندی عناصر زمان اجرای برنامه را Capture می کند. این دیاگرام، هنگامی که یک سیستم ساخته می شود و آماده نصب شدن است، مفیدتر است.

حالا که شناختی از دیاگرام های مختلف UML پیدا کرده ایم، بیایید ببینیم آیا می توانیم تا حدی این دیاگرام ها را گروه بندی کنیم تا بتوانیم درک بیشتری از چگونگی استفاده ار آنها داشته باشیم.

طبقه بندی دیاگرام های UML — استاتیک، دینامیک، و پیاده سازی

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

• استاتیک: این مشخصه یک سیستم لزوماً جنبه ساختاری سیستم است. این مشخصه، تعریف می کند یک سیستم از چه قسمت هایی تشکیل شده است.
• دینامیک: ویژگی رفتاری یک سیستم، مثلاً، روشی که سیستم نسبت به بعضی رویداداها یا اعمال واکنش نشان می دهد، مشخصه دینامیک یک سیستم است.
• پیاده سازی: مشخصه پیاده سازی یک سیستم، یک ویژگی کاملاً جدید است که عناصر مختلفی را که برای نصب یک سیستم لازم هستند، توصیف می کند.

دیاگرام های UML زیر مشخصه های زیر قرار می گیرند:

o استاتیک

· Use case diagram

· Class diagram

o دینامیک

· Object diagram

· State diagram

· Activity diagram

· Sequence diagram

· Collaboration diagram

o پیاده سازی

· Component diagram

· Deployment diagram

مشاهده 4+1 دیاگرام های UML

با در نظر گرفتن اینکه دیاگرام های UML را می توان در مراحل مختلف چرخه حیاتی یک سیستم استفاده کرد، بیایید نگاهی به "4+1 view" دیاگرام های UML بیاندازیم. 4+1 view، ديدی متفاوت برای طبقه بندی و اعمال دیاگرام های UML ارائه می کند. 4+1 view، لزوماً بدین معنی است که یک سیستم چگونه از دید چرخه حیات یک نرم افزار مشاهده می شود. هر یک از این viewها، نشان می دهد چگونه یک سیستم مدل سازی می شود. این موضوع، ما را قادر به درک این مسئله می کند که دیاگرام های UML دقیقاً کجا قابل استفاده هستند.

این viewهای متنوع عبارتند از:

Design View: این view یک سیستم، view ساختاری یک سیستم است. این view، ایده ای از آنچه که یک سیستم معین از آن تشکیل یافته است می دهد. کلاس دیاگرام ها و object دیاگرام ها، design view یک سیستم را شکل می دهند.

Process View: رفتار دینامیک یک سیستم را می توان در حال استفاده از process view دید. دیاگرام های مختلف از قبیل state diagram، activity diagram، sequence diagram، و collaboration diagram در این view استفاده می شوند.

Component View: سپس، شما component view راد دارید که ماژول های گروه بندی شده یک سیستم معین را نشان می د هد که با استفاده از دیاگرام component، مدل سازی شده است.

Deployment View: از این view در UML برای معرفی ماژول های نصب یک سیستم معین استفاده می شود.

Use case View: نهایتاً، ما use case view را داریم. از دیاگرام های Use case در UML، برای مشاهده یک سیستم از این منظر، به عنوان فعالیتها یا مبادلاتی مجزا، استفاده می شود.

خلاصه

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

در سال 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 نمونه

معمولاً از 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

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

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

در شکل 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

با خواندن این 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 که حالتهای مختلفی را که یک کلاس در یک سیستم عمل کننده سپری می کند

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: مدیر گروه و ابزار گزارس دهی

در این 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های نرم افزارهای مختلفی را نشان می دهد که سیستم در بر گرفته است.

---

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

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 استفاده کنید و از مزیت هایش بهره مند شوید.

 

یک sequence diagram، شکلی از interaction diagram است که اشیاء را به صورت طول عمرهایی نشان می دهد که با interactionهایشان، که به صورت پیامهایی به شکل فلش هایی که از طول عمر مبدا به طول عمر مقصد کشیده شده ترسیم شده اند، در پایین صفحه اجرا می شوند. Sequence diagramها، برای نشان دادن اینکه کدام شی با اشیاء دیگر در ارتباط است، و اینکه کدام پیام ها، این ارتباط ها را trigger می کنند، مناسب است. Sequence diagramها، برای نشان دادن procedural logic پیجیده مناسب نیست.

طول عمرها (Lifeline)

یک طول عمر، شرکت کننده ای مجزا (individual participant) در یک sequence diagram را نشان می دهد. یک طول عمر معمولاً، دارای یک مستطیل است که حاوی نام شی اش است. اگر نامش "self" باشد، نشان دهنده این است که طول عمر، نشان دهنده classifierیی است که صاحب sequence diagram است.

بعضی اوقات، یک sequence diagram، دارای یک طول عمر با یک نماد عنصر actor، رو در قسمت بالایی خواهد بود. عناصر boundary، control، و entity، نیز می توانند طول عمر داشته باشند.

پیام ها

پیام ها به صورت فلش نمایش داده می شوند. پیام ها ممکن است کامل، مفقود یا پیدا؛ همزمان و غیرهمزمان؛ call یا signal، باشد. در دیاگرام زیر، پیام اول یک پیام همزمان است که با یک پیام بازگشت غیرمستقیم کامل می شود؛ پیام دوم غیرهمزمان است، و سومی یک پیام بازگشت غیرمستقیم است.

رویداد اتفاقی (Execution Occurrence)

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

Self Message

یک self message، می تواند یک call بازگشتی یک عملیات یا متدی را که متدهای دیگر متعلق به همان شی را فرا می خواند، نشان دهد. و به صورت ایجاد یک nested focus از کنترل در اتفاق اجرایی طول عمر، نشان داده شده.

پیام های مفقود و پیدا شده

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

شروع و پایان طول عمر

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

محدودیت های زمانی

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

اجزای ترکیبی

قبلاً گفته شد که sequence diagramها برای نشان دادن منطق فرایندی پیچیده مناسب نیستند. مکانیزم هایی وجود دارند که اجازه افزودن مقداری منطق فرایندی را به دیاگرام نمی دهند و زیر heading اجزای ترکیبی می آیند. یک جزء ترکیبی، یک یا چند processing sequence است که در یک قالب احاطه شده است و تحت شرایط معینی اجرا می شوند. اجزای درسترس، عبارتند از:

• جزء جایگزین ("alt")، constructهای if…then…else را مدل سازی می کند.
• جزء اختیاری ("opt")، constructهای switch را مدل سازی می کند.
• جزء break، ترتیبی جایگزین از رویدادها را که به جای کل بقیه دیاگرام پردازش می شوند را مدل سازی می کند.
• جزء موازی ("par")، پردازش همزمان را مدل سازی می کند.
• جزء ترتیب بندی ضعیف ("seq ")، تعدادی از ترتیب ها را، که به خاطرشان همه پیام ها باید در قسمت قبلی پردازش شوند، دربر می گیرد، اما هیچ گونه ترتیب گذاری ای را در یک قسمت به پیامی که طولی عمری را به اشتراک نمی گذارد، تحمیل نمی کند.
• جزء ترتیب گذاری دقیق ("strict") یک سری از پیام هایی را که باید در ترتیبی معین پردازش شوند، دربر می گیرد.
• جزء منفی ("neg ")، یک سری از پیام های نامعتبر را دربر می گیرد.
• جزء حیاتی، یک قسمت حیاتی را دربر می گیرد.
• جزء ignore، یک پیام یا پیامی را که اگر در بافت کنونی ظاهر شود، بی فایده خواهد بود را دربر می گیرد.
• جزء consider، اثری برعکس نسبت به جزء ignore دارد: هر پیامی که شامل این جزء نمی شوند، باید نادیده گرفته شوند.
• جزء assertion ("assert ")، مشخص می کند که هر ترتیبی که به صورت یک کارگزار(operand) نشان داده نمی شود، نامعتبر است.
• جزء حلقه، یک سری از پیام هایی را که تکرار می شوند، دربر می گیرد.

دیاگرام زیر یک جزء حلقه (loop) را نشان می دهد:

یک رویداد تعاملی (interaction occurrence) نیز وجود دارد، که شبیه یک جزء ترکیبی است. یک interaction occurrence، ارجاعی به دیاگرام دیگر است که کلمه "ref" را در گوشه چپ بالای frame دیده می شود، و هم نام دیاگرام ارجاع داده شده ای است که در وسط frame نشان داده شده.

دروازه (Gate)

دروازه، یک نتطه اتصال برای وصل کردن پیامی درون یک fragment به پیامی خارج از fragment است. EA، دروازه ای را به صورت یک مربع کوچک روی یک fragment frame نشان می دهد. دروازه های دیاگرام، به صورت connectorهایی off-page برای sequence diagramها عمل می کنند، و منبع پیام های دریافتی یا مقصد پیام های ارسالی را نمایش می دهد. دو دیاگرام بعدی به طورعملی چگونگی استفاده شدنشان را نشان می دهند. دقت کنید که دروازه ای که روی دیاگرام سطح بالا قراردارد، نقطه ای است که در آن سرفلش پیام، جزء ارجاعی را لمس را می کند – نیازی به render کردن آن به صورت یک box shape است.

Part Decomposition
یک شی می تواند بیش از یک lifeline داشته باشد. این موضوع، به پیام های بین اشیا و درون اشیا، اجازه ظاهر شدن روی همان دیاگرام را می دهد.

State Invariant / Continuations

state invariant، یک constraint است که روی lifeline قرار گرفته و باید در زمان اجرای برنامه، true باشد. و به صورت یک مستطیل با گوشه های نیمه گرد نشان داده می شود.

continuation، دارای همان نشانه ای است که state invariant دارد، اما در اجزای ترکیبی استفاده می شود و می تواند در بیش یک lifeline کشیده (stretch) شود.

class diagramهای UML، کلاس های سیستم، روابط داخلی شان، و عملیات ها و صفات کلاس ها را نشان می دهند. Class diagramها، معمولاً برای موارد زیر استفاده می شوند:

• مفاهیم domain را در شکل یک مدل domain، مرور می کند
• مقتضیات فرم یک مدل مفهومی را تحلیل می کند
• طرحی مفصل از نرم افزار شی گرا یا شی محور را نشان می دهد

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

• مسایل عمومی
• کلاس ها
• رابط های کاربر
• رابطه ها
• وراثت
• Aggregation و Composition

1. راهنمایی های عمومی

از آنجایی که class diagramها، استفاده های زیادی دارند — از درک نیاز ها گرقته تا توصیف طرح مفصل شما —باید از سبکی متفاوت برای هر شرایطی استفاده کرد. این بخش، راهنمایی های سبک (style) را که مربوط به انواع مختلف class diagram است، توصیف می کند.

شکل 1: تحلیل و نسخه های طراحی یک کلاس

شکل 2: مدل سازی کلاس های association

1. Identify Responsibilities on Domain Class Diagrams.
2. Indicate Visibility Only On Design Models. 
3. Indicate Language-Dependent Visibility With Property Strings.
4. Indicate Types Only On Design Models.
5. Indicate Types On Analysis Models Only When The Type is an Actual Requirement.
6. Design Class Diagrams Should Reflect Language Naming Conventions. در شکل 1 می بینید که،design version کلاس Order، از نام هایی استفاده می کنند که با Java programming conventionهای رایج از قبیل placementDate و calculateTaxes() هماهنگ می شود.
7. Model Association Classes On Analysis Diagrams. شکل 2 نشان می دهد که association classها به صورت کلاس الصاق شده از طریق یک dashed line به یک association، نشان داده شده اند – خط association، کلاس، و dashed line، یک سمبل در UML محسوب می شوند.
8. Do Not Name Associations That Have Association Classes
9. Center The Dashed Line of an Association Class

2. راهنمایی های Class Style

یک کلاس، یک template موثر است که اشیا ازآن ایجاد می شوند. گرچه در دنیای واقعی، Doug، John، و Bill همگی اشیای دانش آموز هستند، ولی ما کلاس Student را مدل سازی می کنیم. کلاس ها، صفات را توصیف می کنند، اطلاعاتی که مربوط به instance، عملیات، عملکردهایشان است که اشیا آنها را ساپورت می کنند. همچنین کلاسها، رابط های کاربر (interface) را نیز تشخیص می دهد. دقت داشته باشید که شاید نیاز به نرم کردن بعضی از راهنمایی های نامگذاری جهت منعکس کردن زبان یا نرم افزار برنامه نوسی تان داشته باشید که از یک فروشنده طرف سوم خریداری کرده اید.

شکل 3: کلاس OrderItem با و بدون کد scaffolding

1. Use Common Terminology for Names
2. Prefer Complete Singular Nouns for Class Names
3. Name Operations with a Strong Verb
4. Name Attributes With a Domain-Based Noun
5. Do Not Model Scaffolding Code. کد Scaffoldin، به صفات و عملیات هایی بازمی گردد که برای پیاده سازی عملکرد پایه ای در کلاس شما لازم هستند، از قبیل کدی که برای پیاده سازی رابطه با کلاس های دیگر لازم هستند. شکل 3، تفاوت بین کلاس OrderItem را با و بدون scaffolding code نشان می دهد.
6. Never Show Classes With Just Two Compartments
7. Label Uncommon Class Compartments
8. Include an Ellipsis ( … ) At The End of Incomplete Lists
9. List Static Operations/Attributes Before Instance Operations/Attributes
10. List Operations/Attributes in Decreasing Visibility
11. For Parameters That Are Objects, Only List Their Type
12. Develop Consistent Method Signatures
13. Avoid Stereotypes Implied By Language Naming Conventions
14. Indicate Exceptions In An Operation’s Property String. می توان خطاها را با یک UML property string نشان داد.

3. رابط های کاربر (Interface)

یک interface، کلکسیونی از امضای عملیات و/یا تعریف های صفات است که مجموعه ای منسجم از رفتارها را تعریف می کند. interfaceها، در UML parlance، توسط کلاس ها و componentها، پیاده سازی و شناسایی می شوند – تا تشخیص دهد که یک interface، یک کلاس، یا یک component، باید عملیات ها و صفاتی را که توسط interface تعریف می شوند، پیاده سازی کند. هرکلاس یا component معینی، ممکن است هیچ یا چند interface، و یک یا چند کلاس را پیاده سازی کند، یا componentها می توانند همان interface را اجرا کنند.

شکل 5: interfaceها روی UML class diagramها

1. Interface Definitions Must Reflect Implementation Language Constraints. در شکل 5، می بینید که یک standard class box، برای تعریف interface PersistentObject استفاده شده است.
2. Name Interfaces According To Language Naming Conventions
3. Apply “Lollipop” Notation To Indicate That A Class Realizes an Interface
4. Define Interfaces Separately From Your Classes
5. Do Not Model the Operations and Attributes of an Interface in Your Classes. در شکل 5، می بینید که کلاس Shipment، شامل صفات یا عملیات های که توسط دو interface که شناسایی می کند، نمی شود.
6. Consider an Interface to Be a Contract

4. راهنمایی های رابطه (Relationship)

برای راحتی، عبارت relationships، شامل همه مفاهیم UML از قبیل associationها، aggregation، composition، dependencyها، inheritance، و realizationها را شامل می شوند – به عبارت دیگر، اگر خطی روی یک UML class diagram وجود داشته باشد، آن را یک رابطه در نظر می گیریم.

شکل6: Shipping یک order

شکل 7: Modeling یک order

شکل 8: استادها و سمینارها.

شکل 9: مدل سازی افراد در یک دانشگاه.

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

1. Collaboration Indicates Need for a Relationship
2. Model a Dependency When The Relationship is Transitory
3. Depict Similar Relationships Involving A Common Class As A Tree. در شکل 6، می بینید که هم Delivery و هم Order، یک dependency روی OIDGenerator دارند. توجه داشته باشید که چگونه دو dependency در ترکیب با “tree configuration” ترسیم شده اند؛ به جای اینکه به صورت دو خط جدا جهت کاهش clutter در دیاگرام ترسیم شوند.
4. Always Indicate the Multiplicity
5. Avoid a Multiplicity of “*”
6. Replace Relationships By Indicating Attribute Types. در شل7، می بینید که مشتری ها دارای یک صفت shippingAddress از نوع Address هستند یعنی، قسمتی از کد scaffolding که برای حفظ رابطه بین اشیاء و اشیاء آدرس استفاده می شود–
7. Do Not Model Implied Relationships
8. Do Not Model Every Single Dependency
9. Center Names on Associations
10. Write Concise Association Names In Active Voice
11. Indicate Directionality To Clarify An Association Name
12. Name Unidirectional Associations In The Same Direction
13. Word Association Names Left-To-Right
14. Indicate Role Names When Multiple Associations Between Two Classes Exist
15. Indicate Role Names on Recursive Associations
16. Make Associations Bi-Directional Only When Collaboration Occurs In Both Directions. lives at association در شکل 9، یک طرفه است.
17. Redraw Inherited Associations Only When Something Changes
18. Question Multiplicities Involving Minimums And Maximums

6. راهنمایی های وراثت

وراثت، رابطه های “is a” و “is like” را مدل سازی می کند و شما را به راحتی قادر به استفاده مجدد از داده ها و کد موجود می کند. وقتی "A" از "B" ارث می برد، گفته می شود که "A" زیرکلاس "B" و "B" سوپرکلاس "A" است. به علاوه، وقتی "A" همه صفات و متدهای "B" را به ارث می برد، به آن " وراثت محض" گفته می شود. نشانه گذاری مدل سازی UML برای وراثت، خطی با یک سرفلش (arrowhead) است که از زیرکلاس به سوپرکلاس اشاره می کند.

1. Apply the Sentence Rule For Inheritance
2. Place Subclasses Below Superclasses
3. Beware of Data-Based Inheritance
4. A Subclass Should Inherit Everything

7. راهنمایی های Aggregation و Composition

بعضی اوقات یک شی از اشیاء دیگر دیگر درست می شود. مثلاً، یک هواپیما از بدنه، بالها، موتور، ابزار فرود، دریچه بال هواپیما (فلپ)، و غیره درست شده است. یک delivery shipment، حاوی یک یا دو بسته است. یک تیم متشکل از دو یا چند کارمند است. اینها، مثال هایی از مفهوم aggregation هستند که رابطه “is part of” را نمایش می دهد. موتور، بخشی از یک هواپیما است ، یک package، بخشی از یک shipment است، و یک کارمند، عضوی از یک تیم است. Aggregation، تخصصی از association است، که یک رابطه کل به جزء (whole-part) بین دو جسم است. Composition، شکلی قویتر از aggregation است که "کل" و "اجزاء" عمری همسان دارند، و برای مدیریت چرخه حیاتی اجزای whole، بسیار رایج است؛ زیرا از دیدگاهی سبک دار، aggregation و composition هر دو تخصص های association هستند.

شکل 10: نمونه هایی از aggregation و composition.

1. Apply the Sentence Rule for Aggregation
2. You Should Be Interested In Both The Whole And The Part
3. Depict the Whole to the Left of the Part
4. Apply Composition to Aggregates of Physical Items
5. Apply Composition When the Parts Share The Persistence Lifecycle With the Whole
6. Don’t Worry About Getting the Diamonds Right

کلاس دیاگرامها ((class diagrams در UML، مهمترین قسمت تحلیل و طراحی شی گرا هستند. UML 2 class diagram، کلاسهای سیستم، روابط درونی شان (شامل وراثت، aggregation، و association)، و عملیاتها و نسبتهای کلاس را نشان می دهد. Class diagramها، موارد استفاده زیادی دارند، از قبیل مدل سازی مفهومی/دومینی و مدل سازی طراحی با جزییات. من ترجیح می دهم که class diagramها را روی وایت برد ترسیم کنم، زیرا ابزارهای ساده، قابل درک تر هستند. اکثر دیاگرام هایی که من در این مقاله نشان خواهم داد، با استفاده از یک وسیله نرم افزاری طراحی، ترسیم شده اند.

در این مقاله، موارد زیر مورد بحث قرار می گیرد:

• Class diagramهای مفهومی
• طراحی class diagrams
• چگونگی ایجاد یک UML class diagram

1. دیاگرام های Conceptual Class

شکل 1، شروع یک UML class diagram یک مدل مفهومی برای دانشگاه را نشان می دهد. Classها به صورت جعبه هایی با سه قسمت نشان داده شده اند؛ قسمت بالایی، نام کلاس را نشان می دهد، قسمت میانی، attributeهای کلاس را لیست می کند، و قسمت سوم، متدها را لیست می کند. با دربرگرفتن یک attribute و یک جعبه در کلاس، دارم درباره مدل خودم تصمیم گیری می کنم، بعضی اوقات اگر هدف من مدل سازی مفهومی باشد، نباید این کار را انجام دهم. روش دیگر، داشتن دو قسمت است، یکی برای اسم و دیگری برای لیست کردن مسئولیتها. این کار، به یک CRC mode نزدیکتر خواهد بود (پس اگر می خواستم از این روش استفاده کنم، از کارتهای CRC به جای یک UML class diagram استفاده می کردم). همچنین می توانستم از class boxها استفاده کنم که فقط اسم کلاس را نشان مدهد، و مرا قادر به تمرکز روی کلاسها روی کلاسها و روابطشان می کند. اما اگر هدف من آن بود، بیشتر احتمال داشت به جایش یک ORM diagram ایجاد کنم. به طور خلاصه، من ترجیح می دهم روش AM’s Apply the Right Artifact(s) را دنبال کنم و از هر تکنیک مدل سازی استفاده کنم.

شکل 1: طرح اولیه یک class diagram مفهومی

Enrollment، یک کلاس پیوندی (associative) است، که یک کلاس لینک نیز نامیده می شود، و برای مدل سازی associationهایی بکار می رود که دارای متد و attribute هستند. این کلاسها معمولاً هنگام تحلیل مدل سازی می شوند و سپس به چیزی که هنگام طراحی در شکل 2 نشان می دهم، refactore می شود (شکل 2، یک دیاگرام مفهومی است). تا جاییکه من می دانم، هیچ زبان برنامه نویسی ای وجود ندارد که تصویر (notion) associationهایی را ساپورت کند که مسئولیت دارند. زیرا شما می توانید نرم افزارتان را مستقیماً دراین حالت بسازید، من تمایلی به استفاده از کلاسهای association ندارم و در عوض آنها را با تلاشهای هنگام تحلیل، حل می کنم. این روش، بهترین روش برای مدل سازی نیست، اما عمل گرایانه است، زیرا اعضای دیگرتیم، شامل stakeholderهای پروژه، نیازی به یادگیری علامت ها و مفاهیم پشت کلاسهای associative ندارند.

شکل 2، نسخه بازنویسی شده شکل 1 را نشان می دهد. کلاس associative، تجزیه شده است. می توانستم یک attribute در کلاس Seminar، تحت نام Waiting List، اضافه کنم، اما در عوض آن را به صورت یک association مدل سازی کنم، زیرا واقعاً چیزی است که نمایش می دهد: اشیاء آن سمینار، لیستی از اشیاء 0 یا دانش آموزان بیشتری را حفظ می کند. Attributeها و associationها هر دو propertyهایی درUML 2.0 هستند، پس اساساً با آنان به صورت همان نوع چیزها رفتار می شود. همچنین نشان دادم که associationها، به صورت ترکیبی از attributeها و operationها پیاده سازی می شوند. به علاوه، این موضوع، مسئله طراحی با جزییات زیاد خواهد بود، که بعضی وقتها بای یک مدل مفهومی مناسب نیست.

on waiting list ، یک association یک طرفه است زیرا هنوز به همکاری در دو جهت نیازی نیست. روش Create Simple Content را دنبال کنید و بیش از حد مدل سازی نکنید – در حال حاضر نیازی به نیازی به association دوطرفه ندارید، پس آن را مدل سازی نمیکنید. enrolled in، یک association بین کلاسهای Student و Enrollment است که به دلایل مشابه، یک طرفه است. برای این association، بنظر می رسد که اشیاء student می دانند درگیر چیزی هستند که enrollment ثبت می کند؛ سمینارهایی که در گذشته شرکت کرده اند، و همچنین سمینارهایی که در حال حاضر با آنها درگیر هستند. این association، برای محاسبه معدل object دانش آموزان و فراهم کردن اطلاعات درباره سمینارهایی که در آنها شرکت کرده اند، بکار می رود.

همچنین یک enrolled in association بین Enrollment و Seminar وجود دارد تا قابلیت اشیاء student، جهت تهیه لیستی از سمینارها را ساپورت کند. instructs association بین کلاس Professor و کلاس Seminar، دو طرفه است، زیرا اسیاء professor، آنان می دانند چه سمینارهایی را تدریس کرده اند و اشیاء سمینار می دانند چه کسی به آنان تدریس کرد ه است.

وقتی دارم مدل سازی مفهومی می کنم، سبک من، نام گذاری attributeها و متدها با استفاده از فرمتهایAttribute Name و Method Name ست. دنبال کردن یک روش ثابت و محسوس برای نام گذاری، کمک می کند تا دیاگرامتان قابل خواندن شود، که یک مزیت مهم در روش AM’s Apply Modeling Standards است. همچنین در نظر داشته باشید که چگونه من در شکل 2، قابلیت دیده شدن attributeها و متدها را تا حد زیادی مدل سازی نکرده ام. قابلیت دیده شدن (Visibility) هنگام طراحی، مسئله مهمی است، اما فعلاً می توان آنرا نادیده گرفت. این را هم در نظر داشته باشید که من همه امضاهای متد این کلاس را تعریف نکرده ام.

من با اطمینان و براساس این اطلاعات، توانستم کثرتها (multiplicity) را برای همه associationها غیر از یکی، تعیین کنم و آن را با یک یادداشت علامت گذاری کردم تا بعداً با stakeholderهایم درباره آن بحث کنم. به استفاده من از علامت سوال در این یادداشت توجه کنید.

در شکل 2، من یک UML constraint را در این مورد {ordered FIFO} روی association بین Seminar و Student مدل سازی کردم. ایده اصلی این است که دانش آموزان بر اساس FIFOدر لیست انتظار گذاشته می شوند.

به عبارت دیگر، دانش آموزان به ترتیب در لیست گذاشته می شوند. از Constraintهای UML، برای مدل سازی اطلاعات پیچیده و یا مهم موجود در دیاگرام های UMLتان استفاده می شود. Constraintهای UML، با استفاده از فرمت “{constraint description}” مدل سازی می شوند، جاییکه constraint description ممکن است هر فرمتی داشته باشد، مثلاً predicate calculus.

2. طراحی Class Diagramها

به زودی

3. چگونگی ایجاد کردن Class Diagramها

جهت ایجاد و تکمیل یک conceptual class diagram، باید موارد زیر را به طور مکرر مدل سازی کنید:

• کلاس ها
• مسئولیت ها
• Associationها
• روابط وراثتی
• Composition associationها
• Vocabularyها

جهت ایجاد و تکمیل یک design class diagram، باید موارد زیر را به طور مکرر مدل سازی کنید:

• کلاس ها
• مسئولیت ها
• Associationها
• روابط وراثتی
• Composition associationها
• Interfaceها

3.1. کلاس ها

یک object، می تواند یک شخص، مکان، شی، مفهوم، رویداد، صفحه، یا گزارش باشد که مربوط به سیستم شماست. Objectها هم چیزها را می شناسند (دارای attribute هستند) و کار انجام می دهند (دارای متد هستند). یک کلاس، نمایشی از یک object است و، فقط یک template است که objectها از آن ایجاد می شوند. کلاس ها، بخش اصلی یک برنامه شی گرا را شکل می دهند. با اینکه هزاران دانش اموز در دانشگاه شرکت می کنند، اما شما فقط یک کلاس به نام Student را مدل سازی می کنیدف که کل کلکسیون دامش آموزان را نمایش می دهد.

3.2. مسئولیت ها

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

ملاحظه ای مهم برای سطح مناسب جزییات:

کلاس مدل سازی شده student را در شکل 2 ملاحظه کنید که دارای یک attribute و address است. وقتی در مورد آن تامل می کنید، می فهمید که آدرس ها، چیزهای پیچیده ای هستند. آنها داده های پیچیده ای دارند، که مثلاً حاوی اطلاعات خیابان و شهر می شود. یک روش بهتر مدل سازی آن، در شکل 4 نشان داده شده است. دقت کنید که کلاس Address مدل سازی شده تا یک attribute برای هر قسمت از داده هایی را که تشکیل می دهد، در بربگیرد، و 2 متد اضافه شده است: یکی جهت تایید اینکه این آدرس معتبر است و دیگری جهت نمایش آن به صورت یک لیبل (شاید برای پاکت پستی). با معرفی کلاس Address، کلاس Student منسجم تر شده است. و دیگر منطقی را که مرتبط به آدرس است، دربر نمی گیرد. حالا می توان از کلاس Address در جاهای دیگردوباره استفاده کرد، مثلاً در کلاس Student که هزینه کلی develop کردن را کاهش می دهد. به علاوه، اگر نیاز به ساپورت دانش آموزان با چندین آدرس باشد — ممکن است در طول ترم یک دانش آموز در جاهای مختلفی غیر از آدرس پستی دایمش زندگی کند، مثلاً در خواب گاه — ممکن است سیستم نیاز به ردیابی اطلاعات کند. داشتن یک کلاس مجزا برای پیاده ساری آدرس ها، باید پیاده سازی اضافه کردن این رفتار را آسان کند.

شکل 4: دانش آموز و آدرس ها (Conceptual class diagram)

یک ویژگی جالب کلاس Student، مسئولیت Is Eligible to Enroll است. خط زیر آن نشان می دهد که این، یک responsibility در سطح کلاس است، نه یک responsibility در سطح مثال. یک علامت خوب که یک مسئولیت متعلق به سطح کلاس این است که آن مسئولیت این معنی را می دهد که متعلق به کلاس است ولی به شی مجزای آن کلاس اعمال نمی شود. د راین مورد، این عملیات، BR129 Determine Eligibility to Enroll را که در Enroll in Seminar system use caseفراخوانده شده، پیاده سازی می کند.

کلاس Seminar در شکل 2، به کلاس هایی که در شکل 5 نشان داده شده، refactore می شود. به چنین refactore کردنی " class normalization " می گویند، فرآیندی که در آن شما کلاسهای رفتار را refactore می کند تا انسجام شان یا افزایش، و یا جفت شدن بین کلاسها را کاهش می دهد. یک سمینار، به معنار ارایه کردن یک درس است، مثلاً، ممکن است 5 سمینار وجود داشته باشد که درس " CSC 148 Introduction to Computer Science " را ارایه می دهند، صفت name و fees به کلاس Course منتقل شدند و courseNumber معرفی شد. متد getFullName()، شماره درس "CSC 148" و نام درس " Introduction to Computer Science " را به هم زنجیر می کند تا نام کامل درس را بدهد. این روش، روش getter نامیده می شود، عملیاتی که یک data value مرتبط به یک شی را باز می گرداند. گرچه متدهای getter، و متدهای متناظر setter، باید برای کلاسی که فرض می شود معمولاً وجود دارد، develop شوند، و بنابراین برای اینکه مدل شما را بهم نریزد، مدل سازی نمی شوند (مخصوصاً درconceptual class diagrams).

شکل 5: سمینار نرمال شده (Conceptual class diagram).

شکل6، Course شکل 5 را نشان می دهد، همانطور که با متدهای مدل سازی شده getter و setter خودش ظاهر می شود.

getterها و setterها، جزییات هستند که برای مدل های مفهومی مناسب نیستند و با تجربه ای که من دارم، حتی برای دیاگرام های design جزییات دار نیز مناسب نیستند — در عوض، من یک کد راهنما تنظیم می کنم که همه خصوصیات دارای متد getter و setter باشند، و همه اش را در آن رها می کنم. بعضی ها، مدل سازی getter و setter را انتخاب می کنند، اما من آنها را مزاحمانی می دانم که دیاگرام شما را بدون افزودن value، به هم می ریزند.

شکل 6، درس ها با متدهای accessor

3.3. associationها

اشیاء اغلب به اشیاء دیگر مرتبط هستند. مثلاً، همانطور که در شکل 2 می بینید، چندین association وجود دارد: دانش آموزان برای سمینار در لیست انتظار هستند؛ استادها، سمینارها را هدایت می کنند؛ سمینارها، کلاس ها را ارائه می کنند، هر استادی در یک آدرس سکونت دارد، و غیره. associationها به صورت خطوطی مدل سازی می شوند که دو کلاس را که اشیای آنها در این رابطه درگیر هستند را به هم وصل می کند.

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

شکل 6: نشانه associationها

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

نشانگر	معنی
0..1	صفر یا یک
1	فقط یک
0..*	صفر یا بیشتر
1..*	یک یا بیشتر
n	فقط n (جاییکه n > 1)
0..n	صفر تا n (جاییکه n > 1)
1..n	صفر تا n (جاییکه n > 1)

یک آپشن دیگر برای association، نشان دادن جهتی است است که لیبل در آن باید خوانده شود. این کار با استفاده از یک مستطیل پرشده نشان داده می شود که نشانگر جهت نامیده می شود، و یک مثال از آن روی offering رابطه بین Seminar و کلاسهایCourse شکل 5 نشان داده شده است. این نماد (symbol) نشان می دهد که association باید بدین صورت خوانده شود: " یک سمینار، ارائه ای یک درس است"، به جای "یک درس، ارائه یک سمیناراست". نشانگر جهت، باید زمانی استفاده شود که مشخص نیست یک لیبل چگونه باید خوانده شود. اما توصیه من این است که اگر لیبل شما مشخص نیست، باید واژه های آن را عوض کنید.

سر فلشهایی (arrowhead) که انتهای خط هستند، جهت association را نشان می دهند. خطی که یک arrowhead دارد، یک طرفه است، در حالیکه خطی که هیچ یا در arrowhead دارد، دو طرفه است. شما باید هر دو arrowhead را برای associationهای دو طرفه شامل کنید، اما، روش معمول، drop کردن آنها است.

در هر دو انتهای association، یک role، یعنی بافتی (context) که یک شی در association می گیرد، نیز ممکن است نشان داده شود. من role را فقط زمانی که اطلاعات، value را اضافه می کند، مدل سازیم می کنم. من از AM practice Depict Models Simply استفاده می کنم و اگر یک association بازگشتی وجود داشته باشد، یا اگر چندین association بین کلاس ها وجود داشته باشد. roleها را، هنگامی که از لیبل association مشخص نیست که چه چیزی هستند، نشان می دهم.

3.4. رابطه های ارثی

اغلب، شباهتهایی بین کلاسهای مختلف وجود دارد. معمولاً، دو یا چند کلاس، دارای صفتهای یا متدهای مشابهی هستند. زیرا، دوست ندارید مجبور باشید مکرراً کدهای شبیه هم را بنویسید، شما به مکانیزمی احتیاج دارید که استفاده بهینه را از این شباهت ها ببرد. وراثت، همان ساز و کار مورد نیاز است. وراثت، رابطه های “is a” و “is like” را مدل سازی می کند، و شما را قادر به استفاده مجدد و راحت از داده ها و کدهای موجود می کند. وقتی A، از B ارث می برد، گفته می شود که A، زیرکلاس B است و B، سوپر کلاس A است. به علاوه، هنگامی که A، ههم صفات و متدهای B را به ارث می برد، به آن "ارث محض" گفته می شود. نشانه های مدل سازی UML برای ارث، خطی با یک arrowhead بسته است که از زیر به کلاس به سوپر کلاس اشاره می کند.

شباهتهای زیادی بین کلاس های Student و Professor در شکل 2 وجود دارد. نه تنها دارای صفات شبیه هم هستند، بلکه متدهای شبیه به همی هم دارند. برای استفاده از این مزایا، من کلاس جدیدی به نام Person ایجاد کردم و کلاس های Student و Person هر دو از آن ارث بردند، همانگونه که در شکل 7 می بینید. نام این ساختار، سلسله مراتب وراثت (inheritance hierarchy) است، زیرا کلاس Person کلاس ریشه آن است. کلاس Person، انتزاعی (abstract) است: اشیاء مستقیماً از آن ایجاد نمی شوند، و شباهتهای بین دانش آموزان و استادها را capture میکند. کلاس های انتزاعی، برخلاف کلاسهای واقعی (concrete)، با نام هایشان که به صورت مورب (italics) است، مدل سازی می شوند. کلاس های واقعی، کلاس هایی هستند که اشیاء از آنها نمونه سازی می شوند و نامشان به صورت متن معمولی است. هر دو کلاس دارای نام، آدرس ای میل، و شماره تلفن هستند، پس این صفات، به Person نیز منتقل شدند. متد Purchase Parking Pass نیز بین این دو کلاس parent رایج هستند. با معرفی این رابطه وراثتی به مدل، مقدار کاری که باید اجرا شوند، کم می شود. به جای اینکه این مسئولیت ها را دوبار پیاده سازی کنیم، آنها در کلاس Person یک بار اجرا می شوند، و توسط Student و Professor دوباره استفاده می شوند.

شکل 7: سلسله مراتب وراثت

3.5. Composition Association

بعضی اوقات یک شی از اشیاء دیگر دیگر درست می شود. مثلاً، یک هواپیما از بدنه، بالها، موتور، ابزار فرود، دریچه بال هواپیما (فلپ)، و غیره درست شده است. شکل 8، مثالی است که با استفاده از composition، واقعیتی که یک ساختمان از یک چند اتاق تشکیل شده است، و سپس اینکه یک اتاق ممکن است از چندین اتاق کوچکتر تشکیل شده باشد را مدل سازی می کند (می توانید composition بازگشتی داشته باشید). در UML 2، aggregation با یک الماس باز نشان داده شده است.

شکل 8: مدل سازی composition

من به قانون جمله "part of" اعتقاد راسخ دارم – اگرگفتن این که "یک چیز بخشی از چیز دیگری است" معنی دار باشد، آنگاه شانس خوبی برای وجود دارد که composition نیز معنی دار باشد. مثلاً، گفتن اینکه یک اتاق بخشی از یک ساختمان است معنی دار است، اما گفتن اینکه یک آدرس بخشی از یک فرد است، معنی دار نیست. علامت خوب دیگری که نشان می دهد composition معنی دار است، هنگامی است که چرخه حیاتی یک بخش توسط کل، مدیریت می شود—مثلاً، یک هواپیما فعالیت های یک موتور را مدیریت می کند.

Craig Larman (2002) ، در مورد استفاده از composition روی association می گوید: اگر شک داشتید، حذفش کنید. متاسفانه بسیاری از مدل سازان، هنگامی که تفاوت کمی بین association و composition در مرحله coding وجود دارد، از اینکه کی باید از composition استفاده کنند عذاب می کشند.

شکل 9: طبقه بندی افراد درون یک دانشگاه.

معنا شناسی (semantics) مدل مفهومی شما در یک واژه نامه بهتر capture می شود. شکل 9، چندین جنبه جالب دارد:

• به جای رویکرد سه بخشی که در دیاگرام های قبلی دیده ایم، رویکردی تک بخشی “single section” نسبت به کلاس ها دارد؛ زیرا ما رابطه های بین موجودیت داده ها را مرور می کنیم، نه مسولیت هایشان را.
• از مفهوم generalization set در UML 2.0 استفاده می کند، مخصوصاً از یک سرفلش وراثتی با یک لیبل که نام set را نمایش می دهد. در UML 1.x، این لیبل یک discriminator نامیده می شد. سه set برای Person وجود دارد: Nationality (ملیت)، Role (نقش)، و Gender (جنسیت).
• این generalization setها، با هم تداخل دارند — یک شخص را می توان از طریق هر یک از این نقش ها طبقه بندی کرد (مثلاً یک شخص می تواند یک دانش آموز خارجی مذکر باشد). به این کار طبقه بندی چندگانه می گویند.
• می توانید setهای “sub generalization” را نشان دهید، مثلاً، Student در Role generalization set.
• بعضی از setهای generalization، به طور دو جانبه ای از دیگر setها، exclusive هستند، که در مثال نشان داده نشده است، که در آن، یک موجودیت داده ممکن است فقط در یک set موجود باشد. به این کار "طبقه بندی واحد" گفته می شود و با استفاده از یک XOR constraint بین دو یا چند discriminator، مدل سازی می شود.

یک UML Use Case Diagram (UCD) چیست، و کی باید از آن استفاده کرد؟

دیاگرام های UML Use Case را می توان جهت توصیف عملکرد یک سیستم به صورت افقی استفاده کرد. این بدین معناست که غیر از صرفاً نمایش ویژگیهای ویژه سیستم شما، می توان از UCDها جهت نشان دادن همه عملکردهایی که در دسترس است، استفاده کرد. تذکر این نکته مهم است که UCDها اساساً با sequence diagramها یا flow chartها فرق دارند، زیرا آنها تلاشی برای نشان دادن ترتیب یا تعداد دفعاتی که systems actionها و sub-actionها باید اجرا شوند، نمی کنند. تعدادی مثال گرافیکی در این مقاله وجود دارد؛ شاید بخواهید نگاهی به آنها بیاندازید تا با ظاهرشان آشنا شوید.

UCDها دارای فقط 4 عنصر اصلی هستند: actorها، که سیستمی که شما توصیف می کنید، با آن ارتباط متقابل دارد، خود سیستم، use caseها، یا سرویسها، که سیستم می داند چگونه اجرا کند، و خطوطی که نشانگر رابطه بین این عناصر هستند.

شما باید از UCD برای نمایش عملکردهای سیستم تان به صورت top-down استفاده کنید (یعنی از نگاهی که عملکرد سیستم واضح است، اما توصیفها در سطح بالایی هستند. جزییات بیشتر را می توان به دیاگرام ، جهت توضیح دادن نکات جالب در رفتار سیستم، اضافه کرد).

مثال: یک UCD، به خوبی با task توصیف همه چیزهایی که می توان با یک database، توسط تمامی افرادی که می توانند انرا ببینند، انجام داد، سازگار شود.

شما نباید از UCDها برای نمایش رفتارهای استثناء (هنگام روی دادن error) استفاده کنید، یا تلاش کنید ترتیب مراحلی را که باید به منظور تکمیل یک task اجرا شوند، نشان دهید. برای این کار از دیاگرام Sequence استفاده کنید.

مثال: یک UCD، به طور بد وضعیفی با توصیف پروتکل شبکه ای TCP/IP سازگار می شود، زیرا موارد استثناء (exception cases)، رفتارهای شاخه ای (branching behaviors)، و عملکردهای شرطی (conditional functionality) زیادی وجود دارد.

چگونه بفهمیم actorهای یک UCD چه کسانی هستند؟

وقتی با یک جدول Action/Response کار می کنید، شناسایی actor آسان است: موجودیت هایی که رفتارشان در ستون "Actor's Actions" ظاهر می شود، actor هستند؛ و موجودیت هایی که رفتارشان در ستون "System's Response" ظاهر می شود، componentهای سیستم هستند.

اگر در حال کار کردن با نسخه ای قدیمی، یک دیاگرام sequence، یا توصیف یک سناریو هستید، actorها معمولاً موجودیت هایی هستند که نمی توان رفتارشان را کنترل کرد یا تغییر داد (مثلاً agentهایی که قسمتی از سیستمی نیستند که شما می سازید یا توصیف می کنید). بارزترین کاندیدها برای actorها، نقشهای سیستم هستند، مگر در موارد نادری که سیستمی که شما توصیف می کنید، واقعاً یک فرآیند انسانی است (از قبیل متد معینی برای رابطه با مشتری هایی که باید توسط کارمندان پیگیری شوند). نقشهایی که باید با ان ارتباط متقابل برقرار کرد،همگی actor هستند. اگر سیستم شما با سیستمهای دیگر (ازقبیل databaseها، و سرورهایی که توسط افراد دیگر یا legacy system نگه داری می شوند) ارتباط متقابل دارد، بهتر است با آنها مثل actorها برخورد کنید.

مثال: هنگام افزودن یک database جدید به سیستم، جهت مدیریت امور مالی شرکت، احتمالاً سیستم شما مجبور به ایجاد رابطه با نرم افزار موجود برای مدیریت انبار خواهد بود. از آنجاییکه شما آن نرم افزار را ننوشته اید، آن را جایگزین نکنید، و ففط از سرویسهایی که در اختیارتان می گذارد استفاده کنید، actor بودن برای آن سیستم، معنادار خواهد بود.

از کجا بفهمیم در "System" box چه چیزی بگذاریم؟

system box فقط در دیاگرام های سطح بالا ظاهر می شود (به یاد داشته باشید که توصیف یک UML Use Case معمولی، از دیاگرام ها و زیردیاگرام های زیادی تشکیل خواهد شد)، و باید نمادهای Use case را دربربگیرد، یکی برای هر سرویس سطح بالایی که سیستم شما برای actorهایش فراهم می کند. هر نوع رفتار داخلی، که سیستم شما ممکن است داشته باشد و فقط توسط بخشهای دیگر سیستم استفاده می شوند، نباید در system box ظاهر شود. یک راه مفید برای استفاده از این سرویسهای سطح بالا، به ترتیب زیر است:

اگر یک use case، یک سرویس سطح بالا را ارایه می کند، آن سرویس باید برای actorهایی که با آن در ارتباط متقابل هستند تا فقط آن سرویس را در یک session از سیستم شما تقاضا کنند، معنی دار باشد.

مثال: در دیاگرام زیر، قصد داریم use case را برای یک دوربین نمایش دهیم. فرض کنید ما "Open Shutter"، "Flash"، و "Close Shutter" را به عنوان use caseهای سطح بالا انتخاب می کنیم. مسلماً، تمامی اینها رفتارهایی هستند که یک دوربین دارد، اما هیچ عکاسی دوربینش را برنمی دارد، سپس shutter را باز کند، و آن را پایین بگذارد، وآن روز از عکس برداریش راضی باشد. چیز مهمی که باید بفهمیم این است که این رفتارها به تنهایی انجام نمی شوند، اما نسبتاً بخشی از یک use case سطح بالاتر، یعنی "take picture" است. (به یاد داشته باشید که یک بار عکس گرفتن با دوربین برای عکاسان بی معنی است.)

actorها در دیاگرام من ارتباط های متقابل دارند. چگونه انها را نشان دهم؟

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

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

می خواهم ترتیبی از اعمالی را که سیستم اجرا می کند، نشان دهم. چگونه این کار را بکنم؟

با استفاد ه از یک UML Use Case Diagram نمی توانید این کار را انجام دهید. UCDها باید توصیفی از بالا به پایین (top-down) و افقی از عملکرد باشد، نه توصیفی جزء به جزء از رفتار. در بیشتر اوقات، تلاش برای نمایش ترتیبی از اعمال با دیاگرام های use case، ایده خوبی نیست. در عوض شما باید از دیاگرام sequence یا یک flow chart سنتی استفاده کنید. (همانطور که در زیر توضیح داده شده، نمایش شرایط شاخه ای ساده (simple branching conditions) با یک UCD، امکان پذیر است، اما از این تکنیک باید کمتر استفاده کنید زیرا ممکن است یک دیاگرام را غیر فابل خواندن بکند).

تفاوت یک UML Use Case Diagram با flow chart سنتی چیست؟

همانطور که در بالا اشاره شد، UCDها، عملکرد را به صورت از بالا به پایین نمایش می دهند، در حالیکه flow chartها، رفتار را به صورت خطی و زمان محور نشان می دهند. همچنین، روش develop کردن آنها نیز متفاوت است.

مثال: (این متن مربوط به دیاگرام زیر است). هنگام ساختن یک UCD، مرحله اول، شناخت تمامی رفتارهای سطح بالا است. وقتب این کار را انجام دادید، از قبل باید ، همه کارهایی را که سیستم شما می داند چگونه انجام دهد، حداقل به روشی سطح بالا، توصیف کرده باشید. سپس با تجزیه کردن use caseتان به use caseهای بیشترکه توسط use case سطح بالا استفاده می شوند، می توانید به اضافه کردن جزییات ادامه دهید. در هر مرحله از از نصب، UCD شما، شرح کاملی از عملکرد سیستم است: شاید فاقد جزییات باشد، اما فاقد عناصر feature set نخواهد بود. و اگر عملکرد یا رفتار در طول حیات پروژه تان اضافه یا حذف شود، محدوده تغییراتی که باید اعمال کنید، وابسته به محدوده تغییرات در خود سسیستم، و کامل بودن مدلتان است. این، مفید است؛ زیرا بدین معناست که وقتی مدلتان خیلی ناقص است، ایجاد تغییدات گسترده در سیستم، مستلزم کنارگذاشتن کارهای دیگر نیست. اما یک flow chart، تا وقتی که ترسیم آن را تمام نکرده اید، به طور صحیح سیستم را توصیف نمی کند، حتی تغییرات کوچک در سیستم منجر به بازنویسی flow chartهای تان خواهد شد. عموماً، UCها، فرایند تحلیل و طراحی را خیلی بهتر از flow chartها ساپورت می کنند.

کی از uses arrow استفاده کنم؟

extends arrow یا (extends edge)، از یک use case X به یک use case Y کشیده می شوند تا نشان دهند که فرآیند X، یک رفتار موردی از همان نوع فرآیند عمومی تر Y است. شما در شرایطی از این استفاده می کنید که سیستم تان تعدادی فرآیند use case دارد که همگی دارای تعدادی subtaskهای مشترک هستند، اما هر کدام چیز متفاوتی دارد که دسته بندی همه آنها به یک use case را برای شما غیر ممکن می کند.

مثال: فرض کنید می خواهید جزییاتی را به دیاگرامی که در زیر نشان داده شده، بیافزایید که یک سیستم رزرو بلیط هواپیما را نشان می دهد. چیزی که شما می خواهید نشان دهید این است که همه صندلی های هواپیما دقیقاً شبیه هم نیستند (بعضی ها کنار پنجره و بعضی ها کنار راهرو هستند)، و بعضی اوقات مسافران یکی از این نوع صندلی ها را ترجیح می دهند، البته همیشه نمی توان این انتخاب آنان را سریعاً برآورده کرد، زیرا ممکن است صندلی ای که آنها می خواهند، در دسترس نباشد. بنابراین، فرآیند تخصیص دادن یک صندلی کنار پنجره، مستلزم چک کردن "دردسترس بودن" صندلی های کنار پنجره است، در حالیکه، فرآیند تخصیص دادن یک صندلی کنار راهرو، مستلزم چک کردن "دردسترس بودن" صندلی های کنار راهرو است. اما گرچه این فرآیندها متفاوت هستند، اما از جهاتی نیز شبیه هم هستند، پس نادیده گرفتن شباهت هایشان، بی معنی است. خوشبختانه، UML، اجازه داشتن هر دو را به ما می دهد: می نویسیم که تخصیص این دو نوع صندلی، فرآیندهای متفاوتی هستند، اما در both processes extend a common, more general process (تخصیص صندلی ها)، شبیه هم هستند.

فرق بین useها و extendها چیست؟

احتمالاً بهترین راه فکر کردن درمورد عناصر دیاگرام به ترتیب زیر است:

-"X uses Y" نشان می دهد که تسک "X"، دارای یک زیر تسک "Y" است، بدین معنی که در فرآیند تکمیل تسک "X"، تسک "Y" حداقل یکبار تکمیل می شود.

-"X extends Y" نشان می دهد که "X"، یک تسک از همان نوع "Y" است، اما "X"، یک مورد ویژه و معین تر برای انجام "Y" است. بدین معنی که، انجام دادن X بسیار شبیه انجام دادن Y است، اما X دارای فرآیندهای کمی اضافی تر است که فراتر از چیزهایی است که باید جهت تکمیل Y انجام داد.

مثال نشان می دهد که به منظور انجام موفقیت آمیز "Check-in"، شما باید "Weigh luggage" و "Assign a seat" رلا چندین بار انجام دهید. گرچه کلید این کار این است که همه UCDهایی که توسط یک use case استفاده می شود، باید قبل از اینکه آن use case تکمیل شود، انجام شوند. وقتی متوجه شوید که چندین نوع تخصیص صندلی وجود دارد، شاید وسوسه شوید یک دیاگرام با استفاده لبه های uses، مانند نمونه بالایی، ترسیم کنید، اما این کار بی معنی است. این دیاگرام می گوید که به منظور تخصیص دادن یک صندلی، شما باید هم یک صندلی کنار پنجره و هم یک صندلی کنار راهرو به مسافر تخصیص دهید. اما اصلاً نترسید، رابطه extends، به خوبی این موقعیت را منترل می کند. با استفاده از رابطه extends، (همانگونه که در دیاگرام زیر نشان داده شده)، می توان گفت که دو راه برای تخصیص یک صندلی وجود دارد: تخصیص یک صندلی کنار پنجره، و تخصیص یک یک صندلی کنار راهرو، اما در فرآیند تخصیص مسافر یا صندلی، فقط یکی باید تکمیل شود.

سناریویی که من می خواهم توصیف کنم، به چند حالت ممکن تقسیم می شود، یا چندین error دارد. چگونه می توانم آن را با Use Case Diagrams نشان دهم؟

نشان دادن عدم موفقیت و حالت های مختلف، اغلب با یک دیاگرام Sequence یا flow chart، بهتر انجام می شود، اما موارد grey-area وجود دارد که معلوم نیست آیا یک Use Case Diagram مناسب است یا خیر. یک قانون: اگر در نمایش اعمال branching در Use Case Diagram، مجبور به استفاده از نمادهای use case بیشتری شوید، و دیاگرام بدست آمده نامشخص یا گیج کننده باشد، از یک سبک diagramming دیگر استفاده کنید.

با توجه به گفته بالا، نشان دادن رفتار ساده branching با UCDها امکان پذیر است، گرچه دوباره تاکید می کنم که UCDها، FLOW CHART نیستند. این کار از طریق تشخیص اینکه آیا use case، یا فرآیندی که سعی می کنید نمایش دهید، می تواند دو حالت مختلف داشته باشد (مثلاً شکست یا موفقیت)، آنگاه بدین معنی خواهد بود که شما واقعاً در use case متفاوت دارید: یکی که در آن، فرآیند موفقیت آمیز است، و دیگری که در آن، فرآیند شکست می خورد. البته، این دو use case، در اینکه هر دو extensionهای Use case اصلی هستند، مرتبط هستند، در نتیجه، شما use case اصلی را با Branching که از آن extend شده، ترسیم می کنید.من این را تقریباً سواستفاده از معنی لبه extends می دانم، زیرا واقعاً د ر اینجا برای نمایش طبقه بندی use case استفاده نمی شود (که هدفش است). دوباره می گویم، از این تکنیک به ندرت استفاده کنید، زیر ا خیلی زود می تواند یک دیاگرام را غیرقابل خواندن بکند.

مثال: فرض کنید می خواهید use case یک CD Player نرمال را نمایش دهید. وقتی همه چیز خوب است، CD player، سینی را که CD روی آن قرار می گیرد را به داخل می کشد، آن را می خواند، و پخش CD را شروع می کند (use case رفتار، د رزیر نشان داده شده). متاسفانه، برخی کاربران، هنگامی که هیچ CD در سینی وجود ندارد، فرمان play به سیستم می دهند. بنابراین، فرمان انجام نمی شود، و سیستم مجبور است کار دیگری غیر از play کردن CD انجام دهد (مثلاً به کاربر بگوید یک CD قراردهد). برای نشان دادن این، ما دیاگرام نرمال را با چند use case اضافی تغییر می دهیم، که در آن وجود CD تایید می شود. رفتار play کردن CD، رفتار تایید اینکه وجود CD را extend می کند. مورد مخصوص دیگر تایید وجود CD، این است که این کار انجام می شود در حالی که CD وجود ندارد، پس به کاربر گفته می شود تا یک CD قرار دهد.

Use case diagrams موارد زیر را نشان می دهد:

• Use caseها: یک use case، ترتیب اعمالی را که چیزی از valueی قابل اندازه گیری را برای یک actor فراهم می کند، و به عنوان یک بیضی افقی رسم می شود، توصیف می کند.

Actorها: یک actor، یک شخص، سازمان، یا سیستم خارجی است که در یک یا چند تعامل با سیستم شما نقشی دارد. Actorها به صورت نمادآدمک ترسیم می شوند.

• Associationها: رابطه بین actorها و use caseها، در دیاگرام use case، توسط خطوط توپر نشان داده می شوند. هر جا که actor درگیر تعاملی است که توسط یک use case، توصیف شده است، رابطه ای وجود دارد. Associationها به صورت خطوطی که use caseها و actorها را با یک فلش (arrowhead) روی یکی از خطوط به هم وصل می کنند، مدل سازی می شوند.اغلب از سرنیزه برای نشان دادن جهت فراخوانی اولیه رابطه، یا برای نشان دادن actor ابتدایی درون use case استفاده می شود. نوک نیزه ها معمولاً با data flow اشتباه گرفته می شود.
• جهبه دربرگیرنده سیتم (اختیاری): می توان یک مستطیل دور use caseها رسم کرد، که system boundary box نامیده می شود، تا گستره سیستم شما را نشان دهد. هر چیزی درون box نشانگر عملکردی است که در دید است و هرچیزی بیرون از box اینگونه نیست. Boxهای محدوده سیستم بندرت استفاده می شوند، گرچه من در بعضی موارد از آنها جهت تشخیص اینکه کدام use caseها در هر release عمده از سیستم تحویل داده می شوند، استفاده کرده ام. شکل شماره 2، چگونگی انجام این را نشان می دهد.
• بسته ها (اختیاری): بسته ها (packages) ساختارهای UMLیی هستند که شما را قادر به طبقه بندی عناصر مدل (از قبیل use caseها) به صورت گروهایی می کند. بسته ها به صورت file folders نشان داده می شوند و می توان آنها را در هر دیاگرام UML، شامل دیاگرام use case و کلاس دیاگرام، استفاده کرد. من از بسته ها، فقط زمانی استفاده می کنم که دیاگرام های من سنگین می شوند - یعنی اینکه روی یک صفحه چاپ نمی شوند - و نمی توان یک دیاگرام بزرگ را به دیاگرام های کوچک تر طبقه بندی کرد. شکل 3، نشان می دهد چگونه می توان شکل 1 را با بسته ها صبقه بندی کرد.

در مثالی که در شکل 1 نشان داده شده است، دانش آموزان با کمک مسئولین مربوطه در حال ثبت نام هستند. استادها در حال وارد کردن نمره هایی هستند که دانش آموزان در تکالیفشان بدست آورده اند، و مسئولین ثبت نام، کارنامه های دانش آموزان را نیز توزیع می کنند. دقت کنید که چگونه بعضی از use caseها درگیر چند actor هستند. به این موضوع نیز دقت داشته باشید که چگونه بعضی از associationها دارای arrowhead هستند- هر use case association معین، یک arrowhead صفر یا یک خواهد داشت. رابطه (association) بین دانش آموز و ثبت نام در seminar (شکل 4) نشان می دهد که این use case ابتداً توسط یک دانش آموز فراخوانی می شود نه مسئول ثبت نام (actor مسئول ثبت نام نیز در این use case درگیر است). فهم اینکه associationها، جریان های اطلاعات را نشان نمی دهند مهم است؛ آنها صرفاً actorیی را نشان می دهند که تا حدودی درگیر یک use case هستند. اطلاعات بین actor و use case رد و بدل می شود، مثلاً، دانش آموزان باید نشان بدهند قصد ثبت نام در کدام seminar را دارند، و سیستم باید به دانش آموزان نشان دهد ایا آنها ثبت نام شده اند یا خیر. اما، دیاگرام های use case، این نوع اطلاعات را مدل سازی نمی کنند. جریان اطلاعات را می توان با استفاده از UML activity diagrams مدل سازی کرد. خط بین Enroll در Seminar use case وactor registrar هیچ arrowheadیی ندارد، که نشان می دهد معلوم نیست تعامل بین سیستم و مسئولین ثبت نام چگونه شروع می شود. ممکن است یک مسئول ثبت نام متوجه شود دانش آموزی نیاز به کمک دارد و او را کمک کند، در حالیکه، در مواقعی ممکن است خود دانش آموز از مسئول ثبت نام تقاضای کمک کند، اطلاعات مهمی که در توصیف use case، مستند می شود.

Actorها همیشه با حداقل یک use case درگیر هستند، و همیشه روی لبه های بیرونی دیاگرام use case رسم می شوند.

شکل شماره 1: سیستم دیاگرام use case

شکل شماره 2: استفاده از System boundary boxes جهت نشان دادن releaseها

شکل شماره 3: اعمال packageها جهت ساده کردن دیاگرامهای use case

ایجاد دیاگرام های use case

دوست دارم تا آنجا که ممکن است، actorهای زیادی را معرفی کنم. شما باید بپرسید actorها چگونه با سیستم در تعامل است تا مجموعه ای از use caseهای ابتدایی را معرفی کند. سپس، روی دیاگرام، actorها را به use caseهایی که با آنها درگیر هستند، متصل می کنید. اگر یک actor اطلاعاتی را فراهم کند، use case را راه بیاندازد، یا اطلاعاتی رابه عنوان خروجی use case دریافت کند، آنگاه باید ارتباطی بین آنها وجود داشته باشد. من معمولاً arrowheadها را وارد خطوط ارتباط (association lines) نمی کنم زیرا تجربه من نشان می دهد که افراد آنها را با نشانه های جریان اطلاعات (information flow) اشتباه می گیرند، نه با فراخوانی اولیه.

پاراگراف قبلی، سبکی را که من معمولاً برای مدل سازی use case استفاده می کنم توصیف می کند، یعنی روش " ابتدا actorها". دیگران دوست دارند با معرفی یک actor و use caseهایی که با ابتدا با آن درگیر هستن شروع کنند و مدل را از آنجا تکمیل کنند. هر دو روش جواب می دهد. نکته مهم این است که افراد مختلف، از روش های مختلف استفاده می کنند، پس باید وقتی که از روش Model With Others تبعیت می کنید، انعطاف پذیر باشید.

فرصتهای استفاده مجدد

شکل چهار، سه نوع ربطه (extendها، includeها، و inheritance) بین use caseها را نشان می دهد. من دوست دارم روابط extend را معادل یک "hardware interrupt" در نطر بگیرم زیرا شما نمی دانید کی یا آیا extending use case، فراخوانده خواهد شد؛ و روابط Include را معادا یک "فرآیند فراخوانی" در نظر بگیرم؛ Inheritance، به همان روش UML class diagrams اعمال می شود. این مقاله، Reuse in Use Case Models، این سه رابطه را با جزییات بیشتر توضیح می د هد.

شکل 4: استفاده مجد د از use case.

Agile باقیمانده

چگونه می توان use case modeling agile را نگه داشت؟ ابتدا، سعی کنید تا آنجا که ممکن است آنرا ساده نگه دارید. از ابزارهای ساده و انعطاف پذیر برای مدل سازی با آن استفاده کنید. من معمولاً دیاگرامهای use case را روی یک وایت برد ایجاد می کنم، همانطور که در شکل 5 می بینید. شکل 5، مثالی از یک دیاگرام ابتدایی است که من با stakeholderهای پروژه ام رسم کرده ام. AM به ما می گوید که محتوا مهم تر از ظاهر (representation) است، پس رسم کردن دیاگرام با دست، مسئله بزرگی نیست. در ضمن، مهم نیست که دیاگرام کامل نیست، زیرا یک دانشگاه دارای بخشهای بیشتری است که در اینجا نشان داده شده، و همیشه می توان در صورت نیاز، دیاگرام را تغییر داد.

شکل 5: طرح وایت برد

همزمان با ایجاد طرح، من شرح مختصری از هر use case روی یک وایت برد نیز می نویسم. هدف من ثبت اطلاعات کافی در مورد use case است،؛ به طوری که کلاً متوجه شویم درباره چیست. اگر به جزییات بیشتری نیاز داشته باشیم، همیشه می توانیم بعداً آنها را اضافه کنیم، چه به صورت یک essential/business use case یا یک system use case.