ObjectSquare [2007 年 12 月号]

ROOTS

-オブジェクト指向再発見-

「抽象化」の再発見(前編)

(株)オージス総研 組み込みソリューション部

田中 恒


1 はじめに

はじめに宣伝です。 オブジェクト倶楽部様主催の「クリスマスイベント 2007」でオブジェクトの広場が講演します。 『OO 厨厨トレイン(仮)』というよく分からないタイトル(^^;)が付いていますが、テーマはオブジェクト指向再発見、故きを温ねて新しきを知ろうという企画です。 どうぞ皆様、気楽にご参加ください。

ということで、この記事(もしかしたら連載?)はイベント連動の企画です。 筆者なりにオブジェクト指向を再発見していきます。

※なお、この記事の内容はイベントの講演内容とはいっさい関係ありません。

2 「抽象化」の再発見

この記事では、再発見するテーマに「抽象化」を選びました。 なぜこのテーマを選んだかというと、ただただ筆者の個人的な理由からです。 最近、あるきっかけから人の認知について興味を持つようになったのですが、そこから抽象(もしくは、抽象化)について考えるようになりました。 ところで、オブジェクト指向でも抽象化という言葉が使われますよね。 筆者はモデリングが好きなのですが、それを人に説明するとき「抽象化するんだよ」なんて言ったりしていました。 では、OO での抽象化って何なのでしょうか? 本当のことを言えば、筆者はわかりやすく答える自信がありません。 だから、OO で言う抽象化をちゃんと説明できるようになろう。 そんなところから、「抽象化」を再発見しようと思ったのでした。

この記事では次の順番で「抽象化」を再発見していきます。 最初に、オブジェクト指向のソフトウェア開発方法論で説明された「抽象化」を紹介します。 次に、辞書などを参考に、OO 以外での「抽象化」を紹介します。 ここまでが今回の前編となります。 次回の後編では OO とそれ以外での「抽象化」を比較し、OO で言う「抽象化」の特徴を見つけ出します。 最後に筆者なりに「抽象化」を考察します。

3 開発方法論での「抽象化」

最近はそうでもないですが、一昔前、オブジェクト指向を扱った多くの書籍では用語や概念の説明がありました。 ここでは、それらから「抽象化」に関する説明を抜き出して要点を整理します。 また、過去の広場のコンテンツもあわせてご参照ください。

3.1 開発方法論での「抽象化」の要点

開発方法論によって「抽象化」の説明には多少の差異がありますが、概ね次のようにまとめることができます。

抽象化の定義は次の通りです。

なぜ抽象化するのかというと次の通りです。

システム開発のスコープでは次が理由となります。

抽象化する上での留意点は次となります。

代表例として OMT での「抽象化」の説明を示します。ご参照ください。

3.2 OMT

OMT は J.Rumbaugh らにより提唱されたオブジェクト指向ソフトウェア開発方法論です。 この記事では参考文献[1]を参照します。 筆者の所感では、クラス図(OMT ではオブジェクトモデル)での分析に関して最も詳細に説明している開発方法論です。

(参考文献[1] P.18より引用)

抽象化は問題のある側面を選択的に検討することである。 抽象化の目標は、ある目的にとって重要な側面を分離抽出し、重要でない側面を捨て去ることである。 抽象化は常にある目的に対するものでなければならない。 なぜならその目的によって、重要なもの重要でないものが決定されるからである。 同じ物事に対してその目的に応じて異なった多くの抽象化が可能である。
すべての抽象化は不完全で不正確である。・・・(中略)・・・抽象化の目的は、われわれがその中で物事を行えるように世界を制限することである。 それゆえモデルの構築においては絶対的な真理を探すのではなく、ある目的にとっての適切さを追及しなくてはならない。 ある状況に対する単一の「正しい」モデルが存在するのではなく、ただ適切なもの不適切なものが存在するだけである。

要点を整理すると以下となります。

なお、オブジェクト指向開発(システム開発)というスコープで次のような説明があります。

(参考文献[1] P.4より引用)

オブジェクト指向開発の本質は適用領域での概念を特定し、組み合わせるということであり、プログラミング言語で最終的に表現したものがオブジェクト指向か否かということではない。 ブルックスの調査によれば、ソフトウェア開発で困難な部分は問題固有の複雑さが原因となって問題の本質を操作するのが難しいことであり、その本質をたまたま特定の言語に写像するという偶然が問題なのではない。

(参考文献[1] P.7より引用)

抽象とは、ある実体の根本的で固有な面に焦点を当て、偶発的な性質は無視することである。 システム開発においては、オブジェクトがどのように実装されるかを決定する前に、オブジェクトが何であり何をするのかということに焦点を当てるということである。

このことから、OO が抽象化を扱う理由は次の2つと言えそうです。半ば強引ですが。

4 OO 以外での「抽象化」

オブジェクト指向のソフトウェア開発方法論で言う「抽象化」の特徴を見出すために、比較対象として OO 以外での「抽象化」について整理します。

4.1 辞書

goo のオンライン辞書(三省堂「大辞林 第二版」)からの引用です。

4.2 Wikipedia

フリー百科事典『ウィキペディア(Wikipedia)』からの引用です。※原稿執筆時点(2007/12/06)の記述です。

4.3 数学

参考文献[2]を参照して、数学(特にトポロジーの世界)での「抽象化」を見ます。

参考文献[2]では、残念ながら「抽象化とは○○である。」というようには明示されていませんが、「2 紙とエンピツの世界へ」からは次のようにまとめられます。

また、抽象化にはいくつかの段階があることを「ケーニッヒスベルクの橋の問題」(Googleで検索)を例に示しています。まとめると次の通りです。

  1. [抽象化されていない] 実際に現地で、試行錯誤的に何回かコースを変えて散歩する。
  2. [第一段階の抽象化] 相似図形の概念を用いて、地図の上(紙とエンピツの世界)で考える。
  3. [第二段階の抽象化] 橋のつながり具合だけが本質で、伸ばしたり、縮めたりする変形をして考える。
  4. [第三段階の抽象化] 橋である必要もなく、頂点と曲線の図形、すなわちグラフで考える。

4.4 心理学

認知心理学などいくつか文献をあたったのですが、さまざまに定義があり、またそれぞれの主張に合わせて定義されていました。 専門外である筆者にはそれらを整理するのが難しく、この記事では心理学での「抽象化」を整理することはあきらめます。

4.5 OO 以外での「抽象化」のまとめ

OO 以外での「抽象化」についていくつか見てきました。多少乱暴ですが、結局のところ抽象化とは次のように言えそうです。

また、特に数学での「抽象化」では次のことが示されていました。


以上、前編ではオブジェクト指向のソフトウェア開発方法論で言う「抽象化」と、OO 以外での「抽象化」についてまとめました。 後編では、OO で言う「抽象化」の特徴を明らかにし、筆者なりに考察していきたいと思います。

参考文献

  1. 『オブジェクト指向方法論OMT』(J.Rumbaugh他=著, 羽生田栄一=監訳, トッパン, 1992)
  2. 『考える力をつける数学の本』(岡部恒治=著, 日本経済新聞社, 2001)


© 2007-2008 OGIS-RI Co., Ltd.
Index
Index