Elaboración Guía Capa Gómez 2010

ELABORACIN DE UNA GUA PARA LA MIGRACIN DE SISTEMAS
LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTI-CAPA
HUGO ALDEMAR GMEZ MARTNEZ

Cdigo: 1096431
UNIVERSIDAD DE SAN BUENAVENTURA

FACULTAD DE INGENIERA DE SISTEMAS
ESPECIALIZACIN DE PROCESOS PARA EL DESARROLLO DE SOFTWARE
SANTIAGO DE CALI
2010
ELABORACIN DE UNA GUA PARA LA MIGRACIN DE SISTEMAS

LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTI-CAPA
Presentado por:
HUGO ALDEMAR GMEZ MARTNEZ
Cdigo: 1096431
Trabajo de Grado presentado como requisito para optar el ttulo de

Especialista en Procesos para el Desarrollo de Software
Director:
Dr. LUIS MERCHN PAREDES
Ing. De Sistemas
UNIVERSIDAD DE SAN BUENAVENTURA

FACULTAD DE INGENIERA DE SISTEMAS
ESPECIALIZACIN DE PROCESOS PARA EL DESARROLLO DE SOFTWARE
SANTIAGO DE CALI
2010
Nota de aceptacin
______________________________________________________
______________________________________________________
______________________________________________________
_____________________________________________
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 colaboracin
hicieron posible ste logro.
Todas las personas que han confiado en m como estudiante, profesional y amigo.
IV
TITULO: ELABORACIN DE UNA GUA PARA LA MIGRACIN DE SISTEMAS

LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTI-CAPA.*
AUTOR: HUGO ALDEMAR GMEZ MARTNEZ**
PALABRAS CLAVE: SISTEMAS LEGADOS, ORACLE FORMS6i, MIGRACIN,

GUA, ARQUITECTURA, MULTI-CAPA, REINGENIERA, SOFTWARE
DESCRIPCION:
La dinmica actual de los negocios hace que las organizaciones requieran
sistemas de informacin que se adapten al cambio. Por lo tanto, los sistemas
legados se convierten en un obstculo 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 migracin de aplicaciones legadas, especialmente las
desarrolladas bajo la plataforma Oracle Forms6i hacia una arquitectura que
permita desacoplar la lgica de negocio, presentacin y acceso a datos y
aprovechar las potencialidades del Framework de Desarrollo de Aplicaciones
(ADF) de Oracle.
La presente Gua de Migracin se convierte pues, en una herramienta de
orientacin para las organizaciones que desean involucrar la reingeniera en sus
proyectos de evolucin de aplicaciones legadas cliente-servidor hacia
arquitecturas multicapa.
*
**
Trabajo de Grado
Facultad de Ingeniera de Sistemas
Especializacin en Procesos para el Desarrollo del Software
Director: Ing Luis Merchn Paredes
V
TITLE: DEVELOPMENT OF A GUIDE FOR LEGACY SYSTEMS MIGRATION

Oracle Forms6i TOWARDS A MULTI-LAYER ARCHITECTURE.*
AUTHOR: HUGO ALDEMAR GMEZ MARTNEZ**
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 Oracles
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 Ingeniera de Sistemas
Especializacin en Procesos para el Desarrollo del Software
Project Director: Ing Luis Merchn 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 Especficos ....................................................................................... 4
1.3 JUSTIFICACION .................................................................................................... 4
1.4 IMPACTOS ESPERADOS DEL PROYECTO......................................................... 5
1.5 PLAN DE TRABAJO............................................................................................... 5
1.5.1 Fase de Anlisis de Sistemas Legados. .......................................................... 6
1.5.2 Fase de Anlisis de aplicaciones Oracle Forms6i como sistema legado. ........ 6
1.5.3 Fase de Anlisis de arquitecturas objetivo multi-capa candidatas y sus
metodologas de migracin. .......................................................................................... 6
1.5.4 Fase de Diseo de la gua de migracin para aplicaciones Oracle
Forms6i hacia una arquitectura objetivo multicapa. ...................................................... 6
1.5.5 Fase de Generacin de la Gua de migracin.................................................. 6
1.6 CRONOGRMA ....................................................................................................... 7
2 MARCO TERICO / ESTADO DEL ARTE ................................................................ 8
2.1 Sistemas Legados (3) ............................................................................................. 9
2.1.1 Caractersticas que hacen de un sistema, realmente un legado (12) ............ 10
2.1.2 Clasificacin de los sistemas legados (12) (13) ............................................. 11
2.1.3 Opciones para la evolucin de sistemas legados .......................................... 12
3 ARQUITECTURA E HISTORIA DE ORACLE FORMS ............................................ 19
3.1 Qu es Oracle Forms? ....................................................................................... 19
3.2 Cmo funciona Oracle Forms?........................................................................... 21
3.3 Integracin con herramientas CASE de Oracle Designer ..................................... 21
3.3.1 Caractersticas de los Formularios o Formas en Oracle Forms. .................... 21
3.3.2 Lgica 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 aplicacin web ............................................... 29
4.2 Arquitectura multicapa .......................................................................................... 31
4.2.1 Patrn de diseo Model-View-Controller (MVC) ............................................ 31
4.3 Comparacin de la arquitectura multinivel con MVC ............................................ 33
5 GUIA DE MIGRACIN DE SISTEMAS LEGADOS Oracle Forms6i HACIA
UNA ARQUITECTURA MULTICAPA ............................................................................. 34
INTRODUCCION ........................................................................................................ 34
CONTENIDO DE LA GUA ......................................................................................... 34
VII
5.1 Aspectos claves de la gua de migracin y recomendaciones.............................. 35

5.1.1 Definiciones importantes y recomendaciones generales de migracin.......... 36
5.1.2 Recomendaciones Especficas de migracin Oracle Forms6i ....................... 38
Por qu se debe considerar la Modernizacin?........................................................ 38
5.2 Descripcin tcnica de las fases de migracin ..................................................... 39
5.2.1 Consideraciones de la valoracin del sistema legado ................................... 39
5.3 Establecimiento de un proyecto de reingeniera ................................................... 41
5.3.1 Establecimiento de la metodologa ................................................................ 41
5.3.2 Sub-proyecto de ingeniera inversa ............................................................... 42
5.3.3 Sub-proyecto de desarrollo ............................................................................ 46
5.4 Conclusiones de la Gua ...................................................................................... 51
6 TRABAJO FUTURO ................................................................................................ 52
7 CONCLUSIONES .................................................................................................... 53
BIBLIOGRAFA .............................................................................................................. 54
VIII
LISTA DE FIGURAS
FIGURA 1. CICLO DE VIDA DE UNA APLICACIN ......................................................................................................................... 10
FIGURA 2. CLASIFICACIN DE SISTEMAS LEGADOS (11) (12) ....................................................................................................... 11
FIGURA 3 . PROCESO DE SIMULACIN PROPUESTO POR PINHEIRO (14) ......................................................................................... 13
FIGURA 4. PROCESO DE MANTENIMIENTO DE SOFTWARE (13)..................................................................................................... 14
FIGURA 5. PERSPECTIVA DE REINGENIERA COMO SOLUCIN DE UN PROBLEMA DELIMITADO (3)......................................................... 15
FIGURA 6 . PERSPECTIVA DE REINGENIERA COMO SISTEMA (3) .................................................................................................... 16
FIGURA 7 . PROCESO DE REINGENIERA, PROPUESTO POR SOMMERVILLE (13) ................................................................................ 17
FIGURA 8. ELEMENTOS FORMS ............................................................................................................................................. 22
FIGURA 10. EJEMPLO DE LGICA EN UNA FORMA DE ORACLE FORMS6I ........................................................................................ 23
FIGURA 9. RELACIN 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 VALORACIN DE UN SISTEMA .................................................................................... 27
FIGURA 15. DIAGRAMA DE UN ENTORNO DE APLICACIN WEB MULTINIVEL ................................................................................... 29
FIGURA 16. RELACIN ENTRE LOS MDULOS DEL PATRN MVC .................................................................................................. 32
FIGURA 17. USO DEL PATRN OBSERVADOR PARA DESACOPLAR EL MODELO ACTIVO DE LA VISTA........................................................ 32
FIGURA 18 . UNA COMN 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 APLICACIN ORACLE FORMS6I ........................................................................... 48
FIGURA 23. ARQUITECTURA DE MIGRACIN 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 CONSTRUCCIN 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 LGICA DE NEGOCIO. ........................................................................ 48
INTRODUCCION
Los permanentes avances tecnolgicos, el creciente grado de complejidad de los
sistemas de informacin y el permanente cambio de los requerimientos de los
usuarios son algunos de los factores del aumento de los sistemas legados en el
ecosistema tecnolgico de las organizaciones, razn por la cual en muchas de
ellas llevan a la consideracin evolucionar, mantener o migrar dichos sistemas.
Dentro del ciclo del desarrollo del software, la etapa del mantenimiento es una de
las ms 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.
Segn la terminologa 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 desempeo u otras caractersticas,
adaptar o cambiar su entorno...
Aclarado el anterior trmino, se entiende el por qu las empresas gastan en
promedio entre el 60 y 85 por ciento de su presupuesto de Tecnologa de
Informacin en mantenimiento de aplicaciones legadas que no cumplen con las
necesidades cambiantes de la competencia de la organizacin1. A pesar de la
posible obsolescencia, los sistemas legados continan manteniendo una ventaja
competitiva a travs del apoyo al proceso de negocio, acumulando invaluable
conocimiento y data histrica (1).
Diversos factores internos y externos, econmicos, de mercado, legales,
administrativos o polticas de organizacin, exigen cambios continuos en el
negocio. Estos cambios generan o causan modificaciones en los requerimientos
de software que recaen sobre los sistemas tecnolgicos, haciendo necesaria la
introduccin de cambios para alinearse a los nuevos requerimientos del negocio
(2).
Por consiguiente si en la organizacin, luego de evaluadas las alternativas para el
aprovechamiento de los sistemas legados, se elige la migracin como estrategia;
el propsito del presente proyecto servir de gua en definir criterios claves para la
migracin de sistemas legados, especficamente aquellos basados en tecnologa
Oracle Forms6i cuya arquitectura objetivo sea hacia una arquitectura multi-capa.
An Executive Guide to Oracle Modernization. Enabling Strategic Business Transformation.

Oracle.com
CAPITULO 1.
1 GENERALIDADES
1.1 PLANTEAMIENTO DEL PROBLEMA
La creciente competitividad de las compaas, por esforzarse a ser ms 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 informacin de las compaas, los cuales deben
ser adaptados para soportarlos.
En el momento que estos sistemas de informacin se resistan al cambio de las
crecientes necesidades de las compaas para tener contacto ms cercano con
sus clientes, al cambio tecnolgico organizacional, a la integracin con otros
sistemas o al uso de la internet como canal comunicacin, por ejemplo; se
consideraran sistemas legados y se requerira de un anlisis de las estrategias
de aprovechamiento de estos sistemas.
De esta manera, los sistemas de informacin que fundamentalmente estn
dirigidos a la parte operativa de las organizaciones, cuyo mantenimiento o soporte
es costoso, y normalmente son de misin crtica adems de tener una integracin
de componentes en donde se mezclan presentacin y lgica de negocio, tales
como las aplicaciones Oracle Forms6i actualmente, podran catalogarse como
sistemas de informacin legados y representaran para la organizacin una
desventaja tecnolgica que se hace necesaria de evolucin.
Muchos de esos sistemas de informacin que permanecen funcionando durante
aos, se convierten en islas muy eficientes en la estructura vertical de la
organizacin, pero estn desactualizadas tecnolgicamente, son monolticas y su
integracin horizontal con otros sistemas software se han convertido en un
verdadero reto (3). Este proceso de evolucin e integracin involucra cambios a
nivel tecnolgico, los cuales en el contexto de la migracin de software encuentran
cualidades de transformacin o adaptacin.
Cerca del 80 % de los sistemas de informacin todava corren en plataforma
legada (4), pero el deseo de reemplazar estos legados se ve limitado por
restricciones como:
Grandes inversiones acumuladas en el sistema legado en largo tiempo.

Disminucin del personal tcnicamente habilitado.
Prdida significativa de conocimiento sobre las tareas internas que trabajan
estos sistemas.
Estas restricciones impiden a las organizaciones reemplazar estos sistemas de

una forma rpida y econmica (4), las cuales, al considerar los costos de
produccin y mantenimiento de sus sistemas legados, sus dificultades de
integracin con otros sistemas, adems de funcionalidades altamente acopladas
convertidas en factores que aceleran la obsolescencia del software; optan por
evolucionarlas mediante procesos de reingeniera en donde la migracin de las
aplicaciones se convierte en la decisin ms adecuada.
1.2 OBJETIVOS
1.2.1 Objetivo General
Facilitar una gua que sirva como complemento a los proyectos de reingeniera
para la migracin de aplicaciones basadas en tecnologa Oracle Forms6i hacia
una plataforma multicapa.
1.2.2 Objetivos Especficos

Establecer los factores que convierten a un sistema software en un sistema
legado para que las organizaciones puedan mitigarlos.
Identificar las alternativas de evolucin de los sistemas legados con el fin de
elaborar el marco conceptual de la gua de migracin.
Identificar las fases requeridas para la gua de migracin del sistema legado
en un contexto evolutivo.
Analizar la propuesta de Oracle para la evolucin de las aplicaciones
legadas Oracle Forms6i dependiendo de su valoracin.
1.3 JUSTIFICACION
Durante mucho tiempo, las organizaciones han acumulado valioso conocimiento
de sus negocios en sistemas de informacin que adaptaron para soportar su
operacin, delegndoles 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 tecnologa limitaba
su continua evolucin.
En estos casos las directivas de las organizaciones, viendo el creciente y
acelerado avance tecnolgico ven posibles ventajas que les ayudaran a mejorar
su competitividad de la mano de cambios constantes en las estrategias del
negocio. Por sta razn, los ejecutivos de informtica durante las etapas de
mantenimiento preventivo y/o correctivo de los sistemas de informacin con los
que cuenta la organizacin, se les hace prioritario no perder el ritmo de las
tendencias tecnolgicas que permitan apoyar el logro de los objetivos de la
organizacin.
Aunque existen varias alternativas de evolucin de sistemas legados, en algn
momento la migracin de aplicaciones legadas de la mano de la reingeniera se
4
hace evidentemente como la opcin ms adecuada por costes y beneficios para la

organizacin.
Para el caso de los proyectos de Ingeniera del Software que involucren la
evolucin de aplicaciones, y ms especficamente en la migracin de aplicaciones
legadas con tecnologa Oracle Forms6i, una gua de migracin de aplicaciones
legadas se convierte en un activo importante con el que se puede contar durante
las fases de planificacin del proyecto.
En sntesis la ELABORACIN DE UNA GUA PARA LA MIGRACIN DE
SISTEMAS LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTICAPA, es un instrumento de apoyo en las etapas de planeacin o anlisis de los
proyectos de migracin de aplicaciones legadas Oracle Forms6i cuya arquitectura
objetivo sea una arquitectura objetivo multi-capa, para establecer criterios bsicos
que se deban considerar en la evolucin de los sistemas legados que usen sta
tecnologa.
1.4 IMPACTOS ESPERADOS DEL PROYECTO
Acelerar la etapa de anlisis en proyectos que involucren evolucin de

sistemas legados con tecnologa Oracle Forms6i.
Mejorar la integracin de datos en toda la organizacin luego de desacoplar

en capas la arquitectura de los sistemas de informacin valorados como
legados.
Servir como marco de referencia para la identificacin de factores que

puedan afectar el desarrollo de proyectos de migracin, permitiendo la
reduccin de costes.
Resultado/Producto Esperado
Gua de migracin
Indicador
Gua
Beneficiario
Entidades interesadas en
realizar
proyectos
de
migracin de aplicaciones
legadas
1.5 PLAN DE TRABAJO

A continuacin se detallan las fases y sus actividades que ayudarn a cumplir los
objetivos planteados:
1.5.1 Fase de Anlisis de Sistemas Legados.

a. Recopilar informacin que sirva como soporte del marco terico
relacionado con los sistemas legados.
b. Estudiar los conceptos de sistemas legados, caractersticas y tcnicas de
migracin.
c. Establecer criterios de clasificacin de los sistemas legados.
1.5.2 Fase de Anlisis de aplicaciones Oracle Forms6i como

sistema legado.
a. Recopilar la informacin directamente de la fuente de la tecnologa Oracle
Forms6i.
b. Establecer las caractersticas que pueden hacer hoy en da un sistema
basado en Oracle Forms6i considerado como legado.
1.5.3 Fase de Anlisis de arquitecturas objetivo multi-capa

candidatas y sus metodologas de migracin.
a. Recopilar informacin que sirva como soporte del marco terico
relacionado con las arquitecturas multi-capa y sus metodologas de
migracin.
b. Comparar las ventajas ofrecidas por cada arquitectura multi-capa.
c. Proponer una arquitectura y una metodologa para la migracin de
aplicaciones legadas Oracle Forms6i.
1.5.4 Fase de Diseo de la gua de migracin para aplicaciones

Oracle Forms6i hacia una arquitectura objetivo multicapa.
Forms6i.
1.5.5 Fase de Generacin de la Gua de migracin.

Forms6i.
1.6 CRONOGRMA
5. Generacin de la Gua de migracin.

Entrega de Resultados.
X
X
Mes
5
Mes
4
Mes
3
Fase
1. Anlisis de Sistemas Legados.
X
2. Anlisis de Oracle Forms6i como
X
sistema legado.
3. Anlisis de arquitecturas candidatas
multi-capa.
4. Diseo de la gua de migracin para
aplicaciones Oracle Forms6i hacia una
arquitectura objetivo multi-capa.
Mes
2
Mes
1
Tabla 1. Cronograma de Actividades
X
X
CAPITULO 2. ESTADO DEL ARTE

2 MARCO TERICO / ESTADO DEL ARTE
Las Tecnologas de Informacin - IT2, ms que nunca, tienen un impacto directo
sobre la competitividad, calidad, productividad, la lnea 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
Tecnologas de Informacin, sino por el contrario involucrarlas en la creciente
innovacin 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 informacin crtica (5).
Las organizaciones tienen una opcin cuando se trata de crear soluciones ms
giles y favorables a los negocios para responder a los cambios en curso en la
"arquitectura de negocio", la Tecnologa de Informacin - IT. La arquitectura del
negocio es definida como un bosquejo de la empresa que suministra un
entendimiento comn de la organizacin y es usado para alinear objetivos
estratgicos y demandas de tctica. Es llamada Arquitectura basada en la
modernizacin (MDA)3 o, simplemente, "modernizacin". La arquitectura basada
en la modernizacin es definida como Un conjunto colectivo de herramientas y
disciplinas que facilitan el anlisis, la refactorizacin y la transformacin de activos
software existentes para apoyar una amplia variedad de escenarios de negocio
basados en IT (6).
OMG4, define la Arquitectura basada en la modernizacin como el proceso de
entendimiento e involucramiento de los activos software con el propsito del
mejoramiento del software; modificacin; interoperabilidad; refactorizacin;
reestructurado; reuso; migracin; traduccin; integracin; arquitectura orientada a
servicios; y transformacin de la arquitectura basada en modelo (5) (6).
El concepto de modernizacin ha estado involucrado en una gran variedad de
escenarios del negocio en donde las organizaciones intentan entender,
2
Vase http:// wordnetweb.princeton.edu/perl/webwn .Information Technology IT o Tecnologas

de Informacin - TI: Rama de la ingeniera que se ocupa del uso de las computadoras y las
telecomunicaciones para recuperar, almacenar y transmitir informacin.
3
Model Driven Architecture (MDA)
4
Object Management Group (OMG).
evolucionar o reemplazar las aplicaciones y arquitectura de datos existentes,

debido a la dinmica misma de las reglas del negocio; por lo que muy a menudo,
adaptar los sistemas legados para nuevos requerimientos tambin requiere su
migracin a una nueva tecnologa. La migracin 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 desaparicin luego de algn mantenimiento
suspensivo (8).
La migracin de Software involucra la transformacin o adaptacin de un sistema
software existente a un nuevo contexto tecnolgico. De acuerdo con el estndar
IEEE 1219 sobre Mantenimiento de Software (9), la migracin del software cae
bajo la sombrilla ms ancha del mantenimiento adaptativo.
Las actividades de migracin 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 grfica o basada en web) (10).
2.1 Sistemas Legados (3)

