آموزش ++C - بخش پنجم

مبحث آموزشي مهندسي نرم‌افزار: بررسي نيازمندي‌هاي ATM

در اين بخش طراحي و پياده‌سازي شي‌گرا، مبحث آموزشي مهندسي نرم‌افزار را آغاز مي‌كنيم. بخش‌هاي «مبحث آموزشي مهندسي نرم‌افزار» كه در انتهاي اين فصل و چند فصل بعدي قرار داده شده‌اند، شما را به آساني وارد بحث شي‌گرايي خواهند كرد. نرم‌افزاري براي يك سيستم ماشين تحويل‌دار خودكار ATM ايجاد خواهيم كرد، كه تجربه مناسبي در زمينه طراحي و پياده‌سازي برايتان به ارمغان خواهد آورد. ضميمه‌اي در ارتباط با پياده‌سازي ATM با استفاده از تكنيك‌هاي برنامه‌نويسي شي‌گرا (OOP) در C++آورده شده است. بحث ما يك بحث كاملاً آموزشي است، و حالت تمريني ندارد و شما را كاملاً درگير جزئيات كار با كد C++ مي‌كند كه پياده‌سازي‌كننده برنامه هستند. اين مطالب شما را با انواع مسائل قابل توجه در صنايع و همچنين راه‌حل‌هاي موجود آشنا خواهند كرد.

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

مستند نيازها

فرض كنيد يك بانك محلي مايل است تا يك سيستم ATM جديد را بكار گيرد و به كاربران (مشتريان بانك) اجازه دهد تا تعاملات مالي خود را با آن انجام دهند (شكل 15-2). هر كاربر مي‌تواند فقط يك حساب در بانك داشته باشد. كاربران ATM بايد قادر به ديدن موجودي حساب، برداشت از حساب و پس‌انداز باشند.

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

· يك صفحه نمايش كه پيغام‌ها را به كاربر بنمايش درمي‌آورد

· يك صفحه كليد كه ورودي عددي را از كاربر دريافت مي‌نمايد

· تحويل‌دار خودكار كه پول را به كاربر تحويل مي‌دهد

· شكاف سپرده كه پاكت سپرده را از كاربر تحويل مي‌گيرد.

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

شكل 15-2 | واسط كاربر ATM.

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

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

در اولين برخورد، مشتري با ATM بايد توالي از رويدادهاي زير رخ دهند (به شكل 15-2 توجه نمائيد):

1- صفحة نمايش پيغام خوش‌آمدگويي (Welcome) را بنمايش درآورده و از كاربر مي‌خواهد تا شماره حساب خود را وارد سازد.

2- كاربر شماره حساب پنج‌رقمي خود را با استفاده از صفحه كليد وارد مي‌سازد.

3- در صفحه نمايش از كاربر خواسته مي‌شود تا PIN را وارد سازد، كه مرتبط با شماره حساب است.

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

5- اگر شماره حساب و PIN ورودي معتبر باشند، ظاهر صفحه نمايش همانند شكل 16-2 بوده و منوي اصلي در آن ظاهر مي‌گردد. اگر شماره حساب يا PINاشتباه باشد، پيغام مناسب در صفحه نمايش ظاهر شده و ATM به مرحله اول باز مي‌گردد تا فرآيند تاييد را از نو آغاز كند.

شکل 2 - 16

پس از تاييد كاربرد از سوي ATM، منوي اصلي (شكل 16-2) ليستي از گزينه‌هاي عددي براي هر سه نوع تراكنش بنمايش در مي‌آورد: درخواست موجودي (گزينه 1)، برداشت (گزينه 2) و سپرده‌گذاري (گزينه 3). همچنين منوي اصلي، گزينه‌اي براي خروج از سيستم در اختيار كاربر قرار مي‌دهد (گزينه 4). پس از نمايش منوي اصلي، كاربر مي‌تواند تراكنش موردرنظر خود را از طريق وارد كردن 1، 2، 3 يا خروج از سيستم، 4 انتخاب كند. اگر كاربر گزينه اشتباهي را وارد سازد، پيغامي به نمايش درخواهد آمد، و سپس مجدداً منوي اصلي بنمايش در مي‌آيد.

اگر كاربر گزينة 1 را انتخاب كند (با وارد كردن عدد 1) تا از ميزان موجودي خود مطلع گردد، اين امر صورت خواهد گرفت. براي انجام اين كار، بايستي ATM ميزان موجودي را از پايگاه داده بانك بازيابي كند.

