Блок-схемы и диаграммы активности UML

Question

В чем практическая разница между использованием блок-схем и диаграмм активности UML? У меня есть мысли, но, может быть, мне не хватает слона в комнате?

Блок-схема:

1. Широко используется;
2. Легко для понимания непрограммистами;
3. Старый

Диаграмма активности UML:

1. Стандартизированная;
2. Поддерживает параллелизм;
3. Менее известный синтаксис, но все еще достаточно простой.

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

Answer 1

Это может показаться предпочтением, но если у нас есть стандартизированный язык для описания программных систем, почему мы используем что-то еще? Это может привести к плохой привычке злоупотреблять блок-схемами. Диаграммы деятельности действительно просты. Но если вы решите описать более сложный аспект системы или попытаетесь изменить часть, которую вы описываете, вам, возможно, придется все равно переключиться. Так что просто используйте UML и не допускайте путаницы в будущем.

Answer 2

Как вы заметили, диаграммы активности по своей природе могут включать параллелизм и синхронизацию. Если вы посмотрите на этот пример , взятый из Википедии, показанный ниже, вы можете наблюдать раздел с двумя тяжелыми горизонтальными полосами и двумя параллельными действиями «настоящей идеи» и «записи идеи». Это читается как «начинайте эти действия параллельно и продолжайте только после завершения обоих». Блок-схемы не могут выразить это в обозначениях.

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

Диаграмма деятельности от пользователя из Википедии Gwaur CC BY-SA 3.0 , через Wikimedia Commons:

Answer 3

По данным сайта Agile Modeling :

Во многих отношениях диаграммы деятельности UML являются объектно-ориентированным эквивалентом блок-схем и диаграмм потоков данных (DFD) из структурированной разработки.

С IBM :

Однако потоковые диаграммы не включают в себя состояния And, а потоковые диаграммы для операций не могут получать события.

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

Answer 4

UML сам по себе используется, чтобы поделиться вашим пониманием. Делитесь пониманием стандартизированным способом. Поскольку ваш случай является специальным, и основное использование UML-диаграммы заключается в предоставлении неформального эскиза, здесь можно использовать диаграмму действий. Но так могут быть потоковые диаграммы, так как здесь нет пареллизма. Я всегда находил следующий аргумент полезным. Артефакт, который я создаю, пойдет на пользу кому? И могу ли я выразить поток понятным способом, используя блок-схему. И если да, то вы должны пойти дальше и использовать блок-схему. Но если ваши диаграммы классов, последовательности и т. Д. Имеют формат UML, то было бы целесообразно иметь диаграммы активности в UML также для обеспечения согласованности (аргументом здесь будет то, что если люди могут понять класс, семантику последовательности UML, то у вас нет активности диаграммы.).

Answer 5

Вы можете генерировать исходный код из UML и наоборот;отсюда и «стандартизированная» характеристика, о которой вы говорили.