A. OCallaghan, define un sistema legado5 como una aplicacin de software que
posee un importante valor de negocio, y aunque se ha debilitado por el constante
cambio tecnolgico, un pobre soporte arquitectnico, alto costo de mantenimiento
o documentacin inexistente, se mantiene en produccin.
Andy Kyte, Gartner Group. Eliminate 'Legacy' in One Simple Step. Un sistema de etiquetado como
"legado" es degradante para el sistema y no proporciona informacin til sobre el valor que ofrece ni una
indicacin de la futura estrategia para el sistema. Ms tiles y mejores descriptores pueden y deben ser
utilizados..
Figura 1. Ciclo de vida de una Aplicacin
Las aplicaciones existentes son el resultado de las inversiones de capital del

pasado. El valor de la inversin en la aplicacin tiende a disminuir con el tiempo, la
empresa y el contexto tecnolgico cambia. A principios del ciclo de vida habr una
creciente inversin por mantener una estrecha vinculacin con el negocio pero con
el tiempo llegar un punto en que se hace difcil, 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 Caractersticas que hacen de un sistema, realmente un

legado (12)
1. Se trata de un sistema escrito en lenguajes de varios aos atrs 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
grficas.
4. Las aplicaciones que componen el sistema, son frecuentemente
monolticas, las cuales fueron desarrolladas para suplir una necesidad de la
10
organizacin, separadas del resto del sistema, presentando una integracin

normalmente vertical.
5. Es un sistema fundamentalmente dirigido a la parte operativa de las
organizaciones, normalmente de misin crtica para la organizacin que
requiere estar operando todo el tiempo.
6. Suelen ser sistemas bastante complejos y grandes (millones de lneas de
cdigo y lgica de negocio).
7. Estos tipos de sistema suelen no tener ningn tipo de documentacin, no es
posible hacer trazabilidad de funcionalidad.
funcional
Un sistema legado no necesariamente tiene que cumplir una o varias de las
anteriores caractersticas 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 ingeniera, su arquitectura no es lo suficientemente flexible como
para absorber los cambios provocados por nuevos requerimientos (3).
2.1.2 Clasificacin de los sistemas legados (12) (13)

En la siguiente figura se muestra la clasificacin de un componente o aplicacin
segn su tipo de acoplamiento en el manejo de la informacin. Ver Figura 2.
Figura 2.. Clasificacin de sistemas legados (12) (13)
Massari6, los resume:

Altamente desacoplados,
desacoplados, estn bien estructurados y tienen ciertas
cierta caractersticas
fundamentales:
Los componentes de la aplicacin son separables, presentacin, la lgica
de negocio y el acceso a los datos, es decir, el software se descompone
descom
en
tres capas lgicas.
Los mdulos de aplicacin son independientes entre s (no
(
hay
interdependencias jerrquicas).
6
Massari A, Mecella. (13).
11
Los mdulos de aplicacin 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
caractersticas
clave:
Los componentes de la aplicacin se dividen en dos niveles: los servicios de
acceso a datos y la presentacin y la lgica de la aplicacin (fusionados en un solo
bloque).
Los mdulos de aplicacin tienen interfaces bien definidas para otras aplicaciones.
En estos sistemas, puede acceder directamente a los datos, pero no la lgica de la
aplicacin.
Desacoplamiento de programas, tambin son semi-estructuradas con las
siguientes caractersticas:
Los componentes de la aplicacin se dividen en dos niveles: los servicios
de presentacin y el acceso a datos y lgica de la aplicacin (fusionados en
un solo bloque).
Los mdulos de aplicacin 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
transaccin).
Esta categora incluye a la mayora de las aplicaciones legadas.
Monoltico, sistema no estructurado, en el cual el componente aplicativo es un solo
bloque que contiene todos los niveles. Son accedidos generalmente a travs de la
invocacin desde terminales.
La decisin del tratamiento de un sistema legado no es fcil (3), ya que las
opciones iran 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, tambin la opcin de la modificacin en pro de mejorar
su capacidad de mantenimiento, solucin a corto plazo o mediante procesos de
reingeniera 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 solucin, ya que dependen del contexto mismo del
problema.
2.1.3 Opciones para la evolucin de sistemas legados

Las alternativas para la actualizacin de los sistemas legados dependen en gran
medida de la valoracin del sistema: valor del negocio vs calidad del sistema (14),
y con base en sta decidir una estrategia para la evolucin de los mismos, tales
como:
12
Abandonar el sistema legado y sustituirlo por uno nuevo. Esta opcin debera
elegirse cuando los procesos de negocio no reciben alguna contribucin por parte
del sistema, por lo que se debera planear la migracin del sistema legado a un
nuevo sistema. Al respecto Pinheiro (15) propone un proceso para simular y
determinar el comportamiento de la migracin antes de hacerla operativa.
ste modelo se basa en la definicin de una carga de trabajo sinttica7, de la que
se derivan actividades de modelamiento, experimentacin, simulacin y validacin
para predecir el comportamiento de un sistema objetivo o de destino.
El proceso de simulacin para la evaluacin del funcionamiento de un sistema de
destino se muestra en el diagrama de actividad en la Figura 3 mediante la produccin
de un modelo vlido. En la etapa de modelamiento se especfica el modelo, en la
actividad de simulacin se ejecuta el modelo y se producen las salidas de la
simulacin, que junto a los resultados de la experimentacin, permiten hacer la
validacin
Figura 3 . Proceso de simulacin propuesto por Pinheiro (15)
Si los resultados son similares el modelo se considera vlido, de lo contrario se

somete a una actividad de refinamiento y se vuelve a hacer la simulacin, esto se
7
Carga de trabajo sinttica: Concepto que define al conjunto de informacin recogida tanto del
nuevo sistema como del sistema legado como insumo para la propuesta de simulacin.
13
repite hasta que la diferencia de resultados entre simulacin y experimentacin

sea escasa. El modelo validado y aceptado se pasa a la actividad de prediccin
del que resulta la descripcin 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 anlisis exhaustivo que permitan decidir el mtodo
que se va a utilizar para la migracin de la informacin 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 migracin, el cual puede
mitigarse adoptando una estrategia de reemplazo evolutiva (14).
Garantizar mantenimiento del sistema actual. Una definicin de mantenimiento

dada por ISO/IEC:
Un producto software soporta una modificacin en el cdigo y su documentacin
asociada para la solucin 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

organizacin y las peticiones de cambio de los usuarios son mnimas. En dado
caso Sommerville (14) propone un conjunto de actividades que conforman el
proceso de mantenimiento de la Figura 4.
Reingeniera del sistema actual. La reingeniera del software se refiere a la re
implementacin de los sistemas heredados para hacerlos ms mantenibles (14).
La definicin dada por el Reengineering Center del Software Engineering Institute
de la Universidad Carnegie Mellon es:
14
Reingeniera es la transformacin sistemtica de un sistema existente a una

nueva forma para realizar mejoras de la calidad en operacin, capacidad del
sistema, funcionalidad, rendimiento o capacidad de evolucin a bajo coste, con un
plan de desarrollo corto y con bajo riesgo para el cliente.
Las concepciones alrededor de la reingeniera de software son muy variadas, van
desde suponer mejoras en la comprensibilidad y mantenimiento del software (14),
diagnosticar y reconstruir el software, aplicacin de ingeniera inversa e ingeniera
directa al cdigo existente, pero quizs la ms amplia y aceptada es considerarla
una forma de reutilizacin, que mejora la calidad y reduce el esfuerzo de llevar un
sistema existente a un nuevo contexto (3).
Sommerville (14), establece una distincin crtica de la reingeniera y un nuevo
desarrollo en donde el sistema antiguo acta como una especificacin para el
nuevo sistema. Por lo tanto, el bajo riesgo que supone partir de una base slida y
funcional de software y el coste reducido, se convierten en dos ventajas clave
sobre aproximaciones ms radicales a la evolucin del sistema. A continuacin se
presentan algunos de los enfoques de la reingeniera (17):
Figura 5. Perspectiva de reingeniera como solucin de un problema delimitado (3)
1) Reingeniera desde una Perspectiva de ingeniera (17)

La reingeniera puede ser vista como un problema limitado de problemas, en
donde la evolucin del sistema se logra mediante la comprensin del sistema
actual y un plan de que permita lograr el sistema deseado. Ver Figura 5.
2) Reingeniera desde una Perspectiva de sistema (17)
En la reingeniera de sistemas es importante entender que el sistema operacional
es slo una parte del entorno legado total.
15
Figura 6 . Perspectiva de reingeniera como sistema (3)
El modelo que gua el proceso de reingeniera propone actividades para la

planeacin, identificacin descripcin, comprensin, fortalecimiento y evaluacin
de factores tcnicos, administrativos y del proyecto, ofreciendo un contexto para
unificar la terminologa de las actividades de reingeniera, difundiendo las
lecciones aprendidas al respecto, como se ilustra en la Figura 6.
3) Reingeniera desde una Perspectiva evolutiva
Los sistemas evolutivos se definen como sistemas que son capaces de acomodar
los cambios a travs de una vida til prolongada. La tecnologa que soporta los
sistemas evolutivos debe habilitar la creacin de sistemas que estn diseados
para evolucionar y la transformacin 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 evolucin, suponiendo que el software nunca est terminado.
4) Reingeniera desde una perspectiva del software
En esta perspectiva Sommerville (14) propone una metodologa que define varias
tareas y es descrita en la Figura 7. Inicialmente, se hace una traduccin del cdigo
fuente a otro lenguaje o por lo menos a una versin actualizada.
16
Figura 7 . Proceso de reingeniera, propuesto por Sommerville (14)
La reingeniera de software se puede hacer utilizando varias alternativas:

