Experiência migração legado Cobol / PL1 para Java

https://stackoverflow.com/questions/1029974

06-07-2019
|

Pergunta

Q ORIGINAL: Eu estou querendo saber se alguém já teve experiência de migração de um grande Cobol / PL1 base de código para Java?

Como automatizado foi o processo e como sustentável foi a saída?

Como o movimento de transacional para OO fora do trabalho?

Qualquer lições aprendidas ao longo do caminho ou recursos / white papers que podem ser do benefício seria apreciada.

EDIT 7/7: Certamente a abordagem NACA é interessante, a capacidade de continuar a fazer o seu BAU alterações no código COBOL até o ponto de liberar a versão JAVA tem mérito para qualquer organização.

O argumento para Java processual no mesmo layout como o COBOL para dar aos programadores uma sensação de conforto enquanto familiarizar com a linguagem Java é um argumento válido para uma grande organização com uma grande base de código. Como pontos @Didier fora os US $ 3mil economia anual dá espaço para generoso preenchimento em qualquer BAU mudanças daqui para frente para refatorar o código em uma base contínua. Como ele coloca, se você se preocupa com seu povo você encontrar uma maneira de mantê-los felizes enquanto, gradualmente, desafiando-os.

O problema, a meu ver com a sugestão de @duffymo para

Melhor para tentar realmente compreender a problema em suas raízes e re expressar-it como um sistema orientado a objetos

é que se você tiver qualquer BAU mudanças em curso, em seguida, durante a vida útil do projeto LONGO de codificação do seu novo sistema OO você acaba de codificação e testar as alterações no duplo. Essa é uma grande vantagem da abordagem NACA. Eu tive alguma experiência de migração de aplicações cliente-servidor para uma aplicação web e este foi um dos principais problemas que encontramos, requisitos devido a alterações BAU em constante mudança. Fez PM & programando um verdadeiro desafio.

Graças à @hhafez que é experiência é muito bem colocar como "semelhante, mas ligeiramente diferente" e teve uma experiência razoavelmente satisfatória de uma migração automática de código a partir de Ada para Java.

Graças @Didier para contribuir, eu ainda estou estudando a sua abordagem e se eu tiver qualquer Q é que vou deixá-lo cair uma linha.

Solução

Atualização 6/25: Um amigo apenas correu em toda a NACA Cobol para conversor de Java. Looks bastante interessante, ele foi usado para traduzir linhas de 4m de Cobol com 100% de precisão. Aqui está o NACA open source página do projeto . Os outros conversores que eu vi eram proprietários, e os materiais foram conspicuamente falta histórias de sucesso e código de exemplo detalhado. NACA vale a pena um olhar longo.

Atualização 7/4: relatórios @Ira Baxter que a saída aparência Java muito Cobol-esque, que é absolutamente faz. Para mim, este é o resultado natural de tradução automática. Eu duvido que nunca vamos encontrar um tradutor muito melhor. Este, talvez, defende uma abordagem gradual re-escrever.

Atualização 2/7/11: pontos @spgennard que há alguns compiladores Cobol na JVM, por exemplo da Veryant isCOBOL Evolve . Estes poderiam ser usados ??para ajudar a transição gradual da base de código, embora eu acho que o OP estava mais interessado na conversão fonte automatizado.

Eu seria muito cauteloso sobre isso. (Eu costumava trabalhar para uma empresa que automaticamente corrigido Cobol e programas PL / I para Y2K, e fez o compilador front-end que converteu muitos dialetos de Cobol em nossa forma analítica intermediário, e também um gerador de código .) Minha sensação é que você ia acabar com uma base de código Java que ainda seria deselegante e insatisfatória para trabalhar. Você pode acabar com problemas de desempenho, dependências em bibliotecas fornecidos pelo fornecedor, o código gerado é de buggy, e assim por diante. Você certamente vai incorrer em uma enorme factura de teste.

Partindo do zero com um novo design orientado a objeto pode ser a abordagem certa, mas você também tem que considerar cuidadosamente as décadas de conhecimento armazenado representado pela base de código. Muitas vezes, há muitas sutilezas que o novo código pode perder. Por outro lado, se você está tendo dificuldade em encontrar pessoal para manter o sistema legado, você pode não ter uma escolha.

Uma abordagem gradual seria a primeira atualização para Cobol 97. Isso adiciona orientação a objetos, assim você pode reescrever e subsistemas refactor individualmente quando você adicionar novas funcionalidades. Ou você poderia substituir subsistemas individuais com Java recém-escrito.

Às vezes você vai ser capaz de substituir componentes com software off-the-shelf: nós ajudamos uma grande companhia de seguros que ainda tinha linhas de 2m de código em uma linguagem legado ele criou na década de 1950. Nós convertido metade para Y2K idioma legado compatível, e eles substituiu a outra metade com um sistema de folha de pagamento moderno que compraram de um fornecedor externo.

