JPH09152965A - クラスライブラリ再構築方法 - Google Patents

Abstract

(57)【要約】 【課題】 オブジェクト指向プログラムの修正を容易に
する。 【解決手段】 エディタよりメソッドの移動指令を受け
取ると(100)、移動元のクラスのプログラムを読み込み
(101)、移動元のクラスのプログラムから移動するメソ
ッドを検索する(102)。検索したメソッドを切り抜き(10
3)、切り抜いたメソッドの中のクラスの宣言部分を検索
し(104)、その部分を移動元のクラス名から移動先のク
ラス名に変更する(105)、変更後切り抜いたメソッドを
移動先のクラスのプログラムに貼り付ける(106)。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データとデータに
アクセスする関数を１つのクラスと見なし、クラスの集
合としてプログラムを組織化する、オブジェクト指向プ
ログラムの修正作業を容易にするのに有効なシステムに
関する。特に、オブジェクト指向の複数のプログラムを
ライブラリとして管理するクラスライブラリの修正作業
に有効なシステムに関する。

【０００２】

【従来の技術】Mark V Systems社のクラス間の階層構造
を定義するオブジェクト図エディタとオブジェクト図か
らプログラムのスケルトンを生成するObjectMakerに見
られるように、１つのクラスが有する属性やメソッドの
定義情報から、１つのクラスのプログラムのスケルトン
を生成していた。生成されるプログラムは、クラスを定
義したヘッダファイルと、メソッドのアルゴリズムを定
義した実装ファイルからなる。しかし、メソッドのアル
ゴリズムは、オブジェクト図の定義情報に記述されてお
らず、実装ファイルには、メソッドの外枠のみが生成さ
れる。

【０００３】従って、利用者が生成されたプログラムに
アルゴリズムの記述を追加する。その後、メソッドを追
加する必要が生じ、オブジェクト図において、クラスの
定義情報に新しいメソッドの定義情報を追加し、再度オ
ブジェクト図からプログラムを生成した場合には、既に
生成されたプログラムを解析して、既に記述されたメソ
ッドの部分は残し、新しく追加されたメソッドの宣言部
分のみが追加される。

【０００４】

【発明が解決しようとする課題】クラスライブラリを再
利用しながら、新しいシステムを構築する際に、クラス
ライブラリを修正することが度々発生する。修正とは、
親クラスと子クラスの間でメソッドを移動したり、親ク
ラスと子クラスを統合して１つのクラスにしたり、１つ
のクラスを親クラスと子クラスに分割することである。

【０００５】従来の技術では、１つのクラスの定義情報
から１つのクラスのプログラムを生成していたので、上
記のような修正を行った場合に、他のクラスから移動し
たメソッドのアルゴリズムの部分を自動的に生成するこ
とができなかった。

【０００６】本発明の目的は、オブジェクト指向プログ
ラムをライブラリとして管理するクラスライブラリの修
正作業を容易にするクラスライブラリ再構築方法を提供
することにある。

【０００７】

【課題を解決するための手段】本発明を実現するために
は、クラスライブラリのプログラム内のクラスの構造と
一致しているオブジェクト図の情報が必要である。オブ
ジェクト図の情報を得る手段は、３つある。１つは、プ
ログラムを解析して、オブジェクト図を生成する手段で
ある。もう１つは、オブジェクト図の情報からプログラ
ムを生成することで、プログラム内のクラスの構造とオ
ブジェクト図の情報を必ず一致させる手段である。もう
１つは、人手でプログラムからオブジェクト図の情報を
作り出す手段である。どの方法を採用しても、本発明を
適用できる。以後は、プログラムと一致しているオブジ
ェクト図の情報が存在するものとする。

