análisis dinámico del balance de flujos metabólicos (dfba)
DESCRIPTION
Tesis investigativa sobre el anális dinámico del balance de flujos metabólicosTRANSCRIPT
Universidad de Pinar del Río
“HERMANOS SAÍZ MONTES DE OCA”
Facultad de Ciencias Técnicas.
Departamento de Informática.
Trabajo de Diploma
Sistema de Escritorio para Simulaciones Dinámicas (dFBA)
en Redes Metabólicas
(Tesis en opción al título de Ingeniero en Informática)
Autor: Jean Carlos Soto González
Tutores: MSc. Vinelia Córdova Vásquez
MSc. Julián Triana Dopico
Pinar del Río, 2012
i
“Cuando se es joven, se crea. Cuando se es
inteligente, se produce. No se adapta, se innova: la
medianía copia; la originalidad se atreve.”
José Martí
ii
FACULTAD DE CIENCIAS TÉCNICAS.
DEPARTAMENTO DE INFORMÁTICA.
Luego de estudiada la exposición del diplomante
________________________, así como la opinión de los tutores y el
oponente del presente trabajo de diploma, el tribunal emite la calificación de
_____ puntos.
_______________________ _______________________
Presidente del Tribunal Secretario
_______________________
Vocal
Dado en la Universidad de Pinar del Río Hermanos Saíz Montes de Oca a los
___días del mes de __________ del 2012.
iii
DECLARACIÓN DE AUTORIDAD
Declaro que soy autor(a) de este Trabajo de Diploma y que autorizo a la Universidad
de Pinar del Río, a hacer uso del mismo, con la finalidad que estime conveniente.
Firma: __________________________________
Jean Carlos Soto González [email protected]
Jean Carlos Soto González autoriza la divulgación del presente trabajo de diploma bajo
licencia Creative Commons de tipo Reconocimiento No Comercial Sin Obra Derivada, se
permite su copia y distribución por cualquier medio siempre que mantenga el reconocimiento
de sus autores, no haga uso comercial de las obras y no realice ninguna modificación de
ellas. La licencia completa puede consultarse en: http://creativecommons.org/licenses/by-nc-
nd/2.5/ar/legalcode
Jean Carlos Soto González autoriza al Departamento de Informática adscrito a la Universidad
de Pinar del Río a distribuir el presente trabajo de diploma en formato digital bajo la licencia
Creative Commons descrita anteriormente y a conservarlo por tiempo indefinido, según los
requerimientos de la institución, en el repositorio de materiales didácticos disponible en:
http://repoinfo.upr.edu.cu
Jean Carlos Soto González autoriza al Departamento de Informática adscrito a la Universidad
de Pinar del Río a distribuir el presente trabajo de diploma en formato digital bajo la licencia
Creative Commons descrita anteriormente y a conservarlo por tiempo indefinido, según los
requerimientos de la institución, en el repositorio de tesinas disponible en:
http://revistas.mes.edu.cu
iv
AGRADECIMIENTOS
A mis padres, por estos 25 años, por su apoyo, amor, confianza y su fe…
A mi hermana, por su cariño, su comprensión, por ser mi amiga y siempre estar…
A mi abuela Lula por su bondad sin límites…
A mi familia toda…
A ti MI AMOR por los mejores cinco años de mi vida, y todos los que vendrán, por las
sonrisas cuando te pienso, por los nervios cuando te veo, por la alegría en el corazón
y la felicidad en mi interior…
A Zura (La Ampolla), Nereida (La Gordis y sus cabezas), Claudia y Camila, por
abrirme las puertas de su casa y de su vida y hacerme sentir de la familia…
A Vinelia y Julián, mis tutores, por su guía y su ayuda, y la confianza depositada…
A la Profe Caridad por ayudarme a buscar y a encontrar…
A la Profe Malena por sus críticas siempre constructivas y bien recibidas…
A Adiel porque las mil preguntas que le hice siempre encontraron respuesta…
A mis amigos de la UCI…
A Yonita por ser la mejor amiga del mundo… A Rosita por ser tan especial… A la
Diva por ser tan autentica…A Tatiana, A Dianella, a todos…
A mis amigos de la UPR, por acogerme, por incluirme; por estos tres buenos años…
A mis profesores de la UCI, Yaimí aunque nunca lo sepas es mucho lo que te debo,
porque lo que bien se aprende, nunca se olvida, y lo que se enseña con amor, queda
en el corazón.
A mi profesores de la UPR…
A todos aquellos que han dejado huella en vida y que aunque no siempre nos veamos
guardo con cariño su recuerdo…
Muchas Gracias.
v
DEDICATORIA
A mi Madre querida,
que me dure toda la vida.
vi
RESUMEN
Antecedentes
En septiembre del año 2002, gracias al trabajo de Radhakrishnan Mahadevan,
Jeremy S. Edwards, Francis J. Doyle III, presentado en el Biophysical Journal,
volumen 83, (1331-1340); bajo el título: “Dynamic Flux Balance Analysis of Diauxic
Growth in Escherichia coli”, la comunidad científica y el público interesado en general
contó con una extensión del FBA clásico, capaz de responder a la dinámica de las
redes metabólicas (dFBA). Dos formulaciones matemáticas fueron presentadas, una
aproximación estática (SOA) y una dinámica (DOA), como alternativas para resolver
un mismo problema, obteniéndose resultados similares. dFBA representó una
significativa ventaja sobre el FBA y rápidamente se convirtió en una útil herramienta
para el análisis cuantitativo.
Resultados
El propósito de esta investigación fue concebir, diseñar e implementar una aplicación
informática, que siguiendo los algoritmos descritos por la aproximación estática
(SOA), fuera capaz de realizar simulaciones del comportamiento y evolución dinámica
de una ruta metabólica, aplicando el dFBA.
Para el diseño del software se siguieron las pautas dictadas por el Proceso Unificado
de Desarrollo (RUP), la herramienta CASE utilizada fue el Enterprise Architect, y la
implementación se llevó a cabo en el lenguaje de programación CSharp (C#).
Conclusiones
Se obtuvo un Sistema de Software “HYDRA dFBA”, amigable, interactivo, y fiable,
con el cual es posible importar modelos en un formato ampliamente estandarizado
(SBML) y sobre ellos realizar simulaciones dinámicas, con el objetivo de predecir o
comprobar situaciones y/o comportamientos, mediante la aplicación del dFBA.
Palabras claves: dFBA, SOA, simulación, red metabólica.
vii
SUMMARY
Antecedents
On september, 2002, thanks to the work of Radhakrishnan Mahadevan, Jeremy S.
Edwards, Francis J. Doyle, III, presented at the Biophysical Journal, volume 83,
(1331-1340): “Dynamic Flux Balance Analysis of Diauxic Growth in Escherichia coli”,
the scientific community and interested public got an extension for classical FBA, able
to respond for dynamics situations (dFBA). Two different formulations for dynamic
FBA were presented, Static Optimization Approach (SOA) and Dynamic Optimization
Approach (DOA), both as a way to solve a problem, getting similar results. dFBA
provides a significant improvement over the classical FBA and quickly became in an
useful quantitative analysis tool.
Results
This investigation was made to conceive, design and implement informatics solution,
which follows the algorithms described by the Static Optimization Approach (SOA),
allowing to carry out behavior and evolution simulations over a metabolic network,
applying dFBA.
Rational Unified Process (RUP), was applied for the design of the software, Enterprise
Architect, was the CASE tool used for modeling, and the code was written using
CSharp (C #) programming language.
Conclusions
A System of Software, “HYDRA dFBA”, friendly, interactive, and reliable, was
obtained. Whit this tool is possible to load wide standard format (SBML) models and
carry out dynamic simulations over them, to predict or to check situations and/or
behaviors, using dFBA.
Key words: dFBA, SOA, simulation, metabolic network.
viii
TABLA DE CONTENIDOS
INTRODUCCIÓN ..................................................................................................................... 1
CAPÍTULO I: FUNDAMENTACIÓN TEÓRICA ........................................................................ 9
Introducción .......................................................................................................................... 9
1.1. Biología de sistemas. ..................................................................................................... 9
1.2 . El metabolismo celular ................................................................................................ 11
1.2.1. Representación matemática del metabolismo celular ............................................ 12
1.3. Análisis de Balance de Flujos (FBA) ............................................................................ 13
1.4. Análisis Dinámico del Balance de Flujos (dFBA) ......................................................... 16
1.4.1. Aproximación de Optimización Dinámica (DOA) ................................................... 16
1.4.2. Aproximación de optimización estática (SOA) ....................................................... 18
1.5. Sistemas afines ........................................................................................................... 19
1.6. Análisis de Factibilidad ................................................................................................ 20
1.7. Modelo de Dominio ...................................................................................................... 21
1.7.1. Conceptos que se utilizan en el Modelo de Dominio ............................................. 22
Conclusiones del Capítulo .................................................................................................. 24
CAPÍTULO II: CARACTERIZACIÓN DE LA SOLUCIÓN PROPUESTA ............................... 25
2.1. Caracterización de la metodología y herramientas para el diseño .............................. 25
2.1.1. Proceso Unificado de Desarrollo (RUP) ................................................................ 26
2.1.2. Lenguaje Unificado de Modelado (UML) ............................................................... 29
2.1.3. Herramientas Case. Enterprise Architect .............................................................. 30
2.2. MATLAB ...................................................................................................................... 32
2.3. Solver GLPK ............................................................................................................... 33
2.4. Requerimientos del sistema ........................................................................................ 34
2.4.1. Requisitos Funcionales ......................................................................................... 34
2.4.2. Requisitos no Funcionales .................................................................................... 40
2.5. Trazabilidad Requerimiento Funcional- Caso de Uso .................................................. 41
2.5.1. Cargar y Presentar el Modelo ................................................................................ 42
2.5.2. Navegabilidad ....................................................................................................... 43
ix
2.5.3. Simulación ............................................................................................................ 43
2.6. Actores del Sistema ..................................................................................................... 45
2.7. Casos de Uso del Sistema .......................................................................................... 45
2.7.1. Modelo de Casos de Uso del sistema ................................................................... 46
2.7.2. Resumen de los casos de uso principales............................................................. 47
2.8. Patrones de diseño ...................................................................................................... 50
2.9. Diagrama de Clases del Diseño (DCD) ....................................................................... 52
2.9.1. DCD del paquete Modelo ...................................................................................... 54
2.9.2. DCD del paquete Simulación ................................................................................ 55
2.9.3. DCD del paquete Presentación ............................................................................. 56
Conclusiones del capítulo ................................................................................................... 57
CAPÍTULO III: IMPLEMENTACIÓN DE LA SOLUCIÓN PROPUESTA ................................ 58
Introducción ........................................................................................................................ 58
3.1. Lenguaje de Marcado Extensible (XML) ...................................................................... 58
3.2. Lenguaje de Marcado para Sistema Biológicos (SBML) .............................................. 59
3.3. Plataforma .NET .......................................................................................................... 61
3.3.1. Lenguaje de programación C Sharp (C#) .............................................................. 62
3.4. Implementación de la interfaz de usuario..................................................................... 64
3.4.1. Interfaz de usuario ................................................................................................ 65
3.4.2. Interfaz Inicial ........................................................................................................ 66
3.4.3. Interfaz para la presentación del Modelo ............................................................... 67
3.4.4. Interfaz del área de simulación .............................................................................. 67
3.4.5. Otras interfaces ..................................................................................................... 68
3.5. Tratamiento de errores ................................................................................................ 69
3.6. Estándares de Codificación ......................................................................................... 69
3.7. Modelo lógico de datos ................................................................................................ 71
3.8. Modelo Físico de los Datos.......................................................................................... 72
3.9. Modelo de Implementación .......................................................................................... 74
3.10. Modelo de Despliegue ............................................................................................... 75
x
3.11. Implementación de la Ayuda ...................................................................................... 76
Conclusiones del capítulo ................................................................................................... 77
CONCLUSIONES .................................................................................................................. 78
RECOMENDACIONES .......................................................................................................... 79
REFERENCIAS BIBLIOGRÁFICAS ...................................................................................... 80
BIBLIOGRAFÍA ........................................................................ ¡Error! Marcador no definido.84
ANEXOS ................................................................................................................................ 88
ANEXO I ANÁLISIS DE FACTIBILIDAD ............................................................................ 88
ANEXO II: LICENCIA CeCILL V2 ....................................................................................... 96
ANEXO III: MATRIZ DE TRAZABILIDAD REQUERIMIENTOS-CASOS DE USO .............. 97
ANEXO IV ESPECIFICACIÓN DE LOS CASOS DE USO MÁS SIGNIFICATIVOS .......... 100
ANEXO V: DIAGRAMAS DE COLABORACIÓN DE LOS CASOS DE USO MAS
SIGNIFICATIVOS ............................................................................................................. 135
ANEXO VI: DIAGRAMAS DE SECUENCIA DE LOS CASOS DE USO MÁS
SIGNIFICATIVOS ............................................................................................................. 139
ANEXO VII: INTERFACES DE LA APLICACIÓN ............................................................. 147
ANEXO VIIII: MÉTRICAS DEL CÓDIGO DE LA APLICACIÓN......................................... 154
ANEXO X: CASOS DE PRUEBA ...................................................................................... 155
INTRODUCCIÓN
1
INTRODUCCIÓN
El término Computación Científica, como una de las ramas de Las Ciencias de la
Computación, se refiere a todas aquellas prácticas destinadas a modelar, plantear
experimentos y validar teorías científicas, sirviéndose de medios computacionales
para avanzar en campos objetivos como la física, la mecánica de fluidos y la
biología.( Yang X. S., 2008).
La Biología Computacional por su parte, se designa como el uso de algoritmos y
ordenadores para facilitar el entendimiento de complejos problemas biológicos,
abarcando universos ya establecidos como son: bioquímica, matemáticas, ingeniería
de sistemas, etc. Algunos campos de estudio interdisciplinarios muy vinculados, y que
en ocasiones se usan como sinónimos son Biocomputación y Bioinformática (Bajic et
al., 2003).
Según una de sus definiciones, la Bioinformática es un campo de la ciencia en el cual
confluyen varias disciplinas tales como: biología, computación y tecnología de la
información, con el fin de facilitar el descubrimiento de nuevas ideas biológicas así
como crear perspectivas globales a partir de las cuales se puedan identificar
principios unificadores en biología (National Center for Biotechnology Information,
2001). La magnitud de las escalas con que se trabaja sobrepasa con creces la
capacidad humana para discernir, razón por la cual el núcleo principal de estas
técnicas, se encuentra en la utilización de recursos computacionales para solucionar
o investigar tales problemas.
La investigación en biología computacional se solapa a menudo con la Biología de
Sistemas (BS), que abarca la investigación interdisciplinaria de los procesos
biológicos, donde las interacciones de los elementos, internos y externos influyentes
en el desarrollo de los procesos, se analizan matemáticamente, permitiendo
comprender a partir de un análisis holístico el funcionamiento integral de los sistemas
biológicos, dando a los especialista la posibilidad de profundizar en el entendimiento
de cómo sus interacciones internas y con otros sistemas conllevan a la potenciación
de algunas propiedades y a la emergencia de otras nuevas (Snoep et al. 2006).
La BS analiza el funcionamiento global de las células, centrándose en el sistema en
su conjunto, sobre las partes. Con el advenimiento de las técnicas experimentales de
INTRODUCCIÓN
2
alto rendimiento se ha alcanzado un importante grado de desarrollo, materializándose
los modelos en los que el conjunto de reacciones que tienen lugar en una célula se
representan de manera análoga a una red eléctrica o de comunicaciones, así como
todo un conjunto de herramientas para operar sobre dichas redes (Snoep et al. 2006).
La presente investigación forma parte del intercambio científico y la colaboración
entre el Grupo Interdisciplinario de Modelización , InterTech (www.intertech.upv.es),
vinculado al Instituto Universitario de Matemática Pura y Aplicada de la Universidad
Politécnica de Valencia, España y el Grupo Interdisciplinario de Modelización ,
InterTech, de la Universidad de Pinar del Río, Cuba, con el objetivo de generar
sinergias en áreas de alta prioridad en la investigación, y donde la colaboración actual
se basa en la línea emergente de la Biología Sintética (McDaniel y Weiss, 2005).
El avance futuro de esta disciplina científica pasa por establecer un marco
computacional y conceptual que dé asistencia en el desarrollo de sistemas biológicos
artificiales modulares, basándose en una metodología ingenieril y sistemática, para lo
que se necesita proveer a la próxima generación de diseñadores en Biología
Sintética y a los futuros biotecnólogos e ingenieros biológicos de nuevas herramientas
computacionales, integradas en un entorno común para el análisis de fenotipos
metabólicos, el diseño de nuevos circuitos genéticos complejos y la visualización de
mapas metabólicos.
HYDRA (Hybrid Draw and Routes Analysis) es una plataforma informática orientada
al diseño, análisis y visualización de redes metabólicas, que integrará un grupo de
herramientas correspondientes tanto a la Biología de Sistemas como a la Biología
Sintética, diseñadas por el grupo de investigación InterTech, facilitando a los biólogos
la organización y sistematización mediante el uso intensivo de herramientas
Bioinformáticas , de la gran cantidad de resultados que se producen con los métodos
automatizados para el tratamiento de la información biológica, empleados en la
actualidad. Asociadas a la Biología de Sistema HYDRA proporcionará las siguientes
herramientas ( Triana Dopico, et al., 2011):
INTRODUCCIÓN
3
FBA: Para el Análisis del balance de flujo.
RNA: Dirigido al Análisis de robustez de redes.
DFBA: Una versión dinámica del FBA
MOMA: Simulador de eliminación de genes.
FVA: Análisis de Variabilidad de flujos.
HEFM: Análisis de las posibles distribuciones de flujo.
Relacionadas con la Biología Sintética disponibles en HYDRA, estarán:
FRANKY: Para el diseño automático de circuitos genéticos con una
funcionalidad dada.
KNOCK-IN: Dirigido a la Evaluación de posibles knock-in del sistema.
OS (Orthology Study): Útil en el estudio de una vía metabólica en varios
organismos determinando la conservación de los genes.
SYMCOM (Symbiotic Commuties). Analizador de comunidades de organismos.
El reciente desarrollo de la Genómica a partir del empleo de métodos de
secuenciación más potentes, así como la implementación de los microarrays de
genes, trajo consigo un vertiginoso cúmulo de información de las redes genéticas de
muchos microorganismos. Hoy en día uno de los usos más frecuente de esta
información se ha enfocado en el estudio del comportamiento integrado de las redes
celulares. Una de las áreas de investigación ha sido el estudio de las redes
metabólicas (Mahadevan, et al., 2002).
Los métodos analíticos y experimentales para entender la naturaleza de la
distribución de flujos en una red metabólica, junto con las técnicas de biología
molecular para la ingeniería genética, ayudan en el diseño de las redes de
reacciones metabólicas (Stephanpoulos, 1999).
El análisis matemático del metabolismo puede guiar el proceso de la ingeniería
metabólica, de ahí que varios acercamientos cuantitativos se han propuesto para
estudiar las rutas metabólicas. Análisis de Control Metabólico MCA (Metabolic Control
Analysis) (Fell, 1996), Teoría de Sistemas Bioquímicos (Savageau, et al., 1987),
INTRODUCCIÓN
4
Modelación Cibernética (Kompala, 1984) (Varner, et al., 1999) y Análisis de Balance
de Flujos (FBA) (Varma, et al., 1994) . Son algunos de los algoritmos desarrollados
para este fin. Con la excepción del FBA, estos acercamientos requieren una
formulación funcional para la cinética de las reacciones celulares (Mahadevan, et al.,
2002).
El FBA es una aproximación que restringe la red metabólica basada en la
estequiometría de las reacciones y que no requiere de información cinética (Varma, et
al., 1994). La optimización de una función objetivo, como puede ser el índice de
crecimiento de un sistema biológico, es usada para obtener la distribución de flujos
metabólicos que satisface las restricciones. Este método ha demostrado proveer
significativas predicciones en la Escherichia coli (Varma, et al., 1994). La extensión
del FBA para responder a la dinámica de las redes metabólicas es conocida como
dFBA (Mahadevan, et al., 2002).
La importancia fundamental del dFBA radica en la capacidad de representar la
evolución de una ruta metabólica bajo determinadas condiciones, cuales substratos
son consumidos, cuales productos son obtenidos y los índices de
consumo/producción que rigen el proceso, dFBA permite apreciar el comportamiento
de la biomasa resultante para restricciones precisas sobre los flujos y predecir las
concentraciones de los metabolitos. El dFBA representa una significativa mejora del
FBA clásico.
Hasta la fecha se cuenta con dos modelos matemáticos para realizar un análisis
dinámico, la aproximación estática (SOA1) (Varma, et al., 1994) y la aproximación
dinámica (DOA2) (Mahadevan, et al., 2002).
El Análisis Dinámico del Balances de Flujos, es una herramienta de análisis de gran
impacto de la Biología de Sistemas, y por tanto un servicio de obligada prestación en
toda plataforma que se quiera llamar integradora, y este orientada a proveer de
herramientas y facilidades a los biólogos y bioquímicos del siglo XXI.
La situación expuesta líneas arriba nos enfrenta al Problema Científico dado por:
Falta de una herramienta, propia del grupo InterTech, para automatizar el dFBA en
1 Static Optimization Approach, modelo matemático que ofrece soluciones para el dFBA.
2 Dynamic Optimization Approach, modelo matemático que ofrece soluciones para el dFBA.
INTRODUCCIÓN
5
redes metabólicas; como parte de los servicios que prestará la plataforma
computacional HYDRA.
Con vistas a la solución del problema que se presenta queda establecido como
Objeto de Estudio de esta investigación: el modelo matemático que garantiza la
realización del dFBA en las redes metabólicas, mediante una aproximación estática
(SOA). Acotando el Campo de acción a: la obtención de soluciones para el modelo
matemático descrito en la aproximación estática (SOA) para el dFBA.
Este proyecto de investigación se realiza con el Objetivo General de: Elaborar un
sistema informático, que, siguiendo los algoritmos descritos por la aproximación
estática (SOA), sea capaz de realizar simulaciones del comportamiento y evolución
de una ruta metabólica, aplicando el dFBA.
Los Objetivos Específicos están orientados en función de:
1. Realizar una revisión bibliográfica que permita conocer el estado del arte en
que se encuentra el dFBA, para sus dos aproximaciones.
2. Levar a cabo un estudio de los sistemas afines que en la actualidad tratan de
dar soluciones a la situación problémica de esta investigación.
3. Diseñar una herramienta computacional, que automatice modelo matemático
descrito por SOA.
4. Desarrollar una herramienta computacional, que automatice modelo
matemático descrito por SOA.
5. Aplicar principios de diseño que garanticen una interfaz gráfica cómoda a los
usuarios.
Los anteriormente numerados, serán cumplidos por medio de la consecución de las
siguientes Tareas:
1. Estudiar los modelos matemáticos que respaldan el dFBA, así como las
herramientas que actualmente automatizan la aproximación estática (SOA).
2. Estudio y selección de las herramientas y lenguajes apropiados para la
ejecución del proyecto.
INTRODUCCIÓN
6
3. Diseñar un proyecto de software que permita obtener un sistema informático
capaz de encontrar soluciones al modelo matemático de la aproximación
estática (SOA) para el dFBA.
4. Desarrollar la aplicación haciendo uso de las herramientas y lenguaje
seleccionados.
Idea a defender: una herramienta que permita realizar análisis dinámicos del
metabolismo celular brindará a la plataforma HYDRA mayor confiabilidad, robustez y
utilidad ante sus usuarios finales.
La informatización del objeto de esta investigación científica se logró a partir de la
aplicación de métodos teóricos, que revelaron sus relaciones esenciales no
observables directamente. Se estudió la BS desde sus inicios, su establecimiento
como ciencia, y el posterior desarrollo alcanzado, que la ha convertido en un área
emergente de alto potencial científico y tecnológico. Donde los análisis de flujos
metabólicos en estados cuasi-estacionarios constituyen un actor importante a tener
en cuenta. Técnica que es posible, en parte, debió a una modelación matemática de
la dinámica metabólica, usada para generalizar y simular el proceso haciendo posible
su resolución, computacionalmente. Y también al conocimiento y comprensión
detallada de la función de los metabolitos y las reacciones químicas dentro de una red
metabólica, como pieza clave para lograr un análisis dinámico del balance de los
flujos metabólicos.
Conjuntamente con los anteriores se usaron métodos empíricos de investigación,
concretamente la medición, por ser el modelo que se estudia, computacionalmente
costoso debido a la gran cantidad de metabolitos y reacciones con las que trabaja,
donde los tiempos de respuesta pueden llegar a determinar no solo la eficiencia sino
la eficacia del software que se propone.
Se acudió a la entrevista como técnica para recopilar información, y aunque estas no
estuvieron estructuradas en cuestionarios, fluyendo más bien como conversaciones
profesionales, fueron de gran utilidad a la hora de investigar campos necesarios para
la realización de este proyecto, por contener al objeto de la investigación; cercanos a
la informática como ciencia, pero lejanos en la práctica a los conocimientos del
informático, como son la Bioinformática, la Biología Sintética, la Biología de Sistemas
y concretamente el metabolismo celular.
INTRODUCCIÓN
7
Se espera que, este documento sea útil y esclarecedor en lo relacionado con el
dFBA, y que pueda ser usado como futura bibliografía en español, ciertamente
escasa en el tema abordado, que el sistema sea lo suficientemente gráfico y amigable
para que su uso se haga fácil a sus usuarios, y sus servicios útiles en el trabajo que
realizan. Sobre todo se desea que el resultado de este trabajo sirva a todos esos
biólogos, bioquímicos ingenieros metabólicos, etc., que dedican sus vidas a la
investigación y a tratar de hacer de este un mundo mejor.
INTRODUCCIÓN
8
Este documento se estructura en tres capítulos:
CAPITULO I: Se detallan los fundamentos teóricos en los que se basa este
proyecto, conceptos fundamentales y un análisis de factibilidad.
CAPITULO II: Se describe la metodología y las herramientas utilizadas para el
diseño así como artefactos típicos de este flujo de trabajo.
CAPITULO III: Se presenta el sistema en término de componentes y
funcionamiento.
Por último las Conclusiones generales, las Recomendaciones, las Referencias
Bibliográficas y la Bibliografía, que expone toda la documentación utilizada para la
realización del proyecto y al final los Anexos que contienen la información
complementaria del trabajo.
CAPÍTULO I
9
CAPÍTULO I: FUNDAMENTACIÓN TEÓRICA
Introducción
En este capítulo se detallan los aspectos referentes a la BS, profundizando en el
metabolismo celular como proceso biológico intrínseco a todos los organismos, se
explica como la BS es capaz predecir comportamientos de este valiéndose de
modelos matemáticos para representarlo y analizarlo, el FBA para una instantánea y
el dFBA para predecir la evolución de las concentraciones de los metabolitos en el
tiempo. Se describen dos aproximaciones posibles para el análisis dinámico, DOA y
SOA, las cuales haciendo uso de la programación no lineal y la programación lineal,
respectivamente, obtienen resultados similares. Se analizan sistemas afines y se
realiza un análisis de factibilidad para el trabajo que se propone.
1.1. Biología de sistemas.
La Biología Molecular de las últimas décadas se ha basado en la teoría que asume el
camino directo existente entre genes, proteínas y función biológica, así como la
presencia de respuestas predeterminadas del sistema a perturbaciones externas.
Aunque este tipo de investigación ha dado lugar a gran cantidad de conocimiento, no
proporciona información acerca de cómo integran las células estos datos de forma
que se genere un tipo de respuesta u otro. A pesar de que la Biología de Sistemas se
considera una nueva disciplina, el abordaje del estudio de los procesos biológicos
como sistemas se trató por Wiener en 1948 en lo que se llamó en aquel momento la
cibernética. La Biología de Sistemas ha sido descrita por investigadores como Leroy
Hood con detalle, aunque el término se empleó por primera vez en 1968 por teóricos
como Mersarovic (Mesarovic, 1968).
La Biología de Sistemas es el campo de investigación interdisciplinario de los
procesos biológicos en el que las interacciones de los elementos, internos y externos,
que influyen en el desarrollo del proceso se representan mediante un sistema
matemático. Este enfoque global permite comprender de forma integrada el
funcionamiento de los sistemas biológicos y profundizar en el entendimiento de cómo
sus interacciones internas y externas (con otros sistemas) conlleva a la aparición de
nuevas propiedades y/o procesos (Pacheco Suárez, 2011).
CAPÍTULO I
10
Convencionalmente, en el estudio de los procesos biológicos se utiliza el método
científico clásico, que se basa en la confirmación o refutación de una hipótesis al
confrontarle con los resultados experimentales. La BS utiliza, sin embargo, un
enfoque distinto, basado en la modelización matemática de los procesos en estudio.
Como resultado de la simulación, al poner a funcionar los modelos matemáticos con
los que se representa el proceso, se obtiene una serie de predicciones del estado del
proceso biológico que corresponderían a los resultados experimentales esperados.
Durante las simulaciones, la red de interacciones entre los elementos que componen
el proceso biológico se representa mediante un sistema de ecuaciones diferenciales.
Los valores de las características de dichos elementos a distintos tiempos y bajo
diversas condiciones experimentales (simuladas), son predecibles debido a que la
dinámica del estado de ese sistema modelado es calculable matemáticamente. La
Biología de Sistemas es un área interdisciplinaria en la que participan biólogos,
químicos, matemáticos, físicos, entre otros.
Esta disciplina emplea una estrategia diferente a las aproximaciones empíricas
tradicionales, por medio del estudio de sistemas biológicos en sus diferentes niveles,
desde células y redes celulares hasta organismos completos. La Biología de
Sistemas implica el mapeo de rutas, interacción de proteínas y genes, así como el de
los circuitos de organismos a nivel celular y de organismos completos, todo ello
integrado en un modelo informático y/o matemático (Pacheco Suárez, 2011)
Principales características de la Biología de Sistemas
Estudia los sistemas biológicos de una forma global, a nivel molecular.
Contrasta con la aproximación clásica lineal (un gen, una proteína).
Integra el conocimiento de diferentes plataformas o disciplinas (genómica,
transcriptómica, proteómica, metabolómica, fisiología, patología, etc.).
Maneja una gran colección de datos procedentes de estudios experimentales.
Propone modelos matemáticos que pueden explicar algunos de los fenómenos
biológicos estudiados.
Proporciona soluciones matemáticas que permiten obtener predicciones para
los procesos biológicos.
CAPÍTULO I
11
Realiza estudios de comprobación de la calidad de los modelos descritos por
medio de la comparación entre las simulaciones numéricas y los datos
experimentales (López, et al., 2007).
1.2 . El metabolismo celular
El término metabolismo deriva del griego μεταβολισμός, significando cambio, o
también llevar más allá, de μετα (Eknoyan, 1999).
La historia del estudio científico sobre el metabolismo puede ser situada 400 años
en el pasado, y parte desde los primeros estudios examinando animales hasta la
investigación de reacciones metabólicas individuales por la bioquímica moderna. El
primer experimento controlado sobre el metabolismo humano fue publicado por
Santorio Santorio en 1614 en su libro Ars de statica medecina (Eknoyan, 1999).
El metabolismo celular es el conjunto de reacciones y procesos físico-químicos que
ocurren en una célula. Estos complejos procesos interrelacionados son la base de
la vida a nivel molecular (Enciclopedia Médica, 2006).
Se divide en dos procesos conjugados: catabolismo y anabolismo. Las reacciones
catabólicas liberan energía, retenida en los enlaces químicos, mediante de la
degradación de compuestos. Las reacciones anabólicas, en cambio, utilizan esta
energía liberada para recomponer enlaces y construir compuestos.
La economía que la actividad celular impone sobre sus recursos obliga a organizar
estrictamente las reacciones químicas del metabolismo en vías o rutas metabólicas,
donde un compuesto químico (sustrato) es transformado en otro (producto), y este
a su vez funciona como sustrato para generar otro producto, siguiendo una
secuencia de reacciones bajo la intervención de diferentes enzimas (Fig. 1.2). Las
enzimas son cruciales en el metabolismo porque otorgan celeridad a las reacciones
físico-químicas y se comportan como factores reguladores de las vías metabólicas,
modificando su funcionalidad y por ende, la actividad completa de la vía metabólica.
CAPÍTULO I
12
Figura 1.2: Red metabólica simple ficticia. La célula está delimitada por la pared
celular (cell wall), donde S1 y S2 son el conjunto de entradas a la célula y P1 es
la salida. Los compuestos y los flujos denotados por (C1-C5) y (V1-V7)
respectivamente.
Una característica del metabolismo es la similitud de las rutas metabólicas básicas
incluso entre especies muy diferentes: la secuencia de pasos químicos en una vía
metabólica como el ciclo de Krebs es universal entre células vivientes tan diversas
como la bacteria unicelular Escherichia coli y organismos pluricelulares como el
elefante (Smith E, 2004). Es posible usar esta información para reconstruir redes
completas de comportamientos bioquímicos y producir modelos matemáticos
holísticos que puedan explicar y predecir su comportamiento (Borodina I, 2005).
1.2.1. Representación matemática del metabolismo celular
Las reacciones metabólicas son representadas mediante una matriz estequiométrica
de tamaño . Cada fila de la matriz representa un único componente o
metabolito (para un sistema de componentes), y cada columna representa una
reacción (de las reacciones que tienen lugar en el sistema). Las entradas que
ocupan las celdas de la matriz son los coeficientes estequiométricos de los
metabolitos participantes en la reacción. Se atribuye un coeficiente negativo para
cada metabolito consumido y uno positivo para cada metabolito producido (Orth, et
al., 2010).
CAPÍTULO I
13
Un coeficiente estequiométrico igual a cero es usado para cada metabolito que no
participa en una reacción en particular. Dado que la mayoría de las reacciones
bioquímicas involucran solamente unos pocos metabolitos en el elemento
predominante es el , es eficiente y generalmente aplicado, trabajarla como una
matriz esparcida.
1.3. Análisis de Balance de Flujos (FBA)
El flujo de todas las reacciones en una red es representado por el vector , de
longitud La concentración de todos los metabolitos se distribuyen en un
vector , de posiciones. La ecuación de balance de masa para el estado
estacionario del sistema (
) está dada por (Orth, et al., 2010).
En cualquier modelo metabólico realista hay más reacciones que componentes
( ). En otras palabras hay más variables desconocidas que ecuaciones, lo que
deriva en un sistema de ecuaciones de tipo rectangular donde no habrá una única
solución.
Aunque las restricciones definen un rango de soluciones, es todavía posible identificar
y analizar puntos simples dentro del espacio de solución. Por ejemplo, podemos estar
interesado en identificar cual punto corresponde a la máxima producción de ATP en
un organismo, dado por un grupo particular de restricciones. El FBA es un método
para identificar un punto óptimo dentro de un espacio restringido (Fig. 1.3).
CAPÍTULO I
14
Figura 1.3| La base conceptual del modelo basado en restricciones. Sin restricciones,
la distribución de flujo de una red biológica puede caer en cualquier punto en un
espacio de soluciones. Cuando las restricciones de balance de masa impuestas por
la matriz estequiométrica (etiqueta 1) y las restricciones de capacidad impuestas
por limites inferiores y superiores ( ) (etiqueta 2) son aplicadas a la red se define
un espacio de solución deducible. Mediante la optimización de una función objetivo,
El FBA puede identificar una distribución de flujo óptimo que se encuentra sobre la
frontera del espacio permisible de soluciones.
El FBA persigue maximizar o minimizar una función objetivo la cual puede
ser cualquier combinación lineal de flujos, donde es un vector de pesos que indica
cuanto contribuye cada reacción a la función objetivo. En la práctica cuando se desea
maximizar o minimizar una reacción, es un vector de ceros y el valor de uno
en la posición de la reacción de interés, este producto vectorial nos determina cuál de
todos los flujos dentro de la ruta se desea optimizar.
La optimización del sistema en cuestión es lograda mediante programación lineal. El
FBA puede, de este modo ser definido como el uso de la programación lineal para
resolver la ecuación , dado un juego de límites inferiores y superiores sobre, ,
y una combinación lineal de flujos, como función objetivo. La salida del FBA es una
particular distribución , la cual maximiza o minimiza la función objetivo (Orth, et al.,
2010).
Gráficamente sería:
Dada la siguiente red metabólica ficticia, compuesta por 7 reacciones, 3 internas (se
asume que los sustratos y productos están localizados dentro de la célula), y 4 de
CAPÍTULO I
15
intercambio (algún reactante entra o algún producto sale, por tanto solo un metabolito
es contabilizado en ella).
Donde la estequiometria es la que sigue:
Internas: De intercambio:
El balance dinámico de masa o la ecuación de biomasa dada por:
Dónde:
: Concentración de los metabolitos.
: Tiempo.
: Matriz estequiométrica.
: Vector de los flujos.
Es necesario asumir que en el estado estacionario no hay cambio de la concentración
en el tiempo, y por tanto .
Sujeto a.
CAPÍTULO I
16
Para lo cual y el vector de flujos queda como sigue:
1.4. Análisis Dinámico del Balance de Flujos (dFBA)
El FBA solamente identifica la distribución de flujos metabólicos, no aporta
información sobre las concentraciones metabólicas o acerca de las características
dinámicas de los flujos. En simulaciones donde hay transiciones entre dos estados,
las soluciones del FBA indicarán una instantánea de los flujos metabólicos (Varma, et
al., 1994). Por lo tanto, las restricciones sobre el índice de cambio de los flujos tienen
que ser explícitamente incorporadas al problema. La extensión dinámica para el FBA
(dFBA) puede ser formulada de las dos siguientes formas (Mahadevan, et al., 2002),
(Varma, et al., 1994):
1.4.1. Aproximación de Optimización Dinámica (DOA)
Esta involucra la optimización sobre todo el período de tiempo de interés, para
obtener los perfiles de tiempo de los flujos y las concentraciones de los metabolitos.
El anterior problema de optimización se transforma en uno de programación no lineal
(NLP).
Considerando una red metabólica con metabolitos y flujos. El juego de
ecuaciones de conservación de la masa para cada metabolito resulta en un juego de
ecuaciones diferenciales ordinarias,
∑
Donde es el vector de la concentración de los metabolitos, el vector de los flujos
metabólicos por gramo (DW , del inglés dry weight) de biomasa, es la matriz
estequiométrica de la red, es el índice de crecimiento obtenido como una suma con
CAPÍTULO I
17
pesos de las reacciones que sintetizan los precursores del crecimiento, y son las
cantidades de los precursores de crecimiento requeridos por gramo (DW) de biomasa
(Mahadevan, et al., 2002).
Junto con el sistema de ecuaciones dinámicas, varias restricciones tienen que ser
impuestas para una predicción realista de las concentraciones de los metabolitos y de
los flujos. Estas incluyen metabolitos y niveles de flujos no negativos, limites sobre la
tasa de cambio de los flujos, y cualquier restricción no lineal sobre los flujos de
transporte. El problema de optimización dinámica puede ser formulado como:
∑∫ ( ) ( )
Sujeto a.
∑
[ ]
[ ]
Donde y son las condiciones iniciales para la concentración de los metabolitos y
la concentración de biomasa respectivamente, es un vector función que puede
surgir debido a la consideración de expresiones cinéticas para los flujos, y son
los tiempos iniciales y finales, es la función objetivo terminal que depende de la
CAPÍTULO I
18
concentración en el punto final, es la función objetiva instantánea, es la función
Dirac-Delta, es el instante de tiempo en cual es considerada, y son los
pesos asociados con la funciones instantánea y terminal, respectivamente, y es
el perfil de tiempo de los flujos metabólicos. Si la restricción no lineal está ausente, el
problema se reduce a un problema de optimización que involucra un sistema bilineal
(Mahadevan, et al., 2002).
El problema de optimización se puede resolver parametrizando las ecuaciones
dinámicas a través del uso de colocación ortogonal sobre elementos finitos (On the
optimization of differential, 1987). El periodo de tiempo se divide en un
número finito de intervalos (elementos finitos). Los flujos, los niveles metabólicos y la
concentración de biomasa son parametrizados en la raíz de un polinomio ortogonal
dentro de cada elemento finito. La continuidad de los metabolitos y la concentración
de biomasa son impuestas al inicio de cada uno de los elementos finitos. El tiempo
derivado de las variables se aproximado como una combinación lineal de los valores
de flujo en cada punto, y las ecuaciones dinámicas son transformadas a ecuaciones
algebraicas. Las restricciones no lineales deben ser impuestas en puntos discretos en
el intervalo de tiempo considerado. El problema de optimización se convierte en un
problema de programación no lineal (Mahadevan, et al., 2002).
1.4.2. Aproximación de optimización estática (SOA)
Esta aproximación implica dividir el tiempo que interesa, en muchos intervalos y
resolver problemas de optimización instantánea (FBA) al inicio de cada uno, seguido
por una integración sobre todo el período. El problema de optimización se resuelve
usando programación lineal (LP), repetidamente durante el curso del tiempo que
interesa, para obtener la distribución de flujos en un instante particular.
CAPÍTULO I
19
∑
Sujeto a.
( ) [ ]
[ ]
Donde es la duración del intervalo de tiempo escogido. Las ecuaciones dinámicas
son integradas asumiendo que los flujos son constantes en el intervalo. El problema
de optimización se reformula para el próximo instante de tiempo y se resuelve. El
procedimiento se repite dese hasta . Para la clase de sistema que involucra
solamente términos bilineales con flujos y la concentración de biomasa, es posible
resolver directamente las ecuaciones dinámicas, y de este modo eliminar la
integración numérica (Mahadevan, et al., 2002).
1.5. Sistemas afines
Constraint-based reconstruction and analysis (COBRA), es un paquete de software
que corre sobre Matlab, mediante el cual es posible realizar predicciones cuantitativas
del comportamiento celular usando una aproximación basada en restricciones.
Específicamente este software ayuda a predecir computacionalmente estados
estáticos, dinámicos, el efecto de la supresión de genes, análisis de robustez y otros
como muestreos metabólicos y módulos de la red.
Se requiere de cierto grado de destreza para lograr instalar COBRA, ya que carece
de un ejecutable o una secuencia de instalación, además se necesita disponer de
varias librerías y paquetes previamente corriendo en Matlab, como son LibSBML,
para todo el tratamiento de los archivos .xml y una serie de solvers matemáticos para
resolver los problemas de programación cuadrática, lineal y no lineales, como el
GLPK, CPLEX, Lindo_Solver.
CAPÍTULO I
20
En contra de la mejor usabilidad de COBRA está el hecho de carecer de un ambiente
visual, que guie al ingeniero metabólico en el proceso que va desde el cargado del
fichero, contenedor de la información biológica (SBML) hasta la aplicación de las
restricciones y la obtención de los resultados. Todo el trabajo se realiza a base de
comandos, por lo cual es necesario un conocimiento previo y medianamente profundo
del paquete de clases en general.
1.6. Análisis de Factibilidad
Al desarrollar un software resulta imprescindible estimar, desde el comienzo, el
esfuerzo humano, el tiempo de desarrollo y el costo que conlleva la implementación
del mismo. Con esto, es posible determinar si es factible o no la ejecución del
proyecto y en caso de ser posible, ajustar algunos parámetros que ayudan a planificar
el trabajo a realizar (Peralta, 2004).
La estimación se realizó mediante el análisis de Puntos de Casos de Uso, el cual fue
ideado por Gustav Karner, de Rational Software Corporation, en 1993, que estima las
horas-persona del tiempo de desarrollo de un proyecto, mediante la asignación de
pesos a los factores que lo afectan. Este proceso de estimación se realiza mediante
una serie de pasos (Anexo I):
El costo total del proyecto fue estimado en , teniendo en cuenta que la
aplicación es el resultado de un trabajo de diploma, no implica incurrir en ningún tipo
de gastos sino que constituye un ahorro, por lo que es factible llevar a la práctica el
desarrollo de la misma.
CAPÍTULO I
21
1.7. Modelo de Dominio
El modelo de dominio es una representación visual de los conceptos u objetos del
mundo real significativos para un problema o área de interés. Éste es utilizado para
comprender, capturar y describir los conceptos más importantes empleados en el
contexto del negocio. Para la construcción de un modelo de dominio se extraen los
conceptos y eventos principales del entorno y se relacionan en un diagrama de clases
UML (Figura 1.4).
Figura. 1.4| Modelo de Dominio
class Domain Mo...
FBA
dFBA
+ HacerFBA() : void
Modelo_Matematico Metabolismo_Celular
Ruta_Metabolica
Especie
Reaccion
- substrato: Especie
- producto: Especie
- lb: Parametro
- ub: Parametro
Parametro
Compartimiento
SOA DOA 1.. *
«suceden»
1
1.. *
«localizadas-en»
1
1
«se-compone-de»
1.. *
* «modelan» 1
1.. * «simular» 1
1
«calcula»
1.. *
1 «ocurren»
1.. *
CAPÍTULO I
22
1.7.1. Conceptos que se utilizan en el Modelo de Dominio
Para la realización del modelo de dominio es necesario identificar los conceptos
principales del negocio los cuales nos van a garantizar un mejor entendimiento sobre
el objeto de estudio de esta investigación y facilitarán la captura de los requisitos;
posibilitando el desarrollo de un software de acuerdo a las necesidades de los
clientes.
A continuación se desarrollan los conceptos modelados en el diagrama del modelo de
dominio:
Metabolismo celular: conjunto de reacciones y procesos físico-químicos que ocurren
en una célula, se organizan en vías o rutas metabólicas y son la base de la vida a
nivel molecular
Ruta metabólica: sucesión de reacciones químicas que conducen de un sustrato
inicial a uno o varios productos finales, a través de una serie de metabolitos
intermediarios.
Especie: cualquier molécula utilizada o producida durante el metabolismo.
Sustrato: metabolito de partida en una reacción metabólica.
Producto: producto final de la vía metabólica.
Parámetro: Una cantidad con un nombre simbólico que es usado en un sentido
genérico para referirse a las cantidades nombradas sin tener en cuenta si ellos son
constantes o variables.
Reacción: Una declaración que describe alguna transformación, transporte o proceso
obligatorio que pueden cambiar la cantidad de una o más especies. Expresa, por
ejemplo como ciertos substratos son transformados en ciertos productos y regulados
por qué parámetros.
Compartimiento: Un recipiente de un tipo particular y tamaño finito dónde pueden
localizarse las especies.
CAPÍTULO I
23
Modelo matemático: modelo científico, que emplea formulismo matemático para
expresar relaciones, proposiciones, variables, parámetros, entidades y relaciones
entre variables y/o entidades u operaciones, para estudiar comportamientos de
sistemas complejos ante situaciones difíciles de observar en la realidad.
FBA: es un método matemático para analizar el metabolismo en un sistema biológico,
no requiere conocer previamente las concentraciones de los metabolitos o los detalles
de la cinética enzimática del sistema. Se asume que el sistema bajo estudio se
encuentra en homeostasis
dFBA: la extensión dinámica para el FBA.
SOA: Modelo matemático que describe una aproximación estática para realizar el
dFBA.
DOA: Modelo matemático que describe una aproximación dinámica para realizar el
dFBA.
CAPÍTULO I
24
Conclusiones del Capítulo
Se abordó el marco conceptual en que se define el objeto de esta investigación, se
profundizó en la BS así como en sus características principales. El metabolismo
celular, como proceso biológico, quedó representado matemáticamente, como primer
paso para introducir los temas referentes al FBA y dFBA, de los cuales fueron
presentados sus modelos y aproximaciones matemáticas. Se analizaron los sistemas
afines con nuestro propósito investigativo, lo cual permitió saber en qué estado se
encontraba el tema en la actualidad y en cuales áreas serían posibles aportes. Un
estudio de factibilidad justificó la realización del software que se propone como
objetivo general de este trabajo.
CAPÍTULO II
25
CAPÍTULO II: CARACTERIZACIÓN DE LA SOLUCIÓN PROPUESTA
Este capítulo consta de nueve epígrafes, en los cuales se aborda el diseño de
HYDRA dFBA, se hace una breve descripción de la metodología de desarrollo, así
como la fundamentación de su uso. Además se describen las herramientas utilizadas
en el diseño de la aplicación, se hace referencia a cada uno de los requisitos
funcionales y no funcionales del sistema, se expresa su trazabilidad hacia los casos
de uso, se muestra el diagrama de casos de uso, y un resumen de esto. Se definen
los actores y su rol en el sistema. Los Diagramas de Clases del Diseño, general y por
paquetes, son presentados también.
2.1. Caracterización de la metodología y herramientas para el diseño
El proceso de ingeniería de software se define como "un conjunto de etapas
parcialmente ordenadas con la intención de lograr un objetivo, en este caso, la
obtención de un producto de software de calidad. El proceso de desarrollo de
software "es aquel en que las necesidades del usuario son traducidas en requisitos
de software, estos requisitos transformados en diseño y el diseño implementado en
código, el código es probado, documentado y certificado para su uso operativo".
Concretamente "define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un
cierto objetivo" (Jacobson, et al., 2000).
La importancia de la elección y empleo de un proceso de desarrollo se refleja en la
elevada proporción de proyectos de software que fracasan. Un estudio del Standish
Group hecho sobre 352 compañías de software, donde se estudiaron más de 8.000
proyectos, mostró, entre otros, los siguientes resultados:
El 31% de todos los proyectos de software fueron cancelados antes de terminarse.
(Pérdidas de US $81 billones).
El 53% de los proyectos tuvieron un costo 189% mayor de lo estimado.
El 9% de los proyectos se terminaron a tiempo y dentro del presupuesto
(compañías grandes).
El 16% de los proyectos se terminaron a tiempo y dentro del presupuesto
(compañías pequeñas).
CAPÍTULO II
26
En estos últimos años se han desarrollado dos corrientes en lo referente a los
procesos de desarrollo, los llamados métodos pesados y los métodos ligeros o ágiles.
La diferencia fundamental entre ambos es que mientras los métodos pesados
intentan conseguir el objetivo común por medio de orden y documentación, los ligeros
tratan de mejorar la calidad del software por medio de una comunicación directa e
inmediata entre las personas que intervienen en el proceso (Molpeceres, 2002).
Con el desarrollo de la industria del software nuevas herramientas informática son
comercializadas, cuyo objetivo es automatizar las actividades requeridas para diseñar
y producir software, aumentando la productividad y mejorando la calidad, aunque en
última instancia el éxito o el fracaso del producto final sigue siendo responsabilidad
del equipo de desarrollo.
A continuación se describen y justifican la metodología y herramientas empleadas
para diseñar HYDRA dFBA.
2.1.1. Proceso Unificado de Desarrollo (RUP)
Dentro de la ingeniería de software orientada a objetos hay un proceso que por su
flexibilidad y la efectividad de las soluciones que propone, se ha estandarizado entre
los desarrolladores, el Proceso Unificado de Desarrollo (RUP) (Jacobson, et al.,
2000), que utiliza como lenguaje de modelado UML, Lenguaje Unificado de
Modelado, (Fowler, et al., 1999) (Rumbaugh, et al., 2000).
RUP guía a los equipos de proyecto hacia un desarrollo iterativo de un modo
controlado mientras se balancean los requerimientos del negocio, el tiempo al
mercado y los riesgos del proyecto. El proceso describe los diversos pasos
involucrados en la captura de los requisitos y en el establecimiento de una guía
arquitectónica lo más pronto posible, para diseñar y probar el sistema hecho de
acuerdo a los requisitos y a la arquitectura. El proceso describe qué entregables
producir, cómo desarrollarlos y también provee patrones. El Proceso Unificado es
soportado por herramientas que sustentan todas sus bases y automatizan entre otras
cosas, el modelado visual, la administración de cambios y las pruebas.
Las características fundamentales del Proceso Unificado son (Jacobson, et al., 2000):
CAPÍTULO II
27
• Guiado por lo casos de uso: Los casos de uso son el instrumento para validar la
arquitectura del software y extraer los casos de prueba.
• Centrado en la arquitectura: Los modelos son proyecciones del análisis y el
diseño constituye la arquitectura del producto a desarrollar.
• Iterativo e incremental: Durante todo el proceso de desarrollo se producen
versiones incrementales (que se acercan al producto terminado) del producto en
desarrollo.
Un proceso realizado siguiendo RUP se divide en cuatro fases (Santiago) y nueve
flujos de trabajo (Rational):
La fase de Concepción tiene por finalidad definir la visión, los objetivos y el
alcance del proyecto, obteniéndose como uno de los principales resultados una
lista de los casos de uso y una lista de los factores de riesgo del proyecto. El
principal esfuerzo radica en el “Modelamiento del Negocio” y el “Análisis de
Requerimientos”.
La fase de Elaboración tiene como principal finalidad completar el análisis de los
casos de uso y definir la arquitectura del sistema. En esta etapa se busca eliminar
los principales riesgos técnicos.
La fase de Construcción está compuesta por un ciclo de varias iteraciones, en
las cuales se van incorporando sucesivamente los casos de uso, de acuerdo a los
factores de riesgo del proyecto. Este enfoque permite contar tempranamente con
versiones del sistema que satisfacen los principales casos de uso.
La fase de Transición se inicia con una versión beta3 del sistema y culmina con
el sistema en fase de producción.
Flujos de trabajo:
Modelamiento del negocio: Describe los procesos de negocio, identificando
quiénes participan y las actividades que requieren automatización.
Requerimientos: Define qué es lo que el sistema debe hacer, para lo cual se
identifican las funcionalidades requeridas y las restricciones que se imponen.
3 Se encuentra aún sujeta a desarrollo, pero se lanza con motivo de testeo.
CAPÍTULO II
28
Análisis y diseño: Describe cómo el sistema será realizado a partir de la
funcionalidad prevista y las restricciones impuestas, indica con precisión lo que se
debe programar.
Implementación: Define cómo se organizan las clases y objetos en componentes.
Prueba (Testeo): Busca los defectos a lo largo del ciclo de vida.
Instalación: Realiza las actividades (empaque, instalación, asistencia a usuarios,
etc.) para entregar el software a los usuarios finales.
Administración del proyecto: Involucra actividades con las que se busca
producir un producto que satisfaga las necesidades de los clientes.
Administración de configuración y cambios: Describe cómo controlar los
elementos producidos por todos los integrantes del equipo de proyecto en cuanto
a: utilización/actualización, control de versiones, etc.
Ambiente: Contiene actividades que describen los procesos y herramientas que
soportarán el equipo de trabajo del proyecto.
Fundamentación del Uso de RUP para el desarrollo de HYDRA dFBA
RUP ha logrado convertirse en un fuerte estándar en los escenarios de la POO4.
Proporciona un método lógico para asignar las tareas y responsabilidades dentro del
equipo de desarrollo, tomando como objetivo el asegurar la producción de software
de alta calidad, que resuelva las necesidades del usuario dentro de un cronograma
predecible y al menor costo posible. Hace uso de los modelos y diagramas como
vehículo de comunicación, al ser estos más expresivos que las descripciones en
lenguaje natural. Toma en cuenta las mejores prácticas a utilizar en el modelo de
desarrollo de software.
La metodología RUP permite controlar nuevas herramientas y tecnologías en un
único ambiente, es adoptada en cientos de proyectos mundialmente y enseñada en
cientos de universidades. Aplicarla garantiza contar con una serie de artefactos útiles
y una amplia documentación al término del proceso.
4 Programación Orientada a Objetos.
CAPÍTULO II
29
2.1.2. Lenguaje Unificado de Modelado (UML)
El Lenguaje Unificado de Modelado UML, por sus siglas en inglés, Unified Modeling
Language, se define como un lenguaje que permite modelar, construir y documentar
los elementos que forman un sistema de software orientado a objetos (Jacobson, et
al., 2000).
Es el lenguaje de modelado de sistemas de software más conocido y utilizado en la
actualidad; está respaldado por el OMG5. UML sirve para el modelado completo de
sistemas complejos, tanto en el diseño de software como para la arquitectura
hardware donde se ejecuten. UML ofrece un estándar para describir un plano del
sistema (modelo), incluyendo aspectos conceptuales tales como procesos de
negocios y funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programación, esquemas de bases de datos y componentes de software
reutilizables.
Otro aspecto de este modelado visual es que es independiente del lenguaje de
implementación, de tal forma que los diseños realizados se pueden implementar en
cualquier lenguaje que soporte las posibilidades de UML (principalmente lenguajes
orientados a objetos). UML es además un método formal de modelado. Esto aporta
las siguientes ventajas:
Mayor rigor en la especificación.
Permite realizar una verificación y validación del modelo realizado.
Se pueden automatizar determinados procesos y permite generar código a
partir de los modelos y a la inversa.
Fundamentalmente, UML está relacionado con la captura, comunicación y nivelación
de conocimientos. Aunque está pensado para modelar sistemas complejos con gran
cantidad de software, el lenguaje es lo suficientemente expresivo como para modelar
sistemas que no son informáticos, como flujos de trabajo en una empresa, diseño de
la estructura de una organización y por supuesto, en el diseño de hardware. Un
modelo UML está compuesto por tres clases de bloques de construcción:
5 Del inglés Object Management Group, consorcio dedicado al cuidado y establecimiento de estándares de
tecnología orientadas a objetos.
CAPÍTULO II
30
Elementos: Son abstracciones de cosas reales o ficticias (objetos, acciones,
etc.).
Relaciones: Relacionan los elementos entre sí.
Diagramas: Son colecciones de elementos con sus relaciones.
Fundamentación del uso de UML para modelar HYDRA dFBA
UML permite expresar un sistema gráficamente, de forma tal que otro lo puede
entender, permite especificar cuáles son las características de un sistema antes de su
construcción y a partir de los modelos especificados se pueden construir los sistemas
diseñados. Los propios elementos gráficos sirven como documentación del sistema
desarrollado que pueden servir para su futura revisión. Prácticamente todas las
herramientas CASE6 y de desarrollo lo han adaptado como lenguaje de modelado. Es
un lenguaje fácil de aprender y de utilizar. Permite describir requerimientos, la
arquitectura y modelar las pruebas a través de artefactos que documentan el proceso.
Se construyen modelos precisos y completos. No es un lenguaje de programación,
pero sus modelos pueden transformarse en código fuente, tablas o almacenamiento
de objetos.
Se escogió el Lenguaje Unificado de Modelado como el lenguaje para la modelación
de la solución propuesta porque este es un lenguaje expresivo, claro, que permite
especificar todas las decisiones de análisis, diseño e implementación. UML es la
convergencia de las mejores prácticas de la industria de las tecnologías para el
modelado de aplicaciones orientadas a objetos.
2.1.3. Herramientas Case. Enterprise Architect
La Ingeniería de Software Asistida por Computadora, cuenta con un grupo de
herramientas denominadas CASE, cuyo fin no es otro que proporcionar una ayuda
automatizada a las actividades que requiere el proceso de producción de software.
Las herramientas CASE ayudan a alcanzar los siguientes objetivos:
Mejorar la productividad en el desarrollo y mantenimiento del software.
Elevar los niveles de calidad del software.
6 Del inglés Computer Aided Software Engineering.
CAPÍTULO II
31
Reducir el tiempo y el costo de desarrollo y mantenimiento de los sistemas
informáticos.
Mejorar la planificación de un proyecto.
Automatizar ciertos aspectos del proceso de producción, documentación,
pruebas de errores, gestión, etc.
En la actualidad existe un gran número de estas aplicaciones en el mercado, las
cuales ayudan en el desarrollo de una cultura ingenieril nueva para muchas
empresas, e.g: Rational Rose, Umbrello, Visual Paradigm, Enterprise Architect.
Enterprise Architect
Enterprise Architect (EA) es una herramienta CASE utilizada para el diseño y
construcción de sistemas de software, para el modelado de procesos de negocios, y
para objetivos de modelado más generalizados. EA provee una generación poderosa
de documentos y herramientas de reporte con un editor de plantilla completo, genera
reportes detallados y complejos con la información y en el formato que se necesite.
EA soporta generación e ingeniería inversa de código fuente para muchos lenguajes
populares, incluyendo C++, C#, Java, Delphi, VB.Net, Visual Basic y PHP. Con un
editor de código fuente con resaltador de sintaxis incorporado, haciendo posible
navegar y explorar su modelo de código fuente en el mismo ambiente. Además ayuda
a visualizar las aplicaciones, puede modelar procesos de negocio, sitios Web,
interfaces de usuario, redes, configuraciones de hardware, mensajes, etc.
Fundamentación del uso de Enterprise Architect
Enterprise Architect proporciona un entorno de modelación de carácter colaborativo y
potenciado mediante UML 2.0, que abarca por completo el ciclo de desarrollo de un
software, pues soporta ocho de los nueve diagramas estándares del UML (Sparx,
2008): diagrama de casos de uso, de clases, de secuencia, de colaboración, de
actividad, de estados, de implementación, de despliegue y varios perfiles del UML.
Permite Modelado de Datos, Ingeniería Directa de Base de Datos a DDL e ingeniería
inversa de Base de Datos, Ingeniería de Código Directa e Inversa (ediciones
Corporativa y Profesional solamente) con soporte para ActionScript 2.0, Java, C#,
CAPÍTULO II
32
C++, VB.Net, Delphi, Visual Basic, Python y PHP, con Facilidad de
Importación/Exportación XMl7 y además con corrector ortográfico.
2.2. MATLAB
MATLAB es el nombre abreviado de “MATrix LABoratory”. Es un programa para
realizar cálculos numéricos con vectores y matrices. Como caso particular puede
también trabajar con números escalares, tanto reales como complejos, con cadenas
de caracteres y con otras estructuras de información más complejas. Una de las
capacidades más atractivas es la de realizar una amplia variedad de gráficos en dos y
tres dimensiones. MATLAB tiene también un lenguaje de programación propio
(Brazález, et al., 2001).
MATLAB es un sistema interactivo cuyo elemento básico de trabajo es la matriz, con
una característica fundamental, y es que no necesita dimensionamiento. Esto le
permite resolver varios problemas de computación técnica (especialmente aquellos
que tienen formulaciones matriciales y vectoriales) en una fracción de tiempo similar
al que se gastaría cuando se escribe un programa en un lenguaje no interactivo como
C o FORTRAN.
Este dispone también en la actualidad de un amplio abanico de programas de apoyo
especializado, denominado Toolboxes, que extienden significativamente el número de
funciones incorporadas en el programa principal. Estos Toolboxes cubren en la
actualidad prácticamente casi todas las áreas principales en el mundo de la ingeniería
y la simulación, destacando entre ellos los de: proceso de imágenes, señal, control
robusto, estadística, análisis financiero, matemáticas simbólicas, redes neurales,
lógica difusa, identificación de sistemas, simulación de sistemas dinámicos, COBRA,
etc. Es un entorno de cálculo técnico, que se ha convertido en estándar de la
industria, con capacidades no superadas en computación y visualización numérica.
Fundamentación del uso del Matlab
De forma coherente y sin ningún tipo de fisuras, integra los requisitos claves de un
sistema de computación técnico: cálculo numérico, gráficos, herramientas para
aplicaciones específicas y capacidad de ejecución en múltiples plataformas. Esta
7 Especificación para el intercambio de diagramas.
CAPÍTULO II
33
familia de productos proporciona un medio de carácter único, para resolver los
problemas más complejos y difíciles.
MATLAB se ha desarrollado a través de los años con entradas provenientes de
muchos usuarios, en los entornos universitarios, es la herramienta instructiva
estándar para cursos avanzados e introductorios en matemáticas, ingeniería y
ciencias. En la industria MATLAB es la herramienta escogida para investigación de
alta productividad, desarrollo y análisis.
2.3. Solver GLPK
GLPK8 es un solver de programación que se desarrolla bajo el amparo del Proyecto
GNU. Está compuesto por una serie de rutinas escritas en el lenguaje de
programación C y organizadas en forma de una librería accesible. Este intenta dar
solución a problemas de programación lineal (LP), programación entera mixta (MIP) y
otros problemas relacionados. GLPK es un paquete de software libre que puede ser
redistribuido y/o modificado bajo los términos de la licencia GNU, este incluye los
siguientes componentes (GLPK Proyect, 2010):
Implementación del método simplex.
Implementación del método simplex exacto.
Implementación del método primal-dual para puntos interiores.
Implementación del método branch-and-cut.
Interfaz de programación de aplicaciones (API)
Fundamentación del uso de GLPK
La interacción con el solver se hizo por medio de una librería de enlace dinámico
(DLL) denominada GlpkSharp desarrollada por Lionel Berton, que se distribuye bajo
una licencia CeCILLv2 (Anexo II), para software libre. El propósito de esta es llamar
desde C# las funciones de la librería del solver. Se empleó GLPK para resolver el
problema de optimización que supone el FBA, el cual deriva en un problema de
programación lineal, resuelto mediante el empleo del método simplex. Además de la
eficiencia y rapidez con que se resuelve el costoso procedimiento, se brindan otras
facilidades que resultan útiles:
Nivel de tolerancia de error ajustable.
8 Del inglés GNU Linear Programming Kit.
CAPÍTULO II
34
Solución cuantitativa y cualitativa del problema.
Rápido acceso a las soluciones del problema primal y dual.
Posibilidad de nomenclar las columnas.
Formulación del método simplex para variables acotadas, por ambos extremos.
Pero sobre todo la experiencia y el prestigio que este tiene resolviendo, durante años
problemas de optimización, donde tan importante es obtener las aproximaciones más
exactas posibles.
2.4. Requerimientos del sistema
Dentro del Proceso de Desarrollo de Software, definir los Requisitos constituye un
motor fundamental del proyecto, estos permiten guiar el desarrollo hacia el sistema
correcto.
Según el glosario de términos de la IEEE9 un requerimiento es: (1) Una condición o
necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una
condición o capacidad que debe estar presente en un sistema o componentes de
sistema para satisfacer un contrato, estándar, especificación u otro documento formal.
(3) Una representación documentada de una condición o capacidad como en (1) o
(2).
Los requisitos funcionales, son las condiciones o capacidades que el sistema debe
cumplir y para que queden correctamente definidos debe llegarse a un acuerdo entre
el cliente y los desarrolladores sobre qué debe y qué no debe hacer el sistema
(Jacobson, et al., 2000).
Los requisitos no funcionales son las propiedades o cualidades que el producto de
software debe tener, tienen que ver con características que de una u otra forma
puedan limitar el sistema, como por ejemplo, el rendimiento, interfaces de usuario,
mantenimiento, seguridad, portabilidad, estándares, etc. (Jacobson, et al., 2000) .
2.4.1. Requisitos Funcionales
Tomando como punto de partida el Modelo de Domino, así como las entrevistas con
los usuarios del sistema, se logró determinar todas las funcionalidades que se
deberían desarrollar. Estas se recogen en el siguiente listado. El sistema debe:
9 Del inglés Institute of Electrical and Electronics Engineers
CAPÍTULO II
35
R.F. 1 Leer datos del Sistema Biológico desde el archivo SBML (.Xml).
R.F. 1.1 Leer Nivel de SBML.
R.F. 1.2 Leer Versión de SBML.
R.F. 1.3 Leer Modelo Biológico
R.F. 1.3.1 Leer Id del Modelo.
R.F. 1.3.2 Leer Nombre del Modelo.
R.F. 1.3.3 Leer Compartimientos del Modelo.
R.F. 1.3.3.1 Leer Id del Compartimiento.
R.F. 1.3.3.2 Leer Outside del Compartimiento.
R.F. 1.3.4 Leer Especies del Modelo.
R.F. 1.3.4.1 Leer Id de la Especie.
R.F. 1.3.4.2 Leer Nombre de la Especie.
R.F. 1.3.4.3 Leer Carga de la Especie.
R.F. 1.3.4.4 Leer “boundaryCondition” de la Especie.
R.F. 1.3.4.5 Leer Estequiometría de la Especie.
R.F. 1.3.4.6 Leer Compartimiento de la Especie.
R.F. 1.3.5 Leer Reacciones del Modelo.
R.F. 1.3.5.1 Leer Id de la Reacción.
R.F. 1.3.5.2 Leer Nombre de la Reacción.
R.F. 1.3.5.3 Leer Reversibilidad de la Reacción.
R.F. 1.3.5.4 Leer lista de Especies Reactantes de la Reacción.
R.F. 1.3.5.5 Leer lista de Especies Productos de la Reacción.
CAPÍTULO II
36
R.F. 1.3.5.6 Leer Límite Inferior de la Reacción.
R.F. 1.3.5.7 Leer Límite Superior de la Reacción.
R.F. 1.3.5.8 Leer Coeficiente Objetivo de la Reacción.
R.F. 2 Normalizar el Id de las Especies del Modelo.
R.F. 3 Normalizar el Id de las Reacciones del Modelo.
R.F. 4 Construir la Matriz Estequeométrica del Modelo.
R.F. 5 Buscar las Reacciones de Intercambio del Modelo.
R.F. 6 Buscar la Reacción de Biomasa del Modelo.
R.F. 7 Llevar las Reacciones a su forma matemática.
R.F. 8 Mostrar en pantalla resumen del Sistema Biológico leído.
R.F. 8.1 Mostrar Nivel de SBML.
R.F. 8.2 Mostrar Versión de SBML.
R.F. 8.3 Mostrar Id del Modelo.
R.F. 8.4 Mostrar Nombre del Modelo.
R.F. 8.5 Mostrar cantidad de Compartimientos en el Modelo.
R.F. 8.6 Mostrar cantidad de Especies en el Modelo.
R.F. 8.7 Mostrar cantidad de Reacciones en el Modelo.
R.F. 8.8 Mostrar cantidad de Reacciones de Intercambio en el Modelo.
R.F. 8.9 Mostrar cantidad de elementos distintos de cero en la Matriz
Estequeométrica.
R.F. 9 Mostrar en pantalla datos del Sistema Biológico leído.
R.F. 9.1 Listar Compartimientos del Modelo.
R.F. 9.1.1 Listar Id del Compartimiento.
CAPÍTULO II
37
R.F. 9.1.2 Listar Outside del Compartimiento.
R.F. 9.1.3 Listar Especies por Compartimiento.
R.F. 9.2 Listar Especies del Modelo.
R.F. 9.2.1 Listar Id de la Especie.
R.F. 9.2.2 Listar Nombre de la Especie.
R.F. 9.3 Listar Reacciones del Modelo.
R.F. 9.3.1 Listar Id de la Reacción.
R.F. 9.3.2 Listar Nombre de la Reacción.
R.F. 9.3.3 Listar Reversibilidad de la Reacción.
R.F. 9.3.4 Listar Límite Inferior de la Reacción.
R.F. 9.3.5 Listar Límite Superior de la Reacción.
R.F. 9.3.6 Mostrar forma matemática de la Reacción.
R.F. 9.3.6 Listar Exchange Condition de la Reacción.
R.F. 10 Mostrar información detallada de las Reacciones del Modelo.
R.F. 10.1 Salvar información detallada de las Reacciones, en formatos (.xlsx, .xls, .txt,
.htm, .xml), en la ruta y con el nombre escogidos por el usuario.
R.F. 11 Actualizar el Límite Inferior de las Reacciones de Modelo.
R.F. 12 Actualizar el Límite Superior de las Reacciones del Modelo.
R.F. 13 Habilitar área de simulación.
R.F. 14 Listar substratos para reacciones de intercambio.
R.F. 15 Listar reacciones de intercambio, con límite inferior y concentración.
R.F. 16 Mostrar ayuda lateral para el área de simulación.
CAPÍTULO II
38
R.F. 17 Recibir del usuario las Reacciones de Intercambio con concentración de
substrato constante.
R.F. 18 Quitar de la lista de Reacciones de Intercambio, las marcadas como
constante.
R.F. 19 Recibir del usuario Biomasa Inicial a emplear en la simulación.
R.F. 20 Recibir del usuario Intervalo de Tiempo a emplear en la simulación.
R.F. 21 Recibir del usuario Número de Intervalos a emplear en la simulación.
R.F. 22 Permitir al usuario cambiar la concentración de substrato para las reacciones
de intercambio.
R.F.23 Correr la simulación con los parámetros y restricciones establecidas por el
usuario.
R.F. 24 Mostrar los resultados de la simulación en la misma medida en que se vayan
produciendo estos.
R.F. 25 Salvar los resultados de la simulación, en formatos (.xlsx, .xls, .txt, .htm, .xml),
en la ruta y con el nombre escogidos por el usuario.
R.F. 26 Interrumpir la simulación por solicitud del usuario [no implementado aun].
R.F. 27 Graficar la concentración de Biomasa en el tiempo.
R.F. 27.1 En gráfico de barras.
R.F. 27.2 En gráfico de área.
R.F. 27.3 En gráfico de columnas.
R.F. 27.4 En gráfico de line de pasos.
R.F. 28 Graficar la concentración de los substratos de las reacciones de intercambio
en el tiempo.
R.F. 28.1 En gráfico de barras.
R.F. 28.2 En gráfico de área.
CAPÍTULO II
39
R.F. 28.3 En gráfico de columnas.
R.F. 28.4 En gráfico de line de pasos.
R.F. 29 Salvar los gráficos en formato (.jpg), en la ruta y con el nombre escogidos por
el usuario.
R.F. 30 Mostrar la Distribución de Flujos para cada reacción, en las iteraciones
deseadas por el usuario.
R.F. 31 Salvar la Distribución de Flujos en pantalla, en formatos (.xlsx, .xls, .txt, .htm,
.xml), en la ruta y con el nombre escogidos por el usuario.
R.F. 32 Mostrar un Historial de Biomasa, con los resultados de las simulaciones
corridas sobre un mismo modelo.
R.F. 33 Salvar Historial de Biomasa, en formatos (.xlsx, .xls, .txt, .htm, .xml), en la ruta
y con el nombre escogidos por el usuario.
R.F. 34 Mostrar los substratos para las reacciones de intercambio y su concentración
en el tiempo (si al menos en una iteración la concentración fue mayor que cero).
R.F. 36 Salvar la Matriz de Concentración, en formatos (.xlsx, .xls, .txt, .htm, .xml), en
la ruta y con el nombre escogidos por el usuario.
R.F. 37 Abandonar el área de simulación.
R.F. 38 Cerrar el Modelo abierto, dejando el sistema listo para cargar otro Modelo.
R.F. 39 Guardar un historial con los links hacia los últimos cuatro modelos abiertos.
R.F. 40 Consultar la Ayuda.
CAPÍTULO II
40
2.4.2. Requisitos no Funcionales
Tomando como punto de partida los requerimientos funcionales y a los usuarios
finales, es decir lo que el sistema debe hacer y para quien debe hacerlo, se ha
determinado cómo este debe comportarse. Las propiedades y cualidades que rigen
este comportamiento, se relacionan a continuación.
Requisitos de Apariencia
La aplicación debe tener una apariencia atractiva, que llame la atención del usuario
dentro del competitivo mercado actual, al estar dirigida a un público no especializado
en desarrollo de software, y ser de uso opcional, debe estar acorde con las
tendencias actuales, para garantizarse una oportunidad dentro del no reducido grupo
de personas que juzgan un software por su apariencia en primera instancia. La
interfaz de usuario estará llamada a ser el gancho que nos permita demostrar otros
valores agregados y funcionalidades de calidad del producto.
Debe ser ágil, legible y simple de usar, sencillo para la interacción y sin
ambigüedades, consistente y a fin con los términos de los conceptos manejados. Se
cuidará porque la aplicación sea lo más interactiva posible.
Requisitos de usabilidad
Debe haber consistencia en sus interfaces y estas deben ser lo suficientemente
comunicativas como para facilitar su uso y comprensión, al primer intercambio con el
sistema. El usuario debe sentirse guiado y orientado en su uso. La respuesta a
cualquier duda que sobre el uso de la aplicación pueda surgir, estará a la distancia de
un clic, gracias a una ayuda de escritorio lateral. Los usuarios que utilicen la
aplicación solo necesitarán los conocimientos informáticos básicos, y poseer una
conceptualización de los temas que se muestran en la aplicación.
Políticos – Culturales
El sistema estará disponible en idioma Inglés, como parte de la plataforma
computacional HYDRA, igualmente disponible en idioma Inglés.
CAPÍTULO II
41
Requisitos de software
La aplicación podrá ser instalada, o ejecutada en su versión portable, sobre Windows.
Son requeridos:
1. Microsoft .NET Framework 4 Client Profile, o superior.
2. Windows Installer 3.1 o superior.
Requisitos de Hardware
Cualquier computadora que soporte el Framework 4 de .Net podrá ser usada para
correr la aplicación, teniendo en cuenta que la rapidez con que se obtengan los
resultados de la simulación, dependerá de forma directa del poder de cómputo del
procesador, así como de otras propiedades de la PC en cuestión.
Requisitos de diseño e implementación
No hay restricciones de este tipo. La aplicación se desarrollará en C# utilizando
Microsoft Visual Studio 2010 y trabajando con el framework 4.0, por las posibilidades
gráficas que brinda.
Documentación
El usuario podrá auxiliarse de una ayuda del sistema en todo momento, la cual será
bastante visual y explicita, pensadas para usuarios que usen por primera vez la
herramienta.
2.5. Trazabilidad Requerimiento Funcional- Caso de Uso
La trazabilidad de los requerimientos se refiere a la documentación de la vida de cada
uno de ellos, y debe permitir seguir el historial desde su formulación original. Incluso
la implementación de las características determinadas por los requerimientos deben,
poder trazarse (Anexo III).
Los requerimientos funcionales se describen mejor en forma de casos de uso, de
manera que es posible trazar una relación directa entre los requisitos y los casos de
uso que los satisfarán. A continuación se muestra, dividido en tres grupos, de acuerdo
a la tarea que cumplen, dicha trazabilidad.
CAPÍTULO II
42
2.5.1. Cargar y Presentar el Modelo
La Figura 2.1 muestra un grupo de requerimientos que pueden ser catalogados en
cuanto a, que su cometido es cargar un Sistema Biológico desde un archivo y
presentárselo al usuario, dándole a este la posibilidad de explorarlo, salvar algunos
aspectos y modificar otros, como los límites de las reacciones. La trazabilidad hacia
los casos de uso esta explícitamente señalizada.
Figura 2.1: Requerimientos- casos de uso que garantizan cargar y presentar el Modelo.
CAPÍTULO II
43
2.5.2. Navegabilidad
Una vez cargado el modelo una serie de opciones se deben habilitar, la manipulación de estas
y la disponibilidad de ciertos datos es garantizados por los requerimientos y su consecuente
realización en casos de uso que se muestra en la Figura 2.2. La más importante de estas
opciones es la que le permite al usuario llegar al área de simulación, y la necesaria
preparación de esta por parte del sistema.
Figura 2.2: Requerimientos- casos de uso que garantizan la navegabilidad.
2.5.3. Simulación
El objetivo primario del sistema que se propone es la realización de una simulación
dinámica del balance de flujos para una red metabólica, los requerimientos que dan
cumplimiento a este, y que proveen una serie de servicios agregados, disponibles
solo después de que la simulación se realizó, se muestran en la Figura 2.3.
CAPÍTULO II
44
Figura 2.3: Requerimientos casos de uso que garantizan la simulación.
CAPÍTULO II
45
2.6. Actores del Sistema
Son identificados como actores los diferentes tipos de personas (o dispositivos) que
utilizan el sistema o producto. Estos representan roles que personas (o dispositivos)
juegan como impulsores del sistema. Definido más formalmente, un actor es algo que
se comunica con el sistema o producto y que es externo al sistema en sí mismo (Riel,
1996).
Actor Descripción
Usuario
Toda persona que interactúe con el
sistema con el fin de obtener de este
algún(os) beneficio(s), a través del uso
de sus servicios.
Tabla 2.1: Actores del sistema.
El sistema consta de un solo actor pues para el trabajo con la herramienta no se
requiere de ningún tipo de administración, distribución de privilegios o protección de
información. Este es un sistema para simular un proceso biológico, y generar
reportes.
2.7. Casos de Uso del Sistema
La parte más difícil de construir un sistema es precisamente saber qué construir.
Ninguna otra parte del trabajo conceptual es tan difícil como establecer los
requerimientos técnicos detallados, incluyendo todas las interfaces con gente,
máquinas, y otros sistemas. Ninguna otra parte del trabajo afecta tanto al sistema si
es hecha mal. Ninguna es tan difícil de corregir más adelante. Entonces, la tarea más
importante que el ingeniero de software hace para el cliente es la extracción iterativa
y el refinamiento de los requerimientos del producto (Frederik P, 1987).
Los casos de uso son un método que, justamente, ayudan al Ingeniero de Software a
llevar adelante esta parte del desarrollo de un sistema de software. “Un caso de uso
es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno
de sus servicios.”
CAPÍTULO II
46
2.7.1. Modelo de Casos de Uso del sistema
El diagrama de casos de uso del sistema es un artefacto gráfico en el que se
representan los actores, los casos de uso del sistema y las asociaciones que existen
entre actores y casos de uso. A continuación se representa el Diagrama de Casos de
Uso de HYDRA dFBA (Figura 2.4).
Figura 2.4: Diagrama de Casos de Uso del sistema.
CAPÍTULO II
47
2.7.2. Resumen de los casos de uso principales
2.7.2.1. Caso de Uso “Cargar Sistema Biológico”.
Caso de Uso Cargar Sistema Biológico
Actor: Usuario (inicia)
Propósito: Obtener del Sistema Biológico descrito en el archivo .XML los
datos necesarios para realizar la simulación.
Resumen:
El caso de uso se inicia cuando el Usuario decide cargar un
Sistema Biológico, haciendo uso de alguna de las tres
opciones disponibles para ello. El sistema crea un modelo
virtual con los datos que necesita y le informa al usuario que
modelo fue leído, finalizando así el curso normal de los
eventos.
Referencias: R.F 1 R.F 8.
Precondiciones:
Ningún otro Sistema Biológico puede estar abierto.
Para usar la opción Modelo Recientes, algún Modelo debe
haber sido previamente abierto.
Actor: Usuario (inicia)
Propósito: Obtener del Sistema Biológico descrito en el archivo .XML los
datos necesarios para realizar la simulación.
2.7.2.2. Caso de Uso “Gestionar substratos con concentración constante”.
Caso de Uso: Gestionar substratos con concentración constante.
Actor: Usuario (inicia)
Propósito:
Establecer si alguna de las reacciones intercambio del modelo
tendrá una concentración de substrato, que no cambiará en el
tiempo.
Resumen:
Inicia cuando el usuario marca/desmarca alguna reacción
como constante, el sistema adiciona/elimina esta reacción de
la lista de las reacciones de intercambios con concentración
de substrato constante, estas reacciones son retiradas de la
lista de reacciones de intercambio con que se trabajará para
CAPÍTULO II
48
simular, finalizando el caso de uso.
Referencias: R.F 17, 18
Precondiciones: El área de simulación tiene que encontrarse visible.
Poscondiciones:
Se adicionó/removió alguna reacción de la lista de reacciones
de intercambio, por tener concentración de substrato
constante.
2.7.2.3. Caso de Uso “Explorar Modelo”.
Caso de Uso: Explorar Modelo
Actor: Usuario (inicia)
Propósito: Visualizar en pantalla la información del Modelo.
Resumen:
El caso de uso inicia cuando el usuario haciendo uso del
explorador del modelo selecciona alguna(s) de las opciones
disponibles, finalizando el caso de uso con la correspondiente
visualización de la información por parte del sistema.
Referencias: R.F 9
Precondiciones:
Algún Modelo tiene que encontrarse abierto, como
resultado de haber ejecutado el caso de uso “Cargar
Sistema Biológico”.
Poscondiciones: La información del Modelo es mostrada en pantalla al
Usuario.
2.7.2.4. Caso de Uso “Correr Simulación”.
Caso de Uso: Correr Simulación
Actor: Usuario (inicia)
Propósito: Obtener los resultados de la simulación y habilitar el uso de los
servicios que necesitan de esos.
Resumen:
Se inicia cuando el usuario introduce los datos necesarios,
biomasa, intervalo de tiempo y número de intervalos y le
solicita al sistema realizar la simulación con los mismos, el
CAPÍTULO II
49
sistema verifica la validez e integridad de estos y comienza
realizar la simulación hasta el número de intervalos indicado
por el usuario, o hasta que los nutrientes se agoten. Los
resultados que se van obteniendo para cada iteración son
presentados dinámicamente al usuario. Una vez terminada la
simulación, por cualquiera de los motivos antes expuestos se
le hace saber al usuario. Para finalizar el caos de uso el
sistema activa las herramientas que harán uso de estos
resultados.
Referencias:
R.F 19 24.
Casos de uso Asociados:
o Solicitar Matriz de Concentración.
o Solicitar Distribución de Flujos.
o Consultar Gráficos.
o Salvar Datos.
o Abortar Simulación en Curso.
Precondiciones: El área de simulación debe estar visible.
Poscondiciones:
Los vectores de tiempo y biomasa para la simulación son
obtenidos.
La opción para consultar la Matriz de concentración es
activada.
La opción para consultar la distribución de flujos es
activada.
La opción para consultar los gráficos es activada.
La opción para salvar los datos de la simulación es
activada.
Si es la primera ejecución del caso de uso, la opción para
consultar el historial de biomasa es activada.
CAPÍTULO II
50
2.7.2.5. Caso de Uso “Modificar límites de la Reacción”.
Caso de Uso: Modificar límites de la Reacción
Actor: Usuario (inicia)
Propósito: Modificar el(los) límite(s) de una reacción.
Resumen:
Inicia cuando durante la ejecución del caso de uso Explorar
detalles de la reacción, el usuario opta por cambiar algún(os)
de los límites para la reacción seleccionada, el sistema
verifica que la(s) entrada(s) sea(n) correcta(s), modifica la
información y notifica al usuario del éxito de la operación.
Referencias:
R.F 11, 12
Casos de uso Asociados:
Explorar Modelo.
Explorar detalles de la reacción.
Precondiciones: El sistema tiene que encontrarse ejecutando el caso de uso
“Explorar detalles de la reacción”.
Poscondiciones: El(los) límite(s) de la reacción es (son) modificado(s).
2.8. Patrones de diseño
El objetivo es agrupar una colección de soluciones de diseño que son válidas en
distintos contextos y que han sido aplicadas con éxito en otras ocasiones.
Un patrón de diseño es una solución a un problema de diseño no trivial que es
efectiva (ya se resolvió el problema satisfactoriamente en ocasiones anteriores) y
reusable (se puede aplicar a diferentes problemas de diseño en distintas
circunstancias).
Durante el proceso de diseño de clases se descubrieron ciertos problemas, siendo
necesario utilizar patrones de diseño, a continuación se muestran los casos
fundamentales:
CAPÍTULO II
51
Patrón: Creador
Tipo: Creacional
Contexto: Todas las interfaces de usuario se crean a partir de la interfaz principal.
Problema: Se requiere una clase que instancia el resto de las interfaces.
Solución:
Creando la interfaz de usuario “StartF” que tiene métodos para crear
todas las interfaces internas “FluxF”, “GraphicsF”, “BiomassHistoryF”,
“ConcentrationMatrixF”, “About”, “ConfigF”.
Patrón: Fachada
Tipo: Estructural
Contexto:
Algunas clases presentan métodos complejos que se hace necesario
no darles visualización y enmascararlos en métodos más simples, es el
caso de la clase “SbmlIn”.
Problema: Se requiere simplificar los métodos de la clase en un conjunto de
métodos sencillos.
Solución:
En el caso de la clase “SbmlIn” se le da visibilidad al método
“readModel()” , el cual instancia otros más complejos, necesarios para
leer el modelo en un conjunto.
Patrón: Experto
Tipo: Estructural
Contexto:
Cada objeto realiza la funcionalidad de acuerdo a la información que
domina, asignándole la responsabilidad de cumplir una tarea a la clase
con mayor información.
Problema:
Conserva el encapsulamiento, haciendo que los objetos se valgan de
su propia información para hacer lo que se les pide.
Mantener un bajo acoplamiento, creando un sistema robusto y de fácil
mantenimiento.
Solución: Las clases “Specie”, “Reaction”, “Compartment”, se encargan de la
normalización de sus ocurrencias, mientras que la clase “SbmlModel”
CAPÍTULO II
52
2.9. Diagrama de Clases del Diseño (DCD)
Una clase de diseño es una abstracción sin costuras de una clase o construcción
similar en la implementación del sistema. (Jacobson, et al., 2000). Además representa
las especificaciones de las clases e interfaces software en una aplicación. Entre la
información general encontramos (Craig, 2004):
Clases, asociaciones y atributos.
Interfaces, con sus operaciones y constantes.
Métodos.
Información acerca del tipo de los atributos.
Navegabilidad.
Dependencias
A diferencia de las clases conceptuales del Modelo del Dominio, las clases de diseño
de los DCD muestran las definiciones de las clases software en lugar de los
conceptos del mundo real.
se enfoca en aspectos que involucran a todas las partes del modelo,
como la Matriz Estequeométrica y las Reacciones de Intercambio.
Patrón: Bajo Acoplamiento
Tipo: Estructural
Contexto:
Diseño de clases más independientes, que reducen el impacto de los
cambios, y también más reutilizables, que acrecientan la oportunidad
de una mayor productividad.
Problema:
Se desea un grado moderado de acoplamiento entre las clases, para
crear un sistema orientado a objetos, donde las tareas se realicen por
colaboración entre objetos conectados.
Solución:
Se indicaron tareas sencillas a objetos individuales, y tareas más
complejas se realizaron por colaboración entre varios objetos,
obteniéndose índices de mantenimiento entre 60 y 86, profundidades
de herencia entre 1 y 7.
CAPÍTULO II
53
El primer paso en la creación de los DCD es identificar aquellas clases que participan
en la solución del software. Los diagramas muestran cómo se realiza la comunicación
entre las interfaces y los datos. En ellos aparecen las diferentes clases que define
UML, así como las relaciones existentes entre ellas (herencia, agregación asociación.
etc.). El siguiente diagrama (Figura 2.5) muestra cómo será construido el sistema que
se analiza.
Figura 2.5: Vista general del DCD de la aplicación HYDRA dFBA
CAPÍTULO II
54
2.9.1. DCD del paquete Modelo
La Figura 2.6 muestra el diagrama de clases correspondiente al paquete que
contiene todas las clases necesarias para crear un Modelo, estos son los datos que
obtiene el sistema después de leer un archivo, los cuales son necesarios para realizar
la simulación.
Figura 2.6: DCD que conforman un Modelo.
class Mo...
*
1
1.. *
1
1.. * 1
*
1.. *
1.. *
1
*
1
1.. *
1
CAPÍTULO II
55
2.9.2. DCD del paquete Simulación
Las clases que se encargan de la simulación y el curso que esta sigue son mostradas
en la Figura 2.7. Los datos para la simulación son tomados del Modelo, representado
en el epígrafe anterior, y de los parámetros y restricciones entradas por el usuario.
Figura 2.7: DCD para la Simulación.
class Simulation
«library»
GLPKSharp.dll«call»«call»
«build»
«build»«build»
«build»
CAPÍTULO II
56
2.9.3. DCD del paquete Presentación
Las clases que se encargan de la presentación tanto del modelo como de los
resultados son mostradas en la Figura 2.8.
Figura 2.8: DCD para la presentación de los datos.
class Presentation
«call»
«call»
«call»«call»
«call»
CAPÍTULO II
57
Conclusiones del capítulo
Se han descrito y fundamentado la metodología de desarrollo y las herramientas
empleadas para el diseño de la aplicación. Han quedado definidas las características
más importantes del sistema y los servicios que este debe brindar, los cuales serán
posteriormente implementados. Se definieron los requerimientos, funcionales y no
funcionales, se realizó su trazabilidad hacia los casos de uso del sistema y se
designaron los actores. La modelación realizada ha facilitado la mejor comprensión
de las necesidades de automatización del sistema, expresado sobre todo en los
diagrama de clases del diseño.
CAPÍTULO III
58
CAPÍTULO III: IMPLEMENTACIÓN DE LA SOLUCIÓN PROPUESTA
Introducción
El presente capítulo consta de once epígrafes a través de los cuales se describen las
características del XML así como la especificación SBML, formato desde donde serán
obtenidos los modelos que se trabajaran, son abordados la plataforma .NET,
Microsoft Visual Studio, y el lenguaje C#, usado para implementar la aplicación.
Aparecen las consideraciones que se tuvieron en cuenta durante el desarrollo del
sistema, respecto a los estándares de código, el diseño e implementación de la
interfaz y el tratamiento de excepciones. Siguiendo la metodología escogida, son
obtenidos los diagramas de Componentes y de Despliegue.
3.1. Lenguaje de Marcado Extensible (XML)
XML no ha nacido sólo para su aplicación en Internet, sino que se propone como un
estándar para el intercambio de información estructurada entre diferentes
plataformas. Se puede usar en bases de datos, editores de texto, hojas de cálculo y
casi cualquier cosa imaginable.
XML es una tecnología sencilla que tiene a su alrededor otras que la complementan y
la hacen mucho más grande y con unas posibilidades mucho mayores. Tiene un
papel muy importante en la actualidad ya que permite la compatibilidad entre
sistemas para compartir la información de una manera segura, fiable y fácil.
Estructura de un documento XML
La tecnología XML busca dar solución al problema de expresar información
estructurada de la manera más abstracta y reutilizable posible. Que la información
sea estructurada quiere decir que se compone de partes bien definidas, y que esas
partes se componen a su vez de otras partes. Estas partes se llaman elementos, y se
las señala mediante etiquetas.
Documentos XML bien formados
Los documentos denominados como "bien formados" (del inglés well formed) son
aquellos que cumplen con todas las definiciones básicas de formato y pueden, por lo
CAPÍTULO III
59
tanto, analizarse correctamente por cualquier analizador sintáctico (parser) que
cumpla con la norma.
Los documentos han de seguir una estructura estrictamente jerárquica con lo que
respecta a las etiquetas que delimitan sus elementos. Una etiqueta debe estar
correctamente incluida en otra, o sea correctamente anidadas. Los elementos con
contenido deben estar correctamente cerrados. Los documentos XML sólo permiten
un elemento raíz del que todos los demás sean parte. Los valores atributos en XML
siempre deben estar encerrados entre comillas simples o dobles. El XML es sensible
a mayúsculas y minúsculas.
Las construcciones como etiquetas, referencias de entidad y declaraciones se
denominan marcas; son partes del documento que el procesador XML espera
entender. El resto del documento entre marcas son los datos "entendibles" por las
personas.
La importancia de XML en la informática actual está fuera de cualquier tipo de duda.
Dentro de la plataforma .NET XML tiene un papel principal, gran parte de la
arquitectura de .NET trabaja internamente con XML, ADO.NET, WebServices,
SOAP, ASP.NET.
3.2. Lenguaje de Marcado para Sistema Biológicos (SBML)
Las representaciones de modelos son útiles para diferentes propósitos. Los
diagramas gráficos de procesos biológicos son usados para la presentación visual a
las personas, pero al nivel de software, un formato diferente se necesita para
cuantificar a un modelo al punto que pueda simularse y analizarse. Es entonces
donde el SBML juega su papel.
SBML son las siglas en inglés de Systems Biology Markup Language (lenguaje de
marcado para sistemas biológicos). Es el nombre de un formato libre y abierto,
basado en XML que se utiliza para representar modelos cuantitativos de interés
biológico, que aboga por la especificación consistente de los mismos, facilitando el
desarrollo de software y el intercambio de modelos (Hucka, et al., 2008). SBML puede
representar redes metabólicas, rutas de señalización celular, redes de regulación
génicas, y muchas otras clases de sistemas.
CAPÍTULO III
60
SBML no constituye un esfuerzo por definir un lenguaje universal para representar
modelos cuantitativos, es más un formato común intermedio, una lengua franca, que
habilita la comunicación de los aspectos más esenciales de los modelo. La adopción
del SBML ofrece variados beneficios, incluidos: (1) El uso de herramientas múltiples,
sin necesidad de volver a escribir los modelos para cada una de ellas, (2)
habilitándolos para ser compartidos y publicados, de forma que otros investigadores
los puedan usar, incluso en ambientes de software diferentes, (3) asegurando la
supervivencia de los modelos, y el esfuerzo intelectual puesto en estos, más allá de la
vida del software usado para crearlos (Sbml Web Site, 2009).
Los Componentes de un Modelo
La definición de un modelo SBML nivel dos consta de las siguientes listas de
componentes, siendo estas opcionales (Sbml Web Site, 2009):
Definición de Función: Una función matemática que puede ser en todo el
modelo.
Definición de Unidad: Designación de una nueva unidad de medida, o
redefinición de una ya existente.
Tipo de Compartimiento: Define el tipo de el/los recipientes donde las
sustancias químicas estarán localizadas.
Tipo de Especies: Define el tipo de entidad que participa en las reacciones
químicas, por lo general iones y moléculas, otras pueden ser agregadas.
Compartimiento: Recipiente de un tipo particular, y tamaño finito, donde
pueden localizarse las especies de un SBML.
Especies: Concentración de Especies del mismo tipo y localizadas en el mismo
Compartimiento.
Parámetro: Es una cantidad, con un nombre genérico, puede designar
indistintamente constantes o variables, puede abarcar todo el modelo, o solo
una reacción en específico.
Regla: Expresión matemática agregada las reacciones definidas en un modelo.
Restricción: Medio para detectar condiciones fuera de los límites durante la
simulación.
CAPÍTULO III
61
Reacción: Una declaración que describe alguna transformación, transporte o
proceso obligatorio que pueden cambiar la cantidad de una o más especies.
Evento: Una declaración que describe un cambio instantáneo, discontinuo en
un juego de variables de cualquier tipo.
3.3. Plataforma .NET
.NET es un framework de Microsoft que hace énfasis en la transparencia de redes,
con independencia de plataforma de hardware y que permita un rápido desarrollo de
aplicaciones. Basado en ella, la empresa intenta desarrollar una estrategia horizontal
que integre todos sus productos, desde el sistema operativo hasta las herramientas
de mercado.
.NET podría considerarse una respuesta de Microsoft al creciente mercado de los
negocios en entornos Web, como competencia a la plataforma Java de Oracle
Corporation y a los diversos frameworks de desarrollo web basados en PHP. Su
propuesta es ofrecer una manera rápida y económica, a la vez que segura y robusta,
de desarrollar aplicaciones y/o soluciones, permitiendo una integración más rápida y
ágil entre empresas y un acceso más simple y universal a todo tipo de información
desde cualquier tipo de dispositivo. La plataforma .NET proporciona (Recio, et al.,
2007):
Interoperabilidad transparente entre tecnologías.
Fácil migración desde tecnologías existentes.
Un completo soporte de tecnologías de Internet independientes de la
plataforma y basadas en estándares, incluyendo HTTP, XML y SOAP10.
Algunos de los lenguajes desarrollados para el marco de trabajo .NET son: C#, Visual
Basic, Delphi, C++, J#, Perl, Python, Fortran, Prolog (existen al menos dos
implementaciones, el P# y elProlog.NET), Cobol y PowerBuilder (Microsoft
Corporation, 2010). Visual Studio .NET es la herramienta definitiva para la rápida
generación de aplicaciones .NET a escala empresarial y aplicaciones de escritorio de
alto rendimiento, es un entorno de desarrollo integrado para sistemas operativos
Windows. Permite a los desarrolladores crear aplicaciones de escritorio, sitios y
10
Del inglés Simple Object Access Protocol
CAPÍTULO III
62
aplicaciones web, así como servicios web en cualquier entorno que soporte la
plataforma .NET (a partir de la versión 2002). Así se pueden crear aplicaciones que
se intercomuniquen entre estaciones de trabajo, páginas web y dispositivos móviles.
3.3.1. Lenguaje de programación C Sharp (C#)
El lenguaje de programación C#.NET es una actualización técnica de otros lenguajes
de programación más antiguos como lo son el C, C++, Java, Visual Basic, Delphi, etc.
(Hernández Díaz, 2011) . C# es un lenguaje orientado a objetos, desarrollado y
estandarizado por Microsoft como parte de su plataforma .NET, que después fue
aprobado como un estándar por la ECMA11 e ISO.
Su sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la
plataforma.NET, similar al de Java aunque incluye mejoras derivadas de otros
lenguajes (entre ellos Delphi) (Hernández Díaz, 2011) . Algunas características de C#
son:
Provee el beneficio de un ambiente elegante y unificado.
No maneja apuntadores, para emular la función de los apuntadores se utilizan
delegates lo cuál provee las bases para el .NET event model.
La Plataforma .NET provee un colector de basura que es responsable de
administrar la memoria en los programas C#.
El manejo de errores está basado en excepciones.
Soporta los conceptos como encapsulamiento, herencia y polimorfismo de la
programación orientada a objetos.
Soporta los modificadores de acceso private, protected, public y agrega un
cuarto modificador internal.
Es orientado a objetos.
Elimina los ficheros de cabecera.
Es orientado a componentes, la propia sintaxis de C# incluye elementos
propios del diseño de componentes que otros lenguajes tienen que simular
11
Del inglés European Manufacturers Association.
CAPÍTULO III
63
Fundamentación del Uso de C#
La perfección de los lenguajes de programación avanza a grandes pasos, pero
teniendo en cuenta las razones que a continuación se exponen se escogió C# como
lenguaje para la implementación de HYDRA dFBA:
Da soporte para lectura y escritura de documentos XML, así como para su
transformación, filtrado, integración con bases de datos y creación de servicios
Web entre otras tareas más complejas.
Recolección de basura automática.
Eliminación del uso de punteros.
No hay necesidad de declarar funciones y clases antes de definirlas.
Soporta definición de clases dentro de otras.
Todos los valores son inicializados antes de ser usados (automáticamente se
inicializan al valor estandarizado, o manualmente se pueden inicializar desde
constructores estáticos).
No se pueden utilizar valores no booleanos para condicionales. Es mucho más
limpio y menos propenso a errores.
Concepto formalizado de los métodos get y set, con lo que se consigue código
mucho más legible.
Con respecto a algunos lenguajes como por ejemplo Java el rendimiento es,
por lo general, mucho mayor.
Tipos de datos: en C# existe un rango más amplio y definido de tipos de datos
que los que se encuentran en C, C++ o Java.
Propiedades: un objeto tiene propiedades, y debido a que las clases en C#
pueden ser utilizadas como objetos, C# permite la declaración de propiedades
dentro de cualquier clase.
Es orientado a objetos, de una forma más pura y clara que en otros lenguajes
como C++.
Permite controlar la aparición de errores durante la ejecución de la aplicación
capturando y haciendo tratamiento de las excepciones (try - catch).
Permite personalizar los mensajes que brinda el sistema en dependencia de
las necesidades.
CAPÍTULO III
64
Un entorno completamente visual es proporcionado para la creación de las interfaces,
de una forma rápida y sencilla y con una apariencia visual muy profesional, además
de brindar de una serie de componentes en la pestaña de Herramientas,
imprescindibles para esta tarea.
3.4. Implementación de la interfaz de usuario
El diseño de la interfaz de usuario es una tarea que ha adquirido relevancia en el
desarrollo de un sistema informático. La calidad de la interfaz de usuario puede ser
uno de los motivos que conduzca a un sistema al éxito o al fracaso (Meyer, 1998).
Con la implementación de la interfaz para el sistema que tratamos, se persigue darle
cumplimiento a un grupo de aspectos tales como: consistencia, retroalimentación,
minimizar posibilidades de error, proveer recuperación de errores, y minimizar
memorización.
Se ha propuesto para la presente aplicación una interfaz sencilla pero atractiva, que
cumpla con los estándares para las herramientas de la plataforma HYDRA, y que a la
vez posea un estilo propio, que la identifique y proporcione una vista agradable e
informativa. Para lograr estos propósitos se tuvieron en cuenta algunos elementos
como las propiedades de los colores y de la tipografía. Se utilizaron los colores claros,
donde predominan el blanco, el gris y diferentes tonos de verde, siendo este el color
característico. Se hizo uso de los contrastes para resaltar elementos importantes, y
de los degradados, con fines estéticos. Toda la información es mostrada en listas,
tablas o gráficos, ordenada lógica, jerárquica y/o alfabéticamente, con los
identificativos correspondientes, en color negro, y con fondo blanco, con un formato
de fuente estándar para todos los componentes: letra Microsoft Sans Serif, tipo
normal, tamaño 8.5pt.
Los distintos componentes utilizados en la aplicación fueron cuidadosamente
seleccionados de manera que cumplieran con el diseño de interfaz que se deseaba
mostrar y le fueron agregadas todas las funcionalidades requeridas por el usuario del
sistema. Cada componente mantiene informado al usuario en cuanto a su uso y
estado mediante los llamados Tooltips12, que guiarán al usuario inexperto en las
funcionalidades de la aplicación. Se hace un uso intensivo de una barra de estado
12
Consejos de herramientas que se visualizan al detener el mouse sobre ellas.
CAPÍTULO III
65
con la intensión de mantener informado al usuario del estado y el progreso de
operaciones que por su costo computacional, pueden tomar tiempo. Se cuenta con
un logotipo propio, específicamente diseñado para la aplicación, el cual se muestra en
la interfaz inicial.
Leer grandes archivos, visualizar considerables cantidades de información, y la
realización de costosos cálculos matemáticos, son necesarios para proveer los
servicios que brinda la herramienta. Por lo anterior se hizo imprescindible el empleo
de Threads13 para mantener funcional la interfaz cuando alguna de estas tareas está
en curso. De este modo los resultados de la simulación son mostrados a medida de
que se van obteniendo, se evitan los estados inconscientes y los bloqueos del
sistema y se le otorga mayor interactividad y retroalimentación a la solución.
Los errores que pudiera cometer el usuario al introducir los datos en el sistema, son
validados directamente en el momento de la captación, haciendo las aclaraciones
pertinentes a través de mensajes en lenguaje natural. En el sistema se impide la
ocurrencia de muchos de los errores de entrada de datos validándolos por interfaz.
3.4.1. Interfaz de usuario
Todas las ventanas y/o interfaces muestran una estructura visual similar, fácil de
manejar para los usuarios, altamente especializadas en el servicio que proveen y
consecuentes con los principios de diseño anteriormente establecidos. Para todas las
interfaces así como la ayuda y cualquier comunicación con el usuario se hace empleo
del idioma Ingles.
13
Del inglés hilo, en programación hilos de ejecución.
CAPÍTULO III
66
3.4.2 Interfaz Inicial
Al iniciarse el sistema se muestra la interfaz inicial (Figura 3.1), desde la cual será
posible cargar un Modelo, ya sea mediante el “Menú” o la “Barra de Herramientas
Estándar”. Si algún modelo fue exitosamente cargado con anterioridad, este se
muestra en el “Historial de Modelos”, facilitando la operación. La “Barra de Estado”
servirá de retroalimentación al usuario durante el proceso de cargado de un Modelo, y
el “Explorador del Modelo” estará habilitado en el instante en que el proceso termine,
permitiendo la navegación dentro del mismo. La “Ayuda Lateral”, describe estas y
otras opciones, y la “Barra de Herramientas Especializada” estará deshabilitada hasta
que alguna simulación se haya completado.
Figura 3.1: Interfaz inicial HYDRA dFBA.
Menú Barra Herramientas Estándar Barra Herramientas Especializada
Historial Modelos
Ayuda Lateral
Barra de Estado
Explorador del Modelo
CAPÍTULO III
67
3.4.3 Interfaz para la presentación del Modelo
En la Figura 3.2 se muestran los componentes empleados para mostrar al usuario la
información del Modelo, esta se hace visible al terminar de ejecutarse la lectura de
algún Modelo. Se encuentra habilitado el “Explorador de Modelo” que permite
navegar dentro de este, a través de los Compartimientos, las Especies o las
Reacciones del mismo (Anexo VII). Se muestra un resumen cuantitativo e información
específica. Se brinda una vía para llegar hasta el área de simulación (Figura 3.3).
Figura 3.2: Interfaz una vez cargado el Modelo.
3.4.4. Interfaz del área de simulación
Una vez cargado un Modelo se puede acceder al área de simulación (Figura3.3) la
cual brinda las herramientas y la información requeridas para esta tarea. Es mediante
esta que el usuario introduce los parámetros iniciales, biomas, duración del intervalo
de tiempo y cantidad de intervalos; y cualquier restricción adicional sobre los límites
y/ o la concentración de los substratos de intercambio. A partir de esta interfaz, y
después de haber ejecutado el análisis simulado, se puede acceder a una serie de
herramientas (Anexo VIII) útiles al usuario. Se cuenta con una ayuda lateral
especializada en esta vista así como la posibilidad de navegar hacia la pantalla
anterior (Figura 3.2). La “Barra de Estado” es igualmente empleada en esta interfaz.
Resumen Modelo
Área de Simulación
Explorador del Modelo
CAPÍTULO III
68
Figura 3.3: Interfaz para la simulación del análisis dinámico.
3.4.5. Otras interfaces
Después de finalizada alguna simulación se cuenta con la información necesaria para
habilitarle al usuario un grupo de herramientas que le serán de gran utilidad en su
trabajo, estas son: Área de Gráficos, Distribución de Flujos, Historial de Biomasa y
Matriz de Concentraciones (Anexo VIII). La vía para acceder a estas es a través del
“Menú Herramientas” (Figura 3.4) o de la “Barra Herramientas Especializadas”
(Figura 3.5).
Figura 3.4 Menú Herramientas.
Figura 3.5: Barra Herramientas Especializada.
Parámetros Iniciales
Substratos
Límites y Concentraciones
Barra Herramientas de Simulación
Resultados
CAPÍTULO III
69
3.5. Tratamiento de errores
El sistema ha sido diseñado sobre la base de: los errores mejor evitarlos que
tratarlos. No obstante la solución cuenta con la capacidad para lidiar con estos en
caso de que ocurran. Siendo consecuentes con lo anterior:
Se aplicó un filtro en los cuadros de diálogos empleados para abrir archivos,
de modo que solo muestre los .xml.
Los diferentes componentes solo son activados cuando se cuenta con la
información que deben mostrar o q necesitan para operar adecuadamente.
Se examinan cuidadosamente todos los elementos que conforman al Sistema
Biológico antes de crear el Modelo y habilitárselo al usuario.
Se concibió un historial de archivos, que se crea dinámicamente y solo
almacena aquellos cuya valides fue aceptada.
Cada uno de los campos que el usuario pueda usar para entrar información,
tienen habilitados solo los caracteres válidos y acordes con esta información.
Toda la información recibida del usuario es comprobada, antes de usarla en
las simulaciones y/o al sobrescribirla al Modelo.
El sistema cuenta con todo un tratamiento y manejo de excepciones.
Los mensajes de error (Figura 3.6) usan el formato estándar de Windows, el
identificativo de error, una cruz roja, el texto con la información del error y alguna
posible solución, y el aviso acústico.
Figura 3.6: Interfaz de tratamiento de excepciones.
3.6. Estándares de Codificación
Si bien es cierto que programar es una tarea ardua, entender, actualizar y/o extender
lo que otro programador ha realizado con anterioridad, puede ser incluso más
engorroso y en ocasiones imposible.
CAPÍTULO III
70
El uso de un estilo uniforme facilita, la lectura del código por parte de los
programadores, particularmente en las etapas de mantenimiento y los ciclos de
depuración de errores. Esto se traduce en un evidente aumento de la eficiencia. El
uso de estándares está justificado porque la mente humana se adapta a ellos y
encuentra rápidamente la manera de reconocer patrones familiares, asimilando de
forma rápida y sin grandes esfuerzos su significado.
En el sistema implementado se le otorgó esa uniformidad al código aplicando los
siguientes estándares:
Los nombres de las variables siempre en minúscula. Si el nombre fuere
compuesto la segunda palabra comienza en mayúscula, sin caracteres
auxiliares para separarlas.
Los nombres de los métodos comenzando en mayúscula siempre excepto
cuando es un nombre compuesto, en tal caso se aplica el procedimiento
inverso al de las variables.
Las propiedades con letra inicial mayúscula así sea compuesto o no el nombre.
Ninguno de los anteriores se compone de más de dos palabras, en idioma
inglés, y siempre lo más cercano posible a la información que almacenan, que
representan o a la función que realizan.
Al interior de cada clase el código se agrupa en regiones, denotadas según la
información que guardan, “Fields”, “Properties”, “Methods”, “Events”, etc.
El código se encuentra ampliamente comentariado, sobre todo los
procedimientos más complicados y los más abstractos.
Otros conceptos como el espacio entre operadores, la organización de las llaves,
paréntesis y corchetes; interlineado y signos de puntuación, son manejados por
Microsoft Visual Studio 2010.
CAPÍTULO III
71
3.7. Modelo lógico de datos
El modelo lógico de los datos se muestra a través del diagrama de clases
persistentes (Figura 3.7), representando los objetos que perduran en el tiempo y las
relaciones entre ellos.
Figura 3.7: Vista del Modelo Lógico de Datos
class Logical
*
1
1.. * 1
1.. *
1
*
1
*
1.. *
1.. *
1
1.. *
1
1.. *
11.. *
1
1.. *
1
CAPÍTULO III
72
3.8. Modelo Físico de los Datos
Dado que HYDRA dFBA no contempla el uso de una base de datos para el
almacenamiento y/o lectura de la información, se explica detalladamente la estructura
física que tiene un archivo .xml con datos de un Sistema Biológico.
Como se puede ver en la Figura 3.8 se cuenta con el nivel y la versión de SBML
empleado para estructurar el archivo, cada archivo SBML contiene información de un
Modelo, el cual es identificado por Id y Nombre. Principalmente un Modelo contiene
una lista de Compartimientos una de Especies y otra de Reacciones. Cada una de
estas cuenta con un identificativo (Id), y atributos específicos
Las Reacciones a su vez están conformadas por una lista de Reactantes, una de
Productos y otra de Parámetros. Los dos primeros no son más que Especies,
denotadas por su Id y un atributo nuevo que es la Estequiometría, la cual indica la
cantidad de estos que está presente en la expresión que rige la reacción . Los
Parámetros incluyen a los límites, inferiores y superiores y al coeficiente objetivo, que
a los fines de nuestro sistema siempre señalará a la ecuación de Biomasa.
CAPÍTULO III
73
Figura 3.8: Estructura física del archivo xml que contiene la información sobre el Sistema
Biológico.
CAPÍTULO III
74
3.9. Modelo de Implementación
El modelo de implementación describe cómo los elementos del modelo de diseño, se
implementan en términos de componentes. Describe también cómo se organizan los
componentes de acuerdo con los mecanismos de estructuración disponibles en el
entorno de implementación, en el lenguaje o lenguajes de programación utilizados y
cómo dependen los componentes unos de otros (Rumbaugh, et al., 2000).
El modelo de componentes del sistema propuesto es el siguiente:
Figura 3.9: Modelo de Componentes para HYDRA dFBA.
CAPÍTULO III
75
3.10. Modelo de Despliegue
El modelo de despliegue define la arquitectura física del sistema por medio de nodos
interconectados. Estos nodos son elementos de hardware sobre los cuales pueden
ejecutarse los elementos de software. (Rumbaugh, et al., 2000).En la Figura 3.10 se
muestra el modelo de despliegue para el sistema que se analiza.
Figura 3.10: Modelo de despliegue HYDRA dFBA En el nodo Computadora Personal (PC) se ejecuta el proceso HYDRA dFBA.exe,
nombre que recibe el ejecutable de la herramienta. Nótese que se cuenta con un solo
nodo, dado que el sistema no requiere de conectividad. Otros elementos presentes
son el archivo .xml con la información del Sistema Biológico, el cual será leído por el
sistema, los archivos que pueden ser salvados desde el software, ya sean imágenes
o datos y el fichero que se encarga de almacenar el historial de modelos cargados.
CAPÍTULO III
76
3.11. Implementación de la Ayuda
Toda aplicación informática debe contar con una ayuda que guie al usuario inexperto
en su uso, para de esta forma facilitar el trabajo con la herramienta. La ayuda de
HYDRA dFBA fue implementada con Help Maker. Esta es una herramienta de gran
utilidad para los desarrolladores de software, posee multitud de características y es
sencilla de usar. Entre las características de Help Maker, se destaca su capacidad
para generar archivos de diversos tipos (WinHelp, HTML Help, Website Help y PDF),
insertar hipervínculos, imágenes, objetos OLE, etc.
La Ayuda del sistema está diseñada mediante tópicos que corresponden con las
opciones de la aplicación (Figura 3.11), en cada uno de estos tópicos se realiza una
descripción detallada del funcionamiento del sistema, y al igual que la interfaz está
disponible en idioma Ingles.
Figura 3.11: Distribución de los temas de la Ayuda
CAPÍTULO III
77
Conclusiones del capítulo
Ha sido desarrollado el flujo de trabajo de Implementación para el sistema HYDRA
dFBA basado en la metodología RUP, describiéndose las tecnologías y herramientas
empleadas y obteniéndose los correspondientes artefactos. El sistema quedó
expresado en términos de componentes, así como las relaciones entre cada uno de
estos, y el nodo donde serán ejecutados, debido a que no se requiere conectividad.
Se definieron e implementaron los estándares para la interfaz gráfica de usuario, la
codificación y el tratamiento de errores. Se implementó la ayuda de la aplicación.
CONCLUSIONES
78
CONCLUSIONES
En la bibliografía consultada se evidenció que si bien hace diez años que se
cuenta con la extensión dinámica para el FBA (dFBA), esta es usada a diario
por la comunidad científica, siendo una útil herramienta para el trabajo con
redes metabólicas.
En el estudio que se realizó de los sistemas afines se encontró que, en
contraste con su probada utilidad, no existe un gran número de herramientas
que incorporen el dFBA entre sus prestaciones, a excepción de COBRA
Toolbox, no fue posible encontrar otro que permitiera aplicarlo, al menos no en
su estado puro.
Siguiendo la guía del Rational Unified Process (RUP) y haciendo uso del
Unified Modeling Language (UML) se diseñó y modeló un proyecto de
software orientado a obtener una herramienta computacional para simular en
redes metabólicas el dFBA, mediante una aproximación estática (SOA).
Como resultado del proyecto de software se desarrolló y obtuvo una
herramienta computacional que permite simular en redes metabólicas el dFBA,
mediante una aproximación estática (SOA).
Para la creación de la interfaces gráficas de usuario (GUI) se aplicaron
principios de diseño que garantizaron un producto atractivo, gráfico, amigable,
interactivo, etc., que en conjunción con la ayuda y el manual de usuarios
acercan el software a sus usuarios finales.
Atendiendo a los costos y al tiempo de producción, se puede afirmar que el
desarrollo del software fue factible.
RECOMENDACIONES
79
RECOMENDACIONES
Luego de hacer un análisis del trabajo desarrollado se propone lo siguiente:
Ampliar las funcionalidades de la herramienta con la implementación de la
aproximación dinámica (DOA) para el dFBA.
Extender los servicios prestados para modelos en formato de texto (.txt), que
son ampliamente usados.
REFERENCIAS BIBLIOGRÁFICAS
80
REFERENCIAS BIBLIOGRÁFICAS
Bajic, V. B., et al. (2003). «From informatics to bioinformatics». Proceedings of the
first Asia–Pacific bioinformatics conference on bioinformatics, Adelaide.
Borodina I, Nielsen J. 2005. From genomes to in silico cells via metabolic networks.
s.l. : Curr Opin Biotechnol, 2005.
Brazález, Alfonso, García de Jalón, Javier y Rodríguez, José Ignacio. 2001.
Aprenda Matlab. Madrid : Universidad Politécnica de Madrid, 2001.
Craig, Larman. 2004. UML y Patrones Introducción al análisis y diseño orientado a
objetos (I, II). La Habana : Editorial Félix Varela, 2004.
Eknoyan, G. 1999. Santorio Sanctorius (1561- 1636) - Founding father of metabolic
balance studies. 1999.
Enciclopedia Médica. 2006. Enciclopedia Médica. s.l. : Medline Plus, 2006.
Fell, D. 1996. Understanding the Control of Metabolism. Protland Press. 1996.
Fowler, Martin y S, K. 1999. UML Distilled Second Edition A Brief Guide. 1999.
Frederik P, Brooks. 1987. No Silver Bullet. Essence and Accidents in Software
Engineering. s.l. : IEEE Computer, 1987.
GLPK Proyect. 2010. Reference Manual for GLPK Version 4.45. 2010.
Hernández Díaz, Ana Beatriz . 2011. Sistema Automatizado para la Gestión de
Expedientes de Profesores. Pinar del Río : UPR “HERMANOS SAÍZ MONTES DE
OCA”, 2011.
Hernández, Enrique. El Lenguaje Unificado de Modelado (UML).
Hucka, Michael; Hoops, Stefan y Keating, Sarah Le. 2008. Nature Precedings.
Nature Precedings. [En línea] 2008. [Citado el: 14 de 12 de 2011.]
http://dx.doi.org/10.1038/npre.2008.2715.1. 2008.2715.1.
REFERENCIAS BIBLIOGRÁFICAS
81
Jacobson, Ivar; Booch, Grady y Rumbaugh, James. 2000. El Proceso Unificado de
Desarrollo de Software. 2000.
Kompala, D.S. 1984. Bacterial growth on multiple substrates. Experimental
verification of cybernetic models. Ph.D. thesis. Purdue University,West Lafayette, IN.
1984.
López, M, Romero, G. R y Vega, M. 2007. Informe de vigilancia tecnológica.
España : s.n., 2007.
Mahadevan, Radhakrishnan; Edwards, Jeremy S. y Doyle, Francis J. 2002.
Dynamic Flux Balance Analysis of Diauxic Growth in Escherichia coli. Biophysical
Juornal Volume 28. 09 de 2002.
McDaniel R, Weiss R. 2005. Advances in synthetic biology: on the path from
prototypes to applications. Biotechnology, 16: 476-83.
Mesarovic, M. D. 1968. Systems Theory and Biology-View of a Theoretician, in
System Theory and Biology. s.l. : M. D. Mesarovic, 1968.
Metabolism. The Online Etymology Dictionary. [En línea] [Citado el: 25 de 10 de
2011.]
Meyer, B. 1998. Construcción de software orientado a objetos. s.l. : Prentice-Hall,
1998.
Microsoft Corporation. 2010. MSDN. [En línea] Microsoft Corporation, 2010. [Citado
el: 25 de Enero de 2012.] http://msdn.microsoft.com/es-s/vcsharp/default.aspx.
Molpeceres, Alberto. 2002. Proceso de Desarrollo: Rup, XP y FDD. 2002.
National Center for Biotechnology Information. 2001. Bioinformatic. 2001.
Cuthrell, J. E y Biegler, L. T. 1987. On the optimization of differential. 33:1257–
1270, s.l. : AIChE J. , 1987.
Orth, Thiele y Palsson. 2010. What is flux balance analysis. 2010. volume 28
number 3.
REFERENCIAS BIBLIOGRÁFICAS
82
Pacheco Suárez, Yarlenis. 2011. Servicio Web Cliente orientado a la obtención de la
información biológica disponible en la Base de Datos Kegg. Pinar del Río : UPR
“HERMANOS SAÍZ MONTES DE OCA”, 2011.
Peralta, Mario. 2004. Estimación del esfuerzo basada en casos de uso. 2004.
Recio, F y Provencio, D. 2007. Plataforma .Net. 2007.
Riel, A. 1996. Object-Oriented Design Heuristics. s.l. : Addison-Wesley, 1996.
Rumbaugh, James; Jacobson, Ivar y Booch, Grady. 2000. El Lenguaje Unificado
de Modelado. Manual de Referencia. Madrid : ADDISON WESLEY, Pearson, 2000.
Santiago, María de Lourdes. Desarrollando aplicaciones Informáticas con el Proceso
de Desarrollo Unificado.
Savageau, M. A., E. O. , Voit y D. H., Irvine. 1987. Biochemical systems theory and
metabolic control theory: 1. Fundamental similarities and differences. Math. Biosci.
1987, 86:127–145.
Sbml Web Site. 2009. The Systems Biology Markup Language. [En línea] 18 de
Mayo de 2009. [Citado el: 14 de Diciembre de 2011.]
http://sbml.org/More_Detailed_Summary_of_SBML.
Sbml Web Site. 2009. The Systems Biology Markup Language. [En línea] 18 de
Mayo de 2009. [Citado el: 14 de Diciembre de 2011.]
http://sbml.org/Basic_Introduction_to_SBML.
Smith E, Morowitz H. 2004. Universality in intermediary metabolism. s.l. : Proc Natl
Acad Sci U S A , 2004.
Snoep JL, Bruggeman F, Olivier BG, Westerhoff HV. 2006. Towards building the
silicon cell: A modular approach. BioSystems, 83: 207-16.
Sparx, Geoffrey. 2008. Enterprise Architect User Guide. s.l. : Sparx Systems, 2008.
Stephanpoulos, G. 1999. Metabolic fluxes and metabolic engineering. Metab. 1999,
Vols. 1:1–11.
REFERENCIAS BIBLIOGRÁFICAS
83
The Rational egde: e-zine for the rational community. [En línea] [Citado el: 05 de 01
de 2012.] http://www.therationaledge.com/.
Triana Dopico, Julián, y otros. 2011. HYDRA: Una plataforma informática orientada
al diseño, análisis y visualización de redes metabólicas. Universidad de Pinar del Río.
Pinar del Río : s.n., 2011. 48-827-1-SP.
Varma, A y B. O, Palsson. 1994. Stoichiometric flux balance models quantitatively
predict growth and metabolic by-product secretion in wild-type Escherichia coli
W3110. s.l. : Appl. Environ. Microbiol., 1994.
Varner, J y D, Ramkrishna. 1999. Metabolic engineering from a cybernetic
perspective I. Theoretical preliminaries. 1999, 15: 407–425.
Yang X. S., 2008. Introduction to Computational Mathematics, World Scientific
Publishing.
BIBLIOGRAFÍA
84
BIBLIOGRAFÍA
Blaxter, Loraine; Hughes, Christina; Tight, Malcolm. Primera edición 2000. Cómo
se hace una Investigación.
Borodina I, Nielsen J. 2005. From genomes to in silico cells via metabolic networks.
s.l. : Curr Opin Biotechnol, 2005.
Brazález, Alfonso, García de Jalón, Javier y Rodríguez, José Ignacio. 2001.
Aprenda Matlab. Madrid : Universidad Politécnica de Madrid, 2001.
C#: Ventajas y desventajas. Disponible en
http://software.guides4it.com/ES/t/171327.aspx. Recuperado en marzo del 2012.
Craig, Larman. 2004. UML y Patrones Introducción al análisis y diseño orientado a
objetos (I, II). La Habana : Editorial Félix Varela, 2004.
Creación de Reportes con Crystal Reports. Disponible en
http://vbcodigopocketpc.blogspot.com/2009/01/creacin-de-reportes-con-crystal-
reports.html. Recuperado en enero del 2012.
Eknoyan, G. 1999. Santorio Sanctorius (1561- 1636) - Founding father of metabolic
balance studies. 1999.
Enciclopedia Médica. 2006. Enciclopedia Médica. s.l. : Medline Plus, 2006.
Fell, D. 1996. Understanding the Control of Metabolism. Protland Press. 1996.
Fowler, Martin y S, K. 1999. UML Distilled Second Edition A Brief Guide. 1999.
Frederik P, Brooks. 1987. No Silver Bullet. Essence and Accidents in Software
Engineering. s.l. : IEEE Computer, 1987.
GLPK Proyect. 2010. Reference Manual for GLPK Version 4.45. 2010.
Hernández Díaz, Ana Beatriz . 2011. Sistema Automatizado para la Gestión de
Expedientes de Profesores. Pinar del Río : UPR “HERMANOS SAÍZ MONTES DE
OCA”, 2011.
BIBLIOGRAFÍA
85
Hernández, Enrique. El Lenguaje Unificado de Modelado (UML).
Hucka, Michael; Hoops, Stefan y Keating, Sarah Le. 2008. Nature Precedings.
Nature Precedings. [En línea] 2008. [Citado el: 14 de 12 de 2011.]
http://dx.doi.org/10.1038/npre.2008.2715.1. 2008.2715.1.
Jacobson, Ivar; Booch, Grady y Rumbaugh, James. 2000. El Proceso Unificado de
Desarrollo de Software. 2000.
Kompala, D.S. 1984. Bacterial growth on multiple substrates. Experimental
verification of cybernetic models. Ph.D. thesis. Purdue University,West Lafayette, IN.
1984.
López, M, Romero, G. R y Vega, M. 2007. Informe de vigilancia tecnológica.
España : s.n., 2007.
Mahadevan, Radhakrishnan; Edwards, Jeremy S. y Doyle, Francis J. 2002.
Dynamic Flux Balance Analysis of Diauxic Growth in Escherichia coli. Biophysical
Juornal Volume 28. 09 de 2002.
Mesarovic, M. D. 1968. Systems Theory and Biology-View of a Theoretician, in
System Theory and Biology. s.l. : M. D. Mesarovic, 1968.
Metabolism. The Online Etymology Dictionary. [En línea] [Citado el: 25 de 10 de
2011.]
Meyer, B. 1998. Construcción de software orientado a objetos. s.l. : Prentice-Hall,
1998.
Microsoft Corporation. 2010. MSDN. [En línea] Microsoft Corporation, 2010. [Citado
el: 25 de Enero de 2012.] http://msdn.microsoft.com/es-s/vcsharp/default.aspx.
Molpeceres, Alberto. 2002. Proceso de Desarrollo: Rup, XP y FDD. 2002.
National Center for Biotechnology Information. 2001. Bioinformatic. 2001.
Cuthrell, J. E y Biegler, L. T. 1987. On the optimization of differential. 33:1257–
1270, s.l. : AIChE J. , 1987.
BIBLIOGRAFÍA
86
Orth, Thiele y Palsson. 2010. What is flux balance analysis. 2010. volume 28
number 3.
Pacheco Suárez, Yarlenis. 2011. Servicio Web Cliente orientado a la obtención de la
información biológica disponible en la Base de Datos Kegg. Pinar del Río : UPR
“HERMANOS SAÍZ MONTES DE OCA”, 2011.
Peralta, Mario. 2004. Estimación del esfuerzo basada en casos de uso. 2004.
Recio, F y Provencio, D. 2007. Plataforma .Net. 2007.
Reyes Chirino, R. 2010. Diseño de bases de datos biológicas, un paso hacia la
automatización del proceso de construcción de modelos a escala genómica. 2010.
Riel, A. 1996. Object-Oriented Design Heuristics. s.l. : Addison-Wesley, 1996.
Rodríguez, Eduardo A. 2008 .Procesos de software.
Rumbaugh, James; Jacobson, Ivar y Booch, Grady. 2000. El Lenguaje Unificado
de Modelado. Manual de Referencia. Madrid : ADDISON WESLEY, Pearson, 2000.
Santiago, María de Lourdes. Desarrollando aplicaciones Informáticas con el Proceso
de Desarrollo Unificado.
Savageau, M. A., E. O. , Voit y D. H., Irvine. 1987. Biochemical systems theory and
metabolic control theory: 1. Fundamental similarities and differences. Math. Biosci.
1987, 86:127–145.
Sbml Web Site. 2009. The Systems Biology Markup Language. [En línea] 18 de
Mayo de 2009. [Citado el: 14 de Diciembre de 2011.]
http://sbml.org/More_Detailed_Summary_of_SBML.
Sbml Web Site. 2009. The Systems Biology Markup Language. [En línea] 18 de
Mayo de 2009. [Citado el: 14 de Diciembre de 2011.]
http://sbml.org/Basic_Introduction_to_SBML.
Smith E, Morowitz H. 2004. Universality in intermediary metabolism. s.l. : Proc Natl
Acad Sci U S A , 2004.
Sparx, Geoffrey. 2008. Enterprise Architect User Guide. s.l. : Sparx Systems, 2008.
BIBLIOGRAFÍA
87
Stephanpoulos, G. 1999. Metabolic fluxes and metabolic engineering. Metab. 1999,
Vols. 1:1–11.
The Rational egde: e-zine for the rational community. [En línea] [Citado el: 05 de 01
de 2012.] http://www.therationaledge.com/.
Triana Dopico, Julián, y otros. 2011. HYDRA: Una plataforma informática orientada
al diseño, análisis y visualización de redes metabólicas. Universidad de Pinar del Río.
Pinar del Río : s.n., 2011. 48-827-1-SP.
Grupo Intertech/UPR. 2011. Herramientas Computacionales Integrales para el
Diseño, Modelización y Análisis en Biología de Sistemas: Aplicaciones a la
Producción de Biocombustibles. 2011.
Varma, A y B. O, Palsson. 1994. Stoichiometric flux balance models quantitatively
predict growth and metabolic by-product secretion in wild-type Escherichia coli
W3110. s.l. : Appl. Environ. Microbiol., 1994.
Varner, J y D, Ramkrishna. 1999. Metabolic engineering from a cybernetic
perspective I. Theoretical preliminaries. 1999, 15: 407–425.
ANEXOS
88
ANEXOS
ANEXO I ANÁLISIS DE FACTIBILIDAD
1. Cálculo de los Puntos de Casos de Uso (PCU) sin ajustar : En esta instancia se calculan los Puntos de Casos de Uso sin ajustar a partir de la
siguiente ecuación:
Donde,
PCU: Puntos de Casos de Uso sin ajustar.
FPA: Factor de Peso de los Actores sin ajustar.
FPCU: Factor de Peso de los Casos de Uso sin ajustar.
1.1. Factor de Peso de los Actores sin ajustar (FPA)
Se determina teniendo en cuenta la cantidad de actores y su complejidad, un actor
puede ser simple (1), medio (2) o complejo (3). Un actor tiene valor de complejidad 1
si se trata de otro sistema que interactúa mediante una interfaz de programación,
tiene valor de complejidad 2 si es otro sistema que interactúa mediante un protocolo o
una interfaz basada en texto y 3 si es una persona que interactúa mediante interfaz
gráfica. HYDRA dFBA cuenta con 1 actor (usuario): el cual interactúa con el sistema
mediante una interfaz gráfica, de ahí que su FAP tiene valor 3.
1.2. Factor de Peso de los Casos de Uso sin ajustar (FPCU)
Se calcula mediante un análisis de la cantidad de Casos de Uso presentes en el
sistema y la complejidad de cada uno de ellos. La complejidad de un Caso de Uso se
determina a partir de la cantidad de transacciones que este posee. Un Caso de Uso
será de tipo Simple cuando posee menos de cuatro transacciones (peso cinco),
Medio cuando posee de cuatro a siete transacciones (peso diez) y Complejo cuando
posee más de siete transacciones (peso quince).
El sistema cuenta con siete casos de usos de complejidad simple, uno de complejidad
media y ocho de complejidad alta (Tabla 4.1), por tanto su FPCU tiene un valor 165.
ANEXOS
89
Una vez obtenidos los valores de FPA y FPCU, los Puntos de Casos de Uso sin
ajustar resultan
Simples Medios Complejos
Cargar Sistema Biológico Explorar Detalles de la reacción
Modificar Limites de la Reacción
Cerrar Sistema Biológico Correr Simulación
Consultar Ayuda Consultar Gráficos
Explorar Modelo Consultar Gráficos de Substratos
Gestionar Área de Simulación
Salvar Imagen de Gráficos
Gestionar Substratos Concentración constate
Solicitar Distribución de Flujos.
Solicitar Historial Biomasa Solicitar Matriz de Concentración
Salvar Datos
Tabla 4.1: Clasificación de los Casos de Uso según su complejidad.
ANEXOS
90
Paso 2: Cálculo de Puntos de Casos de Uso ajustados.
Después que se tienen los Puntos de Casos de Uso sin ajustar, estos se deben
ajustar:
Donde,
: Puntos de Casos de Uso ajustados
: Puntos de Casos de Uso sin ajustar
: Factor de complejidad técnica
: Factor de ambiente
2.1 Factor de complejidad técnica (FCT)
Se calcula mediante la cuantificación del peso de un conjunto de factores que
determinan la complejidad técnica del sistema, estos factores se cuantifica con un
valor de cero a cinco. El Factor de complejidad técnica se calcula mediante la
siguiente ecuación:
Después de realizar estos cálculos (Tabla 4.2), el FCT para HYDRA dFBA resultó ser
0.965
Métrica Descripción Peso Valor FCT Justificación
FCT01 Sistema distribuido. 2.00 0.00 0.00 El sistema es centralizado.
FCT02
Objetivos de
performance o tiempo
de respuesta.
1.00 4.00 5.00
La velocidad es limitada por
la capacidad de cómputo
del hardware.
FCT03 Eficiencia del usuario
final. 1.00 2.00 2.00
Escasas restricciones de
eficiencia.
FCT04 Procesamiento interno
complejo. 1.00 5.00 5.00
Existe un procesamiento
interno complejo de los
datos.
ANEXOS
91
FCT05 El código debe ser
reutilizable. 1.00 4.00 4.00
Algoritmos y procesos
deben ser reutilizables.
FCT06 Facilidad de
instalación. 0.50 5.00 2.50
Se requiere que la
aplicación sea fácil de
instalar.
FCT07 Facilidad de uso. 0.50 4.00 2.00 Se requiere que la
aplicación sea fácil de usar.
FCT08 Portabilidad. 2.00 5.00 10.00
Se brindarán ambas
opciones, instalador y
versión portable.
FCT09 Facilidad de cambio. 1.00 3.00 3.00
Se requiere un costo
moderado de
mantenimiento.
FCT10 Concurrencia. 1.00 0.00 0.00 No hay concurrencia.
FCT11
Incluye objetivos
especiales de
seguridad.
1.00 3.00 3.00 Seguridad normal.
FCT12 Provee acceso directo
a terceras partes. 1.00 0.00 0.00 No provee acceso directo.
FCT13
Facilidades especiales
de entrenamiento a
usuarios.
1.00 0.00 0.00
No se requieren facilidades
especiales de
entrenamiento a usuarios.
Total: 36.50
Tabla 4.2: Factor de complejidad técnica (FCT)
2.2 Factor de ambiente (FA)
Se estima a partir de un grupo de factores relacionados con las habilidades y el
entrenamiento del equipo de desarrollo. Al igual que el cálculo del FCT, se trata de un
ANEXOS
92
conjunto de factores que se cuantifican con valores de cero a cinco. El Factor de
ambiente se calcula mediante la siguiente ecuación: –
Al realizar los cálculos para FA, se obtuvo el valor 0.71 (Tabla 4.3). Una vez obtenido
el FCT y el FA, se calcula el PCUA, además de ya conocer desde el paso 1 los
puntos de casos de uso sin ajustar (PCU).
Métrica Descripción Peso Valor FA Justificación
FA01
Familiaridad con el
modelo de proyecto
utilizado.
1.50 3.00 4.50 Conocimientos medios del
modelo utilizado.
FA02 Experiencia en la
aplicación. 0.50 2.00 1.00
Se ha trabajado con este
tipo de aplicaciones, pero el
concepto es nuevo.
FA03 Experiencia en
orientación a objetos. 1.00 5.00 5.00
Se ha programado
orientado a objetos.
FA04 Capacidad del
analista líder. 0.50 5.00 2.50
El analista líder tiene buena
preparación y experiencia.
FA05 Motivación. 1.00 5.00 5.00 Altamente motivado.
FA06 Estabilidad de los
requerimientos. 2.00 4.00 8.00
No hay grandes cambios en
los requerimientos.
ANEXOS
93
FA07 Personal part-time. -1.00 0.00 0.00 Full-time.
FA08 Dificultad del lenguaje
de Programación. -1.00 3.00 -3.00
Se usará C# como lenguaje
de programación.
Total: 23.00
Tabla 4.3: Factor de Ambiente (FA)
Paso 3: Cálculo del Esfuerzo de Implementación (E):
Se convierten los Puntos de Casos de Uso Ajustados a esfuerzo de desarrollo. El
esfuerzo en horas-hombre viene dado por:
Donde,
Esfuerzo estimado en horas-hombre
: Puntos de Casos de Uso ajustados
: Factor de Conversión
El Factor de Conversión ( ), denota la cantidad de horas-hombre/Punto de Casos
de Uso y se determina según el siguiente criterio:
Se contabilizan cuántos factores de los que afectan al factor de ambiente están
por debajo del valor medio (tres), para los factores E1 a E6.
Se contabilizan cuántos factores de los que afectan al factor de ambiente están
por encima del valor medio (tres), para los factores E7 y E8.
Si el total es dos o menos, se utiliza el factor de conversión veinte horas-
hombre/Punto de Casos de Uso.
Si el total es tres o cuatro, se utiliza el factor de conversión 28 horas-
hombre/Punto de Casos de Uso.
ANEXOS
94
Según este criterio, se obtuvo que existe uno por debajo de tres para los factores E1
a E6 y cero por encima de tres para los factores E7 y E8, por tanto el total es uno y se
utiliza como FC 20 horas-hombre/Punto de Casos de Uso.
Se calcula el esfuerzo estimado en horas-hombre:
Conociendo que la implementación representa un 40% del tiempo de desarrollo de un
software, se obtiene el esfuerzo total y la distribución por cada una de las etapas del
proceso de desarrollo (Tabla 4.4).
Actividad Porcentaje
% Horas-Hombres
Análisis 5 407.08
Diseño 25 2035.38
Implementación 40 3256.60
Pruebas 20 1628.30
Sobrecarga (otras actividades) 10 814.50
Total: 8141.50
Tabla 4.4: Esfuerzo del proyecto
Paso 4: Estimación del tiempo de desarrollo del proyecto
A partir del esfuerzo se puede estimar el tiempo de desarrollo aproximado del proyecto:
Donde,
: Tiempo de desarrollado del proyecto
: Esfuerzo total
: Cantidad de hombres que desarrollan el proyecto.
En la construcción de HYDRA dFBA participó una persona, por tanto:
ANEXOS
95
Paso 5: Estimación del costo de desarrollo del proyecto
El costo total se obtiene mediante la siguiente ecuación:
Donde,
: Costo total
: Costo del proyecto
Donde,
: Costo por hombre - hora
Donde,
: Coeficiente que tiene en cuenta los costos indirectos (1,5 y 2,0)
: Tarifa Horaria Promedio. El salario promedio de las personas que trabajan en el
proyecto dividido entre 160 horas.
El salario promedio para el desarrollador fue $100, de ahí se obtiene igual a
0.625, por lo tanto:
Con los resultados anteriores se obtiene:
ANEXOS
96
ANEXO II: LICENCIA CeCILL V2
The purpose of this Free Software license agreement is to grant users the right to
modify and redistribute the software governed by this license within the framework of
an open source distribution model.
The exercising of these rights is conditional upon certain obligations for users so as to
preserve this status for all subsequent redistributions.
In consideration of access to the source code and the rights to copy, modify and
redistribute granted by the license, users are provided only with a limited warranty and
the software's author, the holder of the economic rights, and the successive licensors
only have limited liability.
In this respect, the risks associated with loading, using, modifying and/or developing
or reproducing the software by the user are brought to the user's attention, given its
Free Software status, which may make it complicated to use, with the result that its
use is reserved for developers and experienced professionals having in-depth
computer knowledge. Users are therefore encouraged to load and test the suitability of
the software as regards their requirements in conditions enabling the security of their
systems and/or data to be ensured and, more generally, to use and operate it in the
same conditions of security. This Agreement may be freely reproduced and published,
provided it is not altered, and that no provisions are either added or removed
herefrom.
This Agreement may apply to any or all software for which the holder of the economic
rights decides to submit the use thereof to its provisions.
CeCILL stands for Ce(a) C(nrs) I(nria) L(ogiciel) L(ibre)
Version 2.0 dated 2006-09-05.
Texto completo disponible en: http://www.cecill.info".
ANEXOS
97
ANEXO III: MATRIZ DE TRAZABILIDAD REQUERIMIENTOS-CASOS DE USO
Ca
rgar
Sis
tem
a B
ioló
gic
o
Ce
rra
r S
iste
ma
Bio
lóg
ico
Co
ns
ult
ar
Ay
ud
a
Co
ns
ult
ar
grá
fic
o d
e s
ub
str
ato
s
Co
ns
ult
ar
grá
fic
os
Co
rre
r sim
ula
ció
n
Ex
plo
rar
Mo
de
lo
Ex
plo
rar
deta
lle
s d
e la
re
ac
ció
n
Ge
sti
on
ar
are
a d
e s
imu
lació
n
Ge
sti
on
ar
su
bstr
ato
s c
on
co
nce
ntr
ac
ión
co
nsta
nte
Mo
dif
icar
lím
ite
s d
e l
a R
eac
ció
n
Sa
lva
r d
ato
s
Sa
lva
r im
ag
en
del g
ráfi
co
So
lic
ita
r D
istr
ibu
ció
n d
e F
lujo
s
So
lic
ita
r H
isto
rial d
e B
iom
asa
So
lic
ita
r M
atr
iz d
e C
on
cen
tra
ció
n
R.F. 1 Leer datos
del Sistema
Biológico
X
R.F. 10 Mostrar
información
detallada de las
Reacciones
X
R.F. 10.1 Salvar
información
detallada de las
Reacciones
X
R.F. 11 Actualizar el
Límite Inferior de las
Reacciones
X
R.F. 12 Actualizar el
Límite Superior de
las Reacciones
X
R.F. 13 Habilitar
área de simulación X
R.F. 14 Listar
substratos para
reacciones de
intercambio
X
ANEXOS
98
R.F. 15 Listar
reacciones de
intercambio
X
R.F. 16 Mostrar
ayuda lateral para el
área de simulación
X
R.F. 17 Recibir
Reacciones de
Intercambio
constantes
X
R.F. 18 Quitar
Reacciones de
Intercambio
X
R.F. 19 Recibir del
usuario Biomasa
Inicial
X
R.F. 2 Normalizar el
Id de las Especies
del Modelo
X
R.F. 20 Recibir del
usuario Intervalo de
Tiempo
X
R.F. 21 Recibir del
usuario Número de
Intervalos
X
R.F. 22 Permitir al
usuario cambiar la
concentración de
substrato
X
R.F. 24 Mostrar los
resultados de la
simulación
X
R.F. 25 Salvar los
resultados de la
simulación
X
R.F. 26 Interrumpir
la simulación por
solicitud del usuario
R.F. 27 Graficar la
concentración de
Biomasa
X
R.F. 28 Graficar la
concentración de los
substratos
X
ANEXOS
99
R.F. 29 Salvar los
gráficos en formato
(.jpg)
X
R.F. 3 Normalizar el
Id de las Reacciones
del Modelo
X
R.F. 30 Mostrar la
Distribución de
Flujos
X
R.F. 31 Salvar la
Distribución de
Flujos
X
R.F. 32 Mostrar un
Historial de Biomasa X
R.F. 33 Salvar
Historial de Biomasa X
R.F. 34 Mostrar
Matriz de
Concentración
X
R.F. 36 Salvar
Matriz de
Concentración
X
R.F. 37 Abandonar
el área de
simulación
X
R.F. 38 Cerrar el
Modelo abierto X
R.F. 39 Guardar un
historial Modelos
recientes
X
R.F. 4 Construir la
Matriz
Estequeométrica del
Modelo
X
R.F. 40 Consultar la
Ayuda X
R.F. 5 Buscar las
Reacciones de
Intercambio del
Modelo
X
R.F. 6 Buscar la
Reacción de
Biomasa del Modelo
X
R.F. 7 Llevar las
Reacciones a su X
ANEXOS
100
forma matemática
R.F. 8 Mostrar
resumen del
Sistema Biológico
X
R.F. 9 Mostrar datos
del Sistema
Biológico
X
R.F.23 Correr la
simulación X
ANEXO IV ESPECIFICACIÓN DE LOS CASOS DE USO MÁS SIGNIFICATIVOS
Caso de Uso: Cargar Sistema Biológico
Actor: Usuario (inicia)
Propósito: Obtener del Sistema Biológico datos necesarios para
realizar la simulación.
Resumen:
El caso de uso se inicia cuando el Usuario decide cargar
un Sistema Biológico, haciendo uso de alguna de las tres
opciones disponibles para ello (1) a través del “Menú File”,
(2) directamente desde la barra de herramientas
”Standar", ambas descritas en la sección “Buscar
Archivo”, (3) haciendo uso del historial de modelos
recientes, sección “Modelos Recientes”. El sistema crea
un modelo virtual con los datos que necesita y le informa
al usuario que modelo fue leído, finalizando así el curso
normal de los eventos.
Referencias: R.F 1 R.F 8.
Precondiciones:
Ningún otro Sistema Biológico puede estar abierto.
Para usar la opción Modelo Recientes, algún Modelo
debe haber sido previamente abierto.
Poscondiciones: Se cuenta con parte de la información necesaria para
realizar las simulaciones.
ANEXOS
101
Interfaz 1
Interfaz 1.1
Interfaz 1.2
Interfaz 1.3
B A
C
ANEXOS
102
Interfaz 2
ANEXOS
103
Interfaz 3
Curso Normal de los Eventos
Sección: Buscar archivo.
Acciones del Actor Respuesta del Sistema
1. El Usuario selecciona la
opción “Open Sbml Model”
desde la barra de
herramientas “Estándar
toolbox” (B) o desde el
menú “File” (A).
1.1. El sistema muestra el cuadro de dialogo “Open
Sbml Model” (Interfaz 2), para que el usuario
busque el archivo (.xml) que contiene la
información del Sistema Biológico. Se cuenta
con un filtro "Xml files (*.xml), para minimizar el
número de estados erróneos.
2. El Usuario recorre la ruta
hasta el archivo que desea
abrir y se lo indica al
sistema.
2.1. El sistema lee los datos requeridos del archivo
(ver R.F. del 1 al 1.3.5.8).
2.2. El sistema normaliza el Id de las Especies del
Modelo (R.F. 2).
2.3. El sistema normaliza el Id de las Reacciones del
Modelo (R.F. 3).
D E
H
F
G
ANEXOS
104
2.4. El sistema construye la Matriz Estequeométrica
del Modelo (R.F. 4).
2.5. El sistema busca las Reacciones de Intercambio
del Modelo. (R.F. 5).
2.6. El sistema busca la Reacción de Biomasa del
Modelo (R.F. 6).
2.7. El sistema lleva las Reacciones a su forma
matemática (R.F. 7).
2.8. El sistema actualiza la lista de Modelos
Recientes (R.F. 30) (C).
2.9. El sistema muestra en pantalla un resumen del
Modelo leído (R.F. 8) (H), y habilita las
opciones:
a-) Solicitar Área de Simulación (E, F). (C. U. S)
b-) Explorar Modelo (G). (C. U. S)
c-) Cerrar Modelo (D). (C. U. S)
2.10. Durante el tiempo que dure el proceso de
cargado del Modelo, el sistema mantendrá al
usuario informado del progreso de las
actividades, mediante el uso de barras de
progreso y etiquetas de texto. (Interfaz 1.1, 1.2,
1.3).
Sección : Modelos recientes
1. El Usuario selecciona el link
que hace referencia al
Sistema Biológico que
desea cargar, desde el
historial de modelos
recientes (C).
1.1. El sistema realiza los pasos del 2.1 al 2.10 de
la sección “Buscar archivo”.
Cursos Alternos
ANEXOS
105
Mensaje 1
Mensaje 2
Mensaje 3
Mensaje 4
ANEXOS
106
Mensaje 5
Mensaje 6
Mensaje 7
Mensaje 8
ANEXOS
107
Mensaje 9
Mensaje 10
1. Sección “Buscar
archivo” línea 2.1
1.1. Si el archivo indicado por el usuario no es un archivo
xml válido, se muestra el Mensaje 1 y se interrumpe el
curso normal de eventos.
1.2. Si el archivo indicado por el usuario no es un archivo
Sbml válido, o pertenece a un nivel y/o versión no
soportada por el sistema se muestra el Mensaje 2 y
se interrumpe el curso normal de eventos.
1.3. Si el archivo indicado por el usuario no contiene
información sobre ningún modelo biológico, se
muestra el Mensaje 3 y se interrumpe el curso normal
de eventos.
1.4. Si en el archivo indicado por el usuario no se
encuentra información referente a los
Compartimientos, se muestra el Mensaje 4 y se
interrumpe el curso normal de eventos.
1.5. Si en el archivo indicado por el usuario la información
sobre los Compartimientos no se encuentra en el
formato esperado, se muestra el Mensaje 5 y se
ANEXOS
108
interrumpe el curso normal de eventos.
1.6. Si en el archivo indicado por el usuario no se
encuentra información referente a la Especies, se
muestra el Mensaje 6 y se interrumpe el curso normal
de eventos.
1.7. Si en el archivo indicado por el usuario la información
sobre las Especies no se encuentra en el formato
esperado, se muestra el Mensaje 7 y se interrumpe el
curso normal de eventos.
1.8. Si en el archivo indicado por el usuario no se
encuentra información referente a las reacciones, se
muestra el Mensaje 8 y se interrumpe el curso normal
de eventos.
1.9. Si en el archivo indicado por el usuario la información
sobre las reacciones no se encuentra en el formato
esperado, se muestra el Mensaje 9 y se interrumpe el
curso normal de eventos.
2. Sección “Modelos
recientes” línea 2.1
2.1. Si el archivo al que señala el link seleccionado por el
usuario, fue movido, renombrado, eliminado y/o no se
tiene acceso a la ruta en que este se localiza, se
muestra el Mensaje 10 y se interrumpe el curso
normal de eventos.
Prioridad: Alta.
Caso de Uso: Correr Simulación
Actor: Usuario (inicia)
Propósito: Obtener los resultados de la simulación y habilitar el
uso de los servicios que necesitan de esos.
Resumen:
Se inicia cuando el usuario introduce los datos
necesarios, biomasa, intervalo de tiempo y número
de intervalos, opcionalmente puede seleccionar de
la lista de reacciones de intercambio cuales de estas
ANEXOS
109
van a poseer una concentración de substratos
constante (CU Gestionar substratos con
concentración constante) y le solicita al sistema
realizar la simulación con los mismos, el sistema
verifica la validez e integridad de estos y comienza
realizar la simulación hasta el número de intervalos
indicado por el usuario, o hasta que los nutrientes se
agoten. Los resultados que se van obteniendo para
cada iteración son presentados dinámicamente al
usuario. Una vez terminada la simulación, por
cualquiera de los motivos antes expuestos se le
hace saber al usuario. Para finalizar el caos de uso
el sistema activa las herramientas que harán uso de
estos resultados.
Referencias:
R.F 19 24.
Casos de uso Asociados:
o Solicitar Matriz de Concentración.
o Solicitar Distribución de Flujos.
o Consultar Gráficos.
o Salvar Datos.
o Abortar Simulación en Curso.
o Gestionar substratos con concentración
constante.
o Solicitar Historial de Biomasa.
ANEXOS
110
Poscondiciones:
El área de simulación debe estar visible.
Los vectores de tiempo y biomasa para la
simulación son obtenidos.
La opción para consultar la Matriz de
concentración es activada (CU Solicitar Matriz de
Concentración).
La opción para consultar la distribución de flujos
es activada (CU Solicitar Distribución de Flujos).
La opción para consultar los gráficos es activada
(CU Consultar Gráficos).
La opción para salvar los datos de la simulación
es activada (CU Salvar Datos).
Si es la primera ejecución del caso de uso, la
opción para consultar el historial de biomasa es
activada (CU Solicitar Historial de Biomasa).
Interfaz 1
A
B
C
D
E
F
G H
I J
K
L M N O
P
ANEXOS
111
Mensaje 1
Curso Normal de los Eventos
Acciones del Actor Respuesta del Sistema
1. El Usuario entra los valores
para la biomasa inicia (A), el
intervalo de tiempo (B) y el
número de intervalos (C).
2. El usuario gestiona los
substratos con concentración
constante (D) (opcional).
3. El usuario ajusta los límites
inferiores (Lb) (E) y los
valores de concentración (F)
para los substratos de
intercambio, a su gusto.
4. El usuario acciona el botón
de iniciar Run dfba (G).
4.1. El sistema crea un nuevo hilo de ejecución
(Thread), para que el proceso pueda
ejecutarse independientemente, sin bloquear
la interfaz de usuario.[motivo por el cual se
deben deshabilitar las opciones que puedan
crear conflictos con el proceso de simulación]
4.2. El sistema deshabilita el botón Run dFBA (G).
4.3. El sistema chequea que los parámetros
iniciales (A, B, C) entrados por usuario
tengan el formato requerido.
4.4. El sistema chequea que los valores para el Lb
(E) y la Concentración (F) tengan el formato
requerido.
4.5. El sistema actualiza en el modelo biológico los
límites inferiores (Lb) de las reacciones de
intercambio, entrados por el usuario,
validando que su formato sea correcto.
4.6. El sistema crea el vector de concentración
para los substratos de intercambio, validando
que su formato sea correcto.
4.7. El sistema deshabilita las opciones de la
interfaz (L, M, N, O) que requieren de los
resultados de la simulación (si es la primera
ANEXOS
112
corrida, estas están deshabilitadas por
defecto).
4.8. El sistema activa el botón para abortar (H) la
simulación en curso si el usuario así lo desea.
4.9. El sistema comienza a realizar la simulación,
mostrando los valores de tiempo (I) y biomasa
(J) para cada una de las iteraciones, a medida
que estos son obtenidos (tiempo real), y
mediante la barra de estado (K) muestra el
progreso del proceso.
4.10. El sistema construye la matriz de
concentración, almacena los vectores de
tiempo y biomasa, como parte del resultado
de la simulación, el cual será usado para otros
servicios, adicionan los vectores de tiempo y
biomasa al historial de biomasa, el cual
trascenderá todas las simulaciones realizadas
sobre un mismo modelo.
4.11. El sistema muestra un mensaje de
confirmación para que se conozca que el
proceso de simulación concluyo
satisfactoriamente (Mensaje 1).
5. El usuario acepta el Mensaje
1
5.1. El sistema desactiva la opción de abortar
simulación y la barra de estado (H, K).
5.2. El sistema activa la opción para iniciar una
nueva simulación (G).
5.3. El sistema activa las opciones:
o Salvar resultados de la simulación (P).
o Consultar gráficos (L).
o Consular distribución de flujo (M).
o Consultar Historial de biomasa (N).
o Consultar Matriz de concentración (O).
ANEXOS
113
Cursos Alternos
Mensaje 2
Mensaje 3
Mensaje 4
Mensaje 5
ANEXOS
114
Mensaje 6
Mensaje 7
Mensaje 8
1. Línea 4.3
1.1. Si el valor para la biomasa inicial (A) no tiene
el formato requerido, se interrumpe el curso
normal de eventos y se muestra el Mensaje 2.
1.2. Si el valor para el intervalo de tiempo (B) no
tiene el formato requerido, se interrumpe el
curso normal de eventos y se muestra el
Mensaje 3.
1.3. Si el valor para el numero de intervalos (C) no
tiene el formato requerido, se interrumpe el
curso normal de eventos y se muestra el
Mensaje 4.
ANEXOS
115
2. Línea 4.4 2.1. Si alguno de los valores para los límites
inferiores (E) no tiene el formato requerido, se
interrumpe el curso normal de eventos y se
muestra el Mensaje 5, indicando donde se
localiza el error.
2.2. Si alguno de los valores para las
concentraciones (F) no tiene el formato
requerido, se interrumpe el curso normal de
eventos y se muestra el Mensaje 6, indicando
donde se localiza el error.
3. Línea 4.11
3.1. Si el agotamiento de alguno de los substratos
(Concentración =0), influye directamente en el
crecimiento de la biomasa resultante
(crecimiento =0), se interrumpe el proceso de
simulación y esta se da por concluida,
computándose solo los resultados que se
tiene hasta el momento, se muestra el
Mensaje 7. El curso normal de eventos,
continua una vez que el usuario acepta el
mensaje, el paso 4.11 no es realizado.
4. Líneas 4.8 – 4.10 4.1. Si durante el transcurso de la simulación el
usuario acciona el botón Abortar (H), el
sistema interrumpe el proceso de simulación y
esta se da por concluida, computándose solo
los resultados que se tiene hasta el momento,
se muestra el Mensaje 8. El curso normal de
eventos, continua una vez que el usuario
acepta el mensaje, el paso 4.11 no es
realizado.
Prioridad: Alta.
ANEXOS
116
Caso de Uso: Consultar gráficos
Actor: Usuario (inicia)
Propósito: Acceder a las herramientas para graficar la
biomasa resultante de la simulación.
Resumen:
El caso de Uso inicia, cuando, una vez
ejecutado el caso de uso Correr simulación, el
usuario selecciona de la interfaz principal la
opción gráficos (Charts); el sistema busca en el
resultado de la simulación, los vectores de
tiempo y de biomas, y muestra una nueva
ventana, donde estos son mostrados en forma
de gráfico (biomasa/tiempo), el gráfico puede
ser visualizado en barras, columnas, área o
línea de pasos, según el deseo del usuario, y en
el color escogido por este.
Referencias:
R.F 27.
Casos de Usos asociados:
o Consultar gráficos de substratos.
o Salvar imagen del gráfico.
Precondiciones: Se tiene que haber realizado alguna
simulación sobre el modelo abierto.
Poscondiciones: La concentración de biomasa es graficada e
función del tiempo y presentada al usuario.
ANEXOS
117
Interfaz 1
Interfaz 2
Curso Normal de los Eventos
A B C D E F
G
H
I
J
A1
ANEXOS
118
Acciones del Actor Respuesta del Sistema
1. El Usuario selecciona de la
Interfaz Principal (Interfaz 1) la
opción gráficos (Charts) (A1).
1.1. El sistema busca en los resultados de la
última simulación realizada sobre el modelo
abierto, los vectores de tiempo y de
biomasa.
1.2. El sistema busca en la matriz de
concentración de la última simulación los
nombres de todos los substratos graficables
(concentración distinta de cero en al menos
dos iteraciones).
1.3. El sistema muestra la Interfaz 2, donde se
visualiza:
o Gráfico (de barras por defecto) (I), donde
se representa la concentración de
biomasa (H), en función del tiempo (G).
o Opción para gráfico de Barras (A).
o Opción para gráfico de Área (B).
o Opción para gráfico de Columnas (C).
o Opción para gráfico de Línea de Pasos
(D).
o Opción para salvar el gráfico como
imagen (E). (CU Salvar Imagen del
gráfico).
o Opción para cambiar el color (F).
o Lista de los substratos graficables (J).
Para graficar los substratos. (CU
Consultar Gráficos de Substratos).
Prioridad: Media.
ANEXOS
119
Caso de Uso: Consultar gráficos de substratos
Actor: Usuario (inicia)
Propósito: Graficar los substratos graficables.
Resumen:
El caso de uso inicia, cuando, una vez
ejecutado el caso de uso Consultar gráficos, el
usuario decide consultar gráficos para los
substratos de intercambio. El usuario selecciona
de la lista el substrato que desea graficar, ante
lo cual el sistema busca en la matriz de
concentraciones la columna que se corresponde
con dicho elemento, y lo representa en un
gráfico de concentración/tiempo, el gráfico
puede ser visualizado en barras, columnas, área
o línea de pasos, según el deseo del usuario, y
en el color escogido por este, finalizando de
esta forma el caso de uso.
Referencias:
R.F 28.
Casos de Usos asociados:
o Consultar gráficos.
o Salvar imagen del gráfico.
Precondiciones:
Se tiene que haber ejecutado el caso de uso
Consultar Gráficos
Tiene que haber al menos un substrato
graficable.
Poscondiciones:
La concentración del substrato seleccionado
es graficada e función del tiempo y
presentada al usuario.
ANEXOS
120
Interfaz 1
A1
ANEXOS
121
Interfaz 2
Curso Normal de los Eventos
Acciones del Actor Respuesta del Sistema
1. El Usuario selecciona de la
interfaz para el área de los
gráficos (Interfaz 1) la lista de los
substratos graficables (A1), y de
ellos el que desea graficar.
1.1. El sistema busca en la matriz de
concentración de la última simulación la
columna los valores de tiempo y
concentración que se corresponden con
el substrato seleccionado.
1.2. El sistema muestra la Interfaz 2, donde
se visualiza:
A
B D E F
H
I G
C
ANEXOS
122
o Gráfico de substratos (de barras por
defecto) (I), donde se representa la
concentración del substrato
seleccionado (G), en función del
tiempo (H).
o Opción para gráfico de Barras (A).
o Opción para gráfico de Área (B).
o Opción para gráfico de Columnas (C).
o Opción para gráfico de Línea de
Pasos (D).
o Opción para salvar el gráfico como
imagen (E). (CU Salvar Imagen del
gráfico).
o Opción para cambiar el color (F).
Prioridad: Media.
Caso de Uso: Salvar imagen del gráfico.
Actor: Usuario (inicia)
Propósito: Salvar el gráfico como imagen (.jpg).
Resumen:
El caso de Uso inicia, cuando, después de ejecutarse el
caso de uso Consultar gráficos y/o el caso de uso
Consultar gráficos de substratos, el usuario decide salvar
una copia del grafico en pantalla, como imagen (.jpg) en
el disco duro. El sistema garantiza que el usuario escoja
la ruta y el nombre deseados, y crea la imagen,
finalizando el caso de uso.
Referencias:
R.F 29.
Casos de Usos asociados:
o Consultar gráficos.
o Consultar gráficos de substratos.
Precondiciones: Se tiene que haber ejecutado el casos de uso
ANEXOS
123
Consultar gráficos.
Poscondiciones: La imagen del grafico es salvada.
Interfaz 1
A B
ANEXOS
124
Interfaz 2
Mensaje 1
Curso Normal de los Eventos
Acciones del Actor Respuesta del Sistema
1. El Usuario selecciona de la Interfaz
para el área de gráficos (Interfaz 1), la
opción para salvar el grafico como
imagen(A, B).
1.1. El sistema muestra el cuadro de
dialogo para que el usuario
especifique el nombre y la ruta donde
desea que se salve la imagen del
gráfico.
2. El usuario introduce el nombre para el
archivo e indica la ruta done desea
salvarlo.
2.1. El sistema crea el archivo, cierra el
cuadro de dialogo e indica al usuario
que la operación se realizó
(Mensaje 1).
Prioridad: Baja.
Caso de Uso: Solicitar distribución de flujos.
Actor: Usuario (inicia)
Propósito:
Mostrar en pantalla la distribución de flujos para
la iteración(s) solicitada por el usuario, pueden
ser todas las iteraciones.
Resumen:
El caso de Uso inicia, cuando, el usuario
selecciona la opción “Flux Distribution” de la
interfaz principal, el sistema muestra la ventana
ANEXOS
125
correspondiente desde la cual el usuario podrá
especificar que iteraciones desea, y pedirle al
sistema que las muestre, una vez visualizadas
se activa la opción para exportarlas a un
archivo Excel.
Referencias:
R.F 30.
Casos de Usos asociados:
o Correr simulación.
o Salvar datos.
Precondiciones: Se necesita que alguna simulación haya
sido corrida.
Poscondiciones:
La distribución de flujo para cada una de las
reacciones del modelo, en las iteraciones
solicitadas, es mostrada en pantalla.
La opción para exportarla a un archivo Excel
es activada.
A
ANEXOS
126
Interfaz 1
Interfaz 2
Curso Normal de los Eventos
Acciones del Actor Respuesta del Sistema
1. El Usuario selecciona la opción
“Flux Distribution” (A) de la
interfaz 1.
1.1. El sistema muestra la interfaz 2, con los
recursos necesarios para que el usuario
solicite el servicio en cuestión.
2. El usuario introduce el (los
números de las iteración(s)
deseada(s), separados por
punto y coma (;), en el campo
de texto de la ventana (B), y
acciona el botón “Run” (C).
2.1. El sistema verifica que el formato de las
entradas sea correcto.
2.2. El sistema valida que las iteraciones
solicitadas se encuentren en el rango de las
que se realizaron durante la simulación.
2.3. El sistema desactiva el campo de texto y el
botón “Run” mientras la operación se
BC
H
D E
F G
ANEXOS
127
completa, ya que esta se ejecuta en un hilo
de ejecución alternativo.
2.4. El sistema muestra en la primera columna
(D) los nombres de cada una de las
reacciones, y en las contiguas (E), los
valores de flujo para cada una de las
iteraciones solicitadas.
2.5. Mientras la operación se están realizando
el sistema muestra una barra de progreso
(F) indicando el estado de la misma y la
información correspondiente (G).
2.6. El sistema activa la opción para salvar los
datos (H).
Cursos Alternos:
Mensaje 1
Mensaje 2
Curso Normal de eventos Línea 2.1 1.1. Si el formato de las entradas no es
correcto el sistema muestra el Mensaje 1,
limpia el campo de texto e interrumpe el
ANEXOS
128
curso normal de los eventos.
Curso Normal de eventos Línea 2.2 1.1. Si alguna(s) iteración(s) solicitadas por el
usuario no se encuentra en el rango de
las realizadas durante la simulación, el
sistema muestra el Mensaje 2, limpia el
campo de texto e interrumpe el curso
normal de los eventos.
Prioridad: Media.
Caso de Uso: Solicitar historial de biomasa.
Actor: Usuario (inicia)
Propósito:
Mostrar en pantalla el historial de biomasa, con
los resultados de cada una de las simulaciones
realizadas sobre el modelo que se encuentre
actualmente abierto.
Resumen:
El caso de Uso inicia, cuando, el usuario
selecciona la opción “Biomass History” de la
interfaz principal, el sistema muestra la ventana
correspondiente desde la cual el usuario puede
analizar los resultados de todas las
simulaciones realizadas sobre el modelo
abierto, una vez visualizadas se activa la
opción para exportarlas a un archivo Excel.
Referencias:
R.F 32.
Casos de Usos asociados:
o Salvar datos.
Precondiciones: Se necesita que alguna simulación haya
sido corrida.
Poscondiciones: El historial de biomas es mostrado en
pantalla.
ANEXOS
129
La opción para exportarlo a un archivo Excel
es activada.
Interfaz 1
A
ANEXOS
130
Interfaz 2
Curso Normal de los Eventos
Acciones del Actor Respuesta del Sistema
1. El Usuario selecciona la opción
“Biomass History” (A) de la
interfaz 1.
1.1. El sistema busca el historial de biomasa,
donde están guardados los resultados de
todas las simulaciones que se han
realizado sobre el modelo abierto.
1.2. El sistema muestra la interfaz 2, donde en
la primera columna se encuentra el vector
de tiempo (C) y en las restantes los valores
de biomasa (D).
1.3. El sistema activa la opción (B) para salvar
DC
B
ANEXOS
131
el historial en un archivo Excel.
Prioridad: Media.
Caso de Uso: Solicitar matriz de concentración.
Actor: Usuario (inicia)
Propósito:
Mostrar en pantalla la matriz de concentración,
con los valores para los substratos de las
reacciones de intercambio.
Resumen:
El caso de Uso inicia, cuando, el usuario
selecciona la opción “Concentration Matrtix” de
la interfaz principal, el sistema muestra la
ventana correspondiente desde la cual el
usuario puede disponer de los valores de
concentración en el tiempo, para los substratos
de las reacciones de intercambio, una vez
visualizadas se activa la opción para exportarlas
a un archivo Excel.
Referencias:
R.F 34.
Casos de Usos asociados:
o Salvar datos.
o Correr simulación.
Precondiciones: Se necesita que alguna simulación haya sido
corrida.
Poscondiciones:
La matriz de concentración es mostrada en
pantalla.
La opción para exportarla a un archivo Excel
es activada.
ANEXOS
132
Interfaz 1
Interfaz 2
A
D
C
B
ANEXOS
133
Curso Normal de los Eventos
Acciones del Actor Respuesta del Sistema
1. El Usuario selecciona la opción
“Concentration Matrix” (A) de la
interfaz 1.
1.1. El sistema busca en los resultados de la
simulación, la matriz de concentración.
1.2. El sistema recorre la matriz eliminando
aquellas columnas en la que todos sus
valores son cero.
1.3. El sistema muestra la interfaz 2, donde en la
primera columna se encuentra el vector de
tiempo (C) y en las restantes los valores de
concentración para los substratos (D).
1.4. El sistema activa la opción (B) para salvar
la matriz en un archivo Excel.
Mensaje 1
Cursos Alternos
Curso normal de eventos Línea
1.2
1.1. Si todas las columnas de las matriz de
concentración son cero el sistema muestra
el Mensaje 1 e interrumpe el curso normal
de los eventos.
Prioridad: Media.
Caso de Uso: Salvar datos
Actor: Usuario (inicia)
ANEXOS
134
Propósito: Exportar a un archivo Excel (Microsoft Office
2010), datos visualizados en pantalla.
Resumen:
El caso de Uso inicia, cuando, el usuario
selecciona la opción salvar datos, el sistema
comienza a exportar los datos para el archivo, el
usuario es informado en todo momento del
progreso del proceso, mediante la barra de
estado. El caso de uso finaliza con la
visualización del archivo Excel con los datos ya
estructurado.
Referencias:
R.F 10.1, R.F 31, R.F 31, R.F 33, R.F 36.
Casos de Usos asociados:
o Explorar detalles de la reacción.
o Solicitar historial de biomasa.
o Solicitar matriz de concentración.
o Correr simulación.
o Solicitar distribución de flujo.
Precondiciones: Se tiene que haber ejecutado alguno de los
casos de uso asociados.
Poscondiciones: La información deseada es exportada a un
archivo Excel.
Curso Normal de los Eventos
Acciones del Actor Respuesta del Sistema
1. El Usuario selecciona la opción
salvar en la interfaz
correspondiente.
1.1. El sistema comienza a exportar los datos
para el archivo Excel.
1.2. El sistema muestra en la barra de estado el
progreso del proceso.
1.3. El sistema abre el archivo un vez que todo
los datos fueron exportados.
Prioridad: Media.
ANEXOS
135
ANEXO V: DIAGRAMAS DE COLABORACIÓN DE LOS CASOS DE USO MAS
SIGNIFICATIVOS
C.U Cargar Sistema Biológico.
sd Cargar Sistema Biológico
StartF SbmlIn
SbmlModel
Compartment
Specie
Reaction
Stoichiometry
Usuario
1:
1.1:
1.2:
1.3:
1.4 :
1.5:
1.6:
2:
ANEXOS
136
C.U Correr Simulación.
C.U Consultar Gráficos.
sd Correr simulación
StartF dFb a
Fba
«library»
Simulation::
GLPKSharp.dll
Concentration
SbmlModel
Biomass
SimResults
BiomassHistory
Usuario
(from Actors)
1:
1.1:
1.2: 1.3:
1.4 :
1.5:
1.6:
1.7: 1.8:
2:
sd Consultar gráficos
GrphicsF
SimResults
Usuario
(from Actors)
GraphicsStartF
1:
1.1:
1.2:
1.3:
2:
ANEXOS
137
C.U Consultar Gráficos de Substratos.
C.U Salvar Imagen del Gráfico.
C.U Solicitar Historial de Biomasa
sd Consultar gráfico de substratos
GrphicsF
SimResultsUsuario
(from Actors)
GraphicsStartF
1:
1.1:
1.2:
1.3:
2:
sd Salv ar imagen del gráfi...
«<<Image>>»
Image.jpg
SaveImage SaveImageUsuario
(from Actors)
StartF
graphic
1:
1.1:
1.2:
1.3:
1.4 :
2:
2.1:
sd Solicitar Historial de Biomasa
Usuario
(from Actors)
StartF BiomassHystoryF BiomassHistoryBiomassHistory
1: 1.1: 1.2: 1.3:
2:
ANEXOS
138
C.U Solicitar Distribución de Flujos.
C.U Solicitar Matriz de Concentración.
sd Solicitar Distribución de Fluj ...
FluxF SimResultsUsuario
(from Actors)
FluxDistributionStartF
1: 1.1:
1.2:
1.3:
2:
sd Solicitar Matriz de Concentraci...
ConcentrationMatrixF SimResultsUsuario
(from Actors)
ConcentMatrixStartF
1: 1.1: 1.2:
1.3:
2:
ANEXOS
139
ANEXO VI: DIAGRAMAS DE SECUENCIA DE LOS CASOS DE USO MÁS
SIGNIFICATIVOS
C.U Cargar Sistema Biológico (Curso normal de eventos).
ANEXOS
140
C.U Cargar Sistema Biológico (Seccion: Archivos recientes).
ANEXOS
141
C.U Correr Simulación.
ANEXOS
142
C.U Consultar Gráficos.
ANEXOS
143
C.U Consultar Gráficos de Substratos.
ANEXOS
144
C.U Salvar Imagen del Gráfico.
C.U Solicitar Historial de Biomasa
ANEXOS
145
C.U Solicitar Distribución de Flujos.
ANEXOS
146
C.U Solicitar Matriz de Concentración.
C.U Salvar Datos.
ANEXOS
147
ANEXO VII: INTERFACES DE LA APLICACIÓN
Interfaz del Explorador del Modelo (sección de los Compartimientos).
ANEXOS
148
Interfaz del Explorador del Modelo (sección de las Especies).
ANEXOS
149
Interfaz del Explorador del Modelo (sección de las Reacciones).
ANEXOS
150
Interfaz del Explorador del Modelo (Listado de todas las Reacciones del
Modelo).
ANEXOS
151
ANEXO VIII: INTERFACES DE LAS HERRAMIENTAS ESPECIALIZADAS DE LA
APLICACIÓN.
Interfaz del Área de Gráficos.
ANEXOS
152
Interfaz para la Distribución de Flujos de la Red.
ANEXOS
153
Interfaz del Historial de Biomasa.
Interfaz de la Matriz de concentración.
ANEXOS
154
ANEXO VIIII: MÉTRICAS DEL CÓDIGO DE LA APLICACIÓN
Métrica Valor
Maintainability Index 82
Cyclomatic Complexity 831
Depth of Inheritance 7
Class Coupling 206
Lines of Code 5,058
ANEXOS
155
ANEXO X: CASOS DE PRUEBA
Caso de
Uso:
Cargar Sistema Biológico.
Caso de
prueba:
Cargar un sistema biológico desde un archivo .xml, que no está
estructurado según las directivas del sbml.
Entrada:
El usuario necesita cargar el sistema biológico desde el archivo.
El archivo pasa el filtro del cuadro de dialogo “Open Sbml Model”, por
ser .xml.
El archivo no es un formato sbml válido.
Resultado:
Se muestra un mensaje de error informándole al usuario que el
formato no es el esperado/soportado por el sistema.
Condiciones:
El sistema se mantiene en su estado original.
No se permite que se ejecuten los casos de uso relacionados con
“Cargar Sistema Biológico”, los cuales necesitan la información del
mismo.
ANEXOS
156
Caso de
Uso:
Consultar Gráfico de Substratos
Caso de
prueba:
Consultar los gráficos para substratos, cuando no hay substratos
graficables.
Entrada:
El usuario desea consultar los gráficos de substratos, una vez
terminada la simulación.
El grafico de biomasa se encuentra disponible, pero ningún substrato
graficable fue hallado.
Resultado:
El gráfico para los substratos se muestra vacío y sin posibilidades de
selección (A) de algún substrato.
Condiciones: No se obtienen gráficos para los substratos.
A
ANEXOS
157
Caso de
Uso:
Correr simulación
Caso de
prueba:
Correr una simulación, con los parámetros iniciales en un formato
incorrecto.
Entrada:
1.1. El usuario intenta correr una simulación, con el parámetro
inicial (biomasa) en un formato que no es el esperado por el
sistema.
1.2. El usuario intenta correr una simulación, con el parámetro
inicial (Time Step) en un formato que no es el esperado por el
sistema.
1.3. El usuario intenta correr una simulación, con el parámetro
inicial (n Steps) en un formato que no es el esperado por el
sistema.
1.4. El usuario intenta correr una simulación, con un valor de
concentración para alguno de los substratos de intercambio,
en un formato que no es el esperado.
1.5. . El usuario intenta correr una simulación, con un valor de Lb
para alguno de los substratos de intercambio, en un formato
que no es el esperado.
Resultado:
1.1. Se muestra el mensaje:
1.2. Se muestra el mensaje:
ANEXOS
158
1.3. Se muestra el mensaje:
1.4. Se muestra, en correspondencia con el substrato que sea, el
mensaje:
1.5. Se muestra, en correspondencia con el substrato que sea, el
mensaje:
Condiciones:
No se inicia la simulación, mientras que los parámetros permanezcan
incorrectos, ni se ejecutan los casos de uso relacionados con este y
necesitan de la información que en las simulaciones se genera.
ANEXOS
159
Caso de
Uso:
Modificar límites de la Reacción
Caso de
prueba:
Modificar los límites de la reacción, cuando los valores entrados no
están en el formato esperado.
Entrada:
1.1. El usuario intenta modificar el límite inferior (Lb) de una
reacción, pero el valor entrado no está en el formato esperado.
1.2. El usuario intenta modificar el límite superior (Ub) de una
reacción, pero el valor entrado no está en el formato esperado.
Resultado:
1.1. El sistema muestra el mensaje:
1.2. El sistema muestra el mensaje:
Condiciones: Los límites de la reacción conservan su valor por defecto.