第2部：UMLに関する素朴な疑問・誤解解決篇

Q2-2）UMLはオブジェクト指向か？

羽生田栄一
株式会社豆蔵 取締役会長

2003/6/28

---

　UMLってオブジェクト指向なんですか？ オブジェクト指向って何ですか？ クラスとオブジェクトの違いは？ オブジェクトの識別は難しいと聞きましたが？ 人によって違うモデル図ができてしまうのでは？ このような質問をよく受けます。今回の疑問は、みなさんが純粋に疑問に思われるこの問いに答えていこうと思います。

◆はじめに

　近年のUMLに関する流行、雑誌や単行本の出版やソフトウェアエンジニアの資格としての認知度など、1年前には考えられなかったほどの隆盛を極めているのは本当に驚きです。UMLを私が8年前に日経エレクトロニクスで解説記事として初めて紹介したとき、だれがこれほどまでに一般的に普及すると想像したでしょうか。しかし、UMLがこれだけ普及し始めたのとは裏腹に、UMLをきちんと使いこなすための基本原理であるはずのオブジェクト指向のデザイン原理はそれほど認知されているとはいえませんし、取りあえずUMLの文法とJavaさえ知っていればどうにかなる、という風潮さえ感じられます。結果として、現状のJavaによるシステム開発は、オブジェクト指向言語は使っているけれどもオブジェクト指向デザインにはなっていなかったり、UMLと繰り返し型開発スタイルを採用してはいるけれども、なぜかシステムの開発効率も拡張性や再利用性も高まっていない(かえってUMLなどの新技術の採用で学習コストが上がっている)という状況も見聞きします。

　ということで、まずはUMLとオブジェクト指向の関係について考えてみます。

◆オブジェクト指向とは何か

（1）いろいろな視点

　オブジェクト指向とは「Object-Oriented」の訳で略して「OO(オーオー)」といいます。モノ中心、対象に則して、という意味です。オブジェクト指向とは何か、に関しては皆さん、いろいろと思い入れがあるようで、ひとによりさまざまな説明が行われています。そして、それだけの多様性を受け止められるだけの奥深さがオブジェクト指向には備わっているともいえます。ここでは、まず、オブジェクト指向を「モノの見方・認識の視点」として原理的な説明を施し、次に「モデリングの観点」、そして「システム実現の観点」と順に説明を具体的・実践的な視点に落としていくようにします。

（2）オブジェクト指向の基本原理

　オブジェクトとは：私たちは日常生活を、ものや人に囲まれてそれらとのやりとりを通して生きています。そこで起こる悩みや問題も基本的には、それらのものを道具として使い、さまざまな人とパートナーとしてお互い協力することで解決していくわけです。そのとき、こういう目的にはこの道具が使いやすい、この仕事はあのパートナーと組むとやりやすい、と具体的な固有名を出して仕事の組み立てを頭の中でイメージします。このような具体的な問題解決の要素となるものや人のことを抽象化してオブジェクトと呼びます。

　クラスとは：その際、ものや人をその構造や機能や能力に応じて階層的に分類し、いつでも必要に応じて使い分けられるように概念整理をしておくと便利です。さまざまなオブジェクトを構造や機能によって類別し型として概念化したものをクラスと呼びます。クラスはその類似性と差異性に基づいて適切な(クラス継承)階層に分類されます。

　メッセージとポリモルフィズム：また仕事全体を進めていくうえで、ものや人同士でお互いに「ひと仕事」を依頼しあいます。この仕事の依頼のことをメッセージと呼んでいます。依頼メッセージはできるだけ仕事仲間の間で共通化しておいた方が何かと便利です。業界で仕事の進め方を共通化し、新人が入ってきても同じメッセージで仕事を依頼できれば、新メンバーへの業務移転も遅滞なくスムーズに進められるからです。同じ意味の仕事には同じ依頼メッセージを割り振るという命名規則のことをポリモルフィズムと呼んでいます。

（3）モデリングという観点からオブジェクト指向を見ると

　以上のような考え方で対象をとらえる方法をオブジェクト指向モデリングといいます。私たちの日常的な世界観に従って、対象をもの（概念のような抽象的な実体も含む）や人（というより役割）の集合として認識し、それらの相互作用でさまざまな現象が説明できる、ソフトウェアの構成もそれに従って行うべきだという考え方です。非常に素朴で、それでいて強力な「ソフトウェアアニミズム」とでも呼ぶべき世界観です。

