@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

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

投稿者投稿内容
らぶま
常連さん
会議室デビュー日: 2004/10/21
投稿数: 32
投稿日時: 2005-01-28 19:04
k-nakさんの考えを踏まえて、
しつこくobjectさんにお尋ねしますが。
こういうことですか?

現実:
{情報, 振る舞い}⊂「ドメイン空間」
{フィールド, メソッド}⊂「ソフトウェア空間」
通常ソフトウェアを開発する場合は、
情報→フィールド, 振る舞い→メソッド
とマッピング(設計・実装・写像)する。

ところが、本当は

{情報, 振る舞い, 情報∩振る舞い, 情報∪振る舞い}⊂「ドメイン空間」
であり、
情報∪振る舞い は.NETのプロパティや可視性により解決可能だが、
情報∩振る舞い はそれを満たす構造そのものが存在しない。

そこで、メソッドを拡張した「ファンクション」を定義・導入することにより、
情報∩振る舞い の解決を図ろう。
または、情報∩振る舞い に相当する表現技法が必要なのでは?

したがって、本来あるべき姿:
{情報, 振る舞い, 情報∩振る舞い, 情報∪振る舞い}⊂「ドメイン空間」
{プロパティ, ファンクション}⊂「ソフトウェア空間」

ここでいう 情報∩振る舞い とは、
値が一意に定まった瞬間に振る舞いも一意に定まるもの
ということ。
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2005-01-28 19:37
みなさんの投稿でようやく本筋が読めてきました。
(理解できたかどうかは定かではないですが)

 仮にオブジェクト中の要素に影響を与えないメソッドをfunctionと呼ぶならば、
オブジェクトの粒度を下げればUMLで明示的な書き方ができると思います、

 つまり、フィールドもプロパティも存在しないクラスのメソッドは
内在する要素に影響を与えないという意味で、functionということですね。
 
 実際にこういうクラス定義をよく見ていました。
Actionクラスから共通化できる処理を切り出して、
functionメソッドしか存在しないクラス定義を行っている、
実にアルゴリズムな昔かたぎのプログラミング手法です。

 しかし、逆説的ですがfunctionは推奨できるモデリング要素とは言えないのでは
ないでしょうか。

 GoFのデザインパターンなどのように、プログラムのドメイン空間では有用ですが、
リアルのドメイン空間では不自然な気がします。

[ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-01-28 19:40 ]

 とダラダラ書いてしまいましたが、
すでに結論が出ているように感じます。

「オブジェクトの内在要素にステレオタイプを付けること」
そしてコレはUMLには定義されていない(ホント?)が、
.NETの内部的に使われていることから
UMLの次の仕様に盛り込むべき

・・・かもしれない。ということですね。

[ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-01-28 19:42 ]

ですが、やはり私はこういう拡張を好みません。
そこまで詳細にオブジェクトを定義するよりは、
おなじ工数を掛けてユーザ視点の
結合テスト仕様書を複数書いたほうが
(そのテストが実施されたかどうかにかかわらず)
遥かにプログラムの精度を上げられると思います。


[ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-01-28 19:49 ]
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2005-01-28 19:50
るぱんです。

本人不在で話を進めても、推測の域をでていないと思います。
1.問題が本当に核心をついているかスレ主に確認を取る
2.もし仮に、1が正解だとするならば話の本質をあっているか更に確認を重ねる。
3.2の場合で違っていた場合は更に議論を巻き戻して更に議論を重ねる

と言う手戻りが発生しやすい状態になっております。
皆様はいかがお考えでしょうか?
nak2k
ベテラン
会議室デビュー日: 2003/07/17
投稿数: 86
投稿日時: 2005-01-28 21:42
るぱんさんの意見に同意します。
なんというか、本当に議論がかみあってなかった気がします。。。
(今、色々と読み返しているとこです)

[不要部分削除&日本語修正]

[ メッセージ編集済み 編集者: k-nak 編集日時 2005-01-28 23:31 ]
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2005-01-28 22:17
引用:

るぱんさんの書き込み (2005-01-28 19:50) より:
本人不在で話を進めても、推測の域をでていないと思います。
皆様はいかがお考えでしょうか?


皆さんがobjectさんと議論をしたいならば、るぱんさんの仰る通りでしょうね。
他の方が何のキーワードに魅了を感じて投稿されたのかは解りませんが
私はobjectさんの話を理解出来ませんでしたし、基礎学力が無いので
objectさんが議論したい事について参加出来ないと考えています。

しかし、他の方が話をしている事に関して私の中に疑問が発生し、
自己解決出来なかったのでアドバイスを求め投稿致した次第です。


余計なお節介でしょうが、

もし、るぱんさんがobjectさんと議論をしたいならば
るぱんさんにとって、るぱんさんが主体と成るように
動いた方が宜しくありませんか?


