ESCUELA POLITCNICA DEL EJRCITO MAESTRA EN GERENCIA DE SISTEMAS TPICOS ESPECIALES DE INFOCOMUNICACIONES

RESUMEN DEL CAPTULO 5 DEL LIBRO: INFORMATION SYSTEMS TRANSFORMATION

GRUPO N.- 1

INTEGRANTES: ING. WILSON CARCHI ING. ANDREA GUZMN ING. CARMEN MUOZ ING. JORGE NOROA

PROFESOR: RAMIRO DELGADO

Julio del 2011 QUITO - ECUADOR

CAPTULO 5: MODERNIZACIN DEL SISTEMA DE GESTIN DEL TRFICO AREO EUROCAT

Este caso de estudio muestra los mtodos ocupados por Thales Air Systems S.A y por The Software Revolution en la modernizacin de muchas aplicaciones de administracin de trfico areo usados en 280 aeropuertos en el mundo.

Introduccin
Thales es una empresa dedicada al desarrollo de sistemas de misin crtica, por ejemplo, los aplicados en aeropuertos. Su producto estrella en este campo es el Eurocat. Este sistema est escrito en Ada 83 y es ocupado en ms de 50 pases. Es muy fiable en el mbito aeroespacial y fue desarrollado siguiendo parmetros de estndares europeos de seguridad, as como tambin estndares de aseguramiento de calidad de software. Fue diseado adems con el objetivo de que a futuro el trfico areo en Europa pueda crecer en todo aspecto, tecnolgico, de trfico, etc., siendo un elemento clave para soportar altas tasas de trfico previstas para el 2015. El estudio est enfocado en el proceso ocupado para modernizar los sistemas de gestin de trfico areo de esta empresa entre el 2005 y 2008, evaluando cul cdigo sera el ptimo con la ayuda de herramientas facilitadas por TSRI, una industria lder en la modernizacin de sistemas heredados especializada en software orientado a objetos.

Objetivos generales del proyecto

Thales hizo un estudio profundo, llegando a la conclusin de que migrar Eurocat, que inicialmente estuvo escrito en Ada 83, a una versin actual, era fundamental para satisfacer los requisitos de los aeropuertos europeos. Inicialmente las iniciativas fueron: 1. Gestin de reclutamiento de nuevos ingenieros de software para la modernizacin. 2. Modernizacin del mtodo de desarrollo y herramientas 3. Implementacin de cdigo seguro y de calidad 4. Consolidacin del cdigo base para la prxima generacin de Eurocat. Se hizo una rplica de la aplicacin existente antes de cualquier cambio, para identificar los problemas del cambio tecnolgico que la modernizacin implica. Luego se identific que Java es un lenguaje apropiado para este cambio alcanzando los objetivos planteados entre otras razones por su fuerte ascenso como lenguaje de programacin con orientacin a objetos segn se puede apreciar en el siguiente grfico (Figura 1):

Figura 1: Uso de lenguajes en aplicaciones de tiempo real

Proyecto Piloto de Modernizacin del EATMS

Se plante un proyecto piloto con TSRI en el 2005 con los siguientes objetivos:
1. 2. 3. 4. 5. 6.

Asegurar la equivalencia funcional entre Java o C++ y el cdigo original heredado en Ada. Asegurar que el cdigo generado cumple con las reglas de seguridad y establecer estndares de codificacin. Asegurar que la documentacin producida por las herramientas permite una comparacin detallada entre el cdigo fuente original y el resultante. Evaluar si Java o C++ podra satisfacer los objetivos de rendimiento de EATMS. Definir estrategias para la transformacin de la refactorizacin y optimizacin de cdigo. Evaluar las posibilidades de xito para la transformacin total del procesamiento de los datos de vuelos.

Primero se construy un prototipo en lenguaje C++ para medir el rendimiento respecto al sistema heredado en Ada 83. Este mismo prototipo se lo construy en Java con el mismo fin. Luego de las pruebas realizadas con el prototipo construido en C++, se lleg a la conclusin de que los resultados generados por la herramienta heredada y el prototipo eran muy similares. Se encontraron ciertos errores que luego fueron corregidos por TSRI. El mismo proceso se sigui con el prototipo construido en Java. En este caso, se hallaron 10 errores que igualmente fueron solventados por TSRI. El rendimiento de la aplicacin heredada, en comparacin con el prototipo en Java fue muy similar al evaluado en C++ dando como resultado respuestas exitosas.

Se concluy pues, que los prototipos realizados en Java y en C++ no presentaban distorsiones funcionales respecto a la aplicacin original construida en Ada 83. As, se determin que el proceso de transformacin haba sido correctamente implementado.

