(57)【要約】【課題】  オブジェクト指向プログラミング生成装置において、可読性、保守性を維持しつつ、生成されるプログラムが必要とするメモリ容量の削減と実行速度の向上を図る。【解決手段】  ソフトウェアの構造を表現するモデル情報に基づいて、オブジェクト指向プログラミングを実行するオブジェクト指向プログラミング生成装置であって、前記モデル情報を記憶するモデル情報格納部２０２と、前記モデル図情報から統合可能なクラスを統合するクラス統合部２０８と、クラス統合部２０８においてクラスが統合された前記モデル情報に基づいてプログラムを生成するクラス統合後プログラム自動生成部２１１と、クラス統合後プログラム自動生成部２１１において生成されたプログラムを表示するプログラム表示部２０８と、を備える。【選択図】  図２
2006343867.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアの構造を表現するモデル情報に基づいて、オブジェクト指向プログラミングを実行するオブジェクト指向プログラミング生成装置であって、
前記モデル情報を記憶するモデル情報記憶手段と、
前記モデル情報から統合可能なクラスを統合するクラス統合手段と、
前記クラス統合手段においてクラスが統合された前記モデル情報に基づいてオブジェクト指向によるプログラムを生成するクラス統合後プログラム生成手段と、
前記クラス統合後プログラム生成手段において生成されたプログラムを表示するプログラム表示手段と
を備えることを特徴とするオブジェクト指向プログラミング生成装置。
【請求項２】
前記モデル情報記憶手段により記憶された前記モデル情報を表示するモデル情報表示手段を更に備えることを特徴とする請求項１に記載のオブジェクト指向プログラミング生成装置。
【請求項３】
前記モデル情報記憶手段により記憶された前記モデル情報に基づいてオブジェクト指向によるプログラムを生成するプログラム生成手段と、
ユーザからの指示に基づいて、前記統合するクラス統合手段と前記プログラム生成手段とを切り替えて実行させ、前記プログラムを生成することを特徴とする請求項１に記載のオブジェクト指向プログラミング生成装置。
【請求項４】
前記クラス統合手段は、
クラス間の関連情報と多重度情報とに基づいてクラスの統合可否を判定することを特徴とする請求項１に記載のオブジェクト指向プログラミング生成装置。
【請求項５】
前記クラス統合手段において統合されるクラスが、状態図を有する能動クラス同士であった場合に、該クラスが各々有する状態図を統合する状態図統合手段を更に備えることを特徴とする請求項１に記載のオブジェクト指向プログラミング生成装置。
【請求項６】
ソフトウェアの構造を表現するモデル情報に基づいて、オブジェクト指向プログラミングを実行するオブジェクト指向プログラミング生成装置における情報処理方法であって、
前記モデル情報を記憶手段に記憶するモデル情報記憶工程と、
前記モデル情報から統合可能なクラスを統合するクラス統合工程と、
前記クラス統合工程においてクラスが統合された前記モデル情報に基づいてオブジェクト指向によるプログラムを生成するクラス統合後プログラム生成工程と、
前記クラス統合後プログラム生成工程において生成されたプログラムを表示するプログラム表示工程と
を備えることを特徴とする情報処理方法。
【請求項７】
前記モデル情報記憶工程により前記記憶手段に記憶された前記モデル情報を表示するモデル情報表示工程を更に備えることを特徴とする請求項６に記載の情報処理方法。
【請求項８】
前記モデル情報記憶工程により前記記憶手段に記憶された前記モデル情報に基づいてオブジェクト指向によるプログラムを生成するプログラム生成工程と、
ユーザからの指示に基づいて、前記統合するクラス統合工程と前記プログラム生成工程とを切り替えて実行させ、前記プログラムを生成することを特徴とする請求項６に記載の情報処理方法。
【請求項９】
前記クラス統合工程は、
クラス間の関連情報と多重度情報とに基づいてクラスの統合可否を判定することを特徴とする請求項６に記載の情報処理方法。
【請求項１０】
前記クラス統合工程において統合されるクラスが、状態図を有する能動クラス同士であった場合に、該クラスが各々有する状態図を統合する状態図統合工程を更に備えることを特徴とする請求項６に記載の情報処理方法。
【請求項１１】
請求項６乃至１０のいずれか１項に記載の情報処理方法をコンピュータによって実現させるための制御プログラムを格納した記憶媒体。
【請求項１２】
請求項６乃至１０のいずれか１項に記載の情報処理方法をコンピュータによって実現させるための制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オブジェクト指向分析・設計手法を用いて設計されたソフトウェア図面よりプログラムの自動生成を行うオブジェクト指向プログラミング生成装置に関するものである。
【背景技術】
【０００２】
近年、ソフトウェア分析設計手法の一つとしてオブジェクト指向分析設計が普及している。ここで、オブジェクト指向分析設計とは、現実世界の実体をオブジェクトとして抽出し、このオブジェクトを単位としてシステムを構成していく開発手法である。
【０００３】
オブジェクト指向分析設計の開発手法においては、同種類のオブジェクトを抽象化したものを「クラス」と呼び、抽出されたクラス間の構造を表現するために「クラス図」を記述する。また、クラスはそれぞれ役割を持ち、クラスが保持する内部データを記述するための「属性」や、クラスへの操作を表す「関数」が定義される。
【０００４】
さらに、システム全体ではクラス間で処理の依頼を行ない互いに協調し合って１つの大きな処理を実現する。この際の、あるクラスから他のクラスへの処理の依頼を「メッセージ」と呼び、さらにその処理方法の違いにより「同期メッセージ」と「非同期メッセージ」とに大別される。同期メッセージは、通常の関数呼び出しに代表され、呼び出し側が処理の完了を待って次の処理に遷移するメッセージであり、一方、非同期メッセージは、通常「イベント」と称され、呼び出し側が処理の完了を待たずに次の処理を実行するため呼び出し元のオブジェクトと呼び出し先のオブジェクトとで並行処理が実現される。このようにイベントを受け取り、このイベントをトリガとして自らの状態の変化、および特定のアクションを実行するクラスを「能動クラス」と称し、この能動クラスは前記状態の変化や実行するアクションを図示するために「状態図」を保持する。一方、イベントを受け取ることがなく、状態図を持たないクラスを「受動クラス」と称す。
【０００５】
上記オブジェクト指向分析設計を用いたシステム開発を支援するために、オブジェクト指向設計支援装置が提案されている。オブジェクト指向設計支援装置とは、コンピュータなどの情報処理装置を用いて、オブジェクト指向の開発に用いられるソフトウェア設計図の作成を支援する装置である。また、上記オブジェクト指向設計支援装置においてはＵｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ（以下ＵＭＬ）と呼ばれる記法によりソフトウェア設計図面を作成する方法が主流となっている。例えば前述のクラス図、状態図もＵＭＬに基づいて記述される。
【０００６】
さらに、上記ＵＭＬに基づいて記述されたソフトウェア設計図よりプログラムを自動生成するために、オブジェクト指向プログラミング生成装置が提案されている。オブジェクト指向プログラミング生成装置では、ユーザによって記述されたモデル図面情報と、このモデル図面情報を例えばＣ、Ｃ＋＋、Ｊａｖａ（登録商標）などのプログラムに変換する変換ルールとを入力として、動作可能なプログラムを自動生成することを可能としている。
【０００７】
そして、ユーザによって記述されたモデル図面情報から、分析／設計されたソフトウェアの仕様を損なわず、かつ、よりパフォーマンスの高いプログラムを自動生成する手段として、十分実用的な手法が求められている。
【０００８】
例えば、オブジェクト指向分析設計の主旨に沿って、設計者の理解を高めるためにより詳細なクラス分割を行ったモデル図面情報を元にプログラムを自動生成した場合、生成されるプログラムの実行に必要なメモリサイズが大きくなるという問題が生じる。特に自動生成されるプログラムが機器に組込まれるものである場合には、プログラムが利用できるメモリサイズに制限がある場合が多く、この問題は深刻である。
【０００９】
また、より詳細なクラス分割を行ったモデル図面情報を元にプログラムを自動生成した場合、その実行速度が遅くなるという別の問題も生じる。この問題についても、特に生成されるプログラムが機器に組込まれるものである場合には、最適な速度の実現とタイミングの制御が製品の仕様に大きく影響することが多く、大きな問題となる。
【００１０】
このような問題に対しては、本願出願人はクラス図中に分析された複数クラスを統合し、クラス数を少なくすることにより解決することを検討している。
【００１１】
以下、プログラムの実行に必要なメモリサイズが大きくなる理由は以下のとおりである。通常、モデル図よりプログラムを自動生成する場合、１つのクラスに対し１組のソースコードファイルが生成される。この際、それぞれのソースコードには、プログラム上でクラス定義を実現するためのオーバーヘッドが存在する。
【００１２】
このメモリサイズに対するオーバーヘッドは、例えば、クラス名の宣言、コンストラクタ・デストラクタ用関数の定義、能動クラスにおける状態遷移テーブルの定義などによって発生する。これらは、生成するプログラム言語の種類やマッピング方法の違いによりその影響の大小は異なるものの、新たなクラスが定義されるたびに必要となり、その結果プログラム実行時に必要となるメモリサイズの増大を引き起こす。
【００１３】
ここで、例えば２つのクラスとしてモデル図が記述されている特定の分析部分を１つのクラスとして統合して分析／記述した場合、上記クラス定義を実現するためのオーバーヘッドが１クラス分省略され、その結果自動生成されるプログラム実行時に要するメモリサイズを小さくすることが可能となるわけである。
【００１４】
続いて、実行速度が遅くなる理由として、一般にクラスから他のクラスへ処理を依頼する場合には、クラス内で閉じた処理に比べより多くのオーバーヘッド処理時間を要することがあげられる。
【００１５】
この処理時間に対するオーバーヘッドは、クラス間の処理の依頼がイベントの送受信によって実現されている系において顕著に発生する。通常、クラス間の並行処理を実現するためにはイベントのキューイング、およびキューイングされたイベントの取り出しなどの処理が発生し、これらの処理の実現には多くの実行時間を必要とする。
【００１６】
ここで、これらのクラス間の処理の依頼をクラス内部の処理として実現できた場合には、上記のオーバーヘッド処理時間が除かれ、より高速に処理を実行することが可能となる。さらにクラス間の処理の依頼がイベントの送受信によって実現されている系については、統合によって相互に送受信していたイベントを同期メッセージ（関数呼び出し）に置き換えることが可能となり、処理時間の大幅な短縮が実現される。
【００１７】
このように、クラス図中に分析するクラス数を少なくすることにより、自動生成されるプログラムのサイズを小さくする、または実行速度の向上を実現することが可能である。
【００１８】
一方、本願出願人が検討している上記解決策に類似する先行技術として、例えば、特開平０９−１４６７６６号公報が挙げられる。
【００１９】
具体的には、「クラス構造変更方法（特開平０９−１４６７６６）」では、クラスコード解析情報を利用して既存クラスの構造を変更する方法が提案されている。さらに、当該「プログラム生成装置（特開平０９−１４６７６６）」では、サイズの小さなプログラムの生成装置を提供する手法が提案されている。
【特許文献１】特開平０９−１４６７６６号公報
【発明の開示】
【発明が解決しようとする課題】
【００２０】
しかしながら、上記先行技術の場合、複数のクラスの統合に関する手法が提案されてはいるものの、クラス図の等価変換の目的はモデル図面の保守性の向上のみであり、その結果得られるモデル図面より自動生成されるプログラムはパフォーマンスの向上を目的としたものではない。
【００２１】
また、上記先行技術の場合、例えば複数のクラスに共通の属性や関数を抽出して上位の抽象クラスを生成するなど、モデル図面の洗練化作業を支援することが目的であり、前記装置同様にその結果得られるモデル図面より自動生成されるプログラムのパフォーマンスについては言及されていない。さらに、同文献の場合、ある特定のクラスの状態遷移情報のみを読み込み、それを縮約化手段により類似する複数の状態を１つの状態に縮約化し、自動生成されるプログラムのサイズを小さくする手法について提案してはいるものの、責務の異なる複数のクラスおよび複数の状態図を統合し、その結果を元にプログラムを自動生成することによりパフォーマンスを向上する手段については言及されていない。
【００２２】
このように、従来のオブジェクト指向プログラミング生成装置では、複数のクラスを統合し、その統合結果を用いてプログラムを自動生成することができず、上記第１及び第２の問題を解決することはできない。
【００２３】
一方、本願出願人が検討する上記解決策の場合、より少ないクラス数でクラス図を記述しようとすると、モデル図面が理解しにくいものとなってしまい、設計図面の可読性および保守性に優れるといったオブジェクト指向分析設計の最大の利点が失われるという問題を内包している。
【００２４】
本発明はこのような課題に鑑みてなされたものであり、その目的は、ユーザによって入力されたモデル図情報より統合可能な複数のクラスを抜き出し、それらを統合した結果よりプログラムを自動生成することにより、生成されるプログラムが必要とするメモリ容量の減少、および実行速度の向上を実現できるオブジェクト指向プログラミング生成装置を提供することにある。
【００２５】
また、本発明の他の目的は、ユーザに表示するモデル図に対しては、上記クラス統合結果を反映させない構成とすることにより、モデル図の可読性、保守性を維持し、オブジェクト指向分析設計のメリットを損なわない構成を実現するオブジェクト指向プログラミング生成装置を提供することにある。
【課題を解決するための手段】
【００２６】
上記の目的を達成するために本発明に係るオブジェクト指向プログラミング生成装置は以下のような構成を備える。即ち、
ソフトウェアの構造を表現するモデル情報に基づいて、オブジェクト指向プログラミングを実行するオブジェクト指向プログラミング生成装置であって、
前記モデル情報を記憶するモデル情報記憶手段と、
前記モデル情報から統合可能なクラスを統合するクラス統合手段と、
前記クラス統合手段においてクラスが統合された前記モデル情報に基づいてオブジェクト指向によるプログラムを生成するクラス統合後プログラム生成手段と、
前記クラス統合後プログラム生成手段において生成されたプログラムを表示するプログラム表示手段とを備える。
【発明の効果】
【００２７】
本発明によれば、ユーザによって入力されたモデル図情報より統合可能な複数のクラスを抜き出し、それらを統合した結果よりプログラムを自動生成することにより、生成されるプログラムが必要とするメモリ容量の減少、および実行速度の向上を実現できるオブジェクト指向プログラミング生成装置を提供することが可能となる。
【００２８】
また、本発明によれば、ユーザに表示するモデル図に対して、上記クラス統合結果を反映させない構成とすることにより、モデル図の可読性、保守性を維持し、オブジェクト指向分析設計のメリットを損なわない構成を実現するオブジェクト指向プログラミング生成装置を提供することが可能となる。
【発明を実施するための最良の形態】
【００２９】
以下、必要に応じて添付図面を参照しながら本発明の実施形態を詳細に説明する。
【００３０】
＜オブジェクト指向プログラミング生成装置の全体構成＞
図１は本実施形態にかかるオブジェクト指向プログラミング生成装置の全体構成を示す図である。図１において、１０１はＣＰＵであり、以下に説明する１０３〜１１０の装置を１０２で示すバスを介してアクセスし制御を行う。１０３はバス１０２を介してＣＰＵ１０１からアクセス可能な読み出し専用メモリ（ＲＯＭ）であり、本実施形態ではその動作を詳細に説明する処理プログラム１０３ａ及び処理プログラム１０３ａにより使用されるパラメータ１０３ｂが格納されている。
【００３１】
１０４は読み書き可能なメモリ（ＲＡＭ）であり、ＲＡＭ１０４上には、上記処理プログラム１０３ａにより作成／変更がなされるモデル情報、クラス統合結果情報、生成プログラムをそれぞれ格納するための領域（順に１０４ａ、１０４ｂ、１０４ｃ）が確保されている。
【００３２】
１０５は入力インターフェイスであり、１０６で示したキーボード、ボタン、マウス、ダイアル等の入力装置を介してなされる入力を受け取る。１０７は出力インターフェイスであり、１０８で示したＣＲＴ、ＬＣＤ等の表示媒体１０８ａ、更にはプリンタ、プロッタ等の出力装置１０８ｂに対し、データの表示／出力を行う。また、１０９は外部記憶装置インターフェイスであり、１１０で示したＨＤ、ＦＤ、ＣＤ−ＲＯＭ、ＭＤ、ＣＦ等の外部記憶装置に対するデータの入出力を行うものである。
【００３３】
＜オブジェクト指向プログラミング生成装置の機能構成＞
図２は本実施形態にかかるオブジェクト指向プログラミング生成装置の機能構成を示すブロック図である。同図において、２０１はユーザがクラス図、状態図などのモデル情報を入力するモデル図入力部であり、入力インタフェース１０５および入力装置１０６により実現される。
【００３４】
２０２はモデル図入力部２０１によって入力されたモデル図情報をオブジェクト指向プログラミング生成装置上に記憶するモデル情報格納部であり、格納されるモデル情報はバス１０２を介しＲＡＭ１０４に記憶される。
【００３５】
２０３はモデル情報格納部２０２によって記憶されたモデル情報に基づいて、ユーザに対しモデル図を表示するモデル図表示部であり、出力インタフェース１０７および表示媒体・出力装置１０８により実現される。
【００３６】
２０４はモデル情報格納部２０２に記憶されているモデル情報と、モデル情報をＣ、Ｃ＋＋、Ｊａｖａ（登録商標）などといったプログラム言語に変換するための変換ルールとを入力として、動作可能なプログラムを自動生成するプログラム自動生成部であり、この処理プログラム（１０３ａ）はＲＯＭ１０３に格納され、バス１０２を介して利用される。
【００３７】
２０５はプログラム自動生成部２０４もしくは後述のクラス統合後プログラム自動生成部２１１によって生成された生成プログラムをオブジェクト指向プログラミング生成装置上に記憶するプログラム格納部であり、格納される生成プログラムはバス１０２を介しＲＡＭ１０４に記憶される。
【００３８】
２０６はプログラム格納部２０５を介して記憶された生成プログラム１０４ｃを表示するプログラム表示部であり、出力インタフェース１０７および表示媒体・出力装置１０８により実現される。
【００３９】
２０７はモデル情報格納部２０２により記憶されたモデル情報より、統合可能なクラスを自動的に選択する統合クラス選択部であり、この処理プログラム（１０３ａ）はＲＯＭ１０３に格納され、バス１０２を介して利用される。
【００４０】
２０８は統合クラス選択部２０７によって選択されたクラスの情報と、モデル情報格納部２０２により記憶されているユーザが入力したモデル情報とに基づいて、選択された複数のクラスを１つのクラスに統合するクラス統合部であり、この処理プログラム（１０３ａ）はＲＯＭ１０３に格納され、バス１０２を介して利用される。
【００４１】
２０９は特にクラス統合部２０８によって統合される２つのクラスが共に能動クラスだった場合に、それぞれが持つ状態図の情報をマージして１つの状態図を新たに生成する状態図統合部であり、この処理プログラム（１０３ａ）はＲＯＭ１０３に格納され、バス１０２を介して利用される。
【００４２】
２１０はクラス統合部２０８によって統合された結果を記憶するクラス統合結果格納部であり、格納されるクラス統合結果情報はバス１０２を介しＲＡＭ１０４に記憶される。
【００４３】
２１１はクラス統合結果格納部２１０に記憶されているクラス統合結果情報と、モデル情報をＣ、Ｃ＋＋、Ｊａｖａ（登録商標）などといったプログラム言語に変換するための変換ルールとを入力として、動作可能なプログラムを自動生成するクラス統合後プログラム自動生成部であり、この処理プログラム（１０３ａ）はＲＯＭ１０３に格納され、バス１０２を介して利用される。
【００４４】
２１２はユーザによって入力されたモデル情報を元にプログラムを自動生成するプログラム自動生成部２０４と、クラス統合結果情報を元にプログラムを自動生成するクラス統合後プログラム自動生成部２１１とを、ユーザが任意に選択することを可能とするプログラム自動生成方法選択部であり、入力インタフェース１０５および入力装置１０６により実現される。
【００４５】
このように構成されたオブジェクト指向プログラミング生成装置において、ユーザがモデル図入力部２０１を介して入力したモデル情報は、モデル情報格納部２０２に記憶される。そして、当該モデル情報は、まず統合クラス選択部２０７によって複数のクラスが選択され、選択された複数のクラスは、クラス統合部２０８および状態図統合部２０９により統合される。
【００４６】
統合された結果（クラス統合結果情報）はクラス統合結果格納部２１０に格納され、さらにその情報を元にクラス統合後プログラム自動生成部２１１がパフォーマンスに優れるプログラムを自動生成する。自動生成されたプログラムはプログラム格納部２０５に記憶され、またプログラム表示部２０６に表示される。
【００４７】
さらに、モデル図表示部２０３に表示されるモデル図は、常にモデル情報格納部２０２に格納されているユーザによって入力されたモデル情報を元にしている。このため、換言すればクラス統合結果格納部２１０に格納されたクラス統合後のモデル情報は、本オブジェクト指向プログラミング生成装置内でのみ記憶され、上記モデル図表示部２０３に表示されるモデル図には反映されない構成となっている。この結果、モデル図の可読性、保守性を維持しつつ、オブジェクト指向分析設計のメリットを享受することが可能となっている。
【００４８】
＜クラス図の統合例＞
図１４は、クラス図の統合例を示す図である。図中、１４０１および１４０２はそれぞれモデル図入力部２０１によりユーザが入力したモデル情報のうち、統合クラス選択部２０７により統合可能と判定された１対のクラス、１４０３および１４０４はクラス統合部２０８および状態図統合部２０９により統合されたクラスである。
【００４９】
例えば１４０１に示すＣｌａｓｓＢおよびＣｌａｓｓＣが統合された場合、統合後に新たに生成されるクラス１４０３は、統合前のクラスの名前を連結したクラス名（ＣｌａｓｓＢＣｌａｓｓＣ）を持ち、定義される属性、および関数は、統合前の２つのクラスの定義をマージしたものとなる。
【００５０】
１４０２に示すＣｌａｓｓＤおよびＣｌａｓｓＦが統合された場合に関しても同様に統合されたクラス１４０４が生成される。
【００５１】
＜オブジェクト指向プログラミング生成のための手順＞
図３は、本実施形態にかかるオブジェクト指向プログラミング装置におけるプログラム生成のための手順を示すフローチャートである。以下、このフローチャートに沿って説明する。
【００５２】
ステップＳ３０１においてユーザがモデル図入力部２０１を介してモデル情報を入力すると、ステップＳ３０２において、モデル情報格納部２０２は、当該入力されたモデル情報をオブジェクト指向プログラミング生成装置上に記憶する。
【００５３】
ステップＳ３０３では、モデル情報の入力が終了したかをユーザからの入力により判断する。具体的には、ユーザの直前の入力がプログラムの自動生成開始命令であるなど、モデル情報の入力終了を表す入力に相当した場合、モデル情報の入力が終了したと判断する。ステップＳ３０３においてモデル情報の入力が終了したと判断した場合には、ステップＳ３０４に進む。一方、入力が終了していないと判断した場合にはステップＳ３０１に戻る。
【００５４】
ステップＳ３０４では、ステップＳ３０２において格納されたモデル情報に基づいて、統合クラス選択部２０７が統合可能なクラスの選択を行い、さらに選択されたクラスに対しクラス統合部２０８および状態図統合部２０９がクラスの統合を実行する。
【００５５】
ステップＳ３０５では、ステップＳ３０４において生成されたクラス統合結果情報に基づいて、プログラム自動生成部２０４がプログラムの自動生成を行う。
【００５６】
ステップＳ３０６では、ステップＳ３０５において自動生成されたプログラムを、プログラム表示部２０６が出力装置に表示する。
【００５７】
以上の処理によって、ユーザにより入力されたモデル情報を元にクラスを統合し、その統合結果を用いてパフォーマンスに優れたプログラムの自動生成が実現される。
【００５８】
＜統合可能なクラスの選択と統合処理（ステップＳ３０４）＞
図４はステップＳ３０４における、統合可能なクラスの選択と統合処理の詳細アルゴリズムを示すフローチャートである。
【００５９】
ステップＳ４０１では、以降のステップＳ４０２〜ステップＳ４０４までの処理をモデル情報格納部２０２に記憶されているモデル情報に格納されている関連情報の数だけ繰り返す。
【００６０】
ステップＳ４０２では、モデル情報格納部２０２に記憶されているモデル情報を用いて、統合クラス選択部２０７が、現在選択されているクラスが統合可能であるかを判定する。ここで、もし選択されているクラスが統合可能であると判定された場合には、ステップＳ４０３に進み、統合可能でないと判定された場合にはステップＳ４０５に進み、再度ステップＳ４０１からの処理が繰り返される。
【００６１】
ステップＳ４０３では、ステップＳ４０２において統合可能であると判定されたクラスに対し、クラス統合部２０８および状態図統合部２０９がクラスの統合を行う。ステップＳ４０４では、クラス統合結果格納部２１０が、ステップＳ４０３において統合されたモデル情報の結果（クラス統合結果情報）を格納する。
【００６２】
以上の処理によって、ユーザにより入力されたモデル情報より、統合可能なクラスが選択され、さらに選択されたクラスに対し実際の統合処理が行われる。これらの処理によって生成・記憶されたクラス統合結果情報については、パフォーマンスに優れたプログラムの自動生成に用いられる。
【００６３】
以上の説明から明らかなように、本実施形態にかかるオブジェクト指向プログラミング生成装置によれば、モデル情報から統合可能な複数のクラスを選択する統合クラス選択部と、統合クラス選択部によって選択された複数のクラスを１つのクラスに統合するクラス統合部と、クラス統合部によって生成されたクラス統合結果情報に基づいてプログラムを自動生成するクラス統合後プログラム自動生成部とを有することにより、従来のオブジェクト指向プログラミング生成装置に比べ、必要とするメモリ容量を抑え、かつ実行速度に優れたプログラムを自動生成することが可能となる。
【００６４】
さらに、ユーザに表示するモデル図については、上記クラス統合結果情報を反映させない構成とすることにより、モデル図の可読性、保守性を維持し、オブジェクト指向分析設計のメリットを享受することが可能となる。
【００６５】
本実施形態では、統合クラス選択部２０７におけるクラス統合可否の判定方法として、各クラスの多重度に応じて、クラス統合可否の判定を行う。多重度は、二つのクラス（から作られたオブジェクト）が、何対何の関係かを表すものである。
【００６６】
＜モデル情報の一例＞
図５は、本実施形態にかかるオブジェクト指向プログラミング生成装置のモデル情報格納部２０２により記憶されるモデル情報のうち、特にクラス間の関連情報の保持例を示したものである。また、この関連情報例は、図１４に示したユーザが入力したモデル情報に対応している。
【００６７】
図５において、５０１および５０３はお互いに関連するクラスの対を示しており、また５０２および５０４は該当する関連の５０１側のクラスの多重度、および５０３側のクラスの多重度を示している。
【００６８】
＜クラス統合可否の判定処理＞
図６は、本実施形態にかかるオブジェクト指向プログラミング生成装置におけるクラス統合可否判定処理の詳細な処理の流れを示すフローチャートであり、これは図４のステップＳ４０２に対応している。以下では、このフローチャートに沿って図５のモデル情報を例に説明する。
【００６９】
ステップＳ６０１では、既に繰り返し処理（ステップＳ４０１）により選択されている対象行を参照し、“クラス１”及び“クラス２”列に記載のクラスを判定対象のクラスとして登録する。図５の例では、例えば５０５に示される行が選択されている対象行の場合には、ＣｌａｓｓＡおよびＣｌａｓｓＢが判定の対象クラスとして登録される。
【００７０】
ステップＳ６０２では、上記と同じ対象行を参照し、“多重度１”が１であるかどうかを判定する。ここで、もし“多重度１”が１であると判定された場合には、ステップＳ６０３に進む。一方、“多重度１”が１でないと判定された場合にはステップＳ６０６に進み、統合不可能と判定される。図５の例では、５０５に示される行の“多重度１”は＊であるため、この時点でＣｌａｓｓＡとＣｌａｓｓＢの統合は不可能と判定される。
【００７１】
ステップＳ６０３では、上記と同じ対象行を参照し、“多重度２”が１であるかどうかを判定する。ここで、もし“多重度２”が１であると判定された場合にはステップＳ６０４に進み統合可能と判定され、“多重度２”が１でないと判定された場合には、ステップＳ６０６に進み、統合不可能と判定される。
【００７２】
ステップＳ６０４では、統合可能と判定されたクラスの情報を保持したまま、ステップＳ６０５に示すＥＸＩＴ処理により本判定処理を抜け、以降クラスの統合処理（ステップＳ４０３）に戻り処理が続行される。
【００７３】
ステップＳ６０６では、統合不可能であるという判定結果を元に、ステップＳ６０７に示すＥＸＩＴ処理により本判定処理を抜け、以降ステップＳ４０５に戻り繰り返し処理が続行される。
【００７４】
以上の処理によって、ユーザにより入力されたモデル情報の中から、特にクラス間の関連情報とその多重度の情報に基づいて判定された統合可能な２つのクラスが自動的に選択される。
【００７５】
このように、本実施形態にかかるオブジェクト指向プログラミング生成装置によれば、クラス間の関連情報とその多重度の情報とを記憶するモデル情報格納部および統合クラス選択部を有することにより、統合可能な複数のクラスを自動的に抽出することが可能となる。
【００７６】
本実施形態では、クラス統合部２０８におけるクラスの統合方法として、各クラスが能動クラスであるか否かにより、処理を切り替えている。
【００７７】
＜モデル情報の一例＞
図７は、本実施形態にかかるオブジェクト指向プログラミング生成装置のモデル情報格納部２０２により記憶されるモデル情報のうち、特にクラスのクラス種別情報の保持例を示したものである。また、このクラス種別情報例は、図１４に示したユーザが入力したモデル情報に対応している。
【００７８】
図７において、７０１はモデル図に記述されたクラス名、７０２は、それぞれのクラスのクラス種別を示す。ここで、クラス種別７０２については、該当クラスが状態図を持つか否かの違いにより、イベントを受け取り、このイベントをトリガとして自らの状態の変化、および特定のアクションを実行する、状態図を持つ能動クラスと、イベントを受け取ることがなく、状態図を持たない受動クラスとに分けられる。
【００７９】
＜クラスの統合処理＞
図８は、本実施形態にかかるオブジェクト指向プログラミング生成装置におけるクラスの統合処理の詳細な処理の流れを示すフローチャートであり、これは図４のステップＳ４０３に対応している。以下では、このフローチャートに沿って図７のモデル情報を例に説明する。
【００８０】
ステップＳ８０１では、既にステップＳ４０２により統合可能と判定されている２つのクラスのうち、どちらか一方を選択し、対象クラスとする。
【００８１】
ステップＳ８０２では、モデル情報格納部２０２に記憶されているクラス種別情報を元に、対象としているクラスが能動クラスであるかどうかを判定する。ここで、もし対象クラスが能動クラスであると判定された場合には、ステップＳ８０３に進む。一方、能動クラスではないと判定された場合にはステップＳ８０６に進む。
【００８２】
ステップＳ８０３では、既にステップＳ４０２により統合可能と判定されている２つのクラスのうち、ステップＳ８０１により選択されなかったクラスを選択し、対象クラスとする。
【００８３】
ステップＳ８０４では、ステップＳ８０２の処理と同様の手段を用いて、対象としているクラスが能動クラスであるかどうかを判定する。ここで、もし対象クラスが能動クラスと判定された場合にはステップＳ８０５に進み、能動クラスではないと判定された場合にはステップＳ８０６に進む。図７の例では、例えばステップＳ４０２により統合可能と判定されている２つのクラスがＣｌａｓｓＢおよびＣｌａｓｓＣであった場合、ステップＳ８０２およびステップＳ８０４の判定でそれぞれ能動クラスと判定されるため、ステップＳ８０５に進む。
【００８４】
ステップＳ８０５では、統合の対象となっている２つのクラスが持つ状態図を、状態図統合部２０９を用いて統合する。ステップＳ８０６では、統合の対象となっている２つのクラスのクラス定義を、クラス統合部２０８を用いて統合する。
【００８５】
以上の処理を実行することにより、能動クラス同士の統合を含めたクラスの統合処理が実現される。
【００８６】
＜状態図の統合処理の説明＞
図９は、本実施形態における状態図の統合処理の実施形態を示している。図９において、９０１はユーザによって入力された状態図例であり、図１４に示したユーザが入力したクラス図の中のＣｌａｓｓＢが持つ状態図に相当する。同様に９０２は、図１４に示したユーザが入力したクラス図の中のＣｌａｓｓＣが持つ状態図に相当する。
【００８７】
９０３および９０４は、モデル情報格納部２０２により記憶されるモデル情報のうち、特に状態図情報の保持例を示したものである。ここで、９０３はＣｌａｓｓＢが持つ状態図情報、９０４はＣｌａｓｓＣが持つ状態図情報を表している。
【００８８】
この例では、表中の列項目に状態図中で受け取ることのできるイベントが、行項目に取り得る全ての状態がそれぞれ記述され、各セルには、それぞれの状態でそれぞれのイベントを受け取った際の処理（アクション）と遷移先の状態とが記述されている。この状態図情報の保持方法は、状態遷移表とも呼ばれ、これは一般的に良く知られている状態図情報の保持方法である。
【００８９】
９０５は、ＣｌａｓｓＢの状態図情報９０３およびＣｌａｓｓＣの状態図情報９０４が状態図統合部２０９により統合され、クラス統合結果格納部２１０に記憶される統合後の状態図情報の例を示したものである。
【００９０】
９０６は、統合後の状態図情報９０５より実際に統合後の状態図を記述した例である。ただし、実際にはこの統合後の状態図９０６がモデル図表示部２０３に表示されることはなく、統合後の状態図情報９０５は、クラス統合後プログラム自動生成部２１１によりプログラムを自動生成するための情報としてのみ利用される。
【００９１】
＜状態図の統合処理の流れ＞
図１０は、状態図の統合処理（ステップＳ８０５）の詳細な実現手順を示すフローチャートである。以下では、このフローチャートに沿って図９を例に状態図の統合処理を説明する。
【００９２】
ステップＳ１００１では、モデル情報格納部２０２に記憶されている統合する２つの状態図情報を表Ａ、表Ｂとし、これに登録されている全てのイベントを抜き出し、これを統合後の状態図情報（新たに表Ｃとする）のイベント列αとし、この表Ｃをクラス統合結果格納部２１０に格納する。図９の例では、ここで（ｅｖｅｎｔＢ１、ｅｖｅｎｔＢ２、ｅｖｅｎｔＣ１）を要素としたイベント列αが生成され、新たに表Ｃとして格納される。
【００９３】
ステップＳ１００２では、以降のステップＳ１００３〜ステップＳ１０１５の処理を表Ａの行項目に記述されている状態数だけ繰り返す。図９の例では、ＣｌａｓｓＢの状態図情報９０３に記述されている状態数は３であるため、繰り返し数は３となる。
【００９４】
ステップＳ１００３では、表Ａより新たな状態名Ａを取り出す。ここで図９の例では、“ＳｔａｔｅＢ１”が取り出されることとなる。ステップＳ１００４では、以降のステップＳ１００５〜ステップＳ１０１４の処理を表Ｂの行項目に記述されている状態数だけ繰り返す。図９の例では、ＣｌａｓｓＣの状態図情報９０４に記述されている状態数は２であるため、繰り返し数は２となる。
【００９５】
ステップＳ１００５では、表Ｂより新たな状態名Ｂを取り出す。ここで図９の例では、“ＳｔａｔｅＣ１”が取り出されることとなる。ステップＳ１００６では、状態名Ａおよび状態名Ｂの名前の連結（“状態名Ａ状態名Ｂ”）により新たな状態名Ｃを作成し、クラス統合結果格納部２１０によって表Ｃに記述する。図９の例では、“ＳｔａｔｅＢ１ＳｔａｔｅＣ１”という新たな状態名が作成され、表Ｃに記述される。
【００９６】
ステップＳ１００７では、以降のステップＳ１００８〜ステップＳ１０１３の処理を表Ｃに記述されたイベント列αの数だけ繰り返す。図９の例では、ステップＳ１００１によって作成されたイベント列αの要素数は３であるため、繰り返し数は３となる。
【００９７】
ステップＳ１００８では、イベント列αより、新たなイベントＣを取り出す。ここで図９の例では、“ｅｖｅｎｔＢ１”が取り出されることとなる。
【００９８】
ステップＳ１００９では、イベントＣが表Ａに定義されているかを判定し、定義されている場合にはステップＳ１０１０に進み、定義されていない場合にはステップＳ１０１２に進み、それぞれ処理を続ける。上記のごとく図９の例では、“ｅｖｅｎｔＢ１”が表Ａに定義されているため、ステップＳ１０１０に進む。
【００９９】
ステップＳ１０１０では、表Ａより状態名ＡにおけるイベントＣ受信時のアクションを抜き出し、これを表Ｃの状態名ＣにおけるイベントＡ受信時のアクションに転記する。この際、アクションがない場合にも、その情報を転記しておく。図９の例では、ＣｌａｓｓＢの状態図情報９０３（表Ａ）より“ＳｔａｔｅＢ１”における“ｅｖｅｎｔＢ１”受信時のアクションは“ａｃｔｉｏｎα”であることが分かるため、これを転記する。
【０１００】
ステップＳ１０１１では、表Ａより状態名ＡにおけるイベントＣ受信時の遷移先状態（状態名Ｄ）を抜き出し、これと状態名Ｂとを連結した名前（“状態名Ｄ状態名Ｂ”）を表Ｃの状態名ＣにおけるイベントＡ受信時の遷移先状態に転記する。この際、遷移先状態がない場合、すなわち状態名ＡでイベントＡが受け取ることが想定されていない場合（例えば図９中の９０７のセルに相当する）、その情報を転記しておく。図９の例では、ＣｌａｓｓＢの状態図情報９０３（表Ａ）より“ＳｔａｔｅＢ１”における“ｅｖｅｎｔＢ１”受信時の遷移先状態は“ＳｔａｔｅＢ２”であることが分かるため、これと“ＳｔａｔｅＣ１”の名前を連結し、“ＳｔａｔｅＢ２ＳｔａｔｅＣ１”を転記する。
【０１０１】
ステップＳ１０１２では、表Ｂより状態名ＢにおけるイベントＣ受信時のアクションを抜き出し、これを表Ｃの状態名ＣにおけるイベントＡ受信時のアクションに転記する。この際、アクションがない場合にも、その情報を転記しておく。
【０１０２】
ステップＳ１０１３では、表Ｂより状態名ＢにおけるイベントＣ受信時の遷移先状態（状態名Ｄ）を抜き出し、これと状態名Ａとを連結した名前（“状態名Ａ状態名Ｄ”）を表Ｃの状態名ＣにおけるイベントＡ受信時の遷移先状態に転記する。この際、遷移先状態がない場合には、その情報を転記しておく。
【０１０３】
以上の処理によって、統合すべき２つのクラスが持つ状態図同士が統合され、新たな１つの状態図の情報がクラス統合結果格納部２１０によって記憶される。
【０１０４】
＜状態図の統合処理の具体例＞
図１１はモデル情報格納部２０２により記憶されるモデル情報の一部と、前記クラス定義の統合処理（ステップＳ８０６）によってクラス統合結果として格納される情報の一部の具体例を示したものである。
【０１０５】
図中、１１０１はクラス間の関連情報の保持例でありこれは図５と等価である。１１０２は、上記クラス間の関連情報１１０１を元に、クラス統合部２０８によってクラスが統合された際の統合結果の保持例を示したものである。
【０１０６】
１１０３はクラスの種別情報の保持例であり、これは図７と等価である。１１０４は、上記クラスの種別情報１１０３を元に、クラス統合部２０８によってクラスが統合された際の統合結果の保持例を示したものである。
【０１０７】
１１０５は、クラスの属性情報の保持例、同様に１１０７はクラスの関数情報の保持例である。この保持例では、各クラスに定義されている属性、関数１つ１つを１行とし、これを一覧として保持することを特徴としている。
【０１０８】
また、１１０６は、上記クラスの属性情報１１０５を元に、同様に１１０８は上記クラスの関数情報１１０７を元に、それぞれクラス統合部２０８によってクラスが統合された際の統合結果の保持例を示したものである。この際、クラスの統合が行われても各クラスに定義されている属性、関数は不変であり、その行数の増減が起こることはない。
【０１０９】
＜クラス定義の統合処理の流れ＞
図１２は、前記クラス定義の統合処理（ステップＳ８０６）の詳細な手順を示すフローチャートである。以下では、このフローチャートに沿って図１１のｂ）クラス種別情報１１０３、およびｃ）クラスの属性情報１１０５を例にクラス定義の統合処理を説明する。
【０１１０】
ステップＳ１２０１では、統合クラス選択部２０７によって選択された２つのクラス（“クラスＡ”、“クラスＢ”）のクラス名の連結により、統合後のクラス名（“クラスＡクラスＢ”）を作成する。ここで図１１の例では、ＣｌａｓｓＢとＣｌａｓｓＣが選択され、統合後のクラス名が“ＣｌａｓｓＢＣｌａｓｓＣ”となったとする。
【０１１１】
ステップＳ１２０２では、以降のステップＳ１２０３〜Ｓ１２１０の処理をモデル情報格納部２０２に記録されている表の数だけ繰り返す。
【０１１２】
ステップＳ１２０３では、モデル情報格納部２０２より新たな表を１つ取り出し、表Ａとする。ここで図１１の例では、クラス種別情報１１０３が取り出されたものとする。
【０１１３】
ステップＳ１２０４では、以降のステップＳ１２０５〜Ｓ１２０８の処理を表Ａに情報が記載されているセルの数だけ繰り返す。図１１の例では、クラス種別情報１１０３には計１２のセルに設計情報が記載されているため、繰り返し数は１２となる。
【０１１４】
ステップＳ１２０５では、表Ａより新たなセルを取り出しセルＡとする。ここで図１１の例では、“ＣｌａｓｓＢ”と記載されているセルが取り出されたとする。
【０１１５】
ステップＳ１２０６では、セルＡに記載されている情報が“クラスＡ”と等しいかを判定する。ここで、もし等しいと判定された場合にはステップＳ１２０８の処理に流れ、異なると判定された場合にはステップＳ１２０７の処理に流れる。図１１の例では、ここで等しいと判定され、ステップＳ１２０８の処理に流れる。
【０１１６】
ステップＳ１２０７では、セルＡに記載されている情報が“クラスＢ”と等しいかを判定する。ここで、もし等しいと判定された場合にはステップＳ１２０８の処理に流れ、異なると判定された場合にはステップＳ１２０９の処理に流れる。
【０１１７】
ステップＳ１２０８では、セルＡの情報を“クラスＡクラスＢ”に置き換える。図１１の例では、“ＣｌａｓｓＢ”という情報が“ＣｌａｓｓＢＣｌａｓｓＣ”に置き換わる。
【０１１８】
ステップＳ１２１０では、表Ａ内で情報が重複している、もしくは不要な行を削除する。図１１の例では、“ＣｌａｓｓＢＣｌａｓｓＣ”に関する情報と、“ＣｌａｓｓＤＣｌａｓｓＦ”に関する情報がそれぞれ重複しているため、それらの情報を削除する。これにより、クラスの種別情報の統合結果１１０４を獲得し、この情報がクラス統合結果格納部２１０によってオブジェクト指向プログラミング生成装置内に記憶される。
【０１１９】
以上の処理によって、統合すべき２つのクラスの定義が統合され、さらに前記状態図の統合処理とを併用することにより、能動クラス同士の統合を含めたあらゆるクラス同士の統合処理が実現される。
【０１２０】
以上の説明から明らかなように、本実施形態にかかるオブジェクト指向プログラミング生成装置は、クラス統合部において新たに統合されるクラスが、統合前のクラス定義をマージしたものによって表現されることを特徴とし、特に状態図を保持する能動クラス同士を統合する場合には、２つのクラスが持つ状態図より１つの統合された状態図を新たに生成する状態図統合部を有することにより、能動クラス同士の統合が可能となり、メモリ容量が少なく、なおかつ実行速度に優れたプログラムを自動生成することが可能となる。
【０１２１】
［その他の実施形態］
上記実施形態では、統合クラス選択部において統合処理が可能と判定されたクラスについてはすべて統合処理を実行することとしたが、本発明は特にこれに限定されるものではなく、クラスの統合処理の実行／省略をユーザが選択できるようにしてもよい。
【０１２２】
＜オブジェクト指向プログラミング生成のための手順＞
図１３は、本実施形態にかかるオブジェクト指向プログラミング生成装置におけるプログラム生成のための手順を示すフローチャートである。以下、このフローチャートに沿って説明する。
【０１２３】
ステップＳ１３０１では、モデル図入力部２０１によりユーザがモデル情報を入力する。
【０１２４】
ステップＳ１３０２では、前記ステップＳ１３０１により入力されたモデル情報をオブジェクト指向プログラミング生成装置上に記憶する。
【０１２５】
ステップＳ１３０３では、モデル情報の入力が終了したかをユーザからの入力により判定する。具体的には、ユーザの直前の入力がプログラムの自動生成開始命令であるなど、モデル情報の入力終了を表す入力に相当した場合、モデル情報の入力が終了したと判定する。ここでモデル情報の入力が終了したと判定された場合にはステップＳ１３０４に進み、そうでない場合にはステップＳ１３０１の処理に戻る。
【０１２６】
ステップＳ１３０４では、プログラム自動生成方法選択部２１２により、クラスの統合処理を実行し、その結果を用いてプログラムを自動生成するのか、もしくは、統合処理を行わず、モデル情報格納部２０２に記憶されているモデル情報を用いてプログラムを自動生成するのかをユーザが選択する。
【０１２７】
ステップＳ１３０５では、前記ステップＳ１３０４の処理によってクラスの統合処理の実行が選択されたかを判定する。ここで、選択されたと判定された場合にはステップＳ１３０６に進み、選択されなかったと判定された場合にはステップＳ１３０８に進む。
【０１２８】
ステップＳ１３０６では、前記ステップＳ１３０２の処理によって格納されたモデル情報を元に、統合可能なクラスの選択を行い、さらに選択されたクラスに対しクラスの統合処理を実行する。
【０１２９】
ステップＳ１３０７では、前記ステップＳ１３０６の処理により生成されたクラス統合結果情報を元に、プログラムの自動生成を行う。
【０１３０】
ステップＳ１３０８では、前記ステップＳ１３０２の処理によりオブジェクト指向プログラミング生成装置内に記憶されたモデル情報を元に、プログラムの自動生成を行う。
【０１３１】
ステップＳ１３０９では、ステップＳ１３０７の処理もしくはステップＳ１３０８の処理により自動生成されたプログラムを、出力装置１０８ｂに表示する。
【０１３２】
以上の処理によって、上記モデル情報格納部２０２によって記憶されたユーザによって入力されたモデル情報を元にプログラムを自動生成するプログラム自動生成部と、同じく上記クラス統合結果格納部２１０に記憶されたクラス統合結果情報を元にプログラムを自動生成するクラス統合後プログラム自動生成部とを、ユーザが任意に選択して利用することが可能となる。
【０１３３】
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【０１３４】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【０１３５】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１３６】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【０１３７】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１３８】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【０１３９】
【図１】本発明の一実施形態にかかるオブジェクト指向プログラミング生成装置の全体構成を示す図である。
【図２】本発明の一実施形態にかかるオブジェクト指向プログラミング生成装置の機能構成を示すブロック図である。
【図３】本発明の一実施形態にかかるオブジェクト指向プログラミング装置におけるプログラム生成のための手順を示すフローチャートである。
【図４】統合可能なクラスの選択と統合処理の詳細アルゴリズムを示すフローチャートである。
【図５】本発明の一実施形態にかかるオブジェクト指向プログラミング生成装置のモデル情報格納部により記憶されるモデル情報のうち、特にクラス間の関連情報の保持例を示した図である。
【図６】本発明の一実施形態にかかるオブジェクト指向プログラミング生成装置におけるクラス統合可否判定処理の詳細な処理の流れを示すフローチャートである。
【図７】本発明の一実施形態にかかるオブジェクト指向プログラミング生成装置のモデル情報格納部により記憶されるモデル情報のうち、特にクラスのクラス種別情報の保持例を示した図である。
【図８】本発明の一実施形態にかかるオブジェクト指向プログラミング生成装置におけるクラスの統合処理の詳細な処理の流れを示すフローチャートである。
【図９】本発明の一実施形態にかかるオブジェクト指向プログラミング生成装置において、状態図の統合処理の処理結果として格納される情報の具体例を示した図である。
【図１０】本発明の一実施形態にかかるオブジェクト指向プログラミング生成装置における状態図の統合処理の詳細な手順を示すフローチャートである。
【図１１】モデル情報格納部により記憶されるモデル情報の一部と、前記クラス定義の統合処理によってクラス統合結果として格納される情報の一部の具体例を示した図である。
【図１２】本発明の一実施形態にかかるオブジェクト指向プログラミング生成装置におけるクラス定義の統合処理の詳細な手順を示すフローチャートである。
【図１３】本発明の他の実施形態にかかるオブジェクト指向プログラミング装置におけるプログラム生成のための手順を示すフローチャートである。
【図１４】クラス図の統合例を示す図である。
【符号の説明】
【０１４０】
２０１：モデル図入力部
２０２：モデル情報格納部
２０３：モデル図表示部
２０４：プログラム自動生成部
２０５：プログラム格納部
２０６：プログラム表示部
２０７：統合クラス選択部
２０８：クラス統合部
２０９：状態図統合部
２１０：クラス統合結果格納部
２１１：クラス統合後プログラム自動生成部
２１２：プログラム自動生成方法選択部
【図１】
2006343867.tif 000003
【図２】
2006343867.tif 000004
【図３】
2006343867.tif 000005
【図４】
2006343867.tif 000006
【図５】
2006343867.tif 000007
【図６】
2006343867.tif 000008
【図７】
2006343867.tif 000009
【図８】
2006343867.tif 000010
【図９】
2006343867.tif 000011
【図１０】
2006343867.tif 000012
【図１１】
2006343867.tif 000013
【図１２】
2006343867.tif 000014
【図１３】
2006343867.tif 000015
【図１４】
2006343867.tif 000016