Domein modelleren is niet moeilijk

 
26 september 2008

Er wordt vaak erg ingewikkeld gedaan over domein modelleren. Het is echter minder moeilijk dan het lijkt. De belangrijkste fouten die ik vaak tegen kom zijn modelleren op basis van informatie en modelleren op basis van diep nadenken. Goed domein modelleren gebeurt echter op basis van gedrag en op basis van relevante observaties.

Domein modelleren op basis van informatie maakt modelleren lastig. Er is namelijk een oneindige hoeveelheid informatie. De Modelleur moet alle relevante informatie boven tafel krijgen. Dit kost veel tijd, moeite en inzicht. Het is meestal ook niet de essentie van de software. De essentie is het oplossen van het probleem. Een probleem oplossen is een gedrag.

Diep nadenken is een gevolg van onzekerheid. Op het moment dat het gedrag onbekend is moet er diep nagedacht worden over alle mogelijke informatie die eventueel nodig zou kunnen zijn. Compleetheid van het model wordt de meest belangrijke eigenschap. De diepte van de werkelijkheid is echter oneindig. Het is daarom belangrijk te modelleren op zichtbaarheid.

Bekijk eens een een voertuig reparatie werkplaats als voorbeeld. Er zijn auto’s en ze worden gerepareerd. Het gedrag is de reparatie van auto’s en we observeren reparaties en auto’s. Het model hiervoor zou dus worden: ‘auto repareer‘. Dat is alles. Meer is er voor ons model niet nodig. Domein modelleren wordt heel eenvoudig als je modelleert op gedrag en zichtbaarheid.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development

Tags: , ,


Reacties (8)

  • Ralf Wolter schreef:

    @Tom

    Vanwege de verwijzing naar gedrag kan ik me voorstellen dat je de gelijkenis trekt naar behaviorisme. Ik ben het daar minder mee eens omdat het gedrag dat we beschrijven in het domein model een ander gedrag is. Je beschrijft het in je stuk als:

    “Het enige zichtbare van een ’stuk software’ is z’n gedrag, en dus is het enige wat wij dienen te modelleren dat gedrag.”

    Dit is een uitspraak die geld voor behaviorisme omdat het doel is om een model voor het gedrag dat we gaan waarnemen. Voor domein modellering is gedrag belangrijk omdat gedrag het gene is waarmee we ons doel bereiken. Als ik korte zinsnede zou moeten neer zetten die dit weergeeft is het:

    “Software moet iets doen, daarom modelleren we gedrag.”

    Alle software die geschreven wordt heeft een specifiek doel. Dit doel is iets dat bereikt moeten worden. Dit impliceert een veranderende toestand en het veranderen van toestand is gedrag. Mijn kritiek hier is dat modelleurs vaak de nadruk leggen op de toestand. De nadruk zou juist moeten liggen op het veranderen.

    Dit zorgt er voor dat voor de muis ‘piep’ en ‘eten’ misschien zichtbaar zijn, maar niet noodzakelijk het doel. Een doel voor de muis is misschien meer overleven. Ik zou ‘muis overleef’ of misschien ‘muis leef’. Goal-driven zou misschien een betere term zijn.

    Geplaatst op 03 oktober 2008 om 15:15 Permalink

  • Jasper Floor schreef:

    Honger toestand is nog steeds niet nodig tenzij je beslissingen gaat nemen op basis van interne toestanden.

    Interne toestanden zijn echter gewoon niet interesant. Ze zijn niet direkt zichtbaar en met die constatering bestaan ze gewoon ook niet. Piep noem ik het honger signaal maar het intereseert me niet of de muis honger heeft. Natuurlijk wil ik van een auto wel weten waarom hij niet vooruit gaat, maar de toestand van de auto is dan niet onzichtbare informatie (of dat is juist de informatie die je zichtbaar moet maken). Voor gedrag van het systeem is het nauwelijks interesant. Ik wil een tuit vervangen. Maakt mij niet uit wat er mis is met het ruit, als ik vervang ruit signaal krijg dan ga ik dat doen. Of als een inventaris systeem moet ik mischieen een ruit bestellen.

    Waar het wat mij betreft op neer komt (en denk ik ook anderen) is dat je niet meer moet modeleren dan wat je nodig hebt.

    Geplaatst op 02 oktober 2008 om 10:44 Permalink

  • Tammo schreef:

    Hier lijkt mij het handigst om gewoon
    Piep => Eten
    te gebruiken. Totdat blijkt dat er ook daadwerkelijk situaties zijn waarbij het zinnig is om honger te modelleren. Maar de overstap op
    Piep => Honger, Honger => Eten
    pas te maken als die ook echt nodig is. Niet eerder.

    Hiermee ga ik nog even voorbij aan het filosofische vraagstuk of we muizen zijn of ze maken.

    Geplaatst op 01 oktober 2008 om 18:19 Permalink

  • Tom schreef:

    @Jasper

    Dat was niet helemaal wat ik ermee bedoelde te zeggen (toegegeven het is een beetje een brak voorbeeld). Het punt is dat Honger niet toelaatbaar is onder een strikte lezing van Ralphs advies dat “Goed domein modelleren gebeurt [echter] op basis van gedrag en op basis van relevante observaties.”

    Het feit (informatie) in ons model toelaten dat de muis honger heeft (of niet) maakt een model vele malen simpeler. De wereld op z’n smalst:

    Ik zeg modelleer de muis met:
    Piep => Honger, Honger => Eten

    Een strict behavioristisch Programma zegt:
    Piep => Eten

    In dit extreem simpele geval is het model met alleen gedrag misschien eenvoudiger en afdoende, maar voor een iets ingewikkeldere situatie is een informatie-toestand zeker handig, bijvoorbeeld wanneer er soms niet gevoerd dient te worden, en/of de muis z’n honger op meerdere manieren kan uiten.

    In het geval van domeinen als auto-werkplaatsen is het lastiger om de juiste tussenliggende toestanden te vinden, benoemen, en hanteren.

    Geplaatst op 01 oktober 2008 om 17:55 Permalink

  • Jasper Floor schreef:

    Ik vind je muis voorbeeld enigsinds naast de plank slaan. Is de muis een gebruiker van het systeem of is de muis het systeem dat we maken? In het eerste geval ben ik alleen geintereseerd in een honger event (“piep”). In het tweede geval wil maag leeg event met mischien nog een lage energie event…nou ja, gedrag van het lichaam. Muis heeft immers ook niet honger omdat hij energie nodig heeft. De muis heeft honger omdat er allemaal aparte dingen gebeuren die hem stimuleren om honger te hebben. Ga je die dan ook allemaal modeleren? Leuk voor je als je een muizen medisch informatie systeem gaat maken maar een muizen voer systeem wil toch alleen maar “piep” weten (niet te verwarren met “Piep!” of “piep?” natuurlijk ;)

    Je terzijde opmerking vind ik juist heel relevant. Je zegt namelijk een klasse van problemen op te lossen. Hoezo? Als je een kaartautomaat maakt moet je niet het probleem van alle kaartautomaten oplossen! Je hebt mischien veel mogelijkheden mbt kaartsoorten maar je moet niet een systeem maken die *en* vliegtuigtickets *en* treinkaartjes *en* bioscoop kaartjes enz. willen maken. Dan ben je waarschijnlijk te veel werk aan het doen.

    De kunst is juist om je model zo minimaal mogelijk te maken. Natuurlijk rekening houden met mogelijk uitbreiding in de toekomst maar daarbij moet je niet te ver gaan. De toekomst heeft namelijk de eigenschap onvoorspelbaar te zijn. Tenzij je Cassandra heet maar dan luister ik toch niet naar je.

    Geplaatst op 01 oktober 2008 om 17:12 Permalink

  • Tom schreef:

    Dit klinkt heel erg als een behavioristische benadering op software ontwikkeling.

    “Het enige zichtbare van een ‘stuk software’/’de menselijke psyche’ is z’n gedrag, en dus is het enige wat wij dienen te modelleren dat gedrag. De rest is onnodig en moeilijk-doenerij of, zelfs erger, leunstoel-filosofie.”

    Mocht je het eens zijn met de deze stro-man (van zowel jouw positie als het behaviorisme), dan is het de vraag of dit soort software ontwikkeling ook gevoelig is voor dezelfde zwakheden.

    Interne informatie, toestanden die niet direct zichtbaar zijn, zijn vaak van onschatbare waarde om gedragingen te verklaren. De muis eet de kaas niet op omdat hij (op T = -5 hard gerend heeft OF sinds T = -10 niet gegeten heeft OF …een ander extern waarneembaar gedrag vertoont OF etc), hij doet dat omdat hij in de interne toestand honger verkeert.

    De correcte identificatie van de relevante toestanden in een domein is dan helaas nog steeds het resultaat van (uiteraard) goed observeren, maar ook zeker veel ‘diep nadenken’.

    (Geheel terzijde laat ik dan nog dat software vaak niet een specifiek probleem oplost, maar juist een klasse van problemen, waarvan het moeilijk te besluiten is of dat nog ‘een gedrag’ is)

    Aan de positieve kant, aangezien we zoveel gewicht op het domein plaatsen in DDD, -mag- het ook best moeilijk zijn hoor!:)

    Geplaatst op 01 oktober 2008 om 14:00 Permalink

  • Ralf Wolter schreef:

    @Arjan

    Ik kan me je reactie goed voorstellen. Het is gebruikelijk om tijdens het modelleren je probleem te analyseren en diep uit te werken.

    Probleem daarbij is dat we tijdens het modelleren nog geen overzicht hebben om ons probleem daadwerkelijk op te lossen. Dit heeft tot gevolg dat tijdens het modelleren het zekere voor het onzekere genomen wordt en er een complex en groot model ontstaat.

    Wat ik poog te verwoorden in dit artikel is dat we juist niet verder moeten gaan. Het is geen oplossing van het probleem, maar een model van het probleem. Natuurlijk komt er later misschien meer bij, maar voor de initiële opzet is het compleet.

    De magie komt bij het implementeren van de repareer methode. Het is dan wel zo dat het implementeren gecombineerd gaan met een stukje modelleren. Maar ook dat gedeelte van modelleren wordt op basis van gedrag en zichtbaarheid.

    Geplaatst op 29 september 2008 om 11:15 Permalink

  • Arjan Keene schreef:

    Nou nou.
    Een klasse ‘Auto’ met een methode ‘Repareer’ lost het probleem op?
    Ik mis nog de delegate die de ‘.. and then something magic happens …’ uitbesteedt ;-)

    Geplaatst op 27 september 2008 om 13:08 Permalink