Reingenierı́a de Software

Juan Carlos González Moreno

DPTO . DE INFORM ÁTICA Y AUTOMÁTICA .

FAC . MATEM ÁTICAS, (UCM)
AV. COM PLUTENSE S / N , MADRID (SPAIN), E-28040
Email: jcmoreno @dia.ucm.es

Informe Técnico: DIA 22.96

 Reingenierı́a
de
Software
Juan C arlos G onz ález Moreno

Resumen

La popularidad de la reingenierı́a de software ha ido en aumento desde mediados de los

años 80. El motivo parece evidente, si el software que se ha venido utilizando hasta el
momento ha sido válido y presenta aspectos significativos para seguir siendo utilizado,
¿por qué no intentar obtener todo lo que se pueda de él antes de remplazarlo? Por otra
parte, durante la década de los 80 se han utilizado técnicas de reestructuración como
solución a problemas de mantenimiento que no han podido ser fijados modificando úni-
camente el flujo de control.

La reingenierı́a de software es importante para tener bajo control software que requie-
re un alto coste de mantenimiento, para recuperar aspectos y propiedades del software
existente y, en especial, para establecer la base para una futura evolución del software.
El crecimiento que está experimentando esta rama de la se fundamenta en distintos
aspectos que van a ser tratados a lo largo de las próximas secciones:
! Reusabilidad,
! Reestructuración,
! Ingenierı́a inversa,
! Nuevas herramientas .

0
1 INTRODUCCION 1

1 Introducción
Teniendo en cuenta que el gasto en actividades de mantenimiento puede llegar a alcan-
zar cifras de entre el 50-80 % ([11]) del presupuesto de las empresas, no es extraño que
se busquen dı́a a dı́a nuevas técnicas que reduzcan dichos costes, aumenten la producti-
vidad y mejoren los servicios. Una de las tecnologı́as que desde hace tiempo se ha venido
defendiendo para reducir costes es la reestructuración. Dicha tecnologı́a consiste en la
transformación de código antiguo no estructurado, en código estructurado funcional-
mente equivalente. En la actualidad al menos un 10 % de las compañı́as dedicadas al
desarrollo de software están adoptando esta tecnologı́a con vistas a mejorar la calidad
de los productos que han de mantener. Frente a esta aproximación consistente en mejo-
rar el código (documentación y estructuración), muchas compañias prefieren la adopción
de técnicas de reingenierı́a, sobre todo mediante la utilización de herramientas semiau-
tomáticas, como una ayuda inestimable para sus técnicos de mantenimiento, a los que
les facilita enormemente la comprensión del código “alienı́gena ” realizado por equipos
de trabajo distintos y realizados en base a conceptos de desarrollo muy distintos. En los
últimos años, lo que se ha dado a denominar “Ingenierı́a inversa ”, está presentando un
considerable auge. La idea en este caso es intentar reconstruir los modelos, tanto de es-
pecificación como de diseño, sobre los que se sustentan las implementaciones que son
objeto de revisión.

Debido a la juventud del concepto y las diferentes aproximaciones existentes, el pri-

mer punto que debemos intentar aclarar, es “¿ qué entendemos por R e in g e ni e rı́ a d e S o ft-
w a r e ? ”. En general, podemos considerar que la reingenierı́a de software ([2]) es cualquier
actividad diseñada para:

" Conseguir la comprensión personal del software, o

" Conseguir el software con vistas a: un mantenimiento incremental, su reusabilidad,
o una previsión de su evolución.

En esta definición el término “software” incluye (además de codigo fuente) documenta-

ción, representaciones gráficas y análisis. Los análisis conciernen al código fuente, al
diseño, a las especificaciones, a las comprobaciones de datos, y a otros documentos que
soportan directamente el desarrollo y/o el mantenimiento de software.

1.1 Objetivos.-
El principal objetivo que perseguimos con la elaboración de este informe, es la familiari-
zación del lector con un nuevo vocabulario emanado de los conceptos relativos al man-
tenimiento y soporte de sistemas evolutivos. Entre estos destacan conceptos como los
de “Reingenierı́a ” e “Ingenierı́a Inversa ”. Muchas de las ideas expuestas a lo largo del te-
ma hacen referencia a prácticas actuales y pueden encontrarse incluso implementadas
dentro de numerosas herramientas de nueva generación.

Pretendemos que las próximas secciones sirvan como toma de contacto con facetas nue-
vas e interesantes de la y motiven la discusión y el debate sobre la relevancia de
adoptar nuevos enfoques para poder dar soluciones a las nuevas problemáticas.
2 SIGNIFICADO Y PAR TES DE LA REINGENIERIA 2

1.2 Contenido.-
Presentamos un contenido basado no sólo en los conceptos que rodean esta nueva dis-
ciplina, sino también en el desarrollo de algunos casos prácticos. Dividimos la presen-
tación de este nuevo “paradigma ” en las siguientes secciones:

# Sig nifi c a d o y p a rt e s d e l a r e in g e ni e rı́ a

$ R e e stru c tur a c i ó n
% R e in g e ni e rı́ a d e r e c i c l a j e
& In g e ni e rı́ a in v e rs a
' D e s c u brimi e nt o d e o b j e t os

2 Significado y partes de la reingenierı́a

En la introducción hemos definido la Reingenierı́a de Software como cualquier actividad
diseñada para:

" conseguir la comprensión personal del software, o

" conseguir el software con vistas a: un mantenimiento incremental, su reusabilidad,
o una previsión de su evolución.

Sin embargo, esta no es una definición estándar, de hecho diversos autores proponen
diversas definiciones ası́ por ejemplo GUIDE ([10]) la define cómo:

“ El proceso de modificar los mecanismos internos de un sistema (programa ), o las

estructuras de datos de un sistema (programa ) sin cambiar su funcionalidad. ”

Mientras que Chikofsky y Cross ([5]) la definen como:

“ El examen y modificación de un elemento del sistema con objeto de reconstruirlo

en un nuevo formato y su consecuente implementación . ”

Con respecto a las definiciones anteriores, observemos que la primera centra su aten-
ción en las actividades de la reingenierı́a en vez de en su significado o en su proceso. Por
otra parte las dos ‘ultimas definiciones no permiten que algunas actividades, que si lo
hacen según la otra definición, caigan dentro del campo de la reingenierı́a; mientras que
la primera subsume todas las actividades permitidas en las otras dos.

Por otra parte, existen un gran número de sinónimos que son empleados para referir-
se a la anteriormente definida reingenierı́a (re-ingenierı́a, o Reingenierı́a ), entre los más
importantes destaquemos:

! Perfeccionamiento.
! Prolongación.
! Renovación.
! Modernización.
2 SIGNIFICADO Y PAR TES DE LA REINGENIERIA 3

! Ingenierı́a de redesarrollo.
! Ingenierı́a de reutilización.

