case study for atm management system

Cybermedian

Learning one new thing everyday

Use Case Modeling for an ATM System: A Comprehensive Guide and Case Study

Introduction.

This case study focuses on the use case modeling of an ATM system for a bank. The ATM system is designed to provide customers with a convenient way to access their accounts and perform various banking transactions, such as withdrawing cash, depositing cash, transferring funds, checking their account balance, and changing their PIN. The case study discusses the problem description and requirements of the system, as well as the use case diagrams, actors, and scenarios that were created to model the system’s functionality. The case study also explores how other types of UML diagrams, such as activity diagrams and sequence diagrams, can be used in conjunction with use case diagrams to provide a more detailed view of the system’s behavior and interactions. By the end of the case study, readers will have a clear understanding of the use case modeling process and how it can be applied to real-world systems such as an ATM system.

什麼是用例圖？Use Case Diagram - Learn it, Try it! | 學習EA, Agile & UML 和使用Visual Paradigm 技能- 點部落

Guidelines and Tips for Developing Effective Use Cases and Writing Proper Use Case Scenarios

Here are some guidelines, tips, and tricks for developing use cases and writing proper use case scenarios:

Identify the actors: Begin by identifying the actors who will interact with the system. This could include users, administrators, and any other stakeholders who will use the system.
Define the system’s scope: Clearly define the scope of the system and what it is meant to accomplish. This will help ensure that the use case scenarios capture all necessary requirements.
Use a structured approach: Use a structured approach to develop the use case scenarios. This could include using templates or guidelines to ensure that each scenario follows a consistent structure.
Write clear and concise scenarios: Write use case scenarios that are clear, concise, and easy to understand. Use plain language and avoid technical jargon or acronyms that may not be familiar to all stakeholders.
Use action-oriented language: Write use case scenarios using action-oriented language that describes what the user or system is doing. This can help ensure that the scenarios are easy to understand and follow.
Focus on user goals and needs: Focus on the user’s goals and needs when developing use case scenarios. This will help ensure that the scenarios capture the user’s perspective and are aligned with their needs.
Identify pre-conditions and post-conditions: Clearly identify any pre-conditions and post-conditions that must be met for the scenario to be successful. This will help ensure that the scenario is complete and accurate.
Include exception scenarios: Identify any exception scenarios that may occur and include them in the use case scenarios. This will help ensure that the system can handle unexpected situations and errors.
Get feedback and review: Get feedback from stakeholders and review the use case scenarios regularly to ensure that they remain accurate and up-to-date with the latest system specifications and requirements.

By following these guidelines, tips, and tricks, developers can develop use case scenarios that accurately capture the system’s functionality and meet the needs of all stakeholders.

Problem Description of the Case Study – ATM

A bank needs to provide its customers with a convenient way to access their accounts and perform various banking transactions, such as withdrawing cash, depositing cash, transferring funds, checking their account balance, and changing their PIN. To address this problem, the bank plans to implement an ATM system that allows customers to perform these transactions using their ATM cards and a PIN.

Requirements:

Security: The ATM system must ensure the security of customer transactions by verifying the customer’s identity using their ATM card and PIN. The system must prevent unauthorized access to customer accounts and must be protected against various forms of fraud and attack, such as skimming and hacking.
Availability: The ATM system must be available to customers at all times, subject to periodic maintenance and downtime. The system must be reliable and resilient to hardware and software failures to minimize service disruptions and ensure a high level of customer satisfaction.
Usability: The ATM system must be easy to use and navigate for customers of all ages and backgrounds. The system must provide clear instructions and feedback to guide customers through the transaction process and minimize errors and confusion.
Transaction processing: The ATM system must process customer transactions accurately and efficiently, including withdrawing and depositing cash, transferring funds, checking account balances, and changing PINs. The system must maintain accurate records of all transactions and provide customers with receipts and other documentation as needed.
Integration: The ATM system must integrate with the bank’s existing IT infrastructure, including its core banking system, network, and databases. The system must communicate securely and reliably with other systems and components to ensure accurate and timely processing of transactions and account information.

Use Case Modeling and Use Case Scenario Development

Starting with the problem description of an ATM system, the next step is to identify the various use cases that are required to fulfill the needs of the system’s users. This involves analyzing the system’s requirements and defining the specific actions that users can take when interacting with the system. Each use case will have its own set of scenarios that describe how the system and user will interact in specific situations. These scenarios should be developed in a structured manner, using clear and concise language to ensure they are easily understandable by all stakeholders involved in the project.

The process of identifying use cases and developing use case scenarios is a critical step in the software development life cycle. It enables the development team to fully understand the requirements of the system and to design a solution that meets the needs of its users. As the development process progresses, it may be necessary to refine the use cases and scenarios to reflect changes in the requirements or to incorporate feedback from stakeholders. This iterative process helps to ensure that the final system meets the needs of all stakeholders and is capable of handling a wide range of scenarios and use cases.

Use Case Diagram:

The use case diagram for an ATM system could include the following actors:

And the following use cases:

Withdraw Cash
Deposit Cash
Check Balance
Transfer Funds

The diagram would show the relationships between the actors and use cases, indicating which use cases are accessible by which actors.

Use Case Scenarios:

a) Withdraw Cash:

The customer inserts their ATM card into the machine.
The system prompts the customer to enter their PIN.
The customer enters their PIN.
The system verifies the PIN.
The customer selects the “Withdraw Cash” option.
The system prompts the customer to enter the amount of cash they wish to withdraw.
The customer enters the amount of cash.
The system dispenses the cash.
The customer removes their ATM card and takes the cash.

b) Deposit Cash:

The customer selects the “Deposit Cash” option.
The system prompts the customer to enter the amount of cash they wish to deposit.
The system verifies the amount and displays it to the customer.
The customer confirms the amount.
The system accepts the cash and credits the customer’s account.

c) Check Balance:

The system displays the customer’s account balance.

d) Transfer Funds:

The customer selects the “Transfer Funds” option.
The system prompts the customer to enter the account number to which they wish to transfer funds.
The customer enters the account number.
The system prompts the customer to enter the amount of funds they wish to transfer.
The customer enters the amount of funds.
The system transfers the funds and displays a confirmation message to the customer.

e) Change PIN:

The system prompts the customer to enter their current PIN.
The customer enters their current PIN.
The system verifies the current PIN.
The system prompts the customer to enter their new PIN.
The customer enters their new PIN.
The system prompts the customer to confirm their new PIN.
The customer confirms their new PIN.
The system updates the customer’s PIN and displays a confirmation message.

Refining Use Case Scenario – Withdraw Cash

Refining a use case scenario as the development process progresses forward is important for several reasons:

To ensure that the scenario is accurate and reflects the current state of the system: As the development process moves forward, the system may change, and new requirements may emerge. Refining the use case scenario helps ensure that it remains accurate and up-to-date with the latest system specifications.
To identify any missing or incomplete requirements: As the system evolves, it may become apparent that additional requirements are needed to fully capture the system’s functionality. Refining the use case scenario helps identify any missing or incomplete requirements.
To improve usability and user experience: Refining the use case scenario can help improve the usability and user experience of the system. By refining the scenario, developers can better understand the user’s needs and make design decisions that better meet those needs.

The process of refining a use case scenario can involve several steps, including:

Reviewing the scenario for accuracy and completeness: Developers should review the scenario to ensure that it accurately reflects the current state of the system and that all requirements are captured.
Identifying any missing or incomplete requirements: Developers should identify any missing or incomplete requirements and work to incorporate them into the scenario.
Refining the user interface: Developers should refine the user interface to improve usability and user experience, taking into account user feedback and design best practices.
Incorporating feedback: Developers should incorporate feedback from stakeholders and users to refine the scenario and ensure that it meets the needs of all users.

Steps to Refine a Use Case Scenario

By continually refining the use case scenario throughout the development process, developers can ensure that the system meets user needs and requirements and is as usable and user-friendly as possible.

Here’s an elaboration of the “Withdraw Cash” scenario for the ATM system, including normal and exception flows and insertion points to reflect a real-life scenario:

Scenario: Withdraw Cash

Primary Actor: Customer

Preconditions:

The customer has inserted their ATM card into the machine.
The customer has entered their correct PIN.

Basic Flow:

The customer selects the “Withdraw Cash” option from the main menu.
The ATM prompts the customer to enter the amount of cash they wish to withdraw.
The customer enters the amount of cash they wish to withdraw.
The ATM verifies that the customer has sufficient funds in their account to cover the withdrawal amount.
The ATM dispenses the requested cash to the customer.
The ATM displays a message confirming the successful withdrawal and prompts the customer to select another transaction or end the session.
The customer selects another transaction or ends the session.
The ATM ejects the customer’s ATM card.

Exception Flows:

1a. Insufficient Funds

The ATM verifies that the customer has insufficient funds in their account to cover the withdrawal amount.
The ATM displays an error message informing the customer that they do not have sufficient funds to complete the transaction.
The ATM prompts the customer to either enter a smaller withdrawal amount or cancel the transaction.
The customer either enters a smaller withdrawal amount or cancels the transaction.

2a. Invalid Amount

The customer enters an invalid withdrawal amount, such as a negative number or a value that exceeds their daily withdrawal limit.
The ATM displays an error message informing the customer that the amount entered is invalid.
The ATM prompts the customer to enter a valid withdrawal amount.
The customer enters a valid withdrawal amount.

3a. Card Retained

The ATM fails to dispense the cash due to a hardware or software error.
The ATM displays an error message informing the customer that their card has been retained.
The ATM prompts the customer to contact their bank or customer service for assistance.
The customer contacts their bank or customer service to retrieve their card.

Insertion Points:

After step 1: The customer inserts their ATM card into the machine and enters their PIN.
After step 2: The customer enters the amount of cash they wish to withdraw.
After step 3: The ATM verifies that the customer has sufficient funds to cover the withdrawal amount.
After step 5: The ATM dispenses the requested cash to the customer.

Appendix – Refined Use Case Scenarios – ATM

Use Case Name: Withdraw Cash

Actors: Customer, ATM

Preconditions: The customer must have a valid ATM card and PIN number. The ATM must be functioning properly and connected to the banking network.

The customer inserts their ATM card into the card reader slot on the ATM.
The ATM prompts the customer to enter their PIN number using the keypad.
The customer enters their PIN number.
The ATM validates the PIN number and displays the main menu options.
The customer selects the “Withdraw Cash” option from the menu.
The ATM prompts the customer to enter the amount of cash they wish to withdraw using the keypad.
The ATM validates that the customer has sufficient funds in their account to complete the transaction.
The ATM dispenses the requested cash amount to the customer.
The ATM displays a message indicating that the transaction is complete.
The customer removes their ATM card from the card reader slot.

Alternative Flows:

1a. If the ATM is unable to read the customer’s ATM card, the ATM displays an error message and prompts the customer to try again or contact their bank.
4a. If the customer enters an incorrect PIN number three times, the ATM will retain their card and display a message indicating that it has been retained.
8a. If the customer does not have sufficient funds in their account to complete the transaction, the ATM displays an error message and prompts the customer to enter a smaller amount or cancel the transaction.

Use Case Name: Check Account Balance

The customer selects the “Check Account Balance” option from the menu.
The ATM displays the customer’s current account balance on the screen.

Use Case Name: Deposit Cash

The customer selects the “Deposit Cash” option from the menu.
The ATM prompts the customer to insert the cash they wish to deposit into the cash deposit slot on the ATM.
The customer inserts the cash into the deposit slot.
The ATM validates the cash and displays a message indicating the amount of cash that has been deposited.

References: Use Case Modeling Techniques

What is Use Case Specification?
A Practical Tutorial on Robustness Analysis
Identify User Requirements with Use Case Diagrams
User Story vs Use Case for Agile Software Development
Use Case Driven Approach for Agile Development
Types of Actor in Use Case Model
What is Use Case Diagram?
What is UML?
Why UML Modeling?

Use Case Diagram for ATM Machine

The ATM Machine Use Case Diagram is one way that the steps of how an ATM works are shown. It shows how the system is thought to be set up to work. The diagram also has processes (use cases) and users, also called “actors.” It uses defined symbols to show how the whole system works.

Project Overview


:
:	Any Diagram tools that provide use case diagram symbols.
:	ITSourceCode.com

What is a Use Case Diagram?

Importance of uml use case.

One important thing about the UML use case diagram for ATM is that it helps developers and businesses manage their systems. It shows the steps from the users’ point of view.

ATM Machine System Use Case Diagram

Atm system general use case diagram.

The general use case diagram for ATM machines shows the main functions of the system. It is based on the transactions done during ATM management.

Use Case Diagram for ATM System using Include and Extend

The use case diagram using include and extend is used to elaborate the proceeding diagrams.

The label include indicates that the sub-processes of the main processes must be included to complete the task, extend is otherwise.

Manage Customers’ Information and Status Use Case Diagram

Manage atm applicants’ information use case diagram, manage withdrawing and saving transaction.

This is the process where the bank/system admin processes their customer’s info to let them avail the bank and ATM services.

Use Case Diagram for ATM Machine System Pdf

How to draw a use case diagram.

Here’s the complete guide on how to draw a use case diagram for ATM system.

The next step is to determine the system’s processes. They will be the use cases of your project. You may ask the users about the typical activities done in the ATM machine.

The system development process is shown by the UML use case diagram. It helps developers figure out what kinds of inputs the project could get and what it should do with them. Also, the diagram can be used to model how the software’s use cases work (processes). It shows how one process leads to the next in the system.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

Notifications You must be signed in to change notification settings

ATM Case Study: Implementing an Object-Oriented Desing with Java

VictorFantucci/ATM_System

Folders and files.

Name		Name
18 Commits

Repository files navigation

Case Study from: © 2012 Pearson Education, Inc., Upper Saddle River, NJ. All Rights Reserved.

Examining the ATM Requirements Document:

We begin our design process by presenting a requirements document that specifies the ATM system’s overall purpose and what it must do. Throughout the case study, we refer to the requirements document to determine what functionality the system must include.

Requirements Document: A local bank intends to install a new automated teller machine (ATM) to allow users (i.e., bank customers) to perform basic financial transactions (Fig. 25.1). Each user can have only one account at the bank. ATM users should be able to view their account balance, withdraw cash (i.e., take money out of an account) and deposit funds (i.e., place money into an account).

Fig. 25.1 | Automated teller machine user interface.

The user interface of the automated teller machine contains the following hardware components:

a screen that displays messages to the user
a keypad that receives numeric input from the user
a cash dispenser that dispenses cash to the user and
a deposit slot that receives deposit envelopes from the user.

The cash dispenser begins each day loaded with 500 $20 bills. [Note: Owing to the limited scope of this case study, certain elements of the ATM described here do not accurately mimic those of a real ATM. For example, a real ATM typically contains a device that reads a user’s account number from an ATM card, whereas this ATM asks the user to type an account number using the keypad. A real ATM also usually prints a receipt at the end of a session, but all output from this ATM appears on the screen.]

The bank wants you to develop software to perform the financial transactions initiated by bank customers through the ATM. The bank will integrate the software with the ATM’s hardware at a later time. The software should encapsulate the functionality of the hardware devices (e.g., cash dispenser, deposit slot) within software components, but it need not concern itself with how these devices perform their duties. The ATM hardware has not been developed yet, so instead of writing your software to run on the ATM, you should develop a first version of the software to run on a personal computer. This version should use the computer’s monitor to simulate the ATM’s screen, and the computer’s key- board to simulate the ATM’s keypad.

An ATM session consists of authenticating a user (i.e., proving the user’s identity) based on an account number and personal identification number (PIN), followed by creating and executing financial transactions. To authenticate a user and perform transactions, the ATM must interact with the bank’s account information database. [Note: A database is an organized collection of data stored on a computer.] For each bank account, the database stores an account number, a PIN and a balance indicating the amount of money in the account. [Note: For simplicity, we assume that the bank plans to build only one ATM, so we do not need to worry about multiple ATMs accessing this database at the same time. Furthermore, we assume that the bank does not make any changes to the information in the database while a user is accessing the ATM. Also, any business system like an ATM faces reasonably complicated security issues that go well beyond the scope ofa first- or second- semester computer science course. We make the simplifying assumption, however, that the bank trusts the ATM to access and manipulate the information in the database without significant security measures.]

Upon first approaching the ATM, the user should experience the following sequence of events (shown in Fig. 25.1):

The screen displaysa welcome message and prompts the user to enter an account number.

The user enters a five-digit account number, using the keypad.

The screen prompts the user to enter the PIN (personal identification number) associated with the specified account number.

The user enters a five-digit PIN, using the keypad.

If the user enters a valid account number and the correct PIN for that account, the screen displays the main menu (Fig. 25.2). If the user enters an invalid account number or an incorrect PIN, the screen displays an appropriate message, then the ATM returns to Step 1 to restart the authentication process.

Fig. 25.2 | ATM main menu.

After the ATM authenticates the user, the main menu (Fig. 25.2) displays a numbered option for each of the three types of transactions: balance inquiry (option 1), withdrawal (option 2) and deposit (option 3). The main menu also displays an option that allows the user to exit the system (option 4). The user then chooses either to perform a transaction (by entering 1, 2 or 3) or to exit the system (by entering 4). If the user enters an invalid option, the screen displays an error message, then redisplays to the main menu.

If the user enters 1 to make a balance inquiry, the screen displays the user’s account balance. To do so, the ATM must retrieve the balance from the bank’s database.

The following actions occur when the user enters 2 to make a withdrawal:

The screen displays a menu (shown in Fig. 25.3) containing standard withdrawal amounts: $20 (option 1), $40 (option 2), $60 (option 3), $100 (option 4) and $200 (option 5). The menu also contains an option to allow the user to cancel the transaction (option 6).

The user enters a menu selection (1–6) using the keypad.

If the withdrawal amount chosen is greater than the user’s account balance, the screen displays a message stating this and telling the user to choose a smaller amount. The ATM then returns to Step 1. If the withdrawal amount chosen is less than or equal to the user’s account balance (i.e., an acceptable withdrawal amount), the ATM proceeds to Step 4. If the user chooses to cancel the transaction (option 6), the ATM displays the main menu (Fig. 25.2) and waits for user input.

If the cash dispenser contains enough cash to satisfy the request, the ATM proceeds to Step 5. Otherwise, the screen displays a message indicating the problem and telling the user to choose a smaller withdrawal amount. The ATM then re- turns to Step 1.

Fig. 25.3 | ATM withdrawal menu.

The ATM debits (i.e., subtracts) the withdrawal amount from the user’s account balance in the bank’s database.

The cash dispenser dispenses the desired amount of money to the user.

The screen displays a message reminding the user to take the money.

The following actions occur when the user enters 3 (while the main menu is displayed) to make a deposit:

The screen prompts the user to entera deposit amount or to type 0 (zero) to cancel the transaction.

The user enters a deposit amount or 0, using the keypad. [Note: The keypad does not contain a decimal point or a dollar sign, so the user cannot type a real dollar amount (e.g., $1.25). Instead, the user must entera deposit amount asa number of cents (e.g., 125). The ATM then divides this number by 100 to obtaina number representing a dollar amount (e.g., 125 / 100 = 1.25).]

If the user specifies a deposit amount, the ATM proceeds to Step 4. If the user chooses to cancel the transaction (by entering 0), the ATM displays the main menu (Fig. 25.2) and waits for user input.

The screen displays a message telling the user to insert a deposit envelope into the deposit slot.

If the deposit slot receives a deposit envelope within two minutes, the ATM cred- its (i.e., adds) the deposit amount to the user’s account balance in the bank’s database. This money is not immediately available for withdrawal. The bank first must physically verify the amount of cash in the deposit envelope, and any checks in the envelope must clear (i.e., money must be transferred from the check writer’s account to the check recipient’s account). When either of these events occurs, the bank appropriately updates the user’s balance stored in its database. This occurs independently of the ATM system. If the deposit slot does not receive a deposit envelope within this time period, the screen displays a message that the system has canceled the trans- action due to inactivity. The ATM then displays the main menu and waits for user input.

After the system successfully executes a transaction, the system should redisplay the main menu (Fig. 25.2) so that the user can perform additional transactions. If the user chooses to exit the system (option 4), the screen should display a thank you message, then display the welcome message for the next user.

Java 100.0%

UML Use Case Diagram Examples

An automated teller machine ( ATM ) or the automatic banking machine ( ABM ) is a banking subsystem ( subject ) that provides bank customers with access to financial transactions in a public space without the need for a cashier, clerk, or bank teller.

Customer ( actor ) uses bank ATM to Check Balances of his/her bank accounts, Deposit Funds , Withdraw Cash and/or Transfer Funds ( use cases ). ATM Technician provides Maintenance and Repairs . All these use cases also involve Bank actor whether it is related to customer transactions or to the ATM servicing.

Bank ATM Use Cases Example for Customer and ATM Technician.

An example of use case diagram for Bank ATM subsystem - top level use cases.

On most bank ATMs, the customer is authenticated by inserting a plastic ATM card and entering a personal identification number (PIN). Customer Authentication use case is required for every ATM transaction so we show it as include relationship. Including this use case as well as transaction generalizations make the ATM Transaction an abstract use case .

Bank ATM transactions and authentication use cases example.

Bank ATM Transactions and Customer Authentication Use Cases Example.

Customer may need some help from the ATM. ATM Transaction use case is extended via extension point called menu by the ATM Help use case whenever ATM Transaction is at the location specified by the menu and the bank customer requests help, e.g. by selecting Help menu item.

Bank ATM Maintenance, Repair, Diagnostics Use Cases Example.

