COBOL을 Java로 변환할 때 "Jobol"이라는 오류가 발생하는 이유와 이를 방지하는 방법

변환 작업은 3개월 만에 완료되었습니다. 자바 애플리케이션은 컴파일되고 기본적인 스모크 테스트를 통과하여 배포 준비가 완료되었다고 발표되었습니다. 하지만 6개월 후, 플랫폼 팀은 심각한 문제를 발견했습니다. 자바 팀원 중 누구도 코드를 유지보수할 수 없었던 것입니다. 코드 리뷰는 일반적인 자바 리뷰보다 두 배나 오래 걸렸습니다. 버그 보고서에는 메인프레임 경험이 없는 자바 개발자들이 이해할 수 없는 개념들, 예를 들어 작업 저장소(WORKING-STORAGE), 프로시저 나눗셈 논리, 팩형 십진수 필드 규칙 등이 언급되었습니다. 애플리케이션은 COBOL에서 자바로 변환되었지만, 결과적으로 만들어진 자바 코드는 사고방식, 구조, 동작 방식 모두 COBOL과 같았습니다. 마치 Jobol 같았습니다.

Jobol(때때로 JOBOL로 표기)은 COBOL의 절차적 의미론을 유지하면서도 Java의 객체 지향 기능을 활용하지 않는 Java 코드의 합성어입니다. 분석 회사 Intellyx의 설립자인 Jason Bloomberg는 Jobol을 다음과 같이 직접 정의했습니다. "Jobol은 원래 소프트웨어 아키텍처를 그대로 두고 COBOL의 의미론을 보존하는 기술적으로 유효한 Java 코드입니다. 따라서 개발자는 Java 코드를 마치 COBOL처럼 다뤄야 합니다." 여기서 중요한 결과는 바로 드러납니다. COBOL을 Jobol로 전환하는 기업은 COBOL 전문 지식의 필요성에서 벗어난 것이 아닙니다. 단지 그 전문 지식의 필요성을 코드에 포함된 COBOL 패턴을 기본적으로 지원하지 않는 언어로 옮긴 것뿐입니다. 결과적으로 원래 COBOL보다 유지 관리가 더 어렵고 Java가 제공하는 이점도 전혀 누릴 수 없는 시스템을 만들게 됩니다.

Jobol의 실제 모습은 어떨까요?

원인을 진단하기 전에 먼저 패턴을 파악해야 합니다. 다음은 동일한 비즈니스 로직인 고객 신용 조회를 세 가지 형태로 나타낸 것입니다. 원래 COBOL 코드, 자동 변환 프로그램이 일반적으로 생성하는 Jobol 코드, 그리고 숙련된 현대화 작업자가 작성한 관용적인 Java 코드입니다.

원래의 COBOL:

코볼

       PERFORM-CREDIT-CHECK.
           MOVE WS-CUST-ID TO DB-CUST-KEY
           READ CUSTOMER-FILE KEY IS DB-CUST-KEY
               INVALID KEY
                   MOVE 'NOT FOUND' TO WS-STATUS
                   PERFORM HANDLE-MISSING-CUSTOMER
           END-READ

           IF CUST-CREDIT-SCORE < 650
               MOVE 'DECLINED' TO WS-CREDIT-RESULT
               MOVE 'Score below threshold' TO WS-DECLINE-REASON
           ELSE IF CUST-OUTSTANDING-BALANCE > CUST-CREDIT-LIMIT
               MOVE 'DECLINED' TO WS-CREDIT-RESULT
               MOVE 'Balance exceeds limit' TO WS-DECLINE-REASON
           ELSE
               MOVE 'APPROVED' TO WS-CREDIT-RESULT
           END-IF.

줄 단위 변환기를 통해 생성된 Jobol:

자바

// Jobol: procedural COBOL logic mapped directly to Java
// No OOP, no encapsulation, static global state, COBOL naming conventions
public class CreditCheckProgram {
    static String WS_CUST_ID;
    static String DB_CUST_KEY;
    static String WS_STATUS;
    static String WS_CREDIT_RESULT;
    static String WS_DECLINE_REASON;
    static int CUST_CREDIT_SCORE;
    static double CUST_OUTSTANDING_BALANCE;
    static double CUST_CREDIT_LIMIT;

    public static void PERFORM_CREDIT_CHECK() {
        DB_CUST_KEY = WS_CUST_ID;
        Customer customer = CustomerFile.read(DB_CUST_KEY);
        if (customer == null) {
            WS_STATUS = "NOT FOUND";
            HANDLE_MISSING_CUSTOMER();
            return;
        }
        CUST_CREDIT_SCORE = customer.getCreditScore();
        CUST_OUTSTANDING_BALANCE = customer.getOutstandingBalance();
        CUST_CREDIT_LIMIT = customer.getCreditLimit();

        if (CUST_CREDIT_SCORE < 650) {
            WS_CREDIT_RESULT = "DECLINED";
            WS_DECLINE_REASON = "Score below threshold";
        } else if (CUST_OUTSTANDING_BALANCE > CUST_CREDIT_LIMIT) {
            WS_CREDIT_RESULT = "DECLINED";
            WS_DECLINE_REASON = "Balance exceeds limit";
        } else {
            WS_CREDIT_RESULT = "APPROVED";
        }
    }
}

숙련된 현대화 작업이 만들어내는 관용적인 자바:

자바

// Idiomatic Java: domain model, encapsulation, value objects, Spring service
@Service
public class CreditCheckService {

    private final CustomerRepository customerRepository;

    public CreditCheckService(CustomerRepository customerRepository) {
        this.customerRepository = customerRepository;
    }

    public CreditDecision check(CustomerId customerId) {
        Customer customer = customerRepository.findById(customerId)
            .orElseThrow(() -> new CustomerNotFoundException(customerId));

        if (customer.creditScore() < CreditThresholds.MINIMUM_SCORE) {
            return CreditDecision.declined("Score below threshold");
        }
        if (customer.outstandingBalance().compareTo(customer.creditLimit()) > 0) {
            return CreditDecision.declined("Balance exceeds limit");
        }
        return CreditDecision.approved();
    }
}

Jobol 버전은 32줄의 정적 전역 상태를 포함하고 있으며, 절차적으로 구성되어 있고, COBOL식 명명 규칙을 따르며, 전역 클래스 상태를 먼저 초기화하지 않으면 단위 테스트가 불가능합니다. 반면 관용적인 버전은 20줄로 간결하고, 주입 가능하며, 테스트 가능하고, COBOL 배경 지식이 없는 자바 개발자라도 바로 이해할 수 있습니다. 두 버전 모두 동일한 비즈니스 규칙을 구현합니다. 하지만 이 현대화의 목표였던 팀이 유지 관리할 수 있는 코드는 단 하나뿐입니다.

Jobol의 6가지 패턴과 변환기가 이러한 패턴을 생성하는 이유

패턴 1: 작업 저장소를 전역 정적 상태로 대체

COBOL의 작업 저장소(WORKING-STORAGE) 섹션은 PERFORM 호출 간에 유지되는 프로그램 수준 변수를 저장합니다. 이는 프로그램의 공유 가능한 가변 상태이며, 모든 단락에서 동일한 작업 저장소 변수를 읽고 씁니다. 자동 변환 도구는 이를 단일 클래스의 Java 정적 필드로 직접 매핑하여 공유 상태의 의미론을 유지하면서 Java의 모든 캡슐화 원칙을 위반합니다.

변환기가 이렇게 하는 이유: 작업 저장소(WORKING-STORAGE)를 정적 필드로 매핑하는 것은 기계적인 일대일 변환입니다. 변환기는 자바의 캡슐화 모델이 프로그램 수준의 공유 상태를 인스턴스 변수, 메서드 매개변수 및 반환 값으로 대체한다는 사실을 이해하지 못합니다. 변환기는 원래 구조가 존재했던 이유를 파악하지 않고 보이는 그대로 변환합니다.

결과적으로 정적 상태는 독립적으로 테스트할 수 없고, 명시적인 동기화 없이는 스레드 안전성이 확보되지 않으며, 구조적으로 기존 COBOL 코드와 동일합니다. 시스템에 동시성을 추가해야 하는 개발자는 먼저 정적 상태를 풀어내야 하는데, 이 작업은 변환 과정에서부터 이후의 모든 유지보수 담당자에게 미뤄지게 됩니다.

해결 방법: 작업 저장소 변수를 사용 범위에 따라 인스턴스 필드, 메서드 매개변수 또는 반환 값에 매핑합니다. 한 단락 내에서만 사용되는 변수는 지역 변수가 됩니다. 단락 간에 전달되는 변수는 메서드 매개변수 또는 반환 값이 됩니다. 공유 객체의 상태를 실제로 나타내는 변수는 적절하게 캡슐화된 도메인 클래스의 인스턴스 필드가 됩니다.

패턴 2: 긴 정적 메서드가 되는 체인 실행

COBOL 프로그램은 PERFORM 체인으로 구성되며, 메인 프로시저는 명명된 단락들의 시퀀스를 PERFORM하고, 각 단락은 다른 단락을 PERFORM할 수 있습니다. 자동 변환기는 각 단락을 정적 메서드로, 각 PERFORM을 정적 메서드 호출로 변환합니다. 결과적으로, COBOL의 PERFORM 구조를 그대로 반영하는 호출 그래프를 통해 서로를 호출하는 수십 개의 정적 메서드를 가진 단일 클래스가 생성됩니다.

자바

// Jobol: PERFORM chain mapped to static method calls
public class ProcessOrderProgram {
    public static void main() {
        validateOrder();
        checkInventory();
        calculateTotal();
        applyDiscounts();
        processPayment();
        generateConfirmation();
        updateInventory();
    }

    public static void validateOrder() { /* ... */ }
    public static void checkInventory() { /* ... */ }
    // ... 40 more static methods
}

변환기가 이렇게 하는 이유: COBOL 문단과 Java 메서드 간의 구조적 매핑은 직접적입니다. 변환기는 PERFORM이 "이 코드 단위를 호출하라"는 의미임을 정확하게 인식합니다. 하지만 변환기가 간과하는 것은 Java의 객체 모델이 처리 단계가 아닌 도메인 엔티티를 중심으로 코드를 구성한다는 점입니다.

수정 사항 : PERFORM 프로세스에 포함된 도메인 개념을 파악하십시오. validateOrder, calculateTotal예산 및 applyDiscounts 주문에 대한 작업입니다. processPayment 이는 결제 컨텍스트에 대한 작업입니다. checkInventory updateInventory 이는 인벤토리 관련 작업입니다. 리팩토링을 통해 정적 메서드들이 해당 도메인 클래스로 분산되어, 긴 절차적 호출 체인이 적절한 도메인 객체에 위임하는 간결한 오케스트레이션 방식으로 대체됩니다.

패턴 3: 정밀도 처리가 없는 숫자 유형

COBOL의 팩형 십진수(COMP-3) 필드는 정확한 십진수 연산을 수행합니다. COMP-3를 Java로 매핑하는 변환기가 필요합니다. double or float 수백만 건의 금융 거래에 걸쳐 누적되는 체계적인 부동 소수점 반올림 오류를 도입합니다.

자바

// Jobol: COMP-3 mapped to double (wrong)
static double WS_TRANSACTION_AMOUNT;  // Was PIC S9(9)V99 COMP-3
static double WS_RUNNING_TOTAL;

// After 10M additions of 0.1:
// Expected: 1,000,000.00
// Actual:   1,000,000.0000000002 (floating point accumulation)

자바

// Idiomatic Java: COMP-3 mapped to BigDecimal (correct)
private BigDecimal transactionAmount;  // Preserves decimal precision
private BigDecimal runningTotal;

// After 10M additions of 0.1:
// Result: exactly 1,000,000.00

변환기가 이렇게 하는 이유: double `__init__`은 Java의 기본 숫자 유형입니다. COMP-3 시맨틱스를 특별히 이해하지 못하는 변환기는 가장 일반적인 Java 숫자 유형을 기본값으로 사용하는데, 이는 정확한 소수 연산에는 적합하지 않습니다.

수정 사항 : 모든 COMP-3 필드는 다음과 같이 매핑됩니다. BigDecimalCOMP-3 값을 사용하는 모든 수치 계산은 다음과 같습니다. BigDecimal 산수. scale() 의 BigDecimal PIC 절에 암시된 소수점 자리와 일치합니다. PIC S9(9)V99 암시적인 소수점 두 자리가 있으며, 이는 다음과 같이 매핑됩니다. BigDecimal 축척 2로.

