PROTOTIPO DE SOFTWARE PARA EL APOYO, GESTIÓN Y SEGUIMIENTO DEL CRUCE EN FELINOS DOMÉSTICOS

JOSE DANIEL CARRANZA LEGUIZAMO JOSE LEONARDO VANEGAS PRIETO

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD DE INGENIERIA

PROYECTO CURRICULAR DE INGENIERIA DE SISTEMAS BOGOTA D.C.

2017

2

PROTOTIPO DE SOFTWARE PARA EL APOYO, GESTIÓN Y SEGUIMIENTO DEL CRUCE EN FELINOS DOMÉSTICOS

JOSÉ DANIEL CARRANZA LEGUIZAMO JOSÉ LEONARDO VANEGAS PRIETO

PROYECTO DE GRADO

Directora: ALBA CONSUELO NIETO LEMUS, MSc.

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD DE INGENIERIA

PROYECTO CURRICULAR DE INGENIERIA DE SISTEMAS BOGOTA D.C.

2017

3

AGRADECIMIENTOS

Inicialmente agradecemos a la Universidad Distrital Francisco José de Caldas por ofrecernos la oportunidad de formarnos profesionalmente en sus instalaciones, guiados por su excelente planta docente que sembró en nosotros conocimientos, valores, interés por el aprendizaje y pensamiento crítico social, cultural y académico.

Agradecemos a nuestra directora de tesis, MSc. Alba Consuelo Nieto Lemus, por su interés, paciencia, orientación y conocimientos brindados durante nuestros estudios de pregrado y el desarrollo del presente proyecto.

A nuestras familias, fuente de motivación y apoyo emocional, quienes nos han

inculcado los valores que nos caracterizan, compartido e incentivado nuestra formación personal y profesional. De la misma manera a nuestras parejas Adriana y Yaneth por su paciencia, comprensión, soporte y acompañamiento.

Un agradecimiento especial para los médicos veterinarios que proporcionaron

sus conocimientos los cuales constituyeron la base del desarrollo del proyecto, en especial a la doctora, MV. MSc. Adriana Patricia López Romero.

Al señor decano Ph.D Roberto Ferro Escobar, cuyo apoyo e interés constituyeron

un factor clave para que este proyecto pudiera ser presentado en su totalidad. A nuestro jurado, MSc, Ph.D Edgar Jacinto Rincón Rojas, quien con sus valiosos

aportes hicieron este proyecto posible. A las ingenieras Nancy Yaneth Gélves García y Susana Méndez Salas, directora y asistente de programa de ingeniería de sistemas, por su apoyo mediante el ejercicio de sus labores académicas y administrativas.

Para todos ellos nuestros más sinceros agradecimientos.

4

Contenido

1. DESCRIPCIÓN DEL PROYECTO ................................................................. 13

1.1 Introducción ................................................................................................. 13

1.2. Planteamiento del problema ....................................................................... 15

1.2.1 Análisis del problema ............................................................................ 15

1.2.2 Delimitación del problema ..................................................................... 15

1.3 Formulación de la pregunta central de trabajo ............................................. 17

1.4 Objetivos ...................................................................................................... 17

1.4.1 Objetivo General ................................................................................... 17

1.4.2 Objetivos específicos ............................................................................ 17

1.5 Justificación ................................................................................................. 19

1.6. Delimitación ................................................................................................ 20

1.6.1 Alcance ................................................................................................. 20

1.6.2 Limitaciones .......................................................................................... 20

2. MARCO REFERENCIAL ................................................................................... 21

2.1. Marco teórico .............................................................................................. 21

2.1.1 Consideraciones genéticas ................................................................... 21

2.1.2 Variables de relación entre individuos ................................................... 22

2.2 Marco referencial ......................................................................................... 25

2.2.1 Aspectos de la crianza de felinos domésticos ....................................... 25

2.2.2 Software para criaderos ........................................................................ 26

2.3 Marco tecnológico ........................................................................................ 28

2.3.1 Arquitectura de múltiples capas ............................................................ 28

2.3.2 Bases de datos NoSQL ......................................................................... 31

2.3.3 Protocolo Two Phase Commit ............................................................... 35

2.3.4 APIs de persistencia .............................................................................. 36

2.4 Marco metodológico .................................................................................... 38

2.4.1 Metodología ágil Scrum ......................................................................... 38

3. DESARROLLO DEL PROYECTO. .................................................................... 40

3.1 Metodología de desarrollo - Scrum .............................................................. 40

3.1.1 Conformación del equipo ...................................................................... 40

3.1.2 Plan del proyecto................................................................................... 40

3.2 Desarrollo del Sprint 1. ................................................................................ 44

5

3.2.1 Definición de las historias de usuario .................................................... 44

3.2.2 Definición de la arquitectura .................................................................. 55

3.2.3 Especificación de la estructura de la persistencia. ................................ 57

3.2.4 Modelado de la estructura de objetos del prototipo. .............................. 60

3.2.5 Diseño del mapa de navegación y bocetos funcionales ........................ 61

3.2.6 Reuniones del equipo y retrospección del Sprint .................................. 61

3.3 Desarrollo del Sprint 2 ................................................................................. 62

3.3.1 Preparación del entorno de desarrollo. ................................................. 62

3.3.2 Implementación del sistema de autenticación de usuarios. .................. 64

3.3.3 Creación del módulo de gestión de ejemplares .................................... 64

3.3.4 Desarrollo de la funcionalidad de registro, seguimiento de ejemplares y pedigrí. ........................................................................................................... 66

3.3.5 Reuniones por Sprint y retrospección ................................................... 66

3.4 Desarrollo del Sprint 3 ................................................................................. 67

3.4.1 Creación del módulo de seguimiento de consultas médicas ................. 67

3.4.2 Reuniones del Sprint y retrospección .................................................... 67

3.5 Desarrollo del Sprint 4 ................................................................................. 68

3.5.1 Gestión de dietas como tratamiento. ..................................................... 69

3.5.2 Reuniones del Sprint y retrospección. ................................................... 69

3.6 Desarrollo del Sprint 5 ................................................................................. 70

3.6.1 Cálculo de COI y COR .......................................................................... 71

3.6.2 Búsqueda de consultas relevantes........................................................ 72

3.6.3 Búsqueda de camadas. ......................................................................... 72

3.6.4 Comparación de ejemplares para el cruce ............................................ 72

3.6.5 Registro de camadas ............................................................................ 72

3.6.6 Reuniones del Sprint y retrospección. ................................................... 73

3.7 Pruebas de la aplicación .............................................................................. 74

3.8 Resultados obtenidos a través del proceso de desarrollo............................ 75

4. CONCLUSIONES .............................................................................................. 77

5. TRABAJO FUTUROS ....................................................................................... 79

5. ANEXOS ........................................................................................................... 80

5.1 Anexo 1: Modelo de clases aplicación. ........................................................ 80

5.2 Anexo 2: Diagrama de secuencia de la implementación del Protocolo 2PC. ........................................................................................................................... 87

5.3 Anexo 3: Bocetos de interfaz gráfica. .......................................................... 88

6

5.4 Anexo 4: Pruebas funcionales de la aplicación. ......................................... 101

5.4.1 Autenticación de usuarios ................................................................... 101

5.4.2 Creación de ejemplares ...................................................................... 104

5.4.3 Búsqueda y consulta de ejemplares .................................................... 109

5.4.4 Consultas médicas de los ejemplares. ................................................ 111

5.4.5 Seguimiento nutricional ....................................................................... 119

5.4.6 Módulo de cruces ................................................................................ 121

5.4.7 Creación de camada ........................................................................... 123

Lista de referencias ............................................................................................. 126

7

Lista de ilustraciones

Figura 1 Cuadro de Punnett de transmisión de alelos de la progenie. .................. 21 Figura 2 Distribución independiente de plantas con dos características diferentes.

....................................................................................................................... 22 Figura 3 Configuración típica de una arquitectura de 3 capas .............................. 30 Figura 4 Ejemplo de arquitectura de 5 capas ........................................................ 30 Figura 5 Grafo con propiedades y etiquetas.......................................................... 32 Figura 6 Mensajes intercambiados entre el coordinador y los participantes en el

protocolo Two Phase Commit. ....................................................................... 35 Figura 7 Sandbox de IceScrum con las historias de usuario. ................................ 41 Figura 8 Captura de pantalla de IceScrum con los Sprints del proyecto. .............. 42 Figura 9 Diagrama de contexto. ............................................................................ 55 Figura 10 Arquitectura de la aplicación. ................................................................ 56 Figura 11 Diagrama del modelo Entidad Relación ................................................ 58 Figura 12 Modelo relacional. ................................................................................. 59 Figura 13 modelo de grafo etiquetado. .................................................................. 60 Figura 14 Mapa de navegación de las funcionalidades hasta el Sprint 2 .............. 66 Figura 15 Mapa de navegación de las funcionalidades implementadas hasta el

Sprint 3 ........................................................................................................... 68 Figura 16 Mapa de navegación de las funcionalidades implementadas hasta el

Sprint 4 ........................................................................................................... 70 Figura 17 Consulta para el cálculo del COI ........................................................... 71 Figura 18 Mapa de navegación con las funcionalidades implementadas hasta el

Sprint 5. .......................................................................................................... 73 Figura 19 Diagrama de clases de gestión de usuarios y sesión............................ 80 Figura 20 Diagrama de clases de la gestión de ejemplares. ................................. 81 Figura 21 Diagrama de clases de la gestión de consultas médicas. ..................... 82 Figura 22 Diagrama de clases de hallazgos y constantes fisiológicas. ................. 83 Figura 23 Diagrama de clases de diagnóstico y actividades (cirugías, exámenes y

acciones correctivas)...................................................................................... 84 Figura 24 Diagnósticos y actividades (medicaciones, dietas, vacunas,

desparasitaciones) ......................................................................................... 85 Figura 25 Diagrama de clases de la funcionalidad de resumen de cruces y camadas

....................................................................................................................... 86 Figura 26 Diagrama de secuencia del protocolo Two Phase Commit ................... 87 Figura 27 Boceto de búsqueda de ejemplares. ..................................................... 88 Figura 28 Boceto de detalle del ejemplar y del árbol genealógico. ....................... 89 Figura 29 Boceto de detalle del ejemplar con información médica. ...................... 90 Figura 30 Boceto del detalle del ejemplar e información nutricional. ..................... 91 Figura 31 Boceto del detalle del ejemplar y la información de las camadas. ........ 92 Figura 32 Boceto del formulario de consulta médica. ............................................ 93 Figura 33 Boceto de formulario de registro de hallazgos y constantes fisiológicas.

....................................................................................................................... 94 Figura 34 Boceto del formulario de diagnósticos y detalles finales de la consulta. 95

8

Figura 35 Bocetos de ventanas emergentes de actividades, cirugía, vacuna y desparasitación. ............................................................................................. 96

Figura 36 Bocetos de ventanas emergentes de registro de actividades de acción correctiva, medicación y dieta. ....................................................................... 97

Figura 37 Boceto del resumen del cruce y camadas de la hembra. ...................... 98 Figura 38 Boceto del resumen de cruce y las consultas relevantes del macho. ... 99 Figura 39 Boceto del formulario de detalle de una camada. ............................... 100 Figura 40 Página de inicio de la aplicación ......................................................... 101 Figura 41 Módulo de búsqueda de ejemplares. .................................................. 101 Figura 42 Formulario de registro de nuevo usuario. ............................................ 102 Figura 43 Registro de un nuevo usuario. ............................................................ 102 Figura 44 Registro exitoso del usuario. ............................................................... 103 Figura 45 Cierre de sesión de usuario. ............................................................... 103 Figura 46. Sesión iniciada con el usuario registrado. .......................................... 103 Figura 47 Plantilla de búsqueda de ejemplares................................................... 104 Figura 48 Botón para crear ejemplar en la plantilla de búsqueda de ejemplares 105 Figura 49 Formulario de creación de ejemplar. ................................................... 105 Figura 50 Selección del fenotipo. ........................................................................ 105 Figura 51 Botón de búsqueda de la madre. ........................................................ 106 Figura 52 Formulario de búsqueda de la madre. ................................................. 106 Figura 53 Madre y padres seleccionados. ........................................................... 107 Figura 54 Área disponible para la foto del ejemplar. ........................................... 107 Figura 55 Selección de la foto del ejemplar. ....................................................... 107 Figura 56 Foto cargada en la aplicación. ............................................................ 108 Figura 57 Carga del carnet de vacunación. ......................................................... 108 Figura 58 Formulario totalmente diligenciado para la creación del ejemplar. ...... 109 Figura 59 Confirmación del éxito de la creación del ejemplar. ............................ 109 Figura 60 Búsqueda de un ejemplar. .................................................................. 110 Figura 61 Consulta del detalle de un ejemplar. ................................................... 110 Figura 62 Árbol genealógico del ejemplar. .......................................................... 111 Figura 63 Módulo de información médica. .......................................................... 111 Figura 64 Registro de constantes fisiológicas. .................................................... 112 Figura 65 Registros de hallazgos. ....................................................................... 112 Figura 66 Diagnósticos de una consulta. ............................................................ 113 Figura 67 Función para agregar diagnóstico. ...................................................... 113 Figura 68 Formulario de creación de diagnóstico presuntivo. ............................. 113 Figura 69 Selección del diagnóstico creado. ....................................................... 114 Figura 70 Pantalla de creación de actividades. ................................................... 114 Figura 71 Creación de una desparasitación. ....................................................... 114 Figura 72 Creación de cirugía. ............................................................................ 115 Figura 73 Creación de una vacuna. .................................................................... 115 Figura 74 Listado de exámenes. ......................................................................... 116 Figura 75 Creación de una medicación. .............................................................. 116 Figura 76 Creación de una acción correctiva. ..................................................... 117 Figura 77 Área de anexos. .................................................................................. 117 Figura 78 Selección de un anexo. ....................................................................... 117 Figura 79 Selección de archivo a adjuntar como anexo. ..................................... 118

9

Figura 80 Descarga de un documento adjunto.................................................... 118 Figura 81 Consulta médica totalmente diligenciada. ........................................... 119 Figura 82 Lista de consultas médicas asociadas al ejemplar. ............................. 119 Figura 83 Creación de una dieta. ........................................................................ 120 Figura 84 Selección del alimento a usar en la dieta. ........................................... 120 Figura 85 Información nutricional del ejemplar. ................................................... 121 Figura 86 Pantalla inicial del área de cruces ....................................................... 122 Figura 87 Búsqueda de la hembra. ..................................................................... 122 Figura 88 Búsqueda del macho. .......................................................................... 122 Figura 89 Resumen de información de ejemplares para el cruce. ...................... 123 Figura 90 Consultas médicas relevantes en el macho ........................................ 123 Figura 91 Consultas médicas relevantes para la hembra. .................................. 123 Figura 92 Formulario de registro de camada....................................................... 124 Figura 93 Camada creada exitosamente. ........................................................... 124 Figura 94 Camadas de un ejemplar. ................................................................... 124 Figura 95 Botón para ver la camada del ejemplar. .............................................. 125 Ilustración 96 Camadas en común entre dos ejemplares. ................................... 125

10

Lista de tablas

Tabla 1 Integrantes del equipo de desarrollo. ....................................................... 40 Tabla 2 Lista de Sprints con sus respectivas historias técnicas y de usuario. ...... 43 Tabla 3 Herramientas y dependencias usadas en el desarrollo ............................ 63

11

Glosario

A Alelo: Es cada una de las distintas modalidades que puede presentar un gen que informa para un carácter. Cada alelo se simboliza mediante una letra. C Coeficiente de inbreeding (COI): Cantidad de inbreeding para un animal en particular, lo que indica la probabilidad de que un par de genes específicos hayan sido heredados de un antepasado común. Cuadro de Punnett: Ilustra la segregación independiente de los alelos según las leyes de Mendel, se emplea para calcular las proporciones de los diferentes genotipos. Crossbreeding: Apareamiento de ejemplares de raza pura provenientes de diferentes camadas con el fin de replicar las propiedades de los progenitores mezclando sus rasgos. E Epistasia: Cuando un gen solapa o inhibe la manifestación de otro gen que no es alelo. Se denomina epistatico al gen que se manifiesta e hipostatico al gen no alélico que se inhibe o se reprime. F Fenotipo: Las distintas características que se observan en un individuo y que son producto de la expresión del genotipo. Por ejemplo: Ojos azules, pelo negro. Flexibilidad: El esfuerzo necesario para modificar un programa que ya está en funcionamiento. G Genotipo: Conjunto de alelos que posee un organismo individual y expresa un fenotipo. Gestación: Periodo durante el cual una hembra lleva y sustenta una cría embrionaria o fetal dentro de su vientre hasta el nacimiento. H Homocigosis: Cuando los alelos de un gen responsable de un carácter determinado en un ejemplar son idénticos.

12

I Inbreeding: Apareamiento entre animales que tienen uno o más antepasados en común. Cuanto más cercano sea el parentesco, mayor será la consanguinidad en la progenie resultante. M Mantenibilidad: Modificaciones que son hechas después del lanzamiento del producto con el fin de hacer una mejora. Mutación: Alteración al azar en la secuencia del ADN la cual introduce nuevas variantes. L Linebreeding: Apareamiento entre parientes cercanos, con el propósito de concentrar las características deseables de las crías. Esta técnica se utiliza a veces en reproductores destacados, para tratar de fijar o concentrar sus genes en la progenie. Locus: Es una posición fija sobre un cromosoma donde se localiza un gen u otra secuencia de ADN. O Outbreeding: Apareamiento de ejemplares que no presentan relación de consanguinidad, por lo tanto, no presentan parientes en común. P Pedigrí: Genealogía de un animal; si se refiere al documento, es en el cual se registra la genealogía o árbol genealógico de un ejemplar, donde consta la pureza de la raza y de sus ancestros. Penetrancia: Porcentaje de individuos de un genotipo determinado que muestra realmente el fenotipo asociado a dicho genotipo. Población eficaz: Relación entre número de machos y hembras en un sistema de crianza para que demuestre que tan ideal es una población, en cuanto a la dispersión de alelos mediante cruces. T Translocación: Ocurre cuando parte de un cromosoma se transfiere a otro cromosoma

13

1. DESCRIPCIÓN DEL PROYECTO 1.1 Introducción

La domesticación de los gatos (Felis silvestris catus) está relacionada con la civilización egipcia y se presume que pudo darse cerca de los años 3000 A.C., aunque las evidencias más claras datan del año 1900 A.C. Independientemente de cuál haya sido la fecha, alrededor del año 1600 A.C ya se encontraban domesticados y eran considerados animales sagrados por esta cultura (Robinson, 2013). A través de los años esta especie se ha constituido como un animal de compañía que proporciona ayuda en el control de plagas como roedores, también se ha reportado la interacción con esta especie en tratamientos terapéuticos como en enfermedades de déficit cognitivo (Fine, 2011).

En el siglo XV se realizó la primera exposición de felinos domésticos, pero no fue

hasta el año 1868 en el Palacio de Cristal en Londres donde el interés por esta especie hizo su aparición a gran escala, ya que durante este siglo y a partir de esta fecha, se hizo evidente el interés de los criadores y de los cuidadores de mascotas por la creación de modelos de crianza, lo que posibilita contar con ejemplares de características especiales y así hacerse acreedores de premios y reconocimientos en los diferentes certámenes de juzgamiento por razas y grupos. En 1903 con la publicación del libro “Book of the cat” por Frances Simpson se comenzó a hablar de una manera más formal de sistemas de crianza, aunque aún no se tenían en cuenta nociones genéticas para su reproducción (Hartwell, 2003-2015).

Con el avance de la genética, el conocimiento de la fisiología del gato y evolución

de los sistemas de crianza, se han estandarizado ciertas razas e incluso creado nuevas a partir de cruces realizados de manera sistemática. Esto se ha logrado utilizando técnicas de cruce de inbreeding, linebreeding y crossbreeding, en las que se tienen en cuenta los niveles de consanguinidad de los ejemplares para su cruce y por lo tanto la información de su genealogía presente en el documento de pedigrí (Hartwell, 2005).

Para un buen proceso de crianza es fundamental contar con la mayor información

posible de los ejemplares a cruzar: pedigrí, información médica (vacunas, medicamentos suministrados, tratamientos, condiciones reproductivas, entre otras), información nutricional, de temperamento, y si se es posible el resultado de camadas que hayan presentado con anterioridad (McMinn, 2009). Del correcto uso de esta información depende la vida de los animales inmersos en el proceso de crianza, llegando en muchos casos a producir un sin número de resultados no deseados como fenotipos no esperados, malformaciones, enfermedades y muertes.

En un modelo de crianza al incrementarse el número de ejemplares, cruces y

camadas, aumenta significativamente la complejidad de la información, generando desorden y pérdida de datos. Existen diferentes productos de software en mercado, la mayor parte con licencias privativas, que permiten realizar diversas tareas en cuanto al manejo de las reglas de negocio de un criadero como el registro,

14

seguimiento de sus ejemplares y predicciones de cruces, las cuales se limitan a entregar la información de coeficiente de inbreeding (COI), de relación (COR), pedigrí asociado al cruce y en algunos casos los posibles fenotipos resultantes (Zooeasy, 2017; Breedmate, 2012; Tenset, 2014). Esta información resulta incompleta al momento de tomar una decisión sobre si realizar un cruce o no, ya que no se deben pasar por alto aspectos médicos e históricos del comportamiento de los ejemplares a cruzar, pues dicho conocimiento proporciona al criador una herramienta que asista el proceso para la toma de decisiones, y una proyección aproximada de las posibles condiciones de las crías resultantes del cruce (McMinn, 2009).

