Atm Simulator Project Report 67271z

Index Chapter 1: Introduction .......................................................................................................3 1.1 Problem Statement:...........................................................................................................3 1.3 Scope:................................................................................................................................4 1.4 Platform Specification:......................................................................................................5 Chapter 2: System Analysis .................................................................................................6 2.1 Identification of the Need:................................................................................................6 2.2 Preliminary Investigation:.................................................................................................6 Chapter 3: Feasibility Study ............................................................................................8 3.1 Technical Feasibility:........................................................................................................8 3.2 Economical Feasibility:.....................................................................................................8 3.3 Operational Feasibility:.....................................................................................................9 Chapter 4: Technology Used ..............................................................................................10 Container getContentPane( ).....................................................12 void add(comp).........................................................................12 Chapter 5: Technical Part ..........................................................................................16 5.1 Project Standard:.............................................................................................................16 5.2 Proposed Tools:...............................................................................................................16 5.3 JAVA Sockets:................................................................................................................16 5.3.1 Definition:................................................................................................................16 5.3.2 Java Socket Classes:.................................................................................................16 5.3.3 Socket Transmission Modes:...................................................................................19 Chapter 6: Software Engineering Approach ................................................................20 6.1 Software Engineering Paradigm Applied: .............20 6.1.1 Description:..............................................................................................................20 6.1.2 Advantages and Disadvantages: .............................................................................22 6.1.3 Reasons for Use:......................................................................................................23 6.2 Requirement Analysis:........................................................................................................23 6.2.3 Requirement Elicitation:..............................................................................................24 6.3 Planning Managerial Issue:.................................................................................................27 6.3.1 Planning Scope:............................................................................................................27 6.3.2 Project Resources:........................................................................................................27 6.3.3 Team Organization:......................................................................................................28 6.3.3.1 Team Structure......................................................................................................30 6.3.4 Risk Analysis:...................................................................................................................30 6.4 Design:.................................................................................................................................35 6.4.1 Design Concepts:..........................................................................................................35 6.4.2 Dataflow Diagrams:.....................................................................................................42 6.5 Implementation Phase:........................................................................................................45 6.5.1 Language Used Characteristics:...................................................................................45 6.6. Testing:...............................................................................................................................49 6.6.1 Testing Objectives:.......................................................................................................49 8.1 Limitation of the Project:................................................................................................68 8.2 Difficulties Encountered:................................................................................................69 1

8.3 Future Enhancement Suggestion:...................................................................................69 9.1 Reference Books:............................................................................................................71 9.2 Other Documentations and resources:............................................................................71

2

Chapter 1: Introduction.................................................................................. ........................................................................................................................... ........................................................................................................................... ........................................................................................................................... 1.1 Problem Statement:

The goal of this design is provide an interface which allows the controlling authority to remotely configure the system and to be accessible by a wide range of people. The interaction provides direct manipulation and natural language interfaces. Input will be in the form of a graphical interface. Output will be from high resolution graphics, and printed forms. The representation of information will be textual with iconic augmentation. Because of safety and privacy concerns the system will be put in fixed locations inside enclosures which will limit the interaction to one person at a time. The primary goal of developing such software is to develop software so that consumer can access a bank’s computer and carry out their own financial transactions without the mediation of a bank employee.  Who is the application for? A number of companies provide ATM products. Consequently, only a vendor or a large financial company could possibly justify the cost and effort of building ATM software. A small vendor would need some special feature to differentiate itself from the crowd and attract attention. Though this software fully implement the functionally of the ATM that is available in the

3

market today, but largely it includes all the essential features that an ATM software must have.

 What problem will it solve? The ATM software is intended to serve both bank and customer. For the bank, ATM software increases automation and reduces manual handling of routine paperwork. For the customer the ATM is ubiquitous and always available, handling routine transactions whenever and whenever the customer desires.  Where will it be used? ATM software has become essential to financial institutions. Customers take it for granted that a bank will have an ATM machine. ATM machines are available at many stores, sporting events, colleges and other locations throughout the world.  How will it work? We will adopt a three-tier architecture to separate the interface from programming language, and programming language from the database. In reality the architecture is n-tier architecture, because there can be any number of programming language communicating with each other. 1.3 Scope: Any software development effort is a financial institutions. From an economic perspective, it is desirable to minimize the investment, maximize 4

the revenue, and realize revenue as soon as possible. The domains of the software are the financial institutions. Customer takes it for granted that a bank will have an ATM machine. ATM machine are available at many stores, sporting events, colleges and other locations throughout the world. 1.4 Platform Specification:

1.4.1 Hardware: 

U (to control the interface and transaction devices)



Magnetic and/or Chip card reader (to identify the customer)



A Key-Board to provide input for the system



Display (used by the customer for performing the transaction)

1.4.2 Software:  Windows–XP.  Application tool – Java Development Kit. 1.4.3 Implementation Language: JAVA 2

5

Chapter 2: System Analysis

2.1 Identification of the Need:

The requirement of this project comes when End-s want to fetch money from his/her existing bank . Thus using a right technique or approach will not only help the in of time, but will also get the correct

information.

Using

an

ATM,

customers

can

access

their

bank s in order to make cash withdrawals, credit card cash advances, and check their balances as well as purchase prepaid cell phone credit. If the currency being withdrawn from the ATM is different from that which the bank is denominated in (e.g.: Withdrawing Japanese Yen from a bank containing US Dollars), the money will be converted at a wholesale exchange rate. Thus, ATMs often provide the best possible exchange rate for foreign travelers and are heavily used for this purpose as well. 2.2 Preliminary Investigation:

