08-10-2016, 11:09 AM
[attachment=72717]
1. INTRODUCTION
Objective
The main objective of this 4 week project is to develop a client/server model, which deals with “Online Restaurant Meal Reservation System”. The system has two parts first for the customers and the other for the management side.
The customer side allows the customer to view menu list according to the time of delivery he desires and reserve meal for that specific time, and at the management side the staff is allowed to edit information regarding menu list, price, assigning cook, maintain information regarding the orders placed, etc.
Scope
We are greatly constrained by “Time limitations” as only 4 weeks are given to complete the project. So we limited our scope of project to “Meal Reservation” only.
The sole purpose of the project is to learn the web application development in Java, how databases works for the web application and how to co-ordinate Java with databases to produce more commercial web applications for daily business.
We will try our best to make better usage of java (servlets, jsp), MySql and surely all in a better team work.
2. PROBLEM STATEMENT
2.1 Problem Area
Restaurant is a kind of business that serves people all over world with ready made food. Currently this industry is going on with lot of flare. People feel more comfortable with lot of variations in the selection and consumption of their food in their busy life.
One can see lot more restaurant in the world. Even in Denmark one can see thousands of restaurants with dishes from all over the world like from India, Pakistan, Mexican, etc fulfilling the needs of people with nourishments and enjoyments.
Let’s concentrate on booking area in a restaurant. In traditional booking system, a customer has to make a phone call in order to get his meal reserved. If luckily the phone gets connected, then the customer does some formal conversation like hello, hi, etc. Than he demands for today’s menu and do some discussion over menu items then he orders and he has to give some of this identification specifications. This process takes 5-8 minutes to complete. On the receiver side there is hardly one phone line and one operator. So he can cover around 15-20 orders maximum in an hour.
For each booking he has to register manually on paper and puts the order in a queue with specific priority according to time and quantity, and than a cook is assigned for the specific order to complete it.
There are lots of areas to be solved for current restaurants using modern IT World. Many areas come like human resource management, accounts management, etc. But our problem lies within domain of end customer and restaurant “Meal Reservation”.
2.2 Problem Analysis
As discussed earlier our main problem area focuses on the “Meal reservation/booking system”, there are lot of problems in that area which are associated with both the customer and the restaurant staff.
We would like to analyze some of the problems here:
a. Initial problem is that the customer has to get connected over the phone, it would be harder if the restaurant is very popular and busy.
b. As customer won’t have the menu list with him, it would be harder for him to remember the entire list (with price as well...!) and come to a decision, i.e. customer is provided with less time to make decision.
c. The chances of committing mistakes at the restaurant side in providing a menu list for a specific time would be more.
d. There might be some communication problems or sometimes language might be a barrier.
e. As entire booking has to be done manually at the restaurant end, the chances of occurrence of mistakes is high as well.
f. Most of restaurants have single phone line and a single operator to handle incoming calls, so they can accept limited orders.
g. If the restaurant is of busy type, than the operator is left with no time to decide over the priority of the order fulfillment.
h. Even assigning orders (or some menu from the order) to a specific cook can be cumbersome if it is done parallel with the bookings of the order.
i. All the calls will not by intended for booking, as some calls might be for canceling the order or to fetch the status as well, this eats up the productive time at the restaurant side.
Still there might be many other problems associated with the traditional system of booking through telephone. So what should be the solution for these problems..?
2.3 Solutions for the Problems (How to solve this!!!!)
The solution for the above problems, so far we have thought, is client-server system that listen the requests online. We have the intensions to make the system that takes the customer reservations through the browser.
To resister a meal online, the customer has to become a member first then he can access the later part of the site. The option of becoming member was only an attempt to avoid (to some extent) placing the fake bookings.
During login the user as to enter his emailed/UserID, password and desired time of order delivery. After successful login the customer can access the menu page with the items listed according to the desired time. Later within the available items he can search for a menu according to his choice i.e. according to price range and category of food and later he can order a meal.
If the customer later wants to cancel the order, he is permitted to do this only within a specific time period. The customer is also given with the facility to view the status of the order and if the order is ready then he can go and get it.
At Management side, initially the staff member has to login, and according to his designation the privileges are set. If the staff member is a cook, then he is allowed to edit only the order items status, indicating which menu items he has prepared.
If suppose the member is an administrator then, he is allowed to reassign the cook according to his priority, he can edit the menu information such as its price, items available currently, etc. He can also change the status of the order (in some special cases), and can also block (if any customer exists)/Edit any customer’s order according to his priority
Client/server describes the relationship between two computer programs in which one program, the client, makes a service request from another program, the server, which fulfils the request.. In a network, the client/server model provides a convenient way to interconnect programs that are distributed efficiently across different locations. Computer transactions using the client/server model are very common.
Some of the characteristics of Client/Server Architecture
Asymmetrical protocols—there is a many-to-one relationship between clients and a server. Clients always initiate a dialog by requesting a service. Servers wait passively for requests from clients.
Encapsulation of services—the server is a specialist: when given a message requesting a service, it determines how to get the job done. Servers can be upgraded without affecting clients as long as the published message interface used by both is unchanged.
Integrity—the code and data for a server are centrally maintained, which results in cheaper maintenance and the protection of shared data integrity. At the same time, clients remain personal and independent.
Location transparency—the server is a process that can reside on the same machine as a client or on a different machine across a network. Client/server software usually hides the location of a server from clients by redirecting service requests. A program can be a client, a server, or both.
Message-based exchanges—clients and servers are loosely-coupled processes that can exchange service requests and replies using messages.
Modular, extensible design—the modular design of a client/server application enables that application to be fault-tolerant. In a fault-tolerant system, failures may occur without causing a shutdown of the entire application. In a fault-tolerant client/server application, one or more servers may fail without stopping the whole system as long as the services offered on the failed servers are available on servers that are still active. Another advantage of modularity is that a client/server application can respond automatically to increasing or decreasing system loads by adding or shutting down one or more services or servers.
Platform independence—the ideal client/server software is independent of hardware or operating system platforms, allowing you to mix client and server platforms. Clients and servers can be deployed on different hardware using different operating systems, optimizing the type of work each performs.
Reusable code—service programs can be used on multiple servers.
Scalability—client/server systems can be scaled horizontally or vertically. Horizontal scaling means adding or removing client workstations with only a slight performance impact. Vertical scaling means migrating to a larger and faster server machine or adding server machines.
Separation of Client/Server Functionality—client/server is a relationship between processes running on the same or separate machines. A server process is a provider of services. A client is a consumer of services. Client/server provides a clean separation of functions.
Shared resources—one server can provide services for many clients at the same time, and regulate their access to shared resources.
Servlets are loaded and executed by a web server. A servlet accepts requests from a client (via the web server), performs some task, and returns the results.
A servlet has to perform follows tasks:
• Read Explicit data (form data) and implicit data (Request headers) sent by the client.
• Generate the results.
• Send explicit data back to client (in HTML format).
• Send implicit data back to client (status code and the response headers).
JSP (Java Server Page)
Java Server Pages (JSP) technology enables us to mix regular, static HTML
with dynamically generated content from servlets. Java Server Pages (JSP) technology offers a simple way to create dynamic web pages that are both platform-independent and server-independent, giving you more freedom through Java technology's "Write Once, Run Anywhere" capability.
JSP technology separates content generation from presentation and takes advantage of reusable tags and objects, simplifying the maintenance of your web applications.
It may seem that servlets and JSPs are mutually exclusive, but in fact they work well together. You can reduce the amount of Java coding in your JSP by passing control from a servlet to a JSP.
The approach used by us is a hybrid approach for serving dynamic content, since it combines the use of both servlets and JSP. It takes advantage of the predominant strengths of both technologies, using JSP to generate the presentation layer and servlets to perform process-intensive tasks. Here, the servlet acts as the controller and is in charge of the request processing and the creation of any objects used by the JSP, as well as deciding, depending on the user's actions, which JSP page to forward the request to. Interestingly in particular there is no processing logic within the JSP page itself!! it is simply responsible for retrieving any objects that may have been previously created by the servlet, and extracting the dynamic content from that servlet for insertion within static templates. In our opinion, this approach typically results in the cleanest separation of presentation from content.
SOFTWARE REQUIREMENT SPECIFICATIONS
3.1 Functional Specifications
3.1.1 Customer Specifications:
a. Search Menu according to the time of order delivery:
During login, the costumer has to enter the time of delivery, and the menu items will appear accordingly. As availability of items differ from time to time.
b. Allow to search menu according to price and category:
Customers can search menu according to price range and the category as well, this functionality will be working as a search under search, i.e. first search criteria will be time of order delivery (which is default for all cases) and the later will be search within those menus according to price and category.
c. Allow to book/cancel order:
Allowing customer to place an order or allowing him to cancel the placed booking.
d. Allow the customer to edit/create his personal account (membership):
Here customer can create his new account or he can edit his personal
information from the existing account.
e. Allow customer an option to change his password:
Customers are given with a facility to change his existing password.
3.1.2 Management Specifications:
a. Edit Menu records:
A manager can edit/create some or whole part of the menu record on daily basis. That is by changing the menu items, prices, description, etc.
b. Reassign Cook:
A manager can reassign the cook for a specific order or an item, originally the system assigns the cook automatically when an item is booked using some distribution fashion i.e. round robin fashion.
So a member can reassign the cook if such situation arrives.
c. Cancellation the order:
A manager can cancel of the order, this situation comes when the something goes wrong with working or in some unusual situations.
d. Create/Edit Cook’s list:
A manager can create a new entry of cook or edit the existing cook’s information from the cook’s list.
e. Blocking specific customer:
A manager can block a particular customer before signing up. This happens when the customer’s previous history is bad, i.e. if he does not come up to take his orders which were ordered previously.
e. Allotting some privileges to cook:
As previously stated a manager can create a cook, along with creation of a new cook he is given some privileges. The privileges include editing the status of the order, i.e. he can enter the status as ready if he has completed that item or can state the order is in process before preparing that item.
1. INTRODUCTION
Objective
The main objective of this 4 week project is to develop a client/server model, which deals with “Online Restaurant Meal Reservation System”. The system has two parts first for the customers and the other for the management side.
The customer side allows the customer to view menu list according to the time of delivery he desires and reserve meal for that specific time, and at the management side the staff is allowed to edit information regarding menu list, price, assigning cook, maintain information regarding the orders placed, etc.
Scope
We are greatly constrained by “Time limitations” as only 4 weeks are given to complete the project. So we limited our scope of project to “Meal Reservation” only.
The sole purpose of the project is to learn the web application development in Java, how databases works for the web application and how to co-ordinate Java with databases to produce more commercial web applications for daily business.
We will try our best to make better usage of java (servlets, jsp), MySql and surely all in a better team work.
2. PROBLEM STATEMENT
2.1 Problem Area
Restaurant is a kind of business that serves people all over world with ready made food. Currently this industry is going on with lot of flare. People feel more comfortable with lot of variations in the selection and consumption of their food in their busy life.
One can see lot more restaurant in the world. Even in Denmark one can see thousands of restaurants with dishes from all over the world like from India, Pakistan, Mexican, etc fulfilling the needs of people with nourishments and enjoyments.
Let’s concentrate on booking area in a restaurant. In traditional booking system, a customer has to make a phone call in order to get his meal reserved. If luckily the phone gets connected, then the customer does some formal conversation like hello, hi, etc. Than he demands for today’s menu and do some discussion over menu items then he orders and he has to give some of this identification specifications. This process takes 5-8 minutes to complete. On the receiver side there is hardly one phone line and one operator. So he can cover around 15-20 orders maximum in an hour.
For each booking he has to register manually on paper and puts the order in a queue with specific priority according to time and quantity, and than a cook is assigned for the specific order to complete it.
There are lots of areas to be solved for current restaurants using modern IT World. Many areas come like human resource management, accounts management, etc. But our problem lies within domain of end customer and restaurant “Meal Reservation”.
2.2 Problem Analysis
As discussed earlier our main problem area focuses on the “Meal reservation/booking system”, there are lot of problems in that area which are associated with both the customer and the restaurant staff.
We would like to analyze some of the problems here:
a. Initial problem is that the customer has to get connected over the phone, it would be harder if the restaurant is very popular and busy.
b. As customer won’t have the menu list with him, it would be harder for him to remember the entire list (with price as well...!) and come to a decision, i.e. customer is provided with less time to make decision.
c. The chances of committing mistakes at the restaurant side in providing a menu list for a specific time would be more.
d. There might be some communication problems or sometimes language might be a barrier.
e. As entire booking has to be done manually at the restaurant end, the chances of occurrence of mistakes is high as well.
f. Most of restaurants have single phone line and a single operator to handle incoming calls, so they can accept limited orders.
g. If the restaurant is of busy type, than the operator is left with no time to decide over the priority of the order fulfillment.
h. Even assigning orders (or some menu from the order) to a specific cook can be cumbersome if it is done parallel with the bookings of the order.
i. All the calls will not by intended for booking, as some calls might be for canceling the order or to fetch the status as well, this eats up the productive time at the restaurant side.
Still there might be many other problems associated with the traditional system of booking through telephone. So what should be the solution for these problems..?
2.3 Solutions for the Problems (How to solve this!!!!)
The solution for the above problems, so far we have thought, is client-server system that listen the requests online. We have the intensions to make the system that takes the customer reservations through the browser.
To resister a meal online, the customer has to become a member first then he can access the later part of the site. The option of becoming member was only an attempt to avoid (to some extent) placing the fake bookings.
During login the user as to enter his emailed/UserID, password and desired time of order delivery. After successful login the customer can access the menu page with the items listed according to the desired time. Later within the available items he can search for a menu according to his choice i.e. according to price range and category of food and later he can order a meal.
If the customer later wants to cancel the order, he is permitted to do this only within a specific time period. The customer is also given with the facility to view the status of the order and if the order is ready then he can go and get it.
At Management side, initially the staff member has to login, and according to his designation the privileges are set. If the staff member is a cook, then he is allowed to edit only the order items status, indicating which menu items he has prepared.
If suppose the member is an administrator then, he is allowed to reassign the cook according to his priority, he can edit the menu information such as its price, items available currently, etc. He can also change the status of the order (in some special cases), and can also block (if any customer exists)/Edit any customer’s order according to his priority
Client/server describes the relationship between two computer programs in which one program, the client, makes a service request from another program, the server, which fulfils the request.. In a network, the client/server model provides a convenient way to interconnect programs that are distributed efficiently across different locations. Computer transactions using the client/server model are very common.
Some of the characteristics of Client/Server Architecture
Asymmetrical protocols—there is a many-to-one relationship between clients and a server. Clients always initiate a dialog by requesting a service. Servers wait passively for requests from clients.
Encapsulation of services—the server is a specialist: when given a message requesting a service, it determines how to get the job done. Servers can be upgraded without affecting clients as long as the published message interface used by both is unchanged.
Integrity—the code and data for a server are centrally maintained, which results in cheaper maintenance and the protection of shared data integrity. At the same time, clients remain personal and independent.
Location transparency—the server is a process that can reside on the same machine as a client or on a different machine across a network. Client/server software usually hides the location of a server from clients by redirecting service requests. A program can be a client, a server, or both.
Message-based exchanges—clients and servers are loosely-coupled processes that can exchange service requests and replies using messages.
Modular, extensible design—the modular design of a client/server application enables that application to be fault-tolerant. In a fault-tolerant system, failures may occur without causing a shutdown of the entire application. In a fault-tolerant client/server application, one or more servers may fail without stopping the whole system as long as the services offered on the failed servers are available on servers that are still active. Another advantage of modularity is that a client/server application can respond automatically to increasing or decreasing system loads by adding or shutting down one or more services or servers.
Platform independence—the ideal client/server software is independent of hardware or operating system platforms, allowing you to mix client and server platforms. Clients and servers can be deployed on different hardware using different operating systems, optimizing the type of work each performs.
Reusable code—service programs can be used on multiple servers.
Scalability—client/server systems can be scaled horizontally or vertically. Horizontal scaling means adding or removing client workstations with only a slight performance impact. Vertical scaling means migrating to a larger and faster server machine or adding server machines.
Separation of Client/Server Functionality—client/server is a relationship between processes running on the same or separate machines. A server process is a provider of services. A client is a consumer of services. Client/server provides a clean separation of functions.
Shared resources—one server can provide services for many clients at the same time, and regulate their access to shared resources.
Servlets are loaded and executed by a web server. A servlet accepts requests from a client (via the web server), performs some task, and returns the results.
A servlet has to perform follows tasks:
• Read Explicit data (form data) and implicit data (Request headers) sent by the client.
• Generate the results.
• Send explicit data back to client (in HTML format).
• Send implicit data back to client (status code and the response headers).
JSP (Java Server Page)
Java Server Pages (JSP) technology enables us to mix regular, static HTML
with dynamically generated content from servlets. Java Server Pages (JSP) technology offers a simple way to create dynamic web pages that are both platform-independent and server-independent, giving you more freedom through Java technology's "Write Once, Run Anywhere" capability.
JSP technology separates content generation from presentation and takes advantage of reusable tags and objects, simplifying the maintenance of your web applications.
It may seem that servlets and JSPs are mutually exclusive, but in fact they work well together. You can reduce the amount of Java coding in your JSP by passing control from a servlet to a JSP.
The approach used by us is a hybrid approach for serving dynamic content, since it combines the use of both servlets and JSP. It takes advantage of the predominant strengths of both technologies, using JSP to generate the presentation layer and servlets to perform process-intensive tasks. Here, the servlet acts as the controller and is in charge of the request processing and the creation of any objects used by the JSP, as well as deciding, depending on the user's actions, which JSP page to forward the request to. Interestingly in particular there is no processing logic within the JSP page itself!! it is simply responsible for retrieving any objects that may have been previously created by the servlet, and extracting the dynamic content from that servlet for insertion within static templates. In our opinion, this approach typically results in the cleanest separation of presentation from content.
SOFTWARE REQUIREMENT SPECIFICATIONS
3.1 Functional Specifications
3.1.1 Customer Specifications:
a. Search Menu according to the time of order delivery:
During login, the costumer has to enter the time of delivery, and the menu items will appear accordingly. As availability of items differ from time to time.
b. Allow to search menu according to price and category:
Customers can search menu according to price range and the category as well, this functionality will be working as a search under search, i.e. first search criteria will be time of order delivery (which is default for all cases) and the later will be search within those menus according to price and category.
c. Allow to book/cancel order:
Allowing customer to place an order or allowing him to cancel the placed booking.
d. Allow the customer to edit/create his personal account (membership):
Here customer can create his new account or he can edit his personal
information from the existing account.
e. Allow customer an option to change his password:
Customers are given with a facility to change his existing password.
3.1.2 Management Specifications:
a. Edit Menu records:
A manager can edit/create some or whole part of the menu record on daily basis. That is by changing the menu items, prices, description, etc.
b. Reassign Cook:
A manager can reassign the cook for a specific order or an item, originally the system assigns the cook automatically when an item is booked using some distribution fashion i.e. round robin fashion.
So a member can reassign the cook if such situation arrives.
c. Cancellation the order:
A manager can cancel of the order, this situation comes when the something goes wrong with working or in some unusual situations.
d. Create/Edit Cook’s list:
A manager can create a new entry of cook or edit the existing cook’s information from the cook’s list.
e. Blocking specific customer:
A manager can block a particular customer before signing up. This happens when the customer’s previous history is bad, i.e. if he does not come up to take his orders which were ordered previously.
e. Allotting some privileges to cook:
As previously stated a manager can create a cook, along with creation of a new cook he is given some privileges. The privileges include editing the status of the order, i.e. he can enter the status as ready if he has completed that item or can state the order is in process before preparing that item.