패턴 4: EBCDIC 문자열 및 바이트 배열 잔해

COBOL은 문자 데이터를 EBCDIC 인코딩의 고정 길이 공백 문자열로 처리합니다. 변환기는 종종 UTF-8로 변환한 후에도 고정 길이 공백 문자열의 의미를 유지하는 Java 코드를 생성하는데, 이로 인해 Java 코드가 마치 1970년대 메인프레임 프로그래머처럼 문자열을 처리하게 됩니다.

자바

// Jobol: preserves COBOL fixed-length string handling
static char[] WS_CUSTOMER_NAME = new char[40]; // Was PIC X(40)
static char[] WS_CUSTOMER_ADDR = new char[80]; // Was PIC X(80)

// COBOL-style space-padding comparison
if (new String(WS_CUSTOMER_NAME).trim().equals("SMITH")) { ... }

// COBOL-style string concatenation with padding
System.arraycopy(name.toCharArray(), 0, WS_CUSTOMER_NAME, 0,
                 Math.min(name.length(), 40));

자바

// Idiomatic Java: proper String types and domain objects
private String customerName;  // Trim on read, no padding
private String customerAddress;

// Clean comparison
if ("Smith".equalsIgnoreCase(customer.name())) { ... }

변환기가 이렇게 하는 이유: COBOL PIC X(40) 정의에는 변환기가 Java 배열 크기로 유지하는 길이가 있습니다. EBCDIC-UTF-8 변환은 처리될 수 있지만 고정 길이 의미론은 불필요하게 전달됩니다.

수정 사항 : 지도 PIC X(n) 필드에 String 객체의 읽기 시 길이를 줄이고 고정 길이 제약 조건을 제거합니다. 길이 제약 조건이 중요한 유일한 컨텍스트는 영속성 경계(데이터베이스 열 길이, 파일 형식 위치)이며 도메인 모델에서는 중요하지 않습니다.

패턴 5: 상태 코드를 통한 오류 처리

COBOL은 FILE STATUS, SQLCODE, RETURN-CODE와 같은 상태 코드를 통해 오류 조건을 전달합니다. 변환기는 이 패턴을 Java에서도 유지하여 Java의 예외 처리 모델을 사용하는 대신 모든 작업 후에 정수 상태 코드를 확인하는 코드를 생성합니다.

자바

// Jobol: COBOL status code pattern in Java
static int WS_FILE_STATUS;
static int WS_SQL_CODE;

CustomerFile.read(DB_CUST_KEY);
WS_FILE_STATUS = CustomerFile.getLastStatus();
if (WS_FILE_STATUS == 10) {
    // Not found
} else if (WS_FILE_STATUS == 35) {
    // File not available
} else if (WS_FILE_STATUS != 0) {
    // Unknown error
}

자바

// Idiomatic Java: exceptions for error conditions
try {
    Customer customer = customerRepository.findById(customerId)
        .orElseThrow(() -> new CustomerNotFoundException(customerId));
    // process customer
} catch (DatabaseUnavailableException e) {
    log.error("Database unavailable during credit check", e);
    throw new CreditCheckServiceException("Service temporarily unavailable", e);
}

변환기가 이렇게 하는 이유: 상태 코드 검사는 COBOL 패턴입니다. 이를 상태 필드를 반환하거나 설정하는 Java 메서드로 변환하는 것은 기계적인 변환입니다. Java 예외가 관용적인 표현 방식이라는 것을 인식하는 데에는 기계적인 변환이 아닌 아키텍처적인 판단이 필요합니다.

수정 사항 : COBOL 오류 조건을 Java 예외로 매핑합니다. 파일 상태 10(레코드를 찾을 수 없음)은 다음과 같이 변환됩니다. Optional.empty() 또는 도메인별 예외입니다. SQLCODE 오류는 유형이 지정된 데이터베이스 예외로 변환됩니다. Java 코드 구조는 의도를 반영하며, 예상되는 오류 모드에는 try/catch를 사용하고, 예상치 못한 오류에는 검사되지 않은 예외를 사용합니다.