ATM Technician maintains or repairs Bank ATM. Maintenance use case includes Replenishing ATM with cash, ink or printer paper, Upgrades of hardware, firmware or software, and remote or on-site Diagnostics . Diagnostics is also included in (shared with) Repair use case.

Use Cases for Example ATM System

(click on a use case above to go to the flow of events for that use case), flows of events for individual use cases, system startup use case.

The system is started up when the operator turns the operator switch to the "on" position. The operator will be asked to enter the amount of money currently in the cash dispenser, and a connection to the bank will be established. Then the servicing of customers can begin.

[ Interaction Diagram ]

System Shutdown Use Case

The system is shut down when the operator makes sure that no customer is using the machine, and then turns the operator switch to the "off" position. The connection to the bank will be shut down. Then the operator is free to remove deposited envelopes, replenish cash and paper, etc.

Session Use Case

A session is started when a customer inserts an ATM card into the card reader slot of the machine. The ATM pulls the card into the machine and reads it. (If the reader cannot read the card due to improper insertion or a damaged stripe, the card is ejected, an error screen is displayed, and the session is aborted.) The customer is asked to enter his/her PIN, and is then allowed to perform one or more transactions, choosing from a menu of possible types of transaction in each case. After each transaction, the customer is asked whether he/she would like to perform another. When the customer is through performing transactions, the card is ejected from the machine and the session ends. If a transaction is aborted due to too many invalid PIN entries, the session is also aborted, with the card being retained in the machine.

The customer may abort the session by pressing the Cancel key when entering a PIN or choosing a transaction type.

Transaction Use Case

Note: Transaction is an abstract generalization. Each specific concrete type of transaction implements certain operations in the appropriate way. The flow of events given here describes the behavior common to all types of transaction. The flows of events for the individual types of transaction (withdrawal, deposit, transfer, inquiry) give the features that are specific to that type of transaction.

A transaction use case is started within a session when the customer chooses a transaction type from a menu of options. The customer will be asked to furnish appropriate details (e.g. account(s) involved, amount). The transaction will then be sent to the bank, along with information from the customer's card and the PIN the customer entered.

If the bank approves the transaction, any steps needed to complete the transaction (e.g. dispensing cash or accepting an envelope) will be performed, and then a receipt will be printed. Then the customer will be asked whether he/she wishes to do another transaction.

If the bank reports that the customer's PIN is invalid, the Invalid PIN extension will be performed and then an attempt will be made to continue the transaction. If the customer's card is retained due to too many invalid PINs, the transaction will be aborted, and the customer will not be offered the option of doing another.

If a transaction is cancelled by the customer, or fails for any reason other than repeated entries of an invalid PIN, a screen will be displayed informing the customer of the reason for the failure of the transaction, and then the customer will be offered the opportunity to do another.

The customer may cancel a transaction by pressing the Cancel key as described for each individual type of transaction below.

All messages to the bank and responses back are recorded in the ATM's log.

Withdrawal Transaction Use Case

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt. (The dispensing of cash is also recorded in the ATM's log.)

A withdrawal transaction can be cancelled by the customer pressing the Cancel key any time prior to choosing the dollar amount.

Deposit Transaction Use Case

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later. (The receipt of an envelope is also recorded in the ATM's log.)

A deposit transaction can be cancelled by the customer pressing the Cancel key any time prior to inserting the envelope containing the deposit. The transaction is automatically cancelled if the customer fails to insert the envelope containing the deposit within a reasonable period of time after being asked to do so.

Transfer Transaction Use Case

A transfer transaction asks the customer to choose a type of account to transfer from (e.g. checking) from a menu of possible accounts, to choose a different account to transfer to, and to type in a dollar amount on the keyboard. No further action is required once the transaction is approved by the bank before printing the receipt.

A transfer transaction can be cancelled by the customer pressing the Cancel key any time prior to entering a dollar amount.

Inquiry Transaction Use Case

An inquiry transaction asks the customer to choose a type of account to inquire about from a menu of possible accounts. No further action is required once the transaction is approved by the bank before printing the receipt.

An inquiry transaction can be cancelled by the customer pressing the Cancel key any time prior to choosing the account to inquire about.

Invalid PIN Extension

An invalid PIN extension is started from within a transaction when the bank reports that the customer's transaction is disapproved due to an invalid PIN. The customer is required to re-enter the PIN and the original request is sent to the bank again. If the bank now approves the transaction, or disapproves it for some other reason, the original use case is continued; otherwise the process of re-entering the PIN is repeated. Once the PIN is successfully re-entered, it is used for both the current transaction and all subsequent transactions in the session. If the customer fails three times to enter the correct PIN, the card is permanently retained, a screen is displayed informing the customer of this and suggesting he/she contact the bank, and the entire customer session is aborted.

If the customer presses Cancel instead of re-entering a PIN, the original transaction is cancelled.

Page of links for non frames-enabled browsers.

Copyright © 1996, 1997, 1998, 2000, 2001, 2002, 2004 - Russell C. Bjork. Permission for non-commercial reproduction for educational use is hereby granted; all other rights are reserved.

ATM Use Case Diagram Example

UML use case diagrams are the primary form of system/software requirements for new software programs under development. Use cases specify the expected behavior (what), not the exact method (how) to make it happen.

Once a use case is specified, it can be represented in a textual and visual representation (i.e., a use case diagram).

A key concept of use case modeling is that it helps us design a system from the end user's perspective.

It is an effective technique to communicate system behavior in user terms by specifying all externally visible system behaviors.

ATMs enable customers or users to perform financial transactions. These transactions can be performed in a public space without any clerk, cashier or bank teller. With the help of use case diagrams, the working and description of ATMs can be easily explained as shown in the example.

Use Case Diagram Tutorial

Use Case Diagram Templates and Examples

Explore more Use Case Diagram templates

Start creating great diagrams

Terms of Service
Privacy Policy
Security Overview

ATM Case Study, Part 1: Object-Oriented Design with The

ATMCaseStudy,Part1: Object-Oriented Design with theUML 25

Actionspeakslouderthanwords butnot nearly as often. —Mark Twain

Always design athing by consideringitinits next larger context. —Eliel Saarinen

Oh,lifeisaglorious cycleof song. —Dorothy Parker

TheWrightbrothers’ design … allowedthemtosurvive long enough to learnhow to fly. —MichaelPotts

Objectives In this chapter you’ll learn:

■ Asimpleobject-oriented design methodology. ■ What arequirements document is. ■ To identify classes andclass attributes from a requirements document. ■ To identify objects’states, activities andoperationsfrom arequirements document. ■ To determine the collaborationsamong objects in asystem. ■ To work with theUML’s use case, class, state, activity, communication and sequence diagrams to graphically modelanobject- oriented system.

25.1 Introduction 25.6 IdentifyingObjects’Statesand 25.2 IntroductiontoObject-Oriented Activities Analysis andDesign 25.7 IdentifyingClass Operations 25.3 Examiningthe ATMRequirements 25.8 Indicating CollaborationAmong Document Objects 25.4 Identifyingthe Classesinthe ATM 25.9 Wrap-Up RequirementsDocument 25.5 IdentifyingClass Attributes

25.1 Introduction Now we begin theoptionalportion of ourobject-orienteddesign andimplementation case study. In this chapterand Chapter26, you’ll design andimplementanobject-orientedau- tomatedteller machine (ATM) softwaresystem.The case studyprovides youwithacon- cise, carefully paced,completedesign andimplementation experience. You’ll perform the stepsofanobject-orienteddesign (OOD) process using theUML whilerelating themto theobject-oriented conceptsdiscussed in Chapters 2–13. In this chapter, you’ll work with sixpopular typesofUML diagrams to graphicallyrepresent thedesign. In Chapter26, you’ll tune the design with inheritanceand polymorphism, then fully implementthe ATMinan850-line C++application (Section 26.4). This is not an exercise; rather,it’sanend-to-end learning experiencethatconcludes with adetailedwalkthrough of the complete C++code that implements ourdesign. It will acquaint youwith the kindsofsubstantialproblems encountered in industry. Thesechapterscan be studiedasacontinuousunit after you’ve completed theintro- duction to object-oriented programming in Chapters 2–13.Or, youcan pace thesections afterChapters 3–7, 9and 13.Eachsection of thecasestudy beginswithanote telling you thechapterafter which it canbecovered.

25.2 IntroductiontoObject-OrientedAnalysisand Design Whatifyou were askedtocreateasoftwaresystemtocontrol thousandsofautomatedtell- er machinesfor amajor bank ?Orsupposeyou were asked to work on ateamof1000soft- ware developers building thenextU.S.air trafficcontrol system. For projects so largeand complex, youcannotsimplysit down andstartwritingprograms. To createthe best solutions, youshould followaprocess for analyzing your project’s requirements (i.e.,determining what thesystemshould do) anddeveloping a design that satisfiesthem(i.e.,deciding how thesystemshould do it). Ideally,you’d go through this process andcarefully review thedesign (or haveyourdesign reviewed by othersoftware professionals) before writing anycode.Ifthis process involves analyzing anddesigning your systemfromanobject-oriented pointofview, it’s called an object-oriented analysis anddesign(OOAD)process.Analysisand design cansavemanyhours by helping youto avoid an ill-plannedsystem-developmentapproach that hastobeabandoned partofthe waythroughits implementation,possiblywasting considerabletime, moneyand effort. Smallproblems do notrequire an exhaustiveOOAD process.Itmay be sufficient to write pseudocode before youbegin writing C++code.

As problemsand thegroups of people solving them increaseinsize,the methods of OOAD becomemore appropriate than pseudocode. Ideally,members of agroupshould agreeonastrictly definedprocessfor solving theirproblem andauniformway of commu- nicating theresults of that process to oneanother.Although many different OOAD pro- cesses exist, asinglegraphicallanguagefor communicating theresults of any OOAD process hascomeintowide use. This language, knownasthe UnifiedModeling Language (UML), wasdeveloped in themid-1990sunderthe initialdirection of threesoftware methodologists—Grady Booch, JamesRumbaugh andIvarJacobson.

25.3Examining the ATM Requirements Document [Note: This section canbestudied afterChapter3.] We begin ourdesign process by presenting a requirements document that specifiesthe ATMsystem’soverall purposeand what it must do. Throughoutthe case study, we refer to therequirements document to determinewhatfunctionality thesystemmustinclude.

Requirements Document Alocal bank intendstoinstallanewautomated teller machine(ATM) to allowusers (i.e., bank customers) to performbasic financialtransactions(Fig. 25.1). Each usercan have only oneaccount at thebank. ATMusers should be able to view their account balance, withdraw cash (i.e., take moneyout of an account)and depositfunds (i.e.,place moneyintoanaccount).

Please enter youraccountnumber:12345 Screen Enter yourPIN:54321

Take cash here Cash Dispenser

InserInsertdtdeposit envelopelope here here Deposit Slot

Fig.25.1 | Automatedtellermachineuser interface.

Theuserinterfaceofthe automatedteller machinecontains thefollowing hardware components: •ascreen that displays messages to theuser

•akeypad that receives numeric inputfrom theuser •acash dispenser that dispenses cash to theuserand •adepositslotthatreceives depositenvelopes from theuser. Thecashdispenserbeginseachday loaded with 500$20 bills. [Note: Owingtothe limited scopeofthis case study, certainelements of theATM described here do notaccurately mimicthose of arealATM.For example, arealATM typicallycontains adevice that reads auser’s account number from an ATMcard, whereasthis ATMasksthe user to typean accountnumberusing thekeypad.Areal ATMalsousuallyprints areceipt at theend of asession, but alloutputfrom this ATMappears on thescreen.] Thebankwants youtodevelop softwaretoperform thefinancialtransactions initi- ated by bank customersthrough theATM. Thebankwillintegrate thesoftwarewiththe ATM’shardwareatalatertime. Thesoftwareshouldencapsulatethe functionalityofthe hardwaredevices(e.g.,cashdispenser,deposit slot)within software components,but it need notconcern itself with how thesedevicesperform theirduties.The ATMhardware hasnot been developedyet,soinstead of writing your softwaretorun on theATM,you should developafirstversion of thesoftwaretorun on apersonal computer. This version should usethe computer’smonitor to simulatethe ATM’sscreen,and the computer’s key- board to simulate theATM’s keypad. An ATMsession consists of authenticating auser(i.e., provingthe user’s identity) basedonanaccount number andpersonal identification number (PIN), followed by cre- ating andexecuting financial transactions. To authenticate auserand perform transac- tions, theATM must interact with thebank’saccount information database.[Note: A database is an organized collectionofdata storedonacomputer.]For each bank account , thedatabasestoresanaccountnumber,aPINand abalance indicating theamountof moneyinthe account.[Note: For simplicity, we assume that thebank planstobuild only oneATM, so we do notneedtoworry about multiple ATMs accessing this database at thesame time.Furthermore,weassumethatthe bank doesnot make any changes to theinformationin thedatabase while auserisaccessing theATM. Also,any business systemlikeanATM faces reasonably complicatedsecurityissuesthatgowell beyond the scopeofafirst- or second- semester computerscience course. We makethe simplifyingassumption,however,that thebanktruststhe ATMtoaccess andmanipulate theinformation in thedatabase without significant securitymeasures.] Upon firstapproachingthe ATM, theusershould experiencethe followingsequence of events (shown in Fig. 25.1): 1. Thescreen displaysawelcomemessage andprompts theusertoenteranaccount number. 2. Theuserenters afive-digit account number,using thekeypad. 3. Thescreen promptsthe user to enterthe PIN (personalidentification number) associatedwiththe specifiedaccount number. 4. Theuserenters afive-digit PIN, using the keypad. 5. If theuserenters avalid account number andthe correctPIN forthataccount, thescreen displaysthe mainmenu(Fig.25.2).Ifthe userenters an invalid ac- count number or an incorrect PIN, thescreen displaysanappropriate message, then theATM returnstoStep 1 to restartthe authentication process.

Main menu: 1-View my balance 2-Withdraw cash 3-Deposit funds 4-Exit Enter achoice:

Take cash here

InserInserttddepositeposit envelopelope here here

Fig.25.2 | ATMmainmenu.

Afterthe ATMauthenticatesthe user,the mainmenu(Fig.25.2) displaysanum- beredoption foreachofthe threetypes of transactions:balance inquiry (option 1),with- drawal (option 2) anddeposit (option 3).The main menu also displaysanoption that allows theusertoexitthe system (option 4).The user then chooses either to perform a transaction (byentering1,2or 3) or to exit thesystem(by entering4). If theuserenters an invalid option,the screen displaysanerror message,thenredisplays to themainmenu. If theuserenters1to make abalance inquiry,the screen displaysthe user’s account balance.Todoso, theATM mustretrievethe balancefrom thebank’sdatabase. Thefollowing actionsoccurwhenthe user enters 2tomakeawithdrawal: 1. Thescreen displaysamenu (shown in Fig. 25.3)containingstandard withdrawal amounts: $20(option 1),$40 (option 2),$60 (option 3),$100(option 4) and $200 (option 5).The menu also contains an option to allowthe user to cancel thetransaction (option 6). 2. Theuserenters amenuselection (1–6)using thekeypad. 3. If thewithdrawal amount chosenisgreaterthanthe user’s account balance,the screen displays amessage stating thisand telling theusertochooseasmaller amount. TheATM then returns to Step 1.Ifthe withdrawalamount chosenisless than or equal to theuser’s account balance (i.e., an acceptable withdrawal amount), theATM proceedstoStep 4.Ifthe user chooses to cancelthe transaction (option 6),the ATMdisplaysthe main menu (Fig. 25.2)and waitsfor user input. 4. If thecashdispensercontains enough cash to satisfythe request, theATM pro- ceedstoStep 5.Otherwise,the screen displays amessage indicating theproblem andtelling theusertochooseasmallerwithdrawal amount.The ATMthen re- turnstoStep 1.

Withdrawal options: 1-$20 4-$100 2-$40 5-$200 3-$60 6-Cancel transaction Choose awithdrawal option (1-6):

Fig.25.3 | ATMwithdrawalmenu.

5. TheATM debits (i.e.,subtracts)the withdrawalamountfrom theuser’s account balance in the bank’s database. 6. Thecashdispenser dispenses thedesiredamountofmoney to theuser. 7. Thescreen displaysamessagereminding theusertotakethe money . Thefollowing actionsoccurwhenthe user enters 3(whilethe main menu is dis- played)tomakeadeposit: 1. Thescreen promptsthe usertoenteradepositamountortotype 0(zero) to can- celthe transaction. 2. Theuserenters adeposit amount or 0, using thekeypad. [Note: Thekeypad does notcontainadecimal pointoradollar sign,sothe user cannot type arealdollar amount (e.g., $1.25).Instead,the user mustenteradepositamountasanumber of cents(e.g.,125). TheATM then divides this number by 100toobtainanum- berrepresenting adollaramount(e.g.,125 ÷ 100=1.25).] 3. If theuserspecifiesadepositamount, theATM proceedstoStep 4.Ifthe user chooses to cancelthe transaction (byentering0), theATM displaysthe main menu (Fig.25.2) andwaits foruserinput. 4. Thescreen displays amessage telling theusertoinsertadepositenvelope intothe deposit slot. 5. If thedeposit slot receives adeposit envelope within twominutes, theATM cred- its(i.e.,adds)the deposit amount to the user’s account balance in thebank’sda- tabase. This moneyisnot immediatelyavailablefor withdrawal.The bank firstmust physically verifythe amount of cash in thedeposit envelope, andany checks in theen-

velopemust clear (i.e., money must be transferredfromthe check writer’s account to thecheck recipient’saccount). When eitherofthese eventsoccurs, thebankappropri- atelyupdatesthe user’sbalancestoredinits database.Thisoccurs independently of the ATMsystem. If thedeposit slot doesnot receiveadepositenvelopewithinthis time period, thescreen displaysamessagethatthe system hascanceled thetrans- action duetoinactivity. TheATM then displays themainmenuand waitsfor user input. Afterthe system successfully executes atransaction,the system should redisplay the main menu (Fig.25.2) so that theusercan performadditional transactions. If theuser chooses to exit thesystem(option 4),the screen should displayathank youmessage,then display thewelcomemessage forthe next user.

Analyzingthe ATMSystem Theprecedingstatement is asimplifiedexampleofarequirements document. Typically, such adocument is theresultofadetailed requirementsgathering process that mightin- cludeinterviewswithpotential usersofthe system andspecialistsinfields related to thesys- tem. For example, asystemsanalyst whoishiredtopreparearequirements document for banking software (e.g.,the ATMsystemdescribedhere) might interview financialexperts to gain abetterunderstanding of what thesoftwaremustdo. Theanalyst woulduse thein- formation gained to compile alistofsystem requirements to guide systemsdesigners. Theprocessofrequirements gathering is akey task of thefirststageofthe software lifecycle.The software lifecycle specifiesthe stages through which software evolvesfrom thetimeit’sfirst conceived to thetimeit’sretiredfrom use. Thesestagestypically include: analysis,design, implementation, testingand debugging, deployment,maintenance and retirement. Severalsoftwarelife-cyclemodels exist, each with itsown preferences andspec- ificationsfor when andhow oftensoftwareengineers should perform each of thesestages. Waterfallmodels perform each stageonceinsuccession, whereas iterative models may repeat oneormore stages severaltimes throughoutaproduct’s life cycle. Theanalysisstageofthe software life cyclefocusesondefining theproblem to be solved.Whendesigningany system,one must certainly solve theproblem right,but of equal importance,one must solvethe rightproblem.Systems analysts collect therequirements that indicate thespecific problemtosolve.Our requirementsdocument describes our ATMsysteminsufficient detailthatyou do not need to go through an extensive analysis stage—it hasbeendonefor you. To capture what aproposed system should do,developers oftenemploy atechnique knownasusecasemodeling.This processidentifiesthe usecases of thesystem, each of which represents adifferent capabilitythatthe system providestoits clients. For example, ATMs typically have severaluse cases, such as “ViewAccount Balance,” “Withdraw Cash,” “Deposit Funds,”“Transfer FundsBetween Accounts” and“BuyPostage Stamps.” ThesimplifiedATM systemwebuild in this case studyallowsonlythe firstthree of these usecases (Fig.25.4). Each usecasedescribesatypicalscenario in which theuserusesthe system.You’ve alreadyreaddescriptions of theATM system’suse casesinthe requirements document; the listsofsteps required to performeachtypeoftransaction (i.e.,balance inquiry,with- drawal and deposit) actuallydescribedthe threeuse casesofour ATM—“ViewAccount Balance,” “Withdraw Cash” and“DepositFunds.”

View Account Balance

Withdraw Cash

User Deposit Funds

Fig.25.4 | Usecasediagram forthe ATMsystemfromthe User’s perspective.

UseCaseDiagrams We nowintroduce thefirstofseveralUML diagrams in ourATM case study. We create a usecasediagram to modelthe interactionsbetween asystem’sclients (in this case study, bank customers)and the system.The goalistoshow thekinds of interactionsusers have with asystemwithout providingthe details—theseare providedinother UMLdiagrams (which we presentthroughoutthe case study).Use case diagrams areoftenaccompanied by informal text that describes theuse casesinmore detail—like thetextthatappearsin therequirements document. Usecasediagrams areproduced duringthe analysis stageof thesoftwarelifecycle.Inlarger systems, usecasediagrams aresimplebut indispensable toolsthathelpsystemdesigners remain focusedonsatisfying the users’ needs. Figure 25.4 showsthe usecasediagramfor ourATM system. Thestick figure repre- sentsanactor,whichdefines therolesthatanexternalentity—such as apersonoranother system—plays when interacting with thesystem. For ourautomated tellermachine, the actorisaUser whocan view an account balance,withdrawcashand depositfunds from theATM. TheUserisnot an actualperson, butinstead comprises therolesthatareal person—whenplaying thepartofaUser—canplaywhile interactingwiththe ATM. Note that ause case diagramcan includemultipleactors. For example, theuse case diagram for arealbank’sATM system might also includeanactor named Administrator whorefills thecashdispensereachday. We identifythe actorinour system by examining the requirements document, which states,“ATMusers should be able to view theiraccount balance,withdraw cash and depositfunds.” So,the actorineachofthe threeuse casesisthe User whointeractswith theATM.Anexternalentity—arealperson—playsthe part of theUsertoperform finan- cial transactions.Figure25.4shows oneactor, whosename, User,appearsbelowthe actor in thediagram. TheUML models each usecaseasanoval connectedtoanactor with a solidline. Softwareengineers (more precisely,systems analysts)mustanalyze therequirements document or aset of usecases anddesign thesystembefore programmers implementit. Duringthe analysis stage, systemsanalystsfocusonunderstanding therequirementsdoc- umenttoproduce ahigh-level specification that describes what thesystemissupposedto do. Theoutputofthe design stage—a designspecification—shouldspecifyclearly how thesystem should be constructedtosatisfythese requirements. In thenextseveral sections, we perform thesteps of asimpleobject-orienteddesign (OOD) process on theATM

© 2012 Pearson Education, Inc., Upper Saddle River, NJ. All Rights Reserved. 25.3 Examiningthe ATMRequirements Document 25-9 system to produce adesign specification containing acollection of UMLdiagrams and supportingtext. Recall that theUML is designed foruse with anyOOD process.Many such processes exist, thebestknown of which is theRationalUnified Process™ (RUP) developedbyRationalSoftwareCorporation (now adivision of IBM). RUPisarichpro- cessintendedfor designing“industrial strength”applications. For this case study, we presentour ownsimplifieddesign process.

Designingthe ATM System We now begin theATM system’s design.Asystem is aset of components that interactto solveaproblem.Toperform theATM system’s designatedtasks,our ATMsystemhas a user interface (Fig. 25.1), contains software that executes financial transactionsand inter- acts with adatabaseofbankaccount information. System structure describes thesystem’s objectsand their interrelationships. System behavior describes how thesystem changesas itsobjects interactwithone another. Everysystemhas both structureand behavior—de- signersmustspecifyboth. Thereare severaldistincttypes of system structures andbehav- iors. Forexample, theinteractionsamong objectsinthe system differfromthose between theuserand thesystem, yetbothconstitute aportion of thesystembehavior. TheUML 2specifies13diagramtypesfor documenting themodels of systems. Each models adistinctcharacteristicofasystem’s structureorbehavior—sixdiagramsrelateto system structure; theremainingseven relate to system behavior.Welisthereonlythe six typesofdiagrams used in ourcasestudy—oneofthese (classdiagrams)models system structure—theremainingfivemodelsystembehavior.Weoverview theremaining seven UMLdiagramtypes in Appendix G, UML2:Additional DiagramTypes. 1. Usecase diagrams,suchasthe oneinFig.25.4, modelthe interactionsbetween asystemand itsexternalentities(actors)interms of usecases (systemcapabilities, such as “ViewAccount Balance,”“WithdrawCash” and“DepositFunds”). 2. Classdiagrams,whichyou’llstudy in Section 25.4,model theclasses,or“build- ing blocks,”usedinasystem.Eachnounor“thing” described in therequirements document is acandidate to be aclass in thesystem(e.g.,“account,” “keypad”). Classdiagrams help us specifythe structural relationshipsbetween partsofthe system.For example, theATM system classdiagramwillspecifythatthe ATMis physicallycomposedofascreen,akeypad,acash dispenser andadepositslot. 3. Statemachine diagrams,whichyou’llstudyinSection 25.6,modelthe ways in which an object changesstate.Anobject’s state is indicatedbythe values of all theobject’sattributesatagiven time.Whenanobjectchanges state,thatobject maybehavedifferentlyinthe system.For example, aftervalidating auser’s PIN, theATM transitionsfromthe “user notauthenticated” state to the“user authen- ticated” state,atwhich point theATM allows theusertoperform financialtrans- actions(e.g.,viewaccount balance,withdrawcash, depositfunds). 4. Activity diagrams,which you’ll also studyinSection 25.6,modelanobject’s ac- tivity—the object’s workflow (sequence of events)during programexecution. An activity diagrammodels theactions theobjectperformsand specifiesthe orderin which it performsthese actions. For example,anactivitydiagramshowsthatthe ATMmustobtainthe balance of theuser’saccount (from thebank’saccount in- formation database) before thescreen candisplay thebalance to the user.

5. Communication diagrams (called collaborationdiagrams in earlierversions of theUML)modelthe interactionsamong objects in asystem, with an emphasis on what interactionsoccur. You’ll learninSection 25.8thatthese diagrams show which objects must interacttoperform an ATMtransaction. Forexample, the ATMmustcommunicatewiththe bank’s account information database to re- trieve an accountbalance. 6. Sequencediagrams also modelthe interactions amongthe objectsinasystem, butunlikecommunication diagrams, they emphasize when interactionsoccur. You’ll learn in Section 25.8 that thesediagramshelpshow theorderinwhichin- teractions occurinexecuting afinancialtransaction.For example, thescreen prompts theusertoenterawithdrawal amountbefore cash is dispensed. In Section 25.4,wecontinuedesigning ourATM system by identifying the classes from therequirementsdocument. We accomplishthis by extracting keynouns andnoun phrasesfrom therequirements document. Usingthese classes, we developour firstdraft of theclass diagramthatmodels thestructure of ourATM system.

WebResources We’vecreated an extensiveUML Resource Center(www.deitel.com/UML/)thatcontains many linkstoadditional information,including introductions,tutorials,blogs,books, cer- tification,conferences, developertools, documentation, e-books, FAQs,forums,groups, UMLinC++,podcasts, security, tools, downloads,trainingcourses,videos andmore.

Self-ReviewExercises forSection 25.3 25.1 Supposeweenabled auserofour ATMsystem to transfermoney betweentwo bank ac- counts. Modify theuse case diagramofFig.25.4toreflect this change. 25.2 modelthe interactions amongobjects in asystemwithanemphasisonwhen these interactions occur. a) Class diagrams b) Sequence diagrams c) Communication diagrams d) Activity diagrams 25.3 Whichofthe following choiceslists stages of atypicalsoftware life cycleinsequentialorder? a) design,analysis,implementation, testing b) design,analysis,testing,implementation c) analysis,design, testing, implementation d) analysis,design, implementation, testing

25.4Identifyingthe Classesinthe ATM Requirements Document [Note: This section canbestudied afterChapter3.] Now we begin designingthe ATMsystemthatweintroducedinSection 25.3.Inthis sec- tion,weidentifythe classesthatare needed to buildthe ATMsystem by analyzing the nounsand noun phrasesthatappear in therequirementsdocument. We introduceUML classdiagrams to modelthe relationshipsbetween theseclasses.This is an importantfirst step in defining the structureofour system.

Identifyingthe ClassesinaSystem We begin ourOOD process by identifying theclassesrequiredtobuild theATM system. We’lleventuallydescribe theseclasses using UMLclass diagrams andimplement these classesinC++.First,wereviewthe requirementsdocument of Section 25.3 andfindkey nounsand noun phrasestohelpusidentifyclasses that comprisethe ATMsystem. We maydecidethatsomeofthese nounsand noun phrasesare attributes of otherclasses in the system.Wemay also conclude that some of thenouns do not correspondtoparts of the system andthusshould not be modeledatall. Additional classesmay becomeapparent to us as we proceed through thedesignprocess. Figure 25.5 liststhe nounsand nounphrasesinthe requirements document. We list them from lefttoright in theorderinwhichtheyappear in therequirementsdocument. We list only thesingularform of each nounornounphrase.

Nouns andnoun phrasesinthe requirements document

bank money/fund account number ATM screen PIN user keypad bank database customer cash dispenser balanceinquiry transaction $20 bill /cash withdrawal account depositslot deposit balance depositenvelope

Fig.25.5 | Nounsand noun phrasesinthe requirements document.

We create classesonlyfor thenouns andnounphrases that have significance in the ATMsystem.Wedon’t need to model“bank”asaclass, because it’isnot apartofthe ATM system—the bank simplywants us to build theATM. “Customer” and“user”alsorepre- sent outsideentities—theyare importantbecause they interact with ourATM system, but we do notneed to modelthemasclasses in theATM software.Recallthatwemodeled an ATMuser(i.e.,abankcustomer) as theactor in theuse case diagramofFig.25.4. We do notmodel “$20 bill” or “deposit envelope”asclasses. Theseare physicalobjects in therealworld, buttheyare not part of what’s beingautomated. We canadequately rep- resent thepresence of billsinthe system using an attribute of theclass that models thecash dispenser. (Weassign attributes to classesinSection 25.5.) Forexample, thecashdispenser maintains acount of thenumberofbills it contains.The requirements document doesn’t sayanythingabout what thesystem should do with depositenvelopes afteritreceivesthem. We canassumethatacknowledgingthe receiptofanenvelope—anoperation performed by theclass that models thedeposit slot—issufficienttorepresent thepresenceofanenve- lope in thesystem.(We assign operations to classesinSection 25.7.) In oursimplifiedATM system,representingvarious amounts of “money,” including an account’s “balance,” as attributesofother classesseems most appropriate. Likewise,the nouns“account number”and “PIN” represent significant information in theATM system. They areimportant attributes of abankaccount. They do not,however,exhibit behaviors. Thus,wecan most appropriately modelthemasattributes of an account class. Though therequirements document frequently describes a“transaction”inageneral sense, we do notmodelthe broadnotion of afinancialtransaction at this time.Instead,

© 2012 Pearson Education, Inc., Upper Saddle River, NJ. All Rights Reserved. 25-12 Chapter25ATM Case Study,Part1:Object-Oriented Designwiththe UML we modelthe threetypes of transactions(i.e.,“balanceinquiry,” “withdrawal”and “deposit”) as individual classes. Theseclasses possessspecific attributes needed forexe- cuting thetransactions they represent. For example, awithdrawalneeds to know the amount of moneythe user wants to withdraw. Abalance inquiry,however,doesnot require anyadditional data.Furthermore,the threetransaction classes exhibit unique behaviors.Awithdrawalincludes dispensing cash to theuser, whereasadepositinvolves receivingdeposit envelopesfrom theuser. In Section26.3, we “factorout”commonfeatures of alltransactions into ageneral “transaction” class using theobject-orientedconceptsofabstract classes andinheritance. We determinethe classes forour system basedonthe remaining nouns and noun phrasesfrom Fig. 25.5.Eachofthese refers to oneormore of thefollowing: •ATM •screen •keypad •cashdispenser •deposit slot •account •bankdatabase •balance inquiry •withdrawal •deposit Theelements of this list arelikelytobeclasses we’llneedtoimplementour system. We cannow modelthe classes in oursystembased on thelistwe’ve created.Wecap- italize classnames in thedesign process—a UMLconvention—aswe’ll do when we write theactual C++code that implements ourdesign. If thenameofaclasscontains more than oneword, we runthe words together andcapitalize thefirst letterofeachword (e.g., Mul- tipleWordName). Using this convention,wecreateclasses ATM, Screen, Keypad, CashDis- penser, DepositSlot, Account, BankDatabase, BalanceInquiry, Withdrawal and Deposit.Weconstruct oursystemusing allofthese classesasbuilding blocks. Beforewe begin building thesystem, however,wemust gain abetterunderstanding of how the classesrelatetoone another.

Modeling Classes TheUML enablesustomodel, via classdiagrams,the ATMsystem’sclasses andtheir in- terrelationships. Figure 25.6 represents class ATM.Eachclass is modeledasarectanglewith threecompartments. Thetop compartmentcontains thenameofthe class, centered hori- zontally andinboldface. Themiddle compartment contains the class’sattributes.(We dis- cuss attributes in Section 25.5 and Section 25.6.) Thebottomcompartment contains the class’soperations(discussedinSection 25.7).InFig. 25.6 themiddle andbottomcompart- ments areempty,becausewe’ve notyet determined this class’sattributes andoperations. Classdiagrams also show therelationshipsamong theclasses of thesystem. Figure 25.7 showshow ourclasses ATM and Withdrawal relate to oneanother. Forthe moment,wechoosetomodelonlythis subset of classesfor simplicity; we presentamore

Fig.25.6 | Representingaclass in theUML usingaclass diagram.

1 Executes 0..1 ATM Withdrawal currentTransaction

Fig.25.7 | Classdiagram showinganassociation amongclasses. completeclass diagramlater in this section. Notice that therectangles representing classes in this diagram arenot subdividedintocompartments.The UMLallowsthe suppression of class attributesand operationsinthis manner,whenappropriate,tocreatemore read- able diagrams.Suchadiagramissaidtobeanelideddiagram—one in which some infor- mation,suchasthe contentsofthe secondand third compartments,isnot modeled. We’ll placeinformation in thesecompartments in Section 25.5 andSection 25.7. In Fig. 25.7,the solidline that connectsthe twoclasses represents an association—a relationship betweenclasses.The numbersneareachend of theline are multiplicity values,whichindicate how many objectsofeachclass participateinthe association.Inthis case,following theline from oneend to theother revealsthat, at anygiven moment, one ATM object participates in an association with either zero or one Withdrawal objects—zero if thecurrentuserisnot currentlyperformingatransaction or hasrequested adifferent type of transaction, andone if the user hasrequested awithdrawal.The UMLcan model many typesofmultiplicity. Figure 25.8 listsand explains the multiplicitytypes.

Symbol Meaning

0 None 1 One m An integervalue 0..1 Zero or one m, n m or n m..n At least m,but notmorethan n * Anynonnegative integer(zero or more) 0..* Zero or more (identical to *) 1..* Oneormore

Fig.25.8 | Multiplicity types.

An association canbenamed.For example,the word Executes abovethe line con- nectingclasses ATM and Withdrawal in Fig. 25.7 indicatesthe name of that association. This part of thediagramreads “one object of class ATM executeszeroorone objects of class

Withdrawal.” Association namesare directional,asindicatedbythe filled arrowhead—so it wouldbeimproper,for example, to read thepreceding association from righttoleftas “zeroorone objectsofclass Withdrawal executeone objectofclass ATM.” Theword currentTransaction at the Withdrawal endofthe association line in Fig. 25.7 is a role name,whichidentifiesthe role the Withdrawal objectplays in itsrela- tionship with the ATM.Arolename adds meaningtoanassociationbetween classesbyiden- tifying the role aclass playsinthe contextofanassociation.Aclasscan play severalroles in thesame system. For example, in aschool personnelsystem, apersonmay play therole of “professor” when relating to students.The same person maytakeonthe roleof“col- league” when participating in arelationship with anotherprofessor, and“coach” when coachingstudent athletes.InFig.25.7, therolename currentTransaction indicatesthat the Withdrawal object participating in the Executes association with an objectofclass ATM represents thetransaction currentlybeing processed by theATM.Inother contexts,a Withdrawal object may takeonother roles (e.g., theprevioustransaction). Notice that we do not specifyarole name for the ATM endofthe Executes association.Role namesinclass diagrams areoftenomittedwhenthe meaning of an association is clear withoutthem. In additiontoindicating simple relationships, associationscan specifymorecomplex relationships, such as objects of oneclass being composed of objects of otherclasses.Con- siderareal-worldautomatedtellermachine. What“pieces”doesamanufacturer put together to buildaworking ATM? Ourrequirements document tells us that theATM is composed of ascreen,akeypad,acash dispenserand adeposit slot. In Fig. 25.9,the soliddiamonds attachedtothe associationlines of class ATM indicate that class ATM hasacomposition relationship with classes Screen, Keypad, CashDispenser and DepositSlot.Composition impliesawhole/partrelationship.The classthathas the composition symbol (the soliddiamond)onits endofthe associationline is thewhole (inthis case, ATM), andthe classesonthe otherend of theassociation linesare theparts—inthiscase, classes Screen, Keypad, CashDispenser and DepositSlot.The compositions in Fig. 25.9 indicate that an object of class ATM is formed from oneobjectofclass Screen,one object of class CashDispenser,one object of class Keypad andone object of class DepositSlot.The ATM hasascreen,akeypad,acash dispenserand adeposit slot.The has-a relationship definescomposition.(We’llsee in Section 26.3thatthe is-a relationship definesinheritance.)

11 11 DepositSlotCATM ashDispenser

Fig.25.9 | Classdiagram showingcomposition relationships.

According to theUML specification,composition relationshipshavethe following properties: 1. Onlyone classinthe relationship canrepresent thewhole (i.e., thediamond can be placed on only oneend of theassociation line). Forexample, either thescreen is partofthe ATMorthe ATMispartofthe screen,but thescreen andthe ATM cannot both representthe wholeinthe relationship. 2. Theparts in acomposition relationship existonlyaslongasthe whole, andthe wholeisresponsible forcreating anddestroyingits parts. For example, theact of constructing an ATMincludes manufacturingits parts. Furthermore, if theATM is destroyed, itsscreen,keypad,cashdispenserand depositslotare also destroyed. 3. Apartmay belong to only onewhole at atime, although thepartmay be removed andattachedtoanotherwhole,whichthenassumes responsibility forthe part. Thesolid diamondsinour classdiagrams indicate composition relationshipsthatful- fill thesethree properties.Ifahas-a relationship does notsatisfyone or more of thesecri- teria,the UMLspecifiesthathollow diamondsbeattachedtothe ends of association lines to indicate aggregation—a weaker form of composition.For example, apersonalcom- puterand acomputermonitor participate in an aggregation relationship—the computer hasamonitor, butthe twoparts canexist independently, andthe same monitor can be attachedtomultiplecomputersatonce, thus violating the second andthirdproperties of composition. Figure 25.10showsaclassdiagramfor theATM system.This diagrammodels most of theclasses that we identified earlier in this section, as well as theassociationsbetween them that we caninfer from therequirements document. [Note: Classes BalanceInquiry and Deposit participateinassociationssimilar to thoseofclass Withdrawal,sowe’ve chosen to omit them from this diagram to keepitsimple. In Section 26.3,weexpandour class diagramtoincludeall theclasses in theATM system.] Figure 25.10presents agraphical modelofthe structureofthe ATMsystem. This classdiagramincludes classes BankDatabase and Account andseveralassociationsthat were notpresent in either Fig. 25.7 or Fig. 25.9.The class diagramshowsthatclass ATM hasaone-to-one relationship with class BankDatabase—one ATM objectauthenticates usersagainst one BankDatabase object.InFig.25.10,wealsomodelthe fact that the bank’s database contains information aboutmanyaccounts—oneobjectofclass BankDa- tabase participatesinacomposition relationship with zero or more objectsofclass Account.Recallfrom Fig. 25.8 that themultiplicityvalue 0..* at the Account endofthe association between class BankDatabase andclass Account indicatesthatzeroormore objectsofclass Account take part in theassociation.Class BankDatabase hasaone-to- many relationship with class Account—the BankDatabase contains many Accounts. Sim- ilarly,class Account hasamany-to-one relationship with class BankDatabase—there can be many Accountscontainedinthe BankDatabase.[Note: Recallfrom Fig. 25.8 that the multiplicityvalue *isidenticalto0..*.Weinclude 0..* in ourclass diagrams forclarity.] Figure 25.10alsoindicatesthatifthe user is performingawithdrawal, “one objectof class Withdrawal accesses/modifiesanaccount balance through oneobjectofclass Bank- Database.” We could have createdanassociation directly between class Withdrawal and class Account.The requirements document, however,statesthatthe “ATM must interact with thebank’saccount information database” to perform transactions.Abank account

1 111 Keypad CashDispenser

1 DepositSlot Screen

1111 0..1 0..10..1 Executes ATM Withdrawal 1 0..1 1 0..1 Authenticates user against 1

BankDatabase 1 Accesses/modifies an account balance through 1 Contains 0..*

Fig.25.10 | Classdiagram forthe ATMsystemmodel. contains sensitiveinformation,and systemsengineers mustalways considerthe security of personal data when designingasystem.Thus, only the BankDatabase canaccessand manipulate an account directly.All otherparts of thesystem must interactwiththe data- base to retrieve or update account information (e.g., an account balance). Theclass diagram in Fig. 25.10alsomodels associationsbetween class Withdrawal andclasses Screen, CashDispenser and Keypad.Awithdrawaltransaction includes prompting theusertochooseawithdrawalamount and receivingnumeric input. These actionsrequire theuse of thescreenand thekeypad, respectively.Furthermore, dispensing cash to theuserrequiresaccess to thecashdispenser. Classes BalanceInquiry and Deposit,though notshowninFig.25.10,takepartin several associationswiththe otherclasses of theATM system.Likeclass Withdrawal,each of theseclasses associateswithclasses ATM and BankDatabase.Anobjectofclass Balan- ceInquiry also associateswithanobjectofclass Screen to display thebalance of an accounttothe user.Class Deposit associateswithclasses Screen, Keypad and Deposit- Slot.Likewithdrawals,deposit transactions require useofthe screen andthe keypadto display promptsand receiveinput,respectively.Toreceivedeposit envelopes, an object of class Deposit accesses thedeposit slot. We’venow identifiedthe classesinour ATMsystem(although we maydiscover others as we proceed with thedesign andimplementation). In Section 25.5,wedetermine theattributesfor each of theseclasses,and in Section 25.6,weuse theseattributes to examine howthe system changesovertime. In Section 25.7,wedetermine theoperations of theclasses in oursystem.

Self-ReviewExercises forSection 25.4 25.4 Supposewehaveaclass Car that represents acar.Think of some of thedifferent pieces that amanufacturerwouldput together to produceawholecar.Createaclassdiagram (similar to Fig. 25.9) that models some of the compositionrelationships of class Car. 25.5 Supposewehaveaclass File that representsanelectronicdocumentinastand-alone,non- networkedcomputerrepresented by class Computer.Whatsortofassociationexistsbetween class Computer and class File? a) Class Computer hasaone-to-one relationship with class File. b) Class Computer hasamany-to-one relationshipwith class File. c) Class Computer hasaone-to-many relationshipwith class File. d) Class Computer hasamany-to-many relationship with class File. 25.6 Statewhether the followingstatementistrue or false,and if false,explain why: AUML dia- graminwhich aclass’s second andthird compartments arenot modeledissaidtobeanelided diagram. 25.7 Modify theclass diagramofFig.25.10 to includeclass Deposit insteadofclass Withdrawal.

25.5IdentifyingClass Attributes [Note: This section canbestudied afterChapter4.] In Section 25.4,webegan the first stageofanobject-orienteddesign (OOD) forour ATM system—analyzing therequirements document andidentifying the classesneededtoim- plementthe system.Welistedthe nouns and noun phrases in the requirements document andidentifiedaseparateclass foreachone that plays asignificant role in theATM system. We then modeledthe classesand their relationshipsinaUMLclass diagram(Fig.25.10). Classeshaveattributes(data) and operations (behaviors).Class attributesare imple- mented in C++programs as data members, andclass operationsare implementedas member functions.Inthis section, we determinemanyofthe attributesneededinthe ATMsystem.InSection 25.6,weexamine how theseattributes representanobject’sstate. In Section 25.7,wedetermine classoperations.

IdentifyingAttributes Consider theattributesofsomereal-worldobjects:Aperson’s attributes includeheight, weight andwhether thepersonisleft-handed,right-handedorambidextrous. Aradio’sattri- butesincludeits station setting,its volume setting and itsAMorFMsetting.Acar’sattri- butesinclude itsspeedometer andodometer readings,the amount of gasinits tank and what gear it’s in. Apersonal computer’sattributes includeits manufacturer (e.g., Dell,HP, Apple or IBM),typeofscreen(e.g.,LCD or CRT), mainmemorysize andharddisksize. We canidentifymanyattributes of theclasses in oursystembylookingfor descriptive words andphrasesinthe requirements document. Foreachone we find that playsasig- nificantrole in theATM system,wecreateanattribute andassign it to oneormore of the classesidentifiedinSection 25.4.Wealsocreateattributestorepresent anyadditional data that aclass mayneed,assuchneeds becomeapparentthroughoutthe designprocess. Figure 25.11lists thewords or phrasesfromthe requirements document that describe each class. We formed this list by reading therequirementsdocument andidentifying any words or phrasesthatrefer to characteristics of theclasses in thesystem. For example,the requirements document describes thesteps takentoobtaina“withdrawal amount,” so we list “amount”nexttoclass Withdrawal.

Figure 25.11leads us to create oneattribute of class ATM.Class ATM maintains infor- mation aboutthe state of theATM. Thephrase “userisauthenticated” describes astate of theATM (weintroduce statesinSection 25.6), so we include userAuthenticated as a Boolean attribute (i.e., an attributethathas avalue of either true or false). TheUML Boolean type is equivalent to the bool type in C++. This attributeindicateswhether the ATMhas successfullyauthenticatedthe current user—userAuthenticated must be true forthe system to allowthe user to perform transactions andaccess accountinformation. This attribute helpsensurethe securityofthe data in thesystem.

Class Descriptivewords andphrases

ATM user is authenticated BalanceInquiry account number Withdrawal account number amount Deposit account number amount BankDatabase [nodescriptivewords or phrases] Account account number PIN balance Screen [nodescriptivewords or phrases] Keypad [nodescriptivewords or phrases] CashDispenser begins each dayloaded with 500 $20 bills DepositSlot [nodescriptivewords or phrases]

Fig.25.11 | Descriptivewords andphrases from the ATMrequirements.

Classes BalanceInquiry, Withdrawal and Deposit shareone attribute. Each transac- tion involvesan“account number”thatcorrespondstothe account of theusermakingthe transaction.Weassign an integerattribute accountNumber to each transaction classto identifythe account to which an object of theclass applies. Descriptive words andphrasesinthe requirements document also suggest some dif- ferencesinthe attributes requiredbyeachtransaction class. Therequirements document indicatesthattowithdraw cash or depositfunds,users must enteraspecific “amount” of moneytobewithdrawn or deposited, respectively.Thus, we assign to classes Withdrawal and Deposit an attribute amount to store thevalue suppliedbythe user.The amountsof moneyrelatedtoawithdrawal andadepositare defining characteristics of thesetransac- tionsthatthe system requiresfor them to takeplace.Class BalanceInquiry,however, needsnoadditional data to perform itstask—it requiresonlyanaccount number to indi- cate theaccount whosebalance should be retrieved. Class Account hasseveral attributes. Therequirements document statesthateachbank accounthas an “accountnumber”and “PIN,”whichthe systemuses foridentifyingaccounts

© 2012 Pearson Education, Inc., Upper Saddle River, NJ. All Rights Reserved. 25.5 Identifying ClassAttributes 25-19 andauthenticating users. We assign to class Account twointegerattributes: accountNumber and pin .The requirements document also specifiesthatanaccount maintains a“balance” of theamount of moneyinthe accountand that moneythe userdepositsdoesnot become availablefor awithdrawal untilthe bank verifiesthe amount of cash in thedeposit envelope, and any checksinthe envelope clear. An account muststill recordthe amount of moneythat auserdeposits, however.Therefore,wedecidethatanaccount should representabalance usingtwo attributesofUML type Double: availableBalance and totalBalance.Attribute availableBalance tracks theamount of moneythatausercan withdraw from theaccount. Attribute totalBalance refers to thetotal amount of moneythatthe userhas “ondeposit” (i.e.,the amount of moneyavailable,plusthe amount waitingtobeverifiedorcleared). For example, suppose an ATMuserdeposits$50.00into an empty account. The totalBalance attribute wouldincreaseto$50.00torecordthe deposit, but the availableBalance would remainat$0. [Note: We assume that thebankupdates the availableBalance attributeof an Account soon afterthe ATMtransaction occurs, in response to confirming that $50 worthofcashorcheckswas found in thedeposit envelope.Weassumethatthisupdate occursthrough atransaction that abankemployee performsusing some pieceofbanksoft- ware otherthanthe ATM. Thus, we do notdiscuss this transaction in ourcasestudy.] Class CashDispenser hasone attribute.The requirements document statesthatthe cash dispenser “begins each dayloadedwith500 $20bills.” Thecashdispensermustkeep trackofthe number of bills it contains to determinewhether enough cash is on handto satisfywithdrawal requests. We assign to class CashDispenser an integer attribute count, which is initially setto500. For real problemsinindustry,there is no guaranteethatrequirementsspecifications will be rich enough andprecise enough forthe object-oriented systemsdesigner to deter- mine allthe attributes or even allthe classes.The need foradditional (or fewer) classes, attributesand behaviors may becomeclear as thedesign process proceeds. As we progress through this case study, we toowillcontinuetoadd,modifyand delete information about theclasses in oursystem.

Modeling Attributes Theclass diagraminFig. 25.12lists some of theattributes forthe classes in oursystem— thedescriptive words andphrasesinFig.25.11 helped us identifythese attributes.For simplicity, Fig. 25.12doesnot show theassociationsamong classes—weshowed thesein Fig. 25.10. This is acommonpracticeofsystems designerswhendesigns arebeing devel- oped.Recallfrom Section 25.4 that in theUML,aclass’s attributes areplacedinthe mid- dle compartment of theclass’s rectangle. We list each attribute’snameand type separated by acolon (:), followed in some casesbyanequal sign (=)and an initialvalue. Considerthe userAuthenticated attribute of class ATM:

userAuthenticated :Boolean=false This attribute declaration contains threepiecesofinformation aboutthe attribute.The at- tribute name is userAuthenticated.The attribute type is Boolean.InC++,anattribute canberepresentedbyafundamental type,suchasbool, int or double,oraclasstype. We’vechosentomodel only primitive-type attributesinFig.25.12—wediscuss therea- soning behindthis decision shortly.[Note: Figure 25.12lists UML data typesfor theat- tributes.Whenweimplementthe system,we’ll associate theUML types Boolean, Integer and Double with theC++ fundamental types bool, int and double,respectively.]

ATM Account userAuthenticated :Boolean =false accountNumber :Integer pin :Integer availableBalance :Double totalBalance :Double BalanceInquiry accountNumber :Integer Screen

Withdrawal accountNumber :Integer amount :Double Keypad

Deposit accountNumber :Integer CashDispenser amount :Double count :Integer =500

BankDatabase DepositSlot

Fig. 25.12 | Classes with attributes.

We canalsoindicateaninitial value foranattribute. The userAuthenticated attri- bute in class ATM hasaninitialvalue of false.This indicatesthatthe system initially does notconsiderthe user to be authenticated. If an attribute hasnoinitial valuespecified, only itsnameand type (separatedbyacolon) areshown.For example, the accountNumber attri- bute of class BalanceInquiry is an Integer.Hereweshow no initialvalue,because the valueofthis attribute is anumber that we do notyet know—it will be determined at exe- cution time basedonthe account number enteredbythe currentATM user. Figure 25.12doesnot include anyattributes forclasses Screen, Keypad and DepositSlot.These areimportantcomponents of oursystem, forwhichour design process simply hasnot yetrevealed anyattributes. We maystill discover some,however, in theremaining design phases or when we implementthese classesinC++.This is per- fectly normal forthe iterativeprocessofsoftwareengineering. Software EngineeringObservation25.1 At theearly stages in the design process,classes oftenlackattributes (and operations). Such classesshould not be eliminated,however, because attributes (and operations)may become evident in the laterphasesofdesignand implementation.

Figure 25.12alsodoesnot include attributes forclass BankDatabase.Recallthatattri- butescan be representedbyeitherfundamentaltypes or class types. We’vechosento

© 2012 Pearson Education, Inc., Upper Saddle River, NJ. All Rights Reserved. Self-ReviewExercisesfor Section 25.5 25-21 includeonlyfundamental-typeattributesinthe class diagraminFig.25.12 (and in similar classdiagrams throughoutthe case study).Aclass-typeattributeismodeledmore clearly as an association (in particular, acomposition)between the classwiththe attributeand the classofthe object of which theattributeisaninstance. Forexample, theclass diagramin Fig. 25.10indicatesthatclass BankDatabase participates in acomposition relationship with zero or more Account objects. From this composition,wecan determinethatwhen we implementthe ATMsysteminC++,we’ll be required to createanattribute of class BankDatabase to holdzero or more Account objects. Similarly,we’ll assign attributes to class ATM that correspond to itscomposition relationshipswithclasses Screen, Keypad, CashDispenser and DepositSlot.These composition-based attributes wouldberedun- dant if modeledinFig.25.12,because thecompositionsmodeledinFig. 25.10already convey thefactthatthe database contains information aboutzeroormore accountsand that an ATMiscomposed of ascreen,keypad,cashdispenserand depositslot. Software developers typically modelthese whole/part relationshipsascompositionsratherthanas attributesrequiredtoimplement therelationships. Theclass diagraminFig. 25.12provides asolid basisfor thestructure of ourmodel, butthe diagramisnot complete. In Section 25.6,weidentifythe statesand activities of theobjects in themodel, andinSection 25.7 we identify theoperations that theobjects perform.Aswepresent more of theUML andobject-orienteddesign, we’ll continueto strengthenthe structureofour model. Self-ReviewExercises forSection 25.5 25.8 We typically identify theattributes of the classesinour system by analyzingthe in therequirementsdocument. a) nounsand noun phrases b) descriptivewords and phrases c) verbsand verb phrases d) Allofthe above. 25.9 Whichofthe followingisnot an attributeofanairplane? a) length b) wingspan c) fly d) numberofseats 25.10 Describethe meaning of thefollowing attributedeclaration of class CashDispenser in the classdiagram in Fig. 25.12: count :Integer=500 25.6IdentifyingObjects’Statesand Activities [Note: This section canbestudied afterChapter5.] In Section 25.5,weidentifiedmanyofthe class attributes needed to implementthe ATM system andaddedthemtothe classdiagraminFig.25.12.Inthis section, we show how theseattributesrepresent an object’s state.Weidentify some keystatesthatour objectsmay occupy anddiscuss howobjects change state in response to various events occurring in the system.Wealsodiscuss theworkflow,oractivities,thatobjects perform in theATM sys- tem. We presentthe activitiesofBalanceInquiry and Withdrawal transaction objectsin this section, as they representtwo of thekey activities in theATM system.

StateMachine Diagrams Each object in asystemgoesthrough aseriesofdiscrete states.Anobject’scurrentstateis indicatedbythe values of theobject’sattributes at agiven time. Statemachine diagrams (commonlycalled statediagrams)modelkey states of an object andshow underwhatcir- cumstancesthe object changesstate.Unlikethe class diagrams presentedinearliercase studysections,whichfocusedprimarilyonthe structure of thesystem,state diagrams mod- el some of the behavior of thesystem. Figure 25.13isasimplestatediagramthatmodels some of thestates of an objectof class ATM.The UML represents each state in astate diagramasaroundedrectangle with thenameofthe state placed inside it.Asolidcircle with an attachedstick arrowheaddes- ignatesthe initialstate.Recallthatwemodeledthis stateinformation as the Boolean attri- bute userAuthenticated in theclass diagramofFig. 25.12. This attribute is initializedto false,orthe “Usernot authenticated” state, according to thestatediagram.

bank database authenticates user

User notauthenticated User authenticated user exits system

Fig.25.13 | Statediagram forthe ATM object.

Thearrowswithstick arrowheadsindicate transitions betweenstates.Anobjectcan transition from onestate to anotherinresponse to various events that occurinthe system. Thenameordescription of theevent thatcauses atransition is writtennearthe linethat corresponds to thetransition.For example,the ATM objectchangesfrom the“User not authenticated” statetothe “Userauthenticated” state after thedatabase authenticatesthe user.Recallfrom therequirementsdocument that thedatabaseauthenticatesauser by comparingthe account number andPIN enteredbythe user with thoseofthe corre- spondingaccount in thedatabase. If thedatabaseindicates that theuserhas enteredavalid accountnumberand thecorrectPIN, the ATM objecttransitions to the“User authenti- cated” stateand changes its userAuthenticated attributetoavalue of true.Whenthe user exitsthe systembychoosing the“exit”option from themainmenu, the ATM object returnstothe “Usernot authenticated” stateinpreparation forthe next ATMuser. Software EngineeringObservation25.2 Software designers do not generally create statediagramsshowingevery possiblestate and statetransitionfor allattributes—there aresimplytoo many of them.State diagrams typically show onlythe most important or complexstatesand statetransitions.

Activity Diagrams Like astate diagram, an activity diagrammodels aspectsofsystem behavior.Unlikeastate diagram, an activitydiagrammodels an object’s workflow (sequenceofevents)during pro- gramexecution. An activity diagrammodels theactions theobjectwillperform andin what order. RecallthatweusedUML activity diagramstoillustratethe flow of control for thecontrol statements presentedinChapters4and 5. Figure 25.14models theactions involvedinexecuting a BalanceInquiry transaction. We assume that a BalanceInquiry objecthas been initializedand assigned avalid account

© 2012 Pearson Education, Inc., Upper Saddle River, NJ. All Rights Reserved. 25.6 IdentifyingObjects’States andActivities 25-23 number (thatofthe current user), so theobjectknows which balance to retrieve.The dia- gramincludes theactions that occurafterthe user selectsabalance inquiry from themain menu andbefore theATM returns theusertothe main menu—a BalanceInquiry object doesnot perform or initiate theseactions,sowedonot modelthemhere. Thediagram beginswithretrieving the availablebalance of theuser’s account from thedatabase. Next, the BalanceInquiry retrievesthe totalbalance of theaccount.Finally,the transaction dis- playsthe balancesonthe screen.This action completes theexecution of thetransaction.

getavailable balance of user’s account from database

gettotal balance of user’s account from database

displaybalances on screen

Fig.25.14 | Activity diagramfor a BalanceInquiry transaction.

TheUML represents an action in an activity diagramasanaction state modeledbya rectanglewithits leftand right sidesreplacedbyarcs curvingoutward. Each action state contains an action expression—for example, “get available balance of user’s account from database”—that specifiesanaction to be performed.Anarrow with astick arrowhead con- nectstwo action states,indicating theorderinwhichthe actionsrepresented by theaction states occur. Thesolid circle (atthe topofFig. 25.14) represents theactivity’sinitial state—thebeginning of theworkflow before theobjectperformsthe modeledactions.In this case,the transaction firstexecutesthe “get available balance of user’s account from database”action expression.Second, thetransaction retrievesthe totalbalance.Finally,the transaction displays both balancesonthe screen.The solidcircleenclosedinanopencircle (atthe bottomofFig. 25.14) represents thefinal state—theend of theworkflow afterthe object performsthe modeledactions. Figure25.15 showsanactivitydiagramfor a Withdrawal transaction. We assume that a Withdrawal object hasbeenassignedavalidaccount number.Wedonot modelthe user selecting awithdrawalfrom themainmenuorthe ATMreturning the user to themain menu becausethese arenot actionsperformed by a Withdrawal object.The transaction firstdisplays amenuofstandardwithdrawal amounts (Fig.25.3) andanoption to cancel thetransaction. Thetransaction then inputsamenu selection from theuser. Theactivity flow nowarrives at adecisionsymbol. This pointdeterminesthe next action basedonthe associatedguardconditions. If theusercancels thetransaction, thesystem displaysan appropriate message. Next,the cancellation flow reachesamerge symbol,where this activityflowjoins thetransaction’s otherpossibleactivityflows (which we discuss shortly).

displaymenu of withdrawal amounts and option to cancel

input the menu selection

[user canceled transaction] displaycancel message [user selected an amount]

setamount attribute

[amount >available balance] displayerror message [amount <= available balance]

test whether sufficient cash is available in cash dispenser

[insufficient cash available] displayerror message [sufficient cash available]

interact with database to debit amount from user’s account

dispense cash

instruct user to take cash

[cash notdispensed and user did notcancel]

[cash dispensed or user canceled transaction]

Fig. 25.15 | Activity diagramfor a Withdrawal transaction.

Amerge canhave any number of incomingtransition arrows, but only one outgoingtran- sition arrow.The decision at thebottomofthe diagramdetermineswhether thetransac- tion should repeatfrom thebeginning.Whenthe user hascanceledthe transaction, the guardcondition “cashdispensed or user canceled transaction” is true,socontrol transi- tionstothe activity’s finalstate. If theuserselects awithdrawalamountfrom themenu, the transaction sets amount (anattributeofclass Withdrawal originallymodeledinFig.25.12)tothe valuechosenby theuser. Thetransaction next gets theavailable balance of theuser’saccount (i.e.,the availableBalance attribute of theuser’s Account object)fromthe database.The activity flow then arrives at anotherdecision. If therequested withdrawalamount exceedsthe user’s availablebalance,the system displaysanappropriate error messageinforming the user of theproblem. Control then merges with theother activity flowsbefore reachingthe decisionatthe bottomofthe diagram. Theguard decision “cashnot dispensedand user did notcancel” is true,sothe activityflowreturns to the topofthe diagram, andthe trans- action prompts theusertoinput anew amount. If therequested withdrawal amount is less than or equal to theuser’savailablebalance, the transaction testswhether thecashdispenserhas enough cash to satisfythe withdrawal request. If it does not, thetransaction displaysanappropriate errormessage andpasses throughthe mergebeforereachingthe finaldecision.Cashwas notdispensed, so theactivity flow returns to thebeginning of theactivitydiagram, andthe transaction prompts theuser to chooseanewamount. If sufficient cash is available,the transaction interactswiththe data- base to debitthe withdrawalamount from theuser’s account(i.e.,subtractthe amount from both the availableBalance and totalBalance attributesofthe user’s Account object). The transaction then dispensesthe desiredamountofcashand instructsthe user to takethe cash that is dispensed. Themainflowofactivitynextmergeswiththe twoerrorflows andthe can- cellationflow. In this case,cashwas dispensed, so theactivityflowreachesthe final state. We’vetaken the first stepsinmodeling theATM system’s behavior andhaveshown how an object’sattributes participateinthe object’s activities.InSection 25.7,weinvesti- gate theoperationsofour classes to create amore completemodel of thesystem’sbehavior.

Self-ReviewExercises forSection 25.6 25.11 Statewhether thefollowing statementistrue or false,and if false,explain why: Statedia- gramsmodel structural aspects of asystem. 25.12 An activity diagrammodelsthe that an object performs and theorder in which it performs them. a) actions b) attributes c) states d) statetransitions 25.13 Basedonthe requirements document,createanactivitydiagram for adeposit transaction.

25.7IdentifyingClass Operations [Note: This section canbestudied afterChapter6.] In Sections 25.4–25.6, we performed thefirstfew stepsinthe object-oriented design of ourATM system.InSection 25.4,weidentifiedthe classes that we’llneed to implement

© 2012 Pearson Education, Inc., Upper Saddle River, NJ. All Rights Reserved. 25-26 Chapter25ATM Case Study,Part1:Object-Oriented Designwiththe UML andwecreated ourfirst classdiagram. In Section 25.5,wedescribed some attributes of our classes.InSection 25.6,weexaminedobjectstates andmodeledobjectstate transitions andactivities. Now,wedetermine some of theclass operations (or behaviors)neededto implementthe ATMsystem.

