JP2007122187A

JP2007122187A - プログラム・コード生成装置

Info

Publication number: JP2007122187A
Application number: JP2005310475A
Authority: JP
Inventors: Toru Nomaguchi; 徹野間口
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2005-10-25
Filing date: 2005-10-25
Publication date: 2007-05-17

Abstract

【課題】製品内に利用しない機能を実現するためのコードが混入することを防止して、製品の使用リソースを削減し、かつ、デバッグ容易性を向上させる。
【解決手段】特定のソフトウェア部品構成に応じて、汎用的なソフトウェア部品の集まりを、特定製品向けのソフトウェア部品の集まりに変換することで、多製品対応のために汎用的なソフトウェア部品を組み合わせるという手法を用いて開発を行なった際に、製品内に利用しない機能を実現するためのコードが混入することを防止する。
【選択図】図１

Description

複数の汎用的なソフトウェア部品を組み合わせて製品プログラムを構築する開発手法であるソフトウェア・プロダクトラインによる開発を行なった際に、構築した製品プログラムに製品に不要な機能を実現するためのコードが混入することを防止するプログラム・コード生成装置に関する。但し、ここでいう汎用的なソフトウェア部品とは、モデル駆動型アーキテクチャ(Model Driven Architecture技術(以降、ＭＤＡ技術と称す))におけるプラットフォーム非依存な実行可能設計図面(Plathome Independed Model: PIM)のような、プラットフォームに非依存なソフトウェア部品を対象としている。

近年、組み込みソフトウェア開発の規模の増大が進んでおり、加えて、製品サイクルの短縮により、多製品の組み込みソフトウェア開発を効率的に行うための手法が必要とされており、ソフトウェア部品を組み合わせて複数の類似のソフトウェアを作りこんでいく開発手法であるソフトウェア・プロダクトライン(Software Product Line: SPL)を用いた開発や、実行可能な設計図面を作り込んでゆくことでソフトウェアを作りこんでいく開発手法であるモデル駆動型アーキテクチャ(Model Driven Architecture技術(以降、MDA技術と称す))を用いた開発が採用されるようになってきている。

ソフトウェア・プロダクトラインとは、汎用的に作りこまれたソフトウェア部品を組み合わせてプログラムを構築する手法で、多人数並行開発を可能にし、また、多くのソフトウェア部品の再利用を可能にする技術である。

ＭＤＡ技術とは、オペレータが入力したソフトウェアの設計図面情報から各種プラットフォームのプログラム・コードを自動的に生成し、且つ、入力したソフトウェアの設計図面情報をＭＤＡ専用ツール上で動作および検証することが可能な技術である。これらソフトウェアの設計図面情報の代表的な例としては、オブジェクト指向技術のモデル表記言語であるＵＭＬ(Unified Modeling Language)やＳＤＬ(Specification & Description Language)などが挙げられる。

しかしながら、複数の製品プログラムで利用するために汎用的に作りこまれたソフトウェア部品は、特定の製品に対してカスタマイズされておらず特定製品において利用しない機能に関するプログラム・コードが混入してしまうという問題がある。加えて、既存のプログラム生成装置から生成されるプログラム・コードは、設計図面からプログラム・コードに変換するルールによっては、生成されるコードのサイズが大きく、実行のために多くのＲＯＭ、ＲＡＭ、ＣＰＵリソースを必要とするという問題がある。このため、組み込みシステムなどのメモリ容量の制限が厳しい領域では、ＭＤＡ技術の導入やＳＰＬ技術の導入に躊躇するケースが少なくない。

特開平５−４６３７４号公報（特許文献１）は、設計図面とソースコードの対応関係を持たせてソフトウェア部品として扱う技術で、設計図面とソースコードの食い違いを防止する技術である。この技術によれば、図面レベルで矛盾無くソースコードを結合することが可能であるが、設計図面の組み合わせの際に、最適化は考えられていない。

特開平６−１１９１５６号公報（特許文献２）は、部品プログラムを組み合わせてプログラムを自動生成する方法に関し、特に、プログラムの特性を基準として選択した部品同士の結合プログラムを自動生成する技術である。この技術では、様々なパターンのプログラム・コードを予め用意する必要があり、汎用的な部品を作るのに手間がかかるという問題があった。

設計図面の段階での最適化を行う技術については、特開平１１−２３７９８０号公報（特許文献３）掲載の「オブジェクト指向最適化コード生成装置および方法」、特開２００４−１１８８６５号公報（特許文献４）掲載の「最適化ソフトウェア生成方法」で、オブジェクト指向機能排除手段を用いて仮想関数の機能を排除、もしくはインスタンスの動的生成の機能を排除することで必要なメモリ容量を増加させることなく組み込み制御システムに適用可能なコードの最適化を行うことを可能にしている。

さらに、組み込みシステムのソフトウェア開発におけるRAM容量を削減する技術については、特開２０００−４０００５号公報（特許文献５）掲載の「プログラム変換装置」や特開２００１−１８４２１４号公報（特許文献６）掲載の「メモリ配置方法、及びオブジェクトクラス設計方法」で、プログラム・コード中のconst指定されたインスタンス変数やオブジェクトをROM上に配置することにより、RAM容量の削減を図っている。

また、特開２００２−９１７６２号公報（特許文献７）掲載の「プログラム生成装置」は、ROMのデータへのアドレスをRAMへ再配置する際のアドレス変換に関するもので、設計図面のデータを解析して、ＲＡＭに再配置をする。これらの技術は、設計図面やアクションをＣ言語に変換する際に最適化を加える技術であり、設計図面そのものを最適化するという観点の最適化ではない。また、製品の構成情報を元に、汎用的なソフトウェア部品を最適化するという視点はない。

特開平５−４６３７４号公報特開平６−１１９１５６号公報特開平１１−２３７９８０号公報特開２００４−１１８８６５号公報特開２０００−４０００５号公報特開２００１−１８４２１４号公報特開２００２−９１７６２号公報

