Table of Contents

1. Introduction .......................................................................................................................................... 2 1.1 1.2 1.3 Object oriented programming ...................................................................................................... 2 Overview ....................................................................................................................................... 2 Case study ..................................................................................................................................... 3

1.4 Objective ............................................................................................................................................. 5 1.5 Assumption ......................................................................................................................................... 5 2. UML diagrams ....................................................................................................................................... 7 2.1 2.2 What is UML .................................................................................................................................. 7 Use case diagram .......................................................................................................................... 7

2.2.1 Case Study use Case Diagram ...................................................................................................... 9 2.2.2 2.3 Case Study class Diagram .................................................................................................... 10

Sequence Diagram ...................................................................................................................... 13 Case Study Sequence Diagram ............................................................................................ 14

2.3.1 2.4

Activity Diagrams ........................................................................................................................ 16 Case study activity diagrams ............................................................................................... 16

2.4.1 3.

Design patterns ................................................................................................................................... 19 3.1 3.2 3.3 Abstract factory........................................................................................................................... 19 Proxy ........................................................................................................................................... 23 Prototype pattern ....................................................................................................................... 24

.................................................................................................................................................................... 25 4. 5. Application screen shots ..................................................................................................................... 26 Object oriented terminology explanation .......................................................................................... 34 5.1 5.2 5.3 5.4 Inheritance .................................................................................................................................. 34 Add new Customer ..................................................................................................................... 35 Encapsulation .............................................................................................................................. 37 Deposit ........................................................................................................................................ 38

Conclusion ................................................................................................................................................... 39 References .................................................................................................................................................. 40

OOSE ATM Assignment

1. Introduction
1.1 Object oriented programming
Object-oriented programming (OOP) is a programming paradigm using "objects" data structures consisting of data fields and methods together with their interactions to design applications and computer programs. Programming techniques may include features such as data abstraction, encapsulation, messaging, modularity, polymorphism and inheritance. Many modern programming languages now support OOP, at least as an option.

1.2 Overview
Simple, non-OOP programs may be one long list of commands. More complex programs will group lists of commands into functions or subroutines each of which might perform a particular task. With designs of this sort, it is common for the program's data to be accessible from any part of the program. As programs grow in size, allowing any function to modify any piece of data means that bugs can have wide-reaching effects. In contrast, the object-oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. Instead the data is accessed by calling specially written functions, commonly called methods, which are either bundled in with the data or inherited from "class objects" and act as the intermediaries for retrieving or modifying those data. The programming construct that combines data with a set of methods for accessing and managing those data is called an object. An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept such as a bank account, a hockey player, or a bulldozer. A program might well contain multiple copies of each type of object, one for each of the real-world objects the program is dealing with. For instance, there could be one bank account object for each realworld account at a particular bank. Each copy of the bank account object would be alike in the methods it offers for manipulating or reading its data, but the data inside each object would differ reflecting the different history of each account. Mohammad Rafati Page 2

OOSE ATM Assignment

Objects can be thought of as wrapping their data within a set of functions designed to ensure that the data are used appropriately, and to assist in that use. The object's methods will typically include checks and safeguards that are specific to the types of data the object contains. An object can also offer simple-to-use, standardized methods for performing particular operations on its data, while concealing the specifics of how those tasks are accomplished. In this way alterations can be made to the internal structure or methods of an object without requiring that the rest of the program be modified. This approach can also be used to offer standardized methods across different types of objects. As an example, several different types of objects might offer print methods. Each type of object might implement that print method in a different way, reflecting the different kinds of data each contains, but all the different print methods might be called in the same standardized manner from elsewhere in the program. These features become especially useful when more than one programmer is contributing code to a project or when the goal is to reuse code between projects.

1.3 Case study

The client/server architecture is a widespread one. Modern web servers, the ATM networks of banks, and many operating systems use a client server model. Most of these systems allow for multiple clients to interact with a server at once, and hence require the server to be safe when operating concurrently. For example, a busy web server has to be able to serve multiple pages at once if it is to service any serious volume of traffic. You know by now, though, that any concurrent systems have to deal with a host of issues above and beyond the regular correctness issues of single-threaded applications. The software to be designed will control a simulated automated teller machine (ATM) having a magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in multiples of $20), a printer for printing customer receipts, and a key-operated switch to allow an operator to start or stop the machine. The ATM will communicate with the bank's computer over an appropriate communication link. (The software on the latter is not part of the requirements for this problem.) Mohammad Rafati Page 3

OOSE ATM Assignment

