objetos - uml diagrama de clases

¿Qué es el análogo de UML al Diagrama de flujo de datos del análisis estructurado? (7)

De vuelta en la Edad Media (mediados de la década de 1980), utilicé una buena cantidad de los Diagramas de flujo de datos del análisis estructurado , y los encontré muy útiles.

Mi empleador actual ama UML. Normalmente uso BOUML, que no hace dibujos que no sean UML.

¿Cuál es el dibujo UML que corresponde al diagrama de flujo de datos?

Si no hay uno, ¿cuál es el diagrama UML recomendado para presentar los datos correspondientes?

Considero un diagrama de flujo de datos como un diagrama de secuencia, donde los productores de datos y los consumidores de datos crean, utilizan y destruyen objetos de datos por medio de mensajes síncronos y / o asíncronos.

Diagramas similares serían:

diagrama de flujo de información
diagrama de comunicación
diagrama de secuencia

No hay un análogo directo, ya que UML enfatiza el diseño OO cuando DFD proviene del análisis y diseño de sistemas estructurados (SSAD). En UML, una serie de diagramas, específicamente aquellos en el grupo de diagramas de interacción , tienen características que pueden modelar elementos del flujo y procesamiento de datos. Un diagrama de comunicación puede usarse para reflejar la mayoría de los aspectos de un DFD en general, mientras que un diagrama de secuencia puede modelar secuencias específicas de flujo. Si quisiera sugerir semántica de DFD, podría usar objetos estereotipados para el proceso de datos y el almacén de datos, y utilizar actores para entidades externas.

Puede valer la pena señalar que Sparx Systems Enterprise Architect, mientras que principalmente una herramienta UML incluye DFD como una extensión.

No hay un modelo equivalente en OOD. El énfasis en los DFD son datos separados de la función. Esto es más útil cuando se trata de una manera procesal. La escala del DFD es mucho mejor que la OOD. Si intentas escalar (a la vista del mundo) utilizando la OOD, terminas utilizando los diagramas de casos de uso, que son útiles para capturar esencias. Me encantaron los DFD, son de un nivel tan alto y, sin embargo, se pueden ampliar abriendo una caja de DFD y llamándola nivel 1, etc.

Actualmente estoy en el proceso de aprender el lenguaje de programación Go, esto no utiliza Objetos en absoluto y, en algunos aspectos, creo que el modelado DFD se adaptaría mucho mejor.

Yo también estoy buscando un diagrama que pueda hacer este tipo de trabajo. En Go, las estructuras se utilizan de forma intensiva, que son tipos de datos básicos. Se le puede adjuntar un método de extensión primitiva que se parece a OO pero, de hecho, si observa el código de Ensamblaje parece ser una sintaxis de azúcar para una función, cuyo primer parámetro es la estructura en la que desea que funcione la función.

Mi consejo es que si estás haciendo un código OO, usa OOD. Se mapean mejor y ayudan a pensar sobre un sistema. Le toma un tiempo sacar su cabeza del código de procedimiento, especialmente si viene de la programación de los 80/90. Una vez que estás en la zona pensando en los objetos, los métodos OOD funcionan bien. No es estrictamente una metodología, ya que no hay una respuesta directa a las partes que usas, solo pensar en los objetos que encuentro son las más difíciles. Un buen libro sobre esto es "Object Thinking - David West" ... ayuda pensar primero en los objetos. Una vez que empiezas es muy difícil de detener, incluso te puede gustar que algunos acaben atrapados en el reino de los sustantivos, que es un lugar horrible, porque escribes un código interminable de placas de calderas, para que el sistema se describa perfectamente. Esta es una forma de codificar el infierno del que me he mantenido alejado durante muchos años.

Si está codificando en un idioma que permite un código de procedimiento, o incluso un OO / procedimiento mixto, debe decidir su paradigma antes de comenzar a codificar, por ejemplo, tanto en Python como en Object Pascal (Delphi) puede ir por una ruta de OO o por un procedimiento. Codificación mezclando el código en un lío de paradigmas. Esto decidirá qué herramientas de diagramación se deben utilizar y cómo analizará el sistema.

Recientemente se han producido cambios en Java y c # para proporcionar técnicas de programación funcional. Estos que he descubierto no se incluyen en ninguna de las categorías de programación (OO o de procedimiento). Tratar de asignar el código de programación funcional a un objeto es una pesadilla.

Lamento no haber proporcionado una respuesta, pero depende del código que esté escribiendo.

Probablemente lo más cercano sea el diagrama de actividad . No es exactamente lo mismo; Más influenciado por el diagrama de flujo que dfd. Sin embargo: puede hacer algunas de las cosas útiles en los DFD, por ejemplo, los AD admiten la concurrencia y diferencian el flujo de control del flujo de datos.

Más detalles sobre comparaciones y diferencias en esta pregunta .

[Fwiw, todavía uso DFDs: son más simples y elegantes en muchas circunstancias]

hth

Teóricamente, los nuevos tipos de diagramas se pueden definir en UML, opcionalmente extendiéndose de uno o más tipos de diagramas convencionales. Los tipos de diagramas canónicos definidos en UML se definen esencialmente como parte del mismo metamodelo UML.

Formalmente, se proporciona una definición del metamodelo UML en la especificación UML publicada por el Object Management Group (OMG), así como el metamodelo correspondiente definido de MOF, para el cual también hay una especificación correspondiente , además de acompañado del especificación OCL formal, con respecto a las definiciones de restricciones en modelos UML en aplicaciones del lenguaje OCL en UML, y luego está la especificación XMI , en relación con las especificaciones sobre cómo se pueden almacenar los modelos UML en formato legible por máquina.

Aparentemente, todas estas especificaciones se pueden combinar para la aplicación como si fuera "Bajo el capó" de cualquier marco único para el modelado UML, ya sea en aplicaciones del subconjunto Ecore del metmodelo UML o en UML canónico.

Revisar una breve presentación académica sobre los diagramas de flujo de datos, aunque se aleja un poco de las definiciones formales de los tipos de diagramas UML, pero no obstante, en un contexto más amplio de aplicaciones del metamodelo MOF, tal vez el metamodelo BPMN canónico, en su sintaxis abstracta gráfica convencional. - ¿ Quizás BPMN pueda servir para proporcionar una analogía con los diagramas de flujo de datos?

Por supuesto, las prácticas de modelado pueden variar según el proveedor y el entorno de la aplicación.

UML 2 tiene un analógico muy bueno para un diagrama de flujo de datos: el "diagrama de flujo de información".

Los diagramas de flujo de información se explican aquí: https://web.archive.org/web/20121118061853/http://www.uml-diagrams.org/information-flow-diagrams.html

Tenga en cuenta que UML 2.5 tiene flujos de información y elementos de información, pero el término "diagrama de flujo de información" no forma parte de la taxonomía oficial del diagrama de UML 2.5. Así que formalmente, simplemente creas un diagrama de clase o componente con una gran cantidad de flujos de información para obtener tu "diagrama de flujo de información". Hago esto todo el tiempo, usando elementos de información de UML para representar mis datos.