برنامه ی هتل

[smokyshadow]

سلام دوستان
من می خوام برای پروژه دانشگاهی یه برنامه واسه هتل بنویسم...بعد مثلا این باید یه امکاناتی برای مشتری و یه امکاناتی برای کارمندا داشته باشه....تو بعضی امکاناتم مشترکن...بعد اولشم برای ورود باید وارد شی(یعنی یه صفحه ورود داره و کسایی که ثبت نام کردن می تونن وارد شن...بعد الان من دارم uml اشو طراحی می کنم...می خوام بدونم اینکه من یه کلاس پرسون بزارم که ابسترکت باشه و مشتری و کارمند اینو اکستند کنن کار خوبیه؟و اینکه برا register و loginشدن چی کار کنم ؟این دو تارم دو تا کلاس کنم؟(اگه قراره کلاسشون کنم نحوه استفاده ازشون تو کلاس مشتری و.. اینه که یه شی ازشون به عنوان propertyتو کلاس بزارم؟)یا نه ایندو رو تو خوده پرسون یه عنوان یه متد بزارم که وقتی login کنه یه boolean trueبرگردونه ؟
واقعا به کمک سبزتون نیازمندم:)

[vahid-p]

کاملا بستگی به طراح داره. ممکنه:
1- کل کاربرها رو به عنوان یک Person بدونه و با یک فیلد دسترسی هاشو مشخص کنه (معمولا در CMS های وب که با دیتابیس های رابطه ای مثل MySql طراحی میشن از این مورد استفاده می کنند).
2- یک کلاس Person داشته باشه برای کاربرها و یک کلاس Administrator ارث بری شده از اون برای دسترسی های بیشتر.
3- یک Customer و یک Administrator داشته باشه بدون هیچ ارتباطی.
4- یک Person باشه و Customer و Administrator ساب کلاس های اون باشن.

از اونجایی که هدف پروژتون آموزشیه، من ترجیح میدم از شی گرایی بیشتر استفاده بشه و مورد آخر رو انتخاب میکنم. دلیل اینکه چرا مورد آخر بهتر از مورد 2 است چون یه جا میخواید مثلا بگید اگر مثلا آبجکت member در شرط

if (member instance of Customer){
...
}else if(member instance of Administrator)
خب یکیشون اجرا میشه. ولی اگر از Person در حالت کلی و برای مدیرها Administrator به صورت ساب کلاس (روش 2) استفاده کنید، در چنین شروطی، همیشه if(member instance of Person) مقدار true خواهد داشت در صورتی که منظورتون فقط مشتری بوده نه مدیر. البته خب مشخصه با شرطهای بیشتر می تونید این رو هم متمایز کنید ولی آینده رو چی دیدید ممکنه تعداد ساب کلاس های بیشتر بشن و کار دشوارتر.

حالا که کاربرها رو در UML تون مشخص کردید لازمه Use case ها رو برای هر کدوم جداگونه بنویسید. مثلا لاگین کردن و ریجستر کردن هر دو رو بذارید برای Person. ارسال درخواست رو بذارید برای Customer. تایید درخواست رو بذارید برای Administrator. انتخاب مدیرهای دیگه رو بذارید در کلاس Administrator. پرداخت وجه رو بذارید برای Customer و...

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

اینها بیشتر به صورت مسئله و دیدگاه خودتون بستگی داره.

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

[aaligoli]

سلام دوستان
من می خوام برای پروژه دانشگاهی یه برنامه واسه هتل بنویسم...بعد مثلا این باید یه امکاناتی برای مشتری و یه امکاناتی برای کارمندا داشته باشه....تو بعضی امکاناتم مشترکن...بعد اولشم برای ورود باید وارد شی(یعنی یه صفحه ورود داره و کسایی که ثبت نام کردن می تونن وارد شن...بعد الان من دارم uml اشو طراحی می کنم...می خوام بدونم اینکه من یه کلاس پرسون بزارم که ابسترکت باشه و مشتری و کارمند اینو اکستند کنن کار خوبیه؟و اینکه برا register و loginشدن چی کار کنم ؟این دو تارم دو تا کلاس کنم؟(اگه قراره کلاسشون کنم نحوه استفاده ازشون تو کلاس مشتری و.. اینه که یه شی ازشون به عنوان propertyتو کلاس بزارم؟)یا نه ایندو رو تو خوده پرسون یه عنوان یه متد بزارم که وقتی login کنه یه boolean trueبرگردونه ؟
واقعا به کمک سبزتون نیازمندم:)

میشه سایت رو در یک شبکه لوکال ران کرد و هر کسی به وای فای متصل شد یا خواست بشه اون صفحه بیاد بالا و .. البته یک راهش هست.

[smokyshadow]

کاملا بستگی به طراح داره. ممکنه:
1- کل کاربرها رو به عنوان یک Person بدونه و با یک فیلد دسترسی هاشو مشخص کنه (معمولا در CMS های وب که با دیتابیس های رابطه ای مثل MySql طراحی میشن از این مورد استفاده می کنند).
2- یک کلاس Person داشته باشه برای کاربرها و یک کلاس Administrator ارث بری شده از اون برای دسترسی های بیشتر.
3- یک Customer و یک Administrator داشته باشه بدون هیچ ارتباطی.
4- یک Person باشه و Customer و Administrator ساب کلاس های اون باشن.

از اونجایی که هدف پروژتون آموزشیه، من ترجیح میدم از شی گرایی بیشتر استفاده بشه و مورد آخر رو انتخاب میکنم. دلیل اینکه چرا مورد آخر بهتر از مورد 2 است چون یه جا میخواید مثلا بگید اگر مثلا آبجکت member در شرط

if (member instance of Customer){
...
}else if(member instance of Administrator)
خب یکیشون اجرا میشه. ولی اگر از Person در حالت کلی و برای مدیرها Administrator به صورت ساب کلاس (روش 2) استفاده کنید، در چنین شروطی، همیشه if(member instance of Person) مقدار true خواهد داشت در صورتی که منظورتون فقط مشتری بوده نه مدیر. البته خب مشخصه با شرطهای بیشتر می تونید این رو هم متمایز کنید ولی آینده رو چی دیدید ممکنه تعداد ساب کلاس های بیشتر بشن و کار دشوارتر.

حالا که کاربرها رو در UML تون مشخص کردید لازمه Use case ها رو برای هر کدوم جداگونه بنویسید. مثلا لاگین کردن و ریجستر کردن هر دو رو بذارید برای Person. ارسال درخواست رو بذارید برای Customer. تایید درخواست رو بذارید برای Administrator. انتخاب مدیرهای دیگه رو بذارید در کلاس Administrator. پرداخت وجه رو بذارید برای Customer و...

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

اینها بیشتر به صورت مسئله و دیدگاه خودتون بستگی داره.

امیدوارم تونسته باشم راهنمایی کرده باشم، هر چند طراحی خیلی خوبی شاید بهتون پیشنهاد نداده باشم یا سوال شما رو دقیقا متوجه نشدم.
ممنون از راهنمایی جامع و کاملت داداش ...تمام ابهامام رفع شد:):قلب::قلب::قلب::قلب::تشویق: :تشویق::تشویق: