DESARROLLO DE UN PROTOTIPO DE SOFTWARE PARA LA...

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 MEZAJUAN CAMILO MOJICA PISCIOTTI

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDASFACULTAD DE INGENIERÍA

PROYECTO CURRICULAR INGENIERÍA DE SISTEMASBOGOTÁ 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 MEZAJUAN CAMILO MOJICA PISCIOTTI

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

DirectorPH.D. HENRY ALBERTO DIOSA

CodirectoraPH.D. LAUREN RAZ

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDASFACULTAD DE INGENIERÍA

PROYECTO CURRICULAR INGENIERÍA DE SISTEMASBOGOTÁ D.C.

2016

TABLA DE CONTENIDO

LISTA DE FIGURAS...................................................................................................6LISTA DE TABLAS.....................................................................................................8AGRADECIMIENTOS................................................................................................9INTRODUCCIÓN.....................................................................................................101. FORMULACIÓN DEL PROBLEMA......................................................................112. OBJETIVOS.........................................................................................................14

2.1 OBJETIVO GENERAL...................................................................................142.2 OBJETIVOS ESPECíFICOS.........................................................................14

3. JUSTIFICACIÓN..................................................................................................153.1 JUSTIFICACIÓN ACADÉMICA.....................................................................153.2 JUSTIFICACIÓN TÉCNICA...........................................................................153.3 JUSTIFICACIÓN PRÁCTICA........................................................................15

4. MARCO CONTEXTUAL DEL PROBLEMA.........................................................174.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............................................................................................174.1.2 Secado...................................................................................................174.1.3 Elaboración de etiquetas........................................................................174.1.4 Montaje...................................................................................................174.1.5 Sellado....................................................................................................184.1.6 Cuarentena.............................................................................................184.1.7 Toma de fotografía y código de barras...................................................184.1.8 Incluir espécimen en el herbario............................................................184.1.9 Digitalización..........................................................................................18

5. MARCO REFERENCIAL TECNOLÓGICO..........................................................225.1 PATRÓN ARQUITECTÓNICO.......................................................................22

5.1.1 Patrón de arquitectura modelo vista controlador (MVC)........................225.1.2 Patrón de arquitectura modelo-vista-vista modelo (MVVM)..................22

5.2 ZK .................................................................................................................235.2.1 Arquitectura de ZK..................................................................................235.2.2 ZK con MVC...........................................................................................245.2.3 ZK con MVVM........................................................................................25

5.3 JAVA..............................................................................................................255.4 JPA ................................................................................................................255.5 MySQL ..........................................................................................................265.6 SOBRE LA MIGRACIÓN DE DATOS............................................................26

5.6.1 CSV........................................................................................................265.6.2 XML........................................................................................................275.6.3 XLS.........................................................................................................275.6.4 HTML......................................................................................................27

5.7 SPECIFY.......................................................................................................275.8 GENERACIÓN DE ETIQUETAS...................................................................28

3

5.8.1 Apache POI............................................................................................285.8.2 Itext.........................................................................................................28

5.9 PRUEBAS UNITARIAS..................................................................................285.9.1 Junit........................................................................................................28

6. MARCO METODOLÓGICO.................................................................................296.1 MODELO DE PROCESO UNIFICADO (UP).................................................29

6.1.1 El ciclo de vida del Proceso Unificado...................................................296.1.1.1 Fase de Inicio..................................................................................306.1.1.2 Fase de Elaboración.......................................................................306.1.1.3 Fase de Construcción.....................................................................306.1.1.4 Fase de Transición..........................................................................30

6.1.2 Flujos de trabajo de proceso..................................................................306.2 LENGUAJE DE MODELADO UNIFICADO (UML)........................................31

6.2.1 Unidades lingüisticas de UML................................................................316.2.1.1 Unidades lingüisticas para el modelo funcional..............................316.2.1.2 Unidades lingüisticas para el modelo estructural...........................326.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............................................................................................347.2 FASE DE ELABORACIÓN............................................................................347.3 FASE DE CONSTRUCCIÓN.........................................................................357.4 FASE DE TRANSICIÓN................................................................................36

8. MODELO FUNCIONAL........................................................................................378.1 DEFINICIÓN DE POSIBLES ACTORES Y RESPONSABILIDADES ..........37

8.1.1 Rol recolector.........................................................................................378.1.2 Rol validador..........................................................................................388.1.3 Rol administrador...................................................................................38

8.2 DEFINICIÓN DE REQUERIMIENTOS..........................................................398.2.1 Requerimientos funcionales...................................................................39

8.3 REQUERIMIENTOS ESPECÍFICOS DE INTERFACES...............................418.3.1 Interfaces de usuario..............................................................................418.3.2 Interfaces de software............................................................................41

8.4 PROTOCOLOS DE COMUNICACIÓN.........................................................418.5 REQUERIMIENTOS DE PERSISTENCIA....................................................418.6 MODELO FUNCIONAL BASADO EN CASOS DE USO..............................42

8.6.1 Módulo de control de acceso.................................................................448.6.2 Módulo de selección y cargue de archivos............................................508.6.3 Módulo de gestión de especímenes......................................................578.6.4 Módulo de selección y envío de especímenes......................................678.6.5 Módulo de consulta y aprobación de solicitudes de inclusión para aprobación.......................................................................................................718.6.6 Módulo de gestión de usuarios..............................................................79

9. MODELO ESTRUCTURAL..................................................................................859.1 DIAGRAMA DE CLASES..............................................................................85

4

9.2 MODELO DE PERSISTENCIA......................................................................879.2.1 Estructuras de árbol...............................................................................899.2.2 Patrón de fuente de datos......................................................................909.2.3 Estrategia de mapeo..............................................................................90

9.2.3.1 Mapeador de datos.........................................................................909.2.3.2 Clase a tabla en jerarquías de herencia.........................................919.2.3.3 Clase concreta a tabla en jerarquías de herencia..........................939.2.3.4. Mapa de identidad.........................................................................95

9.2.4 Aspectos tecnológicos de mapeo...........................................................959.3 PLANTAE Y LA EXPORTACIÓN DE LOS DATOS.......................................969.4 ESTRATEGIA DE MIGRACIÓN DE DATOS A SPECIFY..............................97

9.4.1 Datos sensibles detectados en el proceso de migración.......................999.4.1.1 Árbol de la Taxonomía..................................................................1009.4.1.2 Árbol de Geografía........................................................................1019.4.1.3 Agente...........................................................................................1039.4.1.4 Otros datos....................................................................................104

10. MODELO DE INTERFAZ GRÁFICA DE USUARIO........................................10510.1 MAPA DE NAVEGACIÓN..........................................................................10510.2 GENERALIDADES DE LA INTERFÁZ GRÁFICA.....................................107

