システム規模と開発チームの人件費など により , 大規模システムの開発コストはし ばしば高いものになる。しかし , かって作 られたプログラムの構成要素を新たなシス テム開発に再利用て、きるとすれば , 開発コ ストを引き下げることがて、きるて、あろう。 大規模なシステムは , ひとりの人間が理 解するには複雑すぎるのて、 , ューザの要求 を正確に仕様化するのは非常に困難て、ある。 そうした状況て、は , システムの仕様は不完 全て、不正確なものになってしまう。 こて、 , プロトタイプについて考えてみ る。プロトタイプを用いることは , ユーザ とシステムの分析者に , ユーザの正確な要 求を発見させることを可能にする。 最近のシステム開発においては , ューザ 自身が自分のニーズを正確に把握していな いと考えたほうがよい というのが情報処 理の世界て、の定説て、ある。システムのニ ズが非定型的な処理に向かっているためて、 あり , そのうえこれらのシステムは対話的 な要素が多く , 机上て、は要求仕様の確定が 困難て、あるが故て、ある。またプロトタイプ は , 正確なアーキテクチャを得るために 設計フェーズにおいても有益て、ある。 多くの人手を必要とするような複雑て、コ ストの高い大規模なシステムは , しばしば , 長期間にわたって使われる。その長いライ フサイクルにおいて , 仕様の変更に対応し て , システムは進化しなければならない 効果的なシステム開発技法において , シス テムの進化は必然的て、あり , 変更の追加は 基本的に必要なことて、あるという事実をま ず認めなければならない システム構築に関するこの事実を前提に すると , オプジェクト指向技法は三つの機 能を直接に支援しなければならない。まず 第一に , 再利用可能な部品を作り上げるこ とを支援しなければならない。第二に , プ ロトタイプは容易に作り上げられねばなら ない。そして最後に , システムのライフサ イクルにおいて , 容易にシステムの仕様を 変更することがて、きるように , チームは構 造化されていなければならない ソフトウェア開発組織において , オプジ ェクト指向技術を効果的に使うためには , ふたつの異なったプロジェクトチームによ るアプローチが有効て、ある。それは , アプ リケーションチームとフレームワークチー ムのふたって、ある。このふたつのチームに よるアプローチは , 実際の企業における開 発の本質の観察に基づくものて、ある。 アプリケーションチームは , クライアン トとの契約を満たすような , アプリケーシ ョンの分野に依存した設計 , 開発 , 提供な どに責任を持つ。このチームはとくに , ユ ーザの要求を決定したり , 納期に間に合わ せるために , 開発において再利用がて、きる 部品に焦点を当てる。 フレームワクチームは , 異なったアプ リケーションのためにカスタマイズが可能、 な , 基本的なプログラム構造を提供する。 これらのアプリケーションは , 製造やネッ トワークサービスなど , 単一の応用分野に 味する。フレームワークチームは , ムワークに付け加えられるということを意 必要なプログラム部品が選択され , カスタマイズとは , プログラマによって 適合する。 一般的 フレー 向技術については , 基本的に異なった指導 程を取るにもかかわらず , オプジェクト指 クチームは , 目的を達成するために同じ過 アプリケーションチームとフレームワー て、ある。 るような , 分野に依存した開発環境のこと リケーションシステムの開発に再利用て、き 野て、別なアプリケーションチームが , アプ う。一般的なフレームワークとは , 同じ分 なフレームワークの設計や開発に注意を払 保守そしてシステムの拡張という , 同様の プジェクト指向設計と分析 , 実装 , 原理を持っている。とくに , 両チームはオ テスト , OOP 思考の周辺 プロセスを取るのて、あるが , オプジェクト 指向技術に基づくプロトタイヒ。ングと再利 用が持つ重要な機能は , こうしたプロセス について , 両チームに影響を与える。 Fig. 1 は , プロトタイピング作業の統合 が , オプジェクト指向による開発プロジェ クトの構造の中て、重要な特徴て、あるという ことを示している。プロトタイプは , 意図 的に不完全て、あったり , システムの規模を 落としたものて、 , 完全な規模のシステムを 構築するプロセスに貢献する。それは , 表 面的に設計された粗末な代物て、はなく , 完 全な製品が開発され得ることを証明するた めのものてある。 「ラピッドプロトタイピング」 ( rapid prototyping) は , プロトタイプがすぐに作ら れ , 評価されるという過程を示している。 オプジェクト指向ラピッドプロトタイピン グに重要な鍵は , 再利用が可能な設計 , フ レームワーク , そしてコンポーネントなど , プログラム部品の倉庫 ( リポジトリ ) の充実 てある。 プロトタイピングの結果は , 多くのプロ グラマによってテストされ使用されている ソフトウェア部品から構築されたものより も精度は落ちる。しかし , その不完全性は , ターゲットのユーザからより多くの要求を フィードバックするのに有効て、ある。 プロトタイビングは , しばしばソフトウ ェア開発の初期段階において用いられる。 プロジェクトを開始する場合 , 「分析プロト タイプ」 (analysis prototype) が要求仕様を 明確にするために作られる。このプロトタ イプは , 実行可能な最終的なプロダクトの 部分的なモックアップによって , ューザの 反応や考えを引き出すための相互作用を引 プロトタイピング 00P 思考の周辺 一度 , ューザとの同意が得られたら , 形 き出すものて、ある。 65
どが特殊変数て、 , perl のさまざまな動作を制 始まるのて、 , 予約語と間違える心配はあり さて , このプログラムを仮に howdy. pl と いうファイルて、セープしたとします (perl プ 御するのに使われます。以下は変数の例て、す。 ません。予約語を気にせず好きな名前がつ ログラムに習慣的な拡張子は . (l) 。 perl に けられます。 C や awk に慣れたプログラマは howdy. pl を実行させるには , 次のようにし $var perl に慣れるまて、、、 $ 〃を忘れがちなのて、注 ますい 1 % 〃はプロンプトを示しています ) 。 意する必要があります。 @some array 1 % perl howdy. が %assoc2 perl の変数には三つの型があります (Table Howdy, world! 10 参照 ) 。スカラ型というのが基本の型て , @ARGV perl はほかの多くの言語と異なり , ファイ 文字列または数値を表しています。 perl て、は ル名に自動的に拡張子をつけることはしな 文字列と数値の区別は非常に瞹眛て、 , 必要 いのて , 上記のようにきちんと拡張子、、 . pl ク List 14 に出てくる、、 $ total 〃は通常の変 に応じて perl が変換してくれます ( 変換され 数て、す。、、 $ 〃は特殊変数て、 , このプログラ をつける必要があります。 てしまうともいえます ) 。なお , perl 内部て さて , このような「 1 行プログラム」を実行 ムて、は入力された行が文字列として入って は数値は常に浮動小数点数 (double)< す ( こ いちいちファイルを作るのは います。この特殊変数、、 $ ー〃は perl プログラ のあたりの事情は awk と似ています ) 。スカ するときに めんどくさいて、すね。このような場合 , プ ムの隠れた主役ともいえる変数て , perl のさ ラ値を単に真偽値として扱う必要がある場 ログラムをコマンド行引数て perl に渡してし 合には , perl て、は空文字列 , 0 ( 数値 0 または まざまな演算子の多くはオペランドが指示 まう方法があります。 されないと、、 $ 〃に対して処理を行うよう 文字列 0 ) , および空リスト ( 後述 ) は偽とし 2 % perl -e 'print "Howdy, world!*n" ・ ' になっています。英語て、 ch 叩 it" とか、、 print て扱われ , それ以外は真て、す。真値の代表 Howdy, world! it ′′といったときの、、 it 〃に当たるのが、、 $ 〃 としては普通 1 を使います。配列 , 連想配列 オプション、、一 e 〃は次の引数がプログラ て、す。 については後て、説明します。 ムてあることを perl に伝えています。 変数への代入は , 以下のように C の代入演 perl の変数は常に $ , @, % などの記号て、 List 1 3 よりも少し複雑な例 while( く STDIN>) { # while input is available, # add t0 $total. $total + = $ ー print "TOtal is : $total%n"; # print it at end. 1 4 List = = 変数 1 ムりっリ 4 もう少し複雑な例 ( List 14 ) を見てみまし よう ( 、、 # クから行末まて、はコメントてす ) 。 何をするプログラムかおわかりて、しようか。 <STDIN> や $ という謎の記号があります が , なんとなくわかるて、しよう。標準入力 から入力された数値の合計を出力するプロ グラムて、す。このプログラムては $ total とい う変数を使っています。 変数を使いたい場合 , perl て、は特別な宣言 は不要てす。代入や参照を最初に行った時 Fig. 4 Pe の定数 点て、自動的に変数が作られます。 perl の変数 名は必ず型を表す 1 文字の記号 ( 、、 $ ク , ① 3 % perl -e 'print "The p 「 ice is \ $ 40 ( \@2 x 20 ) *n" The price is $ 40 ()2 x 20 ). 第@〃 , または % ク ) て始まります。その 後に英文字て、始まる英数字列の名前 ( 、、 ② 'ls ヨ /config. sys 、 , " # " 4 % perl -e 'p 「 int " # ” 679 May 3 1991 05 : 27 /config. sys は名前の中て、は英文字として扱われます ) , または , 英文字以外の 1 文字の名前をつけた ものが変数てす。記号 1 文字の変数はほとん TabIe 10 pe 日の変数 変数 $var @var O/ova 「 意味 文字列 , 数値 添字か整数の配列 添字が文字列の配列 型 スカラ 配列 連想配列 52 C MAGAZINE 1991 9
式的な要求仕様が分析プロトタイプを元に ドキュメント化される。 Fig. 2 に示すよう に , オプジェクト指向分析の成果は , オプ ジェクト群と , 要求される機能を表現した オプジェクト相互の関係て、ある。 分析プロトタイプのコードは , 捨て去る ものと見なされる。その目的は合意した要 求のドキュメント化に迅速に到達すること にある。完全主義のプログラマは , 分析プ ロトタイプが最適化されたプログラムコー ドて、ないことに耐えられないかもしれない 開発の第二段階においては , システムの アーキテクチャの作成と検証のために , 「設 計プロトタイプ」 (design prototype) が開発 される。このプロトタイプは , 設計の冗長 さや矛盾など , 過不足をチェックし , 完全 な機能が統合されているかを決定し , 応答 性や容量などの検証を形作るのに用いられ る。設計プロトタイプによって明確にされ るシステムのアーキテクチャは , 実際のソ フトウェア製品のコーディングの基礎とな プロトタイプが維持され , 製品に組み込 まれた例と同じくらい , 設計プロトタイプ が捨て去られて , 別のチームのメンバによ って製品が再コーディングされた例がある。 その選択は , プロトタイプのパフォーマン スと容量の分析に依存する。そうした からも , プロトタイプの過程から得られる 優れた設計ドキュメントは , 別の開発チー ムにも与えられなければならない プロトタイピングは , 注意深く評価が行 われるならば , 開発チームのメンバの設計 に対する理解を向上させる。おのおののフ ェーズて、多くの時間を必要としないが故に 設計への評価に対しては , 応答したり受け 入れることがたやすい。製品の初期段階の 評価作業にユーザが含まれていれば , ュー ザはシステムの改善について気づきやすい て、あろう。 プロトタイヒ。ングは , 再利用可能なコン 66 C MAGAZINE 1991 9 ポーネントを用いたラビッド分析と , 有効 な再利用可能な部品の設計のための評価に 時間を費やすことを意味している。この評 価作業によって , 優れた再利用可能なコン ポーネント群を作り上げることが可能にな る。しかし , プロジェクトに費やす時間を 減らすことは誰も望まない。時間の節約よ りも , 品質の向上がプロトタイヒ。ング本来 の目的なのて、ある。したがって , プロトタ イプの担当者の役割は重要て、あり , キーマ ンを担当させるべきて、ある。 ソフトウェア開発プロセスの鍵となる部 分としてのオプジェクト指向プロトタイヒ。 ングは , ふたつの理由から評価作業を必要 とする。 まず , 望んて、いたアプリケーションが動 きだすと , たとえそれがプロトタイプて、あ Fig. 1 プロジェクトの構造 ラピッド プロトタイプ 分析 設計 コーティング テスト 使用 ったとしても人々はエキサイトしがちて、あ る。競合他社をマーケットから追い出そう と , マネージャはプロトタイプを市場に提 供しようとする。 第二に , そのプロトタイプの開発プロセ スは集中的て、あるようには見えない。開発 過程における集中力を獲得するためには , プロトタイプが作られているという明白な 合意と , その合意がどのようにプロトタイ プを評価するかという意見を含んて、いるこ とが必要て、ある。プロトタイプの完全性を 判断し評価するために , ひとりの人間を割 り当てられなければならない もし開発チームが小さい場合は , プロト タイプを作った人間が製品開発も担当する ことになるが , 開発のフェーズが現在どこ にあるのか , 最終製品が提供されたのか , と 変更 洗練
学 五ロ いるはずて、す。実際 , alloc node を見ると , 新たなヘッダとノードエリアを malloc した ときにはすべてのノードを FreeIist て、始まる リストに加えています。 ということは , 新たに確保されたノード は Freelist が指しているリストの中に加えら れますが , 使用されていたノードが解放さ れたときには FreeIist て、はなくへッダのメン バ list が指すリストに加えられるのて、す。っ まり自由に使用て、きるノードが 2 種類のリス トに分割されて格納されることになります。 しかも , alloc nodef' 取り出してくるのは F reelist のリスト内のノードなのて、 , 一度解放 したノードは二度と使用されないという問 題があるのて、す。 解放されたノードも FreeIist に加えられて 再使用されるべきて、すから , HEAD 型構造 体のメンバ list は不必要て、す。 free node< 解 放されたノードを list に加えている処理は , いるところて、すが , 定義の実体として式を Freelist に加えるように書き換えましよう。 す。 さて , 鹿内さんはヘッダのリストを双方 使っています。しかし , この式にはカッコ そのほかに気づいた点 リストとして実現していますが , 単方向リ がついていません。 BLOCKSIZE が式の中 て、使われたとき , 正しくない結果となるこ ストても実現てきるということはおわかり こては以上に述べたほかに私が気づい てすよね。それに Newhead もなくても大丈 とがあります。 Fig. 2 を見てください 夫て、す。 Fig. 2 (a) て、は BLOCKSIZE が展開される た点について書きましよう。といってもそ と , * と十の優先順位の問題て、 HEADSIZE のうちのいくつかはスタイルの間題て、 , ほ ヘッダを解放するときにちょっとしたテ クニックを使えばよいのてす。「先頭にダミ とんど個人の趣味の世界に入っていきます が期待どおり 2 倍されなくなってしまいま ーのヘッダをくつつける」。これがヒントて のて、 , 「こいつはこう考えているのかあ」程 す。したがって , #define の実体として式 ( 0 , 1 といった定数も正確には式てすが , す ( ヒントというより答だなあ ) 。とし 、うこ 度に読んてください こて、は演算子を使っている式という意味て、 とて , 私のヘッダは List 2 のようになりま まず記号定数 BLOCKSIZE を #define して す ) を使うときには必ずカッコてくくるよう さらにせこいへッダ にすべきてす。そうすれば Fig. 2 ( b ) のよう にうまくいきます。 1 : typedef s truc t —header— { 2 : struct header *next; 次に気になるのはやたらとキャストして 3 : usedcount; i nt nodesC0] : 4 : NODE いることてす。 ANSIC は型チェックに関し 5 : } HEAD; てかなり厳しくなっていますから , そのチ ェックをかわそうということなのてしよう 私は基本的に , 関数が返す型やパラメー タの型ははっきりと決定されているべき ( つ まり関数プロトタイプは絶対に必要 ) だし , キャストが必要ということは不自然な操作 をしようとしているのだろうと考えていま C 言語雑学講座 113 Fig. 2 # define (a) うまくいかない例 #define BLOCKSIZE HEADSIZE + sizeof(NODE) * ALLOC_UNITS i ま BLOCKSIZE * 2 ; ↓展開されると・ i HEADSIZE + sizeof(NODE) * ALLOC UNITS * 2 ; HEADS に E は 2 倍されない ! ( b) うまくいった例 #define BLOCKSIZE (HEADSIZE + sizeof(NODE) * ALLOC—UNITS) i = BLOCKSIZE * 2 : ↓展開されると・・・ i = (HEADSIZE + sizeof(NODE) * ALLOC_UNITS) * 2 ; 正しく全体が 2 倍されている List 2 / * 第 8 回 ( 1990 年 11 月号 ) 参照り
OOP 思考の周辺 領域て、用いられているのと同様の用語によ れているか否かを決定するからて、ある。再 熟練したプログラマて、あると同時に , 再利 って , 情報モデルを表現することを可能に 利用のために設計することは , プロジェク 用が適切に機能する機会を明確にするため することがオプジェクト指向プログラミン に , すべての評価作業に加わることが期待 トの中て、 , またプロジェクトを越えて , オ これは重要なのて、あ プジェクト指向技術の影響力を行使するた グの鍵てあるが故に される。熟練した , コミュニケーションが 可能な人間て、あるべきて、ある。 めの鍵となる手段て、ある。 オプジェクト指向のプロジェクトのコス また , 再利用ライプラリ管理担当者は , 設計プロトタイプ担当者は , 再利用可能 トは , わずかな部分て、 , 非オプジェクト指 市販されているライプラリにアンテナをは なコンポーネントを作り上げる能力によっ 向開発のコストと異なっているだけて、ある。 り , 必要に応じて再利用可能なコンポーネ て評価されるため , これらコンポーネント トレーニングと言語処理系やツールの購入 ントを得るアクテイプなソフトウェア産業 の特別なテストを行うことは重要て、ある。 など , 初期投資が必要になる。しかし , プ テスト担当者は , 設計者とともに , 可能な の観察者て、あるべきて、ある。 ロジェクトの運用費用について考察してみ そしてライプラリ管理者の報酬は , 組織 抽象化や新たなライプラリを探るために共 ると , もしそれが開発のスケジュールに算 におけるこうした役割の価値を反映すべき 同して作業を行う。 入されていなかったとするならば , 単にプ て、ある。 チームにおいて , 新しく重要な位置を占 ロトタイプの開発のみが追加費用となるだ めるのは , ライプラリ担当者て、ある。ライ けて、ある。 プラリ担当者は , 分析プロトタイプは要求の明確化を支援 ①共有されるレポジトリのために , 定期的 する。故にソフトウェアプロジェクトの結 オプジェクト指向技術の導入は , 以下に にソフトウェアの評価を行う 果をプログラムコードの行数て、測ることは , 示す四つの項目に注目することて、 , プロジ ②効果的な再利用可能な部品のために , 分 オプジェクト指向プログラマにとって , 悪 ェクトの成否を評価て、きる。 析プロトタイプ担当者と相談する しき慣例となる。プロジェクト全体におけ ①再利用が可能なソフトウェア部品は効果 ③再利用が適切に予想されるように , 設計 る高水準プログラミング言語と再利用の導 的てあったか ? プロトタイプの評価に関係する 入は , しばしばコードの行数を削減させ , ②ライプラリに新しいソフトウェア部品は ④設計プロトタイプのどの要素が再利用可 行当たりの費用を減少させ , 生産性を向上 付け加えられたか ? 能て、あるかの決定に注意を払う ③問題を解決する設計は , 拡張可能て、ある ⑤研究開発マネージメントに対して , フレ させる。 オプジェクト指向技術を , ソフトウェア ームワークとなるようにアプリケーショ 開発プロジェクトに導入することは , 対話 ンを一般化するための意見を述べる ④プログラムの実装は理解しやすいか ? 的・追加的開発 , 問題空間から解決状態へ 理解しやすいコードは , オプジェクト指 再利用可能ライプラリ管理担当者は , 開 の接近 , プロトタイピング , 再利用などの 向技術によって期待される利益のうちても , 発チームの最も重要な存在て、ある。彼らは , 項目において , 大きな変化をもたらすこと 抽象化や特殊化に対する鋭い能力を持った とくに重要なものて、ある。現実世界の問題 になる。とくに , 再利用が可能になること TabIe 1 開発チーム内部関係者の評価基準 て , モジュラリティと高品質 , 生産性 , 再 役割 利用可能な財産の増加 , ライフサイクルコ ストの減少などの効果がもたらされること そして , 長期レベルてみると , ユーザの 仕様の変更要求に対する迅速な応答が可能 となり , 組織内ソフトウェア部品のライプ ラリが再利用可能な財産として完全なもの となっていくのてある。 評価 評価尺度 各問題領域の特徴の一般化 フレームワーク構造の一般的な再利用可能性 フレームワークの一般性と特殊性の判断 再利用可能なオプジェクトの特別な応用可能性 再利用可能な財産のライプラリを効果的で矛盾なく管理する , 質と量を付け加える , 有効性の検証 , 設計において部品を使用 することの調整 各分野の分析担当者 フレームワーク設計者 フレームワークテスト担当者 コンポーネントテスト担当者 再利用ライプラリ管理担当者 00P 思考の周辺 69
このアプローチがうまくいくのを知って いる。私がすて、に何度か自分自身をこのよ うなエキスパートの地位から退位させたの 信は悪なり だから。 14 C MAGAZINE 1991 9 ト指向プログラミングをありがたく思うは 右級に慣れてから初めて , オプジェク ればならないことを強調したい。一般的な いくつかの中間ステップを経て進化しなけ へんな技て、ある。そうて、はあるが , 彼らも プラて、コーディングするのはなかなかたい いるのて、はない。システム 3 / 70 用にアセン ないといったが , これは彼らをばかにして BAL プログラマは C 十十の勉強をすべきて、 明確な定義作りを開始した ) 。 re Engineering lnstitute は進化段階のより か有害だ ( 7 月号て、述べたとおり theSoftwa 以上離れたものはすべて役立たないどころ かがわかる。現在の会社の段階から 1 レベル どの技術を使えば自分の会社が有利になる たいせつだ。この知識によって武装すれば , るのか , はっきりと理解することはもっと あなたの会社が進化のどの段階に当てはま 進化の段階を理解することがたいせつだ。 ンスを計画に組み入れている。 計フェーズの一部としてテストとメンテナ る。もっとも先進的な会社だけが解析と設 も呼ばれる ) を使いこなしている会社もあ 設計メソッド ( メソドロジ (methodology) と ところもある。ひとつあるいはそれ以上の 的な知識に対する理解さえもおばっかない 会社によってはおのおのの仕事に伴う基本 の段階を経て進化する , ということがある。 のひとつに , ソフトウェア組織はいくつか ソフトウェア工学における具体的な発見 かる。 の自動販売機を買ってあげたほうがもう えるのは時間のムダだ。彼らにはコーラ 異論その 5 : BAL プログラマに C 十十を教 ずだ。その過程て、制御フローとデータ構造 をマスターする。 段階をスキップすると部下の間に冷笑と 混乱が生ずる。 ージメントされるマネージャ 異論その 6 : ソフトウェアプロジェクトを 予算内におさめるのは利益を出すより重 要だ。 これはもっとも純粋な異論といえるだろ う。もし会社が利益を出せなければ , 結局 長くは続かない。あなたのもっとも高いゴ ールは当然会社を存続させることのはずだ。 いやこれは会社のもっとも高いゴールて、あ り , あなたのゴールて、はないかもしれない マネージメントは 3 階層にわかれる。最高 層のマネージメントは株主に対して責任を 負っている。彼らは求めるゴールが何かを よく考えて選択し , 投資に対する十分な見 返りを出さなければならない。彼らは利益 優先主義だ。 中間層のマネージメントは最高層のマネ ージメントに対して責任を負う。ゴールと 予算を与えられる。割り当てられたゴール を予算内て、達成て、きたときだけが彼らの勝 利となる。変化に反対するのが中間層マネ ージメントの仕事だ。変化は予算にとって 脅威となる。中間層マネージメントは予定 外のチャンスを得ようとして予算を変更す るような傾向や決定権がない 第一線のマネージャとしてのあなたの責 任は仕事の遂行にある。予算優先主義の中 間層マネージャに対して責任を負っている。 予算内におさめれば上司の仕事が楽になる。 また中間層マネージメントの資質があるよ うにも思われる。あなたが仕事をこなすこ とは , 企画全体を手助けしているのだと信 じなければならない 上司て、あるマネージャを信頼て、きなけれ ばほかに仕事を求めなさい。さもなければ 自分て、会社を設立しなさい サイティングな幸福のバランス 異論その 7 : ソフトウェアを書くことは楽 しくなければならないが , 楽しすぎても いけない。 過去には , プログラマが会社て、働くのは コンヒ。ュータが高価すぎたからだったとい う時代もあった。現在て、は平均的なプログ ラマならだれて、も十分な開発環境を家庭て、 も持てる。多くのプログラマは独立のスリ ルよりも給料を求めるのて , 彼らを雇って おけるのてある。 またそれより数は少ないがプログラマに よってはチームの一員として大型プロジェ クトて、働きたいと思っている人もいる。し かしもしプログラマにとって仕事が楽しく なければ , 彼らを雇用し続けるのはかって よりずっと困難になった。 予算内におさめることてあなたの上司を ハッヒ。ーにしなければならないのと同様に 部下もハッピーにしなければならない。プ ログラマには何か楽しめることを与えてハ ッビーにするのだ。楽しみとプロジェクト のニーズのバランスをとるのだ。プログラ マには刺激が必要だが , 常に失敗するほど のものて、はいけない。自由が必要だ。しか しプロジェクトが無政府状態になってはい どちらの極端に走ってもあなたの けない 負けだ。 私にとっては最後の異論がもっとも重要 なのだ。プログラマと企業家の共通の利益 こにある。ソフトウェア開発をエキサ イティングなものにするためには , 決まっ てある程度の楽しみが必要だ。そうてなけ ればやる価値がない。エキサイトてきないよ うなソフトウェア開発はプログラマにとって 楽しみがなく企業家にとって金儲けにならな い。この見方は重要なパートナーにとってデ リケートな基盤だが , なぜかうまくいく。
■ VOI.I 一面白くて役に立つ 特集・プログラマの仕事場 プログラマの開発環境を齷レポート : プロクラミンクのための ■ Vol.2 特集・ Windows の時代である - 一 ミスーバーマガジン 9 月号 Windows プログラミングを徹底解説 8 月 19 日発売 ミ月刊プロクラマーズ・ペー シ : 品切れ / VoI.3 定価 980 円 特集・この言語を使いなさい 主要 1 4 詳吾の特性から使い方のポイントまで 品切れ / Vo 4 特集・ C 読本 C 讎吾証しく付き合うためのポイント MO 物Ⅳ MAGAZINE VoI.5 特集・基礎力としてのアセンプラ コンピュータを理解しその能力をひきだすために Vol.6 特集・はしめての 特集・研究「プログラミング統合」 オフシェクト指向 率的オ醗発環境を考える プロクラミンク Vol.7 問題分析、 0 特集・最新「テパイスドライバ」研究 プロクラム設計、 MS ー DOS テパイスドライバの法斤しい そしてプロクラミンク 0 S 環境における ッヒーティスク み「、崋みプ , イル 、 - ・ ~ [ プ 0 クラム プロクラミンクのための 優良図書 ! っ切れ / 品切れ / ー NE 月刊プロクラ、ズ・ページ りつ 付録 5 ・ '2HD フロッビーティスク付 . な Shoeisha C へ . Ltd. 本誌掲載プログラム 役に立つファイルを満載 ヾソコン嗾能強化などによって個人でも楽しめるよう : なってきたコンピュータグラフィックん プラフィックスアプリケーションを乍成するための必要 とプログラミングテクニックが マクロアセンプラ プログラマーズテキスト ・吉川敏則著 ・定価 2.600 円 最イ邸艮必要なハードとソフトの知 識、データ演算士組みを踏まえ た上でアセンプラブログラミンク の基本を丁寧に解言 IJNIX 入門 0 ・日本電子計算株編 ・定価 1.800 円 SONY NEWS の UNIX 講座に 基づく UN Ⅸの入門書。 PC & PS/ 2 ビデオシステム プログラマーズガイド ・ Richa 「 d Wilton 著 ・定価 6 , 000 円 旧 MPC ファミリーのビテオ システム完全力イド。 プログラマーのための PC ソースブック ・ Thom Hogan 著 ・定価 5 , 200 円 旧 M PC&PS/ 2 プログ ラマ必の技術資 * 睆訳。 C 文解駅 ・豊国永健著 ・定価 2.000 円 C 言語の文法書ではあまり取り上 げられてこなかったわかりづらい ポイントを、実際に応用プログラ ムを用いて解言 ン万 プロクラマテキスト 旧 M PC & PS / 2 第 フロクラミンク 3 部作 ' 昼、 P AM s 6 加朝 THE 旧 M PC & PSZ2 プログラマーズガイド ・ Pete 「 No 「 ton & Richa 「 d Wilton 著 ・定価 5 , 200 円 あのピーター・ノートンのベストセラー 旧 M プログラマー必携のスタンダードカ イガンス 吉川を第・ Mic 「 osoft 、ノ朝「こン、し 20 気物ト 1 トれ・しト′ 0 ′ Quick C コン / ヾイラ Ve 「 .2.0 ランタイムライプラリリファレンス Quick BASIC Ve 「 .4.5 ステートメント & 関数リファレンス ・マイクロソフト株式会社監修 ・定価各 2 , 400 円 マイクロソフトの超人気讎吾ソフト Quick シリーズ。 Quick BAS ℃ Ve 「 .4.5 、 Quick C Ve 「 .2.0 スタンタ ードリファレンス。マイクロソフトネ修でオンライ ンヘルプを完全化。サンカレプログラム満載のリ ファレンス。 引 0 ル me & ー第・一・′・、 0 Shoeisha co„い d. 株式会社翔泳社〒 1 02 東京都千代田区平河町 2 ー 4 ー 1 4 平河町 KS ヒル TEL. 03 ー 3263 ー 0447 ( 代表 ) 翔泳社の本は全国どの書店てもお求めになれます。店頭にない場合は「至急」とお申し出の上こ注文いただければ 1 0 日位てお届けてきます。 く資料請求番号 173 〉
れは , 抽象クラスと , そこに実装されてい る操作と , 固有のアプリケーションのため に , そのフレームワークとしての抽象クラ スを特殊化する機能を持ったサプクラスが , 具体的なコードを実装するて、あろうという 仕様から構成される。 フレームワークは , サプクラスの多様性 を支援することによって , アプリケーショ ンを越えて再利用される。 抽象クラスによるフレームワークの前記 のよラな考えは , C 十十よりも Smalltalk の ファミリ言語において一般的て、ある。しか し , C 十十が成熟するためには , フレームワ ークは疑いなく必要て、あり , 部品の再利用 に対してより注意を払うべきて、ある。 「完全なアプリケーション」 ( complete applications) は , 再利用可能な部品て、もあ る。テスキトエデイタや , ネットワークコ ミュニケーションノヾッケーシ , ファイルマ ネージャ , 図形工デイタ , DBMS などは , ほかのアプリケーションシステムの中に埋 め込むことがて、きる。 ただし , オプジェクト指向の実装の性質 こうした具体的なアプリケーション は , さらに洗練されるべきオプジェクト群 から構成されているともいえる。したがっ て , 完全なアプリケーションは , クラス階 層などをより一層洗練することによって , その抽象度を高めフレームワークを形作る ことになる。 「インタフェイスの仕様」 ( interface specification) は , ソフトウェアシステムの 中て、はもっとも抽象的な部品の再利用て、あ り , オプジェクトの機能を具体化するメッ セージの集合から構成される。インスタン スオプジェクトが , このインタフェイス仕 様によって示される役割を果たすため , そ のクラスは機能のための実装を提供してい なくてはならない。これらのインスタンス こうした共通の動きが必要な場合に用 は , いられる。 68 C MAGAZINE 1991 9 こうした再利用戦略は , すべてふたつの 過程によって確定する。再利用可能な部品 の設計開発と , 再利用可能な部品の利用て、 ある。 こうした過程を認知させるためには , チームの相互協力と同様に , 管理上および 技術上の支援が必要て、ある。ときには , 管 理者は指導や評価の手法を修正したり , ソ フトウェア開発者に特別な報酬を与えなけ ればならないて、あろう。 また開発者は , 自分が作ったものて、はな い部品を使わなければならないという個人 的な抵抗との戦いや , 再利用可能な部品の 開発や利用という作業について学ばねばな らない 管理者は , 再利用が望まれるような環境 に変えなければならない。再利用が可能な 部品が存在する場合に , 新しいコードを書 くことは , 受け入れがたいことて、あると考 えなけれはばらない また , ソフトウェア工ンジニアの書いた コードが , その企業のライプラリとして受 け入れられた場合 , また , ライプラリの管 理者がその効果的な使用を定めた場合 , そ のエンジニアは , 営業マンがノルマを達成 したときと同様に , その企業に貢献したと いえる。組織の時間と費用を節約したわけ て、ある。もちろん , こうした貢献は早急に て、はなく , 1 , 2 年後に表面化するものて、あ る。再利用の過程に対しても正当な評価が なされるように , 組織上長期的に対応され なければならない 再利用可能なソフトウェアが受け入れら れるためには , 多くの選択が可能て、なけれ ばならない。再利用のためのパッケージソ フトの購入は , 内部的な初期投資の支出を 避けるという効果がある。しかし , 不利益 としては , ドキュメントやコーディングの 慣例が , 組織のそれとマッチしないことが 適合させられるように , ソースコードの形 これらのパッケージは , 組織のニーズに あげられる。 て、購入されなければならない。それ以上に , 再利用可能な部品が組織内の各プロジェク トて、効果的 , 効率的に共有て、きるように , ソフトウェアの記述形式とドキュメントの 標準が必要になるて、あろう。 ソフトウェアの開発を請け負い , その結 果として再利用可能な部品を得たいと思う ならば , 再利用可能な財産が作られるとい うことに対する所有者意識を契約の中て、明 確にしておかなければならない 開発者の問題は , まずほとんどが社会的 なものて、ある。再利用は努力する価値があ り , 適切な評価とそれを反映するプロジェ クトの構造によってのみ獲得されるという ことを , ソフトウェア工ンジニアに確信さ せねばならない Table 1 は , 開発チームにおける重要な関 係者と , それらを評価するための新たな基 準て、ある。 2 通りのテスト担当者があげられ ていることに注意していただきたい。なぜ ならば多くのプロジェクトて、は , 再利用可 能なフレームワーク ( 抽象クラス ) とコンポ ーネント ( 部品となるクラス ) の 2 種類のオプ ジェクトが作られるために , 2 種類のテスト 形態が存在するからて、ある。 フレームワークのテスト担当者は , フレ ームワークを使えるかどうかがわかるよう な適切なコンポーネントを作り出す。コン ポーネントのテスト担当者は , そのコンポ ーネントが別の分脈て、使えるかどうかを決 定する。したがって , テスト作業は , ソフ トウェアの再利用の範囲を割り当てること こうした作業は , ライプラリ だといえる。 の管理者と共同して行われる。 再利用のテスト作業は , ソフトウェアの テストに対する非常に特殊なアプローチて、 ある。なぜならば , ソフトウェアコンポー ネントが , 広い応用可能性を持って設計さ チームの割り当て
HIG C386 シグナル関数 数々の実績と定評を得たプロテクトモード対応 C 言語コン パイラが、 ver1.7 にバージョンアップされました。新たな ー KiII シグナルを送る 機能と、処理速度の向上を持って、 C 言語のプロフェッショ シグナルを発する ra lSe signal シグナルハンドラの設定を行なう ナル技術者にお届けします。 子プロセス関数 新たな機能 —exec* 子プロセス利用のための関数群 . 80386/Weitek3167 の他に、 80486 内蔵 . FPU 、 Weitek4 馬 7 、 動作環境 Cy 「ⅸ社 EMC87 コプロセッサをサポート。 2. マイクロソフト社の MASM 及び OS/2 ver2.0 の OMF と同じ 必要な八一ドウェア 対応機種 フォーマットのオプジェクトを生成可能。 NEC 32bit 機対応版 3. 従来のライプラリに、割り込み関数、ファイル管理関数、 NEC PC -9800 シリーズ (XL2, RA, RL, LS, ES, RA2 レ 51, RS シグナル機能、子プロセス関数を強化して追加。 4. 従来品よりも多種のコンバイラトグルスイッチと、コン 2 リ 51, T, DA, DS, NS) バイラドライバのオプションスイッチを装備 PC-H98 シリーズ (Model 60 , 70 コ 00 ) N EC 5. よく使われる重要な項目を本マニュアルより抜き出し EPSON PC -386 シリーズ ( 386 , LS, V, M, G) 旧 M PC / AT 互換機対応版 た、 Quick Reference Manual を追加。 東芝」 - 引 OO(SGT, SGX, GXS ) 卩 -3300 強化された関数群 PC/AT 互換機 , 各種 AX マシン ( 80386 / SX 搭載機 ) IBM 割り込み関数 富士通 32bi1 機対応版 現在のプロテクトモードにおける割り込みハ 富士通 FMR-50(HV, S2, (X), FMR-70(H 刈 , HX2, HX3) ー getpvect ンドラの取得 現在のリアルモードにおける割り込みハンド 八一ドティスク ー getrvect 1MByte 以上のプロテクトモードメモリ ラの取得 プロテクトモードにおける割り込みハンドラ ー setpvect のセット 必要なソフトウェア リアルモードにおける割り込みハンドラのセ MS-DOS ー getrvect NEC, EPSON 機 ver3.3 以上 MS-DOS プロテクト / リアルモードにおける割り込み 旧 M PC/AT 機 , AX 機 ve 「 3.2 以上 PC-DOS ー setrpvect 東芝 J - 引圓等 日本語 DOS ver3.l ハンドラのセット ファイル管理関数 英語 DOS ver3.3 open されたファイルハンドルとストリームを 富士通 FMR ve r3 」 Leve に 8 以上 —fdopen MS-DOS Phar Lap Software lnc. 38 引 TOOLBOX( 弊社取り扱い製品 ) 結び付ける —faopen ファイルを open するとともに、分割モードを 定価 \ 178 , 000 セットする べンチマークテスト WHETSTONE( 自社計測 ) 使用機器 : PC ・ 98 田 RL20MHz 十数値演算コプロセッサ ( 80387 or Turbo-3167) 58 [K whetstone/sec] emulator 十 noFPU 200 [K whetstone/sec) emulator 十 80387 巧 40 [ K whetstone/sec] 80387 inline code Turbo-3167 inline code 2380 [K whetstone/sec] DHRYSTONE( ソフトバンク株刊月刊 C マガジン ' 90.8 月号より抜粋 ) 使用機器 : PC-9801RA2 数値演算コプロセッサ ( 80387 ) HIGH C386 6250 [dhrystone/sec] 8(SEC) for 50000 PASSES 4GByte のメモリカゞイ更える C 一言吾 新バージョン / HIGH C386 旧 17 NDP FORTRAN386 386 T00LBOX 386 DEBUG 38 引 DEBUG は、 80386 / 486CPU のためのシンホリックテ MS - DOS の 640KByte という狭いメモリの制限 NDP FORTRAN386 は、 FORT 日 AN77 仕様に完全準拠した 80386 バッガです。 38 引 DOS - Extende 「を利用する 32bit プロテク を越えて、 4GByte という広大なアドレス空間を利用者に提 CPU プロテクトモード専用 FORTRAN コンノヾイラです。 供するユーティリティ。それが、 38 引 TOOLBOX です。 最大の特長てある、プロテクトモードの 4GByte のアドレス トモードのプログラムのみならす、通常の MS - DOS のリア 38 引 TOOLBOX は、 38 引 DOS-Extender というユーティリ 空間と、最適化による高速コードの生成により、 VAX8600 / ルモードプロクラムをもサポートします。 使用の際は、 38 引 TOOLBOX ( 弊社取り扱い製品 ) が必要てす。 ティを使用して、 32bit プロテクトモードという従来の MS - SUN3 等の汎用コンピュータ / ワークステーションクラス DOS が十分に活用していなかった 80386 / 486CPU の特長を、 の規模と速度を持つ、アプリケーションの開発を可能にし 定価 \ 58 , 000 ました。使用の際は、 38 引 TOOLBOX ( 弊社取り扱い製品 ) が MS - DOS から 100 % 活用可能にしました。 38 引 TOOLBOX は米国 Pha 「 Lap Softwa 「 e 社の開発した 38 引 必要です。 ASM, 386 旧 NK , 386 旧 B , ・ RUN386 , MIN 旧 UG, C 日 G386 386 VMM 動作環境 で構成されているユーティリティです。これらはアセンプ ラ、リンカ、ライプラリアン、 3861DOS-Extender 、デバッ 38 引 TOOLBOX の動作環境に依存 ( ただし、富士通版はあり ガ、コマンドオプションのカスタマイズプログラムてあり、 ません ) 。 プロテクトモードプログラムの開発環境を提供します。 プロテクトモードメモリ 2MByte 以上 数値演算コプロセッサ 動作環境 定価 \ 148 , 000 必要な八一ドウェア対応機種 NEC 32bit 機対応版 SPACE-II PC -9800 シリーズ (XL2, RA, RL, LS, ES, RA21/51 , N EC RS21/51, T, DA, DS, NS) PC-H98 シリーズ (Model 60 , 70 , 田 0 ) N EC EPSON PC -386 シリーズ ( 386 , LS, V, M, G) 旧 M PC / AT 互換機対応版 東芝」 - 引 OO(SGT, SGX, GXS), 」 -3300 PC/AT 互換機 , 各種 AX マシン ( 80386 / SX 搭載機 ) IBM 富士通 32bit 機対応版 富士通 FMR-50(HV, S2, (X), FMR-70(HXl, HX2, HX3) 八一ドティスク 1MByte 以上のプロテクトモードメモリ 必要なソフトウェア MS-DOS NEC, EPSON 機 MS-DOS ver3.3 以上 旧 M PC/AT 機 , AX 機 PC-DOS ver3.2 以上 東芝」 - 引 00 等 日本語 DOS ve r3 」 英語 DOS ver3.3 ver3.I Leve に 8 以上 富士通 FMR MS-DOS 386 Ⅳ MM は、 38 引 TOOLBOX に含まれる 38 引 DOS-Extender 、八一ドティスクを利用した仮想記憶機能を付加する仮 想記憶マネージャです。 使用の際は、 38 引 TOOLBOX ( 弊社取り扱い製品 ) が必要です。 定価 \ 86 , 000 発売 バックセッ 科学技術演算ライプラリ SPACE - Ⅱは、学会論文・雑誌論文 などに発表された最新のアルゴリズムを採用して作られ 2 点バックセット た、数値演算に必要となるサプルーチンの汎用科学技術演 386ⅣMM 十 3861DEBUG 算ライフラリ集てす。 3861TOOLBOX 十 3861DEBUG 使用の際は、 NDP FORTRAN386 ( 弊社取り扱い製品 ) が必要 38 引 TOOLBOX 十 386 Ⅳ MM です。 3 点バックセット 定価 \ 98 , 000 3861TOOLBOX 十 386 Ⅳ MM 十 38 引 DEBUG Y248 , 200 ブッりソフト & プー辷ユ株式会社コンピュータ事業部 Ⅵ 29 , 600 Ⅵ 75 , 0 判 98 , 900 〒 273 千葉県船橋市本町 7 ー 1 ト 5 レランドセンターピル 5F Te に 0474 ー 23 ー 1322 ( 営業直通 ) Fax: 0474 ー 23 ー 0202 Tel: 0474 ー 22 ー 9355 ( ユーザーサービス直通 10 : 00 ~ 12 : 00 , 13 : 00 ~ 16 : 0 の く資料請求番号 062 〉 定価 \ 148 , 000 ※すべての価格に消費税は含まれておりません。
ースタートアップ C + クラス ( 1 ) 実力養成講座 第 。前回まで O 言語に対して拡張された機能について解説 してきた。今回より 2 回にわたり , C 十十の機能の中でも っとも特徴的かつ重要な要素である「クラス」について 解説する。クラスも C 言語を拡張した機能のひとっとし 第て捕えることができる。当然 , 」を拡張された機能の中に一、 は , 新しい概念から生まれたものもある。ここでは , C き語の造体と較からクースの 理論編 とつの単位として扱えるということてある。 『 : ク ? スとは また , 参照てきるメンバと , 参照てきない クラスの定義は , 単に型を決定したにす メンバを区別することもてきる。このよう ぎない。構造体て、は , 構造体の定義を行っ にクラスを構造体の概念の拡張とみなすこ たあとに構造体変数や配列を宣言する。同 クラスは , C 言語の構造体 ( 以下構造体 ) と とにより , クラスの使い方は構造体と同様 同様にユーザが定義する型てあり , 構造体 様に , クラスの定義のあとにクラス変数や 概念を拡張した機能を持つ。構造体は種類 に行える。ただし , 拡張部分の取り扱いが 配列の宣言を行う。クラス変数宣言は , 特徴的なものとなる。 定義済みクラス名変数名 の異なった型のデータをひとつの単位とし て扱うことがてきる。クラスとして拡張さ となる。 クラスの定義 れた概念および機能は , データだけてなく , メンバー そのデータヘアクセスを行う関数まてもひ 構造体がユーザ定義の型てあるように クラスもユーザ定義の型てある。つまり , 構造体の概念を拡張したクラスをメンバ コラム というタームを使ってまとめると クラスを使用するためには , クラスの型の C 十十の構造体 ①関数をメンバとすることができる 定義を行う必要がある。構造体ては , キー C + + にも構造体は存在する。ただし , ②スコープによるメンバの区別 ワード struct により型の定義を行い , 型名に クラス型のひとつの種類として存在す 相当するタグ名をユーザ ( プログラマ ) が決 といえる。 るものである。構造体の定義はキーワ 定した。クラスの定義ては , キーワード class 関数をメンバとする場合は , クラス定義 ード class をキーワード st 「 uct に置き換 の中て関数の定義を行うか , プロトタイプ により型の定義を行い , 型名に相当する「ク えたもので , ラベルが別の保護レベル ラス名 ( タグ名 ) 」をユーザが決定する。ク 宣言を行う必要がある。プロトタイプ宣言 を示すまで自動的にバブリックメンバ ラス定義は , を行ったメンバとなる関数は , クラス定義 となる。つまり , 自動的に設定される class クラス名 { とは別に関数を定義する。 Fig. 1 に示すよう 保護レベルが異なる以外は , クラスと に , クラス定義とは別にメンバとする関数 メン / ヾ 同じものである。 を定義する場合は , 関数の型と関数名の間 龍崎昌平 スタートアップ C 十 + 123