COBOL'dan Java'ya dönüştürücüler neden "Jobol" üretir ve bundan nasıl kaçınılır?

Dönüştürme işlemi üç ayda tamamlandı. Java uygulaması derlendi, temel duman testlerinden geçti ve dağıtıma hazır ilan edildi. Üretimin başlamasından altı ay sonra, platform ekibi rahatsız edici bir şey fark etti: Java ekibinden hiç kimse kodu sürdüremez hale gelmişti. İncelemeler normal Java incelemelerinin iki katı sürüyordu. Hata raporlarında, ana bilgisayar deneyimi olmayan Java geliştiricilerinin anlayamayacağı kavramlara, WORKING-STORAGE'a, PROCEDURE DIVISION mantığına, paketlenmiş ondalık alan kurallarına atıfta bulunuluyordu. Uygulama COBOL'dan Java'ya dönüştürülmüştü, ancak ortaya çıkan Java kodu COBOL gibi düşünüyor, yapılandırılıyor ve davranıyordu. Bu, Jobol'du.

Jobol (bazen JOBOL olarak da yazılır), Java'nın nesne yönelimli yeteneklerini benimsemeden COBOL'un prosedürel semantiğini koruyan Java kodu için kullanılan bir kısaltmadır. Analist firması Intellyx'in kurucusu Jason Bloomberg bunu doğrudan şöyle tanımlamıştır: Jobol, orijinal yazılım mimarisini koruyan ve COBOL semantiğini muhafaza eden, teknik olarak geçerli Java kodudur ve geliştiricilerin Java kodunu COBOL gibi ele almasını gerektirir. Bunun kritik sonucu hemen ortaya çıkar: COBOL'u Jobol'a dönüştüren bir işletme, COBOL uzmanlığına olan ihtiyacından kurtulmamıştır. Sadece bu uzmanlık gereksinimini, kodun içerdiği COBOL kalıplarını doğal olarak desteklemeyen bir dile taşımıştır. Orijinal COBOL'dan daha zor bakım gerektiren ve beklenen Java avantajlarından hiçbirini sağlamayan bir sistem yaratmıştır.

Jobol Gerçekte Nasıl Görünüyor?

Sebepleri teşhis etmeden önce, kalıbın görünür olması gerekir. İşte aynı iş mantığı, bir müşteri kredi kontrolü, üç farklı biçimde: orijinal COBOL, otomatik dönüştürücülerin tipik olarak ürettiği Jobol ve yetenekli bir modernizasyonun ürettiği özgün Java.

Orijinal COBOL:

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.

Satır satır dönüştürücü tarafından üretilen Jobol:

Java

// 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";
        }
    }
}

Java'nın kendine özgü tarzı ve yetenekli modernizasyonu şunları üretir:

Java

// 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 versiyonu, prosedürel olarak yapılandırılmış, COBOL adlandırmasıyla adlandırılmış ve global sınıf durumunu önce başlatmadan birim testi yapılamayan 32 satırlık statik global durumdan oluşmaktadır. İdiomatik versiyon ise 20 satırdan oluşmakta, enjekte edilebilir, test edilebilir ve COBOL geçmişi olmayan herhangi bir Java geliştiricisi tarafından hemen okunabilir. Her ikisi de aynı iş kurallarını uygulamaktadır. Sadece biri, modernizasyonun mümkün kıldığı ekip tarafından sürdürülebilir durumdadır.

Altı Jobol Modeli ve Dönüştürücülerin Bunları Neden Ürettiği

Desen 1: Çalışma Depolamasının Yerine Geçen Küresel Statik Durum

COBOL'un WORKING-STORAGE SECTION'ı, PERFORM çağrıları arasında kalıcı olan program düzeyindeki değişkenleri tutar. Bu, programın paylaşılan değiştirilebilir durumudur; her paragraf aynı WS değişkenlerini okur ve yazar. Otomatik dönüştürücüler bunu doğrudan tek bir sınıftaki Java statik alanlarına eşler ve paylaşılan durum semantiğini korurken Java'nın tüm kapsülleme ilkelerini ihlal eder.

