JP2010282418A - ソースコード自動生成プログラム，ソースコード自動生成装置 - Google Patents

Abstract

【課題】プログラム容量を低下させることが可能な、コンポーネント指向開発における開発支援ツールである統合ツールを提供する。
【解決手段】
Ｄインスタンス４４０が第一のインスタンス構成モデル４００に対応するコンフィグレーションファイルから削除されると、統合ツールは、Ｄインスタンス４４０の削除により非接続状態となった委譲接続用ポートであるｚ提供ポートを持つ親コンポーネントであるＣインスタンス４３０を特定する。さらに、ｚ提供ポートを介してＣインスタンス４３０に委譲接続されているＥインスタンス４５０を、不要なサブコンポーネントとして特定する。そして、統合ツールは、第一のインスタンス構成モデル４００におけるインスタンスのうち、Ｄ，Ｅインスタンスを除いたＡ〜Ｃインスタンスに対応するプロパティソースコードであるＩｎｓｔａｎｃｅＡ．ｃ５００〜ＩｎｓｔａｎｃｅＣ．ｃ５２０を生成する。
【選択図】図７

Description

コンポーネント指向開発における開発支援ツールであるソースコードの自動生成プログラム等に関する。

プログラム開発の生産性や品質を向上させることができる手法として、ソフトウェアプロダクトラインエンジニアリング（以後、ＳＰＬＥと記載）が知られている。ＳＰＬＥでは、共通性を有する一連の製品シリーズが定義され、再利用可能な共通のコア資産から個々の製品バリエーションのプログラム開発が行なわれる。ＳＰＬＥでは、このコア資産がコンポーネントとして表現され、コンポーネントを単位とした再利用開発が行なわれる。尚、このようなコンポーネントを単位とした再利用開発は、コンポーネント指向開発と呼ばれている。引用文献１には、コンポーネント指向開発について記載されている。

このコンポーネントは、一連の製品シリーズにおいて再利用可能なプログラム部品に対応している。各コンポーネントには、特定の形式を持つポートが設けられており、これらのコンポーネントは、対応する形式を持つポートを接続することにより互いに接続される。そして、製品のプログラムを開発する際には、プログラムに実装されるコンポーネントが選択されると共にこれらのコンポーネント同士が接続され、選択されたコンポーネント同士の接続関係等に基づき、製品のプログラムとして用いられるソースコードが自動生成される。

加藤、後藤「組込みシステムのプロダクトラインにおけるＭＤＡ」、組込みシステムシンポジウム２００７ 論文集、Ｐ．５４−Ｐ．６３

ところで、ＳＰＬＥにおける一連の製品シリーズには、高機能の製品から低機能の製品まで様々なバリエーションが存在することが想定されるが、低機能の製品の開発においては、製品コストの低下のためプログラム容量の低下が要求される。

本願発明は、上記課題に鑑みてなされたものであり、コンポーネント指向開発における開発支援ツールであるソースコード自動生成プログラムに関するものである。本願発明は、プログラム容量を低下させることが可能なソースコード自動生成プログラムを提供することを目的とする。

上記課題を解決するためになされた請求項１に記載のソースコード自動生成プログラムは、再利用可能に構成されたプログラム部品に対応しており、ポートを有するコンポーネントと、該コンポーネントに対応するソースコードを生成するためのテンプレートを有する生成用データとにアクセス可能に構成されている。尚、ポートとは、コンポーネントにおける情報のやり取り口となるものである。また、このコンポーネントは、ポート同士を接続することにより、互いに接続することができ、ソースコード自動生成プログラムは、所定のプログラムに実装するために選択された複数のコンポーネントと、これらのコンポーネント同士の接続関係とを示すコンフィグレーションデータ、及び、生成用データに基づき、ソースコードを生成する。

また、コンポーネントには、他のコンポーネントをサブコンポーネントとして有する親コンポーネントが存在し、サブコンポーネントと、該サブコンポーネントを有する親コンポーネントとは、これらのコンポーネントが有する専用ポートにより互いに接続可能に構成され、サブコンポーネントは、自身の専用ポートに接続された親コンポーネントの専用ポートが、他のコンポーネントに接続されることにより、他のコンポーネントに接続される。

そして、このようなサブコンポーネントのうち、親コンポーネントの専用ポートを介して他のコンポーネントに接続されていないサブコンポーネントは、不要であると考えることができる。

そこで、ソースコード自動生成プログラムは、コンフィグレーションデータが示す親コンポーネントのうち、専用ポートが他のコンポーネントに接続されていない親コンポーネントを特定し、該親コンポーネントにおける、該専用ポートに接続されている専用ポートを有するサブコンポーネントを、不要サブコンポーネントとして特定する特定ステップと、コンフィグレーションデータと、生成用データとに基づき、該コンフィグレーションデータが示すコンポーネントのうち、少なくとも不要サブコンポーネントを除いたコンポーネントに対応するソースコードを生成する生成ステップを、コンピュータに実行させる。

こうすることにより、ソースコード自動生成プログラムは、不要なサブコンポーネントに対応するソースコードが生成されてしまうことを防ぐことができ、プログラム容量を低下させることができる。

また、他の製品のプログラム開発に用いられたコンフィグレーションデータを流用して所定の製品のプログラム開発が行なわれる場合が想定される。
そこで、請求項２に記載のソースコード自動生成プログラムは、コンフィグレーションデータを取得する取得ステップと、取得ステップにて取得されたコンフィグレーションデータが示すコンポーネントのうち、削除対象となるコンポーネントである削除対象コンポーネントの選択をユーザから受け付ける選択受付ステップと、選択受付ステップにてユーザに選択された削除対象コンポーネントを、取得ステップにて取得されたコンフィグレーションデータから削除する削除対象コンポーネント削除ステップとをさらにコンピュータに実行させる。そして、特定ステップでは、削除対象コンポーネント削除ステップにおいて削除対象コンポーネントが削除されたコンフィグレーションデータについて、不要サブコンポーネントの特定を行う。

また、請求項３に記載のソースコード自動生成プログラムは、特定ステップにて特定された不要サブコンポーネントを、コンフィグレーションデータから削除する不要サブコンポーネント削除ステップをさらに有する。そして、生成ステップにおいて、不要サブコンポーネント削除ステップにて不要サブコンポーネントが削除されたコンフィグレーションデータを用いてソースコードを生成する。

このような構成を有することにより、不要なサブコンポーネントが削除されたコンフィグレーションデータを流用してプログラム開発を行うことができる。
また、コンフィグレーションデータを流用したプログラム開発では、ベースとなるコンフィグレーションデータに対し、追加機能に対応する新たなコンポーネントの追加や、不要となった機能に対応するコンポーネントの削除が行なわれる。ここで、コンポーネントの削除等が行われたコンフィグレーションデータが、その後、さらに他の製品のプログラム開発に流用される場合が考えられ、後のプログラム開発において、先のプログラム開発において不要となった機能が再び必要となる場合が想定される。つまり、コンフィグレーションデータからコンポーネントを削除しないほうが、このコンフィグレーションデータを流用して行なわれるプログラム開発における作業負担を低減させることができると考えられるのである。

ここで、請求項３では、コンフィグレーションデータからサブコンポーネントが削除される。しかし、親コンポーネントはコンフィグレーションデータに残されたままとなっているので、残された親コンポーネントに基づき、どのようなサブコンポーネントが削除されたかということを特定することができる。したがって、コンフィグレーションデータからサブコンポーネントを削除したとしても、削除したサブコンポーネントを容易に復活させることができ、このコンフィグレーションデータを流用して行なわれるプログラム開発における作業負担の増加を抑えることができる。

ところで、請求項１に記載のステップを実行可能なソースコード自動生成装置を構成してもよい。
すなわち、請求項４に記載されているように、ソースコード自動生成装置は、再利用可能に構成されたプログラム部品に対応しており、ポートを有するコンポーネントと、該コンポーネントに対応するソースコードを生成するためのテンプレートを有する生成用データとにアクセス可能に構成されていても良い。そして、コンポーネントは、ポート同士を接続することにより、互いに接続することができ、所定のプログラムに実装するために選択された複数のコンポーネントと、これらのコンポーネント同士の接続関係とを示すコンフィグレーションデータ、及び、生成用データに基づき、ソースコードを生成しても良い。

また、コンポーネントには、他のコンポーネントをサブコンポーネントとして有する親コンポーネントが存在し、サブコンポーネントと、該サブコンポーネントを有する親コンポーネントとは、これらのコンポーネントが有する専用ポートにより互いに接続可能に構成され、サブコンポーネントは、自身の専用ポートに接続された親コンポーネントの専用ポートが、他のコンポーネントに接続されることにより、他のコンポーネントに接続されても良い。

そして、ソースコード自動生成装置は、コンフィグレーションデータが示す親コンポーネントのうち、専用ポートが他のコンポーネントに接続されていない親コンポーネントを特定し、該親コンポーネントにおける、該専用ポートに接続されている専用ポートを有するサブコンポーネントを、不要サブコンポーネントとして特定する特定手段と、コンフィグレーションデータと、生成用データとに基づき、該コンフィグレーションデータが示すコンポーネントのうち、少なくとも不要サブコンポーネントを除いたコンポーネントに対応するソースコードを生成する生成手段を備えていても良い。

このような構成を有することにより、ソースコード自動生成装置は、請求項１に記載のソースコード自動生成プログラムにより動作するコンピュータと同様の効果を奏することができる。

ところで、既に述べたように、ポートとは、コンポーネントにおける情報のやり取り口となるものであるが、ポートが適切に接続されていない場合には、コンポーネントは必要な情報のやり取りを行うことができず、与えられた役割を果たすことができない。特に、コンフィグレーションデータを流用してプログラム開発を行う場合には、不要となったコンポーネントを削除することにより、このコンポーネントに接続されているコンポーネントにて必要な情報のやり取りができなくなり、与えられた最低限の役割を果たすことができなくなってしまうことが考えられる。

そこで、請求項５に記載のソースコード自動生成プログラムは、再利用可能に構成されたプログラム部品に対応しており、特定の形式を持つポートを有するコンポーネントと、該コンポーネントに対応するソースコードを生成するためのテンプレートを有する生成用データとにアクセス可能に構成されている。そして、コンポーネントは、対応する形式のポート同士を接続することにより、互いに接続することができ、コンポーネントと、これらのコンポーネント同士の接続関係と、生成用データとに基づき、ソースコードを生成する。また、生成用データには、コンポーネントについて、該コンポーネントの存在価値を生じさせることができる、該コンポーネントが有する所定のポートと、他のコンポーネントが有するポートとの接続状態である必要接続状態が定義されている。

このソースコード自動生成プログラムは、所定のプログラムに実装するために選択された複数のコンポーネントと、これらのコンポーネント同士の接続関係と、該接続に係るポートの形式とを示すコンフィグレーションデータを取得する取得ステップと、取得ステップにて取得されたコンフィグレーションデータが示すコンポーネントのうち、削除対象となるコンポーネントである削除対象コンポーネントの選択をユーザから受け付ける選択受付ステップとをコンピュータに実行させる。さらに、このソースコード自動生成プログラムは、生成用データに基づき、コンフィグレーションデータが示すコンポーネントのうち、必要接続状態でないコンポーネントを不要コンポーネントとして特定する特定ステップと、取得ステップにて取得されたコンフィグレーションデータが示すコンポーネントのうち、少なくとも削除対象コンポーネントと不要コンポーネントとを除いたコンポーネントと、これらのコンポーネント同士の接続関係と、生成用データとに基づき、これらのコンポーネントに対応するソースコードを生成する生成ステップと、をコンピュータに実行させる。

こうすることにより、コンフィグレーションデータを流用してプログラム開発を行なう場合において、削除対象となるコンポーネントに接続されているコンポーネントの中から、削除対象のコンポーネントの消滅により必要な情報のやり取りを行なうことができなくなり、与えられた最低限の役割を果たすことができず存在価値がなくなってしまうコンポーネントを不要コンポーネントとして特定することができる。そして、コンフィグレーションデータが示すコンポーネントのうち、不要コンポーネントを除いたコンポーネントに対応するソースコードが生成される。したがって、不要コンポーネントに対応するソースコードが生成されてしまうことを防ぐことができ、プログラム容量を低下させることができる。

また、請求項５に記載のソースコード自動生成プログラムによれば、不要コンポーネントをコンフィグレーションデータに残したままとすることができる。したがって、生成したコンフィグレーションデータを流用して行なわれる後のプログラム開発において、コンポーネントを追加するという作業が発生してしまうことを防ぐことができる。

また、不要コンポーネントに対応するソースコードが生成されないとなると、この不要コンポーネントに接続されているコンポーネントにおいても必要な情報のやり取りができなくなり、与えられた最低限の役割を果たすことができなくなってしまうことが考えられる。

そこで、請求項６に記載のソースコード自動生成プログラムは、特定ステップにおいて不要コンポーネントが特定されると、コンフィグレーションデータが示すコンポーネントのうち、該不要コンポーネントが有するポートと接続されることにより、必要接続状態が形成されるポートを有するコンポーネントを、新たに不要コンポーネントとして特定する不要コンポーネント再特定処理を実行する。

こうすることにより、削除対象となったコンポーネントに接続されている不要コンポーネントに接続されているコンポーネントの中から、不要コンポーネントの消滅により与えられた最低限の役割を果たすことができなくなってしまうコンポーネントを不要コンポーネントとして特定することができる。したがって、プログラム容量をより低減させることができる。

また、請求項７に記載のソースコード自動生成プログラムは、特定ステップにおいて、不要コンポーネント再特定処理にて新たに不要コンポーネントが特定されると、再度、新たに特定された不要コンポーネントについて不要コンポーネント再特定処理を実行する。

こうすることにより、不要コンポーネントが特定されるたびに、新たに特定された不要コンポーネントに接続されているコンポーネントの中から、不要コンポーネントが消滅することにより新たに不要となるコンポーネントを特定することができる。したがって、プログラム容量をより低減させることができる。

また、請求項８に記載されているように、ソースコード自動生成プログラムは、選択受付ステップにてユーザに選択された削除対象コンポーネントを、取得ステップにて取得されたコンフィグレーションデータから削除する削除対象コンポーネント削除ステップを、さらにコンピュータに実行させ、特定ステップにおいて、削除対象コンポーネント削除ステップにて、削除対象コンポーネントが削除されたコンフィグレーションデータについて、不要コンポーネントの特定を行っても良い。

こうすることにより、コンフィグレーションデータを流用してプログラム開発を行なう場合において、不要となった機能に対応するコンポーネントを、ユーザからの指示に応じてコンフィグレーションデータから削除することができる。

また、コンポーネントについての必要接続状態は、次のようにして定義されていても良い。
すなわち、請求項９に記載されているように、生成用データは、いずれかのコンポーネントに関連付けられており、関連付けられているコンポーネントについてテンプレートを有しているテンプレートデータを有しており、テンプレートデータには、関連付けられているコンポーネントについての必要接続状態が定義されていても良い。

こうすることにより、コンポーネントについての必要接続状態の定義を容易に参照することができる。
ところで、請求項５に記載のステップを実行可能なソースコード自動生成装置を構成してもよい。

すなわち、請求項１０に記載されているように、ソースコード自動生成装置は、再利用可能に構成されたプログラム部品に対応しており、特定の形式を持つポートを有するコンポーネントと、該コンポーネントに対応するソースコードを生成するためのテンプレートを有する生成用データとにアクセス可能に構成されていても良い。そして、コンポーネントは、対応する形式のポート同士を接続することにより、互いに接続することができ、コンポーネントと、これらのコンポーネント同士の接続関係と、生成用データとに基づき、ソースコードを生成しても良い。また、生成用データには、コンポーネントについて、該コンポーネントの存在価値を生じさせることができる、該コンポーネントが有する所定のポートと、他のコンポーネントが有するポートとの接続状態である必要接続状態が定義されていても良い。

