簡単なテータベースの作成 パソコンからワークステーションへ 短期集中連載 SPARC げプロクラミンク 今月は , 連載第 1 回目で作成したバ—コード 印刷プログラムを利用して POS システム 。。のデータベースをリ N Ⅸで実現しよう 豊国永健 かなり時間を要した。 ログラムは , 個人てデータベースソフトを はじめに 今回は c ー tree 自体を紹介することが目的て、 作ってしまおうという「とんてもない ! ! 」試 はないのて , 利用方法についてはまたの機 みの若干の成果てある。 会に譲る。さて , 雑談が長くなってしまっ 第 1 回ても触れたが , UNIX がパーソナル C-t 「 ee たが , 今回紹介するプログラムは , 窓口会 レベルまて、なかなか普及しない原因のひと 計処理プログラムてある。 つに , ソフトの価格が高いことがあげられ c-tree は , 米国 FAIRCOM 社が販売してい る。これは開発コストと売り上げ見込み数 窓口会計処理プログラム るデータベース構築用ツールてある。この との関連てやむを得ないことかもしれない ソフトの特徴としては , が , このことが UNIX を導入し稼働させるコ ①全ソースが提供されている 第 1 回 ( ' 91 年 7 月号 ) て、バーコードを印刷す ストを大幅にアップさせることになってい ②サポートされる OS は , MS-DOS, OS / 2 , るプログラムを紹介したが , 今回はそのバ る。したがって , パーソナルレベルて使用 Macintosh, NETBIOS, NOVELL, U ーコードを利用して簡単な POS を実現して することなど「とんてもない ! ! 」ということ みようという試みてある。具体的な機器構 NIX, XENIX など広範囲 になってしまう。 成として Fig. 1 のような形を想定している。 ③作成した実行ファイルについては ( インタ もちろん UNIX を登載したワークステーシ プリタ型のデータベースてないこと , 汎 本来同一構内てあれば , ィーサネットを ョンが急速に普及しつつあるのて , この問 敷いた形を考えるべきてあるが , 本シリー 題は徐々に改善されていくと思われる。し 用のデータベースてないことなど条件は ズのレヾソコンからワークステーションへ」 かし , それまて待つのはいかにも残念てあ あるが ) ライセンス料は無料 という趣旨から , てきるだけ低廉な形を想 ④マルチジョブ , マルチューザがサポート 定してみた。 筆者は , 以前から UNIX 上にデータベース されている まず , 窓口に PC ー 9801 およびスター精密機 を構築しようと考えていた。そこて市販の などがあげられる。有名なデータベースの "infomix" は , このツールを使用して作成 器の SP300 を設置する。 SP300 は , レシート データベースを購入しようとメーカーに問 い合わせたところ , MS-DOS 上のデータベ 発行用の専用プリンタてある。 PC ー 9801 に したということてある。 ースとは価格が 2 桁も違っていたのて , やむ は , バーコードリーダーを接続する。バー どこかて c ー tree の利用法が紹介されている なく断念した。しばらくの間 , 何かいい方 のてはないかと , さまざまな本や雑誌を読ん コードリーダーには , RS ー 232C を使用しな てみたが , 筆者の知るかぎりてはいまだ紹 いキーポードの端子を利用するもの ( PC ー B 法はないかと考えていたところ , ある雑誌 に UN Ⅸ上てデータベースを構築する方法と 介されていないようてある。仕方ないのて , AR Ⅲなど ) を使用する。 SPARCLT には R S ー 232C の端子がふたつあるのて , そのひと して , c ー tree が紹介されていた。「これだ」と 付属のマニュアルとサンプルプログラムを つをリバースケープルて PC ー 9801 に接続し , 頼りに作成したが , データベースを定義す 思い , さっそく購入し , 自分なりのデータ もうひとつを SP300 に接続する。 べースを作成した。これからご紹介するプ るパラメータが複雑てわかりづらいため , SPARC LT プログラミング 105

混乱しがちて、ある。大きな組織て、は , 製品 のコーダーとプロトタイプ担当者は区別さ れるべきて、ある。そしてプロトタイプの過 程からは優れた設計ドキュメントが提供さ れなくてはならない 管理者は , ソフトウェア開発プロセスに おける分析と設計のプロトタイプから , 多 くの利益が期待て、きる。期待される利益の うちもっとも重要なものは , 製品開発やプ ロジェクトを継続するか中止するかを決定 する意志決定の支援機能て、ある。 分析 , 設計プロトタイプは , フレームワ ークとアプリケーションの両チームによっ て作られる。 フレームワークのチームにおいて , 分析 プロトタイプの担当者は , 与えられた業務 分野の詳細な分析に責任を持つ。設計プロ Fig. 2 プロトタイプの評価 コーティング 設計 分析 洗練 保守と拡張 統合 テスト トタイプ担当者は , この分析をもとに , この 分野て、多くのアプリケーション開発を支援 するフレームワークを提供するために , 表 面的な設計プロトタイプを構築する。 アプリケーションのチームの分析プロト タイプ担当者は , 提案する製品の実行可能 なものを作るために , ューザと共同して作 業する。設計プロトタイプ担当者は , ユー ザのニーズを満足させるために , その分析 結果とフレームワークを用いる。 プロトタイヒ。ングはプログラマへの要求 を増加させ , ューザの要求を明確にするた めの負担を減少させる , という間題の望ま しい解決方法て、ある。また こ述べる 再利用 オプジェクト群 , 機能 , 明白な属性 , オプジェクトの関係 情報構成モテルと相互作用モテル 詳細なオプジェクトの記述 , メソッドの実装 設計とコーティングの改善 , 再利用可能な部品の評価 完全なシステム 熟成したシステム OOP,I 、考の周辺 再利用は , システムの信頼性などを失うこ となく , ラピッド開発を行うための解決方 法て、ある。 再利用の目的は , 単独のソフトウェアの 機能に限定されない抽象的な部品群を開発 することて、ある。これらの抽象部品は , 高 い品質とともに , 将来のソフトウェア開発 に高度な生産性も与える。 再利用とは , 要求を達成するために , 既 存のものを用いることて、ある。ソフトウェ ア工ンジニアリングの分脈て、は , 分析 , 設 計 , プログラミングなど , さまざまのフェ ーズにおいて , 多くの部品が再利用て、きる。 オプジェクト指向技術による再利用は , 般に , 以下に挙げる五つのカテゴリのうち のどれかに当てはまる。つまり , アルゴリ ズム , クラスとインスタンス , アプリケー ションのフレームワーク , アプリケーショ ン , そしてインタフェイスの仕様の再利用 て、ある。 「アルゴリズムの再利用」 (algorithm reuse) はデータ構造を越えて同じアルゴリズムを 用いることも含んて、いる。アルゴリズムは , クラス階層の上位に実装され , 自動的にサ プクラスて、も用いることが可能になるよう に , オプジェクト指向技術に支援されたデ ータ抽象が用いられる。 オプジェクトレベルて、の再利用にはふた つの形態がある。新しいクラスを得るため に , インヘリタンスを用いてクラスを段階 的に洗練する再利用と , 新しいクラス構造 て、 , クラスのインスタンスを再利用に用い るものて、ある。 インヘリタンスて、は , クラスのプロトコ ルと実装の両者が再利用される。クラスの 構造によっては , クラスにおいてプロトコ ルが定義されたインスタンスが再利用され 「アプリケーションのフレームワーク」 (application framework) は , 要求される機 00P 思考の周辺 能に近いコードを提供するものて、ある。そ 67

れは , 抽象クラスと , そこに実装されてい る操作と , 固有のアプリケーションのため に , そのフレームワークとしての抽象クラ スを特殊化する機能を持ったサプクラスが , 具体的なコードを実装するて、あろうという 仕様から構成される。 フレームワークは , サプクラスの多様性 を支援することによって , アプリケーショ ンを越えて再利用される。 抽象クラスによるフレームワークの前記 のよラな考えは , C 十十よりも Smalltalk の ファミリ言語において一般的て、ある。しか し , C 十十が成熟するためには , フレームワ ークは疑いなく必要て、あり , 部品の再利用 に対してより注意を払うべきて、ある。 「完全なアプリケーション」 ( complete applications) は , 再利用可能な部品て、もあ る。テスキトエデイタや , ネットワークコ ミュニケーションノヾッケーシ , ファイルマ ネージャ , 図形工デイタ , DBMS などは , ほかのアプリケーションシステムの中に埋 め込むことがて、きる。 ただし , オプジェクト指向の実装の性質 こうした具体的なアプリケーション は , さらに洗練されるべきオプジェクト群 から構成されているともいえる。したがっ て , 完全なアプリケーションは , クラス階 層などをより一層洗練することによって , その抽象度を高めフレームワークを形作る ことになる。 「インタフェイスの仕様」 ( interface specification) は , ソフトウェアシステムの 中て、はもっとも抽象的な部品の再利用て、あ り , オプジェクトの機能を具体化するメッ セージの集合から構成される。インスタン スオプジェクトが , このインタフェイス仕 様によって示される役割を果たすため , そ のクラスは機能のための実装を提供してい なくてはならない。これらのインスタンス こうした共通の動きが必要な場合に用 は , いられる。 68 C MAGAZINE 1991 9 こうした再利用戦略は , すべてふたつの 過程によって確定する。再利用可能な部品 の設計開発と , 再利用可能な部品の利用て、 ある。 こうした過程を認知させるためには , チームの相互協力と同様に , 管理上および 技術上の支援が必要て、ある。ときには , 管 理者は指導や評価の手法を修正したり , ソ フトウェア開発者に特別な報酬を与えなけ ればならないて、あろう。 また開発者は , 自分が作ったものて、はな い部品を使わなければならないという個人 的な抵抗との戦いや , 再利用可能な部品の 開発や利用という作業について学ばねばな らない 管理者は , 再利用が望まれるような環境 に変えなければならない。再利用が可能な 部品が存在する場合に , 新しいコードを書 くことは , 受け入れがたいことて、あると考 えなけれはばらない また , ソフトウェア工ンジニアの書いた コードが , その企業のライプラリとして受 け入れられた場合 , また , ライプラリの管 理者がその効果的な使用を定めた場合 , そ のエンジニアは , 営業マンがノルマを達成 したときと同様に , その企業に貢献したと いえる。組織の時間と費用を節約したわけ て、ある。もちろん , こうした貢献は早急に て、はなく , 1 , 2 年後に表面化するものて、あ る。再利用の過程に対しても正当な評価が なされるように , 組織上長期的に対応され なければならない 再利用可能なソフトウェアが受け入れら れるためには , 多くの選択が可能て、なけれ ばならない。再利用のためのパッケージソ フトの購入は , 内部的な初期投資の支出を 避けるという効果がある。しかし , 不利益 としては , ドキュメントやコーディングの 慣例が , 組織のそれとマッチしないことが 適合させられるように , ソースコードの形 これらのパッケージは , 組織のニーズに あげられる。 て、購入されなければならない。それ以上に , 再利用可能な部品が組織内の各プロジェク トて、効果的 , 効率的に共有て、きるように , ソフトウェアの記述形式とドキュメントの 標準が必要になるて、あろう。 ソフトウェアの開発を請け負い , その結 果として再利用可能な部品を得たいと思う ならば , 再利用可能な財産が作られるとい うことに対する所有者意識を契約の中て、明 確にしておかなければならない 開発者の問題は , まずほとんどが社会的 なものて、ある。再利用は努力する価値があ り , 適切な評価とそれを反映するプロジェ クトの構造によってのみ獲得されるという ことを , ソフトウェア工ンジニアに確信さ せねばならない Table 1 は , 開発チームにおける重要な関 係者と , それらを評価するための新たな基 準て、ある。 2 通りのテスト担当者があげられ ていることに注意していただきたい。なぜ ならば多くのプロジェクトて、は , 再利用可 能なフレームワーク ( 抽象クラス ) とコンポ ーネント ( 部品となるクラス ) の 2 種類のオプ ジェクトが作られるために , 2 種類のテスト 形態が存在するからて、ある。 フレームワークのテスト担当者は , フレ ームワークを使えるかどうかがわかるよう な適切なコンポーネントを作り出す。コン ポーネントのテスト担当者は , そのコンポ ーネントが別の分脈て、使えるかどうかを決 定する。したがって , テスト作業は , ソフ トウェアの再利用の範囲を割り当てること こうした作業は , ライプラリ だといえる。 の管理者と共同して行われる。 再利用のテスト作業は , ソフトウェアの テストに対する非常に特殊なアプローチて、 ある。なぜならば , ソフトウェアコンポー ネントが , 広い応用可能性を持って設計さ チームの割り当て

OOP 思考の周辺 領域て、用いられているのと同様の用語によ れているか否かを決定するからて、ある。再 熟練したプログラマて、あると同時に , 再利 って , 情報モデルを表現することを可能に 利用のために設計することは , プロジェク 用が適切に機能する機会を明確にするため することがオプジェクト指向プログラミン に , すべての評価作業に加わることが期待 トの中て、 , またプロジェクトを越えて , オ これは重要なのて、あ プジェクト指向技術の影響力を行使するた グの鍵てあるが故に される。熟練した , コミュニケーションが 可能な人間て、あるべきて、ある。 めの鍵となる手段て、ある。 オプジェクト指向のプロジェクトのコス また , 再利用ライプラリ管理担当者は , 設計プロトタイプ担当者は , 再利用可能 トは , わずかな部分て、 , 非オプジェクト指 市販されているライプラリにアンテナをは なコンポーネントを作り上げる能力によっ 向開発のコストと異なっているだけて、ある。 り , 必要に応じて再利用可能なコンポーネ て評価されるため , これらコンポーネント トレーニングと言語処理系やツールの購入 ントを得るアクテイプなソフトウェア産業 の特別なテストを行うことは重要て、ある。 など , 初期投資が必要になる。しかし , プ テスト担当者は , 設計者とともに , 可能な の観察者て、あるべきて、ある。 ロジェクトの運用費用について考察してみ そしてライプラリ管理者の報酬は , 組織 抽象化や新たなライプラリを探るために共 ると , もしそれが開発のスケジュールに算 におけるこうした役割の価値を反映すべき 同して作業を行う。 入されていなかったとするならば , 単にプ て、ある。 チームにおいて , 新しく重要な位置を占 ロトタイプの開発のみが追加費用となるだ めるのは , ライプラリ担当者て、ある。ライ けて、ある。 プラリ担当者は , 分析プロトタイプは要求の明確化を支援 ①共有されるレポジトリのために , 定期的 する。故にソフトウェアプロジェクトの結 オプジェクト指向技術の導入は , 以下に にソフトウェアの評価を行う 果をプログラムコードの行数て、測ることは , 示す四つの項目に注目することて、 , プロジ ②効果的な再利用可能な部品のために , 分 オプジェクト指向プログラマにとって , 悪 ェクトの成否を評価て、きる。 析プロトタイプ担当者と相談する しき慣例となる。プロジェクト全体におけ ①再利用が可能なソフトウェア部品は効果 ③再利用が適切に予想されるように , 設計 る高水準プログラミング言語と再利用の導 的てあったか ? プロトタイプの評価に関係する 入は , しばしばコードの行数を削減させ , ②ライプラリに新しいソフトウェア部品は ④設計プロトタイプのどの要素が再利用可 行当たりの費用を減少させ , 生産性を向上 付け加えられたか ? 能て、あるかの決定に注意を払う ③問題を解決する設計は , 拡張可能て、ある ⑤研究開発マネージメントに対して , フレ させる。 オプジェクト指向技術を , ソフトウェア ームワークとなるようにアプリケーショ 開発プロジェクトに導入することは , 対話 ンを一般化するための意見を述べる ④プログラムの実装は理解しやすいか ? 的・追加的開発 , 問題空間から解決状態へ 理解しやすいコードは , オプジェクト指 再利用可能ライプラリ管理担当者は , 開 の接近 , プロトタイピング , 再利用などの 向技術によって期待される利益のうちても , 発チームの最も重要な存在て、ある。彼らは , 項目において , 大きな変化をもたらすこと 抽象化や特殊化に対する鋭い能力を持った とくに重要なものて、ある。現実世界の問題 になる。とくに , 再利用が可能になること TabIe 1 開発チーム内部関係者の評価基準 て , モジュラリティと高品質 , 生産性 , 再 役割 利用可能な財産の増加 , ライフサイクルコ ストの減少などの効果がもたらされること そして , 長期レベルてみると , ユーザの 仕様の変更要求に対する迅速な応答が可能 となり , 組織内ソフトウェア部品のライプ ラリが再利用可能な財産として完全なもの となっていくのてある。 評価 評価尺度 各問題領域の特徴の一般化 フレームワーク構造の一般的な再利用可能性 フレームワークの一般性と特殊性の判断 再利用可能なオプジェクトの特別な応用可能性 再利用可能な財産のライプラリを効果的で矛盾なく管理する , 質と量を付け加える , 有効性の検証 , 設計において部品を使用 することの調整 各分野の分析担当者 フレームワーク設計者 フレームワークテスト担当者 コンポーネントテスト担当者 再利用ライプラリ管理担当者 00P 思考の周辺 69

ーマイクロ、カト lnformation from C0mpiler Makers Microsoft BASIC V 部 . 7.1 たり , サイズ変更することが可能 プロフェッショナルユーザ向け 字列配列 , テンボラリ文字列 利用して大規模なプロクラムを作 てす。 2. プロシージャレベルの文字列 の BASIC として , Microsoft BASIC 成していました。 BASlC7.1ては , オーバーレイ方式を利用して , 最 配列が動的になるか静的になる 3. COMMON< 宣言された文字列 Ver. 7.1 ( 以下 BASIC7.1) の発 大 16M バイトのプログラムを作成 , かは , 配列の宣言方法て変わりま 4. プロシーシャレベルて宣言され 売を 6 月下旬から開始しました。今 す。デフォルトては , 定数の添字 実行てきます。 回は , BASIC7.1 のメモリ関係情報 た文字列配列 オーバーレイを指定するには , を使って次元を決めた配列は静的 far 文字列を利用する場合は , 生 を紹介します。 LINK ユーティリティの実行時にオ 配列となります。 成コードが大きく , かっ , 実行ス コンバイルされた ーバーレイにするモジュールをカ ビードが低下します。 EXE とメモリ M とメモリ ッコ ( ) クて囲みます。カッコの そのため , QuickBASIC4.5 と 中のモシュールがひとつのオーバ 同様 , near 文字列もサポートして ーレイになります。 データベースは大量なデータを います。 30K バイト程度しか文字列 字列と字列 たとえば ,Fig. 1 の LINK コマン 扱うため , メモリを多く消費しま を扱うことはてきませんが , コン ドライン上から実行すると , A—I パクトかっ , 高速な EXE ファイル す。 の 7 個のオプジェクトファイルから MSOS / 2 のプロテクトモードて Quick BASIC4.5 ては , mROUP を生成てきます。 実行する場合はとくに大きな問題 3 個のオーバーレイを生成します。 QuickBASIC Extended Ver ( 最大 64K バイト ) の中にすべての可 はありませんが , MS-DOS< 実行 (B 十 C), (E 十 F), ( I ) がオーバ sion( 以下 QBX)< は , far 文字列 変長文字列データを格納していた ーレイモジュールてす。残りのモ する場合 , メモリの利用方法が実行 ため , 文字列を大量に扱うプログ のみをサポートしています。 シュールとランタイムコードがメ スピードに大きく影響を与えます。 ラムを作成すると , 文字列領域不 S 川 SK オー / ←レイ モリに常駐されています。 ISAM ては , データ用のメモリと 足が頻繁に発生していました。 各オーバーレイモジュールのサ して 2K バイト単位のべージバッフ BASIC7.1 ては , 大量の文字列を イズは , 最大 128K バイトて 64 個の アを使います。 ISAM を利用する場 BASIC7.1ては , EMS メモリ 扱えるように , far 文字列をサポー モジュールを利用てきます。 128K 合 , 最低ても 6 べージが必要となり トしています。 BASIC7.1 ては , 以 や , DISK を利用したオーバーレイ バイト以上の EMS の空きメモリが プログラムを作成することが可能 ます。 下の四つのグループごとに 64K バイ なければ , 自動的に DISK オーバー トを文字列領域として利用てきま てす。 バッフアが十分にないとディス レイとなります。一般的に , オー クとメモリ上のバッフアの間て頻 従来 , MS-DOS の 640K バイトの す。 バーレイを利用する場合 , 実行速 メモリの限界を意識し CHAIN を 繁にスワップが発生するため , 速 1. モジュールレベルの文字列 , 文 度が低下することに注意が必要て 度が低下します。 ューザメモリを圧迫せずに高速 す。 にデータベースを扱うため , MS- 動的配列と静的配列 DOS 上ては ,EMS メモリの利用が ポイントになります。 配列のためのメモリ確保のタイ ミングを制御することによって , プログラムのメモリをより効率的 に管理てきます。 QBX は , 工デイタやデバッガな 配列のためにメモリを確保する どの統合環境を利用するため , 約 のは , プログラムのコンパイル時 , 340K バイトのメモリを必要としま もしくは , 実行時てす。コンパイ ル時に確保する配列を静的 ( スタテ す。そのため , 大きなプログラム の実行のためのメモリを確保てき イク ) 配列 , 実行時に確保する配列 を動的 ( ダイナミック ) 配列と呼び ない場合があります。大きなプロ グラムを QBX 上て実行てきるよう ます。動的配列は実行中に解放し LINKA 十 (B 十 c) + (E 十 F) 十 G 十 (l) TabIe 1 nea 「文字列を使用 引数 fa 「文字列を使用 FRE(a$) その文字列変数を含むセグ DGROUP メント FRE ( " リテラル文字列 " ) テンボラリ文字列領域 DGROUP FRE(O) DGROUP lllegalfunction call FRE(-I) fa 「メモリ fa 「メモリ FREG2) スタック領域 スタック領域 拡張 ( EMS ) メモリ 拡張 ( EMS ) メモリ FRE(-3) Q 日 X とメモリ 148 C MAGAZINE 1 1 9

