¿Cómo visualizar el diseño de un motor de física?

17

Estoy haciendo un motor de física y se está volviendo bastante difícil hacer un seguimiento de todo. A menudo, cuando vuelvo a mi código después de un descanso, simplemente no recuerdo por qué eso no funciona. La mayoría de los problemas no son simples errores de programación, sino defectos de diseño en mi motor de física. Es por eso que debería terminar de diseñarlo antes de programarlo.

Sin embargo, necesito una forma de escribir en papel todo el diseño de mi motor de física. De lo contrario, lo olvidaré mañana y me perderé de nuevo. Un diagrama de clase UML no es apropiado para el diseño de un motor de física. Realmente no me importan las clases sino el proceso. No veo el diagrama de proceso de negocio como realmente útil porque modelar un solo paso (marco) de mi proceso no me ayudará a comprender el comportamiento final de mi motor en muchos pasos.

Entonces, ¿qué tipo de diagrama debo usar para ayudarme a realizar un seguimiento del proceso? ¿Qué tipo de diagrama usan los profesionales para hacer un motor de física?

Invierno
fuente
44
Primero, sugeriría un diagrama de flujo de alto nivel, para mostrar cómo se usa el motor y cómo evalúa las cosas. O tal vez algo similar al diagrama de canalización de OpenGL ( openglinsights.com/pipeline.html ). Luego, haría una búsqueda en Google Images para "Diagrama del motor de física" para ver cómo lo hacen otras personas. ;)
FrustratedWithFormsDesigner
44
¿Por "un diagrama UML" se refiere a un diagrama de clase? El diagrama de clase es uno de los 7 diagramas estructurales en UML. También hay 7 tipos de diagramas de comportamiento.
VENIDO del
En primer lugar, debe tener una muy buena comprensión del motor de física; cada pequeño detalle y cómo funcionan las cosas juntas. Nada que ver con la programación. Luego, intenta modelarlo en entidades de programación (clases) e interacciones. Puede usar las herramientas que desee (incluso bocetos y notas escritas a mano). Luego, creas tus clases una a la vez. Comience escribiendo una aplicación de consola. Puede usar pruebas de unidad / clase para asegurarse de que sus pequeñas clases funcionen y hagan lo que espera
John Kouraklis,
66
En mi experiencia, los programadores profesionales no usan documentos de diseño o diagramas para diseñar cosas. Quizás en una pizarra. Con lenguajes de programación contemporáneos, los diseños están en la cabeza y en el código. Los documentos o diagramas de diseño se usan con mayor frecuencia para la comunicación. Según su descripción, supongo que su diseño debe descomponerse.
JimmyJames
1
"Un diagrama de clase UML no es apropiado para el diseño de un motor de física". Por qué no? Las clases tienen que ver con la separación de las preocupaciones. Cualquier sistema se puede dividir en componentes con roles distintos, y esos componentes generalmente se pueden convertir en clases.
Tanner Swett

Respuestas:

29

Las listas de tareas son cosas maravillosas.

No estoy hablando de // #TODO: bla, bla, comentarios. Me refiero a obtener un cuaderno honesto con Dios.

Nunca se sabe cuándo recordará algo importante que hacer. Un cuaderno se sentará en silencio y le permitirá pensar sin quejarse de cómo su escritura no se compilará. Algunas de mis mejores ideas ocurren en el baño (sí, tengo un cuaderno a prueba de agua, pero no tienes que ir tan lejos).

Puede obtener los de bolsillo que están cosidos (no pegados) para que no se desmoronen en su bolsillo. ¿No logró obtener una elegante con un marcador incorporado? Cinta, tijeras, cinta y nadie lo sabrá jamás.

Cuando una idea golpea, simplemente anótala. Dibuja pequeños cuadros al lado de cada idea y puedes marcarla fácilmente como hecha. Pon un cuadro en la parte superior de la página y sabrás cuando la página esté lista.

¿Qué acceso secuencial no es lo suficientemente bueno para ti? Sí, también hacen carpetas de bolsillo. Todo esto puede parecer un poco demasiado, pero es mejor que ahogarse en las notas o intentar capturar todo en Jira.

No dejes las cosas medio implementadas

Mantenga sus mejoras pequeñas y alcanzables. No comiences nada que no se pueda terminar de una vez. Si es demasiado grande para eso, divídalo en pasos más pequeños. Siempre deje el código que compila y pasa sus pruebas. Ah, y no dejes pasar las pruebas que nunca has visto fallar. Hacer una prueba tanto aprobada como reprobada es cómo se prueba la prueba.

Deja de pensar que necesitas todo el diseño en papel

Lo que debe hacer es capturar su plan en evolución. No sabes cómo se verán las cosas cuando termines, así que deja de fingir que lo haces. Capture lo que haya descubierto lo mejor que pueda. Usa una servilleta y un crayón si es necesario. Pocas personas entienden el 90% de UML de todos modos. Use cualquier forma que pueda para mostrar lo que necesita mostrar. Me concentro en mostrar mis interfaces y qué sabe sobre qué.

Escribe notas cuando dejes de codificar

En el momento en que quite los dedos de las teclas es la última vez que comprenderá lo que ha hecho (y lo que ha planeado) tan bien como lo hace ahora. Capture esa comprensión lo mejor que pueda en algunas notas. Si todo lo que tiene son comentarios, entonces todavía está atado a la computadora y es probable que deje un charco en la silla. Una vez más, tener una computadora portátil es algo increíble.

De esta manera, puede aterrizar su cerebro con gracia, salvar su vejiga y despegar nuevamente más tarde sin recurrir a la cafeína y el rechinar de dientes.

naranja confitada
fuente
(Como una computadora portátil honesta que también es inteligente, el modo Emacs Org funciona bien. Una herramienta similar, incluso un rastreador de problemas, podría funcionar bien, dependiendo de los procesos. Una computadora portátil de papel es excelente para llevar, y permite gráficos rápidos y imágenes, lo cual es genial mientras se piensa.)
9000
66
+1 para Don't start anything that can't be finished in one sitting. If it's to big for that then break it down into smaller steps.. Es una de las cosas más importantes que aprendí en la industria.
Akshat Mahajan
8

"Todo debe construirse de arriba hacia abajo, excepto por primera vez", dicen.

Comenzaría desde el nivel más bajo (por ejemplo, matemática vectorial básica), y me aseguré de entenderlo bien y que tiene una buena cobertura de prueba. Luego, construiría una capa más además de eso, permitiendo más operaciones abstractas (por ejemplo, grupos / entidades, detección de colisiones, mecánica de colisiones). De nuevo, lo cubriría con pruebas; Me ayudaría a pensar en los casos de uso real de estas abstracciones en el motor.

A menos que comprenda muy bien todo el motor (por ejemplo, cuando vuelve a implementar un motor existente conocido), generalmente es bueno tener estas capas; le permite pensar en una capa en particular en términos de la capa anterior, y generalmente no es mucho más profunda. Puede experimentar y construir una capa con nuevas abstracciones útiles; lo que resulta práctico en realidad a menudo se desvía de las ideas iniciales.

Esperemos que cada capa sea lo suficientemente pequeña como para que no necesite un diagrama complicado, o sea fácil encontrar una útil.

Nunca he encontrado un diagrama de código complejo que fuera útil. Sin embargo, los diagramas de interacción y ciclo de vida son útiles. Muy a menudo, un diagrama como ese está limitado a 1-2 capas y, por lo tanto, es simple.

Lo que generalmente encuentro más valioso son las descripciones de interfaz y las garantías proporcionadas por cada nivel. Por ejemplo, el formato de las matemáticas vectoriales y lo que sucede en los errores numéricos; el formato de las descripciones de objetos más grandes (siempre convexo? siempre orientado en el sentido de las agujas del reloj ?, ¿cómo intersecar? etc.), los parámetros mecánicos de interacción (¿cómo avanza el tiempo? ¿cómo se maneja la masa? ¿se conserva siempre el impulso? ¿cómo se calculan las fuerzas?) interacciones correctas (¿cómo manejar la fricción? ¿deformación? ¿fragmentación? ¿La transformación de la energía mecánica en pérdidas de calor es algo?).

Cada capa debe ser lo suficientemente pequeña como para tener una cantidad observable de cosas que introduce y garantiza que proporciona. Esta descripción puede incluso redactarse sin que se escriba ningún código de implementación (todavía). Esto reduce la posibilidad de determinar que has hecho algo horriblemente mal en tres capas de profundidad; si lo hicieras, ya sería visible como máximo en dos capas de profundidad.

9000
fuente
Me gusta construir el código de abajo hacia arriba, haciendo capas que se vuelven más y más expresivas de su conjunto de problemas. Pero no piense que las hará bien la primera vez. Una vez que comience a usar una capa para implementar cosas más arriba, encontrará problemas con su API y tendrá que regresar y cambiarla. Está bien.
Justsalt
4

¡Haz diagramas de la arquitectura! Los diagramas de canalización de OpenGL FrustratedWithFormsDesigner publicados en los comentarios son un gran ejemplo para el flujo del programa , pero ese es solo un tipo de diagrama que puede ser útil.

Al diseñar diagramas, desea hacer que la comprensión del código sea simple e intuitiva; Esto puede abarcar tanto conceptos de alto nivel (como la línea superior de nodos en ese diagrama de canalización de OpenGL, diciendo algo) como detalles técnicos muy granulares (como un gráfico de llamada de función completa).

Idealmente, su documentación también debería hacer que el código sea fácil de entender para otras personas; Esto puede facilitar cosas como las revisiones de código o la colaboración de código abierto. Mire proyectos grandes para ver cómo logran esto: cuando trabaje con cientos de miles o millones de líneas de código, comprender cómo funciona el programa sin tener que leerlo es enormemente importante para realizar un seguimiento de la base de código o presentarlo a otros . El repositorio de Vim, con 1.3 millones de LOC, tiene bastante buena documentación de alto nivel (IMO) para esto en /src/README.txt . Introduce:

  • Qué código en cada archivo hace
  • Variables globales importantes y sus valores.
  • Qué sucede en el bucle principal y qué funciones llama
  • Qué sucede en cada uno de los modos y las funciones principales que los manejan
  • Qué características de depuración nativas son

Si quiero contribuir con un parche, generalmente sé qué archivo necesito modificar para lograr mis objetivos sin excavar mucho.

Una de las mejores características de Vim /src/README.txtes lo fácil que es encontrarlo y lo completo que es; no es granular en ningún sentido, pero si hace clic en la srccarpeta en Github, se carga automáticamente y da instrucciones para encontrar otro código o documentación. Compare eso con el repositorio de Powershell, que busqué como ejemplo pero no pude encontrar ningún archivo o archivos equivalentes a los de Vim /src/README.txt. (¡Una mala señal para un proyecto con 988 mil LOC!)

Algunas cosas que puede querer diagramar o documentar incluyen:

  • El flujo del programa conceptual (¿Qué hace el programa de lograr , y en qué orden?)
  • Gráfico de llamada de función / flujo de programa implementado (¿Cómo logra el programa sus objetivos? ¿Qué funciones se llaman o se crean las clases?)
  • ¿Qué código hay en qué archivos? ¿Cuál es el esquema organizacional y qué reglas tiene para determinar a dónde va una nueva función? Si tiene un esquema organizacional sólido, será fácil saber en qué archivo buscar una determinada función o clase, incluso sin un IDE o una característica similar a la de IDE "buscar en todo el proyecto".
  • De manera relacionada, ¿qué archivos incluyen qué otros archivos (relacionados con un gráfico de llamada de función)?
  • ¿Qué clases heredan de qué otras clases? ¿Cuál es el propósito de cada clase?

¿Cómo puedes hacer esos diagramas? A su nivel, y para los primeros borradores, el lápiz y el papel es probablemente el mejor / más rápido método. Cuando los diagramas y la documentación se vuelven más refinados, puede investigar:

  • Dot / Graphviz, un conjunto de programas para generar gráficos a partir de .dotarchivos.
  • LaTeX / TikZ, una herramienta muy compleja y detallada para generar gráficos o imágenes de cualquier tipo: puede ser demasiado pesado para sus necesidades, especialmente porque todo el posicionamiento de los nodos es manual, pero debe tenerse en cuenta, especialmente si planea escribir un papel o algo por el estilo más tarde.
  • Para C, gson se egyptconecta gccy genera un .dotgráfico de llamadas. Se puede automatizar o incrustar en un makecomando, ¡lo cual es bueno!
  • En relación con esto, GNU cflowpuede generar gráficos de llamadas de solo texto para C. Es posible que existan herramientas equivalentes para otros idiomas, aunque es posible que desee alejarse de las herramientas automatizadas en general; no crear el gráfico manualmente puede dificultar su comprensión del código o proporcionar una información inapropiada nivel de detalle complejo (saber qué funciones llamar printf()es usualmente bastante inútil).
9999 años
fuente
Estoy realmente preocupado por tener una buena documentación, pero por ahora, dejé de hacerlo porque mi código cambia constantemente para establecer nuevos algoritmos e intentos de hacer algo. Por ejemplo, en el código que detecta la detección de colisión continua, cambié varias veces de almacenar posiciones anteriores en las clases Body para calcular la posición anterior a partir del movimiento del Body. Esta falta de profesionalidad se debe a que diseñé la cosa durante la programación porque cuando diseño algo en mi motor de física quiero verificar si es realmente posible.
Invierno
Supongo que debería considerar este proyecto experimental y luego reescribirlo desde cero con el prototipo que hice, pero puse mucho esfuerzo para hacerlo lo suficientemente limpio como para mantenerlo sin tener que volver a escribir todo.
Invierno
0

Intenta usar un diagrama basado en redes de Petri. Es posible traducir el diagrama a programas de computadora de manera sistemática, y es posible integrar diagramas de alto nivel con diagramas de bajo nivel.

Referencias

Elementos netos y anotaciones: un lenguaje de programación visual de uso general (2016). Disponible en https://www.academia.edu/31341292/Net_Elements_and_Annotations_A_General-Purpose_Visual_Programming_Language .

Elementos netos y anotaciones para la programación de computadoras: computaciones e interacciones en PDF (2014). Disponible en https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .

John Frederick Chionglo
fuente