web-dev-qa-db-ja.com

UMLユースケースで「ユースケースのポリモーフィズム」を使用できますか？

私は2つのアクターを持っています：UserとAdminはシステムと相互作用します。 Adminは、Userからの固有のユースケースへの一般化を使用しています。 authenticateという名前のユースケースがあり、2つの異なる動作が必要です。このユースケースの事後条件は次のとおりです。

  1. Userがそれを呼び出している場合、usernameのみを要求する必要があります
  2. Adminがそれを呼び出している場合、usernameとpasswordを要求する必要があります

ユースケース図は次のようになります。

Example

umluse-casegeneralization
5
JChris

この回答は ML 2.5.1仕様 用に更新されました。

まず、表記が有効であるように見えます。

アクター（18.2.1）はUseCase、コンポーネント、およびクラスへの関連付けのみを持つことができ、これらの関連付けはバイナリである必要があります。

管理者とユーザーの関係は汎化です（9.9.7で定義）。これは、Relationship（7.8.15で定義）の特殊化であるDirectedRelationship（7.8.5で定義）の特殊化です。リレーションシップの特殊化は、DirectedRelationshipとAssociationです（11.8.1で定義）。つまり、汎化は関連ではありません。

アクターは、有効な関連付けを制限します。ただし、アクターの定義は他の関係を制限しないため、定義の階層を調べて汎化が有効かどうかを判断する必要があります。

アクターはBehavioredClassifier（10.5.1）の特殊化です。定義されているAssociation Endsのいずれもこのケースをカバーしていないため、引き続き調査する必要があります。 BehavioredClassifierはClassifier（10.5.1.3）の特殊化です。分類子の関連端の1つは汎化です。分類子は分類子間の一般化を可能にし、アクターは一般化に対するさらなる制限なしに分類子であるため、関係は有効であるように見えます。

2つのアクター間の汎化関係を示す図の例はありません。また、この関係について（私が見つけることができた）テキストでの議論はありません。それについて学ぶ唯一の方法は、アクター、アソシエーション、および汎化の正式な定義を、それらの階層全体にわたってたどることです。

次に検討することは、この図が読者にとって意味があるかどうかです。

正式には、ユースケースはUML仕様のセクション18で説明されています-ユースケースはシステムが提供する一連の動作であり、この一連の動作にはバリエーションも含まれます（バリエーションには例外的な動作やエラーが含まれますが、これらに限定されません）取り扱い）。非公式には、ユースケースは「通常、目標を達成するためのロールとシステム間の相互作用を定義するアクションまたはイベントステップのリスト」です。

読者として、説明文のない図を見た場合、Authenticateユースケースで定義された動作は、管理者とユーザーの両方で同じであると想定します。結局のところ、どちらもAuthenticateと呼ばれる同じ一連の動作と関係があります。図の単一のシンボルが2つの異なるイベントステップのセットを表すとは思いません。

UMLでは、拡張と包含関係や汎化などによって、ユースケースを相互に関連付けることができます。これらを使用して、ユースケースの動作を変更できます。

UMLユースケース図で表現したいすべてのものを表現できると思います。ただし、質問に示されている例が、関係者に情報を伝達するための最良の方法であるとは確信していません。

私の好みは、一般的にユースケース図を避けることです。代わりに、使用例をキャプチャし、それらを相互に関連付け、使用例全体で共有される共通の手順または情報を1つの場所に抽出するために、テキストまたは表形式の方法の1つを使用します。これは、Martin Fowlerが ML Distilled で提供するアドバイスに似ています。

ユースケース図が必要であると強く感じている場合は、Authenticateのユースケースをどのように表現するかを見て、実際には2つの異なるフローがあることをより明確にします。ここには、すべて仕様に準拠するいくつかの異なるオプションがあると思います。

7
Thomas Owens

ユースケース間の一般化関係を使用して、2つのユースケース間の共通性を因数分解したいと思います。

enter image description here

電話での注文とインターネットでの注文のユースケースは、抽象的な注文のプレイスオーダー（イタリック体）の特殊化です。

つまり、動作、構造、目的に共通性があるユースケースが2つ以上見つかった場合、一般化が使用されます。これが発生した場合、共有パーツを新しい、多くの場合は抽象的なユースケースで記述できます。その後、子のユースケースに特化します。

プロジェクトの理解を深めると（および）を使用してユースケースをさらに構造化します。

注意：（ ユースケースの詳細 ）

  1. 親ユースケースは、親のより具体的な形式を表す1つ以上の子ユースケースに特化できます。
  2. 親も子も必ずしも抽象的ではない
  3. ほとんどの場合、親は抽象的ですが。
  4. 子は、親のすべての構造、動作、および関係を継承します。同じ親の子は、すべて親の専門分野です。
  5. 一般化は、ユースケースとアクターの両方に適用できます
1
Chk Tsang