Quais diagramas UML ainda estão sendo amplamente utilizados? [fechadas]

Ensino engenharia de software na graduação e tenho uma pergunta para os profissionais da UML.

A maioria dos livros didáticos de engenharia de software faz um grande esforço para cobrir os diagramas UML. Por outro lado, porém, ouvi de muitos graduados que a UML não parece mais ser usada nas trincheiras.

Quais diagramas UML ainda estão sendo amplamente utilizados na prática profissional e por quê? Existem diagramas que não são mais usados ​​e por quê?

NB: Para evitar debates e discussões com base em opiniões, ilustre sua resposta com elementos de fato e objetivo (se possível, verificáveis) ou observações neutras sobre a experiência pessoal

Dos muitos diagramas propostos pela UML, os diagramas de classe e de seqüência ainda são amplamente utilizados, certamente seguidos pelos diagramas de estado:

• eles podem ser facilmente usados ​​em quadros brancos para elaborar e discutir o design antes de entrar no código
• eles permitem transmitir muito rapidamente uma visão geral que o código por si só não oferece tão facilmente e não há substituto viável para ele.

Eu acho que casos de uso na vida real são usados ​​de maneira mais ocasional. Em grandes projetos, com várias centenas de casos de uso, os diagramas são difíceis de desenhar e oferecem pouco benefício sobre uma forma tabular. O BPMN para design de processos, mapeamento de histórias do usuário ou decomposição tabular de eventos no estilo Cockburn é muito mais usado. Por quê ? Porque eles são mais facilmente compartilhados com os usuários corporativos para resolver com eficiência os requisitos.

Tenho certeza de que são os locais onde a UML ainda é usada de maneira sistemática e pesada. Não imagino que softwares aeroespaciais ou sistemas de controle de usinas nucleares sejam produzidos sem o conjunto completo de documentação UML. Mas acredito que é mais a exceção do que a regra.

Sinto-me confirmado nesta declaração ao olhar nas livrarias. Há alguns anos, você podia encontrar muitos livros sobre a UML 2.0. Atualmente, se você procura a UML 2.5, a escolha é bastante restrita. Pior: muitos autores nem se esforçam para revisar seus livros anteriores para mantê-los atualizados (exemplo: a agradável introdução " UML destilada " de Fowler, que ainda data de 2003 com UML 2.0 e o mesmo para os elementos "de Ambler " do estilo UML 2.0 "!).

Eu não acho que essa tendência decrescente mude, olhando para a generalização do ágil e sua promoção de "Software funcionando sobre documentação abrangente".

No final, eu diria provocativamente que os métodos de modelagem parecem seguir um esquema darwinista: apenas a técnica de diagramação mais adequada sobreviverá, aquelas que fornecem uma clara vantagem sobre abordagens informais (por exemplo, ilustração de guardanapos) e código detalhado (por exemplo, por que desenhar um diagrama de atividades A1, quando o código correspondente poderia caber em uma folha A4?) ;-)

Por outro lado, ouvi de muitos graduados que a UML não parece mais ser usada nas trincheiras.

Todos eles são usados ​​na prática. Mas nem todos os usam. Algumas pessoas evitam inteiramente o design e passam direto para a codificação. Você não pode confiar em evidências anedóticas para saber o que "todo mundo" faz.

Ferramentas como UML funcionam melhor se você usar quando elas agregam valor ; por exemplo

• para projetos maiores
• para partes complicadas de um projeto
• quando o design do projeto requer entrada de várias pessoas

Criá-los apenas para fazê-los (ou porque o processo diz que você deve) não é produtivo. A melhor prática é ser seletivo sobre o que você diagrama e quais tipos você usa. Use UML quando e onde ajudar ... e isso inclui ser seletivo dos tipos de diagramas UML que você usa.

Além disso ... UML foi projetado principalmente como uma ferramenta de design. Não é tão eficaz (atualmente) como uma ferramenta de documentação. IDEs típicos ajudam a visualizar muitos aspectos se uma estrutura de base de código estiver em movimento. Isso geralmente é melhor do que depender de diagramas UML que podem ter se tornado desatualizados / imprecisos.

A UML ainda é usada nas trincheiras. Mas, como sempre, as pessoas usam um subconjunto dele. Qual subconjunto está sujeito aos problemas em questão.

A UML vem em várias versões. Mas, como sempre, as pessoas usam seus símbolos de maneira informal e inconstante.

UML é como entendemos muitos dos livros de padrões existentes. É também uma das maneiras de nos comunicarmos no quadro branco. Não se foi. Mas nunca será usado formalmente como código.

Em vez de produzir estudantes que possam corrigir qualquer diagrama UML para estar em conformidade com a versão 2.5 da UML , ou o que for mais recente, produza alunos que possam entender o que o diagrama está tentando se comunicar, mesmo que não seja totalmente consistente com uma versão UML específica, porque é como a UML é usada nas trincheiras. Ele vem em dialetos locais estranhos, misturados com outros sistemas, e às vezes criamos nossos próprios símbolos.

Ensine a eles que não há problema em perguntar o que as coisas significam. Não os ensine a corrigir outros que estão quebrando algumas regras imaginadas. Estamos apenas tentando nos comunicar aqui.

O melhor uso que eu já vi foi deixar um novo programador nos mostrar seu plano de resolver um problema. Ele rapidamente nos mostrou as partes do sistema que eles negligenciaram ou não perceberam que existiam.

Também trabalhei em locais que exigiam UML, mesmo quando não necessários. Estávamos sempre usando o mesmo padrão, então era apenas uma formalidade. Chegamos ao ponto em que apenas compramos novos nomes em diagramas antigos. Não incentive esse tipo de uso.

Mas acho que todos sabemos que há uma diferença entre a ponta da flecha normal e a ponta da flecha aberta. Certo?

Vou ser específico de acordo com a minha experiência: - Diagrama de implantação - Diagrama de sequência - Diagrama de classe Esses três são os mais usados ​​em qualquer projeto, pois fornecem valor real de comunicação com a equipe em diferentes níveis.