بررسی سیستم کتابخانه [بایگانی]

Future

یک شنبه 24 شهریور 1387, 13:53 عصر

سلام دوستان؛ من یه use case diagram که مربوط به یه سیستم کتابخانه می باشد را با power desigh طراحی کردم و از طرفی چون خیلی مبتدی هستم ممنون میشم اگه یکی از دوستان اینو یه نگاه کنه و بگه آیا مشکلی هست یا نه؟

با تشکر

Elham_gh

سه شنبه 26 شهریور 1387, 08:19 صبح

دوست عزيز مي تونيد از نمدارهاتون print screen بگيريد و تصويرشو اينجا بذاريد. (لازم نباشه power designer نصب كنيم) ممنون.

Future

سه شنبه 26 شهریور 1387, 11:57 صبح

سلام دوست عزیز، راستش من تازه شروع بکار کردم . و دارم مرحله مرحله جلو میرم و این فقط use case diagram می باشد ممنون میشم اگه بگید درسته یا غلط؟

anahitanaragh

سه شنبه 26 شهریور 1387, 16:14 عصر

سلام دوستم
با چیزی که اینجا گذاشتین .نشان دادین که در واقع هیچ کاری نکردی .
بهتره برای اینکار یه کم زحمت بکشی و کارهای دیگه را هم انجام بدی
برای مثال برو سراغ رشنال رز فکر می کنم بیشتر به کارت بیاد.

Elham_gh

چهارشنبه 27 شهریور 1387, 08:29 صبح

سلام دوستم
برو سراغ رشنال رز فکر می کنم بیشتر به کارت بیاد.
دوست عزيزTools تاثيري در طراحي شما نداره.در اين حد و اندازه هر tools ي قابل استفاده است. در جزئيات هست كه با هم فرق دارند

Future

چهارشنبه 27 شهریور 1387, 14:27 عصر

سلام دوست عزیز، این اطلاعات مربوط به سیستم کتابخانه می باشد که من در نظر گرفتم. به نظر شما آیا این نموادر Use case Diagram ی که تهیه کردم کامله یا خیر؟

با تشکر

این یک سیستم کتابخانه می باشد که دارای چندین شعبه در سطح شهر است . افراد با دسترسی های مختلف در گروه های مجزا و در جاهای مختلف از آن استفاده می کنند. اعضاء می توانند کتاب را در هر شعبه ای تحویل دهند و یا تاریخ آنرا تمدید کنند. سیستم می بایست بگونه ای باشد که وضعیت هر کتاب را در زمان گزارشگیری مشخص کند. بعنوان مثال از هر کتاب چند جلد و در کدام شعبه ها موجود می باشد و در حال حاضر وضعیت کتاب چه می باشد(چند جلد امانت داده شده و چند جلد باقی مانده و...)
کسانی که به نحوی با این سیستم در ارتباط هستند عبارتند :
1.مدیران ارشد: امکان هر گونه تغییر و تحولی در اطلاعات، اعم از خواندن، نوشتن، حذف، ویرایش و گزارشگیری را دارا می باشند. اعضاء این گروه می توانند مجوز دسترسی به سطوح مختلف را برای کاربران صادر کنند و بعبارت کلی هیچ نوع محدودیتی در این گروه وجود ندارد. مدیران ارشد از طریق سیستمی که در مرکز می باشد کلیه کارها را اداره می کنند.
2.مدیران گروه: کلیه مجوزهایی که توسط مدیران ارشد به آنها اعمال می شود را اجرا می کنند.
3.پرسنل: ثبت نام اعضاء، آپدیت کردن کتابخانه که شامل درج اطلاعات کتاب و ... می باشد را عهده دار می باشند.
4.اعضاء: افرادی که عضو کتابخانه می شوند می توانند کتاب را در هر شعبه ای تحویل دهند و یا تاریخ آنرا تمدید کنند.

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

Elham_gh

چهارشنبه 27 شهریور 1387, 15:05 عصر

سلام دوست عزیز، این اطلاعات مربوط به سیستم کتابخانه می باشد که من در نظر گرفتم. به نظر شما آیا این نموادر Use case Diagram ی که تهیه کردم کامله یا خیر؟

با تشکر

این یک سیستم کتابخانه می باشد که دارای چندین شعبه در سطح شهر است . افراد با دسترسی های مختلف در گروه های مجزا و در جاهای مختلف از آن استفاده می کنند. اعضاء می توانند کتاب را در هر شعبه ای تحویل دهند و یا تاریخ آنرا تمدید کنند. سیستم می بایست بگونه ای باشد که وضعیت هر کتاب را در زمان گزارشگیری مشخص کند. بعنوان مثال از هر کتاب چند جلد و در کدام شعبه ها موجود می باشد و در حال حاضر وضعیت کتاب چه می باشد(چند جلد امانت داده شده و چند جلد باقی مانده و...)
کسانی که به نحوی با این سیستم در ارتباط هستند عبارتند :
1.مدیران ارشد: امکان هر گونه تغییر و تحولی در اطلاعات، اعم از خواندن، نوشتن، حذف، ویرایش و گزارشگیری را دارا می باشند. اعضاء این گروه می توانند مجوز دسترسی به سطوح مختلف را برای کاربران صادر کنند و بعبارت کلی هیچ نوع محدودیتی در این گروه وجود ندارد. مدیران ارشد از طریق سیستمی که در مرکز می باشد کلیه کارها را اداره می کنند.
2.مدیران گروه: کلیه مجوزهایی که توسط مدیران ارشد به آنها اعمال می شود را اجرا می کنند.
3.پرسنل: ثبت نام اعضاء، آپدیت کردن کتابخانه که شامل درج اطلاعات کتاب و ... می باشد را عهده دار می باشند.
4.اعضاء: افرادی که عضو کتابخانه می شوند می توانند کتاب را در هر شعبه ای تحویل دهند و یا تاریخ آنرا تمدید کنند.

با تشکر فراوان
دوست عزيز ،
براي مدل كردن Problem Space بايد به صورت زير تشريح كني:
Actor ها:

1-مدير ارشد
2-مدير گروه
3-كتابدار
4-پرسنل
5- عضو كتابخانه
6-ارباب رجوع
7-......

Use Case هاي هر Actor:
1-عضو كتابخانه:
1-1-درخواست تمديد عضويت
1-2-جستجو كتاب
1-3-امانت كتاب
1-4-.....

2-ارباب رجوع
2-1- درخواست عضويت
2-2-جستجوي منابع
2-3-.......

3-.......

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

Future

چهارشنبه 03 مهر 1387, 08:15 صبح

سلام دوستان،
اين خيلي روش عاليه من چيزهايي را كه مي خواستم خوب بررسي كردم و به اين نتيجه رسيدم؛ممنون ميشم اگه بگيد براي اولين قدم آيا درست انجام داده ام يانه؟ آيا لسيت كارها همان Usecase براي Actor ها مي باشند؟
1. مدير ارشد:
• تعيين حق دسترسي به سطوح مختلف
• تعيين مجوزهاي لازم براي كاربران(خواندن،نوشتن،حذف و ويرايش)
• تهيه پشتيبان و Restore كردن اطلاعات
• انجام كليه گزارشگيري ها
• تعريف پرسنل
• امكان هر گونه تغيير و تحول در اطلاعات
2. مديران گروه:
• تعريف پرسنل
• گزارشگيري
• تهيه پشتيبان
• تعيين مجوزها براي كاربران در حيطه خود
• تعيين حق دسترسي به كاربران در حيطه خود
3. كتابدار:
• Updateكردن اطلاعات مربوط به كتابها و ساير اعضاء از قبيل نام ،آدرس و ...
• تحويل كتاب از عضو
• تمديد كتاب براي عضو
• رزرو كتاب براي عضو
• فرستاندن پيغام به اعضاء در صورت تاخير در برگرداندن كتاب
• تهيه پشتيبان
• گزارشگيري(وضعيت فعلي كتاب، موجودي كتاب)
• رسيدگي به وصعيت ارباب رجوع(آيا امكان ثبت نام مي باشد و ...)
4. عضو كتابخانه:
• امانت كتاب
• تمديد كتاب(در هر شعبه اي كه مي خواهند)
• رزرو كتاب (در هر شعبه اي كه ميخواهند)
• برگرداندن كتاب(فقط به شعبه اي كه از آن تحويل گرفته اند)
• پرداخت جريمه در صورت تاخير در برگرداندن يا خدشه دار كردن كتاب
• جستجوي كتاب(چه در محل و چه در خانه از طريق اينترنت و پيدا كردن منبع مورد نظر و محل)
5. ارباب رجوع:
• درخواست عضويت
6. پرسنل:

Elham_gh

چهارشنبه 03 مهر 1387, 08:39 صبح

بسيار عالي.
بله كتابدار و كاربر ارشد ...... Actor هاي شما هستند . و كاراهايي كه انجام مي دهند همان Use case ها هستند.

Future

پنج شنبه 04 مهر 1387, 20:34 عصر

سلام دوستان، خيلي خيلي ممنون از راهنمايي تون. مرحله بعد پياده سازي كلاس دياگرا مي باشد يعني بايد كليه رابطه هاي و متغير ها و نوعشان در اين مرحله تعيين شوند. به نظر شما براي اين مرحله بايد چه كرد؟ ممنون ميشم اگه يه مقداري توضيح بدهيد.

با تشكر

Elham_gh

شنبه 06 مهر 1387, 09:41 صبح

سلام دوستان، خيلي خيلي ممنون از راهنمايي تون. مرحله بعد پياده سازي كلاس دياگرا مي باشد يعني بايد كليه رابطه هاي و متغير ها و نوعشان در اين مرحله تعيين شوند. به نظر شما براي اين مرحله بايد چه كرد؟ ممنون ميشم اگه يه مقداري توضيح بدهيد.

با تشكر

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

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

Future

شنبه 13 مهر 1387, 06:21 صبح

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

Elham_gh

شنبه 13 مهر 1387, 09:07 صبح

من اولين سناريو شما رو اصلاح كردم. بقيه را هم به همين شيوه اصلاح كنيد(در ضميمه)

البته يه اشكال ديگه كار شما داشت، همانطور كه گفتم ، هر Use Case حداقل يك سناريو دارد. از بين سناريوهاي يك Use case يكي از آنها Basic Path يا Primary Path است و بقيه Alternate Path هستند. بايد اينو براي هر سناريو مشخص كنيد كه Basic Path است يا Alternate Path.
مرحله بعد اينه كه براي هر Basic Path يك Sequence Diagram و بقيه Alternate Path ها رو هم با يك Activity Diagram نشان دهيد(البته بعضي براي تمام سنايو ها Sequence مي كشن-اما من اين كارو نمي كنم!!)

Future

یک شنبه 14 مهر 1387, 06:54 صبح

سلام دوستان
متوچه شدم منظورتون از سناريو قبلي كدوم هست. من دارم اصلاحش مي كنم و با وقتي همه را نوشتم مجددا آنرا براي اطلاح نهايي مي زارم
خيلي ممنون

Elham_gh

چهارشنبه 17 مهر 1387, 08:02 صبح

دوست عزيز ممنون ميشم اگه بگيد كدام قسمت را اصلاح كرديد يا با يه مشخصه خاص آو نرا نمايش دهيد منظورم با يه رنگ ديگه.

خيلي ممنون از لطفتون

من فایل شما و اصلاحی رو پاک کردم. ابن دو فایل رو مقایسه کنید. تغییرات واضحه. اولین سناریو!

odiseh

سه شنبه 28 آبان 1387, 08:56 صبح

بسيار عالي.
بله كتابدار و كاربر ارشد ...... Actor هاي شما هستند . و كاراهايي كه انجام مي دهند همان Use case ها هستند.

دوست من،
آیا افرادی که طبق فاز شناخت در پست قبلی، با این سیستم کار می کنند یعنی کتابدار و کاربر ارشد، مدیران گروه و پرسنل ، همگی جزء Businnes Worker حساب نمی شوند؟
من فکر کنم تنها افرادی که عضو کتابخانه هستند تا کتاب به امانت ببرند، آنها Actor محسوب می شوند.

ضمنا من دقیقا متوجه مدیران گروه نشدم؟ فرق این ها با مدیران ارشد چیه؟

Elham_gh

سه شنبه 28 آبان 1387, 10:05 صبح

