Flavors of the States ‘Saborea los estados’. Proyecto web para la gestión y venta de productos alimenticios americanos

Universidad de Valladolid E. U. de Informática (Segovia) Ingeniería Técnica en Informática de Gestión Flavors of the States “Proyecto web para la gestión y venta de productos alimenticios americanos” Alumno: Carlos Aguado García Tutor: José Vicente Álvarez A mi hermano y a mis padres por su apoyo, y muy en especial a mi prometida Cassidy sin la cuál, habría sido imposible sacar este proyecto adelante. Gracias ÍNDICE SECCIÓN I: MEMORIA DEL PROYECTO 1. IDENTIFICACIÓN DEL PROYECTO .................................................................................... 15 2. ORGANIZACIÓN DEL DOCUMENTO .................................................................................. 15 3. MOTIVACIÓN ........................................................................................................................... 15 4. OBJETIVOS ................................................................................................................................ 16 5. ARQUITECTURA Y ENTORNO DEL SISTEMA ................................................................. 17 5.1 ARQUITECTURA .............................................................................................................. 17 5.2 ENTORNO DEL SISTEMA................................................................................................ 19 6. TECNOLOGIAS EMPLEADAS ............................................................................................... 19 7. METODOLOGIA EMPLEADA ................................................................................................ 22 8. PLANIFICACION ...................................................................................................................... 26 8.1 PLANIFICACIÓN INICIAL ............................................................................................... 27 8.2 PLANIFICACIÓN REAL ................................................................................................... 29 8.3 COMPARACIÓN Y CONCLUSIONES ............................................................................. 31 9. COSTES ....................................................................................................................................... 33 9.1 COSTES DE LOS RECURSOS HUMANOS ..................................................................... 33 9.2 COSTE DE HARDWARE................................................................................................... 34 9.3 COSTE DEL SOFTWARE.................................................................................................. 34 10. CONSIDERACIONES ........................................................................................................... 35 10.1 DISEÑO .............................................................................................................................. 35 10.1.1 Carrito de la compra ................................................................................................... 35 10.1.2 Arquitectura de la aplicación ...................................................................................... 35 10.1.3 Productos, Marcas y Categorías ................................................................................. 36 10.2 IMPLEMENTACIÓN ......................................................................................................... 36 10.2.1 Métodos de pago ........................................................................................................ 36 11. AMPLIACIONES .................................................................................................................. 38 11.1 GESTION DE PROVEEDORES ........................................................................................ 38 11.2 GESTIÓN DE CONTABILIDAD ....................................................................................... 38 11.3 PAGO CON TARJETA ....................................................................................................... 38 11.4 GESTION DE OFERTAS ................................................................................................... 40 11.5 GESTION DE ELIMINACIÓN DE CATEGORIAS O MARCAS .................................... 40 11.6 FACTURAS ........................................................................................................................ 41 12. CONCLUSIONES .................................................................................................................. 41 13. BIBLIOGRAFIA .................................................................................................................... 42 SECCIÓN II: MANUAL TÉCNICO ANALISIS DEL SISTEMA ................................................................................................................. 47 1. DIAGRAMAS DE CASOS DE USO DEL SISTEMA .............................................................. 47 1.1 Caso de uso “Administración Carrito de la compra” ............................................................ 47 1.1.1 Subcaso de uso “Añadir Artículo” .............................................................................. 48 1.1.2 Subcaso de uso “Eliminar Artículo” ........................................................................... 49 1.1.3 Subcaso de uso “Editar Artículo” ............................................................................... 50 1.1.4 Subcaso de uso “Vaciar Carrito” ................................................................................ 50 1.1.5 Subcaso de uso “Ver Contenido”................................................................................ 51 1.2 Caso de uso “Administración de Categorías” ....................................................................... 51 1.2.1 Subcaso de uso “Editar Categoría” ............................................................................. 52 1.2.2 Subcaso de uso “Eliminar Categoría” ......................................................................... 53 1.2.3 Subcaso de uso “Añadir Categoría” ............................................................................ 54 1.2.4 Subcaso de uso “Consultar Categoría” ........................................................................ 54 1.3 Caso de uso “Administración de Clientes” ........................................................................... 55 1.3.1 Subcaso de uso “Editar Cliente” ................................................................................. 56 1.3.2 Subcaso de uso “Eliminar Cliente”.............................................................................. 57 1.3.3 Subcaso de uso “Añadir Cliente” ................................................................................ 57 1.3.4 Subcaso de uso “Consultar Clientes” .......................................................................... 58 1.4 Caso de uso “Administración de Direcciones” ...................................................................... 59 1.4.1 Subcaso de uso “Editar Direccion”.............................................................................. 60 1.4.2 Subcaso de uso “Eliminar Dirección” ......................................................................... 60 1.4.3 Subcaso de uso “Añadir Dirección” ............................................................................ 61 1.4.4 Subcaso de uso “Consultar Direcciones” .................................................................... 62 1.5 Caso de uso “Administración de Información” ..................................................................... 63 1.5.1 Subcaso de uso “Consultar Datos” .............................................................................. 64 1.5.2 Subcaso de uso “Editar Datos” .................................................................................... 64 1.6 Caso de uso “Administración de Marcas” ............................................................................. 65 1.6.1 Subcaso de uso “Editar Marca” ................................................................................... 66 1.6.2 Subcaso de uso “Eliminar Marca” ............................................................................... 67 1.6.3 Subcaso de uso “Añadir Marca” ................................................................................. 67 1.6.4 Subcaso de uso “Consultar Marcas” ............................................................................ 68 1.7 Caso de uso “Administración de Pedidos” ............................................................................ 69 1.7.1 Subcaso de uso “Editar Pedido” .................................................................................. 70 1.7.2 Subcaso de uso “Eliminar Pedido” .............................................................................. 70 1.7.3 Subcaso de uso “Consultar Pedido” ............................................................................ 71 1.8 Caso de uso “Administración de Productos” ......................................................................... 71 1.8.1 Subcaso de uso “Editar Producto” .............................................................................. 72 1.8.2 Subcaso de uso “Eliminar Producto” ........................................................................... 73 1.8.3 Subcaso de uso “Añadir Producto” ............................................................................. 74 1.8.4 Subcaso de uso “Consultar Productos” ....................................................................... 74 1.8.5 Subcaso de uso “Consultar Productos sin stock” ......................................................... 75 1.9 Caso de uso “Buscar Productos”........................................................................................... 75 1.10 Caso de uso “Consultar Productos” ...................................................................................... 76 1.10.1 Subcaso de uso “Consultar por Categoría” .................................................................. 77 1.10.2 Subcaso de uso “Consultar por Marca” ....................................................................... 78 1.11 Caso de uso “Desconectar” ................................................................................................... 79 1.12 Caso de uso “Iniciar sesión” ................................................................................................. 80 1.13 Caso de uso “Recordar Contraseña” ..................................................................................... 81 1.14 Caso de uso “Registrarse” ..................................................................................................... 82 1.15 Caso de uso “Realizar Pedido” ............................................................................................. 83 1.16 Caso de uso “Pagar” ............................................................................................................. 84 2. DIAGRAMAS DE INTERACCIÓN CONCEPTUALES .............................................................. 86 2.1 Escenario 1.1: “Añadir artículo al carrito de la compra” ....................................................... 86 2.2 Escenario 1.2: “Eliminar artículo del carrito de la compra” .................................................. 87 2.3 Escenario 1.3: “Editar artículo del carrito de la compra” ...................................................... 88 2.4 Escenario 1.4: “Vaciar artículo del carrito de la compra” ..................................................... 89 2.5 Escenario 1.5: “Ver contenido del carrito de la compra” ...................................................... 90 2.6 Escenario 2.1: “Editar categoría” .......................................................................................... 91 2.7 Escenario 2.2: “Eliminar categoría” ..................................................................................... 92 2.8 Escenario 2.3: “Añadir categoría” ........................................................................................ 93 2.9 Escenario 2.4: “Consultar categoría” .................................................................................... 94 2.10 Escenario 3.1: “Editar cliente” .............................................................................................. 95 2.11 Escenario 3.2: “Eliminar cliente” ......................................................................................... 96 2.12 Escenario 3.3: “Consultar cliente” ........................................................................................ 97 2.13 Escenario 4.1: “Editar dirección” ......................................................................................... 98 2.14 Escenario 4.2: “Eliminar dirección” ..................................................................................... 99 2.15 Escenario 4.3: “Añadir dirección” ...................................................................................... 100 2.16 Escenario 4.4: “Consultar dirección” ................................................................................. 101 2.17 Escenario 5.1: “Consultar datos” ........................................................................................ 102 2.18 Escenario 5.2: “Editar datos” ............................................................................................. 103 2.19 Escenario 6.1: “Editar marca” ............................................................................................ 104 2.20 Escenario 6.2: “Eliminar marca” ........................................................................................ 105 2.21 Escenario 6.3: “Añadir marca” ........................................................................................... 106 2.22 Escenario 6.4: “Consultar marca” ...................................................................................... 107 2.23 Escenario 7.1: “Editar pedido” ........................................................................................... 108 2.24 Escenario 7.2: “Eliminar pedido” ....................................................................................... 109 2.25 Escenario 7.3: “Consultar pedido” ..................................................................................... 110 2.26 Escenario 8.1: “Editar producto” ........................................................................................ 111 2.27 Escenario 8.2: “Eliminar producto” ................................................................................... 112 2.28 Escenario 8.3: “Añadir producto” ...................................................................................... 113 2.29 Escenario 8.4: “Consultar producto” .................................................................................. 114 2.30 Escenario 8.5: “Consultar productos sin stock” .................................................................. 115 2.31 Escenario 9: “Buscar producto” ......................................................................................... 116 2.32 Escenario 10: “Consultar productos” .................................................................................. 117 2.33 Escenario 10.1: “Consultar producto por categoría” .......................................................... 118 2.34 Escenario 10.2: “Consultar producto por marca” ............................................................... 119 2.35 Escenario 11: “Desconectar” .............................................................................................. 120 2.36 Escenario 12: “Iniciar sesión” ............................................................................................ 121 2.37 Escenario 13: “Recordar contraseña” ................................................................................. 122 2.38 Escenario 14: “Registrarse”................................................................................................ 123 2.39 Escenario 15: “Realizar pedido” ........................................................................................ 124 2.40 Escenario 16: “Pagar” ........................................................................................................ 125 3. DIAGRAMAS DE NAVEGABILIDAD..................................................................................... 126 3.1 Diagrama genérico ............................................................................................................. 126 3.2 Diagrama para un Usuario Registrado ................................................................................ 127 3.3 Diagrama para un Usuario Administrador .......................................................................... 127 3.4 Diagrama para Realizar Pedido .......................................................................................... 131 4. MODELADO DE DATOS ......................................................................................................... 132 4.1 Modelo Entidad-Relación .................................................................................................. 132 4.1.2 Entidades .................................................................................................................. 132 4.1.3 Relación entre las entidades ...................................................................................... 133 4.2 Modelo Relacional ............................................................................................................. 138 4.3 Consideraciones y Restricciones impuestas ....................................................................... 144 4.4 TABLAS DE LA BASE DE DATOS ................................................................................ 147 4.5 DICCIONARIO DE DATOS ............................................................................................. 149 4.6 DIAGRAMA DE CLASES ................................................................................................ 151 5. PRUEBAS DE SOFTWARE ...................................................................................................... 153 5.1 Login en la aplicación web................................................................................................. 153 5.2 Contacto ............................................................................................................................. 154 5.3 Detalle Producto ................................................................................................................ 155 5.4 Carrito ................................................................................................................................ 156 5.5 Recordar contraseña ........................................................................................................... 156 5.6 Buscar productos................................................................................................................ 157 5.7 Registro .............................................................................................................................. 157 5.8 Administración de usuario ................................................................................................. 160 5.8.1 Editar Dirección y Nueva Dirección ......................................................................... 160 5.8.2 Editar información .................................................................................................... 161 5.9 Administración del administrador....................................................................................... 164 5.9.1 Administración de productos .................................................................................... 164 5.9.2 Administración de marcas ......................................................................................... 165 5.9.3 Administración de Categorías ................................................................................... 166 5.9.4 Administración de productos con no stock ................................................................ 167 SECCIÓN III: MANUAL DE USUARIO MANUAL DE USUARIO ................................................................................................................... 171 1. Manual de Instalación ............................................................................................................... 171 1.1 Instalación de SQL Server 2008 R2 .................................................................................... 171 1.2 Instalación de Visual Studio 2010 Ultimate ........................................................................ 177 1.3 Crear base de datos ............................................................................................................. 182 1.4 Desplegar aplicación en IIS ................................................................................................ 184 2. Manual de la aplicación ............................................................................................................. 189 2.1 Inicio de la aplicación ......................................................................................................... 189 2.2 Alta de Usuario ................................................................................................................... 190 2.2.1 Login de Usuario ....................................................................................................... 190 2.2.2 Registro de Usuario ................................................................................................... 192 2.2.3 Recordar contraseña .................................................................................................. 196 2.3 Contacto ............................................................................................................................. 198 2.4 Búsqueda de productos ....................................................................................................... 199 2.5 Marcas ................................................................................................................................ 200 2.6 Categorías ........................................................................................................................... 202 2.7 Añadir productos al carrito de la compra ............................................................................ 205 2.7.1 Manera unitaria ......................................................................................................... 205 2.7.2 Mayor de uno ................................................................................................................. 207 2.8 Carrito de la compra ........................................................................................................... 208 2.8.1 Editar artículo del carrito de la compra ...................................................................... 208 2.8.2 Borrar artículo del carrito de la compra ..................................................................... 209 2.8.3 Vaciar el carrito de la compra ................................................................................... 211 2.9 Realizar pedido ................................................................................................................... 211 2.9.1 Selección de direcciones ........................................................................................... 212 2.9.2 Pago en PayPal .......................................................................................................... 214 2.9.2.1 Cancelación del pedido ............................................................................................. 214 2.9.2.2 Pago con cuenta Sandbox PayPal .............................................................................. 215 2.9.2.3 Pago con tarjeta ......................................................................................................... 216 2.10 Panel de administración para rol Usuario ........................................................................... 219 2.10.1 Pedidos ..................................................................................................................... 219 2.10.2 Direcciones ............................................................................................................... 220 2.10.2.1 Consultar direcciones ........................................................................................... 220 2.10.2.2 Editar una dirección ............................................................................................. 221 2.10.2.3 Añadir una dirección ........................................................................................... 221 2.10.2.4 Borrar una dirección ............................................................................................. 222 2.10.3 Información ............................................................................................................... 223 2.10.3.1 Consultar información .......................................................................................... 223 2.10.3.2 Editar Información ............................................................................................... 224 2.11 Panel de administración para el rol Administrador ............................................................. 225 2.11.1 Administración de productos .................................................................................... 226 2.11.1.1 Añadir un producto .............................................................................................. 227 2.11.1.2 Editar un producto ................................................................................................ 229 2.11.1.3 Borrado de un producto ........................................................................................ 230 2.11.2 Administración de marcas ......................................................................................... 230 2.11.2.1 Consultar una marca ............................................................................................ 230 2.11.2.2 Insertar una marca ................................................................................................ 231 2.11.2.3 Editar una marca .................................................................................................. 232 2.11.2.4 Borrado de una marca .......................................................................................... 233 2.11.3 Administración de categorías ................................................................................... 234 2.11.3.1 Consultar categorías ............................................................................................ 234 2.11.3.2 Insertar una categoría ........................................................................................... 235 2.11.3.3 Editar una categoría ............................................................................................. 235 2.11.3.4 Borrar una categoría ............................................................................................ 236 2.11.4 Administración de clientes ....................................................................................... 238 2.11.4.1 Consulta de clientes ............................................................................................. 238 2.11.4.2 Editar un cliente ................................................................................................... 238 2.11.4.3 Borrar un cliente .................................................................................................. 239 2.11.5 Administración de pedidos ....................................................................................... 239 2.11.5.1 Consulta de pedidos ............................................................................................. 239 2.11.5.2 Editar un pedido................................................................................................... 240 2.11.5.3 Borrar un pedido .................................................................................................. 241 2.11.6 Administración de productos con no stock ............................................................... 242 2.11.6.1 Editar un producto ............................................................................................... 242 2.11.6.2 Consulta de productos .......................................................................................... 243 2.11.6.3 Borrar un producto ............................................................................................... 243 2.12 Desconexión ...................................................................................................................... 244 Flavors of the States Fig 1. Arquitectura básica de 3 capas Se puede entender mejor esta estructura con la siguiente imagen, partiendo del concepto 3 capas, se tiene: Fig 2. Concepto de arquitectura 3 capas avanzada 18 SECCION I: MEMORIA DEL PROYECTO La capa de entidades es utilizada por las 3 capas (Presentación, Negocio y Acceso a datos). Fig 3. Uso de capa entidades por el resto de capas 5.2 ENTORNO DEL SISTEMA El entorno de desarrollo integrado (IDE) de Visual C# es un conjunto de herramientas de desarrollo expuestas a través de una interfaz de usuario común. Algunas de las herramientas se comparten con otros lenguajes de Visual Studio, y otras, como el compilador de C#, son únicas de Visual C#. Un IDE es un entorno de programación que ha sido empaquetado como un programa de aplicación; es decir, consiste en un editor de código, un compilador, un depurador y un constructor de interfaz gráfica (GUI). Los IDEs pueden ser aplicaciones por sí solas o pueden ser parte de aplicaciones existentes. Los IDE proveen un marco de trabajo amigable para la mayoría de los lenguajes de programación tales como C++, PHP,Python, Java, C#, Delphi, Visual Basic, etc. En algunos lenguajes, un IDE puede funcionar como un sistema en tiempo de ejecución, en donde se permite utilizar el lenguaje de programación en forma interactiva, sin necesidad de trabajo orientado a archivos de texto. En este caso, el IDE utilizado es Microsoft Visual Studio 2010 (como se describe en la siguiente sección). 6. TECNOLOGIAS EMPLEADAS Para el correcto desarrollo de nuestra página web, se han utilizado las siguientes herramientas. • HTML Acrónimo ingles de Hyper Text Markup Language (lenguaje de marcación de hipertexto), es un lenguaje informático diseñado para estructurar textos y presentarlos en forma de hipertexto, que es el formato estándar de las páginas Web. Es un lenguaje muy sencillo que a base de etiquetas nos permite presentar el texto de una manera ordenada y agradable, con enlaces que nos conducen a otros documentos o fuente de información relacionadas, y con inserciones multimedia. 19 Flavors of the States • JavaScript JAVA Script es un lenguaje interpretado, multiplataforma, orientado a eventos con manejo de objetos, cuyo código se incluye directamente en el mismo documento, usado para el desarrollo de aplicaciones cliente-servidor en paginas HTML. Esta tecnología permite dar respuesta a eventos iniciados por el usuario, tales como la entrada de un formulario o pinchar en un enlace. La verificación y validación de los datos de usuario se producen en el lado del cliente, no siendo necesario enviar ninguna información al servidor. Después de ser chequeadas, pueden ser enviadas al servidor. • jQuery jQuery es una biblioteca de JavaScript que permite simplificar la manera de interactuar con los documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar animaciones (FLV) y agregar interacción con la técnica AJAX a páginas web. jQuery es software libre y de código abierto y al igual que otras bibliotecas, ofrece una serie de funcionalidades basadas en JavaScript que de otra manera requerirían de mucho más código, es decir, con las funciones propias de esta biblioteca se logran grandes resultados en menos tiempo y espacio. jQuery consiste en un único fichero JavaScript que contiene las funcionalidades comunes de DOM, eventos, efectos y AJAX. La característica principal de la biblioteca es que permite cambiar el contenido de una página web sin necesidad de recargarla, mediante la manipulación del árbol DOM y peticiones AJAX. • C# C# es el lenguaje orientado a objetos diseñado por Microsoft para su plataforma .Net Combina los mejores elementos de lenguajes como C++, Java, Visual Basic o Delphi. Aunque es posible escribir código para la plataforma .Net en muchos otros lenguajes, C# es el único que ha sido específicamente diseñado para ser utilizado en ella, por lo que programarla usando C# es mas sencillo e intuitivo que hacerlo con cualquier otro. Se le considera así, el lenguaje nativo de .N et poseyendo el compilador mas depurado y optimizado del .net Framework SDK. Reduce problemas de legibilidad de código y conflicto de nombres, no admitiendo que ni funciones ni variables globales sean declaradas y todo el código debe definirse en definiciones de tipos de datos. Soporta todas las características propias del paradigma de programación orientada a objetos como la encapsulación, herencia y polimorfismo. Es orientada a componentes, incluyendo elementos propios del diseño de componentes, es decir, lo que en otros lenguajes serían construcciones complejas solo serían propiedades, eventos o atributos. Tiene gestión automática de memoria y un sistema de tipos unificado donde todos los tipos de dato derivan de una clase base común llamada System.Object. Comparando C# con PHP, se podría decir que son lenguajes bastante diferentes y dos de los mas usados para la implementación de páginas web. Mientras que C# es un lenguaje optimizado y compilado para Windows y PHP es un lenguaje interpretativo y multiplataforma. Se dice que en principio un lenguaje compilado es más rápido que un leguaje interpretativo, pero personalmente la razón por la que el proyecto se haya encaminado con C# es que resulta un lenguaje mucho mas intuitivo y limpio que PHP, además de que ya partía con cierto conocimiento de C#, cosa que no era así con PHP. 20 SECCION I: MEMORIA DEL PROYECTO o Herramienta utilizada: Microsoft Visual Studio 2010 Ultimate Microsoft Visual Studio es un entorno de desarrollo integrado (IDE, por sus siglas en inglés) para sistemas operativos Windows. Soporta varios lenguajes de programación tales como Visual C++, Visual C#, Visual J#, y Visual Basic .NET, al igual que entornos de desarrollo web como ASP.NET. aunque actualmente se han desarrollado las extensiones necesarias para muchos otros. Visual Studio permite a los desarrolladores crear aplicaciones, sitios y aplicaciones web, así como servicios web en cualquier entorno que soporte la plataforma .NET (a partir de la versión .NET 2002). Así se pueden crear aplicaciones que se intercomuniquen entre estaciones de trabajo, páginas web y dispositivos móviles. En concreto la versión utilizada en este proyecto es la Ultimate, aunque no es necesaria dicha versión para implementar la página web. Visual Studio 2010 Ultimate: Conjunto completo de herramientas de gestión del ciclo de vida de una aplicación para los equipos que garantizan unos resultados de calidad, desde el diseño hasta la implementación. Ya sea creando nuevas soluciones o mejorando las aplicaciones existentes, Visual Studio 2010 Ultimate le permite llevar sus ideas a la vida en un número creciente de plataformas y tecnologías - incluyendo la nube y la computación paralela. • Smartsheet Es una aplicación web gratuita con la que poder gestionar las planificaciones en tiempo y desarrollar los diagramas de Gantt de forma sencilla, de nuestro proyecto. • SQL El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos normalizado, utilizado por los diferentes motores de bases de datos para realizar determinadas operaciones sobre los datos o sobre la estructura de los mismos. o Herramienta utilizada: Microsoft SQL Server 2008 R2  Es un sistema de administración de datos eficaz y confiable que ofrece un variado conjunto de características, protección de datos y rendimiento para aplicaciones embebidas, sitios web ligeros y almacenes de datos locales. Está basado en el modelo relacional. • StarUML StarUML es un proyecto de código abierto para desarrollar UML de una manera rápida, flexible, extensible, característica y disponible de manera gratuita. Cabe decir que UML es un... Lenguaje Unificado de Modelado (Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados. Se ha utilizado para hacer todos los diagramas UML del proyecto. 21 Flavors of the States • Adobe PhotoShop CS5 Portable Es un programa utilizado para armar, editar, componer, retocar y transformar imágenes. Su gran facilidad para crear y manejar distintas capas superpuestas, permite combinar distintos objetos y efectos sin necesidad de modificar la imagen original como una superposición de transparencia, podemos corregir la imagen completa o parte de ella. En concreto, para este proyecto ha sido útil para poder realizar la cabecera de la página. • Entorno de desarrollo IDE (Entorno de desarrollo integrado o Entorno de desarrollo interactivo) es una aplicación informática que provee de facilidades que abarcan el desarrollo de software para los programadores. Normalmente, un IDE consta de un editor de código, compilador y debugueador. Algunos de ellos contienen aspectos de Intelli-sense (es la aplicación de autocompletar, mejor conocido por su utilización en Microsoft Visual Studio entorno de desarrollo integrado. Además de completar el símbolo de los nombres que el programador está escribiendo, IntelliSense sirve como documentación y desambiguación de los nombres de variables, funciones y métodos de utilización de metadatos basados en la reflexión). En este caso, el entorno de desarrollo o IDE utilizado es el propio Visual Studio 2010. • Microsoft Word Microsoft Word es un software destinado al procesamiento de textos. Fue creado por la empresa Microsoft, y actualmente viene integrado en la suite ofimática Microsoft Office Se ha utilizado para escribir la memoria del proyecto. 7. METODOLOGIA EMPLEADA La Metodología de desarrollo de software en ingeniería de software es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información. A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose por su fortaleza y debilidad. Para este proyecto, la primera opción que se barajó fue el uso del conocido ciclo de vida en cascada ya que es el más intuitivo y mas utilizado, aunque quizá no el más efectivo. El modelo en cascada, uno de los primeros modelos de desarrollo de software que considera las diferentes actividades como fases separadas de tal forma que para iniciar una nueva actividad debe esperarse a la finalización de la actividad anterior. Repasando sus cualidades se observó que ofrece más desventajas que ventajas: • Ventajas o Modelo sencillo y disciplinado. o Fácil de aprender y a utilizar y comprender su funcionamiento. o Ayuda a detectar errores en las primeras fases a bajo coste. o Minimiza gastos de planificación, ya que se realiza correctamente y sin problemas. 22 SECCION I: MEMORIA DEL PROYECTO • Desventajas o Necesidad de tener todos los requisitos al principio ya que lo normal es que el cliente no tenga perfectamente definidas las especificaciones surgiendo nuevos requisitos a lo largo de las diferentes etapas de desarrollo. Según este modelo hay que tener TODOS los requisitos en la primera etapa no pudiéndose llevar a cabo los requisitos que surjan una vez acabada la etapa de especificación. o Es normal cometer errores en alguna de las etapas del proceso de desarrollo. Según este modelo cada vez que se identifique algún error cometido hay que volver a la etapa anterior y rehacer el trabajo. o Los resultados y/o mejoras no son visibles progresivamente, el producto se ve cuando ya está finalizado, lo cual provoca una gran inseguridad por parte del cliente que quiere ir viendo los avances en el producto. Dado que dicho modelo no se ajustaba a la forma de desarrollar el proyecto, y tras ver que el modelo de prototipo tampoco se ajustaba exactamente (ya que el desarrollo no se ha basado en una retroalimentación a través del cliente, al cual se le hayan dado entregables parciales), finalmente se optó por tomar el ciclo de vida en cascada retroalimentada. No es más que una variante del ciclo de vida en cascada. Fig 4. Modelo en cascada retroalimentado 23 Flavors of the States Las ventajas que ofrece el ciclo de vida en cascada retroalimentada son: • Ofrece la oportunidad de realizar cambios o evoluciones durante el ciclo de vida del Software. • Permite retroceder de una etapa a la anterior o incluso poder saltar a otras anteriores si es requerido. • No se tiene en cuenta la naturaleza evolutiva del software, se plantea como estático con requisitos bien conocidos y definidos desde el inicio. Las desventajas que tiene son las siguientes: • No conocer si la solución es correcta hasta estar cerca de su lanzamiento. • Hay poco tiempo para la resolución de fallos y tiene una depuración complicada. • No es muy frecuente que el cliente o usuario final explicite clara y completamente los requisitos. • Es posible que el cliente detecte algún error y debe ser paciente con el proceso. • Es sencilla y facilita la gestión de un proyecto. Estas son las etapas de un proyecto:  Ingeniería y Análisis del Sistema (Pre-Análisis)  Esta fase consiste en conocer las reglas del negocio, sus necesidades y adquirir conocimiento acerca de las funciones propias del modelo de negocio.  Lo que en este proyecto concordaría con los siguientes puntos:  Estudio de páginas similares • Donde se hará un recorrido por páginas web que suministren un servicio similar y de las que se obtendrán ideas o esquemas de lo que se espera de herramientas de compra on-line como la que implementaremos.  Tecnologías a aplicar • En este tema se tendrá que decidir por qué IDE y lenguaje de programación puede satisfacer más las necesidades tanto del cliente como del desarrollador. • En este caso, por temas personales del desarrollador teniendo experiencia en este IDE, por la claridad en el desarrollo y por otros aspectos, se llegó a la confirmación de utilizar Visual Studio 2010 C# frente al archiconocido PHP.  Análisis de Requisitos  La fase de Análisis es directamente abordar la colección de necesidades identificadas en el pre-análisis y en base a ella proponer una solución, teniendo en cuenta la viabilidad tanto a nivel técnico como a nivel administrativo. ¿Qué se va a hacer?  Será necesario hacer un diagrama Entidad-Relación y los Requerimientos estarán en el documento de ‘Especificación de Requerimientos del Sistema’ o ERS.  Es la primera fase real de la consecución de un proyecto donde se extraen los requisitos y requerimientos, donde el cliente da el comportamiento y funcionalidad que se espera de esa página web. 24 SECCION I: MEMORIA DEL PROYECTO  En este caso, no hay cliente físico y ha sido el mismo desarrollador el que ha establecido dichos requisitos y requerimientos, considerando que es lo fundamental para que la página web ofrezca lo que se ofrece en el mercado eCommerce, y además de una manera eficaz e intuitivo.  Diseño  La fase de diseño consiste en detallar la solución al problema que se ha identificado, es decir, se debe estructurar a nivel aplicación, red y base de datos como se va a abordar la solución, en el diseño se debe apoyar de diagramas de entidad relación para la bbdd, diagramas de clases entre otros. ¿cómo se va a hacer?  Dar una arquitectura a nuestro proyecto significa dotar a nuestra página web de unos componentes o entidades, y tras ello mostrar la interacción entre dichos componentes y validación por medio de diagramas de interacción.  Algunos ejemplos de diagramas necesarios serían: • Diagrama de clases • Diagrama de base de datos • Diagrama de secuencia • Diagrama de estados  En este proyecto, se dotará con diagramas de clases, base de datos y secuencia.  Toda la parte de UML será implementado con la herramienta, StarUML.  La parte de diseño de base de datos, se hará con la herramienta DB Designer 4.0.  Codificación  La fase de desarrollo es llevar a acciones el diseño que se ha elaborado previamente, es decir, se toma como ayuda un lenguaje de programación y de los software existentes para elaborar la aplicación que dará solución al problema identificado inicialmente.  En este proyecto, la codificación se llevará a cabo con ASP.Net, con su lenguaje nativo C# en su IDE Visual Studio 2010.  Dicha codificación se verá complementada por la adicción de código JavaScript y jQuery.  Pruebas  La fase de Pruebas consiste en una vez terminada la aplicación y su bbdd, teniendo el producto terminado se debe probar tanto a nivel individual como a nivel integrado y de esta manera se sabrá si la solución creada soluciona las necesidades planteadas al inicio del proceso de desarrollo.  Dichas pruebas tienen que ser realizadas por usuarios que no hayan participado en la codificación del proyecto y que no vayan directamente a probar cosas en concreto, sino que desde el desconocimiento de la funcionalidad de la página web, muchas veces se encuentran errores que no podrían ser detectados por las pruebas unitarias de la persona que codifica.  Serán necesarias pruebas unitarias de cada módulo o sección de la página web, como de ciclos enteros de pruebas que hagan que el ensamblado total de la aplicación funcione de la manera que se requiere. 25 Flavors of the States  Mantenimiento  Aquí se aborda todo lo referente al mantenimiento de la web, donde se puede hacer cambios en los requisitos establecidos al principio, desajustes en funcionalidades ya implementadas...en general cualquier tema que haga que la página web no trabaje como debiera, o cualquier cosa que el usuario final decida que es necesario cambiar, mejorar o hacer de nuevo.  Es más general y normal, hoy en día, dar mantenimiento a una aplicación que crear nuevas aplicaciones. 8. PLANIFICACION En esta sección se hará una comparativa entre la planificación inicial que se hizo para la consecución del proyecto y por otro lado la planificación real que mostrará como fue en realidad ese desarrollo del proyecto en todas y cada una de sus partes. La planificación ha sido detallada con las siguientes fases de trabajo: I. Estudio preliminar a. Estudio de páginas webs similares b. Tecnologías a aplicar II. Análisis a. Estudio del problema b. Captura de Requerimientos c. Análisis de Requerimientos d. Identificación de tareas III. Diseño a. Modelado de clases b. Creación de base de datos IV. Implementación a. Implementación de Código b. Gráficos V. Realización de Pruebas VI. Documentación a. Memoria del proyecto b. Manual Técnico c. Manual de Usuario 26 SECCION I: MEMORIA DEL PROYECTO 8.1 PLANIFICACIÓN INICIAL Fig 5. Planificación Inicial Fig 6. Diagrama de Gantt para la planificación inicial 1 27 Flavors of the States 9.2 COSTE DE HARDWARE En esta subsección se puede ver los gastos en hardware, donde básicamente se ha utilizado un único ordenador portátil y un dispositivo de almacenamiento externo. DISPOSITIVO HARDWARE EMPLEADO COSTE USO COSTE REAL Portátil Clónico 850 € 15% 127.50 € CPU Intel Core 2 duo T7500 RAM 4 GB Disco Duro 500 GB Tarjeta Gráfica Integrada Sistema Operativo Windows XP Almacenamiento Externo Pendrive 32 GB 24 € 15% 3.60 € TOTAL 131.10 € Fig 15. Tabla representativa de costes de Hardware 9.3 COSTE DEL SOFTWARE En esta apartado, se tienen los gastos ocasionados por el Software utilizado. HERRAMIENTA COSTE DESCRIPCION USO COSTE REAL Windows XP 0 Sistema Operativo (Incluido en portátil) 15% 0 Microsoft Word 2003 0 Editor de texto (Incluido en portátil) 15% 0 StarUML 0 Modelado UML 15% 0 Acrobat Reader 0 Lector de archivos PDF 15% 0 Smartsheet 0 Gestión de tiempos para proyectos 15% 0 DB Designer 0 Modelado de bases de datos 15% 0 Visual Studio 2010 Proffessional 630 € IDE .Net 15% 94.5 SQL Server 2008 R2 0 Gestor de BBDD 15% 0 Mozilla Firefox 0 Navegador Web 15% 0 Google Chrome 0 Navegador Web 15% 0 Adobe Photoshop CS5 879 € Diseño Gráfico 15% 131.85 TOTAL 226.35 € Fig 16. Tabla representativa de costes totales de Software 9.4 COSTES TOTALES DE LA PÁGINA WEB DESCRIPCION COSTE Coste RRHH 6,430 € Coste HW 131.10 € Coste SW 226.35 € TOTAL 6,787.45 € Fig 17. Tabla representativa de costes totales del proyecto 34 SECCION I: MEMORIA DEL PROYECTO 10. CONSIDERACIONES 10.1 DISEÑO 10.1.1 Carrito de la compra Cuando se hizo el diseño de las clases y la base de datos, se invirtió tiempo en como enfocar el tema del carrito de la compra en la página web. En principio habría dos opciones: - Crear una tabla Carrito, donde cada cierto tiempo, o en el momento que el usuario actualizase el carrito, se insertara en base de datos y se mantuviese actualizado. o La única ventaja de esta opción, bajo mi punto de vista, es que cuando el usuario se logase en la página, actualizase su carrito y abandonase la página sin realizar ningún pedido, cuando se volviera a logar, tendría de nuevo esos artículos persistentes en su carrito y no tendría que volver a agregar dichos artículos. o Las desventajas, es que habría un constante ataque a base de datos para actualizar datos en el carrito y que realmente, desde mi punto de vista, no tiene sentido guardar esta información en tablas. - Guardar el carrito en sesión. o De esta manera, no se ataca a base de datos constantemente. o No es necesario por tanto, crear ninguna tabla en base de datos ni ningún mantenimiento. o En la mayoría de las páginas web existentes, los carritos de la compra se guardan de esa manera, en el tiempo que la sesión dure antes de que caduque. o Mientras que la sesión dure hasta que se haga el pedido (si es que se hace), las modificaciones se harán en sesión. o Sólo cuando el cliente realice el pedido, se usarán esos datos del carrito de la compra para insertarlos en base de datos, en concreto en la tabla de Pedidos y de DetallePedido. Es la mejor opción por tanto, en cuestión de tiempos, accesibilidad y comodidad a la hora de desarrollar código, por lo que fue la opción escogida. 10.1.2 Arquitectura de la aplicación La estructura usada para nuestra arquitectura sería N-Capas, en este caso, 4 capas: - Interfaz de Usuario o En este caso, esto será todas y cada una de las páginas *.aspx y todos los controles de usuario *.ascx existentes en el proyecto. o Son los encargados de mostrar al usuario de manera gráfica, todo lo que se maneja por detrás. 35 Flavors of the States - Lógica de Negocio o Esta capa es la que contiene la lógica de la página. o Tendrá unos procedimientos que son llamados desde el Interfaz de Usuario y que recibirán también como parámetro, esos objetos tipos Entidad creados. o Estos procedimientos llamarán a su vez a la capa de datos, sin saber qué es lo que hace esa capa de datos. - Acceso a Datos o Esta capa es la que accede directamente a Base de datos, extrayendo la información necesaria en base de datos, CRUD (Create, Read, Update, Delete). - Entidades o Contiene todas las entidades que se utilizan en el proyecto (Productos, Categorías, Marcas…) o Serán los objetos que serán creados en la Interfaz de Usuario y se mandarán como parámetros a la capa de negocio. o Llamada también BEL, o Business Entity Layer. o Contiene la estructura de la entidad, con sus get y set de atributos. 10.1.3 Productos, Marcas y Categorías En este aspecto, es importante reseñar lo siguiente: - El modelo relacional creado, relaciona estas tres tablas (Productos, Marcas y Categorías), por lo que hay tareas que el administrador ‘no puede hacer’ en primera instancia, como es: o Eliminar una categoría que tiene productos asociados. o Eliminar una marca que tiene productos asociados. Para ambos casos, el usuario recibirá un mensaje en una ventana pop-up en el que se le dirá que no es posible hacer esa operación y que es necesario que los productos asociados a esa categoría o marca, sean actualizados a otra categoría o marca existente y una vez hecho esto, se podrá eliminar. 10.2 IMPLEMENTACIÓN 10.2.1 Métodos de pago Para ésta página web, dado los tiempos que se tenían para desarrollar el proyecto y la complejidad de implantación de métodos de pago reales y/o dificultades para cumplir los requisitos de implantación, únicamente se ha implantado el método de pago con PayPal, que incluye el pago con tarjeta pero sin pasarela propia del banco asociado. PayPal ofrece algo muy atractivo para los desarrolladores, ya que permite probar y ver cómo va a funcionar exactamente dicho método de pago sin realizar ninguna transacción económica real. Lo que ofrece PayPal es un duplicado exacto del sitio activo PayPal, llamado Sandbox y que la única diferencia respecto a PayPal es que es un entorno de pruebas y que no hay transacciones reales, donde el dinero pase de unas manos a otras. Este entorno de pruebas permite probar toda la integración antes de enviar transacciones al entorno activo de PayPal. Y puedes crear y administrar cuentas de prueba, en el que se asignarán cuentas de 36 SECCION I: MEMORIA DEL PROYECTO banco y tarjetas de crédito ficticias asociadas a la página web y con las que se puede chequear todo detalle del pago con PayPal o con tarjeta de crédito a través de PayPal. Cuando se finaliza el pago desde la página web, se hace la redirección hacia Sandbox PayPal donde se puede ver el detalle del pedido que el cliente va a realizar ya que contiene el detalle del carrito de la compra, con las unidades, precio unitario, precio total y se pide cuenta de Sandbox para poder realizar el pedido. Fig 18. Pago con Paypal Una vez pagado, haciendo clic en un enlace, se va a redireccionar de nuevo a la página web donde dependiendo del éxito o fracaso del pago, se mostrará un mensaje de confirmación de compra o de fallo en la compra. Éste método de pago ofrece exactamente lo mismo que PayPal y da clara muestra de cómo va a funcionar PayPal cuando se quiera implementar. El único cambio que sería necesario para actualizar de Sandbox PayPal a PayPal, sería cambiar únicamente la web de conexión. Actualmente se conecta a : https://www.sandbox.paypal.com/us/cgi-bin/webscr? Habría que conectar simplemente hacia PayPal directamente: https://www.paypal.com/us/cgi-bin/webscr? Con este simple cambio, y obviamente usando una cuenta de PayPal existente y real (ya que las cuentas creadas en Sandbox son para pruebas y ficticias) se podría apuntar directamente a PayPal de manera real y todo debería funcionar de igual manera que lo está haciendo ahora mismo con Sandbox. 37 Flavors of the States 11. AMPLIACIONES En esta sección, se explicará cuales podrían ser las futuras ampliaciones de dicha página web, que como toda página web, aplicación o software, siempre queda una puerta abierta a la posibilidad de mejorarlas o de hacerlas más completas. 11.1 GESTION DE PROVEEDORES Esta sección podría ser una parte a añadir a la aplicación web, en la que se podría saber desde la página de administración del usuario Administrador, saber a qué proveedores hace falta hacer un pedido de determinados productos cuando no haya stock. Actualmente, sólo se le muestra al Administrador cuáles son los productos sin stock, pero se podrían agrupar por Proveedor y darle un detalle más claro y conciso que le ayudase en su labor administrativa. 11.2 GESTIÓN DE CONTABILIDAD Esta idea abarcaría el darle la posibilidad al Administrador de tener unos informes en los que se reflejen la actividad económica de la página web. En ella, se haría reflejo por semana, mes o año, los beneficios finales marcados por las ventas de productos a clientes menos la suma pagada a proveedores para tener productos en stock. Daría una idea de contabilidad general de la página ya que actualmente no hay nada, que de un resultado de ventas que de al administrador fuentes para hacer un estudio de acercamiento al cliente. 11.3 PAGO CON TARJETA Como para toda aplicación eCommerce, es necesario tener unas transacciones reales entre cliente y aplicación web para cerrar el ciclo de compra-venta on-line. Tal y como ésta página web únicamente va a estar publicada en el servidor localhost, no es posible desarrollar un módulo real con métodos de pago, donde haya una transacción real de una tarjeta de crédito a nuestra cuenta asociada a la tienda on-line, sino que todo será de manera ficticia. Una mejora en este aspecto, sería montar dicha pasarela para hacer un pago mediante tarjeta de crédito/debito, que no sea la propia que ofrece PayPal a clientes de la página web que no tengan una cuenta PayPal creada y operativa (que es la opción que actualmente está implementada). Ésta mejora es bastante opcional, ya que éste sitio eCommerce puede ser totalmente funcional sin tener una pasarela de pago con banco, sino que simplemente es completamente suficiente lo que ofrece en su caso PayPal. PayPal ofrece para ello, elegir un método de pago, sea PayPal o pago con tarjeta de crédito (Visa, MasterCard o American Express) Este método de pago virtual mediante tarjeta se haría a través de una plataforma que haría un procesamiento de esas tarjetas desde Internet conectándose a las redes privadas de los sistemas que se quisiera dar como opciones de pago (VISA, MasterCard, American Express…). Este método permitiría a los clientes realizar compras utilizando su tarjeta y dichas operaciones se validarían en línea. 38 SECCION I: MEMORIA DEL PROYECTO Estos serían los pasos a seguir: - Una vez que el cliente tenga preparado su carrito de la compra con todos los artículos de su pedido, al finalizar el pedido se le preguntaría con qué método prefiere pagar. - La página web redirigiría al servidor seguro del banco contratado y TPV del banco, la cantidad a cobrar para finalizar el pedido. - El cliente introduciría sus datos, como número de tarjeta, fecha de expiración de la tarjeta y su número secreto. Todo ello iría al servidor del banco y se procesaría la petición. - El dinero quedaría substraído de la cuenta del cliente e ingresado en la cuenta asociada a nuestra página web y a nuestro TPV. - Tras un pago satisfactorio o no, devolvería el control a nuestra página web donde se tramitará dicha respuesta de manera conveniente en nuestra base de datos. Para ésta página web se intentó implementar dicha solución pero para ello hay que cumplir numerosos requisitos y también conlleva una gran complejidad en cuanto a la codificación. Algunos de los requisitos que conlleva son: - Que la página web exista, es decir, tenga un dominio asociado, un host en el que esté alojada. - Tras ello tiene que haber un contrato ente comerciante y banco al que se quiera asociar ésta forma de pago, contratando así un TPV virtual (Terminal de punto de venta). - Dicho TPV virtual tendrá un costo inicial, una coste de mantenimiento y una comisión por transacción y dependiendo del volumen de venta. Dado que todo esto no era posible, se optó por otras opciones como un método de pago TPV virtual ficticio por medio de compañías como DataCash. DataCash es parte de MasterCard, y es una compañía de procesamiento de pagos que ofrece una forma de pago global y multicanal para asegurar que no hay fraude o riesgo en el manejo de servicios de pago on-line. Dicha compañía, ofrece una versión ficticia (al igual que PayPal) para simular esos pagos mediante tarjeta de crédito antes de implementarlos en nuestra página web. Finalmente, no se pudo implementar dado que no se aceptan páginas web que no estén alojadas en un host, y porque por su complejidad de implantación, conllevaría un coste en tiempo que dada la planificación del proyecto, es inviable. Con todos estos inconvenientes que se encontraron durante el desarrollo, la única solución viable fue la implementación de todo el sistema de pago de PayPal que ofrece ambas cosas, pago con PayPal (si tienes cuenta operativa) y a través de tarjeta de crédito (si no tienes cuenta operativa PayPal). 39 Flavors of the States Fig 19. Representa la manera alternativa dada por PayPal de pago con tarjeta de crédito 11.4 GESTION DE OFERTAS Cabría la posibilidad de hacer un servicio de ofertas que se encargaría de mandar un correo con ofertas personalizadas a los clientes, dependiendo de los productos que esos clientes compran normalmente. Para ello también sería necesario tener una parte de administración para el usuario, donde quede registrado de alguna manera un estudio de las categorías o las marcas que mas compra ese determinado usuario. De igual manera, para todos los usuarios en general, podría haber una sección de ofertas sin tener ningún tipo de personalización en clientes. 11.5 GESTION DE ELIMINACIÓN DE CATEGORIAS O MARCAS Una mejora respecto a la eliminación de categorías o marcas, es que, cuando se intente eliminar una categoría o marca con productos asociados, en vez de simplemente mostrar al usuario un mensaje indicando que no es posible eliminarlos hasta que se actualicen los productos a otras marcas o categorías, que haga lo siguiente: - Mostrar una ventana pop-up con un grid en el que salgan todos los productos afectados por esa eliminación y se pueda actualizar a otra marca o categoría en ese mismo momento, y tras ello esa categoría o marca pueda ser eliminada. 40 SECCION I: MEMORIA DEL PROYECTO 11.6 FACTURAS Este apartado trata acerca de las facturas hechas para los pedidos que los clientes puedan realizar en la página web. Lo que la página web ofrece ahora mismo, es mandar un correo a la dirección electrónica del usuario con todo el detalle del pedido que se acaba de hacer, que es básicamente una factura pero sin el formato de una factura formal. La mayoría de los sitios web actuales, simplemente mandan un correo electrónico dando el detalle del pedido, pero una posible ampliación podría ser precisamente esto, hacer un apartado que pusiera los mismos detalles del pedido en una plantilla en vez de un email, y que lo exportase a pdf. Cuando se hace un pedido, se piden dos direcciones, la de envío y la de facturación, que pueden ser la misma o no. La aplicación estaría ya preparada para que se le añadiese dicha funcionalidad ya que se tiene todo lo necesario, detalles del pedido y dirección de facturación. Al igual que el pedido (si fuese una página web real) sería enviado a la dirección de envío, la factura sería enviada a la dirección de facturación. Actualmente, la web no hace nada realmente con esa dirección de facturación, únicamente deja todo detallado de manera histórica para los pedidos realizados. 12. CONCLUSIONES El proyecto realizado representa la síntesis de los conocimientos que el desarrollador adquirió en la Universidad en su momento y de la experiencia que ha adquirido en su vida profesional. A pesar de ello, Flavors of the States ha sido la primera aplicación web completa que el desarrollador ha hecho y ha servido para enfrentarse a todas las fases de un proyecto, cosa que en su vida profesional no ha sucedido, ya que en la vida real cuando trabajas para una compañía, tu dedicación (dependiendo de tu categoría) queda relegada a una determinada área, sea diseño o codificación y no a todas las fases que un proyecto puede tener. Ha servido para darse cuenta cómo de importante es un buen análisis y diseño de la aplicación, antes de ponerse a codificar directamente sin analizar todo de la mejor manera y viendo ventajas e inconvenientes. Ya que un mal análisis de un requisito, o un mal diseño de clases o de base de datos puede convertirse en un quebradero de cabeza de grandes dimensiones cuando se descubre un error en esas partes cuando el proyecto puede estar ya bastante avanzado. Todo ello puede suponer un gran cambio en el coste del desarrollo y en los tiempos de entrega, con lo que quizá en mi caso, hubiera sido interesante hacer un análisis más extenso inicialmente para evitar algunos de los problemas que se han podido encontrar durante la codificación del proyecto. 41 Flavors of the States 13. BIBLIOGRAFIA Paginas de apoyo para el desarrollo de la página web http://msdn.microsoft.com/ http://www.dotnetspider.com/ http://www.c-sharpcorner.com/ http://www.codeproject.com http://www.asp.net/ http://net.tutsplus.com/ http://support.microsoft.com Métodos de pago https://developer.paypal.com www.datacash.com jQuery https://developer.paypal.com Otras páginas a las que he recurrido http://stackoverflow.com http://www.free-css.com/ http://www.w3schools.com http://v4.aspnettutorials.com/ Webs similares http://www.myamericanmarket.com/ 42 Flavors of the States 1.1.3 Subcaso de uso “Editar Artículo”  Objetivo Permitir al usuario poder editar la cantidad del artículo en concreto perteneciente al carrito de la compra.  Actor Usuario no registrado Usuario Registrado  Flujo de Eventos principal 1. El cliente hace clic en el icono de editar articulo 2. La aplicación lo pone al estado de edición. 3. El usuario introduce la cantidad de artículos que quiera. 4. La aplicación lo actualiza.  Flujo de Eventos alternativo 2..4 .. Cancelar el proceso.  Flujo de Eventos excepcional 1..4 <Fallo de conexión>  Escenarios o Editar Artículo 1.1.4 Subcaso de uso “Vaciar C arrito”  Objetivo Permitir al usuario poder vaciar el carrito de forma rápida y en una sola acción, sin tener que ir uno a uno eliminando los artículos.  Actor Usuario no registrado Usuario Registrado  Flujo de Eventos principal 1. El usuario solicita el vacío del carrito de la compra haciendo clic en el icono. 2. La aplicación pide confirmación para realizar el vacío del carrito. 3. El usuario confirma. 4. La aplicación elimina todos los artículos del carrito y actualiza. 50 SECCIÓN II: MANUAL TÉCNICO  Flujo de Eventos alternativo 2 <Cancelar Proceso>  Flujo de Eventos excepcional 1..4 <Fallo de conexión>  Escenarios o Vaciar carrito de la compra 1.1.5 Subcaso de uso “Ver Contenido”  Objetivo Permitir al usuario ver el contenido del carrito con todos los artículos existentes.  Actor Usuario no registrado Usuario Registrado  Flujo de Eventos principal 1. El usuario solicita ver el contenido del carrito, mediante un clic en ‘Mi cesta’. 2. La aplicación muestra el contenido del carrito.  Flujo de Eventos excepcional 1..2 <Fallo de conexión>  Escenarios o Ver Contenido 1.2 Caso de uso “Administración de Categorías”  Objetivo Permitir al usuario, registrado o no, que pueda realizar las operaciones básicas para la administración de categorías de productos, tales como: creación, modificación, borrado y consulta.  Actor Administrador 51 Flavors of the States  Flujo de evento principal El administrador accederá a la administración de categorías a través de su cuenta personal, en la que podrá desarrollar las siguientes actividades: • Editarlos datos de una categoría existente • Eliminar una categoría del sistema • Añadir una categoría nueva al sistema • Consultar los datos relativos a cualquiera de las categorías. Este caso de uso, es un caso de uso abstracto que define el conjunto de todas las operaciones posibles con las categorías y que serán definidas más en detalle en los subcasos de uso correspondientes. Fig 1.2. Diagrama caso de uso ‘Administración de las categorías’ 1.2.1 Subcaso de uso “Editar Categoría”  Objetivo Permitir al usuario administrador, modificar los datos pertenecientes a una de las categorías de las existentes.  Actor Usuario administrador  Flujo de Eventos principal 1. El usuario solicita la modificación de una de las categorías existentes. 2. La aplicación web actualiza la página y muestra los datos de dicha categoría en modo edición. 3. El usuario introduce los datos y hace clic en el botón de actualizar. 52 SECCIÓN II: MANUAL TÉCNICO 4. La aplicación web recoge los datos y los valida. Tras ello, actualiza dicha categoría y muestra un mensaje de confirmación por pantalla.  Flujo de Eventos alternativo 2..4 <Cancelación del proceso> El usuario puede cancelar el proceso de actualización de una categoría mediante un clic en el botón ‘Cancelar’.  Flujo de Eventos excepcional 1..4 <Fallo de conexión> 4 <Datos introducidos incorrectos>, si los datos a introducir en la categoría, no son correctos o son vacíos, la aplicación web mostrará un mensaje.  Escenarios Editar Categoría. 1.2.2 Subcaso de uso “Eliminar Categoría”  Objetivo Permitir al usuario administrador, poder eliminar una de las categorías ya existentes en el listado.  Actor Usuario administrador  Flujo de Eventos principal 1. El usuario solicita la eliminación de la categoría mediante un clic en el botón ‘Eliminar’. 2. La aplicación web pide confirmación de eliminación. 3. El usuario confirma la eliminación. 4. La aplicación web elimina la categoría y muestra un mensaje de confirmación de eliminación por pantalla.  Flujo de Eventos alternativo 3 <Cancelación del proceso> El usuario puede cancelar el proceso cuando la aplicación pide confirmación de borrado, y no se seguirá con el proceso. 3..4 <Categoría con productos> Si la categoría a eliminar, tiene productos asignados, la aplicación web mostrará un mensaje informativo en el que se dirá al usuario que no es posible eliminar dicha categoría hasta que los productos asociados sean asignados a otra categoría existente.  Flujo de Eventos excepcional 1..4 <Fallo de conexión> 53 Flavors of the States  Escenarios Eliminar categoría. 1.2.3 Subcaso de uso “Añadir Categoría”  Objetivo Permitir al usuario administrador dar de alta nuevas categorías al listado.  Actor Usuario Administrador  Flujo de Eventos principal 1. El usuario administrador entra en su cuenta y a la sección de administración de categorías, y solicita la inserción de una nueva categoría. 2. La aplicación web se dispone en modo inserción, y se piden los datos referentes a la categoría. 3. El usuario introduce los datos pedidos y confirma la inserción. 4. La aplicación recoge dichos valores, los valida e inserta dicha categoría.  Flujo de Eventos alternativo 2..3 <Cancelar el proceso>, el usuario puede cancelar la operación en estos dos pasos haciendo clic en el botón cancelar.  Flujo de Eventos excepcional 1..4 <Fallo de conexión> 3 <Validación de datos de entrada del usuario por parte de la aplicación web>, donde se indicará si los datos son correctos o no, y cuales en concreto. 1 <No existen categorías>, es posible que no haya categorías y dicha parte de la administración se encuentre vacía. 3..4 <Categoría ya existente>, ya que es posible que el nombre que se le asigne a la nueva categoría ya exista en la base de datos.  Escenarios Añadir categoría. 1.2.4 Subcaso de uso “Consultar Categoría”  Objetivo Permitir al usuario administrador, consultar todos los datos de cualquiera de las categorías dadas de alta en la base de datos. 54 SECCIÓN II: MANUAL TÉCNICO  Actor Usuario administrador  Flujo de Eventos principal 1. El usuario administrador solicita la visualización de las categorías. 2. La aplicación muestra como resultado el listado de las categorías existentes, donde el usuario tiene la posibilidad de mostrar el detalle concreto de una categoría.  Flujo de Eventos excepcional 1..2 <Fallo de conexión> 2 <No hay categorías>, es posible que no haya categorías a listar.  Escenarios Consultar Categoría. 1.3 Caso de uso “Administración de Clientes”  Objetivo Permitir al usuario administrador, que pueda realizar las operaciones básicas para la administración de clientes, tales como: creación, modificación, borrado y consulta.  Actor Usuario administrador  Flujo de evento principal El administrador accederá a la administración de clientes a través de su cuenta personal, en la que podrá desarrollar las siguientes actividades: • Editarlos datos de una cliente existente • Eliminar un cliente del sistema • Añadir un cliente nuevo al sistema • Consultar los datos relativos a cualquiera de los clientes. Este caso de uso, es un caso de uso abstracto que define el conjunto de todas las operaciones posibles con las clientes y que serán definidas más en detalle en los subcasos de uso correspondientes. 55 Flavors of the States Fig 1.3. Diagrama de casos de uso de ‘Administración de Clientes’ 1.3.1 Subcaso de uso “Editar Cliente”  Objetivo Permitir al usuario administrador, poder modificar los campos de un cliente ya existente.  Actor Usuario administrador  Flujo de Eventos principal 1. El usuario solicita modificar un cliente del listado. 2. La aplicación web establece dicho cliente en modo edición. 3. El usuario introduce los valores correspondientes, en este caso únicamente el rol de usuario. 4. La aplicación web recogerá y validará dicha información, y actualizará dicho valor en base de datos. Tras ello, mostrará un mensaje por pantalla donde se indicará que la modificación se hizo correctamente.  Flujo de Eventos alternativo 2..4 <Cancelación del proceso> En todo momento, el administrador podrá cancelar el proceso, haciendo clic en el icono ‘Cancelar’.  Flujo de Eventos excepcional 1..4 <Fallo de conexión> 56 SECCIÓN II: MANUAL TÉCNICO  Escenarios Editar Cliente 1.3.2 Subcaso de uso “Eliminar Cliente”  Objetivo Permitir al usuario administrador, poder eliminar un usuario ya existente.  Actor Usuario Administrador  Flujo de Eventos principal 1. El usuario administrador, solicita el borrado de un cliente del listado. 2. La aplicación web pide confirmación de borrado para ese cliente. 3. El usuario confirma la eliminación. 4. La aplicación web valida dicho cliente, y lo elimina de la base de datos. Tras ello, muestra un mensaje por pantalla indicando que la operación de borrado se ejecutó correctamente.  Flujo de Eventos alternativo 5. El usuario no confirma la eliminación. 6. La aplicación web no hace nada y muestra de nuevo el listado de clientes.  Flujo de Eventos excepcional 1..6 <Fallo de conexión> 1..6 <No hay clientes para borrar> Es posible que no haya clientes para borrar, y el listado se muestre vacío.  Escenarios Borrado de cliente. 1.3.3 Subcaso de uso “Añadir Cliente”  Objetivo Permitir al usuario administrador, poder añadir un nuevo cliente a base de datos.  Actor Usuario Administrador.  Flujo de Eventos principal 57 Flavors of the States 1. El usuario solicita la inserción de un nuevo cliente, haciendo un clic en el icono de Inserción. 2. La aplicación web muestra una nueva línea en el grid de clientes, adaptándolo para una nueva inserción. 3. El usuario introduce los datos en los campos habilitados. 4. La aplicación web recoge y valida los datos introducidos, e inserta dichos campos como un nuevo cliente en la base de datos.  Flujo de Eventos alternativo 3..4 <Cancelación del proceso> En cualquier momento, el usuario puede cancelar el proceso, haciendo que esa nueva línea que aparece en el grid desaparezca, y el listado de clientes aparezca de nuevo.  Flujo de Eventos excepcional 1..4 <Fallo de conexión> 3..4 <Usuario ya existente> Es posible que el usuario que se quiera insertar ya exista en la base de datos, y que por lo tanto no sea posible poder insertarlo, en cuyo caso, se mostrará un mensaje en pantalla indicando que no es posible hacer dicha inserción.  Escenarios Añadir cliente. 1.3.4 Subcaso de uso “Consultar Clientes”  Objetivo Permitir al usuario poder consultar los clientes existentes en la base de datos.  Actor Usuario administrador  Flujo de Eventos principal 1. El usuario administrador solicita ver el listado de clientes. 2. La aplicación web muestra el listado de los clientes, con la posibilidad de entrar en cada uno de los clientes y ver el detalle de cada uno.  Flujo de Eventos excepcional 1..2 <Fallo de conexión> 2 <No hay resultados> Es posible que no haya clientes que listar, con lo cual el listado aparecerá vacío.  Escenarios Consultar clientes. 58 SECCIÓN II: MANUAL TÉCNICO 1.4 Caso de uso “Administración de Direcciones”  Objetivo Permitir al usuario, poder administrar todas las direcciones asociadas a dicho cliente, pudiendo ser las operaciones a realizar: consulta, borrado, modificación y dar de alta.  Actor Usuario registrado.  Flujo de evento principal El usuario accederá a la administración de sus direcciones a través de su cuenta personal, en la que podrá desarrollar las siguientes actividades: • Editar los datos de una dirección existente • Eliminar una dirección • Añadir una nueva dirección al sistema • Consultar los datos relativos a cualquiera de las direcciones Este caso de uso, es un caso de uso abstracto que define el conjunto de todas las operaciones posibles con las direcciones y que serán definidas más en detalle en los subcasos de uso correspondientes. Fig 1.4. Diagrama de casos de uso de ‘Administración de Direcciones’ 59 Flavors of the States Fig 1.6. Diagrama de casos de uso de ‘Administrar Marcas’ 1.6.1 Subcaso de uso “Editar Marca”  Objetivo Permitir al usuario administrador, poder modificar los detalles de una de las marcas existentes, tanto el nombre como la foto.  Actor Usuario administrador.  Flujo de Eventos principal 1. El usuario hace clic en el hipervínculo ‘Marcas’ en la cuenta personal para solicitar el listado de marcas. 2. La aplicación web muestra el listado de marcas existentes. 3. El usuario hace clic en el icono de ‘Editar marca’ 4. La aplicación pone en modo edición, el nombre y la foto de la marca. 5. El usuario introduce los valores requeridos. 6. La aplicación recoge y valida los datos introducidos, y hace la modificación necesaria en base de datos. Tras ello, muestra mensaje en pantalla.  Flujo de Eventos alternativo 4..5 <Cancelación del proceso> En cualquier momento, el usuario puede cancelar el proceso haciendo clic en el icono de Cancelar. 66 SECCIÓN II: MANUAL TÉCNICO 5 <Valores vacíos o incorrectos> Al introducir los valores, si el nombre está vacío o si no se ha seleccionado archivo válido para la foto identificativa de la marca, se mostrará un mensaje por pantalla.  Flujo de Eventos excepcional 1..6 <Fallo de conexión>  Escenarios Editar Marca. 1.6.2 Subcaso de uso “Eliminar Marca”  Objetivo Permitir al usuario administrador, poder eliminar del listado una marca en concreto.  Actor Usuario administrador.  Flujo de Eventos principal 1. El usuario solicita borrar una marca, haciendo clic en el icono de borrar marca. 2. La aplicación web pide confirmación de borrado. 3. El usuario confirma el borrado. 4. La aplicación valida dicha marca, y la elimina de la base de datos. Tras ello, muestra un mensaje por pantalla.  Flujo de Eventos alternativo 5. El usuario no confirma el borrado. 6. La aplicación no hará nada, y simplemente mostrará de nuevo el listado.  Flujo de Eventos excepcional 1..6 <Fallo de conexión>  Escenarios Eliminar Marca 1.6.3 Subcaso de uso “Añadir Marca”  Objetivo Permitir al usuario administrador, poder añadir una nueva marca al listado de las ya existentes. 67 Flavors of the States  Actor Usuario administrador.  Flujo de Eventos principal 1. El usuario solicita poder añadir una nueva marca, haciendo clic al icono correspondiente. 2. La aplicación añade una nueva línea al grid de marcas, dejándo los campos en modo inserción. 3. El usuario inserta los valores correspondientes (Nombre, Foto) y hace clic en el icono de insertar. 4. La aplicación recoge y valida los valores insertados, tras ello inserta la marca y muestra un mensaje por pantalla en caso de que todo vaya correctamente.  Flujo de Eventos alternativo 2..4 <Cancelación del proceso> El usuario puede cancelar el proceso haciendo clic en el icono de cancelar. 2..4 <Valores vacíos o incorrectos> Si el nombre de la marca, o la foto a asignar a la marca están vacíos o desasignados, la aplicación mostrará un mensaje por pantalla.  Flujo de Eventos excepcional 1..4 <Fallo de conexión>  Escenarios Añadir marca. 1.6.4 Subcaso de uso “Consultar Marcas”  Objetivo Permitir al usuario administrador, poder consultar las marcas existentes.  Actor Usuario administrador.  Flujo de Eventos principal 1. El usuario solicita el listado de marcas haciendo clic en Marcas en la cuenta personal. 2. La aplicación muestra un listado de todas las marcas posibles.  Flujo de Eventos excepcional 1..2 <Fallo de conexión> 2 <No hay marcas disponibles> Es posible que no haya marcas en la base de datos, con lo que no habría listado de marcas. 68 SECCIÓN II: MANUAL TÉCNICO  Escenarios Consultar marcas. 1.7 Caso de uso “Administración de Pedidos”  Objetivo Permitir al usuario administrador, poder administrar todas las operaciones asociadas a cada pedido, pudiendo ser las operaciones a realizar: consulta, borrado y modificación.  Actor Usuario administrador Usuario registrado  Flujo de evento principal El usuario administrador accederá a la administración de los pedidos a través de su cuenta personal, en la que podrá desarrollar las siguientes actividades:  Editar los datos de un pedido existente  Eliminar un pedido  Consultar los datos relativos a cualquiera de los pedidos Este caso de uso, es un caso de uso abstracto que define el conjunto de todas las operaciones posibles con los pedidos y que serán definidas más en detalle en los subcasos de uso correspondientes. Fig 1.7 . Diagrama de casos de uso de ‘Administrar Pedidos’ 69 Flavors of the States 1.7.1 Subcaso de uso “Editar Pedido”  Objetivo Permitir al usuario encargado, poder modificar el estado de un pedido en concreto.  Actor Usuario administrador  Flujo de Eventos principal 1. El usuario administrador solicita el listado de pedidos haciendo clic en el hipervínculo ‘Pedidos’. 2. La aplicación muestra un listado con todos los pedidos de todos los usuarios. 3. El usuario solicitar la modificación de un pedido haciendo clic en el icono ‘Editar’. 4. La aplicación pone ese pedido en modo edición. 5. El usuario elige un estado de la combo que aparece en la columna ‘Estado’ y hace clic en el icono ‘Actualizar’. 6. La aplicación recoge los datos, los valida y actualiza en base de datos. Tras ello, muestra un mensaje por pantalla.  Flujo de Eventos alternativo 5. <Cancelación del proceso> El usuario puede cancelar el proceso en todo momento, haciendo clic en el icono ‘Cancelar’.  Flujo de Eventos excepcional 1..6 <Fallo de conexión>  Escenarios Editar Pedido 1.7.2 Subcaso de uso “Eliminar Pedido”  Objetivo Permitir al usuario administrador, poder eliminar cualquier pedido del listado.  Actor Usuario administrador.  Flujo de Eventos principal 1. El usuario solicita hacer un borrado de uno de los pedidos de la lista. 2. La aplicación web pide confirmación del borrado. 70 SECCIÓN II: MANUAL TÉCNICO 3. El usuario confirma dicha petición. 4. La aplicación valida el pedido, lo elimina de la base de datos y tras ello muestra un mensaje por pantalla confirmando el borrado.  Flujo de Eventos alternativo 3 <Cancelación del proceso> En cualquier momento, el usuario puede cancelar el proceso haciendo clic en el icono de ‘Cancelar’.  Flujo de Eventos excepcional 1..4 <Fallo de conexión>  Escenarios Eliminar pedido. 1.7.3 Subcaso de uso “Consultar Pedido”  Objetivo Permitir al usuario administrador o registrado, poder visualizar los detalles de uno de los pedidos.  Actor Usuario Administrador Usuario registrado  Flujo de Eventos principal 1. El usuario solicita ver el detalle de un pedido, haciendo clic en el hipervínculo ‘Ver detalle’ 2. La aplicación redirige al usuario a otra página donde se puede ver todo el detalle del pedido, direcciones de envío y de facturación.  Flujo de Eventos excepcional 1..2 <Fallo de conexión>  Escenarios Consultar pedido. 1.8 Caso de uso “Administración de Productos”  Objetivo Permitir al usuario administrador, poder administrar todas los productos, pudiendo ser las operaciones a realizar: consulta, borrado, modificación, dar de alta y consultar los productos sin stock. 71 Flavors of the States  Actor Usuario administrador  Flujo de evento principal El usuario accederá a la administración de sus productos a través de su cuenta personal, en la que podrá desarrollar las siguientes actividades:  Editar los datos de un producto existente  Eliminar un producto  Añadir un nuevo producto al sistema  Consultar los datos relativos a cualquiera de los productos Este caso de uso, es un caso de uso abstracto que define el conjunto de todas las operaciones posibles con los productos y que serán definidas más en detalle en los subcasos de uso correspondientes. Fig 1.8. Diagrama de casos de uso de ‘Administrar Productos’ 1.8.1 Subcaso de uso “Editar Producto”  Objetivo Permitir al usuario administrador, poder modificar los datos correspondientes al producto.  Actor Usuario administrador  Flujo de Eventos principal 1. El usuario solicita la modificación de un producto haciendo clic en el icono de ‘Editar’. 2. La aplicación pone en modo edición el producto en cuestión. 3. El usuario introduce todos los valores necesarios y hace clic en el botón ‘Actualizar’. 72 SECCIÓN II: MANUAL TÉCNICO 4. La aplicación recoge y valida todos los datos introducidos. Tras ello, actualiza los datos en base de datos y muestra un mensaje por pantalla.  Flujo de Eventos alternativo 3 <Valores vacíos o incorrectos> Si el usuario introduce valores que son incorrectos, o que están vacíos, la aplicación web mostrará un mensaje informativo al usuario para que se introduzcan correctamente. 3 <Cancelación del proceso> El usuario puede cancelar el proceso haciendo clic al icono de ‘Cancelar’.  Flujo de Eventos excepcional 1..4 <Fallo de conexión>  Escenarios Editar producto. 1.8.2 Subcaso de uso “Eliminar Producto”  Objetivo Permitir al usuario administrador, poder eliminar uno de los productos del listado.  Actor Usuario administrador  Flujo de Eventos principal 1. El usuario solicita el borrado de un producto, haciendo clic en el icono de ‘Eliminar’. 2. La aplicación web pide confirmación del borrado. 3. El usuario confirma el borrado. 4. La aplicación valida dicho producto, lo elimina de base de datos y tras ello, muestra un mensaje por pantalla.  Flujo de Eventos alternativo 3 <Cancelación del proceso> El usuario deniega la confirmación y el borrado queda parado.  Flujo de Eventos excepcional 1..4 <Fallo de conexión>  Escenarios Eliminar producto 73 Flavors of the States 1.8.3 Subcaso de uso “Añadir Producto”  Objetivo Permitir al usuario administrador, poder añadir un nuevo producto al listado.  Actor Usuario administrador.  Flujo de Eventos principal 1. El usuario solicita la inserción de un nuevo producto en el sistema. 2. Una nueva línea aparece en el grid de productos, con todos los campos listos en modo inserción para ser rellenados. 3. El usuario rellena todos los campos necesarios y hace clic en el icono ‘Insertar’. 4. La aplicación recoge y valida todos los datos, inserta en base de datos y muestra en pantalla un mensaje confirmando la inserción.  Flujo de Eventos alternativo 3 <Campos vacíos o incorrectos> Es posible que el usuario introduzca valores que no sean correctos, que estén vacíos (y no pueda ser el caso) o se olvide de subir su correspondiente archivo (foto). En ese caso, se mostrará un mensaje correspondiente, donde se informará al usuario del error correspondiente. 4 <Producto ya existente> Es posible que el producto que se está intentando insertar, ya esté insertado en la base de datos. En ese caso, la aplicación mostrará un mensaje de error por existencia del producto.  Flujo de Eventos excepcional 1..4 < Fallo de conexión>  Escenarios Añadir producto. 1.8.4 Subcaso de uso “Consultar Productos”  Objetivo Permitir al usuario, poder consultar los productos existentes.  Actor Usuario administrador. 74 SECCIÓN II: MANUAL TÉCNICO  Flujo de Eventos principal 1. El usuario solicita el listado de los productos existentes, haciendo clic en ‘Productos’ en su cuenta personal. 2. La aplicación web muestra el listado de todos los productos.  Flujo de Eventos excepcional 1..2 <Fallo de conexión>  Escenarios Consulta de productos. 1.8.5 Subcaso de uso “Consultar Productos sin stock”  Objetivo Permitir al usuario, poder consultar los productos en catálogo sin stock.  Actor Usuario administrador.  Flujo de Eventos principal 3. El usuario solicita el listado de los productos existentes sin stock, haciendo clic en ‘No Stock’ en su cuenta personal. 4. La aplicación web muestra el listado de todos los productos sin stock.  Flujo de Eventos excepcional 1..2 <Fallo de conexión>  Escenarios Consulta de productos. 1.9 Caso de uso “Buscar Productos”  Objetivo Permitir al usuario, poder hacer una búsqueda por palabras de un producto en la base de datos de la aplicación web. 75 Flavors of the States  Flujo de eventos alternativo 3 <Cancelación del proceso> En éste momento, el usuario puede cancelar el proceso haciendo clic en el botón ‘Cancelar’. 4 <Usuario no existente o inválido> Si la dirección de correo electrónico no coincide con ninguno de los clientes existentes en base de datos, un mensaje aparecerá por pantalla ‘No tenemos tu correo’.  Flujo de eventos excepcional 1..4 <Fallo de conexión>  Escenario Recordar contraseña 1.14 Caso de uso “Registrarse”  Objetivo Permitir al usuario, que no está registrado en este momento, poderse registrar en la aplicación web.  Actor Usuario no registrado.  Flujo de evento principal 1. El usuario hace clic en el hipervínculo ‘Mi cuenta’ para poder acceder a su cuenta. 2. La aplicación web muestra una página para poder hacer el registro de usuario. 3. El usuario introduce todos los valores necesarios y hace clic en ‘Crear Usuario’. 4. La aplicación web recoge y valida todos los datos, tras ello inserta el usuario en base de datos, y muestra por pantalla que el resgitro se hizo correctamente.  Flujo de eventos alternativo 1..4 <Cancelación del proceso> En cualquier momento, el usuario puede dejar la página en la que nos encontramos y el proceso quedaría cancelado. 3 <Datos vacíos o incorrectos> Si los datos introducidos por el usuario son vacíos o incorrectos, la aplicación web mostrará por pantalla que es lo que está incorrecto y por qué. 3 <Usuario ya existente> Si el usuario que pretendemos insertar, ya existe en la base de datos, se notificará por pantalla de la manera correspondiente.  Flujo de eventos excepcional 1..4 <Fallo de conexión>  Escenario Registrarse. 82 SECCIÓN II: MANUAL TÉCNICO 1.15 Caso de uso “Realizar Pedido”  Objetivo Permitir al usuario, poder realizar un pedido una vez se tenga claro y relleno el carrito.  Actor Usuario registrado  Flujo de evento principal 1. El usuario añade los productos que necesita en la cesta. Tras ello, hace clic en ‘Realizar Pedido’ en el menú o en el botón que hay en la cesta de la compra. 2. La aplicación web muestra la página para definir los detalles del pedido. 3. El usuario elige la dirección de facturación y la de envío y hace clic en el botón ‘Finalizar compra’. 4. La página web manda a PayPal para realizar el pago. 5. El usuario realiza el pago, y se devuelve el control a la aplicación web. 6. La aplicación web muestra un mensaje por pantalla informando de que el pedido ha sido realizado con éxito.  Flujo de eventos alternativo 1 <Sin productos> Es posible que no haya productos en la cesta, en cuyo caso, no podremos realizar el pedido, y tampoco desde el hipervínculo directo del menú. 3. <Dirección de envío y facturación diferentes> o En este caso, el usuario debe hacer clic en el checkbox ‘¿Enviar a la misma dirección de Facturación?’ o La aplicación muestra otra sección para la dirección de envío. o El usuario selecciona una dirección diferente o igual para la dirección de envío. 3. <Dirección de envío y facturación no seleccionadas> o Este caso se da únicamente cuando el cliente no tiene ninguna dirección asociada. o Tras ello, la aplicación web muestra un mensaje por pantalla donde indica que no se ha seleccionado direcciones. 3. <Nueva dirección> o Si el usuario no tiene direcciones asociadas, puede hacer clic en el icono ‘Añadir una dirección’. o En ese momento, una ventana pop up aparece pidiendo los datos para añadir una nueva dirección. o El usuario introduce los datos necesarios y hace clic en el botón ‘Guardar dirección’. o La aplicación recoge los valores y valida que sean correctos. Tras ello, inserta la nueva dirección en base de datos y actualiza la página con la dirección insertada. 3. <Cancelar proceso>, el usuario en cualquier momento es libre de poder ir atrás en la página y hacer nulo el proceso.  Flujo de eventos excepcional 1..6 <Fallo de conexión> 83 Flavors of the States  Escenario Realizar Pedido. Fig 1.15. Diagrama de casos de uso de ‘Realizar Pedido’ y ‘Pagar’ 1.16 Caso de uso “Pagar”  Objetivo Permitir al usuario registrado, hacer el pago del pedido que haya realizado.  Actor Usuario registrado.  Flujo de evento principal 1. El usuario elige los productos en la cesta de la compra y hace clic en el botón ‘Realizar Pedido’. Tras ello, y tras elegir los detalles del pedido, hace clic en ‘Finalizar Compra’. 2. La aplicación web manda el control a la página de PayPal. 3. El usuario tiene dos opciones para hacer el pago: a. Si tiene cuenta PayPal, puede acceder directamente con sus credenciales. b. Si no tiene cuenta PayPal, el usuario hará clic en ‘¿No dispone de una cuenta Paypal?’ donde podrá pagar con tarjetas de crédito. Tras ello, hace clic en el botón ‘Entrar’. 4. La aplicación muestra el detalle del pedido junto con la dirección de envío asociada a la cuenta PayPal del cliente. Hace clic en el botón ‘Pagar ahora’. 5. PayPal informa de que el pago ha concluido correctamente y te lo confirma vía mensaje en la página. 6. El usuario hace clic en el hipervínculo ‘Volver a [email protected]’ 7. PayPal agradece por su gestión y redirige la sesión a la página web. 8. La aplicación web muestra un mensaje que corrobora que el pedido se hizo correctamente. 84 SECCIÓN II: MANUAL TÉCNICO  Flujo de eventos alternativo 3. <El usuario no dispone de cuenta PayPal> Si el usuario no dispone de cuenta PayPal, se le ofrece un método de pago con tarjeta de crédito. El usuario elige tarjeta de crédito con la que pagar y los datos necesarios. Tras ello, hace clic en el botón ‘Continuar’. La aplicación muestra el detalle del pedido junto con la dirección de envío asociada a la cuenta PayPal del cliente. Hace clic en el botón ‘Pagar ahora’. PayPal informa de que el pago ha concluido correctamente y te lo confirma vía mensaje en la página. El usuario hace clic en el hipervínculo ‘Volver a [email protected]’ PayPal agradece por su gestión y redirige la sesión a la página web. La aplicación web muestra un mensaje que corrobora que el pedido se hizo correctamente. 3 <Cancelación del proceso>, es posible que el usuario cancele el proceso de pago haciendo clic en el hipervínculo ‘Cancelar y volver a [email protected]’.  Flujo de eventos excepcional 1..8 <Fallo de conexión> 85 Flavors of the States 2.DIAGRAMAS DE INTERACCIÓN CONCEPTUALES 2.1 Escenari o 1.1: “Añadir artículo al carrito de la compra” • Casos de uso: 1. “Administración Carrito de la compra” • Objetivo: Permitir al usuario poder añadir un artículo a la cesta. • Descripción: El usuario añade la cantidad de productos que quiere añadir en la cesta y la aplicación valida dicha cantidad y el stock existente y los añade automáticamente en la cesta. Fig. 1.1 Escenario “Añadir artículo al carrito de la compra” 86 SECCIÓN II: MANUAL TÉCNICO 2.2 Escenari o 1.2: “Eliminar art ículo del carrito de la compra” • Casos de uso: 1. “Administración Carrito de la compra” • Objetivo: Permitir al usuario poder eliminar un artículo existente en el carrito. • Descripción:  El usuario solicita eliminar el artículo del carrito haciendo clic en el icono ‘Borrar’ o actualizando la cantidad de producto a 0.  La aplicación pide confirmación para el borrado, y si la respuesta es afirmativa, el producto es borrado y en caso negativo, no se efectúa la operación. Fig. 1.2 Escenario “Eliminar artículo del carrito de la compra” 87 Flavors of the States 2.3 Escenari o 1.3: “Editar artículo del carrito de la compra” • Casos de uso: 1. “Administración Carrito de la compra” • Objetivo: Permitir al usuario poder modificar los datos referentes a un artículo del carrito. • Descripción:  El usuario pide actualizar el producto e inserta la cantidad que se quiere de dicho producto.  La aplicación valida dicho dato dependiendo del stock existente de dicho producto, y dependiendo de ello, se actualiza o no. Fig. 1.3 Escenario “Editar artículo del carrito de la compra” 88 SECCIÓN II: MANUAL TÉCNICO 2.4 Escenari o 1.4: “Vaciar artículo del carrito de la compra” • Casos de uso: 1. “Administración Carrito de la compra” • Objetivo: Permitir al usuario poder vaciar el carrito de la compra. • Descripción:  El usuario pide vaciar el carrito.  La aplicación pide confirmación del borrado.  Si el usuario confirma, el carrito es vaciado y se muestra un mensaje. Si no confirma, el carrito se deja tal cual y no se hace ninguna operación. Fig. 1.4 Escenario “Vaciar artículo del carrito de la compra” 89 Flavors of the States 2.5 Escenari o 1.5: “Ver contenido del carrito de la compra” • Casos de uso: 1. “Administración Carrito de la compra” • Objetivo: Permitir al usuario poder ver el contenido del carrito de la compra. • Descripción:  El usuario pide visualizar el contenido del carrito haciendo clic en ‘Mi cesta’ en la parte superior en el menú.  La aplicación muestra todos los artículos que la cesta de la compra contiene. Fig. 1.5 Escenario “Ver contenido del carrito de la compra” 90 SECCIÓN II: MANUAL TÉCNICO 2.6 Escenari o 2.1: “Editar categoría” • Casos de uso: 2. “Administración de Categorías” • Objetivo: Permitir al usuario, poder modificar los datos de una categoría. • Descripción:  El usuario solicita la modificación de la categoría e inserta los datos necesarios.  La aplicación recoge y valida dichos datos introducidos. • Si todo es correcto o La aplicación actualiza la categoría, actualiza la página y muestra un mensaje. • Si no es correcto o La aplicación no hace nada. Fig. 2.1 Escenario “Editar categoría” 91 Flavors of the States 2.13 Escenari o 4.1: “Editar dirección” • Casos de uso: 4. “Administración de Direcciones” • Objetivo: Permitir al usuario, poder modificar los datos de una de las direcciones que tenga asociadas. • Descripción:  El usuario solicita modificar una dirección e introduce los datos necesarios.  Si los datos son correctos: • Se actualiza la dirección  Si no son correctos: • La aplicación no hace nada. Fig. 4.1 Escenario “Editar dirección” 98 SECCIÓN II: MANUAL TÉCNICO 2.14 Escenari o 4.2: “Eliminar dirección” • Casos de uso: 4. “Administración de Direcciones” • Objetivo: Permitir al usuario poder eliminar una dirección asociada al cliente. • Descripción:  El usuario solicita borrar una dirección.  La aplicación pide confirmación de borrado.  Si se confirma: • Se borra la dirección y se muestra mensaje por pantalla. • Redirección a Administracion.aspx  Si no se confirma: • La aplicación no hace nada. Fig. 4.2 Escenario “Eliminar dirección” 99 Flavors of the States 2.15 Escenari o 4.3: “Añadir dirección” • Casos de uso: 4. “Administración de Direcciones” • Objetivo: Permitir al usuario poder añadir una nueva dirección a su libreta. • Descripción:  El usuario solicita añadir una dirección e inserta los datos necesarios.  La aplicación valida los datos y si todo está correcto, inserta la dirección asociándola a ese cliente. • Tras ello, muestra un mensaje por pantalla. Fig. 4.3 Escenario “Añadir dirección” 100 SECCIÓN II: MANUAL TÉCNICO 2.16 Escenari o 4.4: “Consultar direc ción” • Casos de uso: 4. “Administración de Direcciones” • Objetivo: Permitir al usuario, poder consultar las direcciones para un usuario. • Descripción:  El usuario solicita ver las direcciones asociadas.  La aplicación muestra el listado de direcciones. Fig. 4.4 Escenario “Consultar dirección” 101 Flavors of the States 2.17 Escenari o 5.1: “Consultar datos” • Casos de uso: 5. “Administración de Información” • Objetivo: Permitir al usuario poder consultar los datos personales. • Descripción:  El usuario solicita ver su información de contacto.  La aplicación muestra los datos. Fig. 5.1 Escenario “Consultar datos” 102 SECCIÓN II: MANUAL TÉCNICO 2.18 Escenari o 5.2: “Editar datos” • Casos de uso: 5. “Administración de Información” • Objetivo: Permitir al usuario, poder modificar los datos del contacto. • Descripción:  El usuario solicita editar su información de contacto.  Si las contraseñas coinciden, se actualizará la información, si no es así, mensaje. Fig. 5.2 Escenario “Editar datos” 103 Flavors of the States 2.19 Escenari o 6.1: “Editar marca” • Casos de uso: 6. “Administración de Marcas” • Objetivo: Permitir al usuario poder modificar una marca. • Descripción:  El usuario solicita modificar una marca e introduce los datos necesarios.  Si están todos los campos rellenos y correctos: • Se actualiza la marca y se muestra un mensaje.  Si no es así: • La aplicación web muestra un mensaje. Fig. 6.1 Escenario “Editar marca” 104 SECCIÓN II: MANUAL TÉCNICO 2.20 Escenari o 6.2: “Eliminar marca” • Casos de uso: 6. “Administración de Marcas” • Objetivo: Permitir al usuario, poder eliminar una marca. • Descripción:  El usuario solicita borrar una marca.  La aplicación pide confirmación.  Si confirma: • La marca es borrada y se muestra un mensaje por pantalla. Fig. 6.2 Escenario “Eliminar marca” 105 Flavors of the States 2.21 Escenari o 6.3: “Añadir marca” • Casos de uso: 6. “Administración de Marcas” • Objetivo: Permitir al usuario poder añadir una marca. • Descripción:  El usuario solicita añadir una marca e inserta los datos necesarios.  Si los campos están rellenos y correctos: • Inserta la marca y muestra mensaje por pantalla.  Si no es así: • Mostrar mensaje. Fig. 6.3 Escenario “Añadir marca” 106 SECCIÓN II: MANUAL TÉCNICO 2.22 Escenari o 6.4: “Consultar marca” • Casos de uso: 6. “Administración de Marcas” • Objetivo: Permitir al usuario poder consultar el listado de marcas. • Descripción:  El usuario solicita un listado de todas las marcas existentes.  La aplicación muestra el listado de marcas. Fig. 6.4 Escenario “Consultar marca” 107 Flavors of the States 2.29 Escenari o 8.4: “Consultar producto” • Casos de uso: 8. “Administración de Productos” • Objetivo: Permitir al usuario poder consultar un producto. • Descripción:  El usuario solicita consultar los productos.  La aplicación muestra dicho listado de productos. Fig. 8.3 Escenario “Consultar producto” 114 SECCIÓN II: MANUAL TÉCNICO 2.30 Escenari o 8.5: “Consultar productos si n stock” • Casos de uso: 8. “Administración de Productos” • Objetivo: Permitir al usuario poder consultar el listado de productos sin stock. • Descripción:  El usuario solicita consultar los productos que necesitan ser repuestos.  La aplicación muestra dicho listado de productos sin stock. Fig 8.5. Diagrama de secuencia para Consulta de productos sin stock El resto de diagramas de secuencia para éste caso, el de los productos sin stock, serían iguales que los mostrados en la consulta de productos, con lo que editar producto o eliminar, serían los mismos flujos de datos y diagramas. 115 Flavors of the States 2.31 Escenari o 9: “Buscar producto” • Casos de uso: 9. “Buscar Productos” • Objetivo: Permitir al usuario poder buscar productos en base de datos que contengan la palabra a buscar. • Descripción:  El usuario solicita la búsqueda de productos, insertando las palabras que considere necesarias en la caja de texto y haciendo clic en el botón ‘Buscar’.  La aplicación busca los productos que contengan en su nombre la palabra a buscar, y muestra un listado con todos los productos que cumplan dicho requisito. Fig. 9 Escenario “Buscar producto” 116 SECCIÓN II: MANUAL TÉCNICO 2.32 Escenari o 10: “Consultar productos” • Casos de uso: 10. “Consultar productos” • Objetivo: Permitir al usuario poder consultar los productos por marca o por categoría. • Descripción: Es un caso de uso abstracto que contiene dos subcasos que serán vistos mas en profundidad. Fig. 10 Escenario “Consultar producto” 117 Flavors of the States 2.33 Escenario 10.1: “Consultar producto por categoría” • Casos de uso: 10. “Consultar productos” • Objetivo: Permitir al usuario poder consultar un producto por categoría. • Descripción:  El usuario primero solicita el listado de los productos.  La aplicación muestra el listado de los productos.  El usuario marca una categoría de las existentes.  La aplicación muestra entonces todas las marcas asociadas a esa categoría y todos los productos asociados a esas marcas y categoría. Fig. 10.1 Escenario “Consultar producto por categoría” 118 SECCIÓN II: MANUAL TÉCNICO 2.34 Escenari o 10.2: “Consultar producto por marca” • Casos de uso: 10. “Consultar productos” • Objetivo: Permitir al usuario poder hacer una consulta de productos por marca. • Descripción:  El usuario solicita visualizar el listado de productos.  La aplicación muestra el listado de los productos.  El usuario selecciona una de las marcas existentes.  La aplicación muestra el listado de productos filtrando por la marca seleccionada. Fig. 10.2 Escenario “Consultar producto por categoría” 119 Flavors of the States 2.35 Escenari o 11: “Desconectar” • Casos de uso: 11. “Desconectar” • Objetivo: Permitir al usuario registrado o administrador, poder cerrar la sesión de conexión que tienen arrancada. • Descripción:  El usuario solicita la desconexión.  La aplicación cierra y limpia la conexión y hace una redirección a la página, Desconexion.aspx. Fig. 1.11 Escenario “Desconectar” 120 SECCIÓN II: MANUAL TÉCNICO 2.36 Escenari o 12: “Iniciar sesión” • Casos de uso: 12. “Iniciar sesión” • Objetivo: Permitir al usuario que pueda iniciar sesión en la página web. • Descripción:  El usuario solicita iniciar sesión introduciendo sus credenciales.  La aplicación verifica credenciales, guarda usuario en sesión y muestra mensaje. Fig. 1.12 Escenario “Iniciar sesión” 121 Flavors of the States 2.37 Escenari o 13: “Recordar contraseña ” • Casos de uso: 13. “Recordar contraseña” • Objetivo: Permitir al usuario, poder solicitar recordatorio de contraseña en caso de que la olvida. • Descripción:  El usuario solicita el recordatorio de contraseña haciendo clic en el hipervínculo ‘¿Olvidó la contraseña?.  La aplicación muestra una ventana pop up donde pide el correo electrónico.  El usuario introduce la dirección de correo.  La aplicación verifica la dirección de correo. • Si existe en base de datos: o Manda un correo con la nueva contraseña y muestra mensaje. Fig. 1.13 Escenario “Recordar contraseña” 122 SECCIÓN II: MANUAL TÉCNICO 2.38 Escenari o 14: “Regist rarse” • Casos de uso: 14. “Registrarse” • Objetivo: Permitir al usuario, poder registrarse en caso de que no lo esté. • Descripción:  El usuario solicita registrarse, introduciendo todos sus datos.  La aplicación verifica, inserta usuario y muestra mensaje por pantalla. Fig. 1.14 Escenario “Registrarse” 123 Flavors of the States Fig 7. Diagrama de navegabilidad para la administración de productos sin stock Fig 8. Diagrama de navegabilidad, Login / Registro / Recordatorio Contraseña 130 SECCIÓN II: MANUAL TÉCNICO 3.4 Diagrama para Realizar Pedido Fig 9. Diagrama de navegabilidad para realización del pedido Este último diagrama especifica el recorrido para realizar un pedido. Una vez que el carrito esté lleno con los artículos que se quieran, se ordena realizar el pedido, se manda un correo y se transfiere el control a PayPal, que tras efectuar el pago, devolverá el control a la página web. 131 Flavors of the States 4. MODELADO DE DATOS 4.1 Modelo Entidad-Relación A continuación voy a describir cuáles son las entidades que formarán parte de mi proyecto, y tras ello, describiré cuáles son las relaciones entre dichas entidades. 4.1.2 Entidades  IdCategoria: INT  Nombre: VARCHAR(20)  Descripcion: VARCHAR(500)  Foto: VARCHAR(100)  IdStock: INT  Cantidad: INT  IdMarca: INT  Nombre: VARCHAR(20)  Foto: VARCHAR(100)  IdProducto: INT NOT NULL  Nombre: VARCHAR(200)  Precio: DECIMAL(6,2)  Descripcion: VARCHAR(500)  Imagen: VARCHAR(100)  IdPedido: INT NOT NULL  FechaCreacion: DATETIME  Cantidad: INT  Total: VARCHAR(10) 132 SECCIÓN II: MANUAL TÉCNICO  IdEstado: INT NOT NULL  Descripcion: VARCHAR(50)  IdCliente: INT NOT NULL  Nombre: VARCHAR(50)  Apellidos: VARCHAR(100)  Contraseña: VARCHAR(10)  FechaNacimiento: VARCHAR(8)  DNI: VARCHAR(9)  Telefono: INT  Email: VARCHAR(50)  IdRol: INT NOT NULL  Descripcion: VARCHAR(50)  IdLibreta: INT NOT NULL  Nombre: VARCHAR(50)  Apellidos: VARCHAR(100)  Telefono: INT  Direccion: VARCHAR(150)  CodigoPostal: VARCHAR(5)  Ciudad: VARCHAR(30)  Estado: VARCHAR(30)  Pais: VARCHAR(30) Fig 1. Entidades 4.1.3 Relación entre las entidades Las relaciones que existen entre entidades son las siguientes:  Relación uno a uno (1:1) o A cada ocurrencia de la entidad A, le corresponde una ocurrencia de la entidad B, y viceversa.  Relación uno a muchos (1:N) o A cada ocurrencia de la entidad A, le pueden corresponder varias ocurrencias de la entidad B. Pero a cada ocurrencia de la entidad B, sólo le corresponde una ocurrencia de la entidad A. 133 Flavors of the States  Relación muchos a muchos (N:M) o A cada ocurrencia de la entidad A le pueden corresponder varias ocurrencias de la entidad B, y a cada ocurrencia de la entidad B le pueden corresponder varias ocurrencias de la entidad A. Una vez explicados los tipos de relaciones que pueden existir entre entidades, voy a abordar las relaciones que existen entre las entidades de mi esquema.  Relación entre Categoría y Producto Fig 2. Relación Categoria-Producto Una categoría puede tener uno o varios productos (1,N) Un producto sólo puede pertenecer a una categoría (1,1) Relación resultante (1,N)  Relación entre Stock y Producto Fig 3. Relación Stock-Producto Un producto puede tener un único stock (1,1) Un stock puede estar únicamente referido a un producto (1,1) Relación resultante (1,1)  Relación entre Marca y Producto Una marca puede tener uno o varios productos (1,N) Un producto puede tener únicamente una marca (1,1) Relación resultante (1,N) Fig 4. Relación Marca-Producto 134 SECCIÓN II: MANUAL TÉCNICO  Relación entre Producto y Pedido Fig 5. Relación Producto-Pedido Un producto puede estar contenido en uno o varios pedidos (1;N) Un pedido puede contener uno o varios pedidos (1;N) Relación resultante (N:M)  Relación entre Pedido y Estados Fig 6. Relación Pedido-Estados Un pedido puede tener un único estado (1,1) Un estado puede ser estado para uno o varios pedidos (1,N) Relación resultante (1:N)  Relación entre Pedido y Clientes Fig 7. Relación Pedido-Clientes Un pedido es realizado por un único cliente (1,1) Un cliente puede realizar uno o varios pedidos (1,N) 135 Flavors of the States  Relación entre Cliente y Roles Fig 8. Relación Clientes-Roles Un cliente puede tener un único rol (1,1) Un rol puede ser rol de uno o varios clientes (1,N)  Relación entre Cliente y LibretaDirecciones Fig 9. Relación Clientes-LibretaDirecciones Un cliente puede tener una o varias direcciones (1,N) Una dirección puede ser una única dirección de un cliente (1,1) Relación resultante (1:N) 136 SECCIÓN II: MANUAL TÉCNICO Fig. 10 Modelo Entidad-Relación resultante 137 Flavors of the States 4.2 Modelo Relacional En esta sección, se va a transformar el diagrama Entidad-Relación creado en la página anterior, en un modelo relacional, donde obtendremos las tablas necesarias para implementar la base de datos.  Relación Categoría-Producto Fig 11. Relación Categoría-Producto La relación entre Productos y Categorías es de 1:N, ya que un Producto puede tener únicamente una Categoría y una Categoría puede tener diferentes Productos. Para mi proyecto, he considerado que un producto pueda tener sólo una categoría asociada, pero podría tenerse en cuenta que un producto pueda pertenecer a varias categorías. La clave primaria de la entidad ‘Categorías’ IdCategoría queda propagada en la entidad ‘Productos’, marcada como FK.  Relación Stock-Producto Fig 12. Relación Stock-Producto La relación entre Stocks y Productos es de 1:1, ya que un Producto puede tener un determinado y único Stock, y un Stock puede pertenecer únicamente a un Producto. 138 SECCIÓN II: MANUAL TÉCNICO Según la teoría, al ser cardinalidad 1:1, debería fusionar ambas entidades en una, pero he considerado para mayor claridad que ambos conceptos queden separados, aunque estando en una sola entidad sería perfectamente factible y correcto. La clave primaria de la entidad ‘Stocks’ queda propagada en la entidad ‘Productos’.  Relación Marca-Producto Fig 13. Relación Marca-Producto La relación entre Productos y Marcas es de 1:N, ya que un Producto puede tener una sóla marca pero una marca puede tener varios productos. La clave primaria de la entidad ‘Marcas’ quedaría propagada en la entidad ‘Productos’  Relación Producto-Pedido Fig 14. Comparación entre Modelo ER y Modelo Relacional para relación Producto - Pedido 139 Flavors of the States Significa que, el borrado de una tupla en la relación padre ocasiona un borrado de todas las tuplas relacionadas. Fig 21. Borrado de clientes Fig 22. Diagrama modelo Relacional 146 SECCIÓN II: MANUAL TÉCNICO 4.4 TABLAS DE LA BASE DE DATOS CATEGORIAS Campo Tipo Nulo Predeterminado Enlaces a Comentarios IdCategoria int(4) No AutoIncrement Nombre varchar(20) Sí Descripcion varchar(500) Sí Foto varchar(100) No CLIENTES Fig 23. Tabla Categorías Campo Tipo Nulo Predeterminado Enlaces a Comentarios IdCliente int No AutoIncrement Nombre varchar No Apellidos varchar Sí Contraseña varchar Sí FechaNacimiento varchar Sí DNI varchar No Telefono int Sí Email varchar Sí IdRol int No Roles.IdRol DETALLE PEDIDO Fig 24. Tabla Clientes Campo Tipo Nulo Predeterminado Enlaces a Comentarios IdPedido int(4) No Pedidos.IdPedido AutoIncrement IdProducto int(4) No Productos.IdProducto NombreProducto varchar(50) No Cantidad int(4) No Coste decimal(5) No Subtotal decimal(9) Sí Total varchar(10) No ESTADOS Fig 25. Tabla Detalle Pedido Campo Tipo Nulo Predeterminado Enlaces a Comentarios IdEstado int(4) No AutoIncrement Descripcion varchar(50) Sí Fig 26. Tabla Estados 147 Flavors of the States LIBRETADIRECCIONES Campo Tipo Nulo Predeterminado Enlaces a Comentarios IdLibreta int(4) No AutoIncrement IdCliente int(4) No Clientes.IdCliente Nombre varchar(50) No Apellidos varchar(100) No Telefono int(4) Sí Direccion varchar(150) No CodigoPostal varchar(5) No Ciudad varchar(30) No Estado varchar(30) No Pais varchar(30) No Situacion bit No MARCAS Fig 27. Tabla LibretaDirecciones Campo Tipo Nulo Predeterminado Enlaces a Comentarios IdMarca int(4) No AutoIncrement Nombre varchar(20) No Foto varchar(100) No PEDIDOS Fig 28. Tabla Marcas Campo Tipo Nulo Predeterminado Enlaces a Comentarios IdPedido int(4) No AutoIncrement IdCliente int(4) No Clientes.IdCliente IdDireccionEnvio int(4) No LibretaDirecciones.IdLibreta IdDireccionFacturacion int(4) No LibretaDirecciones.IdLibreta FechaCreacion datetime No IdEstado int(4) No Estados.IdEstado EnviadoA varchar(100) Sí FacturadoA varchar(100) Sí Total varchar(10) Sí ROLES Fig 29. Tabla Pedidos Campo Tipo Nulo Predeterminado Enlaces a Comentarios IdRol int(4) No AutoIncrement Descripcion varchar(50) Sí Fig 30. Tabla Roles 148 SECCIÓN II: MANUAL TÉCNICO PRODUCTOS Campo Tipo Nulo Predeterminado Enlaces a Comentarios IdProducto int(4) No AutoIncrement Nombre varchar(200) No Precio decimal(5) Sí IdCategoria int(4) No Categorias.IdCategoria IdMarca int(4) No Marcas.IdMarca Descripcion varchar(500) Sí Imagen varchar(100) Sí IdStock int(4) No Stocks.IdStock Situacion bit No Fig 31. Tabla Productos STOCKS Campo Tipo Nulo Predeterminado Enlaces a Comentarios IdStock int(4) No AutoIncrement Cantidad int(4) Sí Fig 32. Tabla Stocks 4.5 DICCIONARIO DE DATOS Categorías Campo Comentarios IdCategoria Contiene la clave primaria de la categoría. Es una clave autoincrementada. Nombre Indica el nombre de la categoría. Descripcion Contiene la descripción detallada de una categoría. Foto Contiene la ruta donde se encuentra la imagen descriptiva de la categoría. Clientes Campo Comentarios IdCliente Es la clave primaria del Cliente, es autoincrementada. Nombre Contiene el nombre del Cliente. Apellidos Indica los apellidos del Cliente. Contraseña Cadena alfanumérica que indica la contraseña del Cliente. FechaNacimiento Fecha que indica el nacimiento del Cliente. DNI Cadena alfanumérica que coniene el DNI del Cliente. Telefono Cadena alfanumérica que indica el teléfono personal del Cliente. Email Correo del Cliente. IdRol Clave foránea a la tabla Roles que contiene las descripciones de los Roles. 149 Flavors of the States Detalle Pedido Campo Comentarios IdPedido Clave foranea que forma parte de la clave primaria e identifica el pedido. IdProducto Clave foranea que forma parte de la clave primaria e identifica el producto. NombreProducto Indica el nombre del producto. Cantidad Cadena numerica que da la cantidad del producto en el pedido. Coste Cadena numérica que da el coste unitario del producto. Subtotal Cadena numerica que da el subtotal, Coste*Cantidad Total Cadena numérica que da el coste total del pedido. Estados Campo Comentarios IdEstado Clave primaria autoincrementada para identificar el Estado. Descripcion Breve descripción de los estados. Libreta Direcciones Campo Comentarios IdLibreta Clave primaria autoincrementada que identifica unívocamente a una dirección. IdCliente Clave foránea que identifica al Cliente que tiene esta dirección. Nombre Indica el nombre de la persona receptora en esa dirección. Apellidos Indica los apellidos de la persona receptora en esa dirección. Telefono Cadena alfanumérica que contiene el teléfono de contacto de la dirección. Direccion Cadena alfanumérica que contiene la dirección. CodigoPostal Cadena numérica que contiene el Codigo Postal de la dirección. Ciudad Cadena que contiene la Ciudad de la dirección. Estado Cadena que contiene la comiunidad autónoma donde está situada dicha dirección. Pais Cadena que contiene el pais donde está situada dicha dirección. Situacion Bit que contiene la inactividad o no de la dirección en concreto. Marcas Campo Comentarios IdMarca Clave primaria autoincrementada para identificar la Marca. Nombre Cadena alfanumérica que da un nombre para identificar la Marca. Foto Contiene la ruta donde se encuentra la imagen descriptiva de la marca. Roles Campo Comentarios IdRol Clave primaria autoincrementada para identificar los Roles. Descripcion Cadena alfanumérica que da una descripción del Rol. 150 SECCIÓN II: MANUAL TÉCNICO Pedidos Campo Comentarios IdPedido Clave primaria autoincrementada que identifica unívocamente a un Pedido. IdCliente Clave foránea que hace referencia al Cliente que hace este pedido. IdDireccionEnvio Clave foránea que hace referencia a la dirección donde se hace el envío. IdDireccionFacturacion Clave foránea que hace referencia a la dirección donde se factura. FechaCreacion Fecha que recoge el momento en el que se hizo dicho pedido. IdEstado Clave foránea que hace referencia al estado actual del pedido. EnviadoA Breve descripción de la persona a la que se le ha enviado el pedido. FacturadoA Breve descripción de la persona a la que se le ha facturado el pedido. Total Cadena numérica que indica el total del importe del pedido. Productos Campo Comentarios IdProducto Clave primaria autoincrementada que identifica unívocamente al Producto. Nombre Indica el nombre del producto. Precio Cadena numérica que identifica el precio del producto. IdCategoria Clave foránea que identifica la categoria del producto. IdMarca Clave foránea que identifica la marca del producto. Descripcion Cadena alfanumérica que describa el producto. Imagen Cadena alfanumérica que contiene la ruta donde se guarda la imagen del producto. IdStock Clave foránea que contiene el stock del producto. Situacion Bit que contiene la inactividad o no del producto en concreto. Stocks Campo Comentarios IdStock Clave primaria autoincrementada para identificar los Stocks. Cantidad Cadena numérica que da la cantidad en stock de cada producto. 4.6 DIAGRAMA DE CLASES Cabe reseñar lo siguiente en este diagrama de clases:  La clase Negocio, es la clase que controla las operaciones a realizar en la aplicación web y que hace de intermediario entre la clase de acceso a base de datos como es DAL, y la interfaz de usuario. o Es por ello que el resto de clases están haciendo referencia a ella ya que contiene la lógica y funciones a llamar. 151 Flavors of the States Fig 33. Diagrama de clases 152 SECCIÓN II: MANUAL TÉCNICO 5. PRUEBAS DE SOFTWARE Mediante las pruebas de software se puede verificar la calidad de un producto software. Estas pruebas ayudan a identificar posibles fallos que se puedan encontrar tanto en la codificación, calidad o usabilidad de la aplicación web. Las pruebas que se han utilizado para llevar a cabo este proyecto, han sido las de caja negra. Estas se llevan a cabo sobre la interfaz de usuario del software, y se obvia el comportamiento interno o la estructura del programa. Los pasos para estas pruebas son los siguientes:  Para cada dato introducido en la aplicación, se identificarán las clases de equivalencia.  Una vez definidas estas clases, se agruparán en clases válidas e inválidas, es decir, se van a definir las condiciones por las cuales una determinada entrada de datos en un campo de la aplicación se considera válido o inválido.  Definir los casos de prueba en los que se proponen valores de entrada y se analizan los resultados obtenidos. Para la realización de las pruebas, se van a realizar los dos primeros pasos y se identificarán la clases de equivalencia con un número, se clasificarán en clases válidas e inválidas. En las clases de equivalencia se tendrá en cuenta el tipo de dato a insertar. Tras ello, se definen los casos de prueba , las clases de equivalencia a cumplir y los resultados. Por el método de la partición equivalente, el probar un valor representativo de cada clase de equivalencia es como probar cualquier otro valor.  Si se detecta un error en una clase de equivalencia, el resto de casos de prueba van a detectar el mismo error.  Si un caso de prueba no detecta errores, se espera que ningún otro los detecte. Cabe reseñar dos puntos:  Para la validación de alguno de los campos, se han utilizado expresiones regulares.  Para los campos que son combobox, no se han hecho ningún tipo de validaciones dado que ya proceden de base de datos y no requieren validación. A continuación, se va a ir parte por parte de la aplicación identificando clases de equivalencia y casos de prueba para cada una de las secciones de la web. 5.1 Login en la aplicación web  Clases de equivalencia Los datos necesarios para la autenticación en la aplicación son el nombre de usuario y la contraseña, y es válida para identificar a los usuarios en la aplicación. Datos de entrada Clases válidas Clases Inválidas Login Longitud 1. login<=50 2. login=0 3. login > 50 Valor 4. Existe 5. No Existe Contraseña Longitud 6. contraseña <= 10 7. contraseña = 0 8. contraseña > 10 Valor 9. Caracteres 10. No se corresponde con el login 153 Flavors of the States  Casos de prueba Clases Válidas Datos de entrada Clases Resultado Login Usuario3 1,4 Contraseña pwd3 6,9 Acceso permitido 'Bienvenido Usuario3' Clases Inválidas Datos de entrada Clases Resultado Login Longitud = 0 2 El nombre de usuario es obligatorio Longitud > 50 3 Sólo se pueden introducir 50 caracteres No existe 5 Vuelva a introducir las credenciales' Contraseña Longitud = 0 7 La contraseña es obligatoria Contraseña > 10 8 Solo se pueden introducir 10 caracteres No coincide 10 Vuelva a introducir las credenciales' 5.2 Contacto Se validan los campos que aparecen en el formulario de contacto, es decir, el nombre del usuario que escribe el correcto, su dirección de correo electrónico, asunto del mensaje y el mensaje en sí.  Clases de equivalencia Datos de entrada Clases válidas Clases Inválidas Nombre Longitud 1. Nombre <= 50 2. Nombre > 50 3. Nombre = 0 Valor 4. No permite caracteres especiales. 5. Cadena con caracteres especiales. Dirección correo Longitud 6. Email <= 50 7. Email > 50 8. Email = 0 Valor 9. cadena + @ + cadena + '.' + cadena 10. Otro formato diferente Asunto Longitud 11. Asunto <=50 12. Asunto > 50 13. Asunto = 0 Valor 14. No permite caracteres especiales 15. Asunto con caracteres especiales Mensaje Longitud 16. Mensaje <= 500 17. Mensaje > 500 18. Mensaje = 0 154 SECCIÓN II: MANUAL TÉCNICO  Casos de prueba Clases Válidas Datos de entrada Clases Resultado Nombre Carlos 1,4 Cadena aceptada Dirección correo [email protected] 6,9 Cadena aceptada Asunto Duda sobre aperitivos 11,14 Cadena aceptada Mensaje ¿Cuándo van a reponer productos Jack Links? 16 Cadena aceptada Clases Inválidas Datos de entrada Clases Resultado Nombre Longitud > 50 2 No permite introducir mas de 50 caracteres Longitud = 0 3 Devuelve: 'El nombre es obligatorio' Usuario4´` 4 No permite introducir caracteres especiales Dirección correo Longitud > 50 7 No permite introducir mas de 100 caracteres Longitud = 0 8 Devuelve: 'El email es obligatorios' Usuario4@gmail 10 Devuelve:'E-mail incorrecto' Asunto Longitud > 50 12 No permite introducir mas de 50 caracteres Longitud = 0 13 Devuelve: 'El email es obligatorio' Usuario4@gmail 15 Devuelve:'E-mail incorrecto' Mensaje Longitud > 500 17 No permite introducir mas de 50 caracteres Longitud = 0 18 Devuelve: 'El email es obligatorio' 5.3 Detalle Producto El único campo a validar en ésta página es el número de unidades que se quiere ordenar.  Clases de equivalencia Datos de entrada Clases válidas Clases Inválidas Unidades Longitud 1. Unidades <= 3 2. Nombre > 3 3. Nombre = 0 Valor 4. No permite caracteres que no sean numéricos 5. Con caracteres que no sean numéricos  Casos de prueba Clases Válidas Datos de entrada Clases Resultado Unidades 5 1, 4 Cadena aceptada 155