UML/MDAのためのオブジェクト制約言語OCL 第2版

　単に手軽なコミュニケーションツールとして使用している分には、UMLは、それだけで非常に便利なものですね。

でも、きちんとした設計書としてUMLを使いはじめると、図だけでは表現しきれないものが、たくさんあることに気がつくはずです。
だからって、古くさい設計書に立ち戻って、UMLをただの補足説明の図にだけ使用するなんてことは、したくありません。
そういうジレンマに陥ったとき、私はオブジェクト制約言語―OCL(Object Constraint Language)に出会いました。
UML2.0のリリースで、OCLの重要性は、さらに高まりました。
にもかかわらず、OCLの本は非常に少ないです。
というか、私はこれしか知りません。
　契約による設計(Design by Contract)という言葉を知っていますか？
近頃注目されている手法ですので、よく聞かれますね。
大雑把に言うと、

表明契約

実行時に常に真となるべき条件

事前契約、事後契約

関数の開始、終了時で満たすべき条件

不変契約

オブジェクトが常に満たすべき条件

によって、プログラムの仕様(利用条件)を定め、これを実際にプログラムコードに実装するという手法です。
表明契約については、すでにアサーションとしてサポートしている言語も、いくつかあります。
他の契約は、例外処理やAOP(Aspect Oriented Programming)によって実装するのが、一般的なのではないでしょうか。
これらの契約は、設計上の重要な決断を含んでいます。
ですので、設計書にはこれらを含めるべきです。
では、UML上にこれをどうやって表現すべきでしょう？
UMLは、直感的でわかりやすい図による、すぐれた表記法です。
しかし、そうであるがゆえに、単純な表現の仕方しかできません。
表現できる情報に限りがあるのです。
例えば、あるオブジェクトが他のオブジェクトを包含している場合を考えて下さい。
UMLでは、包含しているという事実を、わかりやすく表現することができます。
しかし、もし包含するための条件があったとしたら、どうでしょう？
あるいは、条件によって多重度が変わるとしたら？
「どういう場合に、どう包含するのか」ということは、どうやって表現したらいいのでしょう？
そのための記述方法が、OCLなのです。
OCLを導入することで、飛躍的にUMLの表現力が増すのです。
ところで、MDA(Model Driven Architecture)という言葉をご存知ですか？
PIM(Platform Independent Model)と呼ばれる、プラットフォーム独立モデルで設計を行い、これをPSM(Platform Specific Model)と呼ばれるプラットフォーム固有モデルに自動変換、さらに、そこからソースコードにまで自動変換するというソフトウェア開発手法です。
PIMは、OSだとかフレームワークだとかプログラム言語だとか、そういう環境と関係をもたないモデルです。
環境に依存しない、純粋な設計なわけです。
これが、そういったプラットフォームに依存するモデルに変換されると、PSMになります。
こうしておくと、ソフトウェアの環境を変更する場合には、PSMは作り直すことになりますが、PIMには影響しません。
だから、肝心な設計はそのまま再利用できるわけです。
しかも、PSMは自動変換なんですから、すぐにできます。
さらに、ソースコードも自動変換しなおすだけでOK。
なんともすごい技術ですね。
でも、これはあくまで将来像です。
今は、これを目指して偉い人たちががんばってるわけです。
じゃあ、今これを知ってても、意味ないじゃんって思いました？
そんなことはありません。
一部については、既に対応するツールも出てきています。
PIMからPSMへの変換ができるUMLライティングツールもあります。
また、UMLモデルからデータベースのDDL(Data Definition Language)を生成するツールをよく見ると思いますが、これはソースコードへの自動変換の例です。
MDAが完全にできあがり、誰もが利用できるようになるのは先のハナシですが、このように、部分的には既に実用化されているんです。
そして、MDA実用化の中核をなす技術こそが、OCLです。
MDAでは、PIMからPSMを、そしてPSMからソースコードを自動生成するわけですから、モデルに曖昧さが含まれていることは、許されません。
そのため、OCLによって定義を厳密にする必要があるのです。
いかがですか？
UMLの、設計書としての表現力を増す力。
そして、MDAテクノロジーの立役者としての力。
OCLのパワーを、感じていただけましたでしょうか？
ところで、「じゃあ、MDAってやつが完全にできあがっちゃったら、プログラマはお払い箱かよ」なんてことをよく聞きます。
でも、それはありえません。
だって、ソフトウェア開発を理解していない人が、適切なUMLを書けると思いますか？
結局、PIMを作るのはソフトウェア開発者です。
それに、自動生成されたソースコードが、常に最適なパフォーマンスを発揮するようになるまでには、さらに長い時間が必要でしょう。
これまでに登場したどのコンパイラも、使用されはじめてから高パフォーマンスを発揮するようになるまでには時間がかかったのと同じです。
それまでは、チューニングするのは開発者の仕事です。
遠い将来には、ひょっとしたら、プログラマという仕事は、そういうコンパイラを作る人みたいな、ごく一部しか残らないかもしれませんね。
他のソフトウェア開発者は、みんなPIMを作ることしか、しなくなるかもしれません。(もっとも、要求分析とかテストとか、その辺の仕事は依然として残りますけどね)
でも、それはあくまで遠い将来だと思いますよ。
先のことは、わかりませんけど。