フロー図とUMLアクティビティ図の実際的な違いは何ですか？ 私はいくつかの考えを持っていますが、おそらく私は部屋に象を逃していますか？フロー図とUMLアクティビティ図
フローチャート図：広く使用されている
UMLアクティビティ図：標準
アプリケーションロジックの特定のブロックをアドホックに書いている私のケースでは、私はフローチャートダイアグラムに進むことにしました。同社の多くの人々がそれらを理解することができます。
ソフトウェアシステムを記述するための標準化された言語がある場合は、何か別のものを使用するのはなぜですか？これは、フローチャートを過度に使用する悪い習慣につながる可能性があります。アクティビティ図はとてもシンプルです。しかし、システムのより複雑な側面を記述したり、記述している部分を変更しようとすると、とにかく切り替えなければならない可能性があります。だから、UMLを使用して、将来混乱を避けるだけです。 Agile Modelingサイトによれば
アクティビティ図には、本質的に並行性とタイミングが含まれることに注意してください。 Wikipediaのthis exampleを見ると、2つの重い水平バーと2つの平行した "present idea"と "record idea"という2つのアクティビティがあります。これは、「これらの活動を並行して開始し、両方が完了したときにのみ継続する」と読まれています。フローチャートはこれを表記法で表現することはできません。
実際には、アクティビティ図を使用すると、並行処理について明確に考えることができます。私はあなたがフローチャートを読むことができる誰もがすぐに適応することを見つけるだろうと思う。
UMLからソースコードを生成することができます。逆も同様です。したがってあなたが話した「標準化された」特性です。
私はこれがクラス図にもっと当てはまると思います。また、コードが変更されたときにダイアグラムを再構築できる、まともな往復ジェネレータをまだ見つけていません。 –
@Vladimir Sinenko：アクティビティモデルのロジックを実装するコードを生成できる場合は、ラウンドトリップを探すことはしません。アクティビティモデルを変更するだけです。 –
UML自体があなたの理解を共有するために使用されます。理解を標準化された方法で共有する。あなたのケースは臨機応変でUMLダイアグラムの主な用途は非公式のスケッチを提供することなので、アクティビティ図をここで使用できます。しかし、ここで関与しているparellismがないので、フローチャートもあります。私はいつも助けになるために次の議論を見つけました。私が作り出している工芸品は誰に利益をもたらすだろうか？そして、私はフローチャートを使って、説明的な方法でフローを表現することができます。もしそうなら、あなたは先に進んでフローチャートを使うべきです。しかし、クラス図、シーケンスなどがUML形式であれば、アクティビティ図をUMLで一貫性のあるものにすることは理にかなっています（ここでの議論は、クラス、シーケンスUMLの意味を理解し、ダイアグラム）。
：アクティビティ図UML多くの方法で
は、構造化開発のフローチャート及びデータフロー図（のDFD）のオブジェクト指向等価です。
IBMから：
しかし、フロー・チャートは、操作のためのチャートがイベントを受け取ることができません含めるや状態、および流動しません。
これは、アクティビティ図にオブジェクト指向の開発と同時実行という概念があるため、フローチャートがわかりやすくなるためです。
ありがとう、チャーリー、私も元の投稿のその点を述べた。私の場合、ロジックはシングルスレッドなので、フローチャートとアクティビティ図の両方が適合します。 –