Why OCL ?
話はかなり飛ぶが，訳あってMDA関係に取り組むこととなった．手始めに，MDAを理解する上で重要な概念であるOCLについて理解するため，OCL2.0仕様書の一部を和訳した．
Why OCL ?
なぜOCLが必要なのか？
A UML diagram, such as a class diagram, is typically not refined enough to provide all the relevant aspects of a specification. There is, among other things, a need to describe additional constraints about the objects in the model. Such constraints are often described in natural language. Practice has shown that this will always result in ambiguities. In order to write unambiguous constraints, so-called formal languages have been developed. The disadvantage of traditional
formal languages is that they are usable to persons with a strong mathematical background, but difficult for the average business or system modeler to use.UMLダイアグラム（例えばクラス図）は、一般的に言って、仕様を記述するために必要な全ての側面を、十分に定義できるほど洗練されてはいない。そのモデルの中のモデルについて、制約などの情報を追加記述する必要がある。そういった際の制約情報は、大抵は自然言語で記述される。これまでの事例からも分かるように、そういった記述方法では、いつもあいまいさが残ってしまう。明確に制約情報を記述するために、いわゆる形式言語が開発された。しかしそういった伝統的な形式言語は、数学的なバックグラウンドを強く持つ人々にとっては利用可能なものだが、通常のビジネスロジックの設計、システム設計を行う人々にとっては難解なものになっているという短所があった。
OCL has been developed to fill this gap. It is a formal language that remains easy to read and write. It has been developed as a business modeling language within the IBM Insurance division, and has its roots in the Syntropy method.
OCL（Object Constraint Language）は、こうしたギャップを埋めるために開発された。OCLは読み易さ、書き易さを備えた形式言語となっている。OCLはIBMの品質保証部で、ビジネスモデリング言語として開発された。起源はSyntropy手法である。
OCL is a pure specification language; therefore, an OCL expression is guaranteed to be without side effect. When an OCL expression is evaluated, it simply returns a value. It cannot change anything in the model. This means that the state of the system will never change because of the evaluation of an OCL expression, even though an OCL expression can be used to specify a state change (e.g., in a post-condition).
OCLは純粋な仕様記述言語である。従って、OCL言語で記述されたOCL式は副作用を一切もたらさないことが保証される。OCL式が評価されると、単純に値を返す。モデルに対しては何も変化は与えない。これは、OCL式がシステムのある状態の変化を定義していたとしても、OCL式を評価することによる、システムの状態の変化は一切起こらないということを意味している。
OCL is not a programming language; therefore, it is not possible to write program logic or flow control in OCL. You cannot invoke processes or activate non-query operations within OCL. Because OCL is a modeling language in the first place, OCl expressions are not by definition directly executable.
OCLはプログラム言語ではない。従って、プログラムのロジックや遷移制御の記述をOCLで行うことはできない。OCLを使って、ある処理を呼び出したり、ある処理を活性化させたりすることはできない。OCLは第一にモデリング言語であり、OCL式は実行可能ではないからである。
OCL is a typed language, so that each OCL expression has a type. To be well formed, an OCL expression must conform to the type conformance rules of the language. For example, you cannot compare an Integer with a String. Each Classifier defined within a UML model represents a distinct OCL type. In addition, OCL includes a set of supplementary predefined types. These are described in Chapter 11 (“The OCL Standard Library”).
OCLは型付け言語であり、OCL式はそれぞれ型を持つ。良く形成されるためには、OCL式はOCLの型規約に準拠しなければならない。例えば、Integer型とString型の比較は行えない。UMLモデルで定義されたそれぞれのクラシファイア（インタフェースやクラスをメタ化したもの）は、OCLのそれぞれの型をあらわしている。さらに、OCLは事前に定義された補助的な型のセットが含まれている。それらについては第11章（OCL標準ライブラリ）を参照のこと。
As a specification language, all implementation issues are out of scope and cannot be expressed in OCL.
仕様記述言語であるから、実装にかかわる問題は範囲外であり、OCLでは記述されない。
The evaluation of an OCL expression is instantaneous. This means that the states of objects in a model cannot change during evaluation.
OCL式の評価は一瞬で行われる。つまり、OCL式の評価の最中に、モデルの中にあるオブジェクトの状態は変化しない。
さすが仕様書．なんとなく分かった気にさせてくれる．
もう少し具体的な話は，ビジネスコミュニケーション誌のWEB記事を参照．