汎用的なソフトウェア部品を構築し、その汎用的なソフトウェア部品を組み合わせることにより多製品に対応するという手法を用いた際に生じる課題を解決する。

汎用的なソフトウェア部品は、各製品で利用することが可能であるが、その反面、製品によっては利用しない機能を実現するためのコードが含まれてしまうなど、１つ１つの製品にとって最適な構成となっておらず、ＲＯＭやＲＡＭやＣＰＵリソースの限られた組み込み環境において、これを最適な構成にすることが課題となっている。また、汎用的に構築されたソフトウェア部品は、通常のソフトウェアに比べて複雑な構造となるため、デバッグが容易ではないという問題もあり、デバッグを簡単に行う仕掛けを作ることも課題となっている。

本発明は、多製品対応のために汎用的なソフトウェア部品を組み合わせるという手法を用いて開発を行った際に、製品内に利用しない機能を実現するためのコードが混入することを防止して、製品の使用リソースを削減し、かつ、デバッグ容易性を向上させるプログラム・コード生成装置を提供することを目的とする。

本発明のプログラム・コード生成装置は、インスタンスの配置やインスタンスの値やインスタンス間の関連といった製品の構成を解析する製品構成情報解析手段と、汎用的なクラス定義などといった製品を構成する部品の基本的な型定義を解析する汎用部品群情報解析手段と、前記製品構成情報解析手段より得られた製品の構成から、製品を構成する部品間の関連を抽出する構成部品関連抽出手段と、前記構成部品関連抽出手段より得られた部品間の関連と、前記汎用部品群情報解析手段より得られた部品の基本的な型の定義から、製品に特化した部品を生成する部品特化手段と、前記部品特化手段より得られた製品に特化した部品を、前記製品構成情報解析手段より得られた製品の構成にしたがって組み合わせたものから、製品としてのプログラム・コードを自動生成するプログラム・コード生成手段と、前記プログラム・コード生成手段より得られたプログラム・コードをコンパイル・リンクすることを特徴とするコンパイル・リンク手段とを有する。

本発明によれば、多製品対応のために汎用的なソフトウェア部品を組み合わせるという手法を用いて開発を行なった際に、製品内に利用しない機能を実現するためのコードが混入することを防止して、製品の使用リソースを削減し、かつ、デバッグ容易性を向上させる。

即ち、請求項１に記載のプログラム・コード生成装置を用いることで、汎用的なソフトウェア部品を製品に応じて組み合わせて、製品に特化したソフトウェア部品やプログラム・コードを自動生成することが可能となる。すなわち、汎用的なソフトウェア部品群を組み合わせることで多製品対応することが可能となり、また、製品の特性に応じて省メモリ、実行速度高速化といった最適化されたプログラム・コードの自動生成が可能となり、それに加えて、製品にあわせてスリム化されたソフトウェア部品を用いて用意にデバッグすることも可能になる。請求項３、請求項４、請求項５、請求項６で提案した手法を取り入れることにより、これらの効果はより顕著になる。

また、請求項２で示した部品変換ルールを外部から取り込む方法を採用することにより、ユーザが望む任意の変換をすることが可能になるため、より洗練されたソフトウェア部品やプログラム・コードの生成が可能になる。

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

４は読み書き可能なメモリ（ＲＡＭ）であり、ＲＡＭ４上には、上記処理プログラム３により作成／変更がなされる、製品構成情報、汎用部品群情報、部品変換ルール情報、部品関連情報、特定製品向け部品群情報、製品用コード、製品プログラムをそれぞれ格納するための領域（順に４ａ、４ｂ、４ｃ、４ｄ、４ｅ、４ｆ、４ｇ）が確保されている。

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

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

図２は、図１において３ａで示した処理プログラムの構成要件とそれら構成要件が第１図４ａ〜４ｇで示した格納領域に格納されるデータとどのような関係にあるかを示すものである。
図２において、２００は入力インターフェイス５を介して入力されるデータを扱うＧＵＩ入力処理部であり、ユーザはこのＧＵＩ入力処理部２００によりデータの入力、編集ができるようになっている。

２０１は、インスタンス配置やインスタンス値やインスタンス同士のリンクといった製品構成を外部記憶装置内から読み込み、構文解析を行う製品構成情報解析部であり、処理プログラムが読む込むことが可能な製品構成を解釈し、製品構成情報を生成することを可能にする。
２０２は、製品構成情報解析部２０１より生成された、処理プログラムが解釈することが可能な製品構成情報である。
２０３は、汎用的なクラス定義群やそれらの動作記述といった汎用部品群の内、製品構成情報２０２に利用されることが明記されている汎用部品群を外部記憶装置内から読み込み、構文解析を行う汎用部品群情報解析部であり、汎用部品群情報を生成することを可能にする。

２０４は、汎用部品群情報解析部２０３より生成された、処理プログラムが解釈することが可能な汎用部品群情報である。
２０５は、多重度や関連の有無に依存しない汎用的な記述を多重度や関連の有無に依存する記述に変換する部品変換ルールを外部記憶装置内から読み込み、構文解析を行う部品変換ルール情報解析部であり、処理プログラムが読む込むことが可能な部品変換ルール情報を生成することを可能にする。

２０６は、部品変換ルール情報解析部２０５より生成された、処理プログラムが解釈することが可能な部品変換ルール情報である。
２０７は、製品構成情報２０２を解析し、製品構成情報２０２内で利用されているクラスについて、リンクより必要とされる最小限の多重度や関連線の有無といった部品関連情報を抽出する構成部品関連抽出部であり、目的とする製品における最小限の多重度や関連線に関する部品関連情報を生成することを可能にする。
２０８は、構成部品関連抽出部２０８より生成された、処理プログラムが解釈することが可能な部品関連情報である。

次に、汎用部品群情報や特定製品向け部品群情報の一実施形態について説明する。これらの部品群の実施形態としてMDA（Model Driven Archetcture）の実行可能な設計図面を用いた場合について説明する。

実行可能な設計図面の全体構成を規定する図面は、一般にドメイン図と呼ばれている。実際の例を図３に示す。図３は、オペレータからの入力を受け、オペレータに指定されたスケジュールでハードを制御するシステムを表したドメイン図の一例である。３０１はハードの制御を指定されたスケジュールで行うControllerドメイン、３０２はオペレータからの操作を受け取るUIドメイン、３０３はハードを直接的に制御するDeviceドメイン、３０４はタイムサービスを提供するTimerドメインを示している。さらに、ドメイン同士の結びつきは、関連と呼ばれ、図３においては矢印付きの点線で表現される。図３では、ドメイン間の通信であるイベントの送受信を行う場合に点線で結ぶ例を示している。３０５は、関連の一例で、Controllerドメイン３０１とTimerドメイン３０４の間で、双方向のイベント通信を行うため、両方向に矢印のついた点線で示している。３０６も関連の一例で、Controllerドメイン３０１とDeviceドメイン３０３の間で、片方向のイベント通信を行うため、Deviceドメイン３０３側だけに矢印のついた点線で示す。

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

図４において、４０１の四角形はDeviceクラスを表し、４０２の四角形はControllerクラスを表す。４０３は、２項関連線と呼ばれ、Deviceクラス４０１とControllerクラス４０２が関連を持ち、Deviceクラス４０１からみてControllerクラス４０２が１個、Controllerクラス４０２からみてDeviceクラス４０１が0個から複数個の関連を持っていることを表している。４０４はクラスの名称を示し、図４の例では「Controller」がクラスの名称である。４０５はControllerクラスが「name」というString型のインスタンス変数を持つことを表現している。４０６はControllerクラスが「getName」、「on」、「off」、「offAll」という４つのメソッドをもつことを示している。メソッドは処理の内容が書かれており、イベントはクラス間での通信オブジェクトの一例である。

実行可能な設計図面において、クラスの動的な振る舞いは状態の遷移を表現する図や表などで表現する。実際の例を図５に示す。図５は状態遷移図を使ったクラスの動的な振る舞いを表現した例で、図４におけるControllerクラスの状態遷移図の例である。

図５において、５０１は初期状態を示し、Controllerクラスのインスタンスが生成されたときに入る状態を表す。初期状態５０１はその状態に留まることはなく、すぐに次の状態５０２に遷移する。５０２は「Off」と名づけた状態を表し、Controllerクラスのインスタンスが生成された後、この状態に留まる。５０３は状態から状態への遷移を示し、Off状態５０２のときにevOnイベントが発行されると特定のアクションevOn()を実行して、状態５０４に遷移する。５０５は、On状態５０４のときにevOff()イベントが発行されると特定のアクションevOff()を実行して、再度、On状態５０４に遷移する。５０８は、「Cleaning」と名づけた状態を表す。５０６は、Ｏｎ状態５０４のときにevClean()イベントが発行されると特定のアクションevClean()を実行して、Cleaning状態５０８に遷移する。５０７は、Off状態のときにevClean()イベントが発行されると特定のアクションevClean()を実行して、Cleaning状態５０８に遷移する。５０９は、終了状態で、Cleaning状態に遷移した後、終了することを表す。なお、一般に、状態遷移図にはアクションを記述することも可能であるが、図５に示した状態遷移図の例では別のファイルに定義して利用する例を示している。
プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である、設計図面において、各クラスの状態における処理手順の記述を一般にはアクションと呼ぶ。本発明においてはアクションの記述を別ファイルにて提供する場合を例に説明するが、状態遷移図などに記入する場合も問わない。
プラットフォーム非依存であり、実行可能であり、かつオブジェクト指向である、設計図面におけるアクション記述の例を図６に示す。
６０１は、Controllerクラスのon()メソッドが呼ばれた時に、リンクしている処理であり、引数より入力したデバイス識別子deviceIDと一致するリンク先デバイス・インスタンス１つに対してイベントevOn()が投入されることを表している。ここで用いられているFind構文は、条件に合ったリンク先の要素を１つだけ探索することを表している。また、Generate〜To構文は指定した宛先のインスタンスに対してイベントを投入する処理を表している。

６０２は、Controllerクラスのoff()メソッドが呼ばれた時に、リンクしている処理であり、引数より入力したデバイス識別子deviceIDと一致するリンク先デバイス・インスタンス１つに対してイベントevOff()が投入されることを表している。
６０３は、ControllerクラスのoffAll()メソッドが呼ばれた時に、リンク先デバイス・インスタンス全てに対してevOff()が投入されることを表している。ここで用いられているForeach構文は、条件に合ったリンク先インスタンス全てに対して、ループ処理を実行することを表している。

本実施形態で示したアクション言語において記述可能な構文には、探索を表すFind構文、ループ処理を表すForeach構文／While構文（Continue構文、Return構文を併用可）、ソート処理を表すSort構文、リンクの動的な接続や切断を表すLink構文／Unlink構文、イベントの投入やキャンセルを表すGenerate構文／Cancel構文、条件分岐を表すIf〜Else構文、変数定義構文、代入構文、メンバ関数実行構文などがある。

これらのうち多重度によって、実装形態が大きく変化するものは、クラス間のリンクを操作する構文である、Find構文、Foreach構文、Sort構文、Link構文、Unlink構文、条件によって処理されるブロックや回数が異なるIf構文、While構文である。また、製品構成を表すリンクは静的に決定するため、製品構成を表すリンクの構築の際に、Link構文やUnlink構文が呼ばれることがない。

なお、利用するアクション言語によってこれら構文は異なるが、各アクション言語が目的とする機能は同等の機能であり、本特許で述べる発明の形態は、アクション言語の構文によらず有効である。

Ｃ言語などのプログラミング言語で多重度や実装形態の異なる対象の動作記述をする際には、プログラミングを書き直さなければならないが、アクション言語の場合には、多重度に依存しない書き方が可能なので、書き直さないで動作させることが可能である。

次に、製品構成情報２０２の実施形態としてＵＭＬ（Unified Modeling Language）の設計図面の一つであるオブジェクト図を用いた場合について説明する。但し、本実施形態において、製品構成は静的に決定するということを前提としている。

図７は、製品構成情報２０２をオブジェクト図で表したものである。
７０１はControllerクラスのインスタンス ctrl、７０５はDeviceクラスのインスタンスdevX、７０６はDeviceクラスのインスタンス devY、７０７はDeviceクラスのインスタンス devZを表している。これらのインスタンスの記述では属性値の初期値の設定も可能であるという特徴がある。７０２は、オブジェクトctrl ７０１とオブジェクトdevX ７０５を結ぶA1クラス関連線４０３に属するリンクである。７０３は、オブジェクトctrl ７０１とオブジェクトdevY ７０６を結ぶA1クラス関連線４０３に属するリンクである。７０４は、オブジェクトctrl ７０１とオブジェクトdevZ ７０６を結ぶA1クラス関連線４０３に属するリンクである。

オブジェクト図では、ソフトウェア部品の配置情報や、ソフトウェア部品の関連情報や、ソフトウェア部品の内部パラメータといった情報の設定が可能で、この情報を製品構成情報２０２として用いる。

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

実施形態１では、システム全体のフローについて説明する。なお、実施形態1で説明する内容は、請求項１と請求項３に相当する。
実施形態２では、本システムで扱う汎用部品群情報２０４の詳細な説明をする。
実施形態３では、本システムで扱う汎用部品群情報２０４内の動作記述であるアクションの変換手順について説明する。なお、実施形態３で説明する内容は、請求項２、請求項４、請求項５に相当する。
実施形態４では、本システムで扱う汎用部品群情報２０４内の全体的な動作記述である状態遷移図の変換手順について説明する。なお、実施形態４で説明する内容は、請求項６に相当する。

（実施形態１）
以下、本発明の実施形態を図面およびフローチャートを参照して説明する。
図８は、本実施形態のシステム全体の処理手順を示したフローチャートである。
ステップ８０１において、製品構成情報解析部２０１を起動して、ユーザが設定した製品構成を構文解析し、製品構成情報２０２を生成する。
ステップ８０２において、構成部品関連抽出部２０７を起動して、ステップ８０１で得られた製品構成情報２０２を解析して、部品関連情報２０８を抽出する。
ステップ８０３において、汎用部品群情報解析部２０３を起動して、製品構成情報２０２内に製品で利用されていることが記述されている汎用部品群を構文解析して、汎用部品群情報２０４を抽出する。

ステップ８０４において、部品変換ルール情報解析部２０５を起動して、汎用部品から特化部品に変換する手順が記述された部品変換ルールを構文解析して、部品変換ルール情報２０６を抽出する。
ステップ８０５において、部品特化部２０９を起動して、ステップ８０２において得られた部品関連情報２０８と、ステップ８０３において得られた汎用部品群情報２０４を、ステップ８０４で得られた部品変換ルール情報２０６に基づき合成して、特定製品向け部品群情報２１０を生成する。

ステップ８０６において、プログラム・コード生成部２１１を起動して、ステップ８０１で得られた製品構成情報２０２と、ステップ８０５で得られた特定製品向け部品群情報２１０を用いて、製品用コード２１２を生成する。
ステップ８０７において、コンパイル・リンク部２１３を起動して、ステップ８０６で得られた製品用コードをコンパイル・リンクして、製品プログラムを生成する。

図９は、図２における本実施形態の構成部品関連抽出部２０７に関するフローチャートである。構成部品関連抽出部２０７は、製品構成情報２０２を解析することで、部品関連情報２０８を抽出する。製品構成情報２０２からクラス間の関連線の有無や多重度の範囲を限定する部品関連情報２０８を抽出することで、汎用部品群情報２０４に対して実施可能な最適化を特定することを可能にする。

ステップ９０１からステップ９０３のループは、製品構成情報２０２に記述された全てのインスタンスに対して実行するループであり、全インスタンスに対して関連線ごとにリンク数を集計する処理を行う。ステップ９０３において、指定インスタンスのリンク数を関連線ごとに集計する。

ステップ９０１からステップ９０３のループ処理が終えた後、ステップ９０４からステップ９０７で、製品構成情報２０２に記述された全ての関連に対してループ処理をする。該ループでは製品構成情報内の各関連線に対して、ステップ９０５、ステップ９０６の処理をする。

ステップ９０５において、各クラス関連線ごとに、ステップ９０２で得られたリンク数の最大値と最小値を取得する。ただし、リンクが存在しない場合は、最小値を０、最大値を０とする。
ステップ９０６において、各クラス関連線ごとに、有無や多重度を設定する。なお、ここで設定した情報が部品関連情報２０８である。

図１０に汎用部品群情報２０４の一実施形態を示す。レールの上にいくつかのモータやセンサやソレノイドが乗っている汎用部品群の例を示す。
１００１はレールクラス、１００２はモータクラス、１００３はセンサクラス、１００４はソレノイドクラスである。

１００５は、レールクラス１００１とレールクラス１００１を結ぶクラス関連線で、0から複数個のレールクラス１００１同士が関連を持っていることを表している。
１００６は、レールクラス１００１とモータクラス１００２を結ぶクラス関連線で、レールクラス１００１が０から複数個のモータクラス１００２と、モータクラス１００２が０から複数個のレールクラス１００１とリンク可能であることを表している。
１００７は、レールクラス１００１とソレノイドクラス１００４を結ぶクラス関連線で、レールクラス１００１が０から複数個のソレノイドクラス１００４と、ソレノイドクラス１００４が０から複数個のレールクラス１００１とリンク可能であることを表している。

