Experimente la migración de Cobol / PL1 heredado a Java

Question

P ORIGINAL: Me pregunto si alguien ha tenido experiencia en migrar una gran base de código Cobol / PL1 a Java.

¿Cuán automatizado fue el proceso y cuán sostenible fue el resultado?

¿Cómo funcionó el cambio de transaccional a OO?

Se agradecería cualquier lección aprendida en el camino o recursos / libros blancos que puedan ser beneficiosos.

---

EDIT 7/7: Ciertamente, el enfoque de NACA es interesante, la capacidad de continuar haciendo sus cambios BAU al código COBOL hasta el momento de lanzar la versión JAVA tiene mérito para cualquier organización.

El argumento para Java procesal en el mismo diseño que COBOL para dar a los codificadores una sensación de comodidad mientras se familiariza con el lenguaje Java es un argumento válido para una gran organización con una gran base de código. Como @Didier señala, el ahorro anual de $ 3mil da margen para un relleno generoso en cualquier cambio de BAU en adelante para refactorizar el código de manera continua. Como él dice, si te preocupas por tu gente, encuentras una manera de mantenerlos felices mientras los desafías gradualmente.

El problema tal como lo veo con la sugerencia de @duffymo a

  

Lo mejor es intentar comprender realmente el   problema en sus raíces y volver a expresarlo   como un sistema orientado a objetos

es que si tiene cambios BAU en curso, durante la larga vida útil del proyecto de codificación de su nuevo sistema OO, terminará codificando & amp; probando cambios en el doble. Ese es un beneficio importante del enfoque NACA. He tenido cierta experiencia en la migración de aplicaciones Cliente-Servidor a una implementación web y este fue uno de los principales problemas que encontramos, cambiando constantemente los requisitos debido a los cambios de BAU. Hizo PM & amp; programar un verdadero desafío.

Gracias a @hhafez, cuya experiencia se presenta como " similar pero ligeramente diferente " y ha tenido una experiencia razonablemente satisfactoria de una migración automática de código de Ada a Java.

Gracias @Didier por contribuir, todavía estoy estudiando tu enfoque y si tengo alguna Q te enviaré una línea.

Answer 1

Actualización 6/25: Un amigo acaba de encontrar el Convertidor de NACA Cobol a Java. Parece bastante interesante, se utilizó para traducir 4 millones de líneas de Cobol con un 100% de precisión. Aquí está la página del proyecto de código abierto NACA . Los otros convertidores que he visto eran propietarios, y los materiales carecían notablemente de historias de éxito y código de ejemplo detallado. NACA merece una mirada larga.

Actualización 7/4: @Ira Baxter informa que la salida de Java se ve muy Cobol-esque, lo que hace absolutamente. Para mí, este es el resultado natural de la traducción automática. Dudo que alguna vez encontremos un traductor mucho mejor. Esto quizás argumenta a favor de un enfoque gradual de reescritura.

Actualización 2/7/11: @spgennard señala que hay algunos compiladores de Cobol en la JVM, por ejemplo isCobol Evolve . Estos podrían usarse para ayudar gradualmente a la transición de la base del código, aunque creo que el OP estaba más interesado en la conversión de fuente automatizada.

---

Sería muy cauteloso con esto. (Solía ??trabajar para una empresa que automáticamente corrige los programas Cobol y PL / I para Y2K, e hice el compilador front-end que convirtió muchos dialectos de Cobol en nuestra forma analítica intermedia, y también un generador de código .) Mi sensación es que terminarías con una base de código Java que aún sería poco elegante e insatisfactorio para trabajar. Puede terminar con problemas de rendimiento, dependencias en bibliotecas proporcionadas por el proveedor, código generado que tiene errores, etc. Sin duda incurrirá en una enorme factura de prueba.

Comenzar desde cero con un nuevo diseño orientado a objetos puede ser el enfoque correcto, pero también debe considerar cuidadosamente las décadas de conocimiento almacenado que representa la base del código. A menudo hay muchas sutilezas que su nuevo código puede perder. Por otro lado, si tiene dificultades para encontrar personal para mantener el sistema heredado, es posible que no tenga otra opción.

