ドメイン・エンジニアリング温故知新
ソフトウェア開発とは問題ドメインの知識をアプリケーション・ドメインの知識に変換することだといってもいい。（本文より） ソフトウェア開発方法論とは「いかにしてシステムを分割するか」という“教え”そのものだった。構造化パラダイムしかり。「ソフトウェアをモジュールに分割せよ、分割せよ、分割せよ。して、その方法は……」。“……”の部分は100人の構造化信者がいれば、100通りのお告げがあった。そしてまた、オブジェクト・パラダイムしかり。「ソフトウェアをクラスに分割せよ、分割せよ、分割せよ。して、その方法は……」“……”の部分は100人のオブジェクト信者がいれば、100通りのお告げがあるのである。 最近、ソフトウェア開発方法論の神様は少し退屈していた。世の中、おしなべてオブジェクトばかりなのはよいとしても、神様の本当の出番があまりなかったから。みんなオブジェクトの称名（しょうみょう）には熱心だけれど
ソフトウェア設計とストーリーの記述について
アーキテクトが見るものが形だとすれば、後者が見るものは時間である。形を表したものがモデルだということにすれば、時間を表したものはストーリー（物語、歴史）だといってもいいかもしれない。（本文より） 「アーキテクト」とは形を作る者の謂いだ、ということをこの連載の最初に話した。アーキテクトの立場からすれば、ソフトウェアとは何かの「形」のように見えているというわけだ。でももちろんそれ以外の見方もある。ソフトウェアはたとえ出来上がった後でも静かに固まってじっとしているわけではない。ああ、こんなソフトウェアがあったらなぁという顧客や開発者の思いから始まって、その思いを具体化し、動かしてみて、思ったようにはいかず、何度も作り直し、使っているうちにだんだんユーザーの手になじみながら、アップデートされていく、ソフトウェアの見え方もある。 アーキテクトが見るものが形だとすれば、後者が見るものは時間である。形を
モデリング＝まねることの本質について
残念ながら、第8回「建築家の視点、アーキテクトとしての共通認識」の最後でお約束した第2シーズンには、もろもろの事情があって今回はまだ突入できなかった。それまでのつなぎとして第1シーズンの番外編をお届けしようと思う。 人はまねることによって成長する。オブジェクトも同じだ。オブジェクトにはクラスだとか、継承だとか、多相性だとかいろいろな側面があるけれど、実はそんなのはどうでもよくて、本質は何かを「まねる」ことにある。1つ1つのオブジェクトは何かをまねる、シミュレートする存在だ。 まず何よりもオブジェクトそのものがコンピュータ（あるいはCPU）をまねしている。それぞれのオブジェクトはレジスタあるいはメモリ（＝インスタンス変数）とプログラム（＝メソッド）とプログラム・カウンタ（＝継続）を持っているのである。そう考えればメッセージ交換（＝メソッド呼び出し）はネットワークで結合されたコンピュータ間でや
建築家の視点、アーキテクトとしての共通認識
……確かに建築は幾何学的な側面を持つ。しかしもっと抽象的なソフトウェアにとってこの「幾何学的特性」とは何を意味しているのだろうか？ UMLモデルか？ 確かにソフトウェアのアーキテクチャを何らかのダイヤグラムに表したときの幾何学的特性が意味を持つかもしれない。（本文より） 今回は少し趣を変えて、「本物のアーキテクト」、つまり建築に携わる人たちとわれわれがどのような接点を持っているのか、そこで彼我の間にどのような共通点と相違点があるのかを、彼らの著作をひもときながらざっくばらんに探ってみようと思う。 まずは磯崎新の「プロセス・プランニング論」（鹿島出版会、1997、『空間へ 根源へと遡行する思考』所収）より。建築の計画概念には3つの段階があるという。1つはクローズド・プランニング（閉ざされた建築）、もう1つはオープン・プランニング（開かれた建築）、最後はプロセス・プランニング（プロセスの建築）
「動く」ことを認識しながらソフトウェアを書く
……動きの入っていないモデルはいくら精密に美しく書かれていても、「実行可能知識」であるソフトウェアとしては、「仏作って魂入れず」なのである（本文より） ソフトウェアという「知識 （表現）」がほかの知識と大きく変わっているところは、「柔らか」く「移ろいやすい」ということ、そして「動く」ということだ。典型的な知識（表現）である書物は、いったん印刷されたらほとんど変わることはないし、「実行」されることもない。もっとビジュアル な知識（表現）、例えば、 CGアニメーションは確かに「動く」けれど、もちろんここでいう「動く」とは意味が違う。外界の何かに反応してあるいは自律的に内容が変化して、それがそれ自身の表現や外界に反映される、というのがここでいう「動く」ということだ。 それにもかかわらず、多くの人はソフトウェアを作る過程であまり「動く」ということに注意を払わない。確かに最近UMLのようなものを使っ
「要求」から「コード」に至る長く険しい道
……そういう意味では「コード」よりも「動く知識」といった方がいいかもしれない。アーキテクトの仕事は、要求をドメイン知識やアプリケーション知識を利用して動く知識に変換することであった（本文より） 「ソフトウェアを作る」というのは、顧客や市場のニーズを「動く」プログラムに変換すること、である。アーキテクトだのプログラマだのは、つまりそのための「変換装置」というわけだ。一部分の変換過程はコンパイラやマクロ・プロセッサ、モデル駆動開発などの技術によって自動化されているけれど、多くの変換過程はまだまだ人間の仕事だ。例えば古典的なウォーターフォール・プロセスを変換過程として考えるとこんな感じになる。 まず顧客やユーザーの頭の中にある要求を仕様というものに落とし込む。その変換過程が「分析」と呼ばれる仕事だ。 分析はあいまいで （一般的には）非定型的で矛盾を含んだ要求を、明確で定型的で矛盾のない仕様に変換
フレームワークの本当の意味
オブジェクト指向のポリモルフィズムは一部の人から「何が起こるか分からない」という理由でひどく嫌われている。われわれソフトウェア・アーキテクトにとって「柔軟につなぐ」ということは、良いことなんだろうか、悪いことなんだろうか（本文より） ソフトウェアを作るということは、物事を「分ける」=「分かる」ということである。分け方にはいろいろあるけれど、分けたものを分けたままにしておいても生命を持ったソフトウェアとして動きだすことはない。分けたものは、何とかしてつながなくてはならないのである。分けることを分析（analysis）といい、つなぐことを総合（synthesis）という（こともできる）。 ソフトウェアを作る場合において、物事を分ける方法には例えば「モジュール」「オブジェクト」「ドメイン」「アスペクト」といったさまざまな方法やレベルがある。そして、その裏には必ず分けたものをつなぐやり方が隠されて
モデリングの神さまが降りてくる瞬間
ある程度の経験を積んだプログラマならば、UMLなどのダイヤグラム表現を使わなくても、単なる文字列であるプログラムからさまざまなイメージ、感覚（最近のはやり言葉でいえば「クオリア」）を感じ取ることができるだろう（本文より） UMLの教科書を見ると、たいてい、モデリングの作業はまずユースケース図なるものを描きなさい、というところから始まっている。何を隠そう、筆者の書いたUMLモデリングの教科書もそうなっている。ま、これはこれで無理もない。UMLは従来のソフトウェア開発工程でいえば、要求分析から基本設計、詳細設計といった辺りまでをカバーするものと考えられているし、ユースケース・モデリングとはその要求分析を行うことにほぼ相当するとされているからだ。 ユースケースとはこれから作ろうとするシステムのユーザーがシステムに期待していることを記述したものだ。「サービス」「目的」「フィーチャ（feature）
知識とソフトウェアのギャップ、それをどう埋めるのか？
知識にはいろいろな性質がある。モジュール性、伝達可能性、柔軟性、抽象性、具体化可能性などなど。単に知識が「あればいい」というわけではない。「知識の質」、特に「知識のダイナミクス」を支える質が重要なのだ。今回はその1つ、知識の検証可能性ということを考えてみることにしよう。（本文より） この連載ではソフトウェアを「実行可能な知識（の1つの表現形態）」と見なす。「実行可能な知識」とは、さまざまな知識を表しているソフトウェアというものがまさに、CPU上で実行可能だということを意味する。これは従来の紙の上に書かれているだけの知識にはなかった特徴だろう。「知識」の範囲を少しだけ広げて考えれば、例えばビジネス・プロセスも実行可能な知識（ビジネス組織が実行する）だし、遺伝情報も実行可能な知識（生命体が実行する）と思ってよさそうだ。ソフトウェアは実は、こういうさまざまな存在とつながっている。 知識にはいろい
システムに適した知識の表現方法を探る
プロ （＝あらかじめ）・グラム （＝書かれたもの）、アーキ （＝形）・テクト （＝作る者）…。プログラムはCPUへの指令書だ。「まずメモリ4番地にある値を取ってこい」「それとレジスタAにある値を足せ」「その値をメモリ6番地に書け」……。プログラムがなければソフトウェアは動かない。でも、実は、ソフトウェアの本質はプログラムではない。プログラムはソフトウェアの一最終形態にすぎない。みんなうすうすその事実に気付き始めている。けど、なかなか「ソフトウェア=プログラム」のわなから抜け出せない。プログラムを書くことは気持ちいい（うまく動けばなおさら！）。だけど、ソフトウェアって何？ って考え始めると納期に間に合わなくなる。 Javaを使っている人も、Javaが嫌いな人も例えば次のページを見てみよう。 ◎ http://java.sun.com/j2se/1.4/ja/docs/ja/api/java/
mixi豆テクニック集(仕様が変わるまでの保存版):地獄変00
利用者数が50万人を突破したmixi。もうSNSと言うよりはmixiという新しいメディアですね。 しかし、ここまで利用者数がいる割にはmixiを利用する際の豆知識的なものがあまり浸透していないなぁ、感じることが多いです。最終ログイン時間を更新しない方法とかアクセス禁止にされたときの挙動とか。 そこで、今回はmixi豆テクニック集(仕様が変わるまでの保存版)として、メジャーなものからマイナーなものまでいろいろピックアップしてみました。いつぞやのネットランナーの記事ではmixiの規約違反になるようなものを掲載していましたが、ここにはそういうものはないので安心してどうぞ。 ちなみに、mixiに書かずにBlogに書いているのはmixiは検索性がえらく低いから。また、このエントリーはmixiは現状このような仕様になっていることを記述したもので、mixiに仕様変更などを求めるものではないです。 ログイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://news.com.com/How%20the%20Mac%20was%20born,%20and%20other%20tales/2008-1082_3-5529081.html
http://showcase.blogpulse.com/conversation?link=http%3A%2F%2Fshowcase.blogpulse.com%2F&max_results=25&start_date=20050329&Submit.x=29&Submit.y=7