There are 1.5 million ATMs deployed around the world today and this figure is forecast to reach 2 million by 2011 according to Retail Banking Research. With 63% of all bank customer transactions taking place via the ATM, the ATM is one of the most fundamental and important of all channels for customers. It is time that ATMs evolve from being simply a mechanism for cash withdrawal to become an integral part of the customer’s 6

communication with the bank. In order to minimize costs and to ensure that the ATM channel remains self sufficient, it is becoming increasingly important to offer a broader transaction set via the ATM. With the advent of new Windows based software combined with any ATM hardware, banks can now offer revenue generating facilities such as mobile top-up and bill payment as well as provide a vehicle for targeted third party and own products and services advertising.

7

Chapter 3: Feasibility Study 3.1 Technical Feasibility:

All projects are feasible, given unlimited resources and infinite time. Unfortunately, the development of a computer based system or product is more likely suffered by a scarcity of resources and difficult delivery dates. It is both necessary and prudent to evaluate the feasibility of a project at the earliest possible time. However during the development of our project we concentrate on the following feasibility: Resource Availability: Are the hardware and software resources required available to develop the application? Technology: Has the relevant technology progressed to the stage that will the system? 3.2 Economical Feasibility:

Economic justification is “bottom – line “consideration for most system. Economic justification includes a broad range of concern that includes cost-benefit analysis, long term corporate income strategies, and cost of resources needed for development. As far as monetary matters are concerned

8

we need hard disk space of 2GB and a Pentium processor. These are only requirements, which can be easily met.

3.3 Operational Feasibility:

Operational feasibility is mainly concerned with issues like whether the system will be used if it is developed and implemented. Whether there will be resistance from s that will affect the possible application benefits? The answer to these questions is: Yes, as the system is developed for the convenience of the network who is the main of the system. A block diagram of a generalized ATM System is shown below.

9

Chapter 4: Technology Used Socket programming in JAVA. We have used JAVA Programming Language and the kit used is JDK. JAVA is a platform independent language, which is the biggest benefit of using it. JAVA does not use pointer because pointer are security loophole. Applet is a special type of JAVA program that has been used to implement the system. It provides better security .It is portable and provide high performance. Our project has been completely coded in JAVA, one of the most powerful programming languages. Java is an Object-Oriented Programming Language developed by Sun Microsystems that plays to the strength of the Internet. Object-Oriented Programming (OOP) is an unusual, but powerful way to develop software. In OOP, a computer program is considered to be a group of objects that interact with each other. Java is also related to C++, which is a direct descendent of C. java derives its syntax from C and many of its object oriented features are influenced by C++. Another design decision to make Java simpler is its elementary data types and objects. The language enforces very strict rules regarding variables--in almost all cases, you have to use variables as the data type they were declared to be, or use explicit casts to manipulate them. This arrangement permits mistakes in variable use to be caught when the program is compiled, rather than letting them creep into a running program where they're harder to find. As a result, programs behave in a more predictable manner.

10

“Java is just a small, simple, safe, object-oriented, interpreted or dynamically optimized, byte-coded, architecture-neutral, garbage-collected, multithreaded programming language with a strongly typed exceptionhandling mechanism for writing distributed, dynamically extensible programs.” A Java program is created as a text file with the file extension .java. It is compiled into one or more files of byte codes with the extension .class. Byte codes are a set of instructions similar to the machine code instructions created when a computer program is compiled. The difference is that machine code must run on the computer system it was compiled for; byte codes can run on any computer system equipped to handle Java programs. Java Development Kit (JDK): When the Java programming language was introduced in 1995, the only development tool available was the Java Development Kit (JDK) from Sun. This set of command-line tools makes it possible to write, compile, and debug Java programs (among other things). However, the JDK is a far cry from integrated development environments such as Visual Basic and Borland C++. An integrated development environment (IDE) is software that combines several development tools into a single, cohesive package. The assortment usually includes a source code editor, compiler, debugger, and other utilities. These tools work together through the development process; most packages are highly visual and rely on windows, drag-and-drop, and other graphical elements. The goal is to make software design faster, more efficient, and easier to debug. Following is a list of the main components of the JDK:

11

 Runtime interpreter  Compiler  Applet viewer  Debugger  Class file dissembler  Header and stub file generator  Documentation generator  Archive  Digital signer  Remote Method Invocation tools  Sample demos and source code  API source code Exploring Swing: The Swing-related classes are contained in javax.swing. Many other Swingrelated components exist such as: JApplet: Fundamental to Swing is the JApplet class, which extends Applet. For adding a component to an instance of JApplet one can call add ( ) for the content pane of the JApplet object. The content pane can be obtained via the method shown here: Container getContentPane( ) The add( ) method of Container can be used to add a component to a content pane. Its form is shown here: void add(comp) 12

Here, comp is the component to be added to the content pane. Text Fields: The Swing text field is encapsulated by the JTextComponent class, which extends JComponent. It provides functionality that is common to Swing text components. One of its subclasses is JTextField, which allows you to edit one line of text. Buttons: Swing buttons provide features that are not found in the Button class defined by the AWT. Swing buttons are subclasses of the AbstractButton class, which extends JComponent. AbstractButton contains many methods that allow you to control the behavior of buttons, check boxes, and radio buttons. The JButton Class The JButton class provides the functionality of a push button. JButton allows an icon, a string, or both to be associated with the push button. Some of its constructors are shown as: JButton(Icon i) JButton(String s) JButton(String s, Icon i) Here, s and i are the string and icon used for the button. Check Boxes: The JCheckBox class, which provides the functionality of a check box, is a concrete implementation of AbstractButton. Its immediate superclass is JToggleButton, which provides for two-state buttons. Some of its constructors are shown here: JCheckBox(Icon i) JCheckBox(Icon i, boolean state) JCheckBox(String s) 13