Evaluacin del Desempeo del mdulo de Gestin de Prediccin de la Trayectoria (TPM) antes de la Optimizacin del Cdigo.
Cuando se inici con la evaluacin de los prototipos, se encontr que Java tena problemas en tiempos de respuesta. Es por eso que el proyecto de modernizacin del sistema estaba siendo orientado a que sea construido en C+ +. Las pruebas fueron realizadas sobre un equipo Linux. El sistema fue evaluado con 27 planes de vuelo, monitorendose slo el mdulo de Gestin de Proyeccin de la Trayectoria (TPM), ya que slo ste fue migrado. Mientras se seguan realizando pruebas con distintos tipos de datos en el mdulo de TPM, se iba concluyendo que el prototipo en Java tena problemas en tiempos de respuesta. Se lleg a determinar que este problema principalmente era ocasionado por el garbage collector. En la siguiente figura (Figura 2) podemos ver el desempeo medido en la duracin de la llamada para cada invocacin del mdulo TPM entre C++ y Java.

Figura 2: Tiempos de duracin de las llamadas sin optimizar el rendimiento

Desempeo Despus de la Optimizacin del Cdigo Despus de haber detectado el problema en el prototipo construido en Java, se decidi cambiar el compilador. Inicialmente se trabajaba con JDK 1.5. Se decidi trabajar con JET que es un compilador compatible con Java SE 6.

Con este cambio, el prototipo desarrollado en Java, pudo alcanzar el rendimiento del prototipo construido en C++, y as juntos superar a la versin original escrita en Ada 83. En la siguiente figura (Figura 3) podemos ver los tiempos de duracin de las llamadas luego de optimizar el rendimiento.

Figura 3: Tiempo de duracin de llamadas con la optimizacin del rendimiento

Factor de rendimiento Ciertos factores de rendimiento influyeron en las mediciones realizadas entre los prototipos y el sistema original. Por ejemplo, los prototipos tenan bajo rendimiento cuando su cdigo ocupaba matrices dinmicas, lo cual en Ada 83 era manejado con matrices estticas, haciendo as su rendimiento sea alto. Otro ejemplo ocurri con respecto a la representacin de almacenamiento de nmeros de punto flotante. Algo que tambin es importante sealar, es que el prototipo construido en Java fue desarrollado para 64 bits, mientras que el original era de 32 bits. Los clculos por consiguiente eran duplicados en el prototipo, ya que el cdigo reproduca los mismos clculos del sistema original. En la siguiente tabla (Figura 4) podemos apreciar una comparacin de tiempos de desempeo entre los lenguajes de programacin utilizados en este proyecto:

Figura 4: Proporcin de tiempos de desempeo por lenguajes

Utilizacin y Optimizacin de memoria El uso de memoria del TPM de Java era 4 veces mayor que el de C++, antes de la optimizacin, como se puede ver en la siguiente figura (Figura 5):

Figura 5: Proporcin de uso de memoria

Esto se deba a que se us un compilador Just in time de Java, que haca que antes de la primera llamada a cualquier funcin exista un gran uso de memoria, por la compilacin que se ejecuta. La degradacin del tiempo de respuesta fue eliminada cuando se us un compilador AOT (ahead of time, que hace una precompilacin), esto permiti detectar que el manejo de la memoria del garbage collector era la causa de los tiempos de respuesta inconsistentes. Durante las pruebas de rendimiento del garbage collector se monitorearon las siguientes propiedades:
1. 2. 3. 4. 5.

Tipo de recoleccin (de objetos recientes, de largos tiempos de vida y de tiempos de vida indefinidos) Tiempo total en el que se hace la recoleccin Tiempo de ejecucin de mtodos sin la recoleccin Duracin promedio de la recoleccin Nmero de llamadas que sobrepasan con el 20% el tiempo estndar

Implementando un apropiado tamao de coleccin de objetos recientes, la coleccin de objetos de larga vida no va a crecer, lo que hace que la recoleccin se evite completamente. Al afinar estos temas, la dispersin que se tiene en tiempos de respuesta pudo ser reducida exitosamente. Pruebas de estrs Se hicieron pruebas de estrs sobre las 2 versiones del TPM, haciendo 14 mil invocaciones, se detectaron un 30% de tiempos de respuesta mayores al del promedio y se los atribuy a robos de ciclos de CPU por demonios de LINUX. Los resultados entre la versin de Java y C++ fueron similares (Figura 6).

Figura 6: Resultados tiempos de respuesta pruebas de estrs.

