Foro de elhacker.net

En la fase de diseño de un programa, cuando ya teneis los requerimientos, ¿qué modelo o diagrama os parece más útil usar? Para un proyecto vuestro, personal, quiero decir.

¿Cuál de estos modelos usaríais?

- Diagrama de flujo.
- Diagrama de clases.
- Diagrama de objetos.
- Diagrama de casos de uso.
- Otro (especificar).

Sólo uso diagramas si me resulta muy complicado entender el código.

¿No depende del tipo de programa que uno haga o el lenguaje que se use?

Hay programas en que no hay realmente un flujo sino muchas posibilidades, o estados, entonces parece que conviene escribir los estados y si en ciertos casos pueden cambiar, o cuando y en qué sentido, o al menos en personajes de videojuegos lo veo un poco así.
Del estado Quieto puede pasar a Caminando (<- o ->), Saltando (A), Atacando (S), aGachándose (flecha abajo) o Lanzando (D).
Del estado C puede pasar a Q, S, A, G o L.
De S: Q, SA o SL.
De A: Q o AG.
De G: Q, AG o LG.
De L: Q o LG.

Un ejemplo nada más, y en realidad suele ser más complicado, por ejemplo porque una cosa es el estado saltando y otra cayendo.

¿Puedes ayudarme con esto
https://foro.elhacker.net/foro_libre/iquestcomo_hacer_un_diagrama_de_flujo_de_elegir_desafios_en_juegos-t517881.0.html
?

Los diagramas utilizados por los programadores suelen ser el de flujo, ya que permite pensar, explicar y analizar las distintas partes de un algoritmo;

Y luego el diagrama de UML, que representa las clases, interfaces, etc. que utiliza un sistema, además de las relaciones de herencia o agregación que existen entre estas.

Si utilizas un lenguaje orientado a objetos, UML es muy útil. Si tienes un diagrama UML sólido diseñado, codificarlo es relativamente más simple, y lo puedes aplicar a cualquier lenguaje.  

Cuando es para tí, vría el caso de cuando es para otro/s...

Cuando es para tí, puedes no necesitar hacer un diagrama... En realidad es conveniente hacerlo para aquellas partes que resultan complejas (es dcir entrar en detalles más finos en la partes más complejas y menos detallado en partes que te son fácilmente asequibles) y por tanto no esté seguro de ser capaz de programarlo 'de cabeza'.

Las ventajas de elaborar el diagrama, son:
- Evita confusión de partes o módulos que puedan parecerse (ver las dependencias entre módulos aclara muchos conceptos).
- Ayuda a anticiparte a posibles problemas que puedan darse si elegiste opciones inadecuadas (aún así, siempre hay flexibilidad para elegir).
- Para los principiantes, ayuda a pensar y ordenar ideas de forma mas lógica.
- Si eres principiantes, tras hacer un diagrama, puedes programar más rápido que sin el disgrama. A medida que tu mene es clara, esto deja de ser cierto...

En contra tiene que precisas emplear un tiempo para elaborarlo, luego si no es imprescindible hacerlo, hacerlo supone más un retraso que una ayuda.

Gracias por tu respuesta Locura_23, estoy de acuerdo en que un enfoque estructurado indicando el orden de ejecución de las diferentes operaciones mediante un diagrama de flujo, podría ser el primer paso para diseñar un programa. Luego, si ese proyecto va a ser orientado a objetos, se desarrollaría sobre la base del diagrama de flujo un diagrama de clases que especifica métodos, atributos, relaciones de herencia, etc...



Comprendo tu punto, pero prefiero usar modelos.
Le echaré un vistazo a tu post, un saludo.


No creo que sea una cuestión de velocidad, sino de diseñar de forma más eficiente. La simplicidad en un diseño mecánico simplifica el mantenimiento y reduce los fallos, algo parecido creo que sucede en un sistema de software.

Flujo, describiendo funciones puras (https://en.wikipedia.org/wiki/Pure_function) sobre tipos de datos estándar (que no necesitan documentación adicional).