JP2003280927A - 動作判定装置、同方法、同プログラムおよび判定対象プログラム - Google Patents

Abstract

(57)【要約】 【課題】 アプリケーションなどの判定対象プログラム
の実行可能性を迅速に判定する。 【解決手段】 アプリケーションにおける構成情報とし
て、各タスクの所要リソース量情報（Ｓ１）と、タスク
間の関連性、とくに実行順序と実行タイミングに関する
情報（Ｓ２）と、を取得しておき、これらの情報に基づ
いて、同時に実行されることで一機能となり得るタスク
の組合せを抽出する（Ｓ３）。抽出されたタスクの組合
せと、所要リソース量情報とに基づいて、抽出されたタ
スクの組合せの全てについての実行可能性を判定する
（Ｓ４）。アプリケーションの動作を実際に行うことな
しに実行可能性を判定でき、判定を迅速化できる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、システムにおける
プログラムの実行可能性を判定する装置およびプログラ
ムに関する。

【０００２】

【従来の技術】従来、遅延保証が必要な全てのタスクの
遅延を保証しタスクの実行を制御することで、アプリケ
ーションプログラムのサービス品質を制御するタスク管
理方法として、周期的な実行および実行時からの遅延保
証が必要なタスクを実行するマルチタスクシステム（例
えば、特開平１０−１７１６６７号公報）が提案されて
いる。また、マルチタスクシステムにおいて、実際のタ
スクの処理時間に基づいて各タスクに設定された要求処
理時間と許容遅延時間を自動的に修正してタスクを実行
するマルチタスクシステム（特開平１１−２５９３１１
号公報）も提案されている。さらに、動作中のタスクの
実際の周期および処理時間に基づき、そのタスクの実行
に用いる周期、要求処理時間および許容遅延時間を新た
に算出するようにしたものもある（特開２０００−５６
９８９号公報）。

【０００３】

【発明が解決しようとする課題】しかし、あるマルチタ
スクシステムにおいて、あるアプリケーションが実際に
動作したとしても、そのアプリケーションにおけるタス
ク構成に変更が加えられた場合（例えば新規のタスクが
追加された場合や、一部のタスクが修正された場合）に
は、変更後のアプリケーションを実際にそのマルチタス
クシステムで動作させなければ、各タスクの実行可能性
は判定できない。このためアプリケーションの開発段階
においては、試作品のインストールと動作確認を何度も
繰り返し行う必要があって開発期間の長期化の要因とな
り、特に、アプリケーションのダウンロード機能をもつ
携帯電話機の場合のように、送受信側が共に多様なハー
ドウェア構成をもつ場合にきわめて煩雑であった。

【０００４】そこで本発明の目的は、アプリケーション
などの判定対象プログラムの実行可能性を迅速に判定で
きる手段を提供することにある。

【０００５】

【課題を解決するための手段】第１の本発明は、請求項
１に記載のとおり、複数のタスクを含むプログラムを対
象にシステムにおける実行可能性を判定する動作判定装
置であって、判定対象プログラムを構成するタスクの情
報を構成情報として取得する構成情報取得手段と、前記
構成情報に基づいて、同時に実行されることで一機能と
なり得る前記タスクの組合せを抽出する機能抽出手段
と、前記タスクの夫々について実行に必要なリソース量
の情報を取得する所要リソース量情報取得手段と、前記
抽出されたタスクの組合せと、前記所要リソース量情報
とに基づいて、前記判定対象プログラムが有する全ての
機能について実行可能性を判定する判定手段と、を備え
た動作判定装置である。

【０００６】第１の本発明では、判定対象プログラムに
おける構成情報、つまりタスク間の関連性に関する情報
と、各タスクの所要リソース量情報とを取得しておき、
これらの情報に基づいて、機能抽出手段が、同時に実行
されることで一機能となり得るタスクの組合せを抽出す
る。そして判定手段は、抽出されたタスクの組合せと、
所要リソース量情報とに基づいて、判定対象プログラム
が有する全ての機能について実行可能性を判定する。し
たがって第１の本発明では、判定対象プログラムの動作
を実際に行うことなしに実行可能性を判定できるため、
実行可能性の判定を迅速化できる。

