universdad de guayaquil facultad de ingenieria...
TRANSCRIPT
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
N° Descripción Pág.
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
N° Descripción Pág.
2.1 Metodología XP 11
VI
N° Descripción Pág.
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
N° Descripción Pág.
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
N° Descripción Pág.
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
N° Descripción Pág.
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
N° Descripción Pág.
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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
1. Ingresa al 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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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
1. Ingresa al 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.
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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.
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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
componente, en él se
ingresa texto.
dataTable Dt Se utiliza en el inicio
del nombre del
componente, en él se
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
componente, en él se
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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.
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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.
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
GRÁFICO N° 15
DIAGRAMA DE DESPLIEGUE
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
Propuesta 26
3.5. Diseño de la base de datos
GRÁFICO N° 16
MODELO ENTIDAD RELACIÓN
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
Propuesta 27
3.6. Diccionario de datos
CUADRO N° 8
DICCIONARIO DE DATOS TBL_CLIENTE
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE
DATOS
Página 3 de 20
Fecha de elaboración:
PROYECTO INTEGRANTES: MODULO DE:
CUADRO N°:
tbl_factura
TIPO CUADRO
N°:
Mantenimiento
LONGDEL
REGISTRO
DESCRIPCIÓN: Donde se registra las ventas realizadas.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO
DE DATOS
Página 4 de 20
Fecha de elaboración:
dd/mm/aaaa
PROYECTO INTEGRANTES: MODULO DE:
CUADRO N°:
tbl_tipo_pago
TIPO CUADRO
N°:
Mantenimiento
LONGITUD
DEL
REGISTRO:
DESCRIPCIÓN: Donde se registra el tipo de pago.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE DATOS Página 5 de 20
Fecha de
elaboración:
dd/mm/aaaa
PROYECTO INTEGRANTES: MODULO DE:
CUADRO N°:
tbl_vendedor
TIPO CUADRO
N°:
Mantenimiento
LONGITUD
DEL
REGISTRO:
DESCRIPCIÓN: Donde se registran los datos del vendedor.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE
DATOS
Página 6 de 20
Fecha de elaboración:
dd/mm/aaaa
PROYECTO INTEGRANTES: MODULO DE:
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.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE
DATOS
Página 7 de 20
Fecha de elaboración:
PROYECTO INTEGRANTES: MODULO DE:
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.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE
DATOS
Página 9 de 20
Fecha de elaboración:
dd/mm/aaaa
PROYECTO INTEGRANTES: MODULO DE:
CUADRO N°:
tbl_bodega_producto TIPO
CUADRO N°:
Mantenimiento
LONGITUD
DEL
REGISTRO:
DESCRIPCIÓN: Donde se registra en que bodega está asignado ese producto.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE
DATOS
Página 10 de 20
Fecha de elaboración:
dd/mm/aaaa
PROYECTO INTEGRANTES: MODULO DE:
CUADRO N°:
tbl_compras
TIPO
CUADRO N°:
Mantenimiento
LONGITUD
DEL
REGISTRO:
DESCRIPCIÓN: Donde se registra las compras de los ítems de bodega.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE DATOS Página 11 de 20
Fecha de elaboración:
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.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE DATOS Página 12 de 20
Fecha de elaboración:
dd/mm/aaaa
PROYECTO INTEGRANTES: MODULO DE:
CUADRO N°:
tbl_origen_prod
TIPO
CUADRO
N°:
Mantenimi
ento
LONGITUD
DEL
REGISTRO:
DESCRIPCIÓN: Donde se registra el origen del producto.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE
DATOS
Página 13 de 20
Fecha de elaboración:
dd/mm/aaaa
PROYECT
O
INTEGRANTES: MODULO DE:
CUADRO N°:
tbl_categoria_pro
ducto
TIPO
CUADRO
N°:
Mantenimi
ento
LONGITUD
DEL
REGISTRO:
DESCRIPCIÓN: Donde se registra el origen del producto.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO
DE DATOS
Página 14 de 20
Fecha de elaboración:
dd/mm/aaaa
PROYE
CTO
INTEGRANTES: MODULO DE:
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.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE DATOS Página 15 de 20
Fecha de elaboración:
dd/mm/aaaa
PROYECT INTEGRANTES: MODULO DE:
CUADRO N°:
tbl_bodega
TIPO
CUADRO
N°:
Mantenim
LONGITUD
DEL
REGISTRO:
DESCRIPCIÓN: Donde se registra los datos de la bodega.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE
DATOS
Página 16 de 20
Fecha de elaboración:
dd/mm/aaaa
PROYE
CTO
INTEGRANTES MODULO DE:
CUADRO
N°:
tbl_proveed
TIPO
CUADRO
N°:
Mantenimi
LONGITUD
DEL
REGISTRO:
DESCRIPCIÓN: Donde se registra los datos de la bodega.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE
DATOS
Página 17 de 20
Fecha de elaboración: dd/mm/aaaa
PROYECT INTEGRANTES: MODULO DE:
CUADRO
N°: tbl_user TIPO
CUADRO N°:
Mantenimiento
LONGITUD
DEL
REGISTRO
DESCRIPCIÓN: Donde se registran los usuarios.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE
DATOS
Página 18 de 20
Fecha de elaboración:
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.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE
DATOS
Página 19 de 20
Fecha de elaboración:
dd/mm/aaaa
PROYE
CTO
INTEGRANTES MODULO DE:
CUADRO
N°:
tbl_permisos
TIPO
CUADRO
N°:
Mantenimient
LONGITU
D DEL
REGISTRO
:
DESCRIPCIÓN: Donde se registra los permisos de acceso de los usuarios.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
DICCIONARIO DE
DATOS
Página 20 de 20
Fecha de elaboración:
dd/mm/aaaa
PROYEC
TO
INTEGRANTES: MODULO DE:
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.
DESCRIPCIÓN DEL REGISTRO
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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.
SOLUCIONES: Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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.
SOLUCIONES: Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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.
SOLUCIONES: Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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:
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
GRÁFICO N° 22
CONSUMO POR MINUTO DEL SQL EN POSTGRESQL
GRÁFICO N° 22
Consumo por minuto del SQL en Postgresql
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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
Fuente: Elaboración propia. Elaborado por: Moreira Chuquimarca Joseph Antonio.
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.
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.