Model driven engineering

Examenroosters, algemene discussies, ...

Moderator: Praesidium

Glenn
Posts: 280

Model driven engineering

Post#1 » Sun Nov 27, 2011 1:23 am

Model driven engineering verwijst naar een aantal software ontwikkelingsmethoden waarbij software modellen een centrale plaats innemen. We kunnen deze ontwikkelingsmethoden opdelen in twee groepen.
  • modellen worden gemaakt tot op een bepaald detail niveau, en daarna wordt voor deze modellen code met de hand geschreven
  • complete modellen worden gemaakt inclusief uitvoerbare acties
De eerste methode heb ik onder andere al toegepast bij 'Project databases'. De andere methode is relatief nieuw voor mij en wordt denk ik toegelicht bij enkele cursussen hier aan de UA.

Wat ik graag zou weten is wat de voordelen zijn van deze laatste aanpak. Ik heb er al vanalles over gelezen maar ben nog niet helemaal overtuigd! :D
Last edited by Glenn on Sun Nov 27, 2011 8:47 pm, edited 1 time in total.

User avatar
Joachimvdh
Prosenior
Posts: 1092

Re: Model driven engineering

Post#2 » Sun Nov 27, 2011 12:33 pm

Neem uw click voorbeeld. Beeld u nu in dat ge dat RSVP netwerk van vorig jaar moest gaan definieren ergens in ne file zonder de click syntax, aka packets van de ene poort naar de andere pullen/pushen/... daar komt heel wat synchronisatie timing en threading aan de pas, iets waar ge u nu niks van moet aantrekken, gewoon wat pijltjes tussen poorten en t'is fixed.

Het einddoel van MDE is dat ge u van code helemaal niets meer moet aantrekken, zoals ge u niks van assembler moet aantrekken als ge C++ schrijft. Er zijn tools en modelleertalen die daar al ver in staan, anderen zijn daar nog ver vanaf. Eens je in die ideale situatie beland is dit een gigantisch voordeel. Als je programmeert, hoeveel tijd verspil je niet aan het maken van syntaxfouten en semantische fouten omdat objecten in een toestand belanden die je toch niet echt had voorzien? Om dat dan te vermijden schrijf je testen maar dat neemt ook tijd in beslag daarom dat veel studenten dat ook nog eens overslaan. Last but not least ga je uw objecten liggen "visualiseren" door overal print statements te zetten en alles manueel te checken, tijdrovend jobke en iets wat ge bij MDE gewoon doet door uw model te laten lopen en eventjes alles te volgen.

Het idee achter MDE is dat ge u van syntax bijna niks moet aantrekken, en u volop op semantiek kunt focussen, alsook het eenvoudig verifiëren of uw semantiek wel correct is. Sinds FOTS vorig jaar heb ik zelf ingezien dat als ge mij een heel java / C++ project stuurt met de vraag "hier loopt ergens iets mis als ik deze input geef" ik het waarschijnlijk minder snel ga vinden als dat ge mij een model geeft dat ik even kan laten lopen. Bovendien voelde ik mij op het einde vrij zeker dat mijn java VM correct was, terwijl als ik die VM had gecode ik niet met zekerheid had durven zeggen dat ze volledig juist zou werken

User avatar
Fristi
WOZ
Posts: 4565

Re: Model driven engineering

Post#3 » Sun Nov 27, 2011 1:18 pm

Een ander voordeel van dat visueel werken is dat bijvoorbeeld ook niet zo technisch geschoolde mensen bepaalde taken op zich kunnen nemen.

Ik moet nu bijvoorbeeld voor een project het gedrag van NPC's gaan modelleren d.m.v. statecharts. Je kan je best inbeelden dat een game designer zonder al te veel technische kennis dan ook plots in staat is om complex reactief gedrag te gaan uitwerken zonder dat em den AI letterlijk moet coderen.

Alles is een model trouwens, ook Java, C++.

Bij modellen zit ook zo iets als transformaties ( wat op zich ook weer modellen zijn ) tussen modellen. Je gaat van bijvoorbeeld statecharts een transformatie (dus dat gaat automatisch met een druk op de knop, je maakt gewoon het model van hoe je statecharts naar pakweg petri nets mapt en dan accepteert da alles dat aan zijn specificatie voldoet). naar petri nets utivoeren. Dan verlies je miss sommige informatie, maar dan heb je wel de kracht van petri nets om analyse op je model te gaan uitvoeren.

Het probleem bij dergelijke zaken is dat informatici traditioneel nogal een afkeer hebben van alles wat met vakjes en pijltjes slepen is en het coden prefereren. Dit heeft van mij ook een mindswitch vereist, maar ik zie intussen wel de kracht er van in.
Fristi Ad Infinitum

WINAK WOZ 2013 - ...
WINAK Magister Fristi 2012-2013
WINAK Feest 2011-2012
WINAK Schachtentemmer 2010-2011
WINAK Scriptor 2008-2009 | 2009-2010

Glenn
Posts: 280

Re: Model driven engineering

Post#4 » Sun Nov 27, 2011 8:34 pm

Ik begrijp jullie standpunten. Click vind ik trouwens een heel goed voorbeeld. Ik ben zelf een grote liefhebber van Click en ben blij dat we ons project van Telecom daar mee kunnen maken. Je voorbeeld over AI lijkt mij inderdaad wel interessant. De leercurve hiervoor is misschien minder hoog (wat zeker een voordeel is!).

Als modellen snel kunnen omgezet worden in andere modellen om daar analyses op uit te voeren lijkt mij ook wel een voordeel. Zeker die analyses lijken mij wel iets gaaf. Alhoewel ik mij wel afvraag wat je juist allemaal kan analyseren. Volgens een stelling uit het boek "Introduction to automata theory, languages and computation" is het bijvoorbeeld niet mogelijk om een "Hello, world"-tester te maken. Dat is een hypothetisch programma dat na gaat of een C-programma al dan niet "Hello, world" zou uitprinten.

Verder zou ik ook nog even de aandacht willen vestigen op punt 24.2.4 uit de Stroustroub (3de editie), waar Stroustroub het heeft over "Geen gebruik maken van programmeren".

In dit punt legt hij uit waarom hij denkt dat model-gedreven technieken niet onmiddellijk zullen gebruikt worden. Hij zegt daar het volgende
Zulke technieken werken goed op sommige toepassingsgebieden, waar een goede theoretische basis is (zoals voor wiskunde, toestandsautomaten en relationele databases) of waar er een algemeen raamwerk is waarbinnen kleine applicatiefragmenten kunnen worden ingebed (zoals grafische gebruikersinterfaces, netwerksimulaties of databaseschema's). Doordat deze technieken overduidelijk hun nut hebben op specifieke (en zeer belangrijke) gebieden, zou men kunnen gaan denken dat traditioneel programmeerwerk door deze technieken 'zeer binnenkort' overbodig zal zijn. Dat is niet het geval. Buiten de gebieden met een goede theoretische basis zijn er namelijk voor deze technieken zulke uitgebreide specificaties nodig, dat ze de complexiteit van een algemene, traditionele programmeertaal weer zouden benaderen. Op dat moment schiet het echter zijn doel van een zuivere, goed gefundeerde specificatietaal voorbij.
Graag feedback! :D

User avatar
Fristi
WOZ
Posts: 4565

Re: Model driven engineering

Post#5 » Mon Nov 28, 2011 12:47 am

Glenn wrote:Ik begrijp jullie standpunten. Click vind ik trouwens een heel goed voorbeeld. Ik ben zelf een grote liefhebber van Click en ben blij dat we ons project van Telecom daar mee kunnen maken. Je voorbeeld over AI lijkt mij inderdaad wel interessant. De leercurve hiervoor is misschien minder hoog (wat zeker een voordeel is!).
Minder hoog is nogal een understatement, men kan quasi letterlijk diagrammekes tekenen. Click is in se maar een low level model hoor, op zich is nen rfc iets dat zo goed gespecifieerd is dat dat wel te modelleren valt op een hoger niveau.
Stroustroup wrote: Zulke technieken werken goed op sommige toepassingsgebieden, waar een goede theoretische basis is (zoals voor wiskunde, toestandsautomaten en relationele databases) of waar er een algemeen raamwerk is waarbinnen kleine applicatiefragmenten kunnen worden ingebed (zoals grafische gebruikersinterfaces, netwerksimulaties of databaseschema's). Doordat deze technieken overduidelijk hun nut hebben op specifieke (en zeer belangrijke) gebieden, zou men kunnen gaan denken dat traditioneel programmeerwerk door deze technieken 'zeer binnenkort' overbodig zal zijn. Dat is niet het geval. Buiten de gebieden met een goede theoretische basis zijn er namelijk voor deze technieken zulke uitgebreide specificaties nodig, dat ze de complexiteit van een algemene, traditionele programmeertaal weer zouden benaderen. Op dat moment schiet het echter zijn doel van een zuivere, goed gefundeerde specificatietaal voorbij.
Hij heeft hier ook gelijk in. Programmeren zal altijd nodig blijven, al was het maar om compilers te schrijven voor die modellen om te zetten naar iets wat een pc verstaat. Maar ge moet maar is nadenken over hoeveel toepassingen onder de door stroustroup beschreven normen vallen...

Nokia ontwikkelt zijn gsm's dmv models, die modelleren gewoon heel het spul. (Waarmee ik niet wil zeggen dat er voor hun software niet geprogrammeerd wordt).

Van Gheluwe heeft ons ook een voorbeeld gegeven voor bijvoorbeeld een smartphone applicatie voor bijvoorbeeld een congres. Je kon zien waar wanneer wat te doen was en je, indien nodig, registreren. Was ook nog een hoop andere shizzle mogelijk. Als je de bijhorende statechart ervan zag. wel die was belachelijk simpel.

Kortom, het lost niet alles op, maar het maakt bepaalde zaken wel enorm veel makkelijker en heeft zeker zijn toepassingen.
Fristi Ad Infinitum

WINAK WOZ 2013 - ...
WINAK Magister Fristi 2012-2013
WINAK Feest 2011-2012
WINAK Schachtentemmer 2010-2011
WINAK Scriptor 2008-2009 | 2009-2010

Glenn
Posts: 280

Re: Model driven engineering

Post#6 » Wed Nov 30, 2011 7:08 pm

Allereerst denk ik dat het een goed idee is om bij het spreken over dit onderwerp een duidelijk onderscheid te maken tussen een model (oplossing v/h probleem) en een model (vereenvoudiging v/h probleem).

Vaak worden die twee gewoon door elkaar gebruikt en zijn we eigenlijk over niks aan het praten. In een dicussie over een model als Click, dan wil men dit al graag gaan vergelijken met een model als UML klasse-diagram.

Het eerste is een oplossing v/h probleem, en is dus altijd uitvoerbaar. Het tweede is een vereenvoudiging van het probleem, en is niet noodzakelijk uitvoerbaar. Gemakkelijkheidshalve zal ik het eerste model aanduiden als een probleemoplossend model, het laatste als een vereenvoudigend model.

Voorbeelden van probleemoplossende modellen zijn: C++, Java, Petri Nets, AGG, Click, ...
Voorbeelden van vereenvoudigende modellen zijn: UML klasse-diagrammen, een ecologisch model, een economisch model voor de verkoop van aandelen, een weermodel, ...

Het is misschien handig om probleemoplossende modellen in elkaar om te zetten. Dat is denk ik waar men nu mee bezig is. Of beter nog, ze samen naast elkaar te gebruiken.

Alleen kan men zich bij die probleemoplossende modellen nu de vraag gaan stellen. Welke modellen hebben we echt nodig? Wat is nu iets waar wij als programmeur te veel tijd in steken en dat eenvoudiger kan.

Graag zou ik van jullie het volgende weten. Welke modellen worden er gebruikt. En in welke specifieke situatie hebben ze hun nut. Hoe kunnen we deze modellen goed laten samenwerken?

User avatar
Fristi
WOZ
Posts: 4565

Re: Model driven engineering

Post#7 » Wed Nov 30, 2011 9:11 pm

Glenn wrote: Voorbeelden van probleemoplossende modellen zijn: C++, Java, Petri Nets, AGG, Click, ...
Voorbeelden van vereenvoudigende modellen zijn: UML klasse-diagrammen, een ecologisch model, een economisch model voor de verkoop van aandelen, een weermodel, ...
Hier gaat het dus mis. Petri nets zijn een vereenvoudigd model, dat kan nog makkelijk in te zien zijn. Maar c++ en Java zijn dat dus ook.

Je hebt een real life probleem, dit wil je gaan omzetten naar een programma. Meest basic is het in assembler te doen, wat op zich al een vereenvoudiging is. Daarboven heb je c++/java. Dat zijn op zich ook modellen. Je neemt namelijk iets echts, gaat het (maar misschien niet veel, das iets anders) vereenvoudigen en dan implementeren. Zo is ook click een vereenvoudigend model, namelijk voor routing systemen. Je abstraheert weg van een heel aantal zaken en je creëert zo de mogelijkheid om die dingen makkelijk te implementeren in c++ e.d.

Ze zijn dus volop bezig om dingen in elkaar om te zetten, al heeft dat niet altijd evenveel zin. Van statecharts naar Java/c++ is obviously nuttig. Tussen statecharts en petrinets transformeren, is ook handig. UML klasse diagrammen hebben wij moeten gebruiken om bijvoorbeeld het petri net formalisme te beschrijven. Het is dus een metamodel voor petri nets. In het petri net formalisme moeten we dan vervolgens ene model maken voor een kruispunt en een rond punt om analyse op uit te voeren.
Fristi Ad Infinitum

WINAK WOZ 2013 - ...
WINAK Magister Fristi 2012-2013
WINAK Feest 2011-2012
WINAK Schachtentemmer 2010-2011
WINAK Scriptor 2008-2009 | 2009-2010

Glenn
Posts: 280

Re: Model driven engineering

Post#8 » Thu Dec 01, 2011 6:04 pm

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:

Image

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!

Return to “Algemeen”

Who is online

Users browsing this forum: No registered users and 5 guests

cron