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

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.

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.

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:

• Macneil Shonle, William G. Griswold e Sorin Lerner. Além da refatoração: uma estrutura para manutenção modular de idiomas de projeto transversais . Nas atas da 6ª Reunião Conjunta da Conferência Europeia de Engenharia de Software e do Simpósio ACM SIGSOFT sobre os fundamentos da engenharia de software (ESEC-FSE '07; 3-7 de setembro de 2007). 175-184.

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

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:

• Wermelinger e Fiadeiro

• Tsantalis e cols.

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?

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.

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.