Elaboración Guía Capa Gómez 2010

ELABORACIÓN DE UNA GUÍA PARA LA MIGRACIÓN DE SISTEM AS

LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTI-CAPA

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

UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA DE SISTEMAS

ESPECIALIZACIÓN DE PROCESOS PARA EL DESARROLLO DE S OFTWARE SANTIAGO DE CALI

2010

ELABORACIÓN DE UNA GUÍA PARA LA MIGRACIÓN DE SISTEM AS LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTI-CAPA

Presentado por: HUGO ALDEMAR GÓMEZ MARTÍNEZ

Código: 1096431

Trabajo de Grado presentado como requisito para opt ar el título de Especialista en Procesos para el Desarrollo de Soft ware

Director: Dr. LUIS MERCHÁN PAREDES

Ing. De Sistemas

UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA DE SISTEMAS

ESPECIALIZACIÓN DE PROCESOS PARA EL DESARROLLO DE S OFTWARE SANTIAGO DE CALI

2010

III

Nota de aceptación

______________________________________________________

______________________________________________________

______________________________________________________

_____________________________________________ Director del proyecto

_____________________________________________ Director del proyecto

________________________________________ Jurado

________________________________________ Jurado

DICIEMBRE DE 2010

IV

AGRADECIMIENTOS El autor expresa sus agradecimientos a: Dios, porque me dio fortaleza y salud para culminar ésta estudio de postgrado. Mi esposa Adriana y a mi bebé Sergio, quienes con su apoyo y colaboración hicieron posible éste logro. Todas las personas que han confiado en mí como estudiante, profesional y amigo.

V

TITULO: ELABORACIÓN DE UNA GUÍA PARA LA MIGRACIÓN DE SISTEMAS LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTI-CAPA.* AUTOR: HUGO ALDEMAR GÓMEZ MARTÍNEZ** PALABRAS CLAVE : SISTEMAS LEGADOS, ORACLE FORMS6i, MIGRACIÓN, GUÍA, ARQUITECTURA, MULTI-CAPA, REINGENIERÍA, SOFTWARE DESCRIPCION: La dinámica actual de los negocios hace que las organizaciones requieran sistemas de información que se adapten al cambio. Por lo tanto, los sistemas legados se convierten en un obstáculo para lograr el objetivo de las empresas, las cuales se ven en la necesidad de elaborar estrategias para aprovechar éstos activos con su inherente valor organizacional. Bajo ésta premisa, el siguiente trabajo tiene por objetivo facilitar un conjunto de pautas para las organizaciones de TI que involucran planes de migración de aplicaciones legadas, especialmente las desarrolladas bajo la plataforma Oracle Forms6i hacia una arquitectura que permita desacoplar la lógica de negocio, presentación y acceso a datos y aprovechar las potencialidades del Framework de Desarrollo de Aplicaciones (ADF) de Oracle. La presente Guía de Migración se convierte pues, en una herramienta de orientación para las organizaciones que desean involucrar la reingeniería en sus proyectos de evolución de aplicaciones legadas cliente-servidor hacia arquitecturas multicapa. * Trabajo de Grado ** Facultad de Ingeniería de Sistemas Especialización en Procesos para el Desarrollo del Software Director: Ing Luis Merchán Paredes

VI

TITLE: DEVELOPMENT OF A GUIDE FOR LEGACY SYSTEMS MIGRATION Oracle Forms6i TOWARDS A MULTI-LAYER ARCHITECTURE.* AUTHOR: HUGO ALDEMAR GÓMEZ MARTÍNEZ** KEY WORDS: LEGACY SYSTEMS, ORACLE FORMS6i, MIGRATION, GUIDE, ARCHITECTURE, MULTI-LAYER, REENGINEERING, SOFTWARE DESCRIPTION: The current dynamics of business makes that organizations require information systems that adapt to change. Therefore, legacy systems become an obstacle to achieving the goal of companies, which feel the need to develop strategies to leverage these assets with their inherent organizational value. Under this premise, the following paper aims to provide a set of guidelines for IT organizations that involve migration plans of legacy applications, especially those developed under the Oracle Forms6i platform towards an architecture that allows decoupling the business logic, presentation and data access and exploit the potential of Oracle’s Application Development Framework (ADF). Then, this Migration Guide becomes in a guidance tool for organizations that wish to engage in reengineering projects evolution of legacy client-server applications to multilayer architectures. * Graduation Work ** Facultad de Ingeniería de Sistemas Especialización en Procesos para el Desarrollo del Software Project Director: Ing Luis Merchán Paredes.

VII

TABLA DE CONTENIDO

INTRODUCCION ............................................................................................................. 1 1 GENERALIDADES .................................................................................................... 2 1.1 PLANTEAMIENTO DEL PROBLEMA .................................................................... 2 1.2 OBJETIVOS ........................................................................................................... 4

1.2.1 Objetivo General .............................................................................................. 4 1.2.2 Objetivos Específicos ....................................................................................... 4

1.3 JUSTIFICACION .................................................................................................... 4 1.4 IMPACTOS ESPERADOS DEL PROYECTO......................................................... 5 1.5 PLAN DE TRABAJO ............................................................................................... 5

1.5.1 Fase de Análisis de Sistemas Legados. .......................................................... 6 1.5.2 Fase de Análisis de aplicaciones Oracle Forms6i como sistema legado. ........ 6

1.5.3 Fase de Análisis de arquitecturas objetivo multi-capa candidatas y sus metodologías de migración. .......................................................................................... 6 1.5.4 Fase de Diseño de la guía de migración para aplicaciones Oracle Forms6i hacia una arquitectura objetivo multicapa. ...................................................... 6 1.5.5 Fase de Generación de la Guía de migración. ................................................. 6

1.6 CRONOGRMA ....................................................................................................... 7 2 MARCO TEÓRICO / ESTADO DEL ARTE ................................................................ 8 2.1 Sistemas Legados (3) ............................................................................................. 9

2.1.1 Características que hacen de un sistema, realmente un legado (12) ............ 10 2.1.2 Clasificación de los sistemas legados (12) (13) ............................................. 11 2.1.3 Opciones para la evolución de sistemas legados .......................................... 12

3 ARQUITECTURA E HISTORIA DE ORACLE FORMS ............................................ 19 3.1 ¿Qué es Oracle Forms? ....................................................................................... 19 3.2 ¿Cómo funciona Oracle Forms? ........................................................................... 21 3.3 Integración con herramientas CASE de Oracle Designer ..................................... 21

3.3.1 Características de los Formularios o Formas en Oracle Forms. .................... 21 3.3.2 Lógica de aplicaciones en Oracle Forms y Oracle Reports ........................... 23

3.4 Arquitectura de las aplicaciones Oracle Forms .................................................... 24 3.5 Aplicaciones Oracle Forms como aplicaciones legadas ....................................... 25 4 ARQUITECTURA DE SOFTWARE ......................................................................... 28 4.1 Arquitectura multinivel .......................................................................................... 28

4.1.1 Arquitectura multinivel de una aplicación web ............................................... 29 4.2 Arquitectura multicapa .......................................................................................... 31

4.2.1 Patrón de diseño Model-View-Controller (MVC) ............................................ 31 4.3 Comparación de la arquitectura multinivel con MVC ............................................ 33 5 GUIA DE MIGRACIÓN DE SISTEMAS LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTICAPA ............................................................................. 34

INTRODUCCION ........................................................................................................ 34 CONTENIDO DE LA GUÍA ......................................................................................... 34

VIII

5.1 Aspectos claves de la guía de migración y recomendaciones.............................. 35 5.1.1 Definiciones importantes y recomendaciones generales de migración .......... 36 5.1.2 Recomendaciones Específicas de migración Oracle Forms6i ....................... 38 ¿Por qué se debe considerar la Modernización? ........................................................ 38

5.2 Descripción técnica de las fases de migración ..................................................... 39 5.2.1 Consideraciones de la valoración del sistema legado ................................... 39

5.3 Establecimiento de un proyecto de reingeniería ................................................... 41 5.3.1 Establecimiento de la metodología ................................................................ 41 5.3.2 Sub-proyecto de ingeniería inversa ............................................................... 42 5.3.3 Sub-proyecto de desarrollo ............................................................................ 46

5.4 Conclusiones de la Guía ...................................................................................... 51 6 TRABAJO FUTURO ................................................................................................ 52 7 CONCLUSIONES .................................................................................................... 53 BIBLIOGRAFÍA .............................................................................................................. 54

IX

LISTA DE FIGURAS

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

X

LISTA DE TABLAS

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

1

INTRODUCCION Los permanentes avances tecnológicos, el creciente grado de complejidad de los sistemas de información y el permanente cambio de los requerimientos de los usuarios son algunos de los factores del aumento de los sistemas legados en el ecosistema tecnológico de las organizaciones, razón por la cual en muchas de ellas llevan a la consideración evolucionar, mantener o migrar dichos sistemas. Dentro del ciclo del desarrollo del software, la etapa del mantenimiento es una de las más importantes y menos planeadas, aunque es una de las últimas en realizarse se ha convertido en la principal actividad en cuanto a recursos necesarios y costes. Según la terminología ANSI-IEEE, el mantenimiento del software es: “El proceso de modificar un sistema de Software o componente de éste, una vez ha sido entregado, para corregir fallas, mejorar el desempeño u otras características, adaptar o cambiar su entorno...” Aclarado el anterior término, se entiende el por qué las empresas gastan en promedio entre el 60 y 85 por ciento de su presupuesto de Tecnología de Información en mantenimiento de aplicaciones legadas que no cumplen con las necesidades cambiantes de la competencia de la organización1. A pesar de la posible obsolescencia, los sistemas legados continúan manteniendo una ventaja competitiva a través del apoyo al proceso de negocio, acumulando invaluable conocimiento y data histórica (1). Diversos factores internos y externos, económicos, de mercado, legales, administrativos o políticas de organización, exigen cambios continuos en el negocio. Estos cambios generan o causan modificaciones en los requerimientos de software que recaen sobre los sistemas tecnológicos, haciendo necesaria la introducción de cambios para alinearse a los nuevos requerimientos del negocio (2). Por consiguiente si en la organización, luego de evaluadas las alternativas para el aprovechamiento de los sistemas legados, se elige la migración como estrategia; el propósito del presente proyecto servirá de guía en definir criterios claves para la migración de sistemas legados, específicamente aquellos basados en tecnología Oracle Forms6i cuya arquitectura objetivo sea hacia una arquitectura multi-capa.

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

2

CAPITULO 1.

1 GENERALIDADES 1.1 PLANTEAMIENTO DEL PROBLEMA La creciente competitividad de las compañías, por esforzarse a ser más eficaces y efectivas en el desarrollo cotidiano de sus actividades, hace que las directrices empresariales permanezcan en constante cambio para lograr sus objetivos. Estos cambios frecuentemente afectan los procesos del negocio, casi siempre administrados en los sistemas de información de las compañías, los cuales deben ser adaptados para soportarlos. En el momento que estos sistemas de información se resistan al cambio de las crecientes necesidades de las compañías para tener contacto más cercano con sus clientes, al cambio tecnológico organizacional, a la integración con otros sistemas o al uso de la internet como canal comunicación, por ejemplo; se considerarían “sistemas legados” y se requeriría de un análisis de las estrategias de aprovechamiento de estos sistemas. De esta manera, los sistemas de información que fundamentalmente estén dirigidos a la parte operativa de las organizaciones, cuyo mantenimiento o soporte es costoso, y normalmente son de misión crítica además de tener una integración de componentes en donde se mezclan presentación y lógica de negocio, tales como las aplicaciones Oracle Forms6i actualmente, podrían catalogarse como sistemas de información legados y representarían para la organización una desventaja tecnológica que se hace necesaria de evolución. Muchos de esos sistemas de información que permanecen funcionando durante años, se convierten en islas muy eficientes en la estructura vertical de la organización, pero están desactualizadas tecnológicamente, son monolíticas y su integración horizontal con otros sistemas software se han convertido en un verdadero reto (3). Este proceso de evolución e integración involucra cambios a nivel tecnológico, los cuales en el contexto de la migración de software encuentran cualidades de transformación o adaptación. Cerca del 80 % de los sistemas de información todavía corren en plataforma legada (4), pero el deseo de reemplazar estos legados se ve limitado por restricciones como:

3

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

estos sistemas.

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

4

1.2 OBJETIVOS 1.2.1 Objetivo General Facilitar una guía que sirva como complemento a los proyectos de reingeniería para la migración de aplicaciones basadas en tecnología Oracle Forms6i hacia una plataforma multicapa. 1.2.2 Objetivos Específicos

� Establecer los factores que convierten a un sistema software en un sistema “legado” para que las organizaciones puedan mitigarlos.

� Identificar las alternativas de evolución de los sistemas legados con el fin de elaborar el marco conceptual de la guía de migración.

� Identificar las fases requeridas para la guía de migración del sistema legado

en un contexto evolutivo.

� Analizar la propuesta de Oracle para la evolución de las aplicaciones legadas Oracle Forms6i dependiendo de su valoración.

1.3 JUSTIFICACION Durante mucho tiempo, las organizaciones han acumulado valioso conocimiento de sus negocios en sistemas de información que adaptaron para soportar su operación, delegándoles una responsabilidad importante en los procesos del negocio. Estos sistemas con el paso del tiempo fueron madurando junto a las reglas del negocio dentro de las fases de mantenimiento a las que fueron expuestos, llegando en muchos casos a un punto en donde la tecnología limitaba su continua evolución. En estos casos las directivas de las organizaciones, viendo el creciente y acelerado avance tecnológico ven posibles ventajas que les ayudarían a mejorar su competitividad de la mano de cambios constantes en las estrategias del negocio. Por ésta razón, los ejecutivos de informática durante las etapas de mantenimiento preventivo y/o correctivo de los sistemas de información con los que cuenta la organización, se les hace prioritario no perder el ritmo de las tendencias tecnológicas que permitan apoyar el logro de los objetivos de la organización. Aunque existen varias alternativas de evolución de sistemas legados, en algún momento la migración de aplicaciones legadas de la mano de la reingeniería se

5

hace evidentemente como la opción más adecuada por costes y beneficios para la organización. Para el caso de los proyectos de Ingeniería del Software que involucren la evolución de aplicaciones, y más específicamente en la migración de aplicaciones legadas con tecnología Oracle Forms6i, una guía de migración de aplicaciones legadas se convierte en un activo importante con el que se puede contar durante las fases de planificación del proyecto. En síntesis la “ELABORACIÓN DE UNA GUÍA PARA LA MIGRACIÓN DE SISTEMAS LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTI-CAPA”, es un instrumento de apoyo en las etapas de planeación o análisis de los proyectos de migración de aplicaciones legadas Oracle Forms6i cuya arquitectura objetivo sea una arquitectura objetivo multi-capa, para establecer criterios básicos que se deban considerar en la evolución de los sistemas legados que usen ésta tecnología.

1.4 IMPACTOS ESPERADOS DEL PROYECTO

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

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

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

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

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

Resultado/Producto Esperado Indicador Beneficiario

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

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

6

1.5.1 Fase de Análisis de Sistemas Legados.

a. Recopilar información que sirva como soporte del marco teórico relacionado con los sistemas legados.

b. Estudiar los conceptos de sistemas legados, características y técnicas de migración.

c. Establecer criterios de clasificación de los sistemas legados. 1.5.2 Fase de Análisis de aplicaciones Oracle Forms6i como

sistema legado.

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

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

1.5.3 Fase de Análisis de arquitecturas objetivo mu lti-capa

candidatas y sus metodologías de migración.

a. Recopilar información que sirva como soporte del marco teórico relacionado con las arquitecturas multi-capa y sus metodologías de migración.

b. Comparar las ventajas ofrecidas por cada arquitectura multi-capa. c. Proponer una arquitectura y una metodología para la migración de

aplicaciones legadas Oracle Forms6i. 1.5.4 Fase de Diseño de la guía de migración para a plicaciones

Oracle Forms6i hacia una arquitectura objetivo mult icapa.



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



7

1.6 CRONOGRMA Tabla 1. Cronograma de Actividades

Fase

Mes

1

Mes

2

Mes

3

Mes

4

Mes

5

1. Análisis de Sistemas Legados. X X X 2. Análisis de Oracle Forms6i como sistema legado. X X X

3. Análisis de arquitecturas candidatas multi-capa. X X X X

4. Diseño de la guía de migración para aplicaciones Oracle Forms6i hacia una arquitectura objetivo multi-capa.

X X X X

5. Generación de la Guía de migración.

X X X X

Entrega de Resultados. X

8

CAPITULO 2. ESTADO DEL ARTE

2 MARCO TEÓRICO / ESTADO DEL ARTE Las Tecnologías de Información - IT2, más que nunca, tienen un impacto directo sobre la competitividad, calidad, productividad, la línea base y la supervivencia del negocio. Esta es una realidad tanto para el sector privado como para las agencias gubernamentales. Como resultado, los ejecutivos no pueden alejar a las Tecnologías de Información, sino por el contrario involucrarlas en la creciente innovación del negocio. Las organizaciones ahora encuentran que las IT se han convertido en un entramado junto con la infraestructura de sus negocios tanto que no parece lejos imaginarlas sobreviviendo sin sus sistemas de información crítica (5). Las organizaciones tienen una opción cuando se trata de crear soluciones más ágiles y favorables a los negocios para responder a los cambios en curso en la "arquitectura de negocio", la Tecnología de Información - IT. La arquitectura del negocio es definida como “un bosquejo de la empresa que suministra un entendimiento común de la organización y es usado para alinear objetivos estratégicos y demandas de táctica”. Es llamada Arquitectura basada en la modernización (MDA)3 o, simplemente, "modernización". La arquitectura basada en la modernización es definida como “Un conjunto colectivo de herramientas y disciplinas que facilitan el análisis, la refactorización y la transformación de activos software existentes para apoyar una amplia variedad de escenarios de negocio basados en IT” (6). OMG4, define la Arquitectura basada en la modernización como el “proceso de entendimiento e involucramiento de los activos software con el propósito del mejoramiento del software; modificación; interoperabilidad; refactorización; reestructurado; reuso; migración; traducción; integración; arquitectura orientada a servicios; y transformación de la arquitectura basada en modelo” (5) (6). El concepto de modernización ha estado involucrado en una gran variedad de escenarios del negocio en donde las organizaciones intentan entender,

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

9

