Sperimenta la migrazione dell'eredità Cobol / PL1 a Java

https://stackoverflow.com/questions/1029974

06-07-2019
|

Domanda

ORIGINALE Q: Mi chiedo se qualcuno ha avuto esperienza di migrazione di una grande base di codice Cobol / PL1 su Java?

Quanto è stato automatizzato il processo e quanto è stato gestibile l'output?

Come ha funzionato il passaggio da transazionale a OO?

Qualunque lezione appresa lungo il percorso o risorse / white paper che potrebbero essere utili sarebbero apprezzate.

MODIFICA 7/7: Sicuramente l'approccio NACA è interessante, la possibilità di continuare ad apportare le tue modifiche BAU al codice COBOL fino al punto di rilasciare la versione JAVA ha valore per qualsiasi organizzazione.

L'argomento per Java procedurale nello stesso layout di COBOL per dare ai programmatori un senso di conforto mentre familiarizzano con il linguaggio Java è un argomento valido per una grande organizzazione con una base di codice di grandi dimensioni. Come sottolineato da @Didier, il risparmio annuo di $ 3mil offre spazio per un generoso riempimento su eventuali modifiche BAU in futuro per il refactoring del codice su base continuativa. Come dice lui, se ti preoccupi della tua gente, trovi un modo per renderli felici mentre li sfidi gradualmente.

Il problema come lo vedo io con il suggerimento da @duffymo a

Meglio provare e capire veramente il problema alla radice e ri-esprimerlo come sistema orientato agli oggetti

è che se hai cambiamenti BAU in corso, durante la lunga durata del progetto di codifica del tuo nuovo sistema OO finirai per codificare & amp; testare le modifiche sul doppio. Questo è un grande vantaggio dell'approccio NACA. Ho avuto una certa esperienza nella migrazione di applicazioni client-server a un'implementazione Web e questo è stato uno dei principali problemi che abbiamo riscontrato, spostando costantemente i requisiti a causa delle modifiche BAU. Ha reso PM e amp; programmare una vera sfida.

Grazie a @hhafez la cui esperienza è ben definita come "simile ma leggermente diversa" e ha avuto un'esperienza ragionevolmente soddisfacente di una migrazione automatica del codice da Ada a Java.

Grazie @Didier per il contributo, sto ancora studiando il tuo approccio e se ho qualche Q ti mando una riga.

Soluzione

Aggiornamento del 6/25: un amico ha appena incontrato NACA convertitore Cobol in Java. Sembra piuttosto interessante, è stato usato per tradurre 4 m di linee di Cobol con una precisione del 100%. Ecco la pagina del progetto open source NACA . Gli altri convertitori che ho visto erano proprietari e ai materiali mancavano in modo evidente storie di successo e codici di esempio dettagliati. Il NACA merita una lunga occhiata.

Aggiornamento 7/4: @Ira Baxter riporta che l'output Java sembra molto Cobol-esque, cosa che fa assolutamente. Per me, questo è il risultato naturale della traduzione automatica. Dubito che troveremo mai un traduttore molto migliore. Questo forse sostiene un approccio graduale alla riscrittura.

Aggiornamento 07/02/11: @spgennard sottolinea che ci sono alcuni compilatori Cobol sulla JVM, ad esempio Veryant's isCobol Evolve . Questi potrebbero essere utilizzati per favorire la transizione graduale della base di codice, sebbene ritenga che l'OP fosse più interessato alla conversione automatizzata dei sorgenti.

Sarei molto cauto al riguardo. (Lavoravo per un'azienda che automaticamente correggeva i programmi Cobol e PL / I per Y2K, e facevo il compilatore front-end che convertiva molti dialetti di Cobol nella nostra forma analitica intermedia, e anche un generatore di codice .) Il mio senso è che ti ritrovi con una base di codice Java che sarebbe ancora inelegante e insoddisfacente con cui lavorare. Potresti finire con problemi di prestazioni, dipendenze dalle librerie fornite dal fornitore, codice generato che è difettoso e così via. Sicuramente dovrai sostenere una grossa fattura di prova.

Partire da zero con un nuovo design orientato agli oggetti può essere l'approccio giusto, ma bisogna anche considerare attentamente i decenni di conoscenza memorizzata rappresentati dalla base di codice. Spesso ci sono molte sottigliezze che potrebbero sfuggire al tuo nuovo codice. D'altra parte, se hai difficoltà a trovare personale per mantenere il sistema legacy, potresti non avere scelta.

Un approccio graduale sarebbe quello di aggiornare prima a Cobol 97. Ciò aggiunge l'orientamento agli oggetti, in modo da poter riscrivere e refactoring singolarmente i sottosistemi quando si aggiungono nuove funzionalità. Oppure potresti sostituire i singoli sottosistemi con Java appena scritto.

A volte sarai in grado di sostituire i componenti con un software standard: abbiamo aiutato una grande compagnia assicurativa che aveva ancora 2m di righe di codice in un linguaggio legacy creato negli anni '50. Ne abbiamo convertito metà in un linguaggio legacy conforme a Y2K e hanno sostituito l'altra metà con un moderno sistema di gestione stipendi acquistato da un fornitore esterno.

Altri suggerimenti

Era chiaramente nostro intento ottenere il codice java iniziale che era molto vicino al cobol originale per facilitare la migrazione delle persone: trovano la buona vecchia app che hanno scritto in cobol esattamente nella stessa struttura.

uno dei nostri obiettivi più importanti è stato quello di mantenere gli sviluppatori iniziali a bordo: è così che abbiamo trovato per raggiungerlo. Quando l'applicazione viene migrata su Java, queste persone possono iniziare a renderla più OO man mano che la sviluppano / refattano ulteriormente

Se non ti interessa migrare le persone, puoi usare un'altra strategia.

Questa conversione da 1 a 1 ha anche reso la conversione automatizzata al 100% più semplice & amp; più veloce: la buona conseguenza è che abbiamo fatto i nostri risparmi ricorrenti (3 milioni di euro / anno) molto più velocemente: stimiamo 12-18 mesi. Quei primi risparmi possono essere chiaramente reinvestiti nel refactoring OO

non esitate a contattarmi: didier.durand@publicitas.com o mediaandtech@gmail.com

didier

La mia esperienza è simile ma leggermente diversa. Abbiamo una base di codice grande e vecchia in Ada (0,5Mloc per oltre 15 anni) che è stata recentemente convertita in Java. È stato esternalizzato a una società che ha fornito una combinazione di conversione automatica / manuale. Hanno anche effettuato dei test per verificare che i sistemi Ada e Java si comportassero allo stesso modo.

Alcune parti di esso erano scritte in Ada 95 (cioè avevano la possibilità di OOP) ma la maggior parte non lo era

Ora sì, il codice non è all'altezza degli stessi standard di codice scritti in Java in primo luogo, ma lo usiamo da allora con successo (18 mesi) senza problemi importanti. Il vantaggio principale che abbiamo ottenuto è che ora possiamo trovare più sviluppatori per mantenere la nostra base di codice con le competenze per produrre codice gestibile. (Chiunque può svilupparsi in Ada ma, come qualsiasi altra lingua, se non si ha l'esperienza in essa si può finire con un codice non mantenibile)

Dal punto di vista della prevenzione dei rischi, l'approccio NACA ha assolutamente senso. Riutilizzare i loro strumenti potrebbe non esserlo. Hanno usato lo sviluppo degli strumenti per velocizzare le persone in Java e Linux.

Il risultato della conversione NACA non sarà abbastanza buono, o addirittura OO, e rende difficile assumere nuove persone. Ma è testabile, può essere sottoposto a refactoring e puoi collegare traduttori migliori.

