ガイドライン: アクター
トピック
システムの目的を完全に理解するには、システムが誰のためのものか、つまり誰がシステムを使用するのかを知る必要があります。異なるユーザー・タイプをアクターとして表現します。
アクターは、システムとデータを交換するものすべてです。ユーザー、外部ハードウェア、別システムなどがアクターになることができます。
アクターと個々のシステム ユーザーとの違いは、アクターが実際のユーザーではなくユーザーの特定のクラスを表している点です。複数のユーザーが同じロールを演じることができます。これは、複数のユーザーが 1 つの同じアクターでかまわないことを意味しています。その場合、各ユーザーはアクターのインスタンスを構成します。

Ivar と Mark はリサイクル マシンのオペレータです。この 2 人がマシンを使っている時、それぞれはオペレータというアクターのインスタンスで表されます。
ただし、状況によっては、アクターによってモデル化されたロールをただ 1 人のユーザーが演じることもあります。たとえば、小規模なシステムでは、システム管理者のロールを演じるのが 1 人だけである場合があります。
同じユーザーが複数のアクターとして行動することもできます (つまり、1 人の人物が別のロールになることができます)。

Charlie は主に倉庫管理者として倉庫処理システムを使用しますが、通常の倉庫スタッフとして倉庫処理システムを使用することもあります。

システムの周囲にあるもので、システムのアクターになるものは何でしょうか。
システムを使用する個人について検討することから始めます。どのように分類できますか。特定の個人(2、3 人)を念頭に置いて、その人たちのニーズを満たすアクターを探すようにするとよいでしょう。アクターを識別するときは、次の質問を念頭においておくと役に立ちます。
- 誰が情報を提供し、使用し、削除しますか。
- 誰がこの機能を使用しますか。
- 誰が特定の要求に関心がありますか。
- 組織内のどこでシステムが使用されますか。
- 誰がシステムのサポートと保守を行いますか。
- システムの外部リソースは何ですか。
- このシステムと相互作用する必要があるシステムはどれですか。
システムの周囲にはいくつかの異なる側面があるので、これらを独立したアクターとして表現します。
例:
倉庫内の作業をサポートする倉庫処理システムのユーザーは、倉庫要員、注文登録員、倉庫管理者など、いくつかのカテゴリに分けられます。これらのカテゴリはいずれもシステムにおいて特定のロールを持っているので、それぞれを独立したアクターで表す必要があります。
- システム管理など、システムの 2 次機能を実行するユーザー。
例:
缶、ビン、木箱の再生に使用するリサイクル マシンでは、顧客がメインのアクターで、システムは主にこのアクターのために作られています。ただし、誰かがマシンを管理する必要があります。このロールは、オペレータというアクターで表されます。
例:
建物の中の温度を制御する換気システムは、建物内のセンサーから常時計測データを得ます。したがって、センサーは 1 つのアクターです。
例:
ATM は、銀行口座を保持している中央システムと通信する必要があります。中央システムは恐らく外部にあるシステムなので、アクターとする必要があります。
インターネットベースのアプリケーションを作成する場合、主要なアクターはある意味で匿名性を持ちます。アクターが誰であるのか実際にはわからず、スキルと背景について何の仮定もできません。しかし、そのようなアクターがシステムに対して演じてほしいロールは記述できます。
例:
情報提供システム (サーチ・エンジンなど) のアクターは純粋に匿名のアクターであり、特定のトピックについての情報を探すためだけにアプリケーションにアクセスします。
例:
市民や「ネティズン (ネットワーク上の市民)」に法律や規制、
業務、帳票などの情報を提供する政府情報系サイト。
たとえば、米国では国税庁が税金の還付方法に関する情報のページを開いています。
このサイトでは、すべての書式を電子的に利用できるだけでなく、
税金の還付手続きを個人が電子的に行うことができます。
この場合の主アクターのロールは、米国で税金の還付の申告方法に関心のある人となります。
当然、いったん還付申告を試みた個人は、匿名でいることはできなくなります。
アクターを発見するということはシステムの境界を設定することも意味しており、システムの目的と範囲を理解するのに役立ちます。システムと直接コミュニケーションするものだけをアクターと考える必要があります。システムの周囲にあるもの以外のロールまで含めてしまっている場合は、システム自体ではなく、システムを使用するビジネスをモデル化しようとしています。
例:
航空機予約システムでは何がアクターでしょうか。答えは、旅行業者が使用する航空機予約システムを構築しているのか、それとも旅行者がインターネットを通じて直接接続できるシステムを構築しているのかによって違ってきます。