evolucionar o reemplazar las aplicaciones y arquitectura de datos existentes, debido a la dinámica misma de las reglas del negocio; por lo que muy a menudo, adaptar los sistemas legados para nuevos requerimientos también requiere su migración a una nueva tecnología. La migración de sistemas legados, en otras palabras, es la transferencia de sistemas software a nuevos entornos sin cambiar su funcionalidad (7), y permite a las aplicaciones ya probadas estar en funcionamiento en vez de la desaparición luego de algún mantenimiento suspensivo (8). La migración de Software involucra la transformación o adaptación de un sistema software existente a un nuevo contexto tecnológico. De acuerdo con el estándar IEEE 1219 sobre Mantenimiento de Software (9), la migración del software cae bajo la sombrilla más ancha del mantenimiento adaptativo. Las actividades de migración van desde cambios en la plataforma hardware debido a su obsolescencia, cambio del sistema operativo, cambio en la arquitectura (p.ej., desde una arquitectura centralizada basada en mainframe hacia una arquitectura cliente-servidor o hacia una arquitectura orientada a servicio (SOA)), hasta cambio de interfaz de usuario (p.ej., desde una interface textual hacia una interface gráfica o basada en web) (10).

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

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

10

Figura 1. Ciclo de vida de una Aplicación

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

legado (12)

1. Se trata de un sistema escrito en lenguajes de varios años atrás como: Cobol, RPG, PL, Assembler.

2. Normalmente estos sistemas son soportados por un DBMS (manejador de base de datos) ya obsoleto.

3. La interface de cliente está basada en terminales las cuales no son gráficas.

4. Las aplicaciones que componen el sistema, son frecuentemente monolíticas, las cuales fueron desarrolladas para suplir una necesidad de la

organización, separadas del resto del sistema, presentando una integración normalmente vertical.

5. Es un sistema fundamentalmente dirigido a la parte operativa de las organizaciones, normalmente de misión crítica para la organización querequiere estar operando todo el tiempo.

6. Suelen ser sistemas bastante complejos y grandes (millones de líneas de código y lógica de negocio).

7. Estos tipos de sistema suelen no tener ningún tipo de documentación, no es posible hacer trazabilidad de funcional

Un sistema legado no necesariamente tiene que cumplir una o varias de las anteriores características para quele considera legado a aquel sistema que se resiste a las modificaciones y actualizaciones perdiendo competitividadprincipios de ingeniería, su arquitectura no es lo suficientemente flexible como para absorber los cambios provocados por nuevos requerimientos 2.1.2 Clasificación de En la siguiente figura se muestra la clasificación de un componente o aplicación según su tipo de acoplamiento en el manejo de la información.

Figura 2 . Clasificación de sistemas legados Massari6, los resume: Altamente desacopladosfundamentales:

• Los componentes de la aplicación son separables, de negocio y el acceso a los datos, es decir, el software se descomtres capas lógicas.

• Los módulos de aplicación son independientes entre sí (interdependencias jerárquicas).

6 Massari A, Mecella. (13).

11

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

Un sistema legado no necesariamente tiene que cumplir una o varias de las anteriores características para que sea considerado como tal, por el contrario, se

a aquel sistema que se resiste a las modificaciones y rdiendo competitividad, y aunque fue desarrollado aplicando

principios de ingeniería, su arquitectura no es lo suficientemente flexible como para absorber los cambios provocados por nuevos requerimientos

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

En la siguiente figura se muestra la clasificación de un componente o aplicación según su tipo de acoplamiento en el manejo de la información. Ver

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

Altamente desacoplados, están bien estructurados y tienen cierta

Los componentes de la aplicación son separables, presentación, y el acceso a los datos, es decir, el software se descom

tres capas lógicas. Los módulos de aplicación son independientes entre sí (interdependencias jerárquicas).

organización, separadas del resto del sistema, presentando una integración

Es un sistema fundamentalmente dirigido a la parte operativa de las organizaciones, normalmente de misión crítica para la organización que

Suelen ser sistemas bastante complejos y grandes (millones de líneas de

Estos tipos de sistema suelen no tener ningún tipo de documentación, no es

Un sistema legado no necesariamente tiene que cumplir una o varias de las sea considerado como tal, por el contrario, se

a aquel sistema que se resiste a las modificaciones y , y aunque fue desarrollado aplicando

principios de ingeniería, su arquitectura no es lo suficientemente flexible como para absorber los cambios provocados por nuevos requerimientos (3).

En la siguiente figura se muestra la clasificación de un componente o aplicación Ver Figura 2.

(13)

, están bien estructurados y tienen ciertas características

presentación, la lógica y el acceso a los datos, es decir, el software se descompone en

Los módulos de aplicación son independientes entre sí (no hay

12

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

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

• Los componentes de la aplicación se dividen en dos niveles: los servicios de presentación y el acceso a datos y lógica de la aplicación (fusionados en un solo bloque).

• Los módulos de aplicación tienen interfaces bien definidas para otras aplicaciones.

• En estos sistemas no pueden acceder directamente a los datos, pero es necesario recurrir a las funciones incorporadas (por lo general una transacción).

• Esta categoría incluye a la mayoría de las aplicaciones legadas. Monolítico, sistema no estructurado, en el cual el componente aplicativo es un solo bloque que contiene todos los niveles. Son accedidos generalmente a través de la invocación desde terminales. La decisión del tratamiento de un sistema legado no es fácil (3), ya que las opciones irían desde desecharlo completamente para reemplazarlo por uno nuevo, con un alto riego de fracaso y altos costos o continuar su uso asumiendo los costos de mantenimiento, también la opción de la modificación en pro de mejorar su capacidad de mantenimiento, solución a corto plazo o mediante procesos de reingeniería agregar componentes que lo dinamicen para garantizar su viabilidad en un futuro. Por lo anterior no se puede generalizar el tratamiento para todos los sistemas legados y su solución, ya que dependen del contexto mismo del problema. 2.1.3 Opciones para la evolución de sistemas legado s Las alternativas para la actualización de los sistemas legados dependen en gran medida de la valoración del sistema: valor del negocio vs calidad del sistema (14), y con base en ésta decidir una estrategia para la evolución de los mismos, tales como:

13

Abandonar el sistema legado y sustituirlo por uno nuevo. Esta opción debería elegirse cuando los procesos de negocio no reciben alguna contribución por parte del sistema, por lo que se debería planear la migración del sistema legado a un nuevo sistema. Al respecto Pinheiro (15) propone un proceso para simular y determinar el comportamiento de la migración antes de hacerla operativa. Éste modelo se basa en la definición de una carga de trabajo sintética7, de la que se derivan actividades de modelamiento, experimentación, simulación y validación para predecir el comportamiento de un sistema objetivo o de destino. El proceso de simulación para la evaluación del funcionamiento de un sistema de destino se muestra en el diagrama de actividad en la Figura 3 mediante la producción de un modelo válido. En la etapa de modelamiento se específica el modelo, en la actividad de simulación se ejecuta el modelo y se producen las salidas de la simulación, que junto a los resultados de la experimentación, permiten hacer la validación

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

Si los resultados son similares el modelo se considera válido, de lo contrario se somete a una actividad de refinamiento y se vuelve a hacer la simulación, esto se

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

14

repite hasta que la diferencia de resultados entre simulación y experimentación sea escasa. El modelo validado y aceptado se pasa a la actividad de predicción del que resulta la descripción del comportamiento del nuevo sistema (15). Abandonar el sistema no significa empezar un desarrollo desde cero. No se puede pensar que los datos que contiene el legacy van a desecharse y que los valores que conservan los expertos del sistema van a perderse. El abandono del sistema debe venir precedido por una análisis exhaustivo que permitan decidir el método que se va a utilizar para la migración de la información del sistema actual al nuevo, incluyendo datos, funciones de negocio y arquitectura del sistema (16). Ésta alternativa de abandono del sistema legado tiene un riesgo inherente “el costo” y debe estar contemplado dentro del plan de migración, el cual puede mitigarse adoptando una estrategia de reemplazo evolutiva (14). Garantizar mantenimiento del sistema actual. Una definición de mantenimiento dada por ISO/IEC: “Un producto software soporta una modificación en el código y su documentación asociada para la solución de un problema o por la necesidad de una mejora. Su objetivo es mejorar el software existente manteniendo su integridad”.

Figura 4. Proceso de mantenimiento de software (14)

Se elige ésta alternativa cuando el sistema es útil a los procesos de la organización y las peticiones de cambio de los usuarios son mínimas. En dado caso Sommerville (14) propone un conjunto de actividades que conforman el proceso de mantenimiento de la Figura 4. Reingeniería del sistema actual. La reingeniería del software se refiere a la re implementación de los sistemas heredados para hacerlos más mantenibles (14). La definición dada por el Reengineering Center del Software Engineering Institute de la Universidad Carnegie Mellon es:

15

“Reingeniería es la transformación sistemática de un sistema existente a una nueva forma para realizar mejoras de la calidad en operación, capacidad del sistema, funcionalidad, rendimiento o capacidad de evolución a bajo coste, con un plan de desarrollo corto y con bajo riesgo para el cliente”. Las concepciones alrededor de la reingeniería de software son muy variadas, van desde suponer mejoras en la comprensibilidad y mantenimiento del software (14), diagnosticar y reconstruir el software, aplicación de ingeniería inversa e ingeniería directa al código existente, pero quizás la más amplia y aceptada es considerarla una forma de reutilización, que mejora la calidad y reduce el esfuerzo de llevar un sistema existente a un nuevo contexto (3). Sommerville (14), establece una distinción crítica de la reingeniería y un nuevo desarrollo en donde el sistema antiguo actúa como una especificación para el nuevo sistema. Por lo tanto, el bajo riesgo que supone partir de una base sólida y funcional de software y el coste reducido, se convierten en dos ventajas clave sobre aproximaciones más radicales a la evolución del sistema. A continuación se presentan algunos de los enfoques de la reingeniería (17):

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

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

2) Reingeniería desde una Perspectiva de sistema (17) En la reingeniería de sistemas es importante entender que el sistema operacional es sólo una parte del entorno legado total.

16

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

El modelo que guía el proceso de reingeniería propone actividades para la planeación, identificación descripción, comprensión, fortalecimiento y evaluación de factores técnicos, administrativos y del proyecto, ofreciendo un contexto para unificar la terminología de las actividades de reingeniería, difundiendo las lecciones aprendidas al respecto, como se ilustra en la Figura 6. 3) Reingeniería desde una Perspectiva evolutiva Los sistemas evolutivos se definen como sistemas que son capaces de acomodar los cambios a través de una vida útil prolongada. La tecnología que soporta los sistemas evolutivos debe habilitar la creación de sistemas que están diseñados para evolucionar y la transformación de los sistemas legados de hoy en los sistemas evolucionables. Es por esto que ésta perspectiva propone un modelo de ciclo de vida basado en una continua evolución, suponiendo que el software nunca está terminado. 4) Reingeniería desde una perspectiva del software En esta perspectiva Sommerville (14) propone una metodología que define varias tareas y es descrita en la Figura 7. Inicialmente, se hace una traducción del código fuente a otro lenguaje o por lo menos a una versión actualizada.

