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

  • نوع پروژه باید مشخص شود یک برنامه وب یا یک وب سایت؟
  • برای UXی که قصد دارید به کاربر خود را ارائه دهید Web UI باید مشخص شود(CSR،SSR ،SSG) ؟
  • الگوی معماری باید مشخص شود چند لایه، چند لایه یا معماری دامنه گرا ؟

پاسخ ها مشخص می شود ما برای توسعه یک نرم افزار مدیریت منابع انسانی با یک Web Application روبرو بوده ایم و برای UXی که قصد داریم به کاربر خود ارائه دهیم، CSR را به عنوان Web UI انتخاب کنیم و فریم ورک Blazor را برای آن ارائه دهیم و در نهایت از آن استفاده کنیم. معماری Domain Oriented و ویژگی DDD را برگزیدیم.

اما آیا باید به سرعت به توسعه نرم افزار خود برویم؟ برای این نوع پروژه پاسخ خیر است! ادامه مقدماتی وجود دارد.

هر چه یک سیستم پیچیده تر باشد، نمایش بصری آن بیشتر است. فرآیند ترسیم اجزاء، مشخص می‌کند که چه چیزی در کجا کار می‌کند، چه چیزی نیست، و کجا فرصت‌هایی برای بهبود وجود دارد. و از یک زبان مشترک، مانند کاربردهای UML، به تیم کمک می کند تا در این مسائل همکاری کنند.

معماران، مهندسان نرم افزار و سیستم توسعه دهندگان نرم افزار می بایست فهم صحیحی از نمودارهای UML داشته باشند تا با یک زبان مشترک با سایر اعضای تیم همکاری داشته باشند.

سه مورد از محبوب ترین های UML بیشتر نیازهای مدل سازی شما را پوشش می دهند. 14 نوع مختلف UML برای مدل‌سازی برنامه‌ها وجود دارد، اما در عمل، توسعه‌دهندگان تنها از تعداد کمی برای سیستم‌های مستندسازی نرم‌افزاری خود استفاده می‌کنند. رایج ترین نمودارهای UML که می بینید و استفاده می کنید، نمودارهای کلاس(نمودار کلاس)، نمودارهای توالی(نمودار توالی) و نمودارهای use case هستند. این معناست که دانستن ایجاد و خواندن تنها 20 درصد از این زبان برای اکثر پروژه های شما کافی است.قبلا و در این لینک تنها به همان 20 درصد یعنی موارد نیاز به توسعه نرم افزار پرداخت شده است.

در این پست ما نمودارهای کلاس(class diagrams) را برای پروژه خود با اهداف زیر ترسیم نمود.

  • تجزیه و تحلیل و طراحی برنامه استاتیکی.
  • شرح وظایف سیستم
  • مهندسی مستقیم(رو به جلو) و معکوس.(مهندسی جلو و معکوس)

در مهندسی نرم افزار، کلاس در زبان مدل سازی یکپارچه (UML) نوعی ساختار ساختاری است که ساختار یک سیستم را با نشان دادن کلاس های سیستم، ویژگی ها(attributes)، عملیات (methods) و روابط بین اشیاء و همچنین محدودیت های اعمال می کند. شده بر سیستم را توصیف می کند.
نمودار کلاس ستون فقرات ساختار مدل سازی شی گرا است. برای مدل‌سازی مفهومی کلی برنامه‌ریزی و تبدیل مدل‌ها به کد برنامه‌نویسی می‌شود. نمودارهای کلاس نیز می توانند برای مدل سازی داده ها استفاده شوند.

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

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

مجموعه ای از نقشه های کلاس کل سیستم را نشان می دهد.

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

اما ما قصد توسعه سیستم مدیریت منابع انسانی را داریم برای چه محیطی عملیاتی در نظر داریم؟

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

خوب به نظر اولین موجودیتی که در این محیط عملیاتی با آن مواجه می شود که کارمند می باشد.

هنگام رسم علامت کلاس نکات زیر را باید به خاطر بسپارید:
*نام نمودار کلاس باید برای توصیف آن از سیستم معنی دار باشد.
*هر عنصر و روابط باید از قبل مشخص شود.
*مسئولیت (ویژگی ها و روش ها) هر کلاس باید به وضوح مشخص شود.
*برای هر کلاس، تعداد حداقل مشخصه ها باید مشخص شود، زیرا ویژگی های غیر ضروری، پیچیده می کند.
*هر زماني كه لازم است براي توصيف برخي از جنبه هاي تاريخي از يادداشت ها استفاده شود. در پایان ترسیم باید برای توسعه دهنده/کدنویس قابل درک باشد.
*در نهایت، از ساختن نسخه نهایی، طرح بر روی کاغذ ساده ترسیم شود و تا آنجا که ممکن است دوباره بر روی آن کار شود تا تصویر بهتری درست شود.

نمودار کلاس کارمند (ریشه جمعی).
نمودار کلاس کارمند (ریشه جمعی).

قبلا و در دو پست در خصوصی مفاهیم Entities, Value Objects, Aggregates and Roots و پیاده سازی آن صحبت کردیم.

ویژگی ها (ویژگی ها):

ویژگی birthCertificate یک Owned type حاوی شناسنامه ای کارمند می باشد(اطلاعات شناسنامه بیشتر شبیه یک ویژگی پیچیده است تا یک نوع اولیه مانند string، bool، و غیره)

نمودار کلاسی گواهی تولد (نوع نهاد متعلقه).
نمودار کلاسی گواهی تولد (نوع نهاد متعلقه).

توجه داشته باشید birthCertificate در اینجا یک نوع یا بهتر بگوییم Owned Entity Types است و بمنظور می خوانید class diagram و در نهایت کدی که تولید خواهد شد در نظر گرفته شده است و تاثیر مثبتی نیز برای نگهداری کد خواهد داشت. را در آینده بهمراه خواهد داشت؟

نمودار کلاس استخدام (نوع نهاد مالکیت).
نمودار کلاس استخدام (نوع نهاد مالکیت).
نمودار کلاس آموزش (موجود کودک).
نمودار کلاس آموزش (موجود کودک).
نمودار کلاس آدرس (فرزند).
نمودار کلاس آدرس (فرزند).

خوب اما کارمند تنها موجودیت ما در این پروژه نیست !

  • شعب(محل های خدمت)
  • پست های سازمانی(چارت سازمانی)
  • و…

روابط بین Aggregateها و … آن را تمرین می کنم به خود شما پیشنهاد می کنم.


یک سوال؟ آیا باید آدرس را به عنوان یک شی ارزش در نظر می گیریم؟

اما سوالی دیگر آیا ایرادی درنمودارهای فوق یا تعاریف مربوط به آن احساس می کنید؟

به نظر شما با تغییر کدام موارد به مدل بهتری دست یافتنی؟

در قسمت بعد که لینک آن همیجا منتشر خواهد شد به سراغ استفاده از case diagrams رفت.

بیشتر بخوانید: طراحي و توليد نرم افزار HR با Asp.Net Core – مقدمه
بیشتر بخوانید : نقشه راه توسعه دهندگان Asp.NET Core

اگر دوست داشتی امتیاز دادن یادت نره!