　つまり、オブジェクト指向とは、業務や日常の世界に現実に存在する、あるいは仮想的に存在すると見なされている対象をオブジェクトとして明確に意識し、それらのオブジェクトを中心にシステムをデザインしていく手法です。業務世界から適切なオブジェクトとオブジェクト間の関係を抽出してくることをオブジェクト指向分析、その結果をシステムとして適切な構造と振る舞いに練り上げることをオブジェクト指向設計と呼びます。その際の基本原則は、業務世界で認識されている構造や振る舞いと要求されたシステムとして構築するソフトウェアの構造や振る舞いとをできるだけ自然に対応させられるようにデザインしようということに尽きます。その際に、その対応を少しでも明確に分かりやすくトレースできるようにするために、UML（Unified Modeling Language：統一モデリング言語）というビジュアルなモデル表現言語＝システム仕様記述言語を使うわけです。UMLの利用によって、問題領域や要求仕様やシステムやソフトウェアの構造や動作をあいまいさをできるだけ排除して論理的かつ適度な抽象度を設定して伝達しあうことがやりやすくなったといえます。

図1 業務世界とUMLモデルとシステムの対応関係

（4）システムの実現という観点からオブジェクト指向を見ると

　オブジェクト指向の基本は、内部状態を持つオブジェクトの集団がメッセージ(イベント)のやりとりによって各オブジェクトの内部状態を更新していき、その副作用としてアクションを行うという計算モデルです。メッセージをお互いに授受する有限状態機械のことをオブジェクトと呼ぶわけです。メッセージに反応してどんなアクションを実行するかという規則をメソッドといいます。メッセージに反応して起動されたメソッドの中でさらにほかのオブジェクトにメッセージを送信できます。

図2a 状態機械としてのオブジェクト

図2b 状態機械としてのオブジェクト群がメッセージを介して協調する

　問題領域やシステムをモデル化する場合、静的な視点は各オブジェクトの内部構造および各オブジェクト間の接続構造を併せて表現する「クラス図」、動的な視点は各オブジェクトの状態機械としてのライフサイクルを外部イベント(メッセージ)と対応するアクションとして表現する「ステートチャート図」がモデル表現の基礎となります。

　各ユースケースをどのようなオブジェクトの組み合わせで実現するかを検討するのに、シーケンス図やコラボレーション図が使われます。ユースケースごとに識別されたモデルオブジェクト群をマージし、整理してクラス分類し、各クラス間の関連や集約を識別して、問題領域を表現した分析モデルをクラス-関連図として記述します。また、ユースケース単位の状態遷移は結局、コントローラの状態遷移となります。

図3a ユースケース毎に相互作用し協調動作するオブジェクトの集団としてのシステム

図3b オブジェクトの集団がシステムアーキテクチャを構成する

（5）オブジェクトの識別は難しい？

　まず一言で回答してしまうと、最初の分析段階におけるオブジェクトの識別や概念モデルの構築は、決してソフトウェアエンジニアリング的な作業ではなく、あくまでも人類学、社会学的なフィールドワークとしてモデリング作業をとらえなければいけないということです。

　世間ではオブジェクト指向で適切なオブジェクトを識別するのは難しいといった評がよくなされます。しかし、オブジェクト指向が難しいのではなく、業務を適切に理解し構造として分析するのが難しいのです。従来はドメインにまで踏み込まず、自分たちが作る直近のアプリケーションの機能要求の切り出しだけでお茶を濁していたので難しさがあらわになっていなかっただけだともいえます。

　オブジェクト指向では、作ろうとしているアプリケーションの置かれるコンテキストをきちんと把握し、そのうえで、問題領域・業務領域で行われていることがその領域の専門家たちからどのように理解されているのかを知り、そのコンテキストにとって妥当な整理、抽象化を得た概念モデルとして表現しようと努力します。その際にUMLを使うのです。従って、概念モデリングは一種の現場のフィールドワークのようになります。概念モデリングする人は、業務領域の社会学調査をするつもりで、その業務にかかわる人々（現場担当者だけでなくその業務の直接の利害関係者たち）が、その領域を頭の中でどのようにイメージして活動しているのかを、頭の中から引きずり出して、UMLモデルとして定着させるつもりで臨まねばなりません。それらの利害関係者たちの間で少しずつ解釈が異なる部分を調停しつつ、共通の理解を促す基盤となる共通語彙としてこの概念モデルがクライントと開発者の両サイドにおいて共有されるようになることが目標です。

