レガシーCobol / PL1からJavaへの移行経験

https://stackoverflow.com/questions/1029974

06-07-2019
|

質問

オリジナルQ： 大規模なCobol / PL1コードベースをJavaに移行した経験がある人はいないだろうか？

プロセスはどの程度自動化され、出力はどの程度保守可能でしたか？

トランザクションからオブジェクト指向への移行はどのように行われましたか？

途中で学んだ教訓、または有益なリソース/ホワイトペーパーをいただければ幸いです。

編集7/7：確かにNACAアプローチは興味深いものです。JavaバージョンをリリースするまでCOBOLコードにBAUの変更を加え続ける機能は、どの組織にとってもメリットがあります。

Java言語に慣れている間、コーダーに安心感を与えるための、COBOLと同じレイアウトの手続き型Javaの引数は、大きなコードベースを持つ大規模な組織にとって有効な引数です。 @Didierが指摘しているように、年間300万ドルの節約により、コードを継続的にリファクタリングするために今後BAUを変更する際の寛大なパディングが可能になります。彼が言うように、あなたがあなたの人々を気にかけるなら、あなたは彼らを幸せに保ちながら徐々に彼らに挑戦する方法を見つけます。

@duffymoから

への提案で見た問題

試してみて、本当に理解するのがベストその根本の問題とそれを再表現オブジェクト指向システムとして

は、BAUの変更が進行中の場合、新しいOOシステムをコーディングするLONGプロジェクトの存続期間中に、最終的にコーディング＆amp;ダブルの変更をテストします。これはNACAアプローチの大きな利点です。クライアントサーバーアプリケーションをWeb実装に移行した経験がありますが、これは私たちが直面した主要な問題の1つであり、BAUの変更により要件が絶えず変化しています。 PM＆amp;を作りました実際のチャレンジをスケジュールする。

@hhafezのおかげで、経験は＆quot;似ているがわずかに異なっている＆quot; とうまく入れられており、AdaからJavaへの自動コード移行のかなり満足のいく経験があります。

貢献してくれた@Didierに感謝します。私はまだあなたのアプローチを研究しており、Qがあれば私はあなたに一行を送ります。

解決

更新6/25：友人が NACA CobolからJavaへのコンバーター。非常に面白そうに見えますが、4百万行のCobolを100％の精度で翻訳するために使用されました。 NACAオープンソースプロジェクトページをご覧ください。私が見た他のコンバーターはプロプライエタリであり、材料にはサクセスストーリーと詳細なサンプルコードが著しく欠けていました。 NACAは一見の価値があります。

Update 7/4： @Ira Baxterは、Java出力が非常にCobol風に見えると報告しています。私にとって、これは自動翻訳の自然な結果です。もっと良い翻訳者を見つけることはできないと思います。これはおそらく、段階的な書き換えアプローチを主張しています。

アップデート2/7/11： @spgennardは、Veryantの isCobol Evolve 。これらは、コードベースを徐々に移行するのに役立つ可能性がありますが、OPはソースの自動変換に関心があると思います。

これについては非常に慎重になります。（私はY2KのCobolおよびPL / Iプログラムを自動的に修正する会社で働いていました。また、Cobolの多くの方言を私たちの中間分析形式に変換するフロントエンドコンパイラとコードジェネレーターを行いました。。）私の感覚では、Javaコードベースはまだ洗練されておらず、作業に満足できません。パフォーマンスの問題、ベンダー提供のライブラリへの依存、バグのある生成コードなどが発生する可能性があります。確かに大きなテスト費用が発生します。

新しいオブジェクト指向の設計からゼロから始めるのは正しいアプローチですが、コードベースによって表される何十年もの蓄積された知識も慎重に検討する必要があります。多くの場合、新しいコードでは見落としがちな微妙な点が多くあります。一方、レガシーシステムを保守するスタッフを見つけるのに苦労している場合は、選択肢がない場合があります。

最初の段階的なアプローチは、最初にCobol 97にアップグレードすることです。これにより、オブジェクト指向が追加されるため、新しい機能を追加するときにサブシステムを個別にリファクタリングおよびリファクタリングできます。または、個々のサブシステムを新しく作成したJavaに置き換えることもできます。

コンポーネントを市販のソフトウェアに置き換えることができる場合があります。1950年代に作成したレガシー言語で200万行のコードを保持しているある大規模な保険会社を支援しました。その半分をY2K準拠のレガシー言語に変換し、残りの半分を外部ベンダーから購入した最新の給与計算システムに置き換えました。

他のヒント

