プログラムコード生成装置、プログラムコード生成方法及びプログラム
【課題】 ソフトウェアの設計図面における関連について最適な実装方法を自動で出力することを可能とすることを目的とする。
【解決手段】 プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である設計図面を解析する設計図面解析工程と、前記設計図面情報に基づいて1対多の関連に対してプログラムコード生成規則を定めるインスタンス配置工程と、データアクセスが何回発生したかを示すインスタンスアクセス情報を更新するインスタンス配置情報更新工程と、前記インスタンス配置情報に基づいてプログラムコードを生成するプログラムコード生成工程とを備えることを特徴とするプログラムコード生成方法等、を提供する。
【解決手段】 プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である設計図面を解析する設計図面解析工程と、前記設計図面情報に基づいて1対多の関連に対してプログラムコード生成規則を定めるインスタンス配置工程と、データアクセスが何回発生したかを示すインスタンスアクセス情報を更新するインスタンス配置情報更新工程と、前記インスタンス配置情報に基づいてプログラムコードを生成するプログラムコード生成工程とを備えることを特徴とするプログラムコード生成方法等、を提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアの設計図面からプログラムコードを自動生成することを特徴とするプログラムコード生成装置等に関する。
【背景技術】
【０００２】
近年のソフトウェア設計技術として、モデル駆動型アーキテクチャー(Model Driven Architecture技術（以降、ＭＤＡ技術と称す）が広まり、採用されるようになってきている。一般的にＭＤＡ技術とは、オペレータが入力したソフトウェアの設計図面情報から各種プラットフォームのプログラムコードを自動的に生成し、且つ、入力したソフトウェアの設計図面情報をＭＤＡ専用ツール上で動作および検証することが可能な技術である。これらソフトウェアの設計図面情報の代表的な例としては、オブジェクト指向技術のモデル表記言語であるＵＭＬ（Unified Modeling Language）やＳＤＬ（Specification & Description Language）などが挙げられる。
【０００３】
しかしながら、既存のプログラム生成装置から生成されるプログラムコードは、設計図面からプログラムコードに変換するルールによっては、生成されるコードのサイズが大きく、実行のために多くのＲＡＭを必要とするという問題がある。このため、組み込みシステムなどのメモリ容量の制限が厳しい領域では、ＭＤＡ技術の導入に躊躇するケースが少なくない。
【０００４】
設計図面の段階での最適化を行う技術が、特許文献１（特開平１１−２３７９８０号公報）及び特許文献２（特開２００４−１１８８６５号公報）に開示されている。これらの技術は、オブジェクト指向機能排除手段を用いて仮想関数の機能を排除、もしくはインスタンスの動的生成の機能を排除することで必要なメモリ容量を増加させることなく組み込み制御システムに適用可能なコードの最適化を行うことを可能にしている。更に、組み込みシステムのソフトウェア開発におけるＲＡＭ容量を削減する技術が特許文献３（特開２０００−４０００５号公報）及び特許文献４（特開２００１−１８４２１４号公報）に開示されている。これらの技術は、プログラムコード中のｃｏｎｓｔ指定されたインスタンス変数やオブジェクトをＲＯＭ上に配置することにより、ＲＡＭ容量の削減を図っている。また、特許文献５（特開２００２−９１７６２号公報）に記載の技術は、ＲＯＭのデータへのアドレスをＲＡＭへ再配置する際のアドレス変換に関するもので、設計図面のデータを解析するが、ＲＡＭ上のどこに配置するかについては触れられていない。これらの提案で述べられている最適化は、プログラムコードの生成時に限定された工夫であり、ＭＤＡ技術の実行可能モデルを考慮したものではない。
【０００５】
オブジェクト指向型プログラムでは、クラスの実体であるインスタンス同士が互いに協調動作することによって１つの機能を実現している。あるインスタンスが生成されるとそのインスタンスに働きかける別のインスタンスは、関連を保持するための領域についてメモリ領域を確保し、インスタンス同士で協調動作を実現する。インスタンス同士の関連が１対１の関連であれば、インスタンス自体を参照する領域が１つ存在すれば十分である。しかしながら、インスタンス同士の関連が１対多の場合や多対多の場合では、複数のインスタンスを保持するためのコンテナをメモリ領域に確保することが必要となる。複数のインスタンスを保持するコンテナは、配列型やＬＩＳＴ型やＭＡＰ型などで実現される。
【０００６】
１対多の関連の場合は、インスタンス同士の関連が動的に変化するために、コンテナ領域を動的に確保する必要がある。コンテナ領域は、インスタンスと関連がある別のインスタンスへの参照と次のコンテナへの参照を連続で持つことによって複数インスタンスとの関連を保持することができる。例えば、クラスＸとクラスＹの間に１対多の関連が存在し、クラスＸのインスタンス（ｘ１）がクラスＹのインスタンス（ｙ１，ｙ２，ｙ３）をＬＩＳＴ型のコンテナで実現すると、インスタンスｘ１は、ｙ１からｙ３まで辿ることが可能なリスト形式のコンテナとして関連を持つことになる。そして、クラスＸとクラスＹにおいてデータのやり取りが発生する場合は、インスタンスｘ１が持つＬＩＳＴ型のコンテナからクラスＹのインスタンスをキー検索することで、関連付けられている複数のインスタンスから特定のインスタンスと協調動作することが可能となる。
【０００７】
【特許文献１】特開平１１−２３７９８０号公報
【特許文献２】特開２００４−１１８８６５号公報
【特許文献３】特開２０００−４０００５号公報
【特許文献４】特開２００１−１８４２１４号公報
【特許文献５】特開２００２−９１７６２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
コンテナの実装方法にはメモリ使用量や検索にかかるコストなどから様々な方法が存在する。一般に検索にかかるコストを抑えた実装方法を選択すると、メモリ使用量が大となる。つまり、コンテナの実装方法は検索にかかるコストとメモリの消費量はトレードオフの関係となっている。そのため、メモリ消費量や検索コストの面から最適な実装方法でプログラムコードを生成する必要がある。しかしながら、ＭＤＡ技術を利用した場合は、プログラムの特性に応じてコンテナの実装方法を変更しておらず、メモリ消費量やインスタンスの検索にかかるコストについて何ら考慮がなされていない状況となっている。
【課題を解決するための手段】
【０００９】
本発明は、実際に実行した結果であるインスタンスへのアクセス状況と、設計図面であるモデル情報から、インスタンスの保持方法であるコンテナを実装するプログラムコードについて、インスタンスへのアクセス頻度やアクセスパターンから最適なプログラムコードを選択する。これにより、設計者はソフトウェアの設計図面における関連について最適な実装方法を自動で出力することが可能となる。
【００１０】
上記の目的を達成するために本発明は、プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である設計図面を解析する設計図面解析工程と、前記設計図面情報に基づいて1対多の関連に対してプログラムコード生成規則を定めるインスタンス配置工程と、データアクセスが何回発生したかを示すインスタンスアクセス情報を更新するインスタンス配置情報更新工程と、前記インスタンス配置情報に基づいてプログラムコードを生成するプログラムコード生成工程とを備えることを特徴とするプログラムコード生成方法等、を提供する。
【発明の効果】
【００１１】
本発明によれば、ソフトウェアの設計図面からプログラムコードを自動生成する際、1対多及び多対多の関連のクラスについてはインスタンス配置情報に従ったプログラムコードを生成するプログラムコード生成装置を提供することができる。
【発明を実施するための最良の形態】
【００１２】
以下、添付の図面に沿って本発明の実施形態について説明する。
【００１３】
（第１の実施形態）
図１は、本発明の第１の実施形態を示す全体構成図である。１はＣＰＵであり、以下に説明する３〜１０の装置を２で示すバスを介してアクセスし制御を行う。３はバス２を介してＣＰＵ１からアクセス可能な読み出し専用メモリ（ＲＯＭ）であり、本実施形態ではその動作を詳細に説明する処理プログラム３ａ及び処理プログラムにより使用されるパラメータ３ｂが格納されている。４は読み書き可能なメモリ（ＲＡＭ）である。ＲＡＭ４上には、領域４ａ、４ｂ、４ｃ、４ｄ、４ｅ、４ｆ、４ｇ及び４ｈが確保されている。これらの領域４ａ〜４ｈには、設計図面情報、プラットフォーム依存情報、プログラムコード、インスタンス配置情報、ライブラリ、プログラム実行形式、インスタンスアクセス情報及びインスタンス配置情報が夫々格納される。これらの設計図面情報、プラットフォーム依存情報、プログラムコード、インスタンス配置情報、ライブラリ、プログラム実行形式、インスタンスアクセス情報及びインスタンス配置情報は、上記処理プログラム３により作成／変更がなされる。５は入力インターフェイスであり、６で示したキーボード、マウス、ボタン、ダイアル等の入力装置を介してなされる入力を受け取る。７は出力インターフェイスであり、８で示したＣＲＴ，ＬＣＤ等の表示媒体、更にはプリンタ、プロッタ等の出力装置に対し、データの表示／出力を行なう。また、９は外部記憶装置インターフェイスであり、１０で示したＨＤ、ＦＤ、ＣＤ−ＲＯＭ、ＭＤ、ＣＦ等の外部記憶装置に対するデータの入出力を行うものである。
【００１４】
本実施形態では、処理プログラム３ａやパラメータ３ｂがＲＯＭ３上にあるものとして、また、処理対象となる各データの格納領域（４ａ〜４ｈ）がＲＡＭ上にあるものとして説明を行う。但し、これらはすべて、外部記憶装置上に配置することも可能であり、必要に応じて外部記憶装置からＲＡＭ上にロードして使用することもできる。また、ＣＰＵのキャッシュメモリ上に配置することも同様に可能である。
【００１５】
図２は、図１において３ａで示した処理プログラムの構成要件とそれら構成要件が図１の４ａ〜４ｆで示した格納領域に格納されるデータとどのような関係にあるかを示すデータフロー図である。
【００１６】
２０１は、図１における入力インターフェイス５を介して入力されるデータを扱うＧＵＩ入力処理部であり、ユーザはこのＧＵＩ入力処理部２０１によりデータの入力や編集と、各処理部へ指示できるようになっている。本実施形態に係るプログラムコード生成装置においては、自動生成装置起動部２０２として利用する。
【００１７】
２０３は、外部記憶装置１０に格納されている、プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向であることを特徴とする設計図面を読み込み、設計図面情報２０６を生成する設計図面情報入力部である。
【００１８】
２０４は、プラットフォーム依存情報入力部である。プラットフォーム依存情報入力部２０４は、外部記憶装置１０に格納されている、実行ファイルの動作するＯＳやＣＰＵやメモリ量やプログラミング言語や利用フレームワークを含む情報を読み込み、プラットフォーム依存情報２０７を生成する。
【００１９】
２０５は、インスタンスの実装コードにおけるコレクションの型を決定するためのインスタンス配置情報２０８を更新するインスタンス配置情報更新部である。
【００２０】
２０９は、設計図面情報２０６やプラットフォーム依存情報２０７やインスタンス配置情報２０８からプログラムコード２１０を生成するプログラム生成部である。プログラム生成部２０９はインスタンス配置情報入力部によって選択されたインスタンス配置情報２０８を使って、プログラムコードを生成する。プログラム生成部２０９が生成可能なプログラムコードとして、インスタンスのコレクション型を決定したプログラムコードや、インスタンスへのアクセスログを出力することが可能なコードを付加したプログラムコード等が挙げられる。
【００２１】
２１１は、プログラムコード２１０から参照されるライブラリである。
【００２２】
２１２は、プログラムコード２１０とライブラリ２１１をコンパイル・リンクするコードコンパイラ・リンカである。
【００２３】
２１３は、コードコンパイラ・リンカ２１２が生成したプログラム実行形式である。
【００２４】
２１４は、プログラム実行形式２１３を実行する実行部である。プログラム実行形式２１３がインスタンスへのアクセスログを出力することが可能なコードを付加したプログラム実行形式２１３であった場合、ここでのプログラム動作時にプログラム実行ログ２１５を出力する。
【００２５】
２１５は、プログラム実行部２１４でプログラム実行時に出力されたプログラム実行ログであり、いつ、どのクラスのインスタンスへのアクセスがあったかどうかをログ出力する。
【００２６】
２１６は、プログラム実行ログ２１５を使って、インスタンスへのアクセスログを解析する実行ログ解析部である。
【００２７】
２１７は、実行ログ解析部２１６より算出されたインスタンスアクセス情報である。
【００２８】
これ以降の説明におけるフローチャートによる処理手順は、例に限定されることはなく、本発明の結果を満たす限りいかなる手順の組み合わせも、複数処理をまとめることも、処理を細分化することも可能である。また、各処理を個々に切り出してひとつの機能要素として単体として機能し、示している処理以外の処理と組み合わせて使用することも可能である。
【００２９】
以下、本発明の実施形態の動作について図面及びフローチャートを参照して説明する。
【００３０】
図３は、本実施形態のシステム全体の処理手順を示したフローチャート図である。本システムの起動は（ステップＳ１０１）、ＧＵＩ入力処理部２０１などの入力部からオペレータが指示する。
【００３１】
ステップＳ１０２で、設計図面情報入力部２０３が設計図面を読込み、プログラム生成部２０９が処理できるデータ形式に変換した設計図面情報２０６を生成する。
【００３２】
ステップＳ１０３で、プラットフォーム依存情報入力部２０４が、プログラム生成部２０９が処理できるデータ形式に変換したプラットフォーム依存情報２０７を生成する。
【００３３】
ステップＳ１０４で、プログラム生成部２０９は、設計図面情報２０６とプラットフォーム依存情報２０７を用いてプログラムコード２１０を生成する。ここで、オペレータからの指示がある場合だけ、インスタンス配置情報２０８を使って、インスタンスの保持方法を特定したプログラムコードを生成する。更に、オペレータからの指示があれば、生成するプログラムコード２１０に対し、いつ、どのインスタンスにアクセスしたかを出力するプログラム実行ログ２１５を生成するプログラムコードを付加する。プログラムコード生成ルーチンに関しては、次に詳しく説明する。
【００３４】
ステップＳ１０５で、コンパイラ・リンカ２１２はプログラムコード２１０とライブラリ２１１をコンパイル・リンクし、プログラム実行形式２１３を生成する。
【００３５】
ステップＳ１０６で、プログラム実行部２１４はプログラム実行形式２１３を実行する。ここでプログラム実行形式２１４が、ログ出力機能を付加したプログラムコード２１０の実行形式だった場合、このステップ時にプログラム実行ログ２１５が出力される。
【００３６】
ステップＳ１０７で、実行ログ解析部２１６は、プログラム実行ログを生成するプログラムコードが付加されていて、かつプログラム実行ログ２１５があるかどうかを判断する。プログラム実行ログがあった場合は、ステップＳ１０８へ進む。ステップＳ１０７で、プログラム実行ログがなかった場合は、ステップＳ１０９へ進む。
【００３７】
ステップＳ１０８で、実行ログ解析部２１６はプログラム実行ログ２１５を解析する処理を行い、インスタンスアクセス情報２１７を生成する処理を行う。
【００３８】
ステップＳ１０９で、インスタンス配置情報更新部２０８は、インスタンスアクセス情報が存在して、かつインスタンス配置情報を更新するかどうかを判断する。インスタンス配置情報を更新する場合は、ステップＳ１１０へ進む。ステップＳ１０９でインスタンス配置情報を更新しない場合は、ステップＳ１１１へ進み、本シーケンスを終了する。
【００３９】
ステップＳ１１０で、インスタンス配置情報更新部２０８は、インスタンス配置情報を更新する処理を行う。インスタンス配置情報更新ルーチンに関しては、次に詳しく説明する。
【００４０】
本実施形態においては、ＧＵＩ入力処理部２０１から、オペレータによって、プログラム生成部２０９とコンパイラ・リンカ２１２、プログラム実行部２１４、実行ログ解析部２１６を起動しているが、この方法によらない。
【００４１】
図４は、図３のプログラムコード生成ルーチンＳ１０４の流れを説明したフローチャート図である。プログラムコード生成ルーチンが呼び出されると、ステップＳ２０２で、全てのクラスについて、プログラムコード生成が完了するまでステップＳ２０３からステップＳ２１１を繰り返す処理を行う。全てのクラスについてプログラムコード生成が完了していなかったら、ステップＳ２０３へ進む。
【００４２】
ステップＳ２０３で、クラスに存在する全ての関連についてのプログラムコード生成について、プログラムコード生成が完了するまでステップＳ２０４からステップＳ２１０を繰り返す処理を行う。全ての関連についてプログラムコード生成が完了していなかったら、ステップＳ２０４へ進む。
【００４３】
ステップＳ２０４で、設計図面情報２０６の中で関連が１対多の関連か１対１の関連かを判断する処理を行う。
【００４４】
ステップＳ２０４で、１対１の関連の場合は、ステップＳ２０８へ進む。１対多の関連の場合は、ステップＳ２０５へ進む。
【００４５】
ステップＳ２０５で、インスタンス配置情報２０８に基づいてコレクションについてプログラムコードを自動生成するかどうかを判断する処理を行う。ステップＳ２０５で、インスタンス配置情報２０８を用いてプログラムコード生成をする場合は、ステップＳ２０６へ進む。インスタンス配置情報２０８を用いない場合は、ステップＳ２０７へ進む。
【００４６】
ステップＳ２０６で、インスタンス配置情報に記載の型でインスタンス同士の関連についてプログラムコードを生成する処理を行う。
【００４７】
ステップＳ２０７で、リスト構造でインスタンス同士の関連についてプログラムコード生成する処理を行う。
【００４８】
ステップＳ２０８で、インスタンス同士の関連は１対１であるので、直接参照するプログラムコードを生成する処理を行う。
【００４９】
ステップＳ２０９で、プログラムコードに対して、ログを付加するかどうかを判断する処理を行う。ステップＳ２０９でログを付加する場合は、ステップＳ２１０へ進む。ステップＳ２０９で、ログを付加しない場合は、ステップＳ２１１へ進む。
【００５０】
ステップＳ２１０で、プログラムコードに対してログ出力を行うプログラムコードを付加する処理を行う。
【００５１】
ステップＳ２１１で、全ての関連についてプログラムコード生成が完了すると、ステップＳ２１２へ進む。
【００５２】
ステップＳ２１２で、全てのクラスについてプログラムコード生成が完了すると、ステップＳ２１３へ進み本シーケンスを終了する。
【００５３】
図５Ａは、ある設計図面の一部を示したイメージ図である。図５Ａにおいて、３０１は、クラス名がＡＡＡであるクラスを示している。３０２は、クラス名がＢＢＢであるクラスを示している。３０３は、クラスＡＡＡとクラスＢＢＢが１対多の関連であることを示しており、クラスＡＡＡからクラスＢＢＢへの関連がＡ１であることを示している。
【００５４】
図５Ｂは、クラス間の連携を実装するコンテナに関する特徴を示した表である。キー検索とは、あるインスタンスと関連のある複数のインスタンスの中から、特定のインスタンスをキーをもとに検索してからアクセスする形式である。Ｅｎｕｍとは、あるインスタンスと関連のある複数のインスタンス全てに対してアクセスする形式である。ＭＡＰ型は、インスタンスとそのキーを登録しておくのでキー検索にかかるコストは少なくい構造となる。ＬＩＳＴ型や配列型の場合は、コンテナの構造が簡素であるか複雑であるかの違いはあるが、対象のインスタンスが見つかるまで全インスタンスを走査するため、キー検索にかかるコストは高くなる構造となる。また、Ｅｎｕｍ形式の場合では、コンテナの構造が簡素であるか複雑であるかの違いによりメモリ消費量に違いはあるが、ＥｎｕｍにかかるコストはＭＡＰ型、配列型、ＬＩＳＴ型に違いはない。
【００５５】
図６は、図３のインスタンス配置情報の更新ルーチンＳ１１０の流れを詳細に説明したフローチャート図である。図５Ｂの表で示しているようにアクセス形式にキー検索がある場合は、キー検索にかかるコスト（処理のオーダー）の低いＨＡＳＨ型が有効である。そのため、ある一定以上のインスタンスを関連として持つ（コレクション）場合は、キー検索のコストを考えＨＡＳＨ型を選択する。ＬＩＳＴ型と配列型では、キー検索にかかるコストは同じであるが、構造の複雑さからＥｎｕｍ形式のアクセス頻度の違いによって、配列型かＬＩＳＴ型を選択する。
【００５６】
インスタンス配置情報の更新ルーチンが呼び出されると、ステップＳ３０２で、全てのクラスについて、インスタンスアクセス情報２１７からインスタンス配置情報２０８の更新が完了するまでステップＳ３０３からステップＳ３１５を繰り返す処理を行う。全てのクラスについてインスタンス配置情報２０８の更新が完了していなかったら、ステップＳ３０３へ進む。
【００５７】
ステップＳ３０３で、クラスに存在する１対多の関連に関するインスタンス配置情報２０８の更新について、更新が完了するまでステップＳ３０４からステップＳ３１４を繰り返す処理を行う。全てのインスタンス配置情報２０８の更新が完了していなかったら、ステップＳ３０４へ進む。
【００５８】
ステップＳ３０４で、対象としている関連についてのインスタンスアクセス情報を読み取り、キー検索があるかどうかを判断する処理を行う。ステップＳ３０４でキー検索がある場合は、ステップＳ３０５へ進む。キー検索がない場合は、ステップＳ３０９へ進む。
【００５９】
ステップＳ３０５で、対象としている関連についてのインスタンスアクセス情報を読み取り、コレクションの総インスタンス数を取得する処理を行う。
【００６０】
ステップＳ３０６で、前もって設定している関連を実装するコンテナを決定するための閾値を取得する処理を行う。
【００６１】
ステップＳ３０７で、ステップＳ３０５で取得したコレクションの総インスタンス数とステップＳ３０６で取得した閾値を比較する処理を行う。ステップＳ３０７でコレクションの総インスタンス数が閾値よりも大である場合は、ステップＳ３０８へ進む。ステップＳ３０７でコレクションの総インスタンス数が閾値よりも小である場合は、ステップＳ３０９へ進む。
【００６２】
ステップＳ３０８で、対象としている関連についてのインスタンス配置情報をＨＡＳＨ型に設定する処理を行う。
【００６３】
ステップＳ３０９で、対象としている関連についてインスタンスアクセス情報を読み取り、Ｅｎｕｍ形式があるどうかを判断する処理を行う。ステップＳ３０９で、Ｅｎｕｍ形式がある場合は、ステップＳ３１１へ進む。Ｅｎｕｍ形式がない場合は、ステップＳ３１０へ進む。
【００６４】
ステップＳ３１０で、対象としている関連についてのインスタンス配置情報２０８をＬＩＳＴ型に設定する処理を行う。
【００６５】
ステップＳ３１１で、対象としている関連についてのインスタンスアクセス情報を読み取り、Ｅｎｕｍ形式のアクセス頻度を取得する処理を行う。
【００６６】
ステップＳ３１２で、前もって設定している関連を実装するコンテナを決定するための閾値を取得する処理を行う。
【００６７】
ステップ３１３で、ステップＳ３１１で取得した総数とステップＳ３１２で取得した閾値を比較する処理を行う。ステップＳ３１３で総数が閾値よりも大である場合は、ステップＳ３１４へ進む。ステップＳ３１３で総数が閾値よりも小である場合は、ステップＳ３１０へ進む。
【００６８】
ステップＳ３１４で、対象としている関連についてのインスタンス配置情報２０８を配列型に設定する処理を行う。
【００６９】
ステップＳ３１５で、全ての関連についてインスタンス配置情報２０８の更新が完了すると、ステップＳ３１６へ進む。
【００７０】
ステップＳ３１６で、全てのクラスについてインスタンス配置情報２０８が完了すると、ステップＳ３１７へ進み、本シーケンスを終了する。
【００７１】
図７は、図５Ａの設計図面を入力として、図４のフローチャート図によってプログラムコードが生成され、そのプログラムコードをコンパイル・リンクし、その結果生成されるプログラム実行形式を実際に実行した結果得られるログの一例を示したイメージ図である。図７において、４０１は、クラスＡＡＡの関連Ａ１において、関連Ａ１が保持するインスタンスに対するアクセスが発生した時のログを示している。４０２から４０４は、特定のインスタンスを取得するためのログを示している。４０２は、関連Ａ１に対して、キー“ｎａｍｅ”で検索されたことを示しており、関連によって保持されているインスタンスを４回にわたってチェックした結果、対象インスタンスを取得することが出来たことを示している。４０３及び４０４においても、４０２と同様である。４０５は、関連によって保持されている全インスタンスに対して処理が発生したことを示すログとなっている。
【００７２】
図８は、図７のログを解析した結果得られるインスタンスアクセス情報２１７を示したイメージ図である。図８中の５０１は、次の事項を示している。即ち、クラスＡＡＡにおいて関連Ａ１が存在し、その関連Ａ１に対してキーが“ｎａｍｅ”であるインスタンスが存在するかどうかを検索する処理が発生し、対象インスタンスを取得するのに４回のアクセスが関連Ａ１に対して生じたことを示している。５０２は、関連が保持する全インスタンス４つに対して連続アクセスが発生したことを示している。また、特定インスタンスに対するアクセスが３回、全インスタンスに対する連続アクセスが１回それぞれ発生したことを示している。
【００７３】
図４で示したフローチャートを実行すると、図８のインスタンスアクセス情報を解析し、インスタンス配置情報を更新する。キー検索に関する閾値が３である場合は、インスタンスアクセス情報２１７において総インスタンス数が４個であることからインスタンス配置情報２０８はＭＡＰ型に設定される。キー検索に関する閾値が４で、Ｅｎｕｍ形式のアクセス頻度が１である場合は、ＬＩＳＴ型に設定される。キー検索に関する閾値が４で、Ｅｎｕｍ形式のアクセス頻度が０である場合は、配列型に設定される。以上説明したように、図４で示したフローチャートを実行することによって、インスタンスアクセス情報２１７からインスタンス配置情報２０８を更新する。
【００７４】
図９は、“ＭＡＰ”を用いて生成されたプログラムコードの一例である。図９において、６０１は、クラスのコンストラクタであり、例えばコンストラクタの中でクラス間の関連（ＭＡＰ）を生成するプログラムコードが生成される。６０２は、クラス間の関連において保持されているインスタンスについて、特定のインスタンスを取得するプログラムコードであり、例えばＭＡＰを使用している場合は、引数にキーを与えることで特定のインスタンスをＭＡＰから取得することが出来る。６０３は、クラス間の関連に新たにインスタンスを追加するプログラムコードであり、例えばＭＡＰに登録するときは、インスタンスとそのインスタンスを検索するキーを同時に登録する。ＭＡＰは、メモリ消費量が大であるかわりに検索スピードが高速であることが知られており、ＭＡＰを関連に対するプログラムコードとして生成することによって、特定のインスタンスを検索するのにかかるコストを抑えることが可能となる。
【００７５】
図１０は、“ＬＩＳＴ”を用いて生成されたプログラムコードの一例である。図１０において、７０１は、クラスのコンストラクタであり、例えばコンストラクタの中でクラス間の関連（ＬＩＳＴ）を生成するプログラムコードが生成される。７０２は、クラス間の関連において保持されているインスタンスについて、特定のインスタンスを取得するプログラムコードである。例えばＬＩＳＴを使用している場合は、ｗｈｉｌｅ文などによりすべてのインスタンスに対して、キーと一致するインスタンスが現れるまでループを実行することで実現する。７０３は、クラス間の関連に新たにインスタンスを追加するプログラムコードであり、例えばＬＩＳＴに登録するときは、インスタンスを登録する。ＬＩＳＴ型は、ＭＡＰ型よりもメモリ消費量が小であるかわりに検索にかかるコストがＭＡＰよりも大であることが知られており、ＬＩＳＴ型を関連に対するプログラムコードとして生成することによって、メモリ消費量を抑えることができる。
【００７６】
本実施形態では、あるインスタンスと関連のある別のインスタンスのコンテナに関わるプログラムコード生成について、閾値としてインスタンスの総数やアクセスした総数をもとに変更しているが、閾値として数ではなく割合であっても同様の作用・効果が得られる。
【００７７】
（第２の実施形態）
次に、本発明の第２の実施形態について説明する。第２の実施形態では、第１の実施形態に加え、インスタンス配置情報の更新（図３のステップＳ１１０）において、インスタンスアクセス情報のアクセス情報に優先度を考慮して、インスタンス配置情報更新部２０５でインスタンス配置情報２０８を更新する。インスタンス配置情報を更新する場合のフローチャートを、図１１に示す。
【００７８】
図１１は、第２の実施形態におけるインスタンス配置情報２０８を更新する場合のフローチャート図である。図５Ｂの表で示しているようにアクセス形式にキー検索がある場合は、キー検索にかかるコスト（処理のオーダー）の低いＨＡＳＨ型が有効である。しかしながら、キー検索にかかるコストが低いかわりメモリ消費量が高いため、キー検索がそれほど実行されない場合では、ＨＡＳＨ型を選択してもそれほど効果が得られない場合も存在する。このような場合は、ＨＡＳＨ型ではなくＬＩＳＴ型の方がいいかどうかをキー検索形式の頻度やＥｎｕｍ形式の頻度をもとに計算する。
【００７９】
ステップＳ４０２で、各型を使用する優先度に応じて割り振られたポイントを取得する処理を行う。例えば、関連を実装するプログラムコードをＬＩＳＴ型かＭＡＰ型とする場合において、検索スピードよりもメモリ消費量を抑えたい場合には、ＬＩＳＴ型のポイントをＭＡＰ型よりも高く設定する。
【００８０】
ステップＳ４０３で、全てのクラスについて、インスタンスアクセス情報２１７からインスタンス配置情報２０８の更新が完了するまでステップＳ４０４からステップＳ４１０を繰り返す処理を行う。全てのクラスについてインスタンス配置情報２０８の更新が完了していなかったら、ステップＳ４０４へ進む。
【００８１】
ステップＳ４０４で、クラスに存在する１対多の関連に関するインスタンス配置情報２０８の更新について、更新が完了するまでステップＳ４０５からステップＳ４０９を繰り返す処理を行う。全てのインスタンス配置情報２０８の更新が完了していなかったら、ステップＳ４０５へ進む。
【００８２】
ステップＳ４０５で、Ｅｎｕｍ形式のアクセス回数をインスタンスアクセス情報２１７から取得し、そのアクセス数とステップＳ４０２で取得したポイント数から各型のポイント数を計算する処理を行う。
【００８３】
ステップＳ４０６で、キー検索形式について、全てのキーが完了するまでステップＳ４０７を繰り返す処理を行う。全てのキーが完了していなかったら、ステップＳ４０７へ進む。
【００８４】
ステップＳ４０７で、特定インスタンスのアクセスの回数をインスタンスアクセス情報２１７から取得し、そのアクセス数とステップＳ４０２で取得したポイント数から各型のポイント数を計算する処理を行う。
【００８５】
ステップＳ４０８で、全てのキーについて完了すると、ステップＳ４０９へ進む。
【００８６】
ステップＳ４０９で、ステップＳ４０５とステップＳ４０７から得られた各型のポイント数から、インスタンス配置情報を設定する処理を行う。
【００８７】
ステップＳ４１０で、全ての関連についてプログラムコード生成が完了すると、ステップＳ４１１へ進む。
【００８８】
ステップＳ４１１で、全てのクラスについてプログラムコード生成が完了すると、ステップＳ４１２へ進み本シーケンスを終了する。
【００８９】
図１２は、第１の実施形態と同様のインスタンスアクセス情報２１７を示したイメージ図である。図１２中の８０１は、次の事項を示している。即ち、クラスＡＡＡにおいて関連Ａ１が存在し、その関連Ａ１に対してキーが“ｎａｍｅ”であるインスタンスが存在するかどうかを検索する処理が発生し、対象インスタンスを取得するのに４回のアクセスが関連Ａ１に対して生じたことを示している。８０２は、クラスＡＡＡにおいて関連Ａ１が存在し、その関連Ａ１に対してキーが“ｎａｍｅ”であるインスタンスが存在するかどうかを検索する処理が発生し、対象インスタンスを取得するのに２回のアクセスが関連Ａ１に対して生じたことを示している。８０３は、クラスＡＡＡにおいて関連Ａ１が存在し、その関連Ａ１に対してキーが“ｔｙｐｅ”であるインスタンスが存在するかどうかを検索する処理が発生し、対象インスタンスを取得するのに５０回のアクセスが関連Ａ１に対して生じたことを示している。８０４は、関連が保持する全インスタンス数１００に対して連続アクセスが発生したことを示している。また、同様のアクセスが、この他にも合計１０回発生していることを示している。
【００９０】
図１１で示したフローチャートを実行すると、図１２のインスタンスアクセス情報を解析し、インスタンス配置情報を更新する。例えば、検索にかかるコストよりもメモリ消費量を抑えたい場合には、ＬＩＳＴ型のポイントを２、ＭＡＰ型のポイントを１のようにＬＩＳＴ型のポイントを高く設定する。図１２の場合において、全インスタンスへの連続アクセスについて、全インスタンスへのアクセスが１０回発生するため、ＬＩＳＴ型のポイントは２０ポイントとなる。同様にＭＡＰ型のポイントは１０ポイントとなる。図１２の場合において、特定インスタンスへのアクセスについて、ｎａｍｅをキーとしてアクセスする場合は、２回存在しているため、ＬＩＳＴ型のポイントは０、ＭＡＰ型のポイントは２となる。また、特定インスタンスへのアクセスについて、ｔｙｐｅをキーとしてアクセスする場合は、１回存在しているため、ＬＩＳＴ型のポイントは０、ＭＡＰ型のポイントは１となる。この結果、図１２のようなインスタンスアクセス情報において、メモリ消費量を抑える方針の場合には、次のようになる。即ち、ＬＩＳＴ型のポイントが２、ＭＡＰ型のポイントが１に設定されているので、ＬＩＳＴ型２０ポイント、ＭＡＰ型１２ポイント（キーがｎａｍｅ）及び１１ポイント（キーがｔｙｐｅ）となる。従って、最終的なインスタンス配置情報はＬＩＳＴとして設定することとなり、最終的にプログラムコードを生成するとＬＩＳＴ型を生成する。
【００９１】
また、メモリ消費量検索よりも検索にかかるコストを抑えたい場合には、ＬＩＳＴ型のポイントを１、ＭＡＰ型のポイントを２のようにＭＡＰ型のポイントを高く設定する。図１２の場合において、全インスタンスへの連続アクセスについて、全インスタンスへのアクセスが１０回発生するため、ＬＩＳＴ型のポイントは１０ポイントとなる。同様にＭＡＰ型のポイントは２０ポイントとなる。図１２の場合において、特定インスタンスへのアクセスについて、ｎａｍｅをキーとしてアクセスする場合は、２回存在しているため、ＬＩＳＴ型のポイントは０、ＭＡＰ型のポイントは４となる。また、特定インスタンスへのアクセスについて、ｔｙｐｅをキーとしてアクセスする場合は、１回存在しているため、ＬＩＳＴ型のポイントは０、ＭＡＰ型のポイントは２となる。この結果、図１２のようなインスタンスアクセス情報において、検索コストを抑える方針の場合には、次のようになる。即ち、ＬＩＳＴ型のポイントが１、ＭＡＰ型のポイントが２に設定されているので、ＬＩＳＴ型１０ポイント、ＭＡＰ型２２ポイント（キーがｎａｍｅ）及び２１ポイント（キーがｔｙｐｅ）となる。従って、最終的なインスタンス配置情報はキーをｎａｍｅとするＭＡＰ型として設定することとなり、最終的にプログラムコードを生成するとキーをｎａｍｅとするＭＡＰ型を生成する。
【００９２】
本実施形態においては、ポイントを設定しているがポイントではなく別の優先度の設定方法を用いても同様の作用・効果が得られる。
【００９３】
以上説明してきたように、インスタンス配置情報を更新する場合に、インスタンスアクセス情報に対してポイントを適用することによって、メモリ消費量と検索にかかるコストのトレードオフを図りながら、関連を表すプログラムコードの実装方法を決定することが可能となる。
【００９４】
このように、これらの実施形態によれば、ソフトウェアの設計図面からプログラムコードを自動生成する際、１対多及び多対多の関連のクラスについてはインスタンス配置情報に従ったプログラムコードを生成するプログラムコード生成装置を提供することができる。
【００９５】
また、これらのプログラムコード生成装置は、インスタンス配置情報を更新するために、あるインスタンスが保持しているインスタンスのアクセス状況をログ出力可能なプログラムコードを生成することができる。そして、そのログからコンテナの実装方法を決めるためのインスタンスアクセス情報２１７を抽出することが可能である。さらに、インスタンスアクセス情報をもとにインスタンスを保持するコンテナについて最適なプログラムコードをインスタンス配置情報として更新することができる。更に、これらのプログラムコード生成装置は、コンテナ実装について、インスタンスアクセス情報からインスタンス配置情報を更新することで、インスタンスの検索コストを考慮しメモリ消費量を抑えたプログラムコードを生成できる。
【００９６】
なお、本発明の実施形態は、例えばコンピュータがプログラムを実行することによって実現することができる。また、プログラムをコンピュータに供給するための手段、例えばかかるプログラムを記録したＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体又はかかるプログラムを伝送するインターネット等の伝送媒体も本発明の実施形態として適用することができる。また、上記のプログラムも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体及びプログラムプロダクトは、本発明の範疇に含まれる。
【図面の簡単な説明】
【００９７】
【図１】本発明の第１の実施形態に係るプログラムコード生成装置の構成ブロック図である。
【図２】本発明の第１の実施形態に係るプログラムコード生成装置のデータフロー図である。
【図３】本発明の第１の実施形態におけるシステム全体のフローチャート図である。
【図４】本発明の第１の実施形態におけるプログラムコード生成ルーチンに関するフローチャート図である。
【図５Ａ】ある設計図面の一部を示したイメージ図である。
【図５Ｂ】クラス間の連携を実装するコンテナに関する特徴を表す表を示す図である。
【図６】本発明の第１の実施形態におけるインスタンス配置情報の更新ルーチンに関するフローチャート図である。
【図７】本発明の第１の実施形態におけるログ出力プログラムコードによって出力されたログを示すイメージ図である。
【図８】本発明の第１の実施形態におけるログを解析した結果得られるインスタンスアクセス情報を示すイメージ図である。
【図９】本発明の第１の実施形態におけるプログラムコード生成装置によって生成されるプログラムコードのなかでコンテナをMAP型で実装した例を示したイメージ図である。
【図１０】本発明の第１の実施形態におけるプログラムコード生成装置によって生成されるプログラムコードのなかでコンテナをLIST型で実装した例を示したイメージ図である。
【図１１】本発明の第２の実施形態におけるインスタンス配置情報の更新ルーチンに関するフローチャート図である。
【図１２】本発明の第２の実施形態におけるログを解析した結果得られるインスタンスアクセス情報を示すイメージ図である。
【符号の説明】
【００９８】
１：ＣＰＵ
２：バス
３：ＲＯＭ
４：ＲＡＭ
４ａ：設計図面情報
４ｂ：プラットフォーム依存情報
４ｃ：プログラムコード
４ｄ：インスタンス配置情報
４ｅ：ライブラリ
４ｆ：プログラム実行形式
５：入力インターフェイス
６：キーボード、ボタン、マウス、ダイアル
７：出力インターフェイス
８ａ：ＣＲＴ、ＬＣＤ
８ｂ：プリンタ、プロッタ
９：外部記憶装置インターフェイス
１０：ＨＤ、ＦＤ、ＣＤ−ＲＯＭ、ＭＤ、ＣＦ、・・・（ファイル）
２０１：ＧＵＩ入力処理部
２０２：自動生成装置起動部
２０３：設計図面情報入力部
２０４：プラットフォーム依存情報入力部
２０５：インスタンス配置情報更新部
２０６：設計図面情報
２０７：プラットフォーム依存情報
２０８：インスタンス配置情報
２０９：プログラム生成部
２１０：プログラムコード
２１１：ライブラリ
２１２：コンパイラ・リンカ
２１３：プログラム実行形式
２１４：プログラム実行部
２１５：プログラム実行ログ
２１６：実行ログ解析部
２１７：インスタンスアクセス情報
３０１：クラス名がＡＡＡであるクラス
３０２：クラス名がＢＢＢであるクラス
３０３：クラスＡＡＡとクラスＢＢＢの関連
【技術分野】
【０００１】
本発明は、ソフトウェアの設計図面からプログラムコードを自動生成することを特徴とするプログラムコード生成装置等に関する。
【背景技術】
【０００２】
近年のソフトウェア設計技術として、モデル駆動型アーキテクチャー(Model Driven Architecture技術（以降、ＭＤＡ技術と称す）が広まり、採用されるようになってきている。一般的にＭＤＡ技術とは、オペレータが入力したソフトウェアの設計図面情報から各種プラットフォームのプログラムコードを自動的に生成し、且つ、入力したソフトウェアの設計図面情報をＭＤＡ専用ツール上で動作および検証することが可能な技術である。これらソフトウェアの設計図面情報の代表的な例としては、オブジェクト指向技術のモデル表記言語であるＵＭＬ（Unified Modeling Language）やＳＤＬ（Specification & Description Language）などが挙げられる。
【０００３】
しかしながら、既存のプログラム生成装置から生成されるプログラムコードは、設計図面からプログラムコードに変換するルールによっては、生成されるコードのサイズが大きく、実行のために多くのＲＡＭを必要とするという問題がある。このため、組み込みシステムなどのメモリ容量の制限が厳しい領域では、ＭＤＡ技術の導入に躊躇するケースが少なくない。
【０００４】
設計図面の段階での最適化を行う技術が、特許文献１（特開平１１−２３７９８０号公報）及び特許文献２（特開２００４−１１８８６５号公報）に開示されている。これらの技術は、オブジェクト指向機能排除手段を用いて仮想関数の機能を排除、もしくはインスタンスの動的生成の機能を排除することで必要なメモリ容量を増加させることなく組み込み制御システムに適用可能なコードの最適化を行うことを可能にしている。更に、組み込みシステムのソフトウェア開発におけるＲＡＭ容量を削減する技術が特許文献３（特開２０００−４０００５号公報）及び特許文献４（特開２００１−１８４２１４号公報）に開示されている。これらの技術は、プログラムコード中のｃｏｎｓｔ指定されたインスタンス変数やオブジェクトをＲＯＭ上に配置することにより、ＲＡＭ容量の削減を図っている。また、特許文献５（特開２００２−９１７６２号公報）に記載の技術は、ＲＯＭのデータへのアドレスをＲＡＭへ再配置する際のアドレス変換に関するもので、設計図面のデータを解析するが、ＲＡＭ上のどこに配置するかについては触れられていない。これらの提案で述べられている最適化は、プログラムコードの生成時に限定された工夫であり、ＭＤＡ技術の実行可能モデルを考慮したものではない。
【０００５】
オブジェクト指向型プログラムでは、クラスの実体であるインスタンス同士が互いに協調動作することによって１つの機能を実現している。あるインスタンスが生成されるとそのインスタンスに働きかける別のインスタンスは、関連を保持するための領域についてメモリ領域を確保し、インスタンス同士で協調動作を実現する。インスタンス同士の関連が１対１の関連であれば、インスタンス自体を参照する領域が１つ存在すれば十分である。しかしながら、インスタンス同士の関連が１対多の場合や多対多の場合では、複数のインスタンスを保持するためのコンテナをメモリ領域に確保することが必要となる。複数のインスタンスを保持するコンテナは、配列型やＬＩＳＴ型やＭＡＰ型などで実現される。
【０００６】
１対多の関連の場合は、インスタンス同士の関連が動的に変化するために、コンテナ領域を動的に確保する必要がある。コンテナ領域は、インスタンスと関連がある別のインスタンスへの参照と次のコンテナへの参照を連続で持つことによって複数インスタンスとの関連を保持することができる。例えば、クラスＸとクラスＹの間に１対多の関連が存在し、クラスＸのインスタンス（ｘ１）がクラスＹのインスタンス（ｙ１，ｙ２，ｙ３）をＬＩＳＴ型のコンテナで実現すると、インスタンスｘ１は、ｙ１からｙ３まで辿ることが可能なリスト形式のコンテナとして関連を持つことになる。そして、クラスＸとクラスＹにおいてデータのやり取りが発生する場合は、インスタンスｘ１が持つＬＩＳＴ型のコンテナからクラスＹのインスタンスをキー検索することで、関連付けられている複数のインスタンスから特定のインスタンスと協調動作することが可能となる。
【０００７】
【特許文献１】特開平１１−２３７９８０号公報
【特許文献２】特開２００４−１１８８６５号公報
【特許文献３】特開２０００−４０００５号公報
【特許文献４】特開２００１−１８４２１４号公報
【特許文献５】特開２００２−９１７６２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
コンテナの実装方法にはメモリ使用量や検索にかかるコストなどから様々な方法が存在する。一般に検索にかかるコストを抑えた実装方法を選択すると、メモリ使用量が大となる。つまり、コンテナの実装方法は検索にかかるコストとメモリの消費量はトレードオフの関係となっている。そのため、メモリ消費量や検索コストの面から最適な実装方法でプログラムコードを生成する必要がある。しかしながら、ＭＤＡ技術を利用した場合は、プログラムの特性に応じてコンテナの実装方法を変更しておらず、メモリ消費量やインスタンスの検索にかかるコストについて何ら考慮がなされていない状況となっている。
【課題を解決するための手段】
【０００９】
本発明は、実際に実行した結果であるインスタンスへのアクセス状況と、設計図面であるモデル情報から、インスタンスの保持方法であるコンテナを実装するプログラムコードについて、インスタンスへのアクセス頻度やアクセスパターンから最適なプログラムコードを選択する。これにより、設計者はソフトウェアの設計図面における関連について最適な実装方法を自動で出力することが可能となる。
【００１０】
上記の目的を達成するために本発明は、プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である設計図面を解析する設計図面解析工程と、前記設計図面情報に基づいて1対多の関連に対してプログラムコード生成規則を定めるインスタンス配置工程と、データアクセスが何回発生したかを示すインスタンスアクセス情報を更新するインスタンス配置情報更新工程と、前記インスタンス配置情報に基づいてプログラムコードを生成するプログラムコード生成工程とを備えることを特徴とするプログラムコード生成方法等、を提供する。
【発明の効果】
【００１１】
本発明によれば、ソフトウェアの設計図面からプログラムコードを自動生成する際、1対多及び多対多の関連のクラスについてはインスタンス配置情報に従ったプログラムコードを生成するプログラムコード生成装置を提供することができる。
【発明を実施するための最良の形態】
【００１２】
以下、添付の図面に沿って本発明の実施形態について説明する。
【００１３】
（第１の実施形態）
図１は、本発明の第１の実施形態を示す全体構成図である。１はＣＰＵであり、以下に説明する３〜１０の装置を２で示すバスを介してアクセスし制御を行う。３はバス２を介してＣＰＵ１からアクセス可能な読み出し専用メモリ（ＲＯＭ）であり、本実施形態ではその動作を詳細に説明する処理プログラム３ａ及び処理プログラムにより使用されるパラメータ３ｂが格納されている。４は読み書き可能なメモリ（ＲＡＭ）である。ＲＡＭ４上には、領域４ａ、４ｂ、４ｃ、４ｄ、４ｅ、４ｆ、４ｇ及び４ｈが確保されている。これらの領域４ａ〜４ｈには、設計図面情報、プラットフォーム依存情報、プログラムコード、インスタンス配置情報、ライブラリ、プログラム実行形式、インスタンスアクセス情報及びインスタンス配置情報が夫々格納される。これらの設計図面情報、プラットフォーム依存情報、プログラムコード、インスタンス配置情報、ライブラリ、プログラム実行形式、インスタンスアクセス情報及びインスタンス配置情報は、上記処理プログラム３により作成／変更がなされる。５は入力インターフェイスであり、６で示したキーボード、マウス、ボタン、ダイアル等の入力装置を介してなされる入力を受け取る。７は出力インターフェイスであり、８で示したＣＲＴ，ＬＣＤ等の表示媒体、更にはプリンタ、プロッタ等の出力装置に対し、データの表示／出力を行なう。また、９は外部記憶装置インターフェイスであり、１０で示したＨＤ、ＦＤ、ＣＤ−ＲＯＭ、ＭＤ、ＣＦ等の外部記憶装置に対するデータの入出力を行うものである。
【００１４】
本実施形態では、処理プログラム３ａやパラメータ３ｂがＲＯＭ３上にあるものとして、また、処理対象となる各データの格納領域（４ａ〜４ｈ）がＲＡＭ上にあるものとして説明を行う。但し、これらはすべて、外部記憶装置上に配置することも可能であり、必要に応じて外部記憶装置からＲＡＭ上にロードして使用することもできる。また、ＣＰＵのキャッシュメモリ上に配置することも同様に可能である。
【００１５】
図２は、図１において３ａで示した処理プログラムの構成要件とそれら構成要件が図１の４ａ〜４ｆで示した格納領域に格納されるデータとどのような関係にあるかを示すデータフロー図である。
【００１６】
２０１は、図１における入力インターフェイス５を介して入力されるデータを扱うＧＵＩ入力処理部であり、ユーザはこのＧＵＩ入力処理部２０１によりデータの入力や編集と、各処理部へ指示できるようになっている。本実施形態に係るプログラムコード生成装置においては、自動生成装置起動部２０２として利用する。
【００１７】
２０３は、外部記憶装置１０に格納されている、プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向であることを特徴とする設計図面を読み込み、設計図面情報２０６を生成する設計図面情報入力部である。
【００１８】
２０４は、プラットフォーム依存情報入力部である。プラットフォーム依存情報入力部２０４は、外部記憶装置１０に格納されている、実行ファイルの動作するＯＳやＣＰＵやメモリ量やプログラミング言語や利用フレームワークを含む情報を読み込み、プラットフォーム依存情報２０７を生成する。
【００１９】
２０５は、インスタンスの実装コードにおけるコレクションの型を決定するためのインスタンス配置情報２０８を更新するインスタンス配置情報更新部である。
【００２０】
２０９は、設計図面情報２０６やプラットフォーム依存情報２０７やインスタンス配置情報２０８からプログラムコード２１０を生成するプログラム生成部である。プログラム生成部２０９はインスタンス配置情報入力部によって選択されたインスタンス配置情報２０８を使って、プログラムコードを生成する。プログラム生成部２０９が生成可能なプログラムコードとして、インスタンスのコレクション型を決定したプログラムコードや、インスタンスへのアクセスログを出力することが可能なコードを付加したプログラムコード等が挙げられる。
【００２１】
２１１は、プログラムコード２１０から参照されるライブラリである。
【００２２】
２１２は、プログラムコード２１０とライブラリ２１１をコンパイル・リンクするコードコンパイラ・リンカである。
【００２３】
２１３は、コードコンパイラ・リンカ２１２が生成したプログラム実行形式である。
【００２４】
２１４は、プログラム実行形式２１３を実行する実行部である。プログラム実行形式２１３がインスタンスへのアクセスログを出力することが可能なコードを付加したプログラム実行形式２１３であった場合、ここでのプログラム動作時にプログラム実行ログ２１５を出力する。
【００２５】
２１５は、プログラム実行部２１４でプログラム実行時に出力されたプログラム実行ログであり、いつ、どのクラスのインスタンスへのアクセスがあったかどうかをログ出力する。
【００２６】
２１６は、プログラム実行ログ２１５を使って、インスタンスへのアクセスログを解析する実行ログ解析部である。
【００２７】
２１７は、実行ログ解析部２１６より算出されたインスタンスアクセス情報である。
【００２８】
これ以降の説明におけるフローチャートによる処理手順は、例に限定されることはなく、本発明の結果を満たす限りいかなる手順の組み合わせも、複数処理をまとめることも、処理を細分化することも可能である。また、各処理を個々に切り出してひとつの機能要素として単体として機能し、示している処理以外の処理と組み合わせて使用することも可能である。
【００２９】
以下、本発明の実施形態の動作について図面及びフローチャートを参照して説明する。
【００３０】
図３は、本実施形態のシステム全体の処理手順を示したフローチャート図である。本システムの起動は（ステップＳ１０１）、ＧＵＩ入力処理部２０１などの入力部からオペレータが指示する。
【００３１】
ステップＳ１０２で、設計図面情報入力部２０３が設計図面を読込み、プログラム生成部２０９が処理できるデータ形式に変換した設計図面情報２０６を生成する。
【００３２】
ステップＳ１０３で、プラットフォーム依存情報入力部２０４が、プログラム生成部２０９が処理できるデータ形式に変換したプラットフォーム依存情報２０７を生成する。
【００３３】
ステップＳ１０４で、プログラム生成部２０９は、設計図面情報２０６とプラットフォーム依存情報２０７を用いてプログラムコード２１０を生成する。ここで、オペレータからの指示がある場合だけ、インスタンス配置情報２０８を使って、インスタンスの保持方法を特定したプログラムコードを生成する。更に、オペレータからの指示があれば、生成するプログラムコード２１０に対し、いつ、どのインスタンスにアクセスしたかを出力するプログラム実行ログ２１５を生成するプログラムコードを付加する。プログラムコード生成ルーチンに関しては、次に詳しく説明する。
【００３４】
ステップＳ１０５で、コンパイラ・リンカ２１２はプログラムコード２１０とライブラリ２１１をコンパイル・リンクし、プログラム実行形式２１３を生成する。
【００３５】
ステップＳ１０６で、プログラム実行部２１４はプログラム実行形式２１３を実行する。ここでプログラム実行形式２１４が、ログ出力機能を付加したプログラムコード２１０の実行形式だった場合、このステップ時にプログラム実行ログ２１５が出力される。
【００３６】
ステップＳ１０７で、実行ログ解析部２１６は、プログラム実行ログを生成するプログラムコードが付加されていて、かつプログラム実行ログ２１５があるかどうかを判断する。プログラム実行ログがあった場合は、ステップＳ１０８へ進む。ステップＳ１０７で、プログラム実行ログがなかった場合は、ステップＳ１０９へ進む。
【００３７】
ステップＳ１０８で、実行ログ解析部２１６はプログラム実行ログ２１５を解析する処理を行い、インスタンスアクセス情報２１７を生成する処理を行う。
【００３８】
ステップＳ１０９で、インスタンス配置情報更新部２０８は、インスタンスアクセス情報が存在して、かつインスタンス配置情報を更新するかどうかを判断する。インスタンス配置情報を更新する場合は、ステップＳ１１０へ進む。ステップＳ１０９でインスタンス配置情報を更新しない場合は、ステップＳ１１１へ進み、本シーケンスを終了する。
【００３９】
ステップＳ１１０で、インスタンス配置情報更新部２０８は、インスタンス配置情報を更新する処理を行う。インスタンス配置情報更新ルーチンに関しては、次に詳しく説明する。
【００４０】
本実施形態においては、ＧＵＩ入力処理部２０１から、オペレータによって、プログラム生成部２０９とコンパイラ・リンカ２１２、プログラム実行部２１４、実行ログ解析部２１６を起動しているが、この方法によらない。
【００４１】
図４は、図３のプログラムコード生成ルーチンＳ１０４の流れを説明したフローチャート図である。プログラムコード生成ルーチンが呼び出されると、ステップＳ２０２で、全てのクラスについて、プログラムコード生成が完了するまでステップＳ２０３からステップＳ２１１を繰り返す処理を行う。全てのクラスについてプログラムコード生成が完了していなかったら、ステップＳ２０３へ進む。
【００４２】
ステップＳ２０３で、クラスに存在する全ての関連についてのプログラムコード生成について、プログラムコード生成が完了するまでステップＳ２０４からステップＳ２１０を繰り返す処理を行う。全ての関連についてプログラムコード生成が完了していなかったら、ステップＳ２０４へ進む。
【００４３】
ステップＳ２０４で、設計図面情報２０６の中で関連が１対多の関連か１対１の関連かを判断する処理を行う。
【００４４】
ステップＳ２０４で、１対１の関連の場合は、ステップＳ２０８へ進む。１対多の関連の場合は、ステップＳ２０５へ進む。
【００４５】
ステップＳ２０５で、インスタンス配置情報２０８に基づいてコレクションについてプログラムコードを自動生成するかどうかを判断する処理を行う。ステップＳ２０５で、インスタンス配置情報２０８を用いてプログラムコード生成をする場合は、ステップＳ２０６へ進む。インスタンス配置情報２０８を用いない場合は、ステップＳ２０７へ進む。
【００４６】
ステップＳ２０６で、インスタンス配置情報に記載の型でインスタンス同士の関連についてプログラムコードを生成する処理を行う。
【００４７】
ステップＳ２０７で、リスト構造でインスタンス同士の関連についてプログラムコード生成する処理を行う。
【００４８】
ステップＳ２０８で、インスタンス同士の関連は１対１であるので、直接参照するプログラムコードを生成する処理を行う。
【００４９】
ステップＳ２０９で、プログラムコードに対して、ログを付加するかどうかを判断する処理を行う。ステップＳ２０９でログを付加する場合は、ステップＳ２１０へ進む。ステップＳ２０９で、ログを付加しない場合は、ステップＳ２１１へ進む。
【００５０】
ステップＳ２１０で、プログラムコードに対してログ出力を行うプログラムコードを付加する処理を行う。
【００５１】
ステップＳ２１１で、全ての関連についてプログラムコード生成が完了すると、ステップＳ２１２へ進む。
【００５２】
ステップＳ２１２で、全てのクラスについてプログラムコード生成が完了すると、ステップＳ２１３へ進み本シーケンスを終了する。
【００５３】
図５Ａは、ある設計図面の一部を示したイメージ図である。図５Ａにおいて、３０１は、クラス名がＡＡＡであるクラスを示している。３０２は、クラス名がＢＢＢであるクラスを示している。３０３は、クラスＡＡＡとクラスＢＢＢが１対多の関連であることを示しており、クラスＡＡＡからクラスＢＢＢへの関連がＡ１であることを示している。
【００５４】
図５Ｂは、クラス間の連携を実装するコンテナに関する特徴を示した表である。キー検索とは、あるインスタンスと関連のある複数のインスタンスの中から、特定のインスタンスをキーをもとに検索してからアクセスする形式である。Ｅｎｕｍとは、あるインスタンスと関連のある複数のインスタンス全てに対してアクセスする形式である。ＭＡＰ型は、インスタンスとそのキーを登録しておくのでキー検索にかかるコストは少なくい構造となる。ＬＩＳＴ型や配列型の場合は、コンテナの構造が簡素であるか複雑であるかの違いはあるが、対象のインスタンスが見つかるまで全インスタンスを走査するため、キー検索にかかるコストは高くなる構造となる。また、Ｅｎｕｍ形式の場合では、コンテナの構造が簡素であるか複雑であるかの違いによりメモリ消費量に違いはあるが、ＥｎｕｍにかかるコストはＭＡＰ型、配列型、ＬＩＳＴ型に違いはない。
【００５５】
図６は、図３のインスタンス配置情報の更新ルーチンＳ１１０の流れを詳細に説明したフローチャート図である。図５Ｂの表で示しているようにアクセス形式にキー検索がある場合は、キー検索にかかるコスト（処理のオーダー）の低いＨＡＳＨ型が有効である。そのため、ある一定以上のインスタンスを関連として持つ（コレクション）場合は、キー検索のコストを考えＨＡＳＨ型を選択する。ＬＩＳＴ型と配列型では、キー検索にかかるコストは同じであるが、構造の複雑さからＥｎｕｍ形式のアクセス頻度の違いによって、配列型かＬＩＳＴ型を選択する。
【００５６】
インスタンス配置情報の更新ルーチンが呼び出されると、ステップＳ３０２で、全てのクラスについて、インスタンスアクセス情報２１７からインスタンス配置情報２０８の更新が完了するまでステップＳ３０３からステップＳ３１５を繰り返す処理を行う。全てのクラスについてインスタンス配置情報２０８の更新が完了していなかったら、ステップＳ３０３へ進む。
【００５７】
ステップＳ３０３で、クラスに存在する１対多の関連に関するインスタンス配置情報２０８の更新について、更新が完了するまでステップＳ３０４からステップＳ３１４を繰り返す処理を行う。全てのインスタンス配置情報２０８の更新が完了していなかったら、ステップＳ３０４へ進む。
【００５８】
ステップＳ３０４で、対象としている関連についてのインスタンスアクセス情報を読み取り、キー検索があるかどうかを判断する処理を行う。ステップＳ３０４でキー検索がある場合は、ステップＳ３０５へ進む。キー検索がない場合は、ステップＳ３０９へ進む。
【００５９】
ステップＳ３０５で、対象としている関連についてのインスタンスアクセス情報を読み取り、コレクションの総インスタンス数を取得する処理を行う。
【００６０】
ステップＳ３０６で、前もって設定している関連を実装するコンテナを決定するための閾値を取得する処理を行う。
【００６１】
ステップＳ３０７で、ステップＳ３０５で取得したコレクションの総インスタンス数とステップＳ３０６で取得した閾値を比較する処理を行う。ステップＳ３０７でコレクションの総インスタンス数が閾値よりも大である場合は、ステップＳ３０８へ進む。ステップＳ３０７でコレクションの総インスタンス数が閾値よりも小である場合は、ステップＳ３０９へ進む。
【００６２】
ステップＳ３０８で、対象としている関連についてのインスタンス配置情報をＨＡＳＨ型に設定する処理を行う。
【００６３】
ステップＳ３０９で、対象としている関連についてインスタンスアクセス情報を読み取り、Ｅｎｕｍ形式があるどうかを判断する処理を行う。ステップＳ３０９で、Ｅｎｕｍ形式がある場合は、ステップＳ３１１へ進む。Ｅｎｕｍ形式がない場合は、ステップＳ３１０へ進む。
【００６４】
ステップＳ３１０で、対象としている関連についてのインスタンス配置情報２０８をＬＩＳＴ型に設定する処理を行う。
【００６５】
ステップＳ３１１で、対象としている関連についてのインスタンスアクセス情報を読み取り、Ｅｎｕｍ形式のアクセス頻度を取得する処理を行う。
【００６６】
ステップＳ３１２で、前もって設定している関連を実装するコンテナを決定するための閾値を取得する処理を行う。
【００６７】
ステップ３１３で、ステップＳ３１１で取得した総数とステップＳ３１２で取得した閾値を比較する処理を行う。ステップＳ３１３で総数が閾値よりも大である場合は、ステップＳ３１４へ進む。ステップＳ３１３で総数が閾値よりも小である場合は、ステップＳ３１０へ進む。
【００６８】
ステップＳ３１４で、対象としている関連についてのインスタンス配置情報２０８を配列型に設定する処理を行う。
【００６９】
ステップＳ３１５で、全ての関連についてインスタンス配置情報２０８の更新が完了すると、ステップＳ３１６へ進む。
【００７０】
ステップＳ３１６で、全てのクラスについてインスタンス配置情報２０８が完了すると、ステップＳ３１７へ進み、本シーケンスを終了する。
【００７１】
図７は、図５Ａの設計図面を入力として、図４のフローチャート図によってプログラムコードが生成され、そのプログラムコードをコンパイル・リンクし、その結果生成されるプログラム実行形式を実際に実行した結果得られるログの一例を示したイメージ図である。図７において、４０１は、クラスＡＡＡの関連Ａ１において、関連Ａ１が保持するインスタンスに対するアクセスが発生した時のログを示している。４０２から４０４は、特定のインスタンスを取得するためのログを示している。４０２は、関連Ａ１に対して、キー“ｎａｍｅ”で検索されたことを示しており、関連によって保持されているインスタンスを４回にわたってチェックした結果、対象インスタンスを取得することが出来たことを示している。４０３及び４０４においても、４０２と同様である。４０５は、関連によって保持されている全インスタンスに対して処理が発生したことを示すログとなっている。
【００７２】
図８は、図７のログを解析した結果得られるインスタンスアクセス情報２１７を示したイメージ図である。図８中の５０１は、次の事項を示している。即ち、クラスＡＡＡにおいて関連Ａ１が存在し、その関連Ａ１に対してキーが“ｎａｍｅ”であるインスタンスが存在するかどうかを検索する処理が発生し、対象インスタンスを取得するのに４回のアクセスが関連Ａ１に対して生じたことを示している。５０２は、関連が保持する全インスタンス４つに対して連続アクセスが発生したことを示している。また、特定インスタンスに対するアクセスが３回、全インスタンスに対する連続アクセスが１回それぞれ発生したことを示している。
【００７３】
図４で示したフローチャートを実行すると、図８のインスタンスアクセス情報を解析し、インスタンス配置情報を更新する。キー検索に関する閾値が３である場合は、インスタンスアクセス情報２１７において総インスタンス数が４個であることからインスタンス配置情報２０８はＭＡＰ型に設定される。キー検索に関する閾値が４で、Ｅｎｕｍ形式のアクセス頻度が１である場合は、ＬＩＳＴ型に設定される。キー検索に関する閾値が４で、Ｅｎｕｍ形式のアクセス頻度が０である場合は、配列型に設定される。以上説明したように、図４で示したフローチャートを実行することによって、インスタンスアクセス情報２１７からインスタンス配置情報２０８を更新する。
【００７４】
図９は、“ＭＡＰ”を用いて生成されたプログラムコードの一例である。図９において、６０１は、クラスのコンストラクタであり、例えばコンストラクタの中でクラス間の関連（ＭＡＰ）を生成するプログラムコードが生成される。６０２は、クラス間の関連において保持されているインスタンスについて、特定のインスタンスを取得するプログラムコードであり、例えばＭＡＰを使用している場合は、引数にキーを与えることで特定のインスタンスをＭＡＰから取得することが出来る。６０３は、クラス間の関連に新たにインスタンスを追加するプログラムコードであり、例えばＭＡＰに登録するときは、インスタンスとそのインスタンスを検索するキーを同時に登録する。ＭＡＰは、メモリ消費量が大であるかわりに検索スピードが高速であることが知られており、ＭＡＰを関連に対するプログラムコードとして生成することによって、特定のインスタンスを検索するのにかかるコストを抑えることが可能となる。
【００７５】
図１０は、“ＬＩＳＴ”を用いて生成されたプログラムコードの一例である。図１０において、７０１は、クラスのコンストラクタであり、例えばコンストラクタの中でクラス間の関連（ＬＩＳＴ）を生成するプログラムコードが生成される。７０２は、クラス間の関連において保持されているインスタンスについて、特定のインスタンスを取得するプログラムコードである。例えばＬＩＳＴを使用している場合は、ｗｈｉｌｅ文などによりすべてのインスタンスに対して、キーと一致するインスタンスが現れるまでループを実行することで実現する。７０３は、クラス間の関連に新たにインスタンスを追加するプログラムコードであり、例えばＬＩＳＴに登録するときは、インスタンスを登録する。ＬＩＳＴ型は、ＭＡＰ型よりもメモリ消費量が小であるかわりに検索にかかるコストがＭＡＰよりも大であることが知られており、ＬＩＳＴ型を関連に対するプログラムコードとして生成することによって、メモリ消費量を抑えることができる。
【００７６】
本実施形態では、あるインスタンスと関連のある別のインスタンスのコンテナに関わるプログラムコード生成について、閾値としてインスタンスの総数やアクセスした総数をもとに変更しているが、閾値として数ではなく割合であっても同様の作用・効果が得られる。
【００７７】
（第２の実施形態）
次に、本発明の第２の実施形態について説明する。第２の実施形態では、第１の実施形態に加え、インスタンス配置情報の更新（図３のステップＳ１１０）において、インスタンスアクセス情報のアクセス情報に優先度を考慮して、インスタンス配置情報更新部２０５でインスタンス配置情報２０８を更新する。インスタンス配置情報を更新する場合のフローチャートを、図１１に示す。
【００７８】
図１１は、第２の実施形態におけるインスタンス配置情報２０８を更新する場合のフローチャート図である。図５Ｂの表で示しているようにアクセス形式にキー検索がある場合は、キー検索にかかるコスト（処理のオーダー）の低いＨＡＳＨ型が有効である。しかしながら、キー検索にかかるコストが低いかわりメモリ消費量が高いため、キー検索がそれほど実行されない場合では、ＨＡＳＨ型を選択してもそれほど効果が得られない場合も存在する。このような場合は、ＨＡＳＨ型ではなくＬＩＳＴ型の方がいいかどうかをキー検索形式の頻度やＥｎｕｍ形式の頻度をもとに計算する。
【００７９】
ステップＳ４０２で、各型を使用する優先度に応じて割り振られたポイントを取得する処理を行う。例えば、関連を実装するプログラムコードをＬＩＳＴ型かＭＡＰ型とする場合において、検索スピードよりもメモリ消費量を抑えたい場合には、ＬＩＳＴ型のポイントをＭＡＰ型よりも高く設定する。
【００８０】
ステップＳ４０３で、全てのクラスについて、インスタンスアクセス情報２１７からインスタンス配置情報２０８の更新が完了するまでステップＳ４０４からステップＳ４１０を繰り返す処理を行う。全てのクラスについてインスタンス配置情報２０８の更新が完了していなかったら、ステップＳ４０４へ進む。
【００８１】
ステップＳ４０４で、クラスに存在する１対多の関連に関するインスタンス配置情報２０８の更新について、更新が完了するまでステップＳ４０５からステップＳ４０９を繰り返す処理を行う。全てのインスタンス配置情報２０８の更新が完了していなかったら、ステップＳ４０５へ進む。
【００８２】
ステップＳ４０５で、Ｅｎｕｍ形式のアクセス回数をインスタンスアクセス情報２１７から取得し、そのアクセス数とステップＳ４０２で取得したポイント数から各型のポイント数を計算する処理を行う。
【００８３】
ステップＳ４０６で、キー検索形式について、全てのキーが完了するまでステップＳ４０７を繰り返す処理を行う。全てのキーが完了していなかったら、ステップＳ４０７へ進む。
【００８４】
ステップＳ４０７で、特定インスタンスのアクセスの回数をインスタンスアクセス情報２１７から取得し、そのアクセス数とステップＳ４０２で取得したポイント数から各型のポイント数を計算する処理を行う。
【００８５】
ステップＳ４０８で、全てのキーについて完了すると、ステップＳ４０９へ進む。
【００８６】
ステップＳ４０９で、ステップＳ４０５とステップＳ４０７から得られた各型のポイント数から、インスタンス配置情報を設定する処理を行う。
【００８７】
ステップＳ４１０で、全ての関連についてプログラムコード生成が完了すると、ステップＳ４１１へ進む。
【００８８】
ステップＳ４１１で、全てのクラスについてプログラムコード生成が完了すると、ステップＳ４１２へ進み本シーケンスを終了する。
【００８９】
図１２は、第１の実施形態と同様のインスタンスアクセス情報２１７を示したイメージ図である。図１２中の８０１は、次の事項を示している。即ち、クラスＡＡＡにおいて関連Ａ１が存在し、その関連Ａ１に対してキーが“ｎａｍｅ”であるインスタンスが存在するかどうかを検索する処理が発生し、対象インスタンスを取得するのに４回のアクセスが関連Ａ１に対して生じたことを示している。８０２は、クラスＡＡＡにおいて関連Ａ１が存在し、その関連Ａ１に対してキーが“ｎａｍｅ”であるインスタンスが存在するかどうかを検索する処理が発生し、対象インスタンスを取得するのに２回のアクセスが関連Ａ１に対して生じたことを示している。８０３は、クラスＡＡＡにおいて関連Ａ１が存在し、その関連Ａ１に対してキーが“ｔｙｐｅ”であるインスタンスが存在するかどうかを検索する処理が発生し、対象インスタンスを取得するのに５０回のアクセスが関連Ａ１に対して生じたことを示している。８０４は、関連が保持する全インスタンス数１００に対して連続アクセスが発生したことを示している。また、同様のアクセスが、この他にも合計１０回発生していることを示している。
【００９０】
図１１で示したフローチャートを実行すると、図１２のインスタンスアクセス情報を解析し、インスタンス配置情報を更新する。例えば、検索にかかるコストよりもメモリ消費量を抑えたい場合には、ＬＩＳＴ型のポイントを２、ＭＡＰ型のポイントを１のようにＬＩＳＴ型のポイントを高く設定する。図１２の場合において、全インスタンスへの連続アクセスについて、全インスタンスへのアクセスが１０回発生するため、ＬＩＳＴ型のポイントは２０ポイントとなる。同様にＭＡＰ型のポイントは１０ポイントとなる。図１２の場合において、特定インスタンスへのアクセスについて、ｎａｍｅをキーとしてアクセスする場合は、２回存在しているため、ＬＩＳＴ型のポイントは０、ＭＡＰ型のポイントは２となる。また、特定インスタンスへのアクセスについて、ｔｙｐｅをキーとしてアクセスする場合は、１回存在しているため、ＬＩＳＴ型のポイントは０、ＭＡＰ型のポイントは１となる。この結果、図１２のようなインスタンスアクセス情報において、メモリ消費量を抑える方針の場合には、次のようになる。即ち、ＬＩＳＴ型のポイントが２、ＭＡＰ型のポイントが１に設定されているので、ＬＩＳＴ型２０ポイント、ＭＡＰ型１２ポイント（キーがｎａｍｅ）及び１１ポイント（キーがｔｙｐｅ）となる。従って、最終的なインスタンス配置情報はＬＩＳＴとして設定することとなり、最終的にプログラムコードを生成するとＬＩＳＴ型を生成する。
【００９１】
また、メモリ消費量検索よりも検索にかかるコストを抑えたい場合には、ＬＩＳＴ型のポイントを１、ＭＡＰ型のポイントを２のようにＭＡＰ型のポイントを高く設定する。図１２の場合において、全インスタンスへの連続アクセスについて、全インスタンスへのアクセスが１０回発生するため、ＬＩＳＴ型のポイントは１０ポイントとなる。同様にＭＡＰ型のポイントは２０ポイントとなる。図１２の場合において、特定インスタンスへのアクセスについて、ｎａｍｅをキーとしてアクセスする場合は、２回存在しているため、ＬＩＳＴ型のポイントは０、ＭＡＰ型のポイントは４となる。また、特定インスタンスへのアクセスについて、ｔｙｐｅをキーとしてアクセスする場合は、１回存在しているため、ＬＩＳＴ型のポイントは０、ＭＡＰ型のポイントは２となる。この結果、図１２のようなインスタンスアクセス情報において、検索コストを抑える方針の場合には、次のようになる。即ち、ＬＩＳＴ型のポイントが１、ＭＡＰ型のポイントが２に設定されているので、ＬＩＳＴ型１０ポイント、ＭＡＰ型２２ポイント（キーがｎａｍｅ）及び２１ポイント（キーがｔｙｐｅ）となる。従って、最終的なインスタンス配置情報はキーをｎａｍｅとするＭＡＰ型として設定することとなり、最終的にプログラムコードを生成するとキーをｎａｍｅとするＭＡＰ型を生成する。
【００９２】
本実施形態においては、ポイントを設定しているがポイントではなく別の優先度の設定方法を用いても同様の作用・効果が得られる。
【００９３】
以上説明してきたように、インスタンス配置情報を更新する場合に、インスタンスアクセス情報に対してポイントを適用することによって、メモリ消費量と検索にかかるコストのトレードオフを図りながら、関連を表すプログラムコードの実装方法を決定することが可能となる。
【００９４】
このように、これらの実施形態によれば、ソフトウェアの設計図面からプログラムコードを自動生成する際、１対多及び多対多の関連のクラスについてはインスタンス配置情報に従ったプログラムコードを生成するプログラムコード生成装置を提供することができる。
【００９５】
また、これらのプログラムコード生成装置は、インスタンス配置情報を更新するために、あるインスタンスが保持しているインスタンスのアクセス状況をログ出力可能なプログラムコードを生成することができる。そして、そのログからコンテナの実装方法を決めるためのインスタンスアクセス情報２１７を抽出することが可能である。さらに、インスタンスアクセス情報をもとにインスタンスを保持するコンテナについて最適なプログラムコードをインスタンス配置情報として更新することができる。更に、これらのプログラムコード生成装置は、コンテナ実装について、インスタンスアクセス情報からインスタンス配置情報を更新することで、インスタンスの検索コストを考慮しメモリ消費量を抑えたプログラムコードを生成できる。
【００９６】
なお、本発明の実施形態は、例えばコンピュータがプログラムを実行することによって実現することができる。また、プログラムをコンピュータに供給するための手段、例えばかかるプログラムを記録したＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体又はかかるプログラムを伝送するインターネット等の伝送媒体も本発明の実施形態として適用することができる。また、上記のプログラムも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体及びプログラムプロダクトは、本発明の範疇に含まれる。
【図面の簡単な説明】
【００９７】
【図１】本発明の第１の実施形態に係るプログラムコード生成装置の構成ブロック図である。
【図２】本発明の第１の実施形態に係るプログラムコード生成装置のデータフロー図である。
【図３】本発明の第１の実施形態におけるシステム全体のフローチャート図である。
【図４】本発明の第１の実施形態におけるプログラムコード生成ルーチンに関するフローチャート図である。
【図５Ａ】ある設計図面の一部を示したイメージ図である。
【図５Ｂ】クラス間の連携を実装するコンテナに関する特徴を表す表を示す図である。
【図６】本発明の第１の実施形態におけるインスタンス配置情報の更新ルーチンに関するフローチャート図である。
【図７】本発明の第１の実施形態におけるログ出力プログラムコードによって出力されたログを示すイメージ図である。
【図８】本発明の第１の実施形態におけるログを解析した結果得られるインスタンスアクセス情報を示すイメージ図である。
【図９】本発明の第１の実施形態におけるプログラムコード生成装置によって生成されるプログラムコードのなかでコンテナをMAP型で実装した例を示したイメージ図である。
【図１０】本発明の第１の実施形態におけるプログラムコード生成装置によって生成されるプログラムコードのなかでコンテナをLIST型で実装した例を示したイメージ図である。
【図１１】本発明の第２の実施形態におけるインスタンス配置情報の更新ルーチンに関するフローチャート図である。
【図１２】本発明の第２の実施形態におけるログを解析した結果得られるインスタンスアクセス情報を示すイメージ図である。
【符号の説明】
【００９８】
１：ＣＰＵ
２：バス
３：ＲＯＭ
４：ＲＡＭ
４ａ：設計図面情報
４ｂ：プラットフォーム依存情報
４ｃ：プログラムコード
４ｄ：インスタンス配置情報
４ｅ：ライブラリ
４ｆ：プログラム実行形式
５：入力インターフェイス
６：キーボード、ボタン、マウス、ダイアル
７：出力インターフェイス
８ａ：ＣＲＴ、ＬＣＤ
８ｂ：プリンタ、プロッタ
９：外部記憶装置インターフェイス
１０：ＨＤ、ＦＤ、ＣＤ−ＲＯＭ、ＭＤ、ＣＦ、・・・（ファイル）
２０１：ＧＵＩ入力処理部
２０２：自動生成装置起動部
２０３：設計図面情報入力部
２０４：プラットフォーム依存情報入力部
２０５：インスタンス配置情報更新部
２０６：設計図面情報
２０７：プラットフォーム依存情報
２０８：インスタンス配置情報
２０９：プログラム生成部
２１０：プログラムコード
２１１：ライブラリ
２１２：コンパイラ・リンカ
２１３：プログラム実行形式
２１４：プログラム実行部
２１５：プログラム実行ログ
２１６：実行ログ解析部
２１７：インスタンスアクセス情報
３０１：クラス名がＡＡＡであるクラス
３０２：クラス名がＢＢＢであるクラス
３０３：クラスＡＡＡとクラスＢＢＢの関連
【特許請求の範囲】
【請求項１】
プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である設計図面を解析する設計図面解析手段と、
前記設計図面情報に基づいて１対多の関連に対してプログラムコード生成規則を定めるインスタンス配置情報と、
データアクセスが何回発生したかを示すインスタンスアクセス情報を更新するインスタンス配置情報更新手段と、
前記インスタンス配置情報に基づいてプログラムコードを生成するプログラムコード生成手段と、
を備えることを特徴とするプログラムコード生成装置。
【請求項２】
前記インスタンス配置情報更新手段は、前記インスタンスアクセス情報と前もって設定される閾値に基づいて更新することを特徴とする請求項１に記載のプログラムコード生成装置。
【請求項３】
前記インスタンスアクセス情報は、
前記設計図面に記載の第１のクラスと、
前記設計図面に記載の前記第１のクラスとは異なる第２のクラスと、
前記第１のクラスと前記第２のクラスとの関連と、
前記設計図面の第１のクラスの実体である第１のインスタンスと、
前記設計図面の第２のクラスの実体である第２のインスタンスと、
前記第１のインスンタンス及び前記第２のインスタンスへのアクセス形式と、
を有することを特徴とする請求項２に記載のプログラムコード生成装置。
【請求項４】
前記アクセス形式は、前記第２のインスタンスの特定インスタンスにのみアクセスするキー検索形式であることを特徴とする請求項３に記載のプログラムコード生成装置。
【請求項５】
前記アクセス形式は、前記第１のインスタンスと関連のある前記第２のインスタンスに全アクセスをするＥｎｕｍ形式であることを特徴とする請求項３に記載のプログラムコード生成装置。
【請求項６】
前記閾値は、インスタンスの総数を規定していることを特徴とする請求項３に記載のプログラムコード生成装置。
【請求項７】
前記閾値は、インスタンスへのアクセスする頻度を規定していることを特徴とする請求項３に記載のプログラムコード生成装置。
【請求項８】
プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である設計図面を解析する設計図面解析工程と、
前記設計図面情報に基づいて１対多の関連に対してプログラムコード生成規則を定めるインスタンス配置工程と、
データアクセスが何回発生したかを示すインスタンスアクセス情報を更新するインスタンス配置情報更新工程と、
前記インスタンス配置情報に基づいてプログラムコードを生成するプログラムコード生成工程と、
を備えることを特徴とするプログラムコード生成方法。
【請求項９】
コンピュータに、
プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である設計図面を解析する設計図面解析手順と、
前記設計図面情報に基づいて１対多の関連に対してプログラムコード生成規則を定めるインスタンス配置手順と、
データアクセスが何回発生したかを示すインスタンスアクセス情報を更新するインスタンス配置情報更新手順と、
前記インスタンス配置情報に基づいてプログラムコードを生成するプログラムコード生成手順と、
を実行させることを特徴とするプログラム。
【請求項１】
プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である設計図面を解析する設計図面解析手段と、
前記設計図面情報に基づいて１対多の関連に対してプログラムコード生成規則を定めるインスタンス配置情報と、
データアクセスが何回発生したかを示すインスタンスアクセス情報を更新するインスタンス配置情報更新手段と、
前記インスタンス配置情報に基づいてプログラムコードを生成するプログラムコード生成手段と、
を備えることを特徴とするプログラムコード生成装置。
【請求項２】
前記インスタンス配置情報更新手段は、前記インスタンスアクセス情報と前もって設定される閾値に基づいて更新することを特徴とする請求項１に記載のプログラムコード生成装置。
【請求項３】
前記インスタンスアクセス情報は、
前記設計図面に記載の第１のクラスと、
前記設計図面に記載の前記第１のクラスとは異なる第２のクラスと、
前記第１のクラスと前記第２のクラスとの関連と、
前記設計図面の第１のクラスの実体である第１のインスタンスと、
前記設計図面の第２のクラスの実体である第２のインスタンスと、
前記第１のインスンタンス及び前記第２のインスタンスへのアクセス形式と、
を有することを特徴とする請求項２に記載のプログラムコード生成装置。
【請求項４】
前記アクセス形式は、前記第２のインスタンスの特定インスタンスにのみアクセスするキー検索形式であることを特徴とする請求項３に記載のプログラムコード生成装置。
【請求項５】
前記アクセス形式は、前記第１のインスタンスと関連のある前記第２のインスタンスに全アクセスをするＥｎｕｍ形式であることを特徴とする請求項３に記載のプログラムコード生成装置。
【請求項６】
前記閾値は、インスタンスの総数を規定していることを特徴とする請求項３に記載のプログラムコード生成装置。
【請求項７】
前記閾値は、インスタンスへのアクセスする頻度を規定していることを特徴とする請求項３に記載のプログラムコード生成装置。
【請求項８】
プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である設計図面を解析する設計図面解析工程と、
前記設計図面情報に基づいて１対多の関連に対してプログラムコード生成規則を定めるインスタンス配置工程と、
データアクセスが何回発生したかを示すインスタンスアクセス情報を更新するインスタンス配置情報更新工程と、
前記インスタンス配置情報に基づいてプログラムコードを生成するプログラムコード生成工程と、
を備えることを特徴とするプログラムコード生成方法。
【請求項９】
コンピュータに、
プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である設計図面を解析する設計図面解析手順と、
前記設計図面情報に基づいて１対多の関連に対してプログラムコード生成規則を定めるインスタンス配置手順と、
データアクセスが何回発生したかを示すインスタンスアクセス情報を更新するインスタンス配置情報更新手順と、
前記インスタンス配置情報に基づいてプログラムコードを生成するプログラムコード生成手順と、
を実行させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２００７−７９８３８（Ｐ２００７−７９８３８Ａ）
【公開日】平成１９年３月２９日（２００７．３．２９）
【国際特許分類】
【出願番号】特願２００５−２６５７９５（Ｐ２００５−２６５７９５）
【出願日】平成１７年９月１３日（２００５．９．１３）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成１９年３月２９日（２００７．３．２９）
【国際特許分類】
【出願日】平成１７年９月１３日（２００５．９．１３）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]