패턴 6: 단일화된 계급 구조

COBOL 프로그램은 설계상 단일 프로그램으로 전체 비즈니스 기능을 처리하는 모놀리식 구조를 가지고 있습니다. 변환기는 COBOL 프로그램 하나당 하나의 Java 클래스를 생성하는데, 이로 인해 생성되는 Java 클래스는 수천 줄에 달할 수 있으며 객체 지향 설계라면 여러 개의 특화된 클래스에 분산시켰을 여러 가지 책임을 한꺼번에 처리하게 됩니다.

변환기가 이렇게 작동하는 이유: 하나의 COBOL 프로그램은 하나의 Java 클래스에 매핑되며, 변환기의 변환 단위는 프로그램입니다. 프로그램의 내부 구조(단락, 섹션, PERFORM 체인)는 더 작은 클래스로 분해되지 않고 클래스의 내부 구조가 됩니다.

해결책: 변환된 각 클래스에 단일 책임 원칙을 적용합니다. 입력 유효성 검사, 데이터베이스 읽기, 비즈니스 규칙 적용, 출력 형식 지정 및 파일 쓰기를 수행하는 3,000줄짜리 Jobol 클래스는 입력 유효성 검사기, 저장소, 도메인 서비스, 포맷터 및 쓰기 클래스로 분리되어야 하며, 각 클래스는 독립적으로 테스트 가능하고 하나의 책임에 집중해야 합니다.

구조 분석 필수 요건

모든 Jobol 패턴에는 상응하는 리팩토링이 있습니다. 하지만 리팩토링은 변환기가 직접 적용할 수 있는 것이 아니라, 프로그램의 동작을 이해한 후에야 재구성 방법을 결정할 수 있습니다. 바로 이러한 이해를 얻기 위해 변환 도구를 실행하기 전에 소스 COBOL 코드에 대한 구조 분석을 수행해야 합니다.

구체적으로, 구조 분석은 전환 결정에 필요한 입력값을 생성합니다.

비즈니스 로직 목록. 각 프로그램의 EVALUATE 조건, IF 분기, COMPUTE 수식에 대한 완전한 열거, 즉 프로그램의 구조뿐 아니라 프로그램이 내리는 결정까지 모두 포함합니다. 이 목록은 리팩토링된 Java 코드가 반드시 따라야 하는 명세입니다. 847개의 EVALUATE 조건을 가진 프로그램은 847개의 결정 지점을 수용할 수 있는 대상 클래스 구조를 필요로 합니다. 변환기의 출력은 시작 단계의 초안일 뿐, 최종 제품이 아닙니다.

프로그램 의존성 그래프는 어떤 프로그램이 다른 프로그램을 호출하는지를 보여줍니다. 여러 COBOL 프로그램에 걸쳐 있는 PERFORM 체인은 Java에서는 서비스 호출 그래프가 됩니다. 의존성 그래프를 통해 어떤 프로그램은 독립적으로 리팩토링할 수 있는지(인바운드 의존성이 적은 경우) 그리고 어떤 프로그램은 그룹으로 묶어서 리팩토링해야 하는지(카피북이나 공유 데이터를 통해 공유되는 의존성이 많은 경우)를 판단할 수 있습니다.

데드 코드 식별. 실제 실행 경로에서 전혀 실행되지 않는 단락이나 섹션은 데드 코드로 간주하며, 변환된 Java 코드에 포함되어서는 안 됩니다. 데드 코드를 포함하는 변환기는 변환된 코드베이스의 크기를 증가시키고 이후의 리팩토링 작업량을 늘립니다.

데이터 모델 복구. VSAM 함수 도메인(FD) 항목, DB2 테이블 정의 및 프로그램 데이터를 정의하는 카피북 구조. 각 COBOL 데이터 구조는 하나 이상의 Java 도메인 객체에 매핑됩니다. 이 매핑은 WORKING-STORAGE의 필드 이름이 아니라 데이터 모델에 의해 결정됩니다.

