Por que não podemos capturar o design do software com mais eficiência? [fechadas]


14

Como engenheiros, todos nós "projetamos" artefatos (edifícios, programas, circuitos, moléculas ...). Essa é uma atividade (projetar o verbo) que produz algum tipo de resultado (projetar o substantivo).

Acho que todos concordamos que projetar o substantivo é uma entidade diferente do próprio artefato.

Uma atividade importante nos negócios de software (de fato, em qualquer negócio em que o artefato resultante do produto precise ser aprimorado) é entender o "design (o substantivo)". No entanto, como comunidade, parecemos falhas praticamente completas ao registrá-lo, como evidenciado pela quantidade de esforço que as pessoas enviam para redescobrir fatos sobre sua base de códigos. Peça a alguém para mostrar o design do código e ver o que você recebe.

Penso em um design para software como tendo:

  • Uma especificação explícita para o que o software deve fazer e quão bem ele faz
  • Uma versão explícita do código (esta parte é fácil, todo mundo tem)
  • Uma explicação de como cada parte do código serve para alcançar a especificação (por exemplo, uma relação entre fragmentos de especificação e fragmentos de código)
  • Uma justificativa para o porquê do código ser do jeito que é (por exemplo, por que uma escolha específica e não outra)

O que NÃO é um design é uma perspectiva específica do código. Por exemplo [para não selecionar especificamente] diagramas UML não são modelos. Em vez disso, são propriedades que você pode derivar do código ou, sem dúvida, propriedades que você deseja derivar do código. Mas, como regra geral, você não pode derivar o código da UML.

Por que, após mais de 50 anos de construção de software, por que não temos maneiras regulares de expressar isso? (Fique à vontade para me contradizer com exemplos explícitos!)

Mesmo se o fizermos, a maioria da comunidade parece tão focada em obter "código" que o design do substantivo se perde de qualquer maneira. (IMHO, até que o design se torne o objetivo da engenharia, com o artefato extraído do design, não vamos contornar isso).

O que você viu como meio para gravar projetos (no sentido que eu descrevi)? Referências explícitas a artigos seriam boas. Por que você acha que meios específicos e gerais não foram bem-sucedidos? Como podemos mudar isso?

[Tenho minhas próprias idéias que realçam o ponto de vista com marcadores acima, mas estou interessado nas respostas de outras pessoas ... e é difícil implementar meu esquema [[e talvez esse seja o verdadeiro problema: -]]]

EDIT 2011/1/3: Um dos tópicos de resposta sugere que a "documentação" (presumivelmente textual, em particular não formal) pode ser adequada. Acho que devo esclarecer que não acredito nisso. As ferramentas CASE apareceram em cena nos anos 80, mas as ferramentas mais antigas capturavam pixels para os diagramas do que você desenhou; embora as ferramentas tenham um sucesso comercial comprovável, elas realmente não foram muito úteis. Um insight importante foi que, se os artefatos adicionais de "design" não forem formalmente interpretáveis, você não poderá obter nenhuma ajuda séria da ferramenta. Acredito que o mesmo insight se aplique a qualquer forma útil de captura de design a longo prazo: se não tiver uma estrutura formal, não será de uso real. Documentos de texto praticamente falham neste teste.


1
Concordou com a UML - uma ferramenta de comunicação, na melhor das hipóteses, contribuindo para a descrição do design, mas não por si só o design. Na pior das hipóteses, UML é um código fonte gráfico.
Steve314

quantificar "quão bem ele faz"
Steven A. Lowe

Quando construo sistemas, atendi a muitos requisitos "não funcionais": codificados nesta linguagem, usam esse banco de dados, manipulam registros 1E10 com tempo médio de resposta de 100 ms, ... Você não pode deixá-los fora da especificação. (Sem requisitos não funcionais, um loop permanente é um programa adequado para qualquer especificação funcional). Meu ponto principal sobre a captura de "design" é lidar com outro requisito não-funcional: "manutenível".
Ira Baxter

