TRABAJO FIN DE ESTUDIOS

Transcripción

1 TRABAJO FIN DE ESTUDIOS PROYECTO FIN DECARRERA Sitio web y aplicación para la gestión de una tienda de bellas artes Tania De Pedro Sáenz Tutor: Beatriz Pérez Valle Curso

2 Sitio web y aplicación para la gestión de una tienda de bellas artes, trabajo fin de estudios de Tania De Pedro Sáenz, dirigido por Beatriz Pérez Valle (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 Sitio Web y aplicación para la gestión de una tienda de Bellas Artes Alumna: Tania de Pedro Sáenz Directora: Beatriz Pérez Valle Logroño, Junio 2012

4 0. Contexto Documento de objetivos del proyecto Generalidades Antecedentes y situación actual Herramientas utilizadas Comunicación Alcance del proyecto Metodología y ciclo de vida Entregables del producto Planificación del proyecto Diagrama EDP Descomposición de tareas Diagrama de Gantt Posibles riegos y planes de acción Análisis Glosario de términos Análisis de la aplicación de escritorio Especificación de los requisitos Identificación y especificación de Casos de Uso Análisis de clases Prototipos de interfaces de usuario Análisis de la aplicación web Especificación de los requisitos Identificación y especificación de Casos de Uso Análisis de clases Prototipos de interfaces de usuario Diseño de la aplicación de escritorio Definición de la arquitectura Diseño de la base de datos Normalización Interfaces de usuario Interfaz pantalla inicio Interfaz gestión de alumnos Interfaz gestión de recibos Interfaz gestión de productos Interfaz gestión de clases Interfaz gestión de ventas Interfaz gestión de almacén Interfaz gestión de clientes Interfaz gestión de proveedores Implementación de la aplicación de escritorio

5 4.1 Capas de presentación y lógica de negocio Librerías utilizadas Métodos de validación y comprobación Fragmentos de código de interés Capa de persistencia Conexión a la BD Concurrencia Transaccionalidad Breve reseña a la implementación de la BD. Triggers Pruebas de la aplicación de escritorio Gestión real del proyecto y conclusiones Conclusiones Bibliografía Anexos Actas de reunión Manual de usuario Módulo alumnos Módulo recibos Módulo productos Módulo clases Módulo ventas Módulo almacén Módulo clientes Módulo proveedores Diseño lógico de la BD Comparación de CMS

6 0. Contexto El proyecto que se presenta se trata de un proyecto real desarrollado para la galería de Bellas Artes Pauters (Logroño). La actividad habitual de la galería consiste tanto en impartir clases de pintura como en la venta de productos. Actualmente, la galería no cuenta con ningún tipo de aplicación informática para gestionar toda la información relacionada con las ventas, alumnos y demás servicios, sino que se realiza en formato de papel, sin ninguna ayuda informática. En un principio se planteó la posibilidad de que el proyecto incluyera no sólo una aplicación de escritorio para la gestión de la galería, sino también el desarrollo de una aplicación Web desde la cual un usuario pudiera realizar compras y visualizar información de interés, como los cursos que se imparten o los productos a la venta en la tienda de la galería. Una vez desarrollada la aplicación de escritorio y habiendo realizado el análisis de la aplicación Web, puesto que se acercaba la fecha del depósito del proyecto, se decidió de mutuo acuerdo con la clienta dejar la implementación de la aplicación Web para un futuro, ya que la parte que más le urgía a la clienta era la aplicación de escritorio. Por ello, en esta memoria se incluye el desarrollo de la aplicación de escritorio y el análisis de la aplicación web. Teniendo ésto en cuenta, el objetivo principal del proyecto se ha basado en desarrollar una aplicación de escritorio que permita a la dueña de la galería gestionar sus ventas, compras y demás servicios. 1. Documento de objetivos del proyecto 1.1 Generalidades Datos del cliente: Empresa PAUTERS, con CIF J con domicilio en el Parque San Adrián nº 5 en Logroño (La Rioja), CP representada por Dª Paulina Sáenz Ortega. Proyectante: Dª Tania de Pedro Sáenz con N.I.F C alumna de la Universidad de La Rioja presenta el siguiente proyecto como Proyecto Fin de Carrera de Ingeniería Técnica en Informática de Gestión. Tutora del proyecto: Dª Beatriz Pérez Valle profesora de la Universidad de La Rioja. 4

7 1.2 Antecedentes y situación actual La empresa Pauters es una tienda/galería de Bellas Artes que actualmente lleva a cabo prácticamente todas las gestiones en formato de papel. Para realizar una mejor gestión de la galería, el cliente ha solicitado desarrollar una aplicación de escritorio que permita realizar todas las gestiones referentes a los alumnos, recibos, productos, clases que se imparten, ventas realizadas, pedidos, proveedores y clientes. Además, el cliente ha planteado la posibilidad de desarrollar, si es posible, una aplicación Web para lograr una mejor venta al público de sus productos, así como permitir a los clientes realizar pedidos vía Web y solicitudes de admisión a clases. Todo ello con el objetivo de lograr una mayor satisfacción al cliente. Se quiere señalar la particularidad de que la galería de arte pertenece a la familia de la proyectante, hecho que favorece la comunicación entre clienteproyectante. 1.3 Herramientas utilizadas Para el desarrollo del presente proyecto se utilizarán diversas herramientas: Poseidon para la realización de diagramas UML. MySQL para la implementación de la Base de Datos. Herramientas ofimáticas para la elaboración de la presente documentación. NetBeans para la aplicación de escritorio. Microsoft Project para la realización de diagramas de Gantt. 1.4 Comunicación Como se ha comentado anteriormente, gracias a la relación familiar con el cliente, la comunicación se realizará personalmente mediante reuniones frecuentes. Por ello, el cliente estará al tanto de cada paso llevado a cabo en el proyecto, asegurándose de que se imponen los requisitos establecidos por él mismo. Se espera que dicha relación permita avanzar más rápido en determinadas tareas. Se realizarán reuniones periódicas mediante correos electrónicos y de forma personal, con la directora Beatriz Pérez Valle. 5

8 1.5 Alcance del proyecto A petición del cliente, se desarrollará una aplicación de escritorio y si es posible una aplicación Web. Aplicación de escritorio Por deseo del cliente la aplicación de escritorio tendrá un único rol que llamaremos Administrador. Las funcionalidades de la aplicación se han agrupado en función de los elementos que debe gestionar la dueña de la galería adelantados en el apartado 1.2, a los que llamaremos módulos. En particular, hemos considerado los siguientes: alumnos, recibos, productos, clases, ventas, almacén, clientes y proveedores. A continuación, pasaremos a describir cada uno de ellos. Gestión de alumnos: Se deberán gestionar los alumnos que asisten a clases en la tienda. El administrador de la aplicación será el encargado de: Dar de alta un alumno. Dar de baja un alumno. Modificar datos de un alumno. Consultar información de un alumno. Activar viejos alumnos. Gestión de recibos: Se deberán gestionar los recibos de los alumnos. El administrador podrá: Crear un nuevo recibo. Borrar un recibo. Modificar un recibo. Consultar un recibo. Gestión de clases: Se deberán gestionar las clases que se imparten en la tienda. Las tareas que podrá realizar el administrador mediante el siguiente módulo son: Alta de un curso. Eliminar un curso. Modificar datos de un curso. Consultar información sobre un curso. 6

9 Gestión de ventas: Se deberán gestionar las ventas que se realizan en la tienda. Para ello el administrador podrá: Introducir una venta. Borrar una venta. Consultar datos de una venta. Modificar características de una venta. Introducir un nuevo encargo. Borrar un encargo. Consultar datos de un encargo. Modificar características de un encargo. Generar informes de ventas. Gestión de almacén: Se deberán gestionar los pedidos realizados a proveedores por parte de la tienda. Por mediación de este módulo el administrador será el encargado de: Introducir un nuevo pedido. Borrar pedido. Modificar información de un pedido. Consultar información de un pedido. Gestión de clientes: Se deberán gestionar algunos de los clientes de la tienda. El administrador podrá: Dar de alta un nuevo cliente. Borrar un cliente. Modificar datos de un cliente. Consultar información sobre un cliente. Gestión de proveedores: Se deberán gestionar los proveedores de la tienda. El administrador podrá: Dar de alta un nuevo proveedor. Borrar un proveedor. Modificar datos de un proveedor. Consultar información sobre un proveedor. 7

10 Aplicación web Por deseo del cliente la aplicación Web contará con tres diferentes tipos de rol: visitante, alumno y cliente, que se detallan a continuación: El rol visitante es aquel usuario no identificable que contará con los privilegios mínimos. En cuanto al rol alumno, es un usuario de la aplicación que está o ha estado matriculado en alguna clase. En particular, tendrá privilegios específicos en lo que se refiere a la visualización o acceso a información específica de las clases en las que está o ha estado matriculado. Por último, el rol cliente, será aquel usuario que ha realizado o realiza una compra a través de la aplicación Web. Tendrá ciertos privilegios referentes al módulo tienda. Los roles alumno y cliente, deberán estar registrados y acceder a la aplicación Web para contar con los privilegios de cada uno. Cabe destacar que un usuario con rol cliente puede tener a la vez privilegios de alumno y viceversa. Esta situación se puede representar mediante el diagrama UML que mostramos en la siguiente figura (Figura 1). Figura 1: Diagrama UML roles aplicación Web Teniendo en cuenta los requisitos del cliente, podemos citar cinco tipos diferentes de módulos dedicados a consultar información general, la tienda, las clases, establecer contacto con la galería, y el acceso a la zona de registro, pudiéndose ampliar con otro módulo, la ficha personal, que será exclusiva de los roles alumno y cliente. A continuación, mostraremos una breve descripción de los módulos: 8

11 Módulo Inicio Contendrá información general sobre la galería, que podrá ser vista por los roles visitante y consecuentemente, por los roles de alumno y de cliente. Módulo Tienda Contendrá información relacionada sobre los productos puestos a la venta. Además contará con la posibilidad de permitir al usuario solicitar un producto que no se encuentre en la galería. Los tres roles tendrán acceso a los productos disponibles en la tienda, no obstante, para realizar una compra será requisito indispensable registrarse como rol cliente o identificarse como tal. Módulo Cursos Contendrá los cursos disponibles que se imparten en la galería actualmente, además se podrá solicitar información o solicitar admisión a un determinado curso. Tanto el rol visitante como el rol cliente y rol alumno, podrán acceder a dicho módulo y a sus funcionalidades. Módulo Contacto Contendrá información sobre cómo contactar con el personal de la galería. Los tres roles podrán acceder a dicho módulo. Módulo Zona de Registro Desde este módulo un usuario se podrá o bien registrar o bien acceder a la aplicación en caso de que sea usuario de la misma. Los tres roles podrán acceder a dicho módulo. Módulo Ficha Personal Sólo podrán acceder los usuarios con roles de alumno y cliente. Contendrá información personal del usuario, y según el tipo de rol, además contará con una relación de los pedidos realizados así como el estado de los mismos (en el caso de usuarios con rol de cliente), y los cursos en los que está matriculado, horarios, etc (en el caso de usuarios con rol de alumno). 9

12 1.6 Metodología y ciclo de vida Una vez estudiadas las diferentes metodologías de desarrollo del Software, no se ha decido seguir ninguna en sentido riguroso, aunque nos basaremos en Métrica 3. En cuanto al ciclo de vida, se ha seguido un ciclo de vida en cascada, el cual sigue un orden riguroso de las etapas del proceso de desarrollo software, de forma que cada etapa debe esperar a la finalización de la etapa anterior. 1.7 Entregables del producto Documento de objetivos del proyecto. Memoria del proyecto. Aplicación de escritorio. Aplicación. Manual de usuario: Documentación detallada y lo más sencilla posible para el completo entendimiento del software. Script de creación de la BD. 1.8 Planificación del proyecto Diagrama EDP Figura 2: Diagrama EDP 10

13 1.8.2 Descomposición de tareas DOP y captura de requisitos Análisis Este proyecto tiene como primer paso realizar un análisis de necesidades donde pensaremos qué es exactamente lo que se tiene que hacer. Tiempo estimado: 37 horas. Este apartado contendrá una especificación más detallada de los requisitos de las dos aplicaciones y además se incluirán diagramas de casos de uso con alguna especificación para un mejor entendimiento. Para los casos de uso más complejos se desarrollará el diagrama de actividad correspondiente. Además, se incluirá el diagrama de clases y posteriormente se crearán prototipos de posibles interfaces para las aplicaciones. Tiempo estimado: 50 horas. Diseño Se definirá la estructura básica de la que se compondrá el sistema. Se diseñará un diagrama EER y se incluirá el diseño final de las interfaces. Tiempo estimado: 70 horas. Implementación Finalmente se desarrollará la implementación de las aplicaciones y se implementará la base de datos. Tiempo estimado: 280 horas. Pruebas Se desarrollarán continuamente planes de pruebas durante el desarrollo del proyecto, con el objetivo de encontrar posibles errores y corregirlos. Tiempo estimado: 35 horas. 11

14 Documentación A medida que se vaya avanzando con cada una de las fases, se irá completando la memoria y se desarrollará un sistema de ayuda con un manual de usuario para una mayor satisfacción del cliente. Tiempo estimado: 60 horas. Implantación Se realizará tanto la implantación de la base de datos como de ambas aplicaciones para su correcto funcionamiento. Tiempo estimado: 20 horas Total: 552 horas. A continuación, se muestran los diagramas de Gantt de cada una de las fases. Para cada día se ha dedicado en un margen de 2 a 4 horas, dependiendo del tiempo disponible, debido a que la alumna disfruta de una beca en el Servicio Informático de la Universidad de La Rioja y a otras actividades. Además, al comienzo del proyecto la alumna se encuentra cursando tres asignaturas que le quedan de la carrera disminuyendo, por consecuencia, la dedicación al mismo Diagrama de Gantt DOP y captura de requisitos Figura 3: Diagrama de Gantt: Requisitos del proyecto Análisis Figura 4: Diagrama de Gantt: Análisis 12

15 Diseño Figura 5: Diagrama de Gantt: Diseño Implementación Figura 6: Diagrama de Gantt: Implementación Pruebas Figura 7: Diagrama de Gantt: Pruebas Documentación Figura 8: Diagrama de Gantt: Documentación Implantación Figura 9: Diagrama de Gantt: Implantación 13

16 1.9 Posibles riegos y planes de acción En este apartado se intentarán identificar los riesgos que podrían ocurrir en el transcurso del proyecto y se determinarán las medidas a tomar para minimizarlos. Riesgos de carácter personal. En este tipo de riesgo se pueden encontrar problemas como por ejemplo, enfermedad del alumno, problemas relacionados a la hora de repartir el tiempo con otras actividades, etc. Plan de acción: Al ser un proyecto individual, la planificación va a verse afectada inevitablemente por lo que todas las tareas posteriores al riesgo se verán afectadas y será necesario hacer una nueva planificación de las mismas. Riesgos de carácter temporal. Problemas a la hora de estimar el tiempo dedicado a cada tarea, al no poseer un horario fijo de dedicación del proyecto, o bien que se dificulte alguna tarea por alguna razón. Plan de acción: Intentar hacer un plan de trabajo que se cumpla lo máximo posible, y si alguna tarea no se ha podido realizar en el tiempo acordado, realizarla cuanto antes para que el proyecto se vea lo menos retrasado posible. Riegos de aprendizaje. En determinadas tareas, como por ejemplo, el estudio de gestores de contenidos Web, al ser algo nuevo para el proyectante se necesita una fase de aprendizaje y entendimiento. Plan de acción: Documentarse bien desde el principio y tener claro, por ejemplo, gestores de contenidos que se van a comparar y estudiar. 14

17 Riegos de satisfacción. El producto final puede que no sea del agrado del cliente o del tutor. Plan de acción: Reuniones periódicas con el tutor y con el cliente para comentar, tanto el trabajo realizado hasta el momento, como las posibles dudas que le hayan podido surgir a la alumna. Riegos de viabilidad. En el desarrollo del proyecto nos encontramos ante algún tipo de problema que nos impide continuar. Plan de acción: Tener bien claro qué herramientas utilizar y cómo se va a realizar el desarrollo del proyecto. Riesgos de hardware y software. Problemas relacionados con el software o el hardware. Plan de acción: Disponer de copias de seguridad después de realizar cada tarea para evitar una posible pérdida del trabajo realizado. 2. Análisis En este apartado presentaremos la fase de análisis tanto de la aplicación de escritorio como de la aplicación web. 2.1 Glosario de términos A continuación, se definirán las palabras clave que se van a utilizar durante el desarrollo del proyecto. Aplicación: Se referirá a la aplicación de escritorio en sí. Alumno: Persona que asiste al menos a una de clases impartidas por la tienda. o Alumno activo: Alumno que a día de hoy asiste a al menos una clase. o Alumno inactivo: Alumno que a día de hoy no asiste a ninguna clase pero que permanece en el sistema por haber sido un alumno activo en algún momento. Recibo: Documento en el que se detallará, por cada alumno y mes, el importe total que debe pagar dicho alumno. 15

18 Producto: Cualquiera de los productos puestos a la venta en la galería. Nos encontramos diferentes modelos de productos tales como lienzos, cuadros, figuras, marcos y herramientas (incluyendo en este último varios tipos de herramientas). Clase: Grupo reducido de alumnos con un horario fijo. Cada clase vendrá identificada por el horario y el año en el que se imparte la misma. Venta Venta en local o Encargo en local: Refiere a los encargos realizados por un cliente de la galería a la dueña de la misma. o Venta producto en local: Refiere a traspasar un producto a una persona obteniendo un beneficio por ello. Venta en web o Encargo en web: Refiere a solicitar un producto que no se encuentre en la galería a través de la aplicación web. o Venta producto en web: Refiere a traspasar un producto a una persona obteniendo un beneficio por ello a través de la aplicación web. Almacén: Hace referencia a los pedidos realizados por el personal de la tienda a un proveedor. Cliente: Persona que adquiere un producto de la tienda o realiza un encargo. Proveedor: Persona a la que se le realiza un pedido de algún producto para ser puesto a la venta en la galería. Línea de pedido: Ítem que compone una venta de un determinado pedido. Línea de venta: Ítem que compone una venta de un determinado producto. Histórico alumnos: Datos de los alumnos que ya no asisten actualmente a ninguna de las clases impartidas por la tienda pero que permanecen registrados en el sistema. 2.2 Análisis de la aplicación de escritorio Especificación de los requisitos En la aplicación de escritorio se ha identificado un único tipo de rol: RA.- Rol Administrador. 16

19 Gestión de alumnos: RA1.- El administrador podrá dar de alta a un alumno introduciendo sus datos personales y la clase en la que se inscribe. RA2.- El administrador podrá borrar un alumno seleccionándolo previamente. Los datos del alumno irán a una tabla de históricos. RA3.- El administrador podrá consultar datos sobre un alumno activo o inactivo, seleccionándolo previamente. RA4.- El administrador podrá modificar datos sobre un determinado alumno, seleccionándolo previamente. RA5.- El administrador podrá activar un alumno que haya sido eliminado anteriormente. Gestión de recibos: RA1.- El administrador podrá crear un nuevo recibo introduciendo las características del mismo. RA2.- El administrador podrá borrar un recibo seleccionado el que se desea borrar. A petición explícita del cliente no interesa guardar la información eliminada. RA3.- El administrador podrá consultar datos sobre un recibo seleccionándolo previamente. RA4.- El administrador podrá modificar datos sobre un determinado recibo seleccionándolo previamente. Gestión de productos: RA1.- Permite introducir un nuevo producto para la venta. RA2.- Permite eliminar un producto seleccionándolo previamente. A petición explícita del cliente no interesa guardar la información eliminada. RA3.- Permite modificar las características de un producto seleccionándolo previamente. RA4.- Permite consultar características de un producto seleccionándolo previamente. Gestión de clases: RA1.- Permite crear una nueva clase. RA2.- Permite borrar una clase seleccionando el nombre de la clase A petición explícita del cliente no interesa guardar la información eliminada. RA3.- Permite modificar las características de una clase, seleccionando previamente la clase que se desea modificar. RA4.- Se podrá consultar las características de una clase previamente seleccionada. Gestión de ventas: RA1.- Permite introducir una nueva venta, se dará la opción de añadir más productos a una misma venta si fuera necesario. 17

20 RA2.- Se podrá modificar las características de una venta buscando previamente la venta por fecha. RA3.- Se podrá introducir un nuevo encargo, introduciendo una descripción del mismo y datos del cliente que lo solicita. RA4.- Se podrá modificar las características de un encargo buscando previamente el encargo por cliente que lo solicitó. RA5.- Permite consultar las características de una venta, seleccionado la fecha o rango de fechas en las que se realizó la venta. RA6.- Permite consultar las características de un encargo, seleccionado el cliente que solicitó dicho encargo. RA7.- Permite borrar una venta o un conjunto de ventas seleccionado previamente la fecha o rango de fechas en las que se realizó la venta. A petición explícita del cliente no interesa guardar la información eliminada. RA8.- Permite borrar un encargo o un conjunto de encargos seleccionado previamente la fecha o rango de fechas en las que se realizó el encargo. A petición explícita del cliente no interesa guardar la información eliminada. RA7.- Permite generar un informe de ventas seleccionando una fecha o rango de fechas. Gestión de almacén: RA1.- Permite introducir un nuevo pedido realizado a un determinado proveedor. RA2.- Permite consultar un pedido seleccionando el proveedor y la fecha en la que se realizó. RA3.- Permite borrar un pedido o un conjunto de pedidos seleccionando previamente el proveedor y la fecha o rango de fechas en las que se realizó. A petición explícita del cliente no interesa guardar la información eliminada. RA4.- Modifica un pedido seleccionando previamente el proveedor y fecha en la que se realizó. Gestión de clientes: RA1.- Borra un cliente, seleccionándolo previamente. A petición explícita del cliente no interesa guardar la información eliminada. RA2.- Permite consultar datos de un cliente seleccionado. RA3.- Modifica datos de un cliente seleccionado. RA4.- Permite introducir un nuevo cliente. Gestión de proveedores: RA1.- Borra un proveedor, seleccionándolo previamente. A petición explícita del cliente no interesa guardar la información eliminada. RA2.- Permite consultar datos de un proveedor seleccionado. RA3.- Modifica datos de un proveedor seleccionado. RA4.- Permite introducir un nuevo proveedor. 18

21 2.2.2 Identificación y especificación de Casos de Uso A continuación se presentan los casos de uso identificados para la aplicación de escritorio. Para cada caso de uso se han identificado las siguientes partes: o Resumen: Descripción del caso de uso de una manera textual. o Actor principal: Actor involucrado en el caso de uso. o Precondición: Condición que se debe satisfacer para que se cumpla el caso de uso. o Postcondición: Condición que se cumple una vez ejecutado el caso de uso. o Flujo básico: Secuencia de acciones hasta llegar al caso de uso. o Flujo alternativo: Posibles inconvenientes que pueden surgir dentro del flujo básico. Figura 10. Diagrama CDU Aplicación Escritorio 19

22 Módulo 1: Gestión de alumnos Figura 11. Diagrama CDU Gestión de alumnos A continuación mostraremos la definición de los casos de uso del diagrama de la figura anterior: 1.1 Nuevo alumno. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo El alumno es dado de alta en la aplicación. Administrador Haber accedido al módulo Alumnos y haber pulsado el botón Nuevo alumno El alumno ha sido dado de alta - El usuario rellena un formulario con los datos del alumno. - El usuario pulsa el botón Guardar Alguno de los datos introducidos por el usuario no es correcto y se muestra un mensaje de error A continuación se muestra un diagrama de actividad asociado a este caso de uso: 20

23 Figura 12. Diagrama Actividad nuevo alumno 1.2 Borrar alumno. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo El alumno es eliminado de la aplicación Administrador Haber accedido al módulo Alumnos y haber pulsado el botón Borrar alumno Los datos del alumno se guardan en una tabla de históricos - El usuario selecciona un alumno. - El usuario pulsa el botón Borrar. - Se confirma que desea borrar el alumno. 21

24 1.3 Consultar alumno. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se consulta la información de un alumno Administrador Haber accedido al módulo Alumnos y haber pulsado el botón Consultar alumno La información del alumno ha sido consultada - El usuario selecciona un alumno. - El usuario pulsa el botón Mostrar. - El usuario visualiza la información del alumno. 1.4 Modificar alumno. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se modifican alguno de los datos del alumno Administrador Haber accedido al módulo Alumnos y haber pulsado el botón Modificar alumno El alumno ha sido modificado - El usuario selecciona un alumno. - El usuario pulsa el botón Mostrar. - El usuario visualiza los datos del alumno. - El usuario modifica los datos que se deseen. - El usuario pulsa el botón Modificar. - Alguno de los datos modificados no es válido y se muestran un mensaje de error. 1.5 Activar alumno. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Un antiguo alumno es nuevamente activado. Administrador Haber accedido al módulo Alumnos y haber pulsado el botón Activar alumno El alumno ha sido activado - El usuario selecciona un alumno. - El usuario pulsa el botón Activar. - El alumno es activado. 22

25 Módulo 2: Gestión de recibos Figura 13. Diagrama CDU Gestión de recibos 2.1 Nuevo recibo. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se crea un nuevo recibo Administrador Haber accedido al módulo Recibos y haber pulsado el botón Nuevo recibo El recibo ha sido creado - El usuario selecciona el alumno del recibo que va a crear. - El usuario introduce una serie de datos para crear el recibo - El usuario pulsa el botón Guardar - El recibo es creado - Alguno de los datos introducidos no son válidos y se muestra un mensaje de error. 2.2 Consultar recibo. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se consulta información sobre un recibo Administrador Haber accedido al módulo Recibos y haber pulsado el botón Consultar recibo El recibo ha sido consultado - El usuario selecciona el alumno y la fecha del recibo a consultar. - El usuario pulsa el botón Mostrar. - El usuario visualiza información del recibo. 23

26 2.3 Modificar recibo. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se modifica información de un recibo Administrador Haber accedido al módulo Recibos y haber pulsado el botón Modificar recibo El recibo ha sido modificado - El usuario selecciona el alumno y la fecha del recibo a modificar - El usuario pulsa el botón Mostrar - El usuario visualiza información del recibo - El usuario modifica los datos que desee - El usuario pulsa el botón Modificar - El usuario confirma los cambios - Alguno de los datos modificados no son válidos y se muestra un mensaje de error. 2.4 Borrar recibo. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo El recibo es eliminado Administrador Haber accedido al módulo Recibos y haber pulsado el botón Borrar recibo. El recibo ha sido eliminado - El usuario selecciona el alumno y la fecha del recibo a borrar. - El usuario pulsa el botón Borrar. - El usuario confirma que desea eliminar el recibo Módulo 3: Gestión de productos Figura 14. Diagrama CDU Gestión de productos 24

27 3.1 Nuevo producto. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se introduce un nuevo producto Administrador Haber accedido al módulo Productos y haber pulsado el botón Nuevo producto El producto ha sido introducido - El usuario selecciona el modelo de producto - El usuario introduce una serie de datos del producto - El usuario pulsa el botón Guardar - Alguno de los datos introducidos no son válidos y se muestra un mensaje de error. 3.2 Eliminar producto. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Un producto es eliminado Administrador Haber accedido al módulo Productos y haber pulsado el botón Borrar producto El producto ha sido eliminado - El usuario selecciona el producto. - El usuario pulsa el botón Borrar. 3.3 Modificar producto. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se modifica información sobre un determinado producto Administrador Haber accedido al módulo Productos y haber pulsado el botón Modificar producto El producto ha sido modificado - El usuario selecciona el producto. - El usuario visualiza información del producto. - El usuario modifica los datos que desee. - El usuario pulsa el botón Modificar. - El usuario confirma que desea guardar los cambios. - Alguno de los datos modificados no son válidos y se muestra un mensaje de error 3.4 Consultar producto. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se consulta información sobre un determinado producto Administrador Haber accedido al módulo Productos y haber pulsado el botón Consultar producto El producto ha sido consultado - El usuario selecciona el producto. - El usuario pulsa el botón Mostrar - El usuario visualiza la información del producto seleccionado. 25

28 Módulo 4: Gestión de clases Figura 15. Diagrama CDU Gestión de clases 4.1 Nueva clase. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se introduce una nueva clase Administrador Haber accedido al módulo Clases y haber pulsado el botón Nueva clase La clase ha sido creada - El usuario introduce una serie de datos sobre la clase a crear. - El usuario pulsa el botón Guardar - Alguno de los datos introducidos no son válidos y se muestra un mensaje de error 4.2 Borrar clase. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Una clase es borrada Administrador Haber accedido al módulo Clases y haber pulsado el botón Borrar clase La clase ha sido eliminada - El usuario selecciona la clase que desea eliminar - El usuario pulsa el botón Borrar 26

29 4.3 Modificar clase. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se modifica información sobre una determinada clase Administrador Haber accedido al módulo Clases y haber pulsado el botón Modificar clase La información de la clase ha sido modificada - El usuario selecciona la clase que desea modificar - El usuario modifica los datos que desee - El usuario pulsa el botón Modificar - El usuario confirma que desea guardar los cambios - Alguno de los datos modificados no son válidos y se muestra un mensaje de error 4.4 Consultar clase. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se modifica información sobre una determinada clase Administrador Haber accedido al módulo Clases y haber pulsado el botón Consultar clase La información de la clase ha sido visualizada - El usuario selecciona la clase que desea consultar - El usuario pulsa el botón Mostrar - El usuario visualiza información de la clase 27

30 Módulo 5: Gestión de ventas Figura 16. Diagrama CDU Gestión de ventas Nueva venta. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se crea una nueva venta Administrador Haber accedido al módulo Ventas y haber pulsado el botón Nueva venta La venta ha sido creada - El usuario introduce datos sobre la venta a crear - El usuario pulsa el botón Guardar - Alguno de los datos introducidos no son válidos y se muestra un mensaje de error 28

31 5.1.2 Modificar venta. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se modifica información sobre una determinada venta Administrador Haber accedido al módulo Ventas y haber pulsado el botón Modificar venta La información de la venta ha sido modificada - El usuario introduce un rango de fechas y pulsa el botón Buscar. - El usuario visualiza ventas. - El usuario selecciona la venta que desea modificar - El usuario modifica los datos que desee - El usuario pulsa el botón Modificar - El usuario confirma que desea guardar los cambios. - Alguno de los datos modificados no son válidos y se muestra un mensaje de error Borrar venta. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Una venta es eliminada Administrador Haber accedido al módulo Ventas y haber pulsado el botón Borrar ventas La venta ha sido eliminada - Se selecciona un rango de fechas - El usuario pulsa el botón Buscar - El usuario visualiza las ventas que concuerden con los datos introducidos. - El usuario selecciona una venta o varias y pulsa el botón Borrar. - El usuario confirma que desea eliminar las ventas. 29

32 Figura 17. Diagrama Actividad Borrar venta Consultar venta. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo La información de una venta es consultada Administrador Haber accedido al módulo Ventas y haber pulsado el botón Consultar ventas La información de la venta es visualizada - Se selecciona un rango de fechas - El usuario pulsa el botón Buscar - El usuario visualiza las ventas que concuerden con los datos introducidos. - El usuario selecciona una venta a consultar. - El usuario pulsa el botón Mostrar. 30

33 5.2 Generar informe. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Generar informe de ventas Administrador Haber accedido al módulo Ventas y haber pulsado el botón Generar informe o bien desde la interfaz Consultar venta o Consultar encargo pulsando el botón Generar informe. Se ha creado un informe de ventas - Se selecciona un rango de fechas - El usuario pulsa el botón Generar informe - El usuario visualiza un informe de ventas Buscar venta. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Búsqueda de una venta Administrador Haber accedido al módulo Ventas y haber pulsado o bien el botón Modificar venta o Consultar venta o Borrar venta. La venta es encontrada. - Se selecciona de una lista la venta que se busca Consultar encargo. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo La información de un encargo es consultada Administrador Haber accedido al módulo Ventas y haber pulsado el botón Consultar encargo. La información del encargo ha sido visualizada - Se selecciona el cliente que realizó el encargo - El usuario visualiza los encargos del cliente. - El usuario selecciona el encargo a consultar. - El usuario pulsa el botón Mostrar - El usuario visualiza los datos del encargo Nuevo encargo. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se crea un nuevo encargo Administrador Haber accedido al módulo Ventas y haber pulsado el botón Nuevo encargo El encargo ha sido creado - Se introducen datos referentes al encargo - El usuario pulsa el botón Guardar - Alguno de los datos introducidos no es válido y se muestra un mensaje de error 31

34 5.3.3 Modificar encargo. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo La información de un encargo es modificada Administrador Haber accedido al módulo Ventas y haber pulsado el botón Modificar encargo La información del encargo ha sido modificada - Se selecciona el cliente que realizó el encargo - El usuario visualiza los encargos del cliente. - El usuario selecciona el encargo a modificar. - El usuario pulsa el botón Mostrar - El usuario visualiza los datos del encargo y modifica los que desee. - El usuario pulsa el botón Modificar - Alguno de los datos modificados no es válido y se muestra un mensaje de error Borrar encargo. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Un encargo es eliminado Administrador Haber accedido al módulo Ventas y haber pulsado el botón Borrar encargo El encargo ha sido eliminado - Se selecciona el cliente que realizó el encargo - El usuario visualiza los encargos del cliente. - El usuario selecciona el encargo a borrar. - El usuario pulsa el botón Borrar - El usuario confirma que desea eliminar el encargo Seleccionar cliente. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Un cliente es seleccionado Administrador Haber accedido al módulo Ventas y en el apartado Encargos haber pulsado el botón Modificar encargo o Consultar encargo o Borrar encargo. El cliente ha sido seleccionado - Se selecciona el cliente de una lista desplegable donde se encuentran todos los nombres de los clientes. 32

35 Módulo 6: Gestión de almacén Figura 18. Diagrama CDU Gestión de almacén 6.1 Nuevo pedido. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se crea un nuevo pedido Administrador Haber accedido al módulo Almacén y haber pulsado el botón Nuevo pedido El pedido ha sido creado - Se introducen los datos referentes al pedido - Se pulsa el botón Guardar - Alguno de los datos modificados no es válido y se muestra un mensaje de error. 6.2 Consultar pedido. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo La información de un pedido es consultada Administrador Haber accedido al módulo Almacén y haber pulsado el botón Consultar pedido La información del pedido es visualizada - Se selecciona el cliente que realizó el encargo. - El usuario selecciona el proveedor al que se le realizó el pedido. - El usuario visualiza pedidos realizados al proveedor seleccionado y elige al que desea consultar. - Se pulsa el botón Mostrar. - El usuario visualiza los datos del pedido. 33

36 6.3 Modificar pedido. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo La información de un pedido es modificada. Administrador. Haber accedido al módulo Almacén y haber pulsado el botón Modificar pedido. La información del pedido ha sido modificada. - Se selecciona el proveedor al que se le realizó el pedido. - El usuario visualiza los pedidos realizados al proveedor seleccionado y elige uno. - Se pulsa el botón Mostrar. - El usuario visualiza los datos del pedido y modifica los que desee. - El usuario pulsa el botón Modificar. - Alguno de los datos modificados no es válido y se muestra un mensaje de error. 6.4 Borrar pedido. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo El pedido es eliminado. Administrador. Haber accedido al módulo Almacén y haber pulsado el botón Borrar pedido. El pedido ha sido eliminado. - Se selecciona el proveedor al que se le realizó el pedido. - El usuario visualiza los pedidos realizados al proveedor seleccionado y elige uno. - Se pulsa el botón Eliminar. - El usuario confirma que desea eliminar el pedido seleccionado Módulo 7: Gestión de clientes Figura 19. Diagrama CDU Gestión de clientes 34

37 7.1 Nuevo cliente. PFC: Sitio web y aplicación para la gestión de una tienda de Bellas Artes Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se crea un nuevo cliente Administrador Haber accedido al módulo Clientes y haber pulsado el botón Nuevo cliente El cliente es dado de alta en el sistema - El usuario introduce datos referentes al cliente - El usuario pulsa el botón Guardar. - Alguno de los datos introducidos no es válido y se muestra un mensaje de error. 7.2 Borrar cliente. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Un cliente es eliminado de la aplicación Administrador Haber accedido al módulo Clientes y haber pulsado el botón Borrar cliente El cliente ha sido eliminado - El usuario selecciona el cliente que desea eliminar. - El usuario pulsa el botón Borrar - El usuario confirma que desea eliminar el cliente 7.3 Consultar cliente. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo La información de un cliente es visualizada Administrador Haber accedido al módulo Clientes y haber pulsado el botón Consultar cliente La información del cliente es consultada - El usuario selecciona el cliente que desea consultar. - El usuario pulsa el botón Mostrar - El usuario visualiza los datos del cliente seleccionado. 7.4 Modificar cliente. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo La información de un cliente es modificada Administrador Haber accedido al módulo Clientes y haber pulsado el botón Modificar cliente La información del cliente ha sido modificada - El usuario selecciona el cliente que desea modificar. - El usuario pulsa el botón Mostrar - El usuario visualiza los datos del cliente y modifica los que desee. - El usuario pulsa el botón Modificar y confirma que desea guardar los cambios. - Alguno de los datos modificados no es válido y se muestra un mensaje de error. 35

38 Módulo 8: Gestión de proveedores Figura 20. Diagrama CDU Gestión de proveedores 8.1 Nuevo proveedor. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se crea un nuevo proveedor Administrador Haber accedido al módulo Proveedores y haber pulsado el botón Nuevo proveedor El proveedor es dado de alta en el sistema - El usuario introduce datos referentes al proveedor. - El usuario pulsa el botón Guardar - Alguno de los datos introducidos no es válido y se muestra un mensaje de error. 8.2 Borrar proveedor. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Un proveedor es eliminado de la aplicación Administrador Haber accedido al módulo Proveedores y haber pulsado el botón Borrar proveedor El proveedor ha sido eliminado - El usuario selecciona el proveedor que desea eliminar - El usuario pulsa el botón Borrar - El usuario confirma que desea eliminar el cliente 36

39 8.3 Consultar proveedor. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo La información de un proveedor es visualizada Administrador Haber accedido al módulo Proveedores y haber pulsado el botón Consultar proveedor La información del proveedor es consultada - El usuario selecciona el proveedor que desea consultar - El usuario pulsa el botón Mostrar - El usuario visualiza los datos del proveedor seleccionado 8.4 Modificar proveedor. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo La información de un proveedor es modificada Administrador Haber accedido al módulo Proveedores y haber pulsado el botón Modificar proveedor La información del proveedor ha sido modificada - El usuario selecciona el proveedor que desea modificar - El usuario pulsa el botón Mostrar - El usuario visualiza los datos del proveedor y modifica los que desee - El usuario pulsa el botón Modificar - Alguno de los datos modificados no es válido y se muestra un mensaje de error Análisis de clases En este apartado mostraremos cómo está formado el sistema a nivel de clases. A cada clase se le ha asignado un nombre intuitivo para un mejor reconocimiento de la información que contiene. Sólo se mostrarán los atributos de las clases, omitiendo las operaciones para una mayor claridad. Las clases se han identificado con colores de la siguiente manera: Rosa: Clases exclusivas de la aplicación de escritorio. Amarillo: Clases de ambas aplicaciones. 37

40 Figura 21. Diagrama de clases aplicación escritorio 38

41 A continuación, describiremos las clases comunes a las dos aplicaciones (de Escritorio y web) y las clases específicas de la aplicación de escritorio. Para facilitar la compresión del diagrama de clases se presenta en bloques de clases, en función de su relación. En la imagen anterior, nos encontramos tres clases Alumno, Clase y Recibo las cuales están relacionadas entre sí. La clase Alumno está relacionada con la clase Clase, puesto que un alumno debe asistir a al menos una de las clases impartidas por la galería. Así mismo, a una clase debe de asistir al menos un alumno. La clase Alumno, también está relacionada con la clase Recibo, ya que un alumno debe tener al menos un recibo asociado, por el contrario, un recibo pertenecerá a un único alumno. En el caso de la figura anterior, encontramos tres clases Proveedor, Pedido y LineaDePedido. 39

42 La clase Proveedor irá relacionada con la clase Pedido, puesto que un pedido se le realiza a un único proveedor. Por el contrario a un mismo proveedor se le pueden realizar varios pedidos. A su vez, la clase Pedido irá relacionada con la clase LineaDePedido, ya que un pedido irá compuesto de una o varias líneas de pedido. Por otra parte, una línea de pedido pertenecerá a un único pedido. Esta relación se ha identificado con un rombo de color negro (a esto se le llama relación de composición en UML) porque en el caso de que desaparezca el pedido desaparecerán todas sus líneas de pedido relacionadas. En la imagen anterior, se muestra una nueva clase, la clase Producto. Como es de esperar, cada línea de pedido está asociada a un producto, por el contrario, un producto puede estar en varias líneas de pedido. En este caso, el rombo aparece blanco (relación de agregación) esto es así porque en el caso de que desaparezca una línea de pedido, el producto va a seguir existiendo. 40

43 En la imagen anterior encontramos una relación de herencia. La clase Venta es la clase padre de EncargoEnLocal y VentaProductoEnLocal. Así, por ejemplo, la clase EncargoEnLocal tendrá sus propios atributos más lo de la clase Venta. Un encargo en local va a estar asociado siempre a un cliente, de ahí la relación entre las clases Cliente y EncargoEnLocal. Además estará solicitado por un único cliente, y por el contrario, un cliente puede realizar varios encargos en local. La imagen siguiente muestra la relación entre las clases Venta, LineaDeVenta y Producto (ésta última seguirá la misma jerarquía vista anteriormente). Una venta estará compuesta de, al menos, una línea de venta. Por el contrario, una línea de venta estará siempre asociada a una única venta. Cada línea de venta está asociada a un producto y un mismo producto puede estar en varias líneas de venta. 41

44 2.2.4 Prototipos de interfaces de usuario Según los requisitos del cliente se seguirán los siguientes principios en el diseño de interfaces: Las interfaces serán lo más sencillas e intuitivas posibles debido al escaso conocimiento informático del cliente. En los módulos en los que se debe seleccionar un determinado elemento, éstos seguirán algún criterio de ordenación. Por ejemplo, a la hora de borrar un alumno, se muestran todos los alumnos ordenados alfabéticamente por los apellidos. En todos los casos que sea posible, se permitirán seleccionar opciones en vez de escribirlas, para una mayor sencillez para el cliente y disminuir la posibilidad errores. Siempre que sea posible habrá mensajes brevemente descriptivos que ayudarán al usuario a identificar los posibles errores que se puedan dar. Se seguirá el formato típico de interfaces gráficas de Windows, ya que es el sistema operativo que se va a utilizar Prototipo interfaz gestión de alumnos Figura 22- Prototipo interfaz gestión de alumnos Navegabilidad: En esta ventana nos aparecerá en el menú superior todos los diferentes módulos de los que consta la aplicación. Al pulsar con el ratón sobre cada uno de ellos se abrirá un submenú con las distintas funciones que puede realizar. En el caso de la Figura 37. hemos pulsado sobre el menú Alumnos. 42

45 Prototipo interfaz nuevo alumno Figura 23- Prototipo interfaz alta alumno Navegabilidad: La venta consiste en un formulario donde el usuario introducirá datos referentes a un nuevo alumno. Prototipo interfaz borrar alumno Figura 24- Prototipo interfaz borrar alumno Navegabilidad: La ventana consiste en una lista desplegable donde nos aparecerán todos los alumnos activos de la aplicación. El usuario deberá elegir el que desea eliminar y pulsar el botón Borrar. El usuario eliminado irá a una tabla de históricos. Prototipo interfaz consultar alumno Figura 25- Prototipo interfaz consultar alumno 43

46 Navegabilidad: La ventana, al igual que la anterior, consiste en una lista desplegable donde nos aparecerán todos los alumnos. La diferencia con el anterior radica en que en este caso, aparecerá un botón Consultar donde, al pulsarlo, se mostrará toda la información del alumno. El usuario ha pulsado en este caso sobre Consultar alumno. Prototipo interfaz modificar alumno Figura 26- Prototipo interfaz modificar alumno Navegabilidad: En esta ventana se seguirá el mismo diseño que en los casos anteriores. Una vez seleccionado el alumno se pulsará sobre un botón Modificar. En ese momento los datos del alumno se mostrarán y se permitirá cambiar los datos que se deseen. Una vez se haya terminado de modificar, el usuario pulsará el botón Guardar cambios. Se deberá confirmar que se desean guardar los cambios. Prototipo interfaz activar alumno Figura 27. Prototipo interfaz activar alumno Navegabilidad: En este caso, en el campo desplegable, aparecerán únicamente los alumnos que no se encuentren activos. Al pulsar Activar, el alumno seleccionado previamente se activará. 44

47 Prototipo interfaz gestión de recibos Figura 28. Prototipo interfaz gestión de recibos Navegabilidad: En esta ventana nos aparecerá en el menú superior todos los diferentes módulos de los que consta la aplicación. Al pulsar con el ratón sobre cada uno de ellos se abrirá un submenú con las distintas funciones que puede realizar. En el caso de la Figura 43. hemos pulsado sobre el menú Recibos. Prototipo interfaz nuevo recibo Figura 29. Prototipo interfaz nuevo recibo Navegabilidad: Aparecerán todos los datos que el usuario debe rellenar para crear un nuevo recibo. 45

48 Prototipo interfaz borrar recibo Figura 30. Prototipo interfaz borrar recibo Navegabilidad: La ventana permitirá seleccionar un alumno y una fecha de una lista desplegable. Una vez seleccionadas ambas opciones, el usuario pulsará el botón Borrar y se borrará el recibo del alumno en la fecha seleccionada. Prototipo interfaz consultar recibo Figura 31. Prototipo interfaz consultar recibo Navegabilidad: Al igual que en el caso anterior, se permitirá seleccionar un alumno y una fecha, ambos a partir de listas desplegables. Al pulsar el botón Consultar se mostrarán los datos del recibo previamente seleccionado. Prototipo interfaz modificar recibo Figura 32. Prototipo interfaz modificar recibo Navegabilidad: En este caso, se seguirá el mismo procedimiento pero contará con un botón Modificar, el cual permitirá modificar la información del recibo seleccionado. 46

49 Prototipo interfaz gestión de productos Figura 33. Prototipo interfaz gestión de productos Navegabilidad: En esta ventana nos aparecerá en el menú superior todos los diferentes módulos de los que consta la aplicación. Al pulsar con el ratón sobre cada uno de ellos se abrirá un submenú con las distintas funciones que puede realizar. En el caso de la Figura 48. hemos pulsado sobre el menú Productos mostrándose las diferentes opciones que pueden realizarse relacionadas con ellos. Prototipo interfaz nuevo producto Figura 34- Prototipo interfaz nuevo producto Navegabilidad: La ventana consistirá en un formulario donde el usuario introducirá los datos referentes al nuevo producto. 47

50 Prototipo interfaz borrar producto Figura 35- Prototipo interfaz borrar producto Navegabilidad: La ventana consistirá en dos listas desplegables, una de ellas contendrá los modelos diferentes de productos que hay, y otra una lista de referencias de productos correspondientes al modelo seleccionado. Cuando se pulse el botón Borrar, después de confirmar, el producto se borrará. Prototipo interfaz consultar producto Figura 36- Prototipo interfaz consultar producto Navegabilidad: La venta que se muestra es similar al apartado al anterior, con la diferencia del botón Consultar, que permitirá visualizar la información del producto seleccionado. Prototipo interfaz modificar producto Figura 37- Prototipo interfaz modificar producto Navegabilidad: Siguiendo el mismo diseño, esta ventana contará con dos listas desplegables que permitirán seleccionar el producto que se desea modificar. 48

51 Prototipo interfaz gestión de clases Figura 38- Prototipo interfaz gestión de clases Navegabilidad: En esta ventana nos aparecerá en el menú superior todos los diferentes módulos de los que consta la aplicación. Al pulsar con el ratón sobre cada uno de ellos se abrirá un submenú con las distintas funciones que puede realizar. En el caso de la Figura 53. hemos pulsado sobre el menú Clases mostrándose las diferentes opciones que pueden realizarse relacionadas con ellas. Prototipo interfaz nueva clase Figura 39- Prototipo interfaz nueva clase Navegabilidad: La ventana consistirá en un formulario en el cual el usuario introducirá los datos de la nueva clase. Prototipo interfaz borrar clase Figura 40- Prototipo interfaz borrar clase 49

52 Navegabilidad: La ventana mostrará una lista desplegable que contendrá todas las clases que se imparten. El usuario seleccionará una y pulsará el botón Eliminar. Prototipo interfaz consultar clase Figura 41- Prototipo interfaz consultar clase Navegabilidad: Siguiendo la misma dinámica, se mostrará una lista desplegable donde se seleccionará la clase que se desea consultar. Prototipo interfaz modificar clase Figura 42- Prototipo interfaz modificar clase Navegabilidad: Se seleccionará de una lista desplegable la clase que se desee modificar. Se mostrarán los datos y se modificarán los datos que se necesiten. Posteriormente se pulsará el botón Modificar y se confirmará que se desean guardar los cambios. 50

53 Prototipo interfaz gestión de ventas Figura 43- Prototipo interfaz gestión de ventas Navegabilidad: En esta ventana nos aparecerá en el menú superior todos los diferentes módulos de los que consta la aplicación. Al pulsar con el ratón sobre cada uno de ellos se abrirá un submenú con las distintas funciones que puede realizar. En el caso de la Figura 58. hemos pulsado sobre el menú Ventas mostrándose las diferentes opciones que pueden realizarse relacionadas con ellas. Prototipo interfaz nueva venta Figura 44- Prototipo interfaz nueva venta Navegabilidad: Se mostrará un formulario donde se introducirán los datos necesarios para guardar una venta. Habrá una opción para añadir más productos a una misma venta. 51

54 Prototipo interfaz borrar venta Figura 45- Prototipo interfaz borrar venta Navegabilidad: La ventana consistirá en dos campos fecha con objetivo de buscar la venta que se desea borrar. Prototipo interfaz consultar venta Figura 46. Prototipo interfaz consultar venta Navegabilidad: La ventana consistirá en dos campos fecha con objetivo de buscar la venta que se desea consultar. Prototipo interfaz modificar venta Figura 47- Prototipo interfaz modificar venta Navegabilidad: Al igual que en el caso anterior, se mostrarán dos campos fecha con el objetivo de buscar la venta, en este caso, a modificar. Se mostrarán los datos de la venta seleccionada y se modificarán los datos que se deseen. 52

55 Prototipo interfaz nuevo encargo Figura 48- Prototipo interfaz nuevo encargo Navegabilidad: Se mostrará un formulario donde el usuario introducirá los datos necesarios para crear un nuevo encargo. Prototipo interfaz borrar encargo Figura 49- Prototipo interfaz borrar encargo Navegabilidad: Aparecerá una lista desplegable en la cual el usuario seleccionará el cliente que realizó el encargo. Posteriormente se mostrarán los encargos realizados por dicho cliente y se podrá eliminar el que se desee. Prototipo interfaz consultar encargo Figura 50- Prototipo interfaz consultar encargo 53

56 Navegabilidad: Al igual que en el caso anterior se mostrará una lista desplegable donde el usuario seleccionará el cliente que realizó el encargo. Se mostrarán todos sus encargos y se consultará el que se desee. Prototipo interfaz modificar encargo Figura 51- Prototipo interfaz modificar encargo Navegabilidad: Se mostrará una lista desplegable donde el usuario seleccionará el cliente que realizó el encargo. Se mostrarán todos sus encargos y se modificará el que se desee. Prototipo interfaz informe de ventas Figura 52- Prototipo interfaz informe de ventas Navegabilidad: Se mostrarán dos campos fechas con objeto de que, posteriormente, se visualice un informe de ventas que concuerden con las fechas seleccionadas. Nótese que un encargo al fin y al cabo es un tipo de venta, por lo tanto en los informes, a petición del cliente, también se mostrarán los encargos junto a las ventas. 54

57 Prototipo interfaz gestión de almacén Figura 53- Prototipo interfaz gestión de almacén Navegabilidad: En esta ventana nos aparecerá en el menú superior todos los diferentes módulos de los que consta la aplicación. Al pulsar con el ratón sobre cada uno de ellos se abrirá un submenú con las distintas funciones que puede realizar. En el caso de la Figura 68. hemos pulsado sobre el menú Almacén mostrándose las diferentes opciones que pueden realizarse relacionadas con él. Prototipo interfaz nuevo pedido Figura 54- Interfaz nuevo pedido Navegabilidad: Se mostrará un formulario donde el usuario introducirá los datos necesarios para realizar un pedido. Prototipo interfaz borrar pedido Figura 55- Prototipo interfaz borrar pedido 55

58 Navegabilidad: Esta ventana contendrá tres campos, una lista desplegable donde se seleccionará el proveedor al que se le realizó el pedido y dos campos de tipo fecha con el fin de hacer una búsqueda más acotada. Prototipo interfaz consultar pedido Figura 56- Prototipo interfaz consultar pedido Navegabilidad: Esta ventana será igual que la anterior, pero una vez seleccionado el pedido, se podrá ver sus características. Prototipo interfaz modificar pedido Figura 57- Prototipo interfaz modificar pedido Navegabilidad: Esta interfaz seguirá el mismo procedimiento que las anteriores, pero su fin será el de modificar el pedido seleccionado Prototipo interfaz gestión de clientes Figura 58- Prototipo interfaz gestión de clientes Navegabilidad: En esta ventana nos aparecerá en el menú superior todos los diferentes módulos de los que consta la aplicación. Al pulsar con el ratón sobre cada uno de ellos se abrirá un submenú con las distintas funciones que puede realizar. En el caso de la Figura 73. hemos pulsado sobre el menú Clientes 56

59 mostrándose las diferentes opciones que pueden realizarse relacionadas con ellos. Prototipo interfaz nuevo cliente Figura 59- Prototipo interfaz nuevo cliente Navegabilidad: Esta ventana contará con un formulario donde el usuario introducirá los datos referentes al nuevo cliente. Prototipo interfaz borrar cliente Figura 60- Prototipo interfaz borrar cliente Navegabilidad: Se mostrará una lista desplegable que contendrá todos los clientes, para que el usuario seleccione el que desea borrar. Prototipo interfaz consultar cliente Figura 61- Prototipo interfaz consultar cliente 57

60 Navegabilidad: Siguiendo el mismo procedimiento anterior, pero en este caso el usuario seleccionará un cliente para consultar su información. Prototipo interfaz modificar cliente Figura 62- Prototipo interfaz modificar cliente Navegabilidad: Mismo procedimiento que en los casos anteriores, pero en esta ocasión el usuario seleccionará un cliente para modificar su información Prototipo interfaz gestión de proveedores Figura 63- Prototipo interfaz gestión de proveedores Navegabilidad: En esta ventana nos aparecerá en el menú superior todos los diferentes módulos de los que consta la aplicación. Al pulsar con el ratón sobre cada uno de ellos se abrirá un submenú con las distintas funciones que puede realizar. En el caso de la Figura 78. hemos pulsado sobre el menú Proveedores mostrándose las diferentes opciones que pueden realizarse relacionadas con ellos. 58

61 Prototipo interfaz nuevo proveedor Figura 64- Prototipo interfaz nuevo proveedor Navegabilidad: Se mostrará un formulario donde el usuario introducirá los datos referentes a un proveedor. Prototipo interfaz borrar proveedor Figura 65- Prototipo interfaz borrar proveedor Navegabilidad: Esta ventana, siguiendo diseños anteriores, contará con una lista desplegable que contendrá todos los proveedores y el usuario deberá seleccionar el que desea borrar. Prototipo interfaz consultar proveedor Figura 66- Prototipo interfaz consultar proveedor Navegabilidad: En este caso, el usuario seleccionará el nombre del proveedor que desea consultar. 59

62 Prototipo interfaz modificar proveedor Figura 67- Prototipo interfaz modificar proveedor Navegabilidad: El usuario seleccionará en la lista desplegable el nombre del proveedor que desea modificar. 2.3 Análisis de la aplicación web Especificación de los requisitos En la aplicación Web contamos con tres tipos diferentes de rol: RV: Requisitos que puede llevar a cabo el rol visitante. RC: Requisitos que puede llevar a cabo el rol cliente. RA: Requisitos que puede llevar a cabo el rol alumno. A continuación, mostramos los requisitos a nivel de módulos de la aplicación web. Módulo inicio: RV1. Un visitante podrá visualizar una información general de la galería. Módulo tienda: RV1. Un visitante podrá visualizar el módulo tienda. RV2. Un visitante podrá seleccionar un tipo de producto. RV3. Un visitante podrá solicitar un producto que no se encuentre en la galería enviando un formulario con una descripción del mismo. RC1. Un cliente podrá añadir un producto a la cesta. RC1.2 Una vez añadido el producto o productos que se deseen a la cesta, un cliente podrá confirmar la compra. Módulo clases: RV1. Un visitante podrá visualizar la lista de clases disponibles en la galería. RV2. Un visitante podrá solicitar admisión a una determinada clase, enviando un formulario al personal de la galería. 60

63 RV3. Un visitante podrá solicitar información sobre una determinada clase, enviando un formulario al personal de la galería. Módulo contacto: RV1. Un visitante podrá visualizar información sobre cómo contactar con el personal de la galería. RV2. Un visitante podrá valorar la aplicación Web enviando un formulario con su opinión sobre la misma. Módulo zona de registro: RV1. Un visitante podrá visualizar la zona de registro. RV1. El visitante podrá registrarse desde este módulo introduciendo una serie de datos personales. RA1. El alumno podrá acceder a la aplicación desde este módulo. RC1. El cliente podrá acceder a la aplicación desde este módulo. Módulo ficha personal: RC1. El cliente podrá visualizar información sobre sus datos personales en la ficha personal. RC2. El cliente podrá modificar alguno de sus datos personales en la ficha personal. RC3. El cliente podrá visualizar los pedidos realizados y el estado de los mismos. RA1. El alumno podrá visualizar información sobre sus datos personales en la ficha personal. RA2. El alumno podrá modificar alguno de sus datos personales en la ficha personal. RA3. El alumno podrá ver avisos referentes a clases Identificación y especificación de Casos de Uso La especificación de los casos de uso contendrán las mismas partes que los de la aplicación de escritorio. A continuación se presentan los casos de uso identificados para los requisitos citados anteriormente. 61

64 Diagrama CDU aplicación web Figura 68: Diagrama CDU aplicación web Diagrama CDU módulo tienda Figura 69: Diagrama CDU Módulo tienda 62

65 2.1 Solicitar producto. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Solicitar un producto que no se encuentre en la aplicación web Visitante, y por consiguiente, alumno y cliente Haber accedido al módulo tienda. La solicitud ha sido realizada - El usuario pulsa el botón Solicitar producto. - Rellena un formulario. - Pulsa el botón Enviar y el formulario es enviado a la galería Diagrama CDU comprar producto visitante Figura 70: Diagrama CDU Comprar producto visitante Seleccionar tipo de producto. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Seleccionar uno de los tipos de productos disponibles. Visitante, y por consiguiente, alumno y cliente Haber accedido al módulo tienda. Se muestran los productos disponibles del tipo seleccionado - El usuario selecciona uno de los tipos de producto disponibles. - Visualiza los distintos productos que hay de ese tipo - Si el usuario no selecciona ningún tipo de producto se muestra el que está por defecto Seleccionar producto. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Seleccionar uno de los productos que se muestran. Visitante, y por consiguiente, alumno y cliente Haber accedido al módulo tienda. El producto se añade a la cesta - El usuario selecciona uno de los productos que se muestran y automáticamente se añaden a la cesta. - Si el usuario no selecciona ningún tipo de producto se muestra el que está por defecto. 63

66 2.2.3 Finalizar compra. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo Se finaliza la compra. Visitante, y por consiguiente, alumno y cliente Haber accedido al módulo tienda. La compra es realizada - El usuario pulsa el botón de Finalizar compra. - El usuario no está autentificado y la aplicación pide que se registre o se autentifique antes de finalizar la compra. - No se ha seleccionado ningún producto y la aplicación pide que se seleccione al menos uno Registrarse. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo El usuario se registra en la aplicación. Visitante, y por consiguiente, alumno y cliente Haber accedido al módulo Zona de registro. El usuario es registrado en la aplicación web. - El usuario pulsa el botón de Registrar. - El usuario rellena un formulario. - El usuario pulsa el botón Aceptar. - El nombre de usuario elegido por el usuario ya está en uso y la aplicación pide que se elija otro distinto. - Las contraseñas introducidas no coinciden y la aplicación pide volver a introducirlas. - El usuario no ha rellenado alguno de los datos obligatorios y la aplicación muestra un aviso. A continuación se muestra el diagrama de actividad correspondiente al caso de uso Comprar producto visitante : 64

67 Figura 71: Diagrama actividad comprar producto visitante 65

68 Diagrama CDU comprar producto cliente Figura 72: Diagrama actividad comprar producto cliente Y su diagrama de actividad correspondiente: Figura 73: Diagrama actividad comprar producto cliente 66

69 Diagrama CDU módulo de clases Figura 74. Diagrama CDU Módulo de clases 3.1 Solicitar admisión a clase. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo El usuario quiere asistir a una de las clases disponibles y solicita inscribirse. Visitante, y por consiguiente, alumno y cliente Haber accedido al módulo Clases. El usuario ha enviado un informe de solicitud de admisión. - El usuario observa las clases disponibles. - Pulsa el botón Solicitar admisión a clase. - Se identifica. - Rellena el formulario. - Pulsa el botón Enviar. - Cuando se identifica, el usuario introduce mal el usuario o contraseña y la aplicación le pide que vuelva a introducirlos. 3.2 Solicitar información sobre clase. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo El usuario quiere información sobre uno de las clases disponibles. Visitante, y por consiguiente, alumno y cliente Haber accedido al módulo Clases. El usuario ha solicitado información sobre una determinada clase. - El usuario observar las clases disponibles. - Pulsa el botón Solicitar información. - Rellena un formulario. - Pulsa el botón Enviar. 67

70 3.3 Identificarse. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo El usuario se identifica en la aplicación. Visitante, y por consiguiente, alumno y cliente Haber accedido al módulo Clases y haber pulsado el botón Solicitar admisión a clase. El usuario ha sido identificado. - El usuario introduce su nombre de usuario y contraseña, o bien, accede como visitante. - El usuario introduce mal el usuario y contraseña y la aplicación pide que se vuelvan a introducir Diagrama CDU módulo contacto Figura 75. Diagrama CDU Módulo contacto 4.1 Contactar con el personal de la tienda. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo El usuario quiere contactar con el personal de la tienda. Visitante, y por consiguiente, alumno y cliente Haber accedido al módulo Contacto. El usuario contacta con el personal de la galería. - El usuario visualiza las vías disponibles para contactar con el personal de la galería. - El usuario contacta con el personal de la galería. 68

71 Diagrama CDU módulo zona de registro Figura 76. Diagrama CDU Módulo zona de registro 5.1 Registrarse. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo El usuario se registra en la aplicación. Visitante, y por consiguiente, alumno y cliente Haber accedido al módulo Zona de registro. El usuario es registrado en la aplicación web. - El usuario pulsa el botón Registrar. - El usuario rellena un formulario. - El usuario pulsa el botón Aceptar. - El nombre de usuario elegido ya está en uso y la aplicación pide que se elija otro distinto. - Las contraseñas introducidas no coinciden y la aplicación pide que se vuelvan a introducir. - El usuario no ha rellenado alguno de los datos obligatorios y muestra un aviso. 69

72 Diagrama CDU módulo ficha personal Figura 77. Diagrama CDU Módulo ficha personal 6.1 Modificar datos personales. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo El usuario modifica alguno de sus datos personales. Cliente y alumno, El usuario se ha identificado y accede al módulo Ficha personal. Alguno de los datos personales del usuario han sido modificados. - El usuario pulsa el botón Modificar. - El usuario cambia los datos que desea. - El usuario pulsa el botón Guardar cambios. - El usuario confirma que desea guardar los cambios realizados. - Alguno de los datos modificados no son válidos y debe volver a introducirlos. 6.2 Visualizar pedidos. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo El usuario visualiza los pedidos realizados hasta el momento. Cliente Haberse identificado y haber accedido al módulo Ficha personal. El usuario ha visualizado los pedidos realizados. - El usuario pulsa el botón Ver pedidos. - El nombre de usuario elegido ya está en uso y la aplicación pide que se elija otro distinto. - Las contraseñas introducidas no coinciden y la aplicación pide que se vuelvan a introducir. - El usuario no ha rellenado alguno de los datos obligatorios y muestra un aviso. 70

73 6.3 Ver avisos. Resumen Actor principal Precondición Postcondición Flujo básico Flujo alternativo El usuario ve avisos referentes a clases. Alumno. Haberse identificado y haber accedido al módulo Ficha personal. El usuario ha visualizado los avisos referentes a clases en las que está inscrito. - El usuario pulsa el botón Ver avisos Análisis de clases En este apartado mostraremos cómo estará formada la aplicación Web a nivel de clases. Al igual que se ha hecho en la aplicación de escritorio, se ha procurado asignar un nombre intuitivo para un mejor reconocimiento de la información que contiene. De nuevo, sólo se mostrarán los atributos de las clases, omitiendo las operaciones para una mayor claridad. Las clases se han identificado en colores según el siguiente criterio: Amarillo: Clases comunes a ambas aplicaciones Naranja: Clases exclusivas de la aplicación web. 71

74 Figura 78: Diagrama de clases aplicación web Nota.- Cuando sea implementada la aplicación web en un futuro, las clases Alumno y Cliente tendrán otros dos atributos: NombreUsuario y Contraseña. 72

75 A continuación, siguiendo el mismo procedimiento que en el caso de la aplicación de escritorio, se mostrará el diagrama de clases en bloques, en función de su relación. Sólo se muestran las clases exclusivas de la aplicación web puesto que las clases comunes han sido explicadas en el análisis de la aplicación de escritorio. En la imagen anterior, se muestran las clases Usuario, Cliente y Alumno que corresponden a los roles de la aplicación web. La clase Usuario es clase padre de las otras dos, por lo tanto, la clase Cliente y la clase Alumno tienen los mismos privilegios que la clase Usuario, además de los propios de cada una de ellas. En la figura anterior, tenemos la jerarquía de herencia que siguen las clases relacionadas con las ventas. 73

76 La clase Venta es la clase padre de todas las que le siguen. Así, por ejemplo, la clase EncargoEnWeb tendrá sus propios atributos más los de la clase VentaAplicacionWeb y ésta a su vez tendrá los atributos de la clase Venta Prototipos de interfaces de usuario En este apartado daremos una primera aproximación a cómo quedaría la interfaz de cada uno de los módulos de la aplicación Web. Al igual que en la aplicación de escritorio, se seguirá el formato típico de interfaces gráficas de Windows Prototipo interfaz módulo inicio Figura 79. Prototipo interfaz módulo inicio Navegabilidad: En esta ventana se mostrará información general de la galería con imágenes. 74

77 Prototipo interfaz módulo tienda Figura 80. Prototipo interfaz módulo tienda Navegabilidad: En esta ventana se mostrará información sobre los diferentes modelos de productos puestos a la venta y permitirá al usuario comprarlos Prototipo interfaz módulo clases Figura 81. Prototipo interfaz módulo clases Navegabilidad: En esta ventana se mostrará información sobre las clases disponibles donde el usuario podrá solicitar información o solicitar admisión a alguna de las clases según lo desee. 75

78 Prototipo interfaz módulo contacto Figura 82. Prototipo interfaz módulo contacto Navegabilidad: Mostrará información para contactar con el personal de la galería Prototipo interfaz módulo zona de registro Figura 83. Prototipo interfaz módulo zona de registro Navegabilidad: permitirá acceder a la aplicación introduciendo usuario y contraseña en caso de que el usuario ya esté registrado, o registrarse en caso contrario Prototipo interfaz módulo ficha personal Figura 84. Prototipo interfaz módulo ficha personal Navegabilidad: permitirá a los usuarios ya registrados, acceder a su ficha personal y ver información de su interés. 76

79 3. Diseño de la aplicación de escritorio 3.1 Definición de la arquitectura Desde el punto de vista lógico (más de estructura software), hemos seguido una tecnología de tres capas: La aplicación estará compuesta por tres partes, tres capas, las cuales tienen una función muy diferenciada. Capa de presentación: La capa de presentación es la que se encarga de la interacción con el usuario, presentando la información, aceptando las operaciones y enviando las respuestas. Capa de lógica de negocio: Es el corazón de la aplicación, implementando cualquier proceso que realice la aplicación. Es el conjunto de reglas de negocio que la aplicación tiene que implementar. Capa de persistencia: Se encarga del acceso al sistema de persistencia elegido, independizando a la aplicación del sistema de persistencia elegido. Como sistema de persistencia se ha decidido utilizar una BD ya que los SGBD presentan numerosas ventajas como la mejora de productividad, mejora de la accesibilidad de los datos, etc. Por qué se ha usado Java en el desarrollo del proyecto? Porque es un lenguaje multiplataforma, por lo tanto todos los programas que se desarrollen en Java pueden ejecutarse sin problemas en sistemas operativos como Windows, Linux, Mac, etc. Permite crear programas que se ejecuten en varios dispositivos como por ejemplo en móviles. 3.2 Diseño de la base de datos Para el diseño de la BD se ha creado un diagrama EER: 77

80 Figura 85. Diagrama EER Aplicación escritorio 78

81 En el diagrama de la figura anterior observamos que, casi en su totalidad, está compuesto por entidades fuertes, sólo las entidades referentes a las líneas, LineaDePedido y LineaDeVenta son entidades débiles. Figura 86. EER LineaDePedido Ésto es así, puesto que la clave de línea de pedido es una clave compuesta, y uno de los elementos de esa clave es el NumeroPedido. Un esquema similar se sigue para LineaDeVenta. En la figura 86. también observamos que hay entidades que están subdivididas en subclases. Vemos un ejemplo en la siguiente figura: Figura 87. EER Venta 79

82 Nos encontramos ante una especialización con una restricción de disyunción:. En el ejemplo de la figura quiere decir que, una venta puede ser como mucho una de las dos opciones: o un EncargoEnLocal o una VentaProductoEnLocal. Así mismo, se exige que una Venta tenga que ser de al menos una de las dos opciones (EncargoEnLocal o VentaProductoEnLocal), es decir es una especialización total y se ha representado de la siguiente forma: Todos los atributos encontrados en el diagrama de la figura 86, son de tipo monovalor, exceptuando, que es derivado. 3.3 Normalización Todas las tablas de la base de datos se encuentran en 1FN ya que todos sus atributos son monovaluados. Todas las tablas de la base de datos se encuentran en 2FN porque está en 1FN y todos sus atributos no primos, es decir todos los atributos que no figuran en ninguna clave candidata, dependen funcionalmente de manera total de la clave principal. Todas las tablas de la base de datos se encuentran en 3FN porque están en 2FN y no existe ninguna dependencia funcional transitiva entre los atributos que no son clave. Todas las tablas están en forma normal de Boyce-Codd (FNBC) porque están en 3 FN y además cada determinante, atributo que determina completamente a otro, es clave candidata 3.4 Interfaces de usuario Basándonos en los prototipos de interfaces creados anteriormente se han creado las siguientes interfaces las cuales son más completas. Para mostrar las interfaces finales de la aplicación, se han ocultado ciertos datos para la privacidad de datos reales almacenados en la BD Interfaz pantalla inicio Nada más iniciar el programa se mostrará la siguiente pantalla: 80

83 Figura 88. Interfaz pantalla de inicio, donde el usuario podrá acceder a los diferentes módulos de la aplicación Interfaz gestión de alumnos La siguiente ventana mostrará las diferentes opciones que puede realizar el usuario respecto a la gestión de alumnos: Figura 89. Interfaz pantalla gestión de alumnos A continuación mostraremos las diferentes opciones de este módulo: 81

84 Interfaz nuevo alumno La interfaz consiste en un formulario donde el usuario deberá introducir los datos del alumno. Alguno de estos datos son obligatorios y serán identificados con un *. La interfaz también mostrará las clases donde hay plazas disponibles para apuntar al alumno. Figura 90. Interfaz nuevo alumno Al pulsar el botón, se comprobarán los siguientes datos: Si el DNI no es correcto se mostrará la siguiente ventana: Figura 91. Interfaz error DNI 82

85 Si el alumno ya existe se mostrará la siguiente ventana: Figura 92. Interfaz error existe alumno El no es un campo obligatorio, pero si se introduce un que no siga el formato aparecerá la siguiente pantalla: Figura 93. Interfaz error El CP y el teléfono también serán comprobados: Figura 94. Interfaz error cp Finalmente, cuando un alumno ha sido guardado se mostrará la siguiente ventana de confirmación: Figura 95. Interfaz confirmación alumno guardado 83

86 Interfaz borrar alumno En este caso, se mostrará una lista de todos los alumnos activos. El usuario seleccionará uno de ellos y pulsará el botón Figura 96- Interfaz borrar alumno El usuario deberá confirmar mediante la siguiente pantalla si verdaderamente desea borrarlo: Figura 97. Interfaz confirmar borrar alumno Interfaz modificar alumno En la siguiente pantalla, de primeras, el botón aparecerá inactivo, el usuario deberá primero seleccionar el alumno, del cual quiere ver sus datos, y a continuación pulsar el botón. 84

87 Figura 98. Interfaz modificar alumno Una vez mostrados los datos, el usuario podrá modificar tanto los datos que desee, como matricularlo o darle de baja de una clase a través de los controles que se muestran en la sección Clases. Al igual que en el apartado anterior, se comprobarán los datos y se mostrará el aviso correspondiente si no son correctos. 85

88 Interfaz consultar alumnos activos Este apartado se asemeja mucho al anterior, la única diferencia es que aquí sólo se mostrarán los datos sin posibilidad de modificarlos: Figura 99. Interfaz consultar alumno activo Interfaz consultar alumnos inactivos La interfaz es exactamente la misma que la de consultar alumnos activos, sólo que en la lista desplegable encontraremos los alumnos inactivos en vez de los activos Interfaz activar viejos alumnos En esta ventana se permitirá activar los alumnos que fueron dados de baja (borrados) en algún momento. 86

89 Figura 100. Interfaz activar alumno Una vez pulsado el botón Activar, se pedirá una confirmación de que verdaderamente se quiere activar dicho alumno: Figura 101. Interfaz confirmación activar alumno Y posteriormente, si se ha aceptado, se mostrará un mensaje de confirmación: Figura 102. Interfaz aviso alumno activado Interfaz gestión de recibos La siguiente pantalla, mostrará las opciones que puede realizar el usuario sobre un determinado recibo. 87

90 Figura 103. Interfaz gestión recibos Interfaz nuevo recibo Se mostrará un formulario desde el que se podrá seleccionar el alumno para el que se quiere crear un recibo, permitiéndose introducir los datos del recibo. Figura 104. Interfaz nuevo recibo Interfaz borrar recibo Esta ventana consistirá en dos listas desplegables, en una de ellas el usuario seleccionará el alumno del recibo y posteriormente pulsará el botón. La segunda lista desplegable se cargará con las fechas de los recibos del alumno seleccionado anteriormente. 88

91 Por último, se pulsará el botón mostrará el correspondiente aviso. y después de confirmar, se Figura 105. Interfaz borrar recibo Interfaz consultar recibo Seguirá el mismo diseño que Consultar alumno Interfaz modificar recibo Seguirá el mismo diseño que Modificar alumno Interfaz gestión de productos La siguiente pantalla mostrará las diferentes acciones que el usuario puede realizar relacionadas con los productos. Figura 106. EER Venta 89

92 Interfaz nuevo producto La interfaz contendrá un formulario donde el usuario rellenará los diferentes campos del producto. Previamente deberá seleccionar el tipo de producto. Figura 107. Interfaz nuevo producto Interfaz borrar producto Esta interfaz contendrá dos listas despegables. En la primera de ellas se seleccionará el modelo del producto que se desea borrar y en la segunda lista desplegable, su referencia. Figura 108. Interfaz borrar producto 90

93 Interfaz consultar producto Seguirá el mismo diseño que los dos módulos anteriores de este tipo ( Consultar alumno y Consultar recibo ), exceptuando que en esta parte se seleccionará el modelo y referencia del producto a consultar Interfaz modificar producto Seguirá el mismo diseño que los dos módulos anteriores de este tipo ( Modificar alumno y Modificar recibo ), exceptuando que en esta parte se seleccionará el modelo y referencia del producto a modificar Interfaz gestión de clases Mostrará las opciones que el usuario puede realizar respecto a las clases impartidas en la tienda. Figura 109. Interfaz gestión de clases Interfaz nueva clase Se mostrará un formulario que el usuario rellenará con los datos de la clase a crear. Figura 110. Interfaz nueva clase 91

94 Interfaz borrar clase Consistirá en una lista desplegable con todas las clases ordenadas por año, en la cual el usuario seleccionará la que desea borrar. Figura 111. Interfaz borrar clase Si el usuario selecciona una clase que tiene alumnos, se mostrará una ventana de aviso: Figura 112. Interfaz confirmación borrar clase Interfaz consultar clase Seguirá un diseño similar a las otras opciones de consulta Interfaz modificar clase Seguirá un diseño similar a las otras opciones de modificación. Se comprobarán los datos una vez pulsado el botón Interfaz gestión de ventas Mostrará las opciones que el usuario puede realizar con relación a las ventas. Esta interfaz también añadirá las gestiones de encargos y la opción de generar un informe de ventas. 92

95 Figura 113. Interfaz gestión de ventas Interfaz nueva venta Análogamente a las gestiones de este tipo, se mostrará un formulario mediante el cual el usuario rellenará los diferentes campos solicitados. Figura 114. Interfaz nueva venta 93

96 Interfaz nuevo encargo Análogamente al apartado anterior, podremos guardar un encargo. Figura 115. Interfaz nuevo encargo Interfaz borrar venta Se seleccionará la venta a borrar buscándola entre un rango de fechas. Figura 116. Interfaz borrar venta Una vez mostradas las ventas, el usuario tendrá la opción de borrar sólo alguna de ellas o todas. 94

97 Interfaz borrar encargo Igual que en el caso anterior, pero con encargos Interfaz modificar venta Se buscará la venta a modificar buscando previamente entre un rango de fechas. Cuando se muestren los datos, el usuario podrá modificar los datos de la venta. Figura 117. Interfaz modificar venta Interfaz modificar encargo Forma similar que en el apartado anterior pero con encargos Interfaz consultar venta De igual manera que en los casos anteriores, se buscará la venta a consultar mediante un rango de dos fechas: 95

98 Figura 118. Interfaz consultar venta Interfaz consultar encargo De forma análoga al apartado anterior Interfaz generar informe Permitirá realizar un informe de ventas entre las fechas seleccionadas. Figura 119. Interfaz generar informe 96

99 3.4.7 Interfaz gestión de almacén Figura 120. Interfaz gestión de almacén Interfaz nuevo pedido Mostrará los datos que el usuario debe introducir y seleccionar para crear un nuevo pedido. Figura 121. Interfaz nuevo pedido 97

100 Interfaz borrar pedido Mostrará una lista desplegable donde el usuario seleccionará el nombre del proveedor. Además contará con la opción de seleccionar un rango de fechas para buscar el pedido y posteriormente borrarlo. También se permitirá borrar todos los pedidos que aparezcan en lista de pedidos mostrados. Figura 122. Interfaz borrar pedido Interfaz modificar pedido Mostrará dos listas desplegables para seleccionar el proveedor y la fecha. Posteriormente se pulsará el botón Mostrar y se mostrarán los datos del pedido, pudiéndolos modificar. Figura 123. Interfaz modificar pedido 98

101 Interfaz consultar pedido Análogamente al apartado anterior, aparecerán los datos del pedido habiendo seleccionado previamente el proveedor y una fecha. Figura 124. Interfaz consultar pedido Interfaz gestión de clientes Mostrará las opciones que el usuario puede realizar relacionadas con clientes. Figura 125. Interfaz gestión de clientes 99

102 Interfaz nuevo cliente Mostrará los datos necesarios que el usuario debe introducir para dar de alta un cliente. Figura 126. Interfaz nuevo cliente Interfaz borrar cliente Se mostrará una lista desplegable donde el usuario seleccionará el cliente a borrar. Figura 127. Interfaz borrar cliente Interfaz consultar cliente De forma análoga a los apartados anteriores de este tipo. 100

103 Interfaz modificar cliente La interfaz contendrá una lista desplegable donde el usuario seleccionará el cliente que quiere modificar. A continuación pulsará el botón Mostrar y se mostrarán los datos del cliente, modificando el usuario los que desee. Figura 128. Interfaz modificar cliente Interfaz gestión de proveedores Mostrará las opciones que el usuario puede realizar relacionadas con proveedores. Figura 129. Interfaz gestión de proveedores 101

104 Interfaz nuevo proveedor Se mostrará un formulario dónde el usuario introducirá los datos del proveedor. Figura 130. Interfaz nuevo proveedor Interfaz borrar proveedor La interfaz contendrá una lista desplegable en la que el usuario seleccionará el nombre del proveedor que desea borrar. A continuación se pulsará el botón Borrar. Figura 131. Interfaz borrar proveedor 102

105 Interfaz consultar proveedor De forma análoga a los apartados anteriores de este tipo Interfaz modificar proveedor De forma análoga a los apartados anteriores de este tipo. 4. Implementación de la aplicación de escritorio A continuación se mostrarán los aspectos que consideramos más importantes de la implementación. 4.1 Capas de presentación y lógica de negocio Librerías utilizadas JCalendar En algunos módulos se ha considerado interesante que el usuario tenga a su disposición un calendario gráfico para que, a la hora de seleccionar una fecha, lo tenga más sencillo y no deba introducirla de forma manual. Itext Esta librería nos ha permitido generar los informes de ventas en formato PDF desde Java. En particular, para la generación de los informes de ventas, se ha utilizado el siguiente código: public class PdfVentas { public void crearpdfinforme(list<venta> ventas, String fecha1, String fecha2) { Document documento = new Document(); try { GestorBD gbd = new GestorBD(); SimpleDateFormat formato; formato = new SimpleDateFormat("dd/MM/yyyy HH:mm"); 103

106 File f1 = new File("Informe de Ventas.pdf"); FileOutputStream fichero = new FileOutputStream(f1); PdfWriter.getInstance(documento, fichero); documento.open(); //Calculo el importe total de todas las ventas float total = 0; for (int j = 0; j < ventas.size(); j++) { total = total + ventas.get(j).getimportetotal(); } PdfPTable tablatotal = new PdfPTable(1); //creo la tabla tablatotal.getdefaultcell().setborderwidth(20); //borde de la tabla float[] medidatablatotal = {0.5f}; //anchura tablatotal.setwidths(medidatablatotal); tablatotal.setwidthpercentage(20); //% que ocupa de pantalla tablatotal.sethorizontalalignment(element.align_right); //alineación PdfPCell celltotal; //celdas celltotal = new PdfPCell(new Paragraph("Total :" + gbd.redondear(total) + " ", FontFactory.getFont("Arial", 14, Font.BOLD, BaseColor.BLACK))); celltotal.setcolspan(1); celltotal.sethorizontalalignment(element.align_justified); tablatotal.addcell(celltotal); PdfPTable tabladatos = new PdfPTable(1); float[] medidatabladatos = {0.6f}; tabladatos.setwidths(medidatabladatos); tabladatos.setwidthpercentage(70); tabladatos.sethorizontalalignment(element.align_left); PdfPCell celldatos; if (fecha1 == null && fecha2 == null) { //según que fechas se hayan rellenado muestra //una cosa u otra celldatos = new PdfPCell(new Paragraph("Informe de todas las ventas :", FontFactory.getFont("Arial", 12, Font.BOLD, BaseColor.BLACK))); celldatos.setcolspan(1); celldatos.sethorizontalalignment(element.align_center); tabladatos.addcell(celldatos); } if (fecha1 == null && fecha2!= null) { celldatos = new PdfPCell(new Paragraph("Informe de las ventas hasta el : " + fecha2, FontFactory.getFont("Arial", 12, Font.BOLD, BaseColor.BLACK))); celldatos.setcolspan(1); celldatos.sethorizontalalignment(element.align_center); tabladatos.addcell(celldatos); } if (fecha1!= null && fecha2 == null) { celldatos = new PdfPCell(new Paragraph("Informe de las ventas desde el : " + fecha1, FontFactory.getFont("Arial", 12, Font.BOLD, BaseColor.BLACK))); celldatos.setcolspan(1); celldatos.sethorizontalalignment(element.align_center); tabladatos.addcell(celldatos); } if (fecha1!= null && fecha2!= null) { celldatos = new PdfPCell(new Paragraph("Informe de las ventas desde : " + fecha1 + " hasta el: " + fecha2, FontFactory.getFont("Arial", 12, Font.BOLD, BaseColor.BLACK))); celldatos.setcolspan(1); celldatos.sethorizontalalignment(element.align_center); tabladatos.addcell(celldatos); } documento.add(tabladatos); //añade la tabla al documento 104

107 Image logo = Image.getInstance("src/Imagenes/icono.png"); //ponemos el logo de la //tienda logo.setalignment(chunk.align_right); logo.scaletofit(90, 90); documento.add(logo); agregarlineasenblanco(documento, 3); PdfPTable tabla = new PdfPTable(7); float[] medidaceldas = {0.6f, 0.7f, 1.2f, 0.8f, 0.7f, 1.0f, 0.7f}; //anchura de las celdas tabla.setwidths(medidaceldas); tabla.setwidthpercentage(100); tabla.sethorizontalalignment(element.align_center); //ahora damos valor a cada una de las celdas PdfPCell cell1 = new PdfPCell(new Phrase("Nº Venta", FontFactory.getFont("Arial", 12, Font.BOLD, BaseColor.BLACK))); cell1.sethorizontalalignment(element.align_center); tabla.addcell(cell1); PdfPCell cell2 = new PdfPCell(new Phrase("Nº Linea", FontFactory.getFont("Arial", 12, Font.BOLD, BaseColor.BLACK))); cell2.sethorizontalalignment(element.align_center); tabla.addcell(cell2); PdfPCell cell3 = new PdfPCell(new Phrase("Fecha", FontFactory.getFont("Arial", 12, Font.BOLD, BaseColor.BLACK))); cell3.sethorizontalalignment(element.align_center); tabla.addcell(cell3); PdfPCell cell4 = new PdfPCell(new Phrase("Referencia", FontFactory.getFont("Arial", 12, Font.BOLD, BaseColor.BLACK))); cell4.sethorizontalalignment(element.align_center); tabla.addcell(cell4); PdfPCell cell5 = new PdfPCell(new Phrase("Cantidad", FontFactory.getFont("Arial", 12, Font.BOLD, BaseColor.BLACK))); cell5.sethorizontalalignment(element.align_center); tabla.addcell(cell5); PdfPCell cell6 = new PdfPCell(new Phrase("Precio/Unidad", FontFactory.getFont("Arial", 12, Font.BOLD, BaseColor.BLACK))); cell6.sethorizontalalignment(element.align_center); tabla.addcell(cell6); PdfPCell cell7 = new PdfPCell(new Phrase("SubTotal", FontFactory.getFont("Arial", 12, Font.BOLD, BaseColor.BLACK))); cell7.sethorizontalalignment(element.align_center); tabla.addcell(cell7); List<LineaDeVenta> lineaventa = null; for (int i = 0; i < ventas.size(); i++) { lineaventa = gbd.getlineaventa(ventas.get(i).getnumventa()); for (int aux = 0; aux < lineaventa.size(); aux++) { tabla.addcell(string.valueof(ventas.get(i).getnumventa())); tabla.addcell(string.valueof(lineaventa.get(aux).getnumerolinea())); tabla.addcell(string.valueof(formato.format(ventas.get(i).getfecha()))); tabla.addcell(lineaventa.get(aux).getproducto()); tabla.addcell(string.valueof(lineaventa.get(aux).getcantidad())); tabla.addcell(string.valueof(gbd.redondear(lineaventa.get(aux).getpreciototal() / lineaventa.get(aux).getcantidad()))); tabla.addcell(string.valueof(lineaventa.get(aux).getpreciototal())); } } documento.add(tabla); agregarlineasenblanco(documento, 2); documento.add(tablatotal); documento.close(); 105

108 Desktop d = Desktop.getDesktop(); d.open(f1); } catch (DocumentException e) { // TODO Auto-generated catch block System.out.println("ERROR: Se ha producido un error al generar el contenido."); // throw new ExcepcionDeAplicacion(e); } catch (FileNotFoundException e) { // TODO Auto-generated catch block e.printstacktrace(); // throw new ExcepcionDeAplicacion(e); } catch (IOException e) { // TODO Auto-generated catch block e.printstacktrace(); } } private static void agregarlineasenblanco(document d, int nlineas) throws DocumentException { for (int i = 0; i < nlineas; i++) { d.add(new Paragraph(" ")); } } } Métodos de validación y comprobación Validación DNI El siguiente método comprueba si el DNI es correcto o no. Validación El siguiente método comprueba si el es válido, es decir, que sigue el formato nombreusuario@dominio. 106

109 Validación teléfono El siguiente método comprueba si el teléfono introducido es válido, es decir si está compuesto por 9 dígitos. Validación código postal El siguiente método comprueba si el código postal introducido es válido, es decir, está formado por 5 dígitos. Validación importe El siguiente método comprobará si un importe introducido es válido, es decir, es un número real. 107

110 4.1.3 Fragmentos de código de interés En algunos apartados, como por ejemplo, en la interfaz de borrar un encargo, similar a la de borrar una venta (página 92), se ha hecho uso de un jtable que es un componente visual de forma que nos permite dibujar una tabla. Paso 1: Una forma de Java que nos permite utilizar una tabla es el llamado jtable que consiste en instanciar como modelo de datos un DefaultTableModel. Paso 2: A continuación se le da nombre a las columnas de mi tabla. Paso 3: Se le asocia al jtable el modelo creado en el paso 1. Paso 4: Se establecen los anchos de cada columna de mi tabla. 108

111 Para mostrar los datos se realizan los siguientes pasos realizados en el método buscaractionperformed : Paso 5: Eliminamos los posibles datos que tenga la tabla. Paso 6: Se crea una lista de los datos a mostrar. Paso 7: Recorremos la lista anterior, buscando los datos que nos interesan. Paso 8: Creamos un vector llamado datos, de tres componentes que corresponderán al valor de cada columna de nuestro jtable. Paso 9: A cada componente del vector datos le asignamos el valor que queremos que muestre de la lista del paso 6. Paso 10: Añadimos al modelo el vector datos. El resultado es la tabla que se ha señalado en la siguiente imagen: 109

112 También se ha hecho uso de la siguiente clase, para generar de forma automática, las contraseñas de clientes y alumnos, para poderlo utilizar en un futuro en la aplicación Web. 4.2 Capa de persistencia La capa de persistencia se ha desarrollado utilizando JDBC, que es una API de Java que nos permite ejecutar instrucciones SQL. En particular, es un conjunto de clases e interfaces Java que proporciona a las aplicaciones Java un mecanismo estándar e independiente de la plataforma para el acceso a BDs SQL Conexión a la BD Una vez creada la Base de datos, debemos crear una conexión a ésta desde la aplicación desarrollada en Java.. Para ello hemos usado el Driver o Conector mysql-connector-java bin.jar. El código que se muestra a continuación, se ha incluido en la clase que se ha creado para implementar la capa de persistencia, en particular, se ha incluido en el constructor de ésta, dentro de un bloque static: 110

113 4.2.2 Concurrencia Puesto que la concurrencia es una propiedad por la cual se permite que múltiples procesos sean ejecutados al mismo tiempo, no se ha considerado en la realización del presente proyecto, porque la aplicación sólo va a ser usada por una persona al mismo tiempo, es decir, no va a haber acceso concurrente en la aplicación. Cuando se haga una ampliación con la página web, tendremos que controlar la concurrencia Transaccionalidad Se ha tenido especial cuidado en establecer contextos transaccionales de forma que cuando ha sido necesario ejecutar varias instrucciones de modificación sobre la BD de manera conjunta, dependiendo unas de otras, éstas se han ejecutado en una única transacción, de forma que se completan (commit) o anulan (rollback) en su totalidad (en el caso de que por algún motivo haya que deshacer los cambios). A continuación se muestra un método desarrollado utilizando la tecnología JDBC mediante el cual un alumno es apuntado a una clase. En este método las instrucciones (inserción y modificación) se ejecutan como una única transacción: 111

114 public void apuntaralumnoaclase(alumno alum, Clase clase) { Connection con = conectar(); try { con.setautocommit(false); //Desactivamos el modo autocommit de forma que la transacción no finaliza hasta que se confirme el commit o se deshagan los cambios (rollback) if (sitioenclase(clase)) { PreparedStatement pstmtapuntar = con.preparestatement("insert into alumno_clase values(?,?,?)"); pstmtapuntar.setstring(1, alum.getdni()); pstmtapuntar.setstring(2, clase.gethorario()); pstmtapuntar.setint(3, clase.getagno()); pstmtapuntar.executeupdate(); //Modificamos las plazas disponibles de la clase PreparedStatement pstmtclaseplazasd = con.preparestatement("update clase set PlazasDisponibles=? where horario=? and año=?"); pstmtclaseplazasd.setint(1, clase.getplazasdisponibles() - 1); pstmtclaseplazasd.setstring(2, clase.gethorario()); pstmtclaseplazasd.setint(3, clase.getagno()); pstmtclaseplazasd.executeupdate(); pstmtclaseplazasd.close(); pstmtapuntar.close(); con.commit(); } } catch (SQLException e) { // TODO Auto-generated catch block e.printstacktrace(); try { if (con!= null) { con.rollback();//si hay algún problema deshacemos los cambios } } catch (SQLException e1) { // TODO Auto-generated catch block e1.printstacktrace(); } } finally { desconectar(con); } } 112

115 A continuación se muestra otro ejemplo de un método JDBC en el que la instrucción SQL se trata de una simple consulta: public Alumno getalumnoinactivo(string dnialumno) { Alumno alumno = null; Connection con = conectar(); try { PreparedStatement pstalumno = con.preparestatement("select * from historicoalumnos where DNI=?"); pstalumno.setstring(1,dnialumno); ResultSet rsalumno = pstalumno.executequery(); if (rsalumno.next()){ //Construimos objeto alumno alumno = new Alumno(rsAlumno.getString("DNI"), rsalumno.getstring("nombre"), rsalumno.getstring("apellidos"),rsalumno.getstring("domicilio"), rsalumno.getstring("ciudad"), rsalumno.getint("cp"), rsalumno.getint("telefono"), rsalumno.getstring(" ")); } rsalumno.close(); pstalumno.close(); } catch (SQLException ex) { ex.printstacktrace(); } finally { if (con!= null) { desconectar(con); } } return alumno; } 4.3 Breve reseña a la implementación de la BD. Triggers Como se ha comentado anteriormente, la aplicación gestiona un registro de históricos relacionado con los alumnos que un día dejaron de asistir a las clases y son dados de baja. La clienta desea conservar los datos de esos alumnos y por ello se ha creado el siguiente trigger que, siempre que se elimina un alumno de la tabla alumno (alumnos activos), se ejecuta la instrucción de inserción correspondiente en la tabla HistoricoAlumnos. Nota.- En los anexos se adjunta el diseño lógico de la BD. 113

116 5. Pruebas de la aplicación de escritorio A continuación, se muestran algunas de las pruebas realizadas: Prueba Nº 1 Descripción Introducir un nuevo alumno Resultado esperado El alumno ha sido guardado correctamente y ha sido apuntado a las clases seleccionadas. Resultado obtenido Resultado esperado. Prueba Nº 2 Descripción Borrar un alumno Resultado esperado El alumno es borrado de la aplicación. Resultado obtenido No se actualiza el número de plazas de las clases a las que asistía el alumno. Prueba Nº 3 Descripción Modificar alumno Resultado esperado Es posible modificar todos los datos del alumno así como las clases a las que asiste. Resultado obtenido Resultado esperado. Prueba Nº 4 Descripción Consultar alumno Resultado esperado Tras seleccionar el alumno se muestran sus datos. Resultado obtenido Resultado esperado. Prueba Nº 5 Descripción Crear nuevo recibo. Resultado esperado Se crea un recibo. Resultado obtenido Los alumnos no activos aparecen en el combo de alumnos activos. Se modifica código para que no aparezcan. Prueba Nº 6 Descripción Borrar recibo Resultado esperado El recibo es borrado de la aplicación. Resultado obtenido Los alumnos no activos aparecen en el combo de alumnos activos. Se modifica código para que no aparezcan. Prueba Nº 7 Descripción Modificar recibo Resultado esperado Se modifican los datos del recibo seleccionado. Resultado obtenido El botón Modificar aparece activo sin haber seleccionado algún recibo antes. Se modifica el código. Prueba Nº 8 Descripción Consultar recibo. Resultado esperado Muestra los datos del recibo seleccionado. Resultado obtenido El botón Consultar aparece activo sin haber seleccionado ningún recibo antes, se modifica el código. 114

117 Prueba Nº 9 Descripción Nuevo producto. Resultado esperado Introduce un nuevo producto. Resultado obtenido No se aumentan las unidades del stock asociadas al producto. Se modifica el código para tal fin. Prueba Nº 10 Descripción Modificar producto. Resultado esperado Permite modificar los datos de un producto. Resultado obtenido Resultado esperado. Prueba Nº 11 Descripción Consultar producto. Resultado esperado Muestra datos de un determinado producto. Resultado obtenido Resultado esperado. Prueba Nº 12 Descripción Se introduce una nueva clase con número de plazas menor que el número de plazas disponibles. Resultado esperado Se comprueba que él número de plazas es menor que el número de plazas disponibles. Resultado obtenido No se comprueba y se modifica el código. Prueba Nº 13 Descripción Borrar clase. Resultado esperado Borra la clase seleccionada. Si la clase que se va a eliminar tiene alumnos, se debe mostrar un mensaje de aviso. Resultado obtenido Resultado esperado. Prueba Nº 14 Descripción Modificar clase. Resultado esperado Permite modificar los datos de una clase. Resultado obtenido Si no se muestran datos el botón Modificar permanece activo. Se modifica el código para que aparezca inactivo en caso de que no se muestren datos. Prueba Nº 15 Descripción Consultar clase. Resultado esperado Muestra datos de una clase seleccionada. Resultado obtenido Resultado esperado. Prueba Nº 16 Descripción Nueva venta. Resultado esperado Crea una nueva venta. Resultado obtenido No se disminuyen las unidades en stock del producto vendido. Se modifica el código para tal fin. Prueba Nº 17 Descripción Se intenta borrar una venta introduciendo la fecha inferior del rango con un valor superior al de la fecha superior del rango. Resultado esperado Muestra un mensaje de error. Resultado obtenido No se obtiene ningún mensaje de error, se modifica el código. 115

118 Prueba Nº 18 Descripción Modificar venta. Resultado esperado Permite modificar los datos de una venta. Resultado obtenido Resultado esperado. Prueba Nº 19 Descripción Consultar venta. Resultado esperado Muestra los datos de una venta. Resultado obtenido La tabla donde se muestran las líneas de ventas es editable y no lo debe de ser. Se modifica el código para tal fin. Prueba Nº 20 Descripción Nuevo encargo. Resultado esperado Crea un nuevo encargo. Resultado obtenido Resultado esperado. Prueba Nº 21 Descripción Borrar encargo. Resultado esperado Borra un encargo seleccionado o varios. Resultado obtenido Aparecen ventas y encargos a seleccionar, se modifica el código para que sólo aparezcan los encargos. Prueba Nº 22 Descripción Modificar encargo. Resultado esperado Permite modificar los datos de un encargo. Resultado obtenido Resultado esperado. Prueba Nº 23 Descripción Consultar encargo. Resultado esperado Muestra los datos del encargo seleccionado. Resultado obtenido Resultado esperado. Prueba Nº 24 Descripción Nuevo pedido. Resultado esperado Crea un pedido nuevo. Resultado obtenido No se han aumentado las unidades en stock cuando se recibe. Se modifica el código para tal fin. Prueba Nº 25 Descripción Borrar pedido. Resultado esperado Borra el pedido o pedidos seleccionados. Resultado obtenido Resultado esperado. Prueba Nº 26 Descripción Modificar pedido. Resultado esperado Permite modificar datos de un pedido. Resultado obtenido Resultado esperado. Prueba Nº 27 Descripción Consultar pedido. Resultado esperado Muestra datos del pedido seleccionado. Resultado obtenido Resultado esperado. 116

119 Prueba Nº 28 Descripción Nuevo cliente. Resultado esperado Introduce un nuevo cliente en la aplicación. Resultado obtenido Resultado esperado. Prueba Nº 29 Descripción Borrar cliente. Resultado esperado Borra el cliente seleccionado. Resultado obtenido Resultado esperado. Prueba Nº 30 Descripción Modificar cliente. Resultado esperado Permite modificar algunos de los datos del cliente. Resultado obtenido Resultado esperado. Prueba Nº 31 Descripción Consultar cliente. Resultado esperado Muestra los datos del cliente seleccionado. Resultado obtenido Resultado esperado. Prueba Nº 32 Descripción Nuevo proveedor. Resultado esperado Crea un nuevo proveedor. Resultado obtenido Resultado esperado. Prueba Nº 33 Descripción Borrar proveedor. Resultado esperado Borra el proveedor seleccionado. Resultado obtenido Resultado esperado. Prueba Nº 34 Descripción Modificar proveedor. Resultado esperado Permite modificar datos de un proveedor. Resultado obtenido Resultado esperado. Prueba Nº 35 Descripción Consultar proveedor. Resultado esperado Muestra los datos del proveedor seleccionado. Resultado obtenido Resultado esperado. 117

120 6. Gestión real del proyecto y conclusiones Destacaremos ante todo que al iniciarse el desarrollo del proyecto al principio se pensó en realizar, además de la aplicación de escritorio presentada, un sitio web. Aún así, no se han cumplido los tiempos que se estimaron en la realización de cada tarea. Ésto ha sido debido sobre todo a que se han producto algunos de los riegos tratados en el DOP de la presente memoria. A continuación se muestra una tabla que contiene una relación de horas estimadas y reales: Tarea Horas estimadas Horas reales Análisis de requisitos Análisis Diseño Implementación Pruebas Documentación Implantación Total Como no se ha terminado de desarrollar la aplicación Web, algunas tareas se han realizado en menos tiempo del estimado. De ahí aquí algunas tareas hayan sido realizadas en menos tiempo del estimado. Aún así la estimación no ha sido buena, puesto que si hubiéramos terminado la fase de diseño de la aplicación Web y realizada su implementación, las horas estimadas se nos hubieran quedado muy cortas. A continuación mostramos los motivos del desfase: Motivos del desfase: Motivos de salud Me he visto afectada por varios problemas de salud que han contribuido a retrasar el proyecto en varias semanas. 118

121 Inexperiencia En algunos componentes swing se ha debido de buscar información para lograr entender cómo funcionan realmente. 6.1 Conclusiones Una vez finalizado el proyecto y tras un pequeño periodo tiempo de reflexión puedo afirmar que ha sido más costoso de lo que esperaba. Al tratarse de un proyecto de esta magnitud, empezando desde cero, y para un cliente real ha hecho que durante el desarrollo del mismo me hayan surgido algunas complicaciones a la hora de tomar decisiones. Como he adelantado en apartados anteriores, la clienta, no posee conocimientos de informática y a la hora de recoger información para el análisis, se centraba en representar su objetivo de una forma gráfica, es decir, cómo ver la información por pantalla. Por esta razón, me he visto obligada a pensar toda la funcionalidad de la aplicación, preguntando continuamente a la clienta, dudas que me han ido surgiendo, como por ejemplo, qué hacer con determinada información eliminada. Otro inconveniente ha sido que he tenido que compatibilizar el desarrollo del proyecto con otras actividades, lo cual ha provocado que no haya podido terminar el proyecto en la fecha estimada. En particular, al inicio del proyecto además de poseer una beca en el servicio informático de la universidad de La Rioja, se estaban cursando las tres últimas asignaturas de la carrera con la consecuente pérdida de tiempo. Para concluir diré que el resultado ha sido satisfactorio en un ámbito profesional ya que he cogido práctica, soltura y he aprendido cosas nuevas. También ha sido positivo en el plano personal porque he aprendido a conversar y comprender de una manera más competente, con el fin de evitar malos entendidos entre ambas partes. 7. Bibliografía Características de Joomla Características WordPress Características Drupal Comparativa Joomla, WordPress y Drupal Comparativa Joomla, WordPress y Drupal Comparativa Joomla, WordPress y Drupal 119

122 Uso JList Swing de Java Apuntes de asignaturas cursadas en la carrera. 8. Anexos 8.1 Actas de reunión A continuación se muestran las actas de reuniones realizadas con la tutora del proyecto: Fecha 14 de Febrero 2011 Lugar Logroño, Universidad La Rioja, Edificio Vives Hora inicio 18:00 Hora finalización 19:00 Asistentes - Beatriz Pérez Valle - Tania de Pedro Sáenz Orden del día Primera toma de contacto del proyecto Temas tratados Requisitos Temas pendientes Recoger requisitos del cliente Fecha 8 de Marzo 2011 Lugar Logroño, Universidad La Rioja, Edificio Vives Hora inicio 18:00 Hora finalización 19:30 Asistentes - Beatriz Pérez Valle - Tania de Pedro Sáenz Orden del día Gestores de contenidos web (CMS) Temas tratados CMS Temas pendientes Realizar estudio de CMS 120

123 Fecha 7 de Septiembre 2011 Lugar Logroño, Universidad La Rioja, Edificio Vives Hora inicio 11:30 Hora finalización 12:30 Asistentes - Beatriz Pérez Valle - Tania de Pedro Sáenz Orden del día Repaso de requisitos y CMS Temas tratados Repaso de requisitos y CMS Temas pendientes Corregir requisitos y CMS Fecha 13 de Octubre 2011 Lugar Logroño, Universidad La Rioja, Edificio Vives Hora inicio 18:00 Hora finalización 19:00 Asistentes - Beatriz Pérez Valle - Tania de Pedro Sáenz Orden del día DOP Temas tratados DOP Temas pendientes Realizar DOP Fecha 25 de Octubre 2011 Lugar Logroño, Universidad La Rioja, Edificio Vives Hora inicio 18:00 Hora finalización 19:30 Asistentes - Beatriz Pérez Valle - Tania de Pedro Sáenz Orden del día Diagramas casos de uso Temas tratados Diagramas casos de uso Temas pendientes Realización diagramas casos de uso Fecha 16 de Noviembre 2011 Lugar Logroño, Universidad La Rioja, Edificio Vives Hora inicio 18:00 Hora finalización 19:00 Asistentes - Beatriz Pérez Valle - Tania de Pedro Sáenz Orden del día Diagramas de clases Temas tratados Diagramas de clases Temas pendientes Diagramas de clases 121

124 Fecha 7 de Diciembre 2011 Lugar Logroño, Universidad La Rioja, Edificio Vives Hora inicio 13:00 Hora finalización 14:00 Asistentes - Beatriz Pérez Valle - Tania de Pedro Sáenz Orden del día Comentarios diagramas de actividad y de casos de uso Temas tratados Comentarios diagramas de actividad y de casos de uso Temas pendientes Corregir diagramas Fecha 31 de Enero 2012 Lugar Logroño, Universidad La Rioja, Edificio Vives Hora inicio 18:15 Hora finalización 19:30 Asistentes - Beatriz Pérez Valle - Tania de Pedro Sáenz Orden del día Diagramas de clases Temas tratados Diagramas de clases Temas pendientes Corregir diagramas de clases Fecha 13 de Febrero 2012 Lugar Logroño, Universidad La Rioja, Edificio Vives Hora inicio 17:00 Hora finalización 18:00 Asistentes - Beatriz Pérez Valle - Tania de Pedro Sáenz Orden del día Dudas diagrama EER Temas tratados Dudas diagrama EER Temas pendientes Corregir diagrama EER Fecha 9 de Mayo 2012 Lugar Logroño, Universidad La Rioja, Edificio Vives Hora inicio 16:15 Hora finalización 17:30 Asistentes - Beatriz Pérez Valle - Tania de Pedro Sáenz Orden del día Mostrar parte de la implementación realizada hasta el momento. Temas tratados Mostrar parte de la implementación realizada hasta el momento. Temas pendientes Mejorar implementación y finalizarla 122

125 Fecha 14 de Mayo 2012 Lugar Logroño, Universidad La Rioja, Edificio Vives Hora inicio 16:15 Hora finalización 17:30 Asistentes - Beatriz Pérez Valle - Tania de Pedro Sáenz Orden del día Mostrar aplicación completa. Temas tratados Mostrar aplicación completa. Temas pendientes Últimos retoques en la aplicación. Fecha 4 de Junio 2012 Lugar Logroño, Universidad La Rioja, Edificio Vives Hora inicio 09:00 Hora finalización 10:00 Asistentes - Beatriz Pérez Valle - Tania de Pedro Sáenz Orden del día Comentarios memoria. Temas tratados Mejorar memoria. Temas pendientes Corregir y mejorar memoria. La siguiente tabla contiene información sobre los s intercambiados con la directora: FECHA TEMA TRATADO 23/03/11 Dudas requisitos 12/09/11 Dudas requisitos 14/09/11 Dudas planing 18/10/11 Dudas DOP 05/11/11 Dudas análisis 07/11/11 Dudas CDU 08/11/11 Comentarios DOP y requisitos 27/01/12 Diagrama de clases aplicación escritorio 03/02/12 Dudas DC aplicación web e interfaces 07/02/12 Comentarios diagrama EER 29/02/12 Dudas EER y tablas 01/03/12 Dudas implementación 12/03/12 Dudas implementación 23/04/12 Dudas implementación 15/05/12 Dudas sobre últimos retoques 16/05/12 Dudas memoria 21/05/12 Dudas memoria 24/05/12 Dudas memoria 02/06/12 Dudas memoria 123

126 Las reuniones tratadas con el cliente no es que hayan sido más escasas, pero debido a la relación familiar, la mayoría de las veces han sido preguntas escuetas que se han hecho en momentos puntuales. Fecha 12de Febrero 2011 Lugar Logroño, Pauters Hora inicio 19:00 Hora finalización 20:30 Asistentes - Paulina Sáenz Ortega - Tania de Pedro Sáenz Orden del día Objetivos a realizar Temas tratados Objetos a realizar Temas pendientes Fecha 15 de Febrero 2011 Lugar Logroño, Domicilio del cliente Hora inicio 15:00 Hora finalización 16:30 Asistentes - Paulina Sáenz Ortega - Tania de Pedro Sáenz Orden del día Toma de requisitos Temas tratados Toma de requisitos Temas pendientes Realizar requisitos Fecha 10 de Septiembre 2011 Lugar Logroño, Domicilio del cliente Hora inicio 18:00 Hora finalización 19:00 Asistentes - Paulina Sáenz Ortega - Tania de Pedro Sáenz Orden del día Mejorar aspectos de requisitos Temas tratados Mejorar aspectos de requisitos Temas pendientes Mejorar requisitos Fecha 21 de Noviembre 2011 Lugar Logroño, Pauters Hora inicio 19:00 Hora finalización 20:00 Asistentes - Paulina Sáenz Ortega - Tania de Pedro Sáenz Orden del día Tipos de productos que hay en la tienda y características de ellos. Temas tratados Tipos de productos que hay en la tienda y características de ellos. Temas pendientes Realización de diagramas 124

127 Fecha 21 de Noviembre 2011 Lugar Logroño, Pauters Hora inicio 19:00 Hora finalización 20:00 Asistentes - Paulina Sáenz Ortega - Tania de Pedro Sáenz Orden del día Tipos de productos que hay en la tienda y características de ellos. Temas tratados Tipos de productos que hay en la tienda y características de ellos. Temas pendientes Realización de diagramas Fecha 10 de Mayo 2012 Lugar Logroño, Domicilio del cliente Hora inicio 13:30 Hora finalización 15:00 Asistentes - Paulina Sáenz Ortega - Tania de Pedro Sáenz Orden del día Muestra de la aplicación Temas tratados Muestra de la aplicación Temas pendientes Terminar aplicación. 8.2 Manual de usuario Una vez iniciada la aplicación se nos mostrará la siguiente pantalla: 125

128 8.1.1 Módulo alumnos Nuevo alumno: Si desea introducir un nuevo alumno, vaya al menú Alumnos y seleccione Nuevo. Se mostrará la siguiente pantalla: Introduzca los datos del alumno Para seleccionar varias clases, mantenga pulsada la tecla Ctrl del teclado de su ordenador. Borrar alumno: Si desea borrar un alumno, vaya al menú Alumnos y seleccione Borrar. Se mostrará la siguiente pantalla: 126

129 Seleccione el alumno que desea borrar. Pulse el botón Borrar. Modificar alumno: Si desea modificar algún dato de un alumno, vaya al menú Alumnos y seleccione Modificar. Se mostrará la siguiente pantalla: Seleccione el alumno que desea modificar. Pulse el botón Mostrar. Modifique los datos que desee. Para borrar de una clase, dentro del apartado Clases a las que asiste seleccione la clase o clases a borrar (si son varias mantenga pulsado la tecla Ctrl de su teclado) y presione el botón. De forma análoga para apuntar a una clase, pero seleccionando la clase o las clases a apuntarse del apartado Clases disponibles y pulsando el botón. Para finalizar pulse el botón Modificar. 127

130 Consultar alumno activo: Si desea consultar información sobre un alumno activo, vaya al menú Alumnos y seleccione Consultar alumnos activos. Se mostrará la siguiente pantalla: Seleccione el alumno del cual desea consultar su información. Pulse el botón Consultar. Consultar alumno inactivo: Si desea consultar información sobre un alumno inactivo, vaya al menú Alumnos y seleccione Consultar alumnos inactivos. El procedimiento que sigue es igual que en el caso de consultar alumnos activos. Activar alumno. Si desea activar un alumno, vaya al menú Alumnos y seleccione Activar viejos alumnos. Se mostrará la siguiente pantalla: 128

131 Seleccione el nombre del alumno que desea activar. Pulse el botón Activar Módulo recibos Nuevo recibo Si desea crear un recibo vaya al menú Recibos y pulse Nuevo. Se mostrará la siguiente pantalla: Rellene los datos solicitados relacionados con el recibo. Pulse el botón Crear. Borrar recibo Si desea borrar un recibo, vaya al menú Recibos y pulse sobre Borrar. Se mostrará la siguiente pantalla: 129

132 Seleccione el alumno del que desea borrar el recibo. Pulse sobre Buscar recibos. Seleccione en el apartado fecha el recibo a borrar. Pulse Borrar. Modificar recibo Si desea modificar alguno de los datos de un recibo, vaya al menú Recibos y pulse sobre Modificar. Se mostrará la siguiente pantalla: Seleccione el alumno del que desea modificar el recibo. Pulse sobre Buscar recibos. Seleccione en el apartado fecha el recibo a borrar. 130

133 Pulse Mostrar. Modifique los datos que desee y pulse Modificar. Consultar recibo De forma análoga al apartado anterior Módulo productos Nuevo producto Vaya al modulo Productos y pulse sobre Nuevo. Se mostrará la siguiente pantalla: Dependiendo del modelo del producto elegido se mostrarán unos datos u otros que debe de introducir. Si selecciona el modelo Herramienta aparecerá una nueva lista desplegable dónde debe seleccionar el modelo de herramienta. 131

134 Borrar producto Vaya al modulo Productos y pulse sobre el botón Borrar. Se mostrará la siguiente pantalla: Seleccione el modelo de producto y su referencia y pulse sobre Borrar. Modificar producto Vaya al modulo Productos y pulse sobre Modificar. Se mostrará la siguiente pantalla: Seleccione el modelo de producto y su referencia y pulse el botón Mostrar. 132

135 Modifique los datos que desee y pulse sobre Modificar. Consultar producto Vaya al modulo Productos y pulse sobre Consultar. Se mostrará una pantalla similar al apartado anterior. Seleccione el modelo de producto y su referencia y pulse el botón Consultar Módulo clases Nueva clase Vaya al modulo Clases y pulse sobre el botón Nueva. Se mostrará la siguiente pantalla: Introduzca los datos de la clase. Pulse el botón Crear. Borrar clase Vaya al modulo Clases y pulse sobre Borrar. Se mostrará la siguiente pantalla: Seleccione la clase que desea borrar y pulse el botón Borrar. 133

136 Modificar clase Vaya al modulo Clases y pulse sobre Modificar. Se mostrará la siguiente pantalla: Seleccione el año y el nombre de la clase que desea modificar. Pulse el botón Mostrar y modifique los datos que desee. Pulse el botón Modificar. Consultar clase Vaya al modulo Clases y pulse sobre Consultar. Se mostrará una pantalla similar al apartado anterior. Seleccione el año y el nombre de la clase que desea consultar. Pulse el botón Consultar clase Módulo ventas Nueva venta Vaya al modulo Ventas y pulse sobre Nueva. Se mostrará la siguiente pantalla: 134

137 Introduzca los datos de la venta. Pulse el botón Guardar Borrar venta Vaya al modulo Ventas y pulse sobre Borrar. Se mostrará la siguiente pantalla: Introduzca fecha de inicio y fecha de final si desea. o Si no introduce ninguna fecha se mostrarán todas las ventas hasta el día de hoy. o Si introduce sólo la fecha de inicio, se mostrarán todas las ventas desde la citada fecha. 135

138 o Si se introduce sólo la fecha fin, se mostrarán todas las ventas hasta la citada fecha. o Si se introducen las dos fechas, se mostrarán las ventas comprendidas entre las dos fechas. Pulse el botón Buscar ventas Si desea borrar todas las ventas mostradas pulse el botón Borrar todas. Si desea borrar sólo una venta selecciónela y pulse el botón Borrar. Si desea borrar dos o más ventas pero no todas, vaya seleccionándolas manteniendo pulsada la tecla Ctrl de su teclado y pulse Borrar. Modificar venta Vaya al modulo Ventas y pulse sobre Modificar. Se mostrará la siguiente pantalla: Seleccione un rango de fechas si lo desea (al igual que borrar venta). Pulse el botón Buscar ventas y seleccione la venta que desea modificar. Modifique las cantidades que desee para ello haga doble clic sobre el cantidad a modificar, modifique la cantidad y pulse la tecla Intro. Pulse el botón Modificar. 136

139 Consultar venta Vaya al modulo Ventas y pulse sobre Consultar. Se mostrará una pantalla similar al apartado anterior. Seleccione un rango de fechas si lo desea (al igual que borrar venta). Pulse el botón Buscar ventas y seleccione la venta que desea consultar. Pulse el botón mostrar. Si desea generar un informe de ventas, pulse el botón Generar informe. Se creará un informe como el de la figura. Nuevo encargo Vaya al modulo Encargos y pulse sobre Nuevo. Se mostrará la siguiente pantalla: Introduzca los datos del encargo. Debe seleccionar un cliente, si el cliente es nuevo, pulse sobre el botón Nuevo cliente e introduzca sus datos y pulse Encargo. Pulse el botón Guardar Borrar encargo Vaya al modulo Encargos y pulse sobre Borrar. Se mostrará la siguiente pantalla: 137

140 Seleccione el cliente que realizó el encargo. Pulse sobre Buscar encargos. Si desea borrar todos los encargos del cliente pulse el botón Borrar todos. Si desea borrar sólo un encargo selecciónelo y pulse el botón Borrar. Si desea borrar dos o más encargos pero no todos, vaya seleccionándolos manteniendo pulsada la tecla Ctrl de su teclado y pulse Borrar. Modificar encargo Vaya al modulo Encargos y pulse sobre Modificar. Se mostrará la siguiente pantalla: 138

141 Seleccione el cliente que realizó el encargo y pulse el botón Buscar encargos. Seleccione el encargo a modificar y pulse Mostrar. Modifique la información que desee, para modificar líneas de encargo mire el apartado Modificar venta del siguiente manual. Pulse el botón Modificar. Consultar encargo Vaya al modulo Encargos y pulse sobre Consultar. Se mostrará una pantalla similar a la anterior. Seleccione el cliente que realizó el encargo y pulse el botón Buscar encargos. Seleccione el encargo a consultar y pulse Mostrar. Generar informe Vaya al modulo Ventas y pulse sobre Generar informe. Se mostrará la siguiente pantalla: Introduzca fecha de inicio y fecha de final si desea. o Si no introduce ninguna fecha se generará un informe de todas las ventas y encargos realizados hasta el día de hoy. o Si introduce sólo la fecha de inicio, se generará un informe de todas las ventas y encargos desde la citada fecha. o Si se introduce sólo la fecha fin, se generará un informe de todas las ventas y encargos hasta la citada fecha. o Si se introducen las dos fechas, se generará un informe de todas las ventas y encargos comprendidos entre las dos fechas. Pulse el botón Generar informe. 139

142 8.1.6 Módulo almacén Nuevo pedido Vaya al modulo Almacén y pulse sobre Nuevo pedido. Se mostrará la siguiente pantalla: Seleccione el proveedor al que se le realiza el pedido. Seleccione el producto, referencia y cantidad y pulse Añadir a pedido. Introduzca los demás datos del pedido. Pulse el botón Guardar. Borrar pedido Vaya al modulo Almacén y pulse sobre Borrar pedido. Se mostrará la siguiente pantalla: 140

143 Seleccione el proveedor al que se le realizó el pedido. Seleccione, si lo desea, una fecha de inicio y una fecha de fin. o Si no introduce ninguna fecha se mostrarán todos los pedidos hasta el día de hoy. o Si introduce sólo la fecha de inicio, se mostrarán los pedidos desde la citada fecha. o Si se introduce sólo la fecha fin, se mostrarán todos los pedidos hasta la citada fecha. o Si se introducen las dos fechas, se mostrarán los pedidos comprendidos entre las dos fechas. Si desea borrar todos los pedidos del proveedor pulse el botón Borrar todos. Si desea borrar sólo un pedido selecciónelo y pulse el botón Borrar. Si desea borrar dos o más pedidos pero no todos, vaya seleccionándolos manteniendo pulsada la tecla Ctrl de su teclado y pulse Borrar. Modificar pedido Vaya al modulo Almacén y pulse sobre Modificar pedido. Se mostrará la siguiente pantalla: 141

144 Seleccione el proveedor al que se le realizó el pedido y la fecha en la que se realizó. Pulse el botón Mostrar y modifique los datos que desee. Si desea modifica líneas de pedido mire el apartado Modificar venta. Pulse el botón Modificar. Consultar pedido Vaya al modulo Almacén y pulse sobre Consultar pedido. Se mostrará la siguiente pantalla: 142

145 Seleccione el proveedor al que se le realizó el pedido y pulse el botón Buscar Seleccione el pedido a consultar y pulse Consultar Módulo clientes Nuevo cliente Vaya al modulo Clientes y pulse sobre Nuevo. Se mostrará la siguiente pantalla: Introduzca los datos del cliente. Pulse el botón Crear. Borrar cliente Vaya al modulo Clientes y pulse sobre Borrar. Se mostrará la siguiente pantalla: Seleccione el cliente que desea borrar y pulse el botón Borrar. 143

146 Modificar cliente Vaya al modulo Clientes y pulse sobre Modificar. Se motrará la siguiente pantalla: Seleccione el cliente que desea modificar. Pulse el botón Mostrar y modifique los datos que desee. Pulse el botón Modificar. Consultar cliente Vaya al modulo Clientes y pulse sobre Consultar. Se mostrará una pantalla similar al apartado anterior. Seleccione el cliente que desea consultar. Pulse el botón Consultar Módulo proveedores Nuevo proveedor Vaya al modulo Proveedores y pulse sobre Nuevo. Se mostrará la siguiente pantalla: 144

147 Introduzca los datos del proveedor. Pulse el botón Guardar. Borrar proveedor Vaya al modulo Proveedores y pulse sobre Borrar. Se mostrará la siguiente pantalla: Seleccione el proveedor que desea borrar y pulse el botón Borrar. Modificar proveedor Vaya al modulo Proveedores y pulse sobre Modificar. Se mostrará la siguiente pantalla: 145