【０００８】本発明のクラスライブラリ再構築方法で
は、オブジェクト図を編集するエディタにおいて、利用
者が属性／メソッドの移動／複写を行った際に、移動先
／移動元のプログラムの中から、移動した属性／メソッ
ドに該当する部分を、プログラムを構文解析することで
切り抜くかあるいは複写する。切り抜かれたメソッドの
中で、クラスの宣言部分を検索し、移動先／複写先のク
ラス名に置き換える。次に、移動先／複写先のクラスの
プログラムを構文解析し、移動先／複写先のクラスにお
ける移動／複写した属性／メソッドの位置に該当する部
分に属性／メソッドを挿入する。

【０００９】さらに、本発明では、オブジェクト図を編
集するエディタにおいて、利用者がクラスの分割を行っ
た際に、新しいクラスに存在しない属性／メソッドに該
当する部分をプログラムを構文解析することで削除す
る。その後、クラスの宣言部分を検索し、新しいクラス
名に置き換える。

【００１０】さらに、本発明では、オブジェクト図を編
集するエディタにおいて、利用者がある親クラスとある
子クラスの統合を行った際に、親クラスのメソッドが子
クラスで再定義されているか否かを検査し、再定義され
ていなければ、メソッドの移動の要領で、子クラスのプ
ログラムにメソッドを貼り付ける。もし、再定義されて
いれば、メソッドに別名を付ける。別名を付けたメソッ
ドが呼び出されている親クラス、子クラスの実装ファイ
ルの部分を検索し、新しい親クラスのメソッドの呼び出
しに置き換える。その後、クラスの宣言部分を検索し、
新しいクラス名に置き換える。

【００１１】さらに、本発明では、オブジェクト図を編
集するエディタにおいて、利用者がある親クラスＡと子
クラスＢの間に、新たにクラスＣを挿入し、クラスＣの
定義を行った際に、子クラスＢのヘッダファイル内を構
文解析することで、親クラスを宣言している部分を検出
し、クラスＡからクラスＣに置換する。さらに、オブジ
ェクト図上のクラスＣの情報とクラスＡの情報とを比べ
て、クラスＡのメソッドのうち、クラスＣで再定義され
ているメソッドを識別する。子クラスＢの実装ファイル
を構文解析することで、識別したメソッドを検索し、親
クラスＡのメソッドの呼出しをクラスＣのメソッドの呼
出しに変更する。

【００１２】オブジェクト図エディタにおいて、属性／
メソッドの移動／複写を行うと、該操作が行われたこと
を、プログラムを自動的に修正するシステムに連絡す
る。プログラムを自動的に修正するシステムでは、プロ
グラムを構文解析することで、属性／メソッドの宣言部
分や、メソッドのアルゴリズムの部分を切り出したり、
メソッドが宣言されていることをチェックする。

【００１３】本発明においては、移動／複写したメソッ
ドのアルゴリズムの記述の中で、メソッドの所属するク
ラスを宣言する部分を移動先／複写先のクラスに変更す
ることを、構文解析するステップと宣言部分を置換する
ステップで行う。

【００１４】クラスを分割する際に、分割したどちらか
一方のクラスに属するメソッドは本発明におけるメソッ
ドの移動処理で対処が可能である。しかし、分割後の両
方のクラスに属するメソッドについては、メソッドの中
の処理が、分割後の２つのクラスに分割される可能性が
ある。それ故、メソッドの中の処理を自動的に２つのク
ラスに分割することは、不可能である。よって、本発明
では、分割後の２つのクラスに、同じメソッドを複写
し、利用者がそれぞれのクラスにおいて不要になった処
理を削除することで、メソッドの中の処理の分割を行
う。クラスを分割する本発明においては、分割元のクラ
スのプログラムのファイルを複製し、分割後のクラスに
存在しないメソッドを削除することで達成できる。

【００１５】親クラスと子クラスを統合する際には、親
クラスのメソッドを子クラスのプログラムに移動するス
テップで対処が可能である。両方のクラスで定義されて
いるメソッドについては、親クラスのメソッドの名称を
変更する。統合後のプログラムにおいて、名称を変更し
た親クラスのメソッドを呼び出している部分があれば、
新しい名称のメソッドの呼出しに変更することで本発明
が達成できる。

