ホーランドジャノレ lnformation from C0mpiler Makers Q クラスのオプジェクトを const 型として宣言すると , メンバ関数 が呼び出せなくなるのですが , ど うすればよいのでしようか。 A const 修飾子をつけたクラス型 のオプジェクトて、は , その値を変 更しないことを保証しているメン バ関数しか呼び出せません。 普通に宣言したメンバ関数て、は , クラスオプジェクトのデータ部分 を変更する可能性があるため , コ ンパイラに呼び出しを拒否されて しまいます ( Fig. 1 ) 。 const 型のオプジェクトに適用す るためには , Fig. 2 のようにしてメ ーを ンノヾ関数定義後に、、 const 〃宣日 加え , そのメンバ関数がオプジェ クトの値を変更しない とを宣言 してください Q Turbo C 十十に付属している クラスライプラリとはなんですか ? A クラスライプラリとは , C 十十 が C から拡張されたもっとも重要な 機能て、ある「 class ( クラス ) 」機能を フルに使った , オプジェクト指向 版のライプラリ集て、す。 従来の C のライプラリは , 簡単な 入出力や演算 , ソートなどの「サプ ルーチン」単位の機能が標準ライプ ラリとして定義されていましたが , C 十十のクラスライプラリて、は , 「連 結や分解などの演算機能をもった 文字列」や , 「ソート可能なデータ の集合」などといった , 「データ構 造」単位のライプラリとして定義さ れています。 150 C MAGAZINE 1991 6 さらに Turbo C 十十のクラスラ イプラリのほとんどは , 共通の仮 想関数を継承していて , 起動する メソッドは実行時に決定されます ( レイトバインディング ) 。 このクラスライプラリを使うユ ーザは , C 十十が提供する「クラス の派生」機能を使い , 自分て、定義し た新しいデータ構造を , クラスラ イプラリが提供するクラスを継承 したクラスとして定義すれば , も とのクラスがもっていた機能を受 け継ぎながら自分て、定義したデー タやそれらを操作する機能をもっ たクラスが簡単に作れます。 クラスライプラリに含まれてい るクラスの一覧を Table 1 に示し ます。おもなものを簡単に紹介し ましよう。 ・ Object クラスライプラリに含まれてい るクラス定義の基本機能を定義 しているクラスて、す。 Object ク ラスは , そこから派生したクラ スの基本機能の定義を行う抽象 クラスて、す。 Object 型から派生したクラス は , Object 型て、仮想関数として 定義されているメンバ関数を用 意しなければなりません。直接 この型のオプジェクトを生成す ることはて、きませんが , Object 型へのポインタを定義すれば , こから派生したすべてのクラ スのオプジェクトをポイントて、 き , Object 型て、定義されている メンバ関数を適用することがて、 きます。 ・ Sortable 大きさを比較て、きるオプジェク トの基本クラスとなるクラスて、 す。このクラスは , Object クラ スに , オプジェクト間の大小関 係を比較するためのメンバ関数 を追加したものて、す。 ・ Association ふたつのクラスを組み合わせた クラスを定義する例として , ク ラス Dictionaly て、使用するクラ スて、す。 このクラスて、は繹まれる片方の クラスを検索用のキーとし , も う片方のクラスをその値として 使っています。 このクラス自体も Object 型から 派生し , 内部に含まれるふたっ のクラスは , private 部に「 Obj ect& 」として定義されているこ とに注意してください このよ うに記述すると , 明示的にポイ ンタを使わなくても , 特定のク ラスとそこから派生した ( 大きさ の不定な ) オプジェクトをクラス のメンバとして扱うことがて、き ます。 ・ Contain クラス Object から派生した複数 のオプジェクトをまとめて取り 扱うための基本機能を定義して いるクラスて、す。 ・ Stack FILO(First ln Last Out) 型のデ ータ集合を実現するクラスて、す。 ・ Queue FIFO(First ln First Out) 型のデ ータ集合を実現するクラスて、す。 ・ Deque 一次元リストの先頭と最後のど ちらからて、もデータの挿人 / 削除 が行えるデータ集合を実現する クラスて、す。 ・ CoIIection Container クラスにオプシェクト の追加 / 削除や , オプジェクトが Turbo C Ver. 2.0 Turbo C 十十 Ver. 1. O 集合に含まれているかを判定す る機能を追加したクラスて、す。 ・ HashTable ・ Bag 要素間に順番や大きさが存在し ない集合を取り扱うクラスて、す。 これらは名前が違うだけて、 , 実 際の定義は同じものて、す。 ・ Set 要素の重複を許さない集合を扱 うクラスて、す。クラス bag から導 出され , 要素の追加時にすて、に 同じものが登録されているかを チェックするようにしたものて、 す。 ・ dict. h クラス Association から導出され たオプジェクトの集合を扱うク ラス、、 Dictionaly" を定義してい ます。 ・ List 単方向線形リストを取り扱うク ラスて、す。リストの先頭に対し てのみ挿入 / 削除が可能て、 , 先頭 から後ろに向ってのみ検索が可 能て、す。 ・ DoubleList 双方向線形リストを取り扱うク ラスて、す。リストの両側に要素 が追加て、き , また任意の方向に 検索て、きます。 ・ AbstractArray ランダムアクセス可能な集合を 取り扱うクラスて、す。 ・ SortedArray 要素の順番がその値によって決 まる集合を取り扱うクラスて、す。