1) Modernizacin de caja blanca (16): Se fundamenta en la identificacin de los
componentes del sistema y sus relaciones para conseguir una representacin a
niveles mayores de abstraccin, conocida tambin como ingeniera inversa; cuya
ventaja es la recuperacin del diseo y la funcionalidad del sistema desde el
cdigo para modernizar el lenguaje de programacin o el soporte de los datos.
2) Modernizacin de caja negra o Wrapping8 (16): es una tcnica de reingeniera
en la que slo se analizan las interfases (las entradas y salidas) del legacy
ignorando los detalles internos. La reingeniera basada en wrapping puede
realizarse a nivel funcional, de datos o de interfase. En cada una de ellas se
emplean tcnicas que se describen a continuacin.
Wrapping de interfases de usuario. Se busca dar mayor facilidad de operacin,
modernizando la interfase de usuario, a menudo usando una tcnica conocida
como screen scraping9, la cual envuelve la interface basada en texto con un
entorno grfico basado en GUI o en HTML.
Wrapping de datos. Permite accede a los datos del legado usando una interfaz
diferente a la diseada inicialmente.
Usar puentes hasta los nuevos lenguajes de implementacin haciendo uso

de Gateway de base de datos, emplea interfaces propietarias en la base de
datos del legacy e interfaces estndares (ODBC, JDBC) como puentes
hasta los nuevos lenguajes de implantacin.
Pedraza (3), cita a E. Wohlstadter, S. Jackson, P. Devanbu. para definir a los wrappers como una
capa envolvente de software que asla un sistema legado de una exigente carga de
interoperabilidad, de forma que el sistema pueda mantenerse incluso sin modificaciones.
9
Vase la definicin en http://es.wikipedia.org/wiki/Screen_scraping
17
Integracin con tecnologa XML aprovechando el intercambio de datos

entre sistemas o negocios.
Replicacin de datos, esta es utilizada comnmente 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 especficamente para cada
sistema, buscando el acceso de aplicaciones desarrolladas con tecnologa
orientada a objetos.
Wrapping funcional. Encapsula datos y funcionalidades del legado, se emplean

tcnicas como:
Integracin con CGI que permite el acceso al legacy usando Common
Gateway Interface mediante servidores Web o HTTP.
Object Oriented Wrapping (OOW). La tecnologa de objetos distribuidos
(DOT) es la combinacin de la orientacin a objeto con la distribucin
(middleware objeto) (CORBA).
Wrapping basado en componentes. Este mtodo utiliza el modelo de
componentes distribuidos, donde la idea es separar la interface del sistema
legado en mdulos agrupados por unidades lgicas, buscando un punto de
contacto nico, a travs del cual se establece la comunicacin entre un EJB
por ejemplo y una funcin concreta del sistema legado.
18
3 ARQUITECTURA
FORMS
HISTORIA
DE
ORACLE
3.1 Qu es Oracle Forms?

Oracle Forms es un producto de software para la creacin de pantallas que
interactan con una base de datos Oracle. Cuenta con un IDE que incluye un
navegador de objetos, hoja de propiedades y editor de cdigo que utiliza PL / SQL.
Fue desarrollado originalmente para ejecutarse en el servidor en modo de
sesiones de carcter 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 creacin de sistemas de entrada de datos
ms que el acceso a una base de datos Oracle. En la mayora de lanzamientos de
una base de datos Oracle usualmente resulta una nueva mayor versin de Oracle
Forms para soportar nuevas caractersticas en la base de datos.
A continuacin en la Tabla 2 se muestra la evolucin que ha tenido Oracle Forms
gestionado por la corporacin Oracle:
19
Tabla 2. Resumen de las Versiones de Oracle Forms10
IAF
(*1)
Database
2
Character/
GUI
Character
FastForms+IAG
Character
Name
Version
Comments
No IDE
SQL*Forms
Character
SQL*Forms
2.3
Character
New IDE, No PLSQL, User Exits, INP ASCII File, FRM Runtime File
SQL*Forms
Character
6-7
Gui /
Character
Major Rewrite, New IDE, PLSQL, X Support, Generate code to enforce constraints
Major Rewrite, New IDE, FMB source binary file, FMX Runtime, optimized for Client-Server. New interface is
slow, buggy and not popular with client base.
Oracle Forms
4.0
Gui /
Character
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
contracted to support v4 for a period of time for some large, important customers. So, Oracle named this
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 /
Character
Gui /
Character
Gui /
Character
Forms Server / Web Forms introduced. Client-Server still available and used by most clients. Forms Server
mode is slow, buggy and uses a lot of memory per session.
9i
Gui
Client-Server runtime removed leaving Forms Server as only runtime option. Same memory requirements as
before but memory is now cheaper so not as big an issue.
10g
10g
Gui
This is a Forms 9 release (9.0.4.0.19). Renamed externally to indicate support for 10g database. Menu-HelpAbout 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
Oracle Forms
4.5
Oracle Forms
Oracle Forms
Oracle Forms
6i
Oracle Forms
9i (*2)
Oracle Forms
(*1) Cada versin 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 histricamente han seguido su propia numeracin-release y convenciones de nombrado. Esto cambi con Oracle RDBMS 9i release cuando Oracle
Corporation inici la estandarizacin de Oracle Forms (y Reports y Developer) para usar el mismo mayor nmero de versin 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 Cmo funciona Oracle Forms?11

Oracle Forms accede a la base de datos Oracle y genera una pantalla que
presenta los datos. La forma de cdigo fuente (*.FMB) se compila en un
"ejecutable" (*.FMX), que se ejecuta (interpreta) por el mdulo de tiempo de
ejecucin 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,
mens, barras de desplazamiento, y los grficos se pueden colocar en el
formulario.
El entorno provee la creacin integrada de registros, modo de consulta y
actualizacin, cada uno con sus propios manipuladores de datos por defecto.
Esto reduce al mnimo la necesidad de las operaciones comunes y tediosas de
programar, como la creacin de SQL dinmicos, deteccin 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 automticamente en las etapas crticas en el procesamiento de
registros, la recepcin de las pulsaciones del teclado, y la recepcin de los
movimientos del ratn. Existen diferentes disparadores o triggers que pueden
ser llamados antes, durante y despus de cada paso crtico.
Cada funcin de trigger inicialmente es un bloque, con una accin
predeterminada o nada. La programacin 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 accin por defecto, mientras que otros
aumentan.
Como resultado de esta estrategia, es posible crear una serie de diseos o
layouts de forma predeterminada que posean la funcionalidad de base de datos
completa a pesar de que no haya del todo cdigo escrito por el programador.
3.3 Integracin con herramientas CASE de Oracle

Designer
Oracle Designer es una herramienta CASE capaz de generar diversos mdulos
de software incluyendo Oracle Forms y Oracle Reports.
3.3.1 Caractersticas 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 mdulo de formulario en Oracle Forms Designer (Ver Figura

8), se trabaja con varios objetos especficos para formar mdulos (18), que
incluyen:
Window: Una ventana es, por s mismo, un marco vaco. Tiene una barra de
ttulo y se ocupa de la interaccin, permitiendo a los usuarios finales para
desplazarse, mover y cambiar el tamao de la ventana.
Canvas: Son objetos de fondo sobre el que se colocan los objetos de interfaz y
los elementos grficos que los usuarios finales interactan al usar una aplicacin
Forms Builder.
Block: Los bloques son contenedores lgicos para los elementos de Forms
Builder, y son la unidad bsica de informacin en un mdulo de formulario. Un
mdulo de formulario contiene normalmente varios bloques.
Item: Son objetos de la interfaz que muestran informacin a los usuarios finales
y les permiten interactuar con la aplicacin.
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. Relacin entre Tablas o Vistas con Bloques de Datos
En tiempo de ejecucin, los usuarios finales podrn manipular elementos de la

interfaz en el mdulo de datos para consultar, insertar, actualizar y eliminar
registros de datos en la base de datos.
Un bloque de datos automticamente incluye una funcionalidad para apoyar
estas interacciones con la tabla o vista a la que corresponda el bloque.
3.3.2 Lgica de aplicaciones en Oracle Forms y Oracle Reports

Oracle Forms y Oracle Reports dispone de elementos para el manejo de la
lgica de las aplicaciones, tales como Unidades de Programa o Program Units,
bibliotecas o libraries y triggers de base de datos. sta lgica puede distribuirse
tanto en el cliente como en el servidor de PL/SQL. Ver Figura 10 y Figura 11.
Figura 10. Ejemplo de Lgica en una Forma de Oracle Forms6i
23
3.4 Arquitectura de las aplicaciones Oracle Forms

Para Oracle Forms6i, la implementacin es basada en una arquitectura
cliente/servidor, como se muestra en la Figura 11, el Forms Server Runtime
Engine y toda la lgica de la aplicacin 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 lgica de algunas aplicaciones que podra
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 lgica de las aplicaciones. ste producto llamado Oracle Forms 10g
presenta una arquitectura de tres niveles en las que se distribuye toda la
aplicacin: Cliente, Servidor de Aplicaciones y Servidor de Base
Ba
de Datos. El
Servidor de Aplicaciones, ahora es el componente responsable de ejecutar toda
la lgica de las aplicaciones contenidas en los Program Units, triggers, libreras
adems 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 caractersticas 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 lgica 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 lgica de negocio convive con la
presentacin hace que el costo por mantenerlas sea cada vez mayor; logrando
que en un punto sean analizadas con detenimiento para evaluarlas en el
contexto tecnolgico 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 documentacin 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
Correccin de Errores
Oracle Forms, Reports y Designer
6i
Oracle9i Developer Suite (9.0.2)
Oracle9i Developer Suite y
Application Server 10g (9.0.4)
Oracle9i Developer Suite y
Application Server 10g (10.1.2)
Phase 2
Futuros releases de Oracle
Developer Suite y Application
Server
31/01/2005
Fin de Soporte
Extendido
31/01/2008
Igual que Oracle9i Application Server v9.0.2

01/07/2005
01/07/2008
Igual que Oracle9i Application Server 10g (9.0.4)
31/12/2006
31/12/2009
Igual que Oracle Application Server.
31/12/2011
Igual que Oracle 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 evolucin y adaptacin a
nuevos entornos tecnolgicos.
Figura 13. Ciclo de Vida de Oracle Forms
Tal y como se describi en el captulo 2.1, relacionado los sistemas legados, no

por el simple hecho de que una aplicacin haya sido desarrollada con una
tecnologa deprecada, tal como Oracle Forms6i, debiera ser considerada como
26
aplicacin legada; no obstante el mensaje de Oracle por descontinuar el uso de