【００１６】

【発明の実施の形態】以下、本発明の実施例を詳細に説
明する前に、オブジェクト指向で使用する用語について
説明する。オブジェクト指向のプログラムでは、クラス
がプログラムを組織する単位になる。クラスは、属性と
呼ばれるデータと、メソッドと呼ばれるプログラムで構
成されている。クラスは複数の属性と複数のメソッドを
有する。各メソッドはクラス内の属性の値を参照したり
更新したりする。

【００１７】クラスは階層的に構築される。階層上、上
位のクラスを親クラスと呼び、下位のクラスを子クラス
と呼ぶ。子クラスは、親クラスで定義したメソッドと同
じ名称のメソッドを定義することができる。このことを
メソッドの再定義と呼ぶ。クラス間の親子関係を継承と
呼ぶ。あるクラスが別のクラスを包含する関係にあると
き、クラス間の関係を集約と呼ぶ。

【００１８】クラスライブラリを利用する際には、クラ
スライブラリ内のクラスのメソッドを呼び出す。クラス
ライブラリ内のクラスのメソッドを、一部変更する必要
がある場合は、子クラスを定義し、親クラスの有するメ
ソッドを再定義する。この時、子クラスを定義してメソ
ッドを再定義するだけでは、目的とする機能をクラスラ
イブラリから得られないため、ライブラリ内のクラスを
分割する必要が生じることがある。本発明は、クラスの
分割や統合等、クラスライブラリを再構築する作業を、
容易にするとともに、上位の仕様書であるオブジェクト
図とプログラムの整合性を維持するための方法である。

【００１９】以下、本発明の実施例を詳細に説明する。
最初に第１の実施例を説明する。第１の実施例は、１つ
のクラスのメソッドを他のクラスに移動する作業を容易
にする。

【００２０】第１の実施例を実現するシステムのフロー
チャートを図１に示す。図２は本発明のハードウェア構
成図を示す。２００は本発明のプログラムを実行するＣ
ＰＵ、２０１は本発明で解析するプログラムを一時的に
記憶する主記憶装置、２０２は本発明のプログラムや解
析対象となるプログラムを記憶する外部記憶装置、２０
３はオブジェクト図エディタにおいて、修正指示を入力
する入力装置、２０４は本発明の出力結果を表示する表
示装置である。

【００２１】図３に示したオブジェクト図を、図４に示
したオブジェクト図に変更する操作を例にして説明す
る。図３は、図形エディタのためのオブジェクト図であ
り、300、301、302、303はクラスを表現し、それぞれ図
形、ノード、アーク、アーク名称のクラスを表現する。
１番上の段がクラス名であり、中断が属性、下段がメソ
ッドを表している。図形クラス(300)は、操作対象とな
る図形を画面に表示したり、画面から消去する役割を担
う。属性は有していない。図形クラスと、ノードクラ
ス、アーククラスは継承の関係にあり、アーククラスと
アーク名称クラスは集約の関係にある。

【００２２】ノードクラス(301)はネットワーク形状を
なす編集対象の図形における、ノードを操作する役割を
担う。図形エディタでは、ノードが消去されると、それ
に接続しているアークも自動的に消去される。これを実
現するために、ノードクラスは、自分自身に接続された
アークを記憶し、自分が消去する際に、接続しているア
ークに自分が消去することを通知する。ノードに対する
消去操作は、自分自身を画面から消去する以外のことを
行うので、図形クラス(300)が有する消去メソッドとは
異なる。このため、ノードクラス特有の消去メソッドを
再定義している。また、ノードは名称を有し、名称を変
更するためのメソッドを有する。さらに、幅や、高さを
変更するためのメソッドを有する。

