JPH0736684A

JPH0736684A - ドメイン指向部品管理方法

Info

Publication number: JPH0736684A
Application number: JP5178792A
Authority: JP
Inventors: Kimito Takadate; 公人高舘
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1993-07-20
Filing date: 1993-07-20
Publication date: 1995-02-07

Abstract

(57)【要約】【目的】新たなアプリケーションで必要となる機能を
指定するだけで、関連する部品をまとめてライブラリか
ら検索して部品検索の的中率を向上させ、大規模な再利
用を促進する。【構成】類似する機能を有するアプリケーションの集
合であるドメイン毎に、部品と、ドメインに共通な機能
の汎化階層関係を蓄積したテーブルと、機能と機能を実
現する部品の関連を蓄積したテーブルを部品ライブラリ
に管理する。利用者が部品を検索する際に、機能の汎化
階層テーブルを読み込み（１００）、機能の汎化階層を
画面上に表示する（１０１）。機能の汎化階層の中か
ら、利用者が選択した機能を読み込み（１０２）、機能
部品関連テーブルから利用者が選択した機能を検索し、
対応する部品を検索する（１０５）。検索した部品をま
だ表示していなければ（１０６）、検索した部品の名称
を表示する（１０７）。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ソフトウェア部品の管
理方式、再利用方式に関する。特に、コンパイラ、図形
エディタなど共通の性質を有するアプリケーションの集
合をドメインとみなし、ドメイン毎にドメイン内で再利
用できる部品を管理する部品ライブラリに関する。部品
の階層構造以外に、部品と部品が実現する機能の関係
と、機能の階層構造を有し、ドメインに属する新しいア
プリケーションを開発する際に、利用者の機能設計を支
援すると共に、部品の再利用を促進するものである。

【０００２】

【従来の技術】従来の部品ライブラリは、部品に付加し
たキーワードで部品を検索するものであった。例えば、
特開平０２−４１５２４の”ソフトウェア部品再利用管
理方式”に見られるように、部品名、作成者、作成日等
の情報を付加し、これらの情報を基に検索していた。ま
た、特開平０４−４８３３０の”ソフトウェア部品管理
方式”では、部品に機能名、業務名を付加して記録し、
検索の際に利用していた。

【０００３】また、近年オブジェクト指向言語で記述し
た部品である、クラスを管理するクラスライブラリが注
目を集めている。オブジェクト指向では、ソフトウェア
を構成するクラスを、スーパークラス／サブクラスの関
係に着目して階層的に作成することに特徴がある。スー
パークラスとは、サブクラスを汎用化したクラスであ
る。例えば、三角形の画面上での表示／移動／消去を行
う三角形クラスと、円の表示／移動／消去を行う円クラ
スがあったときに、図形の表示／移動／消去を行う図形
クラスは、三角形クラスと円クラスのスーパークラスに
なる。逆に、三角形クラスと円クラスは、図形クラスの
サブクラスになる。クラスライブラリでは、クラスを階
層的に管理し、階層構造を利用者に見せるので、部品が
平坦に管理されている従来のライブラリと比べると、ク
ラスの機能が明確化し、再利用が容易になった。オブジ
ェクト指向を適用して部品を管理する特許は、特開平０
２−１０５２２２の”ソフトウェア自動生成装置とソフ
トウェア自動生成方法”がある。

【０００４】さらに、第３６回情報処理全国大会論文集
ｐｐ．９５３〜９５８の”電子レンジ制御プログラム開
発支援システムの開発”に見られるように、電子レンジ
の機種と機能の対応関係を管理する製品仕様ＤＢと、部
品を管理する部品ＤＢを有するシステムも存在した。利
用者が指定した機種名と部品名を基に、部品ＤＢから部
品を検索する。検索した部品を複数機種に対応できるよ
うに変換するために、機種と機能の対応関係を製品仕様
ＤＢから検索し、機種を機能の有無によってグループ化
し、グループ化された機種を判別する分岐命令を部品の
中に挿入する。

【０００５】さらに米国では、共通の性質を有するアプ
リケーションの集合をドメインとみなし、ドメインに属
する複数のアプリケーションから、再利用性のある仕様
書やプログラムを抽出し再利用する、ドメインエンジニ
アリングが注目を集めている。Carnegi-Mellon Univers
ity Software Engineering Institute(November 1990)
のテクニカルレポ−ト”Feature-Oriented Domain Anal
ysis(FODA)FeasibilityStudy”では、同じドメインに属
する複数のアプリケーションを横断的に見て、アプリケ
ーションの有する機能を抽出し、機能の階層図を作成す
る。機能階層図は、抽出された機能をドメインに属する
アプリケーションにとって、必須か択一か省略可能かで
区別して表現している。本階層図は、同じドメインに属
する新しいアプリケーションの機能設計の際に指針にな
る。

【０００６】さらに、変更の影響個所や誤りの個所を特
定する技術としては、例えば、特開平０４−１３１９３
０の”ソフトウェア改造支援装置”に見られるように、
ソフトウェアを構成する部分の間の関連を有し、ある部
分を変更したときに他のどの部分に影響が及ぶかを教え
るものであった。特開昭６３−９３０５３の”プログラ
ムテスト装置”では、プログラム構造に関する情報を自
動的に抽出し、変更に影響を及ぼす部分の、今までのテ
スト結果を無効にするものだった。

【０００７】

【発明が解決しようとする課題】従来の部品ライブラリ
では、部品を特定のキーワードで検索する。利用者が適
切なキーワードを指定しないと、目的とする部品は検索
できない。蓄えられている部品の数が多くなると、キー
ワードの数も多くなり、どのキーワードを指定すれば、
目的の部品が検索できるのか、利用者には分からなかっ
た。また、蓄えられている個々の部品の規模は小さいも
のであった。例えば、ソートする部品、和暦を西暦に変
換する部品などである。アプリケーションの１つの機能
を実現するためには、いくつかの部品が必要になる。利
用者は、検索した部品を組み合わせて、１つの機能を実
現する必要があった。

【０００８】オブジェクト指向のクラスライブラリで
は、クラスの機能が明確化されたが、反面、オブジェク
ト指向を理解していないと利用できないものになった。
また、個々の部品の大きさは小さく、アプリケーション
の１つの機能を実現するためには、いくつかのクラスが
必要である。利用者は、検索したクラスを組み合わせ
て、１つの機能を実現する必要があった。

【０００９】電子レンジ制御プログラム開発支援システ
ムでは、製品仕様ＤＢの中にアプリケーションの機能の
情報が含まれているが、部品の検索に利用している訳で
はない。部品の検索は、利用者が部品名を指定すること
で行う。

【００１０】また、ＦＯＤＡは機能の階層関係をドメイ
ン毎に構築する。機能階層は要求分析の際に要求仕様を
決めるのに利用する。しかし、機能とプログラムの関係
については、言及していない。従って、ＦＯＤＡでは要
求分析とプログラム開発を連続して支援していなかっ
た。

【００１１】さらに、変更の影響個所を特定する技術は
あったが、ソフトウェアの一部を変更した時に、他に何
処を修正すべきかを指示する技術であった。仕様変更に
なった時に、どの部分を変更すべきかを指示するもので
はなかった。

【００１２】さらに、従来の部品ライブラリでは、再利
用するクラスは蓄積されていたが、クラスの利用方法を
示す情報は蓄積されていなかった。利用者は、複数の部
品を組み合わせて利用する際に、部品の呼び出し順序が
分からず苦労した。

【００１３】本発明の目的は、新たなアプリケーション
で必要となる機能を指定するだけで、機能に関連する部
品をまとめてライブラリから検索することにより、部品
検索の的中率を向上するとともに、大規模な再利用を促
進する部品管理方法を提供することにある。

【００１４】

【課題を解決するための手段】本発明は、ドメインエン
ジニアリングの考え方を部品ライブラリに適用し、アプ
リケーションのまとまった機能単位に、複数の部品の再
利用を可能にするものである。ドメインとは類似する機
能を有するアプリケーションの集合であり、コンパイ
ラ、図形エディタ、給与計算ソフトなどがそれぞれ１つ
のドメインになる。部品の管理範囲を、１つのドメイン
に対象を絞ることによって、部品の汎用性が損なわれる
一方で、ドメインが有すべき標準的な機能に着目して、
部品をまとめることができる。ドメインが有すべき標準
的な機能は、ソートする、日付を計算する等の、規模の
小さい処理ではなく、これらの処理を集めたものにな
る。例えば、図形エディタのドメインでは、図形を挿入
する、移動するなどが機能になる。移動機能は、図形が
選択されたときに明示する処理、移動メニューを表示し
利用者に選択させる処理、編集領域の利用者が指定した
移動先にマーカーを表示する処理、図形を移動させる処
理、図形に接続した別な図形も連動して移動する処理か
ら構成される。ドメインに着目することで、これらの一
連の処理に関連する部品を、機能に着目してまとめるこ
とができる。ドメインを良く理解した人にとっては、機
能は分かりやすいので、目的とする部品を容易に検索で
きる。部品間の階層情報以外に、機能と機能を実現する
部品との対応関係を有し、利用者が選択した機能に対応
する複数の部品を検索することで、部品の検索を容易に
すると共に、まとまった単位での部品の再利用を可能に
する。

【００１５】本発明で扱う機能の階層関係は、構造化設
計技法で用いる機能階層図における階層関係とは異な
る。従来の機能階層と、本発明で扱う機能階層の違い
を、２つのファイルのマージ機能を例にし、図２３で説
明する。図２３(a)は構造化設計技法で用いる機能階層
図であり、ファイルのマージ機能（２３００）は、ファ
イルの読み込み機能（２３０１）、ファイルの比較機能
（２３０２）、ファイルの書き込み機能（２３０３）か
ら構成されることを示している。読み込み機能、比較機
能、書き込み機能は、マージ機能の一部であり、マージ
機能とは包含関係に有る。

【００１６】一方、図２３(b)は、本発明で扱う機能階
層図であり、ファイルのマージ機能（２３００）には、
同一部分を重複してマージする機能（２３０４）と、重
複する部分を排他的にマージする機能（２３０５）が有
ることを示している。また、両方のマージ機能には、フ
ァイル内の各項目に付けられたキーに従って、キーの順
にマージする機能（２３０６）と、２つのファイルをつ
なぎあわせる単純マージ機能（２３０７）が有ることを
示している。ファイルのマージ機能には、様々なマージ
機能が有り、より特殊化されたマージ機能になってい
る。本発明では、このような機能の関係を、機能の汎化
関係と呼ぶ。

【００１７】機能の汎化関係と部品を対応つける管理方
法と、機能の包含関係と部品を対応付ける管理方法は異
なる。機能の包含関係と部品を対応付ける場合には、読
み込み機能、比較機能、書き込み機能、比較結果の出力
機能毎に、対応する機能を実現する部品と対応付ける。
マージ機能には、これらの機能を実現する部品を呼び出
す部品が対応付けられる。

【００１８】一方、機能の汎化関係と部品を対応付ける
場合には、その機能で必ず利用する機能のみを対応付け
る。例えば、ファイルを読み込む部品、書き込む部品は
マージ機能には必ず必要なので、マージ機能と対応付け
る。一方、ファイルを比較する部品は、特殊化されたマ
ージ機能毎に異なるので、機能毎に異なる比較部品を対
応付けることになる。

【００１９】１つのドメインに着目することによって、
機能を体系付けて表現することができる。例えば、移動
機能には、移動する図形と移動先を指定させ移動させる
機能と、移動する図形を一端カットし移動先でペースト
する機能の２種類が有る。機能とその上位機能との対応
関係を有し、機能の階層関係を利用者に提示すること
で、機能の理解を深めると共に、機能の選択の際の指針
を示すことができる。

【００２０】さらに、本発明では、新しいアプリケーシ
ョンの開発途中に、利用者が指定した機能が変更になっ
た際に、既に開発しているプログラムのどこに影響が及
ぶかを、自動的に検出してくれる。変更前の機能におい
て呼びだされる部品と、変更後の機能において呼びださ
れる部品とを比較する手段を設け、部品名が異なってい
るか、部品のインタフェースが異なっているかをチェッ
クする。異なっている場合には、既に開発したプログラ
ム中から、該部品を呼び出している部分を検索する手段
を設ける。該部分を機能の変更において影響を受ける部
分として表示する手段を設けることによって、変更影響
箇所を特定する。

【００２１】さらに、本発明では、汎用的に利用可能な
部品だけでなく、汎用的に利用できる部品を利用してい
るサンプルプログラムも蓄積する。さらに、汎用的に利
用可能な部品と、外部品を呼び出すサンプル的な部品と
の関連も蓄積する。これによって、検索した部品の利用
方法が理解容易になり、再利用が容易になる。

【００２２】

【作用】部品ライブラリに、部品と、部品の間の階層関
係の情報と、ドメインが備えるべき標準的な機能と、機
能の間の階層関係の情報と、機能と機能を実現する部品
の関係を有し、利用者が新規アプリケーションを開発す
る際に、機能間の階層関係を提示する。利用者が、該機
能群から新規アプリケーションで必要となる機能を選択
することにより、機能に関連する部品一式を検索する。
これによって、利用者が理解しやすい項目で部品が検索
できる。さらに、小規模な部品単位の再利用ではなく、
関連する部品一式の大規模な再利用が可能になる。

【００２３】利用者が、機能の選択を変更した際に、機
能と機能を実現する部品の関係を利用し、既に開発した
アプリケーションの中で、影響を受ける部分を特定す
る。機能と部品の関係を管理しているので、機能を指定
するだけで、変更すべき部品を特定でき、変更前の部品
を利用している部分が変更が必要な部分になる。変更前
の機能において呼びだされる部品と、変更後の機能にお
いて呼び出される部品とを比較する。部品名が異なって
いたり、部品のインタフェースが異なっている場合に
は、変更前の機能において呼びだされる部品を、呼び出
すアプリケーションの部分を検索する。

【００２４】利用者が、目的とする部品を検索できて
も、部品の利用方法が分からない場合がある。この時に
部品を利用するサンプルプログラムが役に立つ。再利用
の対象にはならない部品でも、部品ライブラリに蓄積す
る。利用する部品とされる部品を関連付け、目的とする
部品を検索した際に、サンプルとして利用者に示すこと
によって、再利用する部品の理解を助ける。

【００２５】

【実施例】以下、本発明の１実施例を詳細に説明する。
本発明を用いて部品を管理した場合の、部品再利用の処
理手順の１実施例を図１にフローチャートで示す。図２
は、本発明のハ−ドウェア構成を示す図である。２００
は本発明のプログラムを実行するＣＰＵ、２０１、２０
２は利用者からの入力を受け付けるマウス、キ−ボ−
ド、２０３はプログラムの実行結果を画面に表示する表
示装置、２０４はプログラムの実行結果を紙面に打ち出
すプリンタ、２０５は、本発明のプログラムとデ−タを
一時的に記憶する主記憶装置、２０６は本発明のプログ
ラムとデ−タを記憶する外部記憶装置である。

【００２６】図１のフローチャートに基づいて本実施例
を説明する。システムは機能階層テーブルを読み込み
（１００）、機能階層を画面上に表示する（１０１）。
機能階層図の例を図３に示す。図３を表示するための機
能階層テーブルの例を図４に示す。機能階層テーブルは
図２の外部記憶装置２０６に記憶する。機能階層テーブ
ルのレコ−ド（４００）は、検索キ−である機能名（４
０１）と、階層的に管理するための上位機能名（４０
２）と下位機能名（４０３）からなる。機能階層の表示
においては、まず図４の４０１の機能名の欄の中から、
上位機能の無い機能を探す。上位機能の無い機能が見つ
かったら、その機能の下位機能を４０２の下位機能名の
欄から検索し、画面上に表示する。次に、検索した下位
機能を４０１の機能名の欄から検索し、同様に下位機能
を４０２の下位機能名の欄から検索する。これを順次繰
返し、機能階層図を表示する。

【００２７】機能階層図は、機能の汎化関係を表現して
いる。例えば、図形エディタのドメインを考えた時に、
画面上に表示された図形を移動する方法には、図形を選
択し移動メニューを選択してから移動先を選択して移動
する方法と、図形を選択しカットメニューを選択して図
形を一旦カットした後、ペーストメニューを選択してペ
ーストする方法と、図形を選択したままマウスを移動
し、マウスを離した位置に移動する方法の３通りがあ
る。この場合、移動機能をより詳細化した下位の機能と
して、移動メニューによる移動機能、カット＆ペースト
による移動機能、マウスだけで移動させる直接移動の３
通りの機能を位置付ける。従来の機能階層は、下位の機
能は上位の機能を実現するために、順に実行される機能
である。例えば、移動を移動メニューによる方法にした
場合に、図形を選択する機能、メニューを選択する機
能、移動先を選択する機能、図形を移動させる機能が、
移動機能の下位の機能になる。本発明で扱う機能の階層
は、機能をより詳しく説明するためのもので、従来の機
能階層とは異なる。

【００２８】図１に戻って説明する。利用者が新しいア
プリケーションで実現する機能を選択する。システム
は、選択した機能を読み込む（１０２）。利用者の入力
が’終了’でなければ（１０３）、選択された機能を記
憶する（１０４）。今、利用者は、移動機能と、移動機
能の詳細機能となるカット＆ペーストと、カット＆ペー
スト機能のさらに詳細な機能になるカット時にノードに
付随したアークを削除する機能を選択したとする。も
し’終了’ならば、図５の機能部品関連テーブルから利
用者が選択した機能に関連する部品を検索する（１０
５）。機能部品関連テーブルは、図２の外部記憶装置２
０６に記憶する。機能部品関連テーブルのレコ−ド（５
００）は、検索キ−である機能名（５０１）と、部品名
（５０２）との対応関係で表現される。

【００２９】最初に、どんな機能を選択しても必ず必要
となる部品を検索する。具体的には、図５の機能部品関
連テーブルの５０１の機能名の欄から、機能名の無い機
能を検索し、検索した機能に対応する部品を検索する。
ドメインが図形エディタの場合には、ノード部品、アー
ク部品、メニュー部品である。次に、移動機能に対応す
る部品を検索する。移動機能の場合は、グリッド部品に
対応付けられている。グリッド部品は、グリッドを表示
する役目と、ある座標が与えられた時に座標をグリッド
にあわせて補正する役目を果たす。グリッド部品は、移
動機能の詳細機能として、移動、カット＆ペースト、直
接移動のどの方式を選択しても必要な部品である。カッ
ト＆ペーストに対応する部品は、カット部品、マーカー
部品、クリップボード部品である。カット部品は、選択
された図形をカットする役目を果たす。マーカー部品
は、利用者が編集領域上で、マウスを選択した時に、選
択した位置にマーカーを表示する役目と、選択した位置
の座標を記憶し他の部品から問い合わせがあった時に座
標を教える役目を果たす。クリップボード部品は、カッ
トしたノードを記憶する役目と、記憶したノードをペー
ストする役目を果たす。ノードに付随したアークを削除
する機能に対しては、ノードに付随したアークを削除す
る部品が対応付けられている。

【００３０】検索された部品をまだ表示していなければ
（１０６）、検索した部品の名称を表示する（１０
７）。利用者が選択した機能全てに対して対応する部品
を表示したならば（１０８）、処理を終了する。選択し
た機能がまだ残っている場合には、処理１０５から再び
行う。これによって、利用者にとって判り易い機能階層
中の機能を選択するだけで、複数の部品が検索でき、大
規模な再利用が可能になる。

【００３１】部品が複数の小規模な部品群から構成され
ている場合がある。オブジェクト指向プログラミング言
語では、あるまとまったデータと、データに対する処理
をまとめて、クラスと呼ぶ。データに対する処理をメソ
ッドと呼ぶ。機能とメソッドを対応付け、選択した機能
に対応するメソッドだけを残してクラスを再構築するこ
とにより、クラスのサイズが小さくなる。機能とメソッ
ドの関連を管理する機能メソッド関連テーブルを図６に
示す。機能メソッド関連テーブルのレコ−ド（６００）
は、検索キ−である機能名（６０１）と、メソッド名
（６０２）との対応関係で表現される。メソッド名はメ
ソッドが属するクラス名を記述し、その後に’．’を記
述し、その後にメソッド名を記述することによって表現
する。

【００３２】次に、図７のフローチャートに基づいて利
用者の選択した機能が開発途中で変更になった場合に既
に開発したプログラムの中から影響を受ける部分を自動
的に特定する発明の実施例を説明する。変更前の機能に
おいて最初に呼びだされる部品名を、図３の機能部品関
連テーブルから検索する（７００）。機能に関連する部
品が複数存在する時は、図３の機能部品関連テーブルの
中で、最初に呼びだされる部品名を最初に記述すること
で識別する。検索した部品を部品が格納されている部品
ファイルから検索し、引き数の順序、型、リターンの型
など部品のインタフェースの情報を取得する（７０
１）。次に、変更後の機能において最初に呼びだされる
部品名と部品のインタフェースの情報を同様に取得する
（７０２、７０３）。他の部品は、最初の部品から順次
呼びだされるだけであり、アプリケーションに影響を与
えない。新たな機能で必要になる部品と置き換えるだけ
である。

【００３３】例えば、変更前の機能としてカット＆ペー
ストによる移動を選択していて、変更後の機能として移
動メニューによる移動を選択したとする。カット＆ペー
ストの機能において最初に呼びだされる部品は、カット
部品である。移動機能において最初に呼びだされる部品
は、移動部品である。

【００３４】検索した部品名が変更前と変更後で異なっ
ていたり（７０４）、取得した部品のインタフェースが
変更前と変更後で異なっている場合には（７０５）、既
に開発したソースプログラムから、変更前の機能におい
て最初に呼びだされる部品を呼び出している部分を取得
し（７０６）、取得した部分を表示する（７０７）。先
ほどの例では、部品名が異なっているので、カット部品
を呼び出している部分を検索する。影響範囲の表示の例
を図８に示す。

【００３５】次に、図９のフローチャートを使って、オ
ブジェクト指向の部品を管理する場合の、影響範囲を特
定する発明の実施例を説明する。変更前の機能において
最初に呼びだされるメソッド名を、図５の機能メソッド
関連テーブルから検索する（９００）。検索したメソッ
ドをメソッドが格納されているクラスファイルから検索
し、引き数の順序、型、リターンの型などメソッドのイ
ンタフェースの情報を取得する（９０１）。次に、変更
後の機能において最初に呼びだされるメソッド名とメソ
ッドのインタフェースの情報を同様に取得する（９０
２、９０３）。

【００３６】例えば、変更前の機能であるカット＆ペー
スト機能がノードクラスのカットのメソッドを最初に呼
出し、変更後の機能である移動メニューによる移動機能
がノードクラスの移動メソッドを最初に呼び出している
とする。

【００３７】検索したメソッドの属するクラスの名称が
変更前と変更後で異なっていたり（９０４）、検索した
メソッド名が変更前と変更後で異なっていたり（９０
５）、取得したメソッドのインタフェースが変更前と変
更後で異なっている場合には（９０６）、メソッドの属
するクラスのサブクラスの存在を検索する。先ほどの例
では、メソッド名が異なることになる。

【００３８】オブジェクト指向のクラス間には、図１０
に示す階層関係がある。スーパークラスが有するメソッ
ドはサブクラスにも引き継がれる。例えば、（ａ）はポ
ップアップメニュークラスとプルダウンメニュークラス
のスーパークラスとしてメニュークラスが存在すること
を示している。メニュークラスのメソッドとして、メニ
ューを表示する、選択されているメニューの項目を明示
するなどがある。これらのメソッドは、ポップアップメ
ニュークラスとプルダウンメニュークラスも有すること
になる。また、（ｂ）はノードとアークのスーパークラ
スとしてデータクラスが存在し、ノードのサブクラスと
して三角クラス、円クラスが存在することを示してい
る。データクラスが画面上に表示した図形を消去するメ
ソッドを有していれば、消去のメソッドはノード、アー
ク、三角、円のクラス全てに引き継がれる。ただし、デ
ータクラスが画面上に図形を表示するメソッドを有して
いても、ノード、アーク、三角、円クラスで表示メソッ
ドが再び定義されていれば、データクラスの表示メソッ
ドは継承されない。

【００３９】オブジェクト指向のプログラムでは、メソ
ッドは継承されるので、スーパークラスのメソッドが変
更になると、スーパークラスのメソッドを利用している
部分を変更するだけでなく、サブクラスのメソッドを利
用している部分も変更する必要がある。しかし、サブク
ラスにおいてメソッドが再定義されている場合には、そ
のサブクラスのメソッドを呼び出している部分を変更す
る必要は無い。

【００４０】フローチャートに戻って説明する。クラス
階層テーブルを読み込む（９０７）。クラス階層テーブ
ルの例を図１１に示す。クラス階層テーブルは、図２の
外部記憶装置２０６に記憶する。クラス階層テーブルの
レコ−ド（１１００）は、検索キ−であるクラス名（１
１０１）と、階層的に管理するための上位クラス名（１
１０２）と下位クラス名（１１０３）からなる。クラス
階層テーブルの中から変更前の機能で最初に呼びだされ
るメソッドが属するクラスの、サブクラスを検索する
（９０８）。サブクラスが存在する場合には（９０
９）、サブクラスのプログラムから、該メソッドが再定
義されているか否か調べる（９１０）。もし、再定義さ
れていれば、サブクラスを検索対象から外し、定義され
ていなければ、検索対象にいれる（９１１）。先ほどの
例では、ノードのサブクラスとして三角クラスと円クラ
スが存在し、どちらのクラスもカットメソッドを再定義
していないとすると、検索対象となるクラスは、ノー
ド、三角、円クラスとなる。

【００４１】全てのサブクラスを検索したら、既に開発
したソースプログラムから、検索対象となるクラスのメ
ソッドを呼び出している部分を取得し（９１２）、取得
した部分を表示する（９１３）。

【００４２】次に、図１２のフローチャートを使って、
ドメイン内のアプリケーションに汎用的に利用できる部
品と、ドメイン内のあるアプリケーションでしか利用で
きないサンプルの役目を果たす部品を、区別して表示す
る発明の実施例を説明する。本実施例は、オブジェクト
指向のクラスを管理するライブラリに適用した例で説明
する。始めに、クラスの階層テーブルを読み込む（１２
００）。クラスの階層テーブルの例を図１３に示す。図
１３のクラス階層テーブルは図１１のクラス階層テーブ
ルに、クラスが汎用的に利用できるクラスかサンプルの
クラスかを示す種別（１３００）を付加したものであ
る。次に、スーパークラスの無いクラスを検索する（１
２０１）。スーパークラスの無いクラスが存在しなけれ
ば（１２０２）、処理を終了する。存在すれば、スーパ
ークラスの無いクラスの名称を表示する（１２０３）。
次に検索したクラスのサブクラスを取得する（１２０
４）。サブクラスが存在しなければ（１２０５）、１２
０１から処理を繰り返す。例えば、スーパークラスの存
在しないクラスとして、データクラスを検索したとする
と、サブクラスとして、アーククラス、ノードクラスを
取得できる。

【００４３】次に、取得したサブクラスを検索する（１
２０６）。サブクラスがサンプルのクラスならば（１２
０７）、サンプルのクラスとして表示し（１２０８）、
そうでなければ、汎用的に利用できるクラスとして表示
する（１２０９）。ノードクラス、アーククラスともに
汎用的に利用できるクラスなので、汎用的に利用できる
クラスとして表示する。

【００４４】次に、サブクラスのサブクラスを表示する
処理を再帰的に行う（１２１０）。ノードクラスのサブ
クラスとして、円クラスと三角クラスが取得できるが、
これらのクラスはサンプルクラスなので、サンプルクラ
スとして表示する。表示結果を図１４に示す。

【００４５】これによって、新しいアプリケーションで
四角クラスを開発したい時には、三角クラスを参考にし
て開発すれば良く、従来に比べて早く開発できる。上記
実施例は、サブクラスがサンプルになっている例を示し
た。次の実施例は、あるクラスを呼び出すクラスがサン
プルになっている例を示す。図１５はクラス階層テーブ
ルであり、図１３のクラス階層テーブルに利用するクラ
ス（１５００）を追加したものである。表示する処理の
フローチャートは図１２とほぼ同一なので省略する。表
示結果を図１６に示す。

【００４６】次に、機能間の関係として上位機能と詳細
化した下位機能の関係だけでなく、各機能がドメイン内
のアプリケーションにとって必須か省略可能かを示す必
要度の情報と、複数の下位機能の内、１つしか選択でき
ないのか、複数選択できるのかを示す機能間の排他関係
の情報を有して、利用者が機能を選択する際に、必要度
と、機能間の排他関係を示し、利用者の仕様の決定を誘
導し、全ての機能を選択した際に、機能仕様書を自動的
に生成する発明の実施例を、図１７を使って説明する。

【００４７】始めに、機能階層テーブルを読み込む（１
７００）。機能階層テーブルの例を図１８に示す。図１
８の機能階層テーブルは、図４の機能階層テーブルに、
機能の必要度（１８００）と下位機能の排他関係（１８
０１）と関連する機能仕様書（１８０２）の情報を追加
したものである。次に上位機能がないの機能を検索する
（１７０１）。上位機能がない機能が存在する場合は
（１７０２）、検索した機能が必須機能か省略可能機能
かを調べ（１７０３）、必須機能ならば必須機能である
ことを表示し（１７０４）、省略可能機能ならば省略可
能機能であることを表示する（１７０５）。図１８の例
では、挿入機能、移動機能は必須機能になり、レイアウ
ト機能は省略可能機能になる。

【００４８】次に、下位機能を取得する（１７０６）。
下位機能が存在しないならば（１７０７）、１７０１か
ら処理を繰り返す。存在する時、下位機能が複数選択可
能であれば（１７０８）、複数選択可能であると表示し
（１７０９）、択一的ならば、択一的であると表示する
（１７１０）。下位機能について同様なことを再帰的に
繰り返す（１７１１）。上記を上位機能がない機能が存
在するまで繰り返す。表示した例を図１９に示す。

【００４９】次に利用者が選択した新しいアプリケーシ
ョンで実現する機能を読み込む（１７１２）。利用者の
入力が’終了’でなければ（１７１３）、選択された機
能に対応する機能仕様書を複写する（１７１４）する。
利用者が’終了’を入力したならば、複写した機能仕様
をマージし１冊の機能仕様書にする（１７１５）。これ
によって、新しいアプリケーションの機能仕様を設計す
る際に、利用者を誘導することができ、さらに、機能仕
様書を自動生成できる。択一的な機能、複数選択可能な
機能を選択する際に、複数の機能の比較を行った比較表
を利用者に示せば、さらに機能設計を支援できる。比較
表の例を図２０に示す。

【００５０】次に、部品ライブラリの中に、クラスのプ
ログラムだけでなく、クラスに関する様々な仕様書をク
ラスと対応付けて管理し、クラスの階層を定義するエデ
ィタを使って、クラスの階層構造を定義する際に、別な
ウィンドウに部品ライブラリ内のクラスを表示し、クラ
スのプログラム、仕様書の再利用を促進する発明の実施
例を、図２１のフローチャートを使用して説明する。

【００５１】図１１のクラス階層テーブルを読み込み
（２１００）、画面上に図１０のクラス階層図を表示す
る（２１０１）。利用者のクラスの選択を入力し（２１
０２）、選択したクラスに関連する仕様書やプログラム
を一式複写する（２１０３）。複写した仕様書やプログ
ラムは、前記エディタ内のクラスを指定することによっ
て、画面上に表示できる。表示画面の例を図２２に示
す。これによって、クラスのプログラムだけでなく、仕
様書一式が再利用可能である。さらに、プロジェクト毎
に利用する仕様書の種別を記憶しておき、クラスの仕様
書を複写する際に、プロジェクトで利用する仕様書の種
別に対応する仕様書のみを複写すると便利である。

【００５２】

【発明の効果】本発明によれば、ドメインごとにライブ
ラリを構築することにより、ライブラリ内の部品を、ド
メインに共通な機能に着目してまとめることができる。
利用者はドメインに共通する機能単位での、関連する部
品のプログラム、仕様書の再利用が可能になり、再利用
率が向上する。検索の鍵となる機能も体系付けられて利
用者に示されるため、目的とする部品が試行錯誤を繰り
返すこと無く検索できる。さらに、機能を選択すること
により、要求仕様を固めることができる。

【００５３】また、開発途中で利用者の要求する機能が
変更になった場合に、仕様変更による影響個所を自動的
に検出することができる。これによって、変更洩れを防
止するとともに、変更前に、仕様変更による影響度を類
推することが可能になる。また、サンプルとなる部品も
提供されるため、部品の利用方法が理解しやすい。サン
プルの部品を変形して新しいアプリケーションのための
プログラムを作成することもでき、早期開発が可能にな
る。

【００５４】

【図面の簡単な説明】

【図１】本発明の第１の実施例の処理手順を示すフロー
チャートである。

【図２】本実施例のハードウェア構成を示す図である。

【図３】本発明の第１の実施例で用いる機能階層図の一
例である。

【図４】本発明の第１の実施例で用いる機能階層テーブ
ルの一例である。

【図５】本発明の第１の実施例で用いる機能部品関連テ
ーブルの一例である。

【図６】本発明の第２の実施例で用いる機能メソッド関
連テーブルの一例である。

【図７】本発明の第３の実施例の処理手順を示すフロー
チャートである。

【図８】本発明の第３の実施例で用いる表示画面の一例
である。

【図９】本発明の第４の実施例の処理手順を示すフロー
チャートである。

【図１０】本発明の第４の実施例で用いるクラス階層図
の一例である。

【図１１】本発明の第４の実施例で用いるクラス階層テ
ーブルの一例である。

【図１２】本発明の第５の実施例の処理手順を示すフロ
ーチャートである。

【図１３】本発明の第５の実施例で用いるクラス階層テ
ーブルの一例である。

【図１４】本発明の第５の実施例で用いるクラス階層図
の一例である。

【図１５】本発明の第６の実施例で用いるクラス階層テ
ーブルの一例である。

【図１６】本発明の第６の実施例で用いるクラス階層図
の一例である。

【図１７】本発明の第７の実施例の処理手順を示すフロ
ーチャートである。

【図１８】本発明の第７の実施例で用いる機能階層テー
ブルの一例である。

【図１９】本発明の第７の実施例で用いる機能階層図の
一例である。

【図２０】本発明の第８の実施例で用いる機能比較表の
一例である。

【図２１】本発明の第９の実施例の処理手順を示すフロ
ーチャートである。

