オブジェクト指向方法論批判

１７-1
１７.
オブジェクト指向方法論批判（１）連関論
本章では，UML に代表されるオブジェクト指向方法論の欠陥について，連関(association)
の扱いを中心に詳述する。
１７.１連関と連関クラス
まず OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 における連関
と連関クラスの定義を見ていこう1。
(a) 連関(association)は，タプル(組)の集合を記述する。タプルの値は型付けられた個例の値
を参照する。連関の個例はリンクと呼ばれる。
(b) 連関は，型付けられた個例の間に発生し得る意味的な関係を指定する。連関は特性によ
って表現される端(end)を少なくとも 2 つ持つ。それぞれの特性はその端の型に結び付け
られている。連関の 2 つ以上の端が同一の型を持ってもよい。
(c) 連関は，連関する型の個例の間にリンクが存在することを宣言する。リンクとは，連関
の各端と 1 対 1 で値を持つタプル(組)である。ここに，各値はその端の型の個例である。
(d) 連関クラス(association class)とは，連関とクラスの双方の性質を持つモデル要素である。
連関クラスは，クラスの性質を持つ連関と見ることもできるし，連関の性質を持つクラ
スと見ることもできる。連関クラスは，一組の分類子を結合するだけでなく，それらの
分類子ではなくその関係自身に属する一組の特性を定義する。注意：連関クラスの１個
例の中には，各端で分類子に連関づけられた個例が唯一つしかない。すなわち，個例の
観点からは，連関端の多重度は’1’である。論理的には，連関クラスと連関は意味的に同じ
ものである。しかし，図式表現は異なる。
(e) 特性は構造的特質(structural feature)の一つである。被所有属性(ownedAttribute)によっ
て分類子に関連付けられた特性は属性を表し，また，連関端を表してもよい。特性はク
ラスの一個例をその属性の型の値または値の集合に関連付ける。メンバ端(memberEnd)
によって連関に関連付けられた特性は連関端を表す。特性の型は連関端の型である。
［7.3.44］
(e)は，連関端を属性と同様に扱ってよい――従って，連関をクラスとして表現できる――こ
とを示している。ここまでの定義に忠実に，クラス図として図式化すれば，2 つのクラス A と
B との間の連関 AB と，3 つのクラス A，B，C の間の連関 ABC は，図１７-１のように描く
以下，枠囲みは OMG UML 2.1.2 からの引用。訳責は筆者。訳文は適宜並べ替えてあるので，順序は原文と
一致しない。
Copyright © 200-2010 by IT Consulting Co., Ltd. All Rights Reserved
1
１７-2
ことができる。いずれも，連関端は連関するクラス(の個例)への参照であるから，タプルはその
並びとなる。図中，連関端のタプルである属性は，他の属性と区別できるように，網掛けを施
してある。同様に連関クラスを描いたものが図１７-２である。同図では，連関 AB が固有の属
性 X を持っている。
連関端A
クラスA
連関AB
A
AB
参照
連関端B
a1
a2
a3
クラスB
B
a:A
b:B
ab1
ab2
ab3
ab4
ab5
a1
a1
a2
a2
a3
クラスA
連関ABC
A
b1
b2
b2
b3
b3
a1
a2
a3
b1
b2
b3
b1
b2
b3
ABC
参照
参照
クラスB
a:A
b:B
c:C
c1
c2
参照
C
クラスC
B
参照
abc1
abc2
abc3
abc4
abc5
a1
a1
a2
a2
a3
b1
b2
b2
b3
b3
c1
c2
c1
c2
c2
図１７-１ 2 項連関 AB と 3 項連関 ABC
クラスA
連関クラスAB
クラスB
A
AB
B
参照
a:A
b:B
x:X
固有の属性
a1
a2
a3
ab1
ab2
ab3
ab4
ab5
図１７-２
a1
a1
a2
a2
a3
b1
b2
b2
b3
b3
参照
x1
x1
x2
x3
x2
b1
b2
b3
2 項連関クラス AB
これらの図を見比べれば，連関クラスだけあれば，すべての種類の連関を表現できることが分
かる。最初に図１７-１で導入された連関は，固有の属性を持たない連関クラスとして扱えば
よい。さらに，連関端はクラスの属性として定義されるので，実装上は――すなわち，オブジ
ェクト指向プログラミング言語の構文要素には――クラスだけあればよく，連関も連関クラス
も不要である。発想を転換すれば，クラスは連関クラスから連関を除いたものであるから，連
関クラスさえあれば，クラスも連関も表現できる。これは，モノをもコトで表現する述語抽出
法の立場からは，当然の帰結である。
Copyright © 200-2010
by IT Consulting Co., Ltd. All Rights Reserved
１７-3
１７.２ UMLでの連関の記法
ここまで，連関クラスだけあれば，すべての種類の連関を記述できることを指摘した。しか
し，実際には，UML にはさまざまな連関の記号が用意されており，無用の混乱を招いている。
以下，その原因を究明し，UML が抱える問題点を指摘する。
(a) いかなる連関も，(線の端子よりは大きい)菱形として描いてよい。各連関端と 1 対 1 の
実線が菱形をその端の型である分類子に結びつける。3 項以上の連関は，この方法でし
か描けない。
(b) 2 項連関は，通常，2 つの分類子を結びつける実線として，あるいは，単一の分類子を
自分自身に結びつける実線として(2 つの端は別物である)，描かれる。
(c) 連関端は，連関を描く線と，結びつけられる分類子を描くアイコン(通常は長方形)との
間の接点である。
(d) 連関クラスは，連関経路に点線で接続されたクラス記号として示される。連関経路と連
関クラス記号は同じモデル要素であり，単一の名称を持つ。その名称は経路上，クラス
記号内，あるいは，その双方に配置してよいが，同一の名称でなければならない。
上の定義によれば，UML では，連関には，連関クラスを含めて，図１７-３に示すように，
3 つの記法があることになる。
(a) 2項以上の連関
X
(b) 2項連関
Z
X
Y
(c) 連関クラス
Y
X
Y
A
図１７-３
連関の 3 つの記法
図１７-１と図１７-２では，項数や属性の有無に関わらず，連関を同じ形式で表記できそう
であった。ところが，実際には，連関の記法は 3 つあるし，クラス図本体の記述項目が微に入
り細を穿っているのに対し，菱形の連関記号は中味が何もない。さらに釈然としないのは，な
ぜ，2 項関連だけ別扱いなのか(連関端はどこにいったのか？)，ということである。
Copyright © 200-2010
by IT Consulting Co., Ltd. All Rights Reserved
１７-4
１７.３連関端の扱い
最初に，2 項連関に限定して，連関端がどのように扱われているのかを見ておく。
(a) 端クラスに所有される，または，連関の航行可能被所有端である連関端の特性は，その
連関が対向端から航行可能であることを示す。さもなければ，その連関は，対向端から
航行可能ではない。
(b) 連関するクラスによる連関端の所有は，ドットで示してもよい。下図は，端 endA がク
ラス B に所有されていることを示している。さらに，ドットがないことによって，端
endB が連関 BinaryAssociationAB によって所有されていることをも明示している。
A
endA
*
endB
BinaryAssociationAB
B
*
(c) 下図左は，あるクラスに所有される連関端は属性でもあるので，クラスに所有される連
関端に対して属性表記を用いることができることを示している。これを適用すれば，(b)
の図は下図右のようになる。
B
A
endA
*
endB
BinaryAssociationAB
a:A[*]
*
B
a:A[*]
(d) 連関端には，以下のような特性(Property)がある：
• メンバ端(memberEnd)：各端は，連関のリンクでその端に結び付けられた分類子の個例
が参画していることを表す。
• 被所有端(ownedEnd)：連関自体によって所有される端。
• 航行可能被所有端(navigableOwnedEnd)：連関自体によって所有される航行可能端。
本来，連関端の所有者は，図１７-１に示すように，連関だけのはずであった。ところが，
上記の定義によれば，連関自体の他に，連関に関与するクラス(連関クラスではない)も連関端を
所有できることになる。上の囲みの中の(c)の右図で，連関端 endA がクラス B に所有されてい
るということは，ドット記号の存在だけでなく，実際に属性として実装されることからも裏付
けられる。しかし，同図の連関 BinaryAssociationAB と連関端 endB にはどのような実装の裏
付けがあるのであろうか？答えは，
「実装方法は存在しない」である。図(c)は，単向だから目立
たないが，図１７-４のように双向にしてみれば，そのことが明白になる。図１７-４では，連
関端 endA と endB は，それぞれ対向のクラス B と A に所有されている。しかし，連関
BinaryAssociationAB に対応する実装は存在しない。この図から，１つの 2 項連関のタプルが
2 つのクラスの属性に“解体”されたことが見て取れる。連関はタプルであるから，タプルを
解体するということは連関そのものを解体することである。換言すれば，連関端の一方でもク
Copyright © 200-2010
by IT Consulting Co., Ltd. All Rights Reserved
１７-5
ラスが所有するということは，その連関端がメンバであった連関を解体することであり，その
結果，もとの連関は実体を失う，ということである。実体のないものは実装できない。
endA
A
*
endB
BinaryAssociationAB
B
*
b:B[*]
a:A[*]
図１７-４
双向の 2 項連関
では，連関の解体はどのように行われたのか，単向連関を例にとって検証する。
(a)連関ABが連関端A,Bを所有
(a) 元来，2 項連関 AB の連関端 A, B は，
連関AB
タプルとして連関 AB に所有されてい
クラスA
た。連関端 A, B の値はクラス A, B(の
a:A
参照
個例 a, b)への参照である。
AB
a b
連関端A
クラスB
参照
b:B
連関端B
(b) A から B への単向連関 AB をクラス A
(b)連関ABをクラスAに吸収
に吸収する。すると，連関端 A は自分
自身(クラス A)を参照することになり，
a:A
参照
無意味な存在となる。
b:B
参照
AB
a b
(c) そこで，無用になった連関端 A を亡者
(c)無用の連関端Aを消す
(なきもの)にする。同時に，連関の資格
a:A
を失った連関 AB も亡者にする。この結
果，連関端 B はクラス A によって所有
されることになる。一方，同時に亡者と
参照
b:B
参照
AB
a b
端Bの所有者：クラスA
端Aの所有者：連関AB
なった連関端 A と連関 AB の所有関係
は，冥界でも元のままである。従って，
(d)実際に描かれる姿
a:A
「連関端 A は連関 AB に所有されてい
b
る」と言えないことはない。
(d) 実際にクラスに残るのは，
連関端 B と，
連関端 B からクラス B への参照である。
(e) この参照を改めて連関にすり替えたの
b:B
参照
(e)実際に描かれる姿－UML
A
BinaryAssociationAB
B
b:B
が，
UML の 2 項連関である。すなわち，
UML の 2 項連関は，
実は連関ではなく，
図１７-５
連関の参照へのすり替え
(クラス間の直接)参照である。
Copyright © 200-2010
by IT Consulting Co., Ltd. All Rights Reserved
１７-6
図１６-５に示す経緯を見れば，オブジェクト指向陣営は，
「わが意を得たり。暗黙裡に存在
する連関端 A は暗黙裡に存在する連関 AB に暗黙裡に所有されているのだ。すべて暗黙裡だか
ら記号として明記されないだけだ。
」と主張するであろう。しかし，図１７-４の実装には，連
関端 endA と endB は出現するが連関 BinaryAssociationAB は出現しない。連関
BinaryAssociationAB は，
“思い”としては存在するが“形”としては存在しない。実装
(implement)とは，
“思い”を“形”にすることであるから，
“形”として存在しない限り，実装
したとは言えないのである。試みに，上記の連関 BinaryAssociationAB に属性を追加してみよ。
“形”がないものに属性を与えることはできない。ましてや，連関端の一方しかない単向“連
関”は，連関と呼べるものではない。
単向連関 BinaryAssociationAB と連関端 endB は，
図中とモデラーの頭の中には存在するが，
コンピュータの中には存在しない。しかし，実際に図中にある線は，連関ではなく，参照でし
かない。参照を連関と強弁していることに変わりはない。
かくして，UML の 2 項連関は，実際には連関ではなく参照であることが明らかになった。と
ころが，UML の“連関”が間違いであり，使うべきではないという結論には至らないところに，
問題の根深さがある。真の問題は，連関と参照の混同と，モデリングにおける視点(viewpoint)
の混同が並行しているということである。
１７.４第三者視点と当事者視点
述語抽出法におけるモデルとは，システムの外部にある現実世界をシステム内部に写像した
ものであり，現実世界のモノゴトもその像も第三者の視点で眺められる。この第三者は，現実
世界をシステム内部に写像する役割をも担うのが普通である。
一方，オブジェクト指向におけるクラス図とは，あるクラス A が他のクラス B のメソッドを
呼び出す2という，クラス間の相互作用(interaction)を図式表現したものである。このとき，ク
ラス A とクラス B は，メソッド呼び出しの当事者として振る舞う。すなわち，クラス A は動作
主体(私，一人称)を，クラス B は動作客体(貴方，二人称)を演じる。これらのクラスは，システ
ムの中で実際にプログラムとして動くので，当事者という。当事者視点でのクラス間の連関は，
一人称クラスから二人称クラスへのメソッド呼び出しという相互作用であり，そこで使われる
アクセス経路 (access path)あるいはパイプ(pipe)は，参照として実装される。
当事者と第三者は，演劇における演者(actor)と観客(audience)にたとえることができる．演者
同士は科白のやりとりを行い，観客がそれを見る．ただし，UML 使用事例図(Use Case
Diagram)におけるアクターと混同される恐れがあるので，本書では演者(actor)と観客
(audience)という用語を使わず，当事者と第三者と呼ぶ．
2
公開(public)変数のアクセスには，get/set という暗黙のメソッドが使用される。
Copyright © 200-2010 by IT Consulting Co., Ltd. All Rights Reserved
１７-7
第三者視点と当事者視点の違いを実際の例で見てみよう。図１７-６は，
「人が，ランプを点
けたり消したりする」というモノゴトを，(a)第三者視点で眺めたときと，(b)当事者視点で眺め
たときの様子を示している。両眼の記号が視点を表し，卵黄に相当する部分が現実世界のモノ
ゴトの写像を表し，卵白に相当する部分がプログラムを表す。
点灯する
人
ランプ
人
ランプ
点灯する
(a)　第三者視点
(b)　当事者視点
図１７-６
2 つの視点
図１７-６の両図とも，システムの外界が描かれており，そこには，人とランプというモノが
存在する点は共通である。違いは，コトの存在場所である。(a)第三者視点では，点灯するとい
うコトも外界に存在する－第三者である観者は「人がランプを点灯する」というモノゴトを捉
える。(b)当事者視点では，点灯するというコトは，システム内部に(メソッド呼び出しとして)
存在する。当事者視点で見た外界は UML の使用事例図(Use Case Diagram)に他ならず，外界
の人とランプは，アクター(actor)である。このように，UML は徹頭徹尾当事者視点に立つ。
図１７-７は，これらの実体関連図／クラス図をもう少し詳細に表したものである。第三者
視点で眺めた時の実体関連図は，次の 2 つの述語を図示したものになっている：
点ける(人，ランプ，時刻)
消す(人，ランプ，時刻)
点ける
PL
点灯中
消灯中
人
人
P
ランプ
L
<参照>
ランプ　L
灯状態
L.点く()
消す
PL
(a) 第三者視点
(b) 当事者視点
図１７-７ 2 つの視点のクラス図
Copyright © 200-2010
ランプ
by IT Consulting Co., Ltd. All Rights Reserved
点く
消える
１７-8
ただし，複数回の点ける／消すを区別するため，時刻印を含む 3 項述語にしてある。また，
点灯中／消灯中という単項述語は，現時点で点灯中／消灯中のランプの集合を表す。したが
って，現在点灯中のランプが消されると，そのランプは，点灯中集合から消灯中集合に移動す
る3。簡単のため，ハイパー関連
は使っていない。ここでは，観者(viewer)は，現実世界で起
きているモノゴトを，忠実にモデルに反映するだけである。
一方，当事者視点で眺めたときのクラス図は，次のようなことを表現している：
人を表すクラス(に含まれるメソッド)は，ランプを表すクラスの点くメソッドや消えるメ
ソッドを呼び出すであろうし，public 属性の灯状態を読み取ることもあろう。そのためには，
クラス人はクラスランプを参照できなければならない。すなわち，クラス人やランプは，
自律的に動く当事者なのである。そして，＜参照＞の矢印は，当事者間の相互作用を表してい
る(たまたま上例では，作用は人からランプへの単向であるが)。これが，本来クラス図の連
関によって表されるべきものである。
第三者視点では，
「誰それがランプを点けた」というもモノゴトをシステムに取り込むだけで，
このシステムが実際にランプを点けるわけではない。しかし，当事者視点では，ランプクラス
が電気回路を制御して，実際のランプを点けることができる。
両者をプログラムに変換してみれば，観点の違いが際立つ4。図１７-８にそれぞれのクラス
図を示す。クラス間の矢印はすべて参照である。
(a)Lamp3rdPerson は第三者視点によるもので， Main が観者(viewer)の代理として現実世
界をシステムに写像する。Main は大きな長方形に含まれるすべてのクラスを参照する。また，
長方形に含まれるクラスはすべてその個例を収納する集合を暗黙裡に従えている。
(b)LampFirstPerson は当事者視点によるもので，Main が Person の代理として，実際にラ
ンプを点灯／消灯する。ランプの点灯状態は，状態変数 State に格納される。各クラスの個例
を集合に収納する必要は特にない。
3
状態を表す単項述語集合間の元の移動は，その元の状態遷移に他ならない。述語抽出法では，状態遷移はこ
のように表現される。
4 この例を Java で書いたプログラムを付録に収めている。
Copyright © 200-2010 by IT Consulting Co., Ltd. All Rights Reserved
１７-9
Main
ON
Turn
ON
Person
OFF
TIME
Lamp
Person
兼 Main
Lamp
Lamp　L
State
TurnOn
TurnOff
Turn
OFF
(a) Lamp3rdPerson
(b) LampFirstPerson
2 つの視点をプログラムに変換
図１７-８
このように，参照にすり替えられた連関と本来の連関との混同は，当事者視点と第三者視点
の混同に平行しているのである(表１７-１)。そして，最大の問題は，UML 仕様作成者に混同の
自覚がないことである。
表１７-１
連関と視点の並置
連関の種類
視点
2 項連関 (実は参照)－直線
当事者視点
2 項以上の連関－菱形
第三者視点
連関クラス－直線とクラス記号
さらに混乱に拍車をかけているのは，21 世紀以降のビジネスアプリケーションシステムでは，
2 つの視点を同時に扱わなければならないケースが当然となっていることである。その典型例
がオンラインショッピングで，一つのモノゴトを：
第三者視点「客が商品を注文する」
当事者視点「客が画面から商品の注文を入力する」
という 2 つの視点から同時に眺める必要がある。
ところで，当事者視点で見たクラス図を第三者的に眺めると，図１７-９(a)のようにクラス
同士の間には，
“参照する”という関係がある。ここから，同図(b)のように，システム内部にあ
るすべてのクラスの間の相互参照を表記できる。これは，システムのソフトウェア部品表(Bill
Of Materials－BOM)に相当するもので，通常はリポジトリで集中管理される。しかし，この第
Copyright © 200-2010
by IT Consulting Co., Ltd. All Rights Reserved
１７-10
三者視点は，システムの内部のクラス(プログラム)間の関係を眺めたものであり，現実世界を眺
めたものではない。当然，現実世界を反映しているとは限らないので，本来の第三者視点と混
同してはならない。
人
参照する
ランプ　L
ランプ
灯状態
点く
消える
(a) 当事者間の参照を第三者視点で眺める
図１７-９
Ｃａｌｌｅe
クラス名
Ｃａｌｌｅｒ
Arg
参照する
引数と
する
(b) クラス間の相互参照図
クラス間の相互関連図
１７.５ UMLとデータモデル
UML は，
自分が描くモデルを因果関係モデル(Causality Model)と自己規定している[6.2.3]。
因果関係モデルとは，プログラムの実行時の振舞を，呼び出す側(因)から呼び出される側(果)へ
の作用として記述するものである。従って，クラス図は，プログラム間の呼び出し－呼出され
(caller-callee)関係を当事者視点から描写したプログラム関連図に他ならず，第三者視点による
現実世界のモノゴトの像ではない。
因果関係モデルでは，あり得るのは 2 項連関だけで，3 項以上の連関はあり得ない。一見 3
項(以上)に見える連関も，2 項連関の組み合わせである。また，連関クラスもあり得ない。連関
(参照)に固有の属性は，2 項連関のどちらかのクラスに属させることになる。連関の菱形記法や，
連関クラスは，連関をクラスと独立の存在として扱うため，第三者視点の場合に使われるもの
であり，当事者視点では使えないのである。
UML 仕様書の冒頭には，
「UML の目標は，システム・アーキテクト，ソフトウェア技術者，
ソフトウェア開発者に，ビジネスなどのプロセスをモデル化するための道具だけでなく，ソフ
トウェアに基づく(software-based)システムの分析，設計，実装のための道具をも提供すること
である。
」と，UML が上流工程にも適用できるかのような宣言があるが，UML は，本来下流
工程にしか適用できないことを肝に銘じるべきである。にもかかわらず，連関端の“タプル”
という関係モデルまがいの連関を持ち出したのは，上流工程に対する憧憬あるいは劣等感の表
れなのかもしれない。しかし，これには，関係モデルにも責任の一端はある。なにしろ，多(1)
対１に限るとはいえ，2 項関係のタプルを参照にすり替えたのは，関係モデルの方が本家なの
であるから，UML 陣営が「UML のクラス図でも，データモデリングができる」と錯覚したの
も無理はない。
筆者は，オブジェクト指向方法論の有効性を高く評価するものである。特に，オペレーティ
Copyright © 200-2010
by IT Consulting Co., Ltd. All Rights Reserved
１７-11
ング・システムや各種ミドルウェアに代表される，現実世界とは隔絶した，ソフトウェアに閉
じたシステム5の開発には，絶大な威力を発揮する。(現に，述語抽出法の“基本方程式”は Java
で記述できた)。しかし，残念なことに，現実世界を相手にしなければならない上流工程には向
かない。プログラムの構造と現実世界の構造が相似しているという根拠のない類推に基づいて，
下流工程用の方法論を上流工程に安易に拡大適用したために，関連と連関(＝参照)を混同し，無
用の混乱を招いているのは，褒められたことではない。
述語抽出法を使えば，図１７-８(a)で示したように，第三者視点による現実世界のモノゴト
の像をクラス図として表記することは可能である。しかし，いたずらに混乱するだけであろう
から，第三者視点は実体関連図，当事者視点はクラス図と使い分けることを推奨する。
5
この他にも，現実世界との接点が限定されるソフトウェア・システムとしては，機器組込み型(従来は制御系
と称した)ソフトウェアやゲーム(含む，仮想現実)ソフトウェアなどが挙げられよう。ビジネスシステムにおい
ても，GUI の発達により本来のビジネス・プロセスから離れた部分のソフトエアの比重が高くなっている。オ
ブジェクト指向の隆盛はこのようなソフトウェア開発の趨勢と無縁ではない。
Copyright © 200-2010 by IT Consulting Co., Ltd. All Rights Reserved

Download Report