Ik vraag mij af wat eigenlijk het voordeel is om te gaan van een niveau als Java, naar een nieuw niveau als "Modelleertaal A". Schematisch:
1. Inleiding
Van assembler naar C++, Java, PHP, hebben we heel wat voordelen gezien. We kunnen de eenvoudige routine klusjes nu eenvoudiger typen (door een for-lus, ...) en we kunnen eenvoudig abstraheren (door klassen, functies en namespaces).
Het is de dag van vandaag dus makkelijker om instructies te schrijven om onze machine aan te sturen als vroeger.
Later krijgen we de komst van modellen. We zullen daarbij twee soorten van modellen moeten hanteren.
Eerst en vooral zullen we een
conceptueel model moeten opzetten
van het probleem. We moeten namelijk zien dat we het probleem van onze opdrachtgever goed begrepen hebben. Zoiets bestaat uit een aantal tekeningetjes en pijltjes en is heel informeel. We gebruiken graag een visueel model in deze fase omdat zoiets duidelijk maakt waar het om draait.
Daarna zullen we, eens we het probleem begrepen hebben, een technische oplossing van ons probleem willen uitwerken. We gaan ons probleem opdelen in een aantal onderdelen, en elk onderdeel toevertrouwen aan een team. We spreken wel af dat elk team zal werken in zijn eigen namespace en een bepaalde interface ter beschikking stelt voor de andere high-level ontwikkelaars. Elke teamleader zal een
model van de oplossing maken. Hiervoor maakt hij gebruik van UML klasse diagrammen. Hierdoor heeft hij een eenvoudig overzicht van de oplossing van het probleem en kan ieder teamlid eenvoudig een deel van het probleem laten oplossen.
Voorgaande modellen zullen we ook aanduiden met de term
vereenvoudigde modellen. Een vereenvoudigd model kunnen we als het ware aanduiden als een model dat wat moet gemaakt worden, eenvoudig voorstelt. We doen dit doorgaans visueel. Hierdoor zien we snel in 1 oogopslag wat er moet gebeuren.
Naast de vereenvoudigde modellen hebben we ook nog de
probleemoplossende modellen. Eigenlijk is een probleemoplossend model een synoniem voor een "verzameling instructies om een machine aan te sturen". Hierdoor vallen een C++-programma en een Java-programma ook onder het woord model. Een UML klasse-diagram is geen probleemoplossend model, omdat het niet de nodige instructies biedt om een machine aan te sturen.
2. Voordeel? Sneller verifiëren met de klant
Nu hoor je vaak dat men als voordeel voor het technisch uitwerken, een modelleertaal kan gebruiken, ipv een programmeertaal als Java. Omdat men dan denkt dat er hierdoor sneller met de klant kan geverifieerd worden of wat er gebeurt nog juist is. Het is zo'n beetje als het werken met CRC-kaarten. Men wil hier eigenlijk gebruik gaan maken van de eigenschap dat in Java, het conceptueel model van het probleem dicht ligt bij hoe het geprogrammeerd (opgelost) wordt.
Maar is dit eigenlijk wel de oplossing? Heeft de klant überhaupt wel behoefte om te weten hoe we de oplossing van het probleem uitwerken? Wellicht niet. Zo lang het maar een oplossing biedt voor het probleem.
Daarom zou je je kunnen afvragen of het niet beter is om gewoon eerst grondig het probleem te analyseren. We moeten weten wat er aan de hand is. Waarom zouden ze het graag anders zien? Denk heel menselijk en humaan na op die momenten. Voel de sociale situatie aan, voel wat een verandering op een bepaalde werking van het systeem zal hebben als output. Wijs de opdrachtgever na de analyse op de potentiële gevaren (bijvoorbeeld: door het automatiseren van een bepaalde schakel, zal het personeel minder sociaal contact met elkaar kunnen hebben, wat de algemene sfeer om de werkvloer naar omlaag zal trekken). Vaak kan het oplossen op een andere wijze voordeliger zijn voor de algemene leefomgeving.
Verder heeft deze manier van werken ook het voordeel dat je goed weet wat je moet doen. Je gaat na je grondige analyse terug naar je opdrachtgever en doet concreet volgende twee dingen. Leg hem allereerst uit wat het resultaat is van je analyse en vertel hem waar de problemen zich situeren. Leg hem vervolgens uit hoe je het probleem zal oplossen in Nederlandse taal (+ eventueel wat figuren) en vraag aan de opdrachtgever of dat is wat hij wil. Hierdoor dek jij jezelf ook voor een stuk wat in. Hij kan niet meer zeggen dat het niet is wat hij wilde (verzwijg dit uiteraard!). Zorg er dus wel voor dat je je analyse heel goed gedaan hebt, en laat je opdrachtgever je vertrouwen winnen.
De opdrachtgever moet dus tijdens het ontwikkelingsproces niet betrokken zijn. De oplossing die we maken zal goed zijn omdat wij het probleem heel grondig hebben geanalyseerd. Je opdrachtgever vertrouwt je en hoeft niet mee te kijken naar het model van de oplossing. Het is ook niet de bedoeling dat het personeel van de afdeling, de personeelschef of de domein expert betrokken zijn bij het ontwikkelen van de oplossing van het probleem. Hiervoor moet men jou maar vertrouwen.
3. Voordeel? Eenvoudiger een machine kunnen aansturen
Een ander voordeel dat men vaak hoort is dat we sneller een machine kunnen aansturen. We werken immers op een "hoger niveau". Bij assembler naar Java hebben we een serieuze winst gehad. Dus, we moeten bij Java naar "modelleertaal A" ook wel een serieuze winst krijgen. Vaak hoor je dan als voordeel dat er visueel gewerkt wordt. Maar, de geschiedenis heeft al uitgewezen dat visueel programmeren geen echte hoogvlieger was.
Waar we eigenlijk naar op zoek zouden moeten gaan is wat er momenteel lastig is bij het gewone programmeren. Wat kan eventueel sneller. Kunnen we misschien meerdere methoden voor het geven van instructies aan een machine combineren? Dit zou zeker handig zijn.
4. Eenvoudig eigenschappen controleren
Als er eenvoudiger bepaalde eigenschappen kunnen nagegaan worden in "Modelleertaal A" dan in "Java" dan kan dat een voordeel zijn. Alhoewel het in "Java" per definitie ook mogelijk zou moeten zijn. Als bepaalde eigenschappen sneller visueel zichtbaar zijn in "Modelleertaal A" dan is dat ook een voordeel tegenover Java.
5. Eenvoudiger zaken uitdrukken in de modelleertaal
Als bepaalde zaken eenvoudiger uit te drukken zijn in een bepaalde modelleertaal (bijv. de route hoe pakketten moeten gestuurd worden), een specificatie van een object-georiënteerde taal (meer vertrouwen), een GUI-builder, ... dan is dat zeker een voordeel. Toch zou het handig zijn moesten deze talen makkelijk gecombineerd kunnen worden.
6. Conclusie
Alhoewel men vaak ook argumenten geeft die niet opgaan, kunnen modelleertalen wel zeker een nut hebben in software engineering. Toch moeten we de verschillende talen eenvoudig kunnen combineren. We moeten de mogelijkheid hebben om een groot deel van onze machine instructies in Java te schrijven, een deel in Click, en een deel met een GUI builder.
Sommige modelleertalen zijn dan weer geschikt op een ander vlak. Bijvoorbeeld Petri Nets en AGG. Zij kunnen samen met talen als Z, ... gebruikt worden om formeel een specificatie te schrijven voor het systeem. In de meeste gevallen gaan we dat niet doen. Soms, willen we nadat we ons probleem ge-analyseerd hebben, heel concreet opschrijven wat we gaan maken. Zo concreet dat er zich geen dubbelzinnigheden meer zich kunnen voordoen. Dit kan dan weer een voordeel hebben bij het ontwikkelen van risicovolle systemen.
7. Request for comment
Graag commentaar!