10.2.1 Página de control de acceso..............................................................10710.2.2 Página principal..................................................................................10710.2.3 Menú de opciones de usuario............................................................10910.2.4 Cambiar contraseña...........................................................................10910.2.5 Cerrar sesión......................................................................................11010.2.6 Mensajes............................................................................................11010.3 OPCIONES DE MENÚ..........................................................................11110.4 ASPECTOS DE IMPLEMENTACIÓN....................................................114

11. MODELO DINÁMICO.......................................................................................11511.1 DIAGRAMAS DE SECUENCIA.................................................................11511.2 MÁQUINAS DE ESTADO..........................................................................119

11.2.1 Máquina de estados del espécimen...................................................11911.2.2 Máquina de estados de la solicitud de inclusión ..............................119

12. TECNOLOGÍAS USADAS EN LA CONSTRUCCIÓN.....................................12113. PRUEBAS........................................................................................................123

13.1 Pruebas unitarias y de integración............................................................12314. CONCLUSIONES............................................................................................12515. TRABAJO FUTURO........................................................................................12616. GLOSARIO......................................................................................................12717. GUÍA DE CONTENIDO DE ANEXOS..............................................................128

17.1 DOCUMENTOS.........................................................................................12817.2 PROTOTIPO..............................................................................................12817.3 MODELAMIENTO......................................................................................12917.4 DICCIONARIOS........................................................................................13017.5 MANUALES...............................................................................................130

BIBLIOGRAFÍA......................................................................................................131

5

LISTA DE FIGURAS

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

6

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

7

LISTA DE TABLAS

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

http://arquisoft.udistrital.edu.co/

http://www.biovirtual.unal.edu.co/ICN/

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 InicioEn 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ónEn 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ónEn 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ónEn 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 funcionalEste 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 estructuralA 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ámicoA 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 funcionalesCÓ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 csv.

Permite al biólogo seleccionar el 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 notificación.

Genera mensajes de 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 que fueron migrados.

El biólogo puede realizar la 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 especímenes que el recolector requiere que sean almacenados en la base de datos del ICN.

Los registros seleccionados se almacenan con un estado definido, a la espera de la validación y confrontación de la información con el ejemplar físico.

RFU008 Generar las etiquetas con una plantilla establecida por el ICN.

Permite generar e imprimir 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 enviados por el recolector al usuario validador.

Permite al rol validador validar o agregar el código de barras y 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 base de datos intermedia a la base de datos del ICN.

Permite al validador migrar a la base de datos del ICN, los 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 especímenes.

Permite consultar el estado del espécimen durante todo el proceso de migración a la base de datos del ICN.

RFU012 Visualizar el histórico de los registros que fueron migrados a la base de datos del ICN.

Permite visualizar los registros que fueron migrados desde la base de datos intermedia a la base de datos del ICN.

RFU013 Visualizar el histórico de los archivos que han sido cargados en el prototipo.

Permite ver el histórico de los archivos que han sido cargados en 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

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

uc Casos de uso

Módulo de gestión de especímenes

Módulo de gestión de usuarios

CU001 Iniciar Aplicación

CU003 Validar existencia de usuario

CU015 Editar espécimen

CU019 Eliminar espécimen

CU014 Ver detalles

espécimen

CU008 Cargar archivo

CU021 Seleccionar espécimen

CU023 Enviar especímenes para

inclusión

CU020 Exportar etiqueta

CU018 Filtrar especímenes

CU005 Cerrar sesión

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

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

CU013 Listar especímenes

Módulo de selección y cargue de archivos

CU024 Consultar solicitudes de

inclusión

CU029 Aprobar solicitud

CU030 Rechazar solicitud

CU007 Listar histórico de archivos cargados

CU009 Guardar archivo

CU002 Iniciar sesión

CU022 Listar especímenes para

envío

CU027 Mostrar detalles de solicitud

de inclusión

Estos extend son excluyentes: si el registro se aprueba NO podrá ser rechazado, y si ya fue rechazado no podrán ser aprobado

CU025 Listar solicitudes de

inclusión

Módulo de control de acceso

CU010 Refrescar listado de histórico de archivos

cargados

Usuario

Validador Recolector

Administrador

CU031 Listar usuarios

CU033 Consultar usuario

CU032 Crear usuario

CU034 Modificar usuario

CU012 Gestionar especímenes

CU006 Gestionar archivos de especímenes

CU004 Habilitar menú según rol

CU011 Cancelar cargue de

archivo

CU016 Cancelar edición espécimen

CU017 Guardar edición

espécimen

Estos extend son excluyentes: si se selecciona la opción guardar no se podrá cancelar la edición, y si se selecciona la opción cancelar no se podrá guardar la edición

CU026 Filtrar solicitudes de

inclusión

CU035 Filtrar usuarios

CU028 Mostrar información a

migrar

«extend»

«extend»

«extend»

«extend»

«include»

«extend»

«extend»

«extend»

«include»

« include»

«extend»

«extend»

«extend»

«include»

«extend»

«extend»

«extend»

«extend»

«extend»

«extend»

«extend»

«include»

«extend»

«extend»

«include»

«extend»

«extend»

«include»

«extend»

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.

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

44

uc Casos de uso

CU001 Iniciar Aplicación

CU003 Validar existencia de usuario

CU005 Cerrar sesión

CU002 Iniciar sesión

M ódu lo de contro l de acceso

Usuario

CU004 Habilitar menú según rol

«extend»

«include»

«include»

«extend»

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

45

act CU001 Iniciar Aplicación

Usuario Sistema

In icio

Ingresar la URL de la aplicación en el

navegador Web y dar Enter

Establecer conexión con el serv idor

¿Conexiónexi tosa?

Mostrar ventana de inicio de sesión con sus

respectivas opciones

Fin

Mostrar mensaje de error de conexión

NO

SI

Tabla 3. Iniciar sesión

CASO DE USO

Código CU002 Nombre Iniciar sesión

Actores Usuario


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

46

act CU002 Iniciar sesión

Usuario Sistema

In icio

nom breUsuario contraseña

Ingresar credenciales de acceso


nom breUsuario

contraseña


Elige la opciónnom breUsuario

contraseña


Final

nom breUsuario

usuarioConAcceso

Validar existencia de usuario

nom breUsuario

usuarioConAcceso

Mostrar v entana de inicio de sesión

Mostrar mensaje "Usuario y/o

contraseña no válidos"

Limpiar campos

usuarioConAccesocontraseña

contraseñaCi fradacontraseñaBD

Cifrar contraseña de entrada

usuarioConAccesocontraseña

contraseñaCi fradacontraseñaBD

contraseñaBD contraseñaCifrada

Comparar contraseña de entrada cifrada con

contraseña de BD

contraseñaBD contraseñaCifrada

¿Contraseña esvál ida?

Verificar estado del usuario

¿estado== activo?

Mostrar mensaje "Usuario inactiv o"

usuarioConAcceso!= nul l

usuario

Habilitar menú según rol

usuario

[Aceptar]

[SI]

[NO]

[Cancelar]

[SI]

[NO]

[NO]

Tabla 4. Validar existencia de usuario

CASO DE USO

Código CU003 Nombre Validar existencia de usuario

Actores Sistema


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

47

act CU003 Validar existencia de usuario

nom breUsuario:String

usuarioConAcceso

Validar existencia de usuario

nom breUsuario:String

usuarioConAcceso

Buscar nombreUsuario en

base de datos intermedia

nom breUsuario

usuarioConAcceso

«datasto re»Base de datos

intermedia

¿Existenom bre deusuario?

usuarioConAcceso

retornar usuarioConAcceso

null

usuarioConAcceso

El ob jeto usuario contiene e l nom breUsuario , contraseña , ro l , estado,en tre o tros.

usuarioConAcceso

retornar usuarioConAcceso

usuarioConAcceso

[NO][SI]

Usuario

Tabla 5. Habilitar menú según rol

CASO DE USO

Código CU004 Nombre Habilitar menú según rol

Actores Sistema


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

48

act CU004 Habilitar menú según rol

usuario :UsuarioConAcceso

Habilitar menú según rol

usuario :UsuarioConAcceso usuario

l istaRo les

Obtener lista de roles del usuariousuario

l istaRo les

¿hay m ásro les?

¿rol =adm inistrador?

Habilitar opción de menú administración de

usuarios

¿ro l =recolector?

Habilitar opciones de menú importar datos de

especímenes, gestión de especímenes y Envío de solicitudes de inclusión

¿ro l =val idador?

Habilitar opción de menú solicitudes de inclusión

Fin

[SI]

[NO]

[SI]

[SI]

[NO]

[SI]

[NO]

Tabla 6. Cerrar sesión

CASO DE USO

Código CU005 Nombre Cerrar sesión

Actores Usuario


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

49

act CU005 Cerrar Sesión

Usuario Sistema

In icio

Elige la opción cerrar sesión

Borrar datos de sesión

Mostrar ventana de inicio de sesión

Fin

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”.

Figura 13. Diagrama de casos de uso del módulo de selección y cargue de archivos. Fuente: Este trabajo.

50

uc Casos de uso

CU008 Cargar archivo

M ódulo de se lección y cargue de archivos

CU007 Listar histórico de archivos cargados

CU009 Guardar archivo

CU010 Refrescar listado de histórico de archivos

cargados

Recolector

CU006 Gestionar archivos de especímenes

CU011 Cancelar cargue de archivo

«extend»«include»

«include»

«extend»

«extend»

Tabla 7. Gestionar archivos de especímenes

CASO DE USO

Código CU006 Nombre Gestionar archivos de especímenes

Actores Recolector


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

51

act CU006 Gestionar archivos de especímenes

SistemaRecolector

Inicio

Clic en la opción de menú importar especímenes

usuarioConAcceso

Desplegar formulario de importar especímenes

usuarioConAcceso

usuarioConAcceso

Listado de reg istros

Listar histórico de archivos cargados

usuarioConAcceso

Listado de reg istros

Listado de registros

Mostrar listado de archivos

Listado de registros

Fin

Tabla 8. Listar histórico de archivos guardados

CASO DE USO

Código CU007 Nombre Listar histórico de archivos guardados

Actores Sistema


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

52

act CU007 Listar histórico de archivos cargados

usuarioConAcceso :UsuarioConAcceso

Listado deregistros

Listar histórico de archivos cargados


Listado deregistros

usuarioConAcceso

Consultar registros de archivos cargados

usuarioConAcceso

Listado deregistros

Listar registros

Listado deregistros

«BD Interm edia»Archivo

Tabla 9. Cargar archivo

CASO DE USO

Código CU008 Nombre Cargar archivo

Actores Recolector


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

53

act CU008 Cargar archivo

Recolector Sistema

In icio

Clic en cargar archivo Desplegar ventana de búsqueda y cargue de

archivos

archivo

Buscar y seleccionar archivo almacenado en el

dispositivo móvil

archivo

archivo

arch ivo

Seleccionar opción

archivo

arch ivo

Fin

¿validaciónco rrecta?

Selecciona aceptarMostrar mensaje

"Archivo incorrecto"

archivo

Validar tipo de archivo

archivo

Habilitar botón guardar y botón cancelar

Limpiar ruta del archivo seleccionado

[NO]

[SI]

[Cancelar]

[Aceptar]

Tabla 10. Guardar archivo

CASO DE USO

Código CU009 Nombre Guardar archivo

Actores Recolector


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

54

act CU009 Guardar archivo

Recolector Sistema

In icio

¿Hay m ásregistros?

Mostrar mensaje de "archivo procesado

exitosamente"

usuarioConAcceso

Elige la opción aceptar

usuarioConAcceso

Fina l

arch ivo

Guardar registro

archivo«BD Interm ed ia»

Especímenes

Mostrar mensaje de error de creación y deshacer

toda la transacción

archivo

Elige la opción de guardar archivo

archivo

l istado de reg istros

Actualizar listado de registros en ventana


¿Creacióncorrecta?

usuarioConAcceso


Refrescar listado de histórico de archivos

cargados

usuarioConAcceso


NO

[S I]

[SI]

[NO]

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


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

55

act CU010 Refrescar listado de histórico de archivos cargados


l istado deregistros

Refrescar listado de histórico de archivos cargados


l istado deregistros

usuarioConAcceso

Consultar registros de archivos cargados

usuarioConAcceso

«BD Interm edia»Archivo

l i stado deregistros

Actualizar listado de registros

l i stado deregistros

Tabla 12. Cancelar cargue de archivos

CASO DE USO

Código CU011 Nombre Cancelar cargue de archivos

Actores Recolector


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

56

act CU011 Cancelar cargue de archivo

SistemaRecolector

Inicio

Elige la opción de cancelar cargue de

archivo

Limpiar ruta de archivo

Deshabilitar botones de Guardar archivo y Cancelar archivo

Fin

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”.

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

57

uc Casos de uso

M ódulo de gestión de especím enes

CU017 Editar espécimen

CU021 Eliminar espécimen

CU014 Ver detalles espécimen

CU022 Exportar etiqueta

CU020 Filtrar espécimen

CU013 Listar especímenes

Recolector

CU012 Gestionar especímenes