そして、ソースコード自動生成装置は、所定のプログラムに実装するために選択された複数のコンポーネントと、これらのコンポーネント同士の接続関係と、該接続に係るポートの形式とを示すコンフィグレーションデータを取得する取得手段と、取得手段により取得されたコンフィグレーションデータが示すコンポーネントのうち、削除対象となるコンポーネントである削除対象コンポーネントの選択をユーザから受け付ける選択受付手段とを備えていても良い。また、ソースコード自動生成装置は、生成用データに基づき、コンフィグレーションデータが示すコンポーネントのうち、必要接続状態でないコンポーネントを不要コンポーネントとして特定する特定手段と、取得手段により取得されたコンフィグレーションデータが示すコンポーネントから、少なくとも削除対象コンポーネントと不要コンポーネントとを除いたコンポーネントと、これらのコンポーネント同士の接続関係と、生成用データとに基づき、これらのコンポーネントに対応するソースコードを生成する生成手段とを備えていても良い。

このような構成を有することにより、ソースコード自動生成装置は、請求項５に記載のソースコード自動生成プログラムにより動作するコンピュータと同様の効果を奏することができる。

ＰＣの構成を示すブロック図である。 コンポーネント指向開発における作業についての説明図である。 テンプレートの一例である。 プロパティソースコードの一例である。 第一のインスタンス構成モデルの説明図である。 インスタンス削除処理についてのフローチャートである。 サブコンポーネントの自動削除についての説明図である。 不要インスタンス特定処理についてのフローチャートである。 第二のインスタンス構成モデルの説明図である。

以下、本発明の実施形態について図面を用いて説明する。尚、本発明の実施の形態は、下記の実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態を採りうる。

［構成の説明］
まず、本実施形態に用いられる周知のパソコン（以後、ＰＣと記載）の構成について、図１のブロック図を用いて説明する。

ＰＣ１０は、種々の情報を記憶するためのＨＤＤ１１と、マウスやキーボード等により構成され、開発者からの各種入力を受け付ける入力部１２と、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏ等から構成され、ＰＣ１０の各部位を統括的に制御する制御部１３と、液晶ディスプレイ等を備え、開発者に対して視覚的に情報を伝達する表示部１４とを有している。尚、ＰＣ１０には、コンポーネント指向開発に用いられる開発支援ツールである統合ツール（詳細については後述する）がインストールされており、ＨＤＤ１１には、統合ツールのプログラムが記憶されている。

［動作の説明］
（１）コンポーネント指向開発について
既に述べたように、周知技術であるコンポーネント指向開発は、プログラム部品をモデル化したものであるコンポーネントを単位とした再利用開発である。このコンポーネントには、コンポーネント間の情報のやり取り口となるポートを有しており、コンポーネントは、自身が有するポート同士が接続されることにより互いに接続される。このポートは、情報をやり取りする際の規格となる特定の型を有していると共に、提供ポートと使用ポートとに分類され、型が適合する提供ポートを使用ポートとを接続することができる。コンポーネント指向開発では、周知のＰＣにインストールされた開発支援ツールにより、製品のプログラムとして実装するために選択されたコンポーネントと、コンポーネント同士の接続関係等に基づき、この製品のプログラムとして用いられるソースコードが自動生成される。本実施形態では、この開発支援ツールとして統合ツール（詳細については後述する）が用いられる。

また、コンポーネントには、他のコンポーネントをサブコンポーネントとして一部に有している親コンポーネントが存在し、サブコンポーネントが有する特定のポートは、親コンポーネントが有する特定のポートに委譲接続することができる。この委譲接続が可能なポートを、委譲接続用ポートと記載する。サブコンポーネントは、委譲接続先の親コンポーネントの委譲接続用ポートが、他のコンポーネントが有するポートに接続されることにより、この他のコンポーネントに接続される。尚、委譲接続用ポートもまた提供ポートと使用ポートとに分類され、委譲接続の際には、提供ポート同士、或いは使用ポート同士が接続される。

尚、コンポーネント同士はポートを介して情報のやり取りを行なうが、本実施形態では、この情報のやり取りは、提供ポート側で定義された関数が、使用ポート側のコンポーネントに対応するプログラムからコールされることにより実現される。

また、コンポーネントには、テンプレート変数を設定することができる。本実施形態では、後述する統合ツールは、このテンプレート変数に応じてコンポーネントに対応するプログラム部品において用いられる閾値等を設定する。

（２）コンポーネント指向開発における作業について
次に、コンポーネント指向開発における作業について、図２に記載の説明図を用いて説明する。コンポーネント指向開発は、コア資産開発工程１００と製品開発工程２００とに分けることができ、製品開発工程２００では、コア資産開発工程１００にて生成されたコア資産１５０を用いて製品のプログラム開発が行なわれる。尚、コア資産開発工程１００と製品開発工程２００とは、統合ツールを用いて行なわれる。

（２−１）コア資産開発工程について
コア資産開発工程１００とは、共通性を有する一連の製品シリーズにおいて再利用可能な共通のコア資産１５０を開発する工程である。コア資産開発工程１００では、制御仕様書１３０に基づき要求分析・設計工程１１０が実施され、ユースケースやクラス図等のＵＭＬ設計モデル１４０が作成される。そして、このＵＭＬ設計モデル１４０に基づき実装工程１２０が実施され、コア資産１５０が生成される。このコア資産１５０には、一連の製品シリーズにおいて再利用可能なプログラム部品をモデル化したものであり、自身が有するポート等が定義されているコンポーネントモデル１５１と、この製品シリーズにおいて利用されるライブラリ関数が定義されているライブラリソースコード１５２と、いずれかのコンポーネントモデル１５１に１対１で関連付けられており、関連付けられているコンポーネントモデル１５１に対応するプログラム部品のプロパティソースコード（詳細については後述する）を生成するためのテンプレートファイル１５３が生成される。

ここで、テンプレートファイル１５３について詳しく説明する。テンプレートファイル１５３には、自身が関連付けられているコンポーネントモデル１５１に対応するプロパティソースコードを生成するためのテンプレートが定義されており、統合ツールは、テンプレートの記述に基づきプロパティソースコードを生成する。テンプレートは、対応するプログラム部品についてのＣ言語のソースコードが記述されており、これらの記述がプロパティソースコードの一部としてそのまま用いられる不変部分と、自身が関連付けられているインスタンス（後述する製品開発工程２００において製品のプログラムに実装するために開発者に選択され、実体化したコンポーネントモデル１５１のこと）における他のインスタンスとの接続関係や、この接続に係るポートの型や、テンプレート変数等に応じて変化する可変部分を有している。この可変部分には、ＪＡＶＡ（登録商標）言語により、上記接続関係等に応じてどのようなソースコードが生成されるかが記述されており、統合ツールは、この記述を解釈してプログラム部品についてのソースコードを生成する。尚、図３には、一例としてテンプレート３００が記載されており、“＜％”，“％＞”で挟まれている記述が可変部分に相当し、他の記述が不変部分に相当する。

また、テンプレートファイル１５３には、自身が関連付けられているコンポーネントモデルに基づくインスタンスについて、このインスタンスの存在価値を生じさせることができる、他のインスタンスが有するポートと当該インスタンスが有するポートとの接続状態である必要接続状態が、ＪＡＶＡ（登録商標）言語にて定義されている。この必要接続状態については、後述する。

（２−２）製品開発工程について
次に、製品開発工程２００について、図２の説明図を用いて説明する。製品開発工程２００とは、コア資産１５０を利用して一連の製品シリーズにおける所定の製品のプログラムを作成する工程である。製品開発工程２００では、車両仕様書２４０に基づき、このプログラムに実装するプログラム部品に対応するコンポーネントモデル１５１を選択してインスタンスとし、各インスタンスのポート同士を接続する製品構成設定工程２１０という工程が実施される。製品構成設定工程２１０では、統合ツールにより、選択されたインスタンスと、インスタンス同士の接続関係と、この接続に係るポートの型等を示すコンフィグレーションファイル２６０が生成される。

