第3部：ちょっと上級篇

Q3-1）
UMLには言語としての文法があるんですよね？
その文法はどんなふうに定義されているんですか？

羽生田栄一
株式会社豆蔵 取締役会長

2003/4/24

---

　少し昔にソフトウェア開発の世界に入った方々であれば、例えばFortranで書かれたLispの処理系、Basicで書かれたtinyCの処理系、Pascalで書かれたCの処理系といったものを目にされたことがあるでしょう。

　一番ポピュラーなのは、Pascalの生みの親のニコラス・ヴィルトの書いたPascalによるPascalの言語処理系書籍でしょうね。そこに記述されているのは、いわゆる循環的なメタ記述による言語定義（meta-circular definition of language）です。つまり、「循環的なメタ記述による言語定義」によって、同じ言語を活用しながら、その言語の基本思想や文法（シンタックス）、意味解釈（セマンティクス）を処理系として記述することができるわけです。実際、その方が英語や日本語といった解釈に曖昧（あいまい）性のある自然言語で記述するよりも、よほど厳密に定義できるわけです。
　
　不思議なのは、「まだ動いていない言語で自分自身を記述し、処理系を動かすことが果たしてできるのか？」というなぞですが、実際には、処理系の構成を、「コア部分」と「それを取り囲むいくつかのレイヤ」に階層化しておき、コア部分の実装は別の言語で置き換えて実現、それをブート・ストラップにして最終的にはその言語自身で全体の処理系が動くようにしていくわけです。そして実は、UMLの場合も、文法と意味の体系は、ほぼUML自身によって記述されています。

■UMLメタモデルの仕組み

　UMLの定義がUMLによってなされているという事実を、UMLはUMLメタモデルによって定義されている、といい換えることができます。「メタ〜」というのは「〜について」という意味ですから、UMLメタモデルとは、「UMLについてのUMLモデル」ということですね。

　UMLでどうやってUMLの言語要素を規定するのかちょっとした例でのぞいてみましょう。

図1 UMLメタモデルの仕組み

　図1は、UMLを構成する言語要素である「クラス」の概念を、クラス図によって特徴付けたものです。「GeneralizableElement（汎化可能な要素）」のサブクラスとして「Classifier（分類子）」を定義し、そのサブクラスとして普通の意味の「Class（クラス）」を定義しています。属性（インスタンス変数）や操作（メソッド）をクラスが持つべき可視性（visibility）付きの「Feature（特性）」ととらえ、分類子の保持するモデル要素として位置付けています。このようにUMLの文法要素とそれらの間の関係を表現したものをUMLの「抽象構文」と呼び、クラス図で表現しています。

　ただし単にクラス図で描いただけでは、そこに登場させたクラスや属性の間で成立すべき制約条件が不明確です。なので、正しいUML構文であるための条件を「適格性規則（Well-formed rule）」として、一種の論理式であるOCL（Object Constraint Language）で記述し、抽象構文に付随させます。
　
　たとえば、ここで挙げた例は、「そのクラスが抽象クラスではない（not self.isAbstract）、いい換えると具象クラスであるということは（implies）、つまりそのクラスが持つすべての操作は、メソッドとして実装されている必要がある」ということを表現しています。この論理式によって、GeneralizableElementの持つ属性として定義されているisAbstractが確かに「そのクラスが抽象クラスか否かを示す」という意味を担っていることを保証しているわけです。
　
　実は、これだけではどうしてもUMLのユーザーが直感的にクラスに対して抱いているイメージをすくい上げきれてはいないので、さらに「意味論記述」として自然言語を使い、「クラスClassはObjectの構造と振る舞いを完全に記述する」というように、補足的にその言語要素の意味を与えています。UMLの構文と意味をUMLでできるだけ与えようと努力しているわけですが、究極のところでは、私たちが日ごろ使う日常言語に定義を頼っているわけですね。

■メタモデルは4階層でオブジェクトを意味付ける

　メタモデルは、実は4つの異なる意味レベルの階層（レイヤ）から構成されます。下から「（1）ユーザーオブジェクト層」、「（2）モデル層」、「（3）メタモデル層」、「（4）メタメタモデル層」の4階層です（図2：以下、文中では「（1）ユーザーオブジェクト層」のように、分かりやすく番号をふって記述します）。

（4）メタメタモデル層

メタモデリングアーキテクチャのインフラを提供。メタモデルを記述するための言語の定義。UMLではMOFを利用 例：MetaClass、MetaAttribute、MetaOperation

（3）メタモデル層

メタメタモデルのインスタンス。モデルを記述するための言語の定義 例：Class、Attribute、Operation、Component

（2）モデル層

メタモデルのインスタンス。特定ドメインを表現する言語の定義 例：StockShare、askPrice、sellLimitOrder、StockQuoteServer

（1）ユーザーオブジェクト層

モデルのインスタンス。特定ドメインの具体的表現 例：<Acme_Software_Share_98789>、654.56、sell_limit_order、<Stock_Quote_Svr_32123>

図2 UMLメタモデルの4階層

　この階層構成の意味するところは、1つの層のモデル要素をその上の層のモデル要素が意味付けする、そしてそのモデル要素をさらに1つ上の階層のモデル要素が基礎付ける、という形で3段階まで意味階層を上っていくようになっています。そして、一番上のメタメタモデル層については、もう基礎付けられないので、それ自身で妥当性を内部的に理解してもらうことになります。

