e-stocks: Gestor de stocks Memoria - L'Oberta en...

e-stocks: Gestor de stocks UOC – Ingeniería Técnica de Informática de Gestión

Memoria 17/06/2013

Trabajo de Fin de Carrera – TFC J2EE Página 1 de 37 David Rodríguez Villar

1. Portada

e-stocks: Gestor de stocks

Memoria

Trabajo de Fin de Carrera

Ingeniería Técnica de Informática de Gestión

Autor: David Rodríguez Villar

Consultor: Salvador Campo Mazarico

11 de marzo de 2013

Este trabajo se distribuye bajo licencia CC BY-SA 3.0. La licencia completa se puede consultar en:

http://creativecommons.org/licenses/by-sa/3.0/deed.es

http://creativecommons.org/licenses/by-sa/3.0/deed.es


Memoria 17/06/2013


2. Dedicatoria y agradecimientos

A mis dos hijos y mi mujer,

por darme el tiempo para poder realizar este proyecto.


Memoria 17/06/2013


3. Resumen Para la realización de este trabajo de fin de carrera, se ha escogido la tecnología J2EE (ahora nombrada JEE). Esta tecnología se ha convertido en el referente empresarial para el desarrollo de aplicaciones distribuidas.

El trabajo de fin de carrera se ha realizado como un proyecto de desarrollo de software, siguiendo un ciclo de vida en cascada. El proyecto al final tiene dos objetivos. El primero, el inicial y funcional, consistente en el desarrollo de un sistema de información que satisfaga las necesidades de una empresa en cuanto a la gestión de sus stocks. El segundo, el desarrollo de un arquitectura general para aplicaciones empresariales basada las mejores prácticas de desarrollo en JEE y que permitiese un aumento en la productividad de desarrollo de dichas aplicaciones a la vez que una uniformidad en su estilo y estructura con el fin de utilizarla en nuevos proyectos de desarrollo posteriores.

En el ámbito funcional se ha completado el análisis y diseño de la aplicación pero debido a su gran alcance, en la construcción se ha reducido los módulos del diseño implementados.

En el ámbito tecnológico se ha desarrollado al completo una arquitectura general para aplicaciones empresariales, produciendo una gran satisfacción por el logro obtenido y las características que reúne.

La arquitectura está construida sobre JSF para el interfaz de usuario, Hibernate para la gestión de la persistencia y Spring Framework como pegamento para unirlo todo. Esta arquitectura proporciona un conjunto de servicios a las aplicaciones desarrolladas sobre ella como son la gestión de seguridad y permisos de grupos de usuarios, internacionalización y gestión centralizada de mensajes y literales de la aplicación, un Framework para el interfaz de usuario que simplifica su construcción y da soporte para las validaciones de campos y el control de la seguridad y el aspecto de cliente pesado dentro de un cliente ligero así como clases de ayuda para trabajar con la persistencia, las transacciones y los criterios de las búsquedas de información.

En los siguientes puntos de este documento, se tratarán con detalle todos los aspectos de las etapas por las que ha pasado el proyecto, para finalmente poder llevar a cabo una conclusión y un análisis de los resultados obtenidos.


Memoria 17/06/2013


4. Índice 1. Portada .................................................................................................................... 1

2. Dedicatoria y agradecimientos................................................................................. 2

3. Resumen ................................................................................................................. 3

4. Índice ....................................................................................................................... 4

5. Memoria .................................................................................................................. 6

5.1. Introducción ....................................................................................................... 6

5.1.1. Justificación ................................................................................................. 6

5.1.1.1. Justificación del TFC .............................................................................. 6

5.1.1.2. Contexto en el que se desarrolla............................................................ 6

5.1.1.3. Aportación del TFC ................................................................................ 7

5.1.2. Objetivos del TFC ........................................................................................ 7

5.1.2.1. Objetivos de la asignatura...................................................................... 7

5.1.2.2. Alcance del proyecto .............................................................................. 7

5.1.3. Enfoque y método seguido .......................................................................... 9

5.1.4. Planificación del proyecto ............................................................................ 9

5.1.4.1. Descomposición en fases, actividades e hitos ..................................... 10

5.1.4.2. Descripción de fases ............................................................................ 11

5.1.4.3. Hitos .................................................................................................... 12

5.1.4.4. Cronograma ......................................................................................... 13

5.1.5. Productos obtenidos .................................................................................. 13

5.2. Visión general .................................................................................................. 14

5.2.1. Modelo conceptual de uso ......................................................................... 14

5.2.2. Modelo conceptual de dominio .................................................................. 16


Memoria 17/06/2013


5.3. Arquitectura ..................................................................................................... 17

5.4. Análisis del sistema ......................................................................................... 20

5.5. Diseño del sistema .......................................................................................... 20

5.5.1. Diseño de la persistencia ........................................................................... 21

5.5.2. Diagrama de la base de datos ................................................................... 23

5.6. Construcción del sistema ................................................................................. 29

5.7. Implantación y aceptación del sistema ............................................................ 31

5.8. Conclusiones ................................................................................................... 33

6. Glosario ................................................................................................................. 34

7. Bibliografía ............................................................................................................ 35

8. Anexos .................................................................................................................. 37


Memoria 17/06/2013


5. Memoria

5.1. Introducción

5.1.1. Justificación

5.1.1.1. Justificación del TFC

El trabajo de fin de carrera (TFC) es una asignatura que está pensada para realizar un trabajo de síntesis de los conocimientos adquiridos en otras asignaturas de la carrera y que requiera ponerlos en práctica conjuntamente en un trabajo concreto. Normalmente el TFC es un trabajo eminentemente práctico y vinculado al ejercicio de la informática.

Hace ya unos años que la industria del software está adoptando cada vez más la orientación a objetos. Por otra parte, las aplicaciones de empresa, siguiendo las tendencias actuales, están adoptando cada vez más una estructura distribuida. Esto, añadido a la imposición amplia de Internet a nivel empresarial hace que cada vez más las aplicaciones de empresa usen la red como vehículo de comunicación básico.

Además, la posibilidad de usar la Web como interfaz está haciendo que muchas aplicaciones antiguas se estén trasladando hacia este entorno. El mundo del desarrollo del software reacciona cada vez con más rapidez a las necesidades empresariales, y en la actualidad ya han aparecido varias tecnologías para facilitar y estandarizar el desarrollo de aplicaciones en este entorno.

Concretamente, la tecnología Java se ha constituido desde ya hace unos años en un puntal fuerte en este aspecto. El Java como lenguaje de desarrollo, junto con la arquitectura JEE se han convertido en un estándar en el mundo de la industria para el desarrollo distribuido de aplicaciones empresariales a Internet.

Esta área de trabajo fin de carrera constituye una propuesta para que el estudiante se introduzca o profundice en este apasionante mundo del desarrollo para Internet usando tecnología Java. Esto permitirá al estudiante realizar un trabajo práctico con tecnologías concretas que son usadas ampliamente en la empresa.

5.1.1.2. Contexto en el que se desarrolla

El estudiante siempre ha tenido en la cabeza desarrollar una idea de negocio relacionada con la un software de gestión para tiendas, comenzando por la gestión de stocks.

Aprovechando que el estudiante tiene que realizar el trabajo de fin de carrera y ha sido aceptado dentro del área JEE, área que como hemos mencionado en el anterior apartado, tiene como parte de sus objetivos el desarrollo de una aplicación empresarial, se pueden atender dicha necesidad con la solución que se desarrolle en el trabajo de fin de carrera JEE.


Memoria 17/06/2013


5.1.1.3. Aportación del TFC

La realización del TFC contribuirá con las siguientes aportaciones:

1. El estudiante podrá profundizar en los conocimientos de arquitectura JEE

2. Puede ser el comienzo para un futuro proyecto de emprendimiento de software para tiendas

5.1.2. Objetivos del TFC

5.1.2.1. Objetivos de la asignatura

Los objetivos de la asignatura son:

El estudiante realice un trabajo de síntesis de los conocimientos adquiridos en otras asignaturas de la carrera y que requiera ponerlos en práctica conjuntamente en un trabajo concreto.

El estudiante realice un trabajo eminentemente práctico y vinculado al ejercicio de la informática.

El estudiante profundice en el conocimiento práctico de la plataforma JEE

5.1.2.2. Alcance del proyecto

El alcance del proyecto es el desarrollo de un sistema de información (una aplicación java empresarial) que satisfaga las necesidades de una empresa de venta de mercaderías (en la aplicación de ejemplo será de ropa deportiva) respecto a la gestión de las operaciones necesarias entre la sede central y las tiendas distribuidas por la geografía del país para la gestión de los stocks.

Para delimitar el alcance (que será completamente especificado en la definición de los requisitos del sistema en la fase de análisis), en este apartado vamos especificar el contexto y los requisitos a grandes rasgos que deberá cumplir el sistema desde el punto de vista de la especificación inicial dada por el cliente:

Nuestra empresa, es una empresa de importación y venta de material deportivo de ámbito nacional, y quiere informatizar su software de gestión de stocks.

El aplicativo a desarrollar deberá gestionar el material en stock del almacén central que sirve a las tiendas de la cadena en todo el territorio. La idea principal es que las diferentes tiendas puedan cursar peticiones a la oficina central para prever las posibles rupturas de sus stocks y en caso de que éstas se produzcan, redirigir sus clientes a otras tiendas de la zona donde aún quede stock. Por lo tanto, será necesario mantener, en todo momento, una trazabilidad total de los productos (qué se


Memoria 17/06/2013


encuentran en la tienda X, cuáles se encuentran in itínere del almacén central hacia la tienda y cuáles han sido rechazados por la tienda Z por defectos de fabricación, etc.) para hacer más eficiente la gestión y distribución de los stocks.

La empresa actualmente realiza esta gestión de forma totalmente descoordinada a través de llamadas telefónicas entre las diferentes tiendas y la oficina central y por ello pide al estudiante que desarrolle una aplicación de tipo cliente /servidor formada, en una primera fase del contrato que ha formalizado, por cuatro subsistemas:

• Subsistema de mantenimiento: Este subsistema se encargará de la gestión de los usuarios del sistema así como del mantenimiento de las diferentes entidades presentes: productos, proveedores, tiendas, almacén central, albaranes, etc. Respecto de los roles existentes para los usuarios de la aplicación hay que contemplar, como mínimo: el de administrador de todo el sistema, el de operador de las oficinas centrales y el de operador de una tienda.

• Subsistema de control de flujo: Este subsistema permitirá gestionar el flujo del material para las diferentes tiendas a la vez que mantendrá un control exhaustivo de todos los movimientos (entradas-con los correspondientes albaranes-, salidas, devoluciones, productos in itínere, etc.) así como de la rotación de los diferentes stocks. El sistema disfrutará de diferentes maneras de hacer la distribución del material hacia las tiendas (en función de la demanda actual, peticiones cursadas, de la demanda histórica, de la rotación del stock, de la proximidad entre la tienda de recepción y almacén central etc.) y será el operador de las oficinas centrales que decidirá, en cada caso y, una vez visualizadas estos datos, la distribución final (cantidad y destino) del material.

• Subsistema de listados y estadísticas: Mediante este subsistema se quiere averiguar estadísticamente la eficacia del servicio. Habrá, pues, detalló la información de las rupturas de stock ocurridas, la rotación de los stocks en las diferentes tiendas así como en el almacén central, el porcentaje y ranking los productos más / menos rechazados / pedidos, etc.

• Subsistema de conexión: Es el subsistema que ejecuta cualquier usuario para acceder a la aplicación. Los usuarios se identificarán, y en función de su perfil el sistema les mostrará las opciones adecuadas. En concreto.

El rol de operador de una tienda permitirá:

1. Consultar si se dispone de un cierto material en la propia tienda así como su trazabilidad desde su origen (proveedor, días en el almacén central, días in itínere, fecha de llegada a la tienda, links a los correspondientes albaranes, etc.)


Memoria 17/06/2013


2. Pedir un cierto material a las oficinas centrales

3. Hacer la recepción de material y expedir el albarán correspondiente

4. Consultar las estadísticas relativas a su tienda y

5. Rechazar el material recibido.

Por su parte, el operador de las oficinas centrales podrá

1. Consultar la cantidad, localización y trazabilidad de cualquier producto en toda la red de tiendas

2. Hacer la recepción del material y expedir el albarán correspondiente

3. Consultar todo tipo de estadísticas

4. Rechazar el material recibido en el almacén central.

Por último, el rol de administrador deberá poder realizar operaciones CRUD con cualquier entidad del sistema.

5.1.3. Enfoque y método seguido

Dado que es un proyecto de desarrollo para la universidad y hay marcadas unas pautas de entregas similares a las fases del ciclo de vida en cascada, se ha estimado conveniente utilizar el ciclo de vida clásico (o en cascada) con objeto de desarrollar el nuevo sistema. En la actividad de especificación de requisitos de la fase de análisis, se tendrá un conocimiento exacto de lo que se desea desarrollar para el sistema y para conseguir una estimación ajustada al volumen de trabajo que permite el TFC, se decidirán qué requisitos se cumplirán dentro del proyecto desarrollado en el TFC.

Considero que la utilización de este ciclo de vida, con mi experiencia de análisis y estimación permitirá la selección del alcance correcto para poder cumplir con las exigencias de la asignatura.

5.1.4. Planificación del proyecto

Ya que el proyecto sigue el ciclo de vida en cascada, las actividades se agruparán en fases que utilizarán como entrada los productos generados en la fase anterior y proporcionarán como salida nuevos productos que serán utilizados por la fase posterior.

Se ha tenido en cuenta el enfoque de la asignatura de evaluación continua para fijar como hitos externos las entregas para dichas evaluación continua (PEC).

Dado que tengo otras obligaciones (trabajo, familia y otras asignaturas) se ha considerado para la estimación una dedicación de 15 horas semanales y distribuidas


Memoria 17/06/2013


en días laborables de lunes a viernes (cada día que aparece equivale a 3 horas de trabajo)

Se ha utilizado Microsoft Project para realizar la planificación y con esta misma herramienta se realizará el control y seguimiento de la planificación.

5.1.4.1. Descomposición en fases, actividades e hitos

Id Tarea Dur, Inicio Fin Dep. 1 Fase de arranque de proyecto 7 days Thu 28/02/13 Mon 11/03/13 2 Establecimiento del Alcance del Proyecto 3 days Thu 28/02/13 Tue 05/03/13 3 Definicion del plan de proyecto 3 days Tue 05/03/13 Fri 08/03/13 2 4 Revision y aprobación de productos 1 day Fri 08/03/13 Mon 11/03/13 3 5 PEC1: Entrega 0 days Mon 11/03/13 Mon 11/03/13 1 6 Fase de análisis de sistemas 15 days Mon 11/03/13 Mon 01/04/13 1 7 Especificación de Requisitos 3 days Mon 11/03/13 Thu 14/03/13 8 Análisis del sistema 7 days Thu 14/03/13 Mon 25/03/13 7 9 Modelo de Negocio 1 day Thu 14/03/13 Fri 15/03/13

10 Casos de uso 3 days Fri 15/03/13 Wed 20/03/13 9 11 Diagrama de clases 3 days Wed 20/03/13 Mon 25/03/13 10 12 Definición de Interfaces de Usuario 3 days Mon 25/03/13 Thu 28/03/13 11 13 Especificación de plan inicial de pruebas 1 day Thu 28/03/13 Fri 29/03/13 12 14 Revision y aprobación de productos 1 day Fri 29/03/13 Mon 01/04/13 13 15 Fase de diseño de sistema 10 days Mon 01/04/13 Mon 15/04/13 6 16 Diseño 7 days Mon 01/04/13 Wed 10/04/13 17 Diseño de la Arquitectura Lógica del Sistema 7 days Mon 01/04/13 Wed 10/04/13 18 Diseño de la Arquitectura Física del Sistema 7 days Mon 01/04/13 Wed 10/04/13 19 Diseño Físico de Datos 7 days Mon 01/04/13 Wed 10/04/13 20 Diseño de la Interfaz de Usuario 7 days Mon 01/04/13 Wed 10/04/13 21 Diseño de la Lógica Interna de los Componentes 7 days Mon 01/04/13 Wed 10/04/13 22 Especificación Técnica del Plan de Pruebas 2 days Wed 10/04/13 Fri 12/04/13 16 23 Revision y aprobación de productos 1 day Fri 12/04/13 Mon 15/04/13 22 24 PEC2: Entrega 0 days Mon 15/04/13 Mon 15/04/13 15 25 Fase de construcción de sistemas 35 days Mon 15/04/13 Mon 03/06/13 15 26 Preparación del entorno de construcción y

preproducción 3 days Mon 15/04/13 Thu 18/04/13 27 Generación del código de componentes y

procedimientos 25 days Thu 18/04/13 Thu 23/05/13 26 28 Revisión y realización de pruebas 4 days Thu 23/05/13 Wed 29/05/13 27 29 Generación de documentación de usuario y

explotación 2 days Wed 29/05/13 Fri 31/05/13 28 30 Revision y aprobación de productos 1 day Fri 31/05/13 Mon 03/06/13 29 31 PEC3: Entrega 0 days Mon 03/06/13 Mon 03/06/13 25

32 Fase de implantación y aceptación de sistema 2,9 days Mon 03/06/13 Thu 06/06/13 25

33 Preparación de plan de implantación

0,5 days Mon 03/06/13 Mon 03/06/13

34 Instalación en Preproducción 0,2 days Mon 03/06/13 Mon 03/06/13 33

35 Pruebas en Preproducción 1 day Mon 03/06/13 Tue 04/06/13 34

36 Instalación en producción 0,2 days Tue 04/06/13 Wed 05/06/13 35


Memoria 17/06/2013


37 Revision y aprobación de productos 1 day Wed 05/06/13 Thu 06/06/13 36 38 Fase de cierre de proyecto 7 days Thu 06/06/13 Mon 17/06/13 32 39 Finalización de memoria 4 days Thu 06/06/13 Wed 12/06/13 40 Elaboración de presentación 2 days Wed 12/06/13 Fri 14/06/13 39 41 Revision y aprobación de productos 1 day Fri 14/06/13 Mon 17/06/13 40 42 Entrega Final: Memoria, presentación y software 0 days Mon 17/06/13 Mon 17/06/13 38

5.1.4.2. Descripción de fases

Fase de Arranque de Proyecto

Esta fase persigue delimitar y definir el proyecto en cuanto a ámbito, alcance, objetivos, infraestructura básica, organización y planificación temporal.

Como resultado de esta fase se tendrá el Plan de proyecto (Plan de trabajo) dentro de la memoria.

Fase de análisis de sistemas de información

Esta fase persigue la obtención de una especificación detallada del sistema de información que satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño del sistema.

Como resultado de esta fase se tendrá el capítulo de análisis del sistema que incluirá análisis de requisitos del sistema y el análisis propio del sistema, todo ello dentro de la memoria.

Fase de diseño de sistema de información

Esta fase persigue la definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información.

Como resultado de esta fase se tendrá el capítulo de diseño del sistema dentro de la memoria.

Fase de construcción de sistemas de información

Esta fase persigue construir (codificar) el sistema de información conforme al diseño, ejecutar las pruebas para verificar que cumple con las especificaciones, y además preparar la documentación y formación para el usuario final.

Como resultado de esta fase se tendrá el capítulo de construcción del sistema dentro de la memoria y los anexos que se necesiten.

Fase de implantación de sistemas de información


Memoria 17/06/2013


Esta fase persigue realizar el paso al entorno de preproducción del nuevo software (en este caso se toma el entorno de preproducción y no el de producción para poder cumplir con los requisitos de la asignatura y teniendo las garantías de la calidad del producto software realizado de tal forma que la instalación en producción del cliente sea un mero trámite).

Como resultado de esta fase se tendrá el capítulo de implantación del sistema dentro de la memoria y los anexos que se necesiten.

Fase de cierre de proyecto

Esta fase persigue realizar el cierre del proyecto. En ella se obtendrán las conclusiones de la realización del proyecto, la terminación de la memoria del proyecto y el empaquetado y entrega de todos los productos del proyecto (incluyendo el sistema desarrollado).

Como resultado de esta fase se completará y revisará la memoria desarrollándose en concreto el capítulo de conclusiones. También se elaborará la presentación sobre el proyecto.

5.1.4.3. Hitos

Hito Fecha

PEC1: Entrega 11/03/2013



Entrega Final: Memoria, presentación y software 17/06/2013


Memoria 17/06/2013


5.1.4.4. Cronograma

5.1.5. Productos obtenidos

Los productos obtenidos de este Trabajo Final de Carrera son los siguientes:

El plan de proyecto, que recoge que recoge la planificación y estimación de las tareas necesarias para llevar a cabo los objetivos previstos

El producto en sí, que es el software desarrollado (aplicación JEE) y su documentación técnica asociada.

La presentación, que resume de forma clara y concisa el trabajo realizado y los resultados obtenidos.

La presente memoria, que es el documento que sintetiza el todo el trabajo realizado a lo largo del proyecto incluyendo los productos de documentación resultado de las fases seguidas a lo largo del proyecto. (Plan de proyecto, análisis del sistema, diseño del sistema, construcción del sistema, implantación del sistema).


Memoria 17/06/2013


5.2. Visión general

En este apartado se describe el alcance del sistema desde una perspectiva de alto nivel, la cual permite llegar a un entendimiento común sobre el sistema que se va a desarrollar.

Para llegar a ese punto de comprensión general del sistema, se desarrollan 2 perspectivas:

• El modelo conceptual de uso, que aporta una visión de las funcionalidades que proporciona el sistema.

• El modelo conceptual de dominio, que aporta una visión de la información que maneja el sistema.

5.2.1. Modelo conceptual de uso

El modelo de uso permite explorar cómo los usuarios trabajan con el sistema, lo cual es esencial para entender lo que necesitan. El modelo recoge una colección de las características que el sistema les proporciona a los usuarios y se representa mediante un diagrama de casos de uso.


Memoria 17/06/2013



Memoria 17/06/2013


5.2.2. Modelo conceptual de dominio

Un modelo conceptual de dominio identifica los tipos de entidades fundamentales de negocio y las relaciones entre ellas. El modelo se formula, en esta perspectiva de alto nivel, como una colección de clases con sus atributos y relaciones relevantes.

El modelo conceptual de dominio expresa la información suficiente para comprender "el paisaje" de las entidades de negocio que maneja el sistema. Este modelo se

refinará a lo largo del diseño hasta llegar al modelo físico del sistema.


Memoria 17/06/2013


5.3. Arquitectura

La arquitectura permite reflejar, desde una perspectiva de alto nivel, tanto los aspectos tecnológicos requeridos por el cliente, como el uso de las mejores prácticas de diseño, los cuales servirán como directrices para el diseño en las siguientes fases.

MVC pattern

Cliente (Navegador

Web)

Servidor (servidor de aplicaciones: tomcat con spring

framework) Base datos

Client Tier Enterprise Tier Data Tier

UserInterface

Tier

Interactiontier Business Tier Integration

Tier BD

View Controller Model

Data Access Objects (JPA)@repository

Business Objects@service

@Transactional

JSF Page

JSF Backing Bean

XXX RepositoryClassess

XXX ServiceClassess

XXX xhtml

XXXBean

Classes

BD tables

Table XXX

Clases de arquitectura:LocaleBean,

ViewExpiredExceptionExceptionHandler, XXXConverter

Clases de arquitectura :AbstractRepositoryImpl, ByExampleSpecifications, ByPatternSpecifications , ByRangeSpecifications,

JpaUtil, SearchForm, SearchParameters

Conforme a los aspectos no funcionales y arquitectónicos requeridos por el cliente, la arquitectura de base es cliente/servidor. La solución que se va a desarrollar será una arquitectura de tres capas (en el primer nivel de abstracción): la capa de cliente (que encapsula la presentación), la capa empresarial (que encapsula la lógica de negocio) y la capa de datos (que gestiona la persistencia de la información de negocio):