【図２２】本発明の第９の実施例で用いる表示画面の一
例である。

【図２３】本発明で用いる機能の汎化階層の一例であ
る。

【符号の説明】

２００：ＣＰＵ、２０１：マウス、２０２：キ−ボ−
ド、２０３：ＣＲＴ、２０４：プリンタ、２０５：主記
憶装置、２０６：外部記憶装置

Claims

【特許請求の範囲】

【請求項１】共通の機能を有するアプリケーションの集
合であるドメインの中で、再利用可能なソフトウェア部
品を管理するシステムにおいて、ドメイン内のアプリケ
ーションに共通する機能の汎化階層関係と、機能を実現
する部品と機能との対応関係を有し、新しいアプリケ−
ションを作成する際に、利用者に機能の汎化階層関係を
示し、新しいアプリケーションで必要となる機能を利用
者に指定させ、利用者が指定した機能に対応する部品を
検索することを特徴とするドメイン指向部品管理方法。
【請求項２】請求項１のシステムで、管理する部品がオ
ブジェクト指向プログラミング言語で記述されたクラス
であり、クラス間の汎化階層関係と、ドメイン内の機能
の汎化階層関係と、機能を実現するクラス内のメソッド
と機能との対応関係を有し、新しいアプリケ−ションを
作成する際に、利用者に機能の汎化階層関係を示し、新
しいアプリケーションで必要となる機能を利用者に指定
させ、利用者が指定した機能に対応するクラスとメソッ
ドを検索することを特徴とするドメイン指向部品管理方
法。
【請求項３】請求項１のシステムで、新しいアプリケー
ションの開発途中に、利用者の要求する機能が変更にな
った際に、変更前の機能において呼びだされる部品と、
変更後の機能において呼び出される部品とを比較し、部
品名が異なっていたり、部品のインタフェースが異なっ
ている場合に、変更前の機能において呼びだされる部品
を、機能を実現する部品と機能との対応関係から検索
し、該部品を呼び出している部分を、新しいアプリケー
ションから検索し、該検索された部分を、機能の変更に
おいて影響を受ける部分として表示することを特徴とす
るドメイン指向部品管理方法。
【請求項４】請求項２のシステムで、変更前の機能にお
いて呼びだされるメソッドと、変更後の機能において呼
び出されるメソッドとを比較し、変更前のメソッドの属
するクラスが異なっていたり、メソッド名が異なってい
たり、メソッドのインタフェースが異なっている場合
に、変更前の機能において呼びだされるメソッドが定義
されているクラスと、該メソッドを継承しているクラス
をクラスの階層構造から検索し、該メソッドを定義して
いるクラスと継承しているクラスの、該メソッドを呼び
出している部分を、新しいアプリケーションから検索
し、該検索された部分を、機能の変更において影響を受
ける部分として表示することを特徴とするドメイン指向
部品管理方法。
【請求項５】請求項１のシステムで、システム内の部品
毎に、該部品が、ドメイン内のアプリケーションに汎用
的に利用できるのか、ドメイン内のあるアプリケーショ
ンでしか利用できないサンプルの役目を果たすものなの
かを示す情報を有し、利用者に部品を表示する際に、区
別して表示することを特徴とするドメイン指向部品管理
方法。
【請求項６】請求項５のシステムで、サンプルの役目を
果たす部品が、汎用的に利用できる部品を利用する部品
であった時に、利用される部品と利用する部品の関連を
有し、利用者に部品を表示する際に、利用する側の部品
も表示することを特徴とするドメイン指向部品管理方
法。
【請求項７】請求項１のシステムで、各機能が該ドメイ
ン内のアプリケーションにとって必須か省略可能かを示
す必要度の情報と、ある機能を詳細化した複数の機能に
おいて、該複数機能の内、１つしか選択できないのか、
複数選択できるのかを示す機能間の排他関係の情報を有
し、利用者が機能を選択する際に、該必要度と、該排他
関係を示し、利用者の仕様の決定を誘導し、全ての機能
を選択した際に、機能仕様書を自動的に生成することを
特徴とするドメイン指向部品管理方法。
【請求項８】請求項７のシステムにおいて、上位機能が
等しい複数の機能の間の比較を行った比較表を有し、利
用者が複数の機能の内の１つを選択する際に、該比較表
を利用者に見せることで、利用者の機能の選択を支援す
ることを特徴とするドメイン指向部品管理方法。
【請求項９】請求項２のシステムにおいて、クラスのプ
ログラムだけでなく、クラスに関する様々な仕様書をク
ラスと対応付けて管理し、クラスの階層を定義するエデ
ィタを使って、クラスの階層構造を定義する際に、ドメ
イン指向部品管理方法内のクラスを画面上に表示し、画
面上で利用者の指定したライブラリ内のクラスを、該エ
ディタの画面上に転記するとともに、該クラスに関連す
るプログラムと仕様書を複写し、該エディタの中から利
用者が転記した該クラスを選択した際に、複写した該プ
ログラムと該仕様書を画面上に表示することを特徴とす
るドメイン指向部品管理方法。