派生問題:オブジェクト指向は如何にして可能になるのかRUPの機能は、拡張と再利用が可能なパッケージとしての開発プロセスを提供すると共に、反復型のアーキテクチャ中心設計と漸進的なユースケース駆動型開発の区別を導入することによって、短いタイムスパンとリードタイムで<結果>を少しずつ目に見える形で提示していくことにある。それ故RUPは言わば小刻みなPDCAサイクルの絶え間ない反復を指し示している。方向付けフェーズでは既に「企画」の水準でシミュレートされた<結果>が要求され、遂行フェーズではアーキテクチャ・ドライバの特定に留まらずユースケース・モデルやプロトタイプによる<結果>の視覚化が求められる。制作フェーズは「ベータ版」開発として位置付けられ、移行フェーズすら「過渡期」と見做される。RUPはこの動的なサイクルの反復によって矢継ぎ早に<結果>を出し続けることで「速度」の問題を解消していく。RUPはそれ自体で完結した「マニュアル」ではない。これは「ライブラリ」のようなもので、各組織システムの開発プロジェクトに導入されて初めて成り立つ。RUPは、導入先の組織の企業文化やプロジェクトのユースケースに応じて、その都度「設計」されなければならない。これを前提とすれば、オブジェクト指向設計思想は、RUPを運用する場合にせよ、RUPを実践する場合にせよ、重要な位置付けにある。RUPはオブジェクト指向設計を推奨している。それだけではなく、RUPを運用する上ではオブジェクト指向設計思想に基づいた分析が必要になる。perspectives)」の差異を理解しなければならない。この差異は、二重の区別によって成り立っている。level)の区別だ。責任としてのオブジェクトオブジェクト指向におけるオブジェクトは単なる「データと操作の集合体」ではない。この前提に立ってしまうと、上述した三つの区別を理解することはできない。オブジェクトは「責任」を意味する。インスタンスは責務を遂行する実体に他ならない。概念水準のオブジェクト指向分析RUPのようにオブジェクト指向に準拠した開発プロセスでは、まず全てのソフトウェアを網羅的に設計するのではなく、アーキテクチャ・ドライバに関わる基本的な仕様となるサブセットを設計していく。そのためには、まず開発しようとしているオブジェクトが「そもそも何なのか(What)」を特定しなければならない。初めからそのオブジェクトの「実装は如何にして可能になるのか(How)」を考えてしまっては、何を造れば良いのかも定まらない状況で開発を進めることになるため、不確実性が高まってしまう。この「そもそも何なのか(What)」、すなわち「何の責任を担うのか」を特定する営みを概念水準での分析と呼ぶ。この分析の具体名がオブジェクト指向分析であると考えて良い。実装水準のオブジェクト指向プログラミング一方、やはり最終的には「実装は如何にして可能になるのか(How)」も決定しなければならない。この営みが実装水準となる。この実装の方法がオブジェクト指向プログラミングということになる。一つの開発で要求される責任が単一とは限らない。複数の責任が問題となる場合、複数のオブジェクトが必要になる。場合によっては、オブジェクト同士を結合することで、複合的な責務を担保しなければならなくなる。仕様水準のオブジェクト指向設計そこでオブジェクト指向では特に、複合的な責任を果たそうとしている複数のオブジェクトの結合部分となる公開インターフェイスの仕様化が目指されることになる。ここでいう公開インターフェイスの仕様化とは、あるオブジェクトがそのオブジェクトを「如何にして利用できるのか(How)」を共有する営みを意味する。使い方がわからなければ、仕様書など無いも同然だ。この仕様を共有する営みこそがオブジェクト指向設計に他ならない。GoFのデザイン・パターンは、まさに共通言語化による共有を目指した産物だった。概念水準の分析結果と仕様水準のインターフェイスを介したコミュニケーションのメリット概念水準や仕様水準で要求や仕様の共有を行なえば、システムの概要を伝達することができる。実装水準のコードの詳細を知らなくてもコミュニケートすることが可能になる。RUPのソフトウェア要求定義やアーキテクチャ設計は、まずこの概念水準と仕様水準でのみシステムを分析して設計していく。この区別を導入していると、概念や仕様を変更せずに実装を変更することができるため、コードが改修されたとしても、その実装の詳細を知らない者でも、インターフェイスを介してそのオブジェクトを利用し続けることができる。これは、インターフェイスのユーザーを実装の変更による影響から守ることを意味する。REST(ful)の仕様は、この概念と仕様の水準でコミュニケートしたわかり易い事例になっている。各APIのユーザーは、連携先のシステム内部の具体的な実装内容を全く知らない状態であっても、仕様として規定したHTTP(S)リクエストとレスポンスの形式に従うだけで、そのAPIを運用することができる。機能テストと結合テストと単体テストの差異オブジェクト指向を以上のように区別すると、テスト概念も適切に整理することができるようになる。test)」の差異は、責任という概念を前提として、概念水準と仕様水準と実装水準の差異に対応している。次のように纏めても良い。機能テストでは、成果物がオブジェクト指向分析結果と対応しているか否かを検証する。結合テストでは、成果物がオブジェクト指向設計結果と対応しているか否かを検証する。単体テストでは、オブジェクト指向プログラミング結果となるコードが成果物と見做せるか否かを検証する。以下、もう少し詳述する。機能テストは概念水準の検証になる。「そもそも何なのか(What)」、すなわち「何の責任を担うのか」に関する当初の予定と、実際に実装されたコードをはじめとした成果物との間に矛盾が無いことを確認していく。RUPの場合は特に、ソフトウェア要求定義などで取り上げたユースケース図やユースケース記述に成果物たるオブジェクトが対応し切れるか否かを検証する。いわゆる「ユースケース・テスト」は、ユースケース・モデルとコードの同期関係を確認するテストに他ならない。オブジェクト指向分析で組み立てたモデルと実際のコードが同期していなければ、そもそもその成果物は何の責任も果たしていないことになる。無価値と見做されても致し方ない。「ユースケース・テスト」に象徴されるように、一連の機能テストでは、システムの内部を事実上考慮しない。ユースケース図がアーキテクチャの内部を事実上考慮しない理屈と同じだ。その意味で機能テストは「ブラックボックステスト」であり、「限界値分析」や「同値分割」は「ユースケース・テスト」の機能的等価物として採用されても構わない。結合テストは仕様水準の検証になる。仕様によって共有されるのは、そのオブジェクトが「如何にして利用できるのか(How)」だ。したがって結合テストで検証すべきなのは、そのオブジェクトのインターフェイスが本当に仕様で規定されている通りに利用できるか否かになる。言い換えれば、結合テストでは、インターフェイス同士の結合を検証する。これにより、各オブジェクトのインターフェイスを介した相互利用が「仕様通り」に実現することを確認する。it.に矛盾があるということになる。その影響は他のオブジェクトに波及している。矛盾が見受けられるのならば、そのインターフェイスを抱えているオブジェクトの改修が必要になる。これは一種の「手戻り」であり、別途で退行テストが必要になる。ここでいう退行テストは、概ね単体テストのやり直しと考えて良い。結合テストケースを考察する上では、多くの場合「粒度」が問題になる。同じ結合部分でも、「APIとAPIのマッシュアップ」と「PHPとMySQLの結合」とでは、粒度に差異が生じる。この問題に対する普遍的な正解は無い。どの粒度が適切なのかは、専らオブジェクト指向設計で選択する必要がある。単体テストは実装水準の検証になる。「如何にして実装されるのか(How)」が問われる。詳細クラス図やシーケンス図やコミュニケーション図は実装を手引きしてくれるモデルとしても機能する。実際のコードがこれらのモデルと同期していなければ、仕様を満たせないオブジェクトとして実装されている危険がある。モデルとコードが同期していないということは、後続の開発でそのモデルを見直しても、現状のコードを俯瞰的に観察することが不可能になる。これは、ソフトウェアの全体像を把握することが不可能であるということになるため、後続の開発者との仕様水準でのコミュニケーションが事実上不可能になっていることを意味する。一般的に単体テストは致命的なバグを取り除くデバッグ作業と見做されている。いわゆる「ホワイトボックステスト」や「デシジョンテーブル」では、「分岐網羅」や「命令網羅」や「条件と動作の差異」などのような概念によって網羅性が問われている。した網羅性の問題は二次的な問題として格下げしてしまって構わない。仮にあらゆる条件や可能性を考慮したテストを実施したところで、最終的に提出される成果物たるコードがモデルと同期していないようでは、利用価値が無い。後続の開発による保守や拡張において、モデルによる俯瞰的な全体像の観察ができないようでは、「再利用」の対象にはなり得ない。単体テストの時点で消化しておくべきなのは、「クラス構造テスト」などのような静的テストだろう。よって、思わぬ修正や機能追加を余儀無くされる場合もある。以上のオブジェクト指向設計思想を前提とすれば、RUPを開発プロジェクトに導入する場合にも、オブジェクト指向で考えていかなければならないことがわかる。言うのも、RUPは拡張可能性と再利用可能性を確保したパッケージとして提唱されているからだ。この意味で言えば、RUPの運用や実践は等価機能主義的になる。言い換えれば、RUPと既存の開発プロジェクトの関係は相互にブラックボックス化されている必要がある。analysis)」は、ソフトウェアが相対する問題の領域を設定する上での問題解決策であった。この分析方法は、RUPと既存の開発プロジェクトの関連においても再利用されるべきであろう。共通性/可変性分析は文字通り「共通性」と「可変性」の区別を導入する分析だ。この区別は、概念水準と仕様水準と実装水準の区別と重なり合っている。共通性分析は、カプセルの中で纏め上げることで共通化することが可能な流動的諸要素の属性を意味する。一方で可変性分析は、共通化した場合に、特定のユースケースで逸脱し得る流動的諸要素の属性を意味する。共通性分析の観点は、概念水準と仕様水準に向けられる。可変性分析の観点は、仕様水準と実装水準に向けられる。共通性分析における仕様水準の観点によって、「概念水準から観た場合に共通して立ち現れる諸概念」を網羅して参照できる「インタフェースの仕様」を洗い出すことが可能になる。してある仕様水準の共通性が設定されることで、その共通部分との「差異」を伴わせる特化型のユースケースに対応した実装水準の方法を決定付けることが可能になる。共通性の観点から、言わば共通する諸概念を纏め上げた抽象クラスが抽出される。これに対して可変性の観点からは、当該抽象クラスの共通処理部分との「差異」に対応付けるように、特化した処理を記述すべき具象クラスが抽出される。自己論理的なオブジェクト指向のシステム合理性RUPの開発プロセスを既存の開発プロジェクトに導入する場合には、既存の開発プロジェクトとの共通性と可変性を区別できるようにしておいた方が無難だ。既存の開発プロジェクトと共通している部分については、そのまま抽象化して関連付ければ良いだろう。可変となる部分に関しては、RUPを導入した場合の個別具体的なプロセスを明確化しなければならない。関数型プログラミングが根付いている開発プロジェクトに対してRUPを導入する場合には、関数型プログラミングとオブジェクト指向プログラミングの「差異」を意識せざるを得なくなるはずだ。既存の開発プロジェクトには、既に関数型プログラミングを前提とした設計思想が普及しているかもしれない。可変のメンバ変数に対する参照すら許さないプロジェクトのアサインメンバーに対してオブジェクト指向へのパラダイム転換を要求して従事させるのは至難の業だ。この関数型プログラミングとオブジェクト指向プログラミングの差異に付随する問題に限って言えば、典型的には概念水準と仕様水準と実装水準の区別の導入をそれこそオブジェクト指向分析的に実践することによって解消できるだろう。関数型プログラミングとオブジェクト指向プログラミングの差異は、精々のところ実装水準の全般と仕様水準の一部の問題でしかないからだ。RUPの開発プロセスに従わない関数型プログラミングの担い手が実装水準を担当していたとしても、その成果物が仕様水準で指し示した公開インターフェイス仕様を満たしてさえいれば、その関数型プログラミングが有害になることはあり得ない。このことの前提にあるのは概念水準と仕様水準のアーキテクチャ設計が徹底されているということだ。アーキテクチャ中心設計によって抽出されたアーキテクチャ・ドライバは、オブジェクト指向的には概念水準と仕様水準にしか対応しない。実装水準に対応するのは、アーキテクチャ設計とは区別される詳細設計だ。アーキテクチャ・ドライバの抽出をはじめとしたアーキテクチャ中心設計をオブジェクト指向分析とオブジェクト指向設計によって実践するソフトウェア・エンジニアやアーキテクトは、あくまでも仕様水準を介した詳細設計とのブリッジを心掛けることが求められる。その仕様水準で指し示したインターフェイス仕様が守られている限りにおいて、アーキテクチャ設計者は詳細設計者に自由度を提供しなければならない。言い換えれば、オブジェクト指向設計を実践するアーキテクチャ設計の担い手は、仕様水準における「非オブジェクト指向設計的な詳細設計」や、実装水準における「非オブジェクト指向プログラミング」の担い手たちさえも許容しなければならない。これこそが、オブジェクト指向を自己論理的に適用した場合に到達する結論だ。オブジェクト指向的なアーキテクチャ設計を担当するソフトウェア・エンジニアやアーキテクトは、言わば仕様水準の詳細設計や実装水準のプログラミングという活動そのものをブラックボックス化して観察しなければならない。我々は、オブジェクト指向を徹底すればするほど、非オブジェクト指向に対してすら寛容にならなければならないのである。アーキテクチャ設計を敢行する我々にとって、例えばアラン・ケイのメッセージに耳を傾けることも、ビヨルネ・ストロヴストルップと共に『オブジェクト指向とは何か?』を論じることも、二次的な問題でしかなくなる。オブジェクト指向と非オブジェクト指向の区別をこの区別そのものに再導入(re-entry)することにより、非オブジェクト指向をもオブジェクト指向的に参照することを以って、アーキテクチャ設計のシステム合理性を確保していく必要がある。問題解決策:UMLオブジェクト指向分析やオブジェクト指向設計が広く採用されるようになったのは、1980年代からである。開発現場への普及に伴い、徐々に設計方法も多種多様となっていた。少なく見積もっても、数十の方法が混在していたという。その結果として開発現場では、伝達したい情報は同じであっても、表記法が異なるが故に混乱を招くようになっていた。して分裂状態にあった方法の中でも、とりわけ多くの開発者たちが利用していたのは、次の3つの方法に大別できる。この方法は、分析対象領域をオブジェクトモデル、動的モデル、機能モデルの3つの観点で区別する分析表現法として提唱されていてた。method)」である。この方法はUMLの特にクラス図の起源の一つとなっている。第三の方法は、イヴァー・ヤコブソンの「Objectory法」である。この方法はユーザーの要求をユースケースでモデリングしていく分析方法である。1990年代になると、これら3つの代表的な方法が統合されるようになる。1994年、ブーチが勤務していたラショナルソフトウェア社にランボーが合流したことで、まずOMTとブーチ法が統合されることになる。0.8と名付けられていた。Method」という命名には、「開発方法の統合」という理念がまだ潜んでいた。この理念は必ずしも十全に継承されていった訳ではない。実際、続く1995年にはヤコブソンがこの統合プロジェクトに参加することになった。これにより、OMT、ブーチ法、そしてObjectory法を採り入れたUML0.9が誕生した。この方法の主導的差異を構成したのは、開発プロセスと表記法の区別である。これによりオブジェクト指向分析とオブジェクト指向設計は、個別具体的な開発プロセスの規模や種類に拘らず、独立した固有の表記法を手にすることになる。UMLは開発プロセスに依存しない、表記法としての抽象性を獲得したのである。その後もUMLは順調にバージョンアップされていった。MDA)という設計思想が導入されることになる。それはモデルから実行可能なアーキテクチャを生成するという発想である。この関連からUML2.0以降、特に振る舞いや制約を表現する表記法が潤沢に配備されることになった。MDAの主導的差異を構成したのは、設計とアーキテクチャの区別である。MDAの目的はアーキテクチャから設計を解放することであった。ここでいう「設計」とは、機能要求に対応したユースケースに過ぎない。一方でアーキテクチャとは、アーキテクチャ中心設計でいうところの、品質特性要求に対応する。性能などのような、エンドユーザーにとっては潜在化している諸問題に限定される。MDAはシステム開発の自動化を夢見てきた。この思想はUML2.0にも反映されている。実際、クラス図からコードスニペットを自動生成することも、逆にプログラムからシーケンス図を自動生成することも、不可能ではなくなっている。この夢物語は、過度には賛同されなかった。MDAをサポートする兼ね合いから、UMLのツールは、多くのデータモデルやメタデータを抱え込むことになった。それ故にUMLは、それ自体として、一個のプログラミング言語と化していく。なると、UMLと実際のコードの関連は、プログラム同士の関連と等しくなることで、複合性を増大させていく。Systems)」と化す。理性的な人間の眼から観ても、このシステム複合性の全体像を理解することは困難極まりない。UMLの表記法が共通化されていたとしても、それによって表現すべき対象は、機能要求次第で可変であるためだ。したがってアーキテクトは、UMLの複合性の縮減のために、別のUMLを必要としてしまう。言った具合に、UMLは論理学的に無限後退へと陥っていく。このUMLのパラドックスを脱パラドックス化できたのは、UMLの代替案に対する認知的な期待であった。その代替案とはーーもはやモデリングですらないーー文章である。Markdownの表記法が好例であろう。箇条書きされた短い文章の集まりの方が、設計者の負担を軽減すると共に、ステークホルダーとの認識齟齬も起こり難いためである。忘れてはならないのは、UMLが設計の表記法であるということだ。それは数学的な正確性や構文検証を伴わせた形式的な表記法からは区別される。オブジェクト指向設計の多くの使い手たちは、UMLをそうした形式的な表記法としては利用していないはずだ。UMLは曖昧な表現を許容する。設計者はそれを誤用する場合もあれば、そこからディス・コミュニケーションが派生する場合もある。一方ではオブジェクト指向プログラミングの詳細設計を文書化するためにUMLを利用する設計者もいれば、他方ではシステム設計の文書化にUMLを利用する設計者もいる。この点において、UMLは非ソフトウェア構造を十分には反映させることができないため、不十分な表現に留まってしまう。UMLのユーザーは、しばしばUMLの設計思想では全く意図されてこなかった対象を表現しようとするあまりに、その表記法を歪めてしまう。UMLで描写されたアーキテクチャ設計の表現は、下流工程の設計者、実装者、そして構築に関わるステークホルダーに対して、十分な説明を与える表現ではない。単なるクラス図であっても、図で使用されている線分や箱に関して、状況に応じて凡例が必要になる場合もある。あらゆる関係者がUMLを理解できるほどの数学的または論理学的な思考力を有している訳ではない。UMLで表現していても、設計上の意思決定の根拠を説明する場合や、システムの振る舞いを描写するためには、文章による記述が必要になる。言えば、UMLには、システム開発というコミュニケーション的行為の合意形成を促す機能は全く無い。機能的等価物の探索:ツリーダイアグラム上述したように、UMLの問題は、それが設計の表記法であるが故のパラドックスである。Markdownのような文章の表記法は、脱パラドックス化の形式の一つとなり得る。確かにマークアップ言語であるMarkdownは、UMLも含めた他のオントロジーとの構造的な結合を許容するであろう。このMarkdownという問題解決策は、「オブジェクト指向設計は如何にして可能になるのか」という問題設定に対して、直接的に貢献する方法ではない。UMLの機能的等価物を探索する場合、この「オブジェクト指向設計は如何にして可能になるのか」という問題設定を前提とした上で、尚且つ「設計の表記法であるが故の問題」を回避することが求められる。ステークホルダーが「人間」である場合だ。ここでいう「人間」とは、設計の表記法と形式的な表記法を混同してしまう関係者の総称である。した「人間」は、曖昧な表現を許容するUMLをしばしば誤用することで、別の「人間」との間で、より良き合意形成を断念する。したがって、この類の「人間」を排除することによって、UMLは、設計の表記法であるが故のパラドックスから救済されることになる。言い換えれば、非「人間」的な存在Xがシステムの設計や実装を担えば、上述した「人間」的な問題は派生しない。同時に合意形成の問題も解消されるであろう。正確に言えば、ステークホルダーとなる「人間」たちによる理性的な討議は、この存在Xによる<創造>を信仰するか否かという議論へと代替されていくのである。宗教の社会構造と「生命の樹」の意味論この極端な理念には前例がある。宗教システムの社会構造と歴史的意味論を前提にすれば、この存在Xに代入されるのが「神」の概念であることは直ぐにわかる。Systems)」に匹敵するほどの複合性を宿していた。ゲルショム・ショーレムらが取り上げているユダヤ教的なグノーシス主義の秘境的な体系である「カバラ(Kabbala)」においては、唯一神の認識不可能性が焦点となっている。Sof)」として捉えた。「無限なるもの」は完全なる統一性である。それは「無限なる者」から区別されることで、非人格的な性格を際立たせている。それは「無限なる者」ではなく、あくまでも「無限なるもの」に他ならない。この「無限なるもの」としての神を語り得るには、高度な抽象化が必要になる。ha-Shorashim)」などと表現する場合もある。この抽象化は、あくまでも神を認識不可能な存在Xとして語る場合にのみ機能する。した存在Xは、有(Yesh)でもなければ無(Ain)でもない。「無限なるもの」の中では、如何なる変化も起こらない。故に、神に対して区別を導入することは不可能である。「無限」としての神には限界も際限も無いために、その外部には何も存在しない。神とその外部を区別することは不可能である。これはパラドックスである。神は、唯一神でありながらも、その内部に無限の複数性を宿しているからだ。これは、エンドユーザーから観れば一個のシステムであるように思えても、その内部には無数のサブシステムが構成されているアーキテクチャと、論理的には類似している。アーキテクトならば、この複合性の縮減のために、UMLのような表記法に頼ることになる。同様にカバラ主義者たちの間でも、ある表記法が慣れ親しまれている。haChayim)」である。生命の樹は、神や宇宙に関する思弁的神秘主義の中心的な特徴を成している。Sephiroth)」の体系と共に記述される傾向が強い。セフィロートは、生命の樹の構成要素を成している。カバラ主義者は、このセフィロートをメディアとすることで、神の区別の形式を導入することを可能にした。この背景にあるのは、唯一神の唯一性に内在する複数性にこそ世界の法則が潜在化しているという、カバラ主義者たちに内面化している宇宙の設計思想である。唯一神は10のセフィロートの概念で構成されている。このセフィロートの体系は神の多様な性格を有していると共に、聖性の階層構造によって秩序付けられている。天上に近い上位のセフィラーは、地上に近い下位のセフィラーよりも聖性が高い。中央よりも右側に位置するほど、その神は慈悲深くなる。逆に左側に位置する神ほど、厳格さを備えていると言われている。この左右の差異は、世界の対立や矛盾を表現しているという。したセフィラー(Sephirah)という用語は、「数える(mispar)」という意味のヘブライ語から派生した概念であると言われている。Yetzirah)』では、神の創造を説明する上で、この概念が叙述されていた。『形成の書』は神がアブラハムに語った内容であると言われている。この伝説の真偽はともかくとしても、この書物の主題は神と人間の物語ではない。そこで描かられているのは、神の創造における、ヘブライ文字や数字のような抽象的な概念と天体や自然現象の関係である。その記述は『旧約聖書』の内容とは異質な抽象論となっている。それによれば、世界は10のセフィロートと22のヘブライ語のアルファベットの組み合わせから構成されたという。世界が数字によって構成されているという発想は、何処かピタゴラス学派の音楽論を連想させる。『形成の書』では、個々のセフィラーが具体的に何を表すのかについても、それが如何にして生成され得たのかも、説明されていない。した個別具体的な定義は、後のカバラ主義者たちの解釈に委ねられていた。重要なのは、無限で際限の無いように思える存在Xであっても、「10」で数えることが可能であるという点である。認識不可能であるとされた対象であっても、定量的な区別の形式を導入することが可能なのである。diagram)」の概念史を遡れば、この概念が必ずしも神の構成要素を叙述してきた訳ではないということも、直ぐにわかるであろう。『旧約聖書』の「創世記」には、アダムの家系が延々と叙述されている。家系図は、血縁関係を可視化する生命の樹の一種であると考えられる。生命の樹という概念は、決してユダヤ教に限定される訳ではなく、キリスト教やギリシャ神話とも縁を持っている。Gentilium)』で、ギリシャ・ローマ神話で語られるデミウルゴスの子孫たちの系図の図版を掲載している。14世紀の時代背景を念頭に置けば、この系図は、複合性の高い概念のモデリングとしては稀有な例であった。diagrams)が主流であったためだ。ダイアグラムで可視化されていたのは、星々の運行やその位置関係であった。幾何学的な発想そのものは、古代エジプトの測量士たちの活動に由来している。今でこそ知り渡っている緯度と経度の区別は、古代ローマの学者であり天動説の支持者でもあったクラウディオス・プトレマイオスによって導入された。projection)は、ここから派生している。その後も14世紀までは、この物理学的な観測方法が、地図の標準的なデータビジュアライゼーション法として利用され続けていた。その後の数世紀の間も、モデリングの方法は専ら物理学的なダイアグラムとして発明され続けた。立て続けに地理情報に関する物理学的な測定方法が主題となるのは、領土侵攻という当時の政治的な都合も絡んでいる。16世紀には展望台や三角測量法などが発明され、17世紀には解析学や統計学のような近代科学の発展が大きな貢献をもたらした。18世紀から19世紀前半には、地理情報の可視化方法が、等高線や等高線などによって洗練されていった。棒グラフや円グラフ、ヒストグラムや散布図など、データビジュアライゼーションの主要な表現方法が定着し始めたのも、この時期からである。した方法は地理情報や気象情報のみならず、様々な物理現象を視覚的に理解する上でも用いられるようになった。19世紀中盤から19世紀末の間には、統計学者たちが磨いてきた統計手法が、この可視化の方法論に合流することになる。様々な統計量が様々なグラフィックによって直感的に把握できるようになったのである。この関連から、ツリーダイアグラムの可視化方法も、科学サイドに導入されるようになる。ダーウィンの生物学的な進化論が提唱されて以来、科学的な分析結果もツリーダイアグラムによる可視化の対象となり始めた。実際、動物学者エルンスト・ヘッケルは、全生物の系統樹を生命の樹の如く描いている。そこには、生物の系統関係に基づく壮大な体系が系統樹という一つの体系として叙述されている。ダーウィンの生物学的な進化論がキリスト教的な創造論との対立を生じさせたとすれば、ヘッケルの可視化は、宗教サイドのツリーダイアグラムの偶発性を顕在化させることになった。今やツリーダイアグラムは、神の世界の表記法としてだけではなく、脱魔術化された近代科学の業績をも表現しているのである。ツリーとセミラティスの差異しかしこの対立が指し示しているのは、ツリーダイアグラムという概念が、宗教サイドにも科学サイドにも囚われないほどの抽象性を獲得しているということである。この概念の抽象性を十分に活かすためには、それが「ツリー」的であることの必然性を疑わなければならない。この関連からもう一度我々は、アレグザンダーが導入した「ツリー」と「セミラティス」の区別を観察することになる。実際現代のグラフ理論的な統計学や離散数学の間では、むしろセミラティスの方が、ダイアグラムの形態を巧く叙述しているのである。relation)を把握しておかなければならない。set)の差異である。擬順序は、反射律(reflexivity)と推移律(transitivity)を同時に満たす二項関係を表す。半順序は反射律と推移律と反対称律(antisymmetry)を同時に満たす二項関係を表す。比較可能律(comparability)を同時に満たす二項関係を表す。zにおける二項関係をRとした場合を想定している。反射律は$$xRx$$が成り立つ場合を指す。推移律は$$xRy$$かつ$$yRz$$ならば$$xRz$$を満たす場合を指す。y$$となる場合を指す。比較可能律は、$$xRy$$または$$yRx$$が成り立つ場合を指す。ダイアグラムにおいては、隣接している二つの要素の関連が重要となる場合が多い。relation)」として定義されている。zRy$$が成立しない場合である。したがって、ある二項関係Rを前提とした被覆関連は、他の要素を介在させず、純粋に非冗長的かつ直接的な関連を意味する。この時、xとyは特に$$x^{*}Ry$$と表記される。diagram)」となる。ハッセ図は、特定の順序関係に関して、その有限順序集合を可視化する方法として知られている。順序集合は順序関係の集合である。set)は反射律と推移律で構成されている。これらの条件だけでは、全体としては緩い順序関係が形成されることになる。\}$$とした場合、この集合内で成立する擬順序は以下のようになると仮定する。yRc$$は、それぞれ被覆関係を満たさない。したがってハッセ図として作画されるべき要素は、被覆関係を満たす次の二項関係のみとなる。pRt$$擬順序集合から導かれるハッセ図では、反対称律を満たさなくも良い。y$$でも構わないということになる。relation)」という。set)では、反対称律を満たさなければならないため、同値類は形成されない。同値類は、擬順序集合に固有の特徴である。これに対し、擬順序集合と半順序集合の共通点は、比較可能律が必ずしも満たされていないということである。半順序集合をハッセ図で表した場合、そこには相互に関連の無い複数のグラフが構成されることになる。set)は、半順序集合の条件に加えて比較可能律も満たされている。そのため半順序集合とは異なり、全順序集合のハッセ図では一列のグラフが形成される。擬順序集合が緩やかな条件付けによって構成されているのに対して、全順序集合は緊密な条件付けによって構成されている。この中間にあるのが半順序集合である。bound)の区別を導入しなければならない。この差異は集合の特徴を表す。yRz\}$$である。wRy\}$$である。semilattice)」、そして「束(lattice)」の区別を導入することが可能になる。y)$$が含まれている半順序集合は上半束の集合となる。y)$$が含まれている半順序集合は下半束の集合となる。y)$$が共に含まれている半順序集合は束の集合となる。element)が一意に定まる。element)が一意に定まる。グラフである全順序集合のハッセ図では、生命の樹のように、無数に枝分かれしていく複数のノードを表現することはできない。擬順序集合が可能にする同値類の表現が必要とはならないのであれば、ツリーダイアグラムの表記法として最適なのは、半順序集合である。上限と下限の区別を導入すれば、様々なツリーダイアグラムの表現が可能になる。上半束の半順序集合から作画したハッセ図を有向グラフとして活用するなら、様々な因果関係が最終的に何の要素に帰結しているのかを可視化することが可能になる。逆に下半束の半順序集合を利用するなら、その有向グラフは、逆に発端となる最初の原因ーー「原因の原因」ーーを可視化することを可能にする。semilattice)の差異の共通項となるセミラティス(semilattice)である。先に我々は、アレグザンダーの観察の観察により、ツリーとセミラティスの区別が、セミラティス構造のツリー化というパラドックスを招いていることを確認した。この区別は、人為と自然の区別に対応している。セミラティス構造のツリー化というパラドックスは、<自然の人為性>というパラドックスと論理的に等価である。これに対して上述したグラフ理論や離散数学は、このパラドックスを「展開」することで、ツリーダイアグラムがセミラティス構造を具象化した一種に過ぎないということを記述している。ツリー化したグラフ構造を汎化していけば、それはセミラティスの構造になり得るのである。したがってツリーダイアグラムの観察者は、一見ツリーとして固定化している構造であっても、一旦セミラティスとして抽象化することによって、別のあり方でもあり得る具象的なツリー構造の可能性を探索することも可能になる。擬順序と半順序と全順序の区別、上半束と下半束と束の区別、そしてツリーとセミラティスの区別は、様々な諸要素の諸関連ーー諸関連の諸関連ーーを形式化させるメディアとして機能する。この形式化は、関連するノードの集合と各ノード間のエッジの属性となる二項関係の条件付けをそれぞれパラメタとして受け付けることで、自動化させることが可能になる。以ってこのグラフの構造化は、概念クラス図や詳細クラス図の機能的等価物となり得る。関連の誘導可能性は、エッジで表現することになる。クラスの階層構造は、上半束の構造で表現できる。この構造において、最上位のスーパークラスは全ての上界の最大元となる。下半束の構造は、どちらかと言えばコミュニケーション図やシーケンス図、あるいはコンポーネント図の機能的等価物となろう。この場合、最小元のノードに対応する関数が、エントリーポイントとなる。各エッジは、ここから呼び出される処理を流れを指し示す訳だ。クラス図のメソッド名やシーケンス図のインスタンス名などのようなデータは、グラフ構造では可視化され得ない。ここで重要なのは、非「人間」的な設計者を仮定した場合である。その存在Xが人工知能のような人工物であれば、各ノードが有するメソッドやプロパティのようなデータは、メタデータとして保持されることになるであろう。このように、二項関係という単純な条件付けから、オブジェクト指向分析やオブジェクト指向設計の担い手となる「人間」の機能的等価物としての人工知能を設計することが可能になる。ここまで来れば、これらのみならずオブジェクト指向プログラミングに関しても、自動化したいという欲求に駆られるかもしれない。「人間」のプログラマの傾向から考えてもわかるように、今やプログラミングの大部分は、ライブラリやAPIの機能的な再利用によって成り立っている。その多くは、GitHubのコミットログとして保存されている。したがって、オブジェクト指向プログラミングの自動化としてまず実現するべきなのは、ライブラリやAPIの機能的な再利用の自動化である。この問題解決策となるのは、Webクローラと自然言語処理である。言うのも、大多数のライブラリやAPIは、Sphinxをはじめとした文書の自動生成ツールによって生み出されているからである。した文書は、コードとそのコメントから構成されている。プログラマは、コメントを予め所定の表記法で記述することで、文書化する対象を操作することができている。して生成された文書は、全てWeb上で公開されている。Webクローラによる観察は容易い。各Webページの階層構造は、各クラスの概念的な階層構造やパスの構造に対応している。あるサブクラスのWebページには、そのスーパークラスのWebページへのハイパーリンクが貼られている。各Webページには、メソッドの引数や返り値の型、あるいはプロパティの有無などが詳述されている。した文書をWebスクレイピングの対象とすれば、既存のライブラリやAPIにおける、そのツリー構造やセミラティス構造を抽出することが可能になる。problem)」を解くだけである。「オブジェクト指向設計で構成したツリーダイアグラムの構造」と「既存のAPIやライブラリの論理構造」の差異を最小化する組み合わせを探索する訳だ。周知のように、組み合わせ最適化は困難極まりない問題設定である。サイモンのように、最適化と満足化の区別を導入することは、ここでも有益となる。最適解は不可能でも、満足解であれば、強化学習でパラメタ化することが可能になる。その際、どの既存のAPIやライブラリを利用するかという選択問題は、一種の確率的バンディット問題として設定できるであろう。この場合により一層難易度を上げてしまうのは、「既存のAPIやライブラリの論理構造で参照されている諸概念」と「オブジェクト指向設計で構成したツリーダイアグラムで参照している諸概念」との間の、距離計算である。キーワードのマッチ率程度の類似性計算アルゴリズムでは、勿論全く通用しない。同じ概念であっても、文書の生成者次第では、異なる用語で記述されている場合もある。それ故に、深層学習による汎化性能を備えた自然言語処理が必要不可欠となる。以上の記述は、このWebサイトの概念実証の中でも、とりわけ未来志向的な思弁で留まっているように視えるかもしれない。これらの観察は、このWebサイトにおける概念実証の公理、定理、定式を前提とすれば、十分演繹可能な結論となっている。おける天才物理学者たちの神学的な形象について』、『Webクローラ型人工知能によるパラドックス探索暴露機能の社会進化論』、および『深層強化学習のベイズ主義的な情報探索に駆動された自然言語処理の意味論』において、詳細に解説しておいた。上述した人工知能が実装された時、「人間」の設計者と実装者の大半は不要となる。既存の概念を実装する場合であれば、上述した人工知能により、全てが自動的に開発されていく。「人間」が必要となるのは、未だWeb上に蓄積されていない全く新しい概念を設計して実装する場合のみである。した「人間」を、ここでは<創造的>な「人間」と名付けておこう。現存するエンジニアの全てが、全く新しい概念を設計して実装するほどの知識やスキルを有している<創造的>な「人間」であるとは限らない。既存のAPIやライブラリを使い回すことしかできないエンジニアは、職を失うことになったとしても不思議ではない。なると、「人間とは何か」などといった哲学者たちが好みそうな派生問題に付き合わざるを得なくなるであろう。これが瑣末な問題に過ぎないという観点を確かめたい読者は、次のページに進むよりも、『ヴァーチャルリアリティにおける動物的身体の物神崇拝的なユースケース』をご覧いただくことを推奨する。