1つの例外ハンドラクラスがあります。このクラスをUMLに表示したい-クラス図。しかし、クラス間の関係を表す方法がわかりません<X>
および例外ハンドラクラス。クラス図でクラス間の関係をどのように表すことができますか?
私が見たことから、stereotypeは通常、例外との関係を表すために使用されます。
"exception"のように、キーワードを例外として、UMLのステレオタイプ表記をギレメットで囲まれたステレオタイプとして使用することをお勧めします。
スタックオーバーフローに関するこの回答 もステレオタイプを示唆していますが、代わりに<<throws>>
を使用しています。著者は、従来存在しないステレオタイプを使用しても問題ないと確信しており、この特定のケースでは、彼に同意します。
適切な用語については、ステレオタイプは名詞または動詞である可能性があるため、<<exception>>
と<<throws>>
はどちらも同じように正しいように見えます。適切な用語は、使用する言語によっても異なります。たとえばPythonでは、throwではなく、raiseエラーまたは例外を発生させるため、<<raises>>
は最も適切なものとして;エラーと例外を分離する意図がない限り、<<exception>>
と<<error>>
の方が表現力があります。
最後に、 アジャイルモデリングが推奨 (図4を検索)して、次のように例外の名前を埋め込みます。
+ findAllInstances(): Vector {exceptions=NetworkFailure, DatabaseError}
ただし、IMOはフレームワークで使用される既知の例外には適していますが、作成したカスタム例外にはあまり関係がありません。関係が十分に視覚的ではないためです。
例外ハンドラーの1つは、例外ハンドラーが問題領域の一部ではなく、機能以外の要件の一部であるということです。つまり、システムのアーキテクチャです。その意味では、ドメインモデルのクラス図には、Loggerクラスが属している以上、実際には属していません。 (またはBeanFactory、またはガベージコレクターなど)
クラス図は、モデル内のクラスとそれらの間の関係に関する情報を表示します。ただし、例外ハンドラーは、クラスの多くまたはすべてと関係があります-制御フローが突然停止し、代わりに例外ハンドラーに移動する可能性があります。さらに悪いことに、例外ハンドラとドメインクラスの間の関係は、アプリケーションのframeworkによって管理されるため、(設計上)ドメインクラスとの直接的な関係はありません。
クラス図がフレームワーククラス用である場合、それは簡単です。ほとんどの場合、例外ハンドラとの「関係」を持つコントローラが存在します。しかし、クラスダイアグラムがドメインモデル用である場合、クラスダイアグラムには入れない背景からのビットがたくさんあります。