Piekeren over de business, niet over IT

IT ondersteunt de business. In de eerste fase van een softwareontwikkelingsproject werken gebruikers en informatici samen aan een model van de toekomstige toepassing. Zou het niet praktisch zijn als zo’n model rechtstreeks kon worden omgezet in code? En als er voor het realiseren van zo’n omzetting een wereldwijde standaard bestond? Dat is de ambitie van de Object Management Group met Model Driven Architecture.

De Object Management Group is een standaardisatiegroep. Ze definieerde onder meer een leveranciersonafhankelijke standaard voor middleware: CORBA (Common Object Request Broker Architecture), de standaard voor OO-modellering UML (Unified Modeling Language) en het Common Warehouse Metamodel, een standaard voor modellering van metadata voor objecten in een datawarehouse.

EEN PLATFORMONAFHANKELIJK MODEL
Sinds 2001 werkt de OMG aan een nieuw, ambitieus raamwerk, genaamd Model Driven Architecture. Wat is de bedoeling? ‘De OMG wil de wereld een raamwerk bieden om objectgeoriënteerde toepassingen te genereren op basis van modellen,’ legt professor Monique Snoeck, docent Beleidsinformatica aan de KU Leuven, uit, ‘Het raamwerk biedt een geheel van op elkaar afgestemde standaarden die het mogelijk maken om software te genereren in plaats van de code manueel te moeten schrijven. Softwareontwikkeling start van een platformonafhankelijk model, dat wordt gebouwd met UML, en beschrijft zowel de gegevens als de gegevensverwerking.

Het model kan worden omgezet in uitvoerbare programma’s, als men beschikt over de mapping voor het gewenste platform. ‘ Men kan dus een model bouwen voor een toepassing, op een ogenblik dat het platform nog niet gekozen is. Nog belangrijker: als het bedrijf verandert van platform, dan hoeft niet alles weggegooid te worden. Het model, dat de uitvoering van de bedrijfsprocessen weerspiegelt, en waar businessmensen en informatici veel tijd aan besteed hebben, is nog bruikbaar. Men genereert gewoon vanuit het model een werkende toepassing voor de nieuwe omgeving.

Modellen kunnen ook meermaals opnieuw gebruikt worden voor het genereren van dezelfde applicatie voor meerdere platformen. ‘Bovendien biedt het platformonafhankelijke model de gemeenschappelijke basis voor het ontwikkelen van brugcode, die software op verschillende platformen met elkaar integreert,’ aldus Monique Snoeck, ‘Op die manier bereikt het raamwerk de doelstellingen van portabiliteit, herbruikbaarheid van modellen en interoperabiliteit.’

Deze aanpak is geschikt voor IT-toepassingen van alle soorten, bijvoorbeeld bedrijfstoepassingen voor verwerking van gegevens, maar ook real-time en embedded software. Je kan deze aanpak bovendien gebruiken voor veel platforms (bijvoorbeeld Web Services, XML/SOAP, EJB, C#/.Net, CORBA), programmeertalen (bijvoorbeeld OO-Cobol, Java, C++, C#, Assembler) en databasemanagementsystemen (bijvoorbeeld Oracle, Sybase, DB2)

VAN HET MODEL NAAR DE UITVOERBARE CODE
En hoe komen we nu van het model naar de code? In vier stappen. We bouwen een Computation Independent Model, dan een Platform Independent Model, genereren daaruit een Platform Specific Model, en schrijven vervolgens de programmacode.

STAP 1 : THE COMPUTATION INDEPENDENT MODEL (CIM)
In het CIM beschrijven we de omgeving van het systeem en de vereisten voor het systeem, de requirements. Het CIM bevat geen informatie over de structuur van het systeem of de verwerking ervan; die zijn op dit ogenblik misschien zelfs nog niet bepaald. Het CIM wordt opgesteld door businessmensen en informatici samen.

STAP 2 : THE PLATFORM INDEPENDENT MODEL (PIM)
In het PIM beschrijven we de werking van een systeem: de gegevens en de gegevensverwerking, dus data en processing. Het PIM bevat NIET de details van een bepaald platform. Een PIM kan wel gebouwd zijn voor een platform van een bepaald type: het kan bijvoorbeeld gebouwd zijn voor een objectgerichte omgeving, zonder de details te bevatten van een bepaalde programmeertaal.

STAP 3 : THE PLATFORM SPECIFIC MODEL (PSM)
Hoe geraken we nu verder, tot bij het Platform Specific Model? Hiervoor hebben we een mapping nodig, de specificaties voor de transformatie van een PIM naar een PSM voor een bepaald platform. Bijvoorbeeld, wanneer we een PIM gebouwd hebben voor een database, hebben we een mapping nodig die de details van het databasemanagementsysteem bevat, aangeeft waar een index moet komen, en volgens welke regels de denormalisatie moet gebeuren.

STAP 4 : DE CODE
Dan kan er programmacode gegenereerd worden vanuit het PSM. Maar deze aanpak bevat ook een achterdeur: kunt u niet de hele werking van het systeem vatten in het model, STAP 2 : THE PLATFORM INDEPENDENT MODEL (PIM) In het PIM beschrijven we de werking van een systeem: de gegevens en de gegevensverwerking, dus data en processing. Het PIM bevat NIET de details van een bepaald platform. Een PIM kan wel gebouwd zijn voor een platform van een bepaald type: het kan bijvoorbeeld gebouwd zijn voor een objectgerichte omgeving, zonder de details te bevatten van een bepaalde programmeertaal.

STAP 3 : THE PLATFORM SPECIFIC MODEL (PSM)
Hoe geraken we nu verder, tot bij het Platform Specific Model? Hiervoor hebben we een mapping nodig, de specificaties voor de transformatie van een PIM naar een PSM voor een bepaald platform. Bijvoorbeeld, wanneer we een PIM gebouwd hebben voor een database, hebben we een mapping nodig die de details van het databasemanagementsysteem bevat, aangeeft waar een index moet komen, en volgens welke regels de denormalisatie moet gebeuren.

STAP 4 : DE CODE
Dan kan er programmacode gegenereerd worden vanuit het PSM. Maar deze aanpak bevat ook een achterdeur: kunt u niet de hele werking van het systeem vatten in het model,

Christiane Vandepitte is zelfstandig consultant.