ELABORACIÓN DE UNA GUÍA PARA LA MIGRACIÓN DE SISTEMAS

LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTI-CAPA

HUGO ALDEMAR GÓMEZ MARTÍNEZ

Código: 1096431

UNIVERSIDAD DE SAN BUENAVENTURA

FACULTAD DE INGENIERÍA DE SISTEMAS
ESPECIALIZACIÓN DE PROCESOS PARA EL DESARROLLO DE SOFTWARE
SANTIAGO DE CALI
2010
 ELABORACIÓN DE UNA GUÍA PARA LA MIGRACIÓN DE SISTEMAS
LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTI-CAPA

Presentado por:
HUGO ALDEMAR GÓMEZ MARTÍNEZ
Código: 1096431

Trabajo de Grado presentado como requisito para optar el título de

Especialista en Procesos para el Desarrollo de Software

Director:
Dr. LUIS MERCHÁN PAREDES
Ing. De Sistemas

UNIVERSIDAD DE SAN BUENAVENTURA

FACULTAD DE INGENIERÍA DE SISTEMAS
ESPECIALIZACIÓN DE PROCESOS PARA EL DESARROLLO DE SOFTWARE
SANTIAGO DE CALI
2010
 Nota de aceptación

______________________________________________________

______________________________________________________

______________________________________________________

_____________________________________________
Director del proyecto

_____________________________________________
Director del proyecto

________________________________________
Jurado

________________________________________
Jurado

DICIEMBRE DE 2010

III
 AGRADECIMIENTOS

El autor expresa sus agradecimientos a:

Dios, porque me dio fortaleza y salud para culminar ésta estudio de postgrado.

Mi esposa Adriana y a mi bebé Sergio, quienes con su apoyo y colaboración

hicieron posible éste logro.

Todas las personas que han confiado en mí como estudiante, profesional y amigo.

IV
TITULO: ELABORACIÓN DE UNA GUÍA PARA LA MIGRACIÓN DE SISTEMAS
LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTI-CAPA.*

AUTOR: HUGO ALDEMAR GÓMEZ MARTÍNEZ**

PALABRAS CLAVE: SISTEMAS LEGADOS, ORACLE FORMS6i, MIGRACIÓN,

GUÍA, ARQUITECTURA, MULTI-CAPA, REINGENIERÍA, SOFTWARE

DESCRIPCION:

La dinámica actual de los negocios hace que las organizaciones requieran

sistemas de información que se adapten al cambio. Por lo tanto, los sistemas
legados se convierten en un obstáculo para lograr el objetivo de las empresas, las
cuales se ven en la necesidad de elaborar estrategias para aprovechar éstos
activos con su inherente valor organizacional. Bajo ésta premisa, el siguiente
trabajo tiene por objetivo facilitar un conjunto de pautas para las organizaciones de
TI que involucran planes de migración de aplicaciones legadas, especialmente las
desarrolladas bajo la plataforma Oracle Forms6i hacia una arquitectura que
permita desacoplar la lógica de negocio, presentación y acceso a datos y
aprovechar las potencialidades del Framework de Desarrollo de Aplicaciones
(ADF) de Oracle.

La presente Guía de Migración se convierte pues, en una herramienta de

orientación para las organizaciones que desean involucrar la reingeniería en sus
proyectos de evolución de aplicaciones legadas cliente-servidor hacia
arquitecturas multicapa.

* Trabajo de Grado
** Facultad de Ingeniería de Sistemas
Especialización en Procesos para el Desarrollo del Software
Director: Ing Luis Merchán Paredes

V
TITLE: DEVELOPMENT OF A GUIDE FOR LEGACY SYSTEMS MIGRATION
Oracle Forms6i TOWARDS A MULTI-LAYER ARCHITECTURE.*

AUTHOR: HUGO ALDEMAR GÓMEZ MARTÍNEZ**

KEY WORDS: LEGACY SYSTEMS, ORACLE FORMS6i, MIGRATION, GUIDE,

ARCHITECTURE, MULTI-LAYER, REENGINEERING, SOFTWARE

DESCRIPTION:

The current dynamics of business makes that organizations require information

systems that adapt to change. Therefore, legacy systems become an obstacle to
achieving the goal of companies, which feel the need to develop strategies to
leverage these assets with their inherent organizational value. Under this premise,
the following paper aims to provide a set of guidelines for IT organizations that
involve migration plans of legacy applications, especially those developed under
the Oracle Forms6i platform towards an architecture that allows decoupling the
business logic, presentation and data access and exploit the potential of Oracle’s
Application Development Framework (ADF).

Then, this Migration Guide becomes in a guidance tool for organizations that wish
to engage in reengineering projects evolution of legacy client-server applications to
multilayer architectures.

* Graduation Work
** Facultad de Ingeniería de Sistemas
Especialización en Procesos para el Desarrollo del Software
Project Director: Ing Luis Merchán Paredes.

VI
 TABLA DE CONTENIDO
INTRODUCCION ............................................................................................................. 1
1 GENERALIDADES .................................................................................................... 2
1.1 PLANTEAMIENTO DEL PROBLEMA .................................................................... 2
1.2 OBJETIVOS ........................................................................................................... 4
1.2.1 Objetivo General .............................................................................................. 4
1.2.2 Objetivos Específicos ....................................................................................... 4
1.3 JUSTIFICACION .................................................................................................... 4
1.4 IMPACTOS ESPERADOS DEL PROYECTO......................................................... 5
1.5 PLAN DE TRABAJO............................................................................................... 5
1.5.1 Fase de Análisis de Sistemas Legados. .......................................................... 6
1.5.2 Fase de Análisis de aplicaciones Oracle Forms6i como sistema legado. ........ 6
1.5.3 Fase de Análisis de arquitecturas objetivo multi-capa candidatas y sus
metodologías de migración. .......................................................................................... 6
1.5.4 Fase de Diseño de la guía de migración para aplicaciones Oracle
Forms6i hacia una arquitectura objetivo multicapa. ...................................................... 6
1.5.5 Fase de Generación de la Guía de migración.................................................. 6
1.6 CRONOGRMA ....................................................................................................... 7
2 MARCO TEÓRICO / ESTADO DEL ARTE ................................................................ 8
2.1 Sistemas Legados (3) ............................................................................................. 9
2.1.1 Características que hacen de un sistema, realmente un legado (12) ............ 10
2.1.2 Clasificación de los sistemas legados (12) (13) ............................................. 11
2.1.3 Opciones para la evolución de sistemas legados .......................................... 12
3 ARQUITECTURA E HISTORIA DE ORACLE FORMS ............................................ 19
3.1 ¿Qué es Oracle Forms? ....................................................................................... 19
3.2 ¿Cómo funciona Oracle Forms?........................................................................... 21
3.3 Integración con herramientas CASE de Oracle Designer ..................................... 21
3.3.1 Características de los Formularios o Formas en Oracle Forms. .................... 21
3.3.2 Lógica de aplicaciones en Oracle Forms y Oracle Reports ........................... 23
3.4 Arquitectura de las aplicaciones Oracle Forms .................................................... 24
3.5 Aplicaciones Oracle Forms como aplicaciones legadas ....................................... 25
4 ARQUITECTURA DE SOFTWARE ......................................................................... 28
4.1 Arquitectura multinivel .......................................................................................... 28
4.1.1 Arquitectura multinivel de una aplicación web ............................................... 29
4.2 Arquitectura multicapa .......................................................................................... 31
4.2.1 Patrón de diseño Model-View-Controller (MVC) ............................................ 31
4.3 Comparación de la arquitectura multinivel con MVC ............................................ 33
5 GUIA DE MIGRACIÓN DE SISTEMAS LEGADOS Oracle Forms6i HACIA
UNA ARQUITECTURA MULTICAPA ............................................................................. 34
INTRODUCCION ........................................................................................................ 34
CONTENIDO DE LA GUÍA ......................................................................................... 34
VII
5.1 Aspectos claves de la guía de migración y recomendaciones.............................. 35
5.1.1 Definiciones importantes y recomendaciones generales de migración.......... 36
5.1.2 Recomendaciones Específicas de migración Oracle Forms6i ....................... 38
¿Por qué se debe considerar la Modernización?........................................................ 38
5.2 Descripción técnica de las fases de migración ..................................................... 39
5.2.1 Consideraciones de la valoración del sistema legado ................................... 39
5.3 Establecimiento de un proyecto de reingeniería ................................................... 41
5.3.1 Establecimiento de la metodología ................................................................ 41
5.3.2 Sub-proyecto de ingeniería inversa ............................................................... 42
5.3.3 Sub-proyecto de desarrollo ............................................................................ 46
5.4 Conclusiones de la Guía ...................................................................................... 51
6 TRABAJO FUTURO ................................................................................................ 52
7 CONCLUSIONES .................................................................................................... 53
BIBLIOGRAFÍA .............................................................................................................. 54

VIII
 LISTA DE FIGURAS

FIGURA 1. CICLO DE VIDA DE UNA APLICACIÓN ......................................................................................................................... 10

FIGURA 2. CLASIFICACIÓN DE SISTEMAS LEGADOS (11) (12) ....................................................................................................... 11
FIGURA 3 . PROCESO DE SIMULACIÓN PROPUESTO POR PINHEIRO (14) ......................................................................................... 13
FIGURA 4. PROCESO DE MANTENIMIENTO DE SOFTWARE (13)..................................................................................................... 14
FIGURA 5. PERSPECTIVA DE REINGENIERÍA COMO SOLUCIÓN DE UN PROBLEMA DELIMITADO (3)......................................................... 15
FIGURA 6 . PERSPECTIVA DE REINGENIERÍA COMO SISTEMA (3) .................................................................................................... 16
FIGURA 7 . PROCESO DE REINGENIERÍA, PROPUESTO POR SOMMERVILLE (13) ................................................................................ 17
FIGURA 8. ELEMENTOS FORMS ............................................................................................................................................. 22
FIGURA 10. EJEMPLO DE LÓGICA EN UNA FORMA DE ORACLE FORMS6I ........................................................................................ 23
FIGURA 9. RELACIÓN ENTRE TABLAS O VISTAS CON BLOQUES DE DATOS ....................................................................................... 23
FIGURA 11. FORMS SERVER BASADO EN UNA ARQUITECTURA CLIENTE/SERVIDOR ............................................................................ 24
FIGURA 12. ARQUITECTURA DE ORACLE FORMS 10G EN ADELANTE ............................................................................................. 25
FIGURA 13. CICLO DE VIDA DE ORACLE FORMS ........................................................................................................................ 26
FIGURA 14. ASPECTOS CONSIDERADOS PARA VALORACIÓN DE UN SISTEMA .................................................................................... 27
FIGURA 15. DIAGRAMA DE UN ENTORNO DE APLICACIÓN WEB MULTINIVEL ................................................................................... 29
FIGURA 16. RELACIÓN ENTRE LOS MÓDULOS DEL PATRÓN MVC .................................................................................................. 32
FIGURA 17. USO DEL PATRÓN OBSERVADOR PARA DESACOPLAR EL MODELO ACTIVO DE LA VISTA........................................................ 32
FIGURA 18 . UNA COMÚN INFRAESTRUCTURA DE TI LEGADA....................................................................................................... 40
FIGURA 19. PASOS CLAVES PARA EL MAPEO DE LAS DISCIPLINAS Y FASES DE RUP ............................................................................ 43
FIGURA 20. DOCUMENTAR EL PROCESO DE NEGOCIO APOYADO Y EL MODELO DE DOMINIO ............................................................... 44
FIGURA 21. ANALIZAR LA ARQUITECTURA DE LA ACTUAL BASE DE DATOS ....................................................................................... 44
FIGURA 22. EJEMPLO DE ACOPLAMIENTO EN UNA APLICACIÓN ORACLE FORMS6I ........................................................................... 48
FIGURA 23. ARQUITECTURA DE MIGRACIÓN DE APLICACIONES FORMS HACIA JEE+ADF .................................................................. 50

IX
 LISTA DE TABLAS

TABLA 1. CRONOGRAMA DE ACTIVIDADES ................................................................................................................................. 7

TABLA 2. RESUMEN DE LAS VERSIONES DE ORACLE FORMS......................................................................................................... 20
TABLA 3 FECHAS RELEVANTES DE SOPORTE .............................................................................................................................. 26
TABLA 4. TAREAS PARA CADA ROL INVOLUCRADO EN LA CONSTRUCCIÓN DE MODELOS ABSTRACTOS .................................................... 45
TABLA 5. TAREAS PARA CADA ROL INVOLUCRADO EN RECUPERAR LA ARQUITECTURA DEL SISTEMA LEGADO ........................................... 45
TABLA 6. APROXIMACIONES POSIBLES PARA EL MANEJO DE LA LÓGICA DE NEGOCIO. ........................................................................ 48

X
INTRODUCCION
Los permanentes avances tecnológicos, el creciente grado de complejidad de los
sistemas de información y el permanente cambio de los requerimientos de los
usuarios son algunos de los factores del aumento de los sistemas legados en el
ecosistema tecnológico de las organizaciones, razón por la cual en muchas de
ellas llevan a la consideración evolucionar, mantener o migrar dichos sistemas.

Dentro del ciclo del desarrollo del software, la etapa del mantenimiento es una de
las más importantes y menos planeadas, aunque es una de las últimas en
realizarse se ha convertido en la principal actividad en cuanto a recursos
necesarios y costes.

Según la terminología ANSI-IEEE, el mantenimiento del software es: “El proceso

de modificar un sistema de Software o componente de éste, una vez ha sido
entregado, para corregir fallas, mejorar el desempeño u otras características,
adaptar o cambiar su entorno...”

Aclarado el anterior término, se entiende el por qué las empresas gastan en

promedio entre el 60 y 85 por ciento de su presupuesto de Tecnología de
Información en mantenimiento de aplicaciones legadas que no cumplen con las
necesidades cambiantes de la competencia de la organización1. A pesar de la
posible obsolescencia, los sistemas legados continúan manteniendo una ventaja
competitiva a través del apoyo al proceso de negocio, acumulando invaluable
conocimiento y data histórica (1).

Diversos factores internos y externos, económicos, de mercado, legales,

administrativos o políticas de organización, exigen cambios continuos en el
negocio. Estos cambios generan o causan modificaciones en los requerimientos
de software que recaen sobre los sistemas tecnológicos, haciendo necesaria la
introducción de cambios para alinearse a los nuevos requerimientos del negocio
(2).

Por consiguiente si en la organización, luego de evaluadas las alternativas para el

aprovechamiento de los sistemas legados, se elige la migración como estrategia;
el propósito del presente proyecto servirá de guía en definir criterios claves para la
migración de sistemas legados, específicamente aquellos basados en tecnología
Oracle Forms6i cuya arquitectura objetivo sea hacia una arquitectura multi-capa.

1
An Executive Guide to Oracle Modernization. Enabling Strategic Business Transformation.
Oracle.com

1
 CAPITULO 1.
1 GENERALIDADES

1.1 PLANTEAMIENTO DEL PROBLEMA

La creciente competitividad de las compañías, por esforzarse a ser más eficaces y
efectivas en el desarrollo cotidiano de sus actividades, hace que las directrices
empresariales permanezcan en constante cambio para lograr sus objetivos. Estos
cambios frecuentemente afectan los procesos del negocio, casi siempre
administrados en los sistemas de información de las compañías, los cuales deben
ser adaptados para soportarlos.

En el momento que estos sistemas de información se resistan al cambio de las

crecientes necesidades de las compañías para tener contacto más cercano con
sus clientes, al cambio tecnológico organizacional, a la integración con otros
sistemas o al uso de la internet como canal comunicación, por ejemplo; se
considerarían “sistemas legados” y se requeriría de un análisis de las estrategias
de aprovechamiento de estos sistemas.

De esta manera, los sistemas de información que fundamentalmente estén

dirigidos a la parte operativa de las organizaciones, cuyo mantenimiento o soporte
es costoso, y normalmente son de misión crítica además de tener una integración
de componentes en donde se mezclan presentación y lógica de negocio, tales
como las aplicaciones Oracle Forms6i actualmente, podrían catalogarse como
sistemas de información legados y representarían para la organización una
desventaja tecnológica que se hace necesaria de evolución.

Muchos de esos sistemas de información que permanecen funcionando durante

años, se convierten en islas muy eficientes en la estructura vertical de la
organización, pero están desactualizadas tecnológicamente, son monolíticas y su
integración horizontal con otros sistemas software se han convertido en un
verdadero reto (3). Este proceso de evolución e integración involucra cambios a
nivel tecnológico, los cuales en el contexto de la migración de software encuentran
cualidades de transformación o adaptación.

Cerca del 80 % de los sistemas de información todavía corren en plataforma

legada (4), pero el deseo de reemplazar estos legados se ve limitado por
restricciones como:

2
 • Grandes inversiones acumuladas en el sistema legado en largo tiempo.
• Disminución del personal técnicamente habilitado.
• Pérdida significativa de conocimiento sobre las tareas internas que trabajan
estos sistemas.

Estas restricciones impiden a las organizaciones reemplazar estos sistemas de

una forma rápida y económica (4), las cuales, al considerar los costos de
producción y mantenimiento de sus sistemas legados, sus dificultades de
integración con otros sistemas, además de funcionalidades altamente acopladas
convertidas en factores que aceleran la obsolescencia del software; optan por
evolucionarlas mediante procesos de reingeniería en donde la migración de las
aplicaciones se convierte en la decisión más adecuada.

3
1.2 OBJETIVOS
1.2.1 Objetivo General

Facilitar una guía que sirva como complemento a los proyectos de reingeniería
para la migración de aplicaciones basadas en tecnología Oracle Forms6i hacia
una plataforma multicapa.

1.2.2 Objetivos Específicos

Establecer los factores que convierten a un sistema software en un sistema

“legado” para que las organizaciones puedan mitigarlos.

Identificar las alternativas de evolución de los sistemas legados con el fin de

elaborar el marco conceptual de la guía de migración.

Identificar las fases requeridas para la guía de migración del sistema legado
en un contexto evolutivo.

Analizar la propuesta de Oracle para la evolución de las aplicaciones

legadas Oracle Forms6i dependiendo de su valoración.

1.3 JUSTIFICACION
Durante mucho tiempo, las organizaciones han acumulado valioso conocimiento
de sus negocios en sistemas de información que adaptaron para soportar su
operación, delegándoles una responsabilidad importante en los procesos del
negocio. Estos sistemas con el paso del tiempo fueron madurando junto a las
reglas del negocio dentro de las fases de mantenimiento a las que fueron
expuestos, llegando en muchos casos a un punto en donde la tecnología limitaba
su continua evolución.

En estos casos las directivas de las organizaciones, viendo el creciente y

acelerado avance tecnológico ven posibles ventajas que les ayudarían a mejorar
su competitividad de la mano de cambios constantes en las estrategias del
negocio. Por ésta razón, los ejecutivos de informática durante las etapas de
mantenimiento preventivo y/o correctivo de los sistemas de información con los
que cuenta la organización, se les hace prioritario no perder el ritmo de las
tendencias tecnológicas que permitan apoyar el logro de los objetivos de la
organización.

Aunque existen varias alternativas de evolución de sistemas legados, en algún

momento la migración de aplicaciones legadas de la mano de la reingeniería se

4
hace evidentemente como la opción más adecuada por costes y beneficios para la
organización.

Para el caso de los proyectos de Ingeniería del Software que involucren la

evolución de aplicaciones, y más específicamente en la migración de aplicaciones
legadas con tecnología Oracle Forms6i, una guía de migración de aplicaciones
legadas se convierte en un activo importante con el que se puede contar durante
las fases de planificación del proyecto.

En síntesis la “ELABORACIÓN DE UNA GUÍA PARA LA MIGRACIÓN DE

SISTEMAS LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTI-
CAPA”, es un instrumento de apoyo en las etapas de planeación o análisis de los
proyectos de migración de aplicaciones legadas Oracle Forms6i cuya arquitectura
objetivo sea una arquitectura objetivo multi-capa, para establecer criterios básicos
que se deban considerar en la evolución de los sistemas legados que usen ésta
tecnología.

1.4 IMPACTOS ESPERADOS DEL PROYECTO

• Acelerar la etapa de análisis en proyectos que involucren evolución de
sistemas legados con tecnología Oracle Forms6i.

• Mejorar la integración de datos en toda la organización luego de desacoplar

en capas la arquitectura de los sistemas de información valorados como
legados.

• Servir como marco de referencia para la identificación de factores que

puedan afectar el desarrollo de proyectos de migración, permitiendo la
reducción de costes.

Resultado/Producto Esperado Indicador Beneficiario

Guía de migración Guía Entidades interesadas en
realizar proyectos de
migración de aplicaciones
legadas

1.5 PLAN DE TRABAJO

A continuación se detallan las fases y sus actividades que ayudarán a cumplir los
objetivos planteados:

5
1.5.1 Fase de Análisis de Sistemas Legados.

a. Recopilar información que sirva como soporte del marco teórico

relacionado con los sistemas legados.
b. Estudiar los conceptos de sistemas legados, características y técnicas de
migración.
c. Establecer criterios de clasificación de los sistemas legados.

1.5.2 Fase de Análisis de aplicaciones Oracle Forms6i como

sistema legado.
a. Recopilar la información directamente de la fuente de la tecnología Oracle
Forms6i.
b. Establecer las características que pueden hacer hoy en día un sistema
basado en Oracle Forms6i considerado como legado.

1.5.3 Fase de Análisis de arquitecturas objetivo multi-capa

candidatas y sus metodologías de migración.

a. Recopilar información que sirva como soporte del marco teórico

relacionado con las arquitecturas multi-capa y sus metodologías de
migración.
b. Comparar las ventajas ofrecidas por cada arquitectura multi-capa.
c. Proponer una arquitectura y una metodología para la migración de
aplicaciones legadas Oracle Forms6i.

1.5.4 Fase de Diseño de la guía de migración para aplicaciones

Oracle Forms6i hacia una arquitectura objetivo multicapa.

a. Recopilar la información directamente de la fuente de la tecnología Oracle

Forms6i.
b. Establecer las características que pueden hacer hoy en día un sistema
basado en Oracle Forms6i considerado como legado.

1.5.5 Fase de Generación de la Guía de migración.

a. Recopilar la información directamente de la fuente de la tecnología Oracle
Forms6i.
b. Establecer las características que pueden hacer hoy en día un sistema
basado en Oracle Forms6i considerado como legado.

6
1.6 CRONOGRMA

Tabla 1. Cronograma de Actividades

Mes

Mes

Mes

Mes

Mes
1

5
Fase
1. Análisis de Sistemas Legados. X X X
2. Análisis de Oracle Forms6i como
X X X
sistema legado.
3. Análisis de arquitecturas candidatas
X X X X
multi-capa.
4. Diseño de la guía de migración para
aplicaciones Oracle Forms6i hacia una X X X X
arquitectura objetivo multi-capa.
5. Generación de la Guía de migración. X X X X

Entrega de Resultados. X

7
 CAPITULO 2. ESTADO DEL ARTE

2 MARCO TEÓRICO / ESTADO DEL ARTE

Las Tecnologías de Información - IT2, más que nunca, tienen un impacto directo
sobre la competitividad, calidad, productividad, la línea base y la supervivencia del
negocio. Esta es una realidad tanto para el sector privado como para las agencias
gubernamentales. Como resultado, los ejecutivos no pueden alejar a las
Tecnologías de Información, sino por el contrario involucrarlas en la creciente
innovación del negocio.

Las organizaciones ahora encuentran que las IT se han convertido en un

entramado junto con la infraestructura de sus negocios tanto que no parece lejos
imaginarlas sobreviviendo sin sus sistemas de información crítica (5).

Las organizaciones tienen una opción cuando se trata de crear soluciones más
ágiles y favorables a los negocios para responder a los cambios en curso en la
"arquitectura de negocio", la Tecnología de Información - IT. La arquitectura del
negocio es definida como “un bosquejo de la empresa que suministra un
entendimiento común de la organización y es usado para alinear objetivos
estratégicos y demandas de táctica”. Es llamada Arquitectura basada en la
modernización (MDA)3 o, simplemente, "modernización". La arquitectura basada
en la modernización es definida como “Un conjunto colectivo de herramientas y
disciplinas que facilitan el análisis, la refactorización y la transformación de activos
software existentes para apoyar una amplia variedad de escenarios de negocio
basados en IT” (6).

OMG4, define la Arquitectura basada en la modernización como el “proceso de

entendimiento e involucramiento de los activos software con el propósito del
mejoramiento del software; modificación; interoperabilidad; refactorización;
reestructurado; reuso; migración; traducción; integración; arquitectura orientada a
servicios; y transformación de la arquitectura basada en modelo” (5) (6).

El concepto de modernización ha estado involucrado en una gran variedad de

escenarios del negocio en donde las organizaciones intentan entender,

2
Véase http:// wordnetweb.princeton.edu/perl/webwn .Information Technology – IT o Tecnologías
de Información - TI: Rama de la ingeniería que se ocupa del uso de las computadoras y las
telecomunicaciones para recuperar, almacenar y transmitir información.
3
Model Driven Architecture (MDA)
4
Object Management Group (OMG).

8
evolucionar o reemplazar las aplicaciones y arquitectura de datos existentes,
debido a la dinámica misma de las reglas del negocio; por lo que muy a menudo,
adaptar los sistemas legados para nuevos requerimientos también requiere su
migración a una nueva tecnología. La migración de sistemas legados, en otras
palabras, es la transferencia de sistemas software a nuevos entornos sin cambiar
su funcionalidad (7), y permite a las aplicaciones ya probadas estar en
funcionamiento en vez de la desaparición luego de algún mantenimiento
suspensivo (8).

La migración de Software involucra la transformación o adaptación de un sistema

software existente a un nuevo contexto tecnológico. De acuerdo con el estándar
IEEE 1219 sobre Mantenimiento de Software (9), la migración del software cae
bajo la sombrilla más ancha del mantenimiento adaptativo.

Las actividades de migración van desde cambios en la plataforma hardware

