最新記事一覧
建築の世界ならば、アーキテクチャとは実際に作られた建築物であると同時に、そのスタイルであり、構造であり、発表された論文である。ソフトウェアのアーキテクチャとは、出来上がったソフトウェアそのものであると同時に、知識のソフトウェアへの作り込みである。（本文より）
()
作り過ぎているという問題には、2つの側面がある。1つは量の問題で、本来作らなくてもいいはずなのにいっぱい作り過ぎているということ。（本文より）
()
アーキテクトが見るものが形だとすれば、後者が見るものは時間である。形を表したものがモデルだということにすれば、時間を表したものはストーリー（物語、歴史）だといってもいいかもしれない。（本文より）
()
残念ながら、第8回「建築家の視点、アーキテクトとしての共通認識」の最後でお約束した第2シーズンには、もろもろの事情があって今回はまだ突入できなかった。それまでのつなぎとして第1シーズンの番外編をお届けしようと思う。
()
……確かに建築は幾何学的な側面を持つ。しかしもっと抽象的なソフトウェアにとってこの「幾何学的特性」とは何を意味しているのだろうか？ UMLモデルか？ 確かにソフトウェアのアーキテクチャを何らかのダイヤグラムに表したときの幾何学的特性が意味を持つかもしれない。（本文より）
()
……動きの入っていないモデルはいくら精密に美しく書かれていても、「実行可能知識」であるソフトウェアとしては、「仏作って魂入れず」なのである（本文より）
()
……そういう意味では「コード」よりも「動く知識」といった方がいいかもしれない。アーキテクトの仕事は、要求をドメイン知識やアプリケーション知識を利用して動く知識に変換することであった（本文より）
()
オブジェクト指向のポリモルフィズムは一部の人から「何が起こるか分からない」という理由でひどく嫌われている。われわれソフトウェア・アーキテクトにとって「柔軟につなぐ」ということは、良いことなんだろうか、悪いことなんだろうか（本文より）
()
ある程度の経験を積んだプログラマならば、UMLなどのダイヤグラム表現を使わなくても、単なる文字列であるプログラムからさまざまなイメージ、感覚（最近のはやり言葉でいえば「クオリア」）を感じ取ることができるだろう（本文より）
()
ソフトウェア開発とは問題ドメインの知識をアプリケーション・ドメインの知識に変換することだといってもいい。（本文より）
()
知識にはいろいろな性質がある。モジュール性、伝達可能性、柔軟性、抽象性、具体化可能性などなど。単に知識が「あればいい」というわけではない。「知識の質」、特に「知識のダイナミクス」を支える質が重要なのだ。今回はその1つ、知識の検証可能性ということを考えてみることにしよう。（本文より）
()