DESARROLLO DE UN PROTOTIPO DE SOFTWARE PARA LA MIGRACIÓN DE

DATOS E IMPRESIÓN DE ETIQUETAS SOBRE ESPECÍMENES DE LA FLORA

EN EL INSTITUTO DE CIENCIAS NATURALES DE LA UNIVERSIDAD
NACIONAL

JOHANNA MARCELA GUTIÉRREZ MEZA

JUAN CAMILO MOJICA PISCIOTTI

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR INGENIERÍA DE SISTEMAS
BOGOTÁ D.C.
2016
DESARROLLO DE UN PROTOTIPO DE SOFTWARE PARA LA MIGRACIÓN DE
DATOS E IMPRESIÓN DE ETIQUETAS SOBRE ESPECÍMENES DE LA FLORA
EN EL INSTITUTO DE CIENCIAS NATURALES DE LA UNIVERSIDAD
NACIONAL

JOHANNA MARCELA GUTIÉRREZ MEZA

JUAN CAMILO MOJICA PISCIOTTI

Trabajo de grado como requisito para optar al título de

Ingeniero de Sistemas

Director
PH.D. HENRY ALBERTO DIOSA

Codirectora
PH.D. LAUREN RAZ

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR INGENIERÍA DE SISTEMAS
BOGOTÁ D.C.
2016
 TABLA DE CONTENIDO

LISTA DE FIGURAS...................................................................................................6
LISTA DE TABLAS.....................................................................................................8
AGRADECIMIENTOS................................................................................................9
INTRODUCCIÓN.....................................................................................................10
1. FORMULACIÓN DEL PROBLEMA......................................................................11
2. OBJETIVOS.........................................................................................................14
2.1 OBJETIVO GENERAL...................................................................................14
2.2 OBJETIVOS ESPECíFICOS.........................................................................14
3. JUSTIFICACIÓN..................................................................................................15
3.1 JUSTIFICACIÓN ACADÉMICA.....................................................................15
3.2 JUSTIFICACIÓN TÉCNICA...........................................................................15
3.3 JUSTIFICACIÓN PRÁCTICA........................................................................15
4. MARCO CONTEXTUAL DEL PROBLEMA.........................................................17
4.1 ACERCA DEL PROCESO DE RECOLECCIÓN DE UN ESPÉCIMEN E
INCLUSIÓN EN LA BASE DE DATOS DEL ICN. ..............................................17
4.1.1 Recolección............................................................................................17
4.1.2 Secado...................................................................................................17
4.1.3 Elaboración de etiquetas........................................................................17
4.1.4 Montaje...................................................................................................17
4.1.5 Sellado....................................................................................................18
4.1.6 Cuarentena.............................................................................................18
4.1.7 Toma de fotografía y código de barras...................................................18
4.1.8 Incluir espécimen en el herbario............................................................18
4.1.9 Digitalización..........................................................................................18
5. MARCO REFERENCIAL TECNOLÓGICO..........................................................22
5.1 PATRÓN ARQUITECTÓNICO.......................................................................22
5.1.1 Patrón de arquitectura modelo vista controlador (MVC)........................22
5.1.2 Patrón de arquitectura modelo-vista-vista modelo (MVVM)..................22
5.2 ZK .................................................................................................................23
5.2.1 Arquitectura de ZK..................................................................................23
5.2.2 ZK con MVC...........................................................................................24
5.2.3 ZK con MVVM........................................................................................25
5.3 JAVA..............................................................................................................25
5.4 JPA ................................................................................................................25
5.5 MySQL ..........................................................................................................26
5.6 SOBRE LA MIGRACIÓN DE DATOS............................................................26
5.6.1 CSV........................................................................................................26
5.6.2 XML........................................................................................................27
5.6.3 XLS.........................................................................................................27
5.6.4 HTML......................................................................................................27
5.7 SPECIFY.......................................................................................................27
5.8 GENERACIÓN DE ETIQUETAS...................................................................28

3
 5.8.1 Apache POI............................................................................................28
5.8.2 Itext.........................................................................................................28
5.9 PRUEBAS UNITARIAS..................................................................................28
5.9.1 Junit........................................................................................................28
6. MARCO METODOLÓGICO.................................................................................29
6.1 MODELO DE PROCESO UNIFICADO (UP).................................................29
6.1.1 El ciclo de vida del Proceso Unificado...................................................29
6.1.1.1 Fase de Inicio..................................................................................30
6.1.1.2 Fase de Elaboración.......................................................................30
6.1.1.3 Fase de Construcción.....................................................................30
6.1.1.4 Fase de Transición..........................................................................30
6.1.2 Flujos de trabajo de proceso..................................................................30
6.2 LENGUAJE DE MODELADO UNIFICADO (UML)........................................31
6.2.1 Unidades lingüisticas de UML................................................................31
6.2.1.1 Unidades lingüisticas para el modelo funcional..............................31
6.2.1.2 Unidades lingüisticas para el modelo estructural...........................32
6.2.1.3 Unidades lingüisticas para el modelo dinámico..............................32
7. BREVE EXPLICACIÓN DE LA METODOLOGÍA DE DESARROLLO APLICADA
Y ENTREGABLES...................................................................................................34
7.1 FASE DE INICIO............................................................................................34
7.2 FASE DE ELABORACIÓN............................................................................34
7.3 FASE DE CONSTRUCCIÓN.........................................................................35
7.4 FASE DE TRANSICIÓN................................................................................36
8. MODELO FUNCIONAL........................................................................................37
8.1 DEFINICIÓN DE POSIBLES ACTORES Y RESPONSABILIDADES ..........37
8.1.1 Rol recolector.........................................................................................37
8.1.2 Rol validador..........................................................................................38
8.1.3 Rol administrador...................................................................................38
8.2 DEFINICIÓN DE REQUERIMIENTOS..........................................................39
8.2.1 Requerimientos funcionales...................................................................39
8.3 REQUERIMIENTOS ESPECÍFICOS DE INTERFACES...............................41
8.3.1 Interfaces de usuario..............................................................................41
8.3.2 Interfaces de software............................................................................41
8.4 PROTOCOLOS DE COMUNICACIÓN.........................................................41
8.5 REQUERIMIENTOS DE PERSISTENCIA....................................................41
8.6 MODELO FUNCIONAL BASADO EN CASOS DE USO..............................42
8.6.1 Módulo de control de acceso.................................................................44
8.6.2 Módulo de selección y cargue de archivos............................................50
8.6.3 Módulo de gestión de especímenes......................................................57
8.6.4 Módulo de selección y envío de especímenes......................................67
8.6.5 Módulo de consulta y aprobación de solicitudes de inclusión para
aprobación.......................................................................................................71
8.6.6 Módulo de gestión de usuarios..............................................................79
9. MODELO ESTRUCTURAL..................................................................................85
9.1 DIAGRAMA DE CLASES..............................................................................85

4
 9.2 MODELO DE PERSISTENCIA......................................................................87
9.2.1 Estructuras de árbol...............................................................................89
9.2.2 Patrón de fuente de datos......................................................................90
9.2.3 Estrategia de mapeo..............................................................................90
9.2.3.1 Mapeador de datos.........................................................................90
9.2.3.2 Clase a tabla en jerarquías de herencia.........................................91
9.2.3.3 Clase concreta a tabla en jerarquías de herencia..........................93
9.2.3.4. Mapa de identidad.........................................................................95
9.2.4 Aspectos tecnológicos de mapeo...........................................................95
9.3 PLANTAE Y LA EXPORTACIÓN DE LOS DATOS.......................................96
9.4 ESTRATEGIA DE MIGRACIÓN DE DATOS A SPECIFY..............................97
9.4.1 Datos sensibles detectados en el proceso de migración.......................99
9.4.1.1 Árbol de la Taxonomía..................................................................100
9.4.1.2 Árbol de Geografía........................................................................101
9.4.1.3 Agente...........................................................................................103
9.4.1.4 Otros datos....................................................................................104
10. MODELO DE INTERFAZ GRÁFICA DE USUARIO........................................105
10.1 MAPA DE NAVEGACIÓN..........................................................................105
10.2 GENERALIDADES DE LA INTERFÁZ GRÁFICA.....................................107
10.2.1 Página de control de acceso..............................................................107
10.2.2 Página principal..................................................................................107
10.2.3 Menú de opciones de usuario............................................................109
10.2.4 Cambiar contraseña...........................................................................109
10.2.5 Cerrar sesión......................................................................................110
10.2.6 Mensajes............................................................................................110
10.3 OPCIONES DE MENÚ..........................................................................111
10.4 ASPECTOS DE IMPLEMENTACIÓN....................................................114
11. MODELO DINÁMICO.......................................................................................115
11.1 DIAGRAMAS DE SECUENCIA.................................................................115
11.2 MÁQUINAS DE ESTADO..........................................................................119
11.2.1 Máquina de estados del espécimen...................................................119
11.2.2 Máquina de estados de la solicitud de inclusión ..............................119
12. TECNOLOGÍAS USADAS EN LA CONSTRUCCIÓN.....................................121
13. PRUEBAS........................................................................................................123
13.1 Pruebas unitarias y de integración............................................................123
14. CONCLUSIONES............................................................................................125
15. TRABAJO FUTURO........................................................................................126
16. GLOSARIO......................................................................................................127
17. GUÍA DE CONTENIDO DE ANEXOS..............................................................128
17.1 DOCUMENTOS.........................................................................................128
17.2 PROTOTIPO..............................................................................................128
17.3 MODELAMIENTO......................................................................................129
17.4 DICCIONARIOS........................................................................................130
17.5 MANUALES...............................................................................................130
BIBLIOGRAFÍA......................................................................................................131

5
 LISTA DE FIGURAS

Figura 1. Espécimen del herbario del ICN...............................................................18

Figura 2. Diagrama de flujo del proceso de inclusión de un espécimen recolectado
en la base de datos del ICN. ..................................................................................19
Figura 3. Proceso actual de recolección y manejo de información de especímenes
de flora del ICN en notación BPMN.........................................................................20
Figura 4. Proceso propuesto de recolección y manejo de información de
especímenes de flora del ICN en notación BPMN..................................................21
Figura 5. Arquitectura de ZK....................................................................................23
Figura 6. Arquitectura de ZK con MVC....................................................................24
Figura 7. Arquitectura ZK con MVVM......................................................................25
Figura 8. Modelo RUP..............................................................................................29
Figura 9. Flujos de trabajo en UP............................................................................31
Figura 10. Organización del modelamiento del prototipo. ......................................35
Figura 11. Diagrama general de casos de uso........................................................43
Figura 12. Diagrama de casos de uso del módulo de control de acceso. .............44
Figura 13. Diagrama de casos de uso del módulo de selección y cargue de
archivos. ..................................................................................................................50
Figura 14. Diagrama de casos de uso del módulo de gestión de especímenes.. . .57
Figura 15. Diagrama de casos de uso del módulo de selección y envío de
especímenes............................................................................................................67
Figura 16. Diagrama de casos de uso del módulo de consulta y aprobación de
solicitudes de inclusión............................................................................................71
Figura 17. Diagrama de casos de uso del módulo de gestión de usuarios............79
Figura 18. Diagrama de clases................................................................................86
Figura 19. Diagrama relacional................................................................................88
Figura 20. Estructuras de árbol...............................................................................89
Figura 21. Mapeador genérico.................................................................................90
Figura 22. Clase a tabla en jerarquía de herencia – Diagrama de clases..............92
Figura 23. Clase a tabla en jerarquía de herencia – Modelo relacional..................93
Figura 24. Clase concreta a tabla en jerarquías de herencia – Diagrama de clases.
.................................................................................................................................94
Figura 25. Clase concreta a tabla en jerarquías de herencia – Modelo relacional. 95
Figura 26. Exportación de datos desde Plantae......................................................96
Figura 27. Opción Datos a Specify..........................................................................99
Figura 28. Sección árbol taxonomía de Specify....................................................100
Figura 29. Sección árbol taxonomía a nivel de base de datos.............................101
Figura 30. Sección árbol geografía de Specify......................................................102
Figura 31. Sección árbol geografía a nivel de base de datos...............................102
Figura 32. Mapa de navegación del prototipo.......................................................106
Figura 33. Página de control de acceso................................................................107
Figura 34. Página principal con todas las opciones de menú...............................108

6
Figura 35. Opciones del usuario............................................................................109
Figura 36. Opción de cambio de contraseña.........................................................109
Figura 37. Mensajes de confirmación....................................................................110
Figura 38. Mensajes de resultado..........................................................................110
Figura 39. Opción de menú Importar datos de especímenes................................111
Figura 40. Opción de menú Gestión de especímenes...........................................111
Figura 41. Opción de menú Envío de solicitudes de inclusión..............................112
Figura 42. Opción de menú Solicitudes de inclusión.............................................112
Figura 43. Opción de menú Administración de usuarios.......................................113
Figura 44. DS007 Gestionar archivos de especímenes........................................116
Figura 45. DS008 Listar histórico de archivos cargados.......................................117
Figura 46. DS024 Consultar solicitudes de inclusión............................................118
Figura 47. Máquina de estados del espécimen.....................................................119
Figura 48. Máquina de estados de la solicitud de inclusión..................................120
Figura 49. Arquitectura tecnológica del prototipo PlantaeToSpecify.....................121
Figura 50. Diagrama de despliegue.......................................................................122
Figura 51. Diagrama de clases de la implementación de JUnit............................123
Figura 52. Resultados de las pruebas unitarias....................................................124
Figura 53. Cargue de un archivo...........................................................................125
Figura 54. Cargue de archivo exitoso....................................................................125
Figura 55. Cargue de archivo incorrecto campo invalido......................................126
Figura 56. Cargue de archivo vacío. Fuente.........................................................126
Figura 57. Solicitud de inclusión de especímenes................................................127
Figura 58. Solicitud de inclusión de especímenes enviada...................................127
Figura 59. Agregar información.............................................................................128
Figura 60. Confirmación de inclusión de especímen en Specify...........................128
Figura 61. Espécimen desde Specify....................................................................129
Figura 62. Contenido inicial del CD.......................................................................133
Figura 63. Estructura del proyecto abierto desde Eclipse.....................................134

7
 LISTA DE TABLAS

Tabla 1. Requerimientos funcionales.......................................................................39

Tabla 2. Iniciar aplicación.........................................................................................45
Tabla 3. Iniciar sesión..............................................................................................46
Tabla 4. Validar existencia de usuario.....................................................................47
Tabla 5. Habilitar menú según rol............................................................................48
Tabla 6. Cerrar sesión..............................................................................................49
Tabla 7. Gestionar archivos de especímenes..........................................................51
Tabla 8. Listar histórico de archivos guardados......................................................52
Tabla 9. Cargar archivo............................................................................................53
Tabla 10. Guardar archivo........................................................................................54
Tabla 11. Refrescar listado de histórico de archivos cargados...............................55
Tabla 12. Cancelar cargue de archivos...................................................................56
Tabla 13. Gestionar espécimen...............................................................................58
Tabla 14. Listar especímenes..................................................................................59
Tabla 15. Ver detalles espécimen............................................................................60
Tabla 16. Editar espécimen......................................................................................61
Tabla 17. Cancelar edición espécimen....................................................................62
Tabla 18. Guardar edición espécimen.....................................................................63
Tabla 19. Filtrar espécimen......................................................................................64
Tabla 20. Eliminar espécimen..................................................................................65
Tabla 21. Exportar etiqueta......................................................................................66
Tabla 22. Seleccionar espécimen............................................................................68
Tabla 23. Listar especímenes para envío................................................................69
Tabla 24. Enviar especímenes para inclusión.........................................................70
Tabla 25. Consultar solicitudes de inclusión............................................................72
Tabla 26. Listar solicitudes de inclusión..................................................................73
Tabla 27. Filtrar solicitudes de inclusión..................................................................74
Tabla 28. Mostrar detalles de solicitud de inclusión................................................75
Tabla 29. Mostrar información a migrar...................................................................76
Tabla 30. Aprobar solicitud.......................................................................................77
Tabla 31. Rechazar solicitud....................................................................................78
Tabla 32. Listar usuarios..........................................................................................80
Tabla 33. Crear usuario............................................................................................81
Tabla 34. Consultar usuario.....................................................................................82
Tabla 35. Modificar usuario......................................................................................83
Tabla 36. Filtrar usuarios..........................................................................................84
Tabla 37. Campos que son migrados......................................................................98
Tabla 38. Datos sensibles en la migración..............................................................99

8
 AGRADECIMIENTOS

A Dios y a nuestras familias, porque sin su apoyo todo este camino hubiera sido
más difícil.

A nuestro director Henry Alberto Diosa y nuestra codirectora Lauren Raz, además
del Grupo de Investigación Arquisoft de la Universidad Distrital y de los miembros
del Programa de Informática de la Biodiversidad del Instituto de Ciencias Naturales
de la Universidad Nacional, por su tiempo y colaboración.

9
 INTRODUCCIÓN

Uno de los objetivos del Instituto de Ciencias Naturales de la Universidad Nacional

(de ahora en adelante ICN) a la hora de recolectar un espécimen de flora es que
su información pueda ser puesta a disposición de estudiantes, académicos e
investigadores, con un tiempo de diferencia mínimo entre la recolección,
almacenamiento en Specify1 y posterior publicación en la biblioteca virtual del ICN.

A través de la alianza del programa de Informática de la Biodiversidad del Instituto

de Ciencias Naturales de la Universidad Nacional a cargo de la profesora Lauren
Raz, http://www.biovirtual.unal.edu.co/ICN/ y el grupo de investigación Arquisoft de
la Universidad Distrital, http://arquisoft.udistrital.edu.co se acordó desarrollar un
aplicativo móvil que permitiera la recolección de datos de especímenes biológicos
vegetales en campo a través de un dispositivo móvil, este aplicativo móvil es
Plantae [1], automatizando el proceso de recolección de datos. Sin embargo, el
alcance del aplicativo móvil no incluyó la migración de los datos almacenados en
el dispositivo móvil a la base de datos del ICN.

Dado lo anterior y como complemento a Plantae, en este documento se recopila el

análisis, diseño e implementación del prototipo de software que permite la edición,
selección, solicitud de inclusión, generación de etiquetas, autorización y migración
de los especímenes de flora recolectados en campo a través de Plantae a la base
de datos del ICN. Mediante entrevistas a miembros del grupo ARQUISOFT que
desarrollaron Plantae, el programa de Informática de la Biodiversidad y algunos
miembros del ICN, se recopiló la información necesaria para elaborar un modelo
funcional que pudiera satisfacer los requerimientos, además de definir una
estrategia para migración de los datos. Una vez obtenido el modelo funcional se
realizó la validación con los usuarios que estarán involucrados con el aplicativo, lo
cual contribuyó al mejoramiento de éste.

Posteriormente se realizó el desarrollo del prototipo utilizando un lenguaje

orientado a objetos, de la mano de los modelos funcional y estructural. Este
prototipo está acompañado del modelo dinámico que incluye los diagramas de
secuencia de cada caso de uso, demostrando el cumplimiento de lo diseñado con
lo desarrollado.

1 Specify es una plataforma de base de datos para museos y herbarios.

http://specifyx.specifysoftware.org/

10
 1. FORMULACIÓN DEL PROBLEMA

El Instituto de Ciencias Naturales de la Universidad Nacional de Colombia alberga

la mayor colección de especímenes biológicos colombianos que existe en el
mundo, con un número cercano a 940.000. En la actualidad, el Instituto tiene
sistematizados más de 560.000 especímenes, disponibles en las colecciones
científicas en línea.

El proceso de sistematización de las colecciones biológicas del Instituto de

Ciencias Naturales se inició en los años 1970 con el Herbario Nacional
Colombiano. Desde entonces se ha venido construyendo una base de datos
institucional, la cual se desarrolló en varias etapas, culminando con la decisión en
2005 de adoptar el software Specify para la administración y almacenamiento de
los datos.

Por primera vez, en 2004, el Instituto puso a disposición sus colecciones

biológicas a través de Internet. Actualmente este recurso en línea brinda acceso a
la base de datos, y a más de 193.000 fotografías de los especímenes del Herbario
Nacional Colombiano (el Herbario Virtual) [2].

Teniendo en cuenta que uno de los objetivos del ICN es el de poner a disposición
de la comunidad en general la colección de especímenes biológicos, se evidenció
la necesidad de desarrollar una serie de soluciones basadas en software que
permitan ayudar a cumplirlo.

La primera de estas soluciones basadas en software fue Plantae el “Aplicativo de

software para la recolección de muestras biológicas en campo para el Instituto de
Ciencias Naturales de la Universidad Nacional”[1] que permite la recolección de
datos de especímenes biológicos vegetales en campo a través de un dispositivo
móvil, pero una vez los datos han sido recolectados estos deben continuar con el
proceso que se describe a continuación:

Una vez los datos han sido capturados, el biólogo recolector deberá elaborar las
etiquetas por cada espécimen recolectado de acuerdo a los datos mínimos
requeridos por el ICN, luego imprime las etiquetas y las adjunta al espécimen para
que pase por el proceso de montaje, durante este proceso se pone un sello con un
código (código de colección) al espécimen para su identificación, después es
revisado para su inclusión en la base de datos del instituto, donde surgen tres
escenarios:

1. Sí dicho espécimen es aprobado y la familia de éste se encuentra

