UMLの代わりに関数型プログラマーは何を使用していますか？
私はCSの学生です。私は現在、客観的分析とデザインを教えている講義に出席しています。これは主に、ユースケースの作成、クライアント用のアプリケーションを作成するときに直面する可能性のある問題の分析、およびプロジェクトを拡張可能で開発者にとって明確であり、クライアントがいくつかについて議論したときに問題が発生しないようにプロジェクトを設計する方法で構成されています特徴。 「客観的」なので、OOP視点（クラスなど））から学習しています。
現在、UMLをヘルパーツールとして使用しています。私はOOPをよく理解していると思いますが、機能的なパラダイムを学び、いくつかの小規模なプロジェクトでうまく使用しました。
私たちの教師は、「機能的パラダイムについてはどうですか」と直面したとき、質問、彼は関数型言語でより大きなプロジェクトをプログラミングしていないと答え、彼は関数型プログラムが使用しているかもしれないツールを知りません。
それで、彼らは何を使うでしょうか？このための方法論はありますか？それとも、そのようなことは必要ないのでしょうか？
すべての関数型プログラマについて話すことはできませんが、私が知っているすべての人は、トップレベル関数の型シグネチャを記述することから始めます。その後、詳細が必要な場合は、ヘルパー関数の型シグネチャなどを記述します。
これは、関数型プログラミングには副作用がないため機能します。そのため、関数はすべて、入力と出力のみで指定されます。これにより、型シグネチャは、命令型プログラミングよりも設計ツールとしてはるかに有用になります。コンパイラがそれらを推論することができるときでさえ、それがあなたがそれらを使うのを見る一つの理由です。
作図ツールに関しては、教授に敬意を表し、退学してからanyパラダイムでこれらを使用することはありませんでした。
UML標準は、この便利なチャートに示されているように、12を超えるさまざまな図のタイプを定義しています。
出典： https://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg
も参照してください。図A.5 UML 2.5仕様の構造図と動作図の分類法。
これはクラスダイアグラムの例であり、ダイアグラムタイプ間のサブタイプ関係とイタリック体の抽象ダイアグラムタイプがあることに注意してください。これらの図のタイプは実際にはUMLメタモデル内のクラスですが、このクラス図は、OOPに接続せずに階層を示すのに役立ちます。
OOPにのみ適用されるタイプがいくつかあります。たとえば、class diagramまたはobject diagram。しかし、残りは、単にオブジェクト指向システムよりも広く適用できます。
ステートマシン図– FPは状態を回避せず、状態を明示的にするだけです。状態マシン図は便利です。制御フロー、またはプログラムのさまざまな状態遷移について説明します。
アクティビティ図–ステートマシン図と同様のケースで役立ちますが、より高いレベルにあります。これらを使用して、さまざまなサブシステム間のデータの流れを説明したり、外部ビジネスプロセスをモデル化したりできます。
相互作用図–複数のステートフルプロセス間の相互作用をモデル化します。明らかに、これは純粋な関数型プログラムの内部をモデル化するのには役立ちません。ただし、UMLはコードの構造をモデル化することだけでなく、主にユニバーサルモデリング言語を提供することを目的としています。相互作用図を使用すると、たとえば相互作用図を使用して、システム間の外部動作をモデル化します。ブラウザとWebサーバーの間–これらがFPテクニックを使用して記述されている場合でも.
ユースケース図–ユースケースと要件は、それらを満足するために使用されるテクノロジーとは無関係です。 OOPまたはFPはここでは絶対に無関係です。
展開図–この図のタイプは、実行可能なソフトウェアとハードウェアリソース間の関係を説明するために使用されます。そのソフトウェアがFP言語で書かれているかどうかは関係ありません。
コンポーネント図–最近のほとんどの関数型言語は、モジュール式プログラミングを明示的にサポートしています。コンポーネント図は、コンポーネント/モジュール、およびそれらが提供するインターフェースと必要なインターフェースを示しています。これは私に多くのOCamlのFunctorモジュールを思い出させます。
プロファイル図– UML自体の拡張機能を記述し、実際には決して使用されません。
複合構造図–複合構造を説明します。データ構造、または関数の相互作用点を記述するために使用できます。ウィキペディアは、例としてフィボナッチ関数の図を示しています。
![Composite Structure Diagram for a Fibonacci funciton]()
ソース： https://commons.wikimedia.org/wiki/File:Composite_Structure_Diagram.png
ある意味では、これはクラスダイアグラムではなく関数型プログラマの選択ですが、これはひどく過剰設計されているようです…。
パッケージ図–パッケージは、UMLの名前空間に相当します。この図の種類は、別個の図の種類よりもUML言語インフラストラクチャの一部です。たとえば、パッケージを使用して、大規模なユースケース図を分類できます。
したがって、これまで見てきたように、関数型プログラミングを行う場合、さまざまなUMLダイアグラムのタイプが依然として役立ちます。
システムを設計するときにUMLを使用したいという気持ちはほとんどありません。主にUMLを使用して割り当てられた宿題をしたり、アーキテクチャの概要を簡単なスケッチで伝えたりします。 OOPシステムの場合でも、UMLは常にそれを使用するのに十分な値を提供しません。実際のコードは1000を超える図を示します。UMLのような図を使用して、 FPプログラム内のさまざまな関数とデータ構造、ただしまだそうしていない–私の個人的なスタイルはOOPとFPここでFPテクニックはローカル規模で使用されますが、アーキテクチャ全体には影響しません。