石橋秀仁です. At Fri, 28 May 1999 23:25:06 +0900 "NAKAMURA, Hiroshi" <nakahiro / sarion.co.jp> wrote: > > オブジェクト指向で知識表現的な分析をしても, 結局, 最後は > > ソフトウェアで実現する（計算する）のに違いないので, 目的を > > 達成するのに最も適した分析が最前だと思うのです. > > そうですね．Ruby本体みたいに > 「そこにあったから取り出した」ってわけにはいかなくて，^^;;; うーん, どういう意味でしょう? 差障り無ければ教えてください. > あちこち捨象して作られるモデルであれば， > その捨象の指針となる「視点」が必要で， > その視点には，対象領域の特質と，解くべき問題と，文脈と， > いろいろな要因がある．．． > > かといって対象領域やら解くべき問題やら文脈やら毎にモデル用意してたら > 生産性が悪くて悪くて仕方なくて， > まぁいろいろ苦労したりあがいたりする，と． 上の段落はソフトウェアで実際に実現するための「設計」の話. 下の段落は問題領域を理解する「分析」の話のようですね. OO開発プロセスでは, ソフトウェアによる実現方法を過剰に意識しない 「分析」フェーズと, ソフトウェアによる実際の実現方法を検討する 「設計」フェーズがあります（とくにUMLのRPM(推奨プロセスモデル)では）. 両者を分けることで, 問題領域の分析に普遍性を持たせつつ, 使える ソフトウェアを作ろう, というのが, なひさんのあげた問題点に対する 「現代の」対処法ですよね. だからSA/SDやOOA/Dのような分析設計手法を 学ぶ意味があるのだと思います. > ．．．楽しく書き直せる言語を使ってる限りは，ですが．(^-^) OOA/Dによる分析／設計の（UMLとかの）成果物を, パパッと組み立てる （コーディングする）には, 「お手軽オブジェクト指向スクリプト言語Ruby」 が最適だと思います :-) ですからRubyは, ソースコードレベルでなく, 分析設計レベルで考える ことを助ける言語になれるだろうと思ってます. チームプロジェクトによる大規模システムだけが, 分析設計の対象じゃないと 思うんですよね. そういうのはCやJavaで作るのがフツーとかいわれてたり. だからRubyでOOA/Dというと奇異に聞こえるかも. でも, もっと「フツー」 のホビープログラマが分析設計手法を覚えると, もっと楽しくなるのでは. # ある意味で, 大規模なものはhackerよりパンピーが有利かも. # とにかくOSSの品質が全体的に向上するとほんとにうれしい. つまり, 「楽しい言語」によって「コーディング」が楽しくなるけど, 時間的にはむしろ節約になるので, 「分析設計」にたくさんの時間を かけることができると思うんです. ぼくがRubyのソフトウェアを公開するなら, UMLで表現したクラス図とか, 協調図とかも公開して, "Happy OOA/D with Ruby :-)"をアピールしたい. # いまんとこ作りたいものがないのでチュートリアル作ってます (^^; # 唯一やりたいRubyのJavaへのポートはRubyで開発できないし（笑） --- Concept of "The Ruby for Dummies" http://vip.cis.kurume-nct.ac.jp/%7Es34204/geocities/ja/idea.html --- Hideto Ishibashi <http://vip.cis.kurume-nct.ac.jp/%7Es34204/>