5

原始问题： 我想知道是否有人有将大型 Cobol/PL1 代码库迁移到 Java 的经验？

该过程的自动化程度如何，输出的可维护性如何？

从事务性到 OO 的转变是如何进行的？

在此过程中学到的任何经验教训或可能有益的资源/白皮书将不胜感激。

编辑 7/7：当然，NACA 方法很有趣，在发布 JAVA 版本之前继续对 COBOL 代码进行 BAU 更改的能力对任何组织都有好处。

程序化 Java 与 COBOL 布局相同，以便在熟悉 Java 语言的同时给编码人员一种舒适感，这一论点对于拥有大量代码库的大型组织来说是一个有效的论点。正如@Didier 指出的那样，每年 300 万美元的节省为未来任何 BAU 更改提供了充足的空间，以持续重构代码。正如他所说，如果你关心你的员工，你就会找到一种让他们开心的方法，同时逐渐挑战他们。

我在@duffymo 的建议中看到的问题

最好尝试并真正理解问题的根源并将其重新表达为面向对象的系统

是如果您正在进行任何 BAU 更改，那么在对新的 OO 系统进行编码的 LONG 项目生命周期中，您最终会在双重编码和测试更改。这是 NACA 方法的主要好处。我有一些将客户端-服务器应用程序迁移到 Web 实现的经验，这是我们遇到的主要问题之一，由于 BAU 变化而不断改变需求。它使 PM 和调度成为一个真正的挑战。

感谢@hhafez，他的经验被很好地描述为“相似但略有不同”，并且在从 Ada 到 Java 的自动代码迁移方面获得了相当令人满意的体验。

感谢@Didier 的贡献，我仍在研究你的方法，如果我有任何问题，我会给你留言。

4

7 回答 7

7

更新 6/25：一位朋友刚刚遇到了NACA Cobol 到 Java 转换器。看起来很有趣，它被用来以 100% 的准确率翻译 4m 行 Cobol。这是NACA 开源项目页面。我见过的其他转换器是专有的，并且这些材料明显缺乏成功案例和详细的示例代码。NACA 值得长期关注。

7/4 更新： @Ira Baxter 报告说 Java 输出看起来非常 Cobol 式的，它确实如此。对我来说，这是自动翻译的自然结果。我怀疑我们永远找不到更好的翻译。这或许支持渐进式重写方法。

2/7/11 更新： @spgennard 指出 JVM 上有一些 Cobol 编译器，例如 Veryant 的isCobol Evolve。这些可用于帮助逐步转换代码库，尽管我认为 OP 对自动源转换更感兴趣。

我会对此非常谨慎。（我曾经在一家为 Y2K 自动更正Cobol 和 PL/I 程序的公司工作，并做过前端编译器，将 Cobol 的许多方言转换为我们的中间分析形式，也是一个代码生成器。）我的感觉是你最终会得到一个 Java 代码库，但使用起来仍然不够优雅且令人不满意。您可能会遇到性能问题、对供应商提供的库的依赖、生成的代码有问题等等。你肯定会招致巨额的测试费用。

从头开始采用新的面向对象设计可能是正确的方法，但您还必须仔细考虑代码库所代表的数十年的存储知识。通常，您的新代码可能会遗漏许多细微之处。另一方面，如果您很难找到维护遗留系统的人员，您可能别无选择。

一种渐进的方法是首先升级到 Cobol 97。这增加了面向对象，因此您可以在添加新功能时单独重写和重构子系统。或者，您可以用新编写的 Java 替换单个子系统。

有时您可以用现成的软件替换组件：我们帮助了一家非常大的保险公司，该公司在 1950 年代创建的遗留语言中仍有 200 万行代码。我们将其中的一半转换为符合 Y2K 的遗留语言，他们用从外部供应商处购买的现代工资系统替换了另一半。

于 2009-06-23T05:37:37.753 回答
4

