Basicamente, UML (Unified Modeling Language) é uma linguagem de notação (um jeito de escrever, ilustrar, comunicar) para uso em projetos de sistemas.
Esta linguagem é expressa através de diagramas. Cada diagrama é composto por elementos (formas gráficas usadas para os desenhos) que possuem relação entre si.
Os diagramas da UML se dividem em dois grandes grupos: diagramas estruturais e diagramas comportamentais.
Diagramas estruturais devem ser utilizados para especificar detalhes da estrutura do sistema (parte estática), por exemplo: classes, métodos, interfaces, namespaces, serviços, como componentes devem ser instalados, como deve ser a arquitetura do sistema etc.
Diagramas comportamentais devem ser utilizados para especificar detalhes do comportamento do sistema (parte dinâmica), por exemplo: como as funcionalidades devem funcionar, como um processo de negócio deve ser tratado pelo sistema, como componentes estruturais trocam mensagens e como respondem às chamadas etc.
UML deixa as coisas claras
UML ajuda muito a deixar o escopo claro, pois centraliza numa única visão (o diagrama) um determinado conceito, utilizando uma linguagem que todos os envolvidos no projeto podem facilmente entender.
Mas ajuda desde que utilizada na medida certa, ou seja, apenas quando realmente é necessário.
O maior problema na produção de software, a maior dor, em qualquer país do mundo, chama-se comunicação ruim.
Vejamos um rápido exemplo didático de como se dá a comunicação em equipes de produção de software:
/* João quer A, explica à equipe algo “parecido” com B. Marcos entende que João quer C, e explica para Claudia que é para fazer D. Claudia faz um “D que mais se parece um E”, e entrega um “meio E” para João. E João queria um A… */
Incrivelmente, muitos profissionais seniores de software ainda ignoram isso. Veremos mais sobre isso à frente.
A UML é como uma linguagem universal para profissionais de produção de software, é um “Google Translate” que ajuda muito a comunicação clara e objetiva entre pessoas envolvidas no processo de produção (Analistas de Negócio, Product Onwer, Scrum Master, Arquitetos, Desenvolvedores, Gerentes de Projeto/Produto e demais partes interessadas).
Penso que, no mínimo, 50% do trabalho de construir sistemas é comunicação. Os outros 50% do trabalho trata-se da materialização daquilo que é combinado/alinhado entre as partes envolvidas no processo.
/* Alguns profissionais de diferentes níveis de senioridade consideram que utilizar UML em equipes de software é perder tempo. Isso se dá por alguns poucos motivos, dentre eles: 1) estes profissionais confundem usar UML para comunicação com usar UML para documentação, 2) estes profissionais são seniores que já estão cheio de vícios e preconceitos e não revisam seus pontos de vista sobre as coisas, 3) estes profissionais são jovens que chegaram no mercado na onda “agilista” e com pouco senso crítico compram ideias de terceiros, independente dos fundamentos. Todavia, a diversidade de opinião é saudável e bem aceita, graças a Deus! 🙂 */
Caso você não ainda não tenha tido contato com a UML, seguem alguns diagramas para melhorar o contexto do post.
Diagrama de Atividades
Diagrama de Classes
Diagrama de Sequência
Diagrama de Instalação
Princípio de Pareto – 80/20 no uso da UML
O princípio de Pareto nos mostra (dentre outras coisas) que 20% das ações que realizamos são responsáveis por 80% dos nossos resultados.
E realmente é algo que se aplica.
No contexto do uso de UML na produção de software também se aplica: 20% dos recursos da UML atendem em 80% dos cenários que precisamos especificar.
Dos 21 diagramas disponíveis na versão atual da UML (versão 2.5.1) 6 diagramas atendem 80% do que precisamos, e para cada um dos seis, 20% dos recursos que cada diagrama oferece resolvem 80% do que precisamos fazer.
Ou seja, apenas o necessário, sem desperdício.
Entretanto, principalmente na década passada, a tendência era usar UML para documentar 100% das funcionalidades, utilizando 100% dos diagramas, e 100% dos recursos de cada diagrama, e ainda manter este documentação 100% atualizada.
Na Engenharia Civil isso é possível, na Engenharia de Software, é missão impossível. Isso em função do Cone da Incerteza.
O mesmo se aplica a orientação a objetos, a qualquer linguagem de programação (moderna ou não), a modelagem de dados, a definições arquiteturais, micro serviços, testes unitários etc.
20% resolve 80%. O foco deve ser em não ter desperdício. Foco na eficiência, na produtividade.
Para que serve?
O objetivo de um diagrama da UML é passar uma mensagem de maneira padronizada, onde todos os receptores deste mensagem entendem o padrão usado.
É o famoso: “entendeu ou quer que desenha?” 🙂
Imagine que numa mesma sala, sem internet e telefone, estão três pessoas que só falam seu idioma nativo: um chinês, um francês, e um brasileiro.
Nesta sala tem apenas papel e lápis. O francês quer um café.
Qual será a maneira mais eficiente, considerando os recursos disponíveis na sala, para o francês passar a mensagem “quero um café”?
Talvez fazendo um desenho de uma xícara de café! 😉
Deixar isso claro, de maneira simples, objetiva, transparente e pragmática, é comunicar-se bem.
Levando o raciocínio acima para projetos de software, a UML deve ser utilizada para comunicar o que se quer e/ou como se quer, de maneira eficiente.
No passado utilizou-se UML muito para documentar software existente, fazer projeto preditivo de sistema (ou seja, via diagrama documentar 100% do que deveria ser feito) etc. Isso quase nunca é viável.
A UML serve para uma boa comunicação em equipes que produzem software, onde através do uso de diagramas adotamos uma linguagem que todos entendem, para deixar claro o que deve ser feito.
Quando usar?
O uso de diagramas da UML deve ser feito quando:
- É necessário especificar o desejo do cliente que será materializado no software.
- Quando membros de uma equipe precisam ter uma visão única e padronizada sobre algo, seja no contexto de escopo funcional (requisitos, estórias de usuário ou modelos de processo) e não funcional (foco na arquitetura/estrutura do sistema e integrações)
- Comunicar para o mundo externo protocolos (contratos) de interfaces do sistema que devem ser consumidas por terceiros ou ilustrar topologias arquiteturas físicas/lógicas.
Exemplos de Uso
Abaixo temos alguns posts aqui do blog, com exemplos bem detalhados do uso de alguns dos principais diagramas da UML:
- Diagrama de Atividades
- Diagrama de Caso de Uso
- Diagrama de Classes
- Diagrama de Sequência
- Diagrama de Instalação
Concluindo
UML é uma linguagem espetacular.
É como um idioma de simples compreensão, que auxilia equipes de produção de software a ter maior eficiência e eficácia no dia a dia, possibilitando uma comunicação clara e objetiva sobre o que deve ser feito, e como deve ser feito.
Essa clareza possibilitada na comunicação pelo uso da UML diminui diretamente o desperdício tão comum na produção de software, desperdício este gerado pelo entendimento “torto” das coisas, e descoberta tardia deste desalinhamento.
Mas, como tudo na vida, tem que ser usada na justa medida: o equilíbrio.
Em tempos de agilidade, de lean aplicado na produção de software, o princípio da parcimônia deve ser premissa no mindset dos analistas de sistemas.
Participe nos comentários!
Abraço!