0

私はUMLを研究していて、ユースケースについて読んでいます。私が見るすべての例は単一のシステムを扱っており、エンドツーエンドのプロセスをどのようにモデル化するのか疑問に思いました。それで、私はかなり典型的なエンタープライズシナリオを作成し、それをモデル化しようとしてきました。答えられなかった質問があります。

シナリオ： 私のビジネスユースケースは、買い物客が注文としてベンダーに受け取られるショッピングカートを作成することです。

エンドツーエンドのプロセスフローは次のとおりです。

  1. 買い物客はカートを作成します
  2. マネージャーがカートを確認して承認/拒否し、購入システムで発注書が作成されます。
  3. 購買システムは、新しく作成されたすべてのPOをそれぞれのベンダーのシステムに送信します。
  4. ベンダーはPOを注文として受け取ります。

ただし、悪魔は詳細に宿っているので、次の詳細を追加して、より複雑にすることにしました。

  1. ショッピングと購入のシステムのコミュニケーションは、ポイントツーポイントでリアルタイムです。
  2. POは、ファックスまたはインターネットを介してベンダーに送信できます。すべてのPOは、ベンダーに送信される前にキューに入ります。キューはX分ごとに処理されます。間隔として10分を選びました
  3. 購入ベンダー接続はミドルウェア（ESB）を使用します。

質問：

  1. 私には3つのシステムユースケースがあると思います：買い物客-カートの作成、マネージャー-カートのレビュー、時間-ベンダーへのPOの送信。購買システムとベンダーシステムの間にESBシステムがありますが、正しいですか？
  2. ミドルウェアは上記のユースケースのいずれかではアクターではないため、プロセスへのESBの関与をモデル化する必要があります（購入-> ESB、ESB->ベンダー）。
  3. 2つのシステム境界または1つのシステム境界を描画しますか？私はベンダーのシステムを二次的なアクターとして持つべきだと信じているので、私はショッピングシステムと購買システムしか持っていません。または、それらをE2Eシステム（調達システムなど）にマージしますか？
4

2 に答える 2

0
  1. カートを確認、承認、却下するための個別のユースケースを作成しますが、それ以外の場合は、ユースケースは十分に正確である必要があると思います。ESBシステムはアクターによって直接使用されていないため、ユースケース図には関係ないと思います。
  2. コンポーネント図を作成して、ユースケース図で可能または合理的な、個別のシステムとそのサブシステム間の関係をより詳細にモデル化できます。必要に応じて、接続に関連するユースケースの依存関係としてマークされたユースケース「DeliverPO to Vendor」を使用して、ESBを独自のシステム境界に分離することができます。
  3. ESBに独自の境界を作成するかどうかに応じて、2つまたは3つのシステム境界をお勧めします。ベンダーのシステムが範囲外の場合は、おそらくそれをあまり詳細にモデル化する必要はありません。POを受け取るだけで十分です。
于 2012-06-30T10:23:37.970 に答える
0

ユースケースは、システムのユーザー (アクター) がシステムと対話する方法を説明することを目的としています。それらは、クライアントが理解できるほど単純でなければなりません。ですから、ユースケースの質問で頭を悩ませる前に、あなたのクライアントは誰で、ユースケースを作成することでクライアントにとってより良いシステムをどのように作成しているのかを自問してください.

（哲学的な答えでごめんなさい...）

于 2012-06-30T09:25:39.907 に答える