17

Figura 7 . Proceso de reingeniería, propuesto por S ommerville (14)

La reingeniería de software se puede hacer utilizando varias alternativas: 1) Modernización de caja blanca (16): Se fundamenta en la identificación de los componentes del sistema y sus relaciones para conseguir una representación a niveles mayores de abstracción, conocida también como ingeniería inversa; cuya ventaja es la recuperación del diseño y la funcionalidad del sistema desde el código para modernizar el lenguaje de programación o el soporte de los datos. 2) Modernización de caja negra o Wrapping8 (16): es una técnica de reingeniería en la que sólo se analizan las interfases (las entradas y salidas) del legacy ignorando los detalles internos. La reingeniería basada en wrapping puede realizarse a nivel funcional, de datos o de interfase. En cada una de ellas se emplean técnicas que se describen a continuación. Wrapping de interfases de usuario. Se busca dar mayor facilidad de operación, modernizando la interfase de usuario, a menudo usando una técnica conocida como screen scraping9, la cual envuelve la interface basada en texto con un entorno gráfico basado en GUI o en HTML. Wrapping de datos. Permite accede a los datos del legado usando una interfaz diferente a la diseñada inicialmente.

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

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

18

• Integración con tecnología XML aprovechando el intercambio de datos entre sistemas o negocios.

• Replicación de datos, esta es utilizada comúnmente para descentralizar el almacenamiento masivo de datos de los Mainframes, buscando que bases de datos locales repliquen parte de los datos centralizados.

• Capa de persistencia, ésta es construida específicamente para cada sistema, buscando el acceso de aplicaciones desarrolladas con tecnología orientada a objetos.

Wrapping funcional. Encapsula datos y funcionalidades del legado, se emplean técnicas como:

• Integración con CGI que permite el acceso al legacy usando Common Gateway Interface mediante servidores Web o HTTP.

• Object Oriented Wrapping (OOW). La tecnología de objetos distribuidos (DOT) es la combinación de la orientación a objeto con la distribución (middleware objeto) (CORBA).

• Wrapping basado en componentes. Este método utiliza el modelo de componentes distribuidos, donde la idea es separar la interface del sistema legado en módulos agrupados por unidades lógicas, buscando un punto de contacto único, a través del cual se establece la comunicación entre un EJB por ejemplo y una función concreta del sistema legado.

19

3 ARQUITECTURA E HISTORIA DE ORACLE FORMS

3.1 ¿Qué es Oracle Forms? Oracle Forms es un producto de software para la creación de pantallas que interactúan con una base de datos Oracle. Cuenta con un IDE que incluye un navegador de objetos, hoja de propiedades y editor de código que utiliza PL / SQL. Fue desarrollado originalmente para ejecutarse en el servidor en modo de sesiones de carácter terminal. Fue portado a otras plataformas, incluyendo Windows, para funcionar en un entorno cliente-servidor. Las versiones posteriores fueron portadas a Java que se ejecutan en un contenedor Java EE y puede integrarse con Java y servicios web. El enfoque principal de las formas es la creación de sistemas de entrada de datos más que el acceso a una base de datos Oracle. En la mayoría de lanzamientos de una base de datos Oracle usualmente resulta una nueva mayor versión de Oracle Forms para soportar nuevas características en la base de datos. A continuación en la Tabla 2 se muestra la evolución que ha tenido Oracle Forms gestionado por la corporación Oracle:

20

Tabla 2. Resumen de las Versiones de Oracle Forms 10

Name Version (*1)

Database Character/

GUI Comments

IAF

2 Character No IDE

FastForms+IAG

4 Character

SQL*Forms 2 5 Character

SQL*Forms 2.3 5 Character New IDE, No PLSQL, User Exits, INP ASCII File, FRM Runtime File

SQL*Forms 3 6 Character Major Rewrite, New IDE, PLSQL, X Support, Generate code to enforce constraints

Oracle Forms 4.0 6-7 Gui /

Character 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.5 7 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.

Oracle Forms 5 7 Gui /

Character

Oracle Forms 6 8 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.

Oracle Forms 6i 8 Gui /

Character

Oracle Forms 9i (*2) 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.

Oracle Forms 10g 10g Gui This is a Forms 9 release (9.0.4.0.19). Renamed externally to indicate support for 10g database. Menu-Help-About displays v9.0.4.0.19. Not forward compatible with 10gr2 (cant open 10gr2 forms in 10g/904)

Oracle Forms 10gr2 10gr2 Gui version 10.1.2.0.2 - registry home key moved. Max NUMBER length reduced from 40 to 38

Oracle Forms 11g 11g GUI (*1) Cada versión de Oracle Forms puede conectarse a numerosas versiones de bases de datos ORACLE y es vendido y lanzado separadamente de la Base de Datos ORACLE. Oracle Forms es generalmente compatible con versiones posteriores y anteriores de la Base de Datos ORACLE, por ejemplo: Oracle Forms 9 puede conectarse a menores versiones Oracle 8, 9, 10 y 11. Las versiones de bases de datos listadas aquí son las versiones primarias que estuvieron disponibles en el momento del lanzamiento de Forms.

(*2) Los productos Oracle históricamente han seguido su propia numeración-release y convenciones de nombrado. Esto cambió con Oracle RDBMS 9i release cuando Oracle Corporation inició la estandarización de Oracle Forms (y Reports y Developer) para usar el mismo mayor número de versión que la base de datos. Esto explica el salto en Oracle Forms versiones desde 6i a 9i (no hubo v7 o v8).

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

21

3.2 ¿Cómo funciona Oracle Forms? 11 Oracle Forms accede a la base de datos Oracle y genera una pantalla que presenta los datos. La forma de código fuente (*.FMB) se compila en un "ejecutable" (*.FMX), que se ejecuta (interpreta) por el módulo de tiempo de ejecución de las formas. El formulario se utiliza para ver y editar datos en aplicaciones con bases de datos. Varios elementos de la GUI, como botones, menús, barras de desplazamiento, y los gráficos se pueden colocar en el formulario. El entorno provee la creación integrada de registros, modo de consulta y actualización, cada uno con sus propios manipuladores de datos por defecto. Esto reduce al mínimo la necesidad de las operaciones comunes y tediosas de programar, como la creación de SQL dinámicos, detección de campos modificados, y el bloqueo filas. Como es normal con las interfaces orientadas a eventos, el software implementa las funciones de control de eventos llamados disparadores o triggers que se invocan automáticamente en las etapas críticas en el procesamiento de registros, la recepción de las pulsaciones del teclado, y la recepción de los movimientos del ratón. Existen diferentes disparadores o triggers que pueden ser llamados antes, durante y después de cada paso crítico. Cada función de trigger inicialmente es un bloque, con una acción predeterminada o nada. La programación Oracle Forms por lo tanto generalmente consiste en modificar el contenido de estos disparadores, a fin de modificar el comportamiento predeterminado. Algunos triggers, si se proporciona por el programador, sustituye la acción por defecto, mientras que otros aumentan. Como resultado de esta estrategia, es posible crear una serie de diseños o layouts de forma predeterminada que posean la funcionalidad de base de datos completa a pesar de que no haya del todo código escrito por el programador.

3.3 Integración con herramientas CASE de Oracle Designer

Oracle Designer es una herramienta CASE capaz de generar diversos módulos de software incluyendo Oracle Forms y Oracle Reports. 3.3.1 Características de los Formularios o Formas e n Oracle

Forms.

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

22

Cuando se crea un módulo de formulario en Oracle Forms Designer (Ver Figura 8), se trabaja con varios objetos específicos para formar módulos (18), que incluyen: Window: Una ventana es, por sí mismo, un marco vacío. Tiene una barra de título y se ocupa de la interacción, permitiendo a los usuarios finales para desplazarse, mover y cambiar el tamaño de la ventana. Canvas: Son objetos de fondo sobre el que se colocan los objetos de interfaz y los elementos gráficos que los usuarios finales interactúan al usar una aplicación Forms Builder. Block: Los bloques son contenedores lógicos para los elementos de Forms Builder, y son la unidad básica de información en un módulo de formulario. Un módulo de formulario contiene normalmente varios bloques. Item: Son objetos de la interfaz que muestran información a los usuarios finales y les permiten interactuar con la aplicación. Cuando se crea un bloque de datos, se vincula las columnas de la tabla o vista con objetos de la interface de Forms Builder. Ver Figura 9.

Figura 8. Elementos Forms

23

