Como visualizar o design de um mecanismo de física?

Estou criando um mecanismo de física e está ficando muito difícil acompanhar tudo isso. Freqüentemente, quando volto ao meu código após um intervalo, não me lembro por que isso não está funcionando. A maioria dos problemas não são simples erros de programação, mas falhas de design no meu mecanismo de física. É por isso que devo terminar de projetá-lo antes de programá-lo.

No entanto, preciso de uma maneira de escrever no papel todo o design do meu mecanismo de física. Senão, vou esquecê-lo amanhã e me perder novamente. Um diagrama de classes UML não é apropriado para o design de um mecanismo de física. Eu realmente não me importo com as aulas, mas com o processo. Não vejo o diagrama do processo de negócios muito útil porque a modelagem de uma única etapa (quadro) do meu processo não me ajudará a entender o comportamento final do meu mecanismo em várias etapas.

Então, que tipo de diagrama devo usar para me ajudar a acompanhar o processo? Que tipo de diagrama os profissionais usam para criar um mecanismo de física?

As listas de tarefas são coisas maravilhosas.

Eu não estou falando sobre // #TODO: blá blá comentários. Quero dizer, receba um caderno honesto com Deus.

Você nunca sabe quando se lembrará de algo importante a fazer. Um notebook fica quieto e permite que você pense sem reclamar sobre como sua letra não será compilada. Algumas das minhas melhores ideias acontecem no banheiro (sim, eu possuo um caderno à prova de água, mas você não precisa ir tão longe).

Você pode obter tamanhos de bolso que são costurados (não colados) para que não se desmoronem no seu bolso. Não conseguiu uma fantasia com uma marca de livro embutida? Fita, tesoura, fita e ninguém jamais saberá.

Quando uma ideia surge, anote-a. Desenhe caixinhas ao lado de cada ideia e você poderá marcá-la facilmente como concluída. Coloque uma caixa na parte superior da página e você saberá quando a página está pronta.

Que acesso seqüencial não é bom o suficiente para você? Sim, eles fazem pastas de bolso também. Tudo isso pode parecer um pouco demais, mas é melhor do que se afogar nas notas postadas ou tentar capturar tudo em Jira.

Não deixe as coisas meio implementadas

Mantenha suas melhorias pequenas e viáveis. Não comece nada que não possa ser terminado de uma só vez. Se for grande demais para isso, divida-o em etapas menores. Sempre deixe o código que compila e passa nos testes. Ah, e não deixe de passar nos testes que você nunca viu falhar. Fazer um teste passar e falhar é como você o testará.

Pare de pensar que você precisa de todo o design no papel

O que você precisa fazer é capturar seu plano em evolução. Você não sabe como as coisas vão ficar quando terminar, então pare de fingir que sim. Capture o que você descobriu da melhor maneira possível. Use um guardanapo e giz de cera, se necessário. Poucas pessoas entendem 90% da UML de qualquer maneira. Use da maneira que puder para mostrar o que você precisa mostrar. Eu me concentro em mostrar minhas interfaces e o que sabe sobre o que.

Escreva notas quando parar de codificar

No momento em que você tira os dedos das teclas, é a última vez que entende o que fez (e o que planejou), bem como faz agora. Capte esse entendimento da melhor maneira possível em algumas anotações. Se tudo o que você tem são comentários, você ainda estará ligado ao computador e provavelmente deixará uma poça na cadeira. Novamente, ter um notebook é uma coisa incrível.

Dessa forma, você pode pousar seu cérebro graciosamente, salvar sua bexiga e decolar novamente mais tarde, sem recorrer à cafeína e aos dentes rangendo.

"Tudo deve ser construído de cima para baixo, exceto pela primeira vez", dizem eles.

Eu começaria do nível mais baixo (por exemplo, matemática básica de vetores) e me certificara de entender bem e de ter uma boa cobertura de teste. Depois, construía mais uma camada, permitindo operações mais abstratas (por exemplo, grupos / entidades, detecção de colisões, mecânica de colisões). Mais uma vez, eu o cobriria com testes; isso me ajudaria a pensar nos casos de uso reais dessas abstrações no mecanismo.

A menos que você tenha um entendimento muito bom de todo o mecanismo (por exemplo, ao reimplementar um mecanismo existente bem conhecido), geralmente é bom ter essas camadas; permite que você pense em uma camada específica em termos da camada anterior, e geralmente não muito mais profunda. Você pode experimentar e criar uma camada com novas abstrações úteis; o que prova ser prático na realidade muitas vezes se desvia das idéias iniciais.

Esperamos que cada camada seja pequena o suficiente para que você não precise de um diagrama complicado ou que seja fácil criar um diagrama útil.

Nunca encontrei um diagrama de código complexo que fosse útil. Porém, os diagramas de interação e ciclo de vida são úteis. Muitas vezes, um diagrama como esse é restrito a 1-2 camadas e, portanto, é simples.

O que eu geralmente acho mais valioso são as descrições e garantias de interface fornecidas por cada nível. Por exemplo, o formato da matemática vetorial e o que acontece nos erros numéricos; o formato das descrições de objetos maiores (sempre convexo? sempre no sentido horário ?, como se cruzam? etc), os parâmetros mecânicos da interação (como o tempo avança? como a massa é manipulada? o momento é sempre preservado? como são calculadas as forças)? interações apropriadas (como lidar com o atrito? deformação? fragmentação? transformar a energia mecânica em perdas de calor é algo?).

Cada camada deve ser pequena o suficiente para ter uma quantidade observável de coisas que introduz e garante que fornece. Essa descrição pode até ser redigida sem que nenhum código de implementação seja gravado (ainda). Isso diminui a chance de determinar que você fez algo terrivelmente errado com três camadas de profundidade; se o fizesse, já seria visível no máximo duas camadas de profundidade.

Faça diagramas da arquitetura! Os diagramas de pipeline do OpenGL FrustratedWithFormsDesigner postados nos comentários são um ótimo exemplo para o fluxo do programa , mas esse é apenas um tipo de diagrama que pode ser útil.

Ao criar diagramas, você deseja tornar o entendimento do código simples e intuitivo; isso pode abranger conceitos de alto nível (como a linha superior de nós no diagrama de pipeline do OpenGL, dizendo algo) ou detalhes técnicos muito granulares (como um gráfico de chamada de função completa).

Idealmente, sua documentação também deve facilitar o código para outras pessoas entenderem; isso pode facilitar coisas como revisões de código ou colaboração de código aberto. Procure por grandes projetos para ver como eles conseguem isso - ao trabalhar com centenas de milhares ou milhões de linhas de código, entender como o programa funciona sem ter que lê-lo é extremamente importante para acompanhar a base de código ou apresentá-la a outras pessoas. . O repositório Vim, com 1,3 milhão de LOC, possui uma ótima documentação de alto nível (IMO) para isso em /src/README.txt . Introduz:

• Qual código em cada arquivo faz
• Variáveis ​​globais importantes e seus valores
• O que acontece no loop principal e quais são as funções que ele chama
• O que acontece em cada um dos modos e as principais funções que os tratam
• O que são recursos de depuração nativos

Se eu quiser contribuir com um patch, geralmente sei qual arquivo eu preciso modificar para alcançar meus objetivos sem muito esforço.

Um dos melhores recursos do Vim /src/README.txté como é fácil encontrar e quão abrangente é; não é granular em nenhum sentido, mas se você clicar na srcpasta no Github, ela será carregada automaticamente e dará instruções para encontrar outro código ou documentação. Compare isso com o repositório Powershell, que procurei por exemplo, mas não consegui encontrar nenhum arquivo ou arquivos equivalentes aos do Vim /src/README.txt. (Um mau sinal para um projeto com 988 mil LOC!)

Algumas coisas que você pode querer diagramar ou documentar incluem:

• Fluxo conceitual do programa (O que o programa realiza e em que ordem?)
• Gráfico de chamada de função / fluxo de programa implementado (como o programa alcança seus objetivos? Que funções são chamadas ou que classes são criadas?)
• Qual código está em quais arquivos? Qual é o esquema organizacional e quais regras você possui para determinar para onde vai uma nova função? Se você possui um forte esquema organizacional, saberá qual arquivo procurar uma determinada função ou classe será fácil, mesmo sem um recurso de "localização em todo o projeto" do tipo IDE ou do tipo IDE.
• De maneira semelhante, quais arquivos incluem quais outros arquivos (relacionados a um gráfico de chamada de função)?
• Quais classes herdam de quais outras classes? Qual é o objetivo de cada aula?

Como você pode fazer esses diagramas? No seu nível, e nos primeiros rascunhos, lápis e papel são provavelmente o melhor / mais rápido método. Quando diagramas e documentação se tornam mais refinados, você pode procurar:

• Dot / Graphviz, um conjunto de programas para gerar gráficos a partir de .dotarquivos.
• LaTeX / TikZ, uma ferramenta muito complexa e detalhada para gerar gráficos ou imagens de qualquer tipo - pode ser muito pesada para as suas necessidades, especialmente porque todo o posicionamento dos nós é manual, mas deve ser lembrado, especialmente se você planeja escrever um papel ou qualquer coisa desse tipo mais tarde.
• Para C, o gson egyptconecta gcce gera um .dotgráfico de chamada. Pode ser automatizado ou incorporado em um makecomando, o que é legal!
• De maneira semelhante, o GNU cflowpode gerar gráficos de chamada somente de texto para C. Ferramentas equivalentes podem existir para outros idiomas, embora você possa se afastar das ferramentas automatizadas em geral - não criar o gráfico manualmente pode dificultar sua compreensão do código ou fornecer uma informação inadequada. nível complexo de detalhes (saber quais funções chamam printf()geralmente não ajuda).

Tente usar um diagrama baseado em redes de Petri. É possível converter o diagrama em programas de computador de maneira sistemática e é possível integrar diagramas de alto nível com diagramas de baixo nível.

Referências

Elementos de rede e anotações: uma linguagem de programação visual de uso geral (2016). Disponível em https://www.academia.edu/31341292/Net_Elements_and_Annotations_A_General-Purpose_Visual_Programming_Language .

Elementos de rede e anotações para programação de computadores: cálculos e interações em PDF (2014). Disponível em https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .