やさぐれ日記 (January, 2004)
2004/1/31（土）
-
「チョコとん」で有名な早稲田の店「フクちゃん」が2月7日に閉店する。ということで、首藤くんの同期であるOB二名（浜中くん、山下くん）と修士2年の酒井くんを連れてチョコとんの食べ納め（と言っても食べるのは今回がはじめて）に行く。
-
とはいっても、チョコとんだけで一人前食べる勇気はなかったので、一人（酒井くん）がチーズメンチを、もう一人（僕）がチョコとんを頼み、半分ずつ交換するという作戦に出た。
-
さて、はじめて食べたチョコとんの味だが…チョコの味しかしないよ、これ…でも一応食べられる。
-
ソースをかけてみた…今までに経験したことのない、不思議な味になった。悪くないかも。
-
食べ終わった後に、写真を撮るのを忘れていたことに気がつく。せっかくデジカメ持っていったのに…
-
全員そのまま研究室へ向かう。放言モードの山下くんが柴田くんにカラんでいた。暴言モードでカラまなかっただけ、まだ良いか。
-
その後浜中くん、山下くん、僕で秋葉原めぐり。結局「CPUの創りかた」を買ってしまったよ…
-
2004年2月以降の日記はtDiary形態に移行することにした。こちらからどうぞ。
2004/1/25（日）
-
"Executable UML:A Foundation
for Model-Driven Architecture"を引き続き読む。繰り返し登場する、Domain（領域）なる言葉が、この本を読み解くための重要なキーワードらしい：
-
「Domainとは、現実、仮説、あるいは抽象的概念に基づいた、自律的世界のことを指す。Domainは、固有の規則や方針に従って活動する、概念的存在の集まりから構成されている」(p.30)
-
アプリケーションを作成する場合には、まずそれを構成するDomainを複数定義し、次にそれらDomain同士の結びつきを記述した、Domain
Chartと言う図を作成する、という作業を最初に行うらしい。
-
Domainというのが何者なのか、実は上の定義を見ただけではなんのことやらよく分からなかったのだが、オンライン書店を例にしたアプリケーションの構成例で、「在庫管理」「Web
GUI」「クレジットカード処理」「メッセージング」などといったDomainの集まりが線で結ばれている図を眺めているうちに、Domainを「コンポーネント」という言葉で置き換えると理解しやすそうだということに気がついた。
-
コンポーネントといえば鷲崎さん、ということで、関連しそうなページから引用：
-
「未だにコンポーネントの定義は定まっていない。しかし、最大公約数的には、階層化および標準化された特定のソフトウェアアーキテクチャ上で、定義の詳細を知ることなく（ブラックボックスとして）公開されたインタフェース定義をもとに提供する機能を利用可能で、単独で置換可能な複数のバイナリファイルで構成されるソフトウェア部品ということができる。
置換可能および Plug-and-Play 可能とは、コンポーネントのインタフェース定義がその実装から明確に分離されていて、実装によらずインタフェース定義による協調動作・接続が可能であり、公開されたインタフェース定義に基づく周囲のソフトウェア構成が、コンポーネントの実装の変化に影響を受けないことを意味する」
（「コンポーネントウェア技術の確立に関する調査研究」資料）
-
Domainの方がトップダウンかつ抽象的なのに対し、コンポーネントはボトムアップかつ具体的という、成り立ち上の違いはあるようだが、個々で完結していること、内部に複数の実体（クラスなど）を持つこと、個々のDomain/コンポーネントは他に大きな影響を与えずに置き換えることが可能なことは共通しているようだ。まだ結論は出せないが、両者はかなり近いところにいるのではないかと思う。
-
"Modern
Compiler Implementation in ML" は現在121ページ。型の整合性チェックをする箇所のプログラミングに着手したところ。読了見通しは、6月中旬から8月の中旬の間あたり。
2004/1/24（土）
2004/1/19（月）
2004/1/18（日）
-
1/10より読み始めていた"UML
Distilled (Third Edition)"(Martin
Fowler)を読了。以下コメント：
-
第一章では、「(1)プログラム中の要点を押さえるためにUMLをスケッチ的に使い、プログラムの詳細の記述には使用しない」派と、「(2)プログラムの詳細（青写真）を記述するためにUMLを使用する」派、「(3)UMLそのものをプログラミング言語として使用する」派の3つの流派が存在していることが書かれている(2〜3ページ目)。
-
僕自身の立場は上記の(1)、つまりUMLをスケッチとして使うという流儀に近い。「UMLは抽象化の道具なのだから、クラス図で、あるクラスのメソッドを全部記述したり、数十個のクラスを一つの図に書くなんてのは意味がない。余計な細部は捨てなくちゃダメだ」と思っていたりする。
-
う〜ん、この手の話を始めるとやっぱり中立にはなれない…ということで、ぇぇぃ、この際だから言ってしまえ。
-
最近の本や記事で見かける、ユースケース先行の作り方の有効性にも僕は疑問を持っている。ユースケースはオブジェクトの実行順序と機能を重視するために、下手をするとオブジェクト指向とはほど遠い、手続き型のプログラムが出来上がってしまう危険性がある（2000年9月11日の日記）ためだ。
-
にもかかわらず、初心者向けにUMLを解説した書籍、例えば「UML
Press vol.1 はじめるUML・ぼくにもわかるデザインパターン」では、ユースケース図から入るサンプルを最初に提示している。出来上がったシステムのシーケンス図を見ると、一応Model-View-Controllerという構造らしきものはあるものの、実際にはControllerが全部の仕事を手続き的に実行しているだけのプログラム（青木
淳氏言うところの「コントローラが頑張るMVC」）が出来上がっている。ユースケース図のデメリットがはっきりと出たプログラムであり、初心者に見せるべき、良いお手本とは言い難い。
-
ユースケースの価値は図よりもその詳細を記述した文書の方にあるという意見もある。"UML
Distrilled"より：
-
「私にとって、ユースケース図の価値は以前ほどには感じられなくなって来ている。ユースケースにおいては、図よりも文章のほうに力を入れたほうが良い」（104ページより、サボり訳）
しかし図が文書になったところで、ユースケースが本来持っている問題、つまり実行順序と機能の過度な重視がなくなる訳ではない。ユースケース図はいわゆる要件定義にも使われるはずだが、要件の定義と、実行順序の話が混ざるのはやはり良くないのではないかと思う。
-
…ぁぁ、ついに言ってしまった。ユースケースの元祖であるJacobsonの本"Object-Oriented
Software Engineering: A Use Case Driven Approach"がとにかく読みづらくて苦労した恨みが今になって出たのか、八つ当たりのような文章になってしまった。もちろんユースケースが全くダメ、というつもりはなくて、使いどころに注意すれば有効である、とは思っている（とフォロー）。
-
"Modern
Compiler Implementation in ML" 現在110ページ。4章の練習問題は2つほど残したが、まぁよかろう。読了見通しは先週と同じく、6月始めから9月の始めの間あたり。
2004/1/11（日）
2004/1/9（金）
-
1/5より読み始めていた本"Structured
Walkthroughs"(Edward
Yourdon)を読了。以下コメント：
-
本書は1977年初版の非常に古い本。ただし基本的なテーマ自体は時代遅れになっていないことを再確認した。
-
全体を通して、見事な構造化がされているのに感心。英語の文章のお手本としても非常に良い。
-
本書によれば、ウォークスルーとピアレビューは同義の概念を指すものと見て良いようだ。
-
ウォークスルーを行う上で、複雑な手順を覚える必要はない。しかし正しく運用する方法を押さえるのが難しいので、本書ではいくつかのアドバイスを加えている。
-
「バグではなく仕様です」というのはMicrosoftが最初に言い出した言葉かと思いきや、104ページにこんな文章があった。
"In the extreme case, what they perceive as a bug in his product, he
will regard as a 'feature' of the product."
（極端な場合、ウォークスルーの他の参加者がバグであると思っているのに、ウォークスルーの対象となっているモジュールの作者は「仕様」であると言い張る場合すらある）
本書の出版は1977年、一方Microsoftの創立は1975年なので、実際のところは微妙だが、「バグではなく…」という言葉は昔からあったのではないかと推測される。
-
6日から参加していた「冬のプロシン」の総括：
2004/1/4（日）
Hideo
Fukumori (fukumori at m.ieice.org)