¿En qué circunstancias los diagramas de flujo siguen siendo una herramienta valiosa y útil?

14

Cuando comencé a programar, me basé en gran medida en los diagramas de flujo (y en los gráficos de espaciado de impresoras). Mientras estaba en la clase COBOL, no pude comenzar a escribir ningún código hasta que el instructor aprobó mi diagrama de flujo. En aquel entonces, tenía que hacer un diagrama de flujo para todo.

Hoy, veinticinco años después, me encuentro solo diagramas de flujo de dos tipos de cosas. Algoritmos muy específicos donde la lógica es complicada o conceptos muy generales para garantizar que obtenga todos los grandes pasos definidos y en el orden correcto.

¿Hay otros casos de uso para diagramas de flujo que simplemente he pasado por alto?

Michael Riley - también conocido como Gunny
fuente

Respuestas:

17

Absolutamente.

Cada vez que implemente algo que no he hecho antes (y el algoritmo toma más de unos pocos pasos), lo trazaré. Me parece que realmente me obliga a analizar toda la solución a un nivel más atómico y más exhaustivo que si no se trazara. Encuentro que hay tres beneficios principales para esta práctica:

  • Menos "oh craps" porque he pensado en todo el algoritmo
  • Elimina cualquier posible golpe en los problemas que pueden ocurrir en el resto del sistema
  • Me permite guiar fácilmente a alguien más a través del algoritmo

Las dos ocasiones diferentes donde realmente uso estas son:

  • Algoritmos de nivel bajo (ish). Me refiero a una solución muy específica para un problema muy específico. Generalmente pasaré esto por pares antes de la implementación.
  • Flujo de usuario. No solo puedo usar esto para pasar por un compañero, sino que también lo usaré para explicar (de una manera muy no técnica) el flujo a un experto en usabilidad.

Habiendo dicho todo eso, no produzco diagramas de flujo a diario (e incluso cuando se realizan, generalmente es una sesión de pizarra a menos que esté escribiendo un documento de diseño técnico).

Demian Brecht
fuente
@Cape Cod Gunny: es posible que encuentre Dialog Design Diagrams un poco más útil (una forma temprana de Diagrama de actividad)
Steven A. Lowe
1
@Cape Cod Gunny: Microsoft SketchFlow también podría ser de interés.
Jörg W Mittag
12

Nunca

Los diagramas de flujo, especialmente los practicados hace más de 25 años, han sido reemplazados por técnicas de diagramación mucho más expresivas (ver Diagramas de acción, Gráficos de secuencia, Gráficos de estado, etc.).

Los propios estudios de IBM mostraron que el uso de diagramas de flujo no tuvo efecto en la calidad del diseño o implementación de un sistema (aunque fueron marginalmente útiles para comunicarse con los usuarios y otros desarrolladores) [referencia precisa no disponible fácilmente, pero fue citada en Técnicas de diagramación de James Martin para analistas y programadores ].

Steven A. Lowe
fuente
3
Reemplazado es una palabra dura, solo tenemos más opciones ahora. Más expresivo no siempre es mejor. Mis clientes quieren saber qué está haciendo el software y no quieren perder el tiempo aprendiendo UML. No puedo culparlos.
maple_shaft
2
@ Steven: +1, pero los diagramas de flujo desaparecieron hace 25 años. Cuando ingresé a Carnegie-Mellon en 1975, la programación de investigación en CMU se realizó en línea en ALGOL, SAIL, PASCAL, LISP, Simula, C y otros lenguajes de alto nivel, principalmente utilizando EMACS. Nadie se molestó con los diagramas de flujo. Simplemente escribimos un pequeño código, lo probamos, lo corregimos y luego escribimos un poco más.
Kevin Cline
55
@Demian: las cajas y las flechas son realmente todo lo que necesitas ;-)
Steven A. Lowe
1
@ Steven Low y Steven Jeuris: lo siento, ambos están 100% correctos. "Reemplazar" es la ortografía habitual.
Kevin Cline
1
@ Steven Jeuris: yo también; Miré también pero no encontré nada. Estoy bastante seguro de que mi memoria es correcta sobre dónde lo leí, pero desafortunadamente en este momento todos mis libros de referencia están almacenados (mudanza). ¡El estudio se me quedó grabado en la mente porque fue realizado por IBM en su propia gente usando su propia plantilla de diagrama de flujo!
Steven A. Lowe
7

No he dibujado un diagrama de flujo clásico desde mi primera clase de programación en 1976, y no he visto a nadie más crear uno desde principios de los 80. Los diagramas de flujo fueron útiles para comunicar la lógica del programa cuando el código estaba en lenguaje ensamblador. A fines de la década de 1960, los programadores de lenguaje ensamblador usaban pseudocódigo. Al programar en lenguajes OO modernos, ni los diagramas de flujo ni el pseudocódigo tienen ningún valor. También puede escribir código de alto nivel en el lenguaje de implementación.

De vez en cuando dibujo diagramas UML, principalmente en papel, para expresar ideas de diseño, pero esos diagramas solo viven hasta el final de la discusión. También dibujo diagramas de transición de estado de vez en cuando, luego los convierto en una tabla de estado en el lenguaje de implementación.

Kevin Cline
fuente
5

Uso diagramas de flujo todo el tiempo por varias razones:

  1. Son mejores que los diagramas de casos de uso de UML en mi opinión. Pueden reflejar varios casos de uso diferentes y cómo interactúan, y en general hacen un mejor trabajo al unir la experiencia del usuario y las decisiones.

  2. Son más fáciles de entender y más intuitivos. Tu mente, naturalmente, sigue las flechas como un laberinto de principio a fin. Puede usar diagramas de flujo para finalizar y hacer referencia a otro diagrama de flujo para una historia de usuario diferente. Por lo general, puedo imprimirlos en un libro numerado de páginas y rápidamente voltear páginas para navegar al siguiente diagrama de flujo.

  3. Son universales. Pocas personas ajenas a la ingeniería de software conocen y entienden los diagramas UML, donde los diagramas de flujo son mucho más reconocibles por los usuarios y analistas de negocios. Intento comunicar casos de uso complejos a un cliente y, a veces, luchan por comprenderlo, les dibujo un diagrama de flujo y entienden por qué finalmente comprenden todos los matices que lo hacen MUCHO MÁS complejo de lo que pensaban.

árbol de arce
fuente
44
+1 Para diagramas de flujo reconocibles por los usuarios y BA. ¿Qué herramienta de diagrama de flujo utiliza?
Michael Riley - AKA Gunny
44
Los diagramas de flujo no representan casos de uso en absoluto. Si quisiera correlacionar un diagrama de flujo con un diagrama UML, sería más como un diagrama de secuencia, un diagrama de comunicación o un diagrama de actividad. De hecho, los diagramas de actividad están destinados a mostrar flujos de trabajo. Lo que, en mi opinión, hace que los diagramas de actividad UML sean mejores que un diagrama de flujo es que los símbolos y la terminología utilizados están estandarizados, lo que permite que cualquiera (que lo sepa) pueda leerlo fácilmente sin tener que buscar los significados de los símbolos.
Thomas Owens
@Thomas, diferentes trazos ... Tienes razón, aunque los diagramas de actividad son más expresivos, pero requieren más información, conocimiento de UML y un tiempo precioso que simplemente no tengo cuando el cliente necesita un diagrama ¡AHORA AHORA! Puedo preparar un diagrama de flujo rápido y sucio. Para el usuario, el diagrama de caso de uso UML real le dice sentido común. El diagrama de flujo llega al meollo de la cuestión.
maple_shaft
2
@Cape, solo uso Visio. Ciertamente no es la mejor herramienta, pero ya sabes lo que dicen: la gente elige un infierno familiar y cómodo sobre un cielo extraterrestre desconocido.
maple_shaft
@Maple - Gracias. Estoy impresionado porque pensé que los diagramas de flujo ya no eran relevantes. Me siento como un avestruz ;-)
Michael Riley - AKA Gunny
3

Los diagramas de flujo son útiles cuando las cosas deben hacerse en un orden específico. Donde realmente brillan en mi mente es mostrar dónde se toman las decisiones y asegurarse de que cada posible decisión tenga un camino. Esto evita la creación de programas en los que se requiere la aprobación de un mamager, pero no hay forma de tratarlo si el gerente (que aprueba el 98% del tiempo) dice que no. Nos recuerdan que el camino más común no es el único. Los encuentro útiles al hablar con los usuarios acerca de los requisitos porque a menudo solo le dirán la ruta más común.

HLGEM
fuente
1

Los diagramas de flujo pueden ser útiles para ingeniería inversa de código muy mal estructurado. Particularmente si tiene gotos. Afortunadamente, no he visto mucho código pasado por goto recientemente.

Como otros destacaron por comunicarse con los usuarios finales. Ordeno el inicio de un transmisor de TV documentado por diagrama de flujo. Las personas de hardware y software tenían una especificación común para trabajar.

Nick Keighley
fuente
0

El Diagrama de actividad y el Diagrama de flujo de UML son útiles para mostrar la complejidad baja a media de un proceso o algoritmo.

Son muy buenos cuando se comunican con los usuarios comerciales sobre las reglas comerciales.

Existe una variación en la forma de BPMN 2.0 que es muy útil en el modelado de procesos empresariales.

Algunas herramientas BPMN pueden generar aplicaciones web en ejecución a partir de gráficos.

Entonces, sí, los diagramas de flujo todavía tienen un lugar, pero deben usarse con prudencia.

Ninguna posibilidad
fuente
-2

No soy programador Soy un técnico en ingeniería de hardware.

Para mí tiene sentido comenzar al menos con comentarios que expliquen los bloques lógicos que se utilizarán. Después de eso, desarrolla el esqueleto del programa con el código real. Es similar a comenzar un guión de película con un guión gráfico y luego completar los detalles de acción y el diálogo posterior.

¿No debería planearse cuidadosamente cualquier esfuerzo que valga la pena? En el ámbito del hardware, comenzamos con un documento de requisitos del cliente, luego escribimos un documento de especificación de hardware, luego desarrollamos el esquema, luego dibujamos un diseño de placa y luego presentamos la documentación del ensamblaje. No solo comenzamos a tomar piezas y soldarlas juntas a medida que se nos ocurren ideas para hacer el producto final.

No veo cuán eficiente se puede escribir el código en un programa de 15 KB o 15 MB sin mucho trabajo de preparación antes de comenzar la codificación real.

mobileHman
fuente
1
Mucha gente considera que las analogías entre hardware y software no son necesariamente relevantes. Los ciclos de Diseño-Código-Prueba en software son mucho más rápidos en software. Los llamados métodos ágiles escribirían una prueba primero y luego escribirían el código para pasar la prueba. <br/> 15K es bastante pequeño, por lo que podría ser un software integrado, que podría estar "muy planificado" para garantizar que cumpla con sus especificaciones. <br/> El software del transbordador espacial fue escrito utilizando las técnicas que usted defiende.
Nick Keighley el
¡Además, los diagramas de flujo no son necesariamente la herramienta elegida para el diseño de software!
Nick Keighley el