Опыт миграции устаревшего Cobol/PL1 на Java
ОРИГИНАЛ В: Мне интересно, имел ли кто-нибудь опыт миграции большой кодовой базы Cobol/PL1 на Java?
Насколько автоматизирован был процесс и насколько обслуживаемым был выход?
Как прошел переход от транзакционного к ОО?
Буду благодарен за любые извлеченные уроки или ресурсы / официальные документы, которые могут быть полезны.
РЕДАКТИРОВАТЬ 7/7: Конечно, подход NACA интересен, возможность продолжать вносить изменения BAU в код COBOL вплоть до выпуска версии JAVA имеет смысл для любой организации.
Аргумент для процедурной Java в той же компоновке, что и COBOL, чтобы дать кодировщикам ощущение комфорта при ознакомлении с языком Java, является действительным аргументом для большой организации с большой базой кода. Как отмечает @Didier, ежегодная экономия в 3 миллиона долларов дает возможность щедрого дополнения любых изменений в BAU, которые будут продолжены для проведения рефакторинга кода на постоянной основе. По его словам, если вы заботитесь о своих людях, вы найдете способ сделать их счастливыми, одновременно бросая им вызов.
Проблема, как я вижу, с предложением от @duffymo
Лучше всего попытаться понять проблему с самого начала и переформулировать ее как объектно-ориентированную систему.
в том, что если у вас есть какие-либо изменения BAU, продолжающиеся, то в течение срока действия проекта LONG кодирования вашей новой ОО-системы вы в конечном итоге завершите кодирование и тестирование изменений на двойном уровне. Это главное преимущество подхода NACA. У меня был некоторый опыт миграции клиент-серверных приложений в веб-реализацию, и это была одна из основных проблем, с которой мы столкнулись, постоянно меняющиеся требования из-за изменений BAU. Это сделало PM & планирование реальной проблемой.
Благодаря @hhafez, чей опыт хорошо обозначен как "похожий, но немного другой" и имеет достаточно удовлетворительный опыт автоматической миграции кода с Ada на Java.
Спасибо @Didier за помощь, я все еще изучаю ваш подход, и если у меня есть какие-либо вопросы, я напишу вам строку.
7 ответов
Обновление 6/25: друг только что наткнулся на конвертер NACA Cobol в Java. Выглядит довольно интересно, он был использован для перевода 4-х метровых линий Cobol со 100% точностью. Вот страница проекта с открытым исходным кодом NACA. Другие конвертеры, которые я видел, были проприетарными, и в материалах явно отсутствовали истории успеха и подробный пример кода. НАКА стоит долго смотреть.
Обновление 7/4: @Ira Baxter сообщает, что вывод Java выглядит очень по-кобольски, что он и делает. Для меня это естественный результат автоматического перевода. Я сомневаюсь, что мы когда-нибудь найдем намного лучшего переводчика. Возможно, это говорит о постепенном переписывании.
Обновление 2/7/11: @spgennard указывает, что в JVM есть несколько компиляторов Cobol, например isCobol Evolve от Veryant. Их можно использовать для постепенного перехода к кодовой базе, хотя я думаю, что OP больше интересовался автоматическим преобразованием исходного кода.
Я был бы очень осторожен с этим. (Раньше я работал в компании, которая автоматически исправляла программы на Cobol и PL/I для Y2K, и делал внешний компилятор, который преобразовывал многие диалекты Cobol в нашу промежуточную аналитическую форму, а также генератор кода.) Я чувствую, что вы в конечном итоге с базой кода Java, с которой все равно было бы не элегантно и неудовлетворительно работать. Вы можете столкнуться с проблемами с производительностью, зависимостями от предоставленных поставщиком библиотек, сгенерированным кодом, который содержит ошибки, и так далее. Вы наверняка понесете огромный счет за тестирование.
Начинать с нуля с новым объектно-ориентированным дизайном может быть правильным подходом, но вы также должны тщательно рассмотреть десятилетия хранимых знаний, представленных базой кода. Часто есть много тонкостей, которые может пропустить ваш новый код. С другой стороны, если вам сложно найти сотрудников для поддержки устаревшей системы, у вас может не быть выбора.
Одним из постепенных подходов было бы сначала обновить Cobol 97. Это добавляет объектную ориентацию, поэтому вы можете переписывать и реорганизовывать подсистемы индивидуально при добавлении новых функций. Или вы можете заменить отдельные подсистемы на недавно написанную Java.
Иногда вы сможете заменить компоненты на готовое программное обеспечение: мы помогли одной очень крупной страховой компании, у которой еще было 2 млн строк кода на унаследованном языке, который она создала в 1950-х годах. Мы преобразовали половину из этого в унаследованный язык Y2K, и они заменили другую половину современной системой начисления заработной платы, которую они купили у внешнего продавца.
Мы явно стремились получить исходный код Java, который был очень близок к исходному коболу, чтобы облегчить миграцию людей: они находят старое доброе приложение, которое они написали на коболе, в точно такой же структуре.
одна из наших самых важных целей состояла в том, чтобы поддерживать первых разработчиков: так мы и добились этого. Когда приложение мигрирует на Java, эти люди могут начать делать его более интересным, поскольку они продолжают его разрабатывать / реорганизовывать.
Если вас не волнует миграция людей, вы можете использовать другую стратегию.
Это преобразование 1: 1 также сделало 100% автоматическое преобразование более простым и быстрым: хорошее следствие - мы сделали наши постоянные сбережения (3 миллиона евро в год) намного быстрее: по нашим оценкам, 12-18 месяцев. Эти ранние сбережения могут быть реинвестированы в рефакторинг OO
не стесняйтесь связаться со мной: didier.durand@publicitas.com или mediaandtech@gmail.com
Didier
Я только что посмотрел на страницу NACA и документы. Из их документации:
"Сгенерированный java использует синтаксис, подобный Cobol. Он настолько близок, насколько это возможно, к оригинальному синтаксису Cobol, конечно, в пределах языка Java. Сгенерированный код не похож на классический нативный Java и не ориентирован на объект с точки зрения приложения. Это отличный выбор для обеспечения плавного перехода разработчиков Cobol в среду Java. Цель - сохранить знания бизнеса в руках людей, которые написали оригинальные программы Cobol ".
Я не видел пример, но цитата дает сильный аромат результата. Его COBOL написан на Java.
Вы всегда можете создать "Переводчик" с одного языка на другой, просто кодируя переводчик в целевом языке. ИМХО, это абсолютно ужасный способ перевести язык, так как вы получаете худшее из обоих миров: вы не понимаете ценность нового языка, и вам все равно нужно знать старый, чтобы сохранить результат. (Неудивительно, что это называется "Транскодер"; раньше я никогда не слышал этот термин).
Аргументом для этого трюка является снижение стоимости мэйнфрейма. Где доказательства того, что затраты на работу по преобразованной программе не уменьшают экономию? Я подозреваю, что правда состоит в том, что люди, занимающиеся операциями, снизили свою стоимость, выгружая мэйнфрейм, и им было наплевать, что задачи обслуживания стали дороже. В то время как это может быть рациональным для рабочих, это глупый выбор для организации в целом.
Небеса помогают людям, которые являются жертвами этого инструмента.
РЕДАКТИРОВАТЬ Май 2010: я нашел пример выходных данных 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();
}
Дети: это делают только профессионалы. Не пытайтесь делать это дома.
С точки зрения избежания рисков, подход NACA абсолютно оправдан. Повторное использование их инструментов не может. Они использовали разработку инструментов, чтобы помочь своим людям освоить Java и Linux.
Результат преобразования NACA не будет достаточно хорошим или даже неоправданным, и затруднит наем новых людей. Но это тестируемый, может быть реорганизован, и вы можете подключить лучшие переводчики.
[править] Ира, ты, кажется, не очень осведомлен о риске.
Отправка программистов на Cobol в Java-курс не заставит их писать полезный объектно-ориентированный код. Это занимает несколько лет. В течение этого времени их производительность будет очень низкой, и вы в основном можете выбросить весь код, который они пишут в первый год. Кроме того, вы потеряете 10-20% ваших программистов, которые не хотят или не способны осуществить переход. Многим людям не нравится возвращаться к статусу новичка, и это повлияет на порядок клевания, так как некоторые программисты воспринимают новый язык намного быстрее, чем другие.
Подход NACA позволяет бизнесу продолжать работать и не оказывает ненужного давления на организацию. График конвертации не зависит. Наличие отдельного переводчика, написанного на Java, написанного экспертами OO, позволяет постепенно использовать Java для старой команды. Написание тестовых примеров увеличивает знание предметной области в новой команде Java.
Настоящая система - это переводчик, и именно здесь можно подключить лучших переводчиков. Сделайте это легко, и вам не нужно прикасаться к сгенерированному коду. Если сгенерированный код достаточно уродлив, то это произойдет автоматически::)
- старые программисты изменят ввод cobol;
- новые java изменит переводчика.
[запуск переводчика один раз] - плохая стратегия. Не делай этого. И если вам нужно отредактировать сгенерированный код, сохраните отображение обратно. Это может быть автоматизировано. И должно быть. Гораздо проще делать подобные вещи в образе Smalltalk, но вы можете делать это с файлами. Есть люди с большим опытом работы с разными взглядами на один и тот же артефакт: на ум приходят дизайнеры чипов.
Переводчик должен быть проинструктирован, чтобы вы могли создавать ежедневные счета, например,
- входные компоненты кобола;
- OO Java входные компоненты;
- компоненты вывода в стиле кобол;
- Компоненты вывода в стиле OO.
Возможно, вам захочется прочитать: Peter van den Hamer & Kees Lepoeter (1996) Управление данными проектирования: пять измерений платформ САПР, управление конфигурацией и управление данными, материалы IEEE, Vol. 84, № 1, январь 1996 г.
[перемещение платформ Cobol] Переход с Cobol на мэйнфрейме на Cobol в Windows/Linux мог бы стать жизнеспособной стратегией для команды NACA, но вопрос был в том, чтобы перейти на Java. Если долгосрочная цель состоит в том, чтобы иметь современную ОО-систему и достичь ее с минимально возможным операционным риском, подход NACA является разумным. Это только первый шаг. Много рефакторинга будет следовать.
Мой опыт похож, но немного отличается. У нас есть большая и старая кодовая база в Аде (0.5Mloc за 15 с лишним лет), которая была недавно преобразована в Java. Он был передан компании, которая предоставила комбинацию автоматического / ручного преобразования. Они также провели тестирование, чтобы убедиться, что системы Ada и Java ведут себя одинаково.
Некоторые его части были написаны на Аде 95 (т.е. имели возможность ООП), но большая часть этого не была
Да, код в первую очередь не соответствует тем же стандартам кода, написанного на Java, но с тех пор мы успешно его используем (уже 18 месяцев) без каких-либо серьезных проблем. Основное преимущество, которое мы получили, заключалось в том, что теперь мы можем найти больше разработчиков, которые будут поддерживать нашу кодовую базу с навыками создания поддерживаемого кода. (Любой может развиваться в Ada, но, как и любой другой язык, если у вас нет опыта работы с ним, вы можете получить не поддерживаемый код)
Я удивлен, что никто не упомянул набор инструментов для реинжиниринга программного обеспечения DMS от Semantic Design. Я смотрел на преобразование COBOL в прошлом. Я тогда работал над "автоматическим программированием". Прежде чем написать переводчик, я посмотрел несколько предыдущих работ и продуктов в этой области. Основанный на GLR инструмент Semantic Designs был лучшим из множества.
Это было много лет назад. В то время инструмент переводил COBOL на современный язык, реорганизовывал его, печатал и т. Д. Вот ссылка на него сейчас.
http://www.semdesigns.com/Products/DMS/DMSToolkit.html
Они все еще рядом. Они расширили инструмент. Это более общее. Это может помочь людям, которые выполняют автоматические преобразования или настраивают инструмент преобразования. Он разработан, чтобы быть расширяемым и настраиваемым так же, как указывал Стефан. Спасибо Cyrus также за упоминание SoftwareMining. Я тоже посмотрю их, если столкнусь с миграцией на COBOL в будущем.
Вы говорите о реинжиниринге. Хорошо, что многие люди во всем мире пытаются это сделать. Плохо то, что существует много проблем, связанных с реинжинирингом устаревших приложений: начиная с отсутствующих источников и заканчивая сложными алгоритмами из областей компиляции и теории графов.
Идея автоматического перевода очень популярна, пока вы не попробуете что-то преобразовать. Обычно результат ужасен и недостижим. Это более не поддерживаемо, чем оригинальное сложное приложение. С моей точки зрения, каждый инструмент, который позволяет автоматический перевод с унаследованного на современный язык, очень ориентирован на маркетинг: он говорит именно то, что люди хотят услышать, "переведите ваше приложение с... на Java один раз и забудьте!", Чем вы. покупая контракт, и тогда вы понимаете, что вы очень сильно зависите от инструмента (потому что вы не можете вносить изменения в свое приложение без него!).
Альтернативный подход - "понимание": инструмент, который позволяет вам очень детально понять ваше унаследованное приложение. И вы можете использовать его для обслуживания, документирования или для переизобретения на новой платформе.
Я немного знаком с историей Modernization Workbench до того, как Microfocus купил ее в прошлом году и перенес разработку в другую страну. Было множество сложных инструментов анализа и множество поддерживаемых целевых языков (включая Java). Но ни один клиент не использовал автоматическую генерацию кода, поэтому разработка части генерации была приостановлена. Насколько я знаю, поддержка PL/I была в основном реализована, но она так и не была закончена. Но все же вы можете попробовать, может быть, это то, что вы ищете.