debido a su obsolescencia, cambio del sistema operativo, cambio en la
arquitectura (p.ej., desde una arquitectura centralizada basada en mainframe
hacia una arquitectura cliente-servidor o hacia una arquitectura orientada a
servicio (SOA)), hasta cambio de interfaz de usuario (p.ej., desde una interface
textual hacia una interface gráfica o basada en web) (10).

2.1 Sistemas Legados (3)

A. O’Callaghan, define un sistema “legado”5 como una aplicación de software que
posee un importante valor de negocio, y aunque se ha debilitado por el constante
cambio tecnológico, un pobre soporte arquitectónico, alto costo de mantenimiento
o documentación inexistente, se mantiene en producción.

5
Andy Kyte, Gartner Group. Eliminate 'Legacy' in One Simple Step. “Un sistema de etiquetado como
"legado" es degradante para el sistema y no proporciona información útil sobre el valor que ofrece ni una
indicación de la futura estrategia para el sistema. Más útiles y mejores descriptores pueden y deben ser
utilizados.”.

9
 Figura 1. Ciclo de vida de una Aplicación
Las aplicaciones existentes son el resultado de las inversiones de capital del
pasado. El valor de la inversión en la aplicación tiende a disminuir con el tiempo, la
empresa y el contexto tecnológico cambia. A principios del ciclo de vida habrá una
creciente inversión por mantener una estrecha vinculación con el negocio pero con
el tiempo llegará un punto en que se hace difícil, ver Figura 1. Esto puede ocurrir,
por ejemplo, donde la infraestructura de soporte se ha visto rebasada, el acceso a
Internet es necesario, o el peso de los cambios en las aplicaciones y la falta de
conocimientos disponibles hacen que sea imposible continuar con las mejoras
(11).

2.1.1 Características que hacen de un sistema, realmente un

legado (12)

1. Se trata de un sistema escrito en lenguajes de varios años atrás como:

Cobol, RPG, PL, Assembler.
2. Normalmente estos sistemas son soportados por un DBMS (manejador de
base de datos) ya obsoleto.
3. La interface de cliente está basada en terminales las cuales no son
gráficas.
4. Las aplicaciones que componen el sistema, son frecuentemente
monolíticas, las cuales fueron desarrolladas para suplir una necesidad de la

10
 organización, separadas del resto del sistema, presentando una integración
normalmente vertical.
5. Es un sistema fundamentalmente dirigido a la parte operativa de las
organizaciones, normalmente de misión crítica para la organización que
requiere estar operando todo el tiempo.
6. Suelen ser sistemas bastante complejos y grandes (millones de líneas de
código y lógica de negocio).
7. Estos tipos de sistema suelen no tener ningún tipo de documentación, no es
posible hacer trazabilidad de funcionalidad.
funcional

Un sistema legado no necesariamente tiene que cumplir una o varias de las

anteriores características para que sea considerado como tal, por el contrario, se
le considera legado a aquel sistema que se resiste a las modificaciones y
actualizaciones perdiendo
rdiendo competitividad
competitividad,, y aunque fue desarrollado aplicando
principios de ingeniería, su arquitectura no es lo suficientemente flexible como
para absorber los cambios provocados por nuevos requerimientos (3).

2.1.2 Clasificación de los sistemas legados (12) (13)

En la siguiente figura se muestra la clasificación de un componente o aplicación

según su tipo de acoplamiento en el manejo de la información. Ver Figura 2.

Figura 2.. Clasificación de sistemas legados (12) (13)

Massari6, los resume:

Altamente desacoplados,
desacoplados, están bien estructurados y tienen ciertas
cierta características
fundamentales:
• Los componentes de la aplicación son separables, presentación, la lógica
de negocio y el acceso a los datos, es decir, el software se descompone
descom en
tres capas lógicas.
• Los módulos de aplicación son independientes entre sí (no ( hay
interdependencias jerárquicas).

6
Massari A, Mecella. (13).

11
 • Los módulos de aplicación tienen interfaces bien definidas con los servicios
de base de datos, presentar y otras aplicaciones.

Desacoplamiento de datos, son sistemas llamados semi-estructurados con las

siguientes características clave:
Los componentes de la aplicación se dividen en dos niveles: los servicios de
acceso a datos y la presentación y la lógica de la aplicación (fusionados en un solo
bloque).
Los módulos de aplicación tienen interfaces bien definidas para otras aplicaciones.
En estos sistemas, puede acceder directamente a los datos, pero no la lógica de la
aplicación.

Desacoplamiento de programas, también son semi-estructuradas con las

siguientes características:
• Los componentes de la aplicación se dividen en dos niveles: los servicios
de presentación y el acceso a datos y lógica de la aplicación (fusionados en
un solo bloque).
• Los módulos de aplicación tienen interfaces bien definidas para otras
aplicaciones.
• En estos sistemas no pueden acceder directamente a los datos, pero es
necesario recurrir a las funciones incorporadas (por lo general una
transacción).
• Esta categoría incluye a la mayoría de las aplicaciones legadas.

Monolítico, sistema no estructurado, en el cual el componente aplicativo es un solo

bloque que contiene todos los niveles. Son accedidos generalmente a través de la
invocación desde terminales.

La decisión del tratamiento de un sistema legado no es fácil (3), ya que las

opciones irían desde desecharlo completamente para reemplazarlo por uno nuevo,
con un alto riego de fracaso y altos costos o continuar su uso asumiendo los
costos de mantenimiento, también la opción de la modificación en pro de mejorar
su capacidad de mantenimiento, solución a corto plazo o mediante procesos de
reingeniería agregar componentes que lo dinamicen para garantizar su viabilidad
en un futuro. Por lo anterior no se puede generalizar el tratamiento para todos los
sistemas legados y su solución, ya que dependen del contexto mismo del
problema.

2.1.3 Opciones para la evolución de sistemas legados

Las alternativas para la actualización de los sistemas legados dependen en gran

medida de la valoración del sistema: valor del negocio vs calidad del sistema (14),
y con base en ésta decidir una estrategia para la evolución de los mismos, tales
como:

12
Abandonar el sistema legado y sustituirlo por uno nuevo. Esta opción debería
elegirse cuando los procesos de negocio no reciben alguna contribución por parte
del sistema, por lo que se debería planear la migración del sistema legado a un
nuevo sistema. Al respecto Pinheiro (15) propone un proceso para simular y
determinar el comportamiento de la migración antes de hacerla operativa.

Éste modelo se basa en la definición de una carga de trabajo sintética7, de la que

se derivan actividades de modelamiento, experimentación, simulación y validación
para predecir el comportamiento de un sistema objetivo o de destino.

El proceso de simulación para la evaluación del funcionamiento de un sistema de

destino se muestra en el diagrama de actividad en la Figura 3 mediante la producción
de un modelo válido. En la etapa de modelamiento se específica el modelo, en la
actividad de simulación se ejecuta el modelo y se producen las salidas de la
simulación, que junto a los resultados de la experimentación, permiten hacer la
validación

Figura 3 . Proceso de simulación propuesto por Pinheiro (15)

Si los resultados son similares el modelo se considera válido, de lo contrario se

somete a una actividad de refinamiento y se vuelve a hacer la simulación, esto se

7
Carga de trabajo sintética: Concepto que define al conjunto de información recogida tanto del
nuevo sistema como del sistema legado como insumo para la propuesta de simulación.

13
repite hasta que la diferencia de resultados entre simulación y experimentación
sea escasa. El modelo validado y aceptado se pasa a la actividad de predicción
del que resulta la descripción del comportamiento del nuevo sistema (15).

Abandonar el sistema no significa empezar un desarrollo desde cero. No se puede

pensar que los datos que contiene el legacy van a desecharse y que los valores
que conservan los expertos del sistema van a perderse. El abandono del sistema
debe venir precedido por una análisis exhaustivo que permitan decidir el método
que se va a utilizar para la migración de la información del sistema actual al nuevo,
incluyendo datos, funciones de negocio y arquitectura del sistema (16).

Ésta alternativa de abandono del sistema legado tiene un riesgo inherente “el
costo” y debe estar contemplado dentro del plan de migración, el cual puede
mitigarse adoptando una estrategia de reemplazo evolutiva (14).

Garantizar mantenimiento del sistema actual. Una definición de mantenimiento

dada por ISO/IEC:
“Un producto software soporta una modificación en el código y su documentación
asociada para la solución de un problema o por la necesidad de una mejora. Su
objetivo es mejorar el software existente manteniendo su integridad”.

Figura 4. Proceso de mantenimiento de software (14)

Se elige ésta alternativa cuando el sistema es útil a los procesos de la

organización y las peticiones de cambio de los usuarios son mínimas. En dado
caso Sommerville (14) propone un conjunto de actividades que conforman el
proceso de mantenimiento de la Figura 4.

Reingeniería del sistema actual. La reingeniería del software se refiere a la re

implementación de los sistemas heredados para hacerlos más mantenibles (14).
La definición dada por el Reengineering Center del Software Engineering Institute
de la Universidad Carnegie Mellon es:

14
“Reingeniería es la transformación sistemática de un sistema existente a una
nueva forma para realizar mejoras de la calidad en operación, capacidad del
sistema, funcionalidad, rendimiento o capacidad de evolución a bajo coste, con un
plan de desarrollo corto y con bajo riesgo para el cliente”.

Las concepciones alrededor de la reingeniería de software son muy variadas, van

desde suponer mejoras en la comprensibilidad y mantenimiento del software (14),
diagnosticar y reconstruir el software, aplicación de ingeniería inversa e ingeniería
directa al código existente, pero quizás la más amplia y aceptada es considerarla
una forma de reutilización, que mejora la calidad y reduce el esfuerzo de llevar un
sistema existente a un nuevo contexto (3).

Sommerville (14), establece una distinción crítica de la reingeniería y un nuevo

desarrollo en donde el sistema antiguo actúa como una especificación para el
nuevo sistema. Por lo tanto, el bajo riesgo que supone partir de una base sólida y
funcional de software y el coste reducido, se convierten en dos ventajas clave
sobre aproximaciones más radicales a la evolución del sistema. A continuación se
presentan algunos de los enfoques de la reingeniería (17):

Figura 5. Perspectiva de reingeniería como solución de un problema delimitado (3)

1) Reingeniería desde una Perspectiva de ingeniería (17)

La reingeniería puede ser vista como un problema limitado de problemas, en
donde la evolución del sistema se logra mediante la comprensión del sistema
actual y un plan de que permita lograr el sistema deseado. Ver Figura 5.

2) Reingeniería desde una Perspectiva de sistema (17)

En la reingeniería de sistemas es importante entender que el sistema operacional
es sólo una parte del entorno legado total.

15
 Figura 6 . Perspectiva de reingeniería como sistema (3)

El modelo que guía el proceso de reingeniería propone actividades para la

planeación, identificación descripción, comprensión, fortalecimiento y evaluación
de factores técnicos, administrativos y del proyecto, ofreciendo un contexto para
unificar la terminología de las actividades de reingeniería, difundiendo las
lecciones aprendidas al respecto, como se ilustra en la Figura 6.

3) Reingeniería desde una Perspectiva evolutiva

Los sistemas evolutivos se definen como sistemas que son capaces de acomodar
los cambios a través de una vida útil prolongada. La tecnología que soporta los
sistemas evolutivos debe habilitar la creación de sistemas que están diseñados
para evolucionar y la transformación de los sistemas legados de hoy en los
sistemas evolucionables.
Es por esto que ésta perspectiva propone un modelo de ciclo de vida basado en
una continua evolución, suponiendo que el software nunca está terminado.

4) Reingeniería desde una perspectiva del software

En esta perspectiva Sommerville (14) propone una metodología que define varias
tareas y es descrita en la Figura 7. Inicialmente, se hace una traducción del código
fuente a otro lenguaje o por lo menos a una versión actualizada.

16
 Figura 7 . Proceso de reingeniería, propuesto por Sommerville (14)

La reingeniería de software se puede hacer utilizando varias alternativas:

1) Modernización de caja blanca (16): Se fundamenta en la identificación de los
componentes del sistema y sus relaciones para conseguir una representación a
niveles mayores de abstracción, conocida también como ingeniería inversa; cuya
ventaja es la recuperación del diseño y la funcionalidad del sistema desde el
código para modernizar el lenguaje de programación o el soporte de los datos.
2) Modernización de caja negra o Wrapping8 (16): es una técnica de reingeniería
en la que sólo se analizan las interfases (las entradas y salidas) del legacy
ignorando los detalles internos. La reingeniería basada en wrapping puede
realizarse a nivel funcional, de datos o de interfase. En cada una de ellas se
emplean técnicas que se describen a continuación.

Wrapping de interfases de usuario. Se busca dar mayor facilidad de operación,

modernizando la interfase de usuario, a menudo usando una técnica conocida
como screen scraping9, la cual envuelve la interface basada en texto con un
entorno gráfico basado en GUI o en HTML.

Wrapping de datos. Permite accede a los datos del legado usando una interfaz
diferente a la diseñada inicialmente.

• Usar puentes hasta los nuevos lenguajes de implementación haciendo uso

de Gateway de base de datos, emplea interfaces propietarias en la base de
datos del legacy e interfaces estándares (ODBC, JDBC) como puentes
hasta los nuevos lenguajes de implantación.

