Por que é inadequado usar diagramas UML para planejar como seu código será organizado?

Portanto, sim, os diagramas podem ser inadequados às vezes. Quando eles são inapropriados? Quando você os cria sem código para validá-los e pretende segui-los. Não há nada errado em desenhar um diagrama para explorar uma ideia.

_{Desenvolvimento Ágil de Software: Princípios, Padrões e Práticas - Robert C. Martin}

O que exatamente ele quis dizer com isso? A UML não foi projetada para ajudar a planejar como estruturar seu código antes de "mergulhar"? Qual é o sentido de usá-lo se você não seguir os diagramas apresentados?

Contexto: Neste capítulo, o tio Bob faz um diagrama UML para o Score Keeper de um jogo de boliche. Em seguida, ele desenvolve o programa de maneira orientada a testes, sem consultar o diagrama UML. O programa resultante não se parece com o diagrama da UML, e o tio Bob chega à conclusão citada acima.

— q126y
fonte

O argumento do tio Bob é que a arquitetura que emerge do desenvolvimento orientado a testes pode diferir radicalmente do diagrama UML.

— Robert Harvey

Leia também: O design está morto? Por Martin Fowler para uma discussão equilibrada do tema e do movimento ágil

— Eliezer Steinbock

A votação desta pergunta foi feita em resposta a um julgamento ruim por parte de @RobertHarvey et al. Na votação para encerrar o que é uma pergunta importante e útil.

— David Arno

@DavidArno Se você tem uma opinião forte sobre o que deve ou não ser fechado, eu encorajo você a se envolver nas discussões em nosso meta site. Todo mundo que atualmente publica lá (incluindo eu) provavelmente se enquadra em "@RobertHarvey et al", exceto por alguns funcionários da SE, e estamos preocupados com a possibilidade de outro ponto de vista não ser representado, mas até agora ninguém apareceu para representá-lo .

— Ixrec

@Ixrec, eu nunca me envolvi com meta-discussões antes, exceto uma vez para verificar se eu poderia me referir às minhas próprias bibliotecas de código-fonte aberto em respostas (a resposta para isso era que eu poderia). Talvez eu deva seguir seu conselho e me envolver mais. Obrigado pela sugestão.

— David Arno

Respostas:

Para explicar isso corretamente, precisamos de uma breve lição de história. Nos primeiros dias da engenharia de software, uma analogia frequentemente usada era a construção de uma casa. Um arquiteto e engenheiro estrutural discute os planos com um cliente e cria um design. Os construtores seguem esse projeto para construir a casa real. Escrever código era visto como o equivalente à construção da casa real. Portanto, havia uma necessidade percebida de design antecipado antes que a compilação pudesse ocorrer. Várias ferramentas de design gráfico foram criadas, sendo a UML uma delas.

A ideia originalmente da UML era que alguém projetasse completamente um sistema com a UML e passasse para os codificadores para traduzir esse design em código. Na realidade, isso simplesmente não funciona e levou anos de programadores a serem vistos como "implementadores", em vez de "designers", projetos atrasados, os projetos precisando mudar constantemente depois que deveriam estar completos etc.

O motivo é simples. Codificação é design . Com a analogia da casa, o código são os desenhos do arquiteto. O compilador é o construtor que pega esses designs e cria um programa a partir deles. Essa percepção levou a técnicas ágeis, TDD etc: ferramentas para ajudar a melhorar a qualidade desse design de código.

Assim como um arquiteto pode produzir esboços preliminares para ajudar ela e sua equipe a visualizar o design geral, um desenvolvedor pode usar UML ou outras ferramentas para ajudar a visualizar o design necessário. Assim como esses esboços não são seguidos às cegas, a UML não deve ser seguida às cegas. O design do código deve evoluir a partir de iterações ágeis e usando TDD. Da mesma forma, assim como um arquiteto pode construir um modelo da casa para ajudar ela e sua equipe a visualizar os desenhos, a UML pode ser usada para ajudar a visualizar a estrutura do código.

Como o tio Bob diz, você não pode validar a UML, mas apenas o código. Portanto, o código é a documentação de design principal e a UML, se usada, é apenas uma documentação secundária.

— David Arno
fonte

Eu tinha uma parte do telhado da minha casa levantada no início deste ano e foi bastante educativa. O arquiteto realmente não fez mais que desenhar como deveria ser o produto final. Ele entregou os cálculos e o projeto estrutural a um engenheiro de construção. Os construtores tiveram que combinar os projetos teóricos com a realidade da casa (uma vez que a placa de gesso estava desligada, as vigas foram encontradas em locais ligeiramente diferentes), de modo que o projeto estava ocorrendo a cada passo.

— Jaydee

Esta é uma resposta útil, no entanto, simplifica demais alguns aspectos. Uma das principais razões pelas quais a UML não funciona bem como uma "notação de design de alto nível" é IMHO, seus inventores eram muito teimosos para adicionar um diagrama de fluxo de dados. Esse é o único tipo de notação que conheço que serve para o design das principais cidades, permitindo expressar abstrações para componentes e interfaces entre eles de diferentes escalas, e também pode ter um mapeamento bem definido para o código. Em vez disso, a UML contém muitas bobagens das quais ninguém realmente precisa.

— Doc Brown

Eu acho que nem todo idioma de programação (ou design ou código) se encaixa na UML (que eu admito que não conheço bem - apenas li alguns livros sobre ele -, eu nunca o usei e provavelmente não gosto).

O código C simples (por exemplo, o código-fonte do kernel Linux) pode não ser exatamente modelado pela UML.

O código Ocaml (com seus módulos e functores) ou mesmo o código C ++ 11 (com lambdas e modelos) pode não se encaixar na UML.

A programação em vários estágios no MetaOcaml provavelmente não se encaixa na UML.

O código de prólogo ou o código Common Lisp provavelmente não se encaixa na UML.

Veja também esta resposta e esta minha pergunta.

Leia os livros Pragmática da linguagem de programação de Scott e Conceitos, técnicas e modelos de programação de computadores de Van Roy , e pergunte a si mesmo se todos os modelos de programação ali se encaixam na UML.

Veja também Is Design Dead, de Martin Fowler ? blog.

— Basile Starynkevitch
fonte