JCheckBox(String s, boolean state) JCheckBox(String s, Icon i) JCheckBox(String s, Icon i, boolean state) Here, i is the icon for the button. The text is specified by s. If state is true, the check box is initially selected. Otherwise, it is not. The state of the check box can be changed via the following method: void setSelected(boolean state) Here, state is true if the check box should be checked. Combo Boxes: Swing provides a combo box (a combination of a text field and a drop-down list) through the JComboBox class, which extends JComponent. A combo box normally displays one entry. However, it can also display a drop-down list that allows a to select a different entry. You can also type your selection into the text field. Two of JComboBox’s constructors are shown here: JComboBox( ) JComboBox(Vector v) Here, v is a vector that initializes the combo box. Items are added to the list of choices via the addItem( ) method, whose signature is shown here: void addItem(Object obj) Here, obj is the object to be added to the combo box. Tables: A table is a component that displays rows and columns of data. You can drag the cursor on column boundaries to resize columns. You can also drag a column to a new position. Tables are implemented by the JTable class, which extends JComponent. One of its constructors is shown as: 14

JTable(Object data[ ][ ], Object colHeads[ ]) Here, data is a two-dimensional array of the information to be presented, and colHeads is a one-dimensional array with the column headings. Here are the steps for using a table in an applet: 1. Create a JTable object. 2. Create a JScrollPane object. (The arguments to the constructor specify the table and the policies for vertical and horizontal scroll bars.) 3. Add the table to the scroll pane. 4. Add the scroll pane to the content pane of the applet.

15

Chapter 5: Technical Part The technical description of a project is specified in of the following: 5.1 Project Standard: Project standard defines the kind or type of the project. Our project is application software. 5.2 Proposed Tools: We will be making use of JAVA programming language as a software tools for the development of the application. 5.3 JAVA Sockets: 5.3.1 Definition: A socket is one endpoint of a two-way communication link between two programs running on the network. A socket is bound to a port number so that the T layer can identify the application that data is destined to be sent. 5.3.2 Java Socket Classes: The Socket class has been defined in java.net package. Java s two types of Socket communication.  T (Transmission Control Protocol) Sockets  UDP ( Datagram Protocol) Sockets A Socket is a logical software construct. Each Socket is associated with a particular port number. A port is not a physical entity like a place but it is logical thing. From a particular port number we can transmit and receive information. The lower port numbers are reserved for some particular services 16

like SMTP (Simple Mail Transfer Protocol) runs on port number 25, HTTP (Hyper Text Transfer Protocol) on port number 80. Therefore generally a port number greater than 2000 is chosen to avoid conflicts. Anything that understands the standard protocol can plug into the socket and can communicate. Both T/IP and UDP Sockets can be created. T/IP Sockets are used to implement reliable, bi-directional, persistent, point-to-point, stream based connections between hosts. A Socket can be used to connect two Java’s

I/O system to other programs that may

reside on local or remote machine. Java has two types of Sockets.  Server Socket: For Server

 Socket: For Client The Socket class is designed to connect to the server sockets. The creation of the Socket object implicitly establishes a connection between client and server. Normally, a server runs on a specific computer and has a socket that is bound to a specific port number. The server just waits, listening to the socket for a client to make a connection request. On the client-side: The client knows the hostname (IP address) of the machine on which the server is running and the port number on which the server is listening. To make a connection request, the client tries to make with the server on the server's machine and port. The client also needs to identify itself to the server so it binds to a local port number that it will use during this connection. This is usually assigned by the system. 17

If everything goes well, the server accepts the connection. Upon acceptance, the server gets a new socket bound to the same local port and also has its remote endpoint set to the address and port of the client. It needs a new socket so that it can continue to listen to the original socket for connection requests while tending to the needs of the connected client.

On the client side, if the connection is accepted, a socket is successfully created and the client can use the socket to communicate with the server. The client and server can now communicate by writing to or reading from their sockets. Therefore we can say that “A socket is one endpoint of a two-way communication link between two programs running on the network. A socket is bound to a port number so that the T layer can identify the application that data is destined to be sent.” An endpoint is a combination of an IP address and a port number. Every T connection can be uniquely identified by its two endpoints. That way we can have multiple connections between your host and the server. The java.net package in the Java platform provides a class “Socket” that 18

implements one side of a two-way connection between one Java program and another program on the network. The Socket class sits on top of a platformdependent implementation, hiding the details of any particular system from our Java program. By using the java.net.Socket class instead of relying on native code, your Java programs can communicate over the network in a platform-independent

fashion.

Additionally,

java.net

includes

the

ServerSocket class, which implements a socket that servers can use to listen for and accept connections to clients. 5.3.3 Socket Transmission Modes:

Sockets have two major modes of operation: connection-oriented and connectionless modes. Connection-oriented sockets operate like a telephone: they must establish a connection and then hang up. Everything that flows between these two events arrive in the same order it was sent. Connectionless sockets operate like the mail: delivery is not guaranteed, and multiple pieces of mail may arrive in a different order than they were sent. The mode we use is determined by an application's needs. If reliability is important, connection-oriented operation is better. File servers must have all their data arrive correctly and in sequence. If some data is lost, the server's usefulness is invalidated. Connectionless operation uses the Datagram Protocol (UDP). A datagram is a self-contained unit that has all the information needed to attempt its delivery. Think of it as an envelope-it has a destination and return address on the outside and contains the data to be sent on the inside. A socket in this

19

mode does not have to connect to a destination socket; it simply sends the datagram. The UDP protocol promises only to make a best-effort delivery attempt. Connectionless operation is fast and efficient, but not guaranteed. Connection-oriented operation uses the Transport Control Protocol (T). A socket in this mode must connect to the destination before sending data. Once connected, the sockets are accessed using a streams interface: open-read-write-close. Everything sent by one socket is received by the other end of the connection in exactly the same order it was sent. Connectionoriented operation is less efficient than connectionless operation, but it's guaranteed.

