ユースケースのプライマリアクターとセカンダリアクター
一次アクターはユースケースを開始するアクターであり、二次アクターは特定のサポートを通じてユースケースの完了を支援するアクターであることはわかっています。通常、プライマリアクターはシステムの境界の左側に配置され、セカンダリアクターはシステムの境界の右側に配置されます。しかし、図書館員と読者という2人の俳優がいる図書館システムについて考えてみましょう。ここでいくつかの特定のユースケースを考えてみましょう：
1）図書館が図書館システムに本を追加できるユースケース。この場合、司書は主な俳優です。
2）読者が本を借りるユースケース。より具体的には、読者は借りる必要のある本を司書に渡し、司書はバーコードを使用して本をスキャンし、このシステムに必要なすべての情報（リーダーID、読み込み時間など）を入力します。この場合、司書は二次俳優です。
だから私の質問は、司書をユースケース図のどこに置くかです？システムの境界に対して右または左？なぜなら、いくつかのユースケースでは、彼は他の主な俳優と副俳優です。
プライマリアクターを左に配置し、セカンダリアクターを右に配置することは、その慣習を知っている人々が図を読みやすくするための慣例にすぎません。これはUML標準の一部ではないため、必要に応じて行うことができます。
個人的には、それが1つのUCのプライマリアクターである場合、同じダイアグラムで別のUCのセカンダリアクターであっても左側に配置します。しかし、反対側に置くことも間違っていません。
これを別の角度から見る必要があります。あなたの説明に基づいて、あなたは図書館の従業員の日々の活動をサポートするソフトウェアを作っています（あなたはfor彼らを作り、themの仕事を助けるために作っています）。したがって、ライブラリ自体をモデル化するのではなく、ライブラリのビジネスドメインをモデル化します。主なアクターは、基本的に、モデル化しているドメイン内でビジネス機能を実行するために、そのシステムと直接対話する人々です。たとえば、システムが日常業務を可能にする、または何らかのサービスを提供するためにシステムを使用している可能性があります。彼らのために。
あなたのケース＃2では、リーダーがsystem（ライブラリアンと対話する）と対話することはないため、このモデル（およびこの特定の使用例）のコンテキスト内では、読者はアクターではありません（ただし、ユースケースの説明で言及できる外部の詳細）。ユースケースの意味は、「読者が本を借りる」ではなく、次のようなものです。 「これまで」（システムはライブラリのビジネスニーズを満たすように構築されていることを思い出してください。また、付記として、ここではユーザーストーリースタイルの説明を使用しました[role-what-why]）。 （もちろん、ライブラリには読者のポータルがシステムの一部である可能性がありますが、それは状況が異なり、ユースケースも異なります）。
だから私は司書を主な俳優として扱います。何かをモデリングするときは、モデルの境界がどこにあるかを決定する必要があります。たとえば、読者が実際に本を他の人のために購入している場合、その人はその人の発起人ですか？そのように問題について考えることは役に立ちますか？あなたの質問に基づいて、構築しているシステムだけでなく、ライブラリ全体をエンティティとして含めるように境界を暗黙的に設定しました。それは自然に感じるかもしれませんが、ソフトウェア開発の観点からは必ずしも有用ではありません。
二次俳優に関するメモ。実践または推奨事項に従うときは、その背後にある理由を理解してください。それを行うのは必ずしも容易ではありませんが、熟考する価値はあります。そもそも、なぜ一次俳優と二次俳優を区別するのでしょうか。アイデアは、システムが存在する主なビジネス上の理由、つまりシステムを構築する人々のニーズを満たすために必要な主な機能を特定し、それらの主な観点からシステムを構築できるようにすることですニーズ。これは"why"の背後にあるものです-哲学的な理由ではなく、誰かのためのシステムを構築するときに関連する情報を収集するためです。
この方法で物事を説明するには、いくつかの練習が必要ですが、それは重要です。同じ例を使用すると、司書は特定の画面にアクセスして本に関するデータを入力することを望みません（これにはビジネス指向の「理由」がありません）。代わりに、図書館員はチェックアウト情報を入力して、図書館が提供する主要なサービスを提供できるようにしたいと考えています（読者に本を借りさせ、本を追跡させます）。これらを理解するには、ドメインで作業している人やシステムを使用する人（ドメインの専門家）と話す必要があります。これらを理解して、適切なアーキテクチャのトレードオフを作成し（常にトレードオフがあり）、最も重要なユーザーと最も重要な機能をサポートする初期アーキテクチャを考え出しましょう。 「初期」と言いますが、特定の変更パターンが出現したことに気付いた場合など、将来ドメインについてさらに学習するときに、まだ調整する必要があるかもしれません。
セカンダリアクターは、プライマリアクターのワークフローをサポートするために存在するという意味で、サポートアクターですが、それ自体はビジネス価値の原動力ではありません。これらすべてを事前に考える必要がないことに注意してください。主要な俳優を特定し、それがあなたにとって有益であるかぎり、それに沿ってモデルを修正してください。それをすべて真っ先にしようとすることは、非常に滝のようなものです。アジャイル設定では、短い反復があり、これにより、理解が深まるにつれて、仮定を学習、テストし、時間をかけて再構築することができます。
Christophe's answer は非常に良いですが、私とqwerty_soの間のコメントは Alistair Cockburnの書き込み効果的な使用例 につながりました。本の大部分は、コックバーンが「完全に着飾った」フォーマットのユースケースを文書化したものを使用していますが、「カジュアル」、「1列のテーブル」、「2列のテーブル」、「RUPスタイル」、「if -statementスタイル」、「Occamスタイル」、「diagramスタイル」（UMLユースケース図ではなく、シーケンス、コラボレーション、およびアクティビティー図の使用）、およびUMLユースケース図。
付録は、UMLユースケース図の説明に特化しています。この付録では、ガイドラインの1つは「右側にサポートするアクター」を配置することです。
allプライマリアクターをシステムボックスの左側に配置し、右側をサポート（セカンダリ）アクターに残しておくと便利です。これにより、一次アクターと二次アクターに関する混乱が軽減されます。一部の人々は、自分のダイアグラムに補助的な俳優を決して描きません。これにより、彼らは両側に主演俳優を配置することができます。
したがって、プライマリアクターを右側に配置し、セカンダリアクターを左側に配置するという考えは、UML標準の一部ではありません。この本が出版されたとき（2001年）でも、標準であるようには見えません。これは単にCockburnのスタイルであり、一部の人々は彼らの図表に二次俳優さえ含まないことさえ確認しています。
コックバーンの主演俳優の定義は、質問で提示されたものからわずかに逸脱していることも指摘しておきます。主な俳優は「システムにそのサービスの1つを提供するように要求する利害関係者」であり、主な俳優は「システムに関して目標を持っている」ことです。これは「ユースケースをトリガーするアクター」です。
2つの質問があります。
- 主な俳優は誰ですか？
- 主要なアクターはユースケース図のどこに行きますか？
私は読者か司書が主演者であると主張することができると信じています。彼の現在のシステムの実装では、ライブラリアンはソフトウェアと対話する人ですが、リーダーまたはライブラリの常連客は、システムにサービスを提供するように要求する人です。これは、ソフトウェアの境界とシステムの境界の問題であり、サービスを提供するためにシステムに要求することの正確な意味です。これは意見の分かれる問題です。ここに正誤はありません。
プライマリアクターが誰であるかがわかったら、セカンダリアクターをダイアグラムに表示するかどうかを決定する必要があります。結局のところ、図を含めるつもりなら、それは読みやすいはずです。読みやすさを向上させると、図に俳優を配置するかどうか、またどのように配置するかが決まります。コックバーンのガイドラインから始めるのは興味深いかもしれません。
ただし、UMLユースケース図に関する次の2つの情報を提供しなかった場合は、失礼になります。
Cockburnの効果的なユースケースの記述：
グラフィックと関係を心配して多くの時間とエネルギーを費やしていると、間違った場所でエネルギーを消費しています。
そして、 Martin Fowler in UML Distilled から：
ユースケースの作業では、図にあまり力を入れないでください。代わりに、ユースケースのテキストコンテンツに集中してください。
ユースケース図は非常に高レベルであり、アクター、ユースケースのタイトル、および関係を示しています。より詳細な情報には、UMLユースケース図では提示できないほど多くの価値があります。ダイアグラムのどこに俳優を配置するかについて、細心の注意を払うところまで来ている場合は、間違った場所にエネルギーを費やしています。