【０００７】第２の本発明は、請求項２に記載のとお
り、請求項１に記載の動作判定装置であって、前記複数
のタスクのうち所要リソース量が制御可能な可変タスク
につき、その所要リソース量を補正する所要リソース量
補正手段を更に備え、前記判定手段は、実行不可能との
判定があった場合に、前記抽出されたタスクの組合せ
と、前記補正後の所要リソース量とに基づいて、前記判
定対象プログラムが有する全ての機能について実行可能
性を更に判定することを特徴とする動作判定装置であ
る。

【０００８】第２の本発明では、判定手段によって実行
不可能との判定があった場合に、所要リソース量補正手
段が可変タスクについての所要リソース量を補正し、補
正後の所要リソース量に基づいて実行可能性が更に判定
される。したがって、いったん実行不可能との判定がさ
れた場合にも、サービス品質のわずかの変更によって実
行可能となる場合に、そのような変更の実現により動作
確認の工数を削減できる。

【０００９】第３の本発明は、請求項３に記載のとお
り、請求項１または２に記載の動作判定装置であって、
前記判定手段が、前記システムにおいて複数の判定対象
プログラムを並行動作させる場合の実行可能性を判定す
ることを特徴とする動作判定装置である。

【００１０】第３の本発明では、複数の判定対象プログ
ラムを並行動作させる場合の実行可能性を判定するの
で、判定対象プログラムの実行時の外的条件をよく再現
でき、正確な動作判定を行うことができる。

【００１１】第４の本発明は、請求項４に記載のとお
り、複数のタスクを含むプログラムを対象にシステムに
おける実行可能性を判定する動作判定方法であって、判
定対象プログラムを構成するタスクの情報を構成情報と
して取得する構成情報取得ステップと、前記構成情報に
基づいて、同時に実行されることで一機能となり得る前
記タスクの組合せを抽出する機能抽出ステップと、前記
タスクの夫々について実行に必要なリソース量の情報を
取得する所要リソース量情報取得ステップと、前記抽出
されたタスクの組合せと、前記所要リソース量情報とに
基づいて、前記判定対象プログラムが有する全ての機能
について実行可能性を判定する判定ステップと、を含む
動作判定方法である。第４の本発明では、第１の本発明
と同様の効果を実現できる。

【００１２】第５の本発明は、請求項５に記載のとお
り、請求項４に記載の動作判定方法であって、前記複数
のタスクのうち所要リソース量が制御可能な可変タスク
につき、その所要リソース量を補正する所要リソース量
補正ステップを更に含み、前記判定ステップでは、実行
不可能との判定があった場合に、前記抽出されたタスク
の組合せと、前記補正後の所要リソース量とに基づい
て、前記判定対象プログラムが有する全ての機能につい
て実行可能性を更に判定することを特徴とする動作判定
方法である。第５の本発明では、第２の本発明と同様の
効果を実現できる。

【００１３】第６の本発明は、請求項６に記載のとお
り、請求項４または５に記載の動作判定方法であって、
前記判定ステップでは、前記システムにおいて複数の判
定対象プログラムを並行動作させる場合の実行可能性を
判定することを特徴とする動作判定方法である。第６の
本発明では、第３の本発明と同様の効果を実現できる。

【００１４】第７の本発明は、請求項７に記載のとお
り、複数のタスクを含むプログラムを対象にシステムに
おける実行可能性をコンピュータに判定させるための動
作判定プログラムであって、判定対象プログラムを構成
するタスクの情報を構成情報として取得する構成情報取
得処理と、前記構成情報に基づいて、同時に実行される
ことで一機能となり得る前記タスクの組合せを抽出する
機能抽出処理と、前記タスクの夫々について実行に必要
なリソース量の情報を取得する所要リソース量情報取得
処理と、前記抽出されたタスクの組合せと、前記所要リ
ソース量情報とに基づいて、前記判定対象プログラムが
有する全ての機能について実行可能性を判定する判定処
理と、をコンピュータに実行させるための動作判定プロ
グラムである。第７の本発明では、第１の本発明と同様
の効果を得ることができる。

【００１５】本発明のタスク管理装置と関連して用いら
れるプログラムは、第８の本発明のように、その判定対
象プログラムの構成情報を格納する構成情報格納手段を
備えることとしたり、第９の本発明のように、機能ごと
に実行に必要なリソース量の情報を格納する所要リソー
ス量情報格納手段を備えることとすれば、実行される判
定対象プログラムとこれに含まれるタスクの諸情報とを
組として取り扱うことができ好適である。

【００１６】

【発明の実施の形態】本発明の実施形態について、以下
に図面を参照して説明する。図１において、本発明の実
施形態に係る動作判定装置１は、ＣＰＵ２、タイマ３、
例えばハードディスク装置等の記憶装置４、メモリ５、
ネットワーク１１とのインタフェースとなるネットワー
ク制御部６を備えている。これらＣＰＵ２、タイマ３、
記憶装置４、メモリ５、ネットワーク制御部６は、内部
バス７で接続されている。

【００１７】タイマ３は、設定された一定時間までの計
時を繰り返すものであり、設定時間ごとにＣＰＵ２に割
り込みをかけることにより、設定時間の経過をＣＰＵ２
に通知することが可能である。記憶装置４には本発明に
係る動作判定プログラムのほか、タスクプログラムとし
ての判定対象プログラム等が記録されており、必要に応
じてメモリ５に読み出される。

【００１８】メモリ５上には、リアルタイム性が要求さ
れるタスク、すなわち遅延時間を小さくする必要のある
タスク（以下、このようなタスクを遅延保証が必要なタ
スクと呼ぶ）を管理するために、これら各タスクの情報
を格納しておくためのタスク管理テーブル９が存在す
る。

【００１９】図２はタスク管理テーブル９の一例を示す
図である。タスク管理テーブル９は、タスク情報管理テ
ーブル２１と構成情報管理テーブル２２とから構成され
る。

【００２０】タスク情報管理テーブル２１は、遅延保証
が必要なタスクに関する情報を管理するテーブルであ
る。このタスク情報管理テーブル２１に格納される情報
には、タスク識別子格納部２１ａ、タスクポインタ格納
部２１ｂ、周期格納部２１ｃ、要求処理時間格納部２１
ｄ、許容遅延時間格納部２１ｅにそれぞれ格納される、
タスク識別子ＩＤ、タスクポインタＰ、周期Ｓ、要求処
理時間Ｔ、デッドラインＨがあり、これらの情報がそれ
ぞれタスクごとに格納されている。なお、図２では、横
１列が１つのタスクに関する情報を示している。

【００２１】タスク識別子ＩＤは、各タスクを識別する
ためのものであり、タスクポインタＰは、記憶装置４あ
るいはメモリ５上に存在する各タスクのプログラムの位
置を指し示すものである。周期Ｓは、各タスクにおける
実行開始時点から次の実行開始時点までの時間であり、
あるタスクが実行されると、設定された周期Ｓの間、こ
のタスクが新たに実行されることはない。

【００２２】要求処理時間Ｔは、各タスクの実行に要す
る処理時間であり、本発明における所要リソース量を構
成する。なお、この要求処理時間Ｔは、予め設定される
サンプル値なので、実際のタスクがこれらの値より前に
終了することもあり得る。

【００２３】デッドラインＨは、その時間内で処理が完
了すれば品質が満足されるような許容時間であって、周
期Ｓで示される時間内に設定される。あるタスクに対し
てイベントが発行された状態で前回の実行開始時点から
の経過時間が周期Ｓを超えたり、タスク処理が中断した
りすると、このタスクに遅延が生じる。このような遅延
の発生は、許容遅延時間Ｈを消費することを意味する。
したがって、この許容遅延時間Ｈが全て消費される前に
タスク処理が終了しなければならない。

【００２４】なお、これらの周期Ｓ、要求処理時間Ｔ、
デッドラインＨの各情報は、このタスクを含んでいるア
プリケーションプログラムに予めデータとして格納され
ており、このアプリケーションプログラムの外部記憶媒
体経由やネットワーク１１経由でのインストールにより
記憶装置４に記憶され、後述する動作判定要求のシステ
ムコールに応じてＯＳに渡され、タスク識別子ＩＤが付
与されてタスク情報管理テーブル２１に格納されること
になる。

【００２５】構成情報管理テーブル２２は、アプリケー
ションの構成情報、すなわちそのアプリケーションにお
ける各タスクの相互関係の情報が格納される。具体的に
は、構成情報管理テーブル２２には、基準タスク識別子
格納部２２ａと、前提タスク識別子格納部２２ｂとが設
けられ、あるタスク（以下適宜基準タスクという）のタ
スク識別子ＩＤと、その実行の前提となるタスク（以下
適宜前提タスクという）のタスク識別子ＩＤとが、それ
ぞれ格納されている。

【００２６】例えば、動作判定の対象となるアプリケー
ションが、図３に示すようにタスク１〜５で構成されて
おり、このうちタスク２，４の実行開始がタスク１の実
行完了を前提とし、タスク３の実行開始がタスク２の実
行完了を前提とし、タスク５の実行開始がタスク４の実
行完了を前提とする場合には、構成情報管理テーブル２
２の内容は図２のとおりとなる。この構成情報管理テー
ブル２２を利用して、全ての前提タスクの要求処理時間
Ｔと、その前提タスクを基準タスクとする全ての前提タ
スクの要求処理時間Ｔとを足し込むことにより、同時に
実行される可能性のある全てのタスクを網羅的に抽出す
ることができる。

【００２７】メモリ５上には更に、アプリケーションの
使用環境のリソース量情報を管理するために、リソース
量情報格納部１０が設けられている。このリソース量情
報は、動作判定の対象となるアプリケーションが実装さ
れる環境のリソース量を仮想的な情報として保持したも
のであり、予め記憶装置４に記憶され適宜メモリ５に読
み出される。

【００２８】リソース量情報は、そのアプリケーション
の使用環境（ハードウェア環境およびソフトウェア環
境）が既に存在する場合にはその使用環境の実測により
予め取得する。また、使用環境が存在しない場合には、
その使用環境のハードウェアおよびソフトウェアのベン
ダーから提供される諸元値をそのまま利用するものとす
る。

【００２９】本実施形態におけるリソース量としては、
使用環境におけるＣＰＵの使用時間が用いられる。な
お、本発明におけるリソース量は、ＣＰＵのほかに記憶
装置やメモリ、あるいは図示しないビデオメモリの使用
時間および記憶容量、ネットワークの通信速度やネット
ワークサーバの記憶容量・メモリ容量など、特定のタス
クを実行するために必要なハードウェア資源およびソフ
トウェア資源の全てを選択的に用いることができる。ま
た、リソース量としては、タスクの種類および機能に応
じて異なるものを利用でき、例えばタスクがデータ読込
に係るものである場合にはＣＰＵの使用時間・ハードデ
ィスクの記憶容量・メモリの使用時間と記憶容量、タス
クが復号処理に係るものである場合にはＣＰＵの使用時
間・メモリの使用時間と記憶容量、タスクが映像出力に
係るものである場合にはＣＰＵの使用時間・メモリの使
用時間と記憶容量・ビデオメモリの使用時間と記憶容量
を、それぞれリソース量として用いることができる。

【００３０】次に、本実施形態における動作判定処理に
ついて、図４に従って説明する。いま、アプリケーショ
ンの動作判定要求が入力されると、ＣＰＵ２は、動作判
定プログラム格納部８に格納された動作判定プログラム
に従って、以下の処理を実行する。

【００３１】まずＣＰＵ２により、タスク情報管理テー
ブル２１および構成情報管理テーブル２２から、各タス
クの所要リソース量情報（ここでは、要求処理時間Ｔ）
と、アプリケーションの構成情報とがそれぞれ読み込ま
れる（Ｓ１）。また、リソース量情報格納部１０から、
実装環境のリソース量情報が読み込まれる（Ｓ２）。

【００３２】次に、ステップＳ１で読み込まれたアプリ
ケーションの構成情報と、各タスクの所要リソース量情
報などに基づいて、同時に実行されることで一機能とな
り得るタスクの組合せが抽出される（Ｓ３）。上述した
図３の例では、タスク２とタスク４、タスク３とタスク
５が、それぞれ同時に実行されることで一機能となり得
るタスクとしてここで抽出される。

【００３３】そして、抽出されたすべての組合せが実行
可能かが、先にステップＳ２で読み込まれているリソー
ス量情報との比較により判断される（Ｓ４）。具体的に
は、抽出されたすべての組合せについて、実装環境にお
ける負荷の計測と、ＱｏＳの検証とが行われ、負荷が所
定の基準値を下回り且つＱｏＳが所定の基準値を上回っ
ている場合に実行可能と判定され、そうでない場合に否
定判定がされる。

【００３４】このステップＳ４での判断の結果、実行可
能と判定された場合（Ｓ５）、および実行不可能と判定
された場合（Ｓ６）には、その旨がアプリケーションに
返答され、処理が終了する。なお、ステップＳ５，Ｓ６
での出力に基づいて、所定の表示処理により、対応する
文字メッセージが表示装置（図示せず）に表示される。

