ISO 20022: UML -> XML

„Vše se děje v UML“ znamená:

Že kompletní definice finančních obchodních konceptů, jejich atributů, datových typů a vzájemných vztahů je primárně vytvořena a spravována pomocí diagramů a modelovacích prvků UML. XML schémata (ty .xsd soubory, které vidíte) jsou pak automaticky generována z těchto UML modelů. Finální XML zpráva je pak jen „serializací“ dat podle tohoto XML schématu.

Jinými slovy:

• Lidský faktor a analýza: Prvotní práce analytiků a odborníků z finančního sektoru spočívá v definování a vizualizaci těchto konceptů v UML.
• Centrální zdroj pravdy: UML model je „jediný zdroj pravdy“ (Single Source of Truth) pro veškerou sémantiku a strukturu ISO 20022. XML schémata jsou jeho odvozeniny.

Příklad UML pro ISO 20022: Koncept „Party“ (Účastník transakce)

Vezměme si jeden ze základních „stavebních kamenů“ v ISO 20022 – koncept „Party“ (čili jakákoli zúčastněná strana v transakci, ať už fyzická osoba nebo právnická entita).

Jak to vypadá v UML (zjednodušený třídní diagram):

classDiagram
    direction LR

    class PartyIdentification {
        +Id: GenericIdentification // Identifikace (např. BIC, LEI, IBAN, jméno)
        +Name: String             // Název (např. jméno firmy, jméno osoby)
        +PostalAddress: PostalAddress // Adresa
        +Country: CountryCode     // Kód země
    }

    class PostalAddress {
        +StreetName: String
        +BuildingNumber: String
        +PostCode: String
        +TownName: String
        +Country: CountryCode
    }

    class GenericIdentification {
        +Id: String
        +SchmeNm: String // Název schématu identifikace
        +Issr: String    // Vydavatel (např. "SWIFT", "LEI")
    }

    class Account {
        +Id: AccountIdentification // IBAN, BBAN atd.
        +Ccy: ActiveOrHistoricCurrencyCode // Měna účtu
        +Nm: String              // Jméno účtu
    }

    class AccountIdentification {
        +IBAN: String
        +Othr: GenericIdentification // Jiná identifikace účtu
    }

    class PaymentInstruction {
        +InstructionId: String
        +PmtId: PaymentIdentification
        +Amt: AmountAndCurrency
        +Purpose: String // Účel platby
    }

    class PaymentIdentification {
        +EndToEndId: String
        +UETR: String
    }

    class AmountAndCurrency {
        +Value: Decimal
        +Currency: ActiveOrHistoricCurrencyCode
    }

    PaymentInstruction "1" *-- "1..*" PartyIdentification : +InitiatingParty / +Debtor / +Creditor
    PartyIdentification "1" *-- "0..1" PostalAddress : +hasAddress
    PartyIdentification "1" *-- "0..1" Account : +hasAccount
    Account "1" *-- "1" AccountIdentification : +identifies
    PaymentInstruction "1" *-- "1" PaymentIdentification : +identifiesPayment
    PaymentInstruction "1" *-- "1" AmountAndCurrency : +hasAmount

Vysvětlení UML diagramu a co to znamená „Vše se děje v UML“:

1. Třídy (Classes): Každý obdélník v diagramu je „třída“, která reprezentuje koncept (např. PartyIdentification, PostalAddress, Account, PaymentInstruction). Tyto třídy jsou „stavebními kameny“ standardu.
2. Atributy (Attributes): Seznam položek uvnitř třídy (např. +Id: GenericIdentification v PartyIdentification). To jsou vlastnosti daného konceptu. Každý atribut má svůj datový typ (např. String, Decimal, CountryCode, ActiveOrHistoricCurrencyCode, nebo odkaz na jinou třídu/komponentu).
3. Vztahy (Relationships): Čáry mezi třídami představují, jak spolu koncepty souvisí:
   • Agregace/Kompozice (Composition/Aggregation): Plný kosočtverec (např. PaymentInstruction má (kompozice) PartyIdentification jako InitiatingParty, Debtor, Creditor). To znamená, že jedna třída „obsahuje“ nebo se „skládá“ z jiných tříd. Kardinalita (např. „1“, „1..*“, „0..1“) určuje, kolik instancí dané třídy může být součástí.
     • Například: PaymentInstruction "1" *-- "1..*" PartyIdentification : +InitiatingParty / +Debtor / +Creditor znamená, že každá platební instrukce (1) musí mít minimálně jednu (1..*) identifikaci strany, která může být Odesílatelem, Dlužníkem nebo Věřitelem.
   • Asociace (Association): Přímá čára s rolí (např. PartyIdentification má PostalAddress).
4. Datové typy (Data Types): V ISO 20022 jsou definovány komplexní datové typy (např. IBANIdentifier, BICFIIdentifier, Max35Text, ISODate). Tyto typy zajišťují jednotnost a validaci dat napříč všemi zprávami. V UML jsou reprezentovány jako typy atributů.

Jak se z tohoto UML stane XML (Velmi zjednodušený „překlad“):

1. Třídy se stanou XML elementy nebo komplexními typy:
   • Třída PaymentInstruction se může stát kořenovým elementem XML zprávy nebo komplexním typem.
   • Třída PartyIdentification se stane XML elementem (např. <PtyId>).
2. Atributy se stanou vnořenými XML elementy nebo atributy:
   • Atribut Name v PartyIdentification se stane <Nm>Jan Novák</Nm>.
   • Atribut Id v PartyIdentification by byl komplexnější element pro identifikaci.
3. • Vztah, kde PaymentInstruction „obsahuje“ PartyIdentification (InitiatingParty, Debtor, Creditor), se v XML promítne do vnořené struktury:Vztahy definují strukturu hnízdění (nesting):

   <PaymentInstruction>
     <InitiatingParty>
       <Id>...</Id>
       <Name>...</Name>
     </InitiatingParty>
     <Debtor>
       <Id>...</Id>
       <Name>...</Name>
     </Debtor>
     <Creditor>
       <Id>...</Id>
       <Name>...</Name>
     </Creditor>
     </PaymentInstruction>
   

Proč je to tak silné a „unikátní“:

• Jazyk pro byznys i IT: UML poskytuje most mezi finančními experty (kteří rozumí obchodním procesům) a IT architekty (kteří rozumí datovým strukturám). Všichni mluví jedním vizuálním jazykem.
• Abstrakce před implementací: UML umožňuje definovat sémantiku (co to znamená) ještě předtím, než se rozhodne o syntaxi (jak se to zapíše). To je klíčové pro dlouhodobou stabilitu a interoperabilitu standardu.
• Automatické generování schémat: Jakmile je UML model stabilní, speciální nástroje (tzv. „Schema Generators“) ho dokážou automaticky přeložit do XML schémat (XSD souborů), které pak aplikace používají k validaci a zpracování dat. Tím se minimalizují chyby způsobené ručním překladem.
• Konzistence a znovupoužitelnost: Koncept PartyIdentification nebo PostalAddress je definován jednou v UML a je pak znovupoužíván v jakékoli zprávě ISO 20022, kde je potřeba identifikovat stranu nebo adresu. To zajišťuje konzistenci a snižuje redundanci.

„Vše se děje v UML“ tedy znamená, že UML je primární jazyk a prostředí, kde se formálně definuje celá sémantika a struktura finančních zpráv ISO 20022, a XML je jen technický výstup této definice.