8
Pedraza (3), cita a E. Wohlstadter, S. Jackson, P. Devanbu. para definir a los wrappers como una
capa envolvente de software que aísla un sistema legado de una exigente carga de
interoperabilidad, de forma que el sistema pueda mantenerse incluso sin modificaciones.
9
Véase la definición en http://es.wikipedia.org/wiki/Screen_scraping

17
 • Integración con tecnología XML aprovechando el intercambio de datos
entre sistemas o negocios.
• Replicación de datos, esta es utilizada comúnmente para descentralizar el
almacenamiento masivo de datos de los Mainframes, buscando que bases
de datos locales repliquen parte de los datos centralizados.
• Capa de persistencia, ésta es construida específicamente para cada
sistema, buscando el acceso de aplicaciones desarrolladas con tecnología
orientada a objetos.

Wrapping funcional. Encapsula datos y funcionalidades del legado, se emplean

técnicas como:
• Integración con CGI que permite el acceso al legacy usando Common
Gateway Interface mediante servidores Web o HTTP.
• Object Oriented Wrapping (OOW). La tecnología de objetos distribuidos
(DOT) es la combinación de la orientación a objeto con la distribución
(middleware objeto) (CORBA).
• Wrapping basado en componentes. Este método utiliza el modelo de
componentes distribuidos, donde la idea es separar la interface del sistema
legado en módulos agrupados por unidades lógicas, buscando un punto de
contacto único, a través del cual se establece la comunicación entre un EJB
por ejemplo y una función concreta del sistema legado.

18
3 ARQUITECTURA E HISTORIA DE ORACLE
FORMS
3.1 ¿Qué es Oracle Forms?
Oracle Forms es un producto de software para la creación de pantallas que
interactúan con una base de datos Oracle. Cuenta con un IDE que incluye un
navegador de objetos, hoja de propiedades y editor de código que utiliza PL / SQL.
Fue desarrollado originalmente para ejecutarse en el servidor en modo de
sesiones de carácter terminal. Fue portado a otras plataformas, incluyendo
Windows, para funcionar en un entorno cliente-servidor. Las versiones posteriores
fueron portadas a Java que se ejecutan en un contenedor Java EE y puede
integrarse con Java y servicios web.

El enfoque principal de las formas es la creación de sistemas de entrada de datos

más que el acceso a una base de datos Oracle. En la mayoría de lanzamientos de
una base de datos Oracle usualmente resulta una nueva mayor versión de Oracle
Forms para soportar nuevas características en la base de datos.

A continuación en la Tabla 2 se muestra la evolución que ha tenido Oracle Forms

gestionado por la corporación Oracle:

19
Tabla 2. Resumen de las Versiones de Oracle Forms10
(*1) Character/
Name Version Comments
Database GUI
IAF 2 Character No IDE
FastForms+IAG 4 Character
SQL*Forms 2 5 Character
SQL*Forms 2.3 5 Character New IDE, No PLSQL, User Exits, INP ASCII File, FRM Runtime File
SQL*Forms 3 6 Character Major Rewrite, New IDE, PLSQL, X Support, Generate code to enforce constraints
Gui / Major Rewrite, New IDE, FMB source binary file, FMX Runtime, optimized for Client-Server. New interface is
Oracle Forms 4.0 6-7
Character slow, buggy and not popular with client base.
Major Rewrite, New IDE based on Object Navigator & Property Sheets. Good release, fast, popular with client
base. Oracle wanted customers to upgrade from v4 quickly because v4 was very buggy and Oracle was
Gui / contracted to support v4 for a period of time for some large, important customers. So, Oracle named this
Oracle Forms 4.5 7
Character release 4.5 (rather than 5) which allowed Oracle to claim continued support for v4. This allowed some
customers who were locked into v4 for the life of their project to upgrade from v4 to v4.5 by claiming that this
was a patch release even though it was clearly a major release.
Gui /
Oracle Forms 5 7
Character
Gui / Forms Server / Web Forms introduced. Client-Server still available and used by most clients. Forms Server
Oracle Forms 6 8
Character mode is slow, buggy and uses a lot of memory per session.
Gui /
Oracle Forms 6i 8
Character
Client-Server runtime removed leaving Forms Server as only runtime option. Same memory requirements as
Oracle Forms 9i (*2) 9i Gui
before but memory is now cheaper so not as big an issue.

Oracle Forms 10g 10g Gui This is a Forms 9 release (9.0.4.0.19). Renamed externally to indicate support for 10g database. Menu-Help-
About displays v9.0.4.0.19. Not forward compatible with 10gr2 (cant open 10gr2 forms in 10g/904)
Oracle Forms 10gr2 10gr2 Gui version 10.1.2.0.2 - registry home key moved. Max NUMBER length reduced from 40 to 38
Oracle Forms 11g 11g GUI
(*1) Cada versión de Oracle Forms puede conectarse a numerosas versiones de bases de datos ORACLE y es vendido y lanzado separadamente de la Base de Datos ORACLE. Oracle
Forms es generalmente compatible con versiones posteriores y anteriores de la Base de Datos ORACLE, por ejemplo: Oracle Forms 9 puede conectarse a menores versiones Oracle 8, 9,
10 y 11. Las versiones de bases de datos listadas aquí son las versiones primarias que estuvieron disponibles en el momento del lanzamiento de Forms.
(*2) Los productos Oracle históricamente han seguido su propia numeración-release y convenciones de nombrado. Esto cambió con Oracle RDBMS 9i release cuando Oracle
Corporation inició la estandarización de Oracle Forms (y Reports y Developer) para usar el mismo mayor número de versión que la base de datos. Esto explica el salto en Oracle Forms
versiones desde 6i a 9i (no hubo v7 o v8).

10
Tomado de Wikipedia: http://en.wikipedia.org/wiki/Oracle_Forms
20
3.2 ¿Cómo funciona Oracle Forms?11
Oracle Forms accede a la base de datos Oracle y genera una pantalla que
presenta los datos. La forma de código fuente (*.FMB) se compila en un
"ejecutable" (*.FMX), que se ejecuta (interpreta) por el módulo de tiempo de
ejecución de las formas. El formulario se utiliza para ver y editar datos en
aplicaciones con bases de datos. Varios elementos de la GUI, como botones,
menús, barras de desplazamiento, y los gráficos se pueden colocar en el
formulario.

El entorno provee la creación integrada de registros, modo de consulta y

actualización, cada uno con sus propios manipuladores de datos por defecto.
Esto reduce al mínimo la necesidad de las operaciones comunes y tediosas de
programar, como la creación de SQL dinámicos, detección de campos
modificados, y el bloqueo filas.

Como es normal con las interfaces orientadas a eventos, el software implementa

las funciones de control de eventos llamados disparadores o triggers que se
invocan automáticamente en las etapas críticas en el procesamiento de
registros, la recepción de las pulsaciones del teclado, y la recepción de los
movimientos del ratón. Existen diferentes disparadores o triggers que pueden
ser llamados antes, durante y después de cada paso crítico.

Cada función de trigger inicialmente es un bloque, con una acción

predeterminada o nada. La programación Oracle Forms por lo tanto
generalmente consiste en modificar el contenido de estos disparadores, a fin de
modificar el comportamiento predeterminado. Algunos triggers, si se proporciona
por el programador, sustituye la acción por defecto, mientras que otros
aumentan.

Como resultado de esta estrategia, es posible crear una serie de diseños o

layouts de forma predeterminada que posean la funcionalidad de base de datos
completa a pesar de que no haya del todo código escrito por el programador.

3.3 Integración con herramientas CASE de Oracle

Designer
Oracle Designer es una herramienta CASE capaz de generar diversos módulos
de software incluyendo Oracle Forms y Oracle Reports.

3.3.1 Características de los Formularios o Formas en Oracle

Forms.

11
Tomado de Wikipedia: http://en.wikipedia.org/wiki/Oracle_Forms

21
 Figura 8. Elementos Forms
Cuando se crea un módulo de formulario en Oracle Forms Designer (Ver Figura
8), se trabaja con varios objetos específicos para formar módulos (18), que
incluyen:

Window: Una ventana es, por sí mismo, un marco vacío. Tiene una barra de
título y se ocupa de la interacción, permitiendo a los usuarios finales para
desplazarse, mover y cambiar el tamaño de la ventana.

Canvas: Son objetos de fondo sobre el que se colocan los objetos de interfaz y
los elementos gráficos que los usuarios finales interactúan al usar una aplicación
Forms Builder.

Block: Los bloques son contenedores lógicos para los elementos de Forms
Builder, y son la unidad básica de información en un módulo de formulario. Un
módulo de formulario contiene normalmente varios bloques.

Item: Son objetos de la interfaz que muestran información a los usuarios finales
y les permiten interactuar con la aplicación.

Cuando se crea un bloque de datos, se vincula las columnas de la tabla o vista

con objetos de la interface de Forms Builder. Ver Figura 9.

22
 Figura 9. Relación entre Tablas o Vistas con Bloques de Datos

En tiempo de ejecución, los usuarios finales podrán manipular elementos de la

interfaz en el módulo de datos para consultar, insertar, actualizar y eliminar
registros de datos en la base de datos.

Un bloque de datos automáticamente incluye una funcionalidad para apoyar

estas interacciones con la tabla o vista a la que corresponda el bloque.

3.3.2 Lógica de aplicaciones en Oracle Forms y Oracle Reports

Oracle Forms y Oracle Reports dispone de elementos para el manejo de la
lógica de las aplicaciones, tales como Unidades de Programa o Program Units,
bibliotecas o libraries y triggers de base de datos. Ésta lógica puede distribuirse
tanto en el cliente como en el servidor de PL/SQL. Ver Figura 10 y Figura 11.

Figura 10. Ejemplo de Lógica en una Forma de Oracle Forms6i

23
3.4 Arquitectura de las aplicaciones Oracle Forms
Para Oracle Forms6i, la implementación es basada en una arquitectura
cliente/servidor, como se muestra en la Figura 11, el Forms Server Runtime
Engine y toda la lógica de la aplicación está á instalada en el computador del
usuario. Toda la interfaz de usuario y el procesamiento de triggers ocurren en el
cliente, excepto para los triggers y la lógica de algunas aplicaciones que podría
estar incluida del lado del servidor de base de datos (19).

Figura 11. Forms Server basado

o en una arquitectura cliente/servidor

Posteriormente, Oracle lanza una ostensible mejora en la arquitectura de su

producto Oracle Forms, en el que iincluye
ncluye el componente que desacopla gran
parte de la lógica de las aplicaciones. Éste producto llamado Oracle Forms 10g
presenta una arquitectura de tres niveles en las que se distribuye toda la
aplicación: Cliente, Servidor de Aplicaciones y Servidor de Base
Ba de Datos. El
Servidor de Aplicaciones, ahora es el componente responsable de ejecutar toda
la lógica de las aplicaciones contenidas en los Program Units, triggers, librerías
además de contener el Forms Runtime Engine para el procesamiento. Ver
Figura 12.

24
Figura 12. Arquitectura de Oracle Forms 10g en adelante

A pesar del esfuerzo de Oracle por mejorar características de rendimiento,

escalabilidad y balanceos de carga en las aplicaciones Oracle Forms
(actualmente con Release de Oracle Forms 11g), persiste actualmente la forma
de desarrollar las aplicaciones Oracle Forms las cuales son construidas como un
“bulto” homogenizado de lógica de negocio e Interfaz de usuario (UI) (20).

Éste nivel de acoplamiento con el que han sido desarrolladas muchas de las
aplicaciones de las organizaciones, en el que la lógica de negocio convive con la
presentación hace que el costo por mantenerlas sea cada vez mayor; logrando
que en un punto sean analizadas con detenimiento para evaluarlas en el
contexto tecnológico actual y de su valor al negocio para así darles el
tratamiento adecuado en pro de los objetivos de las empresas.

3.5 Aplicaciones Oracle Forms como aplicaciones

legadas
Para hablar de las aplicaciones Oracle Forms6i como aplicaciones legadas se
debe referir primero a la documentación del soporte del producto Oracle Forms
directamente con Oracle, quienes al respecto presentan las siguientes fechas
relevantes de soporte correctivo y soporte extendido. Ver Tabla 3.

25
Tabla 3 Fechas relevantes de Soporte
Producto Fin de Soporte de Fin de Soporte
Corrección de Errores Extendido
Oracle Forms, Reports y Designer 31/01/2005 31/01/2008
6i
Oracle9i Developer Suite (9.0.2) Igual que Oracle9i Application Server v9.0.2
01/07/2005 01/07/2008
Oracle9i Developer Suite y Igual que Oracle9i Application Server 10g (9.0.4)
Application Server 10g (9.0.4) 31/12/2006 31/12/2009
Oracle9i Developer Suite y Igual que Oracle Application Server.
Application Server 10g (10.1.2)
Phase 2 31/12/2011
Futuros releases de Oracle Igual que Oracle Application Server.
Developer Suite y Application
Server

Claramente se observa para los productos relacionados en éste estudio, Oracle

Forms, Reports y Designer 6i, la fecha de soporte extendido caducó el 31 de
enero de 2008, lo cual deja ver la intencionalidad de Oracle en deprecar éstos
productos posiblemente por verlos como productos que ofrecen cierta limitante
al dar valor agregado a los negocios, su dificultad de evolución y adaptación a
nuevos entornos tecnológicos.

Figura 13. Ciclo de Vida de Oracle Forms

Tal y como se describió en el capítulo 2.1, relacionado los sistemas legados, no

por el simple hecho de que una aplicación haya sido desarrollada con una
tecnología deprecada, tal como Oracle Forms6i, debiera ser considerada como

26
aplicación legada; no obstante el mensaje de Oracle por descontinuar el uso de
d
éstas tecnologías. Ver Figura 13.

Dependiendo del valor agregado que tenga una aplicación desarrollada con
tecnología Oracle Forms para el negocio y la necesidad de integración con otras
aplicaciones con su respectivo riego,
riego se puede considerar su modernización o
no. Se puede tomar como referencia la relación de las variables que se
muestran en la Figura 14. Se consideran aspectos necesarios para garantizar
su continuidad y disponibilidad durante el tiempo (aspectos que incluyen factores
como la disponibilidad de soporte en hardware y software), y la determinación de
continuar con la operación de los procesos soportados en el sistema, permite
tomar una decisión sobre la estrategia adecuada para evolucionar el sistema (2).

Figura 14. Aspectos considerados para valoración de un sistema

Al respecto, Oracle considera a sus productos como activos en evolución para

los cuales ha seguido la siguiente ruta evol
evolutiva
utiva específicamente para la línea de
Oracle Forms:

Ésta figura muestra la evolución que han tenido los productos desde sus inicios
como aplicaciones en modo bloque, pasando a aplicaciones en modo carácter,
mejorando sus capacidades en su momento con con la innovadora arquitectura

27
cliente-servidor de Oracle Forms y actualmente con la tendencia de evolución de
las WebForms a una arquitectura orientada a servicios SOA.

4 ARQUITECTURA DE SOFTWARE
En el marco de desarrollo del presente trabajo, serán consideradas dos
arquitecturas de software como arquitecturas objetivo de una migración de las
aplicaciones Oracle Forms. Antes de ahondar en éstas dos alternativas se
describe el concepto de arquitectura de software definido por Bass de la
siguiente manera (21):

"La arquitectura de software de un sistema o programa de computación es la

estructura o estructuras del sistema, la cual comprende los componentes del
software, las propiedades de esos componentes visibles externamente, y las
relaciones entre ellos".

La arquitectura de un sistema software puede basarse en un modelo o estilo

arquitectónico particular (14). Garlan y Shaw son citados por Sommerville para
definir un estilo arquitectónico como: “un patrón de organización de un sistema
tal como una organización cliente-servidor o una arquitectura por capas”.

Los conceptos de capa y de nivel se usan indistintamente. Sin embargo, un

punto de vista bastante común es que en verdad hay una diferencia, y que una
capa es un mecanismo lógico para la estructuración de los elementos que
componen la solución de software, mientras que un nivel es un mecanismo de
estructuración física de la infraestructura del sistema (22).

A continuación se presenta dos de las arquitecturas más apropiadas que

soportan un adecuado nivel de descomposición de las unidades del sistema
software que una aplicación Oracle Forms6i contiene.

4.1 Arquitectura multinivel

En la ingeniería de software, la arquitectura de varios niveles (a menudo
denominado como la arquitectura n-tier) es una arquitectura cliente-servidor en
el que la presentación, el procesamiento de la solicitud, y la gestión de datos
son, lógicamente, procesos separados. Por ejemplo, una aplicación que utiliza
middleware para servicios de datos de las solicitudes entre un usuario y una
base de datos emplea la arquitectura de varios niveles. El uso más extendido de
la arquitectura de varios niveles es la arquitectura de tres niveles.

La arquitectura de una aplicación de N-tier proporciona un modelo para que los

desarrolladores desarrollen una aplicación flexible y reutilizable. Al romper una
aplicación en niveles, los desarrolladores sólo tienen que modificar o agregar

28
una capa específica, en lugar de tener que reescribir de nuevo toda la
aplicación. Debe haber un nivel de presentación, un nivel de negocio o acceso
de datos, y un nivel de datos (22).

4.1.1 Arquitectura multinivel de una aplicación web

Las aplicaciones Web actualmente poseen un nivel de desacoplamiento de sus

componentes gracias en medida a la maduración de marcos de trabajo que
permiten el despliegue de los mismos mediante las ventajas de la computación
distribuida. Los datos y la lógica de negocios pueden compartirse entre clientes
tanto automatizados como GUI. Las únicas diferencias estarán dadas en la
naturaleza del cliente y la capa Presentation (presentación) del nivel medio.
Además, la separación entre la lógica de negocios y el acceso a los datos
posibilita la independencia de las bases de datos y proporciona la capacidad de
complementación que permite el uso de diversos tipos de almacenamiento de
datos (23).

Figura 15. Diagrama de un entorno de aplicación Web multinivel

El funcionamiento de los componentes de una arquitectura multinivel es

explicado por Bruce Sun, en su artículo de developerWorks (23), de la siguiente
manera:

29
El cliente del navegador Web de la Figura 15 actúa como un front-end GUI al
brindar funciones de visualización usando HTML generado por el Browser
Request Handler en la capa Presentation. El Browser Requester Handler puede
implementarse usando modelos MVC (algunos ejemplos Java son: JSF, Struts o
Spring). Éste acepta la solicitud del navegador, solicita el servicio a la capa
Business Logic, genera la presentación y le responde al navegador. La
presentación debe mostrarse al usuario mediante el navegador y no contendrá
únicamente el contenido, sino también los atributos de visualización como HTML
y CSS.

Las reglas de negocios se centralizan en la capa Business Logic, la cual cumple

la función de intermediario en el intercambio de datos entre la capa Presentation
y la capa Data Access. Los datos se proporcionan a la capa Presentation como
objetos de dominio u objetos de valor. Desacoplar el Browser Request Handler y
el Resource Request Handler de la capa Business Logic ayuda a facilitar la
reutilización de códigos y conlleva a una arquitectura flexible y extensible.
Además, a medida que van surgiendo nuevos frameworks REST y MVC, se
simplifica cada vez más la implementación sin que sea necesario reescribir la
capa Business Logic.

La capa Data Access brinda el nivel de almacenamiento de datos a la interfaz y

puede implementarse usando el patrón de diseño DAO o bien soluciones de
mapeo relacional de objetos como Hibernate, OJB o iBATIS. Otra alternativa es
implementar los componentes de la capa Business y la capa Data Access como
componentes EJB con soporte de un contenedor EJB que facilite el ciclo de vida
de los componentes y gestione la persistencia, las transacciones y las
asignaciones de recursos. Sin embargo, esta opción requiere de un servidor de
aplicaciones conforme a Java EE como, por ejemplo, JBoss y no funcionaría con
Tomcat. La gran ventaja de esta capa está dada en la separación del código de
acceso a datos de la lógica de negocios la cual permite el uso de tecnologías de
almacenamiento de datos dispares. La capa Data Access también puede actuar
como un punto de integración para la vinculación con otros sistemas, incluso en
casos de clientes de otros servicios Web.

El nivel de almacenamiento de datos abarca sistemas de bases de datos,

servidores LDAP, sistemas de archivos y sistemas de información empresarial
como sistemas legado, sistemas de procesamiento de transacciones y sistemas
de planificación de recursos empresariales.

Sun, concluye la descripción del anterior “estilo” arquitectónico de sistemas en

red como una arquitectura multinivel tanto para servicios Web como para
aplicaciones Web dinámicas que conlleva a la reutilización, simpleza,
extensibilidad y a una clara separación de las responsabilidades de los
componentes.

30
4.2 Arquitectura multicapa
El modelo de capas de una arquitectura organiza al sistema en capas, cada una
de las cuales proporciona un conjunto de servicios (14). Una arquitectura
multicapa particiona todo el sistema en distintas unidades funcionales: cliente,
presentación, lógica de negocio e integración. Esto asegura una división clara de
responsabilidades y hace que el sistema sea más mantenible y extensible (24).

La capa del cliente es donde se consumen y presentan los modelos de datos.

Para una aplicación Web, la capa cliente normalmente es un navegador web.
Los clientes pequeños basados-en-navegador no contienen lógica de
presentación; se trata en la capa de presentación.

La capa de presentación expone los servicios de la capa de lógica-de-negocio a

los usuarios. Sabe cómo procesar una petición de cliente, cómo interactuar con
la capa de lógica-de-negocio, y cómo seleccionar la siguiente vista a mostrar.

La capa de la lógica-de-negocio contiene los objetos y servicios de negocio de la

aplicación. Recibe peticiones de la capa de presentación, procesa la lógica de
negocio basada en las peticiones, y media en los accesos a los recursos de la
capa EIS. Los componentes de la capa de lógica-de-negocio se benefician de la
mayoría de los servicios a nivel de sistema como el control de seguridad, de
transacciones y de recursos.

La capa de integración es el puente entre la capa de lógica-de-negocio y la capa

EIS. Encapsula la lógica para interactuar con la capa EIS. Algunas veces a la
combinación de las capas de integración y de lógica-de-negocio se le conoce
como capa central.
Los datos de la aplicación persisten en la capa EIs. Contiene bases de datos
relacionales, bases de datos orientadas a objetos, y sistemas antiguos.

4.2.1 Patrón de diseño Model-View-Controller (MVC)

MVC es un patrón de diseño que considera dividir una aplicación en tres

módulos claramente identificables y con funcionalidad bien definida: El Modelo,
las Vistas y el Controlador.

MVC es el patrón de diseño arquitectural que separa los conceptos de diseño, y

por lo tanto decrementa la duplicación de código, el centralizamiento del control
y hace que la aplicación sea más extensible.

31
 Figura 16. Relación entre los módulos del patrón MVC

Sin embargo, una de las motivaciones de utilizar el patrón MVC es hacer que el
modelo sea independiente de la vista (25). Si el modelo tuvo que notificar a las
vistas de los cambios, se volvería a introducir la dependencia que se está
buscando evitar. Afortunadamente, el patrón observador proporciona un
mecanismo para alertar a otros objetos de los cambios de estado, sin introducir
en ellas las dependencias. Las vistas individuales implementan la interface
Observer y se registra en el modelo. El modelo rastrea de la lista de todos los
observadores que se suscriben a los cambios. Cuando el modelo cambia, el
modelo se repite a través de todos los observadores registrados y les notifica del
cambio. Este enfoque es a menudo llamado "publicación-suscripción". El modelo
no requiere información específica sobre la vista. De hecho, en situaciones en
las que el controlador necesita ser informado de los cambios de modelo (por
ejemplo, para activar o desactivar las opciones de menú), todo lo que el
controlador tiene que hacer es implementar la interfaz Observer y suscribirse a
los cambios del modelo.

Figura 17. Uso del patrón observador para desacoplar el modelo activo de la vista

En situaciones donde hay muchas vistas, tiene sentido para definir varias
interfaces, cada una de las cuales describe un tipo específico de cambio de

32
modelo. Cada vista puede suscribirse únicamente a los tipos de cambios que
son relevantes a la vista.

4.3 Comparación de la arquitectura multinivel con MVC

A primera vista, los tres niveles de la arquitectura multinivel descrita
anteriormente puede parecer similar al concepto de modelo-vista-controlador
(MVC), sin embargo, topológicamente son diferentes. Una regla fundamental en
una arquitectura de tres niveles es que el nivel de cliente no se comunica
directamente con el nivel de datos, en un modelo de tres niveles, todas las
comunicaciones deben pasar por el nivel de middleware. Conceptualmente la
arquitectura de tres niveles es lineal. Sin embargo, la arquitectura MVC es
triangular: la vista envía actualizaciones al controlador, el controlador actualiza el
modelo y la vista se actualiza directamente desde el modelo.

33
5 GUIA DE MIGRACIÓN DE SISTEMAS LEGADOS
Oracle Forms6i HACIA UNA ARQUITECTURA
MULTICAPA
En el presente documento de tesis, se incluyeron algunas definiciones que se
consideran complemento del marco teórico tales como las pautas de migración
de sistemas legados y el concepto de modernización, los cuales se mencionan
dentro de este capítulo y no como antecesores al soporte teórico de la
investigación.

INTRODUCCION

Los sistemas legados son el resultado de muchos años de experiencia

combinada, el desarrollo y la personalización además de la acogida de los
procesos de negocio básicos que se siguen para proporcionar una ventaja
competitiva. Esto, combinado con la fiabilidad y la estabilidad de estos sistemas
que en la mayoría de casos son de escaso valor y de alto riesgo para la
organización los hace candidatos de un plan de sustitución. El reemplazo y la
reescritura son necesarios en ciertos casos, pero si la aplicación legada
existente satisface las actuales necesidades de negocio, lo más probable es que
este legado pueda ser transformado efectivamente para satisfacer las
necesidades de la empresa en el futuro (11).

La Guía de Migración por sí sola, no constituye un activo para un proyecto de

reingeniería, el cual requiere mínimamente un proceso que lo gestione y un
lineamiento claro a seguir dado por la metodología que se adapte a las
características del proyecto.
La ruta o camino de migración de preferencia que se desee tomar es
influenciada por el lugar que se desee estar. Si la motivación para considerar
una migración a una tecnología diferente, es explotar las características y el
poder de ese objetivo, entonces se debe estar dispuesto a hacer grandes
cambios de arquitectura.

