$B%=%U%H9)3X$N%K%e!<%9%0%k!<%W(B

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。計算機関係なのでfj.news.group.comp他に振ります。

ko-...@shimadzu.co.jpさん:
> fjの中に、「ソフトウェア工学」を話題にしているグループはあるで
> しょうか？もしわかる方があればお教えいただきたいのですが。（私
> の調べた範囲ではよくわからなかったので）

確かに、なさそうですね。fj.comp.oopsの議論は一部ソフトウェア
工学に関係あるようですが。

作りたい人はどれくらいいます? (萩本さん ?-) 久野

P.S. fj.engr.*じゃなくていいですよねぇ…

[hagimoto]

萩本です。

> 久野です。計算機関係なのでfj.news.group.comp他に振ります。
>
> ko-...@shimadzu.co.jpさん:
> > fjの中に、「ソフトウェア工学」を話題にしているグループはあるで
> > しょうか？もしわかる方があればお教えいただきたいのですが。（私
> > の調べた範囲ではよくわからなかったので）
>
> 確かに、なさそうですね。fj.comp.oopsの議論は一部ソフトウェア
> 工学に関係あるようですが。
>
> 作りたい人はどれくらいいます? (萩本さん ?-) 久野

　私は、oopsがあるので満足はしてます。でも、それでは視野が狭
すぎると思われる方が多いのでしょうね。もしあれば、ソフトウェア
工学全般について議論できますから、作ることには大賛成です。
　

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

hagi...@njk.co.jpさん:

> 私は、oopsがあるので満足はしてます。でも、それでは視野が狭すぎ
> ると思われる方が多いのでしょうね。もしあれば、ソフトウェア工学
> 全般について議論できますから、作ることには大賛成です。

早速ありがとうございました。では、作るとしたら、名称は

fj.comp.soft-eng

くらいでどうでしょう。

いろんな方のご意見が頂きたいですね 久野

[Oseto Futoshi]

こんにちわ、大瀬戸と申します。

In article <6jgdb6$i...@utogw.gssm.otsuka.tsukuba.ac.jp>, ku...@gssm.otsuka.tsukuba.ac.jp says...

確かに、comp.oops という名称だと視野が狭く感じられるので
違和感は有ります。
だからと言って、別にニュースグループを新設するのには
賛成しかねます。
ソフトウェア工学の視点を除いた oops って意味があるのでしょうか。

現在のここのニュースグループの憲章がどうなっているのか
知りませんが（どなたか、URL を教えてください）、
もしソフトウェア工学について言及されていないなら、
憲章を変更してそれを追加した方が良い気がします。
＃可能であればの話ですが。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

os...@cs.ricoh.co.jpさん:

> 確かに、comp.oops という名称だと視野が狭く感じられるので違和感
> は有ります。だからと言って、別にニュースグループを新設するのに
> は賛成しかねます。

そうですか。

> ソフトウェア工学の視点を除いた oops って意味があるのでしょうか。

私はソフトウェア工学と関係のないオブジェクト指向について研究し
てますがいけませんか ^_^;

> 現在のここのニュースグループの憲章がどうなっているのか知りませ
> んが（どなたか、URL を教えてください）、

「オブジェクトオリエンテッドに関する話題」ですね。

http://www.cs.orst.edu/~takikawm/fj/
http://www3.justnet.ne.jp/~s_kishimoto/WEOCOME.HTM

などから調べれば分かるでしょう。

> もしソフトウェア工学について言及されていないなら、憲章を変更し
> てそれを追加した方が良い気がします。

よくない気がします。私としてはソフトウェア工学と関係のないオブ
ジェクト指向の話ができるグループは欲しいですから。

> ＃可能であればの話ですが。

そう努力されるというなら止めませんけど… 久野

[Koutarou Nakamura]

中村＠組込型リアルタイム系ＳＥです。

ソフトウェア工学のニュースＧｒ作成には賛成です。

ソフトウェア工学とは、
品質向上、生産性向上のための
実務レベルでの指針を与える学問
と記憶しています。

ＯＯ自体はそのための一手段でしかなく、
よく言われているように、「銀の弾丸」ではないですね。

従ってＯＯからソフトウェア工学を議論するのは
すこし視野が狭い気がします。

とくに、私が手がける組込型リアルタイム系では、
未だ、ソフトはハードの付属物という考えが残っており、
それに伴うソフトウェア管理の
ずさんさがソフト屋を苦しめています。
（いわゆるＣＭＭ　１の混沌とした状態ですね）
それなのに、求める品質はパソコンソフトの比ではありません。

システムが巨大化するに従って、
そうした考えでは立ちゆかず、
ソフトウェア工学に期待するところであります。
（もっとも失望する学問とも聞きますけど）

また、そうした病めるソフトウェア開発現場では
ＯＯどころではなく、ソフトウェア工学そのものの
理解から始める必要があると思うのです。

そんな病めるソフトウェア開発現場のための
ＮＧがあっても良いのではないでしょうか？

「銀の弾丸」はなくても「鉛の弾丸」はある筈です。

＃ＯＯの説明をして、
＃「ＯＯをやるとＲＯＭがどんなけ減るのか」
＃と聞かれた際には目が点でしたから。

by 中村耕太朗　（「朗」の字注意）　　

>確かに、comp.oops という名称だと視野が狭く感じられるので
>違和感は有ります。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

kout...@gld.mmtr.or.jpさん:
> ソフトウェア工学のニュースGr作成には賛成です。

どうもどうも。fj.comp.soft-engでどうですか?

> OO自体はそのための一手段でしかなく、よく言われているように、
> 「銀の弾丸」ではないですね。

ですね。

> (いわゆるCMM 1の混沌とした状態ですね)

CMMの話とかも面白そうですね。

> システムが巨大化するに従って、そうした考えでは立ちゆかず、ソフ
> トウェア工学に期待するところであります。(もっとも失望する学問
> とも聞きますけど)

うーん。失望するんですか。

> #OOの説明をして、
> #「OOをやるとROMがどんなけ減るのか」
> #と聞かれた際には目が点でしたから。

なかなかすごいですね。バイトコードインタプリタならROMが減るこ
とはあるかも?

目が点ってどういうsmilyだっけ。*_*? 久野

[TANAKA Koji]

もともとの質問をした田中です。いろいろ反応をいただいたようで恐縮です。

私は現在この分野に関していろいろ本とか読んで勉強している最中です。ニュース
グループ新設前に質問してしまうようで申し訳ないのですが、「スパイラル開発」と
いう概念について、詳しく知りたいと思っています。
あちこちの本で散見される情報をもとに、だいたいどういうものであるかのイメー
ジはあるのですが。最終的な完成まで「設計・作成・実装」のサイクルを４回程度ま
わすとか、１サイクルしたところをマイルストーンと称するとか、そんな感じでしょ
うか。でも、そのサイクル自体をどう計画するかとか、なんかよくわからんのです。
スパイラル開発について、一からまとまった説明をしてある文献があればご紹介い
ただきたいのですが、ご存知の方おられるでしょうか？

....という投稿は、新しいNGができてからにした方がよいですかね....

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。fj.comp.oopsは残しますがfj.comp.miscに振ります。

ko-...@shimadzu.co.jpさんは書きました。
> もともとの質問をした田中です。いろいろ反応をいただいたようで恐
> 縮です。

べっつに恐縮されるようなことでも…

> 私は現在この分野に関していろいろ本とか読んで勉強している最中で
> す。ニュースグループ新設前に質問してしまうようで申し訳ないので
> すが、「スパイラル開発」という概念について、詳しく知りたいと思っ
> ています。

そういえば十年前?くらいから現われた言葉ですけど、誰が言い出し
たのでしょうね。

> あちこちの本で散見される情報をもとに、

どういう本を読まれましたか。参考になりますのでお教え頂けると嬉
しいです。

> だいたいどういうものであるかのイメージはあるのですが。最終的な
> 完成まで「設計・作成・実装」のサイクルを４回程度まわすとか、１
> サイクルしたところをマイルストーンと称するとか、そんな感じでしょ
> うか。でも、そのサイクル自体をどう計画するかとか、なんかよくわ
> からんのです。

私はソフトウェア工学の人じゃないんですが、そんな用語は後からつ
いてきたもので、まずは作って見て試す、それを繰り返す、というのが
基本的なアイデアでしょ? で、それでうまく行くためには、とか失敗し
ないためには、というノウハウをいろんな人がいろんな言い方でしてい
る、とそういうふうに捉えています。

> スパイラル開発について、一からまとまった説明をしてある文献があ
> ればご紹介いただきたいのですが、ご存知の方おられるでしょうか？

ソフトウェア工学の教科書とかにあるかなと思うのですが。Webで見
られるものでしたら、たとえば

http://ns1.srainc.com/~aoki/SmalltalkWorkbookJ/Chapter06.html

とかですかね。今見たら、スパイラルモデルの提案者はBoehmさんで
1988年のIEEE Computer誌(vol. 25, no. 5, pp. 61-72)が参考文献に挙
がっています。まずはこれを読まれるのがいいかも知れません。

> ....という投稿は、新しいNGができてからにした方がよいですかね....

いえ。できるまで投稿を控えるというのはよくないと思います。とい
うのは、できた暁にどういう投稿がなされるのか他の人から見て分から
ないし、作ってもそんなに記事が集まるのかといういちゃもんがつきが
ちですから。とりあえずfj.comp.misc (miscは「その他何でも」という
意味)で議論したらいいのではないでしょうか。

ニュースグループ作成の方は並行してやりましょう 久野

P.S. OTGのページにも開発プロセスの話がありますですよね。よかった
らPRされます?>>萩本さん

[Oseto Futoshi]

大瀬戸です。

In article <6jolh8$3...@utogw.gssm.otsuka.tsukuba.ac.jp>, ku...@gssm.otsuka.tsukuba.ac.jp says...

>
>> ソフトウェア工学の視点を除いた oops って意味があるのでしょうか。
>
> 私はソフトウェア工学と関係のないオブジェクト指向について研究し
>てますがいけませんか ^_^;

いいえ、滅相も無い。^^;;
ただ私は、OOAからオブジェクト指向に入ったせいか、
OOAの理解なしにOOPするのは危険だと思っていたからです。

＃でも、ソフトウェア工学はOOAだけじゃないですね。
＃（自分の視野の狭さを反省します。）

>> もしソフトウェア工学について言及されていないなら、憲章を変更し
>> てそれを追加した方が良い気がします。
>
> よくない気がします。私としてはソフトウェア工学と関係のないオブ
>ジェクト指向の話ができるグループは欲しいですから。

久野さんのお考えは理解しました。

>> ＃可能であればの話ですが。
>
> そう努力されるというなら止めませんけど… 久野

すいません。努力しません。m(_ _;)m

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。fj.comp.oopsのみに絞ります。

os...@cs.ricoh.co.jpさん:
> ただ私は、OOAからオブジェクト指向に入ったせいか、OOAの理解なし
> にOOPするのは危険だと思っていたからです。

この辺が興味あります。たとえば、大学の1年生にプログラミング教
えるとしますよね。で、言語にJavaとか使いたいわけです。それで「ま
ず要求仕様が…」とかやってたらそれで半年終わっちゃうしその前に学
生さんがみんな逃げちゃうような気もするわけです。

どうしたらいいのでしょうね? メカニズムとしてのOOPだけ教えると
いうのも嫌なので、メカニズムをちょっと教え、思想をちょっと教え、
とかしてます。となるとOOAをまず教えるというのとはほど遠いわけで…
でもJavaとかで教育、したいですよね。

この辺のご意見をいろいろ伺いたいです。

> ＃でも、ソフトウェア工学はOOAだけじゃないですね。

そりゃそうです。ただOOでないソフトウェア工学はマイナー化して行
くのかも…(この辺問題発言?)

> すいません。努力しません。m(_ _;)m

そうですか、それは残念…ってこともないか。 久野

[hagimoto]

萩本です。

　ちょっと引用を部分的に省略させてもらって。

ku...@gssm.otsuka.tsukuba.ac.jp wrote:

> べっつに恐縮されるようなことでも…
>
> > 私は現在この分野に関していろいろ本とか読んで勉強している最中で
> > す。ニュースグループ新設前に質問してしまうようで申し訳ないので
> > すが、「スパイラル開発」という概念について、詳しく知りたいと思っ
> > ています。
>

　　　　｜　省略

> P.S. OTGのページにも開発プロセスの話がありますですよね。よかった
> らPRされます?>>萩本さん

　もちろんですぜ久野さん。:-)

　
　以下にスパイラルモデルについて私の所属するOTGページDropFaqから
の引用で、ある方からの質問をベースに作成したものです。
　興味がわいたらこちらを！！(http://www.njk.co.jp/otg/Drop/faq.html)

-----------------------------------------------------------
質問、ウオータフォールモデルとスパイラルモデルの違いについて

|御社のホームページと文献を元にオブジェクト指向について学んでみた
|のですが、少々気になる所がありまして、再度メールさせていただいた次
|第です。
|御社のオブジェクト指向セミナーのオブジェクト指向入門【分析・設計】
|編の１頁目「オブジェクト指向によるシステム開発」の解説の中で
|従来の開発プロセスとオブジェクト指向での開発プロセスについて説明が
|あります。
|従来は「ウォーターフォールモデル」を使用しており、オブジェクト指向では
|「スパイラルモデル」を使用していくとのこと。

　WWWによるオブジェクト指向バーチャルセミナーの基礎編ではオブジェク
ト指向で一般的に述べられていることや一般的なオブジェクト指向方法論
として書かれている事に、できるだけ沿った形で解説するように心がけて
います。よって、その解説に対するOTGの考えはあまり入ってません。
　Dropの第３章では、以下のようにこの問題を指摘しています。
(反復開発とスパイラルは同じようなもので明確な違いは示されていませ
ん)

------http://www.njk.co.jp/otg/Drop/DropBook/
最近のオブジェクト指向手法における開発サイクルは、従来の開発手法で
使いわけていたウォータフォールモデルとは異なり、『反復開発』『ラピッド・

プロトタイピング』といったスタイルが一般的に推薦されている。しかし、ほと

んどの方法論では、開発サイクルを開発プロセスの一環として解説されて
いない。そのため、オブジェクト指向方法論を採用すると、開発システムの
工程管理が困難 になりやすい。Dropの開発サイクルでは、この問題を解
決するため、チームごとに明確な開発サイクルを定義していることが特徴
である。
---------

基礎編に我々の考えをあまり含めていない理由は、オブジェクト指向を体系
的に学んでほしいからです。そして、応用編にてオブジェクト指向の現状の
問題に触れ、最終的にDropへ道案内しようという考えです。

|スパイラルモデルは他の文献を見ていてもよく出てくる開発モデルですが、
|このスパイラルモデルとは最初から繰り返し作業を行うことを前提とした
|モデルなのでしょうか？

人間は、一度に全ての事を把握(分析)して進むことはできません。だからす
こしずつ分析ー設計ー実装ーテストを回していこうとする考えです。

|従来の「ウォーターフォールモデル」にしても、結局システムに不備が
|見つかった時点で最初の分析に戻ることになると思うのですが、そうなると
|「スパイラルモデル」となんら変わりなくなってしまうのではないでしょう
か？
|もちろん、「ウォーターフォールモデル」では、１回の流れで完了する
|ことを目標としていますが、現実ではそうはいかず何度も繰り返し
|行われているわけですよね。

まったくそのとおりです。「ウォーターフォールモデル」とは形だけの形式性
にとらわれ現実を見ていなかったモデルなのです。だからもっと素直になろ
うというわけです。

|自分なりに「ウォーターフォールモデル」では最初の分析に戻った場合には
|１からやり直しとなるが、オブジェクト指向での「スパイラルモデル」では
|最初に作ったモデルを前提として拡張していく・・・というような
|考え方なのかと思っているのですが、結局その前提となるモデルが間違っ
|た方向に進んでいるものであれば、１からやり直しとなる・・・。
|?と考えていると、従来の方法論とオブジェクト指向の方法論の区別が曖昧
|になってきてしまいました。

　結局、人間が受け入れられない開発モデルを無理やり使っていても意味
がないし、ましてや、そのルールに縛られてしまうと非効率なことが多いの
です。
　だから、スパイラルという言葉を使って自由度を与えたわけです。しかし、
このことは開発モデルが無法地帯になったと考えてもよいわけです。オブジ
ェクト指向方法論としてやるべきことはスパイラルに進む際の管理手法をど
うするかということに触れていなければなりません。しかし、今のところ殆ど
の方法論は、このことに触れられていないのが現状です。
　Dropでは、第３章にて、アプリケーションの骨組部分は「カスケードウオー
タフォール」を使う。またコンポーネント開発には「積み上げ反復」を採用す
る。と述べ、その理由や実際の工程においてやるべきことを述べています。

|オブジェクト指向では最初の分析の第１歩目が非常に重要だと言うこと
|なのでしょうか？（そこが間違っていると全くオブジェクト指向の利点が
|生かせなくなる）
|そうなってしまうと、結構オブジェクト指向でのシステム開発はリスクを
|背負うことになってしまうのではないでしょうか？

　アプリケーションの骨組部分は厳密に分析を済ませておかなければなり
ません。
しかし、その肉付けに値するコンポーネント開発は「積み上げ反復」的に進
めることが性質上可能なことが多いのです。このようにアプリケーションを開
発することと、コンポーネントを開発することを区別し、それごとに開発サイク

ルを設ける必要があります。このことについての詳細は、先程のURLを見て
下さい。

|インターネット上でオブジェクト指向を用いてシステム開発をした成功例
|はのっていますが、さすがに失敗例は発見できません。
|「ウォーターフォールモデル」と「スパイラルモデル」の違いについて
|ご説明いただければありがたいのですが。

　これでおわかりになったでしょうか。
　「スパイラルモデル」という奇麗な言葉の定義付けは、いまだに「分析・設
計・実装を回す」というだけでそれで成功する根拠などなく、人間にとって自
然ということだけです。しかし「ウォーターフォールモデル」といった人間にと
っ
て不自然で官僚的なモデルを打ち崩すにはこれで十分だったのでしょう。
　こういった奇麗な用語にだまされてはいけません。その用語が示す理論
が、どれだけ説得力があり実用的であるかを検証しなければなりません。
　ここで、このことをもっと突込んで考えてみることにしましょう。
　私は、分析・設計というものは「ソフトウェア工学的な工程」と「視点」とい
う
性質を合わせ持っていると考えています。このことを開発者は頭においてお
かねばならないと思っています。
　つまり、分析的視点と設計的視点という2つの視点で問題領域を観察する
習慣が常に必要だということです。このように「視点」として考えることが「ウ

ォーターフォールモデル」だとルール違反になり「スパイラルモデル」だとなん

となく出来てしまうということになります。しかし「スパイラルモデル」という
一
言では「ソフトウェア工学的な工程」としては欠陥だらけなのです。
　つまり、この視点と工程という二面性に真っ向から立ち向かい、それをプロ
セスとして実現しやすいものを方法論としては提唱すべきなのです。簡単に
「スパイラルモデル」で済ませてはならないのです。
　このことについてもDrop方法論にてチャレンジしているわけです。

[hagimoto]

萩本です。

ku...@gssm.otsuka.tsukuba.ac.jp wrote:

> 久野です。fj.comp.oopsのみに絞ります。
>
> os...@cs.ricoh.co.jpさん:
> > ただ私は、OOAからオブジェクト指向に入ったせいか、OOAの理解なし
> > にOOPするのは危険だと思っていたからです。
>
> この辺が興味あります。たとえば、大学の1年生にプログラミング教
> えるとしますよね。で、言語にJavaとか使いたいわけです。それで「ま
> ず要求仕様が…」とかやってたらそれで半年終わっちゃうしその前に学
> 生さんがみんな逃げちゃうような気もするわけです。

　そうですね。:-)
　実際に教えるとなると興味のあることから入らせてあげたいですね。

> どうしたらいいのでしょうね? メカニズムとしてのOOPだけ教えると
> いうのも嫌なので、メカニズムをちょっと教え、思想をちょっと教え、
> とかしてます。となるとOOAをまず教えるというのとはほど遠いわけで…
> でもJavaとかで教育、したいですよね。

> この辺のご意見をいろいろ伺いたいです。

　大きな課題や何人かで共同して開発に取り組ませて初めて、要求整理、要件定
義の重要性が明らかになるのではないでしょうか。それまでは、た
ぶんピンとこないものだと思います。
　そのような人に要求は重要だ！と言っても、「私は自分の感性でこれが
必要だと思い作成しました。」なんて答えが返ってくるかも。これもソフトウェ

ア作成における貴重な一側面でもありますよね。
　作ってしまったものに対して、その作者がどのような適用範囲と要求を前
提に作成したかをかならず書かせるようにするのもいいかもしれませんね。
　作成したソフトウェアは、個人レベルであっても明確な要件定義はかなら
ずあるはずですからね。
　しかし、新人さんにはじめから要求を整理せよと言っても要求の中にはソ
フトウェアドメイン的なものも入り込んでおり、そりゃやって見なきゃわかん
ないという部分もありますからね。
　特に学校の中で取り扱う題材には、要求がソフトウェアドメインに深く関係
しており、要求に対するフィジビリテイの判断が重要なファクタとなることが多