Desde el ámbito académico se propone desarrollar un prototipo de software que

implemente los servicios de seguimiento de genealogía de los ejemplares de un criadero de felinos domésticos, sus características individuales, dieta, historial médico y reproductivo, que constituya una herramienta que permita estimar los posibles resultados de un cruce teniendo en cuenta la información más relevante, con el fin de evitar cruzas cuyas crías presentan alteraciones fisiológicas debido al grado de consanguinidad o a patologías congénitas.

15

1.2. Planteamiento del problema

1.2.1 Análisis del problema Durante el proceso de crianza es común que se presenten alteraciones en la

fisiología del animal debido al grado de consanguinidad, patologías congénitas, mutaciones y factores externos, entre otros (McMinn, 2009). Debido a esto se pretende buscar la manera de minimizar su manifestación, criando ejemplares con un riesgo menor de padecer dichas patologías y con características acordes a su raza reduciendo así la mortalidad.

El correcto registro y seguimiento de la información de cada ejemplar, es una

herramienta de apoyo fundamental para el control médico y la posterior toma de decisiones para la cruza (Gough y Thomas, 2004; Niels, 1991). Este registro deberá contar con el historial clínico, reproductivo y nutricional del espécimen, así como con su caracterización fenotípica y de temperamento. Por medio de la lectura de la información anteriormente registrada, el criador podrá estimar de manera teórica el resultado de la cruza y la camada resultante, disminuyendo la posibilidad de obtener crías con características no deseadas.

Para desarrollar el presente proyecto se utilizaron como datos de entrada la

información contenida en el certificado de pedigrí, la información genealógica perteneciente a cada ejemplar, historial clínico, nutricional, reproductivo y de temperamento. La mayoría de criadores al no contar con la herramienta apropiada no llevan un seguimiento adecuado de esta información motivo por el cual se hizo uso de datos de prueba generados a partir de la experiencia y supervisión de un médico veterinario asesor.

1.2.2 Delimitación del problema En el estudio realizado para identificar los módulos y funcionalidades que se

necesitan en el prototipo a desarrollar, se han reconocido como principales tareas: el registro del ejemplar con su caracterización, el seguimiento al pedigrí, el historial clínico, la dieta e información nutricional, el cálculo de los coeficientes de inbreeding (COI) y relación (COR). A continuación, se describen las funcionalidades con base en lo reportado en la literatura (McMinn, 2009; Niels 1991) y en entrevistas con médicos veterinarios y criadores (A. López, comunicación personal, 11 de noviembre de 2015; J. Riveros, comunicación personal, 15 de noviembre de 2015).

Registro de datos básicos de los ejemplares: Esta funcionalidad requiere del

registro de datos de los ejemplares como: identificación, fenotipo y genealogía. Estos están presentes en el documento de pedigrí y constituyen la base para la obtención del coeficiente de inbreeding (COI), de relación (COR), la observación y el seguimiento de las características y condiciones encontradas en su línea genética.

16

Adicionalmente, es necesario contar con el registro de la información de las

camadas y la respectiva asociación entre los ejemplares; de igual manera se requiere el registro de natalidad, mortalidad y otras observaciones relevantes del parto.

Módulo de consultas clínicas: Este módulo es de relevancia primordial ya que

contiene una recopilación de condiciones médicas, novedades, tratamiento y medicamentos suministrados al ejemplar. Los datos más relevantes de la historia clínica deben ser mostrados para la contextualización y análisis por parte del criador, de esta forma servirá como una herramienta para la toma de decisiones en relación al cruce y evaluar las posibles condiciones resultantes.

El historial de vacunación permite conocer el estado inmunológico de los

ejemplares; esta información es relevante ya que tanto el macho como la hembra a cruzar deberán tener las mismas vacunas para evitar la posible transmisión de enfermedades en las crías y asegurar el paso de anticuerpos maternos.

Es necesario contar con un módulo enfocado a la información reproductiva en

particular de la hembra, conocer su periodo de gestación y en lo posible establecer los niveles de progesterona, además debe tener vínculo con información relativa al parto y de los animales resultantes del cruce, para inferir las condiciones reproductivas de las de las madres.

Otro aspecto importante ligado al historial clínico es la capacidad de

determinar patrones o anomalías médicas en caso presentarse tasas de mortalidad sin explicación aparente, por lo cual es relevante la inclusión de la información arrojada por las necropsias en caso de presentarse animales nonatos o la muerte de una ejemplar.

Módulo nutricional: Para el adecuado bienestar de los ejemplares inmersos en

el proceso de crianza es necesario llevar un seguimiento y control nutricional, ya que se ha encontrado que la presencia o ausencia de ciertos nutrientes en la dieta de una hembra gestante podrá generar condiciones no deseadas como la reabsorción fetal, abortos y otras patologías neonatales (malformaciones, desnutrición, deficiencias inmunológicas, entre otras). En general es fundamental una alimentación adecuada para el correcto desarrollo del feto y el fortalecimiento del sistema inmunológico, así como para mantener la salud de la hembra gestante.

El seguimiento de la nutrición del animal debe estar acompañado del registro

de comportamiento del peso, enfatizando en las primeras semanas de la cría, ya que se asocia un considerable nivel de mortalidad en las crías con bajo peso, lo cual en ocasiones está relacionado con deficiencias en la alimentación y condiciones médicas no tratadas.

17

Resumen de características de la pareja a cruzar: reúne la información más relevante enfocada al aspecto reproductivo de los dos ejemplares. Adicionalmente a ello, cálculos de coeficiente de inbreeding (COI), de relación (COR), historial de camadas previas de los ejemplares, consultas médicas más relevantes y tratamientos activos.

Los datos más relevantes que se encontraron para mostrar en el resumen

son: Condiciones médicas latentes en el ejemplar. Fenotipo (color de ojos, patrón y color de pelaje). Vacunas administradas. Información de tratamientos. Camadas previas con sus observaciones particulares (natalidad,

mortalidad, parto asistido, cesárea o parto natural). 1.3 Formulación de la pregunta central de trabajo

¿Cómo desarrollar un prototipo de software web soportado en una base de datos

NoSQL para el apoyo, gestión y seguimiento del cruce de ejemplares de felinos domésticos, considerando grado de consanguinidad, historial clínico y de antecedentes de cruces previos, de manera que ayude a reducir el número de malformaciones y transmisión de enfermedades entre los miembros de la especie? 1.4 Objetivos

1.4.1 Objetivo General Desarrollar un prototipo de software web, para el seguimiento y control de cruces

de felinos domésticos, que constituya una base para la toma de decisiones en este proceso, teniendo en cuenta el pedigrí, historial clínico, nutricional y reproductivo de los ejemplares.

1.4.2 Objetivos específicos

Especificar los requerimientos funcionales y no funcionales para la gestión de la información de cruces de felinos domésticos, a partir de entrevistas con veterinarios que participan en el proyecto y de la revisión de la literatura.

Elaborar el modelo de arquitectura de la aplicación de manera que permita el desarrollo incremental de las funcionalidades requeridas: seguimiento de historial clínico, nutricional, condiciones médicas y reproductivas de los ejemplares.

Definir el esquema de datos no relacional para modelar los atributos y las relaciones genealógicas entre los miembros de la especie y relacional para los demás datos asociados con la historia clínica, nutricional y reproductiva.

18

Implementar los módulos funcionales que hacen parte de la aplicación web para soportar los requerimientos definidos.

Poblar la base de datos con información de prueba para validar las funcionalidades del prototipo.

Validar el prototipo en colaboración de criadores y médicos veterinarios para comprobar la utilidad de la herramienta como apoyo al proceso de cruce; hacer los ajustes requeridos.

19

1.5 Justificación

En los criaderos los cruces son realizados por criadores con nociones básicas y a veces intuitivas sobre esta práctica, no por genetistas, es por ello que usualmente se cometen errores al momento de realizarlos. Estos errores suelen hacerse visibles en estadios avanzados de la crianza (años) con la consecuente pérdida de líneas genéticas completas y un número considerable de ejemplares ven comprometida su salud y vida debido a estos errores.

En cifras del mes de enero de 2017 en Colombia existen alrededor de 80 criaderos de felinos domésticos, 52 de ellos se encuentran registrados ante organizaciones internacionales que agremian la práctica de la crianza (TICA, 2017; ACFEC, 2017), dichos criaderos cuentan con ejemplares de en promedio 3 razas diferentes, siendo la más común de ellas la raza Persa, con presencia en 26 de los criaderos registrados.

Es posible encontrar mediante buscadores en Internet una gran cantidad de

resultados relacionados con cientos de ejemplares de raza que son ofrecidos a través de la red, lo que demuestra el alto grado de informalidad que puede conllevar esta práctica, a la que se asocian por lo menos 1554 felinos de los criaderos registrados, aproximar una cifra de los ejemplares usados por practicantes informales es difícil de calcular. El personal inmerso en esta práctica, por criadero, es en promedio de 3 a 4 personas, involucrando en total a más de 800 personas entre criadores formales e informales. En el año 2012 fueron comercializados alrededor de 12.300 animales provenientes de la práctica informal (Animanaturalis, 2014), de ellos una gran proporción corresponde a felinos domésticos, los cuales llegan a presentar condiciones de salud que ponen en riesgo sus vidas (Maldonado, 2012; Escalante, 2015).

El presente trabajo propone el desarrollo de un prototipo para la gestión de información que apoye el proceso de cruza de felinos domésticos, que proporcione al criador información relevante de los ejemplares, como son el coeficiente de inbreeding (COI), coeficiente de relación (COR), el pedigrí de ambos animales, su historial clínico, vacunaciones, periodo gestacional de la hembra, resultados de cruces previos y un valor sobre la efectividad de la población relativo a las razas inmersas en el proceso y uno en general.

Se espera que con la ayuda de esta herramienta el criador cuente con

información relevante para la toma de decisiones con respecto a los cruces, de manera que se realicen sin poner en riesgo la salud de los ejemplares centrando la atención en el aspecto clínico y no en métricas que busquen que el ejemplar cumpla con las características de una raza en particular.

20

1.6. Delimitación

1.6.1 Alcance Este proyecto se enfoca al desarrollo de un prototipo de software de gestión de

información clínica y reproductiva, para el cruce de felinos domésticos, basándose en una arquitectura de múltiples capas y sobre sistemas de bases de datos relacional y otro NoSQL, utilizando la metodología de desarrollo ágil Scrum.

La aplicación está en la capacidad de almacenar la caracterización, pedigrí,

historial clínico, reproductivo, nutricional y de resultados de las camadas de los animales inmersos en el proceso de crianza y permite realizar un resumen que contiene la información sobre los elementos más importantes a tener en cuenta para realizar el cruce.

No se pretende hacer una herramienta de simulación o análisis genético de los

posibles resultados de una camada, ya que esto supone la utilización de conceptos que no son del alcance del proyecto. No se tuvieron en cuenta métricas morfológicas que caracterizan una raza en particular, ya que tampoco es el interés del desarrollo priorizar la crianza de razas sobre el bienestar del ejemplar.

La aplicación no tiene en cuenta módulos de reglas de negocio del criadero ni de

seguimiento financiero, ya que el desarrollo no se hace con el ánimo de generar lucro por medio de esta actividad, sino de proporcionar una herramienta que incentive el uso de la información recolectada para que se hagan cruces de una manera más apropiada.

1.6.2 Limitaciones

Dado que en Colombia no existe legislación para controlar el cuidado y el cruce de los felinos domésticos ni regulaciones sobre los criaderos por parte de algún ministerio, la información que se va a guardar y el seguimiento que se le hará a los ejemplares dependerá de los veterinarios y los criadores interesados en el desarrollo del proyecto.

No se hará adquisición licencias de uso privativo. Al tratarse de una herramienta sin ánimo de lucro se utilizará software libre.

No se tendrá en cuenta el cálculo de patrones y colores de pelaje ya que al no contar con la información del genotipo del ejemplar algunas de las características debido a su carácter epistático son enmascaradas y el nivel de exactitud del cálculo disminuye significativamente (Gould, 1996).

21

2. MARCO REFERENCIAL 2.1. Marco teórico

2.1.1 Consideraciones genéticas Para describir el modo en el que las características son heredadas entre

ejemplares de padres a hijos es necesario hablar de las leyes de Mendel, las cuales se enuncian a continuación:

Ley de la segregación:

Esta ley plantea que, en la reproducción, un solo alelo de un par se transmite a

cada gameto (células sexuales) lo que sucede de manera aleatoria, es decir, cada progenitor transmite parte de sus características a su progenie de manera aleatoria (Khanna, 2010). En el cuadro de Punnett de la figura 1 se muestra de manera sencilla cómo funciona esta ley.

Figura 1 Cuadro de Punnett de transmisión de alelos de la progenie.

Recuperado de Biology: Concepts and Applications Gene segregation pp. 192. Copyright 2010 por Cengage Learning.

El estado de los alelos del padre es PP y de la madre pp, cada uno de estos transmite de manera aleatoria su material genético. Es posible observar 4 posibles combinaciones que podrían manifestarse en la progenie que en este caso son todas iguales (Pp).

Ley de la segregación independiente: Plantea que diferentes rasgos son segregados independientemente el uno del

otro y al igual que en la ley de la segregación esto se hace de manera aleatoria (Khanna, 2010). En el experimento inicial de Mendel se buscó reproducir plantas que contenían dos rasgos diferentes, de color y textura, en la figura 2 se muestra el principio de esta experiencia y sus resultados.

22

Figura 2 Distribución independiente de plantas con dos características diferentes.

Recuperado de Mašková, J. The law of independent assortment. Copyright 2011-2014 por Wikilectures.eu.

Un método gráfico utilizado para encontrar las posibles soluciones resultantes de un cruce, utilizando las leyes de Mendel anteriormente mencionadas, es el cuadro de Punnett (Neale y Cardon, 2013), que consiste en una matriz n x n, en la cual el orden se incrementa cada vez que se añade un rasgo nuevo. Su utilización consiste en ubicar del lado izquierdo la información del estado de los alelos del macho, y en el lado superior los de la hembra y se procede a realizar el emparejamiento de cada uno de ellos tal como muestra en las figuras 1 y 2. Finalmente toman todos aquellos resultados en común y se relaciona la proporción que podrían ocupar cada uno en la progenie.

2.1.2 Variables de relación entre individuos La palabra consanguinidad deriva de una noción errónea de que la sangre era la

base de la herencia (Cavalli-Sforza, Moroni y Zei, 2013). La consanguinidad tiene un componente social y genético que se refiere al cruce y/o reproducción entre dos individuos estrechamente relacionados (ancestros comunes). Entre mayor el grado de relación, mayor es la proporción de genes compartidos entre ellos, lo que aumenta el riesgo de desórdenes autosómicos (cromosomas no sexuales) debido al mayor riesgo de homocigosis en la descendencia (Coleman y Tsongalis, 2009).

Es posible realizar el cálculo del coeficiente de inbreeding (COI) y relación (COR),

que muestra el grado de parentesco de los ejemplares, y proporciona una idea de qué tipo de cruce se asemeja (inbreeding, linebreeding o crossbreeding).

23

El inbreeding hace relación al emparejamiento de individuos con un mayor grado de relación que la población promedio (Tave, 1999), es decir, entre aquellos que contienen material genético idéntico debido a que descienden de ancestros comunes cercanos (Fox, Roff y Fairbairn, 2001). Por otro lado, el outbreeding es lo contrario del inbreeding, es el emparejamiento de ejemplares con un grado de relación menor que la población promedio (Thornhill, 1993). Finalmente, el linebreeding, consiste en el cruce de un ejemplar que posee características particulares, con múltiples parejas para conservar sus rasgos en una línea genética (Thiagarajan, 2014).

Medidas de relación Nacen como resultado del trabajo del genetista estadounidense Sewall Wright,

en 1921 que descubrió la manera de realizar el cálculo de lo que él denominó el coeficiente de inbreeding (COI) (Snustad y Simmons, 2015). Lo que expresa es la probabilidad de que el par de alelos de un locus en un individuo sean idénticos debido a que desciende de un ancestro cercano en común; dicho valor varía entre 0 y 1 (Wilson, 2000). Para realizar el cálculo es necesario tener la información del pedigrí de los ejemplares, entre mayor sea más acertado será su valor. Dicho cálculo se realiza mediante la ecuación 1 (Snustad y Simmons, 2015; Frankham, Ballou y Briscoe, 2010; Wilson, 2000).

𝑓 =∑(0,5)𝑛(1 + 𝑓𝑐𝑎)

Ecuación 1. Cálculo del coeficiente de inbreeding.

Siendo: ƒ : Coeficiente de inbreeding (COI) de un individuo n : Número de individuos en un camino desde un pariente progenitor hasta un

ancestro común y de vuelta al otro progenitor. 𝑓𝑐𝑎: Coeficiente de inbreeding (COI) del ancestro.

Dentro de los usos más importantes del coeficiente de inbreeding (COI) se

encuentran: el análisis sobre la presencia o incremento de desórdenes recesivos originados por cruces con cierto grado de consanguinidad y la medición de la declinación de un fenotipo complejo (Snustad y Simmons, 2015), lo que es usado para producir las características morfométricas de una raza en particular. Gracias al cálculo y seguimiento es posible controlar efectos tanto benéficos como nocivos en los ejemplares de las camadas. La tasa del coeficiente de inbreeding (COI) es inversamente proporcional al tamaño de la población (Frankham et al., 2000).

Otra de las medidas de relación a tener en cuenta es la del coeficiente de kinship,

el cual es la probabilidad de que un par de alelos extraídos de un mismo locus de dos individuos puedan ser dos copias idénticas provenientes de un ancestro común (Snustad y Simmons, 2015). En el cálculo de este valor se utiliza la misma fórmula que para el coeficiente de inbreeding (COI), a diferencia de que se realiza sobre un

24

ejemplar que hipotéticamente llegaría a ser resultado del cruce de dos ejemplares, es decir una cría.

La diferencia entre coeficiente de inbreeding (COI) y de kinship radica en que, el

coeficiente de inbreeding (COI) es la probabilidad de que dos alelos en el locus de un ejemplar sean idénticos por descendencia, mientras que el coeficiente de kinship es la probabilidad de que un par de alelos extraídos de manera aleatoria del mismo locus de dos individuos sean idénticos por descendencia (Snustad y Simmons, 2015).

En 1922 Sewall Wright nuevamente planteó un nuevo valor para determinar la fracción de genes que dos ejemplares emparentados comparten, conocido como coeficiente de relación (Coefficient of relationship COR) (Snustad y Simmons, 2015). Este valor es calculado mediante el uso del coeficiente de inbreeding, su cálculo básicamente consiste en multiplicar el coeficientes de inbreeding de una hipotética camada por 2 como se muestra en la ecuación 2.

.

𝑟𝑖𝑗 = 2𝑓𝑖𝑗 Ecuación 2. Cálculo del coeficiente de relación.

Siendo: 𝑟𝑖𝑗: Fracción de genes compartidos. 𝑓𝑖 𝑓𝑗: Coeficientes de inbreeding para i y j. El número de la eficacia de la población es un indicador de la sanidad y

estabilidad genética de una población. Da cuenta de la diversidad alélica presente en los ejemplares disponibles para dar crías, entre mayor sea este número, mayor es la probabilidad de contar con una población más sana (Wright, 1930). Este valor se calcula teniendo en cuenta a toda la población activa en un sistema reproductivo, como muestra la ecuación 3 (Snustad y Simmons, 2015).

𝑁𝑒 =4(𝑁𝑓𝑁𝑚)

𝑁𝑓+𝑁𝑚

Ecuación 3. Cálculo de la eficacia de la población Siendo: 𝑁𝑒 : Número de eficacia de la población. 𝑁𝑚 : Número de machos. 𝑁𝑓 : Número de hembras. Una de las funcionalidades clave del prototipo es el cálculo del COI, COR y la

eficacia de la población. Si bien el número de generaciones para la obtención de estos dos primeros coeficientes debería ser la mayor cantidad posible, teniendo en cuenta que en los criaderos consultados solo consideran hasta la segunda generación para sus estimaciones (comunicación verbal. López, 2017), en el prototipo se utilizará hasta la décima; ya que entre más generaciones se tomen en consideración, el tiempo de ejecución será mayor (The Institute of Canine Biology, 2012-2017).

25

2.2 Marco referencial

2.2.1 Aspectos de la crianza de felinos domésticos El interés inicial de la crianza de felinos domésticos se basó en criar ejemplares

con características fenotípicas particulares (rasgos físicos) para ser presentados en diferentes exposiciones, en las cuales sus cuidadores eran acreedores a premios y reconocimientos. Al presentarse diferentes ejemplares con características comunes, se realizó la estandarización de ciertos parámetros bajo el concepto de razas, siendo el interés principal que el resultado de la crianza cumpliera en una mayor proporción dichos lineamientos (Hartwell, 2003-2015).

Al concentrar los esfuerzos en obtener rasgos físicos particulares, la salud de los

especímenes se ve relegada, lo cual ocasiona la aparición de condiciones médicas no deseadas ya que el proceso de crianza no se realiza teniendo en cuenta estas condiciones, que intervienen de manera directa o indirecta en su resultado. Algunos factores a tener en cuenta son mencionados a continuación:

Nutricional: La alimentación inadecuada en los ejemplares, en especial en

las hembras y durante el periodo gestacional, puede producir enfermedades y crías débiles. Uno de los problemas nutricionales más serios es la deficiencia de taurina (aminoácido), situación que incrementa la reabsorción fetal, abortos, muerte de las crías y problemas cardiacos (Niels, 1991). La mayor manifestación de esta deficiencia es la enfermedad conocida como cardiomiopatía congestiva, la cual compromete la vida del animal (Ettinger y Feldman, 2009).

Es de suma importancia que los ejemplares reciban la alimentación

adecuada dado su nivel de actividad, edad y condiciones médicas, ya que su deficiencia es un factor de riesgo para la salud del animal y sus futuras crías.

Clínico: Es importante conocer el estado de salud de cada uno de los ejemplares, para evitar la propagación de enfermedades entre los individuos del sistema de crianza y a las futuras crías.

Si al momento de realizar un cruce, uno de los padres presenta alguna

condición médica particular, esta puede ser transmitida a su descendencia, esta probabilidad se incrementa si ambos padres cuentan con dicha condición, aumentando el riesgo cuando hay un alto grado de consanguinidad.

Es posible categorizar las condiciones clínicas según el sistema que se ve

afectado de la siguiente manera: cardiovasculares, dermatológicas, endocrinas, gastrointestinales, inmunológicas, musculo esqueléticas, neurológicas, oculares, renales y urinarias, reproductivas y finalmente

26

respiratorias (Gough, 2004). Así como por agente etiológico: infecciosas, neoplásicas.

Reproductivo: Si bien hace parte de una condición clínica del animal, no necesariamente se asocia a algún tipo de afección en este caso, sino a su estado e historial reproductivo. Información que ayudará a determinar el momento adecuado para realizar el cruce entre estos ejemplares.

Consanguinidad: La consanguinidad tiene un papel vital al momento de realizar el cruce, ya que dependiendo del parentesco que poseen los ejemplares, se debe tener en cuenta ciertas consideraciones especiales. Básicamente entre más parentesco exista, al cruzarlos es posible aumentar la probabilidad de aparición de características deseadas o no deseadas. Cuando es el caso de outbreeding, es posible que la “pureza” de la raza se vea comprometida, pero esto puede ayudar a disminuir características no deseadas de esa línea genética.

2.2.2 Software para criaderos

Teniendo en cuenta los factores anteriormente mencionados, es posible

encontrar un número considerable de aplicaciones que, ya sea en versiones standalone o web, son en su mayoría de licencia privativa. Casi todas hacen énfasis en la gestión del documento de pedigrí, y en cuanto a los cruces la mayoría solo tiene en cuenta el coeficiente de inbreeding (COI) y coeficiente de relación (COR) (Breedmate, 2012). Existen otras más completas como Breeders Assistant (Tenset, 1996-2016) que realizan la gestión genealógica, coeficientes de consanguinidad, predicción de colores y patrones de pelaje teniendo en cuenta ancestros (versión standalone). Aunque algunas cuentan con módulos clínicos, ninguno tiene en cuenta esta información al momento de considerar un cruce, a pesar de que la información clínica, nutricional y reproductiva de los ejemplares, es de suma importancia para evitar posibles complicaciones en las camadas y resultados anómalos en las crías resultantes.

A continuación 3 de las aplicaciones más completas que se pudieron encontrar en la web, y que ofrecían mayor información sobre su funcionamiento:

Zooeasy® Zooeasy® es un software para criaderos que cuenta con versiones standalone y

web disponible en 6 diferentes idiomas. La lista de características es extensa, incluye tanto de manejo de pedigrí, historia clínica, de shows, lista de contactos y un módulo financiero para el criadero (Zooeasy, 2017). En cuanto a la funcionalidad de cruces, dice contar con una herramienta de búsqueda de parejas, pero no se especifica si para esta función se hace uso del fenotipo, genotipo o que parámetros tiene en cuenta para realizar esta operación.

27

Esta aplicación no está diseñada para una especie en particular, es posible manejar a través de ella por lo menos 20 especies de animales diferentes, cuenta diferentes roles de usuario y su respectivo módulo de administración. Aunque tiene un registro de visitas de veterinarios no cuenta con un sistema robusto de información de condiciones médicas,

El módulo de cruces de esta aplicación se limita a mostrar el árbol genealógico

de ambos ejemplares, su coeficiente de inbreeding, relación (COR) y un cálculo de los posibles colores resultantes de la camada.

Breeders Assistant®

Hace parte de un grupo de aplicaciones que desarrolla la empresa Tenset®,

todas enfocadas al manejo de pedigrí y de sistemas de crianza. Está en particular es la más completa y cuenta con 3 diferentes versiones, todas ellas standalone para Mac y Windows de uso bajo licencia privada. Esta aplicación permite almacenar información sobre los ejemplares, contactos, camadas, registros de visitas médicas, vacunas y finanzas del criadero entre otras opciones (Tenset, 1996-2014).

En cuanto a su funcionalidad para cruces, en sus versiones profesional y

comercial cuenta con un módulo llamado advanced genetics, a través del cual es posible realizar una predicción de colores de pelaje teniendo en cuenta ancestros, por lo tanto, estados de genes recesivos, su frecuencia y probabilidad de aparición. No manifiestan hacer uso de la información clínica, reproductiva o nutricional como datos asociados al cruce.

Pedigree Explorer® Es una aplicación disponible únicamente para Windows, realiza especial énfasis

en la gestión del pedigrí, algo que le hace diferente de muchas otras aplicaciones es que cuenta con lenguaje de scripting propio. Para manejo de cruces maneja un planificador, en donde se muestran COI y COR, los cuales pueden ser almacenados (Breedmate, 2012).

Cuenta con un registro básico de historial médico de los ejemplares, aunque

únicamente para perros, tiene la opción de registro de camadas, asociadas a sus progenitores, número de machos, hembras, aquellos que murieron, que fueron vendidos, fecha de notificación, si fue asistido el parto, peso promedio de nacimiento, lugar y dieta. Ofrece la posibilidad de registrar historial de vacunas con algunos datos básicos, es posible llevar el registro de celos, pero no especifican cómo hacen la gestión. Para el planificador de cruce únicamente se tiene en cuenta el grado de consanguinidad de los ejemplares.

El prototipo al que hace relación el actual documento, se desarrolló en una

arquitectura de múltiples capas con orientación web. Cuenta con información reproductiva relacionada con parejas y resultados de camadas previas. Con

28

respecto al seguimiento nutricional es posible especificar la alimentación suministrada, información que está disponible en el gráfico de seguimiento de peso, además de adjuntar notas relacionadas con los efectos del alimento en el ejemplar. Permite el registro de consultas médicas que reúnen información de hallazgos y constantes fisiológicas, acciones preventivas, tratamientos administrados y controles con el veterinario. La funcionalidad de cruces, a diferencia de otras aplicaciones, facilita que el usuario cuente con un resumen de la información más relevante de ambos ejemplares (vacunas, condiciones médicas, reproductivas, tratamientos y resultados de camadas previas), además de mostrar los datos básicos de genealogía, coeficientes de inbreeding (COI), relación (COR) y efectividad de la población. 2.3 Marco tecnológico

En la siguiente sección se trata temas relacionados con el modelo de arquitectura de software de múltiples capas con el que desarrolló el prototipo, las estructuras de persistencia implementadas en el proyecto; las cuales pertenecen a un modelo heterogéneo que incluye el uso de una base de datos relacional y una orientada a grafos, los API de persistencia que se utilizaron y finalmente, el funcionamiento del protocolo Two Phase Commit (Philip y Newcomer, 2009) para el manejo de transacciones distribuidas.

2.3.1 Arquitectura de múltiples capas

Según la ISO/IEC/IEEE 42010 (2015) la cual afirma que “La arquitectura es

aquella que se refiere a los conceptos fundamentales o propiedades de un sistema en su ambiente, presentes en sus elementos, relaciones y en los principios de su diseño y evolución”, haciéndola esencial para el sistema.

Su relevancia nace de la necesidad de crear software de calidad que esté en la

capacidad de lidiar con la complejidad inherente al problema que busca solucionar, desde el comienzo de su desarrollo hasta el fin de su vida útil (Arias y Durango, 2016). Por este motivo, la arquitectura de software ha sido un tema discutido por múltiples profesionales desde su primera mención en el año de 1970 en un informe técnico titulado Software Engineering Techniques (Buxton y Randell, 1970); a través de los años han surgido y evolucionado diferentes arquitecturas y elementos para su descripción.

La arquitectura de software en múltiples capas tiene como objetivo la separación

de unidades de software con una funcionalidad delimitada que puede ser separada físicamente de otras, de manera que pueda ser desarrollada, mantenida o reemplazada independientemente sin afectar otras capas (Fowler et al., 2002; Sommerville, 2005). De la correcta elección de las capas dependerá su adecuada evolución y las cualidades del producto que componen.

29

Algunas de las principales ventajas que ofrece esta arquitectura son:

Mantenibilidad y flexibilidad al soportar el desarrollo incremental, ya que permite que cada capa sea desarrollada de manera independiente, proporcionando servicios a medida que estén disponibles, su bajo nivel de acoplamiento ofrece la posibilidad de reemplazar capas por otras equivalentes, mientras se mantengan protocolos de comunicación compatibles con las capas adyacentes (Sommerville, 2005; Thakur, 2008).

Escalabilidad, ya que la separación en diferentes capas permite que la aplicación pueda crecer para recibir más carga, por ejemplo, replicando componentes de la aplicación en diferentes servidores (Grove, 2009; Jiménez, Patiño, Kemme, Pérez y Serrano, 2009) lo que permite mejorar la disponibilidad de los servicios ofrecidos por la aplicación (Menascé y Fernandes, 2000).

Dependiendo la elección de las capas otras ventajas podrían obtenerse, como la

interoperabilidad y compatibilidad con otras aplicaciones o segmentos de ellas (Thakur, 2008), la seguridad estableciendo un servicio de firewall en una de las capas, lo que restringe el acceso a los servidores de la aplicación y bases de datos (Menascé y Fernandes, 2000), incluso si la aplicación presenta un alto grado de modularidad, se podría hacer reúso de partes de ella en aplicaciones similares lo que ahorraría costos y tiempo de desarrollo (Thakur, 2008).

Con respecto al rendimiento ofrecido por una arquitectura de múltiples capas, es

un aspecto que se puede presentar a favor o en contra de la aplicación. Debido a la estructura, un servicio solicitado desde una capa superior puede tener que ser interpretado varias veces en diferentes capas al ser procesado (Sommerville, 2005) e incluso en redes muy congestionadas, la comunicación entre los dispositivos físicos que despliegan las capas puede verse comprometida, condiciones que disminuye el tiempo de respuesta de la aplicación. Por otro lado, la especialización de los servidores según su tarea y la delegación de responsabilidades a otros dispositivos, mejora el rendimiento de la aplicación, lo que es más notable en tareas más extensas o complicadas (Thakur, 2008; Grove, 2009).

La división más común y recomendada para aplicaciones medianas es la de 3

capas (Figura 3), la cual consta de una capa de presentación que es donde el usuario interactúa directamente, ya que mediante su interfaz provee acceso a los servicios, la capa de base de datos que los almacena y protege contra fallos e inconsistencias y la de lógica de negocios, que contiene las reglas para manejar los datos y la lógica del negocio, funcionando como intermediaria entre las otras dos capas (Liu, 2011).

30

Figura 3 Configuración típica de una arquitectura de 3 capas

En el cliente solo se concentra la parte gráfica de la aplicación, la lógica de negocios y el manejo de datos se encuentran separados. Recuperado de Web Based Application Development. Typical two-tier architecture. Copyright 2010 por Jones and Bartlett Publishers, LCC.

Para aplicaciones de tamaño mediano a empresarial, es recomendable adoptar

una arquitectura que posea un número mayor de capas, por ejemplo, una arquitectura de 4 y 5 capas puede tomar diferentes configuraciones según las necesidades de la aplicación a desarrollar, ya sea haciendo énfasis en aumentar la modularidad en la capa de presentación, lógica de negocios o en el acceso a los datos (Thakur, 2008). Cabe señalar que, a mayor número de capas la complejidad del desarrollo aumenta y serán necesarios mayores recursos y esfuerzos debido a que se necesitará mayor capacidad de cómputo y de red para que la aplicación sea desplegada (Mukhar y Zelenak, 2006).

Figura 4 Ejemplo de arquitectura de 5 capas

Este ejemplo hace énfasis en la lógica de negocios, separándola en 3 capas distintas con sus funcionalidades delimitadas. Recuperado de Beginning Java EE 5 From Novice to Professional. N-tier Architecture. Copyright © 2006 by Kevin Mukhar and Chris Zelenak, with James L. Weaver and Jim Crume

31

Es importante tener en cuenta que una arquitectura de múltiples capas no exige que cada una de las capas se ejecute en un ordenador separado, es posible ejecutar cada una de ellas en el mismo. Su mayor ventaja reside en que cada una de las capas cuente con el nivel de modularidad suficiente para poder separar cada un ordenador diferente de ser requerido (Mukhar y Zelenak, 2006).

Con el presente trabajo se construyó un prototipo web sobre una arquitectura en

tres capas (presentación, lógica y persistencia) que facilita la modularidad y escalabilidad del producto. La capa de persistencia esta soportada en una base de datos NoSQL que facilita el modelado de los atributos y las relaciones de consanguinidad entre los miembros de la especie; adicionalmente cuenta con una base de datos relacional que simplifica la implementación de las funcionalidades de gestión de las consultas médicas y tratamientos asociados a los ejemplares.

2.3.2 Bases de datos NoSQL Desde los primeros años de utilización de sistemas de almacenamiento de datos,

la necesidad ha sido creciente en diferentes aspectos, capacidad, rendimiento, seguridad, escalabilidad, por solo nombrar algunos, y en respuesta a estos requerimientos, han surgido diferentes maneras de satisfacerlos, desarrollando nuevas tecnologías ya sea de software o hardware.

Uno de los modelos más ampliamente usados ha sido el relacional, ya que reúne

gran cantidad de características deseables en un sistema de base de datos, pero dado el enorme crecimiento y demanda a los sistemas informáticos que han considerado el surgimiento del internet, con la aparición de nuevos conceptos como por ejemplo las redes sociales y el Big Data, las empresas que trabajan en estos segmentos se han visto en la necesidad de encontrar nuevas maneras de satisfacer los requerimientos que implican estas nuevas tecnologías (McKnight, 2014).

Ya que los costos asociados a escalar el modelo relacional resultan muy elevados

se recurren a tecnologías NoSQL lo que para algunos significa “Not Only SQL”, en donde las más comunes de ellas son (Zhu et al., 2014):

Bases de datos clave/valor. Bases de datos documentales. Base de datos columnar. Base de datos orientada a grafos.

Una base de datos orientada a grafos se basa en la teoría de grafos la cual inició

su estudio Leonhard Euler en el año de 1735 (Gross y Yellen, 2004). Aunque su aplicación inicial fue para resolver problemas de topología, se le han encontrado múltiples usos como por ejemplo el almacenamiento y gestión de datos (Zhu et al., 2014). Hoy día la teoría de grafos es una ciencia del campo de la matemática y de la computación, que se encarga del estudio de las relaciones entre objetos, llamados nodos, tanto nodos como relaciones tienen propiedades que les

32

describen. Su base teórica establecida durante cientos de años de estudio, brinda la solidez para su aplicación en un sistema de almacenamiento (Coronel y Morris, 2016).

En este tipo de base de datos se hace especial énfasis en las relaciones entre

los datos y su aplicación no se limita al manejo de grandes volúmenes de información, sino cuando la estructura de los datos puede ser modelada de manera natural como un grafo, lo que constituye uno de sus fuertes (McKnight, 2014). Dentro de las ventajas que esta orientación ofrece se encuentran el rendimiento, la flexibilidad, la agilidad y su diseño intuitivo para el almacenamiento (Robinson, Webber y Eifrem, 2015). Aunque su versatilidad le permite modelar casi cualquier tipo de datos, sus principales aplicaciones se encuentran en las redes sociales, análisis de rutas de viajes, tráfico financiero y de redes de transporte (McKnight, 2014).

La estructura básica de un grafo para el almacenamiento de datos consta de

nodos y relaciones, cada uno de ellos puede tener etiquetas que indican el rol que desempeñan en su contexto y atributos de tipo clave valor que representan datos de interés para almacenar. Las relaciones siempre tienen una dirección, un tipo, un nodo inicial y final, por lo general las propiedades de las relaciones contienen información cuantitativa como pesos, costos, distancias, tiempo, entre otros. Las relaciones pueden ser recorridas sin importar la dirección que posean (Neo4j, 2016).

Figura 5 Grafo con propiedades y etiquetas

Grafo de 6 nodos con 3 etiquetas diferentes, 6 relaciones de 2 tipos diferentes, una de ellas contiene la propiedad de fecha en la que se realizó la relación. Recuperado de Beginning neo4j.com Labeled Property Graph Data Model Copyright © 2016 Neo Technology, Inc.

En la figura 5 se muestra un ejemplo de grafo que contiene información sobre libros, sus autores y compradores, las etiquetas de los nodos son Persona, Autor, y Libro, (los nodos pueden tener múltiples etiquetas) dentro de cada nodo se encuentran sus respectivos atributos de tipo clave-valor (nombre: Ian). Las relaciones en este caso son de 2 tipos, ‘Escribió’ y ‘Adquirió’ a diferencia de los

33

nodos, las relaciones poseen solo una etiqueta o tipo. En este caso en particular los atributos de las etiquetas de compra, almacenan la fecha en la que se realizó la transacción.

Neo4j Neo4j es una base de datos NoSQL orientada a grafos multiplataforma, de código

abierto implementada en Java y Scala. Su desarrollo comenzó en el 2003, cuando se utilizó como una base de datos para copias de seguridad y sistemas de gestión de contenido para el ejército sueco, sin embargo, años más tarde se separó cómo un producto de código abierto (Robinson, 2014). Cuenta con una amplia cantidad de colaboradores y desarrolladores, su código puede ser consultado a través de GitHub y la información sobre soporte oficial está disponible en Stack Overflow y el grupo de google de Neo4j (Neo4j, 2017).

Esta herramienta provee todas las características de una base de datos robusta,

incluyendo el cumplimiento de transacciones ACID, siendo útil para almacenar estructuras datos mediante grafos en diferentes escenarios de producción, con la confiabilidad de una base de datos relacional y las ventajas de una NoSQL (Robinson, 2014), además cuenta con su propio lenguaje de consultas llamado Cypher, el cual es un lenguaje declarativo inspirado en SQL. Posee dos versiones, community y enterprise, la diferencia principal radica en el soporte y ciertas características de rendimiento, seguridad y escalabilidad particulares.

Neo4j es usado hoy día por cientos de miles de empresas y organizaciones en

casi todas las industrias, algunas de las más conocidas son: eBay, Walmart, Cisco y Hewlett Packard. Dentro de las aplicaciones más usadas se encuentran empresas del sector de manejo de redes, análisis de software, investigación científica, rutas de viaje, proyectos organizacionales, redes sociales entre otras (Neo4j, 2017).

InfiniteGraph InfiniteGraph es una base de datos orientada a grafos implementada en Java y

distribuida por la empresa Objectivity desde el año 2010. Fue diseñada para ofrecer soporte a organizaciones que requieran análisis de grandes cantidades de datos de manera rápida, para sectores empresariales, gubernamentales e investigativos. Está disponible para las plataformas MacOs, Linux y Windows, su licenciamiento es comercial y su valor generalmente depende del número de procesadores por servidor de base de datos (Mullins, 2015).

Dentro de las ventajas que ofrece esta base de datos se encuentran su alto

rendimiento, bajos costos, fácil implementación para empresas y organizaciones de diferentes sectores del mercado y escalabilidad ilimitada con su arquitectura Cloud-Ready, prometiendo que sus usuarios no tendrán necesidad alguna de cambiar el back-end de su base de datos. Una de sus principales prioridades es ofrecer una herramienta de análisis de relaciones entre grandes cantidades de datos y facilidad

34

de uso para diferentes tipos de usuario, enfatizando en la mitigación de impactos negativos en sus productos a largo plazo (Jarrell, 2010).

Tiene una particularidad con la cual es posible personalizar el uso que se espera

de la base de datos, desde un sistema de consistencia inmediata síncrona que soporte ACID hasta uno tipo BASE, de consistencia eventual asíncrona, dando la seguridad de que este último cuenta con un rendimiento y capacidad de distribución mucho mayor (Infinitegraph, 2017). Algunos de los principales usuarios de las bases de datos ofrecidas por Objectivity, incluyendo InfiniteGraph son: Ericsson, Siemens y los departamentos de defensa, inteligencia, marina y fuerza aérea de los estados unidos (Objectivity, 2017).

ArangoDB ArangoDB es una base de datos NoSQL de código abierto, implementado en

C++, multiplataforma, que reúne múltiples modelos de almacenamiento, como lo son: clave valor, documentos y grafos. El lanzamiento de su versión 1.0 se realizó en el verano del año 2012. Utiliza un lenguaje de consultas similar al SQL (AQL) o la posibilidad de usar para ello una extensión en lenguaje JavaScript, utiliza ACID en sus transacciones y ofrece una fácil escalabilidad tanto horizontal como vertical (ArangoDB, 2016; Schönert, 2012).

