ABSTRACT Internet banking offers large number of benefits for people involved in financial transactions.

There is no need to visit the bank every time you need to transfer money. You can do so by internet banking from the comfort of your home. With net banking facility, one can not only transfer money, but also pay bills, check bank statements, check account balance, request for check book and various other financial transactions. Online banking has become widely popular among the masses because of its wide array of benefits. All banks offer the online banking facility for their customers nowadays. Online banking has made the lives easier for people who are too busy to go to bank to conduct their financial transactions. Internet banking offers the flexibility to do financial transaction on any day irrespective of the time. In todays fast paced life, people are too much stressed out because of their work pressure and net banking offers them peace of mind as they can pay their bills, book their tickets, do online shopping, etc. Best part of net banking is that it is very easy to do any transaction over the net and highly secure website takes care of all your worries.

INDEX 1. Introduction 1.1 Scope 1.2 UML 1.3 Software Engineering activities 1.4 Rational Rose 2. Problem specification 2.1 Existing System 2.2 Proposed system 3. System Requirements 3.1 Functional Requirements 3.2 Non Functional Requirements 4. Analysis 4.1Introduction-to-analysis 4.2 Use case model 4.2.1 use case introduction 4.2.2 use case description 4.2.3 use case diagram 4.3 Interaction diagram

4.3.1 Introduction 4.3.2 Sequence diagram 4.3.3 collaboration diagram 4.4 State chart 4.4.1 Introduction 4.4.2 state chart diagram 4.5 Class diagram 4.5.1 Introduction 4.5.2 Class diagram 5. System design 5.1 Introduction 5.2 Component diagram 6. Implementation 6.1 Introduction to Activity diagram 6.2 Activity Diagram 7. Testing 8. Conclusion 9. Bibliography

1. INTRODUCTION Internet banking is a system of banking that enables customers to perform various financial transactions on a secured website via internet. In order to use online banking system customer must have an account in the bank. If the customer has an account he can register into online banking system. After registration new login id and password are sent to his/her email address. Then he can utilize all the services provided by online banking system.

1.1 SCOPE: The scope of this project is to provide a web based platform for all the registered customers to perform their financial transactions such as money transfer and also non financial transactions such as viewing of transaction history.

1.2 UML: Unified Modeling Language is the modeling language used for representing the models. The goal of UML is to provide a standard notation that can be used by all object oriented methods to select and to integrate the best elements of precursor notations. System development focuses on three different models. Functional model: It describes the functionality of the system in users point of view. The functionality will be expressed in terms of use cases and actors. This is nothing but the use case diagram. Object model: This model describes the system in terms of classes, objects, attributes, operations and relation among classes. The object model starts with analysis object model in analysis phase and it is transformed into system design object model in system design phase and finally refined into object design model in object design phase. This model is represented with class diagrams. Dynamic model: This describes the internal behavior of the system. This model is represented with interaction diagrams, state chart diagrams and activity diagrams.

1.2 SOFTWARE ENGINEERING ACTIVITIES: Software engineering activities deal with the complexity by constructing and validating models of the application domain model or the system. Engineering activities include Requirement Elicitation Analysis System Design Object Design Implementation Testing

Requirements Elicitation: During requirements elicitation, the client and developers define the purpose of the system. The result of this activity is a description of the s that interacts with the system. Use case diagram will be drawn here. Analysis: During analysis, developers aim to produce the model of the system that is correct, complete, consistent and unambiguous. The system will be modified from use cases into object model that completely describes the system. Class diagram, Object diagram, Interaction diagrams such as

sequence diagram and collaboration diagram, State chart diagram will be drawn in this phase. System Design: During the system design goals of the project and decompose the system into smaller subsystems that can be realized by the individual teams. This also involves strategy selection which includes access control policy, data flow policy, data management, hardware configuration, software configuration. Component diagram will be drawn here. Object Design: During object design, developers define solution domain objects to bridge the gap between the analysis model and the hardware/software platform defined during the system design. The result of the object design activity is a detailed object model annotated with constraints and precise descriptions for each element. Implementation: During implementation, developers translate the solution domain model into source code. This includes implementing the attributes and methods of each object integrating all the objects such that they function as a single system.