　ただし、何でもかんでもフィールドワークすればよいというわけではなく、そのプロジェクトの目標、システム化の目的、いい換えればどの問題ドメインを扱うのか、どのような視点で問題領域を見るのかは、あらかじめしっかりと統一しておく必要があります。すなわち、作ろうとしているシステムのビジネス上のコンテキストを確認するという前提のうえに上記の概念モデリング作業は成り立つというわけです。

（6）人によって違うモデル図ができてしまうのでは？

　従って、この作業はある程度以上のスキル、関係者とうまくコミュニケーションを取って現場や業務の中から基本的かつ重要な要素を認識し、そこから適切な概念を抽象化し構造を浮き彫りにできるようなスキルが望まれます。フィールドワークでは誰からでもうまく話が引き出せて固定観念にとらわれず柔軟な一方で、分析を進めるうえでは論理的・抽象的な思考の得意な人物であることが望ましく、そうでないとうまくモデリング作業は進みません。

　しかし、だれもがそうなれるわけもなく、今後は各問題・業務領域ごとに典型的な概念モデルがパターン化されて集積されていくものと思われます。実際、『アナリシスパターン』（マーチン・ファウラー著）や『ストリームラインオブジェクトモデリング』（ジル・ニコラほか著）などの成果も出つつあります。そのようなパターン化されたモデルがリファレンスとして業種・業界ごとに整備され、誰でもそれをベースに自分たちの独自の業務構造や要件部分を差分として付け加えたり取り除いたりして、業務モデルや概念モデルを完成させるということも現実的なアプローチと考えられます。そうなれば、モデラーの種類だけ異なったモデルができてしまうという状況はなくなっていくでしょう。そのためにも、典型的な問題・業務領域ごとの良質のリファレンスモデルがオープンソースならぬ“オープンモデル”として公開され、みんなの共有財産としていかねばならないでしょう。そうすれば、モデリング技術のスキル向上や教育の質も格段にアップすると思います。

　ただ、その場合でも、ビジネスの革新や業務の差別化を考えたモデリングセンスは問われることになりますが、いまはそこまでは議論しません。

◆ではUMLはオブジェクト指向か？

（1）この質問は何を意味しているのでしょうか？

　UMLは単なる2次元平面上のダイアグラム、もう少し正確にいうなら階層的入れ子構造を許したグラフにすぎません。ですから、それがオブジェクト指向であることはあり得ません。なぜなら、UMLのダイアグラムがメッセージに反応して動きだすなどということは聞いたことがないからです。

　ただし、あり得ないとばかりはいえません。UMLダイアグラムの背後にはきちんとしたオブジェクト指向セマンティクスが定義されていますので、それに基づいて動的モデル（ステートチャート図やアクティビティ図、相互作用図などのメタモデルで定義されているアクションセマンティクスでより実体化されると思います）を具体的にシミュレーションして動かす、ということも考えられます。ですから、UMLの各ダイアグラムの各モデル要素をその背後のセマンティクスまで踏まえて解釈すれば、UMLダイアグラム（というよりそれで表されたUMLモデル）はオブジェクト指向である、といえるでしょう。

　相反する2つの答えを用意しましたが、たぶん世間の皆さんが一般的に「UMLはオブジェクト指向か」と質問するときの意図はもっと現実的なところにあると思われます。つまり、「UMLはオブジェクト指向開発で使うんですよね」あるいは「UMLを使えばオブジェクト指向モデルに基づく開発になるんですよね」ということです。そこで、この解釈で以下の回答を試みましょう。

（2）UMLで一番重要な図であるクラス図はオブジェクト指向？