Conclusiones del benchmark de desempeo Cuando se realizan benchmarkings de desempeo de sistemas, es importante considerar la parcialidad de los ingenieros que van a ejecutarla, as como la correcta eleccin de algoritmos que se evaluarn, en este caso el proyecto piloto del TPM para la prediccin de trayectorias, ofreca una gran oportunidad para comparar el rendimiento en los 3 lenguajes ADA, C++ y Java. El objetivo principal de realizar este benchmarking, era encontrar el lenguaje de programacin que ser empleado para la migracin de todo el sistema de administracin de trfico ATMS, y que permita obtener el rendimiento exigido por los estndares establecidos para este tipo de sistemas. Los resultados obtenidos con el TPM en Java, ayudaron a elegir este lenguaje para la migracin completa del sistema FDM, sin embargo, es necesario elegir una adecuada JVM, adaptar las reglas de transformacin de cdigo para optimizarlo y configurar adecuadamente el garbage collector para cumplir los requerimientos de rendimiento y tiempos de respuesta. Principios generales para las operaciones de refactorizacin Durante el proyecto piloto se identificaron algunos principios y directrices generales para el proceso de transformacin de cdigo. Las directrices fueron: 1. Definir mdulos de alto y bajo nivel con contenidos consistentes limitando la dependencia entre ellos. 2. Identificar y aislar las interfaces entre mdulos 3. Las interfaces del middleware deben estar separadas del cdigo de la aplicacin. 4. Los tipos y procedimientos deben ser encapsulados y la visibilidad de los objetos disminuida para mejorar el diseo orientado a objetos. 5. El rendimiento y uso de memoria deben ser optimizados 6. El cdigo muerto y entradas no usadas deben ser eliminadas. 7. El cdigo redundante debe ser identificado y en lo posible consolidado. 8. Las variables globales deben ser eliminadas para permitir multi threading 9. Los procedimientos y clases deben ser divididas en unidades ms pequeas para mejorar las mtricas de calidad de cdigo y disminuir el nmero de defectos.

10. El cdigo de java debe ser refactorizado despus de la transformacin

original, para mejorar la calidad de cdigo. Se incluyeron tambin algunos principios para la modernizacin: 1. Cualquier operacin de refactorizacin de cdigo, debe ser replicada en la versin de original de ADA del sistema, mientras dure el proyecto de modernizacin. (Se hacan optimizaciones en paralelo al proyecto de transformacin) 2. Todas las modificaciones del cdigo Java resultante deberan hacerse a travs de las reglas establecidas, solamente cuando no haya otra opcin se permitirn las modificaciones manuales. 3. Thales (el cliente), fue responsable de definir todo el proceso de refactorizacin: cronograma, tareas, especificaciones y entradas. TSRI fue responsable de la implementacin de la especificacin de refactorizacin y de generar todo el cdigo y reportes. El proceso de refactorizacin fue definido de la siguiente manera:
1. 2. 3. 4. 5.

Thales actualiz los archivos de configuracin de entrada para la refactorizacin. Thales actualiz el cdigo Ada si era necesario. TSRI transform el cdigo a Java con la nueva configuracin El cdigo Java fue enviado nuevamente a Thales junto con los reportes actualizados y los entregables generados por TSRI. Thales procedi a automatizar las pruebas de verificacin y si era necesario se iniciaba un nuevo ciclo de transformacin hasta que se consigan los objetivos de construccin, composicin y diseo del sistema y la satisfaccin de ambas partes.

Objetivos y Restricciones del Modernizacin del Sistema EATMS

Proyecto

Completo

de

Al terminar el proyecto piloto se inici la modernizacin de todo el sistema, un objetivo clave de la transformacin era el conseguir una rplica exacta en Java del sistema construido en ADA 83. La rplica funcional JFDP, deba asegurar que todas las especificaciones del sistema no fueran afectadas y que sean idnticas a las originales, por lo que la traduccin de cdigo tuvo que ser estrictamente realizada con las herramientas y reglas automatizadas, evitando la transcripcin humana. Para asegurar la consistencia de la traduccin, el 99.5% de la misma se la realiz con procesos automticos, el cdigo resultante a continuacin era refactorizado para optimizar el sistema y alcanzar los requerimientos de rendimiento establecidos. Esta automatizacin se logr creando reglas de traduccin y refactorizacin en el motor de reglas del TSRI de manera que luego puedan ser reutilizadas para futuras mejoras.

Otro requerimiento clave fue mantener las interfaces con otros sistemas idnticas a las originales de ADA. Los sistemas basados en Unix, introdujeron APIs de Java a sus servicios para poder integrar los procesos del FPL de Java. Adicionalmente, el JFDP, deba interactuar con libreras existentes en C que fueron llamadas a travs de JNI (Java Native Interface).

Directrices para Wrappers JFDP La definicin de wrappers fue un aspecto importante en el proceso de transformacin, ya que facilitaban la conexin fluida entre FDP y el resto del sistema Eurocat. El middleware de los sistemas basados en Unix, permitieron una apropiada comunicacin entre los componentes del Eurocat, compartiendo memoria entre los nodos remotos y los buffers punto a punto. El software para sistemas basados en Unix, da acceso a los servicios para las aplicaciones ADA, C y Java. Los JFDP wrappers, son prototipos funcionales hechos en Java, con codificacin y decodificacin de buffers de bytes, para recibir datos a travs de los APIs de Java de manera rpida minimizando la saturacin de las interfaces. Las restricciones clave de la refactorizacin fueron:
1. 2. 3. 4. 5. 6.

