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

نکاتی دیگر در ارتباط توابع set

یک تابع publicset همانند setCourseName بایستی بدقت مراقب هرگونه تغییر در مقدار یک عضو داده (همانند courseName) باشد تا مطمئن گردد که مقدار جدید مناسب این ایتم داده است. برای مثال، مبادرت به تنظیم روزی از ماه به ۳۷ نبایستی قبول شود، مباردت به تنظیم وزن یک شخص با صفر یا مقدار منفی برای آن نبایستی پذیرفته شود یا در صورتیکه حداکثر امتیاز یا نمره شخصی می تواند بین صفر تا ۱۰۰ باشد، نبایستی امتیاز ۱۸۵ تایید شود.

تابع publicset

توابع set یک کلاس می توانند مقادیری به سرویس‌گیرنده‌های کلاس برگشت دهند تا نشان دهند که مبادرت به تخصیص یک داده نامعتبر به شی از کلاس شده است. سرویس‌گیرنده کلاس می تواند مبادرت به تست مقدار برگشتی از یک تابع set کند تا تعیین نماید که آیا عملیات اصلاح یا تغییر در شی موفقیت‌آمیز بوده است یا خیر و در هر دو حالت کار مقتضی را انجام دهد. در فصل ۱۶ به بررسی نحوه اطلاع‌دهی ؛ سرویس‌گیرنده‌های کلاس از طریق مکانیزم رسیدگی به استثناء خواهیم پرداخت. برای اینکه برنامه ۱۵-۳ الی ۱۷-۳ را فعلاً در یک سطح ساده نگهداری کنیم، تابع setCourseName در برنامه ۱۶-۳ فقط مبادرت به چاپ پیغام‌ مقتضی در صفحه نمایش می کند.

۱۱-۳ مبحث آموزشی مهندسی نرم‌افزار: شناسایی کلاس‌های موجود در مستند نیازهای ATM

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

 

شناسایی کلاس‌ها در سیستم

فرآیند OOD خود را با شناسایی کلاس‌های مورد نیاز در ایجاد یک سیستم ATM آغاز می کنیم. سرانجام این کلاس‌ها را با استفاده از دیاگرام‌های کلاس UML و پیاده‌سازی این کلاس‌ها در C++ توصیف خواهیم کرد. ابتدا، نگاهی به مستند نیازها در بخش ۸-۲ می اندازیم تا اسامی و اصطلاحات کلیدی را که میتوانند به ما در شناسایی کلاس‌های که در ایجاد سیستم ATM نقش دارند، پیدا کنیم. امکان دارد تصمیم بگیریم که برخی از این اسامی و اصطلاحات جزو صفات کلاس‌های دیگر در سیستم باشند. همچنین می توانیم استنتاج ‌کنیم که برخی از اسامی ارتباطی با بخش‌های سیستم ندارند و نیازی نیست که آنها را مدل‌سازی نمائیم. کلاس‌های اضافی می توانند میزان حرکت ما را در فرآیند طراحی آشکار کنند.

جدول شکل ۱۸-۳ لیستی از اسامی و اصطلاحات موجود در مستند‌ نیازها را به نمایش در آورده است. در این لیست ترتیب از سمت چپ به راست و با توجه به ظاهر شدن این اسامی در مستند نیازها است.

شکل ۱۸-۳ | اسامی و اصطلاحات موجود در مستند نیازها.

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

نیازی به مدل کردن «اسکناس ۲۰ دلاری» یا «پاکت سپرده» بعنوان کلاس نیست. این موارد شی های فیزیکی در دنیای واقعی هستند، اما بخشی از فرآیند اتوماتیک‌سازی نمی باشند. می توانیم بقدر کفایت اسکناس را در سیستم با استفاده از صفات کلاسی که پرداخت‌کننده یا تحویل‌دار اتوماتیک را مدل می کند، عرضه کنیم. در بخش ۱۳-۴ به تخصیص صفات به کلاس‌ها خواهیم پرداخت. برای مثال، تحویل‌دار اتوماتیک مبادرت به نگهداری تعدادی اسکناس در خود می کند. مستند نیازها چیزی در ارتباط با کاری که سیستم باید با پاکت سپرده‌ها پس از دریافت آنها انجام دهد، بیان نمیکند. می توانیم فرض کنیم که فقط تایید وصول پاکت صورت میگیرد، عملیاتی که توسط کلاس مدل شده برای شکاف سپرده انجام می شود. در بخش ۲۲-۶ با نحوه تخصیص عملیات به کلاس‌ها آشنا خواهید شد.

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

با وجود آنکه در مستند نیازها کلمه “تراکنش” بصورت کلی بکار گرفته شده است، اما فعلاً قصد مدل کردن این مفهم کلی در تراکنش مالی را نداریم. بجای آن سه نوع تراکنش (“نمایش موجودی”، “برداشت پول” و “سپرده”) را بعنوان کلاس‌های مجزا مدل می کنیم. این کلاس‌ها دارای صفات خاص مورد نیاز برای انجام تراکنش‌های متعلق بخود را دارا هستند. برای مثال، کلاس برداشت پول نیاز به داشتن میزان پولی دارد که کاربر می خواهد برداشت کند. با این وجود، کلاس موجودی، نیازی به داده‌های اضافی ندارد. علاوه بر اینها، سه کلاس تراکنشی رفتارهای منحصر به فردی را در معرض دید قرار می دهند. کلاس برداشت پول شامل پرداخت پول به کاربر است، در حالیکه سپرده‌گذاری مستلزم دریافت پاکت سپرده‌گذاری از سوی کاربر است. [نکته: در بخش ۱۰-۱۳، مبادرت به فاکتورگیری ویژگی های مشترک از تمام تراکنش‌ها بصورت یک کلاس «تراکنش» کلی خواهیم کرد. با استفاده از مفهوم کلاس‌های انتزاعی و توارث در برنامه‌نویسی شی گرا.]

کلاس‌های مورد نیاز سیستم را بر پایه اسامی و اصطلاحات موجود در جدول ۱۸-۳ تعیین می کنیم. هر کدامیک از این اسامی به یک یا چند مورد از عبارات زیر مراجعه دارند:

• ATM
• صفحه نمایش
• صفحه کلید
• تحویل‌دار اتوماتیک
• شکاف سپرده‌گذاری
• حساب
• پایگاه داده بانک
• نمایش موجودی (درخواست موجودی)
• برداشت پول
• سپرده‌گذاری

عناصر موجود در این لیست از قابلیت تبدیل شدن به کلاس‌های مورد نیاز در پیاده‌سازی سیستم ATM برخوردار هستند. اکنون می توانیم شروع به مدلسازی کلاس‌ها در سیستم خود بر پایه لیست فوق کنیم. اسامی کلاس‌ها را در فرآیند طراحی با حروف بزرگ نشان می دهیم (قاعده UML)، همین کار را به هنگام پیاده‌سازی طراحی به زبان C++ انجام خواهیم داد. اگر نام کلاسی بیش از یک کلمه باشد، کلمات را در کنار هم قرار میدهیم و هر کلمه را با حرف بزرگ شروع می کنیم (مثلاً Multiple WordName). با استفاده از این روش، مبادرت به ایجاد کلاس‌های ATM، Screen (صفحه نمایش)، صفحه‌کلید (Keypad)، تحویل‌دار خودکار یا پرداخت‌کننده پول (CashDispencer)، شکاف‌ سپرده‌ (DepositSlot)، حساب (Account)، پایگاه داده بانک (BankDatabase)، پرس‌وجوی میزان موجودی (BalanceInquiry)، برداشت پول (Withdrawal) و سپره (Deposit). سیستم خود را با استفاده از تمام این کلاس‌ها بعنوان بلوک‌های سازنده ایجاد خواهیم کرد. قبل از شروع به ایجاد بلوک‌های سازنده سیستم، بایستی درک مناسبی از روابط مابین کلاس‌ها بدست آوریم.

مدل‌سازی کلاس‌ها

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

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

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

در شکل ۲۰-۳، خط مستقیم و یکپارچه دو کلاس را به هم پیوند زده، نشاندهنده یک وابستگی است (رابطه مابین کلاس‌ها). اعداد قرار گرفته در انتهای خط مقادیر تعدد هستند که نشان میدهند که چند شی از هر کلاس در وابستگی (رابطه) شرکت یا دخالت دارند.

شکل ۱۹-۳ | نمایش کلاس در UML با استفاده از دیاگرام کلاس.

 

شکل ۲۰-۳ | دیاگرام‌های کلاس در حال نمایش وابستگی مابین کلاس‌ها.

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

شکل ۲۱-۳ | انواع تعدد.

وابستگی میتواند نام داشته باشد. برای مثال، کلمه Executes در بالای خط متصل‌کننده کلاس‌های ATM و Withdrawal در شکل ۲۰-۳ نشان‌دهنده نام این وابستگی (ارتباط) است. این بخش از دیاگرام بصورت زیر معنی می‌شود، “یک شی از کلاس ATM صفر یا یک شی از کلاس Withdrawal را به اجرا در می آورد.” توجه نمایید که اسامی وابستگی، حالت هدایت‌کننده و نشان‌دهنده جهت هستند، همانند جهت فلش توپر، از اینرو جهت تفسیر دیاگرام مهم است، در صورتی که برای مثال تفسیر را از سمت راست به چپ انجام دهیم، جمله‌ای به این مضمون خواهیم داشت “صفر یا یک شی از کلاس Withdrawal یک شی از کلاس ATM را به اجرا درمی آورد.”