　UMLで一番重要な図はやはりクラス図でしょう。そしてオブジェクト指向開発で一番中心的に用いられるのもクラス図です。クラスアイコンが共通性を持ったオブジェクトの集合に対する定義を与えてくれます。つまり、密に関連する属性セットと操作セットをカプセル化して定義する点でまさにオブジェクト指向の原則にのっとっているといえるでしょう。またクラス間を結ぶ関連のリンクもお互いにそれらのオブジェクト同士がメッセージをやりとりできることを意味する点でオブジェクト指向の原則にのっとっているといえるでしょう。

　しかし、一方で、クラス図は、オブジェクト指向と関係なく利用できるのも事実です。例えば、クラス図でクラス定義の属性の欄だけを使い、さらに各属性に対するステレオタイプを使って<<primary key>><<foreign key>>などを区別することで、ER図として利用できるわけです。この場合、クラスアイコンには振る舞いの責務は存在しませんから、オブジェクトではないわけです。また、分析フェイズの初期に普通のクラス図ではなくもっとラフな見取り図として概念マップをクラス図の記法を用いて描くことがよくあります。概念とその意味的なつながりだけをネットワーク構造で表したもので、属性も操作も汎化も集約もありませんし、概念はカプセル化されていません。つまり複数の概念を束ねて新たな概念のくくりを作り出すことも概念マップでは自由なわけで、あくまでも頭の中の概念地図を描き出し自由にそれらを組み合わせたり変形したり自由に操作して発想を広げることが重要なのであって、オブジェクト指向の原則が適用されるわけではないのです。

（3）相互作用図はオブジェクト指向？

　では、相互作用図つまりシーケンス図やコラボレーション図はオブジェクト指向でしょうか。これらのダイアグラムの意味するところはオブジェクトの集団のメッセージ送受信による協調（コラボレーション）の様子を表示することですから、まさにオブジェクト指向といえます。これらの図をほかの目的で利用することはクラス図とは違ってあまり考えられません。しかし、いうまでもないことですが、各オブジェクトが適切な責務（レスポンシビリティ）を割り振られて相互作用しているかどうかまではUMLでは保証してはくれません。

（4）ステートチャート図やアクティビティ図は？

　ステートチャート図はいわゆる状態遷移図のことです。これがオブジェクト指向かと問われれば、何を対象に状態をモデル化するかによります、と答えざるを得ません。システム全体を対象にしていれば従来の使い方と変わりません。オブジェクト1つ1つを対象にしていれば、各オブジェクトのライフサイクルをモデル化している、つまり外部からのメッセージ（イベント）に反応してどんなアクション（メソッド）を実行し、結果として自分の内部状態をどう変えるかをモデル化していると見なせますから、まさにオブジェクト指向です。

　アクティビティ図は、業務のワークフローやユースケースの内部の処理フロー、メソッド内のアルゴリズムなどを表現するダイアグラムですから、基本的にはオブジェクト指向的ではありません。しかしながら、責任主体（一種のアクター）を示す複数のレーンを設定して、各レーン間でどのようにアクティビティの実施責任を分担しオブジェクトフローをやりとりしあうかを表現すれば、それは一種のアクター間相互作用図ということになり、それに関してはオブジェクト指向的といえます。

（5）では問題のユースケース図はオブジェクト指向か？

　UMLの中でオブジェクト指向でないといって一番議論の的になるのがユースケース図です。いわく、ユースケース図は従来の機能分割と同じではないか！ 確かに形式的にはユースケースは機能に相当するので、このように考えても間違いではありません。しかし、ユースケースの利用のココロは従来の機能分割法とはまったく異なります。

　従来の機能分割は、システムの処理内容をトップ機能から始めていかに階層的に構成するかが問題とされました。あくまでも開発者側の視点に立って機能やメカニズムの階層として手続きに分解していくわけです。一方、ユースケース図の場合には、あくまでもエンドユーザーを役割分類したアクターの視点に立って、そのアクターが業務上価値を感じるサービス内容の単位でユースケースを識別するといういわゆる「アクター満足充足の原則」に基づいてシステム要求を記述します。それより細かい単位での記述は慎みます。従って、ユースケースは「システム機能」と考えるよりも「システムがアクターに提供するサービス」と考える方が妥当です。つまり、ユースケース図というのは、アクターの視点から見たシステムという巨大な1個のオブジェクトの外部公開サービスのセットすなわち利用インターフェイスの規定と見なすことができます。そういう意味では、ユースケース図もオブジェクト指向といえないこともないことが納得していただけましたか。

図4 ユースケース図はシステムという巨大なオブジェクトのクラス定義である

（6）まとめ

　UMLに対する今回の疑問への答えは、結局のところの皆さんが、UMLをどのような意識で利用するかにかかっていると思われます。UMLをオブジェクト指向デザインのための戦略的ツールとして中心に位置付け、プロジェクトメンバー間でのビジョンとアーキテクチャの共有にまじめに取り組むかどうかにかかっているのです。ですから、そういう意味ではUMLはユーザー指向なのだといえます。

コラム：オブジェクト指向モデリングの原理的基礎付けが始まりつつある！

何が適切なオブジェクトないしはクラスであるかは、対象世界をどのような視点でどのような意図や目的を持って認識するかによって変わってきます。この辺の事情は、現在、認知意味論によって解明が進みつつあります。私たちが世界を認識する際の「カテゴリ（オブジェクト指向でいうところのクラスを哲学ではこういい習わしてきました）」は従来、（1）そのカテゴリのメンバーの客観的共有属性によって定義するいわゆる集合と同一視する、（2）カテゴリは恣意的であり人間が自由に設定できる、の2つの対立する見方で考えられてきました。 　しかし、（1）については「コップ」や「いす」のような単純な対象でさえ共通属性を定義することは難しいという難点が指摘され、（2）については「色」の例から分かるようにカテゴリには認知基盤があり勝手に設定はできないことが明らかになってきたのです。「色」でさえ、生理的・認知的制約が働くだけでなく、生存に重要なものが重視されるという環境的要因に従ってカテゴリ分類されています。そこで、現在、認知意味論を主導するGeorge Lakoff（ジョージ・レイコフ）らは、（3）経験的実在論（experiential realism）という第3の立場を主張するに至っています。 　その立場では、カテゴリは、人間の生理的・認知的なプロセスを基にした身体的経験のみならず生活環境や物理・社会的世界との相互作用の結果として生じてくるとしています。こうした立場は従来、哲学の世界では「家族的類似」などとあいまいに呼ばれてきましたが、それに対する認知意味論・認知言語学からのより理論的な解明が始まりました。プロトタイプ意味論・フレーム意味論・メタファー意味論などがかなり納得できる説明の枠組みを提供しつつあります。 　日本語や英語などの日常言語の使い手がその背景として無意識に想定している常識的な世界観というものがあります。世界には、明確な境界を持つほかから空間的に分離された自立した個体が存在し、それらの個体は相互に作用しあって、結果として世界は変化していきます。従って、世界はその変化も含めて、オブジェクト（個体）とそれらの間で作用を伝達しあう相互作用ネットワークとして見なすことができます。この世界観を認知文法理論の提唱者のRonald W. Langackerは「ビリヤードボールモデル」と呼んでいますが、これはソフトウェアの世界でまさにオブジェクト指向モデルと呼ばれるものに一致することはお分かりいただけるでしょう。 　このように、認知意味論を代表として認知言語学では現在、人類一般の世界の認識の仕方、概念の構成の仕方、意味の与え方に関して、従来の思考を突き抜けて、人間の与えられた認知能力と身体的・環境的な制約とのインタラクションとしてとらえ直す動きが活発化しています。その動きの中で、今後、オブジェクト指向モデリングの原理的な基礎付けも行われていく可能性があるでしょう。日常世界・業務世界の中での適切なオブジェクトの識別やそのクラス定義の粒度、汎化（継承）階層で概念分類する際の指針、アナロジーやメタファーの能力とポリモルフィズムに基づく妥当なインターフェイス定義の構成、といった事柄がいまよりも具体的な指針の下で説明できるような時代がくるかもしれませんね。

【参考文献】

［1］マーチン・ファウラー著、『アナリシスパターン』、ピアソン・エデュケーション、2002年
［2］ジル・ニコラ著、『ストリームラインオブジェクトモデリング』、ピアソン・エデュケーション、2002年
［3］ジョージ・レイコフ著、『認知意味論』、紀伊国屋書店、1993年
［4］Ronald W. Langacker著 、『Foundations of Cognitive Grammar Vol.2』 、Stanford Univ. Press、1999年

Development Style FAQ UML篇 INDEXへ戻る

　

IT Architect 連載記事一覧