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

«前のページへ 15|16|17|18|19|20|21|22|23|24|25 次のページへ»

投稿者

投稿内容

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

投稿日時: 2005-02-04 00:14

異論・反論ではなく確認なのですが、本田＠スミテムさんの投稿と
objectさんの示されたスレッドの内容より、以下のような認識を
持ったのですがいかがでしょうか？

・「写像」は「集合」間の制約条件である。
・「アルゴリズム」は「データ」間の制約条件である。
・「振る舞い」は「情報」間の制約条件である。

今まで「振る舞いは振る舞い、情報は情報」と、ただ知覚するままに
独立して扱ってきましたが、それは「安易な認識」というわけですね。

本田＠スミテム: 常連さん; 会議室デビュー日: 2004/01/22; 投稿数: 21; お住まい・勤務地: 東京

投稿日時: 2005-02-04 00:51

引用:

k-nakさんの書き込み (2005-02-04 00:14) より:
異論・反論ではなく確認なのですが、本田＠スミテムさんの投稿と
objectさんの示されたスレッドの内容より、以下のような認識を
持ったのですがいかがでしょうか？

・「写像」は「集合」間の制約条件である。
・「アルゴリズム」は「データ」間の制約条件である。
・「振る舞い」は「情報」間の制約条件である。

少なくとも私はそのように判断しています。

「情報」なくして「振舞」はありえず、「振舞」の主体は「情報」である。
「集合」なくして「写像」はありえず、「写像」の主体は「集合」である。

という認識です。

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

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

レスありがとうございます。
認識が同じであることが確認できて安心しました。

となると、こちらの考えもいけるかな…？

ここで「振る舞い」は上記の内容でいいと仮定して、では「情報」とは何か、
と考えたとき、以下につながりそうです。

引用:

objectさんの書き込み (2005-01-28 11:31) より:
例えば、「量」を扱う場合、「加法的な量」と「加法的で無い量」が出て来ます。
この「加法的で無い量」は、「加法的な量」を扱う中で、「必ず必要になって来る量」です。
そして、
「加法的で無い量」＝「機能的な量(内包量・示強量)」
です。
具体的には、「温度」なんかがあります。

・「？？？」は「量」間の制約条件である。
# 「？？？」に該当する言葉が私には分かりません。そのまま加法？

上記は「振る舞い・情報」をミクロ側にみた場合の話で、
マクロ側にみた時には、「振る舞い・情報」からなる「オブジェクト」がありますから、

・「関連」は「オブジェクト」間の制約条件である。

あたりになりそうかな、と。
# もう少しじっくり考える必要も感じてますが。

上記のミクロ側、マクロ側、ともに対構造であり、

引用:
本田＠スミテムさんの書き込み (2005-02-03 21:06) より: 「集合、写像」は、モノの構造を認識するときの基本フレーム

に合致しそうです。

あとはobjectさんの帰還を待ちます。

[日本語修正]

[ メッセージ編集済み編集者: k-nak 編集日時 2005-02-04 01:34 ]

永井和彦: ぬし; 会議室デビュー日: 2002/07/03; 投稿数: 276; お住まい・勤務地: 東京都

投稿日時: 2005-02-04 10:14

難しいことはさておいて、図自体の話に関して。

引用:
199356さんの書き込み(2005-02-03 22:26)より: 私はドメインモデルと設計モデルと実装モデルで揺れがあるのは当たり前だと思ってるので、何とも感じませんが。上流から下流までシームレスなんてまだ夢物語。

完全シームレスはまだまだ先かな……とは思いますが、k-nakさんのUML#(仮称)は上と下を繋ぐヒントを持っていると感じています。

「実装者が書くところ」と「分析者が書くところ」が明確に領域として分けられていて、かつ一図面上で明確に関連付いているというのは図面利用する上で非常にいい特性だと思います。
＃実装者が分析者の領域を書き直したくなった場合、それは2人の間で何らかの認識違い、もしくは見落とし等があって協議する必要があることを意味するはずです

＜余談＞
まあ、この特性によって逆に「今まで末端がうまくやりくりしていたor誤魔化していた諸々の問題点」が全部表面化して工程がストップしたりと愉快な状態になったりするかも知れませんが
＜/余談＞

引用:

るぱんさんの書き込み (2005-02-03 20:07) より:
１に対しての認識
UMLはツールである。
属性であるか操作であるかは定義してから始めれば良いと思う。

反例：最初に属性として定義していたが、振る舞いであったことに気が付いた場合はどうするべきか？

→リファクタリングするべきなのでは無いでしょうか？

当初の認識が間違っていると気付いた(/感じた)のであれば、当然それは修正検討の対象になります。ここでUML#(仮称)の利点の一つは「対象が誰か」が図面上明白であることだと思います。

(分析者と別人である)実装者が気付いた場合、左(公開)領域なら分析者に話を持っていかなければいけません。右(隠蔽)領域なら自分で勝手に修正して問題無いです。なぜならば左領域は分析者の領域で、右領域は実装者の領域だからです。

勿論、現行UMLでのこの切り分けは可能です。+が付いてるものを修正したければ分析者に、-のものだけであれば実装者だけで……という具合にです。
ただ、「自分だったら大丈夫かなー。+付いてても思わず相談無しで修正しちゃわないかなー」と考えたとき、不安が残ります。
何でもかんでも運用でカバーするでもいいんですが、線一本加えて(ちょっとした工夫で)明確に出来るなら加えたらいいのではないか、と。
＃まあ、やり過ぎると柔軟性が足りなくなったり、複雑になり過ぎたり等で「使えない」モノになっちゃうでしょうけれど