CU015 Crear opciones desplegadas

CU016 Eliminar opciones desplegadas

CU018 Cancelar edición espécimen

CU019 Guardar edición espécimen

Estos extend son excluyentes: si se se lecciona la opción guardar no se podrá cancela r la edición, y si se selecciona la opción cancela r no se podrá guardar la ed ición

«extend»

«extend»

«include»

«extend»

«extend»

«extend»«include»

«extend»

«extend»

«include»

Tabla 13. Gestionar espécimen

CASO DE USO

Código CU012 Nombre Gestionar espécimen

Actores Usuario


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

58

act CU012 Gestionar especímenes

SistemaRecolector

In icio

Selecciona opción de gestión de especímenes

usuarioConAcceso

Cargar ventana de gestión de especímenes

usuarioConAcceso

usuarioConAcceso

lista de especim enes

Listar Especímenes

usuarioConAcceso



Mostrar listado de especímenes

l i sta de especim enes

Fin

Tabla 14. Listar especímenes

CASO DE USO

Código CU013 Nombre Listar especímenes

Actores Sistema


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

59

act CU013 Listar especímenes

l i sta deespecím enes

usuarioConAcceso

Listar especímenes


usuarioConAcceso

l ista deespecím enes

l ista deregistros

Cargar lista con registros


l ista deregistros

«BD Interm edia»Especímenes

l ista de registros

Realizar búsqueda de especímenes

l ista de registros

Solo l istará los especím enes que pertenecen a l usuario.

Tabla 15. Ver detalles espécimen

CASO DE USO

Código CU014 Nombre Ver detalles espécimen

Actores Recolector


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

60

act CU014 Ver detalles espécimen

Recolector Sistema

In icio

espécim en

Selecciona la opción ver detalles sobre uno de los

especímenes listado espécim en

Habilitar opción de editar

Fin

espécim en

espécim en

Verificar estado del espécimen

espécim en

espécim en

¿Estado != Enviado &&E stado != Aprobado?

espécim en

espécim en

Desplegar información del espécimen

espécim en

espécim en

especim en

especim en

CU015A Crear opciones desplegadas

especim en

especim en

[NO]

[S I]

Tabla 16. Editar espécimen

CASO DE USO

Código CU015 Nombre Editar espécimen

Actores Recolector


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

61

act CU015 Editar espécimen

Recolector Sistema

Inicio

Elige la opción editarHabilitar campos editables

del registro

Fin

Habilita las opciones guardar y cancelar

Deshabilita opción editar

La información editable es la relacionada con:Evento de colecciónUbicaciónT axonom íaDeterm inaciónAtributos del espécimenPlantaHojaFlorFrutoInflorescenciaT al loRaíz

Tabla 17. Cancelar edición espécimen

CASO DE USO

Código CU016 Nombre Cancelar edición espécimen

Actores Recolector


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

62

act CU016 Cancelar edición espécimen

SistemaRecolector

In icio

Elige opción cancelar Deshacer cambios

Deshabilitar campos editables

Deshabilitar opciones guardar y cancelar

Habilitar opción editar

Fin

Tabla 18. Guardar edición espécimen

CASO DE USO

Código CU017 Nombre Guardar edición espécimen

Actores Recolector


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

63

act CU017 Guardar edición espécimen

SistemaRecolector

Inicio

Elige opción guardar Verificar cambios realizados

¿Hay cam bios enla in formación?

Actualizar registro

«Base de datos i ...Base de datos

intermedia

¿Actual izacióncorrecta?

Mostrar mensaje de actualización correcta

Mostrar mensaje de error en actualización

Elige opción ok

Deshabilitar campos editables

Recuperar valores originales

Habilitar opción editar

Deshabilitar opción cancelar y guardar

Fin

[NO]

[SI]

[NO]

[SI]

Tabla 19. Filtrar espécimen

CASO DE USO

Código CU018 Nombre Filtrar espécimen

Actores Recolector


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

64

act CU018 Filtrar especímenes

Recolector Sistema

In icio

valorFil tros

Ingresa un valor en los campos de filtro

valorFil tros valorFi l tros

Filtrar especímenes según valorFiltros

valorFi l tros

Fin

Actualizar listado en la ventana.

Se puede fi l trar por código de recolección, fecha de recolección y estado del espécimen

Tabla 20. Eliminar espécimen

CASO DE USO

Código CU019 Nombre Eliminar espécimen

Actores Recolector


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

65

act CU019 Eliminar espécimen

Recolector Sistema

In icio

Mostrar ventana de confirmación de

eliminación

«B D Inte rm edia »espécimen

Actualizar listado de especímenes

incorrectos++

Fin

Seleccionar opción


¿B orrado exi to so?

l i staEspecim enes

li staE specim en es

tamaño = Número de especímenes seleccionados

l i staEspecim enes




i=0, correctos=0, incorrectos=0

l i staE specim en es


¿i <tam año?


Tomar registro i de la lista

l i staE specim en es

¿estado Espe cim en !=enviado &&estadoE specim en !=ap robado& &estadoE specim en!= pend ien te ?

i++

correctos++

Mostrar mensaje de resultado del borrado con

cantidad de borrados y cantidad de no borrados

Borrar registro de la base de datos

l i staEspecim enes

Selecciona los especímenes que quiere

eliminar

l i staEspecim enes

Elige la opción Eliminar

[S I]

[Acep tar]

[Cancela r]

[SI]NO

[S I]

[NO]

[NO]

Tabla 21. Exportar etiqueta

CASO DE USO

Código CU020 Nombre Exportar etiqueta

Actores Recolector


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

66

act CU020 Exportar etiqueta

Recolector Sistema

In icio

l istado deespecím ene s

Elige la opción generar etiqueta l istado de

especím ene s

Fin

l i stado deespecím enes

l istado deespecím enes

Crear lista de etiquetas



archivo pdfEnv iar archiv o pdf al

navegador web

archivo pdf

Selecciona los especímenes

espécim en

etiqueta

generar etiquetaespécim en

etiqueta



tamanio = tamaño del listado de especímenes


l istado deespecím enesl istado de

especím enes


i=0



i<tam anio?

l i stado de especím enes

esp écim e n

tomar espécimen i de la lista

l i stado de especím enes

esp écim e n

etiqueta

agregar etiqueta a la lista de etiquetas

etiqueta

i++

l i sta deetiquetasarchivo pdf

concatenar todas las etiquetas en un único

archiv o pdf l i sta deetiquetasarchivo pdf

Depe nd iendo del navega dor web del usuario el a rchivo se descargará d i rectam ente o se m ostrará al usuario un m ensaje preguntando le que acción desea real i zar sobre e l m ism o

