Centro Nacional de Investigación y Desarrollo ... - CENIDET · 2.1.2 Reestructura de código legado C en C++ 2.1.3 Extracción automática de clases de sistemas legados .. 2.1.4

SEP SElT DGlT

Centro Nacional de Investigación

y Desarrollo Tecnológico

cenidet

FACTORIZACIÓN DE FUNCIONES HACIA MÉTODOS DE PLANTILLA

TESIS Que para obtener el grado de

Maestro en Ciencias en Ciencias Computacionalec

Presenta

Laura Alicia Hernández Moreno

Director de la tesis: M.C. René Santaolaya Salgado

Co-Director de la tesis: -0 3 - o o 1 8 ..-

Cuernavaca, Morelos Febrero del 2003

SEP SElT DGlT

Centro Nacional de Investigación y Desarrollo Tecnológico

cenidet FACTORIZACIÓN DE FUNCIONES HACIA

MÉTODOS DE PLANTILLA*

TESIS Que para obtener el grado de

Maestro en Ciencias en Ciencias Computacionales

Presenta


Director de la tesis:

M.C. René Santaolaya Salgado

Co-Director de la tesis: M.C. Olivia G. Fragoso Diaz

Cuernavaca, Morelos Febrero del 2003 ~

'"Esta tesis es parte del proyecto No. 32042-A "Sistema de Administración de Componentes de Software Basado en Frameworks" financiado por CONACYT. y el proyecto No. 450.01-P "SR2: Sistema de Reingenieria para Reuso" financiado por COSNET.

Cuemavaca, Mor., a 17 de Febrero de 2003.

Dr. Gerard0 Reyes Salgado Presidente de fa Academia de Cienciac €ompuia&nales Presente

Nos es @o eomuntmrle, que confamie a los Iineamientas pafala obtenctón det grado de Maestro en Ciencias de este centro, y después de haber sometido a revisión académica la tesis denominada. "FACTOREACIÓN DE FUNCK)NES HACiA WrÉroDOS DE PLANTILLA", Barizada por h C. Laura Alicia Hemández Maceno, y habiendo cumplido con todas las correcCones que le fueron indicadas, acordamos no tener objeción para que se le conceda la autorización de impresión de la tesis

Sin otro partidar, quedamos de usted.

Atentamente-

La comisión de revisión de tesis

I4 6u.iL-0- . M C MARIO GUtLLEN RODRIGUEZ M C. REYNALDO ALANIS CANTU

Director De Tesis

M C OLiVlA FRA-GOSO EIAZ Co-director de tesis

C.C.P. Dr. Rodolfo A. Pazos RangeüJefe del Depto. de Ciencjas Computgcionates

INTERIOR INTERNADO PALMIRA S/N. COL, PALMIRA , A.P. 5-164. CP. 62490, CUERNAVACA, MOR. - M t X I C O TELS. 1777) 312 23 14.318 77 41. FAX (777) 312 24 34 EMAIL [email protected]

FORMA C4 AUTOREACION DE IMPRESIÓN DE TESIS

Cuernavaca, Mor., a 17 &Febrerode 2003

C. Laura Alicia Hemández Moreno Candidato al grado de Maestro en CmQas en Ciencias Computacionales Presente

Después de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia Ciencias Computacionales en relación a su trabajo de tesis: "FACTORIZACION DE FUNCIONES HACIA METODOS DE PLANTILLA"., me es grato m i c a r i e , que conforme- a los linearnientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda amla it-ftpr- de su tesis.

Atentamente

Dr. Rodoifo &ham PAos Rangel Jefe del üepto. de Ciencias ComputacEonaies

INTERIOR INTERNADO PALMIRA S/N, COL, PALMIRA . A.P. 5-164. CP. 62490, CUERNAVACA. MOR. - MEXICO TELS. (777) 312 23 14.318 77 41, FAX (777) 3F2 24 34 EMAlL [email protected]

W u y cerca de mi ocaso yo fe bendgo, Vida,

porque nunca me &fe ni esperanza fallda

ni lrabajos iymtos, ni pena inmerecida.

Torque oeo al jnal ¿e mi largo camino

que f i i yo el arquifecfo de mi propio des fino

que si extraje la miel o la hiel de los cosas

' fue porque en ella puse hiel o mieles sabrosas;

cuando plan fé rosales. coseché siempre rosa2

cieno, a mis lozanias DB a seguir el inoiemo

i3a?tis iú no me @de que mayo fuera eferno!

%alle sin duda largas las noches de mis penas

mcis no me promer'ísfe fu, solo noches buenas

y en cambio fuoe algunas sanfamenfe serenm

Smé. fui amado, el sol acaricio mi faz

j Vida, nada me debes. oída, esfarnos en paz!

%nado Weroo

&iura a;5cia pemrjndez Woreno

Febrero ¿el 2003

9 9ios por darme Is dicha de oioir y

permiiime dia a dio dar un nueoo paso.

mi madre por ser iodo para mí por todo lo que hemos oioido y pasado junim

3aluchas gracias mamá.

T e Quiero %ucho.

9 dos personas especiales que siempre esiarán en mi corazón.. CraciaJ

3ali abuelo Ymnenegildo'

q o n WanueP

8uan 5;8bnd mi nooio, por miar iodo este tiempo a mi lado incondcionahenfe

y por ser la persona con quien quiero compadir el resto ¿e mi oida. T e 9mo.

5i&p¿ecirníen fos

9 C&J%&(Tpor aceptarme como becan0 dentro de su programa “C8pacifación ¿e jODenes hacia el posgrado

9 C & W C i ) & T p o r abrirme sus puerta

a diloia &¡no ‘Tuenlar que sin conocerme inicia/mente, me ha dado su conjanza y R quien considero mi amiga

9 mis drectoras de tesis el %C %ne c

1

Índice

índice de Tablas ...........................................................................................

lndice de Figuras ........................................................................................................

Capítulo 1. INTRODUCCION ...................................................................................... 1 .I Descripcion del problema .__.___........ ... .......................................... 1.2 SR2: Reingeniería de software legado par

. .,

1.2.1 Objetivo ... 1.2.2 Modelo de referencia ...

1.2.2.1 Proceso de análisis 1.2.2.2 Proceso de reestructura del código original _....,.____._......._.____.... 1.2.2.3 Proceso de refactorización .................................................

1.3 Objetivo de la tesis ................................................................................................. 1.4 Beneficios de la tesis .... 1.5 Justificacion del estudio ............................................................................... 1.6 Límites y alcances del estudio. 1.7 Organización de esta tesis ._...._..._.._.._,.._____....

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , . . . . . . . . . , . . . ..

. . . . . , . . . . . . . . . . . . . , . . . . . . . . , . . , . . . . , . . , . . . . . . . . , , . . . . , . . . . . . . , . . . . . . . . . . . . . . . . .

.. II

2.1.7 SPRUCE: Un framework para reestructurar software ............................. 24

2.2 Análisis comparativo de los trabajos relacionados con respecto a esta tesis ............................................................................................................... 26

Capítulo 3. MARCO TEORICO .................................................................................. 3.1 Factorización ........................ 3.2 Programación por procedimientos en lenguaje C .............

3.3 Análisis e ingeniería de dominios .......................................

. . . . . . . . . . . , , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.7 Software legado _._._ . . . . . . . . . . . . . . . . . . , . . . . , , . . 3.4 Patrones de diseño .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , . . . . . . . . . . . . . . .

3.4.1 Template Method ......................................................................................... 3.4.2 Factory Method .....,. . . . . . . . . . . . . . . , . . . . . . . . . . . . , . 3.4.3 Decorator

3.5 Arquitectura de software basada en componentes _..__...._........._._._ 3.5.1 Programación orient

3.5.2 Reuso de

3.5.3 Componente _.___....,. 3.5.4 Framework o marco de componentes reusables ._..,.,.

3.6 Meta-Lenguaje ANTLR .........

3.5.1.1 Lenguaje de programación C++

Capítulo 4. DESCRIPCIÓN DE LOS MÉTODOS DESARROLLADOS ...................... 4.1 Proceso de análisis de código fuente ._._....__.._.___..,.___..... . . . . . . . . . . , . . . . . . . . . . . . . .

4.1 .I Identificación de operaciones y atributos ...__..__.__......___._. 4.1.1.1 Tipos de datos estructurados.. . . . . . . . . . , , . , . . . . . . . . . . . . 4.1 .I .2 Variables o datos globale 4.1.1.3 Funciones.

4.1.2 Identificación de relaciones ____._....,....____.._...... 4.1.2.1 Funciones - Datos Globales 4.1.2.2 Datos locales por función ..................................................... 4.1.2.3 Funciones - Parámetros ..........

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , , . . . .

. . . . . . . . . . . . . . . . . . . . . . . 4.2 Proceso de reestructura de software le

33

34

34

36

38

38

43

47

51

54

55

57

58

58

59

60

61

62

66

67 69

71

73

73

75

77

79

... 111

4.2.1 Método de creación de clases ...... ......................................

4.2.1.1 Conversión de tipos de datos estructurados a clases de objetos ................................. ....

4.2.1.2 Conversión de datos globales a clases de objetos ................... 4.2.1.3 Conversión de funciones a clases de objetos ...........................

4.2.2 Método de declaración de constructores ............. ............................. 4.2.3 Método de composición de clases .......................................................... 4.2.4 Método de reubicación de funciones ...................................................... 4.2.5 Método de fragmentación de funciones .................................................. 4.2.6 Método de superjerarquizar .... ........... ................. 4.2.7 Método de fábrica de objetos ..........................................................

4.3 Diagrama de clases que integran hasta ahora el sistema SR2 ........................... 4.4 Diagrama de clases que componen al proceso de reestructura ....

79

80 84 86 88 90 92 94 95 98

102 103

Capítulo 5 . CONCLUSIONES .................................................................................. 5.1 Trabajos futuros .................................................................................................... 108

105

Bibliografia ................................................................................................................. 115 Anexos ........................................................................................................................ 119

iv

Índice de Figuras

Figura 1.1. Estructura de un programa ejemplo escrito bajo el paradigma de procedimientos .................................. ..

Figura 4.10. Estructura de clases que se tienen cuando se identifican

datos candidatos a aplicar el método de superjerarquizar ............._... 97 Figura 4.11. Representación tipica de una fábrica de objetos obtenida

a partir de la figura 4.2 .................................................................... 101

vi

índice de Tablas

Tabla 2.1. Tabla comparativa de los trabajos relacionados contra esta tesis .............. Tabla 3.1. Categorias en las que se dividen los patrones de diseño ...........................

Tabla 4.1 Estructura de la tabla UDTs .................................................................

Tabla 4.2 Estructura de la tabla UDTxCC ....................................................................

Tabla 4.3 Estructura de la tabla DGs ...........................................................................

Tabla 4.4 Estructura de la tabla Fs ...............................................................................

Tabla 4.5 Estructura de la tabla FFxDG ...................................................................

Tabla 4.6 Estructura de la tabla FFxUDTxCC ...........................................................

Tabla 4.7 Estructura de la tabla DLs ..........................................................................

Tabla 4.8 Estructura de la tabla ParF ...........................................................................

Tabla 5.1. Diseño de una tabla de información que puede ser de

utilidad para aplicar la fragmentación ..........................................................

32

42

68

68

70

72

74

74

76

78

110

Cauítulo 1 introducción

traves del tiempo nos hemos dado cuenta que la complejidad de los sistemas informáticos ha aumentado en forma impresionante, hasta el punto que el hecho de

dar mantenimiento a estos sistemas es muy difícil y en muchos casos hasta imposible; esto dio comienzo a la crisis del software [PRE93]. Esta crisis se debe principalmente a la

acumulación de productos desarrollados que no son reusados, a los altos costos de

mantenimiento que implican los sistemas y a los costos de invención de nuevas

aplicaciones


A . ' .

1 Cenidet 2003

Capítulo 1 introducción

I¡

De acuerdo a nuestra experiencia por haber laborado en una de las fábricas de