مراحل زير زماني رخ مي‌دهند كه كاربر گزينه 2 را براي برداشت پول انتخاب كرده باشد:

6- منوي در صفحه نمايش ظاهر مي‌شود (شكل 17-2) كه حاوي مقادير استاندارد قابل پرداخت است. (گزينه 1) $20، (گزينه 2) $40، (گزينه 3) $60، (گزينه 4)، $100 و (گزينه 5) $200. همچنين اين منو داراي يك گزينه براي لغو تراكنش كاربر است (گزينه 6).

شكل 17-2 | منوي برداشت پول ATM.

7- كاربر با استفاده از صفحه كليد، انتخاب خود را انجام مي‌دهد (گزينه‌هاي6-1).

8- اگر مقدار درخواستي براي برداشت، بيشتر از ميزان موجودي كاربر باشد، پيغامي اين مطلب را به عرض كاربر رسانده و از وي مي‌خواهد كه مقدار كمتري تقاضا كند. سپس ATM به مرحله اول باز مي‌گردد. اگر مقدار درخواستي كمتر از موجودي يا برابر آن باشد (يك مقدار قابل قبول)، ATM مرحله 4 را آغاز خواهد كرد. اگر كاربر مبادرت به لغو تراكنش كند (گزينه 6)، ATM منوي اصلي را به نمايش در آورده و منتظر ورودي كاربر مي‌شود (شكل 16-2).

9- اگر پرداخت‌كننده خودكار پول، به ميزان كافي پول براي برآورده كردن تقاضاي مشتري داشته باشد، ATM وارد مرحله 5 خواهد شد. در غير اينصورت، صفحه نمايش پيغامي مبني بر اينكه ميزان پول دستگاه كمتر از مقدار درخواستي است از كاربر مي‌خواهد كه مقدار كمتري را انتخاب نمايد. سپس ATM به مرحله اول بازمي‌گردد.

10- ATM مقدار پول برداشتي را از موجودي حساب كاربر در پايگاه داده بانك كم مي‌كند.

11- پرداخت‌كننده خودكار، مقدار پول درخواستي را به كاربر تحويل مي‌دهد.

12- پيغامي در صفحه نمايش ظاهر شده و به كاربر يادآوري مي‌كند، پول را بردارد.

مراحل زير زماني رخ مي‌دهند كه كاربر عدد 3 را از منوي اصلي به منظور سپرده‌گذاري انتخاب كرده باشد:

13- در صفحه نمايش، به كاربر اعلان مي‌شود كه مقدار سپرده‌گذاري خود را وارد سازد يا براي لغو تراكنش صفر را وارد كند.

