ソフトウェアの設計とは何か？

**名無しさん＠お腹いっぱい。** · 2007/09/06(木) 14:33:01

工学の活動の最終目的は、なんらかのドキュメントです。設計の作業が完成したときには、
設計書は製造チームに渡されます。これは、設計チームとは全く別の技能をもつ全く異なる
グループです。設計書が完全な設計を体現している場合には、製造チームは製品を作ること
ができます。実際に、彼らは設計チームとの交渉をほとんど行わずに、製造を進めることが
できます。ソフトウェアのライフサイクルを検討してみた後に、私は工学的な設計の条件を
満たす唯一のドキュメントは、コーディングのソースリストであるというであるという結論
に達しました。

What Is Software Design?
By Jack W. Reeves

ttp://www.developerdotstar.com/mag/articles/reeves_design.html

Jack W. Reeves氏の指摘について、考えてください。

**名無しさん＠お腹いっぱい。** · 2007/09/06(木) 19:32:56

うん，正しいと思う．つーかKnuth先生も同じようなこ
と言ってなかったっけ

**名無しさん＠お腹いっぱい。** · 2007/09/06(木) 21:05:09

>条件を満たす唯一のドキュメントは、コーディングのソースリスト
これはそのとおりなのだが、その前に言っていることがつまらない
ので、案外こちらが思うほどの含意はこめられていないかもね。

**名無しさん＠お腹いっぱい。** · 2007/09/07(金) 12:02:45

>2
Knuth先生は、ソフトウェアのライフサイクルを考慮して、そういうことを言っているのでしょうか。不勉強ですが、教えてください。

>3
Reevesは、産業としてのソフトウェアの開発過程について考察しているから、工学の性質を引き合いに出しているのです。
ソフトウェアシステムの産業としての開発の現状に対する疑問で、抽象的な一般論ではない。そのあたり、どう思いますか？

**名無しさん＠お腹いっぱい。** · 2007/09/07(金) 23:09:14

>>4
ふつうよりはものが見えている人だと思うが、C++の評価
などを読むとすごく見えているとも思えない。今はどんな
ことを言っているのでしょうか？あまり進んではいないの
ではないかと

4 · 2007/09/08(土) 10:11:13

>>5

Reevesは学者ではなく、経験豊かな技術者、ソフトウェア開発者なので、
次から次へと奇抜な「理論」を発表するようなタイプではないと思い
ます。1992年に"What Is Software Design?"をC++ Journalという雑誌に
発表したのだが、間もなくこの雑誌は廃刊になったらしい。

13年後の2005年に13 Years Laterという論文を発表し、前論文に対する
さまざまな批判、誤解に対して、反論しています。あまり安易に要約は
できないので、それは控えます。

ttp://www.developerdotstar.com/mag/articles/reeves_13yearslater.html

ところで、質問に対して質問を返すようですが、

＞C++の評価などを読むとすごく見えているとも思えない。

のあたりをもう少し詳しく語ってくれませんか。彼のC++の
評価のどのあたりを言っているのでしょうか。私の理解では

C++ has become popular because it makes it easier to design
software and program at the same time.

つまり、C++はソフトウェアの設計を行うのと同時にプログラミング
を行うことを容易にしたから、成功したのだと言う点が、彼の視点
で、つまり、コードが設計だという全体の発想と調和していると思う
のですが。

**名無しさん＠お腹いっぱい。** · 2007/09/08(土) 12:29:51

吹いたら負け　フタエノキワミああああー
http://anime2.2ch.net/test/read.cgi/asaloon/1189218197/

**名無しさん＠お腹いっぱい。** · 2007/09/08(土) 18:58:39

>>6
90年代初の時点でC++をそれほどに理想視していた点。
結果論ではなく。

4 · 2007/09/09(日) 13:22:35

>>8
理想化していたわけではないと思うけど。
90年代初はOOとかC++が非常に注目された時代だから、それについて語った
のでは。
C++は、言語自体まあよくできているし、（Cがよくできている面もあるが）
JavaとかC#のように簡易化された言語も派生したわけだし、現在でも有力な
言語系統になっている。
また、OOという考え方は、80年代に構造化言語がスタンダードになったように
現在ではスタンダードになっている。

**名無しさん＠お腹いっぱい。** · 2007/09/09(日) 13:32:52

OO = Object Oriented??

4 · 2007/09/09(日) 16:42:46

>>10
そうです。

**名無しさん＠お腹いっぱい。** · 2007/09/09(日) 20:53:39

http://money6.2ch.net/test/read.cgi/venture/1008922867/

アスキーの西氏が取締役を退任Part25

**名無しさん＠お腹いっぱい。** · 2007/09/26(水) 23:59:27

しかし、完全な設計書は現実には不可能。

**名無しさん＠お腹いっぱい。** · 2007/10/03(水) 11:00:27

>>13
設計書で完全さなど求める時点で間違いだろう。
理念や概念の律する内容であって、どちらでも良い詳細を記述する時点で
無駄な作業になる。
必要なのは矛盾のない点や、表現と理解のしやすさ、誤解の受けない内容、
詳細を記述していないのに詳細まで特定する表現方法。

末端のプログラム作業を本業で行っている者がプログラムの設計と
ソフトウエアの設計の差が理解できずに誤解を生む事が多い。
ユーザーが示す機能仕様と、ソフトウエアが必要とする機能仕様でも
激しい差がある、この当たりも経験が伴わないものには理解できないようだ。

**名無しさん＠お腹いっぱい。** · 2007/10/03(水) 23:08:33

>>14
シンプルな言い回しで、かつ要領を得た意見を頼む。

**名無しさん＠お腹いっぱい。** · 2007/10/23(火) 11:38:33

設計書という狭い考えだけでしか考えてないんじゃないか？

設計は設計技術というものでいろいろな側面を持っているだろう。
設計を標準化する必要性があったり、専門用語や表や図の示し方や、
設計で必要な一般形式、設計が正しく解釈される為の分析の表現方法や
設計の目的になる概念を表す概念図やフローのようなもの。
設計で考えるべき多面性での偏りを防止するためのマトリクス形式の
洗い出しをした多面的から見た表などは重用な要素でしょう。
必要な要素だけを抜き出したような箇条書きでの設計内容や図や機能の
説明では部分だけが誇張され死角になる部分が必ず生まれると思われます。
また、他の作業をする為の連動する工程や作業割り当ての連携に対する
帳票や報告や経過なども表裏一体として技術的に繋がっている
必要性があると思われます。
これらは熟練した上位設計の経験者や各社や関連技術をもっている人、
さらに設計技術を解説した書籍などとも連携し、そのソフトウエア設計をする
部署全体での設計方針というマニュアルが必要で、これらの品質を上げる為の
要素を無駄だと判断するような人たちには、名前だけの設計書という形しか
生まれないと思われます。
作ればいいという話で済ますのでは、今後を無視した建前的の作業となり
将来に渡ってやシステム全体としての役割は最悪な方向へ向かうように
思われます。