(57)【要約】【課題】  プログラムコード生成装置において、組み込みＯＳが有する動的なメモリ管理機構を利用可能なプログラムコードを生成することを目的とする。【解決手段】  設計図面からプログラムコードを生成する生成工程を備えるプログラムコード生成方法であって、前記設計図面の情報を解析し、生成されるプログラムコードに含まれる各オブジェクトの生成及び削除に関する記述を抽出する工程（ステップＳ７０４）と、前記抽出された記述に基づいて、各オブジェクトのライフサイクルを判定する工程（ステップＳ７０５）と、を備え、前記生成工程は、前記設計図面に基づいたプログラムコードの生成にあたり、該プログラムコードがメモリに読み込まれ実行された場合に各オブジェクトが配置されるメモリ領域を、前記工程（ステップＳ７０５）により判定されたライフサイクルに基づいて決定することを特徴とする。【選択図】  図７
2006293437.tif 000002
【特許請求の範囲】
【請求項１】
オブジェクト指向プログラミングにおけるモデル表記言語により記述された設計図面から、プログラムコードを生成する生成手段を備えるプログラムコード生成装置であって、
前記設計図面の情報を解析し、生成されるプログラムコードに含まれる各オブジェクトの生成及び削除に関する記述を抽出する抽出手段と、
前記抽出手段により抽出された記述に基づいて、各オブジェクトの生成から削除までのサイクルを判定する判定手段と、を備え、
前記生成手段は、前記設計図面に基づいたプログラムコードの生成にあたり、該プログラムコードがメモリに読み込まれ実行された場合に各オブジェクトが配置されるメモリ領域を、前記判定手段により判定されたサイクルに基づいて決定することを特徴とするプログラムコード生成装置。
【請求項２】
前記各オブジェクトの生成及び削除に関する記述とは、所定のクラスのインスタンスの生成及び削除に関する記述であることを特徴とする請求項１に記載のプログラムコード生成装置。
【請求項３】
前記各オブジェクトの生成及び削除に関する記述とは、各クラスのインスタンス間で送受信される通信オブジェクトの生成及び削除に関する記述であることを特徴とする請求項１に記載のプログラムコード生成装置。
【請求項４】
前記判定手段は、前記各オブジェクトの生成から削除までのサイクルが、前記プログラムコードが実行された場合の起動から終了までのサイクルに等しいか、あるいは前記プログラムコードの実行中に繰り返される前記各オブジェクトの生成から削除までのサイクルに等しいかを判定することを特徴とする請求項１に記載のプログラムコード生成装置。
【請求項５】
前記判定手段は、関数内のブロックスコープ内で生成と削除を行うオブジェクトについて前記サイクルを判定することを特徴とする請求項１に記載のプログラムコード生成装置。
【請求項６】
前記判定手段により判定されたサイクルをオペレータに通知する通知手段と、
前記プログラムコードがメモリに読み込まれ実行された場合に各オブジェクトが配置されるメモリ領域を、オペレータの指示に基づいて指定する指定手段と、を備え、
前記生成手段は、前記設計図面に基づいたプログラムコードの生成にあたり、該プログラムコードがメモリに読み込まれ実行された場合に各オブジェクトが配置されるメモリ領域を、前記指定手段による指定に基づいて決定することを特徴とする請求項１に記載のプログラムコード生成装置。
【請求項７】
オブジェクト指向プログラミングにおけるモデル表記言語により記述された設計図面から、プログラムコードを生成する生成工程を備えるプログラムコード生成方法であって、
前記設計図面の情報を解析し、生成されるプログラムコードに含まれる各オブジェクトの生成及び削除に関する記述を抽出する抽出工程と、
前記抽出工程により抽出された記述に基づいて、各オブジェクトの生成から削除までのサイクルを判定する判定工程と、を備え、
前記生成工程は、前記設計図面に基づいたプログラムコードの生成にあたり、該プログラムコードがメモリに読み込まれ実行された場合に各オブジェクトが配置されるメモリ領域を、前記判定工程により判定されたサイクルに基づいて決定することを特徴とするプログラムコード生成方法。
【請求項８】
請求項８に記載のプログラムコード生成方法をコンピュータによって実現させるための制御プログラムを格納した記憶媒体。
【請求項９】
請求項８に記載のプログラムコード生成方法をコンピュータによって実現させるための制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアの設計図面からプログラムコードを自動生成するプログラムコード生成装置における情報処理技術に関するものである。
【背景技術】
【０００２】
近年、ソフトウェア設計技術として、モデル駆動型アーキテクチャー（Ｍｏｄｅｌ  Ｄｒｉｖｅｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ技術（以降、ＭＤＡ技術と称す）が広まり、採用されるようになってきている。
【０００３】
一般的にＭＤＡ技術によれば、オペレータが入力したソフトウェアの設計図面情報から各種プラットフォームのプログラムコードを自動的に生成したり、入力したソフトウェアの設計図面情報をＭＤＡ専用ツール上で動作させ検証したりすることが可能である。
【０００４】
また、ソフトウェアの設計図面情報を記述するためには、例えばオブジェクト指向技術のモデル表記言語であるＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）やＳＤＬ（Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ＆  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）などの言語が一般に用いられる。
【０００５】
ここで、既存のプログラムコード生成装置により生成されるプログラムコードの場合、設計図面情報からプログラムコードに変換するルールによっては、そのサイズが大きくなってしまうことがある。このため、生成されたプログラムコードが実行される装置において、実行のために多くのＲＡＭが必要となることがあり、組み込みシステムなどメモリ容量の制限が厳しい環境下では、ＭＤＡ技術の導入に躊躇するケースが少なくない。このため、実行時に必要となるＲＡＭ容量が小さいプログラムコードの生成が望まれている。
【０００６】
一方で、これまで、プログラムコード実行時に必要とされるメモリ容量を削減するための様々な提案がなされている。例えば、設計図面の段階において最適化を行う技術として、特開平１１−２３７９８０号公報掲載の「オブジェクト指向最適化コード生成装置および方法」、特開２００４−１１８８６５号公報掲載の「最適化ソフトウエア生成方法」が挙げられる。同公報によれば、オブジェクト指向機能排除手段を用いて仮想関数の機能を排除、もしくはインスタンスの動的生成の機能を排除することで必要なメモリ容量を増加させることなく組み込みシステムに適用可能なプログラムコードの最適化を行うことができる。
【０００７】
また、組み込みシステム用のソフトウェア開発においてＲＡＭ容量を削減する技術として、特開２０００−４０００５号公報掲載の「プログラム変換装置」や、特開２００１−１８４２１４号公報掲載の「メモリ配置方法、及びオブジェクトクラス設計方法」が挙げられる。同公報によれば、プログラムコード中でｃｏｎｓｔ指定されたインスタンス変数やオブジェクトをＲＯＭ上に配置することにより、ＲＡＭ容量の削減を実現する。
【０００８】
さらに、特開２００２−９１７６２号公報掲載の「プログラム生成装置」では、ＲＯＭのデータのアドレスをＲＡＭへ再配置する際のアドレス変換に関する技術が開示されている。
【特許文献１】特開平１１−２３７９８０号公報
【特許文献２】特開２００４−１１８８６５号公報
【特許文献３】特開２０００−４０００５号公報
【特許文献４】特開２００１−１８４２１４号公報
【特許文献５】特開２００２−９１７６２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、上記特許文献１乃至特許文献５に開示された技術は、いずれもＭＤＡ技術の実行可能モデルを考慮したものではない。したがって、ＭＤＡ技術に適用可能な技術の提案が望まれる。
【００１０】
ここで、現状のＭＤＡツールで生成できるプログラムコードは、汎用ＯＳ上のアプリケーションであることが多く、組み込みシステム向けソフトウェアの領域では実績が乏しい。とりわけ、メモリ領域の使用方法については可変長メモリ管理を前提とするプログラムコードが生成される場合がほとんどで、ＭＤＡツールで生成したプログラムコードの組み込み向けの修正は開発者に任されている場合が多い。
【００１１】
一般的に、汎用ＯＳ上にて行われるアプリケーション開発の場合、Ｃ言語ではｍａｌｌｏｃやｆｒｅｅ、Ｃ＋＋言語ではｎｅｗやｄｅｌｅｔｅなどを使い、メモリ領域の確保と解放とを行っている。また、メモリ領域の確保と解放とは動的に行うことができ、メモリ領域の要求に際してはサイズを指定して行うこともできる。
【００１２】
しかし、これら可変長メモリの割り当てはその管理が煩わしく、一般的に実行速度が遅く時間がかかる。とくにメモリ領域内に要求したサイズ分の空き領域がない場合にはさらに実行時間が増加する。加えて、システムを長時間稼動する場合、フラグメンテーションが発生し、システムの安定動作を保証できなくなる可能性が高い。
【００１３】
こうした理由から、組み込みシステムにおけるソフトウェアの開発では動的な可変長メモリ管理は利用されることは少ない。その代わり、組み込みシステムのＯＳ（以下、組み込みＯＳ）においては、ＲＡＭ上のメモリ領域を固定長で確保し、その領域内を可変長や固定長で確保したり解放したりするメモリ管理機構を備えている場合が多い。
【００１４】
例えば、組み込みＯＳで知られるμＩＴＲＯＮ仕様では、ソフトウェアによる動的なメモリの管理を実現するために、固定長メモリプールや可変長メモリプールと呼ばれるメモリ管理機能が搭載されている。管理機構が単純なため、実行速度が速く、とくに固定長メモリプールでは、フラグメンテーションが起きないという利点がある。これらのメモリ管理機構は、実行速度や安定性保証の面でも有効なため、組み込みシステムのソフトウェアに利用されることは勿論、汎用ＯＳ上のアプリケーションにも利用されることが多い。
【００１５】
このようなことから、組み込みシステム向けのプログラムコードとしてメモリ管理機能を利用可能なプログラムコードを、ＭＤＡツールを用いて生成することが望まれる。
【００１６】
しかしながら、ＭＤＡ技術では設計図面はプラットフォームに非依存であるため、固定長および可変長メモリプールに代表されるメモリ管理機構を利用するプログラムコードが生成されることはなく、メモリプール領域やそのサイズの指定を行う部分は、プログラムコード生成後、開発者自らが生成コードを修正して設定しなしているのが現状である。
【００１７】
本発明は、上記課題に鑑みてなされたものであり、ＭＤＡ技術を用いてソフトウェアの設計図面からプログラムコードを生成するプログラムコード生成装置において、組み込みシステムのＯＳが有する動的なメモリ管理機構を利用可能なプログラムコードを生成することを目的とする。
【課題を解決するための手段】
【００１８】
上記の目的を達成するために本発明に係るプログラムコード生成装置は以下のような構成を備える。即ち、
オブジェクト指向プログラミングにおけるモデル表記言語により記述された設計図面から、プログラムコードを生成する生成手段を備えるプログラムコード生成装置であって、
前記設計図面の情報を解析し、生成されるプログラムコードに含まれる各オブジェクトの生成及び削除に関する記述を抽出する抽出手段と、
前記抽出手段により抽出された記述に基づいて、各オブジェクトの生成から削除までのサイクルを判定する判定手段と、を備え、
前記生成手段は、前記設計図面に基づいたプログラムコードの生成にあたり、該プログラムコードがメモリに読み込まれ実行された場合に各オブジェクトが配置されるメモリ領域を、前記判定手段により判定されたサイクルに基づいて決定することを特徴とする。
【発明の効果】
【００１９】
本発明によれば、ＭＤＡ技術を用いてソフトウェアの設計図面からプログラムコードを生成するプログラムコード生成装置において、組み込みシステムのＯＳが有する動的なメモリ管理機構を利用可能なプログラムコードを生成することが可能となる。
【発明を実施するための最良の形態】
【００２０】
はじめに本発明の実施形態の概要について説明する。一般に、ＭＤＡ技術では、設計図面を解析することにより、オブジェクトの生成や削除箇所を明確にすることができる。そこで、以下の実施形態にかかるプログラムコード生成装置では、当該設計図面の解析によりオブジェクトの生成箇所や削除箇所を明確にし、さらに、該オブジェクトごとのライフサイクルを把握することで、オブジェクト生成に必要なメモリ領域をどう確保するか、すなわち、静的または動的に確保すべきかを判断することができるように構成した。この結果、組み込みシステムのＯＳが有する動的なメモリ管理機構を利用可能なプログラムコードを生成することが可能となった。以下、必要に応じて添付図面を参照しながら本発明の各実施形態を詳細に説明する。
【００２１】
＜プログラムコード生成装置の構成＞
図１は本発明の一実施形態にかかるプログラムコード生成装置の全体構成を示す図である。図１において、１はＣＰＵであり、以下に説明する３〜１０の各装置に対してバス２を介してアクセスし、その制御を行なう。
【００２２】
３はバス２を介してＣＰＵ１からアクセス可能な読み出し専用メモリ（ＲＯＭ）であり、処理プログラム３ａ及び処理プログラム３ａにより使用されるパラメータ３ｂが格納されている。
【００２３】
４は読み書き可能なメモリ（ＲＡＭ）であり、ＲＡＭ４上には、上記処理プログラム３ａにより作成／変更がなされる、設計図面情報、プラットフォーム情報、オブジェクト生成削除箇所情報、オブジェクトライフサイクル情報、プログラムコード、ライブラリ、実行可能形式をそれぞれ格納するための領域（順に４ａ、４ｂ、４ｃ、４ｄ、４ｅ、４ｆ、４ｇ）が確保されている。
【００２４】
５は入力インターフェイスであり、６で示したキーボード、ボタン、マウス、ダイアル等の入力装置を介してなされる入力を受け取る。７は出力インターフェイスであり、８で示したＣＲＴ、ＬＣＤ等の表示媒体、更にはプリンタ、プロッタ等の出力装置に対し、データの表示／出力を行なう。また、９は外部記憶装置インターフェイスであり、１０で示したＨＤ、ＦＤ、ＣＤ−ＲＯＭ、ＭＤ、ＣＦ等の外部記憶装置に対するデータの入出力を行なう。
【００２５】
なお、本実施形態では、処理プログラム３ａやパラメータ３ｂがＲＯＭ３上にあるものとして、また、処理対象となる各データの格納領域（４ａ〜４ｇ）がＲＡＭ４上にあるものとして説明を行なうが、これらはすべて、外部記憶装置１０上に配置することも可能であり、更に、必要に応じて、外部記憶装置１０からＲＡＭ４上にロードし、使用することもできる。また、ＣＰＵ１のキャッシュメモリ上に配置することも可能である。
【００２６】
＜処理プログラム３ａによる処理の概要＞
図２は、処理プログラム３ａによる処理の概要を示すものであり、処理プログラム３ａの構成要件とそれら構成要件が図１の４ａ〜４ｇで示した格納領域に格納されるデータとどのような関係にあるかを示している。
【００２７】
２００は図１における入力インターフェイス５を介して入力されるデータを扱うＧＵＩ入力処理部であり、ユーザはこのＧＵＩ入力処理部によりデータの入力や編集と、各処理部への指示ができるようになっている。なお、本実施形態にかかるプログラムコード生成装置の場合、ＧＵＩ入力処理部は自動生成装置起動部２００の一機能として動作するものとする。
【００２８】
２０１は外部記憶装置１０内から実行可能な設計図面を読み込み、構文解析を行う設計図面入力部であり、処理プログラム３ａが実行可能な設計図面を解釈し、設計図面情報を生成することを可能にする。
【００２９】
２０２は外部記憶装置１０内から実行ファイルの動作するＯＳやＣＰＵやプログラミング言語やフレームワークといったプラットフォームデータを読み込み、構文解析を行うプラットフォーム情報入力部であり、処理プログラム３ａがプラットフォーム情報を生成することを可能にする。
【００３０】
２０３は設計図面入力部２０１において生成された、処理プログラム３ａが解釈することが可能な設計図面情報である。２０４はプラットフォーム情報入力部２０２において生成された、処理プログラム３ａが解釈することが可能なプラットフォーム情報である。
【００３１】
２０５は設計図面情報２０３を解析することで、オブジェクトの生成箇所および削除箇所を抽出するオブジェクト生成削除箇所抽出部であり、設計図面情報２０３からオブジェクトの生成や削除についての記述を抽出し、それがシステム初期化時やシステム稼動後のいかなるタイミングであるかを処理プログラム３ａが解釈することを可能にする。２０６はオブジェクト生成削除箇所抽出部２０５が生成したオブジェクト生成削除箇所情報である。
【００３２】
２０７はオブジェクト生成削除箇所抽出部２０５において生成されたオブジェクト生成削除箇所情報２０６から、オブジェクトのライフサイクルを判定するオブジェクトライフサイクル判定部であり、オブジェクトのライフサイクルがシステムの起動終了と同期した長期的なライフサイクルか、システム稼動中に生成と削除を繰り返す短期的なライフサイクルか、関数内のブロックスコープ内で生成と削除を行うライフサイクルかを処理プログラム３ａが判定することを可能にする。
【００３３】
２０８はオブジェクトライフサイクル判定部２０７が生成するオブジェクトライフサイクル情報であり、判定したオブジェクトのライフサイクル情報をもち、加えて、オブジェクトのデータサイズ、オブジェクトの生成や削除を行うオブジェクトに関する情報を有することもある。
【００３４】
２０９は設計図面情報２０３やプラットフォーム情報２０４やオブジェクトライフサイクル情報２０８から、プログラムコードを自動生成するプログラムコード生成部で、組み込みＯＳで一般的に利用される動的なメモリ管理機構を使って、オブジェクトを配置するメモリ領域を選択および指定可能なプログラムコードを生成することが可能である。
【００３５】
２１０はプログラムコード生成部２０９から生成されたプログラムコードである。２１１はプログラムコードから参照されるライブラリである。２１２はプログラムコード２１０とライブラリ２１１とを用いて生成されたプログラムコード２１０をコンパイル、リンクするコードコンパイラである。
【００３６】
２１３はコードコンパイラ２１２にて生成されたプログラム実行形式で、組み込みＯＳで一般的に利用される動的なメモリ管理機構を使って、オブジェクトを配置するためのメモリ領域を選択および指定可能なプログラム実行形式である。
【００３７】
＜設計図面についての説明＞
次に実行可能な設計図面について説明する。実行可能な設計図面の全体構成を規定する図面は、一般にドメイン図と呼ばれている。具体的な例を図３を用いて説明する。図３は、オペレータからの入力を受け、ライトを付けたり、時間を指定してライトを消すシステムを表したドメイン図の一例である。３０１はライトを明滅するシステムの制御を行うＣｏｎｔｒｏｌｌｅｒドメイン、３０２はオペレータからの操作を受け取るＵＩドメイン、３０３はライトを制御するＬｉｇｈｔドメイン、３０４はタイムサービスを提供するＴｉｍｅｒドメインを示している。
【００３８】
なお、ドメイン同士の結びつきは「関連」と呼ばれ、図３においては矢印付きの点線で表現されており、ここではドメイン間の通信であるイベントの送受信があることを示している。関連３０５は、Ｃｏｎｔｒｏｌｌｅｒドメイン３０１とＴｉｍｅｒドメイン３０４の間で、双方向のイベント通信を行うため、両方向に矢印のついた点線で示している。関連３０６は、Ｃｏｎｔｒｏｌｌｅｒドメイン３０１とＬｉｇｈｔドメイン３０３の間で、片方向のイベント通信を行うため、Ｌｉｇｈｔドメイン３０３側だけに矢印のついた点線で示している。
【００３９】
実行可能な設計図面において、処理を行うオブジェクトの静的な構造を示す設計図面は、クラス図と呼ばれている。具体的な例を図４を用いて説明する。図４は、図３に示すドメイン図において、ライトを明滅するシステムの制御を行うＣｏｎｔｒｏｌｌｅｒドメイン３０１のクラス図の一例である。
【００４０】
図４において、４０１はクラスの名称を示す。ここでは「Ｃｏｎｔｒｏｌｌｅｒ」がクラスの名称である。４０２はＣｏｎｔｒｏｌｌｅｒクラスが「ｎａｍｅ」というＳｔｒｉｎｇ型のインスタンス変数を持つことを表現している。４０３はＣｏｎｔｒｏｌｌｅｒクラスが「ｇｅｔＮａｍｅ」というメソッドをもち、「ｅｖＯｎ」、「ｅｖＯｆｆ」、「ａｌａｒｍ」という３つのイベントを受け取ることを示している。このようにメソッドには処理の内容が書かれており、イベントにはクラス間での通信オブジェクトが書かれている。
【００４１】
実行可能な設計図面において、クラスの動的な振る舞いは、状態の遷移を表現する図や表などで表現する。具体的な例を図５を用いて説明する。図５は状態遷移図を用いてクラスの動的な振る舞いを表現した例で、図４におけるＣｏｎｔｒｏｌｌｅｒクラスの状態遷移図の一例である。
【００４２】
図５において、５０１は初期状態を示し、Ｃｏｎｔｒｏｌｌｅｒクラスのインスタンスが生成されたときに入る状態を表す。初期状態５０１はその状態に留まることはなく、すぐに次の状態５０２に遷移する。５０２は「Ｏｆｆ」と名づけた状態を表し、Ｃｏｎｔｒｏｌｌｅｒクラスのインスタンスが生成された後、この状態に留まる。
【００４３】
５０３は状態から状態への遷移を示し、Ｏｆｆ状態５０２のときにｅｖＯｎイベントが発行されると特定のアクションｅｖＯｎ（）を実行して、状態５０４に遷移する。５０５は、Ｏｎ状態５０４のときにａｌａｒｍイベントが発行されると特定のアクションａｌａｒｍ（）を実行して、再度、Ｏｎ状態５０４に遷移する。なお、一般に、状態遷移図にはアクションを記述することも可能であるが、図５に示した状態遷移図の例では別のファイルに定義して利用する場合を示している。
【００４４】
プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である、設計図面において、各クラスの状態における処理手順の記述は一般的に「アクション」と呼ばれる。なお、本実施形態ではアクションの記述を別ファイルにて提供する場合を例に説明するが、状態遷移図などに記入するようにしてもよい。
【００４５】
次にプラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である、設計図面におけるアクション記述の例を図６に示す。
【００４６】
図６において、６０１は図３のドメイン図で示したシステムの初期化時に実行されるアクションを示した例である。システムで必要となるＣｏｎｔｒｏｌｌｅｒクラス、ＵＩクラス、Ｌｉｇｈｔクラスのインスタンスを、それぞれｎｅｗにより作成する。
【００４７】
ここで作成したインスタンスは、システム全体で操作可能な変数として登録するため、ｒｅｇｉｓｔＬｉｎｋにより登録する。６０２は図５で示したＣｏｎｔｒｏｌｌｅｒクラスの状態遷移図において、Ｏｆｆ状態５０２からＯｎ状態５０４に遷移するアクションｅｖＯｎを記述した例である。
【００４８】
ｅｖＯｎアクション６０２では、このアクション内で、クラスＴｉｍｅｒのインスタンスを新たに生成し、このアクションを実行するＣｏｎｔｒｏｌｌｅｒクラスのインスタンス内で操作可能な変数として登録するため、ｒｅｓｉｇｔＬｉｎｋにより登録する。さらに、ｅｖＯｎアクション６０２では、既にシステム全体で操作可能として登録したＬｉｇｈｔクラスの唯一のインスタンスをｑｕｅｒｙＬｉｎｋにより入手して、ライトを点灯するためのイベントｌｉｇｈｔＯｎをｓｅｎｄＥｖｅｎｔにより送信する。
【００４９】
６０３は図５で示したＣｏｎｔｒｏｌｌｅｒクラスの状態遷移図において、Ｏｎ状態５０４からＯｆｆ状態５０２に遷移するアクションｅｖＯｆｆを記述した例である。ｅｖＯｆｆアクション６０３では、既にシステム全体で操作可能として登録したＬｉｇｈｔクラスの唯一のインスタンスをｑｕｅｒｙＬｉｎｋにより入手して、ライトを消灯するためのイベントｌｉｇｈｔＯｆｆをｓｅｎｄＥｖｅｎｔにより送信する。
【００５０】
さらに、ｅｖＯｆｆアクション６０３では、ｅｖＯｎアクション６０２でＣｏｎｔｒｏｌｌｅｒクラスのインスタンス内で操作可能な変数として登録したＴｉｍｅｒクラスのインスタンスをｑｕｅｒｙＬｉｎｋにより入手してｔｉｍｅｒインスタンスを削除する。加えて、ｅｖＯｆｆアクション６０３では、既にシステム全体で操作可能として登録したＵＩクラスの唯一のインスタンスｕｉをｑｕｅｒｙＬｉｎｋにより入手して、ライトを消灯したことを知らせるイベントｓｔｏｐをｓｅｎｄＥｖｅｎｔにより送信する。
【００５１】
なお、図６に示したアクションの例では、インスタンスの識別に生成時の変数名を利用しているが、インスタンスを識別するための情報、例えばシステム内で特定できる識別番号などを用いる別の方法でも実現可能である。
【００５２】
また、図６に示したアクションの例では、生成したクラスのインスタンスが、システム全体で利用可能なインスタンスであるのか、特定のインスタンス内で利用可能なインスタンスであるのか、アクション記述のブロック内だけで利用可能なインスタンスであるのかを、ユーザがアクションで記述することとしているが、図４で示したドメイン図や図５で示したクラス図からこれらの変数の利用範囲を特定する情報を得ることができるため、特にこの方法によるものでないことはいうまでもない。
【００５３】
＜プログラムコード生成装置における処理の詳細＞
以下、本発明の一実施形態にかかるプログラムコード生成装置における処理の詳細を図面およびフローチャートを参照して説明する。
【００５４】
図７は、本実施形態にかかるプログラムコード生成装置全体の処理手順を示したフローチャートである。はじめにステップＳ７０１において外部記憶装置１０内などに記憶してある実行可能な設計図面を読み込み、設計図面入力部２０１により設計図面情報２０３を生成する。
【００５５】
ステップＳ７０２では、プラットフォーム情報の入力があるか否かを判断し、プラットフォーム情報の入力があると判断した場合にはステップＳ７０３へ分岐し、プラットフォーム情報２０４を生成する。一方、ステップＳ７０２にてプラットフォーム情報の入力がないと判断した場合にはステップＳ７０４へ分岐する。プラットフォーム情報の入力とは、例えば、タスクやスレッドをどこのドメインやクラスなどにマッピングさせるか、実行スピード優先なのか、メモリ容量節約優先なのか、などの生成したプログラムコードが実行されるプラットフォームに依存した情報である。
【００５６】
ステップＳ７０４では、設計図面情報２０３を解析してオブジェクトの生成削除箇所を抽出し、オブジェクト生成削除箇所情報２０６を生成する。ステップＳ７０５では、ステップＳ７０４にて抽出したオブジェクト生成削除箇所情報２０６からオブジェクトのライフサイクルを判定し、オブジェクトライフサイクル情報２０８を生成する。
【００５７】
ステップＳ７０６では設計図面情報２０３とプラットフォーム情報２０４とオブジェクトライフサイクル情報２０８とを用いてプログラムコード２１０を生成する。ステップＳ７０７ではプログラムコード２１０とライブラリ２１１から、コードコンパイラ２１２によりコンパイル、リンクを実施し、プログラム実行形式２１３を生成する。
【００５８】
＜オブジェクト生成削除箇所抽出部における処理の流れ＞
図８は、図２に示すオブジェクト生成削除箇所抽出部２０５における処理の流れを示すフローチャートである。オブジェクト生成削除箇所抽出部２０５は設計図面情報２０３を解析することで、オブジェクトの生成箇所および削除箇所を抽出する。処理プログラム３ａでは、抽出された記述に基づいて、それがシステム初期化時やシステム稼動後のいかなるタイミングであるかを解釈することができる。
【００５９】
ステップＳ８０１では、処理実行時に利用するオブジェクトの生成削除箇所を管理するリストをクリアする。ステップＳ８０２では設計図面情報２０３からアクション記述を読み込む。なお、以下、ステップＳ８０２からステップＳ８１１までの処理は、設計図面情報２０３から読み込まれる全てのアクション記述に対して行われる。
【００６０】
ステップＳ８０３では設計図面情報２０３から読み込んだアクション記述がオブジェクトの生成アクションかを判断し、生成アクションであればステップＳ８０４に分岐し、生成アクションでなければステップＳ８０７に分岐する。
【００６１】
ステップＳ８０４では、対象となるオブジェクトについてのオブジェクト削除情報が既にリストに登録されているか否かを判断し、登録されていると判断した場合には、ステップＳ８０６に分岐し、登録されていないと判断した場合には、ステップＳ８０５に分岐する。
【００６２】
ステップＳ８０５では、オブジェクトの生成情報をリストに新規に追加登録する。一方、ステップＳ８０６では、リストにそのオブジェクトの削除情報がある場合の処理で、リストに既に登録されているオブジェクト削除情報に、オブジェクト生成情報を追記する。
【００６３】
なお、オブジェクトがクラスの実体であるインスタンスの場合、オブジェクト生成情報には、生成されたオブジェクトのクラス名、インスタンス名、生成したインスタンス名、生成したアクション名をリスト記載する。システム起動時に生成されるオブジェクトの場合、生成したインスタンス名にはシステムを表す識別子、例えば「ｓｙｓｔｅｍ」をリストに記載する。
【００６４】
また、オブジェクトがクラスのインスタンス間で送受信されるイベントなどの通信オブジェクトの場合、通信オブジェクトを送信する側がオブジェクト生成アクションとなり、送信するオブジェクトのクラス名、インスタンス名、生成した通信オブジェクトの識別子となる通信オブジェクト名または通信オブジェクトＩＤをリストに記載する。
【００６５】
次に、ステップＳ８０７では設計図面情報２０３から読み込んだアクション記述がオブジェクトの削除アクションかを判断し、削除アクションであればステップＳ８０８に分岐し、削除アクションでなければステップＳ８１１に分岐する。
【００６６】
ステップＳ８０８では、対象となるオブジェクトについてのオブジェクト生成情報が既にリストに登録されているか否かを判断し、登録されていると判断した場合には、ステップＳ８１０に分岐し、登録されていないと判断した場合には、ステップＳ８０９に分岐する。
【００６７】
ステップＳ８０９では、オブジェクトの削除情報をリストに新規に追加登録する。一方、ステップＳ８１０では、リストに既に登録されているオブジェクト生成情報に、オブジェクト削除情報を追記する。
【００６８】
ステップＳ８１１は設計図面情報２０３から読み込んだアクション記述の全てに対し、ステップＳ８０２からの処理を繰り返すことを示す。
【００６９】
＜オブジェクト生成削除箇所情報の例＞
図９は、図６で示したアクション記述に基づいて、オブジェクト生成削除箇所抽出部２０５が生成したオブジェクト生成削除箇所情報２０６の一例を示す図である。図６で示したアクション記述のうち、システムの初期化時に実行されるアクション６０１からｎｅｗを使ったオブジェクト生成箇所を抽出する。
【００７０】
同様に、Ｏｆｆ状態５０２からＯｎ状態５０４に遷移するｅｖＯｎアクション６０２からｎｅｗを使ったオブジェクト生成箇所を抽出する。さらに、Ｏｎ状態５０４からＯｆｆ状態５０２に遷移するｅｖＯｆｆアクション６０３からｄｅｌｅｔｅを使ったオブジェクトの削除箇所を抽出する。こうして全てのアクション記述を含む全ての設計図面情報２０３を解析した結果、ｄｅｌｅｔｅを使ったオブジェクトの削除箇所がなかった場合は、図９の表のエントリに「−」を記載する。
【００７１】
＜オブジェクトライフサイクル判定部における処理の流れ＞
図１０は、オブジェクトライフサイクル判定部２０７における処理の流れを示すフローチャートで、図９に例として示したオブジェクト生成削除箇所情報２０６からオブジェクトライフサイクル情報２０８を生成するための処理の手順を示す。
【００７２】
ステップＳ１００１では図９に例として示したオブジェクト生成削除箇所情報２０６に記載されているオブジェクトを読み込む。なお、以下、ステップＳ１００１からステップＳ１０１４までの処理は、オブジェクト生成削除箇所情報２０６から読み込まれる全てのオブジェクトに対して行われる。
【００７３】
ステップＳ１００２では、図９に例として示したオブジェクト生成削除箇所情報２０６の表にオブジェクトの生成アクションと生成したオブジェクトの情報とが記載されているかを判断し、記載されていればステップＳ１００３に、記載されていなければステップＳ１００４に分岐する。
【００７４】
ステップＳ１００３では、オブジェクトの削除アクションと削除したオブジェクトの情報が記載されているかを判断し、記載されていればステップＳ１００５に、記載されていなければステップＳ１００６に分岐する。
【００７５】
ステップＳ１００５では、ステップＳ１００３でオブジェクトの生成情報と削除情報の両方が記載されていた場合に、生成したオブジェクトと削除したオブジェクトが同じかを判断する。同じであれば、ステップＳ１００９に、違っていればステップＳ１０１０に分岐する。
【００７６】
一方、ステップＳ１００６では、生成したオブジェクトがシステムの初期化処理を表す「ｓｙｓｔｅｍ」であるかどうかを判断する。ｓｙｓｔｅｍであった場合にはステップＳ１００８に、ｓｙｓｔｅｍでなかった場合にはステップＳ１００７に分岐する。
【００７７】
ステップＳ１００７では、オブジェクトを削除するアクションの記述忘れを検知したと判断して、オペレータに対して削除し忘れの警告を通知する。
【００７８】
一方、ステップＳ１００８では、ライフサイクルをシステムと同じだと判断して、オブジェクトライフサイクル情報にライフサイクル「ｓｙｓｔｅｍ」を記載する。
【００７９】
また、ステップＳ１００９では、生成したオブジェクトと削除したオブジェクトとが同じかを判断する。同じであればステップＳ１０１１に、違っていればステップＳ１０１０に分岐する。
【００８０】
ステップＳ１０１０では、システム稼動後に生成と削除が行われるライフサイクルと判断し、オブジェクトライフサイクル情報に、「ｓｈｏｒｔ」と記載する。
【００８１】
ステップＳ１０１１では、オブジェクトの生成と削除のアクションを記述するのではなく、アクションの関数のローカル変数として代用が可能である旨の警告をオペレータに通知する。
【００８２】
一方、ステップＳ１００４では、オブジェクトの削除アクションと削除したオブジェクトの情報とが記載されているかを判断し、記載されていればステップＳ１０１３に、記載されていなければステップＳ１０１２に分岐する。
【００８３】
ステップＳ１０１２では、オブジェクト生成削除箇所抽出リストが不正である旨の処理エラーをオペレータに通知する。
【００８４】
ステップＳ１０１３では、アクションを記述すること自体が不正であると判断し、アクション記述エラーであることをオペレータに通知する。
【００８５】
ステップＳ１０１４では、ステップＳ１００１で開始した、図９に例として示したオブジェクト生成削除箇所情報２０６に記載されているすべてのオブジェクトについて処理を繰り返すことを示す。
【００８６】
オブジェクトライフサイクル判定部２０７が生成するオブジェクトライフサイクル情報２０８の例を図１１に示す。図１１には、図９で示したオブジェクト生成削除箇所情報２０６にオブジェクトのライフサイクルを記載した部分が追加されているが、システム内で特定することのできるオブジェクトの識別情報とライフサイクル情報のみを記載するようにしてもよい。
【００８７】
このように、オブジェクトライフサイクル判定部２０７では、オブジェクトライフサイクル情報２０８から、ライフサイクルとして、図１０のステップＳ１００８の処理で示したシステムと同じである「ｓｙｓｔｅｍ」か、図１０のステップＳ１０１０で示したシステム稼動後に生成と削除を行う「ｓｈｏｒｔ」かを判定する。加えて、ライフサイクル情報を記載すると同時に、図１０のステップＳ１００７で示したオブジェクト削除し忘れ警告、ステップＳ１０１１で示したローカル変数代用可能警告、ステップＳ１０１２で示した処理エラー、ステップＳ１０１３で示したアクション記述エラーをオペレータに通知する。
【００８８】
＜生成されたプログラムコードについての説明＞
図１２は、本実施形態にかかるプログラムコード生成装置により生成されたプログラムコードの一例を示す図である。図１２は、図１１で示したオブジェクトライフサイクル情報２０８を元に、ライフサイクル「ｓｙｓｔｅｍ」および「ｓｈｏｒｔ」として分類されたオブジェクトを生成するプログラムコードの例を示している。なお、図６に示したアクションのうち、クラスのインスタンスを作成するｎｅｗアクションを生成した場合を示している。また、生成されたプログラムコードは、組み込みＯＳで知られるμＩＴＲＯＮ仕様の動的なメモリ管理機構、固定長メモリプールを利用することができる。
【００８９】
図１２において、ライフサイクル「ｓｙｓｔｅｍ」はシステム起動後にオブジェクトが生成され、システム稼動中は削除されることがないため、配列として定義し、アクションｎｅｗから生成したプログラムコード上の関数ａｌｌｏｃ_ｓｙｓｔｅｍＳｐａｎは、その配列のアドレスを返す関数ｇｅｔＡｄｄｒＦｒｏｍＯｂｊＴａｂｌｅとして実装する。
【００９０】
図１２において、ライフサイクル「ｓｈｏｒｔ」はシステム稼動中に生成と削除を繰り返すオブジェクトであるため、サイズごとに割り当てた固定長メモリプールからオブジェクトのメモリ領域を確保する。アクションｎｅｗから生成したプログラムコード上の関数ａｌｌｏｃ_ｓｈｏｒｔＳｐａｎは、サイズごとに割り当てた固定長メモリプールからメモリ領域を確保するμＩＴＲＯＮのサービスコール ｇｅｔ_ｍｐｆ として実装する。
【００９１】
図１２に示すプログラムコードの例では、静的に確保した配列のアドレスを返す関数やμＩＴＲＯＮ仕様の固定長メモリプールを利用する例を示したが、本発明はこの方法に限られるものではない。また、図１２に示すプログラムコードの例では、ライフサイクル「ｓｈｏｒｔ」と判定したオブジェクトをサイズごとに分けて用意したメモリプールから確保することとしているが、本発明は特にこれに限られず、図１１に例として示したオブジェクトライフサイクル情報から得られるクラス、インスタンスなどの他の情報を使って別々のメモリプールを用意して、そこからメモリ領域を確保する実装も可能である。
【００９２】
以上の説明から明らかなように、本実施形態にかかるプログラムコード生成装置によれば、設計図面を解析し、オブジェクトのライフサイクルを判定することで、そのオブジェクト自身とそのオブジェクトが利用するメモリ領域の確保をいつ行うべきかを判断することができる。
【００９３】
これにより、たとえば、静的な配列で確保するのか、動的なメモリ管理機構を利用するかを分類することができる。この結果、組み込みＯＳが有する動的なメモリ管理機構を利用可能なプログラムコードを生成することが可能となる。そして、動的なメモリ管理機構を利用する場合にあっては、利用サイズごとに用意した固定長メモリプールから確保する従来の方法以外にも、メモリ領域を利用するオブジェクト専用にメモリプールを割り当てたり、特定インスタンスの特定サイズに専用のメモリプールを割り当てたり、様々な形態でのメモリ領域利用が可能になる。
【００９４】
さらに、使用するメモリ管理機構は、従来から組み込みＯＳで搭載されてきたメモリ管理機構であるため、実行速度やフラグメンテーションの不安がなく、組み込みソフトウエアでの利用も可能である。
【００９５】
＜他の実施形態＞
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【００９６】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【００９７】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００９８】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【００９９】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１００】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【０１０１】
【図１】本発明の一実施形態にかかるプログラムコード生成装置の全体構成を示す図である。
【図２】プログラムコード生成装置の処理プログラム３ａにおける処理の概要を示す図である。
【図３】設計図面情報のうちドメイン図の一例を示す図である。
【図４】設計図面情報のうちクラス図の一例を示す図である。
【図５】設計図面情報のうち状態遷移図の一例を示す図である。
【図６】設計図面情報に含まれるアクション記述について説明した図である。
【図７】本発明の一実施形態にかかるプログラムコード生成装置全体の処理手順を示したフローチャートである。
【図８】オブジェクト生成削除箇所抽出部における処理の流れを示すフローチャートである。
【図９】オブジェクト生成削除箇所抽出部において抽出されたオブジェクト生成削除箇所情報の一例を示す図である。
【図１０】オブジェクトライフサイクル判定部における処理の流れを示すフローチャートである。
【図１１】オブジェクトライフサイクル判定部において生成されたオブジェクトライフサイクル情報の一例をを示す図である。
【図１２】本発明の一実施形態にかかるプログラムコード生成装置において生成されたプログラムコードの一例を示す図である。
【符号の説明】
【０１０２】
１：ＣＰＵ
２：バス
３：ＲＯＭ
４：ＲＡＭ
４ａ：設計図面情報
４ｂ：プラットフォーム情報
４ｃ：オブジェクト生成削除箇所情報
４ｄ：オブジェクトライフサイクル情報
４ｅ：プログラムコード
４ｆ：ライブラリ
４ｇ：実行可能形式
５：入力インターフェース
６：キーボード、ボタン、マウス、ダイアル
７：出力インターフェース
８ａ：ＣＲＴ、ＬＣＤ
８ｂ：プリンタ、プロッタ
９：外部記憶装置インターフェース
１０：ＨＤ、ＦＤ、ＣＤ−ＲＯＭ、ＭＤ、ＣＦ、・・・（ファイル）
【図１】
2006293437.tif 000003
【図２】
2006293437.tif 000004
【図３】
2006293437.tif 000005
【図４】
2006293437.tif 000006
【図５】
2006293437.tif 000007
【図６】
2006293437.tif 000008
【図７】
2006293437.tif 000009
【図８】
2006293437.tif 000010
【図９】
2006293437.tif 000011
【図１０】
2006293437.tif 000012
【図１１】
2006293437.tif 000013
【図１２】
2006293437.tif 000014