流程圖與UML活動圖

Question

使用流程圖和UML活動圖之間的實際區別是什麼？ 我有一些想法，但也許我錯過了房間裏的一隻大象？

流程圖：

1. 廣泛的應用;
2. 非程序員易於理解;
3. 舊？

UML活動圖：

1. 標準化;
2. 支持併發性;
3. 語法較少，但仍然很簡單。

對於我特設的應用程序邏輯塊來說，我決定去看流程圖。公司中的更多人將能夠理解他們。

Answer 1

這看起來可能是一種偏好，但如果我們有描述軟件系統的標準化語言，爲什麼我們會使用其他的東西呢？這可能導致過度使用流程圖的壞習慣。活動圖很簡單。但是，如果您決定描述系統的更復雜的方面或嘗試更改所描述的部分，則無論如何您可能必須切換。因此，只需使用UML並防止將來出現混淆。

Answer 2

正如您所看到的，活動圖固有地可以包含併發和時間。如果您查看維基百科的cribbed this example（如果僅支持SO支持SVG格式，我會插入），您可以觀察具有兩個重橫條的節，以及兩個「當前創意」和「創意創意」的平行活動。這被認爲是「並行開始這些活動，並且只有在兩者都完成時才繼續。」流程圖無法在符號內表達。

實際上，使用活動圖可以讓您清楚地瞭解併發過程。我想你會發現任何能夠閱讀流程圖的人都會很快適應。

Answer 3

您可以從UML生成源代碼，反之亦然;因此你提到的「標準化」特徵。

Answer 4

UML本身就是用來分享你的理解。以標準化的方式分享理解。由於您的案例是臨時的，UML圖的主要用途是提供非正式的草圖，因此可以在此處使用活動圖。但是，流程圖也是如此，因爲這裏沒有涉及任何遺留問題。我總是發現以下論點是有用的。我正在製作的這件藝術品會讓誰受益？我可以使用流程圖以自解釋的方式表達流程。如果是，那麼你應該繼續使用流程圖。但是如果你的類圖，序列等都是UML格式的，那麼爲了一致性考慮你的活動圖也是有意義的（這裏的論點是，如果人們可以理解類，序列UML語義，那麼y不是活動圖。）。

Answer 5

按照Agile Modeling站點：

在許多方面UML活動圖是面向對象的等效結構從發展的流程圖和數據流圖（的DFD）的。

從IBM：

然而，流程圖不包括與國家和流運營不能接收事件的圖表。

也許這就是爲什麼流程圖更容易理解的原因，因爲活動圖具有面向對象開發和併發的概念。