digitalizada, se le asigna un código de barras y pasa por el proceso de
fotografía, luego el espécimen es almacenado y a través de su fotografía se
digitaliza la información de la etiqueta que acompaña al espécimen y se

11
 almacena en la base de datos del ICN.
2. Sí dicho espécimen es aprobado pero su familia no ha sido digitalizada,
entonces es almacenado en el herbario sin pasar por el proceso de
fotografía y no se registra en la base de datos del ICN, a la espera de que
la familia completa sea digitalizada.
3. Si dicho espécimen no es aprobado, es descartado para su inclusión tanto
física como digital en la base de datos del ICN.

En el proceso anterior se presentan los siguientes inconvenientes:

• A pesar que la información será recolectada a través del dispositivo móvil,

no está definido un proceso de migración de los datos entre el dispositivo
móvil y la base de datos del ICN.
• La información de cada espécimen que sea aprobado para ingresar a la
base de datos del ICN debe ser transcrita aunque previamente haya sido
digitalizada. Cabe señalar que, en una salida de campo de diez días a un
lugar con alta diversidad de especies, generalmente participan de cuatro a
seis biólogos, a su vez cada biólogo recolecta de 150 a 200 plantas, que se
dividen de tres a cinco especímenes y solamente uno de ellos será
almacenado física y digitalmente en el ICN, los demás se envían a otros
herbarios. Es decir, entre los 450 a 1000 especímenes recolectados por
biólogo solo ingresan al herbario del ICN de 150 a 200 (E. Rudas,
comunicación personal, Junio 3, 2014).
• La inclusión de un espécimen en la base de datos del ICN depende de si la
familia de éste se encuentra digitalizada, retrasando la publicación de la
información del espécimen. En la actualidad al ICN ingresan cerca de
11.000 especímenes al año y de estos solo 7.000 se fotografían y registran
en su base de datos.
• La elaboración de las etiquetas, aunque el ICN posee un formato estándar
para su elaboración, se realiza de manera autónoma por cada biólogo.

Por todo lo anterior, surge la pregunta: ¿Se puede, mediante una solución basada
en software gestionar la información recolectada en campo a través de un
dispositivo móvil para:

• Migrar a una base de datos intermedia la información que será recolectada

a través del aplicativo del dispositivo móvil cuando sea requerido por el
recolector?
• Permitir la depuración de los datos almacenados en la base de datos
intermedia para su posterior migración a la base de datos del ICN?
• Posibilitar la verificación y validación de la información migrada a la base de
datos intermedia?
• Permitir la generación de las etiquetas que son agregadas a cada

12
 espécimen, asegurando que los datos sean consistentes con los
registrados en el momento de su captura?
• Permitir la actualización de la información que requieren los especímenes
para ser incluidos en la base de datos del ICN?
• Permitir la migración a la base de datos del ICN de los registros de los
especímenes que cuenten con la información completa requerida por el
mismo?

Es aquí donde se evidencia la posibilidad de desarrollar una segunda solución

basada en software que ayude a cumplir con el objetivo del ICN, anteriormente
expuesto.

13
 2. OBJETIVOS

2.1 OBJETIVO GENERAL

Analizar, diseñar y construir una solución basada en software que permita la

migración de los datos recolectados en campo a través del aplicativo móvil Plantae
a la base de datos del ICN, además de la elaboración e impresión de etiquetas.

2.2 OBJETIVOS ESPECíFICOS

• Definir, diseñar e implementar el proceso de migración de los datos

recolectados a través del aplicativo móvil Plantae a la base de datos
intermedia.

• Definir, diseñar e implementar el proceso de migración entre la base de

datos intermedia y la plataforma Specify que gestiona la información de los
especímenes de flora del ICN.

• Desarrollar una funcionalidad que permita la depuración de los datos sobre

la base de datos intermedia previo a su migración a la plataforma Specify
del ICN.

• Generar e imprimir las etiquetas empleando el modelo establecido por el

ICN para los especímenes de flora migrados a la base de datos intermedia,
evitando así, el uso de otras herramientas para la generación de las
mismas.

• Realizar pruebas unitarias y de integración para verificar el correcto

funcionamiento del prototipo.

14
 3. JUSTIFICACIÓN

3.1 JUSTIFICACIÓN ACADÉMICA

A través de este proyecto se aplican los conocimientos adquiridos a lo largo de la

carrera de ingeniería de sistemas, ofreciendo la posibilidad de afianzar y expandir
los conocimientos propios y de miembros del grupo de investigación.

Este proyecto continúa mejorando el proceso de apoyo interinstitucional con

grupos de otras disciplinas que en este caso se da por la alianza entre el
programa de Informática de la Biodiversidad del Instituto de Ciencias Naturales de
la Universidad Nacional2 y el Grupo de Investigación Arquisoft de la Universidad
Distrital3.

3.2 JUSTIFICACIÓN TÉCNICA

Esta aplicación se desarrollará usando el modelo de Proceso Unificado (UP por

sus siglas en inglés), que hace uso intensivo del Lenguaje Unificado de Modelado
(UML por sus siglas en inglés).

El núcleo de UML son sus unidades lingüísticas que permiten elaborar modelos
para soluciones basadas en software (y por lo tanto una de las características
principales de UP) “lo que en el contexto del proceso de desarrollo de software es
una simplificación de la realidad que ayuda al equipo del proyecto a entender
ciertos aspectos de la complejidad inherente del software, organizar el esfuerzo de
desarrollo y facilitar la posibilidad de re-utilización y evolución del sistema” [3].

Adicionalmente a través de los planos de ingeniería que serían el resultado de

usar este modelo de desarrollo de software, se podrá entender a nivel técnico el
funcionamiento, características y comportamiento de este prototipo de software,
además que contribuirá de manera significativa a la modularidad, escalabilidad y
facilidad de comprensión del aplicativo para extender su alcance en caso que se
desee.

3.3 JUSTIFICACIÓN PRÁCTICA

A partir de un recorrido guiado a través de las instalaciones del ICN para conocer
el procedimiento que se lleva a cabo luego de la recolección de especímenes en
campo, reuniones con la doctora Lauren, el curador general y el líder del programa

2 http://www.biovirtual.unal.edu.co/ICN/
3 http://arquisoft.udistrital.edu.co/portal

15
de Informática de la Biodiversidad del Instituto de Ciencias Naturales de la
Universidad Nacional, se evidenció que la aplicación Plantae permitirá registrar y
almacenar los datos recolectados mejorando el proceso de captura de datos de
especímenes en campo, pero no contempla una solución que permita la validación
de la información capturada, generación de las etiquetas de cada espécimen y
finalmente su inclusión en la base de datos del ICN.

Para dar solución a este nuevo problema surge la idea de desarrollar una solución
basada en software que permitirá migrar los datos que fueron recolectados a
través del aplicativo móvil Plantae, además de brindar al biólogo recolector la
posibilidad de seleccionar, modificar y validar la información recolectada de cada
espécimen, y enviar los registros que él desee que sean incluidos en la base de
datos del ICN, evitando la manipulación reiterada de los mismos y disminuyendo
los fallos al momento de digitalización de un espécimen.

Adicionalmente, se permitirá la elaboración de etiquetas por cada espécimen, en

cuyo caso el recolector solo tendrá que seleccionar el espécimen y generar la
etiqueta. Lo anterior contribuirá a que se maneje un estándar de etiquetado dentro
del ICN.

16
 4. MARCO CONTEXTUAL DEL PROBLEMA

4.1 ACERCA DEL PROCESO DE RECOLECCIÓN DE UN ESPÉCIMEN E

INCLUSIÓN EN LA BASE DE DATOS DEL ICN.

A través de un recorrido guiado por las instalaciones del ICN se identificaron y se

describen a continuación las etapas del proceso de recolección de un espécimen e
inclusión en la base de datos del ICN:

4.1.1 Recolección

En la salida de campo que realizan los biólogos es recolectado el espécimen y

puesto entre hojas de periódico para protegerlo en su viaje al ICN.

4.1.2 Secado

El espécimen es llevado al área de secado en donde es colocado en medio de

unas láminas corrugadas de aluminio y es introducido dentro de un horno para ser
secado a una temperatura establecida, durante un tiempo que varía según el
espécimen.

4.1.3 Elaboración de etiquetas

El espécimen secado es entregado nuevamente al biólogo recolector, el cual se

encargará de elaborar la etiqueta según los datos que previamente ha tomado del
espécimen en la salida de campo. La imprime y la anexa al espécimen.

4.1.4 Montaje

El biólogo recolector lleva al espécimen junto con su etiqueta al área de montaje,

donde el personal encargado realizará un montaje de acuerdo al espécimen para
garantizar la preservación del mismo y facilitar su almacenamiento en las gavetas
del ICN para su posterior consulta, es decir, sí el tamaño del espécimen
recolectado es pequeño es colocado en una lámina de papel sin ácido de tamaño
30cm x 40cm, es sujetado a la lámina mediante unas cintas especiales y sus tallos
son cosidos mediante hilos, si el espécimen cuenta con elementos adicionales
(frutos, semillas, flores, entre otros) estos son puestos dentro de un sobre el cual
será incluido en el montaje.

17
4.1.5 Sellado

Posteriormente le ponen un sello que posee un código único que identificará al

espécimen dentro del herbario del ICN.

4.1.6 Cuarentena

El espécimen es llevado a un congelador a 20ºC bajo cero en donde permanecerá

el tiempo establecido por el ICN, con el fin de eliminar las posibles plagas u
organismos vivos que aún estén adheridos a este.

4.1.7 Toma de fotografía y código de barras

Si la familia a la que pertenece el espécimen ya ha sido digitalizada, entonces se

le adherirá un código de barras y se le tomará una fotografía (Figura 1).

4.1.8 Incluir espécimen en el herbario

El espécimen es almacenado finalmente en las gavetas del herbario.

4.1.9 Digitalización

A través de la fotografía se obtienen los datos de los especímenes para ser

registrados en la base de datos del ICN.

Figura 1. Espécimen del herbario del ICN. Fuente. [4].

18
El proceso descrito anteriormente se representa en el siguiente diagrama de flujo (Figura 2).

Figura 2. Diagrama de flujo del proceso de inclusión de un espécimen recolectado en la base de datos del ICN. Fuente. Este
trabajo4

4 Este diagrama de flujo fue realizado a partir de la información recolectada en la visita al ICN por parte de los autores del proyecto.
Para mostrar con mayor claridad el flujo del proceso que se muestra en la Figura 2, la Figura 3 representa la interacción entre
las aplicaciones que intervienen sin el prototipo propuesto y en la Figura 4 cómo sería la interacción con el mismo a través de
la notación de BPMN.

Figura 3. Proceso actual de recolección y manejo de información de especímenes de flora del ICN en notación BPMN. Fuente.
Este trabajo5

5 Este diagrama en la notación BPMN fue realizado por parte de los autores del proyecto.
 Figura 4. Proceso propuesto de recolección y manejo de información de especímenes de flora del ICN en notación BPMN.
Fuente. Este trabajo6

6 Este diagrama en la notación BPMN fue realizado por parte de los autores del proyecto.
 5. MARCO REFERENCIAL TECNOLÓGICO

5.1 PATRÓN ARQUITECTÓNICO

Los patrones arquitectónicos se refieren a soluciones recurrentes de problemas a

nivel de diseño arquitectónico y proveen un vocabulario común con el propósito de
facilitar la comunicación. Se puede considerar a un patrón ser arquitectónico, si
éste delinea los tipos de elementos y sus formas de interactuar y provee
estrategias para solucionar un problema de abstracción de nivel arquitectónico,
esto es, si el patrón cubre toda la estructura del sistema y no solo unos pocos
subsistemas [5].

5.1.1 Patrón de arquitectura modelo vista controlador (MVC)

Model-View-Controller es un patrón de arquitectura de software que separa el

modelo, la vista y el controlador de una aplicación basada en software,
permitiendo facilitar la tarea de desarrollo de aplicaciones y su posterior
mantenimiento [6].

5.1.2 Patrón de arquitectura modelo-vista-vista modelo (MVVM)

MVVM es una abreviación de un patrón de arquitectura llamado Vista-Modelo-

VistaModelo (Model-View-ViewModel) originario de Microsoft [7]. Es una
especialización del modelo de presentación presentado por Martin Fowler [8], una
variante del patrón MVC. Este patrón tiene 3 roles: Vista, Modelo y vistaModelo.
La vista y el modelo juegan el mismo papel que en MVC.

La VistaModelo (ViewModel) actúa como un controlador especial para la vista el

cual es responsable de exponer datos del modelo en la vista y proveer acciones y
lógica requeridas por peticiones del usuario desde la vista. Esto se puede dar al
pensar en que la interfaz gráfica quiere ejecutar operaciones complejas que deben
estar implementadas en código que en la definición de la vista no tienen sentido,
pero que son muy específicas para ser incluidas en el modelo [9].

El término vistaModelo significa "Modelo de la vista" y puede ser pensado como

una abstracción de la vista, pero también provee una especialización del modelo
que la vista puede usar para enlazar datos. En este último rol, la vistaModelo
contiene transformadores de datos que convierten los tipos de modelo en tipos de
vista y contiene comandos (Commands) que la vista puede usar para interactuar
con el modelo [7].

22
5.2 ZK

Es un framework de interfaz gráfica basado en componentes que permite crear

aplicaciones de internet enriquecidas (RIA por sus siglas en inglés) sin necesidad
de usar explícitamente JavaScript o AJAX. Se pueden construir aplicaciones AJAX
WEB altamente interactivas y sensibles solo con JAVA. ZK provee cientos de
componentes diseñados para varios propósitos, algunos para la visualización de
datos y algunos para la entrada del usuario, además permite crear componentes
en un lenguaje con formato XML o ZUL7.

Todas las acciones de un usuario en una página pueden ser manejadas en un

controlador. Desde el controlador se pueden manipular los componentes para
responder a las acciones del usuario y los cambios que el usuario realice se
reflejarán automáticamente en el navegador, además evita tener que preocuparse
por los detalles de comunicación entre el navegador y el servidor.

En adición a la manipulación directa de componentes con el patrón MVC (Modelo-

vista-controlador), ZK también soporta otro patrón de diseño, MVVM (Modelo-
Vista-VistaModelo) que le da al controlador y a la vista más separación. Estos dos
enfoques son mutuamente intercambiables, y se puede elegir una de ellas según
la consideración arquitectónica [10].

5.2.1 Arquitectura de ZK

Figura 5. Arquitectura de ZK. Fuente. [11].

7 También conocido como XUL (XML User Interface Language) es un lenguaje basado en XML
para construir interfaces de usuario.

23
La Figura 5 corresponde a la arquitectura simplificada de ZK. Cuando un
navegador visita una página de una aplicación en ZK, ZK crea los componentes
escritos en ZUL y los renderiza en el navegador. Se pueden manipular los
componentes a través del controlador de la aplicación para implementar lógica de
presentación de interfaz gráfica. Todos los cambios que se realizan en los
componentes se verán reflejados automáticamente en el navegador del usuario y
ZK maneja la comunicación subyacente.

La aplicación desarrollada en ZK puede acceder fácilmente a la tecnología Java

EE e integrar muchos frameworks basados en JAVA de terceras partes. Además,
ZK también soporta desarrollo centrado en el cliente que permite personalizar
efectos visuales, o manejar acciones del usuario desde el lado cliente [11].

5.2.2 ZK con MVC

Para crear una aplicación de arquitectura MVC con ZK las tres capas (modelo-
vista-controlador) se debe tener en cuenta lo siguientes términos:

• Vista: Es una capa creada con los widgets de ZK, ya sea a través de
notación XML en un archivo .ZUL o a través de Java directamente.
• Controlador: Es una capa de clases en la que se listan los componentes
de la vista para su manipulación, adicionalmente, en estas clases se crean
los objetos del modelo que se comunicarán con la vista.
• Modelo: Son las clases que contienen la lógica de negocio del aplicativo.

Figura 6. Arquitectura de ZK con MVC. Fuente. [12].

24
5.2.3 ZK con MVVM

Como la vistaModelo no contiene referencias a los componentes de interfaz

gráfica, necesita un mecanismo para sincronizar los datos entre la vista y la
vistaModelo. Adicionalmente, este mecanismo tiene que aceptar las solicitudes de
los usuarios de la capa visual y enlazar la solicitud con la acción y lógica
aportadas por la capa de la vistaModelo. ZK provee un mecanismo llamado ZK
Bind en el cual se soporta el patrón MVVM y el enlazador de datos (Binder) juega
el papel principal para operar todo el mecanismo. El binder es el responsable de la
comunicación entre la vista y la vistaModelo [13].

Figura 7. Arquitectura ZK con MVVM. Fuente. [13].

5.3 JPA

Java Persistence API es un especificación de persistencia basada en POJO (Plain

Old Java Object). Ofrece una solución de mapeo objeto relacional para
aplicaciones de Java Enterprise [14].

5.4 MySQL

MySQL es un sistema manejador de base de datos relacional (RDBMS por sus

siglas en inglés) de código abierto. Es uno de los RDBMS más usados para
desarrollar aplicaciones WEB de software.

MySQL ofrece un muy rápido, multi-hilo, multi usuario, y robusto servidor de base
de datos SQL. Está diseñado para sistemas de producción con alta carga de
misión crítica, así como para integrarse en software de despliegue masivo [15].

25
5.5 SOBRE LA MIGRACIÓN DE DATOS

“Una migración de base de datos es un proceso que se realiza para mover o

trasladar los datos almacenados de un origen de datos a otro, para lo cual es
indispensable que antes de empezar cualquier proceso de esta naturaleza, se
tenga clara y documentada la razón por la cual se está migrando, además de
elaborarse la planeación detallada de las actividades contempladas.” [16].

En la migración, se busca exportar datos a un nuevo sistema con mayor

capacidad o más funciones adicionales. Estos cambios llevan consigo una
adaptación de todos los datos de una base de datos a otra [17].

Aunque una migración puede tener todo un proceso con complejidad alta, si dicho
proceso es bien definido, la migración permite hacer una manipulación clara de los
datos, brindando a las partes involucradas la certeza de obtener información
consistente después del proceso.

Una de las formas para migrar datos de una base de datos es mediante archivos
con un formato específico, algunos de estos son:

5.5.1 CSV

CSV traducido como “valores separados por coma” por sus siglas en inglés
(Comma-Separated Value) es un formato de archivo usado para intercambiar
datos entre diferentes aplicaciones. A pesar de ser un formato muy común de
intercambio de datos, no ha sido formalmente documentado, sin embargo se
puede considerar un pseudo-estándar [18].

5.5.2 XML

Lenguaje de etiquetado extensible, por sus siglas en inglés (Extensible Markup

Language) es un formato de texto flexible derivado del Estándar de Lenguaje de
Marcado Generalizado (SGML), es utilizado para almacenar datos de forma legible
mediante etiquetas que pueden ser personalizadas [19].

5.5.3 XLS

En este formato se cuenta con una colección de registros y estructuras que

especifican el contenido de un libro de trabajo que puede incluir tablas de números
no estructurados o semi-estructurados, texto o ambos: números y texto, fórmulas,
conexiones a datos externos, gráficos e imágenes.

26
El contenido del libro de trabajo está típicamente organizado en un diseño basado
en malla y frecuentemente incluye datos numéricos, datos estructurados y
fórmulas [20].

5.5.4 HTML

HTML, que significa Lenguaje de Marcado para Hipertextos (HyperText Markup

Language) es el elemento de construcción más básico de una página web y se
usa para crear y representar visualmente una página web. Determina el contenido
de la página web, pero no su funcionalidad [21].

5.6 SPECIFY

Specify es una plataforma de base de datos para museos y herbarios. Gestiona la

información sobre especies y la curaduría de colecciones, seguimiento de las
transacciones de especímenes, unión de imágenes con registros de especímenes
y la publicación de datos de especímenes en internet. Está construido en JAVA y
usa MySQL como motor de base de datos. Specify soporta datos de los
especímenes, clasificaciones taxonómicas y estratigráficos, cuadernos de campo,
secuencias de ADN, referencias de literatura y de otras fuentes primarias. También
maneja datos asociados con acuerdos de repositorio, adhesiones, tratamientos de
conservación, contenedores de objetos de colección, imágenes y documentos
adjuntos [22].

5.7 GENERACIÓN DE ETIQUETAS

Para la generación de etiquetas se tuvieron en cuenta las siguientes librerías:

5.7.1 Apache POI

La misión del proyecto Apache POI es crear y mantener API's de Java para
manipular varios formatos de archivo basados en el estándar de Open Office XML
OOXML (por sus siglas en inglés Office Open XML standards) y el formato de
Microsoft de documentos compuestos OLE2. En resumen, Apache POI permite
leer y escribir archivos de MS Excel, MS Word y MS Power Point usando java [23].

5.7.2 Itext

Es una biblioteca de código abierto para crear y manipular archivos PDF en JAVA,

27
le da a los desarrolladores máxima flexibilidad para programar PDFs avanzados y
construir cualquier escenario de generación de documentos personalizado [24].

5.8 PRUEBAS UNITARIAS

Las pruebas unitarias constituyen el primer paso para detectar errores en el

código, pues se centran en la menor unidad de diseño del software: el módulo
-por ejemplo, un método de una clase o una clase-. El objetivo principal de estas
pruebas es detectar errores en cada uno de los módulos del software al ser
ejecutados independientemente del resto de componentes [25].

5.8.1 Junit

Junit es un marco de trabajo simple para escribir pruebas repetibles. Soporta

pruebas parametrizadas por anotaciones [26].

Junit fue iniciado por Kent Beck y Erich Gamma a finales de 1995 y es hoy en día
un estándar para pruebas unitarias en aplicaciones Java [27].

28
 6. MARCO METODOLÓGICO

6.1 MODELO DE PROCESO UNIFICADO (UP)

Un proceso de desarrollo de software es el conjunto de actividades necesarias

para transformar requisitos de un usuario en un sistema basado en software. Sin
embargo, el Proceso Unificado es más que un simple proceso; es un marco de
trabajo genérico que puede especializarse para una gran variedad de sistemas
software, para diferentes áreas de aplicación, tipos de organizaciones, niveles de
aptitud y tamaños de proyecto.

El Proceso Unificado utiliza el Lenguaje Unificado de Modelado (Unified Modeling

Language, UML) para elaborar los modelos de un sistema intensivo en software
[28].

Figura 8. Modelo RUP. Fuente. [28].

6.1.1 El ciclo de vida del Proceso Unificado

El proceso unificado se repite a lo largo de una serie de ciclos que constituyen el

ciclo de vida de un sistema en construcción. Cada ciclo concluye con una versión
del producto y consta de cuatro fases:

29
6.1.1.1 Fase de Inicio
En esta fase se desarrolla una descripción del producto final acompañado del
modelado de casos de uso, además se realiza una definición preliminar de la
arquitectura y una estimación de plazos y costos.

6.1.1.2 Fase de Elaboración

En esta fase se especifican en detalle la mayoría de los casos de uso del producto
y se diseña la arquitectura del sistema, además se identifican sus riesgos. Es en
esta fase en donde se elaboran los modelos de ingeniería como: modelo dinámico,
estructural y modelo de persistencia a largo plazo.

6.1.1.3 Fase de Construcción

En esta fase se crea el producto y la línea base de la arquitectura crece hasta
convertirse en el sistema completo. La descripción evoluciona hasta convertirse en
un producto preparado para ser entregado a la comunidad de usuarios, al final de
esta fase el producto contiene todos los casos de uso que se plantearon en la fase
de inicio.

6.1.1.4 Fase de Transición

En esta fase el producto es completamente entregado al cliente para ser probado
y desplegado. Esta fase conlleva actividades como la fabricación, formación del
cliente, el proporcionar una línea de ayuda y asistencia, y la corrección de los
defectos que se encuentren tras la entrega.

6.1.2 Flujos de trabajo de proceso

El proceso unificado consiste en una serie de flujos de trabajo que van desde los
requisitos hasta las pruebas. Los flujos de trabajo desarrollan modelos, desde el
modelo de casos de uso hasta el modelo de prueba. Los flujos interactúan de la
siguiente forma:

Los desarrolladores comienzan capturando los requisitos del cliente en la forma de

casos de uso en el modelo de casos de uso. Después analizan y diseñan el
sistema para cumplir los casos de uso, creando en primer lugar un modelo de
análisis, después uno de diseño y después otro de implementación, el cual incluye
todo el código fuente. Por último, los desarrolladores preparan un modelo de
prueba que les permite verificar que el sistema proporciona la funcionalidad
descrita en los casos de uso.

30
 Figura 9. Flujos de trabajo en UP. Fuente. [28].

6.2 LENGUAJE DE MODELADO UNIFICADO (UML)

Es un lenguaje de modelado visual que se usa para especificar, visualizar,

construir y documentar artefactos de un sistema de software. Captura decisiones y
conocimiento sobre los sistemas que se deben construir. Se usa para entender,
diseñar, hojear, configurar, mantener, y controlar la información sobre tales
sistemas. Está pensado para usarse con todos los métodos de desarrollo, etapas
del ciclo de vida, dominios de aplicación y medios.

UML capta la información sobre la estructura estática y el comportamiento

dinámico de un sistema [29]. Permitiendo modelar sistemas de información, y su
objetivo es lograr modelos que, además de describir con cierto grado de
formalismo tales sistemas, puedan ser entendidos por los clientes o usuario de
aquello que se modela.

6.2.1 Unidades lingüísticas de UML

6.2.1.1 Unidades lingüísticas para el modelo funcional

Este modelo especifica la funcionalidad del sistema de software, a través de los
siguientes elementos:

31
 • Diagrama de casos de uso: Un caso de uso es un fragmento de
funcionalidad del sistema que proporciona al usuario un resultado
importante. Los casos de uso representan los requisitos funcionales. Todos
los casos de uso juntos constituyen el modelo de casos de uso, el cual
describe la funcionalidad total del sistema. Además los casos de uso guían
el proceso de desarrollo [28].

Adicionalmente en el modelo funcional se pueden elaborar los bocetos de las

interfaces con las cuales el usuario final interactuará con el sistema de software.

6.2.1.2 Unidades lingüísticas para el modelo estructural

A través de este modelo se plantea la arquitectura que tendrá un aplicación de
software. Teniendo en cuenta el modelo funcional.

Este modelo cuenta con tres tipos de diagramas:

• Diagramas de clases: Muestran los bloques de construcción de cualquier

sistema orientado a objetos. Los diagramas de clases describen la vista
estática del modelo o parte del modelo, describiendo que atributos y
comportamientos tienen en lugar de detallar los métodos para realizar
operaciones. Los diagramas de Clase son más útiles para ilustrar
relaciones entre clases e interfaces [30].

• Diagramas de componentes: Ilustran las piezas del software, controladores

embebidos, etc. que conformarán un sistema. Un diagrama de
Componentes tiene un nivel más alto de abstracción que un diagrama de
clase – usualmente un componente se implementa por una o más clases (u
objetos) en tiempo de ejecución [31]. En este trabajo no se desarrollarán
componentes de software sino que se trabajará en el marco de una
aplicación orientada a objetos.

• Diagramas de instalación: Estos diagramas especifican una serie de

entidades que se pueden utilizar para definir la arquitectura de ejecución de
sistemas representados por artefactos de software asignados a nodos que
están conectados por enlaces de comunicación, lo cual permite modelar
sistemas de complejidad arbitraria. Los nodos pueden tener anidamientos y
representan tanto hardware como plataformas de ejecución de software.
Los artefactos representan elementos concretos en el mundo físico que son
resultado de un proceso de desarrollo [32].

6.2.1.3 Unidades lingüísticas para el modelo dinámico

A través de este modelo se muestra el comportamiento que tendrá el sistema
cuando un actor del sistema interactúa. La elaboración de los diagramas en los
que se compone este modelo se hace en paralelo con el ejercicio de la

32
programación de funcionalidades.

• Diagramas de secuencia: Un diagrama de secuencia es una forma de

diagrama de interacción, son usados para mostrar qué objetos se
comunican con qué otros objetos y qué mensajes disparan esas
comunicaciones. Los diagramas de secuencia no están pensados para
mostrar lógicas de procedimientos complejos [33].

• Diagramas de actividades: Son usados para mostrar la secuencia de

actividades. Los diagramas de actividades muestran el flujo de trabajo
desde el punto de inicio hasta el punto final detallando muchas de las rutas
de decisiones que existen en el progreso de eventos contenidos en la
actividad [34].

• Diagramas de comunicación: Un diagrama de comunicación destaca la

organización de los objetos que participan en una interacción, gráficamente
es una colección de nodos (objetos) y arcos (enlaces) que reflejan las
interacciones por medio de operaciones asociadas a un flujo de las mismas
por medio de una flecha.

33
 7. BREVE EXPLICACIÓN DE LA METODOLOGÍA DE DESARROLLO
APLICADA Y ENTREGABLES

Mediante entrevistas al equipo de trabajo del aplicativo móvil Plantae “Aplicativo

de software para la recolección de muestras biológicas en campo para el Instituto
de Ciencias Naturales de la Universidad Nacional” y los miembros del ICN
encargados de aprobar la inclusión de un espécimen recolectado a la base de
datos final del instituto, se reunió información que permitió realizar el
levantamiento de requerimientos y un análisis de los mismos para determinar
cómo sería el procedimiento para el manejo de los datos de los especímenes una
vez han sido recolectados en campo y se desee que estos formen parte de la
colección del ICN.

A partir de la información recolectada, se aplicaron las fases que plantea el modelo

de proceso unificado obteniendo como resultado los modelos de ingeniería
pertinentes.

7.1 FASE DE INICIO

Como resultado de esta fase se obtuvo el modelo funcional del prototipo de

software, donde se encuentra:

• La definición detallada del prototipo que se desarrolló.

• Los requerimientos funcionales y de persistencia.
• Los diagramas de casos de uso y la especificación de cada uno en formato
extendido.
• El modelo de interfaz de usuario.

Este conjunto de ítems especifican una parte de la arquitectura del prototipo.

7.2 FASE DE ELABORACIÓN

Como resultado de esta fase se obtuvo el modelo estructural y dinámico del

prototipo de software, donde se encuentran:

• El diagrama de clases.
• El diagrama relacional.
• Los diagramas de máquinas de estado.
• Los diagramas de secuencia.

34
 • El mapa de navegación.
• Diagrama de despliegue.

Para mayor claridad del diagrama de clases y diagrama relacional, se elaboraron

los diccionarios de clases y de datos en donde se explican en detalle las diferentes
características de los componentes de dichos diagramas.

Los modelos de este prototipo ya mencionados fueron elaborados a través de la

herramienta de modelado y diseño visual basada en UML “Enterprise Architect”
[35]. Se encuentran en un único archivo dividido en carpetas como se muestra en
la Figura 10:

Figura 10. Organización del modelamiento del prototipo. Fuente. Este trabajo.

El archivo se encuentra dentro del CD que se adjunta en la ruta

2.Modelamiento/ModeladoPlantaeToSpecify2016.eap, además de estar disponible
en la página Web del grupo de investigación ARQUISOFT.

7.3 FASE DE CONSTRUCCIÓN

Como resultado de esta fase se obtuvo el prototipo de software construido en

lenguaje de programación Java bajo el paradigma de programación orientada a
objetos, este prototipo tiene conformidad frente a los modelos obtenidos en las
fases anteriores.

El prototipo fue exportado a un archivo .WAR, dentro del cual se encuentra el

código fuente del prototipo que está dividido en paquetes de la siguiente manera:
• src/modelo.logica: se encuentran los elementos de lógica de negocio, son
archivos con extensión java.
• src/viewModel: son los elementos que actúan como controlador de la
interfaz gráfica que también son archivos con extensión java.
• WebContent/paginas: son los elementos de la interfaz gráfica de usuario

35
 que son archivos con la extensión zul.
De igual manera se adjunta el script de creación de la base de datos y el script
para insertar los datos iniciales necesarios para el funcionamiento del prototipo.

7.4 FASE DE TRANSICIÓN

En esta fase se realizaron las pruebas unitarias, de integración y las pruebas

funcionales al prototipo, posteriormente se presentó y entregó el prototipo obtenido
a partir de las fases anteriores, junto con la siguiente documentación: manual de
usuario, guía de instalación, entre otros.

El prototipo se puede desplegar en un servidor de aplicaciones como Tomcat y se

puede obtener en el CD adjunto en la ruta 3. Prototipo/PlantaeToSpecify.war o en
la página del grupo Arquisoft.

36
 8. MODELO FUNCIONAL

8.1 DEFINICIÓN DE POSIBLES ACTORES Y RESPONSABILIDADES

A partir de la formulación del problema se identifican y definen los siguientes roles:

• Recolector: Usuario que realizará el cargue del archivo CSV al prototipo.

Podrá editar, generar la etiqueta o eliminar los especímenes que desee,
además de enviarlos como solicitudes de inclusión y para que sean
almacenados en la base de datos del ICN.

• Validador: Usuario que verificará la información de la solicitud de inclusión

de los especímenes enviados por los recolectores y posteriormente
autorizará o rechazará, según sea el caso.

• Administrador: Usuario que podrá crear, editar, asociarles roles y desactivar

usuarios que podrán interactuar con el sistema.

De acuerdo a cada uno de los roles descritos anteriormente, el prototipo permitirá

hacer uso de las siguientes funcionalidades:

8.1.1 Rol recolector

Una vez el biólogo haya capturado la información de los especímenes

recolectados en campo a través del aplicativo móvil Plantae, conecta su
dispositivo móvil a un computador e ingresa la URL en un navegador WEB podrá:

• Realizar el cargue del archivo generado por Plantae que contiene los datos
de los especímenes recolectados en campo para iniciar la migración de los
datos a la base de datos intermedia.

Si la migración de los datos es exitosa podrá:

• Visualizar la información asociada a cada espécimen.
• Editar la información de los especímenes.
• Seleccionar los registros a ser incluidos en la base de datos del ICN y
enviarlos al validador para la verificación y validación de la información.
• Generar e imprimir las etiquetas de cada espécimen.
• Visualizar el estado en el que se encuentran los especímenes en la base de
datos del aplicativo.
• Realizar búsquedas en el aplicativo de acuerdo a un criterio.

37
Si la migración de los datos no es exitosa:
• Se notificará inmediatamente al usuario por medio de un mensaje en el
aplicativo el fallo en el cargue del archivo y el motivo de dicho fallo.

8.1.2 Rol validador

Un usuario con rol de validador podrá:

• Consultar los especímenes que le han sido enviados por los recolectores
para su validación.
• Agregar la información como el código de colección y código de barras, si
determina que sí debe ser incluido en la base de datos del ICN.
• Rechazar una solicitud de inclusión si determina que el espécimen no debe
ser incluido en la base de datos del ICN.
• Migrar los datos de los especímenes que son aprobados a la base de datos
del ICN.
• Ver un histórico de los especímenes que han sido migrados a través del
aplicativo a la base de datos del ICN.

8.1.3 Rol administrador

Un usuario con rol de administrador podrá:

• Consultar los usuarios que pueden acceder al prototipo.

• Crear nuevos usuarios.
• Editar usuarios ya creados.
• Visualizar los datos de un usuario.
• Asignar roles a los usuarios.

38
8.2 DEFINICIÓN DE REQUERIMIENTOS

8.2.1 Requerimientos funcionales

A continuación se relacionan los requerimientos funcionales del prototipo:

Tabla 1. Requerimientos funcionales

CÓDIGO REQUERIMIENTO DESCRIPCIÓN
RFU001 Administrar usuarios. Permite el registro de usuarios que
interaccionarán con el sistema, su
activación y desactivación, además
de la asignación de roles que
determinan las acciones que puede
realizar de acuerdo a este. Solo el
administrador del prototipo puede
acceder a esta funcionalidad.
RFU002 Controlar el acceso. Se controla el acceso; es decir, solo
los usuarios registrados y
autorizados pueden acceder a las
funcionalidades del prototipo según
su(s) rol(es).
RFU003 Seleccionar y cargar el archivo Permite al biólogo seleccionar el
csv. archivo con extensión .csv que
generó el aplicativo del dispositivo
móvil Plantae y que se encuentra
almacenado en este para iniciar el
cargue del archivo.
RFU004 Generar mensajes de Genera mensajes de notificación
notificación. cuando se haya o no podido
realizar el cargue del archivo,
adicionalmente cuando no haya
sido exitosa la migración de la base
de datos intermedia a la base de
datos del ICN.
RFU005 Buscar y consultar los registros El biólogo puede realizar la
que fueron migrados. búsqueda y consulta de los
registros migrados.
RFU006 Editar o eliminar los registros. Permite al biólogo editar o eliminar
los registros que fueron migrados
del archivo, sólo sí no ha sido

39
 CÓDIGO REQUERIMIENTO DESCRIPCIÓN
enviada la solicitud de migración a
la base de datos del ICN.
RFU007 Seleccionar y enviar los Los registros seleccionados se
especímenes que el recolector almacenan con un estado definido,
requiere que sean a la espera de la validación y
almacenados en la base de confrontación de la información con
datos del ICN. el ejemplar físico.
RFU008 Generar las etiquetas con una Permite generar e imprimir
plantilla establecida por el ICN. etiquetas de los especímenes cuya
información haya sido obtenida
mediante la aplicación móvil
Plantae y esté cargada en el
aplicativo.
RFU009 Editar los especímenes Permite al rol validador validar o
enviados por el recolector al agregar el código de barras y
usuario validador. código de colección a los registros
antes de ser migrados a la base de
datos del ICN.
RFU010 Migrar los especímenes de la Permite al validador migrar a la
base de datos intermedia a la base de datos del ICN, los
base de datos del ICN. especímenes que cumplen con los
requisitos establecidos por el ICN y
se encuentren almacenados en la
base de datos intermedia.
RFU011 Consultar el estado de los Permite consultar el estado del
especímenes. espécimen durante todo el proceso
de migración a la base de datos del
ICN.
RFU012 Visualizar el histórico de los Permite visualizar los registros que
registros que fueron migrados a fueron migrados desde la base de
la base de datos del ICN. datos intermedia a la base de
datos del ICN.
RFU013 Visualizar el histórico de los Permite ver el histórico de los
archivos que han sido cargados archivos que han sido cargados en
en el prototipo. el prototipo. Indicando la cantidad
de registros y la fecha del cargue
del archivo.

40
8.3 REQUERIMIENTOS ESPECÍFICOS DE INTERFACES

8.3.1 Interfaces de usuario

El prototipo de software podrá desplegar su interfaz gráfica a través de un

navegador de internet: Google Chrome (versión 32 o superior) o Mozilla Firefox
(versión 37 o superior). Además la interfaz del usuario debe ser fácil de usar para
todos los roles.

8.3.2 Interfaces de software

El prototipo de software que se pretende desarrollar permitirá la migración de los

especímenes seleccionados, verificados y validados de la base de datos
intermedia a la base de datos oficial del ICN.

8.4 PROTOCOLOS DE COMUNICACIÓN

El prototipo, al ser de entorno WEB, usará el protocolo de transferencia de

hipertexto (HTTP) como protocolo de comunicación ya que su esquema petición-
respuesta entre un cliente y un servidor permite obtener la funcionalidad requerida
por el prototipo.

8.5 REQUERIMIENTOS DE PERSISTENCIA

El prototipo debe permitir el almacenamiento de:

✔ Las credenciales de acceso de los usuarios que podrán acceder a las

funcionalidades del mismo.
✔ Los datos que fueron exportados del dispositivo móvil y migrados al
aplicativo.
✔ Los cambios que se realicen a los registros en los distintos pasos del
proceso de migración e inclusión de especímenes a la base de datos del
ICN.

41
8.6 MODELO FUNCIONAL BASADO EN CASOS DE USO

Luego del análisis de los requerimientos del prototipo y su alcance se realiza un

modelo funcional basado en casos de uso (Figura 11) el cual describe la
funcionalidad total del prototipo de software, está compuesto por 35 casos de uso
agrupados en 6 módulos.

42
uc Casos de uso

Módulo de control de acceso Módulo de selección y cargue de archivos

CU003 Validar CU009 Guardar

existencia de usuario archivo
«include» CU008 Cargar «extend»
CU002 Iniciar
archivo «i nclude»
sesión
«extend» CU011 Cancelar CU010 Refrescar listado
«inclu de» cargue de de histórico de archivos
CU004 Habilitar «exten d»
archivo cargados
menú según rol
«extend»
«extend»
CU006 Gestionar
archivos de CU007 Listar histórico
CU001 Iniciar «includ e»
CU005 Cerrar especímenes de archivos cargados
Aplicación
sesión

Módulo de gestión de especímenes

Módulo de consulta y aprobación de solicitudes de inclusión para aprobación

CU014 Ver
CU013 Listar detalles CU016 Cancelar
especímenes espécimen edición espécimen
Estos extend son
CU027 Mostrar CU025 Listar excluyentes: si se
detalles de solicitud solicitudes de selecciona la
Usuario «extend»
de inclusión inclusión «extend» opción guardar no
«i ncl ude» «extend»
CU015 Editar se podrá cancelar
espécimen la edición, y si se
«extend»
«in clude»
CU012 Gestionar selecciona la
CU028 Mostrar
especímenes opción cancelar no
información a
se podrá guardar
migrar CU024 Consultar «extend»
«extend » CU018 Filtrar «extend» la edición
solicitudes de
especímenes
inclusión
«extend» « extend» CU017 Guardar
Estos extend son «e xtend» edición
CU029 Aprobar Validador Recolector
excluyentes: si el solicitud CU019 Eliminar espécimen
registro se «extend»
CU020 Exportar
«e xtend» espécimen
aprueba NO podrá etiqueta
ser rechazado, y
CU026 Filtrar
si ya fue
CU030 Rechazar solicitudes de Administrador
rechazado no Módulo de selección y envío de especímenes
solicitud inclusión
podrán ser
aprobado
Módulo de gestión de usuarios CU021 CU022 Listar
Seleccionar especímenes para
« include»
espécimen envío
CU031 Listar
usuarios
« extend»
«extend» «extend»
CU035 Filtrar CU023 Enviar
usuarios especímenes para
«extend»
CU032 Crear
«extend» inclusión
usuario

CU034 Modificar
CU033 Consultar
usuario
usuario

Figura 11. Diagrama general de casos de uso. Fuente. Este trabajo.

A continuación se presenta en formato extendido cada uno de los 35 casos de
uso, para facilitar la lectura se presentan de acuerdo al módulo al que pertenecen.

8.6.1 Módulo de control de acceso

Como su nombre lo indica este módulo es el encargado de controlar el acceso de

los usuarios al prototipo: verificar las credenciales del usuario y su estado, habilitar
las opciones del prototipo a las cuales el usuario tiene acceso y cerrar la sesión
una vez el usuario desee finalizarla.

uc Casos de uso

M ó d u lo d e co n tro l d e a cce so

CU003 Validar
existencia de usuario

« i n cl u d e »

CU004 Habilitar menú CU002 Iniciar sesión

según rol « i nclu de »

« e xte n d »
« e xte n d »

CU005 Cerrar sesión CU001 Iniciar Aplicación

Usuario

Figura 12. Diagrama de casos de uso del módulo de control de acceso. Fuente.
Este trabajo.

44
 Tabla 2. Iniciar aplicación
CASO DE USO
Código CU001 Nombre Iniciar aplicación
Actores Usuario
Tipo Primario X Secundario Opcional
Descripción El usuario ingresa la URL en el navegador WEB posteriormente
el sistema le mostrará la ventana donde el usuario se
autenticará.
Pre-condición Tener instalado en el computador un navegador WEB y tener
conexión a Internet.
Post-condición Mostrar ventana de control de acceso si hay respuesta del
servidor.
ESCENARIO
act CU001 Iniciar Aplicación

Usuario Sistema

Ini ci o

Ingresar la URL de la
aplicación en el Establecer conexión con
nav egador Web y dar el serv idor
Enter

NO
Mostrar mensaj e de ¿Conexión
error de conexión exi tosa?

SI

Mostrar v entana de inicio

de sesión con sus
respectiv as opciones

Fin

45
 Tabla 3. Iniciar sesión
CASO DE USO
Código CU002 Nombre Iniciar sesión
Actores Usuario
Tipo Primario X Secundario Opcional
Descripción El usuario ingresa usuario y contraseña en la ventana de control
de acceso y selecciona la opción aceptar.
Pre-condición Cargar el aplicativo a través del navegador WEB.
Post-condición Cargar la página principal donde se despliegan las opciones de
menú de acuerdo al rol o los roles o mostrar un mensaje de
“Usuario y/o contraseña no validos” si el usuario ingresó el
usuario o la contraseña incorrecta.
ESCENARIO
act CU002 Iniciar sesión

Usuario Sistema

In ici o

Ingresar credenciales de Mostrar v entana de inicio

acceso de sesión
no m bre Usuario con traseñ a

nom breUsua rio contra seña

Elige la opción Limpiar campos
nom breUsua rio [Cancelar]
co ntrase ña
[Acep tar]

nom breUsua rio

Validar existencia Mostrar mensaj e

de usuario "Usuario y/o
contraseña no
v álidos"
usuario ConAcceso

[NO]
u su arioCo nAcceso
!= nul l

[SI]

usuari oConAcce so
contraseña

Cifrar contraseña de
entrada [NO]

con traseñ aBD contraseñaCi frada

co ntraseñ aBD co ntra se ñaCifrada

Comparar contraseña de
entrada cifrada con
contraseña de BD

¿Contraseña es
váli da?

[SI]

Verificar estado del

usuario

¿esta do Mostrar mensaj e

== activo? [NO ] "Usuario inactiv o"

usuario

Habilitar menú
según rol

Fin al

46
 Tabla 4. Validar existencia de usuario
CASO DE USO
Código CU003 Nombre Validar existencia de usuario
Actores Sistema
Tipo Primario X Secundario Opcional
Descripción El sistema valida contra la base de datos si el usuario y
contraseña ingresados se encuentran en la base de datos y
retorna el usuario con acceso que corresponde al usuario
ingresado y que se encuentra almacenado en la base de datos.
Pre-condición El usuario ingresa su usuario, contraseña y selecciona la opción
aceptar.
Post-condición Desplegar opciones de menú según el rol o los roles.
Mostrar mensaje si el usuario y contraseña son incorrectos.
Mostrar mensaje si el usuario no se encuentra activo.
ESCENARIO
act CU003 Validar existencia de usuario

Validar existencia de usuario

Buscar Usu ario «d atasto re»

nombreUsuario en
Base de datos
n om b reUsua rio base de datos intermedia
n om b reUsuario
:String intermedia
usu arioConAcceso

El o bjeto usua rio

¿Existe conti ene el
nom bre de no m breUsuari o,
usuari o? contraseña , rol, estad o,
en tre o tros.
[NO]
[SI]

retornar retornar
usuarioConAcceso usuarioConAcceso
null
usuarioConAcce so
u suario ConAcceso

usuarioCon Acceso

47
 Tabla 5. Habilitar menú según rol
CASO DE USO
Código CU004 Nombre Habilitar menú según rol
Actores Sistema
Tipo Primario X Secundario Opcional
Descripción El sistema verifica los roles del usuario y habilita las opciones
de menú dependiendo de dichos roles.
Pre-condición El usuario ingreso unas credenciales válidas y dio clic en
iniciar sesión
Post-condición Desplegar opciones de menú según el rol o los roles del
usuario.
ESCENARIO
act CU004 Habilitar menú según rol

Habilitar menú según rol

usuario : Obtener lista de roles del

Usua rioConAcce so usua rio usuario

l ista Ro les

¿h ay m ás
ro les?

[SI]

¿rol =
adm i nistrad or?

[SI]

Habilitar opción de menú [NO]

administración de
usuarios

¿ro l =
recol ector?

[SI] [NO]

Habilitar opciones de [NO]

menú importar datos de
especímenes, gestión de
especímenes y Env ío de
solicitudes de inclusión

¿ro l =
valid ador?

[SI]

Habilitar opción de menú

solicitudes de inclusión

Fi n

48
 Tabla 6. Cerrar sesión
CASO DE USO
Código CU005 Nombre Cerrar sesión
Actores Usuario
Tipo Primario X Secundario Opcional
Descripción El usuario elige la opción de menú cerrar sesión. El sistema
borra los datos de la sesión, retornando al usuario a la ventana
de control de acceso.
Pre-condición El usuario debe haber iniciado sesión.
Post-condición Mostrar ventana de control de acceso.
ESCENARIO
act CU005 Cerrar Sesión

Usuario Sistema

Inicio

Elige la opción cerrar Borrar datos de sesión

sesión

Mostrar v entana de inicio

de sesión

Fi n

49
8.6.2 Módulo de selección y cargue de archivos

Este módulo contiene los casos de uso correspondientes al cargue de

especímenes en el aplicativo a través de un archivo separado por comas (CSV). A
este módulo solo tienen acceso los usuarios con el rol “Recolector”.

uc Casos de uso

M ódu lo d e se lección y cargu e de archi vo s

CU008 Cargar CU009 Guardar

archiv o «exte nd» archiv o

«e xtend» «in cl ude»

« extend»
CU011 Cancelar
cargue de archiv o CU010 Refrescar listado de
histórico de archiv os
cargados

CU006 Gestionar archiv os

de especímenes CU007 Listar histórico de
«i nclud e» archiv os cargados
Recolector

Figura 13. Diagrama de casos de uso del módulo de selección y cargue de

archivos. Fuente: Este trabajo.

50
 Tabla 7. Gestionar archivos de especímenes
CASO DE USO
Código CU006 Nombre Gestionar archivos de especímenes
Actores Recolector
Tipo Primario X Secundario Opcional
Descripción El recolector elige la opción importar datos de especímenes, el
sistema carga el formulario de importar datos de especímenes
y lista el histórico de archivos cargados.
Pre-condición Tener una sesión activa y el rol del usuario sea recolector.
Post-condición Habilitar la opción de cargar archivo y listar el histórico de
archivos cargados.
ESCENARIO
act CU006 Gestionar archiv os de especímenes

Recolector Sistema

Ini cio

Clic en la opción de menú Desplegar formulario de

importar especímenes importar especímenes
usua rio Co nA cceso

u suario Co nA cce so

Listar histórico de archiv os

cargados

L istado de reg istros

Listado de registro s

Mostrar listado de
archiv os
Fi n

51
 Tabla 8. Listar histórico de archivos guardados
CASO DE USO
Código CU007 Nombre Listar histórico de archivos guardados
Actores Sistema
Tipo Primario X Secundario Opcional
Descripción El sistema consulta en la base de datos todos los archivos que
hayan sido subidos al prototipo por el usuario conectado.
Pre-condición Haber dado clic en la opción de menú importar datos de
especímenes.
Post-condición Mostrar el histórico de archivos cargados por el usuario.
ESCENARIO
act CU007 Listar histórico de archiv os cargados

Listar histórico de archiv os cargados

usua ri oCon Acceso :

UsuarioConA cce so
usuarioConAcceso
«BD Interm edia»
Consultar registros de
Archiv o
archiv os cargados

Listar registros
Listado de Listado de
registros registros

52
 Tabla 9. Cargar archivo
CASO DE USO
Código CU008 Nombre Cargar archivo
Actores Recolector
Tipo Primario X Secundario Opcional
Descripción El recolector elige la opción cargar archivo y el sistema
desplegará la ventana que permitirá la búsqueda y selección del
archivo, una vez el usuario seleccione el archivo el sistema
valida el tipo de archivo, si es válido el sistema habilita la opción
guardar.
Pre-condición Tener la opción de menú importar datos de especímenes
abierta.
Post-condición Habilitar la opción de guardar archivo o cancelar cargue archivo
o generar mensaje de error y listar el histórico de archivos
cargados.
ESCENARIO
act CU008 Cargar archiv o

Recolector Sistema

In i cio

Clic en cargar archiv o Desplegar v entana de

búsqueda y cargue de
archiv os

Buscar y seleccionar
archiv o almacenado en el
dispositiv o móv il

archi vo

archi vo

Seleccionar opción
a rch ivo
[Acep ta r]

archivo

Validar tipo de archiv o

¿va li d aci ón [Can ce l ar]

co rrecta?

[SI]

Habilitar botón guardar y [NO]

botón cancelar

Mostrar mensaj e
Selecciona aceptar
"Archivo incorrecto"

Limpiar ruta del archiv o

seleccionado
Fin

53
 Tabla 10. Guardar archivo
CASO DE USO
Código CU009 Nombre Guardar archivo
Actores Recolector
Tipo Primario X Secundario Opcional
Descripción El recolector elige la opción guardar y el sistema almacena las
características del archivo y procesa los registros
(especímenes) que contiene, limpia y carga nuevamente el
listado del histórico de archivos cargados.
Pre-condición Realizar la búsqueda, selección y cargue del archivo.
Post-condición Actualizar el listado del histórico de archivos cargados,
procesar los registros (especímenes) que almacenaba el
archivo cargado.
ESCENARIO
act CU009 Guardar archiv o

Recolector Sistema

Inicio

Elige la opción de guardar

archiv o
archi vo

Mostrar mensaj e de ¿Ha y m ás

Elige la opción aceptar
"archiv o procesado regi stros?
[NO ]
exitosamente"

usuario Con A cce so [S I]

archi vo
« B D Interm ed ia »
Guardar registro Especímenes
[S I]

Mostrar mensaj e de error

NO ¿Crea ción
de creación y deshacer
toda la transacción correcta?

usu arioConA cce so

Refrescar listado de
histórico de archiv os
cargados
l ista do d e registro s

l ista do d e registro s

Actualizar listado de
registros en v entana
Fina l

54
 Tabla 11. Refrescar listado de histórico de archivos cargados
CASO DE USO
Código CU010 Nombre Refrescar listado de histórico de archivos
cargados
Actores Sistema
Tipo Primario X Secundario Opcional
Descripción El sistema refrescará el listado del histórico de los archivos
cargados.
Pre-condición Almacenar un nuevo archivo.
Post-condición El sistema se mantiene con los datos consistentes después de
la consulta a la base de datos intermedia.
ESCENARIO
act CU010 Refrescar listado de histórico de archiv os cargados

Refrescar listado de histórico de archiv os cargados

u suari oCon Acceso :

Usu ari oConAcce so u su ari oConAcce so
«B D Interm e dia »
Consultar registros de
Archiv o
archiv os cargados

Actualizar listado de
registros

l i sta do d e
regi stros

l istado de
regi stro s

55
 Tabla 12. Cancelar cargue de archivos
CASO DE USO
Código CU011 Nombre Cancelar cargue de archivos
Actores Recolector
Tipo Primario X Secundario Opcional
Descripción El sistema cancela la carga de un archivo.
Pre-condición Tener seleccionado un archivo para ser cargado.
Post-condición El sistema deja el prototipo en el menú importar datos de
especímenes abierta
ESCENARIO
act CU011 Cancelar cargue de archiv o

Recolector Sistema

Ini cio

Elige la opción de
cancelar cargue de Limpiar ruta de archiv o
archiv o

Deshabilitar botones de
Guardar archiv o y
Cancelar archiv o
Fin

56
8.6.3 Módulo de gestión de especímenes

Este módulo permite la visualización, edición, eliminación de especímenes y la

generación de etiquetas de los mismos. A este módulo solo tienen acceso los
usuarios con rol “Recolector”.

uc Casos de uso

M ódul o de gesti ón de especím enes

CU013 Listar
especímenes CU014 Ver detalles CU015 Crear opciones CU016 Eliminar
espécimen «i nclude » desplegadas «inclu de» opciones desplegadas

«exte nd»
«in cl ude» «extend»
CU017 Editar CU018 Cancelar E stos extend so n
espécimen «extend» edición espécimen excluyentes: si se
se lecci ona la opció n
CU012 Gestionar gu ardar no se podrá
especímenes «extend» cancela r la edi ci ón, y
si se sel ecciona la
«exte nd» CU020 Filtrar CU019 Guardar op ci ón cancela r no se
espécimen edición espécimen po drá guardar l a
Recolector « extend»
ed ición
«exten d»

CU021 Eliminar
CU022 Exportar espécimen
etiqueta

Figura 14. Diagrama de casos de uso del módulo de gestión de especímenes.

Fuente: Este trabajo.

57
 Tabla 13. Gestionar espécimen
CASO DE USO
Código CU012 Nombre Gestionar espécimen
Actores Usuario
Tipo Primario X Secundario Opcional
Descripción El usuario elige la opción de menú gestión de especímenes, el
sistema desplegará la ventana y listará los especímenes.
Pre-condición El usuario selecciona la opción de menú gestión de
especímenes.
Post-condición Mostrar el listado de los especímenes.
ESCENARIO
act CU012 Gestionar especímenes

Recolector Sistema

Ini ci o

Selecciona opción de Cargar v entana de gestión

gestión de especímenes de especímenes

usua ri oConAcceso

u suari oConAcceso

Listar Especímenes

li sta de esp eci m e nes

li sta de esp eci m e nes

Mostrar listado de
especímenes
Fin

58
 Tabla 14. Listar especímenes
CASO DE USO
Código CU013 Nombre Listar especímenes
Actores Sistema
Tipo Primario X Secundario Opcional
Descripción El sistema listará los especímenes que pertenecen al usuario.
Pre-condición Seleccionar la opción de menú especímenes.
Post-condición Se listarán los especímenes que pertenecen al usuario.
ESCENARIO

act CU013 Listar especímenes

Listar especímenes

Realizar búsqueda de « BD In te rm e d ia »
especímenes Especímenes
usu ari o Con Acce so
l ista d e re gi stro s

So l o l ista rá l o s
l ista d e
e spe cím e n es q u e
re gi stro s
p e rte n ece n a l u sua ri o.
Cargar lista con registros

l i sta d e
e spe cím e n es
l i sta de
e sp e cím e ne s

59
 Tabla 15. Ver detalles espécimen
CASO DE USO
Código CU014 Nombre Ver detalles espécimen
Actores Recolector
Tipo Primario X Secundario Opcional
Descripción El recolector selecciona la opción ver detalles de uno de los
especímenes listados por el sistema, el sistema despliega la
información asociada al espécimen seleccionado.
Pre-condición Dar clic en la opción ver detalles de un espécimen.
Post-condición Mostrar detalles del espécimen, si el estado del espécimen es
diferente de enviado y aprobado se habilitará la opción de editar
espécimen.
ESCENARIO
act CU014 Ver detalles espécimen

Recolector Sistema

In i cio

Selecciona la opción v er e sp e cim e n CU015A Crear opciones

detalles sobre uno de los desplegadas
especímenes listado e sp é cim e n
esp e cim e n

e sp écim e n

Verificar estado del

espécimen
e spé ci m e n

¿Esta d o != E n vi ad o & &

E sta d o != Ap ro b a d o?

[S I]

Habilitar opción de editar

[NO ]

e sp é ci m en

Desplegar información del

espécimen
esp é cim en
Fi n

60
 Tabla 16. Editar espécimen
CASO DE USO
Código CU015 Nombre Editar espécimen
Actores Recolector
Tipo Primario X Secundario Opcional
Descripción El recolector selecciona la opción editar, el sistema habilita los
campos que se podrán editar y las opciones guardar y cancelar
y deshabilita la opción editar.
Pre-condición Haber seleccionado la opción ver detalles de un espécimen
Post-condición Los campos editables quedan habilitados para edición.
ESCENARIO
act CU015 Editar espécimen

Recolector Sistema

Ini cio
La inform ación editabl e es la rel acionada con :
Evento de colecci ón
Habilitar campos editables Ubicaci ón
Elige la opción editar T axonom ía
del registro
Determ i nación
Atributos d el espéci m e n
Planta
Hoja
Fl or
Fruto
Infl orescencia
Habilita las opciones
T all o
guardar y cancelar
Raíz

Deshabilita opción editar

Fi n

61
 Tabla 17. Cancelar edición espécimen
CASO DE USO
Código CU016 Nombre Cancelar edición espécimen
Actores Recolector
Tipo Primario X Secundario Opcional
Descripción El recolector selecciona la opción cancelar, el sistema deshace
los cambios realizados por el usuario, deshabilita los campos
editables, así mismo deshabilita las opciones de cancelar y
guardar y habilita nuevamente la opción de editar.
Pre-condición Haber seleccionado la opción editar
Post-condición Deshacer los cambios y deshabilitar los campos editables.
ESCENARIO
act CU016 Cancelar edición espécimen

Recolector Sistema

In icio

Elige opción cancelar Deshacer cambios

Deshabilitar campos
editables

Deshabilitar opciones
guardar y cancelar

Habilitar opción editar

Fin

62
 Tabla 18. Guardar edición espécimen
CASO DE USO
Código CU017 Nombre Guardar edición espécimen
Actores Recolector
Tipo Primario X Secundario Opcional
Descripción El recolector selecciona la opción guardar, el sistema verifica si
hay cambios en los formularios y procede a ejecutar la
actualización del registro (espécimen), finalmente notifica al
usuario si la actualización fue o no correcta.
Pre-condición Haber seleccionado la opción editar
Post-condición Actualizar el registro con los nuevos cambios.
ESCENARIO
act CU017 Guardar edición espécimen

Recolector Sistema

Ini ci o

Elige opción guardar Verificar cambios

realizados

¿Ha y ca m bi o s e n
l a i n form a ci ó n ?
[SI]

« Base de d atos i ...

Actualizar registro Base de datos
intermedia

¿Actua li zaci ón [NO] Mostrar mensaj e de error [NO ]

corre cta ? en actualización

[SI]

Mostrar mensaj e de
actualización correcta

Elige opción ok
Recuperar v alores
originales

Deshabilitar campos
editables

Habilitar opción editar

Deshabilitar opción
cancelar y guardar
Fi n

63
 Tabla 19. Filtrar espécimen
CASO DE USO
Código CU018 Nombre Filtrar espécimen
Actores Recolector
Tipo Primario X Secundario Opcional
Descripción El recolector ingresa un valor en los campos de filtro. El sistema
mostrará los resultados de la búsqueda de acuerdo a los filtros
ingresados.
Pre-condición El recolector selecciona la opción de menú Especímenes.
Post-condición Listar los especímenes que cumplan con los filtros ingresados
por el recolector
ESCENARIO
act CU018 Filtrar especímenes

Recolector Sistema

Inici o

Se puede fil trar por códi go

Ingresa un v alor en los Filtrar especímenes según
de recolección, fecha de
campos de filtro v alorFiltros
recolecció n y estado del
valorFil tros valorFi ltros espéci m en

Actualizar listado en la
v entana.
Fin

64
 Tabla 20. Eliminar espécimen
CASO DE USO
Código CU019 Nombre Eliminar espécimen
Actores Recolector
Tipo Primario X Secundario Opcional
Descripción El recolector selecciona los especímenes que desea eliminar y
elige la opción eliminar, el sistema desplegará una ventana
donde el recolector confirmará la acción de eliminación. Sí el
recolector confirma la acción el sistema elimina el o los
registros seleccionados si y solo si el estado del espécimen es
diferente a enviado, aprobado o pendiente, en cuyo caso no
podrán ser eliminados.
Pre-condición Seleccionar los especímenes a eliminar.
Post-condición Actualizar los listados de los especímenes en donde se refleja
el cambio realizado.
ESCENARIO
act CU019 Eliminar espécimen

Recolector Sistema

Ini ci o

Selecciona los
especímenes que quiere
eliminar
l i sta E sp eci m e ne s

Mostrar v entana de
Elige la opción Eliminar
confirmación de
eliminación

Seleccionar opción

[A cep tar]
l i sta E sp e ci m e ne s

tamaño = Número de
especímenes
seleccionados
li staE sp e ci m e n es

li staE sp e ci m e n es

i=0, correctos=0,
incorrectos=0
li staE sp e ci m e n es

¿i <ta m a ño ?

[S I]
li staE sp e ci m e n es
[NO ]
Tomar registro i de la lista

¿e stad o Espe cim en != Actualizar listado de

e n vi a d o & & especímenes
e sta do E sp eci m e n != [Can cel a r]
a p ro ba d o
& &e sta do E sp eci m e n
!= p e nd i en te ?
[S I]

«B D Inte rm e di a »
Borrar registro de la base
espécimen
de datos

[NO ]

¿B orra do exi to so?

Mostrar mensaj e de
resultado del borrado con
[SI] cantidad de borrados y
NO cantidad de no borrados

incorrectos++ correctos++

i++

Elige la opción aceptar

Fin

65
 Tabla 21. Exportar etiqueta
CASO DE USO
Código CU020 Nombre Exportar etiqueta
Actores Recolector
Tipo Primario X Secundario Opcional
Descripción El recolector selecciona uno o varios especímenes y
posteriormente elige la opción generar etiqueta, el sistema
genera un archivo pdf con el total de etiquetas correspondiente
y es enviado al navegador Web para que el archivo sea
descargado
Pre-condición Seleccionar especímenes.
Post-condición Descargar etiqueta a través del navegador web.
ESCENARIO
act CU020 Exportar etiqueta

Recolector Sistema

In icio

Selecciona los
especímenes

Elige la opción generar
etiqueta
li sta do de
Crear lista de etiquetas e spe cím ene s tamanio = tamaño del
listad o d e l istado de listado de especímenes
li sta do d e
espe cím e ne s e sp ecím en es
e spe cím ene s
l istado de
l istado de e sp ecím en es
e sp ecím en es

i=0

listado de
esp ecím en e s

La in fo rm ació n q ue se ag rega en l a eti que ta

i <ta m a nio ? es tod a l a in form a ci ó n de l espé cim e n
dispo nib le rela ciona da con :

[SI] Eve nto de col ección

li stado de e spe cím e ne s Ub icaci ón
T a xon om ía
tomar espécimen i de la espéci m e n
Depe nd ien do del n a vega do r De term in ació n
lista generar etiqueta
web d el usua rio el a rchi vo se i++ Atribu tos d el e sp écim en
esp écim e n
de sca rga rá d ire ctam en te o se etiqu eta [NO] Pl anta
m o strará al usu a rio un m en saje Ho ja
pre gu nta n do le que acci ón agregar etiqueta a la lista de Flo r
de se a re ali zar sob re e l m ism o etiquetas Fru to
etiqu eta Infl o re sce ncia
T a llo
a rchi vo p df concatenar todas las Ra íz
Env iar archiv o pdf al etiquetas en un único
nav egador w eb archiv o pdf li sta de
Fin a rchivo pdf e tiqu eta s

66
8.6.4 Módulo de selección y envío de especímenes

En este módulo se le permite al recolector seleccionar los especímenes que desea

sean incluidos en la base de datos del ICN. A este módulo solo tienen acceso los
usuarios con el rol de “Recolector”.

uc Casos de uso

M ó dul o d e se le cció n y en vío de e sp ecím e nes

CU022 Listar
CU021 Seleccionar
especímenes para
espécimen « inclu de» env ío

Recolector
«e xten d»

CU023 Env iar

especímenes para
inclusión

Figura 15. Diagrama de casos de uso del módulo de selección y envío de

especímenes. Fuente. Este trabajo.

67
 Tabla 22. Seleccionar espécimen
CASO DE USO
Código CU021 Nombre Seleccionar espécimen
Actores Recolector
Tipo Primario X Secundario Opcional
Descripción El recolector selecciona la opción de menú solicitar inclusión de
especímenes y selecciona los especímenes que serán incluidos
en la base de datos del ICN, el sistema habilita la opción enviar
solicitud.
Pre-condición Seleccionar especímenes para solicitar su inclusión
Post-condición Habilitar la opción de enviar solicitud.
ESCENARIO
act CU021 Seleccionar espécimen

Recolector Sistema

In i ci o

u su ario Co nA cceso So lo tra e l o s re gistro s q ue

Elige la opción de menú Listar especímenes para
p erte ne cen a l reco l ecto r y
solicitar inclusión de env ío
cu yo s estad o s son
especímenes usua rioCon Acce so
"Carg a do " o "E ditad o "
li stado d e
e sp e cím e ne s

Marcar casilla de selección de Cargar listado de

especímenes para ser especímenes
env iados

Habilitar opción de env íar

especímenes

Fin

68
 Tabla 23. Listar especímenes para envío
CASO DE USO
Código CU022 Nombre Listar especímenes para envío
Actores Sistema
Tipo Primario X Secundario Opcional
Descripción El sistema listará todos los especímenes que pueden ser
enviados para su inclusión en la base de datos del ICN que le
pertenezcan al usuario.
Pre-condición El recolector seleccione la opción de menú solicitar inclusión de
especímenes.
Post-condición Cargar el listado de especímenes que pueden ser enviados
para su inclusión en la base de datos del ICN.
ESCENARIO
act CU022 Listar especímenes para env ío

Listar especímenes para env ío

«BD Interm edi a»

usuarioCo nA cceso : Consultar especímenes Especimen
UsuarioCo nA cceso
li stad o d e
e specím e nes
listado de Solo tra e lo s re gistros que
esp ecím en es perte ne cen a l reco l ector y
cuyo s estado s so n
Retornar listado de "Cargad o" o "E dita do"
especímenes

listado de
esp ecím en es lista do d e
esp ecím en es

69
 Tabla 24. Enviar especímenes para inclusión
CASO DE USO
Código CU023 Nombre Enviar especímenes para inclusión
Actores Recolector
Tipo Primario X Secundario Opcional
Descripción El recolector envía los especímenes que requiere sean
incluidos a la base de datos del ICN.
Pre-condición El recolector selecciona uno o más de los especímenes listados
y selecciona la opción enviar especímenes.
Post-condición El espécimen queda en estado enviado y a la espera de
aprobación.
ESCENARIO
act CU023 Env iar especímenes para inclusión

Recolector Sistema

Ini cio

Mostrar v entana de
Elige la opción de solicitar confirmación de solicitud
inclusión de especímenes de inclusión de
especímenes

Seleccionar opción

[Aceptar]
li stado de especím enes

tamaño = Calcular tamaño

del listado de
especímenes

li stado de especím enes

l istado de especím enes

i=0, correctos=0,
incorrectos=0
l istado de especím enes

¿i<tam año? Mostrar listado de

[NO] incorrectos

[SI]

l istado de especím enes

Tomar registro i de la lista

espéci m en

espécim en
Generar solicitud de [cancelar]
inclusión

espéci m en

espécim en «BD Interm edia»

Espécimen,
Actualizar estado del
solicitudes de
espécimen
inclusión
Generar mensaj e
"Actualización finalizada,
se habilitaron
¿Actuali zaci ón Agregar espécimen a la <<correctos>>
correcta? lista de incorrectos
[NO] especímenes para
v alidación, no fue posible
[SI] habilitar <<incorrectos>>
especímenes"

correctos++

i++ incorrectos++

Elige la opción
aceptar

Cerrar v entana de
confirmación de solicitud
de inclusión de
especímenes
Fin

70
8.6.5 Módulo de consulta y aprobación de solicitudes de inclusión para
aprobación

Módulo que le permite gestionar las solicitudes de inclusión, esto es: Consultarlas,
aprobarlas o rechazarlas. A este módulo solo tienen acceso los usuarios con el rol
de “Validador”.

uc Casos de uso

M ódulo de consulta y aprobación de solicitudes de inclusión para aprobación

CU027 Mostrar detalles de

solicitud de inclusión

CU025 Listar solicitudes de

inclusión

CU028 Mostrar
información a migrar «extend»
«include»

«extend»

CU029 Aprobar CU024 Consultar solicitudes de

Estos extend son solicitud «extend» inclusión
excluyentes: si el
registro se aprueba NO
podrá ser rechazado, y Validador
si ya fue rechazado no «extend»
podrán ser aprobado
CU030 Rechazar «extend»
solicitud

CU026 Filtrar solicitudes de

inclusión

Figura 16. Diagrama de casos de uso del módulo de consulta y aprobación de

solicitudes de inclusión. Fuente: Este trabajo.

71
 Tabla 25. Consultar solicitudes de inclusión
CASO DE USO
Código CU024 Nombre Consultar solicitudes de inclusión
Actores Validador
Tipo Primario X Secundario Opcional
Descripción El validador selecciona la opción de menú solicitudes de
inclusión y el sistema lista todas las solicitudes de inclusión de
especímenes.
Pre-condición Elegir la opción de menú “Solicitudes de inclusión”.
Post-condición El sistema lista las solicitudes de inclusión que hayan con
estado “Enviado”
ESCENARIO
act CU024 Consultar solicitudes de inclusión

Validador Sistema

In ici o

e sta d o Listar solicitudes de

Elige la opción Solicitudes
inclusión
de inclusión
e sta d o
listad o de soli citu d es

listad o de soli citu d es

Desplegar listado de
Selecciona una solicitud especímenes para ser
del listado aprobados

Habilitar opción "v er

más", "Aprobar solicitud"
y "Rechazar solicitud"
Fin sobre cada espécimen

72
 Tabla 26. Listar solicitudes de inclusión
CASO DE USO
Código CU025 Nombre Listar solicitudes de inclusión
Actores Sistema
Tipo Primario X Secundario Opcional
Descripción El sistema consulta en la base de datos intermedia las
solicitudes de inclusión que hayan con estado Enviado
Pre-condición Seleccionar la opción Solicitudes de inclusión
Post-condición Listar las solicitudes de inclusión
ESCENARIO
act CU025 Listar solicitudes de inclusión

Listar solicitudes de inclusión

«BD Interm e...

estado: Consultar registros
Solicitudes de
String listos para inclusión
estado inclusión

Listar solicitudes
de inclusión

li stado d e
sol i ci tud es li stado de
so li ci tudes

73
 Tabla 27. Filtrar solicitudes de inclusión
CASO DE USO
Código CU026 Nombre Filtrar solicitudes de inclusión
Actores Validador
Tipo Primario X Secundario Opcional
Descripción El validador ingresa un valor en los campos de filtro. El sistema
mostrará los resultados de la búsqueda de acuerdo a los filtros
ingresados.
Pre-condición El validador selecciona la opción de menú solicitudes de
inclusión.
Post-condición Listar las solicitudes de inclusión que cumplan con los filtros
ingresados por el validador
ESCENARIO
act CU026 Filtrar solicitudes de inclusión

Validador Sistema

Ini ci o

Se puede fil tra r por código de

Filtrar solicitudes de recolecció n, fech a de e nvío
Ingresar un v alor en los
inclusión según de la sol i ci tud y fecha de
campos de filtro
valorFi l tros val orFil tros v alorFiltros recolecció n

Actualizar listado en la
v entana
Fin

74
 Tabla 28. Mostrar detalles de solicitud de inclusión
CASO DE USO
Código CU027 Nombre Mostrar detalles de solicitud de inclusión
Actores Validador
Tipo Primario X Secundario Opcional
Descripción El validador elige la opción “Ver más” sobre cualquier solicitud
de inclusión listada por el sistema. El sistema despliega una
ventana con la información completa del espécimen asociado a
la solicitud de inclusión.
Pre-condición Seleccionar la opción Ver más de un espécimen.
Post-condición Mostrar formulario del espécimen.
ESCENARIO

act CU027 Mostrar detalles de solicitud de inclusión

Validador Sistema

Inicio

Elige la opción "Ver más" usuarioConA cceso «B D Interm edia»

sobre cualquier Cargar detalles del Espécimen
espécimen usuarioConA cceso espécimen
especim en

especim en

Desplegar información
adicional del espécimen
Fin

75
 Tabla 29. Mostrar información a migrar
CASO DE USO
Código CU028 Nombre Mostrar información a migrar
Actores Validador
Tipo Primario X Secundario Opcional
Descripción El validador elige la opción “Ver más” sobre cualquier solicitud
de inclusión listada por el sistema.
Pre-condición Seleccionar la opción Ver más de un espécimen.
Post-condición Mostrar formulario del espécimen.
ESCENARIO
act CU028 Mostrar información a migrar

Validador Sistema

Inicio

Cargar información del

Elige la opción datos a espécimen que será
specify migrada a specify

Desplegar información
adicional del espécimen
Fin

76
 Tabla 30. Aprobar solicitud
CASO DE USO
Código CU029 Nombre Aprobar solicitud
Actores Validador
Tipo Primario X Secundario Opcional
Descripción El validador selecciona la solicitud que va a aprobar y el
sistema le despliega la ventana para agregar los códigos para
inclusión, después de ingresarlos el validador da clic en aceptar
y el espécimen es migrado a Specify, además el registro es
actualizado.
Pre-condición Seleccionar la solicitud de inclusión del espécimen.
Post-condición El espécimen es ingresado en la base de datos oficial del ICN.
ESCENARIO
act CU029 Aprobar solicitud

Validador Sistema

In ici o

Habilita las opciones

Selecciona una de las Aprobar solicitud y
solicitudes de inclusión Rechazar solicitud

Desplegar v entana para

Elige la opción aprobar
insertar código de barras
espécimen
y código del herbario

Ingresa los códigos

solicitados

codi go Barra s,
codi go Col eccio n

Selecciona opción

[A ce ptar]

Desplegar cuadro de
Selecciona opción confirmación de
aprobación

[A ce ptar]

« BD ICN»
[Can ce la r]
Base de datos Insertar registros
oficial del ICN

«BD Interm ed i...

Cambiar estado de la
Solicitud inclusión
solicitud a aprobada

[Can ce la r]
«B D In te rm e ...
Cambiar estado del
Especimen
espécimen a Aprobado

Mostrar mensaj e de [NO ] ¿Actua li zació n

actualización incorrecta correcta ?

[S I]

Mostrar mensaje
Elige la opción aceptar "Espécimen ingresado en
la base de datos
correctamente"

Fi n

77
 Tabla 31. Rechazar solicitud
CASO DE USO
Código CU030 Nombre Rechazar solicitud
Actores Validador
Tipo Primario X Secundario Opcional
Descripción Una vez el validador selecciona una solicitud de inclusión y
elige la opción “Rechazar solicitud”, el sistema desplegará una
ventana donde le solicita al validador el motivo de rechazo de la
solicitud. Después de rechazar la solicitud el sistema actualizará
el estado de la solicitud de inclusión y del espécimen.
Pre-condición Seleccionar una solicitud de inclusión de espécimen.
Post-condición La solicitud de inclusión cambia a Rechazada y del espécimen
también se cambiará su estado.
ESCENARIO
act CU030 Rechazar solicitud

Validador Sistema

In ici o

Habilita las opciones

Selecciona una solicitud aprobar solicitar y
de inclusión rechazar solicitud

Elige la opción rechazar

solicitud

Desplegar v enta de
motiv o de rechazo

Ingresar observ aciones

acerca del rechazo

Seleccionar opción [Ca n ce l ar]

A ce p ta r

Mostrar cuadro de
Seleccionar opción
confirmación de rechazo

[Ca nce l a r]

[A ce p ta r]

« BD In te rm e d i ...
Actualizar registro en la
Espécimen,
base de datos
SolicitudInclusion

¿A ctu a li za ci ó n Mostrar mensaje de

co rre cta ? [NO ] actualización incorrecta

[S I]

Mostrar mensaj e de
actualización correcta

Elige la opción aceptar

Fi n

78
8.6.6 Módulo de gestión de usuarios

Módulo que permite la administración de los usuarios del prototipo. A este módulo
solo tienen acceso los usuarios con el rol de “Administrador”.

uc Casos de uso

M ódul o de g estión de usuarios

CU032 Crear usuario

«exten d»

CU031 Listar CU033 Consultar

usuarios «exten d» usuario

Administrador
«exten d»
«exten d»
CU034 Modificar
usuario
CU035 Filtrar
usuarios

Figura 17. Diagrama de casos de uso del módulo de gestión de usuarios. Fuente:
Este trabajo.

79
 Tabla 32. Listar usuarios
CASO DE USO
Código CU031 Nombre Listar usuarios
Actores Administrador
Tipo Primario X Secundario Opcional
Descripción El administrador ingresa a la opción de menú administración de
usuarios, el sistema consulta y le muestra los usuarios con
acceso almacenados en el mismo.
Pre-condición Seleccionar opción administración de usuarios.
Post-condición Mostrar lista de usuarios con acceso almacenados.
ESCENARIO
act CU031 Listar usuarios

Administrador Sistema

Inicio

Elige la opción «BD Interm edia»

Consultar usuarios del
administración de usuarioConAcceso
sistema
usuarios
listaUsuarios

listaUsuarios

Mostrar listado de
usuarios
Fin

80
 Tabla 33. Crear usuario
CASO DE USO
Código CU032 Nombre Crear usuario
Actores Administrador
Tipo Primario X Secundario Opcional
Descripción El administrador selecciona la opción agregar usuario, el
sistema despliega la ventana con el formulario de creación de
usuario, el administrador ingresa los datos del usuario.
Pre-condición Seleccionar la opción de agregar usuario.
Post-condición El nuevo usuario es creado.
ESCENARIO

act CU032 Crear usuario

Administrador Sistema

L o s ca m p o s d el form u la ri o so n :
In icio - Id e n ti fica ci ó n*
- No m b re *
- P ri m e r a p e ll id o *
- S e gu n d o a p el li do
- Co rre o e l ectró ni co
Desplegar v entana con - In stitu ci ón
Selecciona opción
agregar usuario formulario de creación de - Usu a ri o *
usuario - S e le ccio n a r esta d o * (A ctivo ,
i na cti vo )
- Co ntra señ a *
- S e le ccio n a r ro le s (reco le cto r,
Ingresar datos de usuario
va lid a d o r y a d m i ni stra d or)
_ _ _ __ _ _ _ __ _ _ _ __ _ _
d a to s d e re g istro * Ca m p o s o b li g ato rio s

Seleccionar opción

[A ce p ta r]

d a to s d e re g istro

Verificar campos
obligatorios

d a to s d e re g istro

¿ca m p o s
Resaltar campos o b lig a to rio
obligatorios [NO ] com pl e to s?

[SI]

d a to s d e re g istro
« B D In te rm e d ia »
usuarioConAcceso Registrar usuario [Can ce la r]

¿crea ció n
corre cta ?
[NO ] [S I]

Mostrar mensaj e de Mostrar mensaj e de

Seleccionar aceptar
creación incorrecta creación correcta

Seleccionar aceptar

Cerrar v entana con

formulario de creación de
usuario

Fi n

81
 Tabla 34. Consultar usuario
CASO DE USO
Código CU033 Nombre Consultar usuario
Actores Administrador
Tipo Primario X Secundario Opcional
Descripción El administrador selecciona un usuario del sistema y selecciona
la opción “visualizar”. El sistema despliega una ventana con la
información del usuario.
Pre-condición Seleccionar un usuario del prototipo.
Post-condición Ventana desplegada con la información del usuario
seleccionado.
ESCENARIO
act CU033 Consultar usuario

Administrador Sistema

In i cio

Selecciona el usuario Habilitar opción de

consultar sobre el usuario
seleccionado

Selecciona opción
consultar
Mostrar v entana con la
información del usuario

Fi n

82
 Tabla 35. Modificar usuario
CASO DE USO
Código CU034 Nombre Modificar usuario
Actores Administrador
Tipo Primario X Secundario Opcional
Descripción El administrador selecciona un usuario del sistema y selecciona
la opción “Editar”. El sistema despliega una ventana con la
información del usuario permitiendo que la misma sea editada.
Pre-condición Seleccionar un usuario del prototipo.
Post-condición Ventana desplegada con la información del usuario
seleccionado.
ESCENARIO
act CU034 Modificar usuario

Administrador Sistema

In ici o

Habilitar opción de editar

Selecciona el usuario sobre el usuario
seleccionado

Seleccionar opción editar

Mostrar v entana con la

información del usuario y
con los campos
habilitados para edición

Editar información del

usuario

da to s d el reg istro

Seleccionar opción

[A ce p tar]

d ato s d el re g istro
« B D In te rm ed ia»
usuarioConAcceso Actualizar registro

Mostrar mensaje de ¿A ctu ali zació n [Ca ncela r]

Seleccionar aceptar
actualización incorrecta [NO ] correcta ?

[S I]

Seleccionar aceptar Mostrar mensaje de

actualización correcta

Cerrar v entana con la

información del usuario

Fin

83
 Tabla 36. Filtrar usuarios
CASO DE USO
Código CU035 Nombre Filtrar usuarios
Actores Administrador
Tipo Primario X Secundario Opcional
Descripción El administrador ingresa un valor en los campos de filtro. El
sistema mostrará los resultados de la búsqueda de acuerdo a
los filtros ingresados.
Pre-condición El administrador selecciona la opción de menú gestión de
usuarios.
Post-condición Listar los usuarios que cumplan con los filtros ingresados por el
administrador.
ESCENARIO
act CU035 Filtrar usuarios

Administrador Sistema

Inicio

Ingresar un v alor en los Filtrar usuarios según

campos de filtro v alorFiltros
valorFi ltros valorFil tros

Actualizar listado en la
v entana
Fi n

84
 9. MODELO ESTRUCTURAL

Se define el modelo estático del aplicativo haciendo uso del diagrama de clases,
permitiendo evidenciar la realización de los casos de uso planteados
anteriormente.

Adicionalmente se incluye el modelo de persistencia donde se evidencia la