人々の移行を容易にするために、元のcobolに非常に近い初期Javaコードを取得することが明らかに私たちの意図でした：cobolで書いた古き良きアプリをまったく同じ構造で見つけます。

私たちの最も重要な目標の1つは、初期の開発者を迎え入れることでした。それが、それを達成するために見つけた方法です。アプリケーションをJavaに移行すると、それらの人々はさらに開発/リファクタリングするにつれて、より多くのオブジェクト指向を開始できます。

人の移動を気にしない場合は、他の戦略を使用できます。

この1対1変換により、100％自動化された変換がより簡単になりました＆amp;より高速：良い結果は、定期的な節約（年間300万ユーロ）をはるかに高速化したことです。12〜18か月と見積もっています。これらの早期の節約は、オブジェクト指向リファクタリングに明らかに再投資できます

お気軽にお問い合わせください：didier.durand@publicitas.comまたはmediaandtech@gmail.com

ディディエ

私の経験は似ていますが、わずかに異なります。私たちは、最近Javaに変換されたAdaに大規模で古いコードベース（15年以上で0.5Mloc）を持っています。自動/手動変換の組み合わせを提供する会社に外部委託されました。また、AdaシステムとJavaシステムが同じように動作することを確認するためのテストも行いました。

Ada 95で記述された（OOPの可能性があった）部分もありますが、ほとんどはそうではありませんでした

今では、コードはそもそもJavaで書かれたコードの標準と同じではありませんが、それ以来、大きな問題もなく正常に使用されています（現在18か月）。私たちが得た主な利点は、メンテナンス可能なコードを生成するスキルを備えたコードベースを維持する開発者を見つけることができたことです。（誰でもAdaで開発できますが、経験がない場合は他の言語と同様に、保守不能なコードになる可能性があります）

リスク回避の観点から、NACAアプローチは絶対に理にかなっています。ツールを再利用することはできません。彼らは、ツールの開発を使用して、JavaとLinuxの速度を向上させました。

NACA変換の結果は十分ではなく、オブジェクト指向でさえないため、新しい人を雇うことが難しくなります。ただし、テスト可能であり、リファクタリングすることができ、より優れたトランスレーターをプラグインできます。

[編集] イラ、あなたはあまりリスクを意識していないようです。

Javaコースにcobolプログラマを送信しても、使用可能なオブジェクト指向コードを作成することはできません。それには数年かかります。その間、彼らの生産性は非常に低くなり、基本的に彼らが最初の年に書くすべてのコードを捨てることができます。さらに、移行を行う意思がないまたはできないプログラマの10〜20％が失われます。多くの人は初心者の状態に戻ることを嫌い、一部のプログラマーは他の言語よりもはるかに速く新しい言語を選択するため、序列に影響を与えます。

NACAアプローチは、ビジネスの継続を可能にし、組織に不必要な圧力をかけません。変換のスケジュールは独立しています。 OOの専門家によって書かれた、Javaの別の翻訳者がいることで、古いチームが徐々にJavaに触れることができます。テストケースを作成すると、新しいJavaチームのドメインに関する知識が増えます。

実際のooシステムは翻訳者であり、より良い翻訳者をプラグインする場所です。それを簡単にし、生成されたコードに触れる必要はありません。生成されたコードがenoughい場合、それは自動的に行われます::）

古いプログラマーはcobol入力を変更します;
新しいJavaのものは翻訳者を変更します。

[翻訳者を1回実行する] 悪い戦略です。しないでください。生成されたコードを編集する必要がある場合は、マッピングバック。それは自動化できます。そしてすべきです。 Smalltalkイメージでこのようなことを行う方がはるかに簡単ですが、ファイルを使用して行うことができます。同じアーティファクトでさまざまなビューを維持している多くの経験を持つ人々がいます：チップ設計者が思い浮かびます。

翻訳者はインストルメント化する必要があります。たとえば、毎日のカウントを作成できます。

cobol入力コンポーネント;
OO Java入力コンポーネント
cobolスタイルの出力コンポーネント;
OOスタイルの出力コンポーネント。

読みたいかもしれません：ピーターヴァンデンハマー＆amp; Kees Lepoeter（1996）設計データの管理：CADフレームワークの5つの側面、構成管理、データ管理、IEEEの議事録、Vol。 84、No。1、1996年1月

[移動Cobolプラットフォーム] メインフレームのCobolからWindows / LinuxのCobolに移行することは、NACAチームにとって実行可能な戦略かもしれませんが、問題はJavaに移行することでした。長期的な目標が最新のオブジェクト指向システムを持ち、運用リスクを可能な限り少なくすることである場合、NACAアプローチは適切です。ただし、手順は1つだけです。多くのリファクタリングが続きます。