[modifica] Ira, non sembri essere molto attento al rischio.

L'invio dei programmatori cobol a un corso Java non li farà scrivere codice orientabile agli oggetti utilizzabile. Ci vogliono alcuni anni. Durante quel periodo, la loro produttività sarà molto bassa e puoi praticamente buttare via tutto il codice che scrivono il primo anno. Inoltre perderai il 10-20% dei tuoi programmatori, che non sono disposti o in grado di effettuare la transizione. A molte persone non piace tornare allo stato di principiante, e influenzerà l'ordine di beccata, poiché alcuni programmatori acquisiscono la nuova lingua molto più velocemente di altri.

L'approccio NACA consente all'azienda di continuare a lavorare e non esercita pressioni inutili sull'organizzazione. Il calendario per la conversione è indipendente. Avere un traduttore separato, in Java, scritto da esperti OO, consente una graduale esposizione a Java per il vecchio team. Scrivere i casi di test aumenta la conoscenza del dominio nel nuovo team Java.

Il vero sistema oo è il traduttore, ed è il posto giusto per collegare traduttori migliori. Semplifica l'operazione e non devi toccare il codice generato. Se il codice generato è abbastanza brutto, è quello che accadrà automaticamente: :) ??

i vecchi programmatori cambieranno l'input cobol;
i nuovi java cambieranno il traduttore.

[eseguendo il traduttore una volta] è una cattiva strategia. Non farlo. E se è necessario modificare il codice generato, mantenere a mappatura indietro. Questo può essere automatizzato. E dovrebbe essere. È molto più facile fare questo tipo di cose in un'immagine Smalltalk, ma puoi farlo con i file. Ci sono persone con molta esperienza nel mantenere visioni diverse sullo stesso artefatto: i progettisti di chip vengono in mente.

Il traduttore dovrebbe essere strumentato, in modo da poter creare i conteggi giornalieri di ad esempio

componenti di input cobol;
componenti di input Java OO;
componenti di output in stile cobol;
Componenti di output in stile OO.

Potresti voler leggere: Peter van den Hamer & amp; Kees Lepoeter (1996) Gestione dei dati di progettazione: le cinque dimensioni dei quadri CAD, gestione della configurazione e gestione dei dati, atti dell'IEEE, vol. 84, n. 1, gennaio 1996

[spostamento delle piattaforme Cobol] Passare da Cobol sul mainframe a Cobol su Windows / Linux avrebbe potuto essere una strategia praticabile per il team NACA, ma la domanda riguardava il passaggio a Java. Se l'obiettivo a lungo termine è quello di disporre di un moderno sistema OO e di arrivarci con il minor rischio operativo possibile, l'approccio NACA è valido. È solo il primo passo, però. Seguiranno molti refactoring.

Sono sorpreso che nessuno abbia menzionato il DMS Software Reengineering Toolkit di Semantic Design. Ho esaminato la conversione COBOL in passato. Stavo lavorando su " programmazione automatica " allora. Prima di scrivere un traduttore, ho cercato un sacco di precedenti sforzi e prodotti in quella zona. Lo strumento basato su GLR di Semantic Designs era il migliore del gruppo.

È stato molti anni fa. All'epoca, lo strumento traduceva COBOL in un linguaggio moderno, lo riformattava, lo stampava piuttosto, ecc. Ecco il link adesso.

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

Sono ancora in giro. Hanno ampliato lo strumento. È più generale. Potrebbe aiutare le persone a fare conversioni automatizzate o a personalizzare uno strumento di conversione. È progettato per essere espandibile e modificabile in modo simile a quanto sottolineato da Stephan. Grazie a Cyrus anche per aver menzionato SoftwareMining. Li esaminerò anche se in futuro incontrerò una migrazione COBOL.

Stai parlando di reengineering . La cosa buona è che molte persone in tutto il mondo cercano di farlo. La cosa brutta è che ci sono molti problemi riguardanti la riprogettazione delle applicazioni legacy: a partire da fonti mancanti e fino a algoritmi complessi dai campi di costruzione del compilatore e di teoria dei grafi.

L'idea della traduzione automatica è molto popolare, finché non proverai a convertire qualcosa. Di solito il risultato è terribile e irraggiungibile. È più non mantenibile rispetto all'applicazione complicata originale. Dal mio punto di vista, ogni strumento che consente la traduzione automatica dall'eredità al linguaggio moderno è molto orientato al marketing: dice esattamente ciò che la gente vuole ascoltare & tradurre; la tua applicazione da ... a Java una volta, e dimenticare! & Quot;, di stai acquistando un contratto e poi capisci che dipende strettamente dallo strumento (perché senza di esso non puoi apportare modifiche alla tua applicazione!).

L'approccio alternativo è "comprensione": lo strumento che ti consente una comprensione molto dettagliata della tua applicazione legacy. E puoi usarlo per manutenzione, per documentare o per reinventare su una nuova piattaforma.

Conosco un po 'di Modernization Workbench prima che Microfocus lo acquistasse l'anno scorso e ha spostato lo sviluppo in un altro paese. C'era un gran numero di strumenti di analisi complessi e un numero di lingue target supportate (incluso Java). Ma nessun client utilizzava davvero la generazione automatica del codice, quindi lo sviluppo della parte di generazione era bloccato. Per quanto ne so, il supporto PL / I è stato per lo più implementato, ma non è mai stato completato. Ma puoi ancora provare, potrebbe essere questo quello che stai cercando.

Ho appena dato un'occhiata alla pagina e ai documenti della NACA. Dalla loro documentazione:

" Il java generato usa una sintassi simile a Cobol. È il più vicino possibile alla sintassi Cobol originale, ovviamente entro i limiti del linguaggio Java. Il codice generato non sembra un java nativo classico e non è orientato agli oggetti dal punto di vista dell'applicazione. Questa è una scelta forte in base alla progettazione, per consentire una migrazione senza problemi degli sviluppatori Cobol nell'ambiente Java. L'obiettivo è mantenere la conoscenza del business nelle mani di chi ha scritto i programmi Cobol originali. & Quot;

Non ho visto un esempio, ma la citazione dà un forte sapore del risultato. Il suo codice COBOL è codificato in Java.

Puoi sempre creare un " Traduttore " da una lingua all'altra, di semplicemente codificando un interprete nella lingua di destinazione. Questo è IMHO un un modo assolutamente terribile di tradurre una lingua mentre si finisce con il peggio di entrambi i mondi: non ottieni il valore della nuova lingua, e devi ancora avere conoscenza di quello vecchio per conservare il risultato vivo. (Non c'è da meravigliarsi che questa cosa sia chiamata "Transcoder", non lo farei mai ho già sentito questo termine).

L'argomento di questa acrobazia è di scaricare i costi del mainframe. Dov'è la prova che i costi di lavoro sul programma convertito non sommergere i risparmi? Sospetto che la verità sia che le operazioni delle persone ha ridotto i costi scaricando il mainframe e non gliene potrebbe fregare di meno che le attività di manutenzione sono diventate più costose. Mentre quello può essere razionale per i ragazzi delle operazioni, è una scelta stupida per l'organizzazione complessiva.

Il paradiso aiuta le persone che sono vittime di questo strumento.

EDIT maggio 2010: ho trovato un esempio dell'output di NACA; uno dei loro casi test. Questo è assolutamente magnifico JOBOL. È una buona cosa loro stanno mantenendo i loro programmatori COBOL e non vogliono assumerli eventuali programmatori Java. Mentre leggi questo, assicurati di ricordare questo è il codice 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();
  }

Bambini: questo è fatto solo da professionisti. Non tentare di farlo a casa.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow