Expérience de la migration de l'ancienne version de Cobol / PL1 vers Java

Question

ORIGINAL Q: Je me demande si quelqu'un a déjà migré une grande base de code Cobol / PL1 vers Java?

Dans quelle mesure le processus était-il automatisé et comment la maintenance était-elle maintenable?

Comment s'est passé le passage du transactionnel au OO?

Toutes les leçons apprises en cours de route ou les ressources / livres blancs qui pourraient être utiles seraient appréciées.

EDIT 7/7: L’approche NACA est certes intéressante. Il est intéressant de pouvoir continuer à modifier le code COB de BAU jusqu’à la publication de la version JAVA.

L'argument de Java procédural dans la même présentation que le COBOL pour donner aux codeurs un sentiment de confort tout en se familiarisant avec le langage Java est un argument valable pour une grande entreprise avec une base de code importante. Comme @Didier le souligne, les économies annuelles de 3 millions de dollars ouvrent la voie à un rembourrage généreux de toutes les modifications de BAU afin de refactoriser le code de manière continue. Comme il le dit si vous vous souciez de vos gens, vous trouvez un moyen de les garder heureux tout en les défiant peu à peu.

Le problème tel que je le vois avec la suggestion de @duffymo de

  

Il vaut mieux essayer et vraiment comprendre le   problème à la base et le ré-exprimer   en tant que système orienté objet

signifie que si des modifications de la structure de base sont en cours, vous devrez coder & amp; pendant la durée de vie du projet LONG pour coder votre nouveau système OO. tester les changements sur le double. C'est un avantage majeur de l'approche NACA. J'ai déjà fait l'expérience de la migration des applications client-serveur vers une implémentation Web. C'est l'un des problèmes majeurs que nous avons rencontré: la modification constante des exigences en raison des modifications apportées à BAU. Il a fait PM & amp; programmer un véritable défi.

Merci à @hhafez, dont l’expérience est bien présentée comme "similaire mais légèrement différente" et et qui a une expérience relativement satisfaisante de la migration automatique de code d’Ada vers Java.

Merci @Didier pour votre contribution, j'étudie toujours votre approche et si j'ai des questions, je vous écrirai un mot.

Answer 1

Mise à jour 6/25: Un ami vient de découvrir le NACA Convertisseur Cobol vers Java. Cela semble intéressant, il a été utilisé pour traduire des lignes de 4 m de Cobol avec une précision de 100%. Voici la page du projet open source NACA . Les autres convertisseurs que j'ai vus étaient propriétaires et les matériaux manquaient cruellement d'histoires de réussite et de code d'exemple détaillé. Le NACA mérite un long regard.

Mise à jour 7/4: @Ira Baxter indique que la sortie Java est très cobolaise, ce qui est le cas. Pour moi, c'est le résultat naturel de la traduction automatique. Je doute que nous trouvions jamais un traducteur de meilleure qualité. Cela plaide peut-être pour une approche de réécriture progressive.

Mise à jour 2/7/11: @spgennard indique qu'il existe des compilateurs Cobol sur la machine virtuelle, par exemple isCobol Evolve . Ceux-ci pourraient être utilisés pour faciliter la transition progressive de la base de code, même si je pense que le PO était plus intéressé par la conversion automatique de source.

