Software para la graficación de diagramas termodinámicos

Transcripción

1 Software para la graficación de diagramas termodinámicos Proyecto Integrador de Ingeniería en Computación Martín Gaitán Abril de 2011 Director Mg. Gustavo Wolfmann Codirector Dr. Martín Cismondi Duarte

2

3 A Nati y a mi familia, por todo el amor

4 II

5 Índice general 1. Introducción Descripción Motivación Importancia Alcance Objetivos Marco Teórico Diagrama de fases de sistemas binarios Equilibrio termodinámico Ecuaciones de Estado Aplicación y utilidad Contexto de trabajo Trabajo interdisciplinario Software libre Ingeniería de requerimientos Metodología de relevamiento Relevamiento de la versión preexistente Especificación de requerimientos Requerimientos especiales Casos de uso Metodología Metodologías Ágiles Desarrollo evolutivo adaptado Modelado conceptual vs. UML Tecnologías adoptadas Lenguaje de programación NumPy III

6 6.3. Matplotlib WxPython El patrón Publish/Subscribe Gestión de proyecto Control de versiones Seguimiento de errores y propuestas Documentación Arquitectura Modelo conceptual Componentes y capas de software Capa de base de datos Diagrama de paquetes Diagramas de clases Preceptos adoptados en el diseño de UI Implementación Utilización de Publish/Suscribe en GPEC Invocación de ejecutables del backend Memorización de resultados costosos Algoritmo de análisis sintáctico Interfaz Gráfica de Usuario (GUI) Integración Matplotlib-WxPython Implementación de base de datos Verificación Conceptos de pruebas unitarias Pruebas realizadas Pruebas de usabilidad Implantación Empaquetado para sistemas Windows Instalación en sistemas Linux Distribución y soporte Conclusiones Resultados Observaciones respecto a la tecnología empleada Problemas detectados Tiempo de desarrollo Costo de desarrollo Impacto Experiencia de trabajo Líneas de trabajo abiertas A. Ejemplos de diagramas 107 Bibliografía 111 IV

7 B. Especificación de la interfaz de comunicación 115 B.1. Tabla de incidencia B.2. CONPAROUT.DAT B.3. GPECIN.DAT B.4. GPECOUT.DAT B.5. TFORPXY.dat B.6. PXYOUT.DAT B.7. PFORTXY.DAT B.8. TXYOUT.DAT B.9. ZforIsop.dat B.10. ISOPOUT.DAT B.11. FUGIN.DAT B.12. FUGOUT.DAT B.13. IsoXTin.DAT B.14. IsoXTout.DAT C. Glosario 127 C.1. Química y termodinámica C.2. Computación Índice 133 V

8 VI

9 CAPÍTULO 1 Introducción En sus orígenes y durante muchas décadas, la computación estuvo vinculada estricta e intrínsecamente al mundo de la ciencia. Este vínculo fue retroalimentándose a lo largo de la historia, permitiendo tecnologías que abarataron y multiplicaron la potencia de las computadoras y, en el otro sentido, ayudando a resolver complejos interrogantes que sin la capacidad computacional los científicos no hubieran podido responder. Es evidente que en la actualidad las computadoras ya no son exclusividad de selectos laboratorios o universidades y su uso generalizado ha modificado drásticamente la cultura y la calidad de vida de las personas, teniendo un rol sine qua non en el trabajo, la comunicación, el ocio, etc. Esta popularización abrió amplísimos campos de desarrollo de la computación, pero, aunque ya no el único, el campo de la computación científica sigue siendo de gran importancia. Diversas áreas de la ciencia y la ingeniería han sido revolucionadas por el software para cálculo, visualización y simulación disponible. Por nombrar sólo dos ejemplos, herramientas como MATLAB o Mathematica forman parte del día a día en la labor de ingenieros e investigadores. En este ámbito de aplicación puede hacerse una distinción entre software científico/técnico de propósito general como los mencionados (independientemente de que tengan mayor aceptación en un campo u otro) de los que son de propósito específico y realizan un conjunto de tareas puntuales (software aplicativo). Este trabajo se incluye en la segunda categoría ya que se trata de una aplicación científica multiplataforma, con interfaz gráfica de escritorio, que basada en programas de cálculo preexistentes permite realizar diagramas de equilibro de fase en 2 y 3 dimensiones que son de suma utilidad para la enseñanza, la investigación y la aplicación industrial. 1.1 Descripción GPEC (Global Phase Equilibrium Calculations) 1, es un software para la obtención de curvas de equilibro termodinámico de fase global para sistemas binarios, que se calculan mediante ecuaciones de estado. Es útil para fines académicos, científicos y de desarrollo industrial. 1 Web: 1

10 GPEC fue desarrollado originalmente en el año 2005 por el Dr. Martín Cismondi Duarte, codirector de este trabajo, en el marco de su tesis doctoral 2 en Ingeniería Química por la Universidad Nacional del Sur, parte de la cual fue cursada en la Universidad Técnica de Dinamarca 3. Luego fue ampliado junto a Diego Nuñez. Está basado en métodos numéricos y algoritmos desarrollados principalmente por Cismondi en colaboración con el Prof. Michael Michelsen, del Department of Chemical Engineering, DTU (Dinamarca), y el Prof. Marcelo Zabaloy de la Universidad Nacional del Sur, (Argentina). Actualmente es un proyecto dirigido por el Prof. Esteban Brignole de PLAPIQUI (Planta Piloto de Ingeniería Química) 4 en colaboración con el IDTQ (Investigación y Desarrollo en Tecnologías Químicas) 5 El software tiene una arquitectura de capas con un mecanismo de comunicación. El Back end corresponde al conjunto de programas (codificados en lenguaje Fortran) que implementa los algoritmos de cálculo. El Front end, denominado Visual Gpec es la interfaz de usuario que genera datos de entrada con formato comprensible por los algoritmos y procesa las salidas generando distintos gráficos. Para detalle sobre esta arquitectura puede ver Modelo conceptual. Para mayores detalle sobre la versión preexistente de GPEC vea Relevamiento de la versión preexistente. Importante: Estrictamente, GPEC es el conjunto de aplicaciones de cálculo desarrolladas por Cismondi Con el advenimiento de la primera interfaz gráfica Visual Gpec, se comenzó a llamar GPEC al conjunto de software, y es, salvo aclaración explícita, la asepción que tiene en este libro. 1.2 Motivación GPEC es un software que goza de cierta popularidad en el ambiente científico- académico. Se utiliza, por ejemplo, en el curso intesivo de postgrado High Pressure Technology in Process and Chemical Industry en el marco del programa Socrates Erasmus de la Unión Europea 6. Dicho curso se dicta iterativamente en distintas universidades europeas de Alemania, Italia, España, Holanda, etc. Hasta el momento no se conoce ningún otro software con capacidades equivalentes, lo que implica una creciente comunidad de usuarios, pertenecientes no sólo a instituciones académicas y de investigación, si no también a industrias. 2 Un resumen de la tesis es el artículo Global phase equilibrium calculations: Critical lines, critical end points and liquid-liquid-vapour equilibrium in binary mixtures, M Cismondi, ML Michelsen - The Journal of Supercritical Fluids, DTU - Danmarks Tekniske Universitet. Web 4 Es un instituto de investigación, educación y desarrollo de tecnología con sede en la ciudad de Bahía Blanca, dependiente de la Universidad Nacional del Sur (UNS) y del Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET). Web: 5 Grupo de investigación de la Facultad de Ciencias Exáctas Físicas y Naturales. Web: Capítulo 1. Introducción

11 Sin embargo, algunos factores han sido determinantes para el virtual congelamiento de su desarrollo desde el año En particular: La falta de recursos técnicos especializados en el desarrollo de software vinculados a los grupos que impulsan GPEC La ausencia de documentación La complejidad que ha alcanzado el proyecto El diseño cerrado, no reutilizable y poco extensible adoptado Ver También: Problemas detectados 1.3 Importancia Las potencialidades técnicas, científicas e incluso comerciales de este software son amplias, ya que tiene aplicación en la industria alimenticia, petroquímica, hidrocarburifera, etc. También es útil como herramienta educativa, donde los estudiantes consolidan conceptos teóricos y manipulan parámetros obteniendo una visualización interactiva de los resultados. Ver También: Para un detalle sobre este aspecto vea Aplicación y utilidad 1.4 Alcance El alcance de este trabajo es el rediseño y la implementación de una nueva aplicación de generación de gráficos para GPEC, cubriendo y superando las prestaciones ofrecidas hasta el momento, contemplando los mecanismos de comunicación con el software de cálculo subyacente sin alterarlo de manera alguna. 1.5 Objetivos Objetivo general El objetivo principal que persigue este trabajo es: Desarrollar un software front end totalmente compatible con el back end existente que reemplace al actual (Visual Gpec), orientado a un desarrollo prolongado y extensible, basado en un lenguaje de programación moderno y bibliotecas en desarrollo activo. Debe satisfacer las funcionalidades con las que la versión actual cuenta, ampliándolas y mejorándolas en algunos aspectos como la ergonomía, la calidad de los diagramas producidos, la usabilidad general, y aspecto visual del programa Importancia 3

12 1.5.2 Objetivos específicos Los objetivos específicos del proyecto son: Estudiar y documentar la versión preexistente del software. Vea Relevamiento de la versión preexistente. Estudiar y documentar el mecanismo de comunicación entre el front end y el back end. Vea Especificación de la interfaz de comunicación. Dilucidar fallas de diseño desde el punto de vista del usuario e idear sus soluciones para incluirlas como nuevos requerimientos. Relevar nuevos requerimientos. Investigar metodologías, procedimientos y paradigmas del desarrollo de software y justificar las adoptadas para este proyecto Investigar tecnologías (lenguajes de programación, bibliotecas de funciones, etc) y justificar las adoptadas. Codificar y documentar el proyecto de manera que satisfaga el conjunto de requerimientos planteados. Verificar y validar la implementación. Ver También: Especificación de requerimientos 4 Capítulo 1. Introducción

13 CAPÍTULO 2 Marco Teórico Debido a la naturaleza multidisciplinaria de este trabajo posiblemente sea leído y evaluado por profesionales o interesados de/en las distintas áreas de incumbecia (química y computación). Ver También: Trabajo interdisciplinario. Dado que no necesariamente se tiene un conocimiento sólido fuera de la especificidad de la profesión, en este capítulo se presentarán conceptos generales de termodinámica y equilibrio de fases (que no pretenden exhaustividad pero sí precisión). Para definiciónes de términos puntuales, consulte el glosario. Como complemento, en Tecnologías adoptadas se verá una introducción a las tecnologías, intentando un desarrollo de los conceptos apto para la comprensión de todos los lectores. 2.1 Diagrama de fases de sistemas binarios Un diagrama de fase es un tipo de gráfico utilizado para mostrar las condiciones en las que distintas fases termodinámicas de un sistema pueden ocurrir en equilibrio. Se representa en función de variables que caracterizan el estado intensivo del sistema fisicoquímico. El estudio introductorio de la termodinámica se centra en sustancias puras o mezclas a composición constante. En este caso, el sistema es descripto por dos variables. Un diagrama de fase típico para estos sistemas, es el Presión vs. temperatura que muestra la Figura 2.1. Así, para determinada presión y temperatura, la sustancia o mezcla constante puede estar en fase líquida, gaseosa o sólida, o bien en un punto crítico. Es decir, qué porcentaje o fracción de la mezcla corresponde a cada una de las dos sustancias del sistema. La composición habitualmente se mide en fracción molar, fracción masa, o concentración molar. Para sistemas binarios (una mezcla de dos componentes) la composición (o, complementariamente, la densidad) se vuelve una variable del sistema, cuya representación gráfica son curvas 5

14 Figura 2.1: La línea verde indica los puntos de congelamiento. La azul los de ebullición. La línea punteada muestra un comportamiento particular del agua. en el espacio R 3 (gráfico tridimensional) como muestra la figura 2.2. Para un determinado estado T-P-x (x es composición, en general expresada como fracción molar del compuesto más volátil) el sistema se encuentra en zonas de equilibrio vapor/líquido, líquido/líquido, vapor/sólido, líquido/sólido u otros casos particulares. La proyección ortogonal de estas curvas tridimensionales sobre los planos correspondientes genera los gráficos cartesianos bidimensionales PT, Px, Tx (y sus análogos para densidad) que son típicos de la bibliografía del tema. Un ejemplo de proyección Temperatura vs. Composición se muestra en la figura 2.3. El comportamiento termodinámico de los sistemas binarios no es uniforme cualquiera sean los compuestos de la mezcla. Existen seis tipos de comportamiento, de los cuales los tipos I, II, III y IV (enumerados en orden creciente de complejidad) son los más comunes (todos calculables a través de GPEC). Esta complejidad creciente del comportamiento se observa en la aparición de equilibrios líquido-líquido, líquido-líquido-vapor, líneas azeotrópicas, etc. 2.2 Equilibrio termodinámico Según [SM-VN-AG2000] : (...) se reconoce al equilibrio como una condición estática donde, con el tiempo, no ocurre cambio alguno en las propiedades macroscópicas de un sistema, lo cual implica un balance de todos los potenciales que pueden ocasionar un cambio. 6 Capítulo 2. Marco Teórico

15 Figura 2.2: Un diagrama P-T-x para un sistema binario de Tipo I. Figura 2.3: Un diagrama T-x para un sistema binario, mostrando la línea crítica y otras informaciones Equilibrio termodinámico 7

16 Figura 2.4: Representación de diagramas P-T para los primeros 4 tipos de comportamiento Por ejemplo, un sistema aislado que consta de las fases en contacto estrecho líquido y vapor, con el tiempo alcanza un estado final donde no existe tendencia a que suceda un cambio en sí mismo. La temperatura, la presión y las composiciones de fase logran los valores finales que en adelante permanecen fijos, por lo que el sistema logra el equilibrio Ecuaciones de Estado El modelado cuantitativo de los equilibrios de fases se realiza principalmente utilizando ecuaciones de estado (EOS (Equation of State)). Estas son relaciones matemáticas (modelos matemáticos) entre dos o más funciones de estado asociadas a la materia como la temperatura, la presión, el volumen o la energía interna. Como ejemplo conocido en cualquier curso introductorio de química, la Ley del gas ideal (2.1) es una ecuación de estado, que al considerar el volumen molecular nulo y a las fuerzas de atracción-repulsión despreciables, limita su utilidad para modelar gases reales. pv = nrt (2.1) p es la presión absoluta, V el volumen, T la temperatura, n la cantidad de materia y R la constante del gas ideal. 1 A pesar de eso, en el nivel microscópico las condiciones no son estáticas. Las moléculas contenidas en una fase en un determinado instante son diferentes a las que después ocuparan la misma fase, es decir, existe intercambio de de moléculas en la zona interfacial, aunque al ser de igual rapidez promedio en ambas direcciones no ocurre transferencia neta de material. 8 Capítulo 2. Marco Teórico