Dönüştürücülerin bunu yapmasının nedeni: WORKING-STORAGE'dan statik alana eşleme, mekanik bir birebir dönüşümdür. Dönüştürücü, Java'nın kapsülleme modelinin program düzeyindeki paylaşılan durumu örnek değişkenler, metot parametreleri ve dönüş değerleriyle değiştirdiğini anlamaz. Orijinal yapının neden var olduğunu anlamadan gördüğünü dönüştürür.

Sonuç olarak: Statik durum tek başına test edilemez, açık senkronizasyon olmadan iş parçacığı açısından güvenli değildir ve yapısal olarak yerini aldığı COBOL ile aynıdır. Sisteme eşzamanlılık eklemek isteyen herhangi bir geliştirici, öncelikle statik durumu çözmelidir; bu iş, dönüşümden sonraki her bakımcıya ertelenmiştir.

Çözüm: Çalışma alanı değişkenlerini kullanım kapsamlarına göre örnek alanlarına, metot parametrelerine veya dönüş değerlerine eşleyin. Yalnızca bir paragraf içinde kullanılan değişkenler yerel değişkenler olur. Paragraflar arasında aktarılan değişkenler metot parametreleri veya dönüş değerleri olur. Paylaşılan nesne durumunu gerçekten temsil eden değişkenler, düzgün bir şekilde kapsüllenmiş etki alanı sınıfındaki örnek alanları olur.

Desen 2: PERFORM Zincirlerinin Uzun Statik Metotlara Dönüşmesi

COBOL programları PERFORM zincirleri şeklinde düzenlenir; ana prosedür, her biri diğerlerini PERFORM edebilen, adlandırılmış paragraflardan oluşan bir diziyi PERFORM eder. Otomatik dönüştürücüler, her paragrafı statik bir metoda ve her PERFORM'u statik bir metot çağrısına çevirir. Sonuç olarak, COBOL PERFORM yapısını yansıtan bir çağrı grafiği aracılığıyla birbirini çağıran düzinelerce statik metoda sahip tek bir sınıf elde edilir.

Java

// 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
}

Dönüştürücülerin bunu yapmasının nedeni: COBOL paragrafından Java metoduna yapısal eşleme doğrudan gerçekleşir. Dönüştürücü, PERFORM'un "bu kod birimini çağır" anlamına geldiğini doğru bir şekilde belirler. Ancak gözden kaçırdığı nokta, Java'nın nesne modelinin kodu işlem adımları etrafında değil, etki alanı varlıkları etrafında düzenlemesidir.

Çözüm: PERFORM zincirinde yer alan alan kavramlarını belirleyin. validateOrder, calculateTotal, ve applyDiscounts Sipariş üzerine yapılan işlemlerdir. processPayment Ödeme bağlamında gerçekleştirilen bir işlemdir. checkInventory hem de updateInventory Envanter üzerinde gerçekleştirilen işlemlerdir. Yeniden yapılandırma, statik yöntemleri ait oldukları etki alanı sınıflarına dağıtarak, uzun bir prosedürel çağrı zincirini, uygun etki alanı nesnelerine yetki devreden kısa bir düzenleme yöntemiyle değiştirir.

Desen 3: Hassas İşlem Yapmayan Sayısal Tipler

COBOL'un paketlenmiş ondalık (COMP-3) alanları, kesin ondalık aritmetiğine sahiptir. COMP-3'ü Java'ya eşleyen dönüştürücüler mevcuttur. double or float Milyonlarca finansal işlemde biriken sistematik kayan noktalı yuvarlama hatalarına yol açar.

Java

// 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)

Java

// 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

Dönüştürücüler bunu neden yapar: double Java'nın varsayılan sayısal türüdür. COMP-3 semantiğini özel olarak anlamayan bir dönüştürücü, varsayılan olarak en yaygın Java sayısal türünü kullanır ki bu, kesin ondalık aritmetik için yanlış bir seçimdir.

Çözüm: Her COMP-3 alanı şuna eşlenir: BigDecimalCOMP-3 değerlerini içeren her sayısal hesaplama, bu değerleri kullanır. BigDecimal aritmetik. scale() arasında BigDecimal PIC maddesindeki ima edilen ondalık basamak sayısıyla eşleşir: PIC S9(9)V99 İki adet örtük ondalık basamağa sahiptir ve bu da şu anlama gelir: BigDecimal 2 ölçeğiyle.

Desen 4: EBCDIC Dizeleri ve Bayt Dizisi Kalıntıları

COBOL, karakter verilerini EBCDIC kodlamasında sabit uzunlukta, boşlukla doldurulmuş dizeler olarak işler. Dönüştürücüler genellikle, UTF-8'e dönüştürmeden sonra bile sabit uzunlukta, boşlukla doldurulmuş dize semantiğini koruyan Java kodu üretir; bu da Java'nın dizeleri 1970'lerin ana bilgisayar programcısı gibi ele almasına neden olur.

Java

// 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));

Java

// 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())) { ... }

Dönüştürücülerin bunu yapmasının nedeni: COBOL PIC X(40) tanımının, dönüştürücünün Java dizi boyutu olarak koruduğu bir uzunluğu vardır. EBCDIC'den UTF-8'e dönüştürme işlemi gerçekleştirilebilir, ancak sabit uzunluk semantiği gereksiz yere aktarılır.

Çözüm: Harita PIC X(n) alanlar String Nesneler, okuma sırasında kırpma ve sabit uzunluk kısıtlamalarının kaldırılması. Uzunluk kısıtlamalarının önemli olduğu tek bağlam, etki alanı modelinde değil, kalıcılık sınırlarındadır (veritabanı sütun uzunlukları, dosya biçimi konumları).

Desen 5: Durum Kodları Aracılığıyla Hata Yönetimi

COBOL, hata durumlarını durum kodları aracılığıyla iletir: DOSYA DURUMU, SQL KODU, DÖNÜŞ KODU. Dönüştürücüler, Java'nın istisna modelini kullanmak yerine, her işlemden sonra tamsayı durum kodlarını kontrol eden kod üreterek bu modeli Java'da korur.

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
}

Java

// 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);
}

Dönüştürücülerin bunu yapmasının nedeni: Durum kodu kontrolü COBOL kalıbıdır; bunu bir durum alanı döndüren veya ayarlayan bir Java yöntemine dönüştürmek mekanik bir dönüşümdür. Java istisnalarının bunun en uygun karşılığı olduğunu anlamak, mekanik çeviri değil, mimari değerlendirme gerektirir.

Çözüm: COBOL hata koşullarını Java istisnalarına dönüştürün. DOSYA DURUMU 10 (kayıt bulunamadı) şu hale gelir: Optional.empty() veya alana özgü bir istisna. SQLCODE hataları, türlendirilmiş veritabanı istisnalarına dönüşür. Java kod yapısı amacı yansıtır: beklenen hata durumları için try/catch, beklenmeyenler için ise denetlenmemiş istisnalar kullanılır.

Desen 6: Tek Parçalı Sınıf Yapısı

COBOL programları tasarım gereği monolitiktir; tek bir program tüm bir iş fonksiyonunu yönetir. Dönüştürücüler, her COBOL programı için tek bir Java sınıfı oluşturur ve bu da binlerce satır uzunluğunda olabilen ve nesne yönelimli tasarımın birkaç odaklanmış sınıfa dağıtacağı birden fazla sorumluluğu üstlenen Java sınıfları üretir.

Dönüştürücülerin bunu yapmasının nedeni: Bir COBOL programı bir Java sınıfına eşlenir; dönüştürücünün çeviri birimi programın kendisidir. Programın iç yapısı (paragrafları, bölümleri, PERFORM zincirleri) daha küçük sınıflara ayrıştırılmadan sınıfın iç yapısı haline gelir.

