06-14-2013
|
|
مدیر بخش مکانیک - ویندوز و رفع اشکال
|
|
تاریخ عضویت: Sep 2009
نوشته ها: 2,586
سپاسها: : 5,427
6,159 سپاس در 1,794 نوشته ایشان در یکماه اخیر
|
|
شیءگرایی یعنی چه و تفکر شیءگرا چیست ؟
اگر دقت کنید که چگونه کارهای خود را در دنیای واقعی انجام میدهید، خواهید دید که در یک دنیای شیءگرا هستید. برای مثال، اگر میخواهید به فروشگاه بروید، با شیء اتومبیل کار دارید. شیء اتومبیل از اشیاء دیگری تشکیل شده است که با یکدیگر همکاری میکنند تا شما را به فروشگاه برسانند. شما سوییچ را در شیء قفل استارتر وارد میکنید و آن را میچرخانید. به این ترتیب یک پیام (از طریق سیگنال الکتریکی) به شیء استارتر ارسال میشود و متعاقب آن، این شیء با شیء موتور ارتباط برقرار میکند تا اتومبیل را روشن کند. به عنوان یک راننده شما از چگونگی همکاری این اشیاء بی خبر و ایزوله هستید. شما با چرخاندن سوییچ آغازگر یک سلسله از رخدادها هستید و فقط به انتظار پاسخ مینشینید.
به صورت مشابه کاربران برنامههای نرم افزاری از منطق و چگونگی انجام کارکردهای برنامه بی اطلاع هستند. برای مثال، وقتی که در نرم افزار واژه پرداز یک صفحه را پرینت میکنید، این کار را با کلیک روی کلید Print آغاز میکنید. شما از پردازشهای داخلی برای انجام عمل پرینت ایزوله هسیتد و تنها منتظر نتیجه چاپ مینشینید. در فرآیند پرینت، شیء دکمه Print در برنامه واژه پرداز با شیء پرینتر ارتباط برقرار میکند و این شیء نیز به پرینتر فیزیکی اطلاع میدهد که صفحه را چاپ کند.
برای آماده سازی صحنه جهت یادگیری برنامه نویسی شیءگرا ابتدا تاریخچه این سبک برنامه نویسی را مرور میکنیم و میبینیم که چرا تبدیل به مهمترین شیوه توسعه سیستمهای نرم افزاری شده است.
تاریخچه برنامه نویسی شیءگرا
برنامه نویسی شیءگرا یا به اختصار [۱]OOP یک روش تولید نرم افزار است که در آن ساختار نرم افزار بر پایه اشیای مرتبط با یکدیگر بنا نهاده شده است تا وظایف خواسته شده از نرم افزار را انجام دهند.
مفاهیم OOP از میانه دهه ۱۹۶۰ با زبان برنامه نویسی Simula معرفی شده و در دهه ۱۹۷۰ با زبان SmallTalk تکمیل شده است. در میانه دهه ۱۹۸۰ با زبانهای C++ و Eifle این شیوه برنامه نویسی دوباره متولد شد. OOP رشد خود را در دهه ۱۹۹۰ با ظهور زبان Java ادامه دارد. در سال ۲۰۰۲ شرکت مایکروسافت با انتشار .Net Framework یک زبان شیءگرا جدید با نام C# را معرفی کرد که تبدیل به پر استفاده ترین زبان برنامه نویسی توسعه دهندگان .Net شد.
[۱] Object Oriented Programming
چرا از OOP استفاده کنیم؟
دلیل اینکه برنامه نویسی شیءگرا برای حل مشکلات بیزنس[۱] تا این اندازه استفاده شده است چیست؟ در طول دهه ۱۹۷۰ تا ۱۹۸۰ زبانهای برنامه نویسی رویهگرا مانند C ، Pascal و Fortran برای توسعه سیستمهای نرم افزاری بیزنسی زیاد استفاده میشدند. زبانهای رویه گرا، برنامه را به سبک خطی سازماندهی کرده و به شیوه بالا به پایین[۲] اجرا میکردند. به عبارت دیگر، برنامه شامل یک سری گامها بود که یکی پس از دیگری اجرا میشد تا وظیفه خواسته شده انجام شود. این سبک برنامه نویسی برای برنامههای کوچک به خوبی کار میکرد ولی وقتی که برنامهها بزرگتر میشدند نگهداری و رفع خطای آنها به مراتب دشوار تر و پر هزینه تر میگشتند.
برای رفع مشکل بزرگ شدن اندازه برنامهها، برنامه نویسی ساخت یافته معرفی شد تا کدها را به بخشهای قابل مدیریتی به نام تابع یا رویه تقسیم کند. این یک بهبود بزرگ بود ولی در برنامههایی که از کارکردهای بیزنسی پیچیده برخوردار بودند، معایب زیر را ظهور کردند:
- نگهداری برنامه مشکل تر میشد.
- ویرایش کارکردهای موجود بدون تاثیر بر سایر کارکردها به سختی انجام میشد.
- برنامههای جدید مجددا از ابتدا ساخته میشدند و در نتیجه برگشت سرمایه کمی از تلاشهای قبلی حاصل میشد.
- ترجمه یا نگاشت مدل بیزنس به مدل برنامهای دشوار بود.
- با آنکه هر برنامه به صورت مجزا درست کار میکرد ولی در اتصال با سایر سیستمها به خوبی عمل نمیکرد.
علاوه بر معایب فوق، برخی از پیشرفتها در سیستمهای محاسباتی باعث شد تغییرات بیشتر در روش برنامه نویسی ساخت ضروری شود، مانند:
- کاربران میخواستند که به صورت حسی و شهودی با برنامه تعامل داشته باشند، نه به صورت ساختارمند مانند سیستم عامل DOS.
- سیستمهای کامیپوتری به مدلهای توزیع شده ارتقا یافتند جایی که منطق بیزنس، واسط کاربر و بانک اطلاعاتی از هم جدا بودند.
در نتیجه اکثر توسعه دهندگان نرم افزارها به متدولوژیها و زبانهای شیءگرا روی آورند تا این مشکلات را برطرف کنند. مزایای این کار عبارتند از:
- انتقال و ترجمه قابل درک تر مدلهای بیزنس به مدلهای نرم افزاری
- توانایی نگهداری کارآمدتر کد و اعمال تغییرات ساده تر
- توانایی کار تیمی بهتر برای توسعه سیستمهای نرم افزاری
- قابلیت استفاده مجدد از کد در برنامه های دیگر و به کارگیری کامپاننتهای تولید شده توسط دیگران
- قابلیت یکپارچه شدن با سیستمهای توزیع شده
- توانایی ایجاد واسط کاربر قابل لمستر برای کاربران
[۱] Busniess : منظور کسب و کاری است که برای آن نرم افزار ساخته میشود. در اینجا به جای کسب و کار از کلمه بیزنس استفاده میگردد.
[۲] Top-down
مشخصات OOP
در اینجا مفاهیم بنیادی و اصطلاحات مشترک همه زبانهای شیءگرا بیان میگردند. هدف این بخش آشنایی با این مفاهیم و ارتباط دادن آنها با تجربه برنامه نویسی است به طوری که بهتر بتوانید مسائل بیزنس را به کدهای شیءگرا تبدل نمایید.
اشیاء
همانطور که قبلا بیان شده، ما در دنیای شیءگرا زندگی میکنیم. شما خودتان یک شیء هستید و میتوانید با سایر اشیاء تعامل داشته باشید. در حقیقت شما شیء ایی هستید با دادههایی مانند قد، رنگ مو و غیره. شما همچنین دارای متدها یا رفتارهایی هستید که آنها را انجام میدهید یا بر شما انجام میشوند؛ مانند خوردن، قدم زدن و غیره.
بنابراین اشیاء چیستند؟ در OOP یک شیء ساختاری است برای یکپارچه کردن دادهها و عملیات مرتبط با آن داده ها. به عنوان مثال در برنامه انبار، شیء ایی به نام کالا داریم. این شیء شامل دادههایی چون کد، نام و موجودی است و عملیاتی که روی این دادهها انجام میشوند مانند ورود به انبار، خروج از انبار و تغییر نام کالا.
انتزاع
وقتی که با اشیاء سر و کار دارید، اغلب فقط به برخی از خصوصیات و رفتارهای آن نیاز دارید. بدون انتزاع کردن یا ***** کردن خصوصیات و رفتارهای نا مربوط اشیاء، برنامه نویسی شیء گرا دشوار میشود زیرا نیاز به پردازش حجم زیادی اطلاعات غیر ضروری خواهد بود.
با توجه به مفهوم انتزاع، وقتی دو فرد با یک شیء یکسان برخورد میکنند، ممکن است با زیر مجموعههای متفاوتی از خصوصیات آن شیء سروکار داشته باشند. به عنوان مثال وقتی که من رانندگی میکنم، لازم است که سرعت ماشین را بدانم و از مسیر حرکت خود اطلاع داشته باشم. مسلما لازم نیست که من از دور موتور ماشین اطلاعی داشته باشم، بنابراین این خصوصیت را کنار میگذارم. از سوی دیگر این اطلاعات برای یک راننده مسابقه حیاتی است و آن را بخشی از خصوصیات ماشین خود در نظر میگیرد.
هنگام ساخت اشیاء در برنامههای کاربردی OOP ، مهم است که مفهوم انتزاع را همیشه در نظر داشته باشیم. اگر شما دارید یک برنامه حمل و نقل مینویسید، یک شیء کالا خواهید داشت با خصوصیاتی مانند اندازه و وزن. در این برنامه خصوصیت رنگ برای کالا جزء اطلاعات بی ربط خواهد بود و کنار گذاشته میشود. از سوی دیگر هنگام ساخت برنامه سفارش کالا، رنگ یک خصوصیت مهم است و باید به عنوان بخشی از خصوصیات کالا در نظر گرفته شود.
بسته بندی
یکی دیگر از ویژگیهای مهم OOP بسته بندی است. بسته بندی میگوید که اجازه دسترسی مستقیم به دادهها داده نمیشود. اگر شما میخواهید به دادهای دسترسی یابید، باید از شیء ایی که مسئول آن داده است، بخواهید. در مثال انبار، اگر بخواهید اطلاعات مربوط به کالا را مشاهده یا ویرایش کنید، باید با شیء کالا رابطه برقرار کنید.
شما بسته بندی را در زندگی روزانه خود تجربه میکنید. درباره دپارتمان منابع انسانی فکر کنید. آنها اطلاعات مربوط به کارمندان را بسته بندی (پنهان) میکنند و تعیین میکنند که این دادهها چگونه میتوانند استفاده و نگهدای شوند. هر درخواست برای مشاهده یا ویرایش دادههای یک کارمند باید از طریق آنها انجام شود.
با بسته بندی، شما دادههای سیستم را ایمن و قابل اعتماد میکنید. شما میدانید که دادهها چگونه مورد دستیابی قرار میگیرند و چه عملیاتی روی آنها انجام میشوند. این کار نگهداری برنامه را ساده تر میکند و رفع خطا را آسان تر.
چند شکلی
چند شکلی عبارت است از انجام دادن یک کار به شکلهای مختلف. وقتی چندین شیء در پاسخ به درخواستهای مشابه، پاسخهای متفاوت و منحصربفرد میدهند، چند شکلی اتفاق میافتد. به عنوان مثال من میتوانم به سگ خود یاد بدهم که هر وقت صدایش کردم بگوید “هاپ” و به پرنده خود یاد دهم که هر وقت صدایش کردم بگوید “جیک” . به عبارت دیگر به هر دو یاد دادم که به یک پیام یکسان (صدا کردن) پاسخهای متفاوت بدهند.
چگونه این موضوع به OOP ربط دارد؟ شما میتوانید اشیایی ایجاد کنید که به پیام مشابه پاسخهای مختص خود را بدهند. به عنوان مثال، میتوانید پیام پرینت را به یک شیء پرینتر بدهید که متنی را روی پرینتر چاپ کند و همین پیام را به یک شیء صفحه نمایش بدهید تا متنی را روی صفحه نمایش نشان دهد. مثال خوب دیگری از چند شکلی استفاده از کلمات در زبان انگلیسی است. کلمات دارای معانی مختلفی هستند اما با توجه به زمینه جمله میتوانید ببینید که کدام معنی مد نظر است.
وراثت
اکثر اشیاء با توجه به خصوصیاتشان دسته بندی میشوند. به عنوان مثال شما میتوانید سگها را بر اساس خصوصیاتی مانند اندازه و وزن دسته بندی کنید. شما همچنین میتوانید اشیاء را با رفتارشان دسته بندی کنید. برای مثال، اتومبیلهای سواری و اتومبیلهای حمل و نقل. برای اینکه دنیا را بهتر درک کنید لازم است که سلسله مراتب اشیاء را داشته باشید.
شما از وراثت در OOP برای دسته بندی اشیاء در برنامه طبق خصوصیات و کارکردهای مشترک بهره میبرید. به کمک وراثت کار کردن با اشیاء سادهتر و قابل درکتر شده و برنامه نویسی سادهتر میگردد، زیرا میتوانید خصوصیات مشترک را در شیء والد قرار داده تا اشیاء فرزند آنها را به ارث ببرید. به عنوان مثال میتوانید یک شیء کارمند ایجاد کنید که همه خصوصیات عمومی یک کارمند را دارا باشد، سپس یک شیء مدیر تعریف کنید که خصوصیات شیء کارمند را به ارث برده و خصوصیات مدیر را به آن اضافه کند.
اجتماع
اجتماع حالتی است که یک شیء مرکب از اشیاء دیگری است که با یکدیگر در ارتباط هستند. برای مثال شیء ماشین چمن زنی از چرخ، موتور، تیغه و غیره تشکیل شده است. همچنین خود شیء موتور مرکب از اشیاء دیگری است. توانایی استفاده از اجتماع در OOP ویژگی قدرتمندی است که شما را قادر میسازد تا به درستی فرآیندهای بیزنس را در برنامه خود مدل کرده و پیاده سازی کنید.
شناسایی ساختار کلاس
اکثر پروژه های نرم افزاری در قالب کار تیمی انجام میشوند. به عنوان یک برنامه نویس در تیم از شما خواسته میشود تا مستندات طراحی را به کد برنامه تبدیل کنید. همین که شما در توسعه برنامههای شیءگرا تجربه کسب کنید، ممکن است حتی از شما خواسته شود که در جلسات طراحی حضور داشته باشید و در فرآیند طراحی شرکت کنید. بنابراین به عنوان یک توسعه دهنده نرم افزار شما باید با ساختار و اهداف مستندات طراحی آشنا باشید و همچنین دانش ایجاد و مدیریت آنها را کسب نمایید.
اهداف طراحی نرم افزار
فاز طراحی مهمترین بخش در چرخه توسعه نرم افزار است. شما میتوانید ببینید که بسیاری از مشکلات نرم افزارها مربوط به طراحی ضعیف و عدم ارتباط درست توسعه دهندگان و مشتریان نرم افزار است. بنابراین لزوم طراحی درست و اصولی نرم افزار ضروری است و منافع زیر را به دنبال دارد:
- فرصتی را فراهم میکند تا فرآیندهای بیزنس را بازنگری کرده و مشکلات و اشتباهات را برطرف کنید.
- تعریف دقیق حوزه نرم افزار
- فراهم کردن زمینه تست نرم افزار
- کاهش زمان و هزینه پیاده سازی نرم افزار
یک تشبیه مناسب از طراحی نرم افزار ساخت یک خانه است. شما انتظار ندارید که سازنده شروع به کار کند بدون اینکه نقشه معمار را داشته باشد. شما همچنین انتظار دارید که معمار قبل از رسم نقشه با شما درباره طراحی خانه صحبت کند. این وظیفه معمار است تا با شما درباره طراحی و کارکرد مورد انتظارتان از خانه مذاکره کند و این خواستهها را تبدیل به نقشههایی کند که سازنده از آنها برای ساخت خانه استفاده میکند. یک معمار خوب همچنین به شما یاد میدهد که چه ویژگیهایی متناسب با بودجه و زمان شما معقولانه هستند.
زبان مدل سازی یکپارچه (UML)
برای طراحی شیءگرا باید بتوانید طراحیها را مستند کنید. رایج ترین روش مستند کردن طراحی نرم افزار استفاده از زبان مدل سازی یکپارچه یا به اختصار UML است. UML در اولین دهه ۱۹۸۰ معرفی شد که پاسخی به داشتن استاندارد و روش نظام مند برای مدل کردن طراحی نرم افزار شیءگرا بود. UML از یک سری مدلها و نمودارهای متنی و گرافیکی تشکیل شده است. این مدلها حوزه سیستم، اجزای سیستم و تعاملات کاربران با سیستم و چگونگی تعامل اجزای سیستم با یکدیگر را تعریف میکنند. برخی از مدلهای معروف UML عبارتند از:
- مشخصه های نیازمندهای نرم افزار : یک توصیف متنی از حوزه و مسئولیتهای کلی سیستم
- مورد کاربرد: یک توصیف گرافیکی/متنی از چگونگی رفتار سیستم از دیدگاه کاربر
- نمودار کلاس: یک نقشه از اشیایی که سیستم را تشکیل میدهند به همراه سلسله مراتب آنها
- نمودار توالی: یک مدل برای بیان تعاملات اشیاء هنگام اجرای برنامه با تاکید بر ترتیب زمانی انجام تعاملات
- نمودار همکاری: یک مدل برای بیان تعاملات اشیاء هنگام اجرای برنامه با تاکید ارتباطات مابین اشیاء
- نمودار فعالیت: یک مدل نمایش جریان اجرای یک عملیات یا فرآیند.
ایجاد مشخصه های نیازمندهای نرم افزار
مشخصههای نیازمندهای نرم افزار[۱] یا به اختصار SRS یک توصیف متنی از حوزه و مسئولیتهای کلی سیستم است. هدف ایجاد این مستد عبارتند از:
- تعریف نیازمندهای عملیاتی سیستم
- شناسایی محدوده سیستم
- شناسایی کاربران سیستم
- توصیف تعامل بین سیستم و کاربران خارجی
- ایجاد یک زبان مشترک بین مشتری و تیم توسعه برای توصیف سیستم
- فراهم کردن زمینه برای مدل کردن موارد کاربرد
برای تهیه SRS شما با صاحبان بیزنس و کاربران سیستم مصاحبه میکنید. هدف این مصاحبهها مستند سازی فرآیندهای بیزنس و تعیین حوزه سیستم است. خروجی این فرآیند مستند رسمی SRS است که نیازمندی های عملیاتی سیستم را تشریح میکند. یک مستند رسمی کمک میکند تا توافق بین مشتریان و تیم نرم افزاری ایجاد شود.
به عنوان یک مثال، فرض کنید که صاحبان یک خط هوایی میخواهند که مشتریان بتوانند با استفاده از یک سیستم ثبت نام تحت وب اطلاعات پرواز را مشاهده کرده و رزرو بلیط را انجام دهند. بعد از مصاحبه با مدیران بیزنس و آژانسهای صدور بلیط، طراحان نرم افزار مستند SRS را تهیه کرده اند که در آن نیازمندی های سیستم به شرح زیر است:
- کاربران وب غیر عضو میتوانند از سایت بازدید نمایند و اطلاعات پروازها را مشاهده کنند ولی امکان رزرو ثبت ندارند.
- مشتریان جدیدی که میخواهند پروازها را رزرو کنند باید فرم ثبت نام را کامل کنند شامل نام، آدرس، شرکت، تلفن و ایمیل.
- و الی آخر
دقت کنید که در مستند SRS حوزه سیستم به خوبی مشخص میگردد. این مستندات فاقد اطلاعات فنی است و تنها نیازمندی های عملیاتی را بیان میکند. به محض اینکه SRS ایجاد شد، نیازمندی های عملیاتی تبدیل به تعدادی نمودار مورد کاربرد میشوند.
نمودار مورد کاربرد
موارد کاربرد[۲] تعاملات موجودیتهای خارجی با سیستم را توصیف میکنند. موجودیتهای خارجی میتوانند انسان یا سیستمهای دیگر باشد که با نام کنشگر (Actor) شناخته میشوند. این نمودار روی دیدگاه کاربران نسبت به سیستم تمرکز دارد و تعاملات بین کاربر و سیستم را نمایان میکد. موارد کاربر کمک میکنند که حوزه و محدوده سیستم را بهتر بشناسیم. آنها معمولا به شکل نمودارهایی به همراه توضیحات متنی هستند. شکل زیر یک نمودار مورد کاربرد نمونه را نشان میدهد که تشکیل شده است از دو کنشگر که با آدمک نشان داده شده اند، محدوده سیستم که با مستطیل نمایش داده شده است و دو مورد کاربرد که به شکل بیضی هایی درون محدوده سیستم ارائه شده اند.
موارد کاربرد بر اساس مستند SRS ایجاد میشوند. کنشگر میتواند هر موجودیت خارجی باشد که با سیستم در تعامل است. او میتواند یک کاربر انسانی (مانند کارشناس فروش) و یا سیستم نرم افزاری دیگر (مانند سیستم صورتحساب) و یا یک دستگاه واسط (مانند میله درجه حرارت) باشد. هر تعاملی که بین کنشگر و سیستم رخ میدهد به صورت یک مورد کاربرد مدل میشود.
برای مثال، مورد کاربرد در شکل زیر برای سیستم رزرو بلیط پرواز ایجاد شده است. این نمودار مورد کاربرد برای نیازمندی “مشتری میتواند جستجو کند برای پروازها بر اساس مقصد و ساعت حرکت” است.
به همراه اشکال گرافیکی در نمودار مورد کاربرد، خیلی از طراحان ترجیح میدهند تا توضیحات متنی را به آن اضافه کنند. این توضیحات باید کوتاه و مربوط بر چیزی باشد که اتفاق میافتد نه اینکه چگونگی اتفاق را شرح دهد. گاهی اوقات پیش شرط ها و پس شرط های مربوط به هر مورد کاربر شناسایی میشوند. متن زیر نمودار مورد کاربرد شکل فوق بیشتر توصیف میکند:
- توضیحات: یک مشتری به صفحه اطلاعات پرواز نگاه میکند. او معیار جستجوی خود را وارد میکند. بعد از ارسال درخواست، لیستی از پروازهای مطابق با معیار جستجوی خود را میبیند.
- پیش شرط: هیچی
- پس شرط: مشتری امکان ورود و هدایت به صفحه رزرو پرواز را دارد.
به عنوان مثالی دیگر، به مورد کاربرد رزرو کردن صندلی که در شکل زیر نشان داده شده است، نگاه کنید:
توضیحات زیر نمودار مورد کاربر فوق را توصیف میکنند:
- توضیحات: مشتری شماره پرواز و شماره صندلی را وارد میکنید. بعد از ارسال درخواست، اطلاعات تایید نمایش داده میشوند.
- پیش شرط: مشتری اطلاعات پرواز را جستجو کرده است. او به سیستم وارد شده است و صفحه رزرو پرواز را مشاهده میکند.
- پس شرط: به مشتری ایمیلی ارسال میشود که شامل جزئیات بلیط و شرایط لغو کردن است.
همانطور که در شکل فوق مشخص است، رابطه خاصی بین موارد کاربرد برقرار است . مورد کاربرد رزرو صندلی شامل مورد کاربرد مشاهده اطلاعات پرواز است. شناسایی این رابطه مفید است زیرا میتوانید از مورد کاربرد مشاهده اطلاعات پرواز مستقل از مورد کاربرد رزرو صندلی در جاهای دیگر استفاده کنید. به این رابطه شمول[۳] میگویند. شناسایی این روابط تاثیر مستقیم برای چگونگی مدل کردن سیستم میگذارند.
روش دیگری که موارد کاربرد میتوانند با یکدیگر در ارتباط باشد از طریق بسط (extension) است. شما میتوانید یک مورد کاربرد کلی داشته باشید که پایه موارد کاربرد دیگر باشد. به عبارت دیگر مورد کاربرد پایه توسط موارد کاربرد دیگر بسط داده میشوند. فرض کنید که مورد کاربرد ثبت نام مشتری را داریم که فرآیند کلی ثبت نام مشتریان را توصیف میکند. از آنجایی که شما دو نوع مشتریان شرکتی و موردی دارید، لازم است که دو مورد کاربرد برای ثبت نام داشته باشید. بنابراین این موارد کاربرد بسط میدهند مورد کاربرد ثبت نام کلی مشتریان. شکل زیر نشان میدهد که چگونه میتوانید این موارد کاربرد را نمایش دهید.
یک اشتباه رایج در طراحی موارد کاربرد، وارد کردن عملیاتی است که توسط خود سیستم آغاز میشود. دقت کنید که تاکید مورد کاربرد بر تعامل بین موجودیتهای خارجی و سیستم است نه تعاملات درونی سیستم. اشتباه رایج دیگر وارد کردن توضیحات مربوط به نیازمندیهای فنی سیستم است. به یاد داشته باشید که موارد کاربرد به چگونگی کارکرد سیستم کاری ندارند بلکه مهم این است که چه کارکردهایی باید سیستم انجام دهد.
بعد از اینکه موارد کاربرد سیستم را شناسایی کردهاید میتوانید شروع کنید با شناسایی اشیاء درونی سیستم. این کار با استفاده از نمودار کلاس انجام میپذیرد.
نمودار کلاس
مفهوم کلاسها و اشیاء در OOP بسیار اساسی است. اشیاء کارکردهای یک برنامه شیء گرا را انجام میدهند و کلاسها به عنوان نقشه یا طرحهایی برای اشیاء است. یک کلاس ساختار، خصوصیات و رفتارهای مربوط به یک شیء را تعریف میکند.
طراحان لیستی از کلاسهای بالقوه را با استفاده از مستند SRS و نمودارهای موارد کاربرد شناسایی میکنند. یک راه که شما میتوانید کلاسها را شناسایی کنید جستجو به دنبال عبارات اسمی در این مستندات است. اگر به مستندات برنامه رزرو هواپیما نگاه کنید، میتوانید شروع به شناسایی کلاسهایی کنید که سیستم را میسازند. برای مثال کلاسهای مشتری و پرواز کاملاً واضح هستند.
هنگام تعریف ساختار کلاس، شما باید تعیین کنید که کلاس مسئول پاسخگویی و نگهداری چه داده هایی است. خصوصیات یا صفات کلاس باید این دادهها را نگهداری کنند. برای مثال کلاس پرواز شامل خصوصیاتی مانند شماره پرواز، تاریخ و زمان حرکت، مدت پرواز، مقصد، ظرفیت و صندلیهای خالی است. همچنین ساختار باید کلاس عملیاتی روی این داده ها انجام میشوند را مشخص کنند. برای مثال کلاس پرواز مسئول به روز کردن صندلیهای خالی به محض رزرو یک صندلی است.
با نمودار کلاس میتواند خصوصیات و عملیات یک کلاس را نمایان کنید. شکل زیر کلاس پرواز را نشان میدهد. یک کلاس به شکل یک مستطیل که به سه قسمت تقسیم شده است. در قسمت بالا نام کلاس، قسمت میانی خصوصیات کلاس و قسمت پایینی عملیاتی که کلاس انجام میدهد، درج میشوند.
|
جای تبلیغات شما اینجا خالیست با ما تماس بگیرید
|
|