Опыт миграции устаревшего Cobol / PL1 на Java

Question

ОРИГИНАЛЬНЫЙ Q: Мне интересно, имел ли кто-нибудь опыт миграции большой кодовой базы Cobol / PL1 на Java?

Насколько автоматизирован был процесс и насколько обслуживаемым был выход?

Как прошел переход от транзакции к ОО?

Буду признателен за любые извлеченные уроки или ресурсы / официальные документы, которые могут быть полезны.

---

РЕДАКТИРОВАТЬ 7/7: Конечно, подход NACA интересен, возможность продолжать вносить изменения в коде COBOL в BAU вплоть до выпуска версии JAVA имеет смысл для любой организации.

Аргумент для процедурной Java в той же компоновке, что и COBOL, чтобы дать кодировщикам ощущение комфорта при ознакомлении с языком Java, является допустимым аргументом для большой организации с большой кодовой базой. Как отмечает @Didier, ежегодная экономия в 3 миллиона долларов дает возможность щедрого дополнения любых изменений в BAU, которые будут продолжены для проведения рефакторинга кода на постоянной основе. По его словам, если вы заботитесь о своих людях, вы найдете способ сделать их счастливыми, одновременно бросая им вызов.

Проблема, как я вижу, с предложением от @duffymo до

Лучше всего попробовать и действительно понять проблема в ее корнях и пересказать это как объектно-ориентированная система

заключается в том, что если у вас есть какие-либо изменения BAU, продолжающиеся, то в течение срока действия проекта LONG кодирования вашей новой ОО-системы вы в конечном итоге завершаете кодирование и тестирование изменений на двойном уровне. Это главное преимущество подхода NACA. У меня был некоторый опыт миграции клиент-серверных приложений в веб-реализацию, и это была одна из основных проблем, с которой мы столкнулись, постоянно меняющиеся требования из-за изменений BAU. Это сделало PM & планирование настоящим вызовом.

Благодаря @hhafez, чей опыт хорошо обозначен как «похожий, но немного другой» и имеет достаточно удовлетворительный опыт автоматической миграции кода с Ады на Java.

Спасибо @Didier за помощь, я все еще изучаю ваш подход, и если у меня есть какие-либо вопросы, я напишу вам строку.

Answer 1

Обновление 6/25: Друг только что наткнулся на конвертер NACA Cobol в Java. Выглядит довольно интересно, он был использован для перевода 4-х метровых линий Cobol со 100% точностью. Вот страница проекта с открытым исходным кодом . Другие конвертеры, которые я видел, были проприетарными, и в материалах явно отсутствовали истории успеха и подробный пример кода. НАКА стоит долго смотреть.

Обновление 7/4: @Ira Baxter сообщает, что вывод Java выглядит очень по-кобольски, что и делает абсолютно. Для меня это естественный результат автоматического перевода. Я сомневаюсь, что мы когда-нибудь найдем намного лучшего переводчика. Возможно, это говорит о постепенном переписывании.

Обновление от 07.07.11: @spgennard указывает, что в JVM есть несколько компиляторов Cobol, например Veryant's isCobol Evolve . Их можно использовать для постепенного перехода к базе кода, хотя я думаю, что OP больше интересовался автоматическим преобразованием исходного кода.

---

