私は現在、私たちが構築している新しいシステムのユースケース図を作成する過程にあり、興味深いシナリオに出くわしました。
システムには、企業ユーザーおよび非企業ユーザーを含む多数の主要なアクターがあります。これらの各ユーザーは、私の会社の直接の管理下にある場合とない場合があるさまざまな異なるデバイスタイプからシステム内で「何かを行う」ことができます。
企業ユーザーは、企業の管理対象デバイスまたは個人のデバイスから「何かを行う」ことができます。
非企業ユーザーは、私の会社によって「管理されていない」デバイスから「何かをする」ことができます。
この関係をユースケースの図でどのように表示しますか?アクターとデバイスタイプの組み合わせは、システム設計の基本的な考慮事項です。
現在、「管理対象デバイスのユーザー」と「非管理対象デバイスのユーザー」を使用して、おそらく俳優の説明タブ内の別のアーティファクトで可能なすべての組み合わせを明確に説明しています。他の人は、私はユースケースの俳優としてデバイスを持っているべきだと言います。
システムの3つのアクターとして、「企業ユーザー」、「非企業ユーザー」、および「デバイス」を設定できます。私は貴重ではありません。それが正しいことを確認したいだけです。
それで、最も適切なアプローチはどれですか?
あなたの物語から、私はそれを理解します:
User
がいて、1つのユースケースdo something
ダイアグラムはできるだけ単純にしてください。コメントと制約は、組み合わせの爆発なしにユースケースモデルに追加できます。
あなたの図は確かに簡略化されています。より複雑なモデルでは、異なる actors が異なるユースケースと相互作用する可能性があります。
自然な選択は、corporate user
と external user
、特にこれらのユーザーが異なる役割を持つ場合(たとえば、外部ユーザーは顧客、または特定の役割を持つ外部の利害関係者)。
もちろん、管理されていないデバイスが使用されている場合、内部ユーザーが相互作用しないか、ユースケースとわずかに異なる方法で相互作用する可能性があります。しかし、これは上で説明したように制約のままです。
UML 2.5仕様の非常に乾燥した正式な定義よりも、UCの発明者である、より理解しやすい Ivar Jacobsonの定義 を好みます。
ユースケースは、特定のユーザーの特定の目標を達成するためにシステムを使用するすべての方法です。すべての使用例のセットをまとめると、システムを使用する便利な方法がすべて提供され、システムが提供する価値が示されます。
結果:ユースケースの選択は、ユーザーの目標に基づいて行う必要があります。デバイスは、アクターがインタラクションで実行できる操作(たとえば、エラーのリスクのためにスマートフォンで禁止されている危険な操作、またはセキュリティリスクのために管理されていないデバイスからの操作)に影響を与える可能性がありますが、やりたいことには影響しません。
つまり、デバイスはシステムと対話するための手段にすぎず、その使用を制限する可能性があります。しかし、それらはユーザーの目標を定義しません。
結局のところ、目標主導の原則はアドバイスにすぎません。ナラティブは企業ユーザーと外部ユーザーの本当の違いであり、管理対象外のデバイスを使用する企業ユーザーは技術的な理由で制約されているため、それを主張しました。
しかし、UMLは、ユースケースをゴールドリブンにする必要はありません。したがって、それが理にかなっている場合は、最初の図を使用することを決定することもできます。これは合法であり、 異なるユーザーインターフェイスが異なる機能を提供する の場合にも使用されます。