オブジェクトロールモデル(ORM)図の概要
by Scott
W. Ambler, Copyright 2003
ORM (object role model) 図については、www.orm.netの『Information Modeling and Relational Databases』(Halpin 2001)において非常に詳しく記述されていますが、私が思うにこの図は、利害関係者と一緒に問題領域の概念を調査する方法として非常に有効です。ORM図には、オブジェクト(エンティティ型)と、オブジェクト間の関係、その関係においてオブジェクトが果たすロール、問題領域における制約事項、そして必要に応じて例(ファクト型テーブルと呼ばれます)を記述します。
図1は簡単なORM図の例です。楕円はエンティティ型を(Halpinはオブジェクトという用語を使っていますが、ORM図を使ってオブジェクト技術をまったく使用しないシステムをモデリングすることも可能です)、長方形は関係においてオブジェクトが果たすロール（役割）を表します。ロールは両方向に記述されます。上の関係では、「学生」は「受講する」というロール、「ゼミ」は「受講される」というロールになります。ロールの上の両方向の矢印は、一意である（同じ組み合わせは一つしかない）という制約を表します。「受講する」と「受講される」の両方にまたがって矢印があるということは、この関係では学生とゼミの組合せが一意になることを表します。学生は多くのゼミを受講することができますし、ゼミは多くの学生に受講されます。しかし、学生はある1つのゼミをたった一度しか受講することができません。もう1つの関係について見てみましょう。この場合、両方向の矢印は「手伝われる」の上にしかありません。つまり、１つのゼミはファクト型テーブル内に1度しか現れないということです(言い換えると、1対多の関係ということです)。見れば分かるように、ファクト型テーブルにはゼミは一度ずつしか現れませんが、Sally Jonesは2度登場します。一意であるという制約は「手伝う」のロールには付いていないため、これが可能になっているのです。両方向の矢印がそれぞれのロールの上に付いている場合は、1対1の関係をモデリングしたことになります。どちらのロールのオブジェクトも、それぞれ1回しか現れることがないからです。ロールの上に何も矢印が付いていない場合は、制限のない多対多の関係になります(たとえば、ある学生が同じゼミを何度も受講できます)。
図1では、各オブジェクトの楕円の中に1つの属性(「学生」の名前と「ゼミ」の番号)が書かれていて、ファクト型テーブルのロールの下に書かれた情報が何であるかを表しています。この形式のORM図はよく知識ベース図と呼ばれますが、私は簡潔さを大切にしたいのでORM図の形式を区別することはしていません。知識ベースを使ってエンティティ型があるロールにあるときの関係の例を示すことで、利害関係者と一緒に簡単かつ明示的に関係を調べることができます。関係が明確でない場合、特に関係の多重度を調べている場合には、私はよく知識ベースを記述します。
図1 簡単なORM図
★==
Student: 学生
(name): (名前)
takes: 受講する
is taken by: 受講される
Seminar: ゼミ
(number): (番号)
assists: 手伝う
assisted by: 手伝われる
==★
図2はもっと複雑な例です。ファクト型テーブルが含まれていないため、広い範囲の概念を調査することができます。ホワイトボードに書ける図の大きさは限られていますし、AMではいずれにしても「少しずつモデリングしよう」と勧めています。「学生」と「ゼミ」の関係は少し肉付けされています。上の関係は、2項の関係から3項の関係になって、参加するエンティティ型が3つになっています(「点数」が追加されました)。ORM図でn項の関係をモデリングするのは簡単で、関係にロールを追加すればよいだけですが、それが必要なことはめったにないと思います。「受講する」ロールと「補助する」ロールの間には、黒丸と×の組合せを丸で囲んで表される排他的OR(XOR)の関係があり、学生はゼミを受講したり手伝うことはできても、両方はできないことを示しています。×のない黒丸を丸で囲んだ印は、単純なORの関係を表します。
図2 少し複雑なORM図
★==
Student: 学生
(name): (名前)
Mark: 点数
takes: 受講する
Record: 成績
is taken by: 受講される
Seminar: ゼミ
assists: 手伝う
assisted by: 手伝われる
has: 持っている
identifies: 識別する
Semiar Number: ゼミ番号
taught by: 教えられる
teaches: 教える
Professor: 教授
Mentors: 指導する
Junior to: 指導される
==★
「教授」と「教える」ロールの間の線には、大きな黒丸が付いていて、教授が必ずゼミを教えなければならないことを表しています。この黒丸は線のどちらの端に付けてもかまいませんが、私はオブジェクト側に付ける方が好みです(時にオブジェクトが数多くの必須の関係に参加していてオブジェクトのシンボルが見苦しくなる場合には、黒丸を線の反対の端に表記するオプションを使うとよいでしょう)。
破線の楕円はオブジェクトの属性を表すもので、「ゼミはゼミ番号を持っている」という概念を図1の簡単な記法よりも詳細に表現することができます。私は「モデルはシンプルに書こう」のプラクティスに従って通常は簡単な記法を使うのですが、ここでは例として複雑な記法の例を挙げてみました。
もう1つ興味深いのは「教授」についての再帰/自己関係の概念です。1人の教授は複数の他の教授を指導でき、1人の教授は自分を指導する複数の教授の弟子になることができます。★この段落の記述と図２のmentors,junior toの上の２つの矢印が食い違っているようです。★
ORM図を使っているときにアジャイルさを保つにはどうすればよいでしょうか。私は、利害関係者と一緒にORM図を使って、ホワイトボードでモデリングし、問題領域を調査します。表記法は多少複雑ですが、利害関係者はすぐに基本的な事柄を理解してくれますし、最初のうちにファクト型テーブルを多めに使うようにすれば、さらに理解は早くなります。ORM図を使って調査対象の問題を理解できれば、私は通常、その情報をUMLクラス図やソースコードなどの他の成果物で表現し、用が終わったORM図は消してしまいます。
注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。
 |
ORMに関してはこの本を読んでください。概念モデリングのスキルを磨きたい人にはこの本を強く推奨します。 |
|
www.orm.net |
このサイトには、ホワイトペーパーや書籍、ORMをサポートするツールへのリンクがあります。 |
アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。 
Ronin
International, Inc. continues to help numerous
organizations to learn about and hopefully adopt agile
techniques and philosophies. We offer both
consulting and
training offerings. In addition we
host several sites - Agile
Modeling, Agile
Database Techniques, UML
Modeling Style Guidelines, Enterprise
Unified Process (EUP) - that you may find of value. You
might find several of my books to be of interest,
including
The Object Primer, Agile
Modeling, The
Elements of UML Style, and Agile
Database Techniques. For more information please
contact Michael Vizdos at 866-AT-RONIN (U.S. number) or via e-mail (michael.vizdos@ronin-intl.com).
visits since June 8, 2004.
|