کلمه currentTransaction در کنار و زیرخط وابستگی Withdrawal در شکل ۲۰-۳، نام یک نقش (role) است، که هویت‌دهنده نقشی است که شی Withdrawal در رابطه خود با ATM بازی میکند. نام نقش، هدف و منظوری را به رابطه مابین‌ کلاس‌‌ها اضافه میکند، و اینکار را با شناسایی نقشی که کلاس در بافت رابطه ایفاء میکند، انجام میدهد. یک کلاس میتواند چندین نقش در همان سیستم بازی کند. برای مثال، در یک سیستم پرسنلی دانشگاه یک نفر میتواند نقش یک «پورفسور» را به هنگام رابطه داشتن با دانشجویان بازی کند. امکان دارد همان شخص نقش «همکار» در کنار پورفسور دیگر و نقش «مربی» را به هنگام مسابقات دانشجویی بازی کند. در شکل ۲۰-۳، نام نقش currentTransaction بر این نکته دلالت دارد که شی Withdrawal در اجرای (Executes) رابطه با یک شی از کلاس ATM دخالت دارد و این کلاس در پردزاش تراکنش جاری عمل میکند. در سایر محیط‌ها امکان دارد یک شی Withdrawal نقش‌های متفاوتی بخود گیرد. زمانیکه مفهوم رابطه در دیاگرام به قدر کافی گویا باشد، از اسامی نقش در دیاگرام‌های کلاس استفاده نمیشود.

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

در شکل ۲۲-۳ لوزی های توپر متصل شده به خطوط وابستگی کلاس ATM بر این نکته دلالت دارند که کلاس ATM دارای یک رابطه ترکیبی با کلاس‌های Screen، Keypad، CashDispenser و DepositSlot است. ترکیب مفهومی از یک رابطه کامل/بخش (قطعه) است. کلاسی که دارای نماد ترکیب (لوزی توپر) در انتها خط وابستگی خود می باشد، کامل بوده (در این مورد ATM) و کلاس‌های قرار گرفته در آن سوی خطوط وابستگی، بخش یا قطعه میباشند، در این مورد کلاس‌های Screen، Keypad، CashDispenser و DepositSlot. ترکیب بنمایش درآمده در شکل ۲۲-۳ نشان میدهد که یک شی از کلاس ATM از یک شی از کلاس Screen، یک شی از کلاس CashDispenser، یک شی از کلاس Keypad و یک شی از کلاس DepositSlot تشکیل یافته است. ATM «دارای» یک صفحه نمایش، یک صفحه‌کلید، یک تحویل‌دار خودکار و شکاف سپرده است. رابطه «داشتن» تعریف‌کننده ترکیب است. در فصل سیزدهم نشان خواهیم داد که رابطه «است یک» تعریف‌کننده توارث است.

بر طبق مشخصات UML، رابطه ترکیب دارای خصوصیات زیر است:

۱- فقط یک کلاس در رابطه میتواند نشاندهنده رابطه کامل باشد (لوزی میتواند فقط در انتهای یک طرف خط وابستگی قرار گرفته باشد). برای مثال خواه صفحه نمایش بخشی از ATM باشد یا ATM بخشی از صفحه نمایش باشد، صفحه نمایش و ATM هر دو نمیتوانند نشاندهنده رابطه کامل (سراسری) باشند.

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

۳- یک قطعه میتواند فقط در یک زمان متعلق به یک رابطه کامل باشد، اگر چه امکان دارد قطعه‌ای حذف و به رابطه کامل دیگری متصل گردد.

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

شکل ۲۲-۳ | دیاگرام کلاس نشاندهنده رابطه ترکیب.

در شکل ۲۳-۳ نمایشی از دیاگرام کلاس سیستم ATM ارائه شده است. این دیاگرام اکثر کلاس‌هایی که در ابتدای این بخش شناسایی کرده بودیم را به همراه وابستگی مابین آنها را که از مستند نیازها استتناج کرده‌ایم، مدل کرده است. [نکته: کلاس‌های BalanceInquiry و Deposit در رابطه مشابهی با کلاس Withdrawal شرکت دارند، از اینرو برای حفظ سادگی دیاگرام، آنها را در نظر نگرفته‌ایم. در فصل ۱۳، دیاگرام کلاس را گسترش داده و تمام کلاس‌های موجود در سیستم ATM را وارد آن میکنیم.]

