Innovative Final Doc

Modern Restaurant System
ACKNOWLEDGEMENT
We wish to express our sincere thanks to our Honorable Principal Dr. P.Ram Mohan Rao for
giving us permission for carrying out the project at COIGN Consultants Pvt Ltd, Hyderabad.
We gratefully acknowledge the inspiring guidance, encouragement and continuous support

of Mr.Karthik Reddy Senior Software Engineer, COIGN Consultants Pvt Ltd, Hyderabad. His
helpful Suggestion and constant encouragement have gone a long way in the completion of this
dissertation .It was a pleasure working under his alert, human and technical supervision.
We express our deep gratitude towards our internal guide, Prof.Jayadev Gyani for his
guidance, comments and encouragement during the course of present work. We are grateful to the
Head, Department of Computer Science and Information Technology, Prof.Jayadev Gyani, for his
valuable suggestions and encouragement during course of the work.
We are greatly indebted to our college, Jayamukhi College of Engineering, which has
provided us the healthy environment to drive us to achive our ambitions and goals.
We owe our hearty regards to all other Proffesors and staff for their encouragement at each
step and their assistance in completion of the project work. Last but not the least; we would like
to thanks our friends for their co-operation and consistent support.
1
CONTENTS:
I COIGN Profile
1. INTRODUCTION
1.1 Purpose
1.2 Document conventions
1.3 Intended Audience and Reading Suggestions
1.4 Goal
1.5 Benefits
2. SYSTEM ANALYSIS
2.1 Existing System
2.2 Proposed System
3. ARCHITECTURE
4. SYSTEM DESIGN
4.1 Module Description
4.2 UML Diagrams
4.3 E-R Diagrams
4.4 Data Dictionary
4.5 Hardware and Software Requirements
2
5. ENVIRONMENT & TECHNOLOGY
6. TESTING
6.1 Testing objectives
6.2 Levels of testing
6.3 White box testing
6.4 Black box testing
6.5 Unit testing
6.6 Integration testing
7. TEST CASES
8. SCREEN SHOTS
9. CONCLUSIONS
10. REFERENCES
3
ABSTRACT
In this mechanical world, the most precious thing which no person can buy with money i
s “time”. So our effort is being laid out in an area where we can help people to save their valuable
time. When you have a restaurant spread on two floors, 30 tables each, 2 bar counter, 2 different
kitchens, 1 Dedicated beverages counter.
A single order can consist of Menu Items to be supplied from different kitchens and bar
counters, due to which there might be problems .Such as:
• Delay in serving
• Misconception of the order
• More requirement of manpower And many more...
Our Modern Restaurant System is a software application which can be implemented by

Providing touch screen facility that puts your business at your fingertips and makes it easy, too.
This software enables the customer to view the menu card on the touch screen and order the
items by himself with the touch of the finger on the screen. Also he can know the amount he need
s to pay. Orders entered by the customer at the client station automatically display at the cooks
station, increasing the speed with which orders can be prepared and decreasing the wasted
time of servers walking back and forth to the kitchen!
When the customer feels to receive the bill he can just close the session so that the bill will be
generated at the server end and also it will be displayed on the table screen.
It can be configured for Fine Dining Restaurants, Bars & Lounges, Discos & Nightclubs, and
Food Court with Prepaid System, Home Delivery, Quick Service / Fast Food and Cafeterias.
In this project we are going to deal with three modules:
4
 Central Management System: This is the centralized location where the menu
is designed and relayed to all ordering terminals.
 Ordering screen: You can place order here and can view the bill amount and
close the session.
 Kitchen Production System: Customers order the items on the touch screen
and these items will be displayed on screen in the kitchen.
 Features of Modern Restaurant System:
 Regional language support
 Easy capture of Customer Information
 Display Customer's Last Visit & Billing Information

 Touch Screen Interface / Cash Register Interface
 This system attracts wide range of customers
 Give customers what they want and improve your customer satisfaction
 Reduce manpower cost
 Fast billing counters & happy customers
5
6
1. INTRODUCTION
0.1 Purpose
Our Modern Restaurant System is a software application which can be implemented by

providing touch screen facility that puts your business at your fingertips and makes it easy, too.
This software enables the customer to view the menu card on the touch screen and order the items
by himself with the touch of the finger on the screen.
0.2 Document Conventions
In this SRS document, we have used the following format:

For Headings: Font: 16pt
Font-face : Times New Roman
Font-weight :Bold
For Sub Headings:
Font: 14pt
Font-face : Times New Roman
Font-weight :Bold
For Content : Font: 11pt
Font-face: Times New Roman
Font-weight: Normal
KPS: Kitchen Production System
SRS: Software Requirements Specification
DB: Database
OS: Operating System
Future scope for this project: Italics
7
0.3 Intended Audience and Reading Suggestions
This SRS is mainly intended for developers, testers, users and marketing staff. The suggested
sequence for reading SRS is:
1. Overall Description
2. System Features
3. External Interface Requirements
4. Non Functional Requirements.
1.4 Goal
To overcome the following consequences:
a. Delay in serving
b. Misconception of order
c. More requirement of manpower……..
1.5 Benefits
• Increase your number of customers
• Fastest implementation (just a snap!)
• Increase the number of sales per customer
• Give customers what they want and improve your customer satisfaction
• Reduce manpower cost
• Reduce the erroneous data entry
• Fast billing counters & happy customers
8
2 SYSTEM ANALYSIS
2.1 Existing System:
In this system the customer is given a menu card from which he needs to select the items and
orders are noted down by the waiter manually. Then the waiter submits this order to the kitchen
head, who instructs the chefs. On the request of the customer for the bill, the waiter informs the
cashier to generate the bill and gets back the bill to the customer for payment. Due to this there
are many drawbacks such as :
a. Delay in serving
b. Misconception of order
c. More requirement of manpower……..
To avoid all these we will switch to Modern Restaurant System.
2.2 Proposed System:
Our MRS is an innovative solution for restaurants which can create craze among the youngsters.
MRS is a windows based application developed in .Net. This application is concerned with 3
modules:
• Back Office
• KPS
• User Terminal
This software enables the customer to view the menu card on the touch screen and order the items
by himself with the touch of the finger on the screen. Also he can know the amount he
need to pay. When the customer feels to receive the bill he can just close the session so that the
bill will be generated at the server end and also it will be displayed on the table screen.
Orders entered by the customer at the client station automatically display at the
cooks station, increasing the speed with which orders can be prepared and decreasing the wasted
time of servers walking back and forth to the kitchen! When the customer closes the session, the
order information along with the bill details automatically send to the server where the bill is
generated avoiding misconceptions in the bill
9
3 ARCHITECTURE
BACK OFFICE
DB 7777777777
Configuration 6
update
Kitchen
production
4 system
1, 2, 3
USER TERMINALS 5
Table 1
Table N
1: Signal send to Back Office when a table is occupied by customer

2: Signal send to Back Office when customer request for the bill
3:Signal send to Back Office when customer registers
4: Menu Card displayed on each terminal is updated by Back Office through this signal.
5: Ordered Items are send to Kitchen room.
6: Signal send to KPS when customer vacates table.
LIFE CYCLE MODEL USED
10
The life cycle model which we use in our application is RAD (Rapid Application Development)
model.
RAD (rapid application development) is a concept that products can be developed faster and of
higher quality through:
• Gathering requirements using workshops or focus groups

• Prototyping and early, reiterative user testing of designs
• The re-use of software components
• A rigidly paced schedule that defers design improvements to the next product version
• Less formality in reviews and other team communication
CHARACTERISTICS OF RAD
A. RAD USES HYBRID TEAMS
• Teams should consist of about 6 people, including both developers and full-time
users of the system plus anyone else who has a stake in the requirements
• Developers chosen for RAD teams should be multi-talented "renaissance" people
who are analysts, designers and programmers all rolled into one
B. RAD USES SPECIALIZED TOOLS THAT SUPPORT
• "visual" development
• creation of fake prototypes (pure simulations)
• creation of working prototypes
• multiple languages
• team scheduling
• teamwork and collaboration
• use of reusable components
• use of standard APIs

•
11
C. RAD USES ITERATIVE, EVOLUTIONARY PROTOTYPING
 ITERATE UNTIL DONE
a. Developers build / evolve prototype based on current requirements.

b. Designers review the prototype.
c. Customers try out the prototype, evolve their requirements.
d. FOCUS GROUP meeting
e. Customers and developers meet to review product together,
refine requirements, generate change requests.
• Developers listen.
• Customers talk.
f. Requirements and change requests are "time boxed".
• Changes that cannot be accommodated within existing timeboxes are
eliminated.
• If necessary to stay "in the box," secondary requirements are
dropped.
WHEN RAD WORKS AND WHEN IT DOESN'T
A. RAD TENDS TO WORK WHEN
• The application will be run standalone.
• Major use can be made of preexisting class libraries (APIs).
• Performance is not critical.
• Product distribution will be narrow (in-house or vertical market).
• Project scope (macro-schedule) is constrained.
• Reliability is not critical.
• System can be split into several independent modules.
• The product is aimed at a highly specialized IS (information systems) market.
• The project has strong micro-schedule constraints (time boxes).
• The required technology is more than a year old.
12
B. RAD TENDS TO FAIL WHEN
• Application must interoperate with existing programs.
• Few plug-in components are available.
• Optimal performance is required.
• Product development can't take advantage of high-end IS tools

(e.g., 4GLs).
• Product distribution will be wide (horizontal or mass market).
• RAD becomes QADAD (Quick And Dirty Application Development).
• RAD methods are used to build operating systems (reliability target too high for
RAD), computer games (performance target too high for RAD).
• Technical risks are high due to use of "bleeding" edge technology.
• The product is mission - or life - critical.
• The system cannot be modularized (defeats parallelism).
EVALUATION OF RAD:
1. ADVANTAGES OF RAD
• Buying may save money compared to building
• Deliverables sometimes easier to port (because they make greater use of high-level
abstractions, scripts, intermediate code)
• Development conducted at a higher level of abstraction (because RAD tools operate at
that level)
• Early visibility (because of prototyping)
• Greater flexibility (because developers can redesign almost at will)
• Greatly reduced manual coding (because of wizards, code generators, code reuse)
• Increased user involvement (because they are represented on the team at all times)
13
• Possibly fewer defects (because CASE tools may generate much of the code)
• Possibly reduced cost (because time is money, also because of reuse)
• Shorter development cycles (because development tilts toward schedule and away from
economy and quality)
• Standardized look and feel (because APIs and other reusable components give a
consistent appearance)
2. DISADVANTAGES
• Buying may not save money compared to building
• Cost of integrated toolset and hardware to run it
• Harder to gauge progress (because there are no classic milestones)
• Less efficient(because code isn't hand crafted)
• Loss of scientific precision(because no formal methods are used)
• May accidentally empower a return to the uncontrolled practices of the early days of
software development
• More defects(because of the "code-like-hell" syndrome)
• Prototype may not scale up, a B-I-G problem
• Reduced features(because of time boxing, software reuse)
• Reliance o n third-party components may ...
i. sacrifice needed functionality
ii. add unneeded functionality
iii. create legal problems
• Requirements may not converge(because the interests of customers and developers

may diverge from one iteration to the next)
• Standardized look and feel (undistinguished, lackluster appearance)
• Successful efforts difficult to repeat(no two projects evolve the same way)
• Unwanted features(through reuse of existing components)
14
15
4 SYSTEM DESIGN
Introduction:
Design is the first step in the development phase for any technique and principles for the purpose
of defining a device, a process or system in sufficient details to permit its physical realization.
Once the software requirement have been analyzed and specified the
software design involves three technical activities design, coding, generation and testing that are
required to build and verify the software.
The design activities are of main importance in this phase,
Because in the activity, decision ultimate affecting the success of the software implementation
and its ease of maintained are made. These decisions have the final bearing upon reliability and
maintainability of the system. Design is the only way to accurately translate the customer
requirements into finished software or a system.
Design is the place where quality is fostered in development software
design is a process through which requirements are translated into a representation of software.
Software design is conducted in two steps. Preliminary design is concerned with the
transformation of requirement into data.
4.1 Modules of the project
1. Back Office
2. Kitchen Production System
3. User Terminal
16
System Overview:
This Module is used to get the System General Information. Not only Server System but also
to get the information about the Systems connected in the Network. The user has to give the
IP address or Domain name.
1. BACK OFFICE
• It is the core part of the product.
• It is of very high priority.
Facilities provided by this module are:

• Generates unique id, when the customer enters his/her details.
• It designs the menu profiles for the table terminals at certain intervals.
• The manager can configure new :
o Terminals such as either User Terminal / KPS.
o Item Types and Items and activates menu profiles.
For configuration of new catalogs, two types of screens are available:
o Browse Screen: This is the screen where the manager can be provided
with add, edit, delete and cancel options
17
o Detail Screen: This is the screen where the manager can view the whole
details about the selected row.
• Monitors the status of the table terminals.
• Generates the bill for respective table terminal.
Stimulus / Response Sequences :
• The server should be provided with a facility of maintaining three list

boxes to ease the task of monitoring. They are :
o In Progress: When the customer sends the order, then the

respective table terminal no. should be automatically placed in
this list indicating that the respective table’s order is in progress.
18
o Pending Payment: When the customer clicks the Bill button

then that particular table terminal no. should be placed in this
list manually by the manager.
o Vacant: When the customer pays the bill, then that particular
table terminal no. should be placed in this list manually by the
manager.
• Whenever the server sees a table terminal no. appear in the vacant list, a
signal should be sent to the KPS so that the slot assigned for that particular
table, if containing any orders should be cleared.
Requirements:
1. Customer Details: Name, Id

2. Order Signal: Table number, Id of the signal
3. Bill Signal: Table number, Id of the signal
2. KITCHEN PRODUCTION SYSTEM

• Here the module consists of only a screen which should be divided into slots,
assigned one for each table terminal.
• This module displays the items ordered by the respective table terminal.
• The orders are being served in a FIFO manner.
19
Stimulus / Response Sequences:
• This is just like a screen where the waiters can look into their respective
table’s order details and later serve them when they get prepared.
• For distinguishing between the items that have been already served and
those which have been not, coloring concept should be provided like -
o Red for those items which have been already served

and green for those which are yet to be served.
Requirements:
1. Terminal Signal: Table terminal no. , Timestamp, Order details
2. Clear Signal: Table terminal no.
3. USER TERMINAL
20
• This module enables the customer to enter his details for further benefits
provided by the hotel.
• The customer can view the menu and place his order by selecting the
items displayed on the Touch screen with the finger.
• The customer can request for the bill.
Stimulus / Response Sequences:
• If the customer is regular, then he should enter his / her id and then only he /she
can view the menu.
21
• If not, then he should enter his / her name, for which an id will be generated and
then he /she can see them menu.
• While ordering, the customer can lessen the quantity of any item ordered or
increase or delete any item if it is selected.
Requirements:
1. Selecting the Language: English /Telugu
2. New User: Name
3. Old User: Id
4. Item Name
22
PROJECT DESIGN
4.2 UML Diagrams
The Unified Modeling Language (UML) is a standard language for specifying,

visualizing, constructing, and documenting the artifacts of software systems, as well as for
business modeling and other non-software systems. The UML represents a collection of best
engineering practices that have proven successful in the modeling of large and complex
systems. The UML is very important parts of developing object oriented software and the
software development process. The UML uses mostly graphical notations to express the
design of software projects. Using the UML helps project teams communicate, explore
potential designs, and validate the architectural design of the software.
Each UML diagram is designed to let developers and customers view a software
system from a different perspective and in varying degrees of abstraction. UML diagrams
commonly created in visual modeling tools include
Use Case Diagram displays the relationship among actors and use cases.
Class Diagram models class structure and contents using design elements such as classes,
packages and objects. It also displays relationships such as containment, inheritance,
associations and other
Interaction Diagrams:
• Sequence Diagram displays the time sequence of the objects participating in the
interaction. This consists of the vertical dimension (time) and horizontal dimension
(different objects).
• Collaboration Diagram displays an interaction organized around the objects and their
links to one another. Numbers are used to show the sequence of messages.
23
User Classes and Characteristics
Customer: The customer should just select the required items.

Kitchen Supervisor: He/She assigns tables to servers
Waiter: Serves the items to the tables which are assigned to him
Supervisor: Monitors the entire session in dining hall
BackOffice Manager: Configures item list on day to day process, monitors the status of each
table and generates bill when requested by customer
24
USECASE DIAGRAM FOR MRS
configuration
updation
MANAGER
bill generation
order
recieve items
CUSTOMER
eat
pay bill
KITCHEN CHEF
see the display
prepare the items
send the items
close the session
25
SEQUENCE DIAGRAM FOR CMS
MANAGER DATABASE PROFILE TABLE

TERMINAL
configuration
update the profile
update the menu
register
bill generation
update the user terminals
26
C OLLABR ATION DIAGR AM FOR C MS
TABLE
PROFIL TERM INAL
E
2: update the profile

4: register
5: bill generation
3: update the menu 6: update the user terminals
DATABA MA NAG
SE ER
1: configuration
27
SEQUENCE DIAGRAM FOR KPS
Kitchen Chef User Terminal menu kitchen display

screen
order
prepare the items according to the display
item code for the items
prepare items
send the items
close the session after leaving of customer
28
C OLLABRATION DIAGRAM FOR KPS
User menu
Terminal
1: order
3: item code for the items
4: prepare items
5: send the items
2: prepare the items according to the display

kitchen display Kitchen
screen Chef
6: close the session after leaving of customer
29
SEQUENCE DIAGRAM FOR UT

CUSTOMER DATABASE ITEM TYPE ID DISPLAY
register
order the items according to the id
order is displayed on the display side of chef
pay the bill
close the session
30
C O L L A B R A T IO N D IA G R A M F O R U T
1: regis ter
4: pay the bill
5: c los e the s es s ion
CUS TO DA TA B A
MER SE
2: order the item s ac c ording to the id

3: order is dis play ed on the dis play s ide of c hef
DIS P LA ITE M
Y TY P E ID
31
4.3 E-R Description:
Entity Relationship (ER) Diagram Generator helps users achieve a better

understanding of their database schema by displaying the structure in a graphical
format.
To view an ER Diagram:
1. Launch the ER Diagram Generator dialog by:

o Selecting Tools -> ER Diagram Generator from the Menu Bar OR
o Selecting Tools -> ER Diagram Generator from the right-click pop-up
menu on a database object in the Schema Browser
2. Select a Database and Schema (or All Schemas)
3. In the left panel, select one or more types of objects to be scripted (Tables, Views
or Both).Click the green check button to select all and the red X button to deselect
all.
4. All objects matching the selected schema & object types will appear in the right panel.
Select one or more objects to be scripted.Click the green check button to select all and the
red X button to deselect all.
5. Click Next to generate the diagram
32
6. Once the diagram is generated, the ER Diagram Viewer will open and display the
new diagram.
7. To change the layout of the diagram, select an entry from the Layout dropdown
list
Supported layouts include:
• Box
• Circle
• Hierarchical
• Tree
• Radial Tree
• Moen
• Fruchterman-Reingold (FR)
• Annealing
• Inverted Self Organizing Map (ISOM)
8. The Entity View drop-down list determines the amount of detail displayed for
each entity in the diagram. Select Full to view all attributes or Header to view
only the entity name.
9. To save an image of the current diagram, click Save Image As.
10. To print a hard-copy of the current diagram, click Print.
Click on an entity to display more column & constraint detail in the lower left panel.
33
E-R DIAGRAM
34
35
4.4 DATA DICTIONARY
The logical characteristics of current systems data stores, including name, description, aliases,
contents and organization. Identifies processes where the data are used and where immediate
access to information needed. Servers as the basis for identifying database requirements during
system design.
Uses of Data Dictionary:
1. To manage the detail in large systems

2. To communicate a common meaning for all system elements
3. To Document the features of the system
4. To facilitate analysis of the details in order to evaluate characteristics and determine where
system changes should be made.
5. To locate errors and omissions in the systems.
36
ITEM_TYPE TABLE:
COLUMN DATA TYPE LENGTH ALLOW NULLS DESCRIPTION

NAME
Item_Type_Id Int 2 - Primary key
Item_Type_Nam marcher 50 -
e
ITEM TABLE:
COLUMN DATA TYPE ALLOW DESCRIPTION

NAME NULLS
Item_Id int - Primary key
ItemName varchar -
ItemPrice int -
Veg_flag int -
Graphic image -
Item_Type_Id int - Foreign key
LEVEL TABLE:
COLUMN DATA TYPE LENGTH ALLOW DESCRIPTION

NAME NULLS
Level_Id int 2 - Primary key
Level_Name Varchar 50 -
Profile_Id int 2 - Foreign key

reference from
profile table
PROFILE:
37
COLUMN DATA TYPE LENGTH ALLOW DISCRIPTION

NAME NULLS
Profile_Id int 2 - Primary key
Profile_Name varchar 50 - -
TERMINAL:

NAME NULLS
Terminal_Id int 2 - Primary key
Terminal_Name varchar 50 - -
Terminal _Type varchar 1 - -
LEVEL_ITEM_MAPPING:

NAME NULLS
Mapping_Id int 2 - Primary key
Item_Id int 2 - Foreign key
Level_Id int 2 - Foreign key
38
4.5 Operating Environment
Deployment Environment:
• SERVER
o HARDWARE REQUIREMENTS
 RAM (256 MB) recommended 512 MB

 Hard Disk – 1.5 GB (other than OS space)
 Pentium 4 processor or higher
o SOFTWARE REQUIREMENTS
 .NET Framework 2.0

 SQL server 2000
 Windows 2000 SP4 or XP SP2 Windows server 2003 SP2
 Receipt Printer Software - Thermal printer
• CLIENT
 RAM (128 MB) ,recommended 256 MB

 Pentium 3 or Pentium 4 processor
 LAN card
 Cables
 Switches
 Hubs
 Touch screen sheets
39
 Windows 2000 SP4 or higher
 .Net Framework 2.0
Development Environment
• SERVER
 RAM (256 MB) recommended 512 MB

 Hard Disk – 1.5 GB (other than OS space)
 Pentium 4 processor or higher
 .NET Framework 2.0

 C# 2.0
 SQL server 2000
 Windows 2000 SP4 or XP SP2 Windows server 2003 SP2
 Receipt Printer Software- Dot matrix printer
40
5. ENVIRONMENT & TECHNOLOGY

Introduction to .NET
The .Net frame is a set of technologies for developing and using components to create:
• Web forms
• Web services
• Windows applications
The .Net frame work supports software lifecycle
• Development
• Debugging
• Deployment
• Maintenance
41
The .NET Framework
.Net languages are not compiled to machine code. They are compiled to an
Intermediate Language (IL). CLR accepts the IL code and recompiles it to machine code. All
languages compile to IL (managed code). IL always complied to native code before being
executed. The recompilation is just-in-time (JIT) meaning it is done as soon as a function or
subroutine is called. The JIT code stays in memory for subsequent calls. In cases where there
is not enough memory it is discarded thus making JIT process interpretive.
Common language Runtime Services:
• Code management
• Conversion of IL to native code
• Loading and execution of managed code
• Creation and management of metadata
• Verification of type safety
42
ADO.NET ARCHITECTURE:
ADO.NET was designed to meet the needs of new programming model: disconnected data
architecture, tight integration with XML, common data representation with the ability to combine
data from multiple and varied data sources, and optimized facilities for interacting with a
database, all native to the .NET Framework.
In creating ADO.NET, Microsoft embraced the following design goals:
• Leverage current ActiveX Data Objects (ADO) knowledge.

• Support the n-tier programming model.
• Integrate XML support
Data Access in ADO.NET relies on two components: Dataset and Data Provider.
Dataset:
The dataset is a disconnected, in-memory representation of data. It can be considered as a local
copy of the relevant portions of the database. The Dataset is persisted in memory and the data in
it can be manipulated and updates independent of the database. When the use of this Dataset is
finished, changes can be made back to the central database for updating. The data is Dataset can
be loaded from any valid data source like Microsoft SQL Server database, an Oracle database or
from a Microsoft Access database.
Data Provider:
The Data Provider is responsible for providing and maintaining the connection to the database. A
Data Provider is a set of related components that work together to provide data in an efficient and
performance driven manner.
The .NET Framework currently comes with two Data Providers: the SQL Data Provider which
is designed only to work with Microsoft’s SQL Server 7.0 or alter and the Ole Db Data Provider
consists of the following component classes:
a. The Connection object which provides a connection to the database.

b. The Command object which is used to execute a command.
43
c. The Data Reader object which provides a forward-only, read only, connected record set.
d. The Data Adapter object which populates a disconnected Dataset with data and performs
update.
ARCHITECTURE OF ADO.NET:
Component Classes of Data Providers:
 The Connection Object creates the connection to the database. Microsoft Visual
Studio .NET provides two types of Connection classes: the Sql Connection object, which is
designed specifically to connect to Microsoft SQL Server 7.0 or later, and the OleDb Connection
object, which can provide connections to a wide range of database types like Microsoft Access
and Oracle. The Connection object contains all of the information required to open a connection
to the database.
 The Command Object is represented by two corresponding classes: Sql Command and
OleDb command. Command objects are used to execute commands to a database across a data
connection. The Command Objects are used to execute stored procedures on the database, SQL
44
Commands, or return complete tables directly. Command objects provide three methods that are
used to execute commands on the database:
 Execute Non Query: Executes commands that have no return values such as INSERT,
UPDATE or DELETE.
 Execute Scalar: Returns single value from a database query.
 Execute Reader: Returns a result set by way of a Data Reader object.
 The Data Reader Object provides a forward-only, read-only, connected stream record set
from a database. Unlike other components of the Data Provider, Data Reader objects cannot be
directly instantiated. Rather, the Data Reader is returned as the results of the Command object’s
Execute Reader method. The SqlCommand. Execute Reader method returns a SqlDataReader
object, and the OleDbCommand.ExecuteReader method returns on OleDb Data Reader object.
The DataReader can provide rows of data directly to application logic when you do not need to
keep the data cached in memory. Because only one row is in memory at a time, the DataReader
provides the lowest overhead in terms of system performance but requires the exclusive use of an
open Connection object for the lifetime of the DataReader.
 The DataAdapter is the class at the core of ADO.Net's disconnected data access. It is
essentially the middleman facilitating all communication between the database and Dataset. The
data adapter is used either to fill a Data Table or Dataset with data from database with its Fill
method. After the memory-resident data has been manipulated, the DataAdapter can commit the
changes to the database by calling the Update method. The DataAdapter provides four properties
that represent database commands:
SERIALIZATION
45
Serialization is the process of converting the state of an object into a form that can be persisted or
transported. The complement of serialization is deserialization, which converts a stream into an
object. Together, these processes allow data to be easily stored and transferred.
The .NET Framework features two serializing technologies:
• Binary serialization preserves type fidelity, which is useful for preserving the
state of an object between different invocations of an application. For example, you can
share an object between different applications by serializing it to the Clipboard. You can
serialize an object to a stream, to a disk, to memory, over the network, and so forth.
Remoting uses serialization to pass objects "by value" from one computer or application
domain to another.
XML serialization serializes only public properties and fields and does not preserve type fidelity.
This is useful when you want to provide or consume data without restricting the application that
uses the data. Because XML is an open standard, it is an attractive choice for sharing data across
the Web. SOAP is likewise an open standard, which makes it an attractive choice
Advantages of Using XML Serialization
The XmlSerializer class gives you complete and flexible control when you serialize an object as
XML. If you are creating an XML Web service, you can apply attributes that control serialization
to classes and members to ensure that the XML output conforms to a specific schema.
For example, XmlSerializer enables you to:
• Specify whether a field or property should be encoded as an attribute or an element.

• Specify an XML namespace to use.
• Specify the name of an element or attribute if a field or property name is inappropriate.
Another advantage of XML serialization is that you have no constraints on the applications you
develop, as long as the XML stream that is generated conforms
to a given schema. Imagine a schema that is used to describe books. It features a title, author,
publisher, and ISBN number element. You can develop an application that processes the XML
data in any way you want, for example, as a book order, or as an inventory of books. In either
case, the only requirement is that the XML stream conforms to the specified XML Schema
definition language (XSD) schema.
46
XML Serialization Considerations
The following should be considered when using the XmlSerializer class:
• The Sgen.exe tool is expressly designed to generate serialization assemblies for optimum
performance.
• The serialized data contains only the data itself and the structure of your classes. Type
identity and assembly information are not included.
• Only public properties and fields can be serialized. Properties must have public accessors
(get and set methods). If you need to serialize non-public data, use the BinaryFormatter
class rather than XML serialization.
• A class must have a default constructor to be serialized by XmlSerializer.
• Methods cannot be serialized.
• XmlSerializer can process classes that implement IEnumerable or ICollection
differently if they meet certain requirements, as follows.
A class that implements IEnumerable must implement a public Add method that takes a
single parameter. The Add method's parameter must be consistent (polymorphic) with
the type returned from the IEnumerator.Current property returned from the
GetEnumerator method.
A class that implements ICollection in addition to IEnumerable (such as CollectionBase)

must have a public Item indexed property (an indexer in C#) that takes an integer, and it
must have a public Count property of type integer. The parameter passed to the Add
method must be the same type as that returned from the Item property, or one of that
type's bases.
• XmlSerializer creates C# (.cs) files and compiles them into

• creates C# (.cs) files and compiles them into .
47
Xml file format:

<?xml version="1.0" standalone="yes" ?>
- <root>
- <items>
<iid>1</iid>
<iname>Tomato soup</iname>
<iprice>40</iprice>
<ipath>D:\veg\tomatosoup.jpg</ipath>
<isveg>True</isveg>
</items>
- <items>
<iid>2</iid>
<iname>hot&sour soup</iname>
<iprice>50</iprice>
<ipath>D:\veg\hot&sour.jpg</ipath>
<isveg>True</isveg>
</items>
- <items>
<iid>3</iid>
<iname>corn soup</iname>
<iprice>40</iprice>
<ipath>D:\veg\csoup.jpg</ipath>
<isveg>True</isveg>
</items>
- <items>
<iid>4</iid>
<iname>chicken soup</iname>
<iprice>60</iprice>
<ipath>D:\nonveg</ipath>
<isveg>False</isveg>
</items>
- <items>
<iid>5</iid>
<iname>hot&sour chicken soup</iname>
<iprice>60</iprice>
<ipath>D:\nonveg</ipath>
<isveg>False</isveg>
</items>
- <items>
<iid>7</iid>
<iname>idly</iname>
<iprice>20</iprice>
<ipath>D:\veg\idli.jpg</ipath>
<isveg>True</isveg>
</items>
- <items>
<iid>8</iid>
<iname>dosa</iname>
<iprice>20</iprice>
<ipath>D:\veg\dosa.jpg</ipath>
<isveg>True</isveg>
</items>
48
- <items>
<iid>11</iid>
<iname>puri</iname>
<iprice>30</iprice>
<ipath>D:\veg\puri.jpg</ipath>
<isveg>True</isveg>
</items>
- - <level>
<iid>0</iid>
<iname>soups</iname>
<item22>1</item22>
<item23>2</item23>
<item24>3</item24>
<item25>4</item25>
<item26>5</item26>
</level>
- <level>
<iid>1</iid>
<iname>tiffins</iname>
<item22>7</item22>
<item23>8</item23>
<item24>11</item24>
<item25>12</item25>
<item26>14</item26>
<item27>16</item27>
</level>
</root>
49
SCREENSHOTS
1. Welcome Screen – The first screen on the table terminal
50
2. Registration Page on table terminal
51
3. Registration Page on table terminal – On clicking New user, user
name text box is enabled.
52
4. Registration Page on table terminal – On clicking existing user, user
id text box is enabled.
53
5. Language selection Page on table terminal
54
6. Menu screen on table terminal
55
7. Menu screen on table terminal – Item list showing selection item
56
8. Menu screen on table terminal – Alert asking user to select an item
prior to clicking delete
57
9. Menu screen on table terminal – Observe the decremented count of
item “idli”. Decremented on clicking delete button.
58
10. KPS Terminal – screen showing the items received from table 1.
59
11.KPS Terminal – screen showing the items received from table 1.

Observe the color change – items in red are order first and items in
black are order just now.
60
6. TESTING
6.1 Testing objectives
To deliver a bug free high quality application with almost zero bugs for complete usage
experience to the end users.
6.2 Levels of testing
In order to uncover the errors present in different phases we have the concept of levels of testing.
The basic levels of testing are:
Client Needs Acceptance Testing
Requirements System Testing
Design Integration Testing
Code Unit Testing
6.3 White box testing
White box testing strategy deals with the internal logic and structure of the code. White box
testing is also called as glass, structural, open box or clear box testing. The tests written based on
the white box testing strategy incorporate coverage of the code written, branches, paths,
statements and internal logic of the code etc.
In order to implement white box testing, the tester has to deal with the code and hence is needed
to possess knowledge of coding and logic i.e. internal working of the code. White box test also
needs the tester to look into the code and find out which unit/statement/chunk of the code is
malfunctioning.
61
6.4 Black box testing
Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need any
knowledge of internal design or code etc. As the name "black box" suggests, no knowledge of
internal logic or code structure is required. The types of testing under this strategy are totally
based/focused on the testing for requirements and functionality of the work product/software
application. Black box testing is sometimes also called as "Opaque Testing",
"Functional/Behavioral Testing" and "Closed Box Testing".
This method of test design is applicable to all levels of software testing: unit, integration,
functional testing, system and acceptance. The higher the level, and hence the bigger and more
complex the box, the more one is forced to use black box testing to simplify. While this method
can uncover unimplemented parts of the specification, one cannot be sure that all existent paths
are tested.
6.5 Unit testing
In computer programming, unit testing is a procedure used to validate that individual units of
source code are working properly. A unit is the smallest testable part of an application. In
procedural programming a unit may be an individual program, function, procedure, etc., while in
object-oriented programming, the smallest unit is a method, which may belong to a base/super
class, abstract class or derived/child class.
Ideally, each test case is independent from the others; mock or fake objects[1] as well as test
harnesses can be used to assist testing a module in isolation. Unit testing is typically done by
developers and not by software testers or end-users.
The goal of unit testing is to isolate each part of the program and show that the individual parts
are correct. A unit test provides a strict, written contract that the piece of code must satisfy. As a
result, it affords several benefits.
Unit testing allows the programmer to refractor code at a later date, and make sure the module
still works correctly (i.e. regression testing). The procedure is to write test cases for all functions
and methods so that whenever a change causes a fault, it can be quickly identified and fixed.
62
Readily-available unit tests make it easy for the programmer to check whether a piece of code is
still working properly. Good unit test design produces test cases that cover all paths through the
unit with attention paid to loop conditions.
In continuous unit testing environments, through the inherent practice of sustained maintenance,
unit tests will continue to accurately reflect the intended use of the executable and code in the
face of any change. Depending upon established development practices and unit test coverage,
up-to-the-second accuracy can be maintained.
6.6 Integration testing
Integration testing (sometimes called Integration and Testing, abbreviated I&T) is the phase of
software testing in which individual software modules are combined and tested as a group. It
follows unit testing and precedes system testing.
Integration testing takes as its input modules that have been unit tested, groups them in larger
aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its
output the integrated system ready for system testing.
The purpose of integration testing is to verify functional, performance and reliability

requirements placed on major design items. These "design items", i.e. assemblages (or groups of
units), are exercised through their interfaces using black box testing, success and error cases
being simulated via appropriate parameter and data inputs. Simulated usage of shared data areas
and inter-process communication is tested and individual subsystems are exercised through their
input interface. Test cases are constructed to test that all components within assemblages interact
correctly, for example across procedure calls or process activations, and this is done after testing
individual modules, i.e. unit testing.
63
7. TEST CASE
Terminal Registration:
TEST CASE: 1
FUNCTION EXPECTED ACTUAL LOW HIGH

REUSLTS RESULTS PRIORITY PRIORITY
Name Should allow allows user to
user to enter his enter his name
-------------------- Yes
name by
clicking on on-
screen
keyboard
layout
Select language Language Display
should be language
-------------------- Yes
displayed and should select
selected
Id Should enter Enter the id
the id given by
-------------------- Yes
database
64
Menu Screen:
TEST CASE 2:

Tab Control Shows all the Shows all the
levels levels
--------------------- Yes
Delete Delete the Delete the
selected item selected item
only only
--------------------- Yes
-
Delete all Delete all the Delete all the
items order by us items
Which is --------------------- Yes
displayed on tree
view
Send We send all the We send all the
items to the kps items to the kps
-------------------- Yes
bill After the order Bill is generated
we request for bill
to the manager --------------------- Yes
65
KPS Screen:
TEST CASE 3:

List Box View- Items ordered Displayed item
first order will be displayed on the screen
on the kitchen --------------------- Yes
side
List Box View- Old ordered items Newly ordered
second order color should be items have
under same changed and new different color
transaction item should have from old ordered
another color items --------------------- Yes
-
66
8 CONCLUSIONS
The project entitled” Modern Restaurant System” is developed using Microsoft .Net 2.0 for front
end & business logic and SQL Sever 2000 for database. We have developed the project with
utmost care at each level of software development life cycle to achieve a high quality product.
The final product provides good user friendly interfaces for ease of usage to suit the market.
67
9 REFERENCES
• www.msdn.com – Microsoft Developer Network
• www.radiantsystems.com – A leading Hospitality software provider

• C# beginner’s guide – Wrox publications
68

Innovative Final Doc

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Innovative Final Doc

Uploaded by

Copyright:

Available Formats

Modern Restaurant System

We gratefully acknowledge the inspiring guidance, encouragement and continuous support

1.2 Document conventions

1.3 Intended Audience and Reading Suggestions

2.1 Existing System

2.2 Proposed System

4.1 Module Description

4.2 UML Diagrams

4.3 E-R Diagrams

4.4 Data Dictionary

4.5 Hardware and Software Requirements

5. ENVIRONMENT & TECHNOLOGY

6.1 Testing objectives

6.2 Levels of testing

6.3 White box testing

6.4 Black box testing

6.5 Unit testing

6.6 Integration testing

Our Modern Restaurant System is a software application which can be implemented by

In this project we are going to deal with three modules:

 Features of Modern Restaurant System:

 Regional language support

 Easy capture of Customer Information

 Display Customer's Last Visit & Billing Information

 Fast billing counters & happy customers

Our Modern Restaurant System is a software application which can be implemented by

0.2 Document Conventions

In this SRS document, we have used the following format:

0.3 Intended Audience and Reading Suggestions

2.1 Existing System:

2.2 Proposed System:

1: Signal send to Back Office when a table is occupied by customer

LIFE CYCLE MODEL USED

• Gathering requirements using workshops or focus groups

A. RAD USES HYBRID TEAMS

B. RAD USES SPECIALIZED TOOLS THAT SUPPORT

• creation of fake prototypes (pure simulations)

• creation of working prototypes

• teamwork and collaboration

• use of reusable components

• use of standard APIs

C. RAD USES ITERATIVE, EVOLUTIONARY PROTOTYPING

 ITERATE UNTIL DONE

a. Developers build / evolve prototype based on current requirements.

WHEN RAD WORKS AND WHEN IT DOESN'T

A. RAD TENDS TO WORK WHEN

• The application will be run standalone.

• Major use can be made of preexisting class libraries (APIs).

• Performance is not critical.

• Product distribution will be narrow (in-house or vertical market).

• Project scope (macro-schedule) is constrained.

• Reliability is not critical.

• System can be split into several independent modules.

• The product is aimed at a highly specialized IS (information systems) market.

• The project has strong micro-schedule constraints (time boxes).

• The required technology is more than a year old.

B. RAD TENDS TO FAIL WHEN

• Application must interoperate with existing programs.

• Few plug-in components are available.

• Optimal performance is required.

• Product development can't take advantage of high-end IS tools

• RAD becomes QADAD (Quick And Dirty Application Development).