Dentro de las características más destacables se encuentran: la combinación del

modelo de datos entre clave valor, documentos y grafos bajo un lenguaje común, la utilización de tecnologías tales como múltiples hilos de procesamiento y unidades de almacenamiento de estado sólido (SSD). Ofrece la posibilidad de elección entre mayor rendimiento o durabilidad, además para lograr mayor escalabilidad es compatible con el uso de sharding, que permite utilizar varias máquinas para ejecutar un clúster de instancias de ArangoDB que en conjunto constituyen una sola base de datos. En su última versión cuenta con un detector automático de bloqueos mutuos (Schönert, 2012).

ArangoDB cuenta con una licencia Apache V2, permitiendo al usuario uso libre

para cualquier tipo de propósito bajo la única condición de que se especifique que se está haciendo uso de esta licencia. Cuenta con 3 tipos de subscripciones, Community, Basic y Enterprise, las dos últimas son versiones comerciales que ofrecen mayores prestaciones relacionadas con el soporte a sus suscriptores (Arangodb, 2017). Su documentación se encuentra disponible en la red a través de su grupo de Google, GitHub y StackOverflow.

Las bases de datos orientadas a grafos (en particular Neo4j frente a MariaDB)

han probado ofrecer mayores prestaciones que las de modelo relacional en conjuntos de datos que poseen estructuras genealógicas asociadas a pedigrí en factores como: eficiencia de almacenamiento, tiempo de respuesta en la obtención de datos y facilidad de expresión de las consultas (Kirby et al., 2014). Los datos a usar en este proyecto responden a una estructura de tipo árbol genealógico. Dadas

35

las ventajas encontradas al hacer uso de bases de datos NoSQL en particular orientadas a grafos en este tipo de estructuras, se opta por este modelo, ya que, al tratarse de un prototipo orientado a la web, la rápida capacidad de respuesta de cada uno de sus componentes se considera de suma importancia.

2.3.3 Protocolo Two Phase Commit Teniendo en cuenta que en este proyecto se integran dos modelos de

persistencia (relacional y no relacional), es necesario tratar el manejo de transacciones entre sistemas distribuidos heterogéneos.

El protocolo Two Phase Commit es una técnica utilizada sobre bases de datos

distribuidas para garantizar la atomicidad en sus transacciones con el fin de evitar inconsistencias en sus registros (Philip y Newcomer, 2009). Este protocolo no es usualmente utilizado en bases de datos que funcionan de manera local o que manejan un único nodo, debido a que una de las características de las bases de datos relacionales modernas es el manejo de las transacciones garantizando las características ACID de manera que sea transparente para la aplicación.

El uso de este protocolo permite tener un mayor control sobre las transacciones

facilitando el manejo personalizado de los errores o excepciones generadas durante el funcionamiento de la aplicación.

Para su implementación se consideran elementos como el coordinador y los

participantes. La función del primero de ellos es la ejecución del protocolo asegurándose que los participantes en cada fase se encuentren en un estado correcto o deseable, de lo contrario se cancelará la transacción o se revertirán los cambios (Hewitt, 2011). Adicionalmente y como su nombre lo indica, cuenta con dos fases: preparación (prepare) y confirmación (commit). En la figura 6 se muestra cómo se ejecutan.

Figura 6 Mensajes intercambiados entre el coordinador y los participantes en el protocolo Two

Phase Commit.

Recuperado de: Principes of Transaction Processing, 2nd ed. pp. 226. Copyright 2009 por Elsevier Inc.

36

El protocolo consta de diferentes mensajes entre el coordinador y los

participantes: en la primera fase se envía un Request-To-Prepare en el cual los participantes podrán contestar Prepared, una excepción o denegación de la solicitud, en este segundo caso el coordinador abortará las operaciones en todos los participantes. En caso de que todos los participantes se encuentren preparados, iniciará la segunda fase, en donde el coordinador enviará el mensaje para que cada uno haga Commit.

Si bien este protocolo no garantiza la atomicidad de las transacciones en su

totalidad, es una buena aproximación a que esto suceda, y en caso de que llegara a ocasionar un fallo en la segunda fase, se pueden utilizar mecanismos de compensación o métodos heurísticos para asegurar la consistencia de la base de datos (Philip y Newcomer, 2009).

2.3.4 APIs de persistencia

En el mundo del desarrollo de aplicaciones existen diferentes herramientas para el manejo de la persistencia dependiendo del lenguaje de programación a utilizar. JDBC (Java Database Connectivity) es una de ellas, siendo una interfaz de programación de aplicaciones que ofrece un medio ampliamente conocido y utilizado para el acceso a las bases de datos (Oracle, 2017). En proyectos pequeños resulta más que suficiente, pero con el aumento de la complejidad de una aplicación hace que el desarrollo sea más lento debido a su codificación repetitiva que supone complicaciones y retrasos por parte del equipo de programadores (Ottinger, Linwood y Minter, 2016).

Para simplificar este proceso de desarrollo se requiere de una herramienta que mediante el análisis de los objetos y sus relaciones se les asocie con los elementos del modelo de base de datos. Algunas de estas herramientas son JPA en Java, Doctrine para PHP o la ofrecida por Django para Python, las cuales entregan todo un conjunto de funciones que permiten facilitar las labores de persistencia y reducir el tiempo de desarrollo de aplicaciones.

2.3.4.1 Hibernate

Hibernate (JBoss, 2017) es una herramienta de mapeo objeto relacional de

código abierto que facilita el desarrollo de aplicaciones de diferentes tamaños permitiendo independizar el desarrollo y las bases de datos, es compatible con múltiples frameworks como lo son JSF, Spring y Struts (Konda, 2014). Una de las principales ventajas de este tipo de herramientas es que permite cambiar fácilmente el sistema gestor de la base de datos sin tener que realizar mayores modificaciones en la codificación de la aplicación y que permite crear automáticamente el esquema de la base de datos a partir de los objetos con los que ha sido configurado facilitando la portabilidad de la aplicación (Prajapati y Ranapariya, 2015).

37

Su implementación se puede hacer mediante anotaciones en los POJOS de la aplicación o utilizando archivos de configuración en lenguaje XML especificando el nombre de la clase que mapeará y sobre que tabla, nombre de los atributos, su tipo, relaciones con otros objetos y algunas restricciones de integridad. Algunos entornos de desarrollo integrados como Eclipse y NetBeans asisten la creación de los diferentes elementos para la utilización de Hibernate como lo son herramientas de ingeniería inversa, generación de POJOS y creación de archivos de configuración.

2.3.4.2 Neo4j OGM

Neo4j OGM es una herramienta de mapeo objeto-grafo desarrollado bajo la

licencia Apache versión 2.0, su funcionamiento consiste en crear asociaciones entre los objetos de Java y los nodos existentes en la base de datos (Neo4j, 2017). Su configuración a diferencia de ORMs como Hibernate permite únicamente la utilización de anotaciones en los POJOS de la aplicación. Como otras herramientas de mapeo busca simplificar y minimizar el tiempo del proceso de desarrollo. Neo4j al ser una base de datos libre de esquema no es necesario el uso de algún lenguaje de declaración, ya con el lenguaje de consultas Cypher utilizado por esta herramienta es suficiente para la creación y configuración de sus objetos.

38

2.4 Marco metodológico

Las metodologías ágiles nacen para tratar llenar el vacío metodológico de los desarrollos que por tiempo y poca flexibilidad evitaban el uso de propuestas tradicionales (Canós, Letelier y Penadés, 2003). A partir del 2001, con la reunión de 17 expertos convocados por Kent Beck en Utah (EEUU), nace el término “metodologías ágiles” y su intención de difundirla a través de una serie de valores y principios que las caracterizan, siendo estas metodologías que han sido especialmente pensadas para desarrollos integrados por equipos pequeños, con tiempo reducido, requisitos que cambian constantemente y basados en nuevas tecnologías (Canós et al., 2003).

Lo que enuncian los valores de las metodologías ágiles es el seguimiento y

respeto de los conceptos tradicionalmente utilizados, pero de manera más flexible, aplicando con mayor énfasis algunos nuevos valores que resultan más prácticos, otorgando mayor relevancia al factor humano. El manifiesto ágil (agilemanifesto.org, 2001) enuncia “Individuos e interacciones sobre procesos y herramientas, Software funcionando sobre documentación extensiva, Colaboración con el cliente sobre negociación contractual, Respuesta ante el cambio sobre seguir un plan. Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.”

Algunas de las metodologías ágiles más usadas son: Programación Extrema

(XP), Scrum, Desarrollo de software ajustado (Lean Software Development), Desarrollo basado en funciones (Feature-Driven Development) y Crystal (Dingsøyr, Nerur, Balijepally, Moe, 2012). Una de las principales características de estas metodologías son su gran adaptación a los cambios y capacidad de respuesta, lo que les da cierta ventaja frente a las metodologías tradicionales en desarrollos web y aplicaciones para dispositivos móviles (Amaya, 2013).

2.4.1 Metodología ágil Scrum

Esta metodología es un modelo iterativo que involucra un conjunto de

participantes a los cuales les es asociado un rol. Contiene una serie de reuniones, fases y entregables al finalizar cada una; lo que constituye un marco de trabajo adecuado para proyectos conformados por un número variable de personas que buscan trabajar de una manera práctica y estructurada en proyectos donde los requerimientos están sujetos a cambios durante su desarrollo.

Scrum inicia en el año de 1986 en un artículo nombrado “The new product development game” (Nonaka y Takeuchi, 1986), en el cual se hace la descripción de ciertas estrategias utilizadas por empresas como Honda, Canon y Fuji-Xerox para gestionar el desarrollo de sus productos. Esta metodología reúne un conjunto de valores, principios y prácticas dentro un marco de trabajo común conocido como Scrum (Rubin, 2012).

39

Este marco de trabajo lo componen roles, eventos, artefactos y reglas que les enlazan. De sus características generales se destaca la conformación de equipos con capacidad de auto organización y multidisciplinarios, la división del progreso de producto en una serie de Sprints, la captura de requerimientos en un product backlog (historias de usuario), la independencia de prácticas de ingeniería y la capacidad del equipo para desarrollar reglas dadas las necesidades particulares del proyecto (Rubin, 2012).

Dentro de las prácticas que componen Scrum se encuentran el empirismo, en donde a través de la inspección y adaptación se responde a situaciones emergentes, priorizar tareas y actividades sujetas a intervalos de tiempo definidos entre 2 y 8 semanas dependiendo de su extensión, complejidad o personal a cargo y finalmente auto organización del equipo de trabajo, mediante grupos idóneos en cada tarea a realizar que mantienen comunicación mediante reuniones diarias así como al inicio y fin de cada fase (Keith, 2010).

Para el desarrollo del proyecto, a partir del product backlog (que resume las funcionales que se esperan de la aplicación con su respectiva prioridad) se hará la planeación de cada Sprint, que contiene una serie de tareas específicas a ejecutar en un lapso de tiempo de entre 2 y 6 semanas, finalizando con la revisión y adaptación, lo que permite contar con un entregable que ofrece nuevas funcionalidades a la aplicación; este proceso se hace de manera iterativa hasta que se pueda terminar el prototipo funcional propuesto.

Se eligió la metodología ágil Scrum debido a la disponibilidad de tiempo, la capacidad de obtener un producto potencialmente entregable al finalizar cada Sprint, las tecnologías inmersas en el desarrollo, el alcance del proyecto y la ágil respuesta a los cambios mediante la inspección y adaptación de los requerimientos del prototipo desarrollado.

40

3. DESARROLLO DEL PROYECTO.

En esta sección se presenta el proceso de desarrollo del proyecto haciendo uso de la metodología Scrum. Inicialmente se muestra la conformación del equipo y los roles que fueron asignados a cada uno de los involucrados y luego se realiza la definición de los Sprints con sus correspondientes tareas asociadas. 3.1 Metodología de desarrollo - Scrum

3.1.1 Conformación del equipo

El desarrollo de este proyecto contó con la participación de las siguientes personas:

Nombre Rol

Alba Consuelo Nieto Lemus (Directora de tesis) Scrum Master Jose Daniel Carranza Leguízamo (Estudiante) Scrum Team 1 Jose Leonardo Vanegas Prieto (Estudiante) Scrum Team 2

Tabla 1 Integrantes del equipo de desarrollo.

3.1.2 Plan del proyecto

Para el desarrollo de los objetivos propuestos en el desarrollo del proyecto se inició configurando el Product Backlog con las historias de usuario identificadas por el equipo las cuales constituyeron la fuente de alimentación para el uso de la herramienta IceScrum como un apoyo para la gestión del proyecto (Kagilum, 2017). Posteriormente se realizó la planificación de los Sprints con sus tareas asociadas, fechas de inicio y fin; los Sprints planificados fueron 5 con una duración individual de entre 3 y 4 semanas.

3.1.2.1 Product backlog

Mediante múltiples reuniones llevadas a cabo con médicos veterinarios y

criadores y apoyándose en las recomendaciones de distintos autores en los temas de cruce y crianza felina, se elaboró una lista de características que debería cumplir la aplicación para satisfacer los objetivos propuestos en este proyecto. De esta lista se construyeron las historias de usuario las cuales fueron clasificadas por módulos desarrollados a través de los diferentes Sprints propuestos para el desarrollo. Adicionalmente se incluyeron historias técnicas asociadas a tareas específicas del desarrollo.

41

En la figura 7, se muestran las historias de usuario obtenidas con las cuales se alimentó el sandbox de la herramienta IceScrum.

Figura 7 Sandbox de IceScrum con las historias de usuario.

42

3.1.2.2 Definición de Sprints

Teniendo en cuenta el nivel de prioridad de las historias de usuario y los módulos a los que pertenecen, se planearon 4 Sprints. A cada uno se asociaron entre 4 y 6 historias de usuario; al finalizar cada uno se obtuvo como resultado un entregable. En la figura 8, se muestra la distribución de las historias de usuario y técnicas a través de los Sprints utilizando la herramienta IceScrum.

Figura 8 Captura de pantalla de IceScrum con los Sprints del proyecto.

43

La duración de cada Sprint osciló entre 3 y 5 semanas. A cada elemento del Product Backlog se asignó un código dependiendo si se trataba de una historia técnica o de usuario. En la tabla 2 se muestran la duración asociada a cada Sprint con sus respectivas historias de usuario asociadas.

En las siguientes secciones se mostrará el detalle de desarrollo de cada Sprint y

todos los artefactos generados a través de ellos.

Sprint Duración (Semanas)

Historias de usuario / técnicas Código Nombre

Sprint 1 3

HT_01 Diagrama E-R HT_02 Diagrama de casos de uso HT_03 Definición de la arquitectura HT_04 Diseño de bocetos funcionales

Sprint 2 3

HU_GL_01 Autenticación de usuario HU_GL_02 Aplicación web HU_GE_01 Registro y seguimiento de ejemplares HU_GE_02 Registro y consulta de pedigrí

Sprint 3 4

HU_CM_01 Seguimiento de consultas médicas

HU_CM_02 Registro y consulta de constantes fisiológicas y hallazgos clínicos

HU_CM_03 Registro y consulta de diagnósticos HU_CM_04 Registro y consulta de tratamientos

Sprint 4 3

HU_NU_01 Historial nutricional de los ejemplares

HU_NU_02 Alimentación de la plataforma con alimentos utilizados

HU_NU_03 Consulta de ración y alimento

Sprint 5 4

HU_CR_01 Cálculo de COI, COR, eficacia y mortalidad.

HU_CR_05 Consulta de información médica relevante para el cruce

HU_CR_06 Consulta de camadas en común de dos ejemplares

HU_CR_02 Consulta de camadas previas HU_CR_03 Resumen de datos de ejemplares para cruces HU_CR_04 Registro de camadas

Tabla 2 Lista de Sprints con sus respectivas historias técnicas y de usuario.

44

3.2 Desarrollo del Sprint 1.

SPRINT 1

ACTIVIDADES

Definición las historias de usuario para tener pleno conocimiento de las características deseadas.

Definición de la arquitectura del prototipo. Especificación la estructura de la persistencia. Modelado la estructura de objetos del prototipo. Diseño de mapa de navegación y bocetos funcionales.

ENTREGABLES

Modelos relacionados con la persistencia. Diagrama de contexto de la aplicación. Diagrama de la arquitectura del prototipo. Bocetos funcionales. Mapa de navegación general de la aplicación.

DURACIÓN 3 semanas

Utilizando los elementos contenidos en el Product Backlog se plantearon 4 módulos que engloban el conjunto de funcionalidades requeridas en la aplicación; adicionalmente se plantearon 4 historias técnicas asociadas a detalles de ingeniería.

Módulo Historias de usuario asociadas Gestión de ejemplares HU_GE_01

HU_GE_02 Consultas Médicas HU_CM_01

HU_CM_02 HU_CM_03 HU_CM_04

Información nutricional HU_NU_01 HU_NU_02 HU_NU_03

Información de cruces HU_CR_01 HU_CR_02 HU_CR_03 HU_CR_04 HU_CR_05 HU_CR_06

Tabla 3 Módulos e historias de usuario asociadas.

3.2.1 Definición de las historias de usuario En el Sprint 1 se realizó la caracterización de las historias de usuario que

componen el proyecto mediante la reunión del equipo Scrum y el Scrum Manager.

45

Para la documentación de las historias se utilizó el formato sugerido en el proyecto “Desarrollo de un prototipo de software móvil para implementar un taxímetro enfocado al control del servicio” (Babativa, Briceño, 2017) que utilizó la misma metodología para su desarrollo, formato que contiene los campos de nombre, código, historias relacionadas, complejidad (alta, media, baja), actor, descripción, módulos y criterios de aceptación. A continuación, se listan las 22 historias de usuario en el formato especificado.

3.2.1.1 Registro y seguimiento de ejemplares

HISTORIA DE USUARIO

Código: HU_GE_01 Nombre: Registro y seguimiento de ejemplares.

Tipo HU: Funcional Complejidad: Alta Actor: Usuario HU Relacionadas: HU_GE_02, HU_CM_01 Módulo: Gestión de ejemplares Descripción: Cómo criador necesito una aplicación que me permita llevar un

registro de los ejemplares del sistema de crianza con diferentes datos asociados a los animales, así este ya no se encuentre activo como procreador en el criadero.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

Usuario autenticado La aplicación permite realizar operaciones de

creación, consulta y modificación de ejemplares.

3.2.1.2 Registro y consulta de pedigrí

HISTORIA DE USUARIO

Código: HU_GE_02 Nombre: Registro y consulta de pedigrí.

Tipo HU: Funcional Complejidad: Media Actor: Usuario HU Relacionadas: HU_GE_01, HU_CR_01 Módulo: Gestión de ejemplares Descripción: Cómo criador necesito una herramienta que me permita visualizar

el pedigrí de cada ejemplar con una cantidad variables de generaciones y navegar por la información asociada de cada animal registrado.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

46

El usuario debe haber creado el ejemplar

El usuario podrá registrar y configurar el árbol genealógico del ejemplar y los datos asociados a su pedigrí.

3.2.1.3 Seguimiento de consultas médicas.

HISTORIA DE USUARIO

Código: HU_CM_01 Nombre: Seguimiento de consultas médicas.

Tipo HU: Funcional Complejidad: Alta

Actor: Usuario HU Relacionadas:

HU_GE_01, HU_NU_02, HU_CM_02, HU_CM_03, HU_CM_04, HU_CR_05, HU_CR_03.

Módulo: Consultas médicas Descripción: Cómo médico veterinario necesito registrar y consultar las

novedades médicas que presente cada ejemplar, como condiciones particulares, afecciones, historial de vacunación, desparasitación, enfermedades, diagnósticos y tratamientos.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

El usuario ha registrado el ejemplar al cual se adjuntará la información médica.

El usuario podrá gestionar la información médica del ejemplar a través de consultas médicas.

3.2.1.4 Registro y consulta de constantes fisiológicas y hallazgos clínicos.

HISTORIA DE USUARIO

Código: HU_CM_02

Nombre:

Registro y consulta de constantes fisiológicas y hallazgos clínicos

Tipo HU: Funcional Complejidad: Media

Actor: Usuario HU Relacionadas: HU_CM_01

Módulo: Consultas médicas Descripción: Como médico veterinario necesito asociar un conjunto de

constantes fisiológicas y hallazgos clínicos a la consulta médica para registrar el estado del ejemplar teniendo en cuenta diferentes aspectos.

47

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

El usuario ha creado la consulta médica asociada al ejemplar y completado los campos de constantes y hallazgos fisiológicos.

El sistema permitirá persistir y consultar la información registrada de los hallazgos y constantes asociados a una consulta.

3.2.1.5 Registro y consulta de diagnósticos.

HISTORIA DE USUARIO

Código: HU_CM_03 Nombre: Registro y consulta de diagnósticos.

Tipo HU: Funcional Complejidad: Media Actor: Usuario HU Relacionadas: HU_CM_01 Módulo: Consultas médicas Descripción: Como médico veterinario necesito asociar diagnósticos a las

consultas médicas registradas con el fin de hacer un mejor seguimiento a la salud del ejemplar por medio de las consultas.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

El usuario ha creado la consulta médica asociada al ejemplar.

El sistema permite asociar múltiples diagnósticos a una consulta y a ellos diferentes tratamientos y persistirlos para su posterior consulta.

