0

シンプルなオンライン ストアがあるとします。ユーザーがストアで達成したいことは次のとおりです。

  1. 登録（アカウントを作成するため）
  2. アイテムを閲覧する
  3. アイテムをバスケットに追加する
  4. チェックアウトと支払い
  5. アカウント情報を表示する
  6. アカウント情報などの編集

ただし、ユーザーが開始できるが、システムを使用する主な目的ではない機能があります。

  1. ログイン
  2. ログアウト
  3. 「エレクトロニクス」部門を選択
  4. 「車両」部門を選択
  5. 配送先情報などを入力

ログインやログアウトなどは UML ユース ケース図に含めるべきではないと私は主張します。その理由は、ユーザーがログインするためだけにオンライン ストアに行きたくないからです。彼らは常に、アカウント情報を表示/編集したり、商品を閲覧して購入したりするという別の目的を持っていました.

同様に、2 つの select 'ステートメント' は、ブラウズ アイテムのユース ケースの一部です。多くの部門が存在する可能性があるため、一般化は使用しません。

最後に、配送情報の入力は、「チェックアウト」または「アカウント情報の編集」のユースケースの一部です。私は通常、これを「アカウント情報の編集」のユースケースとひとくくりにします。

私の主な懸念は、非常に複雑なユースケース図があると、読みにくくなるため、その目的が台無しになることです。

それで、私の質問は次のとおりです。この背後にある私の考えは正しいですか？ユースケース図で「実際の」目標のみをモデル化するのが最善ですか、それともアクターが開始できるすべてのものをモデル化するのが最善ですか?

4

2 に答える 2

0

いくつかのユース ケースを図から除外することは間違いではありません。たとえば、ビジネス部門にダイアグラムを示す場合、運用上のユース ケースを説明する UML モデルを描くことができます。ダイアグラムをプログラマーに渡す場合は、プログラマーが実装しなければならないことを完全に説明する必要があります。これらはシステムの単なるモデルです。

ユース ケース図を描くときは、通常、各ユース ケースの動作も記述します (フリーテキストの説明、疑似コードとして、または相互作用図を使用して)。

UML 仕様には、次のように記載されています。

ユースケースは、システムによって実行される一連のアクションの仕様であり、通常、システムの1人以上のアクターまたは他の利害関係者にとって価値のある観察可能な結果を​​もたらします。

ログインとログアウトは、ユーザーが監視できます。ユーザーがログインすることだけを目的としてサイトにアクセスすることはありませんが、そのようなユースケースには、説明したい実行フローが必ずあります。ユーザーが自分でログインを開始することを許可しない場合、loginの機能を含むユースケースが発生します。ユーザーは、サイトを離れる前にログアウトして、セッション データが自分のコンピューターに保存されないようにすることにも関心がある場合があります。

「エレクトロニクス」部門を選択し、「車両」部門を選択してください...部門を選択しないでください（あまり違いはないと思います）。

モデルに関連する限り、これと他のユースケースを描きます。

于 2013-03-20T12:59:22.870 に答える
0

UML の使用は、アクターができることすべて (機能) またはアクターがやりたいことすべて (目標) を示すことができますか?

それはどちらでもかまいません - UML 仕様はその面で規範的ではありません。Alistair Cockburn は、ユース ケースがどのレベルに焦点を当てているかを示す分類を作成しました。

そうは言っても：

私の主な懸念は、非常に複雑なユースケース図があると、読みにくくなるため、その目的が台無しになることです。

それは非常に現実的なリスクです。個人的には、ユーザーとその目標に焦点を当てることで、UC から最も多くのことを得ることができます。彼らはシステムからどのような価値を得ようとしていますか?

そのレベルに保つことで、「木を見て木が見えない」状況を防ぎ、UC が完全で機能的な分解設計になるのを防ぎます。

h番目。

于 2013-03-20T12:56:18.077 に答える