Çözüm: Dönüştürülen her sınıfa Tek Sorumluluk İlkesini uygulayın. Girişi doğrulayan, veritabanından okuyan, iş kurallarını uygulayan, çıktıyı biçimlendiren ve bir dosyaya yazan 3,000 satırlık bir Jobol sınıfı şu hale gelmelidir: bir giriş doğrulayıcı, bir depo, bir etki alanı hizmeti, bir biçimlendirici ve bir yazıcı; her biri ayrı ayrı test edilebilir ve her biri tek bir sorumluluğa odaklanmıştır.

Yapısal Analiz Önkoşulu

Her Jobol deseninin karşılık gelen bir yeniden düzenlemesi vardır. Ancak yeniden düzenleme dönüştürücü tarafından uygulanamaz; programın ne yaptığını anlamayı ve ardından nasıl yeniden yapılandırılacağına karar vermeyi gerektirir. Bu anlayış, herhangi bir dönüştürme aracı çalışmadan önce kaynak COBOL'un yapısal analizinin sağladığı şeydir.

Özellikle, yapısal analiz, dönüşüm kararlarının gerektirdiği girdileri üretir:

İş mantığı envanteri. Her programdaki EVALUATE koşullarının, IF dallanmalarının ve COMPUTE formüllerinin eksiksiz listesi; programın sadece nasıl yapılandırıldığı değil, neye karar verdiği. Bu envanter, yeniden düzenlenmiş Java kodunun uyması gereken şartnamedir. 847 EVALUATE koşuluna sahip bir program, 847 karar noktasını barındırabilen bir hedef sınıf yapısı gerektirir; dönüştürücünün çıktısı, bitmiş ürün değil, başlangıç ​​taslağıdır.

Bağımlılık grafiği. Hangi programlar hangi diğer programları çağırır. Birden fazla COBOL programını kapsayan PERFORM zinciri, Java'da bir servis çağrı grafiği haline gelir. Bağımlılık grafiği, hangi programların bağımsız olarak yeniden düzenlenebileceğini (az sayıda gelen bağımlılık) ve hangilerinin koordineli gruplar halinde yeniden düzenlenmesi gerektiğini (copybook'lar veya paylaşılan veriler aracılığıyla birçok paylaşılan bağımlılık) belirler.

Ölü kod tespiti. Üretim ortamındaki herhangi bir yürütme yolundan asla çalıştırılmayan paragraflar ve bölümler ölü koddur ve dönüştürülen Java kodunda hiç yer almamalıdır. Ölü kod içeren dönüştürücüler, dönüştürülen kod tabanını ve sonrasında yapılacak yeniden düzenleme çalışmalarını şişirir.

Veri modeli kurtarma. Programın verilerini tanımlayan VSAM FD girişleri, DB2 tablo tanımları ve copybook yapıları. Her COBOL veri yapısı bir veya daha fazla Java etki alanı nesnesine eşlenir; eşleme, WORKING-STORAGE'daki alan adlarına göre değil, veri modeline göre belirlenir.

Analiz Girişi	Dönüşüm Kararı, Tetiklediği Şey
DEĞERLENDİR/EĞER şube sayısı	Alan sınıfı ayrıştırması, her hizmetin kaç karar durumunu ele aldığı
Gelen bağımlılık sayısı	Yeniden düzenleme sırası, en az bağımlılığa sahip programlardan başlayarak.
Ölü kod yüzdesi	Kapsam daraltma, dönüştürülemeyen kodu hariç tutma
COMP-3 alanları	BigDecimal her sayısal alan için eşleme
PIC X alan uzunlukları	Dize türü eşlemesi ve kalıcılık katmanı kısıtlamaları
Grafik yapısını gerçekleştirin	Servis katmanı ayrıştırması, PERFORM zincirleri alan servis çağrılarına dönüşür.
DOSYA DURUMU kullanımı	İstisna modeli tasarımı, hangi durum kodlarının hangi istisna türlerine karşılık geldiğini belirler.

Dönüşümün Bunun Yerine Ne Üretmesi Gerekiyor?

Jobol'a alternatif olarak, COBOL'u şablon olarak değil, spesifikasyon olarak kullanan bir dönüştürme işlemi mevcuttur. COBOL programı iş mantığının ne olduğunu bilir; Java programı ise bu mantığı Java'nın üslubuyla ifade etmelidir.

Dönüşüm prensibi: Sözdizimini değil, amacı dönüştürün. COBOL IF CUST-CREDIT-SCORE < 650 MOVE 'DECLINED' TO WS-CREDIT-RESULT "Kredi puanı 650'nin altında olan bir müşterinin başvurusu reddedilir" diyor. Java kodunda da aynı şey Java dilinde söylenmelidir: if (customer.creditScore() < CreditThresholds.MINIMUM_SCORE) return CreditDecision.declined(...). Değil if (CUST_CREDIT_SCORE < 650) { WS_CREDIT_RESULT = "DECLINED"; }.

İkonik Java çıktısı üreten pratik dönüştürme iş akışı:

Adım 1: COBOL kaynak kodunun yapısal analizi, bağımlılık grafiği, iş mantığı envanteri, veri modeli kurtarma, ölü kod tespiti. Bu adım spesifikasyonu oluşturur. Bu adım tamamlanana kadar hiçbir şey dönüştürülmez.

Adım 2: Alan modeli tasarımı, COBOL programlarının üzerinde çalıştığı iş varlıklarını (Müşteri, Hesap, İşlem, Politika) belirleyin. Bunlar Java alan sınıfları haline gelir. Varlık durumunu temsil eden WORKING-STORAGE değişkenleri, ilgili alan sınıfında örnek alanlar haline gelir.

3. Adım: Servis katmanı tasarımı, COBOL paragrafları ve bölümlerinin uyguladığı iş operasyonlarını (kredi kontrolü, ödeme işlemleri, bakiye hesaplama) belirleyin. Bunlar, uygun etki alanı servis sınıfında Java servis yöntemleri haline gelir. Paragrafları sıralayan PERFORM zinciri, servisin orkestrasyon mantığı olur.

Adım 4: Otomatik dönüştürme (taslak oluşturucu olarak), 2. ve 3. adımlarda tasarlanan etki alanı modelinden yola çıkarak her program için başlangıç ​​noktası niteliğinde bir Java taslağı oluşturmak üzere dönüştürme aracını kullanın. Her karar dalının temsil edildiğini doğrulamak için taslağı iş mantığı envanteriyle karşılaştırın.

5 Adım: Jobol kalıplarına karşı sistematik yeniden düzenleme, altı anti-kalıp düzeltmesini uygulayın: statik durumu örnek durumla değiştirin, statik metotları etki alanı sınıflarına dağıtın, durum kodlarını istisnalarla değiştirin, double 'da BigDecimalSabit uzunluktaki dizileri şunlarla değiştirin: StringTek parça halindeki sınıfları tek sorumluluklu hizmetlere ayrıştırın.

Adım 6: Davranışsal eşdeğerlik testi, yeniden düzenlenmiş Java kodunu COBOL analizinden oluşturulan karakterizasyon test kümesine karşı çalıştırın. Her EVALUATE koşulu ve IF dalı, onu çalıştıran ve COBOL çıktısıyla eşdeğerliğini doğrulayan en az bir test senaryosuna sahip olmalıdır.

Ne kadar SMART TS XL Jobol'ü kaynağında önler.

Jobol saldırılarının önlenmesi için yapısal analiz ön koşulu olan bağımlılık grafiği, iş mantığı envanteri, ölü kod tespiti ve veri modeli kurtarma, tam olarak şudur: SMART TS XLCOBOL kaynak kodunun analizi, herhangi bir dönüştürme aracı çalıştırılmadan önce sağlanır.

SMART TS XL'S statik kod analizi COBOL kaynak kodundaki her EVALUATE koşulunu, her IF dalını, her COMPUTE formülünü ve her PERFORM ilişkisini listeler; yeniden düzenlenmiş Java kodunun sadakatle temsil etmesi gereken eksiksiz iş mantığı envanterini oluşturur. Dönüştürme aracı Jobol kodunu ürettiğinde, iş mantığı envanteri, yeniden düzenlemenin doğrulandığı şartnamedir: envanterdeki her koşul, Java kodunda, ilgili etki alanı sınıfında, Java'nın deyimiyle ifade edilmiş olarak görünmelidir.

Uygulama bağımlılık eşlemesi, Java servis katmanı yapısını belirleyen PERFORM grafiğini ve program çağrı grafiğini üretir. Birbirini sık sık çağıran programlar aynı sınırlı bağlamda yer alır. Birçok program tarafından çağrılan programlar, Java mimarisinde tüm tüketicilerini desteklemek için dikkatlice tasarlanması gereken paylaşımlı servislerdir. Bağımlılık grafiği, COBOL'un örtük bağlantı yapısını Java'nın açık bağımlılık enjeksiyon yapısına dönüştüren servis katmanı tasarım adımının girdisidir.

Eski sistemin modernizasyon analizi, üretim yürütme yollarından hiç erişilmeyen ve dönüştürme kapsamından tamamen çıkarılması gereken ölü kodları, paragrafları ve bölümleri belirler. Ölü COBOL kodunu ölü Jobol koduna dönüştürmek ve ardından ölü Jobol kodunu yeniden düzenlemek, ölü kod belirleme adımıyla dönüştürme başlamadan önce ortadan kaldırılan çabayı boşa harcar.

Etki analizi özelliği, yeniden düzenleme sırasını doğrular: Bir COBOL programının arayüzü Jobol'dan Java'ya yeniden düzenleme sırasında değiştiğinde, etki analizi, değişen arayüzle tutarlı kalmak için Java karşılığı da güncellenmesi gereken diğer tüm programları belirler. Bağımlılık sırasına göre, en az bağımlı olanlardan başlayarak yeniden düzenleme, her adımda gereken koordinasyonu en aza indirir.

Dönüştürücüler Sözdizimini Çevirir. Modernizasyon Anlamı Dönüştürür.

Otomatik COBOL-Java dönüştürücüler, insan eliyle yeniden yazmaktan daha hızlıdır. Ayrıca farklı bir amaç için optimize edilmişlerdir: hedef dilin deyiminde anlamsal eşdeğerlikten ziyade sözdizimsel uyumluluk. Jobol, kaynak dil (COBOL) ve hedef dil (Java) temelde farklı yapısal modellere sahip olduğunda sözdizimsel uyumluluğun ürettiği şeydir.

Jobol'dan kaçınan kuruluşlar, daha iyi dönüştürücüler kullananlar değil. Onlar, dönüştürücüyü bitmiş bir ürün yerine taslak oluşturucu olarak gören, dönüştürme başlamadan önce yapısal analize yatırım yapan, dönüştürücü çalışmadan önce Java alan modelini tasarlayan ve iş mantığı envanterini doğrulama spesifikasyonu olarak kullanarak dönüştürücünün çıktısına sistematik yeniden düzenleme uygulayan kuruluşlardır.

Jobol'dan kaçınılabilir. Bundan kaçınmanın maliyeti, her dönüşümden önce yapılması gereken yapısal analiz ve alan modelleme çalışmasıdır. Bundan kaçınmamanın maliyeti ise, bakım için COBOL uzmanlığı gerektiren bir Java sistemidir; bu da modernizasyonun beklenen faydasının, yani sistemi Java geliştiricileriyle sürdürme yeteneğinin asla gerçekleşmemesi anlamına gelir.

Amacı dönüştürün, sözdizimini değil. Aradaki fark, modernleşmenin tüm değerini oluşturuyor.