TRABAJO FIN DE ESTUDIOS

Transcripción

1 TRABAJO FIN DE ESTUDIOS PROYECTO FIN DECARRERA Aplicación de gestión para el TPV de una cafetería Adela Chandro Velasco Tutor: Eloy Javier Mata Sotés Curso

2 Aplicación de gestión para el TPV de una cafetería, trabajo fin de estudios de Adela Chandro Velasco, dirigido por Eloy Javier Mata Sotés (publicado por la Universidad de La Rioja), se difunde bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más 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 publicaciones@unirioja.es

3 UNIVERSIDAD DE LA RIOJA Facultad de Ciencias, Estudios Agroalimentarios e Informática PROYECTO FIN DE CARRERA Ingeniería Técnica en Informática de Gestión Aplicación de gestión para el TPV de una cafetería Alumno: María Adela Chandro Velasco Director: Eloy Mata Sotes Logroño, Junio del

4 INDICE 2 1. D. O. P Antecedentes Objetivos Descripción Entregables Estructura de descomposición de tareas Plan de trabajo Riesgos ANÁLISIS Análisis de requisitos Identificación de actores Identificación de los casos de uso Análisis de clases Análisis de la interfaz Análisis de pruebas DISEÑO Arquitectura del sistema Diseño de la interfaz Diseño de las clases Diseño de la base de datos IMPLEMENTACIÓN Tecnologías elegidas y herramientas utilizadas Construcción del sistema de información implantación de la base de datos Preparación del entorno de construcción Librerías externas necesarias Problemas con MySQL Borrado y modificación de productos y familias Guardar valores decimales en MySQL Modificaciones en la identificación y creación de camareros Guardar imágenes en la base de datos Problemas encontrados en la aplicación de gestión 70 2

5 Cierre de caja teórico o real Reporte de informes Problemas encontrados en la pantalla de ventas Tamaño de la pantalla de ventas Introducción de precios directos Ventas aplazadas Imprimir tickets de venta GESTIÓN Y CONCLUSIONES Planificación Aplazamiento Conclusiones APENDICE I: ACTAS DE REUNIONES Actas de reuniones con los clientes Actas de reuniones con el director del proyecto 86 3

6 7. D. O. P. 1.1 Antecedentes El proyecto consiste en el desarrollo de una aplicación software para el punto de venta de un pub juvenil. Existen numerosas aplicaciones similares hoy en día. Desde las desarrolladas por grandes empresas como IBM, Apple o Microsoft, muy genéricas, desarrolladas para el TPV de cualquier mediana empresa, sin importar el sector, muy completas y caras; pasando por aplicaciones menos genéricas, desarrolladas por empresas dedicadas al desarrollo de software como Consultic, One Step Rentail Solutions, SGM o TPV.NET, creadas para el TPV de cualquier pequeña o mediana empresa, de un sector concreto, también muy completas; hasta las que podemos encontrar en páginas 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 común que son demasiado completas, unas mucho más que otras, ya que, no solo se encargan de control de ventas, sino también de salones, mesas, stock, almacenes, proveedores, pedidos, etc. dependiendo de la aplicación en concreto. Además todos deben configurar y actualizar periódicamente todos sus parámetros para su correcto funcionamiento. El cliente es un pub para jóvenes, ubicado en Pradejón, en la provincia de La Rioja, cuyos dueños poseen varios negocios en la hostelería, que comparten almacén y género, por lo que quieren una aplicación personalizada para el TPV del pub, mucho más simple y fácil de configurar que las ya existentes, y que únicamente controle las ventas del local y los camareros que las realizan. 1.2 Objetivos La aplicación debe: Ser genérica, para el TPV de cualquier pub o similar. Ser una herramienta intuitiva y fácil de manejar. Tener todas sus funciones diseñadas para una pantalla táctil. Mantener separados el punto de venta y el módulo de gestión. Controlar las ventas y el camarero que las realiza. Hacer el cierre y balance de caja. Crear informes y estadísticas. 4