El cdigo JFDP y las interfaces internas necesitaban ser reestructuradas, preservando su funcionamiento. El sistema JFDP necesitaba adaptarse fcilmente a nuevas interfaces JFDP debe estar en la capacidad de cargar cualquier conjunto de datos distribuidos en el sistema JFDP debe interactuar con otro proceso de Ada como si hubiera sido escrito en el mismo lenguaje. Se necesita que JFDP sea monitoreado y reiniciado como en ADA Los logs de rastreo del FPL del JFDP, debe ser idnticos a los originales.

Enfoque de la modernizacin del EATMS Para cumplir con la transformacin de Ada 83, Thales contrat a TSRI para la traduccin de 1.7 millones de lneas de cdigo en Ada 83 a Java. Los servicios brindados por TSRI fueron: (1) documentacin idntica a la original, (2) transformacin del cdigo de Ada 83 a Java, (3) refactorizacin automtica, (4) refactorizacin semi-automtica, (5) soporte en la integracin del sistema y pruebas y (6) documentacin final. Descripcin general del proceso de modernizacin del EATMS Aunque no existen an certificaciones como CMMi o ISO para las tecnologas de modernizacin automatizadas, como JANUS, TSRI maneja altos estndares de calidad en este paquete de herramientas multi-fuente, multi-target, basado en

modelos y reglas que sigue las mejores prcticas promovidas por OMG (Object Management Group) con su iniciativa ADM (modernizacin basada en arquitectura), de la que TSRI ha participado. Los mtodos y prcticas empleadas por Thales y TSRI para el proyecto EATMS, son un buen ejemplo de varios escenarios del ADM, especficamente (1) gestin de portafolio, (2) modernizacin lenguaje a lenguaje (L2L), (3) modernizacin plataforma a plataforma (P2P), (4) reutilizacin y consolidacin de componentes y (5) transformacin basada en arquitectura. El proceso de modernizacin de TSRI fue controlado mediante sistemas de control de versiones para archivos de entrada, cdigo generado y todos los reportes y documentacin elaborados. Todos los entregables y versiones incrementales de la herramienta son etiquetados con el control de versiones en todos los momentos claves y entregas del proyecto. Virtualmente todos los cambios son conseguidos por la aplicacin de reglas de transformacin basadas en modelos. Las modificaciones manuales de cdigo son muy raras, pero si se requieren, son integradas con las herramientas de control de versiones CVS e incluidas en las reglas del proceso. La calidad se asegur y el proceso de replicacin es conseguido mediante la ejecucin de pruebas antes de cualquier entrega del proyecto. Proyecto del Proceso de modernizacin del EATMS Tres herramientas intervinieron en el proceso de modernizacin de todo el EATMS: 1. JANUS, del TSRI, fue usado para la transformacin de cdigo y refactorizacin automtica, regenerando el cdigo de Java despus de la refactorizacin. 2. Klocwork Architecture, usado por Thales, para refactorizar el cdigo de Java grficamente, crear nuevos tems de cdigo y reubicar paquetes, clases, mtodos campos en algunos mdulos. 3. Refactor, es una herramienta hecha en Perl, de Thales, aplicada para etiquetar el cdigo de Ada que deba ser refactorizado posteriormente por JANUS. La siguiente figura muestra el proceso iterativo de modernizacin empleado por Thales y TSRI (Figura 7).

Figura 7: Proceso Iterativo de modernizacin

El Proceso de Refactorizacin y Transformacin de EATMS La tecnologa que se utiliza en la modernizacin del sistema legacy TSRI se muestra en la figura 8. Aqu se observa dos componentes importantes el JPGEN y JTGEN. JPGEN es el motor de especificacin gramatical de TSRI y se encarga de realizar el anlisis gramatical (parsear) el cdigo para luego generar los modelos AST y los impresores que generarn cdigo a partir de los modelos AST basados en la especificacin gramatical. Por otro lado, el componente JTGEN es el motor de transformacin de TSRI, que se encarga de reconocer patrones ASTs y transformarlos en modelos AST. En el proceso de transformacin, el software EATMS fue representado en 3 modelos AST, para esto en primer lugar los archivos originales del legacy fueron parseados en AST de Ada 83, a continuacin se transforman en un AST de IOM y finalmente como un AST de Java. Esta transformacin fue llevada a cabo por un parseador generado por JPGEN y un limitador generado por JTGEN. Por otro lado, la transformacin entre el modelo AST del legacy Ada y el modelo AST de IOM fue realizado por las reglas de transformacin de Ada2IOM, las cuales son generadas por JTGEN. Y la transformacin entre el IOM y el AST de Java fue llevado a cabo por las reglas de transformacin denominadas IOM2Java generadas tambin por JTGEN.