いのではないかなどと想像しています。

[Kiyohiko Kajihara]

梶原＠ＮＴＴソフトウェア研究所です．

|グループ新設前に質問してしまうようで申し訳ないのですが、「スパイラル開発」と
|いう概念について、詳しく知りたいと思っています。

|でも、そのサイクル自体をどう計画するかとか、なんかよくわからんのです。

読んでいない本を推薦するのは好ましくないのはわかっていますが，Ms. Smalltalk
の Goldberg さんの著作なら安心して推薦できます．以下の本がお薦めです．

A. Goldberg and K. S. Rubin著，とね，今野，稲富，遠藤訳：
オブジェクト指向開発のプロジェクト管理
アジソン・ウェスレイ・パブリッシャーズ・ジャパン (1997)
ISBN 4-7952-0707-X 553 pages

-- kajihara

[Oseto Futoshi]

大瀬戸です。
＃fj.news.group.compじゃないかも知れませんが、
＃話の流れ上そのままにしています。

In article <6jrhlo$k...@utogw.gssm.otsuka.tsukuba.ac.jp>, ku...@gssm.otsuka.tsukuba.ac.jp says...

>
>久野です。fj.comp.oopsのみに絞ります。
>
>os...@cs.ricoh.co.jpさん:
>> ただ私は、OOAからオブジェクト指向に入ったせいか、OOAの理解なし
>> にOOPするのは危険だと思っていたからです。
>
> この辺が興味あります。たとえば、大学の1年生にプログラミング教
>えるとしますよね。で、言語にJavaとか使いたいわけです。それで「ま
>ず要求仕様が…」とかやってたらそれで半年終わっちゃうしその前に学
>生さんがみんな逃げちゃうような気もするわけです。

（中略）
> この辺のご意見をいろいろ伺いたいです。

OOPをする際に一番問題となるのは、「何をオブジェクトとするか」
だと私は考えます。その際、分析が正しく出来てないと変な
オブジェクトが出てきそうな気がします。
＃尤も、フレームワークを使った開発の場合、
＃既に作成すべきオブジェクトが絞られている為
＃そういう必要のない場合もあると思いますけど。

でも、これはOOPを使う（あるいはOOPに慣れる）と
いう視点では必要の無いことかもしれません。

私は、大学での教育と企業内での教育の目的が違うため、
作られるソフトウェアも変わってくると思います。
＃鋸や金槌の使い方に慣れさせるのが目的か、
＃売り物の家を作るのが目的か

僕は後者の立場だから、「OOAの理解なしにOOPするのは危険」
という発想をします。

でも、同じ土俵で論じたらいけないですね。

>> ＃でも、ソフトウェア工学はOOAだけじゃないですね。
>
> そりゃそうです。ただOOでないソフトウェア工学はマイナー化して行
>くのかも…(この辺問題発言?)

どうなのでしょう。
実際、今でも構造化分析を使って実績をあげていってる
企業もあると聞きます。まだまだ現役な部分は多い
と思います。
＃ひょっとするとソフトウェア工学自体がマイナーかも知れません。

＃原子力発電所の制御とか交通信号機の制御とか、どういう
＃開発方法を取っているのか、ちょっと気になりました。

[Hironobu Suzuki]

>>>>> "Oseto" == Oseto Futoshi <os...@cs.ricoh.co.jp> writes:
In article <6ju1bo$m...@bb.shinyoko.ricoh.co.jp> os...@cs.ricoh.co.jp (Oseto Futoshi) writes:
Oseto> 僕は後者の立場だから、「OOAの理解なしにOOPするのは危険」という
Oseto> 発想をします。

それは、どっちも、どっちだなーっていう答えになると思うんですよ。

で、ですね、ＯＯＡ／ＯＯＤがあって、ＯＯＰがあるなんていう人は、たぶ
ん、ＯＯＰＳ以外の手続き型言語あたりから入ってきて、パラダイムシフトが
頭の中でできないままなので、それをどう形にするかというので、ＯＯＡ／Ｏ
ＯＤなんてのを明確にした上じゃないと、恐くて入れないのだと想像します。

混沌設計論の時代から、構造化設計論に移った頃もやはり同じような議論を
しています。ずいぶん古い時代で、僕はリアルタイムじゃなんだけど、やっぱ
りプログラミングの前に設計論とかいっています。デ・マルコやメイヤーやヨー
ドン云々かんぬん。

ところが、ＵＮＩＸ／Ｃで育ってきた子は、Ｃでスパゲッティーgotoなんか使
うアホは滅多にいないし、何でも外部変数にしちゃったり、やたらと大きいモ
ジュールを作っているヤツはあまりいない。で、これは、別に構造化設計論を
やったからじゃないんすよ。これはＣのプログラミング・スタイルであり、パ
ラダイムなわけです。自然となるようになる（でも、少数だがそうじゃないヤ
ツもいる）。

所が、構造化設計論が導入される以前のＣＯＢＯＬやＦＯＲＴＲＡＮを長年
やってきた人がＣ（別に何を書いても同じだけど）を書くと、平気でひどいプ
ログラムを書く。ちゃんと動くんだけど、かんべんしてよー、ってコードになっ
ちゃう。もう、これは設計論としてのシステマチックな考え方を導入しなきゃ
いけない。頭でっかちにして考え方をカチっと決めてやるのが一番早い。で、
設計論云々をがっちりやる（やらせる）わけです。

で、ですね、今はですね、いきなりＣ＋＋しかやったことのない子とかいる
わけですよ。で、その子は、ＯＯＰＳな考え方で始めから考えるわけです。Ｏ
ＯＡとかＯＯＤがなんてやらない。でも、ＯＯＰＳで書くのに最も歪みのない、
ストレートな考え方をするから、というか、それしか知らないから。

ちょっと前まで、僕の回りに、入社以来Smalltalkしかやったことがない、研
修でCを数週間やったけど、もう忘れて教科書見ながらじゃないと、書けない
とかいう若い子がいました。別にＯＯＡとかＯＯＤとか一々面倒なことをいわ
なくても、Smalltalkで、つまりＯＯＰでやろうとすると必然的／自然に、Ｏ
ＯＡ／ＯＯＤなことをやるわけですね。

ＯＯＡ／ＯＯＤなんて言葉がなかった時代だって、当たり前だけどＯＯＰＳ
があるんですね。Smalltalkの現在の原型ができたのは８０年だし、８０年代
後半にあった、Symbolicsの上に載っていたFlavorなんてのは、今考えれば、
美しいＯＯＰＳです。同じころには、Simulaの末裔であるBETAなんてのがあり
ました。けっこう、使っている人は使っていました（使っていない人は使って
いない＜笑＞）。今、考えれば、ちゃんとしたものでしたよ。

僕が知っている範囲では、手続き型言語しかやったことのない人は、ほとん
どの人がつまづくんです。もう頭を切替えられない。完全にパラダイムが違う
んだなー。パラダイムが違うということは、こーゆーことか、と他人を見てい
て思いました。スムーズに考えられない。どうしても過去のやってきたパラダ
イムの中から見ちゃう。

これは、ちょうど英語に似ています。アメリカで育った子は、文法を一々習っ
て言葉（英語）が話せるようになるわけじゃない。一方、日本で、中学校で英
語を勉強し始めるときは、文法がどーのこーのとかやる。でも、文法どうのこー
のってのは、話せるようになってから深く理解するためには、文法をやってお
いた方がいいでしょうけど、当面、言葉（英語）を話すために必ずしも役立っ
てはいない。それと同じです。

ちょっと話しは飛ぶけど、Ｃ＋＋がすごいなー、と思った点は、『大量にい
るＣプログラマーをスポイルせずに、何であれＯＯＰＳへと導くための手段』
という話を聞いた時です。もう随分昔の話になるけど、ＡＴ＆Ｔのベルラボの
人に、『なんで、Ｃ＋＋のような中途半端なＯＯＰＳが必要なの？』と大胆に
も聞いたことがあるんです。そんときの答えが上の答えでした。簡単には、Ｃ
からすぐには離れられないけど、とにかく少しでもＯＯＰさせてしまおうとい
う突破口だったわけです。

これを逆接的に捉えれば、Ｃ＋＋って非ＯＯＰＳな書き方でも十分に書けるわ
けです。恐ろしいことに、単にＣの型チェック厳しいコンパイラだったりする
わけです。でもってＣ＋＋でＯＯＰＳを書いていたつもりが、実は全然ＯＯＰ
Ｓではなかった！なんてこともあり得るわけですね。英語に例えると、ルー大
柴の芸のような「みんなで、楽しく、HAPPY TOGETHERしようよ」みたいな、チャ
ランポランなこともできる。そーゆー意味で、Ｃ＋＋は、ちょっと別格ではな
いかとも思うわけです。

明確な分析と設計の理論、あるいはスタイルが絶対的に必要になるのは、複数
人数でプログラム生産を行なう時の標準化の際だと思います。明確な分析と設
計の理論の導入には色々いいことあるんですけど、最低限ということで考えれ
ば、共通のバックボーンを持たないことには、共通化したドキュメントが書け
ません。

なんか妙にながくなっちゃった。

ひろのぶ
PS.

親しみ易いけど、真面目なソフトウェア工学の本を書いたつもりだったけど、
どうやら、業界暴露裏話本だと思われているので、ちょっと悲しい。

[Hiroaki Nakamura]

萩本さん:

> 最近のオブジェクト指向手法における開発サイクルは、従来の開発手法で
> 使いわけていたウォータフォールモデルとは異なり、『反復開発』『ラピッド・
> プロトタイピング』といったスタイルが一般的に推薦されている。しかし、ほと
> んどの方法論では、開発サイクルを開発プロセスの一環として解説されて
> いない。

UML の特徴のひとつに、ユースケースを基準にして
繰り返しを計画することがあげられます。たとえば
文献[1]の26ページから始まるPlanning の節に次の
ように書いてあります。

"The first step is to categorize the use cases."
... 途中、数ステップ ...
"The next step is to assign the use cases to iterations."
... さらに数ステップ ...

文献[2]にはユースケースを基にして、オブジェクト指向
分析・設計・プログラミングのサイクルを２回転させる
様子が実例を通して詳細に書かれています。

御参考になれば幸いです。

References
[1] Martin Fowler and Kendall Scott, "UML Distilled,"
Addison-Wesley, 1997, 0-201-32563-2.
[2] Craig Larman, "Applying UML and Patterns,"
Prentice Hall, 1998, 0-13-748880-7.

中村宏明
イリノイ大学／日本ＩＢＭ

[Nobukuni Kino]

アイザックの紀と申します。
この数年企業内でオブジェクト指向とJavaの新人教育を担当しています。

大瀬戸さん wrote:
> OOPをする際に一番問題となるのは、「何をオブジェクトとするか」
> だと私は考えます。その際、分析が正しく出来てないと変な
> オブジェクトが出てきそうな気がします。

これはまさにそのとおりだと思いますが、

> でも、これはOOPを使う（あるいはOOPに慣れる）と
> いう視点では必要の無いことかもしれません。
>
> 私は、大学での教育と企業内での教育の目的が違うため、
> 作られるソフトウェアも変わってくると思います。
> ＃鋸や金槌の使い方に慣れさせるのが目的か、
> ＃売り物の家を作るのが目的か
>
> 僕は後者の立場だから、「OOAの理解なしにOOPするのは危険」
> という発想をします。

私は「OOPの理解なしにOOAするのは危険」と考えています。
鋸や金槌はともかくどういう部品を現場でどのように組み立てる
のか知らない人は売り物の住宅を設計できませんから。
住宅の場合に設計と施工が分業できているのは、ソフトウエアよりも
施工方法の変化のスピードが小さいからではないかと思います。

私のところではオブジェクト指向教育はそれ以前のパラダイムの歴史
から始めています。
# 割り込み、サブルーチンの発明から:-)
そして自分の失敗も含めてどのように問題点を解決しようとした手法が
考えられたか、そして現場で-適用できていない-かというお話をします。

そして、OOPの勉強をしたあとでJavaを一通り勉強しますが、最後の
課題は小人数チームでの開発です。しばらくすると一応動くプログラムが
出来あがってきますが、ここでの教育テーマはOOPでもプログラムそのもの
でもなく開発過程での問題点、ドキュメントの重要性など別の技術です。
OOAについてはさわりだけやりますが、何年か経験しないと理解できない
と考えているので新人教育では詳しくやりません。

やはり、プログラミング-設計-分析の順の方が理解しやすいのでは
ないでしょうか。

# バブル期の就職状況がよかったころ、採用面接にやってきた学生の
# 「自分は設計だけやるように教育されましたし、そのような業務だけ
# を行う立場になれる会社に就職したい、プログラミングはやりません」
# という趣旨の発言に唖然としたことがあります。
--
(株)アイザック　紀　信邦

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

いろいろ議論がはじまってますが、やっぱりOOPとソフトウェア工学
とグループ分けたいなと思います。いかがですか? 反対の方います?

そして、分けるとしたら、ソフトウェア工学のグループは

fj.comp.soft-eng

でいいでしょうか? いかがですか? 反対の方います? いたら早急にお知
らせください。

さっさとCFDしてCFAしますよ? 久野

[Toshio HORI]

この記事ではFollowup-To: fj.news.group.compとしています。

In article <6k0is2$l...@utogw.gssm.otsuka.tsukuba.ac.jp>,
ku...@gssm.otsuka.tsukuba.ac.jp writes:
kuno> いろいろ議論がはじまってますが、やっぱりOOPとソフトウェア工学
kuno> とグループ分けたいなと思います。いかがですか? 反対の方います?

作成には賛成です。

とりあえず、最近の「これ、どー考えてもfj.news.group.compにcross postす
る必要ないよなぁ」という記事は、とりあえず誰か適当なとこに移して続けて
ほしいです;-)

kuno> そして、分けるとしたら、ソフトウェア工学のグループは
kuno> fj.comp.soft-eng
kuno> でいいでしょうか?

名称には特に意見を持ちません。"soft-eng"でいい人が多いなら従います。で
も、もし他の方からより良い(と堀が考える)名称が出たら、そちらを推すかも
しれません(^_^)

// 堀 俊夫 / to...@etl.go.jp
// 電子技術総合研究所 知能システム部
// Homepage : http://www.etl.go.jp/~toshi/

[Hironobu Suzuki]

>>>>> "kuno" == kuno <ku...@gssm.otsuka.tsukuba.ac.jp> writes:
In article <6jvqsl$g...@utogw.gssm.otsuka.tsukuba.ac.jp> ku...@gssm.otsuka.tsukuba.ac.jp writes:
kuno> お! これは新説ですね。

これはですねー、もう、８、９年ぐらい前なんですけど、現場で「ＯＯＰＳと
は」なんて話をすると、聞いている人の目が泳いじゃっているんですよー。

で、色々想像したんですけど（想像は想像です、検証なぞはしていません）、
これはパラダイムが違っているからではないかと。クーンの言うパラダイムっ
て、いわば、意識のしない回りを包む空気(atmosphere)のようなものじゃない
ですかー。もう、当たり前の。でも、空気を知らない、むりやり意識しなきゃ
ならない、となった場合、これはシステマチックに体系化したものに、ハメる
のが安心なんですよ。空気に漂うことは、恐くてできない。

kuno> でもですねー。某大学あたりで1年生のプログラミング入門にC++と
kuno> かしてますけど、内容がCのanalogなんですよ。やっぱ教える方のパラ
kuno> ダイムシフトが必要だなーと。で、私はJavaとかしてますけど、いき
kuno> なり教えるべきことが多くて結構苦戦してます。

Smalltalkなんてのは、簡単ですよ。というのは、あれはLOGOとかを学ぶのと
同じステップが踏めるんですよ。これは、別に言語仕様のよしあしの問題では
なくって、Smalltalk文化の懐の深さなんですね。

ゴールドバークのおばさんが、「むかし、ALTOをどっかに収めた時、それまで
なんにもプログラムを作ったことがない人が、チョコチョコっと見よう見まね
でプログラムを作った。そんだけSmattalkは簡単だ」みたいなことを言ってい
たのを聞いたことがあるんですけど、これは、やはり言語仕様云々ではなくっ
て、Smalltalkの開発環境が持つ奥深さみたいなものがあるわけです。

もっと突っ込んで言えば、良質のOOPSの持つパラダイムにドップリ浸かってし
まうと、「あ、こりゃ、楽だな」と。

で、これは他のパラダイムにあるものとは比較ができないんです。なぜなら、
価値基準（パラダイム）が違うんで。

kuno> 現在その弊害がでてますよね。「10年たったら非オブジェクト指向
kuno> 部分は自動的に消滅する」とかいう言語仕様にしてたらよかったとか :-)

Ｃ＋＋はねぇー。でも、「全米ＡＴ＆Ｔの交換機のために大量に雇っているプ
ログラマを（なるべく）解雇せず、かつ、ＯＯＰＳ導入による生産性の向上」
みたいな目標は十分に達したから、それはそれでいいんじゃないかと。

kuno> で、パラダイムシフトな人とそうでない人が一緒に仕事するときは
kuno> どうするんですか? それが伺いたい。

僕もわからない（笑）。

僕の経験した開発では、ＯＯＰＳを完全に使いこなせるグループか、ＯＯＰＳ
をまったく使わないグループか、完全に分かれちゃっていて。プロフェッショ
ナル・レベルでの開発においては、混在している状況って経験ないんですよ。
でも、それで正解なんでしょうー。無用な混乱を避けるという意味で。

そもそも、日本でのＯＯＰＳ導入が遅れているってのが、問題点として上げれ
るとは思うんですけどね。８７、８年頃の僕の予想は、９４、５年ぐらいに開
発現場は、ＯＯＰＳでの開発が多数を占めるだろうと思っていました。所が、
遅々として進まずって所ですよね。

実は９１年に、アメリカまでいって、ランボーとブーチの各々のＯＯＤチュー
トリアルを受けてきたことがあるんですよ。その頃、日本では、「ＯＯＰなん
て遠い未来の話」なんて感じでしたけど、ランボーのセッションは５００名オー
バー、ブーチも同じぐらいで、壇上の講演者が、こんなちっちゃく（３ｃｍ）
ぐらいにしか見えませんでした。こんなに混むとは思っていなかったもんだか
ら、おもいっきり後ろしか席が空いていないという（笑）。あと、Ｃ＋＋で再
利用可能な上手なクラスライブラリの作り方とかいうセッションもいっぱい。
バシバシと現場への導入を現実問題として解決しようとしていました。

９１年でこれですから。ＯＯＰＳとかいった場合でも、アメリカなんかのバッ
クグラウンドは厚いんですよ。

最近、日本もやっと認知をうけたっていう感じですけど、いずれにせよ、つけ
焼き刃的にキャッチアップの効率化を考えても、厳しいよなー、とか思うわけ
です。

本質的には、パラダイムの導入だもんなぁー、真似っ子じゃすまないよなー、
と。

kuno> え、それってバグ本のことですか? 別の本かな…(どうもそういう本
kuno> の本棚をまじめに廻っていないので…)

えへへ。ちょっとテレますねー。

いままでソフトウェアの品質管理とかあまり興味のなかった現場の人でも、読
めるようにしたつもりだったのですが、どうやら開発プログラマーの開発裏話
暴露本だと思われているようです。悲しい。

まあ、自分としては、何年か手を染めていたソフトウェア工学（品質）を文章
にまとめて表に出せただけ幸せかなー、と思って慰めています。でも悲しい。

はーーーいかん。滅茶苦茶忙しい時にかぎって現実逃避でこんな長い文章を書
いてしまう。自分で自分の首を締めているなぁー。

ひろのぶ

[hagimoto]

　萩本です。

Hiroaki Nakamura wrote:

> 萩本さん:

> > 最近のオブジェクト指向手法における開発サイクルは、従来の開発手法で
> > 使いわけていたウォータフォールモデルとは異なり、『反復開発』『ラピッド・
> > プロトタイピング』といったスタイルが一般的に推薦されている。しかし、ほと
> > んどの方法論では、開発サイクルを開発プロセスの一環として解説されて
> > いない。
>

> UML の特徴のひとつに、ユースケースを基準にして
> 繰り返しを計画することがあげられます。たとえば
> 文献[1]の26ページから始まるPlanning の節に次の
> ように書いてあります。
>
> "The first step is to categorize the use cases."
> ... 途中、数ステップ ...
> "The next step is to assign the use cases to iterations."
> ... さらに数ステップ ...
>
> 文献[2]にはユースケースを基にして、オブジェクト指向
> 分析・設計・プログラミングのサイクルを２回転させる
> 様子が実例を通して詳細に書かれています。
>
> 御参考になれば幸いです。
>
> References
> [1] Martin Fowler and Kendall Scott, "UML Distilled,"
> Addison-Wesley, 1997, 0-201-32563-2.
> [2] Craig Larman, "Applying UML and Patterns,"
> Prentice Hall, 1998, 0-13-748880-7.
>
> 中村宏明
> イリノイ大学／日本ＩＢＭ

中村さん。最近だされた書籍を見ていないのでReferences
は参考になりそうです。どうもありがとうございます。

[hagimoto]

萩本です。

ku...@gssm.otsuka.tsukuba.ac.jp wrote:

> 久野です。
>
> いろいろ議論がはじまってますが、やっぱりOOPとソフトウェア工学
> とグループ分けたいなと思います。いかがですか? 反対の方います?
>
> そして、分けるとしたら、ソフトウェア工学のグループは

　そうですね。

>
>
> fj.comp.soft-eng
>
> でいいでしょうか? いかがですか? 反対の方います? いたら早急にお知
> らせください。

　私は賛成です。何かと利用することになりそうです。

[TANAKA Koji]

田中です。文献およびURLのご紹介、ありがとうございました＞ａｌｌ。参考にさ
せていただきます。

>> あちこちの本で散見される情報をもとに、
>
> どういう本を読まれましたか。参考になりますのでお教え頂けると嬉
>しいです。

「螺旋型開発」という語がでてきた本が２冊＝ほとんど出てきただけですが。
（ウェブスター「オブジェクト指向の落とし穴」プレンティスホール出版、ヨードン
「デスマーチ」トッパン）
「マイルストーン」という語がでてきた本が１冊。（Jim McCarthy「ソフトウェア
開発のダイナミズム」アスキー出版局）

これとは別に、ニフティのfprogproというフォーラムで、「スパイラル」「マイル
ストーン」「サイクル」などという言葉がさんざんでてきたのを読みました。

[S.Kubo]

もと記事無いけど・・・。

久野 wrote in message <6jvqsl$g...@utogw.gssm.otsuka.tsukuba.ac.jp>...
>ひろのぶさん:
>> で、ですね、OOA/OODがあって、OOPがあるなんていう人は、たぶん、
>> OOPS以外の手続き型言語あたりから入ってきて、パラダイムシフトが
>> 頭の中でできないままなので、それをどう形にするかというので、
>> OOA/OODなんてのを明確にした上じゃないと、恐くて入れないのだと
>> 想像します。
>
> お! これは新説ですね。

いや、その通りでしょう。

>> で、ですね、今はですね、いきなりC++しかやったことのない子とか
>> いるわけですよ。で、その子は、OOPSな考え方で始めから考えるわけ
>> です。OOAとかOODがなんてやらない。でも、OOPSで書くのに最も歪み
>> のない、ストレートな考え方をするから、というか、それしか知らな
>> いから。

これも、ひろのぶさんの言うとおりでしょう。
プログラム経験の無い人にシステムを与えて「ばらしてみて」と言うと
オブジェクト指向しているんですよね。
ちょっとでも経験があると悩み始める。
結局、両方のバランス感覚が問われるんだと思います。

> でもですねー。某大学あたりで1年生のプログラミング入門にC++とか
>してますけど、内容がCのanalogなんですよ。やっぱ教える方のパラダ
>イムシフトが必要だなーと。で、私はJavaとかしてますけど、いきなり
>教えるべきことが多くて結構苦戦してます。
教えるのは言語特性であって、考えの方は「修正」でしょう。
そこで自ら修正すべきことに気づかないと、普通（素直）にシステムを
考えていた時に戻れない。
難しいのは「コンピュータ的な思考に慣れた頭を、まだそれを知らなかった
頃にどんな発想をしていたか？」に戻すテクニックだと思います。
#本当に知らない人はプログラムが上から下へ流れることも知らないのです。

>> 明確な分析と設計の理論、あるいはスタイルが絶対的に必要になるの
>> は、複数人数でプログラム生産を行なう時の標準化の際だと思います。

必要と言うより指針程度だと私は捕らえています。

>> 明確な分析と設計の理論の導入には色々いいことあるんですけど、最
>> 低限ということで考えれば、共通のバックボーンを持たないことには、
>> 共通化したドキュメントが書けません。
話すら合わないこともあります。
#それにドキュメントフォーマットを指定される開発は避けたいですね。

> で、パラダイムシフトな人とそうでない人が一緒に仕事するときはど
>うするんですか? それが伺いたい。

一人の設計者が漠然と分解した抽象イメージを「ちょっとわかる人・わかる人」
に振り分け説明に回ります。その他の人は設計段階ではじゃまです。
#混乱させるだけ。コーディングまで待っていて・・・。
つまり、最初の設計者はシステムが漠然と見えていて、
各部を考えるときにするべき像が見える。
こうなると他人に任せきりにできず、最初の設計者は任せた人のところを
飛び回って与えた抽象イメージを「像に結ばせるため」に奔走します。
映画の監督のようなものでしょうか?作品は監督の頭にあり、スタッフは
意図に近づくようにする。監督はイメージをなんとか伝えようとする・・・。
当然、喧嘩も始まります。「なんでわからないの？」って。
だから、最初の設計者には強力な権限（決定権）が必要です。
#ちなみに、抽象イメージまでで開発する場合には
#「プロトタイプ手法」が有効でした。

>> 親しみ易いけど、真面目なソフトウェア工学の本を書いたつもりだっ
>> たけど、どうやら、業界暴露裏話本だと思われているので、ちょっと
>> 悲しい。

そもそも＊＊工学なんて、色々な知識・経験を集めたものに後から
言葉の定義を付けたり、もっともらしい数式なんか作るものです。
#「あの絵は何対何になっている」とか「椅子の高さはどうした」とか。
「業界暴露裏話本」でも立派な経験の蓄積だと思います。
むしろこっちのほうが面白い。

ソフトウェア工学ってニュースグループが「言葉の解釈」や「誰が言った」
なんて話題に終始するなら意味は無いと思うのですが・・・。
多数、あるいは個人での開発過程で生じた知恵袋的な議論だと楽しい。
#でも、最後は「・・・に書いてある」とかで終わるのかな?（引用ならいいけど）
知りたいのは議論に参加する人の「経験や主義」で、その違いを指摘したり、
受け入れたりするニュースグループなら良いなと・・・。

～～～～～～～～～～久保覚～～
＞・・＜。ｏＯ E-mail re...@big.or.jp (WEB)
ミ＿＿ミ E-mail p...@mfi.or.jp (Private)
URL http://www2.big.or.jp/~rest/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

[Oseto Futoshi]

大瀬戸です。
＃followup-to:はfj.comp.oopsです。

In article <3563BA...@psrc.isac.co.jp>, ki...@psrc.isac.co.jp says...

>大瀬戸さん wrote:
>> OOPをする際に一番問題となるのは、「何をオブジェクトとするか」
>> だと私は考えます。その際、分析が正しく出来てないと変な
>> オブジェクトが出てきそうな気がします。
>
>これはまさにそのとおりだと思いますが、

（中略）

>> 僕は後者の立場だから、「OOAの理解なしにOOPするのは危険」
>> という発想をします。
>
>私は「OOPの理解なしにOOAするのは危険」と考えています。

卵と鶏問題かな？って思ったけど、実は両方とも理解していないと
駄目なんですよね。

>やはり、プログラミング-設計-分析の順の方が理解しやすいのでは
>ないでしょうか。

歴史を紐解けば、OOPの方が先にあったからOOPの方が先に
理解し易いんでしょうね。
それで、いろいろ躓いて初めてOOAの必要性とかが理解できるでしょうね。
＃でも目先の納期の問題とかがあってなかなか手が付けられないのが実状だったり・・・。

教育上求められる要求と実務上（例えば企業内での量産品開発）必要な要求とは
違いますし、片方が他方より勝っている劣っているとも思いません。
ですから、
In article <6ju1bo$m...@bb.shinyoko.ricoh.co.jp>, os...@cs.ricoh.co.jp says...
>でも、同じ土俵で論じたらいけない
ですね。

In article <HIRONOBU.98...@h2np.h2np.suginami.removeme.tokyo.jp>, hiro...@h2np.suginami.removeme.tokyo.jp says...

>ところが、ＵＮＩＸ／Ｃで育ってきた子は、Ｃでスパゲッティーgotoなんか使
>うアホは滅多にいないし、何でも外部変数にしちゃったり、やたらと大きいモ
>ジュールを作っているヤツはあまりいない。で、これは、別に構造化設計論を
>やったからじゃないんすよ。これはＣのプログラミング・スタイルであり、パ
>ラダイムなわけです。自然となるようになる（でも、少数だがそうじゃないヤ
>ツもいる）。

プログラミングの善し悪しは決してプログラミングスタイルだけで解決するもの
じゃないと思うのですが如何でしょう。
もし、プログラミングスタイルだけで解決するのなら、分析なんか言い出す奴は
現れないとおもいます。
＃ダイクストラ（スペル失念）の後の時代の人ですよね、トム・デマルコって。

プログラミングの善し悪しは、モジュールとその周りのモジュールとの協調関係が
いかに無駄無く・判り易く・矛盾無くなっているかだと思いますが、これって
設計ですよね。
＃私の近くにいる新人くんは、よくコーディングしながら考えているので、私に
＃「コーディングしながら設計するな、ボケ！」と、良くどやされます。^^;

閑話休題

># バブル期の就職状況がよかったころ、採用面接にやってきた学生の
># 「自分は設計だけやるように教育されましたし、そのような業務だけ
># を行う立場になれる会社に就職したい、プログラミングはやりません」
># という趣旨の発言に唖然としたことがあります。

バカヤロウですね、そいつ。^^;;
「ソフト屋で入社したからハードは触らない」
なんてぬかしやがる奴はもう今は昔なのか。^^;;;

[SENOH Yasushi]

はじめまして、妹尾といいます。

＃ 私は OOP より前に OOA/D って思ってます。

S.Kubo wrote in message <6k3j6d$l...@mail.mfi.or.jp>...

>プログラム経験の無い人にシステムを与えて「ばらしてみて」と言うと
>オブジェクト指向しているんですよね。

これって、本当にそうなんでしょうか？

たとえば銀行のATM なんかを考えたとき、「ATM」と「ホスト
コンピュータ」なんてのをオブジェクトとして抽出したとしても、
それだけで「オブジェクト指向している」とは言えんですよね。

ちゃんと「顧客認証」とか「口座」とか「カード」(例えば家族カード
やカードを再発行した場合、口座は同じでもカードは区別したい
かもしれない)とか、払い出しなどの「トランザクション」とかも抽出
できるのかと言う事です。

一方、ケースにもよりますが、特別な事情がなければ「金額」、
「口座番号」、「パスワード」なんかはデータではあってもオブジェクト
ではないですよね。

で、そういった事も含めてシステムをきちんと合理的にオブジェ
クトに分割できる「プログラム経験の無い人」は、ほとんどいない
でしょう。

＃ ただし、プログラム経験がある人にデキる人が多いのかといえば、
＃ それは別問題で大問題 (-_-;)

>難しいのは「コンピュータ的な思考に慣れた頭を、まだそれを知らなかった
>頃にどんな発想をしていたか？」に戻すテクニックだと思います。

OOA/D は OOP よりもコンピュータに距離があるわけで、まさしく
「システマティックには考えるけど、コンピュータ的には考えない」、
1つの方法ではないでしょうか。私は、そう思ってます。
--
せのお http://www02.u-page.so-net.or.jp/xa2/senoh/

[SENOH Yasushi]

妹尾と言います。

＃ ひろのぶ さんの意見には、ちょっと疑問を感じます。

Hironobu Suzuki wrote in message ...

>ところが、ＵＮＩＸ／Ｃで育ってきた子は、Ｃでスパゲッティーgotoなんか使
>うアホは滅多にいないし、

「スパゲティ goto」と使う人は少なくても、やたらと「状態フラグ」を使って
処理の流れが複雑な実装をする人は、決して少なくないと思います。
また、関数の切り方が上手くないプログラマも多いです。

そんなワケで、C 育ちだからと言って構造化されたコードが書けるのか
と言えば、そんなコトはないと思います。これは OO に関しても同様だと
思います。

>別にＯＯＡとかＯＯＤとか一々面倒なことをいわ
>なくても、Smalltalkで、つまりＯＯＰでやろうとすると必然的／自然に、Ｏ
>ＯＡ／ＯＯＤなことをやるわけですね。

単にプログラム中でオブジェクトを使ったり定義したりすることを「OOA/
OODなこと」と言われているのだとすると違和感があります。それは
プログラミングレベルでの「オブジェクト」が、設計レベルにおいても
「オブジェクト」であるとは限らないからです。
--
せのお http://www02.u-page.so-net.or.jp/xa2/senoh/

[Shiino Masayoshi]

茶々です。

In article <HIRONOBU.98...@h2np.h2np.suginami.removeme.tokyo.jp> hiro...@h2np.suginami.removeme.tokyo.jp (Hironobu Suzuki) writes:
>親しみ易いけど、真面目なソフトウェア工学の本を書いたつもりだったけど、

ひろのぶさんがこんな物書いても興味はないけど、

>どうやら、業界暴露裏話本だと思われているので、ちょっと悲しい。

と書かれると読みたくなっちゃうじゃないですか :-p
# 愚痴に見せた巧妙な宣伝だろうか... :-)
--
椎野正元　（しいの　まさよし）

[Kazuhiro Fujieda]

藤枝＠ＪＡＩＳＴです。

In article <3564F908...@uiuc.edu>,
Hiroaki Nakamura <hnak...@uiuc.edu> wrote:

> UML の特徴のひとつに、ユースケースを基準にして
> 繰り返しを計画することがあげられます。たとえば
> 文献[1]の26ページから始まるPlanning の節に次の
> ように書いてあります。

これはUMLの特徴ではなくて、UMLをモデリング言語として用いる開発プロセ
ス「Rational Objectory Process」の特徴でしょう。

> [1] Martin Fowler and Kendall Scott, "UML Distilled,"
> Addison-Wesley, 1997, 0-201-32563-2.

の14ページで
Whatever process discussion there is, don't forget that you
can use any process with the UML.
と筆者が注意しているのに…
____
| ＡＩＳＴ 北陸先端科学技術大学院大学
| HOKURIKU 情報科学研究科 落水研究室
o_/ 1990 藤枝 和宏 fuj...@jaist.ac.jp

[S.Kubo]

SENOH Yasushi wrote in message <6k3vn7$di6$1...@news01bj.so-net.or.jp>...
>はじめまして、妹尾といいます。
どうも。

>＃ 私は OOP より前に OOA/D って思ってます。

#私はOOP、OOA、OOD に限った話をするつもりはありませんでした。
#フォローを付けた場所がいけなかったか。

>S.Kubo wrote in message <6k3j6d$l...@mail.mfi.or.jp>...
>
>>プログラム経験の無い人にシステムを与えて「ばらしてみて」と言うと
>>オブジェクト指向しているんですよね。
>
> これって、本当にそうなんでしょうか？

あらたまって「本当？」と言われると当然そうではありません。
言いたいのは物事を発想する思考が違うんですよね。
適切な例ではないかもしれませんが、ものを動かす場合。
「動かす->もの」が「もの->動かす」とか・・・・。
前者は典型的なコマンド指向で、コンピュータにとって都合が良いわけです。
１．コマンドでmoveを選択。
２．「どれか選択」なんて聞いてくる。（対応していないと「違う」と怒られる）
３．「どこへ」と指示をする。
先入観があると上のように発想するところを、
１．なにか選ぶ。
２．動かしてみる。
と単純に思うのです。（知らないってすごい）
そして、旧態のシステムを考える人から「どうやって？」とか
「違うデータがきたらどうするの？」なんて突っ込まれる。
そうして「ああ、コンピュータってこうやって動くんだ」と理解する。
そのうちに「モード中」なんて観念が入ったりしちゃう。

> たとえば銀行のATM なんかを考えたとき、「ATM」と「ホスト
>コンピュータ」なんてのをオブジェクトとして抽出したとしても、
>それだけで「オブジェクト指向している」とは言えんですよね。

まぁはじめの一歩でしょう。

> ちゃんと「顧客認証」とか「口座」とか「カード」(例えば家族カード
>やカードを再発行した場合、口座は同じでもカードは区別したい
>かもしれない)とか、払い出しなどの「トランザクション」とかも抽出
>できるのかと言う事です。

各種ノウハウでしょう。つまり、当然知らなければ無理。
もちろん、その時は銀行屋さんになったつもりになります。

> 一方、ケースにもよりますが、特別な事情がなければ「金額」、
>「口座番号」、「パスワード」なんかはデータではあってもオブジェクト
>ではないですよね。

ある特定の個人（ケース）をそのデータで扱う。
ある特定の個人（ケース）がそのデータを使った。
#ちょっと違うか・・・。何を言おうとしたんだっけ？

> で、そういった事も含めてシステムをきちんと合理的にオブジェ
>クトに分割できる「プログラム経験の無い人」は、ほとんどいない
>でしょう。

それは、コンピュータに実装するときの話ですね。
ATMにだけ詳しい人でもシステムは作れる。（プログラムするじゃないです）
#通常はコンピュータ屋さんに「そう言う訳にはいかない」なんて言われる。
#もちろん、「それじゃ操作が統一されていない」とかの提言はしますが。

>＃ ただし、プログラム経験がある人にデキる人が多いのかといえば、
>＃ それは別問題で大問題 (-_-;)

プログラムしかできないからでしょう。大問題です。

>>難しいのは「コンピュータ的な思考に慣れた頭を、まだそれを知らなかった
>>頃にどんな発想をしていたか？」に戻すテクニックだと思います。
>
> OOA/D は OOP よりもコンピュータに距離があるわけで、まさしく
>「システマティックには考えるけど、コンピュータ的には考えない」、
>1つの方法ではないでしょうか。私は、そう思ってます。

まぁ、OOPに限定して投稿したわけじゃないので・・・。
流れとしては、コンピュータ屋さんのノウハウ（蓄積）が違う分野の専門家
に違和感無く利用されていくんだと思います。
今まで「コンピュータのプログラムができる」と言う聖域のみに頼っていた人は
どこまでその聖域を保てるんだろう?

[Hironobu Suzuki]

>>>>> "SE" == SENOH Yasushi <se...@xa2.so-net.or.jp> writes:
In article <6k3vn7$di6$1...@news01bj.so-net.or.jp> "SENOH Yasushi" <se...@xa2.so-net.or.jp> writes:
SE> OOA/D は OOP よりもコンピュータに距離があるわけで、まさしく「シ
SE> ステマティックには考えるけど、コンピュータ的には考えない」、1つの
SE> 方法ではないでしょうか。私は、そう思ってます。

「何をコンピュータ的であるのか」という問題があるわけですが、ここでは
「（ベタな）データの流れとその処理フロー」というのがここでの「コンピュー
タ的」という具合に解釈して話を進めます。

まず、答えを先からいうと、それは本当のようなウソだと思います。

たまたま、コンピュータがまだ高価だった頃、科学技術データ計算のFORTRAN
と、事務データ処理のためのCOBOLというのが、利用の中心だったという歴史
上の事実はありますが、これらは、コンピュータ的で、それ以外がコンピュー
タ的ではなかったというわけではありません。

たとえば、６０年代前半に既にSIMULA Iはありましたし、現在のオブジェクト
とクラスの概念を確定させたといってもいい、SIMULA 67は名前の通り６７年
です。

単に、歴史的にみて、コンピュータの利用が、ある１社、（それはＩＢＭなん
ですが）が提供する、計算モデルと、その応用だけが、一般に広がっていただ
けで、それがあたかも、コンピュータという、あるいはプログラミングという
もののすべてであるかのような幻想を多くの人が持っているだけでしょう。

北欧には、６０年代のSIMULAの流れを汲む研究グループが延々と研究を続けて
おり、８０年代にBETAというＯＯＰ言語を作りました（バックグラウンドには、
ミヨルナー・プロジェクトという北欧の官学民のソフトウェア工学のプロジェ
クトがあります）。

このマニュアルや、解説書を読んでいると、SIMULAの怨念、もとい、SIMULAの
頃からあるコンセプトは、延々、脈々と流れています。彼等の言うポイントは
「フェノミナー（事象）を捉えよ」です。もうちょっと、正確に書くために、
今、古い本を探しているのですが、で、みつけたのが1990のBETAのマニュアル
ですが、ここにはこんな風に

DESIGN
...
At this level the object-oriented program will be a description
of phenomena and concepts from application domain.
...

それを提供できるプログラミング環境は、十分にコンピュータのやるべき仕事
で、それは、科学技術データ計算のためのプログラミング環境、事務データ処
理のためのプログラミング環境と、何の違いもありません。

ただし、６０年代からあったといっても、多くの人には知られていませんし、
また使われていませんし、世界中のコンピュータ環境を独占的にサプライして
いた会社からは、これらのプログラミング環境はサポートされませんでした。

ただ、それだけです。僕に言わせれば「あった。でも知られていなかった。」
だけです。

SIMULA 67でプログラムした人を
１人しか知らない
ひろのぶ

