JP2007213417A - プログラムコード生成装置、方法、及びコンピュータプログラム - Google Patents

Abstract

【課題】そのコンテンツデータに関連するコンテンツデータの表示方法を状況によって制御することを目的とする。
【解決手段】プログラムの構造を表現する設計図面情報をユーザが記述編集可能とする手段と、設計図面情報で記述されるプログラムをビルド及び実行する環境を指示するプラットフォーム情報をユーザが記述編集可能とする手段と、複数のプログラム間で送受信されるデータオブジェクトの型情報を設計図面情報から抽出する手段と、プラットフォーム情報から各プログラムの実行環境情報を取り出す手段と、設計図面情報及びプラットフォーム情報を元にプログラムコードを自動生成する手段と、自動生成されたプログラムコードをビルドするために必要となるプロジェクトファイルを自動生成する手段と、実行環境情報及び送信オブジェクトの型情報から最適なデータ変換関数のプログラムコードを自動生成する手段を有する。
【選択図】図１

Description

本発明は、ソフトウェアの設計図面よりプログラムコードの自動生成を行うプログラムコード生成装置、方法、及びコンピュータプログラムのうち、特に分散環境にてソフトウェアコンポーネント間で構造を持ったデータオブジェクトの送受信を行うモデルにおいて、パフォーマンスを向上することを特徴とするプログラムコード生成装置、方法、及びコンピュータプログラムに関する。

近年のソフトウェア設計技術として、モデル駆動型アーキテクチャ(Ｍｏｄｅｌ Ｄｒｉｖｅｎ Ａｒｃｈｉｔｅｃｔｕｒｅ)技術(以降、ＭＤＡ技術と称す)が広まり、採用されるようになってきている。

一般的にＭＤＡ技術とは、オペレータが入力したソフトウェアの設計図面情報(設計モデル)から各種プラットフォームのプログラムコードを自動的に生成し、且つ、入力したソフトウェアの設計図面情報をＭＤＡ専用ツール(以降、ＭＤＡツールと称す)上で動作及び検証することが可能な技術である。ＭＤＡ技術では、実行プラットフォームに非依存な設計モデルと、実行プラットフォーム依存部分を明確に分けている。これにより、実行プラットフォーム依存部分を切り替えることにより、同一の設計モデルから異なるプラットフォームで動作する実行形式を作成することが可能である。

ＭＤＡツールは設計モデルを記述するモデルエディタ、モデルの配置情報やプラットフォーム依存な実行環境情報等を入力する実行環境情報エディタ、設計モデルと実行環境情報からプログラムコードを自動生成するプログラム自動生成装置、実行形式を得るためのコンパイラ、リンカを統合したツールである。

また、コンポーネント開発の考えが広まっている。これは、急激に規模が増大する傾向にあるソフトウェアを、より効率的に開発し、また品質を向上させるために、ソフトウェアをコンポーネントとして部品化し、必要なコンポーネントを組み合わせることによってソフトウェアを開発するものである。ＭＤＡ技術を用いたソフトウェア設計においてもこの考え方を適用することは有効であり、設計モデルをコンポーネントとして部品化し再利用することが考えられている。

ＭＤＡ技術は、アプリケーションの振る舞いを表す設計モデルと、プラットフォームに依存する言語やミドルウェア等の実装技術を分離するものである。すなわち上記コンポーネント単位で開発された設計モデルをミドルウェアにマッピングし、プログラムコードを自動生成することが可能である。

一方、分散オブジェクト技術は、複数のプロセスやネットワーク上に分散されているソフトウェアコンポーネント(オブジェクト)を他のロケーションから利用可能とする技術である。分散オブジェクト技術では、同一コンピュータ上の異なるプロセス上で動作するコンポーネントや、ネットワークを介して異なるコンピュータ上で動作するコンポーネントに対して相互にメッセージ通信が行われる。

このような分散オブジェクトシステムの代表的なものとして、ＣＯＲＢＡ(Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ)や、Ｊａｖａ（登録商標）ＲＭＩ（Ｊａｖａ（登録商標） Ｒｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ）等がある。これらのシステムでは、分散されたコンポーネント(オブジェクト)間でのデータ通信を含むプログラムの記述を簡単にするために、ユーザプログラムとは別に、クライアントとサーバとの間のインタフェースプログラムを、ユーザプログラムのプログラム言語とは異なるＩＤＬ(Ｉｎｔｅｒｆａｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ:インタフェース記述言語)を用いて記述する。ＩＤＬを記述することにより、Ｃ／Ｃ＋＋言語やＪａｖａ（登録商標）言語等異なるプログラミング言語で実装したコンポーネント間でデータ通信が可能となり、コンポーネントの相互運用性を高めていると言える。

異なるコンピュータ上で動作するプログラムで扱うメモリ上のデータ内部表現形式(エンディアン及びアライメント)が異なる場合がある。図９はエンディアン及びアライメントの違いによるデータの内部表現の違いを表している。９０１は数値0x12345678をメモリ上に配置したイメージに関し、ＣＰＵアーキテクチャがビッグエンディアンの場合とリトルエンディアンの場合の違いを例示したものである。

９０２は構造体のアライメントの違いによる内部表現の違いを表しており、例示した構造体(Ｄａｔａ)を１バイト境界、２バイト境界、４バイト境界でメモリ上に配置した場合のパディングの様子を示している。また、構造体のアライメントはコードコンパイル時のコンパイルオプションもしくは、#pragma pack等によりプログラムコード上で指定することができる。プログラムコード上で構造体のアライメントを指定する場合の１例を図１０に示す。

このように、データの内部表現形式の違いが存在するため、プロセスを超えて、又はネットワークを介してデータオブジェクトを送信する際には、マーシャリングを行う必要がある。マーシャリングとは、送信元のコンピュータの内部表現形式からネットワーク上で共通の論理形式に変換する操作のことで、データはメンバ毎にエンディアン変換され、パディングを含まないストリームデータとなる。

マーシャリングされたデータはネットワーク上に送信され、送信先においてデマーシャリングする必要がある。デマーシャリングはマーシャリングの逆変換で、受信した論理形式のデータを受信したコンピュータの内部表現形式に変換する操作のことである。

このように、分散オブジェクトシステムにおいてはコンポーネント相互通信の汎用性を高めるために、送受信データを一旦、共通の表現形式に変換して送信するという手法がとられている。図１１は、ＣＯＲＢＡによるコンポーネント間のデータオブジェクトの送受信時におけるデータ変換の様子を説明した図である。

１１０１はリトルエンディアンのＣＰＵで構成されるコンピュータＡを示しており、１１０２及び１１０５は同コンピュータ内で動作するプロセスである。１１０３はプロセス(Ａ)１１０２内で動作するＣ言語で作成されたコンポーネントＡで、１１０６はプロセス(Ｂ)１１０５内で動作するＣ言語で作成されたコンポーネントＢである。１１０８はビッグエンディアンのＣＰＵで構成されるコンピュータＢを示しており、１１０９は同コンピュータＢ内で動作するプロセス(Ｃ)である。１１１０はプロセス(Ｃ)内で動作するＪａｖａ（登録商標）言語で作成コンポーネントＣである。

コンポーネントＡ１１０３からデータオブジェクトをコンポーネントＢ及びコンポーネントＣに送信する場合を考える。この場合、コンポーネントＡから送信されるデータオブジェクトはマーシャリング関数１１０４にてマーシャリングされ、論理形式に変換されたストリームデータ１１１２としてＯＲＢ等の伝送路を流れる。受信側のコンポーネントＢではデマーシャリング関数１１０７を通して、再び内部表現形式に変換され利用される。

同様にコンポーネントＣにおいてもデマーシャリング関数１１１１により内部表現形式に変換される。

なお、Ｊａｖａ（登録商標）言語の場合はＣＰＵアーキテクチャによらず、内部データ形式はビッグエンディアンで表現される。

特開２０００−９９３４５号公報 特開２００２−１３２５０２号公報

しかしながら、ＣＯＲＢＡ等の分散オブジェクトシステムは高機能であるが、それゆえ実行時のパフォーマンスやメモリ使用量等の観点から組み込みシステム等のメモリリソースやパフォーマンスの制限が厳しい領域では敬遠される傾向にある。

また、組み込みシステムでは内部のソフトウェアコンポーネントの構成は静的に決定されることが多く、必ずしも汎用性の高いコンポーネントが必要とされるわけではない。例えば、マルチプロセスＯＳ上で動作する組み込みシステムにおいて、プロセス間におけるコンポーネント通信を行う場合は、言語非依存性やコンポーネントの可搬性を犠牲にしてもパフォーマンスを重視する場合が多い。

マーシャリングを行うには、データオブジェクト(クラスや構造体)の各メンバの基本型を理解し、正しいサイズでエンディアン変換及びパッキング／アンパッキング処理を送信時及び受信時に行う必要がある為、実行時の負荷を伴う。

一部のＣＯＲＢＡ製品では、Ｃｏｌｌｏｃａｔｉｏｎ Ｏｐｔｉｍｉｚａｔｉｏｎという最適化の仕様が用意されており、同一プロセス内の通信においてはマーシャリングを省略することが可能なものもある。しかしながら、プロセスやコンピュータを越える通信の場合はマーシャリングを行う必要がある。

また、特許文献１では、Ｃ／Ｃ＋＋言語で分散プログラミングを行う場合にユーザプログラムから通信を行う際のマーシャリング関数を自動生成する仕組みが開示されている。しかしながら、本来マーシャリングが不必要な状況においてマーシャリングを省略する考慮はなされていない。

同じく、特許文献２では、ユーザ記述言語ソースプログラムから分散処理プログラムを自動生成する方法が開示されており、前記ＩＤＬ記述をユーザが行うことなくマーシャリング／デマーシャリングを含むコードを自動生成することを可能としている。しかしながら、コンポーネントの配置やエンディアンやアライメント等の実行環境を考慮して、実行効率の良いマーシャリング関数の生成に関する言及はなされていない。

上記問題点を解決すべく、本発明では、ソフトウェア図面よりプログラムの自動生成を行うＭＤＡ技術を用いて、ソフトウェアコンポーネント間のデータ通信を行うモデルを作成する場合、送受信を行うコンポーネント間の実行環境属性を元に、分散環境でのデータオブジェクト送信におけるデータ変換方式を選択し、状況に応じて無駄なマーシャリング操作を省くことにより、実行効率の良いデータ転送を実現することを目的とする。

図１２はデータオブジェクトを送受信するコンポーネントの実行環境(エンディアン及びアライメント)の違いとマーシャリング操作の要否を示した図である。送信側コンポーネント及び受信側コンポーネントの双方のエンディアン及びアライメントが一致した場合は、マーシャリング操作を省略できる。

特に送受信するデータオブジェクトが参照を含まない単純な構造の場合、データオブジェクトの送受信は単純なメモリコピー(シャローコピーという)で実現できる。つまり、送信側はデータオブジェクトを内部表現形式のまま伝送路にデータストリームとして流し、受信側は受け取ったデータストリームをデータオブジェクトの型に当てはめてキャストするだけでよい。

図１３は送信するデータオブジェクトが参照を含まない単純な構造で、送受信を行うコンポーネントのエンディアン及びアライメントが一致した場合のデータオブジェクトの流れを例示した図である。１３０１はリトルエンディアンのＣＰＵを持つコンピュータＡで１３０２及び１３０４はコンピュータＡ１３０１上に存在するプロセスである。１３０２で示したプロセス１上には送信側のコンポーネントＡ１３０３が動作し、１３０４で示したプロセス２上には受信側のコンポーネントＢ１３０５が動作している。また、１３１０はリトルエンディアンのＣＰＵを持つコンピュータＢで、１３１１で示すプロセス３が存在している。１３１２は１３１１で示したプロセス３上で動作するコンポーネントＣである。

このようなコンポーネントの配置関係において、コンポーネントＡからデータオブジェクト１３０６をコンポーネントＢに送信する場合、伝送路１３０９に流すデータストリーム１３０７はデータオブジェクト１３０６と同一の配列で構成されている。また、コンポーネントＢがデータストリーム１３０７を受信して内部表現形式に直した結果のデータオブジェクト１３０８もデータオブジェクト１３０６と同一の配列で構成されている。同様に、コンポーネントＡからコンポーネントＣに対するデータオブジェクト１３０６の送信においても、伝送路を流れるデータストリーム１３１３及びコンポーネントＣで受信したデータオブジェクト１３１４も同一の配列で構成される。つまり、例示した実行環境においてはいかなる個所においてもマーシャリング操作が行われていない。

