Durante muito tempo, principalmente na época de faculdade, olhava para aquele monte de diagramas sem sentido e me perguntava:
- Como isso pode ajudar alguém ou alguma equipe a desenvolver software?
Sim, eu estava falando de UML.
Acredito que muitos profissionais de TI sintam esta mesma antipatia. Isso talvez se deva ao fato de enxergarem a UML, da mesma forma que eu costumava enxergar, como um PROCESSO.
Antes de mais nada é importante esclarecer o seguinte:
"UML não é um processo, UML é uma ferramenta!"
Isso pode parecer básico, mas faz toda a diferença. Vejamos as figuras a seguir:
 |
| Visão geral da UML |
 |
| Visão geral do SCRUM |
A primeira figura, nos dá uma visão geral da UML e seus diagramas, a segunda, fornece uma visão geral do SCRUM.
Se retirarmos qualquer elemento do SCRUM, ele deixa de ser SCRUM, se não utilizarmos certos diagramas da UML em nossos projetos de software, a UML continua sendo UML, continua sendo uma ferramenta de apoio, pois, ao contrário do SCRUM, UML não é um processo.
Utilizar a UML como metodologia de desenvolvimento de software é errado, é contraproducente, torna o processo penoso e se associado à um modelo em cascata, torna as coisas muito piores. No final, você se vê afogado em diagramas que não possuem utilidade prática para o seu domínio e o pior, sem código escrito.
Depois que passei a enxergar UML como uma ferramenta de apoio, passei a usufruir dos seus reais benefícios e ela passou a realmente auxiliar em meus projetos. Basicamente, utilizo 3 diagramas:
- Diagrama de Classes: Este dispensa comentários, é o mainstream dos diagramas da UML, o popstar. Este diagrama é uma foto do seu modelo. Ele contém os objetos e a forma como eles se relacionam.
- Diagrama de Sequência: Serve como apoio para descrever funcionalidades do seu sistema. Ele descreve a maneira como objetos colaboram entre si, para atingirem um objetivo.
- Diagrama de Atividades: Este é um diagrama de uso geral, pode ser utilizado para descrever literalmente, qualquer coisa. É um ótimo diagrama para comunicação entre a equipe, descrição de processos complexos, casos de uso e estórias do cliente.
Com exceção do diagrama de classes, não é sempre que faço uso dos outros diagramas, tudo depende da necessidade da situação.
Esta é apenas uma pequena parte da UML, mas que em geral, atende bem às minhas necessidades. Não se obrigue a utilizar tudo o que é oferecido, utilize a UML como uma ferramenta e com certeza você será beneficiado em seus projetos.