La in form ación que se agrega en la etiqueta es toda la in form ación de l espé cim e n disponib le rela ciona da con :

Evento de colecciónUbicaciónT axon om íaDeterm inaciónAtribu tos d el espécim enPlantaHojaFlorFru toInflo rescenciaT a l loRaíz

[NO]

[SI]

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”.

Figura 15. Diagrama de casos de uso del módulo de selección y envío de especímenes. Fuente. Este trabajo.

67

uc Casos de uso

CU021 Seleccionar espécimen

CU023 Enviar especímenes para

inclusión

M ódulo de se lección y envío de especím enes

CU022 Listar especímenes para

envío

Recolector

«include»

«extend»

Tabla 22. Seleccionar espécimen

CASO DE USO

Código CU021 Nombre Seleccionar espécimen

Actores Recolector


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

68

act CU021 Seleccionar espécimen

Recolector Sistema

In icio

usuarioConAcceso

Elige la opción de menú solicitar inclusión de

especímenes usuarioConAcceso

usuarioConAcceso


Listar especímenes para envío

usuarioConAcceso


Cargar listado de especímenes

Fin

Marcar casilla de selección de especímenes para ser

enviados

Habilitar opción de envíar especímenes

Solo trae los registros que pertenecen a l reco lector y cuyos estados son "Cargado" o "Edi tado"

Tabla 23. Listar especímenes para envío

CASO DE USO

Código CU022 Nombre Listar especímenes para envío

Actores Sistema


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

69

act CU022 Listar especímenes para envío



Listar especímenes para envío




Consultar especímenes


«BD Interm edia»Especimen



Retornar listado de especímenes



Solo trae los registros que pertenecen a l reco lector y cuyos estados son "Cargado" o "Edi tado"

Tabla 24. Enviar especímenes para inclusión

CASO DE USO

Código CU023 Nombre Enviar especímenes para inclusión

Actores Recolector


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

70

act CU023 Env iar especímenes para inclusión

Recolector Sistema

Inicio

Elige la opción de solicitar inclusión de especímenes

Mostrar ventana de confirmación de solicitud

de inclusión de especímenes

Seleccionar opción

Cerrar ventana de confirmación de solicitud

de inclusión de especímenes

espécimen

Actualizar estado del espécimen

espécimen

listado de especím enes

li stado de especím enes

tamaño = Calcular tamaño del listado de especímenes



espécimen

l istado de especímenes

Tomar registro i de la lista

espécimen




i=0, correctos=0, incorrectos=0



i++

¿i<tamaño?

correctos++

Agregar espécimen a la lista de incorrectos

incorrectos++

Generar mensaje "Actualización finalizada,

se habilitaron <<correctos>>

especímenes para validación, no fue posible habilitar <<incorrectos>>

especímenes"

Fin


Mostrar listado de incorrectos

«BD Intermedia»Espécimen,

solicitudes de inclusión

espécimen

espécimen

Generar solicitud de inclusión

espécimen

espécimen

¿Actual i zacióncorrecta?

[cancelar]

[Aceptar]

[SI]

[NO]

[NO]

[SI]

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”.

Figura 16. Diagrama de casos de uso del módulo de consulta y aprobación de solicitudes de inclusión. Fuente: Este trabajo.

71

uc Casos de uso

M ódulo de consul ta y aprobación de sol ici tudes de inclusión para aprobación

CU024 Consultar solicitudes de inclusión

CU029 Aprobar solicitud

CU030 Rechazar solicitud

CU027 Mostrar detalles de solicitud de inclusión

Estos extend son excluyentes: si el reg istro se aprueba NO podrá ser rechazado, y si ya fue rechazado no podrán ser aprobado

CU025 Listar solicitudes de inclusión

Validador

CU026 Filtrar solicitudes de inclusión

CU028 Mostrar información a migrar

«extend»

«extend»

«include»

«extend»

«extend»

«extend»

Tabla 25. Consultar solicitudes de inclusión

CASO DE USO

Código CU024 Nombre Consultar solicitudes de inclusión

Actores Validador


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

72

act CU024 Consultar solicitudes de inclusión

Validador Sistema

In icio

estado

Elige la opción Solicitudes de inclusión

estado

l istado de sol ici tudes

Desplegar listado de especímenes para ser

aprobados


Fin

Habilitar opción "ver más", "Aprobar solicitud"

y "Rechazar solicitud" sobre cada espécimen

estado


Listar solicitudes de inclusión

estado


Selecciona una solicitud del listado

Tabla 26. Listar solicitudes de inclusión

CASO DE USO

Código CU025 Nombre Listar solicitudes de inclusión

Actores Sistema


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

73

act CU025 Listar solicitudes de inclusión

l i stado deso l ici tudes

estado:String


l i stado deso l ici tudes

estado:String

estado

Consultar registros listos para inclusión

estado

«BD Interm e...Solicitudes de

inclusión

l i stado desol ici tudes


l i stado desol ici tudes

Tabla 27. Filtrar solicitudes de inclusión

CASO DE USO

Código CU026 Nombre Filtrar solicitudes de inclusión

Actores Validador


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

74

act CU026 Filtrar solicitudes de inclusión

Validador Sistema

Inicio

valorFi l tros

Ingresar un valor en los campos de filtro

valorFi l tros valorFi l tros

Filtrar solicitudes de inclusión según

valorFiltrosvalorFi l tros

Actualizar listado en la ventana

Fin

Se puede fi l trar por código derecolección, fecha de envío de la sol ici tud y fecha de recolección

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


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

75

act CU027 Mostrar detalles de solicitud de inclusión

Validador Sistema

In icio

usuarioConAccesoElige la opción "Ver más" sobre cualquier

espécimen

usuarioConAcceso

usuarioConAcceso

especim en

Cargar detalles del espécimenusuarioConAcceso

especim en

«BD Interm edia»Espécimen

especim en

Desplegar información adicional del espécimen

especim en

Fin

Tabla 29. Mostrar información a migrar

CASO DE USO

Código CU028 Nombre Mostrar información a migrar

Actores Validador


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

76

act CU028 Mostrar información a migrar

SistemaValidador

In icio

Elige la opción datos a specify

Cargar información del espécimen que será

migrada a specify

Desplegar información adicional del espécimen

Fin

Tabla 30. Aprobar solicitud

CASO DE USO

Código CU029 Nombre Aprobar solicitud

Actores Validador


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

77

act CU029 Aprobar solicitud

Validador Sistema

In ici o

Elige la opción aprobar espécimen

Desplegar ventana para insertar código de barras

y código del herbario

codigoBarras,codigoColeccion

Ingresa los códigos solicitados

codigoBarras,codigoColeccion

Selecciona opciónDesplegar cuadro de

