UMLの代わりに機能プログラマは何を使用していますか？

私はCSの学生です。現在、客観的な分析と設計を教えている講義に参加しています。ほとんどの場合、ユースケースの記述、クライアント用のアプリケーションを作成するときに直面する問題の分析、拡張可能で開発者にとって明確であり、クライアントがいくつかについて議論するときに問題が発生しないようにプロジェクトを設計する方法特徴。「客観的」なので、OOPの観点（クラスなど）から学習しています。

現在、ヘルパーツールとしてUMLを使用しています。私はOOPを十分に理解していると思いますが、機能的なパラダイムも学び、いくつかの小規模なプロジェクトでうまく使用しました。

私たちの先生は、「機能的なパラダイムについてはどうですか？」質問では、彼は関数型言語でより大きなプロジェクトをプログラミングしておらず、関数型プログラムがどのツールを使用しているのかを知りません。

それで、彼らは何を使うのでしょうか？このための方法論はありますか？それとも、そのようなことの必要はありませんか？

私はすべての機能的なプログラマーのために話すことはできませんが、私が知っているすべての人はトップレベル関数の型シグネチャーを書くことから始めます、そして、彼らはより詳細を必要とするので、彼らはヘルパー関数の型シグネチャーなどを書きます。

これは、関数型プログラミングには副作用がないため機能します。そのため、関数はすべて入力と出力のみで指定されます。これにより、型シグネチャは、命令型プログラミングよりも設計ツールとしてはるかに役立ちます。これが、コンパイラーがそれらを推測できる場合でも使用されるのを見る理由の1つです。

作図ツールに関する限り、あなたの教授に敬意を払いながら、私は学校を出て以来、どのようなパラダイムでもそれらをあまり使用していません。

UML標準では、次の便利なチャートに示すように、12種類を超えるダイアグラムタイプを定義しています。

ソース：https : //en.wikipedia.org/wiki/File : UML_diagrams_overview.svg

図A.5 UML 2.5仕様の構造図と動作図の分類も参照してください。

^{これは、ダイアグラムタイプとイタリック体の抽象ダイアグラムタイプ間のサブタイプ関係であるクラスダイアグラムの例であることに注意してください。これらのダイアグラムタイプは実際にはUMLメタモデル内のクラスですが、このクラスダイアグラムは、OOPに接続せずに階層を示すのに役立ちます。}

クラス図やオブジェクト図など、明らかにOOPにのみ適用されるタイプがいくつかあります。しかし、残りは、オブジェクト指向システムだけでなく、より広く適用できます。

• 状態マシン図 – FPは状態を回避せず、単に明示的にします。状態マシン図は、制御フロー、またはプログラムのさまざまな状態遷移を説明するのに役立ちます。

• アクティビティ図 -ステートマシン図の場合と同様の場合に役立ちますが、より高レベルです。これらを使用して、さまざまなサブシステム間のデータの流れを説明したり、外部ビジネスプロセスをモデル化したりできます。

• 相互作用図 –複数のステートフルプロセス間の相互作用をモデル化します。明らかに、これは純粋な関数型プログラムの内部をモデル化するのに役立ちません。ただし、UMLはコードの構造のモデリングだけでなく、主にユニバーサルモデリング言語の提供に関するものです。相互作用図を使用すると、たとえば、相互作用図を使用して、システム間、たとえばブラウザーとWebサーバー間の外部動作をモデリングできます（FPテクニックを使用して記述されている場合でも）。

• ユースケース図 –ユースケースと要件は、それらを満たすために使用されるテクノロジーとは無関係です。ここでは、OOPまたはFPはまったく無関係です。

• 配置図 –この図の種類は、実行可能なソフトウェアとハ​​ードウェアリソースの関係を説明するために使用されます。そのソフトウェアがFP言語で書かれているかどうかは関係ありません。

• コンポーネント図 –ほとんどの関数型言語は、最近ではモジュール式プログラミングを明示的にサポートしています。コンポーネント図は、コンポーネント/モジュール、およびそれらの提供および必須インターフェースを説明します。これは、OCamlのFunctorモジュールの多くを思い出させます。

• プロファイル図 -UML自体の拡張機能を説明するため、実際に使用されることはありません。

• 複合構造図 –複合材料の構造を説明します。データ構造、または関数の相互作用点を記述するために使用できます。ウィキペディアは、例としてフィボナッチ関数の図を示しています。

  

  ソース：https : //commons.wikimedia.org/wiki/File : Composite_Structure_Diagram.png

  ある意味では、これはクラス図ではなく機能的なプログラマーの選択になりますが、これは恐ろしく過剰に設計されているようです…。

• パッケージ図 –パッケージは、名前空間に相当するUMLです。このダイアグラムタイプは、別個のダイアグラムタイプよりもUML言語インフラストラクチャの一部です。たとえば、パッケージを使用して、大規模なユースケース図を分類できます。

したがって、これまで見てきたように、関数型プログラミングを行う際にはさまざまなUMLダイアグラムタイプが依然として有用です。

システムの設計時にUMLを使用し、主にUMLを使用して割り当てられた宿題を実行したり、アーキテクチャの概要を簡単なスケッチで伝えることを希望することはほとんどありませんでした。OOPシステムであっても、UMLは常にそれを使用するのに十分な値を提供しません。実際のコードは、1000以上の図を示しています。UMLのような図を使用して、FPプログラムのさまざまな機能とデータ構造間の依存関係を説明することを想像できますが、まだそうしていません。ただし、アーキテクチャ全体には影響しません。