【００２３】アーククラス(302)は、ノードからの消去
の通知を受信すると、自分自身を画面から消去すると共
に、消去されなかったもう一方のノードに自分自身が消
去されたことを通知する。アークが単独で消去される際
には、アークの両端のノードに自分自身が消去されたこ
とを通知する。アークが消去されたことを通知されたノ
ードは、接続してあるアークを記憶する接続アークリス
トからアークを消去する。アークが挿入された際には、
アークは両端のノードに接続依頼を送信し、それを受け
たノードは、接続アークリストにアークを追加する。

【００２４】アークには名称を付加することができる。
アークは残し、アークの名称だけ消去することもでき
る。アーク名称クラス(303)は、アークの名称が消去さ
れた時に、アークに自分自身が消去されたことを通知す
る。さらに、アークが消去された際に、アークから連絡
を受け、自分自身を消去することを行う。

【００２５】アークには名称が付加される種類と、付加
されない種類が存在する。名称が付加されないアークを
扱うために、図３において、アーククラスを、名称が付
加されないアーククラス(400)と、名称付きアーククラ
ス(401)に分割する。分割した結果を図４に示す。

【００２６】図３、図４は、オブジェクト図エディタを
利用することで作成できる。オブジェクト図エディタが
図３に示す情報を編集するために、ファイルに格納する
データを図１２に示す。各行の最初の４文字が、キーワ
ードとなる。例えば、CIDRはクラスの情報であることを
表現し、OBIDはクラス、継承などの図形要素の番号を表
わす。1200から1219までが図形クラスの情報であり、12
01は図形クラスの番号、1202、1203は図形クラスのＸ座
標、Ｙ座標、1204、1205は幅、高さを表す。1206は、メ
ソッドを記述する領域の高さを表す。1207、1208、1209
はそれぞれクラス名、属性名、メソッド名を表す。1210
から1219はノードクラスの情報、1220から1229はアーク
クラスの情報、1230から1239まではアーク名称クラスの
情報、1240から1254までは継承の情報、1255から1264ま
では集約の情報である。

【００２７】図３と図４を見比べると、300のアークク
ラスから401の名称付きアーククラスに、”アーク名
称”の属性と”アーク名称の消去受信”のメソッドが移
動されている。この例を使用して第１の実施例を、図１
のフローチャートに基づいて説明する。本発明を実現す
るにあたり、利用者が、入力装置を介して、表示装置の
画面上にクラス間の関係を定義するエディタが別システ
ムとして存在するとする。利用者が、新たにアーク名称
クラスを作成した後に、”アーク名称の消去受信”のメ
ソッドをアーククラスから、名称付きアーククラスに移
動すると、エディタは、本発明を実現するクラスライブ
ラリ再構築システムに対して、メソッドが移動されたこ
とを通知する。クラスライブラリ再構築システムは、エ
ディタよりメソッドの移動指令を受け取ると(100)、移
動元のクラスのプログラムを読み込む(101)。この場合
は、アーククラスのヘッダファイルと、実装ファイルで
ある。ヘッダファイルを図５に実装ファイルを図６にそ
れぞれ示す。

【００２８】ヘッダファイルは、クラスが有する属性／
メソッドを定義したファイルであり、505はクラス名”A
rc”とスーパークラス名”Figure”を定義している。50
7から509までは属性の定義であり、511から513まではメ
ソッドを定義している。実装ファイルは、メソッドの処
理内容を定義したファイルであり、図６の中には３つの
メソッドが定義されている。602から614までは”ノード
の消去受信”メソッド、616から621までは”アーク名称
の消去受信”メソッド、622から633までには”消去”メ
ソッドが定義されている。

【００２９】図１１に属性の移動指令とメソッドの移動
指令を示す。１１００は属性の移動指令であり、移動す
る属性名、移動元のクラス名、移動先のクラス名から構
成される。１１０１はメソッドの移動指令であり、移動
するメソッド名、移動元のクラス名、移動先のクラス名
から構成される。

