UML: por que menos pode ser mais?

Photo by rawpixel.com from Pexels

Caso você tenha estudado sobre práticas comuns de Engenharia de Software, provavelmente já se deparou com os conceitos da UML (Unified Modeling Language) e seus diagramas. Se esse não for o seu caso, eu sugiro fazer a leitura desse excelente texto (em português) para entender os conceitos básicos.

Uma coisa que parece incomodar muita gente é o fato dos diagramas UML serem, por vezes, metódicos demais. Através dos diagramas, todas as partes de um software podem ser descritas nos mínimos detalhes, em diferentes pontos de vista: casos de uso, atividades em processos, entidades, pacotes, infraestrutura, trocas de mensagens, estados da aplicação, etc. Mas quem tem tempo para criar a fazer manutenção de uma dezena de diagramas em um projeto real? Considerando que a maioria dos processos de desenvolvimento atuais em dia focam na agilidade, quase ninguém.

E além disso, até que ponto fazer tanta modelagem é realmente útil? Não é melhor ir direto para a ação? Bom, o ideal é encontrar um equilíbrio entre as duas coisas. No artigo Design is Dead, Martin Fowler diz:

Primeiro tenha em mente para quê você está desenhando os diagramas. O princípio primário é a comunicação. Comunicação efetiva significa selecionar as coisas importantes e deixar de lado as menos importantes. Essa seletividade é a chave para utilizar bem a UML.

Trocando em miúdos: às vezes, em termos de UML, quanto menos melhor. Modelar cada mínimo detalhe do sistema, além de cansativo, pode acabar se tornando trabalho inútil, não pelo fato de que a informação nos diagramas não é relevante, mas pelo fato de que quando há informação DEMAIS a comunicação entre as partes de um projeto fica difícil. É como tentar ouvir uma pessoa específica falando em meio a uma multidão aos berros. E já que todo mundo gosta de um bom lanche, tomemos como exemplo um diagrama de classes simplificado representando uma lancheria:

Diagrama de classes para uma lancheria (ou qualquer estabelecimento que realize vendas)

O que tem de errado com esse diagrama? A princípio, nada. Mas ele certamente poderia estar mais limpo e resumido, começando pelas associações entre classes. Segundo o manual de referência da UML:

(…) Não é obrigatório que uma associação possua um nome; rolenames em suas extremidades proporcionam uma maneira de distinguir múltiplas associações entre as mesmas classes.

Sendo assim, podemos optar por retirar os nomes e manter apenas os rolenames, que ajudam a explicar qual é o papel (role) de determinada classe naquele contexto. Como esse modelo é muito simples, aqui os rolenames também não se fazem necessários. Mas, e as operações CRUD nas classes? Bom, é meio óbvio que vamos querer inserir, alterar e excluir instâncias dessas entidades, logo é redundante repetirmos essas operações em cada classe. Algo semelhante pode ser feito no diagrama de casos de uso, onde essa operações podem ser unidas em um único caso, conforme o CRUD Complete pattern.

Além disso, as marcações de visibilidade e tipos não são obrigatórias (há vários exemplos disso com diagramas no manual de referência). Enquanto essas informações são muito importantes do ponto de vista do desenvolvedor, podem não ser fundamentais em uma primeira análise e podem até mesmo confundir alguém que não domine conceitos mais técnicos. Portanto, nesse exemplo iremos removê-las também. E pronto! Com algumas pequenas modificações pudemos deixar o diagrama de classes bem mais limpo visualmente, sem perder informações ou prejudicar o entendimento.

Diagrama de classes simplificado: os conceitos fundamentais para o entendimento permanecem

E quanto aos demais diagramas? Bom, é preciso analisar se eles são necessários no projeto que você está desenvolvendo. Se todos os membros do projeto estão conseguindo comunicar suas ideias de forma concisa com poucos diagramas UML ou mesmo com textos ou outras formas de modelagem, é isso que importa. A UML é extremamente versátil, e apesar de permitir a criação de modelos extremamente detalhados, a ideia é que ela seja usada de forma tão simples quanto possível.

Contudo, nem too mundo tem o mesmo ponto de vista sobre como um determinado diagrama UML deveria ser feito. Com certeza os diagramas nesse post poderiam ter sido criados de maneira diferente caso fossem feitos por outro autor. Isso ocorre por que a UML não é algo “escrito na pedra”: ela é uma linguagem que pode ser usada para múltiplos propósitos, e que oferece também múltiplas interpretações. Em uma equipe de desenvolvimento podem ocorrer embates de opinião por conta da modelagem, mas nesses casos a solução é debater abertamente e tentar chegar a um consenso, como Martin Fowler comenta em How standard is Standard UML?:

Quando utiliza a UML para comunicação, você está escolhendo uma interpretação ou considerando uma extensão – como escolher? Busque fontes renomadas e veja se essas pessoas estão dizendo algo. Caso elas estejam, isso deve influenciar sua decisão, mas não decidir por você. No fim das contas, você deve escolher o que for mais útil para você.

Em resumo: a UML é extremamente útil para a modelagem de sistemas. Contudo, use com moderação!

Fontes:

Nota: todas as citações foram traduzidas do inglês pelo autor deste post. A tradução é de inteira responsabilidade do mesmo.