17 La Ecuación de Van der Waals (2.2) (1873) 2 generaliza la ecuación (2.1), teniendo en consideración tanto el volumen finito de las moléculas de gas como la atracción intermolecular que afectan al término de presiones (P + a υ 2 ) (υ b) = RT (2.2) a y b son constantes físicas de la sustancia en cuestión. Muchas de las ecuaciones de estado modernas son mejoras y correcciones a la ecuación original de Van der Waals (denominadas ecuaciones de estado cúbicas). Por ejemplo la ecuación de Soave-Redlich-Kwong (1972), Peng-Robinson (1976), Elliott-Suresh-Donohue (1990), etc. GPEC es capaz de realizar los cálculos usando cinco diferentes ecuaciones de estado (ver :ref: Requerimientos funcionales ). 2.4 Aplicación y utilidad Los equilibrios entre fases tienen un rol muy importante en la tecnología química, alcanzando una gran diversidad de aplicaciones, principalmente en procesos de separación de la industria química, petroquímica y el sector de hidrocarburos, pero también en novedosos procesos basados en fluídos supercríticos, de gran desarrollo y creciente interés en las últimas décadas, como la generación de co-cristales, la producción de biodiesel, secado supercrítico, cromatografía supercrítica, etc. 3. Especialmente a altas presiones estos equilibrios ser complejos de calcular e interpretar, por lo que la representación a traves de diagramas de fases es esencial. Como ejemplificación del interés de la industria y la academia sobre esta área de investigación, vale mencionar la experiencia del curso Advanced Course on Thermodynamic Models, dictada por los profesores Michael Michelsen y Jørgen Mollerup de la Universidad Técnica de Dinamarca, que ha convocado a centenares de profesionales de diversas firmas como British Petroleum, Chevron, Phillips, Shell y muchas otras de renombre mundial. Este curso se realizó durante 2009 por primera vez en Latinoamérica, teniendo sede en la Universidad Nacional de Córdoba, organizado desde IDTQ, con participantes de Brasil, Canadá, Chile, Alemania y varias otras procedencias 4. 2 Por este descubrimiento, Van der Waals recibió el Premio Nobel de Química en Para un listado más abarcativo, ver Supercritical fluid: Applications ( 4 Ver Aplicación y utilidad 9

18 10 Capítulo 2. Marco Teórico

19 CAPÍTULO 3 Contexto de trabajo 3.1 Trabajo interdisciplinario La ciencia de la computación no trata sobre las computadoras más de lo que la astronomía trata sobre los telescopios Edsger Dijkstra Como se describe en la introducción, la computación ha revolucionado todas las áreas de la cultura y la investigación moderna, incluyendo, por supuesto, a la ingeniería en todas sus formas. Puede decirse que la ingeniería en computación (complementada con la ingeniería en sistemas) se ha constituido en una meta ingeniería requerida por todas las demás áreas. Es aceptable pensar que, en general, un ingeniero en computación puede desenvolverse profesionalmente sin conocimientos de termodinámica, pero un ingeniero químico o mecánico avocado a esa área tendrá dificultades para progresar si no tiene cierta destreza en programación y sistemas de información. No obstante, cuando se quieren alcanzar objetivos más altos a nivel de software, la capacidad y formación media en un profesional de otra área se vuelve escasa: el desarrollo de software es una ingeniería por sí misma, que va mucho más allá de la destreza en programación. Es saludable entonces que profesionales idóneos sean los encargados de ese aspecto específico del proyecto, interactuando y consultando cuestiones que conciernen al ámbito de aplicación, aportando ideas, desarrollando una acabada ingeniería de requerimientos y explicando de manera didáctica cuando estos exceden o complejizan innecesariamente la implementación. Por otro lado, desde el contexto académico y de investigación, en la FCEFYN no existe una notoria sinergia entre las distintas disciplinas 1, cuyas ventajas expone el magíster Antonio Rey Roque en [ARR2003]: Hablar de interdisciplinaridad en el contexto académico significa lograr un nivel adecuado de comunicación, la integración de paradigmas, la ruptura de concepcio- 1 Salvo quizás las más cercanas, como electrónica y computación, pero en una medida muy inferior a la que podría lograrse. 11

20 nes reduccionistas, el desarrollo de una cultura de aprendizaje colectivo. Presupone implicación profesional, multiplicación (no suma) de ideas conceptuales, metodológicas, procedimentales; economía de esfuerzos, de carga profesional y evaluativa. Implica un proceso docente educativo ágil, económico y enriquecedor para los docentes; procesos de aprendizaje más significativos para los alumnos; relación profesional más rica y afectiva entre docentes. El escenario correspondiente a un trabajo interdisciplinario no implica, como algunos pueden pensar, un mayor trabajo, sino, mayor riqueza, variedad y aceptación de actividades; mayor equidad en la distribución de tareas y recibe los beneficios afectivos y profesionales del trabajo en equipo. El resultado del aprendizaje en tal escenario es un saber más coherente, se logra mayor capacidad para enfrentar problemas. Desde ambos puntos de vista, estas han sido las ideas que, desde el principio, guiaron este proyecto. Como se verá en Experiencia de trabajo, el resultado ha sido altamente satisfactorio. 3.2 Software libre El desarrollo de este trabajo ha sido liberado como Software Libre, bajo los teŕminos de la bajo la licencia libre GPL (General Public License) 2. Por su parte, este documento se ofrece bajo los términos de la licencia Creative Commons Atribución-NoComercial-CompartirIgual 2.5 < Se dará a continuación una somera introducción conceptual al Software Libre, y en Justificación se exponen los argumentos de la decisión mencionada, que se invita a leer y analizar. Importante: La liberación se limita al software desarrollado por el autor de este trabajo, siendo este dependiente del backend GPEC que no es libre. Si bien la utilidad de un sofware libre que depende de otro no libre es parcial, (ver [RMS2004]), queda fuera de la potestad del autor la determinación de una liberación total, aunque enfáticamente la promueva Introducción El Software Libre (SL) es aquel que respeta la libertad de los usuarios sobre su producto adquirido (independientemente de si se debe pagar por ello o no) y, por lo tanto, una vez obtenido puede ser usado, copiado, estudiado, cambiado y redistribuido libremente 3. Esto no implica que el/la autor/a o autores del software pierdan los derechos de autoría intelectual que son inalienables e imprescriptibles. La definición de SL [FSFa] fue concebida originalmente por Richard Stallman a mediados de los años 80, oponiéndose a las restricciones que imponía el modelo de software privativo (SP) que muchas universidades empezaban a adoptar y que los hackers 4 no podían aceptar. 2 Licencia pública general versión 3, 3 Refiere a las cuatro libertades esenciales del software libre descriptas en [FSFa] 4 La noción de hacker que el común de la gente tiene es incorrecta. Vea el glosario para una definición correcta. 12 Capítulo 3. Contexto de trabajo

21 Desde entonces, y en especial con la aparición del sistema operativo GNU/Linux, el avance del SL ha sido arrollador, siendo eslabón escencial para el funcionamiento de Internet desde sus orígenes hasta nuestros días 5, de los clusters más poderosos 6 y núcleo propulsor de los dos sitios más visitados y exitosos a nivel mundial: Google 7 8 y Facebook 9. Figura 3.1: Familia de S.O. de los 500 supercomputadores más rápidos del mundo. De cierta manera, el SL ha excedido su condición de forma de licenciamiento de software erigiéndose en un marco de referencia moral, político y legal para la creación de conocimiento en sus diversas formas. Iniciativas como Creative Commons ( y Wikipedia ( nacieron como extensión conceptual aplicada a otros tipos de creaciones intelectuales Justificación Entre los muchos motivos que hacen al SL un modelo técnicamente viable, económicamente sostenible y socialmente justo [JMiH2005], sintéticamente se mencionarán los que justifican que el software desarrollado para este trabajo haya sido liberado. 5 En 2010, el 73 % de los servidores web funciona con software libre. 6 Hasta marzo de 2011, el 91.8 % de los 500 supercomputadores más poderosos del mundo funcionaban con Linux o derivados. 7 Sergey Brin en una entrevista de 2000 cuenta que dentro de Google Linux se utiliza en todas partes... en los más de servidores así como en las máquinas de todos nuestros empleados técnicos (...) Es tan agradable poder adaptar cualquier parte del sistema siempre que quieras Se estima que Google tiene en la actualidad más de 200 mil servidores ( 9 Facebook has been developed from the ground up using open source software, Software libre 13

22 Creación desde la Universidad Pública La formación del autor de este trabajo, así como la de su director y codirector, no obstante el esfuerzo personal, son fruto de la Universidad Pública Argentina, privilegio al que una ínfima porción de la sociedad accede cuando es ella toda, a través del Estado, quien la sostiene. Más aún, el tiempo dedicado por los docentes para guiar y evaluar este trabajo fue sostenido con recursos públicos 10. Retribuir los conocimientos adquiridos en la formación universitaria para beneficio del conjunto del pueblo (y por extensión, de la humanidad), es una obligación ética basada en la concepción misma de la universidad pública y gratuita, y declarada en el artículo 2 del Estatuto de la Universidad Nacional de Córdoba [UNC1] que enumera dentro de sus fines: la promoción de la investigación científica(...), [el] libre desarrollo de la cultura, (...) la efectiva integración del hombre en su comunidad, (...) [el] promover la actuación del universitario en el seno del pueblo al que pertenece, (...) [y] la difusión del saber superior entre todas las capas de la población. Desarrollo basado en software libre Los buenos programadores saben qué escribir. Los mejores, que reescribir (y reutilizar) Eric Raymond, [ER1997] En ninguna disciplina creativa se es absolutamente original. Basarse en las creaciones o ideas previas, que han sido probadas con éxito, presume la posibilidad de llegar a más ambiciosos y seguros resultados. Es un precepto que el software libre comparte con la ciencia, expresada en la frase atribuía a Isaac Newton: Si he visto más lejos es porque me paré sobre hombros de gigantes 11 Eric Raymond, en su famoso ensayo The Cathedral and the Bazaar [ER1997], expresa la ventaja desde su experiencia como programador: Aunque no pretendo ser un gran programador, trato de imitarlos. Una característica importante de los grandes de verdad es la vagancia constructiva. Saben que te darán un diez no por tu esfuerzo, sino por los resultados, y es casi siempre más fácil empezar a partir de una buena solución parcial que desde la nada más absoluta. El lenguaje y las bibliotecas que se usaron para el desarrollo de este trabajo son libres 12 (ver Tecnologías adoptadas) y ampliamente probadas por numerosas aplicaciones que las utilizan. Además, gran cantidad de ejemplos y buenas ideas aplicadas en este trabajo fueron extraídas de código libre disponible en internet. 10 Por supuesto, habiendo podido dedicar su tiempo a otras labores, los docentes aceptaron dirigir este trabajo voluntariamente, actitud por la que vale reiterar el agradecimiento del autor. 11 Según la entrada en Wikipedia ( la cita corresponde a Bernard of Chartres. 12 Particularmente, sus licencias no exigen que el software producido o derivado deba ser liberado, como sí ocurre con GPEC al adoptar una licencia GPL. 14 Capítulo 3. Contexto de trabajo

23 Sin la existencia de SL este trabajo hubiera sido muchísimo más costoso, tanto en términos de horas de desarrollo como en el costo de licencias de software privativo equivalente al utilizado, y hubiese resultado inalcanzable en el contexto de un proyecto integrador de grado. Retribuir el resultado de los beneficios usufructuados para que otros puedan servirse resulta un evidente acto de justicia. Necesidad de transparencia en el software científico Dan Gezelter, mentor de la iniciativa Open Science ( resume en [DG2009] los objetivos del proyecto: Transparencia en metodología experimental, observación y recolección de datos Disponibilidad pública y reusabilidad de los datos científicos Accesibilidad pública y transparencia de la comunicación científica Uso de herramientas basadas en web para facilidad la colaboración científica. Sobre el primer punto agrega: (...) Garantizar el acceso al código fuente es realmente equivalente a publicar su metodología cuando el tipo de ciencia que realiza implica experimentos numéricos. Soy extremista en este punto, porque sin acceso a las fuentes de los programas que usamos, nos apoyamos en la fe a las capacidades de codificación de otras personas para llevar a cabo nuestra experimentación. En algunos casos extremos, (por ejemplo, cuando el código de simulación o archivos de parámetros son privativos u ocultados por sus dueños), la experimentación numérica ni siquiera es ciencia. Un diseño experimental secreto no permite a los escépticos repetir (y con suerte verificar) su experimento y lo mismo ocurre con experimentos numéricos. La ciencia debe ser verificable en práctica tanto como verificable en principio. 13 Si bien el software realizado por el autor no implementa los algoritmos de cálculos numéricos, es una buena práctica permitir la verificabilidad de que los resultados no se adulteran. Calidad del software La libertad de un software no garantiza su calidad per se, ni mucho menos la ausencia de errores, pero aumenta enormemente las posibilidades de alcanzar cotas altas en este aspecto. Según Challet y Le Du en [CLD03] para hacer un software de código privativo de igual calidad que su equivalente libre hacen falta más y mejor calificados desarrolladores. El artículo plantea, desde un modelo matemático, que en el SL la interacción entre los usuarios y desarrolladores logra que los fallos sean eliminados a una velocidad mucho mayor que la que un grupo de programadores de software privativo de elite puede lograr. Esto radica en dos aspectos: la libertad de estudiar el código permite a cualquiera encontrar errores en el programa y reportarlos, y la dinámica de comunidad que muchos proyectos 13 Traducción del inglés propia del autor del trabajo Software libre 15

24 de software libre logran, donde el feedback entre usuarios y desarrolladores es constante y horizontal. Mejor estrategia comercial Un mito, muchas veces difundido por interés 14 o por ignorancia, es que no se puede lucrar con Software Libre, lo cual es falso. Por el contrario, en muchos escenarios, la adopción de software libre resulta beneficiosa para su maximización. Jordi Mas enumera en [JMiH2005] los principales modelos negocio que se han puesto en práctica en el SL con éxito durante los últimos años. En particular, es importante destacar el modelo de desarrollo software como servicio. Sobre este modelo Mas comenta: (...) [son] empresas que se dedican a la consultoría, desarrollo a medida de soluciones, formación y soporte técnico (...) Su valor diferencial respecto a las empresas tradicionales de servicios son los beneficios que transmiten a sus clientes por el hecho de trabajar con tecnologías libres como acceso al código fuente de las soluciones (...) En general, las empresas que mejor funcionan de este tipo son aquellas que se especializan en un área concreta de conocimiento (...) Ser un especialista en un área y ser reconocido como experto en la misma es una buena estrategia. Si bien el derecho a realizar modificaciones es concedido a todo el mundo, dentro del universo de personas o empresas capaces de llevar a cabo adaptaciones a medida (situación plausible en un nicho tan específico como el de GPEC), los autores originales del software se encuentran en una ventaja competitiva obvia. Por otro lado, en nichos de software específicos y pequeños, la posibilidad de difusión (y en consecuencia de tracción de usuarios) que tiene un software son mucho mayores aprovechando la infraestructura comunicacional de la que el SL goza: por el mero hecho de ser libre (y resultar mínimamente interesante) se dará publicidad gratuita y, mejor aún, espontánea, en numerosos sitios de noticias y foros de internet, puede incluirse en repositorios de software accesibles fácilmente desde sistemas operativos libres que facilitan la instalación y la prueba, y ser albergado en sitios de referencia para código libre como SourceForge ( GitHub ( o Google Code ( con cientos de miles de visitas diarias. Más y mejores usuarios repercute, como se ha visto, en más calidad y prestigio, que se realimentan en un bucle virtuoso ampliando posibilidades de lucro, fin que está fuera de los alcances de este trabajo pero no por ello descartado a futuro. Ver También: Líneas de trabajo abiertas 14 Vea FUD en el glosario 16 Capítulo 3. Contexto de trabajo

25 CAPÍTULO 4 Ingeniería de requerimientos 4.1 Metodología de relevamiento Para el relevamiento de requerimientos se realizaron entrevistas informales con el comitente, una evaluación exhaustiva de la versión preexistente y, basado en el modelo de Desarrollo evolutivo adaptado (que se explica en Marco Teórico), sucesivas presentaciones de prototipos que se fueron adaptando según las observaciones de la parte interesada. Además se utilizó un issue tracker para permitir que los usuarios adviertan de errores en la versión en desarrollo o propongan mejoras o nuevas funcionalidades. El proceso de relevamiento incluyó entrevistas con el desarrollador de Visual Gpec y con investigadores de PLAPIQUI involucrados, como desarrolladores o usuarios, en GPEC. 4.2 Relevamiento de la versión preexistente Aspectos históricos La versión previa de GPEC es una aplicación para entornos Microsoft Windows (Windows 2000, Windows XP o superior) desarrollada en una arquitectura de dos bloques funcionales: 1. Cálculos e implementación de algoritmos numéricos, desarrollados en Fortran 2. Interfaz de usuario, validación y graficación (frontend), desarrollado en Visual Basic Esta arquitectura respondió a dos cuestiones principales: La preexistencia de los programas de cálculo (ejecutables sin interfaz de usuario) que desarrolló el Dr. Martín Cismondi como tésis doctoral y mantiene hasta la actualidad, con la colaboración del Dr. Marcelo Zabaloy y la supervisión del Dr. Esteban Brignole, La necesidad pragmática de separar el desarrollo del Gpec visual, trabajo realizado por Diego Nuñez, del mantenimiento e implementación de nuevos algoritmos y ecuaciones de estado. 17

26 La labor de Diego Nuñez se produjo en el marco de su pasantía en PLAPIQUI durante los años 2004 y Descripción general La interfaz visual de GPEC presenta al usuario una GUI para interactuar con los distintos parámetros del diagrama elegido, envía los parámetros a los algoritmos de cálculo y procesa las salidas de estos generando y mostrando los diferentes diagramas. Figura 4.1: Interfaz principal de Visual Gpec. Definiendo un sistema Methane-Methanol con la EoS RK-PR. La comunicación con los algoritmos implementados en Fortran se realiza mediante archivos de texto plano en un formato cuya estructura ad hoc es bien conocida por las dos partes. Como se verá en breve, esta interfaz de comunicación se ha respetado (ver Especificación de la interfaz de comunicación). Asimismo, los datos de salida que producen los algoritmos, son leídos por Visual Gpec desde archivos de texto para su posterior graficación, que se realiza, segun manifestó el comitente, mediante rutinas desarrolladas ad hoc para esta implementación. Es decir, no se utiliza en ninguna biblioteca para estos fines, de modo que los gráficos se generan mediante el trazado punto a punto sobre un widget tipo canvas. El control de escala, segmentación y demás funcionalidades básicas debió programarse desde cero. El resultado de esto, si bien es aceptable y funcional, implicó muchas horas de desarrollo, con gráficos sólo 2D, poco configurables, que no se pueden vectorizar ni exportar Licenciamiento Visual GPEC no tiene una licencia explicitada pero se trata de un freeware*, es decir, un tipo de software que se distribuye sin costo y está disponible para su uso por tiempo ilimitado. La última versión públicamente disponible era la Capítulo 4. Ingeniería de requerimientos

27 Figura 4.2: Visualizacion de un diagrama P-T para el sistema Methane-Methanol con modelo RK-PR. Hasta el momento, GPEC no es Software Libre ni Open source, ya que su código fuente no está disponible Aspectos de ingeniería de software Según surge de las entrevistas realizadas, durante su desarrollo anterior, GPEC no adoptó ninguna metodología particular, salvo la concerniente a la separación funcional de la aplicación como se explicó anteriormente. Un problema manifestado por el equipo de desarrollo es el del versionamiento, ya que era incontrolable la coherencia entre los cambios realizados por más de un colaborador. Las modificaciones y los archivos circulaban por entre uno y otro, pero sin lograr sistematización y control sobre quién cambió qué. y a qué versión de GPEC corresponde un determinado código fuente Problemas detectados Lenguaje Como se ha mencinado, el programa se codificó en Visual Basic 6, que es un lenguaje lanzado en 1998 y ya no es soportado por Microsoft, la empresa creadora, proponiendo en su reemplazo.net, su tecnología más moderna Visual Basic es un lenguaje limitado y de poca robustez (sufre un problema asociado con varias 4.2. Relevamiento de la versión preexistente 19

28 librerías dinámicas 1 ), y con un pobre soporte de orientación a objetos, que condiciona la arquitectura de cualquier software no trivial a ser engorrosa y poco fiable. Asimismo, queda zanjada la posibilidad de contar con una aplicación multiplataforma nativa, ya que el lenguaje sólo funciona sobre Windows. Calidad de los gráficos Los gráficos generados, como se ha comentado, no se generan en ningun formato de archivo de imágenes (vectorial o mapa de bits), sino que simplemente se grafican por pantalla, con una proporción de 1 pixel por punto. La información faltante se completa con segmentos de recta. Esto acarrea la imposibilidad de exportar la imagen si no es a través de una captura de pantalla, requiriendo al menos un mínimo tratamiento de recortado y adaptación (por ejemplo del color de fondo, dependiente del tema de apariencia de Windows configurado por el usuario) con un programa de manipulación de gráficos. El resultado de esta operación es un mapa de bits carente de calidad suficiente para la impresión o la inclusión en un artículo científico, por lo que, en general, los usuarios recurren a la obtención de los datos numéricos y realizan la graficación con otro software específico como Origin o Microsoft Excel. Diseño y Usabilidad Un aspecto poco cuidado de Visual Gpec es su usabilidad, ofreciendo una experiencia de usuario anti-intuitiva. Figura 4.3: Ventanas abiertas para obtener un nuevo compuesto desde la base de datos, para que sea listado y utilizable en el sistema. 1 Este problema es conocido como DLL Hell (infierno de las DLL). Ver 20 Capítulo 4. Ingeniería de requerimientos

29 A primera vista, la pantalla principal ofrece muchísimas opciones que tienden a abrumar al usuario inexperto. Muchos componentes de la interfaz, como la lista de compuestos, no son necesarios permanentemente, y aun así, sin razón objetiva justificable, no todos los compuestos presentes en la base de datos se exponen en este selector. En caso de necesitar un compuesto que no esté allí listado, el proceso de obtención requiere interacturar con 3 formularios distintos. Por poner otro ejemplo, el botón principal para el inicio del cálculo ( ) se encuentra en una barra de herramientas con otras funciones no obligatorias para la ejecución. Es decir, las herramientas carecen de un contexto que facilite la ubicuidad. Base de datos La base de datos está implementada en formato Microsoft Jet 2 y su diseño de tablas es complejo innecesariamente, realizando diversas relaciones One-to-One con una misma clave principal. Por ejemplo, los nombres y las propiedades de un compuesto químico se encuentran en tablas separadas. Figura 4.4: Visualización de algunas estructuras y datos de la base de Visual GPEC mediante el utilitario gmdb2. Sumado a esto, dada la ineficiencia del formato, el archivo de base de datos estándar (sin datos extras agregados por el usuario) ocupa 45.2Mb de espacio en disco. 2 Microsoft Jet Database Engine es un motor de base de datos utilizado por el gestor Microsoft Access, entre otros productos. Ver Relevamiento de la versión preexistente 21

30 4.3 Especificación de requerimientos Requerimientos funcionales Todas las funcionalidades de la versión preexistente de GPEC deben igualarse y en lo posible mejorarse. Se detallan a continuación: Generación del sistema binario: selección de dos sustancias. Gestión de base de datos de constantes de compuestos químicos. Se incluirá una base de datos con el software que el usuario puede manipular. Adecuación del formulario y archivo de entrada de parámetros para diferentes ecuaciones de estado (modelos) de base molecular 3 : Soave-Redlich-Kwong Peng-Robinson RK-PR Simplified Perturbed Hard Chain Theory Perturbed Chain Statistical Associating Fluid Theory (PC-SAFT) Generación de suite de gráficos 2-D: Diagrama global de equilibrio de fases: Presión - Temperatura (P-T) Temperatura - Composición (T-x) Temperatura - Densidad (T-ρ) Presión - Composición (P-x) Presión - Densidad (P-ρ) Isopletas: diagramas para composición Z constante (rango definible [0, 1] ): Presión - Temperatura (P-T) Temperatura - Composición (T-x) Temperatura - Densidad (T-ρ) Presión - Composición (P-x) Presión - Densidad (P-ρ) Diagramas isotérmicos (Pxy): diagramas para temperatura T [K] constante 4 : Presión - Composición (Pxy) 3 Para la parametrización de los datos de entrada para cada ecuación de estado fue menenester documentar la Especificación de la interfaz de comunicación. 4 La validación de los rangos dinámicos (que dependen de las constantes críticas de los compuestos del sistema) la realizan los algoritmos de cálculo. El frontend se limita a reportar un error en la obtención de los datos de salida. 22 Capítulo 4. Ingeniería de requerimientos

31 Presión - Densidad (P-ρ) Diagramas isobáricos (Txy): diagramas para presión P [bar] constante : Temperatura - Composición (Txy) Temperatura - Densidad (T-ρ) Generación de suite de gráficos 3-D: diagramas globales y de parámetros constantes automáticamente superpuestos para cada caso: Presión - Temperatura - Composición Presión - Temperatura - Densidad Superposición de diagramas compatibles Gestión de proyectos (manipulación múltiples casos de sistemas/modelo/gráfico) Gestión de persistencia de datos (abrir, guardar, etc.) Ejecución multiplataforma: GPEC debe ser capaz de utilizarse en entornos Windows y Linux Exportación de gráficos Requerimientos no funcionales GPEC requiere flexibilidad que permita la extensibilidad de funcionalidades. Para esto se apunta a una arquitectura lógica modularizada que permita incorporar o extender funcionalidades de manera accesible. Manipulación de gráficos accesible: zoom, rotación, desplazamiento, ocultación de curvas, etc. Calidad y formatos de gráficos válidos para publicaciones científicas Configurabilidad de aspecto de los gráficos Usabilidad y claridad de las interfaces: debe poder usarse intuitivamente 4.4 Requerimientos especiales Se especifican en esta sección, de manera no formal, un conjunto de requerimientos de especial interés para el diseño del software Un proyecto, muchos casos Una tarea frecuente del usuario (investigador) es la comparación entre distintos casos de estudio. Esto puede ser, un mismo sistema binario con aplicando diferentes coeficientes, las mismas condiciones con diferentes modelo de cálculo, o bien directamente distintos sistemas Requerimientos especiales 23

32 Es decir que debe existir el concepto de proyecto como un conjunto de múltiples casos, gestionados desde una misma interfaz de usuario. Nota: Dado que se presta a confusión, vale reiterar que caso en el contexto es la conjunción de un sistema binario, un modelo de cálculo (ecuación de estado) y sus respectivos parámetros, y caso de uso refiere al ámbito de la ingeniería de software y se trata de una técnica para dilucidad requerimientos y comportamientos esperados del sistema Gráficos en 3D La información resultante de los cálculos brinda conjuntos (vectores) de datos para múltiples variables (presión, temperatura, composición, densidad, etc) Tomando tres vectores de datos en vez de dos, pueden graficarse diagramas 3D, (por ejemplo P-T-composición) sin necesidad de alterar el backend de manera alguna. Esta funcionalidad debe soportarse en la nueva implementación Superposición automática Dada la visualización 3D, es común que el investigador desee superponer diagramas de línea de contorno (isobaras, isopletas, etc.) sobre el diagrama de fase global del mismo caso para ver su disposición tridimensional. Este comportamiento debe ser automático. Es decir, cualquiera sea el diagrama solicitado, debe generar un diagrama 2D independiente y trazar estas mismas curvas sobre un diagrama 3D común para todo el caso Superposición manual El usuario puede necesitar superponer visualmente diagramas 2D, ya sean estos del mismo caso (por ejemplo, un diagrama P-T global con una isopleta) o bien de distintos casos (por ejemplo, diagramas PT correspondientes a distintas mezclas) Validación de orden del sistema En la definición de un sistema binario el usuario puede elegir cualesquiera dos compuestos de la base de datos, sin importar el orden. A los fines del cálculo, es necesario disponer el compuesto más liviano, en términos termodinámicos, para que el resultado sea válido. La determinación de esta condición debe validarse, y en caso necesario, invertir el orden de compuestos dado por el usuario. El sistema es válido si se cumple que la función peso 5 del compuesto 1 es menor a la del compuesto 2, es decir: 5 La validez de esta función fue comprobada de manera empírica por Cismondi. 24 Capítulo 4. Ingeniería de requerimientos

33 T 14 c 1 < T c 14 2 P c1 P c2 4.5 Casos de uso Se describen a continuación los casos de uso más relevantes del sistema. Basado en lo expuesto en la sección Modelado conceptual vs. UML no se realiza una enumeración minuciosa de las condiciones de contexto, flujos alternativos, etc. y en cambio se describen en un formato asociado a historias de usuario Definir caso de estudio El usuario define un caso (Figura 4.5) mediante la conjunción de la definición de un sistema químico binario (dos compuestos), la definición de un modelo de cálculo (de las 5 disponibles) y el cálculo o definición de los parámetros. Figura 4.5: Caso de uso: definición de un caso de estudio en GPEC Graficar diagramas Una vez definido el sistema el usuario solicita la graficación de los diagramas (Figura 4.6) para lo cual el sistema los calcula. Independientemente de la suite de diagramas solicitados por el usuario el cálculo de los diagramas globales es precedente. 6 Ver Casos de uso 25

34 4.5.3 Definir sistema Figura 4.6: Caso de uso: graficación de diagramas En este caso de uso se produce la interacción del usuario con la base de datos. Como se observa en el diagrama de la figura 4.7, el usuario puede elegir compuestos previamente definidos para la conformación del sistema binario o bien crear nuevos compuestos. Figura 4.7: Caso de uso: definición del sistema binario Cálculo Global El backend se modela como un actor lógico (subsistema) que interactua con el software desarrollado realizando el cálculo de los distinto diagramas. Se observa en la figura Cálculo de parámetros Definidas las constantes de los compuestos (obtenidas de la definición del sistema) se calculan los parámetros del modelo elegido a través del backend o bien se ajustan las constantes de los 26 Capítulo 4. Ingeniería de requerimientos

35 Figura 4.8: Caso de uso: graficación de diagramas compuestos en función de los parámetros definidos manualmente por el usuario. Se representa en el diagrama de la figura 4.9. Figura 4.9: Caso de uso: Cálculo de parámetros 4.5. Casos de uso 27

36 28 Capítulo 4. Ingeniería de requerimientos

37 CAPÍTULO 5 Metodología Este capitulo detalla el marco conceptual y la metodología de desarrollo adoptada. Esta decisión ha sido rectora de subsecuentes decisiones de diseño y, de cierta manera, de la tecnología adoptada para la implementación. 5.1 Metodologías Ágiles Este proyecto integrador ha sido guiado por un conjunto de preceptos comunes a las metodologías ágiles de desarrollo de software. Sin necesariamente ajustarse a ninguna en particular, se comparte la escala de valoración hecha en Agile Manifiesto [AG-MANIF] que declara: Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensiva Colaboración con el cliente sobre negociación contractual Respuesta ante el cambio sobre seguimiento (estricto) de un plan Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda. Las implementaciones del marco conceptual propuesto por el Manifiesto de desarrollo ágil (como extremme Programming o Scrum) están estructuralmente concebidas para el trabajo de un equipo de desarrollo abocado al mismo proyecto. Como el desarrollo del software estuvo a cargo de una sola persona (con la colaboración y revisión de los directores) no se ajustó a un método estrictamente definido para un equipo como los mencionados. Sin embargo, muchas ideas propuestas por estos métodos han sido aplicadas, concibiendo un desarrollo evolutivo con énfasis en la adaptabilidad de los requerimientos. Algunas de las técnicas y procesos ágiles involucrados en este desarrollo han sido la utilización de un lenguaje de muy alto nivel (ver Tecnologías adoptadas ), la implementación de pruebas 29

38 automatizadas, la utilización de bibliotecas probas para la implementación de aspectos específicos de la solución, entre otras. 5.2 Desarrollo evolutivo adaptado Según [Sommerville2004], el desarrollo evolutivo se basa en la idea de una implementación inicial, exponiéndola a los comentarios del comitente o los usuarios, y refinándola a través de diferentes versiones preliminares (versiones beta) hasta obtener una versión que satisfaga el conjunto de requerimientos planteado. Figura 5.1: Esquema conceptual del desarrollo evolutivo Las actividades de especificación, desarrollo y validación se entrelazan en vez de separarse, con una rápida y constante retroalimentación entre estas. Existen dos grandes tipos de desarrollos evolutivos: 1. Desarrollo exploratorio donde el objetivo del proceso es trabajar con el cliente para explorar y precisar los requerimientos y obtener un sistema final. Se comienza con las partes del sistema que más cabalmente se comprenden y se evoluciona agregando nuevos atributos precisados por el comitente, la comunidad de usuarios o el propio equipo de desarrollo. 2. Prototipos desechables donde el objetivo del proceso es comprender mejor los requerimientos. Una vez evacuadas todas las incertidumbres, los prototipos se desechan y se diseña e implementa el sistema final desde el principio. 5.3 Modelado conceptual vs. UML Basado en los postulados de [AG-MANIF] durante el desarrollo se ha hecho hincapié en un modelado y documentación orientados a favorecer la comunicación por sobre el apego estricto y exhaustivo al lenguaje UML y sus técnicas asociadas, intentando que el resultado sea útil para el comitente, evaluadores y futuros desarrolladores del proyecto. 30 Capítulo 5. Metodología

39 5.3.1 Justificación Según afirma Terry Quatrani, evangelizadora de las metodologías ágiles en IBM, en [Quatrani2010] : Aunque sigas un proceso ágil, estarás realizando cierto grado de modelado sólo que no lo realizarás tanto como si utilizaras un proceso tradicional. La falta de formalidad en el modelado ágil no significa que no estás modelando, sino que te pones el foco en los beneficios de este sin las desventajas y confusiones de documentos extraños y burocráticos. Por su parte, Robert Martin sostiene en [Martin2006] que el modelado basado en UML en el desarrollo ágil es útil como instrumento de comunicación, pero su detalle no aporta valor significativo: No gastes mucho tiempo en esta tarea, no necesitas tanto detalle. Los modelos y los planos son necesarios en la arquitectura y la construcción civil porque es caro construir una casa para demostrar que su diseño funciona. El software no es así puedes validar tu idea con sólo codificarla, en igual tiempo que el que insume hacer un modelo UML que nada prueba por sí mismo. Aun más escéptico, Alans Stevens, reconocido ingeniero en software 1 y conferencista, opina en [Stevens2006] : No uso UML y noto que ninguno de mis colegas lo usa. Tengo sensaciones mezcladas acerca de su necesidad. Parece perfectamente razonable que debamos acordar como industria un conjunto de símbolos comunes para representar la programación orientada a objetos, pero UML tiene la típica apariencia de diseñado por un comité. (...) El aspecto más crítico en un diseño inicial, en mi experiencia, es la interfaz entre la UI (interfaz de usuario) y el modelo de objetos. Lamentablemente UML no aborda este problema y en cambio parece obsesionado por las minucias en una parodia de distracción académica. 1 Premio MOST VALUABLE PROFESSIONAL (MVP) de Microsoft por sus aportes a la comunidad de usuarios del lenguaje C# Modelado conceptual vs. UML 31

40 32 Capítulo 5. Metodología

41 CAPÍTULO 6 Tecnologías adoptadas Se expondrá a continuación las justificación de adopción de las herramientas y tecnologías utilizadas acompañada de una introducción a las características y conceptos claves de cada una. Ver También: En el capítulo Implementación se ahonda en algunos aspectos para explicar cuestiones particulares. 6.1 Lenguaje de programación Adopción de Python La elección del lenguaje de desarrollo fue clave y previa a muchos otras decisiones a lo largo de la vida del proyecto. Dadas las características y requerimientos de la aplicación a desarrollar se requería un lenguaje que satisfaga las siguientes condiciones: Lenguaje de muy alto nivel que permita rápido prototipado Multiplataforma Orientación a objetos completa y flexible Posibilidad de crear interfaz de usuario compleja Licencia libre no restrictiva Integración con bibliotecas de graficación 2D y 3D Documentación accesible y clara En el análisis realizado, Java y Python (entre otros) satifacen esas condiciones pero se optó por el segundo dadas las siguientes razones: 33

42 Se contaba con un dominio más profundo y mayor experiencia, dado trabajos académicos y laborales previos realizados con este lenguaje Es un lenguaje sintácticamente más sencillo Las opciones de graficación 2D y 3D se consideraron más logradas. Para una resultado equivalente debían usarse sendas bibliotecas en Java, con APIs distintas. Las interfaces de escritorio en plataformas Linux de Java no son nativas La posibilidad a futuro de mejorar la integración con el backend (Fortran) es limitada en Java, y en cambio Python cuenta con herramientas como F2Py ( Características de Python Python ( es un avanzado lenguaje de programación de alto nivel, interpretado, multiparadigma y multiplataforma. interpretado Un lenguaje interpretado es un lenguaje de programación que está diseñado para ser ejecutado por medio de un intérprete (o máquina virtual), en contraste con los lenguajes compilados. En general, el proceso consiste en traducción del código fuente a un bytecode que el interprete traduce a su vez, en tiempo de ejecución y cuando lo necesita, a código máquina. multiparadigma Python soporta múltiples paradigmas de programación. En vez de exigirle al usuario (o forzar el problema para) que se ajuste a un estilo de programación, el lenguaje permite diversos estilos o una mezcla de ellos. Puede usarse con un paradigma estructurado e imperativo (como C o Pascal), como orientado a objetos (como Java o C++). Además soporta características de programación funcional, orientada a aspectos (AOP), y de metaprogramación. multiplataforma Existen intérpretes de Python para distintas arquitecturas (x86, i64, powerpc, etc.) y sistemas operativos (Windows, Linux, OS/x, etc.) manteniendo el mismo código y funcionalidades de alto nivel. Esto permite una altísima portabilidad del software, de manera que un mismo programa puede ser ejecutado en diferentes plataformas. Un sencillo programa Hola Mundo 1 en Python se ve así: print " Hola Mundo!" Además, la mayoría de sus implementaciones 2, permiten ejecutar código en modo interactivo al estilo Matlab u Octave, de manera que las expresiones pueden ser introducidas una a una y ver el resultado de su evaluación inmediatamente: 1 Un programa Hola Mundo! es el que imprime el texto «Hola Mundo!» en un dispositivo de visualización (generalmente una pantalla de monitor). Se suele usar como introducción al estudio de un lenguaje de programación, siendo un primer ejercicio típico. 2 Python es un lenguaje estandarizado que tiene distintas implementaciones. La original y más utilizada es Cpython, implementada en C, pero existen implementaciones en Java ( ( y en Python mismo ( 34 Capítulo 6. Tecnologías adoptadas

43 >>> >>> a = range(10) >>> print a [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] Esto resulta útil tanto para los principiantes que se están familiarizando con el lenguaje como para los programadores avanzados: se pueden probar porciones de código en el modo interactivo antes de integrarlo como parte de un programa. Por diseño 3, Python tiene sintaxis muy clara que facilita la legibilidad del código. Esta característica es la razón por la que Guido van Rossum, su creador, lo compara con pseudocódigo ejecutable 4. El siguiente programa aplica conceptos de programación orientada a objetos como herencia y polimorfismo. La implementación en Python es la siguiente: class Animal: """Superclase que define un constructor común y un método abstracto""" def init (self, nombre): self.nombre = nombre def hablar(self): raise NotImplementedError(u"La subclase debe \ implementar el método") class Gato(Animal): def hablar(self): return Miau! class Perro(Animal): def hablar(self): return Guau, guau! #instanciación de 3 objetos dentro de una lista animales = [Gato( Michi ), Gato( Felix ), Perro( Firulai )] for animal in animales: print animal.nombre + : + animal.hablar() #Imprime lo siguiente: # #Michi: Miau! #Felix: Miau! #Firulai: Guau, guau! 3 La hipótesis en la que se basó su creador es que el código fuente suele leerse muchas más veces de las que se escribe, ya sea por el mismo autor tiempo despues de haberlo escrito, o por otros programadores. 4 Syntactically, Python code looks like executable pseudo code., [GvR1998] 6.1. Lenguaje de programación 35

44 Puede ver el artículo [WIKIPEDIA1] para una comparación (en particular la extensión y legibilidad) de código equivalente en otros lenguajes de programación. Nota: Dar una introducción completa a las capacidades de Python como lenguaje de programación quedan fuera de los alcances de este trabajo. Para ampliar los conceptos aquí vertidos puede ver [TUT-PSF] y [MP2001]. En Python el tipado de datos es dinámico (al igual que la asignación de memoria), es decir que el tipo de dato (entero, cadena, punto flotante u otros tipos de más alto nivel como listas o diccionarios) se determina automáticamente al momento de la asignación de la variable, a diferencia de los lenguajes de tipado estático (como Java o C) que exigen la declaración de todas las varibles con sus tipos antes de ser utilizadas. Sin embargo, el tipado es fuerte, ya que una vez que la variable adquiere un tipo (o sea, ha sido asignada), queda determinado su tratamiento. Por ejemplo la operación + entre cadenas de texto retorna la concatenación de las cadenas, mientras que entre tipos numéricos retorna la suma. Intentar operar con + entre un número y una cadena dará un error sino se convierte una de las dos variables al otro tipo de manera explícita. El lenguaje incluye una robusta biblioteca estándar (se dice habitualmente que Python tiene con las baterías incluídas ) con acceso a funcionalidades de todo tipo como protocolos de internet, funciones matemáticas, manejo de hilos y multiprocesos, pruebas unitarias, manipulación de XML y abstracción de llamadas al sistemas operativo subyacente, entre muchas otras. Además de la biblioteca incorporada, puede utilizar diversas bibliotecas externas, por ejemplo para desarrollar interfaces gráficas de usuario (GUI) (ver WxPython), y a la vez es extensible en C o C++. Esta facilidad de integración permite que frecuentemente sea utilizado como lenguaje pegamento (ver [GvR1998] ) para interconectar código que por razones de diseño, de performance o históricas están desarrolladas en otro lenguaje de más bajo nivel, permitiendo aprovechar las ventajas de Python. Python ha ganado popularidad no sólo entre programadores aficionados sino en el mercado altamente competitivo de la industria del software. Como plantea Shannon Behrens en el prólogo de [ZIADE2008]: Hubo un tiempo en el que las compañías me llamaban loco cuando insistía en usar Python. En estos días, simplemente no hay suficientes programadores Python para todas. Grandes empresas como Google, YouTube, VMware y DreamWorks están en una lucha constante para contratar todo buen talento Python que puedan encontrar Python en el software científico Como se afirma en [JH-FP] en la sección Who is using Python?, el uso de Python en la computación científica es tan amplio como el campo mismo. Los autores destacan muchos usos en distintas universidades y centros de investigación del mundo: 5 Traducción del inglés propia. 36 Capítulo 6. Tecnologías adoptadas

45 El Jet Propulsion Laboratory (JPL) de la NASA (National Aeronautics and Space Administration, EE.UU.) usa Python como interfaz a bibliotecas Fortran y C++ que conforman una suite de herramientas de visualización de trayectorias. El Space Telescope Science Institute (STScI) lo usa en muchos aspectos de su pipeline, planificando la adquisición de datos del telescopio Hubble, administrando volumenes de información y analizando imágenes atronómicas. La National Oceanic Atmospheric Administration (NOAA) usa Python para el análisis sintáctico de archivos, el prototipo de algoritmos computacionales, la codificación de interfaces de usuario de escritorio y web y el desarrollo de modelos. La Enthought Corporation lo usa para adaptar a las necesidades de sus clientes aplicaciones para la exploración de petroleo. Ver También: Muchos otros casos de éxito son detallados en el texto mencionado, en los dos volumenes de Python Success Stories de la editorial O Reilly s 6 y en NumPy Los tipos de datos incorporados con Python nativamente para contener otros tipos de datos u objetos (en particular listas y tuplas), son muy eficientes pero están diseñados para ser multipropósito. Estos contenedores pueden albergar cualquier tipo de objeto (incluso una mezcla de ellos) y las listas, en particular, pueden mutar (agregar, modificar o borrar elementos) dinámicamente. Es decir que si bien pueden usarse listas o tuplas como un arreglo de datos, no están especialmente concebidas para tal fin. Nota: Los siguientes párrafos descriptivos han sido tomados, a modo de paráfrasis y traducido por el autor, del capitulo What is NumPy? de [NumPy-UG]. NumPy ( es una biblioteca que extiende Python para complementar este aspecto, proveyendo un tipo de objeto vector multidimensional (ndarray) y varios objetos derivados (como vectores enmascarados o matrices), además de rutinas optimizadas para la operación sobre estos vectores, incluyendo operaciones matemáticas y lógicas, manipulación de dimensiones, álgebra lineal, operaciones estadísticas básicas, simulación aleatoria, etc. Considere el código siguiente que dado dos secuencias unidimensionales a y b de igual longitud y con todos sus elementos numéricos, multiplica elemento por elemento y dispone el resultado en una nueva lista c: 6 Python Success Stories: 8 True Tales of Flexibility, Speed, and Improved Productivity (2002) y Python Success Stories Volume II: 12 More True Tales (2005), O Reilly Associates 6.2. NumPy 37

46 c = [] for i in range(len(a)): c.append(a[i]*b[i]) El resultado será correcto, pero considerando que las secuencias a y b pueden tener millones de elementos, se pagará el precio de una iteración ineficiente. Esta operación, siendo a y b objetos ndarray de NumPy, resultaría en: c = a * b Dicho código funcionaría siempre que a y b tengan las mismas dimensiones, independientemente que sean uni o multidimensionales. El ejemplo ilustra dos características de NumPy que son gran parte de las bases de su poder: vectorización y broadcasting La vectorización describe la ausencia de iteraciones explícitas e indización (que toman lugar, por supuesto, detrás de escena, en un optimizado y precompilado código C). La vectorización tiene muchas ventajas: El código vectorizado es más conciso y fácil de leer. Menos líneas de código habitualmente implican menos errores. El código se parece más a la notación matemática estándar (por lo que es más fácil, por lo general, corregir código asociado a construcciones matemáticas La vectorización redunda en un código más pythónico 7 El broadcasting o difusión es el término que describe el comportamiento elemento por elemento de las operaciones. En general, en NumPy todas las operaciones adoptan por defecto un comportamiento de este tipo (no sólo las operaciones aritméticas sino las lógicas, las funcionales y las de nivel de bits). Por defecto Numpy define el tipo de dato del array de elementos como el mínimo capaz de contener la información brindada. Se incluyen tipos flotantes de hasta 128 bits de precisión (16 bytes) Alternativa analizada Estrictamente, existe un módulo que da soporte a arreglos (ver Array ( en la biblioteca estándar de Python. Sin embargo, las funcionalidades provistas no son comparables a las de Numpy y fue por ello descartado. 7 El código que sigue los principios de legibilidad y transparencia propuestos por Python se dice que es pythonico. Contrariamente, el código opaco u ofuscado es bautizado como no pythonico. Ver [PEP8] y [PEP20]. 8 Los tipos float64 y complex128 existen en todas las plataformas. En algunas, la precisión es extendida a 96 y 128 bits por número (el doble para complejos) si la arquitectura lo permite. 38 Capítulo 6. Tecnologías adoptadas

47 6.3 Matplotlib Matplotlib ( es una biblioteca para Python, liberada como software libre, que permite la generación de diferentes tipos de gráficos en 2D y 3D con calidad de publicación. Se pueden generar gráficos cartesianos, polares, de barras, histogramas, de superficie, etc. Figura 6.1: Ejemplos de gráficos logrados con Matplotlib Matplotlib puede usarse de una manera pythónica y orientada a objetos. Está principalmente escrito en Python, aunque se basa fuertemente en NumPy y otras extensiones para proveer buena performance incluso con arreglos grandes. Si bien fueron estudiadas otras bibliotecas libres con prestaciones similares como Chaco o GNUplot 9, se optó por Matplotlib dadas las siguientes características: Cuenta con una extensa y clara documentación (ver [MPLDOC]) Es orientado a objetos: se puede heredar, extender y sobrecargar cada tipo de objeto que define La calidad de los gráficos es excepcional, permitiendo la exportación a muchos formatos gráficos, incluyendo PS (PostScript) y SVG (Scalable Vector Graphic) Es empotrable dentro de las bibliotecas para GUI más utilizadas permitiendo realizar aplicaciones de escritorio manteniendose en un alto nivel de abstracción. Incorpora muchos paquetes que extienden las posibilidades: el muy logrado paquete para graficación 3D, graficación sobre mapas geográficos, utilidades para la interacción con Microsoft Excel, etc. Matplotlib incluye una API que tiene su origen en la emulación de los comandos gráficos de Matlab, denominada PyPlot, especialmente orientada a su uso interactivo. El siguiente código es un ejemplo extraído de [ST2009] >>> import matplotlib.pyplot as plt >>> import numpy as np >>> x = np.arange(0.0, 6.0, 0.01) 9 Chaco ( y GNUplot-Py ( son las más notables alternativas Matplotlib 39

48 >>> plt.plot(x, x**2) >>> plt.show() El resultado se observa en la figura 6.2. Figura 6.2: Gráfico generado interactivamente 6.4 WxPython wxwidgets ( es una biblioteca en C++ que permite desarrollar interfaces gráficas para aplicaciones multiplataforma que corren en Microsoft Windows, OS X, GNU/Linux o UNIX de 32 o 64 bits. wxpython ( es un wrapper de la biblioteca wxwidgets para el lenguaje de programación Python. Junto a Python permite el desarrollo rápido de aplicaciones gráficas de escritorio multiplataforma. Una de las características sobresalientes de wxwidgets es su uso nativo de las APIs gráficas de cada entorno, brindando una apariencia y experiencia de uso nativa para cada ambiente. Esto significa la misma aplicación, sin modificaciones (al menos significativas), adopta las características gráficas definidas por el usuario en el entorno de escritorio. En concreto: se ve como una aplicación Windows si se corre en Windows, como una aplicación GNOME si se corre sobre el gestor de escritorio GNOME en Linux, y como una aplicación OS/X en platafomas Mac: 40 Capítulo 6. Tecnologías adoptadas

49 Figura 6.3: El mismo programa wxpython ejecutado en Windows, Linux y Mac La guía [NR-RD2006] escrita por dos de los desarrolladores de la biblioteca es un material de referencia obligado para el desarrollo con wxpython. Allí se exponen como características relevantes la orientación a objetos y la orientación a eventos. Atención: En la bibliografía de wxpython se denomina window a cualquier elemento gráfico que ocupa espacio visual y puede ser contenido por otro. Lo que comunmente se denomina window (ventana) en otros escenarios, en wxpython es un frame, es decir, una ventana de programa. Se expondrán estos conceptos con un ejemplo: import wx class MyFrame(wx.Frame): def init (self): wx.frame. init (self, None, -1, "Ventana", size=(300, 300)) panel = wx.panel(self, -1) wx.statictext(panel, -1, "Pos:", pos=(10, 12)) self.posctrl = wx.textctrl(panel, -1, "", pos=(40, 10)) panel.bind(wx.evt_motion, self.onmove) def OnMove(self, event): pos = event.getposition() self.posctrl.setvalue(" %s, %s" % (pos.x, pos.y)) if name == main : app = wx.pysimpleapp() 6.4. WxPython 41

50 frame = MyFrame() frame.show(true) app.mainloop() La subclase MyFrame hereda de la clase wx.frame y extiende su constructor incluyendo un objeto Panel (elemento contenedor de otros objetos gráficos), una línea de texto estática y una caja de texto denominada self.posctrl. Además se realiza un binding, es decir, la asociación de un evento identificable a una acción, un método o función que indica como responde el programa ante el acaecimiento del evento. En este caso se asocia el evento wx.evt_motion en el objeto panel (que ocurre cuando se mueve el puntero sobre el objeto) al método OnMove. Como ejemplifica la figura 6.4, cada vez que se mueve el puntero sobre el panel, la caja de texto será actualizada con las coordenadas donde este se encuentra. Figura 6.4: Captura del ejemplo de marras Como característica avanzada, wxpython incluye el módulo AUI (ADVANCED USER INTER- FACE) que permite el desarrollo de interfaces de usuario orientadas a la usabilidad y de alta calidad, abstrayendo y encapsulando el control de aspectos comunes. En particular, este módulo permite la gestión de subframes, de manera que los subcomponentes o subventanas pueden configurarse mediante operaciones comunes como abrir, cerrar u ocultar, y ser guardadas como perspectivas que el usuario puede recuperar en posteriores sesiones de trabajo Alternativas analizadas Python soporta un gran número toolkits para desarrollo de interfaces de usuario. Las estudiadas como alternativa fueron: GTK a través de PyGTK QT a través de PyQT o PySide 42 Capítulo 6. Tecnologías adoptadas

51 Tcl/Tk a través del paquete estándar Tkinter Si bien Tkinter contaba con la ventaja de no requerir software adicional a Python para su utilización, se optó por wxpython dada la experiencia previa y la apariencia nativa en cada sistema operativo. 6.5 El patrón Publish/Subscribe Un patrón de diseño (también catalogado como patrón de mensajería) de recurrente aplicación en GPEC ha sido Publish/Subscribe, frencuentemente abreviado Pubsub. Se trata de una arquitectura de paso de mensajes desacoplada (y en algunas implementaciones distribuída) donde existen remitentes (o publicadores ) que envían mensajes ante el acaecimiento de un suceso específico (por ejemplo, un evento originado por el usuario como el click sobre un botón) sin conocimiento alguno sobre qué sucede despues con el mensaje. Análogamente existen receptores (o suscriptores ) que en cuya inicialización se define a qué tipo de mensajes se suscribirán (el tipo se define en función del asunto o topic ) y qué acción (un método o función) debe ejecutarse cuando un mensaje de tal tipo arribe. Figura 6.5: Diagrama conceptual de la arquitectura Pub/Sub Como se describe en [vdlaar2002] Pubsub facilita el desacople de componentes (callables, módulos, paquetes) dentro de una aplicación. Los conceptos involucrados son: Permitir que partes de una aplicación envíe mensajes al resto de la aplicación sin tener que conocer: si el mensaje será manejado y usufructuado: puede suceder que el mensaje se ignore completamente o que sea manejado en muchas partes diferentes de la aplicación cómo será manejado el mensaje: al publicador no le importa qué se hará con el mensaje y su contenido; 6.5. El patrón Publish/Subscribe 43

52 tampoco hay control del orden en que un mensaje dado se enviará al resto de la aplicación (comportamiento no determinístico). Permitiendo que partes de una aplicación reciban y manejen mensajes desde el resto de la aplicación sin tener que conocer quién envió el mensaje. Un receptor (listerner) es una parte de la aplicación que quiere recibir mensajes. Un receptor se suscribe a uno o más tópicos. Un emisor (sender) es cualquier parte de la aplicación que envía (deposita en el intermediario) un mensaje con un tópico dado, y opcionalmente, cualquier información adjunta. Este intermediario (a veces conocido como broker, o directamente pubsub) entrega este mensaje a todos los receptores suscriptos Ventajas Acoplamiento débil: la topología de Pubsub, basada en la intermediación y el desconocimiento de identidades y comportamientos de los objetos que interactuan permite un desacople de los componentes de la aplicación. Esto significa que las distintas partes de la aplicación son independientes entre sí, de modo que pueden facilmente desactivarse componentes no críticos sin afectar al conjunto de la aplicación. Esta estrategia es útil para realizar pruebas de seguridad. Funcionalidad configurable : Dado que un emisor no tiene necesidad de conocer la existencia de un receptor, es fácil diseñar una arquitectura basada en plugins que permite mantener un núcleo y agregar funcionalidades extra con posterioridad (incluso desarrolladas por terceros). Esto trae aparejada la posibilidad de adaptar, mediante extensiones que se activan o no, las características del software en función de las necesidades del usuario. Escalabilidad: En las implementaciones distribuidas de demanda moderada (donde los mensajes se transmiten entre múltiples procesos o, incluso, equipos), PubSub provee una arquitectura mucho más simple y autogestionada que la típica topología cliente/servidor para tareas de procesamiento paralelo o Sin embargo, la eficiencia no suele ser proporcional en sistemas de alta demanda computacional Pubsub en Python En GPEC se ha utilizado el paquete Python Pubsub ( de Oliver Schoenborn, en su versión Esta implementación es muy sencilla y se basa en la existencia de un objeto único (Ver singleton), pub, que controla el envío y las suscripción a los mensajes. Se describe en el siguiente código: from pubsub import pub # declaración de la función "destino" def destino(arg1, arg2=none): 10 En 2010 el autor de Python PySub reescribió completamente la API, agregando una orientación a objetos del paso de mensajes más poderosa, a la que denominó version Capítulo 6. Tecnologías adoptadas

53 print Mensaje con arg1=" %s" y arg2=" %s" % (arg1, arg2) # declaración de suscripción pub.subscribe(destino, asuntoparticular ) # función que envía un mensaje def hacer_algo_y_avisar(): print Se enviará un mensaje pub.sendmessage( asuntoparticular, arg1=123, arg2=dict(a= abc, b= def )) if name == main : hacer_algo_y_avisar() Cuyo diagrama de secuencia se muestra en 6.6. Figura 6.6: Diagrama de secuencia para una interacción sencilla entre emisor y receptor via Pub/Sub 6.6 Gestión de proyecto En cualquier proyecto de software no trivial, sistematizar todos los aspectos del desarrollo es una necesidad ineludible. Esto incluye, por supuesto, la evolución del código, pero también su documentación, el reporte, seguimiento y solución de los errores detectados, la planificación de las etapas de desarrollo, la estimación de la carga de trabajo, etc. La gestión de proyecto es uno de los aspectos esenciales de la ingeniería de software. Como se explaya en [GR-STE2005], se necesita más que una buena idea y equipo de programadores 6.6. Gestión de proyecto 45

54 talentosos para tener éxito con un proyecto de software. Exiten técnicas y herramientas para minimizar la ocurrencia de errores, la pérdida de información o tiempo. Del vasto conjunto de herramientas, se detallan aquí las utilizadas para el desarrollo de este trabajo. 6.7 Control de versiones Un VCS (Sistema de Control de Versiones) es un software capaz de llevar registro de la evolución incremental de cualquier conjunto de archivos, permitiendo recuperar estados anteriores (de una fecha en particular, por ejemplo) de una manera eficiente y automatizada. Cada vez que se detecta un cambio, el software de control almacena sólo la información necesaria (en particular la diferencia respecto a la versión anterior de cada archivo) en vez de guardar todo el archivo completo. En particular,tiene mucha utilidad para archivos de texto, como el código fuente de un software. El VCS utilizado para este proyecto fue Subversion ( (frecuentemente abreviado SVN). Subversion es un VCS centralizado, es decir, requiere un servidor central (repositorio), generalmente accesible vía internet, que almacena todas las versiones (revisiones) de cada archivo. El usuario/desarrollador realiza un commit para enviar sus modificaciones locales al repositorio, y un update para actualizar la versión local (copia de trabajo) con la última versión (o la indicada explícitamente) del repositorio. Con cada commit, el sistema solicita la inclusión de un mensaje descriptivo de la modificación realizada, de manera de poder realizar un seguimiento y detectar un estado en particular si, por alguna razón, es necesario recuperar. Como servidor svn se utilizó el servicio de Google Code, que brinda un repositorio y otras herramientas de gestión de proyecto de manera gratuita, para desarrollos de software libre / open source. El proyecto se encuentra en la dirección Figura 6.7: Portada del proyecto en Google Code. 46 Capítulo 6. Tecnologías adoptadas

55 6.8 Seguimiento de errores y propuestas El mismo servicio que provee el repositorio svn gratuito, incluye un sistema de gestión de errores (bug tracker o, más generalmente, issue tracker), del cual se ha hecho uso exhaustivo. Estos sistemas permiten la sistematización del ciclo de vida de un error, solicitud de funcionalidad o mejora. A través de una interfaz web (característica común a casi todos los sistemas de este tipo), el propio equipo de desarrollo o usuarios particulares pueden reportar un incidente (issue), con un mensaje breve y descriptivo que permita reproducir el error reportado, o bien fundamentando la necesidad de una mejora o nueva funcionalidad. El issue es asociado a palabras clave que identifican su estado (abierto, aceptado, rechazado, solucionado, etc), su gravedad o interés (bajo, normal, alto), etc. Por supuesto, cada una de estas palabras clave puede cambiar con el tiempo, adjuntando mensajes que indican las tareas realizadas en cada intervención, hasta que el issue sea cerrado, ya sea por que se logró una solución o se decidió descartarlo por alguna razón. La utilidad de este tipo de sistemas permite la descentralización del reporte de errores, permitiendo a la comunidad de usuarios participar de la mejora del software. También permite llevar registro de errores o funcionalidades pendientes en cada momento del desarrollo, facilitando la planificación de lanzamientos de nuevas versiones. 6.9 Documentación Gran parte del desarrollo de un software así como el de un proyecto integrador o tesis en general, cualquiera sea el tópico, es la documentación. Contar con procedimientos y herramientas adecuadas para la realización de este trabajo es tan necesaria e importante como el lenguaje de programación adoptado para la codificación del software. A lo largo de todo el proyecto se fue documentando distintos aspectos del desarrollo, con distintos niveles de detalle. Se utilizaron las siguientes herramientas restructuredtext Este documento se ha escrito utilizando el lenguaje de marcado restructuredtext ( (RST O REST). RST permite aportar semántica a un documento de texto plano, de manera equivalente a LaTeX pero mucho más sencilla, conservando legibilidad en formato fuente. A través de diversas herramientas se puede convertir rst a distintos formatos, como html, pdf o código LaTeX. Como ejemplo de la sintáxis de RST se muestra el inicio de esta misma sección: restructuredtext Este documento se ha escrito utilizando el lenguaje de 6.8. Seguimiento de errores y propuestas 47

56 marcado restructuredtext < _ (:abbr: rst o rest ). El uso de restructuredtext permitió obtener un documento de apariencia profesional, con abundantes referencias cruzadas y gestión bibliográfica y terminológica, con el plus de obtener una versión web desde el mismo contenido. Alternativas analizadas La alternativas analizadas fueron OpenOffice Writer que utiliza un esquema WYSIWYG (del inglés: lo que ves es lo que obtienes) al estilo Microsoft Word pero utilizando el formato estándar OpenDocument, y el lenguaje de marcado para textos científicos LaTeX. El primero fue descartado por la dificultad de mantener homogeneidad de estilo y el pobre soporte a referencias cruzadas, y el segundo fue descartado por la complejidad de su sintáxis Wiki Una wiki es un sistema para la creación de documentos hipertextuales de manera sencilla. Con el permiso adecuado, un documento (en general una página web ) se convierte en editable, pudiendo modificar o ampliar el contenido, incluir imágenes u otro tipo de información, o generar enlaces a otros documentos. El servicio Google Code incopora una Wiki que se ha utilizado como cuaderno de notas para llevar cuenta de las minutas, links de interés, etc Sphinx Sphinx ( es una herramienta para la documentación de software. Si bien permite la autodocumentación (realizando introspección de las cadenas de documentación y las entidades del código fuente) está orientado a la creación de documentación escrita por humanos. Sphinx utiliza como formato de entrada el formato restructuredtext ( y genera versiones en html (con motor de búsqueda y resaltado de código incorporado) y PDF de alta calidad a través de Latex. 48 Capítulo 6. Tecnologías adoptadas

57 CAPÍTULO 7 Arquitectura En este capitulo se describe, de manera conceptual, el diseño arquitectónico de la aplicación. La metodología ágil e iterativa adoptada no implica que no haya existido una profunda instancia de reflexión en el diseño en la aplicación, sólo que esta no es estado basada íntegramente en una descripción formal y exhaustiva como UML. Atención: La adopción de principios del desarrollo ágil y el desarrollo evolutivo implica que no se ha utilizado un proceso de ingeniería de software más frecuentemente enseñado en el ámbito académico. Esto es, el proceso de diseño e implementación han sido mancomunados iterativamente en vez de separados estrictamente. De esta manera, muchos de los conceptos arquitectónicos están intrínsecamente aquí expuestados están relacionados intrísecamente con su implementación. 7.1 Modelo conceptual La siguiente infografía describe conceptualmente, de manera simplificada, el flujo de procesamiento de la información. Figura 7.1: Diagrama conceptual del flujo de información entre las distintas capas El frontend, objeto de este trabajo, se compone de la interfaz de usuario, la gestión de base de 49

58 datos, los algoritmos de procesamiento de la información y la graficación. API (Application Programming Interface) refiere a la interfaz de comunicación definida para la comunicación entre ambas partes, que está basada en archivos de texto plano con un formato particular. El relevamiento de esta interfaz formó parte del desarrollo, y se describe exhaustivamente en Especificación de la interfaz de comunicación. Una librería modularmente independiente, basada en ese relevamiento se programó para dar soporte a la comunicación. Se describe en Invocación de ejecutables del backend. El backend refiere al conjunto de programas desarrollados en Fortran que implementan los algoritmos de cálculo. Estos programas leen uno o varios archivos de entrada y producen un archivo de salida con los vectores de números reales resultantes de los cálculos (la información a graficar) junto a otras informaciones relativas al contexto de cálculo Los algoritmos de procesamiento del frontend analizan y extraen sólo la información útil, haciendo una conversión de texto a un tipo de dato numérico y con esa información se realizan los gráficos correspondientes. 7.2 Componentes y capas de software El diagrama de la figura 7.2 describe las capas y componentes de software involucrados en la aplicación. Figura 7.2: Arquitectura Frontend - Middleware - Backend Este diagrama brinda más detalles sobre la vinculación de los componentes y las capas de software. Por simplicidad, se ha obviado la descripción de los componentes Matplotlib y Numpy, asumiéndolos tácitamente como parte de la aplicación. 50 Capítulo 7. Arquitectura

59 Los componentes de middleware de conexión a la base de datos sqlite3 (un wrapper sobre Sqlite) y el módulo que permite la ejecución de procesos hijos (o subprocesos ) subproccess forman parte de las versiones 2.5 y 2.4 de Python respectivamente. Es decir, no son componentes de software que se requieran por separado. La llamada a los procesos del backend a través de subproccess está intercedida por el emulador Wine en todas las plataformas diferentes a Windows. Esto se describe ampliamente en La dependencia con Wine. Un componente que se representa intrínsecamente vinculado al frontend es Pub/Sub. La explicación de la importancia estructural de este componente se describe en Utilización de Publish/Suscribe en GPEC. 7.3 Capa de base de datos La aplicación no requiere una infraestructura de base de datos compleja. En particular, los datos almacenados son las constantes de compuestos químicos. Se incluye una vasta base de datos termodinámicos para más de 2000 compuestos, corroborados mediante DIPPR Project 801 < 1 que incluye información como la fórmula, el factor acéntrico, el volumen, la temperatura y la presión crítica, etc. Esta información se comporta en modo sólo lectura 2 a través de la interfaz de usuario, pero se brinda también una categoría editable para permitir compuestos definidos por el usuario que pueden ser agregados como una copia de un compuesto existente en DIPPR (que acepta, entonces, la modificación o ajuste de sus valores) o bien como un nuevo compuesto definido desde datos experimentales Modelo Entidad-Relación El modelo Entidad-Relación es un diagrama que describe la interrelación de la información gestionada por la base de datos. Se muestra en la figura 7.3. Ver También: Vea Implementación de base de datos para la implementación. 7.4 Diagrama de paquetes El diagrama de paquetes de la figura 7.4, que forma parte de la suite definida por UML 2.0, muestra los paquetes y módulos (unidades de código fuente) y su árbol interdependencia. 1 DIPPR 801 es un producto comercial cuya licencia ronda los u$s3400 anuales. GPEC incluye en su base datos equivalentes a una porción de la información que ese producto ofrece, sin depender de esta de manera alguna. No obstante, el autor considera este aspecto como suceptible a acarrear complicaciones legales y comerciales, que deberán revisarse y solucioanrse a futuro. 2 Sqlite no permite definir tablas o registros de datos como sólo lectura. Queda en potestad del desarrollador vedar la posilidad de modificación como parte del proceso de validación. Sin embargo, siempre es posible para un 7.3. Capa de base de datos 51

60 Figura 7.3: Representación de las entidades con sus atributos y la relación entre las mismas Figura 7.4: Diagrama de paquetes 52 Capítulo 7. Arquitectura

61 Este diagrama se realizó mediante un análisis de ingeniería inversa utilizando la herramienta pyreverse ( 7.5 Diagramas de clases Se incluyen en las siguientes figuras diagramas de clase de la aplicación. Se insiste en que en el proceso de desarrollo no existió una especificación de esta magnitud de detalle previa a la implementación, pero se ofrecen al lector, generadas mediante el análisis del código, como orientación sobre la estructura arquitectónica de la aplicación Relación y dependencia de los paneles El diagrama de la figura 7.5 muestra la relación y jerarquía de las clases que componen la interfaz de usuario. Figura 7.5: Jerarquía de clases de la GUI La clase ShellPanel corresponde a una consola interactiva que se incluyó en uno de los prototipos presentados, pero luego ha sido descartada en versiones actuales por no formar parte de los requerimientos especificados Relaciones del Panel de caso El diagrama de clases de la figura 7.6 hace hincapié en la clase CasePanel y sus relaciones de composición usuario abrir y modificar la información manualmente a través de un gestor que interprete el formato sqlite Diagramas de clases 53

62 Figura 7.6: CasePanel y su composición Clases vinculadas a la graficación El diagrama de la figura 7.7 describe las clases relacionadas con la graficación. Muchas de estas forman parte de MatploLib. Figura 7.7: Diagrama de clases relacionadas con la graficación Tipos de gráficos Los tipos de gráficos 2D y 3D tiene un diseño jerarquico de clases como se muestra en la figura 7.8, donde las subclases reimplementan el método que selecciona el subconjunto de datos que cada gráfico necesita. Los métodos comunes son heredados de la superclase. 54 Capítulo 7. Arquitectura

63 Figura 7.8: Diagrama de clases de los distintos tipos de diagramas soportados 7.5. Diagramas de clases 55

64 7.6 Preceptos adoptados en el diseño de UI Como se ha mencionado, la usabilidad e intuitividad de la interfaz de usuario ha sido un requerimiento de especial atención. Mucha bibliografía fue consultada al respecto, rescantando en particular muchos conceptos y consejos de Joel Spolsky en [Spolsky2001] 3. Entre muchos, se destacan: Brindar contextos intuitivos y secuencias de operación lógicas. Minimizar las opciones en simultáneo. Cada opción es una decisión que se le exige al usuario. Los usuarios no leen manuales (de hecho tampoco leen mensajes en pantalla si son largos) Convenciones por sobre configuraciones: limitar los parámetros requeridos Valerse de las costumbres del usuario: no reinventar la rueda Un software complejo con un acabado estudio de usabilidad es Mayavi ( (Figura 7.9) que ha servido de inspiración para el diseño de GPEC. Figura 7.9: Interfaz de la aplicación de visualización de diagramas VTK que sirvió como inspiración para la interfaz de GPEC. 3 Una versión online gratuita de este libro se encuentra en 56 Capítulo 7. Arquitectura

65 Algunas decisiones concernientes a la usabilidad han sido: El diseño acompaña al workflow: primero se define el sistema, opcionalmente se manipulan los cálculos y por último se grafica. Sólo el primero y el último paso son obligatorios. La ubicación de los botones principales está dispuesta en función del flujo de lectura de occidental (de izquierda a derecha y de arriba hacia abajo) de manera de resultar intuitiva la secuencia de acciones demandada al usuario Todos los botones tiene asociado un ícono descriptivo Los componentes que muestran información no modificable se mantienen en modo sólo lectura y visualmente se ven grisados. Un conjunto de parámetros (coeficientes, reglas de combinación) se ubican en un panel colapsable. Al expandirlo, el panel genera automática una barra de desplazamiento vertical. El uso del símbolo + en la ubicación dispuesta es una convención popularizada por los navegadores web para abrir una nueva pestaña de trabajo. Dado el contexto resulta evidente que genera un nuevo caso. Los resultados del estudio e implementación en materia de usabilidad se analizan en Pruebas de usabilidad Preceptos adoptados en el diseño de UI 57

66 58 Capítulo 7. Arquitectura

67 CAPÍTULO 8 Implementación Este capítulo recorre distintos aspectos de la implementación de GPEC. Como se ha descripto en Metodología, el proceso de implementación y el de diseño han tenido a una evolución conjunta e integrada a lo largo de la vida del proyecto. Si bien una visión de diseño se resume en el capítulo Arquitectura, algunas decisiones y detalles se justifican en este capítulo. 8.1 Utilización de Publish/Suscribe en GPEC En El patrón Publish/Subscribe (ver Marco Teórico) se describió el patrón PubSub y la implementación utilizada para diferentes aspectos del funcionamiento de GPEC. Aquí se describen en detalle sus usos en la aplicación Panel de mensajes Como se ha dicho, PubSub constituye el patrón principal y toda la orientación a eventos de la biblioteca se basa en una comunicación vía esta biblioteca. El ejemplo canónico es el panel de log (registro de mensajes de usuario), donde se registra una crónica de eventos de interés para el usuario, denotados en su categoría con un símbolo y la hora del suceso. Figura 8.1: A través de PubSub, cualquier parte del programa envía avisos que el panel (un receptor) mostrará al usuario. 59

68 En la incialización del panel se realiza la subscripción a los mensajes con tópico log, y asigna como acción el método OnAppendLog(): class LogMessagesPanel(wx.Panel): def init (self, parent, id): wx.panel. init (self, parent, id) self.list = wx.listctrl(self, -1, style= wx.lc_report wx.sunken_border self.setuplist() sizer = wx.boxsizer() sizer.add(self.list, 1, wx.expand) self.setsizerandfit(sizer) pub.subscribe(self.onappendlog, log ) Ante la recepción de un mensaje se produce la invocación del método adjuntando como parámetro un objeto mensaje (msg) en cuyo atributo data se almacena la información enviada por el remitente: def OnAppendLog(self, msg): ico = self.icon_map[msg.data[0]] message = msg.data[1] index = self.list.insertimagestringitem(sys.maxint, message, ico) self.list.setstringitem(index, 1, time.strftime( %H: %M: %S )) self.list.ensurevisible(index) #keep scroll at bottom if msg.data[0] == error : wx.bell() La información en msg.data es, por convención de diseño, una tupla de la forma (asunto, mensaje de usuario). Los asuntos posibles están asociados al icono que los representan: Asunto Símbolo Descripción ok info warning error Acción existosa Información importante Advertencia Error Como se observa en el código, en caso de un mensaje del tipo error, además de agregar el mensaje se ejecuta wx.bell() que produce una alerta sonora. El remitente de mensajes de log se realiza desde múltiples puntos. Por ejemplo ante la carga de la aplicación, cuando se define un sistema, cuando se realiza un cálculo (mediante la invocación a un ejecutable del backend), etc. Por ejemplo, en el código de ejecución de la aplicación, en aui.py se observa: (...) main_frame.show() pub.sendmessage( log, ( ok, GPEC is ready. Define a system to begin ) ) 60 Capítulo 8. Implementación

69 app.mainloop() Solicitud de gráficación Otro uso de PubSub se produce durante la solicitud de generación de gráficos. Se resume en el diagrama de secuencia de la figura 8.2. Esto significa que el panel de definición de casos está independizado del panel contenedor de los gráficos generados a traves de PubSub. El mencanismo invocación del backend (desde donde se obtienen los datos a graficar) se verá más adelante. El objeto SuitePlotsPanel es el panel de pestañas donde se muestran los gráficos de todos los casos de un proyecto. Cada una de estas pestañas contiene un objeto PlotPanel que es el que soporta la integración con Matplotlib y contiene el diagrama en sí. Esta integración se verá en Integración Matplotlib-WxPython Exposición de archivos de datos Cada invocación a un ejecutable del backend dependen de una entrada y produce una salida 1 en un archivo de texto. Para usuarios avanzados que conocen la estructura y significado de estos archivos (descriptos en :ref: api ), es deseable que tengan un acceso al contenido desde la propia aplicación, para encontrar información numérica cuya precisión se pierde en un gráfico. Esta tarea se hace a través de PubSub. El emisor envía un mensaje con tópico add_txt adjuntando como información una tupla con la ruta al archivo y el caso al que este cálculo pertenence. Por ejemplo, la función que escribe el archivo de entrada para el cálculo de parámetros es la siguiente: def write_conparin(self, direction, model_id, data): """ Write the input file CONPARIN.DAT. data could be compound constants (direction=0) or model paramater (d 0 -> [tc, pc, vc, omega] Example: [u , u 48.72, u , u ] """ filename = CONPARIN.DAT filepath = os.path.join(self.path_temp, filename) template = "{0} {1}\n {2}" if int(direction) == 0 and int(model_id) in (1,2,3): 1 En realidad, la llamada está intercedida por una función decoradora (memoize) que realiza un caché de los resultados la primera vez que se invoca. Si en sucesivas llamadas los parámetros coinciden, se devuelven los datos almacenados en memoria, tarea mucho más rápida que recalcular Utilización de Publish/Suscribe en GPEC 61

70 Figura 8.2: Secuencia para la generación de un diagrama desde el evento generado por el usuario 62 Capítulo 8. Implementación

71 Figura 8.3: Panel de navegación y visualización de archivos en entrada y salida data = data[:-2] + [data[-1], data[-2]] #t,p,v,o -> t,p,o,v elif int(direction) == 0 and int(model_id) in (4,6): data = data[:-2] + [data[-1]] output = template.format (direction, model_id, " with open(filepath, w ) as fh: fh.write(output) fh.close() ".join(map(str, data)) self.written.add((filename)) #conparin written pub.sendmessage( add_txt, (filepath, self.case_id)) El atributo path_temp está definido en el constructor de la clase API y se trata de una ruta a un subdirectorio en la carpeta temporal, abstraída del sistema operativo subyacente mediante el módulo tempfile El receptor de este mensaje es IOPanel que maneja el mensaje con el método OnAddItem(). def OnAddItem(self, msg): filepath, case_id = msg.data head,filename = os.path.split(filepath) if case_id not in self.cases.keys(): #if case is unknown, create it node = self.tree.appenditem(self.root, "Case %d" % case_id) self.cases[case_id] = node else: node = self.cases[case_id] with open( filepath, r ) as fh: content = fh.read() 8.1. Utilización de Publish/Suscribe en GPEC 63

72 item = self.tree.appenditem(node, filename) self.tree.setpydata(item, content) #self.tree.expand(node) self.tree.selectitem(item) #TODO refresh text_ctrl? Tabla de incidencias de mensajes Se lista aquí una tabla con diferentes tipos de mensajes, su utilidad, emisor/es y destinatario/s: all active page Trae a primer plano una pestaña de los gráficos PlotsTreePanel Tópico Descripción Emisor/es Receptor/es log Mensaje al usuario varios LogMessagesPanel add_txt Expone archivo de backend ApiManager.* IOPanel clone Crear un nuevo caso a partir del CasePanel.Clone TabbedCases case actual make.* Invoca el cálculo y genera el gráfico CasePanel.OnMakePlots SuitePlotsPanel refresh Refresca la interfaz de usuario varios MainFrame SuitePlotsPanel Para un listado completo puede analizar el código fuente ejecutando grep -r "pub.sendmessage" sobre el directorio de código fuente raiz de GPEC Invocación de ejecutables del backend La comunicación frontend-backend se describe en el diagrama de secuencia de la figura 8.4. Allí se resalta el ciclo de vida del objeto ApiManager donde está implementada la lógica de tratamiento de la interfaz de comunicación. El caso particular representado es la obtención de datos el cálculo del diagrama de fase global (que se obtiene mediante el ejecutable GPEC.exe) satisfaciendo las precondiciones de ejecución (por ejemplo, que exista el archivo de entrada GPECIN.DAT, que exista permiso de ejecución, que exista permiso de escritura en la carpeta destino). En caso de error por algún motivo (conocido o no), se remite un mensaje de log y se cancela la ejecución La dependencia con Wine El backend de GPEC, codificado en Fortran por Cismondi, ha sido compilado mediante Microsoft Fortran y se compone de un conjunto de ejecutables Windows (.exe). Si bien 2 El comando grep -r busca de manera recursiva una cadena (o una expresión regular) sobre sobre los archivos de un directorio 64 Capítulo 8. Implementación

73 Figura 8.4: Secuencia de la comunicación frontend-backend 8.2. Invocación de ejecutables del backend 65

74 el código es Fortran estándar y compatible con compiladores libres (como GNU Fortran ( ) pudiéndose generar ejecutables específicos para sistemas Linux, existe una dependencia con la librería propietaria IMSL Numerical Libraries, que brinda un conjunto de rutinas matemáticas (álgebra lineal, cálculo matricial, etc.) que se utilizan en la implementación de los algoritmos. Esta dependencia impide, por el momento, generar una versión completamente nativa para plataformas Linux (y, a priori, la posibilidad de liberar completamente el código). Para permitir la ejecución sobre Windows es necesario la utilización de Wine, un software que ofrece una capa de compatibilidad para aplicaciones DOS, Windows 3.x, y win32, proveyendo una implementación alternativa (y parcial) del núcleo NT. A través de Wine, los ejecutables Fortran de GPEC funcionan perfectamente. La función que invoca estos ejecutables verifica el sistema operativo en que se está corriendo la aplicación y en caso de no ser Windows, invoca a Wine: args = [] if sys.platform!= win32 : #On any non-windows system, we run binaries through wine args.append( wine ) args.append( os.path.join(path_bin, bin +.exe )) Nota: Esta dependencia es salvable utilizando la versión para Linux de la biblioteca IMSL pero que únicamente es compilable mediante Intel Fortran Composer ( con lo cual se duplica la dependencia de software privativo. 8.3 Memorización de resultados costosos Como se observa la figura 8.4, el proceso de comunicación y obtención de los datos desde el backend no es trivial. Más aún, considerando que, dada la arquitectura heredada interviene de manera insalvable la escritura y lectura a disco, el proceso también es costoso 3 a nivel computacional. Tomando de ventaja de la condición determinística de la operación (para los mismos parámetros de entrada, es decir el caso, se obtiene siempre el mismo resultado) se puede calcular una vez, guardar el resultado en memoria, y devolverlo sin recalcular cada vez que la operación con exáctamente los mismos parámetros es solicitada de nuevo. A este proceso se lo denomina caché de datos. Esto tiene validez, además, dado que la probabilidad de que los parámetros sean los mismos es alta. Por ejemplo, en el siguiente caso de uso: El usuario necesita generar una isopleta para determinada composición (o cualquier otra curva no global). Para esto, GPEC requiere haber calculado el diagrama 3 El módulo cstringio provee un tipo de buffer de cadenas de caractéres con la misma interfaz que un archivo de texto normal. Las operaciones con la información en memoria son altamente eficientes. 66 Capítulo 8. Implementación

75 global previamente (los ejecutables requieren GPECOUT.DAT como precondición de entrada), de modo que este cálculo se realiza sin mostrar los diagramas. Si posteriormente el usuario decide que necesita los diagramas globales, simplemente se grafican el respaldo en memoria sin realizar la el cálculo mediante backend. Por último, dado el manejo referencial de memoria que hace Python, la permanencia del array en memoria no está duplicada respecto al que se utiliza para graficar Patrón decorator Una forma habitual de implementar el mecanismo de caché es a través del patrón Decorator, que en términos simplificados realiza una transformación dinámica de una función o método, agregándole una funcionalidad que no tiene por sí misma, o más en general, alterando de alguna manera el resultado devuelto. Figura 8.5: Diagrama de clases del patrón Decorator Expresándolo en términos matemáticos, se trata de una composición de funciones: X Y Z x f(x) g(f(x)) Desde la versión 2.4, Python tiene una nomenclatura facilitada para la escritura de decoradores. Una estructura genérica para la definición de una función decoradora, que se compone de un wrapper de dos funciones anidadas 4, es la siguiente: def mydecorator(function): def _mydecorator(*args, **kw): 4 Mientras que las velocidades de CPU y las capacidades de memporia se han incrementado enormemente, otros aspectos concernientes a la performance como las velocidades de acceso a disco se han quedado en el tiempo. Como consecuencia, estas latencias son cada vez más seguido un cuello de botella en la performance global del sistema. s_law#importance_of_non-cpu_bottlenecks 8.3. Memorización de resultados costosos 67

76 # hacer las tareas de decoración # antes de llamar a la funcion decorada res = function(*args, **kw) # hacer otras cosas antes de devolver el resultado return res # se devuelve la subfunción return _mydecorator Cuando se tiene una función cualquiera que se quiere decorar, simplemente se utiliza la justo antes de la función en cuestion. Por def mifuncion(): pass Al llamar a mifuncion() se obtiene en realidad mydecorator(mifuncion()). La ventaja sintáctica de Python es que permite hacer esta llamada de manera implícita Algoritmo de caché de datos El algoritmo utilizado para la implementación del sistema de caché se llama memoize 5 y es descripto en detalle en [ZIADE2008], cuya versión, parcialmente simplificada, se ha utilizado. En este caso, la funcionalidad que aporta el decorador a la función que se decora es la siguiente: 1. Se obtienen todos los parámetros de la función, se serializan en una cadena de texto, y con esa cadena se genera un hash, es decir, una clave de caracteres unívoca para ese conjunto de datos. Esta codificacación es un proceso determinístico. 2. Se evalua si ese hash existe como clave en el diccionario que almacena resultados memorizados. 3. Dependiendo del resultado anterior a) Si la clave existe en el diccionario (o sea, el resultado para esos parámetros se calculó previamente) se devuelve el valor de la entrada sin llamar a la función decorada. b) Si la clave no existe (lo que implica que es la primera vez que se llama la función con los parámetros dados) se invoca a la función decorada y con el resultado se agrega una entrada en el diccionario hash:resultado. Además, se devuelve el resultado Código fuente def compute_key(function, args, kw): key = pickle.dumps((function.func_name, args, kw)) return hashlib.sha1(key).hexdigest() 5 También llamado memoization. Ver 68 Capítulo 8. Implementación

77 def memoize(): def _memoize(function): def memoize(*args, **kw): key = compute_key(function, args, kw) if key not in cache.keys(): #we have nt it already? result = function(*args, **kw) cache[key] = result #store a new one else: print found in cache #TODO may be it s a better idea #cache the whole arrays. return cache[key] return memoize return _memoize 8.4 Algoritmo de análisis sintáctico Como ya se ha hecho mención, la comunicación con los ejecutables del backend se realiza mediante archivos de texto. Los archivos de salida, en particular, contienen (en arreglos de columnas) los vectores de datos para cada variable de una curva. Según [Vera1994], la tarea de delimitar la información de un texto se denomina en la lingüistica Análisis sintáctico y es también un área de la informática de utilidad en la implementación de diversos software (como ejemplo notorio, los compiladores). Este trabajo implementa un analizador sintáctico (denominado parser, en ingles) para extraer los vectores numéricos (ordenados como un arreglo bidimensionales) de los archivos de salida, obteniendo así la información necesaria para graficar cada curva. Nota: Para una comprensión cabal del algoritmo, es necesario estár familiarizado con la definición de la interfaz. Una descripción exhaustiva se expone en Especificación de la interfaz de comunicación Descripción El algoritmo se basa en identificar tokens (marcas) que declaran el inicio y final de información válida para un diagrama, determinando así la porción de texto (números flotantes en formato texto) que debe extraerse. Este texto se convierte a un objeto array de numpy. Las marcas de inicio son cadena de tres letras mayúsculas (VAP, CRI, LLV, etc.) y un renglón vacío marca el final del bloque de información como se muestra en la figura 8.6. Una estructura de datos basadas en asociaciones clave-valor (diccionarios), define los tipos posibles de curvas y las columnas significativas que se deben extraer para cada una. Iterando sobre todas las líneas del archivo se obtiene un nuevo diccionario cuya clave es una tupla de la forma (inicio, fin) y el tipo de curva como valor Algoritmo de análisis sintáctico 69

78 Figura 8.6: Topología de la información extractada Con esta información simplemente se recorta el archivo de texto completo del cual se realiza una copia residente en memoria 6 para importarlo y convertirlo a arreglos de números flotantes de doble precisión mediante la función numpy.loadtxt() que acepta como parámetro opcional la cantidad de columnas significativas que deben interpretarse Código fuente def output2array(self, filepath, curve_types): """Parses gpecout.dat, PXYOUT.DAT TXYOUT.DAT or ISOPOUT.DAT Detects numeric blocks and create arrays with them""" tokens = {} #{(begin,end): type,...} begin = 0 end = 0 with open(filepath, r ) as fh: number_of_lines = len(fh.readlines()) fh.seek(0) #give skip from header and skip from footer 6 Cuando se necesita pasar parámetros específicos al decorador (además de los que se pasan en la llamada a la función decorada) se necesita una forma sutilmente más compleja, donde la declaración del decorador tiene un subnivel más de wrappering, o sea, 3 funciones anidadas. 7 Una referencia completa de esta función se encuentra en 70 Capítulo 8. Implementación

79 for line_number, line in enumerate(fh): if begin <= end: #looking for a curve TOKEN : VAP, CRI etc... if line.strip() in curve_types: begin = line_number + 1 curve_type = line.strip() elif not line.strip() or line_number==number_of_lines-1: #looking for a blank line which determines the end of #arrays block. end = line_number tokens[(begin, end)] = curve_type arrays_out = {} #Format: {type: [array1,array2,...],...} for (begin, end), curve_type in sorted(tokens.items()): fh.seek(0) temp_w = cstringio.stringio() #a memory file to write #write lines just of the block between (begin,end) for l,line in enumerate(fh): if begin <= l < end and \ len(get_numbers(line))>0: #a way to check the special case of col #headers after mark temp_w.write( line.replace( *, ) ) #a copy to read temp_r = cstringio.stringio(temp_w.getvalue()) #retrieve significative columns from a dictionary. #(begin,end)=>type=>num_cols signif_cols= range(curve_types[tokens[(begin, end)]]) curve_array = np.loadtxt(temp_r, usecols=signif_cols) temp_w.close() temp_r.close() #if it s a new type on the dict, create it. if curve_type not in arrays_out.keys(): #TODO should it be a ndarray? arrays_out[curve_type] = [] arrays_out[curve_type].append(curve_array) fh.close() 8.4. Algoritmo de análisis sintáctico 71

80 return arrays_out 8.5 Interfaz Gráfica de Usuario (GUI) La interfaz gráfica fue objeto de estudio. La pantalla principal está dividida en cuatro paneles (subventanas) que permiten la entrada de datos (Cases), la visualización de gráficos (Plots), informaciones útiles como mensajes de usuario y los archivos de entrada/salida sin procesar (Info) y el navegador de vistas en forma de árbol (Manager). Esta división se definió para dar soporte al requerimiento de múltiples casos y gráficos permitiendo navegar fácilmente entre los distintos resultados, de manera de facilitar la comparación sin complejizar la interfaz Contenedores y sizers En la introducción general a WxPython vista en Tecnologías adoptadas se hizo referencia a la clase wx.panel describiéndola como un contenedor de otros objetos gráficos. Tradicionalmente, uno de los problemas más complicados en la programación de GUI es el manejo de la disposición física de los componentes en el espacio disponible (layout). En los comienzos, la solución fue el posicionamiento absoluto donde el programador explicitaba el tamaño y la posición exácta del widget en la pantalla 8. Esta estrategia acarrea una batería de problemas ya que sólo funciona correctamente si se tiene control total sobre el espacio disponible, es decir, controlando la resolución de pantalla del equipo del cliente, el tamaño de tipografía estándar que ha elegido, etc. pero se vuelve inmanejable cuando el layout es dinámico, es decir, que cambia en función de alguna acción del usuario. Para solucionar este problema wxpython, y en general, todos los frameworks para la construcción de GUIs modernas, utilizan el concepto de sizers, que son algoritmos automáticos que distribuyen los elementos de la interfaz de una menera predeterminada. Un sizer en wxpython es un objeto invisible que no es un contenedor (como son, por ejemplo, Panel, Frame o una página de un elemento wx.notebook) sino que simplemente indican cómo se ubican originalmente y cómo se comportan visualmente los elementos ante un evento que afecte la apariencia de la aplicación. Todo los sizers son instancias de una subclase de la clase abstracta wx.sizer Ver También: Para una explicación exhaustiva sobre el tema, vea el capitulo 11 de wxpython in Action, [NR-RD2006] Por ejemplo, sizer permite dividir el espacio, cualquier este sea, en porciones proporcionales de filas o columnas, y ubicar allí elementos (como botones o campos de texto), definiendo atributos como su alineación horizontal o vertical, el tamaño (proporcional al espacio, fijo, 8 Una aproximación de este tipo, relativa al tamaño de la ventana, utiliza la versión anterior de GPEC. 72 Capítulo 8. Implementación

81 con límite máximo, etc). Asímismo, un sizer puede contener a otros de manera anidada, definiendo una cuadrícula con espacios para ubicar los widgets controladores 9. Figura 8.7: Diseño con sizers de una ventana de la aplicación mediante la utilidad wxglade ( El hecho de que un sizer no sea un contenedor indica que parent de cualquier elemento aún debe serlo. Es decir, un elemento cualquier (por ejemplo, un botón) está en incrustado en un contenedor (por ejemplo, un panel) pero ubicado según indica un sizer que está asociado al mismo contenedor. Uso en la aplicación En GPEC, toda la distribución de componentes de la interfaz está dispuesta a través de sizers. Como ejemplo, en la figura 8.8 se muestra la parte superior de un panel para la definición de un caso donde consta el uso anidado de sizers de distinta clase. Se observa que existe un panel contenedor principal, CasePanel cuyo sizer principal es por filas (wx.boxsizer(wx.vertical)) al que se le suman 2 instancias del panel, VarsAndParamsPanel (sólo se muestra uno, pero corresponde 1 para cada compuesto del sistema binario) cuyo layout se basa en un wx.gridbagsizer de 6 filas por 5 columnas. 9 Para layout de estilo cuadrícula se utiliza una de las implementaciones de la clase abstracta wx.sizer es GridSizer 8.5. Interfaz Gráfica de Usuario (GUI) 73

82 Figura 8.8: Distribución mediante sizers de componentes. El contenido del GridBagSizer es dinámico, cambiando su contenido en función de un evento de cambio de opción (evento wx.evt_choice) del menú de modelos. La porción de código relevante se describe a continuación: class CasePanel(scrolled.ScrolledPanel): def init (self, parent, id): scrolled.scrolledpanel. init (self, parent, id, style = wx.tab_traversal wx.clip_children wx.full_repaint_on_resize) self.box = wx.boxsizer(wx.vertical) # <- sizer principal self.model_choice = wx.choice(self, -1, choices = sorted(self.model_options.keys())) first_row_sizer = wx.boxsizer(wx.horizontal) # <- sizer secundario self.load_button = wx.lib.buttons.genbitmaptextbutton(self, -1, wx.bitmap(os.path.join(path_icons,"compose.png")), "Define system") first_row_sizer.add(self.load_button, 0, flag=wx.all wx.align_left wx.expand, border=5) first_row_sizer.add((10, 20), 0, wx.expand) first_row_sizer.add(wx.statictext(self, -1, "Model:")) first_row_sizer.add(self.model_choice) # <- menu 74 Capítulo 8. Implementación

83 self.box.add( first_row_sizer, 0, flag= wx.top wx.left wx.fixed_minsize wx.align_left, border = 5) self.panels = (VarsAndParamPanel(self,-1), VarsAndParamPanel(self,-1)) self.box.add(self.panels[0], 0, wx.expand ) # <-- subpanel 1 self.box.add(self.panels[1], 0, wx.expand ) class VarsAndParamPanel(wx.Panel): """a panel with 2 columns of inputs. First colums input EOS variables. The second one are the inputs to model parameters (change depending the model selected). This parameter are related and is possible to calcule a group of values defining the other one. """ def init (self, parent, id, model_id=1, setup_data=none): """setup_data: (id, name, tc, pc, vc, om)""" wx.panel. init (self, parent, id, style = wx.tab_traversal wx.clip_children wx.full_repaint_on_resize ) gbs = self.gbs = ui.widgets.gridbagsizerenh(6, 5) La aplicación de sizer repercute en la homogeneidad y determinismo de la ubicación de los componentes, lo que permite aplicar las características de usabilidad mostradas en la figura 8.9, cuya base conceptual se menciona en en Preceptos adoptados en el diseño de UI El uso de la Advanced User Interface La ventana principal de la aplicación MainFrame definida en aui.py es una de subclase de la clase wx.frame pero el manejo de la distribución de sus componentes se basa en una librería especial denominado Advanced User Interface, que reside en wx.aui. Esta librería está construida sobre la pila de componentes de wxpython y permite implementar interfaces avanzadas a través del control de subventanas automatizado de eventos como maximizar (ocupar toda la ventana principal), cerrar (no se muestra en la ventana principal) o restaurar (vuelve a la posición original) entre otras. Comparando con los resultados que se obtienen, utilizar wx.aui tiende a ser trivial. Básicamente consiste en dos objetos: Un manejador, wx.aui.auimanager, que se encarga de toda la lógica de control, 8.5. Interfaz Gráfica de Usuario (GUI) 75

84 Figura 8.9: Características de usabilidad implementadas en el panel 76 Capítulo 8. Implementación

85 mantener el estado de las ventanas y lanzar los métodos automáticos cuando ocurren eventos sobre la interfaz. Al menos una instancia wx.aui.auipaneinfo que define una subventana a la que se le asocia el contenido a mostrar, en general, un panel principal de wx. Figura 8.10: La interfaz avanzada de GPEC visualizando 2 de los 4 paneles por defecto. Vale comentar que luego de cualquier cambio, yendo a :menuselection: View > Restore default view se reestablece la estructura original. Un extracto relevante de MainFrame es el siguiente: class MainFrame(wx.Frame): def init (self, parent, id=-1, pos=wx.defaultposition, title= GPEC, size=(800,600), style=wx.default_frame_style wx.maximize ): wx.frame. init (self, parent, id, title, pos, size, style=style) self._mgr = wx.aui.auimanager(self) #<- manejador self.cases_panel = TabbedCases(self, -1) self.cases_auipane = wx.aui.auipaneinfo().name("cases").\ Caption(u"Cases").Left().MinSize(the_size).MaxSize(the_size).\ Layer(1).Position(2).CloseButton(True).MinimizeButton(True) 8.5. Interfaz Gráfica de Usuario (GUI) 77

86 self._mgr.addpane(self.cases_panel, self.cases_auipane ) self._mgr.update() self.maximize() En el código se observa la siguiente secuencia 1. Se instancia el manejador de wx.aui 2. Se instancia el panel de contenido, en este caso TabbedCases 3. Se instancia la subventana wx.aui.auipaneinfo con todas sus propiedades (ubicación, título, tamaño mínimo, etc. ) 4. Se define que el contenido de la subventana será el panel antes generado y se lo agrega al manejador. 5. Se actuliza el layout Una observación en el paso 3 es que para definir los atributos del panel se utiliza una técnica denominada encadenado de métodos (Method chaining) 10 donde la ejecución de un método de un objeto devuelve el objeto en sí, posibilitando encadenar la ejecución de otro método. La interfaz por defecto de GPEC se compone de 4 instancias de AuiPaneInfo cuyo contenido se lista en la siguiente tabla: Título Panel de contenido Descripción del contenido Cases TabbedCases Definición de casos Plots SuitePlotsPanel Pestañas de gráficos Manager PlotsTreePanel Árbol de manejo gráficos Info InfoPanel Panel de informaciones diversas La gestión avanzada de pestañas En el área de las interfaces gráficas de usuario, la navegación por pestañas (TABBED DOCU- MENT INTERFACE (TDI)) se refiere a la posibilidad de que varios paneles con información estén contenidos dentro de una sola ventana o panel principal, usando pestañas para alternar entre ellos. Es típico su uso en los navegadores web modernos, como Mozilla Firefox. GPEC hace uso extendido de esta arquitectura, en el soporte de múltiples casos, múltiples gráficos, o varios paneles de información. En wxpython existen múltiples implementaciones de controladores de pestañas y se ha hecho uso de AuiNotebook, que forma parte de las Advanced Generic Widgets ( (AGW) desarrolladas por el programador italiano Andrea Gavana. Toda la librería AGW forma parte del paquete estándar de wx y reside en wx.lib.agw.aui. La gran ventaja de AuiNotebook es que funciona como complemento de la intefaz avanzada de Python wx.aui permitiendo el control de eventos como drag & drop de pestañas entre 10 Esta técnica es ampliamente utilizada en frameworks Javascript como jquery < dada que su alta expresividad produce código más compacto, característica muy relevante en el ambiente web. Ver 78 Capítulo 8. Implementación

87 distintos paneles, o la visualización simultánea de múltiples pestañas, como muestra la figura Figura 8.11: El control AuiNotebook de los gráficos mostrando 2 diagramas en simultáneo 8.6 Integración Matplotlib-WxPython La biblioteca de graficación Matplotlib incluye soporte para los toolkits para creación de interfaces gráficas 11 más utilizados, que permite incrustar (y hacer interactuar) figuras dentro de aplicaciones gráficas. La integración entre Matplotlib y WxPython se logra a través de un canvas (lienzo) donde Matplotlib es capaz de dibujar y, se comporta, a la vez como un panel de wxpython. El objeto en cuestion es FigureCanvasWxAgg. Se muestra su ascendencia de clases en el diagrama de la figura La clase FigureCanvasAgg es en realidad la encargada de dibujar los gráficos a través de los algoritmos Anti-Grain Geometry ( que aplican técnicas como Anti-Aliasing 12 o Precisión de subpixel para mejorar la definición de la líneas trazadas. Por su parte, la otra clase padre FigureCanvasWx es la que realiza la integración concreta con wxpython, heredando de un contenedor tipo wx.panel. 11 El soporte incluye GTK, QT4, TKinter, PDF y wxpython 12 Es un proceso utilizado para suavizar los bordes desparejos de los gráficos. Ver Integración Matplotlib-WxPython 79

88 Figura 8.12: Diagrama de clases para FigureCanvasWxAgg donde se evidencia la herencia múltiple que permite el comportamiento dual del objeto. La figura 8.13 muestra la secuencia de eventos para la graficación de un diagrama. Puede ver la sección Tipos de gráficos para estructura de clases implementada para dar soporte a los distintos tipos de gráficos Barra de herramientas de gráficos Matplotlib provee una integración avanzada con Wx proveyendo un barra de herramientas asociada al canvas integrable en la interfaz de usuario. Esta barra de herramientas provee zoom, definición de margenes, desplazamiento, exportación y navegación histórica 13 La exportación permite guardar el estado actual del diagrama, incluyendo tamaño, curvas visibles, etiquetas, grilla, etc. en distintos formatos escalables como PDF, SVG, EPS, o de mapa de bits como PNG entre muchos otros. La integración es muy sencilla y se logra mediante la clase NavigationToolbar2Wx que se encuentra en el módulo general de integración con wx matplotlib.backends.backend_wxagg. El código se resume a la instanciación, indicando el objeto canvas al que se asocian las herramientas y a la ubicación en un sizer: self.toolbar = NavigationToolbar(self.plot.canvas) #the canvas from plot self.vbox = wx.boxsizer(wx.vertical) self.vbox.add(self.plot.canvas, 1, wx.left wx.top wx.grow) self.vbox.add(self.toolbar, 0, wx.expand) 13 Permite aumentar la resolución contemplando precisiones de fracciones de un pixel. Ver 80 Capítulo 8. Implementación

89 Figura 8.13: Diagrama de secuencia para la graficación de un diagrama al nivel subyacente (via matplotlib) 8.6. Integración Matplotlib-WxPython 81

90 Figura 8.14: Barra de herramientas provista por Matplotlib integrable en wxpython Integración de menús contextuales Otro aspecto de la integración, un poco más complejo, son los menús contextuales que permiten al usuario manipular la figura de diferentes manera, u ocultar y volver a mostrar las diferentes curvas. Figura 8.15: Menú contextual sobre una figura que se activa ante un evento con el botón derecho. La complejidad está dada por el paso de eventos entre wxpython y Matplotlib. El primero, en la clase PlotPanel define y construye el menú contextual pero asocia las acciones a métodos de BasePlot : def onmousebuttonclick(self, event): if event.button == 3: if not hasattr(self, menu ): self.menu = wx.menu() for curve in self.plot.curves: self.menu.append(curve[ wx_id ], curve[ name ], kind=wx.item self.bind(wx.evt_menu, self.plot.ontogglecurve, id=curve[ wx self.menu.check(curve[ wx_id ], True) self.menu.appendseparator() 82 Capítulo 8. Implementación

91 for prop, wx_id in self.plot.properties_normal.iteritems(): self.menu.append(wx_id, prop) self.bind(wx.evt_menu, self.plot.onsetupproperty, id=wx_id) for prop, wx_id in self.plot.properties_check.iteritems(): self.menu.append(wx_id, prop, kind=wx.item_check) self.bind(wx.evt_menu, self.plot.ontoggleproperty, id=wx_id) # Popup the menu. If an item is selected then its handler # will be called before PopupMenu returns. wx.callafter(self.popupmenu, self.menu) Los métodos OnToggleCurve y OnSetupProperty son los que realizan las tareas solicitadas, como cambiar a escala logarítmica, ocultar o mostrar una curva, etc. def OnToggleCurve(self, event): wx_id = event.getid() curve = [curve for curve in self.curves if curve[ wx_id ] == wx_id][0] curve[ visible ] = not curve[ visible ] for line in curve[ lines2d ]: try: line.set_visible(curve[ visible ]) except AttributeError: for line_ in line: line_.set_visible(curve[ visible ]) self.canvas.draw() def OnSetupProperty(self, event): wx_id = event.getid() prop = dict([[v,k] for k,v in self.properties_normal.items()])[wx_id] #i if prop == Set perspective... : dlg = wx.textentrydialog(self.parent, u Azimuthal angle, u Set Perp defaultvalue=str(self.axes.azim) ) r = dlg.showmodal() if r == wx.id_cancel: return elif r == wx.id_ok: azim = float(dlg.getvalue()) dlg = wx.textentrydialog(self.parent, u Elevation angle, u Set Perp defaultvalue=str(self.axes.elev) ) r = dlg.showmodal() if r == wx.id_cancel: return elif r == wx.id_ok: elev = float(dlg.getvalue()) 8.6. Integración Matplotlib-WxPython 83

92 self.axes.view_init(elev, azim) elif prop == Set plot title... : dlg = wx.textentrydialog(self.parent, u Plot title, u Set plot titl defaultvalue=self.axes.get_title() ) r = dlg.showmodal() if r == wx.id_cancel: return self.title = dlg.getvalue() self.axes.set_title(self.title) self.canvas.draw() 8.7 Implementación de base de datos El almacenamiento y gestión de la información necesaria de la base de datos definida en Capa de base de datos como entrada para GPEC se realiza a través de un sistema de gestión de base de datos relacional. Se utilizó el software sqlite ( (versión 3) que respeta el estándar SQL (Structured Query Language) mediante una librería monolítica, portable, eficiente y compacta que es integramente soportada por Python 14. La ventaja principal es que una base de datos de sqlite está autocontenida en un archivo binario que puede ser distribuido en conjunto con el software, sin requerir inicialización o un servidor de base de datos local o remoto. En este sentido es equivalente a una base de datos de Microsoft Access, aunque superadora en las prestaciones y apego a un lenguaje estándar para base de datos Definición de la estructura de tablas CREATE TABLE "compounds" ("id" INTEGER,"id_category" INTERGER PRIMARY KEY AUTOINCREMENT NOT NULL, "name" VARCHAR, "formula" VARCHAR, "formula_extended" VARCHAR, "tc" FLOAT, "pc" FLOAT, "vc" FLOAT, "acentric_factor" FLOAT, "vc_rat" FLOAT DEFAULT (1.168) ); CREATE TABLE "categories" ("id_category" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, 14 Cada vez que se modifica la visualización de la figura (un acercamiento, un desplazamiento, etc) se marca un hito en la historia, al que se puede regresar mediante las flechas de navegación. 84 Capítulo 8. Implementación

93 "name" VARCHAR, "editable" BOOL NOT NULL DEFAULT True ); INSERT INTO "categories" VALUES(1, DIPPR, False ); INSERT INTO "categories" VALUES(2, User defined, True ); Importación de datos Los datos fueron obtenidos de la versión preexistente (Visual GPEC) cuya base de datos, como se ha comentado en la sección Problemas detectados, está en formato MS Jet. La obtención de la información contenida para su conversión a Sqlite se realizó utilizando un proceso de 2 pasos 1. Con la herramienta gmdb2, parte de la suite de utilidades libres para la manipulación de archivos Jet/Access MDB tools ( se exportó la tabla de parámetros de compuestos a un formato CSV (Comma Separeted Values) donde cada registro constituye una línea de texto plano y los valores están separados por un caracter (en particular se utilizó el punto y coma ;). El formato CSV, es un mecanismo canónico para la exportación e importación de datos, por su trivial facilidad de manipulación. 2. Denida la estructura de la base de datos de destino (Sqlite), se utilizó la herramienta sqlite-manager ( para importar las columnas pertinentes del archivo CSV a la tabla de destino Figura 8.16: Procesos de conversión de la base de datos a sqlite 8.7. Implementación de base de datos 85

94 86 Capítulo 8. Implementación

95 CAPÍTULO 9 Verificación Este capítulo describe el trabajo realizado para la verificación del correcto funcionamiento de la aplicación. En particular se ha testeado la librería de comunicación, es decir la clase ApiManager del módulo apimanager 9.1 Conceptos de pruebas unitarias Unit Testing o pruebas unitarias son test en donde cada parte (módulo, clase, función) del programa es testeado por separado (de alló lo de unitario). Idealmente, se pone a prueba todas las funciones y todos los casos posibles para cada una de ellas. Según [Zulberti2010], el unit testing tiene varias ventajas: Permite probar que el programa funciona correctamente. En Python, los tests también permiten identificar variables que no existen o tipos esperados en las funciones (en otros lenguajes eso se hace en tiempo de compilación). Permite identificar en caso de que se haga una modificación que siga funcionando correctamente todas las parte del programa. Tanto las cosas modificadas como las cosas que dependen de las modificadas. Esto es muy importante cuando se trabaja en grupo (con algún sistema de control de versiones) ya que permite asegurar que el código que usa el resto del grupo y que uno modifico sigue funcionando. Permiten documentar el código. Esto no es en forma directa, pero como los tests indican como es que se tiene que comportar el programa, viendo los tests uno puede fijarse cuál es el resultado esperado para ciertas entradas del programa. Esto no excluye que se tenga que escribir la documentación del código. Es muy importante que un test cumpla las siguientes reglas: Tiene que poder correr sin interacción humana. Es decir, los tests no deben pedir que el usuario ingrese valores en ningún caso. Para esto, es en el test mismo cuando se pasan los valores a la función. 87

96 Tienen que poder verificar el resultado de la ejecución sin interacción humana. De nuevo, para saber si esta bien o no el resultado no tiene que pedirle al usuario que verifique el resultado. Para esto, se tiene que saber de antemano el resultado del test con los valores que se pasaron. Un test tiene que ser independiente del otro. Es decir, el resultado de un test no debería depender del resultado anterior Unit testing en Python Python provee en su librería estándar un completo framework para realizar pruebas unitarias. Se trata de unittest 1 cuya arquitectura y api está basada en el framework Junit ( para el lenguaje Java. Nota: El testing en todas sus formas tiene amplio interés en la comunidad de usuarios de Python y además del framework estándar existen gran cantidad de herramientas para facilitar distintos aspectos de la. Ver The Python Testing Tools Taxonomy ( En particular, se utilizó el framework unittest2 que forma parte estándar de la versión 2.7 de Python, y existe como backport para las versiones 2.4 a unittest provee muchas clases y funciones utilitarias para realizar pruebas automatizadas de la cuales se utilizó la estructura más tradicional basada en la clase TestCase. Todos los métodos de una subclase de TestCase cuyo prefijo es test_ son ejecutados como una prueba, cuya estructura general es realizar una acción y comparar el resultado producido con el resultado esperado. Dependiendo de la condición analizada, que se realiza mediante alguno o varios de los métodos que comienzan con assert (assertequal, assertnotequal, assertgreatequal, etc,) todos heredados de la clase TestCase, la prueba es exitosa o falla. Existen además dos métodos especiales setup() () y teardown() que se ejecutan automáticamente (antes y despues, respectivamente) de ejecutar cada test. 9.2 Pruebas realizadas Como se dijo, varias pruebas fueron realizadas sobre el controlador de la interfaz de comunicación. Por supuesto, en un sistema tan complejo como el desarrollado la cobertura de pruebas dista de ser total, pero se ha verificado el módulo más complejo y por ende propenso a introducir errores. Se listan a continuación la batería de test realizados. 1 La documentación completa de la versión utilizada se encuentra en 2 El paquete backported se encuentra en la dirección y se puede instalar fácilmente mediante el utilitario easy_install. 88 Capítulo 9. Verificación

97 class test_apimanager.testapimanager(methodname= runtest ) setup() inicializador de cada test test_gpecout_1() Prueba que hay 2 curvas de vapor y al menos una crítica en los arrays de datos de numpy test_read_conpaout_1() Prueba que para todos los modelos, la primer fila de resultados tiene 4 parámetros y la segunda 3 excepto para RK-PR que son 4 test_write_conparin_1() Dirección 0 para modelos de cálculo 1 2 o 3. Prueba que se invierte el orden de los últimos dos parámetros. test_write_conparin_2() Prueba que la primer linea es [direction, model_id] test_write_conparin_3() Prueba que no se incluye el parámetro Vc test_write_gpecin() Prueba que se satisface la estructura de GPECIN.DAT Ejemplos de código de las pruebas El código de implementación de cada una de estas pruebas es muy descriptivo pero por una cuestión de extensión, se muestran sólo algunos de ellos. Para el estudio completo ver el módulo test_apimanager.py Ejemplo 1 def test_write_conparin_1(self): """ Dirección 0 para modelos de cálculo 1 2 o 3. Prueba que se invierte el orden de los últimos dos parámetros. """ direction = 0 model_id = random.choice([ 1, 2, 3 ]) t, p, v, o = data = [str(random.random()) for x in range(4)] self.api.write_conparin(direction, model_id, data) output = self.file2list( CONPARIN.DAT ) self.assertequal(output[1], [t, p, o, v]) 9.2. Pruebas realizadas 89

98 Ejemplo 2 def test_read_conpaout_1(self): """ Prueba que para todos los modelos, la primer fila de resultados tiene 4 parámetros y la segunda 3 excepto para RK-PR que son 4 """ direction = 0 data = [ 469.7, 33.7, 0.313, ] # n-pentane for model_id in settings.eos.values(): output = self.api.conparin2conparout(direction, model_id, data) self.assertequal(len(output[0]), 4) if model_id == 3: self.assertequal(len(output[1]), 4) else: self.assertequal(len(output[1]), 3) Ejemplo 3 def test_gpecout_1(self): """ Prueba que hay 2 curvas de vapor y al menos una crítica en los arrays de datos de numpy """ model = 1 #random.choice([1,2,4,6]) data1 = [190.56, 45.99, , ] #methane data2 = [514, 61.37, , ] #ethanol data1, param1 = self.api.conparin2conparout(0, model, data1) data2, param2 = self.api.conparin2conparout(0, model, data2) comp1 = (u METHANE, data1, param1) comp2 = (u ETHANOL, data2, param2) data = self.api.gpecin2gpecout(model, comp1, comp2) self.assertequal(len(data[ VAP ]), 2) self.assertgreaterequal(len(data[ CRI ]), 1) Ejecución y validación Se muestra la ejecución automatizada de todas las pruebas y su resultado exitoso: tin@azulita:~/facu/pi/src$ python test_apimanager.py test_gpecout_1 ( main.testapimanager)... ok 90 Capítulo 9. Verificación

99 test_read_conpaout_1 ( main.testapimanager)... ok test_write_conparin_1 ( main.testapimanager)... ok test_write_conparin_2 ( main.testapimanager)... ok test_write_conparin_3 ( main.testapimanager)... ok test_write_gpecin ( main.testapimanager)... ok Ran 6 tests in 0.808s OK 9.3 Pruebas de usabilidad Para analizar la mejora respecto a la versión preexistente se realizaron pruebas con usuarios con el objetivo de observar el éxito en la tarea encomendada. La pruba se basó en métodos propuestos por el reconocido consultor Jakob Nielsen, en en [Nielsen2000] y [Nielsen2009]. Las condiciones experimentales de estas pruebas fueron: Cinco usuarios trabajando individualmente Se solicita la obtención de una suite de gráficos No se da ninguna otra intrucción ni ayuda oral o escrita sobre cómo lograr el resultado Si bien la muestra poblacional no fue representativa para una conclusión definitiva, los cinco usuarios lograron el objetivo en menos de 2 minutos, aun aquellos que no comprendieron, por ser ajenos a la disciplina, el significado de los diagramas obtenidos. Las tareas de manipulación de los diagramas como rotar (sobre diagramas 3D), hacer zoom, desplazar, etc. fueron bien interpretadas mediate los íconos de la barra de herramientas. Como experiencia adicional se menciona que en las clases prácticas realizadas en el marco de los laboratorios de la cátedra Termodinámica (Ingeniería Química, UNC), dictador por el Dr. Cismondi, la gran mayoría de los usuarios (superior al 75 % de un curso de 25 alumnos) lograron realizar los diagramas antes de que se impartieran las instrucciones para obtenerlos Análisis cuantitativo Se describen algunos aspectos cuantitativos que dan muestra de la reducción de componentes de control y acciones necesarias para realizar una tarea, comparando la versión actual con la anterior. Panel de definición de un caso Visual GPEC GPEC componentes simultáneos 19 componentes 3 grupos de opciones 2 menues de opciones Opciones secundarias visibles Opciones secundarias desplegables 100 % espacio pantalla 25 % espacio de pantalla 9.3. Pruebas de usabilidad 91

100 Definición un sistema de componentes arbitrarios Visual GPEC GPEC ventanas modales 1 ventana modales 7 clicks 4 clicks 15 cajas de texto 5 cajas de texto 92 Capítulo 9. Verificación

101 CAPÍTULO 10 Implantación 10.1 Empaquetado para sistemas Windows Como requisito, se especificó que GPEC debía ser capaz de ejecutarse en plataformas Windows y Linux. Para satisfacer esta condición la tecnología utilizada se eligió intrínsecamente multiplataforma, aunque el ambiente de desarrollo principal haya estado basado en Linux. Por supuesto, para realizar pruebas de compatibilidad y asegurar el funcionamiento en windows, se debió instalar un ambiente análogo con versiones para este sistema operativo. Sin embargo, la distribución del software para usuarios Windows no puede basarse en la reproducción de un ambiente de desarrollo, es decir, la instalación por separado del lenguaje Python (intérprete) y las diversas bibliotecas necesarias para la ejecución del software. Esto, en primer lugar, porque complica la utilización al usuario inexperto, y en segundo lugar porque resulta ineficiente en términos de tamaño teniendo en cuenta que sólo parte (algunos módulos) de las bibliotecas intrínsecas de Python y las bibliotecas de terceros son utilizadas en GPEC. Por poner un ejemplo, la biblioteca de graficación Matplotlib incluye soporte para la integración con otras bibliotecas para interfaces gráficas (como Qt, GTK, etc ) que no son utilizadas en GPEC al estar basada, como se ha especificado, en WxWidget Py2exe: separar sólo lo necesario Para realizar el estudio de cuáles son los módulos (y sus respectivas dependencias) unívocamente necesarios se utilizó el software py2exe ( py2exe es una extensión a las Python Distribution Utilities (distutils) que convierte scripts de Python en aplicaciones ejecutables en windows (.exe) sin requerir la instalación por separado del intérprete o bibliotecas. Partiendo de un ambiente de desarrollo Windows con todos los requerimientos satisfechos, py2exe realiza un árbol de dependencias y genera una carpeta incluyendo únicamente los módulos estrictamente necesarios, así como una copia de las librerías dinámicas (.dll) necesarias para la ejecución. Además, puede realizar la conversión del código python a bytecode (formato 93

102 binario más rápidamente interpretable por Python) y agregar una cierta compresión, de manera de optimizar el tamaño del paquete resultante. Figura 10.1: Salida final de la ejecución de py2exe enumerando las librerías dinámicas complementarias que son necesarias para la ejecución del programa. Todas estas son comunes en cualquier instalación por defecto de Windows. La configuración de py2exe se realiza a través de un módulo estándar de las Distutils denominado setup.py. Allí se especifican variables y directrices necesarias, como el nivel de compresión, cuál es el módulo principal (que será convertido en el.exe ), datos extra que deben ser incluídos (por ejemplo, la base de datos), etc. El setup.py de GPEC es el siguiente: from distutils.core import setup import py2exe import matplotlib data = matplotlib.get_py2exe_datafiles() data += [ LICENSE.txt ] includes = [ numpy.core.umath ] excludes = [ _gtkagg, _tkagg, bsddb, curses, , pywin.debugger, pywin.debugger.dbgcon, pywin.dialogs, tcl, Tkconstants, Tkinter ] packages = [] dll_excludes = [ libgdk-win dll, libgobject dll, tcl84.dll, tk84.dll ] setup( data_files = data, options = {"py2exe": {"compressed": 2, 94 Capítulo 10. Implantación

103 ) }, windows=[ aui.py ] "optimize": 0, #2, "includes": includes, "excludes": excludes, "packages": packages, "dll_excludes": dll_excludes, "bundle_files": 3, "dist_dir": "dist", "xref": False, "skip_archive": False, "ascii": False, "custom_boot_script":, } El resultado de py2exe es una carpeta./dist que incluye todo el código fuente de la aplicación en formato bytecode con todas las bibliotecas necesarias así como el intérprete de Python empaquetado como biblioteca dinámica. Figura 10.2: Resultado de la ejecución de py2exe Ejecutando aui.exe se ejecutaría la aplicación distribuible Empaquetado para sistemas Windows 95

104 Generación de un instalador Si bien la distribución de la carpeta./dist, posiblemente en formato comprimido (.zip,.rar, etc.), es suficiente para correr la aplicación y esta se encuentra optimizada, el usuario Windows está acostumbrado a la utilización de instaladores que disponen los archivos en un directorio para tal menester ("windows/programs files" en general), realizan tareas como la registración de la aplicación y generan entradas de acceso rápido en el Menú de Inicio, por ejemplo. Para realizar un instalador a partir del directorio generado por py2exe se utilizó la aplicación NSIS (Nullsoft Scriptable Install System) ( que es una software open source para la creación de instaladores Windows. Figura 10.3: Creando un instalador Windows a partir de un zip con el contenido resultante de py2exe Compatibilidad La instalación de GPEC se ha probado satisfactoriamente en sistemas Windows XP, Windows Vista y Windows Capítulo 10. Implantación

105 10.2 Instalación en sistemas Linux Para entornos Linux, el empaquetado y la distribución se realiza mediante las nombradas Python Distribution Utilities ( Distutils ). En términos generales, es un análogo al utilitario make muy común en flujos de desarrollo basadas en lenguaje C o C++, que permite la declaración de dependencias y la instalación de un paquete Python, ya sea esta una aplicación en sí, una extensión o un módulo de funciones auxiliares. La diferencia fundamental con el empaquetado para Windows es que no se distribuye el conjunto de dependencias, sino que estas son simplemente declaradas. El usuario (o el instalador automatizado, como easy_install) son los encargados de asegurar el cumplimiento de esta dependencia, ya sea verificando que está previamente instalada en el sistema o instalandola. Aunque esto genera cierto overhead en primera instancia, porque una dependencia (por ejemplo, Matplotlib) es instalada completamente, esta política permite una optimización cuando existen dependencias comunes en diversas aplicaciones. En nuestro ejemplo, si dos aplicaciones requieren Matplotlib, utilizan una única versión instalada en el sistema. Esta coincidencia de dependencias es altamente frencuente en sistemas Linux, heredada de la filosofía Unix que se resume en su famoso leitmotif: Write programs that do one thing... and do it well 1 Sin embargo, por falta de masa crítica y tiempo, al momento de la presentación no se realizaron instaladores ni paquetes específicos para una distribución Linux, aunque la instalación mediante el código fuente es trivial, dado que Python no requiere compilación. Los siguientes comandos son suficientes para la obtención de la última versión de GPEC y sus dependencias: $ sudo apt-get install python-matplotlib python-matplotlib-data python-numpy python-wxgtk2.8 wine subversion $ svn checkout gpec Y para ejecutarlo, simplemente se invoca el script principal: $ python gpec/aui.py 10.3 Distribución y soporte Dada la gratuidad de GPEC, cada nueva versión se deja disponible automáticamente en la sección de descargas del sitio de desarrollo, y también en su sitio oficial También se ha creado un grupo de correo, que intenta nuclear a la comunidad de usuarios e interesados en GPEC. Allí se remiten novedades del desarrollo, se contestan dudas y se recibe feedback de los usuarios. La dirección del grupo es 1 Escribe programas que hagan una cosa... y hazlo bien Ver Instalación en sistemas Linux 97

106 98 Capítulo 10. Implantación

107 CAPÍTULO 11 Conclusiones 11.1 Resultados El desarrollo de este proyecto ha satisfecho los objetivos y requerimientos planteados. El software obtenido constituye una mejora cualitativa y cuantitativa de funcionalidad y facilidad de uso respecto a la versión preexistente. Se consiguió una aplicación multiplataforma a partir de una única rama de código que ha sido probada en sistemas Windows XP, Windows Vista, Windows 7 de 32 y 64bits y las distribuciones con kernel Linux Ubuntu (32 y 64bits) y Red Hat. Los gráficos producidos tienen alta calidad, con herramientas de manipulación accesibles desde la misma interfaz (barra de herramientas y menú contextual) que permiten el control de escala, el deslizamiento, el manejo del historial de visualización, ocultación de curvas, escala logarítmica, visualización de grilla, etc. La generación de diagramas 3D constituye una funcionalidad de alta repercusión, sobre todo para la compresión y el estudio introductorio del comportamiento del equilibrio de fases. La naturaleza interactiva (rotación, superposición de diagramas) permite complementar y asimilar el conocimiento, tarea compleja basándose en diagramas 2D típicos de la bibliografía. Como ya se ha mencionado, un aspecto de especial interés fue la mejora en la usabilidad que ha sido estudiada mediante algunas pruebas (por ejemplo, el comportamiento de usuarios con conocimiento del dominio del problema que usan por primera vez la aplicación, o usuarios que no comprenden el dominio pero logran hacer funcionar el programa intuitivamente). La conclusión es que la interfaz es intuitiva y bien lograda aunque se trate de un aspecto sensible a un proceso de mejora continua. La calidad de la los gráficos, exportable en múltiples formatos aptos para la publicación científica (por ejemplo EPS (Encapsulated PostScript), incrustable en documentos generados con LaTeX) también es una característica superadora y bien recibida por los usuarios, ya que evita el procesamiento gráfico de capturas de pantalla (con resultados de pobre calidad) o la graficación de los sets de datos mediante otras herramientas de software. 99

108 11.2 Observaciones respecto a la tecnología empleada La utilización de Python como lenguaje para computación científica ha sido una práctica en constante crecimiento alrededor del mundo, tanto en ambientes académicos como de la industria. Prueba de esto es el éxito de la conferencia SciPy: Python for Scientific Computing Conference que durante 2011 tendrá su 10º edición 1 en Austin, Estados Unidos, mientras que en agosto se hará la 4º edición de la versión europa, EuroScipy, en París, Francia. La edición de 2010 convocó a más de 500 profesionales (ingenieros, matemáticos, físicos, químicos, biólogos), 47 empresas involucradas y los auspicios destacados de Dell, Microsoft y el gobierno de India. En este último pais, vanguardia mundial en la industria del desarrollo de software y en la calidad de su educación superior técnica, en el año 2009 se ha puesto en marcha un programa denominado FOSSE (Free and Open source Software for Science and Engineering Education) con un presupuesto global de 1000 millones de dólares para que los estudiantes de ciencias e ingenierías usen herramientas open source para todas sus necesidades computacionales, mejorando así la calidad de la enseñanza y el aprendizaje 2. Uno de las tres pilares programáticos es el uso de Python para la computación científica. Además, Python ha obtenido el premio a mejor lenguaje de programación durante 3 ediciones consecutivas ( ) en el programa Readers Choice Awards de la revista especializada Linux Journal 3 Por otra parte, el conjunto de herramientas complementarias (Matplotlib y Numpy) constituyen a esta altura casi un estándar de facto para el software científico con Python, con probado éxito de integración y cuyas comunidades de desarrolladores y usuarios están intrínsecamente relacionadas En este contexto de creciente aceptación, la elección de Python y sus complementos constituyó un acierto, no sólo por los resultados satisfactorios en relación a los objetivos y tiempos propuestos, sino porque se suma a una corriente de modernización tecnológica de los ámbitos científico-tecnológicos, en particular en lo relacionado con el desarrollo de software, aportando calidad, facilidad y potencia de prestaciones. Por último, si bien todavía no ha podido cuantificarse, la decisión de mantener el proyecto bajo una licencia libre permitirá no sólo mayor facilidad para que la comunidad de usuarios reporte (y, eventualmente, resuelva) fallos, sino para potenciar sus posibilidades de disfusión, accediendo a circuitos a los que el software privativo (de escala moderada) no accede sin costosas campañas de marketing Problemas detectados Una de las dificultades detectadas constituyó falta de un proceso de refactoring temprano que permitiera llevar la aplicación a un patrón general de la aplicación, por ejemplo del ti- 1 Sitio web: 2 Sitio web: 3 Sitio web: Capítulo 11. Conclusiones

109 po Modelo-Vista-Controlador. No obstante, la aplicación está separada lógica y modulamente según las distintas incumbencias, lo que vuelve factible esta tarea. Otra dificultad se avisora de cara al futuro del proyecto relacianada con la utilización de Pub/Sub. El total desacople (una parte no conoce de la otra) requiere un criterio sistemático de parte del equipo de desarrollo y una documentación clara sobre quién, cómo y sobre qué mensajes se actúa Tiempo de desarrollo El tiempo insumido para la concreción fue mayor que el deseado 4, pero diversas métricas dan cuenta que ha sido un desarrollo al menos un 40 % más rápido que lo estimado restrospectivamente 5. En este sentido, se concluye que la metodología y las tecnologías empleadas han dado resultados positivos. Más aún, analizando el historial de revisiones del repositorio, iniciado el 4 de julio de , puede notarse que durante algunas semanas se realizaron muchos avances (infiriéndose esto, con cierto margen de error, desde la cantidad de commits realizados) mientras que en otras estuvo detenido. Puede concluirse d esto que el ritmo de desarrollo pudo haber sido más alto y, consecuentemente, haber alcanzado los objetivos propuestos con anterioridad, si hubieran existido condiciones (económicas, académicas, laborales, etc.) para una dedicación fulltime al proyecto Costo de desarrollo Según la herramienta de análisis de código Ohloh ( que utiliza el algoritmo COCOMO 7, el código de GPEC se compone de aproximádamente 6700 líneas de código Python, lo que insume un esfuerzo estimado de 1 programador/año. Según un salario internacional estándar para un proyecto de software con esta complejidad y lenguaje, el costo del software (sin su documentación) se estima en u$s 81,053 considerando una remuneración internacional estándar de un programador semi-senior 8. Contemplando la escritura de la documentación (este reporte), el esfuerzo estimado se eleva a 3 desarrolladores/año y u$s de costo total 9. 4 Se considera el proyecto iniciado en el mes de Julio de 2010, aunque la idea se trabajó informalmente desde tiempo antes. Esto suma 9 meses hasta Marzo de El algoritmo COCOMO predice, en la estimación más favorable, un tiempo de desarrollo de 15 meses. 5 Revisión Con cierta perspicacia puede observarse que el autor bautizó el nombre clave del proyecto como GPEC 2010 (tal es el nombre utilizado en Google Code) donde se refleja que la expectativa, no poco audaz, era concluir el trabajo durante dicho año. 7 COCOMO es un algoritmo de estimación de costos de software que utiliza una regresión de la evolución del proyecto. Ver 8 The average computer programmer salary is around USD 55,000 per year. Fuente 9 Una corrección no desestimable a este cálculo es que se calcula el costo de la documentación fuente en restructuredtext y la generada en HTML de manera automática con Sphinx, que representa aproximadamente un 23 % del costo total Tiempo de desarrollo 101

110 Mediante la herramienta SLOCCount ( de David Wheeler se estima un esfuerzo de meses y un costo total estimado de $ 162,167, debido a un factor de overhead (relacionado con la complejidad de abstracción) del 240 %, lo que da pauta de la complejidad global del software. tin@azulita:~/facu/pi/src$ sloccount --personcost / (...) Totals grouped by language (dominant language first): python: 5627 (99.88 %) xml: 7 (0.12 %) Total Physical Source Lines of Code (SLOC) = 5,634 Development Effort Estimate, Person-Years (Person-Months) = 1.23 (14.74) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 0.58 (6.95) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 2.12 Total Estimated Cost to Develop = $ 162,167 (average salary = $55,000/year, overhead = 2.40). SLOCCount, Copyright (C) David A. Wheeler 11.6 Impacto Si bien la publicación y difusión de las versiones públicas de este software se han mantenido como versiones beta manteniendo en paralelo el acceso a descarga de la versión anterior como versión estable, esta nueva versión de GPEC ya ha tenido experiencias de uso. Como se mencionó previamente, durante el mes de noviembre de 2010, la cátedra Termodinámica, correspondiente al 4º cuatrimestre de la carrera Ingeniería Química de la Facultad de Ciencias Exáctas, Físicas y Naturales (Universidad Nacional de Córdoba), utilizó la nueva versión para su prácticas de laboratorio, con gran aceptación y buenos resultados por parte de los alumnos. Con vista a la experiencia del corriente año, la cátedra de la asignatura tiene como plan preparar un artículo sobre la mejora pedagógica de la enseñanza de termodinámica asistida con el uso de esta nueva versión de GPEC. Asimismo, este trabajo permitió la publicación de un poster titulado Una nueva interfaz de 102 Capítulo 11. Conclusiones