Schrijvers archief Robert

Search query Enterprise Architect for searching element by Id

One of the hidden features of the EAValidator is copying the EA Id into the clipboard. When you double-click on a validationerror in Id of the element is copied into to clipboard.

In Enterprise Architect you can easily search for the element by creating a new search (only once) with the following query:

SELECT
ea_guid AS CLASSGUID, Object_Type AS CLASSTYPE,Name AS Object, Object_Type AS [Type], Stereotype, CreatedDate, ModifiedDate
FROM
t_object
WHERE
ea_guid = '<Search Term>'

Search Find by Id

What every Product Owner should know

When I’m participating in an agile team or when I’m doing some agile coaching stuff I often have conversations with the product owner about roles, activities and expectations of his/her job? And during this conversation I advice to read the ‘Product Owner Manual’ from ScrumSense. I don’t think every product owner can or will agree to this manual but it is the first home work I’ll advice.

Product-Owners-Manual

More info: http://www.scrumsense.com/resources/product-owner-manual/

How to split a user story (or slice or use case story or ..)

I found a nice flowchart for splitting a user story. Naturally the same flowchart is applicable for slices or use case stories if you are using Use Case 2.0 techniques.

For more info: http://www.agileforall.com/splitting-user-stories/

 

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.

Nieuw EAValidator

 

validation-protocol-execution-tipsMaak jij weleens fouten bij het modelleren in Enterprise Architect? Ben je weleens vergeten om elementen uit je projectbrowser te verwijderen als je het element hebt verwijderd van je diagram? Ben je ooit eens vergeten om een omschrijving vast te leggen bij je use case?

Ik wel! En ik merkte dat, met al de ‘vergeten’ dingen, het Enterprise Architect model steeds minder betrouwbaar werd als single-source-of-truth. Geïnspireerd door de code analyse mechanisme van Microsoft Visual Studio. Heb ik de tool EAValidator ontwikkeld. EAValidator valideert uw model tegen uw eigen validatieregels en informeert u onmiddellijk over fouten in uw model. De EAValidator zal niet voorkomen dat u fouten maakt. De visie van bij de EAValidator is om niet te beperken maar wel snel te signaleren! Je zult dus heel snel je fouten zien zodat je deze ook snel kunt herstellen.

De EAValidator is in ontwikkeling. Voor het laatste nieuws ga naar http://www.fflowing.nl/model-validation-for-enterprise-architect/

 

Enterprise Architect User Group Event 5 februari 2014

Utrecht Conference date graphicOp 5 februari aanstaande organiseert NS in samenwerking met de EA User Group het Enterprise Architect User Group Event. Dit vindt plaats in het Trefpunt op het hoofdkantoor van NS.

De conferentie is voor professionals die gebruikmaken van de modelleertool Enterprise Architect. Tijdens deze dag kan kennis en ervaring over het gebruik van de tool gedeeld worden. Meer informatie en het programma kun je vinden op de website van de EA User group http://www.eausergroup.com.

Robert heeft goede en slechte tijden gehad met het gebruik van Enterprise Architect. Robert is één van de sprekers en zal zijn ervaringen met Enterprise Architect delen en een aantal tools demonstreren voor code generatie uit EA en Model validatie.

Aanmeldingen voor dit event verlopen ook via www.eausergroup.com. De kosten voor de volledige conferentie dag zijn 60 euro. Er zijn een beperkt aantal plaatsen voor de conferentie, dus meld je snel aan!!

agenda