InnovativeFinalDoc

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:

Central Management System: This is the centralized location where the menu

is designed and relayed to all ordering terminals.

4


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

1.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.

1.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


1.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

7777777777

6

4

1, 2, 3

USER TERMINALS 5

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.

10

Kitchen production system

DB

Configuration update

Table 1

Table N


LIFE CYCLE MODEL USED

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

11


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.

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.

12


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

(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)

13


Greatly reduced manual coding (because of wizards, code generators, code reuse)

Increased user involvement (because they are represented on the team at all times)

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

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.

17


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.

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.

18


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.

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.

19


Requirements:

1. Terminal Signal: Table terminal no. , Timestamp, Order details

2. Clear Signal: Table terminal no.

3. USER TERMINAL

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.

20


Stimulus / Response Sequences:

If the customer is regular, then he should enter his / her id and then only he /she

can view the menu.

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

21


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.

22


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

23


24

configuration

updation

bill generation

MANAGER

see the display

prepare the items

send the items

KITCHEN CHEF

order

recieve items

eat

pay bill

close the session

CUSTOMER

USECASE DIAGRAM FOR MRS


DATABASE PROFILE TABLE TERMINAL

MANAGER

configuration

update the menu

register

bill generation

update the user terminals

SEQUENCE DIAGRAM FOR CMS

update the profile

25


PROFILE

TABLE TERMINAL

DATABASE

MANAGER

6: update the user terminals

COLLABRATION DIAGRAM FOR CMS

2: update the profile

1: configuration

3: update the menu

4: register5: bill generation

26

User Terminal menu kitchen display screen

Kitchen Chef

prepare items

prepare the items according to the display

item code for the items

send the items

SEQUENCE DIAGRAM FOR KPS

close the session after leaving of customer

order


27


28

User Terminal

menu

kitchen display screen

Kitchen Chef

4: prepare items

COLLABRATION DIAGRAM FOR KPS

2: prepare the items according to the display

6: close the session after leaving of customer

3: item code for the items

5: send the items

1: order


CUSTOMER DATABASE DISPLAYITEM TYPE ID

register

order the items according to the id

order is displayed on the display side of chef

pay the bill

close the session

SEQUENCE DIAGRAM FOR UT

29


CUSTOMER

DATABASE

DISPLAY

ITEM TYPE ID

COLLABRATION DIAGRAM FOR UT

1: register4: pay the bill

5: close the session

2: order the items according to the id

3: order is displayed on the display side of chef

30


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

31


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.

32


E-R DIAGRAM

33


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.

34


ITEM_TYPE TABLE:

COLUMN

NAME

DATA TYPE LENGTH ALLOW NULLS DESCRIPTION

Item_Type_Id Int 2 - Primary key

Item_Type_Name marcher 50 -

ITEM TABLE:

COLUMN

NAME

DATA TYPE ALLOW

NULLS

DESCRIPTION

Item_Id int - Primary key

ItemName varchar -

ItemPrice int -

Veg_flag int -

Graphic image -

Item_Type_Id int - Foreign key

LEVEL TABLE:

COLUMN

NAME

DATA TYPE LENGTH ALLOW

NULLS

DESCRIPTION

Level_Id int 2 - Primary key

Level_Name Varchar 50 -

Profile_Id int 2 - Foreign key

reference from

profile table

35


PROFILE:

COLUMN

NAME


NULLS

DISCRIPTION

Profile_Id int 2 - Primary key

Profile_Name varchar 50 - -

TERMINAL:

COLUMN

NAME


NULLS

DISCRIPTION

Terminal_Id int 2 - Primary key

Terminal_Name varchar 50 - -

Terminal _Type varchar 1 - -

LEVEL_ITEM_MAPPING:

COLUMN

NAME


NULLS

DISCRIPTION

Mapping_Id int 2 - Primary key

Item_Id int 2 - Foreign key

Level_Id int 2 - Foreign key

36


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


Windows 2000 SP4 or higher

37


.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

38


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

39


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

40


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.

41


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

42


database, SQL 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:

43


SERIALIZATION

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

44


case, the only requirement is that the XML stream conforms to the specified XML Schema

definition language (XSD) schema.

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 .

45


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>

- <items> <iid>11</iid> <iname>puri</iname>

46


<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>

47


SCREENSHOTS

1. Welcome Screen – The first screen on the table terminal

48


2. Registration Page on table terminal

49


3. Registration Page on table terminal – On clicking New user, user

name text box is enabled.

50


4. Registration Page on table terminal – On clicking existing user, user