Bajo esta perspectiva, la presente guía se constituye en una herramienta de

orientación en la elaboración de planes de reingeniería de aplicaciones legadas
Oracle Forms6i, teniendo en cuenta los riesgos de los proyectos e incluyendo el
punto de vista específico de la tecnología a migrar con su arquitectura objetivo.

CONTENIDO DE LA GUÍA
La guía se dirige a dos grupos distintos. Un grupo se compone de los
responsables a cargo de la planificación e implementación de las estrategias y
proyectos de las TI. El segundo grupo lo forman los Administradores TI en las
organizaciones que gestionan proyectos de desarrollo o migración de

34
aplicaciones que estarán ciertamente interesadas en descripciones técnicas. A
continuación se bosqueja el contenido de cada sección.

En la sección Aspectos claves de la guía de migración y

recomendaciones se proporcionan detalles relevantes para la toma de
decisiones en el marco de un proyecto de reingeniería, además de
abordar temas clave como condiciones y factores a considerar para lograr
una implantación exitosa de los proyectos basados en las
recomendaciones del proveedor de la tecnología del sistema legado.

En las secciones Descripción técnica de las fases de migración y la

sección Establecimiento de un proyecto de reingeniería se consignan las
explicaciones técnicas referidas, de modo que los responsables puedan
obtener una descripción de los diversos componentes de migración. Los
administradores de TI, pueden encontrar en éstas secciones, una fuente
importante de información relacionada con la estrategia de migración
escogida para los sistemas de información legados Oracle Forms6i,
además de tratar temas como:
• Viabilidades técnicas y/o posibles problemas
• Solución o resolución de problemas
• Importancia técnica en el esfuerzo de migración de un componente
• Funcionalidades que se mantienen en la migración y/o restricciones

5.1 Aspectos claves de la guía de migración y

recomendaciones
Todas las organizaciones quieren conseguir el mayor valor de negocio posible
de sus inversiones existentes en infraestructura de TI y aplicaciones software.
Pero en muchos casos, estos sistemas se han mantenido durante muchos años
- es decir, se trata de "sistemas legados" que son importantes para la empresa,
pero a menudo son difíciles de entender y mantener. Por razones
presupuestales, el re-desarrollo de estos sistemas desde cero puede ser una
mala opción.

A menudo, estos sistemas no solo han superado la vida útil de sus componentes
software sino también de su hardware por lo que se hacen costosos de
mantener. La solución es la migración del sistema legado a una nueva
plataforma (hardware o software), conservando gran parte del software
existente, por supuesto si el valor del sistema para el negocio es alto. Para el
caso de este texto, una aplicación desarrollada para un entorno cliente-servidor
con tecnología Oracle Forms6i actualmente se abren varias posibilidades de
migración, las cuales implican adicionar un nuevo comportamiento de dominio
específico y la adaptación del sistema legado a una plataforma tecnológica
diferente. La migración tiene un valor específico del dominio menos tangible,

35
pero de no hacerla de una manera oportuna y eficiente puede traer perjuicios
para la organización.

5.1.1 Definiciones importantes y recomendaciones generales de

migración

Un punto de vista general sobre guías de migración debe considerar aspectos

de gestión y control tanto como los aspectos técnicos. Al respecto, el SEI
propone una serie de guías de migración de sistemas legados (21), en las que
se consideran los siguientes aspectos más relevantes12:

a) Identificar y desarrollar una estrategia global con metas alcanzables y

medibles para el proyecto de reingeniería.

Desarrollar planes de contingencia para la instalación de nuevos sistemas.

 Mantener las operaciones paralelas e instalaciones independientes de

pruebas para sistemas grandes y complejos.

 Cuando hay integración de entornos de ingeniería de software, comprobar

que la integración entre la toda la gama de herramientas ha sido probada,
y que es apropiado para la escala del proyecto.

 Gestionar un cambio significativo a un nuevo sistema o mejoras

importantes al mismo, como un proyecto con su propia línea de
responsabilidad, su propio presupuesto y recursos, y no como un
proyecto paralelo que separadamente contribuyen en incremento del
tiempo.

b) Si una nueva tecnología se utiliza para un proyecto, proporcionar una

formación adecuada, tanto en el contenido técnico y la motivación para
el cambio

Los siguientes son ejemplos de orientación relacionados con la capacitación:

 En la introducción de normas generales, tales como la ISO/IEC 15504

(Modelo para la evaluación y mejora de procesos), ISO/IEC 12207
(ciclo de vida de desarrollo) o el estándar IEEE 1219 (Mantenimiento
de Software), se debe asegurar que los empleados entiendan el
significado pleno y las limitaciones del cambio, y que esta
interpretación va más allá de la capacidad de utilizar palabras de
moda.

12
Bergey J, Smith D, Weiderman N. DoD Legacy System Migration Guidelines. Software
Engineering Institute. Pittsburgh. 1999.

36
  Cuando se apliquen nuevas tecnologías con personas mayores,
asegurar que el plan de reconversión es integral, y que incluye
personal adicional si es necesario.

 Estar preparado para hacer frente a situaciones disfuncionales, por

ejemplo, cuando una cultura organizacional se ha acostumbrado a la
ineficiencia, una exigencia de mayor eficiencia se percibe como una
amenaza para la estabilidad laboral.

c) Establecer y mantener el control de gestión de configuración del

sistema legado

Los siguientes son los tipos específicos de orientación para mantener el

sistema legado bajo control:

 Cuidadoso seguimiento de los datos históricos y mantener los

parámetros precisos para que las estimaciones sean precisas, más
que supuestas.

 Desarrollar un proceso documentado para la gestión, seguimiento y

asignar prioridades a las solicitudes de cambio como un requisito
previo para realizar cualquier tipo de esfuerzo de reingeniería.

d) Hacer de la arquitectura de software una consideración primaria de

reingeniería

Las siguientes son las áreas específicas de la guía de arquitectura:

 Asegurar que haya un entendimiento común y la representación de la

arquitectura entre todos los interesados.

 Asegurar la inclusión de evaluaciones de arquitectura de software

como puntos de control formal a principios del sistema de la fase de
desarrollo, cuando las decisiones críticas de diseño se está realizando
y la arquitectura sigue siendo susceptible a cambio para minimizar el
riesgo en adelante. Esto puede hacerse incluso si el trabajo está
siendo realizado bajo contrato.

e) Debe haber un proceso de reingeniería distinto y separado

Se debe separar el proceso de reingeniería del proceso de desarrollo, a

continuación unas consideraciones al respecto:

 Formular un proceso de reingeniería que es único a su proyecto. No

utilice un proceso de ciclo de vida genérico.

37
  Involucrar a las partes interesadas en la formulación del proceso de
reingeniería.

 Asegurar que las métricas del proceso de reingeniería están acorde a

los objetivos y metas de la organización, y no sólo son datos
generados que se registran y olvidan.

5.1.2 Recomendaciones Específicas de migración Oracle

Forms6i
Con las pautas anteriores, la “Guía de migración de Sistemas Legados Oracle
Forms6i” que se pretende con el presente trabajo, se debe complementar con el
punto de vista de la propia firma propietaria de la tecnología en cuanto a las
posibilidades de evolución de la misma. Al respecto, Oracle recomienda la
“Modernización” (26), concepto de IT que se basa en un requisito fundamental
de hacer negocios en el siglo XXI: maximizar la eficiencia al tiempo que aumenta
la ventaja competitiva.

“La modernización es el proceso de evolución de las tecnologías restrictivas,

tecnologías legadas a nuevas tecnologías basadas en estándares abiertos,
mientras que se conserva la lógica de negocio y los datos de los sistemas
legados.”

¿Por qué se debe considerar la Modernización?

Oracle recomienda una variedad de enfoques de modernización de TI13 como
apoyo para la compleja variedad de desafíos en la modernización de sistemas
legados. Estos enfoques incluyen:

• Sustitución de las aplicaciones legadas existentes con empaquetado,

Aplicaciones Comerciales disponibles en el Mercado (COTS).

• Re-arquitectura de aplicaciones legadas.

• Habilita la arquitectura orientada a servicios (SOA).

• Automatización de la migración de los lenguajes legados basados en

lenguajes de 4ta generación y otros lenguajes legados.

• Reubica la lógica de la aplicación y los datos, intactos, a una plataforma

más abierta, rentable, y ágil.

13
An Executive Guide to Oracle Modernization. Enabling Strategic Business Transformation.
Oracle.com.

38
Una combinación de estos enfoques normalmente se requiere para proporcionar
una solución completa a los problemas de negocios.

Oracle también recomienda (27) a los clientes de Forms, Reports y Designer que
sigan un camino similar al que Oracle realizó con su E-Business Suite:
• Migrar a tecnología de Internet.
• Interoperar y hacer coexistir estas aplicaciones con nuevas aplicaciones
Java Enterprise Edition usando Oracle WebLogic Application Server.
• Para clientes con nuevos requerimientos la plataforma Java Enterprise
Edition proporciona un nuevo y completo conjunto de funcionalidades
anteriormente no disponible para el desarrollador. Oracle Jdeveloper con
ADF es la herramienta más adecuada para los clientes de Forms, Reports
y Designer, debido a su similar modelo de desarrollo. Sin embargo, dadas
las diferencias en arquitectura entre Java Enterprise Edition y Forms,
Oracle no planea ofrecer una solución de migración que migre
aplicaciones construidas con estas herramientas a JEE.

5.2 Descripción técnica de las fases de migración

Tomando en cuenta las recomendaciones expuestas en el apartado anterior 5.1,
antes de definir fases de migración se debe procurar establecer un proyecto
marco de migración en donde se valore en primera instancia el sistema legado
que se va a migrar y, posteriormente, ajustar el proyecto bajo las características
de la reingeniería.

5.2.1 Consideraciones de la valoración del sistema legado

Un sistema legado ha sido definido como un sistema que "... de manera
significativa se resiste a la modificación y evolución para satisfacer las
necesidades de nuevos y constantes cambios en los requerimientos del
negocio." Por lo general, implica que el entorno en el que convive es igualmente
heterogéneo. Ver Figura 18.

39
 Figura 18 . Una común Infraestructura de TI legada

Uno de los retos de TI que puede ser observado del anterior diagrama es que la
mayoría de las aplicaciones se comunican directamente entre sí. Esta
dependencia puede convertirse en un verdadero problema cuando una
aplicación tiene que ser modificada o eliminada. Cualquier modificación puede
llevar a la actualización de cada línea de comunicación a su manera única. Por
lo tanto, estos cambios pueden llegar a ser un esfuerzo costoso. Esta situación
se denomina alto acoplamiento entre las aplicaciones y se está convirtiendo en
un verdadero dolor de cabeza para algunas empresas, pues estos entornos
tecnológicos promueven el deterioro de las aplicaciones convirtiéndolas en
legadas.

Características a valorar del sistema legado Oracle Forms6i

En éste punto se supone que el sistema legado representa un importante activo

para la organización y que realmente vale la pena volver a usar en un nuevo
entorno tecnológico. Así que el valor del actual activo debe ser valorado:

 ¿El código fuente es de valor?

 ¿Qué tanta lógica está bien estructurada en triggers y librerias?
 ¿El diseño de sus componentes es de valor?
 ¿Cumple a cabalidad los requisitos del negocio?

Desafortunadamente, lo más difícil del análisis del legado es captar en su

totalidad su funcionalidad, debido a que generalmente la documentación
asociada del software no existe o es obsoleta, y el diseño requiere recuperarse
aplicando ingeniería inversa, a veces desde el propio código. Al establecer el

40
punto inicial del proyecto de migración, es realmente muy valorado contar con la
existencia del activo legado, ya que se establece un punto de comparación y
uso. Particularmente, el sistema legado le permitirá identificar más fácilmente:

 Requisitos y reglas de negocio

 ¿Qué es de gran importancia arquitectónica?
 Casos de uso básicos
 Establecer prioridades de los usuarios, deseos y comportamientos

El único peligro de que el sistema legado pueda ser un obstáculo, es que sea
valorado de manera errónea o de manera incompleta.

5.3 Establecimiento de un proyecto de reingeniería

El proyecto de reingeniería, se puede descomponer en dos sub-proyectos:
ingeniería inversa (representaciones de la construcción del código real) e
ingeniería hacia adelante (de reestructuración y / o reconstrucción de
algunas partes del código). En particular, una actividad importante en la
ingeniería inversa es recuperar la arquitectura del sistema, por lo que se hace
necesario identificar ciertas garantías durante todas las etapas del proyecto,
para que sirvan de insumo al proyecto de reconstrucción.

5.3.1 Establecimiento de la metodología

Los proyectos de reingeniería al igual que los de ingeniería deben estar
gestionados por un proceso de ingeniería que garanticen:

 Mitigación del riesgo

 Desarrollo iterativo
 Valoración del progreso basado en evidencia concreta y medible
 Colaboración de equipos
 Verificación continua de la calidad
 Administración del alcance del proyecto
 Producir solo los artefactos que son requeridos.

Por lo anterior, la metodología sugerida más acorde y que en sus principios