d
stas tecnologas. Ver Figura 13.
Dependiendo del valor agregado que tenga una aplicacin desarrollada con
tecnologa Oracle Forms para el negocio y la necesidad de integracin con otras
aplicaciones con su respectivo riego,
riego se puede considerar su modernizacin o
no. Se puede tomar como referencia la relacin 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 determinacin de
continuar con la operacin de los procesos soportados en el sistema, permite
tomar una decisin sobre la estrategia adecuada para evolucionar el sistema (2).
Figura 14. Aspectos considerados para valoracin de un sistema
Al respecto, Oracle considera a sus productos como activos en evolucin para

los cuales ha seguido la siguiente ruta evol
evolutiva
utiva especficamente para la lnea de
Oracle Forms:
sta figura muestra la evolucin que han tenido los productos desde sus inicios
como aplicaciones en modo bloque, pasando a aplicaciones en modo carcter,
mejorando sus capacidades en su momento con
con la innovadora arquitectura
27
cliente-servidor de Oracle Forms y actualmente con la tendencia de evolucin de

las WebForms a una arquitectura orientada a servicios SOA.
4 ARQUITECTURA DE SOFTWARE
En el marco de desarrollo del presente trabajo, sern consideradas dos
arquitecturas de software como arquitecturas objetivo de una migracin 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 computacin 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
arquitectnico particular (14). Garlan y Shaw son citados por Sommerville para
definir un estilo arquitectnico como: un patrn de organizacin de un sistema
tal como una organizacin cliente-servidor o una arquitectura por capas.
Los conceptos de capa y de nivel se usan indistintamente. Sin embargo, un
punto de vista bastante comn es que en verdad hay una diferencia, y que una
capa es un mecanismo lgico para la estructuracin de los elementos que
componen la solucin de software, mientras que un nivel es un mecanismo de
estructuracin fsica de la infraestructura del sistema (22).
A continuacin se presenta dos de las arquitecturas ms apropiadas que
soportan un adecuado nivel de descomposicin de las unidades del sistema
software que una aplicacin Oracle Forms6i contiene.
4.1 Arquitectura multinivel

En la ingeniera de software, la arquitectura de varios niveles (a menudo
denominado como la arquitectura n-tier) es una arquitectura cliente-servidor en
el que la presentacin, el procesamiento de la solicitud, y la gestin de datos
son, lgicamente, procesos separados. Por ejemplo, una aplicacin 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 ms extendido de
la arquitectura de varios niveles es la arquitectura de tres niveles.
La arquitectura de una aplicacin de N-tier proporciona un modelo para que los
desarrolladores desarrollen una aplicacin flexible y reutilizable. Al romper una
aplicacin en niveles, los desarrolladores slo tienen que modificar o agregar
28
una capa especfica, en lugar de tener que reescribir de nuevo toda la

aplicacin. Debe haber un nivel de presentacin, un nivel de negocio o acceso
de datos, y un nivel de datos (22).
4.1.1 Arquitectura multinivel de una aplicacin web

Las aplicaciones Web actualmente poseen un nivel de desacoplamiento de sus
componentes gracias en medida a la maduracin de marcos de trabajo que
permiten el despliegue de los mismos mediante las ventajas de la computacin
distribuida. Los datos y la lgica de negocios pueden compartirse entre clientes
tanto automatizados como GUI. Las nicas diferencias estarn dadas en la
naturaleza del cliente y la capa Presentation (presentacin) del nivel medio.
Adems, la separacin entre la lgica de negocios y el acceso a los datos
posibilita la independencia de las bases de datos y proporciona la capacidad de
complementacin que permite el uso de diversos tipos de almacenamiento de
datos (23).
Figura 15. Diagrama de un entorno de aplicacin Web multinivel
El funcionamiento de los componentes de una arquitectura multinivel es

explicado por Bruce Sun, en su artculo de developerWorks (23), de la siguiente
manera:
29
El cliente del navegador Web de la Figura 15 acta como un front-end GUI al

brindar funciones de visualizacin 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 presentacin y le responde al navegador. La
presentacin debe mostrarse al usuario mediante el navegador y no contendr
nicamente el contenido, sino tambin los atributos de visualizacin como HTML
y CSS.
Las reglas de negocios se centralizan en la capa Business Logic, la cual cumple
la funcin 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
reutilizacin de cdigos y conlleva a una arquitectura flexible y extensible.
Adems, a medida que van surgiendo nuevos frameworks REST y MVC, se
simplifica cada vez ms la implementacin 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 patrn de diseo 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 opcin requiere de un servidor de
aplicaciones conforme a Java EE como, por ejemplo, JBoss y no funcionara con
Tomcat. La gran ventaja de esta capa est dada en la separacin del cdigo de
acceso a datos de la lgica de negocios la cual permite el uso de tecnologas de
almacenamiento de datos dispares. La capa Data Access tambin puede actuar
como un punto de integracin para la vinculacin 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 informacin empresarial
como sistemas legado, sistemas de procesamiento de transacciones y sistemas
de planificacin de recursos empresariales.
Sun, concluye la descripcin del anterior estilo arquitectnico de sistemas en
red como una arquitectura multinivel tanto para servicios Web como para
aplicaciones Web dinmicas que conlleva a la reutilizacin, simpleza,
extensibilidad y a una clara separacin 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,
presentacin, lgica de negocio e integracin. Esto asegura una divisin clara de
responsabilidades y hace que el sistema sea ms mantenible y extensible (24).
La capa del cliente es donde se consumen y presentan los modelos de datos.
Para una aplicacin Web, la capa cliente normalmente es un navegador web.
Los clientes pequeos basados-en-navegador no contienen lgica de
presentacin; se trata en la capa de presentacin.
La capa de presentacin expone los servicios de la capa de lgica-de-negocio a
los usuarios. Sabe cmo procesar una peticin de cliente, cmo interactuar con
la capa de lgica-de-negocio, y cmo seleccionar la siguiente vista a mostrar.
La capa de la lgica-de-negocio contiene los objetos y servicios de negocio de la
aplicacin. Recibe peticiones de la capa de presentacin, procesa la lgica de
negocio basada en las peticiones, y media en los accesos a los recursos de la
capa EIS. Los componentes de la capa de lgica-de-negocio se benefician de la
mayora de los servicios a nivel de sistema como el control de seguridad, de
transacciones y de recursos.
La capa de integracin es el puente entre la capa de lgica-de-negocio y la capa
EIS. Encapsula la lgica para interactuar con la capa EIS. Algunas veces a la
combinacin de las capas de integracin y de lgica-de-negocio se le conoce
como capa central.
Los datos de la aplicacin persisten en la capa EIs. Contiene bases de datos
relacionales, bases de datos orientadas a objetos, y sistemas antiguos.
4.2.1 Patrn de diseo Model-View-Controller (MVC)

MVC es un patrn de diseo que considera dividir una aplicacin en tres
mdulos claramente identificables y con funcionalidad bien definida: El Modelo,
las Vistas y el Controlador.
MVC es el patrn de diseo arquitectural que separa los conceptos de diseo, y
por lo tanto decrementa la duplicacin de cdigo, el centralizamiento del control
y hace que la aplicacin sea ms extensible.
31
Figura 16. Relacin entre los mdulos del patrn MVC
Sin embargo, una de las motivaciones de utilizar el patrn 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 volvera a introducir la dependencia que se est
buscando evitar. Afortunadamente, el patrn 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 travs de todos los observadores registrados y les notifica del
cambio. Este enfoque es a menudo llamado "publicacin-suscripcin". El modelo
no requiere informacin especfica 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 patrn 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 especfico de cambio de
32
modelo. Cada vista puede suscribirse nicamente a los tipos de cambios que
son relevantes a la vista.
4.3 Comparacin 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, topolgicamente 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 enva actualizaciones al controlador, el controlador actualiza el
modelo y la vista se actualiza directamente desde el modelo.
33
5 GUIA DE MIGRACIN 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 terico tales como las pautas de migracin
de sistemas legados y el concepto de modernizacin, los cuales se mencionan
dentro de este captulo y no como antecesores al soporte terico de la
investigacin.
INTRODUCCION
Los sistemas legados son el resultado de muchos aos de experiencia
combinada, el desarrollo y la personalizacin adems de la acogida de los
procesos de negocio bsicos que se siguen para proporcionar una ventaja
competitiva. Esto, combinado con la fiabilidad y la estabilidad de estos sistemas
que en la mayora de casos son de escaso valor y de alto riesgo para la
organizacin los hace candidatos de un plan de sustitucin. El reemplazo y la
reescritura son necesarios en ciertos casos, pero si la aplicacin legada
existente satisface las actuales necesidades de negocio, lo ms probable es que
este legado pueda ser transformado efectivamente para satisfacer las
necesidades de la empresa en el futuro (11).
La Gua de Migracin por s sola, no constituye un activo para un proyecto de
reingeniera, el cual requiere mnimamente un proceso que lo gestione y un
lineamiento claro a seguir dado por la metodologa que se adapte a las
caractersticas del proyecto.
La ruta o camino de migracin de preferencia que se desee tomar es
influenciada por el lugar que se desee estar. Si la motivacin para considerar
una migracin a una tecnologa diferente, es explotar las caractersticas y el
poder de ese objetivo, entonces se debe estar dispuesto a hacer grandes
cambios de arquitectura.
Bajo esta perspectiva, la presente gua se constituye en una herramienta de
orientacin en la elaboracin de planes de reingeniera de aplicaciones legadas
Oracle Forms6i, teniendo en cuenta los riesgos de los proyectos e incluyendo el
punto de vista especfico de la tecnologa a migrar con su arquitectura objetivo.
CONTENIDO DE LA GUA
La gua se dirige a dos grupos distintos. Un grupo se compone de los
responsables a cargo de la planificacin e implementacin 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 migracin de
34
aplicaciones que estarn ciertamente interesadas en descripciones tcnicas. A

