¿Cuándo usaría pseudocódigo en lugar de diagrama de flujo?

9

Soy un estudiante que trabaja con varias técnicas de programación, y me he encontrado con pseudocódigo y diagrama de flujo. Sé que ambos se usan para reflexionar sobre el problema antes de programar realmente, pero tengo algunas preguntas al respecto.

  1. ¿Cuándo usaría pseudocódigo para planificar y cuándo usaría diagramas de flujo? ¿O es mejor hacer ambas cosas antes de programar realmente? Particularmente para un pequeño tipo de juego de arcade en JAVA ya que ese es mi próximo proyecto.
  2. Me di cuenta de que el pseudocódigo es muy similar al código real en lugar de los diagramas de flujo. ¿Esto mejoraría la pseudocodificación porque esencialmente copie / pegue el pseudocódigo en su programa (por supuesto, tiene que cambiarlo para que se ajuste al idioma. Entiendo esa parte).
  3. ¿Es práctico usar ambos durante la programación? Particularmente el mismo juego mencionado anteriormente. Gracias.
kullalok
fuente
Obviamente, no usaría diagramas de flujo donde no tiene flujo, es decir, para casi todas las entidades declarativas.
SK-logic
1
No puedo recordar la última vez que vi un diagrama de flujo de codificación. Diagramas de flujo de datos y clases, diagramas de casos de uso, sí. Pero no diagramas de flujo. Tal vez son más frecuentes en el desarrollo del juego.
Robert Harvey
@RobertHarvey, los diagramas FSM (que son, esencialmente, diagramas de flujo) se usan con bastante frecuencia en el diseño del hardware
SK-logic

Respuestas:

7

Los diagramas de flujo y el seudocódigo a menudo tienen el mismo nivel de expresividad, pero difieren en la linealización. El seudocódigo es lineal (es decir, una secuencia de líneas con instrucciones), un diagrama de flujo no lo es. Por lo tanto, los diagramas de flujo son un nivel de abstracción más alto, que se usa antes de escribir pseudocódigo o para documentación.

Los diagramas de flujo tienen, en mi opinión, dos fuertes ventajas sobre el pseudocódigo: en primer lugar, son gráficos. Muchas personas no técnicas tienen un fuerte temor al texto estructurado, pero no a las descripciones gráficas, por lo que los diagramas de flujo les resultarán mucho más agradables. En segundo lugar, los diagramas de flujo son mucho mejores para expresar metaconsideraciones, como mostrar la línea principal de ejecución en lugar de las ramas.

Sus preguntas en detalle:

  1. Para un problema realmente complicado, primero usaría diagramas de flujo, luego pseudocódigo. Ambos son opcionales cuando te sientes lo suficientemente seguro.
  2. Sí, el pseudocódigo tiene la ventaja de ser fusionable con código real. Steve McConnell, por ejemplo, recomienda enfáticamente escribir métodos en pseudocódigo primero y luego dejar el pseudocódigo en el código como comentarios.
  3. Siempre sentí que la necesidad de dibujar un diagrama de flujo durante el diseño muestra una partición insuficiente de su problema. Los diagramas de flujo no triviales indican una lógica enrevesada, que debe evitarse a grandes costos.
thiton
fuente
1
Los diagramas de flujo también son excelentes maneras de asegurarse de que cada punto de decisión defina las acciones para las rutas menos comunes, así como para la más común. ¡Esto ayuda a asegurarse de que sabrá qué hacer cuando se deniegue la aprobación o se cancele el pedido! A menudo hay más errores en los casos extremos porque las personas se olvidan de hacerlos o los apuran durante el control de calidad cuando las pruebas los encuentran.
HLGEM
2

En pseudocódigo

Para ser honesto, no uso mucho el pseudocódigo. Por lo general, es más rápido escribir el código, de modo que cuando haya terminado con mi código, sea el código real. Hay algunos casos en los que el pseudocódigo puede ser útil, pero generalmente está trabajando en algo muy complejo y solo está tratando de descomponer la estructura de un método o algo. En esos casos, uso comentarios en mi IDE para diseñar la estructura hasta que haga las cosas bien. Luego, entro y escribo el código real en los comentarios. Esto me ayuda a hacer algunas cosas:

  • Puedo ver áreas que tengo y no he implementado al leer los comentarios y ver lagunas obvias en ellos.
  • Cuando complete el código real, tengo comentarios que explican en inglés lo que estoy haciendo. (Probablemente lo necesitarán si es tan complicado que primero necesito escribir un pseudocódigo).

En diagramas de flujo

El código generalmente cambia tanto que los diagramas de flujo no son útiles, excepto por un diseño o documentación de arquitectura más grande y más amplio para todo el sistema. En esos casos, solo haré una pizarra con un diagrama para obtener la esencia de las cosas o para mostrárselo a alguien más en el equipo. A menos que realmente necesite un diagrama de flujo que lo ayude a comprender, entonces realmente no necesita que "hagan" correctamente el software. Hoy en día, hay muchos complementos para IDE que generarán diagramas de flujo del código en sí, así como diagramas de clases y otros (y viceversa `). El único momento real en el que necesitaría hacer un diagrama de flujo realmente preciso es si no puede mantener toda la arquitectura y cómo las cosas funcionan en su cabeza de una vez y necesita hablar sobre algo visual para atrapar problemas.

Ryan Hayes
fuente
0

En general, no escribo diagramas de flujo mientras estoy trabajando en proyectos personales (ya que los proyectos no son muy grandes) y la mayoría de las entradas, salidas y procesos son claros.

pero como comenzará a trabajar en grandes proyectos complejos con diferentes fuentes de entrada, los archivos planos, las bases de datos, las interfaces manuales, etc., son útiles.

Te recomendaría escribir Pseudocódigo y digramas UML ya que estas herramientas te ayudarán a encontrar mejores clases, métodos, etc. A veces, mientras escribes pseudocódigo, encontrarás formas diferentes y más eficientes de resolver un programa.

Decifrador de codigos
fuente
0

El pseudocódigo es para representar rápidamente una idea para aquellos que entienden al menos los conceptos básicos del código. Los diagramas de flujo están dibujando imágenes bonitas para que todos los demás entiendan lo mismo.

Los diagramas de flujo a menudo se usan con fines de documentación porque muchas personas diferentes usan esa documentación y los diagramas de flujo son más fáciles de seguir que el pseudocódigo para los no programadores. En un proyecto en el que está trabajando, seguir con el pseudocódigo está bien, ya que es mucho más útil y mucho más fácil de crear, ya que un editor de texto es todo lo que necesita.

Ryathal
fuente
0

Los diagramas de flujo son un alto nivel de abstracción que le permiten planificar cómo deben proceder las cosas, por ejemplo

si x muere y gana

No necesitan depender de cómo está diseñando el programa en términos de clases y métodos, el pseudocódigo, por otro lado, proporciona un menor nivel de abstracción (aunque realmente depende)

if (isdead (s)) y.win ()

así, el pseudocódigo ahora se puede traducir al programa real en función del idioma que esté utilizando.

Para un juego, recomendaría usar primero un diagrama de flujo, luego diseñar las clases y métodos, escribir un pseudocódigo y finalmente convertirlo en un programa

nischayn22
fuente
0

Consideraría la naturaleza del código que está escribiendo. Si esto es:

  1. Altamente iterativo / recursivo
  2. Ramas de formas complicadas
  3. Implementado en varios sistemas, que desea representar

En los primeros dos casos, el pseudocódigo se vuelve cada vez más difícil de leer que un diagrama de imagen grande. Por otro lado, el código que es principalmente lineal crea diagramas increíblemente aburridos que en realidad hacen que el proceso sea más difícil de entender debido a cuánto lo explota.

Para el tercer caso, los diagramas de flujo son mejores para representar procesos que cruzan los límites del sistema y representan todo el proceso.

Chris Pitman
fuente
0
  1. Debe usar lo que le resulte más cómodo. Dicho esto, mi impresión es que los diagramas de flujo no se utilizan mucho para esbozar el control del programa en estos días; por un lado, generalmente no están estructurados, en comparación con el pseudocódigo. Es más común usar diagramas de dependencia de clases como UML, para describir su arquitectura en un nivel mucho más alto. Además, si su aplicación tiene una máquina de estados, es esencial dibujar un diagrama de máquina de estados (similar a un diagrama de flujo).
  2. Creo que tienes razón aquí. Para empezar, una forma de trabajar es escribir su pseudocódigo como comentarios en su archivo fuente e insertar las líneas de implementación reales entre ellos.
  3. Nuevamente, use lo que le resulte más cómodo. Si no está seguro, pruébelos a ambos; Espero que su práctica converja rápidamente en lo que sea más útil para usted. Personalmente, no encuentro útiles los diagramas de flujo a menos que esté tratando de desenredar una orden de ejecución particularmente complicada.
tormenta
fuente
0

¿Por qué escribir pseudocódigo cuando puedes escribir Java? He encontrado que Java, un buen IDE y Javadoc son la forma más fácil de comprender un problema de programación, al menos uno orientado a objetos . (Y un juego de arcade debería ser OO). El lenguaje fue diseñado desde cero para esto. Es simple y directo. (Demasiado simple para muchos propósitos, tal vez, pero lo mejor que he visto para esto.) El hipertexto en el Javadoc y, a través de un IDE, en el código en sí mismo hacen un "diagrama" más comprensible de lo que podrías dibujar incluso una hoja grande de papel El código Java es tan simple como cualquier pseudocódigo y mucho más riguroso. Y una vez que lo haya "diagramado" y "pseudo" codificado, ¡el programa realmente se ejecutará!

RalphChapin
fuente
1
java y otros pueden ser largos sin aliento. "public static void main .." o "system.out.println" o identificadores largos con notación camelback, largos alientos allí. Luego, las excepciones que han atrapado 2b ... Y llamar a cualquier biblioteca puede ser sin aliento. Recuerdo hace 10 años abrir un archivo. algo así como el nuevo BufferedReader (nuevo InputStreamReader (System.in)); aparentemente más fácil ahora mkyong.com/java/… Pero realmente cualquier biblioteca a la que llames podría ser larga, no como un pseudocódigo que puede ser tan conciso como te puedas imaginar
barlop
también en java o en cualquier idioma, encuentras errores en la compilación. nada de eso con pseudocódigo. puedes enfocarte en el diseño sin distracciones. Los comentarios sobre el pseudocódigo pueden ser mucho más breves ya que el pseudocódigo es más claro para la mente, ya que es de la mente. No está limitado al pensar en un solo idioma, y ​​es posible que vea que usaré este otro idioma. Es más rápido y menos doloroso escribir (no se necesitan compilaciones, incluso los muy fluidos obtienen errores de compilación) y, por lo tanto, menos tiempo para escribir facilita el rediseño.
barlop
@barlop: Funciona para mí, pero puede que no funcione para todos. Dejo mucho código ("BufferedReader", por ejemplo) fuera de mis clases hasta que lo necesite o necesite saber si puedo hacerlo funcionar. Incluso cuando lo tengo, está escondido muy bien en clases que no necesito mirar al considerar el diseño general. Los errores del compilador se solucionan fácilmente y pueden evitar defectos de diseño importantes, como el uso de la clase incorrecta en un punto donde ni siquiera puede obtener una instancia de la clase correcta. Admito que he "diseñado" software de esta manera que solo podría escribirse en Java, pero el OP está utilizando Java.
RalphChapin el
digamos que quieres abrir un archivo, ¿ves cómo el pseudocódigo del archivo abierto ("c: \ blah \ file") es más corto que el Java para hacerlo? o que la impresión "dfdfd" es más corta que la de Java para hacerlo? Nunca he hecho (todavía) páginas de pseudocódigo y varias clases. en parte porque no he escrito grandes programas en las edades b) en parte porque no creo que lo haría, creo que escribiría un pseudocódigo y luego lo implementaría. Cualquier otro pseudocódigo, si lo hay, sería de nivel superior. Podría tener una lista de todas las clases y métodos, incluidos los constructores. Así que sé qué clases son qué y que puedo obtener una instancia de eso ...
barlop
así que no estaría en una situación de usar la clase incorrecta, pero de todos modos, si es mi programa, habría escrito en mis notas qué clase es qué ... las clases son de un nivel bastante alto. Tendría una nota sobre eso si no puedo recordarlo. Y el pseudocódigo se trata de lo que uno quiere decir, así que si quisiste hacer una instancia de clase bla y escribiste bleh, entonces es solo un error de escritura pero no obstaculiza tu diseño. (si estás escribiendo para ti porque sabes lo que quieres decir, y lo usaste como un bla)
barlop
0

Podría usar un diagrama de flujo si se está confundiendo realmente con las declaraciones if y está tratando de entender eso. O si está tratando de entender un ciclo, vea el efecto de los contadores. Si estás aprendiendo, puede ayudar mucho.

Puede parecer un poco restrictivo porque tienes que poner breves declaraciones en cuadros. Y si su programa es muy lineal y sus bucles y ifs son triviales, entonces no veo ninguna utilidad.

El pseudocódigo es útil para diseñar un programa, sin la distracción de tener que tener la sintaxis correcta y sin el largo aliento que pueden implicar algunos lenguajes. El hecho de que sea más rápido de escribir también facilita el rediseño del código. Y puede ser tan conciso como lo desee su mente, es agradable escribir, requiere menos esfuerzo mental para que funcione (como no o mucho menos depuración) y más capacidad para enfocarse en el panorama general y el diseño.

Entonces, útil para ti.

También se pueden usar para comunicarse con otros.

barlop
fuente