دوست من،
آیا افرادی که طبق فاز شناخت در پست قبلی، با این سیستم کار می کنند یعنی کتابدار و کاربر ارشد، مدیران گروه و پرسنل ، همگی جزء Businnes Worker حساب نمی شوند؟
من فکر کنم تنها افرادی که عضو کتابخانه هستند تا کتاب به امانت ببرند، آنها Actor محسوب می شوند.

ضمنا من دقیقا متوجه مدیران گروه نشدم؟ فرق این ها با مدیران ارشد چیه؟

دوست من Businnes Worker فقط یک streotype است واسه Actor اینکه میگیم اینها Actor هستند Businnes Worker اونها رو نقض نمی کنه.

دوستمون در دسته بندیشون 2 تا دسته مدیر دارند که به نظر درست هم هست. مدیر ارشد در حقیقت مثل Application Administrator است که کارهای مدیریتی سیستمی را انجام می ده. این شخص لزومی نداره از گردش و قوانین سیستم چیزی بدونه.که البته Businnes Worker هم نیست.اما اون یکی مدیر کارهای مدیریتی انجام میده , مثل کارهایی که ذکر شد و به تبع Businnes Worker است

odiseh

سه شنبه 28 آبان 1387, 10:26 صبح

مدیر ارشد در حقیقت مثل Application Administrator است که کارهای مدیریتی سیستمی را انجام می ده. این شخص لزومی نداره از گردش و قوانین سیستم چیزی بدونه.که البته Businnes Worker هم نیست.اما اون یکی مدیر کارهای مدیریتی انجام میده , مثل کارهایی که ذکر شد و به تبع Businnes Worker است

مطابق نظر شما اگه B.Worker نیست ، پس چیه ؟ من فکر نمی کنم Actor باشه. Actor فقط
اعضاء کتابخانه هستند . درسته؟

Future

شنبه 02 آذر 1387, 06:29 صبح

سلام دوستان
منظور من از مدير ارشد همان Administrator هست يا شخصي كه تمامي اعضا در هر شعبه را مي تواند كنترل كند. اين شخص مي تونه به تمام جزئيات از تمام نقاط ئنيا دسترسي داشته باشه ولي مديران گروه فقط مي تونند اعضاء خودشون رو كنترل كنند. يعني هر گروه يه مدير داخلي داره كه اجازه تعيير و تحول به كاربران را ميده و كسي كه اين مديران را كنترل مي كنه همون مدير ارشد مي باشد.
فكر كنم تمام اعضا كه به نحوي با اين سيستم كار مي كنند طبق راهنمايي هاي خانم Elham_GH همان Actor ها مي باشند.
در ضمن دوستان من سناريو را كامل نوشتم. مي خواستم بدونم مرحله بعدي چيه؟

با تشكر

Elham_gh

شنبه 02 آذر 1387, 15:58 عصر

مطابق نظر شما اگه B.Worker نیست ، پس چیه ؟ من فکر نمی کنم Actor باشه. Actor فقط
اعضاء کتابخانه هستند . درسته؟

بله .Actor است

odiseh

یک شنبه 03 آذر 1387, 10:17 صبح

با تشکر از elham_gh
میشه لطفا Actor ها و B.Worker ها رو جمع بندی و دسته بندی کنید...(با توجه به سناریو و فاز شناخت)

Future

پنج شنبه 07 آذر 1387, 14:51 عصر

سلام دوستان،
من سناريو را تمام كردم حالا نمي دانم مرحله بعدي چيه هست. ممنون ميشم اگه بگيد بايد در مرحله بعد چكار كنم.

Elham_gh

یک شنبه 10 آذر 1387, 07:57 صبح

با تشکر از elham_gh
میشه لطفا Actor ها و B.Worker ها رو جمع بندی و دسته بندی کنید...(با توجه به سناریو و فاز شناخت)
دوست عزيز، من يك مقدار جزئيات فراموشم شده و دوباره بايد مطالعه كنم صورت مسئله رو كه جوابتون رو بدم. علت طولاني شدن جواب شما هم همين بود و متاسفانه هنوز فرصتش نشده. سعي مي كنم تو اين يكي دو روز حتما اين تفكيك رو بگم. اما گمانم دوستمون Future كه سناريو نويسيشون تمام شده هم بتونن جواب اين سئوال رو بدن