旅行業者が使用する航空機予約システムを構築する場合、アクターは旅行業者になります。旅行者はシステムと直接対話しないので、アクターではありません。

ユーザーがインターネット経由で直接接続できる予約システムを構築する場合は、旅行者はシステムと直接対話することになり、システムに対するアクターとなります。
アクターの説明には次の情報が含まれていなければなりません。
- アクターが表しているものまたは人。
- アクターが必要な理由。
- システムに対してアクターが持っている関心。
説明は、長くても数個の文にまとめる必要があります。
例:
リサイクル マシンのユース ケースモデルの場合、3 つのアクターを次のように説明できます。
顧客: 顧客は家でビンや缶や空箱を集め、店に持って行って払戻しを受けます。
オペレータ: オペレータはリサイクル マシンの保守を担当します。
管理者: 管理者は、お金に関する問題と、店が顧客に提供するサービスに関する責任を負います。
アクターの特性は、システムの開発方法、特に最善のユーザー インターフェイスを視覚的に構築する方法に影響を与えます。アクターに対応するビジネス ワーカーがビジネス オブジェクト モデルで既に記述されている場合、次のような特性の一部は既に把握されている可能性があります。アクターの特性には次のものがあります。
- アクターの責任範囲
- アクターがシステムを使用する物理的環境。理想的なケース (ユーザーは静かなオフィスにいて、何の邪魔も入らない) から外れる場合は、サウンド、フォントの選択、入力デバイス (キーボード、タッチ・スクリーン、マウス、ホット・キーなど) の適切な組み合わせなどが、影響を受ける可能性があります。
- アクターが表すユーザーの数。この数は、そのアクターの重要性、およびユーザー・インターフェースの中でそのアクターが使用する部分の重要性を決定する際に関係する要因です。
- アクターがシステムを使用する頻度。この頻度により、セッション間でアクターがユーザー・インターフェースをどの程度覚えているものと期待できるかが決まります。
ほとんどの場合、ユーザー数と使用頻度は大雑把に見積もるだけで十分です。ユーザー数が 30 人と 40 人ではユーザー インターフェイスの形状に影響はありませんが、3 人と 30 人では影響が出る可能性があります。
そのほかのアクターの特性には次のものがあります。
- 対象分野に関するアクターの知識のレベル。このレベルがわかれば、分野に固有のヘルプ情報がどの程度必要か、また分野固有の用語をユーザー・インターフェースでどの程度使用する必要があるかを決めるのに役立ちます。
- 一般的なコンピューター経験に関するアクターのレベル。このレベルがわかれば、ユーザー・インターフェースの対話方式として、高度なものと単純なもののどちらが適切かを決めるのに役立ちます。
- アクターが使用するほかのアプリケーション。このようなアプリケーションで使われているユーザー・インターフェース概念を流用すれば、アクターはそのような概念に既に慣れているので、学習時間を短縮でき、記憶への負担も減ります。
- 専門知識 (教育) のレベル、社会的なかかわり合い (言語)、年齢などの、アクターの一般的特性。これらの特性は、フォントや言語のようなユーザー・インターフェースの詳細に影響を与えます。
このような特性は、主に、バウンダリ クラスとそのプロトタイプを識別し、ユーザー コミュニティとユーザー インターフェイス設計の間で使いやすさに関して最善の一致が得られるようにするときに使用されます。
例:
次に示すのは、電子メール ユーザーのアクター特性の例です。このアクターは、いろいろある中でも、特に受信メール メッセージ管理のユース ケースと相互作用するものです。
|