분석 입력	전환 결정에 영향을 미칩니다
지점 수를 평가/확인	도메인 클래스 분해, 각 서비스가 처리하는 결정 사례 수
인바운드 종속성 개수	리팩토링 순서: 의존성이 가장 적은 프로그램부터 먼저 진행
데드 코드 비율	범위 축소, 변환에서 도달할 수 없는 코드 제외
COMP-3 필드	BigDecimal 모든 숫자 필드에 대한 매핑
PIC X 필드 길이	문자열 유형 매핑 및 영속성 계층 제약 조건
그래프 구조 수행	서비스 계층 분해, PERFORM 체인은 도메인 서비스 호출이 됩니다.
파일 상태 사용	예외 모델 설계, 즉 어떤 상태 코드가 어떤 예외 유형에 매핑되는지

그 대신 전환이 가져와야 할 결과

Jobol의 대안은 COBOL을 템플릿이 아닌 명세로 사용하는 변환 프로세스입니다. COBOL 프로그램은 비즈니스 로직을 알고 있으며, Java 프로그램은 해당 로직을 Java의 관용구로 표현해야 합니다.

변환 원리: 구문이 아니라 의도를 바꾸세요. COBOL IF CUST-CREDIT-SCORE < 650 MOVE 'DECLINED' TO WS-CREDIT-RESULT "신용점수가 650점 미만인 고객의 주문은 거절됩니다."라고 되어 있습니다. 자바 코드도 자바 언어로 동일한 내용을 표현해야 합니다. if (customer.creditScore() < CreditThresholds.MINIMUM_SCORE) return CreditDecision.declined(...). 아니 if (CUST_CREDIT_SCORE < 650) { WS_CREDIT_RESULT = "DECLINED"; }.

관용적인 Java 코드를 생성하는 실용적인 변환 워크플로:

1단계: COBOL 소스 코드의 구조 분석, 의존성 그래프 분석, 비즈니스 로직 목록 작성, 데이터 모델 복구, 사용되지 않는 코드 식별을 수행합니다. 이 단계에서 명세서가 생성됩니다. 이 단계가 완료될 때까지는 어떤 코드도 변환되지 않습니다.

2단계: 도메인 모델 설계. COBOL 프로그램이 처리하는 비즈니스 엔티티(고객, 계정, 거래, 정책)를 식별합니다. 이러한 엔티티는 Java 도메인 클래스가 됩니다. 엔티티 상태를 나타내는 작업 저장 변수는 해당 도메인 클래스의 인스턴스 필드가 됩니다.

3단계: 서비스 계층 설계. COBOL 단락 및 섹션이 구현하는 비즈니스 작업(신용 조회, 결제 처리, 잔액 계산)을 식별합니다. 이러한 작업은 해당 도메인 서비스 클래스의 Java 서비스 메서드가 됩니다. 단락들을 순차적으로 실행하는 PERFORM 체인은 서비스의 오케스트레이션 로직이 됩니다.

4단계: 자동 변환 기능을 사용하여 초안을 생성합니다. 2단계와 3단계에서 설계한 도메인 모델을 기반으로 각 프로그램에 대한 Java 초안을 생성합니다. 생성된 초안을 비즈니스 로직 목록과 비교하여 모든 의사 결정 분기가 표현되었는지 확인합니다.

5 단계 : Jobol 패턴에 대한 체계적인 리팩토링을 수행하고, 다음 6가지 안티 패턴 수정 사항을 적용합니다. 정적 상태를 인스턴스 상태로 대체, 정적 메서드를 도메인 클래스로 분산, 상태 코드를 예외로 대체, double 과 BigDecimal고정 길이 배열을 다음으로 대체합니다. String단일화된 클래스를 단일 책임 서비스로 분해합니다.

6단계: 동작 동등성 테스트. COBOL 분석에서 생성된 특성화 테스트 코퍼스를 사용하여 리팩토링된 Java 코드를 실행합니다. 모든 EVALUATE 조건과 IF 분기에는 해당 조건을 실행하고 COBOL 출력과의 동등성을 검증하는 테스트 케이스가 하나 이상 있어야 합니다.

방법 SMART TS XL Jobol을 원천적으로 방지합니다.

Jobol 예방을 위한 구조 분석의 필수 조건은 의존성 그래프, 비즈니스 로직 목록, 데드 코드 식별 및 데이터 모델 복구입니다. SMART TS XL변환 도구가 실행되기 전에 COBOL 소스에 대한 분석 결과를 제공합니다.

