1

ユースケースをモデル化しようとしています。基本的には、クイズショーでラウンドがどのようにプレイされるかです。ユースケースのアクターはクイズマスターです。彼は参加者に質問をします。

このユースケースでは多くのことが起こっていますが、私の問題は、プレイヤーがボタンを鳴らして、質問した質問に答えて、判断できるようにするのをクイズマスターが待たなければならないという点に帰着します (正しいか間違っているか)。 .

アクター「候補者」がクイズマスターが尋ねた質問に答えるために従う別のユースケースがあります。

クイズマスターが自分のユース ケースを続行する前に、別のアクターがユース ケースを実行するのを待たなければならないという事実をどのようにモデル化すればよいでしょうか? それとも、それらすべてをより小さなサイズのユースケースに分離する方がよいでしょうか。私の先生はそれに対して反対したので、ここでセカンドオピニオンを探していました.

4

5 に答える 5

4

user3934037が提案したようにインクルードを行うか、ユースケースを分離して事前/事後条件で作業することができます。その場合、ユースケースがあります

  • 質問をする

    -> 前提条件: 候補者の準備ができている

    -> 事後条件: 質問済み

  • 質問に答える

    -> 前提条件: 質問済み

    -> 事後条件: 質問に回答しました

  • ジャッジ応答

    -> 前提条件: 質問に回答済み

    -> 事後条件: 応答判定

ユースケースを順番にリンクする代わりに、それらを互いに独立したままにします。ユースケース「ジャッジレスポンス」は、特定のユースケースが終了するのを待つのではなく、前提条件が満たされるまで待つのですが、そうなりました。

一般に、実行の順序をユース ケース分析から除外することをお勧めします (ビジネス プロセス モデリングに残します)。

于 2015-01-20T13:19:53.553 に答える
3

私はこれについて Geert に同意しますが、彼のアプローチをもっと強く勧めたいと思います。ユースケースは、あらゆる種類の流れ、期間を説明するようには設計されていません。事前条件と事後条件を使用して実行順序を推測できますが、ユース ケースの実行順序を明確にしたい場合は、Vladimir のアドバイスに従って、アクティビティ図を使用してマッピングします。

于 2015-01-20T18:31:25.883 に答える
0

UMLは、推奨事項(AFAIK)によるこの必要性を明示的にカバーしていません。現在のユースケース分析に奇妙な点があることを示しているようです。設計スコープ目標レベルを使用してユースケース図をいくつかの詳細レベルに構造化すると、順序付けが不要になる場合があります。

これは、Alistair Cockburn が記事「ユース ケースの目標と設計範囲」でユース ケースの密度のバランスを取ることを提案している方法です。

ここに画像の説明を入力

以下も参照してください。

于 2015-01-29T19:29:12.940 に答える