モデリングからみたオントロジ

オントロジとモデリング

通常、モデルと言うと、主に2つの事柄を指します。1つは、現実世界の事物をコンピュータ上で計算／シミュレーションするために実現した具体的なシステムそのものです。もう1つは、オブジェクト指向におけるUMLのクラス図による概念モデルのように、対象の構造や仕組みを一般化して表したものです。

オントロジは後者です。オントロジは、クラス図で書く概念モデルに、非常に似ています。

概念モデルは、「情報システムの論理的な構造を示した"分析モデル"の理解を補助するために、その情報システムが利用される対象世界＝問題領域＝業務領域を、どんな観点で、どのような仕組みのものととらえたか、を表す」モデルという位置付けで使います。対象領域を説明するため、実装するうえでは直接必要がないクラスも導入します。

なぜわざわざ実装の遠回りをしてまで概念モデルを用意する必要があるのでしょうか。それは、実装に必要なクラスだけでは、その振る舞いの意味を正しく定義できないからです。また、問題領域と対応付けて、そこに存在する実世界や業務に登場するクラスとの関係を示さない限り、対象のクラスがどのようなものであるかを上手に表せない場合が多いからです。概念モデルを考えることによって、それまで気付かなかった意味的な制約が見つかることもあります。

UMLの概念モデルと比べて、オントロジでは、「概念の意味としての存在」をより深く考察でき、宣言的／形式的に定義することに注力できます。このことは、モデリングの初心者がクラスとインスタンスを混同する間違いや、継承関係の適用に関する間違いなどに効果的です。

例えば、システム設計時、クラス図をレビューする場面で、「過剰な継承はするな」とか、「その継承関係は間違っている」などと指摘されたことはないでしょうか。オントロジのアプローチを少し理解しておくと、このような失敗が少なくなります。

図2-1、図2-2は、オントロジの説明でよく用いられる誤りの例です。「is-a」という関係は、UMLの継承関係を示しています。ここで、教師のインスタンスとしてAさんがいた場合に、Aさんが教師を辞めたとします。継承関係では、スーパークラスの特性を引き継ぐため、教師を辞めることは人間を辞めることになります。現実には、職業を辞めても、その人の存在は消えません。つまり、教師クラスを人間クラスのサブクラスとして継承で定義するのは、明らかに間違いです。

図2-2は同様に、リンゴを果物クラスと商品クラスの両方のサブクラスとして多重継承で適用してしまった例です。リンゴという存在は「生物学的にいつでも果物性植物である」と言えます。一方、「リンゴであること」は「商品であること」と本質的につながっているでしょうか。リンゴは、ある条件を満たして流通プロセスの中で取り扱われている状態の場合に限って、商品と「見なす」ことができます。つまり、リンゴを商品のサブクラスとして継承にするべきではありません。

クラス図では、そのモデルに必要な属性やメソッドのみが書かれています。このため、安易に継承関係を作ってしまいがちです。こうして、間違いが起こります。

図2-1: UMLの継承関係において、よく犯しがちな誤り

図2-2: リンゴを商品のサブクラスとして継承するのは誤り

モデリングでの活用

オントロジの主要な構成要素は2つです。「概念」と、概念同士の関係を表す「意味リンク」です。UMLにおけるクラス図とクラス同士の関係に似ていますが、UMLのクラス図とは異なり、メソッドに相当するものは存在しません。

基本概念のほか、ロール（役割）や動詞、関係なども概念として定義されます。このため、UMLのクラス図では単純にロール名や関連名として片付けてしまうところを、オントロジでは、より深く考察することになります。

図2-3に示したクラス図は、エンジン付きボートのモデルです。一方、図2-4は、図2-3のモデルをヒントに、手漕（こ）ぎボートをモデル化したものです。

図2-3と図2-4を比べると、動力源がエンジンから人間に置き換わっています。ここで、おかしな点に気付きます。人間クラスが動力源という役割を持つ点は構わないのですが、多重度が「1」になっており、動力源の人間がボートに対していつでも必ず存在することになってしまいます。動力源というロールの表現がうまくできていないことが原因ですが、直接登場するクラスだけを使って表すと、このあたりの意味が区別できません。

これらのモデルを、オントロジを使って表現したものが、図2-5です。

クラス図と比べ、スーパークラスであるボートにおいて、「動力源 - もの」のように、動力源というロール概念^*1と、それに割り付け可能なクラス（もの）を表しています（クラス制約）。さらに、サブクラスである手漕ぎボートとエンジン付きボートにおいて、動力源ロールを特殊化し、サブクラスでクラス制約を変更して表すことにより、動力源というロールの表現がうまくできています。クラス図では、動力源ロールのクラス制約がものから人間に変化したために違和感があった、ということが分かります。