IdentifyingOperations An operation is aservice that objectsofaclass provide to clientsofthe class.Considerthe operations of some real-worldobjects.Aradio’s operationsinclude setting itsstation and volume (typically invokedbyaperson adjusting theradio’s controls).Acar’soperations include accelerating (invoked by thedriver pressing the acceleratorpedal), decelerating (invoked by thedriver pressing the brakepedal or releasing thegas pedal), turningand shifting gears. Softwareobjects canoffer operationsaswell—forexample, asoftware graphics object might offeroperationsfor drawing acircle, drawing aline,drawing a squareand thelike. Aspreadsheet softwareobjectmight offer operations like printingthe spreadsheet,totaling theelements in arow or columnand graphing information in the spreadsheet as abar chart or piechart. We canderivemanyofthe operations of each classbyexaminingthe keyverbs and verb phrasesinthe requirements document.Wethenrelate each of thesetoparticular classesinour system (Fig. 25.16).The verb phrasesinFig.25.16 help us determinethe operations of each class.

Class Verbsand verb phrases

ATM executes financial transactions BalanceInquiry [none in therequirements document] Withdrawal [none in therequirements document] Deposit [none in therequirements document] BankDatabase authenticates auser, retrievesanaccountbalance, credits adeposit amount to an account, debits awithdrawalamount from an account Account retrievesanaccountbalance, creditsadepositamount to an account, debits awithdrawalamount from an account Screen displays amessage to theuser Keypad receives numeric inputfromthe user CashDispenser dispensescash,indicates whether it contains enoughcashtosatisfy a withdrawal request DepositSlot receives adeposit envelope

Fig.25.16 | Verbsand verb phrasesfor each classinthe ATMsystem.

Modeling Operations To identifyoperations,weexamine the verb phraseslistedfor each classinFig.25.16.The “executesfinancialtransactions”phrase associatedwithclass ATM impliesthatclass ATM in- structstransactions to execute.Therefore, classes BalanceInquiry, Withdrawal and De- posit each need an operation to provide this servicetothe ATM. We placethisoperation

(which we’venamed execute)inthe thirdcompartment of thethree transaction classesin theupdatedclass diagramofFig. 25.17. DuringanATM session,the ATM objectwillin- voke the execute operation of each transaction objecttotellittoexecute.

ATM Account userAuthenticated :Boolean =false accountNumber :Integer pin :Integer availableBalance :Double totalBalance :Double BalanceInquiry validatePIN() :Boolean accountNumber :Integer getAvailableBalance() :Double execute() getTotalBalance() :Double credit() debit() Withdrawal

accountNumber :Integer Screen amount :Double execute() displayMessage()

Deposit Keypad accountNumber :Integer amount :Double execute() getInput() :Integer

BankDatabase CashDispenser count :Integer =500 authenticateUser() :Boolean dispenseCash() getAvailableBalance() :Double isSufficientCashAvailable() :Boolean getTotalBalance() :Double credit() DepositSlot debit()

isEnvelopeReceived() :Boolean

Fig.25.17 | Classesinthe ATMsystemwithattributesand operations.

TheUML represents operations (whichare implementedasmemberfunctionsin C++) by listing theoperation name,followedbyacomma-separated list of parameters in parentheses, acolon andthe returntype: operationName( parameter1, parameter2, …, parameterN ):return type Each parameterinthe comma-separatedparameterlistconsists of aparametername, fol- lowedbyacolon andthe parametertype: parameterName : parameterType Forthe moment,wedonot list theoperations’parameters—we’ll identifyand model theparametersofsomeofthe operations shortly.For some,wedonot yetknowthe return

© 2012 Pearson Education, Inc., Upper Saddle River, NJ. All Rights Reserved. 25-28 Chapter25ATM Case Study,Part1:Object-Oriented Designwiththe UML types, so we also omit them from thediagram.These omissionsare perfectlynormalatthis point. As ourdesign andimplementation proceed,we’ll addthe remaining return types.

Operations of Class BankDatabase and Class Account Figure 25.16 liststhe phrase “authenticatesauser”nexttoclass BankDatabase—the database is theobjectthatcontains theaccountinformation necessary to determinewhether theac- count number andPIN enteredbyausermatchthoseofanaccountheldatthe bank.There- fore,class BankDatabase needsanoperation that providesanauthentication servicetothe ATM. We placethe operation authenticateUser in thethirdcompartment of class Bank- Database (Fig. 25.17).However,anobjectofclass Account,not class BankDatabase,stores theaccount number andPIN that mustbeaccessed to authenticate auser, so class Account mustprovide aservice to validate aPIN obtainedthrough user input against aPIN stored in an Account object.Therefore,weadd a validatePIN operation to class Account.Wespecify return type Boolean forthe authenticateUser and validatePIN operations. Each opera- tion returns avalue indicatingeitherthatthe operation wassuccessful in performing itstask (i.e.,areturnvalue of true)orthatitwas not(i.e.,areturnvalue of false). Figure 25.16lists several additional verb phrasesfor class BankDatabase:“retrieves an accountbalance,” “credits adeposit amount to an account” and “debitsawithdrawal amount from an account.” Like “authenticatesauser,” theseremainingphrasesrefer to services that thedatabasemustprovide to theATM,because thedatabaseholds allthe accountdata used to authenticate auserand perform ATMtransactions.However,objects of class Account actually perform theoperationstowhichthese phrasesrefer.Thus, we assign an operation to both class BankDatabase andclass Account to correspondtoeach of thesephrases. Recallfrom Section 25.4 that, becauseabank account contains sensitive information,wedonot allowthe ATMtoaccessaccountsdirectly.The databaseactsasan intermediary betweenthe ATMand the account data,thuspreventing unauthorized access .Aswe’ll seeinSection 25.8,class ATM invokesthe operationsofclass BankDatabase, each of which in turn invokes theoperation with thesamenameinclass Account. Thephrase “retrieves an account balance”suggeststhatclasses BankDatabase and Account each need a getBalance operation.However,recallthatwecreated twoattributes in class Account to representabalance—availableBalance and totalBalance.Abalance inquiry requires access to both balance attributessothatitcan display them to theuser, butawithdrawalneeds to check only thevalue of availableBalance.Toallow objectsin thesystemtoobtaineachbalance attributeindividually,weadd operations getAvail- ableBalance and getTotalBalance to thethirdcompartment of classes BankDatabase and Account (Fig. 25.17).WespecifyareturntypeofDouble foreachofthese operations, becausethe balance attributes which they retrieve areoftype Double. Thephrases “creditsadepositamounttoanaccount”and “debitsawithdrawal amount fromanaccount”indicate that classes BankDatabase and Account mustperform operations to update an account during adeposit andwithdrawal,respectively. We there- fore assign credit and debit operations to classes BankDatabase and Account.You may recall that crediting an account (asinadeposit) adds an amountonlytothe totalBalance attribute.Debiting an account (asinawithdrawal),onthe otherhand,subtracts the amount frombothbalance attributes.Wehidethese implementation detailsinside class Account.This is agood example of encapsulation andinformation hiding. If this were arealATM system, classes BankDatabase and Account wouldalsoprovide aset of operationstoallowanother bankingsystemtoupdate auser’s account balance after

© 2012 Pearson Education, Inc., Upper Saddle River, NJ. All Rights Reserved. 25.7Identifying ClassOperations 25-29 either confirming or rejecting allorpartofadeposit. Operation confirmDepositAmount, forexample,would addanamount to the availableBalance attribute, thus making depositedfunds availablefor withdrawal. Operation rejectDepositAmount wouldsub- tractanamountfromthe totalBalance attribute to indicate that aspecifiedamount, which hadrecently been depositedthrough theATM andadded to the totalBalance,was notfound in thedeposit envelope.The bank wouldinvokethis operation after deter- mining either that theuserfailed to includethe correct amountofcash or that anychecks did not clear(i.e,they“bounced”). While addingthese operations wouldmakeour system more complete, we do notinclude them in ourclass diagrams or ourimplementation becausetheyare beyond the scopeofthe case study.

Operations of Class Screen Class Screen “displays amessage to theuser” at varioustimes in an ATMsession. Allvisual outputoccurs through thescreen of theATM.The requirementsdocument describes many typesofmessages(e.g.,awelcomemessage,anerror message, athank youmessage) that thescreen displaystothe user.The requirements document also indicatesthatthe screen displays promptsand menustothe user.However,aprompt is really just amessage describingwhatthe user should input next, and amenuisessentially atypeofprompt con- sistingofaseries of messages (i.e.,menuoptions) displayed consecutively.Therefore, rath- er than assign class Screen an individualoperation to display each type of message, prompt andmenu, we simplycreate oneoperation that candisplay anymessage specifiedbyapa- rameter. We placethis operation (displayMessage)inthe thirdcompartment of class Screen in ourclass diagram(Fig.25.17). We do not worry aboutthe parameterofthis operation at this time—wemodelthe parameter laterinthis section.

Operations of Class Keypad From thephrase “receivesnumeric input from theuser” listedbyclass Keypad in Fig. 25.16, we concludethatclass Keypad should performagetInput operation. Because theATM’s keypad,unlikeacomputerkeyboard, containsonlythe numbers0–9, we specifythatthis operation returnsaninteger value.Recallfromthe requirements document that in different situationsthe user mayberequiredtoenteradifferenttype of number (e.g., an account number,aPIN, thenumberofamenu option,adepositamountasanumber of cents). Class Keypad simplyobtains anumeric valuefor aclientofthe class—it does not determine whetherthe value meetsany specific criteria.Any classthatusesthisoperation must verify that theuserenters appropriate numbers,and if not,display error messages viaclass Screen). [Note: Whenweimplementthe system,wesimulate theATM’skeypad with a computerkeyboard, andfor simplicityweassumethatthe user doesnot enternonnumeric inputusing keys on thecomputerkeyboardthatdonot appear on theATM’s keypad.]

Operations of Class CashDispenser and Class DepositSlot Figure 25.16lists “dispenses cash”for class CashDispenser.Therefore,wecreate opera- tion dispenseCash andlistitunder class CashDispenser in Fig. 25.17. Class CashDis- penser also “indicates whetheritcontains enough cash to satisfyawithdrawalrequest.” Thus,weinclude isSufficientCashAvailable,anoperation that returnsavalueofUML type Boolean,inclass CashDispenser.Figure25.16 also lists“receives adeposit envelope” forclass DepositSlot.The depositslotmustindicate whetheritreceivedanenvelope,so we placeanoperation isEnvelopeReceived,which returnsaBoolean value, in thethird

© 2012 Pearson Education, Inc., Upper Saddle River, NJ. All Rights Reserved. 25-30 Chapter25ATM Case Study,Part1:Object-Oriented Designwiththe UML compartment of class DepositSlot.[Note: Arealhardwaredeposit slot wouldmostlikely send theATM asignaltoindicate that an envelope wasreceived. We simulatethis behav- ior,however,withanoperation in class DepositSlot that class ATM caninvoketofindout whetherthe deposit slot received an envelope.]

Operations of Class ATM We do not list anyoperationsfor class ATM at this time.Weare notyet aware of anyservices thatclass ATM provides to otherclasses in thesystem. Whenweimplementthe system with C++code,however,operations of this class, andadditional operations of theother classes in thesystem, may emerge.

Identifyingand Modeling OperationParameters So far, we’venot been concernedwiththe parameters of ouroperations—we’ve attempted to gain only abasic understanding of theoperations of each class. Let’snow takeacloser look at some operation parameters. We identifyanoperation’s parametersbyexamining what data theoperation requirestoperform itsassigned task. Considerthe authenticateUser operation of class BankDatabase.Toauthenticate a user,this operation mustknowthe account number andPIN supplied by theuser. Thus we specifythatoperation authenticateUser takesinteger parameters userAccountNumber and userPIN,whichthe operation must compare to theaccount number andPIN of an Account objectinthe database.Weprefixthese parameternames with “user”toavoid con- fusion betweenthe operation’s parameter namesand the attribute namesthatbelongto class Account.Welistthese parameters in theclass diagraminFig.25.18 that models only class BankDatabase.[Note: It’s perfectlynormal to modelonlyone classinaclassdiagram. In this case,weare most concernedwithexaminingthe parameters of this one classinpar- ticular, so we omit theother classes.Inclass diagrams laterinthe case study, in which parameters arenolongerthe focusofour attention, we omit theparameters to save space. Remember,however,thatthe operationslistedinthese diagramsstill have parameters.] Recall that theUML models each parameter in an operation’s comma-separated parameter list by listingthe parameter name, followed by acolon andthe parametertype (inUML notation). Figure 25.18thusspecifiesthatoperation authenticateUser takes two parameters—userAccountNumber and userPIN,bothoftype Integer.Whenwe implementthe system in C++, we’ll representthese parameterswith int values.

BankDatabase

authenticateUser( userAccountNumber :Integer,userPIN :Integer ):Boolean getAvailableBalance( userAccountNumber :Integer ):Double getTotalBalance( userAccountNumber :Integer ):Double credit( userAccountNumber :Integer,amount :Double ) debit( userAccountNumber :Integer,amount :Double )

Fig.25.18 | Class BankDatabase withoperation parameters.

Class BankDatabase operations getAvailableBalance, getTotalBalance, credit and debit also each require a userAccountNumber parameter to identify theaccount to

© 2012 Pearson Education, Inc., Upper Saddle River, NJ. All Rights Reserved. 25.7Identifying ClassOperations 25-31 which thedatabase must applythe operations, so we includethese parameters in theclass diagramofFig. 25.18. In addition,operations credit and debit each require a Double parameter amount to specifythe amount of moneytobecredited or debited, respectively. Theclass diagraminFig. 25.19models theparameters of class Account’s operations. Operation validatePIN requiresonlyauserPIN parameter,whichcontains the user-spec- ifiedPIN to be comparedwiththe PINassociatedwiththe account.Liketheir counter- partsinclass BankDatabase,operations credit and debit in class Account each require a Double parameter amount that indicatesthe amountofmoney involvedinthe operation. Operations getAvailableBalance and getTotalBalance in class Account require no additional data to perform theirtasks.Class Account’s operations do not require an accountnumberparameter—each of theseoperations canbeinvoked only on aspecific Account object, so including aparameter to specifyanAccount is unnecessary.

Account accountNumber :Integer pin :Integer availableBalance :Double totalBalance :Double validatePIN( userPIN: Integer) :Boolean getAvailableBalance() :Double getTotalBalance() :Double credit( amount :Double ) debit( amount :Double )

Fig.25.19 | Class Account withoperation parameters.

Figure 25.20models class Screen with aparameter specifiedfor operation display- Message.This operation requiresonlyaString parameter message that indicatesthe text to be displayed.Recallthatthe parametertypeslistedinour classdiagrams areinUML notation,sothe String type listed in Fig. 25.20referstothe UMLtype.Whenweimple- ment thesysteminC++,we’ll in factuse aC++ string objecttorepresent thisparameter.

displayMessage( message:String )

Fig.25.20 | Class Screen withoperation parameters.

Theclass diagraminFig.25.21 specifiesthatoperation dispenseCash of class Cash- Dispenser takesaDouble parameter amount to indicate theamountofcash(in dollars)to be dispensed. Operation isSufficientCashAvailable also takesaDouble parameter amount to indicate theamountofcash in question. We do notdiscuss parameters foroperation execute of classes BalanceInquiry, Withdrawal and Deposit,operation getInput of class Keypad andoperation isEnvelope- Received of class DepositSlot.Atthis point in ourdesign process, we cannot determine

CashDispenser count :Integer =500 dispenseCash(amount :Double ) isSufficientCashAvailable( amount :Double ):Boolean

Fig.25.21 | Class CashDispenser with operationparameters. whetherthese operations require additional data to perform theirtasks,soweleave their parameterlists empty. As we progress through thecasestudy,wemay decide to addparam- eterstothese operations. In this section, we’vedeterminedmanyofthe operations performed by theclasses in theATM system.We’ve identifiedthe parametersand return typesofsomeofthe opera- tions. As we continue ourdesign process,the number of operationsbelonging to each class mayvary—we might find that newoperations areneeded or that some currentoperations areunnecessary—andwemight determinethatsomeofour class operations need addi- tional parameters anddifferent return types.

Self-ReviewExercises forSection 25.7 25.14 Whichofthe followingisnot abehavior? a) readingdatafromafile b) printing output c) text output d) obtaininginput from theuser 25.15 If youwere to addtothe ATMsystem an operationthatreturnsthe amount attributeofclass Withdrawal,how and wherewouldyou specifythisoperation in theclass diagramofFig.25.17? 25.16 Describethe meaning of thefollowing operation listingthatmight appear in aclass diagram for an object-oriented design of acalculator:

add( x:Integer, y:Integer ):Integer

25.8IndicatingCollaborationAmong Objects [Note: This section canbestudied afterChapter7.] In this section, we concentrate on thecollaborations(interactions) amongobjects in our ATMsystem. When twoobjects communicatewitheachother to accomplishatask,they aresaidtocollaborate—theydothis by invoking oneanother’s operations.Acollabora- tion consistsofanobjectofone classsending a message to an objectofanotherclass.Mes- sagesare sent in C++via member-function calls. In Section 25.7,wedeterminedmanyofthe operations of thesystem’sclasses.Next, we concentrate on the messages thatinvokethese operations.Toidentifythe collabora- tions, we return to therequirements document in Section 25.3.Recallthatthis document specifiesthe rangeofactivitiesthatoccurduringanATM session (e.g., authenticating a user,performingtransactions). Thesteps used to describehow thesystemmustperform each of thesetasks areour firstindication of thecollaborationsinour system.Aswepro- ceedthrough this andthe remaining sections, we maydiscover additional collaborations.

Identifyingthe Collaborations in aSystem We identify thecollaborationsinthe systembycarefully reading therequirementsdocu- ment sections that specifywhatthe ATMshould do to authenticate auserand to perform each transaction type. Foreachaction or step described,wedecidewhichobjects in our system must interacttoachievethe desired result.Weidentifyone object as the sending object (i.e., theobjectthatsends themessage)and anotherasthe receivingobject (i.e., the object that offers that operation to clientsofthe class).Wethenselectone of thereceiving object’s operations(identifiedinSection 25.7)thatmust be invoked by thesending object to produce theproper behavior. For example, theATM displaysawelcomemessage when idle. We know that an object of class Screen displaysamessagetothe user viaits dis- playMessage operation. Thus,wedecidethatthe system candisplay awelcomemessage by employingacollaboration betweenthe ATM andthe Screen in which the ATM sendsa displayMessage messagetothe Screen by invoking the displayMessage operation of class Screen.[Note: To avoid repeating thephrase “an objectofclass…,”werefer to each object simply by using itsclass name preceded by an article(“a,” “an”or“the”)—forex- ample, “the ATM”referstoanobjectofclass ATM.] Figure 25.22lists thecollaborationsthatcan be derivedfromthe requirements docu- ment.For each sending object,welistthe collaborationsinthe orderinwhichtheyare discussed in therequirements document.Welisteachcollaboration involving aunique sender,message andrecipient only once,eventhoughthe collaboration mayoccurseveral timesduringanATM session. For example,the firstrow in Fig. 25.22indicatesthatthe ATM collaborateswiththe Screen whenever the ATM needstodisplay amessage to theuser.

to an object An object of class… sends themessage… of class…

ATM displayMessage Screen getInput Keypad authenticateUser BankDatabase execute BalanceInquiry execute Withdrawal execute Deposit BalanceInquiry getAvailableBalance BankDatabase getTotalBalance BankDatabase displayMessage Screen Withdrawal displayMessage Screen getInput Keypad getAvailableBalance BankDatabase isSufficientCashAvailable CashDispenser debit BankDatabase dispenseCash CashDispenser Deposit displayMessage Screen getInput Keypad isEnvelopeReceived DepositSlot credit BankDatabase

Fig. 25.22 | Collaborationsinthe ATMsystem. (Part1of 2.)

BankDatabase validatePIN Account getAvailableBalance Account getTotalBalance Account debit Account credit Account

Fig. 25.22 | Collaborationsinthe ATMsystem. (Part2of 2.)

Let’sconsiderthe collaborationsinFig.25.22.Beforeallowingauser to perform any transactions,the ATMmustpromptthe user to enteranaccount number,thentoenter a PIN. It accomplisheseachofthese tasksbysending a displayMessage messagetothe Screen.Bothofthese actionsrefer to thesame collaboration between the ATM andthe Screen,which is alreadylistedinFig.25.22.The ATM obtains input in response to a prompt by sending a getInput messagetothe Keypad.Next, theATM must determine whetherthe user-specifiedaccount number andPIN matchthose of an accountinthe database.Itdoessobysending an authenticateUser messagetothe BankDatabase.Recall that the BankDatabase cannotauthenticate auserdirectly—only theuser’s Account (i.e., the Account that contains the account number specifiedbythe user)can access theuser’s PIN to authenticate theuser. Figure 25.22therefore listsacollaboration in which the BankDatabase sendsavalidatePIN messagetoanAccount. Afterthe user is authenticated, the ATM displays themainmenubysending aseries of displayMessage messagestothe Screen andobtains input containing amenuselection by sendingagetInput message to the Keypad.We’ve alreadyaccounted forthese collabora- tions. Afterthe userchoosesatype of transactiontoperform,the ATM executesthe transac- tion by sendinganexecute message to an objectofthe appropriate transactionclass (i.e., a BalanceInquiry,aWithdrawal or a Deposit). For example, if theuserchoosestoper- form abalance inquiry, the ATM sendsanexecute message to a BalanceInquiry. Furtherexamination of therequirementsdocument revealsthe collaborations involved in executing each transaction type.ABalanceInquiry retrievesthe amount of moneyavailable in theuser’s account by sending a getAvailableBalance messagetothe BankDatabase,whichrespondsbysending a getAvailableBalance messagetothe user’s Account.Similarly,the BalanceInquiry retrievesthe amount of moneyondeposit by sendingagetTotalBalance messagetothe BankDatabase,whichsends thesame message to theuser’s Account.Todisplay both measures of theuser’sbalance at thesame time,the BalanceInquiry sendsadisplayMessage messagetothe Screen. A Withdrawal sendsthe Screen several displayMessage messages to display amenu of standard withdrawalamounts (i.e.,$20,$40,$60,$100, $200). The Withdrawal sends the Keypad a getInput messagetoobtainthe user’s menu selection, then determines whetherthe requestedwithdrawal amountislessthanorequal to theuser’s accountbal- ance.The Withdrawal canobtainthe amount of moneyavailable in theaccount by sendingthe BankDatabase a getAvailableBalance message. The Withdrawal then tests whetherthe cash dispenser contains enough cash by sendingthe CashDispenser an isSufficientCashAvailable message. A Withdrawal sendsthe BankDatabase a debit