Outras dicas

Foi claramente a nossa intenção de obter o código java inicial que era muito perto do cobol de origem para facilitar a migração de pessoas:. Que encontrar o bom aplicativo de idade que escreveu em cobol na exata mesma estrutura

Um dos nossos objetivos mais importante era manter os desenvolvedores iniciais a bordo: essa é a forma que encontramos para alcançá-lo. Quando a aplicação migraram para Java, as pessoas podem começar a torná-lo mais OO como elas se desenvolvem mais / refatorar-lo.

Se você não se preocupam com a migração de pessoas, você pode usar outra estratégia.

Esta conversão 1-to-1 também fez 100% conversão automática mais simples e mais rápido: o bom resultado é que fizemos as nossas poupanças recorrentes (3 milhões de euros / ano) muito mais rápido: estimamos 12-18 meses. Esses primeiros poupança pode claramente ser reinvestido em refactoring OO

não hesite em contactar-me: didier.durand@publicitas.com ou mediaandtech@gmail.com

Didier

A minha experiência é semelhante, mas ligeiramente diferente. Temos uma grande e antiga base de código em Ada (0.5Mloc mais de 15 + anos), que foi recentemente convertido em Java. Foi externalizado a uma empresa que fornecida a combinação de conversão automatizada / manual. Eles também fez o teste para verificar se os sistemas de Ada e Java comportado o mesmo.

Algumas partes dela onde escritos em Ada 95 (ou seja, tinha a possibilidade de OOP), mas a maior parte não era

Agora sim, o código não é até os mesmos padrões de código escrito em Java, em primeiro lugar, mas temos vindo a utilizar desde então com sucesso (18 meses) sem grandes problemas. A principal vantagem que tivemos foi agora podemos encontrar mais desenvolvedores para manter nossa base de código com as habilidades para produzir código sustentável. (Qualquer um pode desenvolver-se em Ada, mas como qualquer outro idioma, se você não tem a experiência em que você pode acabar com código insustentável)

Do ponto de prevenção de riscos de vista, a abordagem NACA absolutamente faz sentido. Reutilizar suas ferramentas talvez não. Eles usaram o desenvolvimento das ferramentas para obter as suas pessoas até a velocidade em Java e Linux.

O resultado da conversão NACA não vai ser bom o suficiente, ou mesmo OO, e torna difícil contratar novas pessoas. Mas é testável, pode ser reformulado, e você pode conectar em melhores tradutores.

[editar] Ira, você não parece ser muito risco consciente.

Enviar os programadores COBOL para um curso de java não está indo para torná-los escrever código orientado a objeto utilizável. Isso leva alguns anos. Durante esse tempo, a sua produtividade será muito baixo, e basicamente você pode jogar fora todo o código que eles escrevem o primeiro ano. Além disso, você vai perder 10-20% de seus programadores, que não estão dispostos ou capazes de fazer a transição. Muitas pessoas não gostam de volta ao status iniciante vai, e vai influenciar a hierarquia, como alguns programadores pegar a nova linguagem muito mais rápido do que outros.

A abordagem NACA permite que o negócio para continuar a trabalhar, e coloca nenhuma pressão desnecessária sobre a organização. O tempo-calendário para a conversão é independente. Ter um tradutor separado, em java, escrito por especialistas OO, permite uma exposição gradual ao java para a antiga equipa. Escrevendo os casos de teste aumenta o conhecimento de domínio na nova equipe java.

O sistema oo real é o tradutor, e esse é o lugar para ligar em melhores tradutores. Tornar mais fácil para fazer isso, e você não tem que tocar o código gerado. Se o código gerado é suficiente feio, que é o que vai acontecer automaticamente::)

os programadores de idade irá alterar a entrada cobol;
os novos java vai mudar o tradutor.

[correndo o tradutor, uma vez] é uma estratégia ruim. Não faça isso. E se você precisa editar o código gerado, manter um mapeamento de volta. Isso pode ser automatizado. E deve ser. É muito mais fácil fazer este tipo de coisas em uma imagem Smalltalk, mas você pode fazê-lo com arquivos. Há pessoas com muita experiência mantendo visões diferentes sobre o mesmo artefato: projetistas de chips vêm à mente

O tradutor deve ser instrumentado, para que possa criar as contagens diárias de exemplo.

componentes de entrada cobol;
componentes de entrada OO Java;
componentes de saída estilo cobol;
componentes de saída estilo OO.

Você pode querer ler: Peter van den Hamer & Kees Lepoeter (1996) Gerenciando Design Data: as cinco dimensões de CAD Frameworks, Gerenciamento de Configuração e Gerenciamento de Dados, Actas do IEEE, Vol. 84, No. 1, janeiro 1996