estructura que persistirá la información que se especificó en los requerimientos.

9.1 DIAGRAMA DE CLASES

Este diagrama fue elaborado a partir del modelo funcional basado en casos de
uso. Además del diagrama de clases se anexa el diccionario de clases para detalle
del modelo en el CD anexo en la ruta: 4. Diccionarios/4. Diccionario de clases.pdf.

85
Figura 18. Diagrama de clases. Fuente. Este trabajo
9.2 MODELO DE PERSISTENCIA

Este modelo está representado a través del modelo relacional, el cual organiza y
representa los datos en forma de tablas y relaciones.

Adicionalmente se anexa el diccionario de datos para detalle del modelo en el CD

anexo en la ruta: 4. Diccionarios/5. Diccionario de datos.pdf.

87
Figura 19. Diagrama relacional. Fuente. Este trabajo.
9.2.1 Estructuras recursivas

En los modelos relacionales usados por las aplicaciones Plantae y Specify, el

manejo que se le da a la información de los sitios geográficos y la taxonomía de
los especímenes es a través de estructuras tipo árbol las cuales permiten que un
registro de la tabla pueda tener como padre a otro registro de la misma tabla.

Dado los beneficios que otorgan estas estructuras, en el modelo relacional de este
prototipo se hace uso de ellas para el manejo de esa misma información, el
funcionamiento es el siguiente:

class MR01 - Modelo Relacional

(SE C_P ad re =
SE C_Si tio _Geo grafi co )

«FK»

+INT _S itio_G e og rafico_ PK +INT _ Siti o_G eog ra fico_F1

0 ..1 0..*

INT_Sitio_Geografico

«co lum n»
*PK S E C_ Siti o_ Ge og ra fico: INT E GER
* S itio _G e og rafico: VARCHA R(30 )
* Nom bre: VARCHAR(13 0)
* Nivel: INT EG ER
FK S E C_ Pad re : INT EG ER

«PK »
+ INT _ Siti o_G eog ra fico_ PK(INT E GER)
«u niq ue »
+ INT _ Siti o_G eog ra fico_ U1(VARCHAR)
+ INT _ Siti o_G eog ra fico_ U2(VARCHAR)
«FK»
+ INT _ Siti o_G eog ra fico_ F1 (INT EG ER)

Figura 20. Estructuras de árbol. Fuente: Este trabajo.

En la tabla INT_Sitio_Geografico se almacena la información relacionada a los

países, departamentos y municipios, el nivel indica la jerarquía del registro dentro
de la tabla, en donde 1 equivale a país, 2 a departamento y 3 a municipio. Un
municipio en el campo sec_padre tiene un número que corresponde a la llave
primaria de otro registro de la misma tabla, lo cual busca mostrar que dicho
registro es el departamento al cual pertenece el municipio, igualmente un
departamento tendrá en el campo sec_padre la relación con otro registro (país) al
cual el departamento pertenece. Si este campo posee un valor nulo, significa que
ese registro o bien es un país (lo cual se confirma al revisar que sea de nivel 1) o
es un departamento o municipio que no tiene asociado su superior en la base de
datos.

89
Por su parte, la tabla INT_Taxonomia tiene la misma estructura recursiva, en la
tabla se almacena la información relacionada a la familia, el género y la especie.
El nivel indica la jerarquía del registro de la tabla donde 1 equivale a familia, 2 a
género y 3 a especie.

9.2.2 Patrón de fuente de datos

Como patrón de fuente de datos se utilizó Row Data Gateway, ya que para cada
registro de cada tabla de la fuente de datos se creará una ejemplificación del
objeto equivalente que puede ser accedido desde el prototipo ocultando los
detalles de acceso a la fuente de datos [8].

9.2.3 Estrategia de mapeo

Teniendo en cuenta los requerimientos de persistencia en este prototipo se usan

diferentes estrategias de mapeo, entre estas:

9.2.3.1 Mapeador de datos

Es la capa de software encargada de la carga y almacenamiento entre el modelo
de dominio (los objetos en memoria) y el modelo de persistencia (la base de
datos), lo que permite que ambas capas sean independientes.

Para utilizar esta estrategia se creó la clase (mapeador genérico)

GeneralSessionBean que contiene todas las operaciones que se pueden realizar
entre el modelo de persistencia y el modelo de dominio, la estructura de dicha
clase se puede apreciar en la Figura 21.

class DC02 Diagrama de clases con framew ork

GeneralSessionBean

- em factory: Enti tyM ana gerFactory

- em : EntityM anager
- etx: EntityT ransacti on

- co nfi gureQuery(Class<T >, M ap , bool ea n, Stri ng) : <T > Query

+ cre ateEn ti ties(Li st<T >) : T List<T >
+ cre ateEn ti ty(T )(T ) : <T > T
- cre ateQuery(Class<T >, bool ean, Stri ng) : <T > Query
- cre ateQuery(Class<T >, bool ean, Stri ng) : <T > Query
+ fi ndAllEntities(Class<T >) : <T > List<T >
+ fi ndAllEntities(M ap, boole an, String, Cl ass<T >) : <T > List<T >
+ fi ndEntity(bool ea n, Stri ng, Class<T >) : <T > T
+ fi ndEntity(Obj ect, Cl ass <T >) : <T > T
+ fi ndEntity(M ap, b oolean, String , Class<T >) : <T > T
+ Ge neralSessionBean()
+ getRe ferenceEntity(int, Class <T >) : <T >
+ getSysdate() : Date
+ refreshEntity(T )(T ) : <T > T
+ rem oveEntity(Object) : boolean
- setParam etersFro m M ap(Que ry, M ap) : voi d
+ updateEntities(List<T >)(List<T >) : <T > Li st<T >
+ updateEntity(T ) : <T > T

Figura 21. Mapeador genérico. Fuente: Este trabajo.

90
9.2.3.2 Clase a tabla en jerarquías de herencia
Representa una herencia jerárquica de clases con una tabla por cada clase. Se
usa esta estrategia de mapeo en las tablas INT_Especimen y INT_Planta lo cual
permite que la información relacionada al espécimen este separada de la
información relacionada a la planta.

Como se aprecia en la Figura 22 la clase Planta es una especialización de la clase

Especimen, en donde Especimen contiene información que puede ser usada en
cualquier tipo de espécimen (códigos de colección, de barras, determinación,
evento de colección, entre otros) mientras que Planta además de contener la
información de su padre (Especimen) también contiene la información propia de
un espécimen de tipo vegetal (como información del fruto, flor, raíz, entre otros), el
equivalente en el modelo de persistencia se puede apreciar en la Figura 23 donde
la tabla INT_PLANTA contiene una clave externa (clave foránea) hacia la tabla
INT_ESPECIMEN, permitiendo asociar a través de dicha clave la información
general de un espécimen con la información concreta del mismo, dando la
posibilidad de extender el modelo funcional y estructural del prototipo a otras
ramas de las ciencias naturales.

91
 class Modelo de clases

Planta
- secPlanta: int
- altura: String
- dap: String
- abundancia: String
- descripcionPlanta: String
- descMuestrasAsociadas: String
- meTraMueAsociadas: String
- color: Color
- flor: Flor
- fruto: Fruto
- tallo: Tallo
- hoja: Hoja
Especimen - inflorescencia: Inflorescencia
- atributoEspecimen: AtributoEspecimen - raiz: Raiz
- codigoBarras: int
- codigoColeccion: int «property get»
- codigoRecoleccion: String + getAbundancia() : String
- colectorPrincipal: UsuarioConAcceso + getAltura() : String
- descripcion: String + getAtributoEspecimen() : AtributoEspecimen
- determinacion: Determinacion + getCodigoBarras() : int
- estadoEspecimen: EstadoEspecimen + getCodigoColeccion() : int
- eventoColeccion: EventoColeccion + getCodigoRecoleccion() : String
- localidad: Localidad + getColectoresSecundarios() : List<UsuarioSinAcceso>
- secEspecimen: int + getColor() : Color
- taxonomia: Taxonomia + getDap() : String
- archivo: Archivo + getDescMuestrasAsociadas() : String
- colectoresSecundarios: List<UsuarioSinAcceso> + getDescripcion() : String
+ getDescripcionPlanta() : String
«property get» + getDeterminacion() : Determinacion
+ getAtributoEspecimen() : AtributoEspecimen + getEstadoEspecimen() : EstadoEspecimen
+ getCodigoBarras() : int + getEventoColeccion() : EventoColeccion
+ getCodigoColeccion() : int + getFlor() : Flor
+ getCodigoRecoleccion() : String + getFruto() : Fruto
+ getDescripcion() : String + getHoja() : Hoja
+ getDeterminacion() : Determinacion + getInflorescencia() : Inflorescencia
+ getEstadoEspecimen() : EstadoEspecimen + getLocalidad() : Localidad
+ getEventoColeccion() : EventoColeccion + getMeTraMueAsociadas() : String
+ getLocalidad() : Localidad + getRaiz() : Raiz
+ getSecEspecimen() : int + getSecEspecimen() : int
+ getTaxonomia() : Taxonomia + getSecPlanta() : int
+ getcolectorPrincipal() : UsuarioConAcceso + getTallo() : Tallo
+ getArchivo() : Archivo + getTaxonomia() : Taxonomia
+ getColectoresSecundarios() : List<UsuarioSinAcceso> + getUsuarioConAcceso() : UsuarioConAcceso
«property set» «property set»
+ setAtributoEspecimen(AtributoEspecimen) : void + setAbundancia(String) : void
+ setCodigoBarras(int) : void + setAltura(String) : void
+ setCodigoColeccion(int) : void + setAtributoEspecimen(AtributoEspecimen) : void
+ setCodigoRecoleccion(String) : void + setCodigoBarras(int) : void
+ setDescripcion(String) : void + setCodigoColeccion(int) : void
+ setDeterminacion(Determinacion) : void + setCodigoRecoleccion(String) : void
+ setEstadoEspecimen(EstadoEspecimen) : void + setColectoresSecundarios(List<UsuarioSinAcceso>) : void
+ setEventoColeccion(EventoColeccion) : void + setColor(Color) : void
+ setLocalidad(Localidad) : void + setDap(String) : void
+ setcolectorPrincipal(UsuarioConAcceso) : void + setDescMuestrasAsociadas(String) : void
+ setSecEspecimen(int) : void + setDescripcion(String) : void
+ setTaxonomia(Taxonomia) : void + setDescripcionPlanta(String) : void
+ setArchivo(Archivo) : void + setDeterminacion(Determinacion) : void
+ setColectoresSecundarios(List<UsuarioSinAcceso>) : void + setEstadoEspecimen(EstadoEspecimen) : void
+ setEventoColeccion(EventoColeccion) : void
+ setFlor(Flor) : void
+ setFruto(Fruto) : void
+ setHoja(Hoja) : void
+ setInflorescencia(Inflorescencia) : void
+ setLocalidad(Localidad) : void
+ setMeTraMueAsociadas(String) : void
+ setRaiz(Raiz) : void
+ setSecEspecimen(int) : void
+ setSecPlanta(int) : void
+ setTallo(Tallo) : void
+ setTaxonomia(Taxonomia) : void
+ setUsuarioConAcceso(UsuarioConAcceso) : void

Figura 22. Clase a tabla en jerarquía de herencia – Diagrama de clases. Fuente:

Este trabajo.

92
class Modelo de datos

INT_Planta
INT_Especimen
«column»
«column»
*PK SEC_Planta: INTEGER
*PK SEC_Especimen: INTEGER
FK SEC_Color_Planta: INTEGER
*FK SEC_Archivo: INTEGER
FK SEC_Flor: INTEGER
* Cod_Recoleccion: VARCHAR(50)
FK SEC_Fruto: INTEGER
Codigo_Coleccion: VARCHAR(32)
FK SEC_Hoja: INTEGER
Codigo_Barras: VARCHAR(32) = NULL +INT _Especim en _PK +INT _Planta _F8
FK SEC_Tallo: INTEGER
*FK SEC_Usuario_Recolector: INTEGER (SEC_Espe cim en = S EC_ Espe cim en)
1 « FK» 1 FK SEC_Raiz: INTEGER
Descripcion: TEXT
FK SEC_Inflorescencia: INTEGER
*FK SEC_Estado_Especimen: INTEGER
FK SEC_Especimen: INTEGER
FK SEC_Taxonomia: INTEGER
Altura: VARCHAR(130)
FK SEC_Determinacion: INTEGER
DAP: VARCHAR(130)
FK SEC_Localidad: INTEGER
Abundancia: VARCHAR(130)
FK SEC_Atributo_Especimen: INTEGER
Descripcion_Planta: TEXT
FK SEC_Evento_Coleccion: INTEGER
Desc_Muestras_Asociadas: TEXT
Tipo: VARCHAR(45) = Planta
Me_Tra_Mue_Asociadas: TEXT

Figura 23. Clase a tabla en jerarquía de herencia – Modelo relacional. Fuente:

Este trabajo.

9.2.3.3 Clase concreta a tabla en jerarquías de herencia

Representa una herencia jerárquica de clases con una tabla por cada clase
concreta en la jerarquía. A través de esta estrategia, las tablas
INT_Usuario_Con_Acceso y INT_Usuario_Sin_Acceso (Figura 24) son mapeadas
a las clases Usuario, UsuarioConAcceso y UsuarioSinAcceso (Figura 25). Esto
permite que Usuario contenga los campos comunes para las clases concretas, y
UsuarioConAcceso y UsuarioSinAcceso tengan sus campos específicos
respectivamente, esto es útil en el mundo orientado a objetos ya que permite
generar una clase a partir de la abstracción de los campos comunes de las tablas,
lo cual no es posible en el mundo relacional al no poder manejar relaciones de
herencia entre las tablas de la base de datos, esto implica que a pesar de que las
tablas tienen unos campos comunes, dichos campos deben estar en cada tabla
respectivamente.

93
 class DC01 Diagrama de clases

Usuario

- corre oE le ctron ico : S tri ng

- id en tifica cio n: in t
- in sti tucion : String
- n om bre: Strin g
- p rim erAp ell ido : String
- se cUsu a ri o: in t
- se gu nd oA pe lli do : S tri ng

UsuarioConAcceso
- con trasen a: S trin g
- e sta do : String
- role s: Li st<Ro l>
- u su ari o: Strin g
« pro p erty g et»
+ g etCo rre oE lectro nico() : Stri ng
+ g etIdentificaci on () : in t
+ g etInstitu cio n () : String
+ g etNo m b re () : Strin g
+ g etPri m e rA pe llid o() : String
+ g etSe cUsua rio () : in t
+ g etSe gu nd oA pe llid o() : String
+ g etRo les() : Li st<Ro l>
+ g etEstad o () : S tri ng
« pro p erty se t»
+ setCorreo El ectron ico (S trin g) : void
+ setIde nti fica cio n(int) : voi d
+ setInstitu cio n(S tri ng ) : voi d
+ setNom b re(String ) : vo id
+ setP rim e rAp e l lid o(S tri ng ) : voi d
+ setS ecUsuario (int) : voi d
+ setS eg un do Ap el lid o(S tri ng ) : voi d
+ setRol es(List<Rol >) : vo id
+ setE sta do (S trin g) : void
«p ro pe rty ge t»
+ g etCorreo El ectron ico () : S trin g
+ g etIde nti fica cio n() : int
+ g etInstitu cio n() : S tri ng
+ g etNom b re() : String
+ g etP rim e rAp el lid o() : S tri ng
+ g etS ecUsua rio () : int
+ g etS eg un do Ap el lid o() : S tri ng
«p ro pe rty set»
+ se tCorre o El e ctron ico (S trin g) : void
+ se tId en tifica cio n(i nt) : vo i d
+ se tIn sti tucio n(S trin g) : vo i d
+ se tNom bre(S tri ng ) : voi d
+ se tP rim erAp ell ido (S trin g ) : void
+ se tS ecUsu a rio(int) : voi d
+ se tS eg u n do Ap ell ido (Stri n g) : void
UsuarioSinAcceso
- de scripcion : String
- tip oUsu ario : String
« prop erty g et»
+ ge tCo rre oE le ctroni co () : Strin g
+ ge tDe scrip cio n() : S tri ng
+ ge tId en tifi cacio n() : in t
+ ge tIn stitucion () : Strin g
+ ge tNo m bre () : S trin g
+ ge tPrim erA pe l li do () : Strin g
+ ge tSe cUsu ari o () : i nt
+ ge tSe gu nd oAp e lli do () : Stri n g
+ ge tT i po Usua rio() : String
« prop erty set»
+ se tCo rre oE le ctro ni co(String ) : vo id
+ se tDe scripcion (S trin g) : void
+ se tIde ntificacio n (in t) : vo id
+ se tInstituci o n (Strin g) : vo id
+ se tNo m bre (S trin g) : void
+ se tPrim erA pe llid o(String ) : vo id
+ se tSe cUsua rio (in t) : vo id
+ se tSe gu nd oA pe llid o(String ) : vo id
+ se tT i po Usu ario(String ) : vo id

Figura 24. Clase concreta a tabla en jerarquías de herencia – Diagrama de clases.

Fuente: Este trabajo.

94
 class Modelo de datos

INT_Usuario_Sin_Acceso
«column»
*PK SEC_Usuario: INTEGER
Tipo_Usuario: CHAR(1)
Identificacion: VARCHAR(20)
Nombre: VARCHAR(150)
Primer_Apellido: VARCHAR(150)
Segundo_Apellido: VARCHAR(150)
Correo_Electronico: VARCHAR(250)
Institucion: VARCHAR(250)
Descripcion: TEXT
«PK»
+ INT_Usuario_Sin_Acceso(INTEGER)
INT_Usuario_Con_Acceso
«column»
*PK SEC_Usuario: INTEGER
* Usuario: VARCHAR(30)
* Contrasena: VARCHAR(130)
* Estado: CHAR(1)
Identificacion: VARCHAR(20)
Nombre: VARCHAR(150)
Primer_Apellido: VARCHAR(150)
Segundo_Apellido: VARCHAR(150)
Correo_Electronico: VARCHAR(250)
Institucion: VARCHAR(250)
«PK»
+ INT_Usuario_Con_Acceso_PK(INTEGER)
«unique»
+ INT_Usuario_Con_Acceso_U1(VARCHAR)

Figura 25. Clase concreta a tabla en jerarquías de herencia – Modelo relacional.

Fuente: Este trabajo.

9.2.3.4. Mapa de identidad

La librería EclipseLink usada en este proyecto maneja por defecto una memoria
caché que es un repositorio en memoria que almacena objetos recientemente
leídos o escritos basados en clases y llaves primarias. Esta memoria caché
maneja el patrón de mapa de identidad el cual mantiene un registro de todos los
objetos que han sido leídos de la base de datos en una sola transacción de
negocio, esto significa que se asegura que cada objeto sea cargado una sola vez
al mantener cada objeto cargado en un mapa, lo cual mejora el desempeño
minimizando los accesos a la base de datos.

9.2.4 Aspectos tecnológicos de mapeo

Para el lenguaje de programación JAVA existe una solución que maneja datos
relacionales en aplicaciones bajo este lenguaje, dicha solución es conocida como
Java Persistence API (de ahora en adelante JPA), la cual permite administrar en
conjunto la base de datos y los objetos en tiempo de ejecución.

Para el mapeo de la información entre la base de datos y el prototipo se usa JPA.

Ya que utiliza un enfoque de mapeo objeto-relacional para cerrar la brecha entre
un modelo orientado a objetos y una base de datos relacional [36].

Adicionalmente, la herramienta que se utilizó es eclipseLink debido a que provee

una implementación de EJB3 y JPA y es de código abierto [37].

95
9.3 PLANTAE Y LA EXPORTACIÓN DE LOS DATOS

Después de capturar la información de especímenes, Plantae permite exportar en

un archivo de valores separados por comas (CSV) la información de todos los
especímenes asociados a un viaje como se ve en la Figura 26. Este archivo es
almacenado dentro de la memoria del dispositivo móvil donde se tiene instalado
Plantae.

Figura 26. Exportación de datos desde Plantae. Fuente: Captura de pantalla de la

exportación de datos en la aplicación Plantae.

El archivo CSV resultante es el insumo que usa este prototipo para cargar en la
base de datos la información de los especímenes, en donde cada columna del
archivo se almacena en un campo específico de la base de datos y no es
concatenada con otros datos, esto significa que la segmentación de la información
que se logra en Plantae es preservada en el prototipo.

96
9.4 ESTRATEGIA DE MIGRACIÓN DE DATOS A SPECIFY

Uno de los objetivos de este proyecto, es migrar la información que fue

recolectada a través de Plantae y manipulada dentro del prototipo, a la base de
datos del ICN. Para lograr esto, se diseñó e implementó una estrategia para su
migración teniendo en cuenta lo siguiente:

1. La base de datos de este prototipo es más completa en la lista de atributos

por entidad estructural que la base de datos de Specify, es decir, la
información se encuentra más segmentada, hay campos (atributos) en la
base de datos del prototipo que no tienen un campo relacionado en Specify.

2. Algunas tablas de Specify cuentan con campos que pueden ser definidos
por el usuario, estos campos se identifican de la siguiente manera: text1,
text2, number1, number2, YesNo1, YesNo2, por lo que carecen de
significado semántico y además tienen su propio tipo de dato.

Se analizó la posibilidad de hacer uso de estos campos pero el personal del