© 2012 Pearson Education, Inc., Upper Saddle River, NJ. All Rights Reserved. 25.8Indicating Collaboration AmongObjects 25-35 messagetodecreasethe user’s account balance.The BankDatabase sendsthe same message to theappropriate Account.Recallthatdebitingfunds from an Account decreases both the totalBalance andthe availableBalance.Todispense therequested amountofcash, the Withdrawal sendsthe CashDispenser a dispenseCash message. Finally, the Withdrawal sendsadisplayMessage messagetothe Screen,instructing theusertotakethe cash. A Deposit responds to an execute messagefirstbysending a displayMessage mes- sage to the Screen to prompt theuserfor adeposit amount. The Deposit sendsaget- Input messagetothe Keypad to obtain theuser’s input. The Deposit then sendsa displayMessage message to the Screen to tell theusertoinsertadeposit envelope.To determinewhether thedeposit slot received an incoming depositenvelope, the Deposit sendsanisEnvelopeReceived messagetothe DepositSlot.The Deposit updatesthe user’s account by sending a credit messagetothe BankDatabase,whichsubsequently sendsacredit messagetothe user’s Account.Recallthatcrediting funds to an Account increases the totalBalance butnot the availableBalance.

InteractionDiagrams Now that we’veidentifiedpossiblecollaborationsbetween theobjects in ourATM system, let’s graphically modelthese interactionsusing theUML.Several types of interaction di- agrams modelthe behavior of asystembyshowing how objectsinteractwithone another. The communication diagram emphasizeswhichobjects participate in collaborations. [Note: Communication diagrams were called collaborationdiagrams in earlierversionsof theUML.] Like thecommunication diagram,the sequencediagram showscollaborations amongobjects,but it emphasizes when messages aresentbetween objects over time.

CommunicationDiagrams Figure 25.23shows acommunication diagramthatmodels the ATM executing a BalanceInquiry.Objects aremodeledinthe UMLasrectangles containing namesinthe form objectName :ClassName.Inthis example, which involvesonlyone objectofeach type,wedisregard theobjectnameand listonlyacolon followedbythe class name.[Note: Specifying the name of each objectinacommunication diagram is recommended when modeling multipleobjects of thesametype.] Communicating objects areconnectedwith solidlines,and messages arepassedbetween objectsalong theselinesinthe direction shownbyarrows. Thenameofthe message, which appearsnexttothe arrow,isthe name of an operation (i.e.,amember function)belonging to the receivingobject— think of the name as aservice thatthe receivingobjectprovides to sending objects (its“clients”).

execute() :ATM :BalanceInquiry

Fig.25.23 | Communicationdiagram of theATM executingabalance inquiry.

Thesolid filled arrow in Fig. 25.23represents amessage—or synchronous call—in theUML andafunctioncallinC++.This arrowindicatesthatthe flow of control is from thesending object (the ATM)tothe receivingobject(aBalanceInquiry). Sincethisisasyn- chronouscall, thesending object maynot send anothermessage,ordoanythingatall, until the receiving object processesthe message andreturns control to thesending object—the sender just

© 2012 Pearson Education, Inc., Upper Saddle River, NJ. All Rights Reserved. 25-36 Chapter25ATM Case Study,Part1:Object-Oriented Designwiththe UML waits. For example,inFig.25.23,the ATM calls member function execute of a BalanceIn- quiry andmay notsendanothermessage until execute hasfinishedand returnscontrol to the ATM.[Note: If this were an asynchronous call,representedbyastick arrowhead,the sendingobjectwould nothave to wait forthe receivingobjecttoreturncontrol—it would continuesending additional messages immediately following the asynchronouscall. Asyn- chronouscalls oftencan be implementedinC++ using platform-specific librariesprovided with your compiler. Suchtechniques arebeyondthe scopeofthis book.]

Sequence of MessagesinaCommunicationDiagram Figure 25.24showsacommunication diagramthatmodelsthe interactionsamong objects in thesystem when an object of class BalanceInquiry executes.Weassume that theobject’s accountNumber attribute contains the accountnumberofthe current user.The collabora- tionsinFig.25.24 begin afterthe ATM sendsanexecute messagetoaBalanceInquiry (i.e., theinteraction modeledinFig.25.23). Thenumbertothe left of amessage name indicates theorderinwhichthe messageispassed. The sequenceofmessages in acommunication diagramprogressesinnumerical orderfrom leasttogreatest.Inthisdiagram,the number- ing starts with message 1 andendswithmessage 3.The BalanceInquiry firstsends a getAvailableBalance messagetothe BankDatabase (message 1), then sendsagetTotal- Balance message to the BankDatabase (message 2). Within theparentheses following a messagename, we canspecifyacomma-separatedlistofthe namesofthe parameters sent with themessage (i.e.,arguments in aC++ function call)—the BalanceInquiry passesat- tribute accountNumber with itsmessagestothe BankDatabase to indicatewhich Account’s balance information to retrieve.Recallfrom Fig. 25.18thatoperations getAvailableBal- ance and getTotalBalance of class BankDatabase each require aparametertoidentifyan account.The BalanceInquiry next displaysthe availableBalance andthe totalBalance to theuserbypassing a displayMessage message to the Screen (message 3)thatincludes aparameterindicating the message to be displayed.

3: displayMessage( message)

:BalanceInquiry

1: getAvailableBalance( accountNumber ) 2: getTotalBalance( accountNumber )

:BankDatabase :Account

1.1: getAvailableBalance() 2.1: getTotalBalance()

Fig.25.24 | Communicationdiagram forexecuting abalance inquiry.

Figure 25.24models twoadditional messages passing from the BankDatabase to an Account (message 1.1 andmessage 2.1). To provide the ATM with thetwo balancesofthe user’s Account (asrequestedbymessages 1 and 2), the BankDatabase must passa getAvailableBalance andagetTotalBalance messagetothe user’s Account.Messages passed within thehandling of anothermessage arecalled nested messages.The UMLrec- ommendsusing adecimal numbering scheme to indicate nested messages.For example, message 1.1 is thefirst messagenestedinmessage 1—the BankDatabase passes a get- AvailableBalance messagewhile processing BankDatabase’s messageofthe same name. [Note: If the BankDatabase needed to pass asecondnestedmessage whileprocessing mes- sage 1,the second message wouldbenumbered 1.2.] Amessage maybepassedonlywhen allthe nested messages from thepreviousmessage have been passed—e.g.,the BalanceIn- quiry passes message 3 only aftermessages 2 and 2.1 have been passed, in that order. Thenestednumberingscheme used in communication diagrams helpsclarify pre- ciselywhenand in what contexteachmessage is passed. For example, if we numbered the messages in Fig. 25.24using aflatnumberingscheme (i.e., 1, 2, 3, 4, 5), someonelooking at thediagrammight not be able to determinethat BankDatabase passesthe getAvailableBalance message(message 1.1)toanAccount during the BankDatabase’s processing of message 1,asopposedtoafter completing theprocessing of message 1.The nested decimalnumbers makeitclear that thesecond getAvailableBalance message (message 1.1)ispassedtoanAccount within thehandling of thefirst getAvailableBal- ance message(message 1)bythe BankDatabase. Sequence Diagrams Communication diagrams emphasize theparticipantsincollaborationsbut modeltheir timing abit awkwardly.Asequence diagram helpsmodelthe timing of collaborations more clearly.Figure25.25 showsasequence diagram modeling thesequenceofinterac- tionsthatoccurwhenaWithdrawal executes.The dottedline extending down from an object’s rectangleisthatobject’s lifeline,whichrepresentsthe progression of time.Actions typically occuralong an object’s lifeline in chronological order from toptobottom—an ac- tion near thetop typically happens before onenearthe bottom. Messagepassing in sequence diagrams is similartomessage passing in communica- tion diagrams.Asolidarrow with afilled arrowhead extendingfrom thesending object to thereceivingobjectrepresentsamessagebetween twoobjects.The arrowheadpointstoan activation on thereceivingobject’slifeline.Anactivation,shownasathin vertical rect- angle, indicatesthatanobjectisexecuting. When an object returnscontrol,areturnmes- sage,representedasadashed line with astick arrowhead,extends from theactivation of theobjectreturning control to theactivation of theobjectthatinitially sent the message. To eliminate clutter, we omit thereturn-messagearrows—theUML allows this practice to make diagrams more readable. Like communication diagrams,sequence diagrams can indicate messageparameters betweenthe parentheses following amessage name. Thesequence of messages in Fig. 25.25beginswhenaWithdrawal prompts theuser to chooseawithdrawal amount by sending a displayMessage messagetothe Screen.The Withdrawal then sendsagetInput messagetothe Keypad,whichobtains input from the user.We’ve alreadymodeledthe controllogic involved in a Withdrawal in theactivitydia- gramofFig. 25.15, so we do notshow this logic in thesequence diagram of Fig.25.25. Instead, we modelthe best-case scenario in which thebalance of theuser’s account is greaterthanorequal to thechosenwithdrawal amount, andthe cash dispenser contains a

:Withdrawal :Keypad :Account

:Screen :BankDatabase :CashDispenser

displayMessage( message)

getAvailableBalance( accountNumber ) getAvailableBalance()

isSufficientCashAvailable( amount )

debit( accountNumber,amount ) debit( amount )

dispenseCash( amount )

Fig.25.25 | Sequencediagram that models a Withdrawal executing. sufficient amount of cash to satisfythe request. For information on how to modelcontrol logic in asequence diagram, please refertothe webresourcesatthe endofSection 25.3. Afterobtaining awithdrawalamount,the Withdrawal sendsagetAvailableBalance messagetothe BankDatabase,whichinturnsends a getAvailableBalance messagetothe user’s Account.Assumingthatthe user’s account hasenoughmoney available to permit thetransaction,the Withdrawal next sendsanisSufficientCashAvailable messageto the CashDispenser.Assumingthatthere is enough cash available, the Withdrawal decreases thebalance of theuser’saccount (i.e.,boththe totalBalance andthe avail- ableBalance)bysending a debit messagetothe BankDatabase.The BankDatabase responds by sending a debit message to theuser’s Account.Finally,the Withdrawal sends a dispenseCash messagetothe CashDispenser andadisplayMessage messagetothe Screen,telling theusertoremovethe cash from themachine.

We’veidentifiedthe collaborationsamong theATM system’s objects andmodeled some of them using UMLinteraction diagrams—bothcommunication diagramsand sequence diagrams. In Section 26.2, we enhance thestructure of ourmodeltocompletea preliminary object-oriented design,thenweimplement theATM system in C++. Self-ReviewExercises forSection 25.8 25.17 A(n) consists of an object of one classsending amessage to an objectofanother class. a) association b) aggregation c) collaboration d) composition 25.18 Whichformofinteraction diagramemphasizes what collaborations occur?Which form em- phasizes when collaborations occur? 25.19 Create asequencediagram that models theinteractions amongobjectsinthe ATMsystem that occurwhenaDeposit executes successfully, and explain thesequenceofmessagesmodeled by thediagram. 25.9Wrap-Up In this chapter, youlearned how to work from adetailedrequirements document to de- velopanobject-oriented design.You worked with sixpopular typesofUML diagrams to graphicallymodelanobject-orientedautomated teller machine softwaresystem. In Section 26.3,wetunethe design using inheritance,thencompletelyimplementthe design in an 850-line C++application.

AnswerstoSelf-Review Exercises 25.1 Figure 25.26 shows ause case diagram foramodified version of ourATM system that alsoallows userstotransfermoney betweenaccounts. 25.2 b. 25.3 d.

Deposit Funds

User Transfer Funds Between Accounts

Fig. 25.26 | Usecasediagram foramodifiedversion of ourATM system that also allows userstotransfermoney betweenaccounts.

25.4 [Note: Answersmay vary.] Figure 25.27presentsaclassdiagram that showssomeofthe compositionrelationships of aclass Car. 25.5 c. [Note: In acomputer network, this relationship could be many-to-many.] 25.6 True. 25.7 Figure25.28 presents an ATM classdiagram includingclass Deposit insteadofclass With- drawal.Notethat Deposit does not access CashDispenser,but does access DepositSlot.

151 1 SteeringWheel Car SeatBelt

Fig.25.27 | Classdiagram showingcompositionrelationships of aclass Car.

1 1 1 Keypad CashDispenser

1 DepositSlot Screen 1 1 1

1111 0..1 0..10..1 Executes ATM Deposit 0..1 1 0..1 Authenticates user against 1

BankDatabase Accesses/modifies an account balance through 1 Contains 0..*

Fig. 25.28 | Class diagram forthe ATMsystemmodel includingclass Deposit.

25.8 b. 25.9 c. Fly is an operationorbehaviorofanairplane,not an attribute. 25.10 This indicates that count is an Integer with an initialvalue of 500.Thisattribute keeps trackofthe numberofbills availableinthe CashDispenser at any giventime. 25.11 False. Statediagramsmodel some of thebehaviorofasystem. 25.12 a. 25.13 Figure25.29’s activity diagrammodelsthe actions that occurafter theuserchooses thede- positoptionfromthe main menu and before theATM returnsthe usertothe main menu. Recall that part of receiving adeposit amount from theuserinvolves convertinganintegernumberofcents to adollaramount.Also recall that creditingadepositamounttoanaccount involves increasing onlythe totalBalance attributeofthe user’s Account object. Thebankupdates the availableBal-

prompt user to enter adeposit amount or cancel

receiveinput from user

[usercanceledtransaction]

[userentered an amount]

displaycancel message setamount attribute

instruct user to insertdeposit envelope

attempt to receivedeposit envelope

[deposit envelope notreceived] [deposit envelope received]

interact with database displayerror message to credit amount to user’s account

Fig. 25.29 | Activity diagramfor a Deposit transaction.

ance attributeofthe user’s Account objectonlyafter confirmingthe amount of cash in thedeposit envelope and after theenclosedchecksclear—thisoccursindependently of theATM system. 25.14 c. 25.15 To specify an operationthatretrievesthe amount attributeofclass Withdrawal,the following operation would be placed in theoperation (i.e., third) compartmentofclass Withdrawal: getAmount( ):Double

25.16 This is an operationnamed add that takesintegers x and y as parameters and returnsanin- tegervalue. 25.17 c. 25.18 Communication diagrams emphasize what collaborations occur. Sequence diagrams em- phasize when collaborations occur. 25.19 Figure 25.30presents asequence diagramthatmodelsthe interactions between objectsthat occurwhenaDeposit executes successfully. A Deposit firstsends a displayMessage messagetothe Screen to askthe user to enter adeposit amount.Next, it sendsagetInput messagetothe Keypad to receive inputfromthe user. Then, it instructsthe user to insert adeposit envelope by sendinga displayMessage messagetothe Screen.Itthen sendsanisEnvelopeReceived messagetothe Depos- itSlot to confirm that the deposit envelope hasbeen received.Finally,itincreasesthe totalBalance attribute(butnot the availableBalance attribute) of theuser’s Account by sendingacredit message to the BankDatabase.The BankDatabase respondsbysendingthe same messagetothe user’s Account.

:Deposit :Keypad :BankDatabase

:Screen :DepositSlot :Account

isEnvelopeReceived()

credit( accountNumber,amount ) credit( amount )

Fig.25.30 | Sequencediagram that models a Deposit executing.

UML diagrams for ATM application

Case Studies »
UML diagrams for ATM application »

ATM application

Read the following documents/reports to understand the problem statement, requirements and other necessary things related to the ATM application: Doc1 , Doc2 , Doc3 , Doc4 , Doc5

1 Use case diagram
2 Class diagram
3 Sequence diagram
4 Collaboration diagram
5 Statechart diagram
6 Activity diagram
7 Component diagram
8 Deployment diagram

Use case diagram

Class diagram, sequence diagram, collaboration diagram, statechart diagram, activity diagram, component diagram, deployment diagram.

How useful was this post?

Click on a star to rate it!

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?

Suryateja Pericherla, at present is a Research Scholar (full-time Ph.D.) in the Dept. of Computer Science & Systems Engineering at Andhra University, Visakhapatnam. Previously worked as an Associate Professor in the Dept. of CSE at Vishnu Institute of Technology, India.

He has 11+ years of teaching experience and is an individual researcher whose research interests are Cloud Computing, Internet of Things, Computer Security, Network Security and Blockchain.

He is a member of professional societies like IEEE, ACM, CSI and ISCA. He published several research papers which are indexed by SCIE, WoS, Scopus, Springer and others.

UML Diagrams for Online Banking System
UML Diagrams for Online Book Shop
UML diagrams for document editor
UML diagrams for library management system
UML diagrams for railway reservation system
Introduction to Rational Rose
« Previous Post
Next Post »

27 Comments

You can follow any responses to this entry through the RSS 2.0 feed.

« Older Comments

love you ho gya sir g

That’s a great content sir

Hello startertutorials.com admin, Your posts are always informative and up-to-date.

are you blind those are diagrams

To the startertutorials.com webmaster, Your posts are always well organized and easy to understand.

i need diagrams

What diagrams?

bro its osm but we need theoretically explanation

pelam article h sir!! garib baccho ka masiha, aise hi articles pelte raho

nice explain sir plz give me report sir

State Transition Diagram for an ATM System

State Transition Diagram are also known as Dynamic models. As the name suggests, it is a type of diagram that is used to represent different transition (changing) states of a System. It is generally used to graphically represent all possible transition states a system can have and model such systems. It is very essential and important and right for object-oriented modeling from the beginning. The System consists of various states that are being represented using various symbols in the state transition diagram. You can see the symbols and their description given below :

Type of State	Description
Initial State	In a System, it represents Starting state.
Final State	In a System, it represents Ending state.
Simple State	In a System, it represents a Simple state with no substructure.
Composite State	In a System, it represents a Composite state with two or more parallel or concurrent states out of which only one state will be active at a time and other states will be inactive.

Please Login to comment...

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

Information

Author Services

Initiatives

You are accessing a machine-readable page. In order to be human-readable, please install an RSS reader.

All articles published by MDPI are made immediately available worldwide under an open access license. No special permission is required to reuse all or part of the article published by MDPI, including figures and tables. For articles published under an open access Creative Common CC BY license, any part of the article may be reused without permission provided that the original article is clearly cited. For more information, please refer to https://www.mdpi.com/openaccess .

Feature papers represent the most advanced research with significant potential for high impact in the field. A Feature Paper should be a substantial original Article that involves several techniques or approaches, provides an outlook for future research directions and describes possible research applications.

Feature papers are submitted upon individual invitation or recommendation by the scientific editors and must receive positive feedback from the reviewers.

Editor’s Choice articles are based on recommendations by the scientific editors of MDPI journals from around the world. Editors select a small number of articles recently published in the journal that they believe will be particularly interesting to readers, or important in the respective research area. The aim is to provide a snapshot of some of the most exciting work published in the various research areas of the journal.

Original Submission Date Received: .

Active Journals
Find a Journal
Proceedings Series
For Authors
For Reviewers
For Editors
For Librarians
For Publishers
For Societies
For Conference Organizers
Open Access Policy
Institutional Open Access Program
Special Issues Guidelines
Editorial Process
Research and Publication Ethics
Article Processing Charges
Testimonials
Preprints.org
SciProfiles
Encyclopedia

Article Menu

Subscribe SciFeed
Recommended Articles
Google Scholar
on Google Scholar
Table of Contents

Find support for a specific problem in the support section of our website.

Please let us know what you think of our products and services.

Visit our dedicated information section to learn more about MDPI.

JSmol Viewer

Driving analysis and multi scenario simulation of ecosystem carbon storage changes based on the invest-plus coupling model: a case study of jianli city in the jianghan plain of china.

1. Introduction

2. materials and methods, 2.1. study area, 2.2. data sources and descriptions, 2.3. research framework, 2.4. methods, 2.4.1. land use dynamics degree, 2.4.2. land use change transfer matrix, 2.4.3. patch-generating land use simulation model, 2.4.4. invest-carbon storage and sequestration, 3.1. temporal and spatial evolution of land use, 3.1.1. temporal evolution of land use, 3.1.2. spatial evolution of land use, 3.2. land use projections, 3.2.1. growth probabilities, 3.2.2. model accuracy verification, 3.2.3. multi-scenario simulation, 3.3. carbon storage dynamics from 2000 to 2020, 3.3.1. temporal evolution for carbon storage, 3.3.2. spatial evolution for carbon storage, 3.3.3. impacts of land use change for carbon storage, 3.4. carbon storage dynamics from 2020 to 2035, 3.4.1. temporal and spatial evolution for carbon storage, 3.4.2. impacts of land use change for carbon storage, 3.5. driving factors, 4. discussion, 4.1. suggestions for carbon storage optimization, 4.2. the novelty of this study.

