TPV (Cafetería)

TRABAJO FIN DE ESTUDIOS
PROYECTO FIN DE CARRERA
Aplicacin de gestin para el TPV de una cafetera
Adela Chandro Velasco
Tutor: Eloy Javier Mata Sots
Curso 2011-2012
Aplicacin de gestin para el TPV de una cafetera, trabajo fin de estudios
de Adela Chandro Velasco, dirigido por Eloy Javier Mata Sots (publicado por la
Universidad de La Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan ms all de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.
El autor
Universidad de La Rioja, Servicio de Publicaciones, 2012
publicaciones.unirioja.es
E-mail: publicaciones@unirioja.es
UNIVERSIDAD DE LA RIOJA
Facultad de Ciencias, Estudios Agroalimentarios e Informtica
PROYECTO FIN DE CARRERA
Ingeniera Tcnica en Informtica de Gestin
Aplicacin de gestin para el TPV de una

cafetera
Alumno: Mara Adela Chandro Velasco

Director: Eloy Mata Sotes
Logroo, Junio del 2012
1
INDICE 2
1. D. O. P. 4
1.1 Antecedentes 4
1.2 Objetivos 4
1.3 Descripcin 5
1.4 Entregables 6
1.5 Estructura de descomposicin de tareas 6
1.6 Plan de trabajo 9
1.7 Riesgos 11
2. ANLISIS 12
2.1 Anlisis de requisitos 12
2.1.1 Identificacin de actores 12
2.1.2 Identificacin de los casos de uso 12
2.2 Anlisis de clases 29
2.3 Anlisis de la interfaz 30
2.4 Anlisis de pruebas 31
3. DISEO 33
3.1 Arquitectura del sistema 33
3.2 Diseo de la interfaz 33
3.3 Diseo de las clases 53
3.4 Diseo de la base de datos 61
4. IMPLEMENTACIN 65
4.1 Tecnologas elegidas y herramientas utilizadas 65
4.2 Construccin del sistema de informacin 66
4.2.1 implantacin de la base de datos 66
4.2.2 Preparacin del entorno de construccin 66
4.2.2.1 Libreras externas necesarias 66
4.2.3 Problemas con MySQL 67
4.2.3.1 Borrado y modificacin de productos y familias 67
4.2.3.2 Guardar valores decimales en MySQL 68
4.2.3.3 Modificaciones en la identificacin y creacin de camareros 69
4.2.3.4 Guardar imgenes en la base de datos 69
4.2.4 Problemas encontrados en la aplicacin de gestin 70
2
4.2.4.1 Cierre de caja terico o real 70
4.2.4.2 Reporte de informes 70
4.2.5 Problemas encontrados en la pantalla de ventas 71
4.2.5.1 Tamao de la pantalla de ventas 71
4.2.5.2 Introduccin de precios directos 71
4.2.5.3 Ventas aplazadas 72
4.2.5.4 Imprimir tickets de venta 72
5. GESTIN Y CONCLUSIONES 76
5.1 Planificacin 76
5.2 Aplazamiento 77
5.3 Conclusiones 80
6. APENDICE I: ACTAS DE REUNIONES 82
6.1 Actas de reuniones con los clientes 82
6.2 Actas de reuniones con el director del proyecto 86
3
7. D. O. P.
1.1 Antecedentes
El proyecto consiste en el desarrollo de una aplicacin software para el punto
de venta de un pub juvenil.
Existen numerosas aplicaciones similares hoy en da. Desde las desarrolladas

por grandes empresas como IBM, Apple o Microsoft, muy genricas, desarrolladas
para el TPV de cualquier mediana empresa, sin importar el sector, muy completas y
caras; pasando por aplicaciones menos genricas, desarrolladas por empresas
dedicadas al desarrollo de software como Consultic, One Step Rentail Solutions, SGM o
TPV.NET, creadas para el TPV de cualquier pequea o mediana empresa, de un sector
concreto, tambin muy completas; hasta las que podemos encontrar en pginas de
software libre como Softonic.com, creadas para un tipo concreto de empresa, dentro
del sector hostelero, completas y gratuitas. Pero todas estas aplicaciones tienen en
comn que son demasiado completas, unas mucho ms que otras, ya que, no solo se
encargan de control de ventas, sino tambin de salones, mesas, stock, almacenes,
proveedores, pedidos, etc. dependiendo de la aplicacin en concreto. Adems todos
deben configurar y actualizar peridicamente todos sus parmetros para su correcto
funcionamiento.
El cliente es un pub para jvenes, ubicado en Pradejn, en la provincia de La

Rioja, cuyos dueos poseen varios negocios en la hostelera, que comparten almacn y
gnero, por lo que quieren una aplicacin personalizada para el TPV del pub, mucho
ms simple y fcil de configurar que las ya existentes, y que nicamente controle las
ventas del local y los camareros que las realizan.
1.2 Objetivos
La aplicacin debe:
Ser genrica, para el TPV de cualquier pub o similar.

Ser una herramienta intuitiva y fcil de manejar.
Tener todas sus funciones diseadas para una pantalla tctil.
Mantener separados el punto de venta y el mdulo de gestin.
Controlar las ventas y el camarero que las realiza.
Hacer el cierre y balance de caja.
Crear informes y estadsticas.
4
1.3 Descripcin
El proyecto es una aplicacin genrica desarrollada para el TPV de cualquier
pub o similar, intuitiva y fcil de manejar, de forma que cualquier usuario sin
conocimientos informticos pueda utilizarlo.
La aplicacin est dividida en dos partes muy diferenciadas:
El punto de venta:
Consistente en una pantalla donde visualizar grficamente todos los productos
a la venta, agrupados por categoras (familias), donde todas las funciones deben ser
diseadas para una pantalla tctil.
Permitir:
Seleccionar el camarero que realiza la venta.

Seleccionar los productos de la venta, indicando su cantidad.
Eliminar un producto de la venta actual.
Ver el total al que asciende la venta, en todo momento.
Anular la venta actual entera.
Visualizar en pantalla los datos de la venta actual, en todo momento.
Imprimir el ticket al confirmar una venta.
Aplazar una venta y recuperarla despus.
Confirmar una venta sin imprimir ticket.
Ver una lista de las ventas aplazadas
El mdulo de gestin:
Aplicacin orientada al gerente o encargado, totalmente separado del mdulo

de venta y con acceso protegido.
Permitir:
Controlar el acceso por contrasea.

Configurar el TPV agregando, eliminando o modificando los productos y
las categoras.
Anular ventas ya confirmadas.
El cierre y balance de caja.
Informes de ventas por fechas, camareros,
Estadsticas sobre productos, familias,
5
1.4 Entregables
Documentacin de objetivos del proyecto (D. O. P.).

Documentacin del anlisis de requisitos.
Documentacin del diseo en UML.
Documentacin del diseo de la base de datos.
Memoria.
Producto final, aplicacin.
Presentacin.
1.5 Estructura de descomposicin de tareas
Conocimientos previos:
Establecer horario del proyecto: 1 hora.
Conocimiento del funcionamiento de la empresa: 1hora.
TOTAL: 2 horas.
Anlisis de requisitos iniciales:

Estudio de la empresa: 6 horas.
Anlisis de requisitos: 10 horas.
TOTAL: 16 horas.
Elaboracin del DOP:

Redactar informacin: 10 horas.
Descomposicin de tareas: 5 horas.
Asignacin del tiempo de tarea: 3 horas.
Elaborar el cuadro de mando: 3 horas.
Digitalizar informacin del DOP: 3 horas.
Revisiones de la planificacin: 10 horas.
TOTAL: 34 horas.
Memoria:
Redaccin de la memoria: 30 horas.
6
Generacin de grficos y diagramas: 30 horas.
Digitalizacin de la memoria: 10 horas.
TOTAL: 70 horas.
Seguimiento:
Reuniones con el cliente: 3 horas.
Reuniones con el tutor: 10 horas.
Levantar actas: 3horas.
TOTAL: 16 horas.
Anlisis de requisitos:
Creacin de casos de uso: 10 horas.
Anlisis de clases: 2 horas.
Anlisis de la interfaz: 2 horas.
Anlisis de pruebas: 1 hora.
Digitalizar diagramas creados: 5 horas.
TOTAL: 20 horas.
Diseo:
Crear diagramas de clases: 10 horas.
Digitalizar los diagramas creados: 5 horas.
TOTAL: 15 horas.
Diseo de la base de datos:

Diseo de la base de datos (en papel): 10 horas.
Diagrama de la base de datos (en UML): 10 horas.
Descripcin de las tablas: 10 horas.
Digitalizacin: 5 horas
TOTAL: 35 horas.
Diseo del interface:

Mdulo de seguridad: 2 horas.
Pantalla de ventas: 2 horas.
Pantalla de inicio del mdulo de gestin: 2 horas.
7
Mdulo de familias: 2 horas.
Mdulo de productos: 2 horas.
Mdulo de camareros: 2 horas.
Mdulo de ventas: 2 horas.
Mdulo de cierre de caja: 2 horas.
Mdulo de informes: 2 horas.
Mdulo de configuracin: 2 horas.
Realizacin de un prototipo: 15 horas.
TOTAL: 35 horas.
Implementacin:
Mdulo de seguridad: 20 horas.
Pantalla de ventas: 20 horas.
Pantalla de inicio del mdulo de gestin: 20 horas.
Mdulo de familias: 20 horas.
Mdulo de productos: 20 horas.
Mdulo de camareros: 20 horas.
Mdulo de ventas: 20 horas.
Mdulo de cierre de caja: 20 horas.
Mdulo de informes: 20 horas.
Mdulo de configuracin: 20 horas
Creacin de un prototipo y ajustes (si fuese necesario):40 horas.
TOTAL: 240 horas.
Pruebas:
Mdulo de seguridad: 1 hora.
Pantalla de ventas: 1 hora.
Pantalla de inicio del mdulo de gestin: 1 hora.
Mdulo de familias: 1 hora.
Mdulo de productos: 1 hora.
Mdulo de camareros: 1 hora.
Mdulo de ventas: 1 hora.
Mdulo de cierre de caja: 1 hora.
8
Mdulo de informes: 1 hora.
Mdulo de configuracin: 1 hora.
TOTAL: 10 horas.
Instalacin de la aplicacin:
Creacin de un ejecutable: 10 horas.
Instalacin en la empresa: 5 horas.
Lanzar batera de pruebas de integracin y retocar (si fuese necesario):
15 horas.
TOTAL: 30 horas.
Preparar defensa:
Crear presentacin: 20 horas.
Ensayos y revisin: 5 horas.
TOTAL: 25 horas.
En total suman 548 horas.
1.6 Plan de trabajo

Se ha creado un plan inicial de trabajo a seguir durante el desarrollo del
proyecto.
En l se recoge el tiempo estimado para cada tarea y las fechas de inicio y

finalizacin.
El siguiente diagrama de Gantt muestra el plan de trabajo elaborado:
9
octubre 2010 noviembre 2010 diciembre 2010 enero 2011 febrero 2011 marzo 2011 abril 2011
15 18 21 24 27 30 03 06 09 12 15 18 21 24 27 30 02 05 08 11 14 17 20 23 26 29 02 05 08 11 14 17 20 23 26 29 01 04 07 10 13 16 19 22 25 28 31 03 06 09 12 15 18 21 24 27 02 05 08 11 14 17 20 23 26 29 01 04 07
23/09 Conocimientos
24/09 previos
13/10 Anlisis
15/10 de Requisitos iniciales
27/09 Elaboracin del07/10

DOP
13/10 Memoria 17/03
30/09 Seguimiento 16/03
15/10 Anlisis de requisitos 02/11
03/11 Diseo 08/11
09/11 Diseo de la BD 26/11
29/11 Diseo del interface 16/12
20/12 Implementacin 15/03
16/03 Pruebas
18/03
21/03 Intalacin 28/03

10
1.7 Riesgos
Enfermedad o accidente:
En cualquiera de los 2 casos, si fuese necesario se hara una replanificacin del
proyecto.
Cambios en las especificaciones:
Segn los nuevos requisitos se procedera a una replanificacin del proyecto, en
caso de que lo ya planificado no sea consecuente con los nuevos requisitos, o a una
ampliacin posterior, en el caso contrario.
Estimaciones mal realizadas:
En caso de que sean por defecto, usaremos los das libres para cubrir las malas
estimaciones. Si fuesen por exceso, se aprovechara para adelantar trabajo en
previsin de una mala estimacin posterior.
Cambios en el horario de trabajo:
Se ha previsto este riesgo dejando una holgura a la hora de la entrega, para ajustes
finales. Y en caso de que el cambio en el horario fuera extremo, la fecha de entrega
se prolongara.
Errores de diseo:
Si hubiese algn error de diseo se documentarn los fallos y se reajustar la
planificacin de acuerdo al nuevo diseo.
Daos software:
Para solucionar posibles daos en el software se crearan varias copias de seguridad
del proyecto durante su realizacin.
Suspensin del proyecto por la empresa:
En este caso el proyecto se continuara con fines acadmicos hasta lo expuesto en
el alcance.
11
2. ANALISIS
2.1 Anlisis de requisitos
2.1.1 Identificacin de actores
Se distingue entre 3 tipos de actores:
Usuario: solo tiene acceso a la pantalla de ventas, por lo que solo podr desarrollar
los casos de uso que se apliquen en ella.
Encargado: tiene acceso tanto a la pantalla de ventas como al mdulo de gestin,
pero no al acceso como administrador, por lo que podr desarrollar todos los casos
de uso del usuario adems de los suyos propios.
Administrador: tiene acceso total a la aplicacin, y es el nico puede realizar todos
los casos de uso.
2.1.2 Identificacin de los casos de uso
Diagrama de casos de uso
12
ESPECIFICACIN DE LOS CASOS DE USO
1. Identificacin del administrador
Objetivo: Identificarse como administrador para acceder al mdulo de gestin.
Actores: Administrador(A).
Pasos:
1.A.: El caso de uso se inicia cuando el administrador abre el mdulo de gestin

de la aplicacin.
2.S.: Solicita la contrasea del encargado.
3.A.: Pulsa el enlace para el administrador.
4.S.: Muestra la pantalla de login del administrador.
5.A.: Introduce la contrasea.
6.S.: Valida la contrasea del administrador.
7.S.: Da acceso al men principal del mdulo de gestin.
Extensiones:
5.1. La contrasea introducida no es correcta.

5.1.1.S.: Muestra una ventana de error.
5.1.2.S.: Vuelve al flujo principal en el paso 4.
Diagrama de Actividad:
13
2. Cambiar contrasea administrador
Objetivo: Modificar la contrasea actual del administrador.
Actores: Administrador(A).
Precondiciones: El administrador debe haberse identificado correctamente para poder

acceder al men principal.
Pasos:
1.A.: El caso de uso se inicia cuando el administrador accede al mdulo de

seguridad.
2.S.: Muestra la pantalla de gestin de seguridad.
3.A.: Selecciona Cambiar contrasea del administrador.
4.S.: Muestra la pantalla de introduccin de la nueva contrasea.
5.A.: Introduce la nueva contrasea.
6.S.: Registra la nueva contrasea.
Diagrama de actividad:
14
3. Cambiar contrasea encargado
Objetivo: Modificar la contrasea actual del encargado, ya sea por el administrador o

por el propio encargado.
Actores: Encargado (E), y por extensin tambin el Administrador(A).
Precondiciones: El actor debe haberse identificado correctamente, bien como

encargado o bien como administrador, para haber accedido al men principal.
Pasos:
1.E.: El caso de uso se inicia cuando el encargado ( administrador) accede

al mdulo de seguridad.
2.S.: Muestra la pantalla de gestin de seguridad.
3.E.: Selecciona Cambiar contrasea del encargado.
4.S.: Muestra la pantalla de introduccin de la nueva contrasea.
5.E.: Introduce la nueva contrasea.
6.S.: Registra la nueva contrasea.
15
4. Identificacin encargado
Objetivo: Identificarse como encargado para acceder al mdulo de gestin.
Actores: Encargado (E).
Pasos:
1.E.: El caso de uso se inicia cuando el encargado abre el mdulo de gestin de la

aplicacin.
2.S.: Solicita la contrasea del encargado.
3.E.: Introduce su contrasea.
4.S.: Valida la contrasea del encargado.
5.S.: Da acceso al men principal del mdulo de gestin.
Extensiones:
3.1. La contrasea introducida no es correcta.

3.1.1.S.: Muestra una ventana de error.
16
5. Gestionar familias
Objetivo: Agregar, modificar y/o eliminar familias a la pantalla de ventas.
Actores: Encargado (E), y por extensin tambin el administrador(A).

encargado bien como administrador, para haber accedido al men principal.
Pasos:
1.E.: El caso de uso se inicia cuando el encargado ( administrador) abre el

mdulo de gestin de familias.
2.S.: Muestra el formulario de familias.
3.E.: Pulsa ver lista de familias.
4.S.: Muestra la lista de familias
5.E.: Selecciona la familia deseada y acepta.
6.S.: Muestra todos los datos de la familia seleccionada.
7.E.: Modifica los datos de la familia seleccionada.
8.S.: Registra los nuevos datos de la familia
Extensiones:
5.1. No existe la familia que buscamos y deseamos crearla.

5.1.1.E.: Pulsa el botn Volver.
5.1.2.S.: Muestra el formulario de familias.
5.1.3.E.: Introduce los datos de la nueva familia.
5.1.4.E.: Pulsa aadir para crear una nueva familia.
5.1.2 No desea crear una nueva familia
5.1.2.1.E.: Pulsa volver.
5.1.2.2.S.: Finaliza el caso de uso.
7.1. Deseamos eliminar la familia.
7.1.1.E.: Selecciona eliminar familia.
7.1.2.S.: Elimina los datos de la familia seleccionada.
7.1.3.S.: Finaliza el caso de uso.
17
18
6. Gestionar productos
Objetivo: Agregar, modificar y eliminar productos a la pantalla de ventas.

administrador bien como encargado, para haber accedido al men principal.
Pasos:

mdulo de gestin de productos.
2.E.: Muestra el formulario de productos.
3.E.: Pulsar ver lista de productos.
4.S.: Muestra lista de productos.
5.E.: Selecciona el producto deseado y acepta.
6.S.: Muestra todos los datos del producto.
7.E.: Modifica los datos del producto.
8.S.: Registra los nuevos datos del producto.
Extensiones:
5.1. No existe el producto que buscamos y desea crearlo

5.1.1.E.: Pulsa el botn Volver.
5.1.2.S.: Muestra el formulario de productos.
5.1.3.E.: Introduce los datos del nuevo producto.
5.1.4.E.: Pulsa aadir para crear un nuevo producto.
5.1.2 No desea crear un nuevo producto.
5.1.2.1.E.: Pulsa volver.
5.1.2.2.S.: Finaliza el caso de uso.
7.1. Deseamos eliminar el producto.
7.1.1.E.: Selecciona eliminar producto.
7.1.2.S.: Elimina los datos del producto seleccionado.
19
20
7. Gestionar camareros
Objetivo: Definir el nmero de camareros a poder identificar en la pantalla de ventas,

con opcin de poder aadir sus identidades.

administrador bien como encargado, para haber accedido al men principal.
Pasos:

mdulo de gestin de camareros.
2.S.: Muestra el formulario para el nmero de camareros.
3.E.: Introduce el nmero de camareros y acepta.
4.S.: Registra el nmero de camareros.
Extensiones:
4.1. Se quiere identificar a los camareros.

4.1.1.E.: Pulsa Identificar camareros.
4.1.2.S.: Muestra el formulario de identificacin de camareros.
4.1.3.E.: Introduce datos camareros y pulsa Aceptar.
4.1.4.S.: Registra datos de los camareros.
21
8. Eliminar venta confirmada
Objetivo: Eliminar o imprimir una venta que ya ha sido confirmada.

Pasos:

mdulo de gestin de ventas.
2.S.: Muestra la lista de ventas diarias.
3.E.: Selecciona la venta deseada y pulsa Eliminar.
4.S.: Muestra la ventana de seguridad.
5.E.: Acepta eliminar venta.
6.S.: Elimina la venta seleccionada.
Extensiones:
3.1. La venta no se encuentra.

3.2. Deseamos imprimir la venta.
3.2.1.E.: Selecciona la venta deseada y pulsa la opcin Imprimir.
3.2.2.S.: Volver al flujo principal en el paso 3.
22
9. Hacer cierre de caja
Objetivo: Hacer el cierre de caja del da.

encargado o bien como administrador, para haber accedido al men principal.
Pasos:

mdulo de cierre de caja.
2.S.: Muestra el total de caja en el momento actual y las opciones.
3.E.: Pulsa Cerrar caja.
4.S.: Muestra la ventana de seguridad.
5.E.: Acepta cerrar caja.
6.S.: Almacena el total de caja y lo actualiza a 0.
Extensiones:
3.1. Deseamos imprimir el cierre de caja.

3.1.1.E.: Pulsa Imprimir.
3.1.2.S.: Imprimir el comprobante del cierre de caja.
3.2. No deseamos hacer an el cierre de caja.
3.2.1.E.: Pulsa Volver.
23
10. Sacar informes
Objetivo: Obtener informes y estadsticas sobre ventas, I.V.A., productos y familias, o

listados de los componentes de familias, productos, camareros y ventas.

Pasos:
1.E.: El caso de uso se inicia cuando el encargado (o administrador) abre el

mdulo de gestin de informes.
2.S.: Muestra la pantalla con las opciones del informe que se desea.
3.E.: Pulsa la opcin del informe deseado.
4.S.: Muestra el formulario con las opciones a rellenar para el informe.
5.E.: Muestra el informe en pantalla.
Extensiones:
3.1. Deseamos obtener un listado.

3.1.1.E.: Pulsa la opcin de listados.
3.1.2.S.: Muestra la ventana de opciones de listados.
3.1.3.E.: Pulsa el listado deseado.
3.1.4.S.: Muestra las opciones del listado elegido.
3.1.5.E.: Selecciona las opciones que desea ver el listado y acepta.
24
11. Cambiar la configuracin
Objetivo: Cambiar la configuracin de la aplicacin y la apariencia de la pantalla de

ventas.
Actores: Encargado (E), y por lo tanto tambin el administrador (A).
Precondiciones: El encargado ( administrador) debe haberse identificado

correctamente para haber accedido al men principal.
Pasos:
1.E.: El caso de uso se inicia cuando el encargado ( administrador) accede al

mdulo de Configuracin.
2.S.: Muestra la pantalla con las opciones configurables.
3.E.: Selecciona la parte a configurar.
4.S.: Muestra el formulario de configuracin de la parte seleccionada.
5.E.: Modifica el formulario y pulsa Guardar cambios.
6.S.: Almacena los datos modificados.
Extensiones:
4.1. No deseamos guardar las modificaciones.

4.1.1.E.: Pulsa volver.
4.1.2.S.: Fin del caso de uso.
25
12. Crear venta
Objetivo: Crear una venta desde el inicio hasta su confirmacin, aplazamiento o

anulacin.
Actores: Usuario (U), y por extensin tambin el encargado (E) y el administrador(A).
Precondiciones: La pantalla de ventas debe estar abierta.
Pasos:
1.U.: El caso de uso se inicia cuando el usuario ( el encargado el

administrador) pulsa su tecla de identificacin como camarero.
2.U.: Selecciona una familia.
3.S.: Muestra los productos de la familia seleccionada.
4.U.: Selecciona un producto.
5.S.: Registra la lnea de venta, la muestra en la venta y modifica el total.
El usuario repite los pasos desde el 2 hasta el 5, hasta haber introducido todos
los productos de la venta.
6.U.: Confirma la venta.
7.S.: Registra la venta confirmada, muestra el total en otra ventanita.
Extensiones:
2.1. Venta de un producto no almacenado.

2.1.1.U.: Introduce el precio del producto.
2.1.2.S.: Muestra el valor introducido en la pantalla del teclado digital.
2.1.3.U.: Pulsa Aadir en el teclado digital.
2.2. Recuperar una venta aplazada.
2.2.1.U.: Selecciona botn de recuperar venta.
2.2.2.S.: Muestra en otra ventanita la lista de ventas aplazadas.
2.2.3.U.: Selecciona la venta a recuperar.
2.2.4.S.: Muestra la venta seleccionada en pantalla.
2.2.5.S.: Vuelve al flujo principal despus del paso 5.
3.1. El nmero de unidades es menor al deseado.
3.1.1.U.: Pulsa el botn + para aumentar en uno el nmero de unidades.
26
Repetir este paso las veces que sean necesarias hasta obtener el
nmero de unidades deseado.
3.2. El nmero de unidades es mayor al deseado.
3.2.1.U.: Pulsa el botn para disminuir en uno el nmero de unidades.
Repetir este paso las veces que sean necesarias hasta obtener el
nmero de unidades deseado.
5.1. Eliminar la lnea de venta.
5.1.1.U.: Selecciona la lnea de venta a eliminar y pulsa eliminar lnea.
5.1.2.S.: Eliminar el registro de lnea de venta y modifica el importe total en
pantalla.
5.1.3.S.: Vuelve al flujo principal despus del paso 5.
5.2. Aplazar venta.
5.2.1.U.: Selecciona el botn Aplazar venta.
5.2.2.S.: Registra la venta como venta aplazada.
5.3. Anular la venta completa, sin confirmar.
5.3.1.U.: Pulsar botn Anular venta.
5.3.2.S.: Elimina el registro de venta completo.
5.4. Imprimir ticket de venta.
5.4.1.U.: Pulsar Imprimir ticket.
5.4.2.S.: Imprime el ticket de venta.
27
28
2.2 Anlisis de clases
Ser necesario crear las siguientes clases, con al menos los campos que se enumeran:
Venta:
Identificador: numrico y nico para cada venta.
Camarero: clase a crear.
Fecha (incluye hora): Date.
Lista de lneas de venta: clase a crear.
IVA: numrico y con 2 decimales.
Importe: numrico y con 2 decimales.
Total: numrico y con 2 decimales.
Estado: texto.
Lnea de venta:
Producto: clase a crear.
Unidades: numrico.
Venta: clase a crear.
Total: numrico y con 2 decimales.
Producto:
Identificador: numrico y nico para cada producto.
Nombre: texto.
Familia: clase a crear.
Precio: numrico y con 2 decimales.
Imagen: texto (opcional).
Familia:
Identificador: numrico y nico para cada familia.
Nombre: texto.
Imagen: texto (opcional).
Camarero:
Identificador: texto.
Nombre: texto.
29
2.3 Anlisis de la interfaz
Debemos diferenciar entre los 2 mdulos del programa:
Pantalla de ventas:
La pantalla debera estar siempre maximizada, es decir, ocupar toda la pantalla del
ordenador y dividida en varios espacios:
Un espacio para las familias, con un botn por familia.
Un espacio para los productos, con un botn por producto, donde
mostrar todos los productos de la familia seleccionada.
Un espacio donde mostrar la venta activa, siempre visible. Con un
espacio para el total.
Un espacio para los botones de identificacin de los camareros.
Un espacio para los botones que controlan la venta activa: aplazar,
recuperar, anular venta, eliminar lnea, confirmar venta e imprimir ticket.
Un espacio para los botones que controlan los productos: nmero de
unidades, aadir unidad, disminuir unidad y aadir producto de precio directo.
Mdulo de gestin:
Las pantallas del mdulo de gestin se deben poder minimizar, maximizar y
cerrar en cualquier momento.
Despus cada men debe tener su propio diseo:
Acceso al mdulo de gestin: debe contener un cuadro de texto para

introducir la contrasea del encargado, un botn para validarla y el enlace al
acceso de administrador.
Acceso del administrador: debe contener un cuadro de texto para
introducir la contrasea del encargado, un botn para validarla.
Men principal: contendr 8 botones de acceso, uno para cada mdulo
del programa.
Mdulo de seguridad: contendr 2 botones de acceso a la pantalla de
cambio de contrasea. Pero el de cambio de contrasea de administrador no
estar siempre activo.
30
Mdulo de gestin de familias: debe contener un formulario para
introducir los datos, adems de los botones de aceptar, mostrar lista, modificar
y eliminar.
Mdulo de gestin de productos: ser similar al mdulo de gestin de
familias, pero con diferente formulario.
Mdulo de gestin de camareros: debe contener un cuadro de texto
para introducir el nmero de camareros y 2 botones, aceptar e identificar.
Mdulo de gestin de ventas: debe contener una lista con las ventas
diarias y 2 botones, eliminar e imprimir.
Mdulo de cierre de caja: debe mostrar un formulario con los datos del
balance, no modificable y 2 botones para imprimir el balance o hacer el cierre
de caja.
Mdulo de gestin de informes: debe contener 4 botones que dan
acceso cada uno a un formulario para introducir los datos del informe
seleccionado.
Mdulo de configuracin: debe contener 4 botones que dan acceso
cada uno a un formulario diferente en el que modificar la configuracin del
programa.
Varias de las pantallas descritas darn acceso a otras pantallas an sin
determinar, pero con diseo similar.
2.4 Anlisis de pruebas

Se debe hacer diferentes pruebas para cada parte de la aplicacin:
En el acceso al mdulo de gestin:

Intentar acceder como encargado con diferentes contraseas.
Intentar acceder como administrador con diferentes contraseas.
En el mdulo de seguridad:
Intentar cambiar, identificado como encargado, la contrasea del
administrador.
Cambiar, identificado como administrador, la contrasea del encargado,
y despus, intentar acceder, como encargado, con la contrasea vieja.
31
Cambiar contrasea del encargado, identificado como encargado, y
despus, intentar acceder como encargado con la contrasea vieja.
En el mdulo de gestin de familias:
Crear una familia nueva, modificarla y despus eliminarla.
En el mdulo de gestin de productos:
Crear un producto nuevo, modificarlo y eliminarlo.
En el mdulo de gestin de camareros:
Cambiar el nmero de camareros y probar a identificarlos.
En el mdulo de gestin de ventas:
Seleccionar venta, imprimirla y eliminarla.
En el mdulo de gestin de informes:
Rellenar el formulario cada formulario varias veces y con diferentes
datos y guardar e imprimir los informes resultantes.
Imprimir varios balances de caja antes de cerrar la caja.
Cerrar la caja y comprobar el nuevo balance del da.
En la pantalla de ventas:
Intentar crear una venta sin seleccionar un camarero.
Crear venta con varios productos de diferentes familias y anularla.
Crear venta con productos varios de precio directo y productos con ms
de 1 unidad y confirmarla.
Crear venta y aplazarla. Despus recuperarla y aadir ms productos.
Imprimir el ticket de venta.
Crear venta, seleccionar una lnea de venta y eliminarla. Confirmar la
venta.
32
3. DISEO
3.1 Arquitectura del sistema
En un principio el desarrollo de la aplicacin se bas en una arquitectura de 3
unidades funcionales (o capas) bien diferenciadas, cuyo esquema es:
La capa de presentacin
Se encarga de la presentacin con la que se encuentra el usuario, en nuestro caso
est formada por todas las interfaces grficas tanto de la aplicacin de gestin
como de la pantalla de ventas.
La capa de lgica de negocio
Es el ncleo del sistema en el que se realizar las operaciones y clculos necesarios
para el funcionamiento de la aplicacin. Ests formada por aquellos
procedimientos que albergan las diferentes funciones a utilizar por la aplicacin.
La capa de persistencia
Se encarga del acceso a los sistemas de almacenamiento, independizando la
aplicacin del sistema de persistencia (en nuestro caso la base de datos). Estar
formada por las funciones de acceso a la base de datos y a sus respectivas tablas.
Al continuar con el desarrollo de la aplicacin se comprob que era ms

eficiente basarse en una actualizacin (o evolucin) de esta arquitectura, la cual
mantiene las 2 primeras capas e introduce otras 3 capas ms, obteniendo as una
nueva arquitectura de 5 capas, cuyo esquema es:
33
Capa de presentacin (UI - User Interface)
Como en la arquitectura anterior, est compuesta por las interfaces grficas con las
que se encuentra el usuario final. En la aplicacin los paquetes
APlicacionGestionTPV y PantallaVentas comprenden esta capa.
Capa de lgica de negocio (BLL - Bussines Logic Layer)
Aunque mantiene el nombre de la arquitectura anterior sus funciones se reducen a
presentar una interfaz para brindar servicios a la capa de presentacin, es decir,
el intermediario entre la capa de representacin y las capas de acceso a los datos y
entidades. Comprende los paquetes Logica de ambas soluciones en la aplicacin.
Capa de acceso a los datos (DAL - Data Access Layer)
Es una porcin del cdigo que realiza justamente el acceso a los datos. De esta
manera, cuando es necesario cambiar el motor de la base de datos, solo tendremos
que corregir esta capa. En la aplicacin comprende los paquetes Persistencia de
ambas soluciones.
Capa de entidades(Domain Entity Layer)
Corresponde al dominio de la aplicacin. En ella se encuentra la declaracin de las
entidades de la aplicacin de manera que se puedan referenciar desde otras capas
sin entrar en ciclos recursivos de compilacin. Comprende el paquete
ClasesBasicas en la aplicacin.
Capa de datos (Data Tier)
Es donde estn los datos y se corresponde directamente con la definicin de
esquemas, tablas, vistas, procedimientos almacenados y todo lo que se pueda o
34
deba poner en un motor de base de datos. Equivalente a la base de datos
pubchandro en la aplicacin.
Esta arquitectura permite total independencia entre la lgica de negocios y las

entidades. Por supuesto que ambas estn relacionadas por los casos de uso y otros
requerimientos de la aplicacin.
Por otro lado, este esquema facilita la incorporacin, en la capa de acceso a

datos, de componentes ORM (Object/Relational Mapping) que permiten mapear
(representa) objetos en un esquema relacional. Esto funciona bien dado que nuestra
base de datos, al igual que la mayora de las bases de datos usadas actualmente, es
relacional.
3.2 Diseo de la interfaz

Las caractersticas deseables para la interfaz de usuario son:
Fcil de utilizar.
Intuitiva.
Segura.
Permitir deshacer una accin siempre que sea posible.
Permitir cancelar la realizacin de la accin.
Tiene que ser totalmente tctil.
Adems de esas caractersticas se debe recordar que tenemos dos partes

totalmente diferenciadas:
La pantalla de ventas.
La aplicacin de gestin.
Ambas deben cumplir las caractersticas ya citadas.
Para poder introducir los datos debemos utilizar el teclado en pantalla que nos
facilita Windows.
Diagrama de interconexin de pantallas de la Pantalla de Ventas
35
Diagrama de interconexin de pantallas de la aplicacin de gestin
Pantalla de ventas
Como vemos en la imagen anterior hay 6 zonas diferenciadas:
Zona de familias (superior derecha):
Cada botn representa una familia, pudiendo visualizar ms familias pulsando

las teclas de desplazamiento (<< y >>).
36
Al pulsar en una familia, si hay un camarero seleccionado, la zona de productos
mostrar los productos asociados a la familia seleccionada.
Zona de productos (central derecha):
Cada botn representa un producto, pudiendo visualizar ms productos

pulsando las teclas de desplazamiento (<< y >>).
Al pulsar en un producto, si hay un camarero seleccionado, se escribe una

nueva lnea de producto en la zona de venta, y aade el precio de la lnea de venta al
total.
Zona de camareros (superior izquierda):
Cada botn representa un camarero pudiendo visualizar ms camareros

pulsando las teclas de desplazamiento (<< y >>).
Al pulsar un camarero, si no hay ya ninguno seleccionado, se selecciona el

camarero que inicia la venta.
Zona de venta (central izquierda):
Muestra los productos aadidos a la venta, en lneas de venta, que se pueden

seleccionar, para ser eliminada.
Adems tambin muestra el total de la venta.
Zona del teclado numrico:
Solo se activa cuando hay un camarero seleccionado y su funcionamiento es

similar al de una calculadora, se marca el precio deseado y al pulsar aadir se muestra
una nueva lnea de producto en la zona de venta, con el producto varios.
Tambin sirve para modificar el nmero de unidades del producto a aadir

seleccionando la pantallita de unidades y despus pulsando el valor deseado.
Zona de botones:(inferior derecha):
Contiene una pantallita con el nmero de unidades y 8 botones, cada uno con
una funcin propia:
Aplazar: aplaza la venta actual, mostrando el total.
Recuperar: si no hay venta actual y se ha seleccionado un camarero, muestra la

lista de ventas aplazadas.
Anular: anula la venta actual.
37
Eliminar lnea: si hay una lnea de producto seleccionada, la elimina y reduce su
precio del total.
Aceptar: confirma la venta y muestra el total.
Imprimir ticket: confirma la venta, muestra el total y manda la impresin del

ticket de venta.
Botn +: aumenta en 1 el nmero de unidades.
Botn - : disminuye en 1 el nmero de unidades, pero nunca baja de 1.
Ventana total
No se puede modificar y basta pulsar sobre ella para que se cierre.
Pantalla de inicio de la aplicacin
Tiene 2 botones:
Aceptar: que validar la contrasea dando o no paso al men principal.
38
Salir: que cierra la aplicacin.
Adems de un enlace Administrador, que lleva a la pantalla de identificacin

del administrador...
Pantalla de identificacin del administrador
Similar a la anterior pero con un botn para volver a la pantalla anterior, la

pantalla de inicio y sin el enlace que da acceso a ella.
Pantalla del men principal
Dispone de 9 botones:
Gestin de Seguridad: da acceso al mdulo de seguridad.
Gestin de Familias: da acceso al mdulo de familias.
Gestin de Productos: da acceso al mdulo de productos.
Gestin de Camareros: da acceso al mdulo de camareros.
Gestin de Ventas: da acceso al mdulo de ventas.
Cierre de Caja: da acceso al mdulo de cierre de caja.
Gestin de Informes: da acceso al mdulo de informes y estadsticas.
39
Configuracin: da acceso al mdulo de configuracin de la aplicacin.
Volver: vuelve a la ventana anterior, la pantalla de acceso a la aplicacin.
Pantalla principal del mdulo de gestin seguridad
Muestra 2 botones de acceso a la pantalla de cambio de contrasea. El

referente al encargado, siempre activado, y el referente al administrador, solo activado
cuando el usuario se haya identificado como administrador.
Adems tambin dispone del botn para volver a la pantalla del men
principal.
Pantalla de cambio de contrasea
40
Contiene 2 cuadros de texto, para introducir la nueva contrasea, y 2 botones:
uno para guardarla y otro para volver a la pantalla principal del mdulo de seguridad.
Pantalla principal del mdulo de gestin de familias
Adems del formulario para creacin o modificacin de una familia, contiene

varios botones:
Lupa: abre una lista de familias ya existentes.
Examinar: abre el cuadro de dilogo para buscar un archivo.
Aadir: muestra una pantalla de seguridad informando de la familia se ha

creado.
Modificar: permite guardar los cambios realizados. Mostrar una pantalla de

seguridad que pregunte si desea guardar los cambios.
Eliminar: permite eliminar permanentemente una familia. Mostrar un mensaje

de seguridad que pregunte si desee eliminarla permanentemente.
Volver: permite volver al men principal.
Pantalla de listado
Aparece al pulsar cualquiera de los botones lupa de los mdulos de familias y

productos.
41
Dispone de un listado cuyos elementos son seleccionables, un botn para
volver al formulario sin seleccionar ninguno y si el listado supera los 8 elementos una
barra de scroll para ver el listado completo.
Pantalla principal del mdulo de gestin de productos
La pantalla es similar a la de gestin de familias, aunque con diferente

formulario, y adems incluye otro botn lupa para ver una lista de los productos ya
existentes.
42
Pantalla principal del mdulo de gestin de camareros
La pantalla contiene un cuadro de texto donde introducir el nmero de

camareros a mostrar en la pantalla de ventas, adems de 3 botones:
Identificar camareros: que da acceso a la pantalla de identificacin de

camareros.
Aceptar: que guarda los cambios y vuelve a men principal.
Volver: que vuelve al men principal sin guardar los cambios.
Pantalla de identificacin de camareros
Muestra una lista con el nmero de elementos igual nmero de camareros,

seleccionables y modificables, adems de 2 botones:
Volver: que vuelve a la pantalla principal del mdulo de gestin de camareros

sin guardar los cambios.
Aceptar: que guarda los cambios y despus vuelve a la pantalla principal del
mdulo de gestin de camareros.
43
Pantalla principal del mdulo de gestin de ventas
Muestra una lista con las ventas diarias, seleccionables, y 3 botones:
Volver: vuelve al men principal.
Imprimir: imprime un ticket de venta en la impresora especificada en la

ventana de configuracin del ticket de venta con los datos de la venta seleccionada.
44
Eliminar: muestra un mensaje de seguridad que pregunta si est seguro de
eliminarla.
Pantalla principal del mdulo de cierre de caja
Muestra en un cuadro de texto, no modificable, el balance de caja desde el

ltimo cierre de caja hasta ahora, y 3 botones:
Volver: vuelve al men principal.
Imprimir: muestra en un pdf el cierre de caja listo para imprimirlo o guardarlo.
Cerrar caja: realiza el cierre de caja, pasa las ventas diarias al histrico dejando
el balance a 0 y muestra el cierre de caja en un pdf listo para imprimirlo o guardarlo en
un archivo.
Pantalla principal del mdulo de gestin de informes
Contiene 6 botones, los cuatro primeros dan acceso al formulario del informe
seleccionado, el quinto, a la pantalla del men de listados y el sexto permite volver al
men principal.
45
Pantalla del formulario de informe de ventas
La pantalla contiene unos cuadros de texto para introducir las fechas inicial y
final del informe, 2 casillas seleccionables para tomar las fechas iniciales y finales del
46
programa, un listado donde se muestran los camareros candidatos seleccionables, y
otro donde se muestren los ya seleccionados, y 5 botones:
Eliminar: al pulsarlo muestra la misma pantalla eliminando el camarero

seleccionado del listado de los ya seleccionados y lo muestra en el de candidatos.
Seleccionar: al pulsarlo muestra la pantalla igual pero aade los camareros

seleccionados al listado de los seleccionados, eliminndolos del listado de candidatos.
Todos: al pulsarlo muestra a todos los camareros en el listado camareros

seleccionados y los elimina del de candidatos.
Aceptar: muestra el resultado del informe en un pdf listo para imprimir o

guardar en un archivo.
Volver: vuelve a la pantalla principal de gestin de informes.
Pantalla del formulario de informe de familias
Su funcionamiento es igual a la pantalla anterior, pero en el listado ahora se

mostrarn las familias.
47
Pantalla del formulario de informe de productos
Su funcionamiento es igual a las 2 pantallas anteriores, pero en el listado ahora

se mostrarn los productos.
Pantalla del formulario de informe de I.V.A.
48
Contiene unos cuadros de texto donde introducir las fechas inicial y final y 2
botones:
Aceptar: muestra el informe en un pdf, listo para imprimir o guardar en un

archivo, si las fechas son correctas o un mensaje de error, si son errneas.
Volver: vuelve a la pantalla principal de gestin de informes.
Pantalla del men de listados
Contiene 5 botones y, excepto Volver y Camareros, todos llevan a un nuevo

formulario con las opciones a mostrar en el listado elegido.
El botn Volver lleva a la pantalla principal del mdulo de gestin de informes

y el botn Camareros muestra directamente un pdf con el listado de camareros, listo
para imprimir o guardar en un archivo.
Pantalla del formulario de opciones para el listado de familias
Muestra las opciones a mostrar en el listado, el botn Volver que lleva a la

pantalla del men de listados y el botn Aceptar que muestra en un pdf el listado de
familias, listo para imprimir o guardar en un archivo.
49
Pantalla del formulario de opciones para el listado de productos
El formulario es igual al anterior, pero con las opciones aplicables al listado de

productos.
Pantalla del formulario de opciones para el listado de ventas diarias
El formulario es igual a los 2 anteriores, pero con las opciones aplicables al

listado de ventas diarias.
50
Pantalla principal del mdulo de configuracin
El formulario contiene 3 botones que llevan cada uno a su pantalla de

configuracin, segn el botn seleccionado, y un cuarto botn que lleva de vuelta al
men principal
51
Pantalla de configuracin de la apariencia del ticket de venta
Muestra el formulario de configuracin del ticket de venta y los botones para

guardar los cambios y volver a la pantalla principal del mdulo de configuracin.
Pantalla de configuracin de la apariencia del comprobante de cierre de caja
Como la pantalla anterior, muestra el formulario de configuracin del ticket de

venta y los botones para guardar los cambios y volver a la pantalla principal del
mdulo de configuracin
52
Pantalla de configuracin de la apariencia de informes y listados
Como las 2 pantallas anteriores, muestra el formulario de configuracin del

ticket de venta y los botones para guardar los cambios y volver a la pantalla principal
del mdulo de configuracin.
3.3 Diseo de las clases

Las clases a disear, segn el anlisis son: familia, producto, venta, lineaVenta y
camarero, junto con sus atributos y mtodos.
Familia
La clase Familia representa a las familias en las que clasifica a los productos a la
venta en el establecimiento.
Como atributos debe tener un identificador nico, su descripcin, una imagen

(opcional) y la lista de los productos que pertenecen a dicha familia.
Sus mtodos deben permitir crearla, obtener y modificar sus atributos y

eliminarla.
Familia
- codigo: int
- descripcion: string
- imagen: string
- productos: List<Producto>
+ Familia(int cod, string nombre, String icono): Familia
+ Familia(string nombre, string icono): Familia
53
+ Familia(int cod, string nombre): Familia
+ Familia(string nombre): Familia
+ getCodigo(): int
+ getDescripcion(): string
+ setDescripcion(string nombre): void
+ getImagen(): string
+ setImagen(string icono): void
+ getProductos(): List<Producto>
+ aadirProducto(Producto prod): void
+ eliminarProducto(Producto prod): void
+ eliminar(int codigo): void
+ numProductos(int codigo): int
+ getFamilia(int codigo): Familia
+ getFamilia(string nombre): Familia
+ estaFamilia(int codigo): Boolean
+ modificarFamilia(int codigo, string nombre, string icono): void
+ Equals(Familia f): Boolean
+ listFamilias(): List<Familia>
Producto
La clase Producto representa a cada artculo a la venta en el establecimiento.
Como atributos debe tener un identificador nico, su descripcin, la familia a la

que pertenece, una imagen (opcional) y su precio.
Sus mtodos deben permitir crearlo, obtener y modificar sus atributos y

eliminarlo.
Producto
- codigo: int
- descripcion: string
- familia: Familia
- imagen: string
- precio: decimal
+ Producto(int cod, string nombre, string icono, Familia fam, decimal pvp):
Producto
+ Producto(string nombre, string icono, Familia fam, decimal pvp): Producto
+ Producto(int cod, string nombre, string icono, Familia fam): Producto
+ Producto(string nombre, string icono, Familia fam): Producto
+ Producto(int cod, string nombre, Familia fam, decimal pvp): Producto
+ Producto(string nombre, Familia fam, decimal pvp): Producto
+ Producto(int cod, string nombre, Familia fam): Producto
+ Producto(string nombre, Familia fam): Producto
+ getCodigo(): int
+ getDescripcion(): string
+ setDescripcion(string nombre): void
54
+ getPrecio(): decimal
+ setPrecio(decimal pvp): void
+ getImagen(): string
+ setImagen(string icono): void
+ getFamilia(): Familia
+ setFamilia(Familia fam): void
+ getProducto(string nombre): Producto
+ getProducto(int codigo): Producto
+ estaProducto(int codigo): Boolean
+ Equals(Producto p): Boolean
+ aadirProducto( Producto p): Boolean
+ modificarProducto(int cod, string nom, string icono, Familia fam, decimal pvp):
void
+ productos(): List<string>
+ listProductos(): List<Producto>
Camarero
La clase Camarero representa a los empleados del establecimiento, es decir, los

usuarios finales de la pantalla de ventas.
Como atributos tiene un identificador nico y su nombre (opcional).
Sus mtodos deben permitir crear un camarero, aadirle su nombre, obtener

sus atributos y eliminarlo.
Camarero
- codigo: string
- nombre: string
+ Camarero(int num): Camarero
+ getCodigo(): string
+ getNombre(): string
+ setNombre(string nombre): void
+ eliminar(string codigo): void
+ Equals(Camarero c): Boolean
+ numCamareros(): int
+ maxCamareros(): int
+ getCamarero(string cod): Camarero
+ aadirCamarero(Camarero c): void
+ guardarCamareros(List<string> lista): void
+ camareros(): List<string>
55
LineaVenta
La clase LineaVenta representa a las lneas de artculos vendidos que

componen cada venta.
Como atributos tiene un identificador nico, el artculo a vender, las unidades

vendidas, el importe total de dicho artculo y la venta a la que pertenece.
Sus mtodos deben permitir crearla, eliminarla y obtener sus atributos, pero no
modificarlos.
LineaVenta
- codigo: int
- unidades: int
- articulo: Producto
- total: decimal
- venta: Venta
+ LineaVenta(int uni, Producto prod, Venta venta): LineaVenta
+ LineaVenta(int codigo, int uni, Producto prod, decimal tot, Venta venta):
LineaVenta
+ getCodigo(): int
+ getUnidades(): int
+ getArticulo(): Producto
+ getTotal(): decimal
+ getVenta(): Venta
+ Equals(LineaVenta lv): Boolean
+ getLineasVenta(int venta): List<LineaVenta>
Venta
La clase Venta representa cada una de las ventas realizadas por un camarero.
Como atributos tiene un identificador nico, el camarero que la crea, la fecha

de creacin, su importe (base imponible), el I.V.A. y el total de ambos, adems de las
lneas de venta y su estado.
Sus mtodos deben permitir crear una venta, aadirle o eliminarle lneas de
venta, eliminarla entera, obtener sus atributos, aplazarla y recuperarla.
Venta
- codigo: int
- camarero: Camarero
- iva: decimal
- importe: decimal
- total: decimal
- fecha: DateTime
56
- detalle: List<LineaVenta>
+ estado: char
+ Venta(int cod, Camarero cam, decimal iva, decimal base, decimal tot,
DateTime fecha) : Venta
+ Venta(Camarero cam): Venta
+ getCodigo(): int
+ getCamarero(): Camarero
+ setCamarero( Camarero cam): void
+ getIva(): decimal
+ setIva(decimal iva): void
+ getImporte(): decimal
+ setImporte(decimal base): void
+ getTotal(): decimal
+ setTotal(decimal tot): void
+ getFecha(): DateTime
+ setFecha(DateTime fecha): void
+ getDetalle(): List<LineaVenta>
+ setDetalle(List<LineaVenta> lista): void
+ aadirLinea(LineaVenta lv): void
+ eliminarLinea(LineaVenta lv):void
+ anular(int codigo): void
+ aplazar(int codigo): void
+ recuperar(Camarero cam, int codigo): Venta
+ confirmar(int codigo): void
+ ventas(): List<Ventas>
+ getVenta(int codigo): Venta
Una vez diseadas las clases nos queda explicar la relacin existente entre ellas:
Una familia puede tener 0 o varios productos, pero un producto pertenece a una
sola familia.
Un producto puede pertenecer a 0 o varias lneas de venta, pero una lnea de
venta tiene un nico producto.
Una lnea de venta pertenece a una nica venta, pero una venta puede tener una o
varias lneas de venta.
La existencia de una lnea de venta no tiene sentido si no existe su venta.
Una venta tiene un nico camarero, pero un camarero puede tener 0 o varias
ventas.
Las relaciones entre las clases sustituyen algunos de los atributos, como se
puede observar en el siguiente diagrama.
57
Diagrama de clases
58
Adems de las clases anteriores, obtenidas del anlisis, tambin estn las
necesarias para la implementacin, que son: Informes, Ticket y Usuario, junto con sus
atributos y mtodos.
Cierre
La clase representa la configuracin del comprobante de cierre.
Como atributos tiene 2 booleanos que seleccionan la aparicin de la cabecera

y el usuario, la cabecera (opcional) y la forma de representacin de la fecha.
Sus mtodos deben permitir obtener sus atributos y modificarlos.
Cierre
- cabecera: Boolean
- textoCab: string
- usuario: Boolean
- tipoFecha: string
+ Cierre(Boolean cab, string text, Boolean user, string tf): Cierre
+ getCabecera(): Boolean
+ setCabecera(Boolean cab): void
+ getTextoCab(): string
+ setTextoCab(string texto): void
+ getUsuario(): Boolean
+ setUsuario(Boolean user): void
+ getTipoFecha(): string
+ setTipoFecha(string tf): void
+ getCierre(): Cierre
+ guardarCierre(Cierre c): void
Informes
La clase representa la configuracin de los informes y listados.
Como atributos tiene un booleano que selecciona la aparicin de la cabecera y

un texto de cabecera (opcional).
Sus mtodos deben permitir obtener sus atributos y modificarlos.
Informes
- cabecera: Boolean
- textoCab: string
+ Informes(int cab, string texto): Informes
+ getCabecera():Boolean
+ setCabecera(Boolean cab): void
+ setTextoCab(string tc): void
59
+ getInformes(): Informes
+ guardarInformes(Informes i): void
Usuario
La clase representa a los diferentes usuarios de la aplicacin de gestin.
Como atributos tiene un usuario y una contrasea.
Sus mtodos deben permitir obtener la contrasea de un usuario y modificarla.
Usuario
- tipo: string
- password: string
+ getPassword(): string
+ setPassword(string p): void
+ getmodificarContrasea(string us, string p): void
Ticket
La clase representa la configuracin del ticket de venta.
Como atributos tiene 3 booleanos que seleccionan la aparicin de la cabecera,

el camarero y el pie de pgina, 3 textos: el de cabecera, el de pie de pgina y los datos
del establecimiento; el tipo de total a mostrar, el porcentaje de IVA y la impresora por
la que se imprimir.
Sus mtodos deben permitir obtener y modificar todos sus atributos.
Ticket
- cabecera: Boolean
- textoCab: string
- pie: Boolean
- textoPie: string
- camarero: Boolean
- datos: string
- tipoTotal: string
- iva: decimal
- impresora: string
+ getCabecera(): Boolean
+ setCabecera(Boolean c): void
+ setTextoCab(string texto): void
+ getPie(): Boolean
+ setPie(Boolean p): void
+ getTextoPie(): string
60
+ setTextoPie(string texto): void
+ getCamarero(): Boolean
+ setCamarero(Boolean c): void
+ getDatos(): string
+ setDatos(string d): void
+ getTipototal(): string
+ setTipoTotal(string tt): void
+ getIva():decimal
+ setIva(decimal iva): void
+ getTicket(): Ticket
+ guardarTicket(Ticket t): void
Estas nuevas clases no tienen interconexin entre ellas, ni con las anteriores.
3.4 Diseo de la base de datos
Se identificarn las necesidades de informacin de cada uno de los procesos

que conforman el sistema de informacin, con el fin de obtener un modelo de datos
que contemple todas las entidades, relaciones, atributos y reglas de negocio
necesarias para dar respuesta a dichas necesidades.
Diagrama conceptual de la base de datos
61
En base al diagrama anterior se han identificado las tablas de la base de datos
que derivan de sus clases:
FAMILIA
codigo descripcion imagen

C.P.
En la tabla Familia se usa como clave principal codigo, ya que es nico para
cada familia.
PRODUCTO
codigo descripcion imagen precio codFam

C.P. C.F.FAMILIA
En la tabla Producto se usa como clave principal codigo, que es nico para
cada producto. Y tenemos tambin una clave fornea codFam con el cdigo de la
familia a la que pertenece.
LINEAVENTA
codigo codVenta unidades total codProd

C.P. C.F.VENTA C.F.PRODUCTO
En la tabla LineaVenta la clave principal est compuesta por el cdigo de la

lnea de venta, codigo, y la clave fornea codVenta que indica el cdigo de la venta
a la que pertenece la lnea, ya que lineaVenta es una entidad dbil. Adems hay una 2
clave fornea codProd la cual indica el cdigo del producto implicado en la lnea de
venta.
VENTA
codigo iva importe total fecha codCam estado

C.P. C.F.CAMARERO
En la tabla Venta la clave principal es codigo, nico para cada producto.

Adems hay una clave fornea codCam, que indica el cdigo del camarero
que cre la venta.
CAMARERO
codigo nombre
C.P.
En la tabla camarero su clave principal ser cdigo, nico para cada

camarero.
62
Adems de las tablas derivadas de las clases tambin se debe de tener en
cuenta las derivadas del histrico:
HISTORICOVENTAS
codigo iva importe total fecha codCam estado

C.P. C.F.CAMARERO
Al igual que en la tabla venta, en la tabla historicoventas la clave principal es

codigo y tiene una clave fornea a la tabla camarero codCam.
HISTORICOLINEAVENTA
codigo codVenta unidades total codProd fecha

C.P. C.F.VENTA C.F.PRODUCTO
Al igual que en la tabla lineaVenta, la tabla historicolineaventa la clave principal

est compuesta por codigo, el cdigo de la lnea de venta y codVenta el cdigo de
la venta a la que pertenece, que en este caso estara ya en historicoventas. Y tambin
tiene una clave fornea a producto, codProd.
Y las tablas necesarias para el funcionamiento y configuracin de la aplicacin,

las cuales solo tendran una sola fila (excepto usuario que tendr 2).
USUARIO
tipo Contrasea
C.P.
La tabla usuario tiene como clave principal tipo, ya que es nico para cada
fila.
TICKET
Cabecera textCab pie textPie camarero datos iva tipoTotal impresora
La tabla ticket no tiene una clave principal, ya que consta de una sola fila, por lo
que no necesita ser indexada.
CIERRE
cabecera textCab usuario tipoFecha
La tabla cierre consta de una nica fila por lo que no necesita ser indexada, por
eso no tiene clave principal.
63
INFORMES
cabecera textCab
Al igual que las 2 tablas anteriores, la tabla informes no necesita ser indexada
porque solo contiene una sola fila, y por ello no tiene clave principal.
La base de datos no tiene atributos multivaluados, con lo cual est en 1FN, hay
una sola clave nica en cada tabla, ya est en 2FN, no hay dependencias transitivas
respecto a claves candidatas, pasando a 3FN y se han corregido todas sus anomalas
dejndola en FNB.
64
4. IMPLEMENTACIN
4.1 Tecnologas elegidas y herramientas utilizadas
Las tecnologas elegidas para el desarrollo del proyecto son:
El sistema gestor de base de datos MySQL

La eleccin de MySQL se debe a que usa bases de datos relacionales; esto
agrega velocidad y flexibilidad, y hace posible combinar datos de varias tablas
cuando se necesita consultar datos.
Para realizar dichas consultas utiliza SQL (Lenguaje Estructurado de Consulta)
que es el lenguaje ms usado y estandarizado para acceder a base de datos
relacionales.
Adems MySQL es Open Source, es decir, puede ser usado gratuitamente.
Cualquiera puede descargar el software de MySQL de internet y usarlo sin
pagar por ello. Y usa la licencia GPL (Licencia Pblica General GNU) para
definir qu es lo que se puede y no se puede hacer con el software para
diferentes situaciones.
El lenguaje de programacin C#
Considerada la solucin ms viable ya que C# es un lenguaje diseado
especficamente para la plataforma .NET (mayor integracin) y proporciona la
robustez de C y la fiabilidad de Visual Basic.
Adems se han utilizado algunas herramientas como:
Visual Studio 2005

Es un entorno de desarrollo integrado (IDE) para sistemas operativos Windows
que permite desarrollar rpidamente interfaces de usuario con el mousse,
gracias a su Cuadro de Herramientas y a su Diseador.
La plataforma .NET
La plataforma .NET dispone de multitud de utilidades, libreras y recursos que
permiten ampliar las funcionalidades de nuestras aplicaciones
Librera de datos Itextsharp
Itextsharp es una librera de .NET que nos ayuda en la creacin de documentos
en txt, rtf, doc, pdf, html y xml.
Librera de datos Ticket
Ticket es una librera libre desarrollada por los internautas para la plataforma
.NET, para facilitar la impresin de tickets en cualquier tipo de impresoras.
Pacestar UML
Aplicacin gratuita para la creacin de todo tipo de diagramas UML.
Microsoft Office Project 2007
65
Aplicacin de escritorio para la planificacin y creacin de diferentes
diagramas, utilizado para la creacin de diagramas de Gantt.
Microsoft Word 2007
Procesador de textos, utilizado para la creacin de la memoria.
MySQL Server 5.4
Para la creacin y gestin de la base de datos.
MySQL Connector Net 5.0.9 y Conector ODBC 5.1
Para conectar la aplicacin a la base de datos
MySQL Administrador 1.1
Para hacer backups (copias de seguridad) y volcados de la base de datos
durante las pruebas.
MySQL Query Browser
Para probar las consultas y controlar la introduccin de datos en la base de
datos.
PDFCreator
Software que se utiliza como una impresora virtual que simplemente utiliza
imprimir un documento para generar el pdf.
En nuestra aplicacin lo utilizamos como impresora, ya que es la forma ms
genrica de utilizar cualquier impresora.
4.2 Construccin del sistema de informacin

En esta tarea se genera tanto la preparacin del entorno de programacin
como todo el cdigo del sistema de informacin, y tambin se especificarn las
pruebas que se realizarn durante la construccin.
4.2.1 Implantacin de la base de datos
En esta tarea se crean todas las tablas del sistema gestor de base de datos, para
la construccin de la misma se ha usado MySQL Server 5.4 y MySQL Query Browser.
4.2.2 Preparacin del entorno de construccin
En este apartado se realiza la implantacin del entorno de programacin Visual

Studio 2005, lenguaje C# con las libreras necesarias para la realizacin del proyecto.
4.2.2.1 Libreras externas necesarias
Las libreras externas necesarias para la construccin del sistema de

informacin son las siguientes:
66
MySQL.Data.dll: la conexin de C# con una base de datos MySQL no tiene
libreras desarrolladas por defecto para C#, por lo tanto, he optado por incluir
en las referencias del proyecto esta librera de funciones.
ItextShap.dll: despus de documentarse sobre la creacin de reportes y
distintos documentos en el lenguaje de programacin C#, se opt por la
inclusin de esta librera, debido a que es una adaptacin de iText para C# que
sirve para crear muchos tipos de documentos de texto, incluyendo el formato
pdf.
Ticket.dll: buscando documentacin se encontraron diferentes formas de hacer
un ticket, como usar la librera anterior, Crystal Report y programas de ese tipo
para hacer reportes, que son muy lentos, entonces surgi la idea de que se
tena que imprimir directamente en la impresora para hacerlo ms rpido y
buscando informacin sobre cmo hacerlo se encontr esta librera que se
ajusta a las necesidades del proyecto y acelera el proceso de impresin de
tickets.
4.2.3 Problemas con MySQL.
Borrado y modificacin de productos y familias.

Guardar valores decimales.
Modificaciones en la identificacin y creacin de camareros.
Guardar imgenes en la base.
4.2.3.1 Borrado y modificacin de productos y familias
Uno de los mayores problemas a la hora de construir la aplicacin es el borrado de

datos. Para mantener la consistencia en la base de datos se usan claves forneas de unas
tablas a otras, por ejemplo, la tabla familia, es referenciada por la tablas producto, la tabla
producto por la tabla lineaventa,, si realizramos el borrado de una familia, se borraran
las productos asociados, y con estos las lneas de venta, dejando a medias las ventas
confirmadas.
Debido a que no es conveniente borrar lneas de venta o modificar las ventas

confirmadas realizadas anteriormente por un usuario, se ha decidido modificar la base de
datos de forma que al borrar una familia, no se borren los productos asociados, sino que
los productos pierdan esa asociacin, pero que en la base de datos sigan existiendo los
productos para poder mantener la consistencia.
Se incluye un fragmento del cdigo de la base de datos donde se muestra la

creacin de la tabla producto:
CREATE TABLE `pubchandro`.`producto` (

`codigo` int(5) NOT NULL AUTO_INCREMENT,
`descripcion` char(50) CHARACTER SET latin1 NOT NULL,
67
ìmagen` char(150) CHARACTER SET latin1 DEFAULT NULL,
`familia` int(5) DEFAULT NULL,
`precio` decimal(10,2) unsigned NOT NULL DEFAULT '0.00',
PRIMARY KEY (`codigo`),
KEY `fk_familia` (`familia`),
CONSTRAINT `producto_ibfk_1` FOREIGN KEY (`familia`) REFERENCES `familia` (`codigo`) ON
DELETE SET NULL ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=latin1 COLLATE=latin1_spanish_ci;
Lo que se hace es crear una clave fornea a familia de forma que si se modifica
familia, la modificacin vaya en cascada, es decir, que se modifique tambin en
producto, pero si se borra, dejamos la clave fornea con valor null, deshaciendo la
asociacin de ese producto con la familia, para que pueda ser borrada, pero no borre
el producto.
4.2.3.2 Guardar valores decimales en MySQL
. Uno de los mayores retos es el de decidir un tipo de datos numrico para

representar los precios y sus operaciones ya que, aunque C# y SQL tienen muchos
tipos de datos numricos en comn, sus representaciones grficas no son iguales.
Se ha decidido el tipo decimal, ya que ambos lenguajes lo reconocen, aunque

no lo representen igual grficamente. En C# el separador de decimales por defecto es
el carcter , mientras que en SQL, es ..
Hay 2 soluciones posibles:
Cambiar la configuracin regional en la aplicacin cada vez que se utilice a la

adecuada para que C# reconozca el carcter . como separador de decimales
por defecto
Reemplazar el carcter , por el carcter . al insertar nuestras variables de C#
como texto en los comandos de SQL.
Se ha optado por la 2 opcin debido a que con ella es ms fcil asegurarse que
la insercin de datos en la base de datos va a ser correcta siempre.
El siguiente cdigo es una porcin de la clase Lgica de la pantalla de ventas

que muestra la funcin crearLineaVenta donde podrn observar cmo se reemplaza ,
por . en la variable "tot" del comando para insertar la lnea de venta en la base de
datos:
public void crearLineaVenta(int uni, Producto p, int vent)

{
this.conectar();
DataSet data = new DataSet();
decimal tot = p.Precio * uni;
68
string insert = "insert into lineaventa (unidades, articulo,
total, venta) values (" + uni + ", " + p.Codigo + "," +
tot.ToString().Replace(',','.') + ", " + vent + ");";
MySqlDataAdapter adaptador = new MySqlDataAdapter(insert,
conexion);
adaptador.Fill(data);
actualizarVenta(tot,vent);
this.desconectar();
}
4.2.3.3 Modificaciones en la identificacin y creacin de camareros.
Durante la creacin de la base de datos se cre la clase camarero con 2

atributos que no podan ser nulos. Hubo muchos problemas porque la aplicacin debe
permitir crear camareros, para despus asignarles o no un nombre. La solucin fue
muy sencilla, permitir que el atributo nombre fuese nulo.
Pero en la creacin de ventas ese problema volvi, ya que la tabla ventas hace
referencia a la tabla camarero mediante una clave fornea, que al modificar o eliminar
un camarero se ve afectada. Se resolvi utilizando de nuevo la configuracin de
modificacin y borrado de claves forneas, pero esta vez dejando el valor null en
ambos casos.
El siguiente cdigo muestra una parte del script de la base de datos que incluye
la creacin de la tabla venta:
CREATE TABLE `pubchandro`.`venta` (

`codigo` int(50) NOT NULL AUTO_INCREMENT,
`camarero` char(3) DEFAULT NULL,
ìva` decimal(10,2) unsigned NOT NULL DEFAULT '0.00',
ìmporte` decimal(10,2) unsigned NOT NULL DEFAULT '0.00',
`total` decimal(10,2) unsigned NOT NULL DEFAULT '0.00',
`fecha` date DEFAULT NULL,
èstado` char(2) DEFAULT NULL,
PRIMARY KEY (`codigo`),
KEY `fk_camarero` (`camarero`),
CONSTRAINT `fk_camarero` FOREIGN KEY (`camarero`) REFERENCES `camarero`
(`codigo`) ON DELETE SET NULL ON UPDATE SET NULL
) ENGINE=InnoDB AUTO_INCREMENT=72 DEFAULT CHARSET=latin1;
4.2.3.4 Guardar imgenes en la base.
Al intentar guardar las imgenes para la pantalla de ventas en la base de datos

se observ que eran muy pesadas, por lo que adems de ocupar muchsimo espacio
ralentizaban mucho la aplicacin, por ello se opt por guardar su ubicacin absoluta,
ocupando muchsimo menos espacio en la base de datos y agilizando la aplicacin.
69
4.2.4 Problemas encontrados en la aplicacin de gestin
Cierre de caja terico o real.
Reporte de informes
4.2.4.1 Cierre de caja terico o real
A la hora de hacer crear la funcin de cierre de caja haba 2 opciones:
El cierre de caja terico, es decir, recoge todas las ventas confirmadas durante
el da actual, guardado en el campo fecha.
El cierre de caja real, es decir, todas las ventas confirmadas desde el anterior
cierre de caja hasta el momento en que se hace el cierre.
Teniendo en cuenta que la empresa en la que se quiere implanta la aplicacin

es un pub para jvenes, cuyo horario de apertura puede abarcar varios das, es decir,
comenzar en un da y terminar en otro, la opcin elegida ha sido el cierre de caja real.
Para ello se han creado 2 tablas para las venta (venta e historicoventas) y otras
2 para las lneas de venta (lineaventa e historicolineaventa), al cierre de caja todas las
ventas confirmadas guardadas en venta pasarn a historicoventas, dejando la tabla
venta lista para el nuevo cierre de caja, solo con las ventas aplazadas, lo que incluye
pasar todas las lneas de venta de esas ventas a historicolineaventa. Hay que tener
cuidado el orden en el que se realiza el paso de ventas y lneas de venta al histrico
para no perder la consistencia de la base de datos e incluso duplicar algunos datos
durante el proceso.
4.2.3.2 Reporte de informes
Otro de los problemas encontrados es la forma de mostrar los informes al

usuario, puesto que estos deben poder ser imprimidos y/o guardados. Por eso la
solucin obtenida ha sido el uso de la librera Itextsharp y la aplicacin PDFCreator
para crear documentos pdf y mostrarlos en pantalla de forma que el usuario pueda
guardarlos en un archivo y/o imprimirlos a travs de PDFCreator, descargando as a la
aplicacin de controlarlo.
Se muestra una parte del cdigo de la pantalla informe de ventas de la

aplicacin de gestin:
...Informes inf= l.getInformes();

Document documento = new Document(PageSize.A4);
PdfWriter.GetInstance(documento, new FileStream(
"informeVentas.pdf", FileMode.OpenOrCreate));
documento.Open();
//cabecera del informe
if (inf.Cabecera == true)
{
70
documento.Add(new Paragraph(inf.TextoCab));
}
// Fecha de la consulta
PdfPTable tabla = new PdfPTable(3);
tabla.DefaultCell.Border = 0;
tabla.DefaultCell.HorizontalAlignment = 2;
PdfPCell ce = new PdfPCell(new Phrase(""));
ce.Colspan = 3;
ce.Border = 0;
tabla.AddCell(ce);
tabla.AddCell(ce);
PdfPCell cell = new PdfPCell(new Phrase("Informe de Ventas"));
cell.Colspan = 3;
cell.HorizontalAlignment = 1; //0=Left, 1=Centre, 2=Right
cell.Border = 0;
tabla.AddCell(cell);
tabla.AddCell(ce);
cell.Phrase=new Phrase("Datos obtenidos entre el " +
tbDiaInicio.Text + "-" + tbMesInicial.Text + "-" + tbAoInicial.Text +
" y el " + tbDiaFinal.Text + "-" + tbMesFinal.Text + "-" +
tbAoFinal.Text);
tabla.AddCell(cell);
tabla.AddCell(ce);
tabla.AddCell(ce);
tabla.AddCell("Camarero");
tabla.AddCell("Ventas");
tabla.AddCell("Porcentaje");
//ventas totales
tabla.AddCell("Todos");
tabla.AddCell(tot.ToString("0.00") + " ");
tabla.AddCell("100,00 %");
//ventas por camarero
for (int n = 0; n < lbSeleccion.Items.Count; n++)
{
int j =
int.Parse(lbSeleccion.Items[n].ToString().Substring(1));
tabla.AddCell(j.ToString());
tabla.AddCell(totCam[j].ToString("0.00")+ " ");
tabla.AddCell(porcentaje[j].ToString("0.00") + " %");
}
documento.Add(tabla);
documento.Close();
//Abrir el informe de ventas
System.Diagnostics.Process.Start("informeVentas.pdf");....
El cdigo muestra como se crea un documento pdf, se le introducen datos,

incluso se crea una tabla para dar formato que primero se rellena con los datos para
despues aadirla al documento, despues el documento se cierra y se muestra en
pantalla, junto con todos los controles de PDFCreator, como se ve en la siguiente
imagen.
71
4.2.4 Problemas encontrados en la pantalla de ventas
Tamao de la pantalla de ventas.

Introduccin de precios directos.
Ventas aplazadas.
Imprimir tickets de venta.
4.2.4.1 Problemas encontrados en la pantalla de ventas
Al elaborar la pantalla de ventas el primer problema era el tamao (resolucin)

porque tiene que ser completamente tctil y los controles que en ella aparezcan
tienen que tener el tamao adecuado para ello.
Como documentacin se comprob la resolucin de pantalla de diferentes

TPVs y tambin la de diferentes software para TPV encontrados por internet, llegando
a la conclusin de que la mejor resolucin es 800x600px, por eso la pantalla de ventas
est optimizada para esa resolucin, pero es vlida para cualquier otra.
4.2.4.2 Introduccin de precios directos.
La pantalla de ventas tiene la opcin de introducir un precio directo mediante

el teclado numrico. El problema viene a la hora de registra la lnea de venta en la base
de datos, ya que no pertenece a ningn producto de registrado en ella.
Se ha solucionado introduciendo un producto con cdigo 1 y nombre varios,

pero con familia, imagen y precio con el valor null, que no puede ser borrado ni
modificado por los usuarios.
Tambin se han tenido que crear funciones especiales para la creacin de lneas
de venta con el producto varios, como muestra el siguiente fragmento de cdigo:
public void crearLineaVarios(int uni, decimal precio, int vent)

{
this.conectar();
string insert = "insert into lineaventa (unidades, articulo,
total, venta) values (" + uni + ", 1," +
precio.ToString().Replace(',', '.') + ", " + vent + ");";
MySqlDataAdapter adaptador = new MySqlDataAdapter(insert,
conexion);
72
adaptador.Fill(data);
actualizarVenta(precio, vent);
this.desconectar();
}
Y para la eliminacin de las lneas de venta del producto varios:
public void eliminarLineaVarios(int v, int uni, decimal precio)

{
this.conectar();
string query = "delete from lineaventa where venta= " +
v.ToString() + " and articulo =1 and total= " +
precio.ToString().Replace(',','.') + " and unidades = " +
uni.ToString() + ";";
MySqlDataAdapter adap = new MySqlDataAdapter(query, conexion);
adap.Fill(data);
actualizarVenta(-precio, v);
this.desconectar();
}
En estas funciones en lugar de pasarles como parmetro el producto se les pasa

el total de la lnea de venta, de forma que tenga todos los datos necesarios para crear
la lnea de venta o identificarla a la hora de borrarla.
4.2.4.3 Ventas aplazadas
Una peticin del cliente era poder aplazar las ventas sin confirmarlas, para
poder recuperarlas en otro momento y continuarlas.
El problema era que al cerrar la aplicacin o hacer el cierre de caja todo lo que
no estuviese almacenado en la base de datos se perda. Por eso se decidi aadir un
campo estado a la tabla venta que identificase el estado de la venta y pueda tomar
los valores ap si est aplazada, ac para la venta activa en ese momento y "null" para
las ventas confirmadas.
Al iniciar la pantalla de ventas los cdigos de todas las ventas aplazadas son
recogidos en una lista, a la que se van aadiendo los de las ventas que se vayan
aplazando, para mostrarlos junto con su total en una pequea ventana al pulsar el
botn recuperar.
4.2.4.4 Imprimir tickets de venta
Con la impresin de tickets el problema estaba en que al ser un programa

genrico no se poda especificar la impresora en la que imprimir. Se ide que haba
que imprimir directamente en el puerto, pero buscando primero en que puerto est
instalada una impresora y se busc documentacin sobre ello. Entre la documentacin
se encontr la librera Ticket.dll, la cual permita imprimir con formato de ticket,
aadirle los datos de la empresa, decirle en que impresora se desea imprimir e
imprimir, como se muestra en el siguiente cdigo:
73
public void imprimirTicket(Venta v)
{
List<LineaVenta> lisArt = getLineasVenta(v.Codigo);
ConfigTicket ct = getTicket();
Ticket ticket = new Ticket();
// Aade la cabecera si lo indica la configuracin
if (ct.Cabecera == true)
{
ticket.AddHeaderLine(ct.TextoCab);
}
// aade los datos de la empresa
ticket.AddHeaderLine(ct.Datos1);
// aade el camarero que le atiende si esta asi configurado
if (ct.Camarero == true)
{
if (v.Camarero.Nombre != "")
{
ticket.AddHeaderLine("Camarero: " + v.Camarero.Nombre);
}
else
{
ticket.AddHeaderLine("Camarero: " +
v.Camarero.Codigo.Substring(1));
}
}
// aade la fecha del ticket
ticket.AddHeaderLine(v.Fecha.ToString());
//lineas de venta
for (int i = 0; i < lisArt.Count; i++)
{
ticket.AddItem(lisArt[i].Unidades.ToString(),lisArt[i].Articulo.
Descripcion, lisArt[i].Total.ToString("0.00"));
}
// importe, iva y total
if (ct.TipoTotal == "bit")
{
ticket.AddTotal("IMPORTE", v.Importe.ToString("0.00"));
}
if (ct.TipoTotal == "bit" || ct.TipoTotal == "it")
{
ticket.AddTotal(ct.Iva.ToString() + "% IVA",
v.Iva.ToString("0.00"));
}
ticket.AddTotal("TOTAL", v.Total.ToString("0.00"));
// pie de ticket
if (ct.Pie == true)
{
ticket.AddFooterLine(ct.TextoPie);
ticket.AddFooterLine("");
}
ticket.PrintTicket(ct.Impresora);
El problema de la funcin era decirle la impresora, y se solucion aadiendo un
campo impresora a la tabla ticket de la base de datos, que se rellena desde la
74
pantalla de configuracin de la apariencia de tickets, como muestra la imagen
siguiente:
Con esto basta con poner en el cuadro de texto impresora el nombre con el que
la impresora se muestra en la carpeta impresoras del ordenador.
75
del D.O.P. el cual finalizaba en mayo del 2010.
5.1 PLANIFICACIN
5. GESTIN Y CONCLUSIONES
Al inicio del proyecto se realiz la planificacin recogida en el plan de trabajo
octubre 2010 noviembre 2010 diciembre 2010 enero 2011 febrero 2011 marzo 2011 abril 2011
18 21 24 27 30 03 06 09 12 15 18 21 24 27 30 02 05 08 11 14 17 20 23 26 29 02 05 08 11 14 17 20 23 26 29 01 04 07 10 13 16 19 22 25 28 31 03 06 09 12 15 18 21 24 27 02 05 08 11 14 17 20 23 26 29 01 04 07 10
23/09 Conocimientos
24/09 previos
13/10 Anlisis
15/10 de Requisitos iniciales
27/09 Elaboracin del07/10

DOP
13/10 Memoria 17/03
30/09 Seguimiento 16/03
15/10 Anlisis de requisitos 02/11
03/11 Diseo 08/11
09/11 Diseo de la BD 26/11
29/11 Diseo del interface 16/12
20/12 Implementacin 15/03
16/03 Pruebas
18/03
21/03 Intalacin 28/03

76
Tambin se hizo una estimacin de riesgos. Uno de los riesgos estimados era el
cambio en el horario de trabajo el cual en caso de cambio extremo de horario
consensuaba un aplazamiento de la entrega.
5.2 Aplazamientos
En este caso se ha sufrido un cambio extremo del horario de trabajo ya que
cuando se comenz el proyecto el proyectante trabajaba unas 4horas diarias de lunes
a viernes y un mnimo 10 horas al da los fines de semana, pudiendo dedicar al
proyecto 29 horas semanales, segn el siguiente cuadro de trabajo:
Hora Lunes Martes Mircoles Jueves Viernes Sbado Domingo

10:00
11:00
Proyecto Proyecto Proyecto Proyecto Proyecto
12.:00
13:00
14:00
Trabajo
15::00 Trabajo Trabajo Trabajo Trabajo Trabajo Trabajo
16.:00
17:00
Proyecto Proyecto
18:00 Proyecto
Clase Proyecto
19:00
20:00
21:00 Clase
22:00 Trabajo Trabajo Trabajo
Trabajo
Trabajo Trabajo
23:00 Trabajo
24:00
Por desgracia este cuadro de trabajo slo pudo ser seguido durante los 2
primeros meses de mitad de septiembre a mitad de noviembre del 2009, ya que
entonces se sufri un aumento en el horario de trabajo de 4 a 8 horas diarias,
reduciendo a 19 las horas de proyecto. En total se le dedicaron unas 232 horas de
trabajo al proyecto antes de modificar el horario.
3 meses despus se sufri un nuevo un aumento masivo de las horas de

trabajo por lo que el proyectante tuvo que paralizar por completo el proyecto desde
febrero del 2010 hasta septiembre del mismo ao, donde lo retomo dedicndole
apenas 8 horas semanales. Hasta aqu se dedicaron unas 228 horas ms proyecto, un
total de 460 horas.
77
Se mantuvo hasta finales de diciembre del 2010, sumando 32 horas ms al
proyecto, y despus el proyectante vuelve a tener una subida masiva de las horas de
trabajo debiendo casi aplazar el proyecto de nuevo, ya que apenas poda dedicarle 2
horas semanales hasta junio del 2011, 48 horas ms que hacen un total de 540 horas.
De nuevo en octubre del 2011 se retom el proyecto dedicndole entre 4 y 6

horas semanales, hasta marzo del 2012, 144 horas ms. Y de finales de marzo del 2012
hasta junio del 2012 se dedicaron 4 horas diarias, lo cual aade otras 360 horas ms,
haciendo un total de 1044 horas, aproximadamente ya que la determinacin de horas
no es exhaustiva.
Este es el plan de trabajo real:

octubre 2009noviembredi2009ciembre 2009enero 2010febrero 2010marzo 2010abril 2010mayo 2010junio 2010julio 2010 agosto 2010septiembreoct2010ubre 2010noviembredi2010ciembre 2010enero 2011febrero 2011marzo 2011abril 2011mayo 2011junio 2011julio 2011 agosto 2011septiembreoct2011ubre 2011noviembredi2011ciembre 2011enero 2012febrero 2012marzo 2012abril 2012mayo 2012junio 2012julio 2012
78
Frente a las 548 horas estimadas, las 1044 horas reales suponen un 190% del
tiempo estimado. El error de estimacin supone un aumento aproximado del 50% en
el total de las horas empleadas, adems de un aplazamiento de 2 aos en la fecha de
entrega.
Este es el balance final entre la estimacin realizada y el tiempo final de

dedicacin:
D.O.P
P. Anlisis Diseo Memoria Implementacin Pruebas Instalacin Total
Tiempo
Estimado 34 38 85 70 240 10 30 507
(h)
Tiempo
105 68 180 150 450 50 30 1033
Real (h)
Variacin
67,62 44,12 52,78 53,33 46,67 80 0 50,92
(%)
En el siguiente grfico podemos observar de una forma ms clara como fue esta
variacin, aunque es un valor aproximado puesto que no se contabilizaron las horas de
forma exhaustiva, si que nos puede dar una idea del tiempo que se tuvo que dedicar a
cada apartado.
500
400
300
200
100
0
Tiempo Real(h)
Tiempo Estimado (h)
Tiempo Estimado (h) Tiempo Real(h)
79
El grfico que
que se encuentra a continuacin muestra el tiempo real
dedicado a cada parte del proyecto con respecto al tiempo total.
Tiempo Real
Pruebas
5% Instalacin
3% D.O.P.
10%
Implementacin
44% Anlisis
7%
Diseo
17%
Memoria
14%
5.3 Conclusiones
En las especificaciones se peda una aplicacin genrica para el TPV de un pub,
cafetera o similar que mantenga separadas
separadas el punto de venta y la aplicacin de
gestin para lo que hemos creado 2 aplicaciones independientes: una pantalla de
ventas y una aplicacin de gestin, ambas conectadas a la misma base de datos.
Pedan una aplicacin intuitiva, fcil de manejar y diseada para pantallas

tctiles. Las nuevas aplicaciones estn diseadas para mostrar su funcionamiento de
forma intuitiva, mostrando pantallas de mens claros que dan acceso a formularios
sencillos, cuyo fcil relleno puede hacerse de forma tctil, necesitando
necesitando el teclado en
pantalla de Windows para rellenar algunos datos.
La pantalla de ventas cumple con las exigencias del cliente de crear ventas,
modificarlas, anularlas, aplazarlas y recuperarlas, mostrar la lista de ventas aplazadas,
registrar el camarero
camarero que crear la venta y mostrar en todo momento el total y las
lneas de venta. Adems permite aadir a las ventas productos de venta directa, es
decir, productos registrados como varios de los cuales introducimos el importe
manualmente, y abrir el cajn monedero.
80
La aplicacin de gestin cumple con sus cometidos de controlar el acceso por
contrasea, pero adems diferencia entre 2 tipos de usuario, el administrador y el
encargado, y puede modificar las contraseas para ambos.
Cumple con sus cometidos de modificar el TPV creando, modificando y

eliminando familias y productos.
Adems de permitir realizar el cierre de caja, se lo imprime o guarda en un

archivo pdf, y hace balances de caja, es decir, comprobantes de las ventas realizadas
hasta el momento sin cerrar la caja, permitiendo imprimirlos y guardarlos.
Tambin deba permitir anular ventas confirmadas, pero adems permite

imprimirlas.
No solo permite crear informes, estadsticas y listados, sino que pueden

imprimirse y guardarse en un archivo pdf.
Adems permite configurar el ticket de venta, incluir en el nuestros datos y

seleccionar la impresora en la que imprimirlos.
Tambin permite configurar las cabeceras de los informes, estadsticas y el

comprobante de cierre de caja, los atributos de los listados.
Y por ltimo permite incrementar o disminuir el nmero de camareros del TPV,

e identificarlos.
81
6. APENDICE 1: ACTAS DE REUNIONES
6.1 Actas de reuniones con los clientes
Primera reunin con el cliente
PROYECTO: Aplicacin de Gestin para el TPV de una Cafetera.
ACTA DE REUNIN
PRIMERA REUNIN CON EL CLIENTE: REQUERIMIENTOS DE LA APLICACION
Fecha: Lunes 26 de Octubre del 2009.
Lugar: Pub Chandro
Hora de inicio: 17:30
Hora de fin: 18:00
Asistentes:
Andrs Chandro Heras (Propietario)
Nicols Chandro Heras (Propietario)
Adela Chandro Velasco (Proyectante)

Orden del da:
Acordar los requerimientos del sistema.

Familiarizarse con la empresa.
Incidencias y decisiones adoptadas:
Se acord crear una aplicacin de gestin para el TPV del pub de su propiedad.
Se recogieron los requisitos que deba cumplir la aplicacin.
82
Se acord mostrar el prototipo para dar aceptacin.
Se acord facilitar todos los datos necesarios por parte de los propietarios para la
creacin de la aplicacin.
Se acordaron plazos de entrega y previsin de posibles atrasos.
Se acord permitir probar la aplicacin en un TPV propiedad de los propietarios.
Segunda reunin con el cliente
ACTA DE REUNIN
SEGUNDA REUNIN: PRIMERA REUNIN CON EL DIRECTOR DE MI PROYECTO
Fecha: Viernes 23 de Octubre del 2009.
Lugar: Despacho Eloy Mata Sotes, Edificio Vives.
Hora de fin: 13:00
Asistentes:
Eloy Mata Sotes (Director del Proyecto))

Orden del da:
Describir el proyecto propuesto.

Obtener las directrices para poner en marcha el proyecto.
Se decidi empezar con el D.O.P. y para ello observar varios proyectos anteriores.
Tambin se decidi comenzar con un cuaderno de proyecto y crear un horario de
trabajo.
83
Se acord una nueva cita en 15 das para la cual ya deberan estar elaborados los 3
primeros puntos del D.O.P.
Tercera reunin con el cliente
ACTA DE REUNIN
TERCERA REUNIN CON EL CLIENTE: AVISO DE RETOMA DEL PROYECTO
Fecha: Jueves 30 de Septiembre del 2010.
Lugar: Pub Chandro
Hora de fin: 17:00
Asistentes:

Orden del da:
Comunicar la retoma del proyecto.
Aceptacin de continuacin del proyecto.
Cuarta reunin con el cliente
84
ACTA DE REUNIN
CUARTA REUNIN CON EL CLIENTE: MUESTRA DEL PROTOTIPO
Fecha: Lunes 21 de Marzo del 2011.
Lugar: Pub Chandro
Hora de fin: 20:30
Asistentes:

Orden del da:
Mostrar el prototipo.
Aceptacin del prototipo para la continuacin de la implementacin.
Quinta reunin con el cliente
ACTA DE REUNIN
85
QUINTA REUNIN CON EL CLIENTE: PRUEBAS DE LA APLICACION
Fecha: Lunes 10 de Mayo del 2012.
Lugar: Bar Chandro
Hora de fin: 00:30
Asistentes:
Orden del da:
Probar la aplicacin en el hardware final.

Comprobar fallos.
Se han comprobados algunos fallos en la impresin del ticket.

Se ha acordado permitir ms pruebas cualquier da hasta el da de la entrega sin
necesidad de reunin con el propietario.
6.2 Actas de reuniones con el director del proyecto

Primera reunin con el director del proyecto
ACTA DE REUNIN
QUINTA REUNIN CON EL CLIENTE: PRUEBAS DE LA APLICACION
86
Fecha: Lunes 10 de Mayo del 2012.
Lugar: Bar Chandro
Hora de fin: 00:30
Asistentes:
Orden del da:
Probar la aplicacin en el hardware final.

Comprobar fallos.
Se han comprobados algunos fallos en la impresin del ticket.

Se ha acordado permitir ms pruebas cualquier da hasta el da de la entrega sin
necesidad de reunin con el propietario.
Segunda reunin con el director del proyecto
ACTA DE REUNIN
SEGUNDA REUNIN: PRIMERA REUNIN CON EL DIRECTOR DE MI PROYECTO
Fecha: Viernes 23 de Octubre del 2009.
87
Hora de fin: 13:00
Asistentes:

Orden del da:
Describir el proyecto propuesto.

Obtener las directrices para poner en marcha el proyecto.
Se decidi empezar con el D.O.P. y para ello observar varios proyectos anteriores.
Tambin se decidi comenzar con un cuaderno de proyecto y crear un horario de
trabajo.
Se acord una nueva cita en 15 das para la cual ya deberan estar elaborados los 3
primeros puntos del D.O.P.
Tercera reunin con el director del proyecto
ACTA DE REUNIN
TERCERA REUNIN: MUESTRA DE LOS 3 PRIMEROS APARTADOS DEL D.O.P
Fecha: Viernes 5 de Noviembre del 2009.
88
Hora de fin: 17:30
Asistentes:

Orden del da:
Revisin de los 3 primeros puntos del D.O.P.

Obtener las directrices para continuar con el proyecto.
Presentar el cuadro de trabajo al director.

Debo modificar los antecedentes para explicar en qu consiste la aplicacin.
Debo investigar sobre proyectos similares ya existentes y compararlos con el nuevo
proyecto y porqu lo quiere as el cliente.
Deb modificar solo algunos cambios en los objetivos.
Corregir el cuadro de horario del proyecto.
Cuarta reunin con el director del proyecto
ACTA DE REUNIN
CUARTA REUNIN: RETOMAR EL PROYECTO DESPUES DE APLAZARLO
Fecha: Mircoles 29 de Septiembre del 2010
89
Hora de fin: 17:30
Asistentes:

Orden del da:
Revisin de lo realizado anteriormente.

Directrices para continuar con el proyecto.
Se ha decidido modificar el tiempo asignado a cada tarea en la descomposicin de

tareas.
Se ha decidido crear estilos y formatos para usar en toda la documentacin.
Se ha decidido comenzar con la parte de anlisis de requisitos.
Queda pendiente hasta documentarse adecuadamente la eleccin de las posibles
tecnologas a utilizar
Se acuerda otra reunin para el mircoles 13 de noviembre a las 17:00.
Quinta reunin con el director del proyecto
ACTA DE REUNIN
QUINTA REUNIN: FINALIZACIN DEL D.O.P. Y MUESTRA DEL ANLISIS
Fecha: Mircoles 13 de Noviembre del 2010
90
Hora de fin: 17:30
Asistentes:

Orden del da:
Mostrar el D.O.P. terminado

Mostrar anlisis de requisitos.
Mostrar el diagrama de casos de uso.
Mostrar el anlisis de la interfaz.
Mostrar el anlisis de pruebas.
Proponer tecnologas para el desarrollo de la aplicacin.
Directrices para continuar con el proyecto.
Se deben reducir los casos de uso agrupndolos, y por ello modificar el diagrama de
casos de uso.
Se deben crear explicaciones y diagramas de actividad para los casos de uso.
Se debe cambiar el anlisis de la interfaz diferenciando entre los 2 mdulos o
aplicaciones del proyecto.
Se debe modificar el anlisis de pruebas.
Se debe continuar con el anlisis de las clases.
Se debe crear el prototipo de la aplicacin.
Sexta reunin con el director del proyecto
ACTA DE REUNIN
SEXTA REUNIN: PROTOTIPO, TECNOLOGAS Y DISEO DE LA BASE DE DATOS
91
Fecha: Jueves 17 de Marzo del 2011
Hora de fin: 19:00
Asistentes:

Orden del da:
Mostrar el prototipo
Decidir tecnologas a utilizar
Mostrar el diseo de la base de datos
Se debe modificar el formato de la documentacin.

Debo aadir el diseo de la interfaz, el diseo de la base de datos y el diseo de las
tablas de la base de datos.
Se ha decidido utilizar Visual Studio 2005 con el lenguaje C# y MySQL.
Sptima reunin con el director del proyecto
ACTA DE REUNIN
SPTIMA REUNIN: MUESTRA DE LA BASE DE DATOS Y RESOLUCION DE DUDAS
Fecha: Jueves 17 de Noviembre del 2011
92
Hora de fin: 18:30
Asistentes:

Orden del da:
Mostrar la base de datos.

Mostrar el captulo de diseo terminado.
Preguntar dudas sobre implementacin.
Queda finalizado el captulo de diseo.

Se debe corregir la base de datos para que sea menos estricta.
Se debe cambiar el formato de los datos que representan un precio.
Se poner al da la documentacin.
Se debe terminar la implementacin.
Octava reunin con el director del proyecto
ACTA DE REUNIN
OCTAVA REUNIN: MUESTRA DE LA APLICACIN Y DOCUMENTACION
Fecha: Mircoles 16 de Mayo del 2012
93
Hora de fin: 17:30
Asistentes:

Orden del da:
Mostrar la aplicacin final.

Comentar los captulos que faltan de la implementacin.
Aceptada la aplicacin final.

Se han fijado plazos para la entrega de las diferentes partes de la documentacin
por e-mail.
Se ha determinado el depsito del proyecto antes de la fecha lmite.
94

TPV (Cafetería)

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TPV (Cafetería)

Transféré par

Droits d'auteur :

Formats disponibles

TRABAJO FIN DE ESTUDIOS

PROYECTO FIN DE CARRERA

Aplicacin de gestin para el TPV de una cafetera

Adela Chandro Velasco

Tutor: Eloy Javier Mata Sots

PROYECTO FIN DE CARRERA

Ingeniera Tcnica en Informtica de Gestin

Aplicacin de gestin para el TPV de una

Alumno: Mara Adela Chandro Velasco

Existen numerosas aplicaciones similares hoy en da. Desde las desarrolladas

El cliente es un pub para jvenes, ubicado en Pradejn, en la provincia de La

Ser genrica, para el TPV de cualquier pub o similar.

La aplicacin est dividida en dos partes muy diferenciadas:

Seleccionar el camarero que realiza la venta.

Aplicacin orientada al gerente o encargado, totalmente separado del mdulo

Controlar el acceso por contrasea.

Documentacin de objetivos del proyecto (D. O. P.).

1.5 Estructura de descomposicin de tareas

Anlisis de requisitos iniciales:

Elaboracin del DOP:

Diseo de la base de datos:

Diseo del interface:

En total suman 548 horas.

1.6 Plan de trabajo

En l se recoge el tiempo estimado para cada tarea y las fechas de inicio y

El siguiente diagrama de Gantt muestra el plan de trabajo elaborado:

27/09 Elaboracin del07/10

13/10 Memoria 17/03

30/09 Seguimiento 16/03

15/10 Anlisis de requisitos 02/11

03/11 Diseo 08/11

09/11 Diseo de la BD 26/11

29/11 Diseo del interface 16/12

20/12 Implementacin 15/03

21/03 Intalacin 28/03

Se distingue entre 3 tipos de actores:

Diagrama de casos de uso

1. Identificacin del administrador

Objetivo: Identificarse como administrador para acceder al mdulo de gestin.

1.A.: El caso de uso se inicia cuando el administrador abre el mdulo de gestin

5.1. La contrasea introducida no es correcta.

Objetivo: Modificar la contrasea actual del administrador.

Precondiciones: El administrador debe haberse identificado correctamente para poder

1.A.: El caso de uso se inicia cuando el administrador accede al mdulo de

Objetivo: Modificar la contrasea actual del encargado, ya sea por el administrador o

Actores: Encargado (E), y por extensin tambin el Administrador(A).

Precondiciones: El actor debe haberse identificado correctamente, bien como

1.E.: El caso de uso se inicia cuando el encargado ( administrador) accede

Objetivo: Identificarse como encargado para acceder al mdulo de gestin.

Actores: Encargado (E).

1.E.: El caso de uso se inicia cuando el encargado abre el mdulo de gestin de la

3.1. La contrasea introducida no es correcta.

Objetivo: Agregar, modificar y/o eliminar familias a la pantalla de ventas.

Actores: Encargado (E), y por extensin tambin el administrador(A).

Precondiciones: El actor debe haberse identificado correctamente, bien como

1.E.: El caso de uso se inicia cuando el encargado ( administrador) abre el

5.1. No existe la familia que buscamos y deseamos crearla.

Objetivo: Agregar, modificar y eliminar productos a la pantalla de ventas.

Actores: Encargado (E), y por extensin tambin el administrador(A).

Precondiciones: El actor debe haberse identificado correctamente, bien como

1.E.: El caso de uso se inicia cuando el encargado ( administrador) abre el

5.1. No existe el producto que buscamos y desea crearlo

Objetivo: Definir el nmero de camareros a poder identificar en la pantalla de ventas,

Actores: Encargado (E), y por extensin tambin el administrador(A).