В OOD нет эквивалентной модели. Акцент на DFD - это данные, отделенные от функции. Это наиболее полезно, когда дело касается процедурного подхода. Масштаб DFD намного лучше, чем OOD, если вы пытаетесь масштабировать (до мировоззрения) с помощью OOD, вы в конечном итоге используете диаграммы вариантов использования, которые полезны для захвата сущностей. Мне понравились DFD, они настолько высокого уровня, и все же их можно расширить, открыв окно DFD и назвав его уровнем 1 и т. Д.
Я сейчас нахожусь в процессе изучения языка программирования Go, он вообще не использует объекты, и в некоторых отношениях я чувствую, что моделирование DFD подойдет ему гораздо лучше.
Я тоже ищу схему, которая могла бы выполнять такую работу. В Go интенсивно используются структуры, которые являются основными типами данных. К нему может быть прикреплен примитивный метод расширения, который напоминает OO, но на самом деле, если вы посмотрите на код Assembly, он кажется синтаксическим сахаром для функции, первым параметром которой является структура, с которой вы хотите, чтобы функция работала.
Мой совет: если вы делаете код OO, используйте OOD. Они лучше отображают и помогают в размышлениях о системе. Требуется время, чтобы выкинуть голову из процедурного кода, особенно если вы пришли из программирования 80-х / 90-х годов. Как только вы попадаете в зону с размышлениями об объектах, методы OOD работают нормально. Это не строго методология, поскольку нет четкого ответа на то, какие части вы используете, просто думать о предметах, которые я считаю самой сложной частью. Хорошая книга на эту тему «Объектное мышление - Дэвид Уэст» ... она помогает в первую очередь думать об объектах. Как только вы начинаете, его очень трудно остановить, вам может даже понравиться, что некоторые в конечном итоге окажутся в ловушке в царстве существительных, что является ужасным местом, потому что вы пишете бесконечный код котельной пластины, просто чтобы система описывалась идеально. Это форма адского кодирования, от которой я держался в течение многих лет.
Если вы кодируете на языке, который допускает процедурный код или даже смешанный OO / Procedural, вам нужно определить свою парадигму до начала кодирования, например, как в Python, так и в Object Pascal (Delphi) вы можете пойти любым путем ОО или процедурное кодирование, смешивающее код в кучу парадигм. Это решит, какие инструменты построения диаграмм следует использовать, и как вы собираетесь анализировать систему.
В последнее время в Java и c # произошли сдвиги, обеспечивающие методы функционального программирования. Я обнаружил, что они не попадают ни в одну из категорий программирования (ОО или процедурные). Попытка отобразить код функционального программирования в объект - это кошмар.
Извините, я не предоставил ответ, но это зависит от того, какой код вы пишете.