(57)【要約】【課題】プログラム開発において、消費リソース量が許容リソース量を満たすプログラムの設計を支援する技術を提供する。【解決手段】複数の部品モジュールから構成されるプログラムの設計において許容される許容リソース量を設定する設定手段と、前記プログラムの実行にあたり消費される消費リソース量を取得する取得手段と、前記取得手段により取得された消費リソース量が前記設定手段により設定された許容リソース量よりも大きい場合、前記プログラムを構成する複数の部品モジュールのうち代替可能な部品モジュールを前記プログラムの設計変更可能箇所として抽出する抽出手段と、前記抽出手段により抽出された部品モジュールに基づいて前記設計変更可能箇所の選択肢を提示する提示手段と、を有することによって課題を解決する。【選択図】図１１
2016018269.tif 000002
【特許請求の範囲】
【請求項１】
複数の部品モジュールから構成されるプログラムの設計において許容される許容リソース量を設定する設定手段と、
前記プログラムの実行にあたり消費される消費リソース量を取得する取得手段と、
前記取得手段により取得された消費リソース量が前記設定手段により設定された許容リソース量よりも大きい場合、前記プログラムを構成する複数の部品モジュールのうち代替可能な部品モジュールを前記プログラムの設計変更可能箇所として抽出する抽出手段と、
前記抽出手段により抽出された部品モジュールに基づいて前記設計変更可能箇所の選択肢を提示する提示手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記提示手段により提示された選択肢を予め定められた基準に基づいて選択し、前記選択した選択肢に基づいて前記プログラムを変更する設計変更選択手段を更に有することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記設計変更選択手段は、前記提示手段により提示された選択肢のうち、前記消費リソース量が前記許容リソース量より大きくならず、かつ、優先リソースとして設定されたリソースの消費リソース量が最小となる選択肢を選択することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記取得手段は、前記部品モジュール毎に消費リソース量が管理されている記憶領域から取得した前記部品モジュール毎の消費リソース量に基づいて、前記プログラムの実行にあたり消費される消費リソース量を算出して取得することを特徴とする請求項１乃至３の何れか１項に記載の情報処理装置。
【請求項５】
前記取得手段は、前記プログラムを構成する部品モジュールの動作順序パターンを抽出し、前記抽出した動作順序パターン毎に算出した前記プログラムの実行にあたり消費される消費リソース量のうち、優先リソースとして設定されたリソースの消費リソース量が最小となる動作順序パターンの消費リソース量を取得することを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記取得手段は、前記動作順序パターンを抽出する際に、前記プログラムを構成する部品モジュールを直列処理動作させる場合における動作順序パターンを抽出することを特徴とする請求項５に記載の情報処理装置。
【請求項７】
前記取得手段は、前記動作順序パターンを抽出する際に、前記プログラムを構成する部品モジュールのうち同時動作可能な部品モジュールが存在する場合、前記同時動作可能な部品モジュールを並列処理動作させる場合における動作順序のパターンも含めて抽出することを特徴とする請求項５又は６に記載の情報処理装置。
【請求項８】
前記取得手段は、前記設計変更選択手段により前記プログラムが変更された場合、再度、前記プログラムの実行にあたり消費される消費リソース量を取得することを特徴とする請求項２又は３に記載の情報処理装置。
【請求項９】
前記抽出手段は、前記プログラムを構成する複数の部品モジュール毎に、又は部品モジュール群毎に代替可能な部品モジュールの有無を判定し、前記プログラムの設計変更可能箇所として抽出することを特徴とする請求項１乃至８の何れか１項に記載の情報処理装置。
【請求項１０】
前記抽出手段は、前記プログラムを構成する複数の部品モジュール毎に、又は部品モジュール群毎に代替可能な部品モジュールが管理されている記憶領域を参照することにより、前記部品モジュール毎に、又は前記部品モジュール群毎に代替可能な部品モジュールの有無を判定することを特徴とする請求項９に記載の情報処理装置。
【請求項１１】
前記提示手段は、前記抽出手段により抽出された部品モジュールで代替した場合における前記プログラムの実行にあたり消費される消費リソース量を前記選択肢として提示することを特徴とする請求項１乃至１０の何れか１項に記載の情報処理装置。
【請求項１２】
前記設定手段は、前記プログラムが実行される環境において許容されるメモリ量、処理時間、回路規模のうち少なくとも何れかを前記許容リソース量として設定することを特徴とする請求項１乃至１１の何れか１項に記載の情報処理装置。
【請求項１３】
複数の部品モジュールから構成されるプログラムの設計を支援する情報処理装置が実行する情報処理方法であって、
複数の部品モジュールから構成されるプログラムの設計において許容される許容リソース量を設定する設定ステップと、
前記プログラムの実行にあたり消費される消費リソース量を取得する取得ステップと、
前記取得ステップにより取得された消費リソース量が前記設定ステップにより設定された許容リソース量よりも大きい場合、前記プログラムを構成する複数の部品モジュールのうち代替可能な部品モジュールを前記プログラムの設計変更可能箇所として抽出する抽出ステップと、
前記抽出ステップにより抽出された部品モジュールに基づいて前記設計変更可能箇所の選択肢を提示する提示ステップと、
を含むことを特徴とする情報処理方法。
【請求項１４】
複数の部品モジュールから構成されるプログラムの設計を支援するコンピュータに、
複数の部品モジュールから構成されるプログラムの設計において許容される許容リソース量を設定する設定ステップと、
前記プログラムの実行にあたり消費される消費リソース量を取得する取得ステップと、
前記取得ステップにより取得された消費リソース量が前記設定ステップにより設定された許容リソース量よりも大きい場合、前記プログラムを構成する複数の部品モジュールのうち代替可能な部品モジュールを前記プログラムの設計変更可能箇所として抽出する抽出ステップと、
前記抽出ステップにより抽出された部品モジュールに基づいて前記設計変更可能箇所の選択肢を提示する提示ステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
ＰＣ上で開発したプログラムを組み込み機器に移植する場合、ＰＣと組み込み機器とではＣＰＵのクロック周波数や、メモリ量等が大きく異なるため、そのプログラムを組み込み機器で実行したときに必要とされるメモリ量や処理時間を予測することは困難であった。同様にＰＣ上で開発したプログラムをハードウェア実装に移植する場合にも、その回路規模（メモリ量を含む）や処理時間を予測することは困難であった。
また、プログラムをＰＣ上で動作させれば、プロファイリングすることにより、ＰＣ上で動作させたときのメモリ量や処理時間は測定できる。しかしながら、そのためには、プログラムを完成させ、コンパイル等して実行形式に変換して、実際に動作させる必要がある。従って、完成途中のプログラムでは、ＰＣ上で動作させる場合のメモリ量や処理時間であっても、測定することは困難であった。以降、メモリ量、処理時間、回路規模のように、あるプログラムを実行するのに必要な空間的、時間的資源をリソースと総称することにする。
このように、実際にターゲットとなる環境でプログラムを動かしてみるまで、必要となるリソース量の予測が困難であった。そのため、実際に移植作業を行った後に、予測していたリソース量と、実際に必要となったリソース量との乖離が判明することがある。その場合、リソース量に関して設定されていた仕様（許容リソース量と呼ぶ）内に、実際のリソース量を収めることができなくなるといった問題も発生する。
【０００３】
この問題に対して、特許文献１、特許文献２には、プログラム部品情報データベースに記録された情報を用いてシミュレーションすることで、プログラムの実行に要する時間を予測する手法が開示されている。
また、特許文献３には、モデルベース開発において、モデルの構成要素毎にリソース消費見積量を管理しておくことで、モデルの構成要素から、そのモデルのマイコンリソース消費見積もり量を算出する手法が開示されている。
また、特許文献４に開示されている手法は、例えば、システム管理者によって入力された複数の処理手順及び複数のポリシーを用い、複数の処理手順に対応するワークフローを実行した際の状態遷移モデルを生成する。更に、この手法では、この状態遷移モデル及びシステム管理者によって入力された複数の制約を用い、複数のワークフローを実行した際に制約違反が発生するか否かを判定する。そして、制約違反が発生すると判定された場合、処理手順、ポリシー及び制約の何れか一つ又は複数に変更を加え、この変更を加えた後の処理手順、ポリシー及び制約を含むワークフロー定義を代替ワークフロー定義としてシステム管理者に提示することができる。これにより、複数のワークフロー間でのリソースの取り合い回避することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−２６８８７９号公報
【特許文献２】特開２００４−２７２５８２号公報
【特許文献３】特開２００５−７８２４３号公報
【特許文献４】国際公開第２００８／１５２９１０号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
以上のように、実際にターゲットとなる環境でプログラムを動かしてみなくても、必要なリソース量を予測する手法が提案されているが、それぞれ以下のような問題点がある。
特許文献１、特許文献２、特許文献３に開示されている手法では、リソース消費見積もり量を算出することはできるが、見積もり量が許容リソース量を超えてしまった場合に、どこをどう修正するのかは、プログラム設計者の経験と勘とに依存していた。
特許文献４に開示されている手法では、ポリシーや制約を変更することで、複数のワークフロー間でのリソース調整は行われるが、そもそもリソース消費量の絶対量を減らすことを考慮していない。また、この手法は、単一のプログラムに関してリソース違反が発生した場合には適用することができない。
本発明は、プログラム開発において、消費リソース量が許容リソース量を満たすプログラムの設計を支援する技術を提供することを目的とする。
【課題を解決するための手段】
【０００６】
そこで、本発明の情報処理装置は、複数の部品モジュールから構成されるプログラムの設計において許容される許容リソース量を設定する設定手段と、前記プログラムの実行にあたり消費される消費リソース量を取得する取得手段と、前記取得手段により取得された消費リソース量が前記設定手段により設定された許容リソース量よりも大きい場合、前記プログラムを構成する複数の部品モジュールのうち代替可能な部品モジュールを前記プログラムの設計変更可能箇所として抽出する抽出手段と、前記抽出手段により抽出された部品モジュールに基づいて前記設計変更可能箇所の選択肢を提示する提示手段と、を有することを特徴とする。
【発明の効果】
【０００７】
本発明によれば、プログラム開発において、消費リソース量が許容リソース量を満たすプログラムの設計を支援する技術を提供することができる。
【図面の簡単な説明】
【０００８】
【図１】プログラム設計支援装置のハードウェア構成の一例を示す図である。
【図２】プログラム設計支援装置の機能構成の一例を示す図である。
【図３】設計中のプログラムの一例を示す図（その１）である。
【図４】プログラム構成情報の一例を示す図（その１）である。
【図５】消費リソース量算出処理の一例を示すフローチャート（その１）である。
【図６】動作順序抽出処理の一例を示すフローチャートである。
【図７】メモリ量算出処理の一例を示すフローチャートである。
【図８】メモリ確保リストの一例を示す図（その１）である。
【図９】動作順序パターン別消費リソース量リストの一例を示す図である。
【図１０】部品モジュール毎の消費リソース量の一例を示す図である。
【図１１】プログラム設計処理の一例を示すフローチャートである。
【図１２】消費リソース量算出処理の一例を示すフローチャート（その２）である。
【図１３】設計中のプログラムの一例を示す図（その２）である。
【図１４】設計中のプログラムの一例を示す図（その３）である。
【図１５】プログラム構成情報の一例を示す図（その２）である。
【図１６】設計中のプログラムの一例を示す図（その４）である。
【図１７】設計中のプログラムの一例を示す図（その５）である。
【図１８】メモリ確保リストの一例を示す図（その２）である。
【発明を実施するための形態】
【０００９】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
＜実施形態１＞
実施形態１として、モデルベース開発手法を用いるプログラム開発を行う場合に本発明によるプログラム設計支援装置（情報処理装置）を用いる例を示す。モデルベース開発手法とは、一般的なソフトウェア開発であるソースコードによる開発とは異なり、予め用意されたプログラム部品モデル（部品モジュールと呼ぶ）を組み合わせて用いることで、所望の処理を実現するプログラムを作成しようとする開発手法である。
まず、本発明によるプログラム設計支援装置のハードウェア構成及び機能構成の説明を行い、続いてプログラム設計支援装置を使ったプログラム設計の手順について説明する。
【００１０】
図１は、本発明によるプログラム設計支援装置のハードウェア構成の一例を示す図である。ＣＰＵ１１は、ＨＤ１４やＲＯＭ１３から読み出したプログラムをＲＡＭ１２に格納して実行することにより、後述するプログラム設計支援装置の機能構成及び後述するフローチャートの処理を実現する。ＲＡＭ１２は、プログラム設計支援装置のメインメモリである。ＲＯＭ１３は、プログラム設計支援装置の電源投入時に最初に読み込まれるプログラム等を格納する。ＨＤ１４は、各種のプログラム及びＣＰＵ１１が実行する処理に要する各種のデータを格納する。入力装置１５は、プログラム設計支援装置を操作するキーボード、マウス、入力キー等で構成されている。表示装置１６は、ディスプレイ等で構成されている。なお、表示装置１６は、ディスプレイをタッチすることにより操作が可能なタッチパネルであってもよい。インターフェース装置１７は、プログラム設計支援装置をネットワークに接続するインターフェースである。
【００１１】
図２は、本発明によるプログラム設計支援装置の機能構成の一例を示す図である。ここでは、図２に示す機能構成はＣＰＵ１１がＨＤ１４等に格納されているプログラムを実行することにより実現されるものとしているが、ハードウェアによって実現されるようにしてもよい。
プログラム設計部１０８は、所望の処理をするプログラムの設計を、モデルベース開発を用いたビジュアルなプログラミング手法で行う。プログラム設計部１０８は、プログラム設計の際に、部品モジュール情報管理データベース（記憶領域）１０７にアクセスし、所望の部品モジュールを取り込み、それらの部品モジュールを組み合わせて動作順序を規定することで、プログラムの設計を進めていく。なお、本実施形態を含む以下の実施形態では、複数のデータを記憶するＨＤ等の記憶領域のことを含めてデータベースという。
プログラム設計部１０８は、今設計しているプログラムを構成している部品モジュールの一覧情報と、その接続状態情報とを合わせた情報を、プログラム構成情報として出力する。また、プログラム設計部１０８は、設計変更可能箇所抽出部１０３から代替部品モジュール情報が入力された場合には、その代替部品モジュールを用いたプログラム構成情報を出力する。プログラム設計部１０８と設計変更可能箇所抽出部１０３との情報のやりとりに関しての詳細説明は、設計変更可能箇所抽出部１０３の説明の際に行う。
【００１２】
ここで代替部品モジュールとは、元の部品モジュールと同様の処理を行うが、その消費リソース量が異なるようなモジュールをいう。また、ここでいうリソースとは、メモリ量、処理時間、回路規模のように、ある所望の処理を実行するのに必要な空間的、時間的資源のことを指す。例えば、ある処理を実現する部品モジュールがあったときに、その部品モジュールを動作させたときに必要なメモリ量や処理時間が、消費リソース量となる。
ある処理を実現するのに所定のメモリ量と処理時間とがリソースとして必要な部品モジュールに対し、同様の処理を実現するが使用するメモリ量が多く処理時間が短いような部品モジュールがあった場合、それらはお互いに代替部品モジュールになる。従って上記の代替部品モジュールを用いたプログラム構成情報とは、プログラム構成情報のうち、代替可能な部品モジュールを代替部品モジュールに置き換えたものを指す。
【００１３】
図３には、プログラム設計部１０８において設計されたプログラムの一例として、画像処理プログラムを実現した例が示されている。図３に示すプログラムでは、入力画像を部品モジュールＡに入力し、その処理結果を部品モジュールＢ並びに部品モジュールＣに入力する。更に、部品モジュールＣの処理結果は部品モジュールＤに入力され、その処理結果は、部品モジュールＢの処理結果と共に部品モジュールＥに入力され、出力画像として出力される。
図３に示すようなプログラムは、プログラム設計部１０８が部品モジュール情報管理データベース１０７にアクセスして、それぞれの部品モジュールを取得し、それらの間を結線することで作成できる。
図４に、図３に示すプログラムのプログラム構成情報の一例を示す。図４は、例えば部品モジュールＡの入力側はプログラム全体の入力と接続され、出力側は部品モジュールＢ並びに部品モジュールＣと接続されていることを示している。プログラム設計部１０８は、このプログラム構成情報を、図３に示す構成から容易に抽出することができる。また、プログラムの入力や出力は本来部品モジュールではないが、後述する動作順序の探索等で統一的な扱いができるようにするため、図４では入力や出力も仮想的に部品モジュールとして扱うこととしている。
【００１４】
図２に示す許容リソース量設定部１０１は、設計変更可能箇所抽出部１０３に対して、今設計しているプログラムに許容されるリソース量（許容リソース量）を設定する。許容リソース量設定部１０１は、今設計しているプログラムが最終的に実行される環境（ターゲット環境と呼ぶ）を想定して、ターゲット環境で許容されるような設定値を許容リソース量として設定する。例えば、プログラムが組み込み機器で実行されるのであれば、許容リソース量設定部１０１は、組み込み機器に課せられた外部仕様（メモリ量、処理時間等）から、許容されるリソース量を推定して設定する。また、プログラムがハードウェア化されて実行されるのであれば、許容リソース量設定部１０１は、ハードウェアチップに課せられた外部仕様（回路規模、処理時間等）から、ハードウェア化された場合に許容されるリソース量を推定して設定する。
【００１５】
図２に示す消費リソース量算出部１０２は、プログラム設計部１０８で設計中のプログラムが、ターゲット環境で消費するリソース量（消費リソース量）を算出し、設計変更可能箇所抽出部１０３に出力する。なお、消費リソース量算出部１０２が実行する処理は、消費リソース量を算出して取得する取得処理の一例である。消費リソース量算出部１０２には、設計中のプログラムで想定されているターゲット環境情報が設定される。これにより、どのような種類のリソースに関して消費リソース量を見積もればよいのかが指定される。例えば、ターゲット環境がハードウェア化であれば、回路規模や処理時間のリソースを算出するように指示される。
更に消費リソース量算出部１０２には、複数のリソースの種類のうち、どのリソースに関して優先的にリソース量を算出するかという優先リソースが設定される。優先リソースは、消費リソース量算出部１０２がリソース量を算出する際に複数の算出方法があったときに、優先リソースが最も小さくなるような算出方法を選択して消費リソース量を算出するために設定される。例えば、優先リソースとして回路規模が設定されている場合に、回路規模が大きくて処理時間が短くなるようなリソース算出方法Ａと、回路規模が小さくて処理時間が長くなるようなリソース算出手法Ｂとがあるとする。この場合、消費リソース量算出部１０２は、リソース算出方法Ｂを選択して消費リソース量を算出する。
【００１６】
次に、図５を用いて、消費リソース量算出部１０２による、設計中のプログラムにおける消費リソース量の見積もり方法を詳細に説明する。図５は、本実施形態における消費リソース量算出部１０２の処理の一例を示すフローチャートである。
まずＳ３０１において、消費リソース量算出部１０２は、設計しているプログラムの消費リソース量を算出するために、プログラム設計部１０８からプログラム構成情報を取得する。プログラム設計部１０８から取得するプログラム構成情報としては、現在設計しているプログラムに対するプログラム構成情報の場合と、そのプログラム中の代替可能部品モジュールを代替部品モジュールで置き換えたプログラムのプログラム構成情報の場合とがある。
Ｓ３０２において、消費リソース量算出部１０２は、取得したプログラム構成情報と、設定されたターゲット環境情報とを用いて、消費リソース量管理データベース（記憶領域）１０６にアクセスし、部品モジュール毎の消費リソース量を読み出す。消費リソース量管理データベース１０６で管理している部品モジュール毎の消費リソース量としては、入力データ量、出力データ量、処理時間等が挙げられる。消費リソース量管理データベース１０６の詳細は後述する。
【００１７】
Ｓ３０３において、消費リソース量算出部１０２は、部品モジュールの動作順序のパターン（動作順序パターン）を抽出する。ある部品モジュールは、その上流側の部品モジュールからデータが出力されたのを受けて動作するので、部品モジュールが直列に並んだだけのプログラムでは、部品モジュールの動作順序は一意に定まる。しかしながら、図３のように部品モジュールが並列に並んだ箇所を含むようなプログラムでは、動作順序として複数のパターンが存在する。消費リソース量算出部１０２は、その動作順序パターンを抽出する。
消費リソース量算出部１０２による動作順序パターンの抽出は、次のような規則に従って行われる。１．各部品モジュールは、動作に必要なデータが全て揃った場合に動作する。２．プログラムを構成する全ての部品モジュールを調査し、動作できるものがあれば動作させる。３．もし、動作できる部品モジュールが複数あれば、それぞれを動作させた場合について独立に動作順序を抽出する。以上の規則に従って動作順序の抽出が行われる。
上記では部品モジュールを動作させると説明したが、動作順序パターンの抽出では、実際に部品モジュールを動作させる必要はなく、動作させたという想定で、その部品モジュールの出力データが下流側の部品モジュールに届いた、ということを意味する。
【００１８】
図６は、Ｓ３０３における処理の詳細の一例を示すフローチャートである。図６のフローチャートを用いて、消費リソース量算出部１０２が、図３のプログラムに対して動作順序パターンの抽出を行う場合について説明する。
本フローチャートにおいて、消費リソース量算出部１０２は、動作順序パターンの抽出を行うために、部品モジュールを動作させる度に動作可能な部品モジュールの抽出を行う。その際に、消費リソース量算出部１０２は、全ての部品モジュールのうちまだ動作していない部品モジュールを管理する未動作部品モジュールリストと、未動作部品モジュールリストに登録されている部品モジュールのうち、動作可能か否かのチェックがまだ行われていない部品モジュールを管理する未調査部品モジュールリストとを用いる。動作可能な部品モジュールの抽出では、未動作部品モジュールリストの部品モジュール一つ一つに対して動作可能か否かをチェックして行うため、そのチェックを行ったか否かを管理するために未調査部品モジュールリストが用いられる。
【００１９】
まずＳ６０１において、消費リソース量算出部１０２は、プログラムを構成する全ての部品モジュールを未動作部品モジュールリストに登録する。図３の場合、消費リソース量算出部１０２は、部品モジュールＡ〜Ｅの５部品モジュールを未動作部品モジュールとして登録する。
Ｓ６０２において、消費リソース量算出部１０２は、プログラムに入力データを投入する。図３では、部品モジュールＡに対して入力データを投入することになるが、ここでは部品モジュールＡに対して実際に入力データを投入する必要はなく、部品モジュールＡが動作できる状態になった、ということを意味するものである。
Ｓ６０３において、消費リソース量算出部１０２は、全ての未動作部品モジュールを未調査部品モジュールリストに登録する。今の場合、消費リソース量算出部１０２は、部品モジュールＡ〜Ｅまでの５部品モジュールを未調査部品モジュールとして登録する。
Ｓ６０４〜Ｓ６０８において、消費リソース量算出部１０２は、未調査部品モジュールリストに登録されている部品モジュールのうち、動作可能な部品モジュールを特定する。より具体的には、Ｓ６０４において、消費リソース量算出部１０２は、未調査部品モジュールリストからある未調査部品モジュールを選択し、選択した未調査部品モジュールを未調査部品モジュールリストから削除する。そして、Ｓ６０５において、消費リソース量算出部１０２は、選択した部品モジュールは動作可能か判定する。今の場合、入力データがそろっているのは部品モジュールＡのみであるので、Ｓ６０７において、消費リソース量算出部１０２は、全ての未調査部品モジュールの調査が終了したか判定し、終了していればＳ６０９に進み、終了していなければＳ６０８に進む。Ｓ６０８において、消費リソース量算出部１０２は、未調査部品モジュールの一つを選択してＳ６０５に戻る。
【００２０】
Ｓ６０９において、消費リソース量算出部１０２は、動作可能部品モジュールの一つを選択し、動作させる。そして、消費リソース量算出部１０２は、動作させた部品モジュールを未動作部品モジュールリストから削除する。ここで、部品モジュールを動作させるとしているが上述のように、実際に部品モジュールをプログラムとして動作させる必要はなく、動作させたという想定で、その部品モジュールの出力データが下流側の部品モジュールに届いた、ということを意味するものである。今の場合、動作可能部品モジュールは部品モジュールＡだけなので、部品モジュールＡを動作させたと想定して、その出力データが出力されたとする。
Ｓ６１０において、消費リソース量算出部１０２は、プログラム全体としての出力データが揃ったか（即ちプログラムが最後まで実行されたか）チェックする。今の場合、まだ揃ってないので、Ｓ６０３に戻り、消費リソース量算出部１０２は、次の動作可能部品モジュールの探索を繰り返す。先ほど部品モジュールＡの処理が終了し、出力データが出力されたので、この時点での動作可能部品モジュールは、部品モジュールＢと部品モジュールＣとになる。
【００２１】
このように、複数の部品モジュールが動作可能部品モジュールとなる場合には、Ｓ６０８において、消費リソース量算出部１０２は、複数の部品モジュールそれぞれを別に動作させたものと想定して、それぞれを独立した複数の動作順序パターンとして抽出する。即ち、今の場合、消費リソース量算出部１０２は、動作順序として、部品モジュールＡの次に部品モジュールＢを動作させる動作順序パターンと、部品モジュールＡの次に部品モジュールＣを動作させる動作順序パターンとを抽出する。このように、複数の部品モジュールが動作可能部品モジュールとなる場合には、動作順序のパターンが増えていく。
このようにして消費リソース量算出部１０２は、部品モジュールの動作順序パターンを抽出する。図３の場合、動作順序として、「入力⇒Ａ⇒Ｂ⇒Ｃ⇒Ｄ⇒Ｅ⇒出力」というパターンと、「入力⇒Ａ⇒Ｃ⇒Ｂ⇒Ｄ⇒Ｅ⇒出力」というパターンと、「入力⇒Ａ⇒Ｃ⇒Ｄ⇒Ｂ⇒Ｅ⇒出力」というパターンと、の３通りが抽出される。以上がＳ３０３で消費リソース量算出部１０２が行う処理である。
【００２２】
図５の説明に戻る。
Ｓ３０４において、消費リソース量算出部１０２は、消費リソース量管理データベース１０６から取得した部品モジュール毎の消費リソース量と、抽出した動作順序のパターンとを用いて、今設計しているプログラムの消費リソース量を算出する。Ｓ３０４で算出する消費リソース量としては、メモリ量や処理時間、回路規模等が考えられる。
Ｓ３０４で消費リソース量算出部１０２が処理時間に関する消費リソース量を算出する場合、Ｓ３０２で取得した部品モジュール毎の消費リソースに含まれる処理時間を、Ｓ３０３で抽出した動作順序に従って加算していくことにより算出できる。このとき、消費リソース量算出部１０２は、Ｓ３０３で抽出した全ての動作順序パターンに従って加算し、処理時間に関する消費リソース量を動作順序パターン数分算出する。ただし、本実施形態の場合には、動作順序パターンの抽出に並列動作が考慮されていないので、動作順序パターンによらず処理時間は同じになる。並列動作を考慮した場合の手順は実施形態２に示す。回路規模も処理時間と同様の手順にて消費リソース量が算出できる。
【００２３】
Ｓ３０４で消費リソース量算出部１０２がメモリ量に関する消費リソース量を算出する場合、Ｓ３０１で取得したプログラム構成情報と、Ｓ３０２で取得した部品モジュール毎の入力データ量、出力データ量と、Ｓ３０３で抽出した動作順序パターンとを用いて算出する。消費リソース量算出部１０２がメモリ量に関する消費リソース量を算出する場合には、まず、各部品モジュールの入力データ量、出力データ量から、それらを格納するための入力データ格納メモリ量、出力データ格納メモリ量を算出する。ただし、これらのメモリ量を処理時間の場合や回路規模の場合と同様に単純に加算すると、メモリの使いまわし（時分割で使いまわす）等のメモリの有効活用が考慮されない。
また、プログラム構成情報上でお互いに接続している部品モジュールであれば、上流側部品モジュールの出力データ格納メモリと、下流側部品モジュールの入力データ格納メモリとは共有されるので、それぞれを別に持つ必要はない。例えば図３では、部品モジュールＡの出力データ格納メモリと、部品モジュールＢの入力データ格納メモリとは共有されるので、何れか一方があればよい。
【００２４】
このようなメモリの共通化を考慮したメモリ量算出手順を図７に示す。図７は、メモリ量算出処理の一例を示すフローチャートである。図７の手順は、Ｓ３０３において抽出した全ての動作順序パターンそれぞれについて独立に行われ、図７において算出される最大メモリ量（ある瞬間に必要とされるメモリ量の最大のもの）が、その動作順序パターンで使用するメモリ量となる。従って、メモリ量は動作順序パターン数分算出されことになる。以降の図７の説明では、動作理解を助けるために、図３において、「入力⇒Ａ⇒Ｂ⇒Ｃ⇒Ｄ⇒Ｅ⇒出力」で示される動作順序に関してメモリ量を算出している場合の手順を例題として説明する。
まず、Ｓ７０１において、消費リソース量算出部１０２は、メモリ確保リストと最大メモリ量とを初期化する。メモリ管理リストは、ある時点で必要となるメモリ量を調査するために用いられる。メモリ確保リストには、そのメモリを入力データ格納メモリとして使用する部品モジュール名（そのメモリから見るとこの部品モジュールは後段に位置することになるので、この部品モジュールを後段接続部品モジュールと呼ぶ）と、メモリ量とが記載される。そのメモリの後段接続部品モジュール名は、プログラム構成情報から抽出できる。メモリ量は、消費リソース量管理データベース１０６から得た情報により算出できる。また、そのメモリが、ある時点以降で使用されるか否かを管理するための動作済みチェック情報（詳細説明はＳ７０４、Ｓ７０５の手順の説明で行う）もメモリ確保リストで管理される。
【００２５】
Ｓ７０２において、消費リソース量算出部１０２は、プログラムの入力データ分のメモリをメモリ確保リストに登録する。例題手順では、部品モジュールＡの入力データ格納メモリをメモリ確保リストに登録する。このとき、メモリ量としては、入力データ格納メモリ量（Ａ＿ｉｎとする）を登録する。このメモリの後段接続部品モジュール名としては、部品モジュールＡを登録する。このときのメモリ確保リストの内容を図８の（Ａ）に示す。
Ｓ７０３において、消費リソース量算出部１０２は、次に動作させる部品モジュールの出力データ格納メモリをメモリ確保リストに登録する。どの部品モジュールが次に動作するのかは、動作順序を見ればわかる。例題手順では、まだ動作した部品モジュールがないので、最初に動作する部品モジュールである部品モジュールＡの出力データ格納メモリをメモリ確保リストに登録する。このとき、メモリ量としては、出力データ格納メモリ量（Ａ＿ｏｕｔとする）を登録する。このメモリの後段接続部品モジュール名としては、プログラム構成情報を参照して、部品モジュールＢと部品モジュールＣとを登録する。このときのメモリ確保リストの内容を図８の（Ｂ）に示す。
Ｓ７０４において、消費リソース量算出部１０２は、現時点でメモリ確保リストに登録されているメモリ量を算出する。消費リソース量算出部１０２は、メモリ量を算出する際に、そのメモリの後段接続部品モジュールの全てが動作済みになっているメモリを除外して算出する。除外する理由は、後段接続部品モジュールの全てが動作済みになっているメモリに格納されているデータは、その時点で不要（今後使われることはない）になっているので、そのメモリ量を確保しておく必要がなくなっているからである。例題手順では、メモリ確保リストは図８の（Ｂ）のようになっているので、メモリ量は、Ａ＿ｉｎ＋Ａ＿ｏｕｔとなる。
【００２６】
Ｓ７０５において、消費リソース量算出部１０２は、動作順序を一つ進める。例題手順では、部品モジュールＡの動作が済んだとする。このときに、今動作させた部品モジュールが、メモリ確保リストの後段接続部品モジュールとなっている場合、メモリ登録リストの対応する動作済みチェック欄を動作済みにする。今の場合、後段接続部品モジュールが部品モジュールＡとなっていれば動作済みとする。このときの例題手順でのメモリ確保リストの内容を図８の（Ｃ）に示す。
Ｓ７０６、Ｓ７０７において、消費リソース量算出部１０２は、Ｓ７０５で算出したメモリ量が最大メモリ量より大きければ、最大メモリ量を更新する。
Ｓ７０８において、消費リソース量算出部１０２は、動作順序が最後まで進んだかをチェックし、最後まで進んでいなければＳ７０３に戻り、次に動作させる部品モジュールに関する手順を続ける。次に動作させるのは、部品モジュールＢであるので、この時点での例題手順でのメモリ確保リストの内容は図８の（Ｄ）のようになり、Ｓ７０４で算出するメモリ量はＡ＿ｏｕｔ＋Ｂ＿ｏｕｔとなる。
以降、例題手順で動作順序を進めるたびに、Ｓ７０３でのメモリ確保リストの様子がどうなるかを図８の（Ｅ）〜（Ｇ）に示す。これらの場合のメモリ量は、それぞれ、Ａ＿ｏｕｔ＋Ｂ＿ｏｕｔ＋Ｃ＿ｏｕｔ、Ｂ＿ｏｕｔ＋Ｃ＿ｏｕｔ＋Ｄ＿ｏｕｔ、Ｂ＿ｏｕｔ＋Ｄ＿ｏｕｔ＋Ｅ＿ｏｕｔとなる。これらの算出されたメモリ量の中の最大のものが、例題手順でのメモリ量となる。ここで、部品モジュールＢ、Ｃ、Ｄ、Ｅの出力データ格納メモリ量をＢ＿ｏｕｔ、Ｃ＿ｏｕｔ、Ｄ＿ｏｕｔ、Ｅ＿ｏｕｔとしている。このようにして、動作順序のパターン毎にメモリ量が算出される。
【００２７】
以上のようにして、Ｓ３０４における消費リソース量の算出（取得）が行われる。Ｓ３０４では、動作順序のパターン毎に、処理時間、メモリ量、回路規模等が算出されることになる。この算出結果を動作順序パターン別消費リソース量と呼ぶ。図３の場合に関して、このようにして得られた動作順序パターン別消費リソース量を模式的に示した図を図９に示す。図９に示したようなリストを、動作順序パターン別消費リソース量リストと呼ぶ。図９では、ターゲット環境として、組み込みソフトウェアが設定された場合が例示されている（組み込みソフトウェアがターゲットなので、回路規模に関する消費リソース量は算出されていない）。上記で示した３種類の動作順序パターンに関して、それぞれメモリ量（ＭＥＭ＿１、ＭＥＭ＿２、ＭＥＭ＿３とした）、処理時間（ＴＩＭＥ＿１、ＴＩＭＥ＿２、ＴＩＭＥ＿３とした）が算出されている様子を示している。ただし、本実施形態においては、上述のようにＴＩＭＥ＿１、ＴＩＭＥ＿２、ＴＩＭＥ＿３は同じ値となる。
図５の説明に戻る。
Ｓ３０５において、消費リソース量算出部１０２は、優先リソースを最小にする動作順序パターンと、そのときの消費リソース量とを特定する。この特定された動作順序を優先動作順序パターンと呼ぶ。例えば、メモリ量が優先リソースに設定されていたなら、メモリ量が最小になるような動作順序パターンを優先動作順序パターンとする。消費リソース量算出部１０２は、動作順序パターン別消費リソース量と、優先動作順序パターンと、優先動作順序パターンのときの消費リソース量とを出力する。例えば、図９のＭＥＭ＿３が一番小さい値であったとすると、消費リソース量算出部１０２は、優先動作順序パターンとして動作順序パターン３を、そのときの消費リソース量として、ＭＥＭ＿３とＴＩＭＥ＿３とを出力する。
【００２８】
図２に示す設計変更可能箇所抽出部１０３は、許容リソース量設定部１０１から送られる許容リソース量と、消費リソース量算出部１０２から送られる消費リソース量とを比較する。そして、設計変更可能箇所抽出部１０３は、その比較結果に応じて、プログラム設計部１０８で設計されているプログラムで設計変更可能な箇所を抽出する。本実施形態では、消費リソース量の何れかのリソースが、許容リソース量の対応するリソース量を超えた場合に、設計変更可能箇所抽出部１０３が設計変更可能箇所の抽出を行うとする。設計変更可能箇所の抽出を行う目的は、消費リソース量を許容リソース量以下に納めることができるような部品モジュールの変更又は動作順序の変更を探索することである。
設計変更可能箇所の抽出は以下のように行われる。まず、設計変更可能箇所抽出部１０３は、プログラム設計部１０８から送られるプログラム構成情報から、今設計しているプログラムを構成する部品モジュールの一覧を得る。次に、設計変更可能箇所抽出部１０３は、それぞれの部品モジュールに関して、その代替部品モジュールの有無を部品モジュール情報管理データベース１０７にアクセスすることで判別する。部品モジュール情報管理データベース１０７に関する詳細については後述する。もし、代替部品モジュールが存在する部品モジュールがあれば、設計変更可能箇所抽出部１０３は、その情報をプログラム設計部１０８に送る。プログラム設計部１０８は、設計変更可能箇所抽出部１０３から代替部品モジュール情報が入力された場合には、代替部品モジュールを用いたプログラム構成情報を出力する。
【００２９】
図２に示す変更選択肢提示部１０４は、消費リソース量算出部１０２から送られてくる動作順序パターン別消費リソース量を変更選択肢として提示する。図３の場合では、動作順序パターンが３通りあるので、現在、優先動作順序パターンとなっている動作パターン以外の動作パターンに関する動作順序パターン別消費リソース量を選択肢として示す。また、消費リソース量算出部１０２は、代替部品モジュールを用いた場合のプログラム構成情報に対しても動作順序パターン別消費リソース量リストを作成する。そのため、それらが作成された場合には、変更選択肢提示部１０４は、代替部品モジュールを用いた場合の動作順序パターン別消費リソース量を選択肢として示す。このように、変更選択肢提示部１０４は、元のプログラムの動作順序パターン別消費リソース量リストと、元のプログラムの代替可能部品モジュールを代替部品モジュールで置き換えたプログラムに対する動作順序パターン別消費リソース量リストとを、変更選択肢として示す。
図２に示す設計変更選択部１０５は、変更選択肢提示部１０４から提示される変更選択肢から、今のプログラムに対する変更指示として適当なものを選択する。この際の選択の基準は予め定められており、例えば、設計変更選択部１０５は、許容リソース量設定部１０１で設定された許容リソース量に違反しない範囲内で、優先リソースが最小になるような選択肢を選択する。設計変更選択部１０５は、選択した選択肢に対応する動作順序や代替部品モジュールの使用をプログラム設計部１０８に指示する。
【００３０】
上述したように図２に示す消費リソース量管理データベース１０６には、部品モジュール毎の消費リソース量が管理されている。部品モジュール毎の消費リソース量は、何らかのプロファイル手法を用いて予め調査されているものとする。プロファイル手法は公知の手法でよい。
図１０に、消費リソース量管理データベース１０６で管理されている部品モジュール毎の消費リソース量の例を示す。図１０では、部品モジュールＡと部品モジュールＢとに対して管理されている消費リソース量を示している。消費リソース量は一般的にターゲット環境に応じて変化するので、ターゲット環境別に管理されている。また、消費リソース量がパラメータに応じて変化する場合には、パラメータ毎の消費リソース量、又はパラメータ化された消費リソース量として管理されている。例えば、部品モジュールＡが画像データに対して輝度変換を行うようなモジュールの場合、入力データ量、出力データ量は入力画像サイズに応じて変化する。このような場合には、入力データ量、出力データ量は入力画像サイズにパラメータ化されて管理される。また、消費リソース量のうち回路規模は、ターゲット環境として、ハードウェア化だった場合にしか関係ないので、組み込みＣＰＵがターゲットであった場合には、管理対象外となる。このようにターゲット環境によっては、管理されない消費リソース量も存在する。
【００３１】
また、上述したように図２に示す部品モジュール情報管理データベース１０７には、プログラム設計部１０８で使用する部品モジュールが管理されている。プログラム設計部１０８は、部品モジュール情報管理データベース１０７で管理している部品モジュールを組み合わせて、所望のプログラムを作成する。
更に、部品モジュール情報管理データベース１０７には、互いに代替部品モジュールとなっている部品モジュールも管理されている。従ってある部品モジュールに対して、その代替となりうる部品モジュールの有無を知ることができる。また、代替部品モジュールがある場合には、その代替部品モジュールを参照することができる。部品モジュール同士が代替部品モジュールとなりうるかどうかは、予め何らかの基準で調べて登録しておく。例えば、同一の入力データに対して、全く同一の出力を出す部品モジュールであれば、全て互いに代替部品モジュールとしてもよい。また、同一の入力データに対して、全く同一の出力を出さなくても、所定の誤差以内であれば、全て互いに代替部品モジュールとしてもよい。
以上が本発明によるプログラム設計支援装置の機能による動作の説明になる。
【００３２】
続いて本発明によるプログラム設計支援装置を使ったプログラム設計のフローについて説明する。図１１は、プログラム設計支援装置によるプログラム設計処理の一例を示すフローチャートである。
Ｓ１００１において、消費リソース量算出部１０２は、今から設計しようとしているプログラムが使用されるターゲット環境情報の設定を受け付ける。また、消費リソース量算出部１０２は、このプログラムを設計していくうえで最も気を遣うべきリソースを優先リソースとする設定を受け付ける。例えば組み込み機器をターゲット環境としており、搭載メモリ量が極めて少量であることが予想されるような場合には、メモリ量を優先リソースとすればよい。
Ｓ１００２において、許容リソース量設定部１０１は、ターゲット環境で許容されるリソース量を設定する。許容リソース量設定部１０１は、例えば処理時間、メモリ量、回路規模等に関して具体的な値を設定する。
Ｓ１００３において、プログラム設計部１０８は、部品モジュール情報管理データベース１０７で管理している部品モジュールを組み合わせて、所望のプログラムを作成する。
Ｓ１００４において、消費リソース量算出部１０２は、現在作成しているプログラムがターゲット環境で消費する消費リソース量を算出する。消費リソース量の算出手順は、消費リソース量算出部１０２の説明で詳述したのでここでは省略する。消費リソース量を算出するタイミングは特に問わない。例えば、プログラム設計に並行してリアルタイムで行われてもよいし、プログラムが完成した時点でもよいし、プログラムのあるまとまりが完成した時点でもよい。
【００３３】
Ｓ１００５において、設計変更可能箇所抽出部１０３は、現在設計しているプログラムがリソース違反を起こすものであるか否かを判定する。この判定は、設計変更可能箇所抽出部１０３が、算出された消費リソース量と設定された許容リソース量とを比較することで行う。両リソース量の比較は、消費リソース量と許容リソース量との間で対応するリソース同士にて行われる。図１１の例では、設計変更可能箇所抽出部１０３が、消費リソース量の何れかのリソース量が許容リソース量の対応するリソース量を超えるか否かを判定する。ただし、この比較方法に限らず、設計変更可能箇所抽出部１０３は、許容リソース量から消費リソース量を引いた量（リソースの余裕に相当する量）と、予め定められた閾値との比較を行うようにしてもよい。Ｓ１００５において、設計変更可能箇所抽出部１０３は、判定の結果、リソース違反を起こすものではないと判定すればＳ１００８に進み、プログラム完成かどうかをチェックする。一方、Ｓ１００５において、設計変更可能箇所抽出部１０３は、リソース違反を起こすものであると判定すればＳ１００６に進む。
Ｓ１００６において、設計変更可能箇所抽出部１０３は、プログラムで変更可能な代替部品モジュールの探索を行う。更に、消費リソース量算出部１０２は、今のプログラムで他の動作順序を想定したときの動作順序パターン別消費リソース量リストや、代替部品モジュールを用いたプログラムでの動作順序パターン別消費リソース量リストを算出する。そして、変更選択肢提示部１０４は、プログラム設計変更の選択肢として提示する。探索の結果、代替部品モジュールが複数見つかった場合には、消費リソース量算出部１０２は、それらを代替する／代替しないにおける全ての組み合わせにおいて、代替部品モジュールを用いたプログラムでの動作順序パターン別消費リソース量リストを算出する。
Ｓ１００７において、設計変更選択部１０５は、提示された選択肢のうちから最適なものを選択し、その選択に基づいてプログラムの変更を行う。即ち、設計変更選択部１０５は、その選択の結果を反映させてプログラムを変更する。選択の基準については上述したため、ここでの説明は省略する。消費リソース量算出部１０２は、変更されたプログラムについて、再度、消費リソース量を算出する。そして、設計変更選択部１０５は、再度Ｓ１００５に戻り、リソース違反のチェックを行う。
【００３４】
以上、上述したように、本発明によるプログラム設計支援装置を用いることで、プログラムを開発している時点で、そのプログラムが消費する消費リソース量を見積もることが可能となる。また、見積もった消費リソース量が、予め設定された許容リソース量を超えてしまった場合（又は、超えそうになった場合）に、その事態を回避するために、どのようにプログラム変更をすればよいかの選択肢を提示することができる。
また、プログラム設計者は、今設計しているプログラムがターゲット環境でどのくらいのリソースを消費することになるのかを知ることができるので、今設計しているプログラムの善し悪し（リソース量に関する善し悪し）を早期に判定することができる。これらのことから、プログラム開発時にそのアルゴリズム的な性能（例えば画像圧縮プログラムを作成しているのであれば圧縮率や復元画像の再現具合等）だけを追求してしまい、その結果生じる不便を解消することができる。より具体的には、プログラムが完成した後に、消費リソース量が許容リソース量を大幅に超過していることが判明し、大きな手戻りが発生する、というような事態を未然に防ぐことが可能となる。
なお、本実施形態では、部品モジュール毎の消費リソース量を管理している消費リソース量管理データベース１０６と、プログラム設計時に使用する部品モジュールや、代替部品モジュールの管理を行っている部品モジュール情報管理データベース１０７とを別のデータベースとして説明したが、この二つを単一の共通のデータベースとしてもよい。
【００３５】
＜実施形態２＞
実施形態１では、消費リソース量算出部１０２での動作順序パターンの抽出において、複数の部品モジュールが同時に動作するような動作順序（並列処理動作）を考慮しない場合の例を示した。本実施形態では、並列動作順序を考慮する場合の例を示す。本実施形態と実施形態１とで異なるのは、消費リソース量算出部１０２において、動作順序パターン別消費リソース量リストを算出する手順だけである。従ってその部分を中心に説明を行い、それ以外の説明は省略する。
本実施形態での消費リソース量算出部１０２における動作順序パターンの抽出では、実施形態１で示した直列処理動作の動作順序パターンの抽出に加えて、並列動作順序の動作順序パターンも抽出する。また、それに伴って、消費リソース量算出部１０２は、並列動作順序の場合の消費リソース見積もりも行う。消費リソース量算出部１０２が並列動作順序の抽出を行うのは、ターゲット環境として、ハードウェア化を想定している場合や、マルチコアのプロセッサを想定している場合等である。
【００３６】
図１２は、本実施形態における消費リソース量算出部１０２の処理の一例を示すフローチャートである。本実施形態での消費リソース量算出部１０２の動作フローは、実施形態１で示した図５のＳ３０３及びＳ３０４の処理が、Ｓ１１０１、Ｓ１１０２及びＳ１１０３の処理に置き換わったものである。それ以外の処理は同じなので、同じ符号を付与し、ここでの説明を省略する。
Ｓ１１０１において、消費リソース量算出部１０２は、並列動作可能（同時動作可能）な部品モジュールの抽出を行う。そのためにまず、消費リソース量算出部１０２は、プログラム構成情報を用いて、プログラムの入力から部品モジュールを下流側に辿っていき経路部品モジュールリストを作成する。消費リソース量算出部１０２は、途中で分岐があると（複数の接続先を持つ部品モジュールがあると）、分岐毎に、下流側部品モジュールのリストを作成する。例えば図３のようなプログラムの場合（図４のようなプログラム構成情報の場合）、消費リソース量算出部１０２は、プログラムの入力から下流側に部品モジュールを辿っていく。部品モジュールＡの出力には２つの部品モジュールが接続されている（即ち分岐が発生している）ので、消費リソース量算出部１０２は、分岐それぞれ毎に経路部品モジュールリストを作成する。この場合、経路部品モジュールリストが２系統作成され、それぞれ「入力⇒Ａ⇒Ｂ⇒Ｅ⇒出力」と、「入力⇒Ａ⇒Ｃ⇒Ｄ⇒Ｅ⇒出力」とになる。
【００３７】
次に、消費リソース量算出部１０２は、それぞれの経路部品モジュールリストを突き合わせて、２つ以上の経路部品モジュールリストに共通に属している部品モジュール系列（共通系列と呼ぶ）を抽出する。抽出された共通系列のうち、経路部品リスト上で第３の共通系列を跨がない２つの共通系列の間が並列処理可能な部品モジュールとなる。例えば図３の場合には、「入力⇒Ａ」と「Ｅ⇒出力」との２つの共通系列が抽出される。従ってその間のＢとＣ、Ｄとが並列処理可能な部品モジュール対となる。
Ｓ１１０１での動作の理解を助けるために、図１３の（Ａ）、（Ｂ）に示す別のプログラムの場合に並列動作可能な部品モジュールの抽出を行う例を示す。
まず、図１３の（Ａ）では、経路部品リストが４系統作成される。それぞれ、系統１：「入力⇒Ａ⇒Ｂ⇒Ｅ⇒Ｇ⇒出力」と、系統２：「入力⇒Ａ⇒Ｂ⇒Ｅ⇒Ｆ⇒出力」と、系統３：「入力⇒Ａ⇒Ｃ⇒Ｄ⇒Ｅ⇒Ｇ⇒出力」と、系統４：「入力⇒Ａ⇒Ｃ⇒Ｄ⇒Ｅ⇒Ｆ⇒出力」とになる。系統１と系統２との共通系列は「入力⇒Ａ⇒Ｂ⇒Ｅ」と「出力」とになるので、その間のＦとＧとが並列動作可能な部品モジュール対となる。系統１と系統３との共通系列は「入力⇒Ａ」と「Ｅ⇒Ｇ⇒出力」とになるので、その間のＢとＣ、Ｄとが並列動作可能な部品モジュール対となる。系統１と系統４との場合は、「入力⇒Ａ」と「Ｅ」と「出力」との３つの共通系列が得られる。このうち経路部品リスト上で第３の共通系列を跨がない２つの共通系列の間が並列処理可能な部品モジュール対となる。従って、共通系列である「入力⇒Ａ」と「Ｅ」の間のＢとＣ、Ｄとが並列動作可能な部品モジュール対となり、更に共通系列である「Ｅ」と「出力」の間のＦとＧとが並列動作可能な部品モジュール対となる。共通系列である「入力⇒Ａ」と「出力」との間には第３の共通系列「Ｅ」があるので、消費リソース量算出部１０２は、「入力⇒Ａ」と「出力」との間では並列動作可能な部品モジュールの抽出を行わない。続いて、消費リソース量算出部１０２は、系統２と系統３、系統２と系統４、系統３と系統４に関しても、同様の手順で並列動作可能な部品モジュールの抽出を行う。
【００３８】
続いて図１３の（Ｂ）では、経路部品リストが３系統作成され、それぞれ、系統１：「入力⇒Ａ⇒Ｂ⇒Ｅ⇒Ｇ⇒出力」と、系統２：「入力⇒Ａ⇒Ｃ⇒Ｄ⇒Ｅ⇒Ｇ⇒出力」と、系統３：「入力⇒Ａ⇒Ｆ⇒Ｇ⇒出力」とになる。
系統１と系統２との共通系列は「入力⇒Ａ」と「Ｅ⇒Ｇ⇒出力」とになるので、その間のＢとＣ、Ｄとが並列動作可能な部品モジュール対となる。系統１と系統３との共通系列は「入力⇒Ａ」と「Ｇ⇒出力」とになるので、その間のＢ、ＥとＦとが並列動作可能な部品モジュール対となる。系統２と系統３との共通系列は「入力⇒Ａ」と「Ｇ⇒出力」とになるので、その間のＣ、Ｄ、ＥとＦとが並列動作可能な部品モジュール対となる。
Ｓ１１０１では、以上のようにして並列動作可能なモジュールの抽出が行われる。
【００３９】
Ｓ１１０２において、消費リソース量算出部１０２は、並列動作順序を含む動作順序のパターンを全て抽出する。動作順序パターンの抽出の手順は以下のように行われる。
まず、Ｓ１１０１で抽出した並列処理可能部品モジュールを括りだして一つの部品モジュールとし、新たなプログラム構成情報を作成する。例えば図３に示すプログラムの場合、前述のようにＳ１１０１にてＢとＣ、Ｄとが並列動作可能部品モジュール対として抽出される。このＢとＣ、Ｄとを新たな部品モジュールＢ＿ＣＤとして括りだした図を図１４に示す（図１４の点線で示した部品モジュールが部品モジュールＢ＿ＣＤを示す）。更に、図１５に図１４のプログラムのプログラム構成情報を示す。
続いて、消費リソース量算出部１０２は、新たに作成したプログラム構成情報を用いて動作順序パターンの抽出を行う。この場合、並列動作可能部品モジュールは、新たに作成した部品モジュール内に存在し、明には出てこないので、実施形態１で説明したＳ３０３の場合と同じ手順で動作順序パターンの抽出が行える。図１５の場合、動作順序パターンとして「入力⇒Ａ⇒Ｂ＿ＣＤ⇒Ｅ⇒出力」という動作順序パターンが抽出される。
【００４０】
次に、消費リソース量算出部１０２は、並列動作可能部品モジュールの動作順序パターン、即ち新たに作成した部品モジュール内の動作順序パターンを抽出する。消費リソース量算出部１０２は、新たに作成した部品モジュール内の動作順序パターンの抽出を、並列動作順序を含む場合と、含まない場合とに分けて行う。
並列動作順序を含まない場合の動作順序パターンの抽出は、実施形態１で説明したＳ３０３の場合と同じなので、ここでの説明を省略する。図１４に示す部品モジュールＢ＿ＣＤの場合、「Ｂ⇒Ｃ⇒Ｄ」と「Ｃ⇒Ｂ⇒Ｄ」と「Ｃ⇒Ｄ⇒Ｂ」との３通りが抽出される。
並列動作順序を含む場合の動作順序パターンの抽出は、並列動作可能な部品モジュール同士に対して、全ての並列動作の組み合わせを設定して行う。例えば部品モジュールＢ＿ＣＤの場合には、ＢとＣ、Ｄとが並列処理可能なので、全ての並列動作の組み合わせは、「ＢとＣとが並列動作」の場合と、「ＢとＤとが並列動作」の場合と、「ＢとＣ⇒Ｄとが並列動作」の場合との３通り考えられる。従って、動作順序パターンとしては、「［Ｂ／Ｃ］⇒Ｄ」と「Ｃ⇒［Ｂ／Ｄ］」と「［Ｂ／Ｃ⇒Ｄ］」とが考えられる。ここで［  ］の記号で囲まれている部分は／の記号の前後の部品モジュールが並列動作することを示している。
【００４１】
次に、消費リソース量算出部１０２は、並列動作可能部品モジュールを明に含まない動作順序パターンと、並列動作可能部品モジュールの動作順序パターンとを組み合わせて、全体の動作順序パターンを作成する。図１４のような場合には、並列動作可能部品モジュールを明に含まない動作順序パターンとして、「入力⇒Ａ⇒Ｂ＿ＣＤ⇒Ｅ⇒出力」が抽出される。更に並列動作可能部品モジュールの動作順序パターンとして、「Ｂ⇒Ｃ⇒Ｄ」、「Ｃ⇒Ｂ⇒Ｄ」、「Ｃ⇒Ｄ⇒Ｂ」、「［Ｂ／Ｃ］⇒Ｄ」、「Ｃ⇒［Ｂ／Ｄ］」、「［Ｂ／Ｃ⇒Ｄ］」の６通りが抽出される。従って、これらを組み合わせて、「入力⇒Ａ⇒Ｂ⇒Ｃ⇒Ｄ⇒Ｅ⇒出力」、「入力⇒Ａ⇒Ｃ⇒Ｂ⇒Ｄ⇒Ｅ⇒出力」、「入力⇒Ａ⇒Ｃ⇒Ｄ⇒Ｂ⇒Ｅ⇒出力」、「入力⇒Ａ⇒［Ｂ／Ｃ］⇒Ｄ⇒Ｅ⇒出力」、「入力⇒Ａ⇒Ｃ⇒［Ｂ／Ｄ］⇒Ｅ⇒出力」、「入力⇒Ａ⇒［Ｂ／Ｃ⇒Ｄ］⇒Ｅ⇒出力」の６通りが動作順序パターンとして抽出される。
【００４２】
Ｓ１１０１の説明のときと同様、Ｓ１１０２の動作の理解を助けるために、図１３の（Ａ）、（Ｂ）に示す別のプログラムの場合に動作順序パターンの抽出を行う例を示す。
図１３の（Ａ）のプログラムから、並列処理可能部品モジュールを括りだして一つの部品モジュールとしたプログラムを図１６に示す。図１３の（Ａ）に示すプログラムの場合、ＢとＣ、Ｄ並びにＦとＧとが並列動作可能部品モジュール対として抽出されるので、それぞれを部品モジュールＢ＿ＣＤ並びに部品モジュールＦ＿Ｇとしている。
図１６の場合には、並列動作可能部品モジュールを明に含まない動作順序パターンとして、「入力⇒Ａ⇒Ｂ＿ＣＤ⇒Ｅ⇒Ｆ＿Ｇ⇒出力」が抽出される。更に部品モジュールＢ＿ＣＤ内の並列動作可能部品モジュールの動作順序パターンとして、「Ｂ⇒Ｃ⇒Ｄ」、「Ｃ⇒Ｂ⇒Ｄ」、「Ｃ⇒Ｄ⇒Ｂ」、「［Ｂ／Ｃ］⇒Ｄ」、「Ｃ⇒［Ｂ／Ｄ］」、「［Ｂ／Ｃ⇒Ｄ］」の６通りが抽出され、部品モジュールＦ＿Ｇ内の並列動作可能部品モジュールの動作順序パターンとして、「Ｇ⇒Ｆ」、「Ｆ⇒Ｇ」、「［Ｇ／Ｆ］」の３通りが抽出される。全体の動作順序パターンを抽出する場合には、これらの全組合せになるので、６×３＝１８通りの動作順序パターンが抽出される。
【００４３】
更に同様に、図１３の（Ｂ）のプログラムから、並列処理可能部品モジュールを括りだして一つの部品モジュールとしたプログラムを図１７の（Ａ）、（Ｂ）、（Ｃ）に示す。図１３の（Ｂ）に示すプログラムの場合、ＢとＣ、Ｄ並びにＢ、ＥとＦ並びにＣ、Ｄ、ＥとＦが並列動作可能部品モジュール対として抽出されるので、それぞれを部品モジュールＢ＿ＣＤ並びに部品モジュールＢＥ＿Ｆ並びに部品モジュールＣＤＥ＿Ｆとしている。図１３の（Ｂ）の場合は、複数の並列動作可能部品モジュール対に属する部品モジュール（例えば部品モジュールＢ）が存在するため、一つの図に表現できないので、図１７の（Ａ）、（Ｂ）、（Ｃ）のように並列動作可能部品モジュール対毎に別々に表現している。
図１７の（Ｂ）、（Ｃ）に関しては、これまで述べたように、並列動作可能部品モジュールを明に含まない動作順序パターンと、並列動作可能部品モジュールの動作順序パターンとを組み合わせて、全体の動作順序パターンを作成すればよい。例えば図１７の（Ｂ）に関しては、並列動作可能部品モジュールを明に含まない動作順序パターンとして、「入力⇒Ａ⇒Ｃ⇒Ｄ⇒ＢＥ＿Ｆ⇒Ｇ⇒出力」が抽出される。更に並列動作可能部品モジュールの動作順序パターンとして、「Ｂ⇒Ｅ⇒Ｆ」、「Ｂ⇒Ｆ⇒Ｅ」、「Ｆ⇒Ｂ⇒Ｅ」、「［Ｂ／Ｆ］⇒Ｅ」、「Ｂ⇒［Ｅ／Ｆ］」、「［Ｆ／Ｂ⇒Ｅ］」の６通りが抽出される。消費リソース量算出部１０２は、全体の動作順序パターンを抽出するには、これらの全組合せを抽出すればよい。
【００４４】
図１７の（Ａ）に関しては、この状態で更に並列動作可能部品モジュールが抽出できるので、まずはそれを行う。図１７の（Ａ）に対して、並列動作可能部品モジュールの抽出を行うと、Ｂ＿ＣＤ、ＥとＦが並列動作可能部品モジュール対として抽出される。これらの並列処理可能部品モジュールを括りだして一つの部品モジュール（部品モジュールαとする）する。この状態で、消費リソース量算出部１０２は、並列動作可能部品モジュールを明に含まない動作順序パターンと、並列動作可能部品モジュールの動作順序パターンとを組み合わせて、全体の動作順序パターンを作成すればよい。この場合、並列動作可能部品モジュールを明に含まない動作順序パターンとして、「入力⇒Ａ⇒α⇒Ｇ⇒出力」が抽出される。更に並列動作可能部品モジュールの動作順序パターンとして、「Ｂ＿ＣＤ⇒Ｅ⇒Ｆ」、「Ｂ＿ＣＤ⇒Ｆ⇒Ｅ」、「Ｆ⇒Ｂ＿ＣＤ⇒Ｅ」、「［Ｂ＿ＣＤ／Ｆ］⇒Ｅ」、「Ｂ＿ＣＤ⇒［Ｅ／Ｆ］」、「［Ｆ／Ｂ＿ＣＤ⇒Ｅ］」の６通りが抽出される。ただし、Ｂ＿ＣＤは内部に更に並列動作可能部品モジュールを含むので、更にその動作パターン「Ｂ⇒Ｃ⇒Ｄ」、「Ｃ⇒Ｂ⇒Ｄ」、「Ｃ⇒Ｄ⇒Ｂ」、「［Ｂ／Ｃ］⇒Ｄ」、「Ｃ⇒［Ｂ／Ｄ］」、「［Ｂ／Ｃ⇒Ｄ］」を組み合わせる必要がある。
Ｓ１１０２では、以上のようにして動作順序パターンの抽出が行われる。
【００４５】
Ｓ１１０３において、消費リソース量算出部１０２は、動作順序パターン毎の消費リソース量を見積る。見積もりの手順は、実施形態１の場合と基本的に同じであるが、本実施形態では並列動作が考慮されているので、その点が異なる。ここでは異なる点を中心に説明する。
消費リソース量算出部１０２は、処理時間に関する消費リソース量を算出する場合には、Ｓ３０２で取得した部品モジュール毎の消費リソース量に含まれる処理時間を、Ｓ１１０２で抽出した動作順序に従って加算していくことにより算出できる。このとき、消費リソース量算出部１０２は、動作順序中に並列動作が含まれている場合には、並列動作する部品モジュール同士の処理時間を比較し、大きいほうだけを加算する。例えば、図３のプログラムの場合には、並列動作を含む動作順序パターンは、「入力⇒Ａ⇒［Ｂ／Ｃ］⇒Ｄ⇒Ｅ⇒出力」、「入力⇒Ａ⇒Ｃ⇒［Ｂ／Ｄ］⇒Ｅ⇒出力」、「入力⇒Ａ⇒［Ｂ／Ｃ⇒Ｄ］⇒Ｅ⇒出力」の３通りがある。ここで、消費リソース量算出部１０２は、［Ｂ／Ｃ］に関して処理時間を算出する場合は、部品モジュールＢと部品モジュールＣの処理時間のうち大きい方の値を用いる。［Ｂ／Ｄ］についても同様である。［Ｂ／Ｃ⇒Ｄ］では、部品モジュールＢの処理時間と、部品モジュールＣと部品モジュールＤの処理時間の合算値との比較を行い、大きい方の値を用いる。
【００４６】
Ｓ１１０３において、消費リソース量算出部１０２がメモリ量に関する消費リソース量を算出する場合の手順も、基本的には、図７に示したものと同じである。ただし、本実施形態では、ある部品モジュールの出力データに対して、並列動作する部品モジュールが同時にアクセスするような動作順序が存在する場合がある。その場合には、出力データに対して全ての並列動作する部品モジュールが同時にアクセスできるように、出力データ格納メモリを複数用意する必要がある。
例えば、図３のプログラムの場合の動作順序パターンが、「入力⇒Ａ⇒［Ｂ／Ｃ］⇒Ｄ⇒Ｅ⇒出力」や「入力⇒Ａ⇒［Ｂ／Ｃ⇒Ｄ］⇒Ｅ⇒出力」の場合には、部品モジュールＡの出力データに対して部品モジュールＢと部品モジュールＣとが同時にアクセスすることになる。この場合、同時アクセスを可能にするために、部品モジュールＡの出力データ格納メモリを２つ用意し、それぞれに出力データを格納するようにする。このような同時アクセスが発生するか否かは、プログラム構成情報と動作順序パターンとから判定できる。即ち、プログラム構成情報から部品モジュールＡの出力は、部品モジュールＢと部品モジュールＣとに接続していることがわかる。更に動作順序パターンから部品モジュールＢと部品モジュールＣとは同時に動作することがわかる。この両者から、この動作順序パターンでは、部品モジュールＡの出力データに対して部品モジュールＢと部品モジュールＣとが同時にアクセスすることになることが判明する。
【００４７】
本実施形態の場合における図７の手順を、実施形態１との違いをメインに説明する。動作理解を助けるために、図３において、消費リソース量算出部１０２が、「入力⇒Ａ⇒［Ｂ／Ｃ］⇒Ｄ⇒Ｅ⇒出力」で示される動作順序に関してメモリ量を算出している場合の手順を例題手順として説明する。
まず、Ｓ７０１、Ｓ７０２の処理は実施形態１と同じである。この時点でのメモリ確保リストの内容を図１８の（Ａ）に示す。
Ｓ７０３において、消費リソース量算出部１０２は、次に動作させる部品モジュールの出力データ格納メモリをメモリ確保リストに登録する。ただし、消費リソース量算出部１０２は、この出力データ格納メモリに対して、複数の部品モジュールからの同時アクセスが発生する場合には、その同時アクセス分の出力データ格納メモリをメモリ確保リストに登録する。例題手順では、次に動作させる部品モジュールである部品モジュールＡの出力データ格納メモリは上述のように２つの部品モジュールからの同時アクセスが発生するので、消費リソース量算出部１０２は、２つ分の出力データ格納メモリをメモリ確保リストに登録する。このときのメモリ確保リストの内容を図１８の（Ｂ）に示す。
【００４８】
Ｓ７０４において、消費リソース量算出部１０２は、現時点でメモリ確保リストに登録されているメモリ量を算出する。例題手順では、メモリ確保リストは図１８の（Ｂ）のようになっているので、メモリ量は、Ａ＿ｉｎ＋２×Ａ＿ｏｕｔとなる。
Ｓ７０５において、消費リソース量算出部１０２は、動作順序を一つ進める。例題手順では、部品モジュールＡの動作が済んだとするので、このときの例題手順でのメモリ確保リストの内容は図１８の（Ｃ）のようになる。
Ｓ７０６、Ｓ７０７において、消費リソース量算出部１０２は、Ｓ７０５で算出したメモリ量が最大メモリ量より大きければ、最大メモリ量を更新する。
Ｓ７０８において、消費リソース量算出部１０２は、動作順序が最後まで進んだかをチェックし、最後まで進んでいなければ、Ｓ７０３に戻り、次に動作させる部品モジュールに関する手順を続ける。次に動作するのは部品モジュールＢと部品モジュールＣなので、この時点での例題手順でのメモリ確保リストの内容は図１８の（Ｄ）のようになり、Ｓ７０４で消費リソース量算出部１０２が算出するメモリ量は２×Ａ＿ｏｕｔ＋Ｂ＿ｏｕｔ＋Ｃ＿ｏｕｔとなる。以降、例題手順で動作順序を進める度に、Ｓ７０３でのメモリ確保リストの様子がどうなるかを図１８の（Ｅ）〜（Ｆ）に示す。これらの場合のメモリ量は、それぞれ、Ｂ＿ｏｕｔ＋Ｃ＿ｏｕｔ＋Ｄ＿ｏｕｔ、Ｂ＿ｏｕｔ＋Ｄ＿ｏｕｔ＋Ｅ＿ｏｕｔとなる。これらの算出されたメモリ量の中で最大のものが、例題手順でのメモリ量となる。
Ｓ１１０３では、以上のようにして動作順序パターン毎の消費リソース量の算出が行われる。
【００４９】
以上、消費リソース量算出部１０２は、並列動作する部品モジュールがある場合には、それらを考慮して消費リソース量を算出し、動作順序パターン別消費リソース量リストを算出することができる。即ち、本発明によるプログラム設計支援装置は、並列動作する部品モジュールを考慮してプログラムの設計を支援することができる。
【００５０】
＜実施形態３＞
実施形態１では、設計変更可能箇所抽出部１０３における設計変更可能箇所の抽出において、設計中のプログラムで使用している部品モジュール毎に代替部品モジュールの有無をチェックしていた。しかしながら、本発明による設計変更可能箇所の抽出はこれに限るものではない。設計変更可能箇所抽出部１０３は、設計中のプログラムで使用している部品モジュール群（複数の部品モジュールで構成されている）毎に、代替部品モジュールの有無をチェックするようにしてもよい。その場合には、部品モジュール情報管理データベース１０７には、互いに代替部品モジュールとなっている部品モジュール群も管理されるようにすればよい。
例えば図３に示すようなプログラムの場合に、設計変更可能箇所抽出部１０３は、部品モジュールＣと部品モジュールＤとに対して代替部品モジュールのチェックを行うようにしてもよい。このとき、部品モジュール情報管理データベース１０７において、部品モジュールＣと部品モジュールＤとに対する代替部品モジュールとして部品モジュールβが管理されていたとする。その場合、設計変更可能箇所抽出部１０３は、部品モジュールＣと部品モジュールＤとに対する代替部品モジュール情報として部品モジュールβを出力すればよい。このような場合には、代替される対象の部品モジュールである部品モジュールＣと部品モジュールＤとの間の接続状態（部品モジュールＣの出力を部品モジュールＤの入力とする等）も含めて、部品モジュール情報管理データベース１０７で管理しておくことになる。
【００５１】
また、逆に設計中のプログラムで使用している部品モジュールに対して管理されている代替部品モジュールが複数の部品モジュールから構成されるものであってもよい。例えば図３に示すようなプログラムの場合に、部品モジュール情報管理データベース１０７において、部品モジュールＣに対する代替部品モジュールとして部品モジュールγと部品モジュールδとが管理されていたとする。その場合、設計変更可能箇所抽出部１０３は、部品モジュールＣに対する代替部品モジュール情報として部品モジュールγと部品モジュールδとを出力すればよい。このような場合には、部品モジュール情報管理データベース１０７で、部品モジュールγと部品モジュールδとの間の接続状態（部品モジュールγの出力を部品モジュールδの入力とする等）も含めて代替部品モジュールとして管理しておくことになる。
更には、上記の２つの場合が組み合わされたような場合も考えられる。即ち、設計中のプログラムで使用している部品モジュール群毎に管理されている代替部品モジュールが複数の部品モジュールから構成されるものであってもよい。
【００５２】
このように、複数の部品モジュールを組み合わせたり、逆に複数の部品モジュールに分解したりすることによって、その部品モジュール（群）が実現する処理に対する最適化が行いやすくなり、消費リソース量が変化することが考えられる。従って、設計変更の選択肢としてこのような場合を考慮しておけば、本発明をより有効に活用できる。例えば、画像データに対して２次元ガウスフィルター処理を行う部品モジュールがあった場合、それを一次元ガウスフィルターを行う部品モジュール２つ（縦方向のフィルター処理と横方向のフィルター処理）に分解すると、処理速度が変化することが考えられる。
また、カラー画像データに対してグレイスケール変換する部品モジュールと縮小処理を行う部品モジュールとが直列に適用されているような場合、これら２つの部品モジュールの代替モジュールとして、縮小処理を行う部品モジュールとグレイスケール変換する部品モジュールとを直列に接続したもの（部品モジュールの順序を逆にしたもの）が適用されてもよい。この場合、代替モジュールに変更すれば、縮小処理が最初に行われるので、メモリ量に関してもとの場合より有利になることが予想される。
【００５３】
＜その他の実施形態＞
上述した実施形態では、リソースの種類として、メモリ量、処理時間、回路規模を例に挙げて説明を行ったが、本発明が対象とするリソースの種類はこれらに限らない。ある処理を実行するのに必要な空間的、時間的資源であればどのようなものでもよい。
また、ターゲット環境も上述した実施形態中に挙げたものに限らない。例えば、クラウド環境がターゲット環境となってもよい。
また、上述した実施形態では、モデルベース開発手法を用いるプログラム開発を行う場合に本発明によるプログラム設計支援装置を用いる例を示したが、プログラムの開発手法はこれに限らない。通常のソースコードベースのプログラム開発に対して、本発明によるプログラム設計支援装置を用いてもよい。その場合には、関数等で表現される処理の塊を部品モジュールとすればよい。
【００５４】
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００５５】
以上、上述した各実施形態によれば、プログラム開発において、消費リソース量が許容リソース量を満たすプログラムの設計を支援する技術を提供することができる。
より具体的には、プログラムを開発している時点で、そのプログラムが消費する消費リソース量を見積もることが可能となる。また、見積もった消費リソース量が、予め設定された許容リソース量を超えてしまった場合（又は、超えそうになった場合）に、その事態を回避するために、どのようにプログラム変更すればよいかを提示することができる。これにより、従来、実際にターゲットとなる環境でプログラムを動かしてみるまで困難であったリソース量の予測が可能になり、更に、問題が発生しそうになった場合には回避方法も提示されるので、プログラム開発の手戻りを防止することができる。
【００５６】
以上、本発明の好ましい形態について詳述したが、本実施形態は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００５７】
１０１  許容リソース量設定部、１０２  消費リソース量算出部、１０３  設計変更可能箇所抽出部、１０４  変更選択肢提示部、１０５  設計変更選択部、１０６  消費リソース量管理データベース、１０７  部品モジュール情報管理データベース、１０８  プログラム設計部
【図１】
2016018269.tif 000003
【図２】
2016018269.tif 000004
【図３】
2016018269.tif 000005
【図４】
2016018269.tif 000006
【図５】
2016018269.tif 000007
【図６】
2016018269.tif 000008
【図７】
2016018269.tif 000009
【図８】
2016018269.tif 000010
【図９】
2016018269.tif 000011
【図１０】
2016018269.tif 000012
【図１１】
2016018269.tif 000013
【図１２】
2016018269.tif 000014
【図１３】
2016018269.tif 000015
【図１４】
2016018269.tif 000016
【図１５】
2016018269.tif 000017
【図１６】
2016018269.tif 000018
【図１７】
2016018269.tif 000019
【図１８】
2016018269.tif 000020