問題タブ [use-case]

このユースケース図は複雑すぎますか？私は初めてユースケースを実装しようとしていますが、それをボールパーク内に収めようとしています。

この単純な問題のユースケース図を作成する必要があるとします（これは、私が行っているはるかに大きな演習の一部です）。

（Webアプリケーションの）登録ユーザーは、2つの方法で観光名所を検索できます。カテゴリ（例：美術館、公園、劇場、遺跡）または場所（市、郡）です。

このUCDをどのようにモデル化する必要がありますか？

最も簡単な方法は、アクター（登録ユーザー）、2つのユースケース（カテゴリで観光名所を検索し、場所で検索）、セカンダリアクター（クエリを処理して結果を返すWebアプリケーションのサーバー）です。 ）。

私の懸念は、このように4つのカテゴリと2つのタイプの場所がユースケースに存在しないことです。

私は「拡張」関係を使用することを考えていました。たとえば、「カテゴリで検索」のユースケースを拡張する「公園の検索」という名前のユースケースを追加します。拡張ポイントは、ユーザーが公園を検索することを選択したイベントになります。

または、「カテゴリで検索」と「公園を検索」の継承関係を使用することもできます...うーん...少し混乱しています...

USDを使用してこの小さな問題をどのようにモデル化しますか？

ありがとう、ルカ

PopupWindow と Dialog をいつ使用するかは不明です。どんな洞察も大歓迎です。ありがとう。

ユースケースでどの関係を使用すべきかわかりません。アクターがアカウントを管理できるユーザーであるとしましょう。-作成; -消去; -アップデート;

アカウントの管理をユースケースとして作成し、[作成]、[削除]、[更新]にリンクする必要があるかどうか（ある場合）、関係を拡張または含めるかどうかについてのアイデアはありますか？または、作成、削除、更新を別々のユースケースとして残したほうがよいでしょうか？

質問はそれをすべて言います、どうすればプラグインの視覚的表現を構築できますか？私はそれを何か他のものと見なすべきか、単に表示しないべきだと考えていますが、これを確認するための証拠（十分な量）を見つけることができません。

どのような状況でも、ユースケースにプラグインを表示するべきではありませんか？

代わりに、プラグインをパッケージまたはアクターとして表す必要がありますか？（もしそうなら、どのような接続が必要ですか、含めますか？）

それとも、インターフェイスのように表現する必要がありますか？

たぶん、私はここで軌道に乗っていないのかもしれません。前回UCDを作成したのは、1年前か何かでしたが、何も使用しないと、すべてがずれてしまいます。だから私はここでいくつかの「初心者」のアドバイスを気にしません:)

Webサイトのメンバーが自分の個人プロファイルと他のユーザーの個人プロファイルを表示できる場合、2つの別々のユースケースを作成する必要がありますか？メンバーである必要があります-自分のプロファイルを表示し、メンバー-他の人のプロファイルを表示しますか？または、メンバーだけです-プロフィールを表示するだけで十分ですか？

私はチームでプロジェクトを開始しており、方法論として SCRUM を使用しています。SCRUMは初めてです。機能をリストし、ストーリーを作成しました（ユーザーストーリーと技術ストーリー、およびそれらのタスク）。

私はあらゆる開発プロジェクトを開始するための厳密な UML アプローチを持っています。すべての機能をリストした後、次のステップはユーザー ケース ダイアグラムを作成して、アプリケーションが何を実行し、誰がそれを操作するのかを誰もが確認できるようにすることです。しかし、私のチームは、SCRUM で UML を使用することに関心がないと言いました。

UML のユーザー図を使用して、SCRUM のユーザー ストーリーを表すことはできますか? SCRUMで使用できる他の図はどれですか? (クラス図やシーケンス図のないアプリケーションは想像できないので、ばかげた質問かもしれませんが、SCRUM の専門家からのアドバイスを本当に知りたいです)

ありがとう。

理論的には、ユースケースにはいくつの基本フローを含めることができますか? また、代替フローは (サブ) 代替フローを持つことができますか? ベストプラクティスは何ですか?

すべてが自動化されている場合、ユースケース図を正確に描くにはどうすればよいでしょうか? 以下は、私が受け取ったリクエストの例です。

「プレイヤーが 2 時間いない場合、ゲームサーバーを特定のマップにリセットするか、ゲームタイプを切り替える変更を行います」

現在、基本的に古典的な意味でのユーザーはいません。問題の変更は、サーバーに追加されると自動的に開始されます。一定の間隔でプレイヤーの数をポーリングし、その数がゼロになるとカウントダウンを開始するタイマーがあると考えてください。次に、タイマーは、変更をトリガーするメソッドを呼び出します。

この説明でどの俳優を見ることができますか?

ユース ケース図に 2 つ以上の境界を追加できますか?