Fig. 9 クラスの階層構造 cl ass A i nt public; class Ba int public; class Ca i nt public, class Dba ;B i nt public, class Eba ;B i nt public; d; C, ;A b; ;A class Dba class Ba class class Eba Ca class を呼び出すことと解釈される。しかし , ポ インタ変数は , クラス B の変数を指している から , クラス B のメンバ関数を呼び出した とになる。このような問題を解決するため の機能が「仮想関数」てある。つまり , ポイ ンタの型と実際の型が異なっていても , プ ログラムの実行時にもっている型のメンバ Fig. 10 プロテクテッド class クラス名 { 非公開部 protected ; プロテクテッドメンバ public: 公開部 80 C MAGAZINE 1991 4 関数を呼び出すメカニズムてある。仮想関 数にしたいメンバ関数は , 基本クラスて、 「 virtual 」によって宣言する (List 15 ) 。仮想 関数と定義て、きるのはメンバ関数だけて、あ List 15 ては , 基本クラスのポインタ変数 にクラス B の変数 x のポインタが代入されて おり , 基本クラスの定義て、メンバ関数 print が仮想関数として宣言されているために p->print( ) て、は , クラス B のメンノヾ関数 print が呼び出される。 C 十十によるオフジェクト指可 プロクラミンクベのアプロ 最後に , オプジェクト指向の考え方によ るプログラミングを行うために必要な要素 と C 十十の機能を比較し , C 十十て、のオプジ ェクト指向プログラミグとは , どのような 形式になるか考えてみたい。 オプジェクト指向の基本的な構成要素は , 「オプジェクト」「メッセージ」「クラス」「イン スタンス」「情報隠蔽」「クラス階層」などて、あ ろう。オプジェクト指向プログラムて、は , オプジェクトにメッセージを送り , 受け手 側はメッセージによって処理を決定する。 この流れて、プログラムが実行される。 C 十十のクラス」かオフジェクト指向の 「オフジェク村 オプジェクト指向におけるオプジェクト とは「データと手続きの融合体」と定義され ている。 C 十十のて、クラスはメンバ変数にデ ータがあり , メンバ関数がそのデータへの 手続きて、ある。 C 十十でのメッセージ式は , クラス変数・メンヾ関数 ( 引数 ) オプジェクト指向プログラムは , オプジ ェクトにメッセージを送ることて、実行され る。メッセージは , オプジェクトに対して 動作の指示とみることがて、きる。「オプジェ クト」に相当するものが C 十十の「クラス」て、 あるとすると , オプジェクトにメッセージ を送る ( メッセージ式 ) ことが , 「メンバ関数 の呼び出し」といえる。 C 十十のクラスかオプジェクト指向での クラスであり , クラス変数がインスタ オプジェクト指向のクラスとインスタン スは , あるデータ型のデータに関する仕様 , つまりデータ型を「クラス」 , そのデータ型 て、割り当てられた領域や実データを「インス タンス」としていることから , C 十十の「クラ ス」がオプジェクト指向の「クラス」にあては まり , 「インスタンス」は , 「クラス変数」と みることがて、きる。 情報隠蔽の機能を C 十十はクラスによって実現 オプジェクト指向において , 情報隠蔽と いう言葉はよく用いられる。情報隠蔽は , オプジェクト内部のデータは外部から直接
も , fThe Practical Guide to Structured Systems Design 』という著書がある。また 前記設計技法て、示した構造化設計の強力な 推進者 , 提唱者て、もある E. Yourdan も , 最 近はオプジェクト指向設計に移行してきて いる。ただしオプジェクト指向は , 構造化 技法と相反する技法て、はない。プログラミ ング言語として考えた場合て、も , オプジェ クトは情報隠蔽 , 抽象化機能をもったモジ ュールとしての側面もあり , オプジェクト 指向型プログラミング言語て、は , 構造化定 理て、明らかにされた , 大域変数や GOTO 文 の排除などの大原則はつらぬかれている。 構造化技法て、は , オプジェクトを単位にシ ステムを分解していくという観点をもたな いだけなのて、ある。そこて、 , オプジェクト 指向に適した , 上流工程における方法論が 必要となってくるのて、ある。 オプジェクト指向分設 00A , 00D の文献 そこて、オプジェクト指向分析 , 設計技法 を考えなければならない。 じつは , OOA, OOD に関して , 欧米て、は かなり文献が発表されてきている。本誌 ' 91 年 3 月号の「オプジェクト指向への招待」て、オ プジェクト指向関係の文献リストを付録デ イスクに添付したが , そのなかて、最近にな って発表されたものの多くが , この OOA, OOD 関係て、ある。実際にはオプジェクト指 向概念自体 , まだ固まっていない部分があ り , そのソフトウェア開発の上流工程への 応用についても方法論的にまだ確立されて はない。しかし , オプジェクト指向手法に 基づくソフトウェア工ンジニアリングは , オプジェクトのもつ機能や性質から , Abstruc tion ( 抽象化 ) , Encapsulation()f ッケージ 化 ) , lnheritance( 継承 ) の 3 つが , 指導原理 とならねばならない 旧来の構造化技法においては , システム を分析 , 設計するのに , 機能やデータなど ・短期集中連載 をばらばらに分解して詳細化していった。 最終的にプログラムとして記述される言語 が , データと処理を分解して記述するノイ マン型のものて、あるため , それは当然のこ とて、ある。つまり開発言語によっては , そ の上流工程が制約を受けてしまうのて、ある。 システムの細分化 のではない。こうした分析や設計を行う 分析や設計作業も決して役に立たないも ばならない。間題が大きくなるにつれ , ェクト指向に基づいた観点へと変更せね 野であるわけであるが , に対してオプジ な問題 , それは実際にはすべての応用分 ドライバなどのプログラムからより大き たちは , ニ進木やキューそしてデノヾイス とに , 状況はそのままではない。今や私 要はなかったのである。しかし悲しいこ ため , だれも設計のために努力を払う必 は , 対象とする問題に強い関係があった のよく使われていたプログラミング言語 努力していた。なぜなら , Smalltalk など プルダウンメニューなどを作るために タックや , 円形バッファ , ウインドウ , のエンジニア諸君は , 再利用ができるス 「 1980 年代の初期には , オプジェクト指向 Objeect-Oriented 』から引用してみる。 実は , これがくせものて、ある。 TM0deling るかによって , 各手法にわかれるのて、ある。 の 3 つがあり , これらをどのように記述す ③オプジェクトの挙動 ( 動的情報 ) の確定 ②オプジェクトの構造 ( 静的情報 ) の確定 ①オプジェクトの抽出 ( 識別子 ) こうした方法をとる場合 , 必要な作業には , のが , 作業の大きな目標となるのて、ある。 確にし , 設計はその解決を表現する」という うに , 「オプジェクト指向分析は , 問題を明 DesignwithC 十十』て、も述べられているよ いく。『 Using CASE for Object-Oriented ステムの分解の単位として詳細化を行って 付随させたものとして , オプジェクトをシ 計て、は , データとそれに対する操作を融合 , それに対してオプジェクト指向分析 , 設 OOP 思考の周辺 ためには , 私たちが構築したいものを表 現する方法 , つまりオプジェクト指向ソ フトウェアの構造を表現するための表記 法を必要とする。構造化分析とその設計 モデルの成功した多くの事例を参考に オプジェクト指向のプロフェッショナル は , 各自みずからの表記法を考察してき たのである。 このことは , Yogi Berra( べラ師 , 誰 だろう ? ) がいったように , 「再び , いつか 来た道 ( dejavu ) 」なのである。このような 設計表記法の急増は , システムの複雑さ が , フローチャートやそれに類似した低 レベルのシステム表現法の有効性に影響 を与え始めている , ということに人々が 気づいた後 , ます構造化革命のときに起 こった。そこで , 多くの表記法が論じら れ試されたが , 実際的な根拠のあるわす かなものしか生き残らなかった。広く用 いられるようになった表記法の一つは , Constantine によって考案され , 多くの人 によって修正されたり , 広められたりし た構造化チャート (structure-chart) であ る。構造化設計の重要な要素である構造 化チャートは , ソフトウェア製品が単純 だったころの , 単純なモデルである。し かし構造化設計は , オプジェクト指向概 念とその考え方を提供するものではない。 時代はオプジェクト , クラス , メッセー ジ , メソッドの概念をもとに , 構造化チ ャートの効力を生かすような表記法を , 再び考えねばならない時期にきている。 多くの顧客や生徒たちの協力によって , 私たちは , 統一的オプジェクト表記法 ( UON ) を長期間に渡って開発してきた。表 記法は , オプジェクト指向方法論によっ て影響されるべきではない。表記法は , ユーザが構築し , 得るものを表現するこ とを可能にする。そして , 方法論は構築 するシステムをよりよくすることを可能 にするのである」 硬い , 学校英語っぱい訳なのはお許し願 00P 思考の周辺 69
OOP 思考の周辺 ・短期集中連載 オプジェクトの表現法 このように , 構造化技法の嵐が吹き荒れ ていたときにも表記手法が議論されていた。 しかし , それらのうちて、生き残ったのは , 「実際的な根拠」のあるものということて、あ る。今後はオプジェクト指向が多くのアプ リケーションにアプローチする過程て、 , 各 オプジェクト指向表記やこの統一的オプジ ェクト表記法の「実際的な根拠」が試されて いくて、あろう。 以下に , TModeling Object-Oriented 』て、 述べられている , 統一的オプジェクト表記 法 ( 以下 UON) に関するコンセプトについて 引用する。 「ます第一に , 私たちは UON を簡潔で直接 的なものにしたかった。そして , 記号に 関する用語を , 慎重で合理的な表現の原 理に根ざしたものとして選びたかったし , 以前に用いられていたような派手な記号 を用いるのも避けたかった。また , 私た ちは設計者の表現力を限定することがな いように , 用語の適切な量的パランスを も求めたのである。記法の構成要素が , 可能なかぎり表現している要素の意味構 造と一致していて , その記号が直感的に 表現しているものに近いような表現方法 を必要としていたのである。構造化設計 における構造チャートのように , UON は ソフトウェアの実際の構造を表現し , コ ードの表現は , 簡潔に間題解決のために 書かれなければならない。オプジェクト 指向プログラムと , UON におけるその表 現の間には , 単純な 1 対 1 の関係が存在し ているのである。 表記法においては , モデル自身を「社説 のように書く」こと , つまり主観をまじえ て表現するようなことは , 避けなければ ならない。いい換えれば , それはよい構 造と同じように , 悪い構造の表現をも許 容してしまう。しかしオプジェクト指 向技法は , けして確立されたものではな いので , 私たちは表現の自由を許容し , 70 C MAGAZINE 199 ! 4 開発者の発想を限定してしまうことは , 避けたかったのである。 汎用の表現技法は , 特定の目的に 依存せす , 多くのレベルの言語に対応し ている。オプジェクト指向言語に付け加 えて , 表記法は FORTRAN や COBOL など の言語においても , カプセル化がモジュ ールに限定されるような , オプジェクト 構造化 (Object-Structured) 開発を支援し なければならない。また , Ada や M0dula ー 2 などのような , データ型の定義ができ るオプジェクトべース (Object-Based) 言語 における開発も , 支援しなければならな い。もっとも重要なのは , 数多く試みら れているように , 幅広い構造化文化圏と の適合性のみならす , オプジェクトと関 数 ( 手続き ) 指向の両者の要素をもった , 複合的なシステムを表現することができ るように , 私たちは確立した構造化設計 表現技法との一貫性を保ちたかったので ある。多くのもっともポピュラーなオプ ジェクト指向型言語が , 関数的 ( 手続き的 ) とオプジェクト構造の , 複合パラダイム の言語であるがゆえに , 明確にオプジェ クト指向と伝統的な構造化の両者を形成 する能力をもっているということは重要 である。とくに構造化設計技法の直接さ と統一性などを保ちながら , 私たちはほ かの知られた表記法との , ある程度の一 貫性をも保ちたかった。」 こて、みるように けして旧来の構造化 設計を排除するものて、はない。これは , オ プジェクト指向開発を考える場合 , 非常に 重要なファクターて、ある。 UON はなおか つ , 記述言語を限定しない , 高度な表現力 をもった表記法を目指している。図式表現 としては , 「オプジェクト指向システムの構 造を , ーっのダイアグラムによって示そう と試みることはおそらく不可能て、ある」とい う前提から , 有効なオプジェクト指向開発 支援ツールて、あるために , クラス定義また はオプジェクトインタフェイスダイアグラ ム , 継承または , クラス階層ダイアグラム , オプジェクトコミュニケーションまたは隣 接ダイアグラム , そしてメソッド内部また はメソッド構造ダイアグラムの 4 つを備え ることになる。それらのダイアグラムの要 素は , オプジェクト構造ダイアグラム (Object Structured Diagram) に統合され , 非オプジ ェクト指向プログラムの要素とも完全に結 合されるわけて、あり , このオプジェクト構 造ダイアグラムが , 旧来の構造化設計上の 構造化チャートとインタフェイスをもつの て、ある。 なお , ここて、いわれている「ほかの知られ た記法」には , オプジェクト指向分析のため のものとして , 『 Object-Oriented Systems Analysis 』 (). Shlaer, S. J. Mellor 著 ) て、述 べられているものが有名て、ある。 オプジェクトはメッセージを受けること によって , 状態を遷移するものと考え , 従 来の情報モデル , 状態モデル , プロセスモ デルの統合によって , オプジェクトに基づ いた分析を行うのて、ある。要求分析段階て、 , InformationModel を作り , 構造化技法にい う , StateModel ( 状態遷移図 ) , Process Model ( DFD ) と組み合せることによって要 求仕様とし , その後の設計段階て、もこの lnfor mationModeI を使う。ここて、は lnformation Structure Diagram というオプジェクトの識 別子や属性名 , オプジェクト間の関係を表 現する図と , Overview lnformation Dia gram という , 概略ダイアグラムを図として 用い , Object Specification Document, ReIationship Specification Document そし て , Summary Specification という日諞ⅱ 述を用いるのて、ある。これは最近『オプジ ェクト指向システム分析』 ( 啓学出版 ) とい う表題て、 , 日本語訳が出版されている。 以上 , CASE の概略とオプジェクト指向分 析 , 設計と呼ばれる手法について概略を示 した。次回以降て、は , ます UON の具体的な 表記法についてふれる予定て、ある。
OOP 思考の周辺 0 CASE の動向 オプジェクト指向による開発は , プログラミングや処理系だ けにとどまらず , 企業の上流工程のシステム設計や分析など , 開発プラノニングにまで及んでいる。今回はそのキーワード である CASE を知るためにソフトの開発技法の流れを追う。 木戸研ー が試されるわけだが , それどころか開発チ 成熟した技法として行き渡っているといっ CASE にかかわる動向 ームや工程の管理まて、もが , オプジェクト こて、述べられているオプジ た観がある。 指向技術を意識したものて、なければならな ェクト指向設計 ( OOD ) やオプジェクト指向分 いともいわれる。 析 (OOA) は , その構造化技法に対するものと オプジェクトと CASE いう位置づけて、登場してきており , オプジ 同誌 10 月号の , Addle Goldberg, Kenneth 昨年の暮れから , 本誌提携の「 COM S. Rubin による「 Taming Object-Oriented ェクト指向技術だけて、なく , 構造化技法に Technology( オプジェクト指向技術を使い PUTER LANGUAGE 』誌に , あいついて、 対するある程度の前提知識を必要としてい こなす ) 」て、は , 「オプジェクト指向への転換 オプジェクト指向に基づく CASE(Computer は , コードだけて、なく企業のあり方をも転 Aided Software Engineering) 関係の記事 本稿て、はそれらの記事の単なる翻訳て、は 換させる」とし , プログラミングにかかわる が掲載された。『 COMPUTER LANGUA なく , CASE の動向や周辺の話題を折り込み チームや , その関係者の技術的なルール , ながら , OOA, OOD について考察していく GE 』誌 10 月号の MeiIir Page-Jones, Larry ューザのシステム観 , 企業の組織形態にま L. Constantine, Steven Weiss による「 M0del つもりて、ある。本誌 1 , 2 月号て、もふれたが , て、影響を与えると述べられている。 ing Object ー Oriented Systems: The l-Jni これらの記事は両者とも多少理解しにくい 上記のような , プログラミングの上流工 これはやはり構造化技法やほかのオプジェ form Object Notation( オプジェクト指向 程よりもさらに上流の企業組織にまて、オプ システムモデリング : 標準的オプジェクト クト指向開発技法などの知識を前提として ジェクト指向技術の観点から考察したもの いるからて、あろう。そこて、今回は , まず CASE 表記法 ) 」と , 11 月号の David K. TaYlor と は , おそらく初めてのものて、あり , 今後の についてこれらの記事と関係がありそうな AIan Hecht による「 Using CASE for オプジェクト指向開発を考えていくうえて Object ー Oriented Design with C 十十 部分について解説するが , 誌面にかぎりが 極めて貴重なものとなるて、あろう。また内 あるのて、説明不足の部分は , 適宜指摘する (C 十十によるオプジェクト指向設計のため 容的にも興味深いものてあるため , あえて 文献を参考していただきたい の CASE ) 」の二つがそれて、ある。 これら CASE に関連する内容て取り上げてい オプジェクト指向の動向は , プログラミ オプクト指向技術に ングや処理系のみにとどまらず , 上流工程 こうと考えている。 基づく開発 著者のひとりて、ある Addle G01dberg は , のシステム設計や分析 , そして最近て、はシ Xerox の PaIo Alto 研究所において Smallt 結論じみたことをいってしまえば , オプ ステムプランニングにまて、波及しつつあり , ジェクト指向技術に基づいた開発を行う場 alk ー 80 の研究 , 開発にかかわった中心的な人 無視することはて、きなくなってきている。 物として知られており , 現在は ParcPlace ただし , このソフトウェア工ンジニアリン 合 , 旧来の構造化手法に基づく分析 , 設計 Systems 社の President, CEO (Chief Execu グの分野には , 構造化設計 , 構造化分析な 技法がそのまま適用てきるわけて、はない tive Officer)< ある。 ど , いわゆる構造化技法が長く研究され , こて述べる新たな記法など そのために 00P 思考の周辺 65
C MAGA 「スマートアラームス」 マンタワークス株 マンタワークス株は , 株ビジョンシステ ムからスマートアラームスの販売権を獲得 , 日本語版スマートアラームスの発売を開始 、 0 スマートアラームスは , マッキントッシ ュの DA ( ディスクアクセサリ ) て , 時計とス ケジューラの役目をする。 55 年先まての 1 , 600 個の予定の設定が可能。 く動作環境 > Mac OS システム 6.04 以上 く価格 > 18 , 000 円 問い合わせ先マンタワークス株 〒 251 神奈川県藤沢市朝日町 13 ー 10 大沢ビル IF TEL 0466 ー 28 ー 4180 「オプジェクトオリエンテッドテクノロジー」 セミナー 「オプジェクト指向設計と C 十十」セミナー ソフトウェア・テクノロジーインターナショナル ソフトウェア・テクノロジー・インター ナショナルは , オプジェクト指向に関する 二つのセミナーを開く。 「オプジェクトオリエンテッドテクノロジ ー」セミナーは , 外国人講師による , オプジ ェクト指向理解に必要な概念を解説する ためのセミナー。内容は次のとおり。 ・オプジェクト指向と従来のアプローチと の違い ・オプジェクト指向の利点とリスク ・オプジェクト指向のツールおよび環境 く期間 > 4 月 9 日 ( 火 ) ~ 4 月 10 日 ( 水 ) く場所〉虎ノ門パストラル く費用〉 96 , 000 円 ( 逐次通訳つき ) 「オプジェクト指向設計と C 十十」セミナー は , 外国人講師によるオプジェクト指向技 術を使用したソフトウェア設計と実践によ るプログラミング演習を行う。オプジェク 146 C MAGAZINE 1991 4 ト指向によるソフトウェア開発の理解が目 A. 3 月 26 日 ( 火 ) ~ 3 月 28 日 ( 木 ) B. 4 月 23 日 ( 火 ) ~ 4 月 25 日 ( 木 ) A. 東京 YMCA ホテル B. 虎ノ門パストラル 145 , 000 円 ( 逐次通訳つき ) く費用〉 く場所〉 く期間〉 互換機シリーズ ・機種 80386 / 486CPU 搭載の PC ー 9800 / く動作環境〉 C ( GCC ) を使ったプログラム開発も可能 ・ FM-TOWNS に移植されている GNU ルデバッガ PTEX386 付属 ・ PARTNERVer. 3 と同機能のソースレベ が付属 オプジェクトがリンク可能なリンカ L386 ・デバッグ情報の出力や MASM , TASM の (High C386 ) て、の開発が可能 圧換性によって , この上て、動作する言語 ・ PharLap 社の MS-DOS 工クステンダとの ビット本来のプログラミング開発が可能 ・ 80386 / 486CPU の持つ広大なメモリと , 32 る。 EXE386 の特徴は以下のとおり。 Ⅲしたプログラムの開発 , 実行が可能とな リ空間を広げる。 32 ビット本来の環境を利 バイトから解放し , 最大 4G バイトまて、メモ EXE386 は , MS-DOS のメモリ上限 640K する。 作する 32 ビット用 DOS ェクステンダを発売 ト CPU80386 / 486 用のネイテイプモードて、動 京都マイクロコンヒ。ュータ株は , 32 ビッ 京都マイクロコンピュータ株 「 EXE386 」 32 ビット用 DOS 工クステンダ TEL 03 ー 5689 ー 3536 キングヒルズ白山 401 〒 112 東京都文京区白山 2 ー 25 ー 10 ・インターナショナル 問い合わせ先ソフトウェア・テクノロジ ・メモリプロテクトモード用増設メモ リ IM バイト以上 ・ OS MS-DOS Ver. 3.1 以上 ・ EXE386 開発キット く価格 > 43 , 000 円 ・ EXE386 ライセンスパック 100 198 , 000 円 ・ EXE386 ライセンスノヾック 1000 990 , 000 円 問い合わせ先京都マイクロコンヒ。ュータ株 〒 617 京都府長岡京市長岡 3 ー 1 ー 2 TEL 075 ー 953 ー 0963 「 Objectworks/ SmalItalk, Release4 」 富士ゼロックス情報システム株 富 I: ゼロックス情報システム株は , UNIX, Macintosh, MS ー DOS の標準的な ウインドウシステムを使用したオプジェク ト指向プログラム言語 Smalltalk によるカラ ーのアプリケーションを開発て、きる開発環 境「 Objectworks/Smalltalk, Release4 」を 発売する。おもな特徴は以下のとおり。 ・移植性 Objectworks/SmalltaIk て、開発された アプリケーションは , Objectworks/Smal ltalk が利用て、きるシステムに依存するこ となく容易に移植てきる。 ・再利用性 オプジェクトというまとまりて、プログラ ムを部品化て、き , ざまざまなオプジェク トを再利用してソフト開発の生産性と 品質を向上させる。 ・生産性 プラットホームの標準的なウインドウ システムの利用と , デバイスから独立し たカラー機能て , プラットホームの詳細 情報を修得することなくアプリケーショ ンの開発がて、きる。 なお , 日本語を利用するための「日本語
face-XX( ューザインタフェイス関係 ) など の名前て、システムクラスは登録されており , それらの範疇に含まれるクラスは , そのク ラスカテゴリ名を受けた形て、登録すること が慣例として存在する。たとえば , ユーザ が新たにユーザインタフェイス関係のクラ スを定義した場合 , Interface-XX, または XX-Interface といったカテゴリ名がつけら れるのて、ある。これは , 複数て、共同開発を 行う場合やプログラムを流通させる場合に は , 暗黙の決まりごとのようになっている。 同様に , メソッドに関しても , そのメソッ ドの大まかな役割に基づいて , メソッドの カテゴリが慣例として決まっている。クラ スメソッドについては , instance creation ( インスタンスの生成 ) や class initialization ( クラス変数などの初期化 ),example( サン プルメソッド ) などがあり , インスタンスメ ソッドには , accessing( 内部変数への参 照 ) , private( オプジェクト内部の操作 ) , initialize-release( インスタンス変数の初期 化と解放 ) , testing( 検査 ) , arithmetic ( 演 算 ) , comparing( 比較 ) など , オプジェクト などの情報をどのように操作するかに基づ いたメソッドカテゴリがある。これらは , 前述したように言語仕様として定義されて いるわけて、はないため , 原則として各プロ グラマが任意につけることがて、きるが , 実 際には慣例に従い , 共通のカテゴリ名がっ けられることが多い。このカテゴリは , 膨 大なプログラム群から , 目的のクラスやメ ソッドを効率よく発見するために , 非常に 重要な機能をもっている。 Smalltalk/V に は , このカテゴリが , クラス , メソッドと もに存在しないため , システム全体のプロ グラムを追いかけるのは若干困難て、ある。 そのため , Smalltalk/V には , Smalltalk-80 のようにシステムすべてを対象とした , シ ステムプラウザ (SystemBrowser) のようなツ ールは存在しない。オプジェクトは ,Fig. 4 に示すような , クラス階層プラウザ ( Class Hierarchy Browser) によって , クラス階層 1991 4 単位て、管理される。 Smalltalk-80 のシステ 128 C MAGAZINE ムプラウザに慣れた側からすれば , Smalltalk/ V のクラス階層プラウザは一見使いにくそう て、あるが , Smalltalk-80 の場合 , 目的とす るクラスのカテゴリやシステム全体のカテ ゴリ構成をだいたい把握て、きるようになる まて、は , かなり使いにくかった記憶がある し , 実際にシステムプラウザをそのままプ ログラミングに用いるということはまずな い。オプジェクト指向プログラミングて、は , クラス階層を意識しながら作業を行うのは 当然て、あるため , 実際の開発過程において は ,Smalltalk/V のようなクラス階層を管理 する , 別のプラウザを開き直して ( spawn す るという ) 作業するのが普通て、ある。結局使 う側の慣れの問題て、あろう。 SmalItaIk/V のプログラムは , このカテゴリに関する情 報をもたないため , Sma Ⅲ alk ー 80 て、そのま ま , 再コンパイルすることはて、きない ℃上の Sm 訓 ta 賑と 00P の将来 SmalltaIk/V と , SmalltaIk-80 を比較した 場合 , 総じて SmaIltalk/V のほうが , 処理が 速いように感じられる。これは , テキスト の処理などを , SmaIItaIk ー 80 に比べ簡単に 行っているため , 感覚的にそのように感じ られるわけて、ある。このように , SmaIItalk/ V は , SmaIItalk ー 80 の冗長な部分を削ぎ落と して , 簡潔にした比較的軽いシステムて、あ るという印象が強い こうしたところから , 8086CPU のメモリ制限にかかわらず , 一般 的なパソコンて、十分動かすことがて、き , 早 くからパソコン上の標準 SmaIItalk の位置を 占めることが可能て、あったといえる。しか し , オプジェクトのサイズが 64KB を超える ことがて、きないというのは , 実用に耐えう るシステムを作ろうとした場合 , 致命的と なる。そうした意味からは , Smalltalk/V 286 は , 容量速度とも大規模アプリケーション を開発する可能性をもったものといえる。 SmaIItaIk/V 286 は , スムーススクロールが 採用されるなど , かなり操作性に気を使っ た拡張もされており , Smalltalk-80 を使い 慣れた筆者て、も , かなり満足て、きる環境て あるといえる。 それに対し , Smalltalk-80 は , すべての プラットフォームにおいて一定の言語仕様 を満たさねばならないため , 80386 以上の CPU とはいえ , パソコンて、は重い環境てあるの は否定て、きない。簡単なアプリケーション を動かすだけても , プロセス管理からウィ ンドウのスケジューリング , 入力イベント の監視まて、 1 本のプログラムが行うという Sma Ⅱ talk ー 80 の宿命なのて、ある。 それては , 同じパソコン上のオプジェク ト指向型プログラミング言語として , 両者 はどのように切り分けられるのて、あろうか。 また , パソコン上て、オプジェクト指向は , 今後どのような位置を占めてゆくのて、あろ 「スペシ・ヤルレポート Methods , パソコン に搭載された SmaIItaIk 環境」 (TASCII 』 ' 86 年 7 月号 ) という ,Smalltalk/V の前身ともい える , Methods の評価レポートがある。キ ャラクタベースのパソコンて , Alto の思 想 , ひいてはアラン・ケイ氏の DynaBook コ ンセプトを継承する , SmaIltaIk-80 をいか に実現するかという , 数年前のレポートて、 あるが , 現在のオプジェクト指向の方向性 を考えるうえて、興味深い記事て、ある。その 記事は , このように結ばれている。 「・・・・・・ Smalltalk には人工知能というすて きな誘惑があるのだ。 Methds て、そのような ものがて、きないわけて、はないだろうが , メ モリも少ないし , 過剰な期待はしないほう がよい。それよりも , Methods にはもっと 重要な使命があるのだ」 ま i,SmaIItaIk( この場合もちろん SmaI ltalk ー 80 を示している ) と , Methods をはっ きり別の存在と考えている点に注目してほ しい。当時から , Methods( そして SmaIItaIk/ V) は , SmaIItalk ー 80 のたんなるサプセット て、はなかった。オプジェクト指向という , 強力なパラダイムに基づいた , 同じ名前を もつ , 別の言語処理系と考えられていたの て、ある。たしかに , 現在存在しているパソ
なお「 ModeIing Object-Oriented Sys tems 」は , OOD に関する一般的な手法につい て特定の言語を想定せずに表記法を中心に 解説したものて、あり , 「 Using CASE for Object-Oriented Design with C 十十」て、は , C 十十言語による OOD を支援する Cadre Technolugies lnc. の CASE ツールを実際に 用いた , いわば各論的なものて、あるため , 今回は「 ModeIing Object-Oriented Sys tems 」を中心に述べることにする。 CASE とは CASE ツール 計算機支援によって計算機ソフトウェア の開発を行おうとする CASE の考え方は , も ともと多くのバックログをかかえる EDP 部 門から起こったものて、ある。ご承知のとお り , 計算機のもっとも大きな利用分野は事 務処理て、あろう。 C 言語も主流になってきた とはいえ , COBOL ューザの人口にはまだま だおよばない。 Smalltalk-80 など , 何をか いわんやて、ある。この EDP 分野が慢性的に かかえる問題は , メンテナンス作業の負荷 とそれにともなうバックログの増大て、ある。 それを裏づける数字は , 各種 EDP 関係の書 籍や雑誌に毎号のように掲載されている。 それほどバックログは EDP 分野にとっては 重大な問題なのて、ある。このようなことが ソフトウェアクライシスとして指摘されて 以来 , その解決のためのアプローチがさま ざまになされてきた。ソフトウェアの生産 性を上げようとするアプローチて、ある。 このアプローチは一般に , 方法論として の構造化技法 , 道具としての第四世代言語 ( いわゆる 4GL ) の採用によって組み立てられ ている。そのなかて、 , この構造化技法を計 算機によって行おうとする試みが , CASE の 発想のもとてあるといわれている。「 CASE ツールー機能解説と活用のノウハウー』 ( 佐藤正美著 / ソフトリサーチセンター ) によ れば , CASE ツールという用語が用いられる 4 レコード 1 レコード 2 66 C MAGAZINE 1991 4 ようになったのは 1986 年からて、あり , CASE ツールとは 1 「構造化手法」を適用している 2 システム開発の全工程を自動化する という二つの要件を兼ね備えた EDP ツール のことをいう , としている。これからもわ かるように , もともと CASE というものが EDP 分野から発生したことを考えるならば , オ プジェクト指向との関連性は希薄に思える。 事実 EDP 分野はオプジェクト指向に基づく アプリケーションの検討が , 極めて行いに くい分野て、ある。 以前本誌連載記事「オプジェクト指向への 招待」て、述べたように , 「物」や「人」のレベル て、モデル化がて、きなければ , オプジェクト 指向を適用する利点があまり見えてこない 事務処理を「物」や「人」て、整理すると , 企業 の経営活動のシミュレーションになってし まう。このため帳票処理という最大の作業 がシステムのなかに埋没してしまい , シス テムのメンテナンス作業などの負荷がそれ ほど減らないのて、ある。またオプジェクト 指向自体がプログラミング技法としての側 面が強く , システム開発の全工程を自動化 する CASE とは馴染みにくいものとも考えら れる。 オプジェクト指向と CASE を結ぶ鍵は , じ つは構造化技法にある。構造化技法のもっ いくつかの問題点を解決する技法のひとっ として , オプジェクト指向採用の試みがさ れはじめているのて、ある。これは下流工程 においての構造化プログラミングからオプ ジェクト指向プログラミングへのシフトと 一致する流れとしてとらえると理解しやす い。そこて、構造化技法について少し整理し ておこう。 構造化技法 ソフトウェア開発における構造化技法と は , ソフトウェアを機能分解することによ り生産性・保守性に優れたプログラムを開 発するための仕様化技法群をいう。システ ム分析から , 設計・プログラミングにいた る開発の各フェーズごとに構造化手法が存 在し , それらを用いることによって , シス テム全体を明確にすることを主眼としてい TabIe 1 は , 「ソフトウェアの仕様化と 設計』 ( 花田収悦著 / 日科技連 ) から引用して 作成した , ソフトウェアに関する設計技法 Fig. 1 構造化チャート 修了標識 テータを得る システム 結果 処理をする 出力をする
拡張 C の C + + 定義する場合に非公開部と公開部があり , 操作することがて、きないと解釈てきる。外 スされる。このことにより , C 十十のクラス 部からは , メッセージ式によってデータ操 非公開部のデータは外部の関数から直接ア がこの情報隠蔽の機能をもっていることに 作を行うことになる。 C 十十て、は , クラスを クセスてきず , メンバ関数によってアクセ なる。 C 十十での派生クラスか クラス階層 クラス階層は , データの抽象化の程度に よって階層化し , 上位に階層情報を継承す ることて、 , C 十十て、は , データの抽象化はク ラスによって行われ , 階層化は派生クラス て、実現て、きる。 0 オプジェクト指向の基本的な構成要素は , ほかにもあるが代表的なものを C 十十の機能 と比較することがてきる。このようにオプ ジェクト指向の考え方てプログラミングを 行うための構成要素カ℃十十にも備わってい ることから , C 十十ても「オプジェクト指向 プログラミングがて、きる ( 可能だ ) 」といえる のて、あろう。 なお , 本連載の最後として , クラスを用 いた簡単なプログラムを付録ディスクに収 録した (SAMPLE. CPP)O 参考にしていただ 本連載の最初にも述べたが , C 十十はあく まても C 言語の拡張版てあり , C 言語の機能 に新しい機能を組み込むことて生まれた新 しい言語てあるといえよう。新しい機能を 組み込む過程て , オプジェクト指向の考え 方によるプログラミングを実現するための 機能が組み込まれたものてあって , オプジ ェクト指向プログラミング言語として設計 された言語て、はない 0 解説の中てはオプジェクト指向とかオプ ジェクトといった表現をあえてさけてきた。 また , C 十十のバージョンによる違いなどを 明らかにしないまま説明した。そのために 表現がうまく伝わらなかった箇所もあった ように思われる。この点 , お詫びするしだ いてある。本記事が今後 C 十十を取り入れよ うとする C 言語ューザの役に並てば幸いて、あ 1 1 : c lass A { 2 : int A() { a ま 4 : print() { VOid printf( ” a = %dYn" 6 : 7 : i nt 12 : 13 : VO i d 14 : 17 : c 1 ass C い A i nt 19 : public: 20 : print() { VOid printf(" c 言 %dYn" 22 : 23 : 24 : } : 25 : main() 28 : 29 : 30 : p->print(); 32 : 33 : B : b : print() [ printf(" b = %d*n ” List 1 : c 1 ass A { i nt a : 3 : public: 4 : print() { virtual VO i d 5 : printf( ” a = %d*n ” 6 : 7 : 9 : c 1 ass B : A int b : 11 : public: print() { VO i d printf(" b = %d%n" 14 : 17 : class C: A int 19 : public: 20 : print() { VO i d printf(" c %d%n" 23 : 24 : } : 25 : main() 26 : { A* p: 28 : 29 : 30 : p->print() : 32 : 33 : 0 拡張 C としての C 十十 81
コンを前提とした処理系て、ある Smaltalk/V と , 理想の仕様をもったハードウェアを想 定して , 仕様が作られた SmalltaIk-80 は , 同じプログラミング言語の方言バーション と考えるよりも , 同じ価値観 , 計算体系に 根ざす , 異なったプログラミング言語と考 えたほうが理解しやすいてあろう。オプジ ェクト指向には , プログラミングパラダイ ムとしての側面と , 人工知能やデータベー スのように , プログラミングよりも , より 高度な作業のためのパラダイムとしての側 面がある。結論からいえば , オプジェクト 指向のもっこの二つの側面が , パソコンと いう場ては , SmaIItaIk-80 と SmalltaIk/V の 二つの処理系に反映しているように思えて ならない。人工知能というのは , 特異な分 野て、ある。この世界ては , 計算機の実行効 率やハードウェアスペックなどはあまり問 題にならない。それどころか , 計算機を対 象にしない認知科学などという分野も , 人 工知能の重要な一分野てある。 こうした価 値観は , 上流作業としてのオプジェクト指 向にもつながるものてある。オプジェクト 指向の世界ては , オプジェクトとメッセー ジという概念てシステムを考えるわけてあ り , データとプロシジャー , そしてそれら を動かすプロセスという観点から物事を考 え , 計算機の構造を見ないようにしてしま う。そのことによって , 計算機の構造を離 れた , 人間の知識が適切に表現てきるのて ある。 Smalltalk-80 は , メディアとして機 能する DynaBook に基づいて生まれたわけて あり , 人間の思考や相互のコミュニケート のための支援システムてあるという性質 , ひいては人工知能向きの言語て、あるという 性質は , パソコンて動こうとも変わるもの てはない。 Xerox 社から , PARC Place Systems 社に商標も含め譲渡された Smal ltalk ー 80 が , 現在正式な製品名を , Object Works for Smalltalk-80 と称することから も , そうした側面がうかがえる。それに比 べ ,Smalltalk/V は ,パソコンという限られ た資源を前提としていることからもわかる ように , プログラミングパラダイムとして のオプジェクト指向という側面を重視した もの , つまり人間の思考をどのように表現 するかというよりも , プログラムをいかに 効率よく記述するかという部分を重視した ものてある。 SmaIIItaIk-80 が , 人工知能に 代表されるような , より高度な人間の知的 作業のための環境て、あるとするならば ,SmaI ItaIk/V は , もう少し計算機よりの , プログ ラミング作業の実験環境としての役割に期 待があるといえようか。 80386 のような高い 機能をもった CPU を登載したパソコンは , パーソナルな使用に限定されるようなレベ ルの能力のものて、はなくなってきている。 そこに , オプジェクト指向という強力なパ ラダイムをもったプログラミング環境が稼 働することにより , プログラミングシステ ムとしても , より高度な作業のためのシス テムとしても , 十分に機能するだけの資源 はそろいつつある。あとは , 私たちが計算 機によって , 何をするかて、ある。 言語と Sm 訓 ta 賑ー 80 の ンタフェイス あまり知られていないが , Smalltalk-80 ては , Ver. 2.3 以降 , C 言語て記述された関 数を呼び出すことがて、きる。これを , User Define Primitive( ユーザ定義プリミティ プ , UDP) と呼ぶ。これに関する情報は , そ の恩恵のわりに非常に少なく , Advanced User's Guide の中て若干触れられているだ けてある ( もちろん英語 ) 。勝手に翻訳する わけにはいかないのて , 筆者が実際に試み て知りえた範囲について , さしつかえない 程度にレポートする。 Smalltalk ー 80 てはす べてのソースコードが , 仮想マシンて実行 てきる中間コードにトランスレートされる。 これが SmaIItaIk ー 80 のコンパイルてあり , この中間コードをバイトコードと呼ぶ。バ イトコードは , その名のとおり 1 バイト分の 命令 , つまり 256 種類の命令しか存在しな い。この仮想マシン中のバイトコードの解 釈機構 ( バイトコードインタブリタ ) は , プ 最新ロロロロレポート ルーブックの 28 章に記載されている ( 27 章の 「 Specification of the Virtual Machine 」以 降 , SmaIItalk-80 のインプリメンテーショ ンに関する部分は , 原則として日本語に翻 訳されていない ) 。以下に述べる部分は , 27 章以降に関連するものだが , 詳細はプルー ブックを参照していただきたい。 さて , SmaIItalk-80 中には , プリミティ プと呼ばれるメソッドが用意されている。 それは , 仮想イメージ中て、解釈されるのて、 はなく , 仮想マシンて、実装されている処理 て、ある。以下に , プルーブックから , プリ ミテイプを用いたメソッドの例を一部引用 する。これを見てわかるとおり , 高速な処 理を要求するものやハードウェアよりの低 レベル処理を行う場合に , このプリミティ プメソッドを用いる。このプリミテイプに ユーザ定義の C 言語による関数を用いること を可能にするのが , ' こに述べる UDP て、あ る。なお , プリミテイプは番号によって識 別され , ユーザ定義プリミテイプとして使 用てきるのは 10000 から 19999 まて、てあるら しい。これらの番号に , 自分の定義した C 言 語の関数を割り当て , SmaIItaIk-80 の仮想 マシンのプログラムをコンパイルして , 新 しい仮想マシンを作り直すことになる。 1 2 3 4 5 6 7 8 9 10 ( 省略 ) 114 113 112 111 110 SmallInteger SmallInteger SmaII lnteger SmallInteger SmallInteger SmaIlInteger SmallInteger SmallInteger SmallInteger Sm alllnteger Object Character 十 く = SystemDictionary coreLeft SystemDictionary quitPrimitive SystemDictionary 最新開発環境レポー ト 129
△ SmaIItaIk-80 Sma Ⅱ k -80 が PC -9801 ( 80386 搭載機 ) に対応。 オプジェクト指向のコンセプトを最も忠実に実現したオプジェクト指向型ソフトウェア 環境「 Sma Ⅲ alk ー 80 システム・パッケーに PC ー 9801 仕様が登場しました。豊富な クラス・ライプラリを提供し、高いパフォーマンスを実現。また、 UN Ⅸワークステーション からパーソナルコンヒ。ュータまて Sma Ⅱ talk 一団上て、の極めて高い移植性を提供します PC -9801 仕様英語版 . 120.000 円日本語機能付 : 140.000 円 ( 消費税別 ) SmalltaIk-80 舮 X 富 5 m Package Sma Ⅱ t 引 k -80 システム・バッケージ適応機種 ・ PC -98 田 ( 80386 搭載機 ) ・ Macintosh シリーズ ・ 386 MS-DOS( 旧 M/PC 、 AX) ・ Sun 3 、 Sun 4(Sun SPARCstation) ・ DECstation ・ HP9000 シリーズ 300 ・ A ロ 0 ⅱ 0 DN3000 / 4000 シリーズ ・ NEWS -14 / 1700 / 1800 / 1900 シリーズ Sma Ⅱ ta ⅸー 80 アプリケーション・バッケージ G 「 a ロ he 「 Gea 「 ( Sma Ⅱ t k -80 アプリケーション醗ツール ) HLJM 日 LE ( エキスパートシステム構築環境 ) SP 「 eadSheet ( オプジェクト指向型スプレッドシート ) ST - P 「 0 g ( Sm 訓 ta 賑 - P 「 0 に g 統合プログラミング環境 ) LJnit 引 k -80 ( 視寛的 IJN Ⅸ環境 ) Sun 、 HP のみ 士ゼロックス情報ンステム株式会ネ 1 〒 0 東京都新宿区西新宿 3-16-6 谷 ( 03 ) 3378-8011 ( 代表 ) * Sma a ⅸ - は米国バークプレースシステムズ社 ( Pa 「 c 曰 ace Systems 旧 c. ) の商標です。 * IJN Ⅸは米国 AT & T 社ベル研究所で開発したソフトウェアの名称です。 * 記載の機種名は各社の商標、登録商標です。 く資料請求番号 004 〉