このユースケース図で<< include >>と<< extend >>の関係を実際に使用していますか？
ソフトウェアプロジェクトの要件をモデル化するために、UMLユースケース図を描画しようとしています。
モデル化する際に問題となる2つの要件は次のとおりです。
TravelAgentは、家をリクエストしている[古い]クライアントの予約を作成します。新しいクライアントが予約を希望する場合、予約を行う前に、
TravelAgentをシステムに登録します。
これらの要件をモデル化する方法は2つあります。
- 最初のユースケースを2番目のユースケースのサブプロシージャとしてモデル化する（図1）。
- 最初のユースケースの拡張（図2）。
どちらのアプローチも、最初のユースケースを個別に実行できることを意味しますが、2番目のユースケースが実行されると、最初のユースケースも実行する必要があります。
それらは実際に同じであり、両方が正しいですか？
追伸別の質問として、NewClientは登録後にClientに変換されるため、NewClientをClientのサブクラスとして表示する必要がありますか？
図1 
図2 
拡張はUMLでの使用とはかなり異なることに注意してください。 Java。
あなたの図はおそらくあなたが彼らに望んでいることを表現していません。汎化関係（白抜きの三角形の付いた矢印）を使用しました。これは「ある」関係を意味します。しかし、明らかに「クライアントを登録する」ことは「予約を作成する」ことのケースでも、その逆でもありません。
「含む」または「拡張」の関係を示す正しい方法は、破線を使用することです。 --->。この2つの違いは次のとおりです。 AにBが含まれているとします。これは、誰かがAを実行するときはいつでも、彼女もBを実行することを意味します。一方、AがBを拡張する場合、誰かがAを実行する場合は常に、Bはそれとは関係ありません。しかし、Bを実行する場合、Bの過程でAを追加で実行する可能性があります。Aが実際にBを拡張する条件を指定する必要があります。
あなたのケースでは、拡張バージョンの状態でこれが顧客の新しさに依存することを示す限り、実際に両方を使用することができます。
新しいクライアントのモデリングについて。ここで両者の違いを表現することに大きな価値があるとは思いません。ところで、「サブクラス化」は正しい用語ではなく、（再び）一般化です。そのような一般化を追加することは、すべての新しい顧客が顧客であり、常連の顧客ができることは何でもできることを意味します。これがあなたの望むものかどうか、私には決定できません。
UMLダイアグラムのINCLUDEとEXTENDSについて私が学んだことは、インクルードは必須であり、拡張はオプションであることです。あなたのケースでは、クライアントはすでにシステムに登録され、ログインしていると想定されています。したがって、彼は再度登録を行う必要はありません。ただし、予約を作成するには、newClientを登録する必要があります。次のようになると思います。
しかし、私も一度学んでいると、よくわかりません...それが役に立てば幸いです。