بررسی سیستم کتابخانه

نقل قول:

---

نوشته شده توسط Future

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

---

شكل اول همون مشكل قبلي رو داره

سلام. راستش من خیلی مطالعه کردم ولی واقعا دیگه نمی دونم که جه مشکلش کجاست. ممنون میشم اگه بیشتر توضیح بدید. هر چند مدلی که که به من دادید را خیلی من بررسی کردم و حتی مدلهای دیگری را هم دیدم.
با تشکر

چرا ديگه ادامه نميديد؟؟؟؟؟
خيلي جالب بود.......

http://chafiye.ir

به نظر من هم خیلی جالب بود. اگه ادامه پیدا می کرد یک کلاس تمام عیار بود. واقعا حیف شد !!:ناراحت:

چرا دیگه این بحث رو ادامه ندادید؟
فکر میکنم به خیلی ها کمک کنه

خوب دوستمون Future بايد ادامه بده . اين سيستم اون بود

ما که تو این چند سال بیننده بودیم و فعالیتی نداشتیم نمیتونیم بهشون پیغام بدیم
شما که اینجا فعالیت دارید و خاک اینجا رو خوردید اگه میتونید یه جوری بهشون بگید بیان اینجا و مارو در جریان ادامه پروژه بزارن اینجوری به ما هم کمک کردید

نقل قول:

---

نوشته شده توسط Elham_gh

نه دوست عزیز , تا اینجا شما فقط actor ها و use case ها تعیین کردید. مرحله بعدی نوشتن سناریو است که بسیار بسیار هم مهم است.یعنی چی؟ به ازای هر use case شما قدم به قدم توضیح میدید که چطور انجام می شه.هر use case حداقل 1 سناریو دارد. اگر یکuse case بیش از یک سناریو داشت (که اغلب این طور است), یکی از سناریو ها اصلی و بقیه فرعی هستند. به اون سناریو اصلی Happy Day یا Basic Path هم می گویند.و به فرعی ها Alternate path می گویند. من 1 نمونه use case رو براتون مثال می یارم.
use case نگهداری اطلاعات اعضاء
اضافه کردن یک عضو جدید(Basic Path)
1.مسئول عضویت فرم اعضاء را انتخاب می کند.
2. سیستم اطلاات خلاصه کلیه ماربران را در یک لیست نشان می دهد
3.مسئول کلید "عضو جدید" را انتخاب می کند.
4. سیستم یک فرم خالی جهت ورود اطلاعات کاربر باز می کند.
5. مسئول اطلاعات عضو جدید را وارد فرم می کند و کلید "ثبت" را می زند.
6. سیستم اطلاعات ورودی را بررسی می کند که فرمت ورود اطلاعات درست باشد و اطلاعات تکراری نباشد(در اینجا بهتر است به جزء توضیح داده شود که کدام فیلدهای اطلاعاتی فرمتشان چک می شود و بر مبنای کدام اطلاعات چک می شود که اطلاعات تکراری نیست)
7. در صورت صحت اطلاعات و تکراری نبودن آن , سیستم اطلاعات عضو جدید را ثبت می کند.و یک شماره شناسایی خودکار به آن می دهد.
8. سیستم یک پیغام ضمنی به کاربر مسئول می دهد که" اطلاعات عضو جدید ثبت گردید"

اصلاح اطلاعات عضو (Alternate Path)
.....

حذف عضو(Alternate Path)
....

اطلاعات عضو تکراری است(Alternate Path)
.....

عضو مورد نظر پیدا نشد(Alternate Path)
.......


این نمونه سناریو عین سناریوهای پیشنهادی خود RUP است.

شما بعد این مرحله باز کلی کار دارید تا به مرحله طراحی کلاس برسید

---

مورد 6 در واقع اشاره به alternate use case ها دارد در رسم نمودار توالی ایا باید مورد 6 را با تمام جزئیات در نظر گرفت بالاخره ما مورد 6 رو توی یوزکیسهای دیگر و توالیهای متناظر با انها رسم کرده ایم .
مساله بعدی اینه که ما در نوشتن سناریوها چقدر باید ریز شویم مثلا ایا باید مراحل کنترل
رکوردهای تکراری و همچنین کار با دیتا بیس رو شرح بدیم .؟ چون به هر حال ما قراره که از روی یوز کیسها توالی رو رسم کنیم و توالی به کلاسهای کنترلی و دیتا اکسس اشاره میکند.؟

نقل قول:

---

نوشته شده توسط aspnet_22

مورد 6 در واقع اشاره به alternate use case ها دارد در رسم نمودار توالی ایا باید مورد 6 را با تمام جزئیات در نظر گرفت بالاخره ما مورد 6 رو توی یوزکیسهای دیگر و توالیهای متناظر با انها رسم کرده ایم .
مساله بعدی اینه که ما در نوشتن سناریوها چقدر باید ریز شویم مثلا ایا باید مراحل کنترل
رکوردهای تکراری و همچنین کار با دیتا بیس رو شرح بدیم .؟ چون به هر حال ما قراره که از روی یوز کیسها توالی رو رسم کنیم و توالی به کلاسهای کنترلی و دیتا اکسس اشاره میکند.؟

