Diagrama de Atividades

abril 11, 2008

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

abril 8, 2008

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.


Comunidade de fonte aberta

fevereiro 8, 2008

sun_ingles.png

sun_portugues.png


Rastreabilidade de requisitos, qual é o teu problema?

abril 24, 2007

Já ouvi dizer que o problema que a rastreabilidade de requisitos tenta resolver é: Em uma situação de alteração ou manutenção, é necessário identificar os artefatos (leia-se classes e documentos) relacionados ao requisito que está sofrendo a alteração.

Será que não existe nada mais simples para fazer isso?

Me parece que as seguintes soluções são melhores:

  • Cobrir a aplicação com testes automatizados de unidade, integração e funcional. Dessa forma, o impacto de qualquer alteração já se reflete nos testes. Muito mais confiável do que olhar uma matriz e analisar o impacto.
  • debug da aplicação com um ou mais breakpoints

Mais alguma solução?