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


20

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.



5
Eu acho que é uma pergunta completamente válida. Se nosso modelo tiver algum valor, ele deverá corresponder ao código. Então, por que não projetar o modelo na mesma linguagem que usamos mais tarde para implementá-lo? Então eles estão sempre sincronizados. E se você preferir gráficos sofisticados, eles podem ser gerados a partir do código.
Ralf Kleberhoff

3
Você deve conhecer mais pessoas de "TI" então. Ou talvez eu deva dizer, você deve se familiarizar com mais comunidades dentro desse guarda-chuva.
Derek Elkins

@DocBrown: Embora as respostas para essa pergunta e especialmente os artigos vinculados no seu comentário forneçam informações relevantes, a pergunta original é muito diferente.
Frank soprador

@FrankPuffer: Estou ciente disso, votei para reabrir. Não obstante, acho que o cerne da sua pergunta - "o que é design de software" e "o papel da modelagem no design de software" é uma pergunta muito ampla, talvez muito ampla para ser respondida aqui de maneira sensata.
Doc Brown

Respostas:


23

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.


2
"simplesmente não existe código nesse nível de abstração que caiba em um quadro branco". Isso traz uma pergunta interessante. Por que não? O que teria que ser verdade para o ponto de entrada de um sistema para explicar em um nível muito alto o que ele faz?
precisa

2
Porque o código deve ser tudo para todas as pessoas (e pelo menos um compilador). Um modelo pode ter uma audiência focada.
Candied_orange

Eu acho que usar a palavra "formalismo" para isso é lamentável. Ou infla demais o que os "modeladores" estão fazendo, ou deprecia a modelagem formal real . (Também não parece realmente capturar sua intenção do que posso dizer aqui. Sua preocupação não parece ser com a modelagem em si, mas com usá-la como um portão ou por razões burocráticas, mesmo quando não está agregando valor.)
Derek Elkins

3
Meu problema não está na modelagem. É com o uso de cerimônias formais como substituto do pensamento crítico. Estou tentando dizer que muito do bashing do modelo acontece porque grande parte da modelagem se encaixou nessa multidão. Modelagem pode ser muito boa. Mas tem um lado sombrio.
Candied_orange 16/08/19

1
"Eu posso encaixar o modelo em um quadro branco" é uma maneira muito concreta (excelente!) De dizer "Eu posso fazer uma abstração de algo que é mais complicado para ajudar a entender ou comunicar o aspecto que considero importante". É o que a boa modelagem faz em geral, seja software ou qualquer outra coisa complexa.
Fuhrmanator

6

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.


Um exemplo de contador (?) :: separação de visualização de modelo (ou qualquer padrão GoF) pode ser facilmente desenhado como uma verdade de design pretendida (blueprint) proposta por um arquiteto. Os desenvolvedores que se desviam dessa intenção não tornam inútil o modelo (pretendido). Sim, o código é a "verdade", mas não é necessariamente o design. A validação não precisa ser automática com UML ou algum modelo. O fato de não ser, não torna um modelo digno de lixo.
Fuhrmanator 16/08/19

Quanto aos testes, não tenho certeza se é útil validar um design. Você pode escrever testes que mostram que a lógica do domínio não está na camada de apresentação (um problema muito comum nas implementações que se desviam do design pretendido)? Mostrar um diagrama das camadas para um desenvolvedor e explicar que um actionPerformed()método está na camada de apresentação e que ele deve simplesmente passar o controle para a camada de domínio é um aspecto essencial da separação. (Exemplo trivial, mas pode ser aplicado a todos os tipos de estratégias de design que não são fáceis de mostrar apenas no código).
Fuhrmanator

5

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.


5

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. insira a descrição da imagem aqui

  • Os diagramas de atividades podem mostrar os processos de negócios que um software precisa suportar. insira a descrição da imagem aqui

  • Os diagramas de estado podem mostrar a dinâmica pretendida em um site: insira a descrição da imagem aqui

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

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):


0

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 ...


Esta resposta descreve um cenário quase sempre melhor. Você menciona uma ressalva no final que é bastante grande por si só. Existem muitos outros. Você pode omitir facilmente os aspectos necessários, subestimar a complexidade de alguma parte, sem levar em consideração as restrições que as bibliotecas / estruturas que você impõe, sem levar em conta bugs nas dependências, sem levar em conta o desempenho ou outros requisitos não funcionais, por engenharia, falham em antecipar mudanças ou simplesmente não são tão bons em design. É improvável que esse cenário de melhor caso seja realizado, aproximadamente em um contexto profissional.
Derek Elkins

Se você começar considerando apenas todas as advertências de tudo, não irá a lugar nenhum. Qualquer que seja o método que você use. E uma longa lista do que você disse é perfeitamente válida ao fazer apenas código.
Walfrat 17/08/19
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.