パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

マイクロソフト、6大学の研究グループにソースコードを公開」記事へのコメント

  • 新聞が好んで使う「設計図」という表現が気持ち悪い。
    「ソースコード」は「ソースコード」でいいじゃないか。
    「オペレーティングシステム」は「オペレーティングシステム」でいいじゃないか。
    「基本ソフト」なんて気持ち悪すぎて新聞を放り投げだしたくなる。
    • UML のことを指しているとしたら、あながち外しているとも 思えん。 あれは図ではあるけど、そのまま独立したオブジェクト指向言語という 感じもするし。
      # UML がそのまま動く処理系募集。
      --
      -- 哀れな日本人専用(sorry Japanese only) --
      親コメント
      • CNET Japan に掲載されてた江島健太郎の非ユークリッド幾何学の歴史とソフトウェア工学の進化(後編) [cnet.com]によると、

        > UMLが実際に行ったのはポンチ絵の描き方を緩やかに標準化した程度のこと

        だそうな。
        ソフトウェア工学をメッタ切りしてます。

        # でも思わず「まあ、そんなもんだよなぁ」と思ってしまったり。
        --
        *-----------------------*
        -- ウソ八百検索エンジン --
        親コメント
      • >あれは図ではあるけど、そのまま独立したオブジェクト指向言語という感じもするし。

        オブジェクト(つーかクラス)の「ある側面」の情報を記述できるだけなんですよね、UMLって。
        プログラムとして振舞うための充分な情報を与える手段が、結局、(少なくとも今は)無い。

        それどころか仕様書として振舞う(?)ための充分な情報すら書けない節がある。
        おかげで、仕様書として使おうとしたらnote(コメント)まみれになるのが今のUMLの姿です(^^;
        #プログラム言語としてはそもそも全く動かないので、「使った」ことは有りません。

        あとUMLが痛いのは絵を濫用してるって点。アイコン濫用と同じでして、
        少しづつしか違わない多数の図形種を的確に区別するのは、人間の目にとってなかなか骨です。
        もっと図形種が少ない言語だったら「読み書き」しやすかったんでしょうけど、
        今のアレは多すぎます。文字言語に対するアドバンテージが殆ど無い。

        ま、逆にいえば、あれだけ多彩な機能を有するUMLですが、実際人間にとって使い物になるのは
        そのうちの一部でしかない、って感じを受けてます。#C++に似てるなあ(藁
        あと、方言っていうか「崩し」をしないと、やってけんっていう感じも、かなり受けています。

        UML図を「動かし」たくなる理由の1つとして、描くのにそれだけ「苦労」を要するから、
        投入した労力を「回収」したいという欲求が当然発生する、って面が有るんだと思っています。
        が、だとすればそれに対する回答はシンプルです。「UMLを使った時点で敗北です」。
        #少なくとも、現状の多くの使いにくいUMLツールや、

        そういえば、 MartinFowler blikiに、UML Modeっていう話が有る [capsctrl.que.jp]ようです。
        UMLとの付き合い方で、人のモードを3種に分類する話らしい。

        ># UML がそのまま動く処理系募集。

        現状は無理でしょうね。

        勿論、アクションを直接書けないという今(今度出るというアレじゃなく)のUMLの根本的問題も有りますが、
        それ以前の問題も色々感じます。こまごまとしたところで、アレも足りないコレも足りないって感じ。

        個人的に思うのは、UMLを一通り描いたらプログラムに必要な情報も一通り描いたことになる、
        なんてな誤解を設計者とかがすることは、断じて避けて欲しい、ってことです。
        それで泣くのはその設計を受け取った実装者なのですから(T_T)

        #泣いてるのでG7。
        #ま、そういう辺りを判ってない奴に書かせれば、UMLであろうがなかろうが、そういう点で突っ込み所満載な仕様書を書くんだけどさ。

        ところで、

        |class X|

        |class A|
        |--- |
        |x:X |

        |class B|
        |--- |
        |x:X |

        みたいなUMLクラス図を書けますが、この場合のAとBのxが「同一の」インスタンスになるのか、
        それとも別インスタンスなのか、を、UMLではどこに書けるんでしたっけ?#Note不可でね。
        まさか、この程度のことも書く手段が無い、なんて言いませんよね?

        こういうケースは、「ある程度以上汎用性のある」クラスをあちこちで使いまわすときに頻発するわけですが…
        どう描いたらいいんでしたっけ?

        個人的には、プログラムの「静的構造」ってのは、(少なくとも)上記の点を書かないと
        全くもって表現したことにならないと思っています。
        だって、さもないと、つまり静的構造を表現するためには「型」の関係だけしか記述しなくていいのだとすると、
        型なし言語には構造が全く無い、という(明らかに変な)話になっちゃう(^^;
        代入可能かどうかを表現しただけで「静的構造」を表現したことになる、なんてこたぁ無いと思うんです。
        クラスを1つづつバラバラに注目してる時ならばそれでもいいんですが、不味いことにUMLのクラス図は
        複数のクラスを(しかも「関連」込みで)描けてしまうんですよね。それこそ構造を表現するためにです。
        言い換えれば、(UMLの)クラス図だけじゃ、とてもじゃないが(静的)構造は表現できん…

        なお、この話は、オブジェクト指向にとっては物凄く初歩的な話であるはずです。
        あっちとこっちからインスタンスを共有するかどうか?なんてな話が「初歩的」であることは、
        オブジェクトが実際存在する状況を想像すれば、誰でも判るはず。

        なのに、 UMLの初歩を解説する本やwebページでは、この点についての言及をしてるものを
        とんと見たことが無い…
        (俺がUMLの仕様を見落としてる恐れはさておくとして(^^;)
        これはいったいどういうことなんでしょうね?

        これはもしかすると、「OOPの基本は、継承、隠蔽、多態だ」みたいな間違った(^^;教育の賜物なんじゃなかろか?
        親コメント
      • ># UML がそのまま動く処理系募集。

        どんな風に?アニメーション?
        UMLはやっぱ絵ですよ。図ではなく。

ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家

処理中...