[Hironobu Suzuki]

>>>>> "Shiino" == Shiino Masayoshi <alc...@soe.ty.ihi.co.jp> writes:
In article <51...@moliere.soe.ty.ihi.co.jp> alc...@soe.ty.ihi.co.jp (Shiino Masayoshi) writes:
>> 親しみ易いけど、真面目なソフトウェア工学の本を書いたつもりだったけ
>> ど、

Shiino> ひろのぶさんがこんな物書いても興味はないけど、

ショック;-<

>> どうやら、業界暴露裏話本だと思われているので、ちょっと悲しい。

Shiino> と書かれると読みたくなっちゃうじゃないですか :-p

と、期待したら書いていることは、いたって真面目だから、つまらないと思う
よ。

Shiino> # 愚痴に見せた巧妙な宣伝だろうか... :-)

３年間過ぎた今も在庫が自室に山積みで.....というのはウソです。あんまり
悪ノリして、ふざけて書いていたら、共著者の加藤さんに悪いので、このヘン
で。

どうやら、最近の僕は、
テクニカル・ライターだと
思われているらしい

ひろのぶ

[SENOH Yasushi]

妹尾です。

S.Kubo wrote in message <6k46sf$u...@mail.mfi.or.jp>...

>SENOH Yasushi wrote in message <6k3vn7$di6$1...@news01bj.so-net.or.jp>...
>

>>>プログラム経験の無い人にシステムを与えて「ばらしてみて」と言うと
>>>オブジェクト指向しているんですよね。
>>
>> これって、本当にそうなんでしょうか？
>あらたまって「本当？」と言われると当然そうではありません。

ですよね。やっぱり「初心に返ったプロ(または求道者)」と
「単なる初心者」は違いますよね。

>言いたいのは物事を発想する思考が違うんですよね。
>適切な例ではないかもしれませんが、ものを動かす場合。
>「動かす->もの」が「もの->動かす」とか・・・・。
>前者は典型的なコマンド指向で、コンピュータにとって都合が良いわけです。

(以下略)

なんとなく雰囲気は伝わってきます。ただ、シロートさんが、あたかも
オブジェクト指向であるかのように考えられるのは、このような簡単な
ケースに限られるのだとも思います。

>> で、そういった事も含めてシステムをきちんと合理的にオブジェ
>>クトに分割できる「プログラム経験の無い人」は、ほとんどいない
>>でしょう。
>
>それは、コンピュータに実装するときの話ですね。

「ほとんどいない」ってのは言い過ぎですね。忘れてください。(^^;)

例えば カード -> 通帳、パスワード->印鑑 てな具合にすると、ATMは
窓口のおねーさん てなことになります。で、この銀行が前近代的で
すべて手作業でやっているとしても、「口座」「顧客認証」「トランザクション
(伝票？)」はオブジェクトとして存在します。

と言うわけで、コンピュータへの実装上の話と言うことでもないです。

以下余談：

>今まで「コンピュータのプログラムができる」と言う聖域のみに頼っていた人は
>どこまでその聖域を保てるんだろう?

別に伝統芸能みたく長い歴史があるわけでなし、いいんじゃないですか。
保てなくても。
--
せのお http://www02.u-page.so-net.or.jp/xa2/senoh/

[SENOH Yasushi]

妹尾です。

Hironobu Suzuki wrote in message ...
>

> SE> OOA/D は OOP よりもコンピュータに距離があるわけで、まさしく「シ
> SE> ステマティックには考えるけど、コンピュータ的には考えない」、1つの
> SE> 方法ではないでしょうか。私は、そう思ってます。
>
>「何をコンピュータ的であるのか」という問題があるわけですが、

そうですね。きちんと書かなくってごめんなさい。

>ここでは
>「（ベタな）データの流れとその処理フロー」というのがここでの「コンピュー
>タ的」という具合に解釈して話を進めます。
>
>まず、答えを先からいうと、それは本当のようなウソだと思います。

つまり、「コンピュータ」は、ここで言う「コンピュータ的」なものとは、必ずし
も
一致しないということでしょうか。で、SIMULA は昔から「コンピュータ的」では
なかったと言う事ですよね。

私は、「コンピュータ的」と言うのを「コンピュータ上への具体的な実装方法」
と言うような意味で使いました。と言うわけで、この定義では SIMULA と言えども
それで実装する場合は「コンピュータ的」に考えることになります。

で、私が言いたかったのは、OOA/OODは 実装とは距離を置いた所で、
システム化の課題・要求を整理しやすいのではないかなぁと言う事です。

そして、これは

<久保 さん>

| 難しいのは「コンピュータ的な思考に慣れた頭を、まだそれを知らなかった
| 頃にどんな発想をしていたか？」に戻すテクニックだと思います。

に通じる所があるのではないかと思うわけです。
--
せのお http://www02.u-page.so-net.or.jp/xa2/senoh/

[Nobukuni Kino]

大瀬戸さん wrote:

> プログラミングの善し悪しは、モジュールとその周りのモジュールとの協調関係が
> いかに無駄無く・判り易く・矛盾無くなっているかだと思いますが、これって
> 設計ですよね。

私は教育のときにモジュール強度、独立性、結合度の話を先にします。
＃大昔の用語なので御存知無い方もいらっしゃるかも知れませんが
OO技術に行きつくまでの過程を知っていた方が理解が深いと
考えるからです。そして、この種のパラダイムが変遷して行くことも
わからせます。

> ＃私の近くにいる新人くんは、よくコーディングしながら考えているので、私に
> ＃「コーディングしながら設計するな、ボケ！」と、良くどやされます。^^;

あは、「この大きさのプログラムを設計なしで書き下ろせるようになるのは
君の場合何年先かな？」というのが、プログラミング演習の講評で
良く使う言葉かな？

> 閑話休題
>
> ># バブル期の就職状況がよかったころ、採用面接にやってきた学生の
> ># 「自分は設計だけやるように教育されましたし、そのような業務だけ
> ># を行う立場になれる会社に就職したい、プログラミングはやりません」
> ># という趣旨の発言に唖然としたことがあります。
>
> バカヤロウですね、そいつ。^^;;

この種の人物のなれの果てが実際に「設計」してるのに出会うことが
現実にあります。
「ここまで分析と設計ができていますので、プログラミングの見積りを
　お願いします」などという仕事が舞い込んだりしますが、その会社で
採用している手法どおりにきれいに書かれた「設計文書」には、
魂が入っていないことがすぐわかります。
あとで酒席で聞いてみると設計担当者は「プログラミングはほとんど
やったことがありません」ということで、なれの果てであることが
暴露されます。
＃この仕事、知り合いの会社に流したら結局大きな仕事になりました。
＃分析・設計を行ったところははずされて、仕掛けの選定からやり直し
＃たそうです。大変だったそうですけど。

--
(株)アイザック　紀　信邦　http://www.isac.co.jp/

[SENOH Yasushi]

妹尾といいます。

＃ ちょっとだけ横入りします :-p

Nobukuni Kino wrote in message <3568C1...@psrc.isac.co.jp>...
>
>この種の人物のなれの果てが実際に「設計」してるのに出会うことが
>現実にあります。

現実問題としてこの手の人に 「なれの果て」が多いのは想像が
つきますが、「(プログラミングもできるけど)設計しかしない」と言う
態度は、あっていいと思います。私自身、そういうの目指してますし。

>「ここまで分析と設計ができていますので、プログラミングの見積りを
>　お願いします」などという仕事が舞い込んだりしますが、その会社で
>採用している手法どおりにきれいに書かれた「設計文書」には、
>魂が入っていないことがすぐわかります。

やっぱり「プログラムの神は細部に宿る」と言うか、ありますよね。
「魂」は正しく悩んだ分だけ育つものでしょうし。

＃ OOと関係なくなってしまったが、どこにふって良いのか解らない (^_^;)
--
せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/

[Hirotaka Yoshioka]

よしおかともうします．

しがないプログラマをしてます．

"SENOH Yasushi" <se...@xa2.so-net.or.jp> writes:

> 妹尾といいます。

> Nobukuni Kino wrote in message <3568C1...@psrc.isac.co.jp>...
> >この種の人物のなれの果てが実際に「設計」してるのに出会うことが
> >現実にあります。
> 現実問題としてこの手の人に 「なれの果て」が多いのは想像が
> つきますが、「(プログラミングもできるけど)設計しかしない」と言う
> 態度は、あっていいと思います。私自身、そういうの目指してますし。

プログラミングと設計ってそもそも分離可能なもんなんでしょうか？
分離可能だというのを信じるとウォータフォールになるし，なんか
どーもよくわからんというスタンスだとちがったスタイルになりそーだし．

プログラミングのうらづけのない設計ってゴミみたいなもんだと
思っているので，なんか分離可能つーのが信じられないんですね．

よ

[Hirotaka Yoshioka]

よしおかともうします．

Nobukuni Kino <ki...@psrc.isac.co.jp> writes:

> 大瀬戸さん wrote:
> > 閑話休題
> >
> > ># バブル期の就職状況がよかったころ、採用面接にやってきた学生の
> > ># 「自分は設計だけやるように教育されましたし、そのような業務だけ
> > ># を行う立場になれる会社に就職したい、プログラミングはやりません」
> > ># という趣旨の発言に唖然としたことがあります。
> >
> > バカヤロウですね、そいつ。^^;;
>
> この種の人物のなれの果てが実際に「設計」してるのに出会うことが
> 現実にあります。

．．．

> 　お願いします」などという仕事が舞い込んだりしますが、その会社で
> 採用している手法どおりにきれいに書かれた「設計文書」には、
> 魂が入っていないことがすぐわかります。

> あとで酒席で聞いてみると設計担当者は「プログラミングはほとんど
> やったことがありません」ということで、なれの果てであることが
> 暴露されます。

ちょっと質問なんですけど，米国でソフトウェア製品作っているところって，設
計とコーディングを分離しているのってほとんど見たことがないんです．大抵，
設計した人がプログラミングする．だもんだから設計担当者がプログラミングし
たことないなんてのはほとんどありえない話なんですけど．

あつかってい対象が，違うのかな．日本でも商用パッケージ作っているところは，
設計とコーディングが一緒ですかね．

そもそも，設計書しかかないハッカーとかいたらわらっちゃいますよね．日本に
は企業にハッカー文化がないつーことか．

よ

[Oseto Futoshi]

大瀬戸です。

In article <g3bhg2c9z...@dlsun329.us.oracle.com>, hyos...@us.oracle.com says...

>ちょっと質問なんですけど，米国でソフトウェア製品作っているところって，設
>計とコーディングを分離しているのってほとんど見たことがないんです．大抵，
>設計した人がプログラミングする．だもんだから設計担当者がプログラミングし
>たことないなんてのはほとんどありえない話なんですけど．

そうかもしれませんね。
特に、米国はベンチャー企業を起こすのが盛んな国ですから、
一人で全部なんでもこなす人ってのが多そうですね。

>あつかってい対象が，違うのかな．日本でも商用パッケージ作っているところは，
>設計とコーディングが一緒ですかね．

あっ、これって、設計＊者＊とコーディング＊者＊が一緒って意味ですよね。
設計しながらコーディングしながら設計しながら・・・って意味じゃないですよね。
＃こういうと、スパイラル開発と混同されますね。そういう意味じゃないです。

>そもそも，設計書しかかないハッカーとかいたらわらっちゃいますよね．日本に
>は企業にハッカー文化がないつーことか．

ある面では、企業にとってハッカー文化は邪魔なのかもしれません。
＃もちろん、ハッカーを禁止しているわけじゃないです。

[Yukihiro Matsumoto]

まつもと ゆきひろです

os...@cs.ricoh.co.jp (Oseto Futoshi) writes:

|大瀬戸です。

|>あつかってい対象が，違うのかな．日本でも商用パッケージ作っているところは，
|>設計とコーディングが一緒ですかね．
|
|あっ、これって、設計＊者＊とコーディング＊者＊が一緒って意味ですよね。
|設計しながらコーディングしながら設計しながら・・・って意味じゃないですよね。

設計とコーディングってそんなに分離すべき工程なんでしょうか．
外部仕様決めやテストは明確に分離すべきでしょうが．

私はプログラムは究極の仕様書だと思ってますが，それは文化の違
いなんでしょうか．

[SENOH Yasushi]

妹尾です。

Hirotaka Yoshioka wrote in message ...

>> 現実問題としてこの手の人に 「なれの果て」が多いのは想像が
>> つきますが、「(プログラミングもできるけど)設計しかしない」と言う
>> 態度は、あっていいと思います。私自身、そういうの目指してますし。
>
>プログラミングと設計ってそもそも分離可能なもんなんでしょうか？
>分離可能だというのを信じるとウォータフォールになるし，なんか
>どーもよくわからんというスタンスだとちがったスタイルになりそーだし．

そうですか？

>プログラミングのうらづけのない設計ってゴミみたいなもんだと
>思っているので，なんか分離可能つーのが信じられないんですね．

「(この設計で)プログラミングが可能である事を示す」のと
「プログラムを書く」のは違うと思うので、これだけから
「分離不可能」とは言えないのではないででしょうか。

[Hirotaka Yoshioka]

よしおかです．

Yukihiro Matsumoto <ma...@netlab.co.jp> writes:
> まつもと ゆきひろです
> |大瀬戸です。

こんちわ

> |>あつかってい対象が，違うのかな．日本でも商用パッケージ作っているところは，
> |>設計とコーディングが一緒ですかね．
> |あっ、これって、設計＊者＊とコーディング＊者＊が一緒って意味ですよね。
> |設計しながらコーディングしながら設計しながら・・・って意味じゃないですよね。
> 設計とコーディングってそんなに分離すべき工程なんでしょうか．
> 外部仕様決めやテストは明確に分離すべきでしょうが．

よくわからないのですけど，シュリンクラップつくっているところって，外部仕
様きまったら，あとは適当に，モジュールオーナーが設計して，コードも書くつー
スタイルがわりと一般的な感じがしてます．原子力発電所とか飛行機の制御とか
のプログラムの作りとちがって，そこそこの品質のものをタイムリーに出すつー
方がともかく必要ですから．

でもってプログラムをスクラッチから作るというのはありえなくて，前のバージョ
ンからの拡張とか修正とかだから，つねに動くものがあるんですよね．だからな
んか設計しているのだかハックしているのだか，(はたから見たら)よくわからな
いんだけど，ともかく雪ダルマ式に機能が増えていくような感じっすね．

そーゆー開発スタイルでは設計者とプログラマを分離するなんてナンセンスです
よね．あ，そーゆー話じゃない？

> 私はプログラムは究極の仕様書だと思ってますが，それは文化の違
> いなんでしょうか．

日本で，そーゆースタイルの開発ができない理由ってあるんでしょうか？プログ
ラマがいないつーのならなんとなくわかるような気がするけど．でも，そんなこ
とないですよね．

よ

[Oseto Futoshi]

大瀬戸です。

In article <lvwwb7c7...@picachu.netlab.co.jp>, ma...@netlab.co.jp says...
>設計とコーディングってそんなに分離すべき工程なんでしょうか．

例えば、
リアルタイム制御の場合、各スレッドは独立に動作するのではなく、
お互いに協調しあいながら動作します。ただその場合、単に
機能達成だけが求められるのではなく、応答時間やスレッドの処理時間
等の要求値を満たす必要があります。特に組み込み機器の場合はそれに
加えて、プログラムサイズ・メモリサイズの制限が加わります。
そのため、単に＊動けば良い・早ければ良い＊と言うのではなく、
各モジュール間での処理の割り振り方などが非常に重要になってきます。
＃別にオブジェクト指向に限った話ではないのでモジュールと呼びます

最近はディスプレイの性能も高くなってきたので、複数のウィンドウを
開いて且つ沢山の行数のソースコードが眺められるようになってますが、
それでも見られる範囲は全然狭いです。

だから、（必要な範囲で）各モジュール群＊全体を見渡して＊、
何処で何をするかと言う方針の決定はソースコードを書く
段階では、（天才か超努力家以外の普通の人では）無理
じゃないかなと思います。
だから、コーディング以前に設計というステップが必要だと思います。

>私はプログラムは究極の仕様書だと思ってますが，それは文化の違
>いなんでしょうか．

さぁどうでしょう。
「仕様」の解釈の違いが文化の違いから来るのであればそうかもしれません。
僕の認識では、仕様書はプログラムの達成すべき目標を書いたものであって
結果そのものではないと思います。
＃「それは仕様です。」と言う（迷）文句が文化の違いを表わしてるの
＃かも知れませんね。

[Hoshi Takanori]

ほし＠えすあーるえーです。

＃ やっぱり cd /usr/spool/news して grep できないのは不便だなあ。

In article <HIRONOBU.98...@h2np.h2np.suginami.removeme.tokyo.jp>
hiro...@h2np.suginami.removeme.tokyo.jp (Hironobu Suzuki) writes:

> で、ですね、ＯＯＡ／ＯＯＤがあって、ＯＯＰがあるなんていう人は、たぶ
> ん、ＯＯＰＳ以外の手続き型言語あたりから入ってきて、パラダイムシフトが
> 頭の中でできないままなので、それをどう形にするかというので、ＯＯＡ／Ｏ
> ＯＤなんてのを明確にした上じゃないと、恐くて入れないのだと想像します。

これ読んで救われました。どーも OOA/OOD の本読んでもすんなり
頭に入ってこないなあと思ってたんだけど、そういうことだったん
ですね。

唯一すんなり読めたのが Design Patterns で、ぼろくそに言う人も
いるみたいだけど、これこそがまさに

> 別にＯＯＡとかＯＯＤとか一々面倒なことをいわ
> なくても、Smalltalkで、つまりＯＯＰでやろうとすると必然的／自然に、Ｏ
> ＯＡ／ＯＯＤなことをやるわけですね。

ってことなんでしょうね。で、パラダイムシフトしてない人から
見るとなんじゃこりゃ、になると。

> 混沌設計論の時代から、構造化設計論に移った頃もやはり同じような議論を
> しています。

もともとプログラミングってのは、ふつーの人間の思考からかけ
離れたところから出発して、段々人間の思考に近付いてきている、
ってなとこでしょうか。

＃ なんか、とんでもない誤解をしてるのかも...

ほし

[Yukihiro Matsumoto]

まつもと ゆきひろです

"SENOH Yasushi" <se...@xa2.so-net.or.jp> writes:

|妹尾です。

|>プログラミングと設計ってそもそも分離可能なもんなんでしょうか？
|>分離可能だというのを信じるとウォータフォールになるし，なんか
|>どーもよくわからんというスタンスだとちがったスタイルになりそーだし．
|
| そうですか？

| 「(この設計で)プログラミングが可能である事を示す」のと

|「プログラムを書く」のは違うと思うので、これだけから
|「分離不可能」とは言えないのではないででしょうか。

原理的には可能ですから，私は分離不可能であるとまでは思わない
んですが，多くの場合で分離することには意味が無いとは思います．
また，日本の企業風土かなにかで分離することに意味が無い場合ま
で，設計とプログラミングを分離して「損して」いることはあるよ
うに思います．

どうやら「ウォーターフォールじゃいかん」ってのは周知の事実に
なったようですが，その場合実装やさまざまな事情によって，プロ
グラミングと設計の間の手戻りがかなり発生するはずですよね．そ
の場合，設計とプログラミングを分離することはたんにコミュニケー
ションコストを増大させるだけだと思います．

分離すべきは，前段階の「外部仕様の決定」「モジュール間のイン
ターフェースの決定」レベルか，後段階の「テスト」などでしょう．
前段階は手戻りが頻繁に発生しちゃいかんはずなんで，分離に問題
ないですし，後段階は分離しないと先入観から問題を見逃しちゃう
恐れがありますよね．

んで，日本で設計とプログラミングを分離したがるのは企業の中に
「設計者(SE)」と「プログラマ(PG)」という一種の身分制度が存在
しているからではないかと憶測しているのです．日本ってプログラ
マの地位が低いですよね．
まつもと ゆきひろ /:|)

[Yukihiro Matsumoto]

まつもと ゆきひろです

Hirotaka Yoshioka <hyos...@us.oracle.com> writes:

|こんちわ

こんにちは

|よくわからないのですけど，シュリンクラップつくっているところって，外部仕
|様きまったら，あとは適当に，モジュールオーナーが設計して，コードも書くつー
|スタイルがわりと一般的な感じがしてます．原子力発電所とか飛行機の制御とか
|のプログラムの作りとちがって，そこそこの品質のものをタイムリーに出すつー
|方がともかく必要ですから．

ええ，そうだとは思いますが，元々の発言された方や日本の多くの
「SE」はそもそもシュリンクラップのプログラムの開発にたずさわっ
たことはほとんどないのではないか，と推測します．

|そーゆー開発スタイルでは設計者とプログラマを分離するなんてナンセンスです
|よね．あ，そーゆー話じゃない？

