Ontem conversei com duas pessoas sobre UML, e percebi um fato curioso. Nas duas ocasiões a UML foi considerada como um método para documentação de desenvolvimento, o que não é uma verdade. Se me permitem, estas conversas me inspiraram a escrever o devaneio a seguir.
Claro que o mercado utiliza UML amplamente na elaboração de documentações (principalmente em empresas que trabalham com processos RUP like), mas este é um equivoco. A UML é somente mais uma ferramenta de modelagem, assim como modelos entidade-relacionamento, fluxogramas, organogramas e todos esses diagramas que se encontra por ai.
Em tradução livre, UML significa Linguagem Unificada de Modelagem, e é exatamente isso que ela é, uma linguagem de modelagem. Não há nenhum método por trás disso, nenhum processo, nenhuma dependência; trata-se apenas da definição de uma notação padrão para a construção de alguns diagramas que ajudam, e muito, na representação de conceitos inerentes ao desenvolvimento de software. Acredito que esta confusão ocorre devido a forma como esta poderosa ferramenta é utilizada no dia-a-dia das equipes de desenvolvimento.
Atualmente, observamos um movimento de empresas que possuem ou buscam um processo bem definido(CMMI/MPS.Br/RUP like). Nestes processos, normalmente há uma análise técnica, que gera um artefato, que será utilizado na decisão da aprovação do desenvolvimento. Nestes casos, a UML é muito utilizada para a documentação, que depois servirá como guia ao desenvolvimento. Atualmente existem muitas empresas em busca de uma certificação CMMI ou MPS.BR, onde a solução mais comum é fazer esta documentação técnica utilizando UML extensivamente, justamente porque a UML é provavelmente a melhor ferramenta que existe atualmente para este fim.
Em empresas e equipes ágeis, a história é um pouco diferente, principalmente porque a análise técnica é realizada somente quando a funcionalidade será implementada e a documentação formal é realizada apenas quando realmente necessária. Com isso, a análise técnica passa a ser feita apenas com o objetivo de entender o problema do cliente, para permitir o início imediato do desenvolvimento de uma solução. Nesta situação a UML passa a ser uma poderosa ferramenta de apoio, pois é capaz de facilitar a análise e entendimento do domínio do problema e a transferência de conhecimento entre os membros da equipe.
Com estes exemplos podemos perceber claramente que a UML é uma ferramenta, não um método. Muitas vezes os métodos adotados levam ao uso da UML para a confecção de documentação, mas a UML pode ser utilizada para outras tarefas além da confecção de documentos. É muito mais fácil entender um domínio através de um diagrama de classes do que lendo um texto ou conversando, assim como é muito mais simples entender um cenário através de um caso de uso. Na análise de um problema envolvendo uma equipe e um quadro branco (ou mesmo um papel de rascunho) a UML passa a ser uma ferramenta de comunicação imprescindível. E isso não a torna menos importante ou essencial como em um documento.
