ども、皆川％本業の方でバタバタしていてとても亀レスです＠豆蔵です。
# 以下、例によってメールの引用部分を一部削らせていただいています。
On Thu, 10 Mar 2005 20:55:32 +0900
Tetsuya T <had20740@....jp> wrote:
> クラス図は制約をいれないと、要件を”厳密”に表現できないことが多いんです
> ね。私のようにUMLを半端な知識のまま使うと、”曖昧”なモデルに陥りやすい
> んではないでしょうか？
> 修行がだいぶ足りないことに気づきました。
何故かクラス図を描いていると「何となく」それなりに厳密っぽいモデルが描
けているように思えてきたりしますが、良く考えてみると思わぬ落とし穴がいろ
んなところに開いていたりするのに気が付くことがあります。制約をしっかり書
き入れる人は*何故か*少ないのですよね (^_^; モデリングをするためには結構
必須な事だと思うのですが…。何故なんでしょうね (?_?)
既にご存知かと思いますが、UMLの仕様書セットの一部として OCL (Object
Constraint Language : オブジェクト制約言語) という仕様が公開されています。
UMLダイアグラム中の制約記述では、(自然言語や特定のプログラミング言語を用
いて記述しても良いのですが)このOCLを使用することによって「ちょっとフォー
マルな感じ」で、ある程度の範囲の制約を曖昧さを抑えて記述することができま
す(もちろん、読み手もOCLを正しく解釈することができないとダメですが…)。
> 例２：勤務していない会社の食堂も利用できない制約を表現している
>
> 勤務している 運営している
> +------+ 1 +------+ 0..* +----------+
> |従業員| ----------- |会社 |--------- | 食堂 |
> +------+ 1..* +------+ 1 +----------+
> 1..* | 雇用している 運営されている | 1 利用する｛利用できる
> | |には自分の勤務している会社
> | |の食堂のみ}
> |------------------------------------------|
> 利用される
たとえば、立見さんの描かれた上図の{利用できるには自分の勤務している会
社の食堂のみ}という制約を、「従業員」クラスに掛かる制約としてOCLで記述し
てみると、だいたい次のような感じになります。
# 上のクラス図では関連のロールが「方向付けありの関連名」のような名前付け
# がされているので、下記のOCL式もちょっと「座りが悪い」感じがしますが…。
context 従業員 inv:
self.勤務している.運営している->includes(self.利用する)
OCLの入門的な記事がウチ(豆蔵)の羽生田と岡村とで@ITさんのサイトに掲載さ
れています。もし宜しかったらご参照くださいませ。
http://www.atmarkit.co.jp/farc/rensai/uml_b_l07/uml_b_l07.html
UML BASIC LECTURE（7）: オブジェクト制約言語（OCL）の基本
http://www.atmarkit.co.jp/farc/rensai/uml_b_l08/uml_b_l08.html
UML BASIC LECTURE（8）: オブジェクト制約言語について 応用編
以上、このメールが何かのお役に立ちましたら幸いです。
P.S.
ちなみに、UMLでは関連間の特別な制約として{subset}や{xor}なども定義され
ています。これらは利用すると便利な局面が結構あるので、知っておくとお徳か
もしれません。
--
／|／| ▲ 皆川 誠 ＠ 株式会社 豆蔵
/ ノ / } 「きつねはコンと鳴く」
|// ノ / | 会社用: kitsune@....com
=o=|＼| / 自宅用: kitsune-san@....com
く | / 携帯用: kitsunex@....jp
■■■■