7 1.3 Descripción El proyecto es una aplicación genérica desarrollada para el TPV de cualquier pub o similar, intuitiva y fácil de manejar, de forma que cualquier usuario sin conocimientos informáticos pueda utilizarlo. La aplicación está dividida en dos partes muy diferenciadas: El punto de venta: Consistente en una pantalla donde visualizar gráficamente todos los productos a la venta, agrupados por categorías (familias), donde todas las funciones deben ser diseñadas para una pantalla táctil. 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 después. Confirmar una venta sin imprimir ticket. Ver una lista de las ventas aplazadas El módulo de gestión: Aplicación orientada al gerente o encargado, totalmente separado del módulo de venta y con acceso protegido. Permitirá: Controlar el acceso por contraseña. Configurar el TPV agregando, eliminando o modificando los productos y las categorías. Anular ventas ya confirmadas. El cierre y balance de caja. Informes de ventas por fechas, camareros, Estadísticas sobre productos, familias, 5

8 1.4 Entregables Documentación de objetivos del proyecto (D. O. P.). Documentación del análisis de requisitos. Documentación del diseño en UML. Documentación del diseño de la base de datos. Memoria. Producto final, aplicación. Presentación. 1.5 Estructura de descomposición de tareas Conocimientos previos: Establecer horario del proyecto: 1 hora. Conocimiento del funcionamiento de la empresa: 1hora. TOTAL: 2 horas. Análisis de requisitos iniciales: Estudio de la empresa: 6 horas. Análisis de requisitos: 10 horas. TOTAL: 16 horas. Elaboración del DOP: Redactar información: 10 horas. Descomposición de tareas: 5 horas. Asignación del tiempo de tarea: 3 horas. Elaborar el cuadro de mando: 3 horas. Digitalizar información del DOP: 3 horas. Revisiones de la planificación: 10 horas. TOTAL: 34 horas. Memoria: Redacción de la memoria: 30 horas. 6

9 Generación de gráficos y diagramas: 30 horas. Digitalización 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. Análisis de requisitos: Creación de casos de uso: 10 horas. Análisis de clases: 2 horas. Análisis de la interfaz: 2 horas. Análisis de pruebas: 1 hora. Digitalizar diagramas creados: 5 horas. TOTAL: 20 horas. Diseño: Crear diagramas de clases: 10 horas. Digitalizar los diagramas creados: 5 horas. TOTAL: 15 horas. Diseño de la base de datos: Diseño de la base de datos (en papel): 10 horas. Diagrama de la base de datos (en UML): 10 horas. Descripción de las tablas: 10 horas. Digitalización: 5 horas TOTAL: 35 horas. Diseño del interface: Módulo de seguridad: 2 horas. Pantalla de ventas: 2 horas. Pantalla de inicio del módulo de gestión: 2 horas. 7

10 Módulo de familias: 2 horas. Módulo de productos: 2 horas. Módulo de camareros: 2 horas. Módulo de ventas: 2 horas. Módulo de cierre de caja: 2 horas. Módulo de informes: 2 horas. Módulo de configuración: 2 horas. Realización de un prototipo: 15 horas. TOTAL: 35 horas. Implementación: Módulo de seguridad: 20 horas. Pantalla de ventas: 20 horas. Pantalla de inicio del módulo de gestión: 20 horas. Módulo de familias: 20 horas. Módulo de productos: 20 horas. Módulo de camareros: 20 horas. Módulo de ventas: 20 horas. Módulo de cierre de caja: 20 horas. Módulo de informes: 20 horas. Módulo de configuración: 20 horas Creación de un prototipo y ajustes (si fuese necesario):40 horas. TOTAL: 240 horas. Pruebas: Módulo de seguridad: 1 hora. Pantalla de ventas: 1 hora. Pantalla de inicio del módulo de gestión: 1 hora. Módulo de familias: 1 hora. Módulo de productos: 1 hora. Módulo de camareros: 1 hora. Módulo de ventas: 1 hora. Módulo de cierre de caja: 1 hora. 8

11 Módulo de informes: 1 hora. Módulo de configuración: 1 hora. TOTAL: 10 horas. Instalación de la aplicación: Creación de un ejecutable: 10 horas. Instalación en la empresa: 5 horas. Lanzar batería de pruebas de integración y retocar (si fuese necesario): 15 horas. TOTAL: 30 horas. Preparar defensa: Crear presentación: 20 horas. Ensayos y revisión: 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 finalización. El siguiente diagrama de Gantt muestra el plan de trabajo elaborado: 9

12 octubre 2010 noviembre 2010 diciembre 2010 enero 2011 febrero 2011 marzo 2011 abril /09 Conocimientos 24/09 previos 13/10 Análisis 15/10 de Requisitos iniciales 27/09 Elaboración del 07/10 DOP 13/10 Memoria 17/03 30/09 Seguimiento 16/03 15/10 Análisis de requisitos 02/11 03/11 Diseño 08/11 09/11 Diseño de la BD 26/11 29/11 Diseño del interface 16/12 20/12 Implementación 15/03 16/03 Pruebas 18/03 21/03 Intalación 28/03 10

13 1.7 Riesgos Enfermedad o accidente: En cualquiera de los 2 casos, si fuese necesario se haría una replanificación del proyecto. Cambios en las especificaciones: Según los nuevos requisitos se procedería a una replanificación del proyecto, en caso de que lo ya planificado no sea consecuente con los nuevos requisitos, o a una ampliación posterior, en el caso contrario. Estimaciones mal realizadas: En caso de que sean por defecto, usaremos los días libres para cubrir las malas estimaciones. Si fuesen por exceso, se aprovecharía para adelantar trabajo en previsión de una mala estimación 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 prolongaría. Errores de diseño: Si hubiese algún error de diseño se documentarán los fallos y se reajustará la planificación de acuerdo al nuevo diseño. Daños software: Para solucionar posibles daños en el software se crearan varias copias de seguridad del proyecto durante su realización. Suspensión del proyecto por la empresa: En este caso el proyecto se continuaría con fines académicos hasta lo expuesto en el alcance. 11

14 2. ANALISIS 2.1 Análisis de requisitos Identificación 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 módulo de gestión, pero no al acceso como administrador, por lo que podrá desarrollar todos los casos de uso del usuario además de los suyos propios. Administrador: tiene acceso total a la aplicación, y es el único puede realizar todos los casos de uso Identificación de los casos de uso Diagrama de casos de uso 12

15 ESPECIFICACIÓN DE LOS CASOS DE USO 1. Identificación del administrador Objetivo: Identificarse como administrador para acceder al módulo de gestión. Actores: Administrador(A). Pasos: 1.A.: El caso de uso se inicia cuando el administrador abre el módulo de gestión de la aplicación. 2.S.: Solicita la contraseña del encargado. 3.A.: Pulsa el enlace para el administrador. 4.S.: Muestra la pantalla de login del administrador. 5.A.: Introduce la contraseña. 6.S.: Valida la contraseña del administrador. 7.S.: Da acceso al menú principal del módulo de gestión. Extensiones: 5.1. La contraseña introducida no es correcta S.: Muestra una ventana de error S.: Vuelve al flujo principal en el paso 4. Diagrama de Actividad: 13

16 2. Cambiar contraseña administrador Objetivo: Modificar la contraseña 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 módulo de seguridad. 2.S.: Muestra la pantalla de gestión de seguridad. 3.A.: Selecciona Cambiar contraseña del administrador. 4.S.: Muestra la pantalla de introducción de la nueva contraseña. 5.A.: Introduce la nueva contraseña. 6.S.: Registra la nueva contraseña. Diagrama de actividad: 14

17 3. Cambiar contraseña encargado Objetivo: Modificar la contraseña actual del encargado, ya sea por el administrador o por el propio encargado. Actores: Encargado (E), y por extensión también 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 módulo de seguridad. 2.S.: Muestra la pantalla de gestión de seguridad. 3.E.: Selecciona Cambiar contraseña del encargado. 4.S.: Muestra la pantalla de introducción de la nueva contraseña. 5.E.: Introduce la nueva contraseña. 6.S.: Registra la nueva contraseña. Diagrama de actividad: 15

18 4. Identificación encargado Objetivo: Identificarse como encargado para acceder al módulo de gestión. Actores: Encargado (E). Pasos: 1.E.: El caso de uso se inicia cuando el encargado abre el módulo de gestión de la aplicación. 2.S.: Solicita la contraseña del encargado. 3.E.: Introduce su contraseña. 4.S.: Valida la contraseña del encargado. 5.S.: Da acceso al menú principal del módulo de gestión. Extensiones: 3.1. La contraseña introducida no es correcta S.: Muestra una ventana de error S.: Vuelve al flujo principal en el paso 2. Diagrama de actividad: 16