OOP 思考の周辺 3 何 Cadre 手法 今回は C 十十を用いたオプジェクト指向設計と CA E について , 『 COMPUTER LANGUAGE 』誌 ' 0 年 1 1 月号の記事「 Using CASE fo 「 Object- Oriented Design with C 十をもとに考察する。 木戸研ー には , 本来 CASE がもつ計算機支援によるソ ト指向の状況が見えるのて、ある。とくに オプジェクト指向の フトウェア開発の自動化 (Computer Aided 今回取り上げるものは , 10 人年て、 15 万ステ ための表記法 Softoware Engineerling) といった方向性は , ップにおよぶ C 十十のソースコードを書いた どちらかといえば , 希薄て、ある。むしろ , オプジェクト指向が完全にプレークした Cadre TechnoIogies lnc. の経験に根ざすも 米国て、は , オプジェクト指向技術をより実 CASE によって提唱されているいくつかの表 のて、あり , オプジェクト指向開発の実践を 記法を , 旧来のドキュメントの代わりにオ 考える場合 , 非常に興味深いものといえる。 際的に開発に用いる段階にきており , 上流 プジェクト指向開発の中て、機能させようと 工程への応用が重要なテーマとなっている。 こうした , C 十十を用いたオプジェクト指 いった目的のほうが重要てある。そのため , 向設計を行ううえて、のいくつかの点を , Cadre 本誌て、も , 先月号 ( ' 91 年 5 月号 ) の℃ OMPUTER これらの記事て、もツール自体よりも表記法 Technologies lnc. ては基本的な問題として LANGUAGE 』誌提携記事として , 「 Object- Oriented Structured Design for C 十十」が に焦点が当てられている。 下記の点を指摘している。 今回の連載て取り上げる二つの CASE 関連 ・ C 十十は , 高級プログラミング言語ではあ 掲載されており , 本稿て、も C 十十と CASE を の記事は , そうしたソフトウェアの仕様化 るが , 直接開発言語を想定してシステム 取り上げるのて、 , 内容が重複してしまうこ 技術としてとらえた場合 , 非常に興味深い 設計を行うためには , 十分に豊かな機能 とになるが , 米国の計算機技術を巡る状況 前回の「統一的オプジェクト表記法 (Uniform をもった言語ではない を反映したものとして , ご容赦願いたい ・同社がオプジェクト指向技法による開発 Object Notation) 」は , 構造化開発において オプジェクト指向に基づいてシステム開 用いられる構造化チャートを , オプジェク 発を行う場合 , 既存の開発技法やプロジェ プロジェクトを開始した 1986 年当時 , オ プジェクト指向設計を支援する手法や ト指向のために拡張したものてある。今回 クト管理技法などが , そのまま適用される CASE ツールが存在していなかった というわけてはない。上流から下流まて , の Cadre Technologies lnc. の Teamwork CASE ツールは , データベース , データモデ ・プロジェクトを開始した以後も , そうい オプジェクト指向にシフトする必要がある った手法はまったく広まらなかったし , ルの世界て用いられる E ー R モデル ( 実体ー関連 とまていわれるが , とくに実際の開発の現 モデル ) ダイアグラムを中心に用いて , オプ 文献なども出版されなかった 場て、問題になるのは , ドキュメンテーショ ジェクトの仕様化を行っていくものてある。 こうした理由から , 本稿に述べる手法 ( 以 ンて、ある。現在用いられているシステムの つまり , オプジェクト指向のための表記法 下 Cadre 手法と呼ぶ ) が提起された。以下 仕様化技術としては , 構造化技法がもっと を最初から作り上げたのてはなく , 既存の に , David K. TayIor と AIan Hecht による も重要なものてあるが , そこに含まれるい さまざまな仕様化技法をオプジェクト指向 「 Using CASE for Object-Oriented Design くっかのチャートては , オプジェクトとい のために修正したり , 拡張したりしてカス withC 十十」 ( C 十十によるオプジェクト指向 うもっとも基本的な要素自体を表現するこ タマイズしていったものてあり , こうした 設計のための CASE ) を紹介する。なお , 本 とすら , そのままてはてきない。オプジェ ところに実践を指向した米国のオプジェク 解説は原記事の翻訳そのままてはなく , 適 クト指向とのかかわりあいて述べられる CASE 67 00P 思考の周辺

OOP 思考の周辺 ・短期集中連載 送られる , すべてのサプクラスのメソッド こうした内容をもつ Cadre 手法は ,CASE なる。 呼び出しは表示しない。このことを最初は 手法や表記法の誤用かもしれないが , 実際 とくに , 分析結果をどのように設計作業 設計手法として誤りて、あると感じるかもし にオプジェクト指向設計を行うに際し , 非 に反映させるかが , 大きな問題となる。 れない。しかし実際には , このことがオプ 常に有効て、ある。 Fig. 2 , Fig. 3 に示した表 の Cadre 手法は , 分析に用いられる実体ー関 ジェクト指向設計を失敗させる可能性のあ 記法は , 間題に対して , 高 , 低 , 両レベル 連図を , クラス設計という , 手続き型プロ る点 , つまり「決定的な局面」て、もあるとい の観点を設計者に提供する。設計結果の複 グラミングて、は行われない作業に利用する ことを理解いただけると田 - 雑さは , 表記の複雑さに反映されるものて、 ことて、 , この分析と設計の間の調整を行っ フ ・じ、フ 0 SmalItaIk て、は , こうしたクラスは , サプ ある。 ているということが特徴て、ある。 クラスて、メソッドが実装されるため , メソ ただし , Cadre 手法て、は , これらの表記法 実体ー関連ダイアグラムは , オプジェクト ッドをもたないことがある。それを抽象ク を拡張して , 誤って用いているのて、 , いく 指向設計 CASE ツールとして , 非常に有効な ラスと呼び , 実際にメッセージが送られて っか問題もある。たとえば , 本来 ASG と ERD 設計クラスプラウザ ( 設問環境 ) として応用 は , オプジェクト指向の概念て、はなく , Ada メソッドを実装しているのは , その抽象ク て、きる。設計クラスプラウザは , 設計者に ラスのサプクラスて、ある。しかし , 明確に と , 情報モデル (lnformation modeling) の概 わかりやすくクラス階層を表示することが なっているクラスに対するメッセージのみ 念を用いるものて、ある。これは , 既存技術 て、きるのて、ある。 のオプジェクト指向の応用による , 実際的 を記述するのは , 以下の理由て、正しいと確 分析段階て、 , この実体ー関連図を用いる な問題解決方法て、あるといえるて、あろう。 信する。 Mellor らのオプジェクト指向分析は , オプ 動的結合メカニズムは , オプジェクト指 Cadre 手法て、は , もうーっ , メソッド設計 ジェクト相互の静的な関係を記述するのに のために , 構造化チャート ( SC ) の誤用も行っ 向プログラミングに必須なものとされる。 適しているが , オプジェクト指向設計への しかし , 各メッセージについて , こうした ている。アプローチ方法は , ERD をクラス つながりが明確て、はないという批判をしば 設計に用いる場合と , 基本的に同じて、ある。 メカニズムを詳細に記述するということは , しば受けてきた。 Cadre 社の多くの C 十十プロジェクトが , 手続き型の高級プログラミング言語て、の , それに対する回答のうちの一つとしても , 各サプルーチンの呼び出しの間て、 , CPU の の SC を用いることによって , 成功をおさめ この Cadre 手法をとらえることがて、きる。そ レジスタの状態を記述するようなものて、あ てきた。この SC は , 基本的には ASG による うした意味から , この「 Using CASE for る。また , マルチに送られるメッセージを 仕様化と同じ目的をもっており , 両者とも , Object-Oriented Design with C 十十」は , 隠蔽されたデータに対する手続き的なイン 己述した図は , 読み取るのがより難しくな 非常に価値のある論文て、ある。 ってしまうて、あろう。 タフェイスを示している。 最近 , オプジェクト指向設計に関する文 SC の情報隠蔽モジュールは , どのような メンバ変数やメソッドは , ASG て、はパッ 献が数多く刊行されている 0Cadre て、は , ど ケージモシュールの端に , サププログラム 手続きて、データを参照するかは詳細には示 の手法が , CASE として自動化するために最 さないが , ASG のパッケージは , それを詳 やデータオプジェクトを記述することて、表 適な候補て、あるかを調査をしてきたが , 既 現される。これは , そのメンバがパプリッ 細に示してしまうという相違点がある。 存の ERD, ASG, そして SC を拡張して用い 「 Using CASE for Object ー Oriented ることは , 現実世界のオプジェクト指向設 クて、あるということを示している。もし , DesignwithC 十十」て、は , この点について メンバがプライベートて、あるならば , パッ 計問題を支援することに対して有効てある。 も解説しているが , ASG と基本的に同じて オプジェクト指向設計における , クラス ケージモジュールの端からは , 離れて示さ あり , 誌面の制約もあるのて、 , 今回は省略 れる。メッセージによって送られる引き数 設計とメソッド設計の二つの側面は , 複雑 する。 は , メッセージ中の「データ結合」として示 なシステムに対するアプローチのためには 必要な要素て、ある。 こうした手法と表記法 される。 Cadre 手法て、は , オプジェクトもこの「デ の成熟に従って , CASE ツールはより有効に ータ結合」として記述する。なぜならば , メ 機能していくて、あろう。 以上が , Cadre 手法の概略てある。オプジ ッセージによって送られるオプジェクトが 前回取り上げた UON の筆者にいわせれ ェクト指向設計は , オプジェクト指向ソフ 複数ある場合 , これを用いると , 各オプジ ば , 自分のオプジェクト指向設計の表記法 トウェア開発のライフサイクルと , より緊 ェクトを識別することがてきるからてある。 をもたないソフトウェア工ンジニアは , 「 most 密に統合しなければならない。構造化手法 メッセージ中の「データ結合」は , メソッド unusual 」なのてある。 ては , 各フェーズ間の情報の同期が問題と 間の結合を評価するのに有効てある。 1 三ロ まとめ 00P 思考の周辺 73

詳細を満たすために用いるのて、ある。そう ーとは , そのオプジェクトと関係をもつオ スタンス群は特定の名前以外は同じて、あり , ことから , クラス設計とメソッド設計 プジェクトが , そのオプジェクトを見つけ クラスの仕様の変史は , ASG 上の各インス の両方を結合した図には , 以下に示すよう 出すための識別子のことて、ある。 タンスにも表現されなくてはならないから 一般に実体ー関連図て、は , 項目の先頭に な欠点がある。 て、ある。クラスの各メソッドは , クラスパ ・メソッド設計は , より詳細であるため , 、、 * 〃をつけて , キーて、はない項目には、、 ッケージのサププログラムとして表現され 多くの情報をもっており , クラス設計を をつけて表示されるが , Cadre 手法て、はキー る。その , 最初の手がかりとしては , 分析 視覚的に圧倒してしまう。図からクラス となる変数には @ 〃が , それ以外の変数に DFD における処理過程が , メソッドとして はヾ十〃がつけられる。また , オプジェクト 設計が見えない場合 , その図を用いてオ 実際の名前に置き換えることがて、きよう。 のメンバ変数が , ほかのオプジェクト中に プジェクト指向開発を行うわけにはいか メンノヾ変数は , ノヾッケージにおけるデータ ない。なぜならば , クラス設計は基本的 ある変数を参照している場合 , 変数名の最 オプジェクトとして表現される。つまり実 な開発の枠組みであり , そのクラスとメ 後に ( R ) を付加することによって , 明確に表 体のもっている属性は , C 十十メンバ変数と ソッド設計が結合した図は , 設計におい なるのて、ある。 現する。 て「決定的な部分」をあいまいにしてしま クラス game node からは , キーとして変 数 address が抽出される。クラス animal と つ characteristic ( 特徴 ) は , 同様に address をキ ・メソッド設計は , それ自体で多くの情報 ーとして継承する。クラス animal のキーて、 をもっている。そのため , クラス設計情 クラスの各メソッドのために , Cadre 手法 報をそれに付け加えることは , メソッド て、は , ほかのクラスに送られるメッセージ ある animal name は , 2 番目のキーとなり , 設計自体を非常にあいまいなものにして をメソッドの要求として表現する。もし , @ 2 〃のように表示される。分析段階て、得ら れた , クラス animal の属性て、ある , 変数 arti あるクラスのメソッドがメソッド名をもっ ・単一のメソッド設計図は , 一般に単一の cle は animal name に結合され , answer は 2 ているとするならば , 単純にこのメソッド 進木の再帰的な流れに含まれてしまう。 クラスに焦点をあてる。ほかのクラスは , 名をメソッドの要求として記述すればよい おもなクラスに対するインタフェイスを しかし , オプジェクト指向設計のためには , 示すために , クラス内部の詳細情報なし ポリモフィズム ( 多態 ) や動的結合をも仕様 に描かれる。そこで , 継承の木のように , 化て、きなくてはならない こまて、 , オプジェクト指向によるクラ 多くのクラスを巡るクラス階層の設計は , すべてのメッセージは , オプジェクト ( 特 ス設計の全体に焦点を当てて考察してきた。 多くの結合した図を越えて分割される 定のクラスのインスタンス ) に送られる。設 クラスの概略を描き終えた後 , 個々のクラ 前述したように , Ada は , 継承やクラス階 計時点て、はメソッド内からメッセージが送 スとメソッドについて考えなくてはならな られる特定のクラスはわからない。つまり , 層などをサポートしていないため , ASG も それらの機能をもたないが , Cadre 手法て、 オプジェクト指向型のプログラミング言語 い。この詳細なクラス設計のために , Cadre 手法て、は ASG を用いる。特定のクラスは , は , メッセージとメソッド本体が動的に結 は , そうしたデメリットをむしろ情報の整 大きな長方形によって表現され , 内部モジ こうし 合されるため , 実行時て、なければクラスが 理のために活用している。ただし , たチャート本来の機能を拡張した用い方を , 確定しないのて、ある。 ュール仕様の設計のために , 内部にアイコ この筆者らは「誤用」と呼んて、いるのが興味 ただし , 設計時点てメッセージの相手側 ンが描かれる。クラス間て、送られるメッセ オプジェクトの手がかりをもっことはて、き ージは , 特定のクラスのメソッドから , ほ 深い 各クラスは , ASG においては , Ada のパ かのクラスへの要求として表示される (Fig. ッケージとして表現される。 Ada のパッケー たとえば C 十十て、は , 少なくともオプジェ ジは , 正確にいえば , クラスて、はない。同 ーっの図に , 設計情報 ( クラス設計とメソ クトの基本クラスがわかるし ,SmaIItaIk て、 じクラスに属する各インスタンス ( つまりオ は , 既存のクラスライプラリ中のスーパー ッド設計 ) を詰め込みすぎないということが プジェクト ) は , 同じ構造をしている。それ 重要て、ある。クラス設計とメソッド設計は クラスやクラス Object 自体がメッセージが 相違する作業てあるため , それらは別個に 送られるオプジェクトの手がかりとなり得 が , 同じクラスて、あるということを示して 表記されなくてはならない。システムの設 もいる。 るのて、ある。 Cadre 手法て、は , これらの明確 Cadre 手法て、は , 各オプジェクトをパッケ 計者は , ERD を多くのクラスを抽出するた になっているクラスのみに対するメソッド ージにする必要はない。なぜならば , イン めに用い , プログラマは ASG を各クラスの の呼び出しを記述する。そして , 実行時に メッセージの表現 羊細なクラス設計 72 C MAGAZINE 1991 6

る。それは , 問題を構成するすべてのオプ て、ある。 宜 , 解説などを付け加えた。 ジェクトを含んだ観点を必要とするため , メソッド設計は , 構造化設計の手続き設 なお , この Cadre Technologies lnc. は , 構造設計など , 高度なレベルの設計に似て Teamwork CASE ツールファミリーを主要 計に類似している。メソッドは , メッセー ジをほかのオプジェクトに送り , それによ いる。よいクラス設計はメソッド設計の枠 な商品としてもっ CASE ツールのべンダーて、 あり , 筆者のひとり David K. Taylor は , って受け手のオプジェクトのメソッドを呼 組みを決定するため , プロジェクトの成功 同社のソフトウェアェンジニア , コンサル び出す。設計作業においては , メソッドが に対して決定的なのて、ある。 よい擬集関係をもち , ほかのオプジェクト タントて、ある。また , AlanHecht は , 同社 C 十十の場合 , 分析の工程て、は問題の中の をスヒ。ンアウトして , 現在は ,MesaSystems やメソッドと , 強い結合関係をもたないよ クラス群が抽出されるため , システムの設 うに注意しなければならないこうした Cadre GuiId lnc. の社長職にある。 計者は , 各クラスのメンバ変数と関数に従 って , どのクラスが必要て、あるかを決定す 技法における , オプジェクト指向設計の指 オプジェクト指向設計 ( 00D ) る。また , 設計においては , 特定のクラス 導原理は , 構造化設計と共通するものて、あ からどのクラスが継承するか , またメンバ 構造化技法て、は , システム開発の過程を 変数によって , どのクラスがほかのクラス システム分析フェーズ 大きくフェーズ分けする。それらのうち , を参照するかなどを決定する。 システムの仕様に大きく影響を与えるフェ UON と同様に , Cadre 技法においても , 構造化設計における二つの概念 , 「結合」と ーズて、ある分析 , 設計作業を上流工程と呼 CASE べンダーて、ある Cadre Technologies lnc. にとって , オプジェクト指向のプロジェ 「擬集」は , 広く用いられる。これらの概念 ぶ。 Cadre 手法て、も , システム開発における は , モジュールに特化したものて、あるため , 分析と設計作業を大きく区別する。分析は クトに CASE を用いるのは当然のアプローチ て、ある。 C 十十にはオプジェクト指向による クラス設計に直接応用することはて、きない システムが対象とする問題を明確にし , 設 が , メソッドの設計に用いることは可能て、 主導的な設計手法がないのて、 , 既存のツー t はそれらに対する解決を表現するのて、あ る。 Cadre 手法はおもに設計作業を対象とす ある。 ルを必要に応じてある程度用いた。したが 「結合」 (coupling) は , 構造化設計におけ るが , もちろんその上流工程て、分析作業は って , この Cadre 手法はまったく新しい表記 るモジュールの相互独立性を示す概念て、 , 法の提案て、はなく , 旧来の記法の誤用に見 行われている。 ーっのモジュールが共有する情報の量によ 効果的な設計表記法は , すべての重要な えるかもしれない って測られる。また , 「擬集」 (cohesion) は , 設計コンセプトを表現し得るだけて、なく , Cadre 手法は , CASE ツールの支援とし モジュール相互て、はなく , ーっのモジュー て , ERD(entity-relationship diagrams/ 実 設計中の「決定的な局面」に対する , 設計者 ル内の要素の結合の強さを示す概念て、ある。 の注目に焦点を当てて表現することもて、き 体ー関連ダイアグラム ) をクラス設計に用い 構造化設計の目標 , 指導原理として , この メソッド設計のために ASG(Ada structure なくてはならない。構造化設計においては , モジュール間の結合が「決定的な局面」て、あ graphs/Ada 構造化グラフ ) を用いるわけて、 擬集度を高め , 結合度をて、きるだけ少なく することによって , モジュール性を高める あるが , 正確な定義に基づいて使用するわ るため , 表記法としてはデータ結合を用い て明確に表現することがて、きる。オプジェ けて、はない。この記法て、表現されるいくつ ことがあげられる。 「結合」概念は , 特定のクラスがもつ , ほ かの概念は , オプジェクト指向設計に重要 クト指向設計においては , クラス階層が「決 かのクラスの情報を減らすために用いるこ なものて、あると考える。しかし , その詳細 定的な局面」に当たるため , まずそれをたや とがて、きる。あるクラスの仕様を変更した についてはまだ改善の余地が多くある。 すく見ることがて、きるように表現て、きなく 場合 , ほかのクラスの変更を意味しない なお , 米国て、は日本て、想像する以上に Ada また , その設計表記法は , てはならない また , 「擬集」概念は , すべてのメンバ変 言語が広く用いられており , 本稿て、述べる 設計者という人間によって用いられる , い わば言語て、あるため , たやすく読み書きて、 数とメソッドがクラスの一部て、あることを ように , Object-Based のプログラミング言 表現するのに有効て、ある。つまり , 「結合」 語として , その成果がオプジェクト指向開 きなくてはならないて、あろう。「決定的な局 面」をより明確にするために , オプジェクト と「擬集」は , 設計作業においてクラス分類 発技法に取り入れられている。その ASG も , 本来 Ada のモジュールて、あるパッケージを 指向設計は , クラス設計とメソッド設計に (classification), カプセル化 (encapsula tion), そして性質継承 (inheritance) の , オプ 効果的に表記するための仕様化手法の一つ 区別される。 このうち , クラス設計はオプジェクト指 ジェクト指向設計の基本概念を , どのよう として , R. J. Buhr が TA System Design 向においてはじめて必要とされる作業て、あ に応用するかを決定するために有効な概念 with Ada 』 (Prentice Hall, 1984 年 ) て、述へ 68 C M AGAZI NE 1991 6

・短期集中連載 OOP 思考の周辺 Fig. 1 アニマルゲームのオプジェクト指向分析 十 animal—status 十 article @animal—name Animal: M characterizes Game: . @game—id 十 game—status Characteristic. @cha 「 acteristic—id 十 question 十 answer 十 characteristic—status ているものて、ある。ただし Ada は , モジュー ルを表現することがて、きるが , クラス階層 と継承を言語仕様としてはサポートしてい ないため , 本来 ASD にはオプジェクト指向 のそうしたメカニズムを表現する機能は備 えられていない Cadre 手法は , システム分析作業の結果て、 ある , オプジェクト指向分析モデルを利用 して作業を開始する。この分析モデルは , すべてのクラスを表す実体ー関連図 ( ERD ) , 各クラスを表現する状態遷移ダイアグラム (state-transition diagram/STD), 各クラス のさまざまな状態を表現するデータフロー ダイアグラム ( DFD ) から構成される。これ は , 本連載第 1 回て、述べた IfObject-Oriented Systems AnalysisJ ( 「オプジェクト指向シス テム分析』啓学出版 ) て、提起されている , シ ステム分析技法の結果を前提とするものて ある。また , その分析モデルは , すべての クラスとメンバ変数を表現するデータ辞書 をもっている。 これらのクラスは , 問題を解決するため にモデル化されるのてはなく , 問題自身の 中から発見される。問題の解決は , 設計フ ェーズの進行にしたがって明確にされてい くのて、ある。 ERD は , クラスと , クラス名 の実体を提供するメンバ変数 , そして階層 による継承とクラス相互の関係を表してい る。また , STD は , クラスのライフサイク ルや振舞いを表し , DFD はクラスに必要と される基本的なメソッドを表している。 この , オプジェクト指向分析においては , カプセル化ということに注意して作業が進 められる。システムの設計にはどのオプジ ェクトが含まれるか , そしてその属性はど のようなものなのかをみつけることが必要 て、ある。こうした情報は , ERD に記述され る。たとえば , イエスとノーの質問に答え ることによって , 動物の種類を推論する , 有名な古典的コンビュータゲームを考えて みる。 ( システム ) 好きな動物を思い浮かべてく ださい ( システム ) それは長い首をもっていま すか ? >yes ( システム ) それはキリンですか ? > no ( システム ) 答えは何ですか ? ( システム ) yes ですか , no ですか ? > 羽をもっていますか ? いですか ? ( システム ) どのような質問をすればよ > ダチョウ >yes プレイヤーは特定の動物を選び , システ ムはそれを想像しようとする。システムは , 推論するまえにプレイヤーに動物の特徴に 関する簡単な質問を行う。多くの誤った推 論の後に , システムはプレイヤーに新しい 特徴を尋ねることにより , 新しい知識を追 加する。このゲームの分析から簡単な ERD が作られる (Fig. 1 ) 。 この問題は , 動物とその特徴を含んて、い る。動物は , 名前と項目をもっている。特 徴には , 「その動物は泳ぎますか ? 」のような 質問がある。各動物は , 多くの特徴をもっ ていて , それは多くの動物に適用される。 Mellor らによるオプジェクト指向分析 は , ERD によってクラス分類と継承を表現 し , そしてすて、に分析作業の結果として ERD が作られているのて、 , Cadre 手法ては設計作 業にも , その ERD を利用する。設計 ERD を 設計クラスプラウザと考えるのてある。 設計 ERD はクラスの設計をグラフィカル に強調する。各クラスは , クラス名をもっ た矩形と , その名前が何を意味するかを示 すメンバ変数によって表現される。クラス の名前とメンバ変数は , 設計作業において クラスの擬集性を決定するのに有効てある。 クラスの設計は , クラス間の結合によって 00P 思考の周辺 69

マレチタスキングの 実際 マルチタスキングは , 実行途中の関数か ら , 別の関数の実行途中へと飛び込み , し かも両者のステートは破壊されないという トリックて、す。具体的には , 関数コールと リターンを , 通常とは違う方法て、行うのて、 す。通常の関数コールて、は , 関数をコール すると , スタックがセットアップされます。 それからその関数の本体が最後まて、実行さ れ , 関数の返り値がコール側に返されると ともに , スタックの後始末も行われます。 しかしマルチタスキングて、は , アクチベ ーションピコードのセットアップは通常の 関数の場合と同じて、すが , もっと早い段階 ( 関数の通常のリターンよりも前 ) て、外に出 て , アクチベーションレコードをセープし ます。そして , アクチベーションレコード をリストアして , もとの場所へと戻るのて、 す ( 訳注 : アクチベーションレコード ( activa tion record ) ・・・・・・変数の現在値なども含め , ある時点て、のその関数の実行ステートのこ 本稿は , 先制制御的て、はない (non-pre- empt ⅳ e ) 並行処理を行う , きわめて単純な task クラスを作ることによって , マルチタ スキングの解説をします ( これだけて、も十分 に複雑なのて、 , タスク制御など高度な機能 については今回は触れません ) 。先制制御的 (pre-emptive) なタスキングシステムて、は , タスクがそのとき何をしているかに関わり なく , 一律にスケジューラによって中断さ れます。タスク制御を伴うシステムて、は , どのタスクをどういう順序て、実行するかと いう点が制御されます。タスクは , 他のタ スクのステートをチェックして自分が走る べきかを判断し , また , 他のタスクを起動 させたりします。 こういう機能は , 実用レベルのマルチタ スキングにとってはきわめて重要て、すが , それによってシステムは , 高度に複雑難解 なものになります。そこて、本稿のプロジェ クトて、は , コンテキストスイッチという , マルチタスキングの最も基本的な考え方だ けを利用することにします。コンテキスト スイッチはタスク側が制御し , スケジュー ラがタスクから強制的に制御を取り上げる のて、はなく , タスクが自発的に制御をスケ シューラに渡します ( 訳注 : コンテキストス イッチ (context switch ) ・・・・・・実行文脈の切り 換え / タスクの切り換えによって起こる事 本稿て、取り上げるマルチタスキングシス テムは , 限られた機能しかもっていません が , 実用性がまったくないわけて、はありま せん。オプションの種類はけっして多くあ りませんが , これだけて、も , コードをスッ キリと編成するために , 非常に便利に利用 て、きます。プログラマがありとあらゆる指 示を記述しなければならないような命令的 な状況 ( たとえば C と PascaI は命令的な言語 て、す ) を再編して , セットアップだけを行え ば , 後はタスクが自分て、自分の面倒をみる という状態を作ります ( いわゆるオプジェク ト指向風になるのて、す ) 。 マルチタスキングを , オプジェクト指向 の手法を拡張するための方法として見るこ とがて、きます。オプジェクト指向プログラ ミングて、は , オプジェクトが受け取るメッ セージを指定し , そしてそれらのメッセー ジに対応する動作を指定します。マルチタ スキングのオプジェクト指向プログラミン グて、は , 自分の行動をわきまえているいく つものオプジェクト群を作り , それらを勝 手に動作させ , オプジェクトたちが自分た ち自身て、相互に制御しあえるようにします。 これはシミュレーションのための完璧なシ ナリオて、あり , そして , シミュレーション にたとえることのてきる問題が , 現実には 多いのて、す。 態 ) 。 単純なシミュレーションて、は , 完全に独 立的なエンティティの集団を扱います。そ ういうエンティティは , 自分の現在のステ ートと , 他のエンティティのステートに従 って振舞います。その好例が , シミュレー ションの古典ともいうべき Life て、す 0Life の 各工ンティティは , 自分のまわりのエンテ イティの数によって行動を決め , 毎回のサ イクルて、自分のステートをテストします。 そこて、 , 各工ンティティに自分のプロセス をもたせることがて、きるのて、 , Life シミュレ ーションの実行は , そういうプロセスを走 らせていくことを意味します。各工ンティ ティ ( それはオプジェクト ) が , 自らのすべ きことを知っているのて、す ( 訳注 : 工ンティ ティ ( entity ) ・・・・・・一般的には存在者とか存在 物と訳され , コンヒ。ュータ関連の文中て、は 工ンティティという片カナ語が使われるこ とが多い。要するに , 他と区別されうる一 個のくっきり / かっきりとした「まとまり物」 のこと ) 。 スケジューリング マルチタスキングはスケジューラが制御 します。実行途中の関数から飛び出て , 他 の関数に飛び込むことを , コンテキストス イッチと呼びます。コンテキストスイッチ を実行するためには , 現在のアクチベーシ ョンレコードをどこかにセープし , それか ら , 命令ポインタ ( 68000 系の用語て、はプロ グラムカウンタ ) やスタックポインタ , フラ グなど ( 全マシンステート ) もセープして , 今の居場所を記憶します。このマシンステ ートのセープに , C のライプラリ関数 setjmp ( ) を利用します。 それから次は longjmp ( ) を使って ( 今セー プしたのとは別の ( 別にセープされている ) マシンステートをリストアして ) , 場所のま C 十十で書く単純なマルチタスクカーネル 15 っただ中へと飛び込むのて、すが , その場所

LANGUAGE 提携記事 、 C 十十で書く単純な Takingz on 0 0 sk 袵Ⅳ c 槲 W : US 解 4 ・ T Gæ ll/l 灯 & 紐に IANG ・ ( 0M2 R マルチタスクカーネル れいにに (COMP TER LANGUAGE Feb. 1991 ) Bruce EckeI/ 岩谷宏訳 オプジェクトを勝手に走って , 彼ら自らか相互に制御しあえるようにできる。 オプジェクト指向プロク 7 ニイをによるマルチタスクでは , 訓練のいき届いた一群の マルチタスクの マルチタスキングについて深く考えると , それがオプジェクトの集まりを作るのと同 じくらい , プログラミングの最も基本的な 概念て、あることが分かってきます。オプジ ェクト指向のモデルて、は , オプジェクトの 集まりはコンテナクラスて、実装します。コ ンテナクラスによって , 数量や型が様々に 異なる複数のオプジェクトをシステム内て、 容易に管理て、きるようになります。マルチ タスキングも , 個数やタイプの異なる複数 のプロセスの管理を容易にします。いずれ の概念も , プログラミングのあらゆる間題 を解決してくれるわけて、はありませんが , 必要なときにはどうしても必要という性質 のものて、す ( 訳注 : コンテナクラス (container class) とは , 配列 , リストなど , 複数データ の「容器」となるクラス ) 。 コンピュータブログラムは , 同時に複数 の状況を監視したり制御しなければならな い場合がよくあります。そういう場面のコ ードは , 一般的に , 「こっちを on にしろ , そ してあっちの用意が OK なら , 別のを更新し 14 C MAGAZINE 1991 6 ろ」という ( あっちを見たりこっちを見たり の ) 形式になっています。こういうスタイル て、は , ちょっと複雑なプログラムになると , どうしようもないほど煩雑なコードになり ます。もっとスッキリさせるには , 問題を 個々のプロセスに分解して , それらを発進 させ , いっ何をやるかといった制御を個々 のプロセス自身にやらせるのて、す。現実に は , 大きなプログラムの構想からたくさん の小さなプログラムを導き出し , そしてそ の個々の小さなプログラムに , 自分がプロ セッサを専有しているというふりをさせる のて、す。これが , マルチタスキングて、す。 マルチタスキングは古くからある , よく 知られた概念て、すが , それをどの段階て、実 装するかに関しては , まだ意見が一致して いません。プログラミング言語の段階て、実 装している例 ( 言語本体がマルチタスク機能 を実装している例 ) として , Modula ー 2(TCOMPUTER LANGUAGE 』誌 ' 91 年 2 月号のマイケル・ビシニャーニ氏の記事 ( 本 誌 22 頁 ) 参照 ) , Ada, Concurrent-C などが あります。 これらの言語を使うと , タスキングシス テムを自作する必要がなく , 新たなプラッ トホーム ( 他機種 ) への移植も簡単なのて、 , きわめて便利て、す。 B. ストラウストラップと C 十十の開発チ ームは , C 十十にマルチタスキングを含めま せんて、した。また , ANSI C 十十委員会も , 言語本体にそれを含めないと決定しました。 これらの決定は , 言語をむやみに大きくし ないためて、あり , また , 状況によってはい ろいろなスタイルのマルチタスキングが必 要になるからて、す ( 訳注 : 言語本体が一形式 のマルチタスキング機能を実装すると , そ ういった多様性に対応しづらくなる ) 。 もっとも重要なのは , C 十十て、は , 様々な マルチタスキングライプラリを自由に自作 て、きるという点て、す。すて、に , 多くの作例 があります。たとえば AT&T のタスクライ プラリ ( 入手困難 ) , WiIliam Miller の C 十十 ライプラリ (Software DeveIopment Tech- nologies lnc. , P. O. Box 366 , Sudbury, Mass. 01776 ) , Tony Hansen の C 十十 Answer Book(Addison-Wesley, 1989 , 本 誓には本稿よりもずっと可搬性に富む複雑 なシステムが記述されており , ディスクて、 入手て、きる ) などて、す。 ある機能を言語を拡張しないて、実現て、き れば , 拡張は不要て、す ( これが C 十十の考え 方なのて、す ) 。

lnformation from Compiler Makers Fig. 2 class SampIeCIass{ private: int data; public: int get-data (void) {return data ; } void set-data(int value) {data = value : } void func ( const SampIeCIass& param) int param. get-data() a class SampIeCIass{ private: int data; public: int get-data(void)const {return data : } int set_data(int value) {data value ; } 内容 TabIe 1 クラスの一覧 クラス名 AbstractArray Array Assoc iation Bag BaseDate BaseTime Collection Container DoubleList Deque DictionaIy String Sta c k SortedArray Sortable Set Queue Object ListElement List HashTable E 作 0 「 DoubleListElement 基本クラス Collection AbstractArray Object HashTable Sortable Sortable Container Object ColIection Containe 「 Set なし Object CO llectio n Collection なし なし Container Bag Object AbstractArray Container Sortable ファイル名 strng. h stack. h SO a 「Ⅳ . h sortable. h set. h queue. h Object. h lstelem . h list. h hashtbl. h Object. h dlstelem. h dict. h deque. h dbllist. h contain. h collect. h ltime. h ldate. h bag. h assoc. h array. h abstarry. h ランダムアクセス可能な集合 要素の順序が定義されていない集合 Diction 引 y で取り扱うキーをもったオプジェクト HashTable と同じ ( 名前が違うだけ ) 年月日 時分秒 Containe 「に追加や削除の機能を追加したクラス オプジェクトの集合 双方向リンクをもつ線形リスト 両側から処理できる拡張キュー Association 型のオプジェクトの集合 双方向リンクをもつ線形リストの要素 new 演算子のエラー処理用 要素の順序をもたない集合 要素の順序をもつ集合 単方向リンクをもつ線形リストの要素 各クラスの基本機能を定義している抽象クラス キュー旧 FO ) 重複した要素をもたない場合 大小が比較できるクラスのもとになるクラス 要素の大小でソートされた集合 スタック旧 LO ) 長さつき文字列 lnformation from CompiIer Makers 151

て、は 2 進木を含まなかったが , これは設計 における選択てある。分析 ERD を用いて , 設計 ERD の検討を始めるのて、あるが , クラ スとオプジェクト相互の関係をその 2 進木 のために付け加えたのが Fig. 2 て、ある。この ・短期集中連載 設計て、は , 設計クラス game node が導き出 され , characterizes ( 特徴づける ) という関 係は , parent 。 f ( 親の関係 ) , yes branch(yes の場合 ) , no branch()o の場合 ) の関係として実装される。このうち parent Fig. 3 アニマルケームのオプジェクト指向手法設計 characteristic OOP 思考の周辺 of の関係は , ほかの二つと区別するため に , これらの関係の混同が起こらないよう に , 設計の初期段階て、指摘される。 設計から分析へと作業を進行する過程て、 , クラスのキーも変化する。 こて、述べるキ new— node child— 0 旧ー node child— reset—child— node yes—node characteristic this no—node characteristic new— question— text question— text strcpy get—yes—node characteristic new—yes—node node child— new— —yes— get— no—node set set— ask 6 node no—node new this —no—node this this characteristic question— answer new—child— node 6 get—answer this printf characteristic this 00P 思考の周辺 71 ask node set—parent— game—node