fundamentales se encuentran los puntos mencionados, es RUP (Rational
Unified Process). Los anteriores principios son genéricos a cualquier proyecto
de desarrollo de software, por lo que hace que la plantilla básica del ciclo de vida
RUP, con sus cuatro fases de la Concepción, Elaboración, Construcción y
Transición sea plenamente aplicable a un proyecto de reingeniería de un
sistema legado. Esto a su vez hace que la mayor parte de las actividades de la
Administración de Proyectos de RUP también sean plenamente aplicables. El
hecho de que se trate de un sistema legado, no sugiere razón alguna para no
tener un Documento de Visión, que describe qué es lo que queremos lograr, un

41
Plan de Proyecto, que muestra los principales hitos y lo que se desea lograr, tal
vez iteraciones y sus objetivos específicos, y una Lista de Riesgos. También se
necesita un Caso de Negocio, para poder hablar sobre los beneficios de hacer el
proyecto y el enfoque que tomará. Este Caso de Negocio se basará en una
estimación de los costes: el personal y otros requisitos (herramientas,
middleware, formación), que, a su vez, dependerá de la magnitud del trabajo que
esté por hacer. A medida que avance hacia la fase de transición, se necesita un
Plan de Implementación, que muestra cómo el nuevo sistema se implementará,
en sustitución del antiguo.

5.3.2 Sub-proyecto de ingeniería inversa

Usualmente la documentación de las aplicaciones legadas, así como también las

aplicaciones legadas Oracle Forms6i, no la tienen y si la tienen es una
documentación escasa o poco fiable. Por lo tanto el objetivo del sub-proyecto de
ingeniería inversa será el de reconstruir con UML algunos modelos que en
conjunto proporcionen la vista arquitectónica del sistema legado Oracle Forms6i
para identificarlos posteriormente en el plan de migración.

Como el objetivo de ésta guía no es detallar el plan del proyecto de ingeniería

inversa, a continuación se presenta el resumen de las actividades propuestas
(28) para el manejo del proyecto de ingeniería inversa con la metodología RUP:

A. Valorar el alcance del proyecto de reingeniería.

B. Construcción de los modelos abstractos.
C. Recuperar la arquitectura del software legado

42
Figura 19. Pasos claves para el mapeo de las disciplinas y fases de RUP14

Paso 1. Valorar el alcance del proyecto de reingeniería.

A continuación se mencionan algunas de las tareas de éste paso que se
recomiendan:

• Establecer el alcance del negocio y los atributos de calidad deseados del

sistema legado objeto de reingeniería.
• Desarrollar el documento de Visión del Proyecto: acá estará definida la
arquitectura objetivo de la migración, para nuestro caso una arquitectura
multicapa JEE con ADF.
• Encontrar actores y Casos de Uso.
• Identificar y valorar el riesgo
• Desarrollo de casos de negocio.

14
Philippe Dugerdil. Using RUP to reverse-engineer a legacy system. developerWorks. 2006.

43
Paso 2. Construcción de los modelos abstractos.
Presunción: Se tiene a la mano el código fuente del sistema legado Oracle
Forms6i, que servirá de punto de partida para la construcción de los modelos
abstractos.

En éste segundo paso, se involucran los roles del diseñador de negocio y base
de datos, junto con el analista de sistemas, quienes tendrán que ejecutar las
tareas de la fase de Concepción y Elaboración. En la Figura 20 se muestra la
responsabilidad del diseñador de negocio en la ejecución de las tareas de
detallar un caso de uso de negocio, entidad de negocio y encontrar trabajadores
y entidades de negocio.

Figura 20. Documentar el proceso de negocio apoyado y el modelo de dominio

Siguiendo con las tareas para encontrar el modelo, se deben analizar las tablas
de la base de datos actual y registrarla como producto de trabajo en un Modelo
de Datos. Este es el resultado de una nueva tarea: Análisis de la Base de Datos,
la cual no hace parte del estándar RUP, pero se acerca a la parte de la tarea de
ingeniería inversa en la disciplina de Diseño de la Base de Datos. Ver Figura 21.

Figura 21. Analizar la arquitectura de la actual base de datos

44
A continuación, se presenta un resumen de la relación de roles y tareas de los
pasos que involucran la construcción de modelos abstractos del sistema legado.

Tabla 4. Tareas para cada rol involucrado en la construcción de modelos

abstractos
Rol Tarea
Detallar un Caso de Uso de Negocio
Diseñador de Procesos de Negocio Encontrar Trabajadores y Entidades de Negocio
Detallar una Entidad de Negocio
Diseñador de Base de Datos Análisis de la Base de Datos
Analista de Sistemas Encontrar Actores y Casos de Uso
Arquitecto de Software Prioriza los Casos de Uso
Administrador del Proyecto Valorar la Iteración
Especificador de Requerimientos Detalla el Caso de Uso

Como resultado final de éste paso, se espera contar como producto de trabajo
una estructura abstracta del sistema legado: el Modelo de Análisis de Casos de
Uso y sus enlaces de trazabilidad para otros elementos del modelo.

Paso 3. Recuperar la arquitectura del sistema software legado.

En éste último paso de la ingeniería inversa, la idea se centra en transformar el
Modelo de Análisis de Casos de Uso del paso anterior y por medio de
heurísticas lograr llegar al Documento de Arquitectura de Software.
El resumen del Paso 3, se muestra en la Tabla 5 incluyendo la relación de las
tareas y los roles quienes las ejecutan.

Tabla 5. Tareas para cada rol involucrado en recuperar la arquitectura del sistema
legado
Rol Tarea
Arquitecto de Software Analizar el Modelo Implementado
Define la Ejecución Detallada
Analista de Casos de Uso
Ejecuta los Casos de Uso
Analiza el Grafo de Llamadas
Analista de Implementación Mapea Funciones para implementar el Modelo
Valida la Arquitectura Hipotética
Arquitecto de Software Reconstruye la Arquitectura de Alto Nivel

Además de los modelos anteriormente generados, uno de los resultados es la

estructura de alto nivel del código fuente de acuerdo con posibles agrupaciones
de tipos de elementos. Por ejemplo, para el caso de Oracle Forms6i, estos
grupos podrían corresponder a los paquetes de la nueva arquitectura multicapa.
Entre las posibles agrupaciones de los elementos de Oracle Forms6i se
tendrían:

45
 • Agrupación de lógica por Program Units
• Agrupación de lógica por Funciones
• Agrupaciones de lógica por Procedimientos
• Agrupaciones de lógica por Triggers
• Agrupaciones de lógica por librerías

Como resultado de este paso, podemos esbozar la estructura de alto nivel del
código de acuerdo a la agrupación que posteriormente se mapearían en las
clases de la nueva plataforma arquitectónica multicapa o en una capa de lógica
en la base de datos según su conveniencia. En éste punto cabe hacer la
anotación que estas agrupaciones han permanecido en constante modificación
durante los años de mantenimiento del sistema. El resultado de esta tarea se
registra en una versión actualizada del Documento de Arquitectura de Software.

5.3.3 Sub-proyecto de desarrollo

Ésta sección agrupa los conceptos de forward engineering para el
establecimiento del proyecto de desarrollo y evolución del sistema legado Oracle
Forms6i, tomando como insumos los productos de trabajo del proyecto de
ingeniería inversa descrito en la sección anterior.

Establecimiento de una Línea Base

Para ir más allá de simplemente aplicar el ciclo de vida propuesto por RUP y el
uso de algunas de las disciplinas de progreso de RUP, es necesario establecer
un punto de partida. Se debe identificar un conjunto mínimo de objetos básicos
que describen el sistema legado (éstos serían los modelos generados de la
sección anterior). Dependiendo del alcance de la evolución, puede que se
necesite más o menos de:

• Requerimientos
• Arquitectura y Diseño
• Pruebas
• Documentación Técnica y de Usuario

Una vez se haya establecido la Línea Base de los artefactos RUP, se puede
proceder con el proyecto del sistema legado como si fuera un ciclo Evolutivo de
RUP.

Directriz del Proyecto de Migración

De acuerdo a las recomendaciones de Oracle, expuestas en la sección 5.1.2,
para lograr una evolución adecuada y probada de las aplicaciones Oracle
Forms6i se definirá la arquitectura objetivo multicapa con el estilo arquitectónico
MVC, desarrollo basado en JEE usando JDeveloper y ADF los cuales permiten
la integración de componentes software sobre el Servidor de Aplicaciones; es
decir un entorno tecnológico favorable a las necesidades del negocio.

46
JEE promete a largo plazo un mantenimiento más fácil para las aplicaciones a
través de estándares abiertos, simplificando la conectividad con productos
externos. Sin embargo, para todos los beneficios que trae, JEE les parece a los
desarrolladores de bases de datos como extremadamente complejo y difícil. Los
desarrolladores de Oracle Forms (en general, desarrolladores 4GL) se utilizan
para una productividad muy alta, la cual no puede ser igualada en el mundo
JEE: es difícil ofrecer a los clientes el mismo tiempo de desarrollo rápido que
estuvieron usando. Este es el por qué Oracle recomienda Application
Development Framework (ADF) como la solución para facilitar el desafío de
implementar patrones de diseño JEE (Model View Controller, MVC) con su
entorno visual y declarativo que minimiza la necesidad de escribir código.

El desafío de la migración
En primera medida, es realmente importante que la ejecución del proyecto de
ingeniería inversa propuesto en la sección anterior de la guía se realice. Esto
garantizaría un entendimiento de la aplicación Forms que necesita ser
reescrita, en toda su complejidad.

En segunda instancia, los miembros del equipo con roles de desarrolladores,

deben tener un profundo conocimiento de la nueva tecnología, y adaptar
todas las funcionalidades en la nueva arquitectura, mientras incluso mejora la
aplicación. Éste segundo desafío es importante porque JEE y Forms son
fundamentalmente diferentes. Además el cambio de la aplicación es exitoso
cuando la nueva versión ofrece una mejor experiencia de usuario y posee unas
capacidades tecnológicas superiores. Después de todo, cuando se invierte en un
proceso de modernización no se querrá un clon de la aplicación legada inicial.

Como tercer desafío, está el establecimiento del proceso de administración

del proyecto para programar y monitorear el progreso durante la transición.
Éste desafío es de gran importancia ya que los proyectos de software basados
en una nueva tecnología a menudo fracasan causado por imprevistos en la
implementación, falta de experiencia, y falta de estándares de implementación.
La gestión del proyecto necesita monitorear continuamente el cronograma de
actividades, limitaciones de calidad y presupuesto aplicado a los esfuerzos por
asegurar un inicio de proyecto exitoso.

Interface de Usuario
Adaptarse a las fortalezas y debilidades del modelo web: para incrementar la
accesibilidad ofrecida por las nuevas interfaces de usuario, las aplicaciones
basadas en navegadores también tienen sus limitaciones. Oracle Forms ofrece
una arquitectura de datos muy eficiente, capaz de consultar y mostrar en un
applet miles de registros a la vez, cientos de campos en una sola página,
acceder a la computadora del cliente y ejecutar comandos de host o acceso a
archivos. Por ello, una aplicación de Forms típica necesita ser rediseñada para
ser capaz de ejecutarse en un navegador sencillo, mostrando conjuntos de

47
pocos registros a la vez, la distribución de los cientos de campos en varias
páginas o reducir el grado en que afectan a la computadora cliente.

Lógica de Negocios
Las aplicaciones de Forms son altamente acopladas, de acuerdo al capítulo
2.1.2, y en una misma unidad de código puede contener lógica de negocio con
acciones como: acciones de interfaz de usuario, validación de datos,
manipulación de datos, etc. Cuando se toma este código para ADF, se requiere
separar la lógica de negocio dentro de sus componentes, y redefinirla de
acuerdo al patrón de diseño MVC, con el fin de crear una verdadera arquitectura
ADF.

Figura 22. Ejemplo de acoplamiento en una aplicación Oracle Forms6i

Las posibles soluciones para manejar la lógica de negocio15 están descritas en

la Tabla 6:

Tabla 6. Aproximaciones posibles para el manejo de la lógica de negocio.

TRATAMIENTO DE LA
VENTAJAS DESVENTAJAS
LÓGICA DE NEGOCIO
Es exitoso cuando se migra Pérdida de la inversión de la lógica de
el 100% de la lógica negocio de Forms6i
manualmente.
Existencia de herramientas El código resultante es secuencial y
que automatizan la procedimental, como PL/SQL, pero
conversión de código ciertamente no es Orientado a Objetos
Oracle Forms a Java como se supone.
A. Traducir el código
El código migrado automáticamente es
entero a Java
difícil de entender y no es reconocido
como un estándar java, lo que conlleva a
más mantenimiento en caso de alguna
mejora.
La lógica que se logre migrar pertenece
más al nivel de la Base de Datos Oracle
que al nivel del cliente

15
Tomado de Professional IT Software Services - PITSS.com

48
 El acceso a datos o el No todos los artefactos son apropiados