19 5. Gestionar familias Objetivo: Agregar, modificar y/o eliminar familias a la pantalla de ventas. Actores: Encargado (E), y por extensión también el administrador(a). Precondiciones: El actor debe haberse identificado correctamente, bien como 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 módulo de gestión 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 E.: Pulsa el botón Volver S.: Muestra el formulario de familias E.: Introduce los datos de la nueva familia E.: Pulsa añadir para crear una nueva familia S.: Vuelve al flujo principal en el paso No desea crear una nueva familia E.: Pulsa volver S.: Finaliza el caso de uso Deseamos eliminar la familia E.: Selecciona eliminar familia S.: Elimina los datos de la familia seleccionada S.: Finaliza el caso de uso. Diagrama de actividad: 17

20 18

21 6. Gestionar productos Objetivo: Agregar, modificar y eliminar productos a la pantalla de ventas. Actores: Encargado (E), y por extensión también el administrador(a). Precondiciones: El actor debe haberse identificado correctamente, bien como administrador ó bien como encargado, para haber accedido al menú principal. Pasos: 1.E.: El caso de uso se inicia cuando el encargado (ó administrador) abre el módulo de gestión 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 E.: Pulsa el botón Volver S.: Muestra el formulario de productos E.: Introduce los datos del nuevo producto E.: Pulsa añadir para crear un nuevo producto S.: Vuelve al flujo principal en el paso No desea crear un nuevo producto E.: Pulsa volver S.: Finaliza el caso de uso Deseamos eliminar el producto E.: Selecciona eliminar producto S.: Elimina los datos del producto seleccionado S.: Finaliza el caso de uso. Diagrama de actividad: 19

22 20

23 7. Gestionar camareros Objetivo: Definir el número de camareros a poder identificar en la pantalla de ventas, con opción de poder añadir sus identidades. Actores: Encargado (E), y por extensión también el administrador(a). Precondiciones: El actor debe haberse identificado correctamente, bien como administrador ó bien como encargado, para haber accedido al menú principal. Pasos: 1.E.: El caso de uso se inicia cuando el encargado (ó administrador) abre el módulo de gestión de camareros. 2.S.: Muestra el formulario para el número de camareros. 3.E.: Introduce el número de camareros y acepta. 4.S.: Registra el número de camareros. Extensiones: 4.1. Se quiere identificar a los camareros E.: Pulsa Identificar camareros S.: Muestra el formulario de identificación de camareros E.: Introduce datos camareros y pulsa Aceptar S.: Registra datos de los camareros S.: Finaliza el caso de uso. Diagrama de actividad: 21

24 8. Eliminar venta confirmada Objetivo: Eliminar o imprimir una venta que ya ha sido confirmada. Actores: Encargado (E), y por extensión también el administrador(a). Precondiciones: El actor debe haberse identificado correctamente, bien como 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 módulo de gestión 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 S.: Finaliza el caso de uso Deseamos imprimir la venta E.: Selecciona la venta deseada y pulsa la opción Imprimir S.: Volver al flujo principal en el paso 3. Diagrama de actividad: 22

25 9. Hacer cierre de caja Objetivo: Hacer el cierre de caja del día. Actores: Encargado (E), y por extensión también 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) abre el módulo 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 E.: Pulsa Imprimir S.: Imprimir el comprobante del cierre de caja S.: Vuelve al flujo principal en el paso No deseamos hacer aún el cierre de caja E.: Pulsa Volver S.: Finaliza el caso de uso. Diagrama de actividad: 23

26 10. Sacar informes Objetivo: Obtener informes y estadísticas sobre ventas, I.V.A., productos y familias, o listados de los componentes de familias, productos, camareros y ventas. Actores: Encargado (E), y por extensión también el administrador(a). Precondiciones: El actor debe haberse identificado correctamente, bien como encargado ó bien como administrador, para haber accedido al menú principal. Pasos: 1.E.: El caso de uso se inicia cuando el encargado (o administrador) abre el módulo de gestión de informes. 2.S.: Muestra la pantalla con las opciones del informe que se desea. 3.E.: Pulsa la opción 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 E.: Pulsa la opción de listados S.: Muestra la ventana de opciones de listados E.: Pulsa el listado deseado S.: Muestra las opciones del listado elegido E.: Selecciona las opciones que desea ver el listado y acepta S.: Vuelve al flujo principal en el paso 5. Diagrama de actividad: 24