In terms of research area selection, the majority of current scholarly investigations into regional carbon storage, both domestically and internationally, predominantly concentrate on economically advanced large urban agglomerations and economic zones [ 24 , 28 ]. These areas often feature significant human concentrations within river basins, as well as ecological protection zones characterized by unique natural features and notable surface structure changes. However, there is a conspicuous lack of focus on related research in small to medium-sized cities at the county level [ 36 ]. This paper aims to address this gap by examining the impact of land use changes in Jianli City on carbon storage, thereby broadening the scope of research on carbon storage at the county scale.
From a research content standpoint, the majority of studies on carbon storage predominantly focus on analyzing spatial variations in carbon storage across different scenarios, neglecting to investigate the socio-economic implications resulting from these changes [ 26 , 34 ]. This study not only quantitatively examines the evolutionary characteristics of land and carbon storage under various conditions but also computes the alterations in the economic value of carbon storage corresponding to these situations. Furthermore, it investigates the primary factors driving the evolution of carbon storage and its spatial patterns in Jianli City. The study also evaluates the contributions of different driving factors to the spatiotemporal evolution of carbon storage, offering theoretical insights for the development of relevant carbon storage management policies.

4.3. Uncertainty of Assessment Results

Inaccuracies in Land Use Data

5. Conclusions

Significant shifts in land use were observed in Jianli City from 2000 to 2020, primarily characterized by the reciprocal conversion between Cropland and Water, coupled with an expansion of Impervious areas. Over this timeframe, cumulative carbon storage of 691,790.27 Mg was diminished within the city. In terms of spatial distribution, the carbon storage exhibited a “high in the west and low in the east” regional pattern. The eastern Honghu Lake coast emerged as a region with minimal carbon storage, while other regions demonstrated higher concentrations. Predominantly, the areas experiencing significant reductions in carbon storage were attributed to the transformation of Cropland into Water in the eastern segment of the city.
The results of land use simulation show that under different development scenarios, the types of land use in Jianli City have undergone significant changes, which in turn affect the distribution and variation of carbon storage. Under the Natural Development scenario, there is a slight increase in Cropland and Imperviousness and a decrease in Forest, Grassland, and Water. The carbon storage and the economic value of carbon sinks increase under this scenario, mainly due to the conversion of water areas into cultivated land. Under the Urban Expansion scenario, the significant expansion of Imperviousness further exacerbates the changes in land cover, and its impact on carbon storage is more complex. The increase in Cropland slows down, and the continuous decrease in Water and Forest both pose challenges to the dynamic balance of carbon storage. In this scenario, special attention needs to be paid to carbon management strategies during urbanization to balance the relationship between economic development and ecological protection. Under the Ecology and Food Security scenario, the rapid increase in Cropland and the drastic decrease in Water and Imperviousness directly reflect the profound impact of policy orientation on land use and carbon storage. At the same time, the decreasing trend of Forest and Grassland is alleviated, and the overall carbon storage increases significantly. This scenario emphasizes the importance of carbon sequestration in cultivated land and also highlights the urgency of optimizing the use of construction land and improving the quality of urbanization while ensuring ecological and food security.

Author Contributions

Institutional review board statement, informed consent statement, data availability statement, acknowledgments, conflicts of interest.

Bozzola, M.; Lamonaca, E.; Santeramo, F.G. Impacts of climate change on global agri-food trade. Ecol. Indic. 2023 , 154 , 110680. [ Google Scholar ] [ CrossRef ]
Yazar, M.; York, A.; Larson, K.L. Adaptation, exposure, and politics: Local extreme heat and global climate change risk perceptions in the phoenix metropolitan region, USA. Cities 2022 , 127 , 103763. [ Google Scholar ] [ CrossRef ]
Varela, R.; de Castro, M.; Dias, J.M.; Gomez-Gesteira, M. Coastal warming under climate change: Global, faster and heterogeneous. Sci. Total Environ. 2023 , 886 , 164029. [ Google Scholar ] [ CrossRef ]
Zhu, P.; Zhang, Z.; Lin, B. Understanding spatial evolution of global climate change risk: Insights from convergence analysis. J. Clean. Prod. 2023 , 413 , 137423. [ Google Scholar ] [ CrossRef ]
Ning, K.; Chen, J.; Li, Z.; Liu, C.; Nie, X.; Liu, Y.; Wang, L.; Hu, X. Land use change induced by the implementation of ecological restoration Programs increases future terrestrial ecosystem carbon sequestration in red soil hilly region of China. Ecol. Indic. 2021 , 133 , 108409. [ Google Scholar ] [ CrossRef ]
Xu, L.; He, N.; Li, M.; Cai, W.; Yu, G. Spatiotemporal dynamics of carbon sinks in China’s terrestrial ecosystems from 2010 to 2060. Resour. Conserv. Recycl. 2024 , 203 , 107457. [ Google Scholar ] [ CrossRef ]
Yin, C.; Zhao, W.; Ye, J.; Muroki, M.; Pereira, P. Ecosystem carbon sequestration service supports the Sustainable Development Goals progress. J. Environ. Manag. 2023 , 330 , 117155. [ Google Scholar ] [ CrossRef ] [ PubMed ]
Feng, Y.; Chen, S.; Tong, X.; Lei, Z.; Gao, C.; Wang, J. Modeling changes in China’s 2000–2030 carbon stock caused by land use change. J. Clean. Prod. 2020 , 252 , 119659. [ Google Scholar ] [ CrossRef ]
Clarke, K.C.; Johnson, J.M. Calibrating SLEUTH with big data: Projecting California’s land use to 2100. Comput. Environ. Urban Syst. 2020 , 83 , 101525. [ Google Scholar ] [ CrossRef ]
Varquez, A.C.G.; Dong, S.; Hanaoka, S.; Kanda, M. Evaluating future railway-induced urban growth of twelve cities using multiple SLEUTH models with open-source geospatial inputs. Sustain. Cities Soc. 2023 , 91 , 104442. [ Google Scholar ] [ CrossRef ]
Luo, G.; Yin, C.; Chen, X.; Xu, W.; Lu, L. Combining system dynamic model and CLUE-S model to improve land use scenario analyses at regional scale: A case study of Sangong watershed in Xinjiang, China. Ecol. Complex. 2010 , 7 , 198–207. [ Google Scholar ] [ CrossRef ]
Liu, G.; Jin, Q.; Li, J.; Li, L.; He, C.; Huang, Y.; Yao, Y. Policy factors impact analysis based on remote sensing data and the CLUE-S model in the Lijiang River Basin, China. Catena 2017 , 158 , 286–297. [ Google Scholar ] [ CrossRef ]
Peng, K.; Jiang, W.; Deng, Y.; Liu, Y.; Wu, Z.; Chen, Z. Simulating wetland changes under different scenarios based on integrating the random forest and CLUE-S models: A case study of Wuhan Urban Agglomeration. Ecol. Indic. 2020 , 117 , 106671. [ Google Scholar ] [ CrossRef ]
Liang, X.; Liu, X.; Li, X.; Chen, Y.; Tian, H.; Yao, Y. Delineating multi-scenario urban growth boundaries with a CA-based FLUS model and morphological method. Landsc. Urban Plan. 2018 , 177 , 47–63. [ Google Scholar ] [ CrossRef ]
Lin, W.; Sun, Y.; Nijhuis, S.; Wang, Z. Scenario-based flood risk assessment for urbanizing deltas using future land-use simulation (FLUS): Guangzhou Metropolitan Area as a case study. Sci. Total Environ. 2020 , 739 , 139899. [ Google Scholar ] [ CrossRef ] [ PubMed ]
Li, X.; Fu, J.; Jiang, D.; Lin, G.; Cao, C. Land use optimization in Ningbo City with a coupled GA and PLUS model. J. Clean. Prod. 2022 , 375 , 134004. [ Google Scholar ] [ CrossRef ]
Gao, L.; Tao, F.; Liu, R.; Wang, Z.; Leng, H.; Zhou, T. Multi-scenario simulation and ecological risk analysis of land use based on the PLUS model: A case study of Nanjing. Sustain. Cities Soc. 2022 , 85 , 104055. [ Google Scholar ] [ CrossRef ]
Zhang, Z.; Hu, B.; Jiang, W.; Qiu, H. Spatial and temporal variation and prediction of ecological carrying capacity based on machine learning and PLUS model. Ecol. Indic. 2023 , 154 , 110611. [ Google Scholar ] [ CrossRef ]
Sharma, H.; Pant, K.S.; Bishist, R.; Lal Gautam, K.; Ludarmani; Dogra, R.; Kumar, M.; Kumar, A. Estimation of biomass and carbon storage potential in agroforestry systems of north western Himalayas, India. Catena 2023 , 225 , 107009. [ Google Scholar ] [ CrossRef ]
Chaudhary, S.; Aryal, B. Factors affecting the tree and soil carbon stock in Shorea robusta Gaertn. forests along the elevational gradient in Eastern Nepal. Acta Ecol. Sin. 2023 , 44 , 517–528. [ Google Scholar ] [ CrossRef ]
Chen, X.; Yu, L.; Hou, S.; Liu, T.; Li, X.; Li, Y.; Du, Z.; Li, C.; Wu, H.; Gao, G.; et al. Unraveling carbon stock dynamics and their determinants in China’s Loess Plateau over the past 40 years. Ecol. Indic. 2024 , 159 , 111760. [ Google Scholar ] [ CrossRef ]
Yoo, J.; Kim, J.; Kim, J.; Lim, J.; Kang, H. Soil carbon storage and its economic values of inland wetlands in Korea. Ecol. Eng. 2022 , 182 , 106731. [ Google Scholar ] [ CrossRef ]
Parisa, Z.; Marland, E.; Sohngen, B.; Marland, G.; Jenkins, J. The time value of carbon storage. For. Policy Econ. 2022 , 144 , 102840. [ Google Scholar ] [ CrossRef ]
Wang, Y.; Liang, D.; Wang, J.; Zhang, Y.; Chen, F.; Ma, X. An analysis of regional carbon stock response under land use structure change and multi-scenario prediction, a case study of Hefei, China. Ecol. Indic. 2023 , 151 , 110293. [ Google Scholar ] [ CrossRef ]
Wu, W.; Xu, L.; Zheng, H.; Zhang, X. How much carbon storage will the ecological space leave in a rapid urbanization area? Scenario analysis from Beijing-Tianjin-Hebei Urban Agglomeration. Resour. Conserv. Recycl. 2023 , 189 , 106774. [ Google Scholar ] [ CrossRef ]
Wu, F.; Wang, Z. Assessing the impact of urban land expansion on ecosystem carbon storage: A case study of the Changzhutan metropolitan area, China. Ecol. Indic. 2023 , 154 , 110688. [ Google Scholar ] [ CrossRef ]
Bozkurt, S.G.; Kusak, L.; Akkemik, U. Investigation of land cover (LC)/land use (LU) change affecting forest and seminatural ecosystems in Istanbul (Turkey) metropolitan area between 1990 and 2018. Environ. Monit. Assess 2022 , 195 , 196. [ Google Scholar ] [ CrossRef ] [ PubMed ]
Yang, B.; Chen, X.; Wang, Z.; Li, W.; Zhang, C.; Yao, X. Analyzing land use structure efficiency with carbon emissions: A case study in the Middle Reaches of the Yangtze River, China. J. Clean. Prod. 2020 , 274 , 123076. [ Google Scholar ] [ CrossRef ]
Li, Y.; Geng, H. Spatiotemporal trends in ecosystem carbon stock evolution and quantitative attribution in a karst watershed in southwest China. Ecol. Indic. 2023 , 153 , 110429. [ Google Scholar ] [ CrossRef ]
Long, X.; Lin, H.; An, X.; Chen, S.; Qi, S.; Zhang, M. Evaluation and analysis of ecosystem service value based on land use/cover change in Dongting Lake wetland. Ecol. Indic. 2022 , 136 , 108619. [ Google Scholar ] [ CrossRef ]
Gao, M.; Xu, R.; Huang, J.; Su, B.; Jiang, S.; Shi, P.; Yang, H.; Xing, Y.; Wang, D.; Jiang, H.; et al. Increase of carbon storage in the Qinghai-Tibet Plateau: Perspective from land-use change under global warming. J. Clean. Prod. 2023 , 414 , 137540. [ Google Scholar ] [ CrossRef ]
Peng, Y.; Cheng, W.; Xu, X.; Song, H. Analysis and prediction of the spatiotemporal characteristics of land-use ecological risk and carbon storage in Wuhan metropolitan area. Ecol. Indic. 2024 , 158 , 111432. [ Google Scholar ] [ CrossRef ]
Fan, L.; Cai, T.; Wen, Q.; Han, J.; Wang, S.; Wang, J.; Yin, C. Scenario simulation of land use change and carbon storage response in Henan Province, China: 1990–2050. Ecol. Indic. 2023 , 154 , 110660. [ Google Scholar ] [ CrossRef ]
He, Y.; Ma, J.; Zhang, C.; Yang, H. Spatio-Temporal Evolution and Prediction of Carbon Storage in Guilin Based on FLUS and InVEST Models. Remote Sens. 2023 , 15 , 1445. [ Google Scholar ] [ CrossRef ]
Tang, L.; Ke, X.; Zhou, T.; Zheng, W.; Wang, L. Impacts of cropland expansion on carbon storage: A case study in Hubei, China. J. Environ. Manag. 2020 , 265 , 110515. [ Google Scholar ] [ CrossRef ] [ PubMed ]
Zhou, H.; Tang, M.; Huang, J.; Mei, X.; Zhao, H. Driving mechanisms and multi-scenario simulation of land use change based on National Land Survey Data: A case in Jianghan Plain, China. Front. Environ. Sci. 2024 , 12 , 1422987. [ Google Scholar ] [ CrossRef ]
Ke, X.; van Vliet, J.; Zhou, T.; Verburg, P.H.; Zheng, W.; Liu, X. Direct and indirect loss of natural habitat due to built-up area expansion: A model-based analysis for the city of Wuhan, China. Land Use Policy 2018 , 74 , 231–239. [ Google Scholar ] [ CrossRef ]
Tang, L.; Ke, X.; Zhou, Q.; Wang, L.; Koomen, E. Projecting future impacts of cropland reclamation policies on carbon storage. Ecol. Indic. 2020 , 119 , 106835. [ Google Scholar ] [ CrossRef ]
Song, S.; Kong, M.; Su, M.; Ma, Y. Study on carbon sink of cropland and influencing factors: A multiscale analysis based on geographical weighted regression model. J. Clean. Prod. 2024 , 447 , 141455. [ Google Scholar ] [ CrossRef ]
Dai, W.; Huang, Y. Relation of soil organic matter concentration to climate and altitude in zonal soils of China. Catena 2006 , 65 , 87–94. [ Google Scholar ] [ CrossRef ]
Li, X.; Li, F.; Wang, D.; Hou, J.; Wang, Z.; Cao, R.; Yang, W. Zonal patterns and driving factors of soil organic carbon density in Zhejiang Province, China. Geoderma Reg. 2023 , 34 , e00679. [ Google Scholar ] [ CrossRef ]
Xu, C.; Zhang, Q.; Yu, Q.; Wang, J.; Wang, F.; Qiu, S.; Ai, M.; Zhao, J. Effects of land use/cover change on carbon storage between 2000 and 2040 in the Yellow River Basin, China. Ecol. Indic. 2023 , 151 , 110345. [ Google Scholar ] [ CrossRef ]
Li, X.; Zhao, H.; Gu, B.; Chen, Y. Carbon sinks/sources’ spatiotemporal heterogeneity and their spatial response to economic-social factors in relatively developed regions: A case of China’s coastal area. J. Environ. Manag. 2024 , 354 , 120494. [ Google Scholar ] [ CrossRef ] [ PubMed ]
Ricke, K.; Drouet, L.; Caldeira, K.; Tavoni, M. Country-level social cost of carbon. Nat. Clim. Chang. 2018 , 8 , 895–900. [ Google Scholar ] [ CrossRef ]
Zuo, W.; Gu, B.; Zou, X.; Peng, K.; Shan, Y.; Yi, S.; Shan, Y.; Gu, C.; Bai, Y. Soil organic carbon sequestration in croplands can make remarkable contributions to China’s carbon neutrality. J. Clean. Prod. 2023 , 382 , 135268. [ Google Scholar ] [ CrossRef ]
Zarandian, A.; Badamfirouz, J.; Musazadeh, R.; Rahmati, A.; Azimi, S.B. Scenario modeling for spatial-temporal change detection of carbon storage and sequestration in a forested landscape in Northern Iran. Environ. Monit Assess 2018 , 190 , 474. [ Google Scholar ] [ CrossRef ] [ PubMed ]
Zhang, D.; Zhao, Y.; Wu, J. Assessment of carbon balance attribution and carbon storage potential in China’s terrestrial ecosystem. Resour. Conserv. Recycl. 2023 , 189 , 106748. [ Google Scholar ] [ CrossRef ]
Zhu, L.; Song, R.; Sun, S.; Li, Y.; Hu, K. Land use/land cover change and its impact on ecosystem carbon storage in coastal areas of China from 1980 to 2050. Ecol. Indic. 2022 , 142 , 109178. [ Google Scholar ] [ CrossRef ]
Gong, W.; Duan, X.; Sun, Y.; Zhang, Y.; Ji, P.; Tong, X.; Qiu, Z.; Liu, T. Multi-scenario simulation of land use/cover change and carbon storage assessment in Hainan coastal zone from perspective of free trade port construction. J. Clean. Prod. 2023 , 385 , 135630. [ Google Scholar ] [ CrossRef ]
Li, L.; Huang, X.; Yang, H. A new framework for identifying ecological conservation and restoration areas to enhance carbon storage. Ecol. Indic. 2023 , 154 , 110523. [ Google Scholar ] [ CrossRef ]
Hansen, M.H.; Li, H.; Svarverud, R. Ecological civilization: Interpreting the Chinese past, projecting the global future. Glob. Environ. Chang. 2018 , 53 , 195–203. [ Google Scholar ] [ CrossRef ]
Meng, F.; Guo, J.; Guo, Z.; Lee, J.C.K.; Liu, G.; Wang, N. Urban ecological transition: The practice of ecological civilization construction in China. Sci Total Env. 2021 , 755 , 142633. [ Google Scholar ] [ CrossRef ] [ PubMed ]
Zhang, L.; Wang, H.; Zhang, W.; Wang, C.; Bao, M.; Liang, T.; Liu, K.-d. Study on the development patterns of ecological civilization construction in China: An empirical analysis of 324 prefectural cities. J. Clean. Prod. 2022 , 367 , 132975. [ Google Scholar ] [ CrossRef ]
Du, W.; Yan, H.; Feng, Z.; Yang, Y.; Liu, F. The supply-consumption relationship of ecological resources under ecological civilization construction in China. Resour. Conserv. Recycl. 2021 , 172 , 105679. [ Google Scholar ] [ CrossRef ]

Click here to enlarge figure

Data Type	Data Name	Time Frame	Spatial Resolution	Data Unit	Data Sources	Treatment
Land use	Land use	2000–2020	30 m	——	, accessed on 21 October 2023	Extraction by mask Project Raster
Natural environment	Elevation	2020	30 m	m	, accessed on 21 October 2023.	Resample
	Slope	2020	30 m	°		Resample Slope
	Slope direction	2020	30 m			Resample Slope direction
	Precipitation	2020	1000 m	mm		Resample
	Temperature	2020	1000 m	°C
	Vegetation coverage	2020	30 m	——
	Soil type	2020	30 m	——
Socio-economic	Population density	2020	1000 m	Person/km	, accessed on 21 October 2023.	Resample
	Per capita GDP	2020	1000 m	million/km
	Night lighting	2020	0.004°	nW/cm /sr
Space-accessible	Distance from motorway	2020	30 m	m	, accessed on 21 October 2023.	Resample Euclidean distance
	Distance from provincial highway	2020	30 m
	Distance from national highway	2020	30 m
	Distance from county road	2020	30 m
	Distance from township	2020	30 m
	Distance from urban primary roads	2020	30 m
	Distance from urban secondary roads	2020	30 m
	Distance from urban tertiary roads	2020	30 m
	Distance from primary schools	2020	30 m
	Distance from secondary school	2020	30 m
	Distance from medical institution	2020	30 m
	Distance from commerce	2020	30 m
	Distance from water	2020	30 m

Class	Cabove (t/ha)	Cbelow (t/ha)	Csoil (t/ha)	Cdead (t/ha)
Cropland	16.49	10.89	75.82	2.11
Forest	30.14	6.03	100.15	2.78
Grassland	14.29	17.15	87.05	2.42
Water	0	0	0	0
Impervious	7.61	1.52	34.33	0

Class	2000		2005		2010		2015		2020
Class	Area/hm	Weight/%	Area/hm	Weight/%	Area/hm	Weight/%	Area/hm	Weight/%	Area/hm	Weight/%
Cropland	326,958.39	88.70%	321,743.34	87.28%	316,109.25	85.75%	315,899.55	85.70%	319,240.17	86.60%
Forest	447.03	0.12%	281.52	0.08%	299.79	0.08%	279.18	0.08%	261.72	0.07%
Grassland	0.09	0.00%	0.00	0.00%	3.69	0.00%	1.35	0.00%	6.48	0.00%
Water	34,865.73	9.46%	39,118.05	10.61%	43,233.12	11.73%	42,676.47	11.58%	37,327.5	10.13%
Impervious	6358.86	1.72%	7487.19	2.03%	8984.25	2.44%	9773.55	2.65%	11,794.23	3.20%
Total	368,630.1	100.00%	368,630.1	100.00%	368,630.1	100.00%	368,630.1	100.00%	368,630.1	100.00%

