私は、(特に) 次のタイプの役割を持つシステムをモデル化しています。
ここにいくつかの追加の事実があります:
一般的な Player の特殊化としてアクターを抽象化できますが、システムの「正式な分析」の一部として「すべてを組み合わせる」方法がよくわかりません。
誰でも助けることができますか？
ユース ケースとユース ケース モデルの両方がアクターを利用します。最初に、ユース ケース モデル レベルで、ユース ケースを介した高レベルの機能と、それらのユース ケースと対話するアクターの両方をグラフィカルに表現する必要があります。
あなたの説明から、個人プレーヤーは俳優であり、グループプレーヤーは役割のように聞こえます. 役割は管理に関するものであり、管理を扱うユースケースが必要になる場合があります。
つまり、Marksman、Navigator、および Engineer アクターはすべて Player のタイプになります。マークスマン、ナビゲーター、エンジニアの役割は、グループの役割になります。これらのマークスマン、ナビゲーター、およびエンジニア アクターが対話する機能を定義するユース ケースは、役割を扱わないでしょう。
いずれにせよ、特定のアクターをサブアクターに分割することに気付いた頃に、別の図で実際にアクターのモデル化 (または階層での描写) を開始することをお勧めします。これは、矛盾や相互関係を振り払うのに役立ちます。
次に、ユース ケースをさらに深く掘り下げると、実際にアクターの記述と定義を開始します。
ユースケース分析は、ソフトウェアがどのようにではなく何を行うかを明確にします。そのため、さまざまな役割のさまざまな機能とそれらを集約する方法を説明する必要がある場合は、役割と機能の間の一般的な関係を示すクラス図を作成してみてください。または、これらの関係を模範的に示す役割ごとにオブジェクト図を設定します。
ユースケースのアクターは、システムと対話する役割を表すと言われています。ただし、アクターのポイントは識別することであり、説明することではありません。したがって、アクター モデルのみに基づいた承認システムなどを作成することはできません。あなたの場合、これはプレーヤーをアクターとして識別する必要があることを意味し、それらのアクターに利用可能なユースケースに応じて、いくつかの一般的なカテゴリが存在する可能性があります。もちろん、あなたの場合のように低レベルに行くことはできますが、ユースケースの価値は失われます。そのため、クラス図を使用して、さまざまなカテゴリのプレーヤーを詳しく説明することを検討します。もう 1 つのポイントは、1 人のユーザー (この場合はプレーヤー) が複数のアクター (具体的なタイプのグループ プレーヤーなど) の役割を担うことができるため、ユース ケースでは役割 (アクター) の構成とライフサイクルが失われることがわかります。
アクターの一般化の理由を要約すると、ロールをモデル化できるようになるためではなく、関連するユース ケースを再利用できるようになるためです。