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

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

[bigbang]

مدل کردن روابط بین اشیاء

در OOP وقتی که برنامه اجرا می­شود، اشیاء مختلفی با یکدیگر کار می­کنند تا وظایف برنامه را انجام دهند. برای مثال، در برنامه رزرو پرواز، برای رزرو کردن یک صندلی، شیء Reservation باید با شیء Flight رابطه برقرار کند. این رابطه باید در نمودار کلاس مدل شود. با بررسی افعال در مستند SRS اغلب این رابطه­های کشف می­شوند. در ادامه برخی از مهمترین رابطه­ها بین کلاس­ها به وجود می­آید بیان می­شوند.
اتحاد[۴]

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

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

حالتی ممکن است وجود داشته باشد که یک نمونه از یک کلاس با چندین نمونه از کلاس خودش رابطه داشته باشد. برای مثال یک نمونه از کلاس خلبان، کاپیتان است و نمونه دیگر کمک خلبان. خلبان کمک خلبان را مدیریت می­کند. این سناریو به عنوان یک اتحاد با خود[۵] شناخته می­شود و با رسم خط ارتباطی از کلاس به خودش مدل می­شود، مطابق شکل زیر:

وراثت

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

اجتماع

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

کلاس های اتحادی

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

نمودار کلاس تکمیل شده برنامه رزرو بلیط پرواز

شکل زیر نمودار کلاس تکمیل شده برنامه رزرو بلیط هواپیما را نمایش می­دهد. این نمودار شامل ک

[bigbang]

شناسایی تعاملات بین اشیاء

در بخش های قبل روی مدل کردن جنبه استاتیک (ساختاری) سیستم­های شیء گرا تمرکز کردیم. در این بخش تکنیک­های مدل سازی UML را ادامه می­دهیم و روی مدل کردن جنبه داینامیک (رفتاری) سیستم تمرکز می­کنیم. در اینجا بیان می­کنیم که اشیاء چگونه با یکدیگر تعامل دارند تا کارکردهای برنامه کاربردی را انجام دهند.
سناریوها

سناریوها به شناسایی تعاملات بین اشیاء کمک می­کنند. یک سناریو توصیفی متنی است از پردازش­های درونی برای پیاده سازی عملکرد یک مورد کاربرد. به یاد آورید که یک مورد کاربرد توصیف می­کرد کارکرد سیستم را از دیدگاه کاربران خارجی. یک سناریو اجرای مورد کاربرد را تشریح می­کند. به عبارت دیگر، هدف توصیف گام­هایی است که باید انجام شود توسط اشیایی که سیستم را می­سازند.
شکل زیر مورد کاربرد پردازش اجاره فیلم را برای برنامه کاربردی کلوپ اجاره فیلم نشان می­دهد. متن زیر این مورد کاربرد را توصیف می­کند:
- پس شرط ها: مشتری درخواستی برای اجاره یک فیلم از کارمند کلوپ صادر می­کند. مشتری دارای یک عضویت در کلوپ است و به کارمند کلوپ، کارت عضویت و شماره شناسایی ملی را ارائه می­کند. عضویت مشتری تایید می­شود، سپس اطلاعات وی نمایش داده شده و اعتبار او بررسی می­گردد.
- توضیحات: بررسی می­شود که آیا فیلم در انبار وجود دارد. اگر وجود داشت، یک نسخه از فیلم به مشتری داده شده و مشخصات آن ثبت می­شود. همچنین تاریخ برگشت فیلم به وی اطلاع داده می­شود.
- پس شرط: هیچی

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

یک نمودار توالی یک مدل برای بیان تعاملات اشیاء هنگام اجرای برنامه با تاکید بر ترتیب زمانی انجام تعاملات است. شکل زیر یک نمودار توالی نمونه را نشان می­دهد.

همانطور که در شکل فوق مشخص است جریان پیام­ها از شیء به شیء به صورت خطوط افقی است. زمان ارسال پیام­ها از بالا به پایین است. از هر شیء یک خط چین عمودی رسم می­شود که به خط زندگی معروف است. وجود مستطیل روی خط زندگی، نشان دهنده فعال بودن شیء است. منظور از فعال بودن یک شیء این است که در حال دریافت یا ارسال پیام است.
در OOP اشیاء از طریق پیام­ها با یکدیگر ارتباط دارند. برای نمایش یک پیام، یک پیکان از شیء شروع کننده آغاز می­شود و به شیء دریافت کننده ختم می­شود. پیکان خط چین که به سمت شیء آغازگر بر می­گردد بیانگر نتیجه پیام است. پیام­های نمودار توالی در حقیقت رفتار اشیاء (متدهای کلاس­های اشیاء) را مشخص می­کنند. شکل زیر نمودار توالی برای سناریو پردازش اجاره فیلم را نشان میدهد.