شکل ۲۳-۳ نمایشی از مدل گرافیکی ساختار سیستم ATM است. این دیاگرام کلاس حاوی کلاس‌های BankDatabase و Account و چندین رابطه (وابستگی) است که در شکل‌های ۲۰-۳ یا ۲۲-۳ عرضه نشده بودند. دیاگرام کلاس نشان میدهد که کلاس ATM دارای یک رابطه یک به یک با کلاس BankDatabase است، یک شی ATM مبادرت به تصدیق کاربران در برابر یک شی BankDatabaseBankDatabase در یک رابطه ترکیبی با صفر یا چندین شی از کلاس Account شرکت دارد. از جدول ۲۱-۳ بخاطر دارید که مقدار تعدد یا کثرت ۰..* در سمت وابستگی Account مابین کلاس BankDatabase و کلاس Account بر این نکته دلالت دارد که صفر یا چندین شی از کلاس Account بخشی در رابطه را تشکیل میدهند. کلاس BankDatabase دارای رابطه یک به چند با کلاس Account است. BankDatabase مبادرت به ذخیره‌ حساب‌های (accounts) متعدد در خود میکند. به همین ترتیب، کلاس Account دارای رابطه چند به یک با کلاس BankDatabase است، چرا که حساب‌های متعدد در پایگاه داده بانک (bank database) ذخیره میشوند. [نکته: از جدول شکل ۲۱-۳ بخاطر دارید که مقدار * معادل با ۰..* است. برای افزایش وضوح دیاگرام‌های کلاس از نماد ۰..* استفاده کرده‌ایم.] میکند. همچنین در شکل ۲۳-۳، مبادرت به مدل کردن این واقعیت کرده‌ایم که پایگاه بانک حاوی اطلاعاتی در ارتباط با حساب‌های متعدد است، یک شی از کلاس

شکل ۲۳-۳ | دیاگرام کلاس برای مدل کردن سیستم ATM.

همچنین شکل ۲۳-۳ نشان میدهد که اگر کاربر مبادرت به برداشت پول کند، «یک شی از کلاس Withdrawal به موجودی حساب دسترسی پیدا کرده/آنرا از طریق یک شی از کلاس BankDatabaseWithdrawal و کلاس Account ایجاد کنیم. با این وجود، مستند نیازها شرح میدهد که «ATM باید با پایگاه داده اطلاعات حساب بانک در تعامل قرار داشته باشد» تا تراکنش‌ها قابل انجام باشند. حساب بانکی حاوی اطلاعات حساس بوده و مهندسان سیستم بایستی همیشه مراقب امنیت داده افراد به هنگام طراحی سیستم باشند. از اینرو، فقط BankDatabase میتواند مبادرت به دسترسی و اعمال تغییر مستقیم در یک حساب کند. تمام قسمت‌های دیگر سیستم باید با پایگاه داده در تعامل قرار گیرند تا بتوانند اطلاعاتی بدست آورده یا حساب را به روز نمایند. تغییر می دهد.» میتوانیم یک رابطه مستقیم مابین کلاس

همچنین دیاگرام کلاس در شکل ۲۳-۳ مبادرت به مدل کردن رابطه موجود مابین کلاس Withdrawal و کلاس‌های Screen، CashDispenser و Keypad میکند. تراکنش برداشت پول شامل اعلان پیغامی به کاربر برای تعیین میزان پول برداشتی و دریافت ورودی عددی است. این اعمال به ترتیب مستلزم استفاده از صفحه نمایش و صفحه کلید است. علاوه بر اینها، پرداخت پول نقد به کاربر مستلزم دسترسی به تحویل‌دار خودکار (پرداخت‌کننده پول خودکار) می باشد.

کلاس‌های BalanceInquiry و Deposit که در شکل ۲۳-۳ آورده نشده‌اند، دارای چندین رابطه با کلاس‌های دیگر در سیستم ATM هستند. همانند کلاس Withdrawl، هر کدامیک از این کلاس‌ها با کلاس‌هایATM و BankDatabase دارای رابطه (وابستگی) هستند. یک شی از کلاس BalanceInquiry دارای رابطه‌ای با یک شی از کلاس Screen برای نمایش میزان موجودی در حساب یک کاربر نیز است. کلاس Deposit با کلاس‌های Screen، Keypad و DepositSlot در ارتباط است. همانند برداشت پول، تراکنش سپرده‌گذاری مستلزم استفاده از صفحه‌نمایش و صفحه‌کلید برای نمایش پیغامی به کاربر و دریافت ورودی است. برای دریافت پاکت سپرده، یک شی از کلاس Deposit به شکاف سپرده دسترسی پیدا میکند.

اکنون کلاس‌های موجود در سیستم ATM خود را شناسایی کرده‌ایم. در بخش ۱۳-۴ به تعیین صفات هر کدامیک از این کلاس‌ها خواهیم پرداخت. در بخش ۱۱-۵ از این صفات برای بررسی نحوه تغییر عملکرد سیستم در زمان استفاده می کنیم. در بخش ۲۲-۶ به تعیین عملیاتی که کلاس‌ها در سیستم انجام خواهند داد، میپردازیم.

 

---