The Design of the System

The Fixed Deposit Management System was designed as a web application. Following technologies will be used in the development of the system.

• php
• HTML
• CSS
• JavaScript
• XML

When designing the system several important decisions were taken. They are listed below.

1. The system was divided into three fundamental layers and each type of functionality was allocated in those separate layers. All the interfaces and interface driving logic was allocated to the “Presentation Tier”. Fundamental logical operations were placed in the “Logic Tier” and the database was placed in the “Data Tier”.

This is technically known as the three-tier architecture and is widely used in web applications.

2. System was to be designed as separate modules. And a base on which all of those modules can be put together. Each module needed to be as separate as possible with other modules. This was to enable the system to be developed and implemented in sections rather than to develop everything in one go. And also to ease future modifications.

3. It was seen that implementation would be much easier if an Object Oriented approach was used. The business process then could be easily simulated inside the computer. Additionally, by using object orientation code reusability and abstraction could be achieved.

4. It was decided to divide the system logically into two parts. These two parts were named as "System" and "Business" The "System" portion of the system comprised of fundamental functionality that was essential to the system. These included.

• User authentication
• Privilege granting for users
• Module handling
• Accessing resources beyond the system boundary
• Database connection handling
• File handling
• XML parsing

On the other hand the "Business" portion contained all the business logic that was needed in maintaining fixed deposits.

5. A minimum amount of business logic was to be allocated inside user interfaces. This gave the ability to completely change the user interface without changing the actual business logic.

The overall design of the Fixed Deposit Management System can be illustrated as follows.

The system comprised of modules and a base that connects all modules together.

Logic was distributed all over the system. This was to achieve distributed computing and to reduce the computational load of the server by doing so. The scattering around of logic all over the system was done adhering to several fundamental conditions.

They are as follows.

1. System and Business logic that are vital to the system was kept in the server

2. Validations and low priority operations were moved to the client side.

Adapters

Adapters are a collection of php classes. The objectives of these are to facilitate access to resources such as the Database, Files, XML documents and third party libraries that reside outside of the system boundary. All other logic classes in the system are given access to outside resources only through an adapter class. As an example a logic class needs to instantiate the adapter class that facilitate database operations in order to connect and run transactions in the DBMS.

Adapter classes facilitate abstraction, code reusability and ease of maintenance. Since these classes provide centralized access to a resource the system gains the distinct advantage of portability.

Common JavaScript Files

These files contain common operations shared by the system’s client side.

CSS

These are a set of Cascading Style Sheet (CSS) files. Their objective is to keep the styling data of the interfaces separate from interfaces themselves. This was done to avoid spending too much time designing user interfaces and also to gain the ability to change the appearance of these interfaces depending on user feedbacks.

Module

A Module accomplishes a unique task within the system. As an example the Client module handles insertion of new clients and updating and deletion of existing clients.

A single Module consists of four files. Two at server side (Logic and Link) and two at client side (Module specific JavaScript and HTML).

HTML Page

This is the user interface for the module

Module Specific JavaScript File

This file handles all of the user operations done on the HTML page. Allow the server side of the module to communicate with the client side and handles data transfer between the server and the client asynchronously. On top of all that this file takes on the job of modifying the interface according to response from the server.

Link File

Link file is a php script file that acts as the bridge between the client side JavaScript file and the server side logic file. Addition of this portion to a module was needed to overcome the heterogenic situation that arises when two different programming languages try to communicate with each other.

Logic File

The Logic file of the module is a php class. All of the vital module specific logic resides within this class.

XMLHTTPRequest

This is a JavaScript file that creates the XMLHTTPRequest object. This object is solely responsible for the asynchronous communication between the client and the server. This is more commonly known as a popular form of Ajax implementation.