خواندن ۵ دقیقه·۲ سال پیش

طراحي و توليد نرم افزار HR با Asp.Net Core - قسمت اول

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

نوع پروژه بايد مشخص شود يک Web Application يا يک Web Site؟
برای UXی که قصد دارید به کاربر خود ارائه دهید Web UI بايد مشخص شود(CSR،SSR،SSG) ؟
الگوی معماری بايد مشخص شود Multi-layer، multi-tiered يا Domain Oriented Architecture ؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ویژگی ها (Attributes) :

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

BirthCertificate(Owned Entity type) Class Diagram

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