UNIVERSIDAD NACIONAL DE PIURA

FACULTAD DE INGENIERIA INDUSTRIAL

ESCUELA PROFESIONAL DE MECATRÓNICA

“RED PARA LA GESTION DE PEDIDOS EN UN RESTAURANTE”

PRESENTADA POR:
CALLE JIMENEZ LUIS RODOLFO
DE LA CRUZ RODRIGUEZ STUWAR
VIERA CASTILLO ERNESTO DAVID

DOCENTE:
ING. CALDERON PINEDO LUIS

CURSO:
REDES INDUSTRIALES

Piura, Perú
2018
 1. INTRODUCCIÓN

La situación habitual en un restaurante en cuanto a pedidos, tiempo de espera,

facturación correcta, entre otros, no es la más ideal en la mayoría de los casos, lo que hace
que resulte difícil dar un buen servicio al cliente, sobre todo durante las horas de mayor
ocupación del local.

Los recursos con los que se cuentan en un local de este tipo son escasos, y esto
obliga al personal del restaurante a tener que desplazarse un gran un número de veces de
un lugar a otro para poder cumplir con su labor, ocasionando deficiencias en el servicio,
olvido de órdenes, retardos, y equivocaciones en los pedidos debido a que el sistema que
se utiliza es manual.

Todo lo anteriormente explicado conlleva pérdidas económicas y de clientela

que pueden determinar el éxito o fracaso del negocio. Es por eso que se propone diseñar
e implementar un sistema que brinde flexibilidad gracias al uso de dispositivos
electrónicos con la participación de los trabajadores y el monitoreo del administrador del
negocio, ofrecerá información precisa garantizada por la aplicación, llevará a cabo el
control de usuarios, la integración de los procesos del negocio por medio de los distintos
módulos del sistema, optimización de los mismos debido a que el sistema reduce el
tiempo de ejecución de los procesos y usabilidad.
 2. OBJETIVO

Desarrollar un aplicativo en formato web capaz de dar soporte a la gestión de pedidos de

un restaurante y su posterior atención. Permitiendo automatizar parte del proceso
generado por un cliente: Ordenar su comida, facturarla, atenderla, etc.

3. DESCRIPCIÓN

La red para la gestión de pedidos en un restaurante está diseñada para contener la

información de los pedidos que se encuentren activos mediante la utilización de una base
de datos. Dentro de cada pedido se sabrá qué productos se ha elegido, y sus características.

Además, existe la posibilidad de mantener y manejar la información de los productos

ofertados, mesas. El administrador tiene la posibilidad de modificar toda esta
información.

Existirán al menos cuatro tipos de usuarios a saber:

Administrador: Administración de productos, mesas y facturas.
Caja: Gestiona el flujo de dinero. (Ingresos/Egresos)
Cocinero: Modificación del estado de cada pedido.
Mozo: Creación, modificación y atención de pedidos.

3.1. REQUISITOS FUNCIONALES DE USUARIOS

A continuación, se presentan los requisitos funcionales de cada tipo de

usuario, con fin de detallar los roles o capacidades de cada uno de ellos.

 Usuario Mozo
Acciones que puede realizar el usuario mozo:
 Seleccionar Mesa.
 Crear pedido.
 Agregar un producto al pedido.
  Antes de enviar el pedido, se preguntará si todos los productos
introducidos son los correctos, puesto que una vez confirmado ya
no se tiene la posibilidad de modificarlo, sólo puede añadir más
productos a su pedido.
 Siempre puede saber qué productos existen en el pedido y el costo
de los mismos (unitario y en general, lo que se lleva gastado).
 Identificar cada terminal con el número de mesa correspondiente.
 Sólo es posible realizar un pedido desde una mesa, no hay
posibilidad de hacer varios pedidos por mesa. Se puede ir
agregando productos al pedido, siempre que no esté en estado
“CERRADO”.

 Usuario cocina
Acciones que puede realizar el usuario cocina:
 Recibir los pedidos generados por los mozos.
 Cambiar el estado a los productos del pedido (“En preparación” -
“Despacho”).

 Usuario Caja
Acciones que puede realizar el usuario caja:
 Abrir/Cerrar Caja
 Generar cuenta del consumo de los clientes.
 Emitir un comprobante de pago por cada cuenta generada.

 Usuario administrador
