Documente Academic
Documente Profesional
Documente Cultură
Universidad de Salamanca
Revisado por: Dr. Francisco Jos Garca Pealvo Dra. Vivian F. Lpez Batista Aprobado en el Consejo de Departamento de 15 de julio de 2004
Informacin de los autores: Juan Carlos lvarez Garca rea de Lenguajes y Sistemas Informticos Departamento de Informtica y Automtica Facultad de Ciencias Universidad de Salamanca Plaza de la Merced S/N 37008 Salamanca jcag@usal.es Montserrat Mateos Snchez Escuela Universitaria de Informtica Universidad Pontificia de Salamanca C/ Compaa, 5 37002 Salamanca m.mateos@upsa.es Mara N. Moreno Garca rea de Lenguajes y Sistemas Informticos Departamento de Informtica y Automtica Facultad de Ciencias Universidad de Salamanca Plaza de la Merced S/N 37008 Salamanca mmg@usal.es
Este documento puede ser libremente distribuido. 2004 Departamento de Informtica y Automtica - Universidad de Salamanca.
Resumen
La reingeniera de sistemas heredados tiene por finalidad reestructurar o transformar viejos sistemas en aplicaciones ms fciles de mantener, con entornos ms agradables e integradas en nuevas plataformas de hardware/software. Tratamos de dar una visin general de lo que es la reingeniera de software y cules son las actitudes que se pueden tomar a la hora de modernizar un sistema legado que se ha quedado obsoleto en cuanto a operatividad, aspecto y software de base sobre el que se ejecuta, pero de probada eficiencia y que mantiene su funcionalidad. Mostramos las caractersticas de un proceso de desarrollo que se adapta a este tipo de aplicaciones, verificado, mediante el caso de estudio, la transformacin de una aplicacin escrita en un lenguaje imperativo, no estructurado, a un nuevo lenguaje visual y orientado a objetos, describiendo las diversas fases de la metodologa aplicadas a un caso concreto.
Abstract
Legacy Systems Reengineering has as primary goal to restructure and transform old systems in easier to maintain applications with nicer and more integrated environments that they run in new platforms of hardware/software. We try to give a general view of what is the software reengineering and which are the approaches that can be taken when modernizing a legacy system that has been obsolete as for operability, but of proved efficiency and that maintains its functionality. We show the characteristics of a development process that adapts itself to this type of systems, verified by means of the case of study, the transformation of an application written in an imperative language, no structured, to a new visual and object oriented language, describing the different stages of the methodology applied to a particular case.
DPTOIA-IT-
Tabla de Contenidos
1 Introduccin __________________________________________________________ 1 2 Reingeniera del software ________________________________________________ 2 2.1 Proceso de reingeniera de software ___________________________________ 2 2.2 Fases en la Reingeniera del Software__________________________________ 2 2.3 La traduccin del cdigo fuente ______________________________________ 5 2.4 Ingeniera inversa __________________________________________________ 5 2.5 Mejora de la estructura del programa _________________________________ 6 2.6 Modularizacin del programa________________________________________ 6 2.7 Reingeniera de datos _______________________________________________ 6 2.8 Reingeniera en el mantenimiento______________________________________ 7 3 Metodologa para la reingeniera de sistemas heredados _______________________ 8 4 Caso de estudio _______________________________________________________ 10 4.1 Definicin del problema ____________________________________________ 10 4.2 Estudio del cdigo y viabilidad del producto ___________________________ 10 4.3 Eliminacin de la interfaz de usuario _________________________________ 12 4.4 Mejora de la estructura del programa ________________________________ 12 4.5 Modularizacin del programa y eliminacin de redundancias (Refactorizacin) ________________________________________________________________________ 12 4.6 Traduccin del cdigo mejorado a C _________________________________ 13 4.7 Ingeniera inversa _________________________________________________ 13 4.8 Diseo de la nueva interfaz de usuario ________________________________ 13 4.9 Perfeccionamiento de la aplicacin resultante __________________________ 14 4.10 Integracin de la interfaz de usuario con el cdigo de clculo ____________ 14 5 Conclusiones_________________________________________________________ 14 Referencias_____________________________________________________________ 15
ii
DPTOIA-IT-
Tabla de Figuras
Figura 1. Proceso bsico de reingeniera. _________________________________________________3 Figura 2. Proceso de reingeniera de Sommerville. __________________________________________3 Figura 3. Proceso de ingeniera inversa. __________________________________________________6 Figura 4. Proceso de reingeniera del software. _____________________________________________9 Figura 5. Ejemplo de sentencia GO TO incondicional. ______________________________________11 Figura 6. Ejemplo de cdigo C obtenido. _________________________________________________11 Figura 7. Ejemplo de transformacin de bucle DO. _________________________________________11
DPTOIA-IT-
iii
1 Introduccin
Este trabajo presenta una nueva metodologa de reingeniera del software para remodelar aplicaciones de tipo cientfico (con unas caractersticas concretas), que por diversos motivos presentan la necesidad de tener que actualizarse. La metodologa surge como consecuencia de la aplicacin de procesos de reingeniera del software tradicionales, sobre una aplicacin cientfica de considerables dimensiones y por la no consecucin de buenos resultados mediante esas tcnicas, que en la mayora de los casos cuenta con una probada validez, pero que aplicadas al tipo de aplicacin del caso de estudio no fueron satisfactorias. Se han establecido las pautas a seguir para actualizar aplicaciones que por distintos factores se han quedado obsoletas y por tanto se desean reconvertir a entornos de trabajo actuales. La metodologa se ha utilizado para transformar una aplicacin del rea qumica para el tratamiento de datos cinticos de absorbancia en mezclas. Las causas que motivan una actualizacin en el software pueden ser muy variadas, en este caso venan derivadas por una actualizacin de los equipos sobre los que trabajaba la aplicacin, tanto a nivel hardware como software. Sobre todo a nivel sistema operativo, dejando de lado MS-DOS, que era el sistema sobre el que estaba trabajando. Al tratarse de una aplicacin en modo texto presentaba muchas limitaciones sobre todo relacionadas con la entrada y salida de datos. As, la introduccin de datos se realizaba de forma secuencial, por lo que si se produca algn error en la introduccin de los datos (valores no adecuados, anomalas en los ficheros manejados, errores de formato, ausencia de datos), el programa abortaba. Se trataba por tanto de desarrollar una aplicacin multiplataforma, implementada en un entorno grfico, que incorporara todas las ventajas de estos sistemas: mens, verificacin de datos, ayudas, etc. Pero adems se buscaba que el sistema fuera ms mantenible, estuviera documentado y fuera fcil de ampliar. Se trataba pues, de un sistema legado, en el que era necesario reescribir o reestructurar parte o todo el sistema sin cambiar su funcionalidad. Cuando se trata de una aplicaciones de tamao considerable y de complejidad algortmica, se intenta mantener la mayora de los elementos del software que sean posibles. En nuestro caso no disponamos de muchos de estos elementos, pero siempre que ha sido posible se han utilizado. No contbamos ni con planes de proyecto, ni estimaciones de coste (tampoco en este caso eran necesarias), ni arquitectura, ni especificaciones y modelos de requisitos ni diseos. Contbamos con el cdigo fuente en Fortran, con documentacin de usuario y tcnica, con interfaces humanas, con datos y con casos de prueba. Se ha reutilizado parte del cdigo fuente, se han usado ambos tipos de documentacin que han sido muy importantes. Se han descartado las interfaces humanas ya que era uno de los puntos que haba que mejorar, si bien han servido para comprender la aplicacin y determinar aspectos de funcionamiento. Se han mantenido los datos, ya que era necesario hacer compatible la nueva versin con los ficheros existentes, para poder seguir utilizando muchos de los datos recogidos. Se han utilizado los casos de uso que estaban recogidos junto con la documentacin. Este documento se ha organizado de la siguiente forma: La seccin 2, describe los principales aspectos y fases clsicas de la reingeniera del software. La seccin 3 expone las caractersticas del proceso de reingeniera que hemos desarrollado para sistemas heredados. La seccin 4 analiza el caso de estudio en el que la metodologa ha sido probada, pormenorizando cada una de las fases. Finalmente, en la seccin 5 se presentan las conclusiones.
-1-
lvarez et al.
decir, el proceso de recuperar el diseo del sistema a partir del cdigo fuente para luego volver a aplicar un ciclo de vida de software tradicional. Otros autores lo ven como un proceso de dos pasos, vase la figura 1. El primer paso es comprender el software existente, donde el diseo del sistema se recupera desde su cdigo fuente con actividades como anlisis de dependencias, comprensin del programa, deteccin, extraccin y almacenamiento del diseo. El segundo paso incluye todas las actividades que se realizan para transformar el software existente en un software diferente, ms fcil de mantener, entre ellas estn: descomposicin, reestructuracin, remodularizacin, redocumentacin, etc.
Ingeniera directa
Ingeniera inversa
Informacin recuperada
Software existente
Reestructuracin
Cdigo modificado
Algunos otros trabajos se centran en la reingeniera y la reutilizacin, como [18], donde se expone como construir o retocar el proceso de reingeniera para reutilizar componentes software existentes; otros autores [10], describen una metodologa de reingeniera para reutilizacin, en la cual, integran tcnicas especificas de reutilizacin dentro del proceso de reingeniera haciendo nfasis en componentes.
Programa original
Programa modularizado
Datos originales
Ingeniera inversa
Reingeniera de datos
Programa estructurado
Segn [20], la reingeniera de software comprende: la redocumentacin del sistema, la reorganizacin y reestructura del sistema, la traduccin del sistema a un lenguaje de programacin ms moderno, la modificacin y actualizacin de la estructura y los valores de los
DPTOIA-IT-
datos del sistema. Un posible proceso de reingeniera, ms completo, dado por Sommerville, sera el que se recoge en la figura 2. En el proceso de reingeniera se podran distinguir las siguientes fases: Traduccin del cdigo fuente. El programa se convierte a una versin ms moderna del lenguaje en que estaba codificado o a un lenguaje diferente. Los motivos que llevan a una traduccin pueden ser muy diversos: falta de conocimientos del personal en ese lenguaje, falta de soporte en los compiladores, actualizacin de la plataforma de hardware o de software, polticas de empresa, necesidad de cambio en las interfaces de usuario, etc. El proceso ser econmicamente rentable, si se dispone de alguna herramienta que realice el grueso de la traduccin. En muchos casos, el cdigo que se obtiene tiene que ser modificado de forma manual. Ingeniera inversa. Se analiza el programa y se extrae informacin de l, la cual ayuda a documentar su organizacin y funcionalidad. Es el proceso de analizar el software con el objetivo de recuperar su diseo y especificacin. Lo normal es que la entrada a este proceso sea el cdigo fuente si se dispone de l. Se alterna el anlisis utilizando herramientas automatizadas con el trabajo manual en el cdigo fuente para obtener el diseo del sistema. La informacin obtenida suele almacenarse como grafo dirigido, que se va modificando y completando. A partir del grafo se generarn otros documentos como diagramas de estructura de programas, diagramas de estructura de datos y matrices de trazabilidad. Las herramientas que se utilizan para comprender el programa suelen ser de tipo navegadores, que permiten moverse por el cdigo, definir unos datos y rastrearlos por el programa. Suelen ser necesarias anotaciones manuales. En [12] se hace un estudio de 5 herramientas de este tipo (cflow, CIA, field, mkfuncmap, rigiparse). Mejora de la estructura del programa. Se analiza y modifica la estructura de control del programa para hacerlo ms fcil de leer y comprender. Los programas pueden presentar lgica de control no intuitiva lo que puede hacer que no se entiendan fcilmente. El principal factor a tener en cuenta es que el control sea estructurado. Modularizacin del programa. Es el proceso de reorganizar un programa de forma que partes relacionadas se integren de forma conjunta. Esto facilita eliminar componentes y mejorar la comprensin. Se pueden considerar diferentes tipos de mdulos: abstracciones de datos, mdulos de hardware, mdulos funcionales, mdulos de apoyo al proceso, etc. Reingeniera de datos. Se trata de analizar y reorganizar las estructuras, e incluso a veces, los valores de los datos de un sistema para hacerlos ms comprensibles. Si la funcionalidad del sistema no cambia, la reingeniera de datos no es necesaria. No son fases que tengan que desarrollarse todas necesariamente, sino que dependiendo de los casos podrn figurar unas u otras. Otros autores [19] desarrollan un modelo de reingeniera del Software que sita al usuario como colaborador principal en la tarea de especificar los requisitos del sistema. Las fases, en este caso seran: Definicin del problema. Se identifican objetivos, lmites, beneficios, riesgos, estimaciones de tiempos, etc., estableciendo una imagen real de lo que existe realmente ahora y lo que se quiere obtener en el futuro. Estudio del cdigo antiguo. Partiendo del cdigo fuente en un lenguaje de tercera generacin, se obtiene un conjunto de documentos que ayudan a posteriores fases de la metodologa.
DPTOIA-IT-
lvarez et al.
Viabilidad del proyecto. Consiste en detectar posibles errores en las especificaciones. Rediseo de especificaciones. Se busca conseguir, que las especificaciones representen de forma real la visin futura deseada del sistema. Creacin de prototipos. De aquellas partes que puedan dar problemas, o solamente de aquellas que vayan a cambiar sustancialmente de la original. Planificacin de la implementacin. Consiste en disear la forma y modo en que se va a migrar de una herramienta a otra. Perfeccionamiento. Realizar cambios en la nueva aplicacin que aumenten la calidad del sistema.
DPTOIA-IT-
Anlisis automatizado
Generacin de documentos
Matrices de rastreabilidad
DPTOIA-IT-
lvarez et al.
programadores hicieron en su da y que con el transcurso del tiempo se han ido alcanzando esos lmites), o la evolucin arquitectnica. Antes de llevar a cabo la reingeniera de datos es necesario analizar los programas que utilizan los datos. Con este anlisis se pretende descubrir la funcin de los identificadores en el programa, encontrar los valores de los literales a reemplazar por constantes con nombre, descubrir reglas internas de validacin de datos y conversiones de representaciones de datos.
DPTOIA-IT-
provoca un incremento en el tiempo de compresin de los programas y una documentacin desfasada. Los sistemas mantenidos son cada vez ms difciles de cambiar. Debido a estos problemas, se producen una serie de efectos secundarios sobre el cdigo, los datos y la documentacin, como por ejemplo: modificacin o eliminacin de subprogramas, etiquetas o identificadores, modificacin de los formatos de registros o archivos, modificacin de definicin de variable globales, nuevos mensajes de error no documentados o modificacin de las interfaces de usuario. Las soluciones al problema del mantenimiento se pueden dividir en dos grupos: soluciones de gestin y soluciones tcnicas (stas ltimas son de dos tipos: herramientas y mtodos). Las herramientas sirven para soportar de forma efectiva los mtodos, algunas de ellas son: formateador, analizador sintctico, estructurador, documentador, depurador interactivo, generador de datos de prueba y comparador. Los principales mtodos seran: Reingeniera, examen y modificacin del sistema para reconstruirlo en una nueva forma. Ingeniera inversa, anlisis de un sistema para identificar sus componentes y las relaciones entre ellos, as como para crear representaciones del sistema en otra forma o en un nivel de abstraccin ms elevado. Reestructuracin de software, consiste en la modificacin del software para hacerlo ms fcil de entender y cambiar o menos susceptible de incluir errores en cambios posteriores. Transformacin de programas, tcnica formal de transformacin de programas.
DPTOIA-IT-
lvarez et al.
<<fsico>> documentacin
Ingeniera inversa
Perfeccionamiento
El siguiente paso sera la integracin de la interfaz de usuario en Java con las funciones que soportan el clculo matemtico en C. Aunque otra posibilidad aceptable habra sido realizar
DPTOIA-IT-
todo el desarrollo en C o C++. Por ltimo, vendra una fase de perfeccionamiento del programa para depurarlo y comprobar con resultados reales su validez.
4 Caso de estudio
El proceso de reingeniera se ha llevado a cabo sobre una aplicacin cientfica que realiza la computacin de datos cinticos de absorbancia total de una mezcla monitorizada a multilongitud de onda. Permite la determinacin de forma individual o conjunta de la concentracin de una mezcla multicomponente y de las constantes de velocidad. Adems, puede discriminar entre diferentes mecanismos de reaccin, realizando la eleccin del que mejor represente los datos experimentales. Realiza de forma automtica el tratamiento de una serie de modelos de reaccin, los ms frecuentes, si bien el usuario puede proporcionar nuevos modelos, facilitando las caractersticas de los nuevos modelos. La aplicacin estaba desarrollada para MS-DOS, escrita en lenguaje de programacin Fortran 77, compilada en su da con SVS C3 (Silicon Valley Software) y consista en un programa principal, junto con una serie de subrutinas encargadas de llevar a cabo los diferentes tratamientos y clculos necesarios para realizar el proceso de optimizacin mediante el algoritmo AGDC [11]. Contaba, en total, con unas 10100 lneas de cdigo. La aplicacin final obtenida mediante el proceso de reingeniera, mantiene su funcionalidad original. Cuenta con una interfaz de usuario escrita en Java, y una serie de subprogramas escritos en lenguaje C, a los que se accede mediante la Interfaz de programacin JNI (Java Native Interface).
DPTOIA-IT-
10
lvarez et al.
bucles eran del nico tipo posible DO. Al intentar traducir de forma automtica una sentencia GO TO incondicional, se obtena una sentencia del mismo tipo pero en C, lo que no se poda permitir, vanse las figuras 5 y 6.
IF(IEL.EQ.2) THEN WRITE(*,502) WRITE(*,511) 511 FORMAT(/10X" ** OPTIMIZACION DE CONCENTRACIONES INICIALES A0 **") WRITE(*,502) GO TO 2600 END IF Figura 5. Ejemplo de sentencia GO TO incondicional.
El caso de los bucles DO que utilizan una etiqueta final para marcar la salida, eran transformados correctamente en un bucle FOR en C, eliminando la etiqueta, vase figura 7. Con la primera traduccin realizada se pudo verificar que el cdigo generado no era vlido, su tamao incluso se disparaba, pero los resultados de los clculos que se obtenan se aproximaban bastante a los de la versin Fortran. Esto nos hizo tener que replantear las fases del desarrollo, debamos primero simplificar y estructurar la aplicacin, incluso separando la parte correspondiente a la interfaz de usuario, para ms tarde obtener el cdigo C.
if (iel == 2) { s_wsfe(&io___268); e_wsfe(); s_wsfe(&io___269); e_wsfe(); s_wsfe(&io___270); e_wsfe(); goto L2600; } Figura 6. Ejemplo de cdigo C obtenido.
i__1 = ncomp; for (i__ = nc + 1; i__ <= i__1; ++i__) { s_rsfe(&io___317); do_fio(&c__1,(char *)&ai[i__ - 1], ftnlen)sizeof(doublereal)); e_rsfe(); }
Otra particularidad que tena el cdigo era la de la utilizacin de gran cantidad de cdigos de formato de entrada/salida especficos de Fortran, del tipo: 250 FORMAT(G20.8) 280 FORMAT(10G10.8) Que indicaban el tipo de los datos a leer o escribir; as el primero de ellos significara que los valores iban a ser real General, 20 sera la anchura total del campo, que correspondera al signo
11
DPTOIA-IT-
de la mantisa, el dgito que precede al punto decimal, el punto decimal, la mantisa y el exponente; 8 correspondera al nmero de dgitos que tiene la mantisa. En el segundo caso el 10 indicara que se va a repetir 10 veces el cdigo G. Al chequear el programa con otros compiladores de Fortran tambin se detect que haba una serie de variables declaradas que no se utilizaban, posiblemente utilizadas como pruebas antes de la versin definitiva. Con la primera traduccin realizada se pudo verificar que el cdigo generado no era vlido, su tamao incluso se disparaba, pero los resultados de los clculos que se obtenan se aproximaban bastante a los de la versin Fortran. Esto hizo tener que replantear las fases del desarrollo, debiendo primero simplificar y estructurar la aplicacin, incluso separando la parte correspondiente a la interfaz de usuario, para ms tarde obtener el cdigo C. Lo importante fue constatar que el proyecto era viable.
DPTOIA-IT-
12
lvarez et al.
13
DPTOIA-IT-
modelo y tipo de optimizacin seleccionado, el diseo de la misma en un lenguaje de programacin orientado a objetos no fue sencillo [5]; Al implementar una nueva interfaz de usuario se solucionaron problemas que tena la antigua interfaz como dejar introducir valores no vlidos, u opciones no factibles en momentos determinados.
5 Conclusiones
La reingeniera del software ha sido y es un tema muy importante para muchas empresas y organismos que tienen que seguir manteniendo sus aplicaciones porque sus desarrollos han sido costosos y adaptados a sus necesidades, lo que en muchos casos hace que no existan aplicaciones comerciales similares. El inconveniente es que estos sistemas con el paso de los aos presentan un aspecto obsoleto, mostrando pantallas y diseos ya descartados, en definitiva interfaces de usuario que no son operativas y que se han superado ampliamente. Por otra parte, en muchos casos no pueden adaptarse a los avances del hardware, porque estos nuevos equipos incorporan sistemas operativos para los que no fueron pensados los sistemas legados. Existen diferentes metodologas de desarrollo que abordan esta problemtica, algunas de ellas especficas para determinados aspectos, como recuperar el diseo, desarrollar la documentacin perdida, o convertir un cdigo a un lenguaje orientado a objetos. Nuestro proceso de desarrollo trata de mantener la funcionalidad del sistema, manteniendo los datos, pero utilizando un nuevo cdigo en un lenguaje orientado a objetos, por tanto, ya estructurado, con una interfaz de usuario totalmente nueva, que dote a las aplicaciones de un aire de modernidad y que, por tanto, facilite su utilizacin por parte del usuario final. Adems, aade nuevas especificaciones con su correspondiente documentacin, lo que permitir la ampliacin del sistema. Aunque la tendencia en la mayora de las metodologas para la reingeniera del software es buscar una completa automatizacin de los procesos, es muy difcil que todas las fases puedan abordarse sin la intervencin humana. El conocimiento de expertos, hoy da se hace an imprescindible, aunque slo sea en determinados momentos de las metodologas o para aportar sus ideas en el desarrollo de determinadas herramientas. En nuestro proceso de desarrollo hemos utilizado herramientas cuando ha sido posible, porque facilitan la labor, podra ser
DPTOIA-IT-
14
lvarez et al.
interesante el desarrollo de nuevas herramientas que se adapten mejor a las necesidades y una formalizacin del proceso integrando las herramientas. Una ventaja de esta metodologa es que algunas de sus fases pueden llevarse a cabo en paralelo, como se aprecia fcilmente en la figura 1. Esto hace, por una parte, que puedan ser abordadas por diferentes equipos humanos, incluso pertenecientes a distintas reas de especializacin y, por otra parte, al solaparse las fases, que se reduzca el tiempo de desarrollo del proyecto. Otra ventaja es que se adapta a dominios cientficos, en los que el tiempo de procesamiento es importante y est claramente diferenciada la interfaz de usuario del procesamiento y la obtencin de resultados.
Referencias
1. Arnold, R.S.: Software Reengineering. IEEE Computer Society Press, 1993. 2. Beck, J. and Eichmann, D.: Program and interface slicing for reverse engineering. In R.C. Waters and E.J. Chikosfsky, editors, Working Conference on Reverse Engineering, IEEE Computer Society Press. 1993, 54-63. 3. Biggerstaff T. and Perlis A.: Software Reusability. Addison-Wesley. November, 1990. 4. Chikofsky, E.J. and Cross, J.H.: Reverse engineering and design recovery: A taxonomy. IEEE Software. 7(1), 1990, 13-17. 5. Gall, H. and Klsch. R.: Finding Objects in Procedural Programs: An Alternative Approach. In Proceeding of the Second Working Conference on Reverse Engineering, Toronto, Canada. IEEE Computer Society Press, July 1995. 208-216. 6. Gall, H., Klsch, R., Mittermeir, R.: Object-Oriented re-architecturing. 5th European Software Engineering Conference (ESEC95), September 1995, Sitges, Spain,. Lecture Notes in Computer Science 989, 1995, 499-519. 7. Jacobson, I., Lindstrm, F.: Re-engineering of old system to an object-oriented architecture. ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages and Applications, Phoenix, Arizona, October 1991, 340-350. 8. Jones, C.: The economics of Object-Oriented Software, American Programmer, vol. 7, n 10, October 1994, 2835. 9. Landis L.D.; Hyland, P.M.; Gilbert, A.L. and Fine, A.J.: Documentation in a software maintenance environment. In Proceeding of the IEEE Conference on Software Maintenance. IEEE Computer Society 1998, 66-73. 10. Linos, P.K., Molterer S., Paech B. and Salzmann C.: Re-engineering for Reuse: Integrating reuse techniques into the reengineering process. Technical report TUM-INFO-11-I9824-100 Intitut Fr Informatik, Technische Universitt Mnchen, 1998. 11. Moreno, M.N., Gonzlez, J.L., Arco M.A. and Casado, J.: Determination of macroscopic thermodynamic ionization constants at variable ionic strenght by an optimization algorithm. Computers and Chemistry, 14, 1990, 165-168. 12. Murphy G. C., Notkin D. and Lan E.S.: An empirical study of static call graph extractors. Technical Report 95-08-01, Department of Computer Science and Engineering, University of Washington. 1995. 13. Piattini, M., Villalba, J., Ruiz, F., Bastanchury, T., Polo, M., Martnez, M.A. y Nistal, C.: Mantenimiento del software: Modelos, tcnicas y mtodos para la gestin del cambio. Rama, noviembre de 2000. 14. Postema M. and Schimidt, H.W.: Reverse Engineering and Abstraction of Legacy Systems. Informatica: An International Journal of Computing and Informatics. Vol 22 n 3, 1998, 359-371. 15. Pressman, R.S.: Software Engineering: A Practitioners Approach. Fifth Edition. McGrawHill. 2001.
15
DPTOIA-IT-
16. Rugaber, S. and Clayton, R.: The representation problem in reverse engineering. In Proceedings of the working Conference in Reverse Engineering, Baltimore, Maryland. IEEE Computer Society, May 1993. 8-16. 17. Rugaber, S. and Will L.M.: Creating a research infrastructure for reengineering. In 3rd Working Conference on Reverse Engineering. IEEE Computer Society Press, september 1996, 120-130. 18. Sametinger, J.: Software engineering with reusable components, Springer-Verlag, 1997. 19. SICUMA, Grupo. Leiva, J.: Construccin de especificaciones de interfaces en un proceso de reingeniera, en: 2da. Conferencia Iberoamericana en Sistemas, Ciberntica e Informtica CISCI 2003, Orlando (Florida)-EEUU. 20. Sommerville, I.: Software Engineering. Sixth edition. Addison Wesley, 2001. 21. Ulrich, W. M.: The evolutionary growth of software reengineering and the decade ahead. American Programmer, 3(10), 1990,14-20. 22. Weiser M.: Program Slicing. In IEEE Transactions on Software Engineering, IEEE Computer Society, July 1984, 352-357.
DPTOIA-IT-
16