آموزش class diagram از صفر تا صد با 6 درس رایگان

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

نمودار کلاس (Class Diagram) چیست؟

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

رابطه‌

سه نوع رابطه اساسی مهم وجود دارند:

• اتحاد (Association) :نماینده روابطی بین وهله‌های انواع است (یک شخص که برای یک شرکت کار می‌کند، یک شرکت چند اداره دارد).
• وراثت (Inheritance) :بدیهی‌ترین افزودنی به نمودارهای ER برای استفاده در شیئ‌گرایی است. تناظر بی‌واسطه‌ای با وراثت در طراحی شیئ‌گرایی دارد.
• تجمیع (Aggregation) :شکلی از ترکیب‌بندی شیئ در طراحی شیئ‌گرا محسوب می‌شود.

کاربرد Class Diagram

• نمودار کلاس برای مدل سازی نمای استاتیک (static view) یک سیستم استفاده می شود.
• نمای ایستا واژگان سیستم را توصیف می کند.
• نمودار کلاس به عنوان پایه و اساس نمودارهای اجزا (component) و استقرار (deployment) در نظر گرفته می شود.
• نمودار کلاس به وضوح نگاشت با زبان های شی گرا مانند ++Java ، C و … را نشان می دهد،نمودار کلاس به طور کلی برای ساخت برنامه های کاربردی استفاده می شود.

اجزای یک کلاس

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

1- نام کلاس

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

2- لیست صفات یک کلاس

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

flightNumber : Integer

departureTime : date

flightDuration : minute

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

3- لیست عملیات کلاس

عملیات های مربوط به کلاس ها در قسمت سوم نمودارها است و البته این بخش اختیاری است. برای مستند سازی عملیات از شیوه نشانه گذاری زیر استفاده می کنیم :

name(parameter list) : type of value returned

در هنگام مستند سازی عملیات مربوط به تابع می توان از علائمی استفاده نمود مبنی بر اینکه پارامتر ورودی یا خروجی است. این علائم اختیاری “in” و “out” می باشند. بطور معمول از این علائم در UML استفاده نمی شود مگر آنکه زبان برنامه نویسی ما زبانی قدیمی مانند Fortran باشد که در این صورت این اطلاعات می تواند بسیار مفید باشد. از آنجایی که در زبان های C++ و Java پارامتر های یک تابع از نوع ورودی هستند، بسیاری از افراد در UML از آوردن علائم in و out صرف نظر می کنند. البته در صورت تمایل می توانید از آنها استفاده کنید.

دروس آموزشی کلاس دیاگرام

در کنار این مطلب حتما بخوانید: روش ساخت پاورپوینت چارت سازمانی (و نکات کاربردی)

• نحوه رسم نمودار کلاس class diagram در رشنال رز
• آموزش نمودار کلاس در UML
• مفهوم انواع نمودار های uml
• نحوه رسم ارتباطات در نمودارکلاس دیاگرام

در ادامه صفر تا صد ویزیو که برنامه مشابه و جایگزین بهتر کلاس دیاگرام است: دانلود آموزش صفر تا صد ویزیو

یکی دیگر از روابط مهم، Inheritance یا ارث‌بری است. ارث‌بری زمانی استفاده می‌شود که یک کلاس، ویژگی‌ها و رفتارهای کلی یک کلاس دیگر را به ارث ببرد. مثلاً اگر کلاس User داشته باشیم، می‌توانیم کلاس‌های Admin و Customer را از آن مشتق کنیم. در این حالت، User ویژگی‌های عمومی مثل name و email را دارد و کلاس‌های فرزند می‌توانند رفتارهای اختصاصی خودشان را اضافه کنند. استفاده درست از ارث‌بری باعث نظم در طراحی می‌شود، اما استفاده بیش از حد از آن می‌تواند سیستم را پیچیده کند.

رابطه مهم دیگر، Aggregation و Composition است. این دو رابطه برای نشان دادن رابطه «جزء و کل» استفاده می‌شوند. در Aggregation، یک کلاس می‌تواند شامل کلاس دیگر باشد، اما آن جزء بدون کل هم می‌تواند وجود داشته باشد. مثلاً یک Department می‌تواند چند Employee داشته باشد، اما کارمند مستقل از دپارتمان هم معنا دارد. در Composition رابطه قوی‌تر است؛ یعنی جزء بدون کل معمولاً معنا ندارد. مثلاً یک OrderItem معمولاً بدون Order وجود مستقلی ندارد.

مفهوم Multiplicity هم در Class Diagram بسیار کاربردی است. Multiplicity نشان می‌دهد چند شیء از یک کلاس می‌توانند با چند شیء از کلاس دیگر ارتباط داشته باشند. برای مثال، یک Customer می‌تواند چند Order داشته باشد، اما هر Order معمولاً متعلق به یک Customer است. این رابطه ممکن است با نشانه‌هایی مثل 1، 0..1، 1..* یا * نمایش داده شود. اگر Multiplicity درست مشخص نشود، ممکن است طراحی دیتابیس یا منطق برنامه دچار ابهام شود.

در Class Diagram، سطح دسترسی یا Visibility هم مهم است. معمولاً علامت + برای public، علامت - برای private و علامت # برای protected استفاده می‌شود. برای مثال، اگر یک ویژگی private باشد، یعنی نباید مستقیماً از بیرون کلاس تغییر کند. این موضوع با اصل Encapsulation یا کپسوله‌سازی ارتباط دارد. کپسوله‌سازی یعنی اطلاعات داخلی کلاس کنترل‌شده و منظم در دسترس قرار بگیرند، نه اینکه هر بخش از برنامه بتواند هر چیزی را مستقیم تغییر دهد.

یکی از کاربردهای مهم Class Diagram، کمک به طراحی شیءگرا است. وقتی قبل از کدنویسی کلاس‌ها، ویژگی‌ها، متدها و ارتباطات مشخص شوند، برنامه ساختارمندتر نوشته می‌شود. این کار مخصوصاً در پروژه‌های تیمی اهمیت دارد، چون همه اعضای تیم می‌توانند یک تصویر مشترک از ساختار سیستم داشته باشند. بدون Class Diagram، ممکن است هر برنامه‌نویس برداشت متفاوتی از سیستم داشته باشد و در نهایت کدها ناهماهنگ شوند.

اشتباه رایج مبتدی‌ها در رسم Class Diagram این است که نمودار را بیش از حد شلوغ می‌کنند. لازم نیست همه متدهای کوچک، همه متغیرهای داخلی و تمام جزئیات فنی در نمودار بیاید. یک Class Diagram خوب باید قابل خواندن باشد. اگر نمودار آن‌قدر پیچیده شود که کسی نتواند آن را سریع بفهمد، ارزش آموزشی و تحلیلی خود را از دست می‌دهد. بهتر است ابتدا کلاس‌های اصلی و روابط مهم رسم شوند و بعد در صورت نیاز، جزئیات اضافه شود.

اشتباه دیگر، تشخیص نادرست کلاس‌هاست. بعضی افراد هر اسم یا واژه‌ای را در سیستم به کلاس تبدیل می‌کنند، در حالی که همه چیز نباید کلاس باشد. معمولاً کلاس‌ها باید موجودیت‌های مهم، پایدار و دارای داده و رفتار باشند. مثلاً در سیستم کتابخانه، Book، Member و Loan کلاس‌های منطقی هستند، اما واژه‌هایی مثل Search یا Submit همیشه لزوماً کلاس نیستند و ممکن است فقط متد یا عملیات باشند.