簡単な疑問なんですが、るぱんさんの中ではUMLの書式自体はリファクタリング対象にならないのですか？

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

投稿日時: 2005-02-04 12:30

引用:
永井和彦さんの書き込み (2005-02-04 10:14) より: 簡単な疑問なんですが、るぱんさんの中ではUMLの書式自体はリファクタリング対象にならないのですか？

なります。
しかし、UMLを深くまでのぞいたら・・・かな？
自分にその経験が希薄であると認識している以上、
UMLが悪い！と言うのは＝使いこなせませんでした
なのではないかと思います。

あと、分析者と実装者の両方から使って使いにくいと言う印象を受けていないからなんですが、
UMLに修正を加えるのであれば、
両方の視点が必要になると思っています。

片側から「これが必要だ！」と言うのは、
もう片方にとっては「いらねーよ」ってな物では困りますし。

そこまでたどり着いた上での議論なのかどうかに疑問符がついている状態です。
[編集]
UMLに概念として
１．Propertyと言う概念を盛り込みたい
２．Functionと言う概念を盛り込みたい

盛り込んだときの
分析者にとってのメリット・デメリット
実装者にとってのメリット・デメリット
が整理されていないのではないかと。

僕の捉え方では、
やりようによっては現在の方式の亜流の１バージョンとして処理できる
と言う判断が働いています。

わざわざ作成するのですから、
そのメリットが大きいなら僕は賛同します。
メリットが小さいという認識ですので現在は反対しております。
[/編集]

[ メッセージ編集済み編集者: るぱん編集日時 2005-02-04 12:39 ]

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

投稿日時: 2005-02-04 12:46

なんだか拡散してきましたね。

引用:

未記人さんの書き込み (2005-02-03 18:10) より:
引用:

zaxx_MDさんの書き込み (2005-02-03 16:45) より:
　メタファとして、functionという考え方は
オブジェクト指向分析そのものを否定するものだと思う。

とりあえず、CLOSとかSchemeとかで遊んでみて、functional programming ってものに触れてみてください。

何が言いたいのか論点がわかりません。
LISPについては１０年以上前に学校の科目でやりましたけど、
そこそこの理解度はあると思います。

functional programmingとOOAが関係あるんですか？

誤字修正。

[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-02-04 12:48 ]

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

投稿日時: 2005-02-04 12:48

objectです。

>H2さん
先ずは、レスがかなり遅くなってしまった事をお詫びします。
#また、みなさんには、時系列的な意味で、大変理解し難いレスになっている事をお詫びします。

私はレス(投稿日時: 2005-02-01 18:43)
-------------------------
H2さんは「基本的な特徴の一つ」という表現で、「オブジェクト指向」と「抽象データ型」の関係を少し曖昧にしていますが、
これは、「オブジェクト指向」で最も重要な特徴が「抽象データ型」だと言う意味でしょうか？
もしそうで無いとしたら、
「オブジェクト指向」で最も重要な特徴は、一体何だとお考えでしょうか？
-------------------------
の中で
「H2さんは「基本的な特徴の一つ」という表現で、「オブジェクト指向」と「抽象データ型」の関係を少し曖昧にしていますが」
と書いています。
これは、
「H2さんが(意識的に)曖昧にしている」
という意味ではなく
「H2さんの文章の中では、明確にはなっていない」
という主旨です。
もし、気分を害されたのであれば、お詫び致します。

>#この質問をされると議題がモデリング手法からオブジェクト指向とはになってしまいますよ？質問されたので答えますが
要するに私がここで述べているのは、
「モデリング手法」の問題は、実は現在の「オブジェクト指向」の問題である
という事ですのでご了承下さい。

私も基本的には
「オブジェクト指向のベースは抽象データ型である」
と思っています。

H2さんは、
「オブジェクト指向とは、継承と多相という機能がついている抽象データ、つまりオブジェクトとオブジェクトの複合体により物事を表現する概念」
と書いておられますが、
それでは、
「オブジェクト指向(Object-Oriented)」
という表現の意味は何でしょうか？
結果的には、
「抽象データ＋継承と多相」…　(1)
を意味するという事でしょうか？
また、
H2さんが書かれている「物事」とは「どういう意味で何を指す」のでしょうか？

最後に、
「オブジェクト指向(Object-Oriented)」は、「パラダイムシフト」とも言われますが、
(1)からどの様な経緯で「パラダイムシフト」という概念に繋がるのでしょうか？

ラフィン: ぬし; 会議室デビュー日: 2002/05/23; 投稿数: 809; お住まい・勤務地: 外野

投稿日時: 2005-02-04 12:52

引用:
るぱんさんの書き込み (2005-02-04 12:30) より: UMLが悪い！と言うのは＝使いこなせませんでしたなのではないかと思います。

　．．ではないと思います。

　理論や言語等を深く掘り下げてスキルアップしていくことはよいことと思いますが、あくまでそれらの枠内にとどまるか拡げていくかはまた別の話しかと思います。このスレッドは枠を拡げようって話じゃないですかね？
　文字として表れるものでものでなく姿勢のレベルであっていないと話は通じないと思います。

　で、かなり前の書き込みになってしまっていますが、プロパティとフィールドの違いは
・プロパティ：私の知っているるばんさん
・フィールド：るばんさんも知らない本当のるばんさん
っていうのはどうです？

«前のページへ 15|16|17|18|19|20|21|22|23|24|25 次のページへ»

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

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