【００３５】以上のとおり、第１実施形態では、判定対
象プログラムであるアプリケーションにおける構成情
報、つまりアプリケーションにおけるタスク間の関連性
（実行順序と実行タイミング）に関する情報と、各タス
クの所要リソース量情報とを取得しておき、これらの情
報に基づいて、同時に実行されることで一機能となる可
能性のあるタスクの組合せを抽出する。そして、抽出さ
れたタスクの組合せと、所要リソース量情報とに基づい
て、抽出されたタスクの組合せの全てについての（すな
わち、そのアプリケーションが有する全ての機能につい
ての）実行可能性を判定する。したがって本実施形態で
は、アプリケーションの動作を実際に行うことなしに実
行可能性を判定できるため、実行可能性の判定を迅速化
できる。

【００３６】また本実施形態では、アプリケーションが
その構成情報と、タスクごとに実行に必要なリソース量
の情報を格納することとしたので、実行されるアプリケ
ーションとこれに含まれるタスクの諸情報とを組として
取り扱うことができ好適である。

【００３７】次に、第２実施形態について説明する。上
記第１実施形態では、ステップＳ４での処理の結果、実
行不可能との判定がされた場合には、その旨の出力を行
うこととしたが、第２実施形態は更に、実行不可能の場
合に処理量を補正して判定を再試行するものである。な
お、第２実施形態におけるシステムのハードウェア構成
は、上記第１実施形態のものと同様であるため、その説
明は省略する。

【００３８】第２実施形態では、各タスクについて、予
め保証部分と制御可能部分とが設定されている。例え
ば、タスクがＭＰ３音声再生プログラムである場合、保
証部分は復号処理に係る処理部分であり、制御可能部分
は、高音質化のための補完処理に係る処理部分である。

【００３９】また、タスクがＭＰＥＧ動画再生プログラ
ムである場合、保証部分は描画間隔１／１５秒のフレー
ムレートに相当する処理部分であり、制御可能部分は、
描画間隔１／３０秒のフレームレートに相当する処理部
分である。なお、タスクが静止画または動画の再生プロ
グラムである場合には、受認できる最低限の解像度に相
当する処理部分を保証部分とし、それ以上の解像度に相
当する処理部分を制御可能部分とする、というように解
像度を調整するのも好適である。

【００４０】また、アプリケーションがＷｅｂブラウザ
である場合、保証部分は、ネットワークタイムアウト時
間内のパケット通信間隔の通信レートに相当する処理部
分であり、制御可能部分は、より大きい通信レート、例
えば（パケットサイズ）／（スループット）の通信レー
トに相当する処理部分である。

【００４１】なお、本実施形態におけるアプリケーショ
ンプログラムでは、各タスクの保証部分のプログラム文
と制御可能部分のプログラム文とが互いに分離して記述
されており、また保証部分のメモリアドレスには、保証
対象識別子としての所定の保証対象フラグが付されてい
る。この保証対象フラグは、後述するステップＳ１７の
処理によって、実装時のサービス品質の設定が変更され
た場合に、変更された設定でアプリケーションを実行す
る際の保証部分の抽出に用いられるものである。

【００４２】また、各タスクの保証部分のリソース量、
すなわち最低限の割当が保証されるリソース量は、その
アプリケーションが実装されるハードウェアおよびソフ
トウェア環境またはこれを模擬したエミュレータにおけ
るスケジューラプログラムの時間計測機能を用いて計測
する。具体的には、最低限保証すべきリソース量は、対
象となる処理が、割り当てタイミングごとに開始してか
ら終了するまでに、各リソースを使用する時間を測定す
ることによって予め計測される。また、各タスクのデッ
ドラインは、割り当てタイミングから処理開始までの時
間をずらし、品質が満足できなくなるまでの空白時間を
測定することで計測できる。また、制御可能部分のリソ
ース量は、各タスクの最高の処理品質による処理を実行
しながら同様のスケジューラプログラムを利用した計測
値から、保証部分の計測値を減算することで算出でき
る。これらのリソース量情報は、このような試行と測定
をシステム上で実際に行うことで取得してもよいし、ア
プリケーションプログラムのベンダーから提供される諸
元値をそのまま利用してもよい。

【００４３】図４は、第２実施形態における動作判定処
理を示す。図４において、ステップＳ１１からＳ１５ま
での処理は、上記第１実施形態におけるステップＳ１か
らＳ５までの処理と同様である。