Testing: During testing developers find the difference between the system and it models by executing the system with sample input data sets. During unit testing, developers compare the object design model with each object and subsystem. During integration testing, combinations of subsystems are integrated together and compared with the system design model. During system testing, typical and exception cases are run through the system and compared with the requirements model. The goal of testing is to discover as many faults as possible such that they can be repaired before the delivery of the system. 1.3 Rational Rose: The Rational Rose section of the rose.ini file contains startup settings for the application. The application reads and writes to this file upon opening and closing the application. Most settings in the rational rose will be altered when you change the options through the GUI. The only way you can change some settings is directly in the rose.ini file. Rational Rose automatically allows you to integrate other applications with Rational Rose in two ways. Using Rational Rose as an automatic controller, you can call an OLE automation object from within a Rational Rose

script. Using Rational Rose software as an automatic server, you Rational Rose automatic is accessible to automation controller environments such as visual basic, EXCEL, Summit Basic Script, C, C++ and others. 2. PROBLEM SPECIFICATION 2.1 EXISTING SYSTEM: The existing system is the manual banking system and ATM system. The existing systems have the following drawbacks: 1. Customer has to go the bank or ATM to do the transactions. 2. At the banks and ATMs there is big queue of waiting customers. 3. It is the more time consuming process.

2.2 PROPOSED SYSTEM: In this system I proposed to perform financial transactions such as money transfer, apply for cheque book, fixed deposit, etc through internet. The customer can have the following features:

1. The customer can do the transactions in internet at his presence. 2. It is more time saving process and there is no waiting in queue. 3. The customer can do his transactions from any place. 4. The customer can do his transactions at any time 24*7.

3. SYSTEM REQUIREMENTS 3.1 FUNCTIONAL REQUIREMENTS Functional requirements describe the interaction between the system and its environment independent of its implementation. 1. The customer must have a valid user id and password to login to the system. 2. When an invalid password is entered, a warning is given to the user that his account is going to be blocked. 3. Customer can change the password after first login. 4. Customer can transfer money from his account to any other account with this bank. 5. Customer can request his cheque book, change of address, stop payment of cheques.

6. Customer can apply for loan, fixed deposits. 7. Customer can view his all his previous transactions. 8. Customers can complaint to the bank regarding inconvenience in any of his transactions. NON FUNCTIONAL REQUIREMENTS: Usability: Is the ease with which the user can learn to operate, prepare inputs for and interpret outputs of a system or component. Usability requirements include convention adapted by the user interface, the scope of online help and the level of user documentation. Reliability: It is ability of system or component to perform its required functions under stated conditions for a specific period of time. Reliability requirements include an acceptable mean time to failure and ability to detect specified faults or to withstand specified security attacks. Supportability: Requirements are concerned with the ease of changes to the system after deployment, this requirement include adaptability, maintainability and internationalization.

Secure access of confidential data 24/7 availability

Better component design to get better performance at peak time. Flexible service based architecture will be highly desirable for future extension. 4. ANALYSIS 4.1Introduction to analysis: During analysis, developers aim to produce the model of the system that is correct, complete, consistent and unambiguous. The system will be modified from use cases into object model that completely describes the system. Class diagram, Object diagram, Interaction diagrams such as sequence diagram and collaboration diagram, State chart diagram will be drawn in this phase. 4.2 Use Case Model 4.2.1 Introduction: A use case diagram shows a set of use cases and actors (a role of a class) and their relationships. Use case diagrams address the static use case view of a system. These diagrams are especially important in organizing and modeling the behaviors of a system. 4.2.2 Use Case Description: A use case diagram commonly contain - Use cases

- Actors - Dependency, generalization and association relationships. ACTOR: Actors represent system users. An actor is one who interacts with system and utilizes services provided by the system. An actor may be a person or an external system or an organization.

Actor

USECASE: A use case represents a goal that an actor wants to achieve by interacting with our system. A use case represents sequence of events performed to achieve a task.

UseCase

RELATIONSHIP:

Relationships tie things together. Relationships from actor to use case and between use cases are possible. Relationship from use case to actor is not possible. Relationships are two types. Association Relationship Dependency Relationship Association Relationship: The relationship from actor to use case is called Association Relationship. It can be represented by straight line. It is a unidirectional.

Dependency Relationship: The relationship between two use cases is called Dependency Relationship. It can be represented by dotted line. It is also unidirectional. ---------------> There are 5 dependency relationships; Include Uses Extends Inheritance Implementation

Includes:- Includes relationship used when there is a continuous flow between two use cases. Uses:- Uses relationship is used when one use case uses another use case for its completion. Extends:- Extends relationship is used in exceptional cases. A Use case diagram may also contain packages, which are used to group elements of your model into larger chunks. Use case diagram is used in one of two ways. 1. To model the context of a system. 2. To model the requirements of a system. Modeling Techniques: Identify the actors that surround the system by considering which groups require help from the system to perform their tasks; which groups are needed to execute the systems functions, which groups interact with external hardware or other software systems; and which groups perform secondary functions for administration and maintenance. Organize actors that are similar to one another in a generalization/specialization hierarchy where it aids understandability; provide a stereotype for each such actor. Populate a use case diagram with these actors and specify the paths of communication from each other to the systems use cases.

4.2.3 Use Case Diagram:

Registration
<<includes>> <<uses>>

login

Validation

Change of password

Apply for cheque book

User

Online payments

<<uses>>

Fund transfer verify

Bank Administrator

Account details and transactions

apply for fixed deposit

<<uses>>

Verification Apply for loan

Close the account

Complaints

logout

Actors

Customer

Administrator

Entry Condition Exit Condition

Customer Bank Officer Administrator -Customer enters to the bank site and login. -He chooses the services provided by the bank. -Enter the details asked by the service. -Do the transactions online. -Administrator provides the security to the customers. -He updates the new technologies and services provided by the bank. -He restricts some permits to the customers. -He must solve the online transaction problems. User opens homepage and login to the system After successfully completing the transactions the user click on the logout to exit from services.

USECASE DESCRIPTION FOR FUND TRANSFER: Customer Customer can transfer the money from his account to another account in the bank. Customer can enter by clicking on the money service and enter the details. Customer exits after getting acknowledgement statement.

Entry Condition

Exit Condition

USECASE DESCRIPTION FOR FIXED DEPOSIT: Customer Entry Condition Customer can create fixed deposits by using this service. Customer can enter by clicking on create fixed deposit service, enter the details. Customer exits after getting acknowledgement statement.

Exit Condition

USECASE DESCRIPTION FOR REQUEST OF CHEQUE BOOK: Customer Customer can request for a cheque book by using this service. Customer can enter by clicking on a request to cheque book service, enter the details. Customer exits after getting acknowledgement statement.

Entry Condition

Exit Condition

USECASE DESCRIPTION FOR APPLY OF LOAN: Customer Entry Condition Customer can apply for loan by using this service Customer can enter by clicking on apply for loan service,enter the details. Customer exits after getting acknowledgement statement.

Exit Condition

4.3 INTERACTION DIAGRAMS: 4.3.1 Introduction: Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams. Sequence diagrams and collaboration diagrams are kinds of interaction diagrams. Sequence Diagrams: It displays interaction between objects that focus on the message from a temporal stand point .The sequence diagram representation focuses on expressing interaction. An object is represented by a rectangle and its life line is represented by a vertical bar and dashed line. Sequence diagram show interaction between objects in a system and also specify the sequence in which those interactions happen and add the dimension of time to your diagram. In sequence diagram we only talk about time and ordering but not about the duration of time. In sequence diagrams objects are sometimes referred to as participants.

SEQUENCE DIAGRAM FOR FIXED DEPOSIT:

:user :display 1: logged 2: menu :control :amount details

:fixed deposit

:fixed deposit caculator

4: amount entered

5: accept 6: verify amount 7: ok

8: success

9: entered 10: for caculating interests 11: calculations 12: success 13: displays calculations' 14: commit 15: for giving fixed deposit acc. no 16: generates

17: success 18: display new acc. no

19: logout

SEQUENCE DIAGRAM FOR FUND TRANSFER:

:user :display :control :admin :registered in customer log

1: login

2: accept 3: verify 4: OK

6: menu

5: success

7: select fund transfer

8: enter receiver acc. no

9: account no. entered

10: accept

11: verify

13: ok 14: enter amount

12: ok

15: amount entered

16: accept 18: ok

17: verify

19: ok 20: amount transfered

21: logout

SEQUENCE DIAGRAM FOR PASSWORD CHANGE:

:user

:display 1: login

:control

:admin

2: accept 4: ok 3: verty

6: menu

5: succes

7: select change password 8: enter older,new and confirm password

9: entered

10: accept 11: verify old password, validate new password 12: ok

13: 14: password changed success

15: logout

COLLABORATION DIAGRAMS: It represents collaboration diagram objects. It is nothing but a set of objects related in a particular content and interaction. In this diagram numbering the message indicates the sequence. Collaboration diagram show exactly the same information the sequence diagram shows. But the purpose of collaboration diagrams is different. The collaboration diagram shows the objects and actor interaction without reference to

time. Quality assurance engineers and system architects view at these diagrams to see the distribution of processing between object. For example, in a collaboration diagram several objects communicate with central object. A system architect then concludes that the system is too dependent on central object and redesigns the objects to distribute the processing more evenly. We get the collaboration diagram by pressing F5 after the sequence diagram. COLLABORATION DIAGRAM FOR FIXED DEPOSIT:

13: displays calculations' 18: display new acc. no 1: logged 4: amount entered 9: entered 14: commit 19: logout

:user 3: apply for fixed deposit 8: success 20: enter tenure 2: menu

:control

:display

15: for giving fixed deposit acc.10: for caculating interests no 7: ok 5: accept 6: verify amount 17: success 12: success 16: generates 11: calculations

:amount details

:fixed deposit

:fixed deposit caculator

COLLOBARATION DIAGRAM FOR FUND TRANSFER:

3: verify 17: verify

:display

:admin 2: accept 16: accept

7: select fund transfer 6: menu 8: enter receiver acc. no 14: enter amount 20: amount transfered

5: success 13: ok 19: ok :control

4: OK 18: ok

10: accept 12: ok

11: verify

1: login 9: account no. entered 15: amount entered 21: logout :user

:registered in customer log

COLLOBARATION DIAGRAM FOR PASSWORD CHANGE:

9: select change password 2: menu :user 10: password changed :display

1: logged 3: passwords entered 8: logout

7: success 5: verify and validate

4: accepts :control 6: ok

:admin

4. STATECHART DIAGRAM 4.4.1 Introduction: A state chart diagram shows state machines, emphasizing the flow of control from state to state. A state machine is a behavior that specifies the sequences of states object goes through during its lifetime in response to events, together with its response to that response, to those events. A

state is a condition or situation in the life of an object during which it satisfies some condition, performs some activity or waits for some event. State chart diagram commonly contain: - Simple states and composite states - Transitions, including events and actions State chart diagram is used only one way. - To model reactive objects. Common Modeling Techniques: 1. Choose the content for the state machine, whether it is a class, a use case, or the system as a whole. 2. Choose the initial and final states for the object. To guide the rest of your model, possibly state the pre and post conditions of the initial and final states respectively. 3. Decide on the stable states of the object by considering the conditions in which the object may exist for some identifiable period of time. 4. Decide on the meaningful partial ordering of stable states over the lifetime of the object. 5. Decide on the events that may trigger a transaction from state to state. 6. Attach actions to these transitions and \ or to those states. 7. Consider ways to simplify your machine by using sub states, branches, forks, joins and history states. 8. Check that all states are reachable under some combination of events. 9. Check that no state is a dead end from which no combination of events will transition the object out of

that state.

homepag e login

main menu

enter receiver acc. no

show receiver details

enter amount to be transferred

successfully transferred

4.5 CLASS DIAGRAM 4.5.1 Introduction: A class diagram shows a set of classes, interfaces, and collaborations and their relationships. The diagrams are most common diagrams founding modeling object-oriented systems Class diagram represents class name, attribute and method. It shares the same attributes, operations, relations and semantics. Class it is description of a set of objects.

Attribute it represents the property of a class. Methods performing operations on date. A class is something that provides blueprint for an object In other words class defines what information and object can hold and the operations that can be performed on the attributes of the objects of class

Class diagram representation: Class name Attributes operations

