Fazendo a uml valer a pena
Por Walter Itamar Mourão
Há mais de vinte anos acompanho a luta da documentação técnica de sistemas, ou melhor: a luta pela boa documentação técnica de sistemas. De um lado, consultores e acadêmicos mostram por
"a+b" o valor da documentação no processo de desenvolvimento de software. Do outro, gerentes de projeto e desenvolvedores que geralmente não têm tempo para criar a documentação técnica nos padrões adequados e no tempo certo.
Considero que os principais motivos que impediam a ampla adoção da documentação como parte essencial de projeto de software eram a falta de um formato padronizado para a criação dessa documentação e uma grande resistência por parte da equipe técnica em acoplar ao seu projeto uma atividade que não traria benefícios visíveis e diretos ao produto final ou ao processo de desenvolvimento. Documentação técnica
Quando falo em documentação técnica estou me referindo a todo e qualquer artefato que seja produzido durante o processo de desenvolvimento que tenha um caráter informativo ou de comunicação entre as partes envolvidas no projeto. Especificações, definições de caso de uso, documentação de fontes (javadoc), diagramas são exemplos de documentação técnica.
A UML
A UML define formalmente um conjunto de elementos para a descrição de um sistema computacional e veio preencher uma lacuna de padronização e formalidade na descrição de um programa de computador, rapidamente se tornando o padrão de fato na descrição em alto nível de sistemas computacionais de qualquer complexidade. Atualmente a UML aborda inclusive as áreas periféricas ao software propriamente dito, como definição de requisitos, ambiente de implantação e fluxo de processos genéricos.
Apesar dessa adoção ampla, pode-se dizer que ela ocorreu “de cima para baixo” uma vez que um grande número de desenvolvedores e gerentes de projeto ainda resiste a UML, ou melhor: resistem à inclusão do processo de documentação no seu