また、製品構成設定工程２１０に続いて、テンプレート変数の設定を受け付け、コンフィグレーションファイル２６０とテンプレート変数とに基づき、コンフィグレーションファイル２６０が示すインスタンスに対応するプロパティソースコード２７０を生成するプロパティファイル生成工程２２０という工程が実施される。プロパティファイル生成工程２２０では、統合ツールは、それぞれのインスタンスに対応するテンプレートファイル１５３に基づきプロパティソースコード２７０を生成する。具体的には、統合ツールは、テンプレートファイル１５３におけるテンプレートの可変部分の記述を解釈し、インスタンスに対応するコンポーネントモデル１５１や、インスタンス同士の接続関係や、この接続に係るポートの形式や、テンプレート変数等に応じて、ソースコードを生成する。そして、生成したソースコードと、テンプレートの不変部分におけるソースコード等により、プロパティソースコード２７０を生成する。尚、図４には、一例として、図３におけるテンプレート３００に対応するインスタンスについてのプロパティソースコード３５０が記載されている。尚、本実施形態では、Ｃ言語によりプロパティソースコードが記述される。

続いて、実行ファイル２８０を生成するビルド工程２３０が実施される。ビルド工程２３０では、統合ツールは、プロパティソースコード２７０と、インスタンスに対応するコンポーネントモデル１５１と、ライブラリソースコード１５２とに基づき、実行ファイル２８０を生成する。

（２−３）インスタンス構成モデルについて
ところで、コンフィグレーションファイル２６０は、プログラムに実装するために選択されたインスタンスと、インスタンス同士の接続関係と、この接続に係るポートの型等を示すが、この接続関係等を示すモデルをインスタンス構成モデルと記載する。図５に記載の説明図には、一例として、Ａ〜Ｅインスタンスについての第一のインスタンス構成モデル４００が記載されている。

尚、Ａインスタンス４１０及びＢインスタンス４２０は機能１に、Ｄインスタンス４４０は機能２に、Ｃインスタンス４３０、及びＣインスタンス４３０のサブコンポーネントとなっているＥインスタンス４５０は機能３に対応している。尚、親コンポーネントとなっているインスタンスを親インスタンス、サブコンポーネントとなっているインスタンスをサブインスタンスとも記載する。

また、Ａインスタンス４１０はＶ型のｖ提供ポート，Ｗ型のｗ提供ポートを、Ｂインスタンス４２０はＷ型のｗ使用ポート，Ｘ型のｘ提供ポートを、Ｃインスタンス４３０はＸ型のｘ使用ポート，Ｙ型のｙ使用ポート，Ｚ型のｚ提供ポートを、Ｄインスタンス４４０はＶ型のｖ使用ポート，Ｚ型のｚ使用ポートを、Ｅインスタンス４５０は、Ｙ型のｙ提供ポート，Ｚ型のｚ提供ポートを、それぞれ有している。尚、Ｄインスタンス４４０が有するｚ提供ポートと、Ｅインスタンス４５０が有するｚ提供ポートとは、委譲接続用ポートとなっている。これらのポートの接続関係は、以下のようになっている。

すなわち、Ａインスタンス４１０におけるｖ提供ポートはＤインスタンス４４０におけるｖ使用ポートに、ｗ提供ポートはＢインスタンス４２０におけるｗ使用ポートに接続されている。また、Ｂインスタンス４２０におけるｘ提供ポートはＣインスタンス４３０におけるｘ使用ポートに接続される。また、Ｃインスタンス４３０におけるｙ使用ポートは、Ｃインスタンス４３０が有するサブインスタンスであるＥインスタンス４５０におけるｙ提供ポートに接続されている。また、Ｃインスタンス４３０におけるｚ提供ポートとＥインスタンス４５０におけるｚ提供ポートとは委譲接続されており、Ｃインスタンス４３０におけるｚ提供ポートは、Ｄインスタンス４４０におけるｚ使用ポートに接続されている。

また、統合ツールにより、Ａインスタンス４１０に対応するプロパティソースコードとしてＩｎｓｔａｎｃｅＡ．ｃ５００が、Ｂインスタンス４２０に対応するプロパティソースコードとしてＩｎｓｔａｎｃｅＢ．ｃ５１０が、Ｃインスタンス４３０に対応するプロパティソースコードとしてＩｎｓｔａｎｃｅＣ．ｃ５２０が、Ｄインスタンス４４０に対応するプロパティソースコードとしてＩｎｓｔａｎｃｅＤ．ｃ５３０が、Ｅインスタンス４５０に対応するプロパティソースコードとしてＩｎｓｔａｎｃｅＥ．ｃ５４０が、それぞれ生成される。

（３）コンフィグレーションファイルが流用される場合について
（３−１）インスタンス削除処理について
ところで、図２に記載されているように、ある製品について作成されたコンフィグレーションファイルであるベースコンフィグレーションファイル２５０に基づき、類似製品についての製品構成設定工程２１０が実施される場合がある。このような場合には、製品構成設定工程２１０において、統合ツールを介して、ベースコンフィグレーションファイル２５０に対し、不要となる機能に対応するインスタンスの削除や、新たに追加する機能に対応するインスタンスの追加等が行われる。ここでは、ベースコンフィグレーションファイル２５０から不要なインスタンスの削除を行う場合に統合ツールにおいて行なわれるインスタンス削除処理について、図６に記載のフローチャートを用いて説明する。本処理は、製品構成設定工程２１０において、統合ツールがインストールされたＰＣ１０が、ベースコンフィグレーションファイル２５０から不要なインスタンスを削除する旨の指示を受け付けた際に実行する処理である。

ＰＣ１０の制御部１３は、例えば、ＨＤＤ１１や、図示しないＵＳＢ Ｉ／Ｆを介してＵＳＢメモリからベースコンフィグレーションファイル２５０を読み込むと（Ｓ６０５）、開発者から、入力部１２を介して、このベースコンフィグレーションファイル２５０から削除するインスタンスの選択を受け付ける（Ｓ６１０）。そして、選択されたインスタンスを、ベースコンフィグレーションファイル２５０から削除する（Ｓ６１５）。

続いて、Ｓ６２０では、制御部１３は、ベースコンフィグレーションファイル２５０が示すインスタンスの中から、委譲接続用ポートが他のインスタンスに接続されていない親インスタンスを特定し、さらに、特定した非接続状態の委譲接続用ポートを介して親インスタンスに委譲接続されているサブインスタンスを不要なサブインスタンスとして特定する。そして、特定した不要なサブインスタンスを、ベースコンフィグレーションファイル２５０から削除し、本処理を終了する（Ｓ６２５）。

（３−２）インスタンス削除処理の具体例について
ここで、インスタンス削除処理において、統合ツールにより不要なサブインスタンスが削除される処理の具体例について、図７に記載されている説明図を用いて説明する。

ベースコンフィグレーションファイル２５０が第一のインスタンス構成モデル４００に対応しており、Ｓ６１０にて、削除対象としてＤインスタンス４４０が選択され、Ｄインスタンス４４０がベースコンフィグレーションファイル２５０から削除されたと仮定する。このとき、Ｓ６２０では、Ｄインスタンス４４０の削除により非接続状態となった委譲接続用ポートであるｚ提供ポートを持つ親コンポーネントであるＣインスタンス４３０が特定され、さらに、ｚ提供ポートを介してＣインスタンス４３０に委譲接続しているサブコンポーネントであるＥインスタンス４５０が特定される。そして、Ｓ６２５にて、Ｅインスタンス４５０が削除される。これにより、この製品構成設定工程２１０に続いて行なわれるプロパティファイル生成工程２２０では、統合ツールにより、ＩｎｓｔａｎｃｅＡ．ｃ５００，ＩｎｓｔａｎｃｅＢ．ｃ５１０，ＩｎｓｔａｎｃｅＣ．ｃ５２０のみが生成される。