• Client tier (presentación): La lógica de presentación se ocupa de cómo manejar la interacción entre el usuario y el software. Las principales responsabilidades de la presentación son mostrar la información al usuario y traducir las instrucciones del usuario a las acciones en de la capa de negocio (Enterprise tier).


Memoria 17/06/2013


• Enterprise tier (lógica de negocio o lógica de dominio): Esta capa realiza el trabajo que el sistema tiene que hacer para el dominio que está trabajando. Esta capa se encarga de proporcionar los servicios que realizan los cálculos basados en las operaciones que proporciona esta capa (junto con las entradas proporcionadas por la capa de presentación) y la información persistida por el sistema.

• Data tier (persistencia): Es responsable de mantener persistente la información de negocio del sistema. En este caso se corresponde con la base de datos que es el principal responsable para el almacenamiento de datos persistentes.

A su vez las capas de presentación y lógica de negocio se podrán dividir en dos capas cada una:

• Client tier (presentación):

o User interface tier: En esta capa se conformarán los objetos que forman el interfaz de usuario y las vistas con las que interactúa el usuario.

o Interaction tier: En capa se comunicará con la del interfaz de usuario recibiendo los

mensajes mediante eventos y tomará las decisiones sobre qué servicios de negocio utilizar contra la capa de negocio. Además decidirá los flujos de interacción con el usuario en base a los resultados de las operaciones contra el negocio, seleccionando y enviando mensajes a la capa de interfaz de usuario para mostrar las vistas necesarias y las siguientes posibilidades de interacción con el usuario. Una de sus funciones será la de proporcionar el nivel de seguridad del interfaz de usuario, garantizando que en la capa de interfaz de usuario sólo estarán disponibles para el usuario

• Enterprise tier (lógica de negocio o lógica de dominio):

o Business tier: Esta capa proporcionará a la capa de cliente los servicios disponibles del sistema. En esta capa figurarán todas las operaciones que se pueden realizar contra el modelo de dominio del sistema. Entre sus funciones se encontraran: Mantener la sesión con los niveles de seguridad de usuario conectado al sistema (manteniendo el estado de la conversación –sesión–), garantizar la transaccionalidad de las operaciones concurrentes contra el sistema e interaccionar mediante mensajes (invocaciones a métodos java de la capa de acceso a datos) que permiten variar el modelo de dominio persistente del sistema conforme a las operaciones que se realizan contra el sistema.


Memoria 17/06/2013


o Integration tier: Esta capa es la encargada de proporcionar el enlace entre la persistencia del modelo de dominio del sistema y las operaciones que la consultan o modifican. Se implementará usando el patrón de Data Access Objects (DAO) sobre JPA dado que existe tan sólo persistencia en la base de datos. Este patrón dotará de un interfaz de acceso a los datos persistentes uniforme que aísla el código de acceso a datos (JDBC) de los objetos de negocio, proporcionando un acceso trasparente a los datos y un mapeo de la base datos relacional a los objetos java de negocio, lo cual, además de las ventajas señaladas, proporciona la reducción de la complejidad de la migración del sistema si se decidiese cambiar en adelante el modelo de persistencia (por ejemplo a otra base de datos). Si existieran más fuentes de información persistente del modelo de dominio u otros sistemas con los que integrarse sería responsabilidad de dotar los interfaces hacia ellos en esta capa (integration tier)

La arquitectura desde el punto de vista de los patrones de diseño actuará conforme al patrón de modelo vista controlador (MVC, Model View Contoller), donde las clases de las páginas JSF actuarán como la vista y los JSF beans que gestionan los eventos disparados desde las pantallas actuarán como controladores hacia la información de negocio (Modelo, conformando por el resto de las capas a partir de los objetos de negocio hasta la base de datos).

Para expresar el diseño basado en esta arquitectura, en el apartado de diseño de los subsistemas se mapearán estas capas y objetos de la siguiente forma:

• Client tier (presentación):

o User interface tier: Con las clases empiezan por PantallaXXX en diseño y que en la codificación se corresponderán con XXX.xhtml para la vista e interacción con el usuario mediante el interfaz gráfica de usuario.

o Interaction tier: No se pondrá explícitamente. Se entenderá que existen objetos (XXX

Bean) que contienen el flujo de los diagramas de interacción y que son invocados desde de las clases Pantalla y que van enviando los mensajes necesarios a los objetos de negocio (Gestores) y van cambiando enviándoles mensajes a las clases Pantalla de la anterior capa para actualizar la vista y el control de flujo del interfaz de usuario.

• Enterprise tier (lógica de negocio o lógica de dominio):

o Business tier: Esta capa se representará con los objetos Gestor. En implementación, cada uno de estos objetos será un objeto @Service, @Transactional dentro de spring framework.

o Integration tier: Esta capa estará representada en diseño como la clase GestorDisco,

aunque en la implementación quien lo desee podrá sustituir el GestorDisco por el conjunto de clases DAO, una por cada entidad de la base de datos que implementará


Memoria 17/06/2013


la ocultación del SQL, el JDBC y el mapeo a objetos de negocio con los registros de la tabla de la base de datos. A nivel de diseño solo se pondrá un mensaje equivalente java (método) que realizará las operaciones que oculta esta capa sin entrar en el detalle de las sentencias SQL por JDBC. De hecho en la implementación del código se usará el API para JPA proporcionado por Spring framework, y para ello, por cada entidad XXX existirá una clase XXXRepository que extienda a org.springframework.data.jpa.repository.JpaRepository<T, X>

5.4. Análisis del sistema

El análisis del sistema se ha realizado para cada subsistema con:

• una descripción de las funcionalidades

• sus diagramas de casos de uso

• sus especificaciones de caso de uso

• un prototipo de diseño gráfico de las pantallas

Dado la extensión del documento de análisis (87 páginas) se adjunta a la memoria como un apéndice.

5.5. Diseño del sistema

El diseño del sistema se ha realizado para cada subsistema con:

• una descripción

• repaso de las funcionalidades

• diagramas de clases y jerarquías

• diagramas de colaboración

• diseño de la interfaz gráfica

Dado la extensión del documento de diseño (97 páginas) se adjunta a la memoria como un apéndice. No obstante, por su relevancia, se copia aquí el diseño de la persistencia:


Memoria 17/06/2013


5.5.1. Diseño de la persistencia

El diagrama de entidades del modelo de negocio que anteriormente se ha presentado es el siguiente:

A este modelo se va añadir todos los atributos que han surgido a lo largo del diseño de los subsistemas.

El modelo presentado es un modelo orientado a objetos y existen ciertas características que no existen en las bases de datos relacionales. Como la persistencia se va a realizar en una base de datos relacional se van a realizar un conjunto de transformaciones para trasladar estos conceptos:

• Se trasladará la herencia integrando las clases Compra, Venta, Traspaso, Devolución y Albarán en una única tabla Albarán

• Se trasladará la herencia de Centro, Tienda y Central y la relación 1 a 1 de Centro y Almacén a una única tabla Tienda que tendrá una relación con una tabla TipoTienda que contendrá los valores Tienda y Central

• Para mantener la identidad de los objetos se utilizarán subrogates enteros en cada tabla que se irán generando usando las secuencias de la base de datos y se utilizarán para trasladar las relaciones de asociación como claves foráneas que refieren a estos subrogates.

• Todos los atributos tipo XXX o situación YYYY o estado YYYY se transforma en claves foráneas a tablas maestras TipoXXX o SituacionYYYY. Mediante


Memoria 17/06/2013


este mecanismo se posibilitará la garantía de la consistencia de dichos atributos y la posibilidad más delante de ampliarlos sin tocar la estructura de la base de datos. Además facilitarán la internacionalización ya que además del subrógate para cada tipo o situación se añadirá una columna descripción que se corresponderá con la clave que el sistema deba buscar en los archivos de internacionalización.


Memoria 17/06/2013


5.5.2. Diagrama de la base de datos