Con objeto de facilitar la comprensión de lo que vamos a entender como una actividad
de reingenierı́a observemos la figura 1 tomada de [2].

Vista de clase 1: Reingenieria

Vista de clase A1:
No procedural y/o meta
Analisis
Ej: Especificaciones

Ingenieria inversa, Ingenieria

Componer
recuperacion de diseno,
Normal
Generar reingenieria
Vistas

Vista de clase 2: Reingenieria

Base de Vista de clase A2:
Pseudo-procedural y/o
Informacion arquitectonico Analisis
Ej: DFD

Descomponer Ingenieria inversa, Ingenieria

recuperacion de diseno,
Capturar reingenieria Normal

Reingenieria,
Vista de clase 3: reestructurar Vista de clase A3:
Procedural
Analisis
Ej: Codigo fuente

Figura 1: Reingenierı́a y términos afines.

En la figura 1 podemos distinguir 5 principales ideas que se encuentran asociadas al

concepto de reingenierı́a:
( Vist a s d e l so ft w a r e .- Una vista del software, no es más que una representación del
software o un informe sobre software. Aunque no es necesario que dicha represen-
tación sea una vista para una persona, lo normal es cuando hablemos de vistas de
software estemos pensando en una representación que potencialmente puede con-
sultar y entender un ser humano.
# B a s e inf or m a tiv a (o d e inf or m a c i ó n).- La base de información es el almacén don-
de podemos localizar toda la información disponible sobre el software. Puede ser
cargada o recuperada de tres maneras distintas:

(a) Descomponiendo el software en objetos y relaciones.

(b) Construyendo de manera incremental objetos y relaciones utilizando herra-
mientas que crean y añaden conociiento en la base.
(c) Importando información de otras bases de información.

$ D e s c o m p osi c i ó n.- Es el proceso por el que transformamos una vista en objetos y al-
macenamos las relaciones en la base. Por ejemplo, los copiladores frecuentemente
descomponen los programas en en árboles sintácticos abstractos.
2 SIGNIFICADO Y PAR TES DE LA REINGENIERIA 4

% C o m p osi c i ó n.- En este caso, generamos una nueva vista (o información), a partir
de la información existente en la base. La herramienta o la persona encargada de
realizar esta actividad, construye la nueva vista a partir del descubrimiento de ob-
jetos relevantes y relaciones entre los mismos existentes en la base de información.
Por ejemplo, los compiladores, a menudo generan código mediante un recorrido a
través del grafo semántico que representa el programa.
& Tr a nsf or m a c i ó n.- La noción de transformación es central dentro del proceso de rein-
genierı́a. En todo el proceso, constantemente se está transformando una informa-
ción (o vista del software) en otra equivalente. Por ejemplo código fuente en código
fuente estructurado, actualizaciones en el diseño, correcciones en la especificación,
cómputos estáticos de medidas,
Como hemos podido apreciar, distintos autores enfatizan en distintos aspectos de man-
tenimiento de sistemas para definir lo que ellos consideran que es la labor de la rein-
genierı́a. Dependiendo del enfoque que queramos abordar podremos considerar como
válida cualquiera de las definiciones anteriores, aunque un estudio más detallado y mi-
nucioso nos permite observar que quizás sea la primera la que conlleva una visión más
general y menos comprometida de lo que debe ser la tarea de reingenierı́a. Haciendo
nuestras las palabras del doctor Arnold ([2]), podemos decir que la labor de reingenierı́a,
es importante por diferentes motivos :

! La reingenierı́a puede ayudar a reducir el riesgo en la evolución de una organización.

En efecto, para extender las capacidades de un software existente las organizacio-
nes pueden: construir nuevo software, evolucionar el existente, hacer una labor de
reingenierı́a y evolucionar el existente, utilizar generadores de aplicaciones, u obte-
ner partes o paquetes software nuevos.

Si las dos últimas opciones no estan disponibles, las organizaciones (empresas) se

enfrentan al dilema de desarrollar un nuevo software o evolucionar el existente.
Una simple evolución manual del software existente tiende, usualmente, a dificultar
posteriormente el cambio del software, o a disminuir la confianza sobre el software
cambiado. Por otra parte, la construcción de un nuevo software desde cero, suele
ser caro e incluso incierto. En estas circunstancias, la reingenierı́a de software y la
posterior evolución del software sobre el que se ha aplicado, puede ofrecer un me-
nor riesgo de cambio, y ayudar a salvaguardar la utilización de un software dentro
de la organización mejor que una nueva construcción o una simple evolución a la
antigua usanza.
! La reingenierı́a puede favorecer la recuperación o la rentabilización del capital inverti-
do en software. Es obvio que las empresas durante estos últimos años han invertido
gran cantidad de dinero en la compra y actualización de sus aplicaciones software;
mucho más en el caso de empresas dedicadas al desarrollo de software. Puesto que
no podemos presuponer que todo el esfuerzo realizado ha sido valdı́o (de hecho po-
demos considerar que los resultados han sido satisfactorios), parece evidente que
la adopción de nuevas técnicas y la compra de nuevos sistemas (hardware y/o soft-
ware) no debiera implicar el abandono del software que hasta la fecha ha venido
utilizándose satisfactoriamente. En estos casos, la reingenierı́a ayuda a construir
el nuevo software a partir del existente, ayudando a las empresas a rentabilizar sus
anteriores adquisiciones.
2 SIGNIFICADO Y PAR TES DE LA REINGENIERIA 5

! La reingenierı́a puede hacer más sencillos los cambios de software. La reingenierı́a

aumenta la productividad en el mantenimiento de sistemas, al hacer que el progra-
mador comprenda más fácilmente el código con el que trabaja. Además proporciona
a la empresa una mayor flexibilidad al poder modificarse más rápidamente el soft-
ware con objeto de acomodarse a los cambios de actividades de la empresa.
! La reingenierı́a es un “ gran negocio”. Es evidente por lo que hemos dicho en los
apartados anteriores, que el mercado potencial para la reingenierı́a abarca al con-
junto de las aplicaciones existentes y futuras; esto supone un mercado de billones
de dólares que se encuentra abonado para recibir con entusiasmo las nuevas técni-
cas.
! Las capacidades de reingenierı́a extienden las posibilidades de las moder nas herra-
mientas . La reingenierı́a puede verse como una especie de vehı́culo de trans-
ferencia de tecnologı́a, que permite a los viejos sistemas su traslado a nuevas y más
potentes herramientas. Su incorporación en herramientas por parte de las
empresas de desarrollo, aumenta el valor de estas y les permite introducirse en un
nuevo mercado.
! La reingenierı́a es un catalizador en el mantenimiento automático de software. La
mayor parte de las herramientas de reingenierı́a siguen el patrón de la figura 2.
Son básicamente almacenes, con caminos especializados para obtener información
interna y externa. Una parte importante de dicha información ha sido preanaliza-
da y almacenada para su posterior uso como valioso material para el futuro nuevo
análisis, la automatización del proceso y la investigación del mantenimiento del sis-
tema.

Producto de

Trabajo Descomponer
Software Analizadores
Base informativa
Informacion representada
en un formato intermedio

Componer
Visualizaciones
Nuevas vistas del producto:

* Formato
* Graficos
* Documentaciones
* Metricas
* Logica
* Informes
Otros productos de trabajo

Figura 2: Proceso de Reingenierı́a Automática.

! La reingenierı́a es un catalizador en la aplicación de técnicas de Inteligencia Artificial

( ) en la solución de problemas de reingenierı́a. Tal y como hemos comentado el
proceso de reingenierı́a se fundamenta en la realización de una serie de transfor-
maciones. Históricamente el campo de investigación sobre transformaciones au-
tomáticas ha sido abordado dentro del campo de la , tal es el caso de los sis-
temas basados en la producción de reglas y de los procesadores de lenguajes. Más
2 SIGNIFICADO Y PAR TES DE LA REINGENIERIA 6

recientemente, las transformaciones han experimentado un importante crecimiento

dentro de la lógica for mal y de los sistemas de reescritura. Para todos estos cam-
pos de investigación la reingenierı́a se está ofreciendo como un campo abonado en
el que poder aplicar el trabajo de los últimos años.

2.1 La tecnologı́a de reingenierı́a

Con objeto de concretar en mayor medida el concepto de reingenierı́a, podemos preci-
sar cuales son los grandes temas que abarca, junto con las tecnologı́as asociadas a los
mismos. En concreto, dichos temas son:

" P e rf e c c io n a mi e nt o d e so ft w a r e .- Con relación a este tema, nos encontramos con

que las principales tecnologı́as que se vienen utilizando en perfeccionar o mejorar
el software existente son:
! R e e stru c tur a c i ó n d e l so t w a r e . Consiste en la modificación del software existen-
te para hacerlo más legible o más fácil de matener. En la actualidad la aplica-
ción de este tipo de tecnologı́as, implica cambios en las estructuras de control
del código fuente.
! Redocumentación, anotación y actualización de la documentación. Supone la
realización de actualizaciones correctas de la información existente sobre el
software. El éxito de este tipo de tecnologı́as se basa, en gran medida, en la
utilización de herramientas automáticas adecuadas.
! R e in g e ni e rı́ a d e r e c i c l a j e , o In g e ni e rı́ a d e R e utiliz a c i ó n. El objetivo en este caso,
es modificar el software con objeto de aumentar su capacidad de reutilización,
localizando partes del código que pueden ser modificadas (sin pérdida de fun-
cionalidad), por un código equivalente que puede ser almacenado en librerı́as
de componentes reutilizables.
! Remodularización. Supone el cambio de la estructura modular de un sistema.
A menudo, esto depende de la realización de diferentes análisis sobre la co-
hesión que aportan distintas agrupaciones de componentes del software exis-
tente, realizadas en base a distintas caracterı́sticas. También es frecuente la
realización de medidas sobre el acoplamiento existente.
! Reingenierı́a de datos. Intenta mejorar los datos que maneja el sistema. Dife-
rentes esquemas de datos pueden ser reorganizados y actualizados. también
es posible consolidar multiples esquemas en uno sólo, conseguir que algunas
entradas del diccionario de datos sean ahora semánticamente consistentes, y
eliminar datos no válidos. La aplicación de este tipo de tecnologı́as suele ser
el prolegómeno de otras tareas, a menudo relacionadas con migraciones del
software existente a nuevas bases de datos.
! Reingenierı́a del proceso comercial. Hoy en dı́a, la flexibilidad de las arquitec-
turas de software y la automatización de la tecnologı́a de la información, están
consiguiendo que el software influya en la organización de las empresas, fren-
te a la situación tradicional que hacı́a que la organización de las empresas in-
fluenciara en el software que se utilizaba. Distintas experiencias en grandes
organizaciones empresariales han demostrado, que se puede conseguir un im-
portante incremento en la productividad cuando la reestructuración del pro-
ceso empresarial se lleva a cabo con la utilización de herramientas software
adecuadas.
2 SIGNIFICADO Y PAR TES DE LA REINGENIERIA 7

! Análisis de mantenimiento, económico, y de cartera de inversiones. El análisis

que se lleva a cabo durante el mantenimiento de una aplicación software es
importante, porque permite descubrir partes del sistema que deben ser rede-
sarrollados (con procedimientos de reingenierı́a).
" C o m pr e nsi ó n d e so ft w a r e .- En este caso nos encontramos con las siguientes tec-
nologı́as:
! Ojeo. El ojeo de información consistente en la utilización de editores adecuados
sobre distintas representaciones del software existente, es el método que desde
hace más tiempo se viene empleando para comprender el funcionamiento de
una aplicación. Hoy en dı́a, la utilización de hipertextos permite un más rápido
acceso y una mejora en dicha comprensión, como una consecuencia directa
de la utilización de adecuadas referencias cruzadas entre las documentaciones
que constituyen la información de la aplicación.
! Análisis y medición. El análisis y la medida del software, son importantes en
la comprensión de algunos detalles significativos del software existente, tales
como la complejidad del código generado.
! In g e ni e rı́ a in v e rs a , r e c u p e r a c i ó n d e d is e ñ os. Estas nuevas tecnologı́as generan
nueva información sobre el software que se esta analizando, una información
que aparece, generalmente, bajo un nuevo aspecto y que proporciona nuevas
vistas de la aplicación. Habitualmente, la ingenierı́a inversa crea diagramas
de cartas y diagramas de flujo de datos a partir del código fuente. Para ello, se
utilizan herramientas bastante sofisticadas que precisan de cierta legibilidad y
estructuración en el código que reciben como entrada.
" C a p tur a , pr e s e rv a c i ó n, y e xt e nsi ó n d e l c o n o c imi e nt o so br e e l so ft w a r e .- Las prin-
cipales tecnologı́as que se utilizan en este tema son:
! Descomposición. La descomposición de programas permite la extracción de ele-
mentos y relaciones entre los mismos. Estos son almacenados en la base de
información, y permiten el descubrimiento posterior de información adicional
de la aplicación. Para ello se analizan las partes almacenadas y obtenidas como
decomposición del programa, en vez de trabajar directamente sobre el código
fuente de la aplicación.
! R e c u p e r a c i ó n d e o b j e t os. Estas tecnologı́as permiten localizar objetos a partir
del código fuente, lo cual es interesante pues proporciona una visión de
aplicaciones que no lo son.
! Comprensión de programas. La comprensión de programas adopta diferentes
formas. La más usual, suele venir de la utilización de técnicas (manuales o au-
tomáticas), por parte de los técnicos programadores. Otras formas alternati-
vas, pasan por la utilización de almacenes de información sobre programación,
que son utilizados para localizar en una determinada aplicación, diversas ins-
tancias de patrones almacenados.
! Bases de conocimiento y transfor maciones. Las bases de conocimiento y la utili-
zación de transformación de programas son fundamentales en la aplicación de
la mayor parte de las tecnologı́as de Reingenierı́a (tal y como ya hemos comen-
tado). Las transformacones trabajan sobre grafos de programas y de objetos
que se encuentran almacenados en la base de información (base de conoci-
miento). La utilización de nuevas arquitecturas transformacionales, basadas
2 SIGNIFICADO Y PAR TES DE LA REINGENIERIA 8

en la utilización de objetos, son motivo de un creciente desarrollo. En concreto,

destaca especialmente la construcción de nuevas y más potentes herramientas
automáticas que ayudan en el proceso de reingenierı́a.

A lo largo de próximas secciones pensamos profundizar en algunas de dichas tecnologı́as

(aquellas que han sido resaltadas), dejando un estudio más extenso y detallado sobre el
resto de tecnologı́as para que el lector avezado la lleve a cabo empleando toda o parte de
la bibliografı́a que aparece al final del informa. Recomendando de manera especial [2].

2.2 Los riesgos de la reingenierı́a

A pesar de las ventajas y beneficios que presenta la adopción de tecnologı́as de Reinge-
nierı́a en el proceso de mantenimiento de una aplicación, hemos de sopesar su utiliza-
ción, ya que no siempre es aconsejable porque los inconvenientes, o costes asociados
pueden ser mayores que los beneficios. Podemos señalar las siguietes áreas de riesgo
que aparecen cuando consideramos la posibilidad de adoptar alguna de las tecnologı́as
descritas en el apartado anterior.

! Riesgo en el proceso:
Elevado coste en la realización de una reingenierı́a manual.
No alcanzar los beneficios en el plazo requerido.
Falta de justificación económica del esfuerzo de la ingenirı́a.
Falta de criterios administrativos que justifiquen la utilización de reingenierı́a.
! Riesgo personal:
Inhibición de los programadores al comienzo del proceso.
Los programadores con un bajo rendimiento pueden contribuir a que un pro-
yecto de reingenierı́a poco popular se vea como improductivo.
! Riesgo en la aplicación:
Realizar reingenierı́a sin la colaboración de expertos de la aplicación.
Pérdida del conocimiento industrial que se encuentra incorporado en el código
fuente.
Falta de adecuación de los procesos de reingenierı́a.
! Riesgo tecnológico:
La información recuperada no es útil o simplemente no es utilizada.
Producción masiva de documentación (costosa).
No pueden compartirse representaciones obtenidas mediante ingenierı́a inver-
sa.
Falta de adecuación entre la tecnologı́a y el objetivo.
Usar un proceso de reingenierı́a con medios insuficientes.
! Riesgo en las herramientas:
Desaprovechamiento de las herramientas instaladas.
3 REESTRUCTURACION 9

No alcanzar los beneficios en el plazo requerido.

Excesiva dependencia del proceso en herramientas incapaces u obsoletas.
! Riesgo estratégico:
Concluir precipitadamente la necesidad de una solución con reingenierı́a.
Fallos de precisión, a largo plazo, de los objetivos internos.
Falta de visión global: código, datos, proceso de reingenierı́a.
Inexistencia de un plan para la utilización de herramientas de reingenierı́a.

3 Reestructuración
La reestructuración de software consiste en “la modificación de software con objeto de
hacerlo más fácil de comprobar y cambiar, o menos susceptible de tener errores cuando se
realicen cambios en un futuro” ([1]). Al hablar de “Software” incluimos la documentación
interna y externa concerniente al código fuente, junto con el propio código fuente.

Esta definición excluye los cambios de software que buscan otros propósitos, tales como
optimización de código. Aunque la optimización de código implica “reestructuración ” en
cierto sentido, no suele ser el punto clave en el mantenimiento de una aplicación.

Con objeto de ilustrar la necesidad del proceso de reestructuración consideremos el si-

guiente programa escrito en Cobol:

000100 EDIT-COST-INDICATORS.
000110 IF C NOT EQUAL TO ‘‘A’’ OR ‘‘B’’ MOVE ‘‘X’’ TO COST-INDICATOR
000120 GO TO EDIT-COST-INDICATORS-EXIT.
000130 IF C EQUAL TO ‘‘A’’ AND CS EQUAL TO 1 MOVE 0 TO
000140 PGNT ADD 1 TO PGNT MOVE ‘‘007’’ TO SPAG.
000150 MOVE ALL NINES TO ZCOD ADD 1 TO NLCNT
000160 ADD SPC TO CUM-SPC PERFORM OK-RECD-PRINT THROUGH
000170 OK-RECD-SUB-PRINT GO TO EDIT-COST-INDICATORS-EXIT.
000180 IF C EQUAL TO ‘‘B’’ AND CS EQUAL TO 1 MOVE 0 TO PGNT ADD 1
000190 TO PGNT MOVE ‘‘007’’ TO SPAG MOVE ‘‘99999’’ TO ZCOD.
000200 ADD 1 TO NLCNT ADD SPC TO CUM-SPC
000210 PERFORM OK-RECD-PRINT THROUGH OK-RECD-SUB-PRINT
000220 GO TO EDIT-COST-INDICATORS-EXIT.
000230 IF C EQUAL TO ‘‘A’’ OR ‘‘B’’ AND AND CS NOT EQUAL TO 1 ADD 1
000240 TO PGNT MOVE ‘‘010’’ TO SPAG ADD 2 TO NLCNT
000250 ADD SPC TO CUM-SPC PERFORM OK-RECD-PRINT.
000260 EDIT-COST-INDICATORS-EXIT.
000270 EXIT.

Puede apreciarse, en especial si se desconoce el lenguaje, la dificultad de mantenimiento

y de comprensión de este programa. En apariencia (por lo que parece ser la cabecera) su
intención es realizar un proceso de edición sobre ciertos indicadores de coste, pero no
queda claro cual es el significado de dichos indicadores. Por otra parte las variables que
se utilizan no son mnemotécnicas (¿ cual es el significado de SPAG ?), además presenta
una gran dificultad el seguimiento del flujo de control, y que existen más de una instruc-
ción por lı́nea, una falta de normalización en el uso de la identación, e incluso se parten
instrucciones por la mitad. Por si esto no fuera poco, además utiliza constantes litera-
les (“007”) en vez de utilizar constantes sı́mbolocas que favorezcan cambios ulteriores.
Frente a este programa, considérese el siguiente programa funcionalmente equivalente:
3 REESTRUCTURACION 10

000100 EDIT-COST-INDICATORS-1080.
000110 IF COST-INDICATOR = ‘‘A’’ OR ‘‘B’’ ,
000120 IF SUB-COST-INDICATOR = 1,
000130 MOVE 0 TO PAGE-COUNT,
000140 ADD 1 TO PAGE-COUNT,
000150 MOVE ‘‘007’’ TO SPECIAL-AGENT,
000160 MOVE ‘‘99999’’ TO ZIP-CODE,
000170 ADD 1 TO NEW-LINE-COUNT,
000180 ADD SPECIAL-COST TO CUMULATIVE-COST,
000190 PERFORM OK-RECD-PRINT-1470 THROUGH
000200 OK-RECD-PRINT-1580
000210 ELSE
000220 ADD 1 TO PAGE-COUNT,
000230 MOVE ‘‘010’’ TO SPECIAL-AGENT,
000240 ADD 2 TO NEW-LINE-COUNT,
000250 ADD SPECIAL-COST TO CUMULATIVE-COST,
000260 PERFORM NOT-OK-RECD-PRINT-1780,
000270 ELSE
000280 MOVE ‘‘X’’ TO COST-INDICATOR,
000290 EDIT-COST-INDICATORS-EXIT-1260.
000300 EXIT.

En este caso, una rápida inspección del código nos indica que el propósito de este es
llevar a cabo la edición de costes acumulados de agentes especiales. Las instrucciones
aparecen ordenadas una por lı́nea, el seguimiento del flujo de control se realiza de una
manera mucho más simplificada, en la que la identación es homogénea y contribuye a
dicho seguimiento. Las variables tienen nombres con significado, y aunque siguen exis-
tiendo constantes literales, estas se encuentran asociadas a identificadores, facilitando
su posible modificación posterior con nuevos valores.

Es un hecho que con cambios continuados, el software tiende a volverse menos estruc-
turado [9], lo cual se manifiesa con documentación pasada de fecha, códificaciones que
no se ajustan a los estándares, incremento del tiempo que necesitan los programadores
para entender el código existente, incremento en de errores no existentes con los nuevos
cambios, . En este marco la reestructuración es una opción muy importante que
permite mantener controlados los elevados gastos asociados al mantenimiento de una
aplicación. La idea principal es “modificar el software (o la percepción que los programa-
dores tienen de la estructura de software) con objeto de volver a comprenderlo y controlar-
lo”.

La reestructuración de software, no sólo concierne a aspectos de la estructura de soft-

ware que pueden ser “medidos y / o observados”; sino también a las percepciones que la
gente tiene de dicha estructura. Existen múltiples factores que influyen en las percep-
ciones que cada persona tiene de la estructura de software (ver figura 3).

En este contexto cabe preguntarse por la existencia de técnicas y metodologı́as que faci-
liten el proceso de reestructuración. La contestación es muy simple y afirmativa, consi-
deremos la siguiente clasificación realizada en base a la estructura de la figura 3:

3.1 Técnicas
( Código:
Estilo del código.- Facilita la comprensión sin necesidad de modificar la estruc-
tua de control o de datos.
! Formateo de código e impresión adecuada.
3 REESTRUCTURACION 11

Contexto
Administración: Políiticas
Ingenieros de Software

Entorno de programación:
Herramientas
Documentación

Código

Figura 3: Ámbitos de influencia en la percepción de la estructura de software.

! Aplicación de estilos de codificación estándares.

! Reestructuración con ayuda de un preprocesador.
Utilización de paquetes de código reutilizable.- Se utilizan librerias de compo-
nentes para reemplazar software pobremente estructurado, o para a adir nuevo
software.
! Reestructurar código con objeto de hacerlo más reutilizable. Esta técnica
involucra frecuentemente una profunda limpieza del código existente (eli-
minación de parámetros supérfluos, reducción de los efectos colaterales,
)
! Comprar actualizaciones de sistemas antiguos.
! Sustituir un sistema obsoleto, por un paquete software nuevo (incluso de
otra casa comercial).
! Sustituir una parte de un sistema antiguo, mediante la compra de un pa-
quete de software nuevo.
! La aproximación del bocadillo de software. En este caso se pretende, que el
antiguo código poco estructurado sea utilizado como si se tratase de una
caja negra, para lo cual colocaremos un nuevo interfaz de comunicación
entre el usuario y el sistema y dispondremos de una nueva base de datos
donde se almacenen los datos que produzca.
Flujo de control.- En esta categorı́a se incluyen algoritmos y procedimientos en
caminados a reestrucurar los grafos de flujo de control, y las herramientas de
reestructuración de pogramas.
! Eliminación de goto’s. Eliminación por diversas técnicas de los saltos a
marcas que dificultan el seguimiento del flujo de control y que son inne-
cesarios.
! Utilización de marcas booleanas. Se crean grafos de flujo estructurados
mediane la inclusión de variables booleanas.
3 REESTRUCTURACION 12

! Utilización de herramientas automáticas. Sobre todo en lenguajes como

FORTRAN y COBOL
! Doble conversión. Se utilizan herramietas de conversión automáticas pa-
ra pasar de un programa en lenguaje A a otro en lenguaje B y de nuevo se
traduce (generalmente) a otro distinto en lenguaje A. Esta situación es es-
pecialmente frecuente si las herramientaas utilizadas en la conversión son
“distintas”.
Datos.- Aunque históricamente la reestructuración de sosftware se centre fun-
damentalmente en la estructura de control, la reestructuración de datos es
también muy importante. Considérese por ejemplo el paso a forma normal ter-
ciaria de las relaciones de una base de datos relacional, cuya ventaja principal
es reducir la necesidad de propagación en las actualizaciones en la base de da-
tos, cuando se produce una actualización en un registro de dichos datos.
# Documentación:
Actualización de la documentación.
Modularización de sistemas.
$ Programación del entorno. Herramientas:
Actualizar el entorno de programación.
Programar entornos/estaciones de trabajo.
Utilizar métricas de software.
Comprobadores de estándares y otras ayudas.
Colecciones de herramientas.
Sistemas de transformación de programas.
Lenguajes de 4 Generación.
% Ingenieros de sofware:
Formación de profesionales.
Contratación de nuevos programadores, más experimentados con el ‘ambito de
la aplicación.
Reducción de cambios.
& Administración y polı́ticas:
Adecuación a estándares y guı́as de estilo.
Inspecciones y colocación de marcas.

3.2 Metodologı́as
Una metodologı́a es tipicamente un conjunto de pasos para mejorar el software en cual-
quiera de los niveles vistos en la figura 3. Una metodologı́a ayuda en manejo y control
de otras técnicas de reestructuración más especı́ficas. Distinguimos las siguientes me-
todologı́as:
3 REESTRUCTURACION 13

" Rejuvenecimiento de sistemas.- Se define como “la utilización de un sistema exis-

tente como base en la elaboración de un nuevo sistema estratégico”. La metodologı́a
involucra una limpieza del sistema existente que lo haga más eficiente.
" Programa de mejora de software.- Esta metodologı́a es una ambiciosa vı́a de aplica-
ción administrativa, tendendente a “reestructurar el software y a actualizar el funcio-
namiento de las prácticas de ingenierı́a de software en un entor no de mantenimiento
deter minado”.
" Reestructuración incremental.- Esta metodologı́a se encuentra en la lı́nea de la an-
terior pero sin prestar tanta atención a la labor administrativa. Esta aproximación
permite que la “estructura ” sea definida por el usuario (en vez de ser construida
dentro de la propia reestructuración); la reestructuración se realiza en pequeñas
partes manejables. Un sistema puede beneficiarse de las aportciones de una rees-
tructuración sin necesidad de ser totalmente reestructurado. Esta aproximación
es de particular interés en la evitación de introducir estructuraciones pobres como
resultado del mantenimiento.
" Renovación de software.- Esta aproximación tiene que ver con la actualización de
la documentación de software, de la especificación del sistema, y de las pruebas del
sistema.

También pueden utilizarse para realizar reestrucutraciones de software mecanismos o

técnicas utilizadas en la ingenierı́a inversa (comprensión de software y recuperación de
diseños).

3.3 Conclusiones y plan de reestructuración

Como conclusiones principales, del proceso de reestructuración de software, podemos
indicar que:

" El código reestructurado necesita cierto tiempo para ser utilizado.

" La reestructuración de código en grandes sistemas, es amenudo insuficiente.
" Es preciso reestructurar también la documentación
" El entorno de programación afecta a la percepción de la estructura de software.
" El coste de la reestructuración puede ser cuantificado y previsto.
" Es necesario decidir, de manera sistemática, como resolver problemas empleando
técnicas de reestructuración.
" Planificar la conservación de la estructura de software que se obtenga después de
reestructurar.

Un posible plan de actuación para llevar a cabo la reestructuración de software, puede

ser el siguiente:

( Hablar con el personal de mantenimiento sobre sus opiniones sobre los problemas
que encuentran en su trabajo.
3 REESTRUCTURACION 14

# Identificar las tareas actuales en las que una polı́tica de reestrucutración puede
ahorrar tiempo, reducir los problemas de mantenimiento, o permitir cualquier otro
beneficio significativo.
$ Ajustar una aproximación de reestrucutración adecuada a los problemas de man-
tenimiento más apremiantes. Una reestructuración adecuada, es aquella que pre-
senta un mayor impacto sobre las tareas del punto anterior.
% Realizar análisis de viabilidad y de transferencia tecnológica de la aproximación se-
leccionada. Un análisis de transferencia tecnológica examina las componentes tan-
to sociales como psicológicas que afectan a la aceptación y utilización de la aproxi-
mación elegida.
& Seleccionar una técnica de reestructuración, planificar su utilización, y emplearla.
' Realizar un seguimiento del esfuerzo de reestructuración, preferentemente median-
te la recolección de datos y aplicación de medidas sobre la estructura. También
realizar el seguimiento de la mejora en el mantenimiento y evaluar los resultados.

La figura 4 muestra una posible planifiación para estudiar la eficacia de una herramienta
de reestructuración.

Programa
elegido

Recodificador

Programa original Programa recodificado

Mediciones

Cambios en ambas versiones

con distinto personal

Cambios en el Cambios en el
programa original programa recodificado

Mediciones y
Resultados
comentarios

Figura 4: Plan de estudio de eficacia de una herramienta de ayuda en la reestructura-

ción.
4 REINGENIERIA DE RECICLAJE 15

4 Reingenierı́a de reciclaje
En un gran número de aplicaciones, la construcción se ha venido llevando a cabo sin
tener en cuenta la posibilidad de reutilizar las componentes del sistema. Hoy en dı́a,
una vez que dichas aplicaciones se han comprobado de utilidad y su uso se ha exten-
dido, ha aparecido la necesidad de crear nuevas aplicaciones a partir de aquellas; sin
emabargo, por falta de previsión no es posible reutilizar mucho de lo ya desarrollado, di-
señado o especificado. Un apartado muy importante dentro de la reingenierı́a tiene por
misión la búsqueda e identificación de componentes reusables dentro de las aplicacio-
nes existentes, con vistas a su incorporación en depósitos y su posterior utilización en
la construcción de nuevas aplicaciones.

La reingenierı́a de sistemas ([2]) cuyo objetivo es reciclar y reutilizar componentes soft-

ware de aplicaciones ya existentes, se encuentra enmarcada en un nuevo ciclo de vida
(véase Figura 5), que es guiado por la utilización de componentes reusables.

Reingeniería
Buscar y
(Salvage) Clasificar Comprender

Reusar
Adquirir

Certificar
Almacén
Diseñar
Sistema 1

Sistema 2
Vuelta
Ver y
atrás Medir Sistema n

Figura 5: Ciclo de vida de reutilización.

5 Ingenierı́a inversa
La ingenierı́a inversa, es la actividad de definir una representación del sistema más abs-
tracta y fácil de comprender que la actualmente existente ([6]). La aplicación de inge-
nierı́a inversa nos hace retroceder desde el código hasta las etapas de diseño e incluso
de análisis, en un proceso en el que se puede recuperar información perdida e incluso
generar nueva información sobre la aplicación estudiada.

Dentro de la ingenierı́a inversa podemos distinguir entre:

" Descompilación. Con esta denominación se identifica el proceso de recuperación del

código fuente a partir del código objeto que se encuentra operativo.
" Ingenierı́a revertida. Esta actividad tiene por objeto el recuperar la estructura de
programa que fué diseñada originalmente para la aplicación que es objeto de estu-
dio.
6 RECUPERACION DE OBJETOS 16

" Ingenierı́a invertida. En ocasiones, el punto fundamental no es recuperar la estruc-

tura de programa, sino recuperar el modelo inicial del sistema, y descubrir los re-
quisitos que se fijaron, con objeto de reestructurarlos, descubrir requisitos que de-
bieron ser abandonados por restricciones de implementación, e incluso descubrir
otros que no se identificaron por diversas causas. Este es el propósito de la inge-
nierı́a invertida.

6 Recuperación de objetos
En la actualidad la fase de mantenimiento de software ha dejado de ser la cenicienta del
proceso de desarrollo, para convertirse sin lugar a dudas en el gran protagonista dentro
de la Ingenieria de Software, en especial mediante la utilización de tecnologı́as . La
formulación de las siguientes preguntas se ha vuelto un tema común en un gran número
de empresas dedicadas al desarrollo de aplicaciones o simplemente a la utilización de
software:
" ¿Cómo podemos construir un modelo de un sistema que nos permita razonar sobre
las modificaciones futuras?
" ¿Cómo podemos reemplazar gradualmente diversas partes de un sistema?
" ¿Cómo podemos integrar las técnicas modernas de orientación a objetos en un sis-
tema existente?
Estas preguntas son “contestadas” mediante la aplicación de tecnologı́as orientadas a
objetos en las que, las entidades reales del dominio de aplicación se modelan mediante
objetos y asociaciones entre estos. El modelo del sistema obtenido puede utilizarse como
una “aplicación ” entre las entidades reales del dominio de aplicación y los elementos de
programación del sistema existente.

Las metodologı́as de desarrollo orientadas a objetos, son de gran utilidad en la moder-

nización gradual de viejos sistemas software ([6]), es decir en su reingenierı́a. La técnica
utilizada para acometer dicha modernización se fundamenta en dos principios:
! Un cambio en el dominio de aplicación es en su mayorı́a “local ” en el sentido de
concernir al comportamiento de una entidad real claramente delimitada.
! El modelo de un sistema puede utilizarse para describir un sistema diseñado
de una manera no orientada a objetos.
Por otra parte, hay que tener en cuenta que no es realista el querer reemplazar un “buen
sistema antiguo” por otro completamente nuevo, ya que tal cambio involucra demasiados
recursos. Tal y como se indica en la figura ?? hay que sopesar los aspectos de facilidad
de cambio y el valor que tiene para la empresa el producto que se está analizando.

Definiendo la reingenierı́a como:

“El proceso de crear una descripción abstracta de un sistema, razonar sobre un cam-
bio del sistema a un elevado nivel de abstracción, y reimplementar el propio sistema.”

Puede modelizarse dicha definición mediante la siguiente ecuación:

6 RECUPERACION DE OBJETOS 17

Cambio

Mantener Mejorar

Descartar Reingeniería

Valor para la empresa

Figura 6: Matriz de decisión. Qué hacer con un sistema antiguo

“Reingenierı́a Ingenierı́a inversa Ingenierı́a Nor mal ”

En la que consideramos que la actividad que define la Ingenierı́a inversa es aquella que
“está encaminada a definir de una manera más abstracta, y fácil de comprender, la repre-
sentación del sistema. ”. Y dónde representa un “Cambio de funcionalidad o de técnica
de implementación del sistema.”

El objetivo fundamental de la Ingenierı́a Inversa (tal y como ya se ha detallado en una

sección previa) es capturar un conocimiento preciso del comportamiento y de la estructura
del sistema, que facilite su comunicación.

Con objeto de poder llevar a cabo dicha misión de una manera satisfactoria es preciso
que contemos con:

! Una representación concreta (grafo) de las componentes del sistema y de sus

interrelaciones. Recogerá detalles de implementación.
! Una representación abstracta (grafo) del comportamiento y de la estructura
del sistema. Libre de detalles de implementación.
! Una correspondencia entre las componentes de ambas representaciones.
Mostrará la relación existente entre el mundo ideal y el mundo concreto.

Las labores de reingenierı́a, y en particularas las actividades encaminadas a recuperar

objetos de aplicaciones existentes, presentan dos dimensiones ortogonales que hay que
considerar durante el proceso. A saber:
6 RECUPERACION DE OBJETOS 18

" Un cambio de funcionalidad.- En este caso hay que tener en cuenta que:

Un cambio en la orientación del “negocio” implica un campio en la fun-

cionalidad de la aplicación.
No “afecta” a la implementación del sistema.

" Un cambio en las técnicas de implementación.- Los puntos fundamentales

en este apartado son:

El cambio puede implicar un cambio en el lenguaje de codificación (paso

del lenguaje C a C ), o en el sistema de almacenamiento de datos (paso
de una base de datos de tipo relacional a una base de datos ).
El proceso es muy “duro”, incluso con la ayuda de herramientas especı́fi-
cas.
Como observaciones particulares indiquemos que:

" Cuando “una parte” de la aplicación cambia su técnica de implementación,

es preciso facilitar la comunicación entre ambas partes del sistema.
" Y que una funcionalidad “básica” consiste en la utilización “de” o “por parte
de” otra aplicación.
Una vez enmarcado el proceso que debe acomenterse, surge la pregunta ¿ cuales son los
pasos a seguir? La contestación viene dada por la siguiente secuencia de actividades:

1. Identificar las relaciones entre las distintas componentes del sistema y crear una
representación más abstracta del mismo. (Por ejemplo mediante la construcción
de un diagrama de flujo de datos para representar las funciones C y un modelo de
entidad relación para la base de datos).
2. Razonar sobre los cambios de funcionalidad a un nivel más abstracto.
3. Rediseñar el sistema, pasando de la representación más abstracta a la representa-
ción más concreta (ingenierı́a normal). Se deben tener en cuenta los cambios en la
técnica de implementación.

Para poder llevar a cabo dichas actividades es preciso que contemos con:

! Una representación del sistema tal cual es.

! Una representación lógica del sistema, a un nivel que posibilite el razonamiento
sobre cambios de funcionalidad.
! Una manera de capturar decisiones de diseño, es decir contestación a la pregunta:
¿ por qué el sistema se ha implementado ası́ ?
! Una técnica o mecanismo que facilite la comunicación entre dos partes implemen-
tadas con técnicas distintas (por ej. comunicación entre código C y código C , y/o
viceversa).
! Una técnica que delimite la parte del sistema que queremos explorar.

Un punto importante a tener en cuenta son los posibles escenarios de aplicación de esta
tecnologı́a. Entre estos podemos destacar los siguientes:
6 RECUPERACION DE OBJETOS 19

! Un cambio completo en la técnica de implementación, y ninguna modificación en la

funcionalidad del sistema. En este caso conviene destacar que esta aproximación
rara vez se aplica a un gran sistema.
! Un cambio parcial en la técnica de implementación y ninguna modificación en la fun-
cionalidad del sistema. Ahora el objetivo principal es que la nueva parte construida
siguiendo una polı́tica crea que el resto del sistema también ha sido construido
con esa polı́tica.
! Cambios en la funcionalidad del sistema. En este caso el escenario se presenta como
un proceso de ingenierı́a normal. Se añaden los cambios de funcionalidad al modelo
del análisis y se procede hasta la implementación siguiendo un desarrollo .

Los pasos que hay que seguir en la aplicación de esta tecnologı́a a las situaciones ante-
riores son:

" Realización de una reingenierı́a completa, sin cambios de funcionalidad:

( Preparar un modelo analı́tico. (Véase figura 7)
! Asimilar la información existente sobre el sistema (especificación, instruc-
ciones de manejo, manuales de mantenimiento, documentos de diseño, códi-
go fuente, ), es decir sus “elementos de descripción ”.
! Aislar los “elementos de descripción primitivos”, lo cual implica en particu-
lar, aislar los e l e m e nt os q u e r e pr e s e nt a n e l sist e m a r e a l
! Preparar el “módelo analı́tico” propiamente dicho, mediante la localización
de objetos utilizando alguna de las metodologı́as existentes ([3, 4, 7,
8]).

Sistema real

Modelo analítico

Implementación

Figura 7: Transformación de sistemas: Reingenierı́a completa s.c.f.

# Establecer una correspondencia entre los objetos y la implementación del siste-

ma existente (Ver figura 8). En este proceso existen las siguientes restricciones:
6 RECUPERACION DE OBJETOS 20

! Todos los objetos deben proceder de algún elemento de descripción primi-

tivo.
! Todas las aristas del “grafo abstracto” deben proceder de algún elemento
de descripción primitivo.
Además los objetos abstractos y las relaciones de herencia identificadas deben
proceder de al menos un elemento de descripción primitivo.

Sistema antiguo

Modelo analítico

Primitivas

Figura 8: Transformación de sistemas: Correspondencia entre modelos

$ Rediseñar el sistema utilizando técnicas de ingenierı́a 0abrOO.

" Realización de una reingenierı́a parcial, sin cambios de funcionalidad:
( Identificar la parte del sistema que debe ser reimplementada. Se crean dos sub-
conjuntos de elementos de descripción primitivos (Ver figura 9):

Figura 9: Transformación de sistemas: Reingenierı́a parcial s.c.f.

! Los que cambian.

! Los que delimitan el entorno de los que cambian:
No estan recogidos dentro de los que cambian.
6 RECUPERACION DE OBJETOS 21

Son adyacentes a los que cambian y presentan una relación de depen-

dencia.
# Preparar el modelo analı́tico de la parte que debe ser modificada y de su entor no.
$ Buscar la correspondencia entre los objetos y el sistema existente. Distinguimos
dos subconjuntos de objetos:
! Los que representan cambios en el subsistema abordados con la nueva
técnica de implementación
! Los que envuelven a los anteriores realizando la comunicación con la parte
del sistema que no se modifica.
% Repetir los pasos anteriores hasta conseguir un interfaz de comunicación acepta-
ble entre la parte que se esta modificando y el resto del sistema. Hay que evaluar
el interfaz buscando un coste de implementación aceptable.
& Realizar en paralelo:
! Diseñar el nuevo subsistema y sus interfaces con el sistema antiguo.(Ver fi-
gura 10).

Figura 10: Transformación de sistemas: Creación de interfaces

En este punto, y gracias al encapsulamiento de los objetos, se fundamenta

la posibilidad de reemplazar gradualmente el antiguo sistema en un siste-
ma .
! Modificar el sistema antiguo y añadir un interfaz adecuado con el nuevo sub-
sistema.
' Integrar y comprobar el nuevo subsistema y las modificaciones de la parte an-
tigua.
" Realización de una reingenierı́a con cambios de funcionalidad:

En este caso se procede añadiendo los cambios en la funcionalidad en el modelo

analı́tico y se implementan utilizando técnicas (Ver figura 11).

Los principales pasos en este subproceso son:

( Cambiar el modelo analı́tico en función de los requisitos. Distinguimos tres

subconjuntos de objetos:
! El subconjunto de los nuevos objetos procedentes del cambio de funciona-
lidad
! El subconjunto de elementos existentes que cambian su funcionalidad.
6 RECUPERACION DE OBJETOS 22

Figura 11: Transformación de sistemas: Reingenieria con cambio de funcionalidad

! El subconjunto de elementos que no se ven afectados por la modificación.

# Diseñar el sistema con una metodologı́a .

6.1 Conclusiones
Por último, y como conclusión de esta sección hacemos las siguientes reflexiones:

) El mantenimiento de aplicaciones predomina en tiempo y, a menudo, en recursos

al resto de fases del ciclo de vida de software.
) Los cambios en las actividades de una empresa suponen un envejecimiento más
rápido del sistema software existente.
) Los cambios durante la fase de mantenimiento acercan al sistema a un punto sin
retorno, en el que el balance coste-eficiencia es desfavorable.
) Una delimitación efectiva de las partes del sistema que son candidatas para ser mo-
dificadas supone mitigar los cambios a realizar en el sistema.
) Existen métodos prácticos para realizar reingenierı́a, y acabamos de presentar uno
basado en la modelización según una polı́tica .
) El nuevo modelo puede servir como base para futuros desarrollos, y extensio-
nes futuras pueden ser incorporadas de una manera “fácil” adaptando los interfaces
de comunicación.
) ¿ Reingenierı́a sustituto o parte activa del ciclo de vida de una aplicación?.- A la vista
de los resultados que se están consiguiendo, al aumento en la aplicación de he-
rramientas que favorecen la labor de reingenierı́a sobre los productos que
se han elaborado con ellas, y a la cada vez mayor utilización de librerias de com-
ponentes reusables (por ej. librerias C ), parece razonable preguntarse si en un
futuro no muy lejano la utilización de la reingenierı́a sobre aplicaciones existentes,
no constituirá una alternativa válida al proceso de ingenierı́a habitual. Es decir, ¿
asistiremos en los próximos años a un aumento, cuantitativamente significativo, en
el reciclaje de aplicaciones, tal y como está ocurriendo en otros ámbitos empresa-
riales ?
REFERENCIAS 23