SMART TS XL의 정적 코드 분석 COBOL 소스 코드에 있는 모든 EVALUATE 조건, 모든 IF 분기, 모든 COMPUTE 수식, 모든 PERFORM 관계를 열거하여, 리팩토링된 Java 코드가 충실히 재현해야 하는 전체 비즈니스 로직 목록을 제공합니다. 변환 도구가 Jobol을 생성할 때, 이 비즈니스 로직 목록은 리팩토링의 유효성을 검증하는 기준이 됩니다. 목록에 있는 모든 조건은 Java 코드의 해당 도메인 클래스에 Java 관용구로 표현되어 나타나야 합니다.

애플리케이션 의존성 매핑은 Java 서비스 계층 구조를 결정하는 PERFORM 그래프와 프로그램 호출 그래프를 생성합니다. 서로 자주 호출하는 프로그램은 동일한 경계 컨텍스트에 속합니다. 다른 여러 프로그램에서 호출되는 프로그램은 Java 아키텍처에서 모든 소비자를 지원하도록 신중하게 설계해야 하는 공유 서비스입니다. 의존성 그래프는 서비스 계층 설계 단계의 입력으로 사용되며, COBOL의 암묵적인 결합 구조를 Java의 명시적인 의존성 주입 구조로 변환합니다.

레거시 현대화 분석을 통해 프로덕션 실행 경로에서 전혀 도달하지 않는 사용되지 않는 코드, 단락 및 섹션을 식별하고, 이러한 코드는 변환 범위에서 완전히 제외해야 합니다. 사용되지 않는 COBOL 코드를 사용되지 않는 Jobol 코드로 변환한 다음 Jobol 코드를 리팩토링하는 것은 변환 시작 전에 사용되지 않는 코드를 식별하는 단계를 통해 얻을 수 있는 노력을 낭비하는 것입니다.

영향 분석 기능은 리팩토링 순서의 타당성을 검증합니다. COBOL 프로그램의 인터페이스가 Jobol에서 관용적인 Java 코드로 리팩토링되는 동안 변경될 경우, 영향 분석은 변경된 인터페이스와 일관성을 유지하기 위해 Java 코드에서도 업데이트해야 하는 다른 모든 프로그램을 식별합니다. 의존성 순서(가입성이 가장 낮은 프로그램부터)로 리팩토링하면 각 단계에서 필요한 조정 작업을 최소화할 수 있습니다.

변환기는 구문을 번역합니다. 현대화는 의미를 변화시킵니다.

COBOL을 Java로 자동 변환하는 프로그램은 사람이 직접 코드를 수정하는 것보다 빠릅니다. 또한, 의미적 동등성보다는 대상 언어의 관용구에서 구문적 대응을 추구하는 다른 목표에 최적화되어 있습니다. Jobol은 소스 언어(COBOL)와 대상 언어(Java)의 구조적 모델이 근본적으로 다를 때 구문적 대응을 통해 생성되는 결과물입니다.

Jobol을 사용하지 않는 조직은 더 나은 변환기를 사용하는 조직이 아닙니다. 오히려 변환기를 완성된 제품이 아닌 초안 생성기로 취급하고, 변환 시작 전에 구조적 분석에 투자하고, 변환기 실행 전에 Java 도메인 모델을 설계하고, 비즈니스 로직 목록을 유효성 검사 기준으로 삼아 변환기 출력물에 체계적인 리팩토링을 적용하는 조직입니다.

Jobol 사용은 피할 수 있습니다. Jobol 사용을 피하는 데 드는 비용은 모든 변환 작업에 앞서 수행해야 하는 구조 분석 및 도메인 모델링 작업입니다. Jobol 사용을 피할 수 없다면 유지 관리에 COBOL 전문 지식이 필요한 Java 시스템이 되므로, 현대화의 기대 이점인 Java 개발자로 시스템을 유지 관리할 수 있다는 이점을 결코 실현할 수 없게 됩니다.

구문이 아니라 의도를 바꾸세요. 그 차이가 현대화의 핵심 가치를 결정합니다.