UNIVERSDAD DE GUAYAQUIL FACULTAD DE INGENIERIA...

UNIVERSDAD DE GUAYAQUIL FACULTAD DE INGENIERIA INDUSTRIAL DEPARTAMENTO ACADÉMICO DE GRADUACIÓN

TRABAJO DE TITULACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO DE

LICENCIADO EN SISTEMAS DE INFORMACIÓN

TEMA DESARROLLO E IMPLEMENTACION DE UN SISTEMA PARA MANEJO Y CONTROL DE

INVENTARIOS UTILIZANDO TECNOLOGÍA RFID

AUTOR: MOREIRA CHUQUIMARCA JOSEPH ANTONIO

DIRECTOR DEL TRABAJO ING. EN SIST. COMP. CAICEDO SALAZAR JOSÉ, MSC.

2015

GUAYAQUIL - ECUADOR

II

DECLARACIÓN DE AUTORÍA

“La responsabilidad del contenido de este trabajo de titulación, me corresponde

exclusivamente; y el patrimonio intelectual del mismo a la Facultad de Ingeniería

Industrial de la Universidad de Guayaquil”

Moreira Chuquimarca Joseph Antonio

0930811914

III

DEDICATORIA

Dedico este trabajo de titulación a DIOS, y a la Virgen María, quienes

inspiraron mi espíritu para la conclusión de este trabajo de titulación de pregrado

de la carrera de Licenciatura de Sistemas de Información.

A mis padres quienes me dieron vida, educación, apoyo y consejos, los cuales

me han ayudado a ser cada día mejor con entusiasmo y seguridad.

A mis compañeros de estudio, a mis maestros y amigos, quienes sin su ayuda

nunca hubiera podido concluir este trabajo de titulación. A todos ellos se los

agradezco desde el fondo de mi alma. Para todos ellos hago esta dedicatoria.

IV

AGRADECIMIENTOS

A Dios primordialmente por darnos la inteligencia, sabiduría, paciencia,

entendimiento y la capacidad para realizar este proyecto.

A mis padres por todo su apoyo, comprensión y confianza, por estar siempre

dándome su apoyo en todo lo que lo he necesitado.

V

INDICE GENERAL

N° Descripción Pág.

PRÓLOGO 1

CAPÍTULO I2

MARCO TEÓRICO2


1.1. La Identificación de la Radiofrecuencia (RFID) ...................................... 2

1.2. Java ........................................................................................................... 6

1.3. Spring ....................................................................................................... 6

1.4. HTML5 ..................................................................................................... 7

1.5. Hibernate .................................................................................................. 7

1.6. JEE (Java, Edición Empresarial) .............................................................. 7

1.7. Java Server (JSP)/Java server Faces (JSF) ............................................... 7

1.8. Server Apache Tomcat ............................................................................. 8

1.9. Extreme Programming (XP) ..................................................................... 8

1.9.1. Fase de exploración ................................................................................... 9

1.9.2. Fase de planificación ................................................................................. 9

1.9.3. Fase de iteraciones .................................................................................... 9

1.9.4. Fase de puesta en producción .................................................................... 9

1.9.5. Las pruebas................................................................................................ 9

CAPÍTULO II11

METODOLOGÍA11


2.1 Metodología XP 11

VI


2.2. Requerimientos Funcionales .................................................................. 15

2.3. Requerimientos no Funcionales ............................................................. 16

2.4. Prototipo ................................................................................................. 17

2.5. Formulario web para ingreso al sistema. ................................................ 18

2.6. Formulario web para despacho de ítems. ............................................... 18

2.7. Formulario web para inventario. ............................................................ 19

2.8. Formulario web para crear compra. ....................................................... 19

2.9. Formulario web para buscar compra. ..................................................... 20

CAPÍTULO III21

PROPUESTA21


3.1. Entorno del Software .............................................................................. 21

3.2. Diagrama de componentes ..................................................................... 23

3.3. Diagrama de despliegue. ........................................................................ 25

3.4. Anotaciones ............................................................................................ 25

3.5. Diseño de la base de datos ...................................................................... 26

3.6. Diccionario de datos ............................................................................... 27

3.7. Diagrama de paquetes del sistema de bodega ........................................ 47

3.8. Pruebas unitarias ..................................................................................... 47

3.9. Prueba de integración del prototipo. ....................................................... 49

3.10. Plan de capacitación ............................................................................... 51

3.11. Costo de desarrollo del Proyecto ............................................................ 52

3.12. Conclusiones .......................................................................................... 52

3.13. Recomendaciones 52

GLOSARIO DE TÉRMINOS .............................................................. 53

BIBLIOGRAFÍAS ................................................................................ 54

VII

ÍNDICE DE CUADROS


1 Caso de uso 1 ......................................................................................... 12

2 Caso de uso 2 .......................................................................................... 13

3 Caso de uso 3 .......................................................................................... 14

4 Requerimientos funcionales .................................................................... 15

5 Requerimientos no funcionales ............................................................... 16

6 Estándares de nombres de componentes ................................................. 17

7 Anotaciones ............................................................................................. 25

8 Diccionario de datos tbl_cliente .............................................................. 27

9 Diccionario de datos tbl_tipo_persona .................................................... 27

10 Diccionario de datos tbl_factura ............................................................. 28

11 Diccionario de datos tbl_tipo_pago ........................................................ 30

12 Diccionario de datos tbl_vendedor.......................................................... 31

13 Diccionario de datos tbl_orden_despacho .............................................. 32

14 Diccionario de datos tbl_estado_venta.................................................... 32

15 Diccionario de datos tbl_producto .......................................................... 34

16 Diccionario de datos tbl_bodega_producto ............................................. 35

17 Diccionario de datos tbl_compras ........................................................... 35

18 Diccionario de datos tbl_marca ............................................................... 37

19 Diccionario de datos tbl_origen_prod ..................................................... 38

20 Diccionario de datos tbl_categoria_producto.......................................... 38

21 Diccionario de datos tbl_inventario ........................................................ 40

22 Diccionario de datos tbl_bodega ............................................................. 41

23 Diccionario de datos tbl_proveedor ........................................................ 42

24 Diccionario de datos tbl_user .................................................................. 42

25 Diccionario de datos tbl_roles ................................................................. 44

26 Diccionario de datos tbl_permisos .......................................................... 45

27 Diccionario de datos tbl_tipo_permiso ................................................... 46

VIII


28 Prueba unitaria vista ingreso al sistema .................................................. 48

29 Prueba unitaria vista despacho de ítems.................................................. 48

30 Prueba unitaria vista inventarios ............................................................. 48

31 Prueba unitaria vista crear compra .......................................................... 48

32 Prueba unitaria vista buscar compra ....................................................... 49

33 Cronograma de capacitación ................................................................... 51

34 Costos del proyecto ................................................................................. 52

IX

ÍNDICE DE GRÁFICOS


1 Funcionamiento tecnología RFID y Sistema informáticos ...................... 3

2 Partes de una etiqueta RFID ..................................................................... 4

3 Esquema de funcionamiento de XP ......................................................... 8

4 Caso de uso para despacho de ítems ...................................................... 11

5 Caso de uso para crear inventario .......................................................... 13

6 Caso de uso para la creación de solicitud de compra ............................. 14

7 Formulario web de ingreso al Sistema ................................................... 18

8 Formulario web para despacho de ítems ................................................ 18

9 Formulario web para realizar inventario ................................................ 19

10 Formulario web para crear una compra ................................................. 19

11 Formulario web para buscar compras .................................................... 20

12 Funcionamiento del sistema ................................................................... 21

13 Archivo Deploy Manager de Spring Security ........................................ 22

14 Archivo Deploy Manager de Spring Security ........................................ 24

15 Diagrama de despliegue ......................................................................... 25

16 Modelo Entidad Relación ....................................................................... 26

17 Diagrama de paquetes del sistema de bodega ........................................ 47

18 Prueba unitaria ....................................................................................... 47

19 Consumo de memoria del prototipo ....................................................... 49

20 Consumo del procesador por parte del prototipo .................................. 50

21 Consumo entre java JDBC y base de datos a orm Hibernate ................. 50

22 Consumo por minuto del SQL en Postgresql ......................................... 51

X

AUTOR: MOREIRA CHUQUIMARCA JOSEPH ANTONIO

TÍTULO: DESARROLLO E IMPLEMENTACION DE UN SISTEMA

PARA MANEJO Y CONTROL DE INVENTARIOS

UTILIZANDO TECNOLOGÍA RFID

DIRECTOR: ING. EN SIST. COMP. CAICEDO SALAZAR JOSÉ, MSC.

RESUMEN

El proyecto está basado en el uso de la identificación por radiofrecuencias

utilizando tecnología RFID en las bodegas de las ferreterías industriales; como

propuesta a la mejora de los procesos de inventario, despacho y perchado, para el

desarrollo de dicha propuesta se usarán tecnologías como Java, Spring, Hibernate,

Java Server Faces bajo el patrón de diseño MVC (Vista, Control Modelo) enfocado

en el desarrollo en capas, mediante la metodología de desarrollo Exteme

Programming que se centra en el uso de la participación del cliente en el proceso

de análisis y desarrollo. Este método carece de documentación y se basa en User

Stories para respaldar los requerimientos de los usuarios, lo cual no lo hace ideal en

el área pedagógica; por lo cual se hace uso de los diagramas de Uml para brindar

soporte y poder documentar los procesos. Por la magnitud de las bodegas de la

compañía, es común encontrar problemas ya mencionados; lo cual ocasiona

pérdidas económicas a la empresa. Se recomienda el uso de sensores RFID los

cuales son ideales para manejar volúmenes de inventarios extensos, previene

pérdidas de los artículos disminuyendo la carga de los mismos ya que este es en

tiempo real. Aunque en la actualidad son elevados los costos de estos sensores, su

costo justifica la inversión ya que pueden trabajar bajo áreas donde existan

materiales como madera, vidrio, metal, papel o líquidos.

PALABRAS CLAVES: Sensores, Soporte, Respaldar, Identificación,

Documentación, Procesos, Desarrollo, MVC.

MOREIRA CHUQUIMARCA JOSEPH ANTONIO ING. CAICEDO SALAZAR JOSÉ, MSC

C.C. 0925619934 Director del trabajo

XI

AUTHOR: MOREIRA CHUQUIMARCA JOSEPH ANTONIO

SUBJECT: DEVELOPMENT AND IMPLEMENTATION OF A SYSTEM

FOR HANDLING AND INVENTORY CONTROL USING

RFID TECHNOLOGY

DIRECTOR: COMP. ENG. CAICEDO SALAZAR JOSÉ, MSC.

ABSTRACT

The project is based on the use of identification by radio frequencies using RFID

technology in the warehouse industrial ironmongery; proposed to the improvement

of the inventory processes, office and hanger. For the development of this project

will be used technologies such as Java, Spring, Hibernate, Java Server Faces under

(Vista, Control model) MVC design pattern focused on development in layers,

using the development methodology Extreme Programming that focuses on the use

of the involvement of the client in the process of analysis and development; This

method has not documentation and relies on User Stories to support the

requirements of them, not making it ideal in the educational area. It is using Uml

Diagrams to provide support and to document the processes. By the magnitude of

the warehouse in the company, it is common to find problems mentioned above,

which causes economic loss to the company. The use of RFID sensors are ideal for

handling large volumes of inventories and is recommended, to prevent loss of the

items decreasing the load of them since this is in real time. Although at the moment

are high costs of these sensors, the cost justifies the investment as they can work on

places where there are materials such as wood, glass, metal, paper or liquids.

KEY WORDS: Sensors, Support, Backup, Identification, Documentation,

Processes Processes, Development, MVC.

MOREIRA CHUQUIMARCA JOSEPH ANTONIO COMP. ENG. CAICEDO SALAZAR JOSÉ, MSC

C.C. 0925619934 Director of work

PRÓLOGO

La presente trabajo de grado tiene el propósito, de desarrollar un sistema para

minimizar automatizar y reducir pasos en los procesos de inventario, perchado,

despacho para la optimización de recursos en las bodegas de las ferreterías

industriáles S.A, para lo cual ha sido necesario utilizar tecnologías tales como

JAVA, HIBERNATE, JPA, Postgres. Las fuentes principales del estudio están

basadas en el modelo de desarrollo MVC, textos especializados en administración

de bodega, ingeniería de software y la observación del proceso por el autor. El

trabajo se divide en 3 partes: la primera parte que trata sobre la introducción y

fundamentación técnica del proceso, la segunda parte sobre el análisis y diagnóstico

del problema y la tercera parte que trate sobre la propuesta y reingeniería de los

procesos.

CAPÍTULO I

MARCO TEÓRICO

1.1. La identificación por radiofrecuencia (rfid)

Los RFID se originaron en la segunda Guerra mundial [Roberti 2004],

inducidos por necesidad de distinguirse entre aviones enemigos y aliados. Mientras

los radares podría descubrir aviones, no se podía distinguir entre aviones enemigos

y amistosos.

Para solucionar este problema los militares británicos desarrollaron IFF, La

tecnología RFID corriente nacen del sistema IFF.

Las tecnología RFID actuales, el transmisor y el receptor se unen en un

transceptor que se llamado lector RFID, para distinguir entre número mucho más

grande de categorías de objetos.

La etiqueta de RFID típica, almacena un número que puede tener una longitud

0 bits, 16 bits, 32bits, 64bits, 96bits, 720bits, 896bits. Cuando se censa con un

lector, una etiqueta transmite su número de serie que permite al lector distinguir

entre aproximadamente 1.028 etiquetas diferentes dependiendo del alcance del

lector.

El identificador almacenado en la etiqueta, identifica el objeto al cual la etiqueta

se asigna, el número de serie no contiene información útil sobre el objeto, sin

embargo, puede ser usada para recuperar la información teniendo acceso a la base

de datos, este proceso lo realiza a través de un lector activo que captura dicha

frecuencia para proceder a comunicarse con el software del mismo y de esa manera

realiza el proceso de búsqueda en la base de datos.

Marco Teórico 3

El receptor RFID, también llamado “etiqueta de RFID”, está compuesta por tres

componentes: una chip una antena y un substrate. Además, la etiqueta también

podría albergar una batería que alimenta a un chip y uno o varios sensores; como

sensores de GPS o temperatura. Los receptores que tienen sensores se llaman

“etiquetas de sensor”.

La antena es una cobertura electromagnética que tiene una envoltura

consecuente creciente en forma de espiral, conecta a la etiqueta.

En etiquetas pasivas la antena canaliza la energía y la retrasmite en las ondas

de radio que vienen de un lector para impulsar la circuitería en el chip de la etiqueta,

el chip contiene, un número que sirve de un identificador único de la etiqueta.

En las etiqueras mixtas poseen una pequeña batería que les permiten realizar el

papel de etiquetas activas y a su vez pasivas dependiendo de cómo se las distribuya,

además las etiquetas tanto activas como pasivas hay que asignarle la frecuencia para

que pueda ser reconocida por el lector, las etiquetas deben de ser relativas al

ambiente donde van ser utilizadas.

GRÁFICO N° 1

FUNCIONAMIENTO TECNOLOGÍA RFID Y SISTEMA

INFORMÁTICOS.

Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.

Marco Teórico 4

GRÁFICO N° 2

PARTES DE UNA ETIQUETA RFID

Las etiquetas de RFID se clasifican como etiquetas pasivas, semipasivas y

activas [Garfinkel y Holtzman 2006]. En las etiquetas pasivas, la energía tenía que

ser dirigida al chip canalizar la transmisión de la radio de vuelta. Una etiqueta

pasiva no posee fuente de energía, una etiqueta activa es alimentada por una batería

incorporada en la etiqueta, esta puede transmitir su señal sin necesidad de ser tocada

por la señal de un lector.

Entre el intermedio entre etiquetas pasivas y activas esta la etiqueta semipasiva

que tiene una batería incluida, para impulsar la señal, no transmite su señal hasta

que sea alcanzada y activada por las ondas electromagnéticas del lector.

La organización EPCglobal, indica que las etiquetas se clasifiquen en seis

clases, desde la Clase 0 a la Clase 5. Los receptores de las Clases 0, 1, y 2 son las

etiquetas de backscatter (método de comunicación por medio de hondas),lLos

receptores de la clase 0 tienen la memoria de sólo lectura, los receptores de la Clase

1 se pueden escribir una vez, y la memoria del receptor de Clase 2 se puede volver

a escribir muchas veces. Los receptores de las Clases 3, 4, y 5 por otra parte se


Marco Teórico 5

asisten por la batería y en su mayoría traen sensores. Mientras los sensores de la

Clase 3 todavía son backscatter, los sensores de las Clases 4 y 5 son capaces de la

transmisión activa.

Las etiquetas de RFID también se diseñan para funcionar en frecuencias

diferentes:

VLF 3 a 30 kHz Ondas miriamétricas.

LF 30 a 300 kHz Ondas kilométricas.

MF 300 a 3000 kHz Ondas hectométricas.

HF 3 a 30 MHz Ondas decamétricas.

VHF 30 a 300 MHz Ondas métricas.

UHF 300 a 3000 MHz Ondas decimétricas.

SHF 3 a 30 GHz Ondas centimétricas.

EHF 30 a 300 GHz Ondas decimilimétricas.