En tiempo de ejecución, los usuarios finales podrán manipular elementos de la interfaz en el módulo de datos para consultar, insertar, actualizar y eliminar registros de datos en la base de datos. Un bloque de datos automáticamente incluye una funcionalidad para apoyar estas interacciones con la tabla o vista a la que corresponda el bloque. 3.3.2 Lógica de aplicaciones en Oracle Forms y Orac le Reports Oracle Forms y Oracle Reports dispone de elementos para el manejo de la lógica de las aplicaciones, tales como Unidades de Programa o Program Units, bibliotecas o libraries y triggers de base de datos. Ésta lógica puede distribuirse tanto en el cliente como en el servidor de PL/SQL. Ver Figura 10 y Figura 11.

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

Figura 9. Relación entre Tablas o Vistas con Bloques de Dat os

3.4 Arquitectura de las aplicaciones Oracle Forms Para Oracle Forms6i,cliente/servidor, como se muestra en la Engine y toda la lógica usuario. Toda la interfaz de usuario y el procesamiento de triggers cliente, excepto para los triggers estar incluida del lado del servidor de

Figura 11. Forms Server Posteriormente, Oracle lanza una ostensible mejora en la arquitectura de su producto Oracle Forms, en el que iparte de la lógica de las aplicaciones. Éste producto llamado Oracle Forms 10g presenta una arquitectura de tres aplicación: Cliente, Servidor de Aplicaciones y Servidor de BaServidor de Aplicaciones, ahora es el componente responsable de ejecutar toda la lógica de las aplicaciones contenidas en los Program Units, triggers, librerías además de contener el Forms Runtime Engine para el procesamiento. VerFigura 12.

24

Arquitectura de las aplicaciones Oracle Forms

Para Oracle Forms6i, la implementación es basada en cliente/servidor, como se muestra en la Figura 11, el Forms Server Runtime

y toda la lógica de la aplicación está instalada en el computador del usuario. Toda la interfaz de usuario y el procesamiento de triggers cliente, excepto para los triggers y la lógica de algunas aplicaciones que podría

del lado del servidor de base de datos (19).

Forms Server basad o en una arquitectura cliente/servidor

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

Arquitectura de las aplicaciones Oracle Forms

basada en una arquitectura Forms Server Runtime

á instalada en el computador del usuario. Toda la interfaz de usuario y el procesamiento de triggers ocurren en el

y la lógica de algunas aplicaciones que podría

o en una arquitectura cliente/servidor

Posteriormente, Oracle lanza una ostensible mejora en la arquitectura de su ncluye el componente que desacopla gran

parte de la lógica de las aplicaciones. Éste producto llamado Oracle Forms 10g en las que se distribuye toda la

aplicación: Cliente, Servidor de Aplicaciones y Servidor de Base de Datos. El Servidor de Aplicaciones, ahora es el componente responsable de ejecutar toda la lógica de las aplicaciones contenidas en los Program Units, triggers, librerías además de contener el Forms Runtime Engine para el procesamiento. Ver

25

Figura 12. Arquitectura de Oracle Forms 10g en adel ante A pesar del esfuerzo de Oracle por mejorar características de rendimiento, escalabilidad y balanceos de carga en las aplicaciones Oracle Forms (actualmente con Release de Oracle Forms 11g), persiste actualmente la forma de desarrollar las aplicaciones Oracle Forms las cuales son construidas como un “bulto” homogenizado de lógica de negocio e Interfaz de usuario (UI) (20). Éste nivel de acoplamiento con el que han sido desarrolladas muchas de las aplicaciones de las organizaciones, en el que la lógica de negocio convive con la presentación hace que el costo por mantenerlas sea cada vez mayor; logrando que en un punto sean analizadas con detenimiento para evaluarlas en el contexto tecnológico actual y de su valor al negocio para así darles el tratamiento adecuado en pro de los objetivos de las empresas.

3.5 Aplicaciones Oracle Forms como aplicaciones legadas

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

26

Tabla 3 Fechas relevantes de Soporte Producto Fin de Soporte de

Corrección de Errores Fin de Soporte

Extendido

Oracle Forms, Reports y Designer 6i

31/01/2005 31/01/2008

Oracle9i Developer Suite (9.0.2) Igual que Oracle9i Application Server v9.0.2

01/07/2005 01/07/2008

Oracle9i Developer Suite y Application Server 10g (9.0.4)

Igual que Oracle9i Application Server 10g (9.0.4)

31/12/2006 31/12/2009

Oracle9i Developer Suite y Application Server 10g (10.1.2) Phase 2

Igual que Oracle Application Server.

31/12/2011

Futuros releases de Oracle Developer Suite y Application Server

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 evolución y adaptación a nuevos entornos tecnológicos.

Figura 13. Ciclo de Vida de Oracle Forms

Tal y como se describió en el capítulo 2.1, relacionado los sistemas legados, no por el simple hecho de que una aplicación haya sido desarrollada con una tecnología deprecada, tal como Oracle Forms6i, debiera ser considerada como

aplicación legada; no obstante el mensaje de Oracle por descontinuar el uso déstas tecnologías. Ver Dependiendo del valor agregado que tenga una aplicación desarrollada con tecnología Oracle Forms para el negocio y la necesidad de integración con otras aplicaciones con su respectivo riegono. Se puede tomar como referencia la relación de las variables que se muestran en la Figura su continuidad y disponibilidad durante el tiempocomo la disponibilidad de soporte en hardware y software), y la determinación de continuar con la operación de los procesos soportados en el sistema, permite tomar una decisión sobre la estrategia adecuada para evolucionar

Figura 14. Aspectos considerados para valoración de un sistema Al respecto, Oracle considera los cuales ha seguido la siguiente ruta evolOracle Forms:

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

27

no obstante el mensaje de Oracle por descontinuar el uso déstas tecnologías. Ver Figura 13.

Dependiendo del valor agregado que tenga una aplicación desarrollada con tecnología Oracle Forms para el negocio y la necesidad de integración con otras

con su respectivo riego, se puede considerar su modernización o Se puede tomar como referencia la relación de las variables que se

Figura 14. Se consideran aspectos necesarios para garantizar su continuidad y disponibilidad durante el tiempo (aspectos que incluyen factores como la disponibilidad de soporte en hardware y software), y la determinación de continuar con la operación de los procesos soportados en el sistema, permite tomar una decisión sobre la estrategia adecuada para evolucionar

Aspectos considerados para valoración de un sistema

Al respecto, Oracle considera a sus productos como activos en evolución para los cuales ha seguido la siguiente ruta evolutiva específicamente para

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

no obstante el mensaje de Oracle por descontinuar el uso de

Dependiendo del valor agregado que tenga una aplicación desarrollada con tecnología Oracle Forms para el negocio y la necesidad de integración con otras

puede considerar su modernización o Se puede tomar como referencia la relación de las variables que se

consideran aspectos necesarios para garantizar (aspectos que incluyen factores

como la disponibilidad de soporte en hardware y software), y la determinación de continuar con la operación de los procesos soportados en el sistema, permite tomar una decisión sobre la estrategia adecuada para evolucionar el sistema (2).

Aspectos considerados para valoración de un sistema

sus productos como activos en evolución para utiva específicamente para la línea de

Ésta figura muestra la evolución que han tenido los productos desde sus inicios como aplicaciones en modo bloque, pasando a aplicaciones en modo carácter,

n la innovadora arquitectura

28

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

4 ARQUITECTURA DE SOFTWARE En el marco de desarrollo del presente trabajo, serán consideradas dos arquitecturas de software como arquitecturas objetivo de una migración de las aplicaciones Oracle Forms. Antes de ahondar en éstas dos alternativas se describe el concepto de arquitectura de software definido por Bass de la siguiente manera (21): "La arquitectura de software de un sistema o programa de computación es la estructura o estructuras del sistema, la cual comprende los componentes del software, las propiedades de esos componentes visibles externamente, y las relaciones entre ellos". La arquitectura de un sistema software puede basarse en un modelo o estilo arquitectónico particular (14). Garlan y Shaw son citados por Sommerville para definir un estilo arquitectónico como: “un patrón de organización de un sistema tal como una organización cliente-servidor o una arquitectura por capas”. Los conceptos de capa y de nivel se usan indistintamente. Sin embargo, un punto de vista bastante común es que en verdad hay una diferencia, y que una capa es un mecanismo lógico para la estructuración de los elementos que componen la solución de software, mientras que un nivel es un mecanismo de estructuración física de la infraestructura del sistema (22). A continuación se presenta dos de las arquitecturas más apropiadas que soportan un adecuado nivel de descomposición de las unidades del sistema software que una aplicación Oracle Forms6i contiene.

4.1 Arquitectura multinivel En la ingeniería de software, la arquitectura de varios niveles (a menudo denominado como la arquitectura n-tier) es una arquitectura cliente-servidor en el que la presentación, el procesamiento de la solicitud, y la gestión de datos son, lógicamente, procesos separados. Por ejemplo, una aplicación que utiliza middleware para servicios de datos de las solicitudes entre un usuario y una base de datos emplea la arquitectura de varios niveles. El uso más extendido de la arquitectura de varios niveles es la arquitectura de tres niveles. La arquitectura de una aplicación de N-tier proporciona un modelo para que los desarrolladores desarrollen una aplicación flexible y reutilizable. Al romper una aplicación en niveles, los desarrolladores sólo tienen que modificar o agregar

29

