エンタープライズモデリングへの誘い（いざない）
第5回 エンティティの中核 バリュー

　エンティティとバリュー間の関連は、エンティティがバリューを記録していることを意味しています。つまりエンティティにバリューを関連付けるということで、バリューを半永続的に管理でき、そのバリューの情報が何（エンティティ）に関する情報か識別できるわけです。図1のようにエンティティは複数種類のバリューを記録することができます（システム開発者は進捗とスキルを持っている）。また、図2のようにバリューは複数種類のエンティティによって記録されることもあります（システム開発者も営業もスキルを持っている）。

　エンティティロールとバリュー間の関連は、エンティティロールがその情報や振る舞いの具体的な内容をバリューで定義することを意味しています。図3のようにエンティティロールは複数種類のバリューで、自身の情報や振る舞いを定義することができます(プロジェクトメンバは進捗とスキルに関する情報、振る舞いを持っている)。図4のようにバリューは複数種類のエンティティロールの情報や振る舞いを定義するために使われることがあります（プロジェクトメンバも評価対象も成果に関する情報、振る舞いをもっている）。

　エンティティロールとエンティティ間の関連は、前述のようにエンティティの情報を組織ロール単位に分離した概念で、言い換えるとエンティティロールは組織ロール上でのエンティティの情報、振る舞いを意味しています。ただし、この情報、振る舞いの具体的な内容はバリューで定義しています。図5のようにエンティティは複数種類の組織ロール上では異なるエンティティロールを持ちます（システム開発者はプロジェクトマネジメント組織ロール上ではプロジェクトメンバとして振る舞い、人事評価組織ロール上では評価対象として振る舞う）。図6のように複数種類のエンティティが同じ組織ロール上で同じエンティティロールを持つこともあります（システム開発者もコード自動生成ツールもプロジェクトマネジメント組織ロール上ではプロジェクトメンバとして振る舞う？）。

　それでは、プロジェクトメンバがどのような意図をもって定義された概念なのか考えてみましょう。プロジェクトメンバはプロジェクトマネジメント組織ロール上に登場するエンティティロールです。システムを開発するスキルを持っています。与えられた作業に関する進捗を記録できます。進捗に対する成果も記録できます。プロジェクトメンバとして振る舞うことのできるエンティティとしてシステム開発者がいます。

　システム開発者もプロジェクトメンバがもつバリューと同様のバリューを持っています。システム開発者はシステムを開発するスキルを持ち、作業の進捗、作業の成果を記録できます。またシステム開発者には人月単位の単価も設定されています。

　ここまでいくとプロジェクトメンバとシステム開発者がほとんど同じバリューを持っていることが見て取れます。実はこのモデルは以下の式に従うように記述されたモデルなのです。

　エンティティがエンティティロールとして振る舞うには、そのエンティティロールに関連付けられているバリューをエンティティも持っていなければならないのです。この関係はクラスとインタフェースと操作の関係と似ています。クラスがインタフェースを実現(implement)するためにはインタフェースで定義されている操作をクラスで実装しなければなりません。

　ということで、システム開発者が持つバリューとプロジェクトメンバの持つバリューがほぼ一致しているのは偶然ではなく、そうしないとシステム開発者はプロジェクトメンバになれなかったということが分かったかと思います。

　システム開発者と同様にコード自動生成ツールもプロジェクトメンバの持つバリューを持っています。コード自動生成ツールはある決まった仕様に基づいたコードのみ自動生成することができます。これは限定的にコーディングスキルを持っているといえます。コード自動生成ツールの自動生成の進捗も記録することができます。コード自動生成ツールの自動生成の成果も記録することができます。このため、コード自動生成ツールはプロジェクトメンバとして振る舞っている、コード自動生成ツールエンティティのエンティティロールとしてプロジェクトメンバエンティティロールがあるという例を出したわけです。

　システム開発者とコード自動生成ツールの2つのエンティティがプロジェクトメンバとして振る舞うという事実はプロジェクトマネジメントの観点から非常に有用です。プロジェクト中のタスクの内容によってこの2つのエンティティのどちらにタスクを遂行させるかを臨機応変に変えることができるからです。

　この有用性は当然エンティティロールとエンティティの関係にも当てはまります。あるエンティティロールとして振る舞うエンティティはいくらあってもよいわけで、それぞれのエンティティで特徴が違う場合には状況に適したエンティティを選択し、適用できるわけです。もし既に定義したエンティティのパフォーマンスが優れない場合には、新しいエンティティを発見し、定義し、エンティティロールに適用することも許されます。エンティティはコンポーネントのように取り替え可能(pluggable)なのです。

　ここまではエンティティの静的構造についての説明でした。今度はエンティティの動的側面について着目します。

　エンティティはプロセス中のプロセスステップを実行するために使用されます。実際にはプロセスステップはエンティティを直接使用するのではなく、エンティティロールを使用します。プロセスステップは必要であればエンティティロールに対して、エンティティの持つバリューを取得するように問い合わせることもできます。またエンティティロールに対して、エンティティにバリューを追加、更新、削除するように問い合わせることもできます。

　エンティティはプロセス、プロセスステップで使用されていく過程で様々なバリューが追加、更新、削除されていきます。エンティティにバリューが記録されていく流れをシステム開発者エンティティを例にとって説明します。

　まず、人事評価組織ロールの採用プロセスステップでシステム開発者エンティティは生成されます。エンティティの生成は評価対象エンティティロールを介して行われます。採用プロセスステップで獲得した氏名、スキルなどのバリューや、決定した給料のバリューは評価対象エンティティロールを介して追加します。

　プロジェクトマネジメント組織ロールのアサインプロセスステップでプロジェクトメンバエンティティロールを介してシステム開発者エンティティを使用します。アサインプロセスステップでは、プロジェクトメンバエンティティロールを介して、システム開発者エンティティのスキル（バリュー）を取得します。取得したスキルからアサインするタスクを決定し、タスクの進捗（バリュー）をプロジェクトメンバエンティティロールを介してシステム開発者エンティティに追加します。

　開発組織ロールの設計プロセスステップで設計者エンティティロールを介してシステム開発者エンティティを使用します。設計プロセスステップでは、設計者エンティティロールを介して進捗（バリュー）を更新、成果（バリュー）を追加、更新します。

　このようにエンティティは様々なプロセスステップで使用される過程で、そのプロセスステップに応じたエンティティロールのバリューが追加されていきます。エンティティはエンティティロールによって進化していくわけです。