UML：非同期の要求/応答メッセージ交換を2つのポート/インターフェースまたは1つのポート/インターフェースとしてモデル化する必要がありますか
UMLで非同期の要求と応答のメッセージ交換をモデル化したいと思います。
リクエストはクライアントからサーバーに送信されます。サーバーは非同期に応答します。
これは、次の2つの方法でコンポーネントモデルでモデル化できます。
オプション1
要求と応答は、それぞれ1つのメソッドを持つ2つの異なるインターフェースです。サーバーは要求インターフェースを提供し、クライアントは応答インターフェースを提供します。インターフェースは逆も同様です。 UMLでは、サーバーとクライアントをそれぞれ1つのポートを持つコンポーネントとしてモデル化します。どちらのポートも2つのインターフェースを公開します。クライアントからサーバー（リクエスト）とサーバーからクライアント（レスポンス）にリンクされている提供インターフェースと必須インターフェースです。
オプション2
要求と応答は、1つのメソッドを持つ1つのインターフェースです。応答は、単にこのメソッドの戻り値です。サーバーが提供し、クライアントがこのインターフェースを必要とします。メッセージ交換は、クライアントからサーバーへのリンクとしてモデル化されます。
オプション（1）は非同期交換に適していると思いますが、オプション（2）は同期交換に適しています。ただし、このような区別を行うと、実際に動作図に属するコンポーネントモデルの詳細が表示されます。
- コンポーネントモデルで非同期メッセージ交換をモデル化するための標準または「ベストプラクティス」はありますか？
- オプション（2）が「正しい」方法の場合：クライアントが応答を受信するためにインターフェイスコントラクトに準拠する必要があることをどのように指定する必要がありますか？
同期メッセージの場合はオプション2が、非同期メッセージの場合はオプション1の方が良いという評価は正しいと思います。
その性質上、非同期メッセージングスキーム（要請されている場合でも）のモデル化はより複雑です。オプション1は、説明するメッセージングをモデル化するためのより良いオプションです。
オプション1を使用すると、かなりのレベルの詳細が含まれているため、問題の図では多すぎる可能性があるという懸念に感謝します。
customの関係または関連付けをモデル化できます（適切な名前、例：<<CustomRqRs>>）を使用して、コンポーネントをリンクします。これにより、ダイアグラムが簡素化され、相互作用がより適切に説明され、メッセージと応答自体のモデリングが向上します。
モデリングするときは、主に意図を伝えるためにそこにあることを常に心に留めておくことは常に重要です。設計、使用法、可能な実装、関数など単純な方がほとんど常に優れています。正確にモデル化し、適切にモデル化しますが、シンプルにしてください。