显然，我们的意图是获得与原始 cobol 非常接近的初始 java 代码，以促进人们的迁移：他们发现他们用 cobol 编写的旧应用程序具有完全相同的结构。

我们最重要的目标之一是让最初的开发人员参与进来：这就是我们找到实现它的方式。当应用程序迁移到 Java 时，这些人可以在进一步开发/重构时开始使其更加 OO。

如果您不关心移民，您可以使用其他策略。

这种 1 对 1 的转换还使 100% 的自动转换更简单、更快：好的结果是我们更快地节省了经常性储蓄（300 万欧元/年）：我们估计需要 12-18 个月。这些早期的节省显然可以再投资于 OO 重构

请随时与我联系：didier.durand@publicitas.com 或 mediaandtech@gmail.com

迪迪埃

于 2009-07-05T04:07:20.663 回答
3

我刚刚查看了 NACA 页面和文档。从他们的文档中：

“生成的 java 使用类似 Cobol 的语法。它与原始 Cobol 语法尽可能接近，当然在 Java 语言的限制范围内。生成的代码看起来不像经典的原生 java，并且从应用程序的角度来看不是面向对象的观点。这是一个设计上的强选择，使 Cobol 开发人员能够顺利迁移到 Java 环境。目标是让编写原始 Cobol 程序的人掌握业务知识。

我没有看到一个例子，但引用给出了结果的强烈味道。它的 COBOL 用 Ja​​va 编码。

您始终可以通过简单地用目标语言编写解释器来构建从一种语言到另一种语言的“翻译器”。恕我直言，这是一种绝对糟糕的翻译语言的方式，因为您最终会遇到两全其美的情况：您没有获得新语言的价值，并且您仍然必须了解旧语言才能使结果保持活力。（难怪这东西被称为“转码器”；我以前从未听说过这个词）。

这个噱头的论据是倾销大型机的成本。哪里有证据表明在转换后的程序上工作的成本不会超过节省的成本？我怀疑事实是运营人员通过抛弃大型机降低了成本，他们不在乎维护任务变得更加昂贵。虽然这对于运营人员来说可能是合理的，但对于整个组织来说，这是一个愚蠢的选择。

天堂帮助那些成为这个工具受害者的人。

编辑 2010 年 5 月：我找到了 NACA 输出的示例；他们的测试用例之一 。这绝对是壮丽的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();
  }

孩子们：这只能由专业人士完成。不要在家里尝试这个。

于 2009-06-30T05:07:34.490 回答
2

我的经历类似，但略有不同。我们在 Ada 中有一个庞大而古老的代码库（0.5Mloc 超过 15 年），最近被转换为 Java。它被外包给一家提供自动/手动转换组合的公司。他们还进行了测试以验证 Ada 和 Java 系统的行为是否相同。

它的某些部分是用 Ada 95 编写的（即有可能是 OOP），但大部分不是

现在是的，该代码一开始并没有达到用 Java 编写的代码的相同标准，但是我们从那时起就成功地使用了它（现在 18 个月），没有出现重大问题。我们获得的主要优势是现在我们可以找到更多具有生成可维护代码的技能的开发人员来维护我们的代码库。（任何人都可以使用 Ada 进行开发，但就像任何其他语言一样，如果您没有这方面的经验，您最终可能会得到无法维护的代码）

于 2009-06-24T02:44:18.047 回答
2

从风险规避的角度来看，NACA 方法绝对有意义。重用他们的工具可能不会。他们使用这些工具的开发来让他们的员工快速掌握 java 和 linux。

NACA 转换的结果将不够好，甚至 OO，并且很难雇用新人。但它是可测试的，可以重构，并且您可以插入更好的翻译器。

[编辑] 艾拉，你似乎不太有风险意识。

将 cobol 程序员送到 Java 课程不会让他们编写可用的面向对象代码。那需要几年时间。在那段时间，他们的生产力会很低，你基本上可以把他们第一年写的所有代码都扔掉。此外，您将失去 10-20% 的程序员，他们不愿意或没有能力进行过渡。很多人不喜欢回到初学者状态，这会影响排序，因为一些程序员比其他程序员更快地掌握新语言。