Sua discussão parece interessante, mas ainda não tenho certeza sobre o que exatamente é a pergunta. Você acha que poderia tentar dar algo como um exemplo concreto ou algo para esclarecer exatamente o que você está interessado? Estou pensando em algo como o exemplo da FFT, onde você pode dar uma visão completa dos quatro pontos da sua pergunta como você os vê e talvez que tipo de coisas você gostaria de fazer com os resultados capturados.
N1ckp

Não tenho idéia dos porquês desta edição, mas é o assunto de Fred Brooks, 'The Design of Design' . (Desculpas, se você já estiver familiarizado.) Ele discute exemplos de programação e arquitetura. Ele observa particularmente que capturar justificativas (tanto para o design quanto para projetos alternativos rejeitados) é realmente útil e não é bem atendido pelas ferramentas atuais.
Paul D. Waite

Respostas:


8

Eu acho que existem várias razões pelas quais ainda não somos bons nisso.

  1. As pessoas, por um longo tempo, apesar de o software ser como casas, estavam usando processos e idéias da construção. "Arquiteto de software" era um título que todos os programadores queriam. Nos últimos dez anos, o arquiteto de software quase desapareceu. A ideia dos processos em cascata nos quais você primeiro tem um arquiteto dizendo como o software deve funcionar e sua aparência e, depois, leva as pessoas a fazer diagramas de como devem ser construídos e, por último, o código monkey implementando esses bons fluxos de trabalho / diagramas UML para especificar, essa ideia é agora amplamente ridicularizado. Então, de fato, toda a indústria estava latindo no caminho errado por 40 anos.

  2. As ferramentas que usamos mudam e melhoram constantemente. A programação é um quebra-cabeça lógico e criamos melhores idéias e técnicas para abstraí-lo e torná-lo compreensível. A maneira como modelamos isso deve evoluir na mesma velocidade, mas fica para trás. As técnicas aprimoradas para abstrair o quebra-cabeça da programação também significa que podemos aumentar a complexidade. E nós também. A programação sempre está nos limites da complexidade que nós, como programadores, podemos lidar.

  3. Criar maneiras de descrever o programa é uma espécie de abstração. Se pudermos encontrar uma boa maneira de abstrair o software, também podemos colocar essa abstração diretamente nas ferramentas de desenvolvimento e, portanto, adicionar outra abstração / simplificação à programação. Isso já aconteceu muitas vezes. Exemplos de tais abstrações são funções, classes e bibliotecas.

  4. Portanto; Se você tiver um modelo bem - sucedido e preciso do software, esse modelo será equivalente ao software. O que torna o esforço inútil, o que corrobora o ponto 1 acima: modelar o software é muito menos útil do que se pensava anteriormente. É melhor extrair dados sobre o software a partir do código. Criar um modelo UML a partir da aparência do código é muito mais esclarecedor do que criar um modelo UML e tentar implementar esse modelo teórico.


2
Não concorde com o seu último ponto. Sim, será bastante equivalente ao software, mas ainda é mais fácil redesenhar um modelo do que refatorar o software real quando (não se) você descobrir que algo não era uma boa idéia, afinal. Eu não subestimaria a importância da etapa de design.
Joris Meys

1
@Joris Meys: O problema é que você não saberá o que é e o que não é uma boa ideia até implementá-la. (Exceto em casos triviais, mas você não terá muito uso de um diagrama UML). Além disso, você não deve superestimar o quão difícil é refatorar o código. Eu recomendo ler os livros de Kent Becks sobre XP e Test Driven Design.
Lennart Regebro

@Lennart: thx for the tip
Joris Meys

2
@Lennart: A diferença entre você e Jó é que você parece concordar que uma especificação expressa de alguma forma pode ser necessária, embora eu não saiba como o seu conjunto de abstrações atualmente programáveis ​​faz isso. Mas imagine que eu preciso de um programa de processamento de sinal que extraia as principais frequências. Observe que eu não sugeri como. Você pode optar por usar uma Fast Fourier Transform, e certamente encontrarei pegadas em todo o código que implementa bits FFT. Mas onde está o fato de você ter decidido usar uma FFT gravada explicitamente? Acredito que você precisa, a menos que seus leitores sejam oniscientes.
Ira Baxter

