プロセッサ、アクラセレータ、またはコントローラを含む、バスマスタがメモリにアクセスし得るシステムにおいて、シミュレーションモデルが表しているプログラムの動作時に、前記バスマスタによるメモリアクセス競合を評価する方法であって、前記シミュレーションモデルについて、シミュレーションステップ毎の実行時間及びメモリアクセス回数を、前記異なるバスマスタ毎に測定し、あるいは測定値を事前に用意するステップと、前記実行時間及びメモリアクセス回数の値を用いて、メモリ帯域の利用率を、前記異なるバスマスタ毎に計算するステップと、前記異なるバスマスタ毎のメモリ帯域の利用率の積を含む式により、前記異なるバスマスタの間のメモリアクセス競合の確率を計算するステップを有する、メモリアクセス競合の確率を評価する方法。前記計算されたメモリアクセス競合の確率に基づき、メモリアクセス競合の結果の実行時間を評価するステップをさらに有する、請求項1に記載の方法。シミュレーションステップ毎の前記メモリ帯域の利用率Uは、Tをステップ時間、Nrを読取りアクセスの回数、Nwを書込みアクセスの回数、Wrを単位時間毎に利用可能な読取りアクセスの最大数、Wwを単位時間毎に利用可能な書込みアクセスの最大数とすると、UTTで計算される、請求項1に記載の方法。プロセッサ、アクラセレータ、またはコントローラを含む、バスマスタがメモリにアクセスし得るコンピュータシステムにおいて、シミュレーションモデルが表しているプログラムの動作時に、前記バスマスタによるメモリアクセス競合を評価するプログラムであって、前記コンピュータシステムに、前記シミュレーションモデルについて、シミュレーションステップ毎の実行時間及びメモリアクセス回数を、前記異なるバスマスタ毎に測定し、あるいは測定値を事前に用意するステップと、前記実行時間及びメモリアクセス回数の値を用いて、メモリ帯域の利用率を、前記異なるバスマスタ毎に計算するステップと、前記異なるバスマスタ毎のメモリ帯域の利用率の積を含む式により、前記異なるバスマスタの間のメモリアクセス競合の確率を計算するステップを実行させる、メモリアクセス競合の確率を評価するプログラム。前記計算されたメモリアクセス競合の確率に基づき、メモリアクセス競合の結果の実行時間を評価するステップをさらに有する、請求項4に記載のプログラム。シミュレーションステップ毎の前記メモリ帯域の利用率Uは、Tをステップ時間、Nrを読取りアクセスの回数、Nwを書込みアクセスの回数、Wrを単位時間毎に利用可能な読取りアクセスの最大数、Wwを単位時間毎に利用可能な書込みアクセスの最大数とすると、UTTで計算される、請求項4に記載のプログラム。アプリケーションと、プロセッサ及びメモリをもち該アプリケーションを実行するためのプラットフォームと、メモリアクセス検出モジュールと、ステップ開始/終了検出モジュールを有する組込みシステムの性能をシミュレーションするための計算を行うプログラムであって、前記メモリアクセス検出モジュールと前記ステップ開始/終了検出モジュールから出力されたデータに基づき、請求項4に記載のプログラムを用いて計算するステップを有する、シミュレーションプログラム。上記従来の技法は、テストするメモリアクセスパターンの網羅性、測定のベースとなるデータを事前準備するためのコストの大きさ、シミュレーション結果に基づき実行速度を推定するための計算量の膨大さなどの点で十分でなかった。従って、本発明の目的は、詳細なメモリアクセスパターンを必要とせず、アプリケーションのモデリングに十分な粒度で且つ妥当な計算量で、メモリアクセス競合の確率を計算することを可能ならしめる技法を提供することにある。この発明の他の目的は、そのように計算されたメモリアクセス競合の確率に基づき、メモリアクセス競合の結果の、プログラムの実行時間を推測する技法を提供することにある。本発明は、上記課題を解決するもので、アプリケーションレベルの振る舞いを、イベントドリブンのシミュレーションで表現するとともに、より粒度の小さいメモリアクセスタイミングを統計的に近似して、ステップ実行時間予測を得る予測技法を提供する。本発明は、様々なデータを入力して計算し、値を出力する、コンピュータシステム上で動作するソフトウェアとして実現される。本発明は、上記のイベントドリブンのシミュレーションを含む、粒度の粗いシステムアーキテクチャモデルに適用可能であって、当該モデルのシミュレーションステップにおける、実行時間Tと、メモリアクセスの回数Nを入力とする。そこで、メモリの同期的アクセスと調停を考慮に入れ、各メモリアクセスの正確なタイミングの情報なしでメモリアクセス競合の効果を評価あるいは推測し、多くの代替アーキテクチャと比較するのに十分なシミュレーション速度で、メモリアクセス競合時の各種の推定値を得る。このシミュレーションの結果得られるのは、メモリアクセス競合の下でのシミュレーションステップの推定実行時間Tと、メモリアクセス競合の下での各シミュレーションステップのメモリ帯域の利用率Uiである。以上のことを、数式を用いてもう少し厳密に説明すると次のとおりである。まず、メモリ帯域の利用率は、次のように表される。UWここで、Wは、共有メモリに対する、単位時間毎に利用可能なメモリアクセスの最大数である。尚、メモリアクセスのreadとwriteの速度が異なる場合は、UNrTWrNwTWwの式を用いると、より正確に計算される。ここで、Nrはメモリ読取り回数、Nwはメモリ書込み回数、Wrは単位時間毎に利用可能な読取りアクセスの最大数、Wwは単位時間毎に利用可能な書込みアクセスの最大数である。PcPcここで、cは衝突パターンのインデックスであり、M個のプロセッサが存在すると、2M個の衝突パターンが存在する。また、Uiは、i番目のプロセッサの上で走るステップのメモリ帯域利用率である。そこで、N1と想定すると、Pcから、メモリアクセス競合の効果による1ステップの実行時間Tiを、次の式で評価する。ここで、Aciは、i番目のプロセッサにつき、衝突がない場合のメモリアクセスの待ち時間に対する、衝突パターンcの場合のメモリアクセスの待ち時間の比である。メモリアクセス競合の下でのメモリ帯域利用率Uiは次の式で評価される。この発明によれば、主としてモデルのシミュレーションステップにおける、実行時間Tと、メモリアクセスの回数Nを入力として、実行時間とメモリアクセス競合を妥当な計算量で求めることができるので、設計モデルの粗い段階でも、さまざまなアーキテクチャに対して、実行時間とメモリ帯域利用率を見積もって、どれが妥当なアーキテクチャを迅速に判定することが可能となる。本発明の実施例を説明する前に、何故、組み込みシステムの設計空間探索に、命令セットシミュレータISSを使用するだけではうまくいかないのかを説明する。組み込みシステムにおいては、ハードウェアとソフトウェアの両方を設計する必要があり、ハードウェアとソフトウェアのコンポーネントが増大するにつれて、考慮すべき代替アーキテクチャの数も指数関数的に増加する。組み込みシステムにおいては、ASICやSoCが、製品能力の源である。一方で、製造コスト、電力消費などの多くの制約がある。例えば、3個のソフトウェアコンポーネントを、2つのコアと、3つのメモリ領域に割り当てるとして、216の代替アーキテクチャがあるとする。1つの製品の1つのテストに1分かかるとする。テストパターンは100あるとする。ISSは、元のシステムより100倍低速であるとする。ホストプロセッサは、ターゲットプロセッサより10倍速いとする。すると、シミュレーション時間は、216×1×100×100150日かかる。ただし、並列化して、このシミュレーション時間を減らすことは可能である。さらに、ソフトウェアコードと、ハードウェアモデルは、代替アーキテクチャに合わせて216回書き直さなくてはならない。なぜなら、ソフトウェアは特にハードウェアにアクセスするように設計されるからである。従って、処理が軽い技法で、設計空間を刈り込むことは重要である。ISSは、刈り込みの後、推測値をより正確にするために使用することができる。このような前提の下で、本発明は、典型的にはUMLなどの設計モデルを作成するツールによって生成された実行可能プログラムを、異なるアーキテクチャのハードウェアで動作させた場合の性能の差を迅速に推測することを可能とする技術である。ここでいう異なるアーキテクチャとは、マルチコアのCPUにおけるコア数やメモリ配置のトポロジなどである。図1~に、異なるアーキテクチャの例を示す。以下の実施例では、プラットフォームとも称する。そこでまず最初の仮定は、異なるアーキテクチャで走らせるプログラムは、同一の命令セットとコンパイラオプションで生成されたものであるべし、ということである。なぜなら、取得したステップの実行時間が、命令セットが全く異なるアーキテクチャでは大きく異なってしまうからである。次の仮定は、基準とするアーキテクチャと、別のアーキテクチャで、キャッシュミスレートが同一に保たれるべし、ということである。これは、粗い粒度のモデルが使用され、キャッシュアーキテクチャが変更されないなら妥当であろう。なぜなら、キャッシュは、アクセスの局所性を利用し、一方、アクセスの局所性は、プログラムの局所的な構造例えば、ループから顕われてくるからである。もちろん、キャッシュサイズやキャッシュ方法などのキャッシュ構造を変更すると、このことは最早当てはまらなくなる。すると、追加の実験やシミュレーションによって、キャッシュミスレートを調整する必要が出てくる。次の仮定は、大抵のメモリアクセスに、メモリストールが存在する、ということである。アウトオブオーダー実行やプリフェッチングは、メモリストールを減少させるが、この仮定はそれでも妥当であろう。なぜなら、最近のコンピュータシステムにおいては、プロセッサ速度とメモリレイテンシの間のギャップは大きい100サイクル以上。これの仮定が正しくないなら、本発明の技法は、時間を過分に見積もっていることになる。次の仮定は、メモリアクセスのスループットは一定であるべし、ということである。このことは、アクセスするアドレスがランダムなら、近似的に正しい。しかし、順次的アクセスのような場合、DRAMはより高いスループットを達成する傾向があるので、最早正しくない。この場合、連続的なアクセスとランダムアクセスで、異なるスループットの値を使用することにより対応できる。次に、本発明を実施するために必要となる、性能パラメータの取得について説明する。既存のシステムの測定アプリケーションプロファイル収集ツールは、外部ハードウェアを用いたロギングに対応したアプリケーションプロファイル収集ツールや、インサーキットキャッシュ評価システムを使用するなら、システム性能にわずかな擾乱しか与えないで、実行時間やメモリアクセス回数を測定することができる。大抵の新規システムは、既存のシステムの変更なので、これがコスト的にも最も効率的で、正確な方法である。既存のシステムの設計仕様文書の解析ASIC及びSoCコンポーネントからのメモリアクセスの回数は通常測定できない。なぜなら、ASIC及びSoCコンポーネントは、アプリケーションプロファイル収集ツールなどが接続されていないハードウェアだからである。ASIC及びSoCコンポーネントはキャッシュメモリをもたないので、ASIC及びSoCコンポーネントのメモリアクセスを評価するために、設計文書に記載されているアルゴリズムやデータサイズについての仕様からメモリアクセス回数を見積もることもできる。全く新しいコンポーネントが新しいシステムに追加されるなら、それは測定できない。もしプラットフォームが存在し、ソフトウェア部分のみが新規であるなら、ソフトウェアコンポーネントをプロトタイプし、アプリケーションプロファイル収集ツールで測定することは、妥当である。仮想プラットフォーム上での部分プロトタイピング新しいコンポーネントのプラットフォームもソフトウェアもともに入手可能でないなら、パラメータは、プロトタイプのISS、SystemCまたはHDLなどの粒度の小さいシミュレーションから推測することになる。このことは、上述の方法に比較して、相対的にコストがかかるが、設計空間の探索を、本発明の軽量の方法で行うので、全体としては依然としてコスト的に合理的であるといえる。ともかく、多くの場合、新しいコンポーネントの比率はあまり大きくない。次に、本発明に従う計算の理論的根拠について説明する。先ず、M個のプロセッサの場合の、衝突確率Pは、次の式で計算される。ここで、衝突パターンインデックスcは、c0122M1の非負の整数であらわされる。bという関数は、cをM桁の2進数としたとき、cのq番目のビットが1であるなら1を返し、そうでないなら0を返す。nは、1bである。上記式2は、他のアクセスが完了するのを待っている、それまでのアクセスと、新しいアクセスの間の衝突をカウントしない。この効果により、実際の衝突確率は、式で示すのよりも大きいものとなる。そこで、この効果を考慮に入れるために、次のような値を導入する。この式の分子は、メモリサブシステムによって処理されるメモリ処理の時間と、処理の待ち時間TTとの和である。そこで、次のように、式のUqを、qiを除いてUqで置き換えることにする。もし式を用いるなら、UqはTiに依存するため、前記式は、Tiの代数方程式となる。これは、順次代入していくことで解ける。すなわち、式の右辺にUqUqを初期値として代入し、式と下記の式とでUqを更新する。この手続は、値が収束するまで繰り返される。式は、再掲である。図2は、2つのプロセッサでの待ち時間のU依存性を示す図である。2つのプロセッサからのアクセスのラウンドロビン調停において、図2に示すように、アクセスが即時に完了する場合2×32で推測される。一方、調停装置は、2つのプロセッサ1及び2の場合、1212のような予め決まった順序で、同時的なメモリアクセスを処理する。もし衝突の次のサイクルが、メモリアクセスであるなら、アクセスは、他のプロセッサからのアクセスが完了するまでは、処理されるチャンスがないことになる。こうして、この場合、図2に示すように、待ち時間の比は、長くなる傾向がある。以上から、待ち時間Aの期待値は、次のように書かれる。この式は、調停が平等として、M個のプロセッサに一般化することができる。この効果は、m番目の連続サイクルまで及ぶ。プロセッサが衝突パターンcにおいて衝突に関係する場合、すなわちb1の場合、またはそれ以外の場合、すなわちb0の場合はAci1である。式に登場するUiとしては、初期値のUiを用いる。ここで、である。図3は、本発明の処理を実施するための機能を示すブロック図である。図3のシステムは、参照組込みシステム310と、モデリング/シミュレーションシステム320と、計測システム330からなる。参照組込みシステム310において、アーキテクチャ302とは例えば、組み込みシステムを実装するためのハードウェアアーキテクチャであり、その例は、図1に示すようなものである。参照組込みシステム310において、アプリケーション312は、動作をテストされる実行可能プログラムである。プラットフォーム314は、アプリケーション312を動作するためのハードウェアであり、その例は、図1に示すようなものである。メモリアクセス検出モジュール316は、アプリケーション312の、プラットフォーム314のメモリへのアクセスを検出する。ステップの開始/終了検出モジュール318は、図8に関して後述するような、ステップTstepの開始と終了を検出する。モデリング/シミュレーションシステム320は、好適にはUMLに基づくシミュレーションシステムであり、モデルUMLエディタ322と、計算モジュール324を有する。計算モジュール324は、上述したアルゴリズムに従い、実行時間やメモリ帯域利用率などの値を推測するものである。計測モジュール330は、メモリアクセス検出モジュール316によって検出され、ステップの開始/終了検出モジュール318によって開始と終了を区切られたデータを、実行トレースの形にして、モデリング/シミュレーションシステム320に転送するように働く。計算モジュール324は、計測モジュール330から渡されたデータを用いて、上述したアルゴリズムに従い、実行時間やメモリ帯域利用率などの値を推測するものである。次に、図4のフローチャートを参照して、計算モジュール324の処理を説明するが、その前に、定義と前提を与える。定義:衝突とは、複数のプロセッサからの同時アクセスである。cは、衝突パターンのインデックスである。もし、M個のプロセッサがあるなら、2M個のパターンがある。Pcとは、パターンcの衝突の確率である。Uiとは、i番目のプロセッサ上で走るステップのメモリ帯域利用率である。Aciとは、パターンcの衝突の下でi番目のプロセッサからのメモリアクセスの待ち時間の、衝突がない場合のi番目のプロセッサからのメモリアクセスの待ち時間に対する比である。前提条件:Mステップは、並列に走っている。Uiは、UiWrWwで計算される。ここで、Wはスループットである。ここで、Nriはメモリ読取り回数、Nwiはメモリ書込み回数、Wrは単位時間毎に利用可能な読取りアクセスの最大数、Wwは単位時間毎に利用可能な書込みアクセスの最大数である。Aciは、式、及びで計算される。ステップ402では、計算モジュール324は、UiUiUi0Uin0により初期化する。ステップ404では、計算モジュール324は、nn1により、nを増分する。ステップ406では、計算モジュール324は、式によりPcを計算する。ステップ408では、計算モジュール324は、式によりTiTiを計算する。ステップ410では、計算モジュール324は、式によりUinを計算する。ステップ412では、計算モジュール324は、UinUin1Ttransなので、時間スケールの分離のために、多くのパラメータが必要になる。次に、設計モデルの性能を評価する従来の方法と、本発明の方法を比較してみると、下記のような表に纏められる。ここで、実行トレースとは、改めて定義すると、例えばページの印刷処理のようなジョブ毎の処理の時間とフローであり、トランザクションレベルモデリングとは、メモリアクセスのような、デバイス間のトランザクションのログと同じ抽象度のモデルである。この表から見て取れるように、本発明の方法は、既存のいくつかの方法の中庸を得て、UMLレベルの設計モデルに好適に適用できる点が特徴である。そこで次に、UMLによる設計について説明する。設計者の意図は、次のようにしてUMLステップレベルで記述される。UMLの挙動モデリングにおいて、アクティビティ、状態、あるいはオペレーションが、UMLステップの単位である。1ステップ内のトランザクションパターンは、均一且つランダムであるとする。というのは、ループにおけるメモリアクセスの周期は、分岐によって変動し得るからである。ステップに亘るトランザクションパターンは異なり得る。というのは、ステップ毎の設計の意図も異なり得るからである。時間のかかるステップは、多くのトランザクションを含む。すなわち、前述のように、TstepTtransである。なお、メモリアクセスの時間が問題となっている状況では、これは、N1と等価となる。このように、TstepTtransという時間スケールの分離があるので、時間スケールTtransでの挙動は、1ステップ内で統計的に評価される。一方、時間スケールTstepでの挙動は、シミュレーション時間をサポートして実行可能なUMLによってシミュレーションされる。前記した各リソースの速度、リソースに対する同期トランザクション、及びリソースに対する競合という3つの要件は以下のように評価される。まず、リソースの速度について説明する。UMLステップは、Tstepを更新するためのリソース利用要求によって特徴づけられる。このとき、計測時のシステムと新規システムのリソースの速度の違いを、下記の式で示すアムダールの法則によってTstepに反映する。TstepTstepここでfは、参照リソースに対する新しいリソースの速度比である。Uは、そのリソースを使用する時間のTstepに占める割合である。プロセッサリソースの場合には、ULは、メモリアクセスのレイテンシである。なお、レイテンシが読み込みと書き出しで異なる場合にはそれぞれをLrLwとし、それぞれのアクセス回数をNrNwとすると、UTstepとなる。メモリリソースの場合、Uはメモリリソースの利用率である。-メモリリソースの場合、リソース競合は、トランザクションの分布がランダム且つ均一であるという仮定の下で、衝突確率から計算される。-プロセッサリソースの場合、リソース競合は、リソースがタイムスライスまたはキューによって共有されているという仮定の下で計算される。また、同期的トランザクションの効果は、競合伝播アルゴリズムによって評価される。その詳細は、図13を参照して後で説明する。このようなUMLステップベースのリソースアクセスと詳細な粒度のリソースアクセスの関係の例を図9に示す。ジョブとしてそこに示されているように、リソース競合は、Tstepという粗いレベルで評価される。ここでリソースは、メモリ、あるいは、メモリにアクセスする、プロセッサ、アクラセレータ、またはコントローラを含む、バスマスタと呼ばれるデバイスも含む。上記では、プロセッサに関して記述されているが、プロセッサ以外のバスマスタについても、シミュレーション方法は、プロセッサに準じて適用可能であることを理解されたい。ここで、UMLベースのモデルに本発明を適用することの目的は、次のとおりである。新しい製品のソフトウェア及びハードウェアアーキテクチャを、性能の観点から検証すること。ここでの性能の定義は、アプリケーションプロセスの実行時間で測定されるものである。そして期待される出力は、次のものである。リソース利用率バス及びプロセッサステップの実行トレース各ステップの開始と終了時間ここで要求されるのは、つぎのものである。UML実行の実行セマンティックス状態マシン、アクティビティ図などをサポートすべきであること。これは、シミュレーション時間をサポートして実行されるUMLをベースとして使用することにより、満たされる。正確なシミュレーションパラメータを使用すること。これは、測定技術と、既存のソースコードからモデルを作成する技術てあるリバースモデリングを使用することにより、満たされる。また、既に説明したように、次のような効果を評価することが必要とされる。各リソースの速度リソースに対する同期トランザクションリソース競合本発明の技法は、UMLレベル実行トレースのために設計されたものであるので、本発明のシミュレーション技法は、UMLエディタに統合することができる。このとき、次のように3種類のモデルを定義する。アプリケーションモデルは、ステレオタイプによる性能パラメータアノテーションをもつソフトウェア設計のためのユーザーのモデルである。リソース割当てモデルは、MARTEアロケーションパッケージを用いて、ソフトウェアコンポーネントと、プラットフォームリソースの間の関係を記述する。ここで、MARTEModelingandAnalysisofRealTimeEmbeddedSystemsとは、リアルタイム組み込みシステム向けのドメイン特化モデリング言語で、UMLの拡張プロファイルとして定義されたものである。プラットフォームモデルは、プロセッサやメモリなどの振舞いをシミュレートするコンポーネントからなるシミュレーションフレームワークである。図10は、このようなUMLエディタの機能を模式的に示す図である。すなわち、ユーザーがアプリケーションモデルを作成し、リソース割当てモデルを指定する。アプリケーションモデルには、性能パラメータが注釈され、リソース割当てモデルには、プラットフォーム仕様が設定される。このとき、例えば、UMLエディタのプラグインが使用される。アプリケーションモデルとリソース割当てモデルは、ライブラリモジュールを含むプラットフォームモデルと結合されて、性能シミュレーションコードが生成される。この時、コード生成機能は、例えばUMLエディタの既存のコード生成機能を拡張することで実現される。性能シミュレーションコードは、組込みシステムとは別のコンピュータシステム上で実行される。このシミュレーションによって得られる典型的な情報は、実行トレースと、時間の関数としての各リソースの使用率のレポートである。実行トレースは、下記の目的で使用することができる。視覚化を通じて、システムの振る舞いを理解する。テストケースの実行時間を評価する。スループットなどの統計を計算する。時間の関数としての各リソースの使用率は、下記の目的で使用することができる。ボトルネックリソースを指摘する。図11は、既存の製品から新しい製品を設計する場合の、処理の流れを示す図である。すなわち、ステップ1102で、既存の製品の動作が測定され、これによって実行トレースが得られる。ステップ1104では、実行トレースが解析され、その解析結果に基づき、ステップ1106でモデリングが行われる。モデリングに際しては、設計文書とパラメータも参照される。モデリングによって得られたモデルに基づき、ステップ1124ではシミュレーションが行われ、それによって実行トレースが得られる。その実行トレースは、ステップ1110で解析され、それによってレポートが生成されるので、そのレポートに基づき、必要に応じて、ステップ1106でモデリングがやり直される。こうして、十分なモデルが得られると、そのモデルとレポートの情報を以って、ステップ1112で設計が行われる。設計の後は、プロトタイプが作られ、ステップ1102で測定が行われる。それにより、満足のいく結果が得られないと、ステップ1106のモデリングに戻る。この一連のステップの結果、ステップ1112で満足のいく設計が得られると、それに基づき、新しい製品が作られる。次に、シミュレーションモデルとして、注釈された実行可能UMLの例について説明する。すなわち、ステップパラメータ記述アプリケーションモデルと、ソフトウェアコンポーネントに対するメモリ及びプロセッサリソースの割当てリソース割当てモデルが、プロファイルすなわち、UMLエクステンション、例えば、OMGMARTEプロファイルを適用することによって、UMLに対して注釈される。UMLモデルはまた、ソフトウェアに対する仕様として使用される。すなわち、ソフトウェアを実装するとき、開発者はUMLモデルに当たることができるし、あるいは、開発者は、モデルから自動的にソフトウェアソースコードを生成することができる。図12は、そのようなアプリケーションモデルと、リソース割当てモデルの例を示す。図において、は、プロファイルで定義されたステレオタイプである。また、リソース割当てモデル中のSW1、SW2は、ソフトウェアコンポーネントを示す。なお、シミュレーションのために、UML以外の形式のイベントドリブンまたは離散時間シミュレーションモデルも使用可能であることに留意されたい。アプリケーションプロファイル収集ツールは、システムに対してほとんど擾乱を与えることなく、実行時間Tと、メモリアクセスの回数Nを測定することを可能ならしめる。ステップの実行時間Tは、ステップの開始/終了検出モジュールに対してステップの出入りを通知する小さいコードを挿入することによって、行うことができる例えば、OhbaNTakanoKHardwaredebuggingmethodbasedonsignaltransitionsandtransactionsInProceedingsofthe11thAsiaSouthPacificDesignAutomationConferenceを参照されたい。メモリアクセスの回数Nは、キャッシュエミュレータハードウェアを使用し、キャッシュミスの回数をカウントすることによって測定される。これらの情報は、実行トレースとして報告され、モデルパラメータは実行トレースから抽出することができる。さらにこの実施例の説明を続ける前に、用語の定義を与える。先ず、ステップとは、UMLモデルにおけるアクション、状態、または操作に対応する。また、ステップは、実行されるとジョブを生成する。ジョブは、リソースによる処理の単位であり、ステップに対応する。このとき、ジョブJTstepU1U2Umであり、ここで、mはリソースの数、Uiは、このジョブによってi番目のリソースに対して要求される利用率である。ジョブの処理時間は、Tstepと、これらの利用率によって計算される。リソースとは、プロセッサ、メモリ帯域などのハードウェアの抽象である。このとき、リソースは、その利用率に従ってジョブを処理する。リソースは容量をもち、それは1に正規化される。各リソースにおいて、ジョブの利用率の合計は、同時にこの容量を超えることはない。リソースは、利用率の合計を1以下に保つようにジョブの利用率を変えることができる競合状態。リソースは、速度ファクタに従い、ジョブの利用率を変えることができる。ステップパラメータ:これは、参照システムから得られ、新しいシステム用に調整される。Tステップ時間Nr読取りアクセスの回数Nw書込みアクセスの回数Wr単位時間毎に利用可能な読取りアクセスの最大数Ww単位時間毎に利用可能な書込みアクセスの最大数ジョブパラメータT処理時間Upプロセッサ利用率要求Ubメモリ帯域利用率要求ステップパラメータと、ジョブパラメータの間の関係は、次のとおりである。JobTStepTUbTTUp1図13は、利用率の計算の例を示す図である。この図において、リソースR1であるプロセッサと、リソースR2であるバスと、リソースR3であるプロセッサがあるとする。最初にジョブJ1が、ジョブJ2が、ジョブJ3がであるとする。すると、明らかにリソース競合が起きるが、利用率が計算され、競合が伝播することによって、競合が緩和されている様子が示されている。次に、図14を参照して、この実施例のシミュレーション方法全体について説明する。Dataleftiは、ジョブがある時刻tに持つリソースアクセスの残量として定義される。DataleftiTUiは、ジョブ生成時の初期値となる。1全てのリソースについて、ジョブの利用率Uを計算する利用率計算アルゴリズムについては、後述する2全てのジョブについて、ジョブ完了時間を次の式で更新する。ΔTiDataleftiUiこの値は、リソースに依存しない3全てのジョブにおいて、ジョブ完了時間の最小時間を見出す。すなわち、ジョブにおけるΔTiの最小値をaとおく。4タイムアウトを待つTm、この間に、ジョブ開始イベントが、ttaで起き得る。ここで、Tmとは、a秒間のタイムアウトを待つことを示す。タイムアウト発生時には、現在のシミュレーション時刻tがtaに更新される。5全てのジョブについて、Dataleftiから、Uを引く。6Datalefti0ならジョブを取り除き、ジョブ完了イベントを送る。図14に、上記の処理に対応するリソースマネジャの状態マシンを示す。図14において、状態1402は、待機し、全てのジョブについての利用率の更新と、全てのジョブについてのΔTの更新と、最小のΔTであるaを見つけることを行う。一方、状態1404は、Dataleftを更新し、完了したジョブを取り除く。次に、利用率計算アルゴリズムについて説明する。先ず、メモリ帯域リソースの場合、図4に関連して説明したメモリアクセス競合計算技法を使用する。プロセッサリソースの場合、非プリエンプティブマルチタスクシステムであるなら、例えば、キューイングモデルを使用する。一方、プリエンプティブマルチタスクシステムであるなら、例えば、次のような単純な比例的利用率割当てを用いる。次に、他のリソースに対するリソース競合伝播の効果について説明する。図13に示したように、あるジョブについて、競合のためにリソースに対する利用率が低下するなら、そのジョブの他のリソースに対する利用率は、同期的性質により低下する。同様の伝播は、次のように記述される。すなわち、もしUifUiであるなら、iに等しくないhについて、UhfUhなぜなら、TUiTUiで時間が延びるだけなので、TUhTUhリソース間のリソース競合計算の順序は、競合伝播のため、ジョブの利用率の分布に影響する。そこで、計算順序であるが、明示的なデバイスベースの順序は、高い特権のリソースから計算することである。例えば、プロセッサリソースの利用率を最初に計算する。その結果を他のリソースに伝播する。次に、メモリリソースの利用率を計算する。その結果を他のリソースに伝播する。以上、リソース利用率の計算処理を、UMLエディタに追加する機能として説明したが、これには限定されず、任意の実行可能プログラムの性能評価に適用可能である。また、本発明は、使用するプラットフォームや、プログラミング言語処理系にも限定されないことを、この分野の当業者なら理解するであろう。