اموزش c++ مبحث آموزشی مهندسی نرم‌افزار (قسمت هشتم)

مبحث آموزشی مهندسی نرم‌افزار: بررسی نیازمندی‌های ATM
در این بخش طراحی و پیاده‌سازی شی‌گرا، مبحث آموزشی مهندسی نرم‌افزار را آغاز می‌کنیم. بخش‌های «مبحث آموزشی مهندسی نرم‌افزار» که در انتهای این فصل و چند فصل بعدی قرار داده شده‌اند، شما را به آسانی وارد بحث شی‌گرایی خواهند کرد. نرم‌افزاری برای یک سیستم ماشین تحویل‌دار خودکار ATM ایجاد خواهیم کرد، که تجربه مناسبی در زمینه طراحی و پیاده‌سازی برایتان به ارمغان خواهد آورد. در فصل‌های ۷-۳ و ۱۳، مراحل مختلفی از فرآیند طراحی شی‌گرا (OOD) را با استفاده از UML انجام خواهیم داد، و در کنار آن، مباحث مرتبط نیز در خود فصل‌ها مطرح می‌شوند. ضمیمه‌ای در ارتباط با پیاده‌سازی ATM با استفاده از تکنیک‌های برنامه‌نویسی شی‌گرا (OOP) در C++ آورده شده است. بحث ما یک بحث کاملاً آموزشی است، و حالت تمرینی ندارد و شما را کاملاً درگیر جزئیات کار با کد C++ می‌کند که پیاده‌سازی‌کننده برنامه هستند. این مطالب شما را با انواع مسائل قابل توجه در صنایع و همچنین راه‌حل‌های موجود آشنا خواهند کرد.

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

مستند نیازها

فرض کنید یک بانک محلی مایل است تا یک سیستم ATM جدید را بکار گیرد و به کاربران (مشتریان بانک) اجازه دهد تا تعاملات مالی خود را با آن انجام دهند (شکل ۱۵-۲). هر کاربر می‌تواند فقط یک حساب در بانک داشته باشد. کاربران ATM باید قادر به دیدن موجودی حساب، برداشت از حساب و پس‌انداز باشند.

واسط کاربر ATM حاوی کامپونت‌های سخت‌افزاری زیر است:

* یک صفحه نمایش که پیغام‌ها را به کاربر بنمایش درمی‌آورد
* یک صفحه کلید که ورودی عددی را از کاربر دریافت می‌نماید
* تحویل‌دار خودکار که پول را به کاربر تحویل می‌دهد
* شکاف سپرده که پاکت سپرده را از کاربر تحویل می‌گیرد.

تحویل‌دار خودکار هر روز با پانصد عدد ۲۰ دلاری پر می‌شود. ‍‍‍‍[نکته: به این علت که این مبحث آموزشی است، برخی از عناصر مشخص ATM توصیف شده در اینجا، دقیقاً مطابق با ATM واقعی نیستند. برای مثال، معمولاً در یک ATM واقعی دستگاهی وجود دارد که شماره حساب مشتری را از یک کارت ATM می‌خواند، در حالیکه در ATM ما از کاربر خواسته می‌شود که شماره حساب خود را از طریق صفحه کلید وارد کند. همچنین در یک ATM واقعی قبض رسید در پایان هر عملیات یا جلسه چاپ می‌شود. امام تمام خروجی‌ها در این ATM بر روی صفحه نمایش ظاهر می‌شوند.]

بانک از شما می‌خواهد تا برنامه‌ای جدید برای انجام تعاملات مالی مشتریان بانک از طریق ATM توسعه دهید. بانک بعداً نرم‌افزار را با سخت‌افزار ATM مجتمع خواهد کرد. نرم‌افزار بایستی عملکرد دستگاه‌های سخت‌افزاری (همانند پرداخت‌کننده پول، دریافت‌کننده سپرده) را در درون کامپونت‌های نرم‌افزاری کپسوله‌ کند، اما نیازی ندارد که از عملکرد داخلی و جزئیات آنها مطلع باشد. فعلاً بخش سخت‌افزاری ATM تولید نشده است، از اینرو بجای نوشتن نرم‌افزاری که بروی ATM اجرا شود، باید نسخه اولیه از نرم‌افزار را برای اجرا بر روی یک کامپیوتر شخصی ایجاد کنید. این نسخه از برنامه، از مانیتور کامپیوتر برای شبیه‌سازی صفحه نمایش ATM و صفحه کلید کامپیوتر برای شبیه‌سازی، صفحه کلید ATM استفاده خواهد کرد.

