構造とふるまい

ソフトウェアの表現に用いられる概念として「構造」と「ふるまい」を対比させた上で、両者に対する考察を試みる。

導入


もうだいぶ前になりますが、Greg Young氏がBDDに向けて批判的な論考を書いたことがあります。批判の内容について言及することはここでの主旨から外れるので避けますが、このブログ記事から明確に浮かび上がる1つの対比があります。ここでYoung氏が示しているのは、ファサードドメインモデルの対比、より正確に言えば、ドメインモデルのファサードを記述するテンプレートとしてのストーリーと、ファサードの内側に存在するドメインモデルを記述するためのユビキタスランゲージという対比です。


BDDのストーリーテンプレートによるふるまいの記述が、実はドメインモデルのファサードを記述したにすぎず、実際のドメインモデルはファサードの内側に活き活きと存在しているものだというこの主張は、DDDが提示するドメインモデルに関する理解を深めてくれるものでもあります。しかしここでは、この対比をソフトウェアの記述に用いられる概念としての「構造」と「ふるまい」に置き換えてとらえ直すことによって、ソフトウェアについて記述することについて考えたいと思います。*1

概念が構造を生み出す


現在、言語学と呼ばれる研究分野の枠組みをつくったのは、スイスの言語学者であるソシュール(Ferdinand de Saussure 185-1913)であるとされています。ソフトウェア開発に携わる方々にとってなじみのある名前ではないと思いますが、彼の思考はソフトウェア開発に対しても重要な示唆を与えてくれます。彼の有名なテーゼに「言語には差異しかない」というものがあります。つまり、ある言葉はそれが1対1で対応する何らかの実体を指し示すものではなく、世界を恣意的に切り取り、他と区別してみせるにすぎないということです。


オブジェクト指向が目指したものは「人間のメンタルモデルを表現すること」でした。この試みは人間が自己のメンタルモデルをどのように構築しているかを探る試みでもあったはずです。オブジェクト指向の黎明期においてソシュールがどの程度まで意識されていたのかは分かりませんが、諸概念とその関係に見る点において両者には共通しているものがあるように思えます。相互の関係が明確に定義された諸概念が集まって生み出されるものが構造であり、これはオブジェクト指向がかなり高いレベルで成功した場所であると言えるのではないでしょうか。


構造の記述には成功している一方で、ふるまいを記述することについては、オブジェクト指向が苦手としているということが指摘されていますが、これは必ずしもオブジェクト指向の欠陥ではないような気がしています。むしろ、人間の精神自体が、「構造的に理解し、線的に思考/記述する」というあり方をしていることによるものと考えるべきなのではないでしょうか。構造に重点を置けばダイナミックな側面は失われますし、ダイナミクスを線的に記述しようとすれば構造を理解するために再構築が必要とされます。そして再構築の際に求められる解釈は再構築後の構造の同一性をゆるがすことになります。

有限オートマトン


ソフトウェアのふるまいも構造的であるよりは線的なものです。このようなふるまいはどのように記述するべきなのでしょうか。この点については、Uncle Bobがブログ記事「http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd」において優れた洞察を示しています。Uncle BobはBDDのストーリーテンプレートであるGIVEN/WHEN/THENが「原因と結果という人間の考え方を、入力/処理/出力(input/process/output)というソフトウェアの考え方と結びつけ」るものであるとした上で、それが有限オートマトンの記述方法であるとします。

This strange similarity caused me to realize that GIVEN/WHEN/THEN is simply a state transition, and that BDD is really just a way to describe a finite state machine. Clearly “GIVEN” is the current state of the system to be explored. “WHEN” describes an event or stimulus to that system. “THEN” describes the resulting state of the system. GIVEN/WHEN/THEN is nothing more than a description of a state transition, and the sum of all the GIVEN/WHEN/THEN statement is nothing more than a Finite State Machine.


この奇妙な類似によって気がついたのは、GIVEN/WHEN/THENが単に状態遷移にすぎず、したがって、BDDは実は有限オートマトン("Finite State Machine")を記述する方法にすぎないということです。明らかに「GIVEN」は、調査対象のシステムの現在の状態であり、「WHEN」が記述するのはそのシステムに対するイベントないし刺激であり、「THEN」が記述するのはその結果として起きるシステムの状態です。GIVEN/WHEN/THENは状態遷移の記述以上のものではなく、GIVEN/WHEN/THEN形式の文章を全て集めたものは、有限オートマトンでしかありません。

その上で、問題を有限オートマトンとして記述することのメリットとして、状態とイベントを数え上げることで、システムを通過するパスの数を閉じることができる点を上げています。これは言い換えれば「ふるまい」の過程を記述せず、事前条件/事後条件という形で瞬間を切り取るという形で前と後を固めることによってふるまいを浮かび上がらせるという考え方です。

まとめ

メンタルモデルを構成する諸概念とその関係として、あるいは事前条件/事後条件を示した一連のテストスイートとして、ソフトウェアのスタティックな側面はこうして記述されることになります。ソフトウェアの実行においては絶対に必要となるは、ソースコードによって表現され、スレッドによって実現されます。線的な記述を表現する場所をソースコードだけに限定することで、構造の変化に伴うパスの変更負荷を最低限に抑えることができるようになります。「構造」と「ふるまい」を自覚的に対比させることが、軽量かつ確実にソフトウェアを記述する上でのヒントになるのではないでしょうか。



Photo Credit

*1:なお、ドメインモデルが最終的には「動作するソフトウェア」である以上、「ドメインモデル=構造」ではなく、「ドメインモデル=構造+ふるまい」になるのだと思いますが、記述力という点から考え、記事の中では「モデル=構造」という解釈の上で考えています。