continuacin se bosqueja el contenido de cada seccin.
En la seccin Aspectos claves de la gua de migracin y
recomendaciones se proporcionan detalles relevantes para la toma de
decisiones en el marco de un proyecto de reingeniera, adems de
abordar temas clave como condiciones y factores a considerar para lograr
una implantacin exitosa de los proyectos basados en las
recomendaciones del proveedor de la tecnologa del sistema legado.
En las secciones Descripcin tcnica de las fases de migracin y la
seccin Establecimiento de un proyecto de reingeniera se consignan las
explicaciones tcnicas referidas, de modo que los responsables puedan
obtener una descripcin de los diversos componentes de migracin. Los
administradores de TI, pueden encontrar en stas secciones, una fuente
importante de informacin relacionada con la estrategia de migracin
escogida para los sistemas de informacin legados Oracle Forms6i,
adems de tratar temas como:
Viabilidades tcnicas y/o posibles problemas
Solucin o resolucin de problemas
Importancia tcnica en el esfuerzo de migracin de un componente
Funcionalidades que se mantienen en la migracin y/o restricciones
5.1 Aspectos claves de la gua de migracin 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 aos
- es decir, se trata de "sistemas legados" que son importantes para la empresa,
pero a menudo son difciles de entender y mantener. Por razones
presupuestales, el re-desarrollo de estos sistemas desde cero puede ser una
mala opcin.
A menudo, estos sistemas no solo han superado la vida til de sus componentes
software sino tambin de su hardware por lo que se hacen costosos de
mantener. La solucin es la migracin 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 aplicacin desarrollada para un entorno cliente-servidor
con tecnologa Oracle Forms6i actualmente se abren varias posibilidades de
migracin, las cuales implican adicionar un nuevo comportamiento de dominio
especfico y la adaptacin del sistema legado a una plataforma tecnolgica
diferente. La migracin tiene un valor especfico del dominio menos tangible,
35
pero de no hacerla de una manera oportuna y eficiente puede traer perjuicios

para la organizacin.
5.1.1 Definiciones importantes y recomendaciones generales de

migracin
Un punto de vista general sobre guas de migracin debe considerar aspectos
de gestin y control tanto como los aspectos tcnicos. Al respecto, el SEI
propone una serie de guas de migracin de sistemas legados (21), en las que
se consideran los siguientes aspectos ms relevantes12:
a) Identificar y desarrollar una estrategia global con metas alcanzables y
medibles para el proyecto de reingeniera.
Desarrollar planes de contingencia para la instalacin de nuevos sistemas.
Mantener las operaciones paralelas e instalaciones independientes de
pruebas para sistemas grandes y complejos.
Cuando hay integracin de entornos de ingeniera de software, comprobar
que la integracin 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 lnea de
responsabilidad, su propio presupuesto y recursos, y no como un
proyecto paralelo que separadamente contribuyen en incremento del
tiempo.
b) Si una nueva tecnologa se utiliza para un proyecto, proporcionar una
formacin adecuada, tanto en el contenido tcnico y la motivacin para
el cambio
Los siguientes son ejemplos de orientacin relacionados con la capacitacin:
En la introduccin de normas generales, tales como la ISO/IEC 15504
(Modelo para la evaluacin y mejora de procesos), ISO/IEC 12207
(ciclo de vida de desarrollo) o el estndar IEEE 1219 (Mantenimiento
de Software), se debe asegurar que los empleados entiendan el
significado pleno y las limitaciones del cambio, y que esta
interpretacin va ms 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 tecnologas con personas mayores,

asegurar que el plan de reconversin 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 gestin de configuracin del
sistema legado
Los siguientes son los tipos especficos de orientacin para mantener el
sistema legado bajo control:
Cuidadoso seguimiento de los datos histricos y mantener los
parmetros precisos para que las estimaciones sean precisas, ms
que supuestas.
Desarrollar un proceso documentado para la gestin, seguimiento y
asignar prioridades a las solicitudes de cambio como un requisito
previo para realizar cualquier tipo de esfuerzo de reingeniera.
d) Hacer de la arquitectura de software una consideracin primaria de

reingeniera
Las siguientes son las reas especficas de la gua de arquitectura:
Asegurar que haya un entendimiento comn y la representacin de la
arquitectura entre todos los interesados.
Asegurar la inclusin de evaluaciones de arquitectura de software
como puntos de control formal a principios del sistema de la fase de
desarrollo, cuando las decisiones crticas de diseo 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 reingeniera distinto y separado
Se debe separar el proceso de reingeniera del proceso de desarrollo, a
continuacin unas consideraciones al respecto:
Formular un proceso de reingeniera que es nico a su proyecto. No
utilice un proceso de ciclo de vida genrico.
37
Involucrar a las partes interesadas en la formulacin del proceso de

reingeniera.
Asegurar que las mtricas del proceso de reingeniera estn acorde a
los objetivos y metas de la organizacin, y no slo son datos
generados que se registran y olvidan.
5.1.2 Recomendaciones
Forms6i
Especficas
de
migracin
Oracle
Con las pautas anteriores, la Gua de migracin 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 tecnologa en cuanto a las
posibilidades de evolucin de la misma. Al respecto, Oracle recomienda la
Modernizacin (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 modernizacin es el proceso de evolucin de las tecnologas restrictivas,
tecnologas legadas a nuevas tecnologas basadas en estndares abiertos,
mientras que se conserva la lgica de negocio y los datos de los sistemas
legados.
Por qu se debe considerar la Modernizacin?

Oracle recomienda una variedad de enfoques de modernizacin de TI13 como
apoyo para la compleja variedad de desafos en la modernizacin de sistemas
legados. Estos enfoques incluyen:
Sustitucin 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).
Automatizacin de la migracin de los lenguajes legados basados en

lenguajes de 4ta generacin y otros lenguajes legados.
Reubica la lgica de la aplicacin y los datos, intactos, a una plataforma

ms abierta, rentable, y gil.
13
An Executive Guide to Oracle Modernization. Enabling Strategic Business Transformation.

Oracle.com.
38
Una combinacin de estos enfoques normalmente se requiere para proporcionar

una solucin completa a los problemas de negocios.
Oracle tambin 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 tecnologa 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 ms 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 solucin de migracin que migre
aplicaciones construidas con estas herramientas a JEE.
5.2 Descripcin tcnica de las fases de migracin

Tomando en cuenta las recomendaciones expuestas en el apartado anterior 5.1,
antes de definir fases de migracin se debe procurar establecer un proyecto
marco de migracin en donde se valore en primera instancia el sistema legado
que se va a migrar y, posteriormente, ajustar el proyecto bajo las caractersticas
de la reingeniera.
5.2.1 Consideraciones de la valoracin del sistema legado

Un sistema legado ha sido definido como un sistema que "... de manera
significativa se resiste a la modificacin y evolucin 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
heterogneo. Ver Figura 18.
39
Figura 18 . Una comn Infraestructura de TI legada
Uno de los retos de TI que puede ser observado del anterior diagrama es que la
mayora de las aplicaciones se comunican directamente entre s. Esta
dependencia puede convertirse en un verdadero problema cuando una
aplicacin tiene que ser modificada o eliminada. Cualquier modificacin puede
llevar a la actualizacin de cada lnea de comunicacin a su manera nica. Por
lo tanto, estos cambios pueden llegar a ser un esfuerzo costoso. Esta situacin
se denomina alto acoplamiento entre las aplicaciones y se est convirtiendo en
un verdadero dolor de cabeza para algunas empresas, pues estos entornos
tecnolgicos promueven el deterioro de las aplicaciones convirtindolas en
legadas.
Caractersticas a valorar del sistema legado Oracle Forms6i
En ste punto se supone que el sistema legado representa un importante activo
para la organizacin y que realmente vale la pena volver a usar en un nuevo
entorno tecnolgico. As que el valor del actual activo debe ser valorado:

El cdigo fuente es de valor?

Qu tanta lgica est bien estructurada en triggers y librerias?
El diseo de sus componentes es de valor?
Cumple a cabalidad los requisitos del negocio?
Desafortunadamente, lo ms difcil del anlisis del legado es captar en su

totalidad su funcionalidad, debido a que generalmente la documentacin
asociada del software no existe o es obsoleta, y el diseo requiere recuperarse
aplicando ingeniera inversa, a veces desde el propio cdigo. Al establecer el
40
punto inicial del proyecto de migracin, es realmente muy valorado contar con la
existencia del activo legado, ya que se establece un punto de comparacin y
uso. Particularmente, el sistema legado le permitir identificar ms fcilmente:

Requisitos y reglas de negocio

Qu es de gran importancia arquitectnica?
Casos de uso bsicos
Establecer prioridades de los usuarios, deseos y comportamientos
El nico peligro de que el sistema legado pueda ser un obstculo, es que sea
valorado de manera errnea o de manera incompleta.
5.3 Establecimiento de un proyecto de reingeniera

El proyecto de reingeniera, se puede descomponer en dos sub-proyectos:
ingeniera inversa (representaciones de la construccin del cdigo real) e
ingeniera hacia adelante (de reestructuracin y / o reconstruccin de
algunas partes del cdigo). En particular, una actividad importante en la
ingeniera inversa es recuperar la arquitectura del sistema, por lo que se hace
necesario identificar ciertas garantas durante todas las etapas del proyecto,
para que sirvan de insumo al proyecto de reconstruccin.
5.3.1 Establecimiento de la metodologa

Los proyectos de reingeniera al igual que los de ingeniera deben estar
gestionados por un proceso de ingeniera que garanticen:

Mitigacin del riesgo

Desarrollo iterativo
Valoracin del progreso basado en evidencia concreta y medible
Colaboracin de equipos
Verificacin continua de la calidad
Administracin del alcance del proyecto
Producir solo los artefactos que son requeridos.
Por lo anterior, la metodologa sugerida ms acorde y que en sus principios

fundamentales se encuentran los puntos mencionados, es RUP (Rational
Unified Process). Los anteriores principios son genricos a cualquier proyecto
de desarrollo de software, por lo que hace que la plantilla bsica del ciclo de vida
RUP, con sus cuatro fases de la Concepcin, Elaboracin, Construccin y
Transicin sea plenamente aplicable a un proyecto de reingeniera de un
sistema legado. Esto a su vez hace que la mayor parte de las actividades de la
Administracin de Proyectos de RUP tambin sean plenamente aplicables. El
hecho de que se trate de un sistema legado, no sugiere razn alguna para no
tener un Documento de Visin, 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 especficos, y una Lista de Riesgos. Tambin 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
estimacin de los costes: el personal y otros requisitos (herramientas,
middleware, formacin), que, a su vez, depender de la magnitud del trabajo que
est por hacer. A medida que avance hacia la fase de transicin, se necesita un
Plan de Implementacin, que muestra cmo el nuevo sistema se implementar,
en sustitucin del antiguo.
5.3.2 Sub-proyecto de ingeniera inversa

Usualmente la documentacin de las aplicaciones legadas, as como tambin las
aplicaciones legadas Oracle Forms6i, no la tienen y si la tienen es una
documentacin escasa o poco fiable. Por lo tanto el objetivo del sub-proyecto de
ingeniera inversa ser el de reconstruir con UML algunos modelos que en
conjunto proporcionen la vista arquitectnica del sistema legado Oracle Forms6i
para identificarlos posteriormente en el plan de migracin.
Como el objetivo de sta gua no es detallar el plan del proyecto de ingeniera
inversa, a continuacin se presenta el resumen de las actividades propuestas
(28) para el manejo del proyecto de ingeniera inversa con la metodologa RUP:
A. Valorar el alcance del proyecto de reingeniera.
B. Construccin 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 reingeniera.

A continuacin se mencionan algunas de las tareas de ste paso que se
recomiendan:
14
Establecer el alcance del negocio y los atributos de calidad deseados del

sistema legado objeto de reingeniera.
Desarrollar el documento de Visin del Proyecto: ac estar definida la
arquitectura objetivo de la migracin, 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.
Philippe Dugerdil. Using RUP to reverse-engineer a legacy system. developerWorks. 2006.
43
Paso 2. Construccin de los modelos abstractos.

Presuncin: Se tiene a la mano el cdigo fuente del sistema legado Oracle
Forms6i, que servir de punto de partida para la construccin de los modelos
abstractos.
En ste segundo paso, se involucran los roles del diseador de negocio y base
de datos, junto con el analista de sistemas, quienes tendrn que ejecutar las
tareas de la fase de Concepcin y Elaboracin. En la Figura 20 se muestra la
responsabilidad del diseador de negocio en la ejecucin 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: Anlisis de la Base de Datos,
la cual no hace parte del estndar RUP, pero se acerca a la parte de la tarea de
ingeniera inversa en la disciplina de Diseo de la Base de Datos. Ver Figura 21.
Figura 21. Analizar la arquitectura de la actual base de datos
44
A continuacin, se presenta un resumen de la relacin de roles y tareas de los

pasos que involucran la construccin de modelos abstractos del sistema legado.
Tabla 4. Tareas para cada rol involucrado en la construccin de modelos
abstractos
Rol
Tarea
Detallar un Caso de Uso de Negocio
Diseador de Procesos de Negocio Encontrar Trabajadores y Entidades de Negocio
Detallar una Entidad de Negocio
Diseador de Base de Datos
Anlisis 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 Iteracin
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 Anlisis 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 ingeniera inversa, la idea se centra en transformar el
Modelo de Anlisis de Casos de Uso del paso anterior y por medio de
heursticas lograr llegar al Documento de Arquitectura de Software.
El resumen del Paso 3, se muestra en la Tabla 5 incluyendo la relacin 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
Analizar el Modelo Implementado
Define la Ejecucin Detallada
Analista de Casos de Uso
Ejecuta los Casos de Uso
Analiza el Grafo de Llamadas
Analista de Implementacin Mapea Funciones para implementar el Modelo
Valida la Arquitectura Hipottica
Reconstruye la Arquitectura de Alto Nivel
Adems de los modelos anteriormente generados, uno de los resultados es la

estructura de alto nivel del cdigo fuente de acuerdo con posibles agrupaciones
de tipos de elementos. Por ejemplo, para el caso de Oracle Forms6i, estos
grupos podran corresponder a los paquetes de la nueva arquitectura multicapa.
Entre las posibles agrupaciones de los elementos de Oracle Forms6i se
tendran:
45
Agrupacin de lgica por Program Units

Agrupacin de lgica por Funciones
Agrupaciones de lgica por Procedimientos
Agrupaciones de lgica por Triggers
Agrupaciones de lgica por libreras
Como resultado de este paso, podemos esbozar la estructura de alto nivel del
cdigo de acuerdo a la agrupacin que posteriormente se mapearan en las
clases de la nueva plataforma arquitectnica multicapa o en una capa de lgica
en la base de datos segn su conveniencia. En ste punto cabe hacer la
anotacin que estas agrupaciones han permanecido en constante modificacin
durante los aos de mantenimiento del sistema. El resultado de esta tarea se
registra en una versin actualizada del Documento de Arquitectura de Software.
5.3.3 Sub-proyecto de desarrollo

sta seccin agrupa los conceptos de forward engineering para el
establecimiento del proyecto de desarrollo y evolucin del sistema legado Oracle
Forms6i, tomando como insumos los productos de trabajo del proyecto de
ingeniera inversa descrito en la seccin anterior.
Establecimiento de una Lnea Base
Para ir ms 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 mnimo de objetos bsicos
que describen el sistema legado (stos seran los modelos generados de la
seccin anterior). Dependiendo del alcance de la evolucin, puede que se
necesite ms o menos de:
Requerimientos
Arquitectura y Diseo
Pruebas
Documentacin Tcnica y de Usuario
Una vez se haya establecido la Lnea 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 Migracin
De acuerdo a las recomendaciones de Oracle, expuestas en la seccin 5.1.2,
para lograr una evolucin adecuada y probada de las aplicaciones Oracle
Forms6i se definir la arquitectura objetivo multicapa con el estilo arquitectnico
MVC, desarrollo basado en JEE usando JDeveloper y ADF los cuales permiten
la integracin de componentes software sobre el Servidor de Aplicaciones; es
decir un entorno tecnolgico favorable a las necesidades del negocio.
46
JEE promete a largo plazo un mantenimiento ms fcil para las aplicaciones a

travs de estndares 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 difcil. 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 difcil ofrecer a los clientes el mismo tiempo de desarrollo rpido que
estuvieron usando. Este es el por qu Oracle recomienda Application
Development Framework (ADF) como la solucin para facilitar el desafo de
implementar patrones de diseo JEE (Model View Controller, MVC) con su
entorno visual y declarativo que minimiza la necesidad de escribir cdigo.
El desafo de la migracin
En primera medida, es realmente importante que la ejecucin del proyecto de
ingeniera inversa propuesto en la seccin anterior de la gua se realice. Esto
garantizara un entendimiento de la aplicacin 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 tecnologa, y adaptar
todas las funcionalidades en la nueva arquitectura, mientras incluso mejora la
aplicacin. ste segundo desafo es importante porque JEE y Forms son
fundamentalmente diferentes. Adems el cambio de la aplicacin es exitoso
cuando la nueva versin ofrece una mejor experiencia de usuario y posee unas
capacidades tecnolgicas superiores. Despus de todo, cuando se invierte en un
proceso de modernizacin no se querr un clon de la aplicacin legada inicial.
Como tercer desafo, est el establecimiento del proceso de administracin
del proyecto para programar y monitorear el progreso durante la transicin.
ste desafo es de gran importancia ya que los proyectos de software basados
en una nueva tecnologa a menudo fracasan causado por imprevistos en la
implementacin, falta de experiencia, y falta de estndares de implementacin.
La gestin 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 tambin 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 pgina,
acceder a la computadora del cliente y ejecutar comandos de host o acceso a
archivos. Por ello, una aplicacin de Forms tpica necesita ser rediseada para
ser capaz de ejecutarse en un navegador sencillo, mostrando conjuntos de
47
pocos registros a la vez, la distribucin de los cientos de campos en varias

pginas o reducir el grado en que afectan a la computadora cliente.
Lgica de Negocios
Las aplicaciones de Forms son altamente acopladas, de acuerdo al captulo
2.1.2, y en una misma unidad de cdigo puede contener lgica de negocio con
acciones como: acciones de interfaz de usuario, validacin de datos,
manipulacin de datos, etc. Cuando se toma este cdigo para ADF, se requiere
separar la lgica de negocio dentro de sus componentes, y redefinirla de
acuerdo al patrn de diseo MVC, con el fin de crear una verdadera arquitectura
ADF.
Figura 22. Ejemplo de acoplamiento en una aplicacin Oracle Forms6i
Las posibles soluciones para manejar la lgica de negocio15 estn descritas en

la Tabla 6:
Tabla 6. Aproximaciones posibles para el manejo de la lgica de negocio.
TRATAMIENTO DE LA
VENTAJAS
DESVENTAJAS
LGICA DE NEGOCIO
Es exitoso cuando se migra Prdida de la inversin de la lgica de
el 100% de la lgica negocio de Forms6i
manualmente.
Existencia de herramientas El cdigo resultante es secuencial y
que
automatizan
la procedimental, como PL/SQL, pero
conversin
de
cdigo ciertamente no es Orientado a Objetos
Oracle Forms a Java
como se supone.
A. Traducir el cdigo
El cdigo migrado automticamente es
entero a Java
difcil de entender y no es reconocido
como un estndar java, lo que conlleva a
ms mantenimiento en caso de alguna
mejora.
La lgica que se logre migrar pertenece
ms al nivel de la Base de Datos Oracle
que al nivel del cliente
15
Tomado de Professional IT Software Services - PITSS.com
48
B. Dejar el cdigo en
PL/SQL y colocarlo
en la Base de
Datos
C. Una aproximacin
mixta
El acceso a datos o el
cdigo de manipulacin de
datos es generalmente ms
rpido en la Base de Datos.
Reduccin de riesgo
Aumento del desempeo
de la aplicacin porque
minimiza el trfico de la
red.
El cdigo de Interfaz de
Usuario en Java, y el cdigo
de manipulacin de datos
en la base de datos.
No todos los artefactos son apropiados

para el uso en la Base de Datos: Cdigo
de Interfaz de Usuario como reglas de
navegacin, validacin de campos
pertenecen ms al nivel del cliente.
De acuerdo a las opciones expuestas anteriormente, la escogencia de la

aproximacin mixta se convierte en la ms adecuada para tratar el tema de la
lgica de negocio. Por lo tanto, y continuando con el planteamiento completo del
proyecto de migracin se debern realizar fases de:

16
Recuperacin del Modelo Arquitectnico del SLOF6i16

Rediseo de los componentes del SLOF6i
Refactorizacin del cdigo del SLOF6i
Regeneracin Arquitectnica del SLOF6i hacia la arquitectura multicapa
JEE+ADF
Abreviatura para referir al Sistema Legado Oracle Forms6i, en el marco de ste documento.
49
Figura 23. Arquitectura de Migracin de Aplicaciones Forms hacia JEE+ADF
La mayor parte de la lgica de negocio de Oracle Forms est manejando datos.