ICN no tiene conocimiento de las posibles repercusiones que traería en el
funcionamiento normal de Specify la manipulación de estos campos, ya sea
cambiando su nombre o tipo de dato, también se consideró la posibilidad de
concatenar la información de la base de datos del prototipo y que fuese
almacenada dentro de estos campos, pero se descartó dado que era
demasiada información para un solo campo y el tipo de dato del mismo
podría no permitirlo; además, en caso de realizarse, se perdería el trabajo
realizado en Plantae con la segmentación de esta información.

3. Existen unos campos que cuentan con correspondencia en Specify pero

que son considerados como datos sensibles para el proceso de migración,
el tratamiento de estos es explicado en la sección 9.4.1

Con base en los tres apartados anteriormente descritos, se define la siguiente

estrategia de migración:

Solo se migrarán los campos de los cuales existe una correspondencia entre la
base de datos del prototipo y Specify, de esta manera se evita realizar
modificaciones estructurales sobre la base de datos de Specify que podrían tener
repercusiones en el uso cotidiano de esta herramienta.

En total son 20 campos del prototipo que son migrados a Specifiy. Cabe aclarar
que tanto la información que sea migrada como la que no sea migrada
permanecerá en la base de datos del prototipo.

El listado completo de los campos de la base de datos del prototipo con la relación

97
de las tablas de Specify se podrá ver como anexo dentro del CD en la ruta 1.
Documentos/2 Relacion campos prototipo y Specify.pdf.

Tabla 37. Campos que son migrados

Base de datos del prototipo Base de datos Specify
TABLA CAMPO CAMPO TABLA
codigo_recoleccion StationFieldNumber collectingevent
INT_Especimen codigo_coleccion CatalogNumber collectionObject
codigo_barras AltCatalogNumber collectionObject
fecha_ini_recoleccion startDate collectingevent
fecha_fin_recoleccion EndDate collectingevent
INT_Evento_Coleccion
metodo Method collectingevent
estacion_ano Remarks collectingevent
nombre localityName locality
elevacion_minima MinElevation locality
elevacion_maxima MaxElevation locality
INT_Localidad
latitud Latitude1 locality
longitud Longitude1 locality
descripcion remarks locality
usos text1 collectionobjectattribute
vegetacion text5 collectionobjectattribute
suelo_sustrato text5 collectionobjectattribute
INT_Atributo_Especimen
especies_asociadas text5 collectionobjectattribute
habito text3 collectionobjectattribute
fenologia text4 collectionobjectattribute
INT_Planta descripcion Remarks collectionobjectattribute

Estos campos son datos sensibles en la migración que se podrán ver en detalle en
la sección 9.4.1

98
 Tabla 38. Datos sensibles en la migración
Base de datos del prototipo Base de datos Specify
TABLA CAMPO CAMPO TABLA
INT_Sitio_Geografico nombre (pais) name geography
INT_Sitio_Geografico nombre name geography
(departamento)
INT_Sitio_Geografico nombre (municipio) name geography
INT_Taxonomia nombre (familia) name taxon
INT_Taxonomia nombre (género) name taxon
INT_Taxonomia nombre (especie) name taxon
INT_Usuario_Con_Acceso nombre firstname agent
INT_Usuario_Con_Acceso primer_apellido lastname agent

El usuario encargado de aprobar la migración (usuario con rol validador) podrá ver
la información que será migrada en la opción de menú Solicitudes de inclusión en
el botón Datos a Specify que aparece en cada solicitud de inclusión, como se
muestra en la Figura 27.

Figura 27. Opción Datos a Specify. Fuente: Este trabajo.

Adicionalmente, con el fin de identificar en Specify los registros que fueron

migrados desde este prototipo, se hace uso del campo text15 de la tabla
collectionobjectattribute en donde se almacena un mensaje informando que el
espécimen fue insertado por el prototipo.

9.4.1 Datos sensibles detectados en el proceso de migración

En Specify existen tres estructuras (tablas) las cuales solo serán consultadas,

99
estas tablas son taxon, geography y agent que son las encargadas de almacenar
la información taxonómica de un espécimen, el sitio geográfico en donde fue
recolectado y el recolector respectivamente. Las razones para que estas
estructuras solo sean consultadas son:

1. El ICN ha estado llevando a cabo un proceso de depuración de las

estructuras debido a que estas tienen información errónea o repetida.
2. La información en taxon y geography solo es creada por expertos de esas
ramas, para asegurar la fiabilidad de la misma.

A pesar de que los especímenes que se desean migrar deben tener una
taxonomía, sitio geográfico y recolector asociados, esta información puede no ser
correcta debido a que dicha información es ingresada por el usuario recolector,
dando cabida a errores de sintaxis o de conocimiento en esas áreas, lo cual puede
llevar a una inconsistencia de los datos asociados.

Por lo tanto el procedimiento que se aplicará para cada una de estas estructuras
es el siguiente:

9.4.1.1 Árbol de la Taxonomía

En la Figura 28, se puede apreciar una sección del árbol de taxonomía de Specify,
en la Figura 29 se pueden ver a nivel de base de datos los tres campos principales
de la sección que se muestra en la Figura 28, en donde se puede apreciar que un
registro está asociado a otro registro de la misma tabla a través de la columna
parentid.

Figura 28. Sección árbol taxonomía de Specify. Fuente: Captura de pantalla de

una sección del árbol de taxonomía desde Specify.

100
Figura 29. Sección árbol taxonomía a nivel de base de datos. Fuente: Captura de
pantalla de una sección de la consulta al árbol de taxonomía de Specify.

Teniendo en cuenta que ésta es una estructura jerárquica igual a las mencionadas
en la sección 9.2.1, se busca la asociación de la siguiente manera:

1. Se realizará una búsqueda que permita obtener un registro (especie) cuyo

padre (género) tenga a su vez otro padre (familia) y que los tres
correspondan con lo registrado en el prototipo.
2. Si se encuentra un registro que cumpla con las características mencionadas
en el ítem anterior, a este será asociado el registro que se está migrando.
3. Si no se encuentra un registro que cumpla con las características
mencionadas en el ítem 1, se mostrará un mensaje al usuario encargado de
la migración informándole que no existe un registro que cumpla con lo
ingresado, por lo que la migración quedará en un estado pendiente
mientras un trámite administrativo dentro del ICN permite tomar alguna
acción con respecto a dicha información. Esto es, en el ICN se verifica la
nueva taxonomía y de acuerdo a lo que informen los expertos del ICN:
1. Se crea esa nueva rama taxonómica en Specify y se informa al
validador para que intente realizar nuevamente la migración del registro.
2. No se crea la nueva rama, lo cual se puede deber a errores de sintaxis o
en la taxonomía que el usuario validador no vio y por lo tanto debe
cancelar la aprobación del registro, es decir, se debe rechazar la
solicitud y especificar esto en el motivo de rechazo.

9.4.1.2 Árbol de Geografía

En Specify, la geografía posee la misma estructura de la taxonomía, como se
puede observar en la Figura 30 y la Figura 31.

101
Figura 30. Sección árbol geografía de Specify. Fuente: Captura de pantalla de una
sección del árbol de geografía desde Specify.

Figura 31. Sección árbol geografía a nivel de base de datos. Fuente: Captura de
pantalla de una sección de la consulta al árbol de geografía de Specify.

La asociación para este caso se realiza de la siguiente manera:

1. Se realizará una búsqueda que permita obtener un registro (municipio) cuyo

padre (departamento) tenga a su vez otro padre (país) y que los tres
correspondan con lo registrado en el prototipo.
2. Si se encuentra un registro que cumpla con las características mencionadas
en el ítem anterior, a este será asociado el registro que se está migrando.
3. Si no se encuentra un registro que cumpla con las características
mencionadas en el ítem 1, se mostrará un mensaje al usuario encargado de
la migración informándole que no existe un registro que cumpla con lo
ingresado, por lo que la migración quedará en un estado pendiente
mientras un trámite administrativo dentro del ICN permite tomar alguna
acción con respecto a dicha información. Esto es, en el ICN se verifica la

102
 nueva geografía y de acuerdo a lo que informen los expertos del ICN:
1. Se crea esa nueva rama geográfica en Specify y se informa al validador
para que intente realizar nuevamente la migración del registro.
2. No se crea la nueva rama, lo cual se puede deber a errores de sintaxis o
en la geografía que el usuario validador no vio y por lo tanto debe
cancelar la aprobación del registro, es decir, se debe rechazar la
solicitud y especificar esto en el motivo de rechazo.

9.4.1.3 Agente
Dado que para la digitalización de los especímenes se toma la información
consignada en la etiqueta que acompaña al espécimen físico, y cada recolector
elabora su etiqueta, la manera de escribir sus nombres y apellidos tienen
variaciones tales como ponerlos de forma completa, solo iniciales, una mezcla
entre iniciales y apellidos completos, los nombres acompañados de puntos, entre
otras.

Anteriormente, la información debía ser digitalizada como se encontraba en la

etiqueta, por lo que se estaba creando un Agent (recolector) por cada variación en
la manera de llamarse dentro de Specify. Es decir, pueden haber N recolectores
que son una misma persona y estos a su vez tener asociados especímenes.

Aunque se dejó de hacer esta práctica al momento de digitalización, mientras el

ICN plantea un proceso de depuración de estos datos, por ahora su estrategia es
buscar el Agent que cuenta con sus nombres y apellidos completos, ignorando
símbolos y asociarle a éste el espécimen que está siendo digitalizado.

Teniendo en cuenta lo anterior, la asociación del recolector al espécimen que se

migra desde este prototipo se realiza de la siguiente manera:

1. Se busca en Specify un Agent (recolector) que corresponda con el nombre

y apellido del usuario asociado al espécimen en el prototipo.
2. Si se encuentra más de un resultado, se relaciona con el Agent (recolector)
que tenga la mayor cantidad de especímenes asociados. De esta manera,
el ICN al momento de depurar los recolectores y asociar todos los
especímenes a un mismo recolector, este último no solo será el definitivo,
sino que será el que más registros posea, por consiguiente en el momento
de la migración la información será asociada a este.
3. Si no se encuentra ningún resultado similar, se mostrará un mensaje al
usuario encargado de la migración informándole que no existe ningún
Agent en Specify relacionado al usuario del prototipo, por lo que la
migración quedará en un estado Pendiente mientras un trámite
administrativo dentro del ICN permite tomar alguna acción con respecto a
dicha información. Esto es, en el ICN se verifica la información y de acuerdo
a lo que informen los expertos del ICN:

103
 1. Se crea el Agent en Specify y se informa al validador para que intente
realizar nuevamente la migración del registro.
2. Se detecta que el Agent ya existe en Specify, así que se modifican los
nombres y apellidos del Agent o del usuario del prototipo, dependiendo
de cuál de los dos tiene información más completa y se informa al
validador para que intente realizar nuevamente la migración del registro.

9.4.1.4 Otros datos

Al ingresar un espécimen a Specify, se le asignan dos códigos de identificación:
código de barras y código de colección, los cuales son únicos en Specify para una
colección, por lo que antes de migrar un registro se verifica si alguno de los
códigos ya está asignado a algún otro espécimen de la colección, de ser así se le
informará al validador que alguno de los códigos ya está registrado en Specify, en
caso contrario se procederá con la migración.

104
 10. MODELO DE INTERFAZ GRÁFICA DE USUARIO

Se presenta el resultado final de la interfaz gráfica los cuales están basados en el

modelo de interfaz gráfica que se diseñó a través de la herramienta Enterprise
Architect y que puede ser visto en el CD en la ruta 2. Modelamiento/3.
ModeladoPlantaeToSpecify2016.eap

10.1 MAPA DE NAVEGACIÓN

En la Figura 32, se representa la navegación que puede tener un usuario dentro

del prototipo de acuerdo al rol que tenga asignado.

105
Figura 32. Mapa de navegación del prototipo. Fuente: Este trabajo.
10.2 GENERALIDADES DE LA INTERFAZ GRÁFICA

El prototipo está compuesto por cinco (5) opciones de menú, de las cuales tres:
Importar datos especímenes, Gestión de especímenes y Envío de solicitudes de
inclusión podrán ser vistas por un usuario con rol de Recolector, un usuario con rol
de Validador podrá ver la opción de menú Solicitud de inclusión, por su parte un
usuario con rol de Administrador podrá acceder a la opción de menú
Administración de usuarios.

Adicionalmente dentro del prototipo existen elementos comunes de navegación

para todos los usuarios.

10.2.1 Página de control de acceso

Al lado derecho de esta página se encuentra la sección de control de acceso que

todo usuario debe diligenciar para acceder a las funcionalidades del prototipo.

Figura 33. Página de control de acceso. Fuente: Este trabajo.

10.2.2 Página principal

Esta página está distribuida de la siguiente manera: en la parte superior se

encuentra el título y logo del prototipo, debajo de estos se encuentra un toolbar

107
que es visible en todo momento y cuenta con las opciones de menú del usuario
(sección 10.2.3), en la parte izquierda de la pantalla los usuarios encontrarán las
opciones de menú que tendrán disponibles de acuerdo a su rol, a la derecha de
las opciones de menú se encuentra el área principal en la cual se desplegarán las
páginas correspondientes a cada opción de menú. Finalmente, en la parte inferior
se muestran los créditos del prototipo.

Figura 34. Página principal con todas las opciones de menú. Fuente: Este trabajo.

108
10.2.3 Menú de opciones de usuario

En la parte superior derecha de la pantalla, el usuario encontrará un menú con su

nombre de usuario, al hacer clic sobre éste menú podrá ver las opciones de
Cambiar contraseña y de Cerrar sesión como se muestra en la Figura 35.

Figura 35. Opciones del usuario. Fuente: Este trabajo.

10.2.4 Cambiar contraseña

Al hacer clic sobre esta opción el prototipo desplegará una ventana en la que el
usuario podrá cambiar su contraseña de acceso a este (Figura 36).

Figura 36. Opción de cambio de contraseña. Fuente: Este trabajo.

109
10.2.5 Cerrar sesión

Al hacer clic sobre esta opción, el sistema borrará los datos de sesión del usuario
y devolverá al usuario a la página de control de acceso (Figura 33) para iniciar
sesión nuevamente.

10.2.6 Mensajes

El prototipo genera mensajes de acuerdo a algunas acciones realizadas por los

usuarios.

• De confirmación: Para la eliminación de especímenes o el envío de

solicitudes de inclusión aparecerá una ventana emergente solicitando la
confirmación de la acción (Figura 37).

Figura 37. Mensajes de confirmación. Fuente: Este trabajo.

• De resultado: Al completar una acción, el sistema mostrará una ventana con

el resultado de la acción ya sea exitosa o no exitosa (Figura 38).

Figura 38. Mensajes de resultado. Fuente: Este trabajo.

110
10.3 OPCIONES DE MENÚ

De acuerdo al rol o roles con los que cuenta un usuario el prototipo le mostrará las
opciones de menú a las cuales podrá acceder.

10.3.1 Rol recolector

Cuenta con tres opciones de menú: Importar datos de especímenes, Gestión de
especímenes y Envío de solicitudes de inclusión.

Figura 39. Opción de menú Importar datos de especímenes. Fuente. Este trabajo.

Figura 40. Opción de menú Gestión de especímenes. Fuente. Este trabajo.

111
Figura 41. Opción de menú Envío de solicitudes de inclusión. Fuente. Este trabajo.

10.3.2 Rol validador

Puede acceder a una opción de menú llamada Solicitudes de inclusión.

Figura 42. Opción de menú Solicitudes de inclusión. Fuente. Este trabajo.

112
10.3.3 Rol administrador
Puede acceder a una opción de menú llamada Administración de usuarios.

Figura 43. Opción de menú Administración de usuarios. Fuente. Este trabajo.

Cabe señalar que cada opción de menú se encuentra debidamente explicada en el

manual de usuario que se encuentra adjunto en el CD en la ruta
5.Manuales/5.Manual de usuario PlantaeToSpecify.pdf.

113
10.4 ASPECTOS DE IMPLEMENTACIÓN

La interfaz gráfica de usuario (GUI) se desarrolló haciendo uso de los elementos

de interfaz propios del framework ZK además de hacer uso de la arquitectura
MVVM (ver sección 5.2.3) y los widgets más utilizados dentro del prototipo fueron:

Button Toolbar Groupbox

Textbox Toolbarbutton Tabbox
Label ListBox Tabs
MenuItem Borderlayaot Tabpanels

Con el fin de que este prototipo quedara bien documentado y de esta manera
poder seguir ampliando sus funcionalidades, se realizó un segundo diagrama de
clases, en donde se muestran las clases del modelo estructural y las clases que
ayudan a soportar la lógica del framework con los elementos de interfaz gráfica.

Por facilidad de lectura este diagrama de clases podrá ser visto en el CD en la ruta
2. Modelamiento/3. ModeladoPlantaeToSpecify2016.eap.

114
 11. MODELO DINÁMICO

Este modelo muestra las interacciones entre los objetos del prototipo en tiempo de
ejecución. Las interacciones que se documentaron incluyen la secuencia de
peticiones de servicio realizadas por los objetos (diagramas de secuencia) así
como los cambios de estado que activan las interacciones de dichos objetos
(máquinas de estado) [38].

11.1 DIAGRAMAS DE SECUENCIA

Cada caso de uso además de contar con su representación en un diagrama de

actividades el cual muestra cual sería la interacción entre el usuario, el sistema y
la base de datos, cuenta con la representación en diagramas de secuencia que
muestran como es el comportamiento real en un lenguaje de programación
orientado a objetos.

A continuación se muestran algunos de estos diagramas, los diagramas en su

totalidad podrán ser vistos en el CD en la ruta:
2. Modelamiento/3. ModeladoPlantaeToSpecify2016.eap

115
sd DS007 Gestionar archivos de especímenes

m e n u Im po rta rDa to sE spe ci m e ne s Im po rtarE sp ecim e n V ie wM od el «L og g er» «S e l ecto rs»

B oce tos d e l og
in terfaz g rá fi ca
Re co l ecto r
: Carga r a rch i vo

«o n Cli c»
in i t()

i ni t(usu ario )

in fo ("in i t")

u su a ri o
:Usu a ri o Co n Acceso

usuario =
se tUsu ari o(Usua ri o Co nA cce so )

a fte rCom p ose(Com p o n e nt vi ew)

in fo ("a fte rCo m po se ")

wi re Com p on en ts(vie w,
th is, fa lse )
te xtb oxRuta A rch i vo

b u tton S ub i rA rch ...

bu tto nG u a rd arA rchi vo

butto n Ca nce la rA rch i vo

« Li stb ox»
li sta A rch i vo s
« L in ked L ist<Arch ivo>»
l i sta A rch ivo sCa rg a do s

A rg u m e n to d e a l to o rde n d e o p eraci ón actu al i za rL i sta A rch ivo sCa rg a d os

ge tUsu a ri o()
ref

«Usu a ri oCo n Acce so » Listar historico de archiv os cargados

usua rio setL ista Archi vo sCa rga do s(l ist<a rchi vo >)

« Li st<A rchi vo >»

a rch ivo

(fro m A cto re s)

Figura 44. DS007 Gestionar archivos de especímenes. Fuente. Este trabajo.

sd DS008 Listar histórico de archiv os cargados

Im p orta rEspe cim e nV i ewM o de l L og ge r

Re gi ón in te rru m p ibl e

«Usu ari oCo n Acceso » usua ri o

in fo (" actua lizarL ista Arch ivo sCarg a do s")

try

Fil eM a na g er

A rgu m en to s de a lto d e orde n de la o pe ra ció n fin d AllEn tities

ca rg a rArch ivo sCarg a do s(usu ario) :

L ist<Arch ivo >

in fo ("carga rA rchivosCarga do s")

gb
:G en e ral Sessio nBe an
« Ha sh M ap »
p aram s

p ut("usua ri o" , usua ri o)

Reg ió n interru m p ib le

try
« L ist<A rchi vo >»
a rch ivo s

A rg um e ntos d e al to orde n de la o pe ra cio n fin d AllEn tities

find A ll Entitie s(Arch ivo.cl ass, "Archivo.fin dAl lByUser", tru e , p aram s) :<T > L ist<T >

a rch ivo s= fin dAl lEntiti es(Archivo.cla ss, "A rchi vo.fin dAl lB yUser", true , p aram s)

« List<Archivo >» archivos

alt catch Gen e ral E xce ption ("Error al co nsu lta r
l os a rch ivo s ca rg ad os" , e ,
[Exce ptio n e] Fil eM a na ge r.cla ss,
« Ge ne ra lExce p tio n»
"ca rg arArch ivo sCa rg a do s", usu ari o)

« Ge n era lExcep tio n»

alt catch
[Excep ti on e ] error(" Erro r", e )

Figura 45. DS008 Listar histórico de archivos cargados. Fuente. Este trabajo.
Figura 46. DS024 Consultar solicitudes de inclusión. Fuente. Este trabajo.
11.2 MÁQUINAS DE ESTADO

Durante el desarrollo del prototipo se identificaron objetos que en respuesta a

mensajes y eventos cambian de estado.

11.2.1 Máquina de estados del espécimen

La máquina de estados de la figura 47 representa los posibles estados por los

cuales pasa un espécimen, en ella se pueden observar las acciones que se dan
en cada estado, asi mismo, se pueden observar las precondiciones para que una
acción se de, y las postcondiciones después de la ejecución de la acción.

Figura 47. Máquina de estados del espécimen. Fuente. Este trabajo.

