Index: [Article Count Order] [Thread]

Date:  Mon, 14 Mar 2005 10:39:13 +0900
From:  "Takayuki Oguro" <oguro@....com>
Subject:  [modeling-dojo:00209] Re: UML記述を理解できるお勧め本ありま
To:  <modeling-dojo@....jp>
Message-Id:  <003a01c52836$e3e9c2e0$756e10ac@S7PC117>
References:  <EC986E83-8004-11D9-A4E7-000393A2E854@....jp> <20050310122537408.RKKE.8089.t-mta1.odn.ne.jp@....jp> <20050314033019.0F17.KITSUNE@....com>
X-Mail-Count: 00209

立見@メトロさん
たつたさん
皆川さん

小黒@制御系です。

なるほど、と思いました。
確かに、自分は、クラス図を描いているときには、
制約を書き表せていません。
必要があれば、ノートや別のドキュメントに
うだうだと書いています。
仕様書として、何か足りないと感じるのは、
これが大きな一つの要因なのでしょうね。
大きな「すっきり」が出始めています。
静的な図を理解しやすく描くのは難しかったんですね。

私は、仕事柄、ステートマシン図を好んで使います。
その次が、シーケンス図で、次がクラス図です。
必要に応じてアクティビティ図(これについては
正直よく分かっていない面が多いです)を使います。
ステートマシン図では、イベントの記述に、「ガード条件」
(near=制約?)があるために、クラス図の方では
あまり意識がはっきりとしていませんでした。
シーケンス図も、UML2.0からは、alt(オルタナティブ)や
opt(オプション)を使って、ケース分けの表現が出来ています。
でも、実際にクラスを作ってもらうときの仕様の書き方が、
いまいちに思っていましたが、とても参考になりました。

OCLは、読み手の教育の問題を伴いますので、
考えてからでないと動けませんが、よく考えてみたいです。

----- Original Message ----- 
From: "Makoto Minagawa" <kitsune@....com>
To: <modeling-dojo@....jp>
Sent: Monday, March 14, 2005 3:34 AM
Subject: [modeling-dojo:00207] Re: UML記述を理解できるお勧め本ありま


>  ども、皆川%本業の方でバタバタしていてとても亀レスです@豆蔵です。
>
> # 以下、例によってメールの引用部分を一部削らせていただいています。
>
> On Thu, 10 Mar 2005 20:55:32 +0900
> Tetsuya T <had20740@....jp> wrote:
>
> > クラス図は制約をいれないと、要件を”厳密”に表現できないことが多いんです
> > ね。私のようにUMLを半端な知識のまま使うと、”曖昧”なモデルに陥りやすい
> > んではないでしょうか?
> > 修行がだいぶ足りないことに気づきました。
>
>  何故かクラス図を描いていると「何となく」それなりに厳密っぽいモデルが描
> けているように思えてきたりしますが、良く考えてみると思わぬ落とし穴がいろ
> んなところに開いていたりするのに気が付くことがあります。制約をしっかり書
> き入れる人は*何故か*少ないのですよね (^_^; モデリングをするためには結構
> 必須な事だと思うのですが…。何故なんでしょうね (?_?)
>
>  既にご存知かと思いますが、UMLの仕様書セットの一部として OCL (Object
> Constraint Language : オブジェクト制約言語) という仕様が公開されています。
> UMLダイアグラム中の制約記述では、(自然言語や特定のプログラミング言語を用
> いて記述しても良いのですが)このOCLを使用することによって「ちょっとフォー
> マルな感じ」で、ある程度の範囲の制約を曖昧さを抑えて記述することができま
> す(もちろん、読み手もOCLを正しく解釈することができないとダメですが…)。
>
> > 例2:勤務していない会社の食堂も利用できない制約を表現している
> >
> >             勤務している      運営している
> > +------+          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
>     ■■■■
>
>