<<not null>> <<PK>>-id_proveedor : serial"(10)" = nextval('prov...<<not null>>-codigo : bpchar"(10)"<<not null>>-cif : bpchar"(10)"<<not null>>-nombre : varchar"(50)"<<null>>-direccion : varchar"(50)"<<null>>-codigo_postal : bpchar"(5)"<<null>>-poblacion : varchar"(50)"<<null>>-provincia : varchar"(50)"<<null>>-telefono : bpchar"(15)"<<null>>-fax : bpchar"(15)"<<not null>>-fecha_alta : date"(13)" = ('now'::text)::date<<not null>>-fecha_modificacion : date"(13)" = ('now'::text)::date<<null>>-fecha_baja : date"(13)"

<<table>>Proveedor

<<not null>> <<PK>>-id_usuario : serial"(10)" = ne...<<not null>>-codigo : bpchar"(10)"<<not null>>-nif : bpchar"(10)"<<not null>>-password : bpchar"(10)"<<not null>>-nombre : varchar"(50)"<<not null>>-apellidos : varchar"(50)"<<not null>>-id_tienda : int4"(10)"<<null>>-direccion : varchar"(50)"<<null>>-codigo_postal : bpchar"(5)"<<null>>-poblacion : varchar"(50)"<<null>>-provincia : varchar"(50)"<<null>>-telefono : bpchar"(15)"<<null>>-movil : bpchar"(15)"<<null>>-sexo : bpchar"(1)"<<null>>-fecha_nacimiento : date"(13)"<<not null>>-fecha_alta : date"(13)" = ('now'::text):...<<not null>>-fecha_modificacion : date"(13)" = ('no...<<null>>-fecha_baja : date"(13)"<<not null>>-id_tipo_usuario : int4"(10)"

<<index>> <<unique>>+Usuario_codigo_key( codi...<<index>> <<unique>>+Usuario_nif_key( nif )

<<table>>Usuario

<<not null>> <<PK>>-id_situacion_albaran : int4"(1...<<not null>>-descripcion : varchar"(20)"

<<table>>SituacionAlbaran

<<not null>> <<PK>>-id_tipo_albaran : int4"(10)"{p...<<not null>>-descripcion : varchar"(20)"

<<table>>TipoAlbaran

<<not null>>-id_tienda : int4"(10)"<<not null>>-id_producto : int4"(10)"<<null>>-stock : int4"(10)"

<<PK>>+pk_stock(){columns = id_tienda, id_produ...

<<table>>Stock

<<not null>>-id_albaran : int4"(10)"<<not null>>-id_linea : serial"(10)" = nextval('albar...<<not null>>-id_producto : int4"(10)"<<not null>>-cantidad : int4"(10)"

<<PK>>+pk_lineaalbaran(){columns = id_albaran, i...

<<table>>LineaAlbaran

<<not null>> <<PK>>-id_tipo_usuario : int4"(10)"{p...<<not null>>-descripcion : varchar"(20)"

<<table>>TipoUsuario

<<not null>>-id_solicitud : int4"(10)"<<not null>>-id_linea : serial"(10)" = nextval('solicit...<<not null>>-id_producto : int4"(10)"<<not null>>-cantidad : int4"(10)"

<<PK>>+pk_lineasolicitud(){columns = id_solicitud,...

<<table>>LineaSolicitud

<<not null>> <<PK>>-id_tienda : serial"(10)" = next...<<not null>>-codigo : bpchar"(10)"<<not null>>-nombre : varchar"(50)"<<null>>-direccion : varchar"(50)"<<null>>-codigo_postal : bpchar"(5)"<<null>>-poblacion : varchar"(50)"<<null>>-provincia : varchar"(50)"<<null>>-telefono : bpchar"(15)"<<null>>-fax : bpchar"(15)"<<not null>>-id_tipo_tienda : int4"(10)"<<not null>>-fecha_alta : date"(13)" = ('now'::text)...<<not null>>-fecha_modificacion : date"(13)" = ('n...<<null>>-fecha_baja : date"(13)"

<<table>>Tienda

<<not null>> <<PK>>-id_tipo_movimiento : int4"(10...<<not null>>-descripcion : varchar"(20)"

<<table>>TipoMovimiento

<<not null>>-id_tienda : int4"(10)"<<not null>>-id_tienda2 : int4"(10)"<<not null>>-distancia : float8"(17, 17)"

<<PK>>+pk_distancia(){columns = id_tienda, id_tie...

<<table>>Distancia

<<not null>> <<PK>>-id_tipo_tienda : int4"(10)"{pk ...<<not null>>-descripcion : varchar"(20)"

<<table>>TipoTienda

<<not null>> <<PK>>-id_situacion_solicitud : int4"(...<<not null>>-descripcion : varchar"(20)"

<<table>>SituacionSolicitud

<<not null>> <<PK>>-id_movimiento : serial"(10)" =...<<not null>>-id_tienda : int4"(10)"<<not null>>-id_producto : int4"(10)"<<not null>>-fecha : date"(13)" = ('now'::text)::date<<not null>>-id_albaran : int4"(10)"<<not null>>-id_tipo_movimiento : int4"(10)"<<not null>>-stock_anterior : int4"(10)"<<not null>>-stock : int4"(10)"<<not null>>-id_linea : int4"(10)"

<<index>>+fki_movimiento_lineaalbaran( id_albara...

<<table>>Movimiento

<<not null>> <<PK>>-id_albaran : serial"(10)" = ne...<<not null>>-id_tipo_albaran : int4"(10)"<<not null>>-fecha : date"(13)" = ('now'::text)::date<<not null>>-fecha_recepcion : date"(13)" = ('no...<<not null>>-id_origen : int4"(10)"<<null>>-id_destino : int4"(10)"<<null>>-id_proveedor : int4"(10)"<<not null>>-id_situacion_albaran : int4"(10)"<<null>>-motivo : varchar"(50)"<<null>>-observaciones : varchar"(50)"

<<table>>Albaran

<<not null>> <<PK>>-id_producto : serial"(10)" = n...<<not null>>-codigo : bpchar"(10)"<<not null>>-nombre : varchar"(50)"<<null>>-atributo1 : bpchar"(10)"<<null>>-atributo2 : bpchar"(10)"<<null>>-atributo3 : bpchar"(10)"<<null>>-atributo4 : bpchar"(10)"<<null>>-descripcion : text"(2147483647)"<<not null>>-fecha_alta : date"(13)" = ('now'::text)...<<not null>>-fecha_modificacion : date"(13)" = ('n...<<null>>-fecha_baja : date"(13)"

<<table>>Producto

<<not null>> <<PK>>-id_solicitud : serial"(10)" = n...<<not null>>-fecha : date"(13)" = ('now'::text)::date<<null>>-fecha_recepcion : date"(13)"<<not null>>-id_tienda : int4"(10)"<<not null>>-id_situacion_solicitud : int4"(10)"<<null>>-observaciones : varchar"(50)"

<<table>>Solicitud

<<FK>>

{FK columns = id_origen ,PK columns = id_tienda }

fk_albaran_tiendaorigen

<<FK>>

{FK columns = id_destino ,PK columns = id_tienda }

fk_albaran_tiendadestino

<<FK>>

{FK columns = id_tipo_albaran ,PK columns = id_tipo_albaran }

fk_albaran_tipoalbaran

<<FK>>

{FK columns = id_situacion_albaran ,PK columns = id_situacion_albaran }

fk_albaran_situacionalbaran

<<FK>>

{FK columns = id_tienda ,PK columns = id_tienda }

fk_solicitud_tienda

<<FK>>


fk_distancia_tienda1

<<FK>>

{FK columns = id_producto ,PK columns = id_producto }

fk_stock_producto

<<FK>>


fk_movimiento_tienda

<<FK>>


fk_movimiento_producto

<<FK>>


fk_stock_tienda

<<FK>>

{FK columns = id_tipo_usuario ,PK columns = id_tipo_usuario }

fk_usuario_tipousuario

<<FK>>


fk_lineaalbaran_producto

<<FK>>

{FK columns = id_solicitud ,PK columns = id_producto }

fk_lineasolicitud_producto

<<FK>>

{FK columns = id_tienda2 ,PK columns = id_tienda }


<<FK>>


fk_usuario_tienda<<FK>>

{FK columns = id_tipo_tienda ,PK columns = id_tipo_tienda }

fk_tienda_tipotienda

<<FK>>

{FK columns = id_tipo_movimiento ,PK columns = id_tipo_movimiento }

fk_movimiento_tipomovimiento

<<FK>>

{FK columns = id_solicitud ,PK columns = id_solicitud }

fk_lineasolicitud_solicitud

<<FK>>

{FK columns = id_situacion_solicitud ,PK columns = id_situacion_solicitud }

fk_solicitud_tiposolicitud

<<FK>>

{FK columns = id_proveedor ,PK columns = id_proveedor }

fk_albaran_proveedor

<<FK>>

{FK columns = id_albaran ,PK columns = id_albaran }

fk_movimiento_albaran

<<FK>>


fk_lineaalbaran_albaran


Memoria 17/06/2013



Memoria 17/06/2013


5.6. Construcción del sistema

La construcción del sistema se ha realizado en el entorno integrado de desarrollo (IDE) Eclipse.

Al usar Dependency Injection, los objetos relevantes se enlazan entre sí mediante lo especificado en los archivos xml de configuración de Dependency Injection de Spring o mediante anotaciones en el código.

edu\uoc\esportstock\model

edu\uoc\esportstock\repository

edu\uoc\esportstock\repository\impl

edu\uoc\esportstock\repository\support

edu\uoc\esportstock\service

edu\uoc\esportstock\web

edu\uoc\esportstock\web\converter

edu\uoc\esportstock\web\util

La configuración del acceso a base de datos está en el archivo database.properties

\META-INF\spring\database.properties

Todos los mensajes y literales que muestra la aplicación están en (con soporte para diferentes idiomas):

Se realizaron las pruebas unitarias -cuando se necesitaron- y de integración durante esta fase.

Se han construido todas estas pruebas mediante JUnit en:

edu\uoc\esportstock\web\i18n\messages_de.properties

edu\uoc\esportstock\web\i18n\messages_en.properties

edu\uoc\esportstock\web\i18n\messages_es.properties

edu\uoc\esportstock\model\AlbaranDataOnDemand.java

edu\uoc\esportstock\model\AlbaranDataOnDemand.java

edu\uoc\esportstock\model\AlbaranIntegrationTest.java

edu\uoc\esportstock\model\LineaAlbaranDataOnDemand.java

edu\uoc\esportstock\model\LineaAlbaranIntegrationTest.java


Memoria 17/06/2013


edu\uoc\esportstock\model\LineaPedidoDataOnDemand.java

edu\uoc\esportstock\model\LineaPedidoIntegrationTest.java

edu\uoc\esportstock\model\MovimientoDataOnDemand.java

edu\uoc\esportstock\model\MovimientoIntegrationTest.java

edu\uoc\esportstock\model\PedidoDataOnDemand.java

edu\uoc\esportstock\model\PedidoIntegrationTest.java

edu\uoc\esportstock\model\ProductoDataOnDemand.java

edu\uoc\esportstock\model\ProductoIntegrationTest.java

edu\uoc\esportstock\model\ProveedorDataOnDemand.java

edu\uoc\esportstock\model\ProveedorIntegrationTest.java

edu\uoc\esportstock\model\StockDataOnDemand.java

edu\uoc\esportstock\model\StockIntegrationTest.java

edu\uoc\esportstock\model\TiendaDataOnDemand.java

edu\uoc\esportstock\model\TiendaIntegrationTest.java

edu\uoc\esportstock\model\TipoUsuarioDataOnDemand.java

edu\uoc\esportstock\model\TipoUsuarioIntegrationTest.java

edu\uoc\esportstock\model\UsuarioDataOnDemand.java

edu\uoc\esportstock\model\UsuarioIntegrationTest.java


Memoria 17/06/2013


5.7. Implantación y aceptación del sistema

Accediendo rápido a probar la aplicación

La aplicación para ser probada se ha colocado en un servidor de Amazon EC2 y se puede acceder a ella mediante la url:

http://ec2-50-19-102-7.compute-1.amazonaws.com/esportstock

Pedirá usuario y password para acceder, son posibles los siguientes usuarios:

Usuario: ADMIN2 Password: ADMIN2

Usuario: USUARIO02 Password: USUARIO02








Bueno, realmente usando el mantenimiento de la entidad Usuario en la aplicación se pueden dar de alta, baja y modificar los usuarios.

Distribución de desplegable y fuentes

Respecto al desplegable para instalar, y los fuentes, como los archivos son muy grandes para adjuntarlos, se distribuyen vía estos enlaces desde donde se pueden descargar:

Para instalar la aplicación solo es necesario en un tomcat7 o superior instalar en el directorio de webapps del tomcat el siguiente archivo war

https://dl.dropboxusercontent.com/u/533539/esportstock.war

No es necesario configurar la base de datos, ya que la configuración que por defecto lleva este war consiste en una base de datos en memoria hypersonic que además está dotada para realizar una carga inicial de datos para pruebas incluyendo los usuarios que se han mencionado.

En el siguiente enlace está disponible las fuentes del proyecto:

https://dl.dropboxusercontent.com/u/533539/esportstock-proyecto-solo-fuentes.zip

http://ec2-50-19-102-7.compute-1.amazonaws.com/esportstock

https://dl.dropboxusercontent.com/u/533539/esportstock.war

https://dl.dropboxusercontent.com/u/533539/esportstock-proyecto-solo-fuentes.zip


Memoria 17/06/2013


En el siguiente enlace está disponible el directorio del proyecto que se ha usado en eclipse (las librerias no están ya que se ha usado maven para la gestión del proyecto)

https://dl.dropboxusercontent.com/u/533539/esportstock-proyecto-completo-fuentesytarget.zip

Configuración de otra base de datos

Si se quisiera cambiar la base de datos, el proyecto está preparado para trabajar con cualquier base de datos que se ajuste a los estandares JDBC y JPA.

En el desarrollo del proyecto se ha usado Mysql 5 y al final y para el despliegue Hypersonic DB en memoria.

La configuración de la base de datos se hace tocando en los siguientes archivos y directorios:

esportstock.war\WEB-INF\classes\META-INF\spring\database.properties

esportstock.war\WEB-INF\classes\META-INF\persistence.xml

esportstock.war\WEB-INF\lib

En esportstock.war\WEB-INF\classes\META-INF\spring\database.properties, hay que poner el usuario y el password y driver y url jdbc, como por ejemplo

database.driverClassName=org.hsqldb.jdbcDriver

database.url=jdbc\:hsqldb\:mem\:esportstock

database.username=sa

database.password=

En esportstock.war\WEB-INF\classes\META-INF\persistence.xml, hay que poner el dialecto de Hibernate apropiado para la base de datos y la politica que seguira para crear las entidades, como por ejemplo

<property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>

<property name="hibernate.hbm2ddl.auto" value="create"/>

En la carpeta esportstock.war\WEB-INF\lib habrá que poner si no está el jar del driver jdbc.




Memoria 17/06/2013


5.8. Conclusiones

La sensación final de pasar por esta experiencia es de gran satisfacción

En principio se han alcanzado los objetivos propuestos: se ha analizado, diseñado e implementado una aplicación real, consiguiendo para ello desarrollar una aplicación con un interfaz muy intuitivo que hará que la curva de aprendizaje del manejo del producto sea realmente corta.

Además se ha lidiado con el cambio de alcance que se produjo en la fase de implementación transformándose del desarrollo de un sistema que cumpliese con las funcionalidades esperadas a dejar la arquitectura implementada y reducir los casos de uso implementados para poder realizarlos en el trascurso de un semestre. Aunque no se hayan podido implementar todas las funcionalidades pensadas en el análisis y diseño, se ha alcanzado una satisfacción por el alumno ya que la arquitectura sobre la que se ha desarrollado este sistema incorpora tecnologías punteras y las mejores prácticas de desarrollo.

La arquitectura está construida sobre el framework JSF para el interfaz de usuario, Hibernate para la gestión de la persistencia y Spring Framework como pegamento para unirlo todo. Esta arquitectura proporciona un conjunto de servicios a las aplicaciones desarrolladas sobre ella como son la gestión de pantallas, gestión de seguridad y permisos de grupos de usuarios, internacionalización y gestión centralizada de mensajes y literales de la aplicación, un Framework para el interfaz de usuario que simplifica su construcción y da soporte para la validación de campos y el control de la seguridad y el aspecto de cliente pesado dentro de un cliente ligero, así como clases de ayuda para trabajar con la persistencia, las transacciones y los criterios de las búsquedas de información.

Se ha conseguido desarrollar un software del mundo real con herramientas y tecnologías Open Source tanto para su desarrollo como para su implantación. Por tanto, al no tener el peso de una política de licencias a sus espaldas, con el ahorro tan enorme en costes que esto supone y dado que es la plataforma java, se puede implantar en cualquier infraestructura hardware disponible.

La herramienta de desarrollo utilizada ya se dominaba (Eclipse) con lo cual no se ha aprendido mucho en este aspecto, pero sin embargo, a nivel de tecnologías JEE, se ha profundizado en el conocimiento inicial que ya se tenía de Spring Framework e Hibernate y se ha tenido la oportunidad, dado el objetivo de desarrollar una nueva arquitectura, de buscar, seleccionar y aprender la que el autor de esta memoria (y otros más) creen que es la mejor tecnología actual y puntera para el desarrollo potente, rápido y mantenible del interfaz de usuario en aplicaciones empresariales con interfaz Web.

En resumen, 156 archivos y 1013713 bytes de código fuente, una gran satisfacción y deseos de continuar el asunto de la idea de la aplicación


Memoria 17/06/2013


6. Glosario BD Base de datos.

Bean Un Bean es un componente software que tiene la particularidad de ser reutilizable y así evitar la tediosa tarea de programar los distintos componentes uno a uno. Un bean es un objeto que debe cumplir unos requisitos: implementar Serializable, tener todos sus atributos privados (private), tener métodos set() y get() públicos de los atributos privados que nos interesen y tener un constructor público por defecto

EJB Enterprise JavaBeans. El API define un conjunto de APIs que un contenedor de objetos distribuidos soportará para suministrar persistencia, RPCs (usando RMI o RMI-IIOP), control de concurrencia, transacciones y control de acceso para objetos distribuidos.

Hibernate ORM de código abierto de reconocido prestigio en la comunidad de desarrolladores que ha influido en la nueva especificación EJB 3 para definir el API empresarial JEE JPA. De hecho actualmente Hibernate es una de las implementaciones de JPA.

JEE Java Enterprise Edition (antes conocida por J2EE). Especificaciones para el desarrollo de aplicaciones empresariales. Estándar liderado por Sun para aplicaciones empresariales.

JPA Java Persistence API, es el API de persistencia desarrollada para la plataforma Java EE e incluida en el estándar EJB 3. Este API busca unificar la manera en que funcionan las utilidades que proveen un mapeo objeto-relacional. El objetivo que persigue el diseño de este API es no perder las ventajas de la orientación a objetos al interactuar con una base de datos, como sí pasaba con EJB2, y permitir usar objetos regulares (conocidos como POJOs).

ORM Object Relational Mapping. Puente entre el mundo de los objetos y las bases de datos relacionales

POJO Un POJO (acrónimo de Plain Old Java Object) es una sigla creada por Martin Fowler, Rebecca Parsons y Josh MacKenzie en septiembre de 2000 y utilizada por programadores de Java para enfatizar el uso de clases simples y que no dependen de un framework en especial.

SGBDR Sistema Gestor de Bases de Datos Relacionales.

Spring Framework Es un framework de código abierto de desarrollo de aplicaciones para la plataforma Java. Entre todas las buenas prácticas que reune, destaca por dotar del patrón Dependency Injection y Aspect Object Programming (AOP) y otras muchas clases de soporte para las habituales necesidades de las arquitecturas de aplicaciones java empresariales.

TFC Trabajo de Fin de Carrera

UML Unified Modelling Language. Lenguaje para modelo utilizado como técnica del análisis y diseño de software.


Memoria 17/06/2013


7. Bibliografía JEE

The Java EE 5 Tutorial.For Sun Java System Application Server 9.1

http://java.sun.com/javaee/5/docs/tutorial/doc/

Enterprise JavaBeans Specification Documentation 3.0 Final Release

http://java.sun.com/products/ejb/docs.html

Patrones de diseño y patrones de arquitectura

Patterns of Enterprise Application Architecture. (The Addison-Wesley Signature Series) by Martin Fowler

Design Patterns: Elements of Reusable Object-Oriented Software. (Addison-Wesley Professional Computing Series) by Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides

Core J2EE™ Patterns: Best Practices and Design Strategies. By Deepak Alur, John Crupi, Dan Malks. Publisher: Prentice Hall.

J2EE Design Patterns. By William Crawford, Jonathan Kaplan. Publisher: O'Reilly

Proceso de desarrollo de software y UML

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. (3rd Edition) (Hardcover) by Craig Larman

Refactoring: Improving the Design of Existing Code, (The Addison-Wesley Object Technology Series) (Hardcover) by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

The Unified Software Development Process. (Addison-Wesley Object Technology Series) (Hardcover) by Ivar Jacobson, Grady Booch, James Rumbaugh

The Unified Modeling Language Reference Manual. (2nd Edition) (The Addison-Wesley Object Technology Series) (Hardcover) by James Rumbaugh, Ivar Jacobson, Grady Booch

http://java.sun.com/javaee/5/docs/tutorial/doc/

http://java.sun.com/products/ejb/docs.html


Memoria 17/06/2013


The Unified Modeling Language User Guide. (2nd Edition) (The Addison-Wesley Object Technology Series) by Grady Booch, James Rumbaugh, Ivar Jacobson

Use Case Modeling. (The Addison-Wesley Object Technology Series) by Kurt Bittner, Ian Spence.

Spring Framework

Spring in Action. By Craig Walls and Ryan Breidenbach. Publisher: Manning.

Spring Live. by Matt Raible. Publisher: SourceBeat

Spring: A Developer's Notebook. By Justin Gehtland, Bruce A. Tate Publisher: O'Reilly

POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks. by Chris Richardson Pro Spring by Rob Harrop, Jan Machacek Publisher: Apress

Professional Java Development with the Spring Framework. By Rod Johnson, Juergen Hoeller , Alef Arendsen, Thomas Risberg, Colin Sampaleanu Publisher: Wiley Publishing, Inc.

Hibernate

Hibernate in Action. By Christian Bauer, Gavin King Publisher: Manning

Java Persistence with Hibernate. By Christian Bauer, Gavin King Publisher: Manning

Beginning Hibernate From Novice to Professional An introduction to all the new features of the Hibernate 3.2 persistence API. By Dave Minter and Jeff Linwood. Publisher: Apress


Memoria 17/06/2013


8. Anexos A continuación se anexan dos documentos:

• El análisis del sistema

• El diseño del sistema

Documento de Análisis eSportStock: Gestor de stocks

TRABAJO DE FIN DE CARRERA.

INGENIERÍA TÉCNICA DE INFORMÁTICA DE GESTIÓN

David Rodríguez Villar Consultor Salvador Campo Mazarico. 15 de abril de 2013

Documento de Análisis. eSportStock: Gestor de stocks

TRABAJO DE FIN DE CARRERA. INGENIERÍA TÉCNICA DE INFORMÁTICA DE GESTIÓN. 2

“Hay dos clases de fracasos: los que provienen de pensar y nunca hacer, y los que provienen de hacer y nunca pensar.”

Citado por Roger Pressman, “Nuestras peores prácticas de desarrollo”, IEEE Software, Marzo de 1996.



Contenido 1 Análisis de funcionalidades __________________________________________ 6

1.1 Subsistema de mantenimiento ___________________________________________ 6

1.1.1 Descripción _______________________________________________________ 6

1.1.2 Casos de uso ______________________________________________________ 6

1.1.2.1 UML Gestión de Usuarios __________________________________________ 6

1.1.2.2 Alta Usuario ____________________________________________________ 7

1.1.2.3 Baja Usuario ____________________________________________________ 8

1.1.2.4 Modifica Usuario ________________________________________________ 9

1.1.2.5 Consulta Usuario _______________________________________________ 10

1.1.2.6 UML Gestión de Centros _________________________________________ 11

1.1.2.7 Alta Centro ____________________________________________________ 12

1.1.2.8 Baja Centro ____________________________________________________ 13

1.1.2.9 Modifica Centro ________________________________________________ 14

1.1.2.10 Consulta Centro ______________________________________________ 15

1.1.2.11 UML Gestión de Proveedores ___________________________________ 16

1.1.2.12 Alta Proveedor _______________________________________________ 17

1.1.2.13 Baja Proveedor _______________________________________________ 18

1.1.2.14 Modifica Proveedor ___________________________________________ 19

1.1.2.15 Consulta Proveedor ___________________________________________ 20

1.1.2.16 UML Gestión de Artículos ______________________________________ 21

1.1.2.17 Alta Articulo _________________________________________________ 22

1.1.2.18 Baja Articulo _________________________________________________ 23

1.1.2.19 Modifica Articulo _____________________________________________ 24

1.1.2.20 Consulta Articulo _____________________________________________ 25

1.1.2.21 UML Diagrama de uso Gestión de Distancias _______________________ 26

1.1.2.22 Gestiona Distancia ____________________________________________ 27

1.1.3 Prototipo de Interfaz de usuario _____________________________________ 28

1.1.3.1 Gestión de Usuarios _____________________________________________ 28

1.1.3.2 Consulta de usuarios ____________________________________________ 29

1.1.3.3 Gestión de Centros ______________________________________________ 30

1.1.3.4 Consulta de centros _____________________________________________ 31

1.1.3.5 Gestión de Proveedores __________________________________________ 32



1.1.3.6 Consulta de proveedores _________________________________________ 33

1.1.3.7 Gestión de Artículos _____________________________________________ 34

1.1.3.8 Consulta de artículos ____________________________________________ 35

1.1.3.9 Gestión de Distancias ____________________________________________ 36

1.2 Subsistema de control de Flujo __________________________________________ 37

1.2.1 Descripción ______________________________________________________ 37

1.2.2 Casos de uso _____________________________________________________ 38

1.2.2.1 UML Gestión de solicitudes _______________________________________ 38

1.2.2.2 Consulta de solicitudes___________________________________________ 39

1.2.2.3 Solicitud de reposición ___________________________________________ 40

1.2.2.4 Salida a proveedor ______________________________________________ 41

1.2.2.5 Recepción de material de proveedor _______________________________ 42

1.2.2.6 UML Gestión de traspasos ________________________________________ 43

1.2.2.7 Recepción de material ___________________________________________ 44

1.2.2.8 Traspaso de material ____________________________________________ 45

1.2.2.9 Consulta de traspasos ___________________________________________ 46

1.2.2.10 Consulta de traspasos de tienda _________________________________ 47

1.2.2.11 UML Gestión de ventas ________________________________________ 48

1.2.2.12 Salidas de ventas _____________________________________________ 49

1.2.2.13 UML Gestión de existencias _____________________________________ 50

1.2.2.14 Gestión consulta stocks ________________________________________ 51

1.2.2.15 Gestión Consulta stocks por tienda _______________________________ 52

1.2.2.16 Consulta de movimientos de artículos por tienda ___________________ 53


1.2.3.1 Albarán de Compra______________________________________________ 54

1.2.3.2 Albarán de Devolución ___________________________________________ 55

1.2.3.3 Solicitud de reposición de género __________________________________ 56

1.2.3.4 Albarán de reposición consulta ____________________________________ 57

1.2.3.5 Albarán de traspaso _____________________________________________ 58

1.2.3.6 Consulta de traspasos ___________________________________________ 59

1.2.3.7 Albarán de Venta _______________________________________________ 60

1.2.3.8 Consulta de Artículos ____________________________________________ 61

1.2.3.9 Consulta Stock Artículos/Tiendas __________________________________ 62

1.2.3.10 Consulta Stock Artículos/Tienda Movimientos ______________________ 63

1.3 Subsistema de listados y estadísticas _____________________________________ 65



1.3.1 Descripción ______________________________________________________ 65

1.3.2 Casos de uso _____________________________________________________ 65

1.3.2.1 UML Listados y Estadísticas _______________________________________ 65

1.3.2.2 Rotación Stocks ________________________________________________ 66

1.3.2.3 Rotura Stocks __________________________________________________ 67

1.3.2.4 Estadística Productos ____________________________________________ 68

1.3.2.5 Imprimir ______________________________________________________ 70


1.3.3.1 Rotación de Stocks ______________________________________________ 71

1.3.3.2 Rotura de Stocks ________________________________________________ 72

1.3.3.3 Estadísticas de Productos _________________________________________ 73

1.4 Subsistema de conexión _______________________________________________ 76

1.4.1 Descripción ______________________________________________________ 76

1.4.2 Casos de uso _____________________________________________________ 77

1.4.2.1 UML Subsistema de conexión _____________________________________ 77

1.4.2.2 Acceso al sistema _______________________________________________ 78

1.4.2.3 Acceso al sistema administrador ___________________________________ 79

1.4.2.4 Acceso al sistema operador central _________________________________ 81

1.4.2.5 Acceso al sistema operador tienda _________________________________ 82

1.4.2.6 Cambio de contraseña ___________________________________________ 83


1.4.3.1 Login _________________________________________________________ 84


1.4.3.3 Ventana principal: Usuario administrador ___________________________ 85

1.4.3.4 Ventana principal: Usuario operador de central _______________________ 85

1.4.3.5 Ventana principal: Usuario operador de tienda _______________________ 86



1 Análisis de funcionalidades

1.1 Subsistema de mantenimiento 1.1.1 Descripción

El subsistema de mantenimiento será el encargado de gestionar los centros (almacenes tiendas y almacenes centrales), usuarios, proveedores y productos. Coexistirán tres tipos de perfiles de usuarios que serán estáticos, es decir, no se va a generar un caso de uso para la creación de los mismos.

1.1.2 Casos de uso

1.1.2.1 UML Gestión de Usuarios



Especificaciones de uso de Gestión de Usuarios

ESPECIFICACION DE CASO DE USO

Caso de uso: 1.1.2.2 Alta Usuario

Actores: • administrador

Descripción: Realizar el alta de un usuario en el sistema

RELACIONES

Incluye: NA

Extiende: Consulta Usuario

Herencia: NA

CONDICIONES

Precondiciones: Usuario a dar de alta no exista previamente.

Postcondiciones: El nuevo usuario quedará registrado en el sistema.

FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Usuarios->Alta. 3. Usuario accede a la pantalla de altas de usuarios donde, inicialmente, sólo tendrá activada la casilla de código y [FlujoAlternativo1] botón de búsqueda a su derecha.

4. El usuario introduce el código del nuevo usuario.

5. Si el código no existe, se desactivará el campo código y se activarán el resto. [FlujoExcepcional1]

6. Rellenados todos los campos, se tiene la opción de pulsar Aceptar para aceptar la operación o Cancelar para cancelar la misma.

7. Si se pulsa Aceptar y si todos los campos son correctos, aparecerá una pantalla de confirmación de operación, con las opciones Aceptar o Cancelar.

8. Pulsando la opción Aceptar, los cambios se guardarán en el sistema. [FlujoExcepcional2]

Flujos alternativos:

1. Se accede al caso de uso Consulta Usuario, donde se podrá realizar una búsqueda del usuario.

Flujos excepcionales:

1.- Código existe en el sistema. Mensaje de error.

2.- Falta de datos o incongruencia en los mismos. Mensaje de error.




Caso de uso: 1.1.2.3 Baja Usuario


Descripción: Realizar la baja de un usuario en el sistema

RELACIONES

Incluye: NA

Extiende: ConsultaUsuario

Herencia: NA

CONDICIONES

Precondiciones: Qué el usuario exista previamente.

Postcondiciones: El usuario será dado de baja en el sistema.

FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Usuarios->Baja. 3. Usuario accede a la pantalla de bajas de usuarios donde, inicialmente, sólo tendrá activada la casilla de código y [FlujoAlternativo1] botón de búsqueda a su derecha.

4. El usuario introduce el código del usuario a dar de baja.

5. Si el código existe, se mostrarán los datos por pantalla. [FlujoExcepcional1]

6. Si el código es el del propio del usuario [FlujoExcepcional2]

6. Se tiene la opción de pulsar Aceptar para aceptar la operación o Cancelar para cancelar la misma.

7. Si se pulsa Aceptar aparecerá una pantalla de confirmación de operación, con las opciones Aceptar o Cancelar.

8. Pulsando el botón Aceptar, la baja se habrá realizado.




1.- Código no existe en el sistema. Mensaje de error.

2- No puede dar de baja su propio código. Mensaje de error.




Caso de uso: 1.1.2.4 Modifica Usuario


Descripción: Realizar la modificación de un usuario en el sistema

RELACIONES

Incluye: NA

Extiende: Consulta Usuario

Herencia: NA

CONDICIONES

Precondiciones: Qué el usuario exista previamente.

Postcondiciones: El usuario incluirá las modificaciones realizadas.

FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Usuarios->Modificación. 3. Usuario accede a la pantalla de modificación de usuarios donde, inicialmente, sólo tendrá activada la casilla de código y [FlujoAlternativo1] botón de búsqueda a su derecha.

4. El usuario introduce el código del usuario a modificar.

5. Si el código existe, se desactivará el campo código y se activarán el resto. [FlujoExcepcional1]

6. Modificados los datos, se tiene la opción de pulsar Aceptar para aceptar la operación o Cancelar para cancelar la misma.











Caso de uso: 1.1.2.5 Consulta Usuario


Descripción: Realizar la consulta usuarios en el sistema

RELACIONES

Incluye: NA

Extiende: NA

Herencia: NA

CONDICIONES

Precondiciones: Qué el usuario exista previamente

Postcondiciones: Se mostrará el resultado de la búsqueda.

FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestion Usuarios->Consulta. 3. Usuario accede a la pantalla de consulta de usuarios donde podrá buscar por Código, Nombre y/o Apellidos.

6. Introducido los datos se tiene la opción de pulsar Buscar para aceptar la operación de búsqueda o Salir para terminar la misma.

7. Si los datos de la búsqueda son correctos, se mostrarán los datos. [FlujoExcepcional1].


NA


1.- Datos de búsqueda introducidos no existen en el sistema. Mensaje de error.



1.1.2.6 UML Gestión de Centros



Especificaciones de uso de Gestión Centros


Caso de uso: 1.1.2.7 Alta Centro


Descripción: Realizar el alta de un centro en el sistema

RELACIONES

Incluye: NA

Extiende: Consulta Centro

Herencia: NA

CONDICIONES

Precondiciones: Centro a dar de alta no exista previamente.

Postcondiciones: El nuevo centro quedará registrado en el sistema.

FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Centros->Alta Centro. 3. Usuario accede a la pantalla de altas de centros donde, inicialmente, sólo tendrá activada la casilla de código y [FlujoAlternativo1] botón de búsqueda a su derecha.

4. El usuario introduce el código del nuevo centro.

5. Si el código no existe, se desactivará el campo código y se activarán el resto. [FlujoExcepcional1]





1. Se accede al caso de uso Consulta Centro, donde se podrá realizar una búsqueda del centro.







Caso de uso: 1.1.2.8 Baja Centro


Descripción: Realizar la baja de un centro en el sistema

RELACIONES

Incluye: NA


Herencia: NA

CONDICIONES

Precondiciones: Qué el centro exista previamente.

Postcondiciones: El centro será dado de baja en el sistema.

FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Centros->Baja. 3. Usuario accede a la pantalla de bajas de centros donde, inicialmente, sólo tendrá activada la casilla de código y [FlujoAlternativo1] botón de búsqueda a su derecha.

4. El usuario introduce el código del centro a dar de baja.












Caso de uso: 1.1.2.9 Modifica Centro


Descripción: Realizar la modificación de los datos de un centro en el sistema.

RELACIONES

Incluye: NA


Herencia: NA

CONDICIONES

Precondiciones: Qué el centro exista previamente

Postcondiciones: El centro incluirá las modificaciones realizadas.

FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Centros->Modificación. 3. Usuario accede a la pantalla de modificación de centros donde, inicialmente, sólo tendrá activada la casilla de código y [FlujoAlternativo1] botón de búsqueda a su derecha.

4. El usuario introduce el código del centro a modificar.













Caso de uso: 1.1.2.10 Consulta Centro


Descripción: Realizar la consulta de centros en el sistema

RELACIONES

Incluye: NA

Extiende: NA

Herencia: NA

CONDICIONES

Precondiciones: Qué el centro exista previamente


FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Centros->Consulta. 3. Usuario accede a la pantalla de consulta de centros donde podrá buscar por Código, Razón Social o Contacto.




NA





1.1.2.11 UML Gestión de Proveedores



Especificaciones de uso de Gestión Proveedores


Caso de uso: 1.1.2.12 Alta Proveedor


Descripción: Realizar el alta de un proveedor en el sistema

RELACIONES

Incluye: NA

Extiende: Consulta de proveedor

Herencia: NA

CONDICIONES

Precondiciones: Proveedor a dar de alta no exista previamente.

Postcondiciones: El nuevo proveedor quedará registrado en el sistema.

FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Proveedores->Alta. 3. Usuario accede a la pantalla de altas de proveedores donde, inicialmente, sólo tendrá activada la casilla de NIF y [FlujoAlternativo1] botón de búsqueda a su derecha.

4. El usuario introduce el NIF del proveedor a dar de alta.

5. Si el NIF no existe, se mostrarán los datos por pantalla. [FlujoExcepcional1]



8. Pulsando el botón Aceptar, el alta se habrá realizado.


1. Se accede al caso de uso Consulta Proveedor, donde se podrá realizar una búsqueda del proveedor.


1.- NIF existe en el sistema. Mensaje de error.




Caso de uso: 1.1.2.13 Baja Proveedor


Descripción: Realizar la baja de un proveedor en el sistema

RELACIONES

Incluye: NA

Extiende: Consulta Proveedor

Herencia: NA

CONDICIONES

Precondiciones: Qué el proveedor exista previamente.

Postcondiciones: El proveedor será dado de baja en el sistema.

FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Proveedores->Baja. 3. Usuario accede a la pantalla de bajas de proveedores donde, inicialmente, sólo tendrá activada la casilla de NIF y [FlujoAlternativo1] botón de búsqueda a su derecha.

4. El usuario introduce el NIF del proveedor a dar de baja.

5. Si el NIF existe, se mostrarán los datos por pantalla. [FlujoExcepcional1]











Caso de uso: 1.1.2.14 Modifica Proveedor


Descripción: Realizar la modificación de los datos de un proveedor en el sistema.

RELACIONES

Incluye: NA

Extiende: Consulta Proveedor

Herencia: NA

CONDICIONES

Precondiciones: Qué el proveedor exista previamente

Postcondiciones: El proveedor incluirá las condiciones realizadas.

FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Proveedores->Modificación. 3. Usuario accede a la pantalla de modificación de proveedores donde, inicialmente, sólo tendrá activada la casilla de NIF y [FlujoAlternativo1] botón de búsqueda a su derecha.

4. El usuario introduce el NIF del proveedor a modificar.

5. Si el NIF existe, se desactivará el campo NIF y se activarán el resto. [FlujoExcepcional1]







1.- NIF no existe en el sistema. Mensaje de error.





Caso de uso: 1.1.2.15 Consulta Proveedor


Descripción: Realizar la consulta de proveedor en el sistema

RELACIONES

Incluye: NA

Extiende: NA

Herencia: NA

CONDICIONES

Precondiciones: Qué el Proveedor exista previamente


FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Proveedores->Consulta. 3. Usuario accede a la pantalla de consulta de proveedores donde podrá buscar por NIF, Razón Social o Contacto.




NA





1.1.2.16 UML Gestión de Artículos



Especificaciones de uso de Gestión Artículos


Caso de uso: 1.1.2.17 Alta Articulo


Descripción: Realizar el alta de un artículo en el sistema

RELACIONES

Incluye: NA

Extiende: Consulta Articulo

Herencia: NA

CONDICIONES

Precondiciones: Artículo a dar de alta no exista previamente.

Postcondiciones: El nuevo artículo quedará registrado en el sistema.

FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Artículos->Alta. 3. Usuario accede a la pantalla de altas de artículos donde, inicialmente, sólo tendrá activada la casilla de Código y [FlujoAlternativo1] botón de búsqueda a su derecha.

4. El usuario introduce el código del nuevo artículo.

5. Si el código no existe, se desactivará el campo Código y se activarán el resto. [FlujoExcepcional1]





1. Se accede al caso de uso Consulta Articulo, donde se podrá realizar una búsqueda del artículo antes de introducir los datos.







Caso de uso: 1.1.2.18 Baja Articulo


Descripción: Realizar la baja de un artículo en el sistema

RELACIONES

Incluye: NA


Herencia: NA

CONDICIONES

Precondiciones: Qué el articulo exista previamente.

Postcondiciones: El artículo será dado de baja en el sistema.

FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Artículos->Baja. 3. Usuario accede a la pantalla de bajas de artículos donde, inicialmente, sólo tendrá activada la casilla de Código y [FlujoAlternativo1] botón de búsqueda a su derecha.

4. El usuario introduce el código del artículo a dar de baja.






1. Se accede al caso de uso Consulta Articulo, donde se podrá realizar una búsqueda del artículo.






Caso de uso: 1.1.2.19 Modifica Articulo


Descripción: Realizar la modificación de los datos de un artículo en el sistema.

RELACIONES

Incluye: NA


Herencia: NA

CONDICIONES

Precondiciones: Qué el artículo exista previamente

Postcondiciones: El artículo incluirá las modificaciones realizadas.

FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Artículos->Modificación. 3. Usuario accede a la pantalla de modificación de artículos donde, inicialmente, sólo tendrá activada la casilla de código y [FlujoAlternativo1] botón de búsqueda a su derecha.

4. El usuario introduce el código del artículo a modificar.






1. Se accede al caso de uso Consulta Articulo, donde se podrá realizar una búsqueda del artículo.







Caso de uso: 1.1.2.20 Consulta Articulo


Descripción: Realizar la consulta de artículo en el sistema.

RELACIONES

Incluye: NA

Extiende: NA

Herencia: NA

CONDICIONES



FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Artículos->Consulta. 3. Usuario accede a la pantalla de consulta de artículos donde podrá buscar por Código, descripción y/o atributos del artículo

4. Introducido los datos se tiene la opción de pulsar Buscar para Aceptar la operación de búsqueda o Salir para terminar la misma.



NA





1.1.2.21 UML Diagrama de uso Gestión de Distancias



Especificaciones de uso de Gestión Distancias


Caso de uso: 1.1.2.22 Gestiona Distancia


Descripción: Realizar la modificación de los datos de un artículo en el sistema.

RELACIONES

Incluye: Consulta Centro

Extiende: NA

Herencia: NA

CONDICIONES



FLUJOS

Flujo básico: 1. Usuario con roll administrador ha entrado al sistema. 2. Usuario administrador accede al menú Mantenimiento->Gestión Distancias. 3. Usuario accede a la pantalla de modificación de distancias donde, tendrá la casilla de código de centro y [FlujoAlternativo1] botón de búsqueda a su derecha.

4. El usuario introduce el código del centro a modificar la distancia.

5. Si el código existe, aparecerá el resultado de la distancia a todos los centros. [FlujoExcepcional1][Flujo Alternativo2].

6. Se procede a modificar la distancia que se requiera. Una vez realizada la modificación de los datos, se tiene la opción de pulsar Aceptar para aceptar la operación o Cancelar para cancelar la misma.





2. El usuario consulta resultado y cierra la pantalla.






1.1.3 Prototipo de Interfaz de usuario

A continuación se mostrará una aproximación de las pantallas de los distintos casos de usos del subsistema de mantenimiento.

1.1.3.1 Gestión de Usuarios

Alta, baja y modificación de usuarios

La interfaz para estos tres casos de uso será la misma. La diferenciación en su uso será por el acceso desde el menú de gestión de usuarios realizado.



1.1.3.2 Consulta de usuarios



1.1.3.3 Gestión de Centros

Alta, baja y modificación de centros

La interfaz para estos tres casos de uso será la misma. La diferenciación en su uso será por el acceso desde el menú de gestión de centros realizado.



1.1.3.4 Consulta de centros



1.1.3.5 Gestión de Proveedores

Alta, baja y modificación de proveedores

La interfaz para estos tres casos de uso será la misma. La diferenciación en su uso será por el acceso desde el menú de gestión de proveedores realizado.



1.1.3.6 Consulta de proveedores



1.1.3.7 Gestión de Artículos

Alta, baja y modificación de artículos

La interfaz para estos tres casos de uso será la misma. La diferenciación en su uso será por el acceso desde el menú de gestión de artículos realizado.



1.1.3.8 Consulta de artículos

Pantalla que permite consultar los artículos bajo una serie de filtros como el código la descripción, los atributos del artículo o si un artículo ha sufrido rotura de stock.

Esta pantalla informa del stock general de todos los almacenes, haciendo un doble click sobre uno de los artículos nos ofrecerá el detalle de la situación de ese stock general.



1.1.3.9 Gestión de Distancias

Modificación y consulta

Existirá una única ventana con la que a la vez que se busca las distancias entre las almacenes de las tiendas se podrá modificar los resultados.



1.2 Subsistema de control de Flujo

1.2.1 Descripción

Es el subsistema que gestiona los movimientos de artículos, que realizan los diferentes usuarios, dentro la aplicación.

Existen dos tipos de usuarios (actores) que contempla este subsistema:

• Operador Almacén central • Operador tienda

OPERACIONES POR PERFIL

Operador de tienda • Consulta de solicitudes

• Solicitud de reposición

• Recepción de material

• Traspaso de material

• Consulta de traspasos de tienda

• Gestión consulta de stocks

• Consulta de movimientos de artículos por tienda

• Salida de ventas

Operador de central • Consulta de solicitudes

• Recepción de material de proveedor

• Salida a proveedor

• Consulta de traspasos




• Gestión consulta stocks por tienda




1.2.2 Casos de uso

1.2.2.1 UML Gestión de solicitudes




Caso de uso: 1.2.2.2 Consulta de solicitudes

Actores: • Operador Almacén Central

• Operador tienda

Descripción: Control de las solicitudes realizadas

RELACIONES

Incluye: • UseCase Solicitud de reposición

Extiende: NA

Herencia: NA

CONDICIONES

Precondiciones: Las solicitudes a consultar existen previamente en el sistema

Postcondiciones: El usuario accede a la lista de solicitudes

FLUJOS

Flujo básico: 1. El sistema presenta la pantalla de consulta de solicitudes al usuario, donde se muestran los campos albarán, Fecha, solicitado por y situación para la selección de las solicitudes

2. El usuario introduce los datos para seleccionar las solicitudes[Flujo de excepción: El sistema no valida los albaranes ni la fecha introducida]

3. El usuario pulsará el botón de buscar

4. El sistema comprueba que los datos introducidos sean correctos [Flujo excepcional: El sistema no valida los datos]

5. El sistema muestra los datos

Flujos alternativos: 1. El sistema presenta la pantalla de consulta de solicitudes al usuario, donde se muestran los campos albarán, Fecha, solicitado por y situación para la selección de las solicitudes

2. El usuario pulsa la botón de salir sin efectuar la consulta

Flujos excepcionales: 1. El sistema valida que los datos introducidos por pantalla sean correctos




Caso de uso: 1.2.2.3 Solicitud de reposición

Actores: • Operador tienda

Descripción: El operador de tienda solicita genero al almacén central

RELACIONES

Incluye: • UseCase Consulta de artículo

Extiende: NA

Herencia: NA

CONDICIONES

Precondiciones: El usuario solicita genero dado de alta

Postcondiciones: El usuario genera el albarán de solicitud

FLUJOS

Flujo básico: 1. Se presenta la pantalla solicitud de reposición de género; el usuario pulsa el botón de nueva y se genera una solicitud nueva con los siguientes datos: número de albarán (correlativo), el usuario validado, la fecha del sistema y la tienda que solicita dicho género.

2. El usuario modifica la situación de dicho albarán si es necesario

3. Introduce artículos [Flujo excepcional: El sistema no valida que el código de artículo sea el correcto][Flujo alternativo: El usuario el código de artículo que solicita y accede a la consulta de artículos] con sus cantidades, en caso necesario puede indicar observaciones

4. El usuario pulsa el botón de añadir línea o bien la botón de borrar línea y va actualizando la solicitud

5. El operador finaliza el proceso pulsando el botón de salir

Flujos alternativos: 1. Se presenta la pantalla y el usuario sin pulsar el botón nueva cancela el alta pulsando salir

2. El usuario desconoce el código de artículo que solicita y accede a la consulta de artículos

Flujos excepcionales: 1. El sistema no valida el código de artículo.




Caso de uso: 1.2.2.4 Salida a proveedor

Actores: • Operador A.Central

Descripción: El usuario genera el albarán de envio de género defectuoso al proveedor

RELACIONES


• UseCase Consulta de proveedor

Extiende: NA

Herencia: NA

CONDICIONES

Precondiciones: El código de proveedor y el o los códigos de artículo existen

Postcondiciones: El usuario genera el albarán de devolución

FLUJOS

Flujo básico: 1. Se presenta la pantalla albarán de Devolución; el usuario pulsa el botón de nuevo y se genera un albarán de devolución con los siguientes datos: número de albarán (correlativo), el usuario validado, la fecha del sistema.

2. El usuario introduce el código del proveedor [Flujo alternativo: El usuario desconoce el código del proveedor y accede a la consulta de proveedores] [Flujo excepcional: El sistema no valida que el código de proveedor sea el correcto]

3. Introduce artículos [Flujo alternativo: El usuario desconoce el código del artículo y accede a la consulta de proveedores] [Flujo excepcional: El sistema no valida que el código de artículo sea el correcto] con sus cantidades, en caso necesario puede indicar observaciones y pulsando el botón de añadir línea o bien la botón de borrar línea y va actualizando la el albarán de devolución.


Flujos alternativos: 1. Se presenta la pantalla y el usuario cancela pulsando salir

2. El usuario desconoce el código de artículo que recepciona y accede a la consulta de artículos

3. El usuario desconoce el código del proveedor y accede a la consulta de proveedores

Flujos excepcionales: 1. El sistema no valida el código de artículo ni el código de proveedor




Caso de uso: 1.2.2.5 Recepción de material de proveedor


Descripción: El usuario genera el albarán de recepción de género de proveedor

RELACIONES


• UseCase Consulta de proveedor

Extiende: NA

Herencia: NA

CONDICIONES

Precondiciones: El código de proveedor y el o los códigos de artículo existen

Postcondiciones: El usuario genera el albarán de devolución

FLUJOS

Flujo básico: 1. Se presenta la pantalla Albarán de compra el usuario pulsa el botón de nuevo y se genera un albarán de compra con los siguientes datos: número de albarán (correlativo), el usuario validado, la fecha del sistema.

2. El usuario introduce el código del proveedor [Flujo alternativo: El usuario puede acceder a la consulta de proveedor] [Flujo excepcional: El sistema no valida que el código de proveedor sea el correcto]

3. Introduce artículos[Flujo alternativo: El usuario puede acceder a la consulta de artículos] [Flujo excepcional: El sistema no valida que el código de artículo sea el correcto] con sus cantidades y pulsando el botón de añadir línea o bien la botón de borrar línea y va actualizando la el albarán de compra

4. El operador finaliza el proceso pulsando la botón de salir


2. El usuario desconoce el código de artículo que recepciona y accede a la consulta de artículos

3. El usuario puede acceder a la consulta de proveedor




1.2.2.6 UML Gestión de traspasos




Caso de uso: 1.2.2.7 Recepción de material


• Operador Almacén Central

Descripción: El usuario recibe género

RELACIONES

Incluye: NA

Extiende: NA

Herencia: NA

CONDICIONES

Precondiciones: El código de artículo existe en el sistema

Postcondiciones: El usuario genera el albarán de recepción

FLUJOS

Flujo básico: 1. Se presenta la pantalla Albarán traspaso, el usuario pulsa el botón de nuevo y se genera un albarán de traspaso con los siguientes datos: número de albarán (correlativo), el usuario validado, la fecha del sistema y el origen del material

2. El usuario modifica el origen en caso de ser Operador del almacén central [Flujo alternativo: El usuario es operador de tienda y esta opción no está disponible]

3. Introduce artículos [Flujo alternativo: El usuario desconoce el código de artículo y pulsa el botón que accede a la consulta de artículos] [Flujo excepcional: El sistema no valida que el código de artículo sea el correcto] con sus cantidades, en caso necesario puede indicar observaciones y pulsando el botón de añadir línea o bien la botón de borrar línea va actualizando el albarán de traspaso.


Flujos alternativos: 1. Se presenta la pantalla y el usuario cancela pulsando salir 2. El usuario desconoce el código de artículo que recepciona y accede a la consulta de artículos





Caso de uso: 1.2.2.8 Traspaso de material



Descripción: El usuario envía genero

RELACIONES

Incluye: NA

Extiende: NA

Herencia: NA

CONDICIONES


Postcondiciones: El usuario genera el albarán de envío

FLUJOS

Flujo básico: 1. Se presenta la pantalla Albarán traspaso, el usuario pulsa el botón de nuevo y se genera un albarán de traspaso con los siguientes datos: número de albarán (correlativo), el usuario validado, la fecha del sistema y el origen del material

2. El usuario modifica el destino en caso de ser Operador del almacén central [Flujo alternativo: El usuario es operador de tienda y esta opción no está disponible]

3. Introduce artículos [Flujo alternativo: El usuario desconoce el código de artículo y pulsa el botón que accede a la consulta de artículos] [Flujo excepcional: El sistema no valida que el código de artículo sea el correcto] con sus cantidades, en caso necesario puede indicar observaciones y pulsando el botón de añadir línea o bien la botón de borrar línea va actualizando el albarán de traspaso.


Flujos alternativos: 1. Se presenta la pantalla y el usuario cancela pulsando salir 2. El usuario desconoce el código de artículo que recepciona y accede a la consulta de artículos

Flujos excepcionales: 1. El sistema no valida el código de artículo




Caso de uso: 1.2.2.9 Consulta de traspasos


Descripción: El usuario consulta el género que se ha enviado o recepcionado entre el almacén central y las diferentes tiendas

RELACIONES

Incluye: UseCase Consulta de solicitudes

Extiende: NA

Herencia: NA

CONDICIONES

Precondiciones: El albarán de traspaso existe en le sistema

Postcondiciones: Se genera un listado con los traspasos existentes

FLUJOS

Flujo básico: 1. Se presenta la pantalla Consulta de traspasos; en ella aparece: El campo de albarán a consultar, fecha, origen y destino [Flujo de excepción: El código de albarán no está dado de alta o bien la fecha es incorrecta]

2. El usuario modifica el origen o el destino

3. El usuario pulsa el botón de buscar y el sistema muestra la lista de albaranes de traspaso [Flujo alternativo: El operador accede a las solicitudes que generaron ese albarán]

Flujos alternativos: 1. Se presenta la pantalla y el usuario cancela pulsando salir 2. El usuario tras consultar los albaranes accede a las solicitudes que generaron ese albarán.

Flujos excepcionales: 1. El sistema no valida el código de albarán ni la fecha introducida




Caso de uso: 1.2.2.10 Consulta de traspasos de tienda


Descripción: El usuario consulta el género que se ha enviado o recepcionado entre el almacén central y la tienda a la que está destinado

RELACIONES

Incluye: • UseCase Consulta de solicitudes

Extiende: NA

Herencia: NA

CONDICIONES

Precondiciones: El albarán de traspaso existe en le sistema

Postcondiciones: Se genera un listado con los traspasos existentes

FLUJOS

Flujo básico: 1. Se presenta la pantalla Consulta de traspasos; en ella aparece: El campo de albarán a consultar, fecha, origen y destino [Flujo de excepción: El código de albarán no está dado de alta o bien la fecha es incorrecta]

2. El usuario modifica el origen o el destino

3. El usuario pulsa el botón de buscar y el sistema muestra la lista de albaranes de traspaso [Flujo alternativo: El operador accede a las solicitudes que generaron ese albarán]


2. El usuario tras consultar los albaranes accede a las solicitudes que generaron ese albarán.

Flujos excepcionales: 1. El sistema no valida el código de albarán ni la fecha introducida



1.2.2.11 UML Gestión de ventas




Caso de uso: 1.2.2.12 Salidas de ventas


Descripción: Se realiza la venta de género

RELACIONES


Extiende: NA

Herencia: NA

CONDICIONES


Postcondiciones: El usuario genera el albarán de venta

FLUJOS

Flujo básico: 1. Se presenta la pantalla Albarán de venta; el usuario pulsa el botón de nuevo y se genera un albarán de venta con los siguientes datos: número de albarán (correlativo), el usuario validado, la fecha del sistema y la tienda que realiza la venta.

2. Introduce artículos [Flujo alternativo: El usuario desconoce el código de artículo y pulsa el botón que accede a la consulta de artículos] [Flujo excepcional: El sistema no valida que el código de artículo sea el correcto] con sus cantidades y pulsando el botón de añadir línea o bien la botón de borrar línea y va actualizando el albarán de venta.


Flujos alternativos: 1. Se presenta la pantalla y el usuario cancela pulsando salir 2. El usuario desconoce el código de artículo que vende y accede a la consulta de artículos




1.2.2.13 UML Gestión de existencias




Caso de uso: 1.2.2.14 Gestión consulta stocks



Descripción: Se consulta la existencia de los artículos (stocks)

RELACIONES

Incluye: • UseCase Gestión Consulta stocks por tienda

• UseCase Consulta de artículo

Extiende: NA

Herencia: NA

CONDICIONES


Postcondiciones: El usuario genera una consulta de existencias del artículo

FLUJOS

Flujo básico: 1. Se presenta la pantalla Consulta de artículos; en ella se pueden consultar las existencias introduciendo: código de artículo[Flujo alternativo: El usuario desconoce el código de artículo y pulsa el botón que accede a la consulta de artículos][Flujo excepcional: El sistema no valida que el código de artículo sea el correcto], descripción del artículo, los atributos (marca, modelo, color y talla) y si tiene o ha tenido rotura de stock o no

2. El usuario introduce los campos por los q desea seleccionar y pulsa la botón buscar

3. Se le muestran por pantalla los artículos que cumplen los requisitos de búsqueda incluyendo una columna para acceder a la consulta de stocks por tienda[Flujo alternativo: el usuario accede a la consulta de stocks por tienda pulsando el botón que se muestra en pantalla]

4. El usuario tras consultar las existencias pulsa el botón Salir


2. El usuario desconoce el código de artículo que quiere consultar y accede a la consulta de artículos

3. Una vez mostradas las existencias por artículo el usuario accede a la consulta de artículos por tienda





Caso de uso: 1.2.2.15 Gestión Consulta stocks por tienda


Descripción: El usuario consulta el stock por tienda

RELACIONES

Incluye: • UseCase Consulta de movimientos de artículos por tienda

Extiende: NA

Herencia: NA

CONDICIONES


Postcondiciones: El usuario genera una consulta de existencias del artículo por tienda

FLUJOS

Flujo básico: 1. Se presenta la pantalla Consulta Stock Artículos/Tiendas; de la cual se accede desde la pantalla de consulta de artículos tras haber pulsado la celda correspondiente al artículo en cuestión.

2. Se presenta las existencias totales solicitadas, in itínere y en stock y las existencias del artículo por cada tienda en detalle informando de la distancia de la tienda, la cantidad de solicitadas, la cantidad que se encuentra in itínere y el stock, además se presenta un columna desde a la que se accede a la consulta de movimientos de stocks por tienda [Flujo alternativo: El usuario pulsa una celda que accede a la consulta de movimientos de stock por tienda]

4. El usuario tras consultar las existencias por tienda pulsa el botón Salir


2. Una vez mostradas las existencias por artículo el usuario accede a la consulta de movimientos de artículos por tienda

Flujos excepcionales: NA




Caso de uso: 1.2.2.16 Consulta de movimientos de artículos por tienda



Descripción: El usuario genera una consulta de existencias del artículo

RELACIONES

Incluye: NA

Extiende: NA

Herencia: NA

CONDICIONES


Postcondiciones: El usuario genera una consulta movimientos de existencias del artículo por tienda

FLUJOS

Flujo básico: 1. Se presenta la pantalla Consulta Stock Artículos/Tiendas Movimientos de la cual se accede desde la pantalla de consulta de artículos/Tiendas tras haber pulsado la celda correspondiente al artículo en cuestión.

2. Se presenta las existencias totales clasificadas en: solicitadas, in itínere y en stock

3. Se solicita la fecha desde la cual se va a realizar la consulta y pulsando buscar se muestra la información referente a solicitudes: solicitud, fecha de la solicitud, unidades solicitadas, albarán de traspaso, Fecha albarán de traspaso; y la información referente a los movimientos: días en servirse, unidades servidas, unidades pendientes y situación de la solicitud.

4. El usuario tras consultar las existencias por tienda pulsa el botón Salir


Flujos excepcionales: NA




A continuación se mostrará una aproximación de las pantallas de los distintos casos de usos del subsistema de control de Flujo.

1.2.3.1 Albarán de Compra

Pantalla de que permite entrar el género solicitado a un proveedor.



1.2.3.2 Albarán de Devolución

Pantalla que permite hacer devoluciones a un proveedor. Se dejará entrar unas observaciones para que el proveedor pueda identificar el motivo de la devolución



1.2.3.3 Solicitud de reposición de género

Pantalla que permite tanto entrar la solicitud de género por la tienda, como el cambio de estado de la solicitud por parte de la central. Se puede acceder a ella tanto por el menú, como por la consulta de solicitudes.



1.2.3.4 Albarán de reposición consulta

Pantalla de consulta de las situaciones de las solicitudes, permite saber el estado general de todas las solicitudes, se puede filtrar por albarán, fecha, la tienda que ha realizado la solicitud o la situación de esta.

Esta pantalla también permitirá acceder a la solicitud haciendo un doble click sobre la línea del grid, esto mostrará su detalle y además permitirá cambiar su situación.



1.2.3.5 Albarán de traspaso

Pantalla que permite realizar traspaso de género entre las tiendas y la central o entre la central y las tiendas.

El campo origen vendrá determinado por el lugar de trabajo de usuario que se ha identificado

En campo destino estará solo habilitado para la central, en el caso de la tienda este campo siempre contendrá como destino la central.



1.2.3.6 Consulta de traspasos

Pantalla de consulta de las situaciones de los traspasos, permite saber el estado general de todos los traspasos, se puede filtrar por albarán, fecha, la tienda que ha realizado el traspaso, el destino de este o la situación de este.

Esta pantalla también permitirá acceder a la traspaso haciendo un doble click sobre la línea del grid, esto mostrará su detalle y además permitirá cambiar su situación.



1.2.3.7 Albarán de Venta

Pantalla que permite informar al sistema de todas las ventas que se han producido en los TPV. Se recomienda al cliente que como posible mejora se realice en el sistema un nuevo caso de uso con el actor TPV que permita rebajar el stock vendido en línea.



1.2.3.8 Consulta de Artículos

Pantalla que permite consultar los artículos bajo una serie de filtros como el código la descripción, los atributos del artículo o si un artículo ha sufrido rotura de stock.

Esta pantalla informa del stock general de todos los almacenes, haciendo un doble click sobre uno de los artículos nos ofrecerá el detalle de la situación de ese stock general.



1.2.3.9 Consulta Stock Artículos/Tiendas

Pantalla que nos informa de un artículo determinado la situación del stock en cada una de las tiendas de la organización. El orden de salida tiene que ser por la distancia sobre la tienda que hace la consulta. A esta pantalla solo se puede acceder desde la consulta de artículos.



1.2.3.10 Consulta Stock Artículos/Tienda Movimientos

Pantalla que nos da información del detalle de solicitudes de reposición de un artículo y una tienda determinada, también nos da información sobre el desglose histórico del movimiento de un artículo. A esta pantalla se tiene que acceder desde la consulta de artículos / tiendas.

En esta primera pantalla se ofrece un ejemplo de la situación de las solicitudes de una tienda y un artículo.



En esta segunda pantalla vemos el desglose de todos los movimientos que se han producido del mismo artículo desde una fecha determinada entrada por el operador.



1.3 Subsistema de listados y estadísticas 1.3.1 Descripción

El subsistema de listados y estadísticas permite a los usuarios realizar consultas predeterminadas sobre productos y almacenes y obtener informes que de una manera visual y rápida.

Los informes se estructuran en dos tipos. Por un lado se presentan informes de estado general, que permiten conocer que almacenes han sufrido roturas de stock y sobre qué productos, con el fin de evitar que se repita en el futuro, así como cual es el tiempo medio en días de rotación de los productos dentro de cada almacén.

Por otra parte se podrán realizar informes estadísticos para conocer información sobre el servicio y analizar la eficacia del mismo. En concreto se podrá obtener información sobre cuáles son los productos más o menos solicitados y más o menos devueltos. De cada producto podremos conocer que puesto ocupa en la consulta o cuál es el porcentaje entre el total de productos.

Las estadísticas es una herramienta muy potente para analizar información y facilitar la toma de decisiones y la optimización de recursos, motivo por el cual está al alcance tanto de los operarios de tiendas como a los operarios del almacén central, si bien sólo estos últimos tienen visibilidad de todos los almacenes y son por tanto capaces de realizar consultas sobre toda la red de distribución.

1.3.2 Casos de uso

1.3.2.1 UML Listados y Estadísticas



Especificaciones de uso de Gestión de Usuarios


Caso de uso: 1.3.2.2 Rotación Stocks

Actores: • Operador Central, Operador de tienda

Descripción: Consultar qué tiempo transcurre desde que un producto entra en el almacén hasta que este es vendido.

RELACIONES

Incluye: Imprimir

Extiende: NA

Herencia: NA

CONDICIONES

Precondiciones: Existe al menos un almacén en el sistema con al menos un producto.

Postcondiciones: El usuario genera una consulta con el tiempo medio en días desde que un producto entra en el almacén hasta que es vendido.

FLUJOS

Flujo básico: 1. Usuario con rol operador central u operador de tienda entra en el sistema.

2. Usuario accede al menú Estadísticas->Rotación de stock.

3. Usuario accede a la pantalla de rotación de stocks.

4. El usuario selecciona el almacén sobre el que va a realizar la consulta dentro de un listado con todos los almacenes que puede visualizar y seleccionará uno de ellos. Los Operadores de Tienda solo tienen visibilidad de su propio almacén [FlujoAlternativo1].,

5. El selecciona el producto sobre el cual quiere conocer la rotación. [FlujoAlternativo1]

6. El usuario no modifica la fecha por defecto. [FlujoAlternativo2]7. Se tiene la opción de pulsar Aceptar para aceptar la operación o Cancelar para cancelar la misma.

8. Si se pulsa Aceptar se realizará la consulta y el resultado aparecerá por pantalla.

9. Pulsando la opción Imprimir, el resultado será enviado a la impresora por defecto del sistema.


1. El usuario Operador Central puede seleccionar la opción <Todas las Tiendas> para hacer la consulta sobre todos los almacenes de las tiendas sistema.

2. El usuario puede seleccionar la opción <Todos los Productos> para hacer la consulta sobre todos los productos del sistema.

3. El usuario modifica la fecha de inicio o fecha de fin. [FlujoExcepcional1]


1.- Fecha de finalización es inferior a fecha de inicio. Mensaje de error.




Caso de uso: 1.3.2.3 Rotura Stocks


Descripción: Consultar qué almacenes han sufrido rotura de stocks y sobre qué productos entre dos fechas determinadas

RELACIONES

Incluye: Imprimir

Extiende: NA

Herencia: NA

CONDICIONES


Postcondiciones: El usuario genera una consulta de almacenes que han sufrido rotura de stock entre dos fechas determinadas.

FLUJOS

Flujo básico: 1. Usuario con rol operador central u operador de tienda ha entrado al sistema.

2. Usuario accede al menú Estadísticas->Roturas de stock

3. Usuario accede a la pantalla de roturas de stocks donde inicialmente la fecha de fin será la fecha actual y la fecha de inicio será 30 días anterior.

4. El usuario selecciona el almacén sobre el que va a realizar la consulta dentro de un listado con todos los almacenes que puede visualizar y seleccionará uno de ellos. Los Operadores de Tienda solo tienen visibilidad de su propio almacén [FlujoAlternativo1]

5. El usuario no modifica la fecha por defecto. [FlujoAlternativo2]


7. Si se pulsa Aceptar se realizará la consulta y el resultado aparecerá por pantalla.



1. El usuario Operador Central puede seleccionar la opción <Todas las Tiendas> para hacer la consulta sobre todos los almacenes de las tiendas del sistema.

2. El usuario modifica la fecha de inicio o fecha de fin. [FlujoExcepcional1]






Caso de uso: 1.3.2.4 Estadística Productos


Descripción: Consultar qué productos son los más/menos solicitados/devueltos y devolver los resultados acompañado de la posición que ocupa o la frecuencia en que ocurre (ranking/porcentaje) entre dos fechas determinadas.

RELACIONES

Incluye: Imprimir

Extiende: NA

Herencia: NA

CONDICIONES


Postcondiciones: El usuario genera una consulta con la información deseada sobre los productos.

FLUJOS

Flujo básico: 1. Usuario con rol operador central u operador de tienda ha entrado al sistema. 2. Usuario accede al menú Estadísticas->Estadísticas de productos. 3. Usuario accede a la pantalla de estadísticas de productos donde inicialmente tendrá activada las casillas <Ranking>, <Más> y <Solicitado>, el número de productos a consultar que por defecto será de 10, la fecha de fin que por defecto será la fecha actual y la fecha de inicio que será 30 días anterior.

4. El usuario selecciona el almacén sobre el que va a realizar la consulta dentro de un listado con todos los almacenes que puede visualizar y seleccionará uno de ellos. Los Operadores de Tienda solo tienen visibilidad de su propio almacén [FlujoAlternativo1]

5. El usuario no modifica las opciones por defecto. [FlujoAlternativo2], [FlujoAlternativo3], [FlujoAlternativo4], [FlujoAlternativo5], [FlujoAlternativo6].


7. Si se pulsa Aceptar se realizará la consulta y el sistema devolverá el ranking con los 10 productos más solicitados por pantalla.



1. El usuario Operador Central puede seleccionar la opción <Todas las Tiendas> para hacer la consulta sobre todos los almacenes de las tiendas del sistema.

2. El usuario selecciona un número de productos sobre los que se devolverá la consulta distinto a 10. [FlujoExcepcional1].

3. El usuario modifica la fecha de inicio o fecha de fin. [FlujoExcepcional2].

4. El usuario selecciona la opción <Porcentaje> para incluir en la consulta información sobre el porcentaje de veces que los productos cumplen con las condiciones seleccionadas.



5. El usuario selecciona la opción <Menos> para hacer la consulta sobre los productos que menos veces cumplen la condición de solicitado/devuelto.

6. El usuario selecciona la opción <Devueltos> para hacer la consulta sobre los productos que más/menos veces cumplen la condición de devuelto.


1.-Número de productos inferior a 1. Mensaje de error.





Caso de uso: 1.3.2.5 Imprimir


Descripción: Envía a una impresora el resultado de una consulta

RELACIONES

Incluye: NA

Extiende: NA

Herencia: NA

CONDICIONES

Precondiciones: Qué exista un informe de consulta previo (puede no tener datos).

Postcondiciones: Se imprime el informe de consulta.

FLUJOS

Flujo básico: 1. Usuario con rol operador ha entrado al sistema. 2. Usuario ha realizado una consulta. 3. Usuario selecciona la opción de imprimir. 4. Los datos son enviados a la impresora.


NA


NA




A continuación se mostrará una aproximación de las pantallas de los distintos casos de usos del subsistema de mantenimiento.

1.3.3.1 Rotación de Stocks

Resultados (por operador de Tienda)



1.3.3.2 Rotura de Stocks

Resultados (por operador de Almacén central)



1.3.3.3 Estadísticas de Productos



Resultado de productos más solicitados por ranking (por operador de tienda)



Resultado de productos menos devueltos por porcentaje (por operador de Almacén Central)



1.4 Subsistema de conexión 1.4.1 Descripción

Es el subsistema que ejecuta cualquier usuario para acceder a la aplicación. Los usuarios se identificarán, y en función de su perfil el sistema les mostrará las opciones que pueden realizar en el sistema.

Existen tres perfiles de usuario:

• Administrador • Operador de central • Operador de tienda

Las operaciones que puede realizar en el sistema cada perfil son las siguientes:

OPERACIONES POR PERFIL

Administrador En el subsistema de mantenimiento:

• Gestión de almacenes

• Gestión de artículos

• Gestión de proveedores

• Gestión de usuarios

• Gestión de distancias

Operador de central En el subsistema de control de flujo:

• Consulta de solicitudes

• Recepción de material de proveedor

• Salida a proveedor

• Consulta de traspasos




• Gestión consulta stocks por tienda


En el subsistema de listados y estadísticas:

• Roturas de stock

• Rotación de stock

• Estadísticas de productos



Operador de tienda En el subsistema de control de flujo:

• Consulta de solicitudes

• Solicitud de reposición



• Consulta de traspasos de tienda



• Salida de ventas

En el subsistema de listados y estadísticas:

• Roturas de stock

• Rotación de stock

• Estadísticas de productos

Además de la funcionalidad de validación del usuario y ajustar el interfaz a los permisos que tiene su perfil, este subsistema permitirá al usuario cambiar su contraseña si lo desea.

1.4.2 Casos de uso

1.4.2.1 UML Subsistema de conexión




Caso de uso: 1.4.2.2 Acceso al sistema

Actores: Usuario

Descripción: Identificar a un usuario para que pueda utilizar el sistema

RELACIONES

Incluye: NA

Extiende: NA

Herencia: NA

CONDICIONES

Precondiciones: El usuario esta dado de alta en el sistema

Postcondiciones: El empleado accede al sistema con las operaciones que le permite realizar el sistema

FLUJOS

Flujo básico: 1. El sistema muestra la ventana de login al usuario

2. El usuario introduce su credenciales (nombre de usuario y clave) y pulsa aceptar

3. El sistema verifica que las credenciales existen y son correctas [Flujo Excepcional: el sistema no valida las credenciales del usuario]

4. El sistema comprueba el rol del usuario es de operador de central [Punto de extensión: Usuario operador central vía caso de uso Acceso al sistema operador central]

5. El sistema comprueba el rol del usuario es de operador tienda [Punto de extensión: Usuario operador tienda vía caso de uso Acceso al sistema operador tienda]

6. El sistema comprueba el rol del usuario es de Administrador [Punto de extensión: Usuario administrador vía caso de uso Acceso al sistema administrador]


1. El sistema muestra la ventana de login al usuario

2. El usuario solicita el cambio de contraseña [Punto de extensión: Usuario solicita cambio de contraseña vía caso de uso Cambio de contraseña]


1.- El sistema no valida las credenciales del usuario

2.- El sistema informa al usuario que los datos de las credenciales no son correctos

3.- Si es la tercera vez que se produce la circunstancia del punto 2 se produce una salida del sistema




Caso de uso: 1.4.2.3 Acceso al sistema administrador

Actores: Administrador

Descripción: Configura la pantalla principal mediante el menú de la aplicación para el perfil de administrador

RELACIONES

Incluye: NA

Extiende: Acceso al sistema

Herencia: NA

CONDICIONES

Precondiciones: El sistema ha validado las credenciales del usuario y ha identificado que tiene el rol de administrador

Postcondiciones: Se ha configurado en los menús de la aplicación que sólo estén habilitados los que dan acceso a las operaciones autorizadas para un administrador

FLUJOS

Flujo básico: 1. El sistema cierra la ventana de login

2. El sistema configura el menú de la ventana principal con aquellas operaciones para las que está autorizado el perfil de administrador

En el menú de mantenimiento:

Gestión de almacenes

Consulta

Alta

Modificación

Baja

Gestión de artículos

Consulta

Alta

Modificación

Baja

Gestión de proveedores

Consulta

Alta

Modificación



Baja

Gestión de usuarios

Consulta

Alta

Modificación

Baja

Gestión de distancias

3. El sistema deshabilita el resto de opciones del menú de la ventana principal

Flujos alternativos: NA


NA




Caso de uso: 1.4.2.4 Acceso al sistema operador central

Actores: Operador Central

Descripción: Configura la pantalla principal mediante el menú de la aplicación para el perfil de operador de central

RELACIONES

Incluye: NA


Herencia: NA

CONDICIONES

Precondiciones: El sistema ha validado las credenciales del usuario y ha identificado que tiene el rol de operador de central

Postcondiciones: Se ha configurado en los menús de la aplicación que sólo estén habilitados los que dan acceso a las operaciones autorizadas para un operador de central

FLUJOS

Flujo básico: 1. El sistema cierra la ventana de login 2. El sistema configura el menú de la ventana principal con aquellas operaciones para las que está autorizado el perfil de operador de central. En el menú de control de flujo: Consulta de solicitudes Recepción de material de proveedor Salida a proveedor Consulta de traspasos Recepción de material Traspaso de material Gestión consulta de stocks Gestión consulta stocks por tienda Consulta de movimientos de artículos por tienda En el menú de estadísticas: Roturas de stock Rotación de stock Estadísticas de productos 3. El sistema deshabilita el resto de opciones del menú de la ventana principal


NA




Caso de uso: 1.4.2.5 Acceso al sistema operador tienda

Actores: Operador Tienda

Descripción: Configura la pantalla principal mediante el menú de la aplicación para el perfil de operador de tienda

RELACIONES

Incluye: NA


Herencia: NA

CONDICIONES

Precondiciones: El sistema ha validado las credenciales del usuario y ha identificado que tiene el rol de operador de tienda

Postcondiciones: Se ha configurado en los menús de la aplicación que sólo estén habilitados los que dan acceso a las operaciones autorizadas para un operador de tienda

FLUJOS

Flujo básico: 1. El sistema cierra la ventana de login 2. El sistema configura el menú de la ventana principal con aquellas operaciones para las que está autorizado el perfil de operador de tienda. En el menú de control de flujo: Consulta de solicitudes Solicitud de reposición Recepción de material Traspaso de material Consulta de traspasos de tienda Gestión consulta de stocks Consulta de movimientos de artículos por tienda Salida de ventas

En el menú de estadísticas: Roturas de stock Rotación de stock Estadísticas de productos

3. El sistema deshabilita el resto de opciones del menú de la ventana principal

Flujos alternativos: NA


NA




Caso de uso: 1.4.2.6 Cambio de contraseña

Actores: Usuario

Descripción: Cambiar la contraseña del usuario

RELACIONES

Incluye: NA


Herencia: NA

CONDICIONES

Precondiciones: El usuario ha solicitado en el caso de uso de acceso al sistema el cambio de su contraseña

Postcondiciones: El sistema ha cambiado la contraseña del usuario solo si ha podido validar sus anteriores credenciales

FLUJOS

Flujo básico: 1. El sistema muestra la ventana de cambio de contraseña

2. El usuario proporciona sus credenciales (usuario y contraseña)

3. El usuario proporciona la nueva contraseña por duplicado

4. El sistema verifica que las credenciales existen y son correctas [Flujo Excepcional 1: el sistema no valida las credenciales del usuario]

5. El sistema verifica que las dos informaciones de la nueva contraseña [Flujo Excepcional 2: Nueva contraseña no introducida correctamente]

6. El sistema cambia en el sistema la contraseña del usuario

7. El sistema informa al usuario que se ha cambiado su contraseña

8. El sistema vuelve al caso de uso del acceso al sistema

Flujos alternativos: 1. El sistema muestra la ventana de cambio de contraseña

2. El usuario pulsa en cancelar

3. El sistema vuelve al caso de uso del acceso al sistema


Flujo Excepcional 1: el sistema no valida las credenciales del usuario 1.1. El sistema informa al usuario que las credenciales proporcionadas no son válidas

1.2. Si es la tercera vez que se produce este hecho se produce una salida del sistema

Flujo Excepcional 2: Nueva contraseña no introducida correctamente

2.1. El sistema informa al usuario de que la contraseña nueva proporcionada no es correcta




1.4.3.1 Login

1.4.3.2 Cambio de contraseña



1.4.3.3 Ventana principal: Usuario administrador

1.4.3.4 Ventana principal: Usuario operador de central



1.4.3.5 Ventana principal: Usuario operador de tienda

Documento de diseño eSportStock: Gestor de stocks

TRABAJO DE FIN DE CARRERA.

INGENIERÍA TÉCNICA DE INFORMÁTICA DE GESTIÓN

David Rodríguez Villar Consultor Salvador Campo Mazarico.

15 de abril de 2013

Documento de diseño. eSportStock: Gestor de stocks


"Un diseñador sabe que ha alcanzado la perfección, no cuando no queda nada que añadir, sino cuando no queda nada que quitar"

Antoine De Saint-Exupéry



Contenido 1 Diseño de subsistemas ______________________________________________ 6

1.1 Subsistema de mantenimiento ___________________________________________ 6

1.1.1 Descripción _______________________________________________________ 6

1.1.2 Funcionalidades ___________________________________________________ 7

1.1.2.1 Gestión de Usuarios ______________________________________________ 7

1.1.2.2 Gestión de Productos _____________________________________________ 8

1.1.2.3 Gestión de Proveedores __________________________________________ 10

1.1.2.4 Gestión de Tiendas ______________________________________________ 11

1.1.3 Diagrama de clases y jerarquías ______________________________________ 13

1.1.3.1 Diagrama de clases del subsistema _________________________________ 14

1.1.3.2 Gestores del subsistema _________________________________________ 15

1.1.3.3 Excepciones del subsistema _______________________________________ 15

1.1.3.4 Diagrama de Pantallas del subsistema ______________________________ 16

1.1.4 Diagramas de colaboración _________________________________________ 17

1.1.4.1 Alta de Usuario _________________________________________________ 17

1.1.4.2 Modificación Usuario ____________________________________________ 18

1.1.4.3 Baja de Usuario _________________________________________________ 19

1.1.5 Diseño interface gráfica del Usuario __________________________________ 20

1.1.5.1 Mantenimiento de Usuarios ______________________________________ 20

1.1.5.2 Mantenimiento de Productos _____________________________________ 22

1.1.5.3 Mantenimiento de Proveedores ___________________________________ 24

1.1.5.4 Mantenimiento de Tiendas _______________________________________ 26

1.2 Subsistema de control de flujo __________________________________________ 29

1.2.1 Descripción ______________________________________________________ 29

1.2.2 Funcionalidades __________________________________________________ 30

1.2.2.1 Gestión de solicitudes (Pedidos) ___________________________________ 30

1.2.2.2 Gestión de albaranes ____________________________________________ 31

1.2.2.3 Ventas de productos ____________________________________________ 33

1.2.2.4 Gestión de stocks (Existencias) ____________________________________ 33


1.2.3.1 Diagrama de clases del Subsistema Control __________________________ 37

1.2.3.2 Gestor del subsistema ___________________________________________ 38






1.2.4.1 Solicitud de productos ___________________________________________ 40

1.2.4.2 Traspaso de productos ___________________________________________ 41

1.2.4.3 Venta de productos _____________________________________________ 42

1.2.5 Diseño Interface gráfica del Usuario __________________________________ 43

1.2.5.1 Gestión de solicitudes (pedidos) ___________________________________ 43

1.2.5.2 Gestión de Albaranes ____________________________________________ 46

1.2.5.3 Gestión de Ventas ______________________________________________ 52

1.2.5.4 Gestión de Stock ________________________________________________ 53

1.2.5.5 Pantallas información ____________________________________________ 56

1.3 Subsistema de listados y estadísticas _____________________________________ 57

1.3.1 Descripción ______________________________________________________ 57


1.3.2.1 Rotación de stock _______________________________________________ 58

1.3.2.2 Roturas de stock ________________________________________________ 58

1.3.2.3 Estadísticas de productos_________________________________________ 59

1.3.2.4 Imprimir ______________________________________________________ 59








1.3.4.2 Rotura de Stcks _________________________________________________ 63

1.3.4.3 Estadística de productos _________________________________________ 63



1.3.5.2 Rotura de Stocks ________________________________________________ 65

1.3.5.3 Estadística de Productos _________________________________________ 66

1.4 Subsistema de conexión _______________________________________________ 69

1.4.1 Descripción ______________________________________________________ 69



1.4.2.2 Selección de almacén ____________________________________________ 70

















1.4.5.4 Menús de usuario _______________________________________________ 79

2 Diseño de la persistencia ___________________________________________ 83

2.1 Diagrama de la base de datos ___________________________________________ 84

2.2 Script de la base de datos ______________________________________________ 89



1 Diseño de subsistemas

1.1 Subsistema de mantenimiento 1.1.1 Descripción

El subsistema de mantenimientos es el encargado de mantener los datos básicos de la empresa. Mediante una serie de CRUDS se encargará de dar de alta, modificar, consultar o dar de baja las diferentes entidades del sistema.

Por seguridad y para mantener la integridad de los datos, las bajas se contemplarán como bajas lógicas.

Las principales funcionalidades de este subsistema son:

• Mantenimiento de usuarios o Alta de nuevos usuarios o Bajas lógicas de usuarios o Consulta/Modificación de los datos de los usuarios

• Mantenimiento de productos o Alta de nuevos productos o Bajas lógicas de productos o Consulta/Modificación de los datos de los productos

• Mantenimiento de proveedores o Alta de nuevos proveedores o Bajas lógicas de proveedores o Consulta/modificación de los datos de los proveedores

• Mantenimiento de tiendas o Alta de nuevas tiendas o Bajas lógicas de tiendas o Consulta/modificación de los datos de las tiendas o Asignación de distancias entre tiendas

Todas estas funcionalidades, están asignadas a aquellos usuarios que una vez identificados en el sistema, dispongan privilegios del rol administrador.

Al cliente se le tiene que facilitar un usuario inicial con rol de administrador que le peRMIta entrar por primera vez al subsistema, una vez identificado uno de sus primeros trabajos será dar de alta todos los usuarios que utilizarán la aplicación y asignarles a estos sus respectivos roles.

La aplicación contemplará tres tipos de usuarios con perfiles diferentes.

• Administradores o Encargado de mantener las entidades del sistema

• Operadores de la tienda o Consultar el material y el stock de las diferentes tiendas o Pedir material a la central o Recepcionar el material recibido por la central o Consultar estadísticas de su tienda o Rechazar el material servido por la central

• Operador de la Central o Consultar el material y el stock de la diferentes tiendas así como su trazabilidad o Recepcionar material servido por el proveedor o Expedir albaranes de reposición a las tiendas



o Consulta de todas las estadísticas del sistema o Rechazar el material recibido de los proveedores.

1.1.2 Funcionalidades

1.1.2.1 Gestión de Usuarios

1.1.2.1.1 Alta de usuarios

Mediante esta opción el administrador del sistema dará de alta los usuarios que interactuarán con la aplicación.

Está opción estará asignada al menú Mantenimientos opción del menú Usuarios sub-opción Alta de usuarios.

El sistema presentará una consulta inicial donde el usuario podrá establecer una serie de filtros que le permitirán localizar y verificar que el usuario que quiere dar de alta no existe en el sistema. En esta consulta el operador podrá también filtrar si quieren que aparezcan los usuarios dados de baja, solo aquellos que están activos o todos.

El sistema solicitará una serie de datos básicos que identificarán al usuario de forma única dentro de la aplicación. Una vez introducidos los datos por el administrador, el subsistema se encargará de verificar la congruencia de estos datos, avisar al usuario en caso de que alguno de los datos no cumpla las siguientes especificaciones.

• El código del usuario no tiene que existir en el sistema • El NIF tiene que ser correcto y no puede pertenecer a otro usuario • La fecha de nacimiento tiene que ser válida e inferior a la fecha actual. • Se tiene le tiene que asignar uno de los tres roles al usuario (Administrador, Operador

de la central o Operador de tienda) • Se tiene que informar del sexo del usuario. • Tiene que ser asignado a una tienda • Todos los campos exceptuando el teléfono móvil con campos obligatorios y no se

pueden dejar en blanco.

Una vez que los datos pasan el control de verificación el sistema dará de dar de alta el nuevo usuario en la base de datos, grabando también la fecha de alta en la que se ha realizado la operación. A su vez informará al gestor de log que usuario y en qué fecha y hora ha realizado la transacción.

1.1.2.1.2 Bajas de usuarios

Mediante esta opción el administrador podrá dar de baja (baja lógica) los usuarios que ya no pueden trabajar en el sistema.

Está opción estará asignada al menú Mantenimientos opción del menú Usuarios sub-opción baja de usuarios.

El sistema presentará una consulta inicial donde el usuario podrá establecer una serie de filtros que le permitirán localizar el usuario que quiere dar de baja. En esta consulta el administrador podrá también filtrar si quieren que aparezcan los usuarios dados de baja, solo aquellos que están activos o todos

Una vez localizado y seleccionado por el operador, se mostrarán los datos detallados del usuario y se solicitará la confirmación de la baja. En caso de seleccionar un usuario que ya está dado de baja el sistema solo mostrará los datos y avisará al operador.



Si el administrador confirma la baja, se grabará la fecha de baja en el registro del usuario y se informará al gestor de log que administrador y en qué fecha y hora ha realizado la transacción.

No se podrá dar de baja el propio usuario que está realizando la transacción.

1.1.2.1.3 Modificación consulta de usuarios

Esta opción permitirá al administrador modificar los datos de la ficha de un usuario.

Está opción estará asignada al menú Mantenimientos opción del menú Usuarios sub-opción Consulta/Modificación de usuarios.

El sistema presentará una consulta inicial donde el usuario podrá establecer una serie de filtros que le permitirán localizar el usuario que quiere modificar. En esta consulta al igual que en las consultas anteriores el administrador podrá filtrar los usuarios por la situación lógica de estos.

Una vez localizado y seleccionado se mostrarán los datos, en el caso de ser un usuario dado de baja se preguntará al administrador si lo quiere recuperar antes de pasar a la edición de la modificación.

El sistema hará la misma verificación que en el alta de usuario para verificar la congruencia de los datos.

• El NIF tiene que ser correcto y no puede pertenecer a otro usuario • La fecha de nacimiento tiene que ser válida e inferior a la fecha actual. • Se tiene le tiene que asignar uno de los tres roles al usuario (Administrador, Operador

de la central o Operador de tienda) • Se tiene que informar del sexo del usuario. • Tiene que ser asignado a una tienda • Todos los campos exceptuando el teléfono móvil con campos obligatorios y no se

pueden dejar en blanco.

1.1.2.2 Gestión de Productos

1.1.2.2.1 Alta de Productos

Opción que permite al administrador del sistema dar de alta los artículos dentro del catalogo de las tiendas.

Está opción estará asignada al menú Mantenimientos opción del menú Productos sub-opción Alta de productos.

El sistema presentará una consulta inicial donde el usuario podrá establecer una serie de filtros que le permitirán localizar y verificar que el artículo que quiere dar de alta no existe en el sistema. En esta consulta el operador podrá también filtrar si quieren que aparezcan los productos dados de baja, solo aquellos que pertenecen al catálogo actual o ambos.

El sistema solicitará una serie de datos básicos que identificarán al artículo de forma única dentro de la aplicación. Una vez introducidos los datos, el subsistema se encargará de verificar la congruencia de estos datos, avisar al usuario en caso de que alguno de los datos no cumpla las siguientes especificaciones.

• El código del producto no tiene que existir en el sistema • El Nombre del producto no puede quedar en blanco

Una vez que los datos pasan el control de verificación el sistema dará de dar de alta el nuevo artículo en la base de datos, grabando también la fecha de alta en la que se ha realizado la



operación. A su vez informará al gestor de log que usuario y en qué fecha y hora ha realizado la transacción.

1.1.2.2.2 Bajas de productos

Mediante esta opción el administrador podrá dar de baja (baja lógica) los artículos que han quedado descatalogados y que ya no pueden no pueden trabajar en el sistema, es importante que el stock actual de este artículo sea igual a cero en los diferentes almacenes del sistema.

Está opción estará asignada al menú Mantenimientos opción del menú Productos sub-opción baja de productos.

El sistema presentará una consulta inicial donde el usuario podrá establecer una serie de filtros que le permitirán localizar el producto que quiere dar de baja. En esta consulta el administrador podrá también filtrar si quieren que aparezcan los productos dados de baja o solo aquellos que están activos.

Una vez localizado se mostrarán los datos detallados del producto y se solicitará confirmación. En caso de seleccionar un producto que ya está dado de baja el sistema solo mostrará los datos y avisará al operador.

El sistema verificará que el stock del producto sea cero en todos los almacenes de la aplicación, en caso que existiera stock informará al usuario y cancelará la operación. Si no hay stock solicitará la confirmación de la baja.

Si el administrador confirma la baja, se grabará la fecha de baja en el registro del producto y se informará al gestor de log que administrador y en qué fecha y hora ha realizado la transacción.

1.1.2.2.3 Modificación consulta de productos

Esta opción permitirá al administrador modificar los datos de la ficha de un producto.

Está opción estará asignada al menú Mantenimientos opción del menú Productos sub-opción Consulta/Modificación de usuarios.

El sistema presentará una consulta inicial donde el usuario podrá establecer una serie de filtros que le permitirán localizar al producto que quiere modificar. En esta consulta al igual que en las consultas anteriores el administrador podrá filtrar los productos por la situación lógica de estos.

Una vez localizado y seleccionado se mostrarán sus datos, en el caso de ser un producto dado de baja se preguntará al administrador si lo quiere recuperar antes de pasar a la edición de la modificación.

El sistema hará la misma verificación que en el alta de productos para verificar la congruencia de los datos.

• El Nombre del producto no puede quedar en blanco



1.1.2.3 Gestión de Proveedores

1.1.2.3.1 Alta de Proveedores

Opción que permite al administrador del sistema dar de alta los proveedores con los que trabajará el aplicativo.

Está opción estará asignada al menú Mantenimientos opción del menú Proveedores sub-opción Alta de proveedores.

El sistema presentará una consulta inicial donde el usuario podrá establecer una serie de filtros que le permitirán localizar y verificar que el proveedor que quiere dar de alta no existe en el sistema. En esta consulta el operador podrá también filtrar si quieren que aparezcan los proveedores dados de baja, los activos o todos.

El sistema solicitará una serie de datos básicos que identificarán al proveedor de forma única dentro de la aplicación. Una vez introducidos los datos, el subsistema se encargará de verificar la congruencia de estos datos, avisar al usuario en caso de que alguno de los datos no cumpla las siguientes especificaciones.

• El código del proveedor no tiene que existir en el sistema • El CIF tiene que ser correcto y no puede pertenecer a otro usuario • Todos los campos son obligatorios y no se pueden dejar en blanco.

Una vez que los datos pasan el control de verificación el sistema dará de dar de alta el nuevo proveedor en la base de datos, grabando también la fecha de alta en la que se ha realizado la operación. A su vez informará al gestor de log que usuario y en qué fecha y hora ha realizado la transacción.

1.1.2.3.2 Bajas de proveedores

Mediante esta opción el administrador podrá dar de baja (baja lógica) los proveedores a los que se ha dejado de comprar y por tanto no se podrán hacer albaranes de entrada de este proveedor.

Está opción estará asignada al menú Mantenimientos opción del menú Proveedores sub-opción baja de proveedores.

El sistema presentará una consulta inicial donde el usuario podrá establecer una serie de filtros que le permitirán localizar el proveedor que quiere dar de baja. En esta consulta el administrador podrá también filtrar si quieren que aparezcan los proveedores dados de baja, solo aquellos que están activos o todos.

Una vez localizado se mostrarán los datos detallados del proveedor y se solicitará confirmación. En caso de seleccionar un proveedor que ya está dado de baja el sistema solo mostrará los datos y avisará al operador.

Si el administrador confirma la baja, se grabará la fecha de baja en el registro del proveedor y se informará al gestor de log que administrador y en qué fecha y hora ha realizado la transacción.



1.1.2.3.3 Modificación consulta de proveedores

Esta opción permitirá al administrador modificar los datos de la ficha de un proveedor.

Está opción estará asignada al menú Mantenimientos opción del menú Proveedores sub-opción Consulta/Modificación de proveedores.

El sistema presentará una consulta inicial donde el usuario podrá establecer una serie de filtros que le permitirán localizar al proveedor que quiere modificar. En esta consulta al igual que en las consultas anteriores el administrador podrá filtrar los proveedores por la situación lógica de estos.

Una vez localizado y seleccionado se mostrarán sus datos, en el caso de ser un proveedor dado de baja se preguntará al administrador si lo quiere recuperar antes de pasar a la edición de la modificación.

El sistema hará la misma verificación que en el alta de proveedores para verificar la congruencia de los datos.

• El CIF tiene que ser correcto y no puede pertenecer a otro usuario • Todos los campos son obligatorios y no se pueden dejar en blanco.

1.1.2.4 Gestión de Tiendas

1.1.2.4.1 Alta de Tiendas

Opción que permite al administrador del sistema dar de alta las tiendas con los que trabajará el aplicativo.

Está opción estará asignada al menú Mantenimientos opción del menú Tiendas sub-opción Alta de tiendas.

El sistema presentará una consulta inicial donde el usuario podrá establecer una serie de filtros que le permitirán localizar y verificar que la tienda que quiere dar de alta no existe en el sistema. En esta consulta el operador podrá también filtrar si quieren que aparezcan las tiendas dados de baja, las activas o todas.

El sistema solicitará una serie de datos básicos que identificarán a la tienda de forma única dentro de la aplicación. Una vez introducidos los datos, el subsistema se encargará de verificar la congruencia de estos datos, avisar al usuario en caso de que alguno de los datos no cumpla las siguientes especificaciones.

• El código del tienda no tiene que existir en el sistema • Todos los campos son obligatorios y no se pueden dejar en blanco.

Una vez que los datos pasan el control de verificación el sistema dará de dar de alta la nueva tienda en la base de datos, grabando también la fecha de alta en la que se ha realizado la operación. A su vez informará al gestor de log que usuario y en qué fecha y hora ha realizado la transacción.



1.1.2.4.2 Bajas de tiendas

Mediante esta opción el administrador podrá dar de baja (baja lógica) las tiendas.

Está opción estará asignada al menú Mantenimientos opción del menú Tiendas sub-opción baja de tiendas.

El sistema presentará una consulta inicial donde el usuario podrá establecer una serie de filtros que le permitirán localizar la tienda que quiere dar de baja. En esta consulta el administrador podrá también filtrar si quieren que aparezcan las tiendas dadas de baja, solo aquellas que están activas o todas.

Una vez localizado se mostrarán los datos detallados de la tienda y se solicitará confirmación. En caso de seleccionar una tienda que ya está dada de baja el sistema solo mostrará los datos y avisará al operador.

Si el administrador confirma la baja, se grabará la fecha de baja en el registro de la tienda y se informará al gestor de log que administrador y en qué fecha y hora ha realizado la transacción.

1.1.2.4.3 Modificación consulta de tiendas

Esta opción permitirá al administrador modificar los datos de la ficha de una tienda.

Está opción estará asignada al menú Mantenimientos opción del menú Tiendas sub-opción Consulta/Modificación de tiendas.

El sistema presentará una consulta inicial donde el usuario podrá establecer una serie de filtros que le permitirán localizar a la tienda que quiere modificar. En esta consulta al igual que en las consultas anteriores el administrador podrá filtrar las tiendas por la situación lógica de estas.

Una vez localizada y seleccionada se mostrarán sus datos, en el caso de ser una tienda dada de baja se preguntará al administrador si lo quiere recuperar antes de pasar a la edición de la modificación.

El sistema hará la misma verificación que en el alta de tiendas para verificar la congruencia de los datos.

• Todos los campos son obligatorios y no se pueden dejar en blanco.

1.1.2.4.4 Asignación de distancias entre tiendas

Esta opción permitirá al administrador especificar las distancias entre las diferentes tiendas.

Está opción estará asignada al menú Mantenimientos opción del menú Tiendas sub-opción Consulta/Asignación de distancias.

El sistema presentará una consulta inicial donde el usuario podrá establecer una serie de filtros que le permitirán localizar a la tienda que quiere modificar. En esta consulta al igual que en las consultas anteriores el administrador podrá filtrar las tiendas por la situación lógica de estas.

Una vez localizada y seleccionada se mostrarán las distancias asignadas entre la tienda seleccionada y el resto de tiendas, dejando que el usuario pueda especificar las diferentes distancias.



1.1.3 Diagrama de clases y jerarquías



1.1.3.1 Diagrama de clases del subsistema



1.1.3.2 Gestores del subsistema

1.1.3.3 Excepciones del subsistema



1.1.3.4 Diagrama de Pantallas del subsistema



1.1.4 Diagramas de colaboración

1.1.4.1 Alta de Usuario



1.1.4.2 Modificación Usuario



1.1.4.3 Baja de Usuario



1.1.5 Diseño interface gráfica del Usuario

1.1.5.1 Mantenimiento de Usuarios

Se propone una mejora en la organización de los campos, intentando que las altas, bajas y modificaciones estén concentradas en una sola pantalla. (Estas podrían ser llamadas desde una única opción del menú o bien como en la propuesta inicial ser llamadas desde diferentes opciones de menú ocultando los botones que no tienen que operar).



1.1.5.2 Mantenimiento de Productos

Se sigue el mismo criterio que en la pantalla anterior, intentando que las altas, bajas y modificaciones estén concentradas en una sola pantalla. (Estas podrían ser llamadas desde una única opción del menú o bien como en la propuesta inicial ser llamadas desde diferentes opciones de menú ocultando los botones que no tienen que operar).



1.1.5.3 Mantenimiento de Proveedores

Se sigue el mismo criterio que en las pantallas anteriores, intentando que las altas, bajas y modificaciones estén concentradas en una sola pantalla. (Estas podrían ser llamadas desde una única opción del menú o bien como en la propuesta inicial ser llamadas desde diferentes opciones de menú ocultando los botones que no tienen que operar).



1.1.5.4 Mantenimiento de Tiendas

Se sigue el mismo criterio que en las pantallas anteriores, intentando que las altas, bajas y modificaciones estén concentradas en una sola pantalla. (Estas podrían ser llamadas desde una única opción del menú o bien como en la propuesta inicial ser llamadas desde diferentes opciones de menú ocultando los botones que no tienen que operar).

Se realiza una modificación de la especificación inicial, para poder asignar las distancias entre las diferentes tiendas. Este dato será necesario para la consultas que realizan las tiendas que permite saber dónde está el stock cuando se produce una ruptura y poder guiar al cliente a la tienda más cercana.



1.2 Subsistema de control de flujo 1.2.1 Descripción

Este subsistema forma parte de la aplicación eSportStok definiéndose como el subsistema encargado de controlar los movimientos de mercaderías entre los diferentes almacenes (central y tiendas) y a su vez, llevar un control exhaustivo de todos estos movimientos. Dentro del ámbito de este subsistema se incluye también el conocer el stock de todos los almacenes y su rotación, lo que influirá en la distribución de los productos realizada por el almacén central. A continuación se muestra una breve descripción de las funcionalidades del subsistema. El acceso a las funcionalidades de este subsistema será permitido para dos roles distintos de usuarios:

• Operador de tienda: Acceso a todas las gestiones pertenecientes a su tienda y a la consultas de stocks.

• Operador de la central: Acceso a todas las consultas tanto de almacén central como de tiendas y gestión del almacén central.

Las principales funcionalidades de este subsistema son:

• Gestión de pedidos (solicitudes)

o Solicitud. Tienda/Central o Consulta/Baja/Modificación Solicitud Tienda o Consulta Solicitudes Central

• Gestión de albaranes

o Recepción de material. Tienda o Traspaso de material. o Consulta de traspasos. Central o Consulta de traspasos tienda. Tienda o Recepción material proveedor. Central o Salida a proveedor. Central o Salida de ventas

• Gestión de stock

o Alta de stock o Gestión consulta stock

Consulta stock por tienda Consulta de movimientos de artículos por tienda

o Distribución Stock




1.2.2.1 Gestión de solicitudes (Pedidos)

1.2.2.1.1 Solicitud (Pedido)

Descripción: Mediante esta opción el operador de tienda podrá realizar el Alta de una nueva solicitud.

Está opción estará asignada al menú Control de Flujo opción del menú Tienda sub-opción Alta Pedidos.

El sistema presentará una pantalla inicial donde existirán una serie de campos de rellenado automático como son: id_solicitud, Usuario (operador de tienda que realiza la operación, logeado previamente), Fecha de generación de la petición, Solicitado por: (Tienda origen).

Posteriormente se irán indicando los artículos y cantidad a solicitar y se irán añadiendo a la petición por líneas.

Una vez comprobado por el sistema que los datos son correctos, se podrá generar el pedido.

Una vez llegada la solicitud a la Central, se cambiará la situación al estado pertinente: (Sin cursar/En Estudio/Aceptada/Rechazada).

1.2.2.1.2 Consulta/Baja/Modificación Solicitudes (Tienda)

Descripción: Mediante esta opción el operador de tienda podrá realizar la Consulta, Modificación y Anulación de un pedido.

Está opción estará asignada al menú Control de Flujo opción del menú Tienda sub-opción Consulta Solicitudes.

El sistema presentará una consulta inicial donde el operador podrá utilizar una serie de filtros como son el ID del Albarán y fecha de emisión del mismo.

Para verificar que la búsqueda es válida, se comprobará que:

ID del Albarán correcto.

Fecha en el formato correcto.

Una vez aparecido el resultado, el operador de tienda podrá modificar o borrar la solicitud siempre que no haya pasado al estado en proceso en almacén.

1.2.2.1.3 Consulta Solicitudes (Central)

Descripción: Mediante esta opción el operador de la central podrá realizar la Consulta, del estado de todos los pedidos de las tiendas.

Está opción estará asignada al menú Control de Flujo opción del menú Central sub-opción Consulta Solicitudes.

El sistema presentará una consulta inicial donde el operador de la central podrá utilizar una serie de filtros como son el ID del Albarán, fecha de emisión del mismo, tienda que ha realizado el pedido y su situación para poder seleccionar los pedidos que se requieran.

Una vez seleccionados, el operador de la central únicamente podrá cambiar el estado del pedido.



1.2.2.2 Gestión de albaranes

El gestor de albaranes será el encargado de gestionar los distintos traspasos que se realizan entre las tiendas.

1.2.2.2.1 Recepción de albarán

Descripción: Mediante opción se podrá:

• El operador central podrá recepcionar el material devuelto por parte de las tiendas.

En este submenú aparecerá el menú consulta al cual se le podrá aplicar una serie de filtros para poder hallar el Albarán a recepcionar. Una vez seleccionado por el operador central, se le cambiará la situación a Aceptado, modificando el stock con el material entrante.

Está opción estará asignada al menú Control de Flujo opción del menú Central sub-opción Recepción del albarán.

• El operador de tienda podrá recepcionar el material enviado por la central.

En este submenú aparecerá el menú consulta al cual se le podrá aplicar una serie de filtros para poder hallar el Albarán a recepcionar. Una vez aceptado por el operador de tienda, se le cambiará la situación a Aceptado, modificando el stock con el material entrante.

En la pantalla de consulta aparecerá desactivado los filtros de origen y destino.

Está opción estará asignada al menú Control de Flujo opción del menú Tienda sub-opción Recepción del albarán.

En la pantalla del Albarán a recepcionar, aparecerán todos los campos sombreados, excepto el de Situación y los de Aceptar, Cancelar.



1.2.2.2.2 Envío de albarán.

En este punto hemos diferenciado lo que es una devolución a proveedor (4.4.2.7), que sólo se podrá realizar desde el almacén central y lo que es un traspaso entre almacenes, incluyendo en el mismo la devolución de una tienda al almacén central.

Descripción: Mediante esta opción se podrá:

• El operador central podrá realizar el envío de material a las tiendas.

Está opción estará asignada al menú Control de Flujo opción del menú Central sub-opción Envío albarán.

• El operador de tienda podrá realizar el traspaso de material desde su tienda al almacén central, realizando la devolución del mismo. En este caso, en la pantalla de Envío, aparecerá deshabilitado del menú Origen y Destino.

Está opción estará asignada al menú Control de Flujo opción del menú Tienda sub-opción Envío albarán.

1.2.2.2.3 Consulta de albaranes

Descripción: Con esta opción se permite consultar los diferentes movimientos existentes en las tiendas.

• Mediante esta opción el operador central podrá consultar el género que se ha enviado o recepcionado entre el almacén central y las diferentes tiendas

Está opción estará asignada al menú Control de Flujo opción del menú Central sub-opción Consulta de traspasos.

• Mediante esta opción el operador de tienda podrá consultar el género que se ha enviado o recepcionado entre su tienda y el almacén central.

En la pantalla de esta consulta no se podrá variar ni Origen ni Destino de la mercancía.

Está opción estará asignada al menú Control de Flujo opción del menú Tienda sub-opción Consulta de traspasos.

1.2.2.2.4 Recepción material proveedor. Central

Descripción: Mediante esta opción el operador central podrá proceder a la recepción del material del proveedor.

Está opción estará asignada al menú Control de Flujo opción del menú Central sub-opción Recepción proveedor.

1.2.2.2.5 Devolución proveedor. Central

Descripción: Mediante esta opción el operador central podrá devolver el género defectuoso al proveedor.



Está opción estará asignada al menú Control de Flujo opción del menú Central sub-opción Devolución Proveedor.

1.2.2.3 Ventas de productos

Descripción: Se realiza la venta de género permitiendo a los usuarios de tienda actualizar el estado de los productos del stock vendidos, manteniendo así el número total de unidades en stock. Se generará un albarán de venta, el cual, una vez salido de la tienda, redundará en una disminución del stock en la misma.

Está opción estará asignada al menú Control de Flujo opción del menú Tienda sub-opción Ventas.

1.2.2.4 Gestión de stocks (Existencias)

1.2.2.4.1 Alta stock

El alta de productos en el stock se podrá producir de distintas formas.

En la central:

• Mediante la adquisición de productos al proveedor. Se generará un albarán de compra el cual, al ser aceptado, automáticamente generará el alta en el stock de los artículos entrantes.

• Por la devolución de productos de las tiendas. La tienda habrá generado un albarán de traspaso de devolución. Una vez llegada la mercancía al almacén central, se cambiará la situación del itínere a aceptado, lo que provocará la actualización del stock del almacén central.

En las tiendas:

• Se producirá un alta en el stock al recibir un traspaso por parte del almacén central. Una vez recibido el albarán de traspaso, el operador de tienda cambiará la situación de itínere a Aceptado lo que, automáticamente, provocará la actualización del stock de la tienda.

1.2.2.4.2 Consulta stock

Descripción: Se realiza la consulta de la existencia de artículos. Desde esta pantalla se podrá realizar la trazabilidad completa de cualquier artículo.

Está opción estará asignada al menú Control de Flujo opción del menú Tienda o Central sub-opción Stocks.

Se presenta la pantalla Consulta de artículos; en ella se pueden consultar las existencias bajo una serie de filtros como el código, la descripción, los atributos del artículo o si un artículo ha sufrido rotura de stock.

Una vez seleccionado el artículo, se tendrá la opción de pinchar sobre él para acceder en detalle a su situación actual en las diferentes tiendas, pudiendo comprobar su disponibilidad, lo cual servirá en caso de rotura de stock en una tienda para poder redirigir a la más próxima que tengan el mismo artículo. Esta segunda pantalla se denomina Consulta ArtículosTienda.



Llegados a esta pantalla y si lo que se quiere es obtener el detalle de los movimientos de un determinado producto en una determinada tienda, se tendrá la opción de pinchar en alguna de las tiendas, mostrándose otra pantalla, denominada Consulta MovimientosStock donde se tendrá acceso a todas las reposiciones y movimientos que ha tenido el producto en la tienda pudiéndose filtrar a partir de una fecha.

1.2.2.4.3 Distribución stock

La distribución del stock por parte del almacén central se gestionará mediante los albaranes de traspasos generados por los operadores de tienda, que una vez llegados al almacén central, será el operador del mismo el gestionará la mercancía de salida. Si el operador del almacén central, por cualquier motivo, quiere priorizar el envío de material a las tiendas, tendrá la posibilidad, mediante la consulta de stock, de realizar un seguimiento pormenorizado de cualquier producto de las tiendas, realizando la consulta pertinente comentada en el punto 4.2.2.4.2 Consulta stock. Como en el punto 4.2.2.4.1 Alta stock, la actualización de la distribución del stock, una vez se haya realizado la priorización mediante la consulta de stock, se hará mediante el traspaso de mercancía a tienda (traspaso de albarán) o devolución a proveedor.




Diagrama clases gestoras, entidad y frontera Solicitudes

Diagrama clases gestoras, entidad y frontera Ventas



Diagrama clases gestoras, entidad y frontera Albarán

Diagrama clases gestoras, entidad y frontera Stock



1.2.3.1 Diagrama de clases del Subsistema Control



1.2.3.2 Gestor del subsistema





1.2.4.1 Solicitud de productos



1.2.4.2 Traspaso de productos



1.2.4.3 Venta de productos



1.2.5 Diseño Interface gráfica del Usuario

1.2.5.1 Gestión de solicitudes (pedidos)

Alta Solicitud



Consulta solicitudes tienda.

Se han añadido los botones Modificar, Borrar para la consulta de solicitudes del operador de tienda. Se ha cambiado la ubicación del botón buscar.



Consulta solicitudes central

En la consulta de solicitudes por parte de la central, sólo aparecerán activos los botones de Modificar y Salir y sólo se podrá modificar la situación de la solicitud. Se ha cambiado la ubicación del botón buscar.



1.2.5.2 Gestión de Albaranes

Albarán de traspaso (envío)



Albarán de traspaso (recepción)

Se han eliminado los botones de añadir o eliminar líneas, así como el botón cantidad.



Consulta albaranes

Consulta traspasos Tienda



Consulta traspasos Central



Devolución a proveedor



Recepción material proveedor



1.2.5.3 Gestión de Ventas



1.2.5.4 Gestión de Stock

Consulta Stock



1.2.5.5 Pantallas información

A continuación se muestran una serie de pantallas estándar de error, información de operación correcta y confirmación de la operación realizada.

Pantalla de error

Pantalla de información de operación correcta

Pantalla de confirmación



1.3 Subsistema de listados y estadísticas 1.3.1 Descripción

Mediante este subsistema generaremos los informes estadísticos de la actividad de los almacenes tanto central como el de las diferentes tiendas, con el objetivo de comprobar la eficacia del servicio, estos informes que serán utilizados por el operador del almacén central, como por los operadores de tienda para la toma de decisiones y así obtener el máximo rendimiento de los recursos de los que disponen. Los informes estadísticos se tendrán que parametrizar por producto, obteniendo cuales son los más o menos solicitados y/o más o menos devueltos, además de cada producto podremos conocer que puesto ocupa en la consulta o cuál es el porcentaje entre el total de los productos. Las principales funcionalidades de este subsistema son:

• Estadísticas de Stocks

o Rotación de stocks o Roturas stocks

• Estadísticas de producto

o Estadísticas productos

• Impresión de estadísticas

o Imprimir

La aplicación contemplará tres tipos de usuarios con perfiles diferentes.

• Administradores o Encargado de mantener las entidades del sistema

• Operadores de la tienda o Consultar los movimientos de stock o Consultar las posibles carencias de producto (roturas de stocks) o Consultar las estadísticas de los productos o Listar los movimientos de stock o Listar las posibles carencias de producto (roturas de stocks) o Listar las estadísticas de los productos

• Operador de la Central o Consultar los movimientos de stock o Consultar las posibles carencias de producto (roturas de stocks) o Consultar las estadísticas de los productos o Listar los movimientos de stock o Listar las posibles carencias de producto (roturas de stocks) o Listar las estadísticas de los productos




Desde este subsistema tendremos definidas las siguientes funcionalidades:

1.3.2.1 Rotación de stock

Con esta funcionalidad consultaran los operadores del almacén central y los operadores de tienda cuanto tiempo transcurre desde que un producto entra en el almacén, hasta que se efectúa la salida de este al ser vendido. Nos permitirá ver de forma global los movimientos de los productos a través de los diferentes almacenes de las tiendas y del almacén central.

Esta opción estará asignada al menú Estadísticas submenú Rotación de stock

El sistema presentará una pantalla inicial donde el usuario podrá establecer una serie de filtros que le permitirán consultar los movimientos de los productos entre los diferentes almacenes.

El sistema solicitará una serie de datos básicos que identificarán los productos a consultar. Una vez introducidos los datos por el operador, el subsistema se encargará de verificar la congruencia de estos datos, avisar al usuario en caso de que alguno de los datos no cumpla las siguientes especificaciones.

• Formato de fecha erróneo.

• Fecha de finalización es inferior a fecha de inicio.

Una vez que los datos pasan el control de verificación, el sistema mostrará por pantalla los movimientos (rotaciones) de los diferentes productos.

1.3.2.2 Roturas de stock

Con esta funcionalidad consultaran los operadores del almacén central y los operadores de tienda cuales son los almacenes que han sufrido alguna rotura de stocks, determinando sobre qué productos y en un intervalo de fechas determinado.

Esta opción estará asignada al menú Estadísticas submenú Roturas de stock





Una vez que los datos pasan el control de verificación, el sistema mostrará por pantalla las roturas de stock de los diferentes productos.



1.3.2.3 Estadísticas de productos

Con esta funcionalidad consultaran los operadores del almacén central y los operadores de tienda qué productos son los más o menos solicitados y/o cuales son los más o menos devueltos y además informar con los resultados de la posición que ocupan o de la frecuencia en la que ocurre, generando para ello un ranking ranking/porcentaje en un intervalo de fechas determinadas.

Esta opción estará asignada al menú Estadísticas submenú Estadísticas de productos





Una vez que los datos pasan el control de verificación, el sistema mostrará por pantalla los movimientos (rotaciones) de los diferentes productos.

1.3.2.4 Imprimir

Con esta funcionalidad realizarán, los operadores del almacén central y los operadores de tienda, listados a enviar a una impresora con el resultado de una consulta previa, vista en las funcionalidades citadas en los puntos anteriores.

Esta opción estará asignada al menú Estadísticas submenú Rotación de stock

Esta opción estará asignada al menú Estadísticas submenú Roturas de stock

Esta opción estará asignada al menú Estadísticas submenú Estadísticas de productos

El sistema presentará cada una de las pantallas iniciales donde el usuario podrá establecer una serie de filtros que le permitirán consultar los movimientos de los productos entre los diferentes almacenes.

Una vez que los datos pasan el control de verificación y mostradas cada una de las consultas el sistema dará la opción de imprimir con lo que se listará por impresora la consulta seleccionada.





1.3.4.2 Rotura de Stcks

1.3.4.3 Estadística de productos





Resultados (por operador de tienda)



1.3.5.2 Rotura de Stocks

Resultados (por operador de Almacén central)



1.3.5.3 Estadística de Productos



Resultado de productos más solicitados por ranking (por operador de tienda)



Resultado de productos menos devueltos por porcentaje (por operador de Almacén Central)

Pantallas de error

Se propone una mejora al añadir las pantallas de error siguientes:



1.4 Subsistema de conexión 1.4.1 Descripción

Es el subsistema que ejecutará cualquier usuario que quiera acceder a la aplicación. Su función es la de hacer de punto de enlace con el resto de los subsistemas que componen la aplicación y permitir al usuario realizar aquellas acciones que tenga a su disposición según su perfil de usuario. Es por tanto indispensable haber sido dado de alta previamente por un administrador del sistema tras lo cual dispondrá de un nombre de usuario único y una contraseña (password) que podrá cambiar posteriormente. La identificación del usuario proporciona una doble utilidad:

• Por una parte funciona como filtro de seguridad, de manera que ningún usuario ajeno al sistema pueda entrar en él.

• Por otro lado al reconocer al usuario, el sistema pondrá a su disposición únicamente las opciones y herramientas que el usuario está autorizado a utilizar.

Con respecto a la fase anterior se ha incluido una medida de seguridad en el acceso a la sesión. En el caso de que un usuario se equivoque tres veces consecutivas a la hora de introducir el password la sesión se cerrará automáticamente. También se ha cambiado la forma en que se presentan los menús en la pantalla principal. Si en la fase anterior todos los usuarios podían ver los tres menús pero solo podían desplegar aquellos a los que tenían permiso (por ejemplo el menú de Mantenimiento sólo estaba disponible para administradores, al resto de usuarios les aparecía sombreado), en esta fase se ha optado por solo mostrar los menús que vayan a utilizar. No se han incluido las opciones de mantenimiento, alta, modificación y borrado de menús, funcionalidades y perfiles. Creemos que la gestión de estos elementos excede el cometido de un administrador del sistema, que es el de gestionar usuarios, almacenes, productos y proveedores. Aquellas modificaciones internas del sistema y que pueden afectar a la estructura de la aplicación deberán ser solicitadas a la empresa que es la propietaria del código fuente.


A la hora de utilizar la aplicación se han establecido tres tipos de perfiles de usuario: • Administrador. • Operador de central. • Operador de tienda.

Una vez autentificados las opciones disponibles variarán en función del perfil del usuario. Las funcionalidades a las que tiene acceso cada perfil son las siguientes:

• Administrador: El Administrador tendrá acceso al menú de Mantenimiento. A través de este menú puede gestionar todos los elementos del sistema: usuarios, almacenes, productos, proveedores y distancias.

• Operador de Central:



El Operador de Central se encarga de aquellas tareas que afectan a la relación entre el almacén central y los almacenes de las tiendas del sistema. En concreto tiene acceso a los menús de Control de Flujo y de Listados y Estadísticas, cada uno de los cuales tiene sus propios submenús, así como a un menú de Opciones que le permitirá cambiar la contraseña de acceso o conectarse a un almacén concreto.

• Operador de Tienda:

El Operador de Tienda se encarga de la gestión de los elementos dentro de la tienda a la que está asignado, y por normal general no podrá consultar la situación de los almacenes de otras tiendas. Al igual que el Operador de Central puede realizar operaciones del menú de Control de Flujo y de Listados y Estadísticas, si bien las operaciones realizadas solo pueden afectar a su tienda y dentro del menú de Opciones solo podrá cambiar la contraseña, no conectarse a otras tiendas.

1.4.2.1 Acceso al sistema

Para comenzar a utilizar la aplicación es necesario autentificarse mediante un nombre de usuario y un password válidos. Una vez introducidos ambos datos en la pantalla de login el sistema será el encargado de verificar que el usuario está dado de alta en la base de datos y que el password es correcto. En caso de error se informará al usuario del problema a través de un mensaje por pantalla. Si el nombre de usuario no existe, ya sea porque no ha sido dado de alta o porque se ha cometido un error a la hora de escribirlo se informará de que el usuario es incorrecto y volverá a solicitar los datos. Si por el contrario el nombre de usuario es correcto pero el password es erróneo el sistema informará de que el password no es válido y solicitará de nuevo los datos. En caso de fallar tres veces seguidas se cerrará la aplicación.

1.4.2.2 Selección de almacén

Tras autentificarse y antes de entrar en la ventana principal se presentará una pantalla de selección de la tienda a la que el usuario desea conectarse. Los usuarios de tienda solo tendrán acceso a su propia tienda dentro de la lista desplegable mientras que los usuarios del almacén central pueden conectarse a cualquier tienda. Posteriormente si el usuario de central desea cambiar la tienda a la que está conectado sin necesidad de cerrar la sesión puede hacer uso de la opción de selección de tienda dentro del menú de Opciones.


Permite a los usuarios registrados en el sistema cambiar la clave de acceso una vez han abierto sesión en el sistema. Para ello deberá utilizar la opción de cambio de contraseña dentro del menú de Opciones (los administradores lo hacen directamente desde la opción correspondiente en el submenú de Gestión de Usuarios).

Para realizar el cambio de contraseña es necesario introducir la contraseña anterior y dos veces la nueva contraseña. En caso de error a la hora de introducir los datos se avisará al usuario del error con alguno de los mensajes siguientes:



• Contraseña incorrecta: en caso de error al introducir la contraseña antigua.

• Contraseñas distintas: en caso de error a la hora de repetir la nueva contraseña.

• Contraseña igual: en caso de que la nueva contraseña sea la misma que la contraseña antigua.





Pantalla de error por contraseña incorrecta:





Pantalla de error por nueva contraseña similar a la antigua:

1.4.5.4 Menús de usuario

• Perfil Administrador:



• Perfil Operador de Central:



• Perfil Operador de Tienda:



2 Diseño de la persistencia El diagrama de entidades del modelo de negocio que anteriormente se ha presentado es el siguiente:

A este modelo se va añadir todos los atributos que han surgido a lo largo del diseño de los subsistemas.

El modelo presentado es un modelo orientado a objetos y existen ciertas características que no existen en las bases de datos relacionales. Como la persistencia se va a realizar en una base de datos relacional se van a realizar un conjunto de transformaciones para trasladar estos conceptos:

• Se trasladará la herencia integrando las clases Compra, Venta, Traspaso, Devolución y Albarán en una única tabla Albarán

• Se trasladará la herencia de Centro, Tienda y Central y la relación 1 a 1 de Centro y Almacén a una única tabla Tienda que tendrá una relación con una tabla TipoTienda que contendrá los valores Tienda y Central

• Para mantener la identidad de los objetos se utilizarán subrogates enteros en cada tabla que se irán generando usando las secuencias de la base de datos y se utilizarán para trasladar las relaciones de asociación como claves foráneas que refieren a estos subrogates.

• Todos los atributos tipo XXX o situación YYYY o estado YYYY se transforma en claves foráneas a tablas maestras TipoXXX o SituacionYYYY. Mediante este mecanismo se posibilitará la garantía de la consistencia de dichos atributos y la posibilidad más delante de ampliarlos sin tocar la estructura de la base de datos. Además facilitarán la internacionalización ya que además del subrógate para cada tipo o situación se añadirá una columna descripción que se corresponderá con la clave que el sistema deba buscar en los archivos de internacionalización.



2.1 Diagrama de la base de datos

<<not null>> <<PK>>-id_proveedor : serial"(10)" = nextval('prov...<<not null>>-codigo : bpchar"(10)"<<not null>>-cif : bpchar"(10)"<<not null>>-nombre : varchar"(50)"<<null>>-direccion : varchar"(50)"<<null>>-codigo_postal : bpchar"(5)"<<null>>-poblacion : varchar"(50)"<<null>>-provincia : varchar"(50)"<<null>>-telefono : bpchar"(15)"<<null>>-fax : bpchar"(15)"<<not null>>-fecha_alta : date"(13)" = ('now'::text)::date<<not null>>-fecha_modificacion : date"(13)" = ('now'::text)::date<<null>>-fecha_baja : date"(13)"

<<table>>Proveedor

<<not null>> <<PK>>-id_usuario : serial"(10)" = ne...<<not null>>-codigo : bpchar"(10)"<<not null>>-nif : bpchar"(10)"<<not null>>-password : bpchar"(10)"<<not null>>-nombre : varchar"(50)"<<not null>>-apellidos : varchar"(50)"<<not null>>-id_tienda : int4"(10)"<<null>>-direccion : varchar"(50)"<<null>>-codigo_postal : bpchar"(5)"<<null>>-poblacion : varchar"(50)"<<null>>-provincia : varchar"(50)"<<null>>-telefono : bpchar"(15)"<<null>>-movil : bpchar"(15)"<<null>>-sexo : bpchar"(1)"<<null>>-fecha_nacimiento : date"(13)"<<not null>>-fecha_alta : date"(13)" = ('now'::text):...<<not null>>-fecha_modificacion : date"(13)" = ('no...<<null>>-fecha_baja : date"(13)"<<not null>>-id_tipo_usuario : int4"(10)"

<<index>> <<unique>>+Usuario_codigo_key( codi...<<index>> <<unique>>+Usuario_nif_key( nif )

<<table>>Usuario

<<not null>> <<PK>>-id_situacion_albaran : int4"(1...<<not null>>-descripcion : varchar"(20)"

<<table>>SituacionAlbaran

<<not null>> <<PK>>-id_tipo_albaran : int4"(10)"{p...<<not null>>-descripcion : varchar"(20)"

<<table>>TipoAlbaran

<<not null>>-id_tienda : int4"(10)"<<not null>>-id_producto : int4"(10)"<<null>>-stock : int4"(10)"

<<PK>>+pk_stock(){columns = id_tienda, id_produ...

<<table>>Stock

<<not null>>-id_albaran : int4"(10)"<<not null>>-id_linea : serial"(10)" = nextval('albar...<<not null>>-id_producto : int4"(10)"<<not null>>-cantidad : int4"(10)"

<<PK>>+pk_lineaalbaran(){columns = id_albaran, i...

<<table>>LineaAlbaran

<<not null>> <<PK>>-id_tipo_usuario : int4"(10)"{p...<<not null>>-descripcion : varchar"(20)"

<<table>>TipoUsuario

<<not null>>-id_solicitud : int4"(10)"<<not null>>-id_linea : serial"(10)" = nextval('solicit...<<not null>>-id_producto : int4"(10)"<<not null>>-cantidad : int4"(10)"

<<PK>>+pk_lineasolicitud(){columns = id_solicitud,...

<<table>>LineaSolicitud

<<not null>> <<PK>>-id_tienda : serial"(10)" = next...<<not null>>-codigo : bpchar"(10)"<<not null>>-nombre : varchar"(50)"<<null>>-direccion : varchar"(50)"<<null>>-codigo_postal : bpchar"(5)"<<null>>-poblacion : varchar"(50)"<<null>>-provincia : varchar"(50)"<<null>>-telefono : bpchar"(15)"<<null>>-fax : bpchar"(15)"<<not null>>-id_tipo_tienda : int4"(10)"<<not null>>-fecha_alta : date"(13)" = ('now'::text)...<<not null>>-fecha_modificacion : date"(13)" = ('n...<<null>>-fecha_baja : date"(13)"

<<table>>Tienda

<<not null>> <<PK>>-id_tipo_movimiento : int4"(10...<<not null>>-descripcion : varchar"(20)"

<<table>>TipoMovimiento

<<not null>>-id_tienda : int4"(10)"<<not null>>-id_tienda2 : int4"(10)"<<not null>>-distancia : float8"(17, 17)"

<<PK>>+pk_distancia(){columns = id_tienda, id_tie...

<<table>>Distancia

<<not null>> <<PK>>-id_tipo_tienda : int4"(10)"{pk ...<<not null>>-descripcion : varchar"(20)"

<<table>>TipoTienda

<<not null>> <<PK>>-id_situacion_solicitud : int4"(...<<not null>>-descripcion : varchar"(20)"

<<table>>SituacionSolicitud

<<not null>> <<PK>>-id_movimiento : serial"(10)" =...<<not null>>-id_tienda : int4"(10)"<<not null>>-id_producto : int4"(10)"<<not null>>-fecha : date"(13)" = ('now'::text)::date<<not null>>-id_albaran : int4"(10)"<<not null>>-id_tipo_movimiento : int4"(10)"<<not null>>-stock_anterior : int4"(10)"<<not null>>-stock : int4"(10)"<<not null>>-id_linea : int4"(10)"

<<index>>+fki_movimiento_lineaalbaran( id_albara...

<<table>>Movimiento

<<not null>> <<PK>>-id_albaran : serial"(10)" = ne...<<not null>>-id_tipo_albaran : int4"(10)"<<not null>>-fecha : date"(13)" = ('now'::text)::date<<not null>>-fecha_recepcion : date"(13)" = ('no...<<not null>>-id_origen : int4"(10)"<<null>>-id_destino : int4"(10)"<<null>>-id_proveedor : int4"(10)"<<not null>>-id_situacion_albaran : int4"(10)"<<null>>-motivo : varchar"(50)"<<null>>-observaciones : varchar"(50)"

<<table>>Albaran

<<not null>> <<PK>>-id_producto : serial"(10)" = n...<<not null>>-codigo : bpchar"(10)"<<not null>>-nombre : varchar"(50)"<<null>>-atributo1 : bpchar"(10)"<<null>>-atributo2 : bpchar"(10)"<<null>>-atributo3 : bpchar"(10)"<<null>>-atributo4 : bpchar"(10)"<<null>>-descripcion : text"(2147483647)"<<not null>>-fecha_alta : date"(13)" = ('now'::text)...<<not null>>-fecha_modificacion : date"(13)" = ('n...<<null>>-fecha_baja : date"(13)"

<<table>>Producto

<<not null>> <<PK>>-id_solicitud : serial"(10)" = n...<<not null>>-fecha : date"(13)" = ('now'::text)::date<<null>>-fecha_recepcion : date"(13)"<<not null>>-id_tienda : int4"(10)"<<not null>>-id_situacion_solicitud : int4"(10)"<<null>>-observaciones : varchar"(50)"

<<table>>Solicitud

<<FK>>

{FK columns = id_origen ,PK columns = id_tienda }

fk_albaran_tiendaorigen

<<FK>>

{FK columns = id_destino ,PK columns = id_tienda }

fk_albaran_tiendadestino

<<FK>>

{FK columns = id_tipo_albaran ,PK columns = id_tipo_albaran }

fk_albaran_tipoalbaran

<<FK>>

{FK columns = id_situacion_albaran ,PK columns = id_situacion_albaran }

fk_albaran_situacionalbaran

<<FK>>


fk_solicitud_tienda

<<FK>>



<<FK>>


fk_stock_producto

<<FK>>


fk_movimiento_tienda

<<FK>>


fk_movimiento_producto

<<FK>>


fk_stock_tienda

<<FK>>

{FK columns = id_tipo_usuario ,PK columns = id_tipo_usuario }

fk_usuario_tipousuario

<<FK>>


fk_lineaalbaran_producto

<<FK>>

{FK columns = id_solicitud ,PK columns = id_producto }

fk_lineasolicitud_producto

<<FK>>

{FK columns = id_tienda2 ,PK columns = id_tienda }


<<FK>>


fk_usuario_tienda<<FK>>

{FK columns = id_tipo_tienda ,PK columns = id_tipo_tienda }

fk_tienda_tipotienda

<<FK>>

{FK columns = id_tipo_movimiento ,PK columns = id_tipo_movimiento }

fk_movimiento_tipomovimiento

<<FK>>

{FK columns = id_solicitud ,PK columns = id_solicitud }

fk_lineasolicitud_solicitud

<<FK>>

{FK columns = id_situacion_solicitud ,PK columns = id_situacion_solicitud }

fk_solicitud_tiposolicitud

<<FK>>

{FK columns = id_proveedor ,PK columns = id_proveedor }

fk_albaran_proveedor

<<FK>>


fk_movimiento_albaran

<<FK>>


fk_lineaalbaran_albaran



2.2 Script de la base de datos CREATE SEQUENCE albaran_id_albaran_seq START WITH 1 INCREMENT BY 1 NO MAXVALUE NO MINVALUE CACHE 1; SET default_tablespace = ''; SET default_with_oids = false; CREATE TABLE albaran ( id_albaran integer DEFAULT nextval('albaran_id_albaran_seq'::regclass) NOT NULL, id_tipo_albaran integer NOT NULL, fecha date DEFAULT ('now'::text)::date NOT NULL, fecha_recepcion date DEFAULT ('now'::text)::date NOT NULL, id_origen integer NOT NULL, id_destino integer, id_proveedor integer, id_situacion_albaran integer NOT NULL, motivo character varying(50), observaciones character varying(50) ); CREATE SEQUENCE albaran_lineas_id_linea_seq START WITH 1 INCREMENT BY 1 NO MAXVALUE NO MINVALUE CACHE 1; CREATE TABLE distancia ( id_tienda integer NOT NULL, id_tienda2 integer NOT NULL, distancia double precision NOT NULL ); CREATE TABLE lineaalbaran ( id_albaran integer NOT NULL, id_linea integer DEFAULT nextval('albaran_lineas_id_linea_seq'::regclass) NOT NULL, id_producto integer NOT NULL, cantidad integer NOT NULL ); CREATE SEQUENCE solicitud_lineas_id_linea_seq START WITH 1 INCREMENT BY 1 NO MAXVALUE NO MINVALUE CACHE 1; CREATE TABLE lineasolicitud ( id_solicitud integer NOT NULL, id_linea integer DEFAULT nextval('solicitud_lineas_id_linea_seq'::regclass) NOT NULL, id_producto integer NOT NULL, cantidad integer NOT NULL ); CREATE SEQUENCE movimiento_id_movimiento_seq START WITH 1



INCREMENT BY 1 NO MAXVALUE NO MINVALUE CACHE 1; CREATE TABLE movimiento ( id_movimiento integer DEFAULT nextval('movimiento_id_movimiento_seq'::regclass) NOT NULL, id_tienda integer NOT NULL, id_producto integer NOT NULL, fecha date DEFAULT ('now'::text)::date NOT NULL, id_albaran integer NOT NULL, id_linea integer NOT NULL, id_tipo_movimiento integer NOT NULL, stock_anterior integer NOT NULL, stock integer NOT NULL ); CREATE SEQUENCE producto_id_producto_seq START WITH 1 INCREMENT BY 1 NO MAXVALUE NO MINVALUE CACHE 1; CREATE TABLE producto ( id_producto integer DEFAULT nextval('producto_id_producto_seq'::regclass) NOT NULL, codigo character(10) NOT NULL, nombre character varying(50) NOT NULL, atributo1 character(10), atributo2 character(10), atributo3 character(10), atributo4 character(10), descripcion text, fecha_alta date DEFAULT ('now'::text)::date NOT NULL, fecha_modificacion date DEFAULT ('now'::text)::date NOT NULL, fecha_baja date ); CREATE SEQUENCE proveedor_id_proveedor_seq INCREMENT BY 1 NO MAXVALUE NO MINVALUE CACHE 1; CREATE TABLE proveedor ( id_proveedor integer DEFAULT nextval('proveedor_id_proveedor_seq'::regclass) NOT NULL, codigo character(10) NOT NULL, cif character(10) NOT NULL, nombre character varying(50) NOT NULL, direccion character varying(50), codigo_postal character(5), poblacion character varying(50), provincia character varying(50), telefono character(15), fax character(15), fecha_alta date DEFAULT ('now'::text)::date NOT NULL, fecha_modificacion date DEFAULT ('now'::text)::date NOT NULL, fecha_baja date );



CREATE TABLE situacionalbaran ( id_situacion_albaran integer NOT NULL, descripcion character varying(20) NOT NULL ); CREATE TABLE situacionsolicitud ( id_situacion_solicitud integer NOT NULL, descripcion character varying(20) NOT NULL ); CREATE SEQUENCE solicitud_id_solicitud_seq START WITH 1 INCREMENT BY 1 NO MAXVALUE NO MINVALUE CACHE 1; CREATE TABLE solicitud ( id_solicitud integer DEFAULT nextval('solicitud_id_solicitud_seq'::regclass) NOT NULL, fecha date DEFAULT ('now'::text)::date NOT NULL, fecha_recepcion date, id_tienda integer NOT NULL, id_situacion_solicitud integer NOT NULL, observaciones character varying(50) ); CREATE TABLE stock ( id_tienda integer NOT NULL, id_producto integer NOT NULL, stock integer ); CREATE SEQUENCE tienda_id_tienda_seq INCREMENT BY 1 NO MAXVALUE NO MINVALUE CACHE 1; CREATE TABLE tienda ( id_tienda integer DEFAULT nextval('tienda_id_tienda_seq'::regclass) NOT NULL, codigo character(10) NOT NULL, nombre character varying(50) NOT NULL, direccion character varying(50), codigo_postal character(5), poblacion character varying(50), provincia character varying(50), telefono character(15), fax character(15), id_tipo_tienda integer NOT NULL, fecha_alta date DEFAULT ('now'::text)::date NOT NULL, fecha_modificacion date DEFAULT ('now'::text)::date NOT NULL, fecha_baja date ); CREATE TABLE tipoalbaran ( id_tipo_albaran integer NOT NULL, descripcion character varying(20) NOT NULL ); CREATE TABLE tipomovimiento ( id_tipo_movimiento integer NOT NULL,



descripcion character varying(20) NOT NULL ); CREATE TABLE tipotienda ( id_tipo_tienda integer NOT NULL, descripcion character varying(20) NOT NULL ); CREATE TABLE tipousuario ( id_tipo_usuario integer NOT NULL, descripcion character varying(20) NOT NULL ); CREATE SEQUENCE usuario_id_usuario_seq INCREMENT BY 1 NO MAXVALUE NO MINVALUE CACHE 1; CREATE TABLE usuario ( id_usuario integer DEFAULT nextval('usuario_id_usuario_seq'::regclass) NOT NULL, codigo character(10) NOT NULL, nif character(10) NOT NULL, password character(10) NOT NULL, nombre character varying(50) NOT NULL, apellidos character varying(50) NOT NULL, id_tipo_usuario integer NOT NULL, id_tienda integer NOT NULL, direccion character varying(50), codigo_postal character(5), poblacion character varying(50), provincia character varying(50), telefono character(15), movil character(15), sexo character(1), fecha_nacimiento date, fecha_alta date DEFAULT ('now'::text)::date NOT NULL, fecha_modificacion date DEFAULT ('now'::text)::date NOT NULL, fecha_baja date );

ALTER TABLE ONLY albaran ADD CONSTRAINT pk_albaran PRIMARY KEY (id_albaran); ALTER TABLE ONLY distancia ADD CONSTRAINT pk_distancia PRIMARY KEY (id_tienda, id_tienda2); ALTER TABLE ONLY lineaalbaran ADD CONSTRAINT pk_lineaalbaran PRIMARY KEY (id_albaran, id_linea); ALTER TABLE ONLY lineasolicitud ADD CONSTRAINT pk_lineasolicitud PRIMARY KEY (id_solicitud, id_linea); ALTER TABLE ONLY movimiento ADD CONSTRAINT pk_movimiento PRIMARY KEY (id_movimiento); ALTER TABLE ONLY producto ADD CONSTRAINT pk_producto PRIMARY KEY (id_producto); ALTER TABLE ONLY proveedor ADD CONSTRAINT pk_proveedor PRIMARY KEY (id_proveedor);



ALTER TABLE ONLY situacionalbaran ADD CONSTRAINT pk_situacionalbaran PRIMARY KEY (id_situacion_albaran); ALTER TABLE ONLY situacionsolicitud ADD CONSTRAINT pk_situacionsolicitud PRIMARY KEY (id_situacion_solicitud); ALTER TABLE ONLY solicitud ADD CONSTRAINT pk_solicitud PRIMARY KEY (id_solicitud); ALTER TABLE ONLY stock ADD CONSTRAINT pk_stock PRIMARY KEY (id_tienda, id_producto); ALTER TABLE ONLY tienda ADD CONSTRAINT pk_tienda PRIMARY KEY (id_tienda); ALTER TABLE ONLY tipoalbaran ADD CONSTRAINT pk_tipoalbaran PRIMARY KEY (id_tipo_albaran); ALTER TABLE ONLY tipomovimiento ADD CONSTRAINT pk_tipomovimiento PRIMARY KEY (id_tipo_movimiento); ALTER TABLE ONLY tipotienda ADD CONSTRAINT pk_tipotienda PRIMARY KEY (id_tipo_tienda); ALTER TABLE ONLY tipousuario ADD CONSTRAINT pk_tipousuario PRIMARY KEY (id_tipo_usuario); ALTER TABLE ONLY usuario ADD CONSTRAINT pk_usuario PRIMARY KEY (id_usuario); ALTER TABLE ONLY usuario ADD CONSTRAINT usuario_codigo_key UNIQUE (codigo); ALTER TABLE ONLY usuario ADD CONSTRAINT usuario_nif_key UNIQUE (nif); CREATE INDEX fki_movimiento_lineaalbaran ON movimiento USING btree (id_albaran, id_linea); ALTER TABLE ONLY albaran ADD CONSTRAINT fk_albaran_proveedor FOREIGN KEY (id_proveedor) REFERENCES proveedor(id_proveedor); ALTER TABLE ONLY albaran ADD CONSTRAINT fk_albaran_situacionalbaran FOREIGN KEY (id_situacion_albaran) REFERENCES situacionalbaran(id_situacion_albaran); ALTER TABLE ONLY albaran ADD CONSTRAINT fk_albaran_tiendadestino FOREIGN KEY (id_destino) REFERENCES tienda(id_tienda); ALTER TABLE ONLY albaran ADD CONSTRAINT fk_albaran_tiendaorigen FOREIGN KEY (id_origen) REFERENCES tienda(id_tienda); ALTER TABLE ONLY albaran ADD CONSTRAINT fk_albaran_tipoalbaran FOREIGN KEY (id_tipo_albaran) REFERENCES tipoalbaran(id_tipo_albaran); ALTER TABLE ONLY distancia ADD CONSTRAINT fk_distancia_tienda1 FOREIGN KEY (id_tienda) REFERENCES



tienda(id_tienda) ON UPDATE CASCADE ON DELETE CASCADE; ALTER TABLE ONLY distancia ADD CONSTRAINT fk_distancia_tienda2 FOREIGN KEY (id_tienda2) REFERENCES tienda(id_tienda) ON UPDATE CASCADE ON DELETE CASCADE; ALTER TABLE ONLY lineaalbaran ADD CONSTRAINT fk_lineaalbaran_albaran FOREIGN KEY (id_albaran) REFERENCES albaran(id_albaran) ON UPDATE CASCADE ON DELETE CASCADE; ALTER TABLE ONLY lineaalbaran ADD CONSTRAINT fk_lineaalbaran_producto FOREIGN KEY (id_producto) REFERENCES producto(id_producto); ALTER TABLE ONLY lineasolicitud ADD CONSTRAINT fk_lineasolicitud_producto FOREIGN KEY (id_solicitud) REFERENCES producto(id_producto); ALTER TABLE ONLY lineasolicitud ADD CONSTRAINT fk_lineasolicitud_solicitud FOREIGN KEY (id_solicitud) REFERENCES solicitud(id_solicitud) ON UPDATE CASCADE ON DELETE CASCADE; ALTER TABLE ONLY movimiento ADD CONSTRAINT fk_movimiento_producto FOREIGN KEY (id_producto) REFERENCES producto(id_producto); ALTER TABLE ONLY movimiento ADD CONSTRAINT fk_movimiento_tienda FOREIGN KEY (id_tienda) REFERENCES tienda(id_tienda); ALTER TABLE ONLY movimiento ADD CONSTRAINT fk_movimiento_tipomovimiento FOREIGN KEY (id_tipo_movimiento) REFERENCES tipomovimiento(id_tipo_movimiento); ALTER TABLE ONLY solicitud ADD CONSTRAINT fk_solicitud_tienda FOREIGN KEY (id_tienda) REFERENCES tienda(id_tienda); ALTER TABLE ONLY solicitud ADD CONSTRAINT fk_solicitud_tiposolicitud FOREIGN KEY (id_situacion_solicitud) REFERENCES situacionsolicitud(id_situacion_solicitud); ALTER TABLE ONLY stock ADD CONSTRAINT fk_stock_producto FOREIGN KEY (id_producto) REFERENCES producto(id_producto); ALTER TABLE ONLY stock ADD CONSTRAINT fk_stock_tienda FOREIGN KEY (id_tienda) REFERENCES tienda(id_tienda); ALTER TABLE ONLY tienda ADD CONSTRAINT fk_tienda_tipotienda FOREIGN KEY (id_tipo_tienda) REFERENCES tipotienda(id_tipo_tienda); ALTER TABLE ONLY usuario ADD CONSTRAINT fk_usuario_tienda FOREIGN KEY (id_tienda) REFERENCES tienda(id_tienda); ALTER TABLE ONLY usuario ADD CONSTRAINT fk_usuario_tipousuario FOREIGN KEY (id_tipo_usuario) REFERENCES tipousuario(id_tipo_usuario);



ALTER TABLE ONLY movimiento ADD CONSTRAINT movimiento_lineaalbaran FOREIGN KEY (id_albaran, id_linea) REFERENCES lineaalbaran(id_albaran, id_linea);

INSERT INTO TipoTienda(id_tipo_tienda, descripcion) VALUES (1,'lit.Central'); INSERT INTO TipoTienda(id_tipo_tienda, descripcion) VALUES (2,'lit.Tienda'); INSERT INTO TipoUsuario(id_tipo_usuario, descripcion) VALUES (1,'lit.Administrador'); INSERT INTO TipoUsuario(id_tipo_usuario, descripcion) VALUES (2,'lit.Operador Central'); INSERT INTO TipoUsuario(id_tipo_usuario, descripcion) VALUES (3,'lit.Operador Tienda'); INSERT INTO tipoalbaran VALUES (1,'lit.Compra'); INSERT INTO tipoalbaran VALUES (2,'lit.Venta'); INSERT INTO tipoalbaran VALUES (3,'lit.Traspaso'); INSERT INTO tipoalbaran VALUES (4,'lit.Devolucion'); INSERT INTO tipomovimiento VALUES (1,'lit.Entrada'); INSERT INTO tipomovimiento VALUES (2,'lit.Salida'); INSERT INTO situacionalbaran VALUES (1,'lit.Emitido'); INSERT INTO situacionalbaran VALUES (2,'lit.Aceptado'); INSERT INTO situacionsolicitud VALUES (1,'lit.Sin cursar'); INSERT INTO situacionsolicitud VALUES (2,'lit.En Estudio'); INSERT INTO situacionsolicitud VALUES (3,'lit.Aceptada'); INSERT INTO situacionsolicitud VALUES (4,'lit.Rechazada');

INSERT INTO Tienda(codigo,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax,id_tipo_tienda) values ('001','SportLliure Central','C/Costa i Llobera 1','8016','Barcelona','Barcelona','935847412','935847413',1); INSERT INTO Tienda(codigo,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax,id_tipo_tienda) values ('002','SportLliure Balmes','C/Balmes 81','8018','Barcelona','Barcelona','934512137','934512138',2); INSERT INTO Tienda(codigo,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax,id_tipo_tienda) values ('003','SportLliure Valldaura','Pso Valldaura 13','8032','Barcelona','Barcelona','932335981','932335982',2); INSERT INTO Tienda(codigo,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax,id_tipo_tienda) values ('004','SporLliure Lleida','Plaza Catalunya 32','25556','Adons','Lleida','973452125','9733452126',2); INSERT INTO Tienda(codigo,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax,id_tipo_tienda) values ('005','SpotLliure Girona','C/Prats 34','17069','Girona','Girona','972341265','972341266',2); INSERT INTO Tienda(codigo,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax,id_tipo_tienda) values ('006','SportLliure Tarragona','Via Julia 145','43007','Tarragona','Tarragona','977451346','977451347',2); INSERT INTO Usuario(codigo,nif,password,nombre,apellidos,id_tipo_usuario,id_tienda,direccion,codigo_postal,poblacion,provincia,telefono,movil,sexo,fecha_nacimiento) values ('001','34054556C','PAC','Juan','Sanchez Diaz',1,'1','C/Villa 23','8014','Barcelona','Barcelona','932335412','684523642','H','1979-03-02'); INSERT INTO Usuario(codigo,nif,password,nombre,apellidos,id_tipo_usuario,id_tienda,direccion,codigo_postal,poblacion,provincia,telefono,movil,sexo,fecha_nacimiento) values ('002','50450003D','PAC','Nuria','Bell Paris',2,'1','C/Marina



234','8016','Barcelona','Barcelona','934513798','635234568','M','1980-09-12'); INSERT INTO Usuario(codigo,nif,password,nombre,apellidos,id_tipo_usuario,id_tienda,direccion,codigo_postal,poblacion,provincia,telefono,movil,sexo,fecha_nacimiento) values ('003','14460014Y','PAC','Maria','Jimenez Pardo',3,'2','C/Mina 782','8018','Barcelona','Barcelona','933456752','612347895','M','1983-07-01'); INSERT INTO Usuario(codigo,nif,password,nombre,apellidos,id_tipo_usuario,id_tienda,direccion,codigo_postal,poblacion,provincia,telefono,movil,sexo,fecha_nacimiento) values ('004','23346005Q','PAC','Daniel','Perez Hernandez',3,'3','Cta/ Barcelona 23','8034','Barcelona','Barcelona','934369878','626451247','H','1976-12-26'); INSERT INTO Usuario(codigo,nif,password,nombre,apellidos,id_tipo_usuario,id_tienda,direccion,codigo_postal,poblacion,provincia,telefono,movil,sexo,fecha_nacimiento) values ('005','34560041B','PAC','Eva','Duch Vilar',3,'4','C/Deu i Mata 345','25036','Lleida','Lleida','973653474','609324512','M','1985-11-07'); INSERT INTO Usuario(codigo,nif,password,nombre,apellidos,id_tipo_usuario,id_tienda,direccion,codigo_postal,poblacion,provincia,telefono,movil,sexo,fecha_nacimiento) values ('006','42466523J','PAC','Georgina','Valls Pons',3,'5','Pso Maragall 74','17001','Giraona','Girona','972365641','614236545','M','1976-01-07'); INSERT INTO Usuario(codigo,nif,password,nombre,apellidos,id_tipo_usuario,id_tienda,direccion,codigo_postal,poblacion,provincia,telefono,movil,sexo,fecha_nacimiento) values ('007','39811245Q','PAC','Anna','Carbonell Casas',3,'6','C/Barea 63','43008','Tarragona','Tarragona','977398451','638986512','M','1969-02-02'); INSERT INTO Usuario(codigo,nif,password,nombre,apellidos,id_tipo_usuario,id_tienda,direccion,codigo_postal,poblacion,provincia,telefono,movil,sexo,fecha_nacimiento) values ('008','45033654E','PAC','Berta','Gonzalez Zomeño',3,'1','C/Salinas 74','8021','Barcelona','Barcelona','934153684','641398545','M','1990-04-01'); INSERT INTO Usuario(codigo,nif,password,nombre,apellidos,id_tipo_usuario,id_tienda,direccion,codigo_postal,poblacion,provincia,telefono,movil,sexo,fecha_nacimiento) values ('009','38906538Z','PAC','Maria','Fernandez Camino',3,'2','Cta de Madrid','8034','Barcelona','Barcelona','933569465','625060810','M','1987-05-23'); INSERT INTO Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1000','B17319237','Adidas s.a.','C/ La Canya,1 (antiga ctra.N.II,Km.711,9)','17458','Fornells de la Selva','Girona','972576455','972477687'); INSERT INTO Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1001','B17694951','Nike s.a.','Barrio Estación s/n','17172','Les Planes d Hostoles','Girona','972445079','972443456'); INSERT INTO Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1002','A17017823','Puma s.a.','Barrio Estación s/n','17172','Les Planes','Girona','972648079','972444056'); INSERT INTO Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1003','A07449796','Rebook s.l.','Ctra. Local GI 674 KM 4,9','17240','Llagostera','Girona','972890714','972681533'); INSERT INTO Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1004','A46301339','Mizuno s.l.','Pasaje de Arrahona,8-10 (Pol. Ind. Santiga)','8210','Barberà del Vallés','Barcelona','937243447','397276689'); INSERT INTO Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1005','A26003731','Kelme s.a.','Carretera Entrena, 38','26370','Navarrete','La Rioja','941444400','941120645'); INSERT INTO



Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1006','B46136669','Joma s.a.','A3 Valencia-Madrid, km 326','46370','Chiva','Valencia','962523437','962670654'); INSERT INTO Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1007','B17859422','Tenth s.a.','Camí de Sant Roc,s/n.','17180','Vilablareix','Girona','972265600','972405296'); INSERT INTO Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1008','A08109365','Joma s.a.','C/ Viladomat, 321 5ª','8029','Barcelona','Barcelona','934923500',' '); INSERT INTO Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1009','B73319964','Aminostar s.a.','Autovia A7-Salida 635 P.I.Vistabella','30892','Librilla','Murcia','968633080','968659210'); INSERT INTO Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1010','B96097977','Santa Cruz s.l.','Pol. Industrial Los Vientos','46119','Naquera','Valencia','961679150','961393541'); INSERT INTO Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1011','B63915946','Hurley s.l.','C/ Tuset, 1','8006','Barcelona','Barcelona','902342818',''); INSERT INTO Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1012','A08642886','Mares s.a.','Progres, 369/371','8912','Badalona','Barcelona','',''); INSERT INTO Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1013','40315169X','Zoo York s.l.','C/ Firal, 44','17430','Santa Coloma de Farners','Girona','972856680',''); INSERT INTO Proveedor(codigo,cif,nombre,direccion,codigo_postal,poblacion,provincia,telefono,fax) values ('1014','B63126387','wesc s.a.','C/ de l Esglesia, 114','8860','Castelldefels','Barcelona','936376803',''); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('001','002',20); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('001','003',50); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('001','004',60); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('001','005',120); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('001','006',90); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('002','003',25); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('002','004',80); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('002','005',100); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('002','006',70); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('003','004',70); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('003','005',110); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('003','006',40); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('004','005',80); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('004','006',50); INSERT INTO Distancia(id_tienda,id_tienda2,distancia) values ('005','006',65);

e-stocks: Gestor de stocks Memoria - L'Oberta en...

Documents

Transcript of e-stocks: Gestor de stocks Memoria - L'Oberta en...