Konversioon viidi lõpule kolme kuuga. Java rakendus kompileerus, läbis põhilised suitsutestid ja kuulutati juurutamiseks valmis olevaks. Kuus kuud pärast tootmise alustamist märkas platvormimeeskond midagi murettekitavat: keegi Java meeskonnast ei suutnud koodi hallata. Ülevaatused võtsid kaks korda kauem aega kui tavalised Java ülevaated. Veaaruannetes viidati kontseptsioonidele, TÖÖ-SALVESTUSELE, PROTSEDUURI JAGAMISE loogikale, pakitud kümnendvälja konventsioonidele, mida Java arendajad ilma suurarvutikogemuseta ei suutnud järgida. Rakendus oli COBOL-ist Java-ks teisendatud, kuid saadud Java mõtles, struktureeris ja käitus nagu COBOL. See oli Jobol.
Jobol (mõnikord nimetatakse seda ka JOBOL-iks) on Java-koodi tähis, mis säilitab COBOLi protseduraalsemantika, omaks võtmata Java objektorienteeritud võimalusi. Analüütikafirma Intellyxi asutaja Jason Bloomberg defineeris selle otse: Jobol on tehniliselt kehtiv Java-kood, mis jätab algse tarkvaraarhitektuuri paika ja säilitab COBOL-semantika, nõudes arendajatelt Java käsitlemist nii, nagu oleks see COBOL. Kriitiline tagajärg järgneb kohe: ettevõte, mis teisendab COBOLi Joboliks, ei ole vabanenud vajadusest COBOL-i oskusteabe järele. See on lihtsalt viinud selle oskusteabe nõude keelde, mis ei toeta natiivselt koodis sisalduvaid COBOL-mustreid. See on loonud süsteemi, mida on raskem hooldada kui algset COBOL-i ja mis ei paku ühtegi oodatud Java eelist.
Sõltuvusgraaf enne domeeni kujundamist
SMART TS XL kaardistab iga PERFORM- ja CALL-sõltuvuse nii, et Java teenusekiht peegeldaks tegelikku sidestusstruktuuri, mitte COBOL-klassi struktuuri.
SAAGE LISATEAVET…Milline Jobol tegelikult välja näeb
Enne põhjuste diagnoosimist peab muster olema nähtav. Siin on sama äriloogika, kliendi krediidikontroll, kolmes vormis: algne COBOL, automatiseeritud konverterite tavaliselt loodud Jobol ja oskusliku moderniseerimise tulemusel loodud idioomaatiline Java.
Algne COBOL:
kobol
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.
Rida-realt konverteri abil toodetud 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";
}
}
}Idiomaatiline Java, mida oskuslik moderniseerimine toodab, on:
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();
}
}Joboli versioon on 32 rida staatilist globaalset olekut, protseduraalselt struktureeritud, COBOL-nimeline ja seda on võimatu ühiktestida ilma globaalse klassi olekut eelnevalt initsialiseerimata. Idiomaatiline versioon on 20 rida, süstitav, testitav ja koheselt loetav iga Java arendaja poolt ilma COBOL-taustata. Mõlemad rakendavad samu ärireegleid. Ainult ühte saab hooldada meeskond, mida moderniseerimine pidi võimaldama.
Kuus Joboli mustrit ja miks konverterid neid loovad
Muster 1: Globaalne staatiline olek, mis asendab WORKING-STORAGE
COBOLi TÖÖSALVESTAMISE SEKTSIOON (WORKING-STORAGE SECTION) sisaldab programmi tasemel muutujaid, mis püsivad ka pärast PERFORM-kõnesid. See on programmi jagatud muudetav olek, iga lõik loeb ja kirjutab samu WS-muutujaid. Automaatsed konverterid seovad selle otse Java staatiliste väljadega ühes klassis, säilitades jagatud oleku semantika, rikkudes samal ajal kõiki Java kapseldamispõhimõtteid.
Miks konverterid seda teevad: WORKING-STORAGE väljade teisendamine staatilisteks väljadeks on mehaaniline üks-ühele teisendus. Konverteerija ei saa aru, et Java kapseldusmudel asendab programmi tasemel jagatud oleku eksemplari muutujate, meetodi parameetrite ja tagastusväärtustega. See konverteerib nähtu, mõistmata, miks algne struktuur eksisteeris.
Tagajärg: staatiline olek on isoleeritult testimatu, ilma selgesõnalise sünkroniseerimiseta lõimedele ebaturvaline ja struktuurilt identne COBOL-iga, mille see asendas. Iga arendaja, kes peab süsteemile samaaegsust lisama, peab kõigepealt lahti harutama staatilise oleku – töö, mis lükkus edasi konversioonist iga järgneva hooldaja teha.
Lahendus: kaardista WORKING-STORAGE muutujad eksemplari väljadeks, meetodi parameetriteks või tagastusväärtusteks vastavalt nende kasutusulatusele. Muutujad, mida kasutatakse ainult ühe lõigu sees, muutuvad lokaalseteks muutujateks. Lõikude vahel edastatud muutujad muutuvad meetodi parameetriteks või tagastusväärtusteks. Muutujad, mis esindavad jagatud objekti olekut, muutuvad õigesti kapseldatud domeeniklassi eksemplari väljadeks.
Muster 2: PERFORM-ahelate muutumine pikkadeks staatilisteks meetoditeks
COBOL-programmid on korraldatud PERFORM-kettidena, kus põhiprotseduur PERFORM-protseduur hõlmab nimetatud lõikude jada, millest igaüks võib teostada PERFORM-protseduuri ka teistes. Automaatsed teisendajad teisendavad iga lõigu staatiliseks meetodiks ja iga PERFORM-protseduuri staatilise meetodi kutsumiseks. Tulemuseks on üks klass, kus kümned staatiliste meetodid kutsuvad üksteist läbi kutsumisgraafi, mis peegeldab COBOL PERFORM-struktuuri.
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
}Miks konverterid seda teevad: COBOL-lõigu ja Java-meetodi struktuuriline vastendus on otsene. Konverteerija tuvastab õigesti, et PERFORM tähendab „kutsu seda koodiüksust”. See aga ei märka, et Java objektimudel korraldab koodi domeeniüksuste, mitte töötlemisetappide ümber.
Fikseerige: Tuvastage PERFORM-ahelas sisalduvad valdkonna kontseptsioonid. validateOrder, calculateTotalja applyDiscounts on tellimusega seotud toimingud. processPayment on maksekontekstis tehtav toiming. checkInventory ja updateInventory on toimingud Inventory kallal. Refaktoreerimine jaotab staatilised meetodid domeeniklassidesse, kuhu nad kuuluvad, asendades pika protseduurilise kõneahela lühikese orkestreerimismeetodiga, mis delegeerib vastavatele domeeniobjektidele.
Muster 3: Numbrilised tüübid ilma täpse käsitlemiseta
COBOLi pakitud kümnendväljadel (COMP-3) on täpne kümnendarvutus. Teisendajad, mis teisendavad COMP-3 Javaks double or float tutvustada süstemaatilisi ujukomaarvuga ümardusvigu, mis akumuleeruvad miljonite finantstehingute hulgas.
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.00Miks konverterid seda teevad: double on Java vaike-numbritüüp. Teisendaja, mis ei mõista täpselt COMP-3 semantikat, kasutab vaikimisi kõige levinumat Java numbritüüpi, mis on täpse kümnendarvutuse jaoks vale valik.
Fikseerige: Iga COMP-3 väli vastab BigDecimalIga COMP-3 väärtusi hõlmav numbriline arvutus kasutab BigDecimal aritmeetika. See scale() Euroopa BigDecimal vastab PIC-klauslis sisalduvatele kümnendkohtadele: PIC S9(9)V99 on 2 kaudset kümnendkohta, mis vastab BigDecimal skaalaga 2.
Muster 4: EBCDIC stringid ja baitimassiivi reliikviad
COBOL töötleb tähemärke fikseeritud pikkusega täidetud stringidena EBCDIC kodeeringus. Teisendajad loovad sageli Java koodi, mis säilitab fikseeritud pikkusega ja tühikutega täidetud stringi semantika ka pärast UTF-8 kodeeringusse teisendamist, mille tulemuseks on Java, mis käsitleb stringe nagu 1970. aastate suurarvuti programmeerija.
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())) { ... }Miks konverterid seda teevad: COBOL PIC X(40) definitsioonil on pikkus, mille konverter säilitab Java massiivi suurusena. EBCDIC-UTF-8 teisendust võidakse küll käsitleda, kuid fikseeritud pikkusega semantika kantakse üle ilma vajaduseta.
Fikseerige: kaart PIC X(n) väljad String objektid, lugemisel kärpimine ja fikseeritud pikkusega piirangute eemaldamine. Ainus kontekst, kus pikkuse piirangud on olulised, on püsivuse piirid (andmebaasi veergude pikkused, failivormingu positsioonid), mitte domeenimudelis.
Muster 5: Veakäsitlus olekukoodide abil
COBOL edastab veatingimusi olekukoodide abil: FILE STATUS, SQLCODE, RETURN-CODE. Teisendajad säilitavad selle mustri Javas, luues koodi, mis kontrollib täisarvulisi olekukoode pärast iga toimingut, selle asemel et kasutada Java erandite mudelit.
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);
}Miks konverterid seda teevad: Olekukoodi kontrollimine on COBOL-muster; selle teisendamine Java-meetodiks, mis tagastab või määrab olekuvälja, on mehaaniline teisendus. Java-erinevuste idiomaatilise vastena tunnistamine nõuab arhitektuurilist otsustusvõimet, mitte mehaanilist tõlget.
Fikseerige: Seo COBOLi veatingimused Java eranditega. FAILI OLEK 10 (kirjet ei leitud) muutub Optional.empty() või domeenispetsiifiline erand. SQLCODE'i vead muutuvad tüübitud andmebaasi eranditeks. Java koodi struktuur peegeldab kavatsust: try/catch eeldatavate tõrkerežiimide puhul ja kontrollimata erandid ootamatute tõrkerežiimide puhul.
Muster 6: Monoliitne klassistruktuur
COBOL-programmid on ülesehituselt monoliitsed – üks programm täidab tervet ärifunktsiooni. Konverteerijad loovad iga COBOL-programmi kohta ühe Java-klassi, mis võib olla tuhandete ridade pikkune ja täita mitmeid ülesandeid, mida objektorienteeritud disain jaotaks mitme fookustatud klassi vahel.
Miks konverterid seda teevad: Üks COBOL-programm seostub ühe Java klassiga, konverteri tõlkeühik on programm. Programmi sisemine struktuur (selle lõigud, sektsioonid, PERFORM-ahelad) saab klassi sisemiseks struktuuriks ilma seda väiksemateks klassideks lagundamata.
Lahendus: Rakenda igale teisendatud klassile ühe vastutuse põhimõtet. 3,000-realine Jobol-klass, mis valideerib sisendit, loeb andmebaasist, rakendab ärireegleid, vormindab väljundit ja kirjutab faili, peaks olema: sisendi valideerija, repositoorium, domeeniteenus, vormindaja ja kirjutaja, igaüks eraldi testitav ja igaüks keskendub ühele vastutusele.
Konstruktsioonianalüüsi eeltingimus
Igal Joboli mustril on vastav refaktoriseerimine. Kuid konverter ei saa refaktoriseerimist rakendada, see nõuab programmi tegevuse mõistmist enne ümberstruktureerimise otsustamist. Just seda arusaamist pakub lähtekoodi COBOLi struktuurianalüüs enne mis tahes teisendustööriista käivitamist.
Täpsemalt, struktuurianalüüs annab sisendid, mida konversiooniotsused vajavad:
Äriloogika inventuur. Täielik EVALUATE-tingimuste, IF-harude ja COMPUTE-valemite loetelu igas programmis, mida programm otsustab, mitte ainult seda, kuidas see on üles ehitatud. See inventuur on spetsifikatsioon, millele refaktoreeritud Java peab vastama. 847 EVALUATE-tingimusega programm vajab sihtklassi struktuuri, mis mahutab 847 otsustuspunkti; teisendaja väljund on algne mustand, mitte lõpptoode.
Sõltuvusgraaf. Millised programmid kutsuvad välja milliseid teisi programme. PERFORM-ahel, mis hõlmab mitut COBOL-programmi, muutub Javas teenusekutsete graafiks. Sõltuvusgraaf määrab, milliseid programme saab iseseisvalt refaktoreerida (vähe sissetulevaid sõltuvusi) ja milliseid tuleb refaktoreerida koordineeritud rühmadena (palju jagatud sõltuvusi koopiaraamatute või jagatud andmete kaudu).
Surnud koodi tuvastamine. Lõigud ja sektsioonid, mida ühelgi tootmisprotsessil kunagi ei teostata, on surnud kood ja need ei tohiks konverteeritud Javas üldse ilmuda. Surnud koodi sisaldavad konverterid paisutavad konverteeritud koodibaasi ja sellele järgnevat refaktoreerimise pingutust.
Andmemudeli taastamine. VSAM FD kirjed, DB2 tabeli definitsioonid ja koopiaraamatu struktuurid, mis määratlevad programmi andmed. Iga COBOL-i andmestruktuur on seotud ühe või mitme Java domeeniobjektiga; vastenduse määrab andmemudel, mitte WORKING-STORAGE'i väljanimed.
| Analüüsi sisend | Konversiooniotsuse tegemine |
|---|---|
| HINDAMINE/IF harude arv | Domeeniklasside jaotus, mitu otsustusjuhtumit iga teenus käsitleb |
| Sissetulevate sõltuvuste arv | Refaktoriseerimise järjestus, kõige vähem sõltuvad programmid esimesena |
| Surnud koodi protsent | Ulatuse vähendamine, kättesaamatu koodi välistamine konversioonist |
| COMP-3 väljad | BigDecimal iga numbrivälja kaardistamine |
| PIC X väljapikkused | Stringitüübi kaardistamine ja püsivuskihi piirangud |
| PERFORM-graafiku struktuur | Teenusekihi lagundamine, PERFORM-ahelatest saavad domeeniteenuse kõned |
| FAILI OLEK kasutus | Erandmudeli disain, millised olekukoodid vastavad millistele eranditüüpidele |
Mida konversioon peaks selle asemel tootma
Joboli alternatiiviks on teisendusprotsess, mis kasutab COBOLi spetsifikatsioonina, mitte mallina. COBOL-programm teab, mis on äriloogika, ja Java-programm peaks seda loogikat Java keeles väljendama.
Konversiooni põhimõte: Teisenda eesmärk, mitte süntaks. COBOL
IF CUST-CREDIT-SCORE < 650 MOVE 'DECLINED' TO WS-CREDIT-RESULTütleb: „Kliendile, kelle krediidiskoor on alla 650, keeldutakse.“ Java peaks Java keeles sama ütlema:if (customer.creditScore() < CreditThresholds.MINIMUM_SCORE) return CreditDecision.declined(...). Mitteif (CUST_CREDIT_SCORE < 650) { WS_CREDIT_RESULT = "DECLINED"; }.
Praktiline teisendusprotsess, mis loob idiomaatilise Java keele:
1. samm: COBOL-i allika struktuurianalüüs, sõltuvusgraafik, äriloogika inventuur, andmemudeli taastamine, surnud koodi tuvastamine. Selle sammu käigus luuakse spetsifikatsioon. Enne selle sammu lõpuleviimist ei teisendata midagi.
2. samm: domeenimudeli disain, äriüksuste (klient, konto, tehing, poliitika) tuvastamine, millega COBOL-programmid töötavad. Nendest saavad Java domeeniklassid. Üksuse olekut esindavad WORKING-STORAGE muutujad saavad vastava domeeniklassi eksemplariväljadeks.
3. samm: Teenusekihi disain, äritoimingute (krediidikontroll, maksete töötlemine, saldo arvutamine) tuvastamine, mida COBOLi lõigud ja sektsioonid rakendavad. Need muutuvad Java teenusemeetoditeks vastavas domeeniteenuse klassis. PERFORM-ahelast, mis järjestab lõike, saab teenuse orkestreerimisloogika.
4. samm: Automaatne teisendamine mustandigeneraatorina. Kasutage teisendustööriista iga programmi jaoks Java-algoritmi loomiseks, tuginedes 2. ja 3. sammus loodud domeenimudelile. Vaadake mustand üle äriloogika inventuuri alusel, et veenduda iga otsustusharu esindatuses.
Samm 5: Süstemaatiline refaktoreerimine Joboli mustrite vastu, kuue mustrivastase paranduse rakendamine: staatilise oleku asendamine eksemplari olekuga, staatiliste meetodite jaotamine domeeniklassidesse, olekukoodide asendamine eranditega, asendamine double koos BigDecimal, asenda fikseeritud pikkusega massiivid järgmisega String, lagundage monoliitsed klassid ühe vastutusega teenusteks.
6. samm: Käitumusliku ekvivalentsuse testimine, käivitage refaktoreeritud Java COBOL-analüüsi käigus genereeritud iseloomustustesti korpuse vastu. Igal EVALUATE tingimusel ja IF-harul peaks olema vähemalt üks testjuhtum, mis seda testib ja kontrollib ekvivalentsust COBOL-väljundiga.
Kuidas SMART TS XL Hoiab ära Joboli tekkeallika
Joboli ennetamise struktuurianalüüsi eeltingimus, sõltuvusgraaf, äriloogika inventuur, surnud koodi tuvastamine ja andmemudeli taastamine on täpselt see, mis SMART TS XLCOBOL-allika analüüs annab enne mis tahes teisendustööriista käivitamist.
SMART TS XL'S staatilise koodi analüüs loetleb kõik EVALUATE tingimuse, iga IF haru, iga COMPUTE valemi ja iga PERFORM seose COBOL-i lähtekoodis – täielikus äriloogika inventuuris, mida refaktoreeritud Java peab usaldusväärselt esindama. Kui teisendustööriist loob Joboli, on äriloogika inventuur spetsifikatsioon, mille suhtes refaktoreerimist valideeritakse: iga inventuuri tingimus peab Javas esinema sobivas domeeniklassis, väljendatuna Java idioomi abil.
Rakenduse sõltuvuste kaardistamine loob PERFORM-graafiku ja programmikõnede graafiku, mis määravad Java teenusekihi struktuuri. Programmid, mis üksteist kutsuvad, kuuluvad sageli samasse piiratud konteksti. Programmid, mida paljud teised kutsuvad, on jagatud teenused, mis tuleb hoolikalt kujundada, et toetada kõiki oma tarbijaid Java arhitektuuris. Sõltuvusgraaf on sisend teenusekihi kujundamise etapis, teisendades COBOLi implitsiitse sidestusstruktuuri Java eksplitsiitseks sõltuvuste süstimise struktuuriks.
Vananenud koodi moderniseerimise analüüs tuvastab surnud koodi, lõigud ja sektsioonid, milleni tootmisprotsessides pole jõutud ning mis tuleks konverteerimise ulatusest täielikult välja jätta. Surnud COBOL-koodi teisendamine surnud Jobol-iks ja seejärel surnud Jobol-i refaktoreerimine raiskab vaeva, mille surnud koodi tuvastamise samm enne konverteerimise algust kõrvaldab.
Mõjuanalüüsi võimalus valideerib refaktoriseerimisjärjestuse: kui COBOL-programmi liides muutub refaktoriseerimise ajal Jobol-keelelt idiomaatilisele Java-keelele, tuvastab mõjuanalüüs kõik teised programmid, mille Java-ekvivalenti tuleb samuti uuendada, et see jääks muudetud liidesega järjepidevaks. Refaktoriseerimine sõltuvuste järjekorras, alustades kõige vähem sõltuvaid, minimeerib igal sammul vajalikku koordineerimist.
Teisendajad tõlgivad süntaksit. Moderniseerimine muudab tähendust.
Automatiseeritud COBOL-Java teisendajad on kiiremad kui inimese tehtud ümberkirjutamine. Need on optimeeritud ka teistsuguse eesmärgi saavutamiseks: süntaktiliseks vastavuseks, mitte semantiliseks ekvivalentsuseks sihtkeele idioomides. Jobol on see, mida süntaktiline vastavus tekitab, kui lähtekeelel (COBOL) ja sihtkeelel (Java) on põhimõtteliselt erinevad struktuurimudelid.
Organisatsioonid, mis Joboli väldivad, ei ole need, kes kasutavad paremaid konvertereid. Need on need, kes käsitlevad konverterit pigem mustandigeneraatorina kui valmistootena, investeerivad enne konversiooni algust struktuurianalüüsi, kujundavad Java domeenimudeli enne konverteri käivitamist ja rakendavad konverteri väljundile süstemaatilist refaktoriseerimist, kasutades valideerimisspetsifikatsioonina äriloogika inventuuri.
Jobol on välditav. Selle vältimise hind on struktuurianalüüs ja domeeni modelleerimise töö, mis peaks eelnema igale konversioonile. Selle vältimata jätmise hind on Java-süsteem, mille hooldamiseks on vaja COBOL-i ekspertiisi, mis tähendab, et moderniseerimisest oodatav kasu – võimalus süsteemi Java arendajatega hooldada – ei realiseeru kunagi.
Teisenda eesmärki. Mitte süntaksit. Erinevus seisnebki moderniseerimise kogu väärtuses.
