＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「UML」を初めとする現在の「モデリング言語(手法)」の問題点は？
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-01-31 17:35
「他人に努力を求める前に自分のやり方変えた方がよいのでは?」という言葉自体が
他人（この場合objectさん）に努力を求めることになります。 いかなる時も他人に変化を求めるのは無理かと。。。 あと、何が普通かはおいておいて、それが許容できないのであれば、 このスレッドを立ち去るしかないと思います。 内容や論理のつなぎ方については、私のひとつ前の投稿にある 「復習」がお役に立てれば、、、と思います。 不愉快に感じられましたらすいません。 ただ、これ以上、議題についての話が進まないのをとめたかったので。。。 | ||||||||||||
|
投稿日時: 2005-01-31 17:59
ご理解頂けないようですので 言葉を変えて説明させていただきます。 １往復のPMの間に何が起きたかを推測して頂いているようですが、 挨拶程度です。 これからこうするので協力してね・・・という内容は記述していません。 話の流れから、談合があったかないかが焦点にあたっているんですよね？ 無いですと言う回答に対してご指摘は焦点から外れていると思います。 さらに、推測が当たれば・・・についてですが 論点がずれてますが・・・？ 推測が当たったときはしめしめ・・・でいいと思うんですね。 相手の姿勢云々は関係ないと思います。 相手に確認を取って論点を整理したうえで指摘すればよいことでは？ 言いたいことがたくさんあるようです。 いま少し整理していただけませんか？ | ||||||||||||
|
投稿日時: 2005-01-31 19:10
それは、あんたの胸の内一つでどうとでもなるのではないですか？
後、最初から仕様書が存在するとは限らん。 せやからリバースエンジニアリングで推測を交えながら、ソースから仕様書興したりする。 アプローチの方法として、必ず仕様書 -> コーディングという先入観からの発言かと お見受けするが、そもそも、今回その仕様はオープンにされていない。 だからこそ、推測するしかない。 論点は、そういう邪推の対象となる事が予測できておりながら、同じ行動に対して、何故 「自分に近い立場」の人間と、そうでない人間との間に温度差を作るのか。。。そこが 最大の焦点でしょうなぁ。 で、今度は整理ですか (ﾌﾟ | ||||||||||||
|
投稿日時: 2005-01-31 20:13
念のためお伺いします。 それはなぜですか？
何をさして仕様書で、何をさしてアプローチなのですか？ 温度差に関しては、理解いたしました。 作るつもりは毛頭ないです。 結果としてできてしまったことについては溝を埋めるべく行動するのみと思います。 以前も話題に上がりましたが、
これについて。 これは溝を作っている発言であると言う認識はありますか？ 僕にはこの発言で溝を作られていると思うわけですが、 自分にできないことを他人に押し付けようとなさってますか？ | ||||||||||||
|
投稿日時: 2005-01-31 20:38
頭のおかしな人の相手はしない方が良いですよ
| ||||||||||||
|
投稿日時: 2005-01-31 22:10
みんなして、意地の張り合い貶しあい。
本題外れること甚だしい。 別に俺ぁ本題がちっとも理解できないので構いませんが。 喧嘩両成敗でスッパリ収めるか、場所を変えるかしては？ | ||||||||||||
|
投稿日時: 2005-01-31 23:43
ちょっと遠巻きにみてたのですが、（今頃何言ってんだって感じかもしれませんが）オブジェクト指向におけるプロパティ(注1)について考えてみました。（識者の方から叩かれそうでどきどきです・・・注2） そもそもオブジェクト指向で基本的な特徴の一つは「抽象データ型」(注3)であること。そして、この抽象データ型であるということはオブジェクトの内部構成 (内部属性・状態・内部データ・そのオブジェクトを構成する内部要素) が外部から直接アクセスできないようにするということ。 .netにおける「プロパティ」はこの抽象データ型の実装方法の一つでしかない。javaはシンプルさゆえ(と私は勝手に思っている)その機構がないだけのこと。Haskell(関数言語ですが)のようにフィールドもプロパティもなしで抽象データ型のコンセプトを実装している言語もあります。 前にも誰かが言っていましたが、「プロパティ」は .net が提供するSyntax Sugarであり、オブジェクト指向のもとのモデリングとはまったく違うレベルの話かと思います（注4）。そして、抽象的なコンセプトのオブジェクト指向(&モデリング)に、プロパティという実装定義を組み込むのはいまいちしっくりとこないと思います。 ということで、「プロパティはOO言語実装レベルの話でありOOモデリングレベルの話ではない」と思います。言語としての話なら「プロパティは便利だなぁ。でも諸刃の刃だなぁ。あれば使いたいなぁ。でもケースバイケースだなぁ」程度の意見になります。 〜〜〜ここまでは「プロパティとオブジェクト指向とモデリングについて」〜〜〜 で、プロパティとか関係なく、「「UML」を初めとする現在の「モデリング言語(手法)」の問題点は？」となるといろいろあると思います。 １．モデリング手法におけるコンセプトの共有化が難しい。ここのスレッドで多いに問題になっているように、皆さんの中で「オブジェクト」とは何かという認識の違いがモデリングに大きく影響してしまうこと。 ２．どうしても実装言語に偏る傾向がある。これは開発のスパイラルを考えるとしかたのないことかもしれません。一般的にモデリングをする時には使用言語が決まっていたりしますし。 ３．モデリングを検証(verify)することが難しい。実際に作ってみたモデルが本当に問題解決もしくは実現しようとしている対象を忠実にモデル化しているかどうか検証するシステムがない。（注5） などなど・・・ おそらく、みんなが納得するような統一理論はまずでないと思います。哲学にも近い概念なんですから。 注1）どこにもオブジェクト指向モデリングとは書いてありませんでしたが、.netやJavaについて議論をしているのでオブジェクト指向でのモデリングと仮定させていただきました。 注2）意見・反論・間違い・指摘など大歓迎です。でも、忙しいので返事ができなかったり、遅かったりします。すみません m(_ _)m 注3）「抽象データ型」(Abstract Data Type)はデータとそれに対する手続きをセットにすることにより内部データアクセスには決められた手続きのみにしか許さないという情報隠蔽やカプセル化の延長線にできたもの。オブジェクト指向ではそのほか継承 (inheritance)や多相 (polymophism)などといった特徴も重要。なお、Objectさんが言っている構造主義というのは簡単にいうと、機能中心(フローダイアグラムを使った手続き型)でもなく、データ中心(ERダイアグラムなどを使ったデータ型)でもない、その間の抽象データ(機能とデータ)中心ということです。和とか積とかいうのは数学的に抽象データ型や継承、多相をあらわしていると考えていいと思います。習った記憶はあるんですけど詳しいところは覚えてないので嘘ついてるかもしれません 
注4）ネットワークでたとえるならば、トランスポート層のプロトコルに物理層のプロトコルを組み込もうとしている感じ。 注5）実はあったりするけれど、あまり現実てきじゃない ＃長文駄文で注釈が多くてすみません。一応、調べて考えて書いてますが嘘だったり間違ってるかもしれません。 | ||||||||||||
|
投稿日時: 2005-02-01 01:15
復習の前にひらめきが得られたのでとりあえずメモ代わりに投稿。
以上の部分について、これからどう考察をすすめるべきだろう、と悩んでる時に 思いついたのですが、ここのフィールドとファンクションは、 アルゴリズムとデータという言葉に置き換えませんか？ フィールドとファンクションでは言語要素的イメージが強いですし。 BPMツールやXAMLのような宣言型プログラミング、XML/XSLTでできるいろいろなこと なんかのことを考えるとあまり言語要素的なイメージを持たせたくない、 と思うのです。（←ここの文章、うまく感覚伝わるか心配・・・＾＾；） | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.