「オブジェクト指向プログラミングJ， その起源からの検証

1
3
7
「オブジェクト指向プログラミング J
，
その起源からの検証
山 本 雅 昭
目 次
1 本論文について
2 S加 u
l
a
:オブジェクト指向言語の誕生
3 S
m
a
l
l
t
a
1
k
4 C++
5 オブ、ジェクト指向とクラス指向
6 オブジェクト指向プログラミングの方向性
7 結びにかえて
本論文について
r
o
b
je
c
t
O
r
i
e
n
t
e
d
J なる語が学術論文，一般論文，コンピュータ関連
雑誌，及びソフトウェア工学書に頻繁に登場し始めた時期は，世界的には
1
9
8
6
年以降からであり，日本圏内では若干遅く，この翌年以降からである。
r
o
b
j
e
c
t
O
r
i
e
n
t
e
d
J は Simu
1aが起源となって，そこから派生した初期の
S
m
a
l
l
t
a1kがその概念を総称したものであり， 1
9
7
0
年代前半には既に存在
していた。しかし， 1
9
8
6
年に B
oochの m
b
j
e
c
t
O
r
i
e
n
t
e
dDevelopmen
t
J
I
に端を発して，世界的に注目を集めるようになった。この点において 1
9
8
6
年は r
o
b
j
e
c
t
O
r
i
e
n
t
e
d元年」であり，この年を境に， r
o
b
j
e
c
t
O
r
i
e
n
t
e
d
J
1
3
8
第1
9
巻 第 1号(経済学・経営学編)
なる語がコンビュータ業界で話題を独占することとなる。
i1986
年」から十年が経過した現在，ソフトウェア産業界においてオブ
ジェクト指向は既に新語としての響きを完全に失い，技術的な側面ではあ
る程度の普及したものと認識されている。ただし，これは「オブジェクト
指向」が専門技術用語のーっとして一般でも認知され，普及段階への移行
の兆候が現れ始めたレベルにすぎない (Yo
町 d
on，1994)。
過去において，構造化開発の一般化が「構造化プログラミング」の普及
からスタートしたのと同様に，オブジェクト指向も「オブジェクト指向プ
ログラミング」から一般へ普及し始めた。ところが，現在においても，オ
ブジェクト指向プログラミングの一般への普及に反して，オブジェクト指
向開発の普及に大きな進展がみられない。この状況は，構造化プログラミ
ングの普及と構造化開発の一般化が比例関係であったケースとは大きく異
なる。企業レベルでのオブ、ジェクト指向ソフトウェア開発が本格化する兆
候も現れていないし，本格化するまでにまだかなりの時聞を要する:
オブジェクト指向開発とオブジェクト指向プログラミングの関係は，絶
対的な相互関係ではない。構造化開発においても，オブジェクト指向プロ
A
b
s
t
r
a
c
tDataTyping) の延長
グラミングは選択肢の一つであり， ADT(
線 上 に オ ブ ジ ェ ク ト 指 向 プ ロ グ ラ ミ ン グ を 応 用 す れ ば よ い (Meyer
，
1988)。ただし，この現状を問題視するに至るのは，この現状が起こり得
ると予測した複数の研究者が，既にその弊害を含めて警告を発していたこ
とにある: 「オブジェクト指向」は単にプログラム・コーデイングを技術
的側面から効率化するためのものではなく，分析/設計段階における「非
n
o
n
a
l
g
o
r
i
s
m
i
c
)J
なオブジェクト指向アプローチがシ
アルゴリスミック (
ステム開発に粛す恩恵のほうがより重要なのである (
Booch，1994)。現在
(
1
) Y
o
u
r
d
o
n(
1
9
9
4
)は
， COBOLの標準仕様にオブジェクト指向技術が拡張される
まで，企業レベルでのオブジェクト指向開発は本格化しないと予測している。
(
2
) B
o
o
c
h(19
9
4
)，
Y
o
u
r
d
o
n(
1
9
9
4
)，
Meyer(
19
8
8
)，C
ox(
19
9
0
) は，オブジェクト
指向プログラミングが先行して普及した場合，オブジェクト指向設計/分析との
間に概念的な溝が生ずる可能性を示唆していた。
「オブジェクト指向プログラミングJ，その起源からの検証
1
3
9
では多くのプログラム言語がオブジェクト指向プログラミングをサポート
するようにはなったが，プログラミング手法のみの習得で「オブジェクト
指向」の真意が理解できるわけではなく，又，その真の目的が達成される
わけで、もなし、。残念ながら，オブジェクト指向は構造化と同様にプログラ
ミングから普及し始め，そのことが多くの矛盾と誤認を蔓延させている。
本研究の着手には，これら研究者の予測が，現実問題として浮上し始め
たことが起因している。特に重大な現実問題として，以下の三点に総括さ
れる。
O 入門書や技術解説書を参照し，オブジェクト指向プログラミングを習
得しでも，オブジェクト指向の概念を明確に理解できなし、。
O オブジェクト指向プログラミングで、コーディングを行ったにもかかわ
らず，オブジェクト指向システムを開発できない。
0再利用性が向上しなし、。
これらの問題は実例として，
W
P
i
ぜ叫1
s o
f O
b
j
e
c
t
O
r
i
e
n
t
e
d
tJIと『オブPジェクト指向狂詩曲』中において既にある程度詳
Developmen
細されている。しかし，このどちらも技術解説書の部類に属する実用書で
あり，学術的な見識には全く欠けている。オブPジェクト指向は学術研究の
結果から導き出されたものであり，数々の学術研究を経て実用段階レベル
に到達した。この後詳細するが，オブ、ジェクト指向は単に新しいプログラ
ミング技法として，学術研究者に注目されたわけではなし、一般普及の段
階において，単なるプログラミング技法として技術解説を行えば，実際に
は「オブジェクト指向」そのものの意味が極めて暖昧なものとなる。そし
て現時点において，
r
オブジェクト指向」がし、かに暖味で，かつ難解なも
P
i
t
f
a
l
l
so
fO
b
j
e
c
t
O
r
i
e
n
t
e
dDevelopmen
tjJと『オブ、ジェ
のとなったかを W
クト指向狂詩曲』が代弁している。
9
8
0
年代後半，多くの研究者
「オブジェクト指向」が注目を集め始めた 1
第1
9
巻 第 1号(経済学・経営学編)
1
4
0
達は「構造化開発」の普及時の失敗を繰り返さないために，オブジェクト
指向分析/設計をオブジェクト指向プログラミングに先行させるべく努力
してきたが，予想通り，ソフトウェア SEを代表とする技術者達の多くは
オブジェクト指向プログラミングを， i
オブジェクト指向」の入り口とし
て選択している。プログラミングを「オブジェクト指向」の第一歩に選ぶ
ことに否定的であるべきではないが，各技術者が構造化開発の経験の中で
蓄積してきた「アルゴリズム重視」の思考と知識をベースにし，オブ、ジェ
クト指向プログラミングの習得の過程において，オブジェクト指向の潜在
的概念である「非アルゴリスミック」な思考を同時に習得できる技術者が
数多くいるとも考え難 L。
、
研究目的
厳密には，オブジェクト指向プログラミングは， i
プログラム言語J
，i
。
フ
，i
オブジェクト指向設計」の三つが複雑に絡み合う。
ログラミング技法J
プログラミングを「オブジェクト指向」の第一歩とする場合，ここに大き
な落とし穴がある。技術解説書はプログラム言語とプログラム技法を詳細
するが，同レベルでオブジェクト指向設計を詳細していない。反対に，オ
ブジェクト指向設計は，手法問での標準化が進まず，所謂「乱立状態」に
ある。
本論文の目的は，オブジェクト指向技術(オブジェクト，クラス，カプ
セノレ化，継承等のサポート技術)の技術論から離れ，オブジェクト指向プ
ログラミングの習得に不可欠な基本概念と，その土台となる思考法につい
て，未定義であった部分を含めて新たに明確にすることにある。これは，
総括的には以下の三点を指す。
(
a
)
i
オブジェクト指向プログラミング」の真意
(
b
) オブジェクト指向プログラミングの必要性
(
c
) オブジェクト指向プログラミングの方向性
「オブジェクト指向プログラミングJ
. その起源からの検証
1
4
1
ただし，本論文は研究対象として，オブ、ジェクト指向開発上における「オ
ブジェクト指向プログラミング」に重点を置いている。これは. i
オブジ
ェクト指向プログラミング」をオブジェクト指向開発上の一つのステージ
(段階)として位置付け. i
オブジェクト指向」をコンピュータ上に反映
iプログラム言語」なる道具)にしかすぎない
するための作業とツール (
ことを意味する。
研究方法
本研究は上記に従い，オブジェクト指向プログラミングをオブジェクト
指向開発の 1ステージとして位置づける。つまり，道具の効率的な使用方
オブジェクト指向」において，この道具が必
法を追求するのではなく. i
要となった背景を検証し，この本質を追求している。
以下に，本研究過程の手順の要約を記しておく。
(
1
) Sim
叫aと Sm
叫
】t
必k誕生当時まで朔り文献調査を行い. i
オブジェ
クト指向誕生」の背景を検証する。
(
2
) 初期の S
i
m
u
l
aと Sm
a
1
l
t
a1kにおいて. i
オブ、ジェクト指向」は何を
意味するものであったか，研究開発プロジェクトの真意を探る。
(
3
) 現時点で一般的に総称される「オブジェクト指向プログラミングJ
，
及び「オブジェクト指向プログラミング言語」と，初期の S
i
m
u
l
a
開発チームと Sm
a
1
l
t
a1k開発チームが創出したオブ、ジェクト指向プ
ログラミングを比較し，相違点を明確にする。
(
4
) オブジェクト指向プログラミングとオブジェクト指向言語の発展す
ベき方向性を追求する。
本研究は先ず，過去のオブジェクト指向誕生まで糊り， i
オブジェクト指
向」の本来の意味を再確認する。オブ、ジェクト指向の起源である S
i
m
u
l
a
第1
9
巻 第 1号(経済学・経営学編)
1
4
2
と
，
r
オブジェクト指向」の総称を創り出した
Sma11ta1kは，暖昧となっ
てしまった現在の「オブジェクト指向」を，原点、から見据えるためにも必
要不可欠な存在である o 特に Sim
u
1
aは「非アルゴリスミック」な「オブ
ジェクト思考」を前提にして，このオブ、ジェクト思考をオブジェクト指向
としてプログラム可能な「オブジェクト・アセンブリ」の手法を創出した。
詳細は本文中にて行うが，オブジェクト指向プログラミングによってコー
ディングされたソフトウェアが，オブジェクト指向ソフトウェアと呼べる
かどうかは，この「オブジェクト・アセンブリ」に代表されるマルチプル
M
u
l
t
i
p
l
eViews)の有無が唯一の判断材料となる。
・ビュー (
2 SIMULA:オブジ.エクト指向言語の誕生
Simula誕生
S
i
m
u
l
a誕生は 1
9
6
0
年代まで湖り，シミュレーション用言語の Sim
u
1
a1
がその産声を上げる。 Sim
u
1
a 1 の rSim
叫a
J はシミュレーシヨンを指し
ており，正確には当時の OR (
O
p
e
r
a
t
i
o
n
a
lR
e
s
e
a
r
c
h
) と離散事象シミュ
レーション (
D
i
s
c
r
e
t
eEventS
i
m
u
l
a
t
i
o
n
) を背景に誕生する。
S泊lUl
a1の最大の特徴は， ALGOL60 をベースにオブジェクトとクラ
スの概念をプログラム言語中に取り入れた点であり， S
泊l
u
1
a
6
7はその当
時で既にオブジェクト指向プログラミングを可能としたことにある。ただ
し
， Sim
u
1
a はオブジェクト指向言語として誕生していなし、。厳密に言え
ば，当時において「オブジェクト指向」なる名称と共に Sim
u
1
aは誕生し
o
b
j
e
c
t
O
r
i
e
n
t
e
d
J の総称は S
m
a
l
l
t
a
l
kの基本概念として初め
ていなし、。 r
て用いられた語であり， S
i
m
u
l
a 1 誕生当時にはまだ存在してはいなかっ
た
。
S
i
m
u
l
aの「オブジェクト・アセンブリ」と B
o
o
c
hの MV(
M
u
l
t
i
p
l
eV
i
e
w
s
)は
厳密には異なるが，基本的には「静的 (
S
t
a
t
i
c
)Jと「動的(Dy
n
a
m
i
c
)
Jの二つ
のビューを同様に持つ。
(
3
)
「オブジェクト指向プログラミングJ
. その起源からの検証
1
4
3
Simula誕生の背景
Simulaは ALGOLベースであれ，全く新しい概念をプログラム言語に
取り入れたのは偶然ではなく，それを要する背景があった。 1
9
6
0年代に利
用可能だったプログラム言語は現在と比較すれば，極めて少なく. F
o
r
-
t
r
a
n に代表される科学技術計算用言語を用いてシミュレーション処理を
行っていた。
0第一世代言語
(
'
"
'
'
1
9
5
9
) :F
o
r
t
r
a
n1
.ALGOL58，IPLV 等
0第二世代言語(19
6
0
年初頭):F
o
r
t
r
a
nI
I，ALGOL60，COBOL，L
i
s
p等
しかし，各プログラム言語とも適正があり，この適正外においては，プロ
グラム言語そのものが大きな制約となることもある。 S加 叫a 誕生には正
にこの問題が背景にあった。
ALGOLや F
o
r
t
r
a
nに代表される従来のフ。ログラム言語とその設計手法
においては，言語特有の処理工程をプロセスとして記述するが，言語構造
と記述形式はコンピュータの内部処理に直接的に影響されている。ここで
問題となるのは，これらの従来言語では設計とプログラミングが困難な
ケースに遭遇した場合である。コンピュータの内部処理よりも，人間の思
考や認識に沿って設計とプログラミングを行いたいケースもある。特にシ
ミュレーション分野では，一般的な計算シミュレーシヨンではなく，観察
ygaard (
19
81
)
目的の再現シミュレーシヨンを行うケースがある。当時， N
は原子炉設計に取り組んでおり，従来言語と手法を用いての発展性を含め
加 叫a 誕生の背
た再現シミュレーションは困難であると判断を下した。 S
景には，離散事象シミュレーションに適したプログラム言語を創造する必
要性があった。
S泊 四1
aの特徴
Sim
叫a はオブジェクト指向言語ではあるが，プログラム言語として他
1
4
4
第1
9
巻 第 1号(経済学・経営学編)
の言語と比較すれば，現在では別段突出した存在ではない。
C++と比較
しでも，オブジェクト指向プログラミングに対するサポート機能で劣るし，
言語自体としても
ALGOLからの影響度が高 L。
、
Sim
u
1
a の最大の特徴は言語構造でも，記述形式でもなく，オブジェク
ト指向プログラミングを可能にしたことそのものにある。ソフトウェア開
発は最終的にはコンピュータ(計算機)上で・行われるため，単に哲学的な
概念や思想では，コードを生成するプログラムに適用することは困難であ
り，システム思考に準ずるオブジェクト思考をコンビュータ上で直接動作
させることは根本的には不可能である。しかも，オブジェクトの創発特性
ergentP
r
o
p
e
r
t
i
e
s
)を損なわず，これらをコンビュータ上でそのまま
(Em
動作させるとなると，オブ、ジェクト思考で動作するコンピュータか，又は，
これをエミュレートする仮想実行環境が必要である;そこで， S
加 叫a は
オブジェクトの抽出と定義する静的なビューと，要求された処理を実行す
:
s
i
m
a
a を経て，現在
る動的なビューの二つに切り離す手法を採用した
ooch によってマルチプル・ビューは一つの確立された手法となっ
では B
たが，相対的な二つの思考的概念を結び付ける発想なしに「オブジェクト
指向」が現実のものとなることはなかった。現実に，マルチプル・ビュー
不在のソフトウェア開発はオブジェクト指向開発ではなく，単に従来のプ
ロセス思考にクラス指向プログラミングを組み合わせたものにしかならない。
へ
オブジェクト思考から S
imula
Schmucker が行った調査から，オブジェクト指向プログラミング言語
の派生とその進化の過程は既に明確にされている。この調査結果において，
Sm
a
1
1
t
a
1
kは，このエミュレーション環境に極めて類似する実行
環境を開発し，この環境上でのみ動作できた。
(
5
) 分析と設計の初期段階は静的ビューを基にドメイン (
P
r
o
b
l
e
mD
o
m
a
i
n
) から
オブジェクトの抽出し，その本来の創発特性から各オブジェクトを定義する。実
際の処理プロセスはこのオブジェクトを一部利用して行う。簡単に言えば，オブ
ジェクトを幾ら集めたところでプロセスにはならないが，プロセスは各オブジェ
クトの創発特性を利用する。
(
4
) 実際に初期の
「オブジェクト指向プログラミングJ
，その起源からの検証
オブジェクト指向プログラミング言語の起源が
1
4
5
ALGOLから Sim
叫aへ
の派生にあり， S
i
m
u
l
aから更に S
m
a
l
l
t
a
l
kへと派生し，以降登場するオ
S
i
m
u
l
a 派生」と i
S
m
a
l
l
t
a
l
k 派生」
ブジェクト指向プログラミング言語は i
に大別可能である。この調査結果と分類方法を用いれば，全てのオブジェ
クト指向プログラミング言語の起源は S
加 叫aにあり，以降，派生的に進
化し，その数が増加してきたことになる。
現時点において， S
i
m
u
l
a は単純にオブジェクト指向言語のーっと認識
されがちであるが，
S
加1
叫a と「オブジェクト指向」の閣に「オブジェク
ト思考」があることを忘れてはならな L、。他のオブジェクト指向言語は「オ
ブ、ジェクト指向」を基に発展するが， S
i
m
u
l
a はゼロからスタートし，結
果として現在のオブジェクト指向の基本原理を創造したことになる。目標
であった離散事象シミュレーシヨンに適したプログラム言語の創造は， i
オ
ブジェクト思考」不在では不可能であり，これをプログラム言語上で実現
する努力がなければ達成できるものではない。
3 Smalltalk
M
i
c
r
o
s
o
f
tWindowsの V
e
r
s
i
o
n3
.
1 (及び3
.
1
1
) が世界市場を独占する
以前， A
ppleM
a
c
i
n
t
o
s
hは PCにマウスと GUI(
G
r
a
p
h
i
cUserI
n
t
e
r
f
a
c
e
)
を導入し，多くの一般ユーザの指示を得た。この M
a
c
i
n
t
o
s
h の成功を背
景に，現状の PC-OSの大半は GUIベースとなり，又マウスは今や標準
としてどの PCにも付属している。
Apple社は PC市場における「マウス+GUIJの先駆者であるが，実際
にはこのどちらも A
p
p
l
e社が研究/開発したものではない。 A
p
p
l
e設立者
の一人である S
t
e
v
eJ
o
b
sは
， XEROX社の研究所を訪れ，当時そこで研
究/開発中のマウスと GUI に魅了されたので、ある。この研究所内(略称
PARC:P
a
l
oA
l
t
oR
e
s
e
a
r
c
hC
e
n
t
e
r
) において心理学研究者(一部，哲学
研究者含む)チームが，幼児の学習能力と学習過程を参考にし，コンピュー
1
4
6
第1
9
巻 第 1号(経済学・経営学編)
タ上でのポインテイング・デ、パイスと GUI のコンビネーシヨンを創出し
た。ただし，この研究は「子供達にも扱えるコンピュータ」なる大目的の
基に行われた。そして. S
m
a
l
l
t
a1kもここから創造される。
Smalltalk誕生の背景
S
m
a
l
l
t
a1kは「オブジェクト指向言語」として初めて誕生したプログラ
ム言語である。当時. S
i
m
u
l
aは既に実用されていたが. Sm
a
1
1
t
a
l
kの言語
構造も記述形式も S
i
m
u
l
a とは大きく異なり，直接の影響を匂わせる点は
極めて少ない。上記において S
m
a
l
l
t
a
l
kは S加 叫aから派生していると述
べたが，表面的に見れば，プログラム言語としての S
m
a
l
l
t
a
1
kが S
i
m
u
l
a
から派生したとは想像し難い。この違いは. Sim
叫a がシミュレーション
目的なのに対して. S
m
a
l
l
t
a1kはユーザ・インターフェイス重視であるこ
とから生じる。 S
m
a
l
l
t
a1kを開発したメンパーの一人は，コンヒ。ュータ上
でグラフイツクをインターフェイスに採用することに，ユタ大学の学生で
あった時点から興味を示し. S
i
m
u
l
aの経験を踏まえて. S
m
a
l
l
t
a1kの研究
を XEROXにおいて行うことになる。 S
i
m
u
l
aが離散事象シミュレーショ
m
a
l
l
t
a1kの研究/開発はユーザ・イ
ン用に研究/開発されたのに対して. S
ンターフェイスに注目したコンピュータの進化そのものであった。
S
m
a
l
l
t
a1k開発プロジェクト・チームが目指したのは. r
オブジェクト指
向」の確立ではなし、。このプロジェクト・チームが試みたのは. r
数値と
文字」のみのコンピュータ上に. r
サウンド」と「イメージ」をユーザ・
m
a
l
l
t
a1kが
インターフェイスに応用することであり，一つの結果として S
創造されたのである。 S
i
m
u
l
a は「数値と文字」中心の典型的なシミュ
レーション・プロ向けであったが，反対に S
m
a
l
l
t
a
l
k開発フ。ロジェクト・
a
c
i
n
t
o
s
hは皮肉にも成
チームのターゲット・ユーザは子供達で、あった。 M
Sm
a
1
1
t
a
1
k
はS
加 叫a以外の言語(例. F
LEX) にも強く影響されている。
Sm
a
1
1
t
a
1
k
がS
i
m
u
l
aから大きな影響を受け， S
凶 叫aから派生していることは，
Go
l
d
b
e
r
g自身が明確にして Lる。
(
6
)
(
7
)
「オブジェクト指向プログラミングJ，その起源からの検証
1
4
7
人層からの強い支持を得るが，現在の一般普及型 PCのユーザ・インター
フェイスの全てがこの影響を受けている。
Smalltalkの特徴
Sim
u
1
a と Sma
l
1
t
a
l
kの間には，オブジェクト思考上において大きな違
m
a
l
l
t
a1kのマルチプル・ビューは， Sim
u
1
aとは多少異なり，
いがある。 S
静的ピューの比率が極めて高い。 S
m
a
l
l
t
a
l
k は全てをオブジェクトとして
m
a
l
l
t
a1kのプログラム言語としての特徴の一つではあ
取り扱う。これは S
るが，コンピュータ上で動作可能にするため，厳密にはプロセスであるも
のまでオブジェクトとして利用するよう強制している。この点が，
S
m
a
l
l
t
a1kがオブジェクト指向理想主義の象徴と称される最大の要因であ
ろう。しかし，これは記述上においての問題であり， Sma
l
1
t
a
l
k であって
もマルチプル・ビューを応用しなければ，コンビュータ上で実行可能なソ
フトウェアを構築することは不可能である。
Sm
a
1
1
t
a1kが S加 叫a から受けた影響は極めて大きいが，言語構造と記
述形式等は Sim
u
1
aから離れ，独自の世界を築くに至っている。例えば，
l
1
t
a
l
kの実行環境の特徴を上げるが，これらを参照しただけで
以下に Sma
も Sm
a
1
1
t
a
l
kが何故独自の世界を築くに至ったかは十分に察することが可
能であろう。
(
a
) ユーザ・インターフェイス
(
b
) 多重 Windows
(
c
) アイコン
(
d
) プルダウン・メニュー
(
e
) ポインティング・デ、パイス(マウス)
上記の特徴は， M
a
c
i
n
t
o
s
h のユーザ・インターフェイスと，現在の主要
PC-OSが標準でサポートする機能である。結果として， M
a
c
i
n
t
o
s
h を含
1
4
8
めて大多数の
9
巻 第 1号(経済学・経営学編)
第1
PC-OS及びワークステイションのユーザ・インターフェイ
m
a
l
l
t
a1kの実行環境が OSとして進化したものであり，コンピュー
スは S
タの一般普及への基盤を創造したことになる。又， S
m
a
l
l
t
a1kはオブジェ
クト指向プログラミングの観点においては，その GUI構築に対する有効
性を実証したことにもなる。ただし，オブ、ジェクトとクラス，オブジェク
ト思考等，概念的な部分を創造したのは，
S
加 叫a であることには間違い
m
a
l
l
t
a1kも存在せず，
ない。仮に S加 叫a が創造されていなければ， S
M
a
c
i
n
t
o
s
h も生まれていなかったかもしれない。この点を熟考すれば，
S
i
m
u
l
aから S
m
a
l
l
t
a
l
kへの派生が，コンピュータの短い歴史の中でも極
めて重要なことであることが分かる。
S
m
a
l
l
t
a1kのプログラム言語としての特徴は，ターゲット・ユーザを子
供達に設定したことにあった。このユーザ設定は他のプログラム言語とは
大きく異なり，言語構造と記述形式を従来のプロセス指向から，より直感
的，かつ簡素化された新たな指向性を必要とした。このため，開発チーム
は単なる技術者の集団ではなく，心理学者，哲学者，医学者等の研究者も
含めた研究チーム編成で，十年にも及ぶ結果のーっとして，
r
オブ ジェク
F
m
a
l
l
t
a1kを創出した。
ト指向」から S
Simulaから Smalltalkヘ
S泊1叫a は離散事象シミュレーションに特化したプログラム言語であっ
た
。 S
泊l
u
l
a はシミュレーシヨン用の道具(ツール)であり，この観点上
m
a
l
l
t
a
l
kを GUI重視の子供向けに開発された道具であった。
においては， S
ここにおいて再確認すべきは，この道具 C
S
i
m
u
l
aと S
m
a
l
l
t
a
l
k
) が「オブ
ジェクト指向」であったのではなく，オブジェクト指向をコンピュータ上
に反映させる道具として，オブジェクト指向言語が必要であった事実であ
る。この点を見落とせば，
r
オブジェクト指向プログラミング」の意味は
凶u
l
aと S
m
a
l
l
t
a1kの開発/研究過程を振り
極めて不透明なものとなる。 S
返れば，その目標が「再利用性」ではないことは明白であり，
r
再利用性」
「オブジェクト指向プログラミングJ
，その起源からの検証
1
4
9
はオブジェクト指向(正確には「オブジェクト思考 J
) そのものから得ら
れる二次的な効果でしかなかった。
4 C++
PC上で利用可能なプログラム言語は年々その数を増している。その中
でも最もポピュラーなのは VB(
V
i
s
u
a
lB
a
s
i
c
)，C++
，P
a
s
c
a
lであろう。
VBは B
a
s
i
cの言語特性とその容易な GUIインターフェイス構築を武器に
し，一般企業に広く普及，プロトタイピングを含む業務用応用ソフト開発
を中心に広く利用されている。
P
a
s
c
a
l 系プログラム言語は欧米で高い人
DOSベースの応用ソフト開発の主要言語の一つであ
e
l
p
h
iを筆頭にし，本格的に GUIベースの
ったが，ここ数年においては D
P
C
O
Sに移行し始めた。
C++は上記 VBや P
a
s
c
a
l系言語とはその存在自体が大きく異なる。 C
気を維持し，従来の
言語そのものは低水準言語であり，強力なタイプ・チェックと厳格な構文
法がセールス・ポイントである
VBや P
a
s
c
a
l系言語と比較すれば，タイ
プ・チェックも構文法も極めてルーズであり，どちらかと言えばアセンブ
リ言語の代用的な存在と受け取られやすい。反面，強力なエディタと開発
環境から得られるデ、パッグ性の高さから，制約の多い高水準言語を嫌う技
術者達が
c言語を利用し続けている。
C++の背景
C++とL、う言語自体は一般に誤認されているケースが多いため，
において解説するが， C++はオブジェクト指向言語ではない。 C++の
O
b
j
e
c
t
i
v
e
Cの存在がある。 Sma
1
l
t
aJk派生の
，オブジェクト指向の概念と関数ライブラリーは
Sm
a
1
l
t
叫k 派に属すが，スーパーセットのオブジェクト識別子とメッセージ転送
をプリプロセッサで処理する以外は従来の Cと同じであり， C++とは正反対の
プρログラム言語となっている。
(
8
) 混乱を引き起こす要因の一つに
Objective-C
に関する限~
1
5
0
第1
9巻 第 1号(経済学・経営学編)
開発者である S
t
r
o
u
s
t
r
u
p(
19
8
6
) が最初に開発したのは rCwi
出 C
l
a
s
s
e
s
J
である。 S
t
r
o
u
s
t
r
u
pが注目したのは， S
i
m
u
l
aや Sm
a
1
l
t
a1kのオブジェク
l
n
h
e
r
i
t
a
n
c
e
)
ト指向の概念や「オブジェクト」ではなく，クラスと継承 (
の応用性と実用性の高さにあった。 S
t
r
o
u
s
t
r
u
pはこの rcw
i
t
hC
l
a
s
s
e
s
J
を rC++Jへと呼び名を変更したが，オブジェクト指向開発を前提とし
たオブジェクトの概念定義と C 言語自体をオブジェクト思考に沿う形式
には変更していない。単純に言えば， C++はオブジェクト指向開発用言
A
b
s
t
r
a
c
tD
a
t
aT
y
p
i
n
g
) とクラス及び継承を組み合わ
語ではなく， ADT(
せ，クラス指向の拡張に重点を置いていた。勿論，オブジェクト指向開発
のコーディング段階でオブジェクト指向プログラミングを行なうことも可
能である。
C++の特徴
C++はオブジェクト指向プログラミングに必須である技術は一通りサ
ポートしている。 GC(
G
a
r
b
a
g
eC
o
l
l
e
c
t
i
o
n
) は基本的にサポートされて L、
ない点と，平行処理に関してサポートの乏しい点を除けば，技術的な側面
においてはオブジェクト指向言語の理想主義を代表する Sm
a
1
l
t
a
l
kよりも
優位に立っている。
C++ は
， S
m
a
l
l
t
a1kを理想主義とすれば，象徴的な実用主義のプログ
ラム言語である。オブジェクト指向言語とは異なり， C++は大量に既存
する C コードをそのまま流用することも可能にし，又必要とあれば，既
存 C コードを強引にオブジェクト指向プログラミングに併用することも
可能にする。つまり，複合型のプログラミング・スタイルを可能にするこ
とで，従来のスタイルを好むプログラマ一連には拡張機能的にオブジェク
ト指向スタイルのプログラミングを可能にできる。この C++の手法は，
(
9
) スーパークラス不在でオブジェクト指向プログラミングを行なうケースをクラ
ス指向と総称とする場合もあるが，ここで怯オブジェクト指向開発に限定されず，
従来のプログラミングにクラス・ライブラリーと継承等を拡張的に利用するスタ
イルを指す。
「オブジェクト指向プログラミングJ，その起源からの検証
1
5
1
高水準言語を使用せず，敢えて低水準の C 言語を使用するプログラマー
達にとっては，オブジェクト指向プログラミングの所謂「美味しい所」だ
けを拝借できる重宝な代物なのである。
S泊 四l
aから C++ヘ
i
S
i
m
u
l
a
S
m
a
l
l
t
a
l
k
Jと i
S
i
m
u
l
a
C
++J，この二つの派生を比較し
た場合，一つの明確な違いを見つけることができるはずである。この違い
とは， C++ は「オブジェクト指向」を何ら発展させてはいない。 C++
は食欲にオブジェクト指向を吸収し，現時点においては，オブジェクト指
i
m
u
l
aは勿論， S
m
a
l
l
t
a
l
kですら完全に圧倒し
向技術のサポート度では， S
ている。ただし，これらオブジェクト指向技術の全ては必ずしも必須では
ないし， ADA
，M
odula-2，Mesa，Sue等の特に貧弱なオブジェクト指向技
術しかサポートしていない言語であっても，オブジェクト指向プログラミ
ングは可能である。オブジェクト指向技術のサポート度が，プログラム言
語の優劣を決めるわけで、はなし、。
C++の「オブジェクト指向」に対する最大の貢献は， Cが汎用言語で
あり， C 言語でオブジェクト指向プログラミングを可能にしたことであ
る
。 S
i
m
u
l
aは本質的にシミュレーション用言語であり， S
m
a
l
l
t
a
l
kはその
V
i
r
t
u
a
lM
a
c
h
i
n
e
) から，汎用言語と呼べる存在では
独自性と実行環境 (
C++や O
b
j
e
c
tP
a
s
c
a
lに代表される複合プログラミング・スタイルを可能と
するプログラム言語は， rADT+クラス及び継承Jを応用することによって，従
来の構造化開発でも強力な拡張機能となる。ただし，オブジェクト指向開発以外
においてオブジェクト指向プログラミングを利用したところで，オブジェク指向
分析/設計の基本概念との聞に矛盾が生じる。クラス・ライブラリーと継承の利
点のみを拡張的に応用する場合は「クラス指向プログラミング」とすべきであろ
(
1
0
)
う
。
(
1
1
) 機能的な不足や技術の不備は，拡張的に付加すればよ L、。例えば，
Rumbaugh
e
t
.a
l
. (1991) は，従来言語上でオブジェクト指向プログラミングを可能にする
多数の拡張テクニックを紹介している。ここにおいて問題視している点は，言語
自体の特性である。
(
1
司 T
u
r
b
oP
a
s
c
a
l も同様に，この点、においては大きく「オブジェクト指向」に貢
献したことになる。
1
5
2
第1
9
巻 第 1号(経済学・経営学編)
なかった。この観点においては， C++は P
C/ワークステイション上に，
汎用言語として新しい可能性を一般ソフトウェア技術者に与えたと言えよ
う
。
C++とオフ‘ジヱクト指向プログラミシグ
Sim
u
1
a は離散事象シミュレーションを目的としたシミュレーション用
言語であったがため，観察目的の仮想現実をシミュレートする作業自体が
「オブジェクト指向(思考 )J であった。つまり，
r
観察目的の仮想現実の
シミュレーシヨン」上に，オブジェクト指向(思考)の原点、があるといっ
im
u
1
a と同様に，離散事象シ
ても過言ではない。これは言い換えれば， S
ミュレーション上において C++ が使用された場合， C++ のサポート
するオブジェクト指向技術は，必然的にオブ、ジェクト指向プログラミング
に方向づけられる。ところが， C++ や O
b
j
e
c
tP
a
s
c
a
l (ここでは，
S
m
a
l
l
t
a
l
kも含む)に代表される PC/ワークステイション上での汎用言語
は，オブジェクト指向技術(特に，カフ。セル化，クラスと継承)を拡張的
にサポートしたが，汎用目的において，この道具をどのように「オブジェ
クト指向」に対して応用するかには，全く無関心である。
C と C++ の聞に言語としての本質的な違いはなく，当たり前の事で
はあるが C++ は C にしかすぎない。プログラミング言語としての
C++はオブジェクト指向プログラミングの必要機能を備えるが，この点
だけをもって， C++をオブジェクト指向言語と定義することは本質的に
不可能であることは，これまでに検証をおこなった S
泊l
u
1
aと S
m
a
l
l
t
a
l
k
から明白である。どの言語にも誕生の背景があり，言語構造及ひ記述形式
はその背景から創 P出される。言語に拡張機能を追加したところで，その
言語の本質は容易に変更可能なものではない。又，
r
オブジェクト指向プ
ログラミング」はオブジェクト指向技術とプログラミング技法が創り出す
ものではなく，
r
オブジェクト指向」をコンピュータ上に反映させるため
の手段にしかすぎなし、。最終的には， C++をオブジェクト指向プログラ
「オブジェクト指向プログラミングJ
. その起源からの検証
1
5
3
ミングの道具として使用できるかどうかは，設計仕様そのものが問題とな
る
。
5 オブジェクト指向とクラス指向
「オブジェクト指向」は，英単語 r
O
b
j
e
c
tO
r
i
e
n
t
a
t
i
o
n
J の日本語訳であ
る:しかし，この「オブジェクト指向」がこれほどまでに難解な専門用語
となってしまった背景はどこにあるのか?
この疑問を解く鍵に，ソフトウェア開発に対する「オブジェクト指向効
果」への期待の高さがある。そこで，期待される「オブジェクト指向プロ
グラミング効果」を以下の二つのポイントに要約した。
(
1
) 生産性の飛躍的向上。
(
n
) 品質の大幅な向上。
ここで重要なのは，上記二つのポイントは，オブジェクト指向が潜在的に
有する「高い再利用性」を前提において達成されると定義されていること
である。
純然たる矛盾が生ずるのは. S
凶 叫a と S
m
a
l
l
t
a
l
k，そのどちらも「再利
用性の追求」したプログラム言語として誕生していない点にある。
S泊1叫a と Sm
a
1
l
t
a
l
k，このどちらもが「結果」として創出されたものであ
り，単なる目的に要する道具(ツール，またはユーティリティ)にしかす
ぎない。「オブジェクト指向言語」と L寸道具を. r
コードの再利用」の方
向に利用するのは，純粋な「オブジェクト指向」の目的ではない(正確に
は
， r目的ではなかった J
)
o C++や O
b
j
e
c
tP
a
s
c
a
lに代表される， rコー
iO
b
j
e
c
t
O
r
i
e
n
t
e
d
Jの日本語訳を「オブジェクト指向」とするほうが一般で
あるが， i
O
b
j
e
c
t
O
r
i
e
n
t
e
d
Jは形容詞であり，厳密にはオブジェクト指向の概念
的な総称である。
(
1
3
)
1
5
4
第1
9
巻 第 1号(経済学・経営学編)
ドの再利用」を大前提としてオブジェクト指向技術(クラス，オブジェク
ト，カプセノレ化，継承等のサポート技術)を吸収してきたプログラム言語
を用いて. r
コードの再利用」を最大の目的とした「オブ、ジェクト指向プ
ログラミング」を解説したところで，オブジェクト指向が難解なものとな
るのは極めて自然な結果である。
オブ、ジェクト指向プログラミング」と
結論として引き出されるのは. r
「再利用」を切り離し，先ず「オブジェクト指向」の概念を徹底すること
が必要である。ただし，これは純粋に「オブジェクト指向プログラミング」
を習得することが目的の場合に限られる。
r
コードの再利用」を完全に無
視し，オブジェクト指向を純粋に遂行した結果，再利用性が副産物として
生じないならば. r
オブジェクト指向」とその「潜在的な再利用性」を発
見することは不可能であろう。
しかし，現時点において純粋にオブジェクト指向の概念を習得するのは，
この数年に出版された技術書，発表された文献ともに. r
クラス指向」の
汚染度が極めて高く，極めて困難である。そこで.•S
i
m
u
l
aと S
m
a
l
l
t
a
l
k
誕生まで湖!'J.その背景にあった「オブジェクト指向(思考 )
J の基本概
念を，オブジェクト思考を中心として以下の五点、に要約する。
「指向(O
r
i
e
n
t
e
d
)
Jの意味
「オブジェクト指向」の概念を習得する過程において，先ず，英語の
r
o
r
i
e
n
t
e
d
J に相当する「指向」が極めて不明瞭であり，この「指向」な
る語に翻弄されてしまう。そして，この不明瞭さが. r
オブジェクト指向」
に対して，何か霧に包まれたようなイメージを抱かせてしまう。
しかし，現実には，この「指向」の部分に然したる意味はない。
e
n
t
e
d
Jの語訳は. r
指向J
.r
志向 J
.r
至高J
.r
重視」等の内どれであ
「伽i
っても. r
オブジェクト」と組み合わせ，一語となり得れば問題とはなら
r
コードの再利用」が目的であれば. r
オブジ z クト指向」を習得する必要は
なしクラス指向プログラミングをその目的に合わせて習得すれば事足りる。
(
1
4
)
「オブジェクト指向プログラミングJ，その起源からの検証
1
5
5
ない。結果的に，その語が「オブジェクト」を強調していれば十分である。
O
r
i
e
n
t
e
d
J，日本語の「指向」にしても，問題となるの
ただし，英語の I
はその前にある「オブジェクト」の意味にある。つまり， i
オブ、ジェクト
指向」の概念の全ては，この「オブジェクト」にある。簡単に言えば， i
オ
ブジェクト指向」の呼称をやめ，単に「オブ、ジェクト」だけで済ませるこ
とも可能である。
「オフ、ジェクト (
Object)Jの意味
実際には， i
オブジェクト」の意味は極めてシンフ。ル，かつ明解なもの
であり，辞書に掲載されている程度の意味しか持たない。
ここにおいて， S
i
m
u
l
a誕生の背景と， S
i
m
u
l
aが「オフ。ジ、エクト指向」
i
m
u
l
a 開発チーム
をコンピュータ上に反映させえた手法が重要となる。 S
が離散事象シミュレーシヨンの分析と設計上で応用したのは「オブジェク
O
b
j
e
c
tT
h
i
n
k
i
n
g
)Jであって， Sim
叫a でのコーディング技術の
ト思考 (
部分が「オブジェクト指向」に該当する。補足的な解説をするならば，
S
i
m
u
l
a開発チームは「全体から部分の役割を定義する」従来の思考では，
「部分」に役割が与えられるために，離散事象シミュレーシヨンのような
仮想現実の観察目的には応用性の問題が大きい。そこで「部分」の概念を
捨て，
i
オブジェクト」の概念を取り入れた。ここでは， i
オブジェクト」
を「全体の一部分」として定義しないことが，必要最低限の概念となる。
つまり，オブジェクト思考とは，オブジェクトをドメインから抽出し，こ
の定義を行うための概念でしかない。
「オフ.ジェクト」の利用(再利用)
オブジェクト思考上で注意すべきは，オブジェクトに役割を与えてはなら
ないことだけである。ところが，現実には，ソフトウェア技術者にとって，
この点が極めて難解なのである。
当然ながら，ソフトウェアが提供するサービスをオブジェクトに割り振
第1
9
巻 第 1号(経済学・経営学編)
1
5
6
ることができなければ，単なるオブジェクトの集合だけではソフトウェア
として動作可能な構造を形成しな L、。現実に，オブジェクト思考だけでソ
フトウェア開発は不可能である。
この解決方法は極めて単純で、，オブジェクトに何かさせるのではなく，
オブジェクトを「利用」すれば済むことである。つまり，全てにおいて「オ
ブジェクトに
させる」発想を捨て，オブジェクトの創発特性がプロセス
中から利用可能であれば，これを活用すれば事足りる。
「クラス指向プログラミング」と「オブジェクト指向プログラミング」
「オブジェクト指向」と「クラス指向」はプログラミング技法上におい
ては，全く同一である。放に，コーディング段階においてプログラマーが，
オブジェクト指向プログラミングとクラス指向プログラミングを使い分け
ることは不可能である。又，詳細仕様書に従いプログラムをコーデイング
するプログラマーに，各オブジェクトの仕様を書き換えることは許されな
い。最終的には，設計者に全てが委ねられる。オブジェクト思考とマルチ
プル・ビューが設計仕様に反映されてこそ，プログラマーがオブジェクト
指向プログラミングでコーディングしていることになる。反対に，この反
映がなされていなければ，結果的にはクラス指向プログラミングでコーデ
イングしていることになる。
「オブジェクト」と「創発特性」
オブジェクト思考上において，
はなし、。しかし，
r
創発特性」は必ずしも不可欠な概念で
r
オブジェクト指向」と「クラス指向」の違いを明確に
把握できていない設計者には必要となる。
複合体である全体においては，その全体性における特性がみられる。オ
ブジェクト思考上では，オブジェクトは「全体」に対して「部分」に該当
することになるが，この「部分」の潜在的な特性は，
r
全体」の特性の一
l
0
0M 走の陸上選手」の足の特性を「走る」と定
部ではない。例えば， r
「オブPジェクト指向プログラミングJ
. その起源からの検証
1
5
7
義すれば，このオブジェクト「足」は. i
走る」と L、う役割を与えられた
ことになる。しかし，熟考すれば容易に矛盾を発見できるはずである。「足」
走る」のはその陸上選手でしかない。足の創発特性は，
は走りはしない. i
「走る J
.i
歩く
J
.i
座る」等の人間の動作ではなく，これらの動作を可能
にする構造的な特性と一致しなければならない。人間の動作を機能的に分
割し (
p
町 t
i
t
i
o
n
i
n
g
).オブ、ジェクトに各役割を分担させることは，本質的
にはトップダウン方式の構造化設計と何ら変わらない. i(オブジェクト応
用型)構造化設計」でしかない。
6 オフ.ジェクト指向プログラミングの方向性
S泊lUl
aと S
m
a
l
l
t
a
l
kから創造されたのは，単にプログラミング・スタイ
ルとオブジェクト指向技術だけでないことを忘れてはならない。「オブジ
ェクト指向プログラミング」がオブジェクト指向であり続けるためには，
「分析 設計 フ。ログラミング」が思考方法論上でーっとなることが前提
条件となる。この前提条件が歪められれば. S
m
a
l
l
t
a
l
k をプログラム言語
に用いたところで，コーディング段階で強引に「オブジェクト指向」に引
き戻すことは不可能である。オブ、ジェクト指向言語にはオブジェクト指向
(正確には，オブジェクト思考)がその背景にある。プログラム言語は結
果として，コーディング段階においてオブジェクト指向をコンピュータ上
に反映させるための道具にしかすぎず，その道具のみを振り窮したところ
で，コーディングがオブジェクト指向化されるはずもない。たとえ技術解
説書で、あれ，この点を疎かにはするのは，極めて危険である。
本研究では現状を踏まえ，特に以下の二点が. i
オブジェクト指向」の
習得において，重要な鍵となるとの結論に至った。
(
1
) クラス指向プログラミングの概念の普及
オブジェクト指向とクラス指向はプログラミング・スタイル上にお
1
5
8
第1
9巻 第 1号(経済学・経営学編)
いて同ーのものであるが，オブジェクト指向分析/設計を経ていな
ければ，例外なくクラス指向プログラミングとなる。マルチプJレ
・
ビューが完全に満足されなければ，オブジェクト思考はコンピュー
タ(計算機)上には反映されない。コーディング段階で実用主義的
に効率を重視する場合には，
r
クラス指向」の名称を使用し，オブ
ジェクト指向とは別の方向性を持たせた上で，発展的にクラス指向
プログラミングを利用すべきである。
(垣)マルチプル・ビューの徹底
オブジェクト指向開発において，マルチプル・ピューはオブジェク
ト思考をソフトウェア開発に反映できる唯一の手法である。残念な
がら，学術研究以外では，このマルチプル・ビューの重要性に対す
る認識が極めて低 L、。クラス指向開発の場合を除き，開発方法論上
において更なるマルチプル・ビューの徹底が必要である。
総括的には，この上記二点は，オブジェクト指向を本来の軌道に引き戻す
ことを意味しているが，同時に「クラス指向」も発展的に肯定している。
クラス指向は実用主義的な見地に立てば，必ずしも否定されるべきもので
はないし，現時点ではオブジェクト指向よりも実益を上げている。特に，
GUIが必須のサポートとなった現在の PC環境においては， OSを含めて
全てをオブ、ジェクト指向に拘束するよりも，クラス指向のルーズさが逆に
技術者には好まれるであろう。つまり，クラス指向は「クラス指向」とし
て今後大きく発展すべき手法の一つであると考えるべきだろう。
反対に「オブジェクト指向」を更に発展的なものとしていくには，開発
O
b
j
e
c
tT
h
i
n
k
プロジェクト全体に適用できる「オブジェクト思考方法論 (
i
n
g Methodology)J の確立が不可欠である。マルチプル・ビューにおけ
(
1
司極めて少数ではあるが， B
o
o
c
h(1994)，Y
o
u
r
d
o
n(1994)，J
a
c
o
b
s
o
n(1992)等の
分析 設計 プログラミング」を既に単一のオブジェクト思考上
開発方法論は， r
にほぼ統ーしている。しかし，これら総合的な関発方法論であっても，分析段階
でのオブジェクト思考と，設計段階でのオブジェクト思考が完全に同一ではない。
「オブジェクト指向プログラミングJ
. その起源からの検証
1
5
9
る. r
オブジェクト思考(静的ビュー )
J と「プロセス指向(動的ビュー )J
の二層階層は，構造化開発手法に依存してきたソフトウェア技術者達にと
って，必ずしも容易に理解可能なものではない。これはマルチブルービュー
が難解であるのではなく，マルチプル・ビューについて詳細な解説を行な
っているのは，厳密に Booch(
1
9
9
4
)，I
n
g
a
1
l
s(
1
9
8
1
)，Yamamoto(
1
9
9
3
)
程度に限定されており，多くの学術論文でさえ，このマルチプル・ビュー
には敢えて言及していない。これの理由の一端には，オブジェクト指向ブー
ムの初期において，構造化開発手法を拡張した「クラス指向開発手法」が
町・
多数登場したことが影響している1:Booch(1994)，Meyer(1988)，YO
don (
1
9
9
4
)，J
a
c
o
b
s
o
n(
1
9
9
2
) 等のオブジェクト指向開発方法論上におい
ても，この点に関する矛盾に触れているが. r
クラス指向」の実用性を考
オブジェクト指向」の枠から排除しなかった。しかし，上記の結
慮し. r
論を下したように，この弊害が表面化している以上，
r
オブジェクト指向」
と「クラス指向」を明確に差別する必要があろう。
u
1
a と
し か し ， こ れ は 逆 に ， 自 然 淘 汰 の 法 則 に 置 き 換 え れ ば . Sim
S
m
a
l
l
t
a
l
k が創出した「オブ、ジェクト指向」は，現在においては最早必要
とされていないのかもしれなし、。企業レベルでのオブジェクト指向開発を
本格的な普及段階に導くためには，この点に関する研究も方法論上の課題
のーっとして残ろう。現実に. Smal
1
t
a
l
kも初期の独自性の追求から. r
ク
ラス指向」でも利用可能とする方向に徐々に移行しつつある。
ERモデリングのエンティ
E
n
t
i
t
y
) の概念とそのデータ・モデリングに，ピヘピアー(振る舞 L、)を
ティ (
追加し，オブジェクト・モデルとして利用し，強引に「オブジェクト指向」と称
した手法である。
同 これは Sm
a
1
l
士a
l
kを，例えば.
W
i
n
d
o
w
s上での開発環境に適応させるためには，
Sma
1
l
t
a
l
kの実行環境やクラス・ライブラリー等を Windows側の構造に適合させ
る必要性から起こっている。本来の S
m
a
l
l
t
a
l
k の実行環境である VM (
V
i
此
u
a
1
M
a
c
h
i
n
e
) を，非オブジェクト指向 OSの Windows上へ移行するのは，理論的
. 賢明な方法とも考え難 L、。この意味では. Sm
a
1
l
t
a
l
k も生き残
にも困難であ 9
Pをかけ. r
理想主義」から「実用主義」へと方向転換し始めた。
(
1
6
) この代表的な例は，構造化関発上で利用されていた
1
6
0
第1
9
巻 第 1号(経済学・経営学編)
7 結びにかえて
最後に，現時点でオブジェクト指向開発に移行すべきか，本研究の検証
の範圏内において結論を引き出す。
最終的には，開発プロジェクト全体が移行する場合，
r
オブジェクト指
向」と「クラス指向」の二つの選択肢が含まれ，また，ユーザの想定も必
要であるため，ポイントを五つに絞って，以下の質問形式に置き換えて行
う
。
(
a
) オブジェクト指向開発を選択する理由は何か?
1
9
崎年を境にして 1
9
8
0年代後半から始まったオブジェクト指向ブー
ムが災いして，オブジェクト指向開発とオブジェクト指向ソフトウ
ェアは驚異的な勢い偶像化されてしまっている。このブームの聞に
様々な比較データ等が数多く発表されているが，大多数のものは構
造化プログラミングに対するクラス指向プログラミングの有効性を
(
18
)
部分的に立証できたにすぎなし、。
企業レベルでオブジェクト指向開発が本格化するためには，現在
COBOL でコーディングされていた専門業務処理部分，又は
F
o
r
t
r
a
nで計算していた処理等に対しての比較が必要となる。しか
まで
し汎用機を土俵にして，現在汎用機上で動作しているアプリケー
ションを比較対象にした場合，現時点ではオブジェクト指向プログ
Cも
P
a
s
c
a1も汎用機版が存在しているが，汎用機上では C
OBOLと F
o
r
t
r
a
n
，又は 4
GLが主要言語なのである。つまり， Cや P
a
s
c
a1といっ
ラミングは間違いなく惨敗する。忘れてはならないのは，
(
1
8
) 構造化プログラミングは特に GUI等のインターフェイス構築に不向きであり，
Sm
a
1
l
t
a
1
k がオブジェクト指向言語として誕生した背景にこの問題が大きく関係
している。 GUI をベースにした比較データは， GUI に不向きな構造化プログラ
ミングと， GUI を含むインターフェイスにおいて最大の効果を発揮するクラス
指向プログラミングを比較する，極めて偏ったものである。
「オブジェクト指向プログラミングJ，その起源からの検証
1
6
1
た PCとワークステイションの主要言語は，汎用機上では COBOL
とF
o
r
t
r
a
nとの比較対象とはなりえない。 C++や O
b
j
e
c
tP
a
s
c
a
l
でF
o
r
t
r
a
nと計算処理速度を競うことは無意味であり，汎用機上の
主要言語争いで、 COBOLに敗退した Cや P
a
s
c
a
lを，単にオブジェ
クト指向化しただけで、は何の優位性も生じなし、。
重要なことは，オブジェクト指向開発を過信してはならなし、。オ
ブジェクト指向開発されたソフトウェアが，全てにおいて高い再利
用性を発揮するわけではない。又，オブジェクト指向ソフトウェア
の再利用性を飛躍的に向上させる手法が確立されているわけでもな
い。オブジェクト指向開発よりも現状では，構造化開発のほうが，
プロジェクト管理，ツール，手法，方法論，技術者等の点において
成熟度で優る。現時点では， PC やワークステイシヨン上を除き，
オブジェクト指向開発は構造化開発が困難を生じるケースに限定
し，主要言語にオブジェクト指向プログラミングをサポートされる
のを待つべきであろう。
(
b
) オブジェクト指向プログラミングが必要な根拠は何か?
オブジェクト指向プログラミングにのみ興味が生じた場合，制約の
少ないクラス指向プログラミングを採用する方向を先ず優先させる
べきであろう。特に， PC やワークステイションが対象機である場
合，主要な選択肢であるプログラム言語はクラス指向プログラミン
グを採用すべきである。 PC-OS とワークステイション OSの多く
は，オブジェクト指向ではなく，クラス指向ソフ Vウェアである。
SDKや DDKを利用し開発する必要があるソフトウェアであれば，
クラス指向プログラミングが必須である。
(
c
) 設計手法はオブジェクト指向なのか?
ウォータ・ホール型のオブ、ジェクト指向開発を採用する場合，オブ
1
(
的 オブジェクト指向プログラミングによって速度面の向上を期待してはならな
い。メッセージ転送のボトルネックが大きく，速度的にはむしろ低下する。
第1
9
巻 第 1号(経済学・経営学編)
1
6
2
ジ ェ ク ト 指 向 設 計 が 非 常 に 重 要 な も の と な る 。 例 え ば ， RDD
(
R
e
s
p
o
n
s
i
b
i
l
i
t
y
D
r
i
v
e
nD
e
s
i
g
n
) はオブジェクト指向設計手法であ
ると位置づける研究者もいるが， RDD は典型的なクラス指向設計
手法である。 RDDはオブジェクトが本来有する創発特性は無視し
トップダウン方式でオブジェクトの役割を定義する動的ビューのみ
のシングル・ピュー手法である。オブジェクト指向開発の設計段階
において RDDを用いれば，必然的にクラス指向開発に転換されて
しまう。オブジェクト指向開発を厳密に行おうとするならば，
RDDに代表されるクラス指向設計を排除する必要がる。
(
d
) 採用するオブジェクト指向開発方法論に矛盾はないか?
一部の統合型開発方法論を除いて，オブジェクト指向の手法同士で
矛盾が起こらなし、かどうか検証しておく必要がある。上記の RDD
が典型的な実例となるが，マルチプル・ビューを前提とした分析手
法では，オブジェクトの抽出とその定義に，システム中での役割を
オブジェクトに負荷することはないが， RDD では逆にオブジェク
トに役割を分担させるアプローチをとるため，分析結果が正しく反
映されない。
(
e
) コード再利用を過信していないか?
オブジェクト指向プログラミングと構造化フ。ログラミングを「コー
ドの再利用性向上を促進する支援技術」の視点、から比較すれば，オ
ブジェクト指向プログラミングが優る。しかし， Y
ourdon (1994，
PP.74-79)の調査を参考にすれば，開発プロジェクト中において
コーデイングが占める割合はわずか 10-15%で あ ￡ つ ま り ， コ 一
。
例分析手法と設計手法の間に，思考方法論的な矛盾が、生ずるケースがある。
)
1 この割合は開発プロジェクト・チームの総合的なレベルによって大きく異な
oehm(
1
9
8
3
) の調査が裏付けするように，分析と詳細な仕様書を
る。しかし， B
含む設計を重視した開発プロジェクトのほうが，デパッグを含むコーディング時
間とコーディング・コストを大幅に圧縮できる。 Y
o
u
r
d
o
n(198θ) は，このコー
ディングが占める割合から，関発チームの総合力をある程度評価可能と指摘して
いる。
「オブジェクト指向プログラミングJ，その起源からの検証
1
6
3
ド再利用性だけの開発プロジェクト全体に対する貢献度は極めて低
い。又，開発プロジェクト全体においてコーディングが三割を大き
く超えるようなケースでは，オブジェクト指向開発に移行する以前
に，開発プロジェクトそのものを効率化する必要がある。
ここにおいて，今一度熟考すべきは，
r
オブジェクト指向プログラミン
グとは何を意味するのか ?
Jであろう。オブジェクト指向プログラミング
とクラス指向プログラミングの聞に明確な境界線を引くならば，オブジェ
クト指向プログラミングの必要性すら見えてこな L、。プログラミングの効
率を追求するのであれば，現在と同様にクラス指向プログラミングで事足
りる。
オブジェクト指向プログラミングが，
r
クラス指向」ではなく，厳密に
「オブジェクト指向」である意義は，オブジェクト指向開発の中にしかな
い。オブジェクト指向設計で書き出される詳細仕様書がオブジェクト指向
であれば，使用するプログラム言語においてオブジェクト指向プログラミ
ングが可能であればよい。使用するプログラム言語の違いが，開発プロジ
ェクト全体に及ぼす影響は，現実的にはわずかなものでしかない。 B
i
g
-
1
9
9
1
) が指摘するように，真の意味でオブジェクト指
g
e
r
s
t
a
f
fと Lubars(
向の再利用性が必要なのは，分析と設計段階においてである。
参考文献
B
i
g
g
e
r
s
t
a
f
f
，T
.
]
.a
n
dL
u
b
a
r
s，M.D
.(
19
9
1
)R
e
c
o
v
e
r
i
n
gandR
e
u
s
i
n
gS
o
f
t
w
a
r
e
D
e
s
i
g
n
:G
e
t
t
i
n
gMoreM
i
l
e
a
g
ef
r
o
mYourS
o
f
t
w
a
r
eA
s
s
e
t
s，
A
m
e
r
i
c
a
匁P
r
o
g
r
a
m
，
M
a
r
c
h
.
mer
B
i
r
t
w
i
s
t
l
e，G
.，D
a
h
l，0
]
.，Myhrhaug，B
.如 dNygard，K
.(
1
9
7
9
)Sim
担l
aB
e
g
i
匁.
S
t
u
d
e
n
t
l
i
t
t
e
r
a
t
u
r，
S
w
e
d
e
n
.
Boehm，B
.W. (
19
8
3
)S
o
f
i
以l
a
r
eE
n
g
i
n
e
e
r
i
担:
gE
c
o
n
o
m
i
c
s
，2nd e
d
.P
r
e
n
t
i
c
e
H
a
1
1
，
EnglewoodC
l
i
f
f
s，
N
]
.
1
6
4
第1
9
巻 第 1号(経済学・経営学編)
Booch，G
.(
1
9
8
6
)O
b
j
e
c
t
O
r
i
e
n
t
e
dD
e
v
e
l
o
p
m
e
n
t，IEEES
o
f
t
w
a
r
e，Vo
l
.1
2，2，
F
e
b
r
u
a
r
y
.
Booch，G
.(
1
9
8
7
a
)S
o
f
t
w
a
r
eC
0
1
ゆ 即e
n
お w
i
t
hADA: S
t
r
u
c
t
u
r
e
，T
o
o
l
s
，a
n
dS
u
b
日o
出 a
.
s
y
s
t
e
m
s
.Benj組 曲/Cummings，Ca
Booch，G
.(
1
9
8
7b)伽 t
h
eC，仰向がSo
fO
b
j
e
c
t
-O
r
i
e
n
t
e
dD
e
s
i
g
n
.R昌t
i
o
n
a
l，D
e
n
v
e
r
:
CO.
.(
1
9
8
9
)Wh
a
t1
sa
n
dWh
a
t1
s
n
'
tO
b
j
e
c
t
-O
r
ie
n
t
e
dD
e
s
i
g
n，
A
m
e
r
i
c
a
nP
r
o
・
Booch，G
grammer
，Vol
.2，
7
8，
Summer.
Booch，
G
.(
1
9
9
4
)O
b
j
e
c
t
-α
τientedDesignwithApplications，2nded.Benjamin/Cumma
l
i
f
o
r
n
i
a
.
i
n
g
s，C
.a
n
dYourdon，E
.(
1
9
9
1
)O
b
j
e
c
t
-O
r
i
e
n
t
e
dA
n
a
l
y
s
i
s，2nd e
d
.P
r
e
n
t
i
c
e
H
a
1
l
，
Coad，P
EnglewoodC
l
i
f
f
s
:N
J
.
L
.L
.(
1
9
9
0
)O
b
j
e
c
t
O
r
i
e
n
t
e
da
n
dF
u
n
c
t
i
o
n
O
r
i
e
n
t
e
dS
o
f
t
w
a
r
eS
t
r
u
c
C
o
n
s
t
a
n
t
i
n
e，
t
u
r
e，C
m
n
.
戸t
t
e
rLa
n
g
u
a
g
e，
Janu
ぽ y
，
p
p
.3
4
5
6
.
Cox，B
.J
.(
1
9
8
7
)O
b
j
e
c
t
-O
r
i
，側 t
e
dPr
ogramm
初i
g
:AnE
v
o
l
u
t
i
o
n
a
r
yA
.
ρ
l
j
J
r
o
a
c
h
.AdU
.S
.A
.
dison-Wωley，
B
.J
.(
1
9
9
0
)There1
saS
i
l
v
e
rBu
1
l
e
t，
BYTE
，
McGraw-H
i
l，O
c
t
o
b
e
r
.
Cox，
Cox
，B
.J
.叩 dN
o
v
o
b
i
l
s
k
i
，J
.A. (
1
9
9
1
)O
b
j
e
c
t
0
1
ぜ
e
n
t
e
dPr
o
g
r
a
m
m
i
n
g
:Aη E
v
o
l
u
仰
，a
r
y
A
.
企p
r
o
a
c
h，2nde
d
.A
d
d
i
s
o
n
W
e
s
l
e
y，
U.S
.A
.
t
i
1
吐
， 0，
J and Nygaard，K
.(
1
9
6
6
)S
i
n
叫 a-an A
LGOL-based S
i
m
u
l
a
t
i
o
n
Da
Language，C
m
n
m
u
n
i
c
a
t
i
o
no
fACM
，
N
o
.9，
p
p
.6
7
1
6
7
8
.
，0J
"M
yrhaug
，B
.andNygaard，K
.(
1
9
6
8
) SIMULA67C仰 z
m
o
nB
a
s
e
D出 1
La
沼郡a
g
e
.Norwegian，
ComputingC
e
n
t
r
e，
O
s
l
o
.
D
a
h
l，
0J
.(
1
9
8
7
)O
b
j
e
c
t
O
r
i
e
n
t
e
dS
p
e
c
出c
a
t
i
o
n
s
.1
nS
c
h
r
i
v
e
r，
B
.a
n
dWegner，
P
.
(
e
d
s
)R
e
s
e
a
r
c
hDi
r
e
c
t
i
o
n
si
nO
b
j
e
c
t
-Or
i
e
n
t
e
d丹 o
g
r
a
m
m
i
n
g
，M1TP
r
e
s
s，Camb
r
i
d
g
e
:MA.
D
i
j
k
s
t
r
a，
E
.W.(
1
9
7
9
)ProgrammingC
o
n
s
i
d
e
r
e
da
saHumanA
c
t
i
v
i
t
y
.1
nYourdon，
E
.(
e
d
.
)C
l
a
s
s
i
c
si
nS
o
f
t
w
a
r
eE
n
g
i
n
e
e
r
i
n
g
，YourdonP
r
e
s
s，
NY.
G
o
l
d
b
e
r
g，
A
.andKay，
A
.(
19
7
6
)S
m
a
l
l
t
a
l
k
7
2
1
n
s
t
r
u
c
#
開 M
a
n
u
a
l
.XeroxP
a
l
oAl
t
o
，C
a
l
i
f
o
r
n
i
a
.
R
e
s
e
a
r
c
hC
e
n
t
e
r
G
o
l
d
b
e
r
g，
A
.andKay
，
A
.(
1
9
7
7
)M
e
t
h
o
d
s
f
o
rT
e
a
c
h
仇i
gt
h
ePr
ogramm
勿!
gLa
n
，
t
gω
!
g
e
.
勿l
k
.XeroxP
a
l
oAl
t
oR
e
s
e
a
r
c
hC
e
n
t
e
r，
C
a
l
i
f
o
r
n
i
a
.
Smal
G
o
l
d
b
e
r
g
，
A
.(
1
9
7
8
)S
m
a
l
l
t
a
l
ki
nt
h
eC
l
a
s
s
r
o
0
1
弘 X
eroxP
a
l
oAl
t
oR
e
s
e
a
r
c
hC
e
n
t
e
r，
C
a
l
i
f
o
r
n
i
a
.
A
.andRobson，
D
.(
19
8
3
)S
m
a
l
l
t
a
l
k
8
0
:TheLa
n
g
z
ω:
g
eandl
i
お1
m
ρ
J
ωz
e
n
G
o
l
d
b
e
r
g，
R
e
a
d
i
n
g
.
t
a
t
i
o
n
.Addison-Wesley，
「オブジェクト指向プログラミングJ
，その起源からの検証
1
6
5
G
o
l
d
b
e
r
g
，A.(
1
9
8
4
)Sm
a
1
1
t
a
1
k
:The1
n
t
e
r
a
c
t
i
v
eProgrammingE
n
v
i
r
o
n
m
e
n
t
.Add
i
s
o
n
W
e
s
l
e
y，
R
e
a
d
i
n
g
.
G
o
l
d
b
e
r
g
，A
.a
n
dPope，S
.(
19
8
9
)O
b
j
e
c
t
-O
r
i
e
n
t
e
dP
r
ogrammingI
sNotEnough，
Ame
r
i
c
a
nPr
o
g
r
a
m
m
e
r
，
Vo
l
.2，
No7
8
.
G
o
l
d
b
e
r
g，A. (
1
9
9
0
)TamingO
b
j
e
c
t
-O
r
i
e
n
t
e
dT
e
c
h
n
o
l
o
g
y，C
o
m
p
u
t
e
rL仰 伊a
g
e
，
Vo
l
.7
，1
0
.
l
n
g
a
l
l
s，D
.(
19
8
1
)D
e
s
i
g
nP
r
i
n
c
i
p
l
e
sB
e
h
i
n
dSma
1
1
t
a
l
k，BYTE
，A
u
g
u
s
t
.
1
n
g
a
l
l
s，
D
.(
1
9
8
3
)TheE
v
o
l
u
t
i
o
no
ft
h
eS
m
a
l
l
t
a
1
kV
i
r
t
u
a
1M
a
c
h
i
n
e
.1
nK
r
a
n
s
e
r
，G
.
(
e
d
.
)S
m
a
l
l
t
a
l
k
8
0
:B
i
t
so
fH
i
s
t
o
r
y
，Wor
ゐo
fA
d
v
i
c
e
，A
d
d
i
s
o
n
W
e
s
l
e
y
，U
.
S
.A
.
J
a
c
o
b
s
o
n，1
.(
1
9
9
2
)O
b
j
e
c
t
-O
r
i
e
n
t
e
dS
ψ担J
a
r
eE
n
g
i
n
e
e
r
i
n
g
:A U
s
eC
a
s
eDr
i
v
e
nA
p
d
d
i
s
o
n
w
e
s
l
e
y，
U.S
.A
.
p
r
o
a
c
h
.A
Ka
d
i
e，C
.(
1
9
8
6
)R
，
併ηe
m
e
n
tThr
ω
，:
g
hC加 蹴:AD
e
v
e
l
，
柳 !
e
n
tM
e
t
h
o
d
o
l
o
g
yf
o
rOb
・
j
e
c
t
-Or
i
e
n
t
e
dLangzω~es. U
n
i
v
e
r
s
i
t
yo
fI
1
l
i
n
o
i
s，
U
r
b
a
n
a
:1
L
.
Kn
u
d
s
e
n，J
.叩 dMadsen，O
.(
1
9
8
8
)T
e
a
c
h
i
n
gO
b
j
e
c
t
O
r
i
e
n
t
e
dProgrammingi
s
e
a
c
h
i
n
gO
b
j
e
c
t
O
r
i
e
n
t
e
dProgrammingL
a
n
g
u
a
g
e
s，
Pr
o
c
e
e
d
i
n
g
宮o
f
more白 叩 t
8
8
:E
u
r
o
p
e
a
ηC
仰 i
f
e
r
e
n
c
e仰 O
b
j
e
c
t
-砂 i
閥 均'
dP
r
o
g
r
a
m
m
i
:
η
i
g
，Spr
・
ECOOP'
i
n
g
e
r
V
e
r
l
a
g
，
NewY
o
r
k
.
K
r
a
n
s
e
r，G
.(
19
8
1
)TheS
m
a
l
l
t
a
l
k
8
0V
i
r
t
u
a
1M
achine，BYTE
，A
u
g
u
s
t
.
，B
.(
19
8
7
)R
e
u
s
a
b
i
l
i
t
y
:TheC
a
s
ef
o
rO
b
j
e
c
t
O
r
i
e
n
t
e
dD
e
s
i
g
n，
AEESψ
Meyer
w
a
r
e，Vo
l
.4，2
，M
a
r
c
h
.
Meyer
，
B
.(
1
9
8
8
)O
b
j
e
c
t
-O
r
i
e
n
t
e
dS
o
f
t
w
a
r
eC
o
n
s
伽 c
t
i
開
， .P
r
e
n
t
i
c
e
-H
a
l
l，
NewY
o
r
k
.
，
B
.(
1
9
8
9
)FromS
t
r
u
c
t
u
r
e
dProgrammingt
oO
b
j
e
c
t
O
r
i
e
n
t
e
dD
e
s
i
g
n
:T
h
ε
Meyer
t
r
u
c
t
u
r
e
dP
r
o
g
r
a
m
m
i
n
g
，Vo
l
.1
0，1
.
Roadt
oE
i
f
f
e
l，S
Minsky，
M.A
.(
1
9
7
5
)AFrameworkF
o
rR
e
p
r
e
s
e
n
t
i
n
gK
n
o
w
l
e
d
g
e
.1
nW
i
n
s
t
o
n，
P
.
(
e
d
.
)T
hePs
y
c
h
o
l
o
g
yo
fG仰 ψu
t
e
rV
i
s
i
仰， N
Y:McGrawH
i
l
l
.
，
Nygaard，
K
.a
n
dD
a
h
l，
0J
.(
1
9
8
1
)TheD
e
v
e
l
o
p
m
e
n
to
ft
h
eS
i
m
u
l
aL
a
n
g
u
a
g
e
s
.1
n
W
e
x
e
l
b
l
a
t，R
.(
e
d
.
)H
i
s
t
o
r
yo
fPr
o
g
r
a
m
m
i
n
gLa
n
g
u
a
g
e
s，AcademicP
r
e
s
s，NY.
Nygaard，
K
.(
19
8
6
)B
a
s
i
cC
o
n
c
e
p
t
si
nO
b
j
e
c
t
O
r
i
e
n
t
e
dProgramming，
SIGPLAN
Vo
l
.2
1，1
0
.
N
o
t
e
s，
.，Bl油a
，M.，P
r
e
m
e
r
l
a
n
i，W Eddy
，F
.叩 dL
o
r
e
n
s
e
n(
1
9
9
1
)O
b
Rumbaugh，J
ν
i
e
n
t
e
dM
o
d
e
l
:
初i
gandD
ω伊 z
.P
r
e
n
t
i
c
e
H
a
l
l，EnglewoodC
l
i
飽， N
，
J
j
e
c
t
G
吋
Schmucker，
K
.(
1
9
8
6
)O
b
j
e
c
t
-Or
i
抑
，制 Programming
f
o
rt
h
eM
a
c
i
n
t
o
s
h
.Hayden，
N
J
.
S
t
a
n
d
i
s
h，
T
.(
19
8
3
)S
o
f
t
w
a
r
eReuse，
P
r
o
c
e
e
d
i
n
g
so
f
t
h
eW
o
r
k
s
h
o
po
nR
e
z
仰 b
i
l
i
t
y仇
P
r
o
g
r
a
m
m
i
n
g
，ITT，S
t
r
a
t
f
o
r
d
.
S
t
r
o
u
s
t
r
u
p，B
.(
1
9
8
6
)T
he C++ P
r
o
g
r
a
m
m
i
n
gLa
n
g
u
a
g
e
. Addison-Wesley，
R
e
a
d
i
n
g
:MA.
1
6
6
第1
9
巻 第 1号(経済学・経営学編)
Webster
，B
.F
.(
19
9
5
) 民 抑l
ゐ0
1O
b
j
e
c
t
・
αienfedDevelψ
，m
e
n
t
.P
r
e
n
t
i
c
e
-Ha
l
1
，
EnglewoodC
l
i
丘s
，
N
]
.
W
i
r
f
s
B
r
o
c
k
，R
. andJ
o
h
n
s
o
n，R
.(
1
9
9
0
)S
u
r
v
e
y
i
n
gC
u
r
r
e
n
tR
e
s
e
a
c
hi
nO
b
j
e
c
t
O
r
i
e
n
t
e
dD
e
s
i
g
n，C
o
m
m
u
n
i
c
a
t
i
o
n0
1幼eACM
，V
o
l
.
3
3，9，S
e
p
t
e
m
b
e
r
.
W
i
r
f
s
B
r
o
c
k，R
.a
n
dWi
1
k
e
r
s
o
n，B
.(
1
9
8
9
)O
b
j
e
c
t
-O
r
ie
n
t
e
dD
e
s
i
g
n
:A R
e
s
p
o
n
s
i
b
i
l
i
t
y
D
r
i
v
e
nA
p
p
r
o
a
c
h，SIGPLANN
o
t
i
c
e
s
，Vo
l
.2
4，1
0，O
c
t
o
b
e
r
.
W
r
i
f
s
B
r
o
c
k
，R
.，W
i
l
k
e
r
s
o
n，B
.a
n
dWiener，L
.(
1
9
9
0
)D
e
s
i
g
n
i
n
gO
b
j
e
c
t
-Or
抑制
S
，qβw
a
r
e
.P
r
e
n
t
i
c
e
H
a
l
1
， EnglewoodC
l
i
f
f
s，N
J
.
Y創 namoto，
M.(
1
9
9
3
)P
o
t
e
n
t
i
a
lO
b
j
e
c
tA
n
a
l
y
s
i
s
.P
h
.D
.T
h
e
s
i
s，
U
n
i
v
e
r
s
i
t
yo
fW訂・
w
i
c
k
.
Yourdon，E
.(
1
9
8
9
)O
b
j
e
c
t
-O
r
ie
n
t
e
dO
b
s
e
r
v
a
t
i
o
n
s，
A
m
e
r
i
c
a
nPr
o
g
r
a
m
m
e
r
，Vo
l
.2
，
7
8，
Summer.
Yourdon，E
.(
1
9
9
0
a
) Au
1
d LangS
y
n
e
:i
n STATE OFTHEART
，BYTE
，
McGraw-H
i
l，
O
c
t
o
b
e
r
.
Yourdon
，E
.(
1
9
9
0
b
)O
b
j
e
c
t
O
r
i
e
n
t
e
dCOBOL
，A
m
e
r
i
c
a
nPr
o
g
r
a
m
m
e
r
，V
o
l
.
3，2，
F
e
b
r
u
a
r
y
.
Yourdon，E
.(
1
9
9
0
c
)I
nS
t
r
u
c
t
u
r
e
d Ana1
y
s
i
sa
n
dO
b
j
e
c
t
-O
r
i
e
n
t
e
d Ana1
y
s
i
s，
，ACMP
r
e
s
s，
NewYor
k
.
OOPSLA'90
Yourdon，
E
.(
1
9
9
4
)O
b
j
e
c
t
-砂 '
i
e
n
t
e
dS
y
s
t
e
mD
e
s
i
g
却:AnI
n
t
e
g
r
a
t
e
dA
p
p
r
o
a
c
h
.P
r
e
n
t
i
c
e
H
a
l
l，
E
n
g
l
e
w
o
o
dC
l
i
f
f
s，
N
J
.
吉田弘一郎(19
9
4
)r
オブジェクト指向狂詩曲」技術評論社。