[Alg] Procesontwerp

[JKVA]

Momenteel ben ik mezelf aan het inlezen voor een project en daar kom ik een stukje ontwerp tegen (een proces in JBoss JBPM) waar ik mijn vraagtekens bij heb.

In een versimpelde vorm ziet het er als volgt uit: (ASCII art, kan hier geen plaatjes uppen )

code:

+-------------------------+
|          Klaar          |
+-------------------------+
     ^               ^
  Ok |               | Niet ok
     |               |
+-------------------------+
|          Bezig          |
+-------------------------+

Dergelijke constructies zie ik erg vaak in het ontwerp. Vanuit een bepaalde node zijn er meerdere transities naar steeds dezelfde andere node, ondanks dat de transities functioneel compleet verschillend zijn (zie voorbeeld met Ok en Niet-Ok).

Gevolg hiervan is dat in de transities (althans de handlers die je eraan knoopt) zeer veel logica komt. JBPM biedt daar support voor, dat is het probleem niet, maar volgens mij is het absoluut niet netjes als je transities meer zijn dan alleen een overgang van node A naar node B.

Ik begrijp dat er altijd uitzonderingsgevallen zijn waarin je logica in een transitie zet:

• Ten behoeve van je model in uitzonderingsgevallen,
• Of om je nodes generiek en dus herbruikbaar te maken,
• Of eventueel voor exotische problemen met je tooling ofzo,

maar om dit met grote regelmaat te doen lijkt me geen slim plan.

Ik weet het niet helemaal te plaatsen, maar het voelt niet lekker en ik voorzie op de een of andere manier problemen met overbodige complexiteit en herbruikbaarheid. Nodes zijn immers de perfecte koffertjes om te hergebruiken, transities (en de bijbehorende handlers) volgens mij niet, aangezien die een harde danwel zachte relatie hebben met de twee nodes waar ze tussen zitten.

Maar zoals misschien al uit de tekst blijkt, ik weet het niet helemaal zeker, dus graag jullie mening. Hoe gaan jullie met dergelijke situaties om en waarom?

[JKVA]

Kickje.

[H!GHGuY]

De persoon die dergelijke state charts schrijft mogen ze voor mijn part met de volgende lancering mee naar de maan zenden Je moet geen rocket-scientist zijn (hoezo woordspeling?) om te weten dat de meeste dingen bezig zijn ooit klaar zijn en dat ze (zeker in IT-land) ofwel OK ofwel NOK zijn.

Zonder natuurlijk meer context, lijkt me dit dus een slecht stukje design.
Beter zou imo zijn:

code:

[Idle]---Start--->[Busy]---Finish--->[OK]
                          +---Error--->[NOK, entry/error-dialog]

Deze approach is imo beter want:
- Je kan errors differentieren (Error1, Error2, Error3 met NOK1, NOK2, NOK3)
- Je kan NOK eventueel als tussenstap zien naar OK (hoewel die dan een andere naam moet krijgen zoals Finished)
- Je kan teruggaan naar de Idle staat (als je dit nodig hebt in je design)
Kortom, meer flexibiliteit.

Hier staat ook een mooi voorbeeld van hoe je wel acties kunt definieren in een state-chart:
http://www.agilemodeling.com/style/stateChartDiagram.htm

Met de uitleg die je geeft moet ik je gelijk geven.

[JKVA]

Dan denken wij er hetzelfde over. Uit het model blijkt dat OK en NOK hetzelfde resultaat opleveren, namelijk een overgang naar de eind state, maar als je de code ziet, zie je dat er stiekemweg toch wel iets gebeurt. Namelijk de code in de handlers.

Jouw suggestie is idd ook de manier die ik gewend ben qua modelleren.