27 11. Cambiar la configuración Objetivo: Cambiar la configuración de la aplicación y la apariencia de la pantalla de ventas. Actores: Encargado (E), y por lo tanto también 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 módulo de Configuración. 2.S.: Muestra la pantalla con las opciones configurables. 3.E.: Selecciona la parte a configurar. 4.S.: Muestra el formulario de configuración 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 E.: Pulsa volver S.: Fin del caso de uso. Diagrama de actividad: 25

28 12. Crear venta Objetivo: Crear una venta desde el inicio hasta su confirmación, aplazamiento o anulación. Actores: Usuario (U), y por extensión también 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 identificación 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 línea 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 U.: Introduce el precio del producto S.: Muestra el valor introducido en la pantalla del teclado digital U.: Pulsa Añadir en el teclado digital S.: Vuelve al flujo principal en el paso Recuperar una venta aplazada U.: Selecciona botón de recuperar venta S.: Muestra en otra ventanita la lista de ventas aplazadas U.: Selecciona la venta a recuperar S.: Muestra la venta seleccionada en pantalla S.: Vuelve al flujo principal después del paso El número de unidades es menor al deseado U.: Pulsa el botón + para aumentar en uno el número de unidades. 26

29 Repetir este paso las veces que sean necesarias hasta obtener el número de unidades deseado S.: Vuelve al flujo principal en el paso El número de unidades es mayor al deseado U.: Pulsa el botón para disminuir en uno el número de unidades. Repetir este paso las veces que sean necesarias hasta obtener el número de unidades deseado S.: Vuelve al flujo principal en el paso Eliminar la línea de venta U.: Selecciona la línea de venta a eliminar y pulsa eliminar línea S.: Eliminar el registro de línea de venta y modifica el importe total en pantalla S.: Vuelve al flujo principal después del paso Aplazar venta U.: Selecciona el botón Aplazar venta S.: Registra la venta como venta aplazada S.: Finaliza el caso de uso Anular la venta completa, sin confirmar U.: Pulsar botón Anular venta S.: Elimina el registro de venta completo S.: Finaliza el caso de uso Imprimir ticket de venta U.: Pulsar Imprimir ticket S.: Imprime el ticket de venta S.: Vuelve al flujo principal en el paso 7. Diagrama de actividad: 27

30 28

31 2.2 Análisis de clases Será necesario crear las siguientes clases, con al menos los campos que se enumeran: Venta: Identificador: numérico y único para cada venta. Camarero: clase a crear. Fecha (incluye hora): Date. Lista de líneas de venta: clase a crear. IVA: numérico y con 2 decimales. Importe: numérico y con 2 decimales. Total: numérico y con 2 decimales. Estado: texto. Línea de venta: Producto: clase a crear. Unidades: numérico. Venta: clase a crear. Total: numérico y con 2 decimales. Producto: Identificador: numérico y único para cada producto. Nombre: texto. Familia: clase a crear. Precio: numérico y con 2 decimales. Imagen: texto (opcional). Familia: Identificador: numérico y único para cada familia. Nombre: texto. Imagen: texto (opcional). Camarero: Identificador: texto. Nombre: texto. 29

32 2.3 Análisis de la interfaz Debemos diferenciar entre los 2 módulos del programa: Pantalla de ventas: La pantalla debería estar siempre maximizada, es decir, ocupar toda la pantalla del ordenador y dividida en varios espacios: Un espacio para las familias, con un botón por familia. Un espacio para los productos, con un botón 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 identificación de los camareros. Un espacio para los botones que controlan la venta activa: aplazar, recuperar, anular venta, eliminar línea, confirmar venta e imprimir ticket. Un espacio para los botones que controlan los productos: número de unidades, añadir unidad, disminuir unidad y añadir producto de precio directo. Módulo de gestión: Las pantallas del módulo de gestión se deben poder minimizar, maximizar y cerrar en cualquier momento. Después cada menú debe tener su propio diseño: Acceso al módulo de gestión: debe contener un cuadro de texto para introducir la contraseña del encargado, un botón para validarla y el enlace al acceso de administrador. Acceso del administrador: debe contener un cuadro de texto para introducir la contraseña del encargado, un botón para validarla. Menú principal: contendrá 8 botones de acceso, uno para cada módulo del programa. Módulo de seguridad: contendrá 2 botones de acceso a la pantalla de cambio de contraseña. Pero el de cambio de contraseña de administrador no estará siempre activo. 30