Class	Land Use Single-Dynamic Degrees
Class	2000–2005	2005–2010	2010–2015	2015–2020	2000–2020
Cropland	−0.32%	−0.35%	−0.01%	0.21%	−0.12%
Forest	−7.40%	1.30%	−1.37%	−1.25%	−2.07%
Grassland	−0.19%	7.88%	−3.59%	9.58%	3.38%
Water	2.44%	2.10%	−0.26%	−2.51%	0.35%
Impervious	3.55%	4.00%	1.76%	4.13%	4.27%

Class		The 2005 Transition Matrix/hm						Transfer-Out Area/hm	Transfer Out Contribution Rate/%
Class		Class 1	Class 2	Class 3	Class 4	Class 5	Total	Transfer-Out Area/hm	Transfer Out Contribution Rate/%
The 2000 transition matrix/hm	Class 1	317,363.94	3.78	0.00	8871.30	719.37	326,958.39	9594.45	66.19
	Class 2	170.28	276.30	0.00	0.45	0.00	447.03	170.73	1.18
	Class 3	0.00	0.00	9.36	0.00	0.09	9.45	0.09	0.00
	Class 4	4206.15	1.44	0.00	30,182.58	466.20	34,856.37	4673.79	32.24
	Class 5	2.97	0.00	0.00	54.36	6301.53	6358.86	57.33	0.40
	Total	321,743.34	281.52	9.36	39,108.69	7487.19	368,630.10	——	——
Transfer-in area/hm		4379.40	5.22	0.00	8926.11	1185.66	——	14,496.39	——
Transfer in contribution rate/%		30.21	0.04	0.00	61.57	8.18	——	——	1

Class		The 2010 Transition Matrix/hm						Transfer-Out Area/hm	Transfer Out Contribution Rate/%
Class		Class 1	Class 2	Class 3	Class 4	Class 5	Total	Transfer-Out Area/hm	Transfer Out Contribution Rate/%
The 2005 transition matrix/hm	Class 1	311,707.08	20.7	3.69	9102.78	909.09	321,743.34	10,036.26	66.03
	Class 2	19.98	260.64	0.00	0.9	0.00	281.52	20.88	0.14
	Class 3	0.00	0.00	9.36	0.00	0.00	9.36	0.00	0.00
	Class 4	4380.57	18.45	0.00	34,044.48	665.19	39,108.69	5064.21	33.32
	Class 5	1.62	0.00	0.00	75.6	7409.97	7487.19	77.22	0.51
	Total	316,109.25	299.79	13.05	43,223.76	8984.25	368,630.10	——	——
Transfer-in area/hm		4402.17	39.15	3.69	9179.28	1574.28	——	15,198.57	——
Transfer in contribution rate/%		28.96	0.26	0.02	60.40	10.36	——	——	1

Class		The 2015 Transition Matrix/hm /hm						Transfer-Out Area/hm	Transfer Out Contribution Rate/%
Class		Class 1	Class 2	Class 3	Class 4	Class 5	Total	Transfer-Out Area/hm	Transfer Out Contribution Rate/%
The 2010 transition matrix/hm	Class 1	310,034.25	2.97	1.17	4864.5	1206.36	316,109.25	6075	48.40
	Class 2	22.86	275.85	0.00	1.08	0.00	299.79	23.94	0.19
	Class 3	0.18	0.00	9.54	0.00	3.33	13.05	3.51	0.03
	Class 4	5842.26	0.36	0.00	37,288.17	92.97	43,223.76	5935.59	47.29
	Class 5	0.00	0.00	0.00	513.36	8470.89	8984.25	513.36	4.09
	Total	315,899.55	279.18	10.71	42,667.11	9773.55	36,8630.1	——	——
Transfer-in area/hm		5865.30	3.33	1.17	5378.94	1302.66	——	12,551.4	——
Transfer in contribution rate/%		46.73	0.03	0.01	42.86	10.38	——	——	1

Class		The 2020 Transition Matrix/hm						Transfer-Out Area/hm	Transfer Out Contribution Rate/%
Class		Class 1	Class 2	Class 3	Class 4	Class 5	Total	Transfer-Out Area/hm	Transfer Out Contribution Rate/%
The 2015 transition matrix/hm	Class 1	311,135.4	14.76	0.9	3078	1670.49	315,899.55	4764.15	35.59
	Class 2	28.53	246.96	0.00	3.69	0.00	279.18	32.22	0.24
	Class 3	0.00	0.00	9.45	0.00	1.26	10.71	1.26	0.01
	Class 4	8069.22	0.00	5.22	34,161.12	431.55	42,667.11	8505.99	63.54
	Class 5	7.02	0.00	0.27	75.33	9690.93	9773.55	82.62	0.62
	Total	319,240.17	261.72	15.84	37,318.14	11,794.23	368,630.1	——	——
Transfer-in area/hm		8104.77	14.76	6.39	3157.02	2103.3	——	13,386.24	——
Transfer in contribution rate/%		60.55	0.11	0.05	23.58	15.71	——	——	1

Typology	Years	Cropland	Forest	Grassland	Water	Impervious
Demand for simulation	2000–2005	3,963,961	993	119	616,178	141,103
	2005–2010	3,929,521	4328	255	633,523	154,727
	2010–2015	4,043,778	3332	120	540,421	134,702
	2000–2010	3,934,295	2784	209	634,323	150,742
Actual	2020	4,090,438	3356	206	477,392	150,961
Error rata	2000–2005	−0.030920161	−0.704112038	−0.422330097	0.290717063	−0.065301634
	2005–2010	−0.039339797	0.289630513	0.237864078	0.327049888	0.024946841
	2010–2015	−0.011407091	−0.007151371	−0.417475728	0.132027768	−0.107703314
	2000–2010	−0.038172685	−0.170441001	0.014563107	0.328725659	−0.001450706

Class	Timespan
	Five Years			Ten Years
	2000–2005	2005–2010	2010–2015	2000–2010
Cropland	0.839403611	0.832110638	0.856305744	0.833121751
Forest	0.000210276	0.000916492	0.00070558	0.000589537
Grassland	2.51993 × 10	5.40 × 10	2.54 × 10	4.43 × 10
Water	0.130481112	0.134154068	0.114438925	0.134323504
Impervious	0.029879801	0.032764803	0.028524339	0.031920951

Modulus	Years
Modulus	2000–2005	2005–2010	2010–2015	2000–2010
Kappa	0.64886	0.694551	0.84709	0.620722
FOM	0.240715	0.224034	0.423506	0.204741

Class	Natural Development					Urban Expansion					Ecology and Food Security
Class	a	b	c	d	e	a	b	c	d	e	a	b	c	d	e
a	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1
b	1	1	0	1	0	1	1	0	1	0	1	1	0	0	0
c	0	0	1	0	1	0	0	1	0	1	0	0	1	0	1
d	1	0	1	1	1	1	0	1	1	1	1	0	1	1	1
e	1	0	1	1	1	1	0	1	1	1	1	0	1	1	1

Class	2020 True		Natural Development			Urban Expansion			Ecology and Food Security
Class	Area/hm	Weight/%	Area/hm	Weight/%	Dynamic/%	Area/hm	Weight/%	Dynamic/%	Area/hm	Weight/%	Dynamic/%
Cropland	319,240.17	86.60%	323,833.18	87.85%	0.10%	323,273.88	87.70%	0.08%	325,590.80	88.32%	0.13%
Forest	261.72	0.07%	222.00	0.06%	−1.01%	221.61	0.06%	−1.02%	236.29	0.06%	−0.65%
Grassland	15.84	0.00%	15.77	0.00%	−0.03%	15.85	0.00%	0.00%	15.85	0.00%	0.00%
Water	37,318.14	10.12%	32,665.98	8.86%	−0.83%	32,934.43	8.93%	−0.78%	31,549.71	8.56%	−1.03%
Impervious	11,794.23	3.20%	11,893.17	3.23%	0.06%	12,184.34	3.31%	0.22%	11,237.46	3.05%	−0.31%

Town	Carbon Stock/Tg					Land Average Carbon Density/(t/hm )
Town	2000	2005	2010	2015	2020	2000	2005	2010	2015	2020
Bianhe Town	2.01	1.93	1.70	1.93	2.13	81.36	78.22	68.74	78.07	86.07
Shangchewan Town	0.92	0.94	0.93	0.94	0.95	98.82	100.21	99.89	100.37	101.55
Sanzhou Town	1.95	1.96	1.97	1.96	1.97	84.48	84.95	85.19	85.08	85.31
Zhoulaozui Town	2.06	2.06	2.06	2.06	2.05	103.43	103.58	103.41	103.33	102.94
Chengji Town	1.66	1.65	1.63	1.64	1.65	103.55	103.17	102.23	102.46	103.08
Chiba Town	1.89	1.90	1.90	1.89	1.91	93.11	93.41	93.38	93.09	93.96
Hongcheng Town	2.64	2.65	2.65	2.64	2.62	99.75	100.21	100.15	99.87	99.01
Wangqiao Town	2.17	2.17	2.16	2.17	2.18	102.32	102.19	101.74	102.19	102.57
Qiaoshi Town	1.83	1.66	1.58	1.38	1.49	95.15	86.54	82.60	72.18	77.86
Bailuo Town	1.60	1.60	1.61	1.59	1.65	78.17	78.17	78.37	77.40	80.35
Zhuhe Town	1.65	1.65	1.64	1.64	1.65	100.22	100.15	99.54	99.27	100.25
Rongcheng Town	1.16	1.18	1.17	1.15	0.99	81.20	82.40	81.78	80.29	69.65
Huanghu Farm Management Area	0.81	0.81	0.80	0.81	0.81	102.91	102.93	101.88	102.14	102.60
Xingou Town	2.18	2.17	2.17	2.16	2.15	103.51	103.28	102.93	102.58	102.05
Zhemu Town	2.20	2.15	2.11	2.08	2.11	90.86	88.75	87.07	85.89	87.34
People’s Dwan Farms Management Area	2.03	2.05	2.10	2.07	2.06	93.95	94.86	96.87	95.46	94.98
Huangxiekou Town	2.06	2.06	2.06	2.06	2.07	102.67	102.83	102.67	102.81	103.11
Futiansi Town	1.25	1.27	1.22	1.27	1.32	94.85	96.15	92.87	96.83	100.09
Qipan Town	1.27	0.91	0.67	0.68	0.86	66.09	47.34	34.84	35.39	45.06
Wangshi Town	1.28	1.28	1.28	1.28	1.27	103.30	103.72	103.80	103.61	102.98
Gongchang Town	1.50	1.49	1.51	1.51	1.51	102.78	102.26	103.49	103.42	103.36
Maoshi Town	1.87	1.84	1.86	1.88	1.89	99.39	98.16	99.12	100.08	100.71
Fenyan Town	2.10	2.08	2.09	2.10	2.10	103.62	102.93	103.42	103.91	103.87

The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

Shao, J.; Wang, Y.; Tang, M.; Hu, X. Driving Analysis and Multi Scenario Simulation of Ecosystem Carbon Storage Changes Based on the InVEST-PLUS Coupling Model: A Case Study of Jianli City in the Jianghan Plain of China. Sustainability 2024 , 16 , 6736. https://doi.org/10.3390/su16166736

Shao J, Wang Y, Tang M, Hu X. Driving Analysis and Multi Scenario Simulation of Ecosystem Carbon Storage Changes Based on the InVEST-PLUS Coupling Model: A Case Study of Jianli City in the Jianghan Plain of China. Sustainability . 2024; 16(16):6736. https://doi.org/10.3390/su16166736

Shao, Jun, Yuxian Wang, Mingdong Tang, and Xinran Hu. 2024. "Driving Analysis and Multi Scenario Simulation of Ecosystem Carbon Storage Changes Based on the InVEST-PLUS Coupling Model: A Case Study of Jianli City in the Jianghan Plain of China" Sustainability 16, no. 16: 6736. https://doi.org/10.3390/su16166736

Article Metrics

Article access statistics, further information, mdpi initiatives, follow mdpi.

Subscribe to receive issue release notifications and newsletters from MDPI journals

Share full article

For more audio journalism and storytelling, download New York Times Audio , a new iOS app available for news subscribers.

Apple Podcasts
Google Podcasts

Harris Chooses Walz

A guide to the career, politics and sudden stardom of gov. tim walz of minnesota, now vice president kamala harris’s running mate..

Hosted by Michael Barbaro

Featuring Ernesto Londoño

Produced by Alex Stern Eric Krupke and Olivia Natt

Edited by Lisa Chow and Patricia Willens

Original music by Marion Lozano and Pat McCusker

Engineered by Alyssa Moxley

Listen and follow The Daily Apple Podcasts | Spotify | Amazon Music | YouTube

Earlier this summer, few Democrats could have identified Gov. Tim Walz of Minnesota.

But, in a matter of weeks, Mr. Walz has garnered an enthusiastic following in his party, particularly among the liberals who cheer on his progressive policies. On Tuesday, Vice President Kamala Harris named him as her running mate. Ernesto Londoño, who reports for The Times from Minnesota, walks us through Mr. Walz’s career, politics and sudden stardom.

On today’s episode

Ernesto Londoño , a reporter for The Times based in Minnesota, covering news in the Midwest.

Kamala Harris and Tim Walz waving onstage in front of a “Harris Walz” sign.

Background reading

Who is Tim Walz , Kamala Harris’s running mate?

Mr. Walz has faced criticism for his response to the George Floyd protests.

There are a lot of ways to listen to The Daily. Here’s how.

We aim to make transcripts available the next workday after an episode’s publication. You can find them at the top of the page.

The Daily is made by Rachel Quester, Lynsea Garrison, Clare Toeniskoetter, Paige Cowett, Michael Simon Johnson, Brad Fisher, Chris Wood, Jessica Cheung, Stella Tan, Alexandra Leigh Young, Lisa Chow, Eric Krupke, Marc Georges, Luke Vander Ploeg, M.J. Davis Lin, Dan Powell, Sydney Harper, Michael Benoist, Liz O. Baylen, Asthaa Chaturvedi, Rachelle Bonja, Diana Nguyen, Marion Lozano, Corey Schreppel, Rob Szypko, Elisheba Ittoop, Mooj Zadie, Patricia Willens, Rowan Niemisto, Jody Becker, Rikki Novetsky, Nina Feldman, Will Reid, Carlos Prieto, Ben Calhoun, Susan Lee, Lexie Diao, Mary Wilson, Alex Stern, Sophia Lanman, Shannon Lin, Diane Wong, Devon Taylor, Alyssa Moxley, Olivia Natt, Daniel Ramirez and Brendan Klinkenberg.

Our theme music is by Jim Brunberg and Ben Landsverk of Wonderly. Special thanks to Sam Dolnick, Paula Szuchman, Lisa Tobin, Larissa Anderson, Julia Simon, Sofia Milan, Mahima Chablani, Elizabeth Davis-Moorer, Jeffrey Miranda, Maddy Masiello, Isabella Anderson, Nina Lassam and Nick Pitman.

An earlier version of this episode misstated the subject that Walz’s wife taught. She taught English, not Social Studies.

How we handle corrections

Ernesto Londoño is a Times reporter based in Minnesota, covering news in the Midwest and drug use and counternarcotics policy. More about Ernesto Londoño

COMMENTS

Use Case Diagram for Bank ATM System
Automated Teller Machine (ATM) also known as ABM (Automated Banking Machine) is a banking system. This banking system allows customers or users to have access to financial transactions. These transactions can be done in public space without any need for a clerk, cashier, or bank teller. Working and description of the ATM can be explained with the help of the Use Case Diagram.
Use Case Modeling for an ATM System: A Comprehensive Guide and Case Study
This case study focuses on the use case modeling of an ATM system for a bank. The ATM system is designed to provide customers with a convenient way to access their accounts and perform various banking transactions, such as withdrawing cash, depositing cash, transferring funds, checking their account balance, and changing their PIN.
ATM Management System using C++
ATM Management System using C++. ATMs are Automated Teller Machines that are used to carry day-to-day financial transactions. ATMs can be used to withdraw money or to deposit money or even to know the information of an account like the balance amount, etc. They are convenient and easy to use,and it allows consumers to perform quick self-service ...
PDF Use Case Narrative for "Deposit" in ATM
This document describes the use case narratives for a simple ATM system. There are two types of users in this system - customers and managers. Any user (manager or customer) requires to login into the system before using it. The system will include four transactions that can be invoked by customers - deposit, withdraw, check balance and ...
Design an ATM
System Requirements The main components of the ATM that will affect interactions between the ATM and its users are: Card reader: to read the users' ATM cards. Keypad: to enter information into the ATM e.g. PIN. cards. Screen: to display messages to the users. Cash dispenser: for dispensing cash. Deposit slot: For users to deposit cash or checks. Printer: for printing receipts. Communication ...
Use Case Diagram for ATM Machine
Learn what is a UML Use Case Diagram for ATM Machine System with a complete guide on how to create a use case diagram using include & extend.
PDF Sample of UML Diagrams for ATM System
Use Case Diagram: Use case diagrams describe the functionality of a system and users of the system. They contain the following elements: Actors , which represent users of a system, including human users and other systems Use cases , which represent functionality or services provided by a system to users Here, is a use case diagram for the ATM ...
GitHub
Examining the ATM Requirements Document: We begin our design process by presenting a requirements document that specifies the ATM system's overall purpose and what it must do. Throughout the case study, we refer to the requirements document to determine what functionality the system must include.
PDF ATM Case Study, Part 1: Object-Oriented Design with the UML
33.1 Case Study Introduction Now we begin the optional portion of our object-oriented design and implementation case study. In this chapter and Chapter 34, you'll design and implement an object-oriented au-tomated teller machine (ATM) software system.
PDF ATM Case Study, Part 2: Implementing an OO Design in C#
ATM Case Study, Part 2: Implementing an OO Design in C# 26.1 Introduction 26.2 Starting to Program the Classes of the ATM System 26.3 Incorporating Inheritance and Polymorphism into the ATM System
An example of UML use case diagram for a bank ATM (Automated Teller
UML Use Case Diagram Examples An automated teller machine ( ATM) or the automatic banking machine ( ABM ) is a banking subsystem ( subject ) that provides bank customers with access to financial transactions in a public space without the need for a cashier, clerk, or bank teller.
Use Cases for Example ATM System
A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the ...
PDF ATM Case Study, Part 1: Object-Oriented Design with the UML
In Chapters 12-13, you design and implement an object-oriented automated teller machine (ATM) software system. Concise, carefully paced, complete design and implementation experience. Perform the steps of an object-oriented design (OOD) process using the UML. Sections 12.2--12.7 and 13.2-13.3. Relate these steps to the object-oriented ...
PDF ATM Traffic Management Case Studies and Configuration Examples
ATM Traffic Management Case Studies and Configuration Examples This chapter provides case studies and configuration examples for enterprise networks using Cisco 7200 series routers in an ATM environment. All of the examples in this chapter represent actual lab-tested configurations from Cisco Systems proof-of-concept and solutions labs.
ATM System
ATM System. Automated Teller Machine (ATM) is a self-service banking machine that enables users to perform various banking transactions, including withdrawing money, checking their account balance, depositing money, and recording transactions. The Withdraw Money use case allows users to withdraw cash from their account using the ATM.
PDF Object-OrientedDesignwith 25 theUML
25.3Examining the ATM Requirements Document [Note:This section canbestudied afterChapter3.] We begin ourdesign process by presenting a requirements document that specifiesthe ATMsystem'soverall purposeandwhatit must do. Throughoutthe case study, we refer to therequirements document to determinewhatfunctionality thesystemmustinclude.
ATM Use Case Diagram Example
A key concept of use case modeling is that it helps us design a system from the end user's perspective. It is an effective technique to communicate system behavior in user terms by specifying all externally visible system behaviors. ATMs enable customers or users to perform financial transactions. These transactions can be performed in a public ...
ATM Case Study, Part 1: Object-Oriented Design with The
We create a usecasediagram to modelthe interactionsbetween asystem'sclients (in this case study, bank customers)and the system.The goalistoshow thekinds of interactionsusers have with asystemwithout providingthe details—theseare providedinother UMLdiagrams (which we presentthroughoutthe case study).Use case diagrams areoftenaccompanied by ...
UML diagrams for ATM application
Contains UML diagrams for ATM like class diagram, use case diagram, component diagram, deployment diagram, sequence and collaboration diagrams and more.
Case study ATM
25 Introduction Now we begin the optional portion of our object-oriented design and implementation case study. In this chapter and Chapter 26, you'll design and implement an object-oriented au- tomated teller machine (ATM) software system. The case study provides you with a con- cise, carefully paced, complete design and implementation ...
State Transition Diagram for an ATM System
State Transition Diagram for an ATM System. State Transition Diagram are also known as Dynamic models. As the name suggests, it is a type of diagram that is used to represent different transition (changing) states of a System. It is generally used to graphically represent all possible transition states a system can have and model such systems.
Water
Bezbradica L, Josimović B, Radić B, Polovina S, Crnčević T. Building Reservoirs as Protection against Flash Floods and Flood Basins Management—the Case Study of the Stubo-Rovni Regional Water-Management System.
Sustainability
Consequently, there is an urgent need to bolster research into carbon storage management. The study focuses on Jianli City, employing the InVEST model and land use data to examine the response patterns of land use changes and terrestrial system carbon storage from 2000 to 2020.
Harris Chooses Walz
A guide to the career, politics and sudden stardom of Gov. Tim Walz of Minnesota, now Vice President Kamala Harris's running mate.