Назад в темное время (середина 1980-х), я использовал Диаграммы потока данных из "Структурированный анализ" , и нашел их очень полезными.
Мой нынешний работодатель любит UML. Обычно я использую BOUML, который не выполняет рисунки без UML.
Каков чертеж UML, который соответствует диаграмме потока данных?
Если его нет, то какая рекомендуемая UML-диаграмма должна представить соответствующие данные?
Вероятно, наиболее близкой является диаграмма действий . Это не совсем то же самое; больше зависит от блок-схемы, чем dfd. Однако: вы можете делать некоторые полезные вещи в DFD, например. ADs поддерживают concurrency и дифференцируют поток управления от потока данных.
Подробнее о сравнении и различиях в этом вопросе.
[fwiw, я по-прежнему использую DFD: они более простые и элегантные во многих обстоятельствах]
НТН.
В OOD нет эквивалентной модели. Акцент на DFD - это данные, отделенные от функции. Это наиболее полезно при рассмотрении процедур. Шкала DFD намного лучше, чем OOD, если вы пытаетесь масштабировать (с точки зрения мира) с помощью OOD, вы в конечном итоге используете диаграммы Use Case, которые полезны для захвата сущностей. Я любил DFD, что они настолько высокого уровня, и все же их можно расширить, открыв окно DFD и назвав его уровнем 1 и т.д.
В настоящее время я изучаю язык программирования Go, это не использует объекты вообще, и в некоторых отношениях я чувствую, что DFD-моделирование подойдет намного лучше.
Я тоже ищу диаграмму, которая могла бы выполнять такую работу. В структурах Go интенсивно используются базовые типы данных. Вы можете подключить к нему примитивный метод расширения, который напоминает OO, но на самом деле, если вы посмотрите на код сборки, он кажется синтаксическим сахаром для функции, первым параметром которого является структура, которой вы хотите, чтобы функция работала.
Мой совет, что если вы делаете OO-код, используйте OOD. Они лучше отображают и помогают в мышлении о системе. Требуется некоторое время, чтобы вытащить голову из процедурного кода, особенно если вы собираетесь программировать с 80-х/90-х годов. Когда вы находитесь в зоне с мышлением об объектах, методы OOD работают нормально. Это не строго методология, поскольку нет прямого ответа на то, какие части вы используете, просто думая в объектах, которые я считаю самой сложной частью. Хорошая книга об этом - "Объектное мышление - Дэвид Уэст"... это помогает сначала подумать об объектах. Как только вы начнете очень трудно остановиться, вам может показаться, что некоторые из них попадают в ловушку в царстве существительных, что является ужасным местом, потому что вы пишете бесконечный код плиты котла, чтобы система была описана отлично. Это форма кодирующего ада, от которой я не справлялся многие годы.
Если вы кодируете язык, который допускает процедурный код или даже смешанный OO/процедурный, вам нужно решить вашу парадигму перед началом кодирования, например, как в Python, так и в Object Pascal (Delphi), вы можете пройти либо по маршруту OO или процедурное кодирование, смешивающее код в беспорядок парадигм. Это решит, какие инструменты диаграмм нужно использовать, и как вы собираетесь анализировать систему.
Недавно были сдвиги в Java и С#, чтобы обеспечить функциональные методы программирования. Я обнаружил, что они не попадают ни в одну категорию программирования (OO или процедурный). Попытка сопоставить функциональный программный код с объектом - это кошмар.
Я сожалею, что не дал ответа, но это зависит от того, какой код вы пишете.
UML 2 имеет очень хороший аналог схемы потока данных: "диаграмма информационных потоков".
Здесь описываются информационные схемы: https://web.archive.org/web/20121118061853/http://www.uml-diagrams.org/information-flow-diagrams.html
Обратите внимание, что UML 2.5 имеет информационные потоки и информационные элементы, но термин "диаграмма информационных потоков" не является частью официальной таксономии диаграмм UML 2.5. Таким образом, вы просто создаете диаграмму классов или компонентов с большим количеством информационных потоков в ней, чтобы получить свою "диаграмму информационных потоков". Я делаю это все время, используя информационные элементы UML для представления моих данных.
Прямого аналога нет, так как UML подчеркивает дизайн OO, поскольку DFD происходит из анализа и проектирования структурированных систем (SSAD). В UML ряд диаграмм, в частности те, которые входят в группу диаграмм взаимодействия со всеми, имеют характеристики, которые могут моделировать элементы потока данных и обработки. Диаграмма связи может использоваться для отражения большинства аспектов DFD в целом, в то время как диаграмма последовательности может моделировать конкретные последовательности потока. Если вы хотите предложить семантику DFD, вы можете использовать стереотипные объекты для процесса обработки данных и хранения данных и использовать участников для внешних объектов.
Возможно, стоит отметить, что Sparx Systems Enterprise Architect, в основном инструмент UML, включает DFD в качестве расширения.
Теоретически, новые типы диаграмм могут быть определены в UML, опционально расширяя один или несколько обычных типов диаграмм. Типы канонической диаграммы, определенные в UML, по существу определяются как часть самой метамодели UML.
Формально определение метамодели UML приведено в спецификации UML, опубликованной группой управления объектами (OMG), а также соответствующая метаметамодель, определенная MOF, к которой также относится соответствующая спецификация - более того, в сопровождении формального спецификация OCL, как в отношении определений ограничений в моделях UML в приложениях языка OCL в UML, - и затем Спецификация XMI, как в отношении спецификаций того, как модели UML могут храниться в машиночитаемом формате.
Якоря, все эти спецификации могут быть объединены для приложения, как если бы "под капотом" любой единой структуры для моделирования UML - будь то в приложениях подмножества Ecore в метамодели UML или в каноническом UML.
Рассмотрение короткой академической презентации о диаграммах потоков данных - хотя и несколько отличается от формальных определений типов диаграмм UML, но тем не менее в более широком контексте приложений мета-метамодели MOF - возможно, канонической BPMN - в ее условном графическом абстрактном синтаксисе - возможно, BPMN может служат для обеспечения аналогии с диаграммами потока данных?
Конечно, методы моделирования могут различаться в зависимости от поставщика и среды приложения.
Я рассматриваю диаграмму потока данных как диаграмму последовательности, с производителями данных и потребителями данных, создающими, использующими и уничтожающими объекты данных с помощью синхронных и/или асинхронных сообщений.