Un enfoque gradual sería actualizar primero a Cobol 97. Esto agrega orientación a objetos, de modo que puede reescribir y refactorizar subsistemas individualmente cuando agrega nueva funcionalidad. O puede reemplazar subsistemas individuales con Java recién escrito.

A veces podrá reemplazar componentes con software estándar: ayudamos a una compañía de seguros muy grande que todavía tenía 2 millones de líneas de código en un lenguaje heredado que creó en la década de 1950. Convertimos la mitad a un lenguaje heredado compatible con Y2K, y reemplazaron la otra mitad con un moderno sistema de nómina que compraron a un proveedor externo.

Answer 2

Fue claramente nuestra intención obtener el código inicial de Java que estaba muy cerca del cobol original para facilitar la migración de las personas: encuentran la buena aplicación que escribieron en cobol en la misma estructura.

uno de nuestros objetivos más importantes era mantener a los desarrolladores iniciales a bordo: esa es la forma en que encontramos para lograrlo. Cuando la aplicación migró a Java, esas personas pueden comenzar a hacerla más OO a medida que la desarrollan / refactorizan.

Si no le importa migrar personas, puede usar otra estrategia.

Esta conversión de 1 a 1 también simplificó la conversión 100% automatizada & amp; más rápido: la buena consecuencia es que hicimos nuestros ahorros recurrentes (3 millones de euros / año) mucho más rápido: estimamos 12-18 meses. Esos ahorros iniciales pueden reinvertirse claramente en la refactorización de OO

no dude en ponerse en contacto conmigo: didier.durand@publicitas.com o mediaandtech@gmail.com

didier

Answer 3

Mi experiencia es similar pero ligeramente diferente. Tenemos una base de código grande y antigua en Ada (0.5Mloc durante más de 15 años) que se convirtió recientemente a Java. Se subcontrató a una empresa que proporcionaba una combinación de conversión automática / manual. También hicieron pruebas para verificar que los sistemas Ada y Java se comportaran igual.

Algunas partes estaban escritas en Ada 95 (es decir, tenían la posibilidad de OOP) pero la mayoría no lo eran

Ahora sí, el código no cumple con los mismos estándares de código escritos en Java en primer lugar, pero lo hemos estado utilizando desde entonces con éxito (hace 18 meses) sin problemas importantes. La principal ventaja que obtuvimos fue que ahora podemos encontrar más desarrolladores para mantener nuestra base de código con las habilidades para producir código mantenible. (Cualquiera puede desarrollarse en Ada, pero como cualquier otro idioma, si no tiene la experiencia, puede terminar con un código que no se puede mantener)

Answer 4

Desde el punto de vista de evitar riesgos, el enfoque NACA tiene absolutamente sentido. Reutilizar sus herramientas podría no ser así. Utilizaron el desarrollo de las herramientas para poner a su gente al día en Java y Linux.

El resultado de la conversión de NACA no será lo suficientemente bueno, ni siquiera OO, y hace que sea difícil contratar nuevas personas. Pero es comprobable, se puede refactorizar y puede conectar mejores traductores.

[editar] Ira, no pareces ser muy consciente de los riesgos.

Enviar a los programadores de cobol a un curso de Java no los hará escribir código orientable a objetos utilizable. Eso lleva unos años. Durante ese tiempo, su productividad será muy baja, y básicamente puede tirar todo el código que escriben el primer año. Además, perderá del 10 al 20% de sus programadores, que no están dispuestos o no son capaces de hacer la transición. A mucha gente no le gusta volver al estado de principiante, y va a influir en el orden jerárquico, ya que algunos programadores aprenden el nuevo idioma mucho más rápido que otros.

El enfoque NACA permite que la empresa continúe trabajando y no ejerce una presión innecesaria sobre la organización. El horario para la conversión es independiente. Tener un traductor separado, en Java, escrito por expertos de OO, permite una exposición gradual a Java para el equipo anterior. Escribir los casos de prueba aumenta el conocimiento del dominio en el nuevo equipo de Java.

