شیءگرایی یعنی چه و تفکر شیءگرا چیست ؟

[bigbang]

اگر دقت کنید که چگونه کارهای خود را در دنیای واقعی انجام می­دهید، خواهید دید که در یک دنیای شیءگرا هستید. برای مثال، اگر می­خواهید به فروشگاه بروید، با شیء اتومبیل کار دارید. شیء اتومبیل از اشیاء دیگری تشکیل شده است که با یکدیگر همکاری می­کنند تا شما را به فروشگاه برسانند. شما سوییچ را در شیء قفل استارتر وارد می­کنید و آن را می­چرخانید. به این ترتیب یک پیام (از طریق سیگنال الکتریکی) به شیء استارتر ارسال می­شود و متعاقب آن، این شیء با شیء موتور ارتباط برقرار می­کند تا اتومبیل را روشن کند. به عنوان یک راننده شما از چگونگی همکاری این اشیاء بی خبر و ایزوله هستید. شما با چرخاندن سوییچ آغازگر یک سلسله از رخدادها هستید و فقط به انتظار پاسخ می­نشینید.
به صورت مشابه کاربران برنامه­های نرم افزاری از منطق و چگونگی انجام کارکردهای برنامه بی اطلاع هستند. برای مثال، وقتی که در نرم افزار واژه پرداز یک صفحه را پرینت می­کنید، این کار را با کلیک روی کلید 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 و نمودارهای موارد کاربرد شناسایی می­کنند. یک راه که شما می­توانید کلاس­ها را شناسایی کنید جستجو به دنبال عبارات اسمی در این مستندات است. اگر به مستندات برنامه رزرو هواپیما نگاه کنید، می­توانید شروع به شناسایی کلاس­هایی کنید که سیستم را می­سازند. برای مثال کلاس­های مشتری و پرواز کاملاً واضح هستند.
هنگام تعریف ساختار کلاس، شما باید تعیین کنید که کلاس مسئول پاسخگویی و نگهداری چه داده هایی است. خصوصیات یا صفات کلاس باید این داده­ها را نگهداری کنند. برای مثال کلاس پرواز شامل خصوصیاتی مانند شماره پرواز، تاریخ و زمان حرکت، مدت پرواز، مقصد، ظرفیت و صندلی­های خالی است. همچنین ساختار باید کلاس عملیاتی روی این داده ها انجام می­شوند را مشخص کنند. برای مثال کلاس پرواز مسئول به روز کردن صندلی­های خالی به محض رزرو یک صندلی است.
با نمودار کلاس می­تواند خصوصیات و عملیات یک کلاس را نمایان کنید. شکل زیر کلاس پرواز را نشان می­دهد. یک کلاس به شکل یک مستطیل که به سه قسمت تقسیم شده است. در قسمت بالا نام کلاس، قسمت میانی خصوصیات کلاس و قسمت پایینی عملیاتی که کلاس انجام می­دهد، درج می­شوند.