Acciones que puede realizar el usuario administrador:
 Añadir/modificar cualquier producto.
 Añadir mesas.
 4. CASOS DE USO

 Caso N°1: Crear pedido

Actor Usuario Mozo

Descripción Observados los productos o no, será necesario crear un pedido
para su posterior envío.
Flujo del 1. Seleccionar la mesa que ocupará el cliente.
evento 2. El sistema muestra distintas opciones para buscar productos
principal disponibles (entradas, primer plato, segundo plato, postres,
bebidas, menú, etc).
3. Arrastrar los productos que se deseen a la parte inferior,
donde aparece la imagen de una libreta.
4. Una vez se han añadido a los productos deseados, apretar
el botón enviar.
5. El sistema pedirá que se confirme el envío o se cancele,
aceptar.
6. El pedido ha sido enviado a cocina.
Precondición No puede haber otro pedido creado desde la misma mesa.
Postcondición El nombre identificador de la mesa debe de estar relacionado
con el pedido creado
El pedido debe aparecer con el estado “Abierto”.

 Caso N°2: Cambiar estado al producto.

Actor Usuario Cocina

Descripción Un pedido está compuesto por productos, y estos tienen unos
estados, la funcionalidad es cambiar el estado del producto
“En preparación” → “Servido”
Flujo del 1. El sistema muestra una cola de productos de pedidos, los
evento cuales se añaden a la cola según van llegando y se les asigna
principal un estado “En preparación”.
 2. Seleccionar la opción de “Cambiar” del producto que se
haya atendido, de modo que pasa al estado “Servido”.
3. El sistema muestra la opción de confirmación de cambio de
estado.
4. Seleccionar aceptar.
5. La cola de los productos de los pedidos se refrescará con la
cola actualizada.
Precondición El producto del pedido tiene que haberse recibido y añadido a
la cola.
Postcondición El producto del pedido tiene que haber pasado de “En
preparación” a “Servido”.

 Caso N°3: Añadir producto al pedido.

Actor Usuario Mozo

Descripción Añadir productos ofertados disponibles a un pedido creado.
Flujo del 1. El sistema muestra un listado con los pedidos en estado
evento “Abierto”.
principal 2. Seleccionar el pedido que se desee y apretar la opción de
abrir el contenido del mismo.
3. Seleccionar la opción de añadir producto.
4. El sistema muestra un listado de los productos disponibles
según la categoría elegida.
5. Marcar la casilla de los productos a añadir y la cantidad
deseada.
6. Aceptar la inserción en el pedido de los productos.
Precondición El pedido debe de estar creado y en estado “Abierto”.
Postcondición El pedido contiene el producto elegido.
 Caso N°4: Eliminar producto del pedido

Actor Usuario Mozo

Descripción Eliminación de un(os) producto(s) del pedido, que todavía no
haya sido enviado ni finalizado sin necesidad de cancelar el
pedido.
Flujo del 1. El sistema muestra un listado con los pedidos en estado
evento “Abierto”.
principal 2. Seleccionar el pedido que se desee y abrir el contenido del
mismo.
3. Selección el producto que se desee eliminar y elegir la
opción de modificar.
4. Indicar el número de productos deseados, tanto si se desea
reducir la cantidad de un producto o si se quiere eliminar, en
este caso se introducirá el número 0.
5. Aceptar la modificación.
Precondición El pedido esta creado, y no tiene estado “Cerrado”
El producto a eliminar aparece en el pedido.
Postcondición El pedido aparece sin el producto seleccionado.

 Caso N° 5: Añadir mesa.

Actor Usuario Administrador

Descripción Añadir una mesa al listado de mesas disponibles.
Flujo del 1. Seleccionar “Añadir mesa”.
evento 2. Introducir el nombre/numero deseado para la nueva mesa.
principal 3. Seleccionar la opción “enviar”.
4. Se actualiza el listado de mesas disponibles.
Precondición El nombre/número a introducir no esté elegido.
Postcondición La mesa este creada y aparezca como disponible.
 Caso N°6: Añadir Producto

Actor Usuario Administrador

