Quali sono le tre principali tecnologie per la riprogettazione di un sistema legacy COBOL

Naviga le tue risposte
2

Esiste un'applicazione che segnala i dati finanziari di una banca a una banca nazionale (tutti situati in Europa). È un sistema legacy che è scritto principalmente in COBOL. Solo l'interfaccia utente è scritta in Java.

La logica aziendale è memorizzata come tabelle e voci di base di dati complesse. Senza conoscere tutti i componenti interni, il sistema non può essere modificato in base alle nuove normative finanziarie. Pertanto, il sistema attuale è molto difficile da eseguire il debug e non è possibile.

Il mio obiettivo è ora quello di identificare tecnologie / metodi all'avanguardia per una riprogettazione e la riscrittura dell'intero sistema.

Quali considereresti come le tre tecnologie più importanti da utilizzare per la riscrittura di un sistema COBOL in finanza?

Le attuali considerazioni includono:

  1. Utilizzo di un approccio DSL (lingua specifica del dominio)
  2. Uso di un linguaggio di programmazione moderno come Scala
  3. Cubo MS OLAP (suggerito da un collega, non da me)
posta mrsteve 29.01.2012 - 22:46
fonte

2 risposte

3

Ingegneria inversa testata

Ci sono due parti.

  1. Un linguaggio moderno. C #, Java, Python, Scala. non utilizza un DSL. Qualsiasi DSL scelto diventa semplicemente un altro COBOL.

  2. Una suite di casi di test che i programmi originali sembrano trasmettere con successo.

Si noti che la maggior parte dei sistemi COBOL ha un numero enorme di singoli programmi applicativi. Quasi incomprensibile.

Tuttavia, il numero di programmi che creano il database Create-Update-Delete è notevolmente ridotto.

Il passaggio 1 consiste nel suddividere lo spazio dei programmi COBOL in due:

  • Create-Update-Delete. Da qualche parte vicino al 20%.

  • Recupera solo. Da qualche parte vicino all'80%.

Per l'80%, puoi usare qualunque strumento di segnalazione appaia pertinente. Ipercubi o altro. Non importa, poiché si tratta solo di rapporti e qualsiasi strumento di segnalazione delle merci funzionerà. Investire il minor tempo possibile nel riferire quanto umanamente possibile. Crea estrazione-trasformazione-carico (ETL) che popola un semplice data warehouse; creare metadati per quel magazzino che si adatta a uno strumento di reporting. Fatto.

Per il 20%, hai davanti a te un lavoro serio e difficile per raccogliere una suite di casi di test, conferma che il COBOL originale li elabora effettivamente come previsto e poi scrive un nuovo codice in C #, Java, Python o Scala per implementare quella logica di programmazione.

Troverete che il 20% dei programmi Create-Update-Delete coinvolge semplici regole di business che possono essere facilmente articolate, adattarsi all'ambiente normativo e facili da implementare nel codice Stored Procedures o Java (C # o Python). Evitare procedure memorizzate. (Haterz ti dirà che le stored procedure sono essenziali, ma non possono fornire una ragione.)

Troverete che l'80% dei programmi Crea-Aggiornamento-Elimina comprende eccezioni, casi speciali, sostituzioni e programmazione incompetente troppo terrificante da esaminare attentamente. (È come essere un personaggio di una storia di HP Lovecraft: inizi a dubitare dell'esistenza stessa della logica o della razionalità.)

Fai la migliore ipotesi possibile su questo codice e fidati dei tuoi casi di test. Il tempo speso per creare casi di test e campioni è più prezioso del tempo passato in reverse engineering con il vecchio COBOL.

    
risposta data 29.01.2012 - 23:20
fonte
1

The business logic is stored as complex data base tables and entries. Without knowing all internals, the system can hardly be changed according to new financial regulations. Thus, the current system is very hard to debug and unmaintainable.

Questo potrebbe significare 3 cose: 1-Non è possibile comprendere i requisiti aziendali originali 2-Non si capisce la logica corrente nel codice 3: 1 e 2

Se si applica (1), non è possibile riscrivere il sistema senza aggirare il problema. La tecnologia non sarebbe il tuo problema principale.

se (2) è il problema, ma comprendi i requisiti aziendali, devi prendere in considerazione quanto segue nella nuova tecnologia selezionata:

  1. Dovresti provare a far sì che tutti i tuoi team prendano lo stesso linguaggio, se possibile, ciò rende Java un buon componente dell'architettura tecnica

  2. Dovresti assicurarti di poter accedere ai dati del mainframe. Presumo che possa essere memorizzato su DB2, IMS, VSAM, file SAM e così via. Poiché IBM ha un compilatore Java, ciò farebbe sì che java giochi un ruolo nella soluzione back-end.

  3. Se l'applicazione non fa altro che riferire (aggregazione e riepilogo) a fini di reporting con un consolidamento dei dati, allora stai cercando una soluzione Modifica, Trasforma e Carica. Uno strumento come IBM InfoSphere (DataStage) è l'ideale se puoi permetterti il prezzo. Esistono anche altri strumenti. A mio modesto parere, sceglierei uno strumento ETL leader sui cubi MS OLAP, specialmente per il lancio di una nuova versione della tecnologia MS OLAP. Inoltre, se si utilizza MS, sarà necessario migrare i dati.

  4. È necessario considerare di non eseguire la migrazione dei dati, se possibile. Se puoi, allora ancora, non usare MS Cubes.

  5. È necessario prendere in considerazione una strategia per la parte OLAP della GUI.

Spero che quanto sopra aiuti.

    
risposta data 29.01.2012 - 23:10
fonte

Leggi altre domande sui tag

Come copyright e licenza dei singoli file di codice Pattern per l'interazione dell'utente e la conferma