El verdadero sistema oo es el traductor, y ese es el lugar para conectar mejores traductores. Haga que sea fácil hacerlo y no tiene que tocar el código generado. Si el código generado es lo suficientemente feo, eso es lo que sucederá automáticamente: :) ??

• los viejos programadores cambiarán la entrada de cobol;
• los nuevos java cambiarán el traductor.

[ejecutando el traductor una vez] Es una mala estrategia. No hagas eso. Y si necesita editar el código generado, mantenga un mapeo de vuelta. Eso puede ser automatizado. Y debería ser. Es mucho más fácil hacer este tipo de cosas en una imagen Smalltalk, pero puede hacerlo con archivos. Hay personas con mucha experiencia manteniendo diferentes puntos de vista sobre el mismo artefacto: los diseñadores de chips vienen a la mente.

El traductor debe estar equipado para que pueda crear los recuentos diarios de, por ejemplo,

• componentes de entrada de cobol;
• OO componentes de entrada de Java;
• componentes de salida de estilo cobol;
• Componentes de salida de estilo OO.

Es posible que desee leer: Peter van den Hamer & amp; Kees Lepoeter (1996) Gestión de datos de diseño: las cinco dimensiones de marcos CAD, gestión de la configuración y gestión de datos, Actas del IEEE, vol. 84, N ° 1, enero de 1996

[moviendo plataformas Cobol] Pasar de Cobol en el mainframe a Cobol en Windows / Linux podría haber sido una estrategia viable para el equipo de NACA, pero la pregunta era acerca de mudarse a Java. Si el objetivo a largo plazo es tener un sistema OO moderno y llegar allí con el menor riesgo operativo posible, el enfoque NACA es sólido. Sin embargo, es solo el primer paso. Seguirá mucha refactorización.

Answer 5

Me sorprende que nadie haya mencionado el kit de herramientas de reingeniería de software DMS de Semantic Design. Miré en la conversión de COBOL en el pasado. Estaba trabajando en "programación automática" en aquel momento. Antes de escribir un traductor, busqué un montón de esfuerzos y productos anteriores en esa área. La herramienta basada en GLR de Semantic Designs fue la mejor del grupo.

Eso fue hace muchos años. En ese momento, la herramienta tradujo COBOL a un lenguaje moderno, lo refactorizó, lo imprimió, etc. Aquí está el enlace.

http://www.semdesigns.com/Products/DMS/DMSToolkit.html

Todavía están por aquí. Han ampliado la herramienta. Es mas general. Puede ayudar a las personas que realizan conversiones automáticas o personalizan una herramienta de conversión. Está diseñado para ser expandible y modificable de manera similar a lo que señaló Stephan. Gracias a Cyrus también por mencionar SoftwareMining. También los examinaré si me encuentro con una migración de COBOL en el futuro.

Answer 6

Estás hablando de reingeniería . Lo bueno es que mucha gente en todo el mundo intenta hacer esto. Lo malo es que hay muchos problemas con respecto a la reingeniería de aplicaciones heredadas: desde fuentes faltantes y hasta algoritmos complejos desde la construcción del compilador y los campos de teoría de grafos.

La idea de traducción automática es muy popular, hasta que intentes convertir algo. Por lo general, el resultado es horrible e imposible de mantener. Es más imposible de mantener que la complicada aplicación original. Desde mi punto de vista, cada herramienta que permite la traducción automática del lenguaje heredado al lenguaje moderno está muy orientada al marketing: dice exactamente lo que la gente quiere escuchar "traducir su aplicación de ... a Java una vez, ¡y olvidarse!" está comprando un contrato y luego comprende que depende mucho de la herramienta (¡porque no puede hacer ningún cambio en su aplicación sin ella!).

El enfoque alternativo es "comprensión": la herramienta, que le permite una comprensión muy detallada de su aplicación heredada. Y puede usarlo para mantenimiento, para documentar o para reinventar en una nueva plataforma.