The ATM will service one customer at a time. A customer will be required to insert an ATM card and enter a personal identification number (PIN) - both of which will be sent to the bank for validation as part of each transaction. The customer will then be able to perform one or more transactions. The card will be retained in the machine until the customer indicates that he/she desires no further transactions, at which point it will be returned - except as noted below. The ATM must be able to provide the following services to the customer: A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed. A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope. A customer must be able to make a transfer of money between any two accounts linked to the card. A customer must be able to make a balance inquiry of any account linked to the card. A customer must be able to abort a transaction in progress by pressing the Cancel key instead of responding to a request from the machine. The ATM will communicate each transaction to the bank and obtain verification that it was allowed by the bank. Ordinarily, a transaction will be considered complete by the bank once it has been approved. In the case of a deposit, a second message will be sent to the bank indicating that the customer has deposited the envelope. (If the customer fails to deposit the envelope within the timeout period, or presses cancel instead, no second message will be sent to the bank and the deposit will not be credited to the customer.) If the bank determines that the customer's PIN is invalid, the customer will be required to reenter the PIN before a transaction can proceed. If the customer is unable to successfully enter the Mohammad Rafati Page 4

OOSE ATM Assignment

PIN after three tries, the card will be permanently retained by the machine, and the customer will have to contact the bank to get it back. If a transaction fails for any reason other than an invalid PIN, the ATM will display an explanation of the problem, and will then ask the customer whether he/she wants to do another transaction. The ATM will provide the customer with a printed receipt for each successful transaction, showing the date, time, machine location, type of transaction, account(s), amount, and ending and available balance(s) of the affected account ("to" account for transfers). The ATM will have a key-operated switch that will allow an operator to start and stop the servicing of customers. After turning the switch to the "on" position, the operator will be required to verify and enter the total cash on hand. The machine can only be turned off when it is not servicing a customer. When the switch is moved to the "off" position, the machine will shut down, so that the operator may remove deposit envelopes and reload the machine with cash, blank receipts, etc.

1.4 Objective
Provide an automatic system in order to control the operation o bank ATM system Implement a system for bank staff in order to control the operation o their ATM system Making all the bank activities easy for client of the bank or cardholders of the bank Provide a efficient way of transferring the money between a number o account link to one card

1.5 Assumption
The system works normally with all the requirement of the system. System operator with 3 kinds of actors with different responsibility Customer o o o Deposit Withdraw Balance inquiry Page 5

Mohammad Rafati

OOSE ATM Assignment

o o o o o o Transfer between accounts Third party transfer

Operator Add new client Add new account for existing customer View transaction log Confirm deposit inside the system

Manager o o All the operator activity Add new operator to the system

The system has to be able to defines unlimited customer and unlimited number of account for the customer ,each account treats as an separate entity and has the ability of performing balance inquiry and all the bank activates When the user tries to log in, he/she can choose the prefer language at first. But all the language chosen in this system would be English. MOHAMMAD RAFATI

Mohammad Rafati

Page 6

OOSE ATM Assignment

2. UML diagrams
2.1 What is UML
The Unified Modeling Language (UML) is used to specify, visualize, modify, construct and document the artifacts of an software-intensive system under development UML offers a standard way to visualize a system's architectural blueprints, The Unified Modeling Language (UML) was adopted by the Object Management Group (OMG) in 2000 and is now the modeling language of choice for modeling application structure, behavior, architecture and data and, increasingly, business processes. Along with it is a key foundation of the modeling

Figure 1: UML

2.2 Use case diagram

In the Unified Modeling Language (UML) is a type of behavioral diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the

Mohammad Rafati

Page 7

OOSE ATM Assignment

functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases. The main purpose of a use case diagram is to show what system functions are performed for which actor. Roles of the actors in the system can be depicted. Use case diagrams are formally included in two modeling languages defined by the OMG: the Unified Modeling Language (UML) and the Systems Modeling Language.

Mohammad Rafati

Page 8

OOSE ATM Assignment

2.2.1 Case Study use Case Diagram

Figure 2: USECASE DIAGRAM

2.2.1.1Use Case Textual Description Preconditions: The ATM cash box is well stocked. There is no card in the reader. Main success scenario:

Mohammad Rafati

Page 9

OOSE ATM Assignment

The Card Holder inserts his or her smartcard in the ATMs card reader. The ATM verifies that the card that has been inserted is indeed a smartcard. The ATM asks the Card Holder to enter his or her pin number. The Card holder enters his or her pin number. The ATM compares the pin number with the one that is encoded on the chip of the smartcard. The ATM requests an authorization from the VISA authorization system. The authorization system confirms its agreement and indicates login. The ATM asks the Card Holder to enter the desired withdrawal amount. The Card Holder Enters the desired withdrawal amount.

A use case represents the specification of a sequence of actions, including variants that a system can perform, interacting with actors of the system. For each actor identified previously, it is advisable to search for the different business goals, according to which is using the system. Contrary to what we might believe, all actors do not necessarily use the system. We call the one for whom the use case produces an observable result the primary actor. In contrast, secondary actors constitute the other participants of the use case. A use case diagram shows the relationships among actors and the subject (system), and use cases. We draw use cases (ellipses) inside the ATM system (box) and linked by associations

