Literate modeling

Een zijspoor van het onderzoek naar archetypes: literate modeling. Het is een techniek waarbij modellen worden "uitgelegd" voor "stakeholders" die ze anders niet begrijpen.

Arlow en Neustadt introduceren dit begrip in hun boek, en op codegeneration vat Jim Arlow de voordelen als volgt samen:

1. The UML model tends to be more correct. It’s amazing how often we have taken a "correct" UML model and discovered semantic errors in it when we came to explain it to ourselves by writing the narrative.
2. You get an improvement in quality. This arises because the non-technical stakeholders gain the ability to assess and critique the model.
3. You get better requirements traceability. High-level requirements often become lost in UML models. We call this the "trivialization of requirements" in our paper. The narrative must highlight key requirements and illustrate how the UML model realizes these.
4. You increase the business benefit of your UML models by making these models accessible to a much wider audience.

Duidelijk verhaal, prima verhaal. Ik geloof dat ik zelf iets dergelijks ook al doe. Dus dan is get goed. :)

De voordelen die Arlow noemt zijn er ook inderdaad, en het zijn echte voordelen.

Maar heb ik een twijfel.

De suggestie is dat dit soort modellen (het gaat om modellen voor de analyse) bedoeld zijn voor afstemming met "stakeholders", of zelfs dat die modellen eerst moeten zijn goedgekeurd door de "stakeholders".

Volgens mij is dat allebei niet waar. Het doel van modellen is het specificeren van een systeem, en de uiteindelijke toets voor de correctheid is of er een goed werkend systeem, met de juiste vrijheidsgraden, etc mee tot stand komt.

Of de "stakeholders" de modellen "herkennen" of begrijpen, is eigenlijk niet relevant. Natuurlijk, als de domeinanalist het domein probeert te begrijpen, is het handig om de modellen die hij heeft gemaakt af te stemmen, en in dat kader is literate modeling zeker nuttig.

Maar de uiteindelijk verantwoordelijke is de analist, en de mening van de "business" over die modellen op zichzelf is strikt genomen niet relevant.

Archetypes (vv)

Ruim twee weken geleden kondigde ik aan te gaan onderzoeken wat het nut is van archetypes, en die te gaan beoordelen op de volgende criteria:
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)?
En daar kwam later bij:
6. leent de aanpak zich voor een koppeling met aspect-orientatie (tbv symmetrische en asymmetrische aspecten of deelmodellen)?

De onderzochte aanpakken zijn:
- de REA aanpak (Resources, Events, Agents), in de variant van Pavel Hruby c.s.
- de "colors" aanpak van Peter Coad c.s.
- de Archetype-aanpak (pleomorphs) van (o.m.) Arlow en Neustadt.

Ik ben nog lang niet klaar, maar dit is de eerste inventarisatie.

Ad 1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
- REA: ja. Daar is de aanpak bij uitstek voor bedoeld. Het gehanteerde metamodel (REA, duality, conversion process, etc) is ook expliciet uit de abstractie van business-domeinen ontleend (mn uit accounting). De aanpak is compleet: elk business-domein wordt in principe volledig bestreken, zij het dat soms wat kunstgrepen nodig zijn. REA is ook alleen maar voor business-domeinen geschikt.

- colors: ja. De Domain Neutral Component (PPT, Role, Description, Moment/Interval) is een zeer abstract model, en eigenlijk een metamodel dat overal (niet alleen voor business-analyse) kan worden toegepast. Maar er zijn specialisaties mogelijk voor business-analyse, en Coad c.s. geven daarvan ook voorbeelden. De aanpak is compleet: elk business-domein wordt volledig bestreken.

- pleomorphs: ja. De aanpak biedt een set aan (samenhangende) analyse-patronen, die uitstekend geschikt zijn om een business-analyse te doen. Of elk business-domein compleet wordt afgedekt, betwijfel ik.

Ad 2. is de aanpak bruikbaar in een MDE-traject?

- REA: ja, mits verder uitgewerkt. Er zijn iig aanzetten voor MDA/MDE-achtige zaken, maar er zal wel nog het nodige meoten worden gedaan om eea te laten werken. Nadeel is wel dat de REA-aanpak niet uit de hoek van de software-ontwikkeling komt, waardoor de mapping van REA-concepten op bv componenten of classes nog wel eens lastig kan zijn (zie bijvoorbeeld het ontbreken van een Role).

- colors: ja, mits doorontwikkeld. Deze aanpak stamt van voor de MDA-hype, en dus zitten er geen expliciete aangrijpingspunten voor MDA of MDE in. Echter, de aanpak zit zo strak in elkaar als het gaat om de afleiding van modellen dat dit geen groot probleem zal zijn. (opvallend in dit verband is dat Coad c.s. de term "metamodel" niet gebruiken voor hun abstracte patronen, hoewel ze wel bij uitstek zo te gebruiken zijn).

- pleomorphs: ja. Is expliciet opgenomen, en er worden zelfs voorbeelden gegeven met ArcStyler als tool.

Ad 3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?

- REA: waarschijnlijk wel. Echter, de mapping van analyse concepten naar services is nog niet triviaal, mede omdat een REA-model puur op het punt van bv object-orientatie (cohesie interfaces, etc) nog niet helemaal klaar is.

- colors: ja. Weliswaar zitten services etc. niet in de aanpak, maar dankzij de strak uitgewerkte interfaces, de keurig aansluitende domein-concepten en vooral de roles die al in het model als koppeling optreden, is een mapping op een SOA niet moeilijk.

- pleomorhs: waarschijnlijk wel. Deze aanpak resulteert in goede OO-modellen, waaruit services normaliter makkelijk af te leiden zijn.

Ad 4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?

- REA: ja. Ik voorzie geen problemen.

- colors: ja.

- pleomorphs: ja, is er zelfs specifiek op gericht (compleet met voorwoord van de onvermijdelijke Richard Mark Soley, Ph.D.)

Ad 5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?

- REA: zeer twijfelachtig. REA is goed in het adhv de business analyseren van die business, maar is niet gericht op software. Ik betwijfel of dit werkt, al zullen proeven dat moeten uitwijzen.

- colors: ja, uitstekend. De top-down benadering helpt ook bij zeer rommelig in elkaar zittende legacy-software. Colors is eigenlijk een soort patroon-taal, en dat is hier een groot voordeel.

- pleomorphs: ja. Het opzoeken van de patronen is goed mogelijk, maar ze moeten wel al zichtbaar zijn.

Ad 6. leent de aanpak zich voor een koppeling met aspect-orientatie (tbv symmetrische en asymmetrische aspecten of deelmodellen)?

- REA: redelijk. REA gebruikt expliciet AO voor bepaalde vormen van gedrag (asymmetrische aspecten vooral). Om het echt in een MDE-aanpak te laten werken is nog wel wat werk nodig, maar het begin is er.

- colors: redelijk. Aspecten zitten er niet expliciet in, maar de aanpak (weer dankzij de roles) leent zich er goed voor. Om het in een MDE-aanpak te laten werken is nog wel werk nodig.

- pleomorphs: matig. Voorzover ik kan overzien is er geen rekening mee gehouden. Aan de andere kant; het zijn wel OO-modellen, dus het is er in te breien. Maar er zal meer werk voor nodig zijn dan bij colors.

Zo, dit is de eerste inventarisatie. Het is duidelijk: er is nog veel uit te zoeken. En er is ook nog veel meer te zeggen van deze aanpakken, de voor- en nadelen, enzovoort. Dat zal allemaal gebeuren.

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...