web-dev-qa-db-ja.com

ユースケースをユースケース図に変換する方法は？

example のようなユースケースがあるとします。

Normal Flow:
The user will indicate that she wants to order the items that have already 
been selected.
The system will present the billing and shipping information that the user 
previously stored.
The user will confirm that the existing billing and shipping information 
should be used for this order.
The system will present the amount that the order will cost, including 
applicable taxes and shipping charges.
The user will confirm that the order information is accurate.
The system will provide the user with a tracking ID for the order.
The system will submit the order to the fulfillment system for evaluation.
The fulfillment system will provide the system with an estimated delivery 
date.
The system will present the estimated delivery date to the user.
The user will indicate that the order should be placed.
The system will request that the billing system should charge the user for 
the order.
The billing system will confirm that the charge has been placed for the 
order.
The system will submit the order to the fulfillment system for processing.
The fulfillment system will confirm that the order is being processed.
The system will indicate to the user that the user has been charged for the 
order.
The system will indicate to the user that the order has been placed.
The user will exit the system.

これをユースケース図、より具体的にはユースケースのバブルに変換するのに役立つ手順またはガイドラインを教えていただければ幸いです。

例に戻って、私はplace orderという名前の1つのユースケースのバブルがあると思います。おそらく、paymentという名前の別のバブルがあり、支払いから注文への "include"関係があります。しかし、私は、より正確な図を思い付くのを助けるために、直感よりも正式なものがあることを願っています。ありがとう!!

documentationumlrequirementsuse-casediagrams
4
Melanie A

ユースケースは1つしかないので、ブロブは1つだけです。ここで言及されている「システム」ではないすべてのアクター（「ユーザー」、「課金システム」など）を追加します。次に、それらを線で結合します。仕事が終わりました。

彼女はあなたが複数のブロブを必要とする理由だけを私に教えます：

  • ユースケースの一部をサブユースケースに分割し、共通の機能がある場合、または
  • 同じダイアグラムに複数のユースケースを置きたい場合。
3
Simon B

原則として、ユースケース図は、アクターへの価値のある目標に対応するユースケースを示す必要があります。

ユースケースは、特定のユーザーの特定の目標を達成するためにシステムを使用するすべての方法です。すべての使用例のセットをまとめると、システムを使用するための便利な方法がすべて提供され、システムが提供する価値が示されます。
- Ivar Jacobson

図の各ユースケースは、さらに 文書化 であり、特に、イベントの通常のフローを説明する説明または表があります。

  • 必須（抽象とも呼ばれる）ユースケース ソリューションを設計するためのより大きな自由を目指すために、段階的な説明を避け、目標に焦点を当てることを試みます。
  • 従来のユースケースナラティブは、ユーザーとシステム間の一連の対話を1列または2列で表現します。
  • 最新のユースケース、つまり se-case 2. はユースケースの全体像を提供しなくなりましたが、ユースケースを小さな部分にスライスし、各部分はユーザーストーリーによって説明されます。

物語は「通常の流れ」から始まり、ユーザーとシステムの間の一連の対話について説明します。それが単一の古典的な使用例の説明です。

他の部分とは無関係にユーザーにとって意味のあるサブゴールが見つかった場合は、このユースケースをさらに分解できます。ただし、ここでは、シーケンスでのみ意味のある密接に関連するアクションのみがあります。つまり、他のユースケースはありませんがあります。私は独立したシステムであるいくつかの二次的な俳優を見ます：Fulfillment system、Billing system、ただしユースケースではありません。

一部の人々（そして残念なことに一部の教師）は、機能の分解（注文、出荷のスケジュールなど）を促進しようとします。これを行うことはできません。ユースケースは関数ではありません。機能分解は、ユースケースの禁止事項です。

1
Christophe