Printable View
چطور میشه usecaseهای یک سیستم رو شناسایی کرد؟
آیا محدوده خاصی مثل محدوده کاری یا وسعت کار یا غیره رو باید در نظر گرفت؟
تا چه حد باید جزییات رو در نظر گرفت؟ مثلا باید گزارشات یک سیستم رو بصورت یک usecse در نظر گرفت یا هر گزارش یک usecse است و یا عمل چاپ خودش میتونه usecase جدایی باشه؟
با سلام
دوست عزیز
من فکر می کنم اگر ابتدا actor های سیستم را تشخیص دهید بهتر می توانید پیش روید.
سپس تعیین کنید که هر actor چه فعالیتهایی باید انجام دهد از این طریق می توانید Use case ها را شناسایی کنید.
تمامی فعالیتها را لیست کنید بعد از آن می توانید use case را شناسایی کنید.
حتی فعالیـتهایی که منجر می شوند اطلاعاتی ذخیره شوند و
فعالیتهایی که اطلاعات ذخیره شده را تغییر می دهند را نیز در نظر بگیرید.
بعد از آن می توانید اطلاعات را دسته بندی کرده و Use Case های واقعی را تشخیص دهید.
مثلا در یک سیستم مکانیزه ثبت اطلاعات پایه، ویرایش اطلاعات پایه، حذف اطلاعات پایه و جستجو را در نظر بگیرید
پعد ازلیست کردن این فعالیتها می توانید Use Case به عنوان ورود اطلاعات پایه در نظر بگیرید که تمام این فعالیتها را پوشش می دهد.
سپس در سناریو Use case ها می توانید حذف، ویرایش جستجو را در نظر بگیرید
سلام
به نظرمن یک راه خوب برای تشخیص Use case ها نوشتن سناریو های کامل از روند business آن سیستم است وسپس با دسته بندی سناریو ها می توان به راحتی Functionality سیستم رو بدست آورد .
Use Case مجموعه از رویداد ها ، که وقتی یکActor، در سیستم پردازش کاملی را انجام می دهد رخ می دهد و به صورت نرمال به یک پردازش بزرک نسبت داده می شود و یک قدم منحصر به فرد یا پایان کار در یک سیستم نیست.
مشکلی که وجود داره در سیستمهای بزرگ با توجه به زیاد بودن یوزکیس ها در یک زیر سیستم گویایی نمودار کاهش پیدا می کنه و همیشه هم نمی شه یوزکیسها رو با هم دسته بندی کرد.
همون طور که دوستان گفتند شناسایی Usecase ها با شناسایی Actor ها رابطه مستقیم داره.
اگر شما Actor ها رو دقیق پیدا کنید اونوقت Usecase هاتون رو هم پیدا کردید.
برای پیدا کردن Actor ها می تونید از Context Diagram استفاده کنید. البته context diagram جزء نمودارهای UML نیست. اما کمک شایانی به پیدا کردن دقیق Usecase ها می کنه. پس از تشکیل Context Diagram در یک سطح انتزاع میشه گفت که هر External Entity که داره می تونه کاندیدایی برای Actor باشه. وقتی Actor پیدا شد پیدا کردن Usecase سادست. از اون چیزی که Actor نیاز داره میشه یه Usecase تشکیل بشه.
با این توضیح عمل گزارشگیری اگر نیازمندی یک Actor باشه ( که معمولا هست ) بنابراین می تونه یک Usecase باشه.
موفق باشید.
چطور میشه تو یک دیاگرام بزرگ یوزکیسها رو پکیج کرد با توجه به اینکه اکثرا با هم رابطه کاری ندارند.
فضولی نباشه ، میشه بپرسم چرا می خواید این کار و کنید؟نقل قول:
چطور میشه تو یک دیاگرام بزرگ یوزکیسها رو پکیج کرد با توجه به اینکه اکثرا با هم رابطه کاری ندارند.
با سلام
به نظر من بهترین راه برای تشخیص usecase ها اینه که اول از همه سناریوی سیستم را تحلیل کنید،یعنی اینکه بدانید هدف سیستم شما چیست و تمام کارهای آن را تحلیل کرده باشید، در این صورت با در نظر گرفتن تعریف usecaseمیتوانید به راحتی کلییه usecase هارا تشخیص دهید.
تعریف- به مجموعه عملیاتی می گویند که به صورت متوالی د ر سیستم انجام می شود و هدف خاصی را دنبال می کند.
موفق باشید.
من تعریفی که از usecase بلدم رو بگم شاید بتونه کمک کنه
مجموعه ای از عملیات که نتیجه آن ملموس باشد
برای چه کسی خوب معلومه برای actor های سیستم
راهههای شناخت ( نکات کنکوری )
1 - یک جمله فعلیه نشان دهنده usecase ماست
2 - اگه به feauture list سیستم نگاه کنیم بیشتر usecase ها رو اونجا میبینیم
3 -برای کاربر خارجی قابل رویت باشد
با سلام
به نظر من خوبه که یک سیستم رو که فکر می کنید می تونه قابل اجرا باشه پیشنهاد کنید تا اینکه در مورد اش بحث کنیم .یعنی خودمون مدل اش کنیم
با تشکر مرزبان
کار خوبیه ولی فکر کنم مدلینگ یک سیستم بزرگ از حوصله این فروم خارج باشه.نقل قول:
به نظر من خوبه که یک سیستم رو که فکر می کنید می تونه قابل اجرا باشه پیشنهاد کنید تا اینکه در مورد اش بحث کنیم .یعنی خودمون مدل اش کنیم
من پیشنهادم اینه که یک سیستم متوسط رو مدل کنیم مثل دبیرخانه. نظر شما چیه ؟
به نظر من خوبه .نقل قول:
نوشته شده توسط vahidAM
اگه کسی نظر دیگری داره لطفا بگه!
به نظر من هم تمرین و نمونه خیلی خوبی می تونه باشه
من یک نرم افزار دبیرخانه در اختیار دارم که بخشی از یک سیستم اتوماسیون اداری هستش فکر می کنم کمک شایانی در این مورد بکنه. ( یعنی جاهایی که آدم یه چیزی جا میندازه رو میشه پیدا کرد.
فکر می کنم که اگه در یک تایپک جدید با یک عنوان مناسب این مورد را ادامه بدیم خیلی بهتر باشه.
با این حال بهتره VahidAm عزیز که به قول دوستان فرمان رو تو دست بگیرید
با تشکر مرزبان
فرمایش شما کاملا صحیح و متینه. این هفته مشغله زیاد است انشاء ا.. از هفته آیندهنقل قول:
فکر می کنم که اگه در یک تایپک جدید با یک عنوان مناسب این مورد را ادامه بدیم خیلی بهتر باشه
ما کوچکتونیم. به روی چشم.نقل قول:
با این حال بهتره VahidAm عزیز که به قول دوستان فرمان رو تو دست بگیرید
در تحلیلی که دارم انجام میدم تعداد یوزکیسها خیلی زیاده و نمودار خیلی بزرگی میشهنقل قول:
نوشته شده توسط vahidAM
دوستان من هم جدیدا درگیر طراحی یک نرم افزار دبیرخانه و گردش مکاتبات بودم که خیلی هم خوب از کار در اومده و می تونم در مورد ویژگیها و امکانات یک سیستم دبیرخانه کمک کنم
لطفا بهتره که یکی فرمان رو بگیره و شروع کنه
بی صبرانه منتظرم
با تشکر مرزبان
سیستم انبار معمولی چطوره ؟؟؟
من دارم تو یک دوزه uml شرکت میکنم و پروژه عملیمون همینه
یا پروژه دبیرخونه و رد گیری نامه ها این رو هم دارم تجربه میکنم
اصلا چند تا مگه نظر داریم رای بگیریم
تو دبیرخانه چند تا کار اصلی وجود داره:
1- نامه وارده
2- نامه صادره
3- ارجاع نامه و گردش مکاتبات
4- نامه داخلی
5- طراحی فرم
6- جستجو
7- گزارشات
تاپیکی برای مدل سازی سیستم دبیرخانه زده شد
با تشکر از همراهی صمیمانه شما
سلام
من نمی دونم جوابی که به شما میدم چه قدر میتونه درست باشه !!اما میدونم که اگر شناخت شما از سیستم تا حدی روشن باشه و شما بتونید گردش کار اون سیستم رو به صورت حتی فرضی برای خودتون در نظر بگیری و رسم کنید شاید تا یه حدی بتونید actor ها که البته با توجه به صحبت دوستان رابطه مستقیمی با usecase داره رو شناسایی کنید.منم یه بار با مشکل شما توی یه سازمان دولتی خیلی سخت مواجه شدم و این کار رو انجام دادم روش تجربی خوبی بود تا حدی کمکم کرد.