Greengrocers apliccation “gestión económica y fiscal de un almacén de frutas y verduras”

Universidad de Valladolid E.U. de Informática (Segovia) Ingeniría Técnica en Informática de Gestión GREENGROCERS APLICCATION “GESTIÓN ECONÓMICA Y FISCAL DE UN ALMACÉN DE FRUTAS Y VERDURAS” Autor: Daniel Alonso Arias Tutor: José Vicente Álvarez Bravo GREENGROCERS APPLICATION Daniel Alonso Arias Índice de contenidos I - MEMORIA DEL PROYECTO 1. Introducción ............................................................................................................................................... 2 1.1. Identificación del proyecto. ................................................................................................................ 2 1.2. Organización de la documentación. ................................................................................................... 2 1.3. Estructura del CD. ............................................................................................................................... 2 2. Definición del problema ............................................................................................................................. 3 2.1. Planteamiento .................................................................................................................................... 3 2.2. Ámbito del proyecto ........................................................................................................................... 3 2.3. Objetivos ............................................................................................................................................ 3 2.4. Descripción técnica ............................................................................................................................ 3 3. Tecnologías empleadas en la implementación .......................................................................................... 4 3.1. Herramientas ...................................................................................................................................... 4 3.2. Entornos de desarrollo ....................................................................................................................... 6 4. Metodología ............................................................................................................................................... 7 4.1. Etapas del proyecto ............................................................................................................................ 7 4.1.1. Ventajas ...................................................................................................................................... 9 4.2. Arquitectura por capas ..................................................................................................................... 10 4.2.1. Capas y niveles ......................................................................................................................... 10 4.3. Programación orientada a objetos ................................................................................................... 12 4.3.1. Metodología orientada a objetos ............................................................................................. 12 4.3.2. Diseño orientado a objetos ...................................................................................................... 12 4.3.3. Programación orientada a objetos ........................................................................................... 12 5. Descripción de funcionalidades................................................................................................................ 19 5.1. Identificación de usuarios ................................................................................................................ 19 5.2. Descripción de tareas ....................................................................................................................... 19 GREENGROCERS APPLICATION Daniel Alonso Arias 6. Planificación y presupuesto ..................................................................................................................... 20 6.1. Proceso de creación del software ................................................................................................... 20 6.2. Planificación temporal inicial ........................................................................................................... 21 6.3. Planificación temporal real .............................................................................................................. 22 6.4. Comparación y conclusiones ........................................................................................................... 23 6.5. Costes .............................................................................................................................................. 24 6.5.1. Coste de los recursos humanos ............................................................................................... 24 6.5.2. Costes del hardware ................................................................................................................ 25 6.5.3. Costes del software ................................................................................................................. 25 6.5.4. Costes totales del proyecto GreengroccersApp ...................................................................... 25 7. Conclusiones y posibles ampliaciones ..................................................................................................... 26 II - MANUAL TÉCNICO 8. Análisis ..................................................................................................................................................... 28 8.1. Introducción..................................................................................................................................... 28 8.2. Objetivos del sistema....................................................................................................................... 28 8.3. Especificación de Requisitos ............................................................................................................ 31 8.3.1. Requisitos de información ....................................................................................................... 31 8.3.2. Requisitos funcionales ............................................................................................................. 50 8.3.3. Requisitos no funcionales ...................................................................................................... 113 8.4. Matriz de rastreabilidad objetivos/requisitos ............................................................................... 115 8.5. Conflictos pendientes de resolución ............................................................................................. 117 8.6. Resumen ........................................................................................................................................ 117 8.7. Glosario de términos ..................................................................................................................... 119 9. Diseño .................................................................................................................................................... 120 9.1. Introducción................................................................................................................................... 120 9.2. Diagramas de clases....................................................................................................................... 121 GREENGROCERS APPLICATION Daniel Alonso Arias 10. Bases de datos .................................................................................................................................... 158 10.1. Diseño ......................................................................................................................................... 158 10.2. Modelo Relacional ...................................................................................................................... 159 10.2.1. Introducción ........................................................................................................................... 159 10.2.2. Diagrama de relaciones .......................................................................................................... 167 10.2.3. Paso a tablas ........................................................................................................................... 167 10.2.4. Descripción de tablas y atributos ........................................................................................... 169 11. Implementación ................................................................................................................................. 208 11.1. Introducción ............................................................................................................................... 208 11.2. Jerarquía de clases ..................................................................................................................... 208 11.3. Implementación de la capa de negocio ...................................................................................... 208 11.3.1. Implementación del diseño .................................................................................................... 208 11.3.2. Consideraciones relevantes .................................................................................................... 208 11.4. Implementación de la capa de presentación ............................................................................. 209 11.4.1. Implementación del diseño .................................................................................................... 209 11.4.2. Consideraciones relevantes .................................................................................................... 209 11.5. Implementación de la capa de datos (conexión al ODBC) ........................................................ 209 11.5.1. Implementación del diseño .................................................................................................... 209 11.5.2. Consideraciones relevantes .................................................................................................... 209 11.6. Implementación de la capa de herramientas ............................................................................. 209 11.6.1. Implementación del diseño .................................................................................................... 209 11.6.2. Consideraciones relevantes .................................................................................................... 209 12. Pruebas ............................................................................................................................................... 210 12.1. Introducción ............................................................................................................................... 210 12.1.1. Niveles .................................................................................................................................... 210 12.1.2. Tipos ....................................................................................................................................... 210 12.2. Pruebas de caja negra ................................................................................................................ 211 12.2.1. Unitarias ................................................................................................................................. 211 12.2.2. Integración.............................................................................................................................. 212 GREENGROCERS APPLICATION Daniel Alonso Arias 12.3. Pruebas de caja blanca .............................................................................................................. 213 12.3.1. Unitarias ................................................................................................................................. 213 12.3.2. Integración ............................................................................................................................. 213 III - MANUALES 13. Manual de instalación ....................................................................................................................... 216 13.1. Introducción ............................................................................................................................... 216 13.2. Instalación de la aplicación ........................................................................................................ 216 14. Manual de Usuario ............................................................................................................................ 220 14.1. Introducción ............................................................................................................................... 220 14.2. Realizar un pedido ..................................................................................................................... 220 14.2.1. Realizar pedido con un cliente existente. .............................................................................. 221 14.2.2. Realizar pedido con un cliente nuevo. ................................................................................... 226 14.2.3. Realizar pedido editando un cliente existente. ..................................................................... 227 14.3. Productos ................................................................................................................................... 228 14.3.1. Añadir producto ..................................................................................................................... 229 14.3.2. Editar producto ...................................................................................................................... 231 14.3.3. Eliminar producto .................................................................................................................. 233 14.3.4. Editar precios ......................................................................................................................... 234 14.3.5. Imprimir precios de los productos ......................................................................................... 235 14.4. Clientes ...................................................................................................................................... 236 14.4.1. Añadir cliente ......................................................................................................................... 237 14.4.2. Editar cliente .......................................................................................................................... 238 14.4.3. Eliminar cliente ...................................................................................................................... 240 14.4.4. Imprimir listado de clientes ................................................................................................... 242 14.4.5. Ver facturas del cliente .......................................................................................................... 243 14.4.6. Ver albaranes del cliente ....................................................................................................... 246 GREENGROCERS APPLICATION Daniel Alonso Arias 14.5. Proveedores ............................................................................................................................... 248 14.5.1. Añadir proveedor ................................................................................................................... 249 14.5.2. Editar proveedor .................................................................................................................... 251 14.5.3. Eliminar proveedor ................................................................................................................. 252 14.5.4. Imprimir listado de proveedores ............................................................................................ 253 14.5.5. Ver facturas del proveedor ..................................................................................................... 254 14.5.6. Añadir compra ........................................................................................................................ 256 14.6. Añadir gasto................................................................................................................................ 258 14.6.1. Gasto de proveedores ............................................................................................................ 258 14.6.2. Gasto libre .............................................................................................................................. 259 14.7. Modificar tipos de IVA ................................................................................................................ 260 14.8. Resúmenes ................................................................................................................................. 260 14.8.1. Resumen mensual .................................................................................................................. 261 14.8.2. Resumen trimestral ................................................................................................................ 263 14.8.3. Resumen anual ....................................................................................................................... 265 14.9. Recuperar datos ......................................................................................................................... 267 GREENGROCERS APPLICATION Daniel Alonso Arias I MEMORIA DEL PROYECTO 1 SECCIÓN I – MEMORIA DEL PROYECTO GREENGROCERS APPLICATION Daniel Alonso Arias 2 I MEMORIA DEL PROYECTO 1. Introducción 1.1. Identificación del proyecto.  Título: Greengrocers Application  Autor: Daniel Alonso Arias  Tutor: José Vicente Álvarez Bravo  Departamento: Informática (CCIA/LSI) 1.2. Organización de la documentación. La documentación se dividirá en los tres siguientes apartados:  Memoria del proyecto: en el que se muestra un resumen con los puntos básicos del PFC, que da entendimiento de la envergadura del trabajo realizado y características principales del sistema.  Manual técnico: en el que se desarrollan aspectos técnicos del análisis y diseño del sistema.  Manuales de usuario: destinados a dar asistencia a las personas que utilizarán el sistema. En ellos se describen el uso de la aplicación desarrollada, así como, el proceso de instalación de la aplicación. Este documento se encontrará también en la ayuda de la aplicación. 1.3. Estructura del CD. A continuación se describirán los apartados, en los que quedará estructurado el CD, explicando brevemente su distribución: - Carpeta “Memoria del proyecto”, que contendrá los archivos:  “Memoria.pdf”, que contendrá la memoria del proyecto.  “Título.pdf”, que contendrá la portada del proyecto. - Carpeta “Software”, que estará compuesta por otras tres subcarpetas:  Carpeta “Código fuente”, que contendrá el código fuente de la aplicación.  Carpeta “Manuales”, que contendrá los archivos “Manual de instalación.pdf”, con la instrucciones correspondiente para una correcta instalación de la aplicación, y “Manual de usuario.pdf”, con las instrucciones para manejar la aplicación.  Carpeta “Aplicación”, que contendrá el software ejecutable de la aplicación. GREENGROCERS APPLICATION Daniel Alonso Arias I MEMORIA DEL PROYECTO 9 4.1.1. Ventajas Desde el punto de vista de gestión  Facilitar la tarea de seguimiento del proyecto  Optimizar el uso de recursos  Facilitar la comunicación entre usuarios y desarrolladores  Facilitar la evaluación de resultados y cumplimiento de objetivos Desde el punto de vista de los ingenieros de Software  Ayudar a comprender el problema  Permitir la reutilización  Facilitar el mantenimiento del producto final  Optimizar el conjunto y cada una de las fases del proceso de desarrollo Desde el punto de vista de cliente o usuario final  Garantizar el nivel de calidad del producto final  Obtener el ciclo de vida adecuado para el proyecto  Confianza en los plazos del tiempo mostrados en la definición del proyecto GREENGROCERS APPLICATION Daniel Alonso Arias 10 I MEMORIA DEL PROYECTO 4.2. Arquitectura por capas La programación por capas es una arquitectura cliente-servidor en el que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al usuario. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, sólo se ataca al nivel requerido sin tener que revisar entre código mezclado. Un buen ejemplo de este método de programación sería el modelo de interconexión de sistemas abiertos. Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este modo, cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma que basta con conocer la API que existe entre niveles. En el diseño de sistemas informáticos actual se suelen usar las arquitecturas multinivel o Programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades aumenten). El diseño más utilizado actualmente es el diseño en tres niveles (o en tres capas) 4.2.1. Capas y niveles 1. Capa de presentación: es la que ve el usuario (también se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). También es conocida como interfaz gráfica y debe tener la característica de ser "amigable" (entendible y fácil de usar) para el usuario. Esta capa se comunica únicamente con la capa de negocio. 2. Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. También se consideran aquí los programas de aplicación. GREENGROCERS APPLICATION Daniel Alonso Arias I MEMORIA DEL PROYECTO 11 3. Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio. Todas estas capas pueden residir en un único ordenador, si bien lo más usual es que haya una multitud de ordenadores en donde reside la capa de presentación (son los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos pueden residir en el mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden separar en dos o más ordenadores. Así, si el tamaño o complejidad de la base de datos aumenta, se puede separar en varios ordenadores los cuales recibirán las peticiones del ordenador en que resida la capa de negocio. Si, por el contrario, fuese la complejidad en la capa de negocio lo que obligase a la separación, esta capa de negocio podría residir en uno o más ordenadores que realizarían solicitudes a una única base de datos. En sistemas muy complejos se llega a tener una serie de ordenadores sobre los cuales corre la capa de negocio, y otra serie de ordenadores sobre los cuales corre la base de datos. En una arquitectura de tres niveles, los términos "capas" y "niveles" no significan lo mismo ni son similares. El término "capa" hace referencia a la forma como una solución es segmentada desde el punto de vista lógico:  Presentación. (Conocida como capa Web en aplicaciones Web o como capa de usuario en Aplicaciones Nativas)  Lógica de Negocio. (Conocida como capa Aplicativa)  Datos. (Conocida como capa de Base de Datos) En cambio, el término "nivel" corresponde a la forma en que las capas lógicas se encuentran distribuidas de forma física. Por ejemplo:  Una solución de tres capas (presentación, lógica del negocio, datos) que residen en un solo ordenador (Presentación+lógica+datos). Se dice que la arquitectura de la solución es de tres capas y un nivel.  Una solución de tres capas (presentación, lógica del negocio, datos) que residen en dos ordenadores (presentación+lógica por un lado; lógica+datos por el otro lado). Se dice que la arquitectura de la solución es de tres capas y dos niveles. Para la solución de nuestro sistema, se ha optado por una arquitectura de 4 (presentación, lógica de negocio, datos, herramientas) capas y 1 nivel. GREENGROCERS APPLICATION Daniel Alonso Arias 12 I MEMORIA DEL PROYECTO 4.3. Programación orientada a objetos 4.3.1. Metodología orientada a objetos La metodología orientada a objetos combina los datos y los procedimientos en un solo objeto. En vez de pasar datos a los procedimientos, los programas envían un mensaje a un objeto para que realice un procedimiento que ya tiene integrado. El mismo mensaje puede ser enviado a muchos objetos diferentes, pero cada uno de ellos implantará el mensaje de forma diferente. Por ejemplo, una aplicación financiera orientada a objetos puede tener que los objetos Cliente envíen mensajes de debo y haber a los objetos Cuentas. Los objetos Cuentas, a su vez, pueden mantener a los objetos Efectivo, Cuentas por pagar y Cuentas por cobrar. Por ende, la metodología orientada a objetos se concibe como conjunto de objetos que interactúan entre sí y se busca el enfoque unificador de los objetos. Entre sus características encontramos:  No modela la realidad, sino la forma en que las personas comprenden y procesan la realidad  Es un proceso ascendente basado en una abstracción de clases en aumento  Se basa en identificación de objetos, definición y organización de librerías de clases, y creación de macros para aplicaciones específicas  Utiliza menor cantidad de código  Es más reutilizable 4.3.2. Diseño orientado a objetos Diseño orientado a objetos es una fase de la metodología orientada a objetos para el desarrollo de Software. Su uso induce a los programadores a pensar en términos de objetos, en vez de procedimientos, cuando planifican su código. Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La 'interfaz del objeto', esto es, las formas de interactuar con el objeto, también se definen en esta etapa. Un programa orientado a objetos se caracteriza por la interacción de esos objetos. El diseño orientado a objetos es la disciplina que define los objetos y sus interacciones para resolver un problema de negocio que fue identificado y documentado durante el análisis orientado a objetos. 4.3.3. Programación orientada a objetos La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa los objetos en sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, cohesión, abstracción, polimorfismo, acoplamiento y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe una gran variedad de lenguajes de programación que soportan la orientación a objetos. GREENGROCERS APPLICATION Daniel Alonso Arias I MEMORIA DEL PROYECTO 13 4.3.3.1. Conceptos fundamentales La programación orientada a objetos es una forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes: Clase: Definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas. Herencia: (Por ejemplo, herencia de la clase C a la clase D) es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables públicas declaradas en C. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de POO. Objeto: Instancia de una clase. Entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos), los mismos que consecuentemente reaccionan a eventos. Se corresponden con los objetos reales del mundo que nos rodea, o con objetos internos del sistema (del programa). Es una instancia a una clase. Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema Evento: Es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento la reacción que puede desencadenar un objeto; es decir, la acción que genera. Atributos: Características que tiene la clase Mensaje: Una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó. Propiedad o atributo: Contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método. GREENGROCERS APPLICATION Daniel Alonso Arias 14 I MEMORIA DEL PROYECTO Estado interno: Es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase. Identificación de un objeto: Un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes. 4.3.3.2. Características de la POO Existe un acuerdo acerca de qué características contempla la "orientación a objetos". Las características siguientes son las más importantes: Abstracción: Denota las características esenciales de un objeto, donde se capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos, y, cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción. El proceso de abstracción permite seleccionar las características relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el proceso de análisis y diseño orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar. Encapsulamiento: Significa reunir todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente. Modularidad: Se denomina modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. Estos módulos se pueden compilar por separado, pero tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la modularidad de diversas formas. Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que específica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas; solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no puedan cambiar el estado interno de un objeto de manera inesperada, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos. Polimorfismo: Una de las características fundamentales de la POO es el polimorfismo, que no es otra cosa que la posibilidad de construir varios métodos con el mismo nombre, pero con relación a la clase a la que pertenece cada uno, con comportamientos diferentes. O, dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++. GREENGROCERS APPLICATION Daniel Alonso Arias I MEMORIA DEL PROYECTO 15 Herencia: Las clases no se encuentran aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento, permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple; siendo de alta complejidad técnica por lo cual suele recurrirse a la herencia virtual para evitar la duplicación de datos. Recolección de basura: La recolección de basura o garbage collection es la técnica por la cual el entorno de objetos se encarga de destruir automáticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse expresamente. 4.3.3.3. Componentes de un objeto Un objeto puede considerarse como una especie de cápsula dividida en tres partes: 1 - RELACIONES 2 - PROPIEDADES 3 - METODOS Cada uno de estos componentes desempeña un papel totalmente independiente: Las relaciones permiten que el objeto se inserte en la organización y están formadas esencialmente por punteros a otros objetos. Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización. Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia. Encapsulamiento y ocultación Cada objeto es una estructura compleja en cuyo interior hay datos y programas, todos ellos relacionados entre sí, como si estuvieran encerrados conjuntamente en una cápsula. Esta propiedad (encapsulamiento), es una de las características fundamentales en la POO. Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los programadores conozcan cómo está distribuida la información o qué información hay disponible. Esta propiedad de los objetos se denomina ocultación de la información. Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario respecto a un objeto y a lo que contiene. Si así fuera no se podría hacer gran cosa con él. Lo que sucede es que las peticiones de información a un objeto. Deben realizarse a través de mensajes dirigidos a él, con la orden de realizar la operación pertinente. La respuesta a estas órdenes será la información requerida, siempre que el objeto considere que quien envía el mensaje está autorizado para obtenerla. El hecho de que cada objeto sea una cápsula facilita enormemente que un objeto determinado pueda ser transportado a otro punto de la organización, o incluso a otra organización totalmente diferente que precise de él. Si el objeto ha sido bien construido, sus métodos seguirán funcionando en el nuevo entorno sin problemas. Esta cualidad hace que la POO sea muy apta para la reutilización de programas. GREENGROCERS APPLICATION Daniel Alonso Arias 16 I MEMORIA DEL PROYECTO Organización de los objetos En principio, los objetos forman siempre una organización jerárquica, en el sentido de que ciertos objetos son superiores a otros de cierto modo. Existen varios tipos de jerarquías: serán simples cuando su estructura pueda ser representada por medio de un "árbol". En otros casos puede ser más compleja. En cualquier caso, sea la estructura simple o compleja, podrán distinguirse en ella tres niveles de objetos.  La raíz de la jerarquía. Se trata de un objeto único y especial. Este se caracteriza por estar en el nivel más alto de la estructura y suele recibir un nombre muy genérico, que indica su categoría especial, como por ejemplo objeto madre, Raíz o Entidad.  Los objetos intermedios. Son aquellos que descienden directamente de la raíz y que a su vez tienen descendientes. Representan conjuntos o clases de objetos, que pueden ser muy generales o muy especializados, según la aplicación. Normalmente reciben nombres genéricos que denotan al conjunto de objetos que representan, por ejemplo, VENTANA, CUENTA, FICHERO. En un conjunto reciben el nombre de clases o tipos si descienden de otra clase o subclase.  Los objetos terminales. Son todos aquellos que descienden de una clase o subclase y no tienen descendientes. Suelen llamarse casos particulares, instancias o ítems porque representan los elementos del conjunto representado por la clase o subclase a la que pertenecen. Veamos ahora en detalle los tres elementos mencionados en "Estructura de un Objeto". 1. RELACIONES Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto relacionarse con aquellos que forman parte de la misma organización. Las hay de dos tipos fundamentales: -Relaciones jerárquicas. Son esenciales para la existencia misma de la aplicación porque la construyen. Son bidireccionales, es decir, un objeto es padre de otro cuando el primer objeto se encuentra situado inmediatamente encima del segundo en la organización en la que ambos forman parte; asimismo, si un objeto es padre de otro, el segundo es hijo del primero. Una organización jerárquica simple puede definirse como aquella en la que un objeto puede tener un solo padre, mientras que en una organización jerárquica compleja un hijo puede tener varios padres). -Relaciones semánticas. Se refieren a las relaciones que no tienen nada que ver con la organización de la que forman parte los objetos que las establecen. Sus propiedades y consecuencia solo dependen de los objetos en sí mismos (de su significado) y no de su posición en la organización. GREENGROCERS APPLICATION Daniel Alonso Arias I MEMORIA DEL PROYECTO 17 2. PROPIEDADES Todo objeto puede tener cierto número de propiedades, cada una de las cuales tendrá, a su vez, uno o varios valores. En POO, las propiedades corresponden a las clásicas "variables" de la programación estructurada. Son, por lo tanto, datos encapsulados dentro del objeto, junto con los métodos (programas) y las relaciones (punteros a otros objetos). Las propiedades de un objeto pueden tener un valor único o pueden contener un conjunto de valores más o menos estructurados (matrices, vectores, listas, etc.). Además, los valores pueden ser de cualquier tipo (numérico, alfabético, etc.) si el sistema de programación lo permite. Pero existe una diferencia con las "variables", y es que las propiedades se pueden heredar de unos objetos a otros. En consecuencia, un objeto puede tener una propiedad de maneras diferentes: -Propiedades propias. Están formadas dentro de la cápsula del objeto. -Propiedades heredadas. Están definidas en un objeto diferente, antepasado de éste (padre, "abuelo", etc.). A veces estas propiedades se llaman propiedades miembro porque el objeto las posee por el mero hecho de ser miembro de una clase. 3. METODOS Una operación que realiza acceso a los datos. Podemos definir método como un programa procedimental o procedural escrito en cualquier lenguaje, que está asociado a un objeto determinado y cuya ejecución sólo puede desencadenarse a través de un mensaje recibido por éste o por sus descendientes. Son sinónimos de 'método' todos aquellos términos que se han aplicado tradicionalmente a los programas, como procedimiento, función, rutina, etc. Sin embargo, es conveniente utilizar el término 'método' para que se distingan claramente las propiedades especiales que adquiere un programa en el entorno POO, que afectan fundamentalmente a la forma de invocarlo (únicamente a través de un mensaje) y a su campo de acción, limitado a un objeto y a sus descendientes, aunque posiblemente no a todos. Si los métodos son programas, se deduce que podrían tener argumentos, o parámetros. Puesto que los métodos pueden heredarse de unos objetos a otros, un objeto puede disponer de un método de dos maneras diferentes: GREENGROCERS APPLICATION Daniel Alonso Arias 18 I MEMORIA DEL PROYECTO -Métodos propios. Están incluidos dentro de la cápsula del objeto. -Métodos heredados. Están definidos en un objeto diferente, antepasado de éste (padre, "abuelo", etc.). A veces estos métodos se llaman métodos miembro porque el objeto los posee por el mero hecho de ser miembro de una clase. Demonios Es un tipo especial de métodos, relativamente poco frecuente en los sistemas de POO, que se activa automáticamente cuando sucede algo especial. Es decir, es un programa, como los métodos ordinarios, pero se diferencia de estos porque su ejecución no se activa con un mensaje, sino que se desencadena automáticamente cuando ocurre un suceso determinado: la asignación de un valor a una propiedad de un objeto, la lectura de un valor determinado, etc. Los demonios, cuando existen, se diferencian de otros métodos por que no son heredables y porque a veces están ligados a una de las propiedades de un objeto, más que al objeto entero. GREENGROCERS APPLICATION Daniel Alonso Arias I MEMORIA DEL PROYECTO 25 6.5.2. Costes del hardware El hardware utilizado para el desarrollo del proyecto consta de dos ordenadores, uno portátil y otro de sobremesa, con sendas conexiones ADSL para el trabajo desde la nube, así como una multifunción. DISPOSITIVO HARDWARE EMPLEADO COSTE USO COSTE REAL PORTATIL Packard Bell TS11-HR-235SP I32310/4GB/640GB/GT 520M/15.6" 482,90€ 11% 53,12€ SOBREMESA intelCORE i5/8GBram/4GBgraphics/128GBssd/84GBss d/1TB-hd/OvisLink Chrome 1800E 1.070,00€ 17% 181,90€ MULTIFUNCION Canon PIXMA MG3550 Wifi Negra 54,00€ 2% 1,08€ ADSL VODAFONE Conexión de un año 384,40€ 50% 192,20€ ADSL TELEFONICA Conexión de un año 541,20€ 50% 270,60€ TOTAL 698,90€ 6.5.3. Costes del software HERRAMIENTA DESCRIPCION COSTE USO COSTE REAL Windows 8,1 Sistema operativo Incluido en HW - - Windows 7 Sistema operativo Incluido en HW - - Microsoft Visual Studio 2005 Express Edition Entorno de desarrollo 40,00€ 10% 4,00€ Microsoft Visual Studio 2013 Ultimate Entorno de desarrollo 1.135,00€ 10% 113,50€ Star UML Modelado software Gratis - - Microsoft Office 2003 Suite ofimática 30,00€ 10% 3,00€ Microsoft Office 2013 Suite ofimática 539,00€ 10% 53,90€ PDF Architect Generador de archivos PDF Gratis - - Microsoft SQL Server 2005, Express Edition Gestor de BBDD Gratis - - Microsoft SQL Server 2012 Gestor de BBDD Gratis - - Google Drive Gestor de archivos web (nube) Gratis - - Google Chrome Navegador web Gratis - - Snagit Capturador/editor de imágenes 47,95€ 10% 4,80€ Camtasia Studio Capturador/editor de vídeo Gratis - - Team Viewer Escritorio remoto Gratis - - TOTAL 179,20€ 6.5.4. Costes totales del proyecto GreengroccersApp COSTE TOTAL DE RRHH Coste de RRHH € 9.946,84 Coste de Hardware € 698,90 Coste de Software € 179,20 TOTAL € 10.824,93 GREENGROCERS APPLICATION Daniel Alonso Arias 26 I MEMORIA DEL PROYECTO 7. Conclusiones y posibles ampliaciones En todos estos años de carrera, hemos tenido numerosas asignaturas en las que nos han enseñado muchas cosas, pero es en el proyecto, donde realmente uno se da cuenta de los conocimientos adquiridos y de los mucho que nos queda por aprender. Se nos han dado una serie de pautas para la realización de un Software de Calidad, bastante acertadas desde mi punto de vista, pero que distan bastante de los procedimientos y métodos que se emplean en a la hora de realizar proyectos, según lo poco que he podido ver mi corta experiencia profesional. En la actualidad se trabaja con unos costes y tiempos muy reducidos, que no permiten realizar un análisis exhaustivo del sistema, con lo cual la mayoría se encuentran muy escasos de documentación, con la dificultad y problemas que eso acarrea. En definitiva, que hacer una buena extracción de requerimientos y a continuación una exhaustiva fase de diseño, resulta crucial para que un proyecto continúe su camino de la manera más eficaz. En cuanto a esta aplicación, creo que se han cubierto satisfactoriamente todos los requisitos especificados por el cliente. Se han quedado bastantes mejoras aplicables en el tintero, posiblemente por el largo periodo de tiempo que he tardado la realización de esta, ya que se empezó con una idea y desde un perfil determinado, que ha evolucionado a lo largo del tiempo, y se ha respetado la idea inicial, quedando una lista de mejoras y ampliaciones para un futuro. Entre las posibles mejoras del sistema cabe destacar: - Una nueva vista de la aplicación, más amigable y moderna, con un formato de pestañas o de submenús contextuales, en vez del sistema de ventanas, que es el que ha sido utilizado. - Una serie de servicios WEB, tales como la realización de pedidos on-line, envío de resúmenes vía email a la gestoría, así como posibilidad de controlar el sistema desde una PDA o un Smartphone. - La integración del manual de usuario en la aplicación, así como la creación de un manual de usuario virtual, también integrado en el sistema. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 27 SECCIÓN II - MANUAL TÉCNICO GREENGROCERS APPLICATION Daniel Alonso Arias 28 II MANUAL TÉCNICO 8. Análisis 8.1. Introducción El análisis de un sistema informático es una de las etapas de construcción más importantes para cumplir los objetivos finales. Esta fase se ocupa de la reunión y estudio a detalle de los datos del sistema en operación y la especificación de los nuevos requerimientos del sistema a desarrollar. Concluye en general con un documento que recoge el resultado del análisis. Para llegar a la solución correcta, hay que extraer todos los requisitos del usuario, comprobarlos, asegurándonos de que todos esos requisitos estén contemplados en el diseño y que el diseño no difiera de los requisitos. A continuación vamos a ir viendo la fase de análisis de la aplicación. 8.2. Objetivos del sistema En este apartado vamos a ir viendo los objetivos que deberán cumplirse cuando la aplicación esté en funcionamiento. OBJ-1 Gestión de Facturación Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Descripción El sistema se encargará de generar y clasificar todo tipo de pedidos, con los datos que introduzca el usuario. Subobjetivos OBJ-1.1 - Gestión de Facturas OBJ-1.1.1 - Gestión de Facturas de Ventas OBJ-1.1.2 - Gestión de Facturas de Compras OBJ-1.1.3 - Gestión de Gastos y Facturas Recibidas OBJ-1.2 - Gestión de Albaranes OBJ-1.2.1 - Gestión de Albaranes de Ventas OBJ-1.3 - Gestión de Resúmenes Mensuales Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 01: Objetivo 1. Gestión de Facturación. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 29 OBJ-2 Gestión de Documentos Fiscales Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Descripción El sistema gestionará, las relaciones de gastos e ingresos, solicitadas por el usuario. Subobjetivos OBJ-2.1 - Gestión de Gastos OBJ-2.1.1 - Gestión de Gastos Trimestrales de un Proveedor OBJ-2.1.2 - Gestión de Gastos Trimestrales General OBJ-2.1.3 - Gestión de Gastos Anuales de un Proveedor OBJ-2.1.4 - Gestión de Gastos Anuales General OBJ-2.1 - Gestión de Ingresos OBJ-2.1.1 - Gestión de Ingresos Trimestrales de un Cliente OBJ-2.1.2 - Gestión de Ingresos Trimestrales General OBJ-2.1.3 - Gestión de Ingresos Anuales de un Cliente OBJ-2.1.4 - Gestión de Ingresos Anuales General Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 02: Objetivo 2. Gestión de Documentos Fiscales. OBJ-3 Gestión de Productos Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Descripción El sistema gestionará, las altas, bajas y modificaciones de los productos y servicios. Subobjetivos Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 03: Objetivo 3. Gestión de Productos. GREENGROCERS APPLICATION Daniel Alonso Arias 30 II MANUAL TÉCNICO OBJ-4 Gestión de Contactos Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Descripción El sistema gestionará, las altas, bajas y modificaciones de los contactos. Subobjetivos OBJ-4.1 - Gestión de Clientes OBJ-4.2 - Gestión de Proveedores Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 04: Objetivo 4. Gestión de Contactos OBJ-5 Gestión de Datos Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Descripción El sistema gestionará tanto las copias de seguridad de los datos, como la eliminación de datos obsoletos Subobjetivos OBJ-5.1 - Gestión de Copias de Seguridad OBJ-5.2 - Gestión de Datos Obsoletos Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 05: Objetivo 5. Gestión de Datos. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 31 8.3. Especificación de Requisitos La especificación de requisitos de software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar. El objetivo es definir de forma clara, precisa, completa y verificable, todas las funcionalidades y restricciones del sistema que se desea construir. Esta documentación está sujeta a revisiones por el grupo de usuarios que se recogerán por medio de sucesivas versiones del documento, hasta alcanzar su aprobación por parte del grupo de usuarios. 8.3.1. Requisitos de información Esta subsección debe contener la lista de requisitos de almacenamiento y de restricciones de información que sea hayan identificado. 8.3.1.1. Requisitos de almacenamiento de información IRQ-1 Información de un cliente Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-4.1 - Gestión de Clientes Requisitos asociados Descripción El sistema deberá almacenar la información correspondiente a cada cliente: Datos específicos Nombre y apellidos o razón social NIF/CIF Dirección completa Teléfonos Cuenta bancaria Descripción Tiempo de vida Medio Máximo Varios años Ilimitado Ocurrencias simultáneas Medio Máximo 1 1 Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 06: Requisito de información 1. Información de un cliente. GREENGROCERS APPLICATION Daniel Alonso Arias 32 II MANUAL TÉCNICO IRQ-2 Información de un Proveedor de Fruta Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-4.2 - Gestión de Proveedores Requisitos asociados Descripción El sistema deberá almacenar la información correspondiente a cada proveedor: Datos específicos Nombre y apellidos o razón social NIF/CIF Dirección completa Teléfonos Cuenta bancaria Descripción Tiempo de vida Medio Máximo Varios años Ilimitado Ocurrencias simultáneas Medio Máximo 1 1 Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 07: Requisito de información 2. Información de un proveedor. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 33 IRQ-3 Información de un Producto Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-3 - Gestión de Productos Requisitos asociados Descripción El sistema deberá almacenar la información correspondiente a cada producto: Datos específicos Nombre Precio unitario Tipo de IVA Descripción Foto Tiempo de vida Medio Máximo Varios años Ilimitado Ocurrencias simultáneas Medio Máximo 1 1 Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 08: Requisito de información 3. Información de un producto GREENGROCERS APPLICATION Daniel Alonso Arias 34 II MANUAL TÉCNICO IRQ-4 Información de una Factura de Compra Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1.1 - Gestión de Facturas OBJ-1.1.2 - Gestión de Facturas de Compras Requisitos asociados IRQ-1 - Información de un Cliente IRQ-2 - Información de un Proveedor Descripción El sistema deberá almacenar la información correspondiente a cada Factura: Datos específicos Contacto Fecha Total factura Tipo de operación IVA Tipo de IVA Equivalencia Identificador Concepto Tiempo de vida Medio Máximo Varios años Ilimitado Ocurrencias simultáneas Medio Máximo 1 1 Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) . Tabla nº 09: Requisito de información 4. Información de una Factura de Compra. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 41 IRQ-12 Información de números de serie Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 - Gestión de Facturación OBJ-3 - Gestión de Productos OBJ-4 - Gestión de Contactos Requisitos asociados Descripción El sistema deberá almacenar el número correspondiente al siguiente identificador para: Datos específicos Factura venta Factura compra Albarán Producto Cliente Proveedor Tiempo de vida Medio Máximo Varios años Ilimitado Ocurrencias simultáneas Medio Máximo 1 1 Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 17: Requisito de información 12. Información de números de serie. IRQ-13 Información de fechas de ejecución Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-5Gestión de datos Requisitos asociados Descripción El sistema deberá almacenar la fecha en la que se realizó el último backup de la BBDD Datos específicos Tiempo de vida Medio Máximo Varios años Ilimitado Ocurrencias simultáneas Medio Máximo 1 1 Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 18: Requisito de información 13. Información de fechas de ejecución. GREENGROCERS APPLICATION Daniel Alonso Arias 42 II MANUAL TÉCNICO IRQ-14 Información de Gastos y Facturas Recibidas Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1.1.3 - Gestión de Gastos y Facturas Recibidas Requisitos asociados Descripción El sistema deberá almacenar la información correspondiente a cada gasto o factura recibida: Datos específicos Proveedor NIF/CIF Número de factura Fecha Tipo de operación Concepto Total Tipo de IVA IVA aplicado Tiempo de vida Medio Máximo Varios años Ilimitado Ocurrencias simultáneas Medio Máximo 1 1 Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 19: Requisito de información 14. Información de Gastos y Facturas Recibidas. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 43 IRQ-15 Información de Resúmenes Fiscales Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-2 - Gestión de Documentos Fiscales Requisitos asociados IRQ-4 Información de una Factura de Compra IRQ-5 Información de una Factura de Venta IRQ-14 Información de Gastos y Facturas Recibidas Descripción El sistema deberá generar la documentación correspondiente a los resúmenes solicitados, para su posterior uso por parte del usuario. Datos específicos Tiempo de vida Medio Máximo Varios años Ilimitado Ocurrencias simultáneas Medio Máximo 1 1 Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 20: Requisito de información 15. Información de Resúmenes Fiscales. GREENGROCERS APPLICATION Daniel Alonso Arias 44 II MANUAL TÉCNICO 8.3.1.2. Requisitos de restricción de información Los requisitos de restricción representarán las reglas de negocio que se deben definir en la aplicación. En nuestro caso serán los siguientes: CRQ-1 Validar campos obligatorios Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 - Gestión de Facturación OBJ-2 - Gestión de Documentos Fiscales OBJ-3 - Gestión de Productos OBJ-4 - Gestión de Contactos Requisitos asociados IRQ-1 - Información de un Cliente IRQ-2 - Información de un Proveedor IRQ-3 - Información de un Producto IRQ-4 - Información de un Servicio/Gasto IRQ-5 - Información de un Factura IRQ-6 - Información de un Consumición (compra) IRQ-7 - Información de un Consumición (venta) IRQ-8 - Información de un Albarán IRQ-9 - Información de un Resumen Mensual IRQ-14 - Información de Gastos y Facturas Recibidas Descripción El sistema deberá de solicitar, al usuario, todos los datos que sean necesarios para su correcto funcionamiento. Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 21: Requisito restricción de información 1.Validar campos obligatorios. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 45 CRQ-2 Validar NIF-NIE-CIF Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 - Gestión de Facturación OBJ-4 - Gestión de Contactos Requisitos asociados IRQ-1 - Información de un Cliente IRQ-2 - Información de un Proveedor de Fruta IRQ-14 - Información de Gastos y Facturas Recibidas Descripción El sistema deberá de validar todas las entradas correspondientes a NIF-NIE-CIF. Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 22: Requisito restricción de información 2.Validar NIF-NIE-CIF. GREENGROCERS APPLICATION Daniel Alonso Arias 46 II MANUAL TÉCNICO CRQ-3 Validar formatos de datos Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 - Gestión de Facturación OBJ-3 - Gestión de Productos OBJ-4 - Gestión de Contactos Requisitos asociados IRQ-1 - Información de un Cliente IRQ-2 - Información de un Proveedor IRQ-3 - Información de un Producto IRQ-4 - Información de un Servicio/Gasto IRQ-5 - Información de un Factura IRQ-6 - Información de un Consumición (compra) IRQ-7 - Información de un Consumición (venta) IRQ-8 - Información de un Albarán IRQ-9 - Información de un Resumen Mensual IRQ-10 - Información de los tipos de IVA IRQ-13 - Información de fechas de ejecución IRQ-14 - Información de Gastos y Facturas Recibidas Descripción El sistema deberá validar el formato de los datos como Domicilio, Teléfonos, Email, Cuenta bancaria, Precios, Fechas, etc. Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 23: Requisito restricción de información 3.Validar formato de datos. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 47 CRQ-4 Validar la redundancia de clientes/proveedores Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes OBJ-4 - Gestión de Contactos Requisitos asociados IRQ-1 - Información de un Cliente IRQ-2 - Información de un Proveedor Descripción El sistema deberá validar que no existan en él dos clientes o dos proveedores iguales. (Distinto identificador, mismo NIF) Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 24: Requisito restricción de información 4. Validar la redundancia de clientes/proveedores. CRQ-5 Validar eliminación de un contacto Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-4 - Gestión de Contactos Requisitos asociados IRQ-1 - Información de un Cliente IRQ-2 - Información de un Proveedor IRQ-4 - Información de un Servicio/Gasto IRQ-5 - Información de un Factura IRQ-6 - Información de un Consumición (compra) IRQ-7 - Información de un Consumición (venta) IRQ-8 - Información de un Albarán IRQ-9 - Información de un Resumen Mensual Descripción El sistema deberá de validar, que la eliminación del contacto, no tiene consecuencias a efectos fiscales. El contacto no deberá tener ninguna factura ni albarán asociado. Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 25: Requisito restricción de información 5.Validar eliminación de un contacto GREENGROCERS APPLICATION Daniel Alonso Arias 48 II MANUAL TÉCNICO CRQ-6 Validar la redundancia de facturas/albaranes Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 - Gestión de Facturación Requisitos asociados IRQ-4 - Información de un Servicio/Gasto IRQ-5 - Información de un Factura IRQ-8 - Información de un Albarán Descripción El sistema deberá validar que no existen facturas o albaranes repetidos. (mismo identificador) Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 26: Requisito restricción de información 6. Validar la redundancia de facturas/albaranes. CRQ-7 Validar la redundancia de consumiciones en factura/albarán Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 - Gestión de Facturación Requisitos asociados IRQ-4 - Información de un Servicio/Gasto IRQ-5 - Información de un Factura IRQ-6 - Información de un Consumición (compra) IRQ-7 - Información de un Consumición (venta) IRQ-8 - Información de un Albarán Descripción El sistema deberá validar que no existen productos repetidos en un mismo pedido. Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 27: Requisito restricción de información 7. Validar la redundancia de consumiciones en factura/albarán. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 49 CRQ-8 Validar eliminación de un producto Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-3 - Gestión de Productos Requisitos asociados IRQ-6 - Información de un Consumición (compra) IRQ-7 - Información de un Consumición (venta) Descripción El sistema deberá de validar, que la eliminación del producto no tiene consecuencias a efectos fiscales. El producto no deberá estar contenido en ninguna factura ni albarán. Importancia Vital Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 28: Requisito restricción de información 8. Validar eliminación de un producto. GREENGROCERS APPLICATION Daniel Alonso Arias 50 II MANUAL TÉCNICO 8.3.2. Requisitos funcionales Los requisitos funcionales establecen los comportamientos del sistema. Un requisito funcional define una función del sistema de software o sus componentes. Una función es descrita como un conjunto de entradas, comportamientos y salidas. Los requerimientos funcionales pueden ser: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que se supone, un sistema debe cumplir. Los requerimientos de comportamiento para cada requerimiento funcional se muestran en los casos de uso. Son complementados por los requisitos no funcionales, que se enfocan en cambio en el diseño o la implementación. 8.3.2.1. Definición de actores Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas externos, además de entidades abstractas, como el tiempo. En el caso de los seres humanos se pueden ver a los actores como definiciones de rol por lo que un mismo individuo puede corresponder a uno o más Actores. Para que una entidad externa sea considerada un actor, debe cumplir dos condiciones:  Ser autónoma con respecto al software, es decir, que la actividad en la que utiliza la información suministrada por el software no esté subordinada a la de éste.  Mantener relación directa con el software o con entidades exteriores que desempeñan tareas subordinadas a la actividad del software. A continuación se muestran los actores que contendrá nuestra aplicación: ACT-1 Usuario Versión 1.0 - 18/05/2014 Autores Daniel Alonso Arias Fuentes Descripción Este actor representa a los usuarios que harán uso de la aplicación Comentarios (ninguno) Tabla nº 29: Actor Usuario. 8.3.2.2. Diagramas de casos de uso Un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la relación y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona una respuesta a eventos que se producen en el mismo. Proporcionan un medio para que desarrolladores, usuarios finales del sistema y expertos del dominio lleguen a una comprensión común del sistema. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 57 Seleccionar productosloop Usuario Vista Controlador Datos Tools 1 : Acceso a pedidos() 2 : Solicitar productos y clientes() 3 : Pedir datos productos y clientes() 4 : Devolver datos productos y clientes() 5 : Cargar productos y clientes() 6 : Mostrar productos y clientes() 7 : Seleccionar cliente() 8 : Mostrar datos cliente() 9 : Seleccionar producto() 10 : Mostrar datos producto() 11 : Solicitar pedido() 12 : Solicitar pedido() 13 : Guardar pedido() 14 : Imprimir pedido() 15 : Pedido guardado() 16 : Pedido guardado() 17 : Informar pedido guardado() 18 : Mostrar pedido() Figura nº 13. Diagrama de Secuencia Realizar pedido con un cliente existente GREENGROCERS APPLICATION Daniel Alonso Arias 58 II MANUAL TÉCNICO UC-2 Realizar pedido con un cliente nuevo Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 Gestión de Facturación OBJ-1.1 - Gestión de Facturas OBJ-1.1.1 - Gestión de Facturas de Ventas OBJ-1.2 - Gestión de Albaranes OBJ-1.2.1 - Gestión de Albaranes de Ventas OBJ-4 Gestión de Contactos Requisitos asociados IRQ-1 Información de un cliente IRQ-3 Información de un Producto IRQ-5 Información de una Factura de Venta IRQ-7 Información de una Consumición (venta) IRQ-8 Información de un Albarán IRQ-10 Información de los tipos de IVA IRQ-12 Información de números de serie CRQ-1 Validar campos obligatorios CRQ-2 Validar NIF-NIE-CIF CRQ-3 Validar formatos de datos CRQ-4 Validar la redundancia de clientes/proveedores CRQ-7 Validar la redundancia de consumiciones en factura/albarán Descripción Se creará un nuevo pedido para un cliente que estuviera dado de alta en el sistema. Precondición - Secuencia normal Paso Acción p1 Acceder a pedidos p2 Introducir datos del cliente p3 Seleccionar productos p4 Solicitar pedido (guardar cliente y pedido e imprimir pedido) Postcondición Se genera un nuevo pedido para el cliente que se da de alta. Excepciones Paso Acción p1 Error si no están informados todos los campos obligatorios. No se lanza el pedido hasta que se supere. p2 Error si los datos no son correctos. No se lanza el pedido hasta que se supere. p3 Error si el cliente ya está dado de alta. No se lanza el pedido hasta que se supere. Frecuencia 1 vez/ cada vez que se solicite. Importancia Vital Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 31: Caso de uso xx. Realizar pedido con un cliente nuevo. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 59 Selecionar productoloop Usuario Vista Controlador Datos Tools 1 : Acceso a pedidos() 2 : Solicitar productos y clientes() 3 : Pedir datos productos y clientes() 4 : Devolver datos productos y clientes() 5 : Cargar productos y clientes() 6 : Mostrar productos y clientes() 7 : Introducir datos cliente() 8 : Validar cliente() 9 : Mostrar datos cliente() 10 : Seleccionar producto() 11 : Mostrar datos del producto() 12 : Solicitar pedido() 13 : Solicitar pedido() 14 : Guardar pedido() 15 : Guardar cliente() 16 : Imprimir pedido() 17 : Cliente guardado() 18 : Cliente guardado() 19 : Informar cliente guardado() 20 : Pedido guardado() 21 : Pedido guardado() 22 : Informar pedido guardado() 23 : Mostrar pedido() Figura nº 14. Diagrama de Secuencia Realizar pedido con un cliente nuevo GREENGROCERS APPLICATION Daniel Alonso Arias 60 II MANUAL TÉCNICO UC-3 Realizar pedido editando el cliente Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 Gestión de Facturación OBJ-1.1 - Gestión de Facturas OBJ-1.1.1 - Gestión de Facturas de Ventas OBJ-1.2 - Gestión de Albaranes OBJ-1.2.1 - Gestión de Albaranes de Ventas OBJ-4 Gestión de Contactos Requisitos asociados IRQ-1 Información de un cliente IRQ-3 Información de un Producto IRQ-5 Información de una Factura de Venta IRQ-7 Información de una Consumición (venta) IRQ-8 Información de un Albarán IRQ-10 Información de los tipos de IVA IRQ-12 Información de números de serie CRQ-1 Validar campos obligatorios CRQ-3 Validar formatos de datos CRQ-7 Validar la redundancia de consumiciones en factura/albarán Descripción Se creará un nuevo pedido para un cliente que estuviera dado de alta en el sistema, editando a éste. Precondición Existe algún cliente en el sistema. Secuencia normal Paso Acción p1 Acceder a pedidos p2 Seleccionar cliente p3 Introducir datos del cliente p4 Seleccionar productos p5 Solicitar pedido (guardar cliente y pedido e imprimir pedido) Postcondición Se generará un nuevo pedido para un cliente, y se modificarán sus datos. Excepciones Paso Acción p1 Error si no están informados todos los campos obligatorios. No se lanza el pedido hasta que se supere. p2 Error si los datos no son correctos. No se lanza el pedido hasta que se supere. Frecuencia 1 vez/ cada vez que se solicite. Importancia Alta Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 32: Caso de uso xx. Realizar pedido editando el cliente. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 61 Seleccionar productoloop Usuario Vista Controlador Datos Tools 1 : Acceder a pedidos() 2 : Solicitar productos y clientes() 3 : Pedir datos productos y clientes() 4 : Devolver datos productos y clientes() 5 : Cargar productos y clientes() 6 : Mostrar productos y clientes() 7 : Seleccionar cliente() 8 : Mostrar datos del cliente() 9 : Introducir datos cliente() 10 : Mostrar datos del cliente() 11 : Seleccionar producto() 12 : Mostrar datos del producto() 13 : Solicitar pedido() 14 : Solicitar pedido() 15 : Guardar pedido() 16 : Guardar cliente() 17 : Imprimir pedido() 18 : Cliente editado() 19 : Cliente editado() 20 : Pedido guardado() 21 : Informar cliente editado() 22 : Pedido guardado() 23 : Informar pedido guardado() 24 : Mostar pedido() Figura nº 15. Diagrama de Secuencia Realizar pedido editando el cliente GREENGROCERS APPLICATION Daniel Alonso Arias 62 II MANUAL TÉCNICO UC-4 Ver listado de productos Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-3 Gestión de Productos Requisitos asociados IRQ-3 Información de un Producto CRQ-1 Validar campos obligatorios CRQ-3 Validar formatos de datos Descripción Se mostrará un listado para consultar el listado de productos Precondición Existe algún producto en el sistema. Secuencia normal Paso Acción p1 Acceder al listado de productos Postcondición Se muestra el listado de productos Excepciones Paso Acción - Frecuencia 1 vez/ cada vez que se solicite. Importancia Vital Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 33: Caso de uso xx. Ver listado de productos. Usuario Vista Controlador Datos 1 : Acceder a productos() 2 : Solicitar productos() 3 : Pedir datos productos() 4 : Devolver datos productos() 5 : Cargar productos() 6 : Mostrar productos() Figura nº 16. Diagrama de Secuencia Ver listado de productos GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 63 UC-5 Añadir producto Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-3 Gestión de Productos Requisitos asociados IRQ-3 Información de un Producto IRQ-12 Información de números de serie CRQ-1 Validar campos obligatorios CRQ-3 Validar formatos de datos Descripción Se creará una nueva factura para un cliente que estuviera dado de alta en el sistema. Precondición - Secuencia normal Paso Acción p1 Acceder a productos p2 Introducir datos del producto p3 Guardar producto Postcondición Se creará un nuevo producto en el sistema. Excepciones Paso Acción p1 Error si no están informados todos los campos obligatorios. No se guarda el producto hasta que se supere. p2 Error si los datos no son correctos. No se guarda el producto hasta que se supere. Frecuencia 1 vez/ cada vez que se solicite. Importancia Vital Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 34: Caso de uso xx. Añadir producto. GREENGROCERS APPLICATION Daniel Alonso Arias 64 II MANUAL TÉCNICO Usuario Vista Controlador Datos 1 : Acceder al formulario de producto() 2 : Mostrar formulario de producto() 3 : Introducir datos del producto() 4 : Mostrar datos del producto() 5 : Solicitar alta del producto() 6 : Validar producto() 7 : Solicitar confirmación() 8 : Confirmar alta() 9 : Solicitar ID de producto() 10 : Solicitar ID de producto() 11 : Devolver ID de producto() 12 : Cargar ID de producto() 13 : Guardar producto() 14 : Producto guardado() 15 : Producto guardado() 16 : Informar producto guardado() Figura nº 17. Diagrama de Secuencia Añadir producto GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 65 UC-6 Editar producto Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-3 Gestión de Productos Requisitos asociados IRQ-3 Información de un Producto CRQ-1 Validar campos obligatorios CRQ-3 Validar formatos de datos Descripción Se editará un producto que estuviera dado de alta en el sistema. Precondición Existe algún producto en el sistema. Secuencia normal Paso Acción p1 Acceder a productos p2 Seleccionar producto p3 Modificar datos del producto p4 Guardar el producto Postcondición Se editará el producto seleccionado Excepciones Paso Acción p1 Error si no están informados todos los campos obligatorios. No se guarda el producto hasta que se supere. p2 Error si los datos no son correctos. No se guarda el producto hasta que se supere. Frecuencia 1 vez/ cada vez que se solicite. Importancia Alta Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 35: Caso de uso xx. Editar producto. GREENGROCERS APPLICATION Daniel Alonso Arias 66 II MANUAL TÉCNICO Usuario Controlador DatosVista 1 : Seleccionar producto() 2 : Producto seleccionado() 3 : Acceder a editar producto() 4 : Solicitar datos del producto() 5 : Buscar producto() 6 : Cargar producto() 7 : Mostrar producto() 8 : Editar datos producto() 9 : Mostrar datos producto() 10 : Solicitar modificación del producto() 11 : Validar producto() 12 : Solicitar confirmación() 13 : Confirmar edición() 14 : Guardar producto() 15 : Guardar producto() 16 : Producto guardado() 17 : Producto guardado() 18 : Informar producto guardado() Figura nº 18. Diagrama de Secuencia Editar producto GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 73 Usuario Vista Controlador Datos 1 : Acceder al formulario de cliente() 2 : Mostrar formulario de cliente() 3 : Introducir datos del cliente() 4 : Mostrar datos del cliente() 5 : Solicitar alta del cliente() 6 : Validar cliente() 7 : Solicitar confirmación() 8 : Confirmar alta() 9 : Solicitar ID de cliente() 10 : Soicitar ID de cliente() 11 : Devolver ID de cliente() 12 : Cargar ID de cliente() 13 : Guardar cliente() 14 : Cliente guardado() 15 : Cliente guardado() 16 : Informar cliente guardado() Figura nº 23. Diagrama de Secuencia Añadir cliente GREENGROCERS APPLICATION Daniel Alonso Arias 74 II MANUAL TÉCNICO UC-12 Editar cliente Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-4 Gestión de Contactos Requisitos asociados IRQ-1 Información de un cliente CRQ-1 Validar campos obligatorios CRQ-3 Validar formatos de datos Descripción Editar un cliente. Precondición Debe existir al menos un cliente en el sistema Secuencia normal Paso Acción p1 Acceder al formulario de cliente p2 Modificar datos del cliente p3 Guardar cliente Postcondición Se modificarán los datos del cliente. Excepciones Paso Acción p1 Error si no están informados todos los campos obligatorios. No se modificará el cliente hasta que se supere. p2 Error si los datos no son correctos. No se editará el cliente hasta que se supere. Frecuencia 1 vez/ cada vez que se solicite. Importancia Media Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 41: Caso de uso xx. Editar cliente. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 75 Usuario Vista Controlador Datos 1 : Seleccionar cliente() 2 : Cliente selccionado() 3 : Acceder a editar cliente() 4 : Solicitar datos del cliente() 5 : Buscar cliente() 6 : Cargar cliente() 7 : Mostrar cliente() 8 : Editar datos del cliente() 9 : Mostrar datos del cliente() 10 : Solicitar modificación del cliente() 11 : Validar cliente() 12 : Solicitar confirmación() 13 : Confirmar edición() 14 : Guardar cliente() 15 : Guardar cliente() 16 : Cliente guardado() 17 : Cliente guardado() 18 : Informar de cliente guardado() Figura nº 24. Diagrama de Secuencia Editar cliente GREENGROCERS APPLICATION Daniel Alonso Arias 76 II MANUAL TÉCNICO UC-13 Eliminar cliente Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-4 Gestión de Contactos Requisitos asociados IRQ-1 Información de un cliente CRQ-5 Validar eliminación de un contacto Descripción Eliminar un cliente. Precondición Debe existir al menos un cliente en el sistema Secuencia normal Paso Acción p1 Seleccionar cliente p2 Eliminar cliente Postcondición Se eliminará el cliente seleccionado Excepciones Paso Acción p1 Error si el cliente está contenido en un pedido no obsoleto. No se eliminará el cliente. Frecuencia 1 vez/ cada vez que se solicite. Importancia Alta Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 42: Caso de uso xx. Eliminar cliente. Controlador DatosUsuario Vista 1 : Seleccionar cliente() 2 : Cliente seleccionado() 3 : Eliminar cliente() 4 : Validar eliminación() 5 : Validar eliminación() 6 : Cliente eliminable() 7 : Cliente eliminable() 8 : Solicitar confirmación() 9 : Confirmar eliminación() 10 : Eliminar cliente() 11 : Eliminar cliente() 12 : Cliente eliminado() 13 : Cliente eliminado() 14 : Informar cliente eliminado() Figura nº 25. Diagrama de Secuencia Eliminar cliente GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 77 UC-14 Imprimir listado de clientes Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-4 Gestión de Contactos Requisitos asociados IRQ-1 Información de un cliente Descripción Imprimir el listado de clientes. Precondición Debe existir al menos un cliente en el sistema Secuencia normal Paso Acción p1 Imprimir listado de clientes Postcondición Se imprimirá el listado de clientes Excepciones Paso Acción p1 Si no existen clientes se imprimirá un listado vacío. Frecuencia 1 vez/ cada vez que se solicite. Importancia Baja Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 43: Caso de uso xx. Imprimir listado de clientes. Usuario Vista Tools 1 : Solicitar imprimir clientes() 2 : Imprimir clientes() 3 : Mostrar clientes() Figura nº 26. Diagrama de Secuencia Imprimir listado de clientes GREENGROCERS APPLICATION Daniel Alonso Arias 78 II MANUAL TÉCNICO UC-15 Ver facturas del cliente Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 Gestión de Facturación OBJ-1.1 Gestión de Facturas OBJ-1.1.1 Gestión de Facturas de Ventas OBJ-4 Gestión de Contactos Requisitos asociados IRQ-1 Información de un cliente IRQ-5 Información de una Factura de Venta Descripción Se mostrará un listado con las facturas del cliente seleccionado. Precondición Existe algún cliente en el sistema. Secuencia normal Paso Acción p1 Seleccionar cliente p2 Acceder a las facturas p3 Mostrar listado de facturas Postcondición Se mostrarán las facturas del cliente Excepciones Paso Acción p1 Si no existen facturas para el cliente, se mostrará un listado vacío Frecuencia 1 vez/ cada vez que se solicite. Importancia Alta Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 44: Caso de uso xx. Ver facturas del cliente. Usuario Vista Controlador Datos 1 : Seleccionar cliente() 2 : Cliente seleccionado() 3 : Ver facturas() 4 : Solicitar facturas cliente() 5 : Solicitar facturas cliente() 6 : Devolver facturas cliente() 7 : Cargar facturas cliente() 8 : Mostrar facturas cliente() Figura nº 27. Diagrama de Secuencia Ver facturas del cliente GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 79 UC-16 Consultar factura Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 Gestión de Facturación OBJ-1.1 Gestión de Facturas OBJ-1.1.1 Gestión de Facturas de Ventas OBJ-1.1.2 Gestión de Facturas de Compras OBJ-1.1.3 Gestión de Gastos y Facturas Recibidas OBJ-1.3 Gestión de Resúmenes Mensuales Requisitos asociados IRQ-4 Información de una Factura de Compra IRQ-5 Información de una Factura de Venta IRQ-6 Información de una Consumición (compra) IRQ-7 Información de una Consumición (venta) IRQ-9 Información de un Resumen Mensual Descripción Consultar la factura seleccionada del listado de un cliente/proveedor Precondición Existe alguna factura para el cliente/proveedor seleccionado. Secuencia normal Paso Acción p1 Seleccionar factura p2 Acceder a la factura p3 Mostrar la factura Postcondición Se mostrará la factura seleccionada. Excepciones Paso Acción - Frecuencia 1 vez/ cada vez que se solicite. Importancia Alta Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 45: Caso de uso xx. Consultar factura. GREENGROCERS APPLICATION Daniel Alonso Arias 80 II MANUAL TÉCNICO ControladorVistaUsuario Datos 1 : Seleccionar factura() 2 : Marcar selección() 3 : Acceso a consulta de factura() 4 : Solicitar datos factura() 5 : Solicitar datos factura() 6 : Devolver datos factura() 7 : Cargar datos factura() 8 : Mostrar datos factura() Figura nº 28. Diagrama de Secuencia Consultar factura GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 81 UC-17 Editar factura Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 Gestión de Facturación OBJ-1.1 Gestión de Facturas OBJ-1.1.1 Gestión de Facturas de Ventas OBJ-1.1.2 Gestión de Facturas de Compras OBJ-1.1.3 Gestión de Gastos y Facturas Recibidas Requisitos asociados IRQ-4 Información de una Factura de Compra IRQ-5 Información de una Factura de Venta IRQ-6 Información de una Consumición (compra) IRQ-7 Información de una Consumición (venta) CRQ-1 Validar campos obligatorios CRQ-3 Validar formatos de datos CRQ-7 Validar la redundancia de consumiciones en factura/albarán CRQ-8 Validar eliminación de un producto Descripción Editar la factura seleccionada del listado de un cliente/proveedor Precondición Existe alguna factura para el cliente/proveedor seleccionado. Secuencia normal Paso Acción p1 Editar los datos de la factura p2 Validar datos de la factura p3 Guardar la factura Postcondición Se guardarán los nuevos datos en la factura. Excepciones Paso Acción p1 Error si no están informados todos los campos obligatorios. No se guarda el pedido hasta que se supere. p2 Error si los datos no son correctos. No se guarda el pedido hasta que se supere. Frecuencia 1 vez/ cada vez que se solicite. Importancia Alta Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 46: Caso de uso xx. Editar factura. GREENGROCERS APPLICATION Daniel Alonso Arias 82 II MANUAL TÉCNICO Usuario Vista Controlador Datos 1 : Editar datos de factura() 2 : Mostrar datos de factura() 3 : Guardar cambios factura() 4 : Validar datos del factura() 5 : Guardar cambios factura() 6 : Guardar cambios factura() 7 : Factura guardada() 8 : Factura guardada() 9 : Informar de factura guardada() Figura nº 29. Diagrama de Secuencia Editar factura GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 89 UC-23 Imprimir albarán Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 Gestión de Facturación OBJ-1.2 Gestión de Albaranes OBJ-1.2.1 Gestión de Albaranes de Ventas Requisitos asociados IRQ-7 Información de una Consumición (venta) IRQ-8 Información de un Albarán Descripción Imprimir el albarán seleccionado del listado de un cliente. Precondición Existe algún albarán para el cliente seleccionado. Secuencia normal Paso Acción p1 Imprimir el albarán. Postcondición Se imprimirá el albarán seleccionado. Excepciones Paso Acción - Frecuencia 1 vez/ cada vez que se solicite. Importancia Alta Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 52: Caso de uso xx. Imprimir albarán. Usuario Vista Tools 1 : Solicitar impresión() 2 : Imprimir albarán() 3 : Mostrar albarán() Figura nº 35. Diagrama de Secuencia Imprimir albarán GREENGROCERS APPLICATION Daniel Alonso Arias 90 II MANUAL TÉCNICO UC-24 Eliminar albarán Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 Gestión de Facturación OBJ-1.2 Gestión de Albaranes OBJ-1.2.1 Gestión de Albaranes de Ventas Requisitos asociados IRQ-8 Información de un Albarán Descripción Eliminar el albarán seleccionado del listado de un cliente. Precondición Existe alguna factura para el cliente seleccionado. Secuencia normal Paso Acción p1 Seleccionar albarán p2 Eliminar albarán Postcondición Se eliminará el albarán seleccionado. Excepciones Paso Acción - Frecuencia 1 vez/ cada vez que se solicite. Importancia Alta Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 53: Caso de uso xx. Eliminar albarán. Usuario DatosControladorVista 1 : Seleccionar albarán() 2 : Marcar selección() 3 : Solicitar eliminación() 4 : Pedir confirmación() 5 : Confirmar eliminación() 6 : Eliminar albarán() 7 : Eliminar albarán() 8 : Albarán eliminado() 9 : Albarán eliminado() 10 : Imformar de eliminación de albarán() Figura nº 36. Diagrama de Secuencia Eliminar albarán GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 91 UC-25 Ver listado de proveedores Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-4 Gestión de Contactos Requisitos asociados IRQ-2 Información de un Proveedor de Fruta Descripción Se mostrará un listado con todos los proveedores. Precondición Existe algún proveedor en el sistema. Secuencia normal Paso Acción p1 Acceder a proveedores p2 Mostrar listado de proveedores Postcondición Se mostrará el listado de proveedores Excepciones Paso Acción p1 Si no existen proveedores se mostrará un listado vacío Frecuencia 1 vez/ cada vez que se solicite. Importancia Vital Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 54: Caso de uso xx. Ver listado de proveedores. Usuario Vista Controlador Datos 1 : Acceder a proveedores() 2 : Solicitar proveedores() 3 : Pedir datos proveedores() 4 : Devolver datos proveedores() 5 : Cargar proveedores() 6 : Mostrar proveedores() Figura nº 37. Diagrama de Secuencia Ver listado de proveedores GREENGROCERS APPLICATION Daniel Alonso Arias 92 II MANUAL TÉCNICO UC-26 Añadir proveedor Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-4 Gestión de Contactos Requisitos asociados IRQ-2 Información de un Proveedor de Fruta CRQ-1 Validar campos obligatorios CRQ-2 Validar NIF-NIE-CIF CRQ-3 Validar formatos de datos CRQ-4 Validar la redundancia de clientes/proveedores Descripción Añadir un nuevo proveedor. Precondición - Secuencia normal Paso Acción p1 Acceder al formulario de proveedor p2 Rellenar formulario p3 Guardar proveedor Postcondición Se creará un nuevo cliente en el sistema Excepciones Paso Acción p1 Error si no están informados todos los campos obligatorios. No se creará el proveedor hasta que se supere. p2 Error si el cliente ya está dado de alta. No se dará de alta el proveedor. p3 Error si los datos no son correctos. No se creará el proveedor hasta que se supere. Frecuencia 1 vez/ cada vez que se solicite. Importancia Importante Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 55: Caso de uso xx. Añadir proveedor. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 93 ControladorUsuario Vista Datos 1 : Acceder al formulario de proveedor() 2 : Mostrar formulario de proveedor() 3 : Introducir datos proveedor() 4 : Mostrar datos proveedor() 5 : Solicitar alta proveedor() 6 : Validar proveedor() 7 : Solicitar confirmación() 8 : Confirmar alta() 9 : Solicitar ID proveedor() 10 : Solicitar ID proveedor() 11 : Devolver ID proveedor() 12 : Cargar ID proveedor() 13 : Guardar proveedor() 14 : Proveedor guardado() 15 : Proveedor guardado() 16 : Informar de proveedor guardado() Figura nº 38. Diagrama de Secuencia Añadir proveedor GREENGROCERS APPLICATION Daniel Alonso Arias 94 II MANUAL TÉCNICO UC-27 Editar proveedor Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-4 Gestión de Contactos Requisitos asociados IRQ-2 Información de un Proveedor de Fruta CRQ-1 Validar campos obligatorios CRQ-3 Validar formatos de datos Descripción Editar un proveedor. Precondición Debe existir al menos un proveedor en el sistema Secuencia normal Paso Acción p1 Acceder al formulario de proveedor p2 Modificar datos del proveedor p3 Guardar proveedor Postcondición Se modificarán los datos del proveedor. Excepciones Paso Acción p1 Error si no están informados todos los campos obligatorios. No se modificará el proveedor hasta que se supere. p2 Error si los datos no son correctos. No se editará el proveedor hasta que se supere. Frecuencia 1 vez/ cada vez que se solicite. Importancia Media Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 56: Caso de uso xx. Editar proveedor. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 95 Usuario Vista Controlador Datos 1 : Seleccionar proveedor() 2 : Proveedro seleccionado() 3 : Acceder a editar proveedor() 4 : Solicitar datos proveedor() 5 : Buscar proveedor() 6 : Cargar proveedor() 7 : Mostrar proveedor() 8 : Editar datos del proveedor() 9 : Mostrar datos del proveedor() 10 : Solicitar modificación del proveedor() 11 : Validar proveedor() 12 : Solicitar confirmación() 13 : Confirmar edición() 14 : Guardar proveedor() 15 : Guardar proveedor() 16 : Proveedor guardado() 17 : Proveedor guardado() 18 : Informar de proveedor guardado() Figura nº 39. Diagrama de Secuencia Editar proveedor GREENGROCERS APPLICATION Daniel Alonso Arias 96 II MANUAL TÉCNICO UC-28 Eliminar proveedor Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-4 Gestión de Contactos Requisitos asociados IRQ-2 Información de un Proveedor de Fruta CRQ-5 Validar eliminación de un contacto Descripción Eliminar un proveedor. Precondición Debe existir al menos un proveedor en el sistema Secuencia normal Paso Acción p1 Seleccionar proveedor p2 Eliminar proveedor Postcondición Se eliminará el proveedor seleccionado Excepciones Paso Acción p1 Error si el proveedor está contenido en un pedido no obsoleto. No se eliminará el proveedor. Frecuencia 1 vez/ cada vez que se solicite. Importancia Alta Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 57: Caso de uso xx. Eliminar proveedor. Usuario Vista Controlador Datos 1 : Seleccionar proveedor() 2 : Proveedor seleccionado() 3 : Eliminar proveedor() 4 : Validar elimación() 5 : Validar elimación() 6 : Proveedor eliminable() 7 : Proveedor eliminable() 8 : Solicitar confirmación() 9 : Confirmar eliminación() 10 : Eliminar proveedor() 11 : Eliminar proveedor() 12 : Proveedor eliminado() 13 : Proveedor eliminado() 14 : Informar proveedor eliminado() Figura nº 40. Diagrama de Secuencia Eliminar proveedor GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 97 UC-29 Imprimir listado de proveedores Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-4 Gestión de Contactos Requisitos asociados IRQ-2 Información de un Proveedor de Fruta Descripción Imprimir el listado de proveedores. Precondición Debe existir al menos un proveedor en el sistema Secuencia normal Paso Acción p1 Imprimir listado de proveedores Postcondición Se imprimirá el listado de proveedores Excepciones Paso Acción p1 Si no existen proveedores se imprimirá un listado vacío. Frecuencia 1 vez/ cada vez que se solicite. Importancia Baja Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 58: Caso de uso xx. Imprimir listado de proveedores. Usuario Vista Tools 1 : Solicitar impresión de proveedores() 2 : Imprimir proveedores() 3 : Mostrar proveedores() Figura nº 41. Diagrama de Secuencia Imprimir listado de proveedores GREENGROCERS APPLICATION Daniel Alonso Arias 98 II MANUAL TÉCNICO UC-30 Ver facturas del proveedor Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 Gestión de Facturación OBJ-1.1 Gestión de Facturas OBJ-1.1.2 Gestión de Facturas de Compras OBJ-4 Gestión de Contactos Requisitos asociados IRQ-2 Información de un Proveedor de Fruta IRQ-4 Información de una Factura de Compra Descripción Se mostrará un listado con las facturas del proveedor seleccionado. Precondición Existe algún proveedor en el sistema. Secuencia normal Paso Acción p1 Seleccionar proveedor p2 Acceder a las facturas p3 Mostrar listado de facturas Postcondición Se mostrarán las facturas del proveedor Excepciones Paso Acción p1 Si no existen facturas para el proveedor, se mostrará un listado vacío Frecuencia 1 vez/ cada vez que se solicite. Importancia Alta Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 59: Caso de uso xx. Ver facturas del proveedor. Usuario Vista Controlador Datos 1 : Seleccionar proveedor() 2 : Proveedor seleccionado() 3 : Ver facturas() 4 : Solicitar facturas proveedor() 5 : Solicitar facturas proveedor() 6 : Devolver facturas proveedor() 7 : Cargar facturas proveedor() 8 : Mostrar facturas proveedor() Figura nº 42. Diagrama de Secuencia Ver facturas del proveedor GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 105 UC-35 Realizar resumen mensual Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 Gestión de Facturación OBJ-1.3 - Gestión de Resúmenes Mensuales IRQ-1 Información de un cliente IRQ-5 Información de una Factura de Venta Requisitos asociados IRQ-9 Información de un Resumen Mensual CRQ-9 Validar resolución del resumen mensual Descripción Crear una factura de resumen mensual para un cliente con albaranes. Precondición Existe algún cliente con albaranes. Secuencia normal Paso Acción p1 Acceder a resumen mensual p2 Seleccionar cliente y mes/año p3 Generar resumen mensual p4 Guardar el resumen mensual Postcondición Se guardará el resumen mensual. Excepciones Paso Acción p1 Si el resumen mensual ya ha sido generado con anterioridad, sólo se podrá visualizar e imprimir. Frecuencia 1 vez/ cada vez que se solicite. Importancia Alta Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 64: Caso de uso xx. Realizar resumen mensual. Usuario Vista Controlador Datos 1 : Acceder a resumen mensual() 2 : Mostrar formulario de datos() 3 : Seleccionar datos() 4 : Mostrar datos seleccionados() 5 : Acceder a facturar() 6 : Solicitar confirmación() 7 : Confirmar acceso() 8 : Mostrar resumen mensual() 9 : Facturar resumen() 10 : Guardar resumen() 11 : Guardar resumen() 12 : Resumen guardado() 13 : Resumen guardado() 14 : Informar de resumen guardado() Figura nº 47. Diagrama de Secuencia Realizar resumen mensual GREENGROCERS APPLICATION Daniel Alonso Arias 106 II MANUAL TÉCNICO UC-36 Resumen fiscal de un contacto Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-2 Gestión de Documentos Fiscales Requisitos asociados IRQ-1 Información de un cliente IRQ-2 Información de un Proveedor de Fruta IRQ-4 Información de una Factura de Compra IRQ-5 Información de una Factura de Venta IRQ-9 Información de un Resumen Mensual IRQ-14 Información de Gastos y Facturas Recibidas IRQ-15 Información de Resúmenes Fiscales Descripción Crear un resumen fiscal de un contacto Precondición Existe algún cliente/proveedor con facturas Secuencia normal Paso Acción p1 Acceder a resúmenes fiscales p2 Seleccionar contacto y resto de datos p3 Mostrar resumen p4 Guardar resumen Postcondición Se mostrarán los datos del resumen, el cual se guardará en formato Excel y se podrá imprimir. Excepciones Paso Acción - Frecuencia 1 vez/ cada vez que se solicite. Importancia Alta Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 65: Caso de uso xx. Resumen fiscal de un contacto. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 107 Usuario Vista Controlador Datos Tools 1 : Acceder a los resúmenes() 2 : Mostrar formulario de modo() 3 : Seleccionar datos() 4 : Datos seleccionados() 5 : Seleccionar contacto() 6 : Cargar contacto() 7 : Mostrar contacto() 8 : Acceder al resumen() 9 : Buscar facturas() 10 : Buscar facturas() 11 : Cargar facturas() 12 : Cargar facturas() 13 : Mostrar resumen() 14 : Imprimir resumen() 15 : Guardar resumen() 16 : Guardar resumen() 17 : Guardar resumen() 18 : Resumen guardado() 19 : Resumen guardado() 20 : Informar de resumen guardado() 21 : Mostrar resumen() Figura nº 48. Diagrama de Secuencia Resumen fiscal de un contacto GREENGROCERS APPLICATION Daniel Alonso Arias 108 II MANUAL TÉCNICO UC-37 Resumen fiscal general Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-2 Gestión de Documentos Fiscales Requisitos asociados IRQ-1 Información de un cliente IRQ-2 Información de un Proveedor de Fruta IRQ-4 Información de una Factura de Compra IRQ-5 Información de una Factura de Venta IRQ-9 Información de un Resumen Mensual IRQ-14 Información de Gastos y Facturas Recibidas IRQ-15 Información de Resúmenes Fiscales Descripción Crear un resumen fiscal de todos los clientes o de todos los proveedores. Precondición Existe algún cliente/proveedor con facturas Secuencia normal Paso Acción p1 Acceder a resúmenes fiscales p2 Seleccionar datos p3 Mostrar resumen p4 Guardar resumen Postcondición Se mostrarán los datos del resumen, el cual se guardará en formato Excel y se podrá imprimir. Excepciones Paso Acción - Frecuencia 1 vez/ cada vez que se solicite. Importancia Alta Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 66: Caso de uso xx. Resumen fiscal general. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 109 Usuario Vista Controlador Datos Tools 1 : Acceder a los resúmenes() 2 : Mostrar formulario de modo() 3 : Seleccionar datos() 4 : Datos seleccionados() 5 : Acceder al resumen() 6 : Buscar facturas() 7 : Buscar facturas() 8 : Buscar facturas() 9 : Buscar facturas() 10 : Mostrar resumen() 11 : Imprimir resumen() 12 : Guardar resumen() 13 : Guardar resumen() 14 : Guardar resumen() 15 : Resumen guardado() 16 : Resumen guardado() 17 : Informar de resumen guardado() 18 : Mostrar resumen() Figura nº 49. Diagrama de Secuencia Resumen fiscal general GREENGROCERS APPLICATION Daniel Alonso Arias 110 II MANUAL TÉCNICO UC-38 Restaurar datos Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-5 Gestión de Datos Requisitos asociados IRQ-11 Repositorio de BBDD Descripción Restaurar una BBDD antigua. Precondición Existe algún backup de BBDD. Secuencia normal Paso Acción p1 Seleccionar BBDD p2 Restaurar BBDD Postcondición Se cargarán los datos de la BBDD seleccionada. Excepciones Paso Acción - Frecuencia 1 vez/ cada vez que se solicite. Importancia Vital Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 67: Caso de uso xx. Restaurar datos. Usuario Vista Controlador Datos 1 : Acceder a recuperar datos() 2 : Mostrar formulario de restaurar datos() 3 : Seleccionar BBDD() 4 : BBDD seleccionada() 5 : Restaurar BBDD() 6 : Solicitar confirmación() 7 : Confirmar restauración() 8 : Restaurar BBDD() 9 : Restaurar BBDD() 10 : BBDD restaurada() 11 : BBDD restaurada() 12 : Informar de BBDD restaurada() Figura nº 50. Diagrama de Secuencia Restaurar datos GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 111 UC-39 Eliminar datos obsoletos Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-5 Gestión de Datos Requisitos asociados Descripción Un demonio eliminará automáticamente las facturas con más de 5 años. Precondición - Secuencia normal Paso Acción p1 Buscar facturas obsoletas p2 Eliminar facturas obsoletas Postcondición Se eliminarán las facturas con más de 5 años. Excepciones Paso Acción - Frecuencia 1 vez/ cada vez que se lance el evento. Importancia Media Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 68: Caso de uso xx. Eliminar datos obsoletos. Usuario Vista Controlador Datos 1 : Lanzar busqueda de facturas() 2 : Buscar facturas obsoletas() 3 : Facturas encontradas() 4 : Facturas encontradas() 5 : Solicitar confirmación() 6 : Confirmar borrado() 7 : Solicitar borrado() 8 : Borrar facturas obsoletas() Figura nº 51. Diagrama de Secuencia Eliminar datos obsoletos GREENGROCERS APPLICATION Daniel Alonso Arias 112 II MANUAL TÉCNICO UC-40 Realizar un backup de BBDD Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-5 Gestión de Datos Requisitos asociados IRQ-13 Información de fechas de ejecución Descripción Un demonio realizará automáticamente una copia periódica de la BBDD Precondición - Secuencia normal Paso Acción p1 Buscar facturas obsoletas p2 Eliminar facturas obsoletas Postcondición Se eliminarán las facturas con más de 5 años. Excepciones Paso Acción - Frecuencia 1 vez/ cada vez que se lance el evento. Importancia Media Urgencia Inmediatamente Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 69: Caso de uso xx. Realizar un backup de BBDD. Usuario Vista Controlador Datos 1 : Lanzar backup de datos() 2 : Recuperar última fecha() 3 : Devolver fecha() 4 : Crear copia de BBDD() 5 : Backup BBDD realizado() 6 : Informar de backup BBDD realizado() Figura nº 52. Diagrama de Secuencia Realizar un backup de BBDD GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 113 8.3.3. Requisitos no funcionales Un requisito no funcional o atributo de calidad es, en la ingeniería de sistemas y la ingeniería de software, un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que no describen información a guardar, ni funciones a realizar. NFR-1 Necesidad de un sistema operativo Windows Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 - Gestión de Facturación OBJ-2 - Gestión de Documentos Fiscales OBJ-3 - Gestión de Productos OBJ-4 - Gestión de Contactos OBJ-5 - Gestión de Datos Requisitos asociados Descripción El sistema deberá tener como sistema operativo Windows, ya que usa una serie de librerías características de este sistema operativo. Importancia Importante Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 70: Requisito no funcional 1. Necesidad de un sistema operativo Windows. NFR-2 Uso de Microsoft Visual Studio Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 - Gestión de Facturación OBJ-2 - Gestión de Documentos Fiscales OBJ-3 - Gestión de Productos OBJ-4 - Gestión de Contactos OBJ-5 - Gestión de Datos Requisitos asociados Descripción Se ha usado esta plataforma para generar la aplicación Importancia Importante Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 71: Requisito no funcional 2. Uso de Microsoft Visual Studio. GREENGROCERS APPLICATION Daniel Alonso Arias 114 II MANUAL TÉCNICO NFR-3 Necesidad de una impresora Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 - Gestión de Facturación OBJ-2 - Gestión de Documentos Fiscales OBJ-3 - Gestión de Productos OBJ-4 - Gestión de Contactos OBJ-5 - Gestión de Datos Requisitos asociados Descripción El sistema deberá tener una impresora para imprimir tanto los pedidos como los resúmenes fiscales. Importancia Importante Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 72: Requisito no funcional 3. Necesidad de una impresora. NFR-4 Necesidad de Gestor de BBDD Versión 1.0 - 11/10/2013 Autores Daniel Alonso Arias Fuentes Objetivos asociados OBJ-1 - Gestión de Facturación OBJ-2 - Gestión de Documentos Fiscales OBJ-3 - Gestión de Productos OBJ-4 - Gestión de Contactos OBJ-5 - Gestión de Datos Requisitos asociados Descripción La aplicación necesita tener un gestor de BBDD Importancia Importante Urgencia Inmediata Estado Validado Estabilidad Alta Comentarios (ninguno) Tabla nº 73: Requisito no funcional 4. Necesidad de Gestor de BBDD. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 121 9.2. Diagramas de clases Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro. A continuación se mostrarán los diagramas de clases planteados para el desarrollo del proyecto: ProductoClienteProveedor Form_Inicio Main (Form_Inicio) 1 0..* 1 0..* 1 0..* Figura nº 53: Diagrama de clases Main. Main Producto Cliente Proveedor Contacto Pedido Consumicion 11..* FacturaAlbaran 1 1 10..* 1 0..* 1 0..* 10..* FacturaCompra Mensual 1 1..* GastoLibre Figura nº 54: Diagrama de clases Capa de Negocio. GREENGROCERS APPLICATION Daniel Alonso Arias 122 II MANUAL TÉCNICO Form_Inicio FormPedido FormAlbaranes FormAnual FormClientes FormCompras FormContacto FormGastos FormMensual FormModificarAlbaran FomrModificarFactura FormProductos FormProducto FormProveedores FormFacturas FormResumenes FormTrimestral FormServiciosFormGestionProductos FormFacturasProveedor FromMostrarMensual FormMostrarTrimestral FormMostrarAnual FormIva FormTipoIva FormBBDD FormGastoLibre FromTipoDeGasto FormLibres Figura nº 55: Diagrama de clases Capa de Interacción. Tools Figura nº 56: Diagrama de clases Capa de Herramientas. Controlador Figura nº 57: Capa de Datos. Después de ver los diagramas, se mostrarán detalladamente cada una de las clases que forman la aplicación. Se ha desarrollado una jerarquía de clases agrupando éstas por tener atributos similares. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 123 Clase Pedido: en esta clase se almacenarán todos los datos correspondientes a un pedido. Figura nº 58: Clase Pedido. GREENGROCERS APPLICATION Daniel Alonso Arias 124 II MANUAL TÉCNICO Clase ListaContactos: en esta clase se almacenarán un listado de contactos. Figura nº 59: Clase ListaContactos. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 125 Clase Contacto: en esta clase se almacenarán todos los datos correspondientes a un contacto. Figura nº 60: Clase Contacto. GREENGROCERS APPLICATION Daniel Alonso Arias 126 II MANUAL TÉCNICO Clase Consumición: en esta clase se almacenarán todos los ratos correspondientes a una consumición. Figura nº 61: Clase Consumición. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 127 Clase Controlador: clase controlará el tráfico de datos entre la BBDD y el sistema. Figura nº 62: Clase Controlador. GREENGROCERS APPLICATION Daniel Alonso Arias 128 II MANUAL TÉCNICO Clase Form_Inicio: esta clase contiene el formulario inicial del sistema. También es la encargada de lanzar procesos en segundo plano como, el backup de la BBDD y la recolección de basura. Figura nº 63: Clase Form_Inicio. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 129 Clase FormAlbaranes: esta clase contiene el formulario en el que se muestran los albaranes de un cliente seleccionado. Figura nº 64: Clase FormAlbaranes. Clase FormAnual: esta clase contiene el formulario en el que se seleccionan los datos para realizar un resumen anual. Figura nº 65: Clase FormAnual. GREENGROCERS APPLICATION Daniel Alonso Arias 130 II MANUAL TÉCNICO Clase FormAyuda: esta clase contiene el formulario, que muestra el PDF, con el manual de ayuda. Figura nº 66: Clase FormAyuda. Clase FormBBDD: esta clase contiene el formulario para restaurar un backup de BBDD. Figura nº 67: Clase FormBBDD. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 137 Clase FormGastos: esta clase contiene el formulario para seleccionar el tipo de gasto a realizar. Figura nº 74: Clase FormGastos. Clase FormGestionProductos: esta clase contiene el formulario que muestra el listado de productos. Figura nº 75: Clase FormGestionProductos. GREENGROCERS APPLICATION Daniel Alonso Arias 138 II MANUAL TÉCNICO Clase FormIva: esta clase contiene el formulario con el valor de los tipos de IVA. Figura nº 76: Clase FormIva. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 139 Clase FormLibres: esta clase contiene el formulario que muestra el listado de gastos libres. Figura nº 77: Clase FormLibres. GREENGROCERS APPLICATION Daniel Alonso Arias 140 II MANUAL TÉCNICO Clase FormMensual: esta clase contiene el formulario para realizar los resúmenes mensuales. Figura nº 78: Clase FormMensual. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 141 Clase FormModificarAlbarán: esta clase contiene el formulario que muestra los datos de un albarán que puede ser modificado. Figura nº 79: Clase FormModificarAlbarán. GREENGROCERS APPLICATION Daniel Alonso Arias 142 II MANUAL TÉCNICO Clase FormModificarFactura: esta clase contiene el formulario que muestra los datos de una factura que puede ser modificada. Figura nº 80: Clase FormModificarFactura. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 143 Clase FormMostrarAnual: esta clase contiene el formulario que muestra un resumen anual. Figura nº 81: Clase FormMostrarAnual. GREENGROCERS APPLICATION Daniel Alonso Arias 144 II MANUAL TÉCNICO Clase FormMostraMensual: esta clase contiene el formulario que muestra un resumen mensual. Figura nº 82: Clase FormMostrarMensual. GREENGROCERS APPLICATION Daniel Alonso Arias II MANUAL TÉCNICO 145 Clase FormMostrarTrimestral: esta clase contiene el formulario que muestra un resumen trimestral. Figura nº 83: Clase FormMostrarTrimestral. GREENGROCERS APPLICATION Daniel Alonso Arias 146 II MANUAL TÉCNICO Clase FormPedido: esta clase contiene el formulario para realizar pedidos. Figura nº 84: Clase FormPedido. GREENGROCERS APPLICATION Daniel Alonso Arias III MANUALES 249 Se mostrará el listado de proveedores. 14.5.1. Añadir proveedor Para añadir un nuevo proveedor seleccionaremos la opción “Nuevo proveedor”. GREENGROCERS APPLICATION Daniel Alonso Arias 250 III MANUALES Se mostrará el formulario para añadir un nuevo contacto. Se comprobará que los datos obligatorios están informados. Se comprobará que los datos son correctos. No se podrán dar de alta proveedores con el mismo NIF/CIF. GREENGROCERS APPLICATION Daniel Alonso Arias III MANUALES 251 14.5.2. Editar proveedor Para editar un proveedor, seleccionaremos el proveedor a editar, y pulsaremos el botón “Editar proveedor”. Se mostrará el formulario del contacto, con los datos del proveedor cargados. Se podrá modificar cualquier dato del proveedor, excepto el NIF/CIF. Se pedirá confirmación para antes de realizar los cambios. Se avisará de la correcta modificación de los datos. GREENGROCERS APPLICATION Daniel Alonso Arias 252 III MANUALES 14.5.3. Eliminar proveedor Para eliminar un proveedor, seleccionaremos el proveedor a eliminar, y pulsaremos el botón “Eliminar proveedor”. Se comprobará que el proveedor no tenga facturas, en cuyo caso no podrá ser eliminado. En el caso que no contenga pedidos asociados se solicitará confirmación de la eliminación del proveedor. Una vez eliminado se mostrará el aviso: GREENGROCERS APPLICATION Daniel Alonso Arias III MANUALES 253 14.5.4. Imprimir listado de proveedores Para imprimir el listado de proveedores, seleccionaremos la opción “Imprimir proveedores”. Se abrirá la ventana de opciones de impresión del pc. Seleccionar la impresora y pulsar “Imprimir”. GREENGROCERS APPLICATION Daniel Alonso Arias 254 III MANUALES 14.5.5. Ver facturas del proveedor Para consultar las facturas de un proveedor, seleccionaremos el proveedor, y pulsaremos el botón “Facturas”. Se mostrará el listado de la facturas del proveedor seleccionado. GREENGROCERS APPLICATION Daniel Alonso Arias III MANUALES 255 14.5.5.1. Editar factura Ver 2.4.5.1 Editar factura (Cliente) 14.5.5.2. Imprimir factura Ver 2.4.5.2 Imprimir factura (Cliente) 14.5.5.3. Guardar factura Ver 2.4.5.2 Guardar factura (Cliente) 14.5.5.4. Eliminar factura Para eliminar una factura, se seleccionará la factura a eliminar, y se pulsará en “Eliminar factura”. Se perdirá que se confirme la anulación. Una vez aceptado se motrará un aviso de la anulación de la factura. GREENGROCERS APPLICATION Daniel Alonso Arias 256 III MANUALES 14.5.6. Añadir compra Para informar una compra a un proveedor, seleccionaremos el proveedor, y pulsaremos el botón “Añadir Compra”. Se mostrará el formulario de con los datos del proveedor. GREENGROCERS APPLICATION Daniel Alonso Arias III MANUALES 257 Se rellenará el pedido como en la sección 2.2 Realizar un pedido, con los productos deseados, y se informarán también los campos “Tipo de operación”, “Concepto” y “Número de factura”. Se pulsará en “Guardar”. Una vez confirmado, se grabará la factura. Está se podrá consultar en las facturas del proveedor seleccionado. GREENGROCERS APPLICATION Daniel Alonso Arias 258 III MANUALES 14.6. Añadir gasto Para informar un gasto, se pulsará el botón “Añadir Compra”. Se mostrará el formulario de “Gastos”. Se podrán realizar gastos/compras a un proveedor definido (en este caso compra de frutas), o gastos libres, en los que habrá que rellenar toda la información. 14.6.1. Gasto de proveedores Para realizar un gasto sobre un proveedor, se pulsará el botón “Gastos de proveedores”. Primero se seleccionará el proveedor sobre el que se va a realizar el pedido. Se mostrará el formulario para realizar el pedido, con los datos del proveedor cargados. Para realizar la compra se seguirán los pasos del apartado 2.5.6 Añadir compra. GREENGROCERS APPLICATION Daniel Alonso Arias III MANUALES 265 Se mostrarán los datos del resumen: Se podrá imprimir este resumen para su posterior uso fiscal. 14.8.3. Resumen anual Para realizar un resumen mensual, se pulsará en el botón “Resumen mensual”. Se mostrará el formulario para seleccionar el año y el Modo. GREENGROCERS APPLICATION Daniel Alonso Arias 266 III MANUALES Si el modo seleccionado es de tipo individual (De un cliente, De un proveedor), se deberá seleccionar también un cliente o un proveedor según proceda. Después se pulsará en “Mostrar Resumen”. Se mostrarán los datos del resumen: Se podrá imprimir este resumen para su posterior uso fiscal. GREENGROCERS APPLICATION Daniel Alonso Arias III MANUALES 267 14.9. Recuperar datos Para cargar los datos de una copia de seguridad, se pulsará en el botón “Recuperar datos”. Se mostrará la pantalla de restaurar datos, con el listado de copias de seguridad realizadas. Se seleccionará una de ellas, y se pulsará en “Restaurar”. GREENGROCERS APPLICATION Daniel Alonso Arias 268 III MANUALES Se solicitará confirmación de la operación.