یک جلسه ATM متشکل از تصدیق یا تایید کاربر (اثبات هویت کاربر) برپایه شماره حساب و شماره شناسایی شخصی (PIN) بوده و در ادامه تعاملات مالی صورت می‌گیرد. برای تایید کاربر و انجام تعاملات، بایستی ATM با پایگاه داده اطلاعات حساب بانکی در تعامل قرار گیرد. [نکته: پایگاه داده یک مجموعه سازماندهی شده از اطلاعات ذخیره شده در یک کامپیوتر است.] برای هر حساب بانکی، پایگاه داده‌ یک شماره حساب، یک PIN و یک موجودی که نشان‌دهنده مقدار پول در آن حساب است، در خود ذخیره می‌سازد. [نکته: برای ساده‌تر شدن کار، فرض می‌کنیم که هدف بانک فقط داشتن یک دستگاه ATM است، بنابراین نیازی نیست که نگران نحوه دسترسی همزمان چندین ATM به این پایگاه داده باشید. علاوه بر این، فرض می‌کنیم که بانک هیچ تغییری در زمان استفاده کاربر (مشتری) از ATM، در پایگاه داده اعمال نمی‌کند. همچنین هر سیستم تجاری همانند ATM به دلایل قابل قبولی در ارتباط با مباحث امنیتی است که خارج از قلمرو تحصیلی یک دانشجوی ترم اول یا دوم کامپیوتر است.]

در اولین برخورد، مشتری با ATM باید توالی از رویدادهای زیر رخ دهند (به شکل ۱۵-۲ توجه نمائید):

۱- صفحه نمایش پیغام خوش‌آمدگویی (Welcome) را بنمایش درآورده و از کاربر می‌خواهد تا شماره حساب خود را وارد سازد.

۲- کاربر شماره حساب پنج‌رقمی خود را با استفاده از صفحه کلید وارد می‌سازد.

۳- در صفحه نمایش از کاربر خواسته می‌شود تا PIN را وارد سازد، که مرتبط با شماره حساب است.

۴- کاربر از طریق صفحه کلید، PIN پنج رقمی خود را وارد می‌سازد.

۵- اگر شماره حساب و PIN ورودی معتبر باشند، ظاهر صفحه نمایش همانند شکل ۱۶-۲ بوده  و منوی اصلی در آن ظاهر می‌گردد. اگر شماره حساب یا PIN اشتباه باشد، پیغام مناسب در صفحه نمایش ظاهر شده و ATM به مرحله اول باز می‌گردد تا فرآیند تایید را از نو آغاز کند.

پس از تایید کاربرد از سوی ATM، منوی اصلی (شکل ۱۶-۲) لیستی از گزینه‌های عددی برای هر سه نوع تراکنش بنمایش در می‌آورد: درخواست موجودی (گزینه ۱)، برداشت (گزینه ۲) و سپرده‌گذاری (گزینه ۳). همچنین منوی اصلی، گزینه‌ای برای خروج از سیستم در اختیار کاربر قرار می‌دهد (گزینه ۴). پس از نمایش منوی اصلی، کاربر می‌تواند تراکنش موردرنظر خود را از طریق وارد کردن ۱، ۲، ۳ یا خروج از سیستم، ۴ انتخاب کند. اگر کاربر گزینه اشتباهی را وارد سازد، پیغامی به نمایش درخواهد آمد، و سپس مجدداً منوی اصلی بنمایش در می‌آید.

اگر کاربر گزینه ۱ را انتخاب کند (با وارد کردن عدد ۱) تا از میزان موجودی خود مطلع گردد، این امر صورت خواهد گرفت. برای انجام این کار، بایستی ATM میزان موجودی را از پایگاه داده بانک بازیابی کند.