El ambiente en el cual los receptores RFID y los sensores actúan ejerce la

influencia considerable el enlace de comunicación inalámbrica. Por ejemplo, los

metales reflejan ondas de radio mientras los líquidos absorben las ondas. Es por eso

que, la presencia de metales y líquidos entre un lector RFID y etiqueta puede

impedir que la energía de RF sea suficiente para alcanzar al receptor.

Las asignaciones de frecuencia de onda de radio y los límites de poder en la

emisión de dispositivos en el espectro es regulado por cada país. La variedad sobre

la cual el receptor y el lector se pueden comunicar depende de la frecuencia usada

en la comunicación. Se recomienda desde menos de 1 metro, se use LF, HF Para

más de 1 metro, UHF y las frecuencias microondas se usen para distancias mucho

mayores [Finkenzeller 2010].

Los receptores RFID con sensores pueden medir parámetros físicos en su

ambiente. Los receptores de sensor actualmente disponibles son capaces de medir

muchos rasgos ambientales. Notable por ejemplo tenemos los receptores que

Marco Teórico 6

pueden medir temperatura, la humedad y la luz, productos químicos, radiactividad,

y determinar su ubicación (usando GPS) [Bancos et al. 2007], y aceleración de la

medida e inclinación [Ruhanen et al. 2008].

Las implantación de RFID en procesos de automatización tiene una amplia

gama, encontrando un gran campo de acción en los sistemas, de identificación

objetos, clasificación, que van desde software para la administración de ítems

académicos, que permite una gestión totalmente automática de la biblioteca, hasta

el uso de sistemas autómatas inteligentes para sacar ítems. Otro campo es la

administración de personal, donde se trabajó en el desarrollo de un sistema integral,

que puede ayudar en la automatización de la administración de los estudiantes en

una institución.

1.2. Java

Es un lenguaje de orientada a objetos. De código interpretado independiente del

sistema operativo y es sintácticamente y estructuralmente modelado como C/C ++

(Richard M.Reese, 2012).

En el desarrollo con java como lenguaje de programación se puede usar varios

framework, que agregan funcionalidad y facilitan al desarrollo.

1.3. Spring

Es un framework de código abierto, pensado para simplificar la complejidad

del desarrollo de aplicación java empresarial, la utilidad de Spring no es limitada

con el desarrollo de lado del servidor. Las aplicación de java puede beneficiarse en

términos de simplicidad, testability, sostenibilidad (Craig Walls, 2011).

Spring hace uso de metodologías de programación como Inversión de Control,

Programación Orientada a Aspectos. Otro aspecto, proporciona la posibilidad de

integrar con otras tecnologías brindando soporte, estabilidad y usabilidad.

Marco Teórico 7

1.4. HTML5

Ha dejado de ser un lenguaje relativamente de marca de documento y se

convirtió en una plataforma sofisticada para aplicaciones web, que brinda

interfaces ricas en contenido (Josué O Connor, 2012).

1.5. Hibernate

Es un framework ORM que transforma la complejidad de obtención de datos en

simples objetos planos de java (POJO), participa en la capa de persistencia (Jeff

Linwood, Dave Minter, 2010).

1.6. JEE (java, edición empresarial)

La Plataforma de Java EE proporciona una plataforma basada en los estándares

para desarrollar web y aplicaciones empresariales. Estas aplicaciones son

típicamente diseñadas como aplicaciones de multicapa, con una capa frontend que

consiste en web framework, una capa de seguridad media y transacciones, y una

capa de conectividad que es suministra la base de datos desde backend en un

sistema de herencia.

El JEE define APIs para diferentes componentes en cada capa, y también

proveen a unos servicios adicionales, como nombramiento, inyección, y

administración de recursos. Cada componente es definido en su especificación

(Arun Gupta, 2012).

1.7. Java server (jsp)/java server faces (jsf)

Son una tecnología que le ayuda a crear páginas dinámicamente generadas por

la conversión de archivos de escritura en módulos de Java ejecutables; Java Server

(JSF) son un paquete que facilita interactividad con los espectadores de página

(Giulio Zambon, 2012).

Marco Teórico 8

1.8. Server apache tomcat

Servidor de fuente abierta, tiene varios contenedores de aplicación Java Web;

creado y dirigido para servlet y Páginas de Java Server (JSP). Nació bajo la Yakarta

apache subproyecto; sin embargo, debido a su popularidad, ahora es un proyecto

apache separado, donde es apoyado y realzado por un grupo de voluntarios de la

comunidad de Java open source (aleksa vukotic ,2011).

1.9. Extreme programming (xp)

Prescribe la programación en grupos conocido como la programación en par,

donde dos programadores trabajan en una sola estación de trabajo (edward

crookshanks, 2014), el uso mínimo de documentación, la integración del cliente en

toda las fase, la simplicidad, agilidad, ciclos de vida más cortos, reducción de pasos

burocráticos, todas estas características hacen de esta metodología ágil de desarrollo

la ideal para realizar proyectos en tiempos cortos, evitando el abusos de procesos

redundantes.

XP está compuesta de cuatro fases:

GRÁFICO N° 3

ESQUEMA DE FUNCIONAMIENTO DE XP


Marco Teórico 9

Fase de exploración: Es donde se definen los alcances generales del proyecto,

se crean los “user stories” (documentos redactados por los usuarios donde se indican

sus requerimientos), se estiman tiempo de desarrollo primarios basándose en el

análisis de los requerimientos, se crean casos de usos y documentación que formule

el soporte para los user stories, se eligen las arquitecturas (software y hardware) a

usar, los casos de usos sirven de apoyo a las user stories no lo remplazan.

Fase de planificación: En esta fase los involucrados llegan a un acuerdo en el

tiempo, numero de reuniones denominadas “Stand-up meeting”, requerimientos por

parte de los desarrolladores y el orden de entrega y agrupación de la

implementación de los user stories, todo la documentación creada en esta fase es

agrupada y denominada “Release Plan”, para demostración de posibles soluciones

se crean las aproximaciones Spike (pequeños programas de prueba para explorar

diferentes soluciones).

Fase de iteraciones: Empieza el ciclo de desarrollo, pruebas (Test-driven

programming), refactoring (reescritura de código), se crean las tareas específicas de

desarrollo y pruebas , con la intervención del cliente al final de esta fase se genera

un entregable funcional, cada interacción termina en una medida clara de avance,

se reevaluar con los clientes para pulir detalles o correcciones en los user stories y

sus implementación también llamadas Black box system tests, se realizan pruebas

de aceptación para verificar que no afecte a las otras implementaciones.

Fase de puesta en producción: Se entregan módulos funcionales, con su

respectiva documentación de funcionalidad y aprobación de los clientes.

Las pruebas: Las pruebas en el software son el proceso de analizar y encontrar

diferencias entre el comportamiento esperado, especificado por los diferentes

modelos del sistema, y el comportamiento observado del sistema. Las pruebas

unitarias buscan diferencias entre el modelo de diseño de objetos y sus componentes

correspondientes. Las pruebas estructurales encuentran diferencias entre el

modelo del diseño del sistema y un subconjunto de subsistemas integrados mucha

Marco Teórico 10

veces como módulos. Las pruebas funcionales encuentran diferencias entre el

modelo de caso de uso y el sistema a analizar. Las pruebas de desempeño

encuentran diferencias entre los requerimientos no funcionales y el desempeño

real del sistema. (Bernd Bruegge, Allen H. Dutoit, 2002).

CAPÍTULO II

METODOLOGÍA

2.1. Metodología XP

Esta metodología consiste en ayudar a desarrollar sistemas en conjunta

sincronización con el usuario es decir el usuario interviene en casi todas las etapas

del proyecto.

En el análisis de la investigación realizada en su trabajo de titulación “Análisis

y diseño de un sistema para manejo y control de inventarios utilizando tecnología

RFID” realizado por el sr. Constantine Daza Juan Carlos se determinaron los

requisitos funcionales (ver anexo 1) y no funcionales (ver anexo 2).

Los requerimientos funcionales y no funcionales se apoyan en los casos de uso

del trabajo de titulación ya mencionado.

GRÁFICO N° 4

CASO DE USO PARA DESPACHO DE ÍTEMS


Metodología 12

CUADRO N° 1

CASO DE USO 1

Caso de uso Despacho ítems

Actor Principal Bupervisor de bodega/Despachador

Descripción El bodeguero compara ítems de factura

con orden de despacho.

Precondición Factura existe.

Actor Sistema

1. Ingresa al sistema.

2. Ingresa número de factura.

3. Busca número de factura

ingresado.

4. Muestra orden de despacho

correstpondiente a esa factura.

5. Compara los de la orden de

despacho vs a la factura.

6. Selecciona ítems a despachar.

