オブジェクト指向アプローチによるソフトウェアの...
TRANSCRIPT
オブジェクト指向アプローチによるソフトウェアの開発
牧 野 真 也
目 次
０．はじめに
１．構造化アプローチの概要と特徴
１．１ 構造化アプローチの登場とその発展
１．２ 構造化アプローチのモデル化手法
１．３ 構造化アプローチの特徴
２．オブジェクト指向を実現する基盤技術
２．１ オブジェクト指向の基本的枠組み
２．２ オブジェクト指向の基盤技術とその発展
３．オブジェクト指向アプローチの概要と特徴
３．１ オブジェクト指向分析
３．２ オブジェクト指向設計
３．３ オブジェクト指向アプローチの特徴と優位性
４．おわりに－今日の情報システムの課題とオブジェクト指向
０．はじめに
今日，情報システムの構築，とりわけその主要な構成要素であるソフトウェ
アの開発においては，そのあらゆる局面において構造化手法（ structured
technique）が広く採用されている。一方，近年のオブジェクト指向技術
（object-oriented technology）の発展と普及には注目すべきものがあり，実現の
ための基盤技術の発展やさまざまな開発方法論の提案が行なわれている。本稿
の目的は，オブジェクト指向によるソフトウェアの開発について整理すること
にある。そのために，まず構造化手法によるソフトウェアの開発の概要と特徴
を把握し（第１章），その後にオブジェクト指向を実現する基盤技術について
（第２章），さらにオブジェクト指向によるソフトウェアの開発について概観
しその特徴を構造化手法と比較する（第３章）。最後に今日の情報システムの
課題とオブジェクト指向の有効性についてまとめる（第４章）。
本文－1
１．構造化アプローチの概要と特徴
１．１ 構造化アプローチの登場とその発展
1960年代末頃から，情報システムの構築においてソフトウェアの開発費用の
増大が顕著となり，これが情報システム構築のボトルネックになるのではない
かという問題意識，いわゆるソフトウェア危機（software crisis）がとりあげら
れるようになってきた。当初，ソフトウェア危機は，その大規模化への対応が
中心的課題であったが，その後，開発件数の増大や品質の問題に重点を移しつ
つも今日に至るまで継続して重要な課題となっている(1)。
ソフトウェア危機への対策としてソフトウェアの開発に対する体系的アプロー
チ，すなわちソフトウェア工学（software engineering）が提唱された(2)。その中
で今日まで，常に中心的役割を果たしてきたのが，さまざまな構造化手法を組
み合わせてソフトウェアを開発するアプローチである。これを本稿では構造化
アプローチ（structured approach）と呼ぼう。構造化アプローチはソフトウェア
に整然とした構造を持たせることによりこれらの問題に対応しようとしたもの
で，1970 年代はじめの Dijkstraらによる構造化プログラミング（ structured
programming）やデータ構造化（data structuring）にその始まりを見ることがで
きる (3) 。 そ の 後 ， 構 造 化 設 計 （ structured design ） (4)， そ し て 構 造 化 分 析
（structured analysis）(5)へと手法の上流化が行なわれた。さらに近年においては
リアルタイムシステムに対応したリアルタイム構造化分析（real-time structured
analysis）(6)への拡張や，データベース設計法との融合が行なわれ，さまざまな
領域のソフトウェアが構造化アプローチによる開発の対象となっている。それ
と同時に構造化アプローチを支える情報処理技術においても発展，成熟が見ら
れた。構造化コーディング（structured coding）のためのプログラミング言語(7)
や，データ管理のためのデータベース管理システム（database management
system : DBMS），とくに近年においては関係データベース管理システム
（relational DBMS : RDBMS）(8)は構造化アプローチのための基盤技術を確立し
本文－2
ている。また，1980年代後半から，ソフトウェア開発のライフサイクル（ life
cycle ） 全 般 に わ た っ て 構 造 化 ア プ ロ ー チ を 計 算 機 で 支 援 す る CASE
（computer-aided software engineering）ツール(9)が普及しはじめ，これらはソフ
トウェアの開発における生産性向上に貢献している。
１．２ 構造化アプローチのモデル化手法
構造化アプローチでは，ソフトウェアの開発において，分析，設計，コーディ
ング，テスト，運用保守などの段階に厳密に分割したウォータフォールモデル
（waterfall model : 落水モデル）と呼ばれるライフサイクルを採用している（図
１．１）。それぞれの段階では，問題領域（problem domain）を，基本的には
処理的側面とデータ的側面に分けてとらえ，処理的側面を中心に(10)，それぞれ
の側面に対応したさまざまなモデル化が行なわれ，主として図式で表現される
成果物を作成する。以下，ソースコード作成までの段階，すなわち(1)分析，
(2)設計，(3)コーディングについてそのモデル化手法や成果物の表記法を中心
に概観する(11)。
図１．１＞(1) 分析段階
分析段階では，問題領域を分析し開発すべきソフトウェアの定義を行なう。
構造化分析においては，リアルタイムシステムの場合，処理的側面は機能的側
面と制御的（時間的）側面に分けてとらえられる。すなわち，問題領域は機能
的側面，制御的側面，データ的側面の３つの側面でモデル化される。
機能的側面のモデル化は「データフロー図（data flow diagram : DFD）」がそ
の中心となる。これは対象問題においてデータが流れる様子をモデル化したも
ので，データの経路を表わす「データフロー（data flow）」，データの変換を
表わす「プロセス（process）」，データの蓄積を表わす「データストア（data
store）」，対象とするシステムにかかわる外部の組織や人などを表わす「デー
タ源泉／吸収（data source/sink）」から構成される。DFDは，「コンテキスト
ダイアグラム（context diagram : CD）」と呼ばれる単一のプロセスから構成さ
れた最も抽象的なDFDを最上位として段階的に詳細化される。単機能に詳細化
本文－3
されたプロセスはその仕様を「プロセス仕様書（process specification : PSPEC，
またはミニ仕様書）」に構造化文（structured English）など (12)を用いて記述さ
れる。またデータフローはその構造を「データ辞書（data dictionary : DD）」(13)
に正規表現（regular expression）を用いて記述される（図１．２）。
図１．２＞制御的側面のモデル化は，Hatleyらの方法とWardらの方法により若干の違い
が見られるが，それぞれDFDと１対１で対応する「制御フロー図（control flow
diagram : CFD）」(14)あるいはDFDを拡張した「変換図（transformation schema）」
を用いて制御の流れを表わし，「状態遷移図（state transition diagram : STD）」，
「プロセス起動表（process activation table : PAT）」などで制御の流れに対応す
るプロセスの活性化，非活性化のロジックを表現する。
データ的側面は，一般的には「実体関連図（entity-relationship diagram : ERD）」
で表現される(15)。これは問題領域における実体とそれらの関連とその数量的対
応，また実体の属性（attribute）を表現する。実体関連図における実体はDFDに
おけるデータストアと通常１対１で対応する。
構造化分析ではDFDを中心的ツールとして問題領域を分析し，現行物理モデ
ル，現行論理モデル，将来論理モデル，将来物理モデルの作成が順次行なわれ
る。以下に例として「酒類販売業の在庫管理問題」(16)のDFDをあげる（図１．
３）。
図１．３＞(2) 設計段階
設計段階は分析段階の成果物を実現可能な形態へ変換する過程である。すな
わち，実現可能なプログラミング言語，DBMSやその他の基本ソフトウェア(17)
の構造にあわせた変換が行なわれる。
機能的または制御的側面，すなわち処理的側面は，構造化設計により，モジュー
ルの階層構造とモジュール間のインタフェイスを記述した構造図（structure
chart : SC）へと変換される。DFDなどからSCへの変換を機械的に行なうことは
困難であるが，トランザクション分析（ transaction analysis ）や変換分析
（transform analysis）などの方法が提案されている(18)。また，主にPSPECをも
本文－4
とに，個々のモジュールをどのようなアルゴリズムとデータ構造で実現すべき
かを，構造化プログラミングの３つの基本制御構造である連接（sequence），
選択（selection），反復（iteration）の階層構造として設計する。PAD，HCP，
SPD，YACIIなどの木構造チャート(19)や疑似コード（pseudo-code）がよく用い
られる（図１．４）。
図１．４＞データ的側面，すなわちERDは，データベーススキーマ（database schema）
やファイルのレコード形式（record format）に変換される。今日ではRDBMSが
多く用いられるが，その場合，ERDや関係スキーマの正規化（normalization）
が行なわれ，データの重複や更新異状が排除されたスキーマが設計される。
(3) コーディング
設計段階の結果を直接実現可能なコードへ変換する過程である。一般的には，
処理的側面，すなわち構造図や木構造チャートは構造化コーディングを支援す
るプログラミング言語を用いて，データ的側面すなわちデータベーススキーマ
やそれらに対するトランザクションはデータベース言語（database language）(20)
を用いて実現される。
１．３ 構造化アプローチの特徴
構造化アプローチの特徴について，そのモデル化手法を中心にまとめてみよ
う。
１つめの特徴としては，モデル化の過程が全般的にトップダウン的であるこ
とがあげられる。構造化アプローチの中心となっている考え方は分割統治
（devide and rule）や段階的詳細化（stepwise refinement）であり，これは対象問
題をまず高い抽象度でとらえその後に段階的に詳細化していく。２つめとして，
その結果構築されるモデルが階層的な形態となっていることがあげられる。
DFDやCFD， 構造図，木構造チャートなど多くのモデル化の過程はトップダウ
ン的であり，その結果構築されるモデルの形態は階層的である。また，ライフ
サイクルにおいてもこの考え方は採用されている。すなわち，ウォータフォー
ルモデルは抽象度の高い段階から低い段階へトップダウン的に変換していく過
本文－5
程とみることができる(21)。３つめとして，モデル化の視点が対象問題の側面や
ライフサイクルの段階によってさまざまであることがあげられる。対象問題は
処理的側面，データ的側面に分割されモデル化される。またライフサイクルの
進展にともない，順次，抽象度の低いモデルへの変換が行なわれる。この結果，
ライフサイクルは一方向的になり，後戻りは困難になる。
こうした構造化アプローチの特徴に対して，これまで多くの批判があった。
トップダウン的過程や階層的モデルはその硬直性が批判の対象となった。例え
ば，重要な判断をソフトウェア開発の早い時期で行ない固定化しなければなら
ないことや，新たな要求に対する変更が困難であることがあげられている(22) 。
また，近年では，モデル化の視点がさまざまであることに対する批判もある。
モデル間の整合性の維持が困難であることや，その抽象度の変換，とくに分析
段階から設計段階へのギャップは大きな問題である(23)。
また，こうした欠点に対応した手法もいくつか提案されてきた。JSD
（Jackson System Development）法 (24) などのオペレーショナル・アプローチ
（operational approach）はその代表であろう。しかしながら，Adaなど直接的な
実現に有用な基盤技術が普及してないことや，多くの面で図式的でなくわかり
にくい(25)という欠点もあり，ヨーロッパ以外ではあまり普及していないようで
ある。
構造化アプローチの問題は多いが，これにかわる総合的で有力なアプローチ
は次章以降述べるオブジェクト指向の登場までなかったともいえよう。
２．オブジェクト指向を実現する基盤技術
オブジェクト指向では，実世界を人間が認識する「もの」を中心として計算
機上にモデル化しようとする。こうした考え方は，1960年代後半から1970年代
前半にかけて計算機科学のいくつかの分野で生まれた(26)。近年になってオブジェ
クト指向の考え方を採用した，プログラミング言語，DBMS，オペレーティン
本文－6
グシステム（operating system : OS），通信ネットワークによる分散システム
（distributed system），グラフィカルユーザインタフェイス（graphical user
interface : GUI）など基盤技術の発展，オブジェクト指向分析（object-oriented
analysis），オブジェクト指向設計（object-oriented design）などソフトウェア開
発方法論の提案などが活発に行なわれ，情報処理技術全般にわたって構造化ア
プローチにかわる一大潮流となっている。オブジェクト指向技術を全面的に採
用しソフトウェアの開発を行なうアプローチを本稿ではオブジェクト指向アプ
ローチ（object-oriented approach）と呼ぼう。本章では，オブジェクト指向の基
本的枠組みと基盤技術について概観する。
２．１ オブジェクト指向の基本的枠組み
まず，オブジェクト指向の基本的枠組みとその機構を説明する。オブジェク
ト指向に関する解説(27)やオブジェクト指向を実現しているプログラミング言語
などの処理系は非常に多くあり，そこで支援されている機構や用語には若干の
違いがある。ここでは，オブジェクト，オブジェクト間の関連，メッセージの
３つに分類し説明を試みる。
(1) オブジェクト
オブジェクトは，データと処理をカプセル化（encapsulation）したもので，
オブジェクト指向においてはこれがソフトウェアを構成する基本単位となる。
これは，構造化アプローチを含めて，これまでのソフトウェアに対する基本的
枠組みが，データと処理を分離していたことと大きく異なる。実世界に存在す
る「もの」は，データ的側面と振る舞い的側面の両方を兼ね備えており，こう
したモデル化は自然であるといえる。例えば，「従業員」というオブジェクト
は，「社員番号」，「氏名」，「性別」，「資格」などのデータ的側面をもつ
と同時に，「退職する」，「昇進する」，「給与を計算する」といった振る舞
い的側面をもっている。また，人間が認識する実世界の「もの」と計算機上に
実現されるオブジェクトは概ね一対一で対応し，このことにより実世界を直接
的にモデル化できるようになる。
本文－7
オブジェクトに内在するデータ的側面を属性（attribute）と呼び，振る舞い
的側面をメソッド（method）と呼ぶ(28)。一般に内部のデータへのアクセスはメ
ソッドを通じて行なわれ，外部から直接アクセスすることを禁じられている場
合が多い (29)。こうした情報隠蔽（information hiding）により，オブジェクト内
部へのアクセスが限定され高いモジュール性が実現される。
(2) オブジェクト間の関連
オブジェクトは以下に説明するいくつかの関連により組織化される。
i) クラスとインスタンス
同じ性質をもつオブジェクトが複数存在する場合，それらをまとめて抽象化
したオブジェクトをクラス（class）という。オブジェクトがあるクラスの要素
であること強調する場合それをインスタンス（ instance）と呼ぶ。例えば，
「従業員」はクラスであり，「鈴木太郎」，「佐藤花子」など個々の従業員は
インスタンスである。クラスとインスタンスは相対的であり，クラスをさらに
抽象化したクラスであるメタクラス（meta-class）を採用している処理系もある
(30)。
ii) 全体－部分関連
あるインスタンスがその部分を表わす別のインスタンスにより構成されてい
る場合，これらのインスタンスの間に全体－部分（whole-part）関連があると
いう。組立物とその部品，容器とその内容物，組織とその下部組織，集合とそ
の要素などがこれに該当する(31)。例えば，「自動車」と「タイヤ」「エンジン」
「車体」などがある。
iii) 汎化－特化関連
あるクラスを特化したものが別のクラスになっている場合，これらのクラス
の間に汎化－特化（generalization-specialization）関連があるという。上位概念と
下位概念の関連がこれに該当する。例えば，「人間」－「従業員」－「管理職」
などがある。クラスは汎化－特化関連により階層構造をもつ。ここで，あるク
ラスから見ての上位にあるクラスを上位クラス（super-class），下位にあるク
本文－8
ラスを下位クラス（sub-class）と呼ぶ。下位クラスは上位クラスの属性とメソッ
ドを共有することができる。これを継承（inheritance） (32)という。継承には，
上位クラスが１つに限定されている単一継承（simple inheritance）と，複数の上
位クラスの設定が可能な多重継承（multiple inheritance）がある(33)。
iv) 参照関連
インスタンス間に関連があり，全体－部分関連に該当するほど意味的に強い
関連がない場合，これらのインスタンスの間に参照（reference）関連があると
いう。例えば，「従業員」が「自動車」を保有する，などがある
オブジェクト指向ではこれらの関連を用いて実世界をオブジェクトを人間の
認識に近い形態で組織化できる。また，継承の機構は，新規のクラスを定義す
る場合，既存の類似したクラスの下位クラスとすることにより，上位クラスと
の差分のみを定義すればよい。このことにより再利用性の向上が期待できる。
(3) メッセージ
オブジェクトに処理を依頼する唯一の方法はメッセージ（message）の送信
である。メッセージを受信したオブジェクトは，それに対応したメソッドを起
動する。オブジェクト指向はこうしたメッセージの送信の連鎖で一連の処理を
行なう。
同一のメッセージであっても，それを受信するオブジェクトによって異なる
動作をさせる機構をポリモーフィズム（polymorphism : 多態性）という。例え
ば，「管理職」と「技術職」で給与の計算方法が異なっている場合でも，「給
与を計算せよ」という同じメッセージを送信することにより，それぞれ正しい
計算が実行される。ポリモーフィズムを実現するための機構として，再定義
（overriding），多重定義（overloading），遅延束縛（late binding，あるいは動
的束縛：dynamic binding）の３つがある。再定義は，上位クラスのメソッドを
下位クラスで定義し直すことであり，多重定義は，異なるクラスで同じ名前の
メソッドをもつことである。遅延束縛は，これら再定義，多重定義されたメソッ
ドのなかから，メッセージを受信したオブジェクトにとって，もっともふさわ
本文－9
しいメソッド(34)を，実行時に動的に選択し起動する機構である。なお，ポリモー
フィズムには単一のオブジェクトによりメソッドを決定する単純ポリモーフィ
ズム（simple polymorphism）と，メッセージに関連する複数のオブジェクトに
よりメソッドを決定する多重ポリモーフィズム（multiple polymorphism）があ
る(35)。以下に「従業員の給与計算」の例をあげポリモーフィズムがもたらす利
点を示そう（図２．１）。
図２．１＞ポリモーフィズムによってアプリケーションプログラムのコード量をかなり
少なくすることができると同時に，処理のインタフェイスもSalaryのみに統一
できる。また，例えば「秘書（Secretary）」という職種が追加されても，オブ
ジェクト指向の場合クラスSecretaryを新規のクラスとして定義することだけ
（もちろんクラス定義の一部としてのメソッドSalaryも）が必要で，プログラ
ムコードは全く修正しなくてもよい。従来の場合はプログラムコードに
Secretaryへの条件分岐がさらに必要になる。メッセージとポリモーフィズムに
よるオブジェクト間の統一的なインタフェイスは，拡張性に優れた柔軟なソフ
トウェアを提供する。
２．２ オブジェクト指向の基盤技術とその発展
オブジェクト指向の枠組みにしたがってソフトウェアを実現する際の基盤技
術として，オブジェクト指向プログラミング言語とオブジェクト指向データベー
ス管理システムを中心に概観する。
(1) オブジェクト指向プログラミング言語
オブジェクト指向プログラミング言語（object-oriented programming language :
OOPL）はオブジェクト指向の枠組みにしたがったプログラミング言語であり，
オブジェクト指向を実現する基盤技術の中心となる。今日のOOPLの基礎を築
いたともいえる1970年始めのSmalltalk(36) 以降，さまざまなOOPLが提案，開発
されている（図２．２）。
図２．２＞OOPLは，独自の構文に基づくものと，既存の普及しているプログラミング
言語を拡張したものとに大別することができる。前者を純粋型，後者をハイブ
本文－10
リッド型と呼ぼう。純粋型にはSmalltalk， Eiffel(37)などがあり，ハイブリッド型
には，C言語を拡張したC++(38)やObjective-C(39)など，Lisp系のFlavors，LOOPS，
CLOS(40)など，Pascalを拡張したObject Pascal(41)など，Prologを拡張したESP(42) な
どがある。最近では，事務処理分野の標準プログラミング言語COBOLを拡張
したObject-Oriented COBOL(43)もある。かつてOOPLは，純粋型が多かったが，
近年はハイブリッド型が主流となっている。これは，かつて構造化手法の普及
にともないCOBOLやFortranが構造化されてきた過程と似ている。ハイブリッ
ド型は，純粋型の問題であったプログラミングの修得や既存の資産の継承を解
消する可能性があり，既存のプログラミング言語から段階的に移行していくこ
とが可能である。また，C++とCLOSがそれぞれANSIのX3J16，X3J13委員会に
お い て ， Object-Oriented COBOL が CODASYL のOOCTG （ Object-Oriented Cobol
Task Group）においてそれぞれ活発な標準化活動がなされていることは特筆す
べきことであろう。OOPLは，言語によって多少の違いはあるものの，オブジェ
クト指向の基本的枠組みのほとんどを何らかの形で支援している(44)。
(2) オブジェクト指向データベース管理システム
オ ブ ジ ェ ク ト 指 向 デ ー タ ベ ー ス 管 理 シ ス テ ム （ object-oriented DBMS :
OODBMS）はオブジェクト指向の枠組みをデータモデルとして採用したDBMS
であり，次世代のDBMSとして注目されている。とくにRDBMSの適用が困難
であった複雑なデータを扱う応用分野，例えばCAD（computer-aided design），
CASE，地図情報システム（geographical information system : GIS），マルチメディ
アシステム（multi-media system）などに有効であることが指摘され，近年では
適用例もいくつか報告されている(45)。
OODBMSの研究と商品化は米国を中心に1980年代後半から始まり，とくに
1990年代に入って多くの商用OODBMSが開発されている。OODBMSはそのデー
タベース言語によりいくつかに分類することができる。まず，RDBMSにおけ
るSQLのように特定の言語に依存しない言語中立的（language nutral）なデータ
ベース言語を採用しているOODBMS，例えばO2がある(46) 。特定の言語を拡張
本文－11
したデータベース言語を採用しているOODBMSとして，Smalltalkを採用してい
るGemStone(47)，Common Lispを採用しているORIONプロトタイプ，またその商
品化であるITASCA(48) ，そして，今日これが最も多いが，C++を採用した，
ONTOS(49)，VERSANT(50)，ObjectStore(51)，ODE(52)，Objectivity/DB(53)などがある。
また，主に1990年以降商品化されたOODBMS(54) の特徴として，UNIXワーク
ステーションを中心とする分散ネットワーク環境に対応したマルチサーバ／マ
ルチクライアント（multi-server/multi-client）のDBMSであることや，RDBMSや
それ以前のOODBMSと比較してかなりパフォーマンスが向上している(55)ことな
どがあげられ，それらは大規模な実用システムへの適用が可能なものとなって
いる。
OODBMSが具備すべき機能について整理したものとして，「オブジェクト指
向データベースシステム宣言（The Object-Oriented Database System Manifesto）」
(56)がよく知られており，多くのOODBMSもこれに準拠した機能を提供している。
ここでは，OOPLやRDBMSと比べてOODBMSに特徴的な機能といえる，永続性
（persistence），複合オブジェクト（complex object），オブジェクト識別性
（object identity），設計トランザクション（design transaction）について簡単に
説明する。
i) 永続性
プログラムが終了してもオブジェクトが保持されていることを永続性という。
多くのOODBMSでは，オブジェクトのクラスと永続性が独立的で，永続性はク
ラスに関係なくインスタンス単位で指定できる。このことにより，オブジェク
トをその物理的位置に関係なく透過的に扱うことができるようになり，
RDBMSなどでは問題となっていたインピーダンス不整合（impedance mismatch）
(57)を解消できる。とくにマルチサーバシステムにおいてはオブジェクトがどの
計算機上にあるかということも利用者は意識しなくてよい。以下にObjectStore
におけるインスタンスの宣言と生成をあげるが，C++の記憶クラスにデータベー
スが追加されたような構文になっている（表２．１）(58)。
本文－12
表２．１＞ii) 複合オブジェクト
オブジェクトに配列，リスト，集合などの構成子を繰り返し適用し，複雑な
データを直接的に表現したものを複合オブジェクトという。RDBMSではその
データに正規性をもとめられるため，こうした表現は直接的には不可能であっ
た。また，ITASCAやVERSANTなどでは，全体－部分関連を構成する複合オブ
ジェクトをあたかも１つのオブジェクトのように扱う機構を備えている(59)。
iii) オブジェクト識別性
オブジェクトをその値でなく存在そのもので識別できる能力のことをオブジェ
クト識別性という。RDBMSではタプル（tuple）を値により区別しており，全
く同じ属性値をもつものを区別するために本質的には不要な属性をもたなけれ
ばならないことが多々あった(60)。OODBMSではそれぞれのオブジェクトはオブ
ジェクト識別子（object identifier）をもち，これはシステムによって管理され利
用者は意識しなくてもよい。
iv) 設計トランザクション
多くのOODBMSでは，設計アプリケーションのために共有化される複雑なデー
タのための，これまでのDBMSにはなかったトランザクションを提供している。
ONTOSなどでは「入れ子トランザクション（nested transaction）」が提供され，
入れ子構造のオブジェクトに対するトランザクションにおいて完全性が保証さ
れる。また，ITASCA，VERSANT，ObjectStoreなどでは，「長時間トランザク
ション（long-duration transaction）」(61) が提供され，複数の利用者が，同時に同
じデータに対して長時間のトランザクションを行なうことが可能となっている。
これらのトランザクションは近年注目されているグループウェア（groupware）
などのための基盤技術となる(62)。
(3) その他の基盤技術とオブジェクト指向
プログラミング言語，DBMSのほかにも，さまざまな分野でオブジェクト指
向の考え方が採用されている。
本文－13
OS，とくに分散システムにおけるオブジェクト指向分散OSの研究が盛んで
ある(63)。複雑化するOSに対して，オブジェクト指向の高いモジュール性によ
る安全性と統一されたインタフェイスは有効である。
GUIにおいては，X window，MS Windows，Macintoshなどのツールキットに
おいてオブジェクト指向的考え方が多く採用されている。C++，CLOS，
SmalltalkによるGUIも多く存在する(64)。実世界を直接的にモデル化するオブジェ
クト指向は，ユーザインタフェイスを開発する側にとっては生産性の向上を，
利用する側にとっては使いやすさをそれぞれ提供する(65)。また，マルチメディ
アデータの蓄積，管理のための機構としてOODBMSは有力である(66)。
大規模化，複雑化，多機種化する分散ネットワーク環境においても，オブジェ
クト指向を適用しようとする動向が見られる。今日，分散システム実現の基盤
技術となっているRPC（remote procedure call）を中心とするサーバ／クライア
ントモデルは，大規模な分散システムには，とくに管理の点などで対応が困難
である(67)。例えばOMG（Object Management Group）では，オブジェクト指向を
用いて異機種分散ネットワーク環境における高い相互運用性（interoperability）
を実現するための標準化活動が行なわれている(68)。
オブジェクト指向はデータ管理，ユーザインタフェイス，ネットワークなど
今日のソフトウェア開発における重要な基盤技術において広範に利用されつつ
ある。これらはまた，オブジェクト指向アプローチにより開発されるソフトウェ
アを直接的に実現するための基盤技術となっているのである。
３．オブジェクト指向アプローチの概要と特徴
構造化分析や構造化設計が構造化手法によるソフトウェアを実現するのため
の上流工程として展開されてきたように，オブジェクト指向においても基盤技
術の発展とともに，その分析法や設計法も発展してきた。とくに近年において
は，ShlaerとMellorのオブジェクト指向システム分析（Obejct-Oriented System
本文－14
Analysis） (69) ， Wassermanらの OOSD（ Object-Oriented Structured Design ） (70) ，
JacobsonのObjectOry(71) ，BoochのOOD(72) ，RumbaughらのOMT（Object Modeling
Technique）(73)，CoadとYourdonのOOA(74)，OOD(75)など有力な手法が数多く提案
されており，CASEツールもいくつか開発されつつある(76)。本章では，Coadと
YourdonによるOOAとOODについて概観し，最後にオブジェクト指向アプロー
チの特徴を整理する。
３．１ オブジェクト指向分析
OOAでは，オブジェクト指向の枠組みにしたがって対象問題を分析，定義す
る。CoadとYourdonのOOAでは，５つの活動（activity），すなわち「クラスと
オブジェクト」の発見（finding Class-&-Objects），「構造」の同定（ identifying
Structures），「サブジェクト」の同定（identifying Subjects），「属性」の定義
（defining Attributes），「サービス」の定義（defining Services）が行なわれ，
その結果はそれぞれレイヤー（ layer）として特定の表記法に従って示される
（図３．１）。
図３．１＞ここではそれぞれの活動の内容について簡単に見ていこう。なお，この方法
論では「戦略（Strategy）」と称されるそれぞれの活動におけるかなり詳細な
手順が提案されている。
(1) 「クラスとオブジェクト」の発見
「クラスとオブジェクト（Class-&-Object）」とは，クラスとそれに属するオ
ブジェクト群，すなわちクラスとインスタンスを同時に表現したものである。
インスタンスを持たないクラスは表記法が異なる。ここでは問題領域中の適切
な「クラスとオブジェクト」を発見する。この活動の結果，「クラスとオブジェ
クト・レイヤー（Class-&-Object layer）」が作成される。
(2) 「構造」の同定
「構造」とは「クラスとオブジェクト」間の関連のことで，「構造」を同定
することにより(1)で抽出された「クラスとオブジェクト」は組織化される。
「構造」には，クラス間の構造である「Gen-Spec構造」，すなわち汎化－特化
本文－15
関連と，オブジェクト間の構造である「Whole-Part構造」，すなわち全体－部
分関連がある。「Gen-Spec構造」をラティス構造にすること，つまり多重継承
の記述が許されている。「Whole-Part構造」ではオブジェクト間の数量的対応
も記述する。この活動の結果，「構造・レイヤー（Structure layer）」が作成さ
れる。
(3) 「サブジェクト」の同定
「サブジェクト」とは「構造」に基づき，問題領域全体を分割したものであ
る。問題領域が非常に大きい，すなわち「クラスとオブジェクト」が非常に多
い場合，これらをいくつかの部分に分割しわかりやすくする。この活動の結果，
「サブジェクト・レイヤー（Subject layer）」が作成される。
(4) 「属性」の定義
個々の「クラスとオブジェクト」が持つデータを定義する。また，「インス
タンス結合（Instance Connection）」，すなわちオブジェクト間の参照関連とそ
の数量的対応もここで定義される。この活動の結果，「属性・レイヤー
（Attribute layer）」が作成される。
(5) 「サービス」の定義
「サービス」とはオブジェクトに特有な振る舞い，すなわちメソッドのこと
である。ここではそれぞれの「クラスとオブジェクト」の「サービス」を定義
する。「オブジェクト状態図（Object State Diagram）」が作成され，「属性」
の値の変化とそれに対する振る舞いが分析される。必要な「サービス」の定義
と，「メッセージ結合（Message Connection）」，すなわちオブジェクト間の
メッセージによる関連づけが行なわれる。この活動の結果，「サービス・レイ
ヤー（Service layer）」が作成される。(4)の「属性」と「サービス」の詳細は，
「クラスとオブジェクトの仕様書（Class-&-Object Specification）」に記述され
る。そこでは「サービス」の記述に，「サービスチャート（Service Chart）」
と称されるフローチャートの一種が使用される。
これらの活動は，(1)～(5)の順に紹介されているが，必ずしもこの順番で行
本文－16
なわれるわけではない。高い抽象度のモデルと低い抽象度のモデルを適宜行き
来しながら分析が行なわれる。そのために，レイヤーは透明なプラスティック
（clear plastic）のようになっており，任意のレイヤーを自由に重ね合わせて表
現できるようになっている(77)。以下に１章でもとりあげた「酒類販売業の在庫
管理問題」の分析結果の一例をあげる（図３．２）。
図３．２>３．２ オブジェクト指向設計
OODでは，OOAと同じ形態のモデルを用いて，OOAの結果をもとに，実現環
境への適合，すなわち実現のための基盤技術であるプログラミング言語，
DBMS，GUI などを意識したモデルの修正や追加が行なわれる。 Coadと
YourdonのOODモデルは４つのコンポーネント（Component）と呼ばれる構成要
素，「問題領域コンポーネント（Problem Domain Component：PDC）」，「ヒュー
マンインタラクションコンポーネント（Human Interaction Component：HIC）」，
「タスク管理コンポーネント（Task Management Component：TMC）」，「デー
タ管理コンポーネント（Data Management Component：DMC）」から成り立って
おり，それぞれのコンポーネントに対応した設計活動が行なわれ，その結果は
OOAと同じ表記法に従って示される（図３．３）。
図３．３＞ここではそれらの内容について簡単に見ていこう。なお，OODにおいても
「戦略」と称されるそれぞれの活動におけるかなり詳細な手順が提案されてい
る。
(1) PDCの設計
基本的にはOOAの結果を検証したものをそのまま用い，主に以下のような追
加，修正が行なわれる。
i) 再利用可能な（Off-the-shelf）クラスを追加し，それに適合させる。
ii) 問題領域特有のクラスをまとめて再利用可能な形にする。
iii) サービスを共有化するための一般的なクラスを追加する。
iv) 継承のレベルを対象プログラミング言語にあわせる。
v) パフォーマンスを改良する。など。
本文－17
(2) HICの設計
エンドユーザとのインタラクションのための必要なクラスの追加が概ね以下
のような手順で行なわれる。
i) PDCにおけるエンドユーザを表わす「クラスとオブジェクト」をさまざ
まな観点で検討し分類する。
ii) i)のエンドユーザのタスクシナリオを記述する。
iii) コマンド階層や詳細なインタラクションを設計する。
iv) プロトタイプを作成しエンドユーザの意見を反映する。
v) 使用するGUIにあわせてクラスを設計する。など。
(3) TMCの設計
マルチタスクシステムのための設計を行ない，クラスの追加を行なう。
(4) DMCの設計
オブジェクトの格納，参照のためのデータ管理機構を設計する。ファイルシ
ステム，RDBMS，OODBMSが設計の対象となっているが，OODBMSとくに
OOPLを拡張したデータベース言語を採用しているものにおいては，そのため
の修正を必要とせず，そのままの形態でのデータ管理が可能である。
なお，この方法論では，OODの結果に対する評価基準（OOD Criteria）につ
いても提案されており，そこでは，構造化設計などで用いられる結合度
（coupling）と凝集度（cohesion）をOODに適用したものが紹介されている。
OODの結果に基づきコーディングが行なわれるが，そこでは，オブジェクト
指向に基づく基盤技術，すなわちOOPL，OODBMS，オブジェクト指向のGUI
などを用いることにより設計の結果をそのまま実現できる。この方法論では，
OOPLの選択方法について，計算機の負荷，再利用性，クラスライブラリなど
の点から述べられている。
３．３ オブジェクト指向アプローチの特徴と優位性
オブジェクト指向アプローチの特徴について，そのモデル化手法，すなわち
モデル化の過程，モデルの形態，モデル化の視点の３点についてまとめよう。
本文－18
モデル化の過程は，対象領域に存在する個々のオブジェクトを発見しそれら
を組織化していくという過程をとり，多分にボトムアップ的である。モデルの
形態は，実世界に対する人間の認識に即した形態をとっており，個々のオブジェ
クト間の関連はかなり自由度がある。モデル化の視点については，分析，設計，
コーディングのあらゆる段階において一貫してオブジェクト指向の枠組みに基
づいている。
これは，１．３ですでに見たように，構造化アプローチのモデル化の過程，
モデルの形態，モデル化の視点がそれぞれトップダウン的，階層的，多面的で
あることと大きく異なっている。以下に構造化アプローチとオブジェクト指向
アプローチを比較した表をあげる（表３．１）。
表３．１＞オブジェクト指向のこれらの特徴は，ソフトウェアの開発において以下のよ
うな利点をもたらす。
(1) 人間にとって理解性が高く，表現力の高いモデルである。
実世界に即した単一のモデルによる直接的なモデル化は，人間，とくにソフ
トウェアの非専門家にとって理解しやすいばかりか，複雑な問題に対する高い
表現力を提供する。
(2) 拡張性に優れている。
カプセル化と情報隠蔽による高いモジュール性と，メッセージやポリモーフィ
ズムによる統一的なインタフェイスを提供するモデルは，ソフトウェアの高い
拡張性と柔軟な再組織化を可能にする。これに加えて，ボトムアップ的な過程
と単一の視点によるモデル化は，ライフサイクルにおいて継ぎ目のない
（seamless）段階間の移行と，漸増的なソフトウェア開発を可能にする。構造
化アプローチにおけるライフサイクル，すなわちウォータフォールモデルが逐
次的で後戻りが困難であることに対して，オブジェクト指向アプローチにおい
ては回遊形態（round-trip gestalt）のライフサイクルが可能になるのである (78)
（図３．４）。
図３．４＞(3) 再利用性に優れている。
本文－19
オブジェクト間の統一的なインタフェイスに加え継承の機構は，再利用性の
高いモデル化を可能にする。またボトムアップ的なモデル化の過程は，トップ
ダウン的過程と比べて，ライフサイクルのあらゆる段階において，より再利用
を促進する。
４．おわりに－今日の情報システムの課題とオブジェクト指向
本稿では，オブジェクト指向の基盤技術およびアプローチの特徴を構造化ア
プローチと比較しながら見てきた。最後に，今日の企業における情報システム
（以下，企業情報システム）の特徴として，(1)大規模化，複雑化への対応，
(2)保守の問題への対応，(3)増力化の支援の３つをあげ，それぞれとオブジェ
クト指向について簡単に考察したい。
(1) 大規模化，複雑化への対応
今日の企業情報システムは，その対象とする業務範囲の拡大や，内容の高度
化，さらには業務間の統合化などにより著しく大規模化，複雑化しつつある。
今日では百万ステップオーダのソフトウェアも決して珍しくない(79)。こうした
傾向に対して構造化アプローチは構造化分析など上流工程を重視し，正確な要
求分析とシステム定義によりその品質を保ってきたと考えられるが，本来大規
模で複雑な問題においては，開発の早い段階でその範囲や機能を決定すること
がかなり困難である。オブジェクト指向アプローチのボトムアップ的で漸増的
な開発過程が有効であろう。
(2) 保守の問題への対応
ソフトウェアの保守の問題はますます深刻なものとなりつつある。近年にお
いては，「ソフトウェアの新規開発のコストと保守のコストの割合はほぼ半々
である」という報告もある(80)。また，一般的に保守の内容はエラーの修正より
も機能の拡張である場合が多い(81)。構造化アプローチにおいて機能の拡張は，
本質的に分析段階からの再構築ということになる。これに対して，オブジェク
本文－20
ト指向アプローチのライフサイクルにおいては，ソフトウェアが逐次拡張され
ることを前提としている。すなわちオブジェクト指向アプローチでは，保守は
ソフトウェアが完成に至るまでの単なる１ステップに過ぎないのである。
(3) 増力化の支援
戦略的情報システム（strategic information system : SIS）(82)や統合OA(83)など，
近年の企業情報システムにおいては，競合優位の獲得やオフィスワーカの知的
能力の増大など，いわゆる増力的観点が重視されている。これは従来のシステ
ムが，省力化や効率化などの観点を重視していたことと大きく異なる。増力化
のための情報システムの構築にあたっては，エンドユーザ自身の業務に対する
理解やノウハウがとくに重要であり，その計画，分析，設計，実現，運用など
さまざまな段階においてエンドユーザの積極的な参加が求められる。すなわち，
エンドユーザ自身の情報システムに対する深い理解と，それを構築し運用して
いく能力が重要なものとなるのである。そしてそこでは，オブジェクト指向が
提供する高い理解性や拡張性が有効にはたらくことが期待されるのである。
これらの課題に対するオブジェクト指向の適用例や成功例はこれまでのとこ
ろあまり報告されていない。しかしながら，近い将来，オブジェクト指向技術
はこれらの課題に対する有効でかつ一般的な解答となることが期待されるので
ある。
本文－21
注
１．１
(1) 文献16（中所）。
(2) ソフトウェア危機およびソフトウェア工学という言葉は，1968年からのNATO
Science Commitee主催のソフトウェア技術者の会合により初めて提唱された。文献34
（河村），pp.31—50。
(3) 文献21（Dijkstra et al.）。
(4) 文献69（Yourdon et al.），文献50（Page-Jones）。
(5) 文献18（DeMarco），文献22（Gane et al.）。
(6) 文献61（Ward et al.），文献27（Hatley et al.）。
(7) 今日においては，PASCAL， PL/I， Cなど本来構造化されている言語だけでは
なく，COBOL， FORTRANなども構造化コーディングの機能をもった言語として標
準化されている。
(8) 文献13（Codd），文献41（増永91）。
(9) 構造化アプローチを採用しているCASEツールは，StP， Teamwork， SAVER，
CARDtools， KangaTool など数多く商品化されている。
１．２
(10) これとは違って，近年ではデータ的側面を中心にソフトウェアを開発する方法
論，例えばインフォメーション・エンジニアリングなどがある。文献38（Martin）。
近年はこうしたデータ中心（data oriented）のアプローチが注目されているが，こ
れは後述するオブジェクト指向（object-oriented）への過渡的段階であると考えられ
よう。
(11) 詳細は前述した各手法の原著や，構造化アプローチについて体系的に説明して
いる多くの出版物，文献20（Dickinson），文献70（Yourdon），文献51（Peters），
文献71（Yourdon），文献72（Yourdon）などを参考にされたい。
(12) 構造化文は，システムの仕様を記述するために自然言語に一定の制約を設けて
あいまいさをなくしたものである。またPSPECにはその他，決定表，原因結果グラ
フ，第４世代言語，数式なども用いられる。
(13) 最近の方法では，データ辞書にはデータフローを含め構造化アプローチで用い
られるあらゆる要素が記述される。その意味で，要求辞書，ライフサイクル辞書と
呼ばれることもある。
(14) 実際のCASEツールにおいてはDFDとCFDを単一の図式で表わすものが多い。
(15) ERDはChenによりデータモデリングの手法として提案され，その後多くの改良
が加えられている。文献10（Chen）。
なお，データ的側面の分析にはワーニエ－オール図，データ構造図，バックマン
ダイアグラムなどが用いられることもある。
(16) 1984年から1985年にかけて，情報処理学会誌においてさまざまな設計技法が紹
注－1
介されたが，それらの共通問題として用いられたものである。文献65（山崎）。
(17) 例えばユーザインタフェイス設計など。
(18) 文献50（Page-Jones），邦訳pp.199—236。
(19) 文献29（石井），pp.110—139。
構造化されたJIS新規格（JIS X0121）のフローチャートも有用である。
(20) データベースのデータ定義やデータ操作を行なう言語で，RDBMSにおいては
SQLが国際的に標準化されている。文献17（Date）。
１．３
(21) 文献4（有沢），pp.7—15。
(22) 1982年にACM SIGSOFTのSoftware Engineering Notes誌において繰り広げられた
ものが有名である。この中でMcCrackenらとGladdenは，本文中の観点で構造化アプ
ローチを批判している。文献42（McCracken et al.），文献23（Gladden)。
また有沢はこの一連の論争を「ライフサイクル有害説」として紹介している。文
献3（有沢），pp.17—20。
(23) 文献11（Coad et al.），pp.1—2，文献12（Coad et al.），pp.20—21。
(24) 文献31（Jackson）。
(25) 文献53（Rumbaugh et al.），pp.295—296。
２．
(26) オブジェクト指向のルーツとして，離散事象シミュレーション言語Simula
（1968），オブジェクト指向の基本的概念を確立したプログラミング言語Smalltalk
（1972），並列処理のためのACTORモデル（1972），人工知能の知識表現フレーム
（1975）などがあげられる。文献67（米沢）。
２．１
(27) オブジェクト指向を全般的に解説したものとして，文献26（春木），文献63
（Winblad et al.），文献59（Tayor）をあげておく。
(28) 属性，メソッドの呼称はプログラミング言語によってさまざまである。例えば，
Smalltalkでは変数，メソッド，C++ではメンバ（あるいはデータメンバ），メンバ
関数，CLOSではスロット，メソッドと称されている。
(29) Smalltalkでは内部データへ外部から直接アクセスすることは禁じられているが，
C++では私的メンバ，公開メンバを指定できる。CLOSでは，メソッドが複数のオ
ブジェクトに関連する多重メソッドを採用しているためカプセル化自体が行なわれ
ない。
(30) Smalltalk， CLOSなどで採用されている。
(31) 文献11（Coad et al.），pp.93—99。
(32) C++では導出（derivation）と称されている。
(33) Smalltalkでは単一継承が，CLOS，C++などでは多重継承が支援されている。
注－2
(34) CLOSではこれを実効メソッド（effective method）という
(35) CLOSでは，多重ポリモーフィズムが支援されている。
２．２
(36) 文献52（Pinson）。
(37) 文献43（Meyer）。
(38) 文献58（Stroustrup）。
(39) 文献14（Cox）。
(40) 文献57（Steele）。
(41) 文献54（Schmucker）。
(42) 文献15（近山）。
(43) Micro Focus社の"OO Option Framework"など一部商品化されている。
(44) 厳密にいえば，「全体－部分関連」と「参照関連」はほとんどのOOPLで明示
的に区別されていない。
(45) OODBMS 適 用 例 と し て は ， マ サ チ ュ ー セ ッ ツ 工 科 大 学 の MagpieBridge
（GemStoneを利用）：建築家と構造技術者の協調設計作業の支援（1989），南カリ
フォルニア大学のCbase（Vbaseを利用）：VLSI回路論理設計の支援（1989），
VIEWLogic社のVIEWLogic Schematic Editor（ObjectStoreを利用）：プリント基盤の
ECAD（1990），Index Technology社のExcelerator（ONTOSを利用）：CASEのリポジ
トリ（1990），Fluent Machine社のFM/1 Multimedia Development System（ONTOSを利
用）：マルチメディアシステム開発支援（1990）など多く報告されている。
また，エンジニアリング分野におけるOODBMSのRDBMSに対する優位性は，文
献2（Ahmed et al.）によくまとめられている。
(46) 文献19（Deux et al.）。オブジェクト指向的な拡張がなされているRDBMS，例
えばIRISなどもここに分類されるかも知れない。
(47) 文献55（Servio）。
(48) 文献30（Itasca）。
(49) 文献49（Ontologic）。
(50) 文献60（Versant）。
(51) 文献46（ObjectDesign）。
(52) 文献1（Agrawal et al.）。
(53) 文献47（Objectivity）。
(54) ベンダ（開発販売社）によるややセールストーク的表現ではあるが第２世代
OODBMSと称されている。
(55) Cattelによるエンジニアリング分野向けのベンチマークテストによると，最近の
OODBMSは条件によってはRDBMSより数十倍から数百倍速い。文献9（Cattel）。
(56) 文献5（Atkinson et al.）。
(57) RDBMSを利用する場合，データベース言語SQLをPL/I，COBOLなどの親言語に
埋め込んで用いるが，SQLの記述方法が宣言的であり，処理方法が集合中心となっ
注－3
ているため，手続き的でレコード中心の処理をする親言語との間に不整合が発生し，
アプリケーション開発上の問題点となっている。文献7（Bancilhon et al.）。
(58) 文献6（Atwood et al.）。
(59) 全体－部分関連におけるオブジェクト間の依存関係を表現でき，それに基づい
た完全性の管理が行なわれる。文献36（Kim et al.）。
(60) 例えば，部品のデータベースなどで全く同じ部品が複数個ある場合，新たにキー
となる属性を設定しなければならない。
(61) 一般には，データベースを共有されるものと個人用のものに分割し，共有デー
タベースから個人用データベースへのオブジェクトのチェックアウトが行なわれ，
しかるべき修正をしたのち，共有データベースに新たなバージョンとしてチェック
インされる。文献35（Kim）。
(62) 文献24（Greif et al.）。
(63) 文献66（横手）。
(64) 例えば，InterViews，ET++，CLUE，Application Frameworksなど。
(65) 文献38（牧村）。
(66) 文献40（増永90）。
(67) 文献68（吉田）
(68) 文献48（OMG）。
３．
(69) 文献56（Shlaer et al.）。
(70) 文献62（Wasserman et al.）。
(71) 文献31（Jacobson）。
(72) 文献8（Booch）。
(73) 文献53（Rumbaugh et al.）。
(74) 文献11（Coad et al.）。
(75) 文献12（Coad et al.）。
(76) CoadとYourdonのOOAを支援するObject International のOOAToolや富士ゼロック
ス情報システムのObjectCastなどさまざまななものがある。
また，StPにおけるOOSDや，Teamworkのオブジェクト指向システム分析など構造
化アプローチに基づくCASEツールにオブジェクト指向分析／設計の機能を付加し
たものもいくつかみられる。
３．１
(77) CASEツールの利用を強く意識しているといえよう。
３．３
(78) 文献8（Booch），pp.187—219。Henderson-Sellersらもこれとほぼ同様の「噴水
モデル（fountain model）」と称するライフサイクルを，羽生田は海洋モデルと称す
注－4
るライフサイクルをそれぞれ提案している。それぞれ，文献28（Henderson-Sellers et
al.），文献25（羽生田）。
４．
(79) 例えば，1980年代後半に開発された銀行の第３次オンラインシステムの規模は
1千万ステップ以上ともいわれている。
(80) 日経コンピュータ誌が1990年に東証１部上場企業など1214社に対して行なった
調査によると，新規開発のコストが52.7%であるのに対して保守のコストは47.3%
であった。文献44（日経コンピュータ）。
(81) Lientzらによると保守の内容は，エラー修正が約18%であり，その他ユーザ要求
の変更，パフォーマンスの向上などが82%を占める。文献37（Lientz et al.）
(82) 文献64（Wiseman）など。
(83) 文献33（事務と経営），文献45（日経コンピュータ）など。
注－5
文 献
1. Agrawal, R. and Gehani, N. H. : "ODE(Object Database and Environment) : The
Language and the Data Model," Proceedings of the 1989 ACM SIGMOD International
Conference on Management of Data, 1989.
2. Ahmed, S., Wong, A., Sriram, D. and Logcher, R. : "A Comparison of Object-Oriented
Database Management Systems for Engineering Applications," IESL Technical Report, No.
IESL 90-03, 91-03, 1991.
3. 有沢誠：『ソフトウェアプロトタイピング』，近代科学社，1986。
4. 有沢誠：『ソフトウェア工学』，岩波書店，1988。
5. Atkinson, M., Bancilhon, F., DeWitt, D., Dittrich, K., Maier, D. and Zdonik, S. : "The
Object-Oriented Database System Manifesto," Proceedings of the First International
Conference on Deductive and Object-Oriented Databases, 1989.（西尾章治郎，田中克己：
「オブジェクト指向データベースシステム宣言とその意義」，bit, Vol.22, No.8,
1990。）
6. Atwood, T. and Orenstein, J. : "Notes toward a Standard Object-Oriented DDL and
DML," Computer Standards & Interfaces, Vol.13, No.1—3, 1991.
7. Bancilhon, F. and Maier, D. : "Multilanguage Object-Oriented systems : New Answer to
Old Database Problem?," Future Generation Computer II, Fuchi, K. and Kott, L. ed.,
North-Holland, 1988.
8. Booch, G. : Object-Oriented Design with Applications, Benjamin/Cummings, 1990.
9. Cattel, R. and Skeen, J. : "Engineering Database Benchmark," Sun Micro Systems
Technical Report, April 1990.
10. Chen, P. : "The Entity-Relationship Model—Toward a Unified View of Data," ACM
Transactions on Database Systems, Vol.2, No.1. 1976.
11. Coad, P. and Yourdon, E. : Object-Oriented Analysis, Second Edition, Prentice Hall,
1991.
12. Coad, P. and Yourdon, E. : Object-Oriented Design, Prentice-Hall, 1991.
13. Codd, E. : "A Relational Model of Data for Large Shared Data Bank," Communications
of the ACM, Vol.13, No.6, 1970.
14. Cox, B. : Object-Oriented Programming—An Evolutionary Approach, Addison-Wesley,
1986. （前川守監訳：『オブジェクト指向のプログラミング－ソフトウェア開発技
法の進化－』，トッパン，1988。）
15. 近山隆：「ESPerへの道－論理型オブジェクト指向言語ESP」，bit，Vol.22,
No.1, 1990。
16. 中所武司：「エンドユーザコンピューティング－ソフトウェア危機回避のシナ
リオ－」，『情報処理』，Vol.32, No.8, 1991。
17. Date, C. : A Guide to the SQL Standard, Second Edition, Addison-Wesley, 1990.（芝
野耕司監訳，岸本令子訳：『標準SQL－改定第２版－』，トッパン，1990。）
文献－1
18. Demarco, T. : Structured Analysis and System Specification, Prentice-Hall, 1979. （高
梨智弘，黒田純一郎監訳：『構造化分析とシステム仕様』，日経ＢＰ社，1986。）
19. Deux, O. et al. : "The Story of O2," IEEE Transactions on Knowledge and Data
Engineering, Vol.2, No.1, 1990.（「オブジェクト指向データベース「O2」のすべて」，
『日経AI別冊』，1990年秋号。）
20. Dickinson, B. : Development Structured Systems, Youdon Press, 1981.（黒田純一郎，
渡部研一訳：『システム設計の構造化手法』，日経ＢＰ社，1987。）
21. Dijkstra, E., Hoare, C. and Dahl, O. : Structured Programming, Academic Press, 1972.
（野下浩平，川合彗，武市正人訳：『構造化プログラミング』，サイエンス社，
1975。）
22. Gane, C. and Sarson, T. : Structured Analysis-Tools and Techniques, Prentice-Hall,
1979.
23. Gladden, G. : "Stop the Life-Cycle, I Want to Get off," ACM SIGSOFT Software
Engineering Notes, Vol.7, No.2, 1982.
24. Greif, I. and Sarin, S. : "Data Sharing in Group Work," ACM Transactions on Office
Information Systems, Vol.5, No.2, 1987.
25. 羽生田栄一：「オブジェクト指向分析・設計法」，『情報システムの計画と設
計』，情報処理学会編，培風館，1991。
26. 春木良且：『オブジェクト指向への招待』，啓学出版，1989。
27. Hatley, D. and Pirbhai, I. : Strategies for Real-Time System Specification, Dosert
House, 1988. （立田種宏監訳：『リアルタイム・システムの構造化分析』，日経Ｂ
Ｐ社，1989。）
28. Henderson-Sellers, B. and Edwards, J. : "The Object-Oriented Systems Life Cycle,"
Communications of the ACM, Vol.33, No.9, 1990.
29. 石井康雄編：『ソフトウェアの製造』，日科技連，1986。
30. Itasca Systems, Inc. : ITASCA Distributed Object-Oriented Database Management
System Technical Summary, 1990.
31. Jackson, M. : System Development, Prentice-Hall, 1983.（大野佝郎，山崎利治監訳：
『システム開発－JSD法－』，共立出版，1989。）
32. Jacobson, I. : Re-engineering Old Software to an Object-Oriented Architecture,
OOPSLA/ECOOP '90 tutorial material, 1990.
33. 「特集：統合OAの進展とシステム部の組織変容」，『事務と経営』，1990.3号。
34. 河村一樹：『ソフトウェア工学入門』，啓学出版，1987。
35. Kim, W. : "An Approach to a Total Solution to Long-duration Transactions," MCC
Technical Report, ACT-OODS-223-89, 1989.
36. Kim, W., Bertino, E. and Garza, J.F. : "Composite Objects Revisited," Proceedings of
ACM SIGMOD International Conference, 1989.
37. Lientz, B., Swanson, E. and Tompkins, G. : "Characteristics of Application Software
Maintenance, " Communications of the ACM, Vol.21, No.6, 1978.
文献－2
38. 牧村信之：「人に優しいインタフェイス」，『コンピュータ科学』，Vol.2,
No.2, 1992.
39. Martin, J. : Information Engineering Book 1 Introduction, Prentice-Hall, 1989. （竹林
則彦監訳，三菱CC研究会IEタスクフォース訳：『インフォメーション・エンジニア
リング 第１巻－統合化CASEのための方法論－』，トッパン，1991。）
40. 増永良文：「オブジェクト指向マルチメディアデータベース」，『システム/制
御/情報』，Vol.34, No.8, 1990。
41. 増永良文：『リレーショナルデータベース入門－データモデル・SQL・管理シ
ステム－』，サイエンス社，1991。
42. McCracken, P. and Jackson, M. : "Life Cycle Concept Considered Harmful," ACM
SIGSOFT Software Engineering Notes, Vol.7, No.2, 1982.
43. Meyer, B. : Object-Oriented Software Construction, Prentice-Hall, 1988. （二木厚吉監
訳，酒匂寛，酒匂順子訳：『オブジェクト指向入門』，アスキー出版局，1990。）
44. 「保守地獄へ挑戦始まる－約８割のユーザが保守は深刻な問題と回答－」，
『日経コンピュータ』，1990.7.30号。
45. 「見えてきたオフィス情報化への３つの道－統合化オフィス・システムの活用
で，変わるオフィス情報化－」，『日経コンピュータ』，1990.12.17号。
46. Object Design, Inc. : ObjectStore Technical Overview, 1990.
47. Objectivity, Inc. : Objectivity/DB : The DBMS built by engineers for engineer, 1990.
48. OMG : "Object Mangement Architecture Revision 1.0," OMG TC Document, 1990.
49. Ontologic, Inc. : Ontos Release 2.0 Product Description, 1990.
50. Page-Jones, M. : The Practical Guide to Structured Systems Design, Second Edition,
Prentice-Hall, 1988. （久保未沙，新谷勝利訳：『構造化システム設計への実践的ガ
イド』，近代科学社，1991。）
51. Peters, L. : Advanced Structured Analisys and Design, Prentice-Hall, 1987.（白井晴男，
奥島晶子訳：『実践的構造化分析と設計』，近代科学社，1990。）
52. Pinson, L. and Wiener, R. : An Introduction to Object-Oriented Programming and
Smalltalk, Addison-Wesley, 1988. （羽生田監訳：『Smalltalk : オブジェクト指向プロ
グラミング』，トッパン，1990。）
53. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W. :
Object-Oriented Modeling and Design, Prentice-Hall, 1991.
54. Schmucker, K : Object-Oriented Programming for the Macintosh, Hayden Book, 1986.
（大谷和利監訳：『オブジェクト指向プログラミング［上・下巻］』，日本ソフト
バンク，1989。）
55. Servio, Corp. : GemStone Product Overview, 1989.
56. Shlaer, S. and Mellor, S. : Object-Oriented Systems Analysis—Modeling the World in
Data, Prentice-Hall, 1988. （本位田真一，山口亨訳：『オブジェクト指向システム分
析－上流CASEのためのモデル化手法－』，啓学出版，1990。）
57. Steele., G. : Common LISP : The Language, Second Edition, Digital Press, 1990. （井
文献－3
田昌之監訳：『bit 別冊 Common LISP 第２版』，共立出版，1991。）
58. Stroustrup, B. : The C++ Programming Language, Addison-Wesley, 1986.（斉藤信男
訳：『プログラミング言語C++』，トッパン，1988。）
59. Taylor, D. : Object-Oriented Technology, Servio, 1990.
60. Versant Object Technology Corp. : Product Profile , 1990.
61. Ward, P. and Mellor, S. : Structured Development for Real-Time Systems,
Prentice-Hall, 1985.
62. Wasserman, A., Pircher, P. and Muller, R. : "The Object-Oriented Structured Design
Notation for Software Design Representation," IEEE Computer, Vol.23, No.3, 1990.
63. Winblad, A., Edwards, S. and King,D. : Object-Oriented Software, Addison-Wesley,
1990.
64. Wiseman, C. : Strategic Information Systems, Richard D. Irwin, 1988.（土屋守章，辻
新六訳：『戦略的情報システム－競争戦略の武器としての情報技術－』，ダイヤモ
ンド社，1989。）
65. 山崎利治：「共通問題によるプログラム設計技法解説」，『情報処理』，
Vol.25, No.9, 1984。
66. 横手靖彦：「オブジェクト指向分散オペレーティングシステム」，『コンピュー
タソフトウェア』，Vol.9, No.3, 1992.
67. 米沢明憲：「オブジェクト指向計算の現状と展望」，『情報処理』，Vol.29,
No.4, 1988。
68. 吉田紀彦：「オブジェクト指向の並列分散化に関する考察」，『オブジェクト
指向ソフトウェア技術シンポジウム論文集』，1991。
69. Yourdon, E. and Constantine, L. : Structured Design, Prentice-Hall, 1979. （原田実，
久保未沙訳：『ソフトウェアの構造的設計』，日本コンピュータ協会，1986。）
70. Yourdon, E. : Managing Structured Techniques, Third Edition, Prentice-Hall, 1986.（黒
田純一郎，渡部研一訳：『構造化手法によるソフトウェア開発』，日経ＢＰ社，
1987。）
71. Yourdon, E. : Managing the System Life Cycle, Prentice-Hall, 1988. （荒川淳三訳：
『CASE時代の最新プロジェクト管理技術』，マグロウヒル出版，1990。）
72. Yourdon, E. : Modern Structured Analysis, Prentice-Hall, 1989.
文献－4
図１．１ ウォータフォールモデル［文献8（Booch）p.198の図をもとに一部変更，和訳した。］
分析
設計
コーディング
テスト
運用保守
図１．２ 階層化されるDFDとDD，PSPEC
a
c
0
i
3.2
hg
f
プロセス
データ源泉／吸収
データストア
データフロー
a
b
c
d e1
2
f
g3
4
f = j + [k | l] + {m + n}........
PSPEC 3.1:INPUT:OUTPUT: IF.... .........
データ辞書
プロセス仕様書
DFD0
コンテキストダイアグラム
DFD3
b
3.1
図１．３ 「酒類販売業の在庫管理問題」の内容とそのDFD
出庫依頼
納品書
在庫
不足
通知
書
出庫指示書
入荷積荷票
出荷確認書
不足品発注書2
不足品
発注
1
出庫指示
4
出庫による
在庫更新
3
入庫による
在庫更新
在庫ファイル
在庫不足リスト
発注係
倉庫係
注文主
(b) 「酒類販売業の在庫管理問題」のDFD（第１層）［文献4（有沢）p.30の図を参考に一部変更した。］
(a) 「酒類販売業の在庫管理問題」の内容［文献65（山崎）。］
ある酒類販売会社の倉庫では，毎日数個のコンテナが搬入されてく
る．その内容はビン詰めの酒で，１つのコンテナには10銘柄まで混載
できる．扱い銘柄は約200種類ある．倉庫係は，コンテナを受取りそ
のまま倉庫に保管し積荷票を受付係へ手渡す．また受付係からの出庫
指示によって内蔵品を出庫することになっている．内蔵品は別のコン
テナに詰め替えたり，別の場所に保管することはできない．
空になったコンテナはすぐに搬出される．
積荷票：コンテナ番号（5桁）
搬入年月，日時
内蔵品番号，数量（の繰り返し）
さて受付係は毎日数十件の出庫依頼を受け，その都度倉庫係へ出庫
指示書を出すことになっている．出庫依頼は出庫依頼票または電話に
よるものとし，１件の依頼では，１銘柄のみに限られている．在庫が
無いか数量が不足の場合には，その旨依頼者に電話連絡し同時に在庫
不足リストに記入する。また空になる予定のコンテナを倉庫係に知ら
せることになっている．
出庫依頼：品名，数量
送り先名
受付係の仕事（在庫なし連絡，出庫指示書作成および在庫不足リス
ト作成）のための計算機プログラムを作成せよ．
出庫指示書：注文番号
送り先名
コンテナ番号 （の繰り返し）
品名，数量
空コンテナ搬出マーク
在庫不足リスト：送り先名
品名，数量
・なお移送や倉庫保管中に酒類の損失は生じない．
・この課題は現実的でない部分もあるので，入力データのエラー処理
などは簡略に扱ってよい．
・以上あいまいな点は，適当に解釈してください．
図１．４ 構造図，木構造チャート
処理
反復 選択
処理
処理
処理
制御パラメータ
モジュール
データパラメータ
コネクタ
ライブラリ
モジュール モジュール モジュール
(a) 構造図 (b) 木構造チャート（PAD）
図２．１ ポリモーフィズムによる拡張性の向上［文献5（Atkinson et al.）中の例を参考に作成した。］
従来の場合 オブジェクト指向の場合for p in Person do for p in Person do Salary(p); begin case of type(p) Manager: Salary_Manager(p); Engineer: Salary_Engineer(p); end end
クラスあるいは型，Manager，Engineerはすでに定義されている。
プログラム中type()はオブジェクトあるいはデータのクラスあるいは型の判定
を行なう関数。
図２．２ OOPLの進展［文献63（Winblad et al.）p.60，文献8（Booch）p.473，文献（春木） p.129を参考に作成した。］
1960
1990
1980
1970
Ada
Modula
Eiffel
Objective-C
LOOPS
CLOS
C++
C
Pascal
Algol
Simula
LISP
Flavors
非オブジェクト指向
ハイブリッド型
純粋型
Prolog
ESP
BCPL
COBOL
Object-Oriented COBOL
Object Pascal
Smalltalk
表２．１ ObjectStoreにおけるインスタンスの宣言と生成syntax lifetime allocate in
Employee e; procedure stack
static Employee e; process heap
persistent<db> Employee e; persistent database
Employee* e = new Employee; process heap
Employee* e = new(db) Employee; persistent database
図３．１ CoadとYourdonのOOAの表記法［文献11（Coad et al.）pp.162—163。］
Class-&-Object
Attribute1Attribute2Service1Service2
Class-&-Object ClassClass
Attribute1Attribute2Service1Service2
Name (top section)
Attribute (middle section)
Service (bottom section)
Gen-Spec Structure
Generalization
Specialization1 Specialization1
Whole-Part Structure
Whole
Part1 Part2
1,m 1,m
1 1
Instance ConnectionClass-&-Object1 Class-&-Object2
1,m
1
Message ConnectionSender Receiver
1 1
1 1
Subject (may be expand or collapsed) Note: In addition, OOA uses Object State Diagramsand Service Charts for specifying Service
(a) OOA notations
specification attribute attribute attribute
exeternalInput exeternalOutput
ObjectStateDiagram
additionalConstraints
notes
service <name & Service Chart> service <name & Service Chart> service <name & Service Chart>
and, as needed traceabilityCodes applicableStateCodes timeRequirements memoryRequirements
(b) Class-&-Object specification template
(c) Object State Diagram notation (used within the template)
State
Transition
(d) Service Chart notation(used within the template, for each service)
Condition (if; pre-condition; trigger, terminate)
Text block
Loop (while; do; repeat; trigger/terminate)
Connector (connected to the top of the next symbol)
図３．２ 「酒類販売業の在庫管理問題」の「クラスとオブジェクト， 構造，属性，サービス・レイヤー」
1
1
1,m 0,1 1,m 0,1
従業員
氏名
倉庫係
出荷確認
入荷通知
発注係
発注処理
酒
品名
送り先名
数量
在庫ファイル
コンテナ確認
コンテナ更新 酒確認
酒更新
コンテナ
コンテナ番号
内蔵酒数量
受付係
在庫確認
在庫更新
出庫指示
不足品発注
在庫不足通知
出庫依頼
注文主
HumanInteractionComponent
ProblemDomain
Component
TaskManagementComponent
DataManagementComponent
Subject LayerClass-&-Object Layer
Structure LayerAttribute LayerService Layer
図３．３ CoadとYourdonのOODにおける４つのコンポーネント［文献12（Coad et al.）p.26。］
表３．１ 構造化アプローチとオブジェクト指向アプローチの比較
構造化アプローチ オブジェクト指向アプローチ
モデル化の過程 トップダウン的 ボトムアップ的
モデルの形態 階層的 実世界に即した形態
モデル化の視点 処理，データなどを分離 一貫して単一のオブジェクト指向の枠組み
ライフサイクルに応じて抽象化の に基づくモデルを利用
レベルを変換
図３．４ オブジェクト指向アプローチのライフサイクル［文献8（Booch）p.198の図を和訳した。］
設計
修正
展開
分析
図中「展開（evolution）」は，コーディング，テスト，統合化を合わせた段階