ビデオレンタルのユースケース図
次の俳優がいるビデオレンタルストアに関する次の使用例があります。
- メンバー（ゴールド、序数）
- アシスタント
- サプライヤー
- 店員
システムは動画をレンタルおよび予約するためのdesktop applicationであり、ショップにはメンバー向けにさまざまな動画の在庫があります
gold membersは最大10本の動画を借りることができますが、ordinal members5Assistants身元の証明を提供したら、メンバーをクラブに追加しますmemberが来店し、店のアシスタントにビデオのレンタルを依頼できますassistantは、memberの可用性と制限を確認しますGold Membersは、採用期間を延長することを選択できます- メンバーはビデオを使い終わったらビデオを返却します（返却時間がレンタル期間を超えた場合、メンバーは罰金を支払う必要があります）
membersは、電話をかけて予約することもできます。この場合、assistantはrent a videoと同じプロセスを実行します（空き状況を確認し、メンバーの制限を特定して確認します）
ビデオショップがオンラインになりました：
membersはオンラインでカタログを閲覧できますclerkは、新しいビデオを注文し、supplierから受け取ったときにカタログに追加します
ユースケースのイラストを作成しました。
1-ユーザーがassistantとともにrent a videoおよびreserve a videoユースケースに関連付けられていることは正しいですか？
2-clerkが注文したときにサプライヤーをどこに追加できますか
更新されたユースケースモデル：
- 削除された注文の作成と注文の受信
- （賃貸料と予約）の両方に含まれる追加の検証ユースケース
1.複数の関連付け：
アクターMemberがいくつかのユースケースと関連しているのは正常です。ただし、各関連付けは通常 関連付けはバイナリ であるため、直線の直線として表示されます。行の一部の「多重化」は、IMHOを混乱させるように見えます。
複数のアクターが同じユースケースに関連付けられていることも正常です。つまり、両方が関与していることを意味します。つまり、Reserve a videoの場合、MemberとAssistantの両方が関与します。 。アシスタントが常に関与するとは限らない場合は、多重度を使用して、このアクターがオプションであることを明確にする必要があります。
2.間接俳優
ユースケースはビジネスプロセスモデルではありません。ユースケースに関与しているアクターを示します。そして、ユースケースは検討中のシステムに関するものです。ベンダーがシステムを使用しない場合、ベンダーはアクターではありません。
目的を明確にするために、UCダイアグラムにメモを作成して、店員がベンダーの納品を受け取り次第、このユースケースに対応することを平文で説明できます。
もちろん、システムが何らかのe-orderingシステムのベンダーシステムと対話している場合は、このリモートシステムをアクターとして表示できます。ただし、ベンダーはシステムと対話しないため、ベンダーは表示されません。
3.追加の考え：
ビジネスユースケース
ユースケースの発明者であるIvar Jacobsonは、彼の著書「オブジェクトの利点」で、ユースケースはビジネスモデリングにも使用できることを示唆しています。この場合、意味論的な変化があります。検討中のシステムはもはやITシステムではなく、会社です。このようなユースケースでは、ベンダーを俳優として示すことができます。しかし、これはあなたが達成しようとしていることとは完全に異なります。
ユースケース図は、全体像を示すことを目的としています。シンプルにしてください
心理学的研究では、6-7を超える要素を含む図はほとんどの人にとって把握するのが難しいことがわかっています（よく理解しているとしたら、それは私たちの脳の短期記憶の制限に関するものです。アイテムを精神的にグループ化します）。
これが、UML図を異なるビューに、異なるフォーカスで分割できる理由です。いくつかの図は、同じモデルのさまざまな部分を示しています。
しかし、あなたの場合、異なる
check this、verify thatなどを削除することで、簡素化を開始できます。これらはユーザーのサブゴールであると主張する人もいますが、私はこれらを強く疑うでしょうユースケースの単なる機能分解にすぎません。ここに表示する必要がありますか？彼らは他のどこかで再利用されていますか？実行される他のチェックはありませんか？