A class is a set of objects that share a common structure and common behavior (the same attributes, operations, relationships and semantics). A class is an abstraction of realworld items. When these items exist in the real world, they are instances of the class and are referred to as objects. MULTIPTLICITY: The Cardinality field specifies the number of expected instances of the class. You can set a specific cardinality value for the client class, supplier class, or both. In the case of relationships, this field indicates the number of links between each instance of the client class and the instances of the supplier class.

Use the following syntax to express cardinality: Value N (default) 1 0..n 1..n 0..1 <Literal>* <Literal>..N <Literal>..<Literal> Description Unlimited number of instances One instance only Zero or more instances one or more instances Zero or one instance Exact number of instances Exact number or more instances Specified range of instances

<Literal>..<Literal>, <literal> the number of instances will be in the specified range or an exact number of instances <Literal>..<Literal>, the number of instances will be in

one of the specified ranges <Literal>..<Literal> * Where <literal> is any integer greater than or equal to one. You can set or display cardinality through the specification or from

CLASS DIAGRAM FOR INTERNET BANKING:

5. SYSTEM DESIGN: 5.1 Introduction: System design consists of 1. Design goals: The design goals can be identified by the following criteria Performance criteria such as response time, throughput and memory. Dependability criteria 1. Reliability 2. Security 3. Robust 4. Availability End user criteria This can be done in three levels 1. By giving commands 2. By giving inputs 3. By using more user friendly atmosphere Cost criteria This is the total cost that is spend on the resources including man power, time and everything used in the achievement of design goals of the project.

 Maintenance criteria The first three criteria are related with the client where as the remaining are related to those who are developing the project. 2. Decomposing the system into many sub systems. Each use case is a sub system and the sub system will be encapsulated by an interface. The coding for this interface will be present in faade design pattern. 3. Strategies: Identifying hardware and software configuration used for the project. Access policy Global control flow Boundary conditions 5.2 COMPONENT DIAGRAM Component diagram show a physical view of your model. A component diagram shows you the components in your system and the relationships between them. This high level physical component may or may not be equivalent to the many smaller components you use in creation of application. Component diagrams provide a physical view of the current model. A component diagram shows the organizations and dependencies among software components, including source code

components, binary code components, and executable components. These diagrams also show the externally-visible behavior of the components by displaying the interfaces of the components. Calling dependencies among components are shown as dependency relationships between components and Component diagrams provide a physical view of the current model. A component diagram shows the organizations and dependencies among software components, including source code components, binary code components, and executable components. These diagrams also show the externally-visible behavior of the components by displaying the interfaces of the components.

Calling dependencies among components are shown as dependency relationships between components and interfaces on other components. Note that the interfaces actually belong to the logical view, but they can occur both in class diagrams and in component diagrams.

Component diagrams contain: Component packages Components Interfaces Dependency relationships

COMPONENT PACKAGE: Definition: Component packages represent clusters of logically related components, or major pieces of your system. Component packages parallel the role played by logical packages for class diagrams. They allow you to partition the physical model of the system. Naming: Typically, a component package name is the name of a file system directory. Relationships: A component package can have dependencies with other component packages, components, and interfaces. Graphical Depiction: The component package is a folder shaped icon:

COMPONENT DIAGRAM FOR INTERNET BANKING:

login,registration and password change

apply for cheque book and loans

fund transfer and DD issue

Fixed deposit

close account and complaints

6.4 DEPLOYMENT DIAGRAM 6.4.1 Introduction: A deployment diagram shows the configuration of run-time processing nodes and the components that live on them. Deployment diagrams address the static deployment view of architecture. A node typically hosts one or more artifacts. We can use import and

generalization relationships between packages. Graphically a deployment diagram is a collection of vertices and arcs. Deployment diagram commonly contains: - Nodes - Dependency and association in one of 3 ways 1. To model Embedded System. 2. To model Client\server System 3. To model fully distributed system

DEPLOYMENT DIAGRAM:

admin database

user

gateway

Printer

fixed deposit database