Je serais très prudent à ce sujet. (Je travaillais auparavant pour une entreprise qui corrigait automatiquement les programmes Cobol et PL / I pour Y2K, et faisait le compilateur frontal qui convertissait de nombreux dialectes de Cobol en notre forme analytique intermédiaire, ainsi qu'un générateur de code .) Mon sentiment est que vous obtiendriez une base de code Java qui serait toujours inélégante et insatisfaisante. Vous pouvez vous retrouver avec des problèmes de performances, des dépendances des bibliothèques fournies par le fournisseur, un code généré douteux, etc. Vous allez certainement avoir à payer une énorme facture d'essais.

Partir de zéro avec une nouvelle conception orientée objet peut être la bonne approche, mais vous devez également prendre en compte les décennies de connaissances stockées représentées par la base de code. Votre nouveau code peut souvent manquer de nombreuses subtilités. Par contre, si vous avez du mal à trouver du personnel pour entretenir le système existant, vous n’avez peut-être pas le choix.

Une approche progressive consisterait tout d’abord à mettre à niveau vers Cobol 97. Ceci ajoute une orientation aux objets afin que vous puissiez réécrire et refactoriser les sous-systèmes individuellement lorsque vous ajoutez de nouvelles fonctionnalités. Ou vous pouvez remplacer des sous-systèmes individuels par du Java fraîchement écrit.

Parfois, vous pourrez remplacer des composants par un logiciel standard: nous avons aidé une très grande compagnie d’assurances qui disposait toujours de 2 millions de lignes de code dans un langage traditionnel créé dans les années 1950. Nous en avons converti la moitié en langage traditionnel conforme à l’an 2000 et ils ont remplacé l’autre moitié par un système de paie moderne acheté à un fournisseur externe.

Answer 2

Notre intention était clairement d'obtenir un code Java initial très proche du Cobol d'origine afin de faciliter la migration des personnes: ils ont trouvé la bonne vieille application qu'ils avaient écrite dans Cobol dans une structure identique.

L’un de nos objectifs les plus importants était de garder les développeurs initiaux dans le processus: c’est la façon dont nous l’avons trouvé. Lorsque l'application a migré vers Java, ces personnes peuvent commencer à la transformer en OO à mesure qu'elles la développent / la refactorisent.

Si vous ne vous souciez pas de la migration des personnes, vous pouvez utiliser une autre stratégie.

Cette conversion 1 en 1 simplifie également la conversion automatisée à 100% & amp; plus rapide: la bonne conséquence est que nous avons réalisé nos économies récurrentes (3 millions d’euros / an) beaucoup plus rapidement: nous estimons 12-18 mois. Ces économies précoces peuvent clairement être réinvesties dans la refactorisation d’OO

n'hésitez pas à me contacter: didier.durand@publicitas.com ou mediaandtech@gmail.com

didier

Answer 3

Mon expérience est similaire mais légèrement différente. Nous avons une base de code ancienne et volumineuse à Ada (0,5Mloc sur 15 ans et plus) qui a été récemment convertie en Java. Il a été sous-traité à une entreprise qui fournissait une combinaison de conversion automatique / manuelle. Ils ont également effectué des tests pour vérifier que les systèmes Ada et Java se comportaient de la même manière.

Certaines parties de celui-ci étaient écrites dans Ada 95 (c’est-à-dire qu’elles pouvaient faire l’objet d’une POO), mais la plupart ne l’étaient pas

Maintenant, oui, le code n’est pas conforme aux normes de code écrit en Java, mais nous l’utilisons depuis lors avec succès (depuis 18 mois) sans aucun problème majeur. Le principal avantage que nous avons eu est que nous pouvons maintenant trouver plus de développeurs pour maintenir notre base de code avec les compétences nécessaires pour produire du code maintenable. (N'importe qui peut se développer dans Ada, mais comme dans n'importe quelle autre langue, si vous n'en avez pas l'expérience, vous pouvez vous retrouver avec un code invraisemblable.)

Answer 4

Du point de vue de la prévention des risques, l’approche NACA a tout son sens. Réutiliser leurs outils pourrait ne pas. Ils ont mis au point des outils pour aider leurs employés à se familiariser avec Java et Linux.

Le résultat de la conversion de la NACA ne sera pas assez bon, ni même bon, et rend difficile l’embauche de nouveaux employés. Mais il est testable, peut être refactorisé et vous pouvez connecter de meilleurs traducteurs.

[modifier] Ira, vous ne semblez pas être très conscient des risques.

Envoyer les programmeurs cobol à un cours java ne leur fera pas écrire de code utilisable orienté objet. Cela prend quelques années. Pendant ce temps, leur productivité sera très faible et vous pourrez essentiellement jeter tout le code qu'ils ont écrit la première année. De plus, vous perdrez 10 à 20% de vos programmeurs, qui ne veulent ou ne peuvent pas faire la transition. Beaucoup de gens n'aiment pas revenir au statut de débutant et cela va influencer l'ordre hiérarchique, car certains programmeurs apprennent la nouvelle langue beaucoup plus rapidement que d'autres.

L’approche NACA permet à l’entreprise de continuer à travailler et ne crée aucune pression inutile sur l’organisation. Le calendrier de la conversion est indépendant. Avoir un traducteur séparé, écrit en java par des experts OO, permet une exposition progressive à Java pour l’ancienne équipe. L'écriture des cas de test augmente la connaissance du domaine dans la nouvelle équipe Java.

Le véritable système oo est le traducteur, et c’est le lieu idéal pour connecter de meilleurs traducteurs. Rendez-le facile, et vous n’avez pas à toucher au code généré. Si le code généré est assez moche, c'est ce qui se passera automatiquement: :)

• les anciens programmeurs changeront l’entrée cobol;
• les nouveaux java changeront le traducteur.

[exécuter le traducteur une fois] est une mauvaise stratégie. Ne fais pas ça. Et si vous avez besoin de modifier le code généré, maintenez un cartographie retour. Cela peut être automatisé. Et devrait être. Il est beaucoup plus facile de faire ce genre de choses dans une image Smalltalk, mais vous pouvez le faire avec des fichiers. Il existe des personnes très expérimentées dans la gestion de points de vue différents sur le même artefact: les concepteurs de puces viennent à l’esprit.

Le traducteur doit être instrumenté afin que vous puissiez créer les comptes quotidiens, par exemple

.

• composants d'entrée cobol;
• composants d'entrée Java OO;
• composants de sortie de style cobol;
• Composants en sortie de style OO.

Vous voudrez peut-être lire: Peter van den Hamer & amp; Kees Lepoeter (1996), Gestion des données de conception: les cinq dimensions des cadres de CAO, la gestion de la configuration et la gestion des données, Actes de l'IEEE, vol. 84, n ° 1, janvier 1996

[plates-formes Cobol en mouvement] Passer de Cobol sur l'ordinateur central à Cobol sous Windows / Linux aurait pu être une stratégie viable pour l'équipe NACA, mais la question portait sur le passage à Java. Si l'objectif à long terme est de disposer d'un système OO moderne et d'y parvenir avec le moins de risque opérationnel possible, l'approche NACA est judicieuse. Ce n'est que la première étape, cependant. Beaucoup de refactoring va suivre.

Answer 5

Je suis surpris que personne n’a mentionné le DMS Software Reengineering Toolkit de Semantic Design. J'ai examiné la conversion COBOL dans le passé. Je travaillais sur la "programmation automatique". à l'époque. Avant d’écrire un traducteur, j’ai jeté un coup d’œil aux nombreux efforts et produits précédents dans ce domaine. L'outil basé sur GLR de Semantic Designs était le meilleur du groupe.

C'était il y a plusieurs années. À l'époque, l'outil traduisait COBOL en langage moderne, le refactorisait, le imprimait joliment, etc. En voici le lien.

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

Ils sont toujours là. Ils ont développé l'outil. C'est plus général. Cela pourrait aider les gens à effectuer des conversions automatisées ou à personnaliser un outil de conversion. Il est conçu pour être extensible et modifiable, comme ce que Stephan a souligné. Merci à Cyrus d'avoir également mentionné SoftwareMining. Je les étudierai aussi si je rencontre une migration COBOL à l'avenir.

Answer 6

Vous parlez de la la réingénierie . La bonne chose est que beaucoup de personnes dans le monde tentent de le faire. Le problème, c’est qu’il ya beaucoup de problèmes concernant la réingénierie d’applications héritées: des sources manquantes aux algorithmes complexes allant de la construction du compilateur aux champs de la théorie des graphes.

L’idée de la traduction automatique est très populaire, jusqu’à ce que vous essayiez de convertir quelque chose. Habituellement, le résultat est affreux et incontrôlable. C'est plus difficile à maintenir que l'application compliquée originale. De mon point de vue, chaque outil permettant la traduction automatique du langage traditionnel au langage moderne est très orienté marketing: il indique exactement ce que les gens veulent entendre "traduire votre application de ... vers Java une fois, et oubliez!", vous achetez un contrat et vous comprenez alors que vous dépendez très étroitement de l'outil (car vous ne pouvez modifier aucunement votre application sans celui-ci!).

L’approche alternative consiste à "comprendre": l’outil, qui vous permet une compréhension très détaillée de votre application héritée. Et vous pouvez l’utiliser pour la maintenance, la documentation ou la réinvention sur une nouvelle plate-forme.

Je connais un peu l'historique de sur le Modernization Workbench avant que Microfocus ne l'achète l'an dernier et déplacé le développement dans un autre pays. Il y avait un grand nombre d'outils d'analyse complexes et nombre de langages cibles pris en charge (y compris Java). Mais aucun client n’a réellement utilisé la génération de code automatique, le développement de la partie génération a donc été gelé. Autant que je sache, le support de PL / I a été principalement mis en œuvre, mais il n'a jamais été terminé. Mais vous pouvez quand même essayer, c’est peut-être ce que vous recherchez.

Answer 7

Je viens de regarder la page NACA et la documentation. De leur documentation:

"Le java généré utilise une syntaxe de type Cobol. C'est aussi proche que possible de la syntaxe Cobol originale, dans les limites bien sûr du langage Java. Le code généré ne ressemble pas au java natif classique et n'est pas orienté objet du point de vue de l'application. Il s’agit d’un choix judicieux, permettant une migration en douceur des développeurs Cobol vers l’environnement Java. L’objectif est de garder les connaissances commerciales entre les mains des auteurs des programmes Cobol originaux. "

Je n'ai pas vu d'exemple, mais la citation donne une forte idée du résultat. Son code COBOL en Java.

Vous pouvez toujours créer un " Traducteur " d'une langue à une autre, par coder simplement un interprète dans la langue cible. C'est à mon humble avis manière absolument terrible de traduire une langue au fur et à mesure que vous vous retrouvez avec le pire des deux mondes: vous n'obtenez pas la valeur de la nouvelle langue, et il faut encore connaître l'ancien pour conserver le résultat vivant. (Pas étonnant que cette chose s'appelle un "transcodeur"; je n'aurais jamais entendu ce terme auparavant).

L’argument en faveur de cette cascade consiste à vider les coûts de l’ordinateur central. Où est la preuve que les coûts de travail sur le programme converti ne pas submerger les économies? Je soupçonne que la vérité est que les gens des opérations abaissé leurs coûts en déchargeant l’ordinateur central, et ils se moquaient bien de que les tâches de maintenance sont devenues plus coûteuses. Bien que cela puisse être rationnel pour les gars des opérations, c’est un choix stupide pour l’organisation dans son ensemble.

Heaven aide les personnes victimes de cet outil.

EDIT Mai 2010: j'ai trouvé un exemple de la production de NACA; un des leurs cas de test. C'est absolument magnifique JOBOL. C'est une bonne chose qu'ils gardent leurs programmeurs COBOL et ne veulent pas embaucher tous les programmeurs Java. Pendant que vous lisez ceci, assurez-vous de vous souvenir il s'agit du code 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();
  }

Enfants: Ceci est fait uniquement par des professionnels. Ne tentez pas cela à la maison.