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

در قسمت قبل و در این لینک ما به طراحی Class diagram موجودیت کارمند پرداختیم و سایر موجودیت ها و روابط بین آنها به عنوان تمرین به خود شما واگذار شد.

قبلا و در این لینک به طور مفصل به طراحی نمودار use case پرداخته ایم.

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

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

نمودار use case باید ساده باشد و فقط شامل چند شکل باشد. اگر سیستم شما بیش از مثلا 20 ، use case دارد، احتمالاً در مسیر اشتباهی از مدلسازی سیستم خود در استفاده از نمودار usecase هستید.

خوب در سیستم مدیریت منابع انسانی فرضی ما بازیگر(Actor) ها چه کسانی هستند ؟

*کسی که با use case (عملکرد سیستم) تعامل دارد.
*بازیگر نقشی را در business(کسب و کار مورد نظر/محیط عملیاتی مورد نظر ما) ایفا می کند.
*بازیگر بر روی use case ها اثر می گذارد.
*بازیگر نسبت به سیستم (ورودی ها) مسئولیت دارد و Actor انتظاراتی از سیستم (خروجی ها) دارد.

• در اینجا یک بازیگر می تواند متصدی ثبت اطلاعات کارمندان(User) باشد(از پرسنل منابع انسانی).
• یک بازیگر می تواند از کارمندان شعبه بوده درخواست ثبت، تغییر اطلاعات و .... را داشته باشد.
• یک بازیگر می تواند از مدیران بانک بوده و می خواهد از اطلاعات گزارشگیری نماید.

در این سیستم بازیگران در واقع همه کارمندان بانک (Bank Employee) هستند اما با نقش های متفاوت.

بعد از آن که بازیگران شما شناسایی شدند، می توان سوالات زیر را برای شناسایی use caseها پرسید :

• بازیگر چه کارکردهایی از سیستم می خواهد؟
• آیا سیستم اطلاعات را ذخیره می کند؟ چه بازیگرانی این اطلاعات را ایجاد، مي خوانند، به روز رسانی یا حذف خواهند کرد؟
• آیا سیستم نیاز به اطلاع یک بازیگر از تغییرات در وضعیت داخلی دارد؟
• آیا رویدادهای خارجی وجود دارد که سیستم باید درباره آن بداند؟
• چه بازیگری سیستم را از آن اتفاقات آگاه می کند؟

نکات

• همیشه نمودار use case را از دیدگاه بازیگران سازماندهی کنید.
• نمودارهاي use case باید ساده و در بالاترین نمای ممکن شروع شوند. تنها در این صورت است که می توان آنها را اصلاح و تفصیل داد.
• نمودارهای use case بر اساس عملکرد هستند و بنابراین باید بر روی "چه" تمرکز کنند نه "چگونه".

یک نمای بسیار ساده از نمودار use case !!! فراموش نکنید نمودارهاي use case باید ساده و در بالاترین نمای ممکن شروع شوند. تنها در این صورت است که می توان آنها را اصلاح و تفصیل داد.

توجه کنید این طراحی سطح بالا بارها و بارها اصلاح می شود تا تصویری کامل و کاربردی از سیستم به دست آید.

اما همانطور که در قسمت اول تنها به ترسیم class diagram موجودیت کارمند پرداختیم در این جا هم تنها به بررسی برخی از use Case ها و actor ها پرداختیم. به نظر شما چه مواردی دیگری می توانند وجود داشته باشد.

مواردی که مثلا با بازیگری بنام System Admin تعامل خواهد داشت ؟ مثلا مدیریت اطلاعات شعب و ... که بعنوان تمرین به شما واگذار می شود.

سوال : چه روابطی دیگری می توانست در نمودار بالا گنجانده شود؟

• Generalization of a Use Case/Generalization of an Actor
• Include Relationship
• Extend Relationship

سوال : برای این سیستم چند ماژول یا Boundary of system می توان متصور بود؟

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

بیشتر بخوانید : نقشه راه توسعه دهندگان Asp.NET Core