DOCUMENT OUTLINE: Introduction System Overview Design Considerations o Assumptions and Dependencies o General Constraints o Goals and Guidelines

nes o Development Methods Architectural Strategies o strategy-1 name or description o strategy-2 name or description o ... System Architecture o component-1 name or description o component-2 name or description o ... Policies and Tactics o policy/tactic-1 name or description o policy/tactic-2 name or description o ... Detailed System Design o module-1 name or description o module-2 name or description o ... Glossary Bibliography

1. INTRODUCTION
A renowned cab service provider NAM wants to improve the service offered to the customer by designing a database which will enable customers to book the cabs online. The database should also store complete info about drivers and customers who book the cab. There is a main booking office which stores the Driver SSN, Customer Id, Start time, End time, Destination, Pickup Point, Amount paid by customer. The booking office issues drivers where every driver has a unique SSN, Name, Address, complete details of its License and also info about availability which determines whether or not a driver is available for source. Every driver drives only a cab where every cab has a Reg No., Plate No., No of Seats, Initial meter reading at the start time, Final reading on completion of day, No. of hours worked and No. of km travelled per day. Every cab requires maintenance for satisfactory service to customers. Every maintenance has a Unique Service No., Cost for maintenance. Maintenance are of 2 types Daily and Quarterly. Every driver works for a particular amount of time, worked have to be recorded, Salary of driver is determined based on No. of hours.

2. SYSTEM OVERVIEW
The Cab Service came in Mumbai in 1960.With time the population of Mumbai has grown a lot and Mumbai is a Metro city now, but public transport is a very big problem. There are millions of people in Mumbai which travel daily through public transport. In order to provide a Cheap, Efficient and Customer friendly door to-door Cab Service JAN. We give the customer a facility to book a cab using our web application providing his/her respective details. The system is efficient enough to take customer inquiry, store the data of the customer on the Database, work on the inquiry by arranging a cab for Customer and then revert back to the Customer with respective details of the Cab and Cab driver.

3. DESIGN CONSIDERATIONS
Hardware Interface: (1) Server side (a) Processor : Pentium 4 with 3.0 GHz or higher (b) RAM : 1Gb or more (c) Hard disk : 100Gb or more (2) Client side (a) A Computer.

Software Interface (1) Server side (a) Database- Oracle 10g. (b) Windows 2008 Server. (2) Client side : (a) A Web Browser or any web enabled device with web browser in it.

Operating Environment (1) Java Platform, Enterprise Edition or Java EE is Oracle's enterprise java computing platform. The platform provides an API and runtime environment for developing and running enterprise software, including network and web services, and other large-scale, multi-tiered, scalable, reliable, and secure network

applications. Java EE extends the Java Platform, Standard Edition (Java SE)[1], providing an API for fault-tolerance, object-relational mapping, distributed and multi-tier architectures, and web services. CONSTRAINTS: 1. Not more than 3 passengers will be allowed. 2. One customer can book only 5 cabs at a time. 3. If there is a delay of more than 1 hour only then the booking amount will be returned. 4. All cabs in the city of Mumbai are non-smoking and the driver has a right to request the fare in advance. (City ordinance)

GOALS: The projects goal is we are so fast we can't help it. Our goal remains to be the best cab company in the Mumbai area and treat every customer with the same respect. Your call helps support our independent, hardworking drivers and owners. JAN cab thanks you for your ongoing business. The major issue related to unavailability of services regardless to cost or environment have been addressed with this project.

Architectural Strategies:
The client/server model is a computing model that acts as distributed application which partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients. Often clients and servers communicate over a computer network on separate hardware, but both client and server may reside in the same system. A server machine is a host that is running one or more server programs which share their resources with clients. A

client does not share any of its resources, but requests a server's content or service function. Clients therefore initiate communication sessions with servers which await incoming requests.

4. ARCHITECTURAL STRATEGIES

Following are the description of the each components of the architecture : 1. Cab Application : The GUI of the Cab Application consists of a form to be filled. In application, the main screen is built using multiple collaborating parts, each one addressing a specific aspect of a business process (for example, billing, claims, or customer information). All of these parts could potentially be developed by different teams. The parts may interact with different back-end systems and can be independently versioned, deployed, and updated. However, they are integrated to provide a consistent user experience, share information between each other, and communicate to help the end user complete a specific task. Shell developers are responsible for building the components that give this application its custom, yet consistent, appearance and behavior (look and feel). The Composite UI Application Block implements the underlying architecture that helps build these types of applications.

2. Finding and Loading Modules A key goal of the Composite UI Application Block is to support the development of applications through the use of independent, but collaborating, modules. This is achieved by:

An implementation of a catalog that specifies which modules to load. A module loader that actually loads and initializes the modules that comprise your application.

These implementations can be customized for your own needs without changing the provided core Composite UI Application Block implementation because all of the main subsystems work as plug-ins. For example, your application could obtain the list of modules to be loaded for a particular user of the application from a centrally managed Web service instead of reading them from a file. 3. Inherent Extensibility Internally, the design is based on concepts of services (components that provide an implementation of functionality) and containers (components that hold references to your objects containing business logic, controls, and services). The Composite UI Application Block's extensibility mechanism allows you to add and extend it with your own behaviors and services in the same way it implements its functionality.

CONNECTORS: Architectural element that models interactions among components and rules that govern those interactions are known as connectors. 1. Connectors as communicators a) Procedure call:

i) HTTP : The user submits its requests via the HTTP get method. On submission, the clients requested data reaches the server. The server then responses to the client by HTTP method about the submission.

ii) Data Access Connector: database connector (jdbc). It is used for connecting a software with database and extracting the information from the database that is required by the server. The Server database can be any software like Oracle, IBM DB2, Microsoft Access database, etc.

5. WEBLIOGRAPHY
[1] JOURNAL OF MULTIMEDIA, Reference paper - A Localized and Secure Method for Transferring Bank Information by SMS for Persian Banks, VOL. 3, NO. 1, MAY 2008 [2] Bank Islam of Malaysia. Retrieved from http://www.bankislam.com [3] Creativity in mobile banking Wit Software. Retrieved from http://www.witsoftware.com [4] Euronet Worldwide Mobile Banking Guide SMS Banking Services 234 [5] Seylan Bank. (n.d.). SMS Banking Users Guide.