مراحل زیر زمانی رخ می‌دهند که کاربر گزینه ۲ را برای برداشت پول انتخاب کرده باشد:

۶- منوی در صفحه نمایش ظاهر می‌شود (شکل ۱۷-۲) که حاوی مقادیر استاندارد قابل پرداخت است. (گزینه ۱) $۲۰، (گزینه ۲) $۴۰، (گزینه ۳) $۶۰، (گزینه ۴)، $۱۰۰ و (گزینه ۵) $۲۰۰. همچنین این منو دارای یک گزینه برای لغو تراکنش کاربر است (گزینه ۶).

۷- کاربر با استفاده از صفحه کلید، انتخاب خود را انجام می‌دهد (گزینه‌های۶-۱).

۸- اگر مقدار درخواستی برای برداشت، بیشتر از میزان موجودی کاربر باشد، پیغامی این مطلب را به عرض کاربر رسانده و از وی می‌خواهد که مقدار کمتری تقاضا کند. سپس ATM به مرحله اول باز می‌گردد. اگر مقدار درخواستی کمتر از موجودی یا برابر آن باشد (یک مقدار قابل قبول)، ATM مرحله ۴ را آغاز خواهد کرد. اگر کاربر مبادرت به لغو تراکنش کند (گزینه ۶)، ATM منوی اصلی را به نمایش در آورده و منتظر ورودی کاربر می‌شود (شکل ۱۶-۲).

۹- اگر پرداخت‌کننده خودکار پول، به میزان کافی پول برای برآورده کردن تقاضای مشتری داشته باشد، ATM وارد مرحله ۵ خواهد شد. در غیر اینصورت، صفحه نمایش پیغامی مبنی بر اینکه میزان پول دستگاه کمتر از مقدار درخواستی است از کاربر می‌خواهد که مقدار کمتری را انتخاب نماید. سپس ATM به مرحله اول بازمی‌گردد.

۱۰- ATM مقدار پول برداشتی را از موجودی حساب کاربر در پایگاه داده بانک کم می‌کند.

۱۱- پرداخت‌کننده خودکار، مقدار پول درخواستی را به کاربر تحویل می‌دهد.

۱۲- پیغامی در صفحه نمایش ظاهر شده و به کاربر یادآوری می‌کند، پول را بردارد.

مراحل زیر زمانی رخ می‌دهند که کاربر عدد ۳ را از منوی اصلی به منظور سپرده‌گذاری انتخاب کرده باشد:

۱۳- در صفحه نمایش، به کاربر اعلان می‌شود که مقدار سپرده‌گذاری خود را وارد سازد یا برای لغو تراکنش صفر را وارد کند.

۱۴- کاربر از طریق صفحه کلید، مقدار سپرده‌گذاری یا صفر را وارد می‌سازد [نکته: صفحه کلید دارای نقطه اعشار یا نماد دلار نمی‌باشد، از اینرو، کاربر نمی‌تواند یک مقدار دلاری واقعی همانند $۱.۲۵ را وارد سازد. بجای آن، کاربر باید مقدار سپرده خود را بعنوان یک عدد از سنت‌ها وارد کند (مثلاً (۱۲۵. سپس ATM این عدد را بر ۱۰۰ تقسیم می‌کند، تا عددی که نشاندهنده مقدار دلاری است بدست آید (مثلاً (۱۲۵÷۱۰۰=۱.۲۵].

۱۵- اگر کاربر میزان سپرده را مشخص سازد، ATM به مرحله ۴ می‌رود. اگر کاربر، مبادرت به لغو تراکنش کند (با وارد کردن صفر)، ATM منوی اصلی را به نمایش درآورده و در انتظار ورودی کاربر باقی می‌ماند.

۱۶- در صفحه نمایش، پیغامی به کاربر اعلان می‌کند که پاکت سپرده را در شکاف سپرده قرار دهد.

۱۷- اگر شکاف سپرده، پاکت سپرده را در عرض دو دقیقه دریافت نماید، ATM مبادرت به افزایش اعتبار کاربر، در میزان موجودی وی در پایگاه داده بانک می‌کند [نکته: این مقدار پول، بلافاصله برداشت نمی‌شود. ابتدا باید بانک به لحاظ فیزیکی مبادرت به بازبینی پول نقد و چک‌های موجود در پاکت کرده و پس از تایید بانک، حساب کاربر در پایگاه داده به روز می‌شود. این عملیات مستقل از سیستم ATM صورت می‌گیرد.] اگر در مدت زمان مشخص شده، شکاف سپرده، پاکتی دریافت نکند، پیغامی در صفحه نمایش مبنی بر لغو تراکنش از طرف سیستم ظاهر خواهد شد. سپس ATM منوی اصلی را به نمایش درآورده و منتظر ورودی کاربر باقی ماند.

پس از اجرای موفقیت‌آمیز یک تراکنش توسط سیستم، باید مجدداً منوی اصلی بنمایش درآید (شکل ۱۶-۲) تا کاربر قادر به انجام تراکنش‌های دیگر باشد. اگر کاربر گزینه ۴ را انتخاب کند (خروج از سیستم)، پیغام تشکر بنمایش درآمده و سپس پیغام خوش‌آمدگویی، برای کاربر بعدی بنمایش درمی‌آید.

تحلیل سیستم ATM

بخش قبلی مثال ساده شده‌ای از یک مستند نیازمندی‌ها بود. بطور نمونه، چنین مستندی، نتیجه‌ای از نیازمندی‌های جمع‌آوری شده است که شامل مصاحبه با کاربران اصلی سیستم و متخصصین در فیلدهای مربوط به سیستم است. برای مثال، تحلیل‌گر سیستم کسی است که برای آماده کردن مستند نیازمندی‌های نرم‌افزار بانک استخدام می‌شود (مثلاً سیستم ATM که در اینجا توضیح داده شده است) و می‌تواند با متخصصین امور مالی مصاحبه انجام دهد تا درک دقیقی از کاری که نرم‌افزار باید انجام دهد بدست آورد. تحلیل‌گر از اطلاعات بدست آمده، لیستی از نیازهای سیستم جمع‌آوری می‌کند تا طراحان سیستم را بخوبی راهنمایی کند.

فرآیند جمع‌آوری اطلاعات نیازمندی‌ها، یک وظیفه کلیدی در مرحله اول چرخه زندگی نرم‌افزار است. چرخه زندگی نرم‌افزار، تصریح‌کننده مراحلی است که نرم‌افزار از بدو تولد تا زمان بازنشستگی طی می‌کند. بطور نمونه این مراحل عبارتند از: تحلیل، طراحی، پیاده‌سازی، تست و خطایابی، استفاده، نگهداری و بازنشستگی. چندین مدل برای چرخه طول عمر نرم‌افزار وجود دارد که هر یک دارای مزایا و مشخصات خاص بوده که روش انجام مراحل مختلف را به مهندسان نرم‌افزار گوشزد می‌کنند. مدل آبشاری (waterfall model) هر مرحله را یکی بعد از دیگری انجام می‌دهد، در حالیکه مدل تکرارکننده (iterative model) می‌تواند مراحل را یک یا چندین بار در فرآیند چرخه طول عمر یک محصول تکرار نماید.

مرحله تحلیل در چرخه طول عمر نرم‌افزار، متمرکز بر تعریف مسئله برای حل کردن آن است. به هنگام طراحی هر سیستمی، باید مسئله بدرستی حل شود (راه حل باید صحیح باشد). تحلیل‌گران سیستم مبادرت به جمع‌آوری نیازهایی می‌کنند که قادر به حل مسئله مشخصی هستند. مستند نیازها که آن را در اینجا برای سیستم ATM مطرح کرده‌ایم، بقدر کافی گویا است و نیازی نیست که وارد یک مرحله تحلیل اضافی‌تر شوید.

برای ثبت اینکه سیستم مورد نظر چه کاری باید انجام دهد، غالباٌ توسعه‌دهندگان از تکنیکی بنام مدل‌سازی use case (حالت استفاده) کمک می‌گیرند. این فرآیند حالات مورد استفاده از سیستم را معین می‌سازد، که هر یک نشانگر یک قابلیت مختلف است که سیستم در اختیار سرویس‌گیرندگان خود قرار می‌دهد. برای مثال، بطور نمونه ATMها دارای چندین حالت استفاده همانند «نمایش میزان موجودی»، «برداشت پول»، «سپرده‌گذاری»، «انتقال پول مابین حساب‌ها» و «خرید تمبر پستی» هستند. سیستم ATM ساده شده که قصد ساخت آن را داریم، فقط دارای سه حالت استفاده است که در شکل ۱۸-۲ دیده می‌شود.

هر حالت استفاده توصیف‌کننده یک سناریو است که کاربر از سیستم استفاده می‌کند. در حال حاضر حالات استفاده از سیستم ATM را از مستند نیازها مطالعه کرده‌اید، که هر مرحله نیازمند نوعی از تراکنش است (نمایش موجودی، برداشت پول و سپرده‌گذاری)، که آنها را در سه حالت استفاده از ATM قرار داده‌ایم.

دیاگرام‌های Use Case

در این بخش مبادرت به معرفی یکی از چندین دیاگرام UML برای ATM مطرح شده در این مبحث آموزشی می‌کنیم. یک دیاگرام حالت استفاده (use case) برای مدل کردن تراکنش‌های مابین سرویس‌گیرندگان سیستم (در این مورد، مشتریان بانک مدنظر هستند) و سیستم ایجاد می‌کنیم. هدف، نمایش انواع تراکنش‌های کاربران با سیستم است بدون اینکه جزئیات را وارد کار نمائیم (جزئیات در دیاگرام‌های دیگر UML تدارک دیده می‌شوند، که در ادامه با آنها مواجه خواهید شد). غالباً دیاگرام‌های حالت استفاده همراه با جملات غیررسمی که توصیف‌کننده دقیق‌تر حالات استفاده هستند، همراه می‌باشند، همانند جملاتی که در مستند نیازها دیده می‌شود. دیاگرام‌های حالت استفاده در مرحله تحلیل چرخه عمر نرم‌افزار تولید می‌شوند. در سیستم‌های بزرگتر، دیاگرام‌های حالت استفاده ساده هستند اما جزء ابزارهای ضروری هستند که به طراحان سیستم کمک می‌کنند تا تمرکز خود را بر روی نیازهای کاربران حفظ کنند.

شکل ۱۸-۲ نمایشی از دیاگرام حالت استفاده برای سیستم ATM است. تصویر آدمک نشان‌دهنده یک بازیگر (actor) است که تعریف‌کننده نقش‌های است که یک موجودیت خارجی همانند یک شخص یا سیستم دیگر، به هنگام در تعامل قرار گرفتن با سیستم ایفاء می‌کند. برای سیستم ATM ما، بازیگر کاربری است که می‌تواند میزان موجودی را مشاهده کند، از سیستم پول دریافت و در آن سپرده‌گذاری انجام دهد. کاربر یک شخص حقیقی نیست، اما دارای نقش‌های از یک شخص واقعی است (زمانیکه نقشی از یک کاربر را باز می‌کند) و می‌تواند آن نقش‌ها را در زمان تعامل با ATM بازی‌کند. دقت کنید که دیاگرام حالت استفاده می‌تواند حاوی چندین بازیگر باشد. برای مثال، دیاگرام حالت استفاده در یک سیستم ATM واقعی، می‌تواند شامل یک بازیگر بنام Administrator (مدیر) باشد که مسئول پر کردن هر روز پول در تحویل‌دار است.

شناسایی بازیگر در سیستم را با بررسی مستند نیازها مشخص می‌کنیم که عبارت است از “کاربران ATM بایستی قادر به مشاهده میزان موجودی، برداشت پول و سپرده‌گذاری باشند.” از اینرو، بازیگر در هر یک از این سه حالت استفاده، کاربری است که با ATM در تعامل قرار می‌گیرد. موجودیت خارجی، یک شخص حقیقی، بخشی از نقش کاربر را در انجام تراکنش‌های مالی بازی می‌کند. در شکل ۱۸-۲ یک بازیگر بنام «کاربر» نشان داده شده است. UML هر کدامیک از حالات استفاده را بصورت یک بیضی متصل به بازیگر توسط یک خط ساده را مدل می‌کند.

بایستی مهندسان نرم‌افزار یا بطور دقیق‌تر طراحان سیستم، مبادرت به تحلیل مستند نیازها یا تنظیم حالات استفاده و طراحی سیستم قبل از شروع به برنامه‌نویسی با یک زبان برنامه‌نویسی خاص کنند. در مدت زمان مرحله تحلیل، طراحان سیستم بر درک مستند نیازها تمرکز دارند تا مشخصاتی با معیار بالا بدست آید که توصیف‌کننده آنچه که سیستم باید انجام دهد، باشد. خروجی مرحله طراحی (طراحی مشخصه‌ها) بایستی بقدر کافی واضح و شفاف باشد که نحوه ایجاد سیستم را برای برآورده کردن نیازها بیان کند. در چند بخش بعدی «مبحث آموزشی مهندسی نرم‌افزار» این مراحل را از طریق طراحی شی‌گرا (OOD) بر روی سیستم ATM به منظور تولید طرحی از مشخصه‌ها انجام خواهیم داد که حاوی مجموعه‌ای از دیاگرام‌های UML و جملات پشتیبانی‌کننده است. بخاطر دارید که UML برای استفاده در هر فرآیند OOD طراحی شده است. چندین پردازش‌کننده وجود دارد که یکی از بهترین آنها RUP (Rational Unified Process) است که توسط شرکت Rational Software توسعه پیدا کرده است (این شرکت تبدیل به بخشی از IBM شده است). RUP یک پردازش‌کننده بسیار مناسب و مطلوب برای طراحی برنامه‌های کاربردی در سطح صنایع است. برای این مبحث آموزشی، فرآیند طراحی ساده شده خود را معرفی می‌کنیم.

طراحی سیستم ATM

در این بخش وارد مرحله طراحی سیستم ATM می‌شویم. سیستم مجموعه‌ای از کامپونت‌ها است که برای حل مسئله‌ای با هم در تعامل قرار می‌گیرند. برای مثال، برای اینکه سیستم ATM وظایف تعیین شده را انجام دهد، باید دارای یک واسط کاربر بوده (شکل ۱۵-۲) و حاوی نرم‌افزاری باشد که قادر به انجام تراکنش‌های مالی و کار با پایگاه داده اطلاعات حساب مشتریان در بانک باشد. ساختار سیستم، توصیف‌کننده شی‌های سیستم و روابط داخلی آنها است. رفتار سیستم توصیف‌کننده نحوه تغییر عملکرد شی‌های سیستم و برقراری روابط بین آنها است. هر سیستمی دارای ساختار و رفتار است، که طراحان باید آنها را مشخص سازند. چندین نوع مشخص از ساختار و رفتار سیستم وجود دارد. برای مثال، تعامل مابین شی‌ها در یک سیستم، متفاوت از تعامل مابین سیستم و کاربر است، با این همه هنوز هر دو بخشی از رفتار سیستم محسوب می‌شوند. نسخه UML 2 تصریح‌کننده ۱۳ نوع دیاگرام برای مستند کردن مدل‌های سیستم است. هر دیاگرام صفات مشخصی از ساختار سیستم یا رفتار آن را مدل‌سازی می‌کند، شش دیاگرام در ارتباط با ساختار سیستم بوده و هفت دیاگرام باقیمانده مربوط به رفتار سیستم هستند. در اینجا فقط شش نوع دیاگرام بکار رفته در این مبحث را لیست کرده‌ایم، یکی از آنها بنام دیاگرام کلاس، مبادرت به مدل کردن ساختار سیستم می‌کند و مابقی در ارتباط با مدل‌سازی رفتار سیستم هستند.

۱- دیاگرام حالت استفاده، همانند شکل ۱۸-۲، مبادرت به مدل‌سازی تعامل صورت گرفته مابین سیستم و موجودیت خارجی آن (بازیگران) با جملات حالت استفاده می‌کند (قابلیت‌های سیستم همانند «نمایش میزان موجودی»، «برداشت پول» و «سپرده‌گذاری»).

۲- دیاگرام‌های کلاس، که در بخش ۱۱-۳ با آنها آشنا خواهید شد. این دیاگرام‌ها در مدل کردن کلاس‌ها یا «ایجاد بلوک‌های» مورد استفاده در سیستم کاربرد دارند. هر اسم یا «چیز» توصیف شده در مستند نیازها، نامزد تبدیل شدن به یک کلاس در سیستم است (همانند «حساب»، «صفحه کلید»). دیاگرام‌های کلاس در مشخص کردن روابط ساختاری موجود مابین اجزای سیستم نقش دارند. برای مثال، دیاگرام کلاس سیستم ATM مشخص می‌کند که ATM به لحاظ فیزیکی متشکل از یک صفحه نمایش، صفحه کلید، تحویل‌دار خودکار پول و شکاف سپرده‌گذاری است.

۳- دیاگرام‌های وضعیت ماشین، که در بخش ۱۱-۳ با آنها آشنا خواهید شد. این دیاگرام‌ها در مدل‌سازی روش‌های که یک شی تغییر وضعیت یا حالت می‌دهد کاربرد دارند. وضعیت یک شی توسط مقادیری که از صفات شی در زمان اجرا بدست می‌آیند، تعیین می‌شود. زمانیکه وضعیت یک شی تغییر پیدا می‌کند، امکان دارد شی رفتار متفاوتی در سیستم بخود بگیرد. برای مثال، پس از اعتبارسنجی PIN کاربر، تراکنش ATM از وضعیت «کاربر تایید نشده» به وضعیت «کاربر تایید شده» تبدیل شده و در این لحظه ATM به کاربر اجازه می‌دهد تا تراکنش‌های مالی انجام دهد (مشاهده میزان موجودی، برداشت پول و سپرده‌گذاری).

۴- دیاگرام‌های فعالیت، که در بخش ۱۱-۵ با آنها آشنا خواهید شد. این دیاگرام‌ها در مدل‌سازی فعالیت یک شی کاربرد دارند (جریان کار یا روند کار یک شی (توالی از رویدادها) در مدت زمان اجرای برنامه). یک دیاگرام فعالیت مبادرت به مدل کردن اعمال یک شی و همچنین ترتیب انجام این اعمال را مشخص می‌نماید. برای مثال، یک دیاگرام فعالیت نشان می‌دهد که ATM باید میزان موجودی حساب کاربر را (از پایگاه داده اطلاعات حساب) قبل از اینکه صفحه نمایش موجودی را بنمایش درآورد، تهیه نماید.

۵- دیاگرام‌های ارتباطی (در نسخه‌های قبلی UML این دیاگرام، دیاگرام‌های همکاری نامیده می‌شود) مدل‌کننده تعامل‌های صورت گرفته‌ مابین شی‌های یک سیستم هستند، با تاکید بر اینکه کدام تعامل رخ دهد. در بخش ۱۲-۷ با این نوع دیاگرام‌ها آشنا خواهید. برای مثال باید ATM با پایگاه داده حساب بانکی ارتباط برقرار کند تا میزان موجودی را بازیابی نماید.

۶- دیاگرام‌های توالی، این دیاگرام‌ها نیز مبادرت به مدل‌سازی تعامل‌های صورت گرفته مابین شی‌های یک سیستم می‌کنند، اما برخلاف دیاگرام‌های ارتباطی، تاکید آنها بر زمان رخ دادن تعامل‌ها است. در بخش ۱۲-۷ با این نوع دیاگرام‌ها آشنا خواهید شد. برای مثال، صفحه نمایش به کاربر اطلاع می‌دهد که مقدار پولی که می‌خواهد برداشت کند را قبل از پرداخت وارد نماید.

در بخش ۱۱-۳ به ادامه طراحی ATM با شناسایی کلاس‌ها از طریق مستند نیازها ادامه خواهیم داد. این کار را با استخراج اسامی کلیدی و تعبیر اسامی از مستند نیازها انجام خواهیم داد. با استفاده از این کلاس‌ها، اولین پیش‌نویس خود را از دیاگرام کلاس ایجاد می‌کنیم که ساختار سیستم ATM را مدل‌سازی می‌کند.