Я бы очень осторожно отнесся к этому. (Раньше я работал в компании, которая автоматически исправляла программы на Cobol и PL / I для Y2K, и делал внешний компилятор, который преобразовывал многие диалекты Cobol в нашу промежуточную аналитическую форму, а также генератор кода. Я чувствую, что у вас получится Java-кодовая база, с которой по-прежнему будет нелегко и неудовлетворительно работать. Вы можете столкнуться с проблемами с производительностью, зависимостями от предоставленных поставщиком библиотек, сгенерированным кодом, который содержит ошибки, и так далее. Вы наверняка понесете огромный счет за тестирование.

Начинать с нуля с новым объектно-ориентированным дизайном может быть правильным подходом, но вы также должны тщательно рассмотреть десятилетия хранимых знаний, представленных базой кода. Часто есть много тонкостей, которые может пропустить ваш новый код. С другой стороны, если вам сложно найти сотрудников для обслуживания устаревшей системы, у вас может не быть выбора.

Одним из постепенных подходов было бы сначала обновить Cobol 97. Это добавляет объектную ориентацию, поэтому вы можете переписывать и реорганизовывать подсистемы индивидуально при добавлении новых функций. Или вы можете заменить отдельные подсистемы на недавно написанную Java.

Иногда вы сможете заменить компоненты готовым программным обеспечением: мы помогли одной очень крупной страховой компании, у которой все еще было 2 млн строк кода на унаследованном языке, созданном в 1950-х годах. Мы конвертировали половину из этого в унаследованный язык, соответствующий требованиям 2000 года, и они заменили другую половину современной системой начисления заработной платы, которую они приобрели у стороннего поставщика.

Answer 2

Мы явно стремились получить исходный код Java, который был очень близок к исходному коболу, чтобы облегчить миграцию людей: они находят старое доброе приложение, написанное на коболе, в точно такой же структуре.

одна из наших самых важных целей состояла в том, чтобы поддерживать первых разработчиков: так мы и добились этого. Когда приложение мигрирует на Java, эти люди могут начать делать его более интересным, поскольку они продолжают его разрабатывать / реорганизовывать.

Если вас не волнует миграция людей, вы можете использовать другую стратегию.

Это преобразование 1-в-1 также сделало 100% автоматическое преобразование более простым и быстрым: хорошее следствие состоит в том, что мы сделали наши постоянные сбережения (3 миллиона евро / год) намного быстрее: мы оцениваем 12-18 месяцев. Эти ранние сбережения могут быть реинвестированы в ОО-рефакторинг

не стесняйтесь связаться со мной: didier.durand@publicitas.com или mediaandtech@gmail.com

Didier

Answer 3

Я удивлен, что никто не упомянул набор инструментов для реинжиниринга программного обеспечения DMS от Semantic Design.Я смотрел на преобразование COBOL в прошлом.Я тогда работал над «автоматическим программированием».Прежде чем написать переводчик, я посмотрел кучу предыдущих работ и продуктов в этой области.Основанный на GLR инструмент Semantic Designs был лучшим из множества.

Это было много лет назад.В то время инструмент переводил COBOL на современный язык, подвергал его рефакторингу, печатал и т. Д. Вот ссылка на него сейчас.

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

Они все еще рядом.Они расширили инструмент.Это более общее.Это может помочь людям, которые выполняют автоматические преобразования или настраивают инструмент преобразования.Он разработан, чтобы быть расширяемым и настраиваемым так же, как указывал Стефан.Спасибо Cyrus также за упоминание SoftwareMining.Я тоже посмотрю их, если столкнусь с миграцией на COBOL в будущем.

Answer 4

С точки зрения избежания риска, подход NACA абсолютно оправдан. Повторное использование их инструментов не может. Они использовали разработку инструментов, чтобы помочь своим людям освоить Java и Linux.

Результат преобразования NACA не будет достаточно хорошим или даже ОО, и затруднит найм новых людей. Но это тестируемый, может быть реорганизован, и вы можете подключить лучшие переводчики.

[править] Ира, ты, кажется, не очень осведомлен о риске.

Отправка программистов на cobol в java-курс не заставит их писать полезный объектно-ориентированный код. Это занимает несколько лет. В течение этого времени их производительность будет очень низкой, и вы в основном сможете выбросить весь код, который они пишут в первый год. Кроме того, вы потеряете 10-20% ваших программистов, которые не хотят или не способны осуществить переход. Многим не нравится возвращаться к статусу новичка, и это повлияет на порядок клевания, так как некоторые программисты воспринимают новый язык намного быстрее, чем другие.

Подход NACA позволяет бизнесу продолжать работать и не оказывает ненужного давления на организацию. График конвертации не зависит. Наличие отдельного переводчика на языке Java, написанного экспертами ОО, позволяет постепенно использовать Java для старой команды. Написание тестовых примеров увеличивает знание предметной области в новой команде Java.

Настоящая система oo - это переводчик, и именно здесь можно подключить лучших переводчиков. Сделать это легко, и вам не нужно прикасаться к сгенерированному коду. Если сгенерированный код достаточно уродлив, то это произойдет автоматически::)

• старые программисты изменят ввод cobol;
• новые java изменит переводчика.

[запускает переводчик один раз] плохая стратегия Не делай этого. И если вам нужно отредактировать сгенерированный код, сохраните отображение обратно. Это может быть автоматизировано. И должно быть. Гораздо проще делать подобные вещи в образе Smalltalk, но вы можете делать это с файлами. Есть люди с большим опытом работы с разными взглядами на один и тот же артефакт: на ум приходят дизайнеры чипов.

Переводчик должен быть инструктирован, чтобы вы могли создавать ежедневные счета, например,

• компоненты ввода кобола;
• Компоненты ввода-вывода Java;
• компоненты вывода в стиле кобол;
• Компоненты вывода в стиле OO.

Возможно, вы захотите прочитать: Peter van den Hamer & Kees Lepoeter (1996) Управление данными проектирования: пять измерений платформ САПР, управление конфигурацией и управление данными, материалы IEEE, Vol. 84, № 1, январь 1996 года

[движущиеся платформы Cobol] Переход от Cobol на мэйнфрейме к Cobol на Windows / Linux мог бы стать жизнеспособной стратегией для команды NACA, но вопрос был в том, чтобы перейти на Java. Если долгосрочная цель состоит в том, чтобы иметь современную ОО-систему и достичь ее с минимально возможным операционным риском, подход NACA является разумным. Это только первый шаг. Будет много рефакторинга.

Answer 5

Мой опыт похож, но немного другой. У нас есть большая и старая кодовая база в Аде (0.5Mloc за 15 с лишним лет), которая была недавно преобразована в Java. Это было передано компании, которая предоставила комбинацию автоматического / ручного преобразования. Они также провели тестирование, чтобы убедиться, что системы Ada и Java ведут себя одинаково.

Некоторые его части были написаны на Аде 95 (т.е. имели возможность ООП), но большая часть не была

Теперь да, код не соответствует тем же стандартам кода, написанного на Java, но мы с тех пор успешно используем его (18 месяцев) без каких-либо серьезных проблем. Основное преимущество, которое мы получили, заключалось в том, что теперь мы можем найти больше разработчиков, которые будут поддерживать нашу кодовую базу с навыками создания поддерживаемого кода. (Любой может развиваться в Ada, но, как и любой другой язык, если у вас нет опыта работы с ним, вы можете получить не поддерживаемый код)

Answer 6

Вы говорите о реинжиниринге . Хорошо, что многие люди во всем мире пытаются это сделать. Плохо то, что существует много проблем, связанных с реинжинирингом устаревших приложений: начиная с отсутствующих источников и заканчивая сложными алгоритмами из областей построения компилятора и теории графов.

Идея автоматического перевода очень популярна, пока вы не попробуете что-то преобразовать. Обычно результат ужасен и недостижим. Это более не поддерживаемо, чем оригинальное сложное приложение. С моей точки зрения, каждый инструмент, который позволяет автоматический перевод с унаследованного на современный язык, очень ориентирован на маркетинг: он говорит именно то, что люди хотят услышать, «переведите ваше приложение с ... на Java один раз и забудьте!», Чем вы. покупая контракт, и тогда вы понимаете, что вы очень сильно зависите от инструмента (потому что вы не можете вносить изменения в свое приложение без него!).

Альтернативный подход - «понимание»: инструмент, который позволяет вам очень детально понять ваше унаследованное приложение. И вы можете использовать его для обслуживания, документирования или для переизобретения на новой платформе.

Я немного знаю об Модернизационном верстаке истории до того, как Microfocus купил ее в прошлом году и перенес разработку в другую страну. Было множество сложных инструментов анализа и множество поддерживаемых целевых языков (включая Java). Но ни один клиент не использовал автоматическую генерацию кода, поэтому разработка части генерации была приостановлена. Насколько я знаю, поддержка PL / I была в основном реализована, но она так и не была закончена. Но все же вы можете попробовать, может быть, это то, что вы ищете.

Answer 7

Я только что посмотрел на страницу NACA и документы. Из их документации:

"Сгенерированный java использует Cobol-подобный синтаксис. Он настолько близок, насколько это возможно, к оригинальному синтаксису Cobol, конечно, в пределах языка Java. Сгенерированный код не похож на классический нативный Java и не является объектно-ориентированным с точки зрения приложения. Это отличный выбор, чтобы обеспечить плавную миграцию разработчиков Cobol в среду Java. Цель состоит в том, чтобы держать деловые знания в руках людей, которые написали оригинальные программы Cobol. "

Я не видел пример, но цитата дает сильный оттенок результата. Его код COBOL написан на Java.

Вы всегда можете создать «Переводчик» с одного языка на другой, просто кодирование переводчика в целевом языке. Это имхо абсолютно ужасный способ перевести язык, как вы в конечном итоге худшее из обоих миров: вы не понимаете ценность нового языка, и вам все еще нужно знать старое, чтобы сохранить результат в живых. (Неудивительно, что это называется «Транскодер»; я бы никогда слышал этот термин раньше).

Аргументом для этого трюка является снижение стоимости мэйнфрейма. Где доказательства того, что затраты на работу по преобразованной программе не заболтать сбережения? Я подозреваю, что правда в том, что люди операции снизили их стоимость, сбросив мэйнфреймы, и им было все равно что задачи по обслуживанию стали дороже. Хотя это может быть рациональным для оперативников, это глупый выбор для организации в целом.

Небеса помогают людям, ставшим жертвами этого инструмента.

РЕДАКТИРОВАТЬ Май 2010 года: я нашел пример выходных данных NACA; один из их testcases. Это абсолютно великолепный 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();
  }

Дети: это делают только профессионалы. Не пытайтесь делать это дома.