6. IMPLEMENTATION 6.1 Introduction: During implementation, developers translate the solution domain model into source code. This includes implementing the attributes and methods of each object integrating all the objects such that they function as a single system 6.2 Activity Description: An Activity diagram shows the flow from activity to activity .An activity is a ongoing non-atomic execution within a state machine. An activity results in some action, results in a change of state or return of a value. Action encompasses calling operation, sending a signal, creating or destroying objects, or a pure computation such as evaluating some expression.

Activity diagram commonly contains 1. Activity states and action states 2. Transitions 3. Objects, it may contains nodes and constraints. Activity states and action states: An executable atomic computation is called action state, which cannot be decomposed. They rendered as lozenge shape. Activity state is non atomic, decomposable and take some duration to execute. Transition: It is the path from one state to the next state, represented as simple directed line.

Branching: When alternate paths exist, branching arises which is represented by open diamond. It has one incoming transition, two or more outgoing transitions. Forking and joining: The Synchronization bar, when splits one flow into two or more flows is called Fork. When two or more flows are combined at synchronization bar, the bar is called Join. Swim lanes: Grouped work flow is called swing lane. All groups are

portioned by vertical solid lines. Each swim lane specifies locus of activities and has a unique name. Each swim lane is implemented by one or more classes. Transition may occur between objects across swim lanes.

ACTIVITY DIAGRAM FOR INTERNET BANKING:

website homepage

Registrati on

Login

Relogin

No id,password

MENU

change password enter old password fails

Fund transfer enter receiver acc no fails ok show receiver details enter amount to be transfered

Fixed deposit enter amount

DD

apply for cheque book

Complaints loans close account

enter receiver details

enter account details

fails

enter new password,conform

ok enter tenure

enters amount fails yes

submits

enter password validates fails show details required to apply loan enter reason for closing enter tenure select loan type show interest submit

enter complaint

submit

fails yes

calculate interest and final amount commit

deliver DD to receiver

fails password changed ok Successfully transferef

generates fixed deposit acc. no

END

6.4 DEPLOYMENT DIAGRAM

6.4.1 Introduction: A deployment diagram shows the configuration of run-time processing nodes and the components that live on them. Deployment diagrams address the static deployment view of architecture. A node typically hosts one or more artifacts. We can use import and generalization relationships between packages. Graphically a deployment diagram is a collection of vertices and arcs. Deployment diagram commonly contains: - Nodes - Dependency and association in one of 3 ways 4. To model Embedded System. 5. To model Client\server System 6. To model fully distributed system

DEPLOYMENT DIAGRAM:

admin database

user

gateway

Printer

fixed deposit database

7. TESTING 7.1 Introduction: Testing is the process to find any deviation from the expected working of the system. If there is no deviation from the expected behavior of the system then the project is successful otherwise failure. Testing cant be done in a full-fledged manner because of the time and budget constraints. 7.2Black box and white box testing: Black box testing: This tests the inputs and the corresponding outputs.

White box testing: The code where exactly the fault occurs can be identified by this means of testing. 7.3Unit Testing: Unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual function or procedure. Unit tests are created by programmers or occasionally by white box testers 7.4 Integration Testing: Integration testing is the activity of finding faults when testing the individual components together. Structural testing is the culmination of integration testing involving all the components of the system.

7.5 System testing:

System testing tests all the components together, seen as a single system to identify faults with respect to scenarios from the problem statement and the requirements and design goals identified in the analysis and system design. CONCLUSION: The purpose of the technology is to make man free from the burden. In Internet banking, the customer convenience factor rates are high. In addition to checking balances and transactions, one can catch discrepancies in the account right way and deal with them swiftly. The best part is that this can be done anywhere! As long as one has internet access, one can practice online banking. Since bills are paid online, the necessity of writing checks, affixing postage and posting the payment in the mail is eliminated. While there is usually a free for online banking, it can be extremely low. Online banking also eliminates paper waste, which is a plus not only for those who have to handle all the paper work, but also for the environment, there are also cons. The convenience of online banking is a perk well worth the cost. What could you rather do, stand in a long

line on a weekend morning or handle your transactions in the comfort of your own home?

9. REFERENCES Professional Java Server Programming Object Oriented Development-Ali Bahrami Fundamental of Database Systems-Elmasri and Navathe Object Oriented Software Engineering by Allen H.Dutoit & Bernd Bruegge.