実際、それはかなり論理的です。名前を見ればいいだけです。
dataフロー図では、「ボックス」間の線は、システムのコンポーネント間を流れるデータを表します。これらはデータの流れを示すだけなので、順序付けを示すものではありません。
activity図では、これらの線は単にアクティビティ間の遷移であり、データフローをまったく表していません。それらは、アクティビティと決定のシーケンスをよりよく表します。これらから、どのような順序で物事が発生するかを知ることができます。
これは単純な説明ですが、出発点として適しています。 DFDs および アクティビティ図 の詳細については、ウィキペディアを参照してください。
明示的なバイアス：私はDFDの支持者です。
@Johnは、アクティビティ図canを使用してオブジェクトフローを表すことが正しいです。 @paxも同様に正しく、めったにありません。
私にとって2つの大きなDFDの利点：
オブジェクトモデルへのリンク。 DFDのデータストアは、生成/消費されたデータをオブジェクトモデルにリンクするための非常に優れた方法を提供します。一貫性を保ち、あなたの考えを結び付けるのに非常に役立ちます。
それらは制御フローを重視しません。多くの場合、過度に制約されたシーケンスを設計します。アクティビティ図は並行性をサポートしていますが、ユーザーは（a）覚えておいて、（b）それを使用する必要があります。したがって、デフォルトはオーバーシリアライズです。 DFDはサポートしていません。それらはrealシーケンスの依存関係をユーザーの側で余計な努力なしに裸にしてくれます。その結果、因果関係を確認しやすくなります。プロセスaとbの両方にデータ入力Dが必要な場合は、図から明らかです。したがって、並行アクティビティは明白です。
誤解しないでください-私はアクティビティ診断に反対しているわけではありません。制御フローが主な考慮事項である場合、DFDではなくADを使用します。しかし、経験的に私は、DFDがケースの70〜80％でより有用なツールであると思います。
もちろん、YMMV。
コンピュータとマニュアルの両方のプロセスを上級管理職とCIOに説明しなければならなかった人からの控えめな意見。私は、シンプルな方がポンド単位で優れていることを発見しました。DFDは、詳細について実際に「質問」されたときにメッセージを受け取ります。そうは言っても、より良いアプローチは、常にストーリーを実践し、単純な答えで答えることです。
ツールと製品の時代に関する最後のコメント。ほとんどの場合、これらはビジネスを運営していて、かなりうまくいきます。 「あなたはそれを壊す（または置き換える）そしてあなたはそれを所有する」という格言は、あなたを英雄にしたり、道化師にしたりすることができます。
古いテクノロジーであるという単純な理由で、すべてのメインフレームアプリケーションを置き換えたいCIOがいます。影響を比較検討し、代替品がワークロードを処理できるかどうかを理解する必要があります。 JPMC、Credit Swiss、Walmart、Bank of Americaがなぜまだメインフレームを実行しているのかと思ったことがありますか？
その方向に進んだことをお詫びします。使用する分析ツールがどのようなものであっても、ワークロード、I/O、同時ユーザー、採用曲線、スケーラビリティなど、置換のすべての側面が文書化されていることを確認してください。
データフロー図をよく見ると、ノードがすべてのエッジからデータを収集すると、ノードがそれらの処理を開始することがわかります。処理するには、プロセッサへのアクセスを表すアクティビティトークンが必要です。通常、そのトークンを取得するプロセスは省略されますが、存在する必要があります。通常、トークンとしてのノード全体は、両端キューに入れられます。キューの反対側には、空きアクティビティ（プロセッサまたはスレッド）が格納されます。スレッドプールはそのようなキューの完璧な例であり、作業の準備ができているノードはタスクとして表されます。ノードがアクティビティに遭遇するとすぐに、両方がキューから取得され、実際の処理が開始されます。処理が完了すると、アクティビティがキューに返されます。このように、私たちは活動を特別な種類のトークンと考えることができます。
したがって、データフローダイアグラムとアクティビティダイアグラムはどちらも、アクティビティまたはデータトークンのいずれかが省略された、一般的なアクティブデータフローダイアグラムの単純化されたバリエーションです。ただし、一般的には、両方の種類のトークンを同時にダイアグラムで表すことができます。
プログラマーはスレッドをアクティビティと見なしていましたが、スレッドを詳しく見てみると、スレッドを実行する準備ができると、プロセッサーに並ぶようになり、実際の実行は、空きプロセッサーがそのスレッドに切り替えたときにのみ開始されます。タスクはスレッドプールで実行されるため、これは完全に類似しています。したがって、単純化された観点から見ると、スレッドはアクティビティであり、より厳密な観点から見ると、スレッドはデータトークンであり、実際の唯一のアクティビティは物理プロセッサです。これは、アクティビティトークンがデータトークンと変わらないことを示しています。実際、アクティビティを追跡するノードのルートを省略して、データフローノードをアクティビティ自体と見なすことができます。アクティビティ自体は、すべてのエッジ（入力）にデータが含まれるとすぐに機能し始めます。
Data Flowは、1つのモジュールまたは1つの独立したコード内のフローを表します。しかしながら Sequence Diagramは、異なるモジュール間のアクティビティのシーケンスを表します。
はい、いくつかの点で同じメッセージを渡すことがあります。
基本的にSequence diagram他のモジュール/要素と共有されるインターフェイスドキュメント内ですが、DFDは、1つのモジュールまたはネットワーク要素内でコードを開発するために使用される低レベルデザインドキュメントで使用されます。