Semantic DesignのDMS Software Reengineering Toolkitについて誰も言及していないことに驚いています。過去にCOBOL変換について調べました。「自動プログラミング」に取り組んでいました。当時。翻訳者を書く前に、私はその分野で以前の努力と製品の束を調べました。 Semantic DesignsのGLRベースのツールは、最高のものでした。

それは何年も前のことです。当時、このツールはCOBOLを最新の言語に翻訳し、それをリファクタリングし、きれいに印刷しました。今、ここにリンクがあります。

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

彼らはまだ存在しています。彼らはツールを拡張しました。より一般的です。自動化された変換を行ったり、変換ツールをカスタマイズしたりするのに役立ちます。 Stephanが指摘したのと同様に、拡張可能および微調整可能に設計されています。 SoftwareMiningについて言及してくれたCyrusにも感謝します。将来COBOLの移行に遭遇した場合にも、それらを調べます。

リエンジニアリングについてお話します。良いことは、世界中の多くの人々がこれをしようとすることです。悪いことは、レガシーアプリケーションのリエンジニアリングに関して多くの問題があることです。ソースの欠落から、コンパイラの構築とグラフ理論の分野までの複雑なアルゴリズムまで。

何かを変換しようとするまで、自動翻訳のアイデアは非常に人気があります。通常、結果はひどく、維持できません。元の複雑なアプリケーションよりも保守が困難です。私の観点からすると、レガシー言語から現代言語への自動翻訳を可能にするすべてのツールは非常にマーケティング志向です：それは人々が聞きたいことを正確に言っています...契約を購入していて、ツールに非常に強く依存していることを理解しています（これがないとアプリケーションに変更を加えることができないためです！）。

代替アプローチは「理解」です。これは、レガシーアプリケーションを非常に詳細に理解できるツールです。そして、メンテナンス、文書化、または新しいプラットフォームでの再発明に使用できます。

昨年、Microfocusが購入する前に Modernization Workbench の歴史について少し知っています。開発を別の国に移動しました。多数の複雑な分析ツールと、サポートされるターゲット言語（Javaを含む）が多数ありました。しかし、実際に自動コード生成を使用したクライアントはいなかったため、生成部分の開発は凍結されました。私の知る限り、PL / Iサポートはほとんど実装されていましたが、まだ完了していませんでした。しかし、まだ試してみることができます。これがあなたが探しているものかもしれません。

NACAのページとドキュメントを見ました。ドキュメントから：

＆quot;生成されたjavaはCobolのような構文を使用します。もちろん、Java言語の制限内で、元のCobol構文にできるだけ近いものです。生成されたコードは、従来のネイティブJavaのようには見えず、アプリケーションの観点からはオブジェクト指向ではありません。これは、Cobol開発者のJava環境へのスムーズな移行を可能にする、設計上強力な選択です。目標は、元のCobolプログラムを書いた人々の手にビジネス知識を保持することです。＆quot;

例はありませんでしたが、引用符は結果の強い味を示しています。 JavaでコーディングされたCOBOL。

＆quot;翻訳者＆quot;はいつでも作成できます。ある言語から別の言語へ、ターゲット言語でインタプリタをコーディングするだけです。それは私見です最終的に言語を翻訳する絶対に恐ろしい方法両方の世界の最悪：新しい言語の価値を手に入れられない、そして、あなたはまだ結果を維持するために古いものの知識を持っている必要があります生きている。（これが「トランスコーダー」と呼ばれるのも不思議ではありません;私は決してこの用語を以前に聞いたことがあります）。

このスタントの議論は、メインフレームのコストをダンプすることです。変換されたプログラムで作業するコストがどこにあるかという証拠はどこにありますか貯蓄を圧倒しませんか？真実は、オペレーションの人々がメインフレームをダンプすることでコストを削減しました。メンテナンスタスクがより高価になったこと。それは合理的かもしれませんが運用担当者にとっては、組織全体の愚かな選択です。

天国は、このツールの被害者である人々を助けます。

EDIT 2010年5月：NACAの出力の例を見つけました。それらの1つテストケース。これは絶対に素晴らしいJOBOLです。彼らの良いこと COBOLプログラマーを維持しており、採用したくない Javaプログラマー。これを読んで、覚えておいてくださいこれは 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();
  }

子供：これは専門家によってのみ行われます。自宅でこれを試みないでください。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow