私はUMLの世界に不慣れで、これまでにユースケース、アクティビティ、およびデプロイメントUML図の基本を学びました。ユーザーがシステムと対話する場所の要件があります。たとえば、ユーザーが電子メールを送信し、それがシステムによって処理されてからエージェント（人）に送信され、エージェント（人）が応答してシステムと再度対話します。
これらの要件と、それがユースケース、アクティビティ、または展開の組み合わせである必要があるかどうかを把握するのに苦労しています。それらを混ぜることはできますか？標準的な慣行とは何ですか？
ご存知のように、ユースケースは要件を把握するために使用されます。ユースケースを特定して詳細に説明するときは、ユーザーの観点から問題を検討します。アクターがシステムに期待することにのみ焦点を当てます。最初のステップは、ユースケースとアクターを特定し、次にユースケースフローを詳しく説明することです。
1-ユースケースとアクターを特定する
あなたの例では、電子メールの送信は、エンドユーザー（アクター）によって開始されたユースケースである可能性があります。次に何が起こるか（たとえば、システムがエージェントに通知を送信する）は、このユースケースのフローの一部としてモデル化できます。
別のユースケースは、システムから通知を受信した後に実行する必要があることを処理するエージェントアクターである可能性があります（このユースケースの前提条件は、通知が受信されていることである可能性があります）。
これらの2つのユースケースを組み合わせて、エージェントをセカンダリアクターとして使用できることに注意してください（セカンダリアクターはユースケースと対話しますが、それを開始しません）。これを行うかどうかは、モデラーの選択であり、ユースケースのサイズ、ユースケースの数、およびその他の多くのものによって異なります。
2-ユースケースの詳細
ユースケースとアクターを特定したら、ユースケースを詳しく説明する必要があります。最も重要な部分は、ユースケースフロー（アクターとシステムの段階的な相互作用）を詳しく説明することです。これは、テキストとして記述したり、アクティビティ図として描画したりできます。
したがって、あなたの質問に答えるために：はい、アクティビティ図とユースケースを組み合わせることが可能であり、非常に一般的です。これは、ユースケースのステップのフローを示すために描かれたアクティビティ図です。
一方、配置図は、要件の抽出フェーズとはまったく関係ありません。これらは、システムの物理構造と、ハードウェアコンポーネントとソフトウェアコンポーネントがどのように相互作用するかをモデル化します。
実際、クラス図、シーケンス図、状態図、その他の多くの図の前にコンポーネント図を学んだことは非常に奇妙です。