Elham_gh

یک شنبه 10 آذر 1387, 08:00 صبح

سلام دوستان،
من سناريو را تمام كردم حالا نمي دانم مرحله بعدي چيه هست. ممنون ميشم اگه بگيد بايد در مرحله بعد چكار كنم.
مرحله بعدي مدل كردن سناريو هاست.
حالا تو approch وجود دارد:
1.Basic Path تون رو با Sequence Diagram مدل كنيد و ساير Alternate Path هاتون رو در يك Activity Diagram.( كاري كه من خودم مي كنم)(مگز اينكه در اين Alternate Path نكاتي وجود داشته باشد كه حتما بايد بهشون پرداخته شه، در اينصورت از روش 2 استفاده مي شه)
2. براي هر سناريو يك Sequence Diagram رسم كنيد.( اين كار سختيه و اعمال تغييراتش سخت تر:گیج:)

Future

دوشنبه 11 آذر 1387, 12:15 عصر

سلام دوستان،خيلي خيلي ممنون از لطفتون كه جواب داديد. راستش 2 تا سوال برام پيش اومده

1) منظور از اينكه در Alternate Path نكاتي وجود داشته باشد كه حتما بايد بهشون پرداخته شه يعني چه؟ ميشه يه مثال بگيد؟
2)براي هر سناريو يك Sequence Diagram رسم كنيد. اين كار سختيه و اعمال تغييراتش سخت تره يعني چي؟ ممنون ميشم اگه يكم واضح تر توضيح بديد.
3)در روش اول آيا بايد براي هرbasic Path در هر سناريو يه sequence diagram داشته باشيم؟

با تشكر از لطفتون

Elham_gh

چهارشنبه 13 آذر 1387, 11:52 صبح

با تشکر از elham_gh
میشه لطفا Actor ها و B.Worker ها رو جمع بندی و دسته بندی کنید...(با توجه به سناریو و فاز شناخت)

Business worker ها(که البته خود نوعیActor هستند):
كتابدار
کارمند کتابخانه
صحاف
مخزن دار
مسئول کتابخانه
....

Actor ها:
ارباب رجوع
عضو
مدیر سیستم
کاربر ارشد
سایر کتابخانه ها
سازمانهای اهدا کننده
سازمانهای گیرنده

Future

چهارشنبه 13 آذر 1387, 12:31 عصر

سلام دوستان،خيلي خيلي ممنون از لطفتون كه جواب داديد. راستش 2 تا سوال برام پيش اومده

1) منظور از اينكه در Alternate Path نكاتي وجود داشته باشد كه حتما بايد بهشون پرداخته شه يعني چه؟ ميشه يه مثال بگيد؟
2)براي هر سناريو يك Sequence Diagram رسم كنيد. اين كار سختيه و اعمال تغييراتش سخت تره يعني چي؟ ممنون ميشم اگه يكم واضح تر توضيح بديد.
3)در روش اول آيا بايد براي هرbasic Path در هر سناريو يه sequence diagram داشته باشيم؟

با تشكر از لطفتون

Elham_gh

چهارشنبه 13 آذر 1387, 13:50 عصر

سلام دوستان،خيلي خيلي ممنون از لطفتون كه جواب داديد. راستش 2 تا سوال برام پيش اومده

1) منظور از اينكه در Alternate Path نكاتي وجود داشته باشد كه حتما بايد بهشون پرداخته شه يعني چه؟ ميشه يه مثال بگيد؟
2)براي هر سناريو يك Sequence Diagram رسم كنيد. اين كار سختيه و اعمال تغييراتش سخت تره يعني چي؟ ممنون ميشم اگه يكم واضح تر توضيح بديد.
3)در روش اول آيا بايد براي هرbasic Path در هر سناريو يه sequence diagram داشته باشيم؟

با تشكر از لطفتون

:لبخندساده: خوب یعنی همه مطلبو توضیح بدم.
قبلا گفتم هر use case حداقل یک سناریو دارد . یکی از سناریو ها اصلی و بقیه فرعی هستند. خوب باید این سناریوها رو مدل کرد.
در Sequence Diagram ی که برای Basic Path رسم می شه,کلاسهایی که از اونها Instance گرفته می شه, تغریبا در بقیه سناریو ها همینه , اگر غیر این باشه باید برای هر سناریو متفاوت , Sequence Diagram ش رو رسم کنید. و یا کنترل وloop یکه حتما باید در جریان نمودار به اون پرداخته بشه.

