Quais são os benefícios de modelar sistemas de software versus fazer tudo em código?

A maioria, se não todas as pessoas de TI que conheço, acredita que é benéfico modelar software com UML ou outros tipos de diagramas antes da codificação. (Minha pergunta não é especificamente sobre a UML, pode ser qualquer descrição gráfica ou textual do design do software.)

Não tenho tanta certeza disso. O principal motivo é: o código não mente. É verificado pelo compilador ou intérprete. Esperançosamente, ele tem testes automatizados e precisa passar na análise de código estático. Se um módulo não faz interface corretamente com outro módulo, geralmente é óbvio no código porque você recebe uma mensagem de erro.

Tudo isso não pode ser feito com diagramas e outros documentos. Sim, existem ferramentas que verificam a UML, mas tudo o que vi até agora é muito limitado. Portanto, esses documentos tendem a ser incompletos, inconsistentes ou simpy false.

Mesmo se os diagramas em si forem consistentes, você não pode ter certeza de que o código realmente os implementa. Sim, existem geradores de código, mas eles nunca geram todo o código.

Às vezes, sinto que a obsessão com a modelagem resulta da suposição de que o código inevitavelmente deve ser uma bagunça incompreensível com a qual os arquitetos, designers ou outras pessoas bem pagas que entendem o cenário não devam lidar. Caso contrário, ficaria muito caro. Portanto, todas as decisões de design devem ser afastadas do código. O próprio código deve ser deixado para especialistas (macacos de código) que são capazes de escrever (e talvez ler), mas não precisam lidar com mais nada. Isso provavelmente fez sentido quando o assembler era a única opção, mas as linguagens modernas permitem codificar com um nível muito alto de abstração. Portanto, não vejo mais a necessidade de modelar.

Que argumentos estou faltando para modelar sistemas de software?

A propósito, acredito que os diagramas são uma ótima maneira de documentar e comunicar certos aspectos do design de software, mas isso não significa que devemos basear o design de software neles.

Esclarecimento:

A questão foi colocada em espera por não ser clara. Portanto, deixe-me adicionar uma explicação:

Estou perguntando se faz sentido usar documentos (sem código) que modelam o software como a principal fonte de verdade sobre o design de software. Não tenho em mente que uma parte significativa do código seja gerada automaticamente a partir desses documentos. Se fosse esse o caso, eu consideraria os próprios documentos como código-fonte e não como modelo.

Listei algumas desvantagens desse procedimento que me fazem pensar por que tantas pessoas (na minha experiência) o consideram a maneira preferível de criar design de software.

O benefício da modelagem de sistemas de software versus tudo no código é: Eu posso encaixar o modelo em um quadro branco.

Eu acredito muito na mágica de me comunicar em uma folha de papel. Se eu tentasse colocar código no quadro branco, ao ensinar nosso sistema a novos codificadores, simplesmente não há código no nível de abstração necessário que caiba em um quadro branco.

Conheço a obsessão com a modelagem a que você está se referindo. Pessoas fazendo coisas porque é assim que foram feitas antes, sem pensar no porquê de fazerem isso. Eu vim chamar isso de formalismo. Prefiro trabalhar informalmente porque é mais difícil esconder a tolice por trás da tradição.

Isso não significa que não vou sacar um esboço UML de vez em quando. Mas nunca serei o cara exigindo que você entregue um documento UML antes de poder codificar. Eu posso exigir que você dedique 5 minutos e encontre ALGUM modo de explicar o que está fazendo, porque eu não suporto a existência de código que apenas uma pessoa entende.

Fowler identificou diferentes maneiras pelas quais as pessoas usam a UML que ele chamou de modos UML . O mais perigoso de todos eles é que eles podem ser usados ​​para esconder o trabalho útil. Se você estiver fazendo isso para codificar usando o mouse, já vi muitas tentativas. Não vi ninguém fazer isso realmente funcionar. Se você está fazendo isso para se comunicar, é melhor garantir que outras pessoas o entendam. Se você está fazendo isso para projetar, é melhor encontrar e corrigir problemas enquanto trabalha. Se tudo estiver indo bem e passar a maior parte do tempo fazendo as flechas parecerem boas, pare com isso e volte ao trabalho.

Mais importante ainda, não produza diagramas que você espera que sejam válidos mais de um dia. Se você puder de alguma forma, você falhou. Porque o software deve ser macio. Não gaste semanas recebendo os diagramas corretamente. Apenas me diga o que está acontecendo. Se for necessário, use um guardanapo.

Dito isto, prefiro codificadores que conhecem seus padrões de design e UML. Eles são mais fáceis de se comunicar. Desde que saibam que produzir diagramas não é um trabalho de período integral.

Estou perguntando se faz sentido usar documentos (sem código) que modelam o software como a principal fonte de verdade sobre o design de software

Não. Isso nunca faz sentido. Seu código é o seu principal documento de design, ou seja, "a principal fonte de verdade sobre o design de software". Somente o código descreve exatamente o que o aplicativo faz quando o compilador pega esse design e cria o aplicativo a partir dele.

Por todos os meios, use diagramas como documentos suplementares de design, embora, se não forem gerados automaticamente a partir do código, tenha cuidado ao contar uma história diferente ao design real. Se a UML flutuar no seu barco, use isso. Caso contrário, use outra coisa.

Algumas pessoas acham útil esboçar seu pensamento na forma de diagrama antes de começar a escrever o código. Mas lembre-se do que o tio Bob disse sobre esse assunto:

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

Se você usa a UML para explorar um design, jogue-o fora quando começar a codificar. Escreva um teste e depois escreva algum código para fazê-lo passar. Repetir. Dessa forma, você terá um design validado. A UML nunca pode oferecer a você o mesmo nível de validação do seu design.

A maioria, se não todas as pessoas de TI que conheço, acredita que é benéfico modelar software com UML ou outros tipos de diagramas antes da codificação.

Não discordo de que todas as pessoas que você conhece acreditam nisso, mas não acho que isso seja necessariamente comum. Em 1970, Winston Royce sabia que o desenvolvimento de software tinha algum nível de iteração entre as atividades de design e código. Em 1992, Jack Reeves escreveu sobre a codificação como a verdadeira atividade de design (também discutida no C2 Wiki ).

Isso não significa que as pessoas tentaram criar ferramentas de desenvolvimento orientadas a modelos. Existem ferramentas que tentam gerar código a partir de modelos UML (e não apenas diagramas de classes, mas vinculando vários tipos de diagrama e gerando código a partir deles). Mas essas não são, pelo menos pelo que vi, ferramentas amplamente usadas.

Isso também não significa que você deve ir diretamente dos requisitos para escrever o código. Existem certas decisões de design que são críticas para acertar cedo e algum nível de modelagem pode ser útil para garantir que todos entendam as opções, seu impacto e possam se comunicar. Algumas pessoas (inclusive eu) chamam isso de "arquitetura de software" .

Código não mente. É verificado pelo compilador ou intérprete. Esperançosamente, ele tem testes automatizados e precisa passar na análise de código estático. Se um módulo não faz interface corretamente com outro módulo, geralmente é óbvio no código porque você recebe uma mensagem de erro.

Esse é realmente o coração de alguns dos aspectos da modelagem ágil, especialmente as especificações executáveis e a fonte única de informações . Não concordo necessariamente com o TDD, mas a idéia de ter seu código e testes associados (da unidade à testes de aceitação, de preferência capturados como testes automatizados) como a única fonte de verdade é uma boa idéia.

Mesmo se os diagramas em si forem consistentes, você não pode ter certeza de que o código realmente os implementa. Sim, existem geradores de código, mas eles nunca geram todo o código.

Eu acho que, como regra geral, passar do modelo-> código é o caminho errado. Em vez disso, o código deve gerar modelos. Ou seja, as ferramentas devem poder examinar o código e gerar representações gráficas e tabulares que podem ser aprimoradas ainda mais à medida que os engenheiros escrevem texto ao seu redor. E essa geração de modelos a partir do código deve ser parte integrante de um processo de criação e lançamento.

Existem ferramentas que, em diferentes graus, suportam isso em vários idiomas. Dada a natureza das linguagens e paradigmas, é mais fácil para alguns do que para outros.

Listei algumas desvantagens desse procedimento que me fazem pensar por que tantas pessoas (na minha experiência) o consideram a maneira preferível de criar design de software.

Eu não acho que essas pessoas necessariamente entendam engenharia de software e design de software. Eu acho que essas pessoas estão olhando para o que outras disciplinas de engenharia fazem e mapeando-as para as coisas que eles acham que os engenheiros de software devem fazer. Mas eles estão ignorando uma grande diferença. Outras disciplinas de engenharia criam modelos e simulações primeiro porque é extremamente caro e demorado construir o produto real. Na engenharia de software, podemos pegar partes do nosso design e produzir algo que possa ser testado em um ambiente do mundo real em muito pouco tempo e com muito pouco custo. A economia é muito diferente.

Quais são os benefícios de modelar sistemas de software versus fazer tudo em código?

