プログラミングの世界は、オブジェクト指向プログラミング[Meyer 88bJ]によって急速に変わりつつある。 オブジェクト指向プログラミング（OOP）を押し進める力となったものは、 システムの巨大化・マルチメディア化・ユーザーインタフェースの複雑化・分散化などである。
従来からの構造化分析・構造化設計（SA/SD）[DeMarco 78J][Hatley 87J][Ward 86]や、 ましてそのほかの古い手法では、これらのシステムを開発するのは困難であった。 このため各種のオブジェクト指向言語が開発され、その言語による開発を支援する オブジェクト指向ライブラリーの開発も相次いだ。 最近では、Apple社のMacintoshパーソナルコンピュータ上でで、 MacApp[Apple 90][Wilson 90]と呼ばれるObject Pascal[Apple 91]とC++[Stroustrup 86J]の オブジェクトライブラリーが開発されている。 同様の機能を持った、NeXT社のワークステーション上のNeXTStep[橋本 90] という Objective-C[Cox 86J]のオブジェクトライブラリーも開発されている。 これらのマシン上では、オブジェクト指向パラダイムを使って、 多くのアプリケーションプログラムやツールがすでに開発されている。
構造化プログラミングだけでは巨大なシステムの開発に支障をきたし、 SA/SDとそれを支援するCASEツールが必要になったように、 OOPだけでは大きなシステムを開発するのに困難が生じる。 当然の帰結として、オブジェクト指向分析・オブジェクト指向設計手法と、 それを支援するCASEツールが必要になってきた。
本稿では、最近になって多くの手法が出現してきたOOA/OOD手法と、それらを支援するCASEツールについて、 その主なものを概説する。 ２章でオブジェクト指向CASEツールのベースとなる主要な３つの方法論について解説し 、3.1節でそれらの方法論を支援する上流工程支援CASE（Upper CASE）ツールを解説する。 また3.2節では、これらの方法論によらない下流工程支援 CASE（Lower CASE）についても紹介する。 さらに3.3節では、オブジェクト指向による開発に欠かせない、 ユーザーインタフェース構築支援のためのCASEツールを紹介する。 3.4節では、オブジェクト指向を支援するビジュアルプログラミングツールについて述べる。
本稿の狙いは、オブジェクト指向パラダイムを使用して、 実用的なシステムを開発する際に助けとなる手法とCASEツールを、分かりやすくかつ組織的な視点から捉え、 類似性と相違点を明確にすることである。
Ada[DoD 83] を支援する方法論やCASEツールは、継承を支援していないこと、日本での重要性が低いことから、 基本的には調査対象から除外した。
OOA/OODの方法論の多くは、ChenのEntityｰRelationship（E-R）図[Chen 76]やSA/SDあるいは JSD法[Jackson 83J]の考え方を取り込んで、オブジェクト指向独自の記法や方法論を追加したものである。
Shlaer／Mellor[Shlaer 88J]やBoochの古い手法[Booch 83]あるいはHOOD[HOOD 89]などの初期のOOA/OOD手法は、 後述する最新の手法に取り込まれ、より完全な形になっていったためここでは触れない。
各手法を評価するための枠組として、以下の項目を選択した。
オブジェクト指向は、ある意味では曖昧な概念であり、 それぞれの手法によって微妙に定義が異なるため、 その手法でどのようにオブジェクト指向を定義しているか、あるいは捉えているかを記述する。
その手法の元になった方法論と、継承した性質を記述する。
主として支援するオブジェクト指向言語あるいはその他の言語を示す。
その手法がどのようなモデルを採用しているかということと、 そこで使われている記法について概略を記述する。
その手法でどのように分析・設計を行うかの概略を示す。
その手法の特徴と問題点を述べる。
Boochの手法[Booch 90]は、[Booch 83] に述べられているAda指向の方法を拡張し、 OOD全体をカバーする方法論としてまとめたものである。Boochの手法は特に名前がないが、 本稿では以下「Booch法」と呼ぶ。
Booch法は、オブジェクト指向を手続き指向・論理指向・ルール指向・制約指向などと 同じ抽象化の１つの方法と捉えている。 ただし、オブジェクト指向が一番適応範囲が広い方法論であるという認識である。
Boochはオブジェクト指向を以下の４つの主要な要素に分類し、 どれが欠けてもオブジェクトモデルとは言えないと主張している。
抽象性は、あるオブジェクトを他のオブジェクトから区別する本質的な特徴を示し、 見る人によって異なる、概念モデルの違いを明確にする。
カプセル化は、オブジェクトの本質的特徴に関係ない詳細を隠す処理である。
モジュール性はSA/SDと同じで、強度が高く結合度が少ない分割をされたシステムの特性である。
階層は抽象性の格付けあるいは順序付けである。 重要な２つの階層として、クラスの階層（"kind of"階層）と オブジェクトの階層（"part of"階層）があり、継承は最も重要な"kind of"階層である。 "kind of"階層は、他の方法論では一般化-特殊化構造あるいは"is-a関係"と捉えられている。 多重継承も考えられる。また、モジュールとプロセスの階層もある。
Booch法は、自身の古い手法[Booch 83]・HOOD[HOOD 89]・OOSD[Wasserman 90]など、 Adaの開発手法から強い影響を受けている。また、クラス間の関係の記述などはE-R図[Chen 76] から、 オブジェクトの認識方法などはJSD法[Jackson 83J]の影響も受けている。
対象とする言語は特定していないが、主としてAda, C++, Object Pascalなどであり、 Smalltalk[LaLonde 90], CLOS[井田 89]なども対象となっている。
Booch法はクラス図・オブジェクト図・モジュール図・プロセス図・状態遷移図・タイミング図の ６つの図を使う。最初の２つは論理的な視点からシステムを記述するものであり、 つぎの２つは物理的な視点からシステムを記述する。この４つはシステムの静的な意味を記述している。 最後の２つは、システムの動的な意味を記述している。
Booch法で特徴的なクラス図を図2.2-1に示し解説する。
クラス図のオブジェクトは、図2.2-1で破線の雲型で示されるクラスと、 それに影が付いたクラスユーティリティ、およびこの例では出てこない四角で表される クラスカテゴリーからなる。
各オブジェクトは、関係を表す線で結ばれる。図2.2-1では白丸付きの２本線は、 白丸が付いているクラスのインタフェース部（例えばObject Pascalのinterface unit）が、 ２本線で結ばれたもう一方のクラスのリソースを使うことを示す。 黒丸の場合は、そのクラスのインプリメンテーション部 （例えばObject Pascalのimplementation unit）がもう一方のクラスのリソースを使うことを示す。 線の両側の数字は基数を表す。矢線は継承を表す。
従って図2.2-1は以下の意味のクラス構造を示す。 Controller Utilitiesクラスユーティリティーのインタフェース部が Environmental Controllerクラスのリソースを使う。Environmental Controllerクラスの インプリメンテーション部はLightクラスのリソースを使い、 Environmental Controller一つに対してLightがn個対応する。 Environmental Controllerクラスのインプリメンテーション部は、 HeaterクラスとCoolerクラスのリソースを使い、関係はそれぞれ１対１である。 HeaterクラスとCoolerクラスは、それぞれActuatorクラスから継承する。
Booch法の手順は大きく以下の４つに分かれるが、特に詳細な手順やコツがあるわけではない。
オブジェクトの見つけ方は、Shlaer／Mellorの方法やCoadの方法[Coad 91]を流用していて 、問題を記述した文章あるいは構造化分析の結果から、 役割・イベント・人・場所・物事・デバイスなどをオブジェクトの候補として 洗い出してくるというものである。最初の分析対象はコンピュータシステムではなく、 対象分野そのものである点はJSD法あたりの影響を受けている。
Booch法の特徴は図の種類の多さと、図中に記述する項目の種類の多さだろう。 ほとんどの言語で作成されたシステムの静的・動的な構造、 あるいは論理的・物理的な構造を記述することができる。 逆にこれがBooch法の欠点になっている。 OOA/OODの段階で記述する必要のない詳細まで混在しているため、 対象システムの領域や開発言語を特定した場合、不要な図や記号が多くなる。 特にSmalltalkで作成されるシステムを記述する場合、 かなりの記号と項目は記述する必要がなくなる。
また、OOA工程での指針が少なくOODに偏った手法であり、 それも手順が十分に詳細化されているとは言いがたい。 クラス図においてオブジェクト間の結合（association）にあまり注意が払われていない といった欠点もあるが、Ada, C++, Object Pascalなどをベースとした開発には一応有効であろう。
OOSD（Object-Oriented Structured Design）[Wasserman 90] は、オブジェクトと既存のモジュールの結合、 開発言語からの独立、方法論からの独立を目指した手法である。
OOSDが支援する概念は、オブジェクト指向から
などであり、Adaの
も取り込んでいる。また、SDの
などの概念も取り込んでいる。
OOSDは、SDの構造化チャート[Page-Jones 80]、Booch法のAdaのパッケージとタスクの記法、 オブジェクト指向のクラス階層と継承などからアイデアを得ている。
対象言語は、C++, Objective-C, Eiffel[Meyer 88bJ] , Smalltalk, CLOS, Ada, C, Fortranなど、 構造化機能を持っている言語すべてである。
OOSDは図としては１種類で構成される。表現できるオブジェクトは、 （１）クラス（２）継承（３）汎化（４）動的束縛（５）同期（６）例外処理、などである。 図2.3-1にOOSDの主な記法を示す。
OOSDは特定の方法論から独立であることが設計目標なので、特に手順はない。 ユーザーはBooch法や他の方法論を用いて、図表記だけOOSDを使うことができる。
OOSDはSDの記法とオブジェクト指向の記法を融合しているため、 既存のシステムを一部改良してオブジェクト指向を導入する時に便利である。 また、方法論や言語から独立しているため適用範囲が広い。
一方、OOSDはOOAの手段を（ERE++として計画中ではあるが）現在何も持っていない。 このため、OOA/OODで使用する記法と方法が一貫している、OMT（後述）などの方法論は難しい。
また、メソッドが多数あるオブジェクト（例えば普通のSmalltalkのオブジェクト）の場合、 OOSDの記法で限られた画面や紙の上に記述しきれるかどうか疑問が残る。
C++, Object Pascal, Ada, Eiffelなどの開発には一応有効であろう。
Coad, Yourdonの手法はOOAと自称しているが、一般的なOOAと混同するので、以後Coad法と呼ぶ。 Coad法は複雑さを軽減する原理を、以下のように分けている。 （１）抽象 手続きとデータの抽象 （２）カプセル化 （３）継承 （４）結合（association） （５）メッセージによる通信 （６）組織化の普及手法 オブジェクトと属性、全体対部分、クラスとそのメンバーとそれらの間の区別 （７）スケール そして、Coad法を構成する概念である （１）クラスとオブジェクト （２）一般化-特殊化構造（is-a関係） （３）全体-部分構造（has-a関係） （４）属性 （５）サービス（メソッド） （６）インスタンス接続 （７）メッセージ接続 （８）サブジェクト サブジェクトはオブジェクトのかたまりであり、スケールの問題を解決する。 で、上の複雑さを軽減する原理を支援していると主張する。 Coad法は、E-RモデルやShlaer／Mellorの方法と、OOPおよび知識ベースシステムの概念を組み合わせて発展させたものである。 Smalltalk, C++, Objective-C, Eiffelなどを直接の対象としている。他の言語の場合や、C++でもオブジェクト指向の機能を使わない場合は、OOA部分はそのまま使えるが、OOD部分はOOSDなどの付加的な方法論が必要になる。 Coad法は図2.4-1の記法で表すオブジェクト図とも呼ぶべき図と、状態遷移図とフローチャートに近いサービスチャートでモデルを構築する。 状態遷移図とサービスチャートは、オブジェクトの内部のサービスの定義に使用する。オブジェクト図で使われる記号は、2.4.1節で述べた概念をそのまま表している。 Coad法の手順は大きく以下の５つに分かれ、それぞれかなり詳細に標準の手順が決められている。 （１）オブジェクトの認識 どうやって名前を付けるか、どこを捜すか、何を捜すか、選択の基準は何か、不必要なオブジェクトは何か、といった指針がある。 （２）構造の認識 一般化-特殊化構造、全体-部分構造などを認識する。そのためのノウハウも提供されている。 （３）サブジェクトの認識 サブジェクトをいつ、どうやって選び、洗練するかの指針がある。 （４）属性の認識 属性の抽出、属性の配置、インスタンス接続の認識、属性とインスタンス接続の必要性のチェック、属性の制約の記述などの指針がある。 （５）サービスの認識 オブジェクトの状態の認識、状態遷移図の作成、サービスの抽出、メッセージ接続の認識、サービスの記述、サービスチャートの作成、ドキュメント化などの指針がある。 Coad法では、オブジェクトの構造と挙動の両方の分析方法が示されている。オブジェクトのかたまりとしてサブジェクトを置くことによって、概観の把握が容易になっている。また、記法が簡単な割に有用性が高い。 一方、分析方法は割合しっかりしているが、挙動面の分析はまだ弱く、設計の方法論は詳細とは言えない。Smalltalkなど、詳細設計にあまり留意する必要のない言語を使う場合有用であるが、C++, Object Pascalなどでは詳細設計に適した記法と方法論で補強する必要があろう。
Object Modeling Technique（OMT）はGeneral Electric社の研究開発センターで開発された手法であり、ほとんどの種類のアプリケーションの開発に役だったと主張されている方法論である。現時点で最も完成された技法なので、多少詳しく解説する。 OMTでは、オブジェクト指向を以下のように捉えている。 （１）抽象 （２）カプセル化 （３）データと振舞いの結合 （４）共有 継承はいくつかのサブクラス間のデータと振舞いの共有であり、継承を使ったコードの共有はオブジェクト指向言語の最も有利な点であるが、他にも、将来のプロジェクトとの設計の共有や、再利用可能なライブラリーの構築が容易といった利点がある。 OMTは、SAからデータフローと状態遷移図を引き継ぎ、オブジェクトモデリングはE-R図やデータベース設計技法から引き継いでいる。オブジェクトの認識方法はJSD法から一部影響を受けている。 他のOOA/OOD技法のうち、特にShlaer／Mellorの手法やCoad法とは、オブジェクトモデリングの方法・記法が似ている。 対象とする言語は、ほとんどすべての言語である。オブジェクト指向言語のうちSmalltalk, Eiffel, C++ については、 どのようにOMTモデルをプログラムに展開していくかのガイドがある。また、非オブジェクト指向言語のうちC, Ada, Fortranについても、どのようにOMTモデルをプログラムに展開していくかのガイドがある。もちろん非オブジェクト指向言語の場合、言語が支援しない機能はプログラマーの責任になるのだが。 OMTの場合特徴的なことは、OMTモデルをリレーショナルデータベースシステム（SQL言語相当のデータベース照会言語を含む）で実現する際の詳細なガイドがある点である。 OMTモデルは、オブジェクトモデル・動的モデル・機能モデルからなる。オブジェクトモデルは図2.5-1のようなオブジェクト図からなり、オブジェクトやクラスの静的構造を表す。動的モデルは状態遷移図で表し、オブジェクトの状態・動作を記述する。機能モデルはデータフロー図で表し、機能の詳細を表す。 OMTのオブジェクト図が表現できるオブジェクトは、以下のように豊富である。 （１）クラスとオブジェクト クラスはCoad法と同じように内部を分割した箱で表す。図2.5-1ではPerson, Companyなどがクラスであり、クラスを表す箱の一番上の部分がクラス名、２番目が属性、３番目が操作を表す。 （２）属性 属性はクラスの記号の中央の部分に列記するが、データの型と初期値を記述することもできる。 （３）操作（operation） 操作はクラス記号の一番下の部分に列記するが、引数リストと返す値も記述できる。 （４）継承 継承は白抜きの三角形で表される。図2.5-1ではWorkerとManagerが、Personの性質を継承していることが示されている。多重継承を表すこともできる。 （５）結合（association） 結合はクラス間を結ぶ線分で表される。結合名は線分上に表され、役割名が線分の両端に表示される。図2.5-1ではPersonとCompanyを結ぶ結合は名前がWorks-forであり、役割名はPerson側がemployeeで、Company側がemployerである。 結合が１体１であれば線分だけで表されるが、図2.5-1のように両側に●あるいは○が付くと、それぞれ多数（０かそれ以上）あるいはオプション（０か１）であることを示す。図2.5-1では、Managerは１つのDepartmentを管理するか１つも管理せず、Departmentには０または１人のManagerが居て、Manager１人は０またはそれ以上のプロジェクトに責任があることが記述されている。 条件付き結合（qualified association）は、結合を表す線分の片側に四角で条件子（qualifier）を記述する。図2.5-1では、CompanyとDepartmentがdept nameという条件子で結合されている。 リンク属性は、図2.5-1のWorks-for結合に付いている記号で表される。ここではjob titleというリンク属性が定義されている。リンク属性を拡張してクラスとして記述することもできる。 この他にも、集合体（Coad法の全体-部分構造と同じ）、三角関係（３つのオブジェクトの結合）などを表すことができる。 （６）インスタンス関係 （７）制約 オブジェクトの属性の制約、結合間の制約などを表すことができる。 OMTは以下の手順で分析・設計を行う。 （１）分析 ここではシステムが何をするべきかというモデルを作る。 (a) 問題記述文の最初の版の作成 (b) オブジェクトモデルの構築 オブジェクトのクラスの認識、データ辞書の作成、クラス間の結合の追加、属性の追加、継承の導入、シナリオに基づくテストの繰り返し、クラスをグループ化してモジュールにする、といったことを行う。 (c) 動的モデルの作成 シナリオの作成、オブジェクト毎のイベントの認識とシナリオによるイベントのトレース、状態遷移図の作成などを行う。 (d) 機能モデルの作成 入出力の認識、データフロー図の作成、各機能の記述などを行う。 (e) ３つのモデルの検証と改良 機能モデルで見つかった主要な操作のオブジェクトモデルへの反映、シナリオによるテストなどを行う。 （２）システム設計 ここでは、システムの上位レベルの構造を決める。 (a) サブシステムへの分割 (b) 問題固有の並行性の認識 (c) サブシステムのプロセッサーとタスクへの割当 (d) データストアの実現方法の選択 (e) 共通リソースの認識とそれらをアクセスする制御機構の決定 (f) ソフトウェア制御の実現方法を選択する プログラム内に状態を持つか、状態マシンを直接実現するか、並行タスクを使うかを選択する。 (g) 境界条件を考える (h) トレードオフの優先順位を決める （３）オブジェクト設計 ここでは、分析モデルをみがき上げ、特定の言語やデータベースシステムへの変換方法に依存しない、実現のための詳細を設計する。 (a) 他のモデルで見つけた操作のオブジェクトモデルへの反映 機能モデルのプロセスから操作を見つけるか、動的モデルのイベントから操作を見つける。 (b) 操作を実現するためのアルゴリズムの設計 操作のコストを最小にするアルゴリズムを選択する、アルゴリズムにあったデータ構造を選択する、必要であれば新たなクラスと操作を追加する、などを行う。 (c) データへアクセスするパスの最適化 アクセスコストを最小化し便利さを最大化するため冗長な結合を追加する、効率化のため計算順序を変える、複雑な計算をやり直さないため計算結果を保存する、などを行う。 (d) ソフトウェア制御を実現する。 (e) クラス構造を吟味して、継承を増やす。 継承を増やすためクラスと操作を再配置する、抽象クラスを抽出する、継承が意味的におかしいとき委譲（delegation）を使う、などを行う。 (f) 結合の実現方法を設計する。 結合を１方向だけ実現する、結合をオブジェクトとして実現する、結合の両側のクラスへ属性として追加することによって実現する、などを行う。 (g) オブジェクトの属性の表現方法を決める。 (h) クラスと結合をモジュールにまとめる。 （４）実現 プログラミング言語で実現するか、データベースシステムで実現するか、コンピュータ以外で実現するかを決める。次に、クラス・操作・結合を対応する各言語毎に指針にしたがって展開する。 OMTの特徴は、分析から設計まで一貫したオブジェクトモデルで記述でき、分析手順と設計手順と実現手順とが、かなり詳細に分かりやすく用意されていることである。オブジェクトモデルはBooch法よりは簡単で、Coad法より記述能力が高く、どちらの方法よりも結合に関しての記述力が高い。 OMTで使用するモデルは言語独立性が高く、利用可能な分野が広い。実際に種々の言語で、いろいろな分野のアプリケーションを作成した経験が感じられる。また、従来のSA/SD手法のEｰR図をオブジェクト図に変えればOMTになるので、SA/SDからOMTに移る障害が少ない。 現時点で、もっとも完成されたOOA/OODの方法論である。 あえて問題点を捜せば、既存のライブラリーとオブジェクト指向のライブラリーを混合した場合、Booch法やOOSDのようにそれを直接的に表すことができない点だろう。既存のシステムを分析する場合にも、モジュールの呼び出し関係などを直接的に表せない。
方法論を支援するCASEツールで完成しているものは少なく、 開発中あるいはプロトタイプは完成しているが製品バージョンは開発中のものが多い。
SA/SDを支援するCASE環境Software through Pictures[Wasserman 87] の上で動く、Interactive Development Environments社のOOSD支援ツールである。プロトタイプは完成しているが製品は開発中である。UNIXまたはVMS上で稼働し、Ada, C++, Eiffelの開発を支援する。 主な機能は以下のとおり。 （１）整合性チェック機能 名前の整合性、モジュールや操作のパラメータの整合性チェック、図上の各記号の接続の正当性チェックなどを行う。 （２）コード生成機能 OOSDの図からコードを生成する。言語毎の生成ルールは、データ辞書を通して設計チェックルール・生成ルーチンと統合化されていて、新しい言語に対応させることは比較的簡単である。また、生成されたコードはテキストファイルであり、パラメータファイルに指定されたコマンド（例えば文法チェッカーやコンパイラー）に渡すことができる。 （３）再利用機能 再利用ライブラリーとして検証された仕様とコードをデータ辞書に入れることができ、検索し複写し修正することができる。 （４）分かりやすさ支援機能 大規模なシステムの設計に利用できるよう、設計を階層化し、不必要な詳細を隠すことができる。 OOSDはSA/SDツールと連係しているため、分析フェーズではE-R図を使わなければならない。このため、ERE++というオブジェクト指向に対応したE-R図の拡張が計画されているが、詳細は不明である。 基本的に、オブジェクト指向の考え方を、SAのE-R図やデータフロー図でシミュレートし、モジュール設計段階からOOSDを使う形になるので、既存のCのライブラリーなどを活かし、一部C++などで開発する場合に有用であろう。 ユーザーインタフェースは、SA/SD機能との整合性を取るため、オブジェクト指向でなく機能指向なので、他のOO-CASEツールよりは使いにくい。 自身の開発にOOSDを使用しているかどうかは不明。
Object International社の、Coad法を支援するツールである。Macintosh上で稼働する。支援する開発言語は特に限定されていないが、Smalltalkが一番向いている。図2.4-1はOOAToolの出力例でもある。 Coad法を全面的に支援しているが、CASEツールとして付加された主な機能は、以下のとおり。 （１）評論機能 作成されたモデルを評価し、方法論の指針に反する部分や未定義部分を指摘する。 （２）フィルター機能 一つのモデルに複数の図を対応させることができ、各図はお互いの修正を反映することができる。さらに、フィルター機能によってモデルが見える部分を制限することができる。 （３）ドキュメント支援機能 オブジェクト毎に、ドキュメントのテンプレートを定義し、ドキュメントを作成することができる。 （４）戦略カード機能 Coad法の方法論を工程別に表示する。この工程や内容をユーザーが変えることも可能である。 OOAToolはCoad法全体を支援するツールであり、Smalltalk/V[Digitalk 88]で開発されているため、Smalltalk/Vのエディターや環境を流用して高機能なツールとなっている。ただし、Smalltalk/Vの環境にはアクセスできない。 ユーザーインタフェースは良い方であり、オブジェクト指向ユーザーインタフェースを採用しているが、Macintoshのアプリケーションとしては良くない部類に入る。またツール実行中、しばしば（おそらく操作を間違えたときであるが）「Message not found」メッセージを出してツールから抜け出すことができなくなる。 自身の開発にCoad法を適用しているか不明。
Objectworks/Smalltalkと後述する（3.2.1節）Blizzard-90[富士ゼロックス 91]上で稼働する、富士ゼロックス情報システム社のCoad法を支援するツールである。現在プロトタイプが完成しているが、OMTに対応したツールも開発中である。図3.1.3-1にObjectCastのオブジェクト図の例を示す。 支援する開発言語は、オブジェクト指向言語全般であるが、現在はSmalltalk支援機能が一番豊富である。 Coad法を全面的に支援するとともに、各種技法を利用して、その拡張も行っている。以下に主な機能を説明する。 （１）マネージャー機能 Coad法のサブジェクトやオブジェクトをまとめる概念として「仕様書」を導入し、全体関係を把握し、オブジェクト図エディター（グラファーと呼ぶ）や次に述べるインベスティゲーター機能を起動するためのものである。 （２）インベスティゲーター機能 ObjectCastで扱うオブジェクトすべてについて、その情報を記述したり参照したりするための機能である。サービスインベスティゲーターには、入力条件・出力条件の記述機能もある。 （３）ハイパーテキスト機能[Conklin 87] インベスティゲーター機能の注釈記述部分から、任意のSmalltalkの式を記述し、それを評価することによって、Smalltalk, Blizzard-90, ObjectCastの任意の機能を実行できる。 （４）状態遷移図 （５）ペトリネット図[Peterson 81J] OOD段階で、タイミングを考察するツールとして導入された。 （６）データーフロー図 （７）フローチャート図 Coad法のサービスチャートは、実質的にフローチャートなので、サービスの詳細を記述するために導入された。 （８）コード生成機能 Smalltalkコードのテンプレート生成機能である。 ObjectCastはCoad法を支援するツールであるが、実際にOOA/OODを実践する中で、必要な図やツールが拡張されている。状態遷移図とデータフロー図を導入したことにより、記法を変えればOMTも支援できるため、OMTにも対応できるよう改造中である。 ObjectCastはObjectworks/SmalltalkとBlizzard-90上で稼働し、それらの環境も同時に利用できるため、OOA/OOD/OOPを一貫して支援するきわめて強力な環境になっている。 ユーザーインタフェースは基本的には良いが、各ツール間で多少の不整合が見られる。また整合性チェックのための機構は、現在開発中である。 自身の開発にCoad法を使用している。
この他のツールとしては、以下のものがあるが、詳細は不明。 （１）Mack V System社のObjectMaker（多分開発中） Booch法のツールで、Ada, C++, Cのコード生成とリバースエンジニアリングを行う。MS-Windos, X11, Mac上で稼働する。 （２）Easyspec社のObjectPlus 詳細不明。 （３）Cadre社のTeamWork（開発中） バージョン4.0でShlaer／Mellorの方法を支援するE-R図と、Booch法のAda構造グラフを出す予定。UNIX 上で稼働。 （４）IPSYS社のCASET Coad法を支援する。 （５）Popkin Software社のSystem Architect E-R図と、AdaとC++のためのBooch法、Coad法を支援する。図の整合性とルール違反をチェックする。MS-Window上で稼働。 （６）GE社のOMTool OMTを支援するCASEツールである。 方法論を支援するツールは、全体として図エディターのレベルにとどまっており、データ辞書を利用した整合性のチェック、ハイパーテキスト機能などは一部しか実現されていない。
Lower CASEはソフトウェア開発の下流工程（詳細設計、プログラミング、デバッグ、保守の一部）を支援する。その性格上、方法論よりは言語に依存したものが多い。ここではその代表的なものを紹介する。
Objectworks/SmalltalkはParcPlace Systems社のSmalltalk支援環境であり、Blizzard-90は、Objectworks/Smalltalk上に構築された富士ゼロックス情報システム社のSmalltalk支援環境である。Blizzard-90は、本体のObjectworks/Smalltalkよりも多くのクラスとステップ数からなる巨大な支援環境と再利用可能なオブジェクトライブラリーの集合である。ユーザーインタフェースは、Objectworks/Smalltalkオリジナルのものも使用できるが、普通はすべてBlizzard-90流に改造されている。図3.2.1-1にBlizzard-90のブラウザーを示す。 Blizzard-90（Objectworks/Smalltalkの機能も含む）の主要な機能は以下のとおりである。 （１）新ユーザーインタフェース 従来のSmalltalkのユーザーインタフェースに、多数の新機能が追加された。 （２）アウトライン機能 ドキュメント作成や情報の整理になどに便利なアウトラインリストビューが追加された。 （３）各種の新ブラウザー Blizzardブラウザー（図3.2.1-1）、クラス木ブラウザー、アウトラインブラウザー、アウトラインカテゴリーブラウザー、クラス階層ブラウザーなど、従来のSmalltalkより強力な多数のブラウザーがある。 （４）グラファ機能 図エディターの基本機能を持っていて、この機能を利用してクラス木ブラウザーや前述のObjectCastが実現されている。ノードやアークの整列機能も持っている。 （５）移植性 移植性のあるSmalltalkコードの作成が可能になった。 （６）動的コンパイル機能 （７）シンボリックデバッガー （８）変更管理機能 各クラスおよびメソッド毎に変更履歴を管理できる。 （９）効率測定機能 （１０）設計評価機能 特殊化-抽象化因子（HF）、組み立て-要素分解因子（RF）、多相化因子（PF）を計算して、ある程度の設計の評価ができる。 HFA = クラスAのスーパークラス数 / (クラスAのスーパークラス数 + クラスAのサブクラス数 + 1) RFA = クラスAのトポロジカルソート順位 / 全クラス数 PFA = システム内でユニークなクラスAのメソッド数 / システム全体のメソッドの種類の数 （１１）ランタイムアプリケーション開発機能 必要のないクラスや開発環境を切り離してアプリケーションプログラムを作成することができる。 （１２）３次元ライブラリー CASEツールなどで利用するための３次元ライブラリーである。 （１３）リレーショナルデータベース接続機能 オブジェクトやその他の情報を格納するための機能である。 全体として、Smalltalkの開発・保守支援環境として十分すぎるほどの機能を持っているが、チームによる協同作業を支援する機能が弱い。 3.2.2 Objectworks/C++ Objectworks/C++はParcPlace Systems社のC++2.0支援環境である。基本的に、Objectworks/Smalltalk的な支援環境をC++に与えるものである。Sunワークステーション上で稼働する。 主な機能は以下のとおり。 （１）ファイルシステムブラウザー機能 （２）ソースコードブラウザー機能 継承構造・クラス・関数の検索とアクセス、コンパイル、などを実現している。 （３）ソースコードデバッグ機能 （４）構成管理機能 （５）UNIXインターフェース機能 UNIXのファイルシステムへのアクセスや、UNIX端末機能、UNIXコマンドへのアクセス機能がある。 全体として、C++の開発・保守支援環境として強力な機能を持っているが、チームによる協同作業を支援する機能が弱い。
OOA/OODだけでは、ユーザーインタフェースが有用なシステムを構築するのは困難である。OOA/OODによるモデル化と並行して、ユーザーインタフェースをあらかじめ設計しチェックする必要がある。このため、ユーザーインタフェース設計用のプロトタイピングツールなどが作られてきた。しかし、ここにきてプロトタイプだけでなく最終製品に拡張していくことも可能で、オブジェクト指向パラダイムにも対応したCASEツールが出現してきた。ここでは、その中でも高機能なWidgets/Vについて述べる。
Widgets/VはAcumen Software社のユーザーインタフェース構築ツールであり、Macintosh上のSmalltalk/V環境に組み込まれて動く。Widgets/Vで作成されたユーザーインタフェースは、そのままアプリケーションプログラムへ発展させていくことができる。このためWidget/Vは、MVCモデルと対応するSmalltalk/VのMPDモデルは分かりにくいとして書き換え、ViewとControllerを一緒にしたWidgetsクラスを使用する。 主な機能は以下のとおりである。 （１）インタフェースエディター Widgets/Vの中心機能であり、Macintoshのウィンドウやポップアップメニューやボタンなどからなるユーザーインタフェースを編集する。図3.3.1-1に画面例を示す。 このエディター上でユーザーは自由にユーザーインタフェース関連のオブジェクト（ボタン・フィールド・メニュー・画面など)を編集することができる。 （２）テスト機能 図3.3.1-1の左上のTest Itボタンをクリックすることにより、編集中のユーザーインタフェースを実行してテストしてみることができる。 （３）コード生成機能 インタフェースエディタから、ユーザーインタフェースに対応したSmalltalkコードを生成させ、ユーザーインタフェースの編集情報と一緒にライブラリーとして格納し、後で再利用することができる。 Widgets/Vはユーザーインタフェースを編集し、それをテストし、Smalltalkコードを生成し、それを再利用でき、ユーザーインタフェース以外のコードをSmalltalk/Vのブラウザーから作成することによって、最終的な製品まで作ることができる。 ユーザーインタフェース自体もオブジェクト指向になっており、分かりやすい。また、ベースにあるSmalltalk/V環境とも融合している。 現時点で考えられる、最良のオブジェクト指向ユーザーインタフェース構築支援CASEツールと言って良いだろう。
従来のビジュアルプログラミングツール[萩谷 91]は、フローチャートや構造化チャートをビジュアル化したものが多かった。ここではOOD/OOPを支援するビジュアルプログラミングツールを紹介する。
Prograhは、Macintosh上で稼働するThe Gunakara Sun Systems社のオブジェクト指向ビジュアルプログラミングツールである。 Prographはオブジェクト指向ビジュアルプログラミング環境であり、図形言語であり、アプリケーション生成ツールである。アプリケーションプログラムの作成までを、すべてPrograph内で行うことができる。カバーする開発工程は、 Objectworks /C++, SoftBenchなどとほぼ同じである。 主要な機能は以下のとおり。 （１）ブラウザー機能 クラスブラウザー、属性ブラウザー、メソッドブラウザーなどがあり、継承の記述、属性の記述、メソッドの記述が容易にできる。図3.4.1-1はクラスブラウザーの例である。 （２）図形言語編集機能 図3.4.1-2のような図形言語を編集し実行する機能がある。この図形言語は、オブジェクト内部のデータフローを記述していると思ってよい。 （３）図形言語インタープリト・デバッグ・コンパイル機能 図形言語編集ウィンドウから、言語のインタープリト、シンボリックデバッグ、コンパイルを行うことができる。 かなり分かりやすく強力なオブジェクト指向図形言語とその開発環境である。これからのプログラミングのひとつの方向を示していると思うが、専門家がObjectworks /C++, SoftBenchなどで開発するのに比べ、生産性が良いとは言えないだろう。ただ学習時間ははるかに少ないと思われるので、プログラマーの範囲を広げる効果はあるだろう。
ここまでに見てきたOOA/OOD手法やそれを支援するCASEツールには、まだ多くの問題点がある。以下に主なものを示す。
現時点のOOA/OOD手法は、その概念にかなりの類似性があるにもかかわらず、その手法と記法の差が大きい。実際に、Booch法とCoad法とOMTとを比較する際、どの記号がどの記号に対応するかを調べるだけでかなりの労力が必要であった。 また、Booch法やOOSDのように、SA/SDとの一貫性を主張する方法論はSA/SDの記号とOODの記号を混合させているが、記号の数が多くなりすぎて分かりにくく、より詳細の設計に偏りすぎている感がある。整理が必要であろう。 手法とそれを支援するCASEツールのいずれも、プロトタイピングやユーザーインタフェース構築の手法を組み込んでいない。実際にはOOA/OODモデルだけでシステムを見通すことは難しく、プロトタイプやユーザーインタフェース構築とモデル化が並行して必要なことを考えれば、手法の拡張が望まれる。
SA/SDを支援するCASEツールでデータ辞書による支援がないものは稀であるが、OO-CASEでSA/SDでのデータ辞書にあたるオブジェクト・リポジトリーによる支援があるものは調査した範囲ではない。このため、モデルの整合性チェック機能や、モデル内のオブジェクトの検索機能が弱く、大きなシステムへの適用にはまだ困難がある。
OMTでは意味的制約の記述ができ、Booch法でも前条件・後条件の設定はできるが、いずれもフォーマルな仕様記述言語は規定されていないため、対応するCASEツールで意味的エラーのチェックができない。このあたりの事情はSA/SDを支援するCASEでも同じだが、改善が望まれる。[Redmond-Pyle 91]で、フォーマル仕様をCoad法などの図表現と融合させる議論が行われている。
OOA/OODのモデルとしては、OMTのようにオブジェクトモデル・動的モデル・機能モデルの３つでシステムを捉えていくのが最も自然だろう。Booch法の６つの図も、クラス図・オブジェクト図・モジュール図をオブジェクトモデル、状態遷移図・タイミング図を動的モデル、プロセス図を機能モデルと考えれば、この捉え方に一致する。Coad法も機能モデルが欠けている点以外はOMTにかなり類似している。 対象システムをオブジェクトモデル・動的モデル・機能モデルの３つで表す考え方は、結局SA/SDの情報モデル・動的モデル・機能モデルのうちの情報モデルをオブジェクトモデルに発展させただけであり、SA/SDとの概念的整合性もとれる。 現時点では、方法論としてOMTが最も精密であり合理的であるが、BoochもCoadも方法論の改善を図っており、今年中にも逆転があるかもしれない。いずれにせよ、この３つを中心としてオブジェクト指向のモデルと開発方法論が展開して行くであろう。
現在のOO-CASE、特に方法論を支援するツールは、ユーザーインタフェースがまだ不十分である。特に以下の機能が望まれる。 （１） 手法のガイド SA/SDでも明らかになったことだが、背後にある方法論を理解しないとCASEツールの効果はほとんどない。また、方法論の本を１冊読んだだけでCASEツールを使いこなす人間はそう多くない。従って、OOAToolにある戦略カード機能と評論機能のように、方法論をガイドする機能とチェックする機能が一体に組み込まれている必要がある。 OOAToolの場合、戦略カード機能は（変更は可能だが）単にテキストを表示するだけだが、今後はハイパーテキスト機能との連動が必要であろう。 （２） ハイパーテキスト OOA/OODは基本的にボトムアップの方法論なので、ユーザーは情報の洪水の中を泳ぎまわることになる。OMTのモジュールやCoad法のサブジェクトといった段階的詳細化のための機能だけでは、適切な情報にたどり着くことはむずかしい。そこで、ハイパーテキスト機能で情報間の関連を保持する必要が出てくる。 ObjectCastでは、任意のオブジェクトの注釈にハイパーテキスト機能を持たせていて、しかもユーザー定義可能になっていた。このような機能がOO-CASEの任意の場所で提供される必要があろう。
SA/SDは、自身の開発手順をモデル化することができ、その能力をある程度証明できた。同様にOOA/OODは、自分自身のモデルと開発手順を記述することによって、その能力を証明できなければならない。 ObjectCastは、その開発にあたって各図のツール毎にCoad法を使用しているが、全体を統括したモデルはまだない。OMTは、オブジェクト図エディターに自分自身を適用してモデルを作成したようであるが、やはり全体を統括したモデルはない。 OO-CASEは（たとえSmalltalkを使用したとしても）巨大なツールになる。自分自身の分析と設計に、自分自身のモデル技法と手法を当てはめるのが何よりも大事であろう。
OOSD, SoftBenchなどの下流工程を支援するOO-CASEは、ある程度、多人数による協同開発作業を支援してくれるが、OOATool, ObjectCastなどはまだ多人数による開発の支援機能が不十分である。いずれの場合も、CSCW（Computer-Supported Cooperative Work）[石井 91]的な、高度な協同作業支援機能を用意しているわけではない。 しかし、OO-CASEが対象にする主なタゲーットは、複雑なシステムを複数の人間で分析し設計していく、大規模システムの開発・保守であろう。この場合、複数の人間が、複数の版のモデルや仕様を協同で検討していくCSCW的な仕掛けが必須となろう。
本稿では、OOA/OODの主な手法とOO-CASEを調査し、その概要と問題点を提示した。そこで明らかになったことのひとつは、SA/SDはもはやOOA/OODの一部として包含されてしまったということである。特にOMTはうまくSA/SDを取り込んでいる。もうひとつ明らかになったことは、SA/SDを支援するCASEツールに比べ、OO-CASEはまだ統合的なツールとしての機能が完成されていないことである。もっとも、Smalltalkをベースにして開発されたOOAToolやObjectCastの開発スピードを見ていると、その差も早晩解消されるだろう。それまででも、SA/SDを支援するCASEを使ってOOA/OODを実行してみる価値は十分にあるだろう。 なお、多くの手法やCASEツールが開発中であり、本稿で対象とした手法やCASEツールも調査の直前に発表されたものが多く、調査はまだ十分とは言えない。今後も調査を継続していかなければならないと考えている。
同僚の酒匂寛氏には、[Rumbaugh 91] の重要性を指摘していただいたほか、 種々の文献の入手に協力頂いた。青木淳氏(富士ゼロックス情報システム)には、 各方法論の評価とCASEツールの入手に協力頂いた。土屋旨夫氏(横河ヒューレットパッカード)には、 C++/SoftBench関連の文献の入手に協力していただいた。 また同僚の佐藤圭氏には、Prographの入手に協力していただいた。 いくつかのソフトウェアやOO-CASEの情報は、WIDEネットワーク[村井 90]を通して入手した。 この場を借りて感謝したい。
参照のしやすさを考えて、翻訳があるものは翻訳本の方を入れた。