（３−３）不要インスタンス特定処理について
また、ベースコンフィグレーションファイル２５０を用いて製品開発工程２００が行なわれる場合には、プロパティファイル生成工程２２０では、インスタンス削除処理にてインスタンスが削除されたことにより不要となったインスタンスを特定する不要インスタンス特定処理が行なわれる。本処理は、統合ツールがインストールされたＰＣ１０が、プロパティファイル生成工程２２０において開発者からの指示に応じて実行する処理である。

Ｓ７０５では、ＰＣ１０の制御部１３は、ベースコンフィグレーションファイル２５０が示すインスタンスについて、テンプレートファイル１５３に基づき、必要接続状態（詳細については後述）となっているかどうかを判定する。そして、必要接続状態となっていないインスタンスを不要インスタンスとして特定し、Ｓ７１０に処理を移行する。

Ｓ７１０では、制御部１３は、本ステップの直前に行なわれたＳ７０５或いはＳ７２０にて不要インスタンスが特定されたかどうかを判定する。そして、不要インスタンスが特定されなかった場合には（Ｓ７１０：Ｎｏ）、制御部１３は、Ｓ７２５に処理を移行し、不要インスタンスが特定された場合には（Ｓ７１０：Ｙｅｓ）、Ｓ７１５に処理を移行する。

Ｓ７１５では、制御部１３は、ベースコンフィグレーションファイル２５０が示すインスタンスの中から、本ステップに先立ち行なわれたＳ７０５、或いはＳ７２０にて新たに特定された不要インスタンスに接続されているインスタンスを判定対象として特定する。そして、判定対象とされたインスタンスについて、このインスタンスに対応するコンポーネントモデル１５１に関連付けられているテンプレートファイル１５３に基づき、新たに特定された不要インスタンスが消滅した場合に必要接続状態となるかどうかを判定する。そして、必要接続状態とならないインスタンスを、不要インスタンスとして新たに特定し（Ｓ７２０）、Ｓ７１０に処理を移行する。

Ｓ７１０にて不要インスタンスが特定されなかった場合に移行するＳ７２５では、制御部１３は、コンフィグレーションファイル２６０が示すインスタンスから不要インスタンスを除いたインスタンスに対応するプロパティソースコードを生成し、本処理を終了する。

（３−４）不要インスタンス特定処理の具体例について
ここで、不要インスタンスを特定する処理の具体例について、図９に記載されている第二のインスタンス構成モデル８００を用いて詳しく説明する。

（３−４−１）第二のインスタンス構成モデルについて
まず、第二のインスタンス構成モデル８００について説明する。第二のインスタンス構成モデル８００は、ｃｏｎｄｉｔｉｏｎＡ８２０，ｃｏｎｄｉｔｉｏｎＢ８１０，ｉｎｖｏｋｅｒ８３０，ｓｗＥｖｅｎｔ８４０，ｅｖｅｎｔＦｉｌｔｅｒ８５０，ａｐｐ８６０というインスタンスを示している。これらのインスタンスは、以下のようなポートを有している。

すなわち、ｃｏｎｄｉｔｉｏｎＡ８２０は、Ｃｏｎｄｉｔｉｏｎ型のｃｏｎｄｉｔｉｏｎ提供ポートと、Ｈｏｏｋ型のｈｏｏｋ提供ポートを有している。また、ｃｏｎｄｉｔｉｏｎＢ８１０は、Ｃｏｎｄｉｔｉｏｎ型のｃｏｎｄｉｔｉｏｎ提供ポートを有している。また、ｉｎｖｏｋｅｒ８３０は、Ｈｏｏｋ型のｈｏｏｋ使用ポートを有している。また、ｓｗＥｖｅｎｔ８４０は、ＥｖｅｎｔＬｉｓｔｅｎｅｒ型のｅｖｅｎｔＬｉｓｔｅｎｅｒ使用ポートを有している。また、ｅｖｅｎｔＦｉｌｔｅｒ８５０は、ＥｖｅｎｔＬｉｓｔｅｎｅｒ型のｅｖｅｎｔＬｉｓｔｅｎｅｒ提供ポートと、Ｃｏｎｄｉｔｉｏｎ型のｃｏｎｄｉｔｉｏｎｓ使用ポートと、ＦｉｌｔｅｒｅｄＬｉｓｔｅｎｅｒ型のｆｉｌｔｅｒｅｄＬｉｓｔｅｎｅｒ使用ポートとを有している。また、ａｐｐ８６０は、ＦｉｌｔｅｒｅｄＬｉｓｔｅｎｅｒ型のｆｉｌｔｅｒｅｄＬｉｓｔｅｎｅｒ提供ポートを有している。

また、これらのポートは、次のような接続状態を有している。すなわち、ｃｏｎｄｉｔｉｏｎＡ８２０のｈｏｏｋ提供ポートは、ｉｎｖｏｋｅｒ８３０のｈｏｏｋ使用ポートと接続されている。また、ｃｏｎｄｉｔｉｏｎＡ８２０のｃｏｎｄｉｔｉｏｎ提供ポートは、ｅｖｅｎｔＦｉｌｔｅｒ８５０のｃｏｎｄｉｔｉｏｎｓ使用ポートと接続されている。また、ｃｏｎｄｉｔｉｏｎＢ８１０のｃｏｎｄｉｔｉｏｎ提供ポートは、ｅｖｅｎｔＦｉｌｔｅｒ８５０のｃｏｎｄｉｔｉｏｎｓ使用ポートと接続されている。また、ｓｗＥｖｅｎｔ８４０のｅｖｅｎｔＬｉｓｔｅｎｅｒ使用ポートは、ｅｖｅｎｔＦｉｌｔｅｒ８５０のｅｖｅｎｔＬｉｓｔｅｎｅｒ提供ポートと接続されている。また、ｅｖｅｎｔＦｉｌｔｅｒ８５０のｆｉｌｔｅｒｅｄＬｉｓｔｅｎｅｒ使用ポートは、ａｐｐ８６０のｆｉｌｔｅｒｅｄＬｉｓｔｅｎｅｒ提供ポートと接続されている。尚、これらの接続状態は、図９において点線で示されている。

（３−４−２）各インスタンスの振る舞いについて
続いて、第二のインスタンス構成モデル８００におけるそれぞれのインスタンスの振る舞いについて、簡単に説明する。尚、互いに接続されている使用ポートと提供ポートとをインターフェースとも記載し、互いに接続されている使用ポートと提供ポートの名称をインターフェースの名称とする。

ｃｏｎｄｉｔｉｏｎＡ８２０は、Ｈｏｏｋインターフェースを介してｉｎｖｏｋｅｒ８３０から通知を受けると、一定の期間にわたって条件が成立する。そして、ｃｏｎｄｉｔｉｏｎＡ８２０は、Ｃｏｎｄｉｔｉｏｎインターフェースを介してｅｖｅｎｔＦｉｌｔｅｒ８５０に、条件成立或いは不成立を通知する。

また、ｃｏｎｄｉｔｉｏｎＢ８１０に関しても同様に、図示しないインスタンスから通知を受けると、一定の期間にわたって条件が成立する。そして、Ｃｏｎｄｉｔｉｏｎインターフェースを介してｅｖｅｎｔＦｉｌｔｅｒ８５０に、条件成立或いは不成立を通知する。

また、ｓｗＥｖｅｎｔ８４０は、ＥｖｅｎｔＬｉｓｔｅｎｅｒインターフェースを介してｅｖｅｎｔＦｉｌｔｅｒ８５０に対しイベントの発生を通知する。この通知を受け取ったｅｖｅｎｔＦｉｌｔｅｒ８５０は、ｃｏｎｄｉｔｉｏｎＡ８２０またはｃｏｎｄｉｔｉｏｎＢ８１０にて条件が成立している場合に限り、ＦｉｌｔｅｒｅｄＬｉｓｔｅｎｅｒインターフェースを介してａｐｐ８６０に対し、イベントの発生を通知する。