Figura 8: Proceso de Refactorizacin

El proceso de refactorizacin consiste en cambiar al software de modo que este cambio no altere o modifique la funcionalidad del cdigo. Al hacerlo manualmente, la refactorizacin se aplica directamente al cdigo origen, lo cual es una labor muy dura y propensa a errores, sin embargo, el proceso de refactorizacin de TSRI es altamente automatizado y se caracteriza porque se aplican transformaciones basadas en patrones a un modelo de software mejor que el cdigo original, permitiendo que este proceso se aplique con confiabilidad y seguridad sobre una escala masiva con una disciplina multi-nivel rigurosa, automatizada y procesada mediante una mquina. La refactorizacin automtica y semiautomtica est formada por reglas de transformacin generadas por JTGEN que son aplicadas al modelo AST de IOM para mejorar su estructura antes de la transformacin en un modelo AST de java. El orden de las operaciones de refactorizacin es crucial para asegurar su uso apropiado, es por esto, que algunas operaciones de refactorizacin deben ser realizadas con mayor prioridad que otras para establecer el estado del modelo de software para las subsecuentes operaciones de refactorizacin. En la figura 9 se observa el proceso de transformacin iterativa y de refactorizacin que emplea TSRI para todos los proyectos.

Figura 9: Proceso de Refactorizacin de TSRI

Las operaciones de refactorizacin son fuertemente dependientes de los objetivos del diseo de un proyecto, es por esto que, en un proyecto de modernizacin muy largo y complejo las operaciones de refactorizacin son generalmente combinadas y se requiere el orden y las secuencias de su invocacin para ser ejecutadas. A continuacin se muestra un resumen parcial de la mayor parte de las operaciones automticas y semiautomticas de refactorizacin ejecutadas por TSRI usando su set de herramientas JANUS para el proyecto EATMS: Tareas de Refactorizacin Automatizadas:
1. 2. 3. 4. 5.

6. 7. 8. 9. 10. 11. 12.

Convertir paquetes genricos Ada a clases genricas de java. Empaquetar clases no instanciables con atributos estticos. Tipos de registro y excepciones a clases instanciables. Empaquetar Ada con sus propios tipos a los paquetes java que contienen las correspondientes clases. Registros de variantes a clases Java con sus propias clases embebidas (inner class), atributos y mtodos para administrar los valores y tipos variantes. Refactorizar enumeraciones Ada a enumeraciones Java. Convertir arreglos a string, list o enumMap sobre ndices y tipos de valores. Resolver las sobrecargas de operadores Ada y transformarlas a mtodos Java. Transformar inicializaciones agregadas a asignaciones simples en Java. Asociaciones nombradas a parmetros de funcin posicional y atributos de clases. Administrar la inicializacin del paquete. Remplazar referencias varias con llamadas en envolturas externas.

13. Combinar parmetros de funcin. 14. Generar interfaces de servicio externos. 15. Generar comentarios para el javadoc desde los comentarios originales de

Ada Tareas de refactorizacin semiautomticas Remover cdigo sin uso y parmetros de funciones Trasladar y renombrar los paquetes, clases, funciones y campos. Detectar registros con valores default y convertirlos en inicializadores de constructor. 4. Convertir funciones de operaciones en algunos tipos de objetos y mtodos de objetos. 5. Reportar y combinar clases similares y funciones. 6. Convertir algunos tipos primitivos de Ada en clases con operaciones propias.
1. 2. 3.

Especificaciones del Proceso de Refactorizacin y Plan de Desarrollo El desarrollar la especificacin del proceso de refactorizacin JFDP tuvo como objetivo definir y documentar todas las operaciones que se requieren para establecer las tcnicas objetivas de JFDP, estructurando la secuencia de las aplicaciones de todas las operaciones de refactorizacin y provee un marco para monitorear el progreso en la definicin del set de reglas y la ejecucin de las especificaciones de refactorizacin. Esta especificacin define un proceso uniforme para ser aplicado en todas partes por cada nueva lnea bases de Ada en la duracin del proyecto. En el proyecto, 63 requerimientos de refactorizacin fueron implementados para la primera transformacin JFDP; luego 14 requerimientos adicionales de refactorizacin fueron definidos para la segunda transformacin JFDP basada sobre acciones y retroalimentacin de anlisis de seguridad. La herramienta de arquitectura Klocwork fue usada para apoyar el trabajo del anlisis de una forma iterativa para analizar las sucesivas iteraciones de las aplicaciones Java generadas por JANUS para construir una visualizacin grfica de la arquitectura del JFDP y definir los planes de refactorizacin especificando la restructuracin de la aplicacin para mejorar las dependencias de los componentes: paquetes, clases y mtodos. La salida de esta arquitectura permite al usuario definir rpidamente los planes de refactorizacin del proyecto, un ejemplo de esto se muestra en la siguiente figura 10:

