Различия между DFD (диаграммой потока данных) и диаграммой деятельности

Мне нужно знать эти различия, чтобы понять, как правильно их использовать.

Каковы различия в диаграмме DFD и активности?

Ответ 1

Собственно, это разумно логично. Вам нужно только посмотреть имена.

В диаграммах потоков данных линии между "ящиками" представляют собой данные, которые протекают между компонентами системы. Поскольку они показывают только поток данных, они не дают указания на последовательность.

В диаграммах активности эти строки являются просто переходами между действиями и вообще не представляют поток данных. Они больше представляют собой последовательность действий и решений. Вы можете сказать из этого, в каком порядке происходят события.

Это упрощенное объяснение, но должно быть хорошей отправной точкой. Дополнительная информация может быть получена из Википедии для DFDs и диаграммы действий.

Ответ 2

Явное предвзятое отношение: я сторонник DFD.

@John правильно, что диаграммы активности могут использоваться для представления потока объекта. @pax одинаково корректны, они редко бывают.

Два больших преимущества DFD для меня:

Ссылка на объектную модель. Хранилища данных на DFD обеспечивают действительно хороший способ связывания данных, полученных/потребляемых с объектной моделью. Очень полезно для согласованности и обеспечения того, чтобы ваше мышление было объединено.
Они де-подчеркивают поток управления. Слишком часто разрабатывает чередующиеся последовательности. Диаграммы действий поддерживают concurrency - но для этого требуется, чтобы пользователь (а) помнил и (б) использовал его. Таким образом, по умолчанию используется чрезмерная сериализация. DFD нет. Они закладывают реальные зависимости последовательностей без каких-либо дополнительных усилий со стороны пользователя. Следовательно, они также облегчают просмотр причинно-следственных связей. Если процессы a и b требуют ввода данных D, то это очевидно на диаграмме. И, следовательно, параллельная активность очевидна.

Не поймите меня неправильно - я не против действий. Там, где поток управления является основным соображением, я буду использовать AD для DFD. Но эмпирически я бы сказал, что я нахожу DFD более полезным инструментом в ~ 70-80% случаев.

Конечно, YMMV.

Ответ 3

Просто скромное мнение от кого-то, кто должен был объяснить процессы, как компьютерные, так и ручные, высшему руководству и ИТ-директорам. Я нашел простой, и фунт-за-фунт, DFD получают сообщение, когда я на самом деле "спрашиваю" о деталях. При этом лучший подход заключается в том, чтобы всегда практиковать сюжетную линию и отвечать на простые ответы.

Одно последнее замечание относительно возраста инструментов и продуктов. Помните, что в большинстве случаев они управляют бизнесом и работают довольно хорошо. Поговорка "вы нарушаете ее (или заменяете ее) и владеете ею", может сделать вас героем или превратить вас в клоуна.

У нас есть ИТ-директор, который хочет заменить все приложения для мэйнфреймов по той простой причине, что они являются старыми технологиями. Нужно взвешивать последствия и понимать, может ли замена обрабатывать рабочую нагрузку. Вы когда-нибудь задумывались, почему JPMC, Credit Swiss, Walmart и Bank of America назвали несколько все еще работающих мэйнфреймов?

Приношу свои извинения за то, что вы приняли его в этом направлении. Просто убедитесь, что какой бы инструмент анализа не использовался, что все аспекты замены документированы, включая рабочую нагрузку, ввод-вывод, одновременных пользователей, кривую принятия решений и масштабируемость.

Ответ 4

Data Flow представляет поток внутри одного модуля или одного независимого кода. Однако Sequence Diagram представляет последовательность действий между различными модулями.

Да, в некоторых случаях они могут передавать одни и те же сообщения.

В основном я использую Sequence Diagram в документах интерфейса, которые будут совместно использоваться другими модулями/элементами, однако DFD будет использоваться в документах низкого уровня, которые будут использоваться для разработки кода внутри одного модуля или сетевого элемента.

Ответ 5

Если мы посмотрим ближе к диаграмме потока данных, мы заметим, что когда node собирает данные со всех его ребер, он начинает их обрабатывать. И для обработки ему нужен токен активности, который представляет собой доступ к процессору. Обычно процесс получения этого токена опущен, но он должен существовать. Как правило, весь node в качестве токена помещается в очередь с двумя очередями, где на другом конце этой очереди сохраняются свободные активности (процессоры или потоки). Пул потоков - прекрасный пример такой очереди, а узлы, готовые к работе, представлены как задачи. Как только node встречает активность, они оба берутся из очереди, и начинается фактическая обработка. При завершении обработки активность возвращается в очередь. Таким образом, мы можем рассматривать активность как особый вид токена.

Таким образом, диаграммы потока данных и активности являются просто упрощенными вариантами общей диаграммы активных данных, при этом либо токены, либо токены данных отсутствуют. Но, как правило, оба вида токенов могут быть представлены на диаграмме одновременно.

Программисты обычно рассматривали потоки как действия, но если мы посмотрим на них ближе, мы заметим, что когда поток готов к выполнению, он попадает в очередь на процессоры, а реальное исполнение запускается только тогда, когда свободный процессор переключается на это нить. Это абсолютная аналогия, поскольку задачи выполняются в пуле потоков. Таким образом, с упрощенной точки зрения поток является активностью, и с более строгой точки зрения поток является токеном данных, и единственным реальным видом деятельности является физический процессор. Это показывает, что токены активности не отличаются от токенов данных. И действительно, мы можем опустить маршрут node в погоне за активностью и рассматривать поток данных node как сам процесс, который начинает работать сразу, когда все его ребра (входы) содержат данные.