【００４４】ステップＳ１４で否定された場合、具体的
には、抽出されたタスクの組合せの全て（すなわち、同
時に実行されることで一機能となり得るタスクの組合せ
の全て）について、実装環境における負荷の計測とＱｏ
Ｓの検証とが行われた結果、負荷が所定の基準値を上回
るか、もしくはＱｏＳが所定の基準値を下回るようなタ
スクの組合せ（タスク群）が存在すると判断された場合
には、次に、そのようなタスクの組合せについて、サー
ビス品質の変更が可能かが、判定対象となっているタス
クの組合せの中に制御可能部分を含むタスクがあるかに
よって判断される（Ｓ１６）。

【００４５】この判断の結果、サービス品質の変更が可
能、つまり判定対象となっているタスクの組合せの中に
制御可能部分を含むタスクがある場合には、次に、その
サービス品質変更可能なタスクのリソース量情報を補正
して再設定する（Ｓ１７）。具体的には、判定対象とな
っているタスク群中の制御可能部分を含むタスクについ
て、処理対象から制御可能部分が仮想的に除外され、そ
の旨がメモリ５の所定の記憶領域に、例えば所定のフラ
グにより記憶される。

【００４６】そして、このようにして制御可能部分を含
むタスクから制御可能部分が除外された設定について、
補正後の所要リソース量に基づいて、そのタスク群の実
行可能性が再び判定され（Ｓ１４）、実行可能な場合に
は、ステップＳ１５に移行する。なお、これらステップ
Ｓ１３，Ｓ１４，Ｓ１６，Ｓ１７の各処理は、例えばス
テップＳ１７において制御可能部分をもつタスクが複数
ある場合に、その中で補正対象となる一部のタスクを所
定の優先度で順次選択することにより、複数回繰り返し
実行することができる。

【００４７】ステップＳ１６において否定の場合、すな
わち、あるタスク群が実行不能であって、かつサービス
品質の変更（調整・削減）の余地もない場合には、その
旨がアプリケーションに返答され（Ｓ１８）、処理が終
了する。なお、ステップＳ１５，Ｓ１６での出力に基づ
いて、所定の表示処理により、対応する文字メッセージ
が表示装置（図示せず）に表示される点は、上記第１実
施形態と同様である。

【００４８】以上のとおり、第２実施形態では、同時に
実行される可能性のある複数のタスクからなるタスク群
のいずれかについて、システムの提供可能なリソース量
からみて実行不可能との判定があった場合に、可変タス
クについての所要リソース量が補正され（Ｓ１７）、補
正後の所要リソース量に基づいて実行可能性が判定され
る（Ｓ１４）。したがって、いったん実行不可能との判
定がされた場合にも、サービス品質のわずかの変更によ
って実行可能となる場合に、そのような変更の実現によ
り動作確認の工数を削減することができる。

【００４９】なお、第２実施形態では、制御可能部分を
全体として仮想的に削除することで処理量を調整する構
成としたが、逆に、リソース量に余裕がある場合（すな
わち、例えば、提供可能なリソース量と全てのタスクの
組合せの所要リソース量の合計との差が所定値を上回る
場合）に、処理品質を上げるような追加的な制御可能部
分を、全てのタスクに付加する構成としてもよい。ま
た、上記各実施形態では、リソース量の余裕の有無に応
じて、タスクの処理品質を段階的に増減変更する構成に
ついて説明したが、タスクの処理品質は無段階的に増減
変更することとしてもよい。

【００５０】なお、上記各実施形態では、単一のアプリ
ケーションにおけるタスクの相互関係（構成情報）に基
づいて、その実行可能性を判定する例について説明した
が、本発明は複数のアプリケーションを並列して動作さ
せる場合や、同じく判定対象プログラムであるミドルウ
ェアと該ミドルウェア上で動作するアプリケーションと
を並列して動作させる場合の実行可能性判断にも適用で
きる。

【００５１】すなわち、あるアプリケーション（以下、
第１のアプリケーションという）について実行可能性が
確認されている場合に、その第１のアプリケーションと
他のアプリケーション（以下、第２のアプリケーション
という）とを並列に動作させ同時に実行させることを考
えた場合に、第２のアプリケーションにおける個々のタ
スクの実行タイミングが第１のアプリケーションにおけ
るいずれかのタスクの実行タイミングに依存しており、
かつ第２のアプリケーションの各タスクの所要リソース
量が既知であれば、この第２のアプリケーションにおけ
る各タスクの実行タイミングと所要リソース量の各情報
を上記第１実施形態におけるタスク情報管理テーブル２
１、および構成情報管理テーブル２２に追加して格納す
ることにより、上記第１実施形態におけるものと同様の
処理によって、その動作可能性を判定することができ
る。

