@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
UML:関連クラスの誤解について
投稿者 | 投稿内容 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-01-05 13:02
objectです。
>guionさん >ええと。どのように「意見が違う」のでしょうか? >抜粋(抜粋は意見ではない)の後に、 >なにも文章(意見)が続いていないようですが… 私の表現の意図を、少し詳しく説明します。 私は、 guionさんの --------------------------------------- たとえば、「関連はデフォでは両方向だ」っていう辺り。 実装言語ではそんな言語は希少ですし、 概念的にも、両方向も片方向も別にどっちを主にしても良さそう。 なのに、わざわざ両方向を選んだわけで… --------------------------------------- に対して、 --------------------------------------- ここに関しては、少し私とは意見が違う様です。 --------------------------------------- と書きました。 それで、私は、 「UML」に於ける「関連の定義」に則した形 で、guionさんに説明して頂くべく、誘導した積もりでした。 少し分かり難かったですね。 申し訳ありません。 それから、「UML」に関しては色々問題があると思いますが、 件名:.NET開発者のためのリファクタリング入門について に書いた様に、 先ず基本をシッカリさせないと、全ての議論が徒労に終わる と私は思っています。 [ メッセージ編集済み 編集者: object 編集日時 2005-01-05 13:04 ] | ||||||||||||||||
|
投稿日時: 2005-01-16 09:12
はにまるさんの書き込み (2005-01-03 00:42) より:
>>「作りたい構造を、そのまま」 >私は設計が完了に近い状態でなければ「作りたい構造」が解りませんし、 完了間近であろうと、道半ばであろうと、どっちであろうと、 その時点なりの「作りたい構造」が有るんじゃないでしょうか? また、全体は未だ見えない段階であっても、部分においては構造が見えてる事も 結構ありますよね。 (たとえばその1つとして、関連クラスの問題が有るんじゃないか?と思うのです。) そして、それぞれの時点なりのそれぞれの構造を、 なんらかの表記手段によって表記したい(したくなることは有る) んじゃないでしょうか? たとえば、 「UMLで描くとき、関連クラスを使わなくても、通常クラスで描けばいいじゃないか」 という声もあったかと思いますが、それをやると凄く困るというか面倒になるのが、 「多重度」の図上での表現です。 AおよびBというエッジクラスを繋ぐ関連(クラス)Rがあり、 その多重度がそれぞれxとyである場合、つまり、 図1: A(x)---(y)B | R という場合において、この関連クラスを通常クラスにバラして表記すると、 図2: A(1)---(y)R(x)---(1)B という、一捻りした多重度になるわけで、ちょっとこれでは 図2(表現できる構造)から図1(作りたい構造)を想像するのは困難なわけで。 >設計時に「作りたい構造を、そのまま表現出来る」図式表現は重要視しません。 >それは「作りたい構造」が実現化不能又は困難であっては困るからです。 ん?実現可能であることを重んじるなら、なおのこと、 それが実現可能かどうかを見て確かめる(これも一種の「見える化」ですね)ことが 大事なのではないか (つまり「絵にも描けない美しさ」なんていう暢気な事を言っちゃいかん)、 と私は思ったんですが、逆なんでしょうか? #まあ、頼るに値しない文法(図法)だったら却って困る、という面もありますが。 >それは、複数のクラス又は複数のオブジェクトを1纏めで捉えているから >「多重関連」になってしまっている。と言う事では無いのでしょうか? >若しくは、業務屋の観点からすると、 >多重関連の問題は「オブジェクト」では無く「情報(データ)」の問題では無いでしょうか? いやー、 どうも世間で馴染みが無いせいか、 関連クラス(UML定義によるやつじゃなくて一般論として)の風当たりは強いですが(^^;、 「関連かつオブジェクト」っていう道具が有ると、かなり便利ですよ。 こないだ書いたように私は(幸いにして) 関連クラス、関連オブジェクトと呼ぶに値するものが 概念だけじゃなくてちゃんと実装として動いてるってゆーのを 体験しているわけですが、 すごくいいですよ。あれは。 #少なくとも「エッジのクラス定義を変更しなくても、関連クラスのクラス定義を変更するだけで #関連を改造(改良)することができる」という性質が有るおかげで、 #すでに実働しているオブジェクトDB環境のスキーマ変更のリスクを #多少下げることができます。まあこれは多数あるメリットの1つです。 まあ実装処理系の有無はともかくとしても、 多重関連を「データ」として見るってのは、単なる最適化の手法に過ぎないと思います。 やっぱり全てはオブジェクト。これでしょ。 >とすると...、guionさん論点は「多重関連の表現」になるのでしょうか? 先日「疑問には思ってない」と言いましたが、 それはつまり理解しているというだけの意味であって、賛同はしていません。 「そんな定義をしても使いものにならんでしょ?じゃあ道を塞がずに空けてよ。」ということです。 | ||||||||||||||||
|
投稿日時: 2005-01-16 09:31
はにまるさんの書き込み (2005-01-03 01:14) より
>ここで言う簡略化の理由や原因は図でも言語でも無いです。 >システム利用者とシステム開発者の仕事上(作業や要望)の問題です。 ええ。それでも構いませんよ。 しかしそれでも、関連クラスの問題が消えるわけではないと思います。 関連クラスを使うか否か?という問題は、 (「客にドメインモデルの設計図を見せたほうがいい」という話と同じ意味で) 利用者の業務とかにも直結(?)してる問題だと思います。 >つまり直接的なオブジェクトの話では無く情報と手順の話であり >情報と手順が必要無いからオブジェクトも要らないよ!っていう話です。 >ま〜、考えがオブジェクト指向から外れているとは思いますが。 うん。外れてますね(^^; OOPが万能だとは言いませんが、 少なくともこの問題は、オブジェクトによって表現可能であるはずです。 というか可能という言い方は弱いですね。 むしろ「そのほうが相応しい」と言っておくべきですね。 それにそもそも、情報が必要です(手順も…場合によっては必要でしょうね)から、 オブジェクトも要らないという結論には、至って欲しくないのですが(^^;。 関連に、ObjectIDやそれ以外の諸々の情報をぶらさげたい「場合には」どうしたいのか、 という話なのですから。 (オブジェクトとみなす必要が無い(個体識別も属性も与える積もりが無い)関連については、 今回は考えていませんから。) >関連をプロセス定義では無く。データ定義出来れば面白いでしょうね:D >TCP/IPの考えをPC内部(プロセス)に取り入れて、 >ノード→オブジェクト、パケット→メッセージの様な関係で >メッセージを特定のオブジェクト・グループにブロードキャストしてそれぞれの >オブジェクトが自分に必要なメッセージか判断し、それぞれのオブジェクトが >独自のメッセージ解釈をして処理する。 すみません。どう面白いのかは、よく判りませんでしたm(__)m というか、それって関連じゃなくてMessageSendingの問題でしょうから、 とりあえず今の話とは関係ないですよね。 #無関係であること自体が悪いと言いたいわけではないですが、 #とりあえず私は、話の脈絡はつかめませんでした。 | ||||||||||||||||
|
投稿日時: 2005-01-16 10:02
objectさんの書き込み (2005-01-05 13:02) より:
>それで、私は、 >「UML」に於ける「関連の定義」に則した形 >で、guionさんに説明して頂くべく、誘導した積もりでした。 >少し分かり難かったですね。 ええと。「少し」ではなく、全く分かりません…。 あれでは何をどう誘導されたのかが全然読み取れませんでした。 少なくとも何かを頼まれた文面には全然えませんでした。 さて、それはともかく、 >「UML」に於ける「関連の定義」に則した形 >で、guionさんに説明して頂くべく、 とのことですが、「何を」私に説明してほしいと仰ってるのでしょうか? 私の認識だと、そもそも私が主張したい要求がUMLの定義から外れている以上、 UMLの関連の定義に即した形では、語りようが無い、のではないかと 思ってるのですが、違うでしょうか? もしかして、 「即して(説明せよ)」ではなく、 「同様の表現(語彙とか)を使って(説明せよ)」、 と仰りたいのでしょうか? >それから、「UML」に関しては色々問題があると思いますが、 >件名:.NET開発者のためのリファクタリング入門について >に書いた様に、 >先ず基本をシッカリさせないと、全ての議論が徒労に終わる うーん。すみません。この場合は何が「基本」なのでしょうか? 語彙でしょうか? 哲学(の用語)でしょうか? あちらのスレッドも読みました(し書きました)が、 どうも「どこがどう基本なのか」が読み取れませんでした。 どちらかというと、「オブジェクト指向の議論」をしてるというより、 「オブジェクト指向とも共通点のある、哲学(でしたっけ)の、議論」を 行ってるように見えました。 つまり、「それって本当に基本なのか?」と。 なお、「基本」という言葉が「UMLの厳密な定義」を(も)指すのでしたら、 (今の「未完成な」状態ですら既に)言語定義として肥大化してしまってるUMLを あまり追いかけたくない、という面もあります。どうしたものでしょうね…。 #UMLって、オブジェクト指向設計界のBASICだよなあ... #(少なくとも事実上は)構造の柔軟さではなく語彙の数で力押しする言語なんだもん。 あと、「全ての」議論が徒労ってのは、言いすぎだと思います。 ただ、基本(とその人が称するもの)を踏まえないと議論ができない人が 議論者の中に一人以上居る場合、それを踏まえなければ議論は成り立たない、 ってのは真ですが。 | ||||||||||||||||
|
投稿日時: 2005-01-16 22:57
guionさんへ返答する前に前投稿時点での認識の間違いに気がついたので
反省の意を込め現状の認識を記述します。(つまり読解力が無かったよん) 間違っていたら突っ込みお願いします。 #↓追記 ごめんなさい下記内容は論点を忘れ勘違いしたまま記述してしまいました。 論点は、両クラスのオブジェクトを定めても、関連クラスのインスタンスが 定まらないでした。 m(_ _)m #↑追記
私はこの説明をクラス図のままで考え受止めてしまいました。 関連クラスは「対なるクラス間のリンク上に存在する」為、 それをオブジェクトに展開して考えると 関連クラスのオブジェクトは「対なるオブジェクト間のリンク上に存在する」事になり 1つの意義を持つ1リンク上にしか存在しえない関連クラスのオブジェクトは、 両端のオブジェクトを一意に定める。と云える事が解りました。 よって
は、クラス図だけて考えてしまった私の勘違いから生まれた疑問でした。 また、個人的に関連クラスの説明として、こう云うのは如何かなと考えました。 (1)「生みの親」と「生まれた子」の関係は関連クラスで表現します。 これは親が子を産んだ事により生まれる親子の関係は一回決定すると変わる事が無いからです。 しかし、これは概念レベルでの話です。 その理由は、実装レベルに措いて現実の親子関係をシステムに直結させる事が出来無いからです。 様は(2)システム実装に措ける親子は、人の意識行動が介入される申請行為によって生成される為、 申請行為の繰返しが不可欠だからです。 つまり(1)と(2)は似ている様で、定義している世界が異なる訳で、 例えば(1)と(2)に措ける定義世界のズレは、不妊治療で出産した(された) 親子関係の法的な取り扱いの問題が良い例(不謹慎で申し訳ない。)だと考えています。 [ メッセージ編集済み 編集者: はにまる 編集日時 2005-01-17 12:48 ] [ メッセージ編集済み 編集者: はにまる 編集日時 2005-01-17 12:49 ] | ||||||||||||||||
|
投稿日時: 2005-01-16 23:22
guionさんへ返答する前に(その2)
前投稿時点での認識の間違いに気付き新たな疑問を持ったので提起しておきます。 ただ、これは単に私のUMLに対する理解不足かもしれません。 参照元記事の 上記、図の問題として
と説明されていますが、しかしこのクラス図をオブジェクトに展開して考えると 利用者が図書(本)を返却した時点で、貸出オブジェクトは消滅する。 のでは無いでしょうか? そして、消滅後に措いてこの一利用者と一図書の関係は無く。 飽くまで、この一利用者が借りたという過去の事実は情報であって 貸出オブジェクトの生存として生かすのは、疑問があります。 そしてまた再度、借りた場合に発生する貸出は前回とは別に新たにオブジェクトが 生成される事になると考え、何が問題なのか新たな疑問が生まれました。 _________________ 人生変わっちゃうかもよ?OFF会参加者募集中今考えるな、参加してから考えろ。 | ||||||||||||||||
|
投稿日時: 2005-01-17 00:21
力量不足な為、guionさんの求める意見レベルを即座に提示出来無い事をご了承ください。
また、粘り強く辛抱して意見して頂けている事に大変感謝致します。
まず議題とズレる事をご了承下さい。 実は、これがオブジェクト指向開発が業務システムに向かないと云われる原因で その理由を自分で説明出来るまでに認識する必要があると思っている所です。 簡単に云えば、上手く説明出来ない状態です。すみません。 ただ現状認識を説明致しますと。 オブジェクト指向ではオブジェクトの一意性を重視すると今回の議論で認識しましたが、 しかし、このオブジェクトの一意性が有効なのは業務上に措ける管理階層の最下層だけと 考えています。この管理階層とは、企業における情報統括の管理階層です。 例えば、システム開発企業のシステム開発管理を想定した場合、 ソースモジュールレベルでの識別管理はプロジェクト関係者レベルになり、 部門長はそんなレベルの情報は欲しませんし、 経営層は一定規模以上のプロジェクト以外に自体に興味を示しません。 つまり上記の管理階層構造により最下層で存在しえるオブジェクト(WBS等)は 上位の管理階層に移動する際、オブジェクトが破壊(又は転換)されて単なる グロス情報(進捗率)になってしまうと考える訳です。 よって、 >少なくともこの問題は、オブジェクトによって表現可能であるはずです。 は仰る通りですが、開発対象のシステムが担う管理階層に最下層(現場管理)が 含まれない場合、最下層のシステム(コンピュータシステムに限らない)が興す情報を 処理するシステムにしなければならず、この際にオブジェクトの識別不能の為に オブジェクト指向の業務分析に措いて有効性の限界が発生すると浅知恵で考えています。
ごめんなさい、自分で投稿して置いて申し訳無いですが、 仰る通り関係無いので無視でお願い致します。 _________________ 日本の中心で、オフを叫ぶ(@名古屋)。 ご意見募集中! [ メッセージ編集済み 編集者: はにまる 編集日時 2005-01-17 00:22 ] | ||||||||||||||||
|
投稿日時: 2005-01-17 02:04
ごめんなさい、この投稿を見逃していました。
う〜ん、深くてムズ痒い所ですね。 まず、私はオブジェクト指向関連の技法は、勉強程度でしかやっていないので、 実装可能な状態までに行ったり来たりを繰り返しています。 もしかすると、私に抜けている所があるのかもしれません。(単なる経験不足?) また、私は分析行為や設計行為で作業をする場合に、自分自身が何がしかの暗黙的変換作業を している事までは認識しているのですが、その変換作業が確実に理解出来ていないのです。 意見を聞く限りそれがguionさんには変換作業行為が確りと認識出来ているのでは?と思えました。
正直羨ましいですね、その様な体験をされている事が。 視界が広がるんでしょうね。 もう一回スレを読み直して解ったのですが、 私の認識範囲を超えている所でにguionさんは物事を考えている人なんだな。 という所まで認識出来ました。 正直私は、いま認識している範囲内で確りと説明出来る状態まで理解したい という前向きな内向き姿勢なので、guionさんの意見は新鮮で勉強になります。
全てはオブジェクトですか。いいですね。 前文を含めツールに思考を合わせ過ぎているのかな?と思うの同時に 逆に思考を広げる為にツールを利用するのも有りなんだろうな、と思いました。 また、取り留めも無くオブジェクト指向から外れましたね。スミマセン。 |