2.2.2 Case Study class Diagram The class diagram has always been the most important diagram in all object oriented methods. This is the diagram that automatic code generation tools use first and foremost. Page 10

Mohammad Rafati

OOSE ATM Assignment

This is also the diagram that contains the widest range of notations and variants; Hence the difficulty in using all these concepts correctly. Identify domain concepts and model them as classes Identify associations between concepts; Think about the multiplicity on each side of an association; Add attributes to domain classes; Understand the difference between analysis and design levels; Use object diagrams to illustrate class diagram Use association classes, constraints and qualifiers; Structure our model into packages; Understand what an analysis pattern is. A class diagram is an illustration of the relationships and source code dependencies among classes in the Unified Modeling Language (UML). In this context, a class defines the methods and variables in an object, which is a specific entity in a program or the unit of code representing that entity. Class diagrams are useful in all forms of object-oriented programming (OOP). The concept is several years old but has been refined as OOP modeling paradigms have evolved.

Mohammad Rafati

Page 11

OOSE ATM Assignment

Figure 3: Class Diagram

Mohammad Rafati

Page 12

OOSE ATM Assignment

2.3 Sequence Diagram
UML sequence diagrams model the flow of logic within your system in a visual manner, enabling you both to document and validate your logic, and are commonly used for both analysis and design purposes. Sequence diagrams are the most popular UML artifact for dynamic

modeling, which focuses on identifying the behavior within your system. Sequence diagrams are typically used to model: Usage scenarios: A usage scenario is a description of a potential way in a system. The logic of a usage scenario may be part of a use case, perhaps an alternate course. It may also be one entire pass through a use case, such as the logic described by the basic course of action or a portion of the basic course of action, plus one or more alternate scenarios. The logic of a usage scenario may also be a pass through the logic contained in several use cases. For example, a student enrolls in the university, and then immediately enrolls in three seminars. The logic of methods: Sequence diagrams can be used to explore the logic of a

complex operation, function, or procedure. One way to think of sequence diagrams, particularly highly detailed diagrams, is as visual object code. The logic of services. A service is effectively a high-level method, often one that can be invoked by a wide variety of clients. This includes web-services as well as business transactions implemented by a variety of technologies such as CICS/COBOL or CORBA-compliant object request brokers (ORBs).

Mohammad Rafati

Page 13

OOSE ATM Assignment

2.3.1 Case Study Sequence Diagram 2.3.1.1 Login

Figure 4: Sequence Diagram - Login

2.3.1.2 Withdraw

Figure 5: Sequence Diagram - Withdraw

Mohammad Rafati

Page 14

OOSE ATM Assignment

2.3.1.3 Deposit

Figure 6: Sequence Diagram - Deposit

2.3.1.4 Third party Transfer

Figure 7: Sequence Diagram - Third party Transfer

Mohammad Rafati

Page 15

OOSE ATM Assignment

2.4 Activity Diagrams
Activity diagrams are typically used for business process modeling, for modeling the logic captured by a single use case or usage scenario, or for modeling the detailed logic of a business rule. Although UML activity diagrams could potentially model the internal logic of a complex operation it would be far better to simply rewrite the operation so that it is simple enough that you dont require an activity diagram. In many ways UML activity diagrams are the objectoriented equivalent of flow charts and data flow diagrams (DFDs) from structured development. 2.4.1 Case study activity diagrams 2.4.1.1 Login

Figure 8: Activity Diagram - Login

Mohammad Rafati

Page 16

OOSE ATM Assignment

2.4.1.2 Deposit

Figure 9: Activity Diagram Deposit

2.4.1.3 Withdraw

Figure 10: Activity Diagram - Withdraw

Mohammad Rafati

Page 17

OOSE ATM Assignment

2.4.1.4 Third party transfer

Figure 11: Activity Diagram - 3rd party transfer

Mohammad Rafati

Page 18

OOSE ATM Assignment

3. Design patterns
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such.

3.1 Abstract factory

Provide an interface for creating families of related or dependent objects without specifying their concrete classes. In this case study we implemented an abstract Person class and base on the requirement of the project we created the different object

Mohammad Rafati

Page 19

OOSE ATM Assignment

Figure 12: Abstract

Below is some samples created from abstract class without specifying their classes.

Mohammad Rafati

Page 20

OOSE ATM Assignment

Figure 13: Design Pattern - Abstract

Mohammad Rafati

Page 21

OOSE ATM Assignment

Figure 14: Design Pattern - Abstract

Mohammad Rafati

Page 22

OOSE ATM Assignment

3.2 Proxy
Proxy design pattern provides a surrogate or placeholder for another object to control access to it. In this case study we provide a proxy for performing the login section of our system actor, each object of the system based on their roles are referenced from proxy