そして、ａｐｐ８６０は、ｅｖｅｎｔＦｉｌｔｅｒ８５０から受け取ったイベント発生の通知に応じて処理を行う。
（３−４−３）必要接続状態について
続いて、第二のインスタンス構成モデル８００におけるインスタンスについて定義されている必要接続状態について説明する。必要接続状態は、インスタンスに対応するテンプレートファイル１５３に定義されており、コア資産開発工程１００において開発者により定義されるものである。既に述べたように、必要接続状態とは、インスタンスの存在価値を生じさせることができる他のインスタンスが有するポートとの接続状態である。より詳しく説明すると、必要接続状態とは、対応するインスタンス、或いはこのインスタンスに接続されているインスタンスが、与えられた最低限の役割を果たすために必要不可欠となる情報のやり取り口となるポート接続がなされている状態であると言うこともできる。尚、第二のインスタンス構成モデル８００におけるインスタンスに関しては、ｃｏｎｄｉｔｉｏｎＡ８２０とｅｖｅｎｔＦｉｌｔｅｒ８５０について必要接続状態が定義されており、これら以外のインスタンスについては必要接続状態が定義されていない。

まず、ｃｏｎｄｉｔｉｏｎＡ８２０について、このインスタンスに対応するテンプレートファイル１５３には、必要接続状態として、「ｃｏｎｄｉｔｉｏｎ提供ポート及びｈｏｏｋ提供ポートが接続されていること」が定義されている。なぜならば、ＨｏｏｋインターフェースやＣｏｎｄｉｔｉｏｎインターフェースが存在しなければ、ｅｖｅｎｔＦｉｌｔｅｒ８５０に条件成立或いは不成立を通知することができず、ｃｏｎｄｉｔｉｏｎＡ８２０の存在価値が無くなるためである。

次に、ｅｖｅｎｔＦｉｌｔｅｒ８５０について、このインスタンスに対応するテンプレートファイル１５３には、必要接続状態として、「ｅｖｅｎｔＬｉｓｔｅｎｅｒ提供ポート及びｆｉｌｔｅｒｅｄＬｉｓｔｅｎｅｒ使用ポートが接続されていること」が定義されている。ＥｖｅｎｔＬｉｓｔｅｎｅｒインターフェースやＦｉｌｔｅｒｅｄＬｉｓｔｅｎｅｒインターフェースが存在しなければ、ａｐｐ８６０に対しイベントの発生を通知することができず、ｅｖｅｎｔＦｉｌｔｅｒ８５０の存在価値が無くなるためである。

（３−４−４）具体例について
次に、ベースコンフィグレーションファイル２５０が第二のインスタンス構成モデル８００に対応している場合に行われる不要インスタンス特定処理について説明する。

不要インスタンス特定処理に先立ち行なわれたインスタンス削除処理にて、ｉｎｖｏｋｅｒ８３０がベースコンフィグレーションファイル２５０から削除されたと仮定する。このとき、ｃｏｎｄｉｔｉｏｎＡ８２０のｈｏｏｋ提供ポートは非接続状態となり、ｃｏｎｄｉｔｉｏｎＡ８２０は、Ｓ７０５にて不要インスタンスとして特定される。

そして、Ｓ７１５，Ｓ７２０では、ｃｏｎｄｉｔｉｏｎＡ８２０に接続されているｅｖｅｎｔＦｉｌｔｅｒ８５０について、必要接続状態となっているかどうか判定が行われる。ここで、ｅｖｅｎｔＦｉｌｔｅｒ８５０は、ｃｏｎｄｉｔｉｏｎＡ８２０が消滅したとしても必要接続状態となるので、Ｓ７２０では新たな不要コンポーネントは特定されず、処理が終了する。

また、インスタンス削除処理にて、ａｐｐ８６０がベースコンフィグレーションファイル２５０から削除されたと仮定する。このとき、ｅｖｅｎｔＦｉｌｔｅｒ８５０のｆｉｌｔｅｒｅｄＬｉｓｔｅｎｅｒ使用ポートは非接続状態となり、ｅｖｅｎｔＦｉｌｔｅｒ８５０は、Ｓ７０５にて不要インスタンスとして特定される。

そして、Ｓ７１５，Ｓ７２０では、ｅｖｅｎｔＦｉｌｔｅｒ８５０に接続されているｃｏｎｄｉｔｉｏｎＡ８２０，ｃｏｎｄｉｔｉｏｎＢ８１０，ｓｗＥｖｅｎｔ８４０について判定が行われる。ここで、ｅｖｅｎｔＦｉｌｔｅｒ８５０が消滅することでｃｏｎｄｉｔｉｏｎ提供ポートは非接続状態となるため、ｃｏｎｄｉｔｉｏｎＡ８２０は必要接続状態でなくなり、ｃｏｎｄｉｔｉｏｎＡ８２０は不要インスタンスとして特定される。尚、ｃｏｎｄｉｔｉｏｎＢ８１０，ｓｗＥｖｅｎｔ８４０については必要接続状態が定義されておらず、不要インスタンスとして特定されることはない。

そして、ｃｏｎｄｉｔｉｏｎＡ８２０が不要インスタンスとして特定されることにより再度行なわれるＳ７１５，Ｓ７２０では、ｃｏｎｄｉｔｉｏｎＡ８２０に接続されているｉｎｖｏｋｅｒ８３０について判定が行われる。しかし、ｉｎｖｏｋｅｒ８３０についての必要接続状態は定義されておらず、不要インスタンスはと特定されない。

また、インスタンス削除処理にて、ｓｗＥｖｅｎｔ８４０がベースコンフィグレーションファイル２５０から削除されたと仮定する。このとき、ａｐｐ８６０が選択された場合と同様にして、ｅｖｅｎｔＦｉｌｔｅｒ８５０，ｃｏｎｄｉｔｉｏｎＡ８２０が不要インスタンスとして特定される。

［効果］
本実施形態の統合ツールによれば、ベースコンフィグレーションファイルから削除するインスタンスの選択を受け付けた後、委譲接続用ポートが非接続状態となっている親インスタンスが特定され、さらに、非接続状態となっている委譲接続用ポートに委譲接続されているサブインスタンスが特定される（Ｓ６２０）。そして、特定されたサブインスタンスが、ベースコンフィグレーションファイルから削除される。したがって、不要なサブインスタンスに対応するプロパティソースコードが生成されてしまうことを防ぐことができ、プログラム容量を低下させることができる。

また、コンフィグレーションファイルを流用してプログラム開発を行う場合には、先のプログラム開発において不要となった機能が再び必要となる場合が想定される。したがって、インスタンスをコンフィグレーションファイルから削除しないほうが、このコンフィグレーションファイルを流用して行なわれる後のプログラム開発における作業負担を低減させることができると考えられる。

ここで、本実施形態の統合ツールによれば、サブインスタンスがコンフィグレーションファイルから削除されても、その親インスタンスはコンフィグレーションファイルに残されたままとなる。したがって、統合ツールは、コンフィグレーションファイルに残された親インスタンスに基づき、どのようなサブインスタンスが削除されたかということを特定することができる。このため、コンフィグレーションファイルからサブインスタンスを削除したとしても、統合ツールは削除したサブインスタンスを自動的に復活させることもでき、このコンフィグレーションファイルを流用して行なわれるプログラム開発における作業負担の増加を抑えることができる。