حالا اگر برای هر سناریوی یک use case یک Sequence Diagram رسم بشه .اگر در روند کار use case تغییری بدید باید تک تک این Sequence Diagram ها رو تغییر بدید.

نمی دونم در مورد سئوال 3 چی رو متوجه نشدید

Future

چهارشنبه 13 آذر 1387, 15:30 عصر

خيلي خيلي ممنون
دقيقا متوجه شدم كه بايد چكار كنم تو اين مرحله

odiseh

یک شنبه 17 آذر 1387, 09:19 صبح

Business worker ها(که البته خود نوعیActor هستند):
كتابدار
کارمند کتابخانه
صحاف
مخزن دار
مسئول کتابخانه
....

Actor ها:
ارباب رجوع
عضو
مدیر سیستم
کاربر ارشد
سایر کتابخانه ها
سازمانهای اهدا کننده
سازمانهای گیرنده
سلام و تشکر از شما
خوب به این ترتیب با توجه به فاز شناخت و صورت مساله Actor ها شناسایی شده اند و حالا نوبت به شناسایی UseCase ها رسیده است.
برای شناسایی U.C ها هم دوباره باید به صورت مساله و فاز شناخت رجوع کرد. من سعی می کنم در پست بعدی اونا رو لیست کنم. خوشحال می شم اگه شما وبقیه دوستان هم نظر بدین یا چنانچه مشکلی داشت اعلام کنین.

Future

یک شنبه 17 آذر 1387, 15:44 عصر

سلام
خيلي عاليه دوست عزيز. من در حال پياده سازي فاز بعدي هستم. يعني تعيين Class Diagram براي هر UseCase به محض تموم شدن اطلاع ميدم تا اساتيد تصحيحش كنن. از همكاري شما و ساير اساتيد صميمانه ممنون

Elham_gh

یک شنبه 17 آذر 1387, 15:53 عصر

سلام
خيلي عاليه دوست عزيز. من در حال پياده سازي فاز بعدي هستم. يعني تعيين Class Diagram براي هر UseCase به محض تموم شدن اطلاع ميدم تا اساتيد تصحيحش كنن. از همكاري شما و ساير اساتيد صميمانه ممنون

دوست عزیز مقاله زیر در روند کارتون خیلی کمکتون خواهد کرد:
تله هاي استفاده از UML در RUP (http://barnamenevis.org/forum/showthread.php?t=111969)

Elham_gh

دوشنبه 02 دی 1387, 14:17 عصر

دوستان odiseh و... از ادامه کار منصرف شدین؟

Future

دوشنبه 02 دی 1387, 15:02 عصر

سلام دوستان

نه از ادامه كار منصرف نشديم فقط 1 2 روز وقت مي خوام . از همه مهمتر خيلي خيلي ممنون به خاطر توجه تون
خيلي خيلي ممنون

Future

سه شنبه 03 دی 1387, 14:58 عصر

سلام به همگي

خلاصه بعد از كلي بررسي و جستجو تونستم Diagram Use Case برنامه را ترسيم كنم. مي دونم اين تا زه اول راه براي من مبتدي هست و از اساتيد خواهشمندم مشكلات من را بگن. من چند تا سوا تو اين قسمت برام پيش اومد.

1) Administrator: شخصي هست كه مي تونه به تمام برنامه از تمام نقاط دسترسي داشته باشه و همه را كنترل كنه
2)Managers: هر كتابخانه براي خودش مدير خودس را داره كه فقط مي تونه اعضاي خودش را كنترل كنه.

حالا اين سوا برام پيش اومد براي رسم دياگرام اين دوتا بايد چكار كرد. اين قسمت يكم من و گيج كرد.

سوال بعدي اينكه بعضي مواقع شرط بوجود مي ياد. كجا بايد اين شرط ها را نشون داد. آيا در Use case Diagram يا در يه دياگرام جداگانه.