una capa específica, en lugar de tener que reescribir de nuevo toda la aplicación. Debe haber un nivel de presentación, un nivel de negocio o acceso de datos, y un nivel de datos (22). 4.1.1 Arquitectura multinivel de una aplicación web Las aplicaciones Web actualmente poseen un nivel de desacoplamiento de sus componentes gracias en medida a la maduración de marcos de trabajo que permiten el despliegue de los mismos mediante las ventajas de la computación distribuida. Los datos y la lógica de negocios pueden compartirse entre clientes tanto automatizados como GUI. Las únicas diferencias estarán dadas en la naturaleza del cliente y la capa Presentation (presentación) del nivel medio. Además, la separación entre la lógica de negocios y el acceso a los datos posibilita la independencia de las bases de datos y proporciona la capacidad de complementación que permite el uso de diversos tipos de almacenamiento de datos (23).

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

El funcionamiento de los componentes de una arquitectura multinivel es explicado por Bruce Sun, en su artículo de developerWorks (23), de la siguiente manera:

30

El cliente del navegador Web de la Figura 15 actúa como un front-end GUI al brindar funciones de visualización usando HTML generado por el Browser Request Handler en la capa Presentation. El Browser Requester Handler puede implementarse usando modelos MVC (algunos ejemplos Java son: JSF, Struts o Spring). Éste acepta la solicitud del navegador, solicita el servicio a la capa Business Logic, genera la presentación y le responde al navegador. La presentación debe mostrarse al usuario mediante el navegador y no contendrá únicamente el contenido, sino también los atributos de visualización como HTML y CSS. Las reglas de negocios se centralizan en la capa Business Logic, la cual cumple la función de intermediario en el intercambio de datos entre la capa Presentation y la capa Data Access. Los datos se proporcionan a la capa Presentation como objetos de dominio u objetos de valor. Desacoplar el Browser Request Handler y el Resource Request Handler de la capa Business Logic ayuda a facilitar la reutilización de códigos y conlleva a una arquitectura flexible y extensible. Además, a medida que van surgiendo nuevos frameworks REST y MVC, se simplifica cada vez más la implementación sin que sea necesario reescribir la capa Business Logic. La capa Data Access brinda el nivel de almacenamiento de datos a la interfaz y puede implementarse usando el patrón de diseño DAO o bien soluciones de mapeo relacional de objetos como Hibernate, OJB o iBATIS. Otra alternativa es implementar los componentes de la capa Business y la capa Data Access como componentes EJB con soporte de un contenedor EJB que facilite el ciclo de vida de los componentes y gestione la persistencia, las transacciones y las asignaciones de recursos. Sin embargo, esta opción requiere de un servidor de aplicaciones conforme a Java EE como, por ejemplo, JBoss y no funcionaría con Tomcat. La gran ventaja de esta capa está dada en la separación del código de acceso a datos de la lógica de negocios la cual permite el uso de tecnologías de almacenamiento de datos dispares. La capa Data Access también puede actuar como un punto de integración para la vinculación con otros sistemas, incluso en casos de clientes de otros servicios Web. El nivel de almacenamiento de datos abarca sistemas de bases de datos, servidores LDAP, sistemas de archivos y sistemas de información empresarial como sistemas legado, sistemas de procesamiento de transacciones y sistemas de planificación de recursos empresariales. Sun, concluye la descripción del anterior “estilo” arquitectónico de sistemas en red como una arquitectura multinivel tanto para servicios Web como para aplicaciones Web dinámicas que conlleva a la reutilización, simpleza, extensibilidad y a una clara separación de las responsabilidades de los componentes.

31

4.2 Arquitectura multicapa El modelo de capas de una arquitectura organiza al sistema en capas, cada una de las cuales proporciona un conjunto de servicios (14). Una arquitectura multicapa particiona todo el sistema en distintas unidades funcionales: cliente, presentación, lógica de negocio e integración. Esto asegura una división clara de responsabilidades y hace que el sistema sea más mantenible y extensible (24). La capa del cliente es donde se consumen y presentan los modelos de datos. Para una aplicación Web, la capa cliente normalmente es un navegador web. Los clientes pequeños basados-en-navegador no contienen lógica de presentación; se trata en la capa de presentación. La capa de presentación expone los servicios de la capa de lógica-de-negocio a los usuarios. Sabe cómo procesar una petición de cliente, cómo interactuar con la capa de lógica-de-negocio, y cómo seleccionar la siguiente vista a mostrar. La capa de la lógica-de-negocio contiene los objetos y servicios de negocio de la aplicación. Recibe peticiones de la capa de presentación, procesa la lógica de negocio basada en las peticiones, y media en los accesos a los recursos de la capa EIS. Los componentes de la capa de lógica-de-negocio se benefician de la mayoría de los servicios a nivel de sistema como el control de seguridad, de transacciones y de recursos. La capa de integración es el puente entre la capa de lógica-de-negocio y la capa EIS. Encapsula la lógica para interactuar con la capa EIS. Algunas veces a la combinación de las capas de integración y de lógica-de-negocio se le conoce como capa central . Los datos de la aplicación persisten en la capa EIs. Contiene bases de datos relacionales, bases de datos orientadas a objetos, y sistemas antiguos. 4.2.1 Patrón de diseño Model-View-Controller (MVC) MVC es un patrón de diseño que considera dividir una aplicación en tres módulos claramente identificables y con funcionalidad bien definida: El Modelo, las Vistas y el Controlador. MVC es el patrón de diseño arquitectural que separa los conceptos de diseño, y por lo tanto decrementa la duplicación de código, el centralizamiento del control y hace que la aplicación sea más extensible.

32

Figura 16. Relación entre los módulos del patrón MV C

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

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

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

33

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

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

34

5 GUIA DE MIGRACIÓN DE SISTEMAS LEGADOS Oracle Forms6i HACIA UNA ARQUITECTURA MULTICAPA

En el presente documento de tesis, se incluyeron algunas definiciones que se consideran complemento del marco teórico tales como las pautas de migración de sistemas legados y el concepto de modernización, los cuales se mencionan dentro de este capítulo y no como antecesores al soporte teórico de la investigación. INTRODUCCION Los sistemas legados son el resultado de muchos años de experiencia combinada, el desarrollo y la personalización además de la acogida de los procesos de negocio básicos que se siguen para proporcionar una ventaja competitiva. Esto, combinado con la fiabilidad y la estabilidad de estos sistemas que en la mayoría de casos son de escaso valor y de alto riesgo para la organización los hace candidatos de un plan de sustitución. El reemplazo y la reescritura son necesarios en ciertos casos, pero si la aplicación legada existente satisface las actuales necesidades de negocio, lo más probable es que este legado pueda ser transformado efectivamente para satisfacer las necesidades de la empresa en el futuro (11). La Guía de Migración por sí sola, no constituye un activo para un proyecto de reingeniería, el cual requiere mínimamente un proceso que lo gestione y un lineamiento claro a seguir dado por la metodología que se adapte a las características del proyecto. La ruta o camino de migración de preferencia que se desee tomar es influenciada por el lugar que se desee estar. Si la motivación para considerar una migración a una tecnología diferente, es explotar las características y el poder de ese objetivo, entonces se debe estar dispuesto a hacer grandes cambios de arquitectura. Bajo esta perspectiva, la presente guía se constituye en una herramienta de orientación en la elaboración de planes de reingeniería de aplicaciones legadas Oracle Forms6i, teniendo en cuenta los riesgos de los proyectos e incluyendo el punto de vista específico de la tecnología a migrar con su arquitectura objetivo. CONTENIDO DE LA GUÍA La guía se dirige a dos grupos distintos. Un grupo se compone de los responsables a cargo de la planificación e implementación de las estrategias y proyectos de las TI. El segundo grupo lo forman los Administradores TI en las organizaciones que gestionan proyectos de desarrollo o migración de

35

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

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

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

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

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

Todas las organizaciones quieren conseguir el mayor valor de negocio posible de sus inversiones existentes en infraestructura de TI y aplicaciones software. Pero en muchos casos, estos sistemas se han mantenido durante muchos años - es decir, se trata de "sistemas legados" que son importantes para la empresa, pero a menudo son difíciles de entender y mantener. Por razones presupuestales, el re-desarrollo de estos sistemas desde cero puede ser una mala opción. A menudo, estos sistemas no solo han superado la vida útil de sus componentes software sino también de su hardware por lo que se hacen costosos de mantener. La solución es la migración del sistema legado a una nueva plataforma (hardware o software), conservando gran parte del software existente, por supuesto si el valor del sistema para el negocio es alto. Para el caso de este texto, una aplicación desarrollada para un entorno cliente-servidor con tecnología Oracle Forms6i actualmente se abren varias posibilidades de migración, las cuales implican adicionar un nuevo comportamiento de dominio específico y la adaptación del sistema legado a una plataforma tecnológica diferente. La migración tiene un valor específico del dominio menos tangible,

36

pero de no hacerla de una manera oportuna y eficiente puede traer perjuicios para la organización. 5.1.1 Definiciones importantes y recomendaciones ge nerales de

migración Un punto de vista general sobre guías de migración debe considerar aspectos de gestión y control tanto como los aspectos técnicos. Al respecto, el SEI propone una serie de guías de migración de sistemas legados (21), en las que se consideran los siguientes aspectos más relevantes12: a) Identificar y desarrollar una estrategia global con metas alcanzables y

medibles para el proyecto de reingeniería. Desarrollar planes de contingencia para la instalación de nuevos sistemas.

� Mantener las operaciones paralelas e instalaciones independientes de pruebas para sistemas grandes y complejos.

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

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

� Gestionar un cambio significativo a un nuevo sistema o mejoras

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

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

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

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

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

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

37

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