【００３０】次に、プログラムから、移動するメソッド
に関連する部分を検索する(102)。ヘッダファイルにお
いて、移動するメソッドに関連する部分は、512のアー
ク名称の消去受信メソッドの宣言部である。実装ファイ
ルにおいて、移動するメソッドに関連する部分は、616
から620のアーク名称の消去受信メソッドの定義部であ
る。これらの部分をファイルから切り抜く(103)。切り
抜いたメソッドから、クラスの宣言部分を検索する(10
4)。本実施例では、図６の618のArcと記述された部分で
ある。この部分を新しいクラス名称であるArcWithName
に変更した後（１０５）、切り抜いたメソッドを移動先
のプログラムに貼り付ける（１０６）。

【００３１】第２の実施例では、属性の移動を容易にす
る。属性”アーク名称”をアーククラスから、名称付き
アーククラスに移動すると、エディタは、クラスライブ
ラリ再構築システムに対して、属性が移動されたことを
通知する。クラスライブラリ再構築システムは、メソッ
ドの移動の時と同様に、図５のヘッダファイルから属
性”アーク名称”に関連する部分507を切り抜き、名称
付きアーククラスのヘッダファイルに貼付ける。

【００３２】第１及び第２の実施例の結果、アーククラ
スのヘッダファイル、実装ファイルは図７、図９のよう
になり、”アーク名称の消去通知”メソッド、”アーク
名称”属性に関連する部分が切り抜かれている。貼り付
けた結果である名称付きアーククラスのヘッダファイ
ル、実装ファイルは、図８、図１０のようになる。図８
のヘッダファイルには、属性としてアーク名称が宣言さ
れ、メソッドとして”アーク名称の消去受信”と”消
去”が宣言されている。メソッド”消去”は、アークク
ラスから複写されたメソッドである。

【００３３】次に、属性／メソッドの複写を可能にする
第３の実施例について説明する。アーク名称の消去受信
メソッドは、メソッド全てが分割後のクラスに移動され
る例だが、クラスの分割に伴い、メソッド”消去”のよ
うにメソッドの中を２つに分割する場合もある。これを
自動的に行うのは、困難である。そこで、メソッドを複
写し、複写されたメソッドを人手によって修正する。第
３の実施例のフローチャートは、図１とほとんど同じで
あり、複写元のメソッドを削除しない点だけが異なる。
図６のアークの消去メソッドでは、629においてアーク
名称に消去の通知を送信しているが、図９のアークの消
去メソッドでは消去の通知を送信していない。図１０の
名称付きアーククラスの消去メソッドでは、アーク名称
に消去の通知を送信している部分が残り、他の部分が削
除されるか、あるいは変更されている。これらの変更
は、メソッドの複写後人手によって行なわれる。

【００３４】上記のようなクラスの分割を簡潔に行うの
が第４の実施例である。第４の実施例のフローチャート
を図１３に示す。エディタよりクラスの分割指令を読み
込むと(1300)、分割元のクラスのプログラムを複写し、
複写したファイルに新たに作成したクラス名に基づいて
命名する(1301)。本実施例では、ArcWithName.CとArcWi
thName.hのファイルが作成される。次に、分割元となっ
たアーククラスのプログラムを読み込み(1302)、メソッ
ドを検索する(1303)。最初に検索されるメソッドは、”
ノードの消去受信”のメソッドである。検索したメソッ
ドが分割後のクラスに存在するか否か、オブジェクト図
を調べ(1305)、もし検索したメソッドが存在しなけれ
ば、メソッドを分割後のプログラムから削除する(130
6)。ノードの消去受信メソッドは存在するので、次のメ
ソッドを検索する(1303)。次のアーク名称の消去メソッ
ドが存在しなければ、ア−ク名称を削除する。消去メソ
ッドが存在すれば、ア−ク名称を残す。これをプログラ
ムの最後まで繰り返す(1304)。同様の操作を複写したプ
ログラムについても行う(1307〜1311)。名称付きアーク
クラスでは、ノードの消去受信メソッドが削除される。