1
@Ira Baxter: Que tal "Optamos por implementar o processamento de sinal com FFT"? O código fonte tem comentários, você sabe. E também posso escrevê-lo em um arquivo README. A expressão explícita da especificação é o código. Linhas de texto como "Optamos por implementá-lo com FFT" não são explícitas, nem projetam no sentido de sua postagem original. É documentação da implementação. Você parece ter acabado em um modo argumentativo, mas eu não entendo o que você está tentando argumentar.
Lennart Regebro

5

Você pode estar interessado em revisar a literatura de rastreabilidade do software. Em nenhuma ordem particular:

  • CUBRANIC, D., MURPHY, GC, SINGER, J. E BOOTH KELLOGG, S. Hipikat: uma memória de projeto para desenvolvimento de software. Transactions on Software Engineering 31, 6 (2005), 446–65.
  • TANG, A., BABAR, MA, GORTON, I. E HAN, J. Uma pesquisa sobre o uso e a documentação da lógica do design da arquitetura. Em Proc da 5ª Conferência IEEE / IFIP de Trabalho sobre Arquitetura de Software (2005).
  • RAMESH, B., POWERS, T., STUBBS, C. E EDWARDS, M. Implementando a rastreabilidade de requisitos: Um estudo de caso. Em Proc do Symp Internacional sobre Engenharia de Requisitos (York, 1995).
  • HORNER, J. E ATWOOD, ME Fundamentação do design: fundamentos e barreiras. Em Proc da 4ª Conferência Nórdica sobre Interação Humano-Computador: Mudando de Papel (Oslo, Noruega, 2006).
  • CLELAND-HUANG, J., SETTIMI, R., ROMANOVA, E., BERENBACH, B. E CLARK, S. Melhores práticas para rastreabilidade automatizada. Computador 40, 6 (junho de 2007), 27–35.
  • ASUNCION, H., FRANÇOIS, F. E TAYLOR, RN Uma ferramenta de rastreabilidade de software industrial de ponta a ponta. No Proc da 6ª Reunião Conjunta da European Software Eng Conf e do ACM SIGSOFT Int'l Symp sobre os Fundamentos da Engenharia de Software (ESEC / FSE) (Dubrovnik, 2007).

Observe que essa é apenas a ponta do iceberg e tenho certeza de que deixei de fora alguns documentos importantes.

Em uma nota separada, meu próprio trabalho no Arcum foi um meio para os programadores expressarem no IDE o uso de expressões cruzadas de design. Uma vez expressos, os programadores poderiam transformar seu código-fonte para usar implementações alternativas:

Aliás, o Arcum também está relacionado ao seu trabalho no DMS.


1
+1 para isso. RT não é tudo, mas é um dos vários passos positivos para resolver o problema em vez de inventar as mesmas velhas desculpas.
Aaronaught 02/01

2

UML é para um programa quais são os planos para um edifício na minha visão humbe. Os planos por si só não são um projeto fora do curso, você precisa de especificações de material (ferramentas de código usadas) para isso, uma visão geral do edifício (alguma representação esquemática de todo o software, incluindo projetos de GUI), como o edifício é plantado nos arredores (um esquema claro de como o software interage com os outros / é plantado no sistema operacional), como ele se destaca no clima e no solo (interação com o hardware), ... Muitos livros sobre design tentam defini-lo, mas como muitas coisas na ciência, todo cientista tem um pouco sua própria definição.

Agora, também não concordo com sua observação de que você não pode derivar o código da UML. Você pode, se tiver as informações adicionais mencionadas. Mas o código real não é mais o design, é o artefato. Também não é possível extrair as pedras e o concreto reais de um plano, mas você precisa colocar as pedras e o concreto reais na forma e no local corretos.

Nessa perspectiva, achei o seguinte artigo interessante (eu o conheci em um contexto diferente quando estava procurando por software gráfico, mas mesmo assim ...). A abordagem gráfica para descrever um design fazia sentido para mim, embora, novamente, isso seja apenas parte do design na minha opinião. O interessante é que essa abordagem fornece uma estrutura para entender e refatorar projetos (em vez de refatorar o software), conforme indicado nos seguintes documentos:

Existem várias outras abordagens para descrever (parte do) design, como design estruturado (HIPO Charts) ou design de programa integrado , padrões de design , ...

Ainda assim, desde que não haja um conjunto de padrões do setor, é improvável que haja uma maneira "regular" de expressar isso. Mesmo após mais de 50 anos. E seja honesto, se sua empresa encontrar uma boa maneira de expressar um design, você o compartilharia com o mundo?


Se sua empresa encontrar uma boa maneira de fazer isso, os programadores diriam a todos os demais rapidamente. :-)
Lennart Regebro

Acho que você perdeu meu argumento sobre a UML (e qualquer outra notação "única"). O código UML antes é uma restrição sobre como você deseja criar o software. O mesmo acontece com todas as outras notações (sim, eu já vi muitas delas, já estou aqui há algum tempo). Dada uma restrição, é sem dúvida possível produzir código que atenda a essa restrição (método de brincadeira: produza todos os programas possíveis e verifique se quais correspondem à restrição, escolha um deles). Nesse sentido, você pode "gerar código a partir da UML". Mas (se ater a diagramas de classe) que o código não vai implementar a função que deseja ...
Ira Baxter

... e a maioria dos outros esquemas de notação também sofrem com isso, eles realmente não capturam uma especificação do que o programa deve fazer. Nem fornecem algo como uma justificativa; por que seu gráfico UML tem a forma que está? Que parte do código posso alterar sem quebrar o gráfico? Posso mudar de uma maneira que não prejudique a intenção por trás do gráfico?
Ira Baxter

@Ira: Depois de visitar sua página, ficou mais claro para mim. Mas tenho que admitir que uma discussão semântica de alto nível sobre esses assuntos está além da minha experiência. No entanto, se você considerar o código real como parte do design, onde está o artefato real? UML - ou qualquer outra notação - é, na minha humilde opinião, um modelo da estrutura de código, e é algo que eu gosto de chamar de parte do design. Mais do que o código real de fato. cuide da parte . Não é o design, mas ainda é uma contribuição essencial para ele. novamente, na minha humilde opinião. A justificativa etc. pode ser adicionada a isso, conforme explicado.
Joris Meys

@Joris: A maioria das notações diagramáticas pode ser considerada como projeção (artefato inferido) a partir do código (pelo menos após a conclusão) ou como orientação para a construção do código (blueprint). Existem muitos diagramas possíveis (alguns listados na sua resposta). Quais são fundamentais para o código que você possui e quais são apenas acidentes? Os fluxogramas são digramas, portanto, eles devem se qualificar; no entanto, estou bastante confiante de que fluxogramas de algum pedaço de código não seriam considerados parte de seu design. Então, o que é fundamental? O que é acidental?
Ira Baxter

2

De minha própria experiência pessoal, eu argumentaria que somos bons em capturar o design do software. Temos um banco de dados de requisitos e documentos de design para todos os recursos que já implementamos em nossa plataforma. Suponho que minha circunstância seja única. Aqui estão algumas coisas em que pensar.

Cada pessoa da minha equipe tem um diploma de engenharia ... principalmente EE ou CE. Engenharia ensina a projetar como parte do currículo.

Eu acho que existem muitos dos chamados engenheiros de software que vêm de origens em CS. O design de software não é parte integrante da maioria dos programas de CS. Não estou dizendo que todos os graduandos de CS são ruins em design, mas aposto que a maioria não tem educação formal que os ensinou. Eu acho que muitas pessoas assumem que, se você pode programar, pode projetar software, o que não é verdade. Dado que muitos programadores não têm formação em engenharia, não é de surpreender que muitos projetos de software não tenham uma equipe que seja boa em capturar design.


Então, que método específico de redigir requisitos e documentos de design você usa? (Olhei sua biografia e esperava ver alguém do espaço de defesa e fiquei surpreso). Presumo que por requisitos você quer dizer algum texto em linguagem natural? ... se sim, você não tem argumentos sobre eles? (Distingo os requisitos de linguagem natural das especificações formais). Eles estão completos? E os documentos de design? Eles estão completamente atualizados para o sistema de remessa atualmente? Concordo que muitos dos chamados programadores e engenheiros de software não são, portanto podemos continuar discutindo o que devem fazer.
Ira Baxter