sta lgica naturalmente pertenece a la Base de Datos. Por lo tanto, sta lgica
de negocio ser dispuesta en una Capa de Lgica de Negocio de la Base de
Datos. Ver Figura 23.
Luego de que el cdigo de lgica 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 evolucin o modernizacin de la
aplicacin o componentes individuales mucho ms fcil. Una vez se haya
definido la lnea base mnimamente con los artefactos requeridos, el proceso de
migracin, involucrara las siguientes disciplinas RUP:
Gestin de Requerimientos: el Modelo de Dominio ya casi estar listo por los
productos de trabajo elaborados en el sub-proyecto de ingeniera inversa,
aunque la posibilidad de inclusin de nuevos requerimientos o cambio de los
mismos permanece, se debera estar en constante actualizacin del documento
del Modelo de Dominio, tal y como se expuso en el aparte del proyecto de
ingeniera inversa.
Anlisis y Diseo: En sta etapa se definir la estrategia dependiendo de la
complejidad de la aplicacin y se debern Analizar los componentes del SLOF6i,
tales como: FMB, MMB, PLL, OLB, RDF, SQL, etc. que posiblemente tendrn
restricciones para adaptarlo al modelo web. De igual forma, se debern
50
Identificar componentes obsoletos o redundantes para reducir la aplicacin a

puro cdigo funcional identificando objetos redundantes: tablas sin uso, libreras,
unidades de cdigo sin uso o duplicadas, o incluso funcionalidades completas
obsoletas.
Implementacin: Dependiendo del alcance de la migracin y del estado del
SLOF6i como tambin del resultado de las anteriores etapas y los productos de
trabajo del sub-proyecto de ingeniera inversa, se prosigue con las siguientes
actividades:
Migrar la Lgica de Negocio a la Base de Datos. En sta actividad es posible
automatizar la migracin del cdigo haciendo uso de herramientas
estandarizadas para ste propsito.
Desarrollo de la Aplicacin JEE+ADF elaborando:
Servicios de Negocio
Objetos de Acceso a Datos
Detalle de las capas MVC
Mtodos de Interfaz de Usuario Java
Afinamientos en la fase de Post-Implementacin
Despliegue o Implantacin: Como la migracin involucr una nueva
arquitectura objetivo, se deber elegir una estrategia para la transicin 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 organizacin. sta disciplina de RUP para los proyectos de
migracin 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 Gua

Con las descripciones realizadas durante el documento de la gua, se
espera suministrar un punto de partida para que los proyectos de
migracin de SLOF6i hacia una arquitectura multicapa aseguren en
mayor valor el alcance de los objetivos.
Con el establecimiento de RUP para la gestin de la evolucin del
proyecto de reingeniera, se permite abarcar el ciclo de vida de los subproyectos de ingeniera inversa y el de desarrollo de la nueva aplicacin,
permitiendo identificar las actividades relacionadas a la evolucin de
proyectos y minimizando los posibles factores que afecten el proyecto de
migracin.
51
6 TRABAJO FUTURO
La Gua para la migracin 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 migracin tienen un alance definido, es
importante que se establezcan lmites bien claros cuando se elaboran los
procesos contractuales de ste tipo de proyectos, para que los esfuerzos
de estas iniciativas no sean subvalorados afectando drsticamente los
costos. sta problemtica enmarca un nuevo proyecto, consistente en la
elaboracin de lineamientos contractuales especficos para los proyectos
de modernizacin de aplicaciones legadas.
La presente gua deja abierta la posibilidad a que se derive un proyecto
de estimacin de costos y eficiencia econmica para los proyectos de
evolucin y modernizacin de aplicaciones legadas Oracle Forms6i.
Un trabajo de continuidad que puede tener cabida, sera el del
involucramiento de alguna disciplina de ingeniera que permita el
mejoramiento del proceso de tomas de decisiones de los proyectos de
modernizacin de aplicaciones, permitiendo valorar, mejorar y alinear los
objetivos de la organizacin (financieros, organizativos, innovacin) con
los objetivos del proyecto de reingeniera.
52
7 CONCLUSIONES
En la actualidad, las organizaciones de TI estn bajo creciente presin
para reducir costes y aumentar su capacidad de reaccin a las demandas
del negocio, por lo que los sistemas legados se convierten en un
problema para las empresas debido a que en la mayora de los casos, su
mantenimiento es difcil y costoso adems 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 metodologa evolutiva que permitiera adaptarse
a las caractersticas de un proyecto de migracin. Es por esto que
algunas de las disciplinas de RUP aplican en mayor o menor medida
dependiendo del tipo de evolucin que se escoja y la cantidad de
informacin del sistema legado objeto de modernizacin.
Para la transformacin del activo software legado Oracle Forms6i en un
activo desplegado un una arquitectura JEE multicapa, se propuso un
proyecto de reingeniera gestionado por las disciplinas de RUP y
desagregado en dos sub-proyectos (de ingeniera inversa y de
desarrollo), con el propsito de aumentar el control de las fases que
involucran la migracin de aplicaciones legadas.
Un error frecuente en los proyectos de evolucin de aplicaciones es
involucrar muchos cambios a la vez durante la ejecucin del proyecto. Por
ejemplo, en un proyecto de migracin 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 recomendacin es fortalecer el entrenamiento y la
capacitacin de la organizacin en la filosofa de RUP y el cmo la
herramienta lo apoya.
53
BIBLIOGRAFA
1. Zoufaly, Federico. Developer.com. Issues and Challenges Facing Legacy
Systems. [Online] 2002. http://www.developer.com/article.phpr/1492531/Issuesand-Challenges-Facing-Legacy-Systems.htm.
2. Evolucin de un sistema legado: mantener o migrar? IT-Liverage. [Online]
http://it-leverage.com/legacy1.aspx.
3. Pedraza Garca, Gilberto. Evolucin e Integracin 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 113122. [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. Ingeniera del Software. Sptima Edicin. 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, Mrquez, Antonio and Toro, Miguel.
ingenieriasimple.com. Gestin de la evolucin 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/fbus100997.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/Multitier_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. Integracin de JSF, Spring e Hibernate para crear una Aplicacin 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. Modernizacin de Forms: De C/S a SOA FMW 11g.
slideshare.net. [Online] http://www.slideshare.net/JC_Diaz_Belmonte/de-forms-aoracle-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

Elaboración Guía Capa Gómez 2010

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Elaboración Guía Capa Gómez 2010

Загружено:

Авторское право:

Доступные форматы

ELABORACIN DE UNA GUA PARA LA MIGRACIN DE SISTEMAS

LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTI-CAPA

HUGO ALDEMAR GMEZ MARTNEZ

UNIVERSIDAD DE SAN BUENAVENTURA

ELABORACIN DE UNA GUA PARA LA MIGRACIN DE SISTEMAS

Trabajo de Grado presentado como requisito para optar el ttulo de

UNIVERSIDAD DE SAN BUENAVENTURA

Director del proyecto

Director del proyecto

El autor expresa sus agradecimientos a:

TITULO: ELABORACIN DE UNA GUA PARA LA MIGRACIN DE SISTEMAS

AUTOR: HUGO ALDEMAR GMEZ MARTNEZ**

PALABRAS CLAVE: SISTEMAS LEGADOS, ORACLE FORMS6i, MIGRACIN,

TITLE: DEVELOPMENT OF A GUIDE FOR LEGACY SYSTEMS MIGRATION

AUTHOR: HUGO ALDEMAR GMEZ MARTNEZ**

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

5.1 Aspectos claves de la gua de migracin y recomendaciones.............................. 35

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

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

Grandes inversiones acumuladas en el sistema legado en largo tiempo.

Estas restricciones impiden a las organizaciones reemplazar estos sistemas de

1.2.2 Objetivos Especficos

hace evidentemente como la opcin ms adecuada por costes y beneficios para la

1.4 IMPACTOS ESPERADOS DEL PROYECTO

Acelerar la etapa de anlisis en proyectos que involucren evolucin de

Mejorar la integracin de datos en toda la organizacin luego de desacoplar

Servir como marco de referencia para la identificacin de factores que

1.5 PLAN DE TRABAJO

1.5.1 Fase de Anlisis de Sistemas Legados.

1.5.2 Fase de Anlisis de aplicaciones Oracle Forms6i como

1.5.3 Fase de Anlisis de arquitecturas objetivo multi-capa

1.5.4 Fase de Diseo de la gua de migracin para aplicaciones

1.5.5 Fase de Generacin de la Gua de migracin.

5. Generacin de la Gua de migracin.

Tabla 1. Cronograma de Actividades

CAPITULO 2. ESTADO DEL ARTE

Vase http:// wordnetweb.princeton.edu/perl/webwn .Information Technology IT o Tecnologas

evolucionar o reemplazar las aplicaciones y arquitectura de datos existentes,

2.1 Sistemas Legados (3)

Figura 1. Ciclo de vida de una Aplicacin

Las aplicaciones existentes son el resultado de las inversiones de capital del

2.1.1 Caractersticas que hacen de un sistema, realmente un

organizacin, separadas del resto del sistema, presentando una integracin

2.1.2 Clasificacin de los sistemas legados (12) (13)

Figura 2.. Clasificacin de sistemas legados (12) (13)

Massari6, los resume:

Massari A, Mecella. (13).

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

2.1.3 Opciones para la evolucin de sistemas legados

Figura 3 . Proceso de simulacin propuesto por Pinheiro (15)

Si los resultados son similares el modelo se considera vlido, de lo contrario se

repite hasta que la diferencia de resultados entre simulacin y experimentacin

Garantizar mantenimiento del sistema actual. Una definicin de mantenimiento

Figura 4. Proceso de mantenimiento de software (14)

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

Reingeniera es la transformacin sistemtica de un sistema existente a una

Figura 5. Perspectiva de reingeniera como solucin de un problema delimitado (3)

1) Reingeniera desde una Perspectiva de ingeniera (17)

Figura 6 . Perspectiva de reingeniera como sistema (3)

El modelo que gua el proceso de reingeniera propone actividades para la

Figura 7 . Proceso de reingeniera, propuesto por Sommerville (14)

La reingeniera de software se puede hacer utilizando varias alternativas:

Usar puentes hasta los nuevos lenguajes de implementacin haciendo uso

Integracin con tecnologa XML aprovechando el intercambio de datos