１００８は、レールクラス１００１とセンサクラス１００３を結ぶクラス関連線で、レールクラス１００１が０から複数個のセンサクラス１００３と、センサクラス１００３が０から複数個のレールクラス１００１とリンク可能であることを表している。
クラス関連線１００５、１００６、１００７、１００８上に記載されているアスタリスクは、０から複数個あることを表しており、製品ごとに、アスタリスクを、リンクしないことを表す"0"や、リンクが１つしかないことを表す"１"や、リンクが１つあるか無いかということを表す"0..1"に置き換えることが可能という特徴がある。

図１１に製品構成情報２０２の一実施形態を示す。ここで、図１１の製品構成情報２０２を製品Ａの製品構成とする。
レールA １１０１、レールB １１０２、レールC １１０３、レールD １１０４は、レールクラス１００１のインスタンスを表している。モータＥ１１０５、モータＦ１１０６は、モータクラス１００２のインスタンスを表している。ソレノイドＧ１１０７は、ソレノイドクラス１００４のインスタンスを表している。
レールＡ１１０１は、モータＥへのＡ２リンク１１１１と、レールＢへのＡ１リンク（右）１１０８を保持している。

レールＢ１１０２は、レールＡ１１０１へのＡ１リンク（左）１１０８と、レールＣ１１０３へのＡ１リンク（右）１１０９を保持している。
レールＣ１１０３は、レールＢ１１０２へのＡ１リンク（左）１１０９と、レールＤへのＡ１リンク（右）と、モータＦ１１０６へのＡ２リンク１１１２を保持している。
レールＤ１１０４は、レールＣ１１０３へのＡ１リンク（左）１１１０と、ソレノイドＧへのＡ４リンクを保持している。

モータＥ１１０５は、レールＡ１１０１へのＡ２リンク１１１１を保持している。
モータＦ１１０６は、レールＣ１１０３へのＡ２リンク１１１２を保持している。
ソレノイドＧ１１０７は、レールＤ１１０４へのＡ４リンク１１１３を保持している。
各インスタンスの保持しているリンク数を、各クラスごとに、リンク数の最小数、最大数という観点でまとめなおしたものを下記に示す。

レールクラス１００１のインスタンスであるレールＡ１１０１、レールＢ１１０２、レールＣ１１０３、レールＤ１１０４について、Ａ１リンク（右）、Ａ１リンク（左）、Ａ２リンク、Ａ４リンクが０か１つ保持している。
モータクラス１００２のインスタンスであるモータＥ１１０５、モータＦ１１０６について、Ａ２リンクは１つ保持している。
ソレノイドクラス１００４のインスタンスであるソレノイドＧ１１０７について、Ａ４リンクは１つ保持している。

図１２に、図１１より得られた各関連線ごとのリンクの最大値、最小値を図１０の汎用部品群情報に反映させた図を示す。
１２０１は、レールクラス、１２０２はモータクラス、１２０３はソレノイドクラスである。
１２０４は、レールクラス１２０４とレールクラス１２０４とを結ぶ関連線Ａ１で、両端の多重度が"0..1"である。

１２０５は、レールクラス１２０１とモータクラス１２０２とを結ぶ関連線Ａ２で、レールクラス１２０１側の多重度が"1"、モータクラス１２０２側の多重度が"0..1"である。
１２０６は、レールクラス１２０１とソレノイドクラス１２０３とを結ぶ関連線Ａ４で、レールクラス１２０１側の多重度が"1"、ソレノイドクラス１２０３側の多重度が"0..1"である。

図１３は、図１０の汎用部品群情報２０４を使用した製品構成情報２０２であり、図１３の製品構成情報２０２を、構成部品関連抽出部２０７で解析し、そこで得られた部品関連情報２０８を汎用部品群情報２０４に反映させることで得られる特定製品向け部品群情報２１０が図１４である。ここで、図１３の製品構成情報２０２を製品Ｂ用の構成情報とする。

図１１の製品Ａ用製品構成情報２０２を用いた場合に得られるのが図１２の特定製品向け部品群情報２１０であり、図１３の製品Ｂ用製品構成情報２０２を用いた場合に得られるのが図１４の特定製品向け部品群情報２１０である。図１２と図１４を比較すると、センサクラス１４０３が無くなっているという違いがある。製品構成によって、特定製品向け部品が異なったものになることが分かる。

（実施形態２）
ＭＤＡで用いるアクション言語には、プラットフォームに依存しない記述が可能という特徴があり、通常のプログラミング言語よりも抽象度の高い記述が可能で、関連の多重度の値とは独立した記述や、ＶｅｃｔｏｒやＬｉｓｔや単一要素といったリンクの実装形態とは独立した記述が可能である。

アクション言語で用意されている配列操作に関する構文には、リンク先の要素走査の際に用いるＦｏｒｅａｃｈ構文、リンク先の要素を探索するＦｉｎｄ構文、リンク先の要素を指定の降順でソートするＳｏｒｔ構文、リンク先の要素数を取得するためのＣｏｕｎｔ構文、リンク先に要素を追加するＬｉｎｋ構文、リンク先の要素を取り除くＵｎｌｉｎｋ構文といったものがある。

Ｆｏｒｅａｃｈ構文による記述は、リンク先の全てのインスタンスに対して指定の処理をすることを表す記述であるが、この記述は、リンク先がない場合は何も処理をせず、リンク先が１つの場合は１つのインスタンスに対して処理を行うというように、多重度とは独立した記述が可能である。
Ｆｏｒｅａｃｈ＜要素への参照名＞＝＜リンク＞｛＜全ての要素に対してする処理＞}
Ｆｏｒｅａｃｈ＜要素への参照名＞＝＜リンク＞Ｗｈｅｒｅ（＜走査条件＞）｛
＜全ての要素に対してする処理＞｝

