＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
UML：関連クラスの誤解について
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-12-25 11:04
さっきも書きましたが、制約が有るかどうか？については、 (私は)「疑問」は持っていません。 何故なら、定義者が勝手に定義すればそれまでだから(^^;。 ＃そしてその定義が秀逸である保証は何処にもない… ところで私は、@IT記事の上記の部分について、別の疑問を持ちました。 というのは、記事の文章自体が論理的に変じゃないか？と思ったので。
(番号を添えたのは私) 元記事はこうなっていますが、私が思うに、1から2は導けないんじゃないでしょうか？ そして結果として、関連インスタンスは一意に定まらないのではないでしょうか？ 1によって言えるのは、対偶(っていうんでしたっけ？)を使うと、 「もし関連インスタンスが存在すれば、そこには両端オブジェクトが有る」 です。 そこでは、関連インスタンスの「個数」について何も言及してない、ですよね？ 関連インスタンスが1つであろうと2つであろうと3つであろうと、上記の話に反しない ように思えるんですが、どうでしょう？ 直感的に考えても変です。 2つの点の間に線が何本引けますか？っていう問題です。 そりゃ、ユークリッド空間だとか、直線しか使っちゃいけないとか、 重なっちゃった線は同一視しますよとか、 そういうルールが有るならば、「1本です」としか言えないんですが、 我らがオブジェクト空間(?)はユークリッド空間である義務もないし、 線は(オブジェクトであるならば)直線に喩えられるものである義務も無いし、 重なった線の識別性も、(先ほど別の文で書いたように)オブジェクト化すれば識別できますし。 というか、ほら。日常生活でも、 2つの点の間に2本以上の紐を渡すことって、幾らでも有りますよね？ 私んちのベランダでも、正にそんな物干し紐(?)が張られてます。 (補強のために二重化したんですけどね。) …と思いました。 どうでしょう？ | ||||||||||||||||||||
|
投稿日時: 2004-12-25 14:26
関連クラスの制約が自分の意図とあわないなら、普通のクラスを使えばいくらでも関連の線は引けます。 関連クラスのセマンティクスについて、人によって考えがまちまちだったので、UMLではunifyしたというだけです。
サブクラスはスーパークラスを特殊化したものですよ。 関連クラスは関連の特殊化したもののひとつなので、関連クラスは通常の関連に制約を与えるという表現で正しいです。 [ メッセージ編集済み 編集者: skulker 編集日時 2004-12-25 14:26 ] | ||||||||||||||||||||
|
投稿日時: 2004-12-25 17:34
それはそうなのですが、 モデリング言語統一という壮大な構想(^^;であるUMLの概念空間の中で、 「関連クラス」という名称を占めてしまった概念が、 使いにくい ってのは、かなり悲しむべきことなんじゃないでしょうか？ 普通のクラスを使うなんていう「不便」なことは、したくないじゃないですか(^^;。 その言語に搭載されてるソレは、関連であり、かつクラスであるのは確かです。 一方UMLに「関連クラス」というイカにもそれっぽいものが既にあるわけです。 じゃあそれを「素直」に使いたいのが人情じゃないですか。 ＃UMLって、図言語にすることで直感的に判りやすくする、のが主眼だったんじゃないんだろうか？ ＃ところが実際にはこんなふうに「定義の厳密さ」に振り回されることになるってのは ＃ちょっとした皮肉ではあります。 ＃まあ、「スケッチUML派」になればいいのですが、自分の好きにやるときはともかく、 ＃仕事でやるときには周囲の人との兼ね合いも有るんで… ちなみに具体的な話になりますが、 私は、関連クラス(関連オブジェクト)が最初から用意されているという、 ちょっと変わった言語(^^;を扱ってるんです。 ＃UMLなんかより随分長い歴史を持つんで、UMLのセマンティクスと無関係な代物です。 で、そいつ用のクラスを作る(設計する)ときに、 UMLで(UMLツールは普及してますからね)関連クラスを描きたいわけです。 ところが、その言語では幾らでもやれてる「多重化された関連クラス」が UMLでは描けないときたもんだ。 そんなわけで、まあ、困っているわけです。 クラス図(みたいなもの)を描くツールが無いということになるんで。 世の中に、UMLと競合するライバルが他にも幾つか有るっていうなら、 「使いにくいなら乗り換えるわい」で話は済むんですが。(^^;
うーん。私がさっき書いた件については、 「まちまち」になりにくいんじゃないか？と思ってるんですが…。
あ。なんか判ったような気がします。 仰りたいことは「関連クラスは通常の関連に制約を与えたものである」といったところでしょうか。 それなら了解です。 関連クラスは(上位クラスである)関連へ、「どんな」影響も、与える事は出来ませんよね？ ところが「関連クラスは(中略)を与える」だと、関連クラスが何かをされたことになっちゃうんで、 おかしなことになると思いますもんで…。 | ||||||||||||||||||||
|
投稿日時: 2004-12-26 12:17
objectです。
「関連クラス」に関して、 私が理解している内容で、私なりに少し補足します。 #間違っていれば、指摘して下さい。 「関連クラス」という概念には、 関連に「含まれる情報」を保持する #「広義」の関連クラス と 関連に「関する情報」を保持する #「狭義」の関連クラス #つまり、関連以外の情報を含んではいけない。 があると思います。 そして、 「UML」では 「狭義の関連クラス」 を「関連クラス」と呼んでいる という事だと思います。 ここで、問題なのは、 「関連クラス」という言葉に対して 殆どの人が 「広義」の意味に理解する という事実だと思います。 「関連クラス」が意識される状況を考えると、 関連を「クラス」として「認識・表現」する必要性が生じている という「状況自体が重要」である と私は思います。 #つまり、「関連」自体が独立したものとして意識されているという事。 従って、本来は 広義の「関連クラス」=「関連クラス」 狭義の「関連クラス」=「純関連クラス」 等の命名が良かったんでしょうね。 #広義の「関連クラス」に「明確な名前」を付与する事は重要だと私は思っています。 それから、
私は、「guionさん」が仰ってる事を表現する為に、「UML」の「関連クラス」は存在すると思います。 ただ、現在の「UML」では、最初に説明した様に、 「関連」以外の属性等を含めると、それは「関連クラス」とは呼ばない というだけの話だと思います。 #名称としては否定されますが、存在が否定される訳では無いのでは？ | ||||||||||||||||||||
|
投稿日時: 2004-12-27 02:07
あ。面白い解釈だと思います。 が、そうだとすると、今度は、 「1本の関連線(リンク)」に対して「複数の(関連を説明する)オブジェクト」を ぶらさげたいなぁ、という欲求が(少なくとも私には)沸いてくるんですが、 UMLだとそれも出来ない…ですよね？(^^; ＃T字型のリンクが作れて、しかも1つの線分に複数の枝がぶらさがれる、みたいな感じの形。
人にとってそれが自然なのだと思います。 この自然に逆らうことを正当化できる理由は、特に存在しない、と 私は予想しています。 「直感に反するけど実は論理的に云々」なんてのも、この件については、無いんじゃないかと。
大筋では同意しますが、細かい所を考えると ソレでもまだダメだろうと読んでいます。 というのは、ほんとに「1ペアのノードの間には線が1つしか引けない」というルールにしてしまうと、 「互いにクラスが違う関連」すら1ペアの間には共存できないことになり、 そのせいで不幸なことに、「純関連クラス」を幾つ作ろうとも、やっぱり線は1つしか引けない ということが起きてしまう。 例えば、「学校では担任と生徒、家では親と子」という関係の二人を、 (純)関連クラスでは、表現できないってことになるわけです。 となると、妙なことになります。 というのは、純関連クラスは、クラスであるくせに、関連を説明できないんです。 関連のリンク自体は、どんなクラスにも染めることが許されなくなっちゃう。 リンクはあくまで無修飾のリンクで有り続けなければならない。 つまり、純関連クラス(クラス自体も、そのインスタンスも)は、現実には出番が一度も無いんです。 これではその概念が存在する意義が無い。 というか、元のままの「無名のリンク」が存在すればそれで充分なんです。
同意します。 で、かつ、名前を与えるのと同じくらいに、UML上での絵のカタチも、与えて欲しいです。 その概念に対してUMLが語彙(UMLでの語彙とは、絵柄のことだと思います)を与えないってのは、 ちょっと不味いんじゃないかと。 ＃で、純関連クラスのほうは、上記のように出番が皆無なので、誰も使わない(^^;
語彙(絵柄など)が無いため、他の概念(普通のクラスを使うとか)で 代用して表現せざるを得ない状況です。 実装言語なら小手先の「代用」で逃げるのも有りでしょうけど、 モデル言語で、そりゃないだろ？と思っています。 HowじゃなくWhatを記述する言語は、 「充分な」語彙※を持っていないと不味い、と思います。 そういう言語においては、存在させられてない概念は、使えないんです。 消極的に否定されているようなもの、だと思います。 [※]あるいは語彙をユーザが自作する能力か、の何れかが必要だと思います。 つまり、概念と絵をユーザがバリバリ追加定義できて、 しかも一般的に実用的なUMLツール(^^;がその追加を受け入れられるように なっているならば、私に不満はありません。 --- ＃ところでこのサイトで、自分がこれまで書いたものを探そうと思ったら、 ＃どうすればよろしいんでしょうか？(^^; ＃まだ数個しか書いてないんですが、既に見つけられなくなってる私。 | ||||||||||||||||||||
|
投稿日時: 2004-12-27 09:46
＃自分以外の書いたものもマッチするけど。 | ||||||||||||||||||||
|
投稿日時: 2004-12-27 09:57
遅ばせながら参戦です。
私も記事の内容は不可解でした。その不可解な点はguionさんが問題提示された、
これであり、関連クラスの存在が問題ではなく[2]の意見が問題だと考えます。 記事ではその後、正しい例として「販売」-「明細」-「商品」を上げられていますが、 「返品」は如何様に扱われるのでしょうか？この問に対して想定出来る回答として 「この関係図に置いて、返品は取扱い対象外」という返答になります。 そうすると「関連クラスを用いる場合、関連クラスが存在可能な様に関連図が 表現しようとするモデル対象範囲に制限を課す」という条件が付きますが、 この条件は、モデル対象範囲の適切性を判断する手段として利用出来ますが、 絶対的制約まで推し進めるのは、図式表現技法としてのＵＭＬの使い勝手を 悪くする事になります。 意見自体が想定ばかりで話を進めている事に問題はありますが、 今の所、上記の考えからguionさんが問題提示されている[2]が、私の争点です。
一つ一つの投稿文書の下段枠に「プロファイル」というアイコンがありますよね。 その先に[このメンバーからの投稿を表示]というのがあります。そいつです。 ただ、そこで表示される一覧のリンクはスレッドの先頭ですので、 投稿文書自体を見る場合、一覧で表示されている日時を覚えて置く必要があります。 _________________ 人生変わっちゃうかもよ?OFF会参加者募集中今考えるな、参加してから考えろ。 | ||||||||||||||||||||
|
投稿日時: 2004-12-27 10:46
スケッチレベルならステレオタイプ(Fowlerの<<history>>とか)で充分でしょうし、バリバリ拡張したいならMOFを使えばよいのでは。 | ||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.