Een collega vroeg me laatst eens te kijken naar een leerboek over "software-ontwikkeling". Het was een aardig boek, ongeveer langs de lijnen zoals die boeken tegenwoordig worden geschreven; vrij veel OO en UML, maar verder het nodige over architecturen (J2EE, Corba, etc), wat over UIs, wat over projectaanpak (RUPachtig), etc. Ik vind dat toch wel raar. Want Sw-ontwikkeling is een "proces" met heel veel totaal verschillende
activeiten en deelgebieden erin.
Van oudsher werd het grootste deel overzien door de 'analist-programmeur'. Die deed een soort halfwas IA, hij ontwierp het systeem in techische zin, en programmeerde ook vrijwel alle aspecten; het "echte" programma, detransactiehandling, de JCL, de files, het scherm als daarvan sprake was. En hij organiseerde ook zijn eigen "project".
Ik ben nog zo opgeleid, maar dat begon toen al een beetje onzin te worden. Iig dreven informatie-analyse en min of functioneel ontwerp weg van het meer technische deel. En dat wegdrijven is alleen maar verder gegaan. "Business modeling" is een aparte tak van sport geworden, "architectuur" ook. DBA is al lang apart. GUI-design wordt door specialisten gedaan, en het resultaat wordt weer door andere specialisten
gebouwd. Etc, etc.
Bovendien: als die activiteiten nog in 1 hand vallen, is dat een probleem, want het resultaat zal suboptimaal zijn. De Programmero Universalis is dood.
En dan hebben we het nog niet over allerhande projectaanpakken, met bijbehorende pseudo-specialismen (agile, RUP, spiral, etc, etc).De nieuwe ontwikkelingen (SOA, SaaS, MDA/E, offshoring/outsourcing, enz) versterken dat alleen maar.
Dat zo zijnde: wat heeft heeft het dan voor zin om een "allesomvattend" verhaal te schrijven over software-ontwikkeling? Of het als 1 onderwerp te doceren, for that matter?
Die leerboeken leggen dan ook sterk de nadruk op OO en UML, maar ze durven zich er niet toe te beperken. Maar wat doen al die verhalen over Corba, RMI, J2EE, er dan toe? Waarom geen Flex, of C#, of VB, of voor mijn part Cobol en CICS? En waarom een of andere RUP-variant, en niet AD? Waarom geen verhaal over SaaS en de consequenties
daarvan?
En door al die aandacht voor die zaken er omheen, zal het OO-design verhaal ook de kern missen, denk ik. Want de grap is natuurlijk dat je OO moet gebruiken als een platform- en aanpak-onafhankelijke "taal" geschikt voor analyse en design, meer niet.
Ik denk dat het niet veel zin heeft om software-ontwikkeling, met alle aspecten die daarbij horen (van requirements gathering tot versiebeheer, en van testen tot design patterns) als 1 discipline te beschouwen. Dat is het niet meer, en dat is maar goed ook. Nu de leerboeken nog.
maandag 30 juli 2007
Wat is software-ontwikkeling?
vrijdag 27 juli 2007
SaaSaaS (1)
Waarom heet deze blog SaaSaaS?
SaaS staat, zoals bekend, voor: Software as a Service. Software die door vele gebruikers als een service wordt aangeroepen, en waarbij de gebruiker dus niet meer de zorgen en de kosten van het beheer (zowel mbt hardware als mbt software) heeft, niet meer verantwoordelijk is voor het design, en eigenlijk alleen nog maar "aan het net" hoeft te zitten om te kunnen werken. Een prachtig toekomst-perspectief, zij het met een paar kanttekeningen (waarover verderop).
SaaSaaS staat voor Software as a Service as a Service. Want om de voordelen van SaaS te kunnen uitbuiten, en de nadelen te vermijden, moet er niet alleen een geschikte infrastructuur zijn (daarop focust men zich nu), maar moet ook de manier waarop IT georganiseerd is en gebruikt wordt veranderen.
Maar eerst de obstakels voor SaaS. Het belangrijkste obstakel is natuurlijk: legacy. Vrijwel alle bedrijven, van groot tot klein, gebruiken allang software, in ieder geval voor hun meest cruciale functies. Dat kan zelfgebouwde software zijn, het kan een pakket zijn, het kan brandnieuw zijn, het kan stokoud zijn. In al die gevallen is de combinatie met SaaS moeilijk. Want in die software zitten de voor het bedrijf specifieke "business rules" verpakt, en het gebruik van een externe service zal niet precies hetzelfde doen. En toch is dat wel de bedoeling. Natuurlijk, in theorie kan bestaande software gebruik maken van een externe service, of zelf als service beschikbaar worden gesteld. Maar dat is theorie. Technisch komen we er nog wel uit, maar op "logisch" niveau is het in de praktijk heel lastig. Want wat zijn eigenlijk die "business rules"? En waar moeten we dan de bestaande software "openknippen" om services te kunnen gebruiken of beschikbaar te stellen?
Een tweede obstakel voor SaaS wordt, merkwaardig genoeg, gevormd door een andere vrij nieuwe ontwikkeling: outsourcing en offshoring. Op het eerste gezicht is dat juist een ontwikkeling die hand in hand zou moeten gaan met SaaS, en tot op zekere hoogte is dat ook inderdaad het geval. Immers: door outsourcing zou het makkelijker moeten zijn om software tussen bedrijven te delen (bijvoorbeeld als service), en offshoring bestaat juist bij de gratie van het gebruik van het net. Dat spoort toch mooi met SaaS?
Ja, dat is wel zo, maar toch is er een probleem. Om iets aan SaaS te hebben, moet de bestaande software omgebouwd worden naar een voor SaaS geschikte opzet. Dat is al lastig als de software in eigen beheer is, maar als het beheer bij een andere partij ligt, wordt het nog moeilijker te organiseren. En als het een pakket is, ben je volkomen afhankelijk van de leverancier.
Er zijn nog twee risico's aan SaaS die aandacht behoeven.
Allereerst is daar het "glue-issue". De SaaS-services op zichzelf hebben meestal niet veel nut. Ze moeten aan elkaar worden gekoppeld, bijvoorbeeld in een user interface (bv een mashup) of een business process (bv een workflow geschreven in BPEL). Als de services perfect passen, is er niets aan de hand. Maar meestal zullen de services niet precies passen, en moet er extra "glue-code" worden geschreven om de services goed te laten samenwerken. De kans is groot dat daarin business-logica terecht zal komen (zeker bij proces-logica) en de kans is ook groot dat die logica redundant zal zijn, dwz: dezelfde logica komt op meer plaatsen in de code voor. Dit leidt al snel tot chaos, en inderdaad is de resulterende spaghetti-code ook al in SOA-trajecten te herkennen.
Een tweede punt is standaardisatie. Op "technisch" nivo is die in de SaaS- en SOA-wereld redelijk goed geregeld. Maar op "logisch" nivo nog niet. Als twee services met elkaar samenwerken en allebei de "Klant" gebruiken, is het wel van belang dat het begrip "Klant" voor beide services hetzelfde betekent. Conclusie: we hebben standaardisatie van begrippen (of concepten) nodig. Zonder dat zal Saas voor de business uitlopen op een babylonische spraakverwarring.
Wat we dus nodig hebben om de belofte van SaaS in te lossen, is in ieder geval een oplossing voor de integratie van legacy, voor het "glue-issue", en voor de standaardisering van begrippen.
Gelukkig zijn er in de IT altijd wel hypes en buzzwords die te hulp schieten: bijvoorbeeld MDA, MDE en Ontology. In een volgende post: hoe die samenwerken in SaaSaaS en waarom dat de geschetste problemen oplost.
SaaS staat, zoals bekend, voor: Software as a Service. Software die door vele gebruikers als een service wordt aangeroepen, en waarbij de gebruiker dus niet meer de zorgen en de kosten van het beheer (zowel mbt hardware als mbt software) heeft, niet meer verantwoordelijk is voor het design, en eigenlijk alleen nog maar "aan het net" hoeft te zitten om te kunnen werken. Een prachtig toekomst-perspectief, zij het met een paar kanttekeningen (waarover verderop).
SaaSaaS staat voor Software as a Service as a Service. Want om de voordelen van SaaS te kunnen uitbuiten, en de nadelen te vermijden, moet er niet alleen een geschikte infrastructuur zijn (daarop focust men zich nu), maar moet ook de manier waarop IT georganiseerd is en gebruikt wordt veranderen.
Maar eerst de obstakels voor SaaS. Het belangrijkste obstakel is natuurlijk: legacy. Vrijwel alle bedrijven, van groot tot klein, gebruiken allang software, in ieder geval voor hun meest cruciale functies. Dat kan zelfgebouwde software zijn, het kan een pakket zijn, het kan brandnieuw zijn, het kan stokoud zijn. In al die gevallen is de combinatie met SaaS moeilijk. Want in die software zitten de voor het bedrijf specifieke "business rules" verpakt, en het gebruik van een externe service zal niet precies hetzelfde doen. En toch is dat wel de bedoeling. Natuurlijk, in theorie kan bestaande software gebruik maken van een externe service, of zelf als service beschikbaar worden gesteld. Maar dat is theorie. Technisch komen we er nog wel uit, maar op "logisch" niveau is het in de praktijk heel lastig. Want wat zijn eigenlijk die "business rules"? En waar moeten we dan de bestaande software "openknippen" om services te kunnen gebruiken of beschikbaar te stellen?
Een tweede obstakel voor SaaS wordt, merkwaardig genoeg, gevormd door een andere vrij nieuwe ontwikkeling: outsourcing en offshoring. Op het eerste gezicht is dat juist een ontwikkeling die hand in hand zou moeten gaan met SaaS, en tot op zekere hoogte is dat ook inderdaad het geval. Immers: door outsourcing zou het makkelijker moeten zijn om software tussen bedrijven te delen (bijvoorbeeld als service), en offshoring bestaat juist bij de gratie van het gebruik van het net. Dat spoort toch mooi met SaaS?
Ja, dat is wel zo, maar toch is er een probleem. Om iets aan SaaS te hebben, moet de bestaande software omgebouwd worden naar een voor SaaS geschikte opzet. Dat is al lastig als de software in eigen beheer is, maar als het beheer bij een andere partij ligt, wordt het nog moeilijker te organiseren. En als het een pakket is, ben je volkomen afhankelijk van de leverancier.
Er zijn nog twee risico's aan SaaS die aandacht behoeven.
Allereerst is daar het "glue-issue". De SaaS-services op zichzelf hebben meestal niet veel nut. Ze moeten aan elkaar worden gekoppeld, bijvoorbeeld in een user interface (bv een mashup) of een business process (bv een workflow geschreven in BPEL). Als de services perfect passen, is er niets aan de hand. Maar meestal zullen de services niet precies passen, en moet er extra "glue-code" worden geschreven om de services goed te laten samenwerken. De kans is groot dat daarin business-logica terecht zal komen (zeker bij proces-logica) en de kans is ook groot dat die logica redundant zal zijn, dwz: dezelfde logica komt op meer plaatsen in de code voor. Dit leidt al snel tot chaos, en inderdaad is de resulterende spaghetti-code ook al in SOA-trajecten te herkennen.
Een tweede punt is standaardisatie. Op "technisch" nivo is die in de SaaS- en SOA-wereld redelijk goed geregeld. Maar op "logisch" nivo nog niet. Als twee services met elkaar samenwerken en allebei de "Klant" gebruiken, is het wel van belang dat het begrip "Klant" voor beide services hetzelfde betekent. Conclusie: we hebben standaardisatie van begrippen (of concepten) nodig. Zonder dat zal Saas voor de business uitlopen op een babylonische spraakverwarring.
Wat we dus nodig hebben om de belofte van SaaS in te lossen, is in ieder geval een oplossing voor de integratie van legacy, voor het "glue-issue", en voor de standaardisering van begrippen.
Gelukkig zijn er in de IT altijd wel hypes en buzzwords die te hulp schieten: bijvoorbeeld MDA, MDE en Ontology. In een volgende post: hoe die samenwerken in SaaSaaS en waarom dat de geschetste problemen oplost.
dinsdag 24 juli 2007
Dijkstra en Cobol
Elders schrijft Rik:
"Tja, het zijn allemaal bekende uitspraken van hem. De eerste die je hieronder noemt is ongetwijfeld bedoeld om het meest te shockeren. Enigszins vergelijkbaar met "goto statement considered harmful".
Ik denk overigens dat het ook zijn bedoeling was om te shockeren. Allerlei afgewogen meningen over talen of taalconstructies beklijven toch een stuk minder dan dit soort uitspraken."
En daarop heb ik geantwoord:
Natuurlijk was het zijn bedoeling om te shockeren. Maar als ie echt de boel op stelten had willen jagen, dan had ie moeten zeggen dat Cobol juist heel erg prima is, of zo. Dat was pas echt een provocatie geweest. Want dit was ook toen al zeer voorspelbaar. Dus het was niet alleen provocatie.
En er komt nog iets bij: het is duidelijk onzin. Waarom is die GOTO-uitspraak zo bekend geworden? Omdat ie weliswaar eenzijdig en overdreven, maar wel waar is. Dijkstra had een punt.
Maar wat betreft Cobol wist Dijkstra gewoon niet waar hij het over had. Er is een hoop mis met Cobol, maar het was toentertijd een doorbraak, de taal was stabiel en zeer goed bruikbaar, en de code was zelfs portable.
En als Dijkstra het beter wist, had ie zelf met iets zinnigers moeten komen, in plaats van dit soort kreten te slaken.
Maar erger is dat een hele generatie informatici het geroep van Dijkstra voor zoete koek hebben aangenomen, en kritiekloos dit soort kreten zat na te bauwen.
Ik heb menige verjaardag van mijn Geleerde Broer doorgebracht met het aanhoren van afgestudeerde of zelfs gepromovederde informatici die mij de les lazen over Cobol. Terwijl ze zelf de taal niet kenden. Maar Dijkstra had het gezegd dus was het waar.
Natuurlijk kun je Dijkstra daarvoor niet verantwoordelijk stellen, maar hij liet zich die rol van goeroe maar al te graag aanleunen. En hij voedde dat met dit soort gezwam.
Affijn, het is natuurlijk een Held van de Automatisering, maar niet mijn favoriet.
"Tja, het zijn allemaal bekende uitspraken van hem. De eerste die je hieronder noemt is ongetwijfeld bedoeld om het meest te shockeren. Enigszins vergelijkbaar met "goto statement considered harmful".
Ik denk overigens dat het ook zijn bedoeling was om te shockeren. Allerlei afgewogen meningen over talen of taalconstructies beklijven toch een stuk minder dan dit soort uitspraken."
En daarop heb ik geantwoord:
Natuurlijk was het zijn bedoeling om te shockeren. Maar als ie echt de boel op stelten had willen jagen, dan had ie moeten zeggen dat Cobol juist heel erg prima is, of zo. Dat was pas echt een provocatie geweest. Want dit was ook toen al zeer voorspelbaar. Dus het was niet alleen provocatie.
En er komt nog iets bij: het is duidelijk onzin. Waarom is die GOTO-uitspraak zo bekend geworden? Omdat ie weliswaar eenzijdig en overdreven, maar wel waar is. Dijkstra had een punt.
Maar wat betreft Cobol wist Dijkstra gewoon niet waar hij het over had. Er is een hoop mis met Cobol, maar het was toentertijd een doorbraak, de taal was stabiel en zeer goed bruikbaar, en de code was zelfs portable.
En als Dijkstra het beter wist, had ie zelf met iets zinnigers moeten komen, in plaats van dit soort kreten te slaken.
Maar erger is dat een hele generatie informatici het geroep van Dijkstra voor zoete koek hebben aangenomen, en kritiekloos dit soort kreten zat na te bauwen.
Ik heb menige verjaardag van mijn Geleerde Broer doorgebracht met het aanhoren van afgestudeerde of zelfs gepromovederde informatici die mij de les lazen over Cobol. Terwijl ze zelf de taal niet kenden. Maar Dijkstra had het gezegd dus was het waar.
Natuurlijk kun je Dijkstra daarvoor niet verantwoordelijk stellen, maar hij liet zich die rol van goeroe maar al te graag aanleunen. En hij voedde dat met dit soort gezwam.
Affijn, het is natuurlijk een Held van de Automatisering, maar niet mijn favoriet.
maandag 23 juli 2007
Genuezel uit Nuenen
Een oude tirade van Dijkstra, o.m. over Cobol. Blijkbaar dacht Dijkstra dat ie een kruising was tussen WF Hermans en Ludwig Wittgenstein.
Over Cobol:
"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence."
En de rest is navenant.
Over Cobol:
"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence."
En de rest is navenant.
Het nut van archetypes
Ik ben inmiddels begonnen met een onderzoek naar aanpakken van (business-) analyse met behulp van archetypes (zeer abstracte analyse-patronen die in varianten elk business-domein beschrijven.
Ik kijk daarbij naar iig 3 aanpakken:
- de REA aanpak (Resources, Events, Agents)
- de "colors" aanpak van Peter Coad c.s.
- de Archetype-aanpak van (o.m.) Arlow en Neustadt.
Bij alle drie moet de "aanpak" ruim worden opgevat. Arlow en Neustadt bv bouwen voort op al bekende analysis patterns, en van zowel de colors- als de REA-aanpak bestaan verscheidene varianten en afgeleiden. Die zullen worden meegenomen, voorzover nuttig en mogeljk.
Ik ga iig naar de volgende criteria kijken:
1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
2. is de aanpak bruikbaar in een MDE-traject?
3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?
4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?
5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?
Ik ben benieuwd...
Ik kijk daarbij naar iig 3 aanpakken:
- de REA aanpak (Resources, Events, Agents)
- de "colors" aanpak van Peter Coad c.s.
- de Archetype-aanpak van (o.m.) Arlow en Neustadt.
Bij alle drie moet de "aanpak" ruim worden opgevat. Arlow en Neustadt bv bouwen voort op al bekende analysis patterns, en van zowel de colors- als de REA-aanpak bestaan verscheidene varianten en afgeleiden. Die zullen worden meegenomen, voorzover nuttig en mogeljk.
Ik ga iig naar de volgende criteria kijken:
1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
2. is de aanpak bruikbaar in een MDE-traject?
3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?
4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?
5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?
Ik ben benieuwd...
vrijdag 20 juli 2007
Michael Jackson
Ik zit wat te graven naar ontwerp-methodes waarmee legacy gebouwd is. En ik kom van de voortreffelijke Michael Jackson naast zijn bekende en onvolprezen JSP (Jackson Strucured Programming) ook JSD (Jackson System Development) tegen.
Dat kende ik niet, en het is wel een interessant verhaal.
Zo te zien van huis uit functie-oriented, maar wel met een interessante groepering van functies die op zelfde object (entity) betrekking hebben. Daarnaast een modellering van de relaties tussen (resultaat van) die functies. Ik kan geen modellering van de relaties tussen die entities vinden. Er zit, lijkt het, dus geen data modeling in. Maar wel weer een ordening van de Actions op een Entity, en dat klint als een soort state machine.
Soort OO zonder O, lijkt het. Uit 1982.
Dat kende ik niet, en het is wel een interessant verhaal.
Zo te zien van huis uit functie-oriented, maar wel met een interessante groepering van functies die op zelfde object (entity) betrekking hebben. Daarnaast een modellering van de relaties tussen (resultaat van) die functies. Ik kan geen modellering van de relaties tussen die entities vinden. Er zit, lijkt het, dus geen data modeling in. Maar wel weer een ordening van de Actions op een Entity, en dat klint als een soort state machine.
Soort OO zonder O, lijkt het. Uit 1982.
donderdag 19 juli 2007
De consultant en de dominee
Kort geleden sprak ik een consultant van een ander bedrijf. Hij was specialist voor een bepaalde werkwijze voor requirements beheer en het bijbehorende tool. Een verstandige man, wist waarover hij het had.
Hij vertelde dat eigenlijk alleen met een klant aan de gang wilde, als men echt "geloofde"in de aanpak. Ook moest er "totaal commitment" zijn van het management, vooral ook van het topmanagement.
Je hoort dat wel vaker, en eigenlijk is dat nogal vreemd. Het is logisch dat je verwacht dat een bedrijf het noodzakelijke doet om een bepaalde aanpak te laten slagen: tool kopen, cursussen, relevante expertise inhuren, etc. Maar waarom moet je erin geloven? Wat is dat toch met die "totale commitment"?
Het lijkt wel een sekte. En als je nou een heel esoterisch produkt verkoopt, met erg veel verhaal, en erg weinig praktisch nut, ja, dan kan ik me deze Johan-Maasbach-benadering voorstellen.
Maar in dit geval ging het om iets wat duidelijk nut heeft, en bewezen kan werken. Ik zou zeggen: verkoop het, doe het, en laat het zichzelf bewijzen.
Waarom dat toch die nadruk op totale overgave? Zou het komen doordat veel IT-consultants eigenlijk gemankeerde dominees of missionarissen zijn?
Hij vertelde dat eigenlijk alleen met een klant aan de gang wilde, als men echt "geloofde"in de aanpak. Ook moest er "totaal commitment" zijn van het management, vooral ook van het topmanagement.
Je hoort dat wel vaker, en eigenlijk is dat nogal vreemd. Het is logisch dat je verwacht dat een bedrijf het noodzakelijke doet om een bepaalde aanpak te laten slagen: tool kopen, cursussen, relevante expertise inhuren, etc. Maar waarom moet je erin geloven? Wat is dat toch met die "totale commitment"?
Het lijkt wel een sekte. En als je nou een heel esoterisch produkt verkoopt, met erg veel verhaal, en erg weinig praktisch nut, ja, dan kan ik me deze Johan-Maasbach-benadering voorstellen.
Maar in dit geval ging het om iets wat duidelijk nut heeft, en bewezen kan werken. Ik zou zeggen: verkoop het, doe het, en laat het zichzelf bewijzen.
Waarom dat toch die nadruk op totale overgave? Zou het komen doordat veel IT-consultants eigenlijk gemankeerde dominees of missionarissen zijn?
use cases considered harmful (3)
Na wat googlen zie ik dat er eerder al vele anderen op het idee van deze titel zijn gekomen. Onder hen de voortreffelijke Peter Coad.
dinsdag 17 juli 2007
Use cases considered harmful (2)
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.
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.
maandag 16 juli 2007
use cases considered harmful
De titel is een grapje. Use cases zijn wel degelijk nuttige instrumenten bij de specificatie van systemen. Tenminste: als ze op de goede manier worden gebruikt. Dus zonder teveel details, zonder beschrijving van het UI, en toegespitst op wat het resultaat van een actie van het systeem moet zijn. En de use case moet vooral niet beschrijven hoe een resultaat bereikt wordt, maw: hoe het systeem moet werken.
In de overgrote meerderheid van de gevallen gaan de use cases ver buiten de grenzen die hierboven zijn beschreven. En dan komen er problemen, want een (gedetailleerde) beschrijving van de werking, de binnenkant, van een systeem vereist een formele taal. Use cases zijn niet formeel. En als UI beschrijvingen worden opgenomen, dan moeten use cases worden gewijzigd als het UI wijzigt. Dat is niet te doen, want UIs zijn zoals bekend erg veranderlijk.
Goed, use cases moeten goed worden gebruikt (ja natuurlijk), en als het toch mis gaat, ligt dat aan degenen die use cases toepassen. Of niet?
Ik denk dat use cases als techniek een paar ingebouwde problemen heeft, en dat die bijdragen aan het wijdverbreide misbruik.
Allereerst: use cases maken deel uit van UML. Dat heeft tot gevolg gehad dat use cases allerwege werden gezien als NIEUW! en MODERN! en vooral ook: OBJECT-GEORIENTEERD! En men verwachtte ook dat de daaraan verbonden (veronderstelde) voordelen zich bij gebruik van use cases als vanzelf zouden manifesteren. Dat is niet gebeurd. Niet alleen omdat die voordelen nooit vanzelf komen, maar ook omdat use cases niets meer zijn dan in een nieuw jasje gestoken functionele ontwerpen. Beter gestrctureerd, enigszins gestandaardiseerd, een leuk diagrammetje waar je niks aan hebt er bij, jazeker, maar eigenlijk gewoon oude wijn in nieuwe zakken. Op zichzelf was er met die oude wijn niet zoveel mis, maar de verwachtingen waren hoger gespannen. En die komen niet uit, want use cases leiden niet tot een betere of een andere wijze van systeemontwikkeling. Dat verklaart waarschijnlijk ook hun populariteit: je hoeft er niks nieuws voor te leren.
Verder: use cases worden gepresenteerd als HET middel voor requirementsanalyse. Dat is onjuist. Voor hoog niveau requirements zijn use cases eigenlijk een niveau "te diep": je kunt pas use cases schrijven als je weet welke processen er zijn, wanneer die processen met het systeem interageren, en wat het resultaat van die interacties moet zijn. En voor het "in kaart brengen" van het business-domein zijn use cases ongeschikt. Daarvoor is een class-model (in UML) een veel beter middel. Maar in de gangbare projectopzet komt een class-model pas na de use cases (als het al komt, want meestal zit het project in de use cse trap, waarover zo dadelijk meer). Use cases worden dus vaak ingezet voor het verkeerde doel.
Tenslotte: use cases komen altijd vergezeld van een preek over hoe ze te gebruiken, en vooral hoe ze niet te gebruiken (zoiets als in de eerste alinea van deze past, maar dan veel langer). En die preken zijn nodig, want het is veel te makkelijk om ze verkeerd toe te passen. Dat komt doordat use cases volledig informeel zijn. Hoe je specificeert, wat de vereiste mate van detail is, het is allemaal open. De hoogste vorm van formalisatie is: een Word-template. Tsja. Fouten maken is dus veel te makkelijk.
Goed, use cases sluiten dus niet goed aan bij (moderne) methoden voor systeemontwikkeling, use cases worden verkeerd ingezet, en use cases zijn veel te informeel. Toch (of juist daardoor) zijn ze populair. De populariteit van use cases heeft ervoor gezorgd dat menig project in de use case trap terecht is gekomen. Hoe werkt de use case trap?
Een voorbeeld. Er moet een nieuw order entry systeem worden gebouwd, en dat moet op een bepaalde datum klaar zijn. Allereerst moet er een inventarisatie van de requirements komen. Daarvoor zetten we use cases in. Die zijn vreselijk onhandig daarvoor, want je moet dan gelijk de interacties van het systeem met de buitenwereld beschrijven, hoewel we nog helemaal weten niet of er wel een systeem moet komen! En veel requirements zullen in verscheidene use cases worden beschreven. Dat is dubbel werk. Maar niet getreurd, we huren een stelletje consultants in.
Bovendien heeft men geen goed zicht op het probleemdomein, dus worden allerlei wetenswaardigheden over het domein in de use cases opgeschreven, bijvoorbeeld dat een order tenmnste een en maximaal tien orderregels bevat. Die zijn daarvoor ongeschikt. En omdat men nu toch zo fijn met de gebruiker aan de gang is, wordt het UI ook gelijk maar even beschreven in de use cases.
Allemaal heel begrijpelijk, maar het gevolg is dat we al heel snel door de bomen het bos niet meer zien, en de tijd die in het projectplan was gereserveerd voor de use cases wordt ruimschoots overschreden. Maar we gaan toch maar door, want je moet toch beschrijven wat je nodig hebt? Maar op een gegeven moment is de einddatum van het hele project nog maar 4 maanden verwijderd. Moet er nou toch niet eens worden gebouwd?
Ja, eigenlijk wel. Gelukkig herinnert een consultant zich dat use cases eigenlijk helemaal niet zo gedetailleerd moeten zijn, dus kunnen we nu best stoppen. (Dat had ie wel eens eerder mogen zeggen.) De bouwers krijgen de stapel met use cases toegeworpen, en mogen op basis daarvan aan de gang gaan. Voor domein analyse is geen tijd meer, voor een goed ontwerp ook niet. Er moet geklopt worden!
Affijn, de bekende ellende dus. En een deel daarvan wordt veroorzaakt door de (verkeerde) toepassing van de use cases. Maar dat ligt niet alleen aan ons, ook wel een beetje aan de use case techniek zelf.
Misschien is die titel toch niet alleen maar een grapje...
In de overgrote meerderheid van de gevallen gaan de use cases ver buiten de grenzen die hierboven zijn beschreven. En dan komen er problemen, want een (gedetailleerde) beschrijving van de werking, de binnenkant, van een systeem vereist een formele taal. Use cases zijn niet formeel. En als UI beschrijvingen worden opgenomen, dan moeten use cases worden gewijzigd als het UI wijzigt. Dat is niet te doen, want UIs zijn zoals bekend erg veranderlijk.
Goed, use cases moeten goed worden gebruikt (ja natuurlijk), en als het toch mis gaat, ligt dat aan degenen die use cases toepassen. Of niet?
Ik denk dat use cases als techniek een paar ingebouwde problemen heeft, en dat die bijdragen aan het wijdverbreide misbruik.
Allereerst: use cases maken deel uit van UML. Dat heeft tot gevolg gehad dat use cases allerwege werden gezien als NIEUW! en MODERN! en vooral ook: OBJECT-GEORIENTEERD! En men verwachtte ook dat de daaraan verbonden (veronderstelde) voordelen zich bij gebruik van use cases als vanzelf zouden manifesteren. Dat is niet gebeurd. Niet alleen omdat die voordelen nooit vanzelf komen, maar ook omdat use cases niets meer zijn dan in een nieuw jasje gestoken functionele ontwerpen. Beter gestrctureerd, enigszins gestandaardiseerd, een leuk diagrammetje waar je niks aan hebt er bij, jazeker, maar eigenlijk gewoon oude wijn in nieuwe zakken. Op zichzelf was er met die oude wijn niet zoveel mis, maar de verwachtingen waren hoger gespannen. En die komen niet uit, want use cases leiden niet tot een betere of een andere wijze van systeemontwikkeling. Dat verklaart waarschijnlijk ook hun populariteit: je hoeft er niks nieuws voor te leren.
Verder: use cases worden gepresenteerd als HET middel voor requirementsanalyse. Dat is onjuist. Voor hoog niveau requirements zijn use cases eigenlijk een niveau "te diep": je kunt pas use cases schrijven als je weet welke processen er zijn, wanneer die processen met het systeem interageren, en wat het resultaat van die interacties moet zijn. En voor het "in kaart brengen" van het business-domein zijn use cases ongeschikt. Daarvoor is een class-model (in UML) een veel beter middel. Maar in de gangbare projectopzet komt een class-model pas na de use cases (als het al komt, want meestal zit het project in de use cse trap, waarover zo dadelijk meer). Use cases worden dus vaak ingezet voor het verkeerde doel.
Tenslotte: use cases komen altijd vergezeld van een preek over hoe ze te gebruiken, en vooral hoe ze niet te gebruiken (zoiets als in de eerste alinea van deze past, maar dan veel langer). En die preken zijn nodig, want het is veel te makkelijk om ze verkeerd toe te passen. Dat komt doordat use cases volledig informeel zijn. Hoe je specificeert, wat de vereiste mate van detail is, het is allemaal open. De hoogste vorm van formalisatie is: een Word-template. Tsja. Fouten maken is dus veel te makkelijk.
Goed, use cases sluiten dus niet goed aan bij (moderne) methoden voor systeemontwikkeling, use cases worden verkeerd ingezet, en use cases zijn veel te informeel. Toch (of juist daardoor) zijn ze populair. De populariteit van use cases heeft ervoor gezorgd dat menig project in de use case trap terecht is gekomen. Hoe werkt de use case trap?
Een voorbeeld. Er moet een nieuw order entry systeem worden gebouwd, en dat moet op een bepaalde datum klaar zijn. Allereerst moet er een inventarisatie van de requirements komen. Daarvoor zetten we use cases in. Die zijn vreselijk onhandig daarvoor, want je moet dan gelijk de interacties van het systeem met de buitenwereld beschrijven, hoewel we nog helemaal weten niet of er wel een systeem moet komen! En veel requirements zullen in verscheidene use cases worden beschreven. Dat is dubbel werk. Maar niet getreurd, we huren een stelletje consultants in.
Bovendien heeft men geen goed zicht op het probleemdomein, dus worden allerlei wetenswaardigheden over het domein in de use cases opgeschreven, bijvoorbeeld dat een order tenmnste een en maximaal tien orderregels bevat. Die zijn daarvoor ongeschikt. En omdat men nu toch zo fijn met de gebruiker aan de gang is, wordt het UI ook gelijk maar even beschreven in de use cases.
Allemaal heel begrijpelijk, maar het gevolg is dat we al heel snel door de bomen het bos niet meer zien, en de tijd die in het projectplan was gereserveerd voor de use cases wordt ruimschoots overschreden. Maar we gaan toch maar door, want je moet toch beschrijven wat je nodig hebt? Maar op een gegeven moment is de einddatum van het hele project nog maar 4 maanden verwijderd. Moet er nou toch niet eens worden gebouwd?
Ja, eigenlijk wel. Gelukkig herinnert een consultant zich dat use cases eigenlijk helemaal niet zo gedetailleerd moeten zijn, dus kunnen we nu best stoppen. (Dat had ie wel eens eerder mogen zeggen.) De bouwers krijgen de stapel met use cases toegeworpen, en mogen op basis daarvan aan de gang gaan. Voor domein analyse is geen tijd meer, voor een goed ontwerp ook niet. Er moet geklopt worden!
Affijn, de bekende ellende dus. En een deel daarvan wordt veroorzaakt door de (verkeerde) toepassing van de use cases. Maar dat ligt niet alleen aan ons, ook wel een beetje aan de use case techniek zelf.
Misschien is die titel toch niet alleen maar een grapje...
URL gewijzigd
Zo, ik heb de URL (sasmde.blogspot.com) gewijzigd naar saasaas.blogspot.com
Want dat is eigenlijk wat ik wil: het beheer van software (bijvoorbeeld Saas) aanbieden als een service.
Want dat is eigenlijk wat ik wil: het beheer van software (bijvoorbeeld Saas) aanbieden als een service.
vrijdag 13 juli 2007
vrijdag 6 juli 2007
donderdag 5 juli 2007
Semantics
David Frankel vindt dat er semantische interoperabiliteit moet komen, om de belofte van SOA's te realiseren.
En gelijk heeft ie. Hij vestigt de aandacht op allerhande initiatieven om te komen tot gedeelde emantische definities. Dat is inderdaad heel waardevol. Daarnaast (voeg ik er aan toe) heeft het ook zin voor een bedrijf om vanuit een abstract business-model te werken. Daarin wordt beschreven wat de semantiek van de gegevens is, en de mapping op feitelijke datastructuren kan dan eenvoudig plaatsvinden. het is niet meer nodig (zoals nu vaak het geval is) om tussen de feitelijke datastructuren mappings te ontwikkelen. Immers, die kunnen worden afgeleid uit de mappings op het abstracte model.
En gelijk heeft ie. Hij vestigt de aandacht op allerhande initiatieven om te komen tot gedeelde emantische definities. Dat is inderdaad heel waardevol. Daarnaast (voeg ik er aan toe) heeft het ook zin voor een bedrijf om vanuit een abstract business-model te werken. Daarin wordt beschreven wat de semantiek van de gegevens is, en de mapping op feitelijke datastructuren kan dan eenvoudig plaatsvinden. het is niet meer nodig (zoals nu vaak het geval is) om tussen de feitelijke datastructuren mappings te ontwikkelen. Immers, die kunnen worden afgeleid uit de mappings op het abstracte model.
Abonneren op:
Posts (Atom)