Reingeniera de Software

Juan Carlos Gonz alez Moreno

DPTO. DE INFORM ATICA Y AUTOM ATICA.
FAC. MATEM ATICAS, (UCM)
AV. COMPLUTENSE S/ N, MADRID (SPAIN), E-28040
Email: jcmoreno @dia.ucm.es
Informe T ecnico: DIA 22.96
Reingeniera
de
Software
Juan Carlos Gonz alez Moreno
Resumen
La popularidad de la reingenier a de software ha ido en aumento desde mediados de los
a nos 80. El motivo parece evidente, si el software que se ha venido utilizando hasta el
momento ha sido v alido y presenta aspectos signicativos para seguir siendo utilizado,
por qu e no intentar obtener todo lo que se pueda de el antes de remplazarlo? Por otra
parte, durante la d ecada de los 80 se han utilizado t ecnicas de reestructuraci on como
soluci on a problemas de mantenimiento que no han podido ser jados modicando uni-
camente el ujo de control.
La reingeniera 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 on del software.
El crecimiento que est a experimentando esta rama de la se fundamenta en distintos
aspectos que van a ser tratados a lo largo de las pr oximas secciones:
! Reusabilidad,
! Reestructuraci on,
! Ingeniera inversa,
! Nuevas herramientas .
0
1 INTRODUCCION 1
1 Introducci on
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 no que
se busquen da a da nuevas t ecnicas que reduzcan dichos costes, aumenten la producti-
vidad y mejoren los servicios. Una de las tecnologas que desde hace tiempo se ha venido
defendiendo para reducir costes es la reestructuraci on. Dicha tecnologa consiste en la
transformaci on de c odigo antiguo no estructurado, en c odigo estructurado funcional-
mente equivalente. En la actualidad al menos un 10 % de las compa nas dedicadas al
desarrollo de software est an adoptando esta tecnologa con vistas a mejorar la calidad
de los productos que han de mantener. Frente a esta aproximaci on consistente en mejo-
rar el c odigo (documentaci on y estructuraci on), muchas compa nias preeren la adopci on
de t ecnicas de reingeniera, sobre todo mediante la utilizaci on de herramientas semiau-
tom aticas, como una ayuda inestimable para sus t ecnicos de mantenimiento, a los que
les facilita enormemente la comprensi on del c odigo aliengena realizado por equipos
de trabajo distintos y realizados en base a conceptos de desarrollo muy distintos. En los
ultimos a nos, lo que se ha dado a denominar Ingeniera inversa, est a presentando un
considerable auge. La idea en este caso es intentar reconstruir los modelos, tanto de es-
pecicaci on como de dise no, sobre los que se sustentan las implementaciones que son
objeto de revisi on.
Debido a la juventud del concepto y las diferentes aproximaciones existentes, el pri-
mer punto que debemos intentar aclarar, es qu e entendemos por Rei ng e ni er a d e Soft-
w ar e?. En general, podemos considerar que la reingenierade software ([2]) es cualquier
actividad dise nada para:
" Conseguir la comprensi on personal del software, o
" Conseguir el software con vistas a: un mantenimiento incremental, su reusabilidad,
o una previsi on de su evoluci on.
En esta denici on el t ermino software incluye (adem as de codigo fuente) documenta-
ci on, representaciones gr acas y an alisis. Los an alisis conciernen al c odigo fuente, al
dise no, a las especicaciones, 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 on de este informe, es la familiari-
zaci on 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 Reingeniera e Ingeniera Inversa. Muchas de las ideas expuestas a lo largo del te-
ma hacen referencia a pr acticas actuales y pueden encontrarse incluso implementadas
dentro de numerosas herramientas de nueva generaci on.
Pretendemos que las pr oximas secciones sirvan como toma de contacto con facetas nue-
vas e interesantes de la y motiven la discusi on y el debate sobre la relevancia de
adoptar nuevos enfoques para poder dar soluciones a las nuevas problem aticas.
2 SIGNIFICADO Y PARTES DE LA REINGENIERIA 2
1.2 Contenido.-
Presentamos un contenido basado no s olo en los conceptos que rodean esta nueva dis-
ciplina, sino tambi en en el desarrollo de algunos casos pr acticos. Dividimos la presen-
taci on de este nuevo paradigma en las siguientes secciones:
# Si gnic a d o y p art es d e l a r ei ng e ni er a
$ Re estru ct ur a ci on
% Rei ng e ni er a d e r e ci cl aj e
& Ing e ni er a i nv ers a
' Desc ubri mi e nt o d e o bj e t os
2 Signicado y partes de la reingeniera
En la introducci on hemos denido la Reingeniera de Software como cualquier actividad
dise nada para:
" conseguir la comprensi on personal del software, o
" conseguir el software con vistas a: un mantenimiento incremental, su reusabilidad,
o una previsi on de su evoluci on.
Sin embargo, esta no es una denici on est andar, de hecho diversos autores proponen
diversas deniciones as por ejemplo GUIDE ([10]) la dene c omo:
El proceso de modicar 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 denen como:
El examen y modicaci on de un elemento del sistema con objeto de reconstruirlo
en un nuevo formato y su consecuente implementaci on .
Con respecto a las deniciones anteriores, observemos que la primera centra su aten-
ci on en las actividades de la reingeniera en vez de en su signicado o en su proceso. Por
otra parte las dos ultimas deniciones no permiten que algunas actividades, que si lo
hacen seg un la otra denici on, caigan dentro del campo de la reingeniera; mientras que
la primera subsume todas las actividades permitidas en las otras dos.
Por otra parte, existen un gran n umero de sin onimos que son empleados para referir-
se a la anteriormente denida reingeniera (re-ingeniera, o Reingeniera), entre los m as
importantes destaquemos:
! Perfeccionamiento.
! Prolongaci on.
! Renovaci on.
! Modernizaci on.
2 SIGNIFICADO Y PARTES DE LA REINGENIERIA 3
! Ingeniera de redesarrollo.
! Ingeniera de reutilizaci on.
Con objeto de facilitar la comprensi on de lo que vamos a entender como una actividad
de reingeniera observemos la gura 1 tomada de [2].
Normal
Ingenieria
Ingenieria
Normal
Ingenieria inversa,
recuperacion de diseno,
reingenieria
Ingenieria inversa,
recuperacion de diseno,
reingenieria
Componer
Generar
Vistas
Descomponer
Capturar
Base de
Informacion
Reingenieria
Reingenieria
Reingenieria,
reestructurar
Vista de clase A1:
Vista de clase A2:
Vista de clase A3:
Analisis
Analisis
Analisis
Vista de clase 1:
Vista de clase 2:
Vista de clase 3:
No procedural y/o meta
Procedural
Pseudo-procedural y/o
arquitectonico
Ej: Especificaciones
Ej: DFD
Ej: Codigo fuente
Figura 1: Reingeniera y t erminos anes.
En la gura 1 podemos distinguir 5 principales ideas que se encuentran asociadas al
concepto de reingeniera:
( Vist as d el soft w ar e.- Una vista del software, no es m as que una representaci on del
software o un informe sobre software. Aunque no es necesario que dicha represen-
taci on sea una vista para una persona, lo normal es cuando hablemos de vistas de
software estemos pensando en una representaci on que potencialmente puede con-
sultar y entender un ser humano.
# Base i nf or ma ti v a (o d e i nf or ma ci on).- La base de informaci on es el almac en don-
de podemos localizar toda la informaci on 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 naden conociiento en la base.
(c) Importando informaci on de otras bases de informaci on.
$ Desc o mp osi ci on.- 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 arboles sint acticos abstractos.
2 SIGNIFICADO Y PARTES DE LA REINGENIERIA 4
% C o mp osi ci on.- En este caso, generamos una nueva vista (o informaci on), a partir
de la informaci on 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 on.
Por ejemplo, los compiladores, a menudo generan c odigo mediante un recorrido a
trav es del grafo sem antico que representa el programa.
& Tr a nsf or ma ci on.- La noci on de transformaci on es central dentro del proceso de rein-
geniera. En todo el proceso, constantemente se est a transformando una informa-
ci on (o vista del software) en otra equivalente. Por ejemplo c odigo fuente en c odigo
fuente estructurado, actualizaciones en el dise no, correcciones en la especicaci on,
c omputos est aticos de medidas,
Como hemos podido apreciar, distintos autores enfatizan en distintos aspectos de man-
tenimiento de sistemas para denir lo que ellos consideran que es la labor de la rein-
geniera. Dependiendo del enfoque que queramos abordar podremos considerar como
v alida cualquiera de las deniciones anteriores, aunque un estudio m as detallado y mi-
nucioso nos permite observar que quiz as sea la primera la que conlleva una visi on m as
general y menos comprometida de lo que debe ser la tarea de reingeniera. Haciendo
nuestras las palabras del doctor Arnold ([2]), podemos decir que la labor de reingeniera,
es importante por diferentes motivos :
! La reingeniera puede ayudar a reducir el riesgo en la evoluci on de una organizaci on.
En efecto, para extender las capacidades de un software existente las organizacio-
nes pueden: construir nuevo software, evolucionar el existente, hacer una labor de
reingeniera y evolucionar el existente, utilizar generadores de aplicaciones, u obte-
ner partes o paquetes software nuevos.
Si las dos ultimas opciones no estan disponibles, las organizaciones (empresas) se
enfrentan al dilema de desarrollar un nuevo software o evolucionar el existente.
Una simple evoluci on manual del software existente tiende, usualmente, a dicultar
posteriormente el cambio del software, o a disminuir la conanza sobre el software
cambiado. Por otra parte, la construcci on de un nuevo software desde cero, suele
ser caro e incluso incierto. En estas circunstancias, la reingeniera de software y la
posterior evoluci on del software sobre el que se ha aplicado, puede ofrecer un me-
nor riesgo de cambio, y ayudar a salvaguardar la utilizaci on de un software dentro
de la organizaci on mejor que una nueva construcci on o una simple evoluci on a la
antigua usanza.
! La reingeniera puede favorecer la recuperaci on o la rentabilizaci ondel capital inverti-
do en software. Es obvio que las empresas durante estos ultimos a nos han invertido
gran cantidad de dinero en la compra y actualizaci on de sus aplicaciones software;
mucho m as en el caso de empresas dedicadas al desarrollo de software. Puesto que
no podemos presuponer que todo el esfuerzo realizado ha sido valdo (de hecho po-
demos considerar que los resultados han sido satisfactorios), parece evidente que
la adopci on de nuevas t ecnicas 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 andose satisfactoriamente. En estos casos, la reingeniera ayuda a construir
el nuevo software a partir del existente, ayudando a las empresas a rentabilizar sus
anteriores adquisiciones.
2 SIGNIFICADO Y PARTES DE LA REINGENIERIA 5
! La reingeniera puede hacer m as sencillos los cambios de software. La reingeniera
aumenta la productividad en el mantenimiento de sistemas, al hacer que el progra-
mador comprenda m as f acilmente el c odigo con el que trabaja. Adem as proporciona
a la empresa una mayor exibilidad al poder modicarse m as r apidamente el soft-
ware con objeto de acomodarse a los cambios de actividades de la empresa.
! La reingeniera es un gran negocio. Es evidente por lo que hemos dicho en los
apartados anteriores, que el mercado potencial para la reingeniera abarca al con-
junto de las aplicaciones existentes y futuras; esto supone un mercado de billones
de d olares que se encuentra abonado para recibir con entusiasmo las nuevas t ecni-
cas.
! Las capacidades de reingeniera extienden las posibilidades de las modernas herra-
mientas . La reingeniera puede verse como una especie de vehculo de trans-
ferencia de tecnologa, que permite a los viejos sistemas su traslado a nuevas y m as
potentes herramientas. Su incorporaci on en herramientas por parte de las
empresas de desarrollo, aumenta el valor de estas y les permite introducirse en un
nuevo mercado.
! La reingeniera es un catalizador en el mantenimiento autom atico de software. La
mayor parte de las herramientas de reingeniera siguen el patr on de la gura 2.
Son b asicamente almacenes, con caminos especializados para obtener informaci on
interna y externa. Una parte importante de dicha informaci on ha sido preanaliza-
da y almacenada para su posterior uso como valioso material para el futuro nuevo
an alisis, la automatizaci on del proceso y la investigaci on del mantenimiento del sis-
tema.
* Formato
* Graficos
* Documentaciones
* Metricas
* Logica
* Informes
Descomponer
Componer
Software
Trabajo
Producto de
Otros productos de trabajo
Nuevas vistas del producto:
Visualizaciones
Analizadores
Informacion representada
en un formato intermedio
Base informativa
Figura 2: Proceso de Reingeniera Autom atica.
! La reingeniera es un catalizador en la aplicaci on de t ecnicas de Inteligencia Articial
( ) en la soluci on de problemas de reingeniera. Tal y como hemos comentado el
proceso de reingeniera se fundamenta en la realizaci on de una serie de transfor-
maciones. Hist oricamente el campo de investigaci on sobre transformaciones au-
tom aticas ha sido abordado dentro del campo de la , tal es el caso de los sis-
temas basados en la producci on de reglas y de los procesadores de lenguajes. M as
2 SIGNIFICADO Y PARTES DE LA REINGENIERIA 6
recientemente, las transformaciones han experimentado un importante crecimiento
dentro de la l ogica formal y de los sistemas de reescritura. Para todos estos cam-
pos de investigaci on la reingeniera se est a ofreciendo como un campo abonado en
el que poder aplicar el trabajo de los ultimos a nos.
2.1 La tecnologa de reingeniera
Con objeto de concretar en mayor medida el concepto de reingeniera, podemos preci-
sar cuales son los grandes temas que abarca, junto con las tecnologas asociadas a los
mismos. En concreto, dichos temas son:
" Perf e c ci on a mi e nt o d e soft w ar e.- Con relaci on a este tema, nos encontramos con
que las principales tecnologas que se vienen utilizando en perfeccionar o mejorar
el software existente son:
! Re estru ct ur a ci on d el sot w ar e. Consiste en la modicaci on del software existen-
te para hacerlo m as legible o m as f acil de matener. En la actualidad la aplica-
ci on de este tipo de tecnologas, implica cambios en las estructuras de control
del c odigo fuente.
! Redocumentaci on, anotaci on y actualizaci on de la documentaci on. Supone la
realizaci on de actualizaciones correctas de la informaci on existente sobre el
software. El exito de este tipo de tecnologas se basa, en gran medida, en la
utilizaci on de herramientas autom aticas adecuadas.
! Rei ng e ni er a d e r e ci cl aj e, o Ing e ni er a d e Re utiliz a ci on. El objetivo en este caso,
es modicar el software con objeto de aumentar su capacidad de reutilizaci on,
localizando partes del c odigo que pueden ser modicadas (sin p erdida de fun-
cionalidad), por un c odigo equivalente que puede ser almacenado en libreras
de componentes reutilizables.
! Remodularizaci on. Supone el cambio de la estructura modular de un sistema.
A menudo, esto depende de la realizaci on de diferentes an alisis sobre la co-
hesi on que aportan distintas agrupaciones de componentes del software exis-
tente, realizadas en base a distintas caractersticas. Tambi en es frecuente la
realizaci on de medidas sobre el acoplamiento existente.
! Reingeniera de datos. Intenta mejorar los datos que maneja el sistema. Dife-
rentes esquemas de datos pueden ser reorganizados y actualizados. tambi en
es posible consolidar multiples esquemas en uno s olo, conseguir que algunas
entradas del diccionario de datos sean ahora sem anticamente consistentes, y
eliminar datos no v alidos. La aplicaci on de este tipo de tecnologas suele ser
el proleg omeno de otras tareas, a menudo relacionadas con migraciones del
software existente a nuevas bases de datos.
! Reingeniera del proceso comercial. Hoy en da, la exibilidad de las arquitec-
turas de software y la automatizaci on de la tecnologa de la informaci on, est an
consiguiendo que el software inuya en la organizaci on de las empresas, fren-
te a la situaci on tradicional que haca que la organizaci on de las empresas in-
uenciara 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 on del pro-
ceso empresarial se lleva a cabo con la utilizaci on de herramientas software
adecuadas.
2 SIGNIFICADO Y PARTES DE LA REINGENIERIA 7
! An alisis de mantenimiento, econ omico, y de cartera de inversiones. El an alisis
que se lleva a cabo durante el mantenimiento de una aplicaci on software es
importante, porque permite descubrir partes del sistema que deben ser rede-
sarrollados (con procedimientos de reingeniera).
" C o mpr e nsi on d e soft w ar e.- En este caso nos encontramos con las siguientes tec-
nologas:
! Ojeo. El ojeo de informaci on consistente en la utilizaci on de editores adecuados
sobre distintas representaciones del software existente, es el m etodo que desde
hace m as tiempo se viene empleando para comprender el funcionamiento de
una aplicaci on. Hoy en da, la utilizaci on de hipertextos permite un m as r apido
acceso y una mejora en dicha comprensi on, como una consecuencia directa
de la utilizaci on de adecuadas referencias cruzadas entre las documentaciones
que constituyen la informaci on de la aplicaci on.
! An alisis y medici on. El an alisis y la medida del software, son importantes en
la comprensi on de algunos detalles signicativos del software existente, tales
como la complejidad del c odigo generado.
! Ing e ni er a i nv ers a , r e c up er a ci on d e dise nos. Estas nuevas tecnologas generan
nueva informaci on sobre el software que se esta analizando, una informaci on
que aparece, generalmente, bajo un nuevo aspecto y que proporciona nuevas
vistas de la aplicaci on. Habitualmente, la ingeniera inversa crea diagramas
de cartas y diagramas de ujo de datos a partir del c odigo fuente. Para ello, se
utilizan herramientas bastante sosticadas que precisan de cierta legibilidad y
estructuraci on en el c odigo que reciben como entrada.
" C a pt ur a , pr eserv a ci on, y ext e nsi on d el c ono ci mi e nt o so br e el soft w ar e.- Las prin-
cipales tecnologas que se utilizan en este tema son:
! Descomposici on. La descomposici on de programas permite la extracci on de ele-
mentos y relaciones entre los mismos. Estos son almacenados en la base de
informaci on, y permiten el descubrimiento posterior de informaci on adicional
de la aplicaci on. Para ello se analizan las partes almacenadas y obtenidas como
decomposici on del programa, en vez de trabajar directamente sobre el c odigo
fuente de la aplicaci on.
! Re c up er a ci on d e o bj e t os. Estas tecnologas permiten localizar objetos a partir
del c odigo fuente, lo cual es interesante pues proporciona una visi on de
aplicaciones que no lo son.
! Comprensi on de programas. La comprensi on de programas adopta diferentes
formas. La m as usual, suele venir de la utilizaci on de t ecnicas (manuales o au-
tom aticas), por parte de los t ecnicos programadores. Otras formas alternati-
vas, pasan por la utilizaci on de almacenes de informaci on sobre programaci on,
que son utilizados para localizar en una determinada aplicaci on, diversas ins-
tancias de patrones almacenados.
! Bases de conocimiento y transformaciones. Las bases de conocimiento y la utili-
zaci on de transformaci on de programas son fundamentales en la aplicaci on de
la mayor parte de las tecnologas de Reingeniera (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 on (base de conoci-
miento). La utilizaci on de nuevas arquitecturas transformacionales, basadas
2 SIGNIFICADO Y PARTES DE LA REINGENIERIA 8
en la utilizaci on de objetos, son motivo de un creciente desarrollo. En concreto,
destaca especialmente la construcci on de nuevas y m as potentes herramientas
autom aticas que ayudan en el proceso de reingeniera.
A lo largo de pr oximas secciones pensamos profundizar en algunas de dichas tecnologas
(aquellas que han sido resaltadas), dejando un estudio m as extenso y detallado sobre el
resto de tecnologas para que el lector avezado la lleve a cabo empleando toda o parte de
la bibliografa que aparece al nal del informa. Recomendando de manera especial [2].
2.2 Los riesgos de la reingeniera
A pesar de las ventajas y benecios que presenta la adopci on de tecnologas de Reinge-
niera en el proceso de mantenimiento de una aplicaci on, hemos de sopesar su utiliza-
ci on, ya que no siempre es aconsejable porque los inconvenientes, o costes asociados
pueden ser mayores que los benecios. Podemos se nalar las siguietes areas de riesgo
que aparecen cuando consideramos la posibilidad de adoptar alguna de las tecnologas
descritas en el apartado anterior.
! Riesgo en el proceso:
Elevado coste en la realizaci on de una reingeniera manual.
No alcanzar los benecios en el plazo requerido.
Falta de justicaci on econ omica del esfuerzo de la ingenira.
Falta de criterios administrativos que justiquen la utilizaci on de reingeniera.
! Riesgo personal:
Inhibici on de los programadores al comienzo del proceso.
Los programadores con un bajo rendimiento pueden contribuir a que un pro-
yecto de reingeniera poco popular se vea como improductivo.
! Riesgo en la aplicaci on:
Realizar reingeniera sin la colaboraci on de expertos de la aplicaci on.
P erdida del conocimiento industrial que se encuentra incorporado en el c odigo
fuente.
Falta de adecuaci on de los procesos de reingeniera.
! Riesgo tecnol ogico:
La informaci on recuperada no es util o simplemente no es utilizada.
Producci on masiva de documentaci on (costosa).
No pueden compartirse representaciones obtenidas mediante ingeniera inver-
sa.
Falta de adecuaci on entre la tecnologa y el objetivo.
Usar un proceso de reingeniera con medios insucientes.
! Riesgo en las herramientas:
Desaprovechamiento de las herramientas instaladas.
3 REESTRUCTURACION 9
No alcanzar los benecios en el plazo requerido.
Excesiva dependencia del proceso en herramientas incapaces u obsoletas.
! Riesgo estrat egico:
Concluir precipitadamente la necesidad de una soluci on con reingeniera.
Fallos de precisi on, a largo plazo, de los objetivos internos.
Falta de visi on global: c odigo, datos, proceso de reingeniera.
Inexistencia de un plan para la utilizaci on de herramientas de reingeniera.
3 Reestructuraci on
La reestructuraci on de software consiste en la modicaci on de software con objeto de
hacerlo m as f acil 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 on
interna y externa concerniente al c odigo fuente, junto con el propio c odigo fuente.
Esta denici on excluye los cambios de software que buscan otros prop ositos, tales como
optimizaci on de c odigo. Aunque la optimizaci on de c odigo implica reestructuraci on en
cierto sentido, no suele ser el punto clave en el mantenimiento de una aplicaci on.
Con objeto de ilustrar la necesidad del proceso de reestructuraci on 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 dicultad de mantenimiento
y de comprensi on de este programa. En apariencia (por lo que parece ser la cabecera) su
intenci on es realizar un proceso de edici on sobre ciertos indicadores de coste, pero no
queda claro cual es el signicado de dichos indicadores. Por otra parte las variables que
se utilizan no son mnemot ecnicas ( cual es el signicado de SPAG ?), adem as presenta
una gran dicultad el seguimiento del ujo de control, y que existen m as de una instruc-
ci on por lnea, una falta de normalizaci on en el uso de la identaci on, e incluso se parten
instrucciones por la mitad. Por si esto no fuera poco, adem as utiliza constantes litera-
les (007) en vez de utilizar constantes smbolocas que favorezcan cambios ulteriores.
Frente a este programa, consid erese 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 apida inspecci on del c odigo nos indica que el prop osito de este es
llevar a cabo la edici on de costes acumulados de agentes especiales. Las instrucciones
aparecen ordenadas una por lnea, el seguimiento del ujo de control se realiza de una
manera mucho m as simplicada, en la que la identaci on es homog enea y contribuye a
dicho seguimiento. Las variables tienen nombres con signicado, y aunque siguen exis-
tiendo constantes literales, estas se encuentran asociadas a identicadores, facilitando
su posible modicaci on posterior con nuevos valores.
Es un hecho que con cambios continuados, el software tiende a volverse menos estruc-
turado [9], lo cual se maniesa con documentaci on pasada de fecha, c odicaciones que
no se ajustan a los est andares, incremento del tiempo que necesitan los programadores
para entender el c odigo existente, incremento en de errores no existentes con los nuevos
cambios, . En este marco la reestructuraci on es una opci on muy importante que
permite mantener controlados los elevados gastos asociados al mantenimiento de una
aplicaci on. La idea principal es modicar el software (o la percepci on que los programa-
dores tienen de la estructura de software) con objeto de volver a comprenderlo y controlar-
lo.
La reestructuraci on de software, no s olo concierne a aspectos de la estructura de soft-
ware que pueden ser medidos y/o observados; sino tambi en a las percepciones que la
gente tiene de dicha estructura. Existen m ultiples factores que inuyen en las percep-
ciones que cada persona tiene de la estructura de software (ver gura 3).
En este contexto cabe preguntarse por la existencia de t ecnicas y metodologas que faci-
liten el proceso de reestructuraci on. La contestaci on es muy simple y armativa, consi-
deremos la siguiente clasicaci on realizada en base a la estructura de la gura 3:
3.1 T ecnicas
( C odigo:
Estilo del c odigo.- Facilita la comprensi on sin necesidad de modicar la estruc-
tua de control o de datos.
! Formateo de c odigo e impresi on adecuada.
3 REESTRUCTURACION 11
Cdigo
Documentacin
Entorno de programacin:
Herramientas
Ingenieros de Software
Administracin: Politicas
Contexto
Figura 3:

Ambitos de inuencia en la percepci on de la estructura de software.
! Aplicaci on de estilos de codicaci on est andares.
! Reestructuraci on con ayuda de un preprocesador.
Utilizaci on de paquetes de c odigo reutilizable.- Se utilizan librerias de compo-
nentes para reemplazar software pobremente estructurado, o para a adir nuevo
software.
! Reestructurar c odigo con objeto de hacerlo m as reutilizable. Esta t ecnica
involucra frecuentemente una profunda limpieza del c odigo existente (eli-
minaci on de par ametros sup eruos, reducci on 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 on del bocadillo de software. En este caso se pretende, que el
antiguo c odigo poco estructurado sea utilizado como si se tratase de una
caja negra, para lo cual colocaremos un nuevo interfaz de comunicaci on
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 categora se incluyen algoritmos y procedimientos en
caminados a reestrucurar los grafos de ujo de control, y las herramientas de
reestructuraci on de pogramas.
! Eliminaci on de gotos. Eliminaci on por diversas t ecnicas de los saltos a
marcas que dicultan el seguimiento del ujo de control y que son inne-
cesarios.
! Utilizaci on de marcas booleanas. Se crean grafos de ujo estructurados
mediane la inclusi on de variables booleanas.
3 REESTRUCTURACION 12
! Utilizaci on de herramientas autom aticas. Sobre todo en lenguajes como
FORTRAN y COBOL
! Doble conversi on. Se utilizan herramietas de conversi on autom aticas 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 on es es-
pecialmente frecuente si las herramientaas utilizadas en la conversi on son
distintas.
Datos.- Aunque hist oricamente la reestructuraci on de sosftware se centre fun-
damentalmente en la estructura de control, la reestructuraci on de datos es
tambi en muy importante. Consid erese 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 on en las actualizaciones en la base de da-
tos, cuando se produce una actualizaci on en un registro de dichos datos.
# Documentaci on:
Actualizaci on de la documentaci on.
Modularizaci on de sistemas.
$ Programaci on del entorno. Herramientas:
Actualizar el entorno de programaci on.
Programar entornos/estaciones de trabajo.
Utilizar m etricas de software.
Comprobadores de est andares y otras ayudas.
Colecciones de herramientas.
Sistemas de transformaci on de programas.
Lenguajes de 4 Generaci on.
% Ingenieros de sofware:
Formaci on de profesionales.
Contrataci on de nuevos programadores, m as experimentados con el ambito de
la aplicaci on.
Reducci on de cambios.
& Administraci on y polticas:
Adecuaci on a est andares y guas de estilo.
Inspecciones y colocaci on de marcas.
3.2 Metodologas
Una metodologa es tipicamente un conjunto de pasos para mejorar el software en cual-
quiera de los niveles vistos en la gura 3. Una metodologa ayuda en manejo y control
de otras t ecnicas de reestructuraci on m as especcas. Distinguimos las siguientes me-
todologas:
3 REESTRUCTURACION 13
" Rejuvenecimiento de sistemas.- Se dene como la utilizaci on de un sistema exis-
tente como base en la elaboraci on de un nuevo sistema estrat egico. La metodologa
involucra una limpieza del sistema existente que lo haga m as eciente.
" Programa de mejora de software.- Esta metodologa es una ambiciosa va de aplica-
ci on administrativa, tendendente a reestructurar el software y a actualizar el funcio-
namiento de las pr acticas de ingeniera de software en un entorno de mantenimiento
determinado.
" Reestructuraci on incremental.- Esta metodologa se encuentra en la lnea de la an-
terior pero sin prestar tanta atenci on a la labor administrativa. Esta aproximaci on
permite que la estructura sea denida por el usuario (en vez de ser construida
dentro de la propia reestructuraci on); la reestructuraci on se realiza en peque nas
partes manejables. Un sistema puede beneciarse de las aportciones de una rees-
tructuraci on sin necesidad de ser totalmente reestructurado. Esta aproximaci on
es de particular inter es en la evitaci on de introducir estructuraciones pobres como
resultado del mantenimiento.
" Renovaci on de software.- Esta aproximaci on tiene que ver con la actualizaci on de
la documentaci on de software, de la especicaci on del sistema, y de las pruebas del
sistema.
Tambi en pueden utilizarse para realizar reestrucutraciones de software mecanismos o
t ecnicas utilizadas en la ingeniera inversa (comprensi on de software y recuperaci on de
dise nos).
3.3 Conclusiones y plan de reestructuraci on
Como conclusiones principales, del proceso de reestructuraci on de software, podemos
indicar que:
" El c odigo reestructurado necesita cierto tiempo para ser utilizado.
" La reestructuraci on de c odigo en grandes sistemas, es amenudo insuciente.
" Es preciso reestructurar tambi en la documentaci on
" El entorno de programaci on afecta a la percepci on de la estructura de software.
" El coste de la reestructuraci on puede ser cuanticado y previsto.
" Es necesario decidir, de manera sistem atica, como resolver problemas empleando
t ecnicas de reestructuraci on.
" Planicar la conservaci on de la estructura de software que se obtenga despu es de
reestructurar.
Un posible plan de actuaci on para llevar a cabo la reestructuraci on 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
# Identicar las tareas actuales en las que una poltica de reestrucutraci on puede
ahorrar tiempo, reducir los problemas de mantenimiento, o permitir cualquier otro
benecio signicativo.
$ Ajustar una aproximaci on de reestrucutraci on adecuada a los problemas de man-
tenimiento m as apremiantes. Una reestructuraci on adecuada, es aquella que pre-
senta un mayor impacto sobre las tareas del punto anterior.
% Realizar an alisis de viabilidad y de transferencia tecnol ogica de la aproximaci on se-
leccionada. Un an alisis de transferencia tecnol ogica examina las componentes tan-
to sociales como psicol ogicas que afectan a la aceptaci on y utilizaci on de la aproxi-
maci on elegida.
& Seleccionar una t ecnica de reestructuraci on, planicar su utilizaci on, y emplearla.
' Realizar un seguimiento del esfuerzo de reestructuraci on, preferentemente median-
te la recolecci on de datos y aplicaci on de medidas sobre la estructura. Tambi en
realizar el seguimiento de la mejora en el mantenimiento y evaluar los resultados.
La gura 4 muestra una posible planiaci on para estudiar la ecacia de una herramienta
de reestructuraci on.
Programa
elegido
Recodificador
Programa recodificado
Mediciones
Programa original
Cambios en ambas versiones
con distinto personal
Cambios en el
programa original
Cambios en el
programa recodificado
Mediciones y
comentarios
Resultados
Figura 4: Plan de estudio de ecacia de una herramienta de ayuda en la reestructura-
ci on.
4 REINGENIERIA DE RECICLAJE 15
4 Reingeniera de reciclaje
En un gran n umero de aplicaciones, la construcci on se ha venido llevando a cabo sin
tener en cuenta la posibilidad de reutilizar las componentes del sistema. Hoy en da,
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 on no es posible reutilizar mucho de lo ya desarrollado, di-
se nado o especicado. Un apartado muy importante dentro de la reingeniera tiene por
misi on la b usqueda e identicaci on de componentes reusables dentro de las aplicacio-
nes existentes, con vistas a su incorporaci on en dep ositos y su posterior utilizaci on en
la construcci on de nuevas aplicaciones.
La reingeniera 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 ease Figura 5), que es guiado por la utilizaci on de componentes reusables.
Sistema n
Sistema 2
Sistema 1
Almacn
Vuelta
atrs Medir
Ver y
Certificar
Reingeniera
(Salvage) Clasificar
Adquirir
Disear
Reusar
Comprender
Buscar y
Figura 5: Ciclo de vida de reutilizaci on.
5 Ingeniera inversa
La ingeniera inversa, es la actividad de denir una representaci on del sistema m as abs-
tracta y f acil de comprender que la actualmente existente ([6]). La aplicaci on de inge-
niera inversa nos hace retroceder desde el c odigo hasta las etapas de dise no e incluso
de an alisis, en un proceso en el que se puede recuperar informaci on perdida e incluso
generar nueva informaci on sobre la aplicaci on estudiada.
Dentro de la ingeniera inversa podemos distinguir entre:
" Descompilaci on. Con esta denominaci on se identica el proceso de recuperaci on del
c odigo fuente a partir del c odigo objeto que se encuentra operativo.
" Ingeniera revertida. Esta actividad tiene por objeto el recuperar la estructura de
programa que fu e dise nada originalmente para la aplicaci on que es objeto de estu-
dio.
6 RECUPERACION DE OBJETOS 16
" Ingeniera 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 jaron, con objeto de reestructurarlos, descubrir requisitos que de-
bieron ser abandonados por restricciones de implementaci on, e incluso descubrir
otros que no se identicaron por diversas causas. Este es el prop osito de la inge-
niera invertida.
6 Recuperaci on 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 on de tecnologas . La
formulaci on de las siguientes preguntas se ha vuelto un tema com un en un gran n umero
de empresas dedicadas al desarrollo de aplicaciones o simplemente a la utilizaci on de
software:
" C omo podemos construir un modelo de un sistema que nos permita razonar sobre
las modicaciones futuras?
" C omo podemos reemplazar gradualmente diversas partes de un sistema?
" C omo podemos integrar las t ecnicas modernas de orientaci on a objetos en un sis-
tema existente?
Estas preguntas son contestadas mediante la aplicaci on de tecnologas orientadas a
objetos en las que, las entidades reales del dominio de aplicaci on se modelan mediante
objetos y asociaciones entre estos. El modelo del sistema obtenido puede utilizarse como
una aplicaci on entre las entidades reales del dominio de aplicaci on y los elementos de
programaci on del sistema existente.
Las metodologas de desarrollo orientadas a objetos, son de gran utilidad en la moder-
nizaci on gradual de viejos sistemas software ([6]), es decir en su reingeniera. La t ecnica
utilizada para acometer dicha modernizaci on se fundamenta en dos principios:
! Un cambio en el dominio de aplicaci on es en su mayora 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 nado
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 gura ?? hay que sopesar los aspectos de facilidad
de cambio y el valor que tiene para la empresa el producto que se est a analizando.
Deniendo la reingeniera como:
El proceso de crear una descripci on abstracta de un sistema, razonar sobre un cam-
bio del sistema a un elevado nivel de abstracci on, y reimplementar el propio sistema.
Puede modelizarse dicha denici on mediante la siguiente ecuaci on:
6 RECUPERACION DE OBJETOS 17
Cambio
Valor para la empresa
Descartar
Mantener Mejorar
Reingeniera
Figura 6: Matriz de decisi on. Qu e hacer con un sistema antiguo
Reingeniera Ingeniera inversa Ingeniera Normal
En la que consideramos que la actividad que dene la Ingeniera inversa es aquella que
est a encaminada a denir de una manera m as abstracta, y f acil de comprender, la repre-
sentaci on del sistema. . Y d onde representa un Cambio de funcionalidado de t ecnica
de implementaci on del sistema.
El objetivo fundamental de la Ingeniera Inversa (tal y como ya se ha detallado en una
secci on previa) es capturar un conocimiento preciso del comportamiento y de la estructura
del sistema, que facilite su comunicaci on.
Con objeto de poder llevar a cabo dicha misi on de una manera satisfactoria es preciso
que contemos con:
! Una representaci on concreta (grafo) de las componentes del sistema y de sus
interrelaciones. Recoger a detalles de implementaci on.
! Una representaci on abstracta (grafo) del comportamiento y de la estructura
del sistema. Libre de detalles de implementaci on.
! Una correspondencia entre las componentes de ambas representaciones.
Mostrar a la relaci on existente entre el mundo ideal y el mundo concreto.
Las labores de reingeniera, 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 on del negocio implica un campio en la fun-
cionalidad de la aplicaci on.
No afecta a la implementaci on del sistema.
" Un cambio en las t ecnicas de implementaci on.- Los puntos fundamentales
en este apartado son:
El cambio puede implicar un cambio en el lenguaje de codicaci on (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-
cas.
Como observaciones particulares indiquemos que:
" Cuando una parte de la aplicaci on cambia su t ecnica de implementaci on,
es preciso facilitar la comunicaci on entre ambas partes del sistema.
" Y que una funcionalidad b asica consiste en la utilizaci on de o por parte
de otra aplicaci on.
Una vez enmarcado el proceso que debe acomenterse, surge la pregunta cuales son los
pasos a seguir? La contestaci on viene dada por la siguiente secuencia de actividades:
1. Identicar las relaciones entre las distintas componentes del sistema y crear una
representaci on m as abstracta del mismo. (Por ejemplo mediante la construcci on
de un diagrama de ujo de datos para representar las funciones C y un modelo de
entidad relaci on para la base de datos).
2. Razonar sobre los cambios de funcionalidad a un nivel m as abstracto.
3. Redise nar el sistema, pasando de la representaci on m as abstracta a la representa-
ci on m as concreta (ingeniera normal). Se deben tener en cuenta los cambios en la
t ecnica de implementaci on.
Para poder llevar a cabo dichas actividades es preciso que contemos con:
! Una representaci on del sistema tal cual es.
! Una representaci on l ogica del sistema, a un nivel que posibilite el razonamiento
sobre cambios de funcionalidad.
! Una manera de capturar decisiones de dise no, es decir contestaci on a la pregunta:
por qu e el sistema se ha implementado as ?
! Una t ecnica o mecanismo que facilite la comunicaci on entre dos partes implemen-
tadas con t ecnicas distintas (por ej. comunicaci on entre c odigo C y c odigo C , y/o
viceversa).
! Una t ecnica que delimite la parte del sistema que queremos explorar.
Un punto importante a tener en cuenta son los posibles escenarios de aplicaci on de esta
tecnologa. Entre estos podemos destacar los siguientes:
6 RECUPERACION DE OBJETOS 19
! Un cambio completo en la t ecnica de implementaci on, y ninguna modicaci on en la
funcionalidad del sistema. En este caso conviene destacar que esta aproximaci on
rara vez se aplica a un gran sistema.
! Un cambio parcial en la t ecnica de implementaci on y ninguna modicaci on en la fun-
cionalidaddel sistema. Ahora el objetivo principal es que la nueva parte construida
siguiendo una poltica crea que el resto del sistema tambi en ha sido construido
con esa poltica.
! Cambios en la funcionalidaddel sistema. En este caso el escenario se presenta como
un proceso de ingeniera normal. Se a naden los cambios de funcionalidad al modelo
del an alisis y se procede hasta la implementaci on siguiendo un desarrollo .
Los pasos que hay que seguir en la aplicaci on de esta tecnologa a las situaciones ante-
riores son:
" Realizaci on de una reingeniera completa, sin cambios de funcionalidad:
( Preparar un modelo analtico. (V ease gura 7)
! Asimilar la informaci on existente sobre el sistema (especicaci on, instruc-
ciones de manejo, manuales de mantenimiento, documentos de dise no, c odi-
go fuente, ), es decir sus elementos de descripci on.
! Aislar los elementos de descripci on primitivos, lo cual implica en particu-
lar, aislar los el e me nt os qu e r e pr ese nt a n el sist e ma r e al
! Preparar el m odelo analtico propiamente dicho, mediante la localizaci on
de objetos utilizando alguna de las metodologas existentes ([3, 4, 7,
8]).
Sistema real
Modelo analtico
Implementacin
Figura 7: Transformaci on de sistemas: Reingeniera completa s.c.f.
# Establecer una correspondencia entre los objetos y la implementaci on del siste-
ma existente (Ver gura 8). En este proceso existen las siguientes restricciones:
6 RECUPERACION DE OBJETOS 20
! Todos los objetos deben proceder de alg un elemento de descripci on primi-
tivo.
! Todas las aristas del grafo abstracto deben proceder de alg un elemento
de descripci on primitivo.
Adem as los objetos abstractos y las relaciones de herencia identicadas deben
proceder de al menos un elemento de descripci on primitivo.
Modelo analtico
Sistema antiguo
Primitivas
Figura 8: Transformaci on de sistemas: Correspondencia entre modelos
$ Redise nar el sistema utilizando t ecnicas de ingeniera 0abrOO.
" Realizaci on de una reingeniera parcial, sin cambios de funcionalidad:
( Identicar la parte del sistema que debe ser reimplementada. Se crean dos sub-
conjuntos de elementos de descripci on primitivos (Ver gura 9):
Figura 9: Transformaci on de sistemas: Reingeniera 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 on de depen-
dencia.
# Preparar el modelo analtico de la parte que debe ser modicaday de su entorno.
$ 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 ecnica de implementaci on
! Los que envuelven a los anteriores realizando la comunicaci on con la parte
del sistema que no se modica.
% Repetir los pasos anteriores hasta conseguir un interfaz de comunicaci on acepta-
ble entre la parte que se esta modicando y el resto del sistema. Hay que evaluar
el interfaz buscando un coste de implementaci on aceptable.
& Realizar en paralelo:
! Dise nar el nuevo subsistema y sus interfaces con el sistema antiguo.(Ver -
gura 10).
Figura 10: Transformaci on de sistemas: Creaci on 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 .
! Modicar el sistema antiguo y a nadir un interfaz adecuado con el nuevo sub-
sistema.
' Integrar y comprobar el nuevo subsistema y las modicaciones de la parte an-
tigua.
" Realizaci on de una reingeniera con cambios de funcionalidad:
En este caso se procede a nadiendo los cambios en la funcionalidad en el modelo
analtico y se implementan utilizando t ecnicas (Ver gura 11).
Los principales pasos en este subproceso son:
( Cambiar el modelo analtico en funci on 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 on de sistemas: Reingenieria con cambio de funcionalidad
! El subconjunto de elementos que no se ven afectados por la modicaci on.
# Dise nar el sistema con una metodologa .
6.1 Conclusiones
Por ultimo, y como conclusi on de esta secci on hacemos las siguientes reexiones:
) 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 as
r apido 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-eciencia es desfavorable.
) Una delimitaci on efectiva de las partes del sistema que son candidatas para ser mo-
dicadas supone mitigar los cambios a realizar en el sistema.
) Existen m etodos pr acticos para realizar reingeniera, y acabamos de presentar uno
basado en la modelizaci on seg un una poltica .
) El nuevo modelo puede servir como base para futuros desarrollos, y extensio-
nes futuras pueden ser incorporadas de una manera f acil adaptando los interfaces
de comunicaci on.
) Reingeniera sustituto o parte activa del ciclo de vida de una aplicaci on?.- A la vista
de los resultados que se est an consiguiendo, al aumento en la aplicaci on de he-
rramientas que favorecen la labor de reingeniera sobre los productos que
se han elaborado con ellas, y a la cada vez mayor utilizaci on de librerias de com-
ponentes reusables (por ej. librerias C ), parece razonable preguntarse si en un
futuro no muy lejano la utilizaci on de la reingeniera sobre aplicaciones existentes,
no constituir a una alternativa v alida al proceso de ingeniera habitual. Es decir,
asistiremos en los pr oximos a nos a un aumento, cuantitativamente signicativo, en
el reciclaje de aplicaciones, tal y como est a ocurriendo en otros ambitos empresa-
riales ?
REFERENCIAS 23
Referencias
[1] R. S. Arnold. Software reestructuring. Proc. IEEE, 77(4):607617, 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 no 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):1317, January 1990.
[6] I. Jacobson and F. Lindstr om. Re-engineering of old systems to an object-oriented
architecture. Proc. OOSPLA, pages 340350, 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):10601076, September 1980.
[10] Guide Pub. Application reengineering. Technical Report GPP-208, Guide Intl Corp.,
Chicago, 1989.
[11] E. Yourdon. Object-OrientedSystems Design: An Integrated Approach. Prentice-Hall,
1994.