(57)【要約】【課題】  親子クラスの統合を実施することで多製品開発にも対応可能なオブジェクト指向プログラム生成装置を提供する。【解決手段】  モデル図面情報から、継承関係にあり、かつ統合可能な1つの親クラスと1つの子クラスの対を選択する統合親子クラス選択手段と、前記統合親子クラス選択手段によって選択された1対の親クラスと子クラスを1つのクラスに統合するクラス統合手段と、前記クラス統合手段によって統合された結果を記憶する統合後モデル情報格納手段とを具備し、前記プログラム自動生成手段においては統合後モデル情報格納手段によって記憶された統合後モデル情報を基にプログラムを自動生成することを特徴とするオブジェクト指向プログラム生成装置等を提供する。【選択図】  図１
2007280138.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアの構造を表現するモデル図面をユーザが記述・編集可能とするモデル図面入力手段と、前記モデル図面入力手段によって入力されたモデル情報を記憶するモデル情報格納手段と、前記モデル情報格納手段によって格納された情報を基に表示するモデル図面を生成する表示モデル図面生成手段と、前期表示モデル図面生成手段によって生成されたモデル図面情報を基に図面を表示するモデル図面表示手段と、前記モデル情報格納手段によって記憶されたモデル情報を基にプログラムを自動生成するプログラム自動生成手段と、前記プログラム自動生成手段によって生成されたプログラムを記憶するプログラム格納手段と、前記プログラム格納手段によって記憶されたプログラムを表示するプログラム表示手段とを有するオブジェクト指向プログラム生成装置において、
前記モデル図面情報から、継承関係にあり、且つ統合可能な１つの親クラスと１つの子クラスの対を選択する統合親子クラス選択手段と、
前記統合親子クラス選択手段によって選択された１対の親クラスと子クラスを１つのクラスに統合するクラス統合手段と、
前記クラス統合手段によって統合された結果を記憶する統合後モデル情報格納手段とを具備し、
前記プログラム自動生成手段においては統合後モデル情報格納手段によって記憶された統合後モデル情報を基にプログラムを自動生成することを特徴とするオブジェクト指向プログラム生成装置。
【請求項２】
前記モデル情報格納手段では、特にクラス間の関連情報として各クラスが継承する親クラスの情報及びインスタンス化の有無に関する情報を持ち、前記統合親子クラス選択手段では、上記クラスごとに保持される親クラスの情報より、１つの親クラスに対し１つの子クラスのみ継承関係が定義され、なおかつ親クラスのインスタンス化が行われない親クラスと子クラスの対を自動的に選択することを特徴とする請求項１に記載のオブジェクト指向プログラム生成装置。
【請求項３】
前記クラス統合手段では、新たに統合されるクラスは統合前の親クラスと子クラスの定義のマージにより表現されることを特徴とし、特に新たに統合されるクラスのクラス名については、統合前の親クラスもしくは子クラスのクラス名、もしくはユーザによって新たに定義されるクラス名を選択的に命名可能とすることを特徴とする請求項１又は２に記載のオブジェクト指向プログラム生成装置。
【請求項４】
前記モデル情報格納手段によって記憶されたモデル情報と、前記統合後モデル情報格納手段に記憶された親子クラス統合後モデル情報とを、ユーザが任意に選択して表示可能とする表示モデル図面選択手段を有することを特徴とする請求項１乃至３の何れか１項に記載のオブジェクト指向プログラム生成装置。
【請求項５】
前記プログラム自動生成手段が基にするモデル情報として、前記モデル情報格納手段によって記憶されたモデル情報、もしくは前記統合後モデル情報格納手段に記憶されたクラス統合後情報をユーザが任意に選択して利用可能とするプログラム自動生成方法選択手段を有することを特徴とする請求項１乃至４の何れか１項に記載のオブジェクト指向プログラム生成装置。
【請求項６】
前記モデル情報格納手段によって記憶されるモデル情報からプログラム自動生成の対象とするクラスを限定する対象クラス限定手段と、
前記対象クラス限定手段により限定されたモデル情報を格納するサブセットモデル情報格納手段とを有し、
前記統合親子クラス選択手段が前記サブセットモデル情報格納手段によって格納されたサブセットモデル情報格納情報を参照することを特徴とする請求項１乃至５の何れか１項に記載のオブジェクト指向プログラム生成装置。
【請求項７】
モデル図面情報から、継承関係にあり、かつ統合可能な１つの親クラスと１つの子クラスの対を選択する統合親子クラス選択ステップと、
前記統合親子クラス選択ステップによって選択された１対の親クラスと子クラスを１つのクラスに統合するクラス統合ステップと、
前記クラス統合ステップによって統合された結果を記憶する統合後モデル情報格納ステップとを具備し、
統合後モデル情報格納ステップによって統合されたモデル情報に基づいてプログラムを自動生成することを特徴とするオブジェクト指向プログラム生成方法。
【請求項８】
請求項７に記載のオブジェクト指向プログラム生成方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、自動生成されるプログラムが必要とするＲＯＭ容量を削減することを目的とするオブジェクト指向プログラム生成装置、オブジェクト指向プログラム生成方法及びプログラムに関する。
【背景技術】
【０００２】
近年、ソフトウェア分析設計手法の一つとしてオブジェクト指向分析設計が普及している。ここで、オブジェクト指向分析設計とは、現実世界の実体をオブジェクトとして抽出し、このオブジェクトを単位としてシステムを構成していく開発手法である。
【０００３】
オブジェクト指向分析設計の開発手法においては、同種類のオブジェクトを抽象化したものを「クラス」と呼び、クラスが保持する内部データを記述するための「属性」や、クラスへの操作を表す「関数」が定義される。
【０００４】
また、抽出されたクラス間の構造を表現するために「クラス図」を記述する。ここでは、他のクラスへの関数呼び出しなど、クラス間の相互作用を実現するための「通常関連」や、あるクラスの定義を継承し、なおかつ新たな定義を加えたクラスを定義するための「継承関連」がクラス間に定義される。
【０００５】
特に、継承関連で結合された２つのクラスについては、継承元となるクラスを「親クラス」と称し、親クラスを継承し新たな定義が加えられたクラスを「子クラス」と称す。
【０００６】
この継承関係は、例えば１つのクラス図にて系列製品群を表現したい場合に、複数の製品間で共通の定義のみ親クラスに定義し、親クラスを継承した子クラスにはその差分を定義するという方法で用いられることがある。この場合、1つの親クラスに対し、個別製品のバリエーション数に対応した複数の子クラスが継承関係によって結合され、その結果、１つの子クラスがすなわち１つの製品に１対１で対応する構造となる。
【０００７】
また、クラスによっては、複数のクラスの定義を継承したいという要求が生じる。この場合、1つの子クラスが複数の親クラスと継承関係で結合される構造となり、このような関係を「多重継承」と称す。
【０００８】
さらに、システム全体では通常関連で結合されたクラス間で処理の依頼を行ない互いに協調し合って１つの大きな処理を実現する。この際の、あるクラスから他のクラスへの処理の依頼を「メッセージ」と呼び、特に呼び出し側のクラスが処理の完了を待たずに次の処理を実行するメッセージを「イベント」と称す。
【０００９】
このようにイベントを受け取り、このイベントをトリガとして自らの状態の変化、および特定のアクションを実行するクラスを「能動クラス」と称し、この能動クラスは前記状態の変化や実行するアクションを図示するために「状態図」を保持する。一方、イベントを受け取ることがなく、状態図を持たないクラスを「受動クラス」と称す。
【００１０】
上記オブジェクト指向分析設計を用いたシステム開発を支援する装置としては、オブジェクト指向設計支援装置が提案されている。オブジェクト指向設計支援装置とは、コンピュータなどの情報処理手段を用いて、オブジェクト指向の開発に用いられるソフトウェア設計図の作成を支援する装置である。また、上記オブジェクト指向設計支援装置においてはUnified Modeling Language(以下、ＵＭＬと称す)と呼ばれる記法によりソフトウェア設計図面を作成する方法が主流となっている。例えば前述のクラス図、状態図もＵＭＬに基づいて記述される。
【００１１】
さらに、上記ＵＭＬに基づいて記述されたソフトウェア設計図よりプログラムを自動生成する装置としては、オブジェクト指向プログラム生成装置が提案されている。オブジェクト指向プログラム生成装置では、ユーザによって記述されたモデル図面情報と、この図面情報を例えばＣ、Ｃ＋＋、Java（登録商標）などのプログラムに変換する変換ルールとを入力として、動作可能なプログラムを自動生成することを可能としている。
【００１２】
しかしながら、ユーザによって記述されたモデル図面情報から、分析／設計されたソフトウェアの仕様を損なわず、かつよりパフォーマンスの高いプログラムを自動生成する手段に関しては、これまでに十分に実用的な手法が提案されていない。
【００１３】
すなわち、オブジェクト指向分析設計の主旨に沿って、設計者の理解を高めるためにより詳細なクラス分割を行ったモデル図面情報を基にプログラムを自動生成すると、生成されるプログラムの実行に必要なＲＯＭ容量が大きくなるという問題が生じる。特に自動生成されるプログラムが機器に組込まれるものである場合には、プログラムが利用できるＲＯＭ容量に制限がある場合が多く、この問題は深刻である。
【００１４】
ここで、通常モデル図面よりプログラムを自動生成する場合には、１つのクラスに対し１組のソースコードファイルが生成される。この際、それぞれのソースコードには、例えば、クラス名の宣言、コンストラクタ・デストラクタ用関数の定義、能動クラスにおける状態遷移テーブルの定義等といったプログラム上でクラス定義を実現するためのオーバーヘッドが存在する。これらは、生成するプログラム言語の種類や変換ルールの違いによりその影響度は異なるものの、新たなクラスが定義されるたびに必要となり、その結果プログラム実行時に必要となるＲＯＭ容量の増大を引き起こす。
【００１５】
ここで、例えば系列製品群を１つのクラス図で表現しているような場合には、ソースコードを自動生成する製品を限定することで参照すべきクラス数を減らすことが可能となる。その結果クラス定義を実現するためのオーバーヘッドが減少しＲＯＭ容量削減をもたらす。この方法は、多製品に対応した汎用的な設計図面より特定の製品に特化したソースコードを自動生成する技術としてよく知られている。
【００１６】
また、２つのクラスとしてモデル図面が記述されている特定の分析部分を1つのクラスとして統合して分析／記述した場合にも、上記クラス定義を実現するためのオーバーヘッドが１クラス分省略され、ＲＯＭ容量の削減が可能となる。これは、統合する２つのクラスが継承関係によって結合された親クラスと子クラスの対である場合にも同様の効果をもたらす。
【００１７】
このように、クラス図中に分析するクラス数を少なくすることにより、自動生成されるプログラムのサイズを小さくすることが可能である。
【００１８】
しかしながら、逆に上記の目的を達成するためにより少ないクラス数でクラス図を記述しようとすれば、モデル図面は理解しにくいものとなってしまい、設計図面の可読性および保守性に優れるといったオブジェクト指向分析設計の最大の利点が失われる。特に継承関係にある２つのクラスは、親クラスには他のクラスとのインタフェースが定義され、子クラスにて内部の異なる動作が規定される場合や前述の通り系列製品群のバリエーションを子クラスで表す場合等がある。そのため、これらのクラスの統合は可読性および保守性を著しく損なう。
【００１９】
上記の問題に関して、特許文献１では、ユーザの入力したクラス図を等価変換し、その結果よりプログラムを自動生成する手法が開示されている。しかしながら、この発明は、複数のクラスの統合に関する手法が提案されてはいるものの、クラス図の等価変換の目的はモデル図面の保守性の向上であり、等価変換の結果得られるモデル図面より自動生成されるプログラムのＲＯＭ容量の削減については考慮されていない。
【００２０】
また、特許文献２、特許文献３では、メモリ容量の小さなプログラムの生成装置を提供する手法が提案されている。しかしながら、これらの装置はどちらも、ある特定のクラスの状態遷移情報のみを読み込み、それを縮約化手段により類似する複数の状態を１つの状態に縮約化し、自動生成されるプログラムの必要とするＲＯＭ容量を小さくする手法について提案してはいる。但し、単一状態図内の縮約を前提としており、親子関係にある複数のクラスを統合し、なおかつ自動生成されるプログラムのＲＯＭ容量を削減する手段については言及されていない。
【００２１】
さらに、特許文献３では、クラスコード解析情報を利用して既存クラスの構造を変更する方法が開示されている。しかしながら、この方法においても、統合の対象は同一の関数および属性を持つクラスであり、例えば複数のクラスに共通の属性や関数を抽出して上位の抽象クラスを生成する等、モデル図面の洗練化作業を支援することが目的である。その結果、得られるモデル図面より自動生成されるＲＯＭ容量の削減については言及されていない。
【００２２】
【特許文献１】特開平６-３４８４９９号公報
【特許文献２】特開平７−２７１５６８号公報
【特許文献３】特開平９−１４６７６６号公報
【発明の開示】
【発明が解決しようとする課題】
【００２３】
このように、従来のオブジェクト指向プログラム生成装置では、親子関係にある２つのクラスを統合し、その統合結果を用いてプログラムを自動生成することができない。
【００２４】
そこで、本発明の目的は、生成されるプログラムが必要とするＲＯＭ容量の削減を実現することにある。
【００２５】
また、本発明の他の目的は、モデル図面の可読性、保守性を維持し、オブジェクト指向分析設計のメリットを損なわない構成を実現することにある。
【００２６】
さらに、本発明の別の目的は、例えば、複数製品に対応するモデル図面から、まずは特定の製品を限定することでサブセット化されたモデル図面情報を得、これを基に上記親子クラスの統合を実施することで多製品開発にも対応可能とすることにある。
【課題を解決するための手段】
【００２７】
本発明のオブジェクト指向プログラム生成装置は、ソフトウェアの構造を表現するモデル図面をユーザが記述・編集可能とするモデル図面入力手段と、前記モデル図面入力手段によって入力されたモデル情報を記憶するモデル情報格納手段と、前記モデル情報格納手段によって格納された情報を基に表示するモデル図面を生成する表示モデル図面生成手段と、前期表示モデル図面生成手段によって生成されたモデル図面情報を基に図面を表示するモデル図面表示手段と、前記モデル情報格納手段によって記憶されたモデル情報を基にプログラムを自動生成するプログラム自動生成手段と、前記プログラム自動生成手段によって生成されたプログラムを記憶するプログラム格納手段と、前記プログラム格納手段によって記憶されたプログラムを表示するプログラム表示手段とを有するオブジェクト指向プログラム生成装置において、前記モデル図面情報から、継承関係にあり、且つ統合可能な１つの親クラスと１つの子クラスの対を選択する統合親子クラス選択手段と、前記統合親子クラス選択手段によって選択された１対の親クラスと子クラスを１つのクラスに統合するクラス統合手段と、前記クラス統合手段によって統合された結果を記憶する統合後モデル情報格納手段とを具備し、前記プログラム自動生成手段においては統合後モデル情報格納手段によって記憶された統合後モデル情報を基にプログラムを自動生成することを特徴とする。
本発明のオブジェクト指向プログラム生成方法は、モデル図面情報から、継承関係にあり、かつ統合可能な１つの親クラスと１つの子クラスの対を選択する統合親子クラス選択ステップと、前記統合親子クラス選択ステップによって選択された１対の親クラスと子クラスを１つのクラスに統合するクラス統合ステップと、前記クラス統合ステップによって統合された結果を記憶する統合後モデル情報格納ステップとを具備し、統合後モデル情報格納ステップによって統合されたモデル情報に基づいてプログラムを自動生成することを特徴とする。
本発明のプログラムは、前記オブジェクト指向プログラム生成方法をコンピュータに実行させることを特徴とする。
【発明の効果】
【００２８】
本発明においては、ユーザの入力したモデル図面情報から、継承関係にあり、なおかつ統合可能な１つの親クラスと１つの子クラスの対を選択する統合親子クラス選択手段と、前記統合親子クラス選択手段によって選択された１対の親子クラスを１つのクラスに統合するクラス統合手段と、前記クラス統合手段によって統合された結果を記憶する統合後モデル情報格納手段を有する。これにより、クラス統合後情報を基にプログラムを自動生成することを可能とし、従来に比べ実行時に必要とするＲＯＭ容量が少ないプログラムを自動生成することが可能となる。
【００２９】
また、本発明においては、特に各クラスが継承する親クラスの情報とインスタンス化の有無に関する情報とを記憶するモデル情報格納手段、および統合親子クラス選択手段を有する。これにより、統合可能な複数のクラスを自動的に抽出することが可能となる。
【００３０】
また、本発明においては、新たに統合されるクラスは統合前の親クラスと子クラスの定義のマージにより表現されることを特徴とし、特に新たに統合されるクラスのクラス名については、統合前の親クラスもしくは子クラスのクラス名、もしくはユーザによって新たに定義されるクラス名を選択的に命名可能とする手段を有する。これにより、１対の親子クラスの自動統合が可能となる。
【００３１】
また、本発明においては、ユーザに表示するモデル情報として、親子クラスの統合前、もしくは統合後のモデル情報をユーザが任意に選択して表示可能とする表示モデル選択手段を有する。これにより、状況に応じて表示するモデルを任意に選択可能となる。
【００３２】
また、本発明においては、プログラムの自動生成の元となるモデル情報として、親子クラスの統合前、もしくは統合後のモデル情報をユーザが任意に選択して表示可能とするプログラム自動生成方法選択手段を有する。これにより、状況に応じて生成するプログラムを任意に選択可能となる。
【００３３】
また、本発明においては、プログラム自動生成の対象とするクラスを限定する対象クラス限定手段と、限定されたモデル情報を格納するサブセットモデル情報格納手段を有する。これにより、例えば系列製品群に対応するクラス図を基にさらに製品を限定することでサブセット化されたクラス図を参照可能な構成とし、上記ＲＯＭ容量削減手段を多製品開発にも対応可能となる。
【発明を実施するための最良の形態】
【００３４】
以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。
【００３５】
図１は、本発明の実施形態を示すシステムの全体構成図である。図中、１０１はＣＰＵであり、以下に説明する１０３〜１１０の装置を１０２で示すバスを介してアクセスし制御を行う。
【００３６】
１０３はバス１０２を介してＣＰＵ１０１からアクセス可能な読み出し専用メモリ（ＲＯＭ）であり、本実施形態ではその動作を詳細に説明する処理プログラム１０３ａ及び処理プログラムにより使用されるパラメータ１０３ｂが格納されている。
【００３７】
１０４は読み書き可能なメモリ（ＲＡＭ）である。ＲＡＭ１０４上には、上記処理プログラム１０３により作成／変更がなされる、モデル情報、サブセットモデル情報、統合後モデル情報、生成プログラムをそれぞれ格納するための領域(順に１０４ａ、１０４ｂ、１０４ｃ、１０４ｄ)が確保されている。
【００３８】
１０５は入力インタフェースであり、１０６で示したキーボード、マウス、タブレット等の入力装置を介してなされる入力を受け取る。１０７は出力インタフェースであり、ＣＲＴ１０８、ＬＣＤ等(順に１０８ａ、１０８ｂ)の表示媒体、更にはプリンタ、プロッタ等の出力装置に対し、データの表示／出力を行う。また、１０９は外部記憶装置インタフェースであり、１１０で示したＨＤ、ＦＤ、ＣＤ−ＲＯＭ、ＭＤ、ＣＦ等の外部記憶装置に対するデータの入出力を行うものである。
【００３９】
また、図２は本発明に関るオブジェクト指向プログラム生成装置の構成を示すブロック図である。図中、２０１はユーザがクラス図、状態図などモデル情報を入力するモデル図面入力部であり、入力インタフェース１０５及び入力装置１０６により実現される。
【００４０】
２０２はモデル図面入力部２０１によって入力されたモデル図面情報をオブジェクト指向プログラム生成装置上に記憶するモデル情報格納部であり、格納されるモデル情報はバス１０２を介しＲＡＭ１０４に記憶される。
【００４１】
２０３はモデル情報格納部２０２によって記憶されたモデル図面情報を基に、ユーザに対し表示するモデル図面を生成する表示モデル図面生成部であり、ＲＯＭ１０３上に配置された処理プログラム１０３ａにより実現される。
【００４２】
２０４は表示モデル図面生成部２０３によって生成されたモデル図面情報を基に、ユーザに対しモデル図面を表示するモデル図面表示部であり、出力インタフェース１０７及び表示媒体１０８により実現される。
【００４３】
２０５はモデル情報格納部２０２に記憶されているモデル情報と、モデル情報をＣ、Ｃ＋＋、Java（登録商標）などといったプログラム言語に変換するための変換ルールとを入力として、動作可能なプログラムを自動生成するプログラム自動生成部である。この処理プログラムはＲＯＭ１０３に格納され、バス１０２を介して利用される。
【００４４】
２０６はプログラム自動生成部２０５によって生成されたプログラム情報をオブジェクト指向プログラム生成装置上に記憶するプログラム格納部であり、格納される生成プログラムはバス１０２を介しＲＡＭ１０４に記憶される。
【００４５】
２０７はプログラム格納部２０６に記憶されているプログラム情報を基に、ユーザに対し自動生成されたプログラムを表示するプログラム表示部であり、出力インタフェース１０７及び表示媒体１０８により実現される。
【００４６】
２０８はモデル情報格納部２０２に記憶されたモデル情報より、統合可能な１対の親子クラスを自動的に選択する統合親子クラス選択部であり、この処理プログラムはＲＯＭ１０３に格納され、バス１０２を介して利用される。
【００４７】
２０９は統合親子クラス選択部２０８によって選択された親子クラスの情報と、モデル情報格納部２０２に記憶されているユーザが入力したモデル図面情報を基に、選択された１対の親子クラスを１つのクラスに統合するクラス統合部である。この処理プログラムはＲＯＭ１０３に格納され、バス１０２を介して利用される。
【００４８】
２１０はクラス統合部２０９によって統合された結果を記憶する統合後モデル情報格納部であり、格納されるクラス統合結果情報はバス１０２を介しＲＡＭ１０４に記憶される。
【００４９】
２１１はモデル情報格納部２０２に記憶されているユーザによって入力されたモデル情報と統合後モデル情報格納部２１０に記憶されているクラス統合結果情報を、ユーザが任意に選択して表示モデル図面生成部２０３への入力情報とすることを可能とする表示モデル図面選択部である。表示モデル図面選択部２１１は入力インタフェース１０５及び入力装置１０６により実現される。
【００５０】
２１２はモデル情報格納部２０２に記憶されているユーザによって入力されたモデル情報と、統合後モデル情報格納部２１０に記憶されているクラス統合結果情報を、ユーザが任意に選択してプログラム自動生成部２０５への入力情報とすることを可能とするプログラム自動生成方法選択部である。プログラム自動生成方法選択部２１２は、入力インタフェース１０５及び入力装置１０６により実現される。
【００５１】
２１３はモデル情報格納部２０２に記憶されているユーザによって入力されたモデル情報から、プログラム自動生成の対象とするクラスを限定する対象クラス限定部であり、入力インタフェース１０５及び入力装置１０６により実現される。
【００５２】
２１４は対象クラス限定部２１３によって選択されたモデル情報のみをモデル情報格納部２０２より取り出し、新たにサブセットモデル情報として格納するサブセットモデル情報格納部である。サブセットモデル情報格納部２１４は、格納されるサブセットモデル情報はバス１０２を介しＲＡＭ１０４に記憶される。
【００５３】
このように構成されたオブジェクト指向プログラム生成装置においては、ユーザがモデル図面入力部２０１によって入力し、なおかつモデル情報格納部２０２に記憶されたモデル図面情報より、まず統合親子クラス選択部２０８によって選択された１対の親子クラスがクラス統合部２０９により統合される。その結果が統合後モデル情報格納部２１０に格納され、さらにその情報を基にプログラム自動生成部２０５が実行時に利用されるＲＯＭ容量に削減されたプログラムを自動生成し、その生成結果はプログラム格納部２０６に記憶され、またプログラム表示部２０７に表示される。
【００５４】
さらに、表示モデル図面生成部２０３により生成され、モデル図面表示部２０４に表示されるモデル情報は、表示モデル図面選択部２１１により択一的に選択されたモデル情報格納部２０２に記憶されたモデル情報、もしくは統合後モデル情報格納部２１０に記憶されたモデル情報のいずれかである。親子クラスの統合処理がそのまま上記モデル図面表示部２０４に表示されるモデル図面には反映されない構成とすることで、モデル図面の可読性、保守性を維持し、オブジェクト指向分析設計のメリットを損なわない構成を実現している。
【００５５】
加えて、統合親子クラス選択部208が参照するモデル情報として、ユーザがモデル図面入力部２０１によって入力し、なおかつモデル情報格納部２０２に記憶されたモデル情報の他に、さらに対象クラス限定部２１３により入力された情報を基に参照するクラス数が限定され、サブセットモデル情報格納部２１４に格納されるモデル情報を参照可能とする。これにより、例えばソースコード自動生成時に、複数製品に対応するクラス図から特定の製品用に参照するクラスを限定するような開発フローにおいても、親子クラスの統合によるＲＯＭ容量の削減を実行可能な構成としている。
【００５６】
−第１の実施形態−
次に、本発明の第１の実施形態について説明する。
図３は、クラス図の統合例を示している。図中、３０１及び３０２はそれぞれモデル図面入力部２０１によりユーザが入力したモデル図面のうち、統合親子クラス選択部２０８により統合可能と判定された１対の親子クラス、３０３はクラス統合部２０９により統合され統合後モデル情報格納部２１０に格納される統合後クラスである。
【００５７】
例えば３０１に示すSuperClass(親クラス)およびSubClass(子クラス)が統合された場合、統合後に新たに生成されるクラス３０３は統合前の親クラスのクラス名（SuperClass）を持ち、定義される属性及び関数は、統合前の２つのクラスの定義をマージしたものとなる。
【００５８】
また、図４は、本発明の第１の実施形態の実現手順を示すフローチャートである。以下では、このフローチャートに沿って実施形態を説明する。
【００５９】
ステップＳ４０１では、モデル図面入力部２０１によりユーザがモデル図面を入力する。ステップＳ４０２では、ステップＳ４０１により入力されたモデル情報をモデル情報格納部２０２を用いてオブジェクト指向プログラム生成装置上に記憶する。
【００６０】
ステップＳ４０３では、モデル図面の入力が終了したかをユーザからの入力により判断する。具体的には、ユーザの直前の入力がプログラムの自動生成開始命令であるなど、モデル図面の入力終了を表す情報に相当した場合、モデル図面の入力が終了したと判断する。もしモデル図面の入力が終了した場合にはステップＳ４０４の処理に流れ、そうでないならばステップＳ４０１の処理に戻る。
【００６１】
ステップＳ４０４では、ステップＳ４０２によって格納されたモデル情報を基に、統合親子クラス選択部２０８により統合可能なクラスの選択を行い、さらに選択されたクラスに対しクラス統合部２０９を用いてクラスの統合を実行する。
【００６２】
ステップＳ４０５では、ステップＳ４０４により生成されたクラス統合情報を基に、プログラムの自動生成を行う。
【００６３】
ステップＳ４０６では、ステップＳ４０５により自動生成されたプログラムを、出力装置に表示する。
【００６４】
以上の処理によって、ユーザにより入力されたモデル情報を基に、親子クラスを統合し、その統合結果を用いて自動生成されるソースコードの実行時ＲＯＭ容量の削減が実現される。
【００６５】
さらに、図５はステップＳ４０４の統合可能なクラスの選択と統合の詳細アルゴリズムを示すフローチャートである。
【００６６】
ステップＳ５０１では、以降のステップＳ５０２〜ステップＳ５０５の処理をモデル情報格納部２０２に記憶されているモデル情報のうち、特に登録されているクラスの数だけ繰り返す。
【００６７】
ステップＳ５０２では、モデル情報格納部２０２に記憶されているモデル情報を用いて、現在選択されているクラスが子クラスであり、なおかつ統合親子クラス選択部２０８によって統合可能であるかを判定する。ここで、もし選択されているクラスが子クラスとして統合可能であると判定された場合にはステップＳ５０３の処理に流れ、そうでないならばステップＳ５０５の処理に流れ、再度ステップＳ５０１からの処理が繰り返される。
【００６８】
ステップＳ５０３では、ステップＳ５０２により統合可能であると判定されたクラスに対し、クラス統合部２０９によりクラスの統合が行われる。
【００６９】
ステップＳ５０４では、ステップＳ５０３により統合されたモデル情報の結果が、統合後モデル情報格納部２１０に対し格納される。
【００７０】
以上の処理によって、ユーザにより入力されたモデル情報より、統合可能な親子クラスの対が選択され、さらに選択された親子クラスに対し実際の統合処理が行われる。これらの処理によって生成、統合後モデル情報格納部２１０に記憶されたクラス結合結果情報については、実行時のＲＯＭ容量が削減されるソースコードの自動生成に用いられる。
【００７１】
−第２の実施形態−
次に、本発明の第２の実施形態について説明する。
図６は、モデル情報格納手段によりモデル情報格納部２０２に記憶されるモデル図面情報の中で、特に各クラスの親クラス情報およびインスタンス化有無情報の保持例を示したものである。また、このクラス情報の保持例は、図３に示したユーザが入力したモデル図面より格納されたモデル情報に対応している。
【００７２】
図中、６０１はユーザの入力した全てのクラス情報を示している。また、６０２は、該当するクラスが親クラスを保持しているかを示しており、もしも保持していない場合には"×"が、保持している場合には親クラス名が記載されている。
【００７３】
６０３は、該当するクラスがシステムの動作時にインスタンス化されるか否かの情報を示している。このインスタンス化されるか否かの情報は、システム内に記述されている全てのアクション内で各クラスに対する生成オペレーションが記述されているか否かを検索することにより取得することができる。生成オペレーションが存在している場合は、すなわち該当クラスがインスタンス化されると判断でき、生成オペレーションが存在しない場合は、すなわち該当クラスがインスタンス化されないと判断できる。また、生成オペレーション以外のアクション、すなわち型を参照するアクション、関数を呼び出すアクションなどは検索の対象外とする。図６の例では、インスタンス化される場合は"○"が、インスタンス化されない場合には"×"が記載されている。
【００７４】
また、図7は、本発明の第２の実施形態の詳細な実現手順を示すフローチャートであり、これは処理５０２に対応している。以下では、このフローチャートに沿って図３及び図６を例に本実施形態を説明する。
【００７５】
７０１では、既に繰り返し処理ステップＳ５０１により選択されている対象クラス（クラスＡ）を参照し、クラスＡが親クラスを保持しているかを判定する。ここで、もしクラスＡが親クラスを保持していると判定された場合にはステップＳ７０２の処理に流れ、そうでないならばステップＳ７１０の処理に流れ、クラスＡは子クラスとして統合不可能と判定される。
【００７６】
図６の例の場合には、クラスＡとして登録されるクラスがClassA、ClassB、SuperClassの場合には親クラスを保持していないと判定されステップＳ７１０の処理に流れ、SubClassの場合には親クラスを保持していると判定され、ステップＳ７０２以降の処理に流れる。
【００７７】
ステップＳ７０２では、クラスＡが保持している親クラスを親クラスＢとして登録する。図６の場合には、クラスＡにSubClassが登録されている場合には、親クラスＢとしてSuperClassが登録される。
【００７８】
ステップＳ７０３では、以降のステップＳ７０４〜ステップＳ７０７の処理をモデル情報に格納されているクラス情報の行数より自身の行を抜いた数だけ繰り返す。図６の具体例では、登録されているクラス情報の全行数は４のため、繰り返し数は３となる。
【００７９】
ステップＳ７０４では、モデル情報より新たなクラスを取り出し、これをクラスＣとして登録する。図６の例では、最初の行に登録されているクラス情報であるClassAが抜き出されたとして、以降の処理を説明する。
【００８０】
ステップＳ７０５では、ステップＳ７０４で登録されたクラスＣが親クラスを保持しているかを判定する。ここで、もしクラスＣが親クラスを保持していると判定された場合にはステップＳ７０６の処理に流れ、そうでないならばステップＳ７０７の処理に流れ、ステップＳ７０３以降の処理を繰り返す。図６の例では、クラスＣとしてClassAが抜き出されていた場合、親クラスを保持していないと判定され、ステップＳ７０７の処理に流れる。
【００８１】
ステップＳ７０６では、クラスＣが保持している親クラスが、ステップＳ７０２で登録された親クラスＢと一致するかを判定する。ここで、もし一致した場合には、親クラスＢに対しクラスＡの他に別の子クラス（クラスＣ）が存在することとなり、親子クラスを統合可能な１親クラス１子クラスの関係ではないと判定されてステップＳ７１０の処理に流れる。一致しなかった場合にはステップＳ７０７の処理に流れ、ステップＳ７０３以降の処理を繰り返す。
【００８２】
ステップＳ７０８では、親クラスＢに登録されているクラスのモデル情報より、親クラスＢがインスタンス化の可能性があるかを判定する。ここで、親クラスＢのインスタンス化の可能性がある場合には、システム上親クラスＢのインスタンスとクラスＡのインスタンスが異なるインスタンスとして共存することを意味し、これらの２つのクラスを統合することは不可能と判定してステップＳ７１０の処理に流れ、そうでないならばステップＳ７０９の処理に流れる。図６の例では、親クラスＢに登録されたSuperClassがインスタンスの可能性がないため、ステップＳ７０９の処理に流れる。
【００８３】
ステップＳ７０９では、統合可能と判定された子クラスＡ及び親クラスＢの情報を保持したまま、ステップＳ７１１に示すEXIT（１）により本判定処理を抜け、以降クラスの統合処理ステップＳ５０３に戻り処理が続行される。
【００８４】
ステップＳ７１０では、クラスＡは子クラスとして統合不可能であるという判定結果を基に、ステップＳ７１１に示すEXIT（２）により本判定処理を抜け、以降ステップＳ５０５に戻り繰り返し処理が続行される。
【００８５】
以上の処理によって、ユーザにより入力されたモデル情報の中で、特に保持する親クラスの情報とインスタンス化可能性の有無に関する情報より、統合可能な１対の子クラスと親クラスが自動的に選択される。
【００８６】
また、図８はユーザが入力したモデル図面の異なる一例を示している。図中、８０２及び８０３の各クラスは、それぞれ親クラス８０１を継承する子クラスとして定義されている。
【００８７】
さらに図９は、図８に示したユーザが入力したモデル図面より格納されたモデル情報を示している。ここで、９０１及び９０２の各行は、それぞれ図８上の８０２及び８０３のクラス情報に対応している。このモデル情報を基に本発明の第２の実施形態を実施した場合、モデル図上にSubClassAとSuperClass、SubClassBとSuperClassという２つの継承関係は存在するものの、どちらの子クラスも共通の親クラスを保持しており、統合可能と判定される親クラスと子クラスの対は発見されない。
【００８８】
−第３の実施形態−
次に、本発明の第３の実施形態について説明する。
図１０は、本発明の第３の実施形態の詳細な実現手順を示すフローチャートであり、これは処理ステップＳ５０３に対応している。以下では、このフローチャートに沿って図３を例に実施形態を説明する。
【００８９】
ステップＳ１００１では、既にステップＳ５０２により統合可能と判定されている１対の親クラスＢと子クラスＡの属性、関数の統合処理を行う。
【００９０】
ステップＳ１００２では、上記１対の親クラスＢと子クラスＡに定義されている状態図の統合処理を行う。
【００９１】
ステップＳ１００３では、上記１対の親クラスＢと子クラスＡの統合後の名前を決定し、新クラス名への変更処理を行う。
【００９２】
また、図１１は、統合可能な１対の親クラスＢと子クラスＡの属性・関数の統合処理の詳細を示すフローチャートであり、これは処理ステップＳ１００１に対応している。以下では、このフローチャートに沿って図３にて統合可能な子クラスＡにSubClassが、親クラスＢにSuperClassが選択された場合を例に実施例を説明する。
【００９３】
ステップＳ１１０１では、以降のステップＳ１１０２〜ステップＳ１１０３の処理をモデル情報に格納されている子クラスＡに定義されている属性数だけ繰り返す。図３の具体例では、SubClassが保持する属性情報は１つのため、繰り返し数は１となる。
【００９４】
ステップＳ１１０２では、子クラスＡに定義されている属性情報を親クラスＢに移動する。図３の具体例では、SubClassが保持する属性情報であるattS3に関する情報が親クラスＢとして登録されているSuperClassに移動される。
【００９５】
ステップＳ１１０４では、以降のステップＳ１１０５〜ステップＳ１１０６の処理をモデル情報に格納されている子クラスＡに定義されている通常関連数だけ繰り返す。図３の具体例では、SubClassは継承関連以外の関連を保持していないため、本繰り返し作業は行われない。
【００９６】
ステップＳ１１０５では、子クラスＡに定義されている通常関連情報を親クラスに移動する。
【００９７】
ステップＳ１１０７では、以降のステップＳ１１０８〜ステップＳ１１１４の処理をモデル情報に格納されている子クラスＡに定義されている関数数だけ繰り返す。図３の具体例では、SubClassが保持する関数情報は２つのため、繰り返し数は２となる。
【００９８】
ステップＳ１１０８では、子クラスＡに定義されている関数から新たな関数を抜き出し、これを関数Ａとする。図３の具体例では、SubClassが保持する関数情報のうち、opeS1が抜き出されたとして、以降の説明を進める。
【００９９】
ステップＳ１１０９では、関数Ａと同名、同じ引数の関数が親クラスＢに定義されているかを判別する。ここで、もしも親クラスにて関数Ａが定義されていた場合にはステップＳ１１１０の処理に流れ、そうでない場合には関数Ａは子クラスのみで定義された関数であると判断し、ステップＳ１１１３の処理に流れる。図３の具体例では、SubClassが保持する関数情報のうち、opeS1が抜き出された場合には、これと同じ定義がSuperClassにも存在するため、ステップＳ１１１０の処理に流れる。
【０１００】
ステップＳ１１１０では、ステップＳ１１０９で発見された親クラスＢ上の関数Ａと同名、同じ引数の関数にアクション記述が含まれるかを判別する。ここで、もしもアクション記述が含まれる場合には、親クラスＢ上に定義されていた関数が子クラスＡによってオーバーライド（関数の上書き）されているものと判断し、ステップＳ１１１１の処理に流れる。そうでないならば、親クラスＢ上に定義された関数は、単にインタフェースの定義のみを目的としたものであったと判別し、ステップＳ１１１３の処理に流れる。
【０１０１】
ステップＳ１１１１では、親クラスＢに定義され、子クラスによってオーバーライドされている関数Ａに対し、新たに親クラスＢ内でユニークな関数名Ｂを割り当てる。この処理により、親子クラスの統合処理によって、親クラスの関数Ａに記述されたアクションが損なわれないことを保証する。
【０１０２】
ステップＳ１１１２では、モデル情報格納部２０２に格納されているモデル情報について親クラスの関数Ａが呼び出されている全てのアクションを、ステップＳ１１１１の処理にて決定した関数名を用いて親クラスの関数Ｂが呼び出されるアクションに変更する。ステップＳ１１１１及びステップＳ１１１２の処理によって、オーバーライドされている親クラス内の関数の退避を完了する。
【０１０３】
ステップＳ１１１３では、子クラスＡに定義されている関数Ａの情報を親クラスＢに移動する。
【０１０４】
以上の処理により、統合可能な１対の親クラスＢと子クラスＡの属性・関数の統合処理が完了する。
【０１０５】
また、図１２は、統合可能な１対の親クラスＢと子クラスＡの状態の統合処理の詳細を示すフローチャートであり、これは処理ステップＳ１００２に対応している。以下では、このフローチャートに沿って状態図情報の統合について説明を加える。
【０１０６】
ステップＳ１２０１では、子クラスＡに状態図が定義されているかを判別する。ここで、もしも状態図が定義されている場合にはステップＳ１２０２の処理に流れ、そうでないならば、EXITに流れ、状態図情報の統合処理を完了する。ステップＳ１２０２では、子クラスＡの状態図定義を親クラスＢに移す。
【０１０７】
以上の処理により、例えば統合される親クラスＢ、子クラスＡ共に状態図が定義されている場合には子クラスＡの状態図が統合後クラスの状態図として新たに定義され、親クラスBのみ状態図が定義されている場合にはその定義がそのまま統合後クラスの状態図として利用される。これは、親子関係にあるクラスのインスタンスを作成する際のＵＭＬの定義に準ずる。
【０１０８】
また、図１３は統合可能な１対の親クラスＢと子クラスＡを統合する際の、統合後のクラスへの新クラス名の付加およびその変更処理を示すフローチャートであり、これは処理ステップＳ１００３に対応している。以下では、このフローチャートに沿って新クラス名への変更処理について説明を加える。
【０１０９】
ステップＳ１３０１では、子クラスＡの定義をモデル情報より削除する。この処理により、モデル情報上のクラス定義が減少する。
【０１１０】
ステップＳ１３０２では、入力インタフェース１０５及び入力装置１０６を用いてユーザによる統合クラスの"新クラス名"の入力を受け付ける。図３に示した例では、ここで"新クラス名"として親クラスＢと同一のクラス名が指定されたとして、以下の処理を説明する。
【０１１１】
ステップＳ１３０３では、１３０２により取得した新クラス名が親クラスＢのクラス名の定義と等しいかを判別する。ここで、もしもクラス名の定義が等しい場合にはステップＳ１３０６の処理に流れ、そうでない場合にはステップＳ１３０４の処理に流れる。図３に示した例では、新クラス名と親クラス名が等しいため、処理ステップＳ１３０６に流れる。
【０１１２】
ステップＳ１３０４では、全てのモデル情報、アクション中に記述の"親クラスＢ"を"新クラス名"に変更する。ここで変更されるアクション記述は、親クラスＢの型を参照するアクション、親クラスＢに定義されている関数を呼び出すアクションなど、親クラスＢに関る全てのアクションが対象となる。
【０１１３】
ステップＳ１３０５では、ステップＳ１３０２により取得した新クラス名が子クラスＡのクラス名の定義と等しいかを判別する。ここで、もしもクラス名の定義が等しい場合にはEXITに流れ処理を終了し、そうでない場合にはステップＳ１３０６の処理に流れる。
【０１１４】
ステップＳ１３０６では、全てのモデル情報、アクション中に記述の"子クラスＡ"を"新クラス名"に変更する。ここで変更されるアクション記述は、子クラスＡの型を参照するアクション、子クラスＡに定義されている関数を呼び出すアクションなど、子クラスＡに関る全てのアクションが対象となる。
【０１１５】
以上の処理によって、統合すべき１対の親クラスと子クラスの定義が統合され、これらの処理によって生成、統合後モデル情報格納部２１０に記憶されたクラス結合結果情報については、実行時のＲＯＭ容量が削減されるソースコードの自動生成に用いられる。
【０１１６】
−第４の実施形態−
次に、本発明の第４の実施形態について説明する。
図１４は、本発明の第４の実施形態の実現手順を示すフローチャートである。以下では、このフローチャートに沿って本実施形態を説明する。
【０１１７】
ステップＳ１４０１では、モデル図面入力部２０１によりユーザがモデル図面を入力する。
【０１１８】
ステップＳ１４０２では、ステップＳ１４０１により入力されたモデル情報をオブジェクト指向プログラム生成装置上に記憶する。
【０１１９】
ステップＳ１４０３では、モデル図面の入力が終了したかをユーザからの入力により判定する。具体的には、ユーザの直前の入力がプログラムの自動生成開始命令であるなど、モデル図面の入力終了を表す情報に相当した場合、モデル図面の入力が終了したと判定する。ここでモデル図面の入力が終了したと判定された場合にはステップＳ１４０４の処理に流れ、そうでないならばステップＳ１４０１の処理に戻る。
【０１２０】
ステップＳ１４０４では、プログラム自動生成方法選択部２１２により、クラスの統合処理を実行し、その結果統合後モデル情報格納部２１０に格納される統合後モデル情報を用いてプログラムを自動生成するのか、もしくは、統合処理を行わず、モデル情報格納部２０２に記憶されている情報を用いてプログラムを自動生成するのかをユーザが選択する。
【０１２１】
ステップＳ１４０５では、ステップＳ１４０４の処理によってクラス図の統合の実行が選択されたかを判定する。ここで、選択されたと判定された場合にはステップＳ１４０６の処理に流れ、選択されなかったと判定された場合にはステップＳ１４１０の処理に流れる。
【０１２２】
ステップＳ１４０６では、ステップＳ１４０２の処理によって格納されたモデル情報を基に、統合可能なクラスの選択を行い、さらに選択されたクラスに対しクラスの統合を実行し、その実行結果は統合後モデル情報格納部２１０に記憶される。
【０１２３】
ステップＳ１４０７では、表示モデル図面選択部２１１によって、モデル情報格納部２０２に記憶されたモデル情報を基に表示モデル図面を生成するのか、もしくは統合後モデル情報格納部２１０に記憶された統合後モデル情報を基に表示モデル図面を生成するのかの選択が行われる。
【０１２４】
ステップＳ１４０８では、ステップＳ１４０７によって選択されたモデル情報がクラス統合後モデル情報であるかを判定する。ここで、クラス統合後モデル情報であると判定された場合にはステップＳ１４０９の処理に流れ、そうでない場合にはステップＳ１４１０の処理に流れる。
【０１２５】
ステップＳ１４０９では、表示モデル図面生成部２０３により、統合後モデル情報格納部２１０に記憶された統合後モデル情報を基に表示モデルが生成される。また、ステップＳ１４１０では、同じく表示モデル図面生成部２０３により、モデル情報格納部２０２に記憶された統合後モデル情報を基に表示モデルが生成される。
【０１２６】
ステップＳ１４１１では、ステップＳ１４０９又はステップＳ１４１０の処理により生成された表示モデルが、出力インタフェース１０７及び表示媒体１０８を用いてユーザに表示される。
【０１２７】
以上の処理によって、上記モデル情報格納部２０２によって記憶されたユーザによって入力されたモデル情報と、同じく上記統合後モデル情報格納部２１０に記憶されたクラス統合後情報とを、ユーザが任意に選択して表示可能とすることが可能となる。
【０１２８】
−第５の実施形態−
次に、本発明の第５の実施形態について説明する。
図１５は、本発明の第５の実施形態の実現手順を示すフローチャートである。以下では、このフローチャートに沿って本実施形態を説明する。
【０１２９】
ステップＳ１５０１では、モデル図面入力部２０１によりユーザがモデル図面を入力する。
【０１３０】
ステップＳ１５０２では、ステップＳ１５０１により入力されたモデル情報をオブジェクト指向プログラム生成装置上に記憶する。
【０１３１】
ステップＳ１５０３では、モデル図面の入力が終了したかをユーザからの入力により判定する。具体的には、ユーザの直前の入力がプログラムの自動生成開始命令であるなど、モデル図面の入力終了を表す情報に相当した場合、モデル図面の入力が終了したと判定する。ここでモデル図面の入力が終了したと判定された場合にはステップＳ１５０４の処理に流れ、そうでないならばステップＳ１５０１の処理に戻る。
【０１３２】
ステップＳ１５０４では、プログラム自動生成方法選択部２１２により、クラスの統合処理を実行し、その結果を用いてプログラムを自動生成するのか、もしくは、統合処理を行わず、モデル情報格納部２０２に記憶されている情報を用いてプログラムを自動生成するのかをユーザが選択する。
【０１３３】
ステップＳ１５０５では、ステップＳ１５０４の処理によってクラス図の統合の実行が選択されたかを判定する。ここで、選択されたと判定された場合にはステップＳ１５０６の処理に流れ、選択されなかったと判定された場合にはステップＳ１５０８の処理に流れる。
【０１３４】
ステップＳ１５０６では、ステップＳ１５０２の処理によって格納されたモデル情報を基に、統合可能なクラスの選択を行い、さらに選択されたクラスに対しクラスの統合を実行する。
【０１３５】
ステップＳ１５０７では、ステップＳ１５０６の処理により生成されたクラス統合情報を基に、プログラム自動生成部２０５によりプログラムの自動生成が行われる。
【０１３６】
ステップＳ１５０８では、ステップＳ１５０２の処理によりオブジェクト指向プログラム生成装置内に記憶されたモデル情報を基に、プログラム自動生成部２０５によりプログラムの自動生成が行われる。
【０１３７】
ステップＳ１５０９では、ステップＳ１５０７の処理もしくはステップＳ１５０８の処理により自動生成されたプログラムを、出力装置に表示する。
【０１３８】
以上の処理によって、プログラムを自動生成する際に元とするモデル情報として、上記モデル情報格納部２０２によって記憶されたユーザによって入力されたモデル情報と、同じく上記統合後モデル情報格納部２１０に記憶されたクラス統合後情報とを、ユーザが任意に選択して利用することが可能となる。
【０１３９】
−第６の実施形態−
次に、本発明の第６の実施形態について説明する。
図１６は、本発明の第６の実施形態の実現手順を示すフローチャートである。また、図１７は、本実施形態の実現手順に基づき親子クラスの統合処理が行われた具体例を示したものである。以下では、図１６に示すフローチャートに沿って、図１７を例に本実施形態を説明する。
【０１４０】
ステップＳ１６０１では、モデル図面入力部２０１によりユーザがモデル図面を入力する。
【０１４１】
ステップＳ１６０２では、ステップＳ１６０１により入力されたモデル情報をオブジェクト指向プログラム生成装置上に記憶する。
【０１４２】
ステップＳ１６０３では、モデル図面の入力が終了したかをユーザからの入力により判定する。具体的には、ユーザの直前の入力がプログラムの自動生成開始命令であるなど、モデル図面の入力終了を表す情報に相当した場合、モデル図面の入力が終了したと判定する。ここでモデル図面の入力が終了したと判定された場合にはステップＳ１６０４の処理に流れ、そうでないならばステップＳ１６０１の処理に戻る。図１７の例では、図面の入力が終了したと判定された時点で、１７０１のクラス情報が入力され、それに対応して１７０２のモデル情報がモデル情報格納部２０２に記憶されたものとして、以下の説明を続ける。
【０１４３】
ステップＳ１６０４では、対象クラス限定部２１３によってユーザの入力を受け付け、ソースコードの自動生成の対象とするクラスを限定する。ここで例えばモデル情報格納部２０２に格納されているモデル情報が系列製品群を１つのクラス図で表現しているようなモデル情報である場合、その中から単一の製品を特定することにより、他製品に固有のクラスは今回のソースコードの自動生成の対象から除外される。図１７の例では、今回対象とする製品ではClassA、ClassB、SuperClass、SubClasAのみにソースコードの自動生成の対象とするクラスが限定されたとする。
【０１４４】
ステップＳ１６０５では、ステップＳ１６０４によって入力された情報より、今回のソースコードの自動生成の対象から除外されたクラスを特定し、このクラスに関係する情報をモデル情報格納部２０２に記憶されている情報から削除し、これを新たにサブセットモデル情報格納部２１４に格納する。図１７の例では、今回対象とする製品ではSubClassBがソースコードの自動生成の対象から除外され、その結果、１７０４に示すモデル情報がサブセットモデル情報格納部２１４に記憶される。
【０１４５】
ステップＳ１６０６では、ステップＳ１６０５の処理によって格納されたサブセットモデル情報を基に、統合可能な親子クラスの選択を行い、さらに選択されたクラスに対しクラスの統合を実行する。
【０１４６】
図１７の例では、統合可能な１対の親子クラスとしてSuperClassとSubClassAが選択され、これを統合して新たにSuperClassとすることで、１７０５に示す新たなクラス構造と、１７０６に示すモデル情報が得られ、統合後モデル情報格納部２１０に記憶される。
【０１４７】
ステップＳ１６０７では、ステップＳ１６０６の処理により生成され、統合後モデル情報格納部210に記憶されたクラス統合情報を基に、プログラム自動生成部２０５によりプログラムの自動生成が行われる。
【０１４８】
ステップＳ１６０８では、ステップＳ１６０７の処理により自動生成されたプログラムを、出力装置に表示する。
【０１４９】
以上の処理によって、例えば系列製品群に対応するクラス図を基にさらに特定の製品に限定することでサブセット化されたクラス図を参照可能な構成とし、上記ＲＯＭ容量削減手段を多製品開発にも対応可能とした。
【０１５０】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体をシステム或いは装置に供給し、そのシステム等のコンピュータが記憶媒体からプログラムコードを読み出し実行することによっても達成される。
【０１５１】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１５２】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０１５３】
また、コンピュータが読み出したプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１５４】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに接続された機能拡張ユニット等に備わるメモリに書込まれた後、そのプログラムコードの指示に基づきＣＰＵ等が実際の処理を行い、前述した実施形態の機能が実現される場合も含まれる。
【図面の簡単な説明】
【０１５５】
【図１】本発明の実施形態に係るオブジェクト指向プログラム生成装置の機器構成図である。
【図２】本発明の実施形態に係るオブジェクト指向プログラム生成装置の全体構成を示すブロック図である。
【図３】本発明の実施形態に係るオブジェクト指向プログラム生成装置における親子クラスの統合の実行例を説明するための図である。
【図４】本発明の第１の実施形態の実現手順を示すフローチャートである。
【図５】本発明の第1の実施形態の中で、特に統合可能な親子クラスの選択とクラスの統合に係る詳細な実現手順を示すフローチャートである。
【図６】本発明の第２の実施形態に係る、クラスが保持する親クラス情報およびインスタンス化情報の保持例を示した図である。
【図７】本発明の第２の実施形態の実現手順を示すフローチャートである。
【図８】本発明の第２の実施形態に係る、ユーザが入力したモデル図面の一例を示す図である。
【図９】本発明の第２の実施形態に係る、クラスが保持する親クラス情報の保持例を示した図である。
【図１０】本発明の第３の実施形態の実現手順を示すフローチャートである。
【図１１】本発明の第３の実施形態の中で、特に属性・関連・関数の統合処理の詳細な実現手順を示すフローチャートである。
【図１２】本発明の第３の実施形態の中で、特に状態図情報の統合処理の詳細な実現手順を示すフローチャートである。
【図１３】本発明の第３の実施形態の中で、特に新クラス名への変更処理の詳細な実現手順を示すフローチャートである。
【図１４】本発明の第４の実施形態の実現手順を示すフローチャートである。
【図１５】本発明の第５の実施形態の実現手順を示すフローチャートである。
【図１６】本発明の第６の実施形態の実現手順を示すフローチャートである。
【図１７】本発明の第６の実施形態に係る、親子クラスの統合の実行例を説明するための図である。
【符号の説明】
【０１５６】
２０１  モデル図面入力部
２０２  モデル情報格納部
２０３  表示モデル図面生成部
２０４  モデル図面表示部
２０５  プログラム自動生成部
２０６  プログラム格納部
２０７  プログラム表示部
２０８  統合親子クラス選択部
２０９  クラス統合部
２１０  統合後モデル情報格納部
２１１  表示モデル図面選択部
２１２  プログラム自動生成方法選択部
２１３  対象クラス限定部
２１４  サブセットモデル情報格納部
【図１】
2007280138.tif 000003
【図２】
2007280138.tif 000004
【図３】
2007280138.tif 000005
【図４】
2007280138.tif 000006
【図５】
2007280138.tif 000007
【図６】
2007280138.tif 000008
【図７】
2007280138.tif 000009
【図８】
2007280138.tif 000010
【図９】
2007280138.tif 000011
【図１０】
2007280138.tif 000012
【図１１】
2007280138.tif 000013
【図１２】
2007280138.tif 000014
【図１３】
2007280138.tif 000015
【図１４】
2007280138.tif 000016
【図１５】
2007280138.tif 000017
【図１６】
2007280138.tif 000018
【図１７】
2007280138.tif 000019
【手続補正書】
【提出日】平成18年4月27日(2006.4.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ソフトウェアの構造を表現するモデル図面をユーザが記述・編集可能とするモデル図面入力手段と、前記モデル図面入力手段によって入力されたモデル情報を記憶するモデル情報格納手段と、前記モデル情報格納手段によって格納された情報を基に表示するモデル図面を生成する表示モデル図面生成手段と、前期表示モデル図面生成手段によって生成されたモデル図面情報を基に図面を表示するモデル図面表示手段と、前記モデル情報格納手段によって記憶されたモデル情報を基にプログラムを自動生成するプログラム自動生成手段と、前記プログラム自動生成手段によって生成されたプログラムを記憶するプログラム格納手段と、前記プログラム格納手段によって記憶されたプログラムを表示するプログラム表示手段とを有するオブジェクト指向プログラム生成装置において、
前記モデル図面情報から、継承関係にあり、且つ統合可能な１つの親クラスと１つの子クラスの対を選択する統合親子クラス選択手段と、
前記統合親子クラス選択手段によって選択された１対の親クラスと子クラスを１つのクラスに統合するクラス統合手段と、
前記クラス統合手段によって統合された結果を記憶する統合後モデル情報格納手段とを具備し、
前記プログラム自動生成手段においては統合後モデル情報格納手段によって記憶された統合後モデル情報を基にプログラムを自動生成することを特徴とするオブジェクト指向プログラム生成装置。
【請求項２】
前記モデル情報格納手段では、クラス間の関連情報として各クラスが継承する親クラスの情報及びインスタンス化の有無に関する情報を持ち、前記統合親子クラス選択手段では、上記クラスごとに保持される親クラスの情報より、１つの親クラスに対し１つの子クラスのみ継承関係が定義され、なおかつ親クラスのインスタンス化が行われない親クラスと子クラスの対を自動的に選択することを特徴とする請求項１に記載のオブジェクト指向プログラム生成装置。
【請求項３】
前記クラス統合手段では、新たに統合されるクラスは統合前の親クラスと子クラスの定義のマージにより表現されることを特徴とし、新たに統合されるクラスのクラス名については、統合前の親クラスもしくは子クラスのクラス名、もしくはユーザによって新たに定義されるクラス名を選択的に命名可能とすることを特徴とする請求項１又は２に記載のオブジェクト指向プログラム生成装置。
【請求項４】
前記モデル情報格納手段によって記憶されたモデル情報と、前記統合後モデル情報格納手段に記憶された親子クラス統合後モデル情報とを、ユーザが任意に選択して表示可能とする表示モデル図面選択手段を有することを特徴とする請求項１乃至３の何れか１項に記載のオブジェクト指向プログラム生成装置。
【請求項５】
前記プログラム自動生成手段が基にするモデル情報として、前記モデル情報格納手段によって記憶されたモデル情報、もしくは前記統合後モデル情報格納手段に記憶されたクラス統合後情報をユーザが任意に選択して利用可能とするプログラム自動生成方法選択手段を有することを特徴とする請求項１乃至４の何れか１項に記載のオブジェクト指向プログラム生成装置。
【請求項６】
前記モデル情報格納手段によって記憶されるモデル情報からプログラム自動生成の対象とするクラスを限定する対象クラス限定手段と、
前記対象クラス限定手段により限定されたモデル情報を格納するサブセットモデル情報格納手段とを有し、
前記統合親子クラス選択手段が前記サブセットモデル情報格納手段によって格納されたサブセットモデル情報格納情報を参照することを特徴とする請求項１乃至５の何れか１項に記載のオブジェクト指向プログラム生成装置。
【請求項７】
モデル図面情報から、継承関係にあり、かつ統合可能な１つの親クラスと１つの子クラスの対を選択する統合親子クラス選択ステップと、
前記統合親子クラス選択ステップによって選択された１対の親クラスと子クラスを１つのクラスに統合するクラス統合ステップと、
前記クラス統合ステップによって統合された結果を記憶する統合後モデル情報格納ステップとを具備し、
統合後モデル情報格納ステップによって統合されたモデル情報に基づいてプログラムを自動生成することを特徴とするオブジェクト指向プログラム生成方法。
【請求項８】
請求項７に記載のオブジェクト指向プログラム生成方法をコンピュータに実行させるためのプログラム。