android - ユースケース図でのリレーションシップの拡張のこの使用法は正しいですか?

Question

画像検索用のモバイルアプリケーションを開発しています

これは私のユースケース図です

アクター＝スマホユーザー

システム = クライアント側アプリケーション

クエリは、サーバーに送信される前にクライアント側で前処理されます (たとえば、音声クエリはテキスト クエリに変換されます)。

このユース ケースを図に追加する必要がありますか?

このようなcqseの拡張使用である可能性があると思います

Answer 1

最初の「一般的なアドバイスとして」:

「「これを追加する必要がありますか?」と尋ねて時間を無駄にしないでください。これを言えるのはあなただけだからです。自問してみてください: これを図に表示または追加すると、どのようなメリットが得られるでしょうか?

モデリングとは、詳細を隠して重要な概念を示すことを意味します。何が重要で何が細かいのかを見極めるのはあなたです。システムを実装して手を汚すからです。

第二に「技術的に」

拡張とは、「ユースケース/シナリオの実行」が オプションまたは条件付きであることを意味します。

したがって、「クエリを前処理する」場合 [ 意味がわかりません。それが何であれ]条件に基づいてオプションで実行されます[「クエリを作成する」ユースケースでx条件が真の場合、「クエリを前処理する」ユースケース/シナリオが実行されると仮定します]、拡張関係を使用して技術的に真です。そのため、自分で判断することができます。

最後に: 技術的に正しいということは、それが正しいという意味ではありません。

可能な限り、「包含」または「拡張」関係を使用しないようにしてください。ユースケースと図をより複雑にします。

最初にユース ケースをテキストとして記述します。次に、ユース ケースに「同じシナリオ」[繰り返し] が見つかった場合は、それらを別のユース ケースとして抽出します。「include」を使用 して、これらの一般的なユース ケース/シナリオを主なユース ケース/シナリオに関連付けます。 メインのユースケースによってオプションで実行される新しい重要なシナリオを見つけたり発見したりするたびに、拡張「関係」を使用してください。

私の個人的なアイデア:

私にとっては、図に「クエリの作成」を表示しないでください.[もちろん、ユースケースを書いているときに、これら3つのユースケースのすべてが同じ方法でクエリを作成する場合、これを別のユースケースとして書き、主なユースケースシナリオを含めます。これにテキストを送信し、インクルード関係を使用すると時間を節約できます。そして、これには何も問題はありません。「ユースケースをテキストとして書いている間」と言うことに注意してください]。

主な質問は、「ユースケース図に表示する必要があるか」です。ですから、私のユース ケース図を誰が読むのでしょうか? または、なぜそのような図を作成するのですか? あなたの文脈に基づいて、あなた自身の判断を下してください。実用的であること。

より詳しい情報：

ユースケースは、目標を達成するためにシステムを使用する一部のアクターの「テキスト ストーリー」です。あなたの状況では、アクターはスマートフォン ユーザーです。

では、ユーザーがあなたのシステムで何をしたいかを自問してみてください。

1. 写真を撮ります。【音程よい】

2. キーボードをタイプする [音が良くない] : なぜ彼/彼女はキーボードをタイプするのですか?彼女/彼の主な目的は何ですか? 写真を検索することを意味しているのかもしれません...その場合、「キーボードを入力する」はユースケースの良い候補ではありません。写真を検索するために、彼はおそらくキーボードの写真名で書くでしょう。しかし、キーボードを入力することは彼/彼女の主な目標ではありません。それは「テキストによる画像検索」ユースケースのステップの一部です。

3. 話す？なぜ彼は話すのですか？彼の声を録音するには? または音声で写真を検索します。再び主な目標？ユーザーが音声で写真を検索できるということだと思います。[ 音声で検索するユースケース ]
4. Make Query : クエリは「開発者」用語です。もちろん、システムを実装するときは、データベースに対してクエリを実行します。ただし、ユースケースは開発用ではありません。これらは、ユーザーの要件をキャプチャするためのものです。ただし、ユースケースで、ユーザーの観点に応じて「クエリ」の多くのユースケースで同じ手順を実行する場合、「インクルード」関係で使用することは問題ありません

5. クエリを扱う :[ 音声クエリをテキストクエリに変換する ] したがって、これはユースケースではありません。「音声で検索」のステップの一部である可能性があります: 「音声で検索」ユースケース テキストを記述する場合:

   メインシナリオ:

   1. スマートフォン ユーザーは音声で検索する写真の名前を伝えます。
   2. 画像検索アプリケーションは、この音声を録音し、テキスト クエリを生成します。
   3. 画像検索アプリケーションは、このクエリを実行します。
   4. 画像検索アプリケーションは、クエリの結果を表示します

   ...

   代替シナリオ

   2 a) 画像検索アプリケーションが音声を認識できない: .....

   私にとっては、これでも不必要な技術的な詳細が追加されます。ステップ 2 については言及しない場合があります。音声からのテキスト クエリの生成は実装の詳細です。ただし、ユースケースの焦点は、「ユーザーがアプリでできること」です。

ユース ケースは図ではないことを忘れないでください。ユース ケース図は、システムの主な機能の概要を視覚的に示すのに適しています。 ユース ケースは「テキスト ストーリー」です。

したがって、ユースケース図でそれらを表示するには多くの方法があります。

原則として、ユース ケース図には最小限の拡張、インクルード、一般化の関係を使用します。ユース ケースの関係を特定するために多くの時間を無駄にしないでください。

無料のユース ケース リソースについては、Craig Larman の有名な本の無料の章を確認してください。

ユースケース入門