Figura 10: Salida de la Arquitectura

El ejemplo de la figura 10 corresponde a uno de los mdulos de nivel 1 del proceso FPL, llamado PRO, la cual esta subdivida en paquetes del nivel 2. Las flechas indican las dependencias reales de software y los nmeros indican el nmero actual de lneas de cdigo donde estas dependencias ocurren. Las dependencias externas de cada tem son representadas por flechas que sealan hacia las fronteras de la inclusin del rectngulo. Esta salida ilustra la naturaleza general del plan de refactorizacin: Tener mdulos funcionales aislados (ctrm, tpm, volm) en una forma consistente. Decremento de las dependencias entre mdulos funcionales lo mximo que sea posible. Evitar dependencias circulares entre mdulos. Identificar y aislar interfaces entre mdulos funcionales para reducir las dependencias entre paquetes. Concentrar mdulos externos en clases creadas automticamente por las operaciones de refactorizacin en servicios externos.

La aplicacin de los planes de refactorizacin especficos de Thales para el proyecto JFDP consisti en la ejecucin de secuencias de operaciones de refactorizacin atmicas tales como estn representadas en la figura 11, que muestra un extracto de ms de 2800 pasos del plan de refactorizacin que es uno de los muchos aplicados al proyecto del cdigo. La ejecucin de tal plan como se considera a ser refactorizado por un proceso semi-automtico mientras

los pasos en el plan de refactorizacin son llevados a cabo por la automatizacin indicadas en la especificaciones construidas explcitamente por el ser humano.

Figura 11: Extracto del Plan de Refactorizacin

Drivers de refactorizacin y de ejecucin Usando la metodologa definida en la seccin anterior la modernizacin de Thales/TSRI mejora el direccionamiento para direccionar los siguientes drivers de refactorizacin del proyecto de modernizacin JFDP: Extraer una nueva arquitectura de las libreras FPL por mdulos aislados con limitadas dependencias y definiciones consistentes Definiciones de tipos de grupos y las instancias para la computadora. Prohibir o limitar el uso de tipos externos para el procesamiento FPL. Se prohibi el emparejamiento de los tipos FPL o tratamiento a CSCIs externos. Se estructur el cdigo con la jerarqua de paquete ms profunda, con clases ms pequeas y los mtodos ms pequeos siempre que fuera posible. Se prohibi las variables globales. Se previno la existencia de dependencias dbiles entre mdulos. Se previno que exista un rendimiento pobre en los mdulos. Se restringi el uso de los servicios del middleware (UBSS). No se implement el cdigo del aplicativo dentro del FDS (Mdulo de la interfaz FPL)

La figura 12 muestra el plan de refactorizacin detallado para el proyecto de modernizacin EATMS.

Figura 12: Proceso de Refactorizacin

Verificacin del Proceso de Refactorizacin Los planes de refactorizacin de la complejidad que se emplean en el proyecto de EATMS requieren rigurosos procedimientos de verificacin. Un proceso para verificar las especificaciones de refactorizacin fue definido para asegurar que todos los requerimientos fueran aplicados correctamente a todos los tems de cdigo para los cuales fueran aplicables. Uno de los pasos previos al plan de refactorizacin envuelve a la aplicacin en cientos de operaciones de refactorizacin complejas aplicadas al cdigo automticamente. El proceso para verificar la exactitud de las operaciones de refactorizacin individuales y el plan de refactorizacin, fueron guiados por el

documento de Especificacin de verificacin de refactorizacin de proyectos Java. Este documento estipulaba que una prueba de inspeccin ser diseada para verificar cada operacin de refactorizacin incluida en la especificacin de refactorizacin. La refactorizacin es un proceso intrnsecamente iterativo que requiri muchas clases de procedimientos de inspeccin, incluyendo inspeccin de cdigo directo visual, anlisis ejecutado por scripts, anlisis en informes de Klocwork y pruebas de cumplimiento unido por reportes de dependencia y mtricas. A travs de este proceso iterativo de refactorizacin y pruebas, seguido por ms refactorizacin, el diseo de una aplicacin compleja es gradualmente desarrollado para mejorar la coherencia composicional de componentes individuales y dependencias intermdulo entre mdulos que son eliminados. Los reportes de anlisis e inspeccin y dependencia fueron activamente intercalados con el proceso de refactorizacin para dirigir, adaptar y optimizar cada ciclo del proceso de refactorizacin. Este proceso de verificacin fue tambin hecho para proveer evidencia de seguridad y justificar el aseguramiento de la calidad en apoyo a la integracin del software JFDP dentro de los actuales proyectos ATC, as como tambin para obtener mtricas para proporcionar pruebas de las ventajas de transformacin JFDP. Este documento JRFSV fue la parte de un Documento de Justificacin de JFDP global en una revisin de cuentas llevada a cabo por clientes de Thales. Algunos ejemplos de las salidas del proceso de refactorizacin estn en la tabla 5.3 de la figura 13 la cual lista el mdulo JFDP de nivel 1 y su tamao actual de lneas de cdigo.