また、本実施形態の統合ツールによれば、開発者の指示によりインスタンスが削除された後のコンフィグレーションファイルにおけるインスタンスのうち、必要接続状態となっていないインスタンスが不要インスタンスとして特定される（Ｓ７０５）。そして、Ｓ７０５で不要インスタンスが特定されると、特定された不要インスタンスが消滅した場合に必要接続状態とならないインスタンスが新たに不要インスタンスとして特定される（Ｓ７２０）。さらに、Ｓ７２０で不要インスタンスが特定されると、再度、同様にして不要インスタンスの特定が行われ（Ｓ７２０）、不要インスタンスが特定されなくなるまで、Ｓ７２０が繰り返し行われる。そして、コンフィグレーションファイルにおけるインスタンスのうち、不要インスタンスを除いたインスタンスに対応するプロパティソースコードが生成されるのである。したがって、不要なインスタンスに対応するプロパティソースコードが生成されてしまうことを防ぐことができ、プログラム容量を低下させることができる。

また、不要インスタンスは、コンフィグレーションファイルに残されたままとなる。したがって、生成したコンフィグレーションファイルを流用して行なわれる後のプログラム開発においてインスタンスを追加するという作業が発生してしまうことを防ぐことができる。

［他の実施形態］
（１）本実施形態では、インスタンス削除処理において、委譲接続先のポートが接続されていないサブインスタンスをコンフィグレーションファイルから削除している。しかし、統合ツールは、このサブインスタンスを削除することなく、単に、このサブインスタンスを不要なものとして認識しておき、プロパティファイル生成工程２２０にて、このサブインスタンスに対応するプロパティソースコードの生成を抑制しても良い。このような構成を有する場合であっても、同様の効果を得ることができる。

（２）本実施形態では、テンプレートファイルにおけるテンプレートの不変部分の記述や必要接続状態の定義の記述にはＪＡＶＡ（登録商標）言語が用いられているが、言うまでも無いことではあるが、他のプログラム言語が用いられても良い。また、言うまでも無いことではあるが、本実施形態では、プロパティソースコードの記述にはＣ言語が用いられているが、他のプログラム言語が用いられても良い。このような構成を有する場合であっても、同様の効果を得ることができる。

（３）本実施形態では、ｃｏｎｄｉｔｉｏｎＡ８２０について、必要接続状態として、「ｃｏｎｄｉｔｉｏｎ提供ポート及びｈｏｏｋ提供ポートが接続されていること」が定義されている。しかしながら、ａ提供ポート，ｂ提供ポート，ｃ提供ポート，ｄ提供ポートを有するＸインスタンスが存在したと仮定した場合に、Ｘインスタンスの必要接続状態として、例えば、「ａ〜ｃ提供ポートのうちのいずれか一つが接続されていること」が定義されていても良い。また、必要接続状態として、例えば、「ａ提供ポート及びｂ提供ポートが共に接続されているか、または、ｂ提供ポート及びｃ提供ポートが共に接続されていること」が定義されていても良い。このような定義がなされている場合であっても、同様の効果を得ることができる。

［特許請求の範囲との対応］
上記実施形態の説明で用いた用語と、特許請求の範囲の記載に用いた用語との対応を示す。

統合ツールがソースコード自動生成プログラムに、コンポーネントモデル１５１，インスタンスがコンポーネントに、コア資産１５０が生成用データに、コンフィグレーションファイルがコンフィグレーションデータに、委譲接続用ポートが専用ポートに、テンプレートファイル１５３がテンプレートデータにそれぞれ相当する。

また、ＰＣ１０がソースコード自動生成装置に相当し、ＰＣ１０が備える制御部１３が、特定手段，生成手段，取得手段にそれぞれ相当し、入力部１２が選択受付手段に相当する。

また、インスタンス削除処理におけるＳ６０５が取得ステップに、Ｓ６１０が選択受付ステップに、Ｓ６１５が削除対象コンポーネント削除ステップに、Ｓ６２０が請求項１における特定ステップに、Ｓ６２５が不要サブコンポーネント削除ステップにそれぞれ相当する。

また、不要コンポーネント特定処理におけるＳ７０５，Ｓ７１５，Ｓ７２０が請求項５における特定ステップに、Ｓ７１５，Ｓ７２０が不要コンポーネント再特定処理に、Ｓ７２５が生成ステップにそれぞれ相当する。

１０…ＰＣ、１１…ＨＤＤ、１２…入力部、１３…制御部、１４…表示部、１００…コア資産開発工程、１１０…要求分析・設計工程、１２０…実装工程、１３０…制御仕様書、１４０…ＵＭＬ設計モデル、１５０…コア資産、１５１…コンポーネントモデル、１５２…ライブラリソースコード、１５３…テンプレートファイル、２００…製品開発工程、２１０…製品構成設定工程、２２０…プロパティファイル生成工程、２３０…ビルド工程、２４０…車両仕様書、２５０…ベースコンフィグレーションファイル、２６０…コンフィグレーションファイル、２７０…プロパティソースコード、２８０…実行ファイル、３００…テンプレート、３５０…プロパティソースコード、４００…第一のインスタンス構成モデル、４１０…Ａインスタンス、４２０…Ｂインスタンス、４３０…Ｃインスタンス、４４０…Ｄインスタンス、４５０…Ｅインスタンス、５００…ＩｎｓｔａｎｃｅＡ．ｃ、５１０…ＩｎｓｔａｎｃｅＢ．ｃ、５２０…ＩｎｓｔａｎｃｅＣ．ｃ、５３０…ＩｎｓｔａｎｃｅＤ．ｃ、５４０…ＩｎｓｔａｎｃｅＥ．ｃ、８００…第二のインスタンス構成モデル、８１０…ｃｏｎｄｉｔｉｏｎＢ、８２０…ｃｏｎｄｉｔｉｏｎＡ、８３０…ｉｎｖｏｋｅｒ、８４０…ｓｗＥｖｅｎｔ、８５０…ｅｖｅｎｔＦｉｌｔｅｒ、８６０…ａｐｐ。

Claims (10)

1. 再利用可能に構成されたプログラム部品に対応しており、ポートを有するコンポーネントと、該コンポーネントに対応するソースコードを生成するためのテンプレートを有する生成用データとにアクセス可能に構成されており、
   前記コンポーネントは、前記ポート同士を接続することにより、互いに接続することができ、
   所定のプログラムに実装するために選択された複数の前記コンポーネントと、これらのコンポーネント同士の接続関係とを示すコンフィグレーションデータ、及び、前記生成用データに基づき、ソースコードを生成するソースコード自動生成プログラムであって、
   前記コンポーネントには、他の前記コンポーネントをサブコンポーネントとして有する親コンポーネントが存在し、前記サブコンポーネントと、該サブコンポーネントを有する前記親コンポーネントとは、これらのコンポーネントが有する専用ポートにより互いに接続可能に構成され、前記サブコンポーネントは、自身の前記専用ポートに接続された前記親コンポーネントの前記専用ポートが、他の前記コンポーネントに接続されることにより、他の前記コンポーネントに接続され、
   前記コンフィグレーションデータが示す前記親コンポーネントのうち、前記専用ポートが他の前記コンポーネントに接続されていない前記親コンポーネントを特定し、該親コンポーネントにおける、該専用ポートに接続されている前記専用ポートを有する前記サブコンポーネントを、不要サブコンポーネントとして特定する特定ステップと、
   前記コンフィグレーションデータと、前記生成用データとに基づき、該コンフィグレーションデータが示す前記コンポーネントのうち、少なくとも前記不要サブコンポーネントを除いた前記コンポーネントに対応するソースコードを生成する生成ステップと、
   をコンピュータに実行させることを特徴とするソースコード自動生成プログラム。
2. 請求項１に記載のソースコード自動生成プログラムにおいて、
   前記ソースコード自動生成プログラムは、
   前記コンフィグレーションデータを取得する取得ステップと、
   前記取得ステップにて取得された前記コンフィグレーションデータが示す前記コンポーネントのうち、削除対象となる前記コンポーネントである削除対象コンポーネントの選択をユーザから受け付ける選択受付ステップと、
   前記選択受付ステップにてユーザに選択された前記削除対象コンポーネントを、前記取得ステップにて取得された前記コンフィグレーションデータから削除する削除対象コンポーネント削除ステップと、
   をさらにコンピュータに実行させ、
   前記特定ステップでは、前記削除対象コンポーネント削除ステップにおいて前記削除対象コンポーネントが削除された前記コンフィグレーションデータについて、前記不要サブコンポーネントの特定を行うこと、
   を特徴とするソースコード自動生成プログラム。
3. 請求項１または請求項２に記載のソースコード自動生成プログラムにおいて、
   前記特定ステップにて特定された前記不要サブコンポーネントを、前記コンフィグレーションデータから削除する不要サブコンポーネント削除ステップを、
   さらにコンピュータに実行させ、
   前記生成ステップにおいて、前記不要サブコンポーネント削除ステップにて前記不要サブコンポーネントが削除された前記コンフィグレーションデータを用いてソースコードを生成すること、
   を特徴とするソースコード自動生成プログラム。
4. 再利用可能に構成されたプログラム部品に対応しており、ポートを有するコンポーネントと、該コンポーネントに対応するソースコードを生成するためのテンプレートを有する生成用データとにアクセス可能に構成されており、
   前記コンポーネントは、前記ポート同士を接続することにより、互いに接続することができ、
   所定のプログラムに実装するために選択された複数の前記コンポーネントと、これらのコンポーネント同士の接続関係とを示すコンフィグレーションデータ、及び、前記生成用データに基づき、ソースコードを生成するソースコード自動生成装置であって、
   前記コンポーネントには、他の前記コンポーネントをサブコンポーネントとして有する親コンポーネントが存在し、前記サブコンポーネントと、該サブコンポーネントを有する前記親コンポーネントとは、これらのコンポーネントが有する専用ポートにより互いに接続可能に構成され、前記サブコンポーネントは、自身の前記専用ポートに接続された前記親コンポーネントの前記専用ポートが、他の前記コンポーネントに接続されることにより、他の前記コンポーネントに接続され、
   前記コンフィグレーションデータが示す前記親コンポーネントのうち、前記専用ポートが他の前記コンポーネントに接続されていない前記親コンポーネントを特定し、該親コンポーネントにおける、該専用ポートに接続されている前記専用ポートを有する前記サブコンポーネントを、不要サブコンポーネントとして特定する特定手段と、
   前記コンフィグレーションデータと、前記生成用データとに基づき、該コンフィグレーションデータが示す前記コンポーネントのうち、少なくとも前記不要サブコンポーネントを除いた前記コンポーネントに対応するソースコードを生成する生成手段と、
   を備えることを特徴とするソースコード自動生成装置。
5. 再利用可能に構成されたプログラム部品に対応しており、特定の形式を持つポートを有するコンポーネントと、該コンポーネントに対応するソースコードを生成するためのテンプレートを有する生成用データとにアクセス可能に構成されており、
   前記コンポーネントは、対応する形式の前記ポート同士を接続することにより、互いに接続することができ、
   前記コンポーネントと、これらのコンポーネント同士の接続関係と、前記生成用データとに基づき、ソースコードを生成するソースコード自動生成プログラムであって、
   前記生成用データには、前記コンポーネントについて、該コンポーネントの存在価値を生じさせることができる、該コンポーネントが有する所定の前記ポートと、他の前記コンポーネントが有する前記ポートとの接続状態である必要接続状態が定義されており、
   所定のプログラムに実装するために選択された複数の前記コンポーネントと、これらのコンポーネント同士の接続関係と、該接続に係る前記ポートの形式とを示すコンフィグレーションデータを取得する取得ステップと、
   前記取得ステップにて取得された前記コンフィグレーションデータが示す前記コンポーネントのうち、削除対象となる前記コンポーネントである削除対象コンポーネントの選択をユーザから受け付ける選択受付ステップと、
   前記生成用データに基づき、前記コンフィグレーションデータが示す前記コンポーネントのうち、前記必要接続状態でない前記コンポーネントを不要コンポーネントとして特定する特定ステップと、
   前記取得ステップにて取得された前記コンフィグレーションデータが示す前記コンポーネントのうち、少なくとも前記削除対象コンポーネントと前記不要コンポーネントとを除いた前記コンポーネントと、これらのコンポーネント同士の前記接続関係と、前記生成用データとに基づき、これらのコンポーネントに対応するソースコードを生成する生成ステップと、
   をコンピュータに実行させることを特徴とするソースコード自動生成プログラム。
6. 請求項５に記載のソースコード自動生成プログラムにおいて、
   前記特定ステップにおいて、前記不要コンポーネントが特定されると、前記コンフィグレーションデータが示す前記コンポーネントのうち、該不要コンポーネントが有する前記ポートと接続されることにより、前記必要接続状態が形成される前記ポートを有する前記コンポーネントを、新たに前記不要コンポーネントとして特定する不要コンポーネント再特定処理を実行すること、
   を特徴とするソースコード自動生成プログラム。
7. 請求項６に記載のソースコード自動生成プログラムにおいて、
   前記特定ステップにおいて、前記不要コンポーネント再特定処理にて新たに前記不要コンポーネントが特定されると、再度、新たに特定された前記不要コンポーネントについて前記不要コンポーネント再特定処理を実行すること、
   を特徴とするソースコード自動生成プログラム。
8. 請求項５から請求項７のいずれかに記載のソースコード自動生成プログラムにおいて、
   前記選択受付ステップにてユーザに選択された前記削除対象コンポーネントを、前記取得ステップにて取得された前記コンフィグレーションデータから削除する削除対象コンポーネント削除ステップを、さらにコンピュータに実行させ、
   前記特定ステップにおいて、前記削除対象コンポーネント削除ステップにて、前記削除対象コンポーネントが削除された前記コンフィグレーションデータについて、前記不要コンポーネントの特定を行うこと、
   を特徴とするソースコード自動生成プログラム。
9. 請求項５から請求項８のいずれかに記載のソースコード自動生成プログラムにおいて、
   前記生成用データは、いずれかの前記コンポーネントに関連付けられており、関連付けられている前記コンポーネントについて前記テンプレートを有しているテンプレートデータを有しており、前記テンプレートデータには、関連付けられている前記コンポーネントについての前記必要接続状態が定義されていること、
   を特徴とするソースコード自動生成プログラム。
10. 再利用可能に構成されたプログラム部品に対応しており、特定の形式を持つポートを有するコンポーネントと、該コンポーネントに対応するソースコードを生成するためのテンプレートを有する生成用データとにアクセス可能に構成されており、
    前記コンポーネントは、対応する形式の前記ポート同士を接続することにより、互いに接続することができ、
    前記コンポーネントと、これらのコンポーネント同士の接続関係と、前記生成用データとに基づき、ソースコードを生成するソースコード自動生成装置であって、
    前記生成用データには、前記コンポーネントについて、該コンポーネントの存在価値を生じさせることができる、該コンポーネントが有する所定の前記ポートと、他の前記コンポーネントが有する前記ポートとの接続状態である必要接続状態が定義されており、
    所定のプログラムに実装するために選択された複数の前記コンポーネントと、これらのコンポーネント同士の接続関係と、該接続に係る前記ポートの形式とを示すコンフィグレーションデータを取得する取得手段と、
    前記取得手段により取得された前記コンフィグレーションデータが示す前記コンポーネントのうち、削除対象となる前記コンポーネントである削除対象コンポーネントの選択をユーザから受け付ける選択受付手段と、
    前記生成用データに基づき、前記コンフィグレーションデータが示す前記コンポーネントのうち、前記必要接続状態でない前記コンポーネントを不要コンポーネントとして特定する特定手段と、
    前記取得手段により取得された前記コンフィグレーションデータが示す前記コンポーネントから、少なくとも前記削除対象コンポーネントと前記不要コンポーネントとを除いた前記コンポーネントと、これらのコンポーネント同士の前記接続関係と、前記生成用データとに基づき、これらのコンポーネントに対応するソースコードを生成する生成手段と、
    を備えることを特徴とするソースコード自動生成装置。