Ｆｉｎｄ構文による記述は、リンク先の全てのインスタンスの中から、配列の先頭インスタンスだとか、指定の条件式に一致するインスタンスだとかいった特定条件に一致するインスタンスを１つだけ探索することを表す記述であるが、この記述は、リンク先がない場合は何も処理をせず、リンク先が１つの場合はそのリンク先のインスタンスの参照を返すといった処理というように、多重度とは独立した記述が可能である。
＜要素への参照名＞＝Ｆｉｎｄ＜リンク＞；
＜要素への参照名＞＝Ｆｉｎｄ＜リンク＞Ｗｈｅｒｅ（＜探索条件＞）；

Ｓｏｒｔ構文による記述は、リンク先の全てのインスタンスを指定の降順に入れ替えることを表す記述であるが、これはリンク先に複数の要素があるときにのみ可能な処理であり、要素数が0や1のときは実行する必要の無い処理である。この記述は、リンク先の数が0もしくは1の場合には、何もしないというように、多重度とは独立した記述が可能である。

Ｃｏｕｎｔ構文による記述は、リンク先の全てのインスタンスの数を数える記述であるが、関連線が無い場合には常に０を返し、多重度が１の場合には常に１を返す。ケースによって入力される値が定数になったり、限定された値になるため、通らない条件節の除去といった最適化が可能である。
＜サイズ＞＝Ｃｏｕｎｔ（＜リンク＞）；

Ｌｉｎｋ構文による記述は、インスタンス間のリンク線を動的に追加することを表す記述である。仮に2回Ｌｉｎｋ構文が呼び出されているクラス関連線に対して、多重度を1と設定すると、多重度1のクラス関連線において、リンクの数が2つになってしまうので、不正な動作をしてしまうが、製品構成は静的に決定するものであるという前提条件下では製品構成を表すインスタンス間の関連に対してＬｉｎｋ構文を使う必要は無いので、これを使っていない箇所について、最適化の範疇としない。
Ｌｉｎｋ＜インスタンスＡ＞＜関連名＞＜インスタンスＢ＞

Ｕｎｌｉｎｋ構文による記述は、インスタンス間のリンク線を動的に削除することを表す記述である。Ｕｎｌｉｎｋ構文についても、Ｌｉｎｋ構文と同様、使う必要がないため、最適化の範疇としない。
Ｕｎｌｉｎｋ＜インスタンスＡ＞＜関連名＞＜インスタンスＢ＞

（実施形態３）
実施形態３では、汎用部品群情報２０４内のアクション記述から特定製品向け部品群情報２１０内のアクション記述に変換する実施形態を示す。
特定製品向け部品群情報２１０の作成は、汎用部品群情報２０４のアクション内をパターン検索して、パターンに一致した箇所を変換するといった手順で実施する。変換手順が記述されている部品変換ルール情報２０６には、パターン検索する情報の型と、検索した情報をどのように変換するかという手順が記述されている。

図１５に、部品変換ルール情報２０６の実施形態を示す。
１５０１は、変換するアクション構文を表しており、例ではリンクに対するＦｏｒｅａｃｈ構文を表している。$と$で囲まれた領域にはユーザ入力形式を指定している。ここで、instance:Instanceとあるのは、インスタンスを表すプログラム記述を表しており、また、link:Linkとあるのは、リンクを表すプログラム記述を表している。body:StatementBlockとあるのは、複数構文から構成されるアクション記述を表している。

１５０２は、リンクの多重度が"0"、すなわち、リンク先がない場合に、変換対象のアクションを"//none"という文字列に置き換えることを表している。target.transform()は、パターン検索で見つかった構文targetを、他の文字列に置き換える処理を表している。link.multiplyは得られたリンクを表す構文linkを解析して得られる多重度を表現したものである。

１５０３は、リンクの多重度が"1"の場合に、変換対象のアクションを、Ｆｉｎｄ構文に置き換えることを表している。
１５０４は、リンクの多重度が"0..1"の場合に、変換対象のアクションを、Ｆｉｎｄ構文と、ＮＵＬＬチェックの構文に置き換えることを表している。

図１６に、図１５で行なっている処理のフローチャートを示す。
ステップ１６０１からステップ１６０８では、リンクに対するＦｏｒｅａｃｈ構文全てについて処理をする。
ステップ１６０２において、クラス関連線の多重度が"０"の場合、ステップ１６０３に、そうでない場合、ステップ１６０４に進む。
ステップ１６０３において、指定のＦｏｒｅａｃｈ構文を除去する。

ステップ１６０４において、クラス関連線の多重度が"0..1"の場合、ステップ１６０５に、そうでない場合、ステップ１６０６に進む。
ステップ１６０５において、指定のＦｏｒｅａｃｈ構文をＦｉｎｄ構文とＮＵＬＬチェック構文に置き換える。
ステップ１６０６において、多重度が１の場合、ステップ１６０７に、そうでない場合、ステップ１６０８に進む。
ステップ１６０７において、指定のＦｏｒｅａｃｈ構文をＦｉｎｄ構文に置き換える。

図１７に、図１６のフローチャートにしたがってＦｏｒｅａｃｈ構文に対する変換処理を実行した場合に得られるアクション言語を示す。
１７０１は、多重度が不定の場合に得られるアクション記述である。元のアクション記述と同じ記述である。
１７０２は、多重度が１の場合に得られるアクション記述である。Ｆｏｒｅａｃｈ構文がＦｉｎｄ構文に置き換えられている。
１７０３は、多重度が0..1の場合に得られるアクション記述である。Ｆｏｒｅａｃｈ構文が、Ｆｉｎｄ構文とＮＵＬＬチェック構文で置き換えられている。
１７０４は、多重度が0の場合に得られるアクション記述である。Ｆｏｒｅａｃｈ構文が除去されている。

Ｆｏｒｅａｃｈ構文の最適化と同様、下記に、Ｆｉｎｄ構文を多重度に応じて最適化する手法を示す。
図１８に、Ｆｉｎｄ構文の変換のフローチャートを示す。
ステップ１８０１からステップ１８０４では、リンクに対するＦｉｎｄ構文全てについて処理をする。
ステップ１８０２において、関連の多重度が０の場合、ステップ１８０３に、そうでない場合、ステップ１８０４に進む。
ステップ１８０３において、Ｆｉｎｄ構文を、定数ＮＵＬＬに置き換える。
ステップ１８０４において、関連の多重度が0..1の場合、ステップ１８０５に、そうでない場合、ステップ１８０６に進む。

図１９に、図１８のフローチャートにしたがってＦｉｎｄ構文に対する変換処理を実行した場合に得られるアクション言語を示す。
１９０１は、多重度が不定の場合のアクション言語記述で、元のＦｉｎｄ構文のままである。
１９０２は、多重度が１の場合のアクション言語記述で、元のＦｉｎｄ構文のままである。
１９０３は、多重度が0..1の場合のアクション言語記述で、元のＦｉｎｄ構文のままである。
１９０４は、多重度が0の場合のアクション言語記述で、コードが除去されている。

本実施形態で示したアクション言語では、複数の要素からなる配列の先頭要素を取り出す処理も、単一の要素をアクセスする処理もＦｉｎｄ構文で記述するため、アクション言語記述からアクション言語記述への最適化では、これ以上の最適化が出来ない。言語形態によっては、参照型や実体型の区別などが可能であるため、これらを考慮に入れた最適化も可能である。

下記に、Ｓｏｒｔ構文を、多重度に応じて最適化する方法を示す。
図２０に、Ｓｏｒｔ構文最適化のフローチャートを示す。
ステップ２００１からステップ２００４では、リンクに対するＳｏｒｔ構文全てに対して処理をする。
ステップ２００２において、Ｓｏｒｔするリンク先の多重度が0か0..1か1のいずれかである場合は、ステップ２００３に、そうでなければ、ステップ２００４に進む。
ステップ２００３において、Ｓｏｒｔ構文を除去する。

図２１に、図２０のフローチャートにしたがってＳｏｒｔ構文に対する変換処理を実行した場合に得られるアクション言語を示す。
２１０１は多重度が不定の場合で、元のＳｏｒｔ構文のままである。
２１０２は多重度が1の場合で、Ｓｏｒｔ構文が除去されている。
２１０３は多重度が0..1の場合で、Ｓｏｒｔ構文が除去されている。
２１０４は多重度が0の場合で、Ｓｏｒｔ構文が除去されている。

Ｓｏｒｔ構文でソート処理をするのは、リンク先の要素数が２以上のときであり、要素数が２未満であることが保証される、多重度0、1、0..1のいずれかの場合は、Ｓｏｒｔ構文自体を除去することが可能である。

図２２に、多重度に依存するＩｆ構文の変換のフローチャートを示す。
ステップ２２０１からステップ２２０３は、アクション内の多重度に依存する全Ｉｆ構文に対する処理である。
ステップ２２０２において、Ｉｆ構文内の条件節を解析し、常にＦａｌｓｅとなるＩｆブロックを発見し、条件節ブロックと条件一致時に実行されるブロックを除去する。
ステップ２２０４からステップ２２０６も、アクション内の多重度に依存する全Ｉｆ構文に対する処理である。
ステップ２２０５において、Ｉｆ構文内の条件節を解析し、常にＴｒｕｅのＩｆブロックを発見し、条件節ブロックを除去する。

図２３に、図２２のフローチャートにしたがって多重度に依存するＩｆ構文に対する変換処理を実行した際に得られるアクション言語を示す。
２３０１は、多重度が不定の場合のアクション言語記述である。
２３０２は、多重度が1の場合のアクション言語記述であり、２３０１内のリンク先の個数が１個の時に実行される(2)ブロックのみの処理に置き換えられる。
２３０３は、多重度が0..1の場合のアクション言語記述であり、(1)、(2)のブロックのみの処理に置き換えられる。
２３０４は、多重度が0の場合のアクション言語記述であり、(1)のブロックのみの処理に置き換えられる。

図２６にＥｌｉｆ（言語によってはelse if）構文を含むＩｆ文への対応方法を示す。
２６０１はＥｌｉｆ構文を用いた記述であり、２６０２は等価な記述をＩＦ〜ＥＬＳＥ構文を階層化することで表現したものである。このように、Ｅｌｉｆ構文はＩｆ〜Ｅｌｓｅ構文に置き換えることが可能であるため、Ｉｆ〜Ｅｌｓｅ構文の階層化により、構造化言語で利用される条件分岐節は全て表現可能である。

なお、図２３のステップ２２０２とステップ２２０５を分離したのは、階層化されたＩｆ〜Ｅｌｓｅ構文に対応するためである。

（実施形態４）
実行されないＩｆブロックを除去したことにより、不要になる状態遷移図内のブロックを抽出する方法を示したフローチャートを図２４に示す。
ステップ２４０１において、Ｉｆブロックを除去したことで実行されなくなったイベントを探索し、除去する。
ステップ２４０２において、除去したイベントによって遷移する遷移線を除去する。
ステップ２４０３において、入場する遷移線を持たない状態が見つかった場合、該状態を除去する。また、該状態から外部に遷移する遷移線も除去する。
以上のステップを実行することにより、特定製品において不要な、イベント定義、状態、遷移線を除去することが可能となる。

図５の状態遷移図を例に、図２４のフローチャートの説明をする。
Ｉｆブロックを除去したことにより、イベントevClean()を投入するＧｅｎｅｒａｔｅ構文が、システム内から無くなった場合を考える。ステップ２４０１により、evClean()が発見され、evClean()が除去される。次に、ステップ２４０２により、図５の遷移線５０６と遷移線５０７が除去される。ステップ２４０３により、状態Ｃｌｅａｎｉｎｇ５０８は入場する遷移線を持たないため除去される。
図２５に、以上の処理をした後に得られる状態遷移図を示す。

本発明の一実施形態に係る複数製品対応装置の構成ブロック図である。本発明の一実施形態に係る複数製品対応装置のデータフロー図である。本発明の一実施形態における汎用部品群情報のうちドメイン図について説明した図である。発明の汎用部品群情報の一実施形態であるMDA設計図面のうち、クラス図について説明した図である。発明の汎用部品群情報の一実施形態であるMDA設計図面のうち、状態遷移図について説明した図である。発明の汎用部品群情報の一実施形態であるMDA設計図面のうち、アクション記述について説明した図である。発明の製品構成情報の一実施形態であるUML図面のうち、静的オブジェクト配置について説明した図である。本発明の一実施形態における、システム全体に関するフローチャートである。本発明の一実施形態における、構成部品関連抽出部に関するフローチャートである。本発明の一実施形態における、汎用部品群情報の例を示す図である。本発明の一実施形態における、製品構成情報の例を示す図である。本発明の一実施形態における、特定製品向け部品群情報の例を示す図である。本発明の一実施形態における、製品構成情報の例を示す図である。本発明の一実施形態における、特定製品向け部品群情報の例を示す図である。本発明の一実施形態における、部品変換ルール情報の例を示す図である。本発明の一実施形態における、多重度に応じてＦｏｒｅａｃｈ構文を変換する処理に関するフローチャートである。本発明の一実施形態における、Ｆｏｒｅａｃｈ構文変換後のアクション記述を示す図である。の本発明の一実施形態における、多重度に応じてＦｉｎｄ構文を変換する処理に関するフローチャートである。本発明の一実施形態における、Ｆｉｎｄ構文変換後のアクション記述を示す図である。本発明の一実施形態における、多重度に応じてＳｏｒｔ構文を変換する処理に関するフローチャートである。本発明の一実施形態における、Ｓｏｒｔ構文変換後のアクション記述を示す図である。本発明の一実施形態における、多重度に応じてＩｆ構文を変換する処理に関するフローチャートである。本発明の一実施形態における、Ｉｆ構文変換後のアクション記述を示す図である。本発明の一実施形態における、状態遷移図内の実行されない状態や遷移線やそれに付随するアクションの除去に関するフローチャートである。図５に示した状態遷移図を、図２４のフローチャートで最適化をした結果得られる状態遷移図である。Ｅｌｉｆ（言語によってはelse if）構文を含むＩｆ文への対応方法を示す図である。

符号の説明

１：ＣＰＵ
２：バス
３：ＲＯＭ
４：ＲＡＭ
４ａ：製品構成情報
４ｂ：汎用部品群情報
４ｃ：部品変換ルール情報
４ｄ：部品関連情報
４ｅ：特定製品向け部品群情報
４ｆ：製品用コード
４ｇ：製品プログラム
５：入力インターフェース
６：キーボード、ボタン、マウス、ダイアル
７：出力インターフェース
８ａ：ＣＲＴ、ＬＣＤ
８ｂ：プリンタ、プロッタ
９：外部記憶装置インターフェース
１０：ＨＤ、ＦＤ、ＣＤ−ＲＯＭ、ＭＤ、ＣＦ、・・・（ファイル）
２０１：製品構成情報解析部
２０２：製品構成情報
２０３：汎用部品群情報解析部
２０４：汎用部品群情報
２０５：部品変換ルール情報解析部
２０６：部品変換ルール情報
２０７：構成部品関連抽出部
２０８：部品関連情報
２０９：部品特化部
２１０：特定製品向け部品群情報
２１１：プログラム・コード生成部
２１２：製品用コード
２１３：コンパイル・リンク部
２１４：製品プログラム

Claims

インスタンスの配置、インスタンスの値及びインスタンス間の関連する製品の構成を解析する製品構成情報解析手段と、
汎用的なクラス定義の製品を構成する部品の基本的な型定義を解析する汎用部品群情報解析手段と、
前記製品構成情報解析手段より得られた製品の構成から、製品を構成する部品間の関連を抽出する構成部品関連抽出手段と、
前記構成部品関連抽出手段より得られた部品間の関連と、前記汎用部品群情報解析手段より得られた部品の基本的な型の定義とから、製品に特化した部品を生成する部品特化手段と、
前記部品特化手段より得られた製品に特化した部品を、前記製品構成情報解析手段より得られた製品の構成にしたがって組み合わせたものから、製品としてのプログラム・コードを自動生成するプログラム・コード生成手段と、
前記プログラム・コード生成手段より得られたプログラム・コードをコンパイル・リンクすることを特徴とするコンパイル・リンク手段と
を有することを特徴とするプログラム・コード生成装置。
前記汎用部品群情報解析手段より得られた部品の基本的な型の定義を製品に特化した部品に変換する手順が記述された部品変換ルールを解析する部品変換ルール情報解析手段を有し、
前記部品特化手段が、前記部品変換ルール情報解析手段より得られた部品変換ルールにしたがって製品に特化した部品を生成することを特徴とする請求項１に記載のプログラム・コード生成装置。
部品関連抽出手段は、クラス関連線の多重度及びクラス関連線の有無を抽出するものであり、
前記部品特化手段は、前記部品関連抽出手段より得られたクラス関連線の情報を、クラス図に設定することを特徴とする請求項１に記載のプログラム・コード生成装置。
部品特化手段は、多重度に応じて探索処理、ループ処理及びソート処理の実装形態を変換することを特徴とする請求項３に記載のプログラム・コード生成装置。
前記部品特化手段は、多重度に応じて不要な条件節ブロックを除去することを特徴とする請求項１に記載のプログラム・コード生成装置。
プログラム・コード生成手段は、前記部品特化手段により不要な条件節ブロックを除去されたことにより、利用されなくなったイベント、遷移線状態、及びこれらに付随するアクションを除去することを特徴とする請求項５に記載のプログラム・コード生成装置。