Искусственный интеллект обновит legacy-код за вас

Автор оригинала: Dexter Johnson
  • Перевод
Инструменты IBM на основе искусственного интеллекта дают инженерам возможность исследовать способы применения устаревшего корпоративного ПО.

В прошлом году компания IBM продемонстрировала, как ИИ может выполнять монотонную работу по обслуживанию программного обеспечения благодаря обновлению устаревшего кода. Теперь компания представила методы на основе ИИ для перекодирования старых приложений, чтобы они могли работать на современных вычислительных платформах.



Последние проекты IBM под названием Mono2Micro и Application Modernization Accelerator (AMA) предоставляют архитекторам приложений инструменты для обновления устаревших приложений и повторного их применения. По словам Ника Фуллера, директора по гибридным облачным сервисам в исследовательской лаборатории IBM Research, эти инициативы позволяют приблизить момент, когда ИИ сможет автоматически перевести программу с COBOL на Java.

Но Фуллер отмечает, что эти передовые подходы на основе ИИ на данный момент способны только разбивать устаревший машинный код монолитных программ на отдельные микросервисы. Для выполнения полноценного перевода с одного языка программирования на другой остается сделать еще один шаг, потому что инструментарий AMA хоть и предназначен для модернизации COBOL, на данный момент он обеспечивает лишь очередной этап в этом процессе. «Перевод с одного языка на другой является фундаментальной проблемой для ИИ, над которой мы работаем, чтобы часть этого устаревшего кода функционировала на современном программном языке», — добавил он.

А пока передовые инструменты IBM на основе искусственного интеллекта предлагают некоторые новые возможности. Что касается Mono2Micro, этот инструмент сначала анализирует старый код, чтобы выявить все скрытые связи внутри него, например, различные компоненты в базовой бизнес-логике, содержащие многочисленные вызовы и связи друг с другом. Самостоятельное выполнение такой задачи было бы для архитектора приложений очень сложным и затратным по времени.

Mono2Micro использует методы кластеризации на основе ИИ для объединения похожих кодов в группы, что более наглядно показывает, как группы кодов взаимодействуют. Сначала Mono2Micro принимает код, затем анализирует исходный и объектный код как статически (анализируя программу перед запуском), так и динамически (анализируя программу во время ее выполнения).

Затем инструмент преобразовывает монолитные программы на основе Java и связанную с ними бизнес-логику и пользовательские интерфейсы в микросервисы. Рефакторинг монолита в отдельные микросервисы с конкретными функциями сводит к минимуму связи, которые существовали в программном обеспечении, когда оно было монолитной программой, изменяя структуру приложения без изменения его внешнего поведения.

Целью инструментария AMA является как анализ, так и рефакторинг ранее разработанных приложений, написанных на устаревших языках (COBOL, PL/I). Что касается инструментария AMA, он сочетает статический анализ исходного кода с пониманием структуры приложения для создания графа, который представляет устаревшее приложение. При использовании совместно с методами глубокого обучения этот подход на основе графов облегчает сохранение данных.


Изображение: IBM Research
Изображение интерфейса Mono2Micro


Стратегия IBM в области искусственного интеллекта направлена ​​на решение ключевых проблем машинного обучения, когда входные данные — код, и параметры для анализа — объем и множественные значения. Важные устаревшие приложения обычно содержат от сотен тысяч до миллионов строк кода. В этом контексте применение методов машинного обучения (ML) к таким большим объемам данных можно сделать более эффективным с помощью концепции встраивания.

Эти слои внедрения представляют собой способ преобразования данных в числовые значения. Преимущество метода встраивания заключается в том, что он позволяет присвоить числовое выражение большому объему кода с множеством возможных значений. То же самое происходит, например, при переводе естественного человеческого языка в числовые значения с использованием векторного представления слов (“word” embeddings). Это также делается в контексте графа, так как это связано с анализом кода.

«Слои встраивания — это потрясающе, потому что без них было бы сложно получить что-либо, напоминающее эффективно работающую систему машинного обучения», — сказал Фуллер.
Он добавил, что в случае анализа кода система машинного обучения с каждым разом лучше предлагает микросервисы для рефакторизованного устаревшего приложения за счет репликации функционального наполнения приложения.

Фуллер отмечает: «На этом этапе вы еще не можете выдохнуть, но 70% работы позади, а значит, вы стали гораздо ближе к рефакторирнгу важного приложения в архитектуру микросервисов».
Timeweb
VDS, инфраструктура и решения для бизнеса

Комментарии 11

    –1
    Ага, а закончится это как в одном известном фильме по известному рассказу:

    image
      0
      Сможет ли кто-то поддерживать и развивать этот код после такого «рефакторинга», иначе в чем смысл такого перехода.
        0
        Думаю смысл в том, чтобы упростить добавление новых фич к модернизированному таким способом ПО. Но любой, кто когда-либо видел код после авто генерации (после декомпилятора как пример) понимает что затея так себе.
          +1

          Так код на условном COBOL и так почти никто не может поддерживать, тем более развивать. А такого кода, как я понимаю, накопилось не мало. Так что такой "рефакторинг" лучше, чем никакой.

            0
            Зачем его поддерживать и рефакторить «кому-то»? Очевидно, что в дальнейшем этот код должен поддерживаться тем-же AI, итеративно в сторону улучшения и оптимизации, без наращивания функционала. Новый функционал должен будет отдельными сервисами создаваться, и передаваться AI в «рефакторинг и поддержку». И так до полного выпиливания программистов…
            0
            Когда ИИ сможет полноценно (ключевое слово, то есть сохранив логику и не добавив новых глюков и говнокода) перевести программу с COBOL на Java, кажется сами java-программисты станут такими же мастодонтами, как ныне те, кто в юности писал на COBOL:)
              0
              Не пройдёт и пятисот лет, как задача перевода программ с Кобола может быть решена.
                0
                Я не понял, вот это «передовые подходы на основе ИИ на данный момент способны только разбивать устаревший машинный код монолитных программ на отдельные микросервисы» что означает? ИИ выдает проект микросервисной архитектуры или же работающий код?
                В первое верится легко, второе кажется практически недостижимым.
                Ну а в целом статья — бла-бла-бла, какие-то абстракции и непонятно что на выходе и как этого добились.
                  0
                  А мне кажется как раз вполне реальным перевод «машинный код из COBOL» в компилируемый проект, например, на C\С++ с совпадающей логикой. Если заняться детальным анализом, что делали эти старые компиляторы, то думаю, как минимум достаточно легко можно разделить проект на функции. А при наличии исходников и возможности скомпилировать без оптимизации реально сопоставить имена переменных и функций.
                  0
                  Мне кажется получится как в поговорке: «программист на COBOL на любом языке программирования может написать программу на COBOL».
                  Если написать "#define begin {", оно может даже скомпилироваться и работать. Но зачем?
                    0

                    Мне кажется вопрос трансляции COBOL (или чего-то еще) заключается в том, чтобы переписать в понятном, подерживаемом и современном формате. Я не вижу проблемы, скажем, если нам доступны исходники COBOL, постоить AST и затем по AST буквально транслировать операции в какой-нибудь C. В конце концов, если есть возможность вызывать методы и ездить по указателям, то можно мимикрировать под что угодно. Но это будет нечитабельно.
                    Мне сложно представить как перевести код с языка одной парадигмы на язык другой — для этого собственно и нанимаются программисты, этот процесс очень плохо автоматизируется. Если бы был доступен корпус исходных текстов на COBOL и их эквивалентов на условной JAVA, можно было бы натренировать транспайлер из одного в другое, но как это водится в ML, нужен очень большой датасет, чего я так понимаю ни у кого нет и быть не может (мало кода переписано с COBOL и все это гарантированно проприетарщина и закрыто лицензиями).


                    А кто-нибудь задавался вообще вопросом, что будет, если приложение на COBOL заменить на приложение на другом языке? Невозможно воспроизвести поведение COBOL без самого COBOL, поэтому даже если внешне приложение на COBOL и Java при одинаковом вводе всегда выдают одинаковый вывод, сама последовательность ассембелрных иснтрукций будет другая. А значит есть вариант, что при замене одной системы на другую что-то развалится — будет работать быстрее/медленнее/не так (на промежуточном уровне). И если скажем это были бы пользовательские приложения, никто бы не заметил разницы, но в каком-нибудь дата центре под высокой нагрузкой любая разница в исполняемых инструкциях и паттернах доступа к периферии может повлиять на все остальные системы.


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

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое