secuencia - Diagramas de diagramas de flujo frente a diagramas de actividad UML

diagrama uml de clases

Question

¿Cuál es la diferencia práctica entre el uso de diagramas de flujogramas y diagramas de actividad UML? Tengo algunos pensamientos, pero tal vez me esté perdiendo un elefante en la habitación.

Diagrama de flujograma:

1. Ampliamente utilizado;
2. Fácil de entender por los no programadores;
3. ¿Antiguo?

Diagrama de actividad UML:

1. Estandarizado;
2. Admite concurrencia;
3. Sintaxis menos conocida, pero aún bastante simple.

Para mi caso de documentación ad-hoc de un bloque particular de lógica de aplicación, decidí ir con los diagramas de flujograma. Más personas en la compañía podrán entenderlos.

Answer 1

Como nota, los diagramas de Actividad inherentemente pueden incluir concurrencia y tiempo. Si miras este ejemplo cifrado de Wikipedia (que insertaría si SO SO fuera el formato SVG) puedes observar la sección con dos pesadas barras horizontales y dos actividades paralelas de "idea presente" e "idea de registro". Esto se lee como "iniciar estas actividades en paralelo, y continuar solo cuando ambas estén completas". Los diagramas de flujo no pueden expresar esto dentro de la notación.

Prácticamente, el uso de diagramas de actividad le permite pensar claramente sobre procesos concurrentes. Creo que encontrará que cualquiera que pueda leer un diagrama de flujo se adaptará rápidamente.

Answer 2

De acuerdo con el sitio de Modelado Ágil :

En muchos sentidos, los diagramas de actividad UML son el equivalente orientado a objetos de diagramas de flujo y diagramas de flujo de datos (DFD) a partir del desarrollo estructurado.

De IBM :

Sin embargo, los diagramas de flujo no incluyen estados Y, y los diagramas de flujo para las operaciones no pueden recibir eventos.

Probablemente es por esto que los diagramas de flujo son más fáciles de entender porque los diagramas de actividad tienen la noción de desarrollo y concurrencia orientados a objetos.

Answer 3

Puede generar código fuente desde UML, y viceversa; de ahí la característica "estandarizada" de la que hablaste.

Answer 4

Puede parecer una preferencia, pero si tenemos un lenguaje estandarizado para describir sistemas de software, ¿por qué utilizamos algo más? Esto puede llevar a la mala costumbre de sobreutilizar diagramas de flujo. Diagramas de actividad son realmente simples. Pero si decide describir un aspecto más complicado del sistema o intenta cambiar la parte que está describiendo, es posible que tenga que cambiar de todos modos. Así que solo use UML y evite confusiones en el futuro.

Answer 5

UML en sí mismo se usa para compartir tu comprensión. Comparte el entendimiento de una manera estandarizada. Como su caso es ad hoc y el uso principal de un diagrama UML es proporcionar un boceto informal, el diagrama de actividad se puede usar aquí. Pero también pueden hacerlo los diagramas de flujo ya que aquí no hay paréntesis. Siempre he encontrado el siguiente argumento para ser útil. ¿El arte que estoy produciendo beneficiará a quién? Y puedo expresar el flujo de una manera auto explicativa usando un diagrama de flujo. Y si es así, entonces debe seguir y usar el diagrama de flujo. Pero si sus diagramas de clase, secuencia, etc. están en formato UML, tendría sentido tener sus diagramas de actividad en UML también por coherencia (el argumento aquí sería, si la gente puede entender clase, secuenciar semántica UML, entonces y no actividad diagramas).