Chapter 6: Software Engineering Approach 6.1 Software Engineering Paradigm Applied: 6.1.1 Description:

20

Software Engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently. It is a layered technology. The bedrock that s software engineering is a quality focus. Software engineering encomes a process management technical methods and tools. The foundation for software engineering is the process layer. Process defines a framework for a set of key process areas. Software engineering methods provide the technical how-to for building software. Software engineering tools provided automated or semi automated for the process and the methods. Incremental Model: Incremental model combines elements of the linear sequential model with the iterative philosophy of prototyping. The incremental model applies linear sequences in a staggered fashion as calendar time progresses. Each linear sequence produces a deliverable increment of the software. In our project we intend to use this Linear Sequential Model (Waterfall Model) because our project Task modules are dependent closely on each other. Therefore if we try our hands on a Concurrent Model then the complexity in its implementation could make the conditions worse. We require completing one task at a time so as to pave the way for other task to begin. Such high degree of dependency makes the condition ideal for using the Incremental Model. Implementing this model in this project heightens the efficiency of the system and yet maintains the complexity under control.

21

Fig. Showing the Incremental Model 6.1.2 Advantages and Disadvantages:

Advantages:  Early increments can be developed with few people.  Increments can be planned to manage technical risks.  Deadlines can be managed in an effective manner. Disadvantages:  Reusability of codes among the modules is minimum.  Integration testing is difficult to do.

22

6.1.3 Reasons for Use:

The project can be created through a series of delivery steps with each delivery steps adding a new feature to the existing product. Thus the process model suited to the project is Incremental Model. It combines elements of the Linear Sequential model with the interactive philosophy of prototyping. Our project demanded to be on time so this model helped us in the right way. Such an approach does not call for many people working on the initial increments so it served us right. And such increments were very well planned with minimized set of technical risks coming our way. 6.2 Requirement Analysis:

Requirements are a feature of a system or description of something that the system is capable of doing in order to fulfill the system’s purpose. It provides the appropriate mechanism for understanding what the customer wants, analyzing the needs, assessing feasibility, negotiating a reasonable solution unambiguously, validating the specification and managing the requirements as they are translated into an operational system. The requirement analysis founded a base on the new Information System that is to be implemented and provided the guidelines to move further on developing this project. 6.2.1 Functional Requirements The functional requirements are organized in two sections; Requirements of the ATM and Requirements of the bank computer. ∗ Requirements of the ATM 23

− authorization process − transaction (withdrawal process) ∗ Requirements of the bank computer − authorization process (bank code and ) − transaction 6.2.2 Non-functional Requirements The non-functional requirement is bellowed. ∗ The ATM network has to be available 24 hours a day. ∗ Each bank may be processing transactions from several ATMs at the same time. ∗ The ATM must be able to use several data formats according to the data formats that are provided by the database of different banks.

6.2.3 Requirement Elicitation: Acknowledgement: A response sent by the receiver to indicate the successful receipt and acceptance of data. Broadcasting: Transmission of a message to all nodes in a network. Buffer: Memory set aside for temporary storage. Class: A template for creating objects. A class defines data and methods and is a unit of organization in a Java program. It can on its public data and methods to its subclasses. Client: A program that initiates communication with another program called the server.

24

Client Server Model: The model of interaction between two application programs in which a program at one end (client) request a service from a program at the other end (server). Guided Media: Transmission media with a physical boundary. IP address: A 32bit address used to uniquely define a host on an Internet. Java:

An

object-oriented

programming

language

for

creating

distributed, executable applications Local Area Network (LAN): A network connecting devices inside a single building or inside buildings close to each other. Mbps: Mega bits per second. Message: A message is the content of the communication between 2 processes. Method: A function that can perform operations on data. Model: A model is a representation of the system. Network Interface Card (NIC): An electronic device, internal or external to a station that contains circuitry to enable a station to be connected to the network. Object: A variable defined as being a particular class type. An object has the data and methods as specified in the class definition. Operation: An operation is a function that can be performed on an object. Port: A number used to identify T/IP applications. Generally a port is an entry or exit point. Process: It is an operating system concept that captures the idea of a program in execution. A process is always executing at some points in a program. 25

Processor: It is the part of a computer system that executes instructions. It is also called a U. Robot: A term for software programs that automatically explore the Web for a variety of purposes. Robots that collect resources for later database queries by s are sometimes called spiders. Server: A program that can provide services to other programs, clients. Socket: In T/IP, an addressable point that consists of an IP address and a T or UDP port number that provides applications with access to T/IP protocols. Socket Address: The complete designation of a T/IP node consisting of a 32-bit IP address and a 16-bit port number. T/IP (Transmission Control Protocol/Internet Protocol): The set of protocols used for network communication on the Internet. Thread: A thread is software object that can be dispatched and executes in an address space. Throughput: The number of bits that can through a point in one second. Topology: A structure of network including physical arrangement of devices. : a is person who is using a computer system by running processes on it. Performance: While deciding the performance of any software, its speed, response time, throughput, resource utilization & efficiency must be taken into consideration.

26

Reliability: The reliability is the mean time to failure, accordingly the to have higher reliability the mean time to failure should be very large. This software provides relevant results and these results would be quick. As far as recovery is concerned, it provides reliable and consistent recovery of complete file. ability: This software is able on Windows XP Platform and all others which JAVA Framework. Usability: The software can be used to provide various services of the ATM systems that are used by the banks and any other financial institutions. It can be used as a computerized telecommunications device that provides the clients of a financial institution with access to financial transactions in a public space without the need for a cashier, human clerk or bank teller.

6.3 Planning Managerial Issue: 6.3.1 Planning Scope: Project planning describes the data and control to be preceding function, performance, constraints, interfaces and reliability. Functions described in the statement of scope are evaluated and in some cases refined to provide more detail prior to the beginning of estimation. 6.3.2 Project Resources: 1. Human Requirements: The human requirements for the software refer to the number of persons required for developing, using, and maintaining the product. The 27

minimum human requirement for our project is 1. However, our team for the project development consists of 4 . However, for using and maintaining the software, one person would suffice. 2. Hardware Requirement: Our software can work on a system with minimum hardware configuration. Each system can even be a 450 MHz processor. A 96MB & 128 MB RAM would also suffice. 3. Software Requirement: The application is platform independent. So it can run on Windows XP. It does not require any other software than JDK 1.4 to run. 4. Skills possessed by developers: The developers of this software should be well versed with Java language. 5. Time: The stipulated time for the development of the application was 4-5 months. 6.3.3 Team Organization: There are basically four types of project teams namely:-

28

1. Democratic Decentralized (DD) 2. Controlled Decentralized (CD) 3. Controlled Centralized (CC) 4. Democratic Decentralized (DD) Democratic Decentralized (DD) The team structure can be specified as The team working to build this software comprises of three under the guidance of a project guide. Our software engineering team has no permanent leader. Rather, “task coordinators are appointed for short durations and then replaced by others who may coordinate different tasks”. Decisions on problems and approach are made by group consensus and are taken democratically. Communication among team is horizontal.

Controlled Decentralized (CD) In CD organization there is a defined leader. Leader co-operate specific task. Secondary leader perform sub-task Problem solving is group activity. Communication between team is horizontal or vertical. Controlled Centralized (CC) In CC organization there is a defined leader. Top level is problemsolving team. Team leader manages every thing. Communication between team is vertical. 29

6.3.3.1 Team Structure

The software team for our project is a Democratic Decentralized (DD) team. The salient features of our team are: 1. There is no permanent leader of the team. 2. The decision making process is a team activity. 3. The communication between the team is horizontal.

6.3.4 Risk Analysis:

Risk Identification and Types: A risk is any unfavorable event or circumstance that can occur while a project is underway. If a risk becomes true, it can hamper the successful and timely completion of a project. Therefore, it is necessary to anticipate and identify different risks that a project is susceptible to. Risk management aims at dealing with all kind of risks that might affect a project.

30

Type of risks: Project risk: Project risks threaten the project plan. For example: If a project risk occurs in reality, then it is likely that the project schedule will slip and that the cost will increase. Project risk identify potential budgetary, schedule, personnel, resource, customer and requirements problems and their impact on software project. The project risk in our application id that due to sudden illness of a team member, the schedule may be affected and all the requirements may not be met practically. Technical risk: Technical risk threatens the quality and timeliness of the software to be produced. A technical risk makes implementation difficult or at times, impossible. Technical risk identifies the potential design, implementation, interfacing, maintaining and verification problems. The technical risk of our project includes that it may be difficult to represent a full length on a single screen and how to implement the difficulty level concept. Business risk: Business risk threatens the viability of the software to me built. Business risk often jeopardizes the product or project. This risk occurs when a product or a system is built correctly but it is not wanted in the market (known as market risk) .or when a product is built without keeping the overall 31

business strategy of the company in mind (known as strategic risk), or when a product does not fetch the price in the market it is expected to (known sell risk), or the tem do not work cohesively towards completing the product (management risk), or when the cost of the product exceeds the budgetary allocation (known as budget risk) . The business risk in our project in our project lies in the fact that it may not be required as it may not give that feel of the preparation or a better application by other professionals might have been developed. Known risk: Known risk is risks that are previously known to the developers. These risks include t he delays related to the delivery date of the project. The known risk of our project is that it may not be submitted on desired date. Predictable risk: Predictable risk are risks that can be foretold based on experience gained in developing past project, Or in developing previous segments gained in developing past projects, or in developing previous segments of the current project. For example a risk ignored in the analysis phase is likely to cause a risk in the design phase. In our project test generation module can pose a few problems as to decide an equal distribution of different types of questions and to decide the next test. Unpredictable risk:

32

Unpredictable risks are undesirable events that occur unexpectedly. This type of risk covers such situations like the one where the changes his requirement during the development of the project. The unpredictable risk which may exist is the formatting issue related to the display of the test. Risk Projection Table: A risk table is a technique for Risk Projection. Risk Projection is an attempt to delineate the effects of risk based on two factors – the probability that the risk is real, and the consequences associated with the occurrence of the risk, should the risk occur.

S.

Risk

No.

Risk Application designed

Category Probability Impact Exposure

becomes outdated Inexperienced Developers Delivery Date tightened Cost Exceeds Budget Change in Requirement Technology will not meet

BI SE BI BI PS

40% 60% 50% 25% 10%

2 2 2 3 4

0.8 1.2 1 0.75 0.4

6 expectations Design Problems and

TE

60%

1

0.6

7 Bugs 8 Insufficient Time for

SE TE

20% 20%

2 2

0.4 0.4

1 2 3 4 5

33

Testing 9 Lack of Training on Tools

DE

80%

2

1.6

Legend used in risk projection table BI = Business Impact SE = Staff Size and Experience PS = Product Size TE = Technology to be built DE = Development Environment Risk Impact categories:  Catastrophe  Critical  Marginal  Negligible Risk Prioritization: Based on the impact of the individual risks, we can prioritize them in the order of their removal as follows

 Size of Project becomes large.

Decreasing Priority

Design does not meet requirements.

34

 Delivery Deadline will be tightened.  Insufficient Time for Testing  Larger Number Of than Planned.  Customer changes the requirements.  Lack of Training on Development Tools.  Technology does not meet requirements.  End s resist system.  Project Loss due to Hard Disk Failure. Project specific risks:  Unformatted image can be sent by the client machine causes the server could not align the image of different client machine.  The network connection can not be maintained.  Due to load server machine may go done.  The network may not respond well under load.

6.4 Design: 6.4.1 Design Concepts:

A set of fundamental software design concepts has evolved over the past three decades. Each provides the software designer with a foundation from which more sophisticated design methods can be applied. A short description of the various design concepts is presented below: 35

Abstraction: There are three types of abstractions that are generally encountered: Procedural Abstractions: A procedural abstraction is a named sequence of instruction that has a specific and limited function. There are three levels of procedural abstraction, they are: 1. Higher Level: To provide the security services to the Clients when they connect to the outside network. To accomplish this task we restrict the unauthorized access of different clients. 2. Middle Level: We provide security services by different techniques such as authentication, istration, usage auditing etc. in our project. 3. Lower Level: We have different modules to provide the security to the clients. The different modules of our project are Basic services module, Security Services

36

module, Identification Services module, istration Services module, Usage ing Services module, Caching module. Data abstraction: 1. Higher Level: The packets are flowing between proxy server and client and vice versa. 2. Lower Level: The data flowing through different modules are IP addresses of different Machines, , Log-off time, services requested and response provided. Refinement: Software refinement is a top-down design strategy originally proposed by Niklaus Writh. A hierarchy is developed by decomposing a macroscopic statement of function (a procedural abstraction) in a step-wise fashion until programming language statements are reached. Refinement is actually a process of elaboration. Refinement causes the designer to elaborate on the original statement, providing more and more detail as each successive refinement (elaboration) occurs.

Modularity:

37

Software architecture embodies modularity; that is, software is divided into separately named and addressable components called modules that are integrated to satisfy problem requirements. Modularization reduces the effort and complexity of the problem, hence it should be followed, but care should be taken to avoid under modularity or over modularity.

Design Techniques:  Bottom up Design  Top-Down Design  Hybrid Design

1. Bottom up Design: This approach lead to a style of design where we decide how to combine lower level modules to provide larger ones; to combine those to provide even larger ones, and so on, till we arrive at one big module which is whole of the desired program. Since the design progress from bottom layer upwards, the method is called bottom up design. The main argument for this design is that if we start coding a module soon after its design, the chances of recoding is high; but the coded module can be tested and design can be validated sooner than module whose sub modules have not yet been designed .The limitation of this design is that

38

we need to use a lot of intuitions to decide exactly what functionality a module should provide. If we get it wrong, then at higher level, we will find it is not as per requirement; than we have to redesign at a lower level. If a system is to be build from an existing system this approach is more suitable, as it starts from some existing modules.

39

2. Top-Down Design: A top-down design approach starts by identifying the major modules of the system, decomposing them into there lower level modules and iterating until the desired level of details is achieved. This is stepwise refinement; starting from an abstract design, in each step the design is refined to a more concrete level, until we reach a level when no more refinement is required and the design can be implemented directly. Most design methodologies are based on this approach and this is suitable, if the specification is clear and development is from scratch. If coding of a part start soon after design, nothing can be tested until all its subordinate modules are coded.

40

3. Hybrid Design: Pure top-down and pure bottom-up approaches are often not practical. For a bottom up approach to be successful, we must have a good notion of the top at which the design should be heading. Without a good idea about the operations needed at the higher layers, it is difficult to determine what operations the current layers should . For top-down approach to be effective, some bottom up approach is essential for the following reasons: 41

 To permit common sub modules.  Near the bottom of the hierarchy, where the intuitions is simpler, and the need for the bottom-up testing is greater.  In the use of pre-written library modules, in particular, reuse of modules.

6.4.2 Dataflow Diagrams:

As in our project no database is used therefore there is no Entity/Relationship Diagram, Control Flow Diagram, State Transition Diagram and dataflow diagram except that the data is flowed across the LAN using T/IP protocol.

42

43

44

6.5 Implementation Phase:

6.5.1 Language Used Characteristics:

The main features of Java which makes it such a widely used language across the globe are described as follows: Java Is Small and Simple: However, Java has been described as "C++ minus" because of elements of C++ that were omitted. The most complex parts of C++ were excluded from Java, such as pointers and memory management. These elements are complicated to use, and are thus easy to use incorrectly. Finding a pointer error in a large program is an experience not unlike searching for the onearmed man who framed you for murder. Memory management occurs automatically in Java--programmers do not have to write their own garbagecollection routines to free up memory. Another design decision to make Java simpler is its elementary data types and objects. The language enforces very strict rules regarding variables--in almost all cases, you have to use variables as the data type they

45

were declared to be, or use explicit casts to manipulate them. This arrangement permits mistakes in variable use to be caught when the program is compiled, rather than letting them creep into a running program where they're harder to find. As a result, programs behave in a more predictable manner.

Java Is Object Oriented: Object-oriented programming (OOP) is a powerful way of organizing and developing software. The short-form description of OOP is that it organizes a program as a set of components called objects. These objects exist independently of each other, and they have rules for communicating with other objects and for telling those objects to do things. Think back to how Star7 devices were developed as a group of independent devices with methods for communicating with each other. Object-oriented programming is highly compatible with what the Green project was created to do and, by extension, for Java as well. Java inherits its object-oriented concepts from C++ and other languages such as Smalltalk. The fact that a programming language is object oriented may not seem like a benefit to some. Object-oriented programming can be an intimidating subject to tackle, even if you have some experience programming with other languages. However, object-oriented programs are more adaptable for use in other projects, easier to understand, and more bug proof. The Java 46

language includes a set of class libraries that provide basic variable types, system input and output capabilities, and other functions. It also includes classes to networking, Internet protocols, and graphical interface functions.

Java Is Safe: Another thing essential to Java's success is that it is safe. The original reason for Java to execute reliably was that people expect their waffle irons not to kill them or to exhibit any other unreliable behavior. This emphasis on security was well-suited for Java's adaptation to the World Wide Web. Java provides security on several different levels. First, the language was designed to make it extremely difficult to execute damaging code. The elimination of pointers is a big step in this regard. Pointers are a powerful feature, as the programmers of C-like languages can attest, but pointers can be used to forge access to parts of a program where access is not allowed, and to access areas in memory that are supposed to be unalterable. By eliminating all pointers except for a limited form of references to objects, Java is a much more secure language. Another level of security is the byte code verifier. Before a Java program is run, a verifier checks each byte code to make sure that nothing suspicious is going on. In addition to these measures, Java has several safeguards that apply to applets. To prevent a program from committing random acts of violence

47

against a 's disk drives, an applet cannot, by default, open, read, or write files on the 's system.

Java Is Platform Independent: Platform independence is another way of saying that Java is architecture neutral. If both leave you saying "huh?" they basically mean that Java programs don't care what system they're running on. Most computer software is developed for a specific operating system. Platform independence is the capability of the same program to work on different operating systems; Java is completely platform independent. A Java .class file of byte code instructions can execute on any platform without alteration.

Java is Architecture-Neutral: The Java designers made several hard decisions in the Java language and the Java Virtual Machine in an attempt to alter the situation of programs not running on the same machine after few days. Their goal was “Write once; run anywhere, any time, forever”. 48

Java is distributed: Java is designed for the distributed environment of the Internet, because it handles T/IP protocols. The feature of inter-address-space messaging is done with the help of the package Remote Method Invocation”. This feature brings an unparalleled level of abstraction to the client/server programming.

Java is Dynamic: Java programs carry with them substantial amounts of run-time type information that is used to and resolve accesses to objects at run-time. This makes it possible to dynamically link code in a safe and expedient manner. This is crucial to the robustness of the applet environment. Platform and tools used: Platform is any windows operating system with JVM 6.6. Testing: 6.6.1 Testing Objectives: Software Testing is a critical element of software quality assurance and the ultimate review of specification, design and code generation. Testing of the software leads to uncovering of errors in the software and reveal that whether software’s functional and performance are met. Testing also provides a good indication of software reliability as software quality as a whole. The 49

result of different phases are evaluated and then compared with the expected results. If the errors are uncovered they are debugged and corrected. A strategy approach to software testing has the generic characteristics:  Testing begins at the module level and works outwards towards the integration of the entire computer based system.  Different testing techniques are appropriate at different point of time.  Testing and debugging are different activities, but debugging must be accommodating in the testing strategy. A strategy for the software testing must accommodate low level test that are necessary to that a small source code segment is performing correctly according to the customers’ requirement and that of developers’ expectations. Testing Objectives:  Testing is the process of executing a program with the intent of finding an error.  A good test case is one which has a high probability of finding an as yet undiscovered error.  A successful test is one that uncovers an as yet undiscovered error.

Our objective is to design tests that systematically uncover different classes of errors and to do so with minimum amount of time and effort.

50

Testing Principles: • All tests should be traceable to customer requirements. • Tests should be planned long before testing begins. • The Pareto principle applies to software testing. • Testing should begin “in the small” and progress towards testing “in the large”. • Exhaustive testing is not possible. • To be most effective, testing should be conducted by an independent third party.

6.6.2 Testing Methods and Strategies Used: Test Case Design: Black box testing: This testing alludes to tests that are conducted at the software interface. Although they are designed to uncover errors, black-box tests are used to demonstrate that software functions are operational, that input is properly accepted and output is correctly produced, and that the integrity of external information is maintained. A black-box test examines the fundamental aspects of a system with little regard for internal logical structure of the software.

51

White box testing: White box software testing is predicated on close examination of procedural detail. Logical paths through the software are tested by providing the test cases that exercise specific sets of conditions or loops. The “status of program” may be examined at various points to determine if the expected or asserted status corresponds to the actual status. The testing method used for the encryption and decryption in cryptography is White box testing also called glass box testing in combination

52

with Black Box testing. White Box testing is a test case design method that uses control structure of procedural design to derive test cases. Using the white box testing methods, the software engineer can derive test cases that guarantees that

 All independent paths within a dingle module have been exercised at least once.  Exercise all logical decisions on their true false sights.  Execute all loops at their loops and within their operational bounds.  Exercise internal data structures to assure their validity.

White Box Testing should not be dismissed as impractical. A limited no of important logical parts can be and exercised. Important data structures can be probed for their validity. It includes Basis path testing and Control Structure testing (condition testing, data flow testing and loop testing). Black Box testing, on the other hand focuses on the functional requirements of the software. It enables a software engineer to derive a set of 53

input conditions that will fully exercise all functional requirements for a program. This approach is complementary to White Box testing and is likely to uncover a different class of errors than White Box method.

Black Box testing attempts to find errors in the following categories:  Incorrect or missing functions.  Interface errors.  Errors in Data Structures or external Database access.  Performance errors.  Initialization and termination errors. Unlike White Box testing, which is performed early in the testing process, Black Box testing tends to be applied during the later stages of testing. Attention in the black box testing is focused on the information.

54

Chapter 7: Design 7.1Use Case diagram for ATM The use case partition the functionality of a system into a small number of discrete units, and all system behavior must fall under some use case. Each use case should represent a kind of service that the system provides, something that provides value to the actor. A particular person may be both a bank teller and the customer of the same bank. For the ATM application, the actors are Customer and Bank. Following figure shows the use case diagram



