simbologia secuencia nivel hacer flujo estados ejemplos diagrama datos como actividades uml

uml - secuencia - Diferencias entre DFD(Diagrama de flujo de datos) y diagrama de actividad



diagrama de flujo de datos nivel 0 (5)

En realidad, es razonablemente lógico. Solo hay que mirar los nombres.

En los diagramas de flujo de datos , las líneas entre "cuadros" representan datos que fluyen entre los componentes de un sistema. Debido a que estos solo muestran el flujo de datos, no dan una indicación de secuenciación.

En los diagramas de actividades , esas líneas son simplemente transiciones entre actividades y no representan en absoluto el flujo de datos. Ellos más representan la secuenciación de actividades y decisiones. Puedes decir a partir de esto en qué orden suceden las cosas.

Esa es una explicación simplista pero debería ser un buen punto de partida. Se puede obtener más información de Wikipedia para DFDs y diagramas de actividad .

Necesito saber estas diferencias para entender cómo usarlas correctamente.

¿Cuáles son las diferencias entre DFD y diagrama de actividad?


Sesgo explícito: soy un defensor de DFDs.

@John tiene razón en que los diagramas de actividad se pueden usar para representar el flujo de objetos. @pax igualmente correctos que rara vez son.

Dos grandes ventajas de DFD para mí:

  1. Enlace al modelo de objeto. Los almacenes de datos en un DFD proporcionan una manera realmente agradable de vincular los datos producidos / consumidos al modelo de objetos. Muy útil para la coherencia y para asegurar que su pensamiento esté unido.

  2. De-enfatizan el flujo de control. Con demasiada frecuencia, los diseños de secuencia de restricción excesiva. Los diagramas de actividad admiten la concurrencia, pero requieren que el usuario (a) recuerde y (b) la use. Por lo tanto, el valor predeterminado es la sobre serialización. DFDs no lo hacen. Ellos dejan al descubierto las dependencias de la secuencia real sin ningún esfuerzo adicional por parte del usuario. En consecuencia, también hacen que sea más fácil ver las relaciones causales. Si los procesos ayb requieren la entrada de datos D, es obvio en el diagrama. Y por lo tanto la actividad paralela es obvia.

No me malinterpretes, no estoy en contra de los diagnósticos de actividad. Donde el flujo de control es la consideración principal, usaré un AD sobre un DFD. Pero empíricamente, diría que considero que los DFD son una herramienta más útil en ~ 70-80% de los casos.

Por supuesto, YMMV.


Si nos fijamos más en un diagrama de flujo de datos, podemos notar que cuando un nodo recopila datos de todos sus bordes, comienza a procesarlos. Y para procesarlo, necesita un token de actividad, que representa el acceso a un procesador. Por lo general, el proceso de obtener ese token se omite, pero tiene que existir. Normalmente, todo el nodo como un token se coloca en una cola de doble extremo, donde en el otro extremo de esa cola se almacenan las actividades libres (procesadores o subprocesos). Un grupo de subprocesos es un ejemplo perfecto de dicha cola, y los nodos listos para trabajar se representan como tareas. Tan pronto como un nodo se encuentra con la actividad, ambos se toman de la cola y comienza el procesamiento real. Cuando termina el procesamiento, la actividad se devuelve a la cola. De esta manera podemos pensar en la actividad como un tipo especial de token.

Por lo tanto, tanto el flujo de datos como los diagramas de actividad son solo variantes simplificadas de un diagrama general de flujo de datos activos, con actividades o tokens de datos omitidos. Pero en general, ambos tipos de tokens se pueden representar en un diagrama simultáneamente.

Los programadores solían pensar en los subprocesos como actividades, pero si los observamos más de cerca, notamos que cuando un subproceso está listo para ejecutarse, se pone en línea con los procesadores, y la ejecución real comienza solo cuando un procesador libre cambia a ese subproceso. Esto es una analogía absoluta ya que las tareas se ejecutan en un grupo de subprocesos. Entonces, desde el punto de vista simplificado, un hilo es una actividad, y desde un punto de vista más riguroso, un hilo es un token de datos y la única actividad real es un procesador físico. Esto muestra que los tokens de actividad no son diferentes de los tokens de datos. Y, de hecho, podemos omitir la ruta del nodo que persigue una actividad y considerar un nodo de flujo de datos como una actividad en sí misma, que comienza a funcionar inmediatamente cuando todos sus bordes (entradas) contienen datos.


Data Flow representa el flujo dentro de un módulo o un código independiente. Sin embargo, el Sequence Diagram secuencia representa la secuencia de actividad entre diferentes módulos.

Sí, en algunos puntos pueden pasar los mismos mensajes.

Básicamente, uso el Sequence diagram en documentos de interfaz que se compartirán con otros módulos / elementos, sin embargo, DFD se usará en documentos de diseño de bajo nivel que se utilizarán para desarrollar el código dentro de un módulo o elemento de red.


Solo una opinión humilde de alguien que ha tenido que explicar los procesos, tanto informáticos como manuales, a la alta dirección y los CIO. Descubrí que simple es mejor y libra por libra, los DFD transmiten el mensaje cuando en realidad me "preguntan" sobre los detalles. Dicho esto, el mejor enfoque es practicar siempre la línea de la historia y responder en respuestas simples.

Un último comentario sobre la edad de las herramientas y productos. Recuerde que, en la mayoría de los casos, estos son los que manejan el negocio y funcionan bastante bien. El adagio "lo rompes (o lo sustituyes) y lo posees" puede convertirte en un héroe o convertirte en un payaso.

Tenemos un CIO que quiere reemplazar todas las aplicaciones de mainframe por la sencilla razón de que son tecnologías antiguas. Uno debe sopesar las consecuencias y comprender si el reemplazo puede manejar la carga de trabajo. ¿Alguna vez se ha preguntado por qué JPMC, Credit Swiss, Walmart y Bank of America nombran algunos mainframes aún ejecutados?

Mis disculpas por tomarlo en esa dirección. Solo asegúrese de que, sea cual sea la herramienta de análisis que se utilice, que todos los aspectos del reemplazo estén documentados, incluida la carga de trabajo, la E / S, los usuarios concurrentes, la curva de adopción y la escalabilidad.