Figura 13: Salidas del Proceso de Refactorizacin

La estrategia de refactorizacin reorienta el diseo orientado a procedimientos mientras ms estructurado y modular es el diseo. La siguiente figura muestra un ejemplo de un diagrama de objetos producto de la refactorizacin (figura 14):

Figura 14: Diagrama de Objetos

Ejemplo de la operacin de Refactorizacin: Eliminacin de Variables Globales Una estrategia utilizada para la optimizacin de los tiempos de respuesta en esta migracin fue la de eliminar las variables de sesin que se llamaban entre diferentes mdulos del sistema, con la ayuda de Java y con la orientacin a objetos en el cual se basa este lenguaje, estas variables de sesin se transformaron en variables de clases que ayudaron a mejorar el desempeo de la aplicacin. Ejemplo de la operacin de refactorizacin: Delimitacin de Cdigo Otra estrategia utilizada fue la de delimitar el cdigo, en otra palabras, se comienza a tener una nocin de desarrollo por capas, ya que se busc separar la lgica de la aplicacin para encapsularla, adems usando el concepto de herencia que nos proporciona la orientacin a objetos se pudo disminuir el nmero de lneas de cdigo con relacin al ADA.

Mtricas de Calidad de la Refactorizacin del EATMS

Se consiguieron mejoras significativas en lo que se refiere a la calidad y seguridad de cdigo, eliminando cdigo muerto y variables globales, logrando con esto que los procedimientos y clases sean ms fciles de mantener, con esto se redujeron las dependencias entre mdulos, se transformaron las variables globales en miembros de las clases logrando un comportamiento ms fcil de entender. Debido a que el cdigo es ms entendible y adems se incluy el manejo de lenguaje UML y herramientas como Eclipse, hicieron que los tiempos de anlisis y desarrollo en lo que se refiere a mantenimiento y correccin de problemas se reduzcan considerablemente. Estos beneficios de transformacin y las herramientas entorno a Java han sido claves para convencer a la comunidad ATC del valor de Java.

Estrategia de Pruebas de la Modernizacin del JFDP

El principal objetivo de la estrategia de prueba JFDP era garantizar la correcta transformacin a la nueva plataforma tecnolgica de tal manera que se mantenga el grado de servicio.

La prueba es para todo el sistema para lograr pruebas ms realistas que las pruebas unitarias. Una de las ventajas de la tecnologa Java es la amplia disponibilidad de herramientas que permiten una mejor calidad del cdigo, el control del mismo y pruebas. Una de estas herramientas es EMMA que es capaz de producir un informe muy detallado, puede ser ejecutado con las pruebas unitarias, pruebas de CSCI, y pruebas del sistema. Los resultados se agregan y se resumen en un informe en formato HTML para que pueda ser analizado por los expertos. A continuacin se presentan los tipos de pruebas que se llevaron a cabo: Pruebas de componentes, incluyendo slo la funcin del FDP en modo stand-alone frente a los requisitos de prueba funcional 2. Las pruebas de integracin, con la participacin de plataforma completa del sistema se centra en FDP interfaces, el comportamiento del sistema, y las actuaciones 3. Las pruebas de validacin, con la participacin de plataforma completa del sistema se centra en funcionalidad. 4. Pruebas de sombra, que involucran al cliente en ambientes ATC en vivo y controles reales.
1.

Principios de las Pruebas CSCI Eurocat proporciona los medios para ejercer estas pruebas tanto en el Ada y Java por medio de simulaciones ATC utilizando los datos del espacio areo en entornos FDP, para esto se utilizaron 12 bases de datos de pruebas distintas, para simular la ejecucin de JFDP bajo escenarios de vuelo riguroso. Una herramienta denominada AIRSPACE permite la reproduccin automtica de escenarios de prueba. Luego, otro mdulo del AIRSPACE fue diseado para extraer las salidas tanto de Ada como de Java. Cada salida de la prueba de Java se compar con el de Ada para asegurar que no exista distorsin de datos entre el FDP y Ada. Este conjunto de pruebas CSCI, combinado con una comparacin automtica de las salidas de Ada y Java fue la clave para lograr la confianza en el nuevo sistema. Principios de las Pruebas de Integracin Las pruebas de integracin para el sistema FDP fueron seleccionadas y ejecutadas tanto en Ada y Java. Estas pruebas de integracin se seleccionaron con los siguientes criterios:

Impacto de la migracin de interfaces

La garanta de que las interacciones con otros CSCIs funcionen correctamente Las pruebas de modo degradado Pruebas de rendimiento (prueba de carga, tiempos de inicializacin, etc.)

Se realiz una gama de pruebas de interfaz para asegurar que todos los CSCIs que interactan con JFDP funcionen correctamente.

Principios de las Pruebas de validacin Las pruebas de validacin tienen que ver con la seguridad. Estas pruebas se realizaron por primera vez en la plataforma del sistema de Ada y luego en Java. Los resultados de las pruebas trajeron un alto nivel de confianza en la transformacin, lo que llena las expectativas del proyecto piloto. Los resultados de las pruebas fueron los siguientes:

100% de las pruebas OK en 272 pruebas automticas 100% de las pruebas OK en 27 pruebas de integracin 100% de las pruebas OK en 99 procedimientos de validacin de pruebas

Evaluacin del Desempeo de Hardware del EATMS

La tendencia actual es el hardware de mltiples ncleos y procesadores, la nueva arquitectura de Java proporciona notables ventajas en relacin al original ADA. Ya que esta nueva plataforma aprovecha mucho mejor los procesadores de este tipo. Un aspecto clave del proyecto era asegurar un rendimiento satisfactorio en tiempo de ejecucin. Hasta la fecha no ha habido incidentes con la JVM. Los tiempos para iniciar, reiniciar y apagar el sistema estuvieron muy por debajo de 1 minuto en realidad 99% de las respuestas estn por debajo de 1 segundo incluso durante las pruebas de carga y el mayor consumo de CPU es de aproximadamente 30-35% de PC de doble ncleo. Evaluacin de la JMV Dos mquinas virtuales de Java fueron evaluadas para su uso en el proyecto EATMS: Sun JDK 1.5 y Aonix PERC-Ultra. La JVM proporciona independencia de la plataforma y una arquitectura de tiempo de ejecucin que simplifica la programacin mediante la eliminacin de la gestin de memoria, pero lo hace con un costo en el tiempo de ejecucin. La JVM realiza interpretacin de los bytes de cdigo, garbage collector, manejo de excepciones, manejo de hilos, inicializacin de variables, etc.

A travs de la optimizacin del rendimiento, la JVM de Sun mantiene los tiempos de respuesta por debajo de 1 segundo y cuando el tiempo de respuesta superar al 1 segundo, se mantiene bastante baja (<5 segundos). Por lo tanto, la JVM de Sun cumple con los requisitos de rendimiento para el Sistema FDP. No hubo problemas con el JDK de Sun 1,5 en 6.500 horas de pruebas, la conclusin es que el actual JVM de Sun es confiable. La otra JVM evaluada fue el Aonix PERC-Ultra cuya JVM ofrece ms opciones para configurar el garbage collector, sin embargo, en el momento de la evaluacin del desempeo de la JVM fue 2,5 veces ms rpido que PERC-Ultra, adems PERCUltra no fue un apoyo en el uso ptimo de Multiprocesador.

Conclusiones del proyecto

La modernizacin del EATMS de Ada a Java, era un proyecto muy sofisticado, la clave del xito del proyecto est en la afinacin de los procesos de software, esto incluy el perfeccionamiento continuo y la adaptacin de las herramientas y mtodos para alcanzar y mantener un alto nivel de automatizacin en todas las fases del proyecto. Otro resultado significativo de este proyecto, es que se pudo llegar a la conclusin que es posible adaptar el uso de la tecnologa Java a la gestin del trfico areo.

Las siglas y definiciones para los sistemas de Eurocat

ADS: Vigilancia Dependiente Automtica. Sistema de vigilancia basado en datos de la aeronave. BADA: Base de datos de la aeronave. Data Set : Conjunto de parmetros y archivos de datos FDP: Procesamiento de Datos de vuelo. Componente de Eurocat que gestiona todos los aspectos de los datos del plan de vuelo, incluyendo FDP. JFDP. Imagen en Java de la funcin principal del FDP. Sistema FPL. La funcionalidad bsica de la CSCI FDP (64% del cdigo y requisitos). La FPL es el corazn de las futuras evoluciones presentadas por EATMS proyectos. Registro FPL. Registro de los datos del plan de vuelo almacenados o procesados por FPL en un disco de base de datos. FDS: Flight Data Server. TPM: Administrador de prediccin de trayectoria. UBSS: Software basado en sistemas UNIX. Es el Middleware de Thales para el ATC, que se ejecuta en sobre de UNIX / LINUX.