3.2.1.6 Registro y consulta de tratamientos.

HISTORIA DE USUARIO

Código: HU_CM_04 Nombre:

Registro y consulta de tratamientos.

Tipo HU: Funcional Complejidad: Media Actor: Usuario HU Relacionadas: HU_CM_01 Módulo: Consultas médicas Descripción: Como cuidador necesito conocer tratamientos a los cuales se

estén sometiendo los ejemplares para suministrar el cuidado específico que requiere.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

48

El usuario ha registrado tratamientos ya sea medicaciones, cirugías, exámenes o acciones preventivas.

El usuario tiene acceso a la información el histórico de tratamientos que ha recibido el ejemplar a través de las consultas médicas registradas.

3.2.1.7 Historial nutricional de los ejemplares.

HISTORIA DE USUARIO

Código: HU_NU_01 Nombre: Historial nutricional de los ejemplares.

Tipo HU: Funcional Complejidad: Media Actor: Usuario HU Relacionadas: HU_NU_03, HU_CM_01 Módulo: Información nutricional Descripción: Cómo médico veterinario necesito contar con el historial

nutricional de cada ejemplar, para poder identificar a mediano o largo plazo el impacto en cambios de dieta del animal y con base en ello poder tomar decisiones nutricionales.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

El usuario registra un diagnóstico que remite una dieta particular.

El usuario a través de dietas asociadas a un diagnóstico maneja la información nutricional de un ejemplar y el seguimiento del peso se extrae de la consulta médica.

3.2.1.8 Alimentación de la plataforma con alimentos utilizados.

HISTORIA DE USUARIO

Código: HU_NU_02

Nombre:

Alimentación de la plataforma con alimentos utilizados.

Tipo HU: Funcional Complejidad: Baja

Actor: Sistema HU Relacionadas: HU_NU_01, HU_NU_02

Módulo: Información nutricional Descripción: Como criador necesito tener la lista de alimentos con sus

tipos asociados disponibles para su asociación a dietas por medio de la aplicación.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

49

Recolección de información de los alimentos con los que son alimentados los ejemplares del criadero.

El usuario dispone de múltiples alimentos de diferentes tipos para asociarlos en las dietas de los ejemplares.

3.2.1.9 Consulta de ración y alimento.

HISTORIA DE USUARIO

Código: HU_NU_03 Nombre: Consulta de ración y alimento.

Tipo HU: Funcional Complejidad: Baja Actor: Usuario HU Relacionadas: HU_NU_01 Módulo: Información nutricional Descripción: Como cuidador necesito conocer aspectos básicos de la

información nutricional de los ejemplares para suministrar el alimento en la ración adecuada.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

El usuario registró la información nutricional asociada al ejemplar.

El usuario consulta la información de su dieta actual, ración, alimento, tipo de alimentación y último peso registrado.

3.2.1.10 Cálculo de COI, COR y eficacia.

HISTORIA DE USUARIO

Código: HU_CR_01 Nombre: Cálculo de COI, COR, eficacia y mortalidad.

Tipo HU: Funcional Complejidad: Alta Actor: Sistema HU Relacionadas: HU_GE_02 Módulo: Información de cruces Descripción: Cómo médico veterinario necesito mediante la aplicación

conocer los coeficientes de inbreeding y relación de los ejemplares a cruzar, adicionalmente el cálculo de la eficacia de la población que da cuenta de la diversidad alélica del criadero y de la tasa de mortalidad por ejemplar.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

El usuario ha registrado el pedigrí del ejemplar

El sistema mediante la base de datos orientada a grafos realiza el recorrido del árbol genealógico,

50

específicamente sus progenitores.

entregando el COI, con este calcula el COR y el cálculo de la eficacia de la población lo obtiene por medio de la cantidad de machos y hembras activos en el sistema de crianza.

3.2.1.11 Consulta de camadas previas.

HISTORIA DE USUARIO

Código: HU_CR_02 Nombre: Consulta de camadas previas.

Tipo HU: Funcional Complejidad: Baja Actor: Sistema HU Relacionadas: HU_CR_04 Módulo: Información de cruces Descripción: Cómo médico veterinario tengo la necesidad de poder ver los

antecedentes de cruzas entre ejemplares para no repetir aquellos que presenten algún tipo de alteración.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

El usuario ha registrado las camadas asociadas al ejemplar.

El usuario puede consultar las camadas asociadas a un ejemplar.

3.2.1.12 Resumen de datos de ejemplares para cruces.

HISTORIA DE USUARIO

Código: HU_CR_03 Nombre: Resumen de datos de ejemplares para cruces.

Tipo HU: Funcional Complejidad: Baja

Actor: Sistema HU Relacionadas:

HU_GE_01, HU_GE_02, HU_CM_01, HU_CR_01, HU_CR_05, HU_CR_06

Módulo: Información de cruces Descripción: Cómo médico veterinario necesito consultar información

médica de cada ejemplar de manera resumida antes de realizar un cruce, para poder hacer una evaluación y proyección médica de la progenie resultante del cruce.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

El sistema cuenta con los datos del ejemplar como su pedigrí,

Se mostrará la información básica de ambos progenitores, COI, COR, camadas de

51

historial médico, tratamientos, dietas y camadas.

cada ejemplar, camadas en común, tasa de mortalidad y consultas relevantes para el cruce.

3.2.1.13 Registro de camadas

HISTORIA DE USUARIO

Código: HU_CR_04 Nombre: Registro de camadas Tipo HU: Funcional Complejidad: Media Actor: Usuario HU Relacionadas: HU_GE_01 Módulo: Información de cruces. Descripción: Cómo criador quiero tener la posibilidad de registrar las camadas

resultantes de cruces, con su fecha y novedades asociadas, información de sus progenitores y aspectos médicos presentes.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

El usuario ha registrado los ejemplares y realizado la prueba de cruce entre los progenitores.

El usuario tendrá disponible la opción de registrar la camada con el número de no natos y observaciones correspondientes, una vez realizado este procedimiento podrá consultarla en los detalles de información del ejemplar.

3.2.1.14 Consulta de información médica relevante para el cruce.

HISTORIA DE USUARIO

Código: HU_CR_05 Nombre:

Consulta de información médica relevante para el cruce.

Tipo HU: Funcional Complejidad: Baja Actor: Sistema HU Relacionadas: HU_GE_01 Módulo: Información clínica Descripción: Como médico veterinario encuentro que algunas consultas

médicas pueden producir tratamientos o diagnóstico de especial importancia al momento de realizar un cruce, por lo que veo la necesidad de poder marcar algunas consultas como relevantes para tenerlas en cuenta en el momento de cruzar el ejemplar.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

52

El usuario ha registrado consultas médicas con el campo de verificación de relevancia para el cruce habilitado.

El sistema consulta las consultas médicas que han sido marcadas como relevantes para el cruce y recupera el listado.

3.2.1.15 Consulta de camadas en común de dos ejemplares.

HISTORIA DE USUARIO

Código: HU_CR_06 Nombre:

Consulta de camadas en común de dos ejemplares.

Tipo HU: Funcional Complejidad: Baja

Actor: Sistema HU Relacionadas: HU_CR_04

Módulo: Información de cruces Descripción: Como criador me es importante conocer información

relacionada con cruces previos presentados entre dos ejemplares para conocer el detalle de su resultado.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

Los ejemplares a consultar tienen camadas registradas y fueron seleccionados para consultar la información para un cruce.

La aplicación mostrará las camadas en común que tienen dos ejemplares seleccionados.

3.2.1.16 Autenticación de usuario.

HISTORIA DE USUARIO

Código: HU_GL_01 Nombre: Autenticación de usuarios.

Tipo HU: Funcional Complejidad: Baja Actor: Usuario HU Relacionadas: Ninguna Módulo: N/A Descripción: Cómo criador necesito que toda la información suministrada a

la aplicación sea privada ya que esta constituye un activo para mí.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

53

No existe ninguna cookie de sesión asociada a la aplicación.

El usuario se autentica y puede acceder a las funcionalidades que ofrece la aplicación.

3.2.1.17 Aplicación web.

HISTORIA DE USUARIO

Código: HU_GL_02 Nombre: Aplicación web. Tipo HU: No funcional Complejidad: Baja Actor: Equipo Scrum HU Relacionadas: Módulo: No aplica Descripción: Cómo criador es de mi interés que la aplicación pueda ser

accedida desde navegador web de manera que su consulta sea posible desde un ordenador con conexión a internet.

CRITERIOS DE ACEPTACIÓN Condición: Resultado: No aplica. Desarrollo del prototipo web.

3.2.1.18 Diagrama E-R

HISTORIA TÉCNICA Código: HT_01 Nombre: Diagrama E-R Tipo HT: No funcional Complejidad: Media Actor: Equipo Scrum HU Relacionadas: Módulo: no aplica

Descripción: Creación del diagrama entidad relación que responda al

modelo de negocio de la aplicación. CRITERIOS DE ACEPTACIÓN

Condición: Resultado: Consulta de información del

funcionamiento del sistema de cruces y crianza en un criadero.

Creación del diagrama Entidad Relación.

3.2.1.19 Diagrama de contexto.

HISTORIA TÉCNICA

Código: HT_02 Nombre: Diagrama de contexto.

54

Tipo HU: No funcional Complejidad: Media Actor: Equipo Scrum HU Relacionadas: HT_01 Módulo: no aplica

Descripción:

Creación de los diagramas de contexto y de casos de uso que describan las funcionalidades del prototipo y la interacción del usuario a través de ella.

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

Consulta de información del funcionamiento del sistema de cruces y crianza en un criadero.

Creación del diagrama de contexto y casos de uso.

3.2.1.20 Definición de la arquitectura.

HISTORIA TÉCNICA

Código: HT_03 Nombre: Definición de la arquitectura.

Tipo HU: No funcional Complejidad: Media Actor: Equipo Scrum HU Relacionadas: HU_GL_02 Módulo: no aplica

Descripción: Definición de la arquitectura de software más adecuada con la

que será desarrollado el prototipo. CRITERIOS DE ACEPTACIÓN

Condición: Resultado: Conocimiento de los

requerimientos del prototipo. Se definirá la arquitectura que modelará la

aplicación.

3.2.1.21 Diseño de bocetos funcionales.

HISTORIA TÉCNICA

Código: HT_04 Nombre: Diseño de bocetos funcionales.

Tipo HU: No funcional Complejidad: Baja Actor: Equipo Scrum HU Relacionadas: HT_01 Módulo: no aplica

Descripción:

Se diseñarán los bocetos funcionales que definirán las plantillas de las vistas por medio de las cuales interactúa el usuario.

55

CRITERIOS DE ACEPTACIÓN Condición: Resultado:

Conocimiento de las necesidades de criadores y médicos veterinarios y lo que esperan del prototipo.

Se cuentan con los diseños que guiarán la capa de vista de la aplicación.

A partir de las funcionalidades planteadas mediante las historias de uso se realizó

un diagrama de contexto mostrado en la figura 9, que enseña cómo es la interacción del usuario con los módulos que se desarrollarían en la aplicación.

Figura 9 Diagrama de contexto.

3.2.2 Definición de la arquitectura

En el desarrollo de la aplicación se utilizó una arquitectura de 3 capas (modelo, vista, controlador); se eligió como lenguaje de programación Java y como framework de presentación Java Server Faces (Oracle, 2017). En la figura 10 se ilustra el modelo conceptual de la arquitectura.

56

Figura 10 Arquitectura de la aplicación.

Los componentes del modelo de la arquitectura son: Capa de cliente: Esta capa cuenta con los diferentes navegadores web con

los cuales, a través del protocolo Http, se hace la comunicación con la capa Web de la aplicación para acceder a sus diferentes funcionalidades.

Capa Web: Capa que se implementó con la tecnología JSF 2.0. Cuenta con las páginas web, y Servlet con las cuales construyen las respuestas http a las peticiones que se realicen desde la capa de cliente, también contiene los Managed Beans los cuales interactúan con la capa de negocio de la aplicación.

Capa de negocio: Capa que cuenta con los objetos de negocio, de acceso a datos y de utilidades con los cuales se modela y manipulan los registros en la

57

capa de base de datos. Debido a que se utilizaron dos motores de bases de datos diferentes, Neo4j y Postgres, se utilizan dos tecnologías diferentes para interactuar con estas bases de datos: para la base de datos de grafos Neo4j, se cuenta con el API java-neo4j-ogm, para la base de datos de Postgres utiliza Hibernate, implementación del API JPA. Los diferentes objetos se organizan en dos paquetes diferentes según el modelo de datos. Se usa el paquete ModelOGM para los objetos relacionados a la base de datos orientada a grafos Neo4j, y el paquete ModelORM para los datos relacionados con la base de datos relacional Postgres. Dentro del paquete ModelOGM se tendrán los siguientes sub paquetes:

o Entidades, donde se organizan los objetos de negocio. o DAO, donde se organizan los objetos de acceso a datos. o Excepciones, donde se organizan los objetos de excepción propios de

la transacción global. o Utilidades, donde se organizan los objetos para obtener el manejador

de sesión por medio del cual se interactúa con base de datos de Neo4j y el objeto para cálculo de coeficientes COI, COR y eficacia de la población.

En el paquete ModelORM se cuenta con los siguientes sub paquetes: o Entidades, donde se organizan los objetos de negocio o CoordinadorTransacciones, donde se tiene el objeto

TransaccionGlobal con el cual se controla la transacción de guardado y actualización de los ejemplares tanto en Neo4j como en Postgres

o CoordinadorTransacciones.DAO, donde se organizan los objetos de acceso a datos.

o Excepciones, donde se organizan los objetos de excepción propios de la transacción global.

o Utilidades, donde se organiza el objeto para obtener el manejador de sesión con el cual se interactúa con la base de datos Postgres, también se tiene el objeto encargado de realizar el encriptado de la clave almacenada en la base de datos.

Capa de Datos: capa en la cual se encuentran los motores de base de datos Neo4j y Postgres. Como ya se mencionó anteriormente, para interactuar con cada uno de los motores de bases de datos se utilizan dos API diferentes, Hibernate para Postgres y java-neo4j-ogm para Neo4j. La comunicación con Neo4j se hace a través del protocolo http, mientras que con Postgres mediante JDBC.

3.2.3 Especificación de la estructura de la persistencia.

La aplicación está soportada en dos modelos de bases de datos, el relacional es

utilizado para contener la información referente al manejo de las historias clínicas, diagnósticos, dietas y tratamientos, mientras que el orientado a grafos se encarga de persistir la estructura de árbol que representa el pedigrí del ejemplar, su fenotipo y las camadas con las que tiene relación. En la figura 11 se muestra el diagrama

58

entidad relación a partir del cual se realizó el modelado de las entidades y sus relaciones.

Figura 11 Diagrama del modelo Entidad Relación

59

Una vez comprendida la estructura de persistencia necesaria para la aplicación mediante el modelo entidad relación mostrado en la figura 11, se procedió a crear el modelo relacional que se implementó en el motor de bases de datos Postgres en el que se almacena la información relacionada con la creación de historias médicas, actividades relacionadas con tratamientos, datos de usuario y parte de la información del ejemplar; dicho modelo se muestra en la figura 12.

Figura 12 Modelo relacional.

60

Para modelar la información del pedigrí y fenotipo del ejemplar almacenados en la base de datos orientada a grafos se utilizó un modelo conocido como “modelo de grafo etiquetado” sugerido por los desarrolladores del motor Neo4j el cual se muestra en la figura 13.

Figura 13 modelo de grafo etiquetado.

Para la implementación del modelo de persistencia planteado se utilizó el framework Hibernate como ORM relacional y el OGM de Neo4j lo que simplificó la utilización de objetos y el desarrollo de la aplicación.

3.2.4 Modelado de la estructura de objetos del prototipo.

Haciendo uso de la herramienta Enterprise Architect se realizó el modelado de la

estructura de objetos usada la aplicación. Para la implementación del manejo de persistencia se utilizó el patrón Data Access Object que permite aislar el código de la aplicación del acceso y manipulación de registros en la base de datos (Elliott, Timothy y Fowler; 2008), al utilizar la especificación 2.2 de Java Server Faces se usaron Managed Beans los cuales son implementaciones de clases de java gestionados por JSF, que en el desarrollo del proyecto fueron utilizados para la interacción entre la capa de negocio y la vista de la aplicación. En el anexo 1 se encuentran los diagramas de clases asociados al desarrollo del proyecto.

61

3.2.5 Diseño del mapa de navegación y bocetos funcionales

Antes de iniciar el desarrollo de la aplicación se elaboró la lista de bocetos que sirvieron de guía para la elaboración de las plantillas de la aplicación los cuales se encuentran en el anexo 2, adicionalmente se creó el mapa de navegación para que el equipo de desarrollo tuviera una visión general del comportamiento de la aplicación, mapa que será actualizado al finalizar cada Sprint.

3.2.6 Reuniones del equipo y retrospección del Sprint

En el desarrollo del primer Sprint se alcanzaron a realizar dos reuniones quincenales

entre el Scrum Manager y el Equipo de desarrollo. En la primera reunión que se tuvo al inicio del Sprint se planteó de qué manera se iba a realizar la documentación de las historias de usuario optando por seguir el formato anteriormente especificado. También se dio orientación al equipo de desarrollo de cómo podría ser el planteamiento de la arquitectura y del modelado de persistencia, inicialmente se había considerado manejar la aplicación mediante un único modelo de bases de datos, pero se llegó a la conclusión de que era más conveniente separar las responsabilidades de los modelos según ciertas funcionalidades.

En la segunda reunión se realizó la revisión del avance, se corrigieron detalles de los

elementos generados. Finalmente, en el análisis retrospectivo del Sprint, se concluyó que la creación de artefactos de ingeniería se había realizado satisfactoriamente, adicionalmente se planteó la inquietud de cómo en el siguiente Sprint se realizaría el trabajo de las operaciones CRUD sobre los diferentes modelos de datos en la creación del ejemplar. El Scrum Manager sugirió al equipo una lectura sobre bases de datos distribuidas para encontrar una estrategia que asegure en la medida de lo posible la consistencia de las operaciones y los registros en los motores de las bases de datos.

62

3.3 Desarrollo del Sprint 2

SPRINT 2

ACTIVIDADES

Preparación del entorno de desarrollo. Implementación del sistema de autenticación de usuarios. Creación del módulo de gestión de ejemplares. Implementación del protocolo 2PC para la persistencia en los

motores de las bases de datos. Desarrollo de la funcionalidad de registro, seguimiento de

ejemplares y pedigrí.

ENTREGABLES

Diagrama de secuencia de la funcionalidad de creación de ejemplar.

Prototipo con la funcionalidad de autenticación en funcionamiento.

Prototipo con la funcionalidad de gestión de ejemplares y pedigrí funcionando.

Mapa de navegación actualizado. Código documentado (Javadoc).

DURACIÓN 3 semanas

3.3.1 Preparación del entorno de desarrollo.

Para el desarrollo del proyecto uno de los primeros pasos fue la configuración del entorno, que consistió en la instalación de las herramientas y dependencias en sus versiones más estables disponibles en el mercado las cuales se detallan en la tabla 3:

Herramienta Versión Descripción

IDE Netbeans

8.2 Entorno de desarrollo para sistemas Windows, Linux y OS X, con compatibilidad para desarrollo de aplicaciones en múltiples lenguajes, entre ellos el empleado para este proyecto java y JSF. También cuenta con compatibilidad con servidores Glassfish para el despliegue de aplicaciones web JSF desde el entorno de desarrollo.

BitBucket

Herramienta en la nube para administración de códigos colaborativo. Ofrece control de versiones, trabajo colaborativo e integración con NetBeans.

Postgres 9.4.10 Sistema gestor de base de datos diseñado para almacenar y manipular datos en una estructura relacional.

63

Herramienta Versión Descripción

Neo4j 3.1.2 Sistema gestor de Base de datos diseñado para almacenar y manipular datos en una estructura de grafos.

Maven 2 Herramienta de administración de proyectos java, permite gestionar las diferentes dependencias de librerías usadas por la aplicación JSF para su compilación.

Log4j 1.2.17 Librería para la gestión de mensajes de registros (logs) en la aplicación.

Primefaces (JSF 2.2)

6.0 Es la implementación de la tecnología JavaServer Faces versión 2.2. Incluye el conjunto de APIs para la construcción ágil de interfaces de usuario del lado del servidor, validación y transferencia de datos en la capa de presentación, gestión de la comunicación por HTTP entre el cliente y el servidor. Se puede acceder a estos APIs a través del repositorio Maven.

Glassfish 4.1.1 Servidor de aplicaciones de código abierto para aplicaciones web java. Posee soporte para el funcionamiento de los componentes tales como JavaServer Faces (JSF), JavaServer Pages (JSP), Servlets, Beans, entre otros.

Hibernate 4.3.1 Framework de persistencia, implementación de JPA (Java Persistence Api) utilizado para hacer el mapeo objeto relacional de la información almacenada en la base de datos Postgres. También es el en cargado de gestionar la interacción entre la aplicación web y la base de datos.

Neo4j-ogm-core

2.1.2 Librería de Java para el mapeo de objeto-grafo para interactuar con base de datos orientada a grafos Neo4j. A través de POJOS con anotaciones de la librería se pueden mapear nodos, relaciones y propiedades de un grafo para ser usadas por la aplicación. Se puede acceder a la librería a través del repositorio de Maven.

Neo4j-ogm-http-driver

2.1.2 Librerías de java utilizadas por la librería Neo4j-ogm-core con el fin de realizar una comunicación con la base datos Neo4j a través del protocolo http.

Tabla 3 Herramientas y dependencias usadas en el desarrollo

64

3.3.2 Implementación del sistema de autenticación de usuarios. Se incluyó en el prototipo el sistema de autenticación de usuarios para evitar que

usuarios no autorizados realizaran operaciones sobre la aplicación, tal como lo indicaba la historia de usuario HU_GL_01, básicamente el prototipo cuenta con dos roles y su única distinción es la capacidad de crear otros usuarios, funcionalidad delegada exclusivamente al usuario administrador.

3.3.3 Creación del módulo de gestión de ejemplares

Dentro del primer Sprint de desarrollo del prototipo se creó la funcionalidad de gestión

de ejemplares, la cual constituye la base para la posterior creación de los siguientes módulos. Esta funcionalidad tuvo la particularidad de que exige la interacción con los diferentes modelos de bases de datos en las operaciones CRUD, para ello se vio la necesidad de utilizar una técnica utilizada principalmente en bases de datos distribuidas conocido como Two Phase Commit o protocolo de dos fases (Philip y Newcomer, 2009), el cual busca dar tratamiento adecuado a este tipo de operaciones; adicionalmente se creó un mecanismo de compensación al final de la segunda fase para evitar inconsistencias en las bases de datos.

3.3.3.1 Implementación del protocolo 2PC

El protocolo 2PC (Two Phase Commit) se implementó haciendo uso de un objeto que

coordina la transacción sobre los participantes en las operaciones realizadas sobre la base de datos. En el anexo 2 se puede observar el diagrama de secuencia que muestra su funcionamiento.

Se encontró la necesidad de usar del protocolo en la inserción y actualización de los

ejemplares; su ejecución inicia desde el Managed Bean del ejemplar al momento de invocar alguna de estas dos operaciones y se implementó como se muestra a continuación:

Fase 1: Preparación Desde el Managed Bean del ejemplar se crea el objeto coordinador ejemplificando la

clase TransaccionGlobal a través de la cual se ejecuta el método guardarEjemplar enviando como parámetros los ejemplares que serán almacenados en las bases de datos Neo4j y Postgres. Inicialmente se obtienen las sesiones a través de las cuales se utilizarán los métodos de persistencia, la fase 1 consta de dos pasos que se muestran a continuación.

Paso 1: Se inicia la transacción para la base de datos de Postgres, si se trata de la

creación de un ejemplar se ejecutará el método de guardar, en caso contrario se actualizará el objeto existente con las modificaciones realizadas.

65

En caso de fallar esta fase de preparación de la transacción se llamará la funcionalidad rollback por medio de la sesión de Hibernate.

Si no se genera ningún error en la preparación se procede con el paso 2. Paso 2: Se inicia la transacción por medio de la sesión de Neo4j, si se trata de la

creación de un ejemplar se le asignará el id generado por Postgres, posteriormente se guarda en la base de datos orientada a grafos.

En caso de fallar la preparación, el coordinador enviará los mensajes de rollback a

las sesiones de Postgres y Neo4j. Si no se genera ningún error se da por finalizada la fase 1 y se continua con la 2.

Fase 2: Confirmación

La fase 2 inicia evaluando el estado de la preparación de las transacciones, verificando si se encuentra activo para Postgres y abierto para Neo4j. En caso de que no se encuentren en un estado válido se finalizará la segunda fase sin hacer commit en ninguna de las bases de datos, de otra manera se continúa el proceso. La fase 2 consta de 2 pasos los cuales se muestran a continuación.

Paso 3: Se realiza el commit de la transacción de Postgres a través de la sesión de

Hibernate en la base de datos relacional. En caso fallar este primer commit, se llama la operación rollback sobre la sesión de

la base de datos orientada a grafos y se finaliza la ejecución del protocolo. En caso de obtener éxito se continúa con el paso 4.

Paso 4: Se realiza el commit de la transacción de Neo4j a través de la sesión del OGM. En caso de que la operación se ejecute exitosamente, el coordinador da por

finalizado el protocolo y se muestra el mensaje de que la creación o modificación del ejemplar se ha efectuado.

Si llega a fallar la segunda fase del protocolo, el coordinador ejecutará un mecanismo de compensación que borra el ejemplar de la base de datos de Postgres para evitar inconsistencias.

El mecanismo de compensación únicamente soluciona inconsistencias relacionadas

con la creación del ejemplar, en caso de actualización se debe recurrir a métodos heurísticos para recuperar la consistencia en la base de datos debido a que Hibernate evita que en una misma sesión existan dos elementos con el mismo identificador, por lo tanto, no es posible realizar una copia del estado del objeto antes de la actualización para su posterior restauración, en este caso, la aplicación mostrará un mensaje informando sobre el error presentado.

66

3.3.4 Desarrollo de la funcionalidad de registro, seguimiento de ejemplares y pedigrí.

Para la implementación del seguimiento del pedigrí del ejemplar se vio la necesidad de utilizar ambos motores de bases de datos. Los registros de información general del ejemplar y el manejo del árbol genealógico se implementaron utilizando el motor de base de datos orientada a grafos Neo4j; el carnet de vacunación que se debe adjuntar al ejemplar se almacenó en la base de datos relacional debido a que de manera nativa puede almacenar este registro ya que soporta un tipo de dato para el almacenamiento del fichero.

3.3.5 Reuniones por Sprint y retrospección

En el Sprint 2 se alcanzaron a hacer dos reuniones del equipo Scrum, en la primera

de ellas se determinó como debería ser la configuración del entorno de desarrollo, se revisó la documentación relacionada con bases de datos distribuidas y se decidió utilizar el protocolo Two Phase Commit al tratarse de una transacción distribuida a través de dos modelos (relacional y orientado a grafos).

En la segunda reunión se revisaron los artefactos producidos durante el desarrollo del Sprint, se acordó implementar un mecanismo de compensación adicional al protocolo para eludir inconsistencias en la base de datos en caso de presentarse un error. Finalmente se encontró que las funcionalidades asignadas para este Sprint cumplían con los criterios de aceptación de la historia de usuario y que con el estado del prototipo el usuario estaría en capacidad de iniciar sesión y alimentar la aplicación con ejemplares con su respectivo pedigrí. En la figura 14 se muestra el mapa de navegación de la aplicación con las funcionalidades implementadas en el Sprint 2.

Figura 14 Mapa de navegación de las funcionalidades hasta el Sprint 2

67

3.4 Desarrollo del Sprint 3

SPRINT 3

ACTIVIDADES

Creación del módulo de seguimiento de consultas médicas. Implementación de la funcionalidad que permite asociar

múltiples hallazgos y constantes fisiológicas. Implementación del registro y consulta diagnósticos asociados

a las consultas médicas. Implementación de la gestión y asociación de tratamientos a los

diagnósticos.

ENTREGABLES

Prototipo con la funcionalidad de seguimiento médico implementada.

Mapa de navegación actualizado. Código documentado (Javadoc).

DURACIÓN 4 semanas

3.4.1 Creación del módulo de seguimiento de consultas médicas Este Sprint tuvo como objetivo implementar el módulo de seguimiento a consultas

médicas las cuales dan parte del historial clínico del ejemplar. Dentro de las tareas asociadas a las actividades estuvo la creación de las tablas de consulta médica, diagnóstico, hallazgos, constantes y otras asociadas a tratamientos como lo son vacuna, desparasitación, medicación, cirugía y examen. Los registros de las consultas médicas se almacenan únicamente dentro de la base de datos relacional por lo que los DAO’s de este módulo se configuraron con el framework Hibernate únicamente.

Dentro de una consulta médica pueden ser asignados múltiples diagnósticos

dependiendo los síntomas que presente el ejemplar, a dicho diagnóstico pueden ser asignadas múltiples actividades; algunas de ellas manejan un estado de activo para que el criador tenga conocimiento de las que se encuentran en curso (dietas, medicaciones y acciones correctivas). Las consultas médicas pueden ser marcadas como relevantes para tenerlas en cuenta en el momento del cruce y traerlas a relación para evitar que se realicen aquellos que podrían conllevar a problemas en la camada.

El manejo de los medicamentos asociados a vacunas, desparasitaciones y

medicaciones se hizo únicamente teniendo en cuenta el principio activo, los medicamentos se listan en función al tipo de actividad que desee realizar el ejemplar.

3.4.2 Reuniones del Sprint y retrospección En el Sprint 3 se alcanzaron a realizar dos reuniones del equipo Scrum, en la primera

de estas reuniones se acordó como sería la implementación del manejo de consultas

68

médicas, manejo de constantes fisiológicas, hallazgos médicos y actividades relacionadas con la consulta. En la segunda reunión se revisaron los artefactos producidos con el avance de este módulo. Finalmente, en el análisis retrospectivo se comprobó que las funcionalidades implementadas cumplieran con los criterios de aceptación de las historias de usuario, se discutió cómo el manejo de la información nutricional se derivará de la consulta médica al tratarse de una actividad derivada de un diagnóstico. En la figura 15 se muestra el mapa de navegación actualizado con las funcionalidades implementadas hasta el Sprint 3.

Figura 15 Mapa de navegación de las funcionalidades implementadas hasta el Sprint 3

3.5 Desarrollo del Sprint 4

SPRINT 4

ACTIVIDADES Codificación de la funcionalidad para asociar una dieta como tratamiento a un diagnóstico.

69

Levantamiento de información de productos nutricionales a manejar en la aplicación.

Alimentación de alimentos y tipos en la aplicación. Implementación de la funcionalidad para el registro y consulta

de las dietas del ejemplar.

ENTREGABLES

Prototipo con la funcionalidad de seguimiento de dietas. Base de datos con la información de los alimentos utilizados en

el criadero. Mapa de navegación actualizado. Código documentado (Javadoc).

DURACIÓN 3 semanas

3.5.1 Gestión de dietas como tratamiento. El desarrollo de este módulo inició con la codificación de las clases de persistencia

asociadas al proyecto y los Managed Beans. El seguimiento nutricional del ejemplar se realiza por medio del registro de dietas que son prescritas por un diagnóstico, un ejemplar puede tener varias dietas activas al mismo tiempo. En respuesta a la necesidad planteada por la historia de usuario HU_NU_01 el usuario podrá consultar el histórico del peso del ejemplar a través del tiempo con el fin de que tenga las herramientas para tomar decisiones o conclusiones sobre las dietas asignadas.

Para la correcta creación de las dietas, fue necesaria la alimentación de la base de

datos con múltiples marcas, alimentos y su tipo asociado. Una dieta solo puede estar asociada con un único alimento, ya que cada una es configurada con una cantidad de ración y un medio de administración en particular. Las dietas del ejemplar pueden visualizarse por medio de la consulta de cada ejemplar, se dispuso una pestaña para que el usuario pueda conocerlas y observar la gráfica con el progreso de su peso.

3.5.2 Reuniones del Sprint y retrospección.

Durante el transcurso del Sprint se hizo solamente una reunión en la que se trató el tema de cómo debería ser creado el módulo y de qué manera el usuario debería poder observar la información nutricional. En la retrospección del Sprint se revisó que las funcionalidades esperadas del módulo funcionaran correctamente y cumpliera con los criterios de aceptación de las historias de usuario asociadas, que los artefactos se hubieran generado correctamente y finalmente, se hizo una revisión general de la aplicación hasta el momento con motivo de estar seguros de que todas las funcionalidades requeridas para el módulo de cruce ya estuvieran disponibles. En la figura 16 se muestra el mapa de navegación actualizado con las funcionalidades implementadas hasta el Sprint 4.

70

Figura 16 Mapa de navegación de las funcionalidades implementadas hasta el Sprint 4

3.6 Desarrollo del Sprint 5

SPRINT 5

ACTIVIDADES

Codificación de la funcionalidad para el cálculo de COI, COR, eficacia y tasa de mortalidad.

Implementación de búsqueda de consultas relevantes para cruces.

Implementación de búsqueda de camadas en común entre dos ejemplares y camadas previas.

Creación del módulo de comparación de ejemplares para un cruce.

71

Codificación de la funcionalidad para el registro de camadas.

ENTREGABLES

Módulo de información de cruce. Módulo de registro de camadas con sus observaciones

asociadas. Mapa de navegación actualizado. Código documentado (Javadoc). Prototipo finalizado con el cumplimiento de las historias

de usuario planteadas. DURACIÓN 4 semanas

3.6.1 Cálculo de COI y COR

Para cálculo del coeficiente de inbreeding y de relación se utilizó la base de datos orientada a grafos, que simplificó significativamente su obtención debido a la estructura en la que se almacenaron los ejemplares, resultó fácil obtener la longitud de los recorridos de su árbol genealógico a través del grafo para su posterior tratamiento por medio de la ecuación (1). Para la implementación del cálculo del coeficiente de inbreeding se siguió la sugerencia encontrada en una página web que contiene temas relacionados con el cálculo del coeficiente de consanguinidad (Thordal, 2017). A continuación de muestra la consulta utilizada en el motor Neo4j para el cálculo del COI.

Figura 17 Consulta para el cálculo del COI

La consulta recibe los dos ejemplares que serán identificados con las variables a y b, su configuración se hace en las líneas 2 y 3 respectivamente. En la línea 4 se buscan todos los ancestros hasta una distancia de cinco generaciones entre los ejemplares; es necesario separar las relaciones de un ejemplar del otro hasta el ancestro el común para posteriormente sumarlas tal como se hace en la línea 5. Finalmente, en la línea 6 se retorna la longitud del camino asociada al ejemplar en común que se encontró a través del recorrido, valores que son utilizados en la ecuación (1) para obtener el coeficiente de inbreeding.

La obtención del coeficiente de relación se calcula haciendo uso de la ecuación 2, que

utiliza tanto el coeficiente de inbreeding como el de kinship, que es obtenido utilizando la misma consulta mostrada en la figura 17.

72

3.6.2 Búsqueda de consultas relevantes

Haciendo uso del atributo que establece una consulta médica como relevante para el cruce, se creó la funcionalidad que permite su obtención y consulta para mostrarlas en el resumen de la cruza; de igual manera se mostrarán aquellos tratamientos que se encuentren activos, como por ejemplo una medicación o una acción correctiva. En la figura 88 se puede observar la manera en la que se muestran los datos.

3.6.3 Búsqueda de camadas.

Otro elemento importante a la hora de reunir la información más relevante para la toma

de decisiones por parte del criador es contar con la capacidad de buscar las camadas previas que los ejemplares tengan en común y aquellas que hayan tenido con otros ejemplares, de manera que pueda observar los resultados previos obtenidos a partir de cruces (figura 93).

3.6.4 Comparación de ejemplares para el cruce

Finalmente, al contar con todos los datos considerados relevantes al momento de hacer un cruce, se implementó la funcionalidad clave del prototipo que consiste en tomar dos ejemplares y crear un cuadro con la información de cada uno por medio de la cual el criador podrá tomar la decisión de continuar o no con el cruce. Los registros mostrados en esta ventana se observan en la figura 88 y se listan a continuación:

Información básica del ejemplar: nombre, edad, peso, color y patrón de pelaje,

color de ojos, nivel de actividad y temperamento. Coeficiente de inbreeding y relación entre los dos ejemplares. Camadas previas de cada uno de los ejemplares y camadas en común. Consultas médicas relevantes para el cruce y tratamientos activos.

3.6.5 Registro de camadas

El registro de camadas es la última funcionalidad que se implementa y solo puede ser

accedida mediante el cuadro de comparación de ejemplares para el cruce debido a que se consideró que era la mejor manera de crear el hábito en el criador de revisar toda la información relacionada con los progenitores antes de proceder a un cruce.

Para registrar una camada primero se deben registrar los ejemplares en el sistema con

sus respectivos progenitores, posteriormente cuando el usuario seleccione ambos ejemplares para el cruce y haga clic en registrar camada, el sistema automáticamente cargará los ejemplares asociados como progenie y permitirá registrar las observaciones, el número de no natos, la fecha del cruce y los coeficientes de COI y COR serán registrados automáticamente por el sistema para evitar su posterior cálculo. En la figura

73

94 se puede ver el listado de camadas asociadas a un ejemplar junto con los registros mencionados.

3.6.6 Reuniones del Sprint y retrospección.

Durante el desarrollo de este Sprint se realizaron dos reuniones del equipo Scrum. En

la primera de ella se revisaron qué requisitos eran necesario para implementar la funcionalidad de resumen de ejemplares a cruzar y se revisó como se haría el cálculo de los coeficientes de inbreeding y relación. En la segunda reunión se revisó que en efecto se contara con todos los elementos para realizar el resumen del cruce y qué elementos se mostrarían.

La retrospección del Sprint fue bastante corta ya que, al tratarse de la última de ellas,

los temas a tratar sobre el futuro del desarrollo fueron detalles mínimos, ya que se concluyó que todas las funcionalidades esperadas del prototipo fueron implementadas según las pruebas realizadas sobre cada caso de uso trabajado a través de cada Sprint. En la figura18 se muestra el mapa de navegación actualizado con las funcionalidades implementadas en su totalidad.

Figura 18 Mapa de navegación con las funcionalidades implementadas hasta el Sprint 5.

74

3.7 Pruebas de la aplicación

Al finalizar el desarrollo se realizaron las pruebas de todas las funcionalidades del prototipo para verificar su correcta implementación. Para esta labor se hizo uso de datos de prueba alimentados bajo la supervisión de un médico veterinario asesor.

El plan de pruebas consistió en tomar cada historia de usuario con el objetivo de

comprobar el cumplimiento de los criterios de aceptación propuestos para cada una de ellas. Para probar todas las funcionalidades se utilizó un usuario con rol “médico veterinario” a excepción de la creación de usuario, ya que esta acción está permitida únicamente para el usuario administrador de la aplicación. En el anexo 3 se muestra el detalle de cómo se realizó cada prueba y los resultados obtenidos, organizándolas por el conjunto de funcionalidades asociadas a los módulos mostrados en la tabla 3 de la siguiente manera:

5.4.1 Autenticación y registro de usuarios. 5.4.2 Creación del ejemplar. 5.4.3 Búsqueda y consulta de ejemplares. 5.4.4 Manejo de consultas médicas. 5.4.5 Información nutricional. 5.4.6 Módulo de cruces. 5.4.7 Registro y consulta de camadas.

Para las pruebas realizadas sobre la funcionalidad de creación de ejemplares se ingresaron 105 animales con sus respectivos datos y su pedigrí, se evidenció que la información se almacenó exitosamente en cada una de las bases de datos gracias a la implementación del protocolo Two Phase Commit. Durante la alimentación de los registros de manera manual no se generó ningún error que impidiera que los datos fueran almacenados de manera correcta. A 10 de los ejemplares registrados les fueron asociadas en total 40 consultas médicas con diferentes diagnósticos presuntivos y actividades asociadas para su tratamiento. En las pruebas de funcionamiento se evidenció que la información se registró exitosamente en la base de datos relacional. Durante las pruebas de cruce se compararon 35 parejas configurando su árbol genealógico con ejemplos encontrados en textos académicos (Snustad y Simmons, 2015) para verificar que el cálculo se estuviera realizando de manera correcta. Los tipos de parentesco que se probaron fueron: full siblings, half siblings, double first cousins, first cousins y uncle-niece. Se registraron 18 camadas asociando sus respectivos coeficientes, crías y datos requeridos, encontrando que los registros fueron persistidos en la base de datos orientada a grafos de manera exitosa.

75

En las pruebas relacionadas con el tiempo requerido para el cálculo de los coeficientes de inbreeding y relación, se encontró que su obtención no representó un impacto negativo en el uso de la herramienta. No hubo necesidad de realizar su cálculo en un número de generaciones superior a 10, debido a que la cantidad con la que fue alimentada la aplicación no superaba este número siendo el máximo 4 generaciones. 3.8 Resultados obtenidos con el desarrollo del proyecto

Los resultados obtenidos a través del desarrollo del presente proyectos son:

Prototipo de software con nombre BreedingApp disponible para el despliegue en un servidor Amazon Web Services disponible en la url: http://13.59.194.220:8080/BreedingApp/ En el prototipo se implementaron las siguientes funcionalidades:

o Autenticación y registro de usuarios. o Registro y consulta de la información asociada al pedigrí del ejemplar

incluyendo los datos de su árbol genealógico. o Registro y consulta de consultas médicas realizadas al ejemplar,

diagnósticos y las sus actividades asociadas como lo son: vacunas, desparasitaciones, acciones correctivas, medicaciones, exámenes y cirugías.

o Registro y consulta de información nutricional relacionada con dietas suministradas y visualización del histórico de peso del ejemplar mediante una gráfica.

o Cálculo de coeficientes de inbreeding, relación y efectividad de la población.

o Visualización de datos relevantes para la toma de decisiones al momento de cruzar dos ejemplares como lo son: información básica asociada al documento de pedigrí, coeficientes COI y COR, temperamento del ejemplar, nivel de actividad, resultados de camadas previas con sus respectivos coeficientes y consultas que el médico veterinario considero relevantes para la cruza.

o Registro y consulta de camadas con el número de no natos, porcentajes COI y COR, observaciones del cruce y finalmente la fecha del cruce por medio de la cual se calcula la duración del periodo de gestación de la camada.

Artefactos relacionados con el desarrollo:

o 17 historias de usuario y 4 historias técnicas para un total de 21. o 1 diagrama de contexto. o 1 diagrama de arquitectura de la aplicación. o 1 diagrama entidad relación. o 1 diagrama relacional con 24 tablas. o 1 diagrama de grafo etiquetado con 5 nodos y 6 relaciones.

76

o 4 mapas de navegación asociados a las fases de desarrollo. o 7 diagramas de clases. o 1 diagrama de secuencia de la implementación del protocolo 2PC. o 13 bocetos de interfaz gráfica. o Elementos de java: 7 páginas, 2 plantillas, 8 beans, 11 utilidades, 17

objetos de acceso a datos, 39 entidades, 8 excepciones personalizadas. o 1 archivo de modelos creado mediante la herramienta Enterprise

Architect. o 1 manual de instalación y despliegue del prototipo. o 1 vídeo que muestra las funcionalidades del prototipo o 1 manual de usuario.

77

4. CONCLUSIONES

Durante el desarrollo del presente prototipo se utilizó una base de datos orientada a grafos para almacenar el árbol genealógico de los ejemplares, decisión que resultó muy conveniente debido a la simplificación del cálculo del coeficiente de inbreeding que requirió recuperar la longitud de los trayectos desde los ejemplares hasta los ancestros en común por medio de una consulta corta y fácil de entender. De lo anterior podemos concluir que es de vital importancia la adecuada elección del modelo de la base de datos con la estructura que se va a persistir a través de ella.

El prototipo desarrollado permite el seguimiento del pedigrí del ejemplar y el historial

médico por medio de consultas clínicas, enfocándose en los aspectos más relevantes al momento de realizar un cruce, por lo tanto, se constituye como una herramienta de apoyo a criadores y médicos veterinarios en la toma de decisiones al considerar cruzar dos ejemplares. Con base en la información registrada, porcentajes COI, COR y resultados de camadas previas, el usuario tendrá más razones para continuar o evitar la cruza, con el fin de eludir o facilitar la replicación de algunas condiciones sobre la progenie de los ejemplares, haciendo especial énfasis en su bienestar más que en replicar características morfométricas asociadas a razas.

La utilización de múltiples sistemas gestores de bases de datos en una misma

aplicación requiere de especial atención en cuanto al cumplimiento de las propiedades ACID, debido a que se podría dar lugar a inconsistencias en caso de que la atomicidad de las transacciones se vea comprometida. En el desarrollo del presente proyecto se optó por la implementación del protocolo Two Phase Commit que permite el manejo de excepciones para evitar inconsistencias y garantizar la atomicidad de la transacción distribuida.

La implementación de un mecanismo de compensación al final de la segunda fase del

protocolo Two Fase Commit, permite manejar ciertos escenarios que podrían dar lugar a inconsistencias en las bases de datos, por lo que es importante determinar de qué manera las herramientas a utilizar interfieren con la ejecución de dichos mecanismos. En este caso en particular se encontró que Hibernate no permite la existencia de dos objetos obtenidos mediante misma sesión que compartan su identificador (primary key), por lo que no fue posible manejar algunas excepciones presentadas en la actualización de registros. Este escenario podría ser manejado utilizando control de cambios en los elementos de las bases de datos y finalmente realizando el registro de mensajes entre el coordinador de la transacción y los participantes, para facilitar la posterior recuperación del estado de consistencia de la base de datos haciendo uso de métodos heurísticos. Para que se de esta situación tendría que ocurrir una falla tan seria como para comprometer el protocolo 2PC sin impedir la ejecución del mecanismo de compensación lo que tendría una probabilidad de ocurrencia muy baja.

78

El uso de la metodología Scrum permitió planear y ejecutar de una manera sencilla, organizada y rápida el proceso de desarrollo, ya que, entre otras ventajas, no hubo necesidad de tener total claridad de los detalles de todas las funcionalidades desde una primera instancia, sino que debido a su flexibilidad para el manejo de los cambios permitió que algunos de ellos se pudieran definir sobre la marcha. Otra de las ventajas fue la generación progresiva de entregables, lo que permitió contar con un nuevo módulo disponible para su uso al finalizar cada uno de los Sprints.

La utilización del framework Java Server Faces junto con las interfaces de

programación de aplicaciones (API) Hibernate y el OGM de Neo4j, permitieron que el desarrollo del prototipo se hiciera de una manera práctica y rápida debido a que cuentan con herramientas que evitan la codificación manual de ciertas funcionalidades. Los mapeadores de datos asistieron el proceso de creación de los POJOs junto con sus anotaciones y los componentes disponibles en PrimeFaces permitieron que las plantillas del cliente se crearan fácilmente sin necesidad de utilizar directamente lenguajes como html, css, Javascript y librerías como JQuery y AJAX.

79

5. TRABAJO FUTUROS

El desarrollo de esta tesis tuvo como resultado la creación de un prototipo de software que constituye una herramienta de apoyo a criadores y médicos veterinarios en el proceso de cruce de felinos domésticos, con el fin controlar y reducir la cantidad de alteraciones presentadas en los ejemplares de la progenie. Durante el proceso se identificaron algunas funcionalidades que podrían ser implementadas a partir del presente proyecto las cuales se mencionan a continuación:

El presente prototipo se basa en principios que pueden ser aplicados a

diferentes especies, con algunas modificaciones la aplicación podría ser utilizada en otros animales domésticos y posteriormente en especies silvestres.

Por cuestiones de seguridad sería conveniente tener el log de las modificaciones realizadas sobre las características del ejemplar y sus consultas médicas asociadas, por lo que la aplicación podría contar con un sistema de control de cambios y su respectiva asociación con el usuario que los realizó.

Caracterización del fenotipo del ejemplar mediante el genotipo teniendo en cuenta el carácter recesivo y dominante. Lo anterior podría facilitar el seguimiento de alteraciones morfométricas y estimar su probabilidad de aparición en productos de cruces.

La implementación para su uso en especies silvestres podrá constituir una herramienta de apoyo en programas de reproducción para especies que se encuentran en peligro de extinción.

Buscar patrones de asociación entre fenotipos y afecciones presentadas en los ejemplares con el fin de encontrar relaciones que ayuden a evitar ciertos cruces.

Evaluar e implementar el cálculo de los coeficientes COI Y COR en un número superior a 10 generaciones con el fin de analizar la exactitud del cálculo en árboles genealógicos más extensos y su impacto en el rendimiento.

80

5. ANEXOS 5.1 Anexo 1: Modelo de clases aplicación.

Figura 19 Diagrama de clases de gestión de usuarios y sesión.

81

Figura 20 Diagrama de clases de la gestión de ejemplares.

82

Figura 21 Diagrama de clases de la gestión de consultas médicas.

83

Figura 22 Diagrama de clases de hallazgos y constantes fisiológicas.

84

Figura 23 Diagrama de clases de diagnóstico y actividades (cirugías, exámenes y acciones correctivas)

85

Figura 24 Diagnósticos y actividades (medicaciones, dietas, vacunas, desparasitaciones)

86

Figura 25 Diagrama de clases de la funcionalidad de resumen de cruces y camadas

87

5.2 Anexo 2: Diagrama de secuencia de la implementación del Protocolo 2PC.

Figura 26 Diagrama de secuencia del protocolo Two Phase Commit

88

5.3 Anexo 3: Bocetos de interfaz gráfica.

Figura 27 Boceto de búsqueda de ejemplares.

89

Figura 28 Boceto de detalle del ejemplar y del árbol genealógico.

90

Figura 29 Boceto de detalle del ejemplar con información médica.

91

Figura 30 Boceto del detalle del ejemplar e información nutricional.

92

Figura 31 Boceto del detalle del ejemplar y la información de las camadas.

93

Figura 32 Boceto del formulario de consulta médica.

94

Figura 33 Boceto de formulario de registro de hallazgos y constantes fisiológicas.

95

Figura 34 Boceto del formulario de diagnósticos y detalles finales de la consulta.

96

Figura 35 Bocetos de ventanas emergentes de actividades, cirugía, vacuna y desparasitación.

97

Figura 36 Bocetos de ventanas emergentes de registro de actividades de acción correctiva, medicación y dieta.

98

Figura 37 Boceto del resumen del cruce y camadas de la hembra.

99

Figura 38 Boceto del resumen de cruce y las consultas relevantes del macho.

100

Figura 39 Boceto del formulario de detalle de una camada.

101

5.4 Anexo 4: Pruebas funcionales de la aplicación.

Para las pruebas funcionales del aplicativo se utilizó un ambiente local donde se ejecutó la aplicación, con un usuario con rol de “médico veterinario” se registró la información en los diferentes módulos de la aplicación la cual se alimentó haciendo uso de datos de prueba con la ayuda de un médico veterinario y criador de felinos domésticos.

A continuación, se muestran las pruebas funcionales correspondientes a las historias

de usuario: HU_GL_01: Autenticación de usuario. HU_LG_02: Aplicación web.

5.4.1 Autenticación de usuarios

Se accedió a la aplicación a través del siguiente enlace: - http://localhost:8080/BreedingApp Una vez cargada la página, se escribe el usuario y contraseña el formulario de

autenticación, posteriormente se da clic en el botón ingresar.

Figura 40 Página de inicio de la aplicación

Una vez autenticado se muestra en la esquina superior derecha el nombre del usuario autenticado la página de inicio de la aplicación es la del buscador de ejemplares.

Figura 41 Módulo de búsqueda de ejemplares.

102

5.4.1.1 Registro de usuario: Para el registro de usuarios, una vez autenticados con un usuario con el rol de

Administrador, se da clic en el botón Registrar de la parte superior que se observa en la figura 40, una vez cargada la página, se puede visualizar el formulario de registro.

Figura 42 Formulario de registro de nuevo usuario.

En el formulario de registro de usuario se muestra un diálogo que indica el nivel de seguridad de la contraseña, una vez diligenciada toda la información, se da clic en el botón Registrar.

Figura 43 Registro de un nuevo usuario.

Al finalizar la operación de registro de manera exitosa se muestra un mensaje de confirmación.

103

Figura 44 Registro exitoso del usuario.

Para cerrar sesión, se hace clic sobre el nombre del usuario autenticado y se elige la

opción Salir.

Figura 45 Cierre de sesión de usuario.

Una vez cerrada la sesión la aplicación redirige a la página de inicio de sesión en donde él usuario recién creado podrá iniciar sesión con las credenciales registradas.

Figura 46. Sesión iniciada con el usuario registrado.

104

5.4.2 Creación de ejemplares

Las siguientes pruebas se realizaron para comprobar el cumplimiento de las historias de usuario:

HU_GE_01: Registro y seguimiento de ejemplares. HU_GE_02: Registro y consulta de pedigrí.

Una vez autenticados en la aplicación, desde la página de inicio se da clic en el botón

“Buscador de ejemplares” que se encuentra en la parte superior derecha de la pantalla.

Figura 47 Plantilla de búsqueda de ejemplares.

Al cargar la página, se muestra el formulario de búsqueda, su tabla de resultados, y el botón por medio del cual se puede crear un ejemplar, posteriormente se da clic en este elemento.

105

Figura 48 Botón para crear ejemplar en la plantilla de búsqueda de ejemplares

Posteriormente se muestra el formulario para la creación del ejemplar.

Figura 49 Formulario de creación de ejemplar.

Para ingresar el fenotipo, basta con escribir un color o patrón de pelo y la aplicación mostrará los resultados aproximados para que el usuario les seleccione fácilmente.

Figura 50 Selección del fenotipo.

106

En la parte superior del formulario, se da clic en el botón ‘Buscar’ del campo relacionado con la madre para seleccionar el respectivo ejemplar.

Figura 51 Botón de búsqueda de la madre.

En cuadro de búsqueda, se da clic al botón buscar para mostrar la lista de ejemplares hembra en estado activo, luego se selecciona el ejemplar, y se da clic al botón ‘Seleccionar’ para asignar la madre del nuevo ejemplar.

Figura 52 Formulario de búsqueda de la madre.

Una vez seleccionado, se muestra el nombre del ejemplar en el campo Madre, se repite el proceso de igual manera para elegir al Padre, haciendo clic el correspondiente. Estos cuadros de búsqueda filtran los ejemplares por macho y hembra según corresponda.

107

Figura 53 Madre y padres seleccionados.

Una vez seleccionados el padre y la madre se muestran sus nombres en los campos correspondientes, posteriormente se da clic en la imagen para habilitar la carga de fotos.

Figura 54 Área disponible para la foto del ejemplar.

A continuación, la aplicación muestra el botón ‘Cargar Foto’, se hace clic en él y se selecciona una foto del sistema de archivos.

Figura 55 Selección de la foto del ejemplar.

108

Una vez seleccionada la foto, el nombre del archivo se muestra junto al botón cargar.

Figura 56 Foto cargada en la aplicación.

A continuación, se da clic en el botón ‘Cargar carnet’ para asignar el archivo PDF correspondiente al carnet de vacunación del ejemplar.

Figura 57 Carga del carnet de vacunación.

Una vez seleccionado el documento, se muestra el nombre del archivo junto al botón.

109

Figura 58 Formulario totalmente diligenciado para la creación del ejemplar.

Con el formulario totalmente diligenciado, se da clic en el botón ‘Guardar’ que se encuentra en la parte inferior derecha para almacenar los datos en las respectivas bases de datos. Al terminar este proceso el sistema muestra un mensaje confirmando que la operación se realizó exitosamente.

Figura 59 Confirmación del éxito de la creación del ejemplar.

5.4.3 Búsqueda y consulta de ejemplares La siguiente prueba se relaciona con la historia de usuario: HU_GE_02: Registro y consulta del pedigrí.

Para realizar la búsqueda de un ejemplar, se ingresa a la sección ‘Buscador de

Ejemplares’ a través del botón ubicado en la parte superior derecha. Se diligencian los campos que cumplan con el criterio de búsqueda de elección del usuario.

110

En la tabla de resultados se muestran los ejemplares que reunan las características

diligenciadas en el formulario.

Figura 60 Búsqueda de un ejemplar.

Se da clic en el nombre del ejemplar en la tabla de resultados para ver el detalle del ejemplar.

Figura 61 Consulta del detalle de un ejemplar.

En el menú lateral izquierdo se da clic en el botón ‘Árbol genealógico’ para ver la información asociada a los progenitores del ejemplar.

111

Figura 62 Árbol genealógico del ejemplar.

5.4.4 Consultas médicas de los ejemplares.

Las siguientes pruebas de funcionamiento se ejecutaron sobre los casos de uso:

HU_CM_01: Seguimiento de consultas médicas. HU_CM_02: Registro y consulta de constantes fisiológicas y hallazgos clínicos. HU_CM_03: Registro y consulta de diagnósticos. HU_CM_04: Registro y consulta de tratamientos.

Para las siguientes pruebas se contaban con los ejemplares registrados en la base de

datos y se realizaron con un usuario médico veterinario.

5.4.4.1 Creación de una consulta médica

Para crear la consulta médica de un ejemplar se debe acceder al detalle de información del pedigrí como se mostró en la sección de búsqueda y consulta de ejemplares.

En el menú lateral izquierdo, se da clic a la opción Información médica, luego en el botón Crear Consulta Médica.

Figura 63 Módulo de información médica.

112

La alimentación de información de la consulta médica está dividida por pasos, el primer paso es ingresar la información de las constantes fisiológicas como se muestra en la siguiente imagen.

Figura 64 Registro de constantes fisiológicas.

Una vez alimentados los datos de constantes fisiológicas se hace clic en el botón ‘Siguiente’ y se procede a registrar los hallazgos de la consulta.

Figura 65 Registros de hallazgos.

Luego de diligenciar los datos de hallazgos, se da clic al botón ‘Siguiente’, acción que dirige a la sección donde se muestran las opciones para agregar diagnósticos con sus respectivas actividades y agregar anexos a la consulta médica.

En esta página se muestra una tabla con los diagnósticos presuntivos agregados a la

consulta médica y una con los anexos, los campos para ingresar el diagnóstico definitivo,

113

el pronóstico, la fecha del próximo control y marcar la consulta médica como relevante para tener en cuenta a la hora de realizar un cruce con otro ejemplar.

Figura 66 Diagnósticos de una consulta.

Para agregar un diagnóstico presuntivo se da clic en el botón ‘Agregar Diagnóstico’.

Figura 67 Función para agregar diagnóstico.

Al hacer clic en la acción indicada, aparece un nuevo registro a la tabla de diagnósticos presuntivos, se da clic al icono editar de la primera columna para ingresar los datos requeridos.

Figura 68 Formulario de creación de diagnóstico presuntivo.

Para crear el diagnóstico presuntivo se da clic en el icono guardar de la primera columna, luego para la asociación de actividades se selecciona el diagnóstico creado y se hace clic en la opción ‘Ver Actividades’.

114

Figura 69 Selección del diagnóstico creado.

Las actividades que se pueden asignar a un diagnóstico presuntivo son: Desparasitación, Vacuna, Cirugía, Examen, Medicamento y Dieta. El detalle de su creación se muestra en las siguientes secciones, en la siguiente imagen se muestra la ventana desde donde se ingresan las diferentes actividades asociadas al diagnóstico.

Figura 70 Pantalla de creación de actividades.

5.4.4.2 Creación de desparasitación

Para la creación de una desparasitación se hace clic en el botón ‘Agregar

Desparasitación’, aparece entonces una nueva línea, al hacer clic en el ícono de edición se pueden ingresar los datos de la actividad.

Figura 71 Creación de una desparasitación.

115

5.4.4.3 Creación de cirugía

Para la creación de una cirugía se hace clic en el botón ‘Agregar Cirugía’, aparecerá entonces una nueva línea que luego de seleccionarla y al hacer clic en el ícono de edición permite ingresar los datos de la actividad. Las cirugías permiten agregar un adjunto del resultado o documentación asociada, se hace de manera similar a cuando se sube una foto del ejemplar.

Figura 72 Creación de cirugía.

5.4.4.4 Creación de Vacuna

Para la creación de una vacuna se hace clic en el botón ‘Agregar Vacuna, aparecerá

entonces una nueva línea que luego de seleccionarla y al hacer clic en el ícono de edición permite ingresar los datos de la actividad.

Figura 73 Creación de una vacuna.

116

5.4.4.5 Creación de examen Para la creación de un examen se hace clic en el botón ‘Agregar Examen’, aparecerá

entonces una nueva línea que luego de seleccionarla y al hacer clic en el ícono de edición permite ingresar los datos de la actividad. Los exámenes posibilitan agregar un adjunto del resultado o documentación asociada, se hace de manera similar a cuando se sube una foto del ejemplar.

Figura 74 Listado de exámenes.

5.4.4.6 Creación de medicación

Para la creación de una medicación se hace clic en el botón ‘Agregar Medicación’,

aparecerá entonces una nueva línea que luego de seleccionarla y al hacer clic en el ícono de edición permite ingresar los datos de la actividad. Las medicaciones pueden estar en estado activo o inactivo lo que indicaría si actualmente se le está suministrando el medicamento.

Figura 75 Creación de una medicación.

5.4.4.7 Creación de acción correctiva

Para la creación de una acción correctiva se hace clic en el botón ‘Agregar acción

correctiva’, aparecerá entonces una nueva línea que luego de seleccionarla y al hacer clic en el ícono de edición permite ingresar los datos de la actividad. Las acciones

117

correctivas pueden estar en estado activo o inactivo lo que indicaría si actualmente se le está ejecutando esta acción en el ejemplar.

Figura 76 Creación de una acción correctiva.

5.4.4.8 Creación de anexo

Para crear un anexo asociado a la consulta médica, se da clic al botón ‘Agregar Anexo’, lo que adiciona una nueva fila a la tabla, luego se da clic en el botón editar de la primera columna para ingresar la información.

Figura 77 Área de anexos.

Una vez ingresados los datos, se da clic en el botón guardar de la primera columna para almacenar la información, a continuación, se usa el selector de la última columna para seleccionar el anexo, luego se da clic en el botón agregar archivo para adjuntar un documento al anexo.

Figura 78 Selección de un anexo.

En la ventana de dialogo, se da clic en el botón seleccionar archivo, se elige el documento y una vez cargado, se elige la opción ‘cerrar’ para volver al formulario de la consulta.

118

Figura 79 Selección de archivo a adjuntar como anexo.

El documento adjuntado podrá consultarse a través del botón de descarga creado para este fin.

Figura 80 Descarga de un documento adjunto.

5.4.4.9 Guardar consulta medica

Para finalizar la creación de la consulta médica, luego de ingresar los datos de

constantes fisiológicas, hallazgos, diagnósticos presuntivos y anexos, se ingresan los datos de diagnóstico definitivo, pronóstico y próximo control.

119

Figura 81 Consulta médica totalmente diligenciada.

Una vez ingresados estos datos, se da clic al botón Guardar en la parte inferior derecha

de la pantalla, finalmente se muestra un mensaje de confirmación indicando que la consulta fue almacenada exitosamente.

5.4.4.10 Ver consultas médicas del ejemplar

Para ver las consultas médicas de un ejemplar el primer paso es buscarlo por medio del módulo creado para este fin, una vez seleccionado haciendo clic en su nombre, se elige la opción “Información médica” que contiene el listado de las consultas.

Figura 82 Lista de consultas médicas asociadas al ejemplar.

Al hacer clic en ‘Ver consulta médica’ se podrán acceder a sus detalles registrados. 5.4.5 Seguimiento nutricional