id text box is enabled.

51


5. Language selection Page on table terminal

52


6. Menu screen on table terminal

53


7. Menu screen on table terminal – Item list showing selection item

54


8. Menu screen on table terminal – Alert asking user to select an item

prior to clicking delete

55


9. Menu screen on table terminal – Observe the decremented count of

item “idli”. Decremented on clicking delete button.

56


10. KPS Terminal – screen showing the items received from table 1.

57


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.

58


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.

59


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.

60

http://en.wikipedia.org/wiki/Method_(computer_science)

http://en.wikipedia.org/wiki/Subroutine

http://en.wikipedia.org/wiki/Regression_testing

http://en.wikipedia.org/wiki/Refactoring

http://en.wikipedia.org/wiki/End-user

http://en.wikipedia.org/wiki/Software_tester

http://en.wikipedia.org/wiki/Software_developer

http://en.wikipedia.org/wiki/Test_harness

http://en.wikipedia.org/wiki/Test_harness

http://en.wikipedia.org/wiki/Unit_testing#cite_note-mocksarentstubs-0%23cite_note-mocksarentstubs-0

http://en.wikipedia.org/wiki/Mock_object#Mocks_and_fakes

http://en.wikipedia.org/wiki/Mock_object

http://en.wikipedia.org/wiki/Test_case

http://en.wikipedia.org/wiki/Method_(computer_science)

http://en.wikipedia.org/wiki/Object-oriented_programming

http://en.wikipedia.org/wiki/Procedural_programming

http://en.wikipedia.org/wiki/Source_code

http://en.wikipedia.org/wiki/Computer_programming

http://en.wikipedia.org/wiki/Acceptance_test

http://en.wikipedia.org/wiki/System_testing

http://en.wikipedia.org/wiki/Integration_testing

http://en.wikipedia.org/wiki/Unit_test

http://en.wikipedia.org/wiki/Software_testing


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.

61

http://en.wikipedia.org/wiki/Test_case

http://en.wikipedia.org/wiki/Subsystem

http://en.wikipedia.org/wiki/Inter-process_communication

http://en.wikipedia.org/w/index.php?title=Error_case&action=edit&redlink=1

http://en.wikipedia.org/wiki/Black_box_testing

http://en.wikipedia.org/wiki/Requirement


http://en.wikipedia.org/wiki/Test_plan

http://en.wikipedia.org/wiki/Unit_testing

http://en.wikipedia.org/wiki/Module_(programming)


http://en.wikipedia.org/wiki/Unit_testing

http://en.wikipedia.org/wiki/Software_testing

http://en.wikipedia.org/wiki/Code_coverage


7. TEST CASE

Terminal Registration:

TEST CASE: 1

FUNCTION EXPECTED

REUSLTS

ACTUAL

RESULTS

LOW

PRIORITY

HIGH

PRIORITY

Name Should allow

user to enter his

name by

clicking on on-

screen

keyboard

layout

allows user to

enter his name-------------------- Yes

Select language Language

should be

displayed and

selected

Display

language

should select-------------------- Yes

Id Should enter

the id given by

database

Enter the id

-------------------- Yes

62


Menu Screen:

TEST CASE 2:

FUNCTION EXPECTED

REUSLTS

ACTUAL

RESULTS

LOW

PRIORITY

HIGH

PRIORITY

Tab Control Shows all the

levels

Shows all the

levels

--------------------- Yes

Delete Delete the

selected item

only

Delete the

selected item

only

---------------------

-

Yes

Delete all Delete all the

items order by us

Which is

displayed on tree

view

Delete all the

items

--------------------- Yes

Send We send all the

items to the kps

We send all the

items to the kps

-------------------- Yes

bill After the order

we request for bill

to the manager

Bill is generated

--------------------- Yes

63


KPS Screen:

TEST CASE 3:

FUNCTION EXPECTED

REUSLTS

ACTUAL

RESULTS

LOW

PRIORITY

HIGH

PRIORITY

List Box View-

first order

Items ordered

will be displayed

on the kitchen

side

Displayed item

on the screen

--------------------- Yes

List Box View-

second order

under same

transaction

Old ordered items

color should be

changed and new

item should have

another color

Newly ordered

items have

different color

from old ordered

items ---------------------

-

Yes

64


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.

65


9 REFERENCES

www.msdn.com – Microsoft Developer Network

www.radiantsystems.com – A leading Hospitality software provider

C# beginner’s guide – Wrox publications

66

http://www.radiantsystems.com/

http://www.msdn.com/

Documents

InnovativeFinalDoc