Automated Teller Machine Example

 

 

Requirements Specification

 

Design the software to support a computerized banking network including both human cashiers and automatic teller machines (ATMs) to be shared by a consortium of banks.  Each bank provides its own computer to maintain its own accounts and process transactions against them.  Cashier stations are owned by individual banks and communicate directly with their own bank’s computers.  Human cashiers enter account and transaction data.  Automatic teller machines communicate with a central computer which clears transactions with the appropriate banks.  An automatic teller machine accepts a cash card, interacts with the user, communicates with the central system to carry out the transaction, dispenses cash, and prints receipts.  The system requires appropriate record-keeping and security provisions.  The system must handle concurrent accesses to the same account correctly.  The banks will provide their own software for their own computers; you are to design the software for the ATMs and the network.  The cost of the shared system will be apportioned to the banks according to the number of customers with cash cards.

 

We now read through the requirements document and underline the nouns (or noun phrases) and circle (italicize) the verb phrases.

 

Design the software to support a computerized banking network including both human cashiers and automatic teller machines (ATMs) to be shared by a consortium of banks.  Each bank provides its own computer to maintain its own accounts and process transactions against them.  Cashier stations are owned by individual banks and communicate directly with their own bank’s computers.  Human cashiers enter account and transaction data.  Automatic teller machines communicate with a central computer which clears transactions with the appropriate banks.  An automatic teller machine accepts a cash card, interacts with the user, communicates with the central system to carry out the transaction, dispenses cash, and prints receipts.  The system requires appropriate record-keeping and security provisions.  The system must handle concurrent accesses to the same account correctly.  The banks will provide their own software for their own computers; you are to design the software for the ATMs and the network.  The cost of the shared system will be apportioned to the banks according to the number of customers with cash cards.

 

List of underlined nouns:

 

software           banking network           cashier              ATM                consortium

 

bank                 bank computer             account            transaction        cashier station

 

account data     transaction data            central              cash card          user

                                                            computer

 

cash                 receipt                          system              record-keeping

                                                                                    provision

 

Security            access                          cost                  customer

provision

 

From this list of nouns we need to identify the classes.  We eliminate candidates that are:

1.      Redundant --    user    (customer)

 

2.      Irrelevant --      cost

 

3.      Implementation constructs --     words like algorithm, process, data structure, interrupt, linked list, and CPU cycle are not part of the problem domain, but may be relevant in the design and implementation of the system.  In this list we may exclude --    access,             software

 

4.      Roles – the name of a class should reflect its intrinsic nature and not a role it plays in an association.  In a company a person may be asked to play the role of a boss or a subordinant.  A system could be modeled that included these two separate classes, but a system in which a person object was capable of playing either role would be far more robust and flexible.  In this list there are no terms that should be considered as roles in an association.

 

5.      Attributes – names that describe properties of individual objects and names that do not have additional attributes and behaviors associated with them. --           account data,                transaction data

      (Both of these are not simple strings or numbers but have several fields and could be considered objects)

 

6.      Operations – the name of something that is applied to an object, but not manipulated in its own right.  None in this list.

 

7.      Vague classes – classes must be specific with well-defined properties and boundaries.  Names describing general concepts are not good candidates for being classes.  Vague nouns may indicate areas in the requirements document that need further refinement, or point to subsystems that will need to be fleshed out in subsequent refinements of the model.  In this example the vague nouns are:                     system,      security provision,   record-keeping provision,               banking network

 

Identified classes in the ATM system

 

Account           ATM                Bank                Bank-computer            CashCard

 

Cashier Consortium       Customer         CashierStation              CentralComputer   

 

Transaction       Cash                Receipt

 

Now go back to the requirements document and extract the verb phrases that relate to these nouns.

 

Subject                        Verb phrase                Object                    Indirect object phrase

Consortium                   shares                          ATMs

Bank                            provides                      BankComputer

BankComputer             maintains                    Accounts

BankComputer             processes                     Transaction                   against Account

Bank                            owns                            CashierStation

CashierStation              communicates with     BankComputer

Cashier                         enters                          Transaction                   for Account

ATMs                          communicate with       CentralComputer          about Transaction

CentralComputer          clears                           Transaction                   with Bank

ATM                            accepts                        CashCard

ATM                            interacts with              Customer

ATM                            dispenses                     Cash

ATM                            prints                           Receipt

 

Implicit verb phrases

 

Consortium                   consists of                   Banks

Bank                            holds                            Account

Consortium                   owns                            CentralComputer

Customers                    have                            CashCards

 

Additional implicit verb phrases from knowledge of the problem domain

 

Bank                            employs                       Cashiers

CashCard                     accesses                       Accounts

 

Now we eliminate the phrases that do not represent proper associations

 

1.      Only keep phrases where the subject has not been eliminated as a class candidate.  This is already done in this list.

2.      Irrelevant or implementation associations –

3.      Actions --  Associations describe static structural properties not temporal or transient ones.  In this example, ATMs print receipts and dispense cash have attributes as objects and indicate that dispense and print are two operations of an ATM.  ATMs accept CashCards is part of the transaction cycle.

4.      Ternary Associations – Most associations between three or more classes can be decomposed into binary associations or phrased as qualified associations.  Cashier enters transaction for account can be decomposed into Cashier enters transaction and Transaction concerns account.

5.      Derived Associations – omit associations that can be derived in terms of other associations.  As much as possible, classes and associations in the object model should represent independent information.  Multiple paths between classes in a diagram often indicate derived associations which are compositions of primitive associations.  Consortium shares ATMs is a composition of Consortium owns CentralComputer and CentralComputer communicates with ATMs.  Not all multiple paths between classes indicate redundancy.  If the multiplicity assignments are important and do not match then both associations may be needed.

 

Domain Model

   

 

Initial Object Model Diagram

 

 

The first refinement of this model is to assign attributes to the classes and organize classes by using inheritance to share common structure.  Look for classes with similar attributes and associations to make generalizations.  Qualifiers select from among objects in a set and remove multiplicity.  Only consider attributes that are visible in the problem domain and relate to the particular application at this time.

 

CashierTransaction and RemoteTransaction have the same association names, multiplicity, and attributes.  They should be generalized.   Similarly ATM and CashierStation have associations of the same name and perform the same kind of services.  We now incorporate this new view into a revision of the initial object model diagram.  Multiplicities can be removed by association qualifiers that distinguish between the multiple objects.

 

 

Iterating the Object Model:

 

  1. Signs of missing objects include: 
  2. Signs of unnecessary classes include

 

Further refinement of this model is suggested by the diagram.  The distinction between the Bank and the BankComputer does not affect the analysis.  The fact that communications are handled by computers is an implementation detail.  Transaction is not sufficiently general because it concerns only a single account.  In general transactions consist of one or more updates on individual accounts.  An update is a single action.

 

 

System Sequence Diagrams

System Operations

 

·        swipeCard

·        enterPasscode

·        selectTransaction

·        enterAmount

 

For each system operation write a contract in which you identify the objects (classes) that collaborate to provide the requested function.  Then construct the collaboration diagrams that detail the exchange of messages required to implement the indicated collaboration.