関数型プログラミングのUML図はありますか？
命令 または 手続き型 プログラミングパラダイムで実装されたモデリングソフトウェアの場合、フローチャート、プロセス図などがあります。
オブジェクト指向 の場合、UMLクラス図、オブジェクト図、状態図などがあります。
関数型プログラミング で実装されたUMLダイアグラムに適した設計ソフトウェアはありますか？
要するに
はいといいえ ！
はい、モデル化できます！
MLアクティビティ図 は、制御フローとオブジェクトフローをモデル化します。どちらも、個々の関数、関数構成、関数パイプラインをモデル化するのに非常に実用的です。
- 関数は actions で表されます。
- Composition は activitiy edge で表示でき、必要に応じて pins を使用してオブジェクトが一方から他方へ流れることを示します（間の混乱を恐れる場合）構成とシーケンス）。
- 関数定義の パターンマッチング は、出力ブランチのガードとしてパターンを使用する 決定ノード で表すことができます。
- 複数の入力パラメーターは join node で表すことができます。これは、異なるパラメーターの評価が必ずしもシーケンスされないことを強調するという利点があります。
いいえ、標準のUMLには高次関数はありません
標準のUMLでは、私の知る限り 高次関数 を表す簡単な方法はありません。
- 高次関数は関数型プログラミングのコア機能です。
- ただし、UMLでは、アクションは生成できず、別のフローによって実行されるアクションは生成できません。また、アクションを別のアクションへの入力として受け入れることもできません。
- この内部の制限は、そのルーツであるペトリネットに起因し、制御フローはノードの固定ネットワーク間を移動するトークンによって表されていました。
おそらく、そこにあるUMLの第一人者は invocation action を使用して、関数型のオブジェクトに対応するファンクターを呼び出す回避策を見つけることができます。でも、それができても理解しにくいと思います。
注：同じ制限が非UMLモデルでも発生することに注意してください。データフロー（DFD）と機能分解モデル（SADT）は常にアクティビティを修正済みと見なします。結局のところ、2つの関数を接続する矢印と、新しい関数を提供する矢印の違いをどのようにしたらわかりますか？
結論
実現可能性を理解するために、いくつかのアクティビティ図の例を見てください。これらは手順的なアプローチを念頭に置いて設計されていますが、機能的な方法でそれらを実装する方法を想像してみてください。驚かれることでしょう。 。
不足している高次のアクティビティについては、何をアドバイスすればよいかわかりません。おそらく、カスタマイズされたUMLプロファイルを作成して、アクションの結果として生成されたアクションを視覚的に表現できるようにしますか？