7. Guarda registro.

Curso alterno

3.1. El número de factura no se ha encontrado, el sistema muestra mensaje de

error.

Pos-condición Se ha guardado el registro con éxito


Metodología 13

CUADRO N° 2

CASO DE USO 2

Caso de uso Realizar Inventario

Actor Principal Jefe inventario

Descripción Se realiza el conteo físico y verificación

de cantidades de ítems en el sistema.

Precondición Generar reportes de stock de productos.

Actor Sistema


2. Abre la búsqueda de

productos

3. Busca stock actual de ítems de

bodega.

4. Muestra stock de productos.

5. Imprime reporte de búsqueda.

Curso alterno

3.1 El sistema no encuentra resultados.

Pos-condición Se imprime reporte existencia de ítems.

GRÁFICO N° 5

CASO DE USO PARA CREAR INVENTARIO



Metodología 14

GRÁFICO N° 6

CASO DE USO PARA LA CREACIÓN DE SOLICITUD DE COMPRA

CUADRO N° 3

CASO DE USO 3

Caso de uso Creación de solicitud de compra

Actor Principal Jefe de bodega.

Descripción Se revisa el stock de ítems en el sistema y se

procede a señalar las cantidades a comprar.

Precondición El stock se encuentre en su cantidad mínima.

Actor Sistema


2. Abre el módulo de compra

3. Busca stock actual de ítems existentes.

4. Muestra stock de ítems.

5. Ordena los ítems según

por cantidad.

6. Muestra ítems mostrado en la vista.

7. Selecciona ítems a

compra.

8. Manda a guardar registro.

9. Guarda los cambios.

Curso alterno Que ningún ítem tenga stock mínimo.

Pos-condición Se ha guardado la orden de compra.



Metodología 15

2.2. Requerimientos funcionales

CUADRO N° 4

REQUERIMIENTOS FUNCIONALES

Requisitos funcionales

ID Requisito Descripción Usuario

RF-001

Ingreso de los

Usuarios al sistema a

nivel de roles

El sistema debe reformase para

que exista un módulo en el cual

permita la creación de los roles del

proceso de bodega (inventario,

despacho, jefe de bodega)

Jefe de

Bodega

RF-002

Mostrar Ítems

Facturados por filtro

en factura, ítems, y

orden de despacho

En el sistema actualmente no

permite realizar filtro de ítems por

número de factura, por cantidad

vendida.

Jefe de

Bodega,

Jefe de

Inventarios

RF-003 Informe ordenado y

detalles de despacho

El sistema debe mostrar informe

con fecha de ventas de los ítems,

cantidad, con su respetivo número

de factura, orden despacho y

responsable de despacho

Jefe de

Bodega,

Jefe de

Inventario

RF-004 Integrar el conteo de

ítems de forma ágil

El sistema debe permitir

almacenamiento comentario para

conteo de ítems y agilitar el

proceso de conteo mediante el uso

de hardware

Jefe de

Inventario

RF-005 Ventana detalle de

despacho

El sistema debe integrar una

ventana donde se pueda consultar

los despacho actuales, pendientes

con un sistema de filtros

Supervisor

de bodega


Metodología 16

2.3. Requerimientos no funcionales

Para poder agilitar el conteo, perchado y despacho de los artículos se utilizará

la tecnología RFID, lo cual incluía etiquetas, lectores, impresora Zebra, y un

servidor los cuales son detallados en la CUADRO N° de requisitos no funcionales.

CUADRO N° 5

REQUERIMIENTOS NO FUNCIONALES

Requisitos no funcionales

ID Requisito Descripción Usuario

RNF-

001

Etiquetas RFID (VT-

92), (IQ 400), (IQ

600).

Etiquetas para trabajar

con metales Jefe de Bodega

RNF-

002

Impresora RFID

(VPR-0 207).

Impresora zebra para

escritura etiqueta RFID Jefe de Bodega

RNF-

003

Lector fijo de RFID

(VF-642) Lector RFID fijo Jefe de Bodega

RNF-

004

RFID lector portátil

(VH-70B). Lector RFID de mano Jefe de Bodega

RNF-

005

El sistema de canales

de RFID de lectura

(VC-420) 400 lectores

estáticos

Sistema de ubicación

de Etiquetas y conteo

en tiempo real

Jefe de

Inventario

RNF-

006

Montacargas RFID

sistema (VI-82)

Trabaja con el sistema

de posicionamiento

para identificar donde

se debe colocar el ítems

Jefe de Bodega/

Jefe Inventario

RNF-

007 Servidor

Servidor para montaje

del sistema con DDR 3

32 de RAM bus 1800,

procesador xeom 64

bits 3.2 ghz, Disco 3

TB., monitor, teclado ,

sistema Linux Centos

Jefe de Sistemas.


Metodología 17

2.4. Prototipo

Este prototipo es un modelo del software para ver su funcionamiento, este posee

las características del sistema.

CUADRO N° 6

ESTÁNDARES DE NOMBRES DE COMPONENTES.

Componente Acrónimo Descripción

Vista Vst Se utiliza en el inicio

del nombre de la vista.

outputLabel Lbl Se utiliza en el inicio

del nombre del

componente, en él se

puede mostrar un texto

estático.

inputText Txt Se utiliza en el inicio

del nombre del


ingresa texto.

dataTable Dt Se utiliza en el inicio

del nombre del


muestra de manera

ordenada, detallada,

tabulada.

selectBooleanCheckbox Chk Se utiliza en el inicio

del nombre del

componente, estos

componentes permiten

seleccionar varios

elementos a la vez.

calendar Cl Se utiliza en el inicio

del nombre del


puede escoger fecha

para las transacciones

que se realizan en el

software.

commandButton Cb Se utiliza en el inicio

del nombre del control,

este componente sirve

para poder realizar

alguna acción en la

vista con tan solo clic. Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.

Metodología 18

2.5. Formulario web para ingreso al sistema.

En esta vista nos tenemos que identificar mediante un usuario y contraseña

asignado por el administrador del sistema.

Los usuarios luego de identificarse con las credenciales correspondientes

dependiendo del rol que se le haya asignado ese acuerdo a sus funciones dentro de

la empresa.

2.6. Formulario web para despacho de ítems.

En esta vista podemos ver los ítems a despachar, son los mismos que están en

la factura del cliente.

GRÁFICO N° 7

FORMULARIO WEB DE INGRESO AL SISTEMA

GRÁFICO N° 8

FORMULARIO WEB PARA DESPACHO DE ÍTEMS



Metodología 19

2.7. Formulario web para inventario.

En esta vista podemos registrar el inventario que se realiza de manera física,

para los cual se pueden añadir la lista de producto.

2.8. Formulario web para crear compra.

Luego que la persona encargada de realizar las solicitudes de compra tenga los

ítems a pedir los realiza en esta vista.

En la parte de la fecha se cuenta con un calendario el cual permite escoger una

fecha actual o futura. En la parte de la CUADRO N° aquí se agregan los ítems para

posteriormente se realice la compra, los mismos que se van a incrementar en la

existencia del inventario.

GRÁFICO N° 9

FORMULARIO WEB PARA REALIZAR INVENTARIO

GRÁFICO N° 10

FORMULARIO WEB PARA CREAR UNA COMPRA



Metodología 20

2.9. Formulario web para buscar compra.

En esta vista nos permite ver las solicitudes de compras guardadas y las

solicitudes de compras vigentes.

Se puede buscar por intervalo de fecha, por nombre del producto, además

también se puede guardar la búsqueda.

GRÁFICO N° 11

FORMULARIO WEB PARA BUSCAR COMPRAS


CAPÍTULO III

PROPUESTA

3.1. Entorno del software

GRÁFICO N° 12

FUNCIONAMIENTO DEL SISTEMA

Propuesta 22

En este desarrollo se usa el framework de Spring y Spring security para las

reglas de navegación.

En las reglas de navegación de spring security para asignar permisos a los roles

de usuarios, es decir a las vistas que cada usuario del sistema tiene acceso.

Spring security se apoya netamente en los cronjobs ya que ellos se encargan de

tener a los usuarios consultados en la base de datos para luego dar acceso a los

diferentes módulos permitidos dependiendo del rol que se le haya asignado.

Para la navegación de los usuarios necesitamos crear los roles de usuario esto

se realiza en el archivo deploy manager de spring security:

GRÁFICO N° 13

ARCHIVO DEPLOY MANAGER DE SPRING SECURITY

Spring es el contenedor de todas las funcionalidades del sistema apoyado con

el desarrollo entre capas utilizando el modelo MVC (modelo, vista, control),

trabajando en conjunto con Jpa y Hibernate.


Propuesta 23

En la capa de modelo empleamos tecnologías de persistencia (framework ORM

JPA - HIBERNATE); estos objetos tienen clases que funcionan con el api de criteria

que ya están incluidos en los ORM ya mencionados (JPA - HIRBERNATE), que

en si ya incluyen los métodos ADO (delete, update, select, insert).

En la capa de control se llevan las reglas de negocio, reglas de acceso, reglas de

almacenamiento; interactúa entre el modelo y la vista.

La capa de vista es la representación, interacción entre usuario y programa, esta

capa depende de las reglas que contenga el control.

En la capa de vista es la que interactúa con el usuario final es decir es la parte

donde el usuario realiza todas las transacciones que tiene el software. Esta capa

utiliza la tecnología de JAVA SCRIPIT, JSF, HTML.

Con los CDI (Context Dependency Injection) es el mecanismo para resolver

dependencias.

Con CDI podemos "declarar" cualquier bean y un punto de inyección sobre el

cual se realizará la inyección del mismo cuando se requiera.

3.2. Diagrama de componentes

Este diagrama permite ver los componentes que integran el sistema. En este

sistema usamos:

Primefaces: Es un framework de desarrollo para vistas utiliza java script,

jsf (java server faces), html.

Jpa: Es un modelo de persistencia que nos permite mapear la base de datos.

Hibernate: Es un framework de persistencia que nos permite administrar

de mejor manera la carga transaccional, es decir las conexiones y consultas

que realiaza a la base de datos.

Propuesta 24

Fu

en

te:

Ela

boració

n p

rop

ia.

Ela

bora

do

po

r:

Moreir

a C

hu

qu

ima

rca J

ose

ph

An

ton

io.

En la persistencia de datos utilizamos JPA para mapear la base de datos y

hibernate para manejar la carga transaccional.

GRÁFICO N° 14

DIAGRAMA DE COMPONENTES

Propuesta 25

3.3. Diagrama de despliegue.

Este diagrama nos permite conocer de manera macro como está estructurada la

aplicación.

3.4. Anotaciones

CUADRO N° 7

ANOTACIONES

Anotación Uso

@Local Indica que la interfaz es local.

@Remote Indica que la interfaz es remota.

@Dependent Es la anotación por defecto que indica que su ámbito

depende del bean en el que se inyecte.

@RequestScoped El bean permanece durante la petición HTTP y es

destruido al final.

@SessionScoped El bean es compartido por todas las peticiones HTTP

que pertenecen a la misma sesión.

@ApplicationScoped El bean es creado en el arranque de la aplicación y

destruido cuando la aplicación se detiene.

@ConversationScoped Se puede mantener una instancia del mismo bean

durante varias peticiones HTTP, demarcando el

ámbito de inicio y fin de la transacción.

@Singleton Se mantiene una instancia única del vean.

@Inject Se usa para inyectar POJOS, además se lo puede

utilizar de igual manera para inyectar EJBs.

@Entity Indica que es un Bean de Entidad.


GRÁFICO N° 15

DIAGRAMA DE DESPLIEGUE


Propuesta 26

3.5. Diseño de la base de datos

GRÁFICO N° 16

MODELO ENTIDAD RELACIÓN


Propuesta 27

3.6. Diccionario de datos

CUADRO N° 8

DICCIONARIO DE DATOS TBL_CLIENTE


DICCIONARIO DE DATOS Página 1 de 20

PROYECTO INTEGRANTES: MODULO DE:

CUADRO N°:

tbl_cliente

TIPO

CUADRO N°:

Mantenimiento

LONGITUD

DEL

REGISTRO:

DESCRIPCIÓN: Donde se los datos de los clientes.

DESCRIPCIÓN DEL REGISTRO

N

o.

NOMBRE

DEL

CAMPO

DEFINICIÓN TI

PO

SEC FOR

M

LO

NG

NULL

1 id_cliente Id de cliente. PK A I No

2 fld_ruc_ced Ruc o cedula del

cliente.

E M VC 15

3 fld_nombre Nombre del cliente. E M VC 17

4 fld_telefono Teléfono del

cliente.

E M VC 23

5 fld_direccio

n

Dirección del

cliente

E M VC 35

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

E Elemento de

dato

SECUENCIA

A

AUTOMATIC

A

M MANUAL

FORMAT

O

NUMERI

CO

I Integer

F Float

FORMATO

CARACTER

C Char

VC Varchar

FORMATO

FECHA

D Date

DT

DateTime

Propuesta 28

CUADRO N° 9

DICCIONARIO DE DATOS TBL_TIPO_PERSONA


DICCIONARIO DE

DATOS

Página 2 de 20

Fecha de elaboración:

dd/mm/aaaa

PROYEC

T

INTEGRANTES MODULO DE:

CUADRO N°:

tbl_tipo_persona

TIPO

CUADRO

N°:

Mantenimie

nto

LONGITUD DEL

REGISTRO:

DESCRIPCIÓN: Donde se registra el tipo de persona ya sea persona natural o

empresa.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN TIP

O

SE

C

FOR

M

LON

G

NULL

1 Id_tipo_pers

ona

Id de ingreso de

mercadería.

PK A I No

2 fl_nombre Fecha en la que

ingreso la

mercadería.

E M VC 12 No

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

E Elemento

SECUENCIA

A

AUTOMATIC

A

M MANUAL

FORMA

TO

NUMERI

C

I Integer

F Float

FORMAT

O

CARACTE

R

C Char

VC Varchar

FORMATO

FECHA

DT DateTime

Propuesta 29

CUADRO N° 10

DICCIONARIO DE DATOS TBL_FACTURA


DICCIONARIO DE

DATOS

Página 3 de 20



CUADRO N°:

tbl_factura

TIPO CUADRO

N°:

Mantenimiento

LONGDEL

REGISTRO

DESCRIPCIÓN: Donde se registra las ventas realizadas.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN TIP

O

SE

C

FOR

M

L

O

N

G

NULL

1 id_factura Id de la factura. PK A I No

2 fld_numero Número de la

factura.

E M VC 25

6

No

3 fld_fecha Fecha de emisión

de la factura.

E M DT No

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

E Elemento de

dato

SECUENCIA

A

AUTOMATIC

A

M MANUAL

FORMATO

NUMERICO

I Integer

F Float

FORMAT

O

CARACT

ER

C Char

VC

Varchar

FORMAT

O FECHA

D Date

DT

DateTime

Propuesta 30

CUADRO N° 11

DICCIONARIO DE DATOS TBL_TIPO_PAGO


DICCIONARIO

DE DATOS

Página 4 de 20


dd/mm/aaaa


CUADRO N°:

tbl_tipo_pago

TIPO CUADRO

N°:

Mantenimiento

LONGITUD

DEL

REGISTRO:

DESCRIPCIÓN: Donde se registra el tipo de pago.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN TIP

O

SE

C

FOR

M

LON

G

NUL

L

1 id_tipo_pago Id de tipo de pago. PK A I No

2 fld_nombre Nombre de tipo de

pago.

E M VC 45 No

3 fld_descripcio

n

Descripción de los

tipos de pagos:

Efectivo.

Cheque.

Tarjeta de

crédito.

E M VC 46 No

OBSERVACIÓN:

TIPO

PK Clave Primaria

FK Clave Foránea

E Elemento de

dato

SECUENCI

A

A

AUTOMATI

CA

M MANUAL

FORMATO

NUMERIC

O

I Integer

F Float

FORMATO

CARACTER

C Char

VC Varchar

FORMA

TO

FECHA

D Date

DT

DateTime

Propuesta 31

CUADRO N° 12

DICCIONARIO DE DATOS TBL_VENDEDOR



Fecha de

elaboración:

dd/mm/aaaa


CUADRO N°:

tbl_vendedor

TIPO CUADRO

N°:

Mantenimiento

LONGITUD

DEL

REGISTRO:

DESCRIPCIÓN: Donde se registran los datos del vendedor.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN TIP

O

SEC FOR

M

LON

G

NU

LL

1 id_vendedo

r

Id del vendedor. PK A I No

2 fld_nombre Nombre del vendedor. E M VC 45 No

3 fld_cod_ve

ndedor

Código asignado al

vendedor.

E M VC 5 No

4 fld_cedula Número de cédula del

vendedor.

E M VC 10 No

5 fld_direcci

on

Dirección del

vendedor.

E M VC 250

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

SECUENCIA

A

AUTOMATIC

M MANUAL

FORMATN

UMERIC

I Integer

F Float

FORMAT

CARACTE

C Char

VC Varchar

FORMATO

FECHA

D Date

DT

DateTime

Propuesta 32

CUADRO N° 13

DICCIONARIO DE DATOS TBL_ORDEN_DESPACHO


DICCIONARIO DE

DATOS

Página 6 de 20


dd/mm/aaaa


CUADRO N°:

tbl_orden_despacho

TIPO CUADRO

N°:

Mantenimiento

LONGITUD

DEL

REGISTRO:

DESCRIPCIÓN: Donde se registra las órdenes de despacho después de generarse

la factura.


No. NOMBR

E DEL

CAMPO

DEFINICIÓN TIP

O

SEC FOR

M

LON

G

NUL

L

1 id_orden_

despacho

Id orden de despacho. PK A I No

2 fld_codig

o_desp

Código de despacho. E M VC 100 No

3 fld_fecha Fecha en la que se

genera la orden de

despacho.

E M DT No

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

E Elemento

de dato

SECUENCI

A

A

AUTOMAT

ICA

M

MANUAL

FORMATO

NUMERIC

O

I Integer

F Float

FORMAT

O

CARACT

ER

C Char

VC

Varchar

FORMATO

FECHA

D Date

DT DateTime

Propuesta 33

CUADRO N° 14

DICCIONARIO DE DATOS TBL_ESTADO_VENTA


DICCIONARIO DE

DATOS

Página 7 de 20



CUADRO N°:

tbl_estado_venta

TIPO CUADRO

N°:

Mantenimiento

LONGITUD

DEL

REGISTRO:

DESCRIPCIÓN: Donde se registra las órdenes de despacho después de generarse

la factura.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN TIP

O

SE

C

FOR

M

LON

G

NULL

1 id_estado Id del estado de la

venta.

PK A I No

2 fld_nombre Nombre del estado

de la venta.

E M VC 20 No

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

SECUENCIA

A

AUTOMATIC

A

M MANUAL

FORMATO

NUMERICO

I Integer

F Float

FORMATO

CARACTE

R

C Char

VC Varchar

FORMA

TO

FECHA

DT

DateTime

Propuesta 34

CUADRO N° 15

DICCIONARIO DE DATOS TBL_PRODUCTO


DICCIONARIO

DE DATOS

Página 8 de 20

PROYECT INTEGRANTES: MODULO DE:

CUADRO

N°:

tbl_producto

TIPO

CUAD

RO

N°:

Manten

imiento

LONGIT

UD DEL

REGIST

RO:

DESCRIPCIÓN: Donde se registra los productos de la

bodega.


N

o.

NOMB

RE

DEL

CAMP

O

DEFINICIÓ

N

TI

P

O

S

E

C

FO

R

M

L

O

N

G

NULL

1 id_prod

ucto

Id del

producto.

P

K

A I No

2 fld_cod

_barra

Código de

barra del

producto.

E M VC 20 No

3 fld_cod

_rfid

Código de

identificación

para asignar

a los tag

RFID.

E M VC 15

0

No

4 fld_cod

igo_int

er

Código

interno para

control de

bodega.

E M VC 10

0

No

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

E Elemento de

SECUE

NCIA

A AUTOM

ATICA

FORMAT

O

NUMERI

CO

I Integer

F Float

FOR

MAT

O

CARA

CTER

C Char

FORM

ATO

FECHA

D Date

DT DateTi

me

Propuesta 35

CUADRO N° 16

DICCIONARIO DE DATOS TBL_BODEGA_PRODUCTO


DICCIONARIO DE

DATOS

Página 9 de 20


dd/mm/aaaa


CUADRO N°:

tbl_bodega_producto TIPO

CUADRO N°:

Mantenimiento

LONGITUD

DEL

REGISTRO:

DESCRIPCIÓN: Donde se registra en que bodega está asignado ese producto.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN TI

PO

SE

C

FO

RM

LO

NG

NULL

1 id_nn_bodeg

a_producto

Id del producto en

la bodega.

PK A I No

2 fld_cantidad Cantidad de

existencia del

producto en la

bodega.

E M I No

3 fld_cantidad_

minima_bod

Cantidad mínima

de existencia del

producto en la

bodega.

E M I No

4 fld_activo Estado del

producto:

Activo.

Inactivo.

E M I 100 No

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave Foránea

E Elemento de

dato

SECUENCI

A

A AUTOMATI

CA

M MANUAL

FORMA

TO

NUMER

ICO

I Integer

F Float

FORMAT

O

CARACT

ER

C Char

VC Varchar

FORMATO

FECHA

D Date

DT DateTime

Propuesta 36

CUADRO N° 17

DICCIONARIO DE DATOS TBL_COMPRAS


DICCIONARIO DE

DATOS

Página 10 de 20


dd/mm/aaaa


CUADRO N°:

tbl_compras

TIPO

CUADRO N°:

Mantenimiento

LONGITUD

DEL

REGISTRO:

DESCRIPCIÓN: Donde se registra las compras de los ítems de bodega.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN T SE

C

FO

RM

LO

NG

NUL

L

1 Id_compras Id de la compra. P

K

A I No

2 fld_date Fecha en la que se realiza

la compra.

E M DT No

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

E Elemento de

dato

SECUENCI

A

A

AUTOMAT

M

MANUAL

FORMAT

O

NUMERI

C

I Integer

F Float

FORMAT

O

CARACT

C Char

VC

Varchar

FORMATO

FECHA

D Date

DT DateTime

Propuesta 37

CUADRO N° 18

DICCIONARIO DE DATOS TBL_MARCA




dd/mm/aaaa

PROYEC

TO

INTEGRANTES: MODULO DE:

CUADRO N°:

tbl_marca

TIPO

CUADRO

N°:

Mantenimient

o

LONGITUD

DEL

REGISTRO:

DESCRIPCIÓN: Donde se registra las marcas de los productos.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN TI

PO

SE

C

FOR

M

LO

NG

NULL

1 Id_marca_p

roducto

Id de la marca del

producto.

PK A I No

2 fld_nombre Nombre de la

marca del

producto.

E M VC 50 No

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

SECUENCI

A

A

AUTOMAT

ICA

FORMAT

O

NUMERI

CO

I Integer

FORMA

TO

CARAC

TER

C Char

FORMATO

FECHA

D Date

DT DateTime

Propuesta 38

CUADRO N° 19

DICCIONARIO DE DATOS TBL_ORIGEN_PROD




dd/mm/aaaa


CUADRO N°:

tbl_origen_prod

TIPO

CUADRO

N°:

Mantenimi

ento

LONGITUD

DEL

REGISTRO:

DESCRIPCIÓN: Donde se registra el origen del producto.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN TI

PO

SE

C

FO

RM

LO

NG

NULL

1 id_origen Id de origen

del producto.

PK A I No

2 Fld_origen Nombre del

origen del

sistema.

E M VC 25 No

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

E Elemento de

dato

SECUENCI

A

A

AUTOMATI

CA

M

MANUAL

FORMA

TO

NUMER

ICO

I Integer

F Float

FORMA

TO

CARAC

TER

C Char

VC

Varchar

FORMATO

FECHA

D Date

DT DateTime

Propuesta 39

CUADRO N° 20

DICCIONARIO DE DATOS TBL_CATEGORIA_PRODUCTO


DICCIONARIO DE

DATOS

Página 13 de 20


dd/mm/aaaa

PROYECT

O


CUADRO N°:

tbl_categoria_pro

ducto

TIPO

CUADRO

N°:

Mantenimi

ento

LONGITUD

DEL

REGISTRO:

DESCRIPCIÓN: Donde se registra el origen del producto.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN TI

PO

SE

C

FO

RM

LO

NG

NULL

1 id_categori

a_producto

Id de la categoría

del producto.

PK A I No

2 fld_nombr

e_cat

Nombre de la

categoría del

producto.

E M VC 28 No

3 fld_descrip

cion

Descripción de la

categoría del

producto.

E M VC 100

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

E Elemento de

dato

SECUENCI

A

A

AUTOMATI

CA

M

MANUAL

FORMA

TO

NUMER

ICO

I Integer

F Float

FORMAT

O

CARACT

ER

C Char

VC

Varchar

FORMATO

FECHA

D Date

DT DateTime

Propuesta 40

CUADRO N° 21

DICCIONARIO DE DATOS TBL_INVENTARIO


DICCIONARIO

DE DATOS

Página 14 de 20


dd/mm/aaaa

PROYE

CTO


CUADRO

N°:

tbl_inventari

TIPO

CUADRO

N°:

Mantenimient

o

LONGITU

D DEL

REGISTR

O:

DESCRIPCIÓN: Donde se registra el inventario realizado en la bodega.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN TI

PO

SE

C

FO

RM

LO

NG

NULL

1 id_inventario Id del

inventario.

PK A I No

2 fld_fecha Fecha en la que

se realizó el

inventario.

E M DT No

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave Foránea

E Elemento de

dato

SECUENC

I

AUTOMA

TICA

M

MANUAL

FORMAT

O

NUMERI

CO

I Integer

F Float

FORMAT

O

CARACT

ER

C Char

VC

Varchar

FORMATO

FECHA

D Date

DT DateTime

Propuesta 41

CUADRO N° 22

DICCIONARIO DE DATOS TBL_BODEGA




dd/mm/aaaa


CUADRO N°:

tbl_bodega

TIPO

CUADRO

N°:

Mantenim

LONGITUD

DEL

REGISTRO:

DESCRIPCIÓN: Donde se registra los datos de la bodega.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN TI

PO

SE

C

FO

RM

LO

NG

NULL

1 id_bodega Id de la bodega. PK A I No

2 fld_nombr

e

Nombre de la

bodega.

E M VC 100 No

3 fld_telefon

o

Teléfono de la

bodega.

E M VC 15 No

4 fld_direcci

on

Dirección de

ubicación de la

bodega.

E M VC 120 No

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

E Elemento de

dato

SECUENCI

A

A

AUTOMATI

CA

M

MANUAL

FORMA

TO

NUMER

ICO

I Integer

F Float

FORMAT

O

CARACT

ER

C Char

VC

Varchar

FORMATO

FECHA

D Date

DT DateTime

Propuesta 42

CUADRO N° 23

DICCIONARIO DE DATOS TBL_PROVEEDOR


DICCIONARIO DE

DATOS

Página 16 de 20


dd/mm/aaaa

PROYE

CTO


CUADRO

N°:

tbl_proveed

TIPO

CUADRO

N°:

Mantenimi

LONGITUD

DEL

REGISTRO:

DESCRIPCIÓN: Donde se registra los datos de la bodega.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN TI

PO

SE

C

FO

RM

LO

NG

NULL

1 id_proveed

or

Id del proveedor. PK A I No

2 fld_nombr

e

Nombre del

proveedor.

E M VC 35 No

3 fld_telefon

o

Teléfono del

proveedor.

E M VC 35 No

4 fld_direcci

on

Dirección de

ubicación del

proveedor.

E M VC 100 No

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

E Elemento de

dato

SECUENCI

A

AUTOMATI

CA

M

MANUAL

FORMAT

O

NUMERI

CO

I Integer

F Float

FORMAT

O

CARACT

ER

C Char

VC

Varchar

FORMATO

FECHA

D Date

DT DateTime

Propuesta 43

CUADRO N° 24

DICCIONARIO DE DATOS TBL_USER


DICCIONARIO DE

DATOS

Página 17 de 20

Fecha de elaboración: dd/mm/aaaa


CUADRO

N°: tbl_user TIPO

CUADRO N°:

Mantenimiento

LONGITUD

DEL

REGISTRO

DESCRIPCIÓN: Donde se registran los usuarios.


N

o

.

NOMBRE

DEL CAMPO

DEFINICIÓN TI

PO

SE

C

FO

RM

LO

NG

NUL

L

1 acount_id Id del usuario. PK A I No

2 Login Nick del usuario. E M VC 255 No

3 password Contraseña del

usuario.

E M VC 255 No

4 Email Correo electrónico

del usuario.

E M VC 255 No

5 Enabled Estado:

Activo.

Inactivo.

E M B No

6 fld_fecha_creac

on

Fecha de creación de

usuario

E M DT No

7 fld_identificativ

o

Identificativo del

usuario.

E M VC 22 No

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave Foránea

E Elemento de

dato

SECUENCI

A

A AUTOMATI

CA

M MANUAL

FORMA

TONUM

ERI

I Integer

F Float

FORMA

TCARA

CTE

C Char

VC Varchar

FORMATO

FECHA

DT DateTime

Propuesta 44

CUADRO N° 25

DICCIONARIO DE DATOS TBL_ROLES


DICCIONARIO DE

DATOS

Página 18 de 20


dd/mm/aaaa

PROYECT

O

INTEGRANTES:

MODULO DE:

CUADRO N°:

tbl_roles

TIPO

CUADRO

N°:

Mantenimie

nto

LONGITUD

DEL

REGISTRO:

DESCRIPCIÓN: Donde se registra el rol del usuario.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN TI

PO

SE

C

FO

RM

LO

NG

NULL

1 role_id Id de los roles

de usuarios.

PK A I No

2 name_local

e

Nombre del rol

de usuario.

E M VC 255

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

E Elemento de

dato

SECUENCI

A

A

AUTOMATI

CA

M

MANUAL

FORMAT

O

NUMERIC

O

I Integer

F Float

FORMA

TO

CARAC

TER

C Char

VC

Varchar

FORMATO

FECHA

D Date

DT DateTime

Propuesta 45

CUADRO N° 26

DICCIONARIO DE DATOS TBL_PERMISOS


DICCIONARIO DE

DATOS

Página 19 de 20


dd/mm/aaaa

PROYE

CTO


CUADRO

N°:

tbl_permisos

TIPO

CUADRO

N°:

Mantenimient

LONGITU

D DEL

REGISTRO

:

DESCRIPCIÓN: Donde se registra los permisos de acceso de los usuarios.


N

o.

NOMBR

E DEL

CAMPO

DEFINICIÓN TIP

O

SE

C

FOR

M

LON

G

NULL

1 fld_permi

sos

Id de los permisos de

los roles de usuario.

PK A I No

2 fld_ruta Módulos a los cuales el

usuario tiene acceso.

E M VC 255 No

3 fld_descri

pc

io

n

Descripción del

permiso de roles de

usuario.

E M VC 50

OBSERVACIÓN:

TIPO

PK Clave

Primaria

FK Clave

Foránea

E Elemento

dato

SECUENCIA

A

AUTOMATIC

A

M MANUAL

FORMAT

O

NUMERI

CO

I Integer

F Float

FORMAT

O

CARACT

ER

C Char

VC

Varchar

FORMATO FECHA

D Date

DT DateTime

Propuesta 46

CUADRO N° 27

DICCIONARIO TBL_TIPO_PERMISO


DICCIONARIO DE

DATOS

Página 20 de 20


dd/mm/aaaa

PROYEC

TO


CUADRO N°:

tbl_tipo_permiso

TIPO

CUADRO

N°:

Mantenimie

nto

LONGITUD DEL

REGISTRO:

DESCRIPCIÓN: Donde se registra el tipo de permiso que posee el sistema.


No. NOMBRE

DEL

CAMPO

DEFINICIÓN TIP

O

SE

C

FOR

M

LO

NG

NULL

1 fld_id_tipo_p

ermiso

Id del tipo de

permiso.

PK A I No

2 fld_nombre Nombre del

permiso.

E M VC 100 No

3 fld_descripci

on

Descripción del

permiso.

E M VC 100

OBSERVACIÓN:

TIPO

PK Clave Primaria

FK Clave Foránea

E Elemento de

dato

SECUENCIA

A

AUTOMATICA

M MANUAL

FORMAT

O

NUMERI

C

I Integer

F Float

FORMAT

O

CARAC

VC

Varchar

FORMATO

FECHA

D Date

DT DateTime

Propuesta 47

3.7. Diagrama de paquetes del sistema de bodega

Es la representación de cómo esta lógicamente el programa.

3.8. Pruebas unitarias

Las pruebas unitarias se realizan a cada módulo del sistema con la finalidad de

comprobar el correcto funcionamiento de cada módulo por separado. Las pruebas

unitarias en todos los casos se la realizaron realizando pruebas de ingresos de todos

erróneos y observando la respuesta del sistema.

GRÁFICO N° 18

Prueba unitaria

Fuente: Elaboración propia.

Elaborado por: Moreira Chuquimarca Joseph Antonio.

GRÁFICO N° 17

DIAGRAMA DE PAQUETES DEL SISTEMA DE BODEGA


Propuesta 48

CUADRO N° 28

PRUEBA UNITARIA VISTA INGRESO AL SISTEMA

COMPONENTE: Vista para ingreso al sistema.

FECHA: 08/07/2014

OBSERVACIONES El campo de la contraseña permite ingresar caracteres infinitos.

SOLUCIONES:

Se recomienda poner una cantidad específica de caracteres en el

password. Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.

CUADRO N° 29

PRUEBA UNITARIA VISTA DESPACHO DE ÍTEMS

COMPONENTE: Formulario web para despacho de ítems

FECHA: 08/07/2014

OBSERVACIONES: Todos los datos y los test se realizaron con éxito.

SOLUCIONES: Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.

CUADRO N° 30

PRUEBA UNITARIA VISTA INVENTARIOS

COMPONENTE: Formulario web para realizar inventario

FECHA: 08/07/2014

OBSERVACIONES: Todos los datos y los test se realizaron con éxito.


CUADRO N° 31

PRUEBA UNITARIA VISTA CREAR COMPRA

COMPONENTE: Formulario web para crear una compra

FECHA: 08/07/2014