Referencias
[1] R. S. Arnold. Software reestructuring. Proc. IEEE, 77(4):607–617, April 1989.
[2] R. S. Arnold. Software Reengineering. IEEE Computer Society, 1994.

[3] G. Booch. Obeject-Oriented analysis and Design. With applications. The Benja-
min/Cummings, 2 edition, 1994.
[4] G. Booch. Diseño orientado a objetos, con aplicaciones. Addison-Wesley. Iberoame-
rica. Diaz de Santos. Madrid, 2 edition, 1995.
[5] Chikofsky, E. and Cross, J.H. Reverse engineering and design recovery: A taxo-
nomy. IEEE Software, 7(1):13–17, January 1990.
[6] I. Jacobson and F. Lindström. Re-engineering of old systems to an object-oriented
architecture. Proc. OOSPLA, pages 340–350, 1991.
[7] J. Rumbaugh and et al. Object-Oriented Modeling and Design. Prentice Hall, 1991.
[8] I. Jacobson. Object-Oriented Software Engineering,A Use Case Driven Approach.
Addison-Wesley, 1992.
[9] M.M. Lehman. Programs, life cycles, and laws of software evolution. Proc. IEEE,
68(9):1060–1076, September 1980.
[10] Guide Pub. Application reengineering. Technical Report GPP-208, Guide Int’l Corp.,
Chicago, 1989.
[11] E. Yourdon. Object-Oriented Systems Design: An Integrated Approach. Prentice-Hall,
1994.