の技術年表て、ある。本書は , 1986 年に出版 されているため , 以降に続くオプジェクト 指向技法には触れられていない 本書に記されたなかて、 1972 年の E. W. Dijk stra の「構造化プログラミング (structured programming) 」は , その後の設計技法にも っとも大きな影響を与えたといっても過言 て、はない。構造化技法もその影響のもとに あるのだが , プログラムにおいて構造化と いう概念をもち出したのは , 1966 年の C. Bohem と G. Jacopini による , 「すべてのプロ グラムは , 順次 , 分岐 , 繰り返しの 3 つの構 造によって , 制御構造を記述することが可 能て、ある」という構造化定理て、ある。この構 造化定理は , プログラムの制御構造をモジ ュール単位て、考察したものて、あるのだが , 構造化の対象をソフトウェア全体に拡張さ せたことにより , 構造化設計へと発展して いったのて、ある。 「構造化設計 (structured design) 」という 語は , Constantine と Yourdon の著書 『 structured design 』のタイトルとして用 いられたのが最初て、あるとされているが , Myers による「複合設計 (composite design) 」と同じものを指しているといわれて いる。構造化設計技法とは , システム全体 を複数のモジュールに分解し , それを階層 構造に組み立てるシステム構築技法て、あり , その中心は構造化定理に基づくモジュール 分割にある。モジュールの定義を , 「 CASE ツール」から引用すると , ①複数のプログラム文が , ある意味をも っ群としてまとまっている ②プログラム群は , 境界識別子 ( たとえば BEGIN と END) て、区切られる ③プログラム群は , 名前によってほかの プログラムからまとめて参照て、きる というものて、ある。これらを特定の表記法 に従ってドキュメント化したものを , 次の プログラミングエに引き渡すのが構造化 設計の目的てある。 Constantine と Y 。 urd 。 n の著書て、は , 構造化チャート (struc ture chart) と呼ばれるドキュメントによっ Fig. 2 テータフローダイアグラム 受注 顧客 OOP 思考の周辺 ・短期集中連載 顧客レコード 顧客ファイル 入力処理 異常入力通知 工ラー情報 異常処理 受注レコード 開発がなされているのて、ある。設計の上流 許さないウォーターフォール型と呼ばれる て、の作業の誤りはないものとして後戻りを 直線的な開発のプロセスを取り , 上流工程 いうことて、ある。つまり構造化手法て、は , 設計はその上流工程の結果を受けたものと さてここて、重要となるのは , この構造化 造化チャートの例を示す。 グラムの構造を示すものて、ある。 Fig. 1 に構 す黒丸 ( ・ ) っき矢印などの , 基本的なプロ タを表す白丸 ( 〇 ) つき小型矢印 , 制御を表 ュール間の従属関係を表す大型矢印 , デー るものはモジュールを表す長方形と , モジ 以上のシンポルが用いられるが , 基本とな る。この構造化チャートの記法は , 20 種類 て , モジュールの関係を表現するとしてい 工ラーファイル 処理 受注情報 処理台帳 00P 思考の周辺 67 げておく。 マルコ手法と呼ばれる構造化分析技法をあ に関係の深いものとして ,T. Demarco のデ が , ここて、は Constantine と Yourdon の技法 (Essential Systems Analysis) などがある Menamin のデータフローによる構造化分析 and design technique) や , S. W. Mc D. T. Ross の SADT(structured Analysis のて、ある。この構造化分析手法に関しては , 係をデータや制御の流れとして記述するも 数の機能の集合と考えて , それらの間の関 構造化分析とは , 一般にはシステムを複 述手法に従って , 何種類かに区別てきる。 が , この分析技法については要求仕様の記 理に従って作業を進める必要があるわけだ 工程の分析過程においても , この構造化原

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 の具体的な 表記法についてふれる予定て、ある。

これは , データ流れ図 ( Data Flow Dia gram) とデータ定義辞書 (Data Diction ary), デシジョンテープ丿レ (Decision Table), ミニスペック (minispeck) などを用 いて , システムのなかの情報の流れを明ら かにする仕様化技術て、ある。 データ流れ図は , システム化する対象業 務をデータの流れとして , 図形表現したも のて、ある。ある処理に対する入出力情報を , データ識別名をもった矢印て、表し , 処理の 内容をバブルと呼ばれる円によって表現す る。この流れ図を用いて , システム全体の 構造を概観しながら , おのおのの処理を詳 細分析していくのて、ある。 Fig. 2 にデータフ ローダイアグラムの例を示す。同様に , デ ータは詳細化され , データ辞書に整理され ていく。データ定義辞書は , DFD て、記述さ れるデータの構造を , 簡潔に記述したもの て、ある。たとえば , く台帳 > く明細表 > という記述は , 台帳は明細表の集合によっ て定義されるということを示している。 れらの作業に基づき , データ構造 , ファイ ル構造 , 処理プロセスロジックなどを定義 し , 要求仕様書として , 次工程て、ある設計 TabIe 1 ソフトウェアに関する設計技法の技術年表 に引き渡すのて、ある。この開発の各工程が , フェーズごとに確定して , 次工程に作業の 結果を引き渡していくさまを , 滝にたとえ てウォーターフォールモデルと呼ぶのて、あ 構造化技法へのアプローチ これらの構造化分析 , 設計技法を計算機 によって自動化するアプローチが , CASE ツ ールて、ある。とくにワークステーション環 境て、稼働し , グラフィック機能や対話的な ユーザインタフェイスを備えた統合された CASE システムのことを , CAS E ワークベン チと呼ぶことがある。ただし計算機によっ て自動化せずとも , このような設計分析技 法を用いることて、問題は整理され , 作業の 目的を達成することがて、きるものもある。 そのため CASE という場合 , Computer Aided Software Enginieering とはいうもの の , 必ずしも計算機の使用を意味しない 図式表現とそのための問題整理技法や , テ キスチャルな記述言語を総称して CASE と呼 ぶこともある。 「結局 , 人手であろうと , 計算機支援であ ろうと , 使い勝手は重要である。計算機支 年度 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1 9 田 1982 1983 1984 1985 技術内容 モジュール化法 ( Parnas ) , 段階的詳細化法 ( W ⅳ th ) , ワーニエ法 ( Warnier ) , トップダウンプログラミング ( M Ⅲ s ) 構造化プログラミング ( Dijkst 「 a ) 複合設計 ( Mye 「 s ) 構造化設計 (Constantine), 抽象テータを用いたプログラミング法 ( Liskov ) ジャクソン法 ( Jackson ) システムの階層分割 ( Ross ) テータ抽象向けプログラミング設計法 ( 久野 ) テータフロー設計法 ( Jackson ) PAM ( ニ村 ) 機能的設計法 ( 花田 ) , SP-FLOW ( 臼井 ) 統一的設計方法論 ( 紫合 ) トップダウン設計法 ( Yourdon ) , 形式的仕様記述 ( Guttag ) 援のソフトウェア開発 ( CASE ) ツールは , ま すます広まってきた。しかし教室での講義 や , そのほかの場所での議論のために , 紙 とンを用いたじゃまにならないような表 現方法は必要である (fModeIing Object- Oriented Systems 』 ) 」 さてこの構造化分析から設計 , そして構 造化プログラミングにまて、いたる構造化手 法は , 非常に大きな成果をあげてきた。 れに対して , fModeIing Object-Oriented Systems 』の著者はこう述べている。 「構造化設計の重要な要素である構造化チ ャートは , ソフトウェア製品が単純だった ころの , 単純なモデルである」 つまり , ソフトウェアシステムに対する 要求の質や量に対して , 構造化技法は , 表 現力が希薄になってきているのて、ある。前 記「 CASE ツール」によれば , 実際に EDP 分野 て、は , 開発したシステムについて , 以下の ような統計値がとられている。 ①ーっのアプリケーションを例にとれば , ーっのデータには平均 20 個もの , 異な る名前がつけられている ②ーっのシステムを例にとれば , データ ストレージの平均 70 % が重複データに 消費されている としても知られている 0Meilir Page-Jones の著者て、もあり , 構造化設計のパイオニア stantine は , 先ほどの『 Stractured Design 』 tems 』の著者のひとりて、ある Larry L ℃ on みに , 「 Modeling Object ー Oriented Sys て解消て、きる可能性をもつのて、ある。ちな は , オプジェクト指向のメカニズムによっ ところがここにあげたいくつかの問題点 という結果を招いているといえる。 消費されている ④ EDP 予算の 80 % がメンテナンス作業に ス作業の増大を引き起こし , ラムがかかえる多くのムタ・が , メンテナン このように複雑になってしまったプログ ている例がある れたソースコードの最大 90 % が重複し ③ーっのアプリケーション内て、 , 開発さ 68 C MAGAZINE 1991 4

も , 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

なお「 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 構造化チャート 修了標識 テータを得る システム 結果 処理をする 出力をする

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 プログラマに贈る最斤 ウインドウが独立しているため , それぞれ のウインドウについて適当なサイズや位置 を自由に設定て、きます。あるウインドウに よって別のウインドウの一部が隠れてしま う場合はそのウインドウのどこかをマウス て、クリックすることて、 , また , ウインドウ の全部が隠されている場合て、も九つまて、の ウインドウて、あれば ( たいていはこれて、十 分 ) , 十テンキーを押すことて、 , ただ ちに目的のウインドウを選択することがて、 きます。もちろん , ウインドウのリストを 表示させてメニューから選択することも可 能て、す。 ヘルプも忘れてはならない機能て、す。 Ver. 1 . 0 から実現されている状況感知型のオンラ インヘルプに加え , Ver. 2.0 て、はクイック リファレンス行による簡易ヘルプ機能が追 加されました。これは , メニューを表示し ているときにカーソルのある項目について の簡単なヘルプメッセージを表示する機能 て、す。これにより , いちいちキーを押 す必要が少なくなりました。 Turbo Debugger の優れた操作性につい て , 限られた誌面て、すべてを語ることはと てもて、きませんが , このほかにもダイアロ グボックス , キーポードマクロ , 入力ショ ートカットなどさまざまな機能により , 他 のデバッガに類を見ないほど快適な操作性 が実現されています。 Turbo Debugger には , デバッグを支援す るための機能が数多く用意され , IBM-PC 版の Borland C 十十て、は Turbo Debugger for Windows がサポートされたためて、す。 ほかの DOS 用のデバッガて、サポートされて いる機能のほとんどがサポートされている といっても過言て、はありません。 まず , 多彩なプレークポイントの機能に ついて述べましよう。 Turb0 DebuggerC' は , プレークポイントの条件として「アドレ 機能 ス ( 行番号 ) て、の指定」に , 「式の評価」「メモ リの変更」という条件を組み合わせることが て、きます。評価て、きる式は , C, Pascal, ア センプラのいずれて、も可能て、す 0Expression Language< 言語を指定することて、 , たとえ ば C プログラムのデバッグ中にアセンプラの 式を評価させることもて、きます。 プレークポイント (Fig. 11 ) における動作 も , たんにプログラムを停止させるばかり て、はありません。指定した式を実行したり , ログ機能て変数の内容をファイルに記録す ることもて、きます。このため , 「ある行番号 にプレークポイントを指定し , 指定したメ モリが変更されたら , ある式を実行する」と いうことが可能になります ( いうまてもな く , これらは一つのダイアログボックス内 て、指定て、きる ) 。 「式の評価」「メモリの変更」は , アドレス を指定せずに「グローバル」な条件として利 用することも可能て、す。変史されてはいけ ないメモリが破壊されていることがわかれ ば , グローバルプレークポイントとしてそ のメモリアドレスを指定するだけて、すみま す。ただし , プログラムを 1 行実行するごと に式を評価したりメモリが変更されている かどうか判断しなければならないため , プ ログラムの実行速度が著しく低下してしま フことがあります。通常は , アドレスの指 定と組み合わせたほうがよいて、しよう。 Turbo Debugger には , メモリの変更を調 べるための実行速度低下を回避するために ードウェアプレークをサポートする機能 が組み込まれています。残念ながらハ ウェアプレークを実現するための PC ー 9801 用 ポードは市販されていませんが , 80386 を使 ってこれを実現するための機能が標準て、用 意されています。 80386 にはデバッグレジスタが用意されて いるため , ほとんど実行速度を低下させず にグローバルプレークポイントが指定て、き ます。実際には , デバッグレジスタは最大 4 バイト ( メモリ境界による制限っき ) x 4 個 まて、しか指定て、きないため , 複数の変数を 監視するためには力不足ともいえますが , 後述の TD386 て、はもっと広範囲のメモリを 対象にて、きます。 Turbo Debugger て、は , データをデノヾッグ・ 監視するための機能も充実しています。た とえば , 構造体型の変数をウォッチすると , 構造体の各要素の値が Watch ウインドウに 1 行て、表示されます。この状態て、は構造体や 変数のアドレスのみが表示され対応するメ ンバ名などは表示されず , それぞれの要素 がカンマ、、 , 〃や中括弧当ドて、区切られるだ けて、すが , さらにデータを詳しく調べたい 場合のためにインスペクト機能が用意され ています。 インスペクト機能は , Turbo Debugger が データデバッグを実現するための最大の特 徴て、す。インスペクトするためには , ロー カルメニューの lnspect を選択するか , 十国を押すだけて、す ( メインメニューにも項 目が用意されている ) 。インスペクトを行う と新たなウインドウがオープンされ , 対象 となる変数が単純な型て、あれば変数名 , ア ドレスとその内容が表示され , 構造体て、あ れば構造体のメンバ名と対応する内容 , 配 列て、あれば要素番号と対応する内容が表示 されます。構造体や配列が組み合わされて いるような複雑な型て、も , 適当な項目にカ ーソルを移動させてリターンキーを押すだ けて、必要な情報が得られます。 また , Watch ウインドウはカーソル位置 のスコープに依存しますが ( デフォルト ) , インスペクトては調べようとする対象はカ ーソル位置のスコープには依存しません。 したがって , データがスコープから外れる 場合て、もデータの追跡がて、きます。 リスト構造になっているデータてあれば リストボインタを追跡することて、 , 次々と データをたどれます。ポインタが配列の先 頭を指している場合て、も , 範囲を指定する ことて、その内容を表示てきます。 Turbo Debugger は , アセンプラレベルて、 特集初級 c プログラマに贈る最新デバッグ学入門 49

Readers' 0 ① モ インテル数値演算コプロセッサ 提供 : インテルジャパン株 谷 0298-47 ー 851 1 タ 集 ア ン ケ ト 用 紙 応 募 く だ い 2 名 3 名 C DATA SCOPE 提供 : アイセル株 谷 03 ー 3988 ー 6973 ! フコグラム興第ツールン」、 01 ◎ インラルを朝ニッロの・サ プログラム開発ツール PC ー 9800 シリーズ 5 " 2HD 1 名 3861DEBUG 提供 : テックソフト & サービス株 1 名 COMPAL/C 提供 : 富士ソフトウェア株 谷 03 ー 3455 ー 7876 1 個 COMPAL/B 提供 : 富士ソフトウェア株 谷 03 ー 3455 ー 7876 構造化チャートシエネレータ COMPAL 38 引 DEBUG 構造化チャートジェネレータ DOS-Extender 版テパッガ PC ー 9800 5"2HD C 言語 PC ー 9800 5"2HD 鉛筆 4 本 1 組 10 名 応募の注意 提供 : アジソン・ウ工スレイ・バブリッシャーズ・ ◇綴じ込みのアンケート用紙に必要事項 ( アン ジャパン株 ケートの回答 , 住所 , 氏名 , 電話番号 , 希望商 品番号 ) を明記のうえ封書でご応募ください。 ◇記入もれや商品番号が複数記入されている場 合 , 綴じ込み用紙以外でのこ応募は無効とさせ ていただきます。 ◇モニタに当選された方には , 後日アンケート などの形式で編集にご協力いただきます。こ了 承ください。 ◇締め切りは 4 月 18 日必着です。 あて先 〒 108 東京都港区高輪 2 ー 19 ー 13 NS 高輪ビルソフトバンク株 「 C マガジン」編集部 モニタ係 構造化チャートジェネレータ COMPAL LflP PHfl 構造化チャートジェネレータ QuickBAS ℃ PC ー 9800 5"2HD ・ヘんてこ MOUSE スケジュールノート 20 名 提供 : 株アルカス 谷 048 ー 653-1348 ・ルみん 朝きなす、 , ス都ををも 第籌アルカス スケジュール管理 PC -9800 5 ″ 2HD 158 C MAGAZINE 1991 4

ライフボ lnformation from C0mpiler Makers 13 : } 13 : } Q プログラム内にファイル名を 指定してファイルをオープンして も , うまくいかないことがありま す。 List ーのプログラムでファイル myfile はできますが , ファイル test はできません。 A 文字列の中て、は , \ 記号は特別 な意味があります。 \ n は改行 , Yt はタブなどて、す。て、すから , 文字 列の中て、 , \ を表すためには , \ \ と 記述する必要があります。したが って , 、、 f:Ytest" は , 、、 f:YYtest" と書 かなければなりません。 "f:Ymyfile" の場合は , \ の後に n や t などの指定 うになります。 List 1 のプログラムは , List 2 のよ ているため , 偶然うまくいきます。 て , 変換しないということになっ 文字がないときのエラー処理とし 外の文字を見つけるまて、読み込み , 字て、 , 、、 0 ~ 9 〃 , が , ANSI 規格て、は , \ x に続く文 く 2 桁を 16 進数として扱いました がされています。従来は , Yx に続 の扱いが ANSI 規格に準じた変史 Ver. 4.0 以降 , 文字列内の \ x A Q fprintf(stdprt, "%xlbA<") : 力できていたのですが・・・ まいます。 Ver. 3.22 ではうまく出 ムでは , 0xba ミく″が出力されてし したいのですが , 以下のプログラ く″を出力して , プリンタを制御 タにエスケープシーケンス A ″ Lattice C Ver. 4 」で , プリン 最後の 2 桁を 16 進数として扱うよう に変更されました。したがって , l•. の場合には , 、、 \ x 〃に続い 1bA 〃 を読み込み , 最後の 2 桁を 16 進数と して扱うのて、 , 0xba となります。 また ANSI 規格て、 , ふたつの並んだ 文字列は , ひとつの文字列に結合 されるということになりましたの て、 , E 記の例は , 以ドのように書 いていただく必要があります。 fp 「 intf(stdprt,"%xlb" "A<"); 文字列の間には , 0 個以 E の空 自 , タブ , 改行文字が誓けます。 Q 警告「 Warning137 Huge ポイ ンタが far ポインタに変換された」が 表示されることがありますが , huge ポインタと far ポインタは , どこが 違うのですか ? A huge ポインタも far ポインタも 32 ビットボインタて、すが , huge;tk インタはポインタ計算の結果 , オ フセットから繰り E がりがあった とき , セグメントに繰り E がった 分が加算されます (Fig. 1 ( 例 a ) ) 。 方 , far ポインタのほうは , ポイン タ計算の結果 , オフセットからの 繰り上がりがあっても , セグメン トに加算しません (Fig. 1 ( 例 b ) ) 。そ のぶん , ポインタ計算が速くなり ます。以上の違いがあるために この警告を出しています。 Q りたいのですが , 64K バイトを越え 546 バイトの構造体を丐 0 個と るところでアクセスできなくなり ます。何かよい方法はありません か ? A ンバにアクセスて、きなくなります トにまたがって定義されると , メ ' する場合 , 構造体がセグメン タを使用します。構造体の配列を アクセスするために , SI ・ DI レジス コンパイラは構造体メンバに 4 : F ILB *fp : 2 : ma i n ( ) #include く stdiO. h> List 1 1 : 5 : 6 : 7 : 8 : 9 : 12 : Lattice C (Fig. 2 ( a ) ) 。またがらないようにす るためには , ひとつの構造体の大 きさが , 65536 をきれいに割り切れ る数字て、ある必要があります。 546 以 l•. て、 , いちばん小さい 65536 を割 切れる数は , 1024 て、す。 478 バイト のダミーメンバを定義する必要が あります (Fig. 2(b))0 また , キーワ ード pad を指定すると , これが自動 的に計算されます (Fig. 2(c))0 List 2 #include く stdio. h> fclose(fp) : fwrite("test i f()p - fopen ("a:yymyfile" fclose(fp) : fwrite( ” test file ” . 9. if()p ニ f 叩 en("a:yytest", FILE *fp; 2 : ma i n ( ) if(fp fopen ("a:ytest" fclose(fp) : if()p = fopen( ” a:ymyfile" fwrite("test file", 9. I. fp); b 十 2 の結果は , a000 : 0001 a 十 2 の結果は , b000 : 0001 a = b = a000 : 幵 ff のとき , char far *b; char huge *a; fclose(fp) : fwrite("test file ” . 9. l, (o) : 4 : 5 : 6 : 7 : 8 : 9 : 10 : ( 例 b) ( 例 a) f Ⅱ e ". 9. (a ) Fig. 2 9976 : 0000 (c) 8976 : FFFO - S ト団でアクセス不可能 アクセス可能 (&struct-ary[120D &struct-ary[O] 構造体配列の 1 要素のべースアドレス struct step { / * 546 バイト * / char dummy[478] ・ -pad struct ste { * 546 バイト * / lnformation f 「 om Compiler Makers 153 / * 478 バイトのダミーが自動的に挿入される * /

