Minu kogemus USA suurema panga (Bhasheer Lepakshi) suurarvuti moderniseerimisel

Minu kogemus USA suurema panga (Bhasheer Lepakshi) suurarvuti moderniseerimisel

Minu kogemus USA suurema panga (Bhasheer Lepakshi) PlatoBlockchain Data Intelligence'i suurarvuti moderniseerimisel. Vertikaalne otsing. Ai.

Suurarvuti moderniseerimise taust:

      Pärast arvutirevolutsiooni algust panganduses, kindlustuses ja teistes suuremates sektorites oli suurarvuti üks suurimaid revolutsioone andmete turvalisemal salvestamisel ja haldamisel. Isegi praegu säilitavad paljud suuremad pangad ja kindlustusseltsid Mainframe süsteemi.

      Aja möödudes tuli tehnoloogiliselt nii palju muudatusi ja maailm muutus digitaalsemaks ning kasutajad/kliendid soovivad andmetele juurde pääseda sekundite murdosa jooksul ning neil pole aega minna traditsioonilisele panga- ja muudele teenustele. Seega on pangad ja muud tööstused sunnitud liikuma digitaalse tee poole.

 Selles digitaalses kiires maailmas muutub pärandsüsteemide (nt suurarvuti) andmetele juurdepääsemine klientidele kiirete teenuste pakkumine keeruliseks, mistõttu soovivad kliendid ajakohastada.

Peamised algatused, mida peaarvuti moderniseerimiseks järgida, on järgmised:

  1. Ümberprojekteerimine: häiriv ümberkujundamine digitaalseteks platvormideks, nagu pilv- ja mikroteenused
  2. Ümberhostimine: kvalifitseeritud rakenduste ümberplatvormimine hajutatud platvormile, säilitades pärandarhitektuuri ja koodi.
  3. Kohapealne moderniseerimine: kasutage System z ja System I moderniseerimisvõimalusi õige kombinatsiooniga Legacy's
  4. Asenda: pärast põhjalikku kinnitusanalüüsi asendage rakendus sobiva COTS-tootega

Selles ajaveebis kirjeldatakse ümberkujundamise stsenaariumi. Selle stsenaariumi korral peame pärandkoodist välja võtma ärireeglid, mida edasisuunamise meeskond kasutab nõuete dokumendina:

Kuidas teisendada suurarvuti kood ärireegliteks?

1. Malli ettevalmistamine:

     Iga kord, kui alustame mis tahes pärandkonversiooni, on kõige esimene väljakutse mõista olemasolevat äriloogikat ja viia see õigesse vormingusse, millest Forward Engineering meeskond aru saab ja oma kodeerimisviisi välja mõelda.

Mall on ärireeglite kokkupanemisel võtmetähtsusega. Kui mall kirjeldab allolevat, oleks sellest abi.

  1. Töö kokkuvõte (JCL kokkuvõte), mis peaks kirjeldama allpool –
    1. Töö funktsionaalsus / kirjeldus
    2. Töös kasutatud failid (lugemine/kirjutamine)
    3. Kasutatud DB2 tabelid (programmiliselt)
    4. Ajakava teave
    5. Töövoog (tõenäoliselt puu struktuur)
    6. Taaskäivitamise juhised
  2. Ärireeglid – see peaks kirjeldama konkreetse programmi konkreetse funktsiooniga seotud reegleid
  3. Record Layout – programmis kasutatavad kirje paigutus/failistruktuurid
  4. Väljade kaardistamine – see peaks kirjeldama kas pildi- või tabelivormingus, kuidas äriloogikas/programmis allika sihtmärgi vastendamist tehakse

   2. Ärireeglite kirjutamine:

     Analüüsige koodi ja mõistke programmi loogilist kulgu. Ärge püüdke kirjutada iga lõiku reeglina, vajaduse korral peame võib-olla lõigud kombineerima, et äriloogika/reegel loogiliselt viia.

Ärireeglite koostamisel tuleb arvesse võtta järgmist.

  • Kaardistage iga tehing ja töö ärifunktsiooniga   
  • Kui reeglid on hõivatud, vastendage need tasemele-4, tase-3, tase-2, tase-1 ja tase-0. Tase 0 on kõrgeim ja see on funktsiooni saavutamiseks kombinatsioon tasanditest 1 kuni 4 (näide: kliendi liitumine on tase 0)
  • Pealkirjad, alapealkirjad – Pealkirjad ja alampealkirjad on ärireeglite kirjutamisel väga olulised, näiteks: üldiselt on töötlemise lõik seal, et töödelda põhiloogikat, kõik selle jaotise / lõigu all olevad funktsioonid tulevad alampealkirjadena, saate kogu sisust aru. voolu või loogikat, nähes pealkirja ja alampealkirju.
  • Ajutised muutujad/töötavad salvestusmuutujad – Andke kindlasti viide mis tahes Temp muutujale, mainige reegli numbrit, kus seda muutujat kasutame või kus me seda muutujat kasutame 
  • KUI Tingimused ja HINDA avaldused – Vanas programmeerimisstiilis IF-tingimuste puhul ei mainita END-IF-i, seega mainige kindlasti END-IF ja kasutage värve pesastatud IF-ide korral. Jagage iga tingimus konkreetseks reegliks.
  • PERFORM Loops – Mainige selgelt tsükli kohta, millal see algab ja millal see lõpeb
  • MASSIVID/tabelid – Mainige kõiki deklaratsioone massiivide/tabelite puhul ja sellega seotud kasutamist konkreetse funktsiooni jaoks.
  • Andmebaas – Andmebaasiga seotud loogikat kirjutades on parem kirjutada DECLARE CURSOR ja kõik muud SQL-laused reeglina ning anda viide kõikjal, kuhu vaja viidata. Ärireeglisse loogika lisamisel mainige SQLCODE tähendust.
  • Vigade käsitlemine – Veenduge, et vigade käsitlemine oleks koos DISPLAY avaldustega korralikult dokumenteeritud.
  • Levinud rutiinid – Ühiste rutiinide reeglid saab paigutada ühele ühisele lehele või dokumenti, nii et Forward Engineering meeskond saab need ühe korra koostada ja kasutada.

Ärireeglite esitlemine edasisuunamise insenerimeeskonnale:

       Peamine väljakutse, kui tõhusalt saate Forward Engineeringi meeskonnale loogikat selgitada, kui saate mõne tehnilise bakalaureusekraadi, kellel on süsteemist teadmised, ja teil veab! Et saaksite loogikat selgitada ja BA mõistab ja saab kasutusjuhtumeid välja mõelda.

Parem viis suurarvuti poolelt on koostada vooskeem, millel on töö tasemel väga kõrge voog. Et seda oleks Forward Engineeringi meeskonnale kogu voo kohta lihtne seedida ja ka suurarvuti kuttidele oleks lihtne voo kohta selgitada.

Selgitage BA ja Forward Engineering meeskonnale kindlasti kogu loogikat. Ja kui Forward Engineeringi poolel tekiks Low-level disain, siis omal moel. See oleks meeskonnale kasulik.

Reeglite teisendamine Javaks:

      Mainframe COBOLi Java-vormingus teisendamisel peaksite mõistma erinevust COBOLi ja Java vahel. Esiteks on COBOL protseduurikeel ja see oleks määratlenud etapid järjestikku. Kui Java on objektorienteeritud keel, mis järgib OOP-i kontseptsioone.

Kaaluge COBOLi jaoks hästi sobivate rakenduste tüüpe. Mõiste COBOL on akronüüm sõnast Common Business Oriented Language. Keel on loodud toetama ärifunktsioone, nagu aruandlus, numbrite kokkulugemine ja andmete töötlemine. See ei tähenda, et COBOL ei saaks teostada muud tüüpi töötlemist; see võib. Lihtsalt, et teatud tüüpi programme saab paremini välja töötada mõne muu keele abil.

    Java on objektorienteeritud programmeerimiskeel, mis sobib mitmeotstarbeliseks andmetöötluseks ja mille lisaeelis on kaasaskantavus mitme riistvaraplatvormi vahel. Võimalus käivitada sama programmi erinevates arvutites (kui platvormile on saadaval Java virtuaalmasin) on üks põhjusi, miks Java on tänapäeval üks populaarsemaid keeli uusarenduseks.

COBOL-koodi teisendamiseks tuleb Java poolelt teha järgmised kaalutlused:

  1. Saate aru java kodeerimisstandarditest vastavalt kliendikeskkonnale
  2. COBOLi ja Java andmetüüpide erinevus
  3. Samaväärsed funktsioonid COBOLi ja Java vahel.
  4. Millist andmebaasiühendust Java-s kasutada pärandandmebaasikõnede korral (kas JPA või JDBC)?
  5. Kas DB päringute jaoks on võimalik päringut optimeerida?
  6. Kas on võimalikud paralleelsed jooksud (sammude vahel)?
  7. Kas me saame DML-i operatsioonides rakendada tükeldamise loogikat?
  8. Kõik levinud rutiinid/teenused tuleb luua ja uuesti kasutada

Ajatempel:

Veel alates Fintextra