@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「UML」を初めとする現在の「モデリング言語(手法)」の問題点は?
投稿者 | 投稿内容 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-01-19 17:29
objectです。
少しテーマが大きいですが、 現在の「モデリング言語」は、そのベースが、どれも「結局」は 「ソフトウエア空間」内に留まっている と私は思っています。 私は「件名:UML:関連クラスの誤解について」のレス(投稿日時: 2005-01-17 12:50)で ---------------------------------------------------------------- 「Java」と「C#」の比較に於いて、 「プロパティ」を使った方が表現が分かり易い と良く言われます。 しかし、これは「分かり易い・難い」というレベルの問題では無くて、 「代数構造」の問題であり、 「Java」は「ドメイン空間」をベースに考えた場合、 「ソフトウエア空間の代数構造に欠陥がある」 と私は言っている訳です。 また、 「UML」もこの事に気付いていない様だ ---------------------------------------------------------------- と書きました。 「ドメイン空間」と「ソフトウエア空間」の「構造」をシッカリ把握し、 これらの上での実際的な「モデル構築」のベースを与えるのは、本来言語というより、 「UML」を初めとする「モデリング言語(手法)」の責任 である筈だと私は思います。 しかし現在、「モデリング言語(手法)」は、上の意味での「構造的なベース」が無い状態で、ただ拡張して行こうとしている様に私には見えます。 #MDA、Executable UMLその他を含めて。 「モデリング言語(手法)」は本当に今のスタンスとその延長で良いのでしょうか? そして、駄目な場合、具体的にどうすれば今の状態を改善出来るとみなさんは思いますか? #今の「UML」関連の組織だけで、本当に現在の状況が改善されて行くのでしょうか? #プロパティに関する統一は未だに出来ていません。 #ここでは細かい「HowTo」の議論では無く、基本的本質的なものを対象にしています。 出来れば、皆さんのご意見をお聞かせ下さい。 | ||||||||||||||||
|
投稿日時: 2005-01-19 17:49
えー・・・元々UMLはRationalの所有物だったわけで。 UMLがモデリング言語として生き残ってきたことを考えると、 改善されるかどうかは別次元だと思います。
おそらく、複数の実装言語を扱いつつ単一のモデリングを元にする作業を 実践している人が少ないから、あえて統一せず、実装言語にあわせて ローカルルールで記述する方がいいのではないでしょうか。
(UMLによる)モデリングはあくまで設計手法の一つにすぎないですし、 UMLだけを使って設計を行うことはありえません。 「HowTo」なくしてUMLを論じようというのは現実的では無いですし、 UMLが単体で意味するものは学術的なメタファでしかないのです。 オブジェクト指向設計全体を見たとき、メタファとしてUMLは不十分でしょうか? 図示できない設計情報を無理やり図示すべきではないし、 必要以上の詳細化は硬直してしまい、実装言語で二重の定義をしてしまうことに なり設計上の矛盾を生じさせる原因になる可能性が高いと思います。 いきなりの横槍でマトはずしてたらごめんなさい。 #元Rationalの人曰く、「UMLは情報交換の道具でしかない」だそうです。 [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-01-19 17:59 ] | ||||||||||||||||
|
投稿日時: 2005-01-19 18:48
るぱんです。
zaxx_MDさんのご指摘は的を射ていると考えています。
スタンスとしては有りと考えています。 個人的な見解を述べれば、活動に加わって問題点を指摘していけばよいのではないかと思います。 もしくは、UMLをベースとした新しい図解言語を「日本発」で仕様を取りまとめていくぐらいの気概があればよいのではないでしょうか? 仕様を取りまとめてる連中からすれば、 「問題意識はわかった。だったら提案してくれ。」 と言うことではないかと思います。 XMLのParserのDOM方式が出てきた際にSAX方式を取りまとめたようなことを考えるのはいかがでしょうか? zaxx_MDさんご指摘済みですが、 全部の言語をTOTALでサポートするのは個人的におろかだと思います。 個人的にはUMLは仕様書を理解することを助ける道具と言う風に考えております。 さらに言うと、万能ではけしてないですし、 開米さんの「図解言語」(アイデアクラフト)もUML以上に有効なシチュエーションがある・・・ぐらいに考えています。 日本語も外国語もそうだと思いますが、 「定義」が最初にあって話し始めたわけではないわけですし、 恐らく、言語と名のつくものは進化していくのではないでしょうか? 気持ち的にめんどくさくてうっとぉしいと言う思いはありますけどね。 [編集] 使用→仕様 [/編集] [ メッセージ編集済み 編集者: るぱん 編集日時 2005-01-19 21:39 ] | ||||||||||||||||
|
投稿日時: 2005-01-20 12:34
objectです。
>zaxx_MDさん >えー・・・元々UMLはRationalの所有物だったわけで。 >UMLがモデリング言語として生き残ってきたことを考えると、 … (1) >改善されるかどうかは別次元だと思います。 … (2) 私は確かに「UML」という名称を挙げています。 しかし、私が問題として提起している中での概念は 「ドメイン空間」 「ソフトウエア空間」 「構造(代数)」 「プロパティ(メソッド)」 程度しかありません。 要するに、私が問題にしているのは、 「モデリング」を支える基本に対するものだ という事をご理解下さい。 私は、「UML」、「Rational」等とは関係ない世界で問題を考えている訳です。 それから、 (1)から(2)を結論付けていますが、 この流れが意味を持つと考えている事自体が理解出来ません。 例示された内容で言うと、重要なのは 本質的な間違いが修正されない -> 使い物にならない -> 生き残れない という事ではないでしょうか? >おそらく、複数の実装言語を扱いつつ単一のモデリングを元にする作業を >実践している人が少ないから、あえて統一せず、実装言語にあわせて >ローカルルールで記述する方がいいのではないでしょうか。 上の説明で理解出来る様に、 私は、「オブジェクト指向モデリング」そのものを問題にしている訳です。 従って、ローカルルール等で対処出来る表面的な内容を問題にしている訳ではありません。 #例えば「Java」に対して #「ソフトウエア空間の代数構造に欠陥がある」 #と書きましたが、これが「オブジェクト指向」つまり、 #「ドメイン空間」をベースに考えないのであれば、これらは欠陥ではなくなると思います。 >(UMLによる)モデリングはあくまで設計手法の一つにすぎないですし、 >UMLだけを使って設計を行うことはありえません。 >「HowTo」なくしてUMLを論じようというのは現実的では無いですし、 … (1) >UMLが単体で意味するものは学術的なメタファでしかないのです。 ここでも、私が問題にしているのは、 「モデリング」そのものだ という事でご理解下さい。 #私が問題にしているのは、「情報・振舞」という「オブジェクト指向の基本カテゴリ」です。 #「UML」に依存した何かをベースに考えている訳ではありません。 (1)は、表現している内容が曖昧ですが、恐らく正しくないと私は思います。 「zaxx_MD」さんは、「プロパティ」の構造的な意味がまだ分かっていないんだと思います。 それから、私たちの認識は、思わぬ所で前提とされているものがあったりします。 今回の場合、この「HowTo」の多くのを部分を支えているのが私の言う「代数構造」だと思います。 >オブジェクト指向設計全体を見たとき、メタファとしてUMLは不十分でしょうか? 重要なのは構造であり、全く不十分だと思うからこそ、今回、思い余って問題提起した訳です。 「構造化プログラム」でもそうでしたが、ソフトウエア科学で「構造主義的構造」が問題にされた事はあるのでしょうか? 恐らく、今のままで行くと、将来「ビジネスモデル」等で複雑になって来ると表現力その他で問題がもっと出るのではないでしょうか? >図示できない設計情報を無理やり図示すべきではないし、 >必要以上の詳細化は硬直してしまい、実装言語で二重の定義をしてしまうことに >なり設計上の矛盾を生じさせる原因になる可能性が高いと思います。 恐らく「私が主張している内容」を余り良く理解されていないんだと思います。 勿論、私は「図示できない設計情報を無理やり図示すべき」と言っている訳ではありません。 逆に、現在のモデリング言語で 図示できない設計情報 -> 重要でない情報 と構造的に言えるのでしょうか? 寧ろ、「具体的な実装言語」に依存した形で表現上での問題が生じているのが現在の状況ではないでしょうか? >いきなりの横槍でマトはずしてたらごめんなさい。 いいえ、zaxx_MDさんが真面目に考えて下さっているのは伝わって来ますから、大丈夫です。 >#元Rationalの人曰く、「UMLは情報交換の道具でしかない」だそうです。 私は、 「その道具が道具としての要件を満たしていない」 という事を言っている積もりです。 モデルと言語の間の概念は、「モデリング言語(手法)」がシッカリ整理する必要があるのではないでしょうか? 最後に少し異なる視点で、問題点を説明します。 オブジェクト指向で 「ドメイン空間」上の対象を「ソフトウエア空間」で表現する場合、 「ドメイン空間」と「ソフトウエア空間」が全く同じ構造であれば全然問題は無いですよね。 #これが理想です。 しかし、 「ドメイン空間」と「ソフトウエア空間」の構造が異なる場合、どちらを基準にしますか? 「オブジェクト指向」は 「ドメイン空間(オブジェクト)」を基準にしろ -> 「オブジェクト指向(目指す)」 と言っている訳です。 そして、私は、 旧来の「ソフトウエア空間」を「ドメイン空間」を基準に再構築して 「ソフトウエア空間をドメイン空間と同じ構造」にする必要があると言っている訳です。 #「ソフトウエア空間」と「ドメイン空間」の基本構造が異なっているという認識がベースにあります。 #そして、それが「プロパティ」に代表される概念の変更である訳です。 [ メッセージ編集済み 編集者: object 編集日時 2005-01-20 15:04 ] | ||||||||||||||||
|
投稿日時: 2005-01-20 13:21
objectです。
>るばんさん >zaxx_MDさんのご指摘は的を射ていると考えています。 zaxx_MDさんへのレスをご覧下さい。 >スタンスとしては有りと考えています。 >個人的な見解を述べれば、活動に加わって問題点を指摘していけばよいのではないかと思います。 これは、どういう「スタンス」か理解した上での発言でしょうか? 理解されているのであれば、具体的に確認させて下さい。 #スタンスの内容の要約を示して下さい。 それから、私もその様な活動に出来れば加わりたいのですが、私の会社は小さいですから、私が他の事をすると飯が食えません。 #実は、ここでの発言も、そんなに余裕があって行っている訳では無いのを理解して下さい。 >もしくは、UMLをベースとした新しい図解言語を「日本発」で使用を取りまとめていくぐらいの気概があればよいのではないでしょうか? そうですね、具体的な構想もありますから、出来るなら「構造」をベースに「モデリング言語」を考えても良いんですが、今は食べるので精一杯ですね。 申し訳ありません。 #でも、恐らく片手間で尚且つ一人で作業を行っても、そう簡単には完成出来ないんでしょうね。 #現状の「UML」を考えた場合、各種デザインパターンを「UML」を使って表記しても、その本質が #的確に表現されていると思えないのは私だけでしょうか? #しかし、「.NET」の「プロパティ」の位置付けが未だに全くなされないというのは異常ではないでしょうか? #それとも何処かでなされているんでしょうか? >使用を取りまとめてる連中からすれば、 >「問題意識はわかった。だったら提案してくれ。」 >と言うことではないかと思います。 それでは、「プロパティ」に関する動きはどう理解すれば良いんでしょうね? #これは、るばんさんの勝手な想像? それから、私は他の所で、少し具体的な提案をしているんですが、分からなかったでしょうか? #確かに、全ての情報を明記している訳ではありませんが。 #見る人がみると、かなり分かる程度の提案にはなってると私は思っています。 >XMLのParserのDOM方式が出てきた際にSAX方式を取りまとめたようなことを考えるのはいかがでしょうか? この例と、私の提案に於いて、どういう部分に共通性があるのか、具体的に説明をお願いします。 それから、るばんさんは、私の提案の意味は、理解されていますか? 出来れば、るばんさんの言葉で示して下さい。 #そして、それをベースとした議論をしましょう。 >全部の言語をTOTALでサポートするのは個人的におろかだと思います。 >UMLの本質がわかっていれば属性に関しては >PropertyでもAttributeでも良いと思います。 るばんさん、 「全部の言語をTOTALでサポートする」 という表現に、今迄の他の議論(抽象化)と同じ問題が矢張り見え隠れしますね。 #「言語に依存しない」事は無理ですか? 分かりました。 るばんさんは「UMLの本質」が分かっていらっしゃる様なので、 その本質を簡単で良いですから、要約して下さい。 #これも議論のベースに加味します。 それから、属性に関して、 「Property」と「Attribute」の本質(定義) を、るばんさんの主旨での具体的な説明を示して頂けませんか? #これも議論のベースに加味します。 >個人的にはUMLは仕様書を理解することを助ける道具と言う風に考えております。 これは「仕様書」が既に存在して、それを補助するのが「UML」と仰っている訳でしょうか? また、「助ける道具」とは「どういう意味で」助けるのでしょうか? 「UML」は言語ですよ? その「言語」を「理解することを助ける道具」と言い替えて、何が変わると思っていらっしゃるんでしょう? 気持ちとして分からない事は無いですが、ただ単に問題を複雑にしている事にはならないのでしょうか? >開米さんの「図解言語」(アイデアクラフト)もUML以上に有効なシチュエーションがある・・・ぐらいに考えています。 私は、具体的に言えば、 「ドメイン空間」と「ソフトウエア空間」との「準同型」を考えています。 るばんさんは、「実行処理系をモデルとして構築するUML」と「図解言語」を同じレベルで考えておられるんでしょうか? >日本語も外国語もそうだと思いますが、 >「定義」が最初にあって話し始めたわけではないわけですし、 >恐らく、言語と名のつくものは進化していくのではないでしょうか? 何が仰りたいのか不明です。 「定義」が最初にあって という部分は何処かでみた表現ですが、 私が焦点にしている「構造」に対する「誤解」ではないでしょうか? [ メッセージ編集済み 編集者: object 編集日時 2005-01-20 13:27 ] | ||||||||||||||||
|
投稿日時: 2005-01-20 13:49
るぱんです
正直、もったいないですね。 テーマとしては申し分ないのですが、言葉を変えすぎていると感じています。 もっと明示的に説明して頂く事ができれば論点がかなり整理されると思います。 オブジェクトに対するプロパティの構造が既に問題だ・・・と言う印象で受けておりますが、間違ってますか? たとえて言うならば、トップダウンで一意に決まる・・・と言う発想に対して、 ボトムアップで決まっているものに対して途中の階層が名称を変えると言う構造もとりうるのではないか・・・? こういういことが言いたいのかな?と感じましたが、明示的でないので 論点にあげるのを避けております。 その点を考慮してメッセージを返したつもりです。 現在のモデリング手法が問題である・・・のならば、活動に参加してみたらいかがですか?・・・としか言えなかったんです。 間違っているのであればご指摘のほどお願いいたします。 | ||||||||||||||||
|
投稿日時: 2005-01-20 14:08
そっすね、UMLはソフトウェア構築のあるシーンで 他の人とコミュニケーションする手段として有用であると 認める人がある程度多くいるから生き残ってきたのだと思います。
プロパティはオブジェクトの属性、 つまりオブジェクトの中の(属性)オブジェクトに すぎないんですけど。 ドメイン空間で統一されたプロパティを引用しなければならないというのは リアルな世界では成り立ちません。 袋で買ってきたりんごの一つ一つの赤が全て違い、 ワインの赤とも違うことが統一的なかつ画一的な定義が無意味であることと 一緒だと思います。あなたの赤は油絵の絵の具の赤ですか?
そんなこといってません。むしろ クライアントなどとのコミュニケーションシートなど 図示できない設計情報が一番重要です。 そういうシートを何語で書くかも結構重要で、 英語で記述するのがソフトウェア構築と相性が良いかもしれません。 でも、アメリカの古い設計資料(コミシ)を見せてもらったとき、 あまりにも雑然と単語が並んでいて図示がなく、 驚いたこともあります。
そおですか?知りませんでした。 私はてっきり、リアルな現象に対するモデリングをした結果 自然とドメイン空間が定義されていくものだと思っています。 設計資料を基にコードを書くときは、リアルな現象を意識せず、 ソフトウェアのルールに従ったドメイン空間に沿ってコードを 書くべきだと思っています。 [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-01-20 14:11 ] | ||||||||||||||||
|
投稿日時: 2005-01-20 14:15
るぱんさんとObjectさんのやり取りの文章を 読むことがつらいです。というか無理。 なのでフォローできません。ごめんなさい。 |