Gisteren heb ik op deze blog wat negatieve dingen over use cases gezet. Dat heeft elders, op een mailing list, wat discussie gebracht. Daarin werd opgemerkt dat use case eigenlijk een vervolgstap behoeven, namelijk een meer formele specificatie van het gedrag van het systeem. Inderdaad, enn daar zit dus het probleem: die formelere specs komen niet.
In die uitgebreidere specs zijn dan 3 onderdelen:
1. een formeler design voor de interactie met het systeem, maw: een soort
van formeel beschreven proces waaruit dan ook de specs van het syteem
interface voortvloeien.
Dit zou wel kunnen (met activity diagrams, BPMN of zoiets), maar wordt
voorzover ik weet zelden gedaan.
2. een design voor het UI. Soms wordt dit al in de uc's gedaan, soms
helemaal niet, en vaak klooit men men maar iets aan. Het zou ook fijn zijn
als er een formele taal voor beschikbaar was.
3. een echt systeemdesign voor de achterliggende functionaliteit, te
beginnen met een domeinmodel.
Dat kan heel goed, maar wordt, afgezien van een dattamodel, zelden gedaan.
Ik denk dat een probleem daarbij is dat uc's je op het verkeerde spoor
zetten. Bij uc's heb je een functiegerichte invalshoek. Dat is prima voor
een inventarisatie, maar voor de "binnenkant" van een systeme heb je daar
weinig aan. Maar de "draai" naar een coherent model is moeilijk, en wordt
dus zelden gemaakt.
En vooral in dat laatste zit dus de schadelijkheid van uc's: het is een
functionele benadering die haaks staat op meer samenhangende methoden voor
systeemontwerp, en stuurt de ontwikkeling dus precies de verkeerde kant
op.
Ik vind het zelf veel beter om eerst een domeinmodel te maken, en dan pas
te kijken naar wat men daar precies mee wil. Dat laatste kan dan eventueel
in de vorm van uc's.
Abonneren op:
Reacties posten (Atom)
Geen opmerkingen:
Een reactie posten