33 Módulo de gestión de familias: debe contener un formulario para introducir los datos, además de los botones de aceptar, mostrar lista, modificar y eliminar. Módulo de gestión de productos: será similar al módulo de gestión de familias, pero con diferente formulario. Módulo de gestión de camareros: debe contener un cuadro de texto para introducir el número de camareros y 2 botones, aceptar e identificar. Módulo de gestión de ventas: debe contener una lista con las ventas diarias y 2 botones, eliminar e imprimir. Módulo 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. Módulo de gestión de informes: debe contener 4 botones que dan acceso cada uno a un formulario para introducir los datos del informe seleccionado. Módulo de configuración: debe contener 4 botones que dan acceso cada uno a un formulario diferente en el que modificar la configuración del programa. Varias de las pantallas descritas darán acceso a otras pantallas aún sin determinar, pero con diseño similar. 2.4 Análisis de pruebas Se debe hacer diferentes pruebas para cada parte de la aplicación: En el acceso al módulo de gestión: Intentar acceder como encargado con diferentes contraseñas. Intentar acceder como administrador con diferentes contraseñas. En el módulo de seguridad: Intentar cambiar, identificado como encargado, la contraseña del administrador. Cambiar, identificado como administrador, la contraseña del encargado, y después, intentar acceder, como encargado, con la contraseña vieja. 31

34 Cambiar contraseña del encargado, identificado como encargado, y después, intentar acceder como encargado con la contraseña vieja. En el módulo de gestión de familias: Crear una familia nueva, modificarla y después eliminarla. En el módulo de gestión de productos: Crear un producto nuevo, modificarlo y eliminarlo. En el módulo de gestión de camareros: Cambiar el número de camareros y probar a identificarlos. En el módulo de gestión de ventas: Seleccionar venta, imprimirla y eliminarla. En el módulo de gestión 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 día. 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 más de 1 unidad y confirmarla. Crear venta y aplazarla. Después recuperarla y añadir más productos. Imprimir el ticket de venta. Crear venta, seleccionar una línea de venta y eliminarla. Confirmar la venta. 32

35 3. DISEÑO 3.1 Arquitectura del sistema En un principio el desarrollo de la aplicación se basó en una arquitectura de 3 unidades funcionales (o capas) bien diferenciadas, cuyo esquema es: La capa de presentación Se encarga de la presentación con la que se encuentra el usuario, en nuestro caso está formada por todas las interfaces gráficas tanto de la aplicación de gestión como de la pantalla de ventas. La capa de lógica de negocio Es el núcleo del sistema en el que se realizará las operaciones y cálculos necesarios para el funcionamiento de la aplicación. Estás formada por aquellos procedimientos que albergan las diferentes funciones a utilizar por la aplicación. La capa de persistencia Se encarga del acceso a los sistemas de almacenamiento, independizando la aplicación 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 aplicación se comprobó que era más eficiente basarse en una actualización (o evolución) de esta arquitectura, la cual mantiene las 2 primeras capas e introduce otras 3 capas más, obteniendo así una nueva arquitectura de 5 capas, cuyo esquema es: 33

36 Capa de presentación (UI - User Interface) Como en la arquitectura anterior, está compuesta por las interfaces gráficas con las que se encuentra el usuario final. En la aplicación los paquetes APlicacionGestionTPV y PantallaVentas comprenden esta capa. Capa de lógica 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 presentación, es decir, el intermediario entre la capa de representación y las capas de acceso a los datos y entidades. Comprende los paquetes Logica de ambas soluciones en la aplicación. Capa de acceso a los datos (DAL - Data Access Layer) Es una porción del código 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 aplicación comprende los paquetes Persistencia de ambas soluciones. Capa de entidades(domain Entity Layer) Corresponde al dominio de la aplicación. En ella se encuentra la declaración de las entidades de la aplicación de manera que se puedan referenciar desde otras capas sin entrar en ciclos recursivos de compilación. Comprende el paquete ClasesBasicas en la aplicación. Capa de datos (Data Tier) Es donde están los datos y se corresponde directamente con la definición de esquemas, tablas, vistas, procedimientos almacenados y todo lo que se pueda o 34

37 deba poner en un motor de base de datos. Equivalente a la base de datos pubchandro en la aplicación. Esta arquitectura permite total independencia entre la lógica de negocios y las entidades. Por supuesto que ambas están relacionadas por los casos de uso y otros requerimientos de la aplicación. Por otro lado, este esquema facilita la incorporación, 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 mayoría de las bases de datos usadas actualmente, es relacional. 3.2 Diseño de la interfaz Las características deseables para la interfaz de usuario son: Fácil de utilizar. Intuitiva. Segura. Permitir deshacer una acción siempre que sea posible. Permitir cancelar la realización de la acción. Tiene que ser totalmente táctil. Además de esas características se debe recordar que tenemos dos partes totalmente diferenciadas: La pantalla de ventas. La aplicación de gestión. Ambas deben cumplir las características ya citadas. Para poder introducir los datos debemos utilizar el teclado en pantalla que nos facilita Windows. Diagrama de interconexión de pantallas de la Pantalla de Ventas 35

38 Diagrama de interconexión de pantallas de la aplicación de gestión Pantalla de ventas Como vemos en la imagen anterior hay 6 zonas diferenciadas: Zona de familias (superior derecha): Cada botón representa una familia, pudiendo visualizar más familias pulsando las teclas de desplazamiento ( << y >> ). 36

39 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 botón representa un producto, pudiendo visualizar más productos pulsando las teclas de desplazamiento ( << y >> ). Al pulsar en un producto, si hay un camarero seleccionado, se escribe una nueva línea de producto en la zona de venta, y añade el precio de la línea de venta al total. Zona de camareros (superior izquierda): Cada botón representa un camarero pudiendo visualizar más 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 añadidos a la venta, en líneas de venta, que se pueden seleccionar, para ser eliminada. Además también muestra el total de la venta. Zona del teclado numérico: 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 añadir se muestra una nueva línea de producto en la zona de venta, con el producto varios. También sirve para modificar el número de unidades del producto a añadir seleccionando la pantallita de unidades y después pulsando el valor deseado. Zona de botones:(inferior derecha): Contiene una pantallita con el número de unidades y 8 botones, cada uno con una función 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

40 Eliminar línea: si hay una línea 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 impresión del ticket de venta. Ventana total Botón +: aumenta en 1 el número de unidades. Botón - : disminuye en 1 el número de unidades, pero nunca baja de 1. No se puede modificar y basta pulsar sobre ella para que se cierre. Pantalla de inicio de la aplicación Tiene 2 botones: Aceptar: que validará la contraseña dando o no paso al menú principal. 38

41 Salir: que cierra la aplicación. Además de un enlace Administrador, que lleva a la pantalla de identificación del administrador... Pantalla de identificación del administrador Similar a la anterior pero con un botón 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: Gestión de Seguridad: da acceso al módulo de seguridad. Gestión de Familias: da acceso al módulo de familias. Gestión de Productos: da acceso al módulo de productos. Gestión de Camareros: da acceso al módulo de camareros. Gestión de Ventas: da acceso al módulo de ventas. Cierre de Caja: da acceso al módulo de cierre de caja. Gestión de Informes: da acceso al módulo de informes y estadísticas. 39

42 Configuración: da acceso al módulo de configuración de la aplicación. Volver: vuelve a la ventana anterior, la pantalla de acceso a la aplicación. Pantalla principal del módulo de gestión seguridad Muestra 2 botones de acceso a la pantalla de cambio de contraseña. El referente al encargado, siempre activado, y el referente al administrador, solo activado cuando el usuario se haya identificado como administrador. Además también dispone del botón para volver a la pantalla del menú principal. Pantalla de cambio de contraseña 40

43 Contiene 2 cuadros de texto, para introducir la nueva contraseña, y 2 botones: uno para guardarla y otro para volver a la pantalla principal del módulo de seguridad. Pantalla principal del módulo de gestión de familias Además del formulario para creación o modificación de una familia, contiene varios botones: Lupa: abre una lista de familias ya existentes. Examinar: abre el cuadro de diálogo para buscar un archivo. Añadir: 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 módulos de familias y productos. 41

44 Dispone de un listado cuyos elementos son seleccionables, un botón 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 módulo de gestión de productos La pantalla es similar a la de gestión de familias, aunque con diferente formulario, y además incluye otro botón lupa para ver una lista de los productos ya existentes. 42

45 Pantalla principal del módulo de gestión de camareros La pantalla contiene un cuadro de texto donde introducir el número de camareros a mostrar en la pantalla de ventas, además de 3 botones: Identificar camareros: que da acceso a la pantalla de identificación de camareros. Aceptar: que guarda los cambios y vuelve a menú principal. Volver: que vuelve al menú principal sin guardar los cambios. Pantalla de identificación de camareros Muestra una lista con el número de elementos igual número de camareros, seleccionables y modificables, además de 2 botones: Volver: que vuelve a la pantalla principal del módulo de gestión de camareros sin guardar los cambios. Aceptar: que guarda los cambios y después vuelve a la pantalla principal del módulo de gestión de camareros. 43

46 Pantalla principal del módulo de gestión 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 configuración del ticket de venta con los datos de la venta seleccionada. 44

47 Eliminar: muestra un mensaje de seguridad que pregunta si está seguro de eliminarla. Pantalla principal del módulo 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 histórico 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 módulo de gestión 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

48 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

49 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 añade los camareros seleccionados al listado de los seleccionados, eliminándolos 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 gestión de informes. Pantalla del formulario de informe de familias Su funcionamiento es igual a la pantalla anterior, pero en el listado ahora se mostrarán las familias. 47

50 Pantalla del formulario de informe de productos Su funcionamiento es igual a las 2 pantallas anteriores, pero en el listado ahora se mostrarán los productos. Pantalla del formulario de informe de I.V.A. 48

51 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 erróneas. Volver: vuelve a la pantalla principal de gestión 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 botón Volver lleva a la pantalla principal del módulo de gestión de informes y el botón 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 botón Volver que lleva a la pantalla del menú de listados y el botón Aceptar que muestra en un pdf el listado de familias, listo para imprimir o guardar en un archivo. 49

52 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

53 Pantalla principal del módulo de configuración El formulario contiene 3 botones que llevan cada uno a su pantalla de configuración, según el botón seleccionado, y un cuarto botón que lleva de vuelta al menú principal 51

54 Pantalla de configuración de la apariencia del ticket de venta Muestra el formulario de configuración del ticket de venta y los botones para guardar los cambios y volver a la pantalla principal del módulo de configuración. Pantalla de configuración de la apariencia del comprobante de cierre de caja Como la pantalla anterior, muestra el formulario de configuración del ticket de venta y los botones para guardar los cambios y volver a la pantalla principal del módulo de configuración 52

55 Pantalla de configuración de la apariencia de informes y listados Como las 2 pantallas anteriores, muestra el formulario de configuración del ticket de venta y los botones para guardar los cambios y volver a la pantalla principal del módulo de configuración. 3.3 Diseño de las clases Las clases a diseñar, según el análisis son: familia, producto, venta, lineaventa y camarero, junto con sus atributos y métodos. 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 descripción, una imagen (opcional) y la lista de los productos que pertenecen a dicha familia. Sus métodos 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

56 + 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> + añadirproducto(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 artículo a la venta en el establecimiento. Como atributos debe tener un identificador único, su descripción, la familia a la que pertenece, una imagen (opcional) y su precio. Sus métodos 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

57 + getprecio(): decimal + setprecio(decimal pvp): void + getimagen(): string + setimagen(string icono): void + getfamilia(): Familia + setfamilia(familia fam): void + eliminar(int codigo): void + getproducto(string nombre): Producto + getproducto(int codigo): Producto + estaproducto(int codigo): Boolean + Equals(Producto p): Boolean + añadirproducto( 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 métodos deben permitir crear un camarero, añadirle 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 + añadircamarero(camarero c): void + guardarcamareros(list<string> lista): void + camareros(): List<string> 55

58 LineaVenta La clase LineaVenta representa a las líneas de artículos vendidos que componen cada venta. Como atributos tiene un identificador único, el artículo a vender, las unidades vendidas, el importe total de dicho artículo y la venta a la que pertenece. Sus métodos 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 + eliminar(int codigo): void + 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 creación, su importe (base imponible), el I.V.A. y el total de ambos, además de las líneas de venta y su estado. Sus métodos deben permitir crear una venta, añadirle o eliminarle líneas de venta, eliminarla entera, obtener sus atributos, aplazarla y recuperarla. Venta - codigo: int - camarero: Camarero - iva: decimal - importe: decimal - total: decimal - fecha: DateTime 56

59 - 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 + añadirlinea(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 diseñadas las clases nos queda explicar la relación 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 líneas de venta, pero una línea de venta tiene un único producto. Una línea de venta pertenece a una única venta, pero una venta puede tener una o varias líneas de venta. La existencia de una línea 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