設計 - みる会図書館


検索対象: 月刊 C MAGAZINE 1991年6月号
57件見つかりました。

1. 月刊 C MAGAZINE 1991年6月号

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

2. 月刊 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

3. 月刊 C MAGAZINE 1991年6月号

詳細を満たすために用いるのて、ある。そう ーとは , そのオプジェクトと関係をもつオ スタンス群は特定の名前以外は同じて、あり , ことから , クラス設計とメソッド設計 プジェクトが , そのオプジェクトを見つけ クラスの仕様の変史は , 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

4. 月刊 C MAGAZINE 1991年6月号

て、は 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

5. 月刊 C MAGAZINE 1991年6月号

も , 強調されて表現される。これらの結合 は , インヘリタンスやオプジェクト相互の 関係などを示している。普通 , ーっか二つ の結合が二つのクラス間に存在する。設計 ERD からは , 包括的な継承構造はたやすく 見たり評価したりすることがてきる。クラ スの結合は , クラスの結合の数や型によっ て示される。 Fig. 1 は , 実体ー関連モデルにおける , 条 件なしの多対多の関係 ( M : M ) と呼ばれるもの を示している。実体ー関連モデルては , オプ ジェクト相互の関係を , それぞれに関与す るオプジェクトの数に基づいて , 三つの基 こに述べる多対 本的な形式に分類する。 多 (M : M ) 関係のほかに , 「州にはひとりの 州知事がいる」のような , 1 対 1 ( 1 : 1 ) 関係 , game—node— らメソッドの最初の手がかりをも得ること の手がかりになる。後に , 私たちは DFD か 分析上のクラスは , 設計上のクラスの最初 に写像することによって設計を開始する。 Cadre 手法て、は , まず分析 ERD を設計 ERD 分析から設計へ げることがて、きる。 につくことはて、きない ) 」といった関係をあ 席を満たす ( 条件 : 上院議員て、なければ議席 と記述され , 例として , 「上院議員は上院議 たとえば , 条件っきの 1 対 1 関係は , ( 1 : IC) り , それらに条件が付加するものもある。 といったような , 1 対多 ( 1 : M) の関係があ 「大の所有者は ( 多くの ) 犬を所有している」 Fig. 2 アニマルゲームのオプジェクト指向クラス設計 となる。 こては , 分析 ERD において , 相 互関係テープルや参照される属性などによ り , 表現される関係がしばしばオプジェク トに対するポインタに置き換えられる。 うした物理的な情報をその分析モデルに付 け加えることは , 機械的に行われる。 次の過程は , より非機械的て、あり , より 不整構造な作業て、ある。いくつかの分析ク ラスは , 単純な設計クラスにマージされる。 そのほかの新たに設計されたクラスは , 設 計者によって選ばれた「メカニズム」を表現 することになる。ほかのメンバ変数は , 冗 長なデータや設計メカニズムなどを表現す るために , クラスにつけ加えられる。 先の動物当てゲームの例ては , 2 進木メ カニズムによる設計を選択してみた。分析 branch no— branch yes— pa re nt— of 「 00t ー Of game ・・ @address 十—>root—node(R) 70 C MAGAZINE 1 1 6 game—node: @address 十 (—>parent—node(R)) lS—a animal: @address 十 @2 animal— name characteristic. @address 十 question 十—>yes—node(R) + —>no—node(R)

6. 月刊 C MAGAZINE 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

7. 月刊 C MAGAZINE 1991年6月号

人に優しいソフトウェア 0 インテワ株式会社 新しいソフトウェアの流れが、 インテグから始まる。 ようこそ、知の工房へ。 パソコンは私達の未来をもっと面白くする。そうインテグは考えています。 スタッフの頭の中は、 新しいアイディアとプロジェクトでいつばいです。 私達にとって大組織はそれを実現するのにあまりに狭すぎました。 選ばれた技術者が結集し、最高の環境で、 クリエイテイプな仕事をこなす。 「人に優しい」というコンセプトで、 ノヾソコン市場を広げた新製品をプロデュースできたのも、 私達が高度知識集約型集団であるからにほかなりません。 あなたの夢を聞かせて下さい。 それを実現するための必要な条件は、 ここにすべてそろっています。 仕事に追われる毎日で、人生に梅いは残りませんか。 - 新一図出力工ケニ ) ーア 第・逆日影高宿 ・一針画書号 : 2 こ道路料線 高度新線 二北線 ロ逆日影 表示そ - ド■転 ■転第 新製品の Advanced SPIRITS 建築設計者のためのトータルな企画計画設計支援 システムとして、プロフェッショナルユースに応 える優れた操作性と充実した機能を誇ります 新しいソフトウェアの波を、 私達と一緒に創造していきませんか。 ・会社プロフィール■ 設立 / 平成元年 5 月 資本金 / 2 〕万円 社員魏 / 6 名 出資株主 / 山田建設株 ( 資本金 2 億 2 第〕万円 ) 事業内容 / ・パソコン及び工ンジニアリング ワークステーション・ソフトウ ェアの開発、並ひに販売 ・コンヒュータシステム及ひソフ トウェアの導入に関するコンサ ルタント並びにユーサー教育 ・募集要項・ 職種 / 0 ) S E ・プログラマ 2 呂 給与 / 子矣・能力を考慮して優遇 ※女性歓迎 ※① C 言言吾の吊矣者 資格 / 専門卒以一日 2 歳迄 ( 冫凡用パッケージソフトの言十・開発 ) く資科請求番号レ 6 〉 勤務地 / 本ネ土 ( 池袋 ) 諸手当 ( 住宅・職能・残業・役物 備、交通費全額支給、退職金制度有、 待遇 / 昇給年 1 回、賞与年 2 回、社完 勤務時間 / 9 : ~ 17 : 関 休日凩段 / 完全週休 2 日制 ( 土・日・祝 ) 年末年始、有給イ和 ( 初年度 14 日 ) 、 特別イ和段 応 / 電話連絡の上、履歴書 ( 写真貼付 ) を 持参でこ来社下さい。 ※応募の秘宅厳守します。 ※電話による問い合わせ歓迎します。 G 1 2 階 03 ー 3982 ー 2861 担当 / / 神谷 〒 171 東京都豊島区冫也袋 2 ー 40 ー 2 スペース ・連絡先・ 効圃 / 」 R 池袋駅西口徒歩 4 分

8. 月刊 C MAGAZINE 1991年6月号

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 思考の周辺

9. 月刊 C MAGAZINE 1991年6月号

護範囲の区分て、はなく , 権利行使の段階て、 公共政策を実現しようとした。 Ashton-Tate Corp. 対 Richard Ross ーっのプログラム製品 , とくにゲームソ フトなどの開発などて、は , しばしば , ユー ザインタフェイス画面部分とコンヒ。ュータ プログラム部分を分担して作成することが ある。本件は , そのような共同開発者らの 著作権の権利帰属が問題となった。 ロス氏と訴外ウイギントン氏は , ロス氏 が計算工ンジン ( プログラム ) 部分を , ウィ ギントン氏がユーザインタフェイス部分を おのおの担当して , スプレッドシートプロ グラムの共同開発を進めた。その際ロス氏 は , ユーザインタフェイスに含めるべきコ マンドリストをメモ書きして , ウイギント ン氏に渡した。その後両氏は対立。ウイギ ントン氏はアシュトンテイト社に入社し , 自身が開発していたユーザインタフェイス 部分とアシュトンテイト社の計算工ンジン 部分とを結合させて「 FulI lmpact 」と呼ばれ るスプレッドシートプログラムを完成させ 争いは , ロス氏の主張から始まった。 Full lmpact のユーザインタフェイスには自分に も著作権の持ち分があると主張して , 訴え を起こしたのて、ある。問題は , ロス氏が共 同著作者と認められるためにはどの程度の 寄なが必要なのかという点て、あったが , 裁 判所はほば以下のような判旨て、ロス氏の主 張をしりぞけた。 ・共同著作の要件は , おのおのが独立して それ自体著作物性のある寄をなすこと。 ・ロス氏のコマンドリストのメモ書きは , 著作権保護に値しない ロス氏のメモ書きを入手したが , 素人目 にもあまり役に立つものとは思えないもの て、あった。したがって , 裁判所がロス氏の 貢献を低くみなした点は理解て、きる。現在 のソフトウェア開発て、は , ューザインタフ ェイスとプログラムの開発が別々に行われ たり , ューザインタフェイス開発だけて、も , 数人が共同て、行ったり , ューザの意見やノ ウハウを取り入れたりする場合がある。そ の場合の権利帰属については契約だけて、は 対処て、きない場合も起こり得るて、あろう。 そういった点て、 , 非常におもしろい論点を 提示した事件といえよう。 周知のとおり , この種の問題に対する米 国の活動は活発て、ある。情報産業に多数の 企業が参入していること , 紛争の多いこと , 知的所有権問題を政策問題としてとらえて いることなどから , 当然 , 産業 , 法曹 , 学 界や政府機関の調査研究は盛んて、あり , そ の国際的な影響力は大きい。なかて、も , 判 例のもつ意味は大きいのて、 , 今後も継続し てウォッチする必要があるだろう。 ティレクテイプをめぐる EC の動向 市場統合を 1992 年に控え , ヨーロッパ共 同体の動きは政治・経済両面において活発 化している。コンヒ。ュータブログラム法的 保護問題についても例外て、なく , 加盟各国 の法制度の調和を目的として , コンヒ。ュー タブログラムの保護に関するディレクティ プ ( 理事会指令 ) を起草中て、ある。ディレク テイプは , EC 条約を根拠とする文書て、あ り , 通達された場合 , 各国政府はその規定 48 C MAGAZINE 1991 6 を遵守する必要がある。また , 場合によっ ては法改正も義務づけられる。したがって , 草案中のディレクテイプが正式に採択され た後は , EC 域内て、のコンヒ。ュータブログラ ム法的保護に関する基本スタンスが確立す るて、あろうといわれている。 さて , 今回のプログラムに関するディレ クテイプは , 著作権による保護のハーモナ イズを企図しているが , プログラムの著作 権保護上の諸問題がさかんに叫ばれている 中て、の著作権立法て、あること , さらに統合 による EC の経済力 , 政治力の増大という背 景から , ディレクテイプ条文の一字一句に 世界の耳目が集まっている。 ョーロッパ先進国にも興味深い判例が数 多くあるが , 上述のように , 現在法制度を めぐる議論の真最中て、あるのて、 , ここては , ディレクテイプそのものを最新動向として 摘記する。なお , こて、紹介するのは , 現 時点て、の最終案となっている ' 91 年 12 月 13 日 に採択された「 Common Position 」て、ある。 全 11 条からなる Common Position て、は , まず , 第 1 条て、 , 保護の客体が規定されてい こて、は , 「コンヒ。ュータブログラム 設け , ある程度の指針を示している。 規約および解法にはおよばない」との規定を 物を作成するために用いるプログラム言語 , て、に第 10 条 3 項「保護は , ( プログラム ) 著作 なお , 日本著作権法て、は 1985 年改正て、 , す テム時代の立法を象徴するものといえよう。 ュータ利用の高度化 , マルチベンダーシス てて、あり , ネットワーク相互接続 , コンヒ。 象外として明記した条文は , おそらく初め いる。プログラムインタフェイスを保護対 インタフェイスは保護されない」と規定して の基礎となるアイデアや原則 , プログラム グラムのあらゆる表現が保護されるが , そ 第 1 条て、は , さらに 「コンヒ。ュータブロ ろう。 といわれており , 比較検討の必要があるだ 射程は , 詳細設計より抽象度の高いレベル 米国判例 WheIan 事件 , PerIsystem 事件の 則の詳細設計レベルと理解し得る。前項の かれていることから , コーディングー歩手 ヒ。ュータブログラムが出来あがるもの」と書 条文の前書きに「後にその準備作業からコン 資科が , どの程度のものかが問題て、あるが , 葉に含まれるとしている。準備段階の設計 計資料もコンヒ。ュータブログラムという言 が明記されている。さらに , 準備段階の設 語の著作物 ) として著作権保護される」こと は , ベルヌ条約上のリテラリワーク ( 文字言

10. 月刊 C MAGAZINE 1991年6月号

すでに「 C 」言語ユーサー 標準ツール 各入力項目毎にデータの形式、 35 種類の完了条件 が設定できます。プログラム実行時には、これらのチェ ックを終えたデータのみをユーザープログラムに引き / 度すので、プログラム作成の負担が大幅に軽減します。 B ー FO 日 P で予めに 0 種類を用意してあり、好みのバタ ーンで塗込が可能。さらに、ユーザー定義バターンを に 0 種類までサポート。表現できない色はない程の機 能です。 B-F 0 日 P で予め 24 種類のバターン備。さらに 120 0 ◆種類までユーザー定義可能。罫線色も 8 色 ( 黒色を 含む ) サポート。そして斜線を引くことも可能です。 V 一日 AM を直接アクセスすることにより、ウインドウの 高速処理を実現、メモリーに取り込んだ複数の画面 を個別に範囲指定して表示・消去が可能。リリース 関数を併用すれば田 0 画面でも 200 画面でも O K です。 マルチウインドウ実行例 「 B - FORP 」は、 printf 、 scanf を使わずに画面の設計制御を可能にした画 期的なツールです。汎用機のレベルをパソコン上で実現した、まさに「 C 」 ユーサーが待ち望んでいたツールです。 ※資料ご希望の方は電話にても受付ております。下記弊社営業部までご連絡下さい。 NEC PC -9800 シリーズ ・本体 NEC PC -9800 シリーズ ・本体 ・ B - FO 日 p ( レイアウトエデイタ + ランタイム関数 ) 89.05 MS-DOS ve 「 . 3 1 以上 ・ OS M S -D 0 S ver. 3 1 以上 ・レイアウトエデイタ ( 3 を 2HD 、 5 ?HD) 59 .05 ・ OS 39. 00 ( 各種日本語入力 FEP 使用可 ・漢字入力 ・ランタイム関数 ( 3.5 2HD 、 5 ?HD) ・対応言語 MIC 「 0S0 れ C/TURBO C Lattlce C PC -P R201 シリーズ ( レイアウト印刷用 ) ・プリンタ 各種日本語入力 FEP 使用可 ※ M S -D O S 及び日本語入力フロントプロセノサは付属しておりません ・漢字入力 * MS - DOS 、 MIC 「 0S0 い C は米国 MIC 「 0S0 社の登録商で B ー FO 日 P を使って作成したフログラムに対するライセンス料は不要です。 *TURBO C は米国 80 ⅱ and 社の登録商標です ネ LattIce C は米国 LattIce 社の登録商標です 本社 / 〒田 5 東京都港区東新橋 2 ート 7 ( 住友生命東新橋ビル 6F ) 谷東京 ( 03 ) 3432 ー田 77 ( 営業部直通 ) ( 03 ) 3432 ー 03 引 ( 代表 ) く資料請求番号 004 〉 B-FORPver 2 当行目町呷第 画面設計制御ツール この商品はマイコンショー ' 91 に出展いたします 東泉流通センター・プース N 。 .3 ーに ( 第 3 会場 ) ・ 5 月 8 日 ~ 5 月凵日 Forrrøt P 「 8e7 「 B—F(W ve 「 .2.2 (c) Copyright 1 , , BITS 8. , Ltd. Japan タイルバターン登録画面 フィールド属性定義画面 工主 「コ 1 望 ラインバターン登録画面 「 B-FORP 」システムフロー ルーい屯 画面レイアウト 工デイタ 画面情報 ファイル 画面制御ライプラリ ( ランタイム関数 C 言語 標準ライプラリ ユーザ プログラム 実行モジュ 実行 ランタイム関数動作環境 レイアウトエテイタ・・動作環境 価格 ( 社 ) 日本システ乙ハウス協会会員 株弌にリ