「UML」を初めとする現在の「モデリング言語(手法)」の問題点は？

投稿者

投稿内容

るぱん: ぬし; 会議室デビュー日: 2003/08/01; 投稿数: 1370

投稿日時: 2005-01-26 14:12

るぱんです。

補足します。
僕は僕なりにモデリングに対して
「このままでいいのか？」
と言う思いはあります。

それが先走った「トップダウン一意」と言う発言につながるのですが、
スレ主さんと恐らく違う観点で見ていることと思います。

そのために敢えて主題の明示は避けました。

問題提起したのはスレ主なのですから、
僕の一方的な思いで終わるわけにも行きません。

というわけで、
「議題：議論として取り上げたい事象」の明示化をお願いする次第です。

■さらに補足■
XMLにおけるDOMとSAXの例は、
W3CでDOMが議論されている際に、使用の詰めの最中にSAXが完成してた比喩を用いています。
その意味したところは、
「モデリングにおいてはOMCが本流かもしれない。でも、こだわりのある亜流を作ってもいいのではないか？」
そういう気持ちも持っているので、
それをやるなら加担するつもりがある・・・という発言です。
別にスレ主に対してネタ振ってそれで終わりにする気はさらさらありません。

未記人: ベテラン; 会議室デビュー日: 2004/08/21; 投稿数: 70

投稿日時: 2005-01-26 15:07

o氏の主張は大きく分けて二つですかね。
1)
・構造主義と代数学こそがオブジェクト指向、ひいてはソフトウェア開発の概念的基盤である。
・それが体感できない人間は勉強が足りないので構造主義と代数学を自分で学べ。私には愚かなる大衆をアジテーションする暇はあっても、内容や根拠を説明する余裕はない。

2)
・Javaは邪教であり.NETこそが解脱への道である。世の中が、JavaとUMLとそれにまつわるUPその他の方法論が主流である(ように見える)のは許せない。
・例えばプロパティというものは正しい存在である。何故なら.NETにある全ての実装要素は、オブジェクト指向の正しい理念の体現だからである。
・.NETにある全ての実装要素は、オブジェクト指向の正しい理念なのだから、JavaもUMLも.NETの要素をそのまま表現できるよう変化する事が、正しいオブジェクト指向への道である。

基本的に議論と言うより布教に感じます。
一方的に主張するだけで、根拠を示したり相手の論を受け入れたりはなさらないですし。

らぶま: 常連さん; 会議室デビュー日: 2004/10/21; 投稿数: 32

投稿日時: 2005-01-26 15:48

通りすがりです。
実は重要な議論である気がしてきました。

ただ、objectさんと他の方の議論がかみ合ってないようですね。
まずは言葉の整理が必要なんじゃないでしょうか。
「ドメイン空間」
「ソフトウエア空間」
「構造(代数)」
「プロパティ・メソッド」
とは何のことなんでしょうか？>objectさん

ここから独り言:
objectさんの言いたいことってこうかな。

現実世界をソフトウェアに置き換えるのに、以下の過程を経るはずである。
「現実世界」→「ドメイン空間」→「ソフトウェア空間」

ここで、
「ドメイン空間」：モデリングの結果(UMLの図とか)
「ソフトウエア空間」：プログラム(Javaのソースとか)
「現実世界」→「ドメイン空間」：モデリング
「ドメイン空間」→「ソフトウェア空間」:プログラミング言語による実装
である。

「ドメイン空間」＝「ソフトウェア空間」なら何も問題ないが、現実的には
「ドメイン空間」≠「ソフトウェア空間」である。

よって、プログラミング言語に依存しないモデリングを行うためには、
「ドメイン空間」と「ソフトウェア空間」とは互いに独立していなければならない。

ところが、ＵＭＬに代表されるモデリング言語(手法)は
一部のプログラミング言語(Javaとか)に偏った仕様(構造)であり、
上記の独立性を損なうものである。

したがって、新たな方法論を模索してみませんか?

違ってたらすいません・・

zaxx_MD: 大ベテラン; 会議室デビュー日: 2003/04/21; 投稿数: 204; お住まい・勤務地: 千葉県柏市

投稿日時: 2005-01-26 16:00

引用:
未記人さんの書き込み (2005-01-26 15:07) より: アジテーション

Agitation
扇動

引用:
UP

(Rational) Unified Process

製品としてのRUP

＃Rationalの実装言語の歴史としては SmallTalk > C++ > Java|C# という
＃遷移を経ており、Java1.1.8以前の時代では旧Rational製品との乖離が混乱を呼び
＃問題になったこともある。

引用:
.NET

[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-26 16:09 ]

[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-26 16:12 ]

nak2k: ベテラン; 会議室デビュー日: 2003/07/17; 投稿数: 86

投稿日時: 2005-01-27 02:11

ここの議論をみてて思いついたことなどを走り書き的にメモしていたので、
それらをとりあえず見れる形にまとめてみました。
まだまだ他人に見てもらう文章としては推敲不足ではありますが、
とりあえず投稿してみます。

コード:

ドメイン空間       ソフトウェア空間
                    （DotNET）
+----------+      +----------+
| Behavior | ---> | Method   | --+
+----------+      +----------+   |
| State    | ---> | Property | --+
+----------+      +----------+   |
                  | Field    | <-+
                  +----------+

ドメイン空間       ソフトウェア空間
                    （Java）
+----------+      +----------+
| Behavior | -+-> | Method   | --+
+----------+  |   +----------+   |
| State    | -+   | Field    | <-+
+----------+      +----------+

ドメイン空間においてstateは常にpublic（なぜなら”認識可能な状態”を抽出したものだから）。
fieldは（実装上必要ってだけなので）ソフトウェア空間にしか存在せず、さらに常にprivateであるべき。

State---Field のマッピング関係が成立しないのは、派生属性のことを考えれば一目瞭然。

ドメイン空間から見た場合、ソフトウェア空間に存在する
実装上のみ必要な情報には興味がないので、表記を少し変えてみる。

コード:

ドメイン空間       ソフトウェア空間
                    （DotNET）
+----------+      +----------+---------+
| Behavior | ---> | Method   |         |
+----------+      +----------+  Field  |
| State    | ---> | Property |         |
+----------+      +----------+---------+

ドメイン空間       ソフトウェア空間
                    （Java）
+----------+      +----------+---------+
| Behavior | -+-> |          |         |
+----------+  |   | Method   |  Field  |
| State    | -+   |          |         |
+----------+      +----------+---------+

左右に分けた箱について左側だけを見ると、

引用:
本当はこの時点で「オブジェクト指向」である為の要件「情報・振舞」を満たさなくなるんですが、それは「棚に上げしている」様です。 #つまり、厳密に言えば、「Java」は「オブジェクト指向言語」ではありません。

これに対応？

ドメイン空間の要素（Behavior、State）に対して、
ソフトウェア空間で各言語の対応する言語要素とのマッピングを考えると
Javaでは言語要素レベルではドメイン空間に２つの要素があることを意識していない。
Stateについては、Methodの中でもアクセサーメソッドと呼ばれるもので代用している。

MethodについてBehaviorに対応するものとStateに対応するものがあることを
Java使用者が意識しながらやれば問題ないと言えなくもないが、そうではなく
その区別を言語レベルで取り込んだのがDotNETの有利な点だと思える。
（DotNET言語使用者はその意識を持つ段階に到達しやすい？）

Stateに属性をつけることも考えると、State-Propertyは1:1だから問題ないとして、
State-Methodでは1:2になることが気になる。
（getterとsetterに同じアノテーションを付ける？）

DotNETにおけるinterfaceが、propertyも宣言可能な理由は、
「propertyの実体がメソッドだから」というよりは、
「ドメイン空間のオブジェクトとマッピングがとれるから」と考えたほうが
より適切に思える。

さらに拡張。

コード:

ドメイン空間       ソフトウェア空間
                    （DotNET）
+----------+      +-----------+---------+
| Behavior | ---> | +Method   | -Method |
+----------+      +-----------+---------+
| State    | ---> | +Property | -Field  |
+----------+      +-----------+---------+

左側がpublicで右側がprivate。
分析レイヤーのクラス図、実装レイヤーのクラス図などと分けて考えず、
実装レイヤーのクラス図から右側を非表示にするだけで
分析レイヤーのクラス図になる……といいなぁ。

さらに別の図。

コード:
+-------+ +--------+ +----------+ \| Real \| -----> \| Domain \| <----- \| Software \| \| World \| (1) \| Model \| (2) \| Model \| +-------+ +--------+ +----------+

リアルに対してアーキテクトが関心事項以外を削ぎ落として
ドメインモデルを得られる(1)。
ソフトウェアモデルから実装要素を削ぎ落として
ドメインモデルを得られる(2)。

上記よりドメイン空間の要素は、リアル空間およびソフトウェア空間に対して
基本的（？）に１：１でマッピングできる要素があるべき。
成り立たない場合は、リアル⇒ドメインの抽出（帰納）に失敗しているか、
ドメイン⇒ソフトウェアの展開（演繹）に失敗しているかを疑う。

以上です。
ほんとまとまりなくて申し訳ない (^^;
反論意見含め、何か意見頂けたら幸いです。

るぱん: ぬし; 会議室デビュー日: 2003/08/01; 投稿数: 1370

投稿日時: 2005-01-27 08:58

るぱんです。

一部のfieldをpublicに指定してあげたら問題なくなるという話ですか？

nak2k: ベテラン; 会議室デビュー日: 2003/07/17; 投稿数: 86

投稿日時: 2005-01-27 11:19

たとえば、Windowについて考えたときに、観測可能な状態として
Left, Right, Width の３つを挙げることができますよね？
propertyの場合、観測可能な状態に１：１でマッピングをとればいいので
そのまま Left, Right, Width の３つのpropertyを定義できます。

でも、３つのpropertyを実装するにあたって必要なfieldは２つですよね。
残り一つは計算で求めれますし、そうすべきですから。（UMLの派生属性）

なので、fieldをpublicにしただけでは、観測可能な状態と
１：１マッピングがとれないという点で、表現力不足かなと感じます。

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

投稿日時: 2005-01-27 12:28

objectです。

>るぱんさん
>本題について思うところがあります。
>以前のやり方では納得していただけないようなので白紙に戻した状態で始めたいと　…　(1)
>思います。
(1)の表現は、どういう意味ですか？
私の最初のレス（投稿日時: 2005-01-19 18:48）に対する「私の確認」に全く答えず、
更に次のレス（投稿日時: 2005-01-20 13:49）に対する指摘を無視し、
今度は、
「私(object)が納得しないから白紙に戻す」
ですか？
「私が納得すべく出した質問」を、ことごとく無視したのは「るばんさん本人」ですよ？
結果的には、るぱんさんが「レス」出来なかったのでは無いでしょうか？
もし、そうで無いなら、「それなりの内容のレス」があって然るべきだと思います。
#またまたまたまた、自分自身を誤魔化すんですか？
#「ふくちゃんさん」がたてたスレ「件名：考えるとは」をもう一度冷静に読まれ、反省された方が良いと私は思います。

>まず、議論の対象となる論点を明示して頂けますでしょうか？
>参照があるのであれば、
>どのスレッドのどのコメントの部分か御教示願います。
>「何を議題にあげたいのか？」
>と言う部分です。
>モデリングに対して問題点がある・・・という主張は明確に受け取りました。
>その上で、
>１．「何が」問題なのか
>２．「どのように」問題なのか
>３．「それはなぜ」問題なのか
>を明確に受け取ってから議論に加わろうと思います。
論点は既に明示しています。
#事実かなり理解されている人も既におられます。
あなたは、言いたい事を、言いたい様に言っておきながら、私の質問には全く答えず、私がだけがあなたに、ヒタスラ答えろと仰ってる訳ですか？
全く、開いた口が塞がりません！

あなたは、全く理解していないにもかかわらず、
投稿日時: 2005-01-20 13:49
投稿日時: 2005-01-19 18:48
のレス(http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=18279&forum=25&30)
を私に書いた訳ですか？

あなたは、既に議論に加わっているんです！
その無責任さを反省すべきだと思います。
#これに関して、何かレスを頂き納得出来る迄、直接的な対話は致しません。

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

「UML」を初めとする現在の「モデリング言語(手法)」の問題点は？

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