11.2.2 Máquina de estados de la solicitud de inclusión

La máquina de estados de la figura 48 representa los posibles estados por los

cuales pasa una solicitud de inclusión, en ella al igual que en la máquina de
estados del espécimen (Sección 11.2.1) se pueden observar las acciones que se
dan en cada estado, asi mismo, se pueden observar las precondiciones para que
una acción se de, y las postcondiciones después de la ejecución de la acción.

119
Figura 48. Máquina de estados de la solicitud de inclusión. Fuente. Este trabajo.

120
 12. TECNOLOGÍAS USADAS EN LA CONSTRUCCIÓN

Finalmente las tecnologías usadas en la construcción del prototipo fueron:

• Framework ZK: Interfaz gráfica.

• Java: Lógica del negocio.
• JPA: Mapeo de lógica de negocio y base de datos relacional.
• EclipseLink: proveedor de JPA.
• MySQL: Base de datos relacional.
• Librería Apache POI: Generación de etiquetas en formato docx.
• Librería Itext: Generación de etiquetas en formato PDF.

En la Figura 44. Se puede apreciar un esquema con las tecnologías usadas en la

construcción de este prototipo. El entorno de desarrollo utilizado fue Eclipse, para
el modelamiento de este la herramienta utilizada fue Enterprise Architect.

Figura 49. Arquitectura tecnológica del prototipo PlantaeToSpecify. Fuente. Este

trabajo.

Por otro lado, a partir de la estrategia de migración especificada en la sección 9.4,

se desarrolló un procedimiento almacenado que permite la migración de los datos
del prototipo a la base de datos de Specify, este se ejecutará cada vez que el
usuario validador apruebe una solicitud de inclusión. Este procedimiento a su vez
realiza el llamado a cuatro (4) procedimientos adicionales que también deben ser
instalados, tres de estos procedimientos son usados para consultar las tablas:
Taxon, Geography y Agent de Specify y el último es usado para verificar que los
códigos de barras y de colección sean únicos en Specify.

Estos cinco (5) procedimientos se encuentran dentro del CD en la ruta 3.

121
Prototipo/Base de datos/2. DDL Procedures.sql y deberán ser instalados en la
base de datos del prototipo.

En la Figura 50 se puede observar el diagrama de despliegue que incluye los tres

nodos asociados en el prototipo, esto es la interacción entre Plantae,
PlantaeToSpecify y Specify.

deployment PlantaeToSpecify

Serv idor ICN

Specify

«DISP OSIT IVO M ÓVIL» « Se rvid or de ap lica ciones T om cat Versió n 7 .0»

Plantae.apk PlantaeToSpecify.war
« datastore »
« use» «use »
Base de datos

«u se»

« datastore »
plantaetospecify

Figura 50. Diagrama de despliegue. Fuente: Este trabajo.

122
 13. PRUEBAS

Se recopilan las pruebas unitarias y funcionales realizadas al prototipo, las

pruebas unitarias fueron realizadas a través de Junit. Durante estas pruebas se
usaron datos reales de la base de datos a través de la conexión desde el
prototipo, lo que permitió realizar junto con las pruebas unitarias, pruebas de
integración entre los diferentes componentes del mismo. Para las pruebas
funcionales, se verifió que el comportamiento del prototipo estuviera acorde con
los requerimientos funcionales, casos de uso y diagramas de actividades.

13.1 Pruebas unitarias y de integración

Las pruebas unitarias se realizaron sobre las clases que concentran la lógica de
negocio más relevante del prototipo, estas clases son las relacionadas con la
carga de archivos CSV al prototipo, la edición de especímenes y la migración de
especímenes a Specify. Para la realización de las mismas se crearon tres (3)
clases de prueba (una para cada clase que iba a ser probada) y una clase suite
que hizo los llamados a las clases de prueba. Dichas clases se pueden ver en el
diagrama de la Figura 51.

Figura 51. Diagrama de clases de la implementación de JUnit. Fuente. Este

trabajo.

Los resultados obtenidos en las pruebas fueron los esperados, como se puede
observar en la Figura 52.

123
 Figura 52. Resultados de las pruebas unitarias. Fuente. Este trabajo.

13.2 Pruebas funcionales

Las pruebas funcionales fueron realizadas sobre todas las funcionalidades del
prototipo, sin embargo a continuación solo se presentan los resultados de estas
pruebas en las funcionalidades de cargue de archivos, solicitudes de inclusión y
aprobación de migración.

13.2.1 Cargue de un archivo

El prototipo carga todos los registros con los que cuenta un archivo y muestra un
mensaje de cargue exitoso como se puede ver en la Figura 54, sin embargo, si en
el archivo uno de los registros tiene algún campo incorrecto o cuando el archivo
está vacío, el prototipo genera un mensaje como se puede ver en la Figura 55 y
Figura 56 respectivamente, cabe aclarar que en estas pruebas se usaron archivos
generados por Plantae, sin embargo, en las dos primeras pruebas los archivos
fueron alterados para verificar el comportamiento del prototipo con archivos sin
información o con información incorrecta, el último archivo si fue cargado al
prototipo tal y como fue generado por Plantae.

124
 Figura 53. Cargue de un archivo. Fuente. Este trabajo.

Figura 54. Cargue de archivo exitoso. Fuente. Este trabajo.

125
 Figura 55. Cargue de archivo incorrecto campo invalido. Fuente. Este trabajo.

Figura 56. Cargue de archivo vacío. Fuente. Este trabajo.

13.2.2 Solicitud de inclusión

Al enviar una solicitud de inclusión el prototipo genera un mensaje de confirmación
de la acción (Figura 57) sí el usuario confirma la acción, el prototipo envía la
solicitud de inclusión al usuario validador y muestra un mensaje con el resultado
del envío de la solicitud (Figura 58).

126
 Figura 57. Solicitud de inclusión de especímenes. Fuente. Este trabajo.

Figura 58. Solicitud de inclusión de especímenes enviada. Fuente. Este trabajo.

13.2.3 Aprobación e inclusión de espécimen

En la Figura 59, se evidencia que una vez el usuario validador hace clic en
aprobar solicitud, debe agregar la información faltante del espécimen para que
este sea incluido en Specify, una vez esta información es agregada y se hace clic
en aprobar solicitud, el prototipo realiza la validación correspondiente y muestra
mediante un mensaje el resultado del proceso de aprobación (Figura 60).

127
 Figura 59. Agregar información. Fuente. Este trabajo.

Figura 60. Confirmación de inclusión de especímen en Specify. Fuente. Este

trabajo.

Posteriormente, el espécimen migrado fue consultado en Specify, y se evidenció

que efectivamente el espécimen fue migrado (Figura 61).

128
Figura 61. Espécimen desde Specify. Fuente. Este trabajo.

129
 14. CONCLUSIONES

• Al definir clara y detalladamente cada uno de los requerimientos expuestos

por los usuarios, al ser estos diagramados en un modelo de casos de uso y
los diagramas de actividades, se evidenció con mayor claridad la
interacción entre los actores del sistema, el sistema y la base de datos.
• Se estableció una estrategia de migración de los datos recolectados a
través de Plantae y la base de datos del ICN, permitiendo completar el
proceso que se está tratando de automatizar.
• Se obtuvo una aplicación que podría facilitar la depuración de los datos
recolectados a través de Plantae para una migración confiable a la base de
datos del ICN.
• Se pudo evidenciar que el framework ZK en su propuesta arquitectónica es
funcional para los propósitos de contar con una interfaz gráfica amigable y
es integrable a tecnologías como JPA.
• Gracias a la alianza entre el ICN y el grupo de investigación Arquisoft, y al
apoyo e interés de los potenciales usuarios finales, se obtuvo información
relevante y valiosa para el desarrollo del prototipo.
• Se elaboró un módulo de generación de etiquetas, el cual fue bien aceptado
por los usuario finales al poseer una interfaz sencilla e intuitiva que no solo
permite establecer un estándar de etiquetado, sino que reemplaza a la
herramienta con la que cuentan actualmente, la cual no es usada debido
principalmente a su complejidad de uso y restricciones de acceso.
• Al obtener los modelos después de cada fase del Proceso Unificado, estos
permitieron verificar que lo desarrollado está acorde a lo modelado y que
puede ser menos dispendiosa la extensibilidad de este prototipo de
software al hacer uso de estos.
• Finalmente, el grupo de investigación Arquisoft al querer impulsar la
corriente de “Open models”, pone a disposición de la comunidad los
modelos de este prototipo, los cuales pueden ser consultados en la página
web del grupo.

130
 15. TRABAJO FUTURO

A medida que se diseñó y desarrolló este prototipo se detectaron mejoras e

incluso nuevas funcionalidades que podrían ser integradas en nuevas versiones
del prototipo, tales como:

• Permitir en el módulo de generación de etiquetas que el usuario pueda

configurar las dimensiones de estas, los campos que quiere sean incluidos,
su distribución, además de acomodar las etiquetas de tal manera que se
optimice el uso del papel e incluso permita la creación de plantillas de
etiqueta.
• El manejo de colores en RGB y el MUNSELL para esta versión del prototipo
solo se aprecia a nivel de codificación y no a nivel visual, entonces se
podría mejorar esta funcionalidad permitiendo al usuario ver estos colores
en estas dos escalas.
• Crear un nuevo módulo y su respectivo rol en el sistema que reciba las
notificaciones del prototipo y a su vez tenga los permisos de realizar ajustes
en Specify para corregir los problemas presentados en el proceso de
migración que hace que la solicitud de inclusión quede en estado
pendiente.
• Permitir la parametrización de los niveles de los árboles de sitio geográfico
y taxonomía, adicionalmente que los sitios geográficos estén referenciados
con otra base de datos como la del Instituto Geográfico Agustín Codazzi,
con el fin de disminuir los inconvenientes con los que cuenta el instituto al
momento del registro de un sitio geográfico.
• Notificar mediante correos electrónicos a los diferentes usuarios
involucrados los cambios de estado que sufre un espécimen o solicitud de
inclusión durante el proceso de solicitud e inclusión en Specify.
• Una funcionalidad que permita la autenticación única para las tres
aplicaciones: Plantae, PlantaeToSpecify y Specify, actualmente cada
aplicación maneja y controla sus usuarios de manera independiente.

131
 16. GLOSARIO

ADMINISTRADOR: Usuario del prototipo que realizará la creación de los usuarios

recolectores y validadores.

ARCHIVO CSV: Archivo generado por la aplicación móvil Plantae con formato
CSV.

CSV: Traducido como “Valores separados por coma” por sus siglas en inglés
(Comma-Separated Value) es un formato de archivo para intercambiar datos entre
diferentes aplicaciones.

ESPÉCIMEN: Muestra recolectada en campo de una especie de flora.

PLANTAE: Aplicativo móvil desarrollado por miembros del grupo de investigación

Arquisoft de la Universidad Distrital.

RECOLECTOR: Usuario que realizará el cargue del archivo generado en Plantae,

además de la depuración de la información recolectada y posterior solicitud de
inclusión.

SOLICITUD DE INCLUSIÓN: es la petición que realiza un usuario recolector a un

usuario validador para que sea incluido un espécimen en la base de datos del ICN.

SPECIFY: plataforma de base de datos para museos y herbarios. Gestiona la

información sobre especies y la curaduría de colecciones, seguimiento de las
transacciones de especímenes, unión de imágenes con registros de especímenes
y la publicación de datos de especímenes en internet.

VALIDADOR: Usuario del prototipo que realizará la validación de la solicitudes de

inclusión enviadas por los usuarios recolectores para aprobarlas o rechazarlas
según sea el caso.

132
 17. GUÍA DE CONTENIDO DE ANEXOS

Junto con este libro se entrega un CD, a continuación se especifica el contenido

de éste.

Figura 62. Contenido inicial del CD. Fuente. Este trabajo.

17.1 DOCUMENTOS

En esta carpeta se encuentran en formato PDF los siguientes documentos:

• Libro Final PlantaeToSpecify: este libro.

• Relación campos Prototipo y Specify: se encuentra la tabla que muestra la
relación entre los campos del prototipo y los campos de Specify.

17.2 PROTOTIPO

En esta carpeta se encuentra un archivo con extensión .WAR la estructura de los

archivos contenidos en este archivo es como se muestra en la Figura 63.

133
 Figura 63. Estructura del proyecto abierto desde Eclipse. Fuente. Este trabajo.

17.3 MODELAMIENTO

Dentro de esta carpeta encontramos el archivo generado por la herramienta

Enterprise Architect, donde se realizaron todos los modelos y diagramas que se
describieron a lo largo del documento.

A su vez dentro de este archivo encontramos los modelos divididos en carpetas de

la siguiente manera:

• Modelo de casos de uso

Actores
Casos de uso
1. Módulo de control de acceso
2. Módulo de selección y cargue de archivo
3. Módulo de gestión de especímenes

134
 4. Módulo de selección y envío de especímenes
5. Módulo de consulta y aprobación de solicitudes
6. Módulo de gestión de usuarios
• Modelo estructural
DC01 Diagrama de clases
DC02 Diagrama de clases con framework
• Modelo de datos
MR01 Modelo Relacional
• Modelo de interfaz de usuario
Modelo de interfaz gráfica
• Modelo dinámico
Diagrama de despliegue
Diagramas de secuencia
1. Módulo de control de acceso
2. Módulo de selección y cargue de archivo
3. Módulo de gestión de especímenes
4. Módulo de selección y envío de especímenes
5. Módulo de consulta y aprobación de solicitudes
6. Módulo de gestión de usuarios
Máquinas de estados
ME01 Máquina de estados espécimen
ME02 Máquina de estados solicitudes de inclusión

17.4 DICCIONARIOS

• Diccionario de clases: En este documento se detallan cada una de las

clases de lógica del negocio del prototipo, sus atributos y métodos.
• Diccionario de datos: En este documento se detallan cada una de las
tablas y campos del prototipo.

17.5 MANUALES

• Manual de instalación PlantaeToSpecifyV1: es un documento donde se

especifican los pasos para la instalación o despliegue de la aplicación en un
servidor de aplicaciones.
• Manual de usuario PlantaeToSpecifyV1: es un documento donde se
especifica el uso del prototipo para cada uno de los roles.

135
 BIBLIOGRAFÍA

1: Sosa, Giovanni, Mateus, Angela, diseño de un aplicativo de software para la

recolección de muestras biológicas en campo para el instituto de ciencias
naturales de la universidad nacional [trabajo de grado], Bogotá, Universidad
Distrital Francisco José de Caldas, Carrera de Ingeniería de Sistemas, 2015.
2: . Instituto de Ciencias Naturales. (2015) "Historia de las colecciones científicas
en línea del ICN" [En línea], recuperado el 18 de Marzo del 2015 de
http://www.biovirtual.unal.edu.co/ICN/.
3: Scott K,. The Unified Process Explained. : Addison-Wesley, 2001. 1 p.
4: Instituto de Ciencias Naturales. (2015) "Colecciones científicas en línea,
Instituto de Ciencias Naturales" [En línea], recuperado el 18 de junio de 2014 de
http://www.biovirtual.unal.edu.co/ICN/?
controlador=ShowObject&accion=show&id=10413.
5: Kuchana, Partha. “Software architecture design patterns in Java: CRC Press
LLC”, 2004. 2 p.
6: Wikipedia. (2016) "Modelo–vista–controlador" [En línea], recuperado el 25 de
agosto de 2016 de https://es.wikipedia.org/wiki/Modelo%E2%80%93vista
%E2%80%93controlador.
7: Gossman, John. (2005) "Introduction to Model/View/ViewModel pattern for
building WPF apps" [En línea], recuperado el 10 de agosto de 2016 de
https://blogs.msdn.microsoft.com/johngossman/2005/10/08/introduction-to-
modelviewviewmodel-pattern-for-building-wpf-apps/.
8: Fowler, Martin. “Patterns of enterprise application architecture” : Addison-
Wesley, 2002. 152 p.
9: ZK. (2015) "Introduction of MVVM" [En línea], recuperado el 10 de agosto de
2016 de http://books.zkoss.org/zk-mvvm-book/8.0/introduction_of_mvvm.html.
10: ZK. (2015) "ZK's Value and Strength" [En línea],
http://books.zkoss.org/zkessentials-book/master/.
11: ZK. (2013) "Architecture of ZK" [En línea], recuperado el 23 de agosto de 2016
de https://www.zkoss.org/wiki/ZK%20Essentials/Chapter%201:%20Introduction.
12: ZK. (2014) "MVC" [En línea], recuperado el 23 de agosto de 2016 de
https://www.zkoss.org/wiki/ZK%20Developer's%20Reference/MVC.
13: ZK. (2015) "MVVM & ZK Bind" [En línea], recuperado el 10 de agosto de 2016
de http://books.zkoss.org/zk-mvvm-book/8.0/mvvm_&_zk_bind.html.
14: ZK. (2013) "JPA" [En línea], recuperado el 10 de agosto de 2016 de
https://www.zkoss.org/wiki/ZK%20Developer's
%20Reference/Integration/Persistence%20Layer/JPA.
15: ZK. (2016) "MySQL 5.7 Reference Manual - General Information" [En línea],
recuperado el 10 de agosto de 2016 de
http://dev.mysql.com/doc/refman/5.7/en/introduction.html.
16: Corona S,. “Factores críticos de éxito en el proceso de migración de bases de
datos relacionales”. Universidad Nacional Autónoma de México, 2006. p.

136
17: Blázquez M,. (2012) "La Migración de datos. Exportación e Importación" [En
línea], recuperado el 15 de Enero de 2014
http://ccdocautomatizacion.blogspot.com/2008/03/10-la-migracin-de-datos-
exportacin-e.html.
18: "The Comma Separated Value (CSV) File Format" [En línea], recuperado el 20
de enero de 2014 de http://creativyst.com/Doc/Articles/CSV/CSV01.htm.
19: W3. (2013) "Extensible Markup Language (XML)" [En línea], recuperado el 20
de enero de 2014 de https://www.w3.org/XML/.
20: Microsoft. (2014) "Excel Binary File Format (.xls) Structure - Introduction" [En
línea], recuperado el 20 de enero de 2014 de https://msdn.microsoft.com/en-
us/library/dd906173(v=office.12).aspx.
21: Mozilla. (2014) "HTML" [En línea], recuperado el 20 de enero de 2014 de
https://developer.mozilla.org/es/docs/Web/HTML.
22: . Specify (2014) "Specify 6 Desktop Application" [En línea], recuperado el 20 de
Enero de 2014 de http://specifyx.specifysoftware.org/welcome-to-specify-6-
desktop-application/.
23: Apache. (2016) "Apache POI - the Java API for Microsoft Documents" [En
línea], recuperado el 10 de agosto de 2016 de https://poi.apache.org/.
24: Itext. (2013) "Itext" [En línea], recuperado el 12 de julio de 2014 de
http://itextpdf.com/.
25: Tuya, Javier, Ramos Román Isabel, Dolado Cosín, Javier. “Técnicas
cuantitativas para la gestión en la ingeniería del software”. : Netbiblo, S.L., 2007.
54 p.
26: JUnit. (2016) "JUnit" [En línea], recuperado el 25 de agosto de 2016 de
http://junit.org/junit4/.
27: Tahchiev, Petar, Leme, Felipe, Massol, Vincent, Gregory, Gary. “JUnit in
Action.” : Manning Publications, 2011. 1 p.
28: Jacobson I, Booch G, Rumbaugh J. “El proceso Unificado de Desarrollo de
software.” Madrid: Addison Wesley, 2000. 4-5 p.
29: Rumbaugh J, Jacobson I, Booch G,. “Lenguaje unificado de modelado manual
de referencia.” Madrid: Addison Wesley, 2000. 1 p.
30: Sparx. (2007) "Diagrama de clase UML2" [En línea], recuperado el 15 de enero
de 2014 de
http://www.sparxsystems.com.ar/resources/tutorial/uml2_classdiagram.html.
31: Sparx. (2007) "Diagrama de componentes UML2" [En línea], recuperado el 15
de enero de 2014 de
http://www.sparxsystems.com.ar/resources/tutorial/uml2_componentdiagram.html.
32: Diosa H, “Ingeniería de software I” [Apuntes]. Bogotá, Colombia, Universidad
Distrital Francisco José de Caldas, Ingeniería de sistemas, 2012
33: Sparx. (2007) "Diagrama de secuencia UML2" [En línea], recuperado el 15 de
enero de 2014 de
http://www.sparxsystems.com.ar/resources/tutorial/uml2_sequencediagram.html.
34: Sparx. (2007) "Diagrama de Actividades UML2" [En línea], recuperado el 15 de
enero de 2014 de
http://www.sparxsystems.com.ar/resources/tutorial/uml2_activitydiagram.html.

137
35: Sparx. (2016) "Enterprise Architect" [En línea], recuperado el 20 de agosto de
2016 de http://www.sparxsystems.com/products/ea/.
36: Oracle. (2010) "Java Persistence API" [En línea], recuperado el 18 de Marzo
del 2015 de http://docs.oracle.com/javaee/5/tutorial/doc/bnacj.html#bnadb.
37: Eclipse. (2009) “Introduction to EclipseLink JPA”, 2009, recuperado el 18 de
Marzo del 2015 de
http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Print_Version#Introduction_to_Eclips
eLink_JPA
38: Sommerville, Ian. “Ingeniería del software.” : Pearson education, 2011. 185-
187 p.

138