در ضمن من فايلهاي ضميمه رو فرستادم. ممنون ميشم اگه يه نگاهي بياندازيد و بگيد كجاي كار اشتباه هست.
من وقتي در محيط Rational Rose گزينه check model را انتخاب مي كنم همش خطا ميده. يعني تمام برنامم اشتباه است.

با تشكر

Elham_gh

سه شنبه 03 دی 1387, 15:55 عصر

دوست عزیز Future
شاید خیلیها, از جمله من, رو دستگاهشون rational نداشته باشن,میشه لطفا تصویر نمودارتو بذاری؟

راستی دوستان ما tools داریم مثلا به اسم rational viewer ؟

Future

سه شنبه 03 دی 1387, 16:46 عصر

سلام
راستش من هر چي سعي مي كنم نمي تونم عكس بگيرم. آخه توي يه صفحه جا نميشه و بعضي قسمتها هم نياز به توضيح دارن كه من همه را در فايلم توضيح دادم
من سعي خودم را ميكنم تا به طريقي عكس بگير
خيلي خيلي ممنون

Future

چهارشنبه 04 دی 1387, 11:57 صبح

سلام اساتيد

من نتونستم هنوزاز كل دياگرامم عكس بگيره. ميشه اون مدل رو برام چك كنيد؟
خيلي لازمش دارم

Elham_gh

چهارشنبه 04 دی 1387, 12:56 عصر

سلام اساتيد

من نتونستم هنوزاز كل دياگرامم عكس بگيره. ميشه اون مدل رو برام چك كنيد؟
خيلي لازمش دارم

شرمنده. من که نمی تونم.مگر دوستان دیگه نگاهی بندازن.

Future

پنج شنبه 05 دی 1387, 04:41 صبح

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

Future

جمعه 06 دی 1387, 04:34 صبح

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

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

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

Elham_gh

دوشنبه 09 دی 1387, 08:42 صبح

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 براتون می ذارم برای ایده گرفتن.
http://barnamenevis.org/forum/attachment.php?attachmentid=26954&stc=1&d=1230530435

Future

دوشنبه 09 دی 1387, 09:14 صبح

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

Elham_gh

دوشنبه 09 دی 1387, 09:42 صبح

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

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

Future

یک شنبه 06 بهمن 1387, 15:13 عصر

سلام به همه

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

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

Future

دوشنبه 14 بهمن 1387, 08:45 صبح

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

با تشکر

Elham_gh

دوشنبه 14 بهمن 1387, 10:03 صبح

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

با تشکر

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

Future

دوشنبه 14 بهمن 1387, 12:40 عصر

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

Elham_gh

دوشنبه 14 بهمن 1387, 15:05 عصر

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

Future

سه شنبه 15 بهمن 1387, 05:38 صبح

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

Elham_gh

شنبه 19 بهمن 1387, 15:54 عصر

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

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

Future

جمعه 25 بهمن 1387, 10:23 صبح

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

ehsan_296

یک شنبه 23 فروردین 1388, 22:12 عصر

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

http://chafiye.ir (http://chafiye.ir/)

keyvan_n

یک شنبه 27 اردیبهشت 1388, 19:06 عصر

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

zahra_k

شنبه 02 خرداد 1388, 00:26 صبح

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

Elham_gh

شنبه 02 خرداد 1388, 09:36 صبح

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

zahra_k

یک شنبه 03 خرداد 1388, 00:38 صبح

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

aspnet_22

یک شنبه 10 خرداد 1388, 17:56 عصر

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

دوشنبه 11 خرداد 1388, 09:05 صبح

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

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

aspnet_22

سه شنبه 12 خرداد 1388, 14:47 عصر

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

Elham_gh

چهارشنبه 13 خرداد 1388, 08:47 صبح

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

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

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

aspnet_22

سه شنبه 02 تیر 1388, 16:11 عصر

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

جمعه 06 آبان 1390, 17:52 عصر

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

ariyayi69

جمعه 22 اردیبهشت 1391, 19:46 عصر

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

mamoor

جمعه 10 شهریور 1391, 11:15 صبح

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

یاس 111

سه شنبه 30 آبان 1391, 18:14 عصر

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

babak2014

دوشنبه 12 آبان 1393, 20:26 عصر

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