もどる
  1. オブジェクト指向とシステム設計

     『諸学問がお互いに他を区別するアイデンティティは、それがメタフォリカルな類推によって結びあわされていることをおおいかくしている』(柄谷行人 注1)

     例えばサファリパークで生き物を管理しなければならないとします。さしあたってサル・イルカ・ライオン・バラクーダ(カマス)・キリン・バタフライフィッシュ(蝶々魚)をグループ分けします。

     このようにグループ分けすることもできます。また少し博学な人なら、

    このようなグループ分けをするかもしれません。
     でもこのようなグループ分けでは”海水に有害物質が混入したので影響のある動物を知りたい”といった質問には即答できません。動物の”類(るい)”というのは、体の機能・構造の側面から分類したものであり、生活している環境は考慮していません。
     ここにオブジェクト指向設計の落とし穴があります。システムで実現したいことと関係なくオブジェクトの抽象化を行ったのでは何のメリットもありません。よく、他人の作成したクラスライブラリを利用することにより生産性があがるということを耳にします。しかし、サファリパークに動物の”類”クラスライブラリを持ち込んでも良いものができるとは思いません。むしろ、その様な予備知識(既成概念)を捨てて、漁師さんなど生活で生き物と密着に関っている人の意見を聞きたいものです(私のようにスキューバ・ダイビングを行っているものにはバタフライフィッシュとイルカを同じグループにすることに何の違和感もありません。学校で理科の授業を受けなければ、イルカをキリンを同じグループにするなんて大笑いするしかなかったでしょう)。
     蛇足ですが、上述のグループ分けの2例は”事典(エンサイクロペディア)”と”辞典(ディクショナリ)”という区分で表わされることもあります。小さいころ読んだ『海辺の生き物図鑑』といったものはエンサイクロペディアに近く、『魚類図鑑』というのはディクショナリに近いのかもしれません。システム設計に必要なのは『海辺の生き物図鑑』的なオブジェクト設計であり(注2)、”海辺の生き物”として何を盛り込むかが編集者(システム設計者)の腕の見せどころです。
     要求仕様からオブジェクトを抽出さえすれば、抽象モデルが”常識的に”できあがるという錯覚にとらわれがちですが、我々の常識というものはともすると辞典的に体系化されているものであり、その体系で出来上がったシステムはやっぱり実情に即した変更に弱い、ということになります。この悩みはコンピュータ屋に限ったものではないらしく、養老猛司氏は解剖学用語集と人体構造との乖離を指摘しています(注3)。
     オブジェクト指向分析はもっと”抽象化”を焦点に議論されるべきです。辞典的に体系化されたオブジェクトモデルはシステムに要求される重要な事象を包み隠してしまうかもしれません。
     オブジェクトモデルの内包している”重要な事象”については次の章にて触れたいと思います。

  2. オブジェクトであるということ

     『すべての概念は等しからざるものを等置することによって発生する』(ニーチェ)

     核心から述べます。
    「オブジェクトはアプリオリに”ある”のではなく、示差的(ディファレンシャル)な関係において”ある”ものである。オブジェクトが現実の世界を表現しているというのは幻想である。現実の世界の差異性がオブジェクトを産み出しているのである。オブジェクトはそれ単体では存在し得ないのである。
     少しハショリすぎました。
    ”じゃんけん”を考えてみましょう。グー・チョキ・パーには以下の関係があります。

     この三すくみの関係ではグーが無ければチョキやパーの存在意味はありません。グーやチョキやパーというオブジェクトに意味があるのではなく、「三すくみ」という制度において意味があるのです。くりかえします。グー・チョキ・パーがあるから三すくみという制度ができたのではなく、三すくみによってグー・チョキ・パーに意味ができたのです。
     前章において、オブジェクトモデルの内包している”重要な事象”というキーワードを出しました。要求仕様からオブジェクトモデルを作成するにあたって大切なことはオブジェクトを切り出すことではなく、制度(事象)を見つけだすことです。それがオブジェクト指向分析・設計に与えられた使命である「抽象化」という仕事なのです。

     ここまで来るとオブジェクト指向という言葉に違和感が出てきます。いま求めているのは「オブジェクトという対象を極度に抽象化して、最後には、オブジェクトをも捨象して、残った強固な枠(フレームワーク)を大切にすること」(注4)であり、オブジェクトは何も残りません。構造主義、フレームワーク指向とでも呼びたくなります。
     ここでゴマカシてきたことを少しはっきりさせなくてはなりません。分析と設計のスタンスです。
     抽象化を極限まで行うのは分析の姿勢です。諸々のしがらみを削りとってフレームワーク(制度)を日の下にさらす。この行為は学問・職業を越えて普遍です。別にコンピュータシステムにこだわる必要はありません。事実、文化人類学などではフィールドワークで得た人間関係から様々な抽象化を行い、研究対象の社会制度のフレームワークを掘り起こします。
     コンピュータシステムに関する技術が必要なのは”強固なフレームワーク”をコンピュータに実装しなければならないときです(注5)。
     このときに削ぎ落としてきた諸々のオブジェクトがメモリ・ファイル・プロセスに姿を変えて具象化されます。これはコンピュータシステム設計のアプローチです。フレームワークを変えることなく、削ぎ落とした”非コンピュータ的なもの”を”コンピュータ的なもの”として実装するのがコンピュータに携わる者の仕事です。こうしてコンピュータ上に具象化されたオブジェクトは、ある時は技術的問題から、ある時は現実の世界の制度の変化から、また新たなフレームワークを要求します。ちょうど「クラインの壺」のようにオブジェクトは抽象と具象を行ったり来たりしながらシステムを現実の世界に近づけます。資本というものがある時は”お金”、ある時は”品物”というものに形をかえながら「資本主義」が成立しているのによく似ています。
     もちろん先ほどの三すくみのようにフレームワークを抽出した対象とフレームワークに肉付けを行う対象は同じものとは限りません(注6)。同様に、オブジェクトを具象化する場所はコンピュータだけとも限りません(注7)。

  3. 抽象化に関する補足(分類という思想)

     ”抽象化”というと何かかまえてしまいますが、以下の例を考えれば当たり前すぎていやになります。
     例えば地図。建物を記号化し、実際の道路の大きさをデフォルメした抽象モデル。チラシを見れば、住宅の見取り図。空間を平面に表わす苦労の賜物です。抽象化の賜物といえば「さんすう」。この世の中に”直線”や”まる”や”しかく”が無い、というとちょっとビックリしますが(注8)、抽象化するというのはごく普通の精神活動であることを強調しておきます。
     さて、それでは実際に抽象化を行うとしましょう。抽象化のためにはモノ事の分類が必要です。冒頭の例ではサル・イルカ・ライオン・バラクーダ(カマス)・キリン・バタフライフィッシュ(蝶々魚)を飼育しやすいようにグループ分けができないかという話でした。ここで重要なのは、「人間の認知パタンから自由である限り、すべての対象は同じ位似ている。太陽も金魚も人間も石ころも同じ位似ている」(注9)ということです。分類する人の世界観や思想なくしてモノ事を分類することはできないのです。これはアヒルの子も白鳥の子も客観的に(思想なくして)は同じくらい白鳥に似ているということから”みにくいあひるの子定理”として渡辺慧氏によって厳密に証明されています。
     ちょっとその定理をのぞいてみましょうか。

    種別水棲哺乳類
    ゴキブリNoNo
    ライオンNoYes
    バラクーダYesNo
    イルカYesYes

     今、このように2つの観点からみてみました。この場合、水棲という観点ではバラクーダとイルカは似ています。この観点ではゴキブリとライオンは似ていません(注10)。
     さてこの2つの観点からいくつかの性質が自動的に導かれます。すなわち「水棲でありかつ哺乳類である」・「水棲であるまたは哺乳類である」...といった具合です。これを全て作図すると以下のようになります。

     先程のゴキブリ・ライオン・バラクーダ・イルカをこの分類に当てはめると下表になります(表中、* はその性質を持っていることを示す)。

    パターン12345678910111213141516
    ゴキブリ        
    ライオン        
    バラクーダ        
    イルカ        

     「同じ性質を持っている」=「似ている」 と考えると、どれだけ同じ位置に * がたっているかが、「似ている」ことの判断ポイントになるといえます。
     しかし、この表をよく見るとどの組み合わせも同じ位置に * がたっているのは4ヶ所であることが分かります。どの組み合わせも、等しく「似ている」のです。
     私の感覚では「ゴキブリ・ライオン」グループと「バラクーダ・イルカ」グループに分類したくなるのですが、これは客観的な分類ではなく(客観的にはどれも同じだけ近しい)、(ちょっとオーバーな表現ですが)私の思想によるものなのです。
     客観的な(あるいは自動的な)分類ができないという証明は、「オブジェクトの抽象化(クラス化)なんて、常識的な分析で行えばよい」といった甘い考えを打ち砕きます。この技術は分析・設計者のポリシーを良くも悪くもムキダシにします。やるからにはそれなりの覚悟がいるのです。
     オブジェクト指向分析・設計は人の考え方にむりのないアプローチであるといいますが、人の考え方に近いからこそ、より曖昧な問題へとエンジニアを引きずりこみます。

  4. オブジェクト指向技術のキーワード

    『作業規定を信じろ、最後にはきっとうまくいく』-注11

     そろそろ具体論に入りましょう。あっ、その前にオブジェクト指向技術で一般に用いられている言葉は本稿でも使用したいので、私の認識を交えて紹介します。

    ・ポリモーフィズム
     ポリモーフィズムとは多様性、多相性、多義性というような和訳で表現されています。実際には多くの事象をひとまとめに取り扱うことを表現した言葉です。
     オブジェクト指向的に表現すると、『一つのメッセージに多くの異なるオブジェクトが答えられること』となります。
     たとえば(たまたまの思いつきですが)、トイレにあるウォシュレットの『止まる』ボタンがいい例です(注12)。
     このボタンひとつで
    ・ノズルから水(お湯?)を出している時は、『水を止める』
    ・ファンで送風している時は、『送風を止める』
    ・ノズルもファンも動作していないときは、『何もしない』
    という動作を行えます。これがポリモーフィズムです。水を止めたい時はツマミをひねり、ファンを止めたい時はスイッチを押すというのでは慣れるのに時間を要します。『止まる』ボタンでどちらも扱えるから良いのです。
     私はオブジェクト指向の最大の利点はこのポリモーフィズムであると考えます。ポリモーフィズムが無いのならオブジェクト指向開発なんていらないと思います。もっと極論すると、後述する『抽象データ型』も『インヘリタンス』もポリモーフィズムを実現させるための一手段であると考えています。

    ・抽象データ型
     抽象データ型とは、『データとそれに対する手続きを一体化しデータへのアクセスは決められた手続きのみによって行う』という仕組みのことです。
     データと手続きを一体化させることをカプセル化(encapsulation)と呼び、決められた手続き以外にはデータを扱うことができないことを情報隠蔽(information hiding)と呼びます。
     つまり、あるデータの値を変えたい場合、直接変えることは許されず、そのデータを変えることの許されている手続き(メッセージ)を呼ぶ必要があるのです。これはちょっと面倒くさそうです。しかし、異なるデータへのアクセスのための手続き名を同一にすることにより、ポリモーフィズムの恩恵を授かれる利点もあるのです。ウォシュレットの例では、水を止める方法もファンを止める方法も知らないけれども、とにかく『止める』というボタンを押せば(メッセージを出せば)、水もファンも止まってくれるのです。カプセル化されていない場合は、それぞれ別の方法で直接止めるしかなかったのです。
     ちょっとオブジェクトしたくなったと思います。
     しかし、注意すると【カプセル化=ポリモーフィズムの実現】という図式にはならないことに気付きます。手続きごとに名前を全て変えてしまえばポリモーフィズムは発生しません。水を止めたい時は『水止まる』ボタン、ファンを止めたいときには『ファン止まる』ボタンを押すという設計だってできます。ツマミやスイッチを使い分けていた頃とどう違うのでしょう?
     これは案外重要な問題を提起しています。つまりオブジェクト指向技術というのは仕組み(facility)であり(注13)、これを利用する人の思想(policy)によって良くも悪くもなるものなのです(注14)。システムエンジニアはもっと思想的な鍛練が必要です。実は前章までで強調してきたことは、このことだったのです。

    ・インヘリタンス
     インヘリタンスとは属性や機能を別のものから受け継ぐことです。コンピュータシステムに限定した場合、属性とはデータ構造やその状態のことを指し、機能とはそのデータを扱う手続きのことを指します。複数の抽象データ型を、属性や機能を決定しているもの(スーパクラス)と受け継ぐもの(サブクラス)の関係構造で表現すると、実態に近似したモデルが出来上がるという考え方が土台となっています。
     この関係構造での表現は多くのことを語っていますが、インヘリタンスを用いればスーパクラスの機能を黙っていても使えるというのが何とも魅力的です。スーパクラスが『止まる』に関する手続きを定義を定義していれば、サブクラスでも『止まる』機能を享受できるのです。これもポリモーフィズムの一種と考えます(注15)。

     以上、多少強引ではありますが、オブジェクト指向技術の3つのキーワードを『抽象データ型とインヘリタンスはポリモーフィズムを実現させるための仕組みである』という仮説(注16)のもとで説明させていただきました。

  5. Boochいわく(オブジェクト指向分析・設計の視点)

     本稿はオブジェクト指向分析・設計技法のマニュアルではありません(注17)。よってここでは技法についてはほとんど触れません。いきなりオイシイとこ取りして、アカデミックな風にふれてみましょう。意外とドキッとするようなホンネも垣間見られます。

     Booch法はAda言語のためにまとめられた手法をオブジェクト指向分析・設計へ発展させたものです。システム設計にウェイトを置いており、「この図の表記がこのC++ヘッダの表記となる」というように、まるで図形コンパイラの仕様書を見ているような記述をしています。Booch法の問題領域への視点というのは、
    @論理的視点
    A物理的視点
    B動的な視点
    の3つであり、それぞれ@オブジェクト図・クラス図、Aモジュール図・プロセス図、B状態遷移図・タイミング図という表記法を提案しています。
     またプロジェクト管理にも首を突っ込んでいて、分析段階でのプロトタイピングによる問題領域のシミュレーションとスパイラルアップモデルによる段階的システムリリースを提案しています。
     分析段階でのプロトタイピングは、オブジェクト指向の特徴である分析段階での「問題領域の抽象的把握」を助長するものであり、スパイラルアップモデルは「イチかバチか」といったシステム開発のリスクを分散し、かつ環境の変化に柔軟であるといった特徴があります。私はオブジェクト指向を採用する・しないに関らず、またコンピュータシステム開発である・ないに関らず、プロトタイピング&スパイラルアップモデルによるプロジェクトの進め方はプロジェクトを”ポシャらせない”ために有効であると考えます。
     Booch liteの表記法については『C MAGAZINE』1993年1月号・2月号に詳しい解説が出ていますので割愛します。ここではBoochの論文(注18)から彼の思想のエッセンスを抽出しましょう。

    「工学とは科学であり芸術です。」
    「オブジェクトとは触れることができる、見ることができるものです。あるいは知的に把握されるものです。」
     要するに、人間の活動(精神・肉体)領域のすべてを含んでいるということです。
    「オブジェクトには状態・振る舞い・特性があります。」
     彼はこう言います。”赤はオブジェクトではありません。それは状態を持たないから。数字の5はオブジェクトではありません。振る舞いが無いから。ただしオブジェクトの振る舞いにはなりえます(例:在庫が5個になる)。霧はオブジェクトではありません。特性がないから。ただし、抽象化の度合によってはオブジェクトになりえます(例:ロンドンの霧・サンフランシスコの霧)”
     特性については補足が必要です。2章の冒頭でふれたように重要なのは、オブジェクトはアプリオリに”ある”のではなく、示差的な関係において”ある”ということです。この”示差的な関係”によって生まれるのが特性です。霧は、雲に対する霧とか、ロンドンの霧に対するサンフランシスコの霧という示差的な関係によってオブジェクトとなりえるということです。
    「”完全な”クラス設計はありえない」
     オブジェクト指向分析・設計について様々な論文が出ているのはこのためです。完全な解が得られれば、そこで完結してしまいます。正解がない、あるいはあらゆる可能性を秘めている点に芸術性の入る余地があります。しかしエンジニアである以上、少しでも余地を埋める努力が必要です。
    「オブジェクト指向の測定方法は以下の要素を含みます−アーキテクチャの安定性・クラスの数・クラスに含まれるメソッドの数・継承の深さ・サブクラスの数・メッセージパッシングに対するレスポンス性能・メソッドの集約(ポリモーフィズムの効率)性。」
     システムの失敗はある程度客観的に分析できます(例:モデル設計の失敗−クラス数が膨大、実装の失敗−ファイルアクセスが膨大)。オブジェクト指向分析・設計技法は表記法が重視されすぎた機来がありますが、当方では開発事例を増やすとともにこれらの数値についても統計を取り、客観的な品質評価を行っていきます。

     Booch氏はオブジェクトになりえるものやオブジェクトとして定義してはならないものについて上述のように至極簡単に述べています。しかしオブジェクトをどう抽象化すべきかについては明解な回答を与えてくれません。
     理由は簡単です。3章で述べたように、抽象化のための分類技法を客観的に確立しようとすればするほど中味がカラッポになってしまい抽象化できなくなってしまうからです。
     ごくごく常識的な範疇で抽象化しなさい、と言うに止めておかなければそれから先には進めません。土台は意外にいいかげんなものです。”いいかげん”であるということを念頭においてトライ&エラーを積み重ねていくのがオブジェクト指向との正しいつきあい方なのかもしれません。

  6. あとがき

     このようなゴキブリ退治キット(注19)が売られていたら、あなたは買いますか?

    「A台にゴキブリをのせることができたら苦労しないわい!」とツッコミたくなりますが、ことコンピュータ開発に至っては、このような宣伝文句がまかり通ります。

    「このツールはオブジェクト指向環境を実現できます。」
    (実現はするけどねぇ...)
    「オブジェクト指向開発は、生産性・再利用性を格段に高めます。」
    (ただし、あなたが生産性・再利用性を高める工夫をすればの話)
    「プログラムを書いている時代ではありません。このツールが自動的に生成します。」
    (確かに、ゴキブリを手で叩きつぶす時代ではないかも。機械が自動的につぶしてくれるとして、どうやってのせるの?)

     筆者はナマケモノなため、システム開発が楽になるならばと、このような宣伝文句に何度も飛び付きました。そのうちゴキブリ退治キットがゴキブリを見つけてくれるようになるさ、とも考えました。しかし”みにくいあひるの子定理”を知るに至って、システム開発の無人化という、ナマケモノにとってバラ色の世界が遠いことを痛感しました。
     このような目でみると、オブジェクト指向技術というのは”いままでのものよりは壊れにくいゴキブリ退治キット”のように思えます。もうしばらくは、頭を使ってゴキブリを追っかける日々が続きそうです。

    【注記】
    1 『マルクスその可能性の中心』(講談社学術文庫)
    2 「進化論」のように辞典が有用な場合もあります。しかし、これは辞典が事典的に使用されているに過ぎません。
    3 「新科学対話」(月刊アスキー1994年1月号)
    4 青木淳 著『オブジクト指向システム分析設計入門』(SRCハンドブック)
    5 スタンドアローン・サーバ/クライアント、パソコン・ワークステーションなどの形態、形式にこだわらずコンピュータシステム全般をさす。
    6 当該社会の歪みをフレームワークとして取り出し、SFや童話として肉付けすることによって生まれた秀作は少なくない。
    7 将棋も封建的な組織が抽象化され、戦略(ルール)というフレームワークと、駒という形(オブジェクト)で将棋盤の上に具象化されたというのは詭弁ですか?
    8 「てん」も拡大すれば「えん」ですよね。「せん」も結局のところ、この世の中では、極細の「めん」です。もっと厳密にいうと、この世の中には立体以外のものはありません。「てん」や「せん」をひねりだして、その規則性(法則、フレームワーク)を抽出するとは、ヒトの抽象力もなかなかなもんです。
    9 『分類という思想』(池田清彦著 新潮選書)
    10 両者ともNoだから同類だという論理は成り立ちません。それは「黄色も水色も赤色じゃないから同じ」と言っている様なものです。これはよくゴッチャになってしまうので注意して下さい。
    11 『ピープル・ウェア』(Tom DeMarco・Timothy Lister著 日経BP社)
    12 NTTデータ本社のトイレにあるものを参考にしました。筆者のオフィスにはウォシュレットがありません。
    13 オブジェクト指向CASEツールの中には思想を含んだものもあります。その思想性ゆえ、熱心な信者を生んだりします。
    14 オブジェクト指向技術に限ったことではありません。
    15 これをポリモーフィズムと呼ぶのは強引かもしれません。本書では異なるクラスが同一メッセージに呼応する事象すべてをポリモーフィズムと呼んでいる、くらいに考えてください。
    16 それぞれのキーワードを別々に理解しても得ることは少ないので、なぜそれが必要なのかを、強引な仮説(我説?)をもとに展開してみました。これは説明のしやすさのために用いた仮説であり、もっと説明し易いものを思いついたらアッサリ変えてしまいます。まぁ、そんなものです。
    17 オブジェクト指向プログラミングの一つのマニュアルとしてはC++に関して執筆中であり、そちらでテクニックに関する議論を展開したい。
    18 『OBJECT-ORIENTED ANALYSIS AND DESIGN』(Grady Booch・Rational社・1993)
    19 『要求仕様の探検学−設計に先立つ品質の作り込み』(D.C.ゴース G.M.ワインバーグ・共立出版)

禁 無断転載 (C)1997 宮川 清嗣