---

در sequence دیگرام هم لزومی به جزئی شدن نیست. اصلا توصیه می شود زیاد وارد جزئیات نشوید. اما اشاره به کنترل تکراری بودن بر اساس کدام فیلدها جزو جزئیات نیست.
در نوشتن سناریو ها هم نه خیلی کلی گویی ونه خیلی جزئی. سناریویی که من نوشتم از این لحاظ قابل قبوله

نقل قول:

---

نوشته شده توسط Elham_gh

در sequence دیگرام هم لزومی به جزئی شدن نیست. اصلا توصیه می شود زیاد وارد جزئیات نشوید. اما اشاره به کنترل تکراری بودن بر اساس کدام فیلدها جزو جزئیات نیست.
در نوشتن سناریو ها هم نه خیلی کلی گویی ونه خیلی جزئی. سناریویی که من نوشتم از این لحاظ قابل قبوله

---

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

نقل قول:

---

نوشته شده توسط aspnet_22

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

---

همانطور که می دونید هر usecase دارای یک سناریو اصلی و چند سناریویalternate است. معمولا سناریوی اصلی را با sequence diagaram نشون می دن و بقیه سناریوهایalternate را با یک activity diagram . اما نباید در این نمودارها جزئیات کم ارزش رو گنجوند.

جواب سئوال شمارو دادم؟

نقل قول:

---

نوشته شده توسط Elham_gh

نه دوست عزیز , تا اینجا شما فقط actor ها و use case ها تعیین کردید. مرحله بعدی نوشتن سناریو است که بسیار بسیار هم مهم است.یعنی چی؟ به ازای هر use case شما قدم به قدم توضیح میدید که چطور انجام می شه.هر use case حداقل 1 سناریو دارد. اگر یکuse case بیش از یک سناریو داشت (که اغلب این طور است), یکی از سناریو ها اصلی و بقیه فرعی هستند. به اون سناریو اصلی Happy Day یا Basic Path هم می گویند.و به فرعی ها Alternate path می گویند. من 1 نمونه use case رو براتون مثال می یارم.
use case نگهداری اطلاعات اعضاء
اضافه کردن یک عضو جدید(Basic Path)
1.مسئول عضویت فرم اعضاء را انتخاب می کند.
2. سیستم اطلاات خلاصه کلیه ماربران را در یک لیست نشان می دهد
3.مسئول کلید "عضو جدید" را انتخاب می کند.
4. سیستم یک فرم خالی جهت ورود اطلاعات کاربر باز می کند.
5. مسئول اطلاعات عضو جدید را وارد فرم می کند و کلید "ثبت" را می زند.
6. سیستم اطلاعات ورودی را بررسی می کند که فرمت ورود اطلاعات درست باشد و اطلاعات تکراری نباشد(در اینجا بهتر است به جزء توضیح داده شود که کدام فیلدهای اطلاعاتی فرمتشان چک می شود و بر مبنای کدام اطلاعات چک می شود که اطلاعات تکراری نیست)
7. در صورت صحت اطلاعات و تکراری نبودن آن , سیستم اطلاعات عضو جدید را ثبت می کند.و یک شماره شناسایی خودکار به آن می دهد.
8. سیستم یک پیغام ضمنی به کاربر مسئول می دهد که" اطلاعات عضو جدید ثبت گردید"

اصلاح اطلاعات عضو (Alternate Path)
.....

حذف عضو(Alternate Path)
....

اطلاعات عضو تکراری است(Alternate Path)
.....

عضو مورد نظر پیدا نشد(Alternate Path)
.......


این نمونه سناریو عین سناریوهای پیشنهادی خود RUP است.

شما بعد این مرحله باز کلی کار دارید تا به مرحله طراحی کلاس برسید

---

در حین رسم نمودارها در rational rose ایا باید یوز کیسهای فرعی را هم رسم کرد . ایا باید ارتباطی بین یوزکیسهای فرعی و اصل ان ایجاد کرد .
سوال 2 - شرح هر یوز کیس را در قسمت specification بنویسیم .؟؟؟

سلام می خواستم بدونم پروژه شما کامل شد؟
اگه کامل شد در صورت امکان پروژه کامل بزارین:خجالت:

سلام خسته نباشید میشه این بحث روادامه بدید اخه منم خیلی بهش نیازدارم

آقا سلام داریم لذت میبریم . لطفا ادامه.............................

با تشکر فراوان

سلام
میخواستم برنامه پروژه سیستم کتابخانه رو اینجا قرار بدید
درسم در مورد مهندسی نرم افزار هست