Categorie Archief UML

Mijn stijl van activity diagrams

Al vaak heb ik UML trainingen mogen geven. Waaronder ook de training Pragmatisch Modelleren op basis van het boek van Sander Hoogendoorn. Vele activity diagrams in verschillende kleuren, smaken en varianten heb ik langs zien komen . Van hele duidelijke diagrammen tot aan super ingewikkelde (maar wel helemaal volgens de UML regels)  diagrammen.

Ik vind het belangrijk dat men dezelfde soort diagrammen maakt. Het belangrijkste doel van zo’n diagram is namelijk de communicatie tussen de verschillende betrokkenen en een eenvoudig en eenduidig diagram helpt daar heel erg mee. De officiele UML regels staan toe om veel verschillende stijlen van modelleren toe te passen. De term ‘stijl’ gebruik ik vaak. Het geeft aan dat het niet goed of fout is om op andere manieren te modelleren. Toch vind ik het belangrijk dat de betrokkene zoveel mogelijk dezelfde stijl gebruiken. Dat verhoogd de leesbaarheid en eenduidigheid en maakt de communicatie dus makkelijker. Een leuke bijkomstigheid is dat hierdoor wellicht automatisch validaties van modellen eenvoudig wordt.

Een stijl is net zoals de stijl van kleding. Sommige stijlen passen je en sommige stijlen passen je niet. Het is waar je van houd. Voor het maken van activity diagrams gebruik ik zelf de onderstaande richtlijnen. Een deel van de richtlijnen is afkomstig van het boek Pragmatisch Modelleren met UML 2.0. Alle richtlijnen gebruik ik zelf in de praktijk.

Mijn richtlijnen

 

1. In een activity diagram gebruiken we alleen de volgende symbolen. We gebruiken géén andere symbolen.

  • Activity node – Een activity is de eenheid om het gedrag (stap) in een aktiviteiten diagram te modelleren.
  • Initial node – De flow start in een Initial node.
  • Final node – De flow eindigt in 1 of meerdere Final nodes
  • Decision node – Een decision node markeert een beslismoment. Er vindt dan een splitsing splitsing plaats in meerdere stromen.
  • Merge node – In een merge node komen verschillende stromen samen.
  • Loop node – Een loopnode modelleert een herhaald uitvoeren van een aantal activity nodes.
  • Fork/Join node – Fork en Join nodes worden gebruikt als eenheid om gelijktijdige (parallele) uitvoering van activity nodes te modelleren.
  • Control flow – Het modelleren van gedrag wordt gemodelleerd dmv de control flow tussen de verschillende nodes.

2. Plaats één enkele initial node in het activity diagram.

3. Modelleer een activity voor iedere stap in het stappenplan.

4. Modelleer één enkele transitie vanaf de initial node naar de eerste activity node.

5. Modelleer het gewenste scenario recht van boven naar beneden. Als je het gewenste scenario recht van boven naar beneden modelleert is het diagram makkelijker en sneller te begrijpen. Het gewenste doel zal dan altijd onderaan staan.

6. Geef ieder beslismoment in het activity diagram weer als een decision node. Geef de decision node geen naam.

7. Noteer guards bij de transities vanuit een decision node. Deze guards zijn volledig en sluiten elkaar uit.

8. Breng beslismomenten in het stappenplan die na elkaar dezelfde conditie testen samen in één enkele decision node in het activity diagram.

9. Maak gebruik van merge nodes. Laat dus nooit meerdere transities naar dezelfde activity lopen

10. Modelleer een herhaling in een stappenplan als een loop node in het activity diagram.

11. Sluit iedere herhaling aan op een merge node.

12. Doorbreek iedere herhaling met minimaal één decision node.

13. Formuleer een guard als een stelling met een onderwerp, werkwoord en zelfstandig naamwoord die met ja of nee beantwoord kan worden.

14. Geef een activity die een (sub function level) use case uitvoert de naam van deze use case. Voorzie de activity van het stereotype <<use case>>. Als je in de flow een ‘uitstap’ maakt naar een andere use case dan geeft ik de activity het stereotype <<use case>>. Als je ook nog automatisch de kleur kunt wijzigen in de modelleer tool dan kun is het direct zichtbaar.

15. Modeleer niet de annuleer flow. Het komt vaak voor dat bij een scherm een annuleer knop heeft. Als je wilt modelleren dat je op elke gewenst moment kunt annuleren kun je een spaghetti krijgen van lijnen. Ik modelleer deze flow nooit als je op elk moment in de flow kunt annuleren én dat er geen extra acties nog plaatsvinden na het drukken op de annuleer knop. Wel modelleer ik vaak een losse notitie om deze flow niet te vergeten.

Estimation and planning with smart use cases

Wat zijn smart use cases. Hoe kan kan ik er mee schatten en nog meer informatie. Deze presentatie heb ik gedaan tijdens het smart use cases event van Capgemini in 2008. De slides staan online!

Wil je meer weten over Smart use cases? Wat zijn de verschillen en overeenkomsten met user stories, gewone use cases? Hoe kun je slim en pragmatisch omgaan met specificaties in een agile werkwijze? Neem dan contact met mij op. Ik help je verder!

Time as an actor for scheduled use cases

TIMERIn an use case model the actor is someone or something outside the system that interacts with the system. An actor may be a person, a device, another system or sub-system. The actor is represented as a “stickman” icon.

So what should we do when we want a use case is automatically started on a certain moment? Probably started by some scheduling mechanism.

According to the definition of an actor we need to know if the scheduling mechanism is a part of the system or something outside the system. Is it part of the system then you don’t model a actor. Is it something outside the system you do model the actor (with the name of that scheduling system)

But when modeling use cases we don’t know or we don’t want to know about how the system is implemented. So it’s not clear if we need to model the actor.

I prefer that all user goal level use cases are always started by an actor. Then I can easily check of my model is complete: every use case needs to be associated with an actor or with another use cases. If not the use cases is useless and can be removed from your model.

My recommendation is always model a Time actor for scheduled use cases also when the scheduling is implemented inside the system. It makes your model clear and complete.