システム規模と開発チームの人件費など により , 大規模システムの開発コストはし ばしば高いものになる。しかし , かって作 られたプログラムの構成要素を新たなシス テム開発に再利用て、きるとすれば , 開発コ ストを引き下げることがて、きるて、あろう。 大規模なシステムは , ひとりの人間が理 解するには複雑すぎるのて、 , ューザの要求 を正確に仕様化するのは非常に困難て、ある。 そうした状況て、は , システムの仕様は不完 全て、不正確なものになってしまう。 こて、 , プロトタイプについて考えてみ る。プロトタイプを用いることは , ユーザ とシステムの分析者に , ユーザの正確な要 求を発見させることを可能にする。 最近のシステム開発においては , ューザ 自身が自分のニーズを正確に把握していな いと考えたほうがよい というのが情報処 理の世界て、の定説て、ある。システムのニ ズが非定型的な処理に向かっているためて、 あり , そのうえこれらのシステムは対話的 な要素が多く , 机上て、は要求仕様の確定が 困難て、あるが故て、ある。またプロトタイプ は , 正確なアーキテクチャを得るために 設計フェーズにおいても有益て、ある。 多くの人手を必要とするような複雑て、コ ストの高い大規模なシステムは , しばしば , 長期間にわたって使われる。その長いライ フサイクルにおいて , 仕様の変更に対応し て , システムは進化しなければならない 効果的なシステム開発技法において , シス テムの進化は必然的て、あり , 変更の追加は 基本的に必要なことて、あるという事実をま ず認めなければならない システム構築に関するこの事実を前提に すると , オプジェクト指向技法は三つの機 能を直接に支援しなければならない。まず 第一に , 再利用可能な部品を作り上げるこ とを支援しなければならない。第二に , プ ロトタイプは容易に作り上げられねばなら ない。そして最後に , システムのライフサ イクルにおいて , 容易にシステムの仕様を 変更することがて、きるように , チームは構 造化されていなければならない ソフトウェア開発組織において , オプジ ェクト指向技術を効果的に使うためには , ふたつの異なったプロジェクトチームによ るアプローチが有効て、ある。それは , アプ リケーションチームとフレームワークチー ムのふたって、ある。このふたつのチームに よるアプローチは , 実際の企業における開 発の本質の観察に基づくものて、ある。 アプリケーションチームは , クライアン トとの契約を満たすような , アプリケーシ ョンの分野に依存した設計 , 開発 , 提供な どに責任を持つ。このチームはとくに , ユ ーザの要求を決定したり , 納期に間に合わ せるために , 開発において再利用がて、きる 部品に焦点を当てる。 フレームワクチームは , 異なったアプ リケーションのためにカスタマイズが可能、 な , 基本的なプログラム構造を提供する。 これらのアプリケーションは , 製造やネッ トワークサービスなど , 単一の応用分野に 味する。フレームワークチームは , ムワークに付け加えられるということを意 必要なプログラム部品が選択され , カスタマイズとは , プログラマによって 適合する。 一般的 フレー 向技術については , 基本的に異なった指導 程を取るにもかかわらず , オプジェクト指 クチームは , 目的を達成するために同じ過 アプリケーションチームとフレームワー て、ある。 るような , 分野に依存した開発環境のこと リケーションシステムの開発に再利用て、き 野て、別なアプリケーションチームが , アプ う。一般的なフレームワークとは , 同じ分 なフレームワークの設計や開発に注意を払 保守そしてシステムの拡張という , 同様の プジェクト指向設計と分析 , 実装 , 原理を持っている。とくに , 両チームはオ テスト , OOP 思考の周辺 プロセスを取るのて、あるが , オプジェクト 指向技術に基づくプロトタイヒ。ングと再利 用が持つ重要な機能は , こうしたプロセス について , 両チームに影響を与える。 Fig. 1 は , プロトタイピング作業の統合 が , オプジェクト指向による開発プロジェ クトの構造の中て、重要な特徴て、あるという ことを示している。プロトタイプは , 意図 的に不完全て、あったり , システムの規模を 落としたものて、 , 完全な規模のシステムを 構築するプロセスに貢献する。それは , 表 面的に設計された粗末な代物て、はなく , 完 全な製品が開発され得ることを証明するた めのものてある。 「ラピッドプロトタイピング」 ( rapid prototyping) は , プロトタイプがすぐに作ら れ , 評価されるという過程を示している。 オプジェクト指向ラピッドプロトタイピン グに重要な鍵は , 再利用が可能な設計 , フ レームワーク , そしてコンポーネントなど , プログラム部品の倉庫 ( リポジトリ ) の充実 てある。 プロトタイピングの結果は , 多くのプロ グラマによってテストされ使用されている ソフトウェア部品から構築されたものより も精度は落ちる。しかし , その不完全性は , ターゲットのユーザからより多くの要求を フィードバックするのに有効て、ある。 プロトタイビングは , しばしばソフトウ ェア開発の初期段階において用いられる。 プロジェクトを開始する場合 , 「分析プロト タイプ」 (analysis prototype) が要求仕様を 明確にするために作られる。このプロトタ イプは , 実行可能な最終的なプロダクトの 部分的なモックアップによって , ューザの 反応や考えを引き出すための相互作用を引 プロトタイピング 00P 思考の周辺 一度 , ューザとの同意が得られたら , 形 き出すものて、ある。 65

BASIC 用に作成された Quick ライプラリは , そのままて、は QBX て利用て、きません。しか し , ほとんどのソースファイルは利用可能 なのて、 , QBX 用にライプラリを再構築する ことがて、きます。 多少の制約はありますが , QuickBASIC と MS-BASIC 7 は , かなり互換性が高いと いえるて、しよう。ほとんどの場合 , Quick- BASIC て、書かれたソースプログラムは , そ のまま MS-BASIC 7 て、利用可能て、すし , そ のままて、は利用て、きない場合て、も , 移植は MS-BASIC の評価 比較的簡単にて、きると思われます。 26 C MAGAZINE 1 1 9 くしています。 よって計算時間を長くし , 測定誤差を小さ のメジャーループを 100 回ループすることに 位て、しか時間を計測て、きないのて、 , whetstone PC ー 9801 シリーズの MS-DOS て、は , 1 秒単 ストは付録ディスクに収録 ) 。 まれるローカル変数を用いていません。リ しました ( したがって , C て、はスタックに積 け同じようなコードを出力するように留意 移植にあたっては , BASIC と C て、て、きるだ います ) 。 て、す。オリジナルは FORTRAN て、書かれて ンチマークとして比較的有名なプログラム 比較しました (whetstone は , 数値計算のべ 移植し , そのコードの大きさと実行速度を ログラム whetstone をそれぞれ BASIC と C に べンチマークの方法は , べンチマークプ べンチマークの方法 いると思われる言語を選んて、みました。 十十 Ver. 1.0 などて、 , 本誌読者が使用して C Ver. 2.0 , Turbo C Ver. 2.0 , Turbo C BASIC Ver. 4.5 , MS-C Ver. 6.0 , Quick MS-BASIC と比較したのは , Quick の質を他の言語と比較してみます。 , こて、は , MS-BASIC が出力するコード 各言語て、コンパイルするときには , 最大 限のオプティマイズをするようにコンパイ ルスイッチを設定しました (TabIe 2 参照 ) 。 ライプラリは , 80X87 用をリンクして用い ました ( ただし , QuickBASIC には , 87 専用 のライプラリがないのて、 , Emulater 用のライ イプラリを使用しました ) 。 プログラムサイズの比較 まず , コンパイラが生成するオプジェク ファイル (. OBJ ファイル ) の大きさと , ライプ ラリをリンクした後の実行ファイル (. EXE フ ァイル ) の大きさを上交します ( TabIe 3 参照 ) 。 . OBJ ファイルサイズを比較すると , MS -BASIC が出力するコードは , C 言語が出力 するコードと同じぐらい小さいことがわか ります (QuickC や Turbo C とほば同じてす ) 。 TabIe 2 TabIe 3 コンバイルスイッチ 言語名 言語名 サイズの比較 Turbo C 十十 Ver. 1 .0 Turbo C Ve 「 . 2.0 QuickC Ver. 2 , 0 MS-C Ver. 6.0 QuickBASlC Ver. 4.5 MS-BASIC Ver. 7.1 MS-BASIC Ver. 7.1 Turbo C 十十 Ver. 1 .0 Turbo C Ver. 2.0 QuickC Ver. 2.0 MS-C Ver. 6.0 QuickBASlC Ver. 4.5 次に , . EXE ファイルのサイズは , ライプ ラリのモジュールが細かくわかれているか どうかに ( ライプラリモジュールのサイズ に ) 依存しているのて、 , 比較は難しいのて、す が , . EXE ファイルを比較すると , C 言語の処 理系よりはサイズが大きいものの , Quick- BASIC と比較すると , ほば半分のサイズと なっています。 次に , 実行速度の比較て、す。べンチマー クは 32 ビットマシン , 16 ビットマシンのそ れぞれについて行いました。 ① PC ー 9801RA2 i80386 ( 16MHz ) 十 i80387 (16MHz) ② PC ー 9801RX2 i80286 ( 12MHz ) 十 i80287 (10MHz) 実行速度の比較 コンノヾイルスイッチ / 0 /FPi /Ot /G2 / 0 /FPi /FPi87 /Oazx /Gr /G2 /FPi87 /Oax /G2 ー f87 ー 0 -Z -G ー 1 - f87 ー 0 -Z -G ー 2 OBJ ファイル ( バイト ) 7 , 516 7 426 5 , 221 7 960 7 808 6 , 820 EXE ファイル ( バイト ) 33 , 196 66 , 605 21 868 22 , 450 18 , 178 7 , 130

G ①影 Fig. 1 有限ステートマシン el se REMARK AWAIT-SLASH el se AWAIT-AST. e lse else STRING-CONSTANT OUTSIDE else CHAR-CONSTANT alpha else PREPROCESSOR digit else IDENTIFIER EOF EXIT NUMBER alphanum FSM は非常に強力て、 , どんなプログラミ タをステート変数として ( カレントステート め , C の、、演算子ステート〃が含まれていま ング課題にも応用て、きます。私のこの記事 を記憶するために ) 利用しているのて、 , それ せん ) 。 ProcessToken() 関数は , トークン を読んて、 , FSM を書くのは実に簡単だ , と はて、きません。そのときは , switch 文を使 とそのタイプをプリントするだけて、す。 おわかりになったと思います。それに私は , うしかありません〔訳注 : なんらかの static p@@e( ) の使用 switch 文やプロシジャテープル〔 C て、は関数 変数にカレントステートを保存するように ポインタの配列〕の信奉者を洗脳して , goto すれば , goto 方法て、もなんとかリターンて、 を使う良質な構造化プログラミングが可能 きるのて、は ? 〕。 parse ( ) がトークンを見つけるたびに下請 という考えに転向させたいて、すね〔訳 け関数をコールするのて、はなく , メインプ FS は用途が広い 注 : コンパイラなどのパーサは , その基本 ログラムがトークンを欲しいときに parse ( ) アルゴリズムとして , 再帰下降法によるも という場合がよくありま をコールしたい をその言語の文法に従って FSM は のと , FSM を使用するものが二大主流のよ す。それは , どうやればよいて、しようか ? ーコロロ パースしていくために , よく使われていま うて、す。私のように再帰がニガ手という頭 簡単て、すよ。 ProcessToken(x) をすべて す。そのテクニックは本稿の範囲を超えま 脳の持ち主は , 後者に基づく文献を勉強し retrun(x) に書き換えて ,FSM 関数にその x すが , しかし , Jack Crenshaw の、 The Nuts た方がよいて、しようね〕。 を帰値として返させるようにするのて、すに & BoIts of CompiIer Construction" (CO れは , ーっのトークンを処理した後には常 MPUTER LANGUAGE, Mar. 1989 ) や , Fis に OUTSIDE ステートへ戻る , ということを her と LeBlanc が書いたコンノヾイラ設計の本 TimCooper 氏は , オーストラリアのシドニ 利用しています ) 。 『 Crafting a CompiIer with C 』 (Benja ー大学の認知科学科の学生。彼の会社の名 文字を一つ読むたびに parse ( ) にリターン min/Cummings, 1991 ) などは , 良い参考文 前は , Esprit de E Software Design といい させたい , という場合もあります。この goto 献て、す。 ます。 を使う方法は , 実質的にプログラムカウン 22 C MAGAZINE 1991 9

式的な要求仕様が分析プロトタイプを元に ドキュメント化される。 Fig. 2 に示すよう に , オプジェクト指向分析の成果は , オプ ジェクト群と , 要求される機能を表現した オプジェクト相互の関係て、ある。 分析プロトタイプのコードは , 捨て去る ものと見なされる。その目的は合意した要 求のドキュメント化に迅速に到達すること にある。完全主義のプログラマは , 分析プ ロトタイプが最適化されたプログラムコー ドて、ないことに耐えられないかもしれない 開発の第二段階においては , システムの アーキテクチャの作成と検証のために , 「設 計プロトタイプ」 (design prototype) が開発 される。このプロトタイプは , 設計の冗長 さや矛盾など , 過不足をチェックし , 完全 な機能が統合されているかを決定し , 応答 性や容量などの検証を形作るのに用いられ る。設計プロトタイプによって明確にされ るシステムのアーキテクチャは , 実際のソ フトウェア製品のコーディングの基礎とな プロトタイプが維持され , 製品に組み込 まれた例と同じくらい , 設計プロトタイプ が捨て去られて , 別のチームのメンバによ って製品が再コーディングされた例がある。 その選択は , プロトタイプのパフォーマン スと容量の分析に依存する。そうした からも , プロトタイプの過程から得られる 優れた設計ドキュメントは , 別の開発チー ムにも与えられなければならない プロトタイピングは , 注意深く評価が行 われるならば , 開発チームのメンバの設計 に対する理解を向上させる。おのおののフ ェーズて、多くの時間を必要としないが故に 設計への評価に対しては , 応答したり受け 入れることがたやすい。製品の初期段階の 評価作業にユーザが含まれていれば , ュー ザはシステムの改善について気づきやすい て、あろう。 プロトタイヒ。ングは , 再利用可能なコン 66 C MAGAZINE 1991 9 ポーネントを用いたラビッド分析と , 有効 な再利用可能な部品の設計のための評価に 時間を費やすことを意味している。この評 価作業によって , 優れた再利用可能なコン ポーネント群を作り上げることが可能にな る。しかし , プロジェクトに費やす時間を 減らすことは誰も望まない。時間の節約よ りも , 品質の向上がプロトタイヒ。ング本来 の目的なのて、ある。したがって , プロトタ イプの担当者の役割は重要て、あり , キーマ ンを担当させるべきて、ある。 ソフトウェア開発プロセスの鍵となる部 分としてのオプジェクト指向プロトタイヒ。 ングは , ふたつの理由から評価作業を必要 とする。 まず , 望んて、いたアプリケーションが動 きだすと , たとえそれがプロトタイプて、あ Fig. 1 プロジェクトの構造 ラピッド プロトタイプ 分析 設計 コーティング テスト 使用 ったとしても人々はエキサイトしがちて、あ る。競合他社をマーケットから追い出そう と , マネージャはプロトタイプを市場に提 供しようとする。 第二に , そのプロトタイプの開発プロセ スは集中的て、あるようには見えない。開発 過程における集中力を獲得するためには , プロトタイプが作られているという明白な 合意と , その合意がどのようにプロトタイ プを評価するかという意見を含んて、いるこ とが必要て、ある。プロトタイプの完全性を 判断し評価するために , ひとりの人間を割 り当てられなければならない もし開発チームが小さい場合は , プロト タイプを作った人間が製品開発も担当する ことになるが , 開発のフェーズが現在どこ にあるのか , 最終製品が提供されたのか , と 変更 洗練

B 0 一員 0 The Leader ⅲ 0biect-Oriented Programming + つ QN Ⅵ 09 間 :WindowsM アプリケーション開発に 最も有効なコンヾイラは、何ですか ? ( 解答はペーシ下をこ覧下さい ) 98 , 000 へむ 従来の開発環境 98 , 000 なし C コンパイラ C 十十コンパイラ ind0WS AP 作成ツール アセンプラ 含む \ 98 , 000 へむ 98 , 000 \ 40 , 000 236 , 000 パソコンとに、視覚的で快適な操作環境を提供す して利用て、きます。さらに、再コンヾイルの速度を大 る Windows 3.0 。そこで利用するアプリケーション 幅に向上させる「コンパイル済みへッタ ] 機能をサ 作成のためのコンパイラは、現在のものでベストと ポート。 MS ー DOS の 640KB というメモリの制限を破 いえるでしようか ? 機能、スヒード価格・・・。これらの 面で理想的ともいえるコンパイラが、登場しました。 るオーバーレイマネージャ VROOM の利用や、 Turbo Drive によってプロテクトモードて、動作する統合開発 「 BORLAND C 十十」です。 BORLA 、 D C 十十 環境て、の大規模なプログラムの作成も可能て、す。 は、 Windows アプリケーションを開発、ラヾックする C ℃ + + コンパイラとツールを標準で装備しています。 programmer's Platform は、好きなツールを組み •Windows アプリケーション開発をサポート 込む機能を持つ強力な統合開発環境て : MS ー DOS BORLAND C ナ十は PW 朝 00W フログラムを完全 や Windows アプリケーション開発に必要なすべての にサポート。高博なつ高性能な処、理を実現していま す。 MDL(Multiple Document fnterface) や ツールがすて、に組み込まれています。さらにオーバーラッ DLLs(By0afiueLink L 市 rtes ) たような プウインドウやマウス、そして Windows のフログラミン Windows の機能を使って、・規なプロテクトモー グリファレンスを含んだオンラインヘルプをサポート。 ドアプ ! を ~ 内蔵のマルチファイルエデイタは、アンドウ ( 実行の ヾョンの開発力可能になります。さらに、 取消 ) / リドゥ ( 再実行 ) やマクロ機能を装えています。 Microsoft の一ソースコンぐイラと WINDOWS. H 、 Resource&Work Sh 叩 ( 日本語版 ) が標準装備 ■動作環境 : PC -9801 シリーズ ( ハイレゾモード対 されていますのて : 別の開発キット ( SDK ) は不要てす 応、 LT は除く ) / メモリ :640KB 以上 /MS-DOS:Ver •ANSI C/AT&T C 十十両用コンパイラ 3.0 以上 /MS-Windows 3.0 以上 / マウス : バス BORLAND C 十十は、 C と C 十十両方のコンヾイラと マウス / 要ハードディスク Turbo C 2. O/Turbo C 十十 1.0 登録ューザの方には 8 月初旬に アップデートのご案内をお送りします。 98 , 000 円 ( 税別 ) 価格 8 月末発売 BORLAND C++ ・ Programmer's PIatform 20 1 麟 1 BORLAND 0 + 日 0 袞ー A N 0 ( 答 ) ※齟 Borland products are trademarks 0 「 registered trademarks Of Borlandlnternatlonal,lnc. OBorland 株式会社ボーランドジャパン ※ Microsoft 、 Windows は米国マイクロソフト社の登録商標です。その他、商品名は一般に各社の商標です。 〒 107 東京都港区南青山 7-8-1 小田急南青山ビル TEL 03-3 6-1400 代 ・製品に関するお問い合せは、総販売元株マイクロソフトウェアアソシェイツ TEL. 03 , 3486-1411 までお願いします く資料請求番号 F04 > 雑誌 14325 ー 9 ◎ソフトパンク凸版印刷 printed in Japan T 4 9 1 1 4 3 2 5 0 9 9 8 5