UML：関連クラスの誤解について

投稿者

投稿内容

object: ぬし; 会議室デビュー日: 2002/03/20; 投稿数: 338; お住まい・勤務地: 香川県高松市

投稿日時: 2004-12-27 12:48

objectです。

>guionさん
>「1本の関連線(リンク)」に対して「複数の(関連を説明する)オブジェクト」を
>ぶらさげたいなぁ、という欲求が(少なくとも私には)沸いてくるんですが、
>UMLだとそれも出来ない…ですよね？(^^;
「狭義の関連クラス」が採用されているという事実でも分かりますが、
「UML」には、考え方自体が少し形式的(表面的)である気が私はします。
そういう意味で、
「UML」は「関連・関連クラス」を「そこまで有効に実現しよう」とはしていないと感じられますね。

////////////////////////////////
次に、元記事の
---------------------
「関連クラスのインスタンスは両端のオブジェクトなしには存在できないオブジェクトであると、先ほどいいました。これはいい換えると、関連クラスのインスタンスは両端の参加クラスのインスタンスが特定されれば一意に定まる、ということを意味します。」
---------------------
に関しては、

確かに、「guionさん」が指摘している様に
「関連クラスのインスタンスは両端のオブジェクトなしには存在できないオブジェクトである」…[1]
#番号の表現は「guionさん」に合わせました。
から直接的に断定出来るのは、[1]を
「両端のオブジェクトが存在しない」→「関連クラスのインスタンスが存在しない」
と理解した場合、その対偶である
「関連クラスのインスタンスが存在する」→「両端のオブジェクトが存在する」
程度だと私も思います。

概念的に言っても、
「存在性」と「一意性」とは全く異なる概念だと思います。
従って、「直接的に導出出来るかの様な発言は二重の意味で誤っている」と私は思います。

[1]は、「狭義の関連クラス(私が前のレスで説明した)」と同じ意味の内容であると、私は理解しました。
#参照記事の本来の主旨は、[2]では無く[1]だと私は思います。
#それで、私は前のレスをした訳ですが。
#[2]は、分かり易く説明しようとしてして記述された、著者の独自の見解なんでしょうね。

>で、かつ、名前を与えるのと同じくらいに、UML上での絵のカタチも、与えて欲しいです。
>その概念に対してUMLが語彙(UMLでの語彙とは、絵柄のことだと思います)を与えないってのは、
>ちょっと不味いんじゃないかと。
これは、私の表現が少し漠然とし過ぎました。
済みません。
私は
「明確な名前」を付与する
という記述を、「guionさん」が仰る意味を含めて書きました。

////////////////////////////////
それから、全体としては、
私も、基本的には「guionさん」と同じ意見です。
「UML」は、まだまだ「不完全」だと思います。
少なくとも全ての「プログラミング言語」のベースとなる事は目指しているとは思いますが、
実際的にそれさえ出来ていないという所が、先ずその限界という気が私はします。
#たまに「UML」=「Java」と感じる事があったりします。
#また、「プロパティ」に関しては、本質に全く触れてさえいないと私は思います。

とは言っても、現在の所は「モデリング言語」は「UML」を「ベース」として展開して行く方が良いのではないでしょうか？
#尤も、「UML認定資格」等で「UML」での利権が絡めば、話は全く別になると思いますが…。
#それから、「UML認定資格」を取る人達には、「教条主義的」にだけはなって頂きたく無いですね。

[ メッセージ編集済み編集者: object 編集日時 2004-12-27 14:49 ]

guion: 常連さん; 会議室デビュー日: 2004/12/24; 投稿数: 30

投稿日時: 2004-12-27 14:44

まず自分書き込みを探す件ですが、

引用:
はにまるさんの書き込み (2004-12-27 09:57) より: 一つ一つの投稿文書の下段枠に「プロファイル」というアイコンがありますよね。その先に[このメンバーからの投稿を表示]というのがあります。そいつです。

なるほど。それに気付いていませんでした。
ありがとうございます。

guion: 常連さん; 会議室デビュー日: 2004/12/24; 投稿数: 30

投稿日時: 2004-12-27 16:29

引用:
skulkerさんの書き込み (2004-12-27 10:46) より: スケッチレベルならステレオタイプ(Fowlerの<<history>>とか)で充分でしょうし、

私がやりたいと思っているのは、historyとかの個別ケースじゃなく、もっと一般的に
<<relation>>
を作りたいわけです。

前述のシステムでは、Relationクラスの子孫クラスは、既に数百個作られています(^^;。
そして勿論、同一ノード間の多重性は許可ですし、クラス違いも問題なしです。
そういうRelationクラス全般を、安心かつ便利に表現できる手段が、UML上に欲しいわけです。

まあ作りたければ作ればいいといえばそれまでなんですが、
UMLに工場出荷時プリセット(?)されてる「関連クラス」と
思いっきりかぶっちゃうんですよね。
何せこちとら、<<relation>>以外の名前なんてつけたくありませんからね。

で、どっちかが道を譲る事になるわけですが、
UMLのあの「関連クラス」には、(正統性は有っても)正当性は少ないよなあ、と
私は思っているわけです。

というか、スケッチUMLをやるなら、はなから UMLのチャチな制約なんて気にせず、
「多重に描ける関連オブジェクト」を堂々と描かせてもらいますとも。はい。

スケッチにおいては、概ね心配する必要はないですね。
ただ、手書きじゃなくツールを使う場合(スケッチでもツール使うことは有ります)に、
ツールによって私が描きたいものを明示的に禁じられてしまわないか？という点が
気がかりではあります。

引用:
バリバリ拡張したいならMOFを使えばよいのでは。

MOFについては不勉強で全く知らないのですが、

○好きな絵柄を定義できる
○既存の制約を踏み潰す(overrideする)ことができる

の二点を満たしているものなのでしょうか？
そうならば「使える」のですが、出来ますか？

「関連クラス」でない普通のクラスを拡張できても、
あんまり嬉しくないんです。
あのカタチ(^^;をした「関連クラス」を拡張できて、はじめて旨みがある。

uk: ぬし; 会議室デビュー日: 2003/05/20; 投稿数: 1155; お住まい・勤務地: 東京都

投稿日時: 2004-12-27 20:35

引用:

guionさんの書き込み (2004-12-27 16:29) より:
前述のシステムでは、Relationクラスの子孫クラスは、既に数百個作られています(^^;。
そして勿論、同一ノード間の多重性は許可ですし、クラス違いも問題なしです。
そういうRelationクラス全般を、安心かつ便利に表現できる手段が、UML上に欲しいわけです。

そのRelationクラスというのがどんなクラスかわからないんですが、「関連クラス」をそれほど
意識する必要があるんでしょうか。個人的には件の記事で関連クラスとして適当な例、不適当
な例として挙げられているのは二つとも関連クラスとしてモデリングするのは不適当だと
思いますので(UMLの制約は関係なく)、関連クラスを意識せずにモデリングすればいいと
思うのですが。

引用:
「関連クラス」でない普通のクラスを拡張できても、あんまり嬉しくないんです。あのカタチ(^^;をした「関連クラス」を拡張できて、はじめて旨みがある。

その「旨み」ってなんですか?

guion: 常連さん; 会議室デビュー日: 2004/12/24; 投稿数: 30

投稿日時: 2004-12-27 23:14

引用:
objectさんの書き込み (2004-12-27 12:48) より: 「UML」には、考え方自体が少し形式的(表面的)である気が私はします。

UMLが言語(プログラム言語に近い奴…形式言語とかいうんでしたでしょうか？)である以上、
「形式的」であることは、歓迎されることであろうと思います。

ただ、その場合(曖昧でない言語ならば)特に心配しないとならないのが、
その言語で許されてる表現に、チャチな限界が設けれていないか？という点です。
なまじ曖昧じゃないために、限界を超えられないとか、越えるためにはヘンテコな回り道を要求されるとか、
そういう問題が生じます。そしてそれが有るとその言語は「使いにくく」なる。

そういう意味では、

引用:
「そこまで有効に実現しよう」とはしていない

それじゃ不味くて、使い物になるように制定者が熟考する必要が(特に)有るんです。

＃BASICは使いにくいとか、LISPマンセーとか(^^;いう意見があるのは、そういう点ですね。
＃言語としての限界が低くならないように熟考されてるかどうかの差。

その程度の完成度でしかないものならば、いろんな団体や企業(^^;がプッシュして
実戦配備するってのは、ちょっと勘弁して欲しいなぁという気がしています。

あと、UMLについて言えば、普通(?)のプログラム言語と違って、
見た目つまり直感に訴える部分とも
出来るだけ矛盾しないように作ったほうが
「もっと役立つ」という側面もあります。

なので、先ほども書きましたが、メタレベル(つまりルール)をユーザが変更できるというなら、
メタレベルの絵をユーザがさくさく作れないと「使い物にならない」のだと思います。

＃もともと、言語制定者が機能を提供しなくても、「ユーザが自力で提供」できるように、
＃言語仕様に自己拡張性を持たせる、という手を使うことが出来ます。

が、絵自体を追加したり絵のルールを修正したりするような仕組みって、
ふつーのUMLツールでは、見かけた記憶が無い…。
つまりふつーのUMLツールは「使い物にならない」…ということに(^^;

というか、もともと絵を拡張するなんてのは、一般ユーザにとっては多大な苦行だろうと思います。
普通のプログラム言語みたいにテキストで書くよりも、数倍大変じゃなかろうかと。
＃これが大変でないならば、UMLツールなんて誰も買わないと思います(^^;。
＃絵のルールを作るのが大変だからこそ、UMLツールは「売れて」いるわけで。

-------

引用:
#[2]は、分かり易く説明しようとしてして記述された、著者の独自の見解なんでしょうね。

判り易くしたというよりも、「筆者による関連クラスの理解」が
あの文章には表れているんだと想像しています。
つまり、(あの筆者じゃなく)私が先に指摘したような「誤解」を、
正に筆者はしている真っ最中なのではないか？と。

この「誤解」は、UML BASIC LECTURE (3)だけではなく、
同(8)でも再掲されています。(「再訪：関連クラスの誤解」っていう辺りです)
その間だいたい3ヶ月。その間ずっと筆者氏は誤解し続けてるのではないか？と想像しています。

UMLの恣意的な制約としてはそれはTRUEなんだろうけど、
問題の文面のように論理的に(つまり「言い換えると」みたいな言い回しを使って)説明しようとすると
無理がある、
という点を押さえてくれて"いない"のではないか、と。

guion: 常連さん; 会議室デビュー日: 2004/12/24; 投稿数: 30

投稿日時: 2004-12-27 23:16

objectさんの書き込み (2004-12-27 12:48) より:
> #たまに「UML」=「Java」と感じる事があったりします。

ああ。UMLは変にJavaに肩入れしすぎてるなぁ、と思うことは私も有ります。

ただ、その割には、Javaと随分違うところも多いですね。
一体どういう位置付けを目指してるのか、正直、よく判らないです。

たとえば、「関連はデフォでは両方向だ」っていう辺り。
実装言語ではそんな言語は希少ですし、
概念的にも、両方向も片方向も別にどっちを主にしても良さそう。
なのに、わざわざ両方向を選んだわけで…

> #また、「プロパティ」に関しては、本質に全く触れてさえいないと私は思います。

ああ。クラス図の二段目と三段目の合体技ですね(^^;
今のUMLじゃ素直に描けないですね。

私はVB/Delphiあがりなんで、
属性とメソッドみたいな低級概念だけをサポートしてて、
その上のプロパティをサポートしてないってのは、
すごく奇異に感じました。

> とは言っても、現在の所は「モデリング言語」は「UML」を「ベース」として
>展開して行く方が良いのではないでしょうか？

政治的には(^^;そうだと思います。
が、プログラマやモデラとしての良心に照らせば、呵責を覚えますね…。

そんなわけで、いいとこ取りだけをするスケッチャー的立場は、
結構アリだと思っています。

>#それから、「UML認定資格」を取る人達には、「教条主義的」にだけはなって頂きたく無いですね。

全くです。

guion: 常連さん; 会議室デビュー日: 2004/12/24; 投稿数: 30

投稿日時: 2004-12-27 23:42

ukさんの書き込み (2004-12-27 20:35) より:
>そのRelationクラスというのがどんなクラスかわからないんですが、「関連クラス」をそれほど
>意識する必要があるんでしょうか。

「必要が」有るかといわれれば微妙です。
というのは、これは(Rubyの松本氏の言葉を借りれば)
「出来るかどうか(それが無ければ何も出来ないか)」じゃなく
「便利かどうか」の問題ですので。

「モノとモノとの間を繋ぐモノ」を
「関連クラス」と呼びたいし、
その絵柄としては既存のUMLのあの絵柄がかなり秀逸だから、
こっちの意図に叶う意味に対しても使いたいぞ、ということです。

ちなみにこちらが経験している「Relationクラス」(の頂点クラス)は、
単に2つのポインタ
(ほんとはポインタ(ないしは参照)という呼び方は不正確であり、
ポインタみたいなアーキテクチャ自体がかなり特殊な言語なのですが、
一番近い概念として仮にポインタと呼んでおくことにします)
だけを属性として持っているオブジェクト(のクラス)です。
関連の線(というかリンク)の両端のオブジェクトをそれぞれ指す属性が有る。それだけです。

＃「ポインタと違う」っていうのは、
＃こいつはUMLの関連みたいに、デフォで片方向じゃなく両方向の関連なんです。
＃まああえて言えばRDBが近いかな。
＃だから、ノードは、「自分を参照してる関連オブジェクト」を(そういう属性を持っていないのに)見つけることが出来ます。
＃そして勿論、関連オブジェクトの向こう側に居る相方も、見つけることが出来ます。

＃そうそう。こいつのアーキテクチャに近いものは、実装としては他で見たことが無いんですが、
＃概念レベルでは、「Object Role Modeling」という奴に近いなぁと感じています。

>関連クラスを意識せずにモデリングすればいいと思うのですが。

モデラーの人が(^^;「関連だ」と捉えたならば、
その選択をUMLという言語ごとき(^^;が妨げないで欲しい、とは思っています。
そういうのは、書きあがった後で、モデリングの良し悪しとして評価すればいいだけのこと。
文法が制約すべきことではないでしょよ、と。

まあそれはともかく、正直、あの記事のあの例が適切かどうかってのは
(例の論理的に変らしき記述を見つけたあたりで)
熟考する熱意を失ったので、私としてはどうでもいいです。

ただ、「関連だ」と呼びたくて、「オブジェクト」として捉えると好都合で、
しかも複数引ける可能性を否定したくない、というケースは
幾らでも有り得ると思っています。

たぶん、私の手元にも、探せば数百の(^^;好例が有るのだと思います。
(もちろん中には不適切な例も有ろうとは思いますが。)

>>あのカタチ(^^;をした「関連クラス」を拡張できて、はじめて旨みがある。
>その「旨み」ってなんですか?

ぶっちゃけ言えば、あのカタチを我が物(^^;に出来ることが旨みです。

あ。我が物といっても、もちろん私一人のものという意味じゃないですよ。
1対のノードの間に複数の関連線を(ただしオブジェクトつきで)引きたいと思ってる、
全国2億6千万モデラー諸氏(ぉぃぉぃ)のもの、という意味です。

あの「絵のカタチ」は、関連クラスを表すカタチとして、結構秀逸だと思っています。
2つのモノの間に線が引いてあり、それ自体にオブジェクトとしての情報がぶら下がってる。
これぞまさしく表現したいものだ！我が意を得たり！って感じです。

だからこそ、あんな変な制約の支配下において欲しくない。「こっち」にも使わせて欲しい。

確かに普通のクラスから2つの関連線を生やして、左右両側のクラスに繋いでも、
論理的に同じものは表現できます。
が、「これぞ関連じゃねーか！」という雰囲気(^^;は表現できないわけです。

guion: 常連さん; 会議室デビュー日: 2004/12/24; 投稿数: 30

投稿日時: 2004-12-27 23:48

自分の書き込み (2004-12-27 23:42) より:
>>>あのカタチ(^^;をした「関連クラス」を拡張できて、はじめて旨みがある。
>>その「旨み」ってなんですか?
>ぶっちゃけ言えば、あのカタチを我が物(^^;に出来ることが旨みです。

あ。1つの可能性について言及し忘れていました。

普通のクラスとも、関連クラスとも、
どちらとも同じじゃない第三の絵柄を定義する、
っていう道でも、構いません。

ただ、その絵は、どうしても現状の関連クラスに似た絵になるでしょうね。
少なくとも私ならそうデザインする。

そして一方、少し前にも書いたように、「純関連クラス」は実用的な存在価値が無いので、
今の「純関連クラス」を表す絵柄は、空席になってしまうわけです。
それを遊ばせておく手は無いな、と思っています(^^;

«前のページへ 1|2|3|4|5|6|7 次のページへ»

UML：関連クラスの誤解について

スキルアップ／キャリアアップ（JOB@IT）