UML2メタモデルを読む − 知識とは何か？（2）：オブジェクト指向の世界（24）（1/2 ページ）

知識というものには、「幅」と「深さ」がある。そして、UMLの仕様にもそれは如実に表れている。こうした点について、今回も前回に引き続きソクラテス式対話の形を借りて論じていく。

[河合昭男，（有）オブジェクトデザイン研究所]

　前回は「UML2メタモデルを読む」と題して、「知識」とは何かについて考えてみました。

　知識を表現するためには、「知識をどのように表現するのかという知識」が必要です。UMLを「知識を表現するツール」と見るなら、そのUMLを表現するための知識というものも必要です。UMLで作成するモデルに対して、UMLの仕様書は「メタモデル」と呼ばれます。UMLのモデルが知識なら、UML仕様書のメタモデルはメタ知識といえます。

　今回も前回に続き、UML 2.1.1（以下、UML2）の仕様書を題材にしてソクラテス式対話風に「知識とは何か？」について考えていきたいと思います。

参考文献（UML 2.1.1仕様書）

▼Unified Modeling Language: Infrastructure version 2.1.1 （PDF）

▼Unified Modeling Language: Superstructure version 2.1.1 （PDF）

語彙の「幅」と「深さ」

［登場人物］

• ソクラテス
• ソクラテスの弟子筋の某
• UMLの勉強を始めた開発者
• 司会

司会　前回からUMLの仕様書を読み始めたのですが、かなり難解です。

開発者　なぜこんなに複雑なんでしょう？

某　メタ知識というものが現実から離れ過ぎていて、直観的にイメージできない。

ソクラテス　さて、今回は「知識の幅と深さ」というものについて考えてみよう。例えば、英語の知識の基本は英単語をどれだけ知っているかです。例えば、“object”の意味は？

開発者　「もの」です。

ソクラテス　つまり、あなたは“object”という単語は取りあえず知っている。これが知識の第1ステップなら、次のステップはどの程度知っているかということです。

司会　「目的」という意味もあります。

某　辞書を引くと、そのほかにも「対象」という意味があります。ある単語を知っているといっても、1つの単語にいろいろな意味があるということですね。

ソクラテス　知識には、語彙（ごい）の数という広がりと、それぞれの言葉の意味という深さがある。

司会　UMLの仕様にも、広がりと深さがあります。要素、あるいはメタクラスを次々に定義して語彙を増やしていくという広がりと、個々の要素の意味付けを段階的に深めていくという2つの仕掛けを用いています。

開発者　仕様書には“Classifier”、“Class”、“Feature”、“Property”、“Operation”など、メタクラスが次から次へと出てきます。

司会　最初に“Element”という要素を定義し、それを汎化関係の最上位としています。それを次々に継承することにより、新たな要素を追加しているのです。UMLに定義されているすべてのメタクラスは、“Element”の子孫として定義されています。つまり、すべてのメタクラスは“Element”（「要素」）の一種です。子には、親の特性に加えてプラス・アルファの特性が追加され、汎化関係が下っていくほど少しずつ特性が追加されていきます。こうしてメタクラスを特化して新たなメタクラスを追加させていく仕掛けが、UML2仕様の第一の仕組みです。

某　つまり、語彙を増やしていくという意味で知識の幅を広めている。

司会　もう1つの仕組みが、パッケージの「マージ」です。これは、あるメタクラスを別のパッケージに取り込んで、その同じ名前のメタクラスに新たな特性を追加して意味を拡張していく方法です。

某　つまり、知識を深めている。

司会　前者は名前を変えて特化していき、後者は名前を変えずに詳細化していきます。ここで問題が出てきます。同じ名前のメタクラスに対して、異なるパッケージで異なる定義が可能になってしまうのです。マージは、この複数の同じ名前のメタクラスを別のパッケージに取り込んで、両者の特性を合成してあらためて1つのメタクラスにしてしまうこともできる仕掛けです。

開発者　同じ名前で異なる定義を与えるとは、一体どういうことでしょう？

パッケージのインポートとマージ

司会　同一パッケージ内で異なる要素の名前を同じにすることは当然できませんが、パッケージが異なれば同じ名前でも構いません。

開発者　ファイルとフォルダの関係に似ていますね。つまり、同一フォルダ内では異なるファイルに同じ名前を付けられませんが、フォルダが異なれば同じ名前のファイルがあっても構わないわけですね。

司会　「インポート」という仕掛けを使えば、別のパッケージにある要素を自分のパッケージに取り込むことができます。別のパッケージ内の要素を、パッケージ名を付けないで自分のパッケージ内の要素と同等に使用することができるのです。

　一方、マージは単に取り込むだけではなく、要素の意味を拡張するための仕掛けです。UMLの仕様書には「パッケージマージは2つのパッケージ間の方向を持つ関係で、2つのパッケージ内の要素は合成される。この関係は、ソースとなる要素はターゲットとなる要素の特性を追加して結果的に両者の特性を合成した1つの要素となるという意味で汎化に似ている。この仕掛けは、異なるパッケージで同じ概念を同じ名前の要素として定義するときに使用する。多くの場合、共通の1つの定義からスタートして、与えられた概念を異なる目的で異なる定義を与えるとき使用される。与えられた基礎となる概念は、別のマージされたパッケージで定義された拡張を用いて徐々に拡張される。マージすべき拡張を選択することにより、ある概念にカスタムな定義を与えることができる」（Infrastructure version 2.1.1 "11.9.3　PackageMerge"）とあります。

某　同じ名前の概念に対し、異なる目的から異なる拡張が加えられ、元は同根でも細部で異なるようになるということですね。これは、同じ言葉が専門領域が異なると違った意味で使われるのと似ていますね。これもマージですね。

開発者　専門領域どころか、厳密には人それぞれで同じ言葉を違う意味で使っていたりする。本当にコミュニケーションは難しい。

司会　そこで、誤解が生じないようにUML2の仕様書は厳密に記述された。その結果として、ある程度難解になってしまったのはやむを得ない。