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