NACA 方法允许企业继续工作，并且不会对组织施加不必要的压力。转换的时间安排是独立的。拥有一个由 OO 专家编写的 Java 翻译器，可以让老团队逐渐接触到 Java。编写测试用例增加了新 Java 团队的领域知识。

真正的 oo 系统是翻译器，这是插入更好的翻译器的地方。让它很容易做到这一点，您不必接触生成的代码。如果生成的代码足够丑陋，那将自动发生：:)

  • 老程序员会改变cobol输入；
  • 新的 java 将改变翻译器。

[运行翻译一次] 是一个糟糕的策略。不要那样做。如果您需要编辑生成的代码，请维护一个映射回来。这可以自动化。并且应该是。在 Smalltalk 图像中做这些事情要容易得多，但你可以用文件来做。有很多经验丰富的人对同一个工件保持不同的看法：想到芯片设计师。

应该对翻译器进行检测，因此您可以创建例如的每日计数

  • cobol 输入组件；
  • OO java输入组件；
  • cobol 风格的输出组件；
  • OO 风格的输出组件。

您可能想阅读：Peter van den Hamer & Kees Lepoeter (1996) 管理设计数据：CAD 框架、配置管理和数据管理的五个维度，IEEE 会议记录，卷。84，第1号，1996年1月

[迁移 Cobol 平台] 从大型机上的 Cobol 迁移到 Windows/Linux 上的 Cobol 对于 NACA 团队来说可能是一个可行的策略，但问题在于迁移到 java。如果长期目标是拥有一个现代化的 OO 系统，并以尽可能低的运营风险实现目标，那么 NACA 方法是合理的。不过，这只是第一步。大量的重构将随之而来。

于 2009-07-02T14:00:03.480 回答
2

我很惊讶没有人提到 Semantic Design 的 DMS Software Reengineering Toolkit。我过去研究过 COBOL 转换。那时我正在研究“自动编程”。在编写翻译器之前，我查阅了该领域之前的一系列努力和产品。Semantic Designs 的基于 GLR 的工具是其中最好的。

那是很多年前的事了。当时，该工具将 COBOL 翻译成现代语言，对其进行重构，将其打印出来等等。现在是它的链接。

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

他们还在附近。他们已经扩展了工具。它更笼统。它可能会帮助人们进行自动转换或自定义转换工具。它被设计为可扩展和可调整的，类似于 Stephan 指出的。感谢 Cyrus 也提到了 SoftwareMining。如果我将来遇到 COBOL 迁移，我也会研究它们。

于 2013-04-02T18:58:50.357 回答
1

你说的是再造。好消息是全世界很多人都在尝试这样做。不好的是，遗留应用程序再造存在很多问题：从缺少源代码到编译器构造和图论领域的复杂算法。

自动翻译的想法非常流行，直到您尝试转换某些东西。通常结果是可怕的和不可维护的。它比原来的复杂应用程序更难以维护。从我的角度来看，每一个允许从传统语言自动翻译到现代语言的工具都非常面向营销：它准确地表达了人们想要听到的“将你的应用程序从......翻译一次，然后忘记！”，而不是你购买合同，然后您就会明白您非常依赖该工具（因为没有它您无法对您的应用程序进行任何更改！）。

另一种方法是“理解”：该工具可以让您非常详细地了解您的遗留应用程序。您可以将其用于维护、记录或在新平台上重新发明。

在 Microfocus 去年收购 Modernization Workbench 并将开发转移到另一个国家之前，我对Modernization Workbench的历史略知一二。有大量复杂的分析工具，以及支持的目标语言（包括 Java）。但是没有客户端真正使用自动代码生成，所以生成部分的开发被冻结了。据我所知，PL/I 支持大部分已实施，但从未完成。但是您仍然可以尝试，可能这就是您要寻找的。

于 2009-07-08T15:26:02.540 回答