フローチャート図とUMLアクティビティ図
フローチャート図とUMLアクティビティ図の使用の実際の違いは何ですか？何か考えはありますが、部屋に象がいないのではないでしょうか？
フローチャート図：
- 広く使われています;
- プログラマでない人でも簡単に理解できます。
- 古い？
UMLアクティビティ図：
- 標準化;
- 並行性をサポートします。
- あまり知られていない構文ですが、それでも十分簡単です。
アプリケーションロジックの特定のブロックをアドホックドキュメント化する私のケースでは、フローチャート図を使用することにしました。会社のより多くの人々がそれらを理解することができます。
それは好みのように思えるかもしれませんが、ソフトウェアシステムを記述するための標準化された言語がある場合、なぜ他の何かを使用するのですか？これは、フローチャートを使いすぎるという悪い習慣につながる可能性があります。アクティビティ図は本当にシンプルです。しかし、システムのより複雑な側面を説明するか、説明している部分を変更しようとする場合は、とにかく切り替える必要があります。したがって、UMLを使用するだけで、将来の混乱を防ぐことができます。
お気づきのとおり、アクティビティ図には本質的に並行性とタイミングが含まれます。 この例 Wikipediaから引用すると、以下に示すように、2つの太い水平バーと、「現在のアイデア」と「アイデアの記録」の2つの並行アクティビティがあるセクションを観察できます。これは「これらのアクティビティを並行して開始し、両方が完了した場合にのみ継続する」と読みます。フローチャートでは、これを表記内で表現することはできません。
実際には、アクティビティ図を使用すると、並行プロセスについて明確に考えることができます。フローチャートを読むことができる人は誰でもすぐに適応するでしょう。
アクティビティ図 スペイン語版ウィキペディアユーザーGwaur CC BY-SA 3. 、ウィキメディアコモンズ経由： 
アジャイルモデリング サイトによると：
多くの点で、UMLアクティビティ図は、構造化開発のフローチャートおよびデータフロー図（DFD）に相当するオブジェクト指向の図です。
[〜＃〜] ibm [〜＃〜] から：
ただし、フローチャートにはAnd状態が含まれず、操作のフローチャートはイベントを受信できません。
アクティビティ図にはオブジェクト指向の開発と並行性の概念があるため、おそらくこれがフローチャートの理解を容易にする理由です。
UMLからソースコードを生成でき、その逆も可能です。したがって、あなたが話した「標準化された」特性です。
UML自体は、理解を共有するために使用されます。標準化された方法で理解を共有します。あなたのケースはアドホックであり、UMLダイアグラムの主な用途は非公式のスケッチを提供することであるため、アクティビティダイアグラムをここで使用できます。ただし、ここには並列性が含まれていないため、フローチャートも可能です。私はいつも次の議論が役立つことを発見しました。私が制作しているアーティファクトは誰に利益をもたらすでしょうか？また、フローチャートを使用して、フローを自明な方法で表現できますか。はいの場合は、先に進み、フローチャートを使用する必要があります。ただし、クラス図、シーケンスなどがUML形式の場合、一貫性を保つためにアクティビティ図もUMLにすることは理にかなっています（ここでの引数は、クラス、シーケンスUMLのセマンティクスを理解できれば、アクティビティではありません）図）.