ユースケース図に関する質問があります。図に示すように、ユーザは自分の名前と彼の問題を入力または更新することができる。ユースケース図が含まれています
最初に自分の情報を入力するときに名前と問題の両方を入力する必要があります（したがって、インクルード）。しかし、彼が彼の情報を更新したいのであれば、ダイアグラムは名前と問題の両方を修正しなければならないことを示していないでしょうか？
名前のスペルが間違っていても問題が正しく入力されていれば、これは問題になります。それは彼が名前と問題の両方を更新しなければならないことを意味するからです。
「入力」が含まれ、「更新」が拡張の2つの使用例がありますか？
ありがとうございました！
実際に一度しか使用しない場合、インクルード/エクステンデッドユースケースを抽出するのは意味がありません。単一のユースケースとしてEnter/update infoに留まり、上記のUCの流れを説明してください。
ほとんどすべてのケース（私が見てきたように）で人々は機能分解のためにそれを使用するので、一般的にinclude/extendから離れてください。そして、それはUCがすべてについてのことではありません。検討中のシステムがそのアクターに提供する単一の付加価値を識別するためにそこにあります。
時間を割いていただきありがとうございます。上記の場合、「名前を付ける」と「問題」を単一の追加値にしませんか？確かに、これらの値を入力する俳優は、両方を別々に入力する能力があるので、俳優が使用するユニークな値と見なすべきではありませんか？単に「入力/更新情報」を持っているだけでは十分ではないように感じられます。 – Johny
状況によって異なります。しかし、「あなたの名前を入力してください」と「姓を入力する」を2つの異なるユースケースにすると思いますか？ –
私はおそらく、図の上ではなく、UC記述にそのような抽象度の低い特定の要素を配置します。それは正しい呼び出しですか？ – Johny
ユースケース「ユーザーが情報を入力/更新する」には、2つのケースを除いて何か他のものがありますか？なぜ「ユーザー更新情報」を取り除くことができないのですか？ – Vlad
はい、これには10個のその他のものが含まれています。私はあなたの2番目の質問を理解しているか分からない。あなたからあまりにも多くの意見を聞いてください。 – Johny
Johny、オプションのインクルードも使用できます。これは、すべてのシナリオに含まれるようなケースを含めるためではありません。特定の用途を含まないシナリオがあるかもしれません。 （そして** no **、それはあなたが延長を使用すべきであることを意味しません） –