confirmación de aprobación

Insertar registros

«BD ICN»Base de datos oficial del ICN

Fin

Mostrar mensaje "Espécimen ingresado en

la base de datos correctamente"


¿Actua li zacióncorrecta?

Mostrar mensaje de actualización incorrecta

Selecciona opción

Selecciona una de las solicitudes de inclusión

Habilita las opciones Aprobar solicitud y Rechazar solicitud

Cambiar estado de la solicitud a aprobada

Cambiar estado del espécimen a Aprobado

«BD Interm ed i ...Solicitud inclusión

«B D In te rm e ...Especimen

[Cance la r]

[NO ]

[A ceptar]

[Cance la r]

[A ceptar]

[S I]

Tabla 31. Rechazar solicitud

CASO DE USO

Código CU030 Nombre Rechazar solicitud

Actores Validador


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

78

act CU030 Rechazar solicitud

Validador Sistema

In icio

Elige la opción rechazar solicitud

Desplegar v enta de motiv o de rechazo

Ingresar observaciones acerca del rechazo

Seleccionar opción

Actualizar registro en la base de datos

« BD In term edi ...Espécimen,

SolicitudInclusion


Fin

Mostrar cuadro de confirmación de rechazo

Seleccionar opción


¿Actu a l i za ció nco rrecta?


Selecciona una solicitud de inclusión

Habilita las opciones aprobar solicitar y rechazar solicitud

Aceptar

[Can ce lar]

[Ace p ta r]

[Ca nce lar]

[S I]

[NO ]

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”.

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

79

uc Casos de uso

M ódulo de gestión de usuarios

Administrador

CU031 Listar usuarios

CU033 Consultar usuario

CU032 Crear usuario

CU034 Modificar usuario

CU035 Filtrar usuarios

«extend»

«extend»

«extend»

«extend»

Tabla 32. Listar usuarios

CASO DE USO

Código CU031 Nombre Listar usuarios

Actores Administrador


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

80

act CU031 Listar usuarios

SistemaAdministrador

In icio

Elige la opción administración de

usuarios

l istaUsuarios

Consultar usuarios del sistema

l istaUsuarios

«BD Interm edia»usuarioConAcceso

l istaUsuarios

Mostrar listado de usuarios

l istaUsuarios

Fin

Tabla 33. Crear usuario

CASO DE USO

Código CU032 Nombre Crear usuario



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

81

act CU032 Crear usuario


In icio

Selecciona opción agregar usuario

Desplegar ventana con formulario de creación de

usuario

da tos de reg istro

Ingresar datos de usuario

da tos de reg istro

da tos de reg istro

da tos de reg istro

Verificar campos obligatorios

da tos de reg istro

da tos de reg istro

Los cam pos del form u la ri o son :- Iden ti ficación*- Nom bre*- Prim er ape l l ido *- Segundo apel l i do- Co rreo e lectrón i co- Insti tución- Usua ri o *- Se lecciona r estado* (A ctivo , i nacti vo )- Contraseña*- Se lecciona r ro les (reco lecto r, va l idado r y adm in i strador)_________________* Cam pos ob l i gato rios

Seleccionar opción

¿cam posob l iga to riocom ple tos?

Resaltar campos obligatorios

da tos de reg istro

Registrar usuario

da tos de reg istro«B D In te rm ed ia»

usuarioConAcceso

¿creacióncorrecta?

Mostrar mensaje de creación incorrecta

Cerrar ventana con formulario de creación de

usuario

Fin

Mostrar mensaje de creación correcta

Seleccionar aceptar

Seleccionar aceptar

[Acep ta r]

[Cance la r]

[SI]

[S I][NO]

[NO ]

Tabla 34. Consultar usuario

CASO DE USO

Código CU033 Nombre Consultar usuario



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

82

act CU033 Consultar usuario


In icio

Selecciona el usuario Habilitar opción de consultar sobre el usuario

seleccionado

Selecciona opción consultar

Mostrar ventana con la información del usuario

Fin

Tabla 35. Modificar usuario

CASO DE USO

Código CU034 Nombre Modificar usuario



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

83

act CU034 Modificar usuario


In icio

Selecciona el usuarioHabilitar opción de editar

sobre el usuario seleccionado

Seleccionar opción editar

Mostrar ventana con la información del usuario y

con los campos habilitados para edición

da tos d el reg istro

Editar información del usuario

da tos d el reg istro

Cerrar ventana con la información del usuario

Seleccionar opción

dato s d el reg istro

Actualizar registro

dato s d el reg istro«BD In te rm ed ia»

usuarioConAcceso

¿Actu al i zació ncorrecta?


Seleccionar aceptar

Fin


Seleccionar aceptar [Cancela r]

[Acep tar]

[S I]

[NO ]

Tabla 36. Filtrar usuarios

CASO DE USO

Código CU035 Nombre Filtrar usuarios



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

84

act CU035 Filtrar usuarios

Administrador Sistema

In icio

valorFi l tros

Ingresar un valor en los campos de filtro

valorFi l tros valorFi l tros

Filtrar usuarios según valorFiltros

valorFi l tros

Actualizar listado en la ventana

Fin

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:

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

class MR01 - Modelo Relacional

INT_Sitio_Geografico

«co lum n»*PK SEC_Si tio_Geogra fico: INT EGER* S i tio_Geografico: VARCHAR(30)* Nom bre: VARCHAR(130)* Nive l : INT EGER FK SEC_Padre : INT EGER

«PK »+ INT _Si tio_Geogra fico_PK(INT EGER)

«unique»+ INT _Si tio_Geogra fico_U1(VARCHAR)+ INT _Si tio_Geogra fico_U2(VARCHAR)

«FK»+ INT _Si tio_Geogra fico_F1(INT EGER)

+INT _Si tio_G eogra fico_F1

0..*

(SE C_Padre =SE C_Si tio_Geografi co )

«FK»

+INT _S i tio_Geografico_PK

0..1

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 datosEs 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.

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

90

class DC02 Diagrama de clases con framework

GeneralSessionBean

- emfactory: Enti tyM anagerFactory- em: Enti tyM anager- etx: Enti tyT ransaction

- configureQuery(Class<T >, M ap, boolean, String) : <T > Query+ createEnti ties(List<T >) : T List<T >+ createEnti ty(T )(T ) : <T > T- createQuery(Class<T >, boolean, String) : <T > Query- createQuery(Class<T >, boolean, String) : <T > Query+ findAl lEnti t ies(Class<T >) : <T > List<T >+ findAl lEnti t ies(M ap, boolean, String, Class<T >) : <T > List<T >+ findEnti ty(boolean, String, Class<T >) : <T > T+ findEnti ty(Object, Class <T >) : <T > T+ findEnti ty(Map, boolean, String , Class<T >) : <T > T+ GeneralSessionBean()+ getReferenceEnti ty(int, Class <T >) : <T >+ getSysdate() : Date+ refreshEnti ty(T )(T ) : <T > T+ rem oveEnti ty(Object) : boolean- setParam etersFrom M ap(Query, M ap) : void+ updateEnti ties(List<T >)(List<T>) : <T > List<T >+ updateEnti ty(T ) : <T > T

