Различия между DFD (Диаграмма потока данных) и диаграммой активности
Мне нужно знать эти различия, чтобы понять, как правильно их использовать.
Каковы различия DFD и диаграммы деятельности?
5 ответов
На самом деле, это достаточно логично. Вам нужно только посмотреть на имена.
На диаграммах потоков данных линии между "блоками" представляют данные, которые передаются между компонентами системы. Поскольку они показывают только поток данных, они не дают указания на последовательность.
На диаграммах действий эти линии являются просто переходами между действиями и вообще не представляют поток данных. Они больше представляют последовательность действий и решений. По ним можно узнать, в каком порядке происходят вещи.
Это упрощенное объяснение, но оно должно стать хорошей отправной точкой. Дополнительную информацию можно получить из Википедии для DFD и диаграмм действий.
Явный уклон: я сторонник DFD.
@John правильно, что диаграммы деятельности могут быть использованы для представления потока объекта. @pax одинаково правильно они редко бывают.
Два больших преимущества DFD для меня:
Ссылка на объектную модель. Хранилища данных на DFD предоставляют действительно хороший способ связать данные, полученные / потребленные с объектной моделью. Очень полезно для последовательности и обеспечения того, что ваше мышление объединено.
Они не подчеркивают поток управления. Слишком часто проектируется чрезмерное ограничение последовательности. Диаграммы действий поддерживают параллелизм, но он требует от пользователя (а) запомнить и (б) использовать его. Поэтому по умолчанию используется чрезмерная сериализация. DFD не делают. Они обнажают реальные зависимости последовательности без каких-либо дополнительных усилий со стороны пользователя. Следовательно, они также облегчают видеть причинно-следственные связи. Если процессы a и b требуют ввода данных D, это очевидно на диаграмме. И поэтому параллельная деятельность очевидна.
Не поймите меня неправильно - я не против Диаграмм Деятельности. Там, где поток управления является основным фактором, я буду использовать AD над DFD. Но опытным путем я бы сказал, что считаю DFD более полезным инструментом в ~70-80% случаев.
Конечно, YMMV.
Просто скромное мнение человека, которому приходилось объяснять процессы, как компьютерные, так и ручные, высшему руководству и ИТ-директорам. Я обнаружил, что простое - это лучше, и фунт за фунт, DFD передают сообщение, когда меня фактически "спрашивают" о деталях. При этом лучший подход - всегда практиковать сюжетную линию и отвечать простыми ответами.
Один последний комментарий относительно возраста инструментов и продуктов. Помните, что в большинстве случаев они ведут бизнес и работают чертовски хорошо. Пословица "ты сломаешь (или заменишь) и сделаешь это") может сделать тебя героем или превратить тебя в клоуна.
У нас есть ИТ-директор, который хочет заменить все приложения для мэйнфреймов по той простой причине, что они являются старой технологией. Нужно взвесить последствия и понять, может ли замена справиться с рабочей нагрузкой. Вы когда-нибудь задумывались, почему JPMC, Credit Swiss, Walmart и Bank of America называют несколько еще работающих мейнфреймов?
Приношу свои извинения за то, что принял это в этом направлении. Просто убедитесь, что независимо от того, какой инструмент анализа используется, все аспекты замены документированы, включая рабочую нагрузку, ввод-вывод, одновременных пользователей, кривую принятия и масштабируемость.
Если мы посмотрим ближе на диаграмму потока данных, мы можем заметить, что когда узел собирает данные со всех своих ребер, он начинает их обрабатывать. А для обработки ему нужен токен активности, который представляет доступ к процессору. Обычно процесс получения этого токена опускается, но он должен существовать. Как правило, весь узел в качестве токена помещается в двустороннюю очередь, где на другом конце этой очереди хранятся свободные действия (процессоры или потоки). Пул потоков - прекрасный пример такой очереди, и готовые к работе узлы представлены в виде задач. Как только узел встречает активность, они оба извлекаются из очереди и начинается фактическая обработка. Когда обработка заканчивается, активность возвращается в очередь. Таким образом, мы можем думать об активности как об особом знаке.
Таким образом, и диаграммы потоков данных, и операции - это просто упрощенные варианты общей диаграммы потоков активных данных, в которых опущены либо операции, либо токены данных. Но в целом оба вида токенов могут быть представлены на диаграмме одновременно.
Программисты привыкли думать о потоках как о действиях, но если мы посмотрим на них поближе, мы заметим, что когда поток готов к выполнению, он попадает в очередь к процессорам, и реальное выполнение начинается только тогда, когда свободный процессор переключается на этот поток. Это абсолютная аналогия, поскольку задачи выполняются в пуле потоков. Таким образом, с упрощенной точки зрения поток - это действие, а с более строгой точки зрения поток - это токен данных, и единственное реальное действие - это физический процессор. Это показывает, что токены активности не отличаются от токенов данных. И действительно, мы можем опустить маршрут узла, преследующего действие, и рассматривать узел потока данных как само действие, которое начинает работать немедленно, когда все его ребра (входы) содержат данные.
Data Flow представляет поток внутри одного модуля или одного независимого кода. тем не мение Sequence Diagram представляет последовательность действий между различными модулями.
Да, в некоторых местах они могут передавать одни и те же сообщения.
Я в основном пользуюсь Sequence diagram в интерфейсных документах, которые будут предоставлены другим модулям / элементам, однако DFD будет использоваться в проектной документации низкого уровня, которая будет использоваться для разработки кода внутри одного модуля или сетевого элемента.