segunda-feira, 21 de julho de 2008

Até onde ir com a redocumentação

Trabalhar com Java agora me fez ter que ler artigos sobre o assunto. Isso já nem me incomoda já que Orientação à objetos é bem discutida no meio. Já faz um tempo eu estava lendo o artigo do Rodrigo Yoshima, sobre UML numa Mundo Java já antiga. O Rodrigo levanta a questão de que UML não serve para documentar e mais ainda para redocumentar.

A UML foi feita para analisar e deve ser utilizada para tal. Quando entrei no serviço foi me pedido para fazer a Redocumentação de um sistema. Refiz o Diagrama de Negocio, Casos de Uso e Regras de Negócio.

Quando terminei o programador responsável pelo desenvolvimento veio me perguntar se dava pra fazer o Diagrama de Classes e Diagrama de Sequência. Resolvi dar uma de preguiçoso e verificar se dava pra fazer com alguma ferramenta de mercado. A única ferramenta que encontrei que fazia o trabalho mais ou menos bem era o Omondo que utilizei o plugin do Eclipse. Mesmo assim ele não conseguia resolver situações nas quais existiam Interfaces no meio do caminho.

Não sei se existe alguma ferramenta que faça o trabalho bem ou se realmente vale a pena refazer toda essa documentação. O desejo do programador lá no caso era ter uma forma de saber qual a comunicação que existe entre as classes e como onde saber até onde um método afeta dentro da estrutura de classes. (Um método do meu controlador afeta qual DAO?)

Seria realmente necessária realizar uma tarefa desse suporte? Isso dá muita discussão e nem sei até onde chega. Existe alguma ferramenta que faça esse trabalho braçal de forma eficiente? Se existe, eu não encontrei.

Um comentário:

Anônimo disse...

"Refiz o Diagrama de Negocio, Casos de Uso e Regras de Negócio."

Sem contar que UML, IMHO, não é a melhor ferramenta pra fazer isso. Um papel, de preferência sem seguir o modelo RUP, e uns .bmp ("toscão mesmo") são melhores.

Morte à UML. xD