【００５２】このようにして、所定のマルチタスクシス
テムにおいて複数のアプリケーションを並行動作させる
場合の実行可能性を、本発明に係る動作判定機能を利用
して判定することとすれば、第１および第２のアプリケ
ーションの実行時の外的条件をより忠実に再現でき、正
確な動作判定を行うことができる。なお、この場合には
更に、第１のアプリケーションにおける各タスクに係る
所要リソース情報と構成情報とを、予め記憶装置４に格
納した形で提供すれば、アプリケーションのベンダーが
これに適合する第２のアプリケーションを開発する場合
にも、本発明に係る動作判定機能を有効に利用すること
ができる。

【００５３】また、上記各実施形態では、リソース量情
報格納部１０に、単一種類の実装環境（ハードウェア環
境・ソフトウェア環境）のリソース量情報を格納するこ
ととしたが、このような構成に代えて、リソース量情報
格納部１０に互いに異なる複数種類の実装環境のリソー
ス量情報を格納すると共に、これら複数種類のリソース
量情報について動作判定処理を順次試行することとした
り、これら複数種類のリソース量情報をアンド条件で満
足することを実行可能判定の条件とすることとしてもよ
い。このような構成とすれば、アプリケーションのダウ
ンロード機能をもつ携帯電話機の場合のように、送受信
側が共に多様なハードウェア構成をもつ場合などに本発
明を有効に適用できる。

【００５４】また、本発明における動作判定機能は、こ
れを周知のパーソナルコンピュータに着脱自在に接続す
ることでその一部の機能を実現する負荷計測ボードまた
は検証ボードとして提供することも可能である。すなわ
ち、ＣＰＵ・ＲＯＭ・ＲＡＭ・入出力インターフェース
をバスラインで相互に接続してなる周知のワンチップマ
イクロプロセッサボードに、タスク管理テーブル９およ
びリソース量情報格納部１０に相当する各情報と、上記
第１または第２実施形態もしくはその変形例の処理プロ
グラムとを格納した形で提供してもよく、本発明による
所期の効果を得ることができる。

【００５５】また、本発明に係る動作判定プログラム
は、複数のタスクを含むプログラムを対象にシステムに
おける実行可能性をコンピュータに判定させるための動
作判定プログラムであって、前記判定対象プログラムを
構成するタスクの情報を構成情報として取得する構成情
報取得処理と、前記構成情報に基づいて、同時に実行さ
れることで一機能となり得る前記タスクの組合せを抽出
する機能抽出処理と、前記タスクの夫々について実行に
必要なリソース量の情報を取得する所要リソース量情報
取得処理と、前記抽出されたタスクの組合せと、前記所
要リソース量情報とに基づいて、前記判定対象プログラ
ムが有する全ての機能について実行可能性を判定する判
定処理と、をコンピュータに実行させるための動作判定
プログラムとして構成でき、これをＣＤ−ＲＯＭなどの
公知の記録媒体に記録した状態で、あるいはネットワー
ク経由のダウンロードによって取引でき、本発明の効果
を実現するための有用な手段として用いることができ
る。

【図面の簡単な説明】

【図１】 本発明の第１実施形態に係る動作判定装置の
ブロック図である。

【図２】 タスク管理テーブルの一例を示す説明図であ
る。

【図３】 第１実施形態におけるタスク構成の一例を示
すツリー図である。

【図４】 第１実施形態における動作判定処理を示すフ
ロー図である。

【図５】 第２実施形態における動作判定処理を示すフ
ロー図である。

【符号の説明】

１ 動作判定装置、２ ＣＰＵ、３ タイマ、４ 記憶
装置、５ メモリ、６ネットワーク制御部、７ 内部バ
ス、８ 動作判定プログラム格納部、９ タスク管理テ
ーブル、１０ リソース量情報格納部、２１ タスク情
報管理テーブル、２２ 構成情報管理テーブル。

Claims (9)

【特許請求の範囲】
1. 【請求項１】 複数のタスクを含むプログラムを対象に
   システムにおける実行可能性を判定する動作判定装置で
   あって、 判定対象プログラムを構成するタスクの情報を構成情報
   として取得する構成情報取得手段と、 前記構成情報に基づいて、同時に実行されることで一機
   能となり得る前記タスクの組合せを抽出する機能抽出手
   段と、 前記タスクの夫々について実行に必要なリソース量の情
   報を取得する所要リソース量情報取得手段と、 前記抽出されたタスクの組合せと、前記所要リソース量
   情報とに基づいて、前記判定対象プログラムが有する全
   ての機能について実行可能性を判定する判定手段と、 を備えた動作判定装置。
2. 【請求項２】 請求項１に記載の動作判定装置であっ
   て、 前記複数のタスクのうち所要リソース量が制御可能な可
   変タスクにつき、その所要リソース量を補正する所要リ
   ソース量補正手段を更に備え、 前記判定手段は、実行不可能との判定があった場合に、
   前記抽出されたタスクの組合せと、前記補正後の所要リ
   ソース量とに基づいて、前記判定対象プログラムが有す
   る全ての機能について実行可能性を更に判定することを
   特徴とする動作判定装置。
3. 【請求項３】 請求項１または２に記載の動作判定装置
   であって、 前記判定手段が、前記システムにおいて複数の判定対象
   プログラムを並行動作させる場合の実行可能性を判定す
   ることを特徴とする動作判定装置。
4. 【請求項４】 複数のタスクを含むプログラムを対象に
   システムにおける実行可能性を判定する動作判定方法で
   あって、 判定対象プログラムを構成するタスクの情報を構成情報
   として取得する構成情報取得ステップと、 前記構成情報に基づいて、同時に実行されることで一機
   能となり得る前記タスクの組合せを抽出する機能抽出ス
   テップと、 前記タスクの夫々について実行に必要なリソース量の情
   報を取得する所要リソース量情報取得ステップと、 前記抽出されたタスクの組合せと、前記所要リソース量
   情報とに基づいて、前記判定対象プログラムが有する全
   ての機能について実行可能性を判定する判定ステップ
   と、 を含む動作判定方法。
5. 【請求項５】 請求項４に記載の動作判定方法であっ
   て、 前記複数のタスクのうち所要リソース量が制御可能な可
   変タスクにつき、その所要リソース量を補正する所要リ
   ソース量補正ステップを更に含み、 前記判定ステップでは、実行不可能との判定があった場
   合に、前記抽出されたタスクの組合せと、前記補正後の
   所要リソース量とに基づいて、前記判定対象プログラム
   が有する全ての機能について実行可能性を更に判定する
   ことを特徴とする動作判定方法。
6. 【請求項６】 請求項４または５に記載の動作判定方法
   であって、 前記判定ステップでは、前記システムにおいて複数の判
   定対象プログラムを並行動作させる場合の実行可能性を
   判定することを特徴とする動作判定方法。
7. 【請求項７】 複数のタスクを含むプログラムを対象に
   システムにおける実行可能性をコンピュータに判定させ
   るための動作判定プログラムであって、 判定対象プログラムを構成するタスクの情報を構成情報
   として取得する構成情報取得処理と、 前記構成情報に基づいて、同時に実行されることで一機
   能となり得る前記タスクの組合せを抽出する機能抽出処
   理と、 前記タスクの夫々について実行に必要なリソース量の情
   報を取得する所要リソース量情報取得処理と、 前記抽出されたタスクの組合せと、前記所要リソース量
   情報とに基づいて、前記判定対象プログラムが有する全
   ての機能について実行可能性を判定する判定処理と、 をコンピュータに実行させるための動作判定プログラ
   ム。
8. 【請求項８】 請求項１ないし３のいずれか１に記載の
   動作判定装置、請求項４ないし６のいずれか１に記載の
   動作判定方法、または請求項７に記載の動作判定プログ
   ラムと関連して用いられる判定対象プログラムであっ
   て、 その判定対象プログラムの構成情報を格納する構成情報
   格納手段を備えたことを特徴とする判定対象プログラ
   ム。
9. 【請求項９】 請求項１ないし３のいずれか１に記載の
   動作判定装置、請求項４ないし６のいずれか１に記載の
   動作判定方法、または請求項７に記載の動作判定プログ
   ラムと関連して用いられる判定対象プログラムであっ
   て、 機能ごとに実行に必要なリソース量の情報を格納する所
   要リソース量情報格納手段を備えたことを特徴とする判
   定対象プログラム。