07-12-2012, 05:55 PM
Project Report On OnLine Cab Service
OnLine Cab.doc (Size: 4.78 MB / Downloads: 132)
THEORETICAL BACKGROUND
The primary goal of this project to analysis the scope of project. So all of first it finds that application must be beneficial in metro cities. So in initial stage it is developed for selected metro cities.Thus all possibilities are mentioned such as Timing ,location and land mark to reach to customer.Basically project is not so huge ,due to reason it is not divided in modules.Simply user can register or can be a guest user.
SYSTEM ANALYSIS
Requirements analysis is a software engineering task that bridges the gap between system level requirements engineering and software design. Requirements engineering activities result in the specification of software’s operational characteristics (function, data and behavior), indicate software’s interface with other system elements, and establish constraints that software must meet. The most commonly used requirements technique is to conduct a meeting or interview. The first meeting between a software engineer (the analyst) and the customer can be likened to the awkwardness of a first date between two adolescents. Neither person knows what to say or ask; both are worried that they do say will be misinterpreted; both are thinking about where it might lead (both likely have radically different expectations here); both want to get the thing over with, but at the same time, both want it to be a success. Gause and Weinberg suggest that the analyst start by asking CONTEXT-FREE QUESTIONS. That is, a set of questions that will lead to a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired, and the effectiveness of the first encounter itself.
Design Pattern:
This software based on concept of the Model View Controller (MVC) design pattern.
View renders the data from the Model in response to the request made to the model by controlled events made by user interaction.
Model View Controller is a design approach to separate the application object model from GUI, originally invented around 80s. Then later on it has become a widely accepted common design pattern. The main objective behind this pattern is to decouple the view of the data (presentation layer) from the actual data processing so that the same model can be used for various views. This is achieved by using three different types of objects that interact with each other in loosely coupled manner with their discreet set of tasks.
VIEW:
View is the graphical data presentation (outputting) irrespective of the real data processing. View is the responsible for look and feel, some custom formatting, sorting etc. View is completely isolated from actual complex data operations. For example, Online product catalog view is completely separated from database connection, query, tables etc. It simply gets final row-data from the model and puts some cosmetics and formatting before displaying it in browser. View provides interface to interact with the system. The beauty of MVC approach is that it supports any kind of view, which is challenging in today’s distributed and multi-platform environment.
A MVC model can have multiple views, which are controlled by controller. View interface can be of WEB-FORMS, HTML, XML/XSLT, XTML, and WML or can be Windows forms etc.
MODEL:
Model is responsible for actual data processing, like database connection, querying database, implementing business rules etc. It feeds data to the view without worrying about the actual formatting and look and feel. Data provided by Model is display-neutral so it can be interfaced with as many views without code redundancy; this eases your code maintenance and reduces bugs and allows code -reuse at good extent. Model responds to the request made by controllers and notifies the registered views to update their display with new data.
CONTROLLER:
Controller is responsible for Notice of action. Controller responds to the mouse or keyboard input to command model and view to change. Controllers are associated with views. User interaction triggers the events to change the model, which in turn calls some methods of model to update its state to notify other registered views to refresh their display.