Initiate Session: The ATM establishes the identity of the and makes available a list of s and actions. 55

• The ATM asks the to insert a card. • The inserts a cash card. • The ATM accepts the card and reads its serial number. • The ATM requests the . • The enters . • The ATM verifies the by ing the bank. • The ATM displays a menu of s and commands. • The choices the command to terminate the session. • The ATM asks the to insert the card. 

Query : The system provides general data for an such as the current balance, date of last transactions, and date for mailing last statement.

• The ATM displays a menu of s and commands. • The chooses to query an . • The ATM s the bank which returns the data. • The ATM displays data for . • The ATM displays a menu of s and commands.



Process Transaction: The ATM performs an action that affects an ’s balance, such as deposit, withdraw, and transfer. The ATM

56

ensures that all completed transactions are ultimately written to the bank’s database.

• The ATM displays a menu of s and commands. • The selects an withdrawal. • The ATM asks for the amount cash. • The enters the cash amount. • The ATM verifies that the withdrawal satisfy its policy limits. • The bank verifies that the has sufficient funds. • The ATM dispenses the cash and asks the to take it. • The takes the cash. • The ATM displays a menu of s and commands. • The ATM displays a menu of s and commands.



Transmit Data: The ATM uses the consortium’s facilities to communicate with appropriate bank computers.

• The ATM requests data from the consortium. 57

• The consortium accepts the requests and forwards it to the appropriate bank. • The bank receives the requests and retrieves the desired data. • The bank sends the data to the consortium. • The consortium routes the data to the ATM.

7.2 Architecture of the ATM system The ATM system is a hybrid of an interactive interface and a transaction management system. The entry stations are interactive interfacestheir purpose is to interact with a human to gather information needed to formulate a transactions. Specifying the entry stations consists of constructing a class model and a state model. The purpose is to maintain data and allow it to be updated over a distributed network under controlled transactions. Following fig. shows the architecture of the system.

58

The only permanent data stores are in the bank computers. A database ensures that data is consistent and available for concurrent access. The ATM systems process each transaction as a single batch operation, locking an until the transaction is complete. Concurrency arises because there are many ATM stations, each of which can be active at any time. There can be only one transaction per ATM station. The bank computer is the only unit with only unit with any nontrivial procedures, but even those are mostly just database updates. The only complexity might come from failure handling. The bank computers must have capacity to handle the expected worst-case load, and they must have enough disk storage all transactions. The system must contain operations for adding and deleting ATM stations and bank computers. Each physical unit must protect itself against the

59

failure or disconnection from the rest of the network. A database protects against loss of data. However, a special attention must be paid to failure during a transaction so that neither the nor the bank loses money – this may require a complicated acknowledgement protocol before committing the transaction. 7.3 Application State Model The application state model focuses on application classes and augments the domains state model. Application classes are more likely to have important temporal behavior than domain classes. First identify application classes with multiple states and use the interaction model to find events for these classes. Then organize permissible event sequence for each class with a state diagram. Next, check the state diagrams against the class and interaction models to ensure consistency. Following figure shows the ATM application class model.

60

7.4 ATM Simulation Transaction Interaction Diagram An interaction diagram is an analysis tool that can be used when an object interacts with various other objects to perform some task. One place this occurs in the ATM Simulation is during the execution of a transaction, when the transaction must interact with the Customer (via the ATM) to get specific information (such as choice of (s), amount), with the Bank, and with various components of the ATM (e.g. cash dispenser, printer). The diagram below is an interaction diagram for a Withdrawal Transaction.

61

7.4 Use Cases for ATM System 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.

62

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.

63

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. (s) involved, amount). The transaction

64

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

65

A withdrawal transaction asks the customer to choose a type of to withdraw from (e.g. checking) from a menu of possible s, 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 to deposit to (e.g. checking) from a menu of possible s, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to that the ATM can accept a deposit from this customer to this . 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 - 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

66

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 to transfer from (e.g. checking) from a menu of possible s, to choose a different 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 to inquire about from a menu of possible s. 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 to inquire about.

Invalid PIN Extension

67

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 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.

Chapter 8: Conclusion 8.1 Limitation of the Project:

The project currently possesses some limitations such as:

68

1. Software is restricted to work in a LAN. 2. If the server processor is slow then bottleneck problem on server occur. 3. Software works well in a LAN with star topology and in other topologies it is

restricted to some limited number of clients because of

a single link used.

8.2 Difficulties Encountered:



Once the keyboard & mouse locked, there is no way to unlock them except restarting the system.



Improper money checking can cause the possibility of a customer receiving counterfeit banknotes from an ATM.

8.3 Future Enhancement Suggestion: Although ATMs were originally developed as just cash dispensers, they have evolved to include many other bank-related functions. In some countries, especially those which benefit from a fully integrated cross-bank ATM network (e.g.: Multibanco in Portugal), ATMs include many functions which are not directly related to the management of one's own bank , such as: 

Deposit currency recognition, acceptance, and recycling



Paying routine bills, fees, and taxes (utilities, phone bills, social

security, legal fees, taxes, etc.) 

Printing bank statements



Updating books



Loading monetary value into stored value cards 69



Purchasing 

Postage stamps.



Lottery tickets



Train tickets



Concert tickets



Movie tickets



Shopping mall gift certificates

70

Chapter 9: Bibliography and References

9.1 Reference Books: 1. Java Complete Reference - Herbert Shildt 2. Java Network Programming – Oreilley Publications 3. Computer Network – Tanenbaum 4. Software Engineering – Roger S. Pressman 9.2 Other Documentations and resources:

1.

www.java.com

2.

www.sun.java.com

3.

www.sitepoint.com

4.

www.oreilley.com

5. www.wikipedia.com

71