ユース ケース図で、アクターが実行できないことを示すことができますか?
それとも、特定のユースケースに結び付ける線がないという事実のために、単に暗示されているのでしょうか?
あなたが図解しているユースケースが、アクターが許可されていないことを試みた後に拒否された場合である場合、はい、それを示します。
それ以外の場合は、実際にユース ケースの一部となるものだけを含めることに固執します。
いいえ。アクターは、自分ができることすべてに接続されます。アクターがそれを実行できない場合、それは表示されません。
これが代替パスの目的です。基本パス (別名ハッピー パス) は、正しいアクターがユース ケースを開始したときに何が起こるかを示します。代替パスでは、間違ったアクタがそれを開始しようとした場合に何が起こるかを示すことができます。
IMHO this questionとほとんどの回答は、ユースケースの使用方法について間違った印象を与えています。
ユースケースは、自然言語を使用する要件手法として意図されていました。その方法が最も効果的です。
あまりにも多くの UML/モデリングと組み合わせると、完全に破壊的な手法になる可能性があります。UML アクティビティ図を使用してメイン フローと代替フローをモデル化するなど、ユース ケース テキストの構造化モデリングは、大量破壊のユース ケースを作成するための実証済みの方法です。
ユースケース図は役に立つ場合がありますが、ユースケースの目的は、システムがサポートする必要があるユーザーの目標を特定するための何よりも重要な手法であることを覚えておく必要があります。その後、メイン フロー、代替フローなどを使用して、ユース ケース テキストで自然言語を使用して詳細をキャプチャできます。
作図ツールを使用すると、いくつかの簡単な情報を視覚化できます。 - ユーザーの目標ごとに、モデル要素タイプのユース ケースを作成できます。- ユース ケース要素を含むシステムのボックスを使用して、システム境界を示します。- アクターとユース ケースの関係を作成して、アクターがシステムに対して特定の目標を持っていることを示します。
ただし、目標にマッピングされたアクターの最新のリストを維持することは、二次的な重要性です。利害関係者の分析を行い、アクターのリストを作成することは、ユーザーの目標を特定する手段です。ユーザーの目標が特定された後は、厳密に言えば、アクターのリストを維持する必要はなくなります。
ユース ケース モデルにユーザーのアクセス許可を配置する方法について質問している場合は、多くの場合、取得しようとしている情報が多すぎます。モデルがこれらのタイプの詳細な設計上の質問に答えたりキャプチャしたりしないように、モデル要素を抽象化する必要があります。
タスクを実行できる Role アクターをモデル化する場合があります。次に、元のアクターが特定のロールを取得しようとする別のユース ケースを作成できます。