9.2.3.2 Clase a tabla en jerarquías de herenciaRepresenta 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

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

92

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- inflorescencia: Inflorescencia- raiz: Raiz

«property get»+ getAbundancia() : String+ getAltura() : String+ getAtributoEspecimen() : AtributoEspecimen+ getCodigoBarras() : int+ getCodigoColeccion() : int+ getCodigoRecoleccion() : String+ getColectoresSecundarios() : List<UsuarioSinAcceso>+ getColor() : Color+ getDap() : String+ getDescMuestrasAsociadas() : String+ getDescripcion() : String+ getDescripcionPlanta() : String+ getDeterminacion() : Determinacion+ getEstadoEspecimen() : EstadoEspecimen+ getEventoColeccion() : EventoColeccion+ getFlor() : Flor+ getFruto() : Fruto+ getHoja() : Hoja+ getInflorescencia() : Inflorescencia+ getLocalidad() : Localidad+ getMeTraMueAsociadas() : String+ getRaiz() : Raiz+ getSecEspecimen() : int+ getSecPlanta() : int+ getTallo() : Tallo+ getTaxonomia() : Taxonomia+ getUsuarioConAcceso() : UsuarioConAcceso

«property set»+ setAbundancia(String) : void+ setAltura(String) : void+ setAtributoEspecimen(AtributoEspecimen) : void+ setCodigoBarras(int) : void+ setCodigoColeccion(int) : void+ setCodigoRecoleccion(String) : void+ setColectoresSecundarios(List<UsuarioSinAcceso>) : void+ setColor(Color) : void+ setDap(String) : void+ setDescMuestrasAsociadas(String) : void+ setDescripcion(String) : void+ setDescripcionPlanta(String) : void+ setDeterminacion(Determinacion) : 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

Especimen

- atributoEspecimen: AtributoEspecimen- codigoBarras: int- codigoColeccion: int- codigoRecoleccion: String- colectorPrincipal: UsuarioConAcceso- descripcion: String- determinacion: Determinacion- estadoEspecimen: EstadoEspecimen- eventoColeccion: EventoColeccion- localidad: Localidad- secEspecimen: int- taxonomia: Taxonomia- archivo: Archivo- colectoresSecundarios: List<UsuarioSinAcceso>

«property get»+ getAtributoEspecimen() : AtributoEspecimen+ getCodigoBarras() : int+ getCodigoColeccion() : int+ getCodigoRecoleccion() : String+ getDescripcion() : String+ getDeterminacion() : Determinacion+ getEstadoEspecimen() : EstadoEspecimen+ getEventoColeccion() : EventoColeccion+ getLocalidad() : Localidad+ getSecEspecimen() : int+ getTaxonomia() : Taxonomia+ getcolectorPrincipal() : UsuarioConAcceso+ getArchivo() : Archivo+ getColectoresSecundarios() : List<UsuarioSinAcceso>

«property set»+ setAtributoEspecimen(AtributoEspecimen) : void+ setCodigoBarras(int) : void+ setCodigoColeccion(int) : void+ setCodigoRecoleccion(String) : void+ setDescripcion(String) : void+ setDeterminacion(Determinacion) : void+ setEstadoEspecimen(EstadoEspecimen) : void+ setEventoColeccion(EventoColeccion) : void+ setLocalidad(Localidad) : void+ setcolectorPrincipal(UsuarioConAcceso) : void+ setSecEspecimen(int) : void+ setTaxonomia(Taxonomia) : void+ setArchivo(Archivo) : void+ setColectoresSecundarios(List<UsuarioSinAcceso>) : void

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 herenciaRepresenta 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 Modelo de datos

INT_Planta

«column»*PK SEC_Planta: INTEGER FK SEC_Color_Planta: INTEGER FK SEC_Flor: INTEGER FK SEC_Fruto: INTEGER FK SEC_Hoja: INTEGER FK SEC_Tallo: INTEGER FK SEC_Raiz: INTEGER FK SEC_Inflorescencia: INTEGER FK SEC_Especimen: INTEGER Altura: VARCHAR(130) DAP: VARCHAR(130) Abundancia: VARCHAR(130) Descripcion_Planta: TEXT Desc_Muestras_Asociadas: TEXT Me_Tra_Mue_Asociadas: TEXT

INT_Especimen

«column»*PK SEC_Especimen: INTEGER*FK SEC_Archivo: INTEGER* Cod_Recoleccion: VARCHAR(50) Codigo_Coleccion: VARCHAR(32) Codigo_Barras: VARCHAR(32) = NULL*FK SEC_Usuario_Recolector: INTEGER Descripcion: TEXT*FK SEC_Estado_Especimen: INTEGER FK SEC_Taxonomia: INTEGER FK SEC_Determinacion: INTEGER FK SEC_Localidad: INTEGER FK SEC_Atributo_Especimen: INTEGER FK SEC_Evento_Coleccion: INTEGER Tipo: VARCHAR(45) = Planta

+INT _Planta_F8

1

(SEC_Especim en = SEC_Especim en)

«FK»

+INT _Especim en_PK

1

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

94

class DC01 Diagrama de clases

Usuario

- correoElectron ico: S tring- identi ficacion: in t- insti tucion: String- nom bre: String- p rim erApel l ido : String- secUsuario: in t- segundoApel l ido : S tring

«p roperty get»+ getCorreoElectron ico() : S tring+ getIdenti ficacion() : int+ getInsti tucion() : S tring+ getNom bre() : String+ getPrim erApel l ido() : S tring+ getSecUsuario() : int+ getSegundoApel l ido() : S tring

«p roperty set»+ setCorreoElectron ico(String) : void+ setIdenti ficacion(i nt) : vo id+ setInsti tucion(String) : vo id+ setNom bre(String) : void+ setPrim erApel l ido(String) : void+ setSecUsuario(int) : void+ setSegundoApel l ido (String) : void

UsuarioSinAcceso

- descripcion: String- tipoUsuario : String

«property get»+ getCorreoElectronico() : String+ getDescripcion() : S tri ng+ getIden ti fi cacion() : in t+ getInsti tucion() : String+ getNom bre () : S tring+ getPrim erApel l ido() : String+ getSecUsuario() : int+ getSegundoApel l ido() : String+ getT ipoUsuario() : String