Las siguientes pruebas tienen como intención probar la implementación de las

funcionalidades relacionadas con las historias de usuario:

120

HU_NU_01: Historial nutricional de los ejemplares. HU_NU_02: Alimentación de la plataforma con alimentos utilizados. HU_NU_03: Consulta de ración y alimento.

Las dietas se asocian a diagnósticos presuntivos, de manera que para su creación se

debe seleccionar el diagnóstico que genera esta actividad para posteriormente crearla mediante la opción ‘Agregar dieta’.

Figura 83 Creación de una dieta.

Para la asignación del alimento a la dieta se realiza su búsqueda por la marca, en este caso en particular se digitó Hills en la entrada del alimento, luego en la lista de resultados se seleccionó el alimento de nombre ‘Kitten development’ de tipo seco.

Figura 84 Selección del alimento a usar en la dieta.

Luego se da clic en el botón guardar para asociar la dieta al diagnóstico. 5.4.5.1 Consultar información nutricional

Para ver la información nutricional de un ejemplar, se consulta por medio de la página

de búsqueda destinada para este fin, luego se da clic en la tabla de resultados para ver

121

los detalles, en el menú lateral izquierdo se selecciona la opción de información nutricional en donde se muestra la lista de dietas activas asociadas al ejemplar. Adicionalmente se muestra un gráfico con el histórico de pesos registrados a través de las consultas médicas con las que se ha alimentado la aplicación.

Figura 85 Información nutricional del ejemplar.

5.4.6 Módulo de cruces

Las siguientes pruebas tienen como intención probar la implementación de las funcionalidades relacionadas con las historias de usuario:

HU_CR_01: Cálculo de COI, COR, eficacia y mortalidad. HU_CR_02: Cálculo de camadas previas. HU_CR_03: Resumen de datos de ejemplares para cruces. HU_CR_04: Registro de camadas. HU_CR_05: Consulta de información médica relevante para el cruce. HU_CR_06: Consulta de camadas en común de los ejemplares.

Para ejecutar estas pruebas se debe contar con los ejemplares a cruzar registrados

en la aplicación, su información de pedigrí, consultas médicas y camadas registradas.

5.4.6.1 Información relevante para el cruce.

Para el uso de esta funcionalidad se puede acceder a través del botón de la parte superior derecha de la aplicación.

122

Figura 86 Pantalla inicial del área de cruces

El primer paso es seleccionar el macho y hembra a cruzar por medio de sus respectivos botones de búsqueda.

Figura 87 Búsqueda de la hembra.

Figura 88 Búsqueda del macho.

Una vez seleccionados los dos ejemplares se puede observar la información de cada uno de ellos como el estado reproductivo, temperamento, raza, fenotipo, color de ojos y la foto en caso de tenerla; además se puede descargar el carnet de vacunación de cada uno de ellos y se pueden conocer los valores del COI y COR entre ambos ejemplares.

123

Figura 89 Resumen de información de ejemplares para el cruce.

5.4.6.2 Consultas relevantes para él cruce. En el menú lateral izquierdo se encuentran múltiples opciones todas ellas relacionadas

con el resumen del cruce, por medio de ella se pueden ver las consultas médicas más relevantes de cada uno de los ejemplares.

Figura 90 Consultas médicas relevantes en el macho

Como se puede observar el macho tiene dos consultas marcadas como relevantes mientras que la hembra ninguna, el criador puede abrir el detalle de la consulta para obtener mayor información del estado médico del ejemplar.

Figura 91 Consultas médicas relevantes para la hembra.

5.4.7 Creación de camada

El registro de una camada se puede realizar únicamente después de utilizar el módulo de cruces para la comparación entre los ejemplares, en donde luego de ser seleccionados se podrá utilizar el botón ‘Crear camada’ por medio del cual el usuario es dirigido al formulario de registro de camada en donde ingresa datos como la fecha del cruce, número de no natos, y finalmente observaciones asociadas.

124

Para cargar los ejemplares se debe escribir la fecha de nacimiento y la aplicación traerá los ejemplares que nacieron asociados con los progenitores seleccionados.

Figura 92 Formulario de registro de camada.

Una vez diligenciados los datos, y seleccionadas las crías de la camada, se da clic en el botón guardar. Al finalizar la operación, aparece un mensaje de confirmación indicando que la información de la camada fue guardada.

Figura 93 Camada creada exitosamente.

5.4.7.1 Visualización de las camadas de un ejemplar

Para visualizar las camadas en las que ha participado un ejemplar, se busca y consulta

su detalle y en el menú lateral izquierdo se selecciona la opción ‘Camadas’. Se puede ver la lista de camadas del ejemplar donde se muestra la fecha del cruce, la pareja, los coeficientes COI y COR asociados, número de crías, número de no natos y el tiempo de gestación.

Figura 94 Camadas de un ejemplar.

125

Al hacer clic en el botón ‘Ver’ de una de ellas, se carga el detalle de la camada en pantalla donde adicionalmente se podrán ver las observaciones y el listado de las crías, las cuales se podrán consultar para ver el detalle de cada una.

5.4.7.2 Visualización de la camada a la que pertenece el ejemplar

Para visualizar la información de la camada a la cual pertenece un ejemplar específico,

se da clic en el botón ‘Ver camada del ejemplar’, ubicado en la parte superior de la pantalla de detalle del ejemplar, posteriormente el usuario será dirigido a la página en donde se mostrará la información solicitada.

Figura 95 Botón para ver la camada del ejemplar.

5.3.7.3 Visualización de camadas en pantalla de cruce En la pantalla de cruce, al seleccionar dos ejemplares se puede acceder en el menú

lateral izquierdo a la lista de camadas de cada uno de los ejemplares y las que tienen en común entre sí.

Ilustración 96 Camadas en común entre dos ejemplares.

126

Lista de referencias Fine, A. h. (Ed.). (2011). Handbook on Animal-Assisted Therapy: Theoretical Foundations

and Guidelines for Practice. San Diego, California: Academic Press. McMinn, B. (Ed.). (2009). The Cat Breeder’s Handbook. Oroville, California, U.S.A: TIBCC

Publications. Pedersen, N. C., & Pratt, P. W. (1991). Feline Husbandry: Diseases and Management in

the Multiple-cat Environmen. U.S.A: American Veterinary Publications, Inc. Gough, A., & Thomas, A. (2004). Breed Predispositions to Disease in Dogs and Cats.

Blackwell Publishing. Hartwell, S. (2003-2015). Messybeast Portal. Recuperado el 10 de Diciembre de 2015,

de A HISTORY OF CAT SHOWS IN BRITAIN: http://messybeast.com/showing.htm Hartwell, S. (2005). Messybeast Portal. Recuperado el 11 de Diciembre de 2015, de A

BRIEF HISTORY OF SCIENTIFIC BREEDING OF CATS (GENETICS): http://messybeast.com/retro-genetics.htm

López Romero, A. P. (11 de Noviembre de 2015). (J. D. Carranza Leguizamo, & J. L. Vanegas Prieto, Entrevistadores) Bogotá, Colombia.

Wright, S. (1931). Evolution in Mendelian populations. Genetics, 16(2), 97-159. (s.f.). Gould, L. L. (1996). Cats are Not Peas: A Calico History of Genetics. A K Peters/CRC

Press. Defining architecture. (2015). Recuperado el 17 de Diciembre de 2015, de Systems and

software engineering — Architecture description ISO/IEC/IEEE 42010: http://www.iso-architecture.org/ieee-1471/defining-architecture.html

Arias, Á., & Durango, A. (2016). Ingeniería y Arquitectura del Software: 2ª Edición. IT Campus Academy.

Buxton, J. N., & Randel, B. (Edits.). (1969). SOFTWARE ENGINEERING TECHNIQUES. Conference sponsored by the NATO SCIENCE COMMITTEE (pág. 130). Roma: NATO Science Committee.

Sommerville, I. (2005). Ingeniería de Software 7ma Edición. Madrid, España: Pearson Educación.

Fowler, M., Rice, D., Foemmel, M., Hieatt, E., Mee, R., & Stafford, R. (2002). Patterns of Enterprise Application Architecture. Addisson Wesley.

Qian, K. (2010). Software Architecture and Design Illuminated. Sudbury, Massachusetts, U.S.A: Jones & Bartlett Learning.

Mukhar, K., Zelenak, C., Weaver, J. L., & Crume, J. (2006). Beginning Java EE 5: From Novice to Professional. U.S.A: Apress.

Grove, R. F. (2009). Web Based Application Development. U.S.A: Jones & Bartlett Learning.

Menascé, D. A., & Fernandes de Almeida, V. A. (2000). Scaling for E-business: Technologies, Models, Performance, and Capacity Planning. U.S.A: Prentice Hall Professional.

Jimenez Peris, R., Patiño Martínez, M., Kemme, B., Pérez Sorrosal, F., & Serrano, D. (2 de Noviembre de 2009). A system of architectural patterns for scalable, consistent

127

and highly available multi-tier service-oriented infrastructures. Architecting Dependable Systems, 6(VI), 335.

McKnight, W. (2014). Information Management: Strategies for Gaining a Competitive Advantage with Data. U.S.A: Elsevier.

Zhu, W.-D., Gupta, M., Kumar, V., Perepa, S., Sathi, A., & Statchuk, C. (2014). Building Big Data and Analytics Solutions in the Cloud. International Technical Support Organization. International Business Machines Corporation.

Coronel, C., Morris, S., & Rob, P. (2016). Database Systems: Design, Implementation, & Management. U.S.A: Course Technology, Cengage Learning.

Robinson, I., Webber, J., & Eifrem, E. (2015). Graph Databases, New opportunities for connected data. U.S.A: O’Reilly.

Robinson, I. (25 de Agosto de 2014). Ian Robinson on Neo4j's History, Data Structure and Use Cases. (C. Humble, Entrevistador) Obtenido de http://www.infoq.com/interviews/ian-robinson-neo4j

Mullins, C. S. (Junio de 2015). InfiniteGraph enterprise distributed graph database overview. Recuperado el 19 de Diciembre de 2015, de SearchDataManagement Website: http://searchdatamanagement.techtarget.com/feature/InfiniteGraph-enterprise-distributed-graph-database-overview

Jarrell, J. (20 de Mayo de 2010). Infinitegraph Interview. Obtenido de http://www.objectivity.com/support/resources/infinitegraph-interview-jay-jarrell/.

MattersNoSQL. (8 de Febrero de 2012). AvocadoDB explained. Recuperado el 21 de Diciembre de 2015, de Vimeo: https://vimeo.com/36411892

Rubin, K. S. (2012). Essential Scrum: A Practical Guide to the Most Popular Agile Process. U.S.A: Addison-wesley signature series.

Schwaber, K., & Sutherland, J. (Julio de 2013). The Definitive Guide to Scrum: The Rules of the Game. Recuperado el 3 de Enero de 2016, de Scrumguides: http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

Schwaber, K. (2004). Agile Project Management with Scrum. Microsoft Press. Takeuchi, H., & Nonaka, I. (Enero de 1986). The New New Product Development Game.

Recuperado el 04 de Enero de 2016, de Harvard Business Review: https://hbr.org/1986/01/the-new-new-product-development-game#

Ettinger, S. J., & Feldman, E. C. (2009). Textbook of Veterinary Internal Medicine (Vol. 1). Canada: Elsevier Health Sciences.

Gross, J. L., & Yellen, J. (2004). Handbook of Graph Theory. CRC Press. Canós, J. H., Letelier, P., Penadés, M. C., & 2. (2003). Métodologías Ágiles en el

Desarrollo de Software. http://ima.udg.edu/Docencia/07-08/3105200728/TodoAgil.pdf.

Principios del Manifiesto Ágil. (2001). Recuperado el 05 de Enero de 2016, de Manifesto for Agile Software Development: http://www.agilemanifesto.org/iso/es/principles.html

Dingsøyr, T., Nerur, S., Balijepally, V., & Moe, N. B. (Junio de 2012). A decade of agile methodologies: Towards explaining agile software development. Journal of Systems and Software, 85, 1213–1221. doi:10.1016/j.jss.2012.02.033.

128

Amaya Balaguera, Y. D. (Julio de 2013). Metodologías ágiles en el desarrollo de aplicaciones para dispositivos móviles. Estado actual. Revista de tecnología, Journal of Technology, 12(2), doi: http://dx.doi.org/10.18270/rt.v12i2.1291.

Kirby, G., de Kerckhove, C., Shumailov, I., Carson, J., Dearle, A., Dibben, C., & Williamson, L. (Febrero de 2014). Comparing relational and graph databases for pedigree data sets. Workshop on Population Reconstruction.

Sfetcu, N. (2014). About cats. Lulu Enterprises, Inc. Roberts, H. R. (3 de Noviembre de 2007). Basic color/pattern genetics. Recuperado el 5

de Enero de 2016, de The International Cat Association: http://www.tica.org/es/cat-colors

Craft, J. (s.f.). Genes and genetics: the language of scientific discovery. Recuperado el 10 de Enero de 2016, de Oxford English Dictionary: http://public.oed.com/aspects-of-english/shapers-of-english/genes-and-genetics-the-language-of-scientific-discovery/

Eurocatfancy. (2005-2012). Dominance of genes in cats. Recuperado el 12 de Enero de 2016, de Eurocatfancy Website: http://www.eurocatfancy.de/en1/nav/cat-genetics/dominance_of_genes.html

Starr, C., Evers, C., & Starr, L. (2010). Biology: Concepts and Applications. U.S.A: Cengage Learning.

Gould, L. L. (2012). Cats are not Peas: A Calico History of Genetics. U.S.A: Springer Science & Business Media.

Khanna, P. (2010). Essentials of Genetics. Nueva Delhi, India: I. K. International Pvt Ltd. Neale, M. C., & Cardon, L. (2013). Methodology for Genetic Studies of Twins and

Families. Springer Science & Business Media. Cavalli-Sforza, L. L., Moroni, A., & Gianna, Z. (2013). Consanguinity, Inbreeding, and

Genetic Drift in Italy (MPB-39). Princeton, New Jersey, U.S.A: Princeton University Press.

Coleman, W. B., & Tsongalis, G. J. (2009). Molecular Pathology: The Molecular Basis of Human Disease . Academic Press.

Tave, D. (1999). Inbreeding and Brood Stock Management, Número 392. Coos Bay, Oregon, U.S.A: Food & Agriculture Org.

Fox, C. W., Roff, D. A., & Fairbairn, D. J. (2001). Evolutionary Ecology : Concepts and Case Studies. U.S.A: Oxford University Press.

Thornhill, N. W. (Ed.). (1993). The Natural History of Inbreeding and Outbreeding: Theoretical and Empirical Perspectives. U.S.A: University of Chicago Press.

Thiagarajan, R. (2014). Text Book of Animal Breeding. Satish Serial Publishing House. Snustad, D. P., & Simmons, M. J. (2015). Principles of Genetics, Binder Ready Version.

U.S.A: John Wiley & Sons. Frankham, R., Ballou, J. D., & Briscoe, D. A. (2010). Introduction to Conservation

Genetics. Reino Unido: Cambridge University Press. Robinson, R. (2013). Genetics for Cat Breeders: International Series in Pure and Applied

Biology (Vol. 58). Reino Unido: Pergamon. Thakur, V. (2008). ASP.NET 3.5 Application Architecture and Design. Birmingham, Reino

Unido: Packt Publishing. Wilson, E. O. (2000). Sociobiology: The New Synthesis. U.S.A: Harvard University Press.

129

TICA. (2017). CRIADEROS DE LA REGIÓN POR PAISES. Recuperado el 4 de Junio, de The International Cat Association, South American Region: http://ticasaonline.org/criaderos.html

ACFEC. (2017). Criaderos Registrados. Recuperado el 4 de Junio de 2017, de Asociación Club Felino Colombiano: http://www.acfec.co/criaderos/

Animanaturalis. (20 de Diciembre de 2014). En navidad no compres, adopta a un animal de compañía. Recuperado el 16 de Febrero de 2016, de ANIMANATURALIS INTERNACIONAL: http://www.anima.org/n/44059

Maldonado T., J. C. (8 de Octubre de 2012). Ojo a las ventas de animales. Recuperado el 16 de Febrero de 2016, de El Espectador: http://www.elespectador.com/noticias/bogota/ojo-ventas-de-animales-articulo-380129

Escalante Alarcón, P. (16 de Julio de 2015). El ABC de la adopción de mascotas. Recuperado el 17 de Febrero de 2016, de Noticias RCN: http://www.noticiasrcn.com/bienestar-mascotas/el-abc-adopcion-mascotas

Riveros, J. D. (15 de Noviembre de 2015). (J. D. Carranza Leguizamo, & J. L. Vanegas Prieto, Entrevistadores) Bogotá, Colombia.

Mašková, J. (2011). Laws of Inheritance. Recuperado el 10 de Febrero de 2016, de Wikilectures: http://www.wikilectures.eu/index.php/Laws_of_Inheritance

Neo4j. (2016). What is a Graph Database? Recuperado el 19 de Diciembre de 2015, de Neo4j Website: http://neo4j.com/developer/graph-database/#_what_is_neo4j

Breedmate. (2012). Breed Mate Pedigree Software. Recuperado el 14 de Diciembre de 2015, de http://www.breedmate.com/Home/Index

Tenset. (1996-2014). Advanced Genetics. Recuperado el 15 de Diciembre de 2015, de Breeders Asistant: http://www.tenset.co.uk/ba/progenetics.html

ArangoDB. (s.f.). Documentación ArangoDB. Recuperado el 20 de Diciembre de 2015, de ArangoDB v2.8.5 Documentation: https://docs.arangodb.com/

Infinitegraph. (s.f.). Creating and Updating Data. Obtenido de InfiniteGraph Developer Site: http://wiki.infinitegraph.com/3.4/w/?title=Creating_and_Updating_Data

Objectivity. (2016). INDUSTRY USE CASES. Recuperado el 20 de Diciembre de 2015, de Objectivity Website: http://www.objectivity.com/solutions/use-cases/

KippenJungle. (s.f.). Kruising Kat. Recuperado el 2016 de Diciembre de 2015, de KippenJungle: http://kippenjungle.nl/kruisingKat.html

Spellbound's. (2012). Maine Coon/Color Calculator. Recuperado el 15 de Diciembre de 2015, de Spellbound's Maine Coon: http://www.mainecoons.no/english/mainecoon_colorcalculator.html

Persians, P. (2004-2016). Persian Cat Color Calculator. Recuperado el 16 de Diciembre de 2015, de Pelaquita Persians: http://www.pelaqitapersians.com/persian-cat-color-calculator.php

ZooEasy. (2016). List of all Features. Recuperado el 15 de Diciembre de 2015, de ZooEasy: http://www.zooeasy.com/features/list-features/#filter

The Institute of Canine Biology. (2012-2017). How many generations of pedigree data should you use to estimate inbreeding. Recuperado el 4 de Junio de 2017, de: http://www.instituteofcaninebiology.org/blog/how-many-generations-of-pedigree-data-should-you-use-to-estimate-inbreeding

130

Oracle. (2017). List of JDBC faq. Recuperado el 4 de Junio de 2017, de Oracle:

http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-faq-090281.html

Oracle. (2017). JavaServer Faces technology. Recuperado el 4 de Junio de 2017, de Oracle: http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html

JBoss. (2017). List of hibernate features. Recuperado el 4 de Junio de 2017, de JBoss: https://tools.jboss.org/features/hibernate.html

Kagilum SAS. (2017). IceScrum features. Recuperado el 4 de Junio de 2017, de IceScrum: https://www.icescrum.com/features/

ArangoDB. (s.f.). Subscriptions ArangoDB. Recuperado el 21 de Diciembre de 2015, de ArangoDB Website: https://www.arangodb.com/subscriptions/

Keith, C. (2010). Agile Game Development with Scrum. Pearson Education. Philip A. B., Newcomer E. (2009). Principles of transaction processing.--2nd ed.

Burlington, USA: Elsevier. Elliott J. O'Brien T. M., Fowler R. (2008) Harnessing Hibernate: Step-by-Step Guide to

Java Persistence. USA: O'Reilly Media, Inc. Hewitt E. (2011) Cassandra: The Definitive Guide. USA: O'Reilly Media, Inc. Liu H. H. (2011) Software performance and scalability: A quantitative aproach. New

Jersey: IEEE computer society. Neo4j. (2017). What is a OGM? Recuperado el 16 de Abril de 2017, de Neo4j Website:

https://neo4j.com/docs/ogm-manual/current/introduction/ Konda M. (2014) Just Hibernate: A lightweight introduction to the hibernate framework.

USA: O'Reilly. Babativa G. A. M., Briceño N. P. D. (2015) Desarrollo de un prototipo de software móvil

para implementar un taxímetro enfocado al control del servicio. Proyecto de grado. Bogotá, Colombia. Universidad distrital Francisco José de Caldas.

Prajapati Y., Ranapariya V. (2015) Java Hibernate Cookbook. Birmingham, UK: Packt Publishing.

Ottinger B. J., Linwood J., Minter D. (2016) Beginning Hibernate. Youngsville, North Carolina, USA: Apress.

Thordal S. (2017). Graphs and geneaology finding inbred nobles with neo4j. Recuperado el 1 de Abril de 2017, Simon Thordal Website: https://simonthordal.github.io/neo4j/2016/12/22/Graphs-and-Geneaology-Finding-inbred-nobles-with-Neo4j/