JP2001282537A

JP2001282537A - 抽象クラスの自動生成方法および装置

Info

Publication number: JP2001282537A
Application number: JP2000094923A
Authority: JP
Inventors: Norikazu Kijima; 教和木島
Original assignee: Hitachi Software Engineering Co Ltd
Current assignee: Hitachi Software Engineering Co Ltd
Priority date: 2000-03-30
Filing date: 2000-03-30
Publication date: 2001-10-12

Abstract

(57)【要約】【課題】クラスの再利用性、可読性（分かり易さ、理
解のし易さ）を高めることが可能なクラス間の関連に基
づいた抽象クラスの自動生成方法および装置を提供する
こと。【解決手段】任意の業務システムを構成するクラス群
の中の各クラスのメソッド内で呼ばれる他クラスのメソ
ッドを取得するステップと、複数の他クラスに対する自
クラスのインタフェースクラスを生成するステップと、
複数の他クラスに対する自クラスのそれぞれのインタフ
ェースクラスを継承した１つのインタフェースクラスを
生成するステップとを含む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、オブジェクト指向
技術を用いたソフトウェア開発においてクラス間の関連
に基づいた抽象クラスを自動生成する方法および装置に
に関するものである。

【０００２】

【従来の技術】オブジェクト指向のソフトウェア開発に
おいて、抽象クラスを作成する場合、主に２つの役割に
基づいて作成する。ここで、抽象クラスとは、直接のイ
ンスタンスを持たないクラスのことである。１つ目は同
一業務の別システムを作成していくにつれ、同じような
役割のクラスの同じメソッドや属性を見つけ出すことに
よって共通の属性、メソッドを抽象クラスにすること。
２つ目はクラス間の関連からインタフェースクラス(純
粋仮想関数しか持たない抽象クラス)を作成し、クラス
間の役割を明確にすること。

【０００３】上記の１つ目の抽象化を行う技術は、例え
ば特開平８−１６６８７３号公報に記載の技術が知られ
ている。上記の２つ目におけるクラス間の関連をインタ
フェースクラス化するものは未だないが、クラス間の関
連を理解し易くするものとして、特開平９−３４７０６
号公報に記載の技術や特開平１０−３０１７６７号公報
に記載の技術が知られている。

【０００４】特開平８−１６６８７３号公報に記載の技
術は、例えば、オブジェクト指向により開発されたシス
テムのクラス群を解析し、クラスの属性やメソッドの型
や引数の情報を他のクラスと比較することによって、再
利用可能な最適な抽象クラスを抽出するものである。

【０００５】特開平９−３４７０６号公報に記載の技術
は例えば、クラス図においてクラス間の関連を基底クラ
スのもののみ表示する機能と、全ての関連を表示する機
能を有したものである。

【０００６】特開平１０−３０１７６７号公報に記載の
技術は、例えばオブジェクト指向により開発されたシス
テムのクラス群を解析し、クラス間の関連を抽出するこ
とによって、関数本体を呼び出したソースを表示する機
能と、関数本体が呼び出す関数を順にツリー表示する機
能を有したものである。

【０００７】

【発明が解決しようとする課題】ところで、オブジェク
ト指向技術によるソフトウェア開発において、インタフ
ェースクラスを抽出すると、以下の利点がある。（１）インタフェースクラスを作成することにより、各
クラスの役割が明確になり、インタフェースクラスの関
連のみで１つの業務システムを表すことが出来る。この
結果、業務システムを関連のみを使用したモデルで表す
ことができる。(２）さらにこれらのインタフェースク
ラスのメソッドを実装するのに最小限の属性とメソッド
を実装したクラスは、業務で最低限必要とされるメソッ
ドを実装したクラスであり、１つの業務システムを表す
業務フレームワークとなる。

【０００８】しかしながら、上記従来の技術の２つ目に
示した抽象化技術にあっては、クラス間の関連を表示す
る機能や抽出する機能を備えているが、クラス間の関連
をインタフェースクラス(純粋仮想関数しか持たない抽
象クラス)として抽象化することはできない。

【０００９】本発明は、上記従来の問題点を解決し、ク
ラスの再利用性、可読性(分かり易さ、理解のし易さ）
を高めることが可能なクラス間の関連に基づいた抽象ク
ラスの自動生成方法および装置を提供することを目的と
する。

【００１０】

【課題を解決するための手段】上記の目的を達成するた
めに、本発明の抽象クラスの自動生成方法は、任意の業
務システムを構成するクラス群の中の各クラスのメソッ
ド内で呼ばれる他クラスのメソッドを取得するステップ
と、複数の他クラスに対する自クラスのインタフェース
クラスを生成するステップと、複数の他クラスに対する
自クラスのそれぞれのインタフェースクラスを継承した
１つのインタフェースクラスを生成するステップとを含
むことを特徴とする。

【００１１】また、前記任意の業務システムを構成する
クラス群の中の各クラスの属性、メソッド、メソッド内
で呼ばれる他クラスのメソッド、メソッド内で呼ばれる
自クラス内のメソッド、メソッド内で呼ばれる自クラス
内の属性を取得するステップと、前記１つのインタフェ
ースクラスのメソッドを実装するのに最小限の属性とメ
ソッドを持つ抽象クラスを作成するステップとを含むこ
とを特徴とする。

【００１２】また、前記１つのインタフェースクラスの
クラス図を生成するステップを含むことを特徴とする。
また、前記１つの抽象クラスのクラス図を生成するステ
ップを含むことを特徴とする。また、前記１つのインタ
フェースクラスのソースコードを生成するステップを含
むことを特徴とする。また、前記１つの抽象クラスのソ
ースコードを生成するステップを含むことを特徴とす
る。

【００１３】さらに、本発明の抽象クラス自動生成装置
は、任意の業務システムを構成するクラス群の中の各ク
ラスのメソッド内で呼ばれる他クラスのメソッドを取得
する手段と、複数の他クラスに対する自クラスのインタ
フェースクラスを生成する手段と、複数の他クラスに対
する自クラスのそれぞれのインタフェースクラスを継承
した１つのインタフェースクラスを生成する手段とを備
えることを特徴とする。

【００１４】また、前記任意の業務システムを構成する
クラス群の中の各クラスの属性、メソッド、メソッド内
で呼ばれる他クラスのメソッド、メソッド内で呼ばれる
自クラス内のメソッド、メソッド内で呼ばれる自クラス
内の属性を取得する手段と、前記１つのインタフェース
クラスのメソッドを実装するのに最小限の属性とメソッ
ドを持つ抽象クラスを作成する手段とを備えることを特
徴とする。

【００１５】

【発明の実施の形態】以下、図面を参照しながら本発明
の実施例を説明する。

【００１６】図１は、本発明によるクラス間の関連に基
づいた抽象クラス自動生成システムの一実施形態を示す
システム構成図である。

【００１７】ここで示す抽象クラス自動生成システム
は、プログラムのソースコード１１１からクラス情報
(クラスの属性、メソッド、メソッド内で呼ばれる他ク
ラスのメソッド、メソッド内で呼ばれる自クラス内のメ
ソッド、メソッド内で呼ばれる自クラス内の属性）を抽
出するソースコード解析装置１１２と、クラス図１２１
からクラス情報（クラスの属性、メソッド、メソッド内
で呼ばれる他クラスのメソッド、メソッド内で呼ばれる
自クラス内のメソッド、メソッド内で呼ばれる自クラス
内の属性）を抽出するクラス図解析装置１２２とを備え
ている。

【００１８】さらに、これらの解析装置１１２および１
２２の解析結果の情報からクラス情報を抽出するクラス
情報抽出装置１９１と、抽出されたクラス情報に基づ
き、任意の業務システムを構成するクラス群のクラス間
関連に基づいた抽象クラス化を行い、この抽象クラス化
によって生成されたインタフェースクラス、抽象クラ
ス、具象クラスから成るソースコード１１３、同じくイ
ンタフェースクラス、抽象クラス、具象クラスからなる
クラス図１２３を生成する抽象クラス自動生成装置１９
２から構成される。

【００１９】以下、図２〜図１２を参照しながら任意の
業務システムを構成するクラス群のインタフェースクラ
ス化と抽象クラス化について説明する。以下では、業務
システムの具体例として保険契約システムで使用される
「顧客クラス」と言うクラスの抽象化を行う場合を例に
挙げて説明する。

【００２０】図２は、保険契約システムで使用される
「顧客クラス」の具体例を示すクラス図である。この例
のクラス図は、顧客クラス２２０を集約している会社ク
ラス２１０と、顧客クラス２２０と関連を持つ保険料ク
ラス２３０で構成されている。会社クラス２１０のメソ
ッド内では顧客クラス２２０のメソッドであるgetI
D()、getName()、getCode()のみが呼ばれる。保険料ク
ラス２３０のメソッド内では顧客クラスのメソッドであ
るgetID()、getRestLife()のみが呼ばれる。

【００２１】顧客クラス２２０は、属性であるid、nam
e、birthday、sexとメソッドであるgetID()、getNam
e()、getAge()、getSex()、dump()、getCode()、getRes
tLife()を持っている。なお、クラスの表記にはＵＭＬ
表記法を使用し、属性およびメソッドの前の符号は属性
およびメソッドの修飾子を表しており、それぞれの修飾
子は、「＋」が「public」、「＃」が「protected」、
「−」が「private」を表すものである。

【００２２】図３は、顧客クラス２２０の抽象化の全過
程を示すフローチャートである。ここで示す抽象化プロ
セスでは、まず、図５のようなクラス図を取得し(ステ
ップ３０１）、顧客クラス２２０の第１段階の抽象クラ
ス化を行い、第１段階の抽象クラス化の結果のクラス図
を作成する(ステップ３０２）。この後、第１段階の抽
象クラス化の結果のクラス図から顧客クラス２２０の第
２段階の抽象クラス化を行い、第２段階の抽象クラス化
の結果のクラス図を作成する(ステップ３０３，３０
４）。次に、第２段階の抽象クラス化の結果のクラス図
から顧客クラス２２０の第３段階の抽象クラス化を行
い、第３段階の抽象クラス化の結果のクラス図を作成す
る(ステップ３０５，３０６，３０７）。

【００２３】第２段階目の抽象クラス化により、顧客ク
ラス２２０のインタフェースクラスが生成される。第３
段階目の抽象クラス化により、顧客クラス２２０の抽象
クラスが生成される。この第３段階目の抽象クラス化処
理では、抽象クラスで定義される属性かの判断処理(ス
テップ３０８）が行われ、さらにその結果によって抽象
クラスで実装されるメソッドかの判断処理(ステップ３
０９）が行われる。

【００２４】第１段階目の抽象クラス化の処理手順を図
４に示し、第２段階目の抽象クラス化の処理手順を図６
に示し、第３段階目の抽象クラス化の処理手順を図８に
示す。そして、第１段階目の抽象クラス化によって生成
されたクラス図を図５に示し、第２段階目の抽象クラス
化によって生成されたクラス図を図７に示し、第３段階
目の抽象クラス化によって生成されたクラス図を図９に
示している。また、ステップ３０８の処理の詳細を図１
０に、ステップ３０９の処理の詳細を図１１にそれぞれ
示す。

【００２５】最初に、図４及び図５を参照して第１段階
目の抽象クラス化の詳細について説明する。

【００２６】第１段階目の抽象クラス化では、クラスの
役割を明確にするため、各クラス間でそれぞれ使用され
ているメソッドを調べ、インタフェースクラスを生成す
る。すなわち、各クラス間でそれぞれ使用されているメ
ソッドに基づいてクラスをインタフェースクラス化す
る。ただし、クラスライブラリのようにあらかじめ作成
されているクラスに対しては行わない。例えば、図５が
図２の顧客クラス２２０の抽象化を進めた場合の結果を
示すクラス図である。図５のクラス図に対して順に図４
の処理を適用していったといても、顧客クラス２２０
(図４ではクラスＸ）が関連を持っているクラスは未だ
存在するので、ステップ４００の処理はtrueとなる。顧
客クラス２２０が集約されている会社クラス２１０(図
４ではクラスＹ）で使用しているメソッドがあるか否か
を調べ(ステップ４０１）、ある場合には、さらに顧客
クラス２２０のどのメソッドが使用されているかを読み
込む(ステップ４０２)。図２の例の会社クラス２１０の
メソッド内では、顧客クラス２２０のメソッドであるge
tID()、getName()、getCode()のみを呼んでいる。この
ように会社クラス２１０は、顧客クラス２２０のすべて
のメソッドを呼んではおらず、特定のメソッドだけを使
用している。そこで、会社クラス２１０で使用している
顧客クラス２２０のメソッドgetID()、getName()、getC
ode()のみを定義している顧客クラス２２０の会社クラ
ス２１０へのインタフェースクラス５１２(図４ではク
ラスＺ）を生成する(ステップ４０３)。

【００２７】顧客クラス２２０は、当該顧客クラス２２
０の会社クラス２１０へのインターフェース５１２を継
承する(ステップ４０４)。会社クラス２１０は顧客クラ
ス２２０の会社クラス２１０へのインターフェース５１
２を集約する(ステップ４０５)。すなわち、ステップ４
０５では、顧客クラス２２０の会社クラス２１０への集
約関係、関連をそれぞれインタフェースクラス５１２へ
の集約関係および関連に変更する。

【００２８】この後、ステップ４００に戻って、顧客ク
ラス２２が関係を持っているクラスがあるか否を判断す
る。図２の例のクラス図では、顧客クラス２２０は保険
料クラス２３０とも関係を持っている。このため、ステ
ップ４００の判断結果はtrueとなり、ステップ４０１以
降の処理に進む。

【００２９】このステップ４０１以降の処理において
は、顧客クラス２２０の保険料クラスへ２３０のインタ
フェースクラス５２２も同様にして作成される。すなわ
ち、顧客クラス２２０が関連を持っている保険料クラス
２３０で顧客クラス２２０のどのメソッドが使用されて
いるかを読み込む(ステップ４０２)。保険料クラス２３
０のメソッド内では顧客クラス２２０のメソッドgetI
D()、getRestLife()のみが呼ばれている。そこで、getI
D()、getRestLife()のみを定義した顧客クラス２２０の
保険料クラス２３０へのインタフェースクラス５２２を
生成する(ステップ４０３)。

【００３０】これにより、顧客クラス２２０は顧客クラ
ス２２０の保険料クラス２３０へのインタフェースクラ
ス５２２を継承する(ステップ４０４)。保険料クラス２
３０は顧客クラス２２０の保険料クラス２３０へのイン
タフェースクラス５２２へ関連を持つものとなる(ステ
ップ４０５)。すなわち、ステップ４０５では、顧客ク
ラス２２０の保険料クラス２３０への集約関係、関連を
それぞれインタフェースクラス５２２への集約関係およ
び関連に変更する。

【００３１】図２の例では、顧客クラス２２０が関連を
持っているクラスはもう存在しないのでステップ２００
の判断結果はfalseとなる。そこで、全てのクラスに着
目したか否かを調べる(ステップ４０６）。しかし、図
２の例では、未だ全てのクラスに着目していないので、
ステップ４０６の処理はfalseとなる。そこで、再度ス
テップ４００に戻って同様の処理を行う。

【００３２】図２の例では、会社クラス２１０に注目
し、これに関係を持っている他のクラスを調べていない
ので、会社クラス２１０を新たな注目クラスとしてその
関連を調べる。しかし、図２の例では、会社クラス２１
０が関連を持っているクラスはないので、ステップ４０
０の判断結果はfalseとなる。そこで、再び全てのクラ
スに着目したか否かを調べる(ステップ４０６）。しか
し、図２の例では、未だ全てのクラスに着目していない
ので、ステップ４０６の処理はfalseとなる。そこで、
再度ステップ４００に戻って同様の処理を行う。

【００３３】図２の例では、保険クラス２３０に注目
し、これに関係を持っている他のクラスを調べていない
ので、保険クラス２３０を新たな注目クラスとしてその
関連を調べる。しかし、図２の例では、保険クラス２３
０が関連を持っているクラスはないので、ステップ４０
０の判断結果はfalseとなる。そこで、再び全てのクラ
スに着目したか否かを調べる(ステップ４０６）。今度
は、全てのクラスに着目し終えたので、ステップ４０６
の処理はtrueとなる。

【００３４】この結果、図５に示すように、顧客クラス
２２０の会社クラス２１０へのインタフェースクラス５
１２と、顧客クラス２２の保険料クラス２３０へのイン
タフェースクラス５２２という２つのインタフェースク
ラスが生成される。

【００３５】次に、上記のようにして生成された１つの
クラスが継承している複数のインタフェースクラス(図
５の５１２と５２２）を１つにまとめる処理を第２段階
目の抽象クラス化処理で行う。

【００３６】図７において、まず、１つのクラスが継承
している複数のインタフェースクラスを１つのインタフ
ェースクラスに継承し、その１つのインタフェースクラ
スを継承したクラスを生成する。ただし、図４の処理に
よって生成されたインタフェースクラス以外は除く。

【００３７】具体的には、まず、システム内で１つのク
ラスＸ、図２の例では顧客クラス２２０に着目する(ス
テップ６０１)。顧客クラス２２０が継承している顧客
クラス２２０の会社クラス２１０へのインタフェースク
ラス５１２と顧客クラス２２０の保険料クラス２３０へ
のインタフェースクラス５２２を全て継承した１つのイ
ンタフェースクラスＰを作成する(ステップ６０２）。
このインタフェースクラスＰは実装をもたず、メソッド
の定義のみ行うので、多重継承によるメソッドの重複が
おきても問題が無い。

【００３８】図５の例では、顧客クラス２２０の会社ク
ラス２１０へのインタフェースクラス５１２にはメソッ
ドgetID()、getName()、getCode()が定義されている。
また、顧客クラス２２０の保険料クラス２３０へのイン
タフェースクラス５２２にはメソッドgetID()、getRest
Life()が定義されている。顧客クラス２２０の会社クラ
ス２１０へのインタフェースクラス５１２と顧客クラス
２２０の保険料クラス２３０へのインタフェースクラス
５２２ではメソッドgetID()が重複しているため、顧客
クラス２２０のインタフェースクラス７２２にはgetI
D()、getName()、getCode()、getRestLife()の４つのメ
ソッドが定義されることになる。

【００３９】これにより、顧客クラス２２０はインタフ
ェースクラス７２２を継承する(ステップ６０３)。すな
わち、顧客クラス２２は、インタフェースクラス５１
２，５２２からの継承を止め、インタフェースクラス７
２２を継承する。そこで、次に全てのクラスに着目した
か否かを調べる(ステップ６０４）。しかし、図５の例
のクラス図では未だ全てのクラスに着目していないの
で、その判断結果ははfalseとなる。そこで、ステップ
６０１に戻り、今度は注目クラスを他のクラス、例えば
会社クラス２１０に設定し、同様の処理を行う。

【００４０】この段階では、会社クラスの２１０のイン
タフェースクラスは生成されていないので、ステッ６０
２，６０３の処理は行わない。この後、全てのクラスに
着目したか否かを調べる(ステップ６０４）。しかし、
図５の例のクラス図では未だ全てのクラスに着目してい
ないので、その判断結果はfalseとなる。そこで、ステ
ップ６０１に戻り、今度は注目クラスを他のクラス、保
険料クラス２３０に設定し、同様の処理を行う。しか
し、保険料クラス２３０のインタフェースクラスは生成
されていないので、ステップ６０２、ステップ６０３の
処理を行わない。次に、全てのクラスに着目したか否か
を再度調べる(ステップ６０４）。今度は全てのクラス
に着目し終わっているのでtrueとなる。

【００４１】ここまでの説明では、顧客クラス２２０に
おいてのみ抽象クラス化を行った場合について説明し
た。このようにして１つの業務システムにおいて、１つ
のクラスのインタフェースクラスが１つずつ作成され
る。

【００４２】次に、インタフェースクラスの抽象クラス
化を行う。その抽象クラス化は上記のようにして作成さ
れた１つのクラスにおける１つのインタフェースクラス
で定義されているメソッドを実装するのに最小限の属性
とメソッドを実装するように図８、図１０、図１１の処
理に従って、設計、実装される。さらに生成された抽象
クラスを継承した具象クラスには元のクラスの操作が全
て実装される。

【００４３】図９は、図８の第３段階目の抽象クラス化
処理に従って図７の顧客クラス２２０の抽象化を進めた
場合の結果を示すクラス図である。図７のクラス図に対
して順に図８の処理を適用する。

【００４４】まず、１つのクラスＸ、例えば顧客クラス
２２０に着目する(ステップ８０１)。顧客クラス２２０
のインタフェースクラス７２２で定義されているメソッ
ドを実装するのに最小限の属性とメソッドを持つ顧客ク
ラス２２０の抽象クラス８２２(図８では抽象クラス
Ｑ）を作成する(ステップ８０２)。

【００４５】次に、顧客クラス２２０の全ての操作を行
うことができる抽象クラス８２２を継承した顧客クラス
２２０の具象クラス８２１(図８では具象クラスＲ）を
作成する(ステップ８０３)。なお、抽象クラスの生成、
具象クラスの生成については後述する。

【００４６】次に、顧客クラス２２０の抽象クラス８２
２を継承した顧客クラス２２０の具象クラス８２１を作
成する(ステップ８０４)。

【００４７】次に、全てのクラスに着目したか否かを調
べる(ステップ８０５）。しかし、図７のクラス図の例
では、未だ全てのクラスに着目し終わっていないので、
falseとなる。そこで、ステップ８０１に戻り、今度は
注目クラスを他のクラス、会社クラス２１０に設定し、
同様の処理を行う。しかし、会社クラス２１０のインタ
フェースクラスは生成されていないので、ステップ８０
２〜８０４の処理を行わない。そこで、再度ステップ８
０１に戻り、今度は注目クラスを他のクラス、保険料ク
ラス２３０に設定し、同様の処理を行う。しかし、保険
料クラス２３０のインタフェースクラスは生成されてい
ないので、ステップ８０２〜８０４の処理を行わない。
次に、全てのクラスに着目したか否かを再度調べる(ス
テップ８０５）。今度は全てのクラスに着目し終わって
いるのでtrueとなる。

【００４８】ここで、顧客クラス２２０の抽象化を行う
ために必要な情報を以下に示す。

【００４９】顧客クラス２２０から抽出、解析された情
報である図１のクラス解析情報１９１とインタフェース
クラス７２２の情報を図１２に示している。顧客クラス
２２０に定義されている属性、メソッドは顧客クラス２
２０から得ることが出来る。顧客クラス２２０に書かれ
ていないクラス解析情報は図１２に記載されている。属
性はid、name、birthday、sexであり、メソッドはgetID
()、getName()、getAge()、getSex()、dump()、getCode
()、getRestLife()である。１つのメソッド当り、次の
３つの情報を持ち、図１２にそれらの情報を示してい
る。

【００５０】図１２のテーブル１２００では左から１列
目にはメソッド名１２１０を、左から２列目にはメソッ
ド内で呼ぶ自クラスの属性１２１１を、左から３列目に
はメソッド内で呼ぶ自クラスのメソッド１２１２を、左
から４列目には他クラスから呼ばれるメソッドか１２１
３を表にして示してある。

【００５１】このテーブル１２００のメソッドgetID()
１２１０の場合、メソッド内で呼ぶ自クラスの属性１２
１１がid １２１４、メソッド内で呼ぶ自クラス内のメ
ソッド１２１２が「なし」１２１５と、インタフェース
クラスのメソッドかを判断できる「他クラスから呼ばれ
るメソッドか」１２１３が「○」１２１６である。

【００５２】１２１６で示した「○」はインタフェース
クラス７２２で定義されているメソッドであることを示
す。「×」の場合はインタフェースクラス７２２で定義
されていないことを示す。以下、顧客クラス２２０の全
てのメソッドについてメソッドの情報が同様にテーブル
１２１０に記載されている。

【００５３】以上の情報を元にして顧客クラス２２０の
抽象化を図１０、図１１のフローを適用して進める(ス
テップ８０２、８０３に該当する)。

【００５４】図１０では、クラスの属性が抽象クラスで
定義される属性か、具象クラスで定義される属性かを判
断する処理が示されている。

【００５５】例えば、顧客クラス２２０について図１０
の処理を行う。まず、全ての属性に着目したか否かを判
断する(ステップ１００１）。この段階では、全ての属
性に着目していないのでステップ１００１の処理はfals
eとなる。１つのクラスＸの１つの属性Ｓに着目する(ス
テップ１００２）。例えば属性idに着目する。そして、
自クラスにおいてインタフェースクラスで定義されてい
ないメソッドのみで属性Ｓが使用されているか否かを判
断し(ステップ１００３）、さらに自クラスにおいてイ
ンタフェースクラスで定義されているメソッドのみで属
性Ｓが使用されているか否かを判断する(ステップ１０
０４）。

【００５６】属性id(１２１４）はインタフェースクラ
ス７２２で定義されている(１２１６)メソッドgetID()
１２１０のみで使用されており、getName()１２２０やg
etAge()１２３０等の他のメソッドでは使用されていな
い。このため、ステップ１００３の処理はfalse、ステ
ップ１００４の処理はtrueとなり、属性idは抽象クラス
８２２で定義される(ステップ１００６)。

【００５７】この後、ステップ１００１に戻り、同様の
処理を繰り返す。この段階では、未だ全ての属性に着目
していないのでステップ１００１の処理はfalseとな
る。そして、今度は属性nameに着目する(ステップ９０
２)。属性name(１２２４，１２５４)はインタフェース
クラス７２２で定義されている(１２２６)メソッドgetN
ame()１２２０とインタフェースクラス７２２で定義さ
れていない(１２５６)メソッドdump()１２５０で使用さ
れている。このため、ステップ１００３の処理はfals
e、ステップ１００４の処理はfalseとなり、属性nameは
抽象クラス８２２で定義されるが、属性nameを返すprot
ected修飾子を指定したメソッドName()も抽象クラス８
２２で定義される(ステップ１００５)。

【００５８】この後、ステップ１００１に戻り、同様の
処理を繰り返す。この段階では、未だ全ての属性に着目
していないのでステップ１００１の処理はfalseとな
る。そして、今度は属性birthdayに着目する(ステップ
１００２)。属性birthday(１２３４)はインタフェース
クラス７２２で定義されていない(１２３６)メソッドge
tAge()１２３０でのみ使用されている。このため、ステ
ップ１００３の処理はtrueとなり、具象クラス８２１で
定義される(ステップ１００７)。

【００５９】この後、ステップ１００１に戻り、同様の
処理を繰り返す。この段階では、未だ全ての属性に着目
していないのでステップ１００１の処理はfalseとな
る。そして、今度は属性sexに着目する(ステップ１００
２)。属性sex(１２１４)はインタフェースクラス７２２
で定義されていない(１２４６)メソッドgetSex()１２４
０でのみ使用されている。このため、ステップ１００３
の処理はtrueとなり、具象クラス８２１で定義される
(ステップ１００７)。全ての属性に着目し終わったこと
により、ステップ１００１の処理はtureとなる。

【００６０】故に属性idおよびnameは顧客クラス２２０
の抽象クラス８２２で定義され、属性birthdayおよびse
xは顧客クラス２２０の具象クラス８２１で定義され
る。

【００６１】図１１は、クラスのメソッドが抽象クラス
で定義されるメソッドか、具象クラスで定義されるメソ
ッドかを判断する処理を示すものである。

【００６２】例えば、顧客クラス２２０について図１１
の処理を行う。まず、全てのメソッドに着目したか否か
を判断する(ステップ１１０１）。この段階では、未だ
全てのメソッドに着目していないのでステップ１１０１
の処理はfalseとなる。そこで、１つのクラスＸの１つ
のメソッドＭに着目する(ステップ１１０２）。例え
ば、メソッドgetID()に着目する。そして、メソッドＭ
は自クラスにおいてインタフェースクラスで定義されて
いないメソッドであるか否かを判断し(ステップ１１０
３）、さらにメソッドＭ内で呼ばれるメソッドが全てイ
ンタフェースクラスで定義されているメソッドであるか
否かを判断する(ステップ１１０４）。

【００６３】メソッドgetID()１２１０はインタフェー
スクラス７２２で定義されている(１２１６)メソッドで
あり、メソッドgetID()内で呼ばれる自クラスのメソッ
ドは無い(１２１５)。このため、ステップ１１０３はfa
lse、ステップ１１０４はtrueとなり、抽象クラス８２
２で実装される(ステップ１１０５)。

【００６４】この後、ステップ１１０１に戻り、同様の
処理を繰り返す。この段階では、未だ全てのメソッドに
着目していないのでステップ１１０１の処理はfalseと
なる。そして、今度は他のメソッドに着目する(ステッ
プ１１０２)。例えば、メソッドgetName()に着目する。
メソッドgetName()１２２０はインタフェースクラス７
２２で定義されている(１２２６)メソッドであり、メソ
ッドgetName()内で呼ばれる自クラス内のメソッドは無
い(１２２５)。このため、ステップ１１０３はfalse、
ステップ１１０４はtrueとなり、抽象クラス８２２で実
装される(ステップ１１０５)。

【００６５】この後、ステップ１１０１に戻り、同様の
処理を繰り返す。この段階では、未だ全てのメソッドに
着目していないのでステップ１１０１の処理はfalseと
なる。そして、今度は他のメソッドに着目する(ステッ
プ１１０２)。例えば、メソッドgetAge()に着目する。
メソッドgetAge()１２３０はインタフェースクラス７２
２で定義されていない(１２３６)メソッドであり、メソ
ッドgetAge()内で呼ばれる自クラス内のメソッドは無い
(１２３４)。さらにgetAge()内で呼ばれている属性 bir
thday１２３４は図１０の処理により具象クラス８２１
で定義される属性であることが分かっている。このた
め、ステップ１１０３はtrueとなる。ステップ１１０６
では、具象クラス内で呼ばれていた属性が抽象クラスの
属性である場合、抽象クラスの属性を取得するメソッド
を呼ぶように変換する処理が行われるが、この場合には
ステップ１１０６の処理は行わずに具象クラス８２１で
実装される(ステップ１１０７)。

【００６６】この後、ステップ１１０１に戻り、同様の
処理を繰り返す。この段階では、未だ全てのメソッドに
着目していないのでステップ１１０１の処理はfalseと
なる。今度は、メソッドgetSex()に着目する(ステップ
１１０２)。メソッドgetSex()１２４０はインタフェー
スクラス７２２で定義されていない(１２４６)メソッド
であり、メソッドgetSex()内で呼ばれる自クラス内のメ
ソッドは無い(１２４４)。さらにgetSex()内で呼ばれて
いる属性sex１２４４は図１０の処理により具象クラス
８２１で定義される属性であることが分かっている。こ
のため、ステップ１１０３はture、ステップ１１０６の
処理は行わずに具象クラス８２１で実装される(ステッ
プ１１０７)。

【００６７】この後、ステップ１１０１に戻り、同様の
処理を繰り返す。この段階では、未だ全てのメソッドに
着目していないのでステップ１１０１の処理はfalseと
なる。今度は、メソッドdump()に着目する(ステップ１
１０２)。メソッドdump()１２５０はインタフェースク
ラス７２２で定義されていない(１２５６)メソッドであ
り、dump()内で呼ばれている属性はname１２５４であ
り、属性nameは図１０の処理により抽象クラス８２２で
定義される属性であることが分かっている。このため、
ステップ１１０３はtrue、ステップ１１０６の処理は行
うこととなり、属性nameの部分をName()に置き換えて具
象クラス８２１を実装する(ステップ１１０７)。

【００６８】この後、ステップ１１０１に戻り、同様の
処理を繰り返す。この段階では、未だ全てのメソッドに
着目していないのでステップ１１０１の処理はfalseと
なる。

【００６９】今度はメソッドgetCode()に着目する(ステ
ップ１１０２)。メソッドgetCode()１２６０はインタフ
ェースクラス７２２で定義されている(１２６６)メソッ
ドであり、getCode()内で呼ばれている属性は無い。get
Code()メソッド内で呼ばれているメソッドgetID()、get
Name()１２６５はインタフェースクラス７２２で定義さ
れている(１２１６、１２２６)メソッドである。このた
め、ステップ１１０３はfasle、ステップ１１０４はtru
eとなり、抽象クラス８２１で実装される(ステップ１１
０５)。

【００７０】この後、ステップ１１０１に戻り、同様の
処理を繰り返す。この段階では、未だ全てのメソッドに
着目していないのでステップ１１０１の処理はfalseと
なる。

【００７１】今度はメソッドgetRestLife()に着目する
(ステップ１１０２)。メソッドgetRestLife()１２７０
はインタフェースクラス７２２で定義されている(１２
７６)メソッドであり、getRestLife()内で呼ばれている
属性は無い。getRestLife()メソッド内で呼ばれている
メソッドgetAge()１２７５はインタフェースクラス７２
２で定義されていない(１２３６)メソッドである。この
ため、ステップ１１０３はfalse、ステップ１１０４はf
alseとなり、ステップ１１０６の処理は行わずに具象ク
ラス８２１で実装される(ステップ１１０７)。

【００７２】以上のようにして全てのメソッドに着目し
終わったならばステップ１１０１の処理はtrueとなる。

【００７３】故に顧客クラス２２０の抽象クラス８２２
で実装されるメソッドはgetID()、getName()、getCod
e()となり、具象クラス８２１で実装されるメソッドはg
etAge()、getSex()、dump()、getRestLife()となる。

【００７４】以上のようにして図８の処理(ステップ８
０２、ステップ８０３)は完了し、顧客クラス２２０に
おいて、顧客クラス２２０の抽象クラス８２２の属性は
id、name、メソッドはgetID()、getName()、getCode()
となる。また、顧客クラス２２０の具象クラス８２１の
属性はbirthday、sex、メソッドはgetAge()、getSe
x()、dump()、getRestLife()となる。

【００７５】

【発明の効果】以上説明したように本発明によれば、ク
ラスの関連を容易に理解し、再利用可能なクラスをイン
タフェースクラス、抽象クラス、具象クラスの３通りの
方法で与えることが出来る。インタフェースクラスには
クラス間に最低限必要なメソッドが定義され、抽象クラ
スにはインターフェースのメソッドを実装するのに必要
最小限な属性とメソッドが実装される。具象クラスは元
となったクラスのすべての操作を行うことができる。

【００７６】オブジェクト指向プログラムのソースコー
ドに対して本方法を適用すれば、実際に動作するインタ
フェースクラス、抽象クラス、具象クラスを与えること
が出来る。また、クラス図の設計に対して適用すれば、
インタフェースクラス、抽象クラス、具象クラスの設計
を与えることが出来、クラス毎の役割を明確にし、設計
を支援することが出来る。

【００７７】また、業務システムに適用すれば、上記の
インタフェースクラス群、抽象クラス群を業務モデルの
関連を表したフレームワークとして得ることが出来る。
このように整理した形で業務システムを理解できること
は同様な別の業務システム構築の際に重要となるメソッ
ドを容易に見つけ出すことにも役立つなどの極めて有用
な効果を発揮するものとなる。

【図面の簡単な説明】

【図１】本発明によるクラス間の関連に基づいた抽象ク
ラス自動生成システムの実施形態を示すシステム構成図
である。

【図２】顧客クラスの具体例を示すクラス図である。

【図３】顧客クラスの抽象化の全過程を示すフローチャ
ートである。

【図４】クラスの第１段階の抽象クラス化処理のフロー
チャートである。

【図５】顧客クラスを第１段階の抽象クラス化したクラ
ス図である。

【図６】クラスの第２段階の抽象クラス化処理のフロー
チャートである。

【図７】顧客クラスを第２段階の抽象クラス化したクラ
ス図である。

【図８】クラスの第３段階の抽象クラス化処理のフロー
チャートである。

【図９】顧客クラスを第３段階の抽象クラス化したクラ
ス図である。

【図１０】抽象クラスで定義される属性かの判断処理を
示すフローチャートである。

【図１１】抽象クラスで実装されるメソッドかの判断処
理を示すフローチャートである。

【図１２】顧客クラスの各メソッドの情報テーブルの構
成図である。

【符号の説明】

１１１…ソースコード、１１２…ソースコード解析装
置、１１３…抽象クラス化を行ったソースコード、１２
１…クラス図、１２２…クラス図解析装置、１２３…抽
象クラス化を行ったクラス図、１９１…クラス情報抽出
装置、１９２…クラス間の関連に基づいた抽象クラス自
動生成装置、２１０…会社クラス、２２０…顧客クラ
ス、２３０…保険料クラス、５１２，５２２…インタフ
ェースクラス、７２２…顧客クラスのインタフェースク
ラス、８２１…顧客クラスの具象クラス、８２２…顧客
クラスの抽象クラス。

Claims

【特許請求の範囲】

【請求項１】オブジェクト指向技術を用いたソフトウ
ェア開発における抽象クラスを生成する方法であって、任意の業務システムを構成するクラス群の中の各クラス
のメソッド内で呼ばれる他クラスのメソッドを取得する
ステップと、複数の他クラスに対する自クラスのインタ
フェースクラスを生成するステップと、複数の他クラス
に対する自クラスのそれぞれのインタフェースクラスを
継承した１つのインタフェースクラスを生成するステッ
プとを含むことを特徴とするクラス間の関連に基づいた
抽象クラスの自動生成方法。
【請求項２】前記任意の業務システムを構成するクラ
ス群の中の各クラスの属性、メソッド、メソッド内で呼
ばれる他クラスのメソッド、メソッド内で呼ばれる自ク
ラス内のメソッド、メソッド内で呼ばれる自クラス内の
属性を取得するステップと、前記１つのインタフェース
クラスのメソッドを実装するのに最小限の属性とメソッ
ドを持つ抽象クラスを作成するステップとを含むことを
特徴とする請求項１に記載のクラス間の関連に基づいた
抽象クラスの自動生成方法。
【請求項３】前記１つのインタフェースクラスのクラ
ス図を生成するステップを含むことを特徴とする請求項
１に記載のクラス間の関連に基づいた抽象クラスの自動
生成方法。
【請求項４】前記１つの抽象クラスのクラス図を生成
するステップを含むことを特徴とする請求項２に記載の
クラス間の関連に基づいた抽象クラスの自動生成方法。
【請求項５】前記１つのインタフェースクラスのソー
スコードを生成するステップを含むことを特徴とする請
求項１に記載のクラス間の関連に基づいた抽象クラスの
自動生成方法。
【請求項６】前記１つの抽象クラスのソースコードを
生成するステップを含むことを特徴とする請求項２に記
載のクラス間の関連に基づいた抽象クラスの自動生成方
法。
【請求項７】オブジェクト指向技術を用いたソフトウ
ェア開発における抽象クラスを生成する装置であって、任意の業務システムを構成するクラス群の中の各クラス
のメソッド内で呼ばれる他クラスのメソッドを取得する
手段と、複数の他クラスに対する自クラスのインタフェ
ースクラスを生成する手段と、複数の他クラスに対する
自クラスのそれぞれのインタフェースクラスを継承した
１つのインタフェースクラスを生成する手段とを備える
ことを特徴とするクラス間の関連に基づいた抽象クラス
の自動生成装置。
【請求項８】前記任意の業務システムを構成するクラ
ス群の中の各クラスの属性、メソッド、メソッド内で呼
ばれる他クラスのメソッド、メソッド内で呼ばれる自ク
ラス内のメソッド、メソッド内で呼ばれる自クラス内の
属性を取得する手段と、前記１つのインタフェースクラ
スのメソッドを実装するのに最小限の属性とメソッドを
持つ抽象クラスを作成する手段とを備えることを特徴と
する請求項７に記載のクラス間の関連に基づいた抽象ク
ラスの自動生成装置。