Pajarraco's Pajarería. Portal web de consulta y venta de aves

1 -PAJARRACO'S PAJARERÍAPORTAL WEB DE CONSULTA Y VENTA DE AVES ALUMNOS: CAROLINA ANTÓN CEREZO MARÍA SÁNCHEZ POSTIGO TUTOR: FERNANDO DÍAZ 2 3 Agradecimientos Este proyecto ha supuesto para nosotras un largo camino lleno de alti bajos que hemos ido superando gracias a nuestro esfuerzo, acompañado del apoyo de todos los que nos rodean. Queremos rendir en estas líneas un pequeño homenaje a todas las personas que han contribuido de una u otra forma a que hayamos llegado hasta aquí. A nuestros compañeros de facultad, que no sólo han supuesto una ayuda indispensable para poder superar las diferentes asignaturas de la carrera, sino que a lo largo de los años han dejado de ser compañeros para convertirse en amigos. A los compañeros de piso, en especial a ti Tere por el apoyo, la ayuda, el cariño, las risas y las partidas al scrabble. En especial queremos agradecer la confianza que siempre han depositado en nosotras nuestros padres y hermanos. Siempre nos han demostrado su cariño y confianza inquebrantable y sin ellos no habríamos llegado donde estamos hoy en día. Tampoco queremos olvidarnos de Julio y Pedro, compañeros de vida y fatigas. Siempre dispuestos a echarnos una mano. Puntos fundamentales de ánimo y apoyo que nos han proporcionado el empuje que necesitábamos en todo momento no solo par a finalizar el proyecto sino durante toda la carrera. Por último y no por ello menos importante, queremos agradecer la paciencia y dedicación que nos ha demostrado nuestro tutor Fernando durante el desarrollo de todo el proyecto. Siempre amable y servicial, para nosotras ha sido una fuente de conocimiento fundamental en la que nos hemos apoyado para poder desarrollar todo el proyecto. 4 Índice general de contenidos I. Memoria del proyecto II. Análisis del Sistema de Información III. Diseño del Sistema de Información IV. Construcción del Sistema de Información V. Manual de Usuario 5 Memoria del proyecto 6 Índice de Contenido 1. Introducción ..................................................................................................................................................................... 12 1.1. Identificación del proyecto ............................................................................................................... 12 1.2. Organización de la documentación ................................................................................................. 12 1.3. Estructura del CD ............................................................................................................................... 12 2. Descripción general del proyecto .................................................................................................................................. 14 2.1. Objetivos .............................................................................................................................................. 14 2.2. Cuestiones metodológicas ................................................................................................................. 15 2.3. Tecnologías de desarrollo ................................................................................................................. 15 3.- Descripción general de producto ................................................................................................................................. 17 3.1.- Funcionalidades del producto ........................................................................................................ 18 3.2. Arquitectura del producto ................................................................................................................ 19 3.2.1. Arquitectura general del producto ............................................................................................... 19 3.2.2. Arquitectura interna del producto ................................................................................................ 19 3.2.3. Funcionamiento de la aplicación PAJARRACO'S PAJARERÍA ............................................... 20 3.3. Despliegue del producto ................................................................................................................... 21 4. Planificación y presupuesto ........................................................................................................................................... 23 4.1. Modelo de gestión del proyecto ....................................................................................................... 23 4.1.1. Estimación mediante puntos de función ...................................................................................... 23 4.1.2. Estimación de costes siguiendo el modelo de COCOMO ......................................................... 29 4.2. Planificación ........................................................................................................................................ 32 4.3. Presupuesto ......................................................................................................................................... 35 5. Consideraciones adicionales .......................................................................................................................................... 36 5.1. Cuestiones de análisis y diseño ........................................................................................................ 36 5.2.- Cuestiones de implementación reseñables .................................................................................... 36 5.3. Cuestiones reseñables sobre la base de datos ................................................................................. 37 6. Conclusiones y posibles ampliaciones.......................................................................................................................... 38 6.1. Ampliaciones ...................................................................................................................................... 38 Análisis del Sistema de Información ................................................................................................................................ 43 1. Definición del Sistema .................................................................................................................................................... 43 1.1. Determinación del Alcance del sistema .......................................................................................... 43 1.2. Ámbito de la aplicación y perspectiva del proyecto ..................................................................... 43 1.3. Objetivos del sistema ......................................................................................................................... 43 1.4. Identificación del entorno tecnológico ............................................................................................ 44 1.5. Especificación de estándares y normas ........................................................................................... 44 1.6. Identificación de usuarios participantes y finales.......................................................................... 44 2. Establecimiento de Requisitos ....................................................................................................................................... 46 2.1. Obtención de Requisitos .................................................................................................................... 46 2.1.1 Requisitos No Funcionales .............................................................................................................. 46 2.1.2 Requisitos Funcionales .................................................................................................................... 47 7 2.2. Especificación de Casos de Uso ........................................................................................................ 48 3. Identificación de Subsistemas de Análisis ................................................................................................................... 50 4. Análisis de los Casos de Uso ......................................................................................................................................... 61 4.1. Identificación de Clases Asociadas a un Caso de Uso ................................................................... 61 4.2. Descripción de la Iteración de Objetos ............................................................................................ 61 5. Análisis de Clases ........................................................................................................................................................... 70 5.1. Identificación de Responsabilidades y Atributos ........................................................................... 70 5.2. Identificación de Asociaciones y Agregaciones .............................................................................. 70 5.3. Identificación de Generalizaciones ................................................................................................... 70 6. Definición de las Interfaces de Usuario ....................................................................................................................... 72 6.1. Principios generales............................................................................................................................ 72 6.2. Especificación de formatos Individuales de la Interfaz ................................................................. 72 6.3. Formatos de impresión ...................................................................................................................... 72 7. Especificación del Plan de Pruebas .............................................................................................................................. 73 8. Aprobación del Análisis del sistema de Información ................................................................................................ 74 Diseño del Sistema de Información .................................................................................................................................. 78 1. Antecedentes ................................................................................................................................................................... 78 1.1. Definición del proyecto ...................................................................................................................... 78 1.2. Objetivos del sistema.......................................................................................................................... 78 1.3. Objetivos del proyecto ....................................................................................................................... 79 2. Definición de la Arquitectura del Sistema ................................................................................................................... 80 2.1. Definición de Niveles de Arquitectura ............................................................................................ 80 2.2. Identificación de Requisitos de Diseño y Construcción ................................................................ 82 2.3 Especificación de Excepciones ........................................................................................................... 83 2.3.1 DNS Caído .......................................................................................................................................... 83 2.3.2 Servidor Web Caído ............................................................................................................................ 83 2.3.3 ISP no da servicio ................................................................................................................................ 83 2.2.4 Servidor de Aplicaciones Caído .......................................................................................................... 83 2.2.5 Servidor de Base de datos Caído ......................................................................................................... 83 2.4 Especificación de Estándares y Normas de Diseño y Construcción ............................................. 84 2.5 Identificación de los Subsistemas de Diseño ................................................................................... 85 2.6. Especificación del Entorno Tecnológico .......................................................................................... 86 2.7. Especificación de Requisitos de Operación y Seguridad .............................................................. 91 3. Diseño de la Arquitectura de Soporte .......................................................................................................................... 92 4. Diseño de Casos de Uso Reales ..................................................................................................................................... 93 4.1.- Diagrama casos de uso tienda virtual ............................................................................................ 93 4.2.- Diagrama casos de uso gestión del programa Mendel ................................................................ 98 4.3.- Diagrama casos de uso gestión de usuario .................................................................................. 100 4.4.- Diagrama casos de uso gestión de productos y proveedores ................................................... 103 4.5.- Diagrama casos de uso compra on-line ........................................................................................ 109 8 5. Matriz de Rastreabilidad .............................................................................................................................................. 114 6. Diseño de Clases ............................................................................................................................................................ 119 6.1. Identificación de Clases Adicionales ............................................................................................. 119 6.2. Diagrama de clases........................................................................................................................... 126 7. Diseño de la Arquitectura de Módulos del Sistema ................................................................................................. 144 7.1. Diseño del Modelo Físico de Datos................................................................................................ 144 7.1.1. Diseño Conceptual ........................................................................................................................ 144 7.1.2. Diseño Lógico ................................................................................................................................ 156 7.1.3. Diseño Físico de Base de Datos ................................................................................................... 163 7.2. Optimización del Modelo Físico de Datos (Esquema Normalizado) ........................................ 164 8. Generación de Especificaciones de Construcción ..................................................................................................... 176 8.1. Especificación del Entorno de Construcción ................................................................................ 176 8.1.1 Entorno Tecnológico ...................................................................................................................... 176 8.1.2 Herramientas de construcción ...................................................................................................... 176 8.1.3. Planificación ................................................................................................................................... 176 8.1.4. Requisitos de Operación y seguridad......................................................................................... 176 9. Especificación Técnica del Plan de Pruebas ............................................................................................................... 178 10. Modelo de Comportamiento del Sistema ................................................................................................................ 179 10.1. Diagramas de Secuencia del Sistema ........................................................................................... 179 10.1.1. Diagrama de Secuencia Insertar Entidad ................................................................................. 179 10.1.2. Diagrama de Secuencia Eliminar Entidad ............................................................................... 180 10.1.3. Diagrama de Secuencia Modificar Entidad ............................................................................. 180 10.1.4. Diagrama de Secuencia Buscar Información ........................................................................... 181 10.1.5. Diagrama de Secuencia Comprar Producto ............................................................................ 182 10.1.6. Diagrama de Secuencia Cambiar Credenciales Cliente ......................................................... 184 10.1.7. Diagrama de Secuencia Consultar Información...................................................................... 184 10.1.8. Diagrama de Secuencia Identificarse ........................................................................................ 185 10.2. Diagramas de Actividad del Sistema .......................................................................................... 186 10.2.1. Diagrama de Actividad Insertar Entidad................................................................................. 186 10.2.2. Diagrama de Actividad Eliminar Entidad ............................................................................... 186 10.2.3. Diagrama de Actividad Modificar Entidad ............................................................................. 187 10.2.4. Diagrama de Actividad Buscar Información ........................................................................... 187 10.2.5. Diagrama de Actividad Comprar Producto ............................................................................ 188 10.2.6. Diagrama de Actividad Cambiar Credenciales Cliente ......................................................... 189 10.2.7. Diagrama de Actividad Consultar Información ..................................................................... 190 10.2.8. Diagrama de Actividad Identificarse ....................................................................................... 190 1. Preparación del Entorno de Generación y Construcción ......................................................................................... 194 1.1. Implantación de la Base de Datos Física o de Ficheros ............................................................... 194 2. Ejecución de las pruebas unitarias .............................................................................................................................. 197 2.1. Página principal de usuario ............................................................................................................ 197 9 2.2. Alta y modificación de usuario ....................................................................................................... 197 2.3. Catálogo de productos ..................................................................................................................... 199 2.4. Contacto ............................................................................................................................................. 199 2.5. Pedidos ............................................................................................................................................... 199 2.6. Formulario de pagos ........................................................................................................................ 200 2.7. Programa Mendel ............................................................................................................................. 201 2.8. Gestión de clientes ............................................................................................................................ 205 2.9 Gestión de cliente............................................................................................................................... 206 2.10. Gestión de proveedor ..................................................................................................................... 206 2.11. Alta y modificación de proveedor ................................................................................................ 207 2.12. Gestión de productos ..................................................................................................................... 207 2.13. Modificación de productos ............................................................................................................ 208 2.14. Pedidos ............................................................................................................................................. 209 2.15. Gestión de pedido .......................................................................................................................... 209 2.16. Gestión de pedidos a clientes ........................................................................................................ 209 2.17. Gestión de pedidos a proveedores ............................................................................................... 210 2.18. Gestión de centros .......................................................................................................................... 211 2.19. Alta y modificación de centros ..................................................................................................... 212 2.20. Consulta de stock ............................................................................................................................ 213 2.21. Nueva oferta .................................................................................................................................... 213 2.22. Modificación oferta......................................................................................................................... 214 2.23. Visualización de gráficos ............................................................................................................... 214 3. Ejecución de las pruebas de integración .................................................................................................................... 216 3.1 Diseño pruebas de integración ........................................................................................................ 217 3.2. Definición de las pruebas ................................................................................................................ 217 3.2.1. Alta usuario .................................................................................................................................... 217 3.2.2. Modificación datos usuario .......................................................................................................... 218 3.2.3. Programa Mendel .......................................................................................................................... 218 3.2.4. Gestión de proveedores ................................................................................................................ 223 3.2.5. Gestión de centros ......................................................................................................................... 225 3.2.6. Gestión de productos .................................................................................................................... 225 3.2.7. Pedidos a proveedores .................................................................................................................. 226 3.2.8. Pedidos de clientes ........................................................................................................................ 226 3.2.9. Consulta de stock ........................................................................................................................... 227 3.2.10. Generar catálogo .......................................................................................................................... 227 3.2.11. Gestión clientes ............................................................................................................................ 228 3.2.12. Visualización de gráficos ............................................................................................................ 228 1. Introducción .................................................................................................................................................................. 230 2. Requisitos mínimos ...................................................................................................................................................... 231 2.1. Requisitos hardware......................................................................................................................... 231 16  MySql de Oracle: es un sistema de gestión de bases de datos relacionales. MySql es una base de datos muy rápida en cuanto a lectura de información y muy adecuada en aplicaciones web (como es nuestro caso), ya que, hay muy baja concurrencia en la modificación de datos y sin embargo hay gran cantidad de trabajo de lectura de datos.  IBM Webshpere Studio de IBM: es el entorno de desarrollo que hemos escogido para la implementación de la lógica o código de la aplicación. Está diseñado con tecnologías abiertas y basado en Eclipse. Es compatible con múltiples lenguajes, plataformas y dispositivos. Está diseñado para cumplir los requisitos de programación específicos de empresas, desde interfaces web hasta aplicaciones de servidor, desde programación individual hasta entornos avanzados para equipos, desde programación en java hasta integración de aplicaciones.  Pacestar UML Diagrammer v.6.20.2040: es la herramienta que hemos utilizado para el modelado de los diagramas expuestos en la documentación técnica del proyecto, como son los diagramas de casos de uso, de actividad, de secuencia, de clases de estados, de paquetes… Este programa requiere de licencia comercial para el sistema operativo Windows, pero se ofrece una descarga gratuita de prueba.  Microsoft Office 2010: el paquete de Microsoft Office 2010 ofrece un conjunto de programas de entre los cuales hemos utilizado el Microsoft Office Excel (para el diseño de tablas) y Microsoft Office Word para el desarrollo de toda la documentación del proyecto. El lenguaje de programación que hemos decidido utilizar para la implementación ha sido Java. Los motivos de la elección son principalmente los siguientes: - Es un lenguaje que no depende del tipo de plataforma que emplea, lo cual nos permite que sea portable a otros sistemas operativos. - Java es un leguaje orientado a objetos lo cual supone una gran ventaja, ya que permite al código emular con mayor exactitud los problemas del mundo real que se desean resolver. Además es un lenguaje dinámico, en el que los pequeños fragmentos de código Java se ensamblan en tiempo de ejecución en el programa y no en el momento en el que se escribe el código. - Además Java dispone de una serie de funcionalidades ya implementadas y recogidas en un conjunto de paquetes que facilitan el desarrollo de las aplicaciones y que pueden ser utilizadas por cualquier desarrollador. - Este lenguaje puede ser desarrollado en plataformas OpenSource que es el requisito primordial que buscábamos. Por último Java tiene la característica de que libera la memoria automáticamente, por lo cual los desarrolladores no se tienen que centrar en la liberación de memoria y como consecuencia mejora notablemente el rendimiento de las aplicaciones. Cabe destacar que, a pesar de que a pesar de que el código de la aplicación está desarrollado en java, el mapa que se visualiza en cuando accedemos a la opción de contacto del menú de usuario está desarrollado en flash. 17 3.- Descripción general de producto La aplicación web PAJARRACO’S PAJARERÍA, como ya hemos dicho anteriormente, es una aplicación dirigida a varios públicos algunos de los cuales no tienen porque tener ningún conocimiento informático, ni experiencia con la utilización de aplicaciones web. La interfaz gráfica es el elemento que permite al usuario interactuar con los contenidos, y no sólo se precisa una interfaz atractiva, sino además debe ser funcional. Con la idea de simplificar el uso de la aplicación para los usuarios, hemos prestado especial atención al desarrollo de la interfaz gráfica para que el usuario establezca un contacto más fácil e intuitivo con la web. Hemos tratado de hacer la aplicación lo más atractiva, sencilla y amigable posible. Uno de los objetivos que hemos perseguido, es que el usuario sea capaz de saber en qué punto del proceso que esté realizando se encuentra en todo momento. La elaboración de una interfaz gráfica clara es fundamental principalmente para hacer que el proceso de compra sea sencillo y con ello que el porcentaje de ventas aumente y no haya dificultades ni dudas por parte del cliente durante dicho proceso. En el diseño de las páginas de la web PAJARRACO’S PAJARERÍA podemos diferenciar tres partes:  En función del rol de usuario, se mostrará un menú diferente en la parte izquierda de la pantalla en la que se muestran las opciones a las que tiene acceso.  En la parte superior de cualquier pantalla se muestra el logo de la empresa y los campos para registrarse en caso de no estar logado o el nombre del usuario en caso de estarlo y el enlace para cerrar la sesión.  En la parte central de la pantalla se mostrarán los formularios correspondientes a la opción que haya escogido el usuario. Nuestra interfaz gráfica cumple varias características entre las que destacamos las siguientes: - Es de fácil comprensión y utilización. - La tipología de color y letra es uniforme en todas las pantallas, cuidando el diseño de las formas y la coherencia entre todos los elementos visuales. - Tiene un diseño claro y eficiente mediante el establecimiento de menús, submenús, enlaces, botones e iconos que facilitan la navegación. - La acción que se está realizando es identificada claramente en todo momento. - Las operaciones son rápidas y reversibles en todo momento pudiéndose regresar a la pantalla previa. - También se ha prestado cuidado con la presentación de mensajes de error de manera que sean comprensibles por el usuario. Además del cuidado del diseño de las páginas de la web, nuestro desarrollo se ha realizado pensando en cubrir los siguientes objetivos:  Accesibilidad: desde diferentes navegadores.  Escalabilidad: la aplicación debe poder adaptarse a un incremento de usuarios, del tamaño de los datos que maneja y debe ser mantenible.  Reutilización de recursos: se debe programar el código de la aplicación de tal manera que se puedan reutilizar módulos para diferentes partes de la aplicación.  Portable a otros sistemas operativos: como ya hemos comentado anteriormente la aplicación ha sido desarrollada en una plataforma de desarrollo que no depende del sistema operativo. Por último, como tareas para abordar en una segunda fase quedarán pendientes varias relacionadas con la mejora de nuestra interfaz gráfica, funcionalidad y manejo de la web. Algunas que se nos ocurren pueden ser la creación de una herramienta de ayuda y soporte poder resolver cualquier pregunta que pueda surgir acerca del manejo de la web, o la elaboración de una sección de FAQs en las que se muestren las preguntas más realizadas por los usuarios. También se debería de mejorar el tratamiento de los errores, intentando especificar al máximo posible el motivo por el cual no se ha podido completar una acción solicitada de manera que sea lo más claro posible para el usuario. Por último se nos ocurre que una buena manera de renovar rápidamente la imagen de la empresa y la web es mediante la actualización de los temas y colores utilizados en las diferentes pantallas de la aplicación. 18 3.1.- Funcionalidades del producto A continuación vamos a enumerar las funcionalidades que podemos encontrar en los distintos menús de la web, agrupadas por módulos de gestión: Gestión de productos: Buscar productos. Añadir productos. Eliminar productos. Modificar productos. Listar catálogo de productos. Consultar el stock de un producto. Consultar descendencia Diamantes de Gould. Añadir oferta al catálogo de productos. Eliminar oferta del catálogo de productos. Modificar el precio de una oferta. Gestión de clientes: Alta de usuario. Baja de usuario. Buscar clientes. Modificación de datos de usuario. Listar clientes. Gestión de proveedores: Alta de proveedor y de su catálogo de productos. Baja de proveedor y de su catálogo de productos. Modificación del catálogo de productos de un proveedor. Buscar proveedor. Listar proveedores. Modificar catálogo de proveedor (alta/baja producto). Gestión del foro: Contestar o dar de alta un mensaje. Eliminar un mensaje o un hilo de conversación. Añadir un nuevo tema. Gestión de contacto con la empresa: Consulta centros. Añadir centro. Eliminar centro. Buscar centro. Listar centros. Modificación de centro. Envío de email. Gestión de pedidos: Realización de pedidos por parte de clientes. Realización de pedidos a proveedores. Modificación estado pedidos de clientes. Buscar pedidos de clientes. Buscar pedidos hechos a proveedores. Listar pedidos de clientes. Listar pedidos a proveedores. Visualizar listado productos en pedido. Gráfico de ventas (por centro/producto/fecha/familia). 19 3.2. Arquitectura del producto En este apartado se pretende dar una visión general de la arquitectura que hemos seguido para la implementación de nuestro proyecto. En primer lugar haremos una descripción a más alto nivel para posteriormente profundizar más en detalle cada componente de dicha arquitectura. 3.2.1. Arquitectura general del producto La web de PAJARRACO’S PAJARERÍA utiliza varias tecnologías en las cuales nos hemos basado para poder desarrollar la lógica de nuestra aplicación y para poder almacenar, tratar y leer los datos que se manejan en los formularios de ésta. El desarrollo de la lógica de la aplicación está íntegramente desarrollado en Java, por lo que la plataforma de ejecución Java es la base para el desarrollo de la aplicación web. En cuanto a la parte visual de la aplicación, los formularios, son JSP (Java Server Pages) que son básicamente una tecnología Java que permite la generación de contenido dinámico web en forma de páginas estáticas HTML que no pueden proporcionar por sí solas esta potencia. Nuestro modelo de datos o base de datos, será accedido mediante un API que nos proporciona Java llamada JDBC, que permite la ejecución de operaciones sobre la base de datos desde nuestro código java (lógica de nuestra aplicación). Esta comunicación se establecerá con independencia del sistema operativo sobre el que estemos trabajando pero siempre utilizando la sintaxis de SQL. Además esta interfaz Java se encargará de controlar y manejar todas las conexiones que se realicen hacia la base de datos. Figura 2. Estructura general y tecnologías utilizadas por nuestra aplicación 3.2.2. Arquitectura interna del producto En este apartado vamos a centrarnos en describir cómo hemos desarrollado la parte lógica y visual de nuestra aplicación. A la hora de implementar el core de negocio de nuestra aplicación nos hemos decantado por un patrón de diseño, que podría asemejarse al patrón modelo-vista-controlador con algunas diferencias y que pasamos a detallar a continuación:  Modelo-controlador: en nuestro caso hemos decidido juntar ambas partes ya que no existen servlets como tal pero si contamos con el uso de struts, que será un poco quien se encargue del control de la acción que esté solicitando un usuario (su función será un poco la de intermediario entre las jsp y la parte de las clases java que contienen la lógica). En esta parte se engloba toda la funcionalidad de la aplicación. Estará compuesta por una serie de clases java gestionadas por struts. Struts es un framework que implementa el patrón modelo-vistacontrolador en java y que se emplea fundamentalmente como soporte en el desarrollo de aplicaciones web.  Vista: proporcionará una serie de páginas web dinámicamente al cliente, siendo para él simples páginas HTML. Nuestras páginas web serán jsp (java script page), las cuales mediante una serie de tags XML ofrecen un interfaz a 20 las clases y objetos Java proporcionados por nuestro servidor de aplicaciones. En estas páginas también hemos utilizado un lenguaje de programación llamado js (javascript), el cual se utiliza principalmente para la creación de web’s dinámicas. Gracias a él podremos incorporar efectos, animaciones, acciones que se activan al pulsar botones y ventanas con mensajes de aviso al usuario. Nuestros archivos js contendrán fundamentalmente las validaciones de los formularios de entrada de datos por parte del usuario, lo cual impedirá que llegue información mal formada a la parte de la lógica de negocio. Además cabe destacar que nuestras jsp utilizan hojas de estilo o css desarrolladas específicamente para dar un aspecto uniforme y atractivo a todos los formularios de la aplicación. La utilización de ficheros .js y .ccs nos proporcionará una serie de ventajas ya que además de reutilizar código (lo cual proporcionará un mantenimiento rápido y sencillo), liberará de carga a nuestro servidor lo cual repercutirá en el rendimiento de nuestra aplicación. Figura 3. Modelo de arquitectura interna seguida en el desarrollo de la aplicación 3.2.3. Funcionamiento de la aplicación PAJARRACO'S PAJARERÍA Este apartado tiene como finalidad dar una visión general del funcionamiento de la web desde que el usuario hace una petición hasta que finalmente llega a la base de datos o para leer información o para escribir. Figura 4. Entorno de ejecución de la aplicación Un elemento que juega un papel fundamental en el funcionamiento de cualquier web es el servidor de aplicaciones. La arquitectura de un servidor de aplicaciones incluye una serie de subsistemas que pasamos a describir a continuación:  Servidor HTTP: es el encargado de servir las páginas web a los usuarios que hacen una petición http a través de su navegador web.  Contenedor de aplicaciones: contiene los servlet y JSP que componen la aplicación.  Contenedor Java: contiene el código java de la aplicación. El funcionamiento simplificado de cualquier web es el que se muestra en la siguiente figura: 21 Figura 5. Esquema general de la generación dinámica de contenido El usuario abre un navegador web y escribe en la barra de ese navegador la URL de la web a la que quiere acceder. La petición llega al servidor de aplicaciones web gracias a la conexión que se establece en base al protocolo de comunicación web HTTP. Es un protocolo de comunicación implementado sobre TCP/IP y que se basa en enviar las solicitudes que recibe de los usuarios hacia el servidor web y de responder a cada una de ellas. Por defecto este protocolo establece la comunicación con el servidor a través de un puerto por defecto 8080 (definido por servidores Tomcat). Cuando el servidor web recibe una petición debe recuperar el recurso solicitado del contenedor web, el cual gestionará su localización y ejecución. La JVM (maquina virtual de java) del contenedor web invocará al objeto solicitado JSP servlet. El servidor no creará una instancia por cada solicitud del mismo recurso sino que da servicio a múltiples solicitudes, las cuales generarán cada una un hilo de ejecución en el servidor, que a su vez se encargara de la gestión de todos los hilos. Figura 6. Esquema específico de la generación dinámica de contenido con tecnología JSP 3.3. Despliegue del producto Las aplicaciones web están formadas por un conjunto de servlets, páginas jsp, ficheros html y clases Java de apoyo empaquetadas o no en ficheros jar, war o ear. 22 Figura 7. Estructura de directorios y archivos típicos de una aplicación JSP Durante la etapa de desarrollo estableceremos una determinada estructura de carpetas que definirá la estructura de la aplicación. Posteriormente la aplicación se compilará, utilizando una serie de ficheros de configuración, formando un paquete .war (web application resource) que engloba todo su contenido jsp y clases java. Este paquete contendrá la misma estructura de paquetes que hemos definido durante la etapa de desarrollo. La finalidad es que dicho paquete pueda ser desplegado en diferentes servidores web manteniendo su funcionalidad y sin necesidad de realizar ninguna modificación de código. El paquete compilado se colocará en una ubicación específica definida en función del servidor web que se esté utilizando. Posteriormente se arrancará el servidor web para poder comenzar a utilizar la aplicación web. 23 4. Planificación y presupuesto En este capítulo se mostrarán los datos obtenidos para la planificación y presupuesto del proyecto PAJARRACO’S PAJARERÍA. 4.1. Modelo de gestión del proyecto El ciclo de vida ha marcado la metodología de trabajo, de principio a fin, del proyecto y la planificación del mismo. El ciclo de vida del desarrollo software nos proporciona la orientación que debe seguirse para obtener, a partir de los requisitos de los que partimos a la hora de elaborar una aplicación, sistemas que puedan ser utilizados por los usuarios a los que va dirigido. Todo este proceso comprende un conjunto de fases, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener un producto software. El ciclo de vida que se decida utilizar para el desarrollo de un producto software define el orden de las tareas o actividades involucradas, además de la coordinación entre ellas, enlace y realimentación entre las etapas. Como punto de partida en la planificación de nuestro sistema, se deberá tener en cuenta el tamaño que tendrá. Para ello nos hemos decantado por una planificación en puntos de función que detallaremos a continuación. 4.1.1. Estimación mediante puntos de función La estimación mediante puntos de función es un tipo de métrica utilizada para medir el tamaño de un producto software independientemente de la tecnología empleada para su desarrollo o explotación. Posteriormente se utilizara para evaluar el coste y el esfuerzo que supone el desarrollar el proyecto. Esta métrica consiste en asignar una serie de puntos a una aplicación informática en función de los datos que maneja y de los procesos o funciones que realiza sobre ellos desde el punto de vista del usuario. Los puntos de función que obtienen utilizando una función empírica basando en medidas cuantitativas del dominio de información del software y valoraciones subjetivos de la complejidad del software. 4.1.1.1. Explicación del proceso Vamos a explicar brevemente en qué consiste este tipo de métrica. En primer lugar habrá que identificar los componentes que intervienen en este tipo de métrica son:  Número de entradas externas en el sistema (EI, External inputs): Procesos en los que se introducen datos y que suponen la actualización de cualquier archivo interno, es decir por ejemplo la información que introducen los usuarios en el sistema a través de los formularios de la aplicación o selección de opciones de menú etc.  Número de salidas del sistema (EO, External outputs): Procesos en los que se envía datos al exterior de la aplicación, es decir es la información que el sistema aporta a los usuarios que la utilizan.  Número de archivos lógicos internos (ILF, Internal logical files): datos, ficheros y bases de datos de uso exclusivo por parte de la aplicación que residen dentro de los límites del sistema y se mantienen a través de entradas externas.  Número de archivos externos (EIF, External interface files): datos, ficheros y bases de datos que pueden ser utilizados por nuestra aplicación y por otros sistemas. Residen fuera de los límites del sistema y se mantienen por las entradas externas de otras aplicaciones.  Número de consultas externas (EQ, External queries): entradas al sistema que requieren una respuesta por parte de este. Los datos de entrada no actualizan ni mantienen ningún archivo y los datos de salida no contienen datos derivados como por ejemplo las búsquedas que se realizan dentro de un sistema. A continuación vamos a describir brevemente los pasos a seguir para realizar este tipo de estimación: - Para el cálculo de los puntos de función, en primer lugar hay que identificar y contar los números de elementos de cada clase. 24 - Cada uno de estos elementos se clasificará según su grado de complejidad (alta, media o baja). No obstante la determinación de la complejidad es algo subjetivo. - Por último se obtienen los PFNA (Puntos de Función No Ajustados) mediante una suma ponderada de esas cantidades con los pesos que aparecen a continuación: Figura 8. Pesos puntos de función no ajustados A continuación presentamos una tabla donde se pueden ver los criterios que se seguirán para determinar la complejidad de los elementos: Figura 9. Cálculo de la complejidad de los elementos Para el cálculo de los PFNA (puntos de función no ajustados), realizaremos la suma de todos los parámetros que hemos calculado previamente: PFNA = (Nº Entradas × multiplicador (complejidad)) + (Nº Salidas × multiplicador (complejidad) +(Nº Fichero internos × multiplicador (complejidad)) + (Nº Ficheros externos multiplicador (complejidad)) + (Nº Consultas externas × multiplicador (complejidad)). Una vez obtenido el resultado deberemos realizar un ajuste mediante un factor de ajuste (FA). Para obtener el valor del factor de ajuste deberemos sumar 14 factores de complejidad siguiendo la siguiente fórmula: FA= (0.01 × SUM (FC)) + 0.65 Una vez obtenido el factor de ajuste podemos realizar el cálculo definitivo de los puntos de función: PF = PFNA ×FA A continuación vamos a detallar cada uno de los factores de complejidad: 1.- Comunicación de datos: los datos o información de control que la aplicación utiliza se envía o recibe a través de las facilidades de comunicación. 25 0 Aplicación es batch exclusivamente. 1-2 Impresión o entrada de datos remota. 3-5 Teleproceso (TP) interactivo. 3 TP interface a un proceso batch. 5 La aplicación es interactiva predominantemente. 2.- Datos de procesamiento distribuidos: "Distribuida" significa que los datos de la aplicación están distribuidos en dos o más procesadores diferentes (esto también implica un incremento del factor de comunicación de datos). 0 La aplicación no ayuda a la trasferencia de datos o procesamiento entre los componentes de nuestro sistema. 1 La aplicación prepara datos para el usuario final de otro procesador. 2-4 Los datos se preparan para trasferencia, se trasfieren y se procesan en otro componente del sistema. 5 Las funciones de procesamiento se realizan dinámicamente en el componente más apropiado del sistema. 3. Objetivos de rendimiento: para el correcto funcionamiento de cualquier sistema es muy importante la respuesta dentro del sistema. 0-3 Análisis y diseño de las consideraciones del rendimiento son estándar. No se precisan requerimientos especiales por parte del usuario. 4 En la fase de diseño se incluyen tareas del análisis del rendimiento para cumplir los requerimientos del usuario. 5 Además se utilizan herramientas de análisis del rendimiento en el diseño, desarrollo e instalación. 4. Configuración utilizada masivamente: referente a la importancia del entorno. Esto es, si hay restricciones de memoria o del hardware. 0-3 La aplicación corre en una máquina estándar sin restricciones de operación. 4 Restricciones de operación requieren características específicas de la aplicación en el procesador central. 5 Además hay restricciones específicas a la aplicación en los componentes distribuidos del sistema. 5. Tasa de transacción: cuando un sistema recibe un elevado número de transiciones pueden darse problemas en el sistema (como por ejemplo problemas de rendimiento y lentitud). 0-3 Las tasas son tales que las consideraciones de análisis de rendimiento son estándares. 4 En la fase de diseño se incluyen tareas de análisis de rendimiento para verificar las altas tasas de transacciones. 5 Además se utilizan herramientas de análisis del rendimiento. 6. Entrada de datos on-line: 0-2 Hasta el 15% de las transacciones tienen entrada interactiva. 3-4 15% al 30% tienen entrada interactiva. 5 30% al 50% tienen entrada interactiva. 7. Eficiencia para el usuario: 0-3 No se especifican requerimientos especiales. 4 Se incluyen tareas de diseño para la consideración de factores humanos. 5 Además se utilizan herramientas especiales o de prototipado para promover la eficiencia. 8. Actualización on-line: 0 Nada. 1-2 Actualización on line de los ficheros de control. El volumen de actualización es bajo y la recuperación fácil. 3 Actualización on line de la mayoría de los ficheros internos lógicos. 4 Además es esencial la protección contra la pérdida de datos. 5 Además se considera el coste de recuperación de volúmenes elevados. 32 Tiempo estimado de desarrollo = Por último, una vez que tenemos los cálculos del tiempo de desarrollo de la aplicación y las personas que serán necesarias por mes, podemos calcular las personas que se necesitarían para poder implementar la aplicación por mes. Entonces obtendríamos: Nº personas por mes = 15,85 (personas *mes) / 7,144 (meses) = 2,18 3 personas Hemos deducido que para completar el desarrollo en el tiempo calculado serían necesarias tres personas trabajando en la aplicación cada mes. Teniendo en cuenta que este proyecto ha sido desarrollado por dos personas el tiempo será ligeramente superior al obtenido. 4.2. Planificación El proceso de gestión de un proyecto de software comienza con un conjunto de actividades que globalmente se denominan planificación del proyecto. La fase de planificación aporta una aproximación lo más real posible del orden en el que se van a desarrollar las distintas fases del proyecto y el tiempo que abarcará cada una de ellas. El objetivo que se persigue cuando se realiza una planificación de un proyecto es el proporcionar un marco de trabajo que permita, al gestor del proyecto, hacer estimaciones razonables de recursos, coste y planificación temporal. Las estimaciones se hacen dentro de un tiempo limitado al comienzo de un proyecto software, y se deben ir actualizando conforme se van avanzando por las distintas fases, ya que es bastante frecuente que se tengan que ir realizando ajustes. Dicha planificación nos ayudará a realizar un seguimiento del desarrollo de todo el proyecto. Esto nos permitirá que en el caso de que una tarea no se cumpla en los plazos determinados, puedan realizarse ajustes en las tareas posteriores. Vamos a describir cada una de las fases identificadas en la planificación de nuestro proyecto PAJARRACO’S PAJARERÍA. 1.- Definición. 2.- Planificación. 3.- Iniciación. 4.- Control. 5.- Finalización o Cierre. 1.- Definición y estudio de la viabilidad: El objetivo de esta fase consiste en especificar, con claridad, aquello qué se espera conseguir con el proyecto. Toda definición de un proyecto debe identificar los propósitos y los objetivos del trabajo. En definitiva, el estudio del problema que queremos abordar y las herramientas que se usarán para poder llevarlo a cabo. Las tareas que realizaremos durante esta etapa son:  Escribir una descripción de los requisitos a alto nivel, que tendrán nuestro sistema en función de los objetivos que se pretenden alcanzar con el desarrollo. Ello significa comprender el problema o propósito que se persigue. Tiempo estimado: 15 días.  Estimar el tamaño del sistema, la planificación y los costos que conllevan el desarrollo de la aplicación. Tiempo estimado: 5 días. En nuestro caso esta fase ha sido la más breve. Se definió brevemente los objetivos que queríamos perseguir con este proyecto y la plataforma de desarrollo que queríamos emplear para llevarlo a cabo. Nuestra aplicación será una primera versión de una web de una pequeña empresa con lo que inicialmente no requerirá de grandes infraestructuras ni un gran desarrollo. El objetivo que hemos buscado con este proyecto es realizar una versión inicial de la web de una empresa que comienza a darse a conocer a través de la web. Como ya hemos comentado anteriormente, para este proyecto decidimos desarrollar nuestra aplicación con un lenguaje java por varios motivos. Se puede utilizar una plataforma de desarrollo gratuita y además este lenguaje de programación dispone de una amplia API que nos facilitará en gran medida el desarrollo de aplicaciones web y la gestión con nuestro sistema de 33 persistencia de datos. En esta primera fase emplearemos un total de 20 días para realizar el estudio. 2.- Análisis: Esta fase tiene lugar una vez que el estudio de viabilidad de un proyecto ha sido favorable, y se ha decidido llevar a cabo el proyecto. En esta etapa de la planificación hemos incluido las siguientes tareas:  Realizaremos de una estimación más detallada y revisada de costes, planificación, recursos necesarios, etc. Es en este punto en el que en función de los resultados obtenidos en esta etapa se deberá tomar la decisión de continuar o no con el proyecto. Tiempo estimado: 5 días.  En esta fase además se revisarán los requisitos para ofrecer un mayor detalle de cada uno de ellos de cara a la elaboración del funcional. 15 días.  A continuación elaboraremos el documento de análisis funcional. Este documento es una transformación de los requerimientos del usuario de la fase anterior en unas especificaciones funcionales. Definiremos los usuarios, dimensiones y restricciones que tendrá nuestro sistema. Incluirá además un análisis del modelo de datos que se quiere utilizar como método de persistencia de la información que se maneje en la web. Tiempo estimado:15 días. En nuestro caso el tiempo total empleado en realizar todas estas tareas será de 35 días. 3.- Diseño: Esta etapa dentro de la planificación de un proyecto en la que los requisitos empiezan a tomar forma. Las tareas que hemos realizado en esta etapa de la planificación del proyecto son:  Evaluaremos diferentes posibilidades de diseño para escoger la que mejor se adapta a nuestro proyecto. Tiempo estimado:5 días.  Desarrollo de un diseño detallado del sistema (interfaz del sistema) y de la base de datos. Tiempo estimado:10 días.  Posterior elaboración del documento de diseño definitivo del sistema. Tiempo estimado:12 días.  Identificación de las necesidades de conocimiento y documentación de los usuarios que van a utilizar la herramienta; definición de las guías finales. Tiempo estimado:3 días. El tiempo total que hemos empleado en esta fase ha sido de 30 días. 4.- Codificación: Esta etapa es la más larga de todo el proceso de planificación. En ella se desarrollará todo lo que se ha ido definiendo y tratando en las anteriores etapas de análisis. Una vez que se llega a esta fase no debe quedar ninguna duda en la definición de ninguna funcionalidad. Implementación tanto del código de la aplicación web como de la base de datos donde se almacenará la información. Tiempo estimado: 120 días. 5.- Pruebas: Esta etapa se encamina a probar la consistencia, fiabilidad y robustez del producto que se ha desarrollado. Los hitos que hemos realizado en esta etapa son: Realización del test del sistema. Normalmente las pruebas se dividen en pruebas unitarias, integradas y de usuario. Como en este caso tanto los desarrolladores como los usuarios finales de la aplicación son los mismos todas las pruebas se realizarán como un solo plan de pruebas. Este test incluirá la elaboración de una amplia batería de pruebas tanto de las funcionalidades de la aplicación como del rendimiento y capacidad del mismo. Tiempo estimado:21 días. 34 Finalización del sistema completamente probado. Modificación de mensajes a usuario y retoques de interfaz. Tiempo estimado:7 días. En total en esta fase hemos empleado un total de 28 días. 6.- Integración del sistema en producción: Una vez pasadas todas las pruebas del sistema, el siguiente paso es su explotación en un entorno de producción. Este es el objetivo que se pretende en esta etapa: Instalación del hardware y software para el entorno de explotación. En nuestro caso, en principio, necesitaremos un servidor de aplicaciones que soporte todo el despliegue del código de la aplicación y una base de datos que sea capaz de hacer persistir el contenido de la aplicación web. Llevar a cabo la configuración de los servidores (servidor de la aplicación y de la base de datos), el despliegue del código en el servidor de aplicación y la creación de la base de datos con todos los datos que inicialmente se necesiten para el correcto funcionamiento de la aplicación, como puede ser el catálogo de productos o la creación de usuarios con perfiles de administración del sistema Estabilización de la plataforma en el entorno de producción. Con esto se persigue el mantener la cuarentena del desarrollo para poder reaccionar de manera rápida y eficaz ante posibles incidencias que pudieran detectarse en dicho entorno. Esta etapa no la hemos contemplado ya que este proyecto no se desplegará en ningún entorno de producción. 7.- Mantenimiento: Al igual que la etapa anterior, esta fase la hemos incluido a título informativo como una fase más dentro de la planificación de un proyecto. El objetivo que se persigue en esta fase es ir adaptando la aplicación a las distintas necesidades que puedan surgir, tanto a nivel de funcionalidad, como a nivel de aumentar el rendimiento de la plataforma de explotación mediante la inclusión de nuevos servidores. Algunas de las tareas que podemos incluir en esta etapa pueden ser: Implementar los cambios y evoluciones funcionales que vaya requiriendo el sistema. Asegurarse de que el sistema soporta adecuadamente el tráfico que recibe la aplicación. Figura 12. Diagrama de Gantt 35 4.3. Presupuesto Para calcular el presupuesto de un proyecto hay que tener en cuenta tanto los recursos humanos como los materiales que han sido necesarios para el desarrollo del mismo. En cuanto a los recursos humanos empleados para la elaboración de la web PAJARRACO’S PAJARERÍA hemos dividido el trabajo por perfiles. Cada uno de estos perfiles se encargaran de la elaboración de diferentes etapas dentro de la planificación del proyecto. Suponemos que cada día empleado supone 8 horas de trabajo. Por un lado será necesario un perfil de analista y otro de programador. A continuación mostramos el desglose de las tareas y el coste humano total que supondrá el desarrollo de todas. Tarea Perfil Coste perfil(Eur/h) Horas tarea(h) Coste Tarea(Eur) Definición y estudio de la viabilidad Analista 10 Eur/h 20 días X 8= 160h 160 X 10 = 1600 Eur Análisis Analista 10Eur/h 20 días X 8 =160h 160 X 10= 1600 Eur Diseño Analista 10Eur/h 30 días X 8 = 240h 240 X 10 = 2400Eur Codificación Programador 5Eur/h 120 días X 8 =960h 960 X 5 = 4800 Eur Pruebas Programador 5Eur/h 28 días X 8 = 224h 224 X 5 = 1120 Eur TOTAL 11520Eur Figura 13. Coste recursos humanos En cuanto al presupuesto en recursos materiales, hardware y software lo hemos desglosado en la siguiente tabla: Figura 14. Coste recursos materiales Por tanto el coste total del desarrollo de la aplicación web es aproximadamente 11520 + 850 = 12370 Eur. Recurso Uso (%) Coste total(Eur) Coste para el proyecto(Eur) Ordenador Personal 25 800 Eur 200 X 2(unidades) = 400 Eur Impresora 10 80 Eur 8 Eur Internet ADSL 12 meses. 25 240 Eur 60 X 2(conexiones) = 120 Eur Microsoft Windows Vista (incluido en coste del ordenador personal y servidor). 100 0 (incluido en el PC) Eur 0 Eur Maquina virtual Java 100 0 Eur 0 Eur IBM Webshpere Studio con servidor de aplicaciones integrado 100 0 Eur 0 Eur Microsoft Office 2010 20 700 Eur 140 X 2 (unidades) = 280 Eur StarUML 5.0 100 0 Eur 0 Eur MySql 100 0 Eur 0 Eur Adobe Reader 100 0 Eur 0 Eur Material de oficina 100 50 Eur 50 Eur TOTAL 850 Eur 36 5. Consideraciones adicionales En este apartado vamos a exponer cuestiones reseñables que hemos tenido en cuenta a la hora del desarrollo de nuestra aplicación y que merece la pena mencionar. 5.1. Cuestiones de análisis y diseño Jerarquía de usuarios: nosotras hemos enfocado el diseño de la web en base a cubrir las necesidades de cualquier usuario que acceda a la web. Lógicamente no todos los usuarios que navegan por la web realizan un pedido, a pesar de ser ese el principal objetivo. Es por ello por lo que nos surgió la necesidad de establecer un modelo de jerarquía de usuarios, que nos permitiera obtener diferentes niveles de seguridad requeridos para cada funcionalidad. Por tanto decidimos crear tres roles o perfiles de usuario que son: usuario, cliente y administrador. Pago del pedido realizado: la implementación de un proceso real de pago complicaba en gran medida el desarrollo de la aplicación ya que habría que establecer una comunicación entre nuestra aplicación y una pasarela de pagos a través de la cual poder realizar los pagos de los pedidos. El objetivo del proyecto es la realización de una primera versión de la web de una pajarería con las funcionalidades más básicas. Es por ello por lo que hemos descartado la implementación de la pasarela. En versiones posteriores se tendrían que ir realizando ajustes y modificaciones para ir perfeccionando la web. Modelo de datos: nuestro modelo de datos utiliza bastantes relaciones entre las diferentes entidades. Esto es debido a que la mayoría están directamente relacionadas y la eliminación de algún registro de una de ella hace que sea lógica la eliminación del registro relacionado de otra, ya que dejaría de tener sentido por sí solo. Diseño de la interfaz: hemos tenido especial cuidado en el desarrollo de la interfaz web. Para el éxito de cualquier página web es fundamental que la interfaz de la misma sea atractiva e intuitiva para el usuario. En nuestro caso hemos optamos por la modularidad de las funcionalidades y los recursos gráficos para hacer la interfaz más amigable. Además se diseñó un controlador de dialogo que atiende a las peticiones para cambiar de interfaz y, opcionalmente, admite guardar un histórico de las interfaces de las que se procede, permitiendo regresar a ellas en cualquier momento, mediante los botones de navegación oportunos. Patrón o modelo de nuestro sistema: para la implementación de nuestro modelo hemos utilizado el patrón de diseño MVC(modelo-vista-controlador). Nos hemos decantado por este modelo debido a una serie de razones entre las que destacamos:  El mantenimiento de las aplicaciones que siguen este patrón es mucho más sencillo.  Se separa la parte de la lógica de negocio y la presentación de datos.  Se pueden reutilizar componentes. Se basa principalmente en la descomposición de la lógica de negocio (que es lo que llamamos modelo) y la presentación de la información (la vista). El controlador es el encargado de realizar la abstracción de los datos, haciendo que la vista y las acciones sean independientes. 5.2.- Cuestiones de implementación reseñables Métodos de una clase: todas las clases que hemos implementado, que necesitan de un listado de elementos en la aplicación y una visualización individual por pantalla, incorporaron en su implementación métodos para poder cumplir este objetivo de visualización de elementos almacenados en la base de datos, sin necesidad de instanciar objetos de dicha clase. Clases de acceso a base de datos: a la hora de implementar nuestra aplicación, hemos creado varias clases para establecer el acceso y conexión de las distintas clases con la base de datos. Hemos creado una clase de acceso a la base de datos en función de los objetos con los que estemos trabajando. Es una manera de ordenar las operaciones por objeto. Por ejemplo, todas las operaciones de acceso a base de datos que estén relacionadas con el objeto centro se realizaran en una clase denominada CentroBO. 37 Utilización de struts: para la implementación de la web nos hemos basado en la utilización de struts. Struts es un framework que implementa el modelo patrón vista controlador en Java que es el modelo que hemos seguido para el desarrollo de la web. El motivo por el que nos decantamos a utilizarlo es que simplifica en gran medida la implementación de una arquitectura según el patrón MVC. Nos ayuda a gestionar el workflow de la aplicación, del modelo de objetos y de la generación de la interfaz. Para ello utilizaremos dentro de las JSP’s etiquetas propias que proporciona el framework de struts. A continuación vamos a explicar brevemente como funciona struts:  Un usuario realiza una petición.  Cada petición se asocia con una determinada regla de negocio.  La acción necesita de un conjunto de datos que se encapsulan en un objeto llamado Form. Si no se pasan las validaciones de este formulario se mostrará de nuevo, para que el usuario vuelva a introducir los datos.  Una vez que se han pasado las validaciones del formulario, se ejecutará la acción que corresponda. El resultado de ejecutar esta acción puede ser favorable o no. En función de dicho resultado se mostrará diferentes páginas de presentación. Los mensajes mostrados se almacenarán en un fichero de recursos que ayuda a facilitar el mantenimiento y la internacionalización de las aplicaciones.  Cada elemento se construye por separado y se relacionan en el fichero struts-config.xml que es el que define la lógica. 5.3. Cuestiones reseñables sobre la base de datos Relaciones 1:N y 1:1: en nuestra base de datos existen relaciones de diferentes tipos. Las relaciones tipo 1:1 y 1:N se transformaron en tablas al igual que las relaciones de tipo N:M. Identificadores principales auto numéricos: en nuestra base de datos existen identificadores principales que son auto numéricos. Único usuario sobre la base de datos: nuestra base de datos ha sido diseñada con un único usuario. Los credenciales de este usuario se utilizarán desde la parte de la lógica de la aplicación para establecer la conexión con la base de datos. 38 6. Conclusiones y posibles ampliaciones Este proyecto cumple los objetivos que perseguíamos con esta primera fase. Esta página web es la manera de extender y acercar un negocio a un mayor número de posibles compradores. Además supone el realizar un seguimiento y mantenimiento del negocio de una manera más sencilla y fiable. Todo esto se logra gracias a un interfaz muy sencillo y amigable que no requiere de grandes esfuerzos para aprender a manejar la aplicación web. Por eso hemos dedicado un gran esfuerzo en cuidar su desarrollo. Para poder realizar el proyecto tal y como queríamos, resultó indispensable el majeo de algunos conocimientos y lenguajes, que no habíamos visto a lo largo de la carrera. El uso del lenguaje java y del framework de struts son algunos de los conocimientos que hemos necesitado para llevar a cabo nuestro desarrollo. No obstante, nosotras contábamos con la ventaja de tener ya gran parte de los conocimientos que necesitábamos adquiridos. Esto nos ha facilitado enormemente la implementación del código de la web. No obstante pese a ello, el hecho de iniciar una aplicación desde cero no ha sido tarea fácil ya que además hay que establecer la configuración de todas las herramientas que hemos utilizado para el desarrollo. También hemos recurrido a la utilización de conocimientos adquiridos en las distintas asignaturas de la carrera. Algunos de estos conocimientos son el lenguaje de modelado UML, patrones de diseño, creación y manejo de bases de datos etc. Otra cosa que nos ha resultado difícil has sido el realizar una estimación del tiempo y los costes que nos llevarían realizar el proyecto por varios motivos:  La inexperiencia a la hora de hacer estimaciones de proyectos.  El no saber a priori el trabajo que supondría la realización del proyecto, y la dedicación al mismo, lo que nos supuso la realización de una estimación “a ciegas”. Por último tenemos que destacar que para nosotras el mayor obstáculo ha sido el ser fiel al cumplimiento de los plazos fijados en las distintas fases del proyecto. El no tener exclusiva dedicación en el desarrollo del proyecto ha hecho que las fechas iniciales se fueran dilatando en el tiempo más de lo que nos hubiera gustado. 6.1. Ampliaciones Una de las características de las páginas web son la posibilidad de que se reinventen, es decir de añadir, eliminar y modificar funcionalidad a medida que se requiera. Entre las posibles ampliaciones que se podrían realizar en el futuro podemos pensar en las siguientes opciones:  En el futuro habría que mejorar el foro como herramienta para conocer la opinión de los usuarios con respecto a la web y al negocio. Esto proporcionaría una visión diferente del negocio y nos permitirá mejorar la situación de nuestro negocio en el mercado.  Igualmente habría que añadir funcionalidad a la página web a medida que fuera creciendo el negocio.  Una de las maneras de hacer mejor una web es mejorando al máximo posible su rendimiento. Para ello tendríamos que estudiar la volumetría de tráfico que tiene la web y así determinar el número de recursos que son necesarios para dar un soporte óptimo.  Una manera de mejorar la contabilidad de la empresa es mediante su automatización. Esto podría realizarse mediante el control de los pedidos que se vayan pagando a través de la web y los pedidos que la empresa realice a los diferentes proveedores. Así podemos obtener el resultado de los ingresos y los gastos y saber de una manera más rápida el balance de cuentas de la empresa.  La implementación de conectividad entre la aplicación y una pasarela de pagos real es una de las funcionalidades que se nos ha quedado pendientes en esta primera fase. Así el pago de los pedidos de los clientes se re direccionará al servidor seguro del banco, que será el encargado de aceptar o rechazar el pago y devolver el resultado de la transacción a la web.  Una funcionalidad que se nos ocurre que se podría implementar en una segunda fase es la posibilidad de ofrecer al cliente ciertos productos tras realizar una compra y en función de lo que acabase de comprar. Es una manera de aprovechar el momento de compra impulsiva de los clientes para aumentar las ventas además de proporcionar un asesoramiento personalizado a los clientes.  A medida que aumentara el negocio se podría pensar en crear más perfiles de administrador y distribuir las tareas entre todos los perfiles. Por ejemplo uno de los perfiles podría ser el encargado de estudiar las ventas que se van 39 registrando mientras que otro podría dedicarse exclusivamente a controlar el stock de los productos del catálogo. Cada perfil vería exclusivamente las opciones correspondientes a sus funciones. Al mismo tiempo existiría un perfil “maestro” que sería el encargado de distribuir las funciones y gestionar los diferentes roles administrativos de la web.  Adaptar el diseño de la web a los nuevos recursos gráficos que vayan surgiendo en el futuro. Esto nos proporcionará una web más vistosa atractiva e interactiva para los usuarios.  Por último sería muy útil e interesante el crear un microsite de la web para poder acceder a la aplicación desde dispositivos móviles como tablets o smartphones, ya que actualmente cada vez se utiliza más dichos dispositivos para conectarse a internet. 40 Índice de Contenido Análisis del Sistema de Información ................................................................................................................................ 43 1. Definición del Sistema .................................................................................................................................................... 43 1.1. Determinación del Alcance del sistema .......................................................................................... 43 1.2. Ámbito de la aplicación y perspectiva del proyecto ..................................................................... 43 1.3. Objetivos del sistema ......................................................................................................................... 43 1.4. Identificación del entorno tecnológico ............................................................................................ 44 1.5. Especificación de estándares y normas ........................................................................................... 44 1.6. Identificación de usuarios participantes y finales.......................................................................... 44 2. Establecimiento de Requisitos ....................................................................................................................................... 46 2.1. Obtención de Requisitos .................................................................................................................... 46 2.1.1 Requisitos No Funcionales .............................................................................................................. 46 2.1.2 Requisitos Funcionales .................................................................................................................... 47 2.2. Especificación de Casos de Uso ........................................................................................................ 48 3. Identificación de Subsistemas de Análisis ................................................................................................................... 50 4. Análisis de los Casos de Uso.......................................................................................................................................... 61 4.1. Identificación de Clases Asociadas a un Caso de Uso .................................................................. 61 4.2. Descripción de la Iteración de Objetos ............................................................................................ 61 5. Análisis de Clases ............................................................................................................................................................ 70 5.1. Identificación de Responsabilidades y Atributos .......................................................................... 70 5.2. Identificación de Asociaciones y Agregaciones ............................................................................. 70 5.3. Identificación de Generalizaciones .................................................................................................. 70 6. Definición de las Interfaces de Usuario ........................................................................................................................ 72 6.1. Principios generales ........................................................................................................................... 72 6.2. Especificación de formatos Individuales de la Interfaz ................................................................ 72 6.3. Formatos de impresión ...................................................................................................................... 72 7. Especificación del Plan de Pruebas ............................................................................................................................... 73 8. Aprobación del Análisis del sistema de Información ................................................................................................. 74 41 Análisis del Sistema 48 En la aplicación se distinguen tres actores asociados a cada unos de los roles que pueden tomar los usuarios que naveguen a través de la web de la aplicación. Entre ellos se establece una jerarquía de actores de manera que cualquier usuario con perfil Cliente o Administrador podrá realizar las acciones de un Usuario, y cualquier usuario Administrador podrá realizar las funciones de un Cliente (con flujos adaptados a la finalidad de cada perfil, es decir, por ejemplo ambos usuarios podrán realizar pedidos, pero un Cliente realizará un pedido para él, mientras que un Administrador realizará un pedido para la tienda, con lo cual el flujo variará en ambos procesos).  Actor Usuario: cualquier persona anónima que accede a la web de la aplicación tiene acceso a funcionalidades sin necesidad de darse de alta en el sistema. Podrá realizar acciones como consultar datos acerca de la empresa, ver las diferentes tiendas que tiene en España, realizar cualquier consulta…  Actor Cliente: usuario registrado en el sistema con una determinada nomenclatura y que tendrá acceso a funcionalidades restringidas adaptadas a ese perfil de usuario tales como la realización de un pedido, acceso al programa Mendel de descendencia genética etc.  Actor Administrador: usuario registrado en la aplicación con un código específico que puede realizar las operaciones propias de mantenimiento de la web y gestión de la pajarería. Entre sus funcionalidades podemos destacar el poder realizar pedidos de productos a proveedores o la modificación del catálogo de productos. Usuario Cliente Administrador Figura 1. Jerarquía de usuarios 2.2. Especificación de Casos de Uso Un caso de uso es una secuencia de transacciones que son realizadas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas, es decir, es un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona una respuesta a eventos que se producen en el mismo. Por cada caso de uso es necesario especificar información relativa a:  Actores: es toda entidad externa que interactúa con el sistema y que demanda una funcionalidad de este.  Descripción del escenario: es decir, cómo un usuario interactúa con el sistema y cuáles son los distintos caminos por los que puede evolucionar nuestro caso de uso.  Precondiciones y postcondiciones: son las condiciones que han de darse antes para que se realice un caso de uso y cuáles son las condiciones que se cumplen posteriormente.  Identificación de las interfaces de usuario, es la especificación de la interfaz de usuario donde se desarrolla el caso de uso.  Flujo de eventos y condiciones de fallo, específica el flujo de eventos que se desarrollan dentro del caso de uso en condiciones óptimas, también debe especificar el flujo del tratamiento que realiza el sistema en condiciones de fallo. 49 En esta fase cada caso de uso recoge información general de sistema, de modo que cada caso de uso puede englobar uno o varios requisitos del sistema. 50 3. Identificación de Subsistemas de Análisis El objetivo de esta actividad es facilitar el análisis del sistema de información llevando a cabo la descomposición del sistema en subsistemas. El análisis de estos subsistemas está orientado a identificar los procesos de negocio. Para identificar cada subsistema, vamos a agrupar las funcionalidades de nuestro sistema por perfil del posible usuario que puede acceder a la web y además por proceso de negocio. Siguiendo este razonamiento hemos descompuesto nuestro sistema en tres paquetes funcionales:  Paquete funcional público  Paquete funcional cliente  Paquete funcional administrador Figura 2. Paquetes funcionales del sistema Paquete funcional público El paquete funcional público abarca todas las operaciones que pueden ser realizadas por cualquier usuario que acceda a la web. Las operativas que hemos identificado dentro de este paquete son: - Acceso al formulario de alta en el sistema para poder acceder con un perfil Cliente. - Consulta del catálogo de productos ofrecidos por la tienda on-line. De cada producto se podrá consultar además de su código y nombre, su precio unitario y el número de unidades disponibles en el almacén. El usuario podrá buscar un producto concreto para visualizar únicamente la información de dicho producto. - Consulta de características de las distintas especies. El usuario podrá consultar distintos aspectos como cuidados, habilidades, enfermedades y curiosidades de las especies de pájaros que existen en la tienda. - Consulta de centros. El usuario podrá conocer la localización, teléfono e email de las distintas tiendas que existen en España. De esta forma el usuario puede conocer cuál es su centro más cercano. - Acceso al formulario de contacto. El usuario tendrá la posibilidad de contactar con una tienda concreta enviando un e mail. Así puede preguntar las dudas que le surgen acerca de cualquier producto, compra online etc. al centro que más le interese. 51 Casos de uso para el paquete funcional público Figura 3. Paquete funcional público 1.- Caso de uso Alta: Actor: Usuario no registrado. Descripción: Cualquier usuario que acceda a la web de la pajarería puede registrarse rellenando un formulario de alta con sus datos personales. Precondiciones: Seleccionar el enlace que accede al formulario para registrarse en el sistema. Postconciciones: Se da de alta al usuario en la web de la pajarería. Flujo de eventos. 1. El usuario accede a la web de la aplicación. 2. El sistema accede y muestra un menú lateral que contendrá todos los servicios a los que tiene acceso cualquier usuario. 3. El usuario solicita el acceso al registro en la aplicación. 4. El sistema accede, y muestra el formulario que el usuario deberá rellenar para darse de alta en la web. 5. El usuario rellenará el formulario de alta. 6. El sistema recoge el formulario rellenado y guarda la información en la base de datos. A partir de ese momento el usuario pasará a ser un cliente de la aplicación y por tanto podrá acceder a la funcionalidad asociada a este perfil. Condiciones de fallo. 1. Si algún campo del formulario no se ha rellenado correctamente el sistema impedirá el alta y mostrará al usuario un mensaje de error indicándolo. 2. En caso de que se produzca un error al tratar de guardar los datos del usuario, el sistema también mostrará un mensaje de error indicándolo. Interfaz: Paquete funcional público. 2.- Catálogo: Actor: Usuario no registrado. Descripción: Cualquier usuario que acceda a la web de la pajarería puede consultar el catálogo de productos de la tienda. Precondiciones: Seleccionar la búsqueda de productos. Postconciciones: devuelve el listado de productos que se ajusten a los criterios de búsqueda. Flujo de eventos. 1. El usuario accede a la web de la aplicación. 2. El sistema accede y muestra un menú lateral que contendrá todos los servicios a los que tiene acceso cualquier usuario. 3. El usuario solicita la opción de menú de catálogo de productos. 4. El sistema accede, y muestra el formulario que el usuario deberá rellenar con sus criterios de búsqueda. 5. El sistema realiza la búsqueda según los criterios de búsqueda. Interfaz: Paquete funcional público. 52 3.- Caso de uso Características: Actor: Usuario no registrado. Descripción: Contiene información de diferentes aspectos acerca de varias especies de aves. Precondiciones: Elegir un aspecto del cual desea conocer información y la especie sobre la que desea informarse. Postconciciones: Se muestran por pantalla la información solicitada de la especie elegida. Flujo de eventos. 1. El usuario accede a la web de la aplicación. 2. El sistema accede y muestra un menú lateral que contendrá todos los servicios a los que tiene acceso cualquier usuario. 3. El usuario solicita el acceso las características de las aves. 4. El sistema accede, y muestra el menú horizontal con las opciones de: cuidados, habilidades, enfermedades y curiosidades. Dentro de cada opción se muestra una lista desplegable con las distintas especies de aves y variedades dentro de cada una de ellas. 5. El usuario elige una opción del menú horizontal y una especie (corresponde al caso de uso Selección especie). 6. El sistema recoge la elección del usuario y muestra la información correspondiente a la opción seleccionada y a la especie y variedad de ave. Interfaz: Paquete funcional público. 4.- Caso de uso Consulta de Centros: Actor: Usuario no registrado. Descripción: Cualquier usuario que acceda a la web de la pajarería puede consultar información de los centros dados de alta en el sistema. Precondiciones: Realizar una búsqueda de centros. Seleccionar una provincia dentro del mapa. Postconciciones: Se muestra la información de contacto (dirección, teléfono de contacto e email) de la tienda elegida por el usuario. Flujo de eventos. 1. El usuario accede a la web de la aplicación. 2. El sistema accede y muestra un menú lateral que contendrá todos los servicios a los que tiene acceso cualquier usuario. 3. El usuario solicita el acceso a la consulta de centros. 4. El sistema accede, y muestra un mapa de España con todas sus provincias delimitadas. 5. El usuario elige una provincia y pincha sobre ella (corresponde al caso de uso Selección provincia). 6. El sistema muestra todas las tiendas ubicadas en esa provincia (con su dirección, teléfono y correo electrónico para poder contactar) o un mensaje informativo de que no todavía no existen tiendas en la provincia seleccionada. Interfaz: Paquete funcional público. 5.- Caso de uso Formulario de Contacto: Actor: Usuario no registrado. Descripción: La aplicación contiene un formulario a través del cual el usuario puede formular cualquier pregunta a la empresa a través de la web. Precondiciones: Posibilidad de elegir el centro al que se quiere enviar la consulta introduciendo su dirección de correo electrónico. Postconciciones: Se muestra un mensaje de éxito si todo ha ido bien y se envía el email al centro elegido. Flujo de eventos principal. 1. El usuario accede a la web de la aplicación. 2. El sistema accede y muestra un menú lateral que contendrá todos los servicios a los que tiene acceso cualquier usuario. 3. El usuario solicita el acceso al formulario de contacto con la empresa. 4. El sistema accede, y muestra el formulario de contacto. 5. El usuario rellena el formulario, elige una provincia y posteriormente un centro al que enviará la pregunta y lo envía al sistema (corresponde al caso de uso enviar pregunta). 6. El sistema recibe la información, y abre una ventana de Outlook rellenada con los datos del formulario para ser enviado al centro elegido. Condiciones de fallo. 53 1. El sistema mostrará un mensaje de error en caso de que algún campo del formulario de contacto sea incorrecto o no se haya rellenado la dirección de correo electrónico de la tienda a la cual se enviara el formulario. 2. También se mostrará un mensaje de error cuando por algún motivo (caída del sistema, perdida de conexión con las Base de Datos etc…) no se haya podido enviar el correo. Interfaz: Paquete funcional público. Paquete funcional cliente El paquete funcional cliente abarca todas las operaciones que pueden ser llevadas a cabo por un usuario que ya ha sido dado de alta previamente con el perfil "Cliente". Las operativas que hemos detectado dentro de este paquete funcional son: - Identificarse/login. El usuario podrá introducir su login de usuario y password y el sistema le permitirá acceder a su cuenta personal. Todos los casos de uso relacionados con el paquete funcional cliente y administrador requieren la comprobación del usuario para poder llevarse a cabo. - Realizar pedidos. El cliente tiene la posibilidad de hacer compras por internet. Podrá realizar búsquedas de los productos que desea comprar (por su código, familia, nombre o nada). De esta forma puede seleccionar los productos que se quieren adquirir y la cantidad de cada uno. También puede ver un desglose de toda la compra antes de realizarla para poder quitar productos de su cesta, añadir otros nuevos o modificar el pedido de alguno de sus productos. Visualizar información de los productos como su código, nombre, número de unidades existentes en el almacén y el precio por unidad. El cliente tiene la posibilidad de elegir la forma de pago de su pedido (contra rembolso o por transferencia bancaria). En caso de que todo el proceso de compra sea correcto, el pedido se realizará correctamente. - Acceso al foro. El usuario podrá intercambiar información con los distintos usuarios. El cliente puede crear nuevos mensajes para los distintos temas en los que se divide el foro; y para una especie concreta También puede responder a los mensajes que existen. - Modificación de los datos de usuario. El cliente puede revisar sus datos y cambiarlos o actualizarlos. En caso de modificar los datos de acceso como cliente puede verificar si sus nuevos datos no se han cogido todavía por otros clientes anteriormente. En este apartado también tendrá la posibilidad de darse de baja como cliente de la aplicación. - Acceso al Programa Mendel. El usuario podrá realizar un pronóstico de la posible descendencia de pájaros Diamante de Gould, en función de los genes del padre y madre. Se podrá visualizar un gráfico y tabla con los resultados en porcentajes. Casos de uso para el paquete funcional cliente Figura 4. Paquete funcional cliente 54 1.- Caso de uso Pedido: Actor: Usuario no registrado. Descripción: Cualquier usuario que este dado de alta en el sistema como usuario de tipo cliente puede realizar pedidos de productos. Precondiciones: Seleccionar el enlace que accede al formulario para registrarse en el sistema. Postconciciones: Se da de alta al usuario en la web de la pajarería. Flujo de eventos. 1. El usuario se loga en la web de la aplicación. 2. El sistema accede y muestra un menú lateral que contendrá todos los servicios a los que tiene acceso el usuario cliente. 3. El usuario hace una búsqueda de productos a través del popup de búsqueda de productos. 4. El sistema devuelve el listado de productos. 5. El usuario selecciona los productos que desea y los añade al listado de productos seleccionado. 6. El usuario continúa con el proceso de compra. 7. El usuario selecciona la forma de pago (contra reembolso o transferencia bancaria). 8. El sistema almacena la información relativa al pedido y devuelve el resultado de la operación. Condiciones de fallo. 1. Si algún campo del formulario no se ha rellenado correctamente el sistema impedirá el alta y mostrará al usuario un mensaje de error indicándolo. 2. El sistema no debe permitir añadir una cantidad de productos superior al stock existente. 3. En caso de que se produzca un error al tratar de guardar los datos del usuario, el sistema también mostrará un mensaje de error indicándolo. Interfaz: Paquete funcional cliente. 2.- Caso de uso Foro: Actor: Usuario no registrado. Descripción: Cualquier usuario que acceda a la web podrá hacer consultar e interactuar con otros usuarios a través del foro. Precondiciones: Seleccionar el enlace que accede al apartado del foro. Postconciciones: Muestra los distintos temas del foro. Flujo de eventos. 1. El usuario accede a la web de la aplicación. 2. El sistema accede y muestra un menú lateral que contendrá todos los servicios a los que tiene acceso cualquier usuario. 3. El usuario solicita la opción del menú del foro. 4. El sistema accede, y muestra los mensajes del foro agrupados por temas. 5. El usuario da de alta un mensaje sobre un tema. 6. El sistema da de alta el mensaje de modo que estará disponible para el resto de usuarios. Condiciones de fallo. 1. Si algún campo del formulario no se ha rellenado correctamente el sistema impedirá el alta y mostrará al usuario un mensaje de error indicándolo. Interfaz: Paquete funcional cliente. 3.- Caso de uso Modificación: Actor: Usuario no registrado. Descripción: Cualquier usuario que acceda a la web de la pajarería puede modificar sus datos personales. Precondiciones: El usuario tiene que estar dado de alta en el sistema. Postconciciones: Se modifican los datos de usuario. Flujo de eventos. 1. El cliente accede a la opción del menú correspondiente a la Gestión de datos de Usuario tras logarse en la web (corresponde al caso de uso Identificarse). 2. El sistema muestra el formulario de modificación de los datos de usuario. 3. El cliente puede consultar, modificar o borrar (darse de baja) sus datos de usuario en el sistema. 4. En caso de que el cliente solicite al sistema guardar modificaciones sobre sus datos de usuario, éste validará que los nuevos datos introducidos por el cliente son correctos y en caso de serlo los guardará en el sistema. 5. En caso de que lo que quiera el cliente sea darse de baja, el sistema pide confirmación por parte del cliente para continuar con el proceso de baja. Si el cliente confirma su decisión, el sistema eliminará sus 55 datos de alta y toda la información referente a él. A continuación la aplicación mostrará al cliente el menú de usuario ya que no está ya dado de alta en el sistema. Condiciones de fallo. 1. Si el cliente tiene pedidos pendientes, el sistema emitirá un mensaje advirtiendo de esto e impedirá que el cliente pueda darse de baja en la web. 2. En caso de que se produzca algún fallo al actualizar la información en la base de datos se mostrará un mensaje de error y no se guardarán las modificaciones. Interfaz: Paquete funcional cliente. 4.- Caso de uso Mendel: Actor: Usuario no registrado. Descripción: La aplicación muestra un formulario que le permite al cliente introducir los datos de los pájaros macho y hembra de los cuales se quiere comprobar la posible descendencia genética que tendrían. Precondiciones: El cliente debe ser un usuario válido, rellenar el formulario con los fenotipos de los progenitores y solicitar al sistema que calcule la descendencia con esos datos. Postcondiciones: El sistema calculará y mostrará la posible descendencia a partir de los datos proporcionados por el cliente Flujo de eventos. 1. El cliente accede a la opción del menú correspondiente al Programa Mendel tras logarse en la web (corresponde al caso de uso Identificarse). 2. El cliente introduce los fenotipos del macho y la hembra. 3. El sistema validará que los fenotipos introducidos por el usuario son válidos y calculará la posible descendencia. Condiciones de fallo. 1. Si el sistema detecta algún error durante el proceso de cálculo de la descendencia mostrará un mensaje indicándolo y volverá a la página principal del programa Mendel. Interfaz: Paquete funcional cliente. Paquete funcional administrador El paquete funcional administrador abarca todas las operaciones que pueden ser llevadas a cabo por un usuario que ya ha sido dado de alta previamente con perfil "Administrador". Las operativas que pueden realizarse dentro de este módulo son: - Identificarse/login. El usuario podrá introducir su login de usuario y password y el sistema le permitirá acceder a su cuenta personal. Todos los casos de uso relacionados con el paquete funcional cliente y administrador requieren la comprobación del usuario para poder llevarse a cabo. - Gestionar clientes. El administrador podrá realizar búsquedas de clientes concretos en función de distintos filtros como pueden ser su código de cliente, nombre, alguno de sus apellidos, el estado de un determinado pedido del cliente o la fecha en que se realizó alguno de sus pedidos. En caso de que no introduzca ningún parámetro de búsqueda, visualizará un listado con todos los clientes dados de alta en el sistema. De cada uno de ellos obtendrá como información su código de cliente, nombre, apellidos, estado de pedido y fecha de cada uno de los pedidos que cada cliente haya realizado. El administrador podrá elegir un pedido concreto de cualquier cliente y modificar su estado, en función de si el pedido ha avanzado o no (por ejemplo el pedido ya ha sido entregado al cliente o ha sido pagado) y guardar los cambios en el sistema. Por otro lado también tiene la posibilidad de dar de baja del sistema a clientes. - Gestionar proveedores. Al igual que en el apartado anterior el administrador podrá realizar búsquedas de proveedores en función de algunos parámetros (código, nº documento, nombre, apellidos). El administrador puede eliminar uno o varios proveedores del sistema, también puede elegir un proveedor y modificar alguno de sus datos como pueden ser su nombre, país etc… o puede simplemente elegir un proveedor para ver su ficha personal que contendrá toda la información suya. Por último podrá dar de alta a nuevos proveedores en el sistema y modificar sus catálogos de productos pudiendo eliminar o añadir nuevos productos. - Gestión de productos. El usuario podrá realizar un control de los productos existentes en el almacén. Se pueden realizar búsquedas de productos concretos o mostrar todos los productos existentes. Se podrán realizar pedidos de productos que estén desabastecidos o añadir nuevos productos en base de datos que entren en la tienda. El administrador también puede modificar alguno de los aspectos de un producto ya existente como puede ser su precio o por último eliminar productos que ya estén descatalogados. - Gestión de envíos a clientes. El administrador podrá obtener un informe de los pedidos que se han realizado en unas fechas concretas. 56 - Gestión de pedidos. Se podrán consultar por un lado los pedidos que ha realizado los clientes a la tienda, y por otro los pedidos que el almacén ha hecho a proveedores. En ambos casos se pueden realizar búsquedas de pedidos concretos (filtrando por tipo de producto, fecha de realización del pedido etc…). Los resultados de las búsquedas se podrán guardar en el sistema. - Consulta de stock. El administrador puede saber o consultar en todo momento la cantidad de cada producto que hay disponible en el almacén o en una tienda determinada. También se pueden realizar búsquedas de productos para conocer únicamente las unidades de un producto determinado en una tienda. - Gestión de foro. Una de las funciones que tendrá un administrador será la gestión del foro de la web. Será el encargado de poder responder dudas o preguntas que puedan surgir a través de los diferentes hilos de conversación. Además también tendrá potestad para eliminar cualquier comentario o hilo de conversación que considere inadecuado o no siga la política del foro. - Generar Catálogo. Crear un folleto virtual con los productos que se ofrecen en un período determinado a precios más bajos de los habituales. El administrador puede dar de baja ofertas descatalogadas o añadir nuevos productos al catálogo. También puede visualizar el catálogo de ofertas disponible en ese momento con una breve descripción de las características de cada producto y una imagen de estos. - Visualización de gráficos. se podrán visualizar distintos gráficos en función de unos parámetros que se seleccionen como pueden ser tipo de producto, tienda y fechas… Los tipos de gráficos que se podrán consultar son: Ventas por producto en un determinado periodo de tiempo. Ventas por cada tienda. 57 Casos de uso para el paquete funcional administrador Figura 5. Paquete funcional administrador 1.- Caso de uso Gestión Clientes: Actor: Usuario registrado con perfil administrador. Descripción: Un usuario con perfil administrador puede gestionar los clientes del sistema. Precondiciones: Seleccionar la opción de menú de gestión de usuarios. Postconciciones: Se modifican los datos relativos al cliente. Flujo de eventos. 1. El usuario accede a la web de la aplicación. 2. El sistema accede y muestra un menú lateral que contendrá todos los servicios a los que tiene acceso cualquier usuario. 3. El usuario selecciona la opción de menú de gestión de clientes. 4. El sistema muestra los datos relativos al cliente, tanto datos personales como de pedidos. 5. El usuario modifica datos de usuario. 6. El sistema recoge la información y la guarda en la base de datos. Condiciones de fallo. 1. Si algún campo del formulario no se ha rellenado correctamente el sistema impedirá el alta y mostrará al usuario un mensaje de error indicándolo. 2. En caso de que se produzca un error al tratar de guardar los datos del usuario, el sistema también mostrará un mensaje de error indicándolo. Interfaz: Paquete funcional administrador. 2.- Caso de uso Gestión Proveedores: Actor: Usuario registrado con perfil administrador. Descripción: Un usuario con perfil administrador puede gestionar los proveedores del sistema. Precondiciones: Seleccionar la opción de menú de gestión de proveedores. Postconciciones: Se modifican los datos relativos al proveedor. 64 Figura 12. Pedido Figura 13. Foro 65 Figura 14. Modificación Usuario Figura 15. Mendel MÓDULO ADMINISTRADOR Figura 16. Login 66 Figura 17. Gestión Clientes Figura 18. Gestión Proveedor 67 Figura 19. Gestión Productos Figura 20. Gestión Pedidos Figura 21. Consulta Stock 68 Figura 22. Gestión Foro Figura 23. Generar Catálogo 69 Figura 24. Visualizar Gráfico 70 5. Análisis de Clases 5.1. Identificación de Responsabilidades y Atributos En esta tarea se identifican las responsabilidades y atributos relevantes de una clase. Las responsabilidades de una clase definen la funcionalidad de una clase y los atributos especifican las propiedades de una clase. 5.2. Identificación de Asociaciones y Agregaciones En esta tarea se especifican los mensajes (relaciones) establecidos entre los objetos del diagrama de iteración, estas relaciones se caracterizan por el papel que desempeña en la relación entre los objetos, su dirección y la cardinalidad. 5.3. Identificación de Generalizaciones El objetivo de esta tarea es definir la herencia y agrupación de las distintas clases. El estudio de los anteriores apartados da por resultado el siguiente Diagrama de Clases. 71 DIAGRAMA DE CLASES Figura 25. Diagrama de Clases 72 6. Definición de las Interfaces de Usuario En esta actividad se especifican las interfaces entre el sistema y el usuario: formatos de pantallas, diálogos, e informes, principalmente. El objetivo es realizar un análisis de los procesos del sistema de información en los que se requiere una interacción del usuario, con el fin de crear una interfaz que satisfaga todos los requisitos establecidos, teniendo en cuenta los diferentes perfiles a quiénes va dirigido. 6.1. Principios generales Todas las interfaces de entrada/salida del sistema seguirán la misma plantilla definido en la etapa de diseño, esto es, una cabecera con el logo de la empresa en la parte superior izquierda, el componente de logado en la parte superior derecha, que deberá estar siempre disponible, un menú lateral izquierdo diferente por cada perfil de usuario y una sección donde se recrea la navegación de la interfaz de usuario. 6.2. Especificación de formatos Individuales de la Interfaz Los campos de texto deberán tener un tamaño, en la medida de lo posible, acorde con el tamaño requerido para dicho campo, es decir, si un campo de texto admite sólo 4 caracteres el campo de texto deberá tener un ancho de 4 caracteres. Los botones deberán estar estandarizados, y por cada pantalla de entrada de datos deberá existir un botón “borrar” que permita resetear los campos introducidos previamente quedando limpio el formulario. Para evitar posibles errores en la introducción de datos deberán utilizarse en la medida de lo posible componentes de tipo combo y radio button. Las etiquetas de los componentes de tipo texto deberán alinearse a la derecha. 6.3. Formatos de impresión Existen cuatro tipos de interfaz de usuario  Pantallas de consulta. En las pantallas de consulta los elementos mostrados deberán aparecer en modo deshabilitado para impedir la modificación de estos por parte del usuario.  Pantallas de modificación. En las pantallas de modificación se cargará la información disponible de modo que los campos no editables aparecerán deshabilitados y aquellos que el usuario pueda modificar aparecerán habilitados.  Pantallas de entrada de datos. En estas pantallas estarán habilitados todos los campos. Se extenderá el uso de componentes de tipo combo y radio button para evitar en la medida de lo posible errores por inserción de usuario.  Pantallas de búsquedas. En estas pantallas el resultado de la búsqueda debe mostrarse en un componente de tipo tabla, y en él sólo se mostrará la información útil para el usuario. 73 7. Especificación del Plan de Pruebas En esta actividad se inicia la definición del plan de pruebas, el cual sirve como guía para la realización de las pruebas, y permite verificar que el sistema de información cumple las necesidades establecidas por el usuario, con las debidas garantías de calidad. Los niveles de prueba que se realizarán a lo largo de los sucesivos procesos de ciclo de vida de software son los siguientes:  Pruebas unitarias. Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente una vez que ha sido codificado  Pruebas de integración. El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados.  Pruebas del sistema. Prueban a fondo el sistema, comprobando su funcionalidad e integridad globalmente en un entorno lo más parecido al entorno de producción.  Pruebas de implantación. Comprueba el correcto funcionamiento del sistema dentro del entorno real de producción.  Pruebas de aceptación. La labor principal de este tipo de pruebas es que el usuario valide el sistema como paso previo a la puesta en marcha de la aplicación. Deberán tenerse en cuenta aspectos como : - Procesos críticos del sistema - Rendimiento del sistema - Seguridad - Disponibilidad 80 2. Definición de la Arquitectura del Sistema En esta actividad se define la arquitectura general del sistema de información, especificando las distintas particiones físicas del mismo, la descomposición lógica en subsistemas de diseño y la ubicación de cada subsistema en cada partición. También se detallará la infraestructura tecnológica necesaria para dar soporte al sistema de información. El particionamiento físico del sistema de información se especifica identificando los nodos y las comunicaciones entre los mismos, con cierta independencia de la infraestructura tecnológica que da soporte a cada nodo. En cuanto al diseño lógico se especifica la estructura de la aplicación y sus componentes sin tener en cuenta donde se localizará el software, hardware ni la infraestructura. Con el fin de organizar y facilitar el diseño, se realiza una división del sistema de información en subsistemas de diseño, como partes lógicas coherentes y con interfaces claramente definidas. Como resultado de esta actividad, se actualizan los catálogos de requisitos y normas, y se generan los siguientes productos:  Diseño de la Arquitectura del Sistema, como producto que engloba el particionamiento físico del sistema de información y la descripción de subsistemas de diseño.  Entorno Tecnológico del Sistema, que a su vez comprende la especificación del entorno tecnológico, las restricciones técnicas y la planificación de capacidades.  Catálogo de Excepciones.  Procedimientos de Operación y Administración del Sistema.  Procedimientos de Seguridad y Control de Acceso. 2.1. Definición de Niveles de Arquitectura La arquitectura adoptada para desarrollar nuestro sistema se basa en la arquitectura cliente-servidor de 3 capas sobre un sistema multiusuario distribuido a través de una red de ordenadores. En este tipo de arquitectura existen 3 figuras principales, por un lado el cliente que es quién interactúa directamente con los usuarios finales a través de la interfaz gráfica de usuario. El cliente para llevar a cabo su actividad necesita hacer peticiones de recursos y servicios, el receptor de estas peticiones es nuestra segunda figura, el servidor. Por otro lado separamos la lógica de negocio de la gestión de base de datos, es aquí donde aparece la tercera figura que será el servidor de base de datos. El servidor debe ser capaz de atender y controlar múltiples peticiones de clientes, las evalúa y decide sin son aceptadas o rechazadas, si una petición es aceptada, devolverá la información solicitada al cliente. Figura 1. Jerarquía de usuarios La comunicación entre los servidores clientes y el servidor de aplicaciones se lleva a cabo a través de una red, mediante el envío de unidades de información que se agrupan lógicamente y que se denominan paquetes de datos. Estos paquetes 81 necesitan de un protocolo para definir el formato en el que viajaran los datos entre diferentes dispositivos, para que sean reconocidos por ambos. Dicho protocolo establece una serie de propiedades en la comunicación entre las que se pueden destacar:  Sintaxis: formato de los datos que viajaran a través de la red.  Semántica: coordinación y control en el manejo de errores devueltos tras ejecutar una petición al servidor. Las características más destacadas de este tipo de arquitectura son: Combinación entre un cliente que interactúa con el usuario, y un servidor que interactúa con los recursos compartidos por la aplicación. Como ya hemos dicho el cliente proporciona una interfaz entre el usuario y el resto del sistema. El servidor procesa los datos del cliente y a su vez hace peticiones al servidor de base de datos. La relación establecida es de muchos a uno, en la que el servidor puede dar servicio a muchos clientes, regulando el acceso a sus recursos compartidos. Los clientes corresponden a procesos activos que hacen peticiones al servidor que tiene un carácter pasivo, ya que espera esas solicitudes. La comunicación entre clientes y servidores se establece mediante el intercambio de mensajes entre ambos. El mensaje es el mecanismo para la petición y entrega de solicitudes de servicio. Tanto la plataforma hardware como el sistema operativo de las máquinas clientes, servidor y servidor de base de datos no tienen porque coincidir. Si atendemos a las características que deben tener las máquinas clientes y la servidora podemos nombrar las siguientes: En cuanto al servidor: Comunicación pasiva: esperan a recibir peticiones de clientes. Procesan las peticiones y envían respuesta a los clientes. Procesan la lógica de la aplicación e interactúa con el servidor de base de datos. Son capaces de dar respuesta a múltiples peticiones. En cuanto al servidor de base de datos: Comunicación pasiva: esperan a recibir peticiones de clientes. Procesan las peticiones y envían respuesta al servidor. Son capaces de dar respuesta a múltiples peticiones. 82 En cuanto al cliente: Administra la interfaz de usuario e interactúa con él. Comunicación activa: inician la comunicación con el servidor mediante el envío de solicitudes o peticiones. Espera y recibe las respuestas a las peticiones por parte del servidor y formatea los resultados. Es capaz de conectarse a varios servidores simultáneamente. Proporciona la interfaz gráfica que será el vínculo entre los usuarios de las aplicaciones con los servidores. Además este tipo de arquitectura presenta una serie de ventajas que explican las razones por las cuales es una de las más utilizadas en la actualidad:  Cada vez son más baratas las plataformas hardware lo que ha provocado que cada vez se utilicen más las arquitecturas cliente – servidor.  Otra ventaja fundamental es la posibilidad de integrar sistemas diferentes. No todas las máquinas tienen porque utilizar el mismo sistema operativo.  Este tipo de arquitectura permite el uso de interfaces gráficas más amigables y manejables para los usuarios. De esta manera no siempre es necesario transmitir información gráfica por la red, ya que esta puede residir en el cliente, lo cual permite hacer un uso más óptimo del la red.  El mantenimiento y desarrollo de las aplicaciones que utilizan este tipo de arquitectura es más rápido ya que pueden usarse herramientas existentes como por ejemplo servidores SQL, scokets...  El hecho de estar utilizando los recursos de las máquinas clientes hace que la capacidad del sistema aumente y se puedan atender mayor número de peticiones hacia el servidor de la aplicación. Todo esto se traduce en un que el coste asumible para el funcionamiento y mantenimiento de la plataforma es menor. 2.2. Identificación de Requisitos de Diseño y Construcción En esta tarea se realiza la especificación de los requisitos que están directamente relacionados con la adopción o diseño de una arquitectura o infraestructura concreta, y que pueden condicionar el diseño o la construcción del sistema de información. Entre estos requisitos pueden estar los relacionados con lenguajes, rendimiento de los distintos elementos de la arquitectura, así como criterios de ubicación de módulos y datos en los distintos nodos. DNS (Domain name service) - Domain Name System o DNS (en español: sistema de nombres de dominio) es un sistema de nomenclatura jerárquica para computadoras, servicios o cualquier recurso conectado a Internet o a una red privada. Este sistema asocia información variada con nombres de dominios asignados a cada uno de los participantes. Su función más importante, es traducir (resolver) nombres inteligibles para las personas en identificadores binarios asociados con los equipos conectados a la red, esto con el propósito de poder localizar y direccionar estos equipos mundialmente. El servidor DNS utiliza una base de datos distribuida y jerárquica que almacena información asociada a nombres de dominio en redes como Internet. Aunque como base de datos el DNS es capaz de asociar diferentes tipos de información a cada nombre, en nuestro caso lo usaremos para asignar a nuestra IP pública un nombre de dominio Router – Es un dispositivo que proporciona conectividad a nivel de red. Su función principal consiste en enviar o encaminar paquetes de datos de una red a otra, es decir interconectar subredes. En nuestro caso configuraremos el router como un servidor virtual de modo que los usuario remotos puedan conectarse vía web o ftp a nuestro sitio vía IP pública y las peticiones se redireccionan al servidor web con una dirección IP privada, es decir, el router será el encargado de hacer el nateo de ip pública – ip privada y así redirigir peticiones web a nuestro servidor web. Firewall – Es una parte del sistema que se encarga de bloquear las peticiones no autorizadas. Servidor Web o servidor HTTP - es un programa informático que procesa una aplicación del lado de servidor realizando conexiones bidireccionales y/o unidireccionales y síncronas o asíncronas con el cliente generando o cediendo una respuesta en cualquier lenguaje o aplicación del lado del cliente. El código recibido por el cliente suele ser compilado y ejecutado por un navegador web. Para la transmisión de todos estos datos suele utilizarse algún protocolo. La principal función de un servidor web es almacenar los archivos de un sitio y emitirlos por internet para poder ser visitado por los usuarios. Básicamente, un servidor web es una gran computadora que guarda y transmite datos vía Internet. Cuando un usuario entra en una página de Internet su navegador se comunica con el servidor enviando y recibiendo datos que determinan qué es lo que ve en la pantalla. Por eso decimos que los servidores web están para almacenar y transmitir datos de un sitio según lo que pida el navegador de un visitante. Para nuestro sistema utilizaremos un servidor web Apache. 83 Servidor de aplicaciones - Es un dispositivo software encargado de de ejecutar la aplicación. El servidor de aplicaciones gestiona las funciones lógicas de negocio y el acceso a los datos de la aplicación. Como servidor de aplicaciones utilizaremos Websphere 6.1 que soporta el estándar J2EE. Servidor de Base de Datos - es la máquina, física o lógica, sobre la que corre un servicio que ejecuta un Sistema Gestor de Bases de Datos Relacionales (SGBDR). En nuestro caso usaremos como sistema gestor de Base de Datos MySQL 2.3 Especificación de Excepciones El objetivo de esta tarea es la definición de los comportamientos no habituales en el sistema, que reflejan situaciones anómalas o secundarias en el funcionamiento y ejecución del sistema de información. Para ello, se establece previamente el nivel de especificación de las mismas, así como los criterios de catalogación y clasificación. 2.3.1 DNS Caído Descripción – El servidor DNS está caído o está fuera de servicio. Elemento Afectado – Acceso a la aplicación. Respuesta del sistema – El navegador devuelve el tipo de error servidor no encontrado. 2.3.2 Servidor Web Caído Descripción – El servidor web está caído o está fuera de servicio. Elemento Afectado – Acceso a la aplicación Respuesta del sistema – El navegador devuelve el tipo de error servidor no encontrado 2.3.3 ISP no da servicio Descripción – Nuestro ISP no nos da servicio. Elemento Afectado – Acceso a la aplicación. Condiciones Previas – El dns está levantado. Respuesta del sistema – El navegador devuelve el tipo de error servidor no encontrado (Error 404). 2.2.4 Servidor de Aplicaciones Caído Descripción – Nuestro Servidor Web está caído. Elemento Afectado – Acceso a la aplicación. Condiciones Previas – El dns está levantado y el ISP está dando servicio. Respuesta del sistema – El navegador devuelve el tipo de error Servidor no encontrado (Error 404). 2.2.5 Servidor de Base de datos Caído Descripción – Nuestro Servidor Web está caído. Elemento Afectado – Cualquier consulta a base de datos. Condiciones Previas – El dns está levantado y el ISP está dando servicio al igual que nuestro servidor web y de aplicaciones. Respuesta del sistema – El navegador devuelve el tipo de error de aplicación (Error 500). 84 2.4 Especificación de Estándares y Normas de Diseño y Construcción En esta tarea se definen los estándares técnicos y de nomenclatura, normas y recomendaciones de codificación para este proyecto que se va a desarrollar dentro de la tecnología J2EE. Los objetivos de esta tarea es definir estándares de codificación para el desarrollo de una aplicación J2EE desarrollada mediante el patrón MVC e implementada con el framework de Struts. Definiciones y Acrónimos Acrónimo Definición JEE Java Enterprise Edition JSP Java Servlet Pages MVC Model View Controller UTF-8 8-bit Unicode Transformation Format CSS Cascading Style Sheets URI Uniform resource Identifier Los documentos utilizados en la especificación de esta normativa son los siguientes: Referencia Nombre http://www.oracle.com/technetwork/java/codeconv138413.html Code Conventions for the Java Programming Language. http://java.sun.com/blueprints/code/namingconv entions.html Guidelines, Patterns, and code for end-to-end Java applications Estándares generales Encoding – Para evitar problemas de compatibilidad todos los ficheros deben ser codificados en UTF-8. Estructura de directorios – El formato del proyecto debe seguir la estructura de plantilla de un proyecto web. A continuación se detalla la estructura del proyecto 1º nivel 2º nivel 3º nivel 4º nivel 5º nivel 6º nivel 7º Nivel Descripción Pajareria Web Nombre del proyecto JavaSource Directorio con los fuentes del proyecto es proyecto common s utils Clases de utilidad del proyecto es proyecto pajareria action Clases controladoras es proyecto pajareria bo Clases del modelo de acceso a datos es proyecto pajareria vo Interfaz de las entidades del proyecto es proyecto pajareria vo impl Clases que implementa las interfaces es proyecto pajareria form Formularios es proyecto pajareria exceptio ns Clases para el control de excepciones pajareriaw eb resources Directorio con los properties multiidiomas WebContent Directorio de contenido Web 85 WebContent css Hojas de Estilo js Javascript jsp Jsp images Imágenes de la aplicación WEB-INF Directorio de configuración de ficheros de despliegue (web.xml, struts-config.xml.) WEB-INF classes Ruta de los binarios de la aplicación Nomenclatura – Por convenio aquella nomenclatura que por estandarización pueda escribirse en inglés se mantendrá en inglés (insert, delete, action.) y toda aquella que tenga que ver con lógica de negocio se definirá en castellano (nombres de procedimiento, constantes). Nombres de clase – Los nombres de clases intercalarán mayúsculas y minúsculas. Los nombres de clases deben ser cortos y descriptivos. Todas las entidades tienen que tener un constructor así como los get y set de todos sus atributos. El número máximo de caracteres por línea es de 80. Cada clase tendrá un máximo de 2000 líneas de código y cada procedimiento de 150 líneas. Métodos obsoletos – No está permitido el uso de métodos deprecated. Constantes – Existirá una clase de constantes que contendrá todos los literales de la aplicación para tenerlos centralizados. Los nombres de las constantes se escriben en mayúsculas Application-context – Para todos los literales de las jsp o componentes visuales existirá un fichero de propiedades (uno por idioma) para permitir su internalización. Comentarios – Los comentarios de clases deben dar información al desarrollador sobre la implementación de la clase. Para cada clase se deben especificar los parámetros de entrada y de salida. Variables – Las variables de clase deben estar inicializadas. Propiedades – El acceso y/o modificación de las propiedades (atributos) de una clase deben realizarse a través de los métodos get() y set(). Código JSP – Sólo está permitido el uso de los taglib de struts. No está permitido el uso de includes salvo el caso de los menús laterales. En lugar del uso de los includes se hará uso de los tags de tiles. Javascript – Todas las funciones javascript estarán dentro los ficheros js. No está permitido su uso dentro de las jsp. CSS – Los estilos para los componentes visuales de la aplicación se darán mediantes css. Formularios – El paso de parámetros entre la vista y el controlador se realizará a través de formularios. El nombre para estos elementos tiene que ser identificativo de la entidad a la que representa con el sufijo Form.java. 2.5 Identificación de los Subsistemas de Diseño En esta tarea se divide de forma lógica el sistema de información en subsistemas de diseño, con el fin de reducir la complejidad y facilitar el mantenimiento. Hemos agrupado los distintos subsistemas que forman el sistema por funcionalidad de modo que hemos obtenido 5 subsistemas. Otros aspectos que hemos tenido en cuenta a la hora de identificar los subsistemas son que exista el menor acoplamiento posible entre ellos, de modo que permite su desarrollo en paralelo y que el mantenimiento o modificación de cada módulo no afecte al resto. El siguiente diagrama muestra los subsistemas en los que se ha dividido nuestra aplicación: 86 Figura 2. Diagrama de Subsistemas Subsistema de gestión tienda virtual. Agrupa todas las operaciones que puede realizar un usuario no logado en el sistema tales como consulta de información, consulta de centros, formularios de contacto, consulta de las características de una especie. También incluye todas las operaciones del foro (tanto a nivel del cliente como del administrador), la gestión de centros del administrador y la explotación de estadísticas también por parte del administrador. Subsistema de gestión de usuarios. Agrupa toda la operativa de alta de usuarios y la consulta baja y modificación de usuarios por parte del administrador del sistema. Subsistema compra On-line. Agrupa la operativa de consulta del catálogo de productos por parte del usuario logado (cliente), la operativa de compra de productos por parte del cliente y la gestión de pedidos por parte del administrador del sistema. Subsistema de gestión Programa Mendel. Agrupa todas las operaciones para el cálculo de probabilidades sobre la posible descendencia de dos diamantes de Gould con las características introducidas por el cliente. Subsistema de gestión de productos y proveedores. Agrupa todas las operaciones de gestión de productos y proveedores tales como alta, baja y modificación de productos y proveedores, gestión del stock y generación del catálogo de productos. 2.6. Especificación del Entorno Tecnológico En esta tarea se definen en detalle los distintos elementos de la infraestructura técnica que dan soporte al sistema de información, determinando la implementación concreta de los nodos y comunicaciones especificados en la tarea Definición de Niveles de Arquitectura. En la tarea de definición de los niveles de Arquitectura identificamos 3 elementos principales, cliente, servidor y servidor de base de datos. El protocolo utilizado será TCP/IP y dentro de este el protocolo HTTP que es el que se utiliza para acceder a las páginas web. En cuanto a la parte cliente es necesario una computadora con navegador de Internet, en nuestro caso nuestro sistema está optimizado para el navegador Internet Explorer 7. 87 Estructura Física del Sistema El particionamiento físico de nuestro sistema viene determinado por la estructura de desarrollo de aplicaciones modelo cliente-servidor, siendo, para este caso, un cliente ligero sobre navegador web que no engloba lógica de negocio. Así pues, el diseño lógico del sistema será en tres capas:  Ubicación de la lógica de negocio en la capa servidora que, físicamente, deberá correr sobre el servidor de la aplicación.  Capa de acceso a datos, ubicados físicamente sobre un esquema de datos relacional en el servidor de Base de Datos.  Capa cliente. Cliente ligero sobre navegador web. El servidor de aplicación mandará la información al navegador a través de la red, una vez validados los requisitos de acceso al servidor de aplicaciones. Entre otras, las ventajas de este sistema son: - Centralización y actualización constante de una única base de datos espacial y alfanumérica. - Flexibilidad ante cambios de máquinas. - Facilidad de mantenimiento en cada una de las capas. La arquitectura de tres capas consiste en la siguiente distribución con Struts: Estructura Física con Struts Nuestro sistema se desarrolla bajo el patrón MVC. Hoy en día existen múltiples herramientas que dan soporte para el desarrollo de aplicaciones web bajo el patrón MVC y la plataforma J2EE. Para el desarrollo de nuestro sistema vamos a utilizar el framework Struts. Struts es un framework open source para el desarrollo de aplicaciones MVC construidas sobre Servlets y JSP’s. Las aplicaciones web difieren de las aplicaciones convencionales en que estas pueden crear respuestas dinámicas. Muchos sitios web sólo proporcionan contenido estático mientras que las aplicaciones web interactúan con base de datos y la lógica de negocio para proporcionar una respuesta a una petición de usuario. Antes, las JavaServer Pages aglomeraban el código de acceso a base de datos, el diseño de la interfaz de usuario y el flujo de negocio dentro del mismo fichero jsp. Al introducirse el modelo vista controlador se separa cada una de estas partes en módulos independientes. El framework de Struts está diseñado para ayudar a los desarrolladores a implementar aplicaciones basadas en este modelo. Este framework provee de tres componentes clave:  Un manejador de peticiones que proporciona a la aplicación un modo de mapear peticiones a una URI estándar.  Un manejador de respuestas que proporciona un control para tratar y transferir las peticiones a otros sistemas hasta formar respuestas completas.  Unas librerías de tags que ayudan a los desarrolladores a interactuar entre los formularios de usuario y con las páginas del servidor. 88 Funcionamiento con Struts Figura 3. Funcionamiento Struts ActionServlet – La clase ActionServlet es el corazón del controlador de struts y se configura como servlet en el fichero web.xml. Cada vez que un usuario hace una petición es manejada por el ActionServlet de Struts quien intercepta la url y a través del fichero de configuración struts-config.xml dirige la petición a la clase de acción (DispathAction) correspondiente. El DispathAction es la encargada de comunicarse con el modelo. Todas las peticiones atendidas por el framework siguen un patrón en su nomeglatura (*.do). El método más importante de la clase Action es el método execute(). public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException; El método execute() lo invoca el controlador cuando se recibe una petición de un cliente. El controlador crea una instancia de la clase Action si no existe ya alguna. Solo se creara una instancia de la clase Action por cada aplicación. Se debe crear la propia implementación del método execute. ActionForm – Será el objeto que almacena el bean con los datos enviados por el usuario. HttpServletRequest – request es el objeto que proporciona los datos que se almacena durante el tiempo de vida de la petición. Es el objeto que contendrá la información que enviaremos como respuesta al browser. ActionMapping – será el objeto que almacena en memoria la entrada para el posterior mapeo en el strutsconfig.xml Struts-config.xml – Es el fichero encargado de controlar el flujo de la aplicación. En este fichero se mapean las peticiones (una acción se mapea a un determinada vista o en este caso jsp). En este fichero también se declaran los beans de formulario. DispathAction – Esta clase hereda de la clase Action de struts y es la encargada de mediar entre la vista y el modelo. 89 Vista – Struts facilita y soporta la construcción de la interfaz de la aplicación utilizando un conjunto de tags predefinidos. Busca evitar el uso de scriptlets que son trozos de código java en las jsp entre <% %> para ganar mantenibilidad y rendimiento. Figura 4. Flujo de una petición con Struts El navegador genera una petición que es atendida por el controlador. El controlador analiza la solicitud y a través del fichero de configuración struts-config.xml llama al DispathAction correspondiente pasándole los parámetros enviados. El paso de parámetros se realiza a través de los ActionForm. La clase de acción (DispathAction) instanciará y/o usará los objetos de negocio que necesite. Según el resultado que retorne el controlador devolverá el control de la interfaz a una o más jsp las cuales podrán consultar los objetos del modelo para mostrar la información. Struts y ámbito El Frameworks Struts utiliza varias áreas de recursos compartidos para almacenar objetos. Las áreas de recursos compartidos tienen una vida útil y una regla de visibilidad que definen el ámbito del recurso. Objeto HttpServletRequest Cada vez que un cliente lanza una petición HTTP, el servidor crea un objeto que implementa el interface: javax.servlet.http.HttpServletRequest. Este objeto contiene una colección de parejas atributo/valor que pueden ser usados para almacenar objetos durante el tiempo de vida de la petición. La clave para cada par es un String y el valor puede ser cualquier tipo de Object. Este objeto estará accesible desde el controlador (clase Action) para poder operar con él y generar la salida o respuesta del sistema. Los métodos para almacenar y obtener objetos en un ámbito de petición sesión son: public void setAttribute(String name, Object obj); public Object getAttribute(String name); Una vez el servidor ha atendido la petición y ha enviando la respuesta al cliente, la petición pasa a ser procesada por el garbage collected de la máquina Virtual, muriendo. Struts contiene funcionalidades para almacenar JavaBeans dentro de la petición Así pueden ser usados por componentes de presentación como páginas JSP. Estos javaBeans se almacenan en los formularios de nuestro sistema y se definen dentro del fichero de configuración struts-config.xml. Gracias a estos formularios es mucho más sencillo acceder a los datos de un JavaBeans, sin tener que ServletContext preocuparnos por limpiar o remover los objetos más tarde. Esta tarea la hará el contenedor web por nosotros. Los objetos que son almacenados en una petición no son visibles por otra petición de otro cliente. Objeto Session El siguiente nivel de visibilidad es el nivel de ámbito de sesión. El contenedor web crea un objeto que implementa el interfaz javax.servlet.http.HttpSession para identificar a un usuario a lo largo de varias peticiones. La sesión de usuario se va a mantener por un tiempo que se basa en la frecuencia en la que el usuario realiza peticiones (se puede configurar este parámetro de inactividad a través del fichero web.xml), aunque también se puede invalidar invocando al método invalidate() del objeto de sesión. En la sesión existe una colección de objetos que son almacenados basados en pares de atributo/valor, similar a los objetos de petición. La 96 1. Si el cliente no es válido o ha introducido mal los datos el sistema emitirá un mensaje de error. Escenario: Subsistema tienda virtual. 9.- Caso de uso Escribir mensaje (RF-09): Descripción: El cliente puede escribir un mensaje en el foro acerca del tema y especie de ave que desee. Objetivo: Este mensaje puede abrir un muevo hilo de conversación en el foro o responder a alguno ya existente. Este caso de uso incluye el caso de uso Identificarse y Visualizar Mensajes. Actor: Cliente. Precondiciones: El cliente debe seleccionar una categoría y una especie de ave, para posteriormente solicitar al sistema la creación del mensaje. A continuación rellenará el formulario con los datos del mensaje que quiere añadir y lo guardará en el sistema. Postconciciones: El sistema creará un nuevo mensaje almacenándolo en la base de datos y mostrando la nueva lista de mensajes actualizada. Flujo de eventos principal: 1. El cliente accede a la opción del menú correspondiente al foro tras logarse en la web (corresponde al caso de uso Identificarse). 2. El cliente elige una categoría y especie del foro. 3. El sistema muestra al cliente el listado de mensajes (hilos de conversación) para esa categoría. 4. El cliente puede iniciar un nuevo hilo de conversación en esta categoría (para ello debe pulsar el botón crear mensaje) o responder a alguno de los ya existentes (debe pinchar sobre el mensaje que desea responder). 5. El sistema muestra al cliente el formulario de creación de mensajes nuevos. 6. El cliente escribe su mensaje y pide al sistema que lo guarde. 7. El sistema guarda el mensaje y muestra al cliente el listado de mensajes actualizado (corresponde al caso de uso Visualizar mensajes). Flujo de eventos excepcional: 1. Si durante la creación del mensaje ocurriera algún error el sistema emitirá un mensaje avisando al cliente de lo ocurrido y no guardará el mensaje. Escenario: Subsistema tienda virtual. 10.- Caso de uso Visualizar mensajes (RF-10): Descripción: El cliente puede visualizar los mensajes existentes en cualquier tema del foro. Objetivo: El sistema muestra los mensajes del tema que elija el cliente. Este caso de uso incluye el caso de uso Identificarse. Actor: Cliente. Precondiciones: El cliente debe seleccionar una categoría y especie. Postconciciones: El sistema mostrará la lista de mensajes existentes (en función de la categoría que haya elegido). Flujo de eventos principal: 2. El cliente accede a la opción del menú correspondiente al foro tras logarse en la web (corresponde al caso de uso Identificarse). 3. El cliente elige una categoría y especie del foro. 4. El sistema muestra al cliente todos los mensajes existentes para esa categoría. Escenario: Subsistema tienda virtual. 11.- Caso de uso Visualizar mensaje: Descripción: El cliente puede visualizar el mensaje que desee de cualquier tema del foro. Objetivo: El sistema visualiza el contenido del mensaje que el cliente haya escogido. Este caso de uso es una extensión del caso de uso Visualizar mensajes. Actor: Cliente. Precondiciones: El cliente debe seleccionar una categoría y especie para posteriormente escoger uno de los mensajes del listado. Postconciciones: El sistema muestra el contenido del mensaje elegido. Flujo de eventos principal: 1. El cliente accede a la opción del menú correspondiente al foro tras logarse en la web (corresponde al caso de uso Identificarse). 2. El cliente elige una categoría y especie. 3. El sistema muestra al cliente el listado de mensajes para esa categoría. 4. El cliente elige el mensaje que quiera consultar. 5. El sistema muestra al cliente la información para ese mensaje. Escenario: Subsistema tienda virtual. 97 12.- Caso de uso Eliminar mensaje (RF-11): Descripción: Un administrador del sistema tiene la posibilidad de borrar cualquier mensaje que considere. Objetivo: Eliminar del foro los mensajes que no se consideren aptos para el hilo del foro en el que se encuentren. Actor: Administrador. Precondiciones: El administrador elegirá una categoría y especie para posteriormente escoger los mensajes del listado que vaya a eliminar. Postconciciones: El sistema muestra la lista de mensajes actualizada. Flujo de eventos principal: 1. El administrador accede a la opción del menú correspondiente al foro tras logarse en la web (corresponde al caso de uso Identificarse). 2. El administrador elige una categoría y especie. 3. El sistema muestra el listado de mensajes para esa categoría (corresponde al caso de uso Visualizar mensajes). 4. El administrador elige los mensajes que quiera borrar del foro. 5. El sistema muestra de nuevo el listado de mensajes actualizado. Flujo de eventos excepcional: 1. El sistema mostrará un mensaje de error en caso de que se haya producido algún error al eliminar el mensaje del foro. Escenario: Subsistema tienda virtual. 13.- Caso de uso Gestión centros (RF-12): Descripción: Un administrador realizará todas las labores relacionadas con la gestión y mantenimiento de los centros que la empresa tiene abiertos. Objetivo: Realizar el mantenimiento de todos los centros. Actor: Administrador. Precondiciones: El administrador debe acceder a la pantalla de gestión de centros. Postconciciones: El sistema actualizará en base de datos las modificaciones que el administrador realice tanto en los centros ya existentes como la creación de nuevos centros. Flujo de eventos principal: 1. El administrador accede a la opción del menú correspondiente a la gestión de centros, tras logarse en la web (corresponde al caso de uso Identificarse). 2. El administrador puede realizar las siguientes acciones: - Modificación de los datos de contacto de cualquier centro dado de alta en el sistema. - Eliminación de un centro. Cuando cualquier tienda se cierre se deberá dar de baja en el sistema. - Anadir un nuevo centro, cuando se abra una tienda en cualquier provincia. 3. El sistema actualizará la base de datos con la información requerida por el administrador y mostrará un mensaje de éxito en caso de que el proceso haya sido satisfactorio. Flujo de eventos excepcional: 1. El sistema mostrará un mensaje de error en caso de que se produzca un error en modificar/borrar o añadir información en la base de datos. Escenario: Subsistema tienda virtual. 14.- Caso de uso Búsqueda centros (RF-13): Descripción: El administrador tiene la posibilidad de realizar búsquedas de centros en el sistema. Objetivo: Acceder de forma rápida a los centros que el administrador quiere gestionar. Este caso de uso extiende el caso de uso Gestión centros. Actor: Administrador. Precondiciones: El administrador debe acceder a la pantalla de gestión de centros y rellenar algún filtro de búsqueda como el código de centro y/o provincia en caso de que el usuario lo necesite. Postconciciones: El sistema muestra la lista de centros que cumple con los filtros de búsqueda. Flujo de eventos principal: 1. El administrador rellena los filtros de búsqueda que considere (en caso de que lo desee) y pulsa en el botón de buscar. 2. El sistema muestra el listado de centros que cumplen con los requisitos de búsqueda iniciales. Flujo de eventos excepcional: 1. Si los parámetros de búsqueda introducidos por el usuario no son correctos el sistema debe de generar un mensaje informando del error al usuario. Escenario: Subsistema tienda virtual. 98 15.- Caso de uso Visualizar gráficos (RF-14): Descripción: Un administrador tiene la posibilidad de obtener graficas de los resultados de las ventas de los productos de la empresa o las ventas realizadas por cada una de las tiendas. Objetivo: Realizar el mantenimiento de todos los centros. Actor: Administrador. Precondiciones: El administrador debe acceder a la pantalla de visualización de gráficos. Postconciciones: Ninguna. Flujo de eventos principal: 1. El administrador accede a la opción del menú correspondiente a la visualización de gráficos, tras logarse en la web (corresponde al caso de uso Identificarse). 2. El sistema muestra el formulario de gráficos para que el administrador rellene los datos de búsqueda que requiera según la información que necesite. Escenario: Subsistema tienda virtual. 16.- Caso de uso Rellenar filtros búsqueda (RF-15): Descripción: El administrador puede rellenar filtros de búsqueda. Objetivo: Mostrar gráficos con la información que el administrador necesite en cada momento. Este caso de uso extiende el caso de uso Visualizar gráficos. Actor: Administrador. Precondiciones: El administrador debe acceder a la pantalla de visualización de gráficos e introducir algún filtro de búsqueda como familia de productos, tienda, o fechas. Postconciciones: El sistema muestra el gráfico acorde a la información solicitada por el usuario. Flujo de eventos principal: 1. El administrador rellenará los filtros de búsqueda que considere y pulsa en el botón de visualizar producto o visualizar tienda. 2. El sistema muestra el gráfico con la información. Flujo de eventos excepcional: 1. Si los parámetros de búsqueda introducidos por el usuario no son correctos el sistema debe de generar un mensaje informando del error al usuario. Escenario: Subsistema tienda virtual. 4.2.- Diagrama casos de uso gestión del programa Mendel Figura7. Diagrama casos de uso Gestión del Programa Mendel CASOS DE USO DEL SUBSISTEMA GESTION DEL PROGRAMA MENDEL 1.- Caso de uso Comprobar herencia genética (RF-16): Descripción: La aplicación muestra un formulario que le permite al cliente introducir los datos de los pájaros macho y hembra de los cuales se quiere comprobar la posible descendencia genética que tendrían. Objetivo: Este módulo permite al cliente calcular la herencia genética de los diamantes de gould a partir de los 99 fenotipos que el cliente elija para cada progenitor. Este caso de uso de uso incluye el caso de uso Identificarse y Visualizar resultados. Actor: Cliente logado en la web de la aplicación. Precondiciones: El cliente debe ser un usuario válido, rellenar el formulario con los fenotipos de los progenitores y solicitar al sistema que calcule la descendencia con esos datos. Postcondiciones: El sistema calculará y mostrará la posible descendencia a partir de los datos proporcionados por el cliente. Flujo de eventos principal: 1. El cliente accede a la opción del menú correspondiente al Programa Mendel tras logarse en la web (corresponde al caso de uso Identificarse). 2. El cliente introduce los fenotipos del macho y la hembra. 3. El sistema validará que los fenotipos introducidos por el usuario son válidos y calculará la posible descendencia. Flujo de eventos excepcional: 1. Si el sistema detecta algún error durante el proceso de cálculo de la descendencia mostrará un mensaje indicándolo y volverá a la página principal del programa Mendel. Escenario: Subsistema gestión del programa Mendel. 2.- Caso de uso Visualizar resultados (RF-17): Descripción: Muestra los fenotipos de las crías. Objetivo: Permite al cliente visualizar los resultados tras el cálculo de la descendencia. Actor: Cliente. Precondiciones: Haber realizado el cálculo genético a partir de los fenotipos de los padres. Postconciciones: Ninguna. Flujo de eventos principal: 1. Tras haber realizado el cálculo de probabilidades de descendencia genética, el sistema visualizará la información en forma de listados para las distintas partes del cuerpo del pájaro (cabeza, pecho, cuerpo), y además se incluirá una tabla con todos los datos calculados. Escenario: Subsistema gestión del programa Mendel. 3.- Caso de uso Mostrar imágenes descendencia (RF-18): Descripción: Visualización de las crías mediante imágenes. Objetivo: Permite al cliente visualizar las imágenes de las posibles crías obtenidas tras el cálculo de la descendencia. Este caso de uso es una extensión del caso de uso Visualizar resultados. Actor: Cliente. Precondiciones: El cliente debe elegir la cría que desee visualizar. Postconciciones: El sistema abrirá una pantalla nueva con la imagen y los datos de la cría que se ha escogido. Flujo de eventos principal: 1. El cliente selecciona del listado de resultados la cría que desea visualizar. 2. El sistema busca la imagen y la muestra en una nueva pantalla junto con los datos genéticos y sexo de la cría que el cliente ha escogido. Flujo de eventos excepcional: 1. Si el sistema detecta algún error al cargar las imágenes, emitirá un mensaje advirtiendo de ello al cliente y volverá a la pantalla de resultados. Escenario: Subsistema gestión del programa Mendel. 100 4.3.- Diagrama casos de uso gestión de usuario Figura8. Diagrama casos de uso Gestión Usuarios CASOS DE USO DEL SUBSISTEMA GESTION DE USUARIOS 1.- Caso de uso Registrarse: Descripción: Cualquier usuario que acceda a la web de la pajarería puede registrarse rellenando un formulario de alta con sus datos personales. Objetivo: Una vez que el usuario se identifique en la web, podrá acceder a funcionalidades exclusivas de los usuarios registrados en la aplicación. Este caso de uso incluye el caso de uso Consultar disponibilidad, es decir cuando un usuario rellena el formulario de alta, el sistema comprueba que el login que ha escogido el usuario no está asociado a otro cliente ya guardado en el sistema. Actor: Usuario no registrado. Precondiciones: Seleccionar el enlace que accede al formulario para registrarse en el sistema. Postconciciones: Se da de alta al usuario en la web de la pajarería. Flujo de eventos principal: 1. El usuario accede a la web de la aplicación. 2. El sistema accede y muestra un menú lateral que contendrá todos los servicios a los que tiene acceso cualquier usuario. 3. El usuario solicita el acceso al registro en la aplicación. 4. El sistema accede, y muestra el formulario que el usuario deberá rellenar para darse de alta en la web. 5. El usuario rellenará el formulario de alta. 6. El sistema recoge el formulario rellenado y guarda la información en la base de datos. A partir de ese momento el usuario pasará a ser un cliente de la aplicación y por tanto podrá acceder a la funcionalidad asociada a este perfil. Flujo de eventos excepcional: 1. Si algún campo del formulario no se ha rellenado correctamente el sistema impedirá el alta y mostrará al usuario un mensaje de error indicándolo. 2. En caso de que se produzca un error al tratar de guardar los datos del usuario, el sistema también mostrará un mensaje de error indicándolo. Escenario: Subsistema gestión Usuarios. 2.- Caso de uso Consultar disponibilidad (RF-19): Descripción: Un usuario puede modificar sus datos de identificación en el sistema para lo cual puede comprobar si el “login” que desea está disponible. Objetivo: Permite al cliente asegurarse de que el login que desea no está siendo usado por cualquier otro cliente de la web. Este caso de uso extiende el caso de uso Actualizar datos cliente. 101 Actor: Cliente. Precondiciones: El cliente debe introducir un login. Postconciciones: El sistema verificará que el login no esté siendo usado por otro cliente mostrando un mensaje con el resultado de la consulta. Flujo de eventos principal: 1. El cliente accede a la opción del menú correspondiente a la Gestión de datos de Usuario tras logarse en la web (corresponde al caso de uso Identificarse). 2. El sistema muestra el formulario de modificación de los datos de usuario. 3. El cliente introduce un nuevo login y consulta su disponibilidad en el sistema al pichar el botón de comprobar disponibilidad. 4. El sistema comprueba que ese nuevo login introducido por el cliente no esté siendo utilizado por otro usuario del sistema. En caso de estar disponible, mostrará un mensaje al cliente advirtiéndole de esto. Flujo de eventos excepcional: 1. Si el nuevo login elegido por el usuario no está disponible, el sistema emitirá un mensaje alertando al cliente de esto y pidiéndole la introducción de uno nuevo. Escenario: Subsistema gestión Usuarios. 3.- Caso de uso Actualizar datos cliente (RF-20): Descripción: Un usuario puede modificar sus datos de identificación en el sistema para lo cual puede comprobar si el “login” que desea está disponible. Objetivo: Permite al cliente modificar sus datos personales. Este caso de uso incluye el caso de uso Identificarse. Actor: Cliente. Precondiciones: El cliente debe modificar los datos del formulario que desee y solicitar al sistema que los guarde. Postconciciones: El sistema actualiza la información en base de datos mostrando un mensaje de éxito de la operación. Flujo de eventos principal: 1. El cliente accede a la opción del menú correspondiente a la Gestión de datos de Usuario tras logarse en la web (corresponde al caso de uso Identificarse). 2. El sistema muestra el formulario de modificación de los datos de usuario. 3. El cliente puede consultar, modificar o borrar (darse de baja) sus datos de usuario en el sistema. 4. En caso de que el cliente solicite al sistema guardar modificaciones sobre sus datos de usuario, éste validará que los nuevos datos introducidos por el cliente son correctos y en caso de serlo los guardará en el sistema. 5. En caso de que lo que quiera el cliente sea darse de baja, el sistema pide confirmación por parte del cliente para continuar con el proceso de baja. Si el cliente confirma su decisión, el sistema eliminará sus datos de alta y toda la información referente a él. A continuación la aplicación mostrará al cliente el menú de usuario ya que no está ya dado de alta en el sistema. Flujo de eventos excepcional: 1. Si el cliente tiene pedidos pendientes, el sistema emitirá un mensaje advirtiendo de esto e impedirá que el cliente pueda darse de baja en la web. 2. En caso de que se produzca algún fallo al actualizar la información en la base de datos se mostrará un mensaje de error y no se guardarán las modificaciones. Escenario: Subsistema gestión Usuarios. 4.- Caso de uso Consultar cliente (RF-21): Descripción: Cualquier usuario con privilegios de administrador puede ver los clientes que han realizado algún pedido a través de la web de la pajarería. Objetivo: Identificar a los clientes actuales (entendiendo como cliente aquel usuario identificado en el sistema que ha realizado como mínimo un pedido). Este caso de uso incluye el caso de uso Identificarse. Actor: Administrador. Precondición: El administrador debe realizar una búsqueda y seleccionar un cliente con uno de sus pedidos del listado mostrado tras realizar dicha búsqueda. Postcondición: El sistema muestra una pantalla con un formulario con los datos de alta del usuario y el estado del pedido que se ha seleccionado. Flujo de eventos principal: 1. El cliente accede a la opción del menú correspondiente a la Gestión de Clientes tras logarse en la web (corresponde al caso de uso Identificarse). 2. El sistema muestra el formulario de búsqueda de clientes. 3. Tras realizar una búsqueda, el administrador elige uno de los clientes con un pedido que ha realizado. 4. El sistema muestra un formulario con los datos de contacto del usuario y el estado del pedido seleccionado. 5. El administrador tiene la posibilidad de modificar el estado de este pedido. 102 Flujo de eventos excepcional: 1. Si ocurriera algún error durante la actualización del estado del pedido del cliente se emitirá un mensaje advirtiendo de ello al administrador Escenario: Subsistema gestión Usuarios. 5.- Caso de uso Buscar cliente (RF-22): Descripción: Poder encontrar clientes de la pajarería de manera fácil y rápida, mostrando únicamente aquellos que le interesan al administrador según sus necesidades. Objetivo: Permite al administrador realizar búsquedas de clientes a partir de los parámetros de búsqueda introducidos. Este caso de uso es una extensión del caso de uso Consultar cliente. Actor: Administrador. Precondición: Introducir los filtros de búsqueda en caso de que los requiera el administrador. Postcondición: El sistema muestra un listado con los clientes y sus pedidos, que se ajustan a los parámetros de búsqueda introducidos. Flujo de eventos principal: 1. El administrador rellena los filtros de búsqueda que considere (en caso de que lo desee) y pulsa en el botón de buscar. 2. El sistema muestra el listado con los clientes que cumplen con los requisitos de búsqueda iniciales. Flujo de eventos excepcional: 1. Si ocurriera algún error durante el proceso de búsqueda se emitirá un mensaje advirtiendo de ello al administrador. 2. Si la búsqueda no produce resultados se emitirá un mensaje advirtiéndolo. 3. Si los parámetros de búsqueda introducidos por el usuario no son correctos el sistema debe de generará un mensaje informando del error al usuario. Escenario: Subsistema gestión Usuarios. 6.- Caso de uso Baja cliente (RF-23): Descripción: Un administrador puede eliminar los clientes que quiera del sistema. Objetivo: Eliminar los clientes que el administrador considere. Este caso de uso es una extensión del caso de uso Consultar cliente. Este caso de uso incluye el caso de uso Eliminar pedidos cliente. Actor: Administrador. Precondición: Tras realizar una búsqueda de clientes, el administrador debe seleccionar aquel que desea dar de baja. Postcondición: El sistema eliminará al cliente de la base de datos. Flujo de eventos principal: 1. El administrador elegirá un cliente de la lista obtenida tras realizar una búsqueda de clientes (corresponde al caso de uso buscar cliente). 2. El sistema muestra los datos asociados a ese cliente. 3. El administrador pincha el botón dar de baja a ese cliente. 4. El sistema pide confirmación por parte del administrador 5. El administrador confirma la operación. 6. El sistema elimina al cliente de la base de datos y toda la información relacionada con él Flujo de eventos alternativo: 1. Si el administrador cancela la operación de baja de un cliente el sistema no lo eliminará. Flujo de eventos excepcional: 1. Si ocurriera algún error durante el proceso de baja de clientes se emitirá un mensaje advirtiendo de ello al administrador. Escenario: Subsistema gestión Usuarios. 7.- Caso de uso Eliminar pedidos cliente (RF-24): Descripción: Cuando se elimine un cliente del sistema también se borrará toda la información asociada a él, como por ejemplo los pedidos que ha realizado. Objetivo: Eliminar por completo el rastro del cliente que se ha eliminado. Actor: Administrador. Precondición: El administrador debe borrar un cliente. Postcondición: El sistema eliminará de la base de datos los pedidos que haya realizado el cliente que se esté borrando. Flujo de eventos principal: 1. Tras seleccionar un cliente y pulsar el botón dar de baja, se borrarán todos los pedidos que ese cliente ha realizado. Flujo de eventos excepcional: 103 1. Si ocurriera algún error durante la eliminación de la información del sistema se emitirá un mensaje de error y no se borrará la información. Escenario: Subsistema gestión Usuarios. 4.4.- Diagrama casos de uso gestión de productos y proveedores Figura9. Diagrama casos de uso Gestión Productos y Proveedores CASOS DE USO DEL SUBSISTEMA GESTION DE PRODUCTOS Y PROVEEDORES 1.- Caso de uso Consultar catalogo de productos (RF-25): Descripción: Cualquier usuario de la aplicación puede consultar el catálogo de productos que se venden en la empresa. Objetivo: Permite al usuario conocer los productos que se venden. Así podrá saber si el producto que busca está disponible en ese momento o no queda stock. De cada producto se mostrará su código, nombre, precio unitario y stock. Actor: Usuario; no necesita ningún privilegio especial para poder acceder al catálogo de productos. Precondiciones: Realizar una búsqueda de productos. Postconciciones: Se muestra el listado para la consulta de productos de la tienda con su código, nombre, precio unitario y stock. Flujo de eventos principal: 1. El usuario accede a la web de la aplicación. 104 2. El sistema accede y muestra un menú lateral que contendrá todos los servicios a los que tiene acceso cualquier usuario. 3. El usuario solicita el acceso al catálogo de productos. 4. El sistema accede, y muestra el formulario de búsqueda. 5. El usuario realiza la búsqueda. 6. El sistema recoge la información y muestra un listado de productos de acuerdo con los parámetros de búsqueda que ha introducido el usuario. Escenario: Subsistema gestión Productos y Proveedores. 2.- Caso de uso Búsqueda producto (RF-26): Descripción: El usuario puede buscar un producto concreto mediante su código (en caso de que lo conozca), o bien pulsando la lupa que abrirá un “popup” donde podrá seleccionar un producto del listado. Objetivo: Encontrar de manera rápida el producto que se quiere consultar. Este caso de uso es una extensión del caso de uso Consultar catálogo de productos. Actor: Usuario. Precondiciones: Pulsar la lupa de producto para realizar la búsqueda o introducir un código de producto que exista en base de datos. Postconciciones: El producto con sus características se cargará en el listado del catálogo de productos. Flujo de eventos principal: 1. El administrador rellena los filtros de búsqueda que considere (en caso de que lo desee) y pulsa en el botón de buscar. El sistema permite al usuario buscar un producto por código o familia o nombre (en la lupa). 2. Una vez realizada la búsqueda por parte del usuario el sistema visualizará el listado de productos que se ajusten a los filtros de búsqueda. Flujo de eventos excepcional: 1. Si los parámetros de búsqueda suministrados por el usuario no son correctos el sistema debe de generar un mensaje informando del error al usuario. 2. Si ocurriera algún error durante el proceso de búsqueda se emitirá un mensaje advirtiendo de ello al administrador. 3. Si la búsqueda no produce resultados se emitirá un mensaje advirtiéndolo. Escenario: Subsistema gestión Productos y Proveedores. 3.- Caso de uso Modificar/Eliminar/Añadir producto (RF-27): Descripción: El administrador puede modificar los datos de cualquier producto del catálogo y ampliar o reducir dicho catalogo dando de alta o baja los productos que quiera. Objetivo: Modificar el catálogo del productos de la empresa para adecuarlo a sus necesidades en cada momento. Este caso de uso incluye el caso de uso Consultar catálogo de productos e Identificarse. Actor: Administrador. Precondición: El administrador debe acceder a la opción de gestión de productos. Postcondición: El sistema actualizara la información que solicite al administrador en base de datos. Flujo de eventos principal: 1. El administrador accede a la opción del menú correspondiente a la Gestión de Productos tras logarse en la web (corresponde al caso de uso Identificarse). 2. El sistema muestra el formulario de gestión de productos. 3. El administrador puede solicitar al sistema añadir nuevos productos (realizar pedido a un proveedor), eliminar alguno de los existentes o modificar los datos de los productos del catálogo. 4. En caso de que el administrador solicite el alta de un producto, debe introducir los datos del proveedor al cual va a realizar el pedido del producto y el producto que desea solicitar. El sistema guardará los datos del nuevo producto en el catálogo. 5. Cuando el administrador desee borrar o modificar algún producto, antes debe realizar una búsqueda de productos. Del listado obtenido el administrador puede seleccionar los productos que desee a la vez y eliminarlos del sistema. Si lo que quiere esa modificar las características de alguno de los productos bastará con que pinche sobre su nombre. Entonces la aplicación mostrará un formulario con los datos del producto para que el administrador modifique el que quiera. A continuación el administrador solicitará al sistema que guarde los cambios realizados. Flujo de eventos excepcional: 1. Si ocurriera algún problema durante el proceso de actualización de la información en la base de datos, el sistema mostrará un mensaje de error advirtiendo de ello al usuario. 2. Si el administrador intentara hacer un pedido del un producto que no suministrara el proveedor que ha escogido, el sistema mostrará un mensaje de aviso e impedirá continuar con el alta del producto. Escenario: Subsistema gestión Productos y Proveedores. 105 4.- Caso de uso Gestionar oferta catálogo (RF-28): Descripción: La empresa dispondrá de una serie de productos ofertados durante un determinado período de tiempo que servirán de reclamo publicitario. Objetivo: El objetivo del catalogo de ofertas es generar un folleto virtual en el que se muestren una serie de productos a precios más bajos de los habituales en un periodo de tiempo determinado. El administrador puede gestionar el catalogo de ofertas realizando para ello operaciones como alta de nuevas ofertas, eliminar ofertas antiguas o descatalogadas o por ultimo modificar el precio de ofertas ya existentes en el catalogo. Una oferta podrá localizarse por el nombre del producto ofertado. Este caso de uso incluye el caso de uso Consultar catálogo de productos e Identificarse. Actor: Administrador. Precondición: El administrador debe acceder a la opción de generar catálogo. En caso de que se quiera modificar o eliminar ofertas, el catálogo debe disponer de al menos una oferta para que el administrador pueda seleccionarla. Postcondición: El sistema actualizará la información el catalogo de ofertas. Flujo de eventos principal: 1. El administrador accede a la opción del menú correspondiente a Generar catálogo tras logarse en la web (corresponde al caso de uso Identificarse). 2. El sistema muestra un listado con todos los productos ofertados por la empresa en ese momento. 3. El administrador puede solicitar al sistema el alta, modificación o borrado de ofertas del catálogo. 4. En caso de que lo que se solicite añadir una nueva oferta el administrador debe seleccionar el botón de añadir oferta. A continuación el sistema mostrará el formulario de alta de una oferta en el que el administrador deberá escoger el producto que desea ofertar y el precio al cual se va a vender. Posteriormente el sistema guardará la oferta en la base de datos y mostrará el listado con todas las ofertas actualizado. 5. Cuando el administrador quiera dar de baja ofertas del catálogo, debe seleccionar aquellas ofertas que vaya a dar de baja. Entonces el sistema borrará las ofertas de la base de datos y mostrará de nuevo el listado de ofertas actualizado. 6. Por último en caso de que el administrador quiera modificar una oferta, deberá seleccionar una del listado y solicita al sistema su modificación. El sistema mostrará un formulario rellenado con los datos de la oferta. El administrador podrá modificar el precio del producto. Entonces el sistema actualizará el precio mostrando de nuevo el listado de ofertas actualizado. Flujo de eventos excepcional: 1. En caso de que se está añadiendo la oferta de un producto ya existente en el catalogo de ofertas, la aplicación mostrará un mensaje de advertencia e impedirá que se guarde en el sistema la oferta. 2. En caso de que algún campo del formulario de ofertas (tanto el de alta como el de modificación) sea incorrecto, el sistema también generará un mensaje de error. 3. Si ocurriera algún problema durante el proceso de actualización de la información en la base de datos, el sistema mostrará un mensaje de error advirtiendo de ello al usuario. Escenario: Subsistema gestión Productos y Proveedores. 5.- Caso de uso Comprobar stock (RF-29): Descripción: El administrador podrá consultar la cantidad que dispone de cada producto. Objetivo: El administrador puede consultar en cualquier momento la cantidad de cada producto que hay disponible en el almacén o en tiendas concretas. También puede realizar búsquedas de productos para conocer únicamente las unidades de un producto determinado en una tienda o en el almacén. Este caso de uso incluye el caso de uso Consultar catálogo de productos e Identificarse. Actor: Administrador. Precondición: Realizar búsquedas de productos por productos o tiendas correctos y que produzcan resultados. Postcondición: Se mostrará un listado con el stock de los productos buscados (en función de los filtros de búsqueda introducidos) mostrando para cada uno de ellos su código, nombre y stock. Flujo de eventos principal: 1. El administrador accede a la opción del menú correspondiente a Consulta de Stock tras logarse en la web (corresponde al caso de uso Identificarse). 2. El sistema accede y muestra el formulario de consulta de stock. 3. El administrador podrá rellenar los filtros de búsqueda que necesite (tienda y/ producto) en función de los datos que desee consultar. 4. El sistema recoge los filtros de búsqueda introducidos por el administrador y devuelve un listado de productos con su código, nombre y número de unidades disponible. Flujo de eventos excepcional: 1. El sistema mostrará un mensaje de error en caso de que los filtros de búsqueda sean incorrectos. 2. Si los filtros de búsqueda no producen ningún resultado, el sistema mostrará un mensaje de error indicándolo. 112 totales de cada producto y el coste total del pedido incluyendo además los gastos de envío. Flujo de eventos excepcional: 1. Si el sistema detecta algún problema durante el cálculo del importe del pedido, mostrará un mensaje de error y anulará el pedido. Escenario: Subsistema Compra on-line. 8.- Caso de uso Realizar compra (RF-44): Descripción: Un cliente o administrador puede realizar un pedido a través de la web de la pajarería. Objetivo: En caso de que el pedido lo realice un cliente su finalidad es la de adquirir un producto que ofrezca la empresa. Si por el contrario el pedido lo realiza un administrador su objetivo es abastecer a la empresa de los productos que necesite (en este caso el pedido se realiza a través de la web pero a proveedores asociados a la empresa). Este caso de uso incluye los casos de uso Identificarse, Consultar catálogo de productos, Rellenar formulario de entrega, Forma de pago y Visualizar/modificar carrito. Actor: Cliente/Administrador. Precondición: El usuario debe haber seleccionado la opción que le permitirá realizar un pedido a través de web. Postcondición: El sistema almacena la información asociada al pedido realizado por el usuario. Flujo de eventos principal: 1. El administrador accede a la opción del menú correspondiente a Pedidos (si el pedido lo está realizando un cliente a la empresa) o Gestión de productos (si el pedido lo está realizando un administrador a un proveedor), tras logarse en la web (corresponde al caso de uso Identificarse). 2. El sistema inicia el proceso de gestión de pedidos creando un pedido vacio y con estado iniciado. 3. Una vez finalizado todo el proceso de compra correctamente (rellenar el carrito de la compra, completar formulario de entrega y forma de pago), el sistema muestra un resumen del pedido con los datos de la factura, del envío y un mensaje del éxito de la operación. En ese momento el estado del pedido pasa a pendiente de cobro. Flujo de eventos excepcional: 1. Si el sistema detecta alguna anomalía en el proceso mostrará un mensaje de error y anulará el pedido. Escenario: Subsistema Compra on-line. 9.- Caso de uso Consultar pedidos (RF-45): Descripción: Esta opción está disponible únicamente para administradores del sistema, los cuales podrán conocer el estado de un pedido realizado por un cliente y los productos que se han adquirido en cualquier pedido tanto lo realizados a la empresa como los que la empresa ha realizado a cualquier proveedor. Objetivo: Conocer en detalle información de cualquier pedido como puede ser la fecha en la que se ha realizado, el proveedor al cual se le ha realizado el pedido (en caso de que el pedido se haya realizado a un proveedor) o cliente que ha realizado el pedido (en caso de que sea el cliente el que esté realizando un pedido a través de la web), importe, y productos adquiridos. Este caso de uso incluye el caso de uso Identificarse. Actor: Administrador. Precondición: Deben realizarse búsquedas de pedidos que produzcan resultados. Postcondición: El sistema muestra el detalle del pedido que quiera el administrador. Flujo de eventos principal: 1. El administrador accede a la opción del menú correspondiente a la Gestión de Pedidos tras logarse en la web (corresponde al caso de uso Identificarse). 2. El sistema muestra dos opciones para que el administrador elija el tipo de pedidos que quiera consultar o pedidos a clientes o pedidos a proveedores. 3. En cualquiera de los dos casos el administrador deberá realizar una búsqueda de pedidos (corresponde al caso de uso Búsqueda pedidos) para lo cual puede rellenar algún filtro de búsqueda que quiera. En caso de búsquedas de pedidos a proveedores los filtros que puede rellenar son el código de pedido, proveedor, tipo de producto, fecha de inicio y fecha de fin del pedido. Si se trata de búsquedas de pedidos a clientes los filtros de búsqueda a rellenar son código del pedido, estado, cliente, tipo de producto, fecha de inicio y fecha de fin. 4. Tras realizar la búsqueda el sistema mostrará el listado de pedidos que se ajuste a los filtros de búsqueda. 5. En caso de que la búsqueda sea de pedidos realizados por clientes, el administrador podrá elegir el pedido que desee. Entonces el sistema muestra una pantalla con toda la información asociada al pedido como son datos del pedido, datos de envío y datos bancarios. Flujo de eventos excepcional: 1. Si el sistema detecta alguna anomalía durante el proceso de búsqueda, mostrará un mensaje de error y no devolverá registros. Escenario: Subsistema Compra on-line. 113 10.- Caso de uso Modificar estado pedido cliente (RF-46): Descripción: Un administrador de la web debe actualizar el estado de los pedidos realizados por los clientes. Objetivo: Actualizar el estado del pedido al momento que corresponda. Los estados posibles son pendiente de envío (estado inicial al finalizar un pedido), pagado, entregado y realizado (cuando se ha completado todo el ciclo del pedido). Actor: Administrador. Precondición: El usuario debe haber elegido un pedido. Postcondición: El sistema actualizará el estado del pedido que ha modificado. Flujo de eventos principal: 1. El administrador accede a la opción del menú correspondiente a Gestión de clientes, tras logarse en la web (corresponde al caso de uso Identificarse). 2. A continuación el administrador deberá realizar una búsqueda de pedidos de clientes (corresponde al caso de uso Búsqueda pedidos) para lo cual puede rellenar algún filtro de búsqueda que quiera. 3. El sistema muestra los pedidos que se ajusten a los filtros de búsqueda. El administrador elige un pedido del listado. 4. El sistema muestra los datos del cliente que ha realizado ese pedido y el estado del pedido. 5. El administrador actualizará el estado del pedido que ha escogido para adecuarlo a su nueva situación. Flujo de eventos excepcional: 1. Si se produce algún fallo durante el proceso de actualización del estado del pedido en el sistema la aplicación arrojará un mensaje de error. Escenario: Subsistema Compra on-line. 11.- Caso de uso Búsqueda pedidos (RF-47): Descripción: El sistema permite a cualquier administrador realizar búsquedas de pedidos. Objetivo: Localizar de manera rápida los pedidos que necesita consultar o gestionar. Actor: Administrador. Precondiciones: Rellenar el formulario de búsqueda en caso de que el administrador lo necesite (los filtros de búsqueda introducidos deben ser válidos) y pinchar el botón de buscar. Postcondición: El sistema mostrará un listado con los pedidos que se ajustan a los parámetros de búsqueda introducidos en el formulario. Flujo de eventos principal: 1. El administrador rellena los filtros de búsqueda que quiera y solicita al sistema que realice la búsqueda a partir de los parámetros introducidos en la etapa anterior. 2. El sistema realiza la búsqueda y muestra los resultados en forma de listado por pantalla. Flujo de eventos excepcional: 1. El sistema mostrará un mensaje de error en caso de que los filtros de búsqueda sean incorrectos. 2. Si los filtros de búsqueda no producen ningún resultado, el sistema indicará al administrador que la búsqueda no ha producido ningún resultado. Escenario: Subsistema Compra on-line. 114 5. Matriz de Rastreabilidad La matriz de rastreabilidad es una herramienta que es usa para saber qué requisitos de una aplicación han sido probados y cubiertos en cada test de pruebas diseñado. Es decir, relaciona los requisitos del sistema con objetivos de prueba. No puede haber objetivos que queden sin reflejar en los casos de uso. En el caso de nuestra aplicación web, se definieron anteriormente todos los requisitos que hemos identificado en el sistema que recopilamos a continuación: REQUISITO DE INFORMACION Datos de Usuario RI-01 Datos de Producto RI-02 Datos de Pedido RI-03 Datos de Venta/Factura RI-04 Datos de Proveedor RI-05 Datos del foro RI-06 REQUISITOS NO FUNCIONALES Interfaz de Usuario RNF-01 Interfaz Hardware y Rendimiento RNF-02 Interfaz Software RNF-03 Seguridad RNF-04 REQUISITOS FUNCIONALES Consultar información RF-01 Mostrar características RF-02 Selección especie RF-03 Ponerse en contacto RF-04 Enviar pregunta RF-05 Consulta de centros RF-06 Selección provincia RF-07 Identificarse (Login) RF-08 Escribir mensaje RF-09 Visualizar mensaje/s RF-10 Eliminar mensaje RF-11 Gestión centros RF-12 Búsqueda centros RF-13 Visualizar gráficos RF-14 115 Rellenar filtros búsqueda RF-15 Comprobar herencia genética RF-16 Visualizar resultados RF-17 Mostrar imágenes descendencia RF-18 Consultar disponibilidad RF-19 Actualizar datos cliente RF-20 Consultar cliente RF-21 Buscar cliente RF-22 Baja cliente RF-23 Eliminar pedidos cliente RF-24 Consultar catálogo de productos RF-25 Búsqueda producto RF-26 Modificar/Eliminar/Añadir producto RF-27 Gestionar oferta catálogo RF-28 Comprobar stock RF-29 Elegir centro RF-30 Actualizar/añadir proveedor RF-31 Consultar catálogo proveedor RF-32 Realizar pedido proveedor RF-33 Consultar proveedor RF-34 Búsqueda proveedor RF-35 Eliminar proveedor RF-36 Eliminar catálogo proveedor RF-37 Añadir producto al carrito RF-38 Rellenar formulario de entrega RF-39 Forma de pago RF-40 Generar factura RF-41 Visualizar/modificar carrito RF-42 Calcular importe RF-43 Realizar compra RF-44 Consultar pedidos RF-45 Modificar estado pedido cliente RF-46 Búsqueda pedidos RF-47 Figura 10. Requisitos del sistema 116 Además definiremos nuestros objetivos o casos de prueba que deberá pasar nuestro sistema. Estos son: Figura 11. Objetivos del sistema Por tanto nuestra matriz de rastreabilidad quedará definida de la siguiente manera: OBJ-01 OBJ-02 OBJ-03 OBJ-04 OBJ-05 OBJ-06 OBJ-07 OBJ-08 OBJ-09 OBJ-10 RI-01 X X X RI-02 X X X X RI-03 X X X RI-04 X X X X RI-05 X X X RI-06 X X X RNF-01 X X X X X X X X RNF-02 X RNF-03 X RNF-04 X X RF-01 X RF-02 X RF-03 X RF-04 X X RF-05 X X OBJETIVOS Gestión de usuarios OBJ-01 Gestión de centros OBJ-02 Gestión del foro OBJ-03 Gestión de productos OBJ-04 Gestión de proveedores OBJ-05 Gestión de ventas OBJ-06 Gestión de pedidos OBJ-07 Gestión de información de negocio OBJ-08 Gestión de la capacidad del sistema OBJ-09 Gestión de la información OBJ-10 117 RF-06 X RF-07 X RF-08 X X RF-09 X RF-10 X RF-11 X RF-12 X RF-13 X RF-14 X X RF-15 X X RF-16 X RF-17 X RF-18 X RF-19 X X RF-20 X X RF-21 X RF-22 X RF-23 X X RF-24 X X RF-25 X RF-26 X RF-27 X X RF-28 X X RF-29 X RF-30 X RF-31 X X RF-32 X X RF-33 X X RF-34 X RF-35 X 118 RF-36 X RF-37 X X X RF-38 X RF-39 X X X RF-40 X X X RF-41 X RF-42 X RF-43 X RF-44 X X RF-45 X X RF-46 X X RF-47 X X Figura 12. Matriz de rastreabilidad 119 6. Diseño de Clases El propósito de esta actividad, que se realiza sólo en el caso de diseño orientado a objetos, es transformar el modelo de clases lógico, que proviene del análisis, en un modelo de clases de diseño. Dicho modelo recoge la especificación detallada de cada una de las clases, es decir, sus atributos, operaciones, métodos, y el diseño preciso de las relaciones establecidas entre ellas, bien sean de agregación, asociación o jerarquía. Para llevar a cabo todos estos puntos, se tienen en cuenta las decisiones tomadas sobre el entorno tecnológico y el entorno de desarrollo elegido para la implementación. Se identifican las clases de diseño, que denominamos clases adicionales, en función del estudio de los escenarios de los casos de uso. Entre ellas se encuentran clases abstractas, que integran características comunes con el objetivo de especializarlas en clases derivadas. Se diseñan las clases de interfaz de usuario, que provienen del análisis. Hay que considerar que pueden aparecer nuevas clases por el diseño de asociaciones y agregaciones o desaparecer clases junto con sus atributos y métodos por motivos de optimización. En esta actividad también se identifican las jerarquías de clases y los atributos y métodos de cada clase gracias al análisis de los casos de uso de la actividad anterior. Además, en los casos en que sea necesaria una migración de datos de otros sistemas o una carga inicial de información, se realizará su especificación a partir del modelo de clases y las estructuras de datos de los sistemas origen. 6.1. Identificación de Clases Adicionales En este apartado pasamos a definir cada una de las clases identificadas a partir del análisis del diagrama de subsistemas de aplicación. Todas las clases correspondientes al controlador de la aplicación heredarán de la clase org.apache.struts.actions.DispatchAction. Figura 13. Clase DispatchAction Esta clase está dentro del paquete de struts y provee de la funcionalidad necesaria para gestionar la parte del controlador del sistema. Atributos protected java.lang.Class Instancia de la clase DispatchAction class. Protected static org.apache.commons.logging.Log log Commons Logging instance. protected static MessageResources messages The message resources for this package. protected java.util.HashMap methods The set of Method objects we have introspected for this class, keyed by method name. 120 protected java.lang.Class[] Types The set of argument type classes for the reflected method call. Constructor DispatchAction() Métodos protected ActionForward cancelled(ActionMapping mapping, ActionForm form, javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) Método que despacha la petición de usuario cuando es cancelada a través del botón cancel. protected ActionForward dispatchMethod(ActionMapping mapping, ActionForm form, javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response, java.lang.String name) Método que redirecciona la peticiónal método correspondiente. ActionForward execute(ActionMapping mapping, ActionForm form, javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) Proceso especificado por la petición http y que se encarga de crear la correpondiente respuesta del sistema. protected java.lang.reflect.Method getMethod(java.lang.String name) Introspect the current class to identify a method of the specified name that accepts the same parameter types as the execute method does. Protected java.lang.String getMethodName(ActionMapping mapping, ActionForm form, javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response, java.lang.String parameter) Devuelve el nombre del método y sus parámetros. protected java.lang.String getParameter(ActionMapping mapping, ActionForm form, javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) Devuelve el valor del parámetro. protected ActionForward unspecified(ActionMapping mapping, ActionForm form, javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) Method which is dispatched to when there is no value for specified request parameter included in the request. Clase Controlador En las clases controlador será donde se desarrolle toda la lógica de negocio, en nuestro sistema vamos a llamarlas clases de acción. La nomenclatura de estas clases será de tipo NombreProcesoNegocioAction y heredarán de la clase DispatchAction. Por cada clase de acción tendremos un formulario asociado y los métodos a los que se redirecciona desde la interfaz de usuario a través de las jsp. La implementación de cada método tiene que cumplir la siguiente secuencia:  Obtener el formulario con los datos de usuario  Operar con los datos de usuario  Llamada a las interfaces de acceso a base de datos  Preparar la respuesta del sistema almacenándola en los distintos áreas que provee el sistema (objeto request, session...)  Mapear la redirección a la siguiente navegación 121 A continuación se detallan atributos y métodos que como mínimo tiene que tener una clase de acción cualquiera de nuestro sistema. Atributos private es.proyecto.pajareria.bo.ClaseBO ClaseBO Clase de acceso a base de datos. Métodos public ActionForward busqueda(ActionMapping mapping, ActionForm form, javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) Método que devuelve un resultado de búsqueda y redirecciona la petición a la interfaz de usuario correspondiente. public ActionForward alta(ActionMapping mapping, ActionForm form, javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) Método que hace el alta en el sistema y redirecciona la petición a la interfaz de usuario correspondiente. public ActionForward baja(ActionMapping mapping, ActionForm form, javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) Método que la baja en el sistema y redirecciona la petición a la interfaz de usuario correspondiente. public ActionForward modificacion(ActionMapping mapping, ActionForm form, javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) Método que modifica los datos y redirecciona la petición a la interfaz de usuario correspondiente. El siguiente esquema muestra una implementación de una clase de acción cualquiera de nuestro sistema. public ActionForward search( final ActionMapping aMapping, final ActionForm aForm, final HttpServletRequest aRequest, final HttpServletResponse aResponse) { CentrosForm tmpForm = (CentrosForm) aForm; ActionForward tmpForward = new ActionForward(); CentroVO tmpCentro = new CentroVOImpl(); CentroBO tmpCentroBO = new CentroBO(); inicializarFormulario(tmpForm); try { if (tmpForm.getBoton()!= null && tmpForm.getBoton().equals("1")){ Collection tmpListaCentros = tmpCentroBO.getListadoCentros (tmpForm.getCodigo(), tmpForm.getNombre()); aRequest.setAttribute(Constantes.LISTADO_CENTROS, tmpListaCentros); aRequest.getSession().setAttribute(Constantes.LISTADO_CENTROS, tmpListaCentros); tmpForm.setListCentros(tmpListaCentros); aRequest.setAttribute("listaCentros", tmpListaCentros); } } catch (Exception e) { e.printStackTrace(); String mensaje = "error al obtener el listado bbdd"; tmpForm.setError(mensaje); } tmpForward = aMapping.findForward("success"); return tmpForward; } 128 CentroAction Figura 18. Centro CentrosAction Figura 19. Centro 129 CharAction Figura 20. Char 130 ClienteAction Figura 21. Cliente 131 ConsultaStockAction Figura 22. Consulta Stock 132 ContactoAction Figura 23. Contacto EnviosAction Figura 24. Envíos 133 ForoAction Figura 25. Foro 134 GestionClienteAction Figura 26. Gestión Cliente 135 GestionPedidosAction Figura 27. Gestión Pedidos 136 GestionProductosAction Figura 28. Gestión Productos 137 GestionProveedorAction Figura 29. Gestión Proveedor 144 7. Diseño de la Arquitectura de Módulos del Sistema Cuando abordamos el desarrollo de una aplicación Java, uno de los primeros requerimientos que se debe tener en cuenta es la integración de la aplicación con una base de datos para guardar, actualizar y recuperar la información que utilizará dicha aplicación (tanto los datos producidos durante la interacción de los usuarios con la aplicación como datos que son mostrados a los usuarios). Por ello necesitamos que nuestra aplicación sea persistente, es decir que sea capaz de guardar y recuperarse desde un medio de almacenamiento (base de datos). La manera de conseguir implementar esto es gracias a la API de Java JDBC que nos permitirá conectar nuestra aplicación a su base de datos. En este apartado se definirán todos los aspectos relativos a la parte de diseño de la aplicación como son el modelo de datos, las clases que conformarán nuestra aplicación así como las relaciones y dependencias entre ellas. Para ello nos basaremos en el modelo estático del sistema. 7.1. Diseño del Modelo Físico de Datos En este apartado expondremos el diseño físico de nuestro modelo de datos. Diseño de la Base de Datos Aquí se definirá la forma o diseño que tendrá nuestra base de datos. Nuestro sistema de base de datos es relacional y estará formado por un conjunto de registros, datos y relaciones que reflejan las necesidades de información de nuestra aplicación. Todos los elementos que conforman nuestras bases de datos están interrelacionados. Las bases de datos relacionales se basan precisamente, en generar un conjunto de esquemas de relaciones, que permitan almacenar la información con un mínimo de redundancia, pero que a la vez faciliten la recuperación de la información. Estas relaciones que agrupan información se conocen como “tuplas”. Entre las cualidades básicas que debe tener nuestro sistema de base de datos se encuentran:  Evitar la información redundante.  Mantener la integridad entre los datos almacenados.  Proporcionar un acceso seguro y fiable a los datos almacenados.  Ha de permitir captar las relaciones del mundo real. Por tanto para abordar el diseño de una base de datos se deben seguir las siguientes fases de diseño:  Diseño conceptual: descripción global y genérica de la información sin tener en cuenta las consideraciones físicas. Contiene descripciones de los tipos de datos, relaciones entre ellos y restricciones. - Nosotras utilizaremos para el diseño de nuestro esquema conceptual el modelo E-R (entidad relación), que describe los datos cono entidades, vínculos (relaciones) y atributos.  Diseño lógico: descripción de la información usando un modelo de datos específico. El siguiente paso en el proceso de diseño consiste en implementar la base de datos con un S.G.B.D. (sistema gestor de base de datos), transformando el modelo conceptual.  Diseño físico: implementación física de la base de datos. 7.1.1. Diseño Conceptual 7.1.1.1. Modelo de Entidad Relación El diagrama de entidad relación es una herramienta de modelado de datos, a través de la cual estableceremos todas las entidades, relaciones y atributos relevantes en nuestro sistema, y que proporcionará la estructura de nuestra base de datos. Para ello se basan en los siguientes componentes:  Entidad: cualquier objeto del mundo real que tiene existencia por sí mismo y del que se recoge información de interés que se almacenará en la base de datos. Pueden ser fuertes (no dependen de ninguna otra ya y se representan con un rectángulo de trazo simple), o débiles (su existencia está ligada a otra entidad y se representan con rectángulos de doble trazo). 145  Atributo: propiedades de una entidad o relación común para todas las ocurrencias de una misma entidad. Están basados en un dominio (conjunto de valores posibles que pueden tomar). Su valor puede ser único o multivaluado.  Clave primaria: atributo que permite identificar a las distintas instancias de una entidad.  Relación o interrelación: expresa una asociación entre dos o más ocurrencias de una entidad. Pueden tener atributos propios. Pueden tener las siguientes cardinalidades (número de ocurrencias de una entidad que pueden asociarse con otra entidad): - 1:1: cada ocurrencia de una entidad A le corresponde como máximo una ocurrencia de la otra entidad B. - 1: N: cada ocurrencia de una entidad A le pueden corresponder varias ocurrencias de la otra entidad B. - N: M: cada ocurrencia de una entidad A le pueden corresponder varias ocurrencias de la otra entidad B y viceversa. A continuación se muestra nuestro modelo entidad-relación: IMAGEN APLICACIÓN WEB USARIO FORO EMPRESA PRODUCTO TEMA SUBTEMA MENSAJE PEDIDO BANCO FACTURA TIENE CONSTA TIENE RESPONDE TIENE TIENE TIENE TIENE ES_UN REALIZA FORMADOR POR DISPONE CENTRO DISTRIBUYE PAGA GENERA TIENE Id_tema (1,1) (1,1) (1,1) (1,1) (1,1) (1,1) (1,1) (1,1) (1,1) (1,1) (1,1) (1,1) (1,1) (1,1) (0,1) (1,N) (1,N) (1,N) (1,N) (1,N) (1,N) (1,N) (1,N) (1,N) (1,N)(0,N) (1,N) (1,N) (1,1) (0,N) Num_uni Fecha Num_Uni Precio Id_mensaje ADMINISTRADOR CLIENTE PROVEEDOR id id id 1.N 1.N 1.N 1.N 1.N 1.N 1.N 1.N 1.N 1.1 1.1 1.1 1.N N,M N,M (0,1) (0,1) SUMINISTRA TIENE PEDIDO_PROV Iva Gastos_Envio Num_Unidades FACTURA PROV (1,N) (1,N) (1,1) (1,1) 1:1 N:M:P Cod_Imagen Url Cod_foro Cif Id_tema Id_subtema Id_centro Cod_producto Cod_pedido Cod_pedido Id_subtema Cod_Usuario ENVIA (1,N) (1,N) (0,N) (1,1) 1:N Cod_proveedor Num_factura Cod_banco Importe (1,1) N:M Cod_pedido (0,N) Figura 6.- Diagrama Entidad Relación 146 DICCIONARIO DE DATOS DEL MODELO ENTIDAD RELACIÓN ENTIDADES Entidad Imagen: representa cada foto de las crías que pueden salir de un posible análisis de descendencia genética. Atributos:  Cod_Imagen: identificador de la entidad. Tipo: int.(10), clave principal.  Nombre: nombre con el que se identifica a la imagen. Tipo varchar(40), no nulo.  Fenotipo: combinación genética necesaria para visualizar esa imagen. Tipo varchar(50), no nulo.  Path: ruta donde se encuentra ubicada físicamente la imagen. Tipo varchar(90), no nulo.  Url: representa la url de la aplicación a la que pertenecen las imágenes. Tipo varchar(50), no nulo. Imagen Path Fenotipo Cod_Imagen Nombre Url Figura 38. Entidad Imagen Entidad Aplicacion_Web: representa los datos de la aplicación web. Atributos:  Url: identificador de la entidad que contiene la dirección web de la aplicación. Tipo varchar (50), clave principal.  Nombre: representa el nombre que se asocia a la web de la pajarería. Tipo varchar(50), no nulo. Aplicacion_Web Url Nombre Figura 39. Entidad Aplicacion_Web Entidad Usuario: representa a los usuarios de la aplicación web Atributos:  Cod_Usuario: identificador de la entidad que representa a un usuario que accede a la web. Tipo varchar (10), clave principal.  Login: usuario de acceso a la web. Tipo varchar(10), no nulo.  Password: contraseña de acceso del usuario a la web. Tipo varchar(10), no nulo.  Dni: documento de identificación del usuario. Tipo varchar(9), nulo por defecto.  Nombre: nombre del usuario. Tipo varchar(20) , nulo por defecto.  Apellido: primer apellido del usuario. Tipo varchar(20) , nulo por defecto.  Apellido2: segundo apellido del usuario. Tipo varchar(20) , nulo por defecto.  Tratamiento: tratamiento que solicita el usuario en la web. Tipo varchar(1) , nulo por defecto.  Telefono: teléfono de contacto. Tipo varchar(9) , nulo por defecto.  Id_Provincia: código de la provincia donde reside el usuario. Tipo int(10) , nulo por defecto. 147  Ciudad: ciudad donde reside el usuario. Tipo varchar(40) , nulo por defecto.  Calle: calle donde reside el usuario. Tipo varchar(50) , nulo por defecto.  Id_Pais: código del país de origen del usuario. Tipo int(2) , nulo por defecto.  Cp: código postal del lugar donde reside el usuario. Tipo varchar(5) , nulo por defecto.  Correo: dirección de correo electrónico del usuario. Tipo varchar(40) , nulo por defecto.  Nacionalidad: nacionalidad del usuario. Tipo varchar(25) , nulo por defecto.  F_Nac: fecha de nacimiento del usuario. Tipo date , nulo por defecto.  Tipo: clase de usuario que se está dando de alta (particular o empresa). Tipo char , nulo por defecto.  Tipo_Documento: tipo de documento que se escoge para identificarse. Tipo varchar(2) , nulo por defecto.  Numero: numero de la dirección de contacto. Tipo varchar(3), no nulo.  Bloque: bloque de la dirección de contacto. Tipo varchar(2) , nulo por defecto.  Info_Adicional: comentarios adicionales que desee añadir el usuario. Tipo varchar(50) , nulo por defecto.  Id_Piso: número del piso de contacto del usuario. Tipo varchar(2) , nulo por defecto.  Id_Letra: letra del piso de contacto del usuario. Tipo varchar(2) , nulo por defecto.  Url: dirección web de la pajarería donde se están dando de alta. Tipo varchar(50) , nulo por defecto.  Borrado: indica si un usuario ha sido eliminado o se ha dado de baja del sistema. ES_UN CLIENTE USUARIO ADMINISTRADOR Cod_Usuario Password Nombre Login Apellido2 Apellido Dni Telefono Tipo_Documento Nacionalidad Info_Adicional Ciudad Id_Provincia F_Nac Url Cp Id_Letra Tipo Id_Piso Numero Bloque Calle Correo Id_Pais Tratamiento Borrado Figura 40. Entidad Usuario Entidad Empresa: representa la empresa asociada a la web de la pajarería. Atributos:  Cif: representa el código de identificación fiscal de la empresa. Tipo varchar (9), clave principal.  Nombre: nombre de la empresa. Tipo varchar(20), no nulo.  Id_Provincia: código de la provincia donde se ubica la empresa. Tipo int(10).  Ciudad: ciudad donde se ubica la empresa. Tipo varchar(40), no nulo.  Calle: calle donde se sitúa la empresa. Tipo varchar(50), no nulo.  Id_Pais: código del país donde se ubica la empresa. Tipo int(2).  Cp: código postal correspondiente a la dirección donde se ubica la empresa. Tipo varchar(5), no nulo.  Correo: correo electrónico de contacto con la empresa. Tipo varchar(40), no nulo.  Url: web de la pajarería a la que está asociada la empresa. Tipo varchar(50), no nulo. 148 Empresa Cif Nombre Id_Provincia Ciudad Calle Id_Pais Correo Url Cp Figura 41. Entidad Empresa Entidad Foro: representa al foro de la aplicación donde los usuarios intercambian información. Atributos:  Cod_Foro: representa el código de identificación del foro de la aplicación. Tipo varchar (2), clave principal.  Nombre_Foro: representa el nombre del foro de la empresa. Tipo varchar(10), no nulo.  Url: web de la pajarería a la que pertenece el foro. Tipo varchar(50), no nulo. Foro Cod_Foro Url Nombre_Foro Figura 42. Entidad Foro Entidad Tema: representa cada tema de conversación que existe dentro del foro. Atributos:  Id_Tema: representa el código de identificación de cada uno de los temas del foro. Tipo varchar (2), clave principal.  Nombre_Tema: representa el nombre del foro de la empresa. Tipo varchar(20), no nulo.  Cod_Foro: código de identificación del foro de la aplicación. Tipo varchar(2). Tema Id_Tema Nombre_Tema Cod_Foro Figura 43. Entidad Tema Entidad Subtema: representa al foro de la aplicación donde los usuarios intercambian información. Atributos:  Id_Subtema: representa el código de identificación del subtema del foro de la aplicación. Tipo varchar (2), clave principal.  Id_Tema: representa el código de identificación del tema al que pertenece el. Tipo varchar(2), clave principal.  Nombre_Subtema: nombre del subtema del foro de la aplicación. Tipo varchar(20), no nulo.  Características: muestra la ruta donde se encuentra el fichero que se cargará para el subtema seleccionado. Tipo varchar(50), no nulo. 149 Subtema Id_Tema Nombre_Subtema Características Id_Subtema Figura 44. Entidad Subtema Entidad Mensaje: representa al foro de la aplicación donde los usuarios intercambian información. Atributos:  Id_Mensaje: representa el código de identificación del mensaje que el usuario está creando en el foro de la aplicación. Tipo varchar (2), clave principal.  Id_Subtema: representa el código de identificación del subtema en el cual se está escribiendo el mensaje. Tipo varchar (2), clave principal.  Id_Tema: representa el código de identificación del tema en el cual se está escribiendo el mensaje. Tipo varchar(2), clave principal.  Nombre_Mensaje: nombre del mensaje del foro de la aplicación. Tipo varchar(20), no nulo.  Descripcion: muestra el contenido del mensaje que se ha generado en el foro. Tipo varchar(100), no nulo.  Id_Mensaje_Res: muestra el identificador del mensaje al que está asociado un mensaje. Tipo varchar(2), no nulo.  Cod_Usuario: indica el código del usuario que ha creado un mensaje. Tipo varchar(10) , nulo por defecto. Mensaje Nombre_Mensaje Descripcion Id_Tema Id_Subtema Id_Mensaje Cod_Usuario Id_Mensaje_Res Figura 45. Entidad Mensaje Entidad Centro: representa un centro o tienda de la empresa. Atributos:  Id_Centro: código que identifica a cada centro asociado a la empresa. Tipo int(2), clave principal.  Nombre_Centro: nombre de la tienda. Tipo varchar(20), no nulo.  Id_Provincia: provincia en la cual se encuentra la tienda. Tipo int (2), no nulo.  Ciudad: ciudad donde se sitúa el centro. Tipo varchar(40), no nulo.  Calle: calle donde se encuentra la tienda. Tipo varchar(50), no nulo.  Numero: número donde se ubica el centro. Tipo varchar(3), no nulo.  Bloque: muestra el identificador del bloque donde está ubicada la tienda. Tipo varchar(2), nulo por defecto.  Id_Pais: país en el que se encuentra la tienda. Tipo int(2) , nulo por defecto.  Cp: código postal correspondiente a la ubicación donde está la tienda. Tipo varchar(5), no nulo.  E_Mail: dirección de correo electrónico de la tienda. Tipo varchar(40), no nulo.  Telefono: teléfono de contacto del centro. Tipo varchar(9), no nulo.  Cif: documento de identificación fiscal de la empresa a la que pertenece la tienda. Tipo varchar(9), no nulo. 150 Centro Id_Centro Nombre_Centro Ciudad Calle Numero Bloque Id_Pais Cp Telefono Cif Email Figura 46. Entidad Centro Entidad Producto: artículo de venta en la web de la pajarería. Atributos:  Cod_Producto: código que identifica a cada producto. Tipo varchar (6), clave principal.  Nombre_Producto: nombre del producto. Tipo varchar(30), no nulo.  Fecha: fecha en la que se ha dado de alta el producto en el sistema. Tipo date, no nulo.  Precio_Compra: precio a l cual la empresa ha comprado el producto. Tipo decimal(6,2), no nulo.  Precio_Venta: precio de venta al público del producto . Tipo decimal(6,2), nulo por defecto.  Id_Familia: muestra el identificador de la familia a la que pertenece el producto. Tipo varchar(2), no nulo.  Características: descripción de las características del producto. Tipo varchar(20) , nulo por defecto.  Oferta: indica si el producto está en oferta o no. Tipo varchar(3), no nulo.  Stock: cantidad de unidades disponibles del producto. Tipo varchar(9), no nulo.  Id_Iva: identificador del iva que se aplicará al producto. Tipo char, nulo por defecto.  Cif: identificador fiscal de la empresa donde se vende el producto. Tipo varchar(9), no nulo.  Promoción: identifica si el producto está en promoción. Tipo char(1), no nulo.  Cod_Imagen: identificador de la imagen asociada al producto. Tipo int(10), nulo por defecto.  Peso: peso del producto. Tipo decimal decimal(5,2).  Borrado: identificador de un producto cuando se ha dado de baja en el catálogo de la empresa. Tipo char no nulo siendo su valor por defecto ‘N’. Producto Fecha Precio_Compra Precio_Venta Id_Familia Caracteristicas Oferta Cod_Producto Nombre_Producto Stock Cod_Imagen Cif Promocion Id_Iva Borrado Peso Figura 47. Entidad Producto Entidad Pedido_Prov: representa el pedido que una tienda hace a un proveedor. Atributos:  Cod_Pedido: código que identifica cada pedido que se hace a un proveedor. Tipo int (6), clave principal. Se autoincrementa su valor.  Fecha: fecha en la que se realiza el pedido. Tipo date, no nulo. Pedido_Prov Cod_Pedido Fecha Figura 48. Entidad Pedido_Prov 151 Entidad Proveedor: representa a un proveedor asociado a la empresa. Atributos:  Cod_proveedor: código que identifica a un proveedor. Tipo varchar (6), clave principal.  Dni: representa al código de identificación del proveedor. Tipo varchar(9), no nulo.  Nombre: nombre del proveedor. Tipo varchar(20), no nulo.  Apellido: primer apellido del proveedor. Tipo varchar(20), nulo por defecto.  Apellido2: segundo apellido. Tipo varchar(20), nulo por defecto.  Correo: dirección de correo electrónico del proveedor. Tipo varchar(40), nulo por defecto.  Telefono: número de teléfono de contacto. Tipo varchar(9), no nulo.  Id_Provincia: código de la provincia del proveedor. Tipo int(2), no nulo.  Ciudad: ciudad donde se ubica el proveedor. Tipo varchar(40), no nulo.  Calle: dirección de localización del proveedor. Tipo varchar(50), no nulo.  Id_Pais: código del país del proveedor. Tipo int(2), nulo por defecto.  Cp: código postal de la dirección de contacto del proveedor. Tipo varchar(5), no nulo.  Numero: numero del centro del proveedor. Tipo varchar(3), no nulo.  Tipo: representa el tipo de proveedor. Tipo char(1), no nulo.  Borrado: identificador de un proveedor cuando se ha dado de baja como proveedor de la empresa. Tipo char no nulo siendo su valor por defecto ‘N’. Cod_proveedor Proveedor Dni Nombre Apellido Apellido2 Telefono Correo Numero Cp Ciudad Calle Id_Pais Tipo Id_Provincia Borrado Figura 49. Entidad Proveedor Entidad Pedido: representa un pedido que realiza un cliente a través de la web de la pajarería. Atributos:  Cod_Pedido: código que identifica a un pedido que realiza un cliente a través de la web. Tipo int (6), clave principal. Se autoincrementa.  Fecha: representa la fecha en la que se ha realizado el pedido. Tipo date, no nulo.  Id_Estado: estado en el que se encuentra un pedido. Tipo varchar(2), no nulo.  Forma_Pago: método de pago elegido por el cliente. Tipo char, no nulo.  Cod_Banco: código que identifica una cuenta asociada al usuario. Tipo varchar(4), nulo por defecto.  Cod_Usuario: código del usuario que realiza el pedido. Tipo varchar(10), no nulo.  Cod_Usuario_Ped: código asignado a un usuario que realiza un pedido. Tipo int(10), no nulo.  Id_Gastos: representa el código que generará los gastos de envío del pedido. Tipo varchar(2) nulo por defecto.  Importe: importe total del pedido. Tipo decimal(7,2), no nulo. Pedido Cod_Pedido Cod_Usuario_Ped Cod_Usuario Forma_Pago Fecha Cod_Banco Importe Id_Gastos 152 Figura 50. Entidad Pedido Entidad Factura: representa una factura de un pedido. Atributos:  Num_Factura: código que identifica a cada factura. Tipo int (4), clave principal. Se autoincrementa.  Cod_Pedido: código que identifica un pedido realizado a través de la web. Tipo int(6), clave principal.  Id_Sector: id de los gastos de envío que se aplicarán a un pedido. Tipo varchar(2), nulo por defecto.  Importe: importe total del pedido. Tipo decimal (7,2), no nulo. Factura Cod_Pedido Num_Factura Importe Id_Sector Figura 51. Entidad Factura Entidad Banco: representa los datos bancarios de las cuentas asociadas a la pajarería donde los clientes podrán realizar transferencias bancarias de los pedidos que realicen. Atributos:  Cod_Banco: código que identifica cada cuenta bancaria. Tipo varchar(4), clave principal. Se autoincrementa.  Nombre: nombre del banco al que pertenece la cuenta. Tipo varchar(20), no nulo.  Entidad: entidad donde se abrió la cuenta bancaria. Tipo varchar(4), no nulo.  Oficina: oficina donde se abrió la cuenta bancaria. Tipo varchar(4), no nulo.  Dc: dígito de control de la cuenta. Tipo varchar(2), no nulo.  Cuenta: número de cuenta. Tipo varchar(10), no nulo. Banco Nombre Dc Cod_Banco Cuenta Entidad Oficina Figura 52. Entidad Banco RELACCIONES Relación Tiene (Imagen-Aplicación web): Descripción: Relación entre la entidad Imagen y Aplicación web. Una aplicación web contendrá una serie de imágenes necesarias para la visualización de los diamantes de Gould del programa Mendel, así como de los productos que se venden a través de la web. Restricciones: A una aplicación web le pertenecen varias imágenes o una como mínimo y una imagen pertenece a una sola aplicación. Las cardinalidades entre las entidades imagen y aplicación web serán (1,N) y (1,1) con una interrelación Tiene de tipo 1:N. Atributos: Ninguno. 153 Relación Tiene (Usuario-Aplicación web): Descripción: Los usuarios de la aplicación podrán identificarse en la web por medio del login y password con el que se dieron de alta. Restricciones: Dado que la aplicación web puede tener como mínimo un usuario o múltiples, las cardinalidades entre las entidades Usuario y Aplicación web serán (1,N) y un usuario concreto pertenece a una Aplicación web (1,1). Por tanto la interrelación Tiene que existe entre ambas entidades es de tipo 1:N. Atributos: Ninguno. Relación Es_un (Usuario-Cliente-Administrador): Descripción: Respecto a la entidad Usuario podemos decir que existen dos tipos específicos de usuarios (aquellos que necesitan identificarse en la web con un login de usuario y password), que son cliente o administrador. Restricciones: La entidad usuario se modula como una jerarquía total y exclusiva ya que cada usuario sólo puede ser o un cliente o un administrador de la aplicación pero no ambos a la vez. Las cardinalidades entre el supertipo (Usuario) y el subtipo (Cliente o Administrador) serán de tipo (1,1) y (0,1) respectivamente. Atributos: Ninguno. Relación Tiene (Aplicación-Empresa): Descripción: La aplicación web está asociada a una única empresa y a una empresa le pertenece una aplicación web. Restricciones: Las cardinalidades entre las entidades Empresa y Aplicación web serán (1,1) y (1,1) con una interrelación Tiene de tipo 1:1. Atributos: Ninguno. Relación Tiene (Empresa-Centros): Descripción: Una empresa puede tener más de una tienda ubicadas en diferentes ciudades, como mínimo tendrá una. Sin embargo cada tienda pertenece a una única empresa. Restricciones: Por tanto las cardinalidades entre las entidades Centro y Empresa serán (1,N) y (1,1) respectivamente, con una interrelación Tiene de tipo 1:N. Atributos: Ninguno. Relación Distribuye (Centro-Producto): Descripción: Cada centro o tienda distribuyen una serie de productos disponibles en la empresa. Cada centro puede distribuir varios productos y un producto puede ser distribuido como mínimo en un centro o por varios centros. Restricciones: Las cardinalidades entre las entidades Centro y Producto serán (1,N) y (1,N) con una interrelación Distribuye de tipo N:M donde además debemos almacenar el número de unidades distribuidas a cada centro y la fecha. Atributos: Num_uni, Fecha. Relación Dispone (Empresa-Producto): Descripción: Una empresa puede distribuir muchos productos a través de sus centros. Cada producto sólo puede venderse en una única empresa. Restricciones: Por otro lado las cardinalidades entre las entidades Empresa y Producto serán (1,N) y (1,1) con una interrelación Dispone de tipo 1:N. Atributos: Ninguno. Relación Tiene (Aplicación web-Foro): Descripción: Los clientes de la aplicación pueden intercambiar información a través de un foro que contiene la aplicación, o consultar entre otras cosas las características especiales de varias especies de aves. Una aplicación web tiene como máximo un foro mientras que cada foro es utilizado en exclusiva por una única aplicación. Restricciones: Las cardinalidades entre las entidades Foro y Aplicación web serán (1,1) y (1,1) con una interrelación Tiene de tipo 1:1. Atributos: Ninguno. 256 Campo Tipo de Campo Descripción hasta el momento. Añadir Producto Botón Botón habilitado que permite acceder al formulario para dar de alta un nuevo producto en la base de datos. Realizar pedido Botón Botón habilitado en el caso de que se haya seleccionado un registro del listado de productos. Permite acceder a la pantalla de realización de pedidos de un producto. A continuación se muestra el formulario para dar de alta un producto en el catálogo. Figura 24. Alta productos Campo Tipo de Campo Descripción Nombre del producto Campo de texto Campo editable obligatorio en el que se podrá introducir el nombre del nuevo producto. Admite dígitos y letras y tiene una longitud máxima de 20 caracteres. Familia lista desplegable Lista que muestra las distintas familias en las que se distribuyen todos los productos existentes (Alimentación, Especie, Accesorios, Medicamentos…). No se informa ningún valor por defecto. Campo obligatorio. Fecha de alta Etiqueta Campo protegido que mostrará la fecha actual en la que se dio de alta ese producto. Se cargará por defecto con la fecha del día. Precio Campo de texto Campo editable y obligatorio que indica el precio unitario de venta del producto a los clientes. Admite 6 dígitos (3 decimales y 3 enteros). Stock Campo de texto Campo editable y obligatorio en el que se muestra el número de unidades del producto que se van a dar de alta en el almacén del producto. Tendrá 6 dígitos. Características Campo de texto Campo editable y obligatorio en el que el administrador podrá introducir una pequeña descripción de las características más importantes del producto. Tiene un tamaño máximo de 300 caracteres. Volver Botón Botón habilitado que permite regresar a la pantalla inicial (Búsqueda de productos). Guardar Botón Botón habilitado que permite guardar los datos del nuevo producto en la base de datos si se ha rellenado el formulario correctamente. En este caso se mostrará un mensaje de éxito. En caso contrario se mostrará un 257 Campo Tipo de Campo Descripción mensaje de error. Respecto al formulario de modificación de producto, cabe destacar que a este formulario se podrá acceder mediante el link que aparece en el listado de productos de la pantalla de gestión de productos. El formulario tendrá el siguiente aspecto: Figura 25. Modificación productos Campo Tipo de Campo Descripción Nombre del producto Etiqueta Campo editable que muestra el nombre del producto seleccionado en el listado. Familia Combo desplegable Campo editable con el valor seleccionado de la familia a la que pertenece el producto. Fecha de alta Etiqueta Campo protegido que mostrará la fecha en la que se dio de alta el producto. Precio Campo de texto Campo editable y obligatorio que indica el precio unitario de venta del producto a los clientes. Admite 6 dígitos (3 enteros y 3 decimales). Stock Etiqueta Campo editable que se muestra el número de unidades del producto existentes en el almacén. Características Etiqueta Campo editable que da una pequeña descripción de las características más importantes del producto. Volver Botón Botón habilitado que permite regresar a la pantalla inicial (Búsqueda de productos). Guardar Botón Botón habilitado que permite guardar los datos modificados del producto. Cuando el stock de alguno de los productos no sea suficiente, cualquier administrador tendrá la posibilidad de realizar pedidos de los productos bajos de stock.. Para poder acceder a este formulario bastará con pulsar el botón de realizar pedidos de la pantalla de gestión de productos. 258 Figura 26. Pedidos Campo Tipo de Campo Descripción Producto Lupa Campo para hacer búsquedas de productos. Se puede introducir el código del producto, nombre o stock para realizar la búsqueda. En caso de que el producto no exista se mostrará un mensaje de error, si se ha encontrado se cargará el código y la descripción en los campos correspondientes. Proveedor Lupa Campo que contiene la referencia y la descripción de un proveedor. Se puede introducir el código del proveedor para realizar la búsqueda. En caso de que el proveedor no exista se mostrará un mensaje de error, si se ha encontrado se cargará el código y la descripción en los campos correspondientes. Otra posibilidad de buscar el proveedor es pulsando sobre la imagen de la lupa. Número de unidades Campo de texto Campo editable y obligatorio en el que el administrador pondrá el número de unidades del producto que desea adquirir. Campo numérico Pedido Listado Listado con los pedidos introducidos por el usuario. Contiene un campos de tipo check para seleccionar los productos que el administrador quiera eliminar, código de producto, código de proveedor, número de unidades, importe, la fecha y el importe total del pedido Añadir Botón Botón habilitado que permite añadir los productos elegidos por el usuario a la lista Eliminar Botón Botón habilitado que permite al usuario eliminar los productos de la lista que desee el usuario Volver Botón Botón habilitado que permite regresar a la pantalla inicial (Búsqueda de productos). Generar Factura Botón Botón habilitado que permite realizar un pedido de un producto a un determinado proveedor y guardar un registro para ese pedido en base de datos. Tras haber realizado el pedido el administrador podrá visualizar el desglose del pedido realizado. 259 Figura 27. Factura Campo Tipo de Campo Descripción Pedido Listado Listado con los pedidos introducidos por el usuario. Contiene los campos código de producto, código de proveedor, número de unidades, importe, la fecha y el importe total del pedido Volver Botón Botón habilitado que permite regresar a la pantalla inicial (Búsqueda de productos). Aceptar Botón Botón habilitado que permite aceptar la factura asociada al pedido Además la web proporcionará la posibilidad de imprimir el desglose de la factura del pedido. Figura 28. Factura Campo Tipo de Campo Descripción Pedido Listado Listado con los pedidos introducidos por el usuario. Contiene los campos código de producto, código de proveedor, número de unidades, importe, la fecha y el importe total del pedido 260 Campo Tipo de Campo Descripción Volver Botón Botón habilitado que permite regresar a la pantalla inicial (Búsqueda de productos). Aceptar Botón Botón habilitado que permite aceptar la factura asociada al pedido 3.6.4. Gestión de pedidos A través de la opción de gestión de pedidos, cualquier administrador del sistema podrá gestionar tanto los pedidos realizados por clientes a través de la web, como los pedidos que la empresa ha realizado a distintos proveedores. Figura 29. Gestión de pedidos Campo Tipo de Campo Descripción Opciones Radio El administrador podrá elegir mediante un radio button la opción de pedidos de clientes o a proveedores Una vez que se ha elegido los pedidos que se quieren gestionar (pedidos de clientes o pedidos a proveedores), se presentará un formularios diferente en función de la opción elegida. Para los pedidos realizados a clientes se presentará el siguiente formulario: 261 Figura 30. Pedidos clientes Campo Tipo de Campo Descripción Código pedido Campo de texto y lupa Contendrá un campo de texto para introducir el código del pedido que será de 7 caracteres. Si no se conoce el código se pulsará la lupa que abrirá un popup para poder realizar la búsqueda del pedido. Estado Lista desplegable Lista desplegable con los distintos tipos de estado de un pedido. Este campo será opcional y su opción por defecto estará vacía. Código cliente Campo de texto y lupa Contendrá un campo de texto para introducir el código del cliente que será de 7 caracteres y/o el nombre que será de 60 caracteres. También podrá realizar una búsqueda del cliente a través de la lupa que abrirá el popup de búsqueda de clientes. Tipo de Producto Campo de texto y lupa Contendrá un campo de texto para introducir el código del producto que será de 7 caracteres y o el nombre que será de 20 caracteres. También podrá realizar una búsqueda del producto a través de la lupa que abrirá el popup de búsqueda de productos. Fecha Inicio Calendario Calendario para fijar el rango de fechas para la búsqueda de un pedido. Ese campo es opcional. Fecha Fin Calendario Calendario para fijar el rango de fechas para la búsqueda de un pedido. Ese campo es opcional. Listado de pedidos Listado Será la lista resultante de la búsqueda. Contendrá un campo de texto protegido con el código del cliente, código de Producto también protegido, estado del pedido será una lista desplegable editable y por último un campo de texto protegido con el precio. Buscar Botón Tras pulsar el botón buscar saldrá el listado de pedidos resultado de los filtros de búsqueda introducidos anteriormente. Volver Botón El administrador podrá volver a la pantalla de gestión de pedidos. Para los pedidos realizados a proveedores el sistema nos mostrará la siguiente pantalla: 262 Figura 31. Pedidos a proveedores Campo Tipo de Campo Descripción Código pedido Campo de texto y lupa Contendrá un campo de texto para introducir el código del pedido que será de 7 caracteres. Si no se conoce el código se pulsará la lupa que abrirá un popup para poder realizar la búsqueda del pedido. Estado Lista desplegable Lista desplegable con los distintos tipos de estado de un pedido. Este campo será opcional y su opción por defecto estará vacía. Familia Campo de texto y lupa Contendrá un campo de texto para introducir el código del producto que será de 7 caracteres. Si no se conoce el código se pulsará la lupa que abrirá un popup para poder realizar la búsqueda del producto. Proveedor Campo de texto y lupa Contendrá un campo de texto para introducir el código del proveedor que será de 7 caracteres y otro con el nombre del proveedor que será de 20 caracteres. Además tendrá una lupa que abrirá un popup para hacer búsquedas. Fecha Inicio Calendario Calendario para fijar el rango de fechas para la búsqueda de un pedido. Ese campo es opcional. Fecha Fin Calendario Calendario para fijar el rango de fechas para la búsqueda de un pedido. Ese campo es opcional. Listado de pedidos Listado Será la lista resultante de la búsqueda. Contendrá un campo de texto protegido con el código de pedido, una lista desplegable con el estado que se podrá modificar, un campo de texto protegido con el tipo de producto y por último un campo de texto también protegido con el precio. Buscar Botón Tras pulsar el botón buscar saldrá el listado de pedidos resultado de los filtros de búsqueda introducidos anteriormente. Guardar Botón Botón que permitirá al administrador guardar los cambios introducidos. Volver Botón Botón que permitirá al administrador volver a la pantalla de gestión de envíos. 3.6.5. Consulta de stock A través de la funcionalidad de consulta de stock, los administradores del sistema podrán conocer en todo momento el stock disponibles de cada uno de los productos del catálogo. Así sabrán en todo momento si es necesario realizar el pedido de alguno de ellos. 263 Figura 32. Consultad de stock Campo Tipo de Campo Descripción Tienda Lupa Campo que contiene el código que será de 7 caracteres y la provincia que será de 25 caracteres. El administrador podrá introducir directamente el código de la tienda. En caso de que no exista el código se mostrará un mensaje de error, si el código es correcto, se cargará directamente la descripción de la tienda. También se podrá elegir un centro accediendo a la pantalla de selección de centros. Producto Lupa Campo obligatorio que contiene el código que será de 7 caracteres y la descripción del producto que será 25 caracteres, asociado a la tienda seleccionada en caso de existir. El administrador podrá introducir directamente el código del producto. En caso de que no exista el código se mostrará un mensaje de error, si el código es correcto, se cargará directamente la descripción del producto. También se podrá elegir un producto accediendo a la pantalla de selección de producto. Código del producto Etiqueta Campo protegido que muestra el código del producto Nombre del producto Etiqueta Campo protegido que muestra el nombre del producto. Stock Etiqueta Campo protegido que muestra el número de unidades existentes en el almacén de ese producto concreto. Volver Botón Botón habilitado que permite regresar a la pantalla inicial (Búsqueda de productos). Buscar Botón Botón habilitado que realizar búsquedas en función de los filtros de búsqueda que se hayan rellenado. En caso de no existir ninguno se muestra el stock de todos los productos existentes en el almacén. 3.6.6. Catálogo de ofertas La web dispone de un catálogo de promociones u ofertas que irá cambiando en función de la demanda, stock y otros factores. A través de esta opción del menú de administrador se podrá gestionar todos los cambios que se necesiten realizar en el catálogo de ofertas de la web. 264 Figura 33. Catálogo de ofertas Campo Tipo de Campo Descripción Sel Checkbox Campo que permite elegir una oferta o varias. Nombre del producto Link Enlace que muestra el nombre del producto en oferta y permite acceder a la pantalla de modificación de la oferta. Características del producto Etiqueta Campo protegido que mostrará una breve descripción de las características más importantes del producto. Precio Etiqueta Campo protegido que muestra el precio unitario del producto. Imagen del producto Imagen Imagen del producto. Añadir oferta Botón Botón habilitado que permite al administrador acceder a la pantalla en la cual podrá añadir nuevas ofertas. Eliminar oferta Botón Botón habilitado en caso de que haya algún registro seleccionado que permite eliminar del catálogo ofertas. Cuando se selecciona la opción de menú de añadir oferta se mostrará el siguiente formulario para incluir una nueva oferta en el catálogo. 265 Figura 34. Nueva oferta Campo Tipo de Campo Descripción Producto Lupa Campo editable y obligatorio que tendrá el código que será de 7 caracteres y la descripción del producto que será de 25 caracteres (este último deshabilitado). El administrador podrá introducir directamente el código del producto y en caso de que exista, se cargará automáticamente en el otro campo su descripción. Si no existe se mostrará un mensaje de error. También podrá seleccionar el producto pinchando en la lupa la cual abrirá el popup de Productos. Nombre del producto Etiqueta Campo protegido en el que se visualizará el nombre del producto en oferta. Precio Campo de texto Campo editable y obligatorio que permitirá sólo dígitos. Admite 3 enteros y 3 decimales. Volver Botón Botón habilitado que permite regresar a la pantalla inicial (Búsqueda de productos). Añadir oferta Botón Botón habilitado que permite cargar el nuevo producto como oferta en el listado del catálogo (pantalla de catálogo de ofertas). Desde la pantalla principal se puede acceder al formulario de modificación de una oferta pinchando en el enlace del nombre del producto. El formulario de modificación de oferta se mostrará pre rellenado con los datos de la oferta seleccionada. El administrador podrá modificar el precio de la oferta. Figura 35. Modificación oferta Campo Tipo de Campo Descripción Nombre del producto Etiqueta Campo protegido en el que se visualizará el nombre del producto en oferta. Precio Campo de texto Campo editable y obligatorio que permitirá sólo dígitos. Admite 3 enteros y 3 decimales. Volver Botón Botón habilitado que permite regresar a la pantalla inicial (Búsqueda de productos). Añadir oferta Botón Botón habilitado que permite cargar el producto modificado como oferta en el listado del catálogo (pantalla de catálogo de ofertas). 272 Figura 45. Virtual host 8.- Validamos el context-root de la aplicación. Figura 46. Validar contexto de la aplicación 9.- La siguiente pantalla muestra un resumen con los datos de la instalación. 273 Figura 47. Resumen instalación aplicación web 10.- Una vez instalada sólo nos falta configurarla para que se carguen las librerías de la aplicación antes que el resto de librerías asociadas al servidor. Figura 48. Configuración librerías 11.- Una vez completado el proceso de instalación comprobamos que la aplicación está corriendo en el servidor de aplicaciones correctamente. Abrimos un navegador e introducimos http://diamantedegould.no-ip.org/PajareriaWeb/ 274 Figura 49. Aplicación web 4.7. Reinicio de la aplicación De manera diaria se reiniciará el servidor de aplicaciones para liberar memoria. Para realizarlo, ejecutaremos el script stopServer.bat para parar la aplicación y posteriormente el script startServer.bat, que se encuentra dentro de la instalación de Websphere C:\Websphere\profiles\AppSrv01\bin. Otra opción para realizar la parada y el arranque del aplicativo es a través del listado de aplicaciones instaladas. Figura 50. Reinicio aplicación La ruta donde se almacenan los logs del arranque y ejecución de la aplicación son el SystemOut.log y SystemErr.log que se encuentra ubicados en el directorio C:\Websphere\profiles\AppSrv01\logs\server1. Las trazas de aplicación nos ayudan a comprobar el correcto arranque de la aplicación es WSVR0001I: Servidor server1 abierto para e-busines. 275 4.8. Export / Import de la Base de Datos Dentro de las tareas de mantenimiento de la aplicación, además del reinicio del servidor de aplicaciones, se realizará de manera semanal un backup de seguridad de la Base de Datos. Para realizar el export (extracción) del contenido de la base de datos realizaremos los siguientes pasos:  Nos posicionamos a través de una consola de msdos en el directorio de instalación de mysql, por defecto, C:\Archivos de programa\MySQL\MySQL Server 5.5\bin.  Una vez ubicados en el directorio, ejecutaremos la sentencia: mysqldump -h. Esto nos genera un fichero export.sql con una copia de la información de la base de datos. Figura 51. Consola msdos en directorio de instalación MySQL En el caso de que tuviéramos que recuperar la información realizaríamos la operación inversa, es decir, realizaríamos el import (volcado) de la base de datos. Para ello, seguiremos los siguientes pasos:  No conectamos al servidor con la sentencia: mysql –h 127.0.0.1 –u root –p.  Creamos la base de datos con la sentencia: createdatabase pajarería;.  Seleccionamos la base de datos que acabamos de crear: use pajarería;.  Por último, ejecutamos el fichero export.sql que obtuvimos en el proceso anterior: sourceexport.sql. 4.9. Export / Import de la Base de Datos Dentro de las tareas de mantenimiento de la aplicación, además del reinicio del servidor y las copias de seguridad de la base de datos, también es necesario adaptar la funcionalidad de la aplicación a las nuevas necesidades que vayan surgiendo. Para las actualizaciones de código y nuevos desarrollos de la aplicación, el procedimiento a seguir será la construcción del war a partir del código de la aplicación. La aplicación debe de compilar en su totalidad y el war se generará a través de AST. Figura 52. Exportación de código Seleccionamos el proyecto compilado, botón derecho exportar archivo war. Una vez empaquetado continuamos con el 276 proceso de instalación a través de la consola administrativa de Websphere. Figura 53. Instalación aplicación Posteriormente continuamos el proceso siguiendo los pasos del punto 4.6 del documento (Instalación de la aplicación). 277 Bibliografía Configuración Apache http://www.oracle.com/technetwork/java/index.html http://www.desarrolloweb.com/manuales/41/ http://httpd.apache.org/docs/2.0/ Documentación Struts http://struts.apache.org/development/1.x/userGuide/ http://struts.apache.org/release/1.2.x/api/index.html http://www.jguru.com/faq/java-tools/struts http://tiles.apache.org/ http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=struts_appdemo MySQL http://dev.mysql.com/doc/refman/5.0/es/index.html http://www.mysqltutorial.org/ http://www.mysqltutorial.org/install-mysql/ Métrica v3 http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_Metrica_v3#. UhXZD3-NAgk Ingeniería del Software http://es.wikipedia.org/wiki/COCOMO http://www.uml.org http://users.dcc.uchile.cl/~psalinas/uml/modelo.html http://es.wikipedia.org/wiki/Modelo_Vista_Controlador http://www.soyatec.com/euml2/