UML: Vantagens e Desvantagens
Tags: uml, braziliandevs
Published: 2020-07-16 22:16:45

Estudar UML é sempre um jogo de perguntas e respostas para a profissão de desenvolvedor, por um ponto de vista, ela é uma estrutura padrão no ensino acadêmico superior e nos é  mostrada como algo essencial e indispensável para a modelagem e arquitetura do software a ser desenhado, por outro ponto de vista, temos opiniões contrárias de alguns profissionais dizendo que não existe tanta importância a sua utilização, a modelagem geralmente é feita DER da estrutura do banco de dados e os requisitos listados, com documentação superficial ou sem documentação, fruto da metodologia ágil, alguns dizem; e talvez o fator que esteja fazendo esse aculturamento de desprezo pela utilização da UML e seus 14 tipos de diagramas

Com objetivo de tentar listar as vantagens e desvantagens do uso dessa ferramenta de modelagem, realizei algumas pesquisas, o texto [“A complexibilidade da UML e seus diagramas”](http://revista.faculdadeprojecao.edu.br/index.php/Projecao4/article/view/825) de Bonny Martins, Walisson Diniz e Rogerio da Silva, faz uma introdução da ferramenta, abordando aspectos históricos, técnicos e explicando cada diagrama proposto e sua utilização, mas para entregar esse texto, preciso de opniões práticas de uso, e existe muita discussão sobre o tema em redes sociais e blogs de empresas como a Creately.com e Techwalla usados como referência base desse texto e threads de discussão no Twitter e no site dev.to.  

Minha humilde experiência e opinião acerca do tema, é o não uso, talvez por que a equipe de desenvolvimento é pequena, demanda exagerada onde a documentação e modelagem está em estrutura de banco de dados e rascunhos com checklists de funcionalidades, sei e tenho consciência que não é uma boa prática, acho importante tentar documentar, listar processos e code review do código fonte, elaborar documentação do código com ferramentas específicas, para retirar a dependência da lógica de negócio de está com uma única pessoa.

# Vantagens da UML 

### Mais usados ​​e flexíveis

UML é uma plataforma altamente reconhecida e compreendida para design de software. É uma notação padrão entre desenvolvedores de software. Você pode assumir com segurança que a maioria dos profissionais de software conhece pelo menos os diagramas UML, se não bem versados, tornando-o a alternativa ideal para explicar os modelos de design de software.

### Representação visual

Um diagrama UML é uma representação visual dos relacionamentos entre classes e entidades em um programa de computador. Ao mostrar essas informações em um diagrama, é fácil entender e visualizar os relacionamentos de um programa

### Legibilidade e reutilização

Um diagrama UML é benéfico, pois é muito legível. O diagrama deve ser entendido por qualquer tipo de programador e ajuda a explicar os relacionamentos de um programa de maneira direta. Além disso, usando um diagrama para mostrar o código em execução em um programa, um programador pode ver código redundante e reutilizar partes do código que já existem, em vez de reescrever essas funções

### Padrão

Por ser usado como padrão, é amplamente entendido e bem conhecido. Isso facilita para um novo programador entrar em um projeto e ser produtivo desde o primeiro dia.

### Ferramenta de Planejamento

A UML ajuda a planejar um programa antes que a programação ocorra. Em algumas ferramentas usadas para modelar UML, a ferramenta irá gerar código com base nas classes configuradas no modelo. Isso pode ajudar a reduzir a sobrecarga durante o estágio de implementação de qualquer programa. 

### A arquitetura do software deve ser comunicada com eficácia

A arquitetura do software é a planta do sistema. É a estrutura da qual depende a eficiência do sistema e de seus processos. Mas, essa estrutura só é eficaz se for comunicada adequadamente a todos que a utilizam e trabalham nela. É aqui que a UML ( Unified Modeling Language ) entra em cena.

Devido ao seu amplo alcance, a UML é a linguagem visual perfeita para comunicar informações detalhadas sobre a arquitetura ao maior número de usuários.

Você precisa conhecer apenas uma fração da linguagem para usá-lo
Embora existam 14 tipos diferentes de diagramas UML para aplicativos de modelagem, os desenvolvedores usam apenas três ou quatro para documentar um sistema de software. Diagramas de classes, diagramas de seqüência e diagramas de casos de uso continuam sendo os mais procurados.

### Abundância de ferramentas UML

As ferramentas UML são uma das razões mais importantes pelas quais a UML é tão amplamente usada. As ferramentas UML variam de software de código aberto gratuito até aqueles que custam milhões de dólares. Essas ferramentas cobrem muito território, além de apenas desenhar diagramas. Eles podem gerar código a partir do design, aplicar padrões de design, requisitos de mina, código de engenharia reversa e executar análises de impacto e complexidade.

# Desvantagens da UML

### Notação formal não é necessária

O argumento mais forte contra a UML é que você realmente não precisa de um diagrama UML para comunicar seus projetos. Você pode ter o mesmo impacto e efeito com diagramas informais de caixa e linha criados no PowerPoint, Visio ou em um quadro branco. Como a codificação é uma linguagem formal por si só, muitos desenvolvedores não preferem a complexidade e a formalidade no nível da arquitetura, o que desencoraja o uso da UML e se tornou uma de suas desvantagens.

### Grau de complexidade crescente

Desde o seu início até agora, a UML cresceu em complexidade e tamanho. O tamanho da UML deixa muitas pessoas nervosas logo no início, e elas sentem que não serão capazes de aprender e que estão melhor sem ela.

### Não é necessário em 'design indiferente à arquitetura'

Um termo cunhado [por George Fairbanks, 'design indiferente à arquitetura'](https://www.amazon.com/Just-Enough-Software-Architecture-Risk-Driven/dp/0984618104/ref=sr_1_1?s=books&ie=UTF8&qid=1287576926&sr=1-1) é uma situação em que a UML é considerada desnecessária.

Na sua essência, um design indiferente à arquitetura refere-se a uma arquitetura de software simples e básica e não precisa de nenhum diagrama complexo para representar ou explicar o design. Se as empresas enfatizarem mais a codificação formal e houver uma cultura predominante de documentação mínima de design, a UML será considerada desnecessária.

### Tempo

Uma desvantagem que alguns desenvolvedores podem encontrar ao usar a UML é o tempo necessário para gerenciar e manter os diagramas da UML. Para funcionar corretamente, os diagramas UML devem ser sincronizados com o código do software, o que requer tempo para configurar e manter, além de adicionar trabalho a um projeto de desenvolvimento de software.

### Quem não se beneficia

Nem sempre é claro quem se beneficia de um diagrama UML. De acordo com um artigo publicado no site da Eiffel Software, a UML não é vantajosa para os desenvolvedores de software, principalmente porque os desenvolvedores de software trabalham com código, não com figuras ou diagramas.

### Diagramas podem ficar impressionantes

Ao criar um diagrama UML em conjunto com o desenvolvimento de software, o diagrama pode se tornar esmagador ou complicado demais, o que pode ser confuso e frustrante para os desenvolvedores. Os desenvolvedores não podem mapear todos os cenários de uma ferramenta de software no diagrama e, mesmo que tentem, o diagrama fica confuso

### Muita ênfase no design

A UML coloca muita ênfase no design, o que pode ser problemático para alguns desenvolvedores e empresas. Observar um escopo de software em um diagrama UML pode fazer com que as partes interessadas do projeto de software super examinem os problemas, além de fazer com que as pessoas percam o foco gastando muito tempo e atenção nos recursos de software. As empresas não podem resolver todos os problemas com uma ferramenta de software usando um diagrama UML - eventualmente, elas apenas precisam começar a codificar e testar

Todas as opções levantadas tem sua lógica e o uso ou adoção do UML dentro de uma empresa vai depender de uma séries de variáveis, como time de desenvolvimento, tamanho da equipe,  necessidade, apesar que necessidade vai ocorrer em algum momento, nem que seja um documentação de processo usando BPMN, ou uma documentação inicial usando UML. Brody Gooch, co-criador da UML, disse que a visão original da UML era uma "linguagem gráfica para ajudar a raciocinar sobre o design de um sistema à medida que ele se desenrola".

E as inúmeras discussões e opiniões levantadas e encontradas na pesquisa inicial encontramos outros métodos e direcionamentos de substituição ou complementar. Exemplo:
 
- [modelo C4](https://c4model.com/) (esta é uma abordagem de abstração para diagramação; compatível com UML) criado por [Simon Brown](https://simonbrown.je/)
- A pesquisa do Dr. Sebastian Baltes no artigo sobre ["Esboços e diagramas na prática"](https://empirical-software.engineering/assets/pdf/xp16-sketching.pdf) descreve que a maioria dos esboços e diagramas no estudo era bastante informal e apenas 9% deles foram classificados como diagramas UML "puros".
- Para sistemas intensivos em banco de dados, o [Crow's foot](http://www2.cs.uregina.ca/~bernatja/crowsfoot.html)
- [notação de Chen](https://www.vertabelo.com/blog/chen-erd-notation/) para diagramas de ER são úteis.
- O [SysML](https://www.omgsysml.org/what-is-sysml.htm) é um bom elogio à UML para engenharia de sistemas.
- [notações de modelagem do IDEF](http://www.sba.oakland.edu/faculty/mathieson/mis524/resources/readings/idef/idef.html#:~:text=The%20Integrated%20Computer%2DAided%20Manufacturing%20Definition%20(IDEF)%20language%20consists,data%22%20associated%20with%20the%20ICOMs.)

>Martin Fowler [escreveu cerca de quatro deles - esboço, notas, planta e linguagem de programação](https://martinfowler.com/bliki/UmlMode.html). A UML é uma linguagem rica, mas isso não significa que você precise usar todos os recursos que ela oferece. Escolha e escolha adequadamente e faça seus modelos no nível apropriado para o público-alvo. Mas siga as regras que a linguagem fornece para que as pessoas possam entender facilmente a notação usada

Esse foi um comentário de um usuário sobre UML em uma discussão no site [Dev.to](https://dev.to/rafalpienkowski/do-developers-still-need-uml-ajh) acerca de classifcações dada a UML sob a perspectiva de quem está utilizando e usando como exemplo um artigo de Martin Fowler onde ele conclui que quando a visão de alguém da UML parece bastante diferente da sua, talvez seja porque eles usam um modo diferente para você. Além disso, sua percepção da UML pode ser afetada pelo modo em que ela foi introduzida a você.

Outra referência que podemos encontrar conectada diretamente a UML são os softwares [MDE - Model Driven Engineering](https://ict.eu/model-driven-engineering/) que hoje em dia estão usando palavras da moda como [Low-Code Platforms](https://modeling-languages.com/low-code-platforms-new-buzzword/) com suas telas de arrastar e soltar já conhecidas do MDE com uma reformulação da marca usando terminologia novas, mas atuando no mesmo segmento de modelagem do sistema e geração automática de código.

# REFERÊNCIAS:


https://www.techwalla.com/articles/list-of-advantages-of-uml

https://www.techwalla.com/articles/the-disadvantages-of-uml

https://creately.com/blog/diagrams/advantages-and-disadvantages-of-uml/

https://saturnnetwork.wordpress.com/2010/10/22/five-reasons-developers-dont-use-uml-and-six-reasons-to-use-it/

https://c4model.com/

https://simonbrown.je/

https://empirical-software.engineering/assets/pdf/xp16-sketching.pdf
https://empirical-software.engineering/publications/#xp16-sketching-experiment

https://dev.to/rafalpienkowski/do-developers-still-need-uml-ajh

https://martinfowler.com/bliki/UmlMode.html

https://www.amazon.com/Just-Enough-Software-Architecture-Risk-Driven/dp/0984618104/ref=sr_1_1?s=books&ie=UTF8&qid=1287576926&sr=1-1

http://www2.cs.uregina.ca/~bernatja/crowsfoot.html

https://www.vertabelo.com/blog/chen-erd-notation/

https://www.omgsysml.org/what-is-sysml.htm

http://www.sba.oakland.edu/faculty/mathieson/mis524/resources/readings/idef/idef.html#:~:text=The%20Integrated%20Computer%2DAided%20Manufacturing%20Definition%20(IDEF)%20language%20consists,data%22%20associated%20with%20the%20ICOMs.

https://twitter.com/ThePracticalDev/status/932330636291043330

https://ict.eu/model-driven-engineering/

https://modeling-languages.com/low-code-platforms-new-buzzword/

https://www.mendix.com/blog/understand-no-code-vs-low-code-development-tools/