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

[Future]

سلام دوستان،
بالاخره من تونستم يه عكس تهيه كنم ولي در 2 قسمت هست. ممنون ميشم اگه مشكلاتش را بگيد. مي خواستم ببينم لايه ها رو كجا بايد بكار برد. منظور از لايه چي هست.

1) ممنون ميشم اگه اساتيد بگن كه آيا Include & Exclude ها درست اعمال شدن.
2) چطوري بايد لايه ها رو پياده سازي كرد.

خيلي خيلي ممنون

[Elham_gh]

Use case های Receive Document و Reply به نظر درست نیستند. همینطور send_document , Recive _Publication , Recive , Return .
شما چند اصل رو باید رعایت کنید.
یکی اسم گذاری use case است. که این use case ها هیچ کدوم اسم گذاری درستی ندارند.مثلا Search اصلا واضح نیست روی چی این جستجو انجام می شه.
دوم اینکه هر آنچیزی use case می شه که یک فرآیند و سناریو داشته باشه. Receive Document یا نمونه هایی که بالا گفتم هر کدوم یک فعلند اما سناریو یی ندارند.

اشکال بعدی که به چشم می خوره , اگر فرض بر این بگیریم که use case ی به نام Recive _Publication درست باشد, جهت فلش به سمت actor خواهد بود. از این نمونه اشکال هم در نمودار شما چند تا هست.
یک اشکال دیگه جهت رابطه های Extend و Include است. اگر فرض کنیم که 2 تا use case داشته باشیم به نامهای A و B اگر B , Extend شده A باشد. جهت از B به A است و اگر B , Include شده A باشد, جهت از A به B می باشد.
(من دیگه شکل2 رو ندیدم)
من یک نمونه use case Diagram براتون می ذارم برای ایده گرفتن.

[Future]

خيلي خيلي ممنون.
من راستش مبتدي هستم و تازه شروع كردم . منتظره نمونه use case diagram شما هستم
با تشكر

[Elham_gh]

خيلي خيلي ممنون.
من راستش مبتدي هستم و تازه شروع كردم . منتظره نمونه use case diagram شما هستم
با تشكر

د! گذاشتم که! به این بزرگی!

[Future]

سلام به همه


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

يعني چي؟ پس بايد چطوري usecase را شناخت.
ممنون ميشم اگه توضيح بيشتري بديد

[Future]

سلام دوستان؛
من نسخه قبلی را تصحیح کردم و فکر کنم متوجه اشتباهاتم در نسخه قبلی شده ام. من ویرایش شده آنرا می گذارم. ممنون میشم اگه اساتید لطف کنن و آنرا مجدداً بررسی کنن.

با تشکر

[Elham_gh]

سلام دوستان؛
من نسخه قبلی را تصحیح کردم و فکر کنم متوجه اشتباهاتم در نسخه قبلی شده ام. من ویرایش شده آنرا می گذارم. ممنون میشم اگه اساتید لطف کنن و آنرا مجدداً بررسی کنن.

با تشکر

كجا گذاشتينش؟!

[Future]

نمی دونم چه شده. بفرمائید ایندفعه امیدوارم درست باشه

[Elham_gh]

دوست عزيز
مشكل بارزي كه در مدل شما وجود داشت ، اين بود كه شما 2 تا Actor داشتيد كه هر كدام Use case خود را داشتند و بين usecase ها رابطه include بر قرار بود(اگه اشتباه نكنم، چون به سختي از تصوير فابل word تون تشخيص دادم). اين غلط است.Use case ي كه Include شده براي use case ديگريست را Actor ي نمي تواند مستقيما انجام دهد. مگر اينكه نوع رابطه extend باشد.
من براي راهنمايي شما يك قسمت از مدل يك سيستم رو براتون ضميمه كردم كه با نحوه نگارش سناريو هم آشنا بشيد. هر چند فكر كنم قبلا هم نمونه بهتون داده بودم.
اين مستند چون اتوماتيك توسط EA ساخته شده ، مشكلات فارسي انگليسي ممكنه داشته باشه.
نكته ديگه اينكه فكر نكنيد تمام use case ها مثل اين مثال بايد فقط "نگهداري" باشد. اين مسئله اين مدل use case ها رو لازم داشته كه البته فراوانيش در سيستمهاي مختلف زياد است.

[Future]

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

[Elham_gh]

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

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

[Future]

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

[ehsan_296]

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

http://chafiye.ir

[keyvan_n]

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

[zahra_k]

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

[Elham_gh]

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

[zahra_k]

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

[aspnet_22]

نه دوست عزیز , تا اینجا شما فقط 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 رو توی یوزکیسهای دیگر و توالیهای متناظر با انها رسم کرده ایم .
مساله بعدی اینه که ما در نوشتن سناریوها چقدر باید ریز شویم مثلا ایا باید مراحل کنترل
رکوردهای تکراری و همچنین کار با دیتا بیس رو شرح بدیم .؟ چون به هر حال ما قراره که از روی یوز کیسها توالی رو رسم کنیم و توالی به کلاسهای کنترلی و دیتا اکسس اشاره میکند.؟

[Elham_gh]

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

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

[aspnet_22]

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

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

[Elham_gh]

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

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

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

[aspnet_22]

نه دوست عزیز , تا اینجا شما فقط 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 بنویسیم .؟؟؟

[mahdiyeh1]

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

[ariyayi69]

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

[mamoor]

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

[یاس 111]

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

[babak2014]

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