暗黒時代 (1980 年代半ば) に戻って、私は構造化分析のデータ フロー ダイアグラムをかなりの量使用しましたが、それらが非常に役立つことがわかりました。
私の現在の雇用主はUMLが大好きです。私は通常、UML 以外の描画を行わない BOUML を使用します。
データ フロー ダイアグラムに対応する UML 図面は何ですか?
存在しない場合、対応するデータを表示するために推奨される UML 図は何ですか?
暗黒時代 (1980 年代半ば) に戻って、私は構造化分析のデータ フロー ダイアグラムをかなりの量使用しましたが、それらが非常に役立つことがわかりました。
私の現在の雇用主はUMLが大好きです。私は通常、UML 以外の描画を行わない BOUML を使用します。
データ フロー ダイアグラムに対応する UML 図面は何ですか?
存在しない場合、対応するデータを表示するために推奨される UML 図は何ですか?
OOD には同等のモデルはありません。DFD の強調点は、関数から分離されたデータです。これは、手続き的な方法で処理する場合に最も役立ちます。DFD のスケールは OOD よりもはるかに優れています。OOD を使用して (世界観に) スケールアウトしようとすると、本質を捉えるのに役立つユース ケース図を使用することになります。私は DFD が非常に高レベルでありながら、DFD ボックスを開いてレベル 1 などと呼ぶことで拡張できる点が気に入りました。
私は現在、Go プログラミング言語を学んでいます。これはオブジェクトをまったく使用していません。いくつかの点で、DFD モデリングの方がはるかに適していると感じています。
私もこの種の作業を行うことができる図を探しています。Go では、基本的なデータ型である構造体が集中的に使用されます。オブジェクト指向に似たプリミティブな拡張メソッドをアタッチすることができますが、実際にアセンブリ コードを見ると、関数の構文シュガーのように見えます。最初のパラメーターは、関数が操作する構造体です。
私のアドバイスは、OO コードを実行している場合は、OOD を使用することです。それらはより適切にマッピングされ、システムについて考えるのに役立ちます。特に 80 年代または 90 年代のプログラミングから来ている場合は、手続き型コードに慣れるまでに時間がかかります。オブジェクトについて考えるゾーンに入ると、OOD メソッドは正常に機能します。どの部品を使用するかについての直接的な答えはないため、厳密には方法論ではありません。私が最も難しいと思うオブジェクトで考えるだけです。これに関する良い本は "Object Thinking -- David West" です...最初にオブジェクトについて考えるのに役立ちます。停止するのが非常に困難になると、名詞の王国に閉じ込められてしまう人もいるかもしれません。これは恐ろしい場所です。システムを完全に記述するためだけに、ボイラープレートコードを無限に書くためです。
手続き型コード、または OO と手続き型の混合を許可する言語でコーディングしている場合は、コーディングを開始する前にパラダイムを決定する必要があります。パラダイムの混乱にコードを混ぜてコーディングします。これにより、どの作図ツールを使用するか、およびシステムをどのように分析するかが決まります。
最近、関数型プログラミング手法を提供するために、Java と c# が移行されています。私が発見したこれらは、プログラミングのどちらのカテゴリ (オブジェクト指向または手続き型) にも当てはまりません。関数型プログラミング コードをオブジェクトにマップしようとするのは悪夢です。
申し訳ありませんが、回答を提供していませんが、作成しているコードによって異なります。
UMLはオブジェクト指向デザインを強調しているのに対し、DFDは構造化システム分析および設計(SSAD)に由来するため、直接的な類似点はありません。UMLでは、多くの図、特に相互作用図グループの図には、データフローと処理の要素をモデル化する可能性のある特性があります。コミュニケーション図は、DFDのほとんどの側面を一般的に反映するために使用できますが、シーケンス図は、特定のフローのシーケンスをモデル化する場合があります。DFDセマンティクスを提案したい場合は、データプロセスとデータストアにステレオタイプ化されたオブジェクトを使用し、外部エンティティにアクターを使用できます。
Sparx Systems Enterprise Architectは、主にUMLツールに拡張機能としてDFDが含まれているのに対し、注目に値するかもしれません。
理論的には、新しいダイアグラムの種類を UML で定義し、必要に応じて 1 つ以上の従来のダイアグラムの種類を拡張することができます。UML で定義されている正規図の種類は、基本的に UML メタモデル自体の一部として定義されています。
正式には、UML メタモデルの定義は、オブジェクト管理グループ (OMG) によって公開されたUML 仕様、および MOF で定義された対応するメタメタモデル (対応する仕様もあります) で提供されます。正式なOCL 仕様、UML での OCL 言語のアプリケーションにおける UML モデルの制約の定義に関するもの、およびXMI 仕様、UML モデルを機械可読形式で格納する方法に関する仕様に関するもの。
表向きには、これらの仕様はすべて、UML モデリングの単一のフレームワークの「内部」のように、UML metmodel の Ecore サブセットのアプリケーションであろうと、正規の UML であろうと、アプリケーションのために組み合わせることができます。
データ フロー ダイアグラムに関する短い学術プレゼンテーションのレビュー- UML ダイアグラムの種類の正式な定義から多少逸脱していますが、MOF メタメタモデル (おそらく正規のBPMNメタモデル) のアプリケーションのより広いコンテキストで、従来のグラフィカルな抽象構文で- BPMN は、データ フロー ダイアグラムに類似したものを提供するのに役立つのではないでしょうか?
もちろん、モデリングの手法は、ベンダーやアプリケーション環境によって異なる場合があります。