＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
UML：関連クラスの誤解について
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-12-31 10:04
関連にオブジェクトの性質を付加するんだったら、
オブジェクトの十八番である識別性を活用しないなんて、馬鹿げてます。 なのでUMLは、 ○広義関連クラス(^^;を用意する。 か、あるいはいっそ、 ○(純)関連クラスなんていう半端なものは、用意しない。 (広義関連クラスを通常クラスの組み合わせで表現できるぞというならば、 純関連クラスだって、広義関連クラスに更に1つの制約(重複ダメよん)を追加する「だけ」で出来ちゃいますからね:-)) か、どっちかにすればいいんじゃないかと思います。 ---- 「UMLモデリングの本質」(児玉公信氏)の、P46の直ぐ後のp48あたりに、 どうもすっきりしない記述が有ります。 [1]「関連は(中略)クラス間におけるリンクの集合を表す」(P44) [2]「「集合の中には同じ要素が重複して存在することはない」という集合の定義に関わっている」(P47) [3]「関連クラスは事象を記録する」(P48、小見出し(2)の見出し名) 1や2とで、まあUMLの関連クラスは集合(重複を許さない)ということになってるってのは構わないのですが、 問題は、ここ数ページの例でも正に示されているように、 純関連クラス(つまり集合)だと「事象を記録できないことがある」って点です。 皆さんが既にご存知でしょうけど「履歴をとりたい」というケースとか、 前述の「最履修」のケースとか、 考えればそんなものは幾らでも有ります。 そのため(か)、おかしなことに、 [4]「したがって、業務システムでは(中略)関連を通常のクラスで表記するのが一般的だ」 という記述が、[3]の見出しから始まる文章「に」書かれているんです。 つまり一体であるはずの[3]と[4]の言ってることが自己矛盾している。 ほんとに「関連クラスは事象を記録する」というならば、 通常クラスなんか使わなくて済むはずなのに。 この歯切れの悪さは… …もしかして児玉さんも釈然としていなかった、のだろうか？(^^; ---- というわけで、 UMLの生きる道(^^;として、第三の提案もしておきます。 関連は集合だ、関連クラスも集合だ、だから関連クラスは多重化できない、という三段論法には、 1つの穴が有るのだと思います。 それは、「何の」集合なのか？という話です。 無印の関連線は、両端のNodeのIDしか、集合のネタとして使える情報が有りません。 だから多重化できないっていう理屈は通る。 しかし、関連オブジェクトは他にも属性が色々ある(最悪でも関連オブジェクト自体のIDが有る)わけですから、 ○関連オブジェクトの属性も、関連の「集合」の中で要素を特定(区別)するための材料として、使っていいことにする。 という道を選べば、万事丸く収まるわけです(^^; これにより、使い道の少ない純関連クラスは自然消滅してくださいます。 結局のところ、「関連」の制約はOverride可能なHotspot(改造点)として定義しておいてくれたら 良かったのになあ、ということだと思います。 | ||||||||||||||||
|
投稿日時: 2004-12-31 10:12
はにまるさんの書き込み (2004-12-28 10:30) より:
>関連クラスで表現出来るほどの意義のある関連を簡略化する場合は 簡略化せずに済んだらいいのになあ、と私は思うんです(^^; 関連クラス(広義)が自由自在に使える実装処理系が もっと多く存在してくれるといいんですけどねえ。 そうすれば、何をどうすれば使い物になるのか、ということを より多くの人が考えるようになって、 (OpenSourceの「多くの目」みたいに)改良が促進されるんでしょうけど。 ＃「制御情報」という言葉によって何を仰りたいのかが、ちょっと読み取れなかったので、 ＃はずしてるかも知れませんが… | ||||||||||||||||
|
投稿日時: 2004-12-31 13:17
objectさんの書き込み (2004-12-29 16:31) より:
>私が「形式的(表面的)」と書いたのはそういう意味ではありません。 (中略) >「クラス」に止揚された「関連」は一体何だったの？ >という意味で、「形式的(表面的)」という言葉を使わせて頂きました。 まあ言葉には色々な意味が有るので、それはそれなんですが、 ＃というか、「形式的」という言葉の世間での使われ方に、ちょっと疑問を感じてます… それはともかく、「表面的」ってのは全くもって同意します。 >「広義・狭義の関連クラス」を導入する為には、 >「今の枠組み」とは異なる「別の枠組み」を採用 >しないと、或る意味で言葉に矛盾(曖昧性)が生じるのではないでしょうか？ 行き違いになりましたが、2004-12-31 10:04 に私が書いたように 幾つかの道が有り得るだろうとは思っています。 なお参考までに。 友人に相談したところ、 「Associationを関連と訳すからおかしくなるんだ」 「純関連の制約のことを考えると、(英和辞書を調べて…)「連想」という訳のほうが、良かったのではないか？」 とのことでした。 幾つかの言語には連想配列(とか辞書とかハッシュとか呼ばれる奴)が有りますが、 あれのように要素の重複を(キー単位で)拒絶する奴ってことですね。 言葉の曖昧さという意味では、こっちのほうを気にすべきなんじゃないか？とは思います。 つまり、一部(?)の言語にはCollection系クラスの子孫としてSet(重複不可)とBag(重複可)というのが有りますが、 純関連と広義関連とはちょうどSetとBagの関係にあるのではないか？と。 うまい命名とはとても言えませんが一案を出すならば、「AccosiationClass」じゃなく「SetClass、BagClass」とか。 ただ、前述したように、Setの重複チェックのネタとして何を使うか？を 単純な関連と関連クラスとの間で同じにする義理は無かったろうに、というのが 私の主張(の一部)なので、 広義関連をBagに喩える必要は、私は、感じていません。 >私は、それが出来ないから現状維持をせざるを得ないと考えています。 「出来ない」のは、 「こちらの主張がUML制定者に届くまでに時間がかかる(^^;」から、に他ならないですよね。 そういう意味では「現状のUMLのユーザに過ぎない私」が現状維持を強制されるのは、当然ではありますね。 ただ、当然ではあっても「残念」であり、受け入れるには苦痛を伴いますが。 ＃ストックホルム症候群は御免です。許容と賛同は別です。 >「UML」に於いて、 >「構造的にシッカリした枠組みが必要・十分な形で整理」 >されないと、無理なのではないでしょうか？ >「UML」は、まだそこまで至っていないと私は思っています。 それはたぶん、メタなんとかって奴の仕事なのだろうと想像します。 (想像という言い方をしてるのは、自分がUMLの規格書をきちんと読んでないせいです。) で、メタなんとかが、どれくらい「きちんと」してるかも(今の)私は知らないです。 あと規格だけじゃなく、絵柄の定義と連動する必要があるだろうと思っています。 つまり、絵柄の定義の機能をUMLツールに積むことを、規格によって義務化してもらう、とか。 …ツール市場への参入障壁が増えそうですね(^^; 逆にいえば、そういうツール作成側への負担を最小限にするための逃げの手として 絵じゃなくテキストベースの言語ってものが今まで山のように沢山作られてきたわけで…。 つまり、絵言語って、もともと(対コストの)拡張性は低いんですよね。 形式という奴は、 ○形式としてきちんと辻褄がとれている。 ○その形式が使いやすいようにデザインされている。 という二点を満たして初めて、使い物になるんですよね… >かなり厳しいですね。 というか、もしアレが(私が睨んだとおりに)誤解ならば、 厳しいというより、「3ヶ月誤解し続けてる」は単なる事実です(^^; >これに関しては、読者サイドの想像ではなく、筆者御自身が何らかの形で対応して頂ける事を祈ります。 そうですねえ。ここにこうして書いておくと、 同じ@IT内ということで、筆者側に自動的に認知されたりする…のかな？ 元々、ご本人にMailでも投げようかと(ここ3ヶ月)思っていたんですが、 メアドも書いてないし、所属企業の窓口としては妥当そうなメアドが無いし (あえて言えばセールス担当くらいでしょうか。でもそれも変ですよね…) 投げるターゲットが無いなぁという状況でした。 >「Java」以外の例えば、「C#」に近い内容での議論等を殆ど聞かないと言う主旨での >「UML」が少し言語に近過ぎるのでは？ 単にC#が新参だからかなと思っています。 Javaが出てきたのとUMLが出てきたのって、たまたま同じような時期だったんで、 面影(???)を重ねて捉える人が後を絶たないのだろうと想像しています。 実際には、Javaとも、C#とも、C++とも、ObjectiveCとも、Rubyとも、Smalltalkとも、 その他どんな言語とも(^^;、 似てる処と似てない処が半々という感じです。 ただし、注意すべきは、 「似てない処が半分有る」からといって「どの言語からも中立な、言語非依存性を、実現できてる」とは 言い切れないという点です。 それだけだと、単に、「どの言語とも似てないUMLという言語が有る」というだけなんですよね。 >ここに関しては、少し私とは意見が違う様です。 >「UML仕様書」での「関連」の説明を抜粋します。 (後略) ええと。どのように「意見が違う」のでしょうか？ 抜粋(抜粋は意見ではない)の後に、 なにも文章(意見)が続いていないようですが… >私は、もっと基本的な意味で書きました。 >#プロパティに関する私の考えは、要約を以下のスレに簡単に書きました。 >#件名：.NET開発者のためのリファクタリング入門について では、その話題の続きは、私も、そちらに(も)書いてみます。 私の捉え方は、やや違うようです。 で、objectさんの考え方を「基本的」と呼んでいいのかどうか？を、ちょっと迷っています。 | ||||||||||||||||
|
投稿日時: 2004-12-31 13:27
その行だけ取り出すと「うーん」ということになりますね。 その前の行からの続きという文脈では、一応、 実装で役立たないけど、分析や設計では役立つ、 なんていう図法は、有るの？ そういうのってUMLでは結局無意味なんじゃないの？ ということを主張してるつもりだったんですが、 その主張自体が変だとすると、どのように変なのか説明して頂けると助かります。 ---- UML…というかその地盤であるはずのObject指向の考え方では、 実装も設計も分析も大筋で同じ考え方をし続けりゃいいじゃん、という面が有りますよね。 分析／設計／実装の間で、いちいち意味のインピーダンスミスマッチを作らないようにしようぜ、と。 関連クラスが実装では役立たないけど設計では役立つ、という捉え方は、 オブジェクト指向のこういう考え方に、逆光しちゃうんじゃないかな？と思います。 つまり、実装で役立たないからと切り捨てるならば、 分析や設計でも使わないほうが良いんじゃないか？と。 | ||||||||||||||||
|
投稿日時: 2004-12-31 15:09
「大筋で同じ考え方」という言葉の解釈次第ですな。 概念モデル・設計モデル・実装モデルとフェーズ毎に違うモデルになるのはよくある事です。 一方で、世の主流のOOPLでは実装できないような概念、例えば多重分類のようなものでも、分析段階で便利ならそれはそれで使いましょうって言う人もいるし。 OMGはMDAの方向に向かっているので、分析・設計段階(PIM)でOOでも、実装段階(PSM)ではPL/IとかCOBOLにマッピングされるって事もありえますから、そういう考え方も反映されているかと。 | ||||||||||||||||
|
投稿日時: 2005-01-03 00:42
はにまるです。
いえ。２つの意義で捉えています。 一つ、実装するか否か判断をする事。 二つ、例え実装しなくても、実装しない事により起こる不整合の調整判断に使う事。 の２つです。
私は設計が完了に近い状態でなければ「作りたい構造」が解りませんし、 設計時に「作りたい構造を、そのまま表現出来る」図式表現は重要視しません。 それは「作りたい構造」が実現化不能又は困難であっては困るからです。
同意です。
とすると．．．、guionさん論点は「多重関連の表現」になるのでしょうか？ オブジェクト指向は遊び程度でしか解らないので、他の方の様に深い意見や 突っ込みは出せませんが。 それは、複数のクラス又は複数のオブジェクトを１纏めで捉えているから 「多重関連」になってしまっている。と言う事では無いのでしょうか？ 若しくは、業務屋の観点からすると、 多重関連の問題は「オブジェクト」では無く「情報（データ）」の問題では無いでしょうか？ | ||||||||||||||||
|
投稿日時: 2005-01-03 00:48
提示された質問になった、疑問に思う途中段階を一つ提示頂けませんか？ 返答の方向性が定まりませんでした。 | ||||||||||||||||
|
投稿日時: 2005-01-03 01:14
ここで言う簡略化の理由や原因は図でも言語でも無いです。 システム利用者とシステム開発者の仕事上(作業や要望）の問題です。 つまり直接的なオブジェクトの話では無く情報と手順の話であり 情報と手順が必要無いからオブジェクトも要らないよ！っていう話です。 ま〜、考えがオブジェクト指向から外れているとは思いますが。
あ．．．なるほど！ 関連をプロセス定義では無く。データ定義出来れば面白いでしょうね 
ＴＣＰ／ＩＰの考えをＰＣ内部（プロセス）に取り入れて、 ノード→オブジェクト、パケット→メッセージの様な関係で メッセージを特定のオブジェクト・グループにブロードキャストしてそれぞれの オブジェクトが自分に必要なメッセージか判断し、それぞれのオブジェクトが 独自のメッセージ解釈をして処理する。 ってま、これ位は既に誰かが考えているんでしょうが．．．． 
| ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.