【００３５】次に、クラスを統合する第５の実施例につ
いて説明する。図４のオブジェクト図を図３のオブジェ
クト図に対する操作を例に、図１４のフローチャートを
用いて説明する。エディタよりクラスの統合指令を受け
取ると(1400)、親クラスのプログラムを読み込み(140
1)、メソッドを検索する(1402)。検索したメソッドが子
クラスに存在しないならば(1404)、検索したメソッドを
子クラスのプログラムに貼り付ける(1405)。本実施例で
は、図９に示した”Arc.C”の実装ファイルが読み込ま
れ、中に書かれたノードの消去受信メソッドと消去メソ
ッドが検索され、それぞれのメソッドが子クラスであ
る”名称付きアーククラス”に定義されているかがチェ
ックされる。ノード消去受信メソッドは存在しないの
で、そのまま図１０に示した子クラスの実装ファイルで
ある”ArcWithName.C”に貼り付けられる。ノ−ド消去
受信メソッドが存在する場合は、メソッドの名称に親ク
ラス名を付加し、メソッドの名称を変更する(1406)。消
去メソッドは存在するので、メソッドの名称が”Clea
r”から”ClearArc”に変更される。変更したメソッド
が子クラスのプログラム内で呼び出されていないかチェ
ックし(1407)、呼び出されていればその部分を新しいメ
ソッド名に変換する(1408)。図１０の625の部分は、”C
lear”メソッドを呼び出している部分なので変更され
る。同様に親クラスの別のメソッドでも呼び出されてい
ないかチェックし(1409)、呼び出されていればその部分
を新しいメソッド名に変換する(1410)。図９の例では、
親クラスで変更したメソッドを呼び出している部分は存
在しない。統合した実装ファイルの例を図１５に示す。

【００３６】さらに、クラス階層木の途中にクラスを挿
入した際に、挿入したクラスの子クラスに修正が発生す
る。第６の実施例は子クラスの修正を自動的に行うもの
である。第１の実施例で使用したオブジェクト図上でア
ーククラスの子クラスに、関連クラスが定義されている
とする。オブジェクト図を図１６に示す。関連クラスに
は、アーク名称以外に役割名称が付加されている。”関
連”が削除されたときには、”役割名”も削除されなけ
ればならない。この時、アーククラスを分割し、アーク
クラスと名称付きアーククラスに分割すると、今まで、
アーククラスの子クラスだった関連クラスも修正の必要
が生じる。これは、クラスを分割した例であるが、単に
クラスを挿入した際にも同様な修正が発生する。修正後
のオブジェクト図を図１７に示す。

【００３７】第６の実施例のフローチャートを図１８に
示す。エディタよりクラスの挿入指令を受け取ると(180
0)、挿入した子クラスの実装ファイルを読み込み(180
1)、元の親クラスのメソッドを呼び出している部分を検
索する(1802)。この場合、読み込むプログラムは、関連
クラスの実装プログラムであり、検索する部分は、アー
ククラスのメソッドを呼び出している部分である。次
に、検索したメソッドが新たに挿入したクラスで再定義
されているかを調査し(1804)、されていれば、メソッド
の呼び出しを、元の親クラスの呼び出しから、新たに挿
入したクラスの呼び出しに変更する(1805)。関連クラス
の実装ファイルの例を図２０に示す。変更した関連クラ
スの実装ファイルの例を図２２に示す。図２０における
2012は親クラスのメソッドの呼び出しであり、この部分
が図２２では変更されて2200になる。関連クラスの実装
ファイルの検索が終了すると(1803)、次に、ヘッダファ
イルを読み込み(1806)、親クラスの宣言部分を検索し(1
807)、その部分を挿入したクラス名に変更する(1808)。
関連クラスのヘッダファイルの例を図１９に示す。変更
した関連クラスのヘッダファイルの例を図２１に示す。
図１９における1902は親クラスの宣言であり”Arc”に
なっている。この部分が図２１では変更されて2100にな
り、"ArcWithName”になる。

【００３８】クラス階層木の途中のクラスを削除した際
に、削除したクラスの子クラスに修正が発生する。第７
の実施例は子クラスの修正を自動的に行うものである。
第６の実施例とは逆に、図１７のオブジェクト図を図１
６のように変更すると、名称付きアーククラスの子クラ
スだった関連クラスも修正の必要が生じる。これは、ク
ラスを統合した例であるが、単にクラスを削除した際に
も同様な修正が発生する。フローチャートは図１８とほ
とんど同じであり、関連クラスから呼び出されている名
称付きアーククラスのメソッド名が、アーククラスのメ
ソッドの呼出しに変更される。

【００３９】

【発明の効果】本発明では、クラス間の関連を表現した
オブジェクト図を編集するエディタと連動して、ソース
プログラムを修正する。テキストエディタによる煩わし
いプログラムの修正作業が不要となるので、修正作業が
楽になり、修正誤りも削減できる。

【００４０】さらに、オブジェクト図の修正結果がプロ
グラムに反映されるので、仕様書とプログラムの間の不
整合が削減できる。

【図面の簡単な説明】

【図１】本発明の第１の実施例のフローチャート。

【図２】本発明のハードウェア構成図。

【図３】本発明の第１の実施例で用いる修正前のオブジ
ェクト図。

【図４】本発明の第１の実施例で用いる修正後のオブジ
ェクト図。

【図５】本発明の第１の実施例で用いる”アーク”クラ
スのヘッダファイル。

【図６】本発明の第１の実施例で用いる”アーク”クラ
スの実装ファイル。

【図７】本発明の第１の実施例で用いる変更後の”アー
ク”クラスのヘッダファイル。

【図８】本発明の第１の実施例で用いる”名称付きアー
ク”クラスのヘッダファイル。

【図９】本発明の第１の実施例で用いる変更後の”アー
ク”クラスの実装ファイル。

【図１０】本発明の第１の実施例で用いる”名称付きア
ーク”クラスの実装ファイル。

【図１１】本発明の第１の実施例で用いる、属性／メソ
ッドの移動指令

【図１２】本発明の第１の実施例で用いる修正前のオブ
ジェクト図のファイル形式。

【図１３】本発明の第４の実施例のフローチャート。

【図１４】本発明の第５の実施例のフローチャート。

【図１５】本発明の第５の実施例で用いる変更後の”ア
ーク”クラスの実装ファイル。

【図１６】本発明の第６の実施例で用いるオブジェクト
図。

【図１７】本発明の第６の実施例で用いる修正後のオブ
ジェクト図。

【図１８】本発明の第５の実施例のフローチャート。

【図１９】本発明の第５の実施例で用いる”関連”クラ
スのヘッダファイル。

【図２０】本発明の第５の実施例で用いる”関連”クラ
スの実装ファイル。

【図２１】本発明の第５の実施例で用いる変更後の”関
連”クラスのヘッダファイル。

【図２２】本発明の第５の実施例で用いる変更後の”関
連”クラスの実装ファイル。

【符号の説明】

１００……メソッドの修正指示の受信処理、１０１……
移動元のクラスのプログラムの読み込み処理、１０２…
…移動するメソッドの検索処理、１０３……メソッドの
切り抜き処理、１０４……切り抜いたメソッドからクラ
スの宣言を検索する処理、１０５……クラスの宣言部分
を移動元のクラス名から移動先のクラス名に変更する処
理、１０６……切り抜いたメソッドを貼り付ける処理。

Claims (7)

【特許請求の範囲】
1. 【請求項１】計算機を用いて、オブジェクト指向プログ
   ラム言語で記述されたプログラムを管理する際に、 プログラム中のクラスの有する属性とメソッド、クラス
   間の階層関係を示すオブジェクト図を表示装置に表示
   し、 前記表示装置の画面上で利用者が入力装置を用いてある
   クラスの有するメソッドを別のクラスに移動し、 移動元のクラスの該メソッドに該当するプログラム断片
   を抽出し、 該プログラム断片中のクラスの宣言部分を移動元のクラ
   ス名から移動先のクラス名に変更し、 移動先のクラスのプログラムに前記プログラム断片を貼
   り付けることを特徴とするクラスライブラリ再構築方
   法。
2. 【請求項２】前記オブジェクト図上で利用者が前記入力
   装置を用いてあるクラスの有する属性を別のクラスに移
   動し、 移動元のクラスの該属性の宣言に該当するプログラム断
   片を抽出し、 移動先のクラスのプログラムに前記プログラム断片を貼
   り付けることを特徴とする請求項１記載のクラスライブ
   ラリ再構築方法。
3. 【請求項３】前記オブジェクト図上で利用者が前記入力
   装置を用いてあるクラスの有する属性／メソッドを別の
   クラスに複写し、 複写元のクラスの該属性／メソッドに該当するプログラ
   ム断片を別のクラスに複写し、 該プログラム断片中のクラスの宣言部分を移動元のクラ
   ス名から移動先のクラス名に変更し、 複写先のクラスのプログラムに前記プログラム断片を貼
   り付けることを特徴とする請求項１、及び２記載のクラ
   スライブラリ再構築方法。
4. 【請求項４】前記オブジェクト図上で利用者が前記入力
   装置を用いてあるクラスを親クラスと子クラスに分割
   し、 該クラスが有する属性／メソッドを移動、又は複写によ
   って親クラスに属するものと子クラスに属するものに振
   り分け、 元のクラスのプログラムを別のクラスに複写し、 親クラス、及び子クラスのプログラムに対して、各クラ
   スで存在しない属性／メソッドに該当するプログラム断
   片を削除することを特徴とする請求項１記載のクラスラ
   イブラリ再構築方法。
5. 【請求項５】前記オブジェクト図上で利用者が前記入力
   装置を用いてある親クラスと子クラスを統合し、 該親クラスのメソッドの内、該子クラスで再定義されて
   いないメソッドについては、該当するプログラム断片を
   切り抜き、 該子クラスのプログラムに貼り付けられ、該子クラスで
   再定義されているメソッドについては、別名を付け、 該メソッドが呼ばれていないかを検査し、 前記メソッドが呼ばれている場合には、該メソッドの呼
   出しを新しくつけた名称のメソッドの呼出しに変更した
   後、該子クラスのプログラム断片中のクラスの宣言部分
   を統合後のクラス名に変更し、 親クラスのプログラムのファイルを削除することを特徴
   とする請求項１記載のクラスライブラリ再構築方法。
6. 【請求項６】前記オブジェクト図上で利用者が前記入力
   装置を用いてある親クラスＡと子クラスＢの間に、新た
   にクラスＣを挿入して、クラスＣを定義し、 子クラスＢ内で親クラスを宣言している部分をクラスＡ
   からクラスＣに変更し、 子クラスＢから呼び出されて
   いる親クラスＡのメソッドが、クラスＣで再定義された
   場合には、子クラスＢにおける親クラスＡのメソッドの
   呼出しをクラスＣのメソッドの呼出しに変更することを
   特徴とする請求項１記載のクラスライブラリ再構築方
   法。
7. 【請求項７】前記オブジェクト図上で利用者が前記入力
   装置を用いてある親クラスＡと孫クラスＢとの間の子ク
   ラスＣを削除し、 子クラスＢ内で親クラスを宣言している部分をクラスＣ
   からクラスＡに変更し、 子クラスＢから呼び出されて
   いるクラスＣのメソッドが、クラスＡで定義されている
   場合には、子クラスＢにおけるクラスＣのメソッドの呼
   出しをクラスＡのメソッドの呼出しに変更することを特
   徴とする請求項１記載のクラスライブラリ再構築方法。