一般的な議題では無く参照情報(記事)も無い状態で
問題提起をし議論出来る環境状態に持ち込むには相当骨が折れるモノです。
もしスレ主がそれを知らずして戦術も立てず始めた議論であれば、
現在の状況は成るようにして成っただけ思います。

そして周囲もスレ主が持つ関心事に関して議論をしたいのであれば
問題提起から議論始めるまでの難しさを理解し
スレ主と共に努力をする必要があると思います。

つまり議論をする前準備工程の必要性を認識し
そして準備も無しに議論を急がぬ様注意する事が
私は大切だと思います。

過去、皆で他人の上げた議論スレを幾つも潰してきている訳ですから
そろそろ議論技法では無く、議論の始め方を考えた方がいいのでは?
と思いますよ。

以上、つまらん経験談からでした。
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2005-01-29 00:51
るぱんです。

>はにまる様
僕がUMLに対して思っているのはfieldの可視性とか、プロパティとかじゃないんですもん。(笑)
リファクタリングを早くするための手法だったり、
リファクタリングをしやすいUMLの使用法・・・みたいな所ですね。
自分の中で確立して無いからです。。
知る限り、リファクタリングの「これだ!」と言うパターンがそこまであるのかどうかすらわかってないのが原状なんですけどね。
そんなノウハウ蓄積してみたいですけど、
話がそれるので、保留w
永井和彦
ぬし
会議室デビュー日: 2002/07/03
投稿数: 276
お住まい・勤務地: 東京都
投稿日時: 2005-01-29 02:32
なんかスレッドの方は火が消えかかっているようで、完全に乗り遅れた感はありますが、どうしても言わずにいられなかったので一言だけ。

引用:

k-nakさんの書き込み (2005-01-27 02:11) より:
コード:
ドメイン空間       ソフトウェア空間
                    (DotNET)
+----------+      +-----------+---------+
| Behavior | ---> | +Method   | -Method |
+----------+      +-----------+---------+
| State    | ---> | +Property | -Field  |
+----------+      +-----------+---------+



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



この図を見られただけで個人的には大満足です。有り難うございました>k-nakさん
#図中の「(DotNET)」が不要な気がしたりはするのですが、まあ、それは置いておいて
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2005-01-29 14:25
objectです。

>ALL
今日、みなさんの真剣なレスを拝見し、とても驚きました。
私は、ここでの議論を殆ど諦めてましたから、とても嬉しかったです。
有難う御座います。

それから、みなさんにそれぞれ対話的にレスする事は無理だと思います。
それで、みなさんの意見を最終的に集約されていると思う、「らぶまさん」のレスに沿って
重要と思われる部分を、今までより少し詳しく整理してみました。

===================
現在の状況
全体の関係:
「ドメイン空間」⊂「リアル空間」
「ドメイン空間」→「ソフトウェア空間」
#→:「ドメイン図」等で何らかの対応関係はあるが、「構造」的なものは余り意識されていない。
-------------------
内部の関係:
「ドメイン空間」={情報、振る舞い}
「ソフトウェア空間」 ={フィールド、メソッド=ファンクション}
「フィールド、ファンクション」に対して、「独立」なものとして考えている。
「ファンクション」の中では「フィールド」が使える。
「フィールド」は単独でしか使えない。
「フィールド、ファンクション」は、独立ではあるが、対等ではない。
===================
本来:
全体の関係:
「ドメイン空間1」⊂「リアル空間」
「ドメイン空間2」⊂「ソフトウェア空間」
「ドメイン空間1」⇒「ドメイン空間2」 …(1)
#⇒は、「ドメイン空間1」での重要な関係を「ドメイン空間2」でも成立させる様にする写像。
#最終的には、全く同じものも考えられるが、その場合はドメイン空間1,2間の制約が最も厳しくなる
#(1)は「ドメイン空間」と「ソフトウェア空間」は全く独立であるが、無関係では役に立たないので導入する。
#これによって、ドメイン空間1でのモデルが、ドメイン空間2でも成立し、
#ビジネスモデルは、ドメイン空間1でソフトウエア空間とは独立に発展させる事が出来る。
#また、⇒の内容によっては、「ソフトウエア空間」上での成果が殆ど直接的に「ドメイン空間」に反映出来る可能性がある。
-------------------
内部の関係:
「ドメイン空間」={情報、振る舞い}
「ソフトウェア空間」 ={プロパティ、メソッド}
プロパティ=f(フィールド、ファンクション):フィールドどファンクションを使って実現される
メソッド=g(フィールド、ファンクション):フィールドどファンクションを使って実現される
#特別な場合として「プロパティ=フィールド」となる場合がある。
===================
取り合えずですが、以上です。

[ メッセージ編集済み 編集者: object 編集日時 2005-01-30 04:13 ]

スキルアップ/キャリアアップ(JOB@IT)