Figure 15: Design Pattern - Proxy

Mohammad Rafati

Page 23

OOSE ATM Assignment

Figure 16: Design Pattern - Proxy

3.3 Prototype pattern

Prototype pattern is usually used to create objects when the process of object creation is time consuming when done from scratch. In this case an existing object is used as a prototype and similar objects are constructed using this prototype object. In java there is a facility to implement the prototype pattern. That's the Clone-able interface.

Mohammad Rafati

Page 24

OOSE ATM Assignment

Figure 17: Design Pattern - Prototype

Figure 18: Design Pattern Prototype

Mohammad Rafati

Page 25

OOSE ATM Assignment

4. Application screen shots
Language page In this page customer welcomes to the bank with the main screen and guide to the language menu in order to choose his/her suitable language

Main frame This frame can be used for the cardholders of the ATM to login into their Services Frame, Also there is a button for Staff of the system in order to login to perform different task.

Mohammad Rafati

Page 26

OOSE ATM Assignment

The Above Picture demonstrace the Staff Login frame for ATM operator

Mohammad Rafati

Page 27

OOSE ATM Assignment

Validation section The validation is provided in order to assure validity of program input

Mohammad Rafati

Page 28

OOSE ATM Assignment

Operator Frame The Operator frame Provide the Different Services for the Operator Services Include Add a new Customer and Cardholder to the System With Default Account number Add a new Operator to the System Add a new Account for existing Customers View all the transaction happened in the system View total amount of deposit View total amount of withdraw Confirm all the deposit made through the system

In the Operator Interface ,validation also Provided for Adding New Customer ,Addign new staff and etc .

Mohammad Rafati

Page 29

OOSE ATM Assignment

Services Frame The Card Holders of ATM after login use the Services frame in order to perform different Functionalities, the services available In the Services Frame include Withdraw Money From Different Accounts Deposit Money Into different Accounts Consult the Balance of Different Accounts Transfer the Money between Card holder Different Accounts Transfer the Money to Third party Person account Number

Mohammad Rafati

Page 30

OOSE ATM Assignment

Figure 19: Operator Panel

Figure 20: Transaction Log Frame

Mohammad Rafati

Page 31

OOSE ATM Assignment

The customer Can Withdraw from and deposit into account Using Keypad Provided in order to prevent form making error while entering the amount of transaction

Transfer money Section This section of program is used for transferring the Money between Customers Accounts

Mohammad Rafati

Page 32

OOSE ATM Assignment

Third party transfer In this section the Logged Customers is able to make a payment to third party person account by knowing his/her account Number ,First Customer enter the Third party account number ,after that ,System search the Database for matched record and if the record found ,and amount of transfer is invalid the transaction can be done.

Mohammad Rafati

Page 33

OOSE ATM Assignment

5. Object oriented terminology explanation
5.1 Inheritance

Mohammad Rafati

Page 34

OOSE ATM Assignment

5.2 Add new Customer

Figure 21: Add customer

Above figure in the add customer section check for the validity of input data such as empty fields and the correct type of input

Mohammad Rafati

Page 35

OOSE ATM Assignment

Figure 22: Add new customer

Above figure demonstrate that all the customer object field are initialized and the new customer will be added to the bank database after confirmation

Mohammad Rafati

Page 36

OOSE ATM Assignment

5.3 Encapsulation
Encapsulation demonstrates the entire object fields which are accessible through the defined access modifiers and not directly.

Figure 23: Encapsulation

Mohammad Rafati

Page 37

OOSE ATM Assignment

5.4 Deposit

Figure 24: Deposit

Above figure demonstrate that deposit transaction has been performed by the customer and after checking with banks server it goes for final confirmation by officer and one log of this transaction is added to the bank transaction collection for the usage of transaction log

Mohammad Rafati

Page 38

OOSE ATM Assignment

Conclusion
The whole project implemented in java programming languages and supported with the UML diagram is designed to be runes on the automated teller machine as an embedded system. In this project developer first analyze the system with UML diagrams such as use case diagram and activity diagram, class diagram and implementation is happened through the final design using the object oriented terminology and java as a programming language. There are some other functionality which was canceled to put to this project due short period of time and lack of knowledge. Still there were some limitations such as lack of original copy of visual paradigm application to draw the UML diagrams as you can see from the figures. The developer tried to put all requirement functionalities and features to this project, but there are some weakness due to graphical design or lack of knowledge to use a proper code to have smarter menus and command. MOHAMMAD RAFATI

Mohammad Rafati

Page 39

OOSE ATM Assignment

References
[Online] java how to program

Available at http://www.java2s.com/Code/JavaAPI/CatalogJavaAPI.htm Accessed on 10th august 2011

Java how to program ,second edition ,DEITEL and DEITEL ,2004 , DEITEL publisher

Mohammad Rafati

Page 40