نمودار توالی برای سناریو پردازش اجاره فیلم
با تحلیل نمودار توالی، کلاس­هایی که باید برای این اشیاء ساخته شوند، شناسایی می­شوند. همچنین متدهای هر یک از کلاس­ها نیز تعیین می­گردند. در نمودار توالی فوق چهار شیء برای انجام سناریوی پردازش اجاره فیلم درگیر هستند که عبارتند از:
- شیء مشتری یک نمونه از کلاس Customer است و مسئول نگهداری اطلاعات یک مشتری.
- شیء کارمند کلوپ یک نمونه از کلاس RentalClerk است و مسئول مدیریت پردازش اجاره یک فیلم.
- شیء مورد اجاره یک نمونه از کلاس RentalItem است و مسئول مدیریت اطلاعات مربوط به یک فیلم قابل اجاره.
- شیء اجاره یک نمونه از کلاس Rental است و مسئول بسته بندی و نگهداری اطلاعات مربوط به یک اجاره .
انواع پیام­ها

در OOP ، پیام­ها به صورت همزمان یک غیر همزمان انتقال داده می­شوند. وقتی که داده­ها به صورت همزمان انتقال داده می­شوند، شیء ارسال کننده، پردازش را متوقف می­کند و منتظر دریافت پاسخ می­ماند و پس از آن به کار خود ادامه می­دهد. یک خط رسم شده با پیکان بسته در نمودار توالی بیان کننده پیام همزمان است. از سوی دیگر وقتی که یک شیء پیام غیر همزمان ارسال می­کند، به کار خود ادامه می­دهد و منطق پاسخ فوری نمی­ماند. یک خط رسم شده با نوک پیکان باز در نمودار توالی بیانگر پیام رسانی غیر همزمان است. یک پیکان خط چین معمولا یک پاسخ را نمایش می­دهد. این خطوط در شکل زیر رسم شده است.

با مطالعه نمودار توالی برای سناریوی پردازش اجاره فیلم، انواع پیام­هایی که باید انتقال یابند، قابل شناسایی هستند. برای مثال شیء RentalClerk ارسال می­کند یک پیام همزمان را به شیء RentalItem برای بررسی اینکه آیا یک نسخه از فیلم در انبار است یا نه. شیء RentalItem پاسخ بررسی را شیء RentalClerk برگشت می­دهد.
نمودار فعالیت

نمودار همکاری بیان کننده جریان فعالیت­هایی است که در طول یک فرآیند یا عملیات رخ می­دهد. شما می­توانید نمودار همکاری را برای مشاهده گردشکار در سطوح مختلف بسازید:
- تمرکز سطح بالا نمایش می­دهد هر مورد کاربرد را به عنوان یک فعالیت گردشکار.
- تمرکز سطح میانی نمایش می­دهد گردشکاری که درون یک مورد کاربرد خاص رخ می­دهد.
- تمرکز سطح پایین نمایش می­دهد گردشکاری که در یک متد خاص از یک کلاس رخ می­دهد.
نمودار فعالیت تشکیل شده است از نقطه شروع فرآیند که با یک دایره توپر نشان داده می­شود. پیکان­ها نمایش دهنده جریان فعالیت از یکی به دیگری است. مستطیل های گرد گوشه بیانگر فعالیت هستند و یک دایره چشم مانند، نشانگر انتهای فرآیند است. برای مثال در شکل زیر یک نمودار فعالیت نشان داده شده است که بیانگر یک فرآیند است که از فعالیت A شروع می­شود و به فعالیت B پیش می­رود و به پایان می­رسد.

نقاط تصمیم و شرایط محافظ

اغلب، یک فعالیت در شرایط خاصی منجر به فعالیت دیگر می­شود. در یک نمودار فعالیت شرطی بودن با یک نقطه تصمیم (به صورت یک لوزی) و با شرایط محافظ (شرطی که باید برای پیشروی فراهم گردد) در براکت در کنار خط جریان مشخص می­شود، مطابق شکل زیر:

پردازش موازی

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

[bigbang]

واسط کاربری گرافیکی

تا به حال، مباحث تحلیل و طراحی شیءگرا بر مدل کردن طراحی کارکردی و پردازش درونی برنامه متمرکز بود. برنامه های مدرن بر واسط کاربری گرافیکی قدرتمندی استوار هستند تا این کارکردها را به بهترین نحوه به کاربران ارائه کنند.
طراحی واسط کاربر نباید به صورت مجزا صورت گیرد، بلکه باید در ارتباط با طراحی منطق بیزنس باشد. موفقیت اکثر برنامه­های کاربردی با بازخورد کاربران سنجیده می­شوند. اگر کاربران از کار با برنامه راحت نیستند و برنامه نمی­تواند بهره وری کاربران را افزایش دهد، نشانه­های شکست نرم افزار پدیدار می­گردد. برای یک کاربر؛ برنامه کاربردی فقط واسط کاربری آن است و منطق پشت آن از نظر وی مهم نیست. بنابراین طراحی واسط کاربر روان، شهوی و سریع بسیار مهم است.
اگرچه UMLبه صورت مشخص برای طراحی واسط کاربر چیزی ندارد، خیلی از معماران و طراحان از نمودارهای UML برای مدل کردن واسط کاربر استفاده می­کنند.
نمودار فعالیت واسط کاربر

اولین گام برای طراحی واسط کاربر شناسایی نحوه تعامل کاربران با سیستم است. با استفاده از نمودارهای فعالیت واسط کاربر می­توانید این تعاملات را نشان دهید. شکل زیر نمودار فعالیت واسط کاربر برای ثبت اطلاعات اجاره فیلم را نمایش می­دهد.

نمونه اولیه واسط کاربر

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