UML

março 3, 2010

É fato que modelagem é essencial para desenvolvermos sistemas de fácil manutenção e de boa qualidade. Porém, vez ou outra escuto alguém com a ideia de que para modelar devemos representar em UML todos os aspectos do sistema antes de iniciar a implementação, chamando isso de etapa de análise e projeto.

Não é novidade que isso não é nada produtivo e totalmente desnecessário. No livro UML Destilled do Martin Fowler, é proposta a abordagem de uso dos diagramas UML como rascunhos, com o objetivo de facilitar a comunicação na modelagem do sistema. Outros profissionais e autores respeitáveis também compartilham desta opinião. Por exemplo, o Ron Jeffries disse recentemente numa lista de discussão:

If you mean by UML occasionally drawing a picture on a bar napkin, I’m all for it. If you mean something more like using full-on UML to draw a comprehensive diagram of the entire object graph, it is a waste of time.

Designing in code works much better than UML for many people, mostly because when you design in UML you get UML and when you design in code you get the program.

Outro que também tem uma opinião parecida é o Robert Martin:

Look, modeling is an abstraction. We purposely suppress details to see the big picture. In order for these ‘modeling’ tools to generate executable code, they need all the details. Well, I have news for you. If you include all the detail, then you’re not modeling! You’re programming, albeit with a different language!

Concordo com eles, a UML é uma excelente ferramenta de modelagem e não uma linguagem de programação. Papel e caneta, ou quadro e pincel são ferramentas UML tão boas quanto o JBuilder ou o StarUML e demais ferramentas CASE.

Anúncios

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.