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