Descripción Cambiar algún dato de un producto
Flujo del 1. El sistema muestra un listado de los productos según la
evento categoría escogida.
principal 2. Seleccionar el producto deseado y elegir la opción
modificar.
3. Cambiar los datos que se crean convenientes.
4. Aceptar la modificación del producto.
5. El sistema comprueba que los dato modificados son
correctos.
6. El sistema muestra la lista de productos.
Precondición El producto debe de estar creado
Postcondición El producto debe aparecer en la lista con los datos
modificados.

 Caso N°7: Modificar Producto

Actor Usuario Administrador

Descripción Eliminación de un(os) producto(s) del pedido, que todavía no
haya sido enviado ni finalizado sin necesidad de cancelar el
pedido.
Flujo del 1. El sistema muestra un listado con los pedidos en estado
evento “Abierto”.
principal 2. Seleccionar el pedido que se desee y abrir el contenido del
mismo.
3. Selección el producto que se desee eliminar y elegir la
opción de modificar.
4. Indicar el número de productos deseados, tanto si se desea
reducir la cantidad de un producto o si se quiere eliminar, en
este caso se introducirá el número 0.
5. Aceptar la modificación.
 Precondición El pedido esta creado, y no tiene estado “Cerrado”
El producto a eliminar aparece en el pedido.
Postcondición El pedido aparece sin el producto seleccionado.

 Caso N° 8: Finalizar pedido.

Actor Usuario mozo

Descripción Proceso mediante el cual un pedido pasa a estado “Cerrado”
y a partir de ahí se puede crear el comprobante de pago
(Boleta/Factura).
Flujo del 1. Seleccionar la opción de finalizar pedido, “Finalizar”.
evento 2. El sistema pide confirmación para finalizar el pedido,
principal aceptar.
3. El pedido ha sido finalizado.
Precondición Todos los productos deben de tener el estado “Servido” para
poder finalizarse.
Postcondición El Pedido pasa a tener el estado “Cerrado”.

 Caso N° 9: Pagar cuenta

Actor Usuario Caja

Descripción Elección del tipo de comprobante de pago (Boleta/Factura)
Flujo del 1. El sistema mostrará el contenido del pedido, El precio de
evento cada producto y el monto total.
principal 2. Elegir el tipo de comprobante de pago.
2. Ingresar el monto con el que el cliente está pagando su
cuenta.
3. Ingresar datos del cliente.
4. Generar comprobante de pago.
5. Cuenta pagada.
Precondición El pedido debe de estar finalizado.
Postcondición El comprobante de pago creado con los datos de pedido y el
cliente.
 5. DISEÑO

5.1. SELECCIÓN DEL ENTORNO DE DESARROLLO

A continuación, se van a describirán aspectos importantes para el diseño del sistema.

 Entorno de desarrollo

“Lenguaje de Programación Interpretado”. Este lenguaje es al que le debemos la

visualización de contenido dinámico en las páginas web. Todo el código PHP es invisible
para el usuario, porque todas las interacciones que se desarrollan en este lenguaje son por
completo transformadas para que se puedan ver imágenes, variedad de multimedia y los
formatos con los que somos capaces de interactuar añadiendo o descargando información
de ellos.

 Servidor web

Apache: es un servidor web HTTP de código abierto para plataformas Unix (BSD,
GNU/Linux, etc.), Microsoft Windows, Macintosh y otras, que implementa el protocolo
HTTP/1.11 y la noción de sitio virtual. Apache presenta entre otras características
altamente configurables, bases de datos de autenticación y negociado de contenido, pero
fue criticado por la falta de una interfaz gráfica que ayude en su configuración.
5.2. XAMPP

Es un paquete de instalación que cuenta con un gestor de base de datos MySQL, servidor
web Apache y un intérprete del lenguaje PHP, con estas herramientas podremos realizar
pruebas de sitios web de forma local sin tener que estar conectados a internet.
5.2 SELECCIÓN DE BASE DE DATOS
 Base de datos

MySQL: es un sistema de gestión de base de datos relacional, multihilo y

multiusuario.

Por un lado, se ofrece bajo la GNU GPL para cualquier uso compatible con esta
licencia, pero para aquellas empresas que quieran incorporarlo en productos
privativos deben comprar a la empresa una licencia específica que les permita este
uso. Está desarrollado en su mayor parte en ANSI C.

 Editor de la base de datos

phpMyAdmin: es una herramienta escrita en PHP con la intención de manejar la

administración de MySQL a través de páginas web. Actualmente puede crear y eliminar
Bases de Datos, crear, eliminar y alterar tablas, borrar, editar y añadir campos, ejecutar
cualquier sentencia SQL, administrar claves en campos, administrar privilegios, exportar
datos en varios formatos.
Seguridad en la base de datos: el programa puede incluir una contraseña para ingresar,
eliminar o modificar datos de la base.

También incluye seguridad para que no se pueda visualizar la base de datos, sin que
tengas información previamente anticipada.
Base de datos SQL
 Programación para generar la base de datos

/**
@author evilnapsis
**/
create database thunder;
use thunder;

create table user(

id int not null auto_increment primary key,
name varchar(50) not null,
lastname varchar(50) not null,
username varchar(50),
email varchar(255) not null,
password varchar(60) not null,
image varchar(255),
is_active boolean not null default 1,
is_admin boolean not null default 0,
is_mesero boolean not null default 0,
is_cajero boolean not null default 0,
created_at datetime not null
);

insert into user(name,lastname,email,password,is_admin,created_at) value

("Administrador", "","admin","90b9aa7e25f80cf4f64e990b78a9fc5ebd6cecad",1,NOW());

create table category(

id int not null auto_increment primary key,
name varchar(50) not null,
is_active boolean not null default 1
);

insert into category (name) value ("Tacos");

insert into category (name) value ("Caldos");
 /* tabla para almacenar las mesas del restaurant*/
create table item(
id int not null auto_increment primary key,
name varchar(50) not null,
capacity int
);

insert into item (name,capacity) values

("1",6),("2",6),("3",6),("4",6),("5",6),("6",6),("7",6),("8",6),("9",6),("10",6);

create table product(

id int not null auto_increment primary key,
code varchar(50) not null,
name varchar(50) not null,
description varchar(50) not null,
preparation varchar(50) not null,
price_in float not null,
price_out float,
unit varchar(255) not null,
presentation varchar(255) not null,
duration int, /* tiempo de preparacion en minutos */
use_ingredient boolean not null default 1,
is_active boolean not null default 1,
user_id int not null,
category_id int,
foreign key (user_id) references user(id),
foreign key (category_id) references category(id)
);

create table ingredient(

id int not null auto_increment primary key,
code varchar(50) not null,
name varchar(50) not null,
price_in float not null,
price_out float,
 unit varchar(255) not null,
is_active boolean not null default 1,
user_id int not null,
foreign key (user_id) references user(id)
);

create table product_ingredient(

id int not null auto_increment primary key,
product_id int not null,
ingredient_id int not null,
q float,
is_required boolean not null,
foreign key (product_id) references product(id),
foreign key (ingredient_id) references ingredient(id)
);

create table operation_type(

id int not null auto_increment primary key,
name varchar(50) not null
);

insert into operation_type (name) value ("entrada");

insert into operation_type (name) value ("salida");

create table sell(

id int not null auto_increment primary key,
item_id int, /* mesa */
q int, /* cantidad de personas en la mesa */
is_applied boolean not null default 0,
mesero_id int,
cajero_id int,
foreign key (mesero_id) references user(id),
foreign key (cajero_id) references user(id),
created_at datetime not null
);

create table operation(

id int not null auto_increment primary key,
product_id int not null,
q float not null,
operation_type_id int not null,
sell_id int,
is_oficial boolean not null default 0,
created_at datetime not null,
foreign key (product_id) references product(id),
foreign key (operation_type_id) references operation_type(id),
foreign key (sell_id) references sell(id)
);
/* para gestionar el inventario de ingredientes */
create table sell2(
id int not null auto_increment primary key,
user_id int ,
operation_type_id int default 2,
foreign key (operation_type_id) references operation_type(id),
foreign key (user_id) references user(id),
created_at datetime not null
);

create table operation2(

id int not null auto_increment primary key,
ingredient_id int not null,
q float not null,
operation_type_id int not null,
sell_id int,
is_oficial boolean not null default 0,
created_at datetime not null,
foreign key (ingredient_id) references ingredient(id),
foreign key (operation_type_id) references operation_type(id),
foreign key (sell_id) references sell2(id)
);

/* no se usa actualmente */
create table spent(
id int not null auto_increment primary key,
q int not null,
concept varchar(255) not null,
unit varchar(255) not null,
price float not null,
category_id int not null,
created_at datetime not null,
foreign key (category_id) references category(id)
);
Programación en PHP
 6. ARQUITECTURA DE LA APLICACIÓN

La aplicación utiliza una arquitectura cliente – servidor.

El proveedor es el servidor web y el cliente son los múltiples hosts que interactúan en el
proceso.
 7. INTERFACES

7.1 Interfaz de ingreso

Es el inicio para que los usuarios (mozo, administrador o cajero), puedan realizar una
acción en el proceso de la aplicación. Ejemplo: el mozo pueda realizar una venta. Para
ello se debe conocer una información que previamente ha sido programada.

7.2. Interfaz de administrador

En esta interfaz el administrador tendrá la opción de monitorear, vender y configurar

todo lo referente al restaurante.
7.2.1. Interfaz monitor

El administrador tendrá la opción de monitorear las mesas que se encuentre en el local

o restaurante.

7.2.2. Interfaz vender

Incluye la acción de vender al restaurante por motivos, que, en situaciones reales, esté
puede tener ciertos afectos hacia un pariente o persona, la cual quiera ofrecerle o
pagarle productos del restaurante
7.2.3. Interfaz sección de ventas

Está interfaz permite al administrador tener en cuenta las ventas diarias, semanales o
instantáneas que tenga fines de contabilidad.

7.2.4. Interfaz sección productos

En está sección le permite al administrador configurar ciertos parámetros de los

productos que se encuentran ofrecidos en el local, dando a cavidad al control total de
agregar o eliminar productos e ingredientes que contengan estos.
7.2.5. Interfaz sección categorías

7.2.6. Interfaz sección reportes

7.2.7 Interfaz sección usuarios

7.2.8 Interfaz configuración de administrador

7.3. Interfaz Cajero
7.4. Interfaz mozo
 8. ARQUITECTURA DE PROTOCOLOS TCP/IP

Las siglas TCP/IP se refieren a un conjunto de protocolos para comunicaciones de datos. Este
conjunto toma su nombre de dos de sus protocolos más importantes, el protocolo TCP
(Transmission Control Protocol) y el protocolo IP (Internet Protocol).

Existen descripciones del protocolo TCP/IP que definen de tres a cinco niveles. La Figura
anterior representa un modelo de cuatro capas TCP/IP y su correspondencia con el modelo de
referencia OSI.

Los datos que son enviados a la red recorren la pila del protocolo TCP/IP desde la capa más alta
de aplicación hasta la más baja de acceso a red. Cuando son recibidos, recorren la pila de
protocolo en el sentido contrario.

Durante estos recorridos, cada capa añade o sustrae cierta información de control a los datos para
garantizar su correcta transmisión.
Como esta información de control se sitúa antes de los datos que se transmiten, se llama cabecera
(header). En la Figura se puede ver cómo cada capa añade una cabecera a los datos que se envían
a la red. Este proceso se conoce como encapsulado.

Si en vez de transmitir datos se trata de recibirlos, el proceso sucede al revés. Cada capa elimina
su cabecera correspondiente hasta que quedan sólo los datos

En teoría cada capa maneja una estructura de datos propia, independiente de las demás, aunque
en la práctica estas estructuras de datos se diseñan para que sean compatibles con las de las capas
adyacentes. Se mejora así la eficiencia global en la transmisión de datos.
 8.1. Capa acceso a red

Dentro de la jerarquía del protocolo TCP/IP la capa de acceso a red se encuentra en el nivel más
bajo. Es en esta capa donde se define cómo encapsular un datagrama IP en una trama que pueda
ser transmitida por la red.

En las redes de área local, se pueden encontrar tecnologías inalámbricas basadas en tecnologías
basadas en WiFi, que siguen el estándar IEEE 802.11x.

Una red de área local inalámbrica (Wireless Local Área Network, WLAN) es un sistema de
comunicación de datos utilizando como medio de transmisión las ondas de radio.

Los requisitos de movilidad en las comunicaciones hacen que se usen cada vez más este tipo de
tecnologías.

Sus características más importantes son:

 La información llega en tiempo real a cualquier lugar de la organización o empresa.
 Se conseguí mayor productividad y posibilidades de servicio.
 Evita al tener que hacer obra para instalar cables por muros y techos.
 Es flexible, que permite llegar donde el cable no puede.
 Son adecuados en entornos muy cambiantes.
 Son muy escalables. Los cambios son sencillos independientemente de si la red es grande
o pequeña.
8.1.1. Topología

Está aplicación usa una topología de tipo infraestructura (cliente y punto de

acceso)
 8.2. Capa de red: internet

En este nivel el protocolo IP es el gran protagonista. Existen varias versiones del

protocolo IP: IPv4 es la que ha sido empleado en este proyecto.

El protocolo de IP (Internet Protocol) es la base fundamental de la Internet. Porta

datagramas de la fuente al destino. El nivel de transporte parte el flujo de datos en datagramas.
Durante su transmisión se puede partir un datagrama en fragmentos que se montan de nuevo en
el destino. Las principales características de este protocolo son:

 Protocolo orientado a no conexión.

 Fragmenta paquetes si es necesario.
 Direccionamiento mediante direcciones lógicas IP de 32 bits.
 Si un paquete no es recibido, este permanecerá en la red durante un tiempo finito.
 Realiza el "mejor esfuerzo" para la distribución de paquetes.
 Tamaño máximo del paquete de 65635 bytes.
 Sólo ser realiza verificación por suma al encabezado del paquete, no a los datos éste que
contiene.

El Protocolo Internet proporciona un servicio de distribución de paquetes de

información orientado a no conexión de manera no fiable. La orientación a no conexión significa
que los paquetes de información, que será emitido a la red, son tratados independientemente,
pudiendo viajar por diferentes trayectorias para llegar a su destino. El término no fiable significa
más que nada que no se garantiza la recepción del paquete.

La unidad de información intercambiada por IP es denominada datagrama. Tomando

como analogía los marcos intercambiados por una red física los datagramas contienen un
encabezado y un área de datos. IP no especifica el contenido del área de datos, ésta será utilizada
arbitrariamente por el protocolo de transporte.

8.2.1 Direcciones IP

Para que en una red dos computadoras puedan comunicarse entre sí ellas deben estar
identificadas con precisión Este identificador puede estar definido en niveles bajos (identificador
físico) o en niveles altos (identificador lógico) de pendiendo del protocolo utilizado. TCP/IP
utiliza un identificador denominado dirección internet o dirección IP, cuya longitud es de 32
bites. La dirección IP identifica tanto a la red a la que pertenece una computadora como a ella
misma dentro de dicha red.

Tomando tal cual está definida una dirección IP podría surgir la duda de cómo identificar
qué parte de la dirección identifica a la red y qué parte al nodo en dicha red. Lo anterior se
resuelve mediante la definición de las "Clases de Direcciones IP". Para clarificar lo anterior
veamos que una red con dirección clase A queda precisamente definida con el primer octeto de
la dirección, la clase B con los dos primeros y la C con los tres primeros octetos. Los octetos
restantes definen los nodos en la red específica.

8.3. Capa transporte

En esta capa se encuentran definidos el protocolo TCP. TCP permite enviar los datos de un
extremo a otro de la conexión con la posibilidad de detectar errores y corregirlos.

El fin de TCP es proveer un flujo de bytes confiable de extremo a extremo sobre una internet no
confiable. TCP puede adaptarse dinámicamente a las propiedades de la internet y manejar fallas
de muchas clases.

La entidad de transporte de TCP puede estar en un proceso de usuario o en el kernel. Parte un

flujo de bytes en trozos y los mande como datagramas de IP.

Para obtener servicio de TCP, el emisor y el recibidor tienen que crear los puntos terminales de
la conexión (los sockets).
La dirección de un socket es la dirección de IP del host y un número de 16 bits que es local al
host (la puerta). Se identifica una conexión con las direcciones de socket de cada extremo; se
puede usar un socket para conexiones múltiples a la vez.

Los números de puerta bajo 256 son puertas bien conocidas para servicios comunes (como FTP).

Las conexiones de TCP son punto-a-punto y full dúplex. No preservan los límites de mensajes.
Cuando una aplicación manda datos a TCP, TCP puede mandarlos inmediatamente o
almacenarlos (para acumular más). Una aplicación puede solicitar que TCP manda los datos
inmediatamente a través del flag de PUSH (empujar).

TCP también apoya los datos urgentes. TCP manda datos con el flag URGENT inmediatamente.
En el destino TCP interrumpe la aplicación (la manda una señal), que permite que la aplicación
pueda encontrar los datos urgentes.

8.4. Capa aplicación

El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un sencillo

protocolo cliente-servidor que articula los intercambios de información entre los clientes Web y
los servidores HTTP

HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexión

con un servidor y envía un mensaje con los datos de la solicitud. El servidor responde con un
mensaje similar, que contiene el estado de la operación y su posible resultado. Todas las
operaciones pueden adjuntar un objeto o recurso sobre el que actúan; cada objeto Web
(documento HTML, fichero multimedia o aplicación CGI) es conocido por su URL.
Un servidor web está a la escucha por un puerto (por defecto, el 80), aceptando peticiones y
haciendo respuestas según el protocolo http.
El protocolo especifica la sintaxis de peticiones y respuestas.
El intercambio de información se hace en modo texto.

Get: se trata de un mensaje con solicitud de datos por parte del cliente, es decir, un navegador
web envía el mensaje GET para solicitar paginas al servidor.

Para profundizar más en el funcionamiento de HTTP, veremos primero un caso

particular de una transacción HTTP; en los siguientes apartados se analizarán las diferentes partes
de este proceso.

Cada vez que un cliente realiza una petición a un servidor, se ejecutan los siguientes
pasos:

 Un usuario accede a una URL, seleccionando un enlace de un documento HTML o

introduciéndola directamente en el campo Location del cliente Web.
 El cliente Web descodifica la URL, separando sus diferentes partes. Así identifica el
protocolo de acceso, la dirección DNS o IP del servidor, el posible puerto opcional (el
valor por defecto es 80) y el objeto requerido del servidor.

 Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP correspondiente.
Se realiza la petición. Para ello, se envía el comando necesario (GET, POST, HEAD,…),
la dirección del objeto requerido (el contenido de la URL que sigue a la dirección del
servidor), la versión del protocolo HTTP empleada (casi siempre HTTP/1.0) y un
conjunto variable de información, que incluye datos sobre las capacidades del browser,
datos opcionales para el servidor.

 El servidor devuelve la respuesta al cliente. Consiste en un código de estado y el tipo de

dato MIME de la información de retorno, seguido de la propia información.

 Se cierra la conexión TCP.

Este proceso se repite en cada acceso al servidor HTTP. Por ejemplo, si se recoge un
documento HTML en cuyo interior están insertadas cuatro imágenes, el proceso anterior se repite
cinco veces, una para el documento HTML y cuatro para las imágenes.
 9. CONCLUSIONES

La aplicación no necesita de algún dominio de internet o protocolo DNS, porque dentro del
proceso de gestión de pedidos, sólo interviene el personal del local, es decir que los clientes del
restaurant no tienen intervención y por ende es una red interna del restaurante.

La seguridad de la aplicación se da en tres fases: en la base de datos, en tener una cuenta y estar
conectada a la misma red que el servidor. Para todas ellas es necesario tener una cuenta,
contraseña o información para poder intervenir en el proceso de gestión de pedidos.

El proyecto realizado puede tener fines comerciales, ya que su uso es la solución de la

problemática que existe en los diferentes restaurantes ubicados en la región Piura.

10.BIBLIOGRAFIA

Herramientas WEB para la enseñanza de protocolos de de comunicación. (s.f.). Obtenido de El

protocolo HTTP

ortiz, O. (s.f.). diales. Obtenido de https://es.scribd.com/document/180090925/2-6-Redes-de-

Area-Local

Rodriguez Hernanz, F. (2010). SGP: SISTEMA DE GESTION DE PEDIDOS. Universidad

Autónoma de Barcelona.

SUMANO FUENTEVILLA, J. (2012). Diseño y construccion de un sistema de seguimiento

fotovoltaico. (Tesis de grado), Uniersidad Tecnológica de la Mixteca, oaxaca.