Sé un poco sobre Modernization Workbench antes de que Microfocus lo comprara el año pasado y movió el desarrollo a otro país. Había una gran cantidad de herramientas de análisis complejas y una cantidad de lenguajes de destino compatibles (incluido Java). Pero ningún cliente realmente usó la generación automática de código, por lo que el desarrollo de la parte de generación se congeló. Hasta donde sé, el soporte PL / I se implementó principalmente, pero nunca se terminó. Pero aún puede intentarlo, puede ser esto lo que está buscando.

Answer 7

Acabo de mirar la página de NACA y los documentos. De su documentación:

" El Java generado utiliza una sintaxis tipo Cobol. Está lo más cerca posible de la sintaxis original de Cobol, dentro de los límites del lenguaje Java. El código generado no se parece al clásico Java nativo y no está orientado a objetos desde el punto de vista de la aplicación. Esta es una opción fuerte por diseño, para permitir una migración sin problemas de los desarrolladores de Cobol al entorno Java. El objetivo es mantener el conocimiento del negocio en manos de las personas que escribieron los programas originales de Cobol. & Quot;

No vi un ejemplo, pero la cita da un fuerte sabor del resultado. Su COBOL codificado en Java.

Siempre puedes construir un "Traductor" de un idioma a otro, por simplemente codificando un intérprete en el idioma de destino. Eso es en mi humilde opinión manera absolutamente terrible de traducir un idioma a medida que terminas con lo peor de ambos mundos: no obtienes el valor del nuevo idioma, y todavía tienes que tener conocimiento del anterior para mantener el resultado viva. (No es de extrañar que esto se llame un "Transcodificador"; nunca escuché este término antes).

El argumento para este truco es volcar los costos del mainframe. ¿Dónde está la evidencia de que los costos de trabajar en el programa convertido no pantanos los ahorros? Sospecho que la verdad es que la gente de operaciones redujo su costo al deshacerse del mainframe, y no les importó menos que las tareas de mantenimiento se volvieron más caras. Si bien eso puede ser racional para los operadores, es una estúpida elección para la organización en su conjunto.

Heaven ayuda a las personas que son víctimas de esta herramienta.

EDITAR mayo de 2010: encontré un ejemplo de la salida de NACA; uno de sus Casos de prueba. Esto es absolutamente magnífico JOBOL. Es algo bueno que están manteniendo sus programadores COBOL y no quieren contratar cualquier programador de Java. Mientras lees esto, asegúrate de recordar este es el código Java .

/*
 * NacaRTTests - Naca Tests for NacaRT support.
 *
 * Copyright (c) 2005, 2006, 2007, 2008 Publicitas SA.
 * Licensed under GPL (GPL-LICENSE.txt) license.
 */

import idea.onlinePrgEnv.OnlineProgram;
import nacaLib.varEx.*;

public class TestLong extends OnlineProgram
{
  DataSection WorkingStorage = declare.workingStorageSection();

  Var W3 = declare.level(1).occurs(10).var();
  Var V9Comp010 = declare.level(5).pic9(10).var();
  Var V9Comp014V4 = declare.level(5).pic9(14, 4).var();
  Var VX10 = declare.level(5).picX(10).var();

  public void procedureDivision()
  {
    setAssertActive(true);

    move("9876543210", VX10);
    assertIfDifferent("9876543210", VX10);

    move(VX10, V9Comp010);
    long l = V9Comp010.getLong();
    assertIfFalse(l == 9876543210L);

    multiply(1000, V9Comp010).to(V9Comp014V4);
    assertIfFalse(9876543210000L == V9Comp014V4.getLong());

    String cs = V9Comp010.toString();
    cs = V9Comp014V4.toString();
    assertIfDifferent("9876543210000.0000", V9Comp014V4);

    inc(V9Comp010);
    assertIfFalse(9876543211L == V9Comp010.getLong());

    CESM.returnTrans();
  }

Niños: Esto solo lo hacen profesionales. No intente esto en casa.