Diagrama de Atividades

Mais umas citações do livro de UML do guru barbudo:

Dessa eu não sabia:

You’ll notice that the nodes on an activity diagram are called actions, not activities. Strictly, an activity refers to a sequence of actions, so the diagram shows an activity that’s made up of actions.

Sempre achei que cada bolha do diagrama de atividades fosse uma atividade… passarei a chama-las corretamente.

Foi o cão que fez:

If you’re sufficiently brave to venture into the demonic depths of the UML specification, you’ll find that the activity section of the specification talks a lot about tokens and their production and consumption.

Diagramas de atividades são complexos, utilize-os com parcimônia.

Casos de uso

Do livro “UML Destilada” do barbudo Martin Fowler:

Diagramas de caso de uso são índices…

The best way to think of a use case diagram is that it’s a graphical table of contents for the use case set.

Essa é a melhor:

The UML includes other relationships between use cases beyond the simple includes, such as «extend». I strongly suggest that you ignore them. I’ve seen too many situations in which teams can get terribly hung up on when to use different use case relationships, and such energy is wasted. Instead, concentrate on the textual description of a use case; that’s where the real value of the technique lies.

Eu mesmo já perdi muito tempo pensando se eu deveria usar include ou extend, o pior é quando perde-se tempo discutindo qual relacionamento é melhor para uma situação X!

Outra:

You don’t have to write all the detail down; verbal communication is often very effective, particularly within an iterative cycle in which needs are quickly met by running code.

É bom lembrar disso quando for preencher templates de casos de uso. Numa dessas, é mais eficiente resolver na palavra falada.