OBSERVACIONES Todos los datos y los test se realizaron con éxito.


Propuesta 49

CUADRO N° 32

PRUEBA UNITARIA VISTA BUSCAR COMPRA

COMPONENTE: Formulario web para buscar compras

FECHA:

OBSERVACIONES Todos los datos y los test se realizaron con éxito.


3.9. Prueba de integración del prototipo.

Al prototipo creado para esta propuesta se le realice las pruebas de integración

las cuales arrojaron los siguientes gráficos:


La prueba de integración en la que se mide el consumo de memoria se la realizo

con 25 clientes conectados al sistema enviado una carga transaccional de 30 MB en

la GRÁFICO N° 19 notamos que el consumo mínimo fue de 114MB y el máximo

fue 100MB.

GRÁFICO N° 19

CONSUMO DE MEMORIA DEL PROTOTIPO

Propuesta 50


El prototipo consume alrededor de un 30% a 45% en el servidor con una carga

transaccional de 25 clientes enviando 30MB transaccional. (Ver GRÁFICO N°

20)

GRÁFICO N° 20

CONSUMO DEL PROCESADOR POR PARTE DEL PROTOTIPO

GRÁFICO N° 20

Consumo del procesador por parte del prototipo

GRÁFICO N° 21

CONSUMO ENTRE JAVA JDBC Y BASE DE DATOS A ORM

HIBERNATE

GRÁFICO N° 21

Consumo entre java JDBC y base de datos a orm Hibernate


Propuesta 51

El consume de transacionalidad de los datos es bastante elevado se puede

mejorar simplificando los query utilizados en Hibernate este medida se la realizo

con 25 clientes realizando transacciones con peso de 30 MB. (Ver GRÁFICO N°

21).

El empleo de Postgresql como base de datos podemos ver el tiempo de respuesta

notable, la prueba se la realizo con 25 clientes enviando una carga transaccional de

30MB (ver GRÁFICO N° 22).

3.10. Plan de capacitación

CUADRO N° 33

CRONOGRAMA DE CAPACITACIÓN

Módulo Personal capacitado Tiempo Personas capacitadas

Inventarios Bodegueros

1 hora diaria

por 3 días.

José Luis Pincay

Supervisor de bodega

Ing. Juan Carlos

Lavalle

Crear compras Jefe de bodega

1 hora diaria

por 3 días. Ing. Carlos Llanos

1 hora diaria

por 3 días.

Ing. Carlos Llanos


GRÁFICO N° 22

CONSUMO POR MINUTO DEL SQL EN POSTGRESQL

GRÁFICO N° 22

Consumo por minuto del SQL en Postgresql


Propuesta 52

3.11. Costo de desarrollo del proyecto

Los costos aproximados del proyecto en su implementación se basan en las

proformas consultadas.

CUADRO N° 34

COSTOS DEL PROYECTO

Cantidad Descripción Costo Total

1200 1200 etiquetas RFID 845

3 Lectores RFID de mano 1234

2 Lectores fijos RFID largo alcance 1200

1 Impresora Zebra RFID todos tipos de etiquetas 2000

4 Desarrolladores 3200

1 Costo de Instalación 1000

1 Costo servidor 1356


C

3.12. Conclusiones: En el área de bodega y despacho existen problemas

comunes como los mencionados en el plan de investigación de este trabajo. Pero se

ha realizado el análisis de una tecnología llamada RFID que en apoyo con un

software permitió reducir en gran parte la incidencia de los problemas suscitados,

además permitió mejorar considerablemente los costos y la rotación del inventario,

ya que conociendo el stock actual se puede realizar un pedido más preciso en cuanto

a la mercadería con mayor rotación.

3.13. Recomendaciones: Se recomienda replicar el uso de la tecnología RFID

en empresas con similares inconvenientes en el área de despacho, logística.;

aunque la implementación de la tecnología RFID tiene costos elevados es factible

porque también disminuye de manera considerable las pérdidas económicas

ocasionadas por los inconvenientes ya mencionados con anterioridad.

53

GLOSARIO DE TÉRMINOS

Backscatter: Retrodisperción, usado para comunicación entre componentes

electrónicos.

BarTender: Software para la impresión de etiquetas.

Centimétricas: Similares a las ondas decimétricas estas permiten reflejarse

fácilmente sobre obstáculos de mayor interruptor de ondas de radiofrecuencia.

Decamétricas: Onda de radiofrecuencia usada en la transmisión de radios

convencionales.

Decimétricas: Similares a las ondas decamétricas estas permiten reflejarse

fácilmente sobre obstáculos de algunos metros de dimensión.

Decimilimétricas: Pertenece a la ondas milimétricas, esta oda tiene mayor alcance

al momento de reflejarse en obstáculos interruptores de ondas de radiofrecuencia.

Deploy manager: Tiene como objetivo planificar, controlar el movimiento de

varios componentes de un software.

EPCglobal: EPCglobal es una organización que lidera el desarrollo de estándares

de la industria impulsados por las normas del Código Electrónico de Producto.

Front-end: Es la parte del que interactúa con el o los usuarios.

Hectométricas: Onda de radiofrecuencia terrestre.

Miriamétricas: Propagación de las ondas kilométricas, Miriamétricas y más largas

en la ionosfera y a través de ella.

Senatel: Superintendencia de Telecomunicaciones del Ecuador.

54

BIBLIOGRAFÍA

Aleksa Vukotic, James Goodwil (2011), Apache Tomcat 7, Introduction to

Apache Tomcat 7, pág. 1.

Arun Gupta (2012), Java EE 6 Pocket Guide pág. 1 cap.1.

Bernd Bruegge, Allen H. Dutoit, 2002, Ingeniería del software orientado a

objetos, pag.327.

Craig Walls (2011), Spring in Action 3th edition, about this book pág. XIX.

Conatel, Senatel. (2012)

http://www.arcotel.gob.ec/wpcontent/uploads/downloads/2013/07/plan_nacio

nal_frecuencias_2012.pdf.

Departamento de Electrónica y Telecomunicaciones Universidad Central

¨Marta Abreu¨ de Las Villas 2011 Articulo: Análisis mediante simulación de

mecanismos de control de acceso al medio para redes RFID.

Edward crookshanks (2014), practical software development techniques, pág.

98.

Finkenzeller, K. (2010), RFID Handbook: Fundamentals and Applications in

Contactless Smart Cards, Radio Frequency Identification and Near-Field

Communication, 3rd Edition, John Wiley & Sons.

Frederick S. Hillier Gerald 2010 libro: Introducción a la investigación de

operaciones 9na edición Tema: teoría de Inventarios Pág. 830

Garfinkel, S., and Holtzman, H. (2006), Understanding RFID technology, in

RFID Applications, Security and Privacy, Eds: Garfinkel, S., and Rosenberg,

B., Addison Wesley.

Giulio Zambon (2012), Beginning JSP, JSF and Tomcat, Introducing JSP AND

Tomcat, cap. 1, pág. 2.

Hamdy A. Taha 2012 Libro. Investigación de Operaciones 9na edición Pag.

457)

Jeff Linwood, Dave minter, Beginning Hibernate 2nd edition, Introduction pág.

XVIII.

http://www.arcotel.gob.ec/wpcontent/uploads/downloads/2013/07/plan_nacional_frecuencias_2012.pdf

http://www.arcotel.gob.ec/wpcontent/uploads/downloads/2013/07/plan_nacional_frecuencias_2012.pdf

55

Joshue O Connor (2012), Pro Html5 Accessibility, Introduction to html5

Accessibility, cap1, pág 1.

Loft media publishing (2010), RFID Tag catalogue international.

Roberti, M. (2004), The History of RFID Technology,

http://www.rfidjournal.com/article/articleview/1338/1/129 .

Revista Inge Cuc, Vol. 9, N° 2, pp 11-20, Diciembre, 2013 Colombia título

RFID - EPC Código Electrónico de Producto como Herramienta de Control de

Merma.

Richard B. Chase 2014 libro: Administración de operaciones producción y

cadena de suministros 13ª edición Pág. 558.

Ruhanen, A. et al. (2008), Sensor-enabled RFID Tag Handbook,

http://www.bridgeproject.eu/data/File/BRIDGE_WP01_RFID_tag_handbook.

pdf

http://www.rfidjournal.com/article/articleview/1338/1/129

http://www.bridgeproject.eu/data/File/BRIDGE_WP01_RFID_tag_handbook.pdf

http://www.bridgeproject.eu/data/File/BRIDGE_WP01_RFID_tag_handbook.pdf

UNIVERSDAD DE GUAYAQUIL FACULTAD DE INGENIERIA...

Documents

Transcript of UNIVERSDAD DE GUAYAQUIL FACULTAD DE INGENIERIA...