ですから，そーゆー開発スタイルはあんまりないみたいなんですよ
ね．で，得意ワザは「原子力発電所とか飛行機の制御とかのプログ
ラム」なんで，そーゆーのが必要でない(むしろジャマになる)局面
でも，設計者とプログラマを分離しちゃうんじゃないか，と思うの
です．

|日本で，そーゆースタイルの開発ができない理由ってあるんでしょうか？プログ
|ラマがいないつーのならなんとなくわかるような気がするけど．でも，そんなこ
|とないですよね．

企業としての設計者とプログラマ(コーダー)の分化が進んでしまっ
て，取り返しがつかないのじゃないかなあ．憶測ですが．

まつもと ゆきひろ /:|)

[Yukihiro Matsumoto]

まつもと ゆきひろです

ho...@sra.co.jp (Hoshi Takanori) writes:

|ほし＠えすあーるえーです。

|これ読んで救われました。どーも OOA/OOD の本読んでもすんなり
|頭に入ってこないなあと思ってたんだけど、そういうことだったん
|ですね。
|
|唯一すんなり読めたのが Design Patterns で、ぼろくそに言う人も
|いるみたいだけど、これこそがまさに

(後略)

あ，まったく同感です．同士よっ！

迷惑でした？
まつもと ゆきひろ /:|)

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

ho...@sra.co.jpさん:
> これ読んで救われました。どーも OOA/OOD の本読んでもすんなり頭
> に入ってこないなあと思ってたんだけど、そういうことだったんです
> ね。

どうだかわかんないけど、OOA/OODが嫌いでも全然恥じることじゃな
いと思いますよ。私は嫌いだー(ソフトウェア工学はほとんどみんな。
というとまた物議!? まあ自分の趣味じゃないということで)。

> 唯一すんなり読めたのが Design Patterns で、ぼろくそに言う人も
> いるみたいだけど、これこそがまさに

...

> ってことなんでしょうね。で、パラダイムシフトしてない人から見る
> となんじゃこりゃ、になると。

Design Patterns批判ってどんなことが言われているんですか?

あれは万能じゃないけど「なーるほど!」って楽しいですよね。でも
ガンマ本は精選されたパターンだからいいけど、PLoP(Pattern
Languages of Program Design)は読みかけてめげました。辞書を読むよ
うなもんか。

> もともとプログラミングってのは、ふつーの人間の思考からかけ離れ
> たところから出発して、段々人間の思考に近付いてきている、ってな
> とこでしょうか。

私は違う見かたをしてます。初期のプログラミングはハードウェアの
限界内で動かせることが優先されたけど、ハードウェアが強力になり、
かつソフトウェアが複雑になるにつれて、人間が習熟している領域にプ
ログラミングが歩み寄らなければ人間の手に負えなくなってそういう方
向に変化しているのだと思います。

> ＃ なんか、とんでもない誤解をしてるのかも...

誤解してるとすれば、どーいう? :-) 久野

P.S. 上の帰結として、プログラムはどんどん芸術に近くなっていくの
かも知れない。芸術の歴史は古いですからねー!

[Nobukuni Kino]

アイザックの紀です。たびたびお邪魔します。

まつもと ゆきひろさん：

> んで，日本で設計とプログラミングを分離したがるのは企業の中に
> 「設計者(SE)」と「プログラマ(PG)」という一種の身分制度が存在
> しているからではないかと憶測しているのです．日本ってプログラ
> マの地位が低いですよね．

そのとおり。企業の中に身分制度があるだけでなく、企業間にも
上流と下流の身分があります。

私のところでは部分的な工程の受注をほとんどやらなくなりまし
たが、日本の世の中では、受発注関係で上流にある会社が
工程上の上流を、下流にある会社が工程上の下流を分担する、
同時に作業単価も下流の方が安いという商習慣がいまでも
あると思います。
だいたい、分析・設計・プログラミング・テストなんていう
工程別の単価表があって、当社ではプログラミングはｘｘ万円/月
だからその単価で見積もるように、などという神話級のやりかたが
いまでもあるんです。これじゃ、ソフト業界はまともな産業に
育たないですよね。

本当にあった笑い話のような話をひとつ。
顧客「見積りは分析・設計・プログラミング・テストに分けて明細を
　　　つけてください」
某社「当社ではそういう工程では開発していません」
顧客「その形式で無いと購買が通らないんです」
某社「わかりました、形式をあわせましょう」
...見積り提出
顧客「この見積りで結構ですがテストのところはいりません。
　　　うちでやりますから」
...受注確定

開発工程の認識の差はともかく、「某社」の方では「テスト工数」に
見積りの多くの部分を割り当てていたので相当値切られた形です。
「顧客」がテストなんかやらなかったのは言うまでもありません。
（なんでそんな妙な受注があり得たか？　その辺の事情は知りません）

私は、スパイラルならテスト工程の実施を分離できると思います。
一種のコンカレントエンジニアリングの形態でプログラミングと
テストを同時に行えるようになれば良いと考えています。
ウオーターフォールでは分離は現実的に効率が良くないでしょう。
一方、手戻りが少ないはずの上流工程は（どのモデルでも）分離
しやすいのでしょうが、個人の技量に出来が左右されるところが
大きいんでしょうね。次工程での実装が読めていない人の下流には
なりたくないです。

＃　上流とか下流とか、「上下」の字を使うからいけないのかな
--
(株)アイザック　プログラマ　紀　信邦

[Yukihiro Matsumoto]

まつもと ゆきひろです

os...@cs.ricoh.co.jp (Oseto Futoshi) writes:

|大瀬戸です。

|だから、（必要な範囲で）各モジュール群＊全体を見渡して＊、

|何処で何をするかと言う方針の決定はソースコードを書く
|段階では、（天才か超努力家以外の普通の人では）無理
|じゃないかなと思います。
|だから、コーディング以前に設計というステップが必要だと思います。

そこまでは否定しません．私も「外部仕様の決定」や「モジュール
分割」は分離できると述べました．が，普通「設計」というとそれ
より踏み込んだプログラミングの一歩手前まで含みませんか？

そのような(詳細)設計は分離すべきではないというのが，私の主張
です．

[SENOH Yasushi]

妹尾です。

Yukihiro Matsumoto wrote in message ...

>| 「(この設計で)プログラミングが可能である事を示す」のと
>|「プログラムを書く」のは違うと思うので、これだけから
>|「分離不可能」とは言えないのではないででしょうか。
>
>原理的には可能ですから，私は分離不可能であるとまでは思わない
>んですが，多くの場合で分離することには意味が無いとは思います．

なんていうか、実感として肌に染み込んでくる意見ですね。

カタチ(例えば書類)の上で分離する事には、私も意味を感じません。
ただ、実装の都合でいつのまにか設計が変わっている(無視されている)
と言う事はあってはならないので、ココロの持ち方として、この分離は
重要ではないかと。

一応断っておきますが、実装上問題が出たときに、設計まで振り返って、
設計を変更し、実装するのは否定してません。

むしろ、カタチの上での分離は、実装→設計へのフィードバックが
しにくくなり、結果として「設計が無視される」と言った事態を起こしやすい
のではないかと思います。ただ、こうした「カタチ」の話は、「設計論」では
なく「プロジェクトマネージメント」の話ではないかとも思います。

>どうやら「ウォーターフォールじゃいかん」ってのは周知の事実に
>なったようですが，その場合実装やさまざまな事情によって，プロ
>グラミングと設計の間の手戻りがかなり発生するはずですよね．そ
>の場合，設計とプログラミングを分離することはたんにコミュニケー
>ションコストを増大させるだけだと思います．

まさしく。

>んで，日本で設計とプログラミングを分離したがるのは企業の中に
>「設計者(SE)」と「プログラマ(PG)」という一種の身分制度が存在
>しているからではないかと憶測しているのです．日本ってプログラ
>マの地位が低いですよね．

うーん、微妙なトコロですね。

とりあえず、正論を吐いておくと、「優れた設計者」と「優れたプロ
グラマ」では、「優れた設計者」の方が優遇されて良いんじゃないで
しょうか。

ただ、プログラミングは「プログラミング」を知らないと出来ないのに
対して、設計は「設計」をしらなくても「できて」しまいますし、これが
結果として「プログラミングはできないから設計でもする」なんて事態を
招く事もあるかと。

＃ まぁ、「仮定」の話ですから。そういうことで。

[Oseto Futoshi]

大瀬戸です。

In article <lvsoltd9...@picachu.netlab.co.jp>, ma...@netlab.co.jp says...
>どうやら「ウォーターフォールじゃいかん」ってのは周知の事実に
（中略）

>
>分離すべきは，前段階の「外部仕様の決定」「モジュール間のイン
>ターフェースの決定」レベルか，後段階の「テスト」などでしょう．
>前段階は手戻りが頻繁に発生しちゃいかんはずなんで，分離に問題
>ないですし，後段階は分離しないと先入観から問題を見逃しちゃう
>恐れがありますよね．

そうやって分離するのが「ウォーターフォール」だと思いますが。
そして、「スパイラル開発」がモジュール内でプログラミングと
設計との間の手戻りをすることではないと思っていたのですが。

認識を変えるべきでしょうか。

閑話休題

確認ですが
In article <lvsoltd9...@picachu.netlab.co.jp>, ma...@netlab.co.jp says...

>なったようですが，その場合実装やさまざまな事情によって，プロ
>グラミングと設計の間の手戻りがかなり発生するはずですよね．そ

でいう、プログラミングと設計は作業のことで

>の場合，設計とプログラミングを分離することはたんにコミュニケー
>ションコストを増大させるだけだと思います．

でいう、設計とプログラミングは担当者のことですよね。
ちょっと混乱してきたもので。

[SENOH Yasushi]

妹尾です。

＃ ポストに失敗したみたいで、もう一度出します。
＃ もし二度見た方がいらっしゃいましたらごめんなさい。

Yukihiro Matsumoto wrote in message ...

>| 「(この設計で)プログラミングが可能である事を示す」のと
>|「プログラムを書く」のは違うと思うので、これだけから
>|「分離不可能」とは言えないのではないででしょうか。
>
>原理的には可能ですから，私は分離不可能であるとまでは思わない
>んですが，多くの場合で分離することには意味が無いとは思います．

なんていうか、実感として肌に染み込んでくる意見ですね。

カタチ(例えば書類)の上で分離する事には、私も意味を感じません。
ただ、実装の都合でいつのまにか設計が変わっている(無視されている)
と言う事はあってはならないので、ココロの持ち方として、この分離は
重要ではないかと。

一応断っておきますが、実装上問題が出たときに、設計まで振り返って、
設計を変更し、実装するのは否定してません。

むしろ、カタチの上での分離は、実装→設計へのフィードバックが
しにくくなり、結果として「設計が無視される」と言った事態を起こしやすい
のではないかと思います。ただ、こうした「カタチ」の話は、「設計論」では
なく「プロジェクトマネージメント」の話ではないかとも思います。

>どうやら「ウォーターフォールじゃいかん」ってのは周知の事実に

>なったようですが，その場合実装やさまざまな事情によって，プロ
>グラミングと設計の間の手戻りがかなり発生するはずですよね．そ

>の場合，設計とプログラミングを分離することはたんにコミュニケー
>ションコストを増大させるだけだと思います．

まさしく。

>んで，日本で設計とプログラミングを分離したがるのは企業の中に
>「設計者(SE)」と「プログラマ(PG)」という一種の身分制度が存在
>しているからではないかと憶測しているのです．日本ってプログラ
>マの地位が低いですよね．

うーん、微妙なトコロですね。

とりあえず、正論を吐いておくと、「優れた設計者」と「優れたプロ
グラマ」では、「優れた設計者」の方が優遇されて良いんじゃないで

しょうか。それは一人当たりで見たとき、設計者のほうがプログラマ
よりもシステムへの影響力が大きいからです。

ただ、プログラミングは「プログラミング」を知らないと出来ないのに
対して、設計は「設計」をしらなくても「できて」しまいますし、これが
結果として「プログラミングはできないから設計でもする」なんて事態を
招く事もあるかと。

＃ まぁ、一応「架空」の話ですから。そういうことで。(^^;)

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

os...@cs.ricoh.co.jpさん:

> リアルタイム制御の場合、各スレッドは独立に動作するのではなく、
> お互いに協調しあいながら動作します。ただその場合、単に機能達成

> だけが求められるのではなく、応答時間やスレッドの処理時間等の要
> 求値を満たす必要があります。
...
> だから、(必要な範囲で)各モジュール群*全体を見渡して*、何処で何
> をするかと言う方針の決定はソースコードを書く段階では、(天才か
> 超努力家以外の普通の人では)無理じゃないかなと思います。だから、
> コーディング以前に設計というステップが必要だと思います。

もちろん設計は必要ですね。

それで、そのような並行システムの設計ってOOA/OODでやられてます?
それでどのくらい有効なんでしょう。

その辺も懐疑的なんで :-) 久野

[Yukihiro Matsumoto]

まつもと ゆきひろです

os...@cs.ricoh.co.jp (Oseto Futoshi) writes:

|大瀬戸です。

|>分離すべきは，前段階の「外部仕様の決定」「モジュール間のイン

|>ターフェースの決定」レベルか，後段階の「テスト」などでしょう．
|>前段階は手戻りが頻繁に発生しちゃいかんはずなんで，分離に問題
|>ないですし，後段階は分離しないと先入観から問題を見逃しちゃう
|>恐れがありますよね．
|
|そうやって分離するのが「ウォーターフォール」だと思いますが。

えーと，ということは，大瀬戸さんは「分離はすべからくウォーター
フォールである，存在してはいかん」と思っていらっしゃるという
ことでしょうか？ しかし，それでは大瀬戸さんの他の発言とは矛
盾するのできっと違うでしょうね．

前の発言で私が述べたのは

外部仕様やモジュール間のインターフェースは頻繁に変更しては
いけない(場合が多い)ので，分離による問題が生じにくいし，変
更の頻度を下げる外部要因とするために分離した方が良い(場合
が多い)

という意味で「手戻りが発生しない」とか「してはいけない」とか
いうような意図はありませんので，直接にウォーターフォールモデ
ルにつながるという認識はなかったのですが，いかがでしょう？

ついでにいえば，上記の「良い」は主にコストの問題ですので，コ
ストを度外視している場合には，良いも悪いもありません．

そして，私は「このような方法は『スパイラル開発』である」とは
ひとことも申しておりませんので，

|そして、「スパイラル開発」がモジュール内でプログラミングと
|設計との間の手戻りをすることではないと思っていたのですが。

については，若干当惑しております．

# 個人的な考えでは「フィードバックが行われれば粒度はともかく
# スパイラル開発である」と思ってますが．

|確認ですが
|In article <lvsoltd9...@picachu.netlab.co.jp>, ma...@netlab.co.jp says...

|>なったようですが，その場合実装やさまざまな事情によって，プロ
|>グラミングと設計の間の手戻りがかなり発生するはずですよね．そ
|

|でいう、プログラミングと設計は作業のことで
|
|>の場合，設計とプログラミングを分離することはたんにコミュニケー
|>ションコストを増大させるだけだと思います．
|
|でいう、設計とプログラミングは担当者のことですよね。

そうであった方が「被害」が大きいですが，どちらも作業と考えて
いただいても議論の本質は変りません．

まつもと ゆきひろ /:|)

[Yukihiro Matsumoto]

まつもと ゆきひろです

"SENOH Yasushi" <se...@xa2.so-net.or.jp> writes:

|妹尾です。

| カタチ(例えば書類)の上で分離する事には、私も意味を感じません。

|ただ、実装の都合でいつのまにか設計が変わっている(無視されている)
|と言う事はあってはならないので、ココロの持ち方として、この分離は
|重要ではないかと。

えーと，この場合の前提は

実装の都合でいつのまにか設計が変わっている(無視されている)
と言う事はあってはならない

ですよね．この議論では設計という用語がいろいろの領域(粒度)で
使われているので難しいのですが，私の考えは

この設計変更が閉じたモジュールの範囲内で行われるなら問題なし

と思ってます．ですから，前提を共有してないんですね．もちろん，
他人との関わりのある部分を勝手に変更してはいけないので，大き
なレベルでの設計については同意しますが．

ですから，わたしはこの件に関して妹尾さんの意見を全否定してい
るのではなくて，成立しない場合がありますよ，と述べているまで
です．

| とりあえず、正論を吐いておくと、「優れた設計者」と「優れたプロ
|グラマ」では、「優れた設計者」の方が優遇されて良いんじゃないで
|しょうか。

ふむ，つまり「優れた設計者」であるが「プログラマとしては優秀
でない」人や「優れたプログラマ」であるが「ろくな設計が出来な
い」人が存在すると考えておられるんですね．

企業における「コーダー」という職種の存在を見ているとそういう
人がいそうな気になってもしょうがないと思いますが，私の経験で
はそういう人は見たことないですし，存在しないんじゃないかとも
思っています．

もしかすると「プログラマ」という単語が指しているものが食い違っ
ているのかも知れませんが．

まつもと ゆきひろ /:|)

[Oseto Futoshi]

大瀬戸です。

In article <lv1ztcva...@picachu.netlab.co.jp>, ma...@netlab.co.jp says...
>|だから、（必要な範囲で）各モジュール群＊全体を見渡して＊、
（略）

>|だから、コーディング以前に設計というステップが必要だと思います。
>
>そこまでは否定しません．私も「外部仕様の決定」や「モジュール
>分割」は分離できると述べました．が，普通「設計」というとそれ
>より踏み込んだプログラミングの一歩手前まで含みませんか？

ここへの回答をする前に、

>そのような(詳細)設計は分離すべきではないというのが，私の主張
>です．

について確認ですが、ここでおっしゃられている「設計の分離」は
工程の分離のことですよね。担当者の分離のことなんかじゃないですよね。

以後、「工程の分離」だと解釈して話を進めます。

で、僕からの回答をします。
ここでお互いの認識がずれている可能性のあるのが、
「モジュールの大きさ」についての様な感じがします。
僕の認識では、モジュールは、
・手続き型言語の場合は、プロシージャや関数のこと
・オブジェクト指向言語の場合は、クラスのこと
です。
その上で、そのモジュールの構成はコーディング以前に設計というステップで
詰めておく必要があると考えてます。
＃モジュール内部のメカニズムは、場合によりその時にある程度規定する
＃かもしれません（疑似言語という形で。）が、
＃基本的には“好きにして”ってスタンスです。

分析・設計という概念を知る以前は、僕の場合、モジュールの決定は
結構いいかげんでした。
＃その時代はＣ言語でしたから、モジュール＝関数 です。
つまり、最初に“まぁこんなもんだろう”と大まかな決定をして
詳細を詰めていき、大きさが80x25のスクリーンで手に負えなく
なってくると、その都度、意味の上でまとまった単位で
細かい関数に分ける、ということの繰り返しでした。
お陰で、出来上がったソースは、1度しか使われないモジュールや
良く似たモジュールが沢山ありました。

手続き型言語の場合は、そういうことがおきても多少の無駄
（呼び出し時間とスタックの消費量）だけで済み、ちゃんと
動くわけです。
＃しかも、1度しか使われないモジュールであっても
＃「手続きの隠蔽」という見方をすると、
＃全く無駄なわけじゃないですけど。

ところが、オブジェクト指向型言語の場合、オブジェクトに
よって、「手続きの隠蔽」に加え「データ（構造）の隠蔽」が
加わります。その場合、矛盾したオブジェクト構造はそのまま
矛盾したデータを含むことが起きてしまうと思います。
だから、思い付きでオブジェクトを作り出す訳には
いかないと思います。

だから、オブジェクト単位の大きさまで踏み込んだ設計
が必要になるのではないかと思っています。

＃もっとも、Shlaer-Mellor 法から OO に入ったから
＃こんな考えを持つのかもしれませんが。
＃しかも、SM法なんてOOじゃないという人もいるかもしれない。:p

[Yukihiro Matsumoto]

まつもと ゆきひろです

os...@cs.ricoh.co.jp (Oseto Futoshi) writes:

|大瀬戸です。

|ここへの回答をする前に、

|
|>そのような(詳細)設計は分離すべきではないというのが，私の主張
|>です．
|
|について確認ですが、ここでおっしゃられている「設計の分離」は
|工程の分離のことですよね。担当者の分離のことなんかじゃないですよね。

実は担当者の分離を念頭において話していたのですが…．工程の分
離でも議論の本質は変らないとは思いますが，「分離」という用語
の使い方によっては違いが出てくるかも知れません．

|ここでお互いの認識がずれている可能性のあるのが、
|「モジュールの大きさ」についての様な感じがします。
|僕の認識では、モジュールは、
|・手続き型言語の場合は、プロシージャや関数のこと
|・オブジェクト指向言語の場合は、クラスのこと
|です。

あ，そうなんですか．うーん．

私が(多分よしおかさんも)考えているモジュールはもっと大きな単
位です．そして，そのレベルで

|＃モジュール内部のメカニズムは、場合によりその時にある程度規定する
|＃かもしれません（疑似言語という形で。）が、
|＃基本的には“好きにして”ってスタンスです。

が成立すると考えています．

|ところが、オブジェクト指向型言語の場合、オブジェクトに
|よって、「手続きの隠蔽」に加え「データ（構造）の隠蔽」が
|加わります。その場合、矛盾したオブジェクト構造はそのまま
|矛盾したデータを含むことが起きてしまうと思います。
|だから、思い付きでオブジェクトを作り出す訳には
|いかないと思います。

それについては否定しませんが，なにか私が設計が要らないとか，
思い付きでオブジェクトを定義すれば良いと主張しているかのよう
に読めるのですが，気のせいでしょうか？

私が主張しているのは，ある一定の粒度以下では設計という工程と
プログラミングという工程を分離する必要はない，ということで，
分析や設計が不要だとか，いい加減なプログラムを書けば良いとか
いうようなことは主張してません．

まつもと ゆきひろ /:|)

[SENOH Yasushi]

妹尾です。

Yukihiro Matsumoto wrote in message ...

> 実装の都合でいつのまにか設計が変わっている(無視されている)

> と言う事はあってはならない
>
>ですよね．この議論では設計という用語がいろいろの領域(粒度)で
>使われているので難しいのですが，私の考えは
>
> この設計変更が閉じたモジュールの範囲内で行われるなら問題なし

これは実装レベルの話だから問題ないと思います。
逆に言えば、こういうレベルの事は設計で話すようなコトではないと
思ってます。良い設計とはシステムなりを実現するにあたって必要な
ことがすべて記述されていて、なおかつ実装の自由があるものだと
思います。実装の自由の範囲内では何をしようとも、それは設計を
かえる必要はありません。

>と思ってます．ですから，前提を共有してないんですね．もちろん，
>他人との関わりのある部分を勝手に変更してはいけないので，大き
>なレベルでの設計については同意しますが．

という事で、良いんじゃないでしょうか。どのレベルまでを設計と
呼ぶかという差はあれど、実態は変わらないと思います。

>ふむ，つまり「優れた設計者」であるが「プログラマとしては優秀
>でない」人や「優れたプログラマ」であるが「ろくな設計が出来な
>い」人が存在すると考えておられるんですね．

少なくとも、そういう意味ではありません。

このあたりは単に言葉の問題で、「プログラマ」ってのは「プログ
ラムを書く人」であり、「設計者」は「設計をする人」だという事です。
「プログラムも書けるけど、設計している人」は設計者です。

＃ こういう表現ってへんですか？

>企業における「コーダー」という職種の存在を見ているとそういう
>人がいそうな気になってもしょうがないと思いますが，私の経験で
>はそういう人は見たことないですし，存在しないんじゃないかとも
>思っています．

私も見た事無いです。でも、存在しないと主張する気もありません。
もっとも、存在するにせよ、しないにせよ、私の書いた事には関係
ありません。

[Oseto Futoshi]

大瀬戸です。
＃沢山あってフォローが大変です。(^^;)ゞ

In article <lv67il8q...@picachu.netlab.co.jp>, ma...@netlab.co.jp says...

>|ここでお互いの認識がずれている可能性のあるのが、
>|「モジュールの大きさ」についての様な感じがします。
>|僕の認識では、モジュールは、
>|・手続き型言語の場合は、プロシージャや関数のこと
>|・オブジェクト指向言語の場合は、クラスのこと
>|です。
>
>あ，そうなんですか．うーん．
>
>私が(多分よしおかさんも)考えているモジュールはもっと大きな単
>位です．

私が(多分妹尾さんも)考えているモジュールはもっと小さな単
位です．:-)

＃モジュールという言葉をつかったのが駄目だったのですね。
＃済みません。

In article <lv67il8q...@picachu.netlab.co.jp>, ma...@netlab.co.jp says...

>実は担当者の分離を念頭において話していたのですが…．工程の分
>離でも議論の本質は変らないとは思いますが，「分離」という用語
>の使い方によっては違いが出てくるかも知れません．

担当者間のコミュニケーションコストと、
一人の担当者の頭の中でのコミュニケーションコストとを、
比較すると、議論の本質はかわらないといえないのでは
ないでしょうか。

つまり、モジュール一つの捉え方（たとえば大きさ）から
異なってくると思うわけです。

>|＃モジュール内部のメカニズムは、場合によりその時にある程度規定する
>|＃かもしれません（疑似言語という形で。）が、
>|＃基本的には“好きにして”ってスタンスです。
>
>が成立すると考えています．

もし、ここでのモジュールが関数単位、オブジェクト単位
であるのならば、担当者（あえてそう呼びます）が
エディタに向かって、キーボードを叩きながら考えても
そんなにおかしなことにはならないでしょう。

しかし、ここでのモジュールがもっと大きな単位
＃たぶん、担当者に任せられる仕事の大きさの単位
であるのならば、担当者が直接エディタに向かって、
キーボードを叩きながら考えてると、おかしなことに
なるのではないでしょうか。
“好きにして”っていう、スタンスは取れないと思います。

前者は、まつもと さんの
>私が主張しているのは，ある一定の粒度以下では設計という工程と
>プログラミングという工程を分離する必要はない，ということで，
という発言と（粒度の面でも）同じだと思いますが
如何でしょう。

そして、後者において、もし、“好きにして”っていう
スタンスを取るとすると、
>分析や設計が不要だとか，いい加減なプログラムを書けば良いとか
>いうようなことは主張してません．
という発言と矛盾してしまうので、この意見にも同意頂けると
思います。

つまり、モジュールの粒度の面を共通に認識すると
お互い同意見になるのではないかと思いますが、
如何でしょうか。

>|ところが、オブジェクト指向型言語の場合、オブジェクトに
（略）

>それについては否定しませんが，なにか私が設計が要らないとか，
>思い付きでオブジェクトを定義すれば良いと主張しているかのよう
>に読めるのですが，気のせいでしょうか？

決してそのような意図はありません。
しかし、モジュールの大きさの解釈で食い違いがあって
そのため誤解を生じた可能性は否定できないと思います。
申し訳ありません。m(_ _)m

[Yukihiro Matsumoto]

まつもと ゆきひろです

"SENOH Yasushi" <se...@xa2.so-net.or.jp> writes:

|妹尾です。

|>ふむ，つまり「優れた設計者」であるが「プログラマとしては優秀

|>でない」人や「優れたプログラマ」であるが「ろくな設計が出来な
|>い」人が存在すると考えておられるんですね．
|
| 少なくとも、そういう意味ではありません。

そうなんですね．それは曲解のしすぎだったかもしれません．謝罪
します．

|＃ こういう表現ってへんですか？

表現は変じゃないです．ただ，元の表現は

| とりあえず、正論を吐いておくと、「優れた設計者」と「優れたプロ
|グラマ」では、「優れた設計者」の方が優遇されて良いんじゃないで
|しょうか。

というものでした．で，この発言のこの文脈での意味をとりかねた
わけです．で，結局はどういう意味だったのでしょうか？
もしかして

優れた人材は設計に回すべきだ

ということ？ それとも全然違う意味？ いずれにしてもなんとなく
私の賛成していない設計とプログラミングの分離を前提にしている
ような気がするんですが…．

まつもと ゆきひろ /:|)

[Yukihiro Matsumoto]

まつもと ゆきひろです

os...@cs.ricoh.co.jp (Oseto Futoshi) writes:

|大瀬戸です。

|>私が(多分よしおかさんも)考えているモジュールはもっと大きな単

|>位です．
|
|私が(多分妹尾さんも)考えているモジュールはもっと小さな単
|位です．:-)
|
|＃モジュールという言葉をつかったのが駄目だったのですね。
|＃済みません。

じゃあ，私はサブシステムという言葉を使いましょう．

|しかし、ここでのモジュールがもっと大きな単位
|＃たぶん、担当者に任せられる仕事の大きさの単位
|であるのならば、担当者が直接エディタに向かって、
|キーボードを叩きながら考えてると、おかしなことに
|なるのではないでしょうか。

# そもそも私が「分離しない」と言ってることは「キーボードを叩
# きながら考える」こととイコールではないのですが…，まあ，い
# いです．

一般論としてそういう「おかしなこと」が発生することが多いこと
には同意します．が，そこで「だから分離せねばならない」と考え
るか，「分離するかしないかは担当者が『好きにして』」と考える
かの違いでしょう．

私の欲しいものはルールではなく，ちゃんとしたサブシステムだけ
ですから．またルールを設定しないとちゃんと分析もしてくれない
技術者より，優れたサブシステムをアウトプットしてくれる技術者
が欲しいです(そうありたいです)．

で，これはシュリンクラップなソフトフェアプロダクトでは普通の
考えだと思います，多分．が，日本の多くの企業では(おそらくは
程度のあまり高くない技術者を大量に抱えていたため)ルールで縛
る性悪説的なやり方が横行している(いた)と考えています．

|つまり、モジュールの粒度の面を共通に認識すると
|お互い同意見になるのではないかと思いますが、
|如何でしょうか。

そうかもしれません．よくわからないけど．

まつもと ゆきひろ /:|)

[Hirotaka Yoshioka]

よしおかです．

なかなか琴線にふれるお話なんでリプライしちゃいます．
誰かを説得しよーとか，なにか新しい知見があるとか，
そーゆーことは一切ない，ただのプログラマのヨタ話です．

でもって，設計(未定義語)とプログラミングをわけるメリットってなんなんでしょ
うね．よくわからないっす．

Yukihiro Matsumoto <ma...@netlab.co.jp> writes:
> まつもと ゆきひろです
> |大瀬戸です。

> |しかし、ここでのモジュールがもっと大きな単位
> |＃たぶん、担当者に任せられる仕事の大きさの単位
> |であるのならば、担当者が直接エディタに向かって、
> |キーボードを叩きながら考えてると、おかしなことに
> |なるのではないでしょうか。

> 一般論としてそういう「おかしなこと」が発生することが多いこと
> には同意します．が，そこで「だから分離せねばならない」と考え
> るか，「分離するかしないかは担当者が『好きにして』」と考える
> かの違いでしょう．

素人にプログラミングさせれば，そりゃだめでしょう．どんなことやったって，
とか思っちゃいます．

> 私の欲しいものはルールではなく，ちゃんとしたサブシステムだけ
> ですから．またルールを設定しないとちゃんと分析もしてくれない
> 技術者より，優れたサブシステムをアウトプットしてくれる技術者
> が欲しいです(そうありたいです)．

そーなんです．素人を救済しよーとするから，話がややこしくなるんです．
プロのプログラマにやらせりゃいいんです．でもって，これって鶏と卵なんだけ
ど，大学の教育とか企業の研修がプロのプログラマを育成するのに，どれだけや
くだっているかというと，ほとんど，なんの貢献もしていないのじゃないかと思っ
てます．あ，これは余談か．

> で，これはシュリンクラップなソフトフェアプロダクトでは普通の
> 考えだと思います，多分．が，日本の多くの企業では(おそらくは
> 程度のあまり高くない技術者を大量に抱えていたため)ルールで縛
> る性悪説的なやり方が横行している(いた)と考えています．

シュリンクラップなソフトウェアの開発現場ではプログラマがエディタであれや
これやしながらもの作っていきます．外部仕様書はあります．でも，デザインの
メモ程度のものはあっても，詳細な設計仕様書みたいな，それだけわたせば，素
人でもコードがかけるようなプログラムの一歩手前みたいなものは，少くともう
ちの会社にはありません．シリコンバレーの多くの現場もそうでしょう．コード
が最終的なよりどころです．外部仕様書を書く人と，コードを書く人が違う場合
もありますけど，それも多くの場合一緒だったりします．外部仕様を複数人で書
いて，複数人でコードを書くというパターンもあります．でも，外部仕様だけを
書く人とか設計だけする人とかプログラムを書くだけの人とかの区別はないです．
設計もすればコードも書く．

ある意味でハッカーがコードをハックしながらプロダクトを作っていく．そーゆー
イメージです．カオスといってもいいかもしれません．でも，モノは作られてい
ます．すごいスピードで．

素人にプログラムを書かせない．素人に設計をさせない．素人を何人あつめても
プロには勝てないっすよ．

あー，物議をかもしだすよーな事いっちゃったなあ．

よ

[Hirotaka Yoshioka]

"SENOH Yasushi" <se...@xa2.so-net.or.jp> writes:
> 妹尾です。

> >いずれにしてもなんとなく
> >私の賛成していない設計とプログラミングの分離を前提にしている
> >ような気がするんですが…．
> 私は設計とプログラミングの分離を前提にしてます。
> 確かに作業の流れの中では分離しにくいこともありますが、設計で
> すべきこととプログラミングですべきことは、まるで違うと思います。
>
> 設計は、そのアーキテクチャを示すものであり、具体的に実装の
> 内容を指すものではないと思います。だから分離は可能だし、
> 現実的だと思います。

多分妹尾さんのおっしゃっている「設計」が示すものをわたしが理解できていな
いのだと思いますが．．．

> 逆に言えば、プログラミングから分離されていない「設計」って設計
> じゃなくてプログラミングだと思うんですけど。具体的にどう実装しよう
> かと考える行為は設計ではなく、プログラミングだと思います。

別に言葉は，どーでもいいっちゃいいのですが，プログラミングと分離した，設
計というのは，どーゆーナニなのでしょうか？抽象的は話だと，わたしは多分理
解できないので，たとえば，モジラに縦書きを追加するという要求があったとし
て，外部仕様で，<SPAN DIR=TTB>というタグがあったときに縦書きにする，となっ
ていた場合の「設計」ってなんでしょうか？

よ

[SENOH Yasushi]

妹尾です。

Yukihiro Matsumoto wrote in message ...

>| とりあえず、正論を吐いておくと、「優れた設計者」と「優れたプロ

>|グラマ」では、「優れた設計者」の方が優遇されて良いんじゃないで
>|しょうか。
>
>というものでした．で，この発言のこの文脈での意味をとりかねた
>わけです．で，結局はどういう意味だったのでしょうか？
>もしかして
>
> 優れた人材は設計に回すべきだ

>ということ？ それとも全然違う意味？

非常にベタな書き方をしてしまえば、設計でこけるのと、
プログラミングでこけるのはどちらが影響力がでかいかと
いえば、設計のほうだろう。だから設計はプログラミングより
も注意してやる必要がある。だから優れた(こけない)設計者
は、とても重要だという事です。

設計はプログラミングより重要だと思いますけど、どうですか？

＃ このあたりの主張がどうも読み切れない。

>いずれにしてもなんとなく
>私の賛成していない設計とプログラミングの分離を前提にしている
>ような気がするんですが…．

私は設計とプログラミングの分離を前提にしてます。
確かに作業の流れの中では分離しにくいこともありますが、設計で
すべきこととプログラミングですべきことは、まるで違うと思います。

設計は、そのアーキテクチャを示すものであり、具体的に実装の
内容を指すものではないと思います。だから分離は可能だし、
現実的だと思います。

逆に言えば、プログラミングから分離されていない「設計」って設計
じゃなくてプログラミングだと思うんですけど。具体的にどう実装しよう
かと考える行為は設計ではなく、プログラミングだと思います。

[SENOH Yasushi]

妹尾です。

Hirotaka Yoshioka wrote in message ...

>"SENOH Yasushi" <se...@xa2.so-net.or.jp> writes:

>別に言葉は，どーでもいいっちゃいいのですが，プログラミングと分離した，設
>計というのは，どーゆーナニなのでしょうか？抽象的は話だと，わたしは多分理
>解できないので，たとえば，モジラに縦書きを追加するという要求があったとし
>て，外部仕様で，<SPAN DIR=TTB>というタグがあったときに縦書きにする，となっ
>ていた場合の「設計」ってなんでしょうか？

具体的といわれても モジラの設計を知らないので、それは無理です。

ただ、最終的には その縦書きの追加によって変化する、各クラスの
「責任」と「協調動作」をまとめればいいんじゃないですか。

枠組みまでは指定してますが、それを実現する方法に関しては言及
してませんよね。注意して欲しいのですが、ここでの「クラス」は OOD
におけるクラスなので、実装されているクラスと 1:1 では対応しません。
それは設計にはないけど、実装の都合で定義したクラスが存在する
からです。

確か 「銀たま」に

「設計者は、具体的な実装方法までは指定しない。しかし、プログラマから
聞かれた場合には少なくとも一つは、その方法を挙げる事ができなければ
ならない。」

といった事が書かれていたと思います。つまり考えた上で、限定しないと。

単に「言葉」の話じゃないとおもいますよ。

[Hoshi Takanori]

ほし＠えすあーるえーです。

In article <6klj21$1...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:

> > 唯一すんなり読めたのが Design Patterns で、ぼろくそに言う人も
> > いるみたいだけど、これこそがまさに

(略)
>
> Design Patterns批判ってどんなことが言われているんですか?

ごめんなさい。ぼろくそに言う人がいるって噂を聞いたような
気がするだけで、具体的な批判の内容は知りません。

ほし

[Oseto Futoshi]

大瀬戸です。

＃あまりにも投稿記事が多くって困っています。
＃程々の投稿数だから、購読していたのに。（苦笑）

In article <g3b3edna7...@dlsun329.us.oracle.com>, hyos...@us.oracle.com says...
>でもって，設計(未定義語)とプログラミングをわけるメリットってなんなんでしょ
>うね．よくわからないっす．

僕の考える分析・設計・プログラミングの定義はこういうことです。
＃別に、どこかの教科書に載っていた訳ではなく、色々な本を
＃読んだ上で、自分が行き着いた考えです。

分析：作りたいソフトウエアは、何であるかを定式化すること。
設計：その何を、与えられたアーキテクチャで達成するための
メカニズムを選択（場合によっては発明）すること。
与えられたアーキテクチャの要件により、
そこに時間制約やメモリ制約などが課せられる。
プログラミング：設計で選られたメカニズムを、プログラミング
言語を用いて、コーディングする。

って意味です。
＃考えてみたんですけど、プログラミング言語自体にある程度の
＃メカニズムが入っていますよね。たとえば、x = x + 1;なんての
＃は、実は、メモリｘ番地からアキュムレータにロードして云々
＃なんてことが。
＃そういう小さいレベルで、プログラミングが設計に影響を与えて
＃いることはあるでしょうね。

まぁ、僕が定義する設計って、メカニズムの選択（必要なら発明）です。

>Yukihiro Matsumoto <ma...@netlab.co.jp> writes:
>> るか，「分離するかしないかは担当者が『好きにして』」と考える
>> かの違いでしょう．
>
>素人にプログラミングさせれば，そりゃだめでしょう．どんなことやったって，
>とか思っちゃいます．

素人がプログラミングしちゃうわけです。最初は。(;_;)

>ど，大学の教育とか企業の研修がプロのプログラマを育成するのに，どれだけや
>くだっているかというと，ほとんど，なんの貢献もしていないのじゃないかと思っ
>てます．あ，これは余談か．

ははは。（笑）

>シュリンクラップなソフトウェアの開発現場ではプログラマがエディタであれや
（中略）

>ある意味でハッカーがコードをハックしながらプロダクトを作っていく．そーゆー
>イメージです．カオスといってもいいかもしれません．でも，モノは作られてい
>ます．すごいスピードで．

僕（や多分妹尾さんも）が設計とプログラミングを分離するという
意味は、この、「カオスといってもいいかもしれ」ない、
「コードをハックしながら」のプログラミングを、ハッカーでない
普通のプログラマがやったら危険だと言っているわけです。
別に、「詳細な設計仕様書」を書けって言っているわけじゃ
全然無いです。
＃あったら、後の世代にとっては嬉しいですけどね。
考え方として、「今は設計をやっているからこれこれは
考察対象から省く。今は、プログラミングをやっているから云々」
という仕事をしないと危険じゃないか。と言っているわけです。
＃そこをやらないと、「エディタに向かって考え込む」訳です。

＃シュリンクラップのソフトウェア開発現場が、非常な開発競争を
＃やっているのは端から見ても判ります。
＃でも、だからと言って高機能ワープロが途中でハングアップするのは
＃我慢が出来ないです。:-)

>素人にプログラムを書かせない．素人に設計をさせない．素人を何人あつめても
>プロには勝てないっすよ．

そうなんですよ。プロには勝てないです。ハイ。
でも、そのプロってなかなか社員にならないんですよね。
＃流しのプロっていればよいのかな。:p

[Hiro Yoshioka]

よしおかです．

家からポストしているので，うまくいくかどうか
わからないですが．．．

SENOH Yasushi <se...@xa2.so-net.or.jp> wrote in article
<6l23ko$hn8$1...@news01ca.so-net.or.jp>...
> 妹尾です。

> >別に言葉は，どーでもいいっちゃいいのですが，プログラミングと分離した，設
> >計というのは，どーゆーナニなのでしょうか？抽象的は話だと，わたしは多分理
> >解できないので，たとえば，モジラに縦書きを追加するという要求があったとし
> >て，外部仕様で，<SPAN
DIR=TTB>というタグがあったときに縦書きにする，となっ
> >ていた場合の「設計」ってなんでしょうか？
> 具体的といわれても モジラの設計を知らないので、それは無理です。

モジラの実装を知らないと設計できないわけですよね．
じゃあ，設計できるようになるためには，何をしなくちゃ
いかんかというと，実装を理解しなければならないわけですよね．

それって，なんか魔法のドキュメントが存在するわけではなくて，
コードを読む．それに尽きると思うのです．わたしは．

このプロセスの事を仮にデザインリカバリーと呼ぶとすると，
設計者の頭の中には，デザインリカバリーの後に，なんらかの
モデルができあがって，その後にやっとこさ設計ができると．
先に設計があるんじゃなくて先に実装があって，その後に設計がある．
まあ，渾然一体となって鶏と卵なんですけどね．

最初にスクラッチから作る時はどーするんだつー話は
もちろんありますけどね．

いずれにせよ，そーゆープロセスをまわす時，
設計者と実装者を分けるメリットってなんでしょうか？
設計工程と実装工程を分けるメリットってなんでしょうか？

いい設計にはよりよい実装の理解が必要だと
思っちゃったりするんです．わたしは．

あ，なにからなにまで一人で作れるような
小さいサイズのプログラムだったら，別に
どーでもいいことかもしれないですね．

よ

[Hiro Yoshioka]

よしおかです．

お，なんか意見の一致をみそうな気配が．．．

Oseto Futoshi <os...@cs.ricoh.co.jp> wrote in article
<6l2850$h...@ohmori.ohmori.ricoh.co.jp>...
> 大瀬戸です。

> >Yukihiro Matsumoto <ma...@netlab.co.jp> writes:
> >> るか，「分離するかしないかは担当者が『好きにして』」と考える
> >> かの違いでしょう．
> >
> >素人にプログラミングさせれば，そりゃだめでしょう．どんなことやったって，
> >とか思っちゃいます．
>
> 素人がプログラミングしちゃうわけです。最初は。(;_;)
>

> >シュリンクラップなソフトウェアの開発現場ではプログラマがエディタであれや
> （中略）
>
>ある意味でハッカーがコードをハックしながらプロダクトを作っていく．そーゆー
> >イメージです．カオスといってもいいかもしれません．でも，モノは作られてい
> >ます．すごいスピードで．
>
> 僕（や多分妹尾さんも）が設計とプログラミングを分離するという
> 意味は、この、「カオスといってもいいかもしれ」ない、
> 「コードをハックしながら」のプログラミングを、ハッカーでない
> 普通のプログラマがやったら危険だと言っているわけです。

ここは同意します．

だから

> >素人にプログラムを書かせない．素人に設計をさせない．素人を何人あつめても
> >プロには勝てないっすよ．

なんです．

> そうなんですよ。プロには勝てないです。ハイ。
> でも、そのプロってなかなか社員にならないんですよね。
> ＃流しのプロっていればよいのかな。:p

雇用されているのプロのプログラマーっていっぱい
いますよ．むしろそっちのほうが多数でフリーランス
のほうが少ないような気がする．プロのプログラマが
日本に少ないとしたらなんでだろうか？

工場型開発対プログラマ型（？）開発なんなんですかね．

よ

[Yukihiro Matsumoto]

"SENOH Yasushi" <se...@xa2.so-net.or.jp> writes:

|妹尾です。

| 非常にベタな書き方をしてしまえば、設計でこけるのと、

|プログラミングでこけるのはどちらが影響力がでかいかと
|いえば、設計のほうだろう。だから設計はプログラミングより
|も注意してやる必要がある。だから優れた(こけない)設計者
|は、とても重要だという事です。

| 設計はプログラミングより重要だと思いますけど、どうですか？

はあ，きっと妹尾さんには「設計とプログラミングがそれほど分離
していない状況」ってのが想像も出来ないんでしょうね．まあ，育っ
た環境とかありますからしょうがないんでしょうけど，ねえ．

よしおかさんの

<g3b3edna7...@dlsun329.us.oracle.com>

とか読まれて，どう感じます．「私とは関係ない世界」と思います？
# それはそれで当然ですが．

私のこのスレッドでの主張は

設計とプログラミングを分離しない世界もあるんだよ
そして分離するやり方は多くの場合損している
(が，分離するやり方が向いてる分野もある)

ってものです．妹尾さんの住んでいる(だろう)世界を全然否定して
いないんですね．が，どうか妹尾さんの住んでいる世界の常識だけ
で全てを決めつけないで欲しいとは思います．

ですから，

| 設計はプログラミングより重要だと思いますけど、どうですか？

という「設計とプログラミングが分離した世界を前提にした質問」
をされても困っちゃいます．そのような世界では私も「設計はプロ
グラミングより重要だ」と思います．しばらく前までそういう世界
に住んでましたから．そういう世界では往々にして下流の方に「使
えない人」を配置するのも当然だと思います．

が，よしおかさんの示されたような「そうでない世界」では，設計
でこけようが，プログラミングでこけようが，こけたことは一緒で
す．で，優秀な人*だけ*を求めるのです．

| 逆に言えば、プログラミングから分離されていない「設計」って設計
|じゃなくてプログラミングだと思うんですけど。具体的にどう実装しよう
|かと考える行為は設計ではなく、プログラミングだと思います。

それならそれで結構です．ちゃんとしたものが出来れば．

まつもと ゆきひろ /:|)
p.s.
妹尾さんの反論としては「なぜいつも設計とプログラミングは分離
していなければならないか」という点に関して行われることを期待
します．

[Oseto Futoshi]

大瀬戸です。

In article <01bd8e9f$5f5fcca0$91ab...@yoshioka.vip.best.com>, yosh...@best.com says...
>お，なんか意見の一致をみそうな気配が．．．

って言うか、最初っから意見は一致していたんだけど、
言葉が一致してなかったからそう見えなかっただけのような
気がしてます。(;_;)

>> 僕（や多分妹尾さんも）が設計とプログラミングを分離するという
>> 意味は、この、「カオスといってもいいかもしれ」ない、
>> 「コードをハックしながら」のプログラミングを、ハッカーでない
>> 普通のプログラマがやったら危険だと言っているわけです。
>
>ここは同意します．
>
>だから
>
>> >素人にプログラムを書かせない．素人に設計をさせない．素人を何人あつめても
>> >プロには勝てないっすよ．
>
>なんです．

そこのスタンスが、置かれた環境によるんでしょうね。

>雇用されているのプロのプログラマーっていっぱい
>いますよ．むしろそっちのほうが多数でフリーランス
>のほうが少ないような気がする．プロのプログラマが
>日本に少ないとしたらなんでだろうか？

全部のプログラマの数を数えたわけじゃないですけど、
僕の知り得る範囲では、素人からプログラムをはじめた
人がほとんどです。
＃それこそ、流しのプログラマなんてお目にかかったことが無い。

>工場型開発対プログラマ型（？）開発なんなんですかね．

っていうか、ソフトウエアに要求されている＊質＊が
違うのかもしれませんね。
＃WindowsNTで制御されている、BowingNTなんて飛行機が
＃飛んでいたら、乗りたいと思います？:p

[Hitoshi Uehara]

上原＠茨城大学.院生です。

NG:fj.news.group.comp,fj.comp.oops
Article:<HOSHI.98J...@sras49.sra.co.jp>
Mr ho...@sra.co.jp

ぼろくそとまで行かないと思いますが，オブジェクト指向'97シンポジウムで
「パターンははたして有効か」というパネルセッションがありまして，その中
で現状のデザインパターンの問題点として次の点が指摘されていました。

(オブジェクト指向'97シンポジウム資料集より抜粋)
・利用者の創造性が前提
・自動化，ツールサポート (の点が弱い)
・（一般の開発者にとっては）意図するところを理解するのは容易でない
・（一般の開発者にとっては）実際のプロジェクトにそのまま利用できるわけ
ではない
・効果的に利用するには比較的長期の訓練が必要

また研究課題として，
・言語設計
・型・プロトコルの理論
・プログラミング環境
・パターン情報の視覚化
・パターンのリポジトリ
などがあげられていました。

以降は私見ですが，会場の雰囲気として「デザインパターンを使えばソフト開
発現場での開発効率が上がるのか？」という雰囲気だった気がします。
それに対して，パネラーの方々は「そうじゃない，必ずしもそうとは言えない，
開発者間での共通語彙になるから，うまく使えば有効だけどね」という答えだっ
たと思います。

面白かったのは富士通の吉田さんが言われた「(各プロジェクト毎に)自分達で
パターンを作って，洗練して，他の人たちも使えるまでにしよう」という，
PSP(Project Specific Pattern)の考えでした。ガンマ本のような，教科書的
なパターンもそれなりに価値があると思いますが，PSPの方がよっぽど実用的
だよなぁ，と感じました。

私は逆に，「デザインパターンはいいんだ！」という方々にどういう理由でデ
ザインパターンがいいのか，聞いてみたいです。

それでは失礼します。
+---------------------------------------+
|上原 均 <ueh...@cis.ibaraki.ac.jp> |
|茨城大学 大学院 情報・システム科学専攻 |
+---------------------------------------+

[SENOH Yasushi]

妹尾です。

Hiro Yoshioka wrote in message
<01bd8e9d$39bc66e0$91ab...@yoshioka.vip.best.com>...

>> 具体的といわれても モジラの設計を知らないので、それは無理です。
>
>モジラの実装を知らないと設計できないわけですよね．

いいえ、「設計」を知らないと「設計を拡張」することもできないとしか
言ってないつもりですが。

>じゃあ，設計できるようになるためには，何をしなくちゃ
>いかんかというと，実装を理解しなければならないわけですよね．

いいえ。現実問題として、そういう事は多々ありますけど。それは
ドキュメントの不備か、まともな設計がされていないかだと思います。

ただ、ドキュメントを整備しつづけるのは困難なので、プログラムと
ドキュメントを一体化することはあると思います。でも、そのドキュメント
を読むのと「実装を理解する」事は別物だと思います。

>まあ，渾然一体となって鶏と卵なんですけどね．

鶏と卵は別れているとおもいますけど。言葉遊びでなく。
お互いに影響しているということと、渾然一体になってしまう
ことは別物じゃないですか。

>いずれにせよ，そーゆープロセスをまわす時，
>設計者と実装者を分けるメリットってなんでしょうか？

別に分けなくてもいいですけど。

>設計工程と実装工程を分けるメリットってなんでしょうか？

逆に混ぜてしまうメリットは？

>いい設計にはよりよい実装の理解が必要だと
>思っちゃったりするんです．わたしは．

「銀たま」や「コード コンプリート」なんかを読まれてもそう思う
のでしたら、何も言いません。

「銀たま」こと「人月の神話」アジソン ウェスレイ パブリシャーズ ジャパン
2900円 ISBN4-7952-9675-8

「コードコンプリート」 アスキー出版 (もとは Microsoft press)
7000 円ぐらいだったと思う。 ISBN は手元に無いので解りません。

>あ，なにからなにまで一人で作れるような
>小さいサイズのプログラムだったら，別に
>どーでもいいことかもしれないですね．

Toy problem はどーでも良いかと思います。

[SENOH Yasushi]

妹尾です。

＃ OO から離れたのでサブジェクト変えました。

Yukihiro Matsumoto wrote in message

<lvpvgr6s...@picachu.netlab.co.jp>...

>
>妹尾さんの反論としては「なぜいつも設計とプログラミングは分離
>していなければならないか」という点に関して行われることを期待
>します．

だから 設計とプログラミングはやる事が全然違うからです。

とりあえず、「銀たま」か「コードコンプリート」でも読まれては
いかがですか。少なくとも私は「分離しないほうがいい」という
話は聞いた事がないです。

[Hirotaka Yoshioka]

よしおかです．

やっぱり宗教が違うみたいですね．しくしく．
あいかわらづ，おやぢのヨタ話かましてますので，お急ぎの方，どーぞとばしちゃっ
てください．

"SENOH Yasushi" <se...@xa2.so-net.or.jp> writes:
> 妹尾です。

> >> 具体的といわれても モジラの設計を知らないので、それは無理です。
> >モジラの実装を知らないと設計できないわけですよね．
> いいえ、「設計」を知らないと「設計を拡張」することもできないとしか
> 言ってないつもりですが。

そりゃそーですよね．

> >じゃあ，設計できるようになるためには，何をしなくちゃ
> >いかんかというと，実装を理解しなければならないわけですよね．
> いいえ。現実問題として、そういう事は多々ありますけど。それは
> ドキュメントの不備か、まともな設計がされていないかだと思います。

がびーん．コードを読めばわかることをなぜわざわざ別の形式にしなければいけ
ないのだろうか？コードを読むとっかかりとしての簡単なメモとかアーキテクチャー
のドキュメントはあったとしても，詳細設計(？)のドキュメントを作るなんて時
間のムダだと思ってしまうなあ．なにをもって，「ドキュメントの不備」という
のか，「まともな設計」というのかをわたしが理解していないからだとは思うの
ですけどね．

ドキュメントを作るのが目的ではなくて，ソフトウェアプロダクトを作るのが目
的なんですよね(確認)．でもって，ソフトウェアを作るとき，「まともな設計」
だと，バグが修正しやすいとか，拡張しやすいとか，性能がよいだとか，いろい
ろな属性をかねそなえていると．

事例研究として，
http://www.mozilla.org/
にいって，モジラが「まともな設計」でないというのを指摘いただけるとうれし
いんですけど．あるいはドキュメントが不備で，設計ができないという指摘をい
ただけたら．具体的な話じゃないと，どーも理解ができないんですよ，わたしは．

でも，僭越ながら妹尾さんのお話をうかがっていると，なんか評論家のお話を聞
いているような感じがします．いやーごもっともごもっともみたいな．プログラ
マーつーのはプログラムを書いて金もらってんだから，ドキュメントがあろうが
なかろうが，設計がタコだろうがなんだろうが，プログラムを作った方がエライ
つーか．でもそれって人それぞれですから，別にいいんですけど．

> ただ、ドキュメントを整備しつづけるのは困難なので、プログラムと
> ドキュメントを一体化することはあると思います。でも、そのドキュメント
> を読むのと「実装を理解する」事は別物だと思います。

そうですか．現実問題として，一つのものを表現するのに複数の実体があるのは，
一貫性を維持するのが困難なんで推奨されていないし，教条的に「ドキュメント
を整備しろ」というのは簡単だけど，危険な発想だとわたしは思います．外部仕
様を用意するのは，あたりまえなんだけど，詳細設計のドキュメントもメンテナ
ンスしないといかんですか．言葉がよくわかっていないけど．

> >いずれにせよ，そーゆープロセスをまわす時，
> >設計者と実装者を分けるメリットってなんでしょうか？
> 別に分けなくてもいいですけど。

ちょっとほっとしてます．

> >設計工程と実装工程を分けるメリットってなんでしょうか？
> 逆に混ぜてしまうメリットは？

開発のスピードが早い速い．

> >いい設計にはよりよい実装の理解が必要だと
> >思っちゃったりするんです．わたしは．
> 「銀たま」や「コード コンプリート」なんかを読まれてもそう思う
> のでしたら、何も言いません。
> 「銀たま」こと「人月の神話」アジソン ウェスレイ パブリシャーズ ジャパン
> 2900円 ISBN4-7952-9675-8

人月の神話は，初版も第2版も読みました．何回も読みました．

http://www.best.com/~yoshioka/d/98/i980227.html

に感想文のせてます．

コードコンプリートは読んでいないです．すいません．

ここでわたしの対象としているソフトウェアはいわゆるシュリンクラップみたい
なやつで，原子力発電所の制御とか，航空機のなにとか，そーゆーものではない
です．そこそこの品質の製品をどーつくるかの話ですね．

よ
--
Hiro Yoshioka
mailto:yosh...@best.com (home)
mailto:hyos...@jp.oracle.com (office)
http://www.best.com/~yoshioka/diary.html
What is Oracle 8?
It's The Database for Network Computing.
http://www.oracle.co.jp/books/o8/003/top.html

[Shinji Kono]

河野 真治@琉球大情報工学です。

In article <g3bwway8i...@dlsun329.us.oracle.com> ,
Hirotaka Yoshioka <hyos...@us.oracle.com> writes

>がびーん．コードを読めばわかることをなぜわざわざ別の形式にしなければいけ
>ないのだろうか？コードを読むとっかかりとしての簡単なメモとかアーキテクチャー
>のドキュメントはあったとしても，詳細設計(？)のドキュメントを作るなんて時
>間のムダだと思ってしまうなあ．なにをもって，「ドキュメントの不備」という
>のか，「まともな設計」というのかをわたしが理解していないからだとは思うの
>ですけどね．

もし、一人で作っているのだったら、そんなドキュメントはいらない
んですよね。でも、例えば、学生に「こういうものを作る」と説明
する時とか、あるいは「一体全体、何を作ったんだ?」とか、「何を
作るつもりだったんだ?」とかいう答に対して、

「がびーん．コードを読めばわかる」

とはいえないでしょう? そういう時に、どういうものを答えれば良いか
ということに関しては、OOA/OODは正しい答を与えていると思います。

それとも、何人かでプロジェクトをすすめる時に、テレパシーかなんか
を使うんでしょうか...

あと、3000行ぐらいのプログラムでも読めない奴っていますよね。
僕でも3000行を一日で読めっていわれると、げー、と思う。
そういう奴にも、それなりに構造を納得してほしかったり、
一部でもいいから改良してほしかったりしますよね。その時に、
コードでなくて何を見せるのか? ってことだと思うんだ。

---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科

[Hirotaka Yoshioka]

よしおかです．

どもども，多分ドキュメントをどの程度の細かさで記すかという粒度の問題だと
は思うのですけど，わたし自身は，設計の概要とか，モジュールの構成とか，そー
ゆー安定している部分のドキュメントが不要だとかいっているわけではなくて，
それは必要だとは思うけど，詳細(？)なものは不要だと言っているわけです．

ko...@ie.u-ryukyu.ac.jp (Shinji Kono) writes:
> 河野 真治@琉球大情報工学です。
> In article <g3bwway8i...@dlsun329.us.oracle.com> ,
> Hirotaka Yoshioka <hyos...@us.oracle.com> writes
> >がびーん．コードを読めばわかることをなぜわざわざ別の形式にしなければいけ
> >ないのだろうか？コードを読むとっかかりとしての簡単なメモとかアーキテクチャー
> >のドキュメントはあったとしても，詳細設計(？)のドキュメントを作るなんて時
> >間のムダだと思ってしまうなあ．なにをもって，「ドキュメントの不備」という
> >のか，「まともな設計」というのかをわたしが理解していないからだとは思うの
> >ですけどね．
> もし、一人で作っているのだったら、そんなドキュメントはいらない
> んですよね。でも、例えば、学生に「こういうものを作る」と説明
> する時とか、あるいは「一体全体、何を作ったんだ?」とか、「何を
> 作るつもりだったんだ?」とかいう答に対して、
> 「がびーん．コードを読めばわかる」
> とはいえないでしょう? そういう時に、どういうものを答えれば良いか
> ということに関しては、OOA/OODは正しい答を与えていると思います。

河野さんのおっしゃっているのは「何を」というドキュメントで，その必要性を
否定したつもりはないのですけど．わたしが問題としているのは，いかにという
のを記したドキュメントで，その詳細を記したドキュメントの必要性に疑義をは
さんでいると．

> それとも、何人かでプロジェクトをすすめる時に、テレパシーかなんか
> を使うんでしょうか...

がはは．

> あと、3000行ぐらいのプログラムでも読めない奴っていますよね。

読めない奴もいれば，読める奴もいる．
でも，読めない奴は，いーの，相手にしないから．

> 僕でも3000行を一日で読めっていわれると、げー、と思う。
> そういう奴にも、それなりに構造を納得してほしかったり、
> 一部でもいいから改良してほしかったりしますよね。その時に、
> コードでなくて何を見せるのか? ってことだと思うんだ。

仮にその何かというのがあって，その使えないやつを使うはめになって，どーに
かしてほしい場合どうするかという問題だと勝手に解釈します．その何かという
を読む時間，理解する時間は，コードを読んで理解する時間より短いと．そして，
その結果，コードを変更できると．うーむ，そーゆー便利なものがあれば，ぜひ，
見たいです．

ちょっと，話をかえますけど，忙しくて，ねこの手もかりたい状況つーのはあり
ます．もちろん，しょっちゅうです．その時，いろいろな作戦がありますけど，
一番最悪なのは，素人をそのプロジェクトにつっこむこと．つまり，3000行のプ
ログラムを一人で，どーにかできない連中をつっこむことですね．ブルックス先
生も言っていましたよね．状況悪化しちゃいますよね．そーゆー時の次善の策は，
スケジュールを延すか，実装する機能をおとすか，それだけだと思うのです．実
装レベルの詳細を記述したドキュメントを整備することが，その問題を解決する
とは思っていないです．

もちろんこれは，わたしのスタイルというか，ここらへんの会社がやっているス
タイルですから，どんなソフトウェアにも適用可能だとか，有効だとか言うつも
りはモートーないです．

大規模ソフトウェアを作成する時，その詳細ドキュメントを整備するより，リグ
レッションテストとかディリービルドとか，そーゆーインフラの方がはるかに重
要だとは思うのだけど，まあ，ここの文脈では，あんまり関係ないですね．

よ

[Oseto Futoshi]

大瀬戸です。
＃チャチャです。m(_ _)m

In article <g3bu3628a...@dlsun329.us.oracle.com>, hyos...@us.oracle.com says...

>もちろんこれは，わたしのスタイルというか，ここらへんの会社がやっているス
>タイルですから，どんなソフトウェアにも適用可能だとか，有効だとか言うつも
>りはモートーないです．

そうですよね。シュリンクラップの開発競争ではそうでしょう。
＃特に、競争相手がMSなら。
でも、その思想が他のところに波及しないように願うわけです。
核攻撃とまではいかなくても、サッカーの中継の後半ロスタイムの
終了間際の肝心な時にバグられると、人命には関係なくても
腹が立ちます。
＃べつに、あの事件がソフトウエアのバグによるものだとは決して
＃言っていません。でも、バグの所為だったら、殺されるな担当者は。:p

>大規模ソフトウェアを作成する時，その詳細ドキュメントを整備するより，リグ
>レッションテストとかディリービルドとか，そーゆーインフラの方がはるかに重
>要だとは思うのだけど，

私は、はるかに重要かどうかは、全ての開発ケースを知っている
訳じゃないので言えませんが、開発する対象の置かれた環境に
寄るのじゃないでしょうか。

[Oseto Futoshi]

大瀬戸です。
＃チャチャの自己フォローになってしまいます。
＃御恥ずかしい。m(_ _;)m

In article <6l4ldb$6...@ohmori.ohmori.ricoh.co.jp>, os...@cs.ricoh.co.jp says...

>In article <g3bu3628a...@dlsun329.us.oracle.com>, hyos...@us.oracle.com says...
>>もちろんこれは，わたしのスタイルというか，ここらへんの会社がやっているス
>>タイルですから，どんなソフトウェアにも適用可能だとか，有効だとか言うつも
>>りはモートーないです．

これは、シュリンクラップ開発の場合での納期が満たせない時の
対処の仕方でしたね。
バグ云々の話では有りませんでした。

お詫びして訂正します。

[SONODA Syuji]

そのだです

＃ちょっと頭を柔らかくしてから読んでください :-)

Hitoshi Uehara wrote:
> 上原＠茨城大学.院生です。
:

> ぼろくそとまで行かないと思いますが，オブジェクト指向'97シンポジウムで
> 「パターンははたして有効か」というパネルセッションがありまして，その中

このパネルで

「オブジェクト指向パラダイムにおけるパターンは、構造化パラダイムに
おけるアルゴリズム、と類似した位置づけができないか。
そうであれば、パターンはアルゴリズムと同程度有効といえないか? 」

という質問をしました。
このときのパネリストの方の反応は、

まあ肯定 1
まあ反対 1
質問の意図とは違う回答 3

という感じだったと思います。
(全体的には "苦笑い" ってリアクションだったなあ)

ここではパターンとアルゴリズムの類似性の例の一つとして、以下の文の
「パターン」を「アルゴリズム」と置き換えても(ほぼ)成立するというの
を挙げておきます。

---- ここから

> で現状のデザインパターンの問題点として次の点が指摘されていました。
>
> (オブジェクト指向'97シンポジウム資料集より抜粋)
> ・利用者の創造性が前提
> ・自動化，ツールサポート (の点が弱い)
> ・（一般の開発者にとっては）意図するところを理解するのは容易でない
> ・（一般の開発者にとっては）実際のプロジェクトにそのまま利用できるわけ
> ではない
> ・効果的に利用するには比較的長期の訓練が必要
>
> また研究課題として，
> ・言語設計
> ・型・プロトコルの理論
> ・プログラミング環境
> ・パターン情報の視覚化
> ・パターンのリポジトリ
> などがあげられていました。
>
> 以降は私見ですが，会場の雰囲気として「デザインパターンを使えばソフト開
> 発現場での開発効率が上がるのか？」という雰囲気だった気がします。
> それに対して，パネラーの方々は「そうじゃない，必ずしもそうとは言えない，
> 開発者間での共通語彙になるから，うまく使えば有効だけどね」という答えだっ
> たと思います。

---- ここまで

> 私は逆に，「デザインパターンはいいんだ！」という方々にどういう理由でデ
> ザインパターンがいいのか，聞いてみたいです。

ということで、非常におおざっぱな言い方をすれば「アルゴリズムと同程度い
い」
と思います。

＃アルゴリズムは、目的とその適用結果がシンプルなので効果がわかりやすい
＃けど、パターンは目的とその適用結果の根が深いからなあ。

たまたま立堀さんが別スレッドで書かれた

Michiaki Tatsubori wrote:
> すなわち、オブジェクト指向パラダイムにおいて、
> なにかを実現するためのアルゴリズムにあたるものが、
> デザインパターンであり、
> パターンカタログはアルゴリズム辞典にあたる。

という見方は結構好きです。
--
Dramatically Effect!! -----------> ∬ ∧∧
∫・・ ヽ~
E-mail:son...@cup.com Ｏ 〃｜
http://www.osk.3web.ne.jp/~xtvkun/ u-u ―u

[SENOH Yasushi]

妹尾です。

Hirotaka Yoshioka wrote in message ...

>やっぱり宗教が違うみたいですね．しくしく．

それはあるでしょうね。やっぱり。最終的には
「これだけの効果がありました」
なんていう成果の話をせんとイカンのでしょうが、そこまでのバックデータは
ないですし、そもそもどうやってそれを測定するのかという話もあります。

システムの「複雑さ」やプログラマの「能力」なんかは「測定」しにくい
または不可能ですよね。

>がびーん．コードを読めばわかることをなぜわざわざ別の形式にしなければいけ
>ないのだろうか？

コードはアーキテクチャの実現例であって、そのものではないからです。
極論すれば「コードを読めば解るのなら、ソースコードでなくて、アセンブラ
コードでもいいですよね」とも言えるかと。当然、そんな主張はしません。
ソースコードにはアセンブラコードに記述されない、意味が込められています。
おなじく設計にもプログラムコードには記述されない意味が込められて
います。

つまり「コードを読んでも解らない」からです。

>コードを読むとっかかりとしての簡単なメモとかアーキテクチャー
>のドキュメントはあったとしても，

簡単かどうかは、その規模によると思いますが、設計としてはそこまでの
話しかしていないつもりです。

>詳細設計(？)のドキュメントを作るなんて時
>間のムダだと思ってしまうなあ．

あれって、「設計」なんですかね？私も疑問を感じてます。
私も実装方法を記述したドキュメントなんか要りません。大体ウソしか書いて
ないし。

＃ なんどだまされた事か。

ってことは、結局やっている事はおなじなのかな。

>なにをもって，「ドキュメントの不備」という
>のか，「まともな設計」というのかをわたしが理解していないからだとは思うの
>ですけどね．

ここで「まともま設計がされていない」というのは、そのアークテクチャが
まるで表現できないようなプログラムになっているような場合を想定してい
ただけるとありがたいです。

プログラムがあるからといって、それに読解可能な「アーキテクチャ」
があるとはかぎらないですよね。

>> ただ、ドキュメントを整備しつづけるのは困難なので、プログラムと
>> ドキュメントを一体化することはあると思います。でも、そのドキュメント
>> を読むのと「実装を理解する」事は別物だと思います。
>
>そうですか．現実問題として，一つのものを表現するのに複数の実体があるのは，
>一貫性を維持するのが困難なんで推奨されていないし，

そうです。だから私はソースコード中にコメントとして記述してます。これなら
少しは楽です。具体的には (C++の場合) ヘッダファイルに集中して書きます。
こんなカンジです。

// Class: CPerson (人間クラス)

// Responsibilities:
// ・ 一人の人間に対応し、その情報を管理する。
// ・ 人間に対して「名前」「社員コード」を設定・取得することができる。
// (SetName, GetName, SetIDNumber, GetIDNumber)
// ・ 人間は、どの部署にいるのかを返すことができる。(GetDep)
// ・ 人間は、その上司オブジェクトを返す事ができる。(GetBoss)

// Collaborators:
// ・ 人間クラスは部署クラスと N:1 の「所属する」という関係をもつ。
// ・ 上司オブジェクトは所属している部署クラスに問い合わせる事で得る。

一応 CRC のつもりです。

あとは全体の見通しをよくするためのクラス図。全クラスは
描きません。OOA/OODで抽出されたクラスだけです。実は
私もこの程度しかしてません。

実は昔、私は「複数の実体があるのは，一貫性を維持するのが困難
だから、全て一つだけで記述しなければならない」と考え、設計もコメント
(本当にただの一行のコメントも)書かないで作業していたときもあります。
3年間ぐらい、そんなスタイルでやってました。でも、それはナンカ違うな
と思ったんです。

>人月の神話は，初版も第2版も読みました．何回も読みました．

そーですか。それでもそう思われるのならば、私の出る幕ではないかと。

>ここでわたしの対象としているソフトウェアはいわゆるシュリンクラップみたい
>なやつで，原子力発電所の制御とか，航空機のなにとか，そーゆーものではない
>です．そこそこの品質の製品をどーつくるかの話ですね．

わからんでも無いですが、やたらと「攻撃的」な手法である気がします。
「失敗した時のことは考えるな、成功すればいいんだから」的なです。

[Oseto Futoshi]

大瀬戸＠茶々丸です。:-)

In article <lvd8cp7q...@picachu.netlab.co.jp>, ma...@netlab.co.jp says...

>| とりあえず、「銀たま」か「コードコンプリート」でも読まれては
>|いかがですか。
>

>「銀たま」(うーん凄い略称)は読みました．

えっ！？「銀たま」って言わないんですか？

[Hiro Yoshioka]

茶々蔵です．

> 大瀬戸＠茶々丸です。:-)

> >| とりあえず、「銀たま」か「コードコンプリート」でも読まれては
> >|いかがですか。
> >「銀たま」(うーん凄い略称)は読みました．
> えっ！？「銀たま」って言わないんですか？

若いプログラマ志望の女の子なんかに，
ぼそっと「銀たま」とか言えないっす．
あれは名著だからよまんといかんよ．とか．

よ

[Hiro Yoshioka]

よしおかです．

大体双方の主張がでそろって，なんとなく
見解の相違ですね，とかいう感じで落ち着こうと
している予感がする今日このごろです．

> 妹尾です。

> >がびーん．コードを読めばわかることをなぜわざわざ別の形式にしなければいけ
> >ないのだろうか？
> コードはアーキテクチャの実現例であって、そのものではないからです。
> 極論すれば「コードを読めば解るのなら、ソースコードでなくて、アセンブラ
> コードでもいいですよね」とも言えるかと。当然、そんな主張はしません。
> ソースコードにはアセンブラコードに記述されない、意味が込められています。
> おなじく設計にもプログラムコードには記述されない意味が込められて
> います。
> つまり「コードを読んでも解らない」からです。

なぜこういう実装をしたか？という問いにはソースコードは
答えていませんね．確かに．その部分は同意します．

従って，なぜこーゆー実装をしたかという事を
記すというのは重要であるという点においては，
意見の一致を見そうなきがします．

でも，それって，コードにコメントで書くのじゃ
だめなんですか？だめなんでしょうね？

> >詳細設計(？)のドキュメントを作るなんて時
> >間のムダだと思ってしまうなあ．
> あれって、「設計」なんですかね？私も疑問を感じてます。
> 私も実装方法を記述したドキュメントなんか要りません。大体ウソしか書いて
> ないし。

おお，ここでも意見の一致をみそうですね．

> >なにをもって，「ドキュメントの不備」という
> >のか，「まともな設計」というのかをわたしが理解していないからだとは思うの
> >ですけどね．
> ここで「まともま設計がされていない」というのは、そのアークテクチャが
> まるで表現できないようなプログラムになっているような場合を想定してい
> ただけるとありがたいです。

これって実装がたこだということを言っていますか？

> プログラムがあるからといって、それに読解可能な「アーキテクチャ」
> があるとはかぎらないですよね。

「アーキテクチャ」を反映していないプログラムからは
いくらプログラムを読んだところで，「アーキテクチャ」を
読解できない，という事ですか？

そりゃそうでしょうね．それはプログラムが
悪いわけですから．

> >> ただ、ドキュメントを整備しつづけるのは困難なので、プログラムと
> >> ドキュメントを一体化することはあると思います。でも、そのドキュメント
> >> を読むのと「実装を理解する」事は別物だと思います。
> >そうですか．現実問題として，一つのものを表現するのに複数の実体があるのは，
> >一貫性を維持するのが困難なんで推奨されていないし，
> そうです。だから私はソースコード中にコメントとして記述してます。これなら
> 少しは楽です。具体的には (C++の場合) ヘッダファイルに集中して書きます。
> こんなカンジです。

ここも意見の一致をみそうですね．
管理すべきはソースコードだけだと．

> あとは全体の見通しをよくするためのクラス図。全クラスは
> 描きません。OOA/OODで抽出されたクラスだけです。実は
> 私もこの程度しかしてません。

なるほどね．

> >人月の神話は，初版も第2版も読みました．何回も読みました．
> そーですか。それでもそう思われるのならば、私の出る幕ではないかと。

今，手元に第２版を置いているのですけど，
ドキュメントについては１５章に書いてあると
思うのですが，そこで「フローチャートの呪い」
ということで，その役割を否定しています．
また「自己文書プログラム」ということで
プログラムのコードの中に文書を入れる事を
提案してます．

”プログラム文書は悪名高いほどに貧弱で，
そのメンテナンスはさらにひどい．プログラムの
変更が，すみやかに正確にそしてそのまま
紙の上に記述されることはない．”
．．．
”主要な目的は，文書作成の負担を最小化することだ．”

ということで同じ本を読んでもまるっきり違う
解釈というか，印象というか，アプローチを
読み取るという事例なんでしょうね．

> >ここでわたしの対象としているソフトウェアはいわゆるシュリンクラップみたい
> >なやつで，原子力発電所の制御とか，航空機のなにとか，そーゆーものではない
> >です．そこそこの品質の製品をどーつくるかの話ですね．
> わからんでも無いですが、やたらと「攻撃的」な手法である気がします。
> 「失敗した時のことは考えるな、成功すればいいんだから」的なです。

ブルックスの第２版では，漸増的構築モデルということで，
マイクロソフトの「毎晩構築」アプローチを紹介してます．
デイリービルドとかナイトリービルドとか呼ばれている
やつですね．これは毎日毎日ビルドを繰り返して，
徐々に機能を洗練しいくアプローチです．

毎日のビルドでは常に動くプロダクトが得られます．
時として機能の後退（リグレッション）が発生しますが，
毎日ビルドしてリグレッションテストを流していますから
すぐに発見できます．いつ失敗してもいいのだけれど
それを発見してすぐに修正するというプロセスが
組み込まれています．

このプロセスのダイナミズムを理解しないと
なかなかシュリンクラップの現場の勢いを
理解できないかなと思います．

一つのプロダクトが出荷されるまでに
ものによっては数百回，あるいはそれ以上
ビルドされて，常に修正されるというイメージです．

よ

[Oseto Futoshi]

In article <01bd8f88$5b558f20$91ab...@yoshioka.vip.best.com>, yosh...@best.com says...

>> >「銀たま」(うーん凄い略称)は読みました．
>> えっ！？「銀たま」って言わないんですか？
>
>若いプログラマ志望の女の子なんかに，
>ぼそっと「銀たま」とか言えないっす．
>あれは名著だからよまんといかんよ．とか．

では、「臨月の神話」と紹介したら？:p:p:p

＃ホント、ここまでにします。
＃大変、失礼しました。m(_ _)m

[Kiyohiko Kajihara]

妹尾さんではなく，梶原＠ＮＴＴソフトウェア研究所ですが．

>> 設計はプログラミングより重要だと思いますけど、どうですか？

|はあ，きっと妹尾さんには「設計とプログラミングがそれほど分離
|していない状況」ってのが想像も出来ないんでしょうね．まあ，育っ
|た環境とかありますからしょうがないんでしょうけど，ねえ．

設計が「システム全体あるいはサブシステムのレベルでの構造や，制御の基本
方針の決定」と定義するなら，プログラミング「各モジュールの役割を決め，
コードを記述すること」とは別のものであるわけです．あるいは「モジュール
の役割を決め，インタフェースを明確にすること」と設計を定義するなら，
プログラミング「各モジュールのアルゴリズムを決め，コードを記述すること」
も別のものですよね．

つまり，設計とプログラミングはシステムの異なる特性を決定（記述）すること
なわけです．

規模の大きなソフトウェアは複雑なので，決定の対象範囲の分割または決定の
順序を設計→プログラミングと分離する必要があるわけです．後者の場合当然，
スムーズにつながらない場合が多いので調整が必要です．前者の場合には，設
計とプログラミングを同じ人が担当した方が効率的ですが，分割損や分割した
ものどおしの調整が必要です．

結局，開発チームの構成やメンバの能力／経験，プロジェクト管理方法などから
決めることになるのであって，「設計とプログラミングを分離すること」がよい，
悪いということではないでしょ．状況によりどちらがより適しているかです．

-- kajihara of NTT Software Labs.

[SENOH Yasushi]

妹尾です。

Hiro Yoshioka wrote in message

<01bd8f95$7ababf40$91ab...@yoshioka.vip.best.com>...

>でも，それって，コードにコメントで書くのじゃ
>だめなんですか？だめなんでしょうね？

いいんじゃないですか。
私はそうしていると書いたつもりですが...。

>> ここで「まともま設計がされていない」というのは、そのアークテクチャが
>> まるで表現できないようなプログラムになっているような場合を想定してい
>> ただけるとありがたいです。
>
>これって実装がたこだということを言っていますか？

そうですね。ただ、私の立場ではそんな風に実装がタコになるのは設計が
悪い(またはされていない)からだという事です。この辺は宗教かもしれません。

>今，手元に第２版を置いているのですけど，
>ドキュメントについては１５章に書いてあると
>思うのですが，そこで「フローチャートの呪い」
>ということで，その役割を否定しています．

これって「詳細設計 or プログラム設計」だと思うので、私も否定している
つもりですが...。

>また「自己文書プログラム」ということで
>プログラムのコードの中に文書を入れる事を
>提案してます．

これもしていると書いたつもりなんですが。

>”プログラム文書は悪名高いほどに貧弱で，
>そのメンテナンスはさらにひどい．プログラムの
>変更が，すみやかに正確にそしてそのまま
>紙の上に記述されることはない．”
>．．．

こういうのは必要ないと書いているつもりなんですけど。

>”主要な目的は，文書作成の負担を最小化することだ．”
>
>ということで同じ本を読んでもまるっきり違う
>解釈というか，印象というか，アプローチを
>読み取るという事例なんでしょうね．

どこが違うんでしょう？

設計と実装は分けましょうとは言ってますが、この手の文書を
作成しようとは言ってないつもりです。つまり設計者がコメントとか
クラス定義を書くんです。そして、プログラマはこれを勝手に変え
てはいけないと。

設計者とプログラマが同一人物であることはあると思いますが、
ちゃんと、それぞれに立場にそって作業すべきです。この場合も
「プログラマ」が勝手に(コメントやクラス定義で表現されている)設計
を変えちゃだめです。一度「設計者」に戻らないと。さらに場合に
よっては「設計者会議」が必要かと。

>ブルックスの第２版では，漸増的構築モデルということで，
>マイクロソフトの「毎晩構築」アプローチを紹介してます．
>デイリービルドとかナイトリービルドとか呼ばれている
>やつですね．これは毎日毎日ビルドを繰り返して，
>徐々に機能を洗練しいくアプローチです．

だからといって、プログラマが設計を変えていいわけじゃないです
よね。よしおかさんのやり方は「プログラマが設計を変える」ような方法
だと思ったのですが、違うんでしょうか？

[Yukihiro Matsumoto]

まつもと ゆきひろです

kaji...@ammonite.slab.ntt.co.jp (Kiyohiko Kajihara) writes:

|妹尾さんではなく，梶原＠ＮＴＴソフトウェア研究所ですが．

| |はあ，きっと妹尾さんには「設計とプログラミングがそれほど分離
| |していない状況」ってのが想像も出来ないんでしょうね．まあ，育っ
| |た環境とかありますからしょうがないんでしょうけど，ねえ．

|結局，開発チームの構成やメンバの能力／経験，プロジェクト管理方法などから

|決めることになるのであって，「設計とプログラミングを分離すること」がよい，
|悪いということではないでしょ．状況によりどちらがより適しているかです．

もちろんです．私は「そういうやり方が存在している」ことを示し
ているだけで，「そのようなやり方がいつも優れている」とは述べ
ていないつもりです．

# 存在を認めてなければ「どちらがより適しているか」とは言えま
# せんものね．

私には妹尾さんは「そのようなやり方」を認めていらっしゃらない
ように読めました．