«property set»+ se tCorreoElectronico(String) : vo id+ se tDescripcion(String) : void+ se tIdenti ficacion(in t) : vo id+ se tInsti tucion(String) : vo id+ se tNom bre(String) : void+ se tPrim erApel l ido(String) : vo id+ se tSecUsuario(in t) : vo id+ se tSegundoApel l ido(String) : vo id+ se tT i poUsuario(String) : vo id

UsuarioConAcceso

- contrasena: S tring- estado: String- roles: L ist<Ro l>- usuario: String

«property get»+ getCorreoElectronico() : String+ getIdenti ficacion () : in t+ getInsti tucion() : String+ getNom bre() : String+ getPrim erApel l ido() : String+ getSecUsuario() : in t+ getSegundoApel l ido() : String+ getRoles() : L ist<Rol>+ getEstado() : S tring

«property set»+ setCorreoElectron ico(String) : void+ setIdenti ficacion(int) : void+ setInsti tucion(String ) : void+ setNom bre(String) : vo id+ setPrim erApel l ido(String) : void+ setSecUsuario(int) : void+ setSegundoApel l ido(String ) : voi d+ setRoles(List<Rol>) : vo id+ setEstado(String) : void

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

9.2.3.4. Mapa de identidadLa 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

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)

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 migradosBase de datos del prototipo Base de datos Specify

TABLA CAMPO CAMPO TABLA

INT_Especimen

codigo_recoleccion StationFieldNumber collectingevent

codigo_coleccion CatalogNumber collectionObject

codigo_barras AltCatalogNumber collectionObject

INT_Evento_Coleccion

fecha_ini_recoleccion startDate collectingevent

fecha_fin_recoleccion EndDate collectingevent

metodo Method collectingevent

estacion_ano Remarks collectingevent

INT_Localidad

nombre localityName locality

elevacion_minima MinElevation locality

elevacion_maxima MaxElevation locality

latitud Latitude1 locality

longitud Longitude1 locality

descripcion remarks locality

INT_Atributo_Especimen

usos text1 collectionobjectattribute

vegetacion text5 collectionobjectattribute

suelo_sustrato text5 collectionobjectattribute

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 (departamento)

name geography

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íaEn 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íaEn 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 AgenteDado 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 datosAl 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:

ButtonTextboxLabelMenuItem

ToolbarToolbarbuttonListBoxBorderlayaot

GroupboxTabboxTabsTabpanels

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

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

sd DS007 Gestionar archivos de especímenes

Argum ento de a l to o rden de operación actual iza rL istaArch ivosCargados

Reco lecto r

(from Acto res)

Im portarEspecim enViewM odel «Logger»

l og

«Li stbox»

l i staArch ivos

«L inkedL ist<Arch ivo>»

l istaArch ivosCargados

usuario:UsuarioConAcceso

«Se lecto rs»m enuIm porta rDa tosE specim enes

textboxRutaArch ivo

bu ttonSub i rArch ...

bu ttonGuardarArchi vo

buttonCance la rArch ivo

Boce tos de in terfaz g rá fica : Cargar a rch i vo

ref

Listar historico de archivos cargados«Usuari oConAcceso»usuario«Usuari oConAcceso»usuario

«Li st<Archi vo>»arch ivo«Li st<Archi vo>»arch ivo

«onCli c»

in i t()

i ni t(usuario )

in fo (" in i t")

usuario=se tUsuario(UsuarioConAcceso)

a fte rCom pose(Com ponent vi ew)

in fo ("a fte rCom pose")

wi reCom ponen ts(view,th is, fa lse )

ge tUsuario()

setL istaArchivosCargados(l ist<a rchivo>)

Figura 45. DS008 Listar histórico de archivos cargados. Fuente. Este trabajo.

sd DS008 Listar histórico de archivos cargados

Argum entos de al to orden de la operacion findAl lEnti ties

Argum entos de a l to de orden de la operación findAl lEnti ties

try

try

Fi leM anager

«HashM ap»

param s

«List<Archivo>»

arch ivos

«Genera lException»

Im portarEspecim enViewM odel Logger

gb:GeneralSessionBean

«UsuarioConAcceso» usuario«UsuarioConAcceso» usuario

«List<Archivo>» archivos«List<Archivo>» archivos

«Genera lException»«Genera lException»

alt catch

[Exception e ]

alt catch

[Exception e]

Región in terrum pible

Región interrum pib le

in fo("actua l izarL istaArch ivosCargados")

cargarArch ivosCargados(usuario) :L ist<Arch ivo>

in fo("cargarArchivosCargados")

put("usuario" , usuario)

findA l lEnti ties(Arch ivo.class, "Archivo.findAl lByUser", true , param s) :<T > L ist<T >

arch ivos= findAl lEnti ti es(Archivo.class, "Archivo.findAl lByUser", true , param s)

GeneralException("Error al consu l ta rlos arch ivos cargados" , e ,Fi leM anager.class,"cargarArch ivosCargados", usuario)

error("Error", e )

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.

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

122

deployment PlantaeToSpecify

«DISPOSIT IVO M ÓVIL» «Servidor de ap l icaciones T om cat Versión 7 .0»

Servidor ICN

Plantae.apk PlantaeToSpecify.war

Specify

«datastore»Base de datos

«datastore»plantaetospecify

«use»

«use»

«use»

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 archivoEl 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ónAl 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écimenEn 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 usoActores Casos de uso1. Módulo de control de acceso2. Módulo de selección y cargue de archivo3. Módulo de gestión de especímenes

134

4. Módulo de selección y envío de especímenes5. Módulo de consulta y aprobación de solicitudes6. Módulo de gestión de usuarios

• Modelo estructuralDC01 Diagrama de clasesDC02 Diagrama de clases con framework

• Modelo de datosMR01 Modelo Relacional

• Modelo de interfaz de usuarioModelo de interfaz gráfica

• Modelo dinámicoDiagrama de despliegueDiagramas de secuencia

1. Módulo de control de acceso2. Módulo de selección y cargue de archivo3. Módulo de gestión de especímenes4. Módulo de selección y envío de especímenes5. Módulo de consulta y aprobación de solicitudes6. Módulo de gestión de usuarios

Máquinas de estadosME01 Máquina de estados espécimenME02 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, 201233: 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_EclipseLink_JPA38: Sommerville, Ian. “Ingeniería del software.” : Pearson education, 2011. 185-187 p.

138

DESARROLLO DE UN PROTOTIPO DE SOFTWARE PARA LA...

Documents

Transcript of DESARROLLO DE UN PROTOTIPO DE SOFTWARE PARA LA...