software de México[SOFWW] e información preliminar[MCC94, MCC94b, MCC951, las

diversas empresas que producen software en nuestro país y en otros países, empezaron

con el desarrollo de sistemas pequeños. Algunas.empresas han desertado y las que aún

permanecen con el tiempo ha crecido su número de clientes y la complejidad de sus

sistemas, lo cual ha venido .obligando a la adopción de procesos de desarrollo más o

menos formales por parte de las diversas empresas. C ello, cada empresa adoptó los

procesos de desarrollo basandose en su experiencia y en sus necesidades. La forma de los ciclos de desarrollo de sistemas obedecía más bien a la naturaleza de los clientes, al nicho del mercado y al tamaño de los sistemas, pero no a un proceso de desarrollo estandarizado que garantizara la confiabilidad o el éxito en los productos emitidos.

!I

11 . ’

Los paradigmas para la construcción de software como una herramienta dentro de la ingeniería de software se han venido considerando como la solución al así llamado

“problema de software” o “crisis del software’’ [UDE94] que aun permanece con nosotros.

“Durante muchos años se ha visto al reuso como una de las técnicas más

importante para,dar solución al problema de costo’y esfuerzo que radica en el desarrollo y

administración .. de los sistemas de información. El término reuso se ha tratado de frabajar

en conjunto concada uno de los paradigmas de programación que han ido apareciendo. Sin embargo, en la actualidad no se ha logrado establecer en totalidad que la producción

de sistemas de información se haga bajo una política de reuso, como un modelo de

reingenieria” [SANOZ]. “Hoy en dia, han emergido nuevas tecnologías como: el análisis e ingeniería de

dominios; herramientas CASE; modelos de referencia para el ciclo de vida del software, modelos de arquitecturas de software sustentadas en tecnologías de análisis, diserio y programación orientada a objetos; patrones de diseño; y marcos de componentes de software para reuso. Como se puede observar las tecnologías mencionadas ofrecen

soporte para dar un nuevo impulso al desarrollo de herramientas que apoyen al reuso”

#,

[SANOZ]. ‘i “Para agregar madurez al proceso de desarrollo de sistemas [AHRSS], una meta

actual de la lngenieria de Soffware es la de otorgar facilidades en los procesos por medio de la adopción de ambientes de desarrollo que integren herramientas automatizadas, visuales e interactivas, para construir, entender, mantener y documentar el software,

2 Laura Alicia Hernández Moreno Cenidet 2003

Capítulo 1 introducción

conduciendo a una mejor calidad y contabilidad de los servicios de cómputo, así como a

una más grande satisfacción de/ cliente” [SAN02]. En esta tesis se presenta una estrategia base, que parte de la reingenieria inicial

de código que ha sido desarrollado y que aun sobrevive en algunas empresas. La

estrategia se basa en la ampliación de su tiempo de vida útil, por medio de su recuperación y transformación, a través de un proceso de reestructura. El desarrollo que

aqui se presenta toma código legado escrito bajo el modelo de procedimientos en

lenguaje de programación C y lo transforma en arquitecturas de componentes reusables

para aplicaciones orientadas a objetos escritos en lenguaje de programación C++. Cada vez es más frecuente que la arquitectura que exhibe un marco de este tipo

incorpore patrones de diseño en su estructura. Por lo que el enfoque que se le da a esta tesis es la de incorporar patrones de diseño a la arquitectura del código resultante del

proceso de reingenieria de software legado para reuso.

1 .I Descripción del problema Construir marcos de componentes reusables de dominios específicos a partir del

software legado, mediante procesos de ingeniería inversa y10 reingenieria, puede resultar

una estrategia aceptable. Sin embargo, a la fecha, relativamente poco esfuerzo se h a

invertido en trabajos de investigación enfocados a buscar formas para extender el tiempo

de vida útil de a plicaciones I egadas existentes. Por I o q ue, aún n o e xisten sistemas o

herramientas a decuadas q ue permitan transformar I a a rquitectura d e sistemas legados instrumentados en lenguajes de procedimientos, hacia arquitecturas o marcos reusables de aplicaciones orientadas a objetos, que permitan la maduración de dominios

especificoc de aplicaciones.

En apoyo a la solución de este problema, en el CENIDET se está desarrollando una herramienta conocida como SR2 (Reingenieria de Software Legado para Reuso), que

permite transformar código legado por procedimientos a marcos de componentes

reusables. con el objetivo de poder reusar el software existente de dominios de

aplicaciones en nuevos desarrollos de software del mismo dominio (Véase sección 1.2).

Una de las etapas iniciales de la herramienta mencionada en el párrafo anterior consiste en el análisis del código fuente escrito en lenguaje C y en la identificación y


Capítulo 1 ' Introducción

extracción de la información necesaria que sirva para construir frameworks de dominios

de aplicación orientados a objetos.

En general el SR2, incorpora los procesos'ide preprocesamiento, análisis de código fuente, reestructura a través de patrones de diseño (State, Strategy), reestructura de

datos (variables y funciones) y un proceso de refactorización. De los procesos descritos,

en esta tesis se'desarrollo el método de reestructura de datos, el cual ataca el problema

que a continuación se describe.

1

En la figura 1.1, se muestra la estructura de un programa ejemplo escrito bajo el

paradigma de procedimientos, a partir de la cual mostraremos el problema a resolver.

Programa Ejemplo

Variables Globajes: Varl Var2 Var3 Var4

Funciones: F1() /I Accede Varl ,VaR F2() /I Accede Varl ,Var3 F3() /I Accede YaR, Var3 F4() /I Accede Var l a Var4

I

Figura 1 .I. Estructura de un programa ejemplo escrito bajo el paradigma de procedimientos.

'!

Podemos ver en la figura que un programa procedural puede estar compuesto de

variables globales y funciones, en donde las funciones pueden acceder a una, varias o a todas las variables globales dando por consiguiente un nivel de anidamiento que no es

factible si se desea hacer reuso de alguna de las funciones existentes de ese programa o de la aplicación en general.

't

4 Laura Alicia Hernández Moreno Cenidet 2003 ,I

CaDítulo 1 Introducción ~~

Una forma rápida en la que se puede pensar para reusar las funciones que existen

en un programa procedural, sería que cada función que este definida en un programa sea

una clase, como se muestra en la figura 1.2.

ClaseFl ClaceF4

Var3 Var4

F40

Figura 1.2. Creación de clases por funciones.

Se puede observar que esta forma no es la más apropiada para obtener una

arquitectura de clases ya que existiría la duplicación de variables en mas de una clase, lo

cual es un factor importante que debe considerarse para su buen funcionamiento, ya que

si una variable fue afectada en su valor al estar en una clase, dicho valor puede ser utilizado en una función subsecuente que se encuentre.

El problema que se resuelve en esta tesis, consiste en reducir en lo mayor posible el nivel de anidamiento que se puede presentar en un programa empleando una herramienta de reestructura de software, que nos permite incorporar datos especificos en

clases especificas. Los métodos de reestructura que componen a la herramienta desarrollada en este trabajo de tesis, se describen detalladamente en el capitulo 4.

1.2 SR2: Reingeniería de software legado para reuso El trabajo de tesis que en este documento se describe tiene su base sobre la

herramienta SR2. En las subceccionec 1.2.1 y 1.2.2 se presentan el objetivo y una descripción breve del modelo de referencia, los cuales fueron planteados por el M.C. René Santaolaya Salgado el cual es candidato a obtener el grado de Doctor en Ciencias

de la Computación por el Centro de Investigación en Computación del Instituto Politécnico

5 Laura Alicia Hernandez Moreno Cenidet 2003

Capítulo 1 Introducción

Nacional. Los secciones siguientes fueron estructuradas tomando puntos de referencia de [SAN02]. ' ' II

1.2.1 Objetivo El objetivo de SR2, es organizar el software legado, desarrollado bajo el

paradigma de programación por procedimientos, en lenguaje de programación "C",

para Su reuso en futuras aplicaciones del mismo dominio. Con el propósito de tener

beneficios en cuanto a la productividad de los programadores, de la calidad de los sistemas de software desarrollados y para un mejor enfrentamiento a la complejidad

de los actuales sistemas de software.

El enfoque que se ha dado al proyecto SR2 para el logro de este objetivo, consiste en diseñar y proponer un modelo de referencia que sirva de guia para

cambiar la arquitectura de sistemas existentes, escritos en lenguajes de

procedimientos, hacia una arquitectura orientada a objetos (utilizando C++), y un sistema de reingenieria basado en este modelo, con el propósito de construir marcos

reusables de aplicaciones orientadas a objetos &e dominios.

. < , . li 1.2.2 Modelo de referencia ' . El modelo de referencia de SR2 (Reingenieria de Software Legado para Reuso)

considera tres aspectos importantes (Véase figura 1.3), análisis de código fuente, reestructura del código fuente, y refactorización'del marco de aplicaciones orientado a

objetos obtenido para cada dominio. El sistema de reingeniería (SR2) incorpora tecnologias modernas tales como

reconocimiento de patrones, de código para la fase de análisis, arquitecturas

orientadas a objetos y patrones de diseño para los procesos de reestructura, y refactorización para el control de la evolución y aumento de la vida Útil del software.

II



de Dams

(. . L Se hace uso de:

( a Paimnes dediseño 1 2. .

Figura 1.3. Modelo de referencia de SR2 (Reingeniería de Software

Legado para Reuso).

1.2.2.1 Proceso de análisis de código fuente En este proceso se explora el código fuente, en el que se trata de identificar los

siguientes requerimientos:

1. La identificación de atributos y operaciones que sirven de referencia para ia creación de clases de objetos, tales como:

P Identificación de UDTs (tipos de datos estructurados). P DGs (datos globales). P DLs (datos locales).

Laura Alicia Hernández Moreno 7

Cenidet 2003

Capítulo I Introducción

P Par (parámetros). 9 Fs (funciones),

P Patrones de comportamiento de los patrones de diseño State y Strategy[GAM95], entre otros.

2. La identificación de relaciones'entre las entidades del sistema, es decir, relaciones de: 9 Agregación o asociación. 9 Generalización-especialización. :/)

I/'

> Creación de instancias. El software desarrollado bajo un enfoque por procedimientos no cuenta de manera

explícita con la información que satisfaga los requerimientos ya mencionados. Sin embargo se parte del supuesto de que esta información existe en los sistemas de manera

implícita. Por lo tanto, este proceso consiste en la extracción de la información necesaria,

la cual es depositada en tablas (diccionario de datos) que la almacenan para su posterior

utilización en la generación de código orientado a objetos.

1 , .

1.2.2.2 Proceso de reestructura del código original Este proceso toma como entrada el diccionario de datos que se obtuvo en el

proceso de análisis de código' fuente y realiza la reestructura del código original,

construyendo una arquitectura orientada a objetos (lenguaje procedural C a lenguaje O0 C++). Esto es, el diseño de la estructura del modelo compuesta por las clases de objetos

y la manera en que éstas se relacionan entre si. Los métodos que componen este proceso son: I. Creación de clases estratégicas.(Toma la estructura del patrón de diseño Strategy) 2. Creación de clases de comportamiento dinámico (Toma la estructura del patrón de

diseño State).

3. Conversión de UDTs a clases.

4. Conversión.de DGs a clases. 5. Conversión de funciones a clases. 6. Conversión de parámetros a clases.

7. Declaración de constructores.

11

.?I

I¡,

8. Reubicación de funciones.

Laura Alicia Hernández Moreno 8

Cenidet 2003 I(

http://Conversi�n.de

introducción Capítulo 1

9. Fragmentación de funciones

1 O. Superjerarquizar.

11. Subjerarquizar.

12. Fábrica de objetos.

13. Composición de objetos.

En el siguiente capítulo se hace una descripción detallada de los métodos

desarrollados en este trabajo de tesis y/o algunas sugerencias para el desarrollo de otros

métodos.

1.2.2.3 Proceso de refactorización Utilizando el modelo de clases de la arquitectura o framework del sistema

obtenido y la estructura de los patrones de diseño de Gamma[GAM95], en este

proceso, se proporciona un medio interactivo auxiliado por los métodos de refactorización d e Martin Fowler[FOW99] para que se facilite al usuario o personas

identificadas con el dominio (experto en el dominio, o el experto en software) un

refinamiento del modelo de clases actual, incorporando tópicos del contexto que

influyen en el diseño, así como la mejor manera en la que se relacionan las entidades

de la arquitectura del modelo.

Los cambios al modelo podrán hacerse en nombres de clases, identificadores de variables de instancia o de los métodos, así como posibles cambios en las

relaciones de herencia, agregación o asociación, jerarquización por herencia y composición por delegación.

En este proceso también se buscan similitudes estructurales entre el framework y los patrones de diseño, mediante una máquina de pareo de sus formas canónicas,

con el objeto de evolucionar el modelo de clases buscando las mejores condiciones de

reuso del framework de aplicaciones orientadas a objetos obtenido.

9 Laura Alicia Hernandez Moreno Cenide! 2003


1.3 Objetivo de la tesis Desarrollo de una herramienta de software, que permita realizar de forma

automática la reestructura de código legado escrito en lenguaje C bajo el paradigma de

programación por procedimientos. Dicha reestructura, enfocada hacia los tipos de datos

estructurados, datos globales y las funciones que estos utilizan, obteniendo como

resultado arquitecturas de clases reusables orientadas a objetos.

Para el 'logro de ' este objetivo, en esta tesis consideramos dos procesos

importantes, los cuales son: análisis de código fuehte y reestructura del código fuente (Ver

capítulos 4.1 y 4.2).

1.4 Beneficios de la tesis Para efectos de mantenimiento y para !evolucionar el software legado hacia

esquemas de reuso, la Única fuente confiable de información disponible es su código fuente.

La mayoría de las veces, los sistemks legados cuentan con muy poca

documentación, lo que implica la ausencia de información 'critica de decisiones de diseño. En muchas ocasiones la documentación es confusa o contradictoria y

usualmente i nconsistente con I a instrumentación del código. Esto sucede porque la actualización a l a documentación del software(si es que se actualiza) raramente es -'

congruente con la evolución del código. i/

En consecuencia, antes de intentar la transformación de software hay que tratar

directamente con su código fuente para obtener un entendimiento de su estructura y su comportamiento.

Por lo tanto, la actualización de software desarrollado involucra la extracción

adecuada de información, y en base e Sta i nformación reestructurar e I código hacia plataformas tecnológicas más modernas.

El propósito de transformar software escrito bajo el paradigma de programación por procedimientos hacia arquitecturas de aplicaciones orientadas a objetos no es una

tarea fácil, porque se necesita extraer información desde el código fuente que no se

encuentra expficitamente en él. La complejidad radica en el tipo de información

necesaria para este propósito como aquella que permita encapsular entidades 10


I

Cenidet 2003


relacionadas del código original, la que permita establecer relaciones de herencia y

asociación entre las diferentes entidades del código, así como de encontrar la forma

de crear instancias de las diferentes entidades del código transformado en relación

directa con el código original.

Así mismo, dentro del contexto de la maduración y evolución de dominios de

aplicaciones, la herramienta permite construir arquitecturas de aplicaciones orientadas

a objetos de dominios, lo que hace posible alcanzar un mayor grado de maduración de

dominios de aplicaciones de manera más rápida, y ahora se podrán desarrollar

incrementalmente, nuevas aplicaciones del dominio, personalizando por extensión,

composición y/o reemplazo, a la arquitectura de aplicaciones orientado a objetos

obtenida como resultado de la aplicación de la herramienta al software legado de

dominios.

A continuación se hace una sintecis de los beneficios que provoca este proceso de reestructura:

La obtención de una arquitectura de clases y de las relaciones entre clases, para

poder generar un nuevo framework, incorporando patrones de diseño que hacen

más factible s u reuso. La ampliación del tiempo de vida y recuperación del valor del software legado.

La reducción del tiempo al realizar la reestructura de una manera automática.

Mejora el diseño del código para que sea más fácil refinar o ampliar el programa [OPD93].

Otros beneficios que se obtienen con el desarrollo y culminación de este proyecto de

tesis, consisten en:

d Dar inicio al proceso de reestructura que forma parte del proyecto SR2 (Reingeniería de Sofhvare Legado para Reuso).

d Abrir caminos a nuevas investigaciones dentro del proyecto SR2.

1 1 Laura Alicia Hernández Moreno Cenidet 2003


iJ

1.5 Justificación del estudio A p e s a r d e q u e e l c o n c e p t o d e r e u s o ~ o e s n u e v o y d e l a gran cantidad de

artículos publicados, que justifican la creación de modelos, métodos, técnicas Y herramientas que ayuden en el proceso de desarrollo, mantenimiento y evolución de

software, de dominios, y la utilización de bFbliotecas de reuso para las nuevas aplicaciones del dominio; dos motivos fueron los que originaron la idea de realizar este

trabajo de tesis.

El primero es que en la actualidad el desarrollo de software se está moviendo

rápidamente de una forma artesanal hacia un proceso de ingeniería y manufactura a

gran escala. Este movimiento está causando una urgente necesidad d e contar con

artefactos reusables de software que cuenten con una mejor calidad y que puedan ser

configurados para dar respuesta a varias aplicaciones ante las necesidades de cambio

con un mínimo de inversión en costo y esfueko. Considerando que la adquisición

comercial de estos componentes reusables desde catálogos especializados por

dominios se ve limitada por su escasa producción para todos los dominios de aplicaciones, y/o adquirirlos a partir de la espekificación de dominios de aplicaciones puede ser riesgoso y caro, y puede llevar muchos años antes de que las funciones de

sistemas disponibles sean reemplazadas por un sistema orientado a objetos confiable y equivalente.

La segunda razón que motivó este trabajo de tesis radica en que con el paso

del fiempo, mucho código, basado en proceüimienios, ha sido desarrollado para

diferentes aplicaciones y dominios de problemas. Ahora, con el advenimiento de

nuevos modelos y tecnologías de desarrollo de software, este código tiende a quedar obsoleto, Todo este software representa una inversión considerable en las organizaciones, el cual se cree que no tiene valor, sin embargo, este código puede ser

legado para la construcción de componentes reusables, lo que puede representar un ahorro considerable en los costos de produc6ión de software, sobre todo cuando

algunos de estos componentes lleguen a ser usados con cierta frecuencia,

amortizando así el costo de su conversión. Por lo tanto, se hace necesario pensar en estrategias para aumentar su tiempo de vida Ctil mediante su recuperación y trarkformación . . en arquitecturas de componenfes reusables [SANOZ].

81

I/

'I

'I

I .


Caoítulo 1 Introducción

Esta tesis proporciona una estrategia que cubre ambos aspectos, basada en la

reestructura de software legado escrito en lenguaje de programación " C , bajo el modelo de desarrollo por procedimientos, hacia marcos de aplicaciones orientadas a

objetos para reuso. escritos en lenguaje de programación "c++". En relación al tiempo que se invierte en realizar el proceso de reestructura a

través de la herramienta desarrollada en esta tesis, es cuestión de segundos o un par

de minutos dependiendo del tamaño del programa fuente que sirva de entrada. Sin

embargo, en comparativa con llevar a cabo el proceso de reestructura en forma

manual podemos decir que la herramienta desarrollada en esta tesis resulta factible,

ya que el realizar una identificación de los datos que componen al programa de

entrada en forma manual se llevara minutos y posiblemente hasta horas dependiendo del tamaño del programa a reestructurar, además de tener que llevar una relación muy

rigurosa en cuanto a la clasificación de datos y su reubicación correcta de funciones en el archivo o clase que haya sido generado para determinado tipo de dato. En si, el

realizar el proceso en forma manual puede ocasionar equivoco y/o redundancia d e

datos, sin que se puedan dar cuenta fácilmente los encargados de realizar el proceso.

1.6. Límites y alcances del estudio El alcance de este trabajo de tesis, se limita a hacer una reestructura inicial del

código fuente con el propósito de construir arquitecturas iniciales de componentes

reusables orientadas a objetos de dominios (se considera un objeto de dominio a un

conjunto d e datos del dominio encapsulado junto con las operaciones del dominio que

manipulan a esos datos).

No se ha pretendido con este trabajo obtener.el mejor diseño de arquitecturas o garantizar las mejores condiciones de reuso, esto es tan solo una parte inicial del proyecto SR2 tal y como se menciona en la sección 1.1 de este documento. SR2 esta apoyado por otros trabajos de maestría que trabajarán en colaboración para lograr así lo

planteado en [SAN02].

El lenguaje de origen del código a analizar y reestructurar debe de ser "C". dando como resultado al aplicar el proceso de reestructura, código orientado a objetos en

lenguaje "C++".

Laura Alicia Hernández Moreno 1 3

Cenidet 2003


La limitación que se tiene en cuanto ai proceso de reestructura de software legado,

radica en que, para automatizar este' procesoilse requiere de la instrumentación de

métodos o algoritmos especificos de este trabajo y los cuales se describen

detalladamente en la sección 4.2.

I' !'

1.7 Organización de esta tesis Para describir el trabajo que se realizó para llevar a cabo esta tesis, a continuación

El propósito de este capitulo fue presentar ki entorno de investigación en el cual se se da un panorama de la organización de este documento.

desarrolló este trabajo.

En el capítulo 2, se presenta una revisión de los trabajos relacionados con este tema de investigación y se describe un análisis comparativo de éstos con respecto a este

En el capítulo 3, se hace una revisión de los conceptos y temas relacionados con

trabajo de tesis. .Il

esta investigación, con la finalidad de presentar el fundamento teórico de ésta.

Posteriormente, en el capítulo 4 se describen detalladamente los métodos desarrollados en esta tesis y que conforman la herramienta SR2.

En el capitulo 5. se presentan las conclusiones observadas en esta investigación.

En la Última parte del documento se presentan la bibliografía y anexos que

integran a este trabajo, Los anexos consisten en la descripción detallada de un programa fuente y la forma en que fue reestructurado. 'I¡


Revisión de la literatura Capítulo 2

2.1 Trabajos relacionados con esta tesis Los trabajos que fueron encontrados y que más se acercan a este trabajo de tesis,

son aquellos que tratan de atacar el problema de mantenimiento en sistemas legados, en

los que tratan que sus sistemas evolucionen o sean entendibles a través de un buen

diseño de su código. Dentro de los trabajos relacionados se mencionan algunos puntos importantes de la implementación de los mismos, tales como las herramientas o métodos


Capítulo 2 I' Revisión de la literatura

que utilizan para el análisis y extracción de datos a partir de un programa fuente. Los

trabajos se describen en las siguientes subsecciones.

2.1 .I Transformación automática de sistemas legados [PHIOI] En este documento se menciona la necesidad de búsqueda y creación de técnicas

o herramientas que sirvan de apoyo al sector industrial, donde proporcionen a éste una

disminución en costos de desarrollo, un mayor entendimiento de ¡os sistemas legados, un

cambio de paradigma de programación para que su software legado no se vuelva obsoleto.

Menciona que las alternativas de solución para la modernización de los sistemas incluyen el desarrollar un nuevo sistema, el reemplazar sistemas con soluciones

comerciales (COTS - Component off-the- Shelf, Componentes de software comerciales de vitrina o anaquel) o la reescritura manual de las aplicaciones de software legado hacia

un ambiente moderno de programación. Donde el desarrollar totalmente un nuevo sistema

o reemplazar los sistemas legados por medio de la reescritura manual de los sistemas de software con el soporte de herramientas semiautomaticas es extremadamente costoso y

consume tiempo.

Reemplazar el sistema usando COTS aunque es menos costoso y consume menor

tiempo, tiene la desventaja de que no permite extender o expandir los componentes que

los integran con la finalidad de brindar mas funcionalidad en los sistemas en donde los estén usando.

Se describe que a través de la tecnología de Inteligencia Artificial es posible construir herramientas que nos permitan lograr un alto porcentaje en el análisis,

transformación, refactorización o reingeniería. KBSA (Air Force-funded Knowledge-Based

Software Assistant) en su intento por tratar de construir herramientas que den soporte en la transformación de software legados a un nivel de automatización que se acerque a un

loo%, se ha dado a la tarea de tratar de construir una herramienta que nos permita hacer la transformación de sistemas legados escritos en lenguaje COBOL, JOVIAL, FORTRAN.

C, ASSEMBLER, ADA, CMS-2 y MUMPS hacia lenguajes tales como C++, JAVA, C# y J2EEI.NET.

'11

I , - . ,

I'

16 Laura Alicia Hernandez Moreno Cenidet 2003 1)

http://J2EEI.NET


Se menciona que se han hecho pruebas de transformación sobre 10s lenguajes

JOVIAL, COBOL, c , FORTRAN y ASSEMBLER; mas no se menciona en que IenguaMs)

han sido transformados.

El proceso de reingenieria se define sobre cuatro procesos, los cuales son:

Ei proceso de análisis se realiza a través de la construcción en memoria de un

árbol de sintaxis abstracto basado en conocimiento (KBAST) generado a partir del código

de entrada que se da a la herramienta.

análisis, reestructura, refactorización y Web-enablement.

Las interpretaciones que se van realizando del KBAST se van almacenando para

posteriormente documentar decisiones acerca de las situaciones que se encuentren en el

código (propiedades) y así poder llevar a cabo la transformación.

El proceso de reestructura consiste en especificar o generalizar cada una de las

interpretaciones obtenidas en el proceso de análisis. Las interpretaciones que se hacen

se basan en las estructuras del programa, en la definición de datos estructurados, en

bloques básicos de código, funciones o variables de entrada del programa. Tanto el proceso de transformación así como el proceso de refactorización

requieren intervención manual. cuando es necesario establecer sistemas que apoyen la

tarea de clasificación.

El proceso de refactorización se encarga de extraer y parametrizar métodos,

mezclar y consolidar métodos similares, reducir el conjunto de métodos asociados con

una clase, el conjunto mínimo de operaciones para mejorar. Reduce la duplicidad y

redundancia de código.

Web-enabiement trata de vincular la transformación de una aplicación hacia aplicaciones distribuidas o trabajo en red (crear componentes distribuidos o los

actualmente llamados servicios web), haciendo uso de herramientas que permitan trabajar

sobre ambientes distribuidos, tal es el caso de las siguientes herramientas:

I Para bases de datos. ODBC(0bject Data Base Connectivity), JDBC (Java Data Base Connectivity).

i Para proveer servicios de componentes distribuidos. CORBA (Common Object Request Broker Architecture)


Revisión de la literatura 1 Capítulo 2

El objetivo que persiguen [PHIOI]. es cbnstruir una herramienta genérica que

permita realizar la reingenieria sobre los lenguajes ya mencionados en párrafos

anteriores. Lo que no queda claro ya que no lo mencionan, es en que lenguaje(es) quedarían como resultado de aplicar la reingenieka. Otra de las cosas que no mencionan

es la forma en que realizan la reestructura, lo que mencionan en relación a esto es que es una tarea dificil y que en su mayoría requiere de la intervención manual.

2.1.2 Reestructurar código legado C en C++ [RICOO]

el Departamento de Ciencias Computacionales de la Universidad de Detroit, E.U..

En este documento se hace mención de un prototipo, el cual esta en desarrollo en

Se hace uso de una herramienta que sirve para realizar el proceso de reestructura

y para tareas más complicadas de reestructura se hace uso de escenarios que combinan el uso de la herramienta con la intervención del usuario.

La herramienta de reestructura se compone de las siguientes fases: inserción de

variables en clases, hacer'accesos a variables no locales, agregar parámetros a funciones

y cambiar especificaciones de accesos de una clase.

Para la identificación de los elementos o datos del programa fuente y que habrán

de servir para el proceso de reestructura, se empleo una herramienta de análisis llamada

GEN++. GEN++ es un analizador de código programable basado en el Cfront de AT&T. Este analiza el código fuente escrito en lenguaje "C" y lo almacena en un grafo semántico abstracto, a través del cual el programador puede escribir consultas (queries) analizando

el grafo en un lenguaje tal como LISP. El proceso de reestructura se compone de tres partes:

li

.I1

9

9

Restricciones del analizador (implementado en GEN++). Se asegura que estén todas

las precondiciones requeridas para llevar a cabo el proceso de transformación. Transformación del analizador (implementado. en GEN++). Localiza todas las partes del código que pueden ser cambiadas (variables globales ylo locales, funciones,

parámetros, accesos a variables y funciones) y que cambio es requerido en ellas. Los datos obtenidos los guarda en un archivo.

'I

18 Laura Alicia Hernandez Moreno Cenidet 2003 I\


> Código reestructurado (implementado en C++). Esta parte usa el archivo obtenido en el punto anterior y realiza los cambios necesarios para su reestructura apoyado con la

intervención del experto humano.

2.1.3 Extracción automática de clases desde sistemas legados [ANDOO] Este artículo menciona algunas de las ventajas del paradigma de programación

orientado a objetos, da una breve descripción de la herramienta Rescueware, y un análisis por parte del escritor con relación a una nueva forma de extraer en forma

automática las clases desde sistemas legados.

Las ventajas que menciona son acorde a [B0094], y son las siguientes: > Los objetos proveen un buen modelo del mundo real, ayudan a simplificar el diseño de

un sistema (abstracción, descomposición).

> Los objetos son independientes e interactúan usando interfaces definidas o métodos. > El uso de la herencia, nos permite hacer más fácil poder agregar características

nuevas a objetos existentes.

> Cuando un objeto necesita ser actualizado, este es un cambio interno y no afecta a otros objetos (consecuencias de la encapsulación).

La herramienta Rescueware considera la tarea de transformar sistemas legados escritos en lenguaje COBOL a programas orientados a objetos en lenguajes modernos de programación, tales como C++, Java o Visual Basic. Los principales pasos que sigue esta herramienta son: Creación del procedimiento, localización o eliminación completa del

GOTO. localización de datos y transformación optimizada. El proceso se basa generalmente en la representación del programa fuente en un árbol de

sintaxis abstracto (AST) y 'lo que se hace con éste, es localizar e incorporar en clases las variables definidas en el programa (las cuales no son difíciles de identificar porque todas

sus variables son globales y están como una sola estructura), hace una descomposición

de los procedimientos localizados como funciones e incorpora a estas últimas parámetros que vendrán a tomar la representación de las variables que utiliza el procedimiento en

descomposición.

El autor del documento que en este punto se describe brevemente, plantea los siguientes principios básicos para la extracción de clases de programas legados:



Acoplamiento de datos, llamadas y nivel de variables. A través de estos principios hace

un llamado a un mejor análisis base a las variables globales y el nivel de anidamiento y/o

dependencia entre variables y procedimientos. ,

2.1.4 Reingeniería de software legado a':través de la conversión del

lenguaje [MAAOO] Proyecto desarrollado en la Universidad' de Tempere en el Departamento de

Computación y Ciencias de la Información, Finlakdia. Este es un ambiente de desarrollo

que da soporte a un proceso de reingenieria en apoyo a la industria de este pais.

La reingenieria, es un proceso de transformación o conversión que toma como

código fuente o de entrada programas escrito; en el lenguaje PL/M (Programming Language for Microcomputers) dejando por resultado programas en lenguaje C. El

proceso que se sigue consiste principalmente de un proceso de reestructura. En la reestructura, el software legado es bnalizado utilizando la herramienta que

lleva por nombre TaLE (Tampere Language Editor), ésta nos brinda soporte en el

desarrollo o implementación de lenguajes. Su desarrollo ha sido en Eiffel, C++ y actualmente en lenguaje Java. /I

En este trabajo TaLE parte de la gramática de PUM y de un programa de entrada escrito en PUM, una vez que lo está analizando empieza a mostrar los elementos de la gramática encontrados en forma gráfica, a su vez hace empleo de tablas de simbolos y archivos para guardar la información obtenida, la cual se enfoca a la identificación de variables globales, funciones y sus relaciones. De los datos obtenidos se despliega en una interfaz a través de un árbol, las variables globales que localizó dentro del programa y a partir de éstas pide la intervención del usuario para ir asignando nombres a los archivos

que va crear. La creación de archivos la lleva a cabo de la siguiente forma:

> Toma como archivo principal, la primera variable global que encontró y a las demás las

'1

II incorpora en otros archivos, con sus respectivas operaciones.

9 En el archivo principal pone como librerías a los demás archivos creados.

1 En este articulo se menciona que se tiene contemplado llegar hasta un diseño

onentado a objetos, el cual es un paradigma de programación que promete un mejor 20

Laura Alicia Hernández Moreno Cenidet 2003 11

Capítulo 2 Revisión de la literatura

diseño y calidad en los sistemas de software. Sin embargo para llegar al paradigma planteado anteriormente, se menciona que no es una tarea fácil de automatizar, por la

complejidad que se tiene de manejar diferentes paradigmas de programación (estructural

- orientado a objetos).

2.1.5 Un framework para reestructurar software [KYB99] Es un prototipo desarrollado en la Universidad de Colorado, E.U., que soporta la

reestructura de software procedural escrito en lenguaje C, COBOL, FORTRAN o Pascal.

Tiene como objetivo mejorar las características de diseño, sin cambiar su paradigma de

programación.

El framework consta de tres elementos principales: modelo de diseño de software, métricas basadas en criterios de reestructura y un proceso para reestructurar mediciones.

Los autores de este documento usan el término de "módulo", para referirse a procedimientos o funciones individuales definidos en un programa.

El modelo de diseño de software, generalmente usa gráficos para representar los componentes de un módulo y las conexiones entre módulos. Trata de ajustarse a los requerimientos del framework (entradaslsalidas de un módulo).

Las métricas basadas en criterios de reestructura, se basan sobre la cohesión y acoplamiento de módulos.

La cohesión de software o relación fuerte, se refiere a la relación que puede existir

entre los componentes (operaciones) de un módulo a través de sus atributos; donde los módulos cohesivos son difíciles de dividir en componentes separados.

El acoplamiento de software se refiere a la conexión que puede existir entre módulos.

Uno de los objetivos del proceso de reestructura es incrementar la cohesión y

,

reducir el acoplamiento.

Los tipos de cohesión y acoplamiento que se pueden identificar son:

9 Cohesión coincidental, temporal, procedural, de comunicación, secuencial y funcional. 9 Acoplamiento común, condicional, computacional, secuencial y el no acoplamiento.

DG'T\ SEP CENIDET CENTRO DE INFORMAC~O~



I Las medidas de cohesión y acoplamiento son un punto importante para el proceso

de reestructura. ya que indican si un módulo será o no descompuesto, y compuesto en un nuevo diseño. 11

El proceso de descomposición de los módulos los realiza a través de la partición de los mismos módulos (entiéndase por módulos a las funciones o procedimientos), los

cuales los integra en nuevos módulos con una funcionalidad especifica. Ese proceso es mejor conocido como partición de programas (program slices) y trabaja en conjunto con el

nivel de cohesión y acoplamiento de módulos, algunos de los trabajos mas recientes

referentes a partición de programas, cohesión y acoplamiento podemos ver en [ARU99,

HEE99, BIE981 I1 El proceso de reestructura consiste de una secuencia de descomposición y

composición o creación de módulos. En este proceso que integra a la herramienta que en esta sección se describe, se hizo uso inicialmente de una herramienta que lleva por nombre F-Slicer para hacer las particiones de programas, sin embargo esta herramienta

no es completamente automática. Los elementos que integran al framework se

encuentran incorporados dentro de la herramienta que lleva por nombre FUNCO. La

herramienta hace uso de los analizadores lex y yacc en conjunto con el compilador gcc (UNIX). La herramienta ha sido probada e instalada en una SUN SPARCstatation.

.I

r. L

2.1.6 RESTRUCT [SAGWW, SAG98, SAG971 Es una herramienta CASE de reestructura,, que hace uso de la ingeniería inversa,

la cual ha sido desarrollada en base la integración de proyectos estudiantiles de la Universidad de Montfort, Inglaterra. Transforma programas escritos en lenguaje C que están pobremente estructurados, en programas con una estructura orientada a objetos

utilizando el lenguaje Java.

La herramienta parte del uso de una base de datos que contiene los componentes

o datos extraídos, donde éstos se extraen en forma manual (de acuerdo a [ S A G W ) del programa candidato a ser reestructurado.

Mencionan que las técnicas de identificacih de objetos sobre las cuales se apoya

la herramienta están sustentadas por tres algoritmos descritos por Livadas & Roy [LIV92],

Liu & Wilde [LIU90]. Los algoritmos de identificación de objetos son los siguientes: 22

Laura Alicia Hernández Moreno Cenidet 2003

Revisión de l a literatura Capítulo 2

> Basado en variables globales (gboi). Consiste en agrupar las variables globales Y las funciones que manipulan estas variables.

> Basado en tipos (tboi). Agrupa tipos definidos por el usuario con las funciones que utilizan estos tipos como parámetros formales o valores de retorno.

k Basado en el reconocimiento de receptores (rboi). El algoritmo define un objeto

candidato como un par (F,T) donde F es un conjunto de rutinas que modifican par variables de tipo T. Los receptores son tipos de variables representados' como

variables globales o parámetros pasados por referencia.

Los métodos de transformación que utiliza RESTRUCT son: P Partición simple, Se usa cuando un conjunto de variables son modificadas por un

conjunto de rutinas o funciones y estas variables no están relacionadas a otros

conjuntos de funciones o rutinas. Lo cual indica que estos conjuntos de variables y funciones o rutinas definen un comportamiento común y pueden ser clasificadas en

clases separadas.

> Partición con métodos parametrizados. Se utiliza cuando las funciones o rutinas que son separadas en una clase independiente de la clase original, acceden a algunas

de las variables que permanecen a esta última. Lo cual sugiere que la separación puede efectuarse aplicando una partición simple, pero pasando como parárnetros a

las variables accedidas por las funciones a ser separadas de la clase original. Los parámetros se pasan por valor si las variables sólo son,referidas y por referencia si las variables son modificadas.

> Partición con herencia. Se utiliza cuando una relación de este tipo es más natural que las relaciones de agregación (composición) de los métodos de partición anteriores. Por ejemplo se puede utilizar este método de partición cuando un

conjunto de funciones que podrían ubicarse en una subclase pueden llamar a otras funciones que permanecen a la clase original.

P Extracción de librerias de clases estáticas reusables. Nos dice que la mayoría de los programas que contengan métodos que pueden ser utilizados por otros programas o que pueden ser requeridos por un gran número de clases (creando librerías), no

pueden ser incluidos en ninguna de las clases. Tales métodos pueden ser agrupados

en una librería de clases declarada como pública y estática, indicando con.esto que

no hay instanciación de esta clase. De tal manera que ahora las funciones o


Capítulo 2 1 Revisión de l a literatura

métodos de esta clase pueden ser compartidas por todas las clases que las

P Partición con una superclase estática reusable. La partición con una superclase estática reusable se utiliza cuando se presentan los siguientes dos problemas: cuando

un conjunto de funciones o rutinas usan a otro conjunto de funciones o rutinas de la

clase original, pero estas funciones son candidatas a'ser parte de otra clase.

Este es un problema causado por las reglas de alcance de los lenguajes orientados a objetos de verificación robusta' de tipos, ya que estos dos conjuntos

de funciones no estarán al alcance unos de otros después de la transformación.

Este problema se resuelve ubicando a las funciones o rutinas utilizadas junto con

sus variables asociadas como miembros;. de una superclase y heredar los componenfes de la clase que contiene a las funciones invocadas.

requieran. 1

Sin embargo, el segundo problema se presenta cuando hay dos subclases

en la misma situación, porque cuando se genera una instancia de cada una de las

subclases se produce la creación de dos variables de instancia, cuando puede

darse el caso de que sea necesaria solamente una variable de clase compartida por las dos subclases. h!

La solucibn que plantea este método de partición es declarar las variables

de la superclase como estáticas, asegurando de esta manera sólo una copia en memoria de estas variables para todas las irktancias del tipo de las subclases que

se declaren en una aplicación.

I1

2.1.7 SPRUCE: Un framework para reestructurar software [DAV97] SPRUCE (System fo.r Providing assistance with' Restructuring CodE), es un

sistema que proporciona ayuda para reestructurar código de programas escritos en

lenguaje Pascal (mejorar las características de diseño). Soportado en parte por la NSERC

(Natural Sciences and Engineering Research Council), por los estudiantes de posgrado

del NSERC y a la ITRC (Information Technology Ffesearch Centre) el cual es parte de los Centros de programa de Excelencia de Ontario. En este sistema proponen dividir la reestructura en cuatro etapas:


Revision de l a literatura Capítulo 2

9

9

P

P

Reestructurar nivel del código. Consiste en la identificación de tomas de decisiones (if-

then-else) y en las entradas y salidas que pueden surgir dentro de un ciclo (llamadas a otros módulos, uso de goto's).

Reestructura de datos. Analiza las relaciones que pueden existir entre estructuras de

datos y variables, es decir, identifica si una variable o estructura de datos tiene alguna relación con alguna otra variable o estructura de datos. Incluye identificar si una

variable global puede ser local y si parámetros de variables pueden ser parámetros de valores.

Reestructura procedural. Divide un programa en un conjunto lógico de rutinas, pero

menciona que las rutinas obtenidas no son necesariamente la mejor división. Se

menciona que por cada rutina se deberia tener sólo un punto de entrada y un punto de salida, en la cual se integre cada rutina como una función abstracta de tal forma que

las rutinas puedan ser organizadas en una jerarquia.

Remodulación. Es la reestructuración de un sistema existente en una jerarquia modular; esto incluye mover rutinas en módulos apropiados.

Cada una de estas etapas tiene tres fases: Reunir información, efectuar decisiones

y ejecutarlas.

Para limitar la dependencia del lenguaje, SPRUCE procesa un árbol abstracto de

sintaxis con un lenguaje independiente "tree walker". El "tree walker" entiende la estructura del árbol abstracto de sintaxis y provee rutinas que permiten acceder de la

información en los nodos y para instruir el "tree walker" para moverse entre nodos. La tabla de entradas para cada tipo de nodo llama al "tree walker" para que realice la

reestructura.

Hace uso de otros procedimientos tales como: Análisis del grafo de llamadas,

alternado del código, análisis del flujo de datos, análisis del goto, controlador de interface. controlador de la estructura del módulo, análisis de procedimientos, reescribir procedimientos, organizar la estructura de módulos, renombrar variables y análisis del uso

de variables.

Lo que se encontró, que se ha construido de SPRUCE es lo siguiente:

9 Un parser en Pascal y un analizador semántico parcial.

9 Análisis de datos y flujo de control.

9 Implernentación de la facilidad para renombrar variables.



9 Una implementación parcial de una interface de usuario basada en SUNView para

visualizar el código fuente escrito en lenguaje pascal.

> Implementación de lineas de código, otras herramientas como Halstead. McCabe y unas pocas métricas no muy conocidas.

Estos trabajos han surgido como proyectos separados desarrollados por

estudiantes, los cuales no han sido integrados aún.

2.2 Análisis comparativo de los trabajos relacionados con respecto a esta tesis

Como se puede observar, existen trabajos que no hacen una transformación de C

a C++ que es lo que se hace en este trabajo de tesis. Sin embargo tienen un punto muy en común, el cual esta enfocado a tratar de c o n h i r herramientas o metodologias que

ayuden a los programadores al entendimiento del software legado para su fácil o mejor mantenimiento, reduciendo con esto tiempo y esfuerzo (costos). As¡ también se enfocan a mejorar las características del diseño, donde algunos cambian su paradigma de

programación tratando de evolucionar y mejorar sus diseños, mientras que otros tratan de mejorar sus diseños sin cambiar su paradigma de programación.

Se hace mención que el paradigma de programación orientado a objetos nos

brinda muchas ventajas, siendo una de las más importantes la siguiente: Hacer diseños

reusables a través de la creación de componentes o marcos de componentes reusables, los cuales pueden ser utilizados en extensiones o nuevas aplicaciones del mismo dominio.

Uno de los puntos importantes de este trabajo de tesis es poder obtener marcos

de componentes reusables, cosa que en la mayor parte de los trabajos no se prevee, la reusabilidad.

Una de las similitudes que existen entre al&nos de los trabajos ya descritos en las

subsecciones anteriores (principalmente de la herramienta RESTRUCT) y este trabajo de tesis, es la identificación de variables y funciones que se trata de hacer para realizar un proceso de transformación o reestructura.

I1

I/

I1

Desde esta perspectiva podemos decir que existe una diferencia ya que en este

trabajo de tesis no sólo nos referimos a la incorporación de variables globales y las 26

Laura Alicia Hernández Moreno Cenidet 2003

Revisión de l a literatura Capítulo 2

funciones que las acceden en una clase o archivo separado, va mas allá empleando 10s siguientes criterios en el proceso de reestructura: conversión de tipos de datos

estructurados a clases de objetos, conversión de datos globales a clases de objetos y conversión de funciones a clases de objetos. Estos criterios se describen en el capítulo 4 de la tesis.

Hasta ahora no se ha encontrado una herramienta que trate de incorporar en

clases de objetos a los tipos de datos estructurados a través de un proceso de

reestructura, refiriéndonos principalmente a los tipos de datos estructurados anidados. Se ha llegado a hacer dejando a la definición del tipo de dato estructurado en una clase y los campos que integran al tipo de dato estructurado se forma una clase por cada campo y los métodos que utilizan a cada campo son agrupados en la clase correspondiente al campo. Se crean variables de instancia en la clase creada a partir de la definición del tipo

de dato estructurado, las variables de instancia corresponden a las clases creadas a partir

de los campos que componen al tipo de dato estructurado.

Podemos ver que la mayor parte de los trabajos tratan de ver un proceso de reestructura tan sólo como una encapsulación de datos, esto debido a que no se tiene

contemplado un diseño que permita el reuso. Dado que el reusar utiliza otros mecanismos

para su buen funcionamiento tales como: herencia, agregación, instanciación y un concepto nuevo que ha venido a ser de gran utilidad el cual es, los patrones de diseño.

El Único trabajo encontrado que haga uso de patrones, es el de Harald C. Gall, Rene Klosh, Roland T. Mittermeir y Johannes Weidl (GAL951 los cuales realizan un proceso de reestructura que transforma código legado en C, Pascal y PUI a una

arquitectura orientada a objetos y hacen uso de los patrones del catálogo de Peter Coad (patrones de análisis y patrones de diseño) con el objetivo de modelar dominios de aplicaciones.

Respecto a este trabajo la diferencia principal radica en que su modelado de dominios se ve limitado debido a que no contempla algunos patrones de diseño que son

fundamentales para la construcción de arquitecturas y/o marcos de componentes reusables orientados a objetos, tales como: El patrón de diseño template method con el cual se puede implantar la definición de métodos gancho que nos permiten la inversión del flujo de control, el patrón de diseño facfory method que permite crear una alternativa o interfaz de implantación, y por Último el patrón de diseño Decorator el cual nos sirve para


Revisión de la literatura 11 Capítulo 2

estructurar la funcionalidad en clases de los tipos de datos abstractos cuando existen

anidaciones, es decir un tipo de datos estructurado dentro de otro(s).

Cabe mencionar que esta tesis esta siendo extendida, actualmente se está

trabajando sobre la incorporación de nuevos patrhes de diseño en la herramienta SR2.

Con respecto a los trabajos de las subsecciones anteriores se dice que alguno de ellos (véase sección 2.1.4) hace uso del patrón de diseño Singleton el cual sirve para hacer la incorporación o agregación de una clase a otra (como una simple agregación o composición).

La herramienta FUNCO (2.1.5) se trató'ide investigar a través de su uso, su funcionalidad. Después de varios dias de tratar de hacer funcionar la herramienta se encontró que ésta no estaba completa, por lo cual se le envió un correo electrónico a uno 1 de los autores el Dr. Bieman, el cual afirmó que laiherramienta no ha sido aún terminada.

En la tabla siguiente (tabla 2.1) se describe en forma general un análisis

comparativo entre los trabajos relaciones a este trabajo de tesis y sus desventajas 1

respecto a esta tesis.

de inteligencia artificial. 9 su proceso de

reingenieria esta

sustentado en cuatro procesos: análisis,

reestructura,

refactorización Y

9 Para el proceso de

clasificación de datos

servicios web. :.

compiladores haciendo

uso de la herramienta ANTLR. se aplican métricas y se hace uso de patrones de diseño

propios para el reuso.

9 El proceso completo de SR2 contempla los

mismos procesos que se

mencionan

28 Laura Alicia Hernández Moreno Cenidet 2003 I)


leestructurar código legadc

: en C++ [RICOO]

menciona el articulo que se requiere de

intervención manual.

Tratan de hacer una

transformación de

lenguajes tales como:

COBOL, JOVIAL,

FORTRAN, C, ASSEMBLER, ADA,

CMS-2 y MUMPS hacia

lenguajes tales como

C++, JAVA, C# y J2EEI.NET. No

mencionan

específicamente, las

transformaciones de los

lenguajes, es decir, un

determinado lenguaje

hacia cual ienguaje(s) es

transformado. AI parecer

este trabajo aun no se

termina.

Es un prototipo que se

encuentra en desarrollo.

Se compone de las siguientes fases: inserción de variables en

clase, hacer accesos a

variables no locales,

agregar parámetros a

funciones y cambiar

columna de desempeño

sin embargo nc

mencionan los método5

que se llevan a cabo er

cada proceso. En este

trabajo de tesis SE

aplican 7 métodos tar

solo para el proceso dr reestructura.

En este trabajo de tesi:

se lleva a cabo un:

reestructura dr

programas escritos er

lenguaje C hack

programas escritos er

lenguaje C++ orientado:

a objetos.

Los siete métodos de reestructura han sidc

concluidos en este trabajo de tesis.

* Las fases de este trabajo

de tesis van más allá de

una simple inserción de

datos en clases, se hace

uso de conceptos de la


http://J2EEI.NET

I

I


I

Extracción automática de

clases desde sistemas

legados [ANDOO]

Un framework para

reestructurar software

[KYB99]

especificaciones de

accesos de una clase.

P Hace uso del analizadoi GEN++. analiza códigc

escrito en'lenguaje C y Io

almacena en ''un grafo

semantico. Las consultas

al gráfo se! hacen a

través de un programa

para consultas tal como LISP. 11.

I

+. Realiza la transformación

de sistemas legados

escritos en '1 lenguaje COBOL a programas

orientados a li objetos

(C++, Java o Visual

Basic).

Prototipo que sbporia la reestructura de software

procedural escrito en

lenguaje C, COBOL,

FORTRAN o PASCAL. Teniendo como objetivo mejorar las

caracteristicas de

diseño, sin cambiar su paradigma de

programación. I/

programación orientada

a objetos, así como de

patrones de diseño.

+. ANTLR proporciona las

facilidades de

reconocimiento, de

consulta y obtención de

datos sin tener que

interactuar con otras

herramientas. Genera

código en lenguaje Java.

+ Se aplica la reestructura

a programas escritos en

lenguaje C hacia

programas escritos en

lenguaje C++ orientado a

objetos.

AI realizar el proceso de

reestructura se esta

llevando a cabo un

cambio de paradigma de

programación de

programación procedural a programación

orientada a objetos.

Siendo esta ultima uno

de los paradigmas actuales de mayor auge

y con mayor desempeño

en el reuso de software.

30 Laura Alicia Hernández Moreno Cenidet 2003 a


tESTRUCT [SAGWW

;AG98, SAG971

>PRUCE [DAV97]

* Transforma programas

escritos en lenguaje C,

en programas con una

estructura orientada a

objetos utilizando el

lenguaje Java. Se

menciona que hace uso

de patrones de diseño,

sin embargo dentro de

sus artículos no hay

ninguna publicación que

lo demuestre.

* En el trabajo que presenta RESTRUCT al

parecer solo hacen uso de la composición ya que

de una clase grande van

sacando a clases los datos globales y sus

respectivas funciones.

' En las publicaciones de

RESTRUCT se menciona que el proceso

se realiza en una forma

automática, sin embargo no 'se han publicado

pruebas que corroboren

esta afirmación.

> Mejora las características de diseño

de programas escritos en

El hacer uso de la

programación orientada

a objetos (en esta tesis)

va más allá del uso de tan solo una

composición. Va hacia la

creación de un marco

completo de

componentes reusables.

SR2 aplica los patrones

de diseño Strategy,

State, Decorator, Factory

Method, Template Method, entre otros.

SR2 es una herramienta

automática que permite

generar código en

lenguaje C++ a partir de programas escritos en

lenguaje C.

Se continua trabajando

tratando de obtener

marcos de componentes

reusables mas

completos y en donde esta herramienta sea de utilidad dentro de

dominios específicos. Se trata no de mejorar

las características de

diseño, sino de obtener



I lenguaje Pascal buenos diseños que permitan el fácil

entendimiento. extensión

y actualización de los programas. Esto es lo

que persigue SR2.

Tabla 2.1 Tabla comparativa de los trabajos relacionados contra este trabajo de tesis


Marco teórico Capítulo 3

ada día crece más la necesidad de pensar en estrategias o herramientas que nos

ayuden a diseñar sistemas de información con más tiempo de vida útil. En esta tesis se construye una metodología de reingeniería para ampliar el tiempo de vida útil del software. reestructurándolo para su reuso.

c En este sentido a continuación se presentan los conceptos empleados en torno a

este proyecto de tesis.


Capítulo 3 Marco teórico

3.1 Factorización La factorización implica la descomposición o partición de un determinado

programa en una jerarquia de clases, partiendo de una clase padre o raiz y llegando a las clases concretas o atómicas que realizan las funciones operativas.

Análogamente a lo que sucede en las organizaciones humanas, una clase padre de máximo nivel no realiza ninguna de las tareas del sistema por si mismo, sino a través

de sus subordinados. En el caso limite, una clase raiz solo contiene llamadas a otras

clases. Las clases padres (alto nivel) normalmente tratan decisiones globales, en tanto

que las de bajo nivel tratan aspectos especificos de las decisiones de nivel superior

[TORXX].

¡I

3.2 Programación por procedimientos en lenguaje C [SANO21 La programación estructurada fue empleada desde el principio de la década de los

setenta, y tuvo como filosofia, construir un programa a partir de la composición de

funciones o procedimientos entre otros modelos que permiten que los programas sean más fáciles de escribir, verificar, leer y mantener.'iLos programas deben de estar dotados de una estructura. De tal manera, que los principales elementos del reuso fueron las bibliotecas de funciones.

La programación por procedimientos en lenguaje C, está cimentada en mecanismos que dan facilidades para comunicar, como argumentos, información a

procedimientos ylo funciones y retornar valores desde las funciones. Este modelo de

programación cuenta con estructuras de datos globalec, aunque también se han desarrollado mecanismos para manejar el alcance y el tiempo de vida de las variables, siendo factible dependiendo de: el lenguaje ,de implantación, manejar variables

globales y locales con tiempo de vida que puede ser estático, dinámico y automático.

j

Bajo el contexto de reuso, la meta principal de este modelo de programación

es la de permitir a los programadores ejecutar segmentos de código, organizados en bibliotecas de funciones, más de una vez, sin tener que duplicar el código en cada localidad fisica donde son necesarios.

Los programadores observaron que podian insertar subrutinas extraídas de sus

programas previamente desarrollados, o ta'mbién aquellas escritas por otros 34

Laura Alicia Hernandez Moreno . : . - I;

Cenidet 2003

Marco teórico Capítulo 3

programadores, en nuevas aplicaciones, tomando ventaja de la funcionalidad Sin tener

que involucrarse con 10s detalles del código. Así es como nació el concepto de reuso

de software [BR096].

A pesar de que las subrutinas representan un gran avance para el desarrollo de programas de aplicación con mayor rapidez, con mayor calidad y con más facilidad,

este paradigma de programación no ha sido suficiente para lograr que la producción

de software se realice bajo un esquema completo de reuso. El resultado de construir sistemas de software bajo este paradigma son

programas de una sola pieza, que por ser diseñados para resolver un problema específico es difícil su reuso, parcial o total, en otros problemas aún del mismo dominio de aplicación, pues como dice Clemens Szyperski [SZYSS] "no basta con e/

diseño monolitico de una solución completa y después fragmentarla, cuyo beneficio es

mínimo, sino que /as descripciones tienen que ser cuidadosamenfe generalizadas para

permitir su reuso en muchos contextos diferentes".

Estos programas monolíticos exhiben una gran cantidad de líneas de código,

estatutos condicionales con profundos niveles de anidamiento, alto grado de

acoplamiento entre las diferentes funciones y procedimientos, y cualquier línea de

código puede acceder a las estructuras de datos globales.

Estos factores producen en el software un alto nivel de complejidad,

disminución de su comprensión y entendimiento, muchas dependencias funcionales,

una baja importante del nivel de cohesión entre los datos y las funciones ylo procedimientos.

Como consecuencia, se dificulta el mantenimiento de este tipo de programas,

se impide su reuso aún en el mismo dominio de aplicación, porque existe dificultad

para fragmentar y modular el código, ocultar los detalles de implantación, extender y especializar la funcionalidad, factorizar en funcionalidades comunes para reuso, e ínter

operar con un menor nivel de dependencias.

Para minimizar estos problemas, Dijkstra [DIJ68] mostró que las piezas de código de un programa podrían ser desarrolladas de manera independiente y David

Parnas [PAR721 introdujo el concepto de Ocultación de Datos. Así han ido surgiendo

nuevos paradigmas de programación, sin embargo hoy en día el paradigma de



desarrollo basado en componentes apoyado en la orientación a objetos prevalece y se

presenta como una alternativa de solución a los problemas de software.

3.3 Análisis e ingeniería de 'dominios[SAN02] El análisis de dominios ha sido identificado como un factor esencial en el reuso

sistemático de software. Por medio de un análisis de dominios se pretende identificar a

las entidades, relaciones, y operaciones básicas de un dominio de aplicación.

Un dominio es un conjunto de sistemas que tienen propiedades comunes, lo

cual proporciona la ventaja de poder estudiar y organizar esas propiedades .comunes

en una colección de componentes reusables para ser usados en la construcción de

nuevos sistemas en el dominio.

El análisis e ingeniería de dominios :I son tendencias de investigación y

desarrollo emergentes de los últimos años para poner fin al problema del reuso de

software. Si bien esto ha sido uno de los puntos más promisorios y de los que se han obtenido más ventajas, también se han encontrado diversos problemas. Los

principales son de tipo técnico, ya que se tieneiuna carencia de herramientas para su

soporte.

El análisis de dominios está en un proceso de maduración, en donde los

resultados hasta ahora obtenidos apenas empiezan a tomar forma. Como ejemplo de

un resultado importante es la especificación de!algunos estándares sobre el reuso de

software que particularmente se pueden utilizar para análisis de dominios.

El 'análisis de dominios [MIL95], sigue un proceso similar al de desarrollo de sistemas de software.

Especificación de requerimientos.

Análisis del problema.

Producción de componentes reusables de amplio dominio.

Pero, las salidas difieren del desarrollo tradicional de sistemas: Componentes

reusables típicamente incluyen estándares y guías (por ej. conocimiento semántico),

as¡ como generalidades y particularidades, tales como los modelos de dominios (por

ej. arquitecturas funcionales genéricas), arquitecturas genéricas de diseño y plantillas, y aun fragmentos de código genérico.

36 Laura Alicia Hernández Moreno

. ... Cenidet 2003//


Las herramientas de indexación, localización y exploración, juegan un papel

muy importante en la organización del conocimiento del software existente para los propósitos (de entradas) de la ingeniería de dominios, pero no proporcionan o generan

componentes utilizables directamente.

El modelado de dominios sirve para tres propósitos fundamentales: 1.

2.

3.

Ayuda a los programadores a entender el dominio de una aplicación.

Se utiliza para el análisis de sistemas. Proporciona una base dependiente de la aplicación para clasificar a los componentes de software existentes, para que las oportunidades de reuso puedan

ser identificadas en el proceso de desarrollo de software tan pronto como sea

posible.

De acuerdo al tipo de actividades que se realiza en un método de análisis de dominios y sus objetivos finales, que dan como resultado modelos, Holmes (HOL931 ha hecho una clasificación de los modelos: 1. Modelos funcionales. Descriptivos y Prescriptivos. 2. Modelos Dinámicos. 3. Modelos de Objetos.

sistema dentro de un dominio, desde el punto de vista del usuario.

problema o dominio de interés.

Los modelos funcionales son utilizados para describir el comportamiento de un

Los modelos descriptivos. describen información acerca del espacio del

Los modelos prescriptivos se enfocan al espacio de solución, o hacia las ciencias de la computación relacionadas con aspectos requeridos para implantar un

sistema en el dominio.

Los modelos dinámicos describen el comportamiento, el control o la secuencia temporal de actividades de un sistema.

Los métodos de análisis de dominios más nuevos utilizan modelos de objetos, apoyándose en las Últimas tecnologias de análisis orientado a objetos. Herramientas

de análisis y diseño orientado a objetos tales como UML, Rational Rose, Visio entre

otras.


Capítulo 3 I4 Marco teórico

3.3.1 Software legado I¡

Faisal y Santanu dan el concepto de software legado de la siguiente forma:

4 Faisal [FA198]. “Son programas que son criticos para /a operación de /as compañías, pero que fueron desarrollados en el lapso de varios años”,

4 Santanu [SAN95]. “Son sistemas de software muy largos, que a menudo corren en millones de líneas de código fuente y han sido adaptados, corregidos y mejorados

lentamente sobre el tiempo para adaptarlos a las necesidades cambiantes de, una

amplia base de usuarios”.

Faisal menciona que por lo general muchos de los sistemas que fueron desarrollados en el lapso de varios años, se crearon en plataformas tecnológicas que hoy

estan cayendo en desuso, tal es el caso de los sistemas hechos utilizando la

programación estructurada o por procedimientos, que se caracterizan por su arquitectura

monolitica y poco reutilizable.

:I

!,

ij

il

Otros programas se desarrollaron, cuando las tecnologías orientadas a objetos

comenzaban a aparecer, por lo cual, la falta de comprensión de estos conceptos

revolucionarios se tradujo en la implementación de disetios deficientes que no proporcionan las ventajas asociadas con estas tecnologías [CAS98].

A medida que las empresas han aceptado el paradigma de desarrollo basado en componentes y experimentado sus ventajas, los procesos de migración de software legado y la adquisición de componentes para el desarrollo de nuevas aplicaciones, han adquirido mayor interés. Por lo cual, podemos decir que la construcción de frameworks de componentes a partir de software legado es una.nueva línea d

Documents

Centro Nacional de Investigación y Desarrollo ... - CENIDET · 2.1.2 Reestructura de código legado C en C++ 2.1.3 Extracción automática de clases de sistemas legados .. 2.1.4