　たとえば、図3の例では、まず一番下の「（1）ユーザーオブジェクト層」に、1枚の具体的な乗車券を表すインスタンスオブジェクト「45723990550:PassengerTicket」があります。このオブジェクトを意味付けるのに、通常のオブジェクト・モデリング作業によって構築されるモデルを表す「（2）モデル層」内のモデル要素「PassengerTicket」が定義されます。ここに属性や操作、関連が定義されることによって、その下の層のオブジェクトの構造や振る舞いが規定されるわけです。ここまでは、皆さんよくご存じのクラス図による分析、設計モデリングそのものです。

図3 UML4層メタモデルの具体例（出典『UML2001：A Standardization Odyssey』 by Cris Kobryn）、クリックすると拡大

　そして、その次のステップでは、モデル要素「PassengerTicket」やモデル要素「fare:Currency」（料金に相当）、モデル要素「issue（）」（発券処理に相当）が正しく意図された構造や意味を反映していることを保証するために、「（3）モデル層」が導入されます。このレイヤでは、下の層で登場した要素がどのような意図のモノかをメタモデル要素のインスタンスとして規定してやる、というスタンスで、いわゆるモデルの上位概念として、「Class」「Attribute」「Operation」といったメタモデル要素を導入します。「（2）モデル層」内のPassengerやfare、issue（）といった要素はこれらメタモデル要素Class、Attribute、Operationの各インスタンスであると指定できるわけです。

　ここで終わってもよいのですが、一応これらのメタモデル要素が整合性のある一般的な定義になっていますよ、という保証を与えるために最上位の「（4）メタメタモデル層」というのが用意されています。ここは、先のメタモデル要素Class、Attribute、Operationといったものが、お互いに矛盾なく整合的に定義されていることを、「MOF（Meta Object Facility）」というメタモデル定義の標準的な枠組みを用いて保証しておく一種の保険のためのレイヤです。
　
　ここに「MetaClass」「MetaAtrribute」「MetaOperation」といった要素（メタメタモデル要素ということになります）が、MOFにのっとって導入され、それらのインスタンスとして、「（3）メタモデル層」の要素（こちらがClass、Attribute、Operationといったメタモデル要素）が基礎付けられます。MOFはOMGで制定されたもので、UML以外にもいろいろなメタモデル定義で利用されています。

■UMLメタモデルを“観光”する

　以上をメタモデルに関する一般知識として確保し、次にUMLの文法を規定しているメタモデル層を見ていきましょう。一番ラフな視点でメタモデルを見るとそこには「基盤（Foundation）」「振る舞い要素（BehavioralElements）」「モデル管理（ModelManagement）」という3つのパッケージが定義され、振る舞い要素、モデル管理のそれぞれが基盤パッケージに依存関係を持っていることが分かります（図4-a）。

図4-a UMLメタモデル層のラフな構造

　さらに、基盤パッケージは「データ型」「コア」「拡張機構」で構成されます。振る舞い要素パッケージは、「共通振る舞い」を「コラボレーション」「ユースケース」「状態マシン」が参照（依存）しており、さらに「アクティビティグラフ」が「状態マシン」に依存しています（図4-b）。

図4-b UMLメタモデル層の詳細構造

　そして、さらに「コア」は「バックボーン」と「関係」の2つのパッケージからなるのですが、例えば「コア／バックボーン」の中身を見ると、図5のようなクラス図によって表現されています。ここに、「ModelElement」「NameSpace」「Feature」「Classifier」「Operation」「Method」「Parameter」といったいわゆるオブジェクト指向で基本となる要素が、メタモデル要素として定義されているわけです。

図5 メタモデル「コア／バックボーン」を眺める（クリックすると拡大します）

　これらを使って、UML文法に対する4階層メタモデルアーキテクチャの「（3）メタモデル層」が仕様化されているわけですね。こうしたメタモデル要素を利用することで、あいまいになりがちな「（2）モデル層」における各クラスや属性、操作、関係、状態、遷移、メッセージ受信、といったもろもろの事象をより正確に特徴付けることが可能になるわけです。

　なお、今回は、UMLの抽象構文の定義でも補足的に利用されていたOCL（Object Constraint Language）についてはあえて解説しませんでしたが、今後、この連載の中で取り上げる予定です。

■UMLメタモデルに関する参考書

　以上、少々厄介な話が続きましたが、興味を持たれた皆さんはぜひ『UML仕様書』『UMLリファレンスマニュアル』の2冊を参照して、UML定義文書の解読に取り組んでみてください。自分で、UMLエディタを作ってみたくなるかもしれませんが、私は責任を持ちませんよ。

【参考】UML定義文書

UMLリファレンスマニュアル ジェームズ・ランボー、イヴァー・ヤコブソン、グラディ・ブーチ／著、日本ラショナルソフトウェア訳、石塚圭樹／監訳 ピアソン・エデュケーション 2002年1月 ISBN4-89471-267-9 6400円＋税

UML仕様書 Object Management Group／著 OMG Japan SIG翻訳委員会UML作業部会／訳 アスキー 2001年11月 ISBN4-7561-3962-0 7800円＋税

Development Style FAQ UML篇 INDEXへ戻る

IT Architect 連載記事一覧