構造化分析のデータフローダイアグラムに類似したUMLとは何ですか？
UML 2には、データフローダイアグラムに非常によく似た「情報フローダイアグラム」があります。
情報フロー図はここで説明されています： https://web.archive.org/web/20121118061853/http://www.uml-diagrams.org/information-flow-diagrams.html
UML 2.5には情報フローと情報アイテムがありますが、「情報フロー図」という用語は、公式のUML 2.5図の分類法の一部ではありません。したがって、正式には、大量の情報フローを含むクラス図またはコンポーネント図を作成して、「情報フロー図」を取得します。私は、UMLの情報項目を使用して自分のデータを表すことで、常にこれを行っています。
OODには同等のモデルはありません。 DFDに重点を置いているのは、機能から分離されたデータです。これは、手続き的な方法で処理する場合に最も役立ちます。 DFDのスケールはOODよりもはるかに優れています。OODを使用して（ワールドビューに）スケールアウトしようとすると、エッセンスのキャプチャに役立つユースケース図を使用することになります。私はDFDが大好きでした。それらは非常に高いレベルですが、DFDボックスを開いてレベル1と呼ぶことで拡張できます。
私は現在Goプログラミング言語を学習しています。これはオブジェクトをまったく使用していません。いくつかの点で、DFDモデリングがはるかに適していると感じています。
私もこのような作業を行うことができる図を探しています。 Goでは、基本的なデータ型である構造体が頻繁に使用されます。 OOのようなプリミティブ拡張メソッドをアタッチすることができますが、実際には、アセンブリコードを見ると、それは関数の構文シュガーであるように見えます。最初のパラメーターは希望する構造体です操作する関数。
私のアドバイスは、OOコードを実行している場合はOODを使用することです。これらはより適切にマッピングされ、システムについての考え方を支援します。頭から抜け出すにはしばらく時間がかかります手続き型コード、特に80年代/ 90年代のプログラミングから来ている場合。オブジェクトについて考えるゾーンに入ると、OODメソッドは正常に機能します。厳密には方法論ではありません。使用して、私が最も難しい部分であると思うオブジェクトを考えるだけです。これについての良い本は「オブジェクト思考-デビッドウェスト」です...それは最初にオブジェクトについて考えるのに役立ちます。システムが完全に記述されるように、無限のボイラープレートコードを記述しているため、恐ろしい場所である名詞の王国に閉じ込められてしまうようなものです。何年もの間。
手続き型コード、またはOOと手続き型の混合を許可する言語でコーディングしている場合、コーディングを開始する前にパラダイムを決定する必要があります。たとえば、PythonとObject Pascal（Delphi）の両方） OOのいずれかのルート、またはコードを混乱させてパラダイムに混ぜる手続き型コーディングのいずれかを使用できます。これにより、使用するダイアグラムツールとシステムの分析方法が決まります。
最近Javaとc＃にシフトがあり、関数型プログラミング手法を提供しています。これらがプログラミングのカテゴリ（OOまたは手続き型）に分類されないことを発見しました。関数型プログラミングコードをオブジェクトは悪夢です。
申し訳ありませんが、答えを提供していませんが、それはあなたが書いているコードによって異なります。
UMLはOO設計を強調するため、直接的な類似物はありません。DFDは構造化システム分析および設計（SSAD）に由来します。UMLでは、多数の図、特にwith interaction図グループには、データフローと処理の要素をモデル化する特性があります。コミュニケーション図は、DFDの一般的なほとんどの側面を反映するために使用できますが、シーケンス図は、フローの特定のシーケンスをモデル化できます。DFDを提案する場合セマンティクスを使用すると、データ処理とデータストアにステレオタイプオブジェクトを使用し、外部エンティティにアクターを使用できます。
Sparx Systems Enterprise Architectには主にUMLツールがDFDが拡張機能として含まれていますが、注目に値するかもしれません。
同様の図は次のようになります。
- 情報フロー図
- コミュニケーション図
- シーケンス図
私は、データフロー図をシーケンス図と見なします。データプロデューサーとデータコンシューマーは、同期および/または非同期メッセージによってデータオブジェクトを作成、使用、および破棄します。
理論的には、UMLで新しい図の種類を定義でき、オプションで1つ以上の従来の図の種類を拡張できます。 UMLで定義された正規図の種類は、本質的にUMLメタモデル自体の一部として定義されます。
正式には、UMLメタモデルの定義は、オブジェクト管理グループ（OMG）によって公開された ML仕様 と、MOFで定義された対応するメタメタモデルで提供されます。 対応する仕様 -さらに、正式な OCL仕様 を伴う-UMLのOCL言語のアプリケーションでのUMLモデルの制約の定義に関して-そして、- XMI仕様 、UMLモデルを機械可読形式で格納する方法の仕様に関して。
表面上、これらのすべての仕様は、UMLモデリングの単一フレームワークの「内部」であるかのように、UML metmodelのEcoreサブセットのアプリケーションでも、標準のUMLでも、アプリケーションに組み合わせることができます。
復習 データフローダイアグラムに関する短い学術的プレゼンテーション -UMLダイアグラムの種類の正式な定義から多少は離れていますが、それでもMOFメタメタモデルのアプリケーションのより広いコンテキストでは-おそらく正規 [〜＃〜] bpmn [〜＃〜] メタモデル-従来のグラフィカルな抽象構文で-おそらくBPMNはデータフロー図との類似点を提供するのに役立つでしょうか？
もちろん、モデリング手法はベンダーやアプリケーション環境によって異なる場合があります。
Enterprise Architect 'Dynamic View' Analysis図を使用しています。
コントロール=プロセス
情報=データストア
多くの点で、分析ダイアグラムはデータフローダイアグラムよりもはるかに優れています。送信および受信の形式でイベントを表示することもでき、プロセスシンボルもありますが、私はコントロールを好みます。オブジェクトと決定が含まれます。