Ontkoppeling van generatie en modelleringstool .

Modelgedreven ontwikkeling kan een grote factor zijn in het verbeteren van de efficiëntie van de ontwikkeling van dataoplossingen en de kwaliteit van het eindproduct. Om modelgedreven ontwikkelen succesvol toe te passen zijn tools nodig voor het modelleren van de applicatie en voor het genereren van de daadwerkelijke software op basis van het model. Dit artikel […]

Ontkoppeling van generatie en modelleringstool .

Modelgedreven ontwikkeling kan een grote factor zijn in het verbeteren van de efficiëntie van de ontwikkeling van dataoplossingen en de kwaliteit van het eindproduct. Om modelgedreven ontwikkelen succesvol toe te passen zijn tools nodig voor het modelleren van de applicatie en voor het genereren van de daadwerkelijke software op basis van het model. Dit artikel […]

Inhoudsopgave

Modelgedreven ontwikkeling kan een grote factor zijn in het verbeteren van de efficiëntie van de ontwikkeling van dataoplossingen en de kwaliteit van het eindproduct.

Om modelgedreven ontwikkelen succesvol toe te passen zijn tools nodig voor het modelleren van de applicatie en voor het genereren van de daadwerkelijke software op basis van het model.

Dit artikel vergelijkt een scenario waarin modellering en het genereren van code in één tool zijn geïntegreerd, met een scenario waarin afzonderlijke tools worden gebruikt voor het modelleren en genereren.

Voorbeeld van een gebruiksscenario

Voor de doeleinden van dit artikel beschouwen we een eenvoudig scenario waarin de modelleringsvereisten als volgt zijn:

  • Het model omvat datastructuren in de vorm van entiteiten met attributen en relaties
  • Het omvat ook modelgegevensstromen die definiëren welke brongegevens nodig zijn voor een bepaalde doelentiteit, waaronder deelnamevoorwaarden in gevallen waarin een doelentiteit wordt gevuld met behulp van meer dan één bronentiteit.

Op basis van de modelinformatie moeten de volgende softwarecomponenten worden gegenereerd:

  • DDL voor de vereiste tabellen
  • SQL-views die de gegevensstromen implementeren
  • Opgeslagen procedures die uit de views lezen en naar de doeltabellen laden

Bij het toepassen van modelgestuurde ontwikkeling zal je altijd gebruik maken van een modelleringstool. Ook zal je atijd ergens in het proces code genereren. In dit artikel beschrijven we de verschillen tussen het integreren van de codegeneratie in een modelleringstool en het scheiden van de codegeneratie.

Geïntegreerde codegeneratie

Wanneer u begint met modelgestuurde ontwikkeling, is het erg handig om een modelleringstool te hebben waarin u ook sjablonen kunt maken om de implementatie te genereren. Dit zorgt voor een zeer snelle start en vanuit gebruikersperspectief is er maar één tool bij betrokken.

Een voorbeeld van een modelleertool waarin dit mogelijk is, is SAP PowerDesigner. Aangepaste modelleringsopties en codegeneratie kunnen worden gemaakt in een zogenaamde modelleringsextensie (XEM).

Voorbeeldimplementatie in PowerDesigner

Out-of-the-box PowerDesigner ondersteunt het modelleren van logische datastructuren (entiteiten, attributen, relaties) en data mappings (bron-naar-doel mapping op attribuutniveau). Een voorbeeld van maatwerk zou een PowerDesigner-extensie kunnen zijn die:

  • Verbetert de modelleringsopties, zodat joinvoorwaarden kunnen worden gedefinieerd op een datatoewijzing (iets dat niet mogelijk is met de standaardfuncties)
  • Implementeert codesjablonen voor:
    • SQL-weergaven gebaseerd op de gegevenstoewijzingen (met behulp van de join-voorwaarden uit de modelleringsverbetering)
    • SQL Opgeslagen procedures om gegevens uit de views naar de doeltabel te laden
    • Orkestratietaken die de opgeslagen procedure aanroepen, bijvoorbeeld in Azure Data Factory

Voors en tegens

In onderstaande tabel hebben wij de voor- en nadelen van deze manier van werken op een rij gezet.

VoorTegen
Er is slechts één hulpmiddel nodig
  • Als u overschakelt naar een andere modelleringstool, moet alle logica voor modellering en codegeneratie worden aangepast.
  • Het optimaliseren van de prestaties voor het genereren van code kan moeilijk zijn.

Koppel modellering los van het genereren van code

Een andere mogelijke methode om modelgestuurde ontwikkeling toe te passen is het gebruik van een modelleringstool, puur om het logische model met zijn gedrag vast te leggen. Voor een dataoplossing wordt dit gemodelleerd met behulp van entiteiten, relaties, mappings en transformaties.

Om de code in dit scenario te genereren, moeten alle metagegevens die nodig zijn voor het genereren van code vanuit de modelleringstool worden geëxporteerd naar een formaat dat bruikbaar is voor het genereren van code.

In dit scenario zouden we minstens twee tools gebruiken, namelijk de modelleringstool en een codegenerator. Bij CrossBreeze gebruiken we CrossGenerate als codegenerator. Deze generator heeft XML-bestanden nodig als modelinvoer, dus in dit geval kunnen we alle metagegevens naar XML-formaat exporteren met behulp van de modelleringstool.

Voors en tegens

In onderstaande tabel hebben wij de voor- en nadelen van deze manier van werken op een rij gezet.

VoorsTegens
  • Het onderhouden van modellering en het genereren van code kan eenvoudiger in meerdere teams worden gedaan.Geen afhankelijkheid van modelleringstool tijdens het genereren, dus genereren kan worden gedaan op een machine (of k8s-pod) zonder dat de modelleringstool is geïnstalleerd.Het updaten/wisselen van de modelleringstool of codegenerator kan onafhankelijk van elkaar worden gedaan (zolang de metadata-export hetzelfde blijft).
  • Gemakkelijker om meerdere technologiestacks tegelijkertijd te ondersteunen (bijvoorbeeld tijdens een PoC voor een nieuwe technologie).
Kennis van meerdere tools is nodig.

Samenvatting

Bij CrossBreeze geven we er, op basis van onze ervaring met beide benaderingen, de voorkeur aan om de codegeneratie los te koppelen van de modelleringstool. In ons perspectief wegen de winst op het gebied van flexibiliteit en prestatie zwaarder dan de nadelen van het toevoegen van een nieuwe tool aan de ontwikkelstapel.