1
Não tenho certeza de que exista um nome específico para o nosso método. Nossos requisitos são o que eu chamaria de híbrido entre requisitos de linguagem natural e documentos de design de alto nível. Normalmente, temos duas rodadas de edição. Primeiro, documentamos o que um recurso precisa fazer em inglês simples. Em seguida, especificamos exatamente como isso funcionará da perspectiva do usuário. O documento tem dois objetivos. Primeiro, queremos fornecer um documento que possa ser revisado por nossa equipe de Marketing para garantir que atendamos às nossas necessidades de negócios. Segundo, queremos fornecer um documento que possa ser usado por nossa equipe de controle de qualidade para testar.
Pemdas

1
Nossos documentos de design são muito mais formais e detalhados. Eles sempre incluem o seguinte: Algum tipo de análise de caso de uso, qualquer explicação sobre trocas ou razões pelas quais escolhemos uma maneira específica de fazer as coisas, referências a outros designs, definições explícitas de interface, estruturas de dados ... etc. Não temos necessariamente comentários explícitos sobre como o código específico atende a certos requisitos. Não sei se acho isso importante ou não.
pemdas

1
Eu diria que nossos documentos estão 95% atualizados. Algumas coisas aqui e ali escapam pelas rachaduras.
pemdas

2

Eu vejo dois problemas.

A primeira é que é muito difícil manter o código e a documentação sincronizados. Se estiverem separados, eles divergem e a documentação se torna inútil. Os programadores tentaram usar ferramentas para mantê-las sincronizadas (como as ferramentas CASE), mas essas ferramentas ficaram entre os programadores e seu código, o que causou mais danos do que benefícios. Um dos principais insights do design orientado a domínio (Evans, 2004) é que um bom design é realmente difícil; portanto, para obter algo com isso, você deve:

  • escolha a menor área possível do seu programa, onde um bom design trará grandes benefícios, o chamado domínio principal
  • trabalhar muito duro para obter um bom design na forma de uma linguagem onipresente que todos os membros da equipe usam o tempo todo
  • Na medida do possível, torne o design parte do código

O outro grande problema com a maneira como projetamos é que nossos métodos de design não são matemáticos o suficiente. Abstrações com vazamento não se prestam a extrair conclusões sólidas delas, e o mundo da lógica estritamente aplicada e da verdade clara é chamado de matemática, da qual os programadores geralmente evitam.

As poucas ferramentas matemáticas que temos, como métodos formais, são muito difíceis de manejar.

Reduzir mapa é um bom exemplo de matemática em programação. A idéia principal é a seguinte: quando você tem uma operação binária associativa, pode distribuir sua execução com muita facilidade. Uma operação binária é uma função com dois parâmetros, associatividade implica que (a + b) + c = a + (b + c)

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99 é

(a1 + a2 + ... + a99) + (b1 + b2 + ... + b99) + (c1 + c2 + ... + c99) onde As, Bs e Cs podem ser adicionados trivialmente em locais diferentes, seus resultados são coletados e resumiu em pouco tempo.

Reduzir mapa é uma ideia ridiculamente simples. Pode ser descrito em um pedaço de papel. Se você puder supor que o leitor tenha uma compreensão firme do conceito de associatividade, ele cabe em um pedaço de papel bem pequeno. Agora, tente explicar o mapa-reduzir para alguém sem usar o termo associatividade ou se referir a ele indiretamente. Atreva-se.

O design de software sem abstrações matemáticas é como tentar fazer arquitetura sem se preocupar em aprender geometria.

Talvez Haskell possa consertar isso com o tempo. O uso de conceitos da teoria das categorias para descrever programas parece promissor para mim. A teoria das categorias é tão abstrata que até os matemáticos tiveram pouco uso, mas aparentemente as categorias, que são abstratas além do reconhecimento, parecem ser abstratas o suficiente para descrever a estrutura do software. Nós vamos descobrir. Lentamente.

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.