List 20 : 18 : 15 : 14 : 12 : 10 : 7 : 6 : 5 : 4 : 3 : 2 : 1 : LiSt 24 : { 30 : } 1 : 1 : 4 : 6 : 7 : 8 : 9 : 13 : 20 : 21 22 : 25 : 26 : 28 : 29 : 23 : main() #include 2 : #include 3 : c lass A int a; 5 : pub ⅱ c : VO i d VO i d 12 : class B:public A{ int 14 : pub ⅱ c : VO i d VO i d く stream. h> く std i 0. h > aset(int i) aprint() { printf(" bprint() bset(int { a printf(" b ニ %dYn ” x. aset ( 3 ) : x. bset ( 5 ) : x. aprint() : x. bprint() class int protected : int public: VO i d class B int protected: int public: VO i d List 12 VO i d 14 : public: int 12 : protected: int class VO i d 5 : pub ⅱ c : int protected: int C lass 10 : 8 : 7 : 4 : 3 : 2 : aset(int a set ( i + 3 ) : P a i + 2 : set(int i) { b : :public A set(int b : aset(int 拡張 C の C + + は行えない ・引数は一つて , 必ずフレンド関数を定 義しているクラス変数て、なければなら 単項演算子の多義化 のンバ関数による ては , 非公開部のメンバはどのような扱い からはこの関数だけを呼び出すことになる。 のはメンバ関数 eset ( ) のみてあるから , 外部 受け継がれる。派生クラスの公開部にある バ関数も , すべて派生クラスの非公開部に イベートなメンバ変数もパプリックなメン 派生クラス 1 の場合は , 基本クラスのプラ の方法て、派生クラス employee を定義してい Fig. 8 を見ていただきたい。ここては二つ 義する。 基本クラスとして派生クラス employee を定 ず , 日付をクラス date とし , クラス date を スによって employee を定義してみたい。ま List 8 を , クラスを用い , さらに派生クラ 用いる。 , こて、は , 「基本クラス」 , 「派生クラス」を 「派生クラス」 , 「導出クラス」などと呼ぶ。 本クラスから作り出される新しいクラスを ラス」 , 「基底クラス」などと呼ぶ。また , 基 クラスにおいて , 元になるクラスを「基本ク えることがてきる ( まず最初の段階として ) 。 を作り出すことは , 構造体と同じように考 クラスて、も一つのクラスから新しいクラス て他の構造体を入れ子にすることがて、きる。 げると , List 8 のように構造体のメンバとし す機能を解説する。まず , 構造体を例にあ ーっのクラスから新しいクラスを作り出 派生クラス ・引数はない ー ) の多義化を行える ・変数の後ろにくる単項演算子 になるか ? メンバ変数 name と age は , 拡張 C としての C 十十 派 77