� Estar preparado para hacer frente a situaciones disfuncionales, por

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

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

sistema legado

Los siguientes son los tipos específicos de orientación para mantener el sistema legado bajo control:

� Cuidadoso seguimiento de los datos históricos y mantener los parámetros precisos para que las estimaciones sean precisas, más que supuestas.

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

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

d) Hacer de la arquitectura de software una conside ración primaria de

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

� Asegurar que haya un entendimiento común y la representación de la arquitectura entre todos los interesados.

� Asegurar la inclusión de evaluaciones de arquitectura de software

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

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

Se debe separar el proceso de reingeniería del proceso de desarrollo, a continuación unas consideraciones al respecto:

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

utilice un proceso de ciclo de vida genérico.

38

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

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

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

5.1.2 Recomendaciones Específicas de migración Oracle

Forms6i Con las pautas anteriores, la “Guía de migración de Sistemas Legados Oracle Forms6i” que se pretende con el presente trabajo, se debe complementar con el punto de vista de la propia firma propietaria de la tecnología en cuanto a las posibilidades de evolución de la misma. Al respecto, Oracle recomienda la “Modernización” (26), concepto de IT que se basa en un requisito fundamental de hacer negocios en el siglo XXI: maximizar la eficiencia al tiempo que aumenta la ventaja competitiva. “La modernización es el proceso de evolución de las tecnologías restrictivas, tecnologías legadas a nuevas tecnologías basadas en estándares abiertos, mientras que se conserva la lógica de negocio y los datos de los sistemas legados.” ¿Por qué se debe considerar la Modernización? Oracle recomienda una variedad de enfoques de modernización de TI13 como apoyo para la compleja variedad de desafíos en la modernización de sistemas legados. Estos enfoques incluyen:

• Sustitución de las aplicaciones legadas existentes con empaquetado, Aplicaciones Comerciales disponibles en el Mercado (COTS).

• Re-arquitectura de aplicaciones legadas.

• Habilita la arquitectura orientada a servicios (SOA).

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

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

• Reubica la lógica de la aplicación y los datos, intactos, a una plataforma más abierta, rentable, y ágil.

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

39

Una combinación de estos enfoques normalmente se requiere para proporcionar una solución completa a los problemas de negocios. Oracle también recomienda (27) a los clientes de Forms, Reports y Designer que sigan un camino similar al que Oracle realizó con su E-Business Suite:

• Migrar a tecnología de Internet. • Interoperar y hacer coexistir estas aplicaciones con nuevas aplicaciones

Java Enterprise Edition usando Oracle WebLogic Application Server. • Para clientes con nuevos requerimientos la plataforma Java Enterprise

Edition proporciona un nuevo y completo conjunto de funcionalidades anteriormente no disponible para el desarrollador. Oracle Jdeveloper con ADF es la herramienta más adecuada para los clientes de Forms, Reports y Designer, debido a su similar modelo de desarrollo. Sin embargo, dadas las diferencias en arquitectura entre Java Enterprise Edition y Forms, Oracle no planea ofrecer una solución de migración que migre aplicaciones construidas con estas herramientas a JEE.

5.2 Descripción técnica de las fases de migración Tomando en cuenta las recomendaciones expuestas en el apartado anterior 5.1, antes de definir fases de migración se debe procurar establecer un proyecto marco de migración en donde se valore en primera instancia el sistema legado que se va a migrar y, posteriormente, ajustar el proyecto bajo las características de la reingeniería. 5.2.1 Consideraciones de la valoración del sistema legado Un sistema legado ha sido definido como un sistema que "... de manera significativa se resiste a la modificación y evolución para satisfacer las necesidades de nuevos y constantes cambios en los requerimientos del negocio." Por lo general, implica que el entorno en el que convive es igualmente heterogéneo. Ver Figura 18.

40

Figura 18 . Una común Infraestructura de TI legada

Uno de los retos de TI que puede ser observado del anterior diagrama es que la mayoría de las aplicaciones se comunican directamente entre sí. Esta dependencia puede convertirse en un verdadero problema cuando una aplicación tiene que ser modificada o eliminada. Cualquier modificación puede llevar a la actualización de cada línea de comunicación a su manera única. Por lo tanto, estos cambios pueden llegar a ser un esfuerzo costoso. Esta situación se denomina alto acoplamiento entre las aplicaciones y se está convirtiendo en un verdadero dolor de cabeza para algunas empresas, pues estos entornos tecnológicos promueven el deterioro de las aplicaciones convirtiéndolas en legadas. Características a valorar del sistema legado Oracl e Forms6i En éste punto se supone que el sistema legado representa un importante activo para la organización y que realmente vale la pena volver a usar en un nuevo entorno tecnológico. Así que el valor del actual activo debe ser valorado:

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

Desafortunadamente, lo más difícil del análisis del legado es captar en su totalidad su funcionalidad, debido a que generalmente la documentación asociada del software no existe o es obsoleta, y el diseño requiere recuperarse aplicando ingeniería inversa, a veces desde el propio código. Al establecer el

41

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

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

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

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

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

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

42

Plan de Proyecto, que muestra los principales hitos y lo que se desea lograr, tal vez iteraciones y sus objetivos específicos, y una Lista de Riesgos. También se necesita un Caso de Negocio, para poder hablar sobre los beneficios de hacer el proyecto y el enfoque que tomará. Este Caso de Negocio se basará en una estimación de los costes: el personal y otros requisitos (herramientas, middleware, formación), que, a su vez, dependerá de la magnitud del trabajo que esté por hacer. A medida que avance hacia la fase de transición, se necesita un Plan de Implementación, que muestra cómo el nuevo sistema se implementará, en sustitución del antiguo. 5.3.2 Sub-proyecto de ingeniería inversa Usualmente la documentación de las aplicaciones legadas, así como también las aplicaciones legadas Oracle Forms6i, no la tienen y si la tienen es una documentación escasa o poco fiable. Por lo tanto el objetivo del sub-proyecto de ingeniería inversa será el de reconstruir con UML algunos modelos que en conjunto proporcionen la vista arquitectónica del sistema legado Oracle Forms6i para identificarlos posteriormente en el plan de migración. Como el objetivo de ésta guía no es detallar el plan del proyecto de ingeniería inversa, a continuación se presenta el resumen de las actividades propuestas (28) para el manejo del proyecto de ingeniería inversa con la metodología RUP:

A. Valorar el alcance del proyecto de reingeniería. B. Construcción de los modelos abstractos. C. Recuperar la arquitectura del software legado

43

Figura 19. Pasos claves para el mapeo de las discip linas y fases de RUP 14 Paso 1. Valorar el alcance del proyecto de reingeni ería. A continuación se mencionan algunas de las tareas de éste paso que se recomiendan:

• Establecer el alcance del negocio y los atributos de calidad deseados del sistema legado objeto de reingeniería.

• Desarrollar el documento de Visión del Proyecto: acá estará definida la arquitectura objetivo de la migración, para nuestro caso una arquitectura multicapa JEE con ADF.

• Encontrar actores y Casos de Uso. • Identificar y valorar el riesgo • Desarrollo de casos de negocio.

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

44

Paso 2. Construcción de los modelos abstractos. Presunción : Se tiene a la mano el código fuente del sistema legado Oracle Forms6i, que servirá de punto de partida para la construcción de los modelos abstractos. En éste segundo paso, se involucran los roles del diseñador de negocio y base de datos, junto con el analista de sistemas, quienes tendrán que ejecutar las tareas de la fase de Concepción y Elaboración. En la Figura 20 se muestra la responsabilidad del diseñador de negocio en la ejecución de las tareas de detallar un caso de uso de negocio, entidad de negocio y encontrar trabajadores y entidades de negocio.

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

Figura 21. Analizar la arquitectura de la actual ba se de datos

45

A continuación, se presenta un resumen de la relación de roles y tareas de los pasos que involucran la construcción de modelos abstractos del sistema legado. Tabla 4. Tareas para cada rol involucrado en la con strucción de modelos abstractos

Rol Tarea

Diseñador de Procesos de Negocio

Detallar un Caso de Uso de Negocio

Encontrar Trabajadores y Entidades de Negocio

Detallar una Entidad de Negocio

Diseñador de Base de Datos Análisis de la Base de Datos

Analista de Sistemas Encontrar Actores y Casos de Uso

Arquitecto de Software Prioriza los Casos de Uso

Administrador del Proyecto Valorar la Iteración

Especificador de Requerimientos Detalla el Caso de Uso

Como resultado final de éste paso, se espera contar como producto de trabajo una estructura abstracta del sistema legado: el Modelo de Análisis de Casos de Uso y sus enlaces de trazabilidad para otros elementos del modelo. Paso 3. Recuperar la arquitectura del sistema softw are legado. En éste último paso de la ingeniería inversa, la idea se centra en transformar el Modelo de Análisis de Casos de Uso del paso anterior y por medio de heurísticas lograr llegar al Documento de Arquitectura de Software. El resumen del Paso 3, se muestra en la Tabla 5 incluyendo la relación de las tareas y los roles quienes las ejecutan. Tabla 5. Tareas para cada rol involucrado en recupe rar la arquitectura del sistema legado

Rol Tarea

Arquitecto de Software Analizar el Modelo Implementado

Analista de Casos de Uso Define la Ejecución Detallada

Ejecuta los Casos de Uso

Analista de Implementación

Analiza el Grafo de Llamadas

Mapea Funciones para implementar el Modelo

Valida la Arquitectura Hipotética

Arquitecto de Software Reconstruye la Arquitectura de Alto Nivel

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

46

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

Como resultado de este paso, podemos esbozar la estructura de alto nivel del código de acuerdo a la agrupación que posteriormente se mapearían en las clases de la nueva plataforma arquitectónica multicapa o en una capa de lógica en la base de datos según su conveniencia. En éste punto cabe hacer la anotación que estas agrupaciones han permanecido en constante modificación durante los años de mantenimiento del sistema. El resultado de esta tarea se registra en una versión actualizada del Documento de Arquitectura de Software. 5.3.3 Sub-proyecto de desarrollo Ésta sección agrupa los conceptos de forward engineering para el establecimiento del proyecto de desarrollo y evolución del sistema legado Oracle Forms6i, tomando como insumos los productos de trabajo del proyecto de ingeniería inversa descrito en la sección anterior. Establecimiento de una Línea Base Para ir más allá de simplemente aplicar el ciclo de vida propuesto por RUP y el uso de algunas de las disciplinas de progreso de RUP, es necesario establecer un punto de partida. Se debe identificar un conjunto mínimo de objetos básicos que describen el sistema legado (éstos serían los modelos generados de la sección anterior). Dependiendo del alcance de la evolución, puede que se necesite más o menos de:

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

Una vez se haya establecido la Línea Base de los artefactos RUP, se puede proceder con el proyecto del sistema legado como si fuera un ciclo Evolutivo de RUP. Directriz del Proyecto de Migración De acuerdo a las recomendaciones de Oracle, expuestas en la sección 5.1.2, para lograr una evolución adecuada y probada de las aplicaciones Oracle Forms6i se definirá la arquitectura objetivo multicapa con el estilo arquitectónico MVC, desarrollo basado en JEE usando JDeveloper y ADF los cuales permiten la integración de componentes software sobre el Servidor de Aplicaciones; es decir un entorno tecnológico favorable a las necesidades del negocio.

47

JEE promete a largo plazo un mantenimiento más fácil para las aplicaciones a través de estándares abiertos, simplificando la conectividad con productos externos. Sin embargo, para todos los beneficios que trae, JEE les parece a los desarrolladores de bases de datos como extremadamente complejo y difícil. Los desarrolladores de Oracle Forms (en general, desarrolladores 4GL) se utilizan para una productividad muy alta, la cual no puede ser igualada en el mundo JEE: es difícil ofrecer a los clientes el mismo tiempo de desarrollo rápido que estuvieron usando. Este es el por qué Oracle recomienda Application Development Framework (ADF) como la solución para facilitar el desafío de implementar patrones de diseño JEE (Model View Controller, MVC) con su entorno visual y declarativo que minimiza la necesidad de escribir código. El desafío de la migración En primera medida, es realmente importante que la ejecución del proyecto de ingeniería inversa propuesto en la sección anterior de la guía se realice. Esto garantizaría un entendimiento de la aplicación Forms que necesita s er reescrita , en toda su complejidad. En segunda instancia, los miembros del equipo con roles de desarrolladores, deben tener un profundo conocimiento de la nueva tecnología , y adaptar todas las funcionalidades en la nueva arquitectura, mientras incluso mejora la aplicación. Éste segundo desafío es importante porque JEE y Forms son fundamentalmente diferentes. Además el cambio de la aplicación es exitoso cuando la nueva versión ofrece una mejor experiencia de usuario y posee unas capacidades tecnológicas superiores. Después de todo, cuando se invierte en un proceso de modernización no se querrá un clon de la aplicación legada inicial. Como tercer desafío, está el establecimiento del proceso de administración del proyecto para programar y monitorear el progreso durante la transición. Éste desafío es de gran importancia ya que los proyectos de software basados en una nueva tecnología a menudo fracasan causado por imprevistos en la implementación, falta de experiencia, y falta de estándares de implementación. La gestión del proyecto necesita monitorear continuamente el cronograma de actividades, limitaciones de calidad y presupuesto aplicado a los esfuerzos por asegurar un inicio de proyecto exitoso. Interface de Usuario Adaptarse a las fortalezas y debilidades del modelo web: para incrementar la accesibilidad ofrecida por las nuevas interfaces de usuario, las aplicaciones basadas en navegadores también tienen sus limitaciones. Oracle Forms ofrece una arquitectura de datos muy eficiente, capaz de consultar y mostrar en un applet miles de registros a la vez, cientos de campos en una sola página, acceder a la computadora del cliente y ejecutar comandos de host o acceso a archivos. Por ello, una aplicación de Forms típica necesita ser rediseñada para ser capaz de ejecutarse en un navegador sencillo, mostrando conjuntos de

48

pocos registros a la vez, la distribución de los cientos de campos en varias páginas o reducir el grado en que afectan a la computadora cliente. Lógica de Negocios Las aplicaciones de Forms son altamente acopladas, de acuerdo al capítulo 2.1.2, y en una misma unidad de código puede contener lógica de negocio con acciones como: acciones de interfaz de usuario, validación de datos, manipulación de datos, etc. Cuando se toma este código para ADF, se requiere separar la lógica de negocio dentro de sus componentes, y redefinirla de acuerdo al patrón de diseño MVC, con el fin de crear una verdadera arquitectura ADF.

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

Las posibles soluciones para manejar la lógica de negocio15 están descritas en la Tabla 6: Tabla 6. Aproximaciones posibles para el manejo de la lógica de negocio.

TRATAMIENTO DE LA LÓGICA DE NEGOCIO

VENTAJAS DESVENTAJAS

A. Traducir el código

entero a Java

Es exitoso cuando se migra el 100% de la lógica manualmente.

Pérdida de la inversión de la lógica de negocio de Forms6i

Existencia de herramientas que automatizan la conversión de código Oracle Forms a Java

El código resultante es secuencial y procedimental, como PL/SQL, pero ciertamente no es Orientado a Objetos como se supone.

El código migrado automáticamente es difícil de entender y no es reconocido como un estándar java, lo que conlleva a más mantenimiento en caso de alguna mejora.

La lógica que se logre migrar pertenece más al nivel de la Base de Datos Oracle que al nivel del cliente

15 Tomado de Professional IT Software Services - PITSS.com

49

B. Dejar el código en

PL/SQL y colocarlo

en la Base de

Datos

El acceso a datos o el código de manipulación de datos es generalmente más rápido en la Base de Datos.

No todos los artefactos son apropiados para el uso en la Base de Datos: Código de Interfaz de Usuario como reglas de navegación, validación de campos pertenecen más al nivel del cliente. Reducción de riesgo

Aumento del desempeño de la aplicación porque minimiza el tráfico de la red.

C. Una aproximación

mixta

El código de Interfaz de Usuario en Java, y el código de manipulación de datos en la base de datos.

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

� Recuperación del Modelo Arquitectónico del SLOF6i16 � Rediseño de los componentes del SLOF6i � Refactorización del código del SLOF6i � Regeneración Arquitectónica del SLOF6i hacia la arquitectura multicapa

JEE+ADF

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

50

Figura 23. Arquitectura de Migración de Aplicacione s Forms hacia JEE+ADF La mayor parte de la lógica de negocio de Oracle Forms está manejando datos. Ésta lógica naturalmente pertenece a la Base de Datos. Por lo tanto, ésta lógica de negocio será dispuesta en una Capa de Lógica de Negocio de la Base de Datos. Ver Figura 23. Luego de que el código de lógica de negocio sea migrado de las Formas y Reportes a la base de datos, esta capa podrá ser accesible por cualquier entorno de interfaz de usuario (ADF, JSP, APEX), incluso ser expuesta como servicios web. Esto garantiza la posibilidad de evolución o modernización de la aplicación o componentes individuales mucho más fácil. Una vez se haya definido la línea base mínimamente con los artefactos requeridos, el proceso de migración, involucraría las siguientes disciplinas RUP: Gestión de Requerimientos : el Modelo de Dominio ya casi estará listo por los productos de trabajo elaborados en el sub-proyecto de ingeniería inversa, aunque la posibilidad de inclusión de nuevos requerimientos o cambio de los mismos permanece, se debería estar en constante actualización del documento del Modelo de Dominio, tal y como se expuso en el aparte del proyecto de ingeniería inversa. Análisis y Diseño : En ésta etapa se definirá la estrategia dependiendo de la complejidad de la aplicación y se deberán Analizar los componentes del SLOF6i, tales como: FMB, MMB, PLL, OLB, RDF, SQL, etc. que posiblemente tendrán restricciones para adaptarlo al modelo web. De igual forma, se deberán

51

Identificar componentes obsoletos o redundantes para reducir la aplicación a puro código funcional identificando objetos redundantes: tablas sin uso, librerías, unidades de código sin uso o duplicadas, o incluso funcionalidades completas obsoletas. Implementación : Dependiendo del alcance de la migración y del estado del SLOF6i como también del resultado de las anteriores etapas y los productos de trabajo del sub-proyecto de ingeniería inversa, se prosigue con las siguientes actividades: Migrar la Lógica de Negocio a la Base de Datos. En ésta actividad es posible automatizar la migración del código haciendo uso de herramientas estandarizadas para éste propósito. Desarrollo de la Aplicación JEE+ADF elaborando:

� Servicios de Negocio � Objetos de Acceso a Datos � Detalle de las capas MVC � Métodos de Interfaz de Usuario Java

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

5.4 Conclusiones de la Guía

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

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

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

52

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

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

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

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

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

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

53

7 CONCLUSIONES

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

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

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

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

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

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

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

54

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

55

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

Elaboración Guía Capa Gómez 2010

Documents

Transcript of Elaboración Guía Capa Gómez 2010