Опыт переноса устаревшего Cobol / PL1 на Java
https://stackoverflow.com/questions/1029974
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
ИСХОДНЫЙ Q: Мне интересно, был ли у кого-нибудь опыт переноса большой кодовой базы Cobol / PL1 на Java?
Насколько автоматизирован был этот процесс и насколько удобен в обслуживании результат?
Как прошел переход от транзакционного подхода к OO?
Мы были бы признательны за любые уроки, извлеченные на этом пути, или за ресурсы / официальные документы, которые могут оказаться полезными.
ПРАВКА 7/7: Безусловно, подход NACA интересен, возможность продолжать вносить свои BAU-изменения в код COBOL вплоть до выпуска версии JAVA имеет преимущество для любой организации.
Аргумент в пользу процедурной Java в той же компоновке, что и COBOL, чтобы дать программистам ощущение комфорта при ознакомлении с языком Java, является веским аргументом для крупной организации с большой базой кода.Как отмечает @Didier, ежегодная экономия в размере 3 миллионов долларов дает возможность щедро дополнять любые изменения BAU в будущем для постоянного рефакторинга кода.По его словам, если вы заботитесь о своих людях, вы находите способ сделать их счастливыми, постепенно бросая им вызов.
Проблема, на мой взгляд, связана с предложением от @duffymo
Лучше всего попытаться действительно понять проблему в ее корнях и переформулировать ее как объектно-ориентированную систему
заключается в том, что если у вас есть какие-либо текущие изменения BAU, то в течение ДЛИТЕЛЬНОГО срока службы проекта по кодированию вашей новой OO-системы вы в конечном итоге кодируете и тестируете изменения дважды.Это главное преимущество подхода NACA.У меня был некоторый опыт переноса клиент-серверных приложений в веб-реализацию, и это была одна из основных проблем, с которыми мы столкнулись, постоянно меняющиеся требования из-за изменений BAU.Это превратило PM & планирование в настоящую проблему.
Спасибо @hhafez, чей опыт прекрасно изложен в виде "похожий, но немного другой" и имел достаточно удовлетворительный опыт автоматической миграции кода с Ada на Java.
Спасибо @Didier за вклад, я все еще изучаю ваш подход, и если у меня возникнут какие-либо вопросы, я напишу вам.
Решение
Обновление 6/25. друг только что наткнулся на NACA Конвертер Cobol в Java. Выглядит довольно интересно, он был использован для перевода 4-х метровых линий Cobol со 100% точностью. Вот страница проекта с открытым исходным кодом NACA . Другие конвертеры, которые я видел, были проприетарными, и в материалах явно отсутствовали истории успеха и подробный пример кода. НАКА стоит долго смотреть.
Обновление 7/4: @Ira Baxter сообщает, что вывод Java выглядит очень по-кобольски, что он и делает. Для меня это естественный результат автоматического перевода. Я сомневаюсь, что мы когда-нибудь найдем намного лучшего переводчика. Возможно, это говорит о постепенном переписывании.
Обновление от 2/7/11: @spgennard указывает, что в JVM есть несколько компиляторов Cobol, например, isCobol Evolve . Их можно использовать для постепенного перехода к базе кода, хотя я думаю, что OP больше интересовался автоматическим преобразованием исходного кода.
<Ч>Я буду очень осторожен с этим. (Раньше я работал в компании, которая автоматически исправляла программы на Cobol и PL / I для Y2K, и делал компилятор внешнего интерфейса, который преобразовывал многие диалекты Cobol в нашу промежуточную аналитическую форму, а также генератор кода .) Я чувствую, что у вас получится Java-кодовая база, с которой по-прежнему будет сложно работать. Вы можете столкнуться с проблемами с производительностью, зависимостями от предоставленных поставщиком библиотек, сгенерированным кодом, который содержит ошибки, и так далее. Вы наверняка понесете огромный счет за тестирование.
Начинать с нуля с новым объектно-ориентированным дизайном может быть правильным подходом, но вы также должны тщательно рассмотреть десятилетия хранимых знаний, представленных базой кода. Часто есть много тонкостей, которые может пропустить ваш новый код. С другой стороны, если вам трудно найти сотрудников для поддержки устаревшей системы, у вас может не быть выбора.
Одним из постепенных подходов было бы сначала обновить Cobol 97. Это добавляет объектную ориентацию, так что вы можете переписывать и реорганизовывать подсистемы индивидуально при добавлении новых функций. Или вы можете заменить отдельные подсистемы на недавно написанную Java.
Иногда вы сможете заменить компоненты на готовое программное обеспечение: мы помогли одной очень крупной страховой компании, у которой еще было 2 млн строк кода на устаревшем языке, который она создала в 1950-х годах. Мы преобразовали половину из этого в унаследованный язык Y2K, и они заменили другую половину современной системой начисления заработной платы, которую они купили у внешнего продавца.
Другие советы
Очевидно, что нашим намерением было получить исходный код java, который был бы очень близок к оригинальному cobol, чтобы облегчить миграцию людей:они находят старое доброе приложение, которое они написали на cobol, в точно такой же структуре.
одной из наших самых важных целей было удержать первоначальных разработчиков на борту:вот какой способ мы нашли для достижения этой цели.Когда приложение мигрирует на Java, эти люди могут начать делать его более OO по мере дальнейшей разработки / рефакторинга.
Если вас не волнует миграция людей, вы можете использовать другую стратегию.
Это преобразование 1 к 1 также сделало 100% автоматизированное преобразование более простым и быстрым:хорошим следствием этого является то, что мы значительно быстрее добились нашей постоянной экономии (3 миллиона евро в год):мы оцениваем это через 12-18 месяцев.Очевидно, что эти ранние сбережения могут быть реинвестированы в рефакторинг OO
не стесняйтесь обращаться ко мне:didier.durand@publicitas.com или mediaandtech@gmail.com
didier
Мой опыт похож, но немного отличается. У нас есть большая и старая кодовая база в Аде (0.5Mloc за 15 с лишним лет), которая была недавно преобразована в Java. Это было передано компании, которая предоставила комбинацию автоматического / ручного преобразования. Они также провели тестирование, чтобы убедиться, что системы Ada и Java ведут себя одинаково.
Некоторые его части были написаны на Аде 95 (т.е. имели возможность ООП), но большая часть этого не была
Теперь да, код не соответствует тем же стандартам кода, написанного на Java, но мы с тех пор успешно используем его (18 месяцев) без каких-либо серьезных проблем. Основное преимущество, которое мы получили, заключалось в том, что теперь мы можем найти больше разработчиков, которые будут поддерживать нашу кодовую базу с навыками создания поддерживаемого кода. (Любой может развиваться в Ada, но, как и любой другой язык, если у вас нет опыта работы с ним, вы можете получить не поддерживаемый код)
С точки зрения предотвращения рисков подход NACA абсолютно логичен.Повторное использование их инструментов может оказаться невозможным.Они использовали разработку инструментов, чтобы познакомить своих сотрудников с Java и Linux.
Результат преобразования NACA будет недостаточно хорошим или даже OO, что затруднит наем новых людей.Но он поддается тестированию, может быть переработан, и вы можете подключить лучшие переводчики.
[редактировать] Айра, ты, похоже, не очень-то осознаешь риск.
Отправка программистов cobol на курс Java не заставит их писать пригодный для использования объектно-ориентированный код.На это уходит несколько лет.В течение этого времени их производительность будет очень низкой, и вы можете практически выбросить весь код, который они напишут в первый год.Кроме того, вы потеряете 10-20% ваших программистов, которые не хотят или не способны осуществить переход.Многим людям не нравится возвращаться к статусу новичка, и это повлияет на иерархию, поскольку некоторые программисты осваивают новый язык намного быстрее других.
Подход NACA позволяет бизнесу продолжать работать и не оказывает ненужного давления на организацию.График преобразования не зависит от вас.Наличие отдельного транслятора на java, написанного экспертами OO, позволяет постепенно знакомить старую команду с Java.Написание тестовых примеров расширяет знания предметной области в новой команде java.
Настоящая oo-система - это переводчик, и это то место, где можно подключить лучших переводчиков.Упростите это, и вам не придется прикасаться к сгенерированному коду.Если сгенерированный код достаточно уродлив, именно это произойдет автоматически::)
- старые программисты изменят входные данные cobol;
- новые версии Java изменят переводчик.
[запуск переводчика один раз] это плохая стратегия.Не делай этого.И если вам нужно отредактировать сгенерированный код, сохраните обратное сопоставление .Это может быть автоматизировано.Так и должно быть.Намного проще делать подобные вещи в образе Smalltalk, но вы можете сделать это с помощью файлов.Есть люди с большим опытом, придерживающиеся разных взглядов на один и тот же артефакт:на ум приходят дизайнеры чипов.
Переводчик должен быть оснащен инструментами, чтобы вы могли создавать ежедневные подсчеты, например
- входные компоненты cobol;
- Компоненты ввода OO java;
- выходные компоненты в стиле cobol;
- Компоненты вывода в стиле OO.
Возможно, вы захотите почитать:Питер ван ден Хамер и Кис Лепоутер (1996) Управление проектными данными:The Five Dimensions of CAD Framework, Управление конфигурацией и управление данными, Proceedings of the IEEE, Vol.84, Нет.1 января 1996 года
[переход на платформы Cobol] Переход с Cobol на мэйнфреймах на Cobol на Windows / Linux мог бы стать жизнеспособной стратегией для команды NACA, но вопрос заключался в переходе на java.Если долгосрочной целью является создание современной системы OO и достижение этой цели с как можно меньшим операционным риском, то подход NACA является разумным.Однако это только первый шаг.За этим последует большой рефакторинг.
Я удивлен, что никто не упомянул набор инструментов для реинжиниринга программного обеспечения DMS от Semantic Design. Я смотрел на преобразование COBOL в прошлом. Я работал над "автоматическим программированием" тогда Прежде чем написать переводчик, я посмотрел кучу предыдущих работ и продуктов в этой области. Основанный на GLR инструмент Semantic Designs был лучшим из множества.
Это было много лет назад. В то время инструмент переводил COBOL на современный язык, реорганизовывал его, печатал и т. Д. Вот ссылка на него сейчас.
Вы говорите о реинжиниринге . Хорошо, что многие люди во всем мире пытаются это сделать. Плохо то, что существует много проблем, связанных с реинжинирингом устаревших приложений: начиная с отсутствующих источников и заканчивая сложными алгоритмами из областей построения компилятора и теории графов.
Идея автоматического перевода очень популярна, пока вы не попробуете что-то преобразовать. Обычно результат ужасен и недостижим. Это более не поддерживаемо, чем оригинальное сложное приложение. С моей точки зрения, каждый инструмент, который позволяет автоматический перевод с унаследованного на современный язык, очень ориентирован на маркетинг: он точно говорит о том, что люди хотят услышать, "перевести ваше приложение с ... на Java один раз и забыть!", Чем вы покупаете контракт, и тогда вы понимаете, что очень сильно зависите от инструмента (потому что вы не можете вносить изменения в свое приложение без него!).
Альтернативный подход - это «понимание»: инструмент, который позволяет вам очень детально понять ваше унаследованное приложение. И вы можете использовать его для обслуживания, документирования или для переизобретения на новой платформе.
Я немного знаком с Модернизацией Workbench до того, как Microfocus купил ее в прошлом году, и перенес развитие в другую страну. Было множество сложных инструментов анализа и множество поддерживаемых целевых языков (включая Java). Но ни один клиент не использовал автоматическую генерацию кода, поэтому разработка части генерации была приостановлена. Насколько я знаю, поддержка PL / I была в основном реализована, но она так и не была закончена. Но все же вы можете попробовать, может быть, это то, что вы ищете.
Я только что посмотрел страницу NACA и документы. Из их документации:
" сгенерированный java использует Cobol-подобный синтаксис. Это как можно ближе к оригинальному синтаксису Cobol, конечно же, в пределах языка Java. Сгенерированный код не похож на классический нативный Java и не является объектно-ориентированным с точки зрения приложения. Это отличный выбор, чтобы обеспечить плавную миграцию разработчиков Cobol в среду Java. Цель состоит в том, чтобы держать деловые знания в руках людей, написавших оригинальные программы на Cobol. & Quot;
Я не видел пример, но цитата дает сильный оттенок результата. Его 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();
}
Дети: это делают только профессионалы. Не пытайтесь делать это дома.
