UMLを使用して関数型プログラムをモデル化できますか？
より具体的には、関数型プログラム、またはテキスト形式ではなくダイアグラムを使用して、関数型スタイル（クラスなし）を使用して開発された関数型プログラムをどのようにモデル化しますか？ （オープンソース、ビールのように無料でください）
関数型プログラマーは通常、ダイアグラムをあまり使用しません。多くの関数型プログラマー（すべてではない）は、typesを書き留めることが、OO =プログラマーがUML図に入れます。
関数型プログラムでは変更可能な状態はめったにないため、変更可能な「オブジェクト」は存在しないため、通常、それらの間の関係を図で示すことは役に立ちません。また、1つの関数が別の関数を呼び出すこともありますが、このプロパティは通常、システム全体の設計にとって重要ではなく、呼び出しを行う関数の実装にとってのみ重要です。
関数型プログラムをダイアグラム化する必要性が強いと感じた場合は、型または関数が機能する コンセプトマップ を使用できます。概念の役割。
UMLはクラス図だけではありませんね。
他のほとんどの種類の図（ユースケース図、アクティビティ図、シーケンス図など）は、純粋に機能的なプログラミングスタイルに完全に適用できます。属性と関連付けを単に使用せず、「クラス」を「関連する関数のコレクション」として解釈する場合は、クラス図でさえも役立つ可能性があります。
UMLは、さまざまなタイプのモデリングの概要です。オブジェクトダイアグラム（クラスダイアグラム）について話している場合、目的の用途に合ったものを見つけることはできません。ただし、相互作用図（アクティビティ図）または要件図（ユースケース図）について話している場合は、もちろんそれらが役に立ち、UMLベースの一部です。
関数型プログラマーには独自のバージョンのUMLがあり、それは Category Theory と呼ばれます。
（これには確かな真実がありますが、それはhumourのタッチで読むことを意図しています）。
グラフィカルレベルでは機能モデリングを定義できないため、UMLはオブジェクトアプローチです。トリックは、ダイアグラムレベルではなく、モデルで制約と注記を直接追加することです。つまり、メタモデルで各モデル要素の完全な機能ドキュメントを直接記述し、UMLエディターを使用してオブジェクトビューのみを表示できます。これは馬鹿げているかもしれませんが、私はこのデモをフランス語でまったく同じ主題で使用し、EclipseUML Omondo：OCLとUML 2.2（フランス語のデモ3分）を使用しているのを見つけました： http://www.download-omondo.com/ regle_ocl.swf
このデモでは、メタモデルレベルでメソッドに直接制約を追加する方法について説明します。このデモの興味深い点は、プロジェクト全体で単一のモデルを使用すると、すべての情報がUML 2.2メタモデルの上に構築されるため、従来のUMLを拡張し、SysML、BPMN、DSL追加モデルを回避するのに十分な柔軟性が得られることです。成功するかどうかはわかりませんが、モデリングの複雑さを軽減し、新しいフロンティアを開くため、このイニシアチブは非常に興味深いものです。
noclassというクラスを作成し、関数をメソッドとして配置できると思います。また、noclassを関数の複数のカテゴリに分割することもできます。
これは古いスレッドだと思いますが、ここでは問題を理解していません。
クラスは、そのメソッドの機能をより人間にやさしい方法で結び付ける概念の抽象化にすぎません。たとえば、WaveGeneratorクラスには、Sine、Sawtooth、SquareWaveなどのメソッドが含まれる場合があります。 3つのメソッドはすべて、ジェネレータクラスに明確に関連しています。ただし、3つともステートレスです。正しく設計されていれば、メソッドの外側に状態情報を格納する必要はありません。これにより、それらはステートレスオブジェクトになり、-私が正しく理解していれば-機能パラダイムのコアコンセプトである不変の関数になります。
概念的な観点から、私は違いがないと思います
envelope Sine = ...
そして
envelope Generator.Sine = ...
後者が関数の目的についてより深い洞察を提供するかもしれないという事実以外は。
実際にUMLで大規模なシステムをモデル化してから機能的な実装を試みたわけではありませんが、なぜ機能しないのかわかりません。
実装がHaskellになると仮定して、クラス図を使用して型とその関係を定義することから始めます。主な引数によって関数をクラスに割り当てますが、これはUMLのアーティファクトにすぎないことを覚えておいてください。すべての関数を保持するためだけに架空のシングルトンオブジェクトを作成する方が簡単だったとしても、それで問題ありません。アプリケーションが状態を必要とする場合、状態チャートまたはシーケンス図でそれをモデル化しても問題はありません。アプリケーション固有のシーケンスのセマンティクスにカスタムモナドが必要な場合、それはステレオタイプになる可能性があります。目標は、アプリケーションが何をしているかをドメイン用語で説明することです。
主なポイントは、UML couldを使用して、機能を実装するプログラムをモデル化することです。実装へのマッピングを覚えておく必要があり（それを文書化しても害はありません）、適合は正確にはほど遠いものです。しかし、それは可能であり、さらには付加価値をもたらす可能性もあります。