このように、データオブジェクトを送受信するコンポーネント間通信において、コンポーネント相互間の配置を静的に決定することにより、不要なマーシャリング処理を省略することが可能となる。

本発明によるプログラムコード生成装置は、プログラムの構造を表現する設計図面情報をユーザが記述編集可能とする設計図面入力手段と、前記設計図面情報で記述されるプログラムをビルド及び実行する環境を指示するプラットフォーム情報をユーザが記述編集可能とするプラットフォーム情報入力手段と、複数のプログラム間で送受信されるデータオブジェクトの型情報を前記設計図面情報から抽出する送信オブジェクト型情報抽出手段と、プラットフォーム情報から各プログラムの実行環境情報を取り出す実行環境抽出手段と、前記設計図面情報及びプラットフォーム情報を元にプログラムコードを自動生成するプログラムコード生成手段と、前記自動生成されたプログラムコードをビルドするために必要となるプロジェクトファイルを自動生成するプロジェクトファイル生成手段と、前記実行環境情報及び送信オブジェクトの型情報から最適なデータ変換関数のプログラムコードを自動生成するマーシャリング関数コード生成手段を有することを特徴とする。

本発明によれば、ソフトウェア図面よりプログラムの自動生成を行うプログラム生成装置によりソフトウェアコンポーネント間のデータ通信を行うプログラムを作成する場合、送受信を行うコンポーネントのそれぞれの実行環境属性(エンディアン、アライメント)を元に、データオブジェクト送信におけるデータ変換(マーシャリング)方式を選択する。すなわち、送受信を行うコンポーネントのエンディアン及びアライメントを示した実行環境属性からマーシャリングが必要か否かを判断して、マーシャリングが不必要な場合はマーシャリングコードを生成せず、単純なメモリコピーでマーシャリングを代用するコードを生成する。これにより、データオブジェクトを送受信するコンポーネント間通信において、コンポーネント相互間の配置及び実行環境属性を静的に決定することで、不要なマーシャリング処理を省略し実行効率の良いデータ転送を実現するプログラムを生成することが可能となる。

以下、添付図面を参照して、本発明の好適な実施形態について説明する。
図１は本発明の実施例を示す全体構成図である。図１において、１はＣＰＵであり、以下に説明する３〜１０の装置を２で示すバスを介してアクセスし制御を行う。３はバス２を介してＣＰＵ１からアクセス可能な読み出し専用メモリ（ＲＯＭ）であり、本実施例ではその動作を詳細に説明する処理プログラム３ａ及び処理プログラムにより使用されるパラメータ３ｂが格納されている。

４は読み書き可能なメモリ（ＲＡＭ）であり、ＲＡＭ４上には、上記処理プログラム３により作成／変更がなされる、設計図面情報、プラットフォーム情報、送信オブジェクト型情報、エンディアン／アライメント情報、プログラムコード、ライブラリ、マーシャリングコード、プロジェクトファイル、実行可能形式をそれぞれ格納するための領域（順に４ａ、４ｂ、４ｃ、４ｄ、４ｅ、４ｆ、４ｇ、４ｈ、４ｉ）が確保されている。

５は入力インタフェースであり、６で示したキーボード、マウス、タブレット等の入力装置を介してなされる入力を受け取る。７は出力インタフェースであり、８で示したＣＲＴ、ＬＣＤ等の表示媒体、更にはプリンタ、プロッタ等の出力装置に対し、データの表示／出力を行う。９は外部記憶装置インタフェースであり、１０で示したＨＤ、ＦＤ、ＣＤ−ＲＯＭ、ＭＤ、ＣＦ等の外部記憶装置に対するデータの入出力を行うものである。

本実施例では、動作の詳細な説明と行う処理プログラム３ａやパラメータ３ｂがＲＯＭ３上にあるものとして説明を行う。また、処理対象となる各データの格納領域（４ａ〜４ｉ）がＲＡＭ上にあるものとして説明を行う。ただし、これらはすべて、外部記憶装置上に配置することも可能であり、更に、必要に応じて、外部記憶装置からＲＡＭ上にロードし、使用することもできる。また、ＣＰＵのキャッシュメモリ上に配置することも同様に可能である。

図２は、図１において３ａで示した処理プログラムの構成要件とそれら構成要件が図１の４ａ〜４ｇで示した格納領域に格納されるデータとどのような関係にあるかを示すものである。２００は図1における入力インタフェース５を介して入力されるデータを扱うＧＵＩ入力処理部であり、ユーザはこのＧＵＩ入力処理部によりデータの入力や編集と、各処理部へ指示できるようになっている。本発明におけるプログラムコード生成装置においては、自動生成装置起動部２００として利用する。

２０１は外部記憶装置内から実行可能な設計図面を読み込み、構文解析を行う設計図面入力部であり、処理プログラムが実行可能な設計図面を解釈し、設計図面情報を生成することを可能にする。

２０２は外部記憶装置内から実行ファイルの動作するＯＳやＣＰＵアーキテクチャやプログラミング言語やコンパイラオプションやフレームワークといったプラットフォームデータを読み込み、構文解析を行うプラットフォーム情報入力部である。プラットフォーム上方入力部２０２は、処理プログラムがプラットフォーム情報を生成することを可能にする。

２０３は設計図面入力部２０１より生成された、処理プログラムが解釈することが可能な設計図面情報である。２０４はプラットフォーム情報入力部２０２より生成された、処理プログラムが解釈することが可能なプラットフォーム情報である。プラットフォーム情報は対象とする実行形式が複数存在する場合は、それぞれの実行形式を動作させるプロセスやコンピュータを指定する配置情報を含む。従って、システムが複数のプラットフォームに跨る場合は、それぞれのプラットフォーム情報が含まれる。

２０５は設計図面情報２０３を解析することで、コンポーネント間で送受信されるオブジェクトを抽出する送信オブジェクト抽出部であり、設計図面から送信オブジェクトの型(クラスや構造体)情報を取り出すことを可能とする。２０６は送信オブジェクト抽出部２０５が生成した送信オブジェクト型情報である。

２０７はプラットフォーム情報２０４から、実行ファイルの動作するＣＰＵアーキテクチャやコンパイラオプションというプログラムの実行環境を決定する情報を取り出す実行環境抽出部であり、エンディアン及び構造体のアライメント情報を抽出する。２０８は実行環境抽出部２０７により抽出された、エンディアン／アライメントの情報であり、実行ファイルが複数存在する場合は、それぞれの実行ファイル毎にエンディアン及びアライメントの情報を含んでいる。

２１１は設計図面情報２０３、送信オブジェクト型情報２０６及びエンディアン／アライメント情報２０８から、適切なマーシャリング関数のプログラムコードを生成するマーシャリング関数コード生成部である。例えば、対象送信オブジェクトがマーシャリング操作を省略可能である場合は、単純なメモリコピー操作でオブジェクトのコピーを作成する関数を生成する。エンディアンもしくはアライメントが異なる場合等マーシャリング操作が省略不可能な場合は、送信オブジェクト型情報からデータオブジェクトのメンバ１つ１つをエンディアン変換してパディングを除いてシリアライズ化されたデータストリームに変換するマーシャリング関数を生成する。

２１２は設計図面情報２０３やプラットフォーム依存情報２０４から、プログラムコードを自動生成するプログラムコード生成部である。プログラムコード生成部２１２は、設計図面の依存情報や実行対象となるプラットフォームに応じて最適化されたプログラムコードの自動生成が可能である。２１３は、設計図面情報２０３やプラットフォーム依存情報２０４から、生成されたプログラムコードやマーシャリングコード及びライブラリ等の依存関係及びコードコンパイラやリンカに渡すオプション等の情報を管理するプロジェクトファイルを自動生成するプロジェクトファイル生成部である。ここでは、プロジェクトファイル生成部２１３がプログラムコード生成部２１２に内包される機能として記述した。

２１５はプロジェクトファイル生成部２１３から生成されたプロジェクトファイルである。２１６はプログラムコード生成部２１２から生成されたプログラムコードである。２１７はマーシャリング関数コード生成部２１１から生成されたマーシャリング関数のプログラムコードである。２１８はプログラムコード２１６やマーシャリングコード２１７から参照されるライブラリである。

２１９はプログラムコード２１６と、プロジェクトファイル２１５と、マーシャリングコード２１７及びライブラリ２１８から、実行可能形式２２０を生成するコードコンパイラである。２２０はコードコンパイラにより生成された実行形式ファイルである。

次に、実行可能な設計図面について説明する。実行可能な設計図面の全体構成を規定する図面は、一般にドメイン図と呼ばれている。実際の例を図３に示す。図３は、オペレータからの入力を受け、ライトを付けたり、時間を指定してライトを消すシステムを表したドメイン図の一例である。

３０１はライトを明滅するシステムの制御を行うControllerドメイン、３０２はオペレータからの操作を受け取るUIドメイン、３０３はライトを制御するLightドメイン、３０４はタイムサービスを提供するTimerドメインを示している。さらに、ドメイン同士の結びつきは、関連と呼ばれ、図３においては矢印付きの点線で表現される。図３では、ドメイン間の通信であるイベントの送受信を行う場合に点線で結ぶ例を示している。３０５は、関連の一例で、Controllerドメイン３０１とTimerドメイン３０４の間で、双方向のイベント通信を行うため、両方向に矢印のついた点線で示している。３０６の関連の一例で、Controllerドメイン３０１とLightドメイン３０３の間で、片方向のイベント通信を行うため、Lightドメイン３０３側だけに矢印のついた点線で示す。

実行可能な設計図面において、処理を行うオブジェクトの静的な構造を示す設計図は、クラス図と呼ばれている。実際の例を図４に示す。図４は、図３で示したオペレータからの入力を受け、ライトを付けたり、時間を指定してライトを消すシステムを表したドメイン図の一例における、ライトを明滅するシステムの制御を行うControllerドメイン３０１のクラス図の一例である。

図４において、４０１はクラスの名称を示し、図４の例では「Controller」がクラスの名称である。４０２はControllerクラスが「name」というString型のインスタンス変数を持つことを表現している。４０３はControllerクラスが「getName」というメソッドをもち、「evOn」、「evOff」、「alarm」という３つのイベントを受け取ることを示している。メソッドは処理の内容が書かれており、イベントはクラス間での通信オブジェクトの一例である。

実行可能な設計図面において、クラスの動的な振る舞いは状態の遷移を表現する図や表等で表現する。実際の例を図５に示す。図５は状態遷移図を使ったクラスの動的な振る舞いを表現した例で、図４におけるControllerクラスの状態遷移図の例である。図５において、５０１は初期状態を示し、Controllerクラスのインスタンスが生成されたときに入る状態を表す。初期状態５０１はその状態に留まることはなく、すぐに次の状態５０２に遷移する。５０２は「Off」と名づけた状態を表し、Controllerクラスのインスタンスが生成された後、この状態に留まる。５０３は状態から状態への遷移を示し、Off状態５０２のときにevOnイベントが発行されると特定のアクションevOn()を実行して、状態５０４に遷移する。５０５は、On状態５０４のときにalarmイベントが発行されると特定のアクションalarmを実行して、再度、On状態５０４に遷移する。なお、一般に、状態遷移図にはアクションを記述することも可能であるが、図５に示した状態遷移図の例では別のファイルに定義して利用する例を示している。

プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である、設計図面において、各クラスの状態における処理手順の記述を一般にはアクションと呼ぶ。本発明においてはアクションの記述を別ファイルにて提供する場合を例に説明するが、状態遷移図等に記入する場合も問わない。

プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である、設計図面におけるアクション記述の例を図６に示す。図６において、６０１は図３で例として示した、オペレータからの入力を受け、ライトを付けたり、時間を指定してライトを消すシステムの初期化時に実行されるアクションを示した例である。システムで必要となるControllerクラス、UIクラス、Lightクラスのインスタンスを、それぞれ、newにより作成する。ここで作成したインスタンスは、システム全体で操作可能な変数として登録するため、registLinkにより登録する。

６０２は図５で示したControllerクラスの状態遷移図において、Off状態５０２からOn状態５０４に遷移するアクションevOnを記述した例である。evOnアクション６０２では、このアクション内で、クラスTimerのインスタンスを新たに生成し、このアクションを実行するControllerクラスのインスタンス内で操作可能な変数として登録するため、resigtLinkにより登録する。さらに、evOnアクション６０２では、既にシステム全体で操作可能として登録したLightクラスの唯一のインスタンスをqueryLinkにより入手して、ライトを点灯するためのイベントlightOnをsendEventにより送信する。

６０３は図５で示したControllerクラスの状態遷移図において、On状態５０４からOff状態５０２に遷移するアクションevOffを記述した例である。evOffアクション６０３では、既にシステム全体で操作可能として登録したLightクラスの唯一のインスタンスをqueryLinkにより入手して、ライトを消灯するためのイベントlightOffをsendEventにより送信する。さらに、evOffアクション６０３では、evOnアクション６０２でControllerクラスのインスタンス内で操作可能な変数として登録したTimerクラスのインスタンスをqueryLinkにより入手してtimerインスタンスを削除する。加えて、evOffアクション６０３では、既にシステム全体で操作可能として登録したUIクラスの唯一のインスタンスuiをqueryLinkにより入手して、ライトを消灯したことを知らせるイベントstopをsendEventにより送信する。

図６に示したアクションの例では、インスタンスの識別に生成時の変数名を利用しているが、インスタンスを識別するための情報、例えばシステム内で特定できる識別番号等を用いる別の方法でも実現可能である。図６に示したアクションの例では、生成したクラスのインスタンスが、システム全体で利用可能なインスタンスであるのか、特定のインスタンス内で利用可能なインスタンスであるのか、アクション記述のブロック内だけで利用可能なインスタンスであるのかを、ユーザがアクションで記述している。ただし、図４で示したドメイン図や図５で示したクラス図からこれらの変数の利用範囲を特定する情報を得ることができるため、この方法によらない。

これ以降の説明においてのフローチャートによる処理手順は、例に限定されることはなく、本発明の結果を満たす限りいかなる手順の組み合わせも、複数処理をまとめることも、処理を細分化することも可能である。また、各処理を個々に切り出してひとつの機能要素として単体として機能し、示している処理以外の処理と組み合わせて使用することも可能である。

（実施例１）
以下、図面を参照して、本発明の請求項１及び請求項２の実施例を説明する。図７は、本実施例のシステム全体の処理手順を示したフローチャートである。起動したオブジェクト配置を考慮したプログラムコード生成装置は、ステップ７０１において外部記憶装置内等に記憶してある実行可能な設計図面を読み込み、設計図面入力部２０１により設計図面情報２０３を生成する。

また、ステップ７０２においてプラットフォーム情報入力部２０２によりプラットフォーム情報２０４を生成する。プラットフォーム情報とは、例えば、プログラムを実行するプラットフォームのＣＰＵアーキテクチャ(エンディアン情報を含む)やアライメント等の実行環境に関わる情報及び、タスクやスレッドをどこのドメインやクラス等にマッピングさせるか、等の生成したコードを実行するプラットフォームに依存した情報である。

ステップ７０３において、設計図面情報２０３から図面情報を解析してドメインやクラス間で送信される送信オブジェクトを抽出し送信オブジェクト型情報２０６を生成する。

ステップ７０４において、プラットフォーム情報２０４から実行環境抽出部２０７によって実行可能プログラムのアライメント／エンディアン情報２０８を抽出する。ここで抽出されるアライメント情報は対象プログラムをコンパイルするコンパイラの設定によって予め選択されているものとする。アライメントは２、４、８、１６等の２のべき乗の数値であり、コンパイラによって選択可能な範囲やデフォルトの値が異なる場合がある。

ステップ７０５において、設計図面情報２０３及びアライメント／エンディアン情報２０８から、各ドメインもしくはクラス間のデータ送受信においてマーシャリング操作の必要性の有無の判定を行い、マーシャリング判定結果を得る。

ステップ７０６において、マーシャリングが必要と判断された場合は、ステップ７０８へ進む。マーシャリングが不用と判断された場合はステップ７０７へ進む。

ステップ７０７において、送信オブジェクト型情報２０６からオブジェクトのサイズを取得しオブジェクトの単純なコピーを生成するコードを生成する。なお、Ｃ言語の構造体でデータオブジェクトを表現する場合は、そのサイズはsizeof()にて取得することができるので、データオブジェクトの先頭番地からサイズ分のメモリコピーを行うコードを生成すればよい。同様に、Ｃ＋＋言語のクラスにおいてもsizeof()を利用してデータオブジェクトのサイズを取得することができるが、Ｃ＋＋言語のクラスでデータオブジェクトを表現する場合は、オブジェクトの先頭番地に仮想関数テーブルへのポインタを含む場合があるので、最初のデータメンバのオフセット位置からsizeof()で取得したサイズのメモリコピーを行うコードを生成する必要がある。

ステップ７０８において、マーシャリング関数コード生成部２１１では、送信オブジェクトの型情報２０６から送信オブジェクトの型に従って各メンバに対する変換処理を行うマーシャリング関数のコードを生成する。

ステップ７０９において、プロジェクトファイル生成部２１３は、設計図面情報２０３及びプラットフォーム情報２０４からプロジェクトファイル２１５を生成する。

ステップ７１０において、プログラムコード生成部２１２は設計図面情報２０３とプラットフォーム情報２０４とを用いてプログラムコード２１６を生成する。

ステップ７１１においてプログラムコード２１６とライブラリ２１８及びマーシャリングコード２１７から、コードコンパイラ２１9によりコンパイル、リンクを実施し、プログラム実行形式２２０を生成する。

以上の説明から、設計図面及びプラットフォーム情報を解析し、送受信を行うプログラム間の実行環境の相違を判定することで、送信するデータオブジェクトのマーシャリングを行うか否かを静的に判断することができる。例えば、データオブジェクトが参照を含まない単純な構造で、送受信を行うプログラムのアライメント及びエンディアンが一致する場合はマーシャリング操作を単純なメモリコピー操作に置き換えることができる。

（実施例２）
以下、図面を参照して、本発明の請求項３の実施例を説明する。図１６は、図１において３ａで示した処理プログラムの構成要件とそれら構成要件が図１の４ａ〜４ｇで示した格納領域に格納されるデータとどのような関係にあるかを示すものである。基本的な流れは図２で示したものと同様であるので、ここではその差分だけを説明する。

１６０９は、エンディアン／アライメント情報１６０８から使用するコンパイラで選択可能なアライメントの選択枝をユーザによって選択させるアライメント選択部である。アライメント選択部１６０９は、設計図面情報１６０３に記述されている実行可能なプログラム毎にアライメントを選択することが可能である。従って、当該プログラムに複数の送信オブジェクトが含まれる場合でも、全ての送信オブジェクトのアライメントは選択したアライメントに統一される。ユーザが選択したアライメントは選択されたアライメント１６１０として保存される。

１６１１は、設計図面情報１６０１、送信オブジェクト型情報１６０６、エンディアン情報１６０８及び選択されたアライメント１６１０から、適切なマーシャリング関数のプログラムコードを生成するマーシャリング関数コード生成部である。例えば、対象送信オブジェクトがマーシャリング操作を省略可能である場合は、単純なメモリコピー操作でオブジェクトのコピーを作成する関数を生成する。エンディアンもしくはアライメントが異なる場合等マーシャリング操作が省略不可能な場合は、送信オブジェクト型情報からデータオブジェクトのメンバ１つ１つをエンディアン変換してパディングを除いてシリアライズ化されたデータストリームに変換するマーシャリング関数を生成する。

１６１３は、設計図面情報１６０３、プラットフォーム依存情報１６０４及び選択されたアライメント１６１０から、生成されたプログラムコードやマーシャリングコード及びライブラリ等の依存関係及びコードコンパイラやリンカに渡すオプション等の情報を管理するプロジェクトファイルを自動生成するプロジェクトファイル生成部である。ここでは、プロジェクトファイル生成部１６１３がプログラムコード生成部１６１２に内包される機能として記述した。

なお、コードコンパイラに渡すオプションの中に、本実施例によって選択されたアライメントを指定するコンパイルスイッチが指定されることになる。

図８は、本実施例のシステム全体の処理手順を示したフローチャートである。起動したオブジェクト配置を考慮したプログラムコード生成装置は、ステップ８０１において、外部記憶装置内等に記憶してある実行可能な設計図面を読み込み、設計図面入力部１６０１により設計図面情報１６０３を生成する。

また、ステップ８０２において、プラットフォーム情報入力部１６０２によりプラットフォーム情報１６０４を生成する。プラットフォーム情報とは、例えば、プログラムを実行するプラットフォームのＣＰＵアーキテクチャ(エンディアン情報を含む)や利用するコードコンパイラにおける選択可能なアライメントの選択枝等の実行環境に関わる情報及び、タスクやスレッドをどこのドメインやクラス等にマッピングさせるか、等の生成したコードを実行するプラットフォームに依存した情報である。

ステップ８０３において、設計図面情報１６０３から図面情報を解析してドメインやクラス間で送信される送信オブジェクトを抽出し送信オブジェクト型情報１６０６を生成する。

ステップ８０４において、プラットフォーム情報１６０４から実行環境抽出部１６０７によって実行可能プログラムのアライメント／エンディアン情報１６０８を抽出する。ここで抽出されるアライメント情報は対象プログラムをコンパイルするコンパイラよって選択可能な候補が列挙されているものとする。アライメントは２、４、８、１６等の２のべき乗の数値であり、コンパイラによって選択可能な範囲やデフォルトの値が異なる場合がある。

ステップ８０５において、設計図面情報１６０３及びアライメント／エンディアン情報１６０８から、選択可能なアライメントの候補を列挙し、アライメント選択部１６０９によって候補の中から１つをユーザが選択する。

ステップ８０６において、設計図面情報１６０３、エンディアン情報１６０８及び選択されたアライメント１６１０から、各プログラム間のデータ送受信においてマーシャリング操作の必要性の有無の判定を行い、マーシャリング判定結果を得る。

ステップ８０７において、マーシャリングが必要と判断された場合は、ステップ８０９へ進む。マーシャリングが不用と判断された場合はステップ８０８へ進む。

ステップ８０８において、送信オブジェクト型情報１６０６からオブジェクトのサイズを取得しオブジェクトの単純なコピーを生成するコードを生成する。

ステップ８０９において、マーシャリング関数コード生成部１６１１では、送信オブジェクトの型情報１６０６から送信オブジェクトの型に従って各メンバに対する変換処理を行うマーシャリング関数のコードを生成する。

ステップ８１０において、プロジェクトファイル生成部１６１３は、設計図面情報１６０３、プラットフォーム情報１６０４及び選択されたアライメント１６１０からプロジェクトファイル１６１５を生成する。

ステップ８１１において、プログラムコード生成部１６１２は設計図面情報１６０３とプラットフォーム情報１６０４及び選択されたアライメント１６１０とを用いてプログラムコード１６１６を生成する。

ステップ８１２において、プログラムコード１６１６とライブラリ１６１８及びマーシャリングコード１６１７から、コードコンパイラ１６１9によりコンパイル、リンクを実施し、プログラム実行形式１６２０を生成する。

（実施例３）
以下、図面を参照して、本発明の請求項４の実施例を説明する。図１６は、図１において３ａで示した処理プログラムの構成要件とそれら構成要件が図１の４ａ〜４ｇで示した格納領域に格納されるデータとどのような関係にあるかを示すものである。基本的な流れは実施例２で示したものと同様であるので、ここではその差分だけを説明する。

１６０９は、エンディアン／アライメント情報１６０８から使用するコンパイラで選択可能なアライメントの選択枝をユーザによって選択させるアライメント選択部である。アライメント選択部１６０９は、設計図面情報１６０３に記述されている送信オブジェクト毎にアライメントを選択することが可能である。従って、当該プログラムに複数の送信オブジェクトが含まれる場合は、それぞれの送信オブジェクトに対して異なるアライメントを指定することが可能で、ユーザが選択したアライメントは選択されたアライメント１６１０として保存される。

１６１２は設計図面情報１６０３、プラットフォーム依存情報１６０４及び選択されたアライメント１６１０から、プログラムコードを自動生成するプログラムコード生成部である。プログラムコード生成部１６１２は、設計図面の依存情報や実行対象となるプラットフォームに応じて最適化されたプログラムコードの自動生成が可能である。また、送信オブジェクト毎にユーザが設定したアライメントに従ったデータオブジェクトを作成する為のコンパイラへの指示を、プログラムコードのデータオブジェクトの型宣言を行う部分に埋め込む。

例えば、図１０で示した例は、あるコンパイラにおけるアライメントの指定方法を示しており、#pragma packを用いることにより、特定の構造体やクラスに対して個別にアライメントの指定を行うことができる。これにより、同一実行プログラム内に複数のタイプの送信オブジェクトが存在し、それぞれアライメントの異なる相手に送信する場合においても、それぞれのアライメントで送信オブジェクトを生成することができる為、本発明を適用することが可能となる。

（実施例４）
以下、図面を参照して、本発明の請求項５の実施例を説明する。図１４は、送受信するデータオブジェクトのマーシャリングが必要な場合において、本発明で生成されるマーシャリング関数を送信側プログラムのみに配置した一例を示した図である。

１４０１はリトルエンディアンのＣＰＵを持つコンピュータＡである。１４０２はコンピュータＡ１４０１上に存在するプロセスである。１４０２で示したプロセス１上にはＣ言語で記述され構造体のアライメントが４である送信側のコンポーネントＡ１４０３が動作している。

また、１４１０はリトルエンディアンのＣＰＵを持つコンピュータＢで、１４１１で示すプロセス３が存在している。

１４１２は１４１１で示したプロセス３上で動作するＣ言語で記述され構造体のアライメントが２であるコンポーネントＣである。このようなコンポーネントの配置関係において、コンポーネントＡからコンポーネントＣに対するデータ送信において、１４０４で示したマーシャリング関数によってデータオブジェクト１４０６をマーシャリングする。この例では、送信側コンポーネントＡ１４０３と受信側コンポーネントＣ１４１２では、エンディアンは一致しているがアライメントが異なっている。

本発明の請求項５のマーシャリング関数は、送信側コンポーネントＡ１４０３で呼び出され、４バイトでアライメントされたデータオブジェクト１４０６を、受信側コンポーネントＣ１４１２の内部表現形式である２バイトでアライメントされた形式に変換し、データストリーム１４１３として伝送路１４０９に流す。コンポーネントＣで受信したデータストリーム１４１３は、既にコンポーネントＣにおける内部表現形式に変換されているため、受信側でデマーシャリングを行う必要がない。

（実施例５）
以下、図面を参照して、本発明の請求項６の実施例を説明する。図１５は、送受信するデータオブジェクトのマーシャリングが必要な場合において、本発明で生成されるマーシャリング関数を受信側プログラムのみに配置した一例を示した図である。

１５０１はリトルエンディアンのＣＰＵを持つコンピュータＡで１５０２はコンピュータＡ１５０１上に存在するプロセスである。１５０２で示したプロセス１上にはＣ言語で記述され構造体のアライメントが４である送信側のコンポーネントＡ１５０３が動作している。

また、１５１０はリトルエンディアンのＣＰＵを持つコンピュータＢで、１５１１で示すプロセス３が存在している。１５１２は１５１１で示したプロセス３上で動作するＣ言語で記述され構造体のアライメントが２であるコンポーネントＣである。このようなコンポーネントの配置関係において、コンポーネントＡからコンポーネントＣに対するデータ送信において、１５１５で示したマーシャリング関数によってデータストリーム１５１３をマーシャリングする。

この例では、送信側コンポーネントＡ１５０３と受信側コンポーネントＣ１５１２では、エンディアンは一致しているがアライメントが異なっている。送信側コンポーネントＡ１５０３は送信データオブジェクト１５０６を内部表現形式のまま無加工でデータストリーム１５１３として伝送路１５０９に流す。

本発明の請求項６のマーシャリング関数は、受信側コンポーネントＣ１５１２で利用され、伝送路１５０９を流れてきた４バイトでアライメントされたデータストリーム１５１３を、送信側のアライメントで解釈し、受信側コンポーネントＣ１５１２の内部表現形式である２バイトでアライメントされた形式のデータオブジェクト１５１４に変換する。本方式では変換操作を受信側に集中させることにより、送信側でのマーシャリングを省略可能にしている。

なお、本発明の目的は、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。

この場合、記憶媒体から読み出されたプログラムコード自体が上述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、上述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（基本システム或いはオペレーティングシステム）等が実際の処理の一部又は全部を行い、その処理によって上述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって上述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本発明の一実施形態に係るプログラムコード生成装置の構成ブロック図である。 本発明の請求項１及び２の一実施形態に係るプログラムコード生成装置のデータフロー図である。 本発明の一実施形態における設計図面情報のうちドメイン図について説明した図である。 本発明の一実施形態における設計図面情報のうち、クラス図について説明した図である。 本発明の一実施形態における設計図面情報のうち、状態遷移図について説明した図である。 本発明の一実施形態における設計図面情報のうち、アクション記述について説明した図である。 本発明の請求項１及び２の一実施形態における、システム全体に関するフローチャートである。 本発明の請求項３及び４の一実施形態における、システム全体に関するフローチャートである。 エンディアン及びアライメントの違いによるデータの内部表現の違いを表した一例を説明するための図である。 プログラムコード上で構造体のアライメントを指定する場合の一例を説明するための図である。 ＣＯＲＢＡによるコンポーネント間のデータオブジェクトの送受信時におけるデータ変換の様子を説明した例を説明するための図である。 データオブジェクトを送受信するコンポーネントの実行環境(エンディアン及びアライメント)の違いとマーシャリング操作の要否を示した図である。 送信するデータオブジェクトが参照を含まない単純な構造で、送受信を行うコンポーネントのエンディアン及びアライメントが一致した場合のデータオブジェクトの流れを示した例を説明するための図である。 送受信するデータオブジェクトのマーシャリングが必要な場合において、本発明で生成されるマーシャリング関数を送信側プログラムのみに配置した一例を説明するための図である。 送受信するデータオブジェクトのマーシャリングが必要な場合において、本発明で生成されるマーシャリング関数を受信側プログラムのみに配置した一例を説明するための図である。 本発明の請求項３及び４の一実施形態に係るプログラムコード生成装置のデータフロー図である。

符号の説明

１：ＣＰＵ
２：バス
３：ＲＯＭ
４：ＲＡＭ
４ａ：設計図面情報
４ｂ：プラットフォーム情報
４ｃ：送信オブジェクト型情報
４ｄ：エンディアン／アライメント情報
４ｅ：プログラムコード
４ｆ：ライブラリ
４ｇ：マーシャリングコード
４ｈ：プロジェクトファイル
４ｉ：実行可能形式
５：入力インタフェース
６：キーボード、ボタン、マウス、ダイアル
７：出力インタフェース
８ａ：ＣＲＴ、ＬＣＤ
８ｂ：プリンタ、プロッタ
９：外部記憶装置インタフェース
１０：ＨＤ、ＦＤ、ＣＤ−ＲＯＭ、ＭＤ、ＣＦ、・・・（ファイル）
２００：自動生成装置起動部
２０１：設計図面入力部
２０２：プラットフォーム情報入力部
２０３：設計図面情報
２０４：プラットフォーム情報
２０５：送信オブジェクト抽出部
２０６：送信オブジェクト型情報
２０７：実行環境抽出部
２０８：エンディアン／アライメント情報
２１１：マーシャリング関数コード生成部
２１２：プログラムコード生成部
２１３：プロジェクトファイル生成部
２１５：プロジェクトファイル
２１６：プログラムコード
２１７：マーシャリングコード
２１８：ライブラリ
２１９：コードコンパイラ
２２０：プログラム実行形式

Claims (8)

1. プログラムの構造を表現する設計図面情報をユーザが記述編集可能とする設計図面入力手段と、
   前記設計図面情報で記述されるプログラムをビルド及び実行する環境を指示するプラットフォーム情報をユーザが記述編集可能とするプラットフォーム情報入力手段と、
   複数のプログラム間で送受信されるデータオブジェクトの型情報を前記設計図面情報から抽出する送信オブジェクト型情報抽出手段と、
   プラットフォーム情報から各プログラムの実行環境情報を取り出す実行環境抽出手段と、
   前記設計図面情報及びプラットフォーム情報を元にプログラムコードを自動生成するプログラムコード生成手段と、
   前記自動生成されたプログラムコードをビルドするために必要となるプロジェクトファイルを自動生成するプロジェクトファイル生成手段と、
   前記実行環境情報及び送信オブジェクトの型情報から最適なデータ変換関数のプログラムコードを自動生成するマーシャリング関数コード生成手段を有することを特徴とするプログラムコード生成装置。
2. 前記実行環境情報とは、前記設計図面情報に含まれる１つのプログラムを実行するコンピュータのエンディアン情報及び自動生成されたプログラムコードをコンパイルする際に利用するコンパイラで決められている構造体のアライメント情報を含み、これらの予め決定されたエンディアン情報及びアライメント情報及び前記送信オブジェクトの型情報から、最適なマーシャリング関数のプログラムコードを自動生成するマーシャリング関数コード生成手段を有することを特徴とする請求項１に記載のプログラムコード生成装置。
3. 前記実行環境情報とは、前記設計図面情報に含まれる１つのプログラムを実行するコンピュータのエンディアン情報及び自動生成されたプログラムコードをコンパイルする際に利用するコンパイラの設定可能なアライメントの選択肢を含み、前記設定可能なアライメントの選択肢をユーザが選択するアライメント選択手段を有し、ユーザがプログラム毎に選択したアライメント情報をコンパイラのオプションとしてプロジェクトファイルに反映し、前記アライメント情報と前記エンディアン情報及び前記送信オブジェクトの型情報から、最適なマーシャリング関数のプログラムコードを自動生成するマーシャリング関数コード生成手段を有することを特徴とする請求項１に記載のプログラムコード生成装置。
4. 前記実行環境情報とは、前記設計図面情報に含まれる１つのプログラムを実行するコンピュータのエンディアン情報及び自動生成されたプログラムコードをコンパイルする際に利用するコンパイラの設定可能なアライメントの選択肢を含み、前記設定可能なアライメントの選択肢をユーザが選択するアライメント選択手段を有し、ユーザが送信オブジェクト毎に選択したアライメントを、自動生成するプログラムコードの各データオブジェクトの宣言部にて個々に指定し、前記アライメント情報と前記エンディアン情報及び前記送信オブジェクトの型情報から、最適なマーシャリング関数のプログラムコードを自動生成するマーシャリング関数コード生成手段を有することを特徴とする請求項１に記載のプログラムコード生成装置。
5. 送受信するデータオブジェクトのマーシャリングが必要な通信の場合において、送信側プログラムにおいて実行される、受信側プログラムの内部表現形式に直接変換するマーシャリング関数を前記アライメント情報と前記エンディアン情報及び前記送信オブジェクトの型情報を用いて生成することを特徴とする請求項１〜４のいずれか１項に記載のプログラムコード生成装置。
6. 送受信するデータオブジェクトのマーシャリングが必要な通信の場合において、送信側プログラムの内部表現形式を未加工のまま伝送路に送出し、受信側プログラムにおいて実行される、送信側プログラムの内部表現形式から受信側プログラムの内部表現形式に直接変換するマーシャリング関数を前記アライメント情報と前記エンディアン情報及び前記送信オブジェクトの型情報を用いて生成することを特徴とする請求項１〜４のいずれか１項に記載のプログラムコード生成装置。
7. プログラムの構造を表現する設計図面情報をユーザが記述編集可能とする設計図面入力工程と、
   前記設計図面情報で記述されるプログラムをビルド及び実行する環境を指示するプラットフォーム情報をユーザが記述編集可能とするプラットフォーム情報入力工程と、
   複数のプログラム間で送受信されるデータオブジェクトの型情報を前記設計図面情報から抽出する送信オブジェクト型情報抽出工程と、
   プラットフォーム情報から各プログラムの実行環境情報を取り出す実行環境抽出工程と、
   前記設計図面情報及びプラットフォーム情報を元にプログラムコードを自動生成するプログラムコード生成工程と、
   前記自動生成されたプログラムコードをビルドするために必要となるプロジェクトファイルを自動生成するプロジェクトファイル生成工程と、
   前記実行環境情報及び送信オブジェクトの型情報から最適なデータ変換関数のプログラムコードを自動生成するマーシャリング関数コード生成工程を有することを特徴とするプログラムコード生成方法。
8. プログラムの構造を表現する設計図面情報をユーザが記述編集可能とする設計図面入力処理と、
   前記設計図面情報で記述されるプログラムをビルド及び実行する環境を指示するプラットフォーム情報をユーザが記述編集可能とするプラットフォーム情報入力処理と、
   複数のプログラム間で送受信されるデータオブジェクトの型情報を前記設計図面情報から抽出する送信オブジェクト型情報抽出処理と、
   プラットフォーム情報から各プログラムの実行環境情報を取り出す実行環境抽出処理と、
   前記設計図面情報及びプラットフォーム情報を元にプログラムコードを自動生成するプログラムコード生成処理と、
   前記自動生成されたプログラムコードをビルドするために必要となるプロジェクトファイルを自動生成するプロジェクトファイル生成処理と、
   前記実行環境情報及び送信オブジェクトの型情報から最適なデータ変換関数のプログラムコードを自動生成するマーシャリング関数コード生成処理とをコンピュータに実行させることを特徴とするコンピュータプログラム。

Images