código de manipulación de para el uso en la Base de Datos: Código
datos es generalmente más de Interfaz de Usuario como reglas de
B. Dejar el código en
rápido en la Base de Datos. navegación, validación de campos
PL/SQL y colocarlo
Reducción de riesgo pertenecen más al nivel del cliente.
en la Base de
Datos Aumento del desempeño
de la aplicación porque
minimiza el tráfico de la
red.
El código de Interfaz de
C. Una aproximación Usuario en Java, y el código
mixta de manipulación de datos
en la base de datos.

De acuerdo a las opciones expuestas anteriormente, la escogencia de la

aproximación mixta se convierte en la más adecuada para tratar el tema de la
lógica de negocio. Por lo tanto, y continuando con el planteamiento completo del
proyecto de migración se deberán realizar fases de:

 Recuperación del Modelo Arquitectónico del SLOF6i16

 Rediseño de los componentes del SLOF6i
 Refactorización del código del SLOF6i
 Regeneración Arquitectónica del SLOF6i hacia la arquitectura multicapa
JEE+ADF

16
Abreviatura para referir al Sistema Legado Oracle Forms6i, en el marco de éste documento.

49
Figura 23. Arquitectura de Migración de Aplicaciones Forms hacia JEE+ADF

La mayor parte de la lógica de negocio de Oracle Forms está manejando datos.

Ésta lógica naturalmente pertenece a la Base de Datos. Por lo tanto, ésta lógica
de negocio será dispuesta en una Capa de Lógica de Negocio de la Base de
Datos. Ver Figura 23.
Luego de que el código de lógica de negocio sea migrado de las Formas y
Reportes a la base de datos, esta capa podrá ser accesible por cualquier
entorno de interfaz de usuario (ADF, JSP, APEX), incluso ser expuesta como
servicios web. Esto garantiza la posibilidad de evolución o modernización de la
aplicación o componentes individuales mucho más fácil. Una vez se haya
definido la línea base mínimamente con los artefactos requeridos, el proceso de
migración, involucraría las siguientes disciplinas RUP:

Gestión de Requerimientos: el Modelo de Dominio ya casi estará listo por los

productos de trabajo elaborados en el sub-proyecto de ingeniería inversa,
aunque la posibilidad de inclusión de nuevos requerimientos o cambio de los
mismos permanece, se debería estar en constante actualización del documento
del Modelo de Dominio, tal y como se expuso en el aparte del proyecto de
ingeniería inversa.

Análisis y Diseño: En ésta etapa se definirá la estrategia dependiendo de la

complejidad de la aplicación y se deberán Analizar los componentes del SLOF6i,
tales como: FMB, MMB, PLL, OLB, RDF, SQL, etc. que posiblemente tendrán
restricciones para adaptarlo al modelo web. De igual forma, se deberán

50
Identificar componentes obsoletos o redundantes para reducir la aplicación a
puro código funcional identificando objetos redundantes: tablas sin uso, librerías,
unidades de código sin uso o duplicadas, o incluso funcionalidades completas
obsoletas.

Implementación: Dependiendo del alcance de la migración y del estado del

SLOF6i como también del resultado de las anteriores etapas y los productos de
trabajo del sub-proyecto de ingeniería inversa, se prosigue con las siguientes
actividades:
Migrar la Lógica de Negocio a la Base de Datos. En ésta actividad es posible
automatizar la migración del código haciendo uso de herramientas
estandarizadas para éste propósito.
Desarrollo de la Aplicación JEE+ADF elaborando:
 Servicios de Negocio
 Objetos de Acceso a Datos
 Detalle de las capas MVC
 Métodos de Interfaz de Usuario Java
Afinamientos en la fase de Post-Implementación

Despliegue o Implantación: Como la migración involucró una nueva

arquitectura objetivo, se deberá elegir una estrategia para la transición del
SLOF6i al sistema JEE+ADF, ya sea cortando completamente el legado, o
utilizar una estrategia por etapas en pasos incrementales. O, incluso tener
ambos sistemas trabajando en paralelo hasta que el nuevo sistema sea de total
confianza para la organización. Ésta disciplina de RUP para los proyectos de
migración cobra una gran importancia, ya que se deben garantizar la continuidad
de las operaciones normales del negocio, mejoramiento en las habilidades del
personal entre otras, mientras se hacen frente a los posibles problemas que se
presenten.

5.4 Conclusiones de la Guía

Con las descripciones realizadas durante el documento de la guía, se
espera suministrar un punto de partida para que los proyectos de
migración de SLOF6i hacia una arquitectura multicapa aseguren en
mayor valor el alcance de los objetivos.

Con el establecimiento de RUP para la gestión de la evolución del

proyecto de reingeniería, se permite abarcar el ciclo de vida de los sub-
proyectos de ingeniería inversa y el de desarrollo de la nueva aplicación,
permitiendo identificar las actividades relacionadas a la evolución de
proyectos y minimizando los posibles factores que afecten el proyecto de
migración.

51
6 TRABAJO FUTURO
La “Guía para la migración de aplicaciones legadas Oracle Forms6i hacia una
arquitectura multicapa”, deja las puertas abiertas para el desarrollo de nuevos
proyectos:

Debido a que los proyectos de migración tienen un alance definido, es

importante que se establezcan límites bien claros cuando se elaboran los
procesos contractuales de éste tipo de proyectos, para que los esfuerzos
de estas iniciativas no sean subvalorados afectando drásticamente los
costos. Ésta problemática enmarca un nuevo proyecto, consistente en la
elaboración de lineamientos contractuales específicos para los proyectos
de modernización de aplicaciones legadas.

La presente guía deja abierta la posibilidad a que se derive un proyecto

de estimación de costos y eficiencia económica para los proyectos de
evolución y modernización de aplicaciones legadas Oracle Forms6i.

Un trabajo de continuidad que puede tener cabida, sería el del

involucramiento de alguna disciplina de ingeniería que permita el
mejoramiento del proceso de tomas de decisiones de los proyectos de
modernización de aplicaciones, permitiendo valorar, mejorar y alinear los
objetivos de la organización (financieros, organizativos, innovación) con
los objetivos del proyecto de reingeniería.

52
7 CONCLUSIONES

En la actualidad, las organizaciones de TI están bajo creciente presión
para reducir costes y aumentar su capacidad de reacción a las demandas
del negocio, por lo que los sistemas legados se convierten en un
problema para las empresas debido a que en la mayoría de los casos, su
mantenimiento es difícil y costoso además de la falta de respuesta
oportuna a las necesidades actuales de las empresas.

A pesar de que no estaba dentro del alcance del proyecto, se identificó la

necesidad del uso de una metodología evolutiva que permitiera adaptarse
a las características de un proyecto de migración. Es por esto que
algunas de las disciplinas de RUP aplican en mayor o menor medida
dependiendo del tipo de evolución que se escoja y la cantidad de
información del sistema legado objeto de modernización.

Para la transformación del activo software legado Oracle Forms6i en un

activo desplegado un una arquitectura JEE multicapa, se propuso un
proyecto de reingeniería gestionado por las disciplinas de RUP y
desagregado en dos sub-proyectos (de ingeniería inversa y de
desarrollo), con el propósito de aumentar el control de las fases que
involucran la migración de aplicaciones legadas.

Un error frecuente en los proyectos de evolución de aplicaciones es

involucrar muchos cambios a la vez durante la ejecución del proyecto. Por
ejemplo, en un proyecto de migración de un sistema legado a una nueva
plataforma, buscar un cambio en el proceso de desarrollo de software al
mismo tiempo que se quiere una nueva herramienta o IDE de desarrollo
que lo soporte; es decir, involucrar por ejemplo RUP con JDeveloper en
un equipo de trabajo que no esté familiarizado completamente con las
dos. En dado caso, la recomendación es fortalecer el entrenamiento y la
capacitación de la organización en la filosofía de RUP y el cómo la
herramienta lo apoya.

53
BIBLIOGRAFÍA
1. Zoufaly, Federico. Developer.com. Issues and Challenges Facing Legacy
Systems. [Online] 2002. http://www.developer.com/article.phpr/1492531/Issues-
and-Challenges-Facing-Legacy-Systems.htm.
2. Evolución de un sistema legado: mantener o migrar? IT-Liverage. [Online]
http://it-leverage.com/legacy1.aspx.
3. Pedraza García, Gilberto. Evolución e Integración de Aplicaciones Legadas:
Comenzar de Nuevo o Actualizar? Universidad Nacional de Colombia. [Online]
Abril 23-25, 2008. http://pisis.unalmed.edu.co/3CCC/pdf/76.pdf.
4. Leonid, ERLICKH. Integrating Legacy systems using Web Services. [Online]
Agosto 2002.
http://www.bijonline.com/Article.asp?ArticleID=584&DepartmentId=11.
5. Ulrich, William M. Legacy Systems: Transformation Strategies. 2002.
6. William M. Ulrich, Philip Newcomb. Information Systems Transformation
Architecture Driven Modernization. s.l. : Morgan Kaufmann OMG Press, 2010.
7. H. M. Sneed and S. Opferkuch. Training and Certifying Software Maintainers,
pages 113–122. [book auth.] IEEE Computer Society. Athens, Greece :
European Conference on Software Maintenance and Reengineering (CSMR),
2008.
8. Andreas Fuhr, Tassilo Horn, Andreas Winter. Model-Driven Software
Migration. Oldenburg, Koblenz : s.n.
9. The Institute of Electrical and Electronics, Inc. IEEE Standard for Software
Maintenance. IEEE Std 1219-1998. 1998.
10. Marco Torchiano, Massimiliano Di Penta, Filippo Ricca, Andrea De
Lucia, Filippo Lanubile. Software Migration Projects in Italian Industry:
Preliminary Results from a State of the Practice Survey. Research Centre of
Software Technology. [Online]
http://www.rcost.unisannio.it/mdipenta/papers/evol08.pdf.
11. Price, Steven. Oracle Forms to SOA: A Case Study in Modernization. s.l. :
Oracle Corporation, 2008.
12. Rojas, Nolberto Jaimes. Conviviendo con sistemas legados. [Online]
http://paradigma.uniandes.edu.co/index.php?option=com_content&task=view&id
=16&Itemid=1&lang=en&showall=1.
13. Massari A, Mecella. M IL TRATTAMENTO DEI LEGACY SYSTEM. [Online]
http://www.dis.uniroma1.it/~mecella/publications/Miscellanea/legacy_system.pdf.
14. Sommerville, Ian. Ingeniería del Software. Séptima Edición. s.l. : Addison
Wesley.
15. P. Pinheiro, A. Laender, P. Golgher. Stanford Knowledge Systems, AI
Laboratory. A Simulation Model for the Performance Evaluation for Migrating a
Legacy System. [Online] Junio 2010.
http://www.ksl.stanford.edu/people/pp/papers/PinheirodaSilva_CSMR_2001.pdf.
16. Rodriguez, Alfredo, Márquez, Antonio and Toro, Miguel.
ingenieriasimple.com. Gestión de la evolución del software. El eterno problema
de los legacy systems. [Online] Septiembre 2010.
http://www.ingenieriasimple.com/papers/GestionArchivosLegacy.pdf.

54
17. Reengineering Center, Carnegie Mellon University. Pittsburg. Computer
and Information Science. University of Alabama at Birminham. Perspectives on
Legacy System Reengineering. [Online] 1995.
http://www.cis.uab.edu/softcom/GenParse/reengineering.pdf.
18. Oracle Corporation. Oracle Technology Network. Forms Developer Quick
Tour. [Online] http://www.oracle.com/technetwork/developer-tools/forms/fbus-
100997.html.
19. Migrating Legacy Applications to the Web. Oracle Forms Server Release 6i.
[Online]
http://download.oracle.com/docs/cd/A97338_01/doc/forms.6i/a83591/chap08.htm
.
20. Roland, Grant. Migrating Oracle Forms to Fusion: Myth or Magic Bullet? s.l. :
Oracle Tools Direction.
21. John Bergey; Dennis Smith; Nelson Weiderman. DoD Legacy System
Migration Guidelines. SEI. [Online] 1999.
http://www.sei.cmu.edu/reports/99tn013.pdf.
22. Multi-tier Architecture. Wikipedia. [Online] http://en.wikipedia.org/wiki/Multi-
tier_architecture.
23. Sun, Bruce. A multi-tier architecture for building RESTful Web services.
developerWorks. [Online] Junio 2010.
http://www.ibm.com/developerworks/library/wa-aj-multitier/?.
24. Integración de JSF, Spring e Hibernate para crear una Aplicación Web del
Mundo Real. Programacion.com. [Online]
http://www.programacion.com/articulo/integracion_de_jsf-
_spring_e_hibernate_para_crear_una_aplicacion_web_del_mundo_real_307/3.
25. Model-View-Controller. MSDN. [Online] Microsoft.
http://msdn.microsoft.com/en-us/library/ff649643.aspx.
26. Oracle Corporation. An Executive Guide to Oracle Modernization.
27. Diaz, Juan Carlos. Modernización de Forms: De C/S a SOA FMW 11g.
slideshare.net. [Online] http://www.slideshare.net/JC_Diaz_Belmonte/de-forms-a-
oracle-fusion-middleware-3597727?from=share_email.
28. Dugerdi, Philippe. Using RUP to reverse-engineer a legacy system.
developerworks. [Online] Septiembre 2006.
http://www.ibm.com/developerworks/rational/library/sep06/dugerdil/.

55