[plataformas móveis Cobol] Mover-se de Cobol no mainframe para Cobol no Windows / Linux poderia ter sido uma estratégia viável para a equipa NACA, mas a pergunta foi sobre a mudança para java. Se o objetivo a longo prazo é ter um sistema OO moderna, e para chegar lá com o mínimo de risco operacional quanto possível, a abordagem NACA é som. É apenas o primeiro passo, no entanto. Um monte de refactoring vai seguir.

Estou surpreso que ninguém tenha mencionado de Semantic projeto DMS Software Reengineering Toolkit. Olhei para conversão COBOL no passado. Eu estava trabalhando em "programação automática" na época. Antes de escrever um tradutor, eu olhei para um monte de esforços anteriores e produtos nessa área. ferramenta baseada em GLR Designs semânticas foi o melhor do grupo.

Isso foi há muitos anos. Na época, a ferramenta traduzido COBOL para uma linguagem moderna, reformulado-lo, muito imprimiu, etc. Aqui está o link para ele agora.

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

Eles ainda estão ao redor. Eles expandiram a ferramenta. É mais geral. Pode ajudar as pessoas a fazer conversões automatizadas ou personalizando uma ferramenta de conversão. Ele foi projetado para ser expansível e tweakable semelhante ao que Stephan apontou. Graças ao Cyrus também para mencionar SoftwareMining. Eu vou olhar para eles também, se eu me deparo com uma migração COBOL no futuro.

Você está falando de reengenharia . A coisa boa é que um monte de pessoas em todo o mundo tenta fazer isso. A única coisa ruim é que há um monte de problemas relacionados com aplicações legadas reengenharia:. A partir de fontes ausentes e até algoritmos complexos de campos de construção compilador e teoria dos grafos

Idea de tradução automática é muito popular, até que você vai tentar converter alguma coisa. Normalmente, o resultado é horrível e insustentável. É mais insustentável do que a aplicação complicada originais. Do meu ponto de vista, todas as ferramentas que permite a tradução automática de legado para linguagem moderna é muito marketing orientado: ele diz exatamente o que as pessoas querem ouvir, do que você é "traduzir o seu pedido de ... a Java uma vez e esquecer!" a compra de um contrato, e então você entender que você com muito rigor depende da ferramenta (porque você não pode fazer qualquer alteração à sua aplicação sem ele!).

abordagem alternativa é "compreender": a ferramenta, que permite muito detalhado compreensão do seu aplicativo de legado. E você pode usá-lo para manutenção ou para documentar, ou para reinventar na nova plataforma.

Eu sei um pouco sobre a história Modernização Workbench antes Microfocus comprei no ano passado e desenvolvimento transferida para outro país. Houve grande número de ferramentas de análise complexas, eo número de idiomas de destino suportadas (incluindo Java). Mas nenhum cliente realmente usado geração automática de código, de modo que o desenvolvimento da parte geração foi congelado. Tanto quanto eu sei PL / I apoio foi principalmente implementada, mas nunca foi terminado. Mas você ainda pode tentar, pode ser este é o que você está procurando.

Eu olhei para a página e docs NACA. A partir de sua documentação:

"O java gerado usa um Cobol-como sintaxe. É o mais próximo possível da sintaxe Cobol original, dentro, claro, os limites da linguagem Java. código gerado não se parece com Java Native clássica e não é objeto orientado a partir do ponto de vista da aplicação. Este é um por design forte opção, para permitir uma migração suave de desenvolvedores em Cobol para o ambiente Java. O objetivo é manter o conhecimento do negócio na mão de pessoas que escreveram os programas Cobol originais. "

Eu não vi um exemplo, mas a citação dá um forte sabor do resultado. Sua COBOL codificado em Java.

Você sempre pode construir um "tradutor" de uma língua para outra, por simplesmente codificação de um intérprete no langauge alvo. Aquela IMHO um maneira absolutamente terrível para traduzir um langauge como você acabar com o pior dos dois mundos: você não receber o valor da nova linguagem, e você ainda tem que ter conhecimento do velho para manter o resultado vivo. (Não admira que este coisa é chamado de "Transcoder"; eu nunca tinha ouvido esse termo antes).

O argumento para este truque é para despejar os custos do mainframe. Onde está a evidência de que os custos de trabalho sobre o programa convertido não inundar as economias? Eu suspeito que a verdade é que as pessoas operações reduziu seu custo despejando o mainframe, e eles não poderia me importar menos que as tarefas de manutenção ficaram mais caros. Embora isso possa ser racional para os caras de operações, é uma escolha estúpida para o orgnization como um todo.

Céu ajudar as pessoas que são uma vítima desta ferramenta.

EDIT maio de 2010: Eu encontrei um exemplo de saída do NACA; um dos sua casos de teste. Isto é absolutamente magnífico JOBOL. É uma boa coisa que eles são manter seus programadores COBOL e não querem contratar quaisquer programadores Java. Como seu ler isto, certifique-se de que você lembre-se este é Java código.

/*
 * 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();
  }

Kids: Isto é feito apenas por profissionais. Não tente isso em casa.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow