[PukiWiki]
AlexanderReading19
http://patterns-wg.fuka.info.waseda.ac.jp/st/index.php?%5B%5BAlexanderReading19%5D%5D

[ リロード ]   [ 新規 | 編集 | 差分 | 添付 ]   [ トップ | 一覧 | 単語検索 | 最終更新 | バックアップ | ヘルプ ]

最新の20件
2008-03-172007-07-072007-07-032007-06-222007-03-132005-10-172005-09-272005-09-262005-06-302005-06-29

Alexander読み倒し議事録

第7回 「形の合成に関するノート」読書会の報告です。

 日時: 2005/9/8 (水曜) 19:10-21:20
 場所: 株式会社豆蔵 34F会議室
 参加人数: 7名 
 羽生田さん、勝田さん、横川さん、河合さん、湯浦さん、加藤さん、沖田
 内容: 「形の合成に関するノート」 7章 プログラムの実現

次回は10/5(水曜) 19:00からです。 第8章 「定義」を輪読します。

7章 プログラムの実現(The Realizeation of The Program)


全般

「プログラムの実現」とはF3のことを指している。 建設的なダイアグラムであることが重要。

  C1    F1
  ↓    ↑
  C2    F2
  ↓    ↑
  C3 → F3


建設的なダイアグラム

高速道路のダイアグラムの例は美しい。 形と要求のダイアグラムの両面を持っていることが分かりやすい。

やや突飛的で、主張はナイーブすぎるようにも思われる。 高速道路のダイアグラムありきで、後から理由をつけたという邪推もあり。


ソフトウェアプログラムでも建設的なダイアグラムはあるか?

ちょっと脱線。

UMLのダイアグラムでも一目見て分かりやすいものと、そうでないものが確かにある。 分かりやすいものは形が美しく、一貫性を持っている。主張したいことが伝わる。 一貫性は軸でも表現される。この一貫性を持ちつつ、整理された構造は結果として、美しいダイアグラムとなる。

ソースコードにも美しさはある。美しいコード→良いプログラムとはかならずしもいえないが、醜いコード→良くないプログラムはかなり一致する。 なぜだか分からないが、醜いコードは直感的に分かる。

美しいダイアグラムに関しては、ハードウェア開発者に比べてソフトウェア開発者は、追求が甘い気がする。 一因として、ハードウェア開発にとって設計図は重要な位置付けになっていることが挙げられるかもしれない。


まとめ

not found.

リロード   新規 編集 差分   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS
Last-modified: Tue, 27 Sep 2005 05:49:12 JST (4464d)
Link: Alexander読み倒し議事録(3932d)

Modified by Hironori Washizaki

"PukiWiki" 1.3.4 Copyright © 2001,2002,2003 PukiWiki Developers Team. License is GNU/GPL.
Based on "PukiWiki" 1.3 by sng
Powered by PHP 5.3.3

HTML convert time to 0.008 sec.