14- كاربر از طريق صفحه كليد، مقدار سپرده‌گذاري يا صفر را وارد مي‌سازد [نكته: صفحه كليد داراي نقطه اعشار يا نماد دلار نمي‌باشد، از اينرو، كاربر نمي‌تواند يك مقدار دلاري واقعي همانند $1.25 را وارد سازد. بجاي آن، كاربر بايد مقدار سپرده خود را بعنوان يك عدد از سنت‌ها وارد كند (مثلاً (125. سپس ATM اين عدد را بر 100 تقسيم مي‌كند، تا عددي كه نشاندهنده مقدار دلاري است بدست آيد (مثلاً (125÷100=1.25].

15- اگر كاربر ميزان سپرده را مشخص سازد، ATM به مرحله 4 مي‌رود. اگر كاربر، مبادرت به لغو تراكنش كند (با وارد كردن صفر)، ATM منوي اصلي را به نمايش درآورده و در انتظار ورودي كاربر باقي مي‌ماند (شكل 16-2)

16- در صفحة نمايش، پيغامي به كاربر اعلان مي‌كند كه پاكت سپرده را در شكاف سپرده قرار دهد.

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

پس از اجراي موفقيت‌آميز يك تراكنش توسط سيستم، بايد مجدداً منوي اصلي بنمايش درآيد (شكل 16-2) تا كاربر قادر به انجام تراكنش‌هاي ديگر باشد. اگر كاربر گزينه 4 را انتخاب كند (خروج از سيستم)، پيغام تشكر بنمايش درآمده و سپس پيغام خوش‌آمدگويي، براي كاربر بعدي بنمايش درمي‌آيد.

تحليل سيستم ATM

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

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

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

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

 شكل 18-2 | دياگرم حالت استفاده براي سيستم ATM از منظر كاربر.

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

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

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

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

شناسايي بازيگر در سيستم را با بررسي مستند نيازها مشخص مي‌كنيم كه عبارت است از "كاربران ATM بايستي قادر به مشاهده ميزان موجودي، برداشت پول و سپرده‌گذاري باشند." از اينرو، بازيگر در هر يك از اين سه حالت استفاده، كاربري است كه با ATM در تعامل قرار مي‌گيرد. موجوديت خارجي، يك شخص حقيقي، بخشي از نقش كاربر را در انجام تراكنش‌هاي مالي بازي مي‌كند. در شكل 18-2 يك بازيگر بنام «كاربر» نشان داده شده است. UML هر كداميك از حالات استفاده را بصورت يك بيضي متصل به بازيگر توسط يك خط ساده را مدل مي‌كند.

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

طراحي سيستم ATM

در اين بخش وارد مرحله طراحي سيستم ATM مي‌شويم. سيستم مجموعه‌اي از كامپونت‌ها است كه براي حل مسئله‌اي با هم در تعامل قرار مي‌گيرند. براي مثال، براي اينكه سيستم ATM وظايف تعيين شده را انجام دهد، بايد داراي يك واسط كاربر بوده (شكل 15-2) و حاوي نرم‌افزاري باشد كه قادر به انجام تراكنش‌هاي مالي و كار با پايگاه داده اطلاعات حساب مشتريان در بانك باشد. ساختار سيستم، توصيف‌كننده شي‌هاي سيستم و روابط داخلي آنها است. رفتار سيستم توصيف‌كننده نحوه تغيير عملكرد شي‌هاي سيستم و برقراري روابط بين آنها است. هر سيستمي داراي ساختار و رفتار است، كه طراحان بايد آنها را مشخص سازند. چندين نوع مشخص از ساختار و رفتار سيستم وجود دارد. براي مثال، تعامل مابين شي‌ها در يك سيستم، متفاوت از تعامل مابين سيستم و كاربر است، با اين همه هنوز هر دو بخشي از رفتار سيستم محسوب مي‌شوند. نسخه UML 2 تصريح‌كننده 13 نوع دياگرام براي مستند كردن مدل‌هاي سيستم است. هر دياگرام صفات مشخصي از ساختار سيستم يا رفتار آن را مدل‌سازي مي‌كند، شش دياگرام در ارتباط با ساختار سيستم بوده و هفت دياگرام باقيمانده مربوط به رفتار سيستم هستند. در اينجا فقط شش نوع دياگرام بكار رفته در اين مبحث را ليست كرده‌ايم، يكي از آنها بنام دياگرام كلاس، مبادرت به مدل كردن ساختار سيستم مي‌كند و مابقي در ارتباط با مدل‌سازي رفتار سيستم هستند.

1- دياگرام حالت استفاده، همانند شكل 18-2، مبادرت به مدل‌سازي تعامل صورت گرفته مابين سيستم و موجوديت خارجي آن (بازيگران) با جملات حالت استفاده مي‌كند (قابليت‌هاي سيستم همانند «نمايش ميزان موجودي»، «برداشت پول» و «سپرده‌گذاري»).

2- دياگرام‌هاي كلاس، كه در بخش 11-3 با آنها آشنا خواهيد شد. اين دياگرام‌ها در مدل كردن كلاس‌ها يا «ايجاد بلوك‌هاي» مورد استفاده در سيستم كاربرد دارند. هر اسم يا «چيز» توصيف شده در مستند نيازها، نامزد تبديل شدن به يك كلاس در سيستم است (همانند «حساب»، «صفحه كليد»). دياگرام‌هاي كلاس در مشخص كردن روابط ساختاري موجود مابين اجزاي سيستم نقش دارند. براي مثال، دياگرام كلاس سيستم ATM مشخص مي‌كند كه ATM به لحاظ فيزيكي متشكل از يك صفحه نمايش، صفحه كليد، تحويل‌دار خودكار پول و شكاف سپرده‌گذاري است.

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

4- دياگرام‌هاي فعاليت، كه در بخش 11-5 با آنها آشنا خواهيد شد. اين دياگرام‌ها در مدل‌سازي فعاليت يك شي كاربرد دارند (جريان كار يا روند كار يك شي (توالي از رويدادها) در مدت زمان اجراي برنامه). يك دياگرام فعاليت مبادرت به مدل كردن اعمال يك شي و همچنين ترتيب انجام اين اعمال را مشخص مي‌نمايد. براي مثال، يك دياگرام فعاليت نشان مي‌دهد كه ATM بايد ميزان موجودي حساب كاربر را (از پايگاه داده اطلاعات حساب) قبل از اينكه صفحه نمايش موجودي را بنمايش درآورد، تهيه نمايد.

5- دياگرام‌هاي ارتباطي (در نسخه‌هاي قبلي UML اين دياگرام، دياگرام‌هاي همكاري ناميده مي‌شود) مدل‌كننده تعامل‌هاي صورت گرفته‌ مابين شي‌هاي يك سيستم هستند، با تاكيد بر اينكه كدام تعامل رخ دهد. در بخش 12-7 با اين نوع دياگرام‌ها آشنا خواهيد. براي مثال بايد ATM با پايگاه داده حساب بانكي ارتباط برقرار كند تا ميزان موجودي را بازيابي نمايد.

6- دياگرام‌هاي توالي، اين دياگرام‌ها نيز مبادرت به مدل‌سازي تعامل‌هاي صورت گرفته مابين شي‌هاي يك سيستم مي‌كنند، اما برخلاف دياگرام‌هاي ارتباطي، تاكيد آنها بر زمان رخ دادن تعامل‌ها است. در بخش 12-7 با اين نوع دياگرام‌ها آشنا خواهيد شد. براي مثال، صفحه نمايش به كاربر اطلاع مي‌دهد كه مقدار پولي كه مي‌خواهد برداشت كند را قبل از پرداخت وارد نمايد.

در بخش 11-3 به ادامه طراحي ATM با شناسايي كلاس‌ها از طريق مستند نيازها ادامه خواهيم داد. اين كار را با استخراج اسامي كليدي و تعبير اسامي از مستند نيازها انجام خواهيم داد. با استفاده از اين كلاس‌ها، اولين پيش‌نويس خود را از دياگرام كلاس ايجاد مي‌كنيم كه ساختار سيستم ATM را مدل‌سازي مي‌كند.

اينترنت و منابع وب

www.306.ibm.com/software/rational/uml/

www.softdocwiz.com/Dictonary.htm

www-306.ibm.com/software/rational/offerings/design.html

www.embarcadero.com/products/describe/index.html

www.borland.com/together/index.html

www.ilogix.com/rhapsody/rhapsody.cfm

argouml.tigris.org

www.objectsbydesign.com/booklist.html

www.objectsbydesign.com/tools/umltools-bycompany.html

www.ootips.org/ood-principles.html

www.cetus-link.org100-uml.html

www.agilemodeling.com/essays/umlDiagrams.htm

كتاب‌هاي توصيه شده

كتاب‌هاي معرفي شده در اين بخش حاوي اطلاعاتي در ارتباط با طراحي شي‌گرا با UML هستند.

· Booch,G. Object-Oriented Analysis and Design with Applications, Third Edition. Addision-Wesly,2004.

· Eriksson,H.,et al. UML2 Toolkit.NewYork:John Wiley,2003.

· Kruchten,P.The Rational Unified Process:An Introduction.Boston: Addison-Wesley, 2004.

· Lorman,C.Applying UML and Patterns:An Introduction to object. Oriented Analysis and Design, Second Edition.Upper Saddle River, NT:Prentice Hall, 2002.

· Roques,P.UML in Practical:The Art of Modeling Software Systems Demonstrated through worked Examples and solutions.NewYork:John wiley,2004.

· Rosenberg,D.,and K.Scott.Applying use Case Driven Object Modeling withUML:An Anstated e-Commerce Example.Reading,MA:Addison-Wesley, 2001.

· Rumbaugh,J.,I.Jacobson and G.Booch.The Complete UML Training Course.Upper Saddle River,NS:Prentice Hall,2000.

· Rumbaugh,J.,I.Jacobson and G. Booch. The unified Modeling Language Reference Manual. Reading, MA: Addison-Wesley,1999.

· Rumbaugh,J.,I.Jacobson an g.Booch.The unified Software Development Process. Reading, MA: Addison-Wesley,1999.