Quando você tem um sistema de software extremamente complexo, ter modelos significa ter algo mais fácil de entender. É um nível diferente de abstração, algo para ajudar as pessoas a entender várias facetas do seu sistema. É uma das razões pelas quais existem tantas linguagens de modelagem diferentes e tipos diferentes de modelos permitidos por cada linguagem ou notação de modelagem - para permitir que diferentes partes interessadas entendam, conceitualmente, o sistema de software de maneira rápida e fácil.

Estou perguntando se faz sentido usar documentos (sem código) que modelam o software como a principal fonte de verdade sobre o design de software. Não tenho em mente que uma parte significativa do código seja gerada automaticamente a partir desses documentos. Se fosse esse o caso, eu consideraria os próprios documentos como código-fonte e não como modelo.

Muitos documentos que não são de código são úteis como projetos . Ou seja, a "verdade" do design deve seguir essa direção. É uma maneira de modelar elementos que um design deve atender. Você poderia chamá-los de documentos de requisitos, mas isso talvez seja forte demais em todos os exemplos que eu poderia dar. Eu usei o PlantUML via PlantText.com para produzi-los.

• Os diagramas de casos de uso podem mostrar os recursos e interações pretendidos com usuários ou sistemas externos.

• Os diagramas de atividades podem mostrar os processos de negócios que um software precisa suportar.

• Os diagramas de estado podem mostrar a dinâmica pretendida em um site:

• Os padrões de design do Gang of Four são apresentados como modelos estáticos e dinâmicos. Por exemplo, Memento:
  
  

Listei algumas desvantagens desse procedimento que me fazem pensar por que tantas pessoas (na minha experiência) o consideram a maneira preferível de criar design de software.

Se você estiver interessado em algumas informações reais sobre o uso da UML fora da sua experiência, existem alguns estudos que foram realizados (tentei encontrar links para artigos que não são de paywall):

• Petre, Marian (2013). UML na prática . In: 35ª Conferência Internacional de Engenharia de Software (ICSE 2013), 18-26 de maio de 2013, San Francisco, CA, EUA, pp. 722-731.
• N. Mangano, TD LaToza, M. Petre e A. van der Hoek (2015). Como os designers de software interagem com os esboços no quadro branco . In: Transações IEEE sobre Engenharia de Software, vol. 41, n. 2, pp. 135-156.
• Andrew Forward e Timothy C. Lethbridge. 2008. Problemas e oportunidades para o desenvolvimento de software centralizado em modelo versus centralizado em código: uma pesquisa com profissionais de software . Em Anais do workshop internacional de 2008 sobre Modelos em engenharia de software (MiSE '08). ACM, Nova York, NY, EUA, 27-32.

Nós desenvolvedores adoramos usar imagens para explicar nosso mundo, então aqui está um com a produção de um carro:

• O carro é o resultado da cadeia de produção, o mesmo para o código (adicione o processo de implantação, é claro).
• O documento de design do carro é o mesmo que o documento de design do software.

Em nossos mundos, geralmente acontece que aqueles que concebem e produzem o documento de design são os mesmos que os que produzem o código. Isso não é verdade nos outros campos. No entanto, isso não significa que você realmente é capaz de obter o mesmo nível de qualidade, fazendo todos juntos.

Criando esses documentos primeiro sem codificação (excluindo qualquer coisa como uma prova de conceito de fasabilidade, ...):

• Você tem certeza de pensar antes de fazer a codificação, uma vez que você sabe o que precisa fazer é FÁCIL.
• Você é capaz de colocar as pessoas mais experientes focadas na parte mais difícil do seu software: design, algoritmo / matemática é qualquer, exceto para fins muito específicos (incorporado, em tempo real, montagem).
• Você pode delegar para pessoas menos experientes uma boa parte do processo de codificação, enquanto as pessoas mais experientes focam apenas na parte mais crítica que precisa do nível de suas habilidades. As pessoas menos experientes aprenderão muito sobre isso.
• Você pode discutir com pessoas que não são de TI através da imagem do seu documento de design, enquanto se você tivesse apenas código, teria que extrair uma imagem do que fez, com todo o risco de esquecer algo (um ouvinte esquecido em algum lugar ...). Veja a resposta de CandiedOrange para mais aspectos sobre comunicação.
• Quando você precisa fazer o seu software evoluir, pode antecipar melhor o que será impactado.
• O design facilitará o corte de parte do seu software e o desenvolvimento simultâneo de partes do software.
• Escrever esses malditos testes de unidade reberbativa será muito mais fácil quando você não precisar ter dores de cabeça por ter que cobrir todos os casos enquanto os